#ubuntu-devel 2005-03-21
<mdz> Kamion: are yo ugoing to do a CD build for mvo to test before you go?
<Kamion> mdz: yes, will do one for just i386 and amd64
<mdz> ok
<Kamion> mdz: we're waiting for pitti's language-pack changes anyway, aren't we?
<lamont> Kamion: probably
<Kamion> so I can do the really-final build tomorrow morning
<Kamion> lamont: how badly?
<lamont> the sequence is: daily, byhand, daily, byhand
<mdz> Kamion: the language-pack issue is purely an upgrade one, but yes, I expect we will
<lamont> otherwise your upload is b0rekd
<lamont> want me to force a happy upload on i386?>
<Kamion> lamont: mdz said he byhanded something just recently
<Kamion> lamont: will that have been b0rked?
<lamont> check the dates on the files - that may have been this mornings.
<Kamion> mdz: ?
<mdz> I byhanded 200503091
<mdz> was that not the right build?
<lamont> mdz: the issue is that the daily build script uses w-b for state-storage, and w-b trashes it.
<Kamion> 200503091 was there on four architectures
* lamont goes to look
<Kamion> I only built two
<Kamion> therefore I deduce that it was not the right build
<mdz> it was the only one in the queue
<lamont> logs/debian-installer_20041227ubuntu20.0.200503091_20050309-0615
<lamont> logs/debian-installer_20041227ubuntu20.0.200503091_20050309-2238
<lamont> right.
<jon1012> someone needs some help right now ? it's strike in france tomorrow, so I on't have anything to do... so I can help tomorrow and tonight :) (I'm a C developer and a graphic designer)
<lamont> the other upload bounced.
<mdz> Package ubuntu-desktop has broken dep on esound
<mdz>   Considering esound 0 as a solution to ubuntu-desktop 0
<mdz>   Removing ubuntu-desktop rather than change esound
<mdz> BAH
<toresbe> haha
<Kamion> lamont: now that it's byhanded, it should be possible to do i386 and amd64 builds; perhaps it would be best if you disabled the cron job, so that only manual "daily" builds happen
<lamont> actually, it claims to have intsalled that version...
<lamont> Kamion: just tell me when to reenable it.
<Kamion> lamont: after preview :-)
<Kamion> but yes, will do
<mdz> lamont: 2 more hours before we get ppc?
<lamont> ppc should enter the archive at 0103 london time
<lamont> it is now 2306.
<mdz> "yes"
<lamont> so, that'd be 1:57 :-)(
* lamont was thinking out loud
<ogra_live> oh, update-manager runs in the livecd default session ?
<mdz> is there anyone here besides mvo who can test the piix fix?
<lamont> Kamion: post hoary, I'll keep the state outside of wb and merge as needed.  Worst case, we'll skip a version number or 2.
<mdz> ogra_live: itym update-notifier
<lamont> mdz: with a couple of 10 minute drives, I can go fetch the fix and abuse my daughters computer to test it.
<Kamion> lamont: nod, that would be great
<ogra_live> mdz: i'm currently running on a piix system without probs....
<lamont> current livecd verified b0rked in her computer.
<mdz> lamont: have you reproduced the bug on that machine already?
<mdz> ok
<lamont> that is, this morning's
<mdz> because mvo is going to need to sleep at some point
<ogra_live> mdz: without the fixes
<mdz> ogra_live: your system is not a good test case, then :-)
<Kamion> jon1012: currently, the bulk of development effort is going into making sure that tomorrow's preview release is rock-solid
<ogra_live> nope :)
<Kamion> jon1012: so we're all a bit distracted right now ...
<lamont> Kamion: what's the best way to find the state that the installer leaves things in before postfix's config/postinst run?
<Kamion> lamont: how much before?
* lamont is really really really not happy with the interaction...
<mvo> mdz: what is the ETA for something to test? I can manage to stay up for a bit 
<lamont> immediately before is fine...
<jon1012> Kamion: that's why I ask if I can be of any help :)
<lamont> worst case, I'll just hack the postinst/config to exit 0... :-)
<Kamion> lamont: after it unpacks postfix, edit /target/var/lib/dpkg/info/postfix.config and put 'sleep <lots>' just after '. /usr/share/debconf/confmodule' :-)
<mdz> lamont: we need a new i386 d-i build, right?
<lamont> mdz: just to be sure, we should... give me a coupl eminutes
<Kamion> jon1012: at the moment I'm afraid it's just testing testing testing, not very exciting, but welcome nonetheless
<Kamion> cdimage.ubuntu.com/daily/current/ and cdimage.ubuntu.com/daily-live/current/ are the things to test, although we'll be rolling new dailies shortly
<lamont> i386 d-i build launched
<lamont> 03092 is our friend
<Kamion> lamont: could you do amd64 too?
<Kamion> (might as well)
<lamont> Kamion: perl syntax for that sleep?  (postfix config is perl... believe it or not...)
<mdz> might as well wait, and do an 03093 for all architectures
<Kamion> mdz: that won't let mvo test tonight
<mdz> Kamion: mvo is on i386
<lamont> Kamion: amd64 launched
<Kamion> mdz: it will probably have to be 03092 on the other architectures (less confusing that way, without manual help from lamont ...)
<mdz> I'm not feeling particularly good about all this byhanding
<Kamion> I'm not feeling particularly good about committing to sabdfl for a 1200 final build when the required d-i stuff won't arrive until close to that
<lamont> mdz: but you're good at waving your hands... I've seen you.
<mdz> Kamion: eh?  we'll have a ppc kernel in 2 hours, and we'll build d-i shortly after that
<lamont> mdz: let me know about 10 min before we have new images, and I'll drive down to fetch them.
<lamont> mdz: I hope he doesn't mean midnight, because we're gonna miss that by an hour...
<Kamion> mdz: if we're waiting for 03093 on all architectures, that's +6h or whatever for ia64
<mdz> Kamion: fuck ia64
<Kamion> heh
<mdz> ia64 is explicitly and implicitly excluded anytime I say "all" ;-P
<Kamion> so why bother with 03093? that's just *more* byhanding
* lamont thinks that the current official plan for hoary/ia64 is that there might be these isos on cdimage.ubuntu.com that might work.
<mdz> Kamion: I suppose we must, because 03092 may be borked
<Kamion> how come?
<mdz> or was that 091?
<Kamion> that was 03091
<Kamion> the builds lamont recently launched should be good
<mdz> ok, fine
<Kamion> ok, that explains the confusion. :)
<mdz> so long as the next set of uploads are the last
* lamont feels less confused now
<zenwhen> A hoary install should swap between two sstems assuming they are both fully supported in the stock kernel perfectly, am I correct?
<mdz> (barring further complications)
<zenwhen> systems*
<mdz> zenwhen: not at all
<zenwhen> so a reinstall would be required?
<mdz> not strictly, no
<Kamion> you'd probably have to rebuild the initrd
<mdz> it would be sufficient to regenerate the initrd
<zenwhen> oh
<wasabi_> and fix fstab
<lamont> amd64/i386 uploaded, waiting for cron.hourly
<wasabi_> if it needs fixin
<Kamion> and fix the bootloader
<mdz> if they require different drivers to mount the root filesystem
<wasabi_> yeah
<zenwhen> Oh
<zenwhen> ok cool
<wasabi_> so does hte mkinitrd contain every storage driver or just the one that's needed?
<zenwhen> but how would I do that without booting the install
<mdz> zenwhen: #ubuntu, please
<wasabi_> you would boot it with a live cd
<zenwhen> not to bother you guys
<zenwhen> sorry
<zenwhen> I got off topic again. I know you guys are busy.
<elmo> lamont: our ia64 buildds actually have 15k SCSI disks - I don't really think that constitutes "SLOW", esp. compared with powerpc's single-disk SATA
<mdz> elmo: sabdfl insists that you sleep so that you can be abused tomorrow
<elmo> mdz: that's nice, I slept most of the afternoon tho - by mistake
<mdz> elmo: oh, good, then you'll be up late and can byhand for us?
<elmo> yeah
<lamont> elmo: OK
<mdz> thanks
<lamont> elmo: and I apologize for calling the ia64 boxen P-O-S...  Because they cost way to much to be that... :0)
<elmo> the boxes aren't POSes, they're just slow - IMHO, given how much they cost that's just a reflection on the state of the architecture far more than the boxes :p
* lamont knows when to not debate a point.. :0)
<elmo> mdz: anything for me to do now before I go catchup on what I missed?
<mdz> elmo: there should be i386 and amd64 d-i builds in byhand now or shortly
<lamont> waiting there for at least 4 minutes...
<HiddenWolf> elmo: is there actually a market for ia64 tux distro's?
<lamont> HiddenWolf: that's the question
<lamont> and so far, the answer seems to be somewhere between "NO", and "NFC"
<HiddenWolf> (if I was feeling evil, i'd say 'are there any ia64's in the wild?' now, i'd say  that if one wants a ia64 box, one wants support with it)
<Kamion> elmo: catch up on the NIGHTMARE
<HiddenWolf> kamion: how's it going?
<Kamion> HiddenWolf: it's going ... :)
<Kamion> I'm going to pass out soon and hand the baton to others
<elmo> i386/amd64 processed
<HiddenWolf> Kamion: what was the show-stopper?
<Kamion> HiddenWolf: ata_piix breakage with ATA_ENABLE_PATA
* HiddenWolf is drooling at enlightenment
<mdz> mvo: while you are waiting, I could use more ideas about how to address the esound/polypaudio upgrade issue
<mvo> mdz: is there a bugnumber? I haven't followed the discussion
<mdz> mvo: no, there is no bug currently, but I should open one
<mdz> mvo: so ubuntu-desktop depended on polypaudio, which also provides esound, and now we want upgrades to bring in the real esound package and remove polypaudio
<jdub> the versioned depend didn't work?
<mdz> (one way of looking at) the problem is, apt will consider polypaudio more important than ubuntu-desktop
<mdz> because polypaudio is depended upon by several other packages (its plugins)
<mdz> so apt will prefer to remove ubuntu-desktop and keep polypaudio
<mvo> mdz: a nasty situation
<jdub> oof
<mdz> mvo: yes
<mdz> one solution might be to remove polypaudio from the archive
<mvo> mdz: it's a drastic one, but it will certainly work :)
<mdz> and then force a conflict
<jdub> remove the provides temporarily?
<mdz> but I would prefer to find another way
<mdz> removing the provides does not help
<jdub> it still prefers to remove u-d?
<mdz> apt says: ubuntu-desktop needs esound, but when I upgrade polypaudio, esound will be gone.  I can remove ubuntu-desktop, or remove these 5 other packages of equal priority.  I'll remove ubuntu-desktop
<elmo> add a pre-depends on ubuntu-desktop to dpkg.  that'll learn apt.
<jdub> so, i'm not sure why we want to force the upgrade
<jdub> a particular class of users use hoary before preview
<jdub> and we can note it as an upgrade issue
<mdz> the problem with that
<jdub> do we need to do anything more drastic than that?
<mdz> is that it doesn't accomplish a damn thing
<mdz> we will still have thousands of users running polypaudio forever
<mdz> the right thing to do is to transition them to esound
<jdub> they're using a development branch, things change, and we can always point out the note if they raise an issue
<jdub> on this timescale, we're going to have to deal with that kind of thing
<Kamion> elmo: *laugh*
<mdz> what timescale?
<jdub> six month releases
<Kamion> ooh, openssh 4.0
<mdz> I don't see what relevance that has
<jdub> particularly once sarge is done and sid gets interesting again
<mdz> "screw you, you ran the development branch" is not a good solution
<jdub> it's not that bad
<Kamion> * Improved sftp(1) client, including bugfixes and optimisations for the 
<Kamion>   ``ls'' command and command history and editing support using libedit.
<elmo> I think it is FWIW
<Kamion> ABOUT TIME
<jdub> we have a responsibility to cleanly upgrade releases; devel branch interestingness is par for the course
<mdz> Kamion: !
<Kamion> oh, THANK GOD, they finally fixed the "store port numbers in known_hosts" thing
<Kamion> I've lost count of the bugs I have about that
<Kamion> erm, at least I think they did, the changelog is not entirely clear
<HrdwrBoB> the primary problem with sftp is you have to have a login account to use it
<Kamion> actually maybe not, oh well
<mdz> HrdwrBoB: you're thinking of scp
<mdz> sftp addresses exactly that problem
<HrdwrBoB> mdz: sftp too
<HrdwrBoB> unless it's change in the last six months
<HrdwrBoB> changed
<mdz> nope, from the beginning
<Kamion> that's a bit like saying "the primary problem with apples is that they aren't oranges"
<Kamion> sftp is very useful within its use case
<mdz> unless you mean something other than "shell access" when you say "login account"
<Kamion> but certainly yes, the subsystem facility in SSH2 is meant to allow for this kind of thing
<mdz> Kamion: shall we roll a CD build for mvo?
<Kamion> I thought you were talking about lack of anonymous sftp
<HrdwrBoB> mdz: yeah
<Kamion> mdz: about to
<HrdwrBoB> not not anon ftp
<Kamion> building amd64/i386, no jigdo
<Kamion> note that this means people will see powerpc "disappearing" from daily/current
<Kamion> might want to direct them to 20050309.1
<lamont> Kamion: does that mean that later when ppc is done, we gen all 3?
<Kamion> yeah, but I'll probably just do that tomorrow morning
<lamont> or just ppc, and do some hand migration of files/links?
<elmo> OOI where did the other two arches go?
<Kamion> elmo: waiting for updated kernels
<Kamion> no point otherwise
<elmo> ah
<Kamion> lamont: we're getting updated language-packs anyway
<Kamion> mvo: ok, images up for you
<Kamion> http://cdimage.ubuntu.com/daily/20050309.2/hoary-install-i386.iso or equivalent rsync
<mvo> Kamion: thanks, downloading now
<Kamion> cjwatson@little:~/cdimage/www/full/daily/current$ isoinfo -R -i hoary-install-i386.iso -x /install/initrd.list | grep sata-modules
<Kamion> sata-modules-2.6.10-4-386-di 2.6.10-25.1
<jdub> mdz: the timescale is relevant because the amount of change in a short period of time forces you to be comfortable with push-and-revert as a change management technique; it's tougher for us because we also have packaging toolset issues to consider.
<mdz> jdub: our rate of change is slower than Debian's
<jdub> mdz: unfortunately, epochs and task packages are icky things, and everyone wants to feel a certain level of cleanliness.
<mdz> this is a technical issue; the fact that the solution isn't apparent doesn't mean that we throw up our hands just yet
<mdz> I assume you agree that if we can transition everyone, that's simply better
<mdz> so I'm going to continue to look for a way
<jdub> sure, but i'm not going to scrub my hands twice a day and flick lightswitches 9 times to make sure :)
<mdz> certainly not
<jdub> our policy implementation is pretty brittle
<jdub> (and on the agenda for UDU)
<GheRivero> res
<thom> hm, Message-ID: <a2ce2a0e050309155334320d1d@mail.gmail.com> on users is presumably just a reiteration of fabio's problem
<mdz> thom: can you ask them to test the latest daily?
<thom> mdz: sure can
<Kamion> I just sent mail about that
<Kamion> saying exactly that :)
<Kamion> and I just got bug #7386 about it too
<Kamion> amazing how it's obvious how many things are the same problem once it's diagnosed
<jbailey> thom: Figured out the sulogin problem.  This was a sarge->hoary upgraded machine, and sysvinit is newer in sarge.
<thom> ah
<Kamion> sigh, see #1440
<Kamion> somebody who's awake please diagnose
<lamont> grumble
<Kamion> although actually I suspect he has a piix chipset
<Kamion> perhaps he installed with array 6 or greater, and is therefore relying on the devices being scsi
<lamont> Kamion: wouldn't surprise me...
<lamont> must ask him though
<lamont> I think at this point, if we wind up re-opening 1440 with -25.1, we still ship, and call it RC for release
<Kamion> yes
<jbailey> I'll reply to it, just a sec.
<lamont> shipping -25 is completely unacceptable, since it causes data corrpution
<lamont> jbailey: thanks
<jbailey> Is it impolite for me to add him to the cc: list of the bug and just reply to the bug?
<Kamion> not in my book
<Kamion> (i.e. go ahead)
<jbailey> Lovely.  I don't want to lose things from the trail.
<Kamion> night folks
<lamont> Kamion: remind me..
<jbailey> g'n Colin
<lamont> the end of stage 1 is after debootstrap, but basically before just about everything else?
<lamont> or what else happens before the reboot?
<lamont> that is, how much of base-* has run?
<Kamion> lamont: debootstrap, kernel install, initrd-tools install and initrd generation, archive-copier, timezone/shadow/apt config, bootloader setup, bits and pieces to prepare for base-config
<Kamion> base-config has not yet run, although a few bits of it have (timezone/apt config)
<lamont> ok'
<lamont> Kamion: and btw....
<lamont> for hoary+1 we should really notice when there's only one network cable plugged in (and eth1 doesn't have link), and just use that...
<Kamion> mii/ethtool lies sometimes
<Kamion> it's infuriating and crap but apparently true
<lamont> yeah
<lamont> anyway, sleep
* lamont bbia 5-10 min
<HiddenWolf> I'm afraid to ask, but is there any place where I can check up on the gnome 2.12 -> 3.x goals?
<thom> HiddenWolf: live.gnome.org is the gnome wiki
<thom> certainly there's 3.0 discussion there
<HiddenWolf> thom: thanks, the gnome website is a jungle
<thom> jdub: ^^
<jdub> uh huh
<jdub> live is wildly unliked from everywhere :)
<jdub> ha ha
<jdub> unlinked
<elmo> W: GPG error: http://archive.ubuntu.com hoary Release: Could not execute /usr/bin/gpgv to verify signature (is gnupg installed?)
<elmo> that's a bit spethial
* T-None uninterruptible_sleep();
<jbailey> T-None: That sounds like a challenge.
<T-None> not for me, I promise :)
<jbailey> T-None: Hah!  I was succesful.
<T-None> ROTFL
<T-None> damn you ;)
<lamont> dh_fixperms -s
<lamont> xargs: chown: terminated by signal 4
<lamont> dh_fixperms: command returned error code
* lamont SCREAMS!!
<lamont> mdz: linux-source-2.6.10_2.6.10-25.1_20050310-0012 03:08:44 (5 entries, sigma 01:28:21)
<lamont> so, depending on it's mood, I'm inclined to believe the worst (04:36), but hey...
<lamont> plan on seeing ppc kernel binaries somewhere around 0333 or 0403
<lamont> jbailey: find that ppc SIGILL source and kill it, 'k?
<jbailey> lamont: You sure it's not hardware?  I don't do a ton of compiling, but I've done gcc and glibc a few times and not seen it on my box.
<lamont> jbailey: happens on our good boxes, which pass memtests and such. happens on debian's buildd.
<lamont> predominantly during kernel compiles and other really long builds
<lamont> but not always
* koke 's eyes are about to close
<lamont> so do we have something pretty to use for labels for hoary-preview local burns?"
<jdub> no
<jdub> hopefully for release we will
<lamont> jdub: grumble
<lamont> jdub: but I want it, NOW!!!!!
* jdub sends lamont a picture of a bum with a fist coming out of it.
<lamont> (with apologies to willy wonka)
<lamont> how about a piix chipset with a red circle-slash?
<mdz> lamont: DOH
<lamont> mdz: uh, yeah.
* lamont considers just launching it on all 3, to see which one wihns
<lamont> actually, I think I will do that
<mdz> lamont: I don't suppose ccache is working on that box
<lamont> mdz: well, it gets pretty invalidated.
<lamont> all 3 ppc boxes are taking a stab at the build...
<lamont> one of them will make it, and I apologize for what it'll look like under buildLogs...
<mdz> lamont: it gets invalidated? why?
<lamont> either size or variety of compiliations
<mdz> the size of that cache, last time we talked about it, is way larger than a kernel build
<mdz> O(gigabytes), no?
<lamont> cache hit                          43230
<lamont> cache miss                        141733
<lamont> cache size is 7-10 GB on those machines
<mdz> ...and 1440 has been reopened
<mdz> though it doesn't sound like the same issue, it is a new issue with -25.1
<lamont> well, given that we removed part of the change that fixed him in -25, and things broke, I expect that it may be highly related.
<lamont> but I don't think 1440 is necessarily a preview-blocker
<lamont> certainly a release-blocker
<mdz> who is him?
<lamont> dunno
<lamont> the final commenter who reopened it
<lamont> that jbailey replied to
<mdz> he had not participated in the bug until that time
<mdz> as far as i know he wasn't experiencing #1440, and his symptoms don't sound the same
<jbailey> I can check against my laptop and against the SATA machine.
<jbailey> laptop will happen tonight, the sata machine is best rebooted early in the morning.
<jbailey> The 'too much time' comment also doesn't make alot of sense.
<zenwhen> is 1440 an install blocker?
<lamont> zenwhen: the "fix" for it in -25 was
<HiddenWolf> zenwhen: it'll mess a lot of people up if it isn't fixed, so yes
<lamont> mdz: do we have new i386/amd64 images?
<zenwhen> i have a machine with sata I can test array 6 on. Would that information be of ANY benifit?
<mdz> mvo: have you been able to test the CD?
<mdz> lamont: yes
<zenwhen> Its the newest disk I have.
<lamont> mdz: OK.  off to go download, I guess
<mdz> zenwhen: array 6 is pretty much irrelevant at this point
<zenwhen> ok. just checking.,
<mvo> mdz: download/burning just finished, booting now
<mdz> mvo: great, thanks
<zenwhen> ll be doing daily install testing and stuff for you guys in a month.
<lamont> cdimage/daily-live/current/hoary-live-i386.iso, yes?
<lamont> why is that claiming to be current....
<lamont> or are the current links not moved yet?
<mvo> mdz: is working now
<mvo> mdz: only piix is loaded, no ata_piix
* lamont finds himself confused....  ENOCURRENTIMAGE
<mdz> <Kamion> http://cdimage.ubuntu.com/daily/20050309.2/hoary-install-i386.iso or equivalent rsync
<mdz> mvo: ok, good
<mvo> mdz: I continue installing now and see if it goes all well
<lamont> ah, no livecd then. got it.
<mdz> does anyone here have a system with SATA disks?
<elmo> the powerpc buildds do - dunno if that counts
<mdz> SATA disk and ATAPI CD-ROM?
<jbailey> mdz: Yes.
<mdz> jbailey: but you said you couldn't test until morning
<mdz> morning for you is the time we need our final candidate build
<jbailey> mdz: Lemme just check about doing it now, hold a sec.
<HiddenWolf> guys: don't forget to update the release notes; now 'on the very same day as the gnome 2.10 release' is 'a mere day after the release of gnome 2.10' 
<zenwhen> "Before anyone else. Thats all that counts."
<HiddenWolf> agreed, but the release notes state 'on the same day' 
<zenwhen> Oh, I agree. I was adding.
<zenwhen> ;)
<jbailey> mdz: All we need is a reboot test to see if it sees the cdrom, right?
<mdz> jbailey: I think so
<mdz> jbailey: the fact that he's talking about disks to me indicates that he isn't experiencing the CD-ROM problem
<mdz> jbailey: I think Colin's guess is reasonable
<jbailey> Yeah.
* lamont grumbles at the machine he was testing on
<mdz> he probably installed with array 6, has a /dev/sd* device in /etc/fstab because of it, and now his disk is a /dev/hd* device
<lamont> mdz: that would make sense
* HiddenWolf is so glad he's been on hoary from the start
<lamont> nothing like an expert install to make you appreciate Kamion's work
<mdz> jbailey: if you can reconfirm with -25.1, I'll follow up
<jdub> lamont: hear hear.
<jbailey> mdz: Cool.  After this I need to run out and meet my wife.  It's out wedding aniversary today. =)
<mdz> elmo: I'm not sure if that counts either
<HiddenWolf> jbailey: congratulations
<lamont> jbailey: happy anniversary to both of you
<lamont> er, you both, even. :-)
<jbailey> ROFL
<jdub> jbailey: congrats. years?
<thom> jbailey: congrats
<jbailey> jdub: 3 =)
<mdz> you crazy people and your marriages
<jdub> jbailey: cool :)
<thom> mdz: it seems fashionable currently...
<m_tthew> mdz: hear hear
* HiddenWolf goes and looks up the stats that show there are more singles than ever
<ogra> mdz: doesnt it save taxes in US ?
<jbailey> jdub: That doesn't scare me as much as the fact that in January we celebrated 9 years of being together...  
<jdub> thom: you know pipka would kick your butt for that comment. :-)
<jdub> thom: btw, measurements?
<jbailey> In that time my sister was engaged twice, married once, had a kid and got divorced. =)
<jdub> heh
<mdz> ogra: no, it only saves you from filing two tax returns
<ogra> lol
<m_tthew> ogra: in fact, it can hurt in us taxes
<jdub> ogra: (so only one of you needs to be able to spell)
<mdz> HiddenWolf: marriage is on the rise in Ubuntu
<koke> mmm, someone had asked for cd labels??
<ogra> mdz: if i would marry my gf it would drop mine about a third 
<HiddenWolf> mdz: in the general population, it's going down, in all minorities except gays, actually. :)
<jdub> ogra: that's the perfect start to a proposal :-)
<jon1012> lool
<mdz> HiddenWolf: and except Ubuntu developers
<jdub> ogra: "the money we save can go to a honeymoon in... um... sydney. in april. yeah."
<mdz> a tiny but growing minority
<ogra> jdub: remember i dont pay taxes currently ;)
<HiddenWolf> mdz; let's hope it grows fast. :)
<mdz> m_tthew: I don't suppose you have any SATA boxen lying around
<thom> jdub: heh; i'll get them for you by monday
<jdub> thom: ta. pia is very excited about your frock.
<jbailey> rebooting it..
* thom throws things at jdub idly
<thom> actually; WHY IS IT 01:15? i was going to bed at midnight
<thom> night
<jbailey> It takes about three minutes to reboot from here until I see grub on the serial console.
<jdub> gute nacht
<ogra> jdub: GF says she wants a more romantic reason than this ....
<dredg> ogra: tell her she's not commited enough
<koke> lamont: a present for you ;) http://www.amedias.org/~koke/misc/ubuntu-preview-cd.svg
<dredg> or don't... :)
<jbailey> ogra: Weddings are not romantic.  Weddings are where you get to learn just how ugly you both can be.  It forms the bonds on which you can build romance later ;)
* jdub has fried brain, ploddingly upgrades his home server to hoary
<koke> lamont: you even can do export CURDATE=`date -u +%Y%m%d%H%M`; cat ubuntu-preview-cd.svg | sed -e "s/YYYYMMDDHHMM/$CURDATE/" > ubuntu-preview-cd.$CURDATE.svg
<ogra> jbailey: its not about weddingd, its about the reason for it :)
<thom> hrm; firefox asking what app to display something with, with the default set to firefox, could get kinda recursive
<jdub> ogra: ha ha
<dredg> ogra: right. cake.
<jbailey> mdz: On the SATA HD, IDE CD system I no longer see the CD at all.
<lamont> koke: to do what?
<mdz> jbailey: IOW, 1440 has indeed regressed
<mdz> and in addition, all SATA systems installed with array 6 are rendered unbootable
<koke> put the build date in the label or wathever you want (array cd X)
<koke> or you can remove the build line :)
<jdub> koke: nice svg :-)
<mdz> we may even be worse off than before! :-P
<koke> CD's are 12cm ?
<koke> I can't remember
<mvo> mdz: grub failed on my system (test-install). error in in unifont it seems
<jbailey> mdz: I don't see how they would be unbootable.  My sata system still sees all the drivers as /dev/sda* anbd /dev/sdb*
<jbailey> Just no cdrom as part of the set.
<mdz> jbailey: but it's not piix
<mdz> right?
<jbailey> This is ata_piix
<mdz> ata_piix shouldn't be used with -25.1
* koke sleep(MIN_SLEEP_TIME)
<jbailey> mdz: It is because initrd-tools is stupid and keep loading whatever you had before.
<jbailey> But right, I see your point.  Other systems may have detected it as piix and gotten installed that way.
<jbailey> Oy, nasty.
<mdz> this whole hd* vs. sd* has been a disaster from the beginning
<mdz> but to see the same hardware both ways is insane
<jbailey> My piix laptop (all pure IDE) sees HD and cdrom fine.
<mdz> jbailey: was your piix laptop broken with -25?
<jbailey> mdz: No.
<jbailey> But again, off of an upgrade, not off of a new install.
<jbailey> These problems will show up more clearly with hotplug in the initramfs.
<mvo> the error is (on seting up unifont): "/usr/X11R6/bin/mkfontscale: No such file for directory" 
<mvo> has anyone seen this before?
<mdz> mvo: never. I thought you said the problem was grub?
<jbailey> Gotta run, back in a couple of hours.
<mdz> it is not at all clear to me that -25.1 is an improvement over -25, overall
<mvo> mdz: that the message from debconf, but I see on the console that the actual problem is that one package (unifont) was not fully installed and dpkg tries to configure it now
<mdz> fixes mvo, breaks jbailey
<mdz> mvo: check /var/log/syslog
<dredg> mvo: xbase-clients: /usr/X11R6/bin/mkfontscale
<mdz> or is it /var/log/messages
<mdz>  /var/log at any rate
<mdz> mvo: is there any earlier failure which could be responsible?
<mvo> mdz: there is a E: Couldn't find package bterm-unifont
<mvo> (greping for unifont)
<mdz> mvo: which locale are you using?
<mvo> mdz: german
<mvo> here are some more: "E: couldn't find localization-config, jfbterm"
<mvo> and it does not install xbase-clients (which according to dreg has mkfontscale)
<mvo> only "cpp cpp-3.3 libfreetype6 libfs6 unifont xorg-common xutils"
<mdz> that's because unifont doesn't depend on it
<mdz> but unifont doesn't get installed on my systems, either
<lamont> mdz: what can I do to be most useful?  thinking fetch the damn install image, and verify locally, eh?
<mdz> lamont: yes
<lamont> right. back online and off again for a bit.
<mdz> lamont: at this point we need to figure out how bad -25.1 is and what to do about it
<mdz> mvo: wait
<mdz> mvo: is this stage 1 or stage 2?
<mdz> mvo: I had assumed stage 1 because you said grub failed to install
<mvo> mdz: stage 1
<mdz> mvo: unifont is only installed when you use certain locales
<mdz> as I understand it
<mdz> thully: before you ask where the preview release is, please read ubuntu-devel or /topic
<crimsun> mvo: When you have time, a question regarding gnome-apt in hoary/universe: I rebuilt it against apt 0.6.34, which necessitated a change to src/gdeb/main.cc:Filelist() [line 231] . I take it 'ExtractTar tpart (df->GetFile(), data->Size, "gzip");' is sufficient?
<mvo> oh, I hit "greek" (very close to german) at the beginning, but I changed that to german afterwards
<thully> no - I already saw the delay notice
<mvo> crimsun: I already uploaded a fixed version
<crimsun> d'oh
<mvo> crimsun: it will understand both gzip and bzip2 :)
<crimsun> mvo: thanks.
<mdz> mvo: ok, that's what caused it
<mdz> mvo: you found a bug
<mvo> crimsun: but your analysis is correct, "gzip" would have done it for virtually all cases
<mvo> mdz: a interessting one
<mvo> mdz: I guess I report it now and try again
<mdz> mvo: what I don't understand is why this caused grub to fail
<bob2> so
<bob2> the smartlink modem drivers in hoary are broken
<bob2> since they Depend on kernel-image-blah
<mdz> bob2: universethx
<mvo> mdz: unifont fail and then grub is installed and dpkg tries to setup unifont (that failed before). so the run fails and debconf reports it as a grub failure
<bob2> mdz: does this mean I get to make MOTU fix it?
<mdz> this is the preview release crisis channel :-P
<mdz> bob2: it means we aren't very sympathetic in this particular channel right now
<bob2> hah, I'll get out of your way then, sorry
<mvo> and the sleepy people channel (at least in my case)
<ogra> mvo: mine too, but its to exciting to go to bed :)
<mdz> mvo: file the bug against xutils
<mdz> mvo: mkfontdir (xutils) calls mkfontscale (xbase-clients) but xutils doesn't depend on xbase-clients
<mdz> daniels: ^^^
<mvo> mdz: commited as #7391
<mvo> mdz: isn't there still a bug in the installer? my language is german not greek so there is probably no need to installed the unifont package
<mvo> ogra: exciting? *cough*
<mdz> mvo: when you select your language, it queues packages for installation
<mdz> there is no mechanism to undo that if you switch languages
<mvo> mdz: aha, ok :)
<mvo> fair enough
<mdz> mvo: probably it should not allow you to change your language, but force you to start over
<mdz> mvo: so probably worth a bug
<jon1012> good night everybody :)
<elmo> Mithrandir: ?
<dredg> ok, excessive problems focusing. 
* dredg beds
<mvo> mdz: not tonight :)
<m_tthew> mdz: I have no SATA drives anywhere
<m_tthew> I do have SATA amd64 hardware, though.
<ogra> bob2: put the slmodem package here: http://www.ubuntulinux.org/wiki/MOTUTodo
<mdz> my current feeling is that since -25.1 seems to have regressed #1440 anyway, we should revert the patch entirely, rather than only the half of it that we did already
* lamont_r rsync
<lamont_r> s
<mdz> thoughts?
<lamont_r> we could do that
<jdub> dpkg: error processing /var/cache/apt/archives/perl-base_5.8.4-6_i386.deb (--unpack):
<jdub>  trying to overwrite `/usr/lib/perl/5.8', which is also in package liblockfile-simple-perl
<jdub> ^ hrm
<ogra> jdub: i thought that was fixed....
<jdub> meh, universe package
<ogra> jdub: nope
<jdub> liblockfile is
<lamont_r> mdz: if we completely reverse it, then we get backto a very known state...
<ogra> jdub: perl dependency bug
<lamont_r> and at that point, we can start thuroughly exploring the various combinations of things, to deal with the issue correctly.
<lamont_r> thoughts?
<mdz> any other kernel team folk around to offer an opinion?
<lamont_r> t-bone and fabbione fell over a whileback
<lamont_r> zul is sitting at about 2050 now, should be around if he's not outand about
<lamont_r> jbailey went to do marital things.
<lamont_r> and so I think it is down to you, and it is down to me.
<lamont_r> sadly, I think reverting it completely still leaves anyone who installed with -25 in a bad world, given the right (wrong) hardware
<ogra> jdub: http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004964.html
<mdz> in favour of -25.1: it's already built and ready, and it seems to fix the PIIX issue from -25
<bob2> ogra: thanks!
<mdz> in favour of reverting more: more tested code path
* lamont_r has an install CD image... anything more before I run back home?
<mdz> if we can get any responses from #1440, that'll give us more information to go on
<mdz> lamont_r: I don't suppose so
<jdub> ogra: ahr
<lamont_r> ok.  back online in about 5-10 then
<jdub> so perl-base should conflict with earlier versions or soemthing
<ogra> jdub: since pitti rebuilt perl last week i thought it was fixed
<mdz> jdub: hell no
<jdub> what's the or-something?
<mdz> a new versioned conflict in an essential package is not a place I want to go right now
<jdub> i'm totally not talking about "right now"
<mdz> jdub: "it's an unsupported package, too bad"
<mdz> I suggest applying your earlier strategy for polypaudio here
<jdub> bitterness aside, this is a different issue
<ogra> jdub: i'll write down my experience with angry users for you ;)
<mdz> it's the same issue
<jdub> i think it's pretty demonstrably not
<jdub> it's not relevant to the preview, however
<zul> hey
<mdz> zul: hi
<mdz> zul: we're trying to decide whether to roll back the remainder of the patch for #1440
<zul> is it not working?
<mdz> zul: well, it seems that it has caused #1440 to recur anyway
<zul> i would roll it back then
<mdz> I had hoped to get some feedback from the people who experienced #1440, but the only example we seem to be able to get right now (one of jbailey's machines) doesn't see its CD-ROM now
<zul> gah...then the patch doesnt fix it then we have to look to at another way then
<lamont> moof
<mdz> there's also the issue (commented in #1440) where people who generated initrds using -25 may not be bootable with -25.1, but I tihnk we're stuck with that one
<lamont> ah, zul is back
<zul> sorry i jut got back from futsal
<jdub> hrm
<jdub> i'm not even sure how useful my test will be
<mdz> a new kernel build costs us something over 4 hours
<mdz> deadline is in 10 hours
<jdub> reports so far seem to be using same controller
<mvo> mdz: stage1 completted, correct this time
<mdz> mvo: thanks for testing
<zul> is it not detecting any cd-rom or is it just the i/o corruption
<mdz> Mar 09 17:23:21 <jbailey>       mdz: On the SATA HD, IDE CD system I no longer see the CD at all.
<zul> bullocks
* lamont burns a CD
<mdz> I believe that's the system where jbailey tested the fix for #1440, so it's pretty solid evidence
<mdz> but it is only a single instance
<lamont> mdz: and reverting the rest of the patch doesn't correct that issue either, right?
<mdz> at this point I am leaning toward reverting it entirely, but am concerned about the time we lose by doing that
<mdz> lamont: it definitely doesn't
<zul> lamont: then you are right back at square one 
<mdz> but it tells us that the portion of the patch we are still applying is not giving us the benefit we hoped
<zul> i would say bite the bullet
<mdz> and could be causing other unknown problems
<mdz> they're both bullets :-)
<lamont> right
<mdz> lamont: how are those ppc builds doing?
<mdz> that is, how long until we could actually have -25.1 all around if we wanted it?
<lamont> mdz: 2 still chugging along
<zul> couldnt you leave it in powerpc but disable it in 686 et al?
<mdz> lamont: what time did they start?
* lamont finds the failure on the other one rather confusing, probably related to my evilness
<mdz> zul: it's a possibility
<zul> find like a really fast computer and shoe horn it in
<lamont> 0012 and 0045 respectively
<mdz> so nearly half finished
<lamont> yeah
<lamont> power4 done x2, power 3 in prog on one, done on the other.
<mdz> hmm, jbailey's system was piix
<mdz> I guess that explains why it regressed for him
<mdz> I wonder if all of the #1440 problems were in fact piix systems
* lamont goes to boot his daughter's machine
<zul> they probably were because there were some positive bug reports
<mdz> the ones where dmesg output is available, seem to be
<mdz> so we established that the only effect of ATA_ENABLE_PATA was to cause ata_piix to be used for certain devices
<lamont> daughter's piix/no-sata computer is fixed with 25.1
<mdz> so if that's the bit that fixed it, that seems to imply that piix doesn't see the CD devices, but ata_piix does
<lamont> mdz: whatever got loaded on my daughter's computer saw the CD...
<mdz> what other drivers use libata currently?
<mdz> lamont: as far as i know, #1440 has only ever been observed on sata systems
<mdz> I'm leaning toward staying with -25.1
<mdz> ATA_ENABLE_ATAPI could very well fix some instances of #1440
<zul> http://linux-pel.blog-city.com/read/742498.htm
<mdz> zul: or, apparently, it could break things entirely :-)
<mdz> ok, let's back it out
<lamont> mdz: well -25 died beautifully on my daughter's machine...
<mdz> lamont: right, so you confirmed that the piix regression is fixed by reverting ATA_ENABLE_PATA
<lamont> yes
<zul> mdz: yeah i think turning into the black sheep of the kernel team thanks...;)
<mdz> zul: hmm?
<mdz> http://people.ubuntu.com/~mdz/temp/linux-source-2.6.10_2.6.10-25.2.debdiff
<mdz> look reasonable?
<mdz> I just copied 00list-25.1 to 00list-25.2 and removed enable_atapi_ata-2.dpatch from it
<mdz> and copied the $#!$#@!$ hppa list
* mdz growls at lamont
<elmo> hmm, if we're going to have more kernel uploads, I'm going to find a 24 hour shop with kaffeine
<mdz> elmo: it might be better to just get some sleep
* lamont looks up
<lamont> mdz: pretty please also copy 00list-25.1.hppa
<lamont> oh.  much clearer now
<mdz> lamont: <mdz> and copied the $#!$#@!$ hppa list
<zul> mdz: nothing :) we can try building a test kernel after the preview to test the enable_atapi
<elmo> mdz: you won't be needing ftp-ish stuff for a while?
<mdz> ok, I'm uploading this, then
<lamont> mdz: that would be the patch I would do
<lamont> I'll push it into baz then
<mdz> elmo: not for hours
<mdz> and I can do it in a pinch
<lamont> elmo: although a little cron.daily love wouldn't hurt, once the upload is there
<lamont> although 15 minutes on 4 hours doesn't really make much differencce
<mdz> perhaps we shouldn't bother with powerpc
<lamont> are there any ppc machines taht would be affected by this?
<lamont> s/aff/eff/
<mdz> apparently there are ppcs at the data centre with sata
<mdz> anyway, -25.2 uploaded
<jdub_> surely it's controllers that support both pata and sata
<mdz> 3 minutes past cron.daily
<jdub_> that's what most of the libata warnings have been about
<jdub_> my sii+piix machine doesn't get any of thise
<mdz> jdub_: neither #1440 with -25.1, nor the piix bug with -25?
<jdub_> definitely not 1440
<jdub_> i'll have to install -25
<zul> is the -25.1 with the pata set back to #undef?
<lamont> zul: yes
<mdz> yes, and -25.2 reverts both enable_pata and enable_atapi
<zul> ok
<mdz> elmo: I would not object if you were to kick cron.daily to save us 20 minutes
<lamont> zul: through the simple technique of removing the patch from 00list-25.2
<jdub_> no, not even worth trying here, this class of bug can't affect me
<elmo> mdz: will do, waitin for exising one to finish
<zul> lamont: lol
<jdub_> i have a sata only sii board, separate from my piix onboard controller
<elmo> one day I'll get cron.daily not to actually run every 30mins - pitti's habit of leaving security crap in queue/accepted causes that atm
<lamont> elmo: queue/pitti-crap?
<lamont> what we need to gather is a list of all the combinations, and who (competent to test) has them
* lamont goes to force the failure of -25.1 on ppc
<lamont> mdz: or do we want to let that finish?
<mdz> lamont: no, -25.2 is the one true build
<lamont> right
<zul> if you enable pata in ata_piix on 0x7x111 0x24dh and 0x25a2 are turned on if im following it correctly
<mdz> we're going to fix the fact that it applies and unapplies 27 sets of patches for each build, right?
<lamont> wow.  killmake is pretty effective... :-)
<mdz> zul: right
<zul> mdz: oh hell yeah we are going to fix that
<mdz> zul: which caused both ata_piix and piix to be loaded for the same device, which broke
<lamont> zul: and that directly leads to 2 drivers thinking they own the dma engine, if I'm understanding this morning's discussion
<zul> ah ok..
<lamont> do they make CDRW's that'll do better than 10x?
<mdz> the ones I have here say 16x-24x
<lamont> guess I should buy some then
<lamont> and give these 8X beasts to someone in need
<mdz> you can have mine
<mdz> i've given up on writable CD media
<mdz> it's all crap, and so is cdrecord
<lamont> you just burn cd-r's?
<mdz> I mostly use DVD+RW; the discs I have are 4xDVD speed, so ~36xCD
<lamont> ah, cool
* lamont has a supply of dvd+r media, but sadly many of the machines in the house really like CD-RW or CD-R...
<mdz> the media is a bit more expensive (I think these were ~$2 apiece in packs of 10)
<mdz> but it seems to have a much lower failure rate than CD-RW, so it's at least a wash, and probably cheaper overall
<lamont> yeah
<lamont> don't ask why I have ~75 of the 4X dvd+r disks
<lamont> (they were on sale, you see...)
<zul> hah cheapies you get what you pay for
<lamont> memorex
<lamont> work pretty well..
<lamont> on sale == ~$40/25
<zul> not bad
<lamont> instead of $55 or so
* lamont has a stack of 4-6X CD-R media that he's going to burn hoary-live CD's on.
<lamont> note: debuging postinst scripts in packages that are part of base is a royal pita
<mvo> mdz: it's fetching some packages from the net, should it do that?
* lamont does a server install
<mvo> mostly german locale stuff it seems
<mdz> mvo: not during the main aptitude run, but for the language support, yes
<mvo> yes, for language support, 23,7Mb
<mdz> yes, this is a problem we must reconcile for final
<mdz> well, if it turns out to be a problem
<mdz> it's definitely too much for dialup users, but dialup users aren't online yet
<mvo> ok
<lamont> is that just because the CD has older bits, or is it pacakges that are just missing from the CD?
<mvo> I think I'm getting close, looks pretty good so far
<mdz> lamont: it's beacuse they're missing
<mdz> and they're missing because they don't fit
<lamont> ah, OK./
<lamont> ppc building on all 3 buildd's, for better chances of success
<elmo> lamont: eh - are the SIGILLs getting worse or are you just being melodramatic?
<mvo> does it install all the english support too? even if I selected german? I got myspell-en-us and openoffice-*-en-gb and stuff
<lamont> elmo: -25.1 died with a sigill, so I launched it everywhere (build/REDO is your friend...)
<lamont> of course, the ones that didn't actually _take_ it will fail to upload, but if the one that got it fails, then there are 2 more chances of success, with only minor evil on the other end
<lamont> elmo: and given the impending deadline, I don't want to wait for a SIGILL to start it again...
<lamont> damn thing takes too long to build as it is..
<mvo> should it try to load network docbook dtds from oasis-open.org?
<dholbach> hope you all find some sleep soon
<dholbach> i'm off to bed now
<mvo> (in register documentation)?
<lamont> sigh.
<lamont> mvo: we at least got it to quit loading from there during _BUILDS_
<mvo> and my default theme seems to be human
<mvo> but now I'm really really tired :) I need some sleep
* ogra too...
<ogra> night
<mvo> lamont, mdz: should I report bugs about "trying to fetch external dtds in register documentation and default theme is still human" ? 
<lamont> does the server install load anything more than ubunut-base?
<lamont> mvo: certainly
<jdub> mvo: yes tothe first one
<jdub> mvo: what's with the second?
<mvo> jdub: after a fresh install my theme was human
<jdub> that's correct
<mvo> jdub: ah, ok. good then :)
<lamont> mvo: I got the splash screen after an upgrade..
<mvo> lamont: splash screen?
<lamont> background
<mvo> I got that too on the install 
<mvo> ok, going to sleep now
<mvo> bye
<zenwhen> good luck and good night guys. 
<tseng> mako: great, thanks
<zul> hmm...there is ata_dma_blacklist now
<lamont> zul: where?
<tseng> hi zul 
<zul> its in 2.6.11 http://lkml.org/lkml/2005/2/6/8
<zul> hey tseng 
<lamont> so what exactly happens in the 'Configuring apt' step?
<jbailey> mdz: There?
<Benoni> What's the difference between "normal" and "udeb" packages?
<jdub> udeb packages are microdebs
<jbailey> Benoni: udeb packages don't have to follow the usual packaging policy - they're intentionally designed for use in the installer.
<jdub> they're very tiny, generally only used in the installer
<jbailey> So they're usually smaller, have no docs, etc...
<Benoni> OK, got it.  Thanks guys.
<zul> im thinking of heading to bed...night all
<jbailey> zul: g'night chuck.
<zul> night jbailey 
<wasabi> hah i just found something crazy
<wasabi> The process to migrate packages from Debian to Ubuntu, alters the control file, no?
<wasabi> To stuff them in universe/ or multiverse/ right?
<wasabi> Or is that done with an override or something?
<wasabi> Hmm, actually this is very odd. =/
<elmo> wasabi: no that's overridden centrally
<wasabi> (working with subversion, which regenerates debian/control at build time)
<elmo> automated syncs maintain the Section: entry from the original debian/control
<wasabi> Okay.
<wasabi> does it recompile the package on Ubuntu's buildds?
<wasabi> Or just copy over the .debs?
<elmo> former
<elmo> we only ever do source uploads
<wasabi> Well that makes little sense.
<elmo> it makes a heck of a lot of sense
<wasabi> Oh I see. Grr.
<wasabi> Naw, this Subversion package is giving me fits.
<wasabi> Because of it's regeneration of control.
<wasabi> It creates Build-Deps... at build time.
<mdz> jbailey: yes
<jbailey> mdz: See #u-kernel...
<mdz> oh no :-/
<elmo> argh more #*u* channels
<wasabi> elmo, how often are they updated?
<elmo> wasabi: which updated?
<mdz> jbailey: so in fact we have no indication of a regression in 1440
<wasabi> Oh I think I get it. This subversion package was probably uploaded directly to main.
<wasabi> So it just needs an update
<wasabi> nobody put -ubuntu at the end of the version, so it's confusing the hell out of me.
<elmo> subversion | 1.1.1-2ubuntu3 |         hoary | source, amd64, i386, ia64, powerpc, sparc
<elmo> err, that?
<wasabi> Yeah. It's 1.1.3 in Debian now.
<wasabi> Wait.
<wasabi> I am disoriented. =(
<jbailey> mdz: Right.  I have scd0/sr0 on that system.
<wasabi> elmo, forget everything I said. I am confused. =)
<jbailey> mdz: The two SATA systems have a null modem cable between them, I log in to both when I'm doing kernel upgrades so I can watch the serial console.
<mdz> jbailey: it's too late now; we'll have to live with 1440 for preview
* lamont primes the mirror on his to-be co-lo'ed machine
<mdz> lamont: how are the 25.2 builds going?
<jbailey> mdz: Ah, did you revert to -24?
<mdz> jbailey: no, we reverted the remainder of the patch from #1440
<elmo> i386 just finished
<jbailey> Ah shit, sorry about that.  *sigh*
<mdz> I was unable to get any confirmation from anyone else with an SATA system regarding 1440
<mdz> so all we had to go on was your example
<elmo> amd64 is installed
<jbailey> I'm surprised at how rare of a configuration it is.
<mdz> piix doesn't seem to be as popular as it once was
<lamont> elmo: and uploaded
<elmo> yeah, I haven't seen any since I left my old job - but there, I had nothing but PIIX
<mdz> so another ~2 hours for powerpc
<lamont> adare is 4/6+ done
<mdz> lamont: will you kick off the d-i builds as the kernels are installed?
<lamont> sure
<lamont> amd64 d-i launched
<m_tthew> eta for testable builds is ~2h (right now is 2008 UTC-8)
<m_tthew> ?\
<mdz> ETA for testable i386 CDs is <1 hour
* m_tthew nods
<m_tthew> good timing
* lamont waits for cron.daily to give i386 some lvoe
<elmo> you should be good, judging by the lights on jackass
<lamont> nope. i386 didn't make the last cron.daily run...
<lamont> and is still waiting
<lamont> di running on i386
<lamont> thanks elmo
* lamont discovers the ssl-cert package
<lamont> kewlness
<schweeb> lamont: whoa neat
<lamont> postfix-tls's cert just got much easer. :-)
<schweeb> wonder if that's what courier-imap uses to create its cert
<Benoni> I have a tricky packaging question for you folks.
<Benoni> I have a non-standard build process that generates some extra debug-related information.
<Benoni> On Fedora, there's a convention that filenames in debug info should be rewritten to look for source under "/usr/src/debug/package-x.y.z" instead of wherever your source tree really was a build time.
<Benoni> Does Ubuntu have a similar convention?  Should I be rewriting source paths in some similar way?
<jbailey> Benoni: No, gdb can generally handle whatever you give it, and has search statements otherwise.
<Benoni> jbailey: OK, so wherever the build tree happened to be on the buildd box, that's what ships out in the debug information?
<jbailey> Benoni: Yeah.  In practice I don't think I've ever even noticed it though.  Usually if I have a source tree handy I've always just told gdb where to find the info.
<Benoni> OK, cool.  Well, it's easy enough to just disable this extra rewrite functonality in my tools.
<Benoni> Thanks for the info.
* Benoni tips his hat to jbailey.
<jdub> yo Benoni 
<jdub> was off getting lunch, glad you got help here :)
<Benoni> Hey, jdub.
<jbailey> jdub: He had to settle for the other Jeff. ;)
<jdub> heh
<Benoni> jbailey gets a gold star for helping strangers with weird questions.
<Benoni> Or weirdos with strange questions.
<elmo> lamont: ?
<elmo> no i386 d-i yet?
* lamont beats on w-b a little. sigh
<lamont> uploaded now
<lamont> with seconds to spare - thanks
<lamont> when cron.daily runs on top of a d-i daily build, sick things happen
<elmo> dude seconds to spare suck when it's byhand :p
<lamont> doh.
<lamont> OTOH, adare as 5/6 kernels built
<fabbione> morning
<lamont> morning fabbione
<fabbione> i can see that it wasn't enough the PATA
<lamont> mdz?
<fabbione> what was the problem with ATAPI?
<lamont> elmo: I assume the byhand is done for i386?
<elmo> yes
<lamont> fabbione: so -25.1 was, um, worse
<lamont> so -25.2 is the new plan.
<lamont> == 25.1 with the rest of the patch gone
<lamont> mdz: amd64/ia64 can build images if you're so inclined...
<fabbione> worste in what sense?
<lamont> mdz: and you'll want new livecd rootfs'es as well, I assume
<lamont> problem still existed for at least jbailey's machine (WTH??), and etc, etc,
<lamont> see scrollback
<lamont> this channel, for the most part
<fabbione> i don't keep irc scrollback.. sorry
<fabbione> but ok
<fabbione> i will dig the logs later
<lamont> around 2600 UTC :)
<fabbione> so we get 1440 back
<lamont> basically, < -25 was known b0rkage (see #1440).  -25 had big issues, -25.1 didn't seem to fix #1440, but was yet another set of new and therefore scary code if it didn't fix #1440, so we decided to codify the regression on #1440
<lamont> declared to be "not a preview-stopper, but is a release-showstopper:"
<lamont> well, release critical anyway
<fabbione> make sense
<fabbione> is it already in cd images?
<lamont> built on i386,amd64; building on ppc
<lamont> d-i upload in the archive for i386,amd64.
<lamont> mdz is go for CD build
<fabbione> roger that
<lamont> but ENOMDZ recently....
<lamont> ppc is building the .o's for kernel #6/6 - then come the modules, of course.
<fabbione> yeah
<fabbione> we should hardcode the buildd names or something in debian/rules to enable CONCURRENT_JOBS
<fabbione> so it can fork on the buildd
<fabbione> or check for /CurrentlyBuilding
<fabbione> and take appropriate actions
<fabbione> that would speed up hell of a lot
<fabbione> lamont: did you merge 25.2 in baz?
<fabbione> i guess not
<lamont> not yet.
<lamont> it's on my list
<lamont> total difference is to drop enable_....-2 from 00list-25.2
<fabbione> ok if you don't get around it before you crash, i will do it immediatly after preview
<fabbione> i need to sync at least pre26
<lamont> and btw, please change your umask to 002 on rookery
<lamont> (thom covered for you...)
<fabbione> ah right
* fabbione does
<lamont> mainline has 25.1, wasn't sure what the state of --pre26 was, and if you had done that merge or not.
<fabbione> no i didn't
<fabbione> i did commit only the bits i had local
<lamont> ok.  if you don't beat me to it, I'll do the merge once I wake up again
<fabbione> done
<fabbione> no.. done nothing
<fabbione> that was supposed to go in daily report :-)
<fabbione> mdz: WAKE UP MY LITTLE TINY BOLD FRIEND!
<lamont> heh
<jdub> fabbione: bold is certainly true, but i think you might mean bald? :)
<fabbione> isn't bold = without any hair on the head?
<jdub> that's bald
<fabbione> that is actually what i am becoming.. but naturally
<jdub> bold is like courageous
<fabbione> ah ok
<jdub> both are correct ;)
<fabbione> than i meant BALD!
<fabbione> mdz: WAKE UP MY LITTLE TINY BOLD AND BALD FRIEND!
<m_tthew> baldness increases the bandwidth of the brain
<m_tthew> :)
<fabbione> doko: i can confirm that gcc-4 requires cairo 0.3.0-1 to build
<fabbione> doko: at least to pass the point where it was failing 2 days ago
<fabbione> so it might be a good idea to bump the build-dep
<fabbione> but please don't upload just for it :-)
<lamont> looks like maybe a ppc kernel in about 30 minutes
<lamont> yeah, just in time to miss cron.daily. :-(
<fabbione> humpf
<fabbione> i will start merging 25.1 and 25.2 in pre26
<fabbione> so i can keep going
<lamont> cool
<fabbione> or do you prefer to do it in another way?
<fabbione> like branching 25.1 and let baz handling the merge?
<lamont> 25.1 is already on mainline (and kernel-debian--mainline-2,6,10-25--0--patch-1)
<lamont> if you just check the 25.2 diff in on mainline, and then merge from mainline to --pre26, you'll be there
<fabbione> i will need to figure how to do that :-)
<lamont> of course, when you check -25.2 into mainline, you want to branch  kernel-debian--mainline-2,6,10-25,2--0 as well
<lamont> simple.
<lamont> start with a checkout of kernel-debian--mainline--2.6.10
<lamont> apply the chagnges for -25.2
<lamont> baz commit
<lamont> baz branch  kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10 kernel-team@ubuntu.com--2005/kernel-debian--mainline-2,6,10-25,1--0
<fabbione> ok
* fabbione does
<lamont> baz switch kernel-team@ubuntu.com--2005/kernel-debian--pre26--2.6.10
<lamont> baz merge kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10
<lamont> clean up debian/changelog from the merge, and commit
<lamont> well, with a baz resolved --all in the middle of that last line...
<mdz> fabbione: morning
<mdz> on which architectures are we ready for CD builds?
<fabbione> hey mdz
<lamont> i386, amd64
<lamont> ppc needs about another 30 min  or so
* lamont crosses digits
<fabbione> ppc is teh sux :)
<zwol> speaking of CDs, a question
<zwol> the CD has emacs on it
<zwol> the CD has lots of cool python stuff on it
<mdz> I had a short nap so I can stay up for a bit
<zwol> why does the CD not have the emacs mode for editing python on it?
<mdz> i386 and amd64 CDs building
<fabbione> cool
<fabbione> i386 would be fine for testing
<mdz> zwol: it does, "the" emacs mode for python comes with emacs
<fabbione> since it was the one really affected by the problem
<zwol> mdz: uh, no it doesn't.  you have to install the python-mode package, which is in main but not on the CD.
<zwol> (let me be specific: I am referring to emacs21, not xemacs.
<zwol> )
<elmo> we only support emacs21 anyways
<fabbione> morning elmo
<zwol> yeah, i didn't remember seeing xemacs on the cd
<elmo> but zwol's right - we should probably promote it to ship, it's only like 46k
<elmo> (it == python-mode)
<elmo> fabbione: meh
* fabbione hugs elmo
<fabbione> elmo: was it good to sleep on the DC floor ?
<zwol> elmo: i'd be much obliged.  editing python in emacs without the major mode for it is all kinds of no fun.
<elmo> fabbione: they're a classy DC, they have sofas and stuff
<fabbione> elmo: ah...
<mdz> emacs is only on the CD because it's relatively large
<fabbione> that rocks
<mdz> as a convenience so you don't have to download it
<elmo> zwol: sorry, I was just agreeing with you - that doesn't mean it'll actually happen ;)
<mdz> Kamion made some magic to allow install CD builds without jigdo, but I haven't investigated that yet
<lamont> module build
* lamont finds himself staring at some debug output, needing to understand when newaliases would exit with no output, and not create /etc/aliases.db
<zwol> i don't personally care all that much since i have no plans to install ubuntu again in the near future, but i do think it would be nice.
<mdz> zwol: did you install on a machine which is not connected to the Internet?
<zwol> mdz: yes, i installed on a laptop while sitting in a cafe, far away from all sources of connectivity.
<zwol> it was only a problem till I got home, but i did tear my hair out for a little while.
<Treenaks> lamont: wrong map type?
<zwol> i'm mainly suggesting it because it seems consistent with the general policy of putting lots of python goodness on the CD.
<mdz> the python goodness on the CD is there because it's installed by default
<lamont> Treenaks: very last thing in the postinst.  during debootsrap
<mdz> we might be able to squeeze python-mode because it's tiny, but then again, it's also possible that emacs will get pushed off the CD in favour of more language support
<schweeb> lamont: hrm, have you tried postalias directly?
<lamont> schweeb: shouldn't matter
<schweeb> yea, wouldn't think so
<mdz> ARGH it's building source CDs
* lamont will launch a shell from postinst.  :-)
<elmo> mdz: eww
<elmo> oh dear god
<elmo> (system) cron.daily time is a REALLY bad time to be in the data centre on little sleep
<elmo> I have 300 hard drive lights flashing at me manically - I feel like I'm having a semi-permanent fit or something
<lamont> elmo: lol
* m_tthew laughs
<srbaker> how do i turn off screen locking when i close my laptop lid
<lifeless> elmo: lol - want to /become/ epileptic ?
<zwol> edit /etc/acpi/lid.sh?
<schweeb> srbaker: /etc/default/acpi-support
<schweeb> i believe
<srbaker> thanks
<srbaker> lid.sh is what she was looking for
<mdz> i386 and amd64 install CDs are ready
<mdz> fabbione: ^^
<fabbione> ok
<fabbione> i can test only i386
<fabbione> client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
<fabbione> ok rsyncing now
<mdz> well, they're built and syncing to the mirrors
<fabbione> it was still copying to archive i guess
<mdz> could be a short time before they're available
<fabbione> fetching now
<mdz> lamont: did ppc miss cron.daily?
<lamont> Mar 10 06:44:43 buildd-mail: Moved linux-source-2.6.10_2.6.10-25.2 to upload-hoary
<lamont> Mar 10 06:45:31 buildd-uploader: 1 jobs to upload in upload-hoary: linux-source-2.6.10_2.6.10-25.2_powerpc.changes
<lamont> Mar 10 06:45:40 buildd-uploader: dupload successful.
<lamont> sorry - I was 45 seconds slow there.
<lamont> it's waiting for the _NEXT_ cron.daily
<fabbione> mdz: burning now
<fabbione> it will take a little while
<mdz> ok
<mdz> pitti should be here soon to build new langpacks
<mdz> but we don't actually need those in order to release preview
<fabbione> aren't they borked?
<m_tthew> i386 install burning
<mdz> fabbione: they're borked for upgrades, not for new installs
<fabbione> ah ok
<pitti> Hi folks
<pitti> Mr. Langpack breaker greets you
<pitti> mdz: still here?
<mdz> pitti: yes
<mdz> pitti: hello my langpack breaking friend
<pitti> mdz: mvo phoned me
<mdz> pitti: I sent you email also
<pitti> mdz: sorry, was offline yesterday night
<Mithrandir> elmo: pong
<lamont> pitti: btw, null component name in /CurrentlyBuilding is fatal.
<pitti> mdz: I almost feared that we must ship an empty update package :-(
<pitti> mdz: that means we can't ship update packages until this dpkg bug is solved?
<mdz> pitti: correct, see #7401
<pitti> ah, imported to our bz now..
<daniels> mdz: ok, thanks
<mdz> elmo: you took care of the powerpc d-i upload already?
<daniels> svenl: yes, but how do you detect a pegasos, exactly?  note that I'm still very, very uncomfortable with this hack.
<pitti> mdz: but why a versioned pre-depends wouldn't work?
<pitti> lamont: what do you mean my fatal? does it cause FTBFS?
<mdz> pitti: oh, I think it might, now that you changed the package layout
<pitti> mdz: oh, no, now I see why it doesn't work
<mdz> pitti: I was thinking it would be impossible because you would need to update the existing package to increment the version, which would defeat the point
<mdz> oh, right, still won't work
<pitti> right, the error msg was about updating the -base package while an older -update package is still installed
<lamont> pitti: yes
<lamont> mdz: d-i build launched on ross
<lamont> mdz: you want livecd rootfses yes?
<Benoni> Where would I find a list of section names suitable for use in the "Section:" field of "debian/control" files?
<pitti> lamont: this is actually a feature, you enabled it with invalid_currentlybuilding = fail
<lamont> no. that's not in the file
<pitti> ?
<pitti>     readctrl "/CurrentlyBuilding" "Component"
<pitti>     if [ -z "$RET" ] ; then
<pitti>         echo "pkgstriptranslations: inconsistent /CurrentlyBuilding file, Component: value is empty" >&2
<pitti>         [ "$ignore_invalid_cb" ]  || exit 1
<pitti>     fi
<lamont> grep invalid build-hoary/chroot-hoary/etc/pkgstriptranslations.conf
<lamont> buildd@adare:~ $ 
<mdz> lamont: yes, please
<pitti> lamont: oh sorry, the default is "fail", not "ignore". my bad
<mdz> pitti: so since this problem does not affect new installs, it might be better to wait until we have built the final preview images
<pitti> lamont: does it actually do any harm?
<lamont> pkgstriptranslations: inconsistent /CurrentlyBuilding file, Component: value is empty
<lamont> dh_builddeb: command returned error code 256
<lamont> that'd be harm.
<pitti> mdz: you mean, build new langpacks after the preview?
<mdz> pitti: yes
<pitti> mdz: this would still leave some upgraders from array affected
<pitti> however, interesting that this was never reported so far
<mdz> pitti: yes, but they have been affected for some time already, a few hours shouldn't make much difference
<pitti> we had several langpack updates in the past
<mdz> it is pure luck which package is unpacked first
<pitti> mdz: okay, fine
<pitti> lamont: why would it be harm? is the Component field empty on purpose sometimes?
<lamont> if I stop the buildd and restart it, sbuild looses that information
<pitti> ah
<lamont> which is how I discovered that it's fatal...
<fabbione> lamont: that's an error in buildd
<fabbione> i figured that buildd doesn't update the Component when you stop/start
<lamont> fabbione: no, it's a design error in how we implemented the pkg striptranslations
<pitti> lamont: okay, so what do you prefer? changing the logic not to fail (i. e. invalidcurrentlybuilding defaults to "ignore")
<lamont> fabbione: buildd isn't even _INVOLVED_ when you stop/start
<pitti> lamont: or changing the conffile to explicitly set it to ignore?
<lamont> pitti: don't worry about it
<fabbione> lamont: well the part of sbuild of whatever that is supposed to write the Component: leaves it blank if you stop/start
<lamont> right.  because it doesn't record that information in build/REDO when it stops, so it can't recover it
<lamont> and I'm not going to worry about it tonight - about to fall over
<fabbione> lamont: good night
<pitti> mdz: reagarding the -home / issue, shall I fix it for preview or after?
<pitti> lamont: night
<mdz> pitti: after
<fabbione> bah
<fabbione> bad burn
<lamont> oh, I don't get to fall over yet, I'm just ready to
<mdz> pitti: well...
<mdz> pitti: how fast can you have packages ready?
<pitti> mdz: hoary's adduser does not do this anyway...
<mdz> pitti: ok, definitely wait then
<pitti> mdz: building and uploading them takes 10 minutes
<pitti> mdz: I'm more concerned about _which_ directory they should actually get
<pitti> mdz: /var/cache/scratchdir ...
<pitti> mdz: chown'ing /tmp or any other normal directory would be bad, too
<mdz> pitti: I think the adduser defaults are fine
<pitti> mdz: on the box you experienced this, did it happen to be a woody upgrade or so?
<pitti> mdz: the warty version does not chown either
<mdz> pitti: no, it was a debootstrapped warty, I believe
<pitti> hmm, odd
<mdz> can everyone here check the ownership of the root directory on their Ubuntu systems and see if it's hosed?
<pitti> mdz: already checked my systems, all are ok
<fabbione> mdz: ???
<pitti> ls -ld /
<mdz> fabbione: there is a potential problem with hpoj and cupsys where the ownership of / is changed
<mdz> pitti: bug#?
<pitti> https://bugzilla.ubuntulinux.org/show_bug.cgi?id=7365
<fabbione> drwxr-xr-x  25 root root 1024 2005-03-10 08:24 /
<pitti> mdz: sudo adduser --system --ingroup lpadmin foobar
<pitti> mdz: -> then I get /home/foobar created
<pitti> mdz: I really need --no-create-home 
<mdz> pitti: oh, interesting
<mdz> --no-create-home without --home seems fine
<pitti> yes
<mdz> looking at /etc/passwd, that seems to be what syslog, ntp, etc. do
<pitti> mdz: then the home will still be /home/foobar, but it cannot chown it because it doesn' exist
<pitti> nice hack :-)
<pitti> mdz: okay, your call, can upload any time
<mdz> pitti: after preview
<mdz> since it seems that very few people actually experience the bug
<mdz> and we will need to have postinst fix the root directory anyway
<pitti>         if dpkg --compare-versions "$2" lt-nl "1.1.23-1ubuntu10"; then
<pitti>             chown 0:0 /
<pitti>         fi
* lamont had a / owned by hpoj
<lamont> drwxr-xr-x  25 hpojlp lp 4096 2005-03-05 09:12 /
<lamont> pitti: and while you're in hpoj... has it's init.d been lsb-ized yet?
<pitti> lamont: no yet, can do this if I'm at it
<lamont> that'd make one less upload for me, fixing them.
<mdz> hmm
<mdz> has the powerpc upload arrived too late for elmo?
<mdz> it looks like we may have lost him
<mdz> fabbione: how is the test going?
<fabbione> mdz: i am having some problems to burn the CD
<fabbione> either these medias are the suck
<fabbione> or my dvd burner just died
<mdz> powerpc byhanded
<m_tthew> the i386 install here is in aptitude, grinding away at the HD
<fabbione> it seems a frigging problem with linux...
<lamont> mdz: you tried burning slowly?
<fabbione> bah
<fabbione> lamont: i can't go slower than x2
<fabbione> it doesn't even blank the disk now
<fabbione> at least not under linux
<lamont> heh
<lamont> i386 cloop done
<lamont> (and kubuntu building there)
<mdz> m_tthew: 06c9fb5aa557a916c4e91cc8f18cbae8  hoary-install-i386.iso ?
<m_tthew> pretty sure, lemme dbl-check
<m_tthew> 06c9fb5aa557a916c4e91cc8f18cbae8  hoary-install-i386.iso
<lamont> amd64 compressing
<lamont> don't even ask about ppc
* m_tthew asks about ppc
<m_tthew> :)
<pitti> lamont: erm, hpoj's init script is perl, hard to use /lib/lsb/init-functions..
<lamont> oh, lovely
* mdz gags
<lamont> use /lib/lsb/init-functions.pl :-)
* T-None sends lamont to bed :)
<pitti> oh, cool
<lamont> pitti: I don't think it exists
<pitti> ENOENT
<Mithrandir> you might need to _write_ /lib/lsb/init-functions.pl first, though
<lamont> so you'll need to write it. :-)
* Mithrandir ^5s lamont 
* lamont ^5s Mithrandir 
<pitti> *sigh*
<daniels> perl?!?
<T-None> gack
<pitti> it's not a standard init script, it's a huuge program that includes installer, configurator, and a coffe machine
<Mithrandir> daniels: it's such a evil init script, I'm not sure you want to rewrite it in shell, iirc.
<mdz> yeah, it's this crazy script that upstream ships
<mdz> and it's used as the init script
<lamont> perl: for when you're all out of syrup of ipecac
<Mithrandir> pitti: you forgot the space shuttle launchpad.
<mdz> probably it should be moved into /usr/sbin and wrapped by a real init script
<pitti> oh, right
<lamont> see - mdz _is_ a party pooper. :-)
<T-None> you guys are sick in your heads ;)
<lamont> T-None: see, I _told_ you it's a fun group
<mdz> has anyone else noticed that ubuntu in a mirror is "utnudu"?
<T-None> lamont: hehe ;)
<mdz> or only those of us who are lacking sleep?
<lamont> mdz: lol
<pitti> mdz: this sounds even less comprehensible 
<mdz> I like words which are perfectly formed in the mirror, and our logo font has that property
<T-None> Mithrandir: i'm letting the box up for whenever you can use it, btw :)
<pitti> mdz: the "t" is wrong, though :-)
<lamont> ah, I see that elmo did grab ubunut.com
<mdz> only a bit
<mdz> it is stylized :-)
<Mithrandir> T-None: thanks.
<lamont> amd64 is done
<lamont> ppc should _start_ in about 5-10 minutes
<T-None> lamont: btw, do you *ever* sleep? :)
<lamont> T-None: on occasion
* T-None thinks lamont is some kind of alien that doesn't need to sleep :)
<Mithrandir> T-None: shhh!  Don't make him feel unwelcome.
<T-None> lol
<dilinger> pitti: hey, i don't suppose you know anything about http://linux.bkbits.net:8080/linux-2.6/cset@41fbf0fcleNsr1YP92sb8eg7m1w90A  ?
<amu> moin
<pitti> Hi amu
* T-None is already quite late, runs away to work, bbi ~10h
<pitti> dilinger: no, indeed not. Do you? :-)
<pitti> dilinger: security relevant?
<dilinger> no, i just noticed it.  not sure if it depends on 41fbef32tPWgju_Vydfojr8LR1ZnEQ, and whether it's something that a user could ever trigger
<pitti> http://www.linuxense.com/challenge/
<pitti> fabbione: ^ do you think we have 'nuff exploits to try? :-)
<daniels> jdub: dbus 0.23.3 (.3 just fixes a few horrific memory leaks in the mono stuff, really) for hoary.  i'd like to do it.
<fabbione> pitti: ehhehe probably we do :-)
<amu> hey pitti, i found libboost, remember we're looking for it, a while ago   
<mdz> waiting for d-i stuff to sync up, then I'm going to build a full set of images
<fabbione> pitti: too bad the context is now
<fabbione> pitti: we have not enough time to work on it
<mdz> with jigdo and all
<mdz> which should hopefully be a real candidate
<pitti> fabbione: no, just found the announcement on full-disclosure
<mdz> lamont: ETA for livefs builds x3?
<fabbione> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<fabbione> BAH
* mdz workraves
<fabbione> how do i fix that crap???
<pitti> fabbione: you need to fix the ++revision-lock/+contents dir in the latest patch
<lamont> 2 done.
<lamont> ppc will be starting soon
<fabbione> pitti: how and where?
<pitti> fabbione: and remove any ++revision-lock-held-foo crap in the directory which holds all the patches
<pitti> fabbione: which is the latest committed patch?
<fabbione> 7 probably
* fabbione starts to time wasted in fixing baz
<pitti> fabbione: then go into .../patch-7/
<lamont> mdz: I was afraid to kill the one that launched at 0615 until it finished.
<lamont> ppc has started.
<pitti> fabbione: is the repo on a server I have access to?
<fabbione> rookery
<lamont> and now that cron.daily and a kernel build aren't competing with the livecdfs build, it should finish in much < 2 hours... :=(
<fabbione> lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre26--2.6.10
<pitti> fabbione: you need to rm -r ++revision-lock-held--patch-7--fabbione@canonical.com--429de7a23f250
<pitti> fabbione: and mkdir -p patch-7/++revision-lock/+contents
<fabbione> THIS IS THE SUX
<pitti> fabbione: did you happen to abort a commit?
<fabbione> pitti: yes
<fabbione> it is still the sucks
<pitti> fabbione: okay, seems to have worked
<fabbione> yes
<pitti> fabbione: beat up the baz guys... :-)
<lamont> baz lock-revison -b <version-spec>
<fabbione> oh i will
<lamont> don't remove files in the archive
<pitti> lamont: this command almost never works for me...
<lamont> works for me
* pitti always tried and had to fix it manually in the end
<lamont> fabbione: fwiw, those were left over in mainline as well, and those were the files that I had to have thom fix for me.
<lamont> you aren't doing something stupid like killing commits in the middle of the log edit are you?
<fabbione> lamont: i did kill the commit at gpg sign
<fabbione> i never edit the commit log. i always use -s'
<lamont> yeah - that case is the trivial lock-revision -b will fix it case.
<fabbione> it just shouldn't happen
<lamont> ok.  well, that'd be a #arch thing
<fabbione> yes i know
<lamont> mdz: ppc is in debootstrap...
<lamont> once http://adare.buildd/~buildd/livecd/ubuntu/latest/livecd.ubuntu.manifest exists, the image is golden
<lamont> hrm.. guess I should stay up until it's done.
* lamont decides that since he's pretty useless for most stuff anyway, maybe now is a good time to kill a little bit attacking level 234
<m_tthew> i386 install successful and smooth like butter
<m_tthew> some sort of space jellyfish graces the desktop
<fabbione> i am afraid my dvd burner is dead
* fabbione sighs
<svenl> daniels: if you are uncofortable with the hack, then port the real solution from the debian X radeon driver.
<svenl> daniels: and the pegasos detection i told you how to do it in the bug report.
<svenl> daniels: you only need to look for "machine         : CHRP Pegasos" in /proc/cpuinfo.
<svenl> daniels: if [ "`grep 'machine.*CHRP Pegasos' /proc/cpuinfo`" ] ; then echo PEGASOS; else echo not pegasos; fi
<svenl> daniels: or a variation thereof.
<svenl> daniels: damn, www.ubuntu.org seems unreachable, too bad bugzilla has not propper email bug-reporting enabled.
<mdz> new install CDs are up, x3
<mdz> hmm, not yet
<svenl> daniels: just get the bustype hack in, and i will get you the xresprobe fix. yours is the less work, and probably a 5 minutes fix.
<mdz> silly source CDs
<mdz> m_tthew: thanks
<m_tthew> np, I'll give the new build a spin too, soon as it's there to rsync
<lamont> ppc is in lang-pack/locale
<mdz> I think we might need to do one after this, unfortunately
<mdz> if we want proper volume labels
<mdz> I'll check with Kamion when he gets up
<mdz> svenl: www.ubuntu.org is not our website
<svenl> yeah, i meant .com, but i guess it was just the firewall here playing tricks.
<svenl> mdz: still having no email interface to the BTS sucks bigtime, which is my main grip against bugzilla.
<mdz> svenl: we aren't going to put much more work into making bugzilla better, since we'll be moving to malone
<hiweed> hey all
<mdz> for which a proper email interface is planned
<svenl> BTW, you have a gparted package, right, but gparted is not in debian yet, and the package is a different one from the gparted package in debian svn repo ?
<svenl> mdz: ah, cool.
<hiweed> where can I get the Ubuntu's Debian-Installer source codes? it has some bugs and I wanna fix them.
<Treenaks> hiweed: apt-get source debian-installer ?
<mdz> hiweed: all the source code is in the package archive; we don't have a revision control repository for it
<mdz> (yet)
<hiweed> Treenaks: thanks. is there any svn or cvs?
<hiweed> mdz: okay thanks
<mdz> hiweed: you can send patches to ubuntu-devel@lists.ubuntu.com
<hiweed> okay
<lamont> scrollkeeper
<fabbione> whos is an awk expert?
* lamont is no expert, but has been known  to do a thing from time to time...
<lamont> elmo maintains gawk...
<lamont> or was that mawk.
<fabbione> lamont: debian/make-substvars 
<mdz> fabbione: don't ask to ask ;-)
<fabbione> lamont: we need find a way to replace that thingy
<mdz> this is insane, the CD build process spends like 10 minutes making CDs, and 40 minutes making .jigdo files
<mdz> which no one uses
<fabbione> i am afraid my burner is dead
<mdz> fabbione: bad timing :-(
<fabbione> mdz: i have another one...
<fabbione> it will just take time to change them
<lamont> fabbione: shouldn't be too bad.. what needs to change in it?  or does it just annoy you?
<fabbione> lamont: let's move to -kernel
<lamont> partimage.  woot
<low> hi there
<low> i've tested 20050309.1 a64 iso
<low> lilo and grub can't be installed but i suppose it's a known bug
<lamont> install fine here...
<mdz> lamont: ETA?
<low> having already a grub installed, i've tried to boot the thing anyway
<low> crashes at unable to mount VFS, unknown device...(using xfs)
<lamont> mdz: cp, compress, and done
<low> lamont, hmmm forgor to tell i use sata (sata_sis), is there an initrd or ?
<mdz> lamont: how long does that bit take usually?
<mdz> pitti: have you tried to reproduce #6749?
<mdz> new install ISOs are being md5summed
<lamont> mdz: haven't really paid _that_ much attention.
<lamont> it's running along at ~2MB/sec
<lamont> on 2GB ==> 10 minutes, give or take
<lamont> really ballpark figures
<mdz> ok, thanks
<fabbione> amen
<fabbione> it's the DVD burner
<fabbione> FUCK
<lamont> over 16K blocks done
<lamont> (and screaming along at much closer to 6MB/sec)
<lamont> 25K of 32K blocks compressed
<lamont> at the end there's a small amount more cp madness
<mdz> fortunately the live iso build is _way_ faster
<mdz> no source madness and no jigdo madness
<lamont> i386 wins the compression competition at 24% vs 25 and 25
<lamont> ubuntu livecd build is a GO
<mdz> building
<lamont> for future reference, runs about 1 hour on ppc, under good conditions
<lamont> and in about 1 hour.  fwiw, those builds did ubuntu and kubuntu, so you could build kubuntu-live (if you wait another hour for ppc-kubuntu to finish..)
<lamont> anything more before I go grab 4 hours sleep and then run the kids to school?
<lamont> T-None: see, I do sleep. :-)
* lamont will sync images on his way home from school
<mdz> Ubuntu 5.04 "Hoary Hedgehog" - Preview amd64 Binary-1 (20050310)
<mdz> oh yay, Kamion did the .disk/info magic already
* mdz hugs Kamion
<mdz> lamont: I think we're in reasonable shape, thanks
<m_tthew> is there one more build for volume labels still?
<mdz> m_tthew: nope
<lamont> mdz: g'night then
<m_tthew> yay
<mdz> sabdfl: morning
<pitti> Hi sabdfl 
<sabdfl> morning guys
<lamont> morning sabdfl 
* m_tthew waves
<lamont> night sabdfl 
<sabdfl> mdz: how's it looking?
<fabbione> morning sabdfl 
<mdz> sabdfl: install candidate is up, live candidate is building
<fabbione> burning now the install candidate
<sabdfl> mdz: canidate announced to -devel?
<mdz> sabdfl: not yet, live build will be done in a moment and I'll announce together
<sabdfl> cool
<sabdfl> then we have a good few hours testing before we announce
<mdz> thom: ping
<mdz> ok
<mdz> live and install are both up
<sabdfl> Kamion get a decent night's rest last night?
<mdz> sabdfl: haven't seen him for 9 hours, so I hope so
<fabbione> wow.. found the DVD burner recepits
<fabbione> and it is still underwarranty
* pitti can't rsync two images in parallel
<pitti> do we restrict the #rsyncs per IP?
<m_tthew> pitti : it seems that way to me, too
<mdz> pitti: yes
* m_tthew suddenly wishes his burner could rsync the media
<mdz> live-amd64: success
<dholbach> hi
<m_tthew> i386 install burning
<Keybuk> "he advisory notes that this vulnerability "...pretty much destroys what PaX has always stood and been trusted for." So the author is taking his marbles and going home; PaX will be discontinued at the end of this month."
* ..[topic/#ubuntu-devel:mdz] : 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 | preview release: 2005-03-10 1800UTC | please test the current daily (preview candidate)!
<pitti> Keybuk: I think it won't come that far
<Keybuk> pitti: funny though :p
<pitti> Keybuk: scary, rather
<Keybuk> why scary? all software has security flaws
<d3vic3> can someone explain #7403 to me 
<Keybuk> I find it more scary that people really believe that there aren't any in things like PaX, etc.
<mdz> d3vic3: we're working on the preview release right now; can you help by testing the candidate?
<Kamion> mdz: ok, what's the CD situation?
<d3vic3> mdz, yes, when will it be ready? 
<Kamion> hm, so we seem to have d-i builds throughout, good
* fabbione kicks his burning machine
<mdz> install-amd64 on stage 2
<mdz> Kamion: /topic
<fabbione> mdz: i should be able to test install in approx 15 minutes
<fabbione> i just finished to solve all the burning issues
<mdz> Kamion: we have a full set of isos which should represent a reasonabe preview candidate
<Kamion> mdz: what I mean is, you just did 'cron.daily' right?
<mdz> Kamion: and daily-live, yes
<Kamion> mdz: for future reference, to avoid source builds and jigdo, put SPECIAL=1 in the environment
<mdz> Kamion: and I griped a lot about how long it takes now
<Kamion> with elmo pronunciation
<mdz> Kamion: I fiigured out SPECIAL=1 earlier
<mdz> Kamion: but since this was to be a real candidate, I figured we should have the jigdos
<Kamion> yes, thom uses them at least
<mdz> I didn't realize it turned off source, too, or I might have done it anyway
<Kamion> and I've had a number of other users asking about them, so they are used :)
<fabbione> gnome is a FTBFS due to wrong Build-Dep.. *sighs*
<abelli> which burning, if one, is going to be "supported"?
<abelli> *app*
<fabbione> seb128 
<mdz> powerpc-live: success
<fabbione> i was thinking about you
<mdz> Kamion: I was just griping because they take so long
<fabbione> seb128: gnome is a FTBFS due to wrong Build-Dep.. *sighs*
<seb128> what gnome ?
<mdz> Kamion: down the road, I'd prefer to separate the ISO builds and jigdo into two phases, so we can add the jigdos later when we're happy with a build (or if we can do that already, learn me how ;-) )
<fabbione> seb128: libbonoboui_2.8.1-1ubuntu1: libgnome2-dev: Depends: libgnome2-0 (= 2.9.1-0ubuntu1) but it is not going to be installed
<fabbione> seb128: but 2.10 is in the archive
<fabbione> seb128: and after that a chain of other packages
<fabbione> seb128: for similar reasons
<seb128> $ apt-cache show libgnome2-dev
<seb128> Depends: libgnome2-0 (= 2.10.0-0ubuntu1), liborbit2-dev, libbonobo2-dev (>= 2.6.0), libgconf2-dev (>= 2.7.92), libgnomevfs2-dev (>= 2.7.91-3), libglib2.0-dev (>= 2.4.0), libesd0-dev
<seb128> 
<seb128> that's a out of sync any/all
<fabbione> seb128: i noticed it because sparc was catching up
<seb128> what arch is that ?
<fabbione> seb128: nope.. i have it in sync..
<fabbione> seb128: read above...
<fabbione> (= 2.9.1-0ubuntu1)
<seb128> libgnome2-dev: Depends: libgnome2-0 (= 2.9.1-0ubuntu1) 
<seb128> is not possible
<seb128> Package: libgnome2-dev
<seb128> Architecture: any
<seb128> Section: libdevel
<seb128> Depends: libgnome2-0 (= ${Source-Version}),
<seb128> 
<fabbione> in the archive they are in sync
<Kamion> mdz: the reason why we don't do that at the moment is because a successful jigdo run requires (or at least, may require) the exact same archive as was used for the ISO run
<seb128> what's wrong with that ?
<Kamion> mdz: building them at the same time has a much higher chance of actually working
<fabbione> seb128: weird
<seb128> it's like that for ages
<seb128> and works on debian and ubuntu for ages
<Kamion> mdz: believe me, it irritates me too, but the answer is not breaking it, the answer is shifting to JTE
<seb128> are you sure you are not lagging on libgnome on sparc ?
<mdz> install-powerpc: on stage 1
<fabbione> seb128: yup...
<Kamion> mdz: which pushes most of the jigdo-generation logic into mkisofs, where it can be much more efficient; you save enormous amounts of md5summing that way
<Kamion> Debian are using that now, because with 11 arches and a billion CDs they hit the problem much harder
<Kamion> for us it's just an annoyance, for Debian it was a showstopper
<fabbione> seb128: http://sparc.ubuntu.com/ubuntu-sparc/pool/main/libg/libgnome/
<seb128> fabbione: apt-cache show libgnome2-dev | grep Depends ?
<seb128> and apt-cache show libgnome2-dev | grep Version
<fabbione> sec
<mdz> install-amd64: success
<mdz> who else is testing?
<fabbione> seb128: it looks ok to me...
<fabbione> bah
<fabbione> i will figure that crap out later
<low> mdz, i've tried 20050309.1 and had some problems
<mdz> low: please try the current one
<seb128> fabbione: k
<pitti> mdz: still downloading, when we can download only one image at one time, this lasts a while
<low> mdz, ok
<mdz> pitti: why would it be faster if you could do more than one?
<low> mdz, 10.2 ?
<mdz> I have always done them in series
<mdz> low: /current/
* seb128 downloading too
<mdz> thom: torrents would be good
<mdz> Kamion: can we get a TORRENTS flag to generate them as part of the build process?
<pitti> mdz: rsync port is slow for me (about 40 kB/s)
<mdz> (the metafiles, that is)
<mdz> thom is going to work on automating the seeding
<pitti> mdz: but my overall bandwith is about 200 kb/s
<mdz> live-i386: success
<mdz> Kamion: (live-i386 tested via USB)
<seb128> pitti: lucky you, I've 60k here :p
<fabbione> install-i386 with piix seems ok (it passed the critical point)
<Kamion> mdz: torrents> maybe, need to rethink half of that anyway
* Kamion is rsyncing still
<mdz> Kamion: RESUME is set correctly for me so far
<Kamion> I certainly want to have a separate script that builds them
<Kamion> mdz: yeah, every RESUME test has been good for me so far, looks like that worked well
<mdz> the amd64 doesn't like to resume from swsusp, though
<Kamion> mine neither
<mdz> but I forgive it since it's a desktop
<thom> mdz: do we have final images in place?
<Kamion> thom: probably
<Kamion> here, how about I dump these images into releases.u.c/.pool/
<thom> yeah, that'd be good
* thom jigdos ppc and amd64 quickly
<Kamion> will take a while, it md5sums THE WORLD
<Kamion> and the scripts are kind of, er, half there for doing that kind of thing
<thom> heh
<Kamion> $ publish-release daily 20050310.2 install poolonly preview
<Kamion> [remove lots of shit] 
<Kamion> or words to that effect
<Kamion> and it's all going to have to change around post-preview anyway from what sabdfl said yesterday
<Kamion> but at least I have an idea how
<Kamion> thom: oh, I have half the code for a torrent rsync target too, I'm just too wussy to try to apply it pre-preview
<koke> oh, hell I was going to test the preview but I don't have CD-R's here :(
<thom> Kamion: heh, heh
<YokoZar> Ok, somehow I managed to upgrade to Hoary, select xorg as my default xserver, and NOT have xserver-xorg installed.
<YokoZar> There has to be a missing dependency somewhere
<pitti> elmo: can we please temporarily increase the rsync-per-IP limit ?
<Kamion> YokoZar: install ubuntu-desktop?
<Kamion> oh, heh, I don't notice any of this rsync limit stuff because I gave up ages ago and made my scripts do rsync-over-ssh - whoops
* Kamion pleads necessity
<pitti> Kamion: you mean ssh to cdimage.ubuntu.com?
<Kamion> to little, which is to cdimage.ubuntu.com as jackass is to archive.ubuntu.com
<Kamion> i.e. no, but close enough :)
<mdz> I've had to do that before
<mdz> though the rsync limits seem to be fairly reasonable now
<mdz> or they're being used less
<YokoZar> Hmm, how did that not get selected...
<YokoZar> It let me set the xserver as xserver-xorg-dbg
<YokoZar> Which should probably depend on xserver-xorg
<Kamion> heh, probably yeah
<mdz> daniels: any particular value in having xserver-xorg-dbg Provide: xserver-xorg, rather than just xserver?
<Kamion> gah, new kernels make CD images take forever to rsync
<mdz> install-powerpc: in scrollkeeper hell
<YokoZar> Hmm ubuntu-desktop won't install, giving me an error that mozilla-firefox-gnome-support depends on mozilla-firefox-1.0+dfsg.1-6ubuntu1 but 1.0-2ubuntu4-wart99 is to be installed
<mdz> Kamion: new kernels take forever to build, and forever to get onto the CDs, too
<mdz> YokoZar: backports are buggy
<mdz> their use is not recommended
<YokoZar> Yeah that is probably it
<Kamion> they're entirely unQAed by us
<YokoZar> But I removed the backport repository
<mdz> but you still have packages from it installed
* fabbione starts to get pissed at any CD/DVD media
<YokoZar> Hmm... I thought they would be named smarter
<YokoZar> Such that they would upgrade to hoary cleaner
<mdz> one would hope
<mdz> but it is not so
<YokoZar> The backport guy should make a metapackage that conflicts all the hoary backports so it upgrades cleaner
<YokoZar> Still, I did uncover a strange thing about xserver-xorg-dbg ;)
<Kamion> I don't think you can really hope for that given that the backports are broken to start with
<Kamion> they are generally not even versioned correctly
<mdz> Kamion: can you copy the .torrents into the daily dirs as well?
<mdz> Kamion: I posted those to ubuntu-devel asking for testing, before you published them as preview
<Kamion> mdz: yes, when publish-release is finished
<mdz> oh, it isn't finished?
<Kamion> I haven't actually published them really yet
<Kamion> just pushed them into .pool for mirroring
* thom hugs jigdo - with a local mirror, that's totally easy
<mdz> thom: I hope it's worth the 2 hours of my time it wasted overnight :-P
<mdz> not that i'm bitter
<thom> mdz: absolutely; two isos in 5 minutes
<Kamion> thom: ok, stuff syncing to releases.u.c/.pool/ now
<Kamion> mdz: did you generate .torrents, or do you mean that you want me to make some?
<Kamion> if so, where did you put them? :P
<mdz> Kamion: the latter
<Kamion> ok
<mdz> Kamion: I thought that I saw that you had created .torrents in releases/hoary/preview
<mdz> but I was cockeyed and what I saw were the warty/preview ones
<mdz> my eyes have lost their knack for focus this evening
<Kamion> releases/hoary/preview existed briefly, because the scripts are THAT GOOD
<Kamion> the procedure for doing .pool-only publishing is currently (a) run publish-release with poolonly as the fourth arg, (b) rm -rf releases/hoary/preview, (c) sync-mirrors
<mdz> I just did a find for *.torrent, saw the word 'preview', and assumed from there
<mdz> thom: I get a full set of 6 live+install isos in ~6 minutes with rsync
<Kamion> the problem with rsync for me is that I have to allocate space to keep the CDs, and if I let them get out of date it takes ages to rsync back to current
<Kamion> jigdo has considerable appeal because the local mirror is much easier to keep up to date
<Kamion> I don't keep the ISOs on the mirror box because it doesn't have a CD writer
<mdz> I allocate space for 6 CDs + space for rsync to work
<mdz> I do not allocate space for an entire mirror
<Kamion> yeah, that's kind of irritating to have to do on my laptop
* pitti tries ppc/install
<Kamion> the server has more or less infinite space, but no writer; the laptop has a writer, but limited space
<mdz> oh, forgot about that
<mdz> install-powerpc: success
<mdz> that's 5/5 for me
<Kamion> still rsyncing :(
<pitti>    206346088  38%   34.43kB/s    2:41:35
<Kamion> on 2/6
* pitti kicks rsync
<pitti> thom: I should really have considered jigdo, will switch to it after preview
<mdz> I must have finished rsyncing before you guys bogged down the servers :-P
<carlos> elmo: how big is an ubuntu mirror with hoary + warty?
<Kamion> the problem with jigdo is that we still don't have the snapshot archives that would make the jigdo files actually survive in useful form for more than a couple of days
<mdz> pitti: at that rate it would be faster for you to use wget -c
<Kamion> (apart from stable releases)
<pitti> mdz: now it's    413320896  76%    2.94MB/s    0:00:42
<pitti> mdz: probably the kernel part is done now :-)
<pitti>    534603704  98%   42.07kB/s    0:02:11
<pitti> yay
<mdz> thom: torrent ETA?
* Nafallo still syncs kernel *
<Kamion> torrents still generating
<Nafallo> rsync started 9:01 ;-)
<mdz> Kamion: eek
<Keybuk> oops, not that button
<Kamion> syncing
<Kamion> thom: ok, you should be able to embark on torrent love nowish
<pitti> mdz: I just wonder why i386/live is only 540 MB (although it is supposed to contain WinFOSS), but ppc/live is 615 MB, although it certainly does not contain Win stuff?
<mdz> pitti: 3 kernels
<pitti> oh, right
<mdz> pitti: i386 does not have winfoss on it yet
<pitti> so power3 and power4 machines don't boot with the powerpc kernel?
<pitti> I always thought that was like 386 vs. 686
<Kamion> I didn't manage to get winfoss down pre-preview
<Kamion> pitti: no, they're incompatible
<pitti> Kamion: not that I would miss it :-)
<Kamion> pitti: at the MMU-handling level in the kernel
<pitti> ah
<Kamion> requires scary kernel hacking to unify them
<Kamion> and upstream basically don't care
<fablivemulti> live-i386 is GO on piix
<fablivemulti> there is only one little issue with the UK keyboard with X
<memyself> which is?
<fablivemulti> but nothing too bad
<fablivemulti> it's mismapping one char
<fablivemulti> hashmark
<fablivemulti> 
<memyself> k
<thom> ppc is going
<jordi> thom thom thom
<mdz> thom: I have seeds standing by, pending tracker authorization
<fabbione> live-cd doesn't recover from hibernate
<mdz> fabbione: haha no it certainly doesn't
<mdz> one amd64 success report from ubuntu-devel
<Keybuk> we need an employee in Houston
<thom> rsync still running
<Mithrandir> GFDL is not ok for main, right?
<Kamion> Mithrandir: it's fine for Ubuntu main
<Mithrandir> Kamion: ok
* amu 's sync is now also finished, i'll try also one round 
<mdz> fabbione: was that a multiseat boot?
<mdz> has anyone done an i386 install yet?
* pitti receives a traffic limit warning email
* Kamion goes to get CDs
<GheRivero> hi
<mdz> d3vic3: the current build (linked from the topic) is the one to test
<d3vic3> ok 
<fabbione> mdz: yes, but in normal mode
<Kamion> burning install-i386 nw
<Kamion> now
<fabbione> mdz: i just used the multiseat hw
<fabbione> mdz: i am reburning i386 install again. the previous ones were just doomed
<pitti> mdz: btw, did anybody tried upgrading from warty?
<thom> waaargh, source isos
<Kamion> I don't think source ISOs are very useful but it's not clear to me that we can get away without them
<mdz> pitti: I'll do one now, also a server install
<thom> (as in, rsync is syncing them)
<pitti> mdz: I can try one on ppc, but it will last about 1.5 hours
<pitti> mdz: (install warty, upgrade from CD)
<pitti> mdz: do we have enough time for this?
<Kamion> if somebody competent to do so can tell me that pointing people at the archive for source is fine and that people might never be entitled to ask for source ISOs, then I can drop them, but somebody did ask for source ISOs (for Array <something>) and asserted that the GPL entitled him to that
<Kamion> i.e. a frozen image of the source used to build those CDs, not the archive which is changing
<mdz> pitti: that's what I'm doing now, but on amd64
<mdz> so it should only take 40-60 minutes
<mdz> our release target is 1800 UTC, so we have time
<Kamion> pitti: we have plenty of time
<pitti> mdz: okay, ppc install is still running, I immediately try an upgrade afterwards
<Kamion> having delayed a day, this is our least rushed release yet ;-)
<mdz> Kamion: next time we tell everyone that the release is the day before
<Kamion> mdz: exactly what I was going to say
<Kamion> mdz: but we have to not have artwork pending until THREE MILLISECONDS before the release
<mdz> Kamion: exactly hwat I was going to say
<thom> mdz: torrents torrenting
<mdz> thom: thanks
<jdub> Kamion: i was going to suggest the same strategy as gnome -> due monday, released wednesday
<Kamion> that certainly stands a better chance of working
<Kamion> it would be overkill for arrays, but for preview/final, absolutely
<jdub> yeah
<fabbione> mdz: installing base now (i386)
<Kamion> testing rescue mode, i386
<mdz> thom: my hoary-install-i386 torrent is flowing, but hoary-live-i386 is still saying rejected
<fabbione> livecd i386 doesn't catch a cisco aironet pcmcia card
<thom> mdz: oh, sorry. live cds still syncing
<thom> damn different directories :/
<Kamion> rescue mode seems fine, modulo crap UI (but what's news)
<fabbione> ah it got it.. but it took a long time
<mdz> has anyone done a server install yet?
<pitti> i386/live: success on old fujitsu laptop
<thom> mdz: i'll try ppc server as soon as desktop finishes
<falivefromlappy> there
<falivefromlappy> cool
<Kamion> I did a server install last night FWIW
<thom> mdz: live torrents going from here, work for you?
<mdz> thom: I'll know in about 2.5 minutes when it retries
<mdz> btdownloadcurses seems to check every 5 minutes
<fabbione> i386 install in phase2 now
<Mithrandir> thom: all the live torrents are dead forme
<Mithrandir> s/forme/for me/
<Mithrandir> nah
<Mithrandir> there they sprang to life
* Mithrandir kicks his connection.  Only 2.2MB/sec.
<jdub> mdz: i did server installs of last night's images (i386, ppc)
<mdz> jdub: thanks
<fabbione> Mithrandir: DIE!
<ogra> morning
<Mithrandir> fabbione: passing 3.0MB/sec now
<Mithrandir> seems like kicking worked
<fabbione> Mithrandir: DIE! DIE!
* ogra fires up his rsyncs
<Mithrandir> uploading at 1.6MB/sec too
<pitti> mdz: ppc/install: success on iBook G4 w/o network
<thom> aww, i'm only d/ing at 2.0MB/sec
<jdub> mdz: perhaps we should put together a little web form for install reports
<mdz> jdub: a test plan would be good
<jdub> mdz: if the person ticks 'failure', it throws the report into bugzilla
<thom> 1.2MB/sec up, too
<jdub> otherwise, it notes success
<mdz> a wiki test plan seems more achievable in the near term :-)
<jdub> yeah
<Mithrandir> thom: I just passed 5.0MB/sec down.
<Mithrandir> now we're almost talking
* Kamion cajoles Kinnison into testing the live CD
<jdub> encouraging success feedback would be good; even I didn't bother mentioning the successful installs i did last night
<WeFuckingROCK> 3/3 successes with LiveCD
* WeFuckingROCK pats himself because he is cool
<Mithrandir> hi fabio :)
<WeFuckingROCK> yeah i know it's me!
<WeFuckingROCK> :)
* d3vic3 wonders what was that about
<pitti> d3vic3: fabbione tested a live CD image
<Mithrandir> d3vic3: it was just fabio testing the live cd.
<fabbione> yeah
<fabbione> 3 over 3 are GO
<pitti> d3vic3: ... cybercity.dk says it all :-)
<d3vic3> sweet 
<fabbione> install on i386 almost done
* d3vic3 still waiting for image download
* Treenaks is torrenting at 1600/300
<fabbione> generating locales....
<Kamion> pitti: the phrasing says it all :)
<fabbione> Kamion: ahhaa
<pitti> Kamion: that as well :-)
<pitti> mdz: success: i386/live w/ network, ati 9600, desktop
<thom> ppc in scrollkeeper hell for desktop
<jdub> thom: spewage?
<pitti> thom: these nice error messages? do they occurr only on ppc?
<thom> none thus far
* jdub doesn't get why most of those only appear on ppc
<thom> just three weeks wait
<mdz> scrollkeeper seems especially slow on ppc
<Mithrandir> does anybody know _why_ scrollkeeper is so slow?
<fabbione> install i386 is GO
<fabbione> on the piix crap too
<Mithrandir> bah, my box is useless ATM. :P
<Kamion> smurfix: could the keymap selector please tell you at the end which keymap it's selected?
<jdub> Mithrandir: originally written by people who normally write docbook ;)
<mdz> upgrading a warty desktop to current hoary removes ubuntu-desktop
<mdz> with apt-get dist-upgrade anyway
<thom> desktop ppc finished fine
<smurfix> Kamion: I can do that. Add an input field to let people try whether it's correct?
<Mithrandir> jdub: I guess that explains something..
<thom> Kamion: the yaboot preamble doesn't mention the server option
<fabbione> mdz, Kamion: i have no issues so far.. you get the green light from piix department
<Kamion> smurfix: maybe something like that, yeah, with an opportunity to try again
<mdz> fabbione: thanks
<fabbione> mdz: no problem
<mdz> mvo: here?
<mvo> mdz: yes
<mdz> mvo: can you look into the warty->hoary upgrade issue?
* fabbione goes back bashing the kernel build system to death
<smurfix> Kamion: Makes sense. I'll put that in.
<mvo> mdz: ok
<Kamion> mdz: the live CD takes CENTURIES to generate locales if you select a language not already on the CD
* pitti hugs daniels
<pitti> success: i386/live on Samsung M40 laptop with widescreen display
<mdz> mvo: aptitude dist-upgrade gets it right, but not apt-get dist-upgrade
<pitti> last time, the resolution was completely wrong and it was impossible to setup 1440x90
<pitti> 900
<mdz> Kamion: to generate?  or to download?
<mdz> Kamion: oh, the live CD
<Kamion> mdz: adding a --keep-existing option to locale-gen would probably fix it
<mdz> yes, it takes a very long time
<Kamion> mdz: it's regenerating all the locales that are already there
<Kamion> and the progress bar just says "Configuring language", no extra information
<mvo> mdz: boot a warty system now
<mdz> Kamion: that'd have to be changed in glibc, I suppose
<Kamion> yep, I can do that pre-final
<Kamion> Kinnison thought the live CD had hung
<mdz> Kamion: we need to figure out what to do about language-support-* which are not on the install CD, too
<Kamion> <Kinnison> oh, and mouse pointers are still shit
<mdz> Kamion: hung, but was churning wildly away at the disk?
<mdz> Kamion: it's possible that we'll be able to fit all language-pack-* on the live CD, so this may not be an issue for final
<mdz> pitti will let us know
* mdz workraves
<mvo> it installed some english dictionaries and openoffice stuff yesterday even when installing for german language
<mdz> mvo: that's a feature
<pitti> mvo: language-support-en is in desktop, for whatever reason
<mvo> aha
<Kamion> hmm, fontconfig is picking a serif font
<Kamion> mdz: no, it was churning RAM
<mdz> pitti: it's not in desktop
<mdz> but the installer installs it by default
<Kamion> locale-gen is not quick when it has to regenerate everything
<pitti> mdz: ah, ok
<mdz> oh, it was regenerating all the english locales, I see
<Kamion> mdz: the live rootfs generation will take eons without --keep-existing or whatever anyway, because it is currently O(n^2)
<svenl> Kamion: you have mails with patches.
<mdz> Kamion: true
<mdz> it's not that bad on reasonable hardware, though
<mdz> even the 50 english locales take only a minute or so
<Kamion> svenl: ok, thanks
<svenl> Kai doubt you have time to test and i may still come up with a OF kludge to fix this clear yaboot misbehavior, but i still would like to get pmac results from it.
<Nafallo> Can someone confirm that About Ubuntu doesn't do what it should?
<Nafallo> for me it pops up an .xml in gedit.
<pitti> success: ppc live @ibook G4, networkless (only keyboard is broken, known bug)
<pitti> Nafallo: with ppc/live, I get a yelp with the welcome page
<thom> Nafallo: i get yelp on amd64/install
<Kamion> Kinnison *really* doesn't like the clearlooks progress bar shimmying effect
<Nafallo> I should add I get an empty yelp in the background. probably a local failure then...
<Kamion> especially in combination with a left->right->left throbber
<Nafallo> yikes! school *runs*
<jdub> Kamion: left-right-left throbber?
<jdub> Kamion: you mean a cylon? what's doing that?
<thom> synaptic does it when you do an update
<thom> or, i remember some part of g-a-i/update-manager/synaptic doing it
<sabdfl> Kamion: agreed on the direction of the throbber
<Kamion> jdub: yes, update-manager
<Kamion> sabdfl: um, it's not the direction?
<sabdfl> it should be >>>>> and move to the right
<Kamion> sabdfl: it doesn't know the length yet, so it does that briefly
<thom> synaptic does it when it's unpacking
<sabdfl> ?
<thom> server just installed fine on ppc
<mvo> synaptic does it when it waits for dpkg (when dpkg reads it's database and gives no feedback)
<Kamion> but when it does that in combination with the shimmering effect, it's epileptic-fit-inducing
* thom burns amd64
<Kamion> because you have a thing going left->right->left *and* a diagonal shimmer on the bar
<sabdfl> the shimmering -- the diagonal lines are crackful
<mvo> Kamion: it's a bit fast in the version in hoary, my version is slower now
<sabdfl> they should be chevron-style
<sabdfl>  > > > >
<sabdfl> and only move to the right
<Kamion> *boggle*
<Kamion> no, they should just disappear IMHO
<sabdfl> Kamion: sure, text-mode-boy
<jdub> Kamion: ah, right; i think the animation is appropriate there; hmm.
<ogra> mvo: are you guys talking about pulse() ?
<Kamion> sabdfl: dude, there's way too much stuff moving around at the moment
<Kamion> it's foul
<Keybuk> Dear Nautilus; please stop placing volume icons on top of existing ones, kthxbye
<Kamion> it's like blingtastic
<jdub> Kamion: it could be made less distracting
<sabdfl> it could do with some simplification
<mvo> ogra: yes
<sabdfl> but it has potential
<jdub> Kamion: look at OS X's, it provides great affordance of processing, but isn't too distracting
<jdub> (it's not chevron style, either)
<Kamion> jdub: hmm, will have to look again
<sabdfl> jdub: colour selection needs help, for window titles and menus
<ogra> mvo: hmm, so someone shuld com up with an idea what to do if you got no response form the pipe :)
<jdub> the important bit is the hint of processing
<sabdfl> needs some of the warmth we got from warty -> hoary desktop transition
<jdub> sabdfl: yes, that's totally not final
<Kamion> Kinnison didn't like the hover effect on menus
<ogra> mvo: i'm using it too in hwdb-client ;)
<jdub> Kamion: that's definitely being deblinged
<jdub> Kamion: too chunky atm
<Kamion> you get a brown rectangle which is very distinct from the grey background, but there's a little border around the edge of it
<sabdfl> Kamion: i think the colours there are leftover from warty palette
<Kamion> sabdfl: ah, right
<Kamion> cool
<sabdfl> the raised-effect will stay, but the colours will get warmer
<sabdfl> a bit more subtle
<Kamion> that would certainly be nice
<sabdfl> checkout clearlooks-olive
<Kamion> hmm, lilo install failed on an LVM-root install
<jdub> sabdfl: the 3dness of the menu selections will be less prominent though
<Kamion> will have to try again post-preview and debug
<Kamion> LVM-root's not quite so high prio though
<Kamion> mvo: fast> yeah, reducing the speed would help with the motion-sickness effect, definitely
<Kamion> (hmm, that sounded sarcastic, sorry, it wasn't meant to be)
<jdub> the OS X one is slower
<mvo> Kamion: no worries, I think I understood it right :) it's slower in my local tree 
<Kamion> cool
<Kamion> so the application controls the speed?
<jdub> no, engine defined
<jdub> could be turned into a theme option, but that's silly :)
<ogra> Kamion: you can either set an idle loop or set a timeout....
<jdub> oh, synaptic cylon, not theme?
<ogra> Kamion: where the idling depends on the system speed and scles with it
<Kamion> jdub: right
<jdub> ok
<mvo> jdub: synaptic calls gtk_progress_bar_pulse
<Kamion> clearlooks-olive> is that in universe? can't check right now
<ogra> Kamion: should be installed
<Kamion> 'k
<ogra> Kamion: its just another color variant
<thom> mvo: holy crap; the "You've inserted an ubuntu cd" thing is totally sweet!
<Kamion> it's pretty
* mvo is happy
<jdub> mvo: yeah, was caught up in previous context ;)
* ogra is _very_ courious if his amd64 widescreen display will get recognized now.....
<ogra> brb
<mdz> mvo: we need to be sure to test that thoroughly; it will be great to be able to upgrade from hoary with it, but only if we make sure that it is solid before final :-)
<Kinnison> Hi guys
<Kamion> 11:52 < sabdfl> the raised-effect will stay, but the colours will get warmer
<Kamion> 11:52 < sabdfl> a bit more subtle
<Kamion> Kinnison: ^-
<Kamion> 11:52 < sabdfl> checkout clearlooks-olive
<jdub> raised effect will be more subtle too
<jdub> less liney
<mvo> mdz: nod
<Kinnison> The wibbly lines in the progress bars actually gave me about three seconds worth of motion sickness the first time I saw them
<thom> i actually think clearlooks itself is the nicest of the clearlooks based themes, but lighthouse-blue is still my favourite :-)
<Kinnison> bad muju
<amu> mdz: i386/live on T41 and Samsung X30, works fine
* thom reboots to test amd64
* amu test ppc
<mdz> d3vic3: did you intend to claim bug 7405?
<sivang> Hey all
<jdub> uh oh
<sabdfl> Kinnison: agreed, they need work, but given direction i think they could be very nice
<jdub> getting abnormal status eroror messages on my sata disks
<Kinnison> sabdfl: A good rule of thumb is "only one moving part at a time"
<d3vic3> mdz, yes 
<sabdfl> Kinnison: aqua
<Kinnison> sabdfl: Really far too busy
* Kinnison finds aqua very very very very annoying
<Kinnison> Hmm, not enough 'very's there
<jdub> Kinnison: equally, the affordance given by knowing there's something happening is helpful
<Kinnison> jdub: Then it needs to be way way more subtle
<sivang> is there any news for the PIIX detection bug?
<sabdfl> yes, it needs to be more subtle
<jdub> yes, closer to OS X's
<Kinnison> jdub: E.g. a periodic glint or something
<mdz> d3vic3: hotplug is a critical package, and I'm not certain that the proposed changes are correct
<Kamion> sivang: kernel -25.2
<fabbione> sivang: yes. it has been fixed
<sabdfl> sivang: we've rolled back to a previous bug instead
<Kinnison> jdub: OS X's is too in-your-face IMO
<Kamion> sivang: current CDs are preview candidates
<sabdfl> guys, let's focus on release now
<Kamion> mdz: was I correct in gleaning from the scrollback that jbailey's report that -25.1 was broken on his system was a false alarm?
<mdz> Kamion: yes
<jbailey> Kamion: Yes.
<sivang> Kamion, sabdfl, fabbione : kthxrsyncingnow :)
<mdz> Kamion: so in fact it looks like the approach in -25.1 is fairly reasonable
<mdz> Kamion: and seems to have fixed nico's problem (see #ubuntu)
<d3vic3> mdz, i figured the changes must not go to hotplug 
<ogra_live> no widescreen :(
<Kamion> ok, good (hm, I'm not on #ubuntu)
<jbailey> Kamion: My bad for being in too much of a hurry.  I have the two SATA systems side by each and got scrambled as to which one I was looking at.
<d3vic3> mdz, I'm trying to figure out wich package they must go to 
<Kamion> jbailey: np, we were all a bit stressed
<jdub> jbailey: do you have any sii sata?
<pitti> hi sivang
<sabdfl> jbailey: happy to send you some more systems to have side by side, kamion's full :-)
<sivang> pitti: Hi :)
<Mithrandir> sabdfl: ooh, free hardware. ;)  (I guess I shouldn't say that with you present. :)
<jbailey> jdub: Lemme just check a couple other machines, just a sec.
<Kamion> quid pro quo ...
* jdub_ might reboot to 2.6.8, see if the same thing happens
<thom> Kamion: d'you know if anyone is working on evms support for the installer, OOI?
<jbailey> sabdfl: *lol*  At this point so am I.  And then a G5 arrived and I haven't quite figured out where I'm going to put it ;)
<Kamion> thom: not AFAIK
<Mithrandir> thom: I'm going to, but haven't gotten around to it yet.
<sabdfl> mdz: #ubuntu-meeting?
<Mithrandir> jbailey: get a rack and a KVM?
<jbailey> Mithrandir: You know I live in a one-room appartment, right?
<Mithrandir> jbailey: nope, I didn't know that.
<Mithrandir> jbailey: and you work from home?  Must be crowded.
<dredg> jbailey: clearly you need to expand. annex your neighbours :)
<jbailey> Mithrandir: Ah, yeah.  Me, my wife and two cats.  Looking forward to moving in July. =)
<Kamion> sabdfl: btw, the candidate images have been on releases.ubuntu.com/.pool/ for a while, although I've no idea how many mirrors will have picked them up
<Mithrandir> jbailey: same, sans wife, cats, add girlfriend who likes computers almost as much as I do.  Also looking forward to moving in June/July.
<sabdfl> Kamion: what time were they uploaded?
<sivang> Kamion: the "current" symlink is updated right?
<Kamion> sabdfl: 10:32 < Kamion> thom: ok, stuff syncing to releases.u.c/.pool/ now
<Kinnison> I'll leave you guys to it
<Kamion> sivang: no, .pool is for pre-mirroring
<jbailey> Mithrandir: My belle is 'patient' about the computers...  The pegasos and G5 are almost silent, so they can at least stay on all the time.  The alpha and hppa box may as well go in storage, and the ia64 is at a colo ;)
<Kamion> sivang: er, daily/current has been yes, sorry, misunderstood you
<sivang> Kamion: tnx :)
<Mithrandir> jbailey: we're getting a computer room and somewhere to stuff a rack.  I'm adamant about that. :)
<lifeless> Kamion: elmo gpg internals question.
<Kamion> lifeless: ?
* d3vic3 thinks his space is too big 
<d3vic3> anayone got hardware to send my way :p 
<lifeless> gpgme exposes per key keyid as 16digit hex strings
<Kamion> lifeless: did you mean me or elmo or both?
<lifeless> gpg exposes teh same as 8 digit hex strings  + key type 
<opi> is there anyone who is handling php4 modules in Universe?
<lifeless> Kamion: whoever can help.
<jbailey> d3vic3: Careful wht you ask for.  People have this crazy habit of expecting you to actually troubleshoot things on the hardware. =)
<lifeless> picked the math head and the security head. 
<lifeless> ;)
<Mithrandir> jbailey: and you being a glibc guy...  fun, isn't it? :)
<Kamion> lifeless: elmo is asleep, and when he gets up he will probably be busy with the hoary preview; I'm busy with the hoary preview right now
<lifeless> ah:[
<Kamion> lifeless: now is not really an ideal time :)
<d3vic3> jbailey, good thing I can do that, if I got the time 
<lifeless> this is making baz do gpg checking right
<sivang> jbailey: hey Jeff, hmm, I wouldn't mind troubelshooting for having exotic hardware :)
<dredg> opi: try #ubuntu-motu
<opi> dredg: 'k
<jbailey> Mithrandir: I told people that I would care about any arch that they sent me and then prayed that an s390 wouldn't show up at my doorstep.  It was worse, I got an m68k.
<lifeless> so I'll carry on with my obscene hack. AFAICT its not any more gamable than ids are intrinsically, and I support fingerprints
<Mithrandir> jbailey: *chuckle*.  They're not as noisy, though.
<Mithrandir> lifeless: what is the problem you're trying to solve?
<lifeless> Mithrandir: getting the 16 digit keyid out of gpg, so that I can directly compare with gpgme, and so that users can easily configure stuff.
<Mithrandir> lifeless: gpg --with-colons --list-keys tfheen@debian.org | grep ^pub
<Mithrandir> pub:u:1024:17:412B1E31817A996A:1999-11-28:::u:Tollef Fog Heen <tfheen@err.no>::scESC:
<lifeless> sweet
<Mithrandir> you should be using --with-colons anyhow if you are parsing gpg output
<Mithrandir> anything else is madness
<lifeless> oh, gpgme does
<thom> grmph
<thom> ok, server install on amd64 looks good
<sivang> hmm rsync speedup's real nice, 40Mins to finish :)
<jdub> ah crap, lost the logs of the errors
<pitti> mvo: ubuntu-desktop is removed for me (ppc) as well when doing warty->hoary
<pitti> mvo: any idea why?
<Kamion> sivang: rsync will lie, it'll probably be faster than that
<sivang> Kamion: then yay, great :)
<mvo> pitti: not yet, my warty install didn't showed it and therefore I'm installing a clean version now
<seb128> liveCD works fine on amd64
<ogra_live> seb128: no widescreen panel detection here
<lifeless> Mithrandir: thanks
<pitti> mvo: darn, upgrade is already running
<mvo> lifeless: you know about /usr/share/doc/gnupg/DETAILS.gz? 
<pitti> mvo: I should probably have done a --dry-run before
<pitti> mvo: can you please do this?
<lifeless> mmm, didn't, thanks
<jdub_> hrm. disk death may be a possibility. :-|
<mvo> pitti: do what?
<lifeless> mvo: I do have most gpg stuff under control ;)
<dholbach> re
<pitti> mvo: apt-get -u --dry-run dist-upgrade
<pitti> mvo: I upgraded right away
<mvo> lifeless: ok (wanted to be helpfull :)
<mvo> pitti: I'll look into it
<lifeless> mvo: oh you were - thanks again.
<lifeless> mvo: I'm just tired -> grumpy
<thom> ogra_live, please, for the love of god, don't use php5 based on dotdeb.org? :-)
<mpt_london> "E: /var/cache/apt/archives/language-pack-en-base_20050308_all.deb:  trying to overwrite `/usr/share/locale-langpack/en_CA/LC_MESSAGES/gnome-panel-2.0.mo', which is also in package language-pack-en"
<ogra_live> thom: i will ask for your expertise on package review if you like ;)
<sivang> thom: are you allergic to php5, I've seen you talk about this before :)
<thom> ogra_live, well, infinity is already working on php5 for debian unstable, and he's php4 maintainer and working on ubuntu too
<Kamion> mpt_london: yeah, known langpack bug
<ogra_live> thom: will he make it before release (php5)
<Mithrandir> hmm, releases.ubuntu.com seems to be missing a favicon.
<thom> ogra_live, he's been threatening them for a while
<pitti> great, now when we release the preview, everybody stumbles over the langpacks
<pitti> they had this structure for ages...
<Kamion> Mithrandir: feel free to give me one
<Mithrandir> Kamion: same as the one on www.ubuntu.com?
<Kamion> cdimage.ubuntu.com doesn't have one either iirc?
<Kamion> Mithrandir: ok, where does it have to live?
<Mithrandir> /favicon.ico, iirc
<thom> Kamion, i can do favicons
<ogra_live> thom: i want that in universe in any case for release, even if its a packages i have to tag as preview in the version (to prevent the whining)
<Kamion> thom: they need to be on little
<Kamion> I'll grab the one from www.u.c
<Kinnison> I just upgraded my desktop and my look&feel just went way downhill
<Kinnison> Any chance of hoary *also* carrying the old theme for those of us who prefer it?
<Kamion> Mithrandir: will be there for preview
<Mithrandir> Kamion: great
<jdub_> Kinnison: possibly; your point was made earlier - what's in preview is not final.
<Kamion> good suggestion, not something I tend to think of
<Kamion> cdimage.ubuntu.com has it too
<Kinnison> jdub_: I appreciate changing the default for new installs; I just think it's a pity that we've effectively stomped on a user preference
<jdub_> Kinnison: it was done that way for preview, it won't be like that for final
<jdub_> Kinnison: it was change one package vs. three or four.
<jdub_> one was tough enough, at the time.
<d3vic3> seb128, ping 
<Kinnison> jdub_: okay cool
* Kinnison puts up with blue window borders for now
<seb128> d3vic3: pong ?
<jdub_> all this sata talk killed one of my server's disks :-)
* pitti watches the warty->hoary upgrade removing openoffice.org
<pitti> mvo: any idea? ^
<pitti> (only the metapackage)
<mvo> pitti: not yet, still installing :)
<d3vic3> seb128, "rebuild without libhowl0 dep" = "rebuild for libhowl transition" ? 
<seb128> yep
<amu> hmm live@ppc powerbook4 has trouble with german keybord, in xorg it is a pc104 and US 
<pitti> amu: known bug, for me too
<dholbach> seb128: uploading rebuilt gnomeicu
<seb128> k
<mvo> hi dholbach 
<amu> pitti: `k   
<dholbach> hi mvo! :-)
<pitti> amu: #7138
<pitti> argh
<pitti> warty->hoary upgrade asks conffile question about /etc/udev/scripts/ide-devfs.sh
<Treenaks> pitti: it asks a LOT of conffile questions.. didn't write them down, but I upgraded a clean warty (CD) install to hoary the other day
<Treenaks> and I had to answer 4-5 conffile questions
<Treenaks> (clean = un-security-patched, pure CD-install)
<pitti> same for me
<pitti> mdz: is there a meta-bug for upgrading warty->hoary, similar to #1436?
<pitti> mdz: I'd like to make it depend on particular bugs like #4973
<mdz> pitti: no, but feel free to create one
<pitti> ok
<pitti> mdz: do you agree that we should fix dpkg question bugs by the final? #4973 is "normal" right now, but I'd like to upgrade their severity
<fabbione> mdz: if i understood right, 25.2 was a mistake and enable_libata-2 should be readded, right?
* amu boots back in his wounderfull K-env :)
<mdz> fabbione: 25.2 was not a mistake, but yes, we should readd that
<fabbione> mdz: yeah i mean.. the report of the problem was a mistake
<Keybuk> When mentioning dpkg-related bugs, _please_ specify whether it's a Debian# or Ubuntu#
<Keybuk> there are dpkg bugs in the Debian BTS < 4973 :p
* netjoined: irc.freenode.net -> orwell.freenode.net
<jdub__> http://www.iceni.org/cgi-bin/blosxom.cgi//2005/03/08#05-03-07-1
<jdub__> ^ automated testing interest
<jdub__> no real detail
<jdub__> but interesting insight into what their tools test
<low> ok, lilo and grub chokes at install if /boot is xfs
* ..[topic/#ubuntu-devel:mdz] : 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/
<low> mdz, another problem is, i can't open gnome menus on top on the screen
<sabdfl> congrats everybody
<dholbach> WOOHOO!
<sabdfl> thanks espcially to kamion, mdz, elmo, fabbione for getting us through the kernel krunch
<sabdfl>  < no reference to kde whatsoever >
<Kamion> low: xfs /boot and grub> yeah, long-known bug, never been successfully diagnosed
<Kamion> there is a warning in place I believe
<Treenaks> hey, no final name for hoary+1 in the announcement :P
<Riddell> sabdfl :)
<mpt_london> eep
<low> Kamion, yep. i even know why it breaks (long time xfs user): 1st partition sector can't be used for lilo or grub when xfs is used
<low> you must use MBR
<mpt_london> Someone, please, s/The correct CD for/For/g :-)
<HiddenWolf> kamion: the warning is there, yeah
<low> Kamion, anyway i don't know why grub and lilo grumble when i ask them to use mbr
<Kamion> mpt_london: where what?
<sabdfl> mpt_london: where does that show up?
<magnon> congrats to everyone :)
<Kamion> oh
<Kamion> ok, will change
<mdz> sabdfl: the CD image index
<mpt_london> Kamion, sabdfl: http://releases.ubuntu.com/hoary/
<Kamion> that was mako text I think
<sabdfl> Treenaks: erm. good point
<sabdfl> ah, good catch mpt_london
<Kamion> mpt_london: done
<mpt_london> yay
<mpt_london> Either that, or add various "The incorrect CD for" sections around the place
<mpt_london> just to keep people on their toes
<Kamion> low: we *don't* use the first partition sector; we *do* use the MBR
<Kamion> low: it's not that simple
<Kamion> heh
<fabbione> mdz: do i have green light to upload kernel-wedge? ;)
<koke> hmm, gnome-btdownload is nice, testing with hoary-preview :)
<low> Kamion, i'm using lilo for ages w/ xfs on mbr, it never annoyed me
<lifeless> Kamion: can I ask a favour ?
<Kamion> lifeless: sure
<Kamion> you can ask ;-)
<mdz> fabbione: yes
<lifeless> Kamion: when elmo srufaces, or thom, There was a request I asked elmo to do - that he did - that seems not-quite-right.
<mdz> pitti: OK to upload langpacks, security updates, hpoj, cupsys, etc.
<jdub> seb128: want version diffs now? ;-) ;-)
<lifeless> Kamion: the request was gnupg & libgpgme-dev in the bazaar build chroots
<lifeless> Kamion: I suspect only the former happened, because I phrased the second as 'and shortly willalso need' ;/
<Kamion> lifeless: thom should be around ...
<Kamion> but if not I can pass it on
<lifeless> Kamion: I'm crashing to sleep though, so can't do the buzzy fly thing - so if you can channel me, for that, with promises of a lovely JustWork gpg interface as soon as I can build the debs ..
<Kamion> lifeless: 'k
<lifeless> I'd really appreciate that.
<lifeless> thanks!
<lifeless> gnight
* jdub weighs up early meeting and sleep today. hrm.
* ogra_live reboots to normal.....
<thom> *grumble*
<Kamion> thom: request from lifeless:
<Kamion> 13:14 < lifeless> Kamion: when elmo srufaces, or thom, There was a request I asked elmo to do - that he did - that seems not-quite-right.
<Kamion> 13:14 < lifeless> Kamion: the request was gnupg & libgpgme-dev in the bazaar build chroots
<Kamion> 13:14 < lifeless> Kamion: I suspect only the former happened, because I phrased the second as 'and shortly willalso need' ;/
<Kamion> 13:15 < lifeless> Kamion: I'm crashing to sleep though, so can't do the buzzy fly thing - so if you can channel me, for that, with promises of a lovely JustWork gpg interface as soon as I can build the debs ..
<Kamion> low: doing a test run now
<low> Kamion, thx
<pitti> mdz: cool, I'll do. preview stuff is settled now?
<Kamion> pitti: preview's done and dusted
<pitti> mdz: "langpacks" -> shall I do new base langpacks and empty updates, or shall we wait for a bug fix?
<pitti> Kamion: all my install and live tests were okay, upgrading is a mess
* jdub raises an eyebrow at "desktop publishing" in release announce
<pitti> Kamion: but it's too late to fix this for preview anyway :-)
* Treenaks publishes his desktop
<seb128> jdub: yep
<jdub> seb128: glutton for punishment :)|
<seb128> jdub: probably gnomemeeting and gdm
<Kamion> jdub: that was sivang I think
<mdz> pitti: new base, please
<mdz> pitti: this is urgent
<pitti> okay
<pitti> mdz: we need to trick away elmo again :-)
<Mithrandir> mdz: is the preview freeze lifted now? :)
<Kamion> "with vorbis playback and Python 2.4 ready out of the box" is not great grammar, but hey
<mdz> Mithrandir: yes
<mdz> but please don't do anything crazy yet :-)
<ogra> hehe
<Mithrandir> utf8-migration-tool ok in a couple of hours?
<HiddenWolf> kamion: who knows, if patents in the eu get shot down... ;)
<mdz> sabdfl: we're the top story on distrowatch
<mdz> they are so fast
<Kamion> HiddenWolf: what was that in reply to?
<fabbione> mdz: do you still have superpower to process NEW?
<mdz> fabbione: yes, but only if it's urgent
<fabbione> ok nothing urgent
<dholbach> whoever put the community in the previewrelease draft: good thinking, thank you!
<HiddenWolf> kamion: the vorbis playback: if patents get shot, it's one hurdle out of the way to add mp3/dvd playback
<mdz> Mithrandir: utf8-migration-tool is fine now; it isn't installed by default or anything
<Mithrandir> mdz: it needs some more polishing for those people who want to upgrade from C locales.  Should be easy enough now that I've decided how to handle it.
<mdz> pushing 8mbit on the torrent
<jdub> dholbach: dude, that's the best bit :-)
<dholbach> jdub: YEAH :-)
<Burgundavia> already on distrowatch
<Treenaks> OK, who submits to slashdot?
<jordi> sabdfl: did you see planet.d.o?
* Mithrandir notes that there hasn't been a single byte of ia64 downloads yet.
<jdub> Mithrandir: ;)
<HiddenWolf> hm, distrowatch isn't mentioning ubuntu for me
<dholbach> jdub: uploaded rebuilt gnome-phone-manager
<jdub> Treenaks: do it anyway, best entry wins ;)
<jdub> dholbach: sweet!
<Kamion> HiddenWolf: EU patents haven't been legally valid up to now and that hasn't stopped it being a problem
<HiddenWolf> kamion: it'll take the threat out of the air for 400 million people. 
<mdz> HiddenWolf: reload
<Burgundavia> HiddenWolf: top of the page
<HiddenWolf> mdz: 2005-03-10  	Distribution Release: Kurumin Linux 4.1
<tseng> its definately ubuntu
<tseng> you are caching or something.
<tseng> shift+reload could be helpful.
<jdub> gee DW are fast
<Burgundavia> mdz: do we have stats about how many people are hittings the repos, etc?
<Kamion> HiddenWolf: however that's anything but the direction in which things are going, unfortunately
<Treenaks> jdub: maybe they're reading the channel?
<mdz> Burgundavia: I don't
<Kamion> HiddenWolf: in any case I was complaining about the grammar, not the content :)
<Burgundavia> he is probably subscribed to the announce lists of ever distro
<dholbach> can anybody help me with this one: "dh_shlibdeps -pgnome-bluetooth -> dpkg-shlibdeps: warning: could not find path for libgnomebt.so.0"   --  although debian/libgnomebt0.shlibs seems ok
<HiddenWolf> mdz: i've been reloading a lot, but it still won't refresh
<thom> ubuntu is top for me (on distrowatch, but ... ;-) )
<mdz> HiddenWolf: I have no more clues for you; it's correct for everyone else
<jdub> hrm, one thing missing from the preview announce i didn't think of before: there's no clear, strong indication that this intended for and regarded as safe for testing
<mdz> jdub: too late
<Burgundavia> I think the word preview might be a clue
<jdub> mdz: obviously.
<mdz> the fact that we're sending it to ubuntu-announce is a clue for those folks
<Burgundavia> hey you planet.ubuntu folks, push the blogs out
<jdub> mdz: we make it very explicit in gnome release announcements because people, on the whole, don't infer it.
<Kamion> mdz: #7424 is a good idea from Kinnison that might have allowed us to dodge some of the bullets this time round
<mdz> mvo: someone posted to -devel saying that update-notifier tried to upgrade from a live CD again; I thought that was fixed
<mdz> Kamion: sure, we could do that
<mdz> and perhaps some knoppix-style options as well
<mvo> mdz: I didn't wanted to upload before preview
<mdz> mvo: I thought it was fixed weeks ago, but I guess I'm mistaken
<mdz> mvo: anyway, feel free to upload now :-)
<Kamion> parsing non-debconfy boot options is annoyingly fiddly, but could be done
<HiddenWolf> hm: it seems distrowatch.com is updated / distrowatch.cz is not
<mvo> mdz: what is upload policy now? can we upload carefully selected bugfixes?
<mdz> mvo: for things which are part of desktop, be careful
<mvo> mdz: I thought it was fixed, but one or two days before preview noticted that it wasn't :/
<mdz> for other things, general bugfixes are OK
<mvo> mdz: I have fixes for update-manager, synaptic, python-apt and update-notifier ready that I would like to upload in the new couple of days
<mdz> mvo: synaptic -> including libgnome2-perl?
* HiddenWolf wonders how many new users hoary will generate
<Burgundavia> HiddenWolf: at least 1, my step mom
<Kamion> XFS on lilo works fine for me, so I don't know what low was talking about
<HiddenWolf> burgundavia: my mother will start on hoary+1: provided gnome tackles the resources
<mvo> mdz: I can add this dependency, yes. and small fixes like a slower progressbar pulse, a potenial file-descriptor leak and stuff like this, pretty low impact
* Kamion -> lunch
<Burgundavia> HiddenWolf: my father is hoary+1
<Burgundavia> HiddenWolf: or 2 or 3 or 10
<mvo> mdz: update-manager/python-apt is a bit bigger, I added support to read the apt pinfile 
<mvo> mdz: but it does not touch exisiting code in python-apt and should generally be safe
<HiddenWolf> my father sells windows software, won't ever get him to switch
* fabbione heads off for a little nap
<lamont> morning
<pitti> Hi lamont
<dholbach> hey lamont 
<fabbione> ah lamont
<mdz> madduck: yes, it is
<madduck> thanks.
<mdz> madduck: cf. #kubuntu and #kubuntu-devel
<fabbione> lamont: i just commited the "Kill the patch madness"
<madduck> mdz: that's pretty amazing. so you guys want to continue a 6 month release cycle with 15'000+ packages?
<fabbione> lamont: if you want to give it an overall check.. it works on amd64.. waiting i38 to finish the build
<mdz> madduck: yes.  not all 15,000 packages are officially supported, though.
<madduck> mako: do i have to sign up for more CDs again, or will i be sent the same shipment as before?
* lamont brb
<madduck> mdz: mh, maybe this should be made more explicit in such announcements... but that's just a detail.
<mdz> madduck: we still consider these packages to be part of Ubuntu, though they receive less QA
<tarzeau> madduck: now
<jdub> so, the gnome livecd is kinda funny
<madduck> tarzeau: what's going on?
<jdub> luis removed a huge stack of stuff to have more space (and smaller cd)
<mdz> jdub: which daily is it based on?
<jdub> including vim, nano, ... ;-)
<jdub> mdz: few days back, i'll double check
<tarzeau> madduck: i was curious about your question and the answers to it
<madduck> mdz: some people did not read that from your email. i just had two in my office who were all in rage telling me that ubuntu now goes full way.
<madduck> oh. want scrollback?
<mdz> jdub: depending on which kernel he got, it might be a good idea to roll a preview-based one
<madduck> tarzeau: http://rafb.net/paste/results/3g5sR434.txt
<Goshawk> what will be happen to GNU/linux ubuntu is the software patents in Europe will be accepted?
<madduck> we will become an underground organisation
<pitti> mdz: warty->hoary upgrade finished; a bit rough and there are no langpacks installed, but it works in principle
<Goshawk> madduck, what???
<Goshawk> or better how?
<pitti> mdz: I collected all issues in #7416
<madduck> Goshawk: who knows... 
<mvo> we'll move development into a space station
<mdz> Goshawk: madduck is joking with you
<dholbach> mvo: oh rocking, sabdfl wll love that
<dredg> Goshawk: that really remains to be seen. i'll let you know when I take out McCreevy.. he only lives a few miles away
<madduck> mdz: unless push comes to shove and we will actually have to do something like that... :/
<pitti> mdz: oh, and the locale is still ISO
<madduck> Goshawk: but yeah, i am joking... somewhat.
<lamont> it's not nice to upgrade all the libs and not restart things, you see..
<Goshawk> dredg, but have you thought only one time to what will happen?
* lamont must run kids to school. back in a bit
<jdub> Goshawk: it will just mean more places that won't be able to use stuff, and we'd continue to be careful
<mdz> pitti: utf8-migration-tool will handle that (right, Mithrandir?)
<pitti> mdz: locales are generated at langpack installation, but the default in /etc/environment must be changed
<Mithrandir> mdz: u8mg will change the locale and convert file names.
<pitti> Mithrandir: ^is that done?
<pitti> ah, cool
<Mithrandir> pitti: it doesn't touch /etc/environment, no.
<pitti> Mithrandir: uh, how does it change the default locale then?
<Mithrandir> changes .dmrc
<pitti> Mithrandir: so console will still have ISO?
<Mithrandir> yes
<Mithrandir> the real fix is for pam_env to have per-user enviroment files
<pitti> Mithrandir: uh, that means u8mg is per-user, not system-wide?
<Mithrandir> pitti: correct.
<Mithrandir> u8mt, actually
<pitti> er, yes
<tarzeau> mvo: on the sea would be easier, no?
<mdz> gah, everyone is replying to me with pre-preview tests now
<mdz> and off-list
<mvo> tarzeau: sure, but less fun :p
<ogra> tarzeau: but less cool
<mdz> Kamion: you're going to be awake for a while, right?
<mdz> I think I'm going to sleep some
<dholbach> mdz: good night
<mvo> night mdz 
<ogra> night mdz
<jdub> gute nacht
<mdz> call my mobile if the world is ending
<mdz> night folks
<pitti> night mdz 
<tarzeau> ogra, mvo i wouldn't want to live in a fartstinking, hard to get fresh air space station
<tarzeau> but certainly you can put me on a ship or island with internet 
<seb128> 'night mdz 
<thom> night mdz
<ogra> tarzeau: but "the distro from outer space" would make a nice advert :)
<tarzeau> distro from northpole would be nice too, wouldn't it?
<tarzeau> especially when you shipped it on 24th dec
<ogra> heh
<ogra> pitti: did you send heise a note ?
<pitti> ogra: no, not yet
<pitti> ogra: I'm still waiting for the next catastrophy which blocks the preview another day
* pitti ducks
<pitti> ogra: no, seriously, didn't find the time to do so 
<ogra> pitti: much to late now
<ogra> (for blocking)
<pitti> ogra: all my machines were tested successfully. worksforme -> out with it :-)
<ogra> nearly the same here...beside one bug in the detetion of my widescreen display
* pitti installs cd on his i386 desktop
* koke going to eeatt
<jdub> Riddell: http://dot.kde.org/1110426963/
<jdub> Riddell: see that?
<Riddell> jdub: of course, I approved it
<Riddell> jdub: I've spoken to them about doing a kubuntu-amarok in future
<daniels> svenl: i'm uncomfortable with the hack, and i do not have the time to port the radeon driver.  i don't appreciate being given ultimatums, either.  if you want to actually provide a full patch, please do that, and i'll look at it.  if you want to fix the pcigart fallback, even better.  but please realise that I have even less time than you do (I'm in the middle of moving right now, as well as Hoary), so really, telling me to do one or the othe
<jdub> Riddell: tops.
<daniels> mdz: is xserver even a virtual package at all?
<svenl> daniels: hey, don't take it badly, it was not meant so.
<daniels> mdz: i suppose the main value comes in that external modules can depend on xserver-xorg if they're compiled, although the value of a debugging server when you're loading external modules is severely decreased
<svenl> daniels: you said you would add the bustype thing first, and then continue telling me you don't like the hack :/
<daniels> svenl: i said i'd think about it.
<svenl> daniels: why you dislike it so much ? And what do you think i can propose apart from the full pcigart fallback patch that would be acceptable to you ?
<daniels> svenl: because it's an ugly hack, dude.  you do realise that there is absolutely no precedent for testing for a specific machine type and adding device-specific options?
<daniels> svenl: no-one's done this before, because it's really, really ugly.
<zul> there thats better...hey
<jdub> Riddell: amarok-gstreamer is in universe - intended?
<svenl> daniels: ok, but you suggest no alternative ? It is not my fault that pcigart fallback has been broken in X.org for ages.
<svenl> daniels: what do you think as alternative to have mentioned in the release notes that it should be added by hand ? It will not break X, just DRI accel.
<daniels> svenl: it's not my fault, either.  i'm saying that I don't like an incredibly nasty hack that no-one has ever done before, and I don't have the time to integrate the full fix.
<daniels> svenl: 'DRI is broken on Pegaos machines and whatever crazy Intel machines that provide AGP slots that aren't AGP slots.  We know.  It will probably get fixed in Bendy or something.'
<Kamion> mdz: yeah, I'll be up for ages
<daniels> svenl: dri not working is just so far down on my list of things that I consider bugs that it's not funny
<svenl> daniels: what about checking that there is no agpgart for a given hardware and setting bustype pci then ?
<daniels> svenl: given that my bug list is currently filled with 'does not work' 'hangs my machine' 'crashes and then leaves my keyboard in an unusable state'
<daniels> not 'can't watch glxgears whizzing around'
<daniels> svenl: err ... how do you propose to do that?
<svenl> daniels: the current drivers will disable dri for whatever motherboard (including x86) which has no agpgart.
<daniels> right
<daniels> i don't think this is the worst problem ever
<svenl> altough pcigart will work in these case.
<daniels> given we don't have anything to set up pcie garts, and regressing acceleration on pci (or fake agp, whatever) radeons really isn't a very bad thing
<Kamion> daniels: yeah, xserver-xfree86 has provided xserver for a long time
<kent> If i try to install Hoary with qemu (I have no free partition to play with), should i still report bugs (if found)? Or does the use of qemu make the bug reports of low value to Hoary developers?
<daniels> Kamion: oh, right.  well, -dbg should provide it also.
<svenl> nope, but maybe related to the 'my machine hangs' whenpeople force suff :)
<Kamion> daniels: it dates to xfree86v3 days, when depending on xserver made sense 'cos there were lots of them
<daniels> if you force stuff, you get to keep both pieces
<daniels> Kamion: yeah
<daniels> svenl: seriously, if you add Option "AGPFastWrite" to your configuration and your machine locks up dead, I don't care
<svenl> I will try to find time to port the pcigart-fallback patch from debian, but i can't promise nothing.
<daniels> svenl: my aim is to get 2D working absolutely out of the box for absolutely everyone.  3d acceleration is a nice bonus.
<Kamion> kent: not exceptionally high priority maybe, but the bugs are still valuable
<daniels> svenl: i doubt it's a patch from debian, it's probably just something that broke since radeon_driver has changed so much
<svenl> daniels: 2D performance is vastly improved on radeon with DRI.
<svenl> daniels: we will see.
<svenl> daniels: still, the workaround would be upto 5 lines of shell script, and d-i stuff is full of this, so it is not unprecedented.
* sivang is burning new livecd for testing.
<daniels> svenl: yes, but I have to maintain xserver-xorg, and the configuration there is unmaintainable as it is
<daniels> svenl: and yeah, I know the difference in 2D performance.  but I could spend a while making sure that all i8xx owners can actually get X started, or I could make sure that people who owned PCI Radeons or fake-AGP Radeons got every last drop of performance out of their card ... I know which I'd rather.
<pitti_> daniels: kudos, preview works great on my flatmate's widescreen laptop (it was completely b0rked about a month ago)
<daniels> pitti_: oh cool.   it might well break again after preview. :\  but we'll see.
<seb128> pitti_: around ?
<pitti_> seb128: of course :-)
<pitti_> seb128: currently installing my desktop, that's why I'm at the laptop now
<seb128> pitti_: <jody> Can you put him in contact with me
<seb128> pitti_: about the libgnomecups regression
<pitti_> seb128: oh, is that the g-cups-manager guy?
<seb128> you can query him on irc.gnome ?
<pitti_> cool
<sivang> seb128: what regression are we talking about?
<pitti_> hm, I didn't investigate this problem yet, but I'll do
<smurfix> Bah. language-support-en deps on openoffice.org-l10n-en which deps on openoffice :-/
<seb128> <pitti> the "Paper" and "Complex" register cards of the properties window are empty
<pitti_> smurfix: erm, shouldn't
<smurfix> doesn't any more
<sivang> pitti_: lemme know if I can help on those, I am alrady in contact with jody
<Kamion>  Depends: openoffice.org (>> 1.1.1+1.1.2) | language-support-en
<pitti_> Depends: openoffice.org (>> 1.1.1+1.1.2) | language-support-en
<seb128> pitti_: short story: I've said to JHM to not update in debian and he has said to jody that's broken
<pitti_> smurfix: ^ 
<pitti_> seb128: I join the channel
<seb128> ah
<sivang> hey jody :-)
<pitti_> Hi jody 
<pitti_> jody: welcome to the Ubuntu channel :-)
<jody> Good morning lads
<jody> pitti_: I here you've got problems with libgnomecups 0.30
<pitti_> jody: I /msg you
<jody> blah, 0.2.0
<smurfix> This morning the German mirror still had the old dep
<daniels> ok, i'm going back to bed; not feeling very well.
<dholbach> daniels: hope you get well soon, good night
<smurfix> daniels: take care
<pitti_> smurfix: it's like this for ages (months) now...
<smurfix> pitti_: strange
<smurfix> I'll re-check later
<smurfix> installing the package in aptitude definitely pulled in all the OOo crap
* sivang --> testing live_cd, brb
<jdub> hi jody :-)
<svenl> daniels: but the xresprobe is worth fixing if i provide you a clean patch ?
<ogra> pitti_, i mailed the link to the announcement to heise and golem shortly after we talked....
<pitti_> cool, thanks
<ogra> pitti_: but i think heise will ignore us again
<ogra> (hopefully a golem message forces them)
<sivang> bah, no network on the livecd :-( i had to enable it manually, since the /etc/netowrk/intefaces file has only loopback
<sivang> known issue?
<sivang> (i have 2 nics)
<ogra> sivang: a bit late to report that :) preview is already out
<Burgundavia> that is why it is a preview
<pitti_> sivang: worked fine for all my tests 
<sivang_livecd> pitti_: where is the bug report ? i  will reopen/add comments
<sivang_livecd> pitti_: (sorry, meaning, what is the bug number)
<pitti_> sivang_livecd: which bug report?
<ogra> <pitti_> sivang: worked fine for all my tests 
<pitti_> sivang_livecd: I checked it on five computers
<sivang_livecd> pitti_: hmmm
<sivang_livecd> pitti_: interesting
<ogra> sivang_livecd: i checked on 3 (2 arches)
<sivang_livecd> pitti_: maybe it's my crazy system
<Kamion> sivang_livecd: the live CD tries to enable the network automatically, but if it can't for whatever reason then it won't ask you questions
<Kamion> sivang_livecd: compare with the install CD and see what questions it asks
<Kamion> the process is largely the same, but the live CD forces it to be noninteractive
<mako> woot
* Keybuk wonders whether elmo has got up yet
<mako> mdz: hey.. your post needs moderation :)
<Keybuk> I had images of him psychically connected to the servers, and suddenly sitting up in bed screaming as the release went out and they started to take the strain
<pitti_> yay, another successful i386 installation
<mako> mdz: no.. it's done
<jdub> mako: :)
<sivang_livecd> pitti_: 17:00utc has passed already? :-)
<pitti> no
<pitti> it's 15:08 UTC
<sivang_livecd> pitti_: oh, so the preview hasn't been released yet right?
<pitti> not officially
<sivang_livecd> pitti_: k
<pitti> however, the images are ready
<Kamion> erm, it has
<Kamion> it went out officially a couple of hours ago
<sivang_livecd> Kamion: oops
<ogra> sivang_livecd: the announcement got out some hours ago
<pitti_> Kamion: oh, did it?
* sivang_livecd is going back to the his installed system, brb
<Kamion> yes
<Burgundavia> sivang_livecd: suggest you read the top of distrowatch
<pitti_> Kamion: I thought sabdfl told us sth. like 1800 UTC
<pitti_> hmm
<pitti_> darn
<sivang_livecd> pitti_: yes, that what i recalled from the last email of mdz
<sivang_livecd> pitti_: or on the channel
<Kamion> it was going to be 1800, but everything seemed to be ready, and sabdfl said let's do it early to catch the news in all US timezones
<sivang_livecd> Kamion: ok, then off to translating and spreading the announcment , is the draft on the wiki still applicable?
<ogra> Kamion: btw, no announcement on http://ubuntulinux.org/ ?
<pitti_> cool, so I missed the release
<pitti_> darn
<pitti_> CONGRATS EVERYBODY!!!
<ogra> heh
* pitti_ opens a bottle of champagne
<Kamion> ogra: probably should be ...
<pitti_> so why is the preview release not on the www.ubuntu.com frontpage
<Kamion> sivang_livecd: yeah, or see ubuntu-announce@ for what actually went out
<pitti_> or not even in thew news section
<ogra> pitti_: thats what i was asking :)
<Kamion> I'm not sure how the news stuff works
<Kamion> mako: around?
<Kamion> sivang_livecd: which of your NICs should have been used?
<Kamion> sivang_livecd: sorry it went out earlier than intended, we probably should have remembered to contact announcement translators
<Kamion> sivang_livecd: I've added that to our release checklist
* mvo is in town for ~2h
<sivang> Kamion: I can add news
<sivang> Kamion: (as I added the bit about arsetechnica)
<smurfix> sivang: Mind the typo
<sivang> smurfix: in the name? :-)
<zul> announcement should be on slashdot if you want alot of publicitiy
<smurfix> sivang: Yeah, "arsetechnica" looks ... slightly wrong, somehow
<sivang> smurfix: well, I don't recall if I did a type on the news bit...sorry :-/
<smurfix> sivang: The news bit looks OK
<zul> hey lamont_r
<pitti> Hi lamont_r 
<Kamion> "ars technica"
<Kamion> or maybe no space
<sivang> Kamion: nothing on u-announce, I'm afraid
<Kamion> I have it on ubuntu-announce@ here
<Kamion> http://lists.ubuntu.com/archives/ubuntu-announce/2005-March/000019.html
<sivang> Kamion: thanks, I have only the UDU there
* lamont_r downloads the install CD
<jdub> seb128: hmm, sabayon release :)
<dholbach> were on LWN.net
<seb128> jdub: yeah, I've started to package it
<jdub> heh :)
<jdub> "Administrator level permissions are needed to run this program because it can modify system files."
<jdub> ^ ber
<seb128> jdub: but I need to figure what to do with the user to add and some stuff
<smurfix> Ah, cdimage.u.c is already slowing down. :-/
<lamont_r>    559190016 100%    1.16MB/s    0:07:38  (1, 100.0% of 1)
<lamont_r> not so bad...
<smurfix> We should probably encourage people to use BitTorrent if possible ..?
<lamont_r> certainly
<smurfix> lamont_r: Where's that from? cdimage?
<lamont_r> yeag
<lamont_r> to yesterday's image - only really transferred 39MB... :-0)
<lamont_r> given that the link I'm borrowing right now is only 1.5 mbits/sec....
<jbailey> What the right bugzilla classification for bugs that affect debian but not us that got propagated to bugzilla?
<lamont_r> NOTWARTY
<pitti> jbailey: RESOLVED/NOTWARTY
<jdub> seb128: home == /var/lib/sabayon ?
<jbailey> pitti: Thanks.
<lamont_r> and one of these days, that'll get renamed to NOTUBUNTU, but probably not before hoary ...
<lamont_r> or so I've heard rumoured...
<seb128> jdub: does it need a home ?
<jdub> yeah
<mako> Kamion: yes
<ogra> lamont_r: oh, you talked to the malone guys ? :-P
<mako> Kamion: was caffienating :)
<fabbione> re
<pitti> hey fabbione, slept well?
<lamont_r> right.  livecd finished downloading.  heading home
<lamont_r> b1t3 m3!
<lamont_r> gah!
<fabbione> pitti: yeah it was really needed
<ogra> pitti, http://www.golem.de/0503/36865.html
<ogra> :-D
<fabbione> elmo: you awake?
<sivang> releases.ubuntu.com is down for some reason?
<sivang> (can't get to it)
<fabbione> sivang: probably overloaded
<maswan> sivang: I'm currently mirroring from it, so it seems to be ok.
<dholbach> ogra: wow... we have "PowerOC" ISOs as well?
<maswan> I was thinking that I should have gotten that done earlier though
<ogra> dholbach: only OC 64 yet, but they are hidden somehow....lol
<sivang> I can ping to it (64 bytes from 82.211.81.155: icmp_seq=1 ttl=49 time=86.0 ms
<sivang> but don't get a response, probably overloaded.
* pitti wants a PowerOC cpu
<maswan> in an hour or less: http://ftp.acc.umu.se/mirror/ubuntu-releases/
<thom> sivang: kicked it, thanks
* maswan heads home, back in a while
<dholbach> i'll be back later... *wave*
<sivang> thom: no, thank you :-)
<Kamion> mako: can we get something about hoary preview on www.ubuntu.com?
<sivang> argh, what is that apt-get.org doing there? :-)
<Kamion> sivang: that was Mark's addition
<Kamion> (I believe)
<ogra> i thought elmos
<Kamion> that would surprise me
<mako> Kamion: yeah, i'll do that
<Kamion> Does anyone know how to test the return value of setlocale(LC_ALL, $LANG) from shell?
<ogra> Kamion: i just remember his name mentioned in relation to it....
<Kamion> ogra: yes, that was Mark asking him if it was accurate because elmo did a lot of the imports for multiverse
<Kamion> shortly after warty released IIRC
<ogra> ah, ok
<Kamion> I suppose I could do perl -e setlocale or something
<Kamion> there's 'locale -a', but it's in an annoying form
<Kamion> and wow, no way am I going to parse the output of 'locale -av'
<thom> Kamion: wimp ;-)
<lamont> Kamion: that's almost parsable
<srbaker> anyone know of a gnome app that will let me change between wifi networks?
<srbaker> or, autosensing a la Rendesvous would be nice :)
<Mithrandir> srbaker: networkmanager or netapplet
<tseng> netapplet and networkmanager both try to fill that niche
<tseng> both fail so far
<tseng> net applet is a fair bit more usable
<srbaker> okay
<srbaker> thanks
<Kamion> lamont: if you're INSANE
<sabdfl> netapplet has some bad side effects if you have multiple wifi networks around
<lamont> Kamion: you have doubts? :-)
<sabdfl> for me, at least
<tseng> sabdfl: its not a fan of the ipw2200 drivers either
<tseng> since the dont report signal in a standard way
<Kamion> lamont: ...
* lamont is preparing to hack around his wifi world with a list of AP's that 'iwlist scan' finds, to take the first one found
<lamont> yum. new bind9 bits coming
<lamont> but not for hoary, of course./
<jdub> lamont: you mentioned postfix-tls cert love? uses ssl-cert?
<mroth> the other thing to look at in addition to GUI switching of wifi networks is something that integrates WPA support for end-users in a easy to use way
<lamont> Kamion: daily/current is the preview, yes?
<mroth> (for next release cycle, of course)
<lamont> guess I could just verify sums..
<lamont> mroth: WPA?
<mroth> lamont: wifi protected access... standard WEP replacement
<lamont> ah,ok
<maswan> So, feel fre to redirect people here if releases gets too busy: http://ftp.acc.umu.se/mirror/ubuntu-releases/
<jdub> mroth: NM is getting some of that
<jdub> might be ready for hoary+1
<mroth> that would be nice
<mroth> lot of users out there who dont want to edit a wpa_supplicant.conf file, dont blame em
<Kamion> lamont: yes
<Kamion> maswan: thanks; we need to update www.u.c/download/ somehow too
<Kamion> maswan: can you arrange for IndexIgnore in .htaccess to be permitted in that directory, so that jigit and favicon.ico don't show up?
<Tux-Rox> Any plans to try and get Beagle into 5.04?
<Kamion> not 5.04, maybe 5.10
<Tux-Rox> With a back-port repo version available, I hope! :-)
<jdub> not in main
<jdub> it may be in universe
<Kamion> ick, backports
<lamont> jdub: so how much of hoary are we gonna backport to warty, huh, huh, huh????
<sabdfl> lamont: only the gnome parts
<Kamion> we do six-month releases, any more than that is just impatient :-)
<mroth> countdown to slashdot post "omg why does hoary not have firefox 1.0.1--it is totally useless!"
<Tux-Rox> That would be nice. I've got it going now, but it does have a few issues yet. Hopefully they will get ironed out. Thx for the info!
<Kamion> mroth: hoary final probably will
<jdub> backports are vile and reprehensible :-)
<mroth> Kamion: I know that, you know that, but slashdot posters, well... ;-)
<Kamion> mroth: this is why I do not read /. :-)
<lamont> jdub: you know that, I now that... But does that stop them???
<Kamion> well, actually, it's more 'cos I once had an entire story dedicated to vilifying me
<Kamion> but that's another matter :)
<Tux-Rox> It's one thing to read /. objectively, it's quite another to post.....
<mroth> Kamion: haha, what story was that?
<jdub> lamont: the sf.net ones are stunningly broken
<jdub> lamont: have you looked at the version numbers?
<Kamion> mroth: some half-baked early-release story about Debian splitting non-free bits out of the doc-linux package
<Kamion> which I maintained at the time
<mroth> ahh
<Kamion> we didn't even do the split until a year or more later, but that didn't stop slashdo
<Kamion> t
<sivang> Kamion: the shrinkwrapped cds are like bussiness card cds?
<lamont> jdub: I ignore backports other than the ones on people.debian.org/~lamont/woody-updates
<jdub> heh
<mroth> did mako get the new shipit thing up?  i bet preview is going to generate a lot of cd orders
<lamont> sabdfl: feeling sorry over the artwork, eh?
<sabdfl> lamont: that part we can forward-port
<Kamion> sivang: no
<lamont> lol
<Kamion> sivang: we don't do netinsts or businesscards at the moment
<sivang> Kamion: ah ok, so what are "shrinkwrapped" cds? :)
<Kamion> sivang: we may do at some point, but they'll be on an "if you know about them, you can use them" kind of basis, not heavily promoted to avoid confusion with the full CDs
<Nafallo> all files disassociate their programsettings. is this a local bug?
<maswan> Kamion: Hmm... I'm not sure we have anytihng like that active at all. I'll have to check the config files.
<Kamion> sivang: "shrinkwrapped" means officially packaged
<Kamion> sivang: it's by analogy with the plastic packaging you get on all sorts of products that shrinks around the product it's wrapping
<sivang> Kamion: ah ok, thakns :)
<sivang> Kamion: ah right, with vacume used to shrink wrap ;-)
<lamont> sivang: sometimes, but not always.
<lamont> some of it truely is heat-shrinked
<lamont> shrunk.
<lamont> whatever
<lamont> thom: wanna know why you don't get /etc/aliases.db on a fresh install?
* lamont points at debootstrap
<jdub> seb128: you were chatting to carlos earlier about i18n issues - any answers for the new .desktop file translations?
<seb128> the translations are in rosetta but not in the langpacks
<Kamion> lamont: huh?
<thom> lamont: oh?
<seb128> ie: we need to merge them by hand for the moment
<jdub> yeah
<jdub> hrm
<Kamion> <cjwatson@cairhien ~/src/ubuntu/debootstrap/debootstrap-0.2.45ubuntu25>$ wcgrep aliases
<lamont> Kamion: from deep inside debootstrap somewhere, ls -l /usr/sbin/sendmail*
<Kamion> <cjwatson@cairhien ~/src/ubuntu/debootstrap/debootstrap-0.2.45ubuntu25>$
<lamont> you'll find sendmail.REAL, and sendmail -> /bin/true
<Kamion> lamont: hah, yeah, that's kind of necessary
<lamont> and newaliases is, of course, a symlink to sendmail
<Kamion> don't want it actually sending mail
<lamont> right
<maswan> Kamion: http://churchill.acc.umu.se/mirror/ubuntu-releases/
<maswan> Kamion: like that?
<Kamion> maswan: yeah
<lamont> fortunately, postalias works almost as well.
<Kamion> maswan: (this is like really minor nitpicking)
<lamont> so I don't have to detect debootstrap
<Kamion> cool
<maswan> Kamion: Ok, I'll see if I can get that propagated to the proper machines then
<Mithrandir> mako: you're on BoingBoing :)
<lamont> (postalias doesn't use $alias_database, but I _know_ what that says on a fresh install...)
<Kamion> maswan: ta
<lamont> although detecting it isn't so hard... just 'newaliases --this-is-fatal': if that succeeds, then you've been diverted.
<lamont> "american english" keyboard == pc105?
<Mithrandir> probably 104 if you have windows keys
<Mithrandir> 101 if not
<Mithrandir> iirc
<mako> Mithrandir: again?!
<mako> Mithrandir: dude, this is the second time this week!
<lamont> hrm.. maybe writing that 4x CD-R at 16x was bad...
<HiddenWolf> lol@lamont
<mako> Mithrandir: thanks for telling me :) i'm still feeling the bandwidth crunch from unhappybirthday.com :-/
<lamont> oh yeah.. wrote 454/515 MB.. :-(
<maswan> Kamion: there, all done: http://ftp.acc.umu.se/mirror/ubuntu-releases/
<maswan> Right now I'm having fun in that the gnome livecd generated about 100-200Mbit extra traffic, and the ftp mirror isn't even breathing hard. :)
<Kamion> maswan: ta
<Mithrandir> mako: about the 419 mail.
<Mithrandir> mako: you rock, but you knew that already. :)
* lamont considers ordering 1000000 hoary CD's, just to watch mako do a spit take
<pitti> lamont: wanna build a new house with them? :)
<Mithrandir> lamont: imagine what would happen if he shipped them to you.
<Keybuk> knowing Jane, she'd make sure you got them
<Keybuk> by air drop
<silbs> all in one big package
* pitti imagines the crater
<Mithrandir> lamont: or even if he cut it by a bit, but shipped you 50k
<mpt_london> A crate of them on your vege garden
* lamont notes that his hoary order _is_ smaller than his warty order...
<mako> lamont: try it
<mako> lamont: i've actually made that impossible
<mako> lamont: i am the only person who can order 100000000 cds now
<mako> lamont: you ahev to do it through mine
<Mithrandir> mako: he'll just trojan your computer
<mako> Mithrandir: well, actually, he could do it from chinstrap probably
<mako> you can only place large orders from chinstrap
* thom orders assufield a billion cds
<toresbe> I... HATE... ncurses
<mako> thom: we better get those to him quick.. i've heard rumors of increased volcacnic activity in his area
<toresbe> Why must it point out my C newbishness with such skill?
<thom> mako: i think the impact of the cds will help the volcano come to life
<Mithrandir> toresbe: it has been honed for many years.
<toresbe> This piece of code worked. I went out to the kitchen for a dinner. I return.
<toresbe> Program does not work.
<Mithrandir> it's probably an error on line 46
<toresbe> 46: main (int argc, char *argv[] ) :P
<Mithrandir> good guess, heh?
* toresbe removes main
<toresbe> Well, look! No more segfaults.
<lamont> mako: nice
<lamont> ejsy frgomrd 
<lamont> what defines 'large'
<lamont> damn keyboard
<lamont> hrm... 300 is large.
<fabbione> mako: i just updated my order for hoary.. mind to check if you get the proper DAnish chars?
<lamont> mako: will probably be re-shipping several of them to family members around the country, and then I plan to paper a school or two
<lamont> s/school/city/
<Kamion> pitti: have you done the new language packs yet, or do I have time to slip in a change?
<pitti> Kamion: already uploaded a few hours ago :-(
<pitti> Kamion: what do you want to change?
<pitti> Kamion: I can't do update packages until the dpkg bug is fixed
<Kamion> pitti: about to upload glibc with a new --keep-existing flag to locale-gen
<pitti> yay
<Kamion> I'm bored of locale-gen generating new locales all the time
<pitti> Kamion: thanks, that's great
<Kamion> or rather, locales it already has
<thom> http://popcon.ubuntu.com/ ; i hate writing html :P
<jdub> ah, give it to someone you know who loves it :)
<jdub> LAMONT! thom wants to speak to you!
<thom> jdub: thanks; i'll mail you the script
<thom> it's embedded in perl, btw
<Kamion> it's a bit RED :)
<jdub> heh
<thom> just for extra love
<jdub> golly
<Hannes_> nvu :P
<pitti> thom: erm, the white line is amd64?
<thom> Kamion: it just does what the css tells me
<jdub> thom: hey, maybe steal css from planet ubuntu
<thom> pitti: all
<jdub> thom: it routes around some plone damage
<thom> jdub: is that less damaged?
<thom> cool
<Kamion> pitti: it doesn't do removals from locale-archive, so your prerm/postrm scripts or whatever still have to run 'locale-gen' without arguments
<pitti> thom: the key to the right of the diagram has a white background, I can't read the white text on it :-/
* jdub handily routes around perl damage in the process ;)
<Kamion> pitti: and you need to depend on locales (>= 2.3.2.ds1-20ubuntu10)
<pitti> Kamion: okay, I already modify the templates, so that I don't forget about it
<jbailey> Kamion: Will that do the right thing when locales actually change?
<koke> jdub: I don't see you in #gnome, do you know what happened to gnome 2.10 spanish release notes?
<Kamion> jbailey: locales still runs locale-gen without arguments on upgrade, which will regenerate everything from scratch
<jbailey> Ah, cool.
<Kamion> it's an option for the case where you're running locale-gen multiple times in sequence without upgrading locales
<pitti> Kamion: please wait with upload
<thom> pitti: yeah
<thom> jdub: thanks, that looks better
<pitti> Kamion: the langpack just does "/usr/sbin/install-language-locales %LCODE%"
<pitti> Kamion: so you have to change this script in glibc 
<Kamion> pitti: oh, ok
<pitti> Kamion: I added this abstraction to have the script on one central place
<pitti> Kamion: did you already upload?
<Kamion> no, not yet
<pitti> cool
<Kamion> cool, no dependency needed then
<pitti> yes
<jdub> koke: they were broken when i built them
<pitti> well, at least not a new one
<jdub> koke: might've been updated, but i haven't done another run
<koke> jdub: when was that??
<pitti> Kamion: it already depends on the versions that provides install-language-locales
<Kamion> pitti: indeed
<jdub> the current release notes module layout is a bit bong
<jdub> koke: mere hours before release
<koke> murrayc updated the es.po for me after the release
<lamont> hrm.. this 5 year old media really sucks
<Kamion> pitti: whoa, install-language-locales sorts the comment at the top of /etc/locale.gen
<Kamion> pitti: I'll not fix that now; but maybe you could just remove the sort?
<lamont> especially since people might put comments right above various entries in the file, etc.
<Kamion> yeah
<mpt_london> Kamion: Please add to <http://releases.ubuntu.com/hoary/> a link to the release notes. Perhaps as the first sentence before "Ubuntu is distributed on...", something like: "This is the second major release of Ubuntu, a free operating system based on the Linux kernel. To find out what's new in this release, see the _release notes_."
<Kamion> it isn't the second major release, it's a preview of the second major release
<pitti> Kamion: which comment?
<Kamion> pitti: all of them
<Kamion> pitti: it does 'sort -u /etc/locale.gen'
<mpt_london> Kamion: sure
* pitti does not have any comments in /etc/locale.gen
<Kamion> mpt_london: but yeah; any idea where the release notes are?
<pitti> Kamion: normal #-style ones?
<Kamion> pitti: yes, locales puts some there by default
<mpt_london> Kamion: No -- that's part of th reason I'm asking for a link to them ;-)
<Kamion> hm
<Kamion> ok, in a bit :)
<pitti> Kamion: I probably removed them when I played around with this
<mpt_london> Kamion: Once I know where they are, perhaps I could help with jdub's "a bit bong" problem
<Kamion> pitti: probably not absolutely trivially fixable, so will defer
<pitti> Kamion: I see, I have to improve the the check 
<pitti> Kamion: I will send you an updated script 
<pitti> Kamion: tomorrow, probably, I still have some RL stuff to do today
<Kamion> pitti: ok. I'll do this upload now so we get the live CD speedup
<jdub> mpt_london: we were talking about the gnome release notes
<Hannes_> btw does the live cd boot from an -USB-stick?
<Kamion> Hannes_: not at the moment I think, but it would probably be possible to make it do so with a bit of hacking
<Hannes_> ok
<Kamion> casper is fairly generic at least in principle
<Kamion> but you won't be able to write it to a USB stick and have it Just Work
<Kamion> yet
<Hannes_> as it would be nice to use it from there
<Kamion> nod
<Hannes_> or could you install it there with the install-disk?
<Kamion> theoretically, but there are a number of bugs surrounding that
<Kamion> you can certainly try it though, would probably only involve some minor bootloader hacking at worst
<mpt_london> jdub: Well, with all due respect, there's lots about gnome that's a bit bong ;-)
<Kamion> easier than making the live CD boot from there :)
<Hannes_> but it would be good to have the "system check" (as in live cd) as you use it in different places
<Hannes_> Kamion: yes, i know
<fabbione> mjg59: ping?
<Kamion> Hannes_: yeah
<jdub> Kamion: ubuntu release notes haven't been officially published yet
<jdub> Kamion: mako has some autobuilt samples, but that's it
<fabbione> now that i have hibernate my machine... how do i bring it back to life?
<Hannes_> fabbione: power button on my machine
<Kamion> fabbione: switch it on
<mpt_london> jdub: What was that that was in the topic before, then? Was that just a draft?
<jdub> i don't know
<Kamion> fabbione: hibernate is "save all state to disk, tell initrd to resume from there, power off"
<fabbione> HMMMM
<fabbione> it never did a poweroff
<Hannes_> Kamion: one + with the usbstick is that you could (mabye) save to it
<fabbione> and pushing the power button has the effect of a bit of disk activity and that's it
<mako> jdub: i'm trying to find context
<mako> jdub: what i have i built?
<jdub> mako: release notes samples
<mako> userlinux stuff, etc?
<mpt_london> ah, here it is http://www.ubuntulinux.org/wiki/DraftHoaryPreviewAnnouncement
<mako> jdub: oh yes that too
<jdub> mpt_london: hoary preview is announced and shipped
<Kamion> linking to the actual archived announcement would be better than that
<doko> jdub: so it's ok upload fixes again?
<jdub> doko: yes
<travail101> any chance of getting linux-wlan-ng added to the live and install CDs?
<mpt_london> jdub: I realize that, but if it's announced and shipped, there should be release notes somewhere ...
<Kamion> doko: I just uploaded glibc, so I certainly hope so ;)
<jdub> mpt_london: the release notes are targeted for the final release
<mpt_london> oh
<jdub> mpt_london: mako will point you to in-progress samples in a moment
<travail101> yes no?
<Kamion> jdub: they're linked to from the draft announcement
<travail101> maybe?
<jdub> Kamion: don't know what i'm explaining it for then ;)
<Kamion> travail101: there's been a bit of discussion about it; is it just the userspace tools, or kernel modules as well?
<Kamion> travail101: if the latter, they should be integrated into our standard kernels instead
<Kamion> travail101: I do agree on the former, but don't know whether there's really time before our next release now
<travail101> the drivers are kernel modules...
<mako> mpt_london: i'm building the new one right now.. give it like 5 minutes
<Kamion> yeah, we require all our supported kernel modules to be in the linux-image-* or linux-restricted-modules-* packages (depending on licensing)
<mako> mpt_london: not building, but downloading and installing
<travail101> and are of course necessary for Prism2-2.5 card owners to be online with the liveCD
<fabbione> travail101: not for hoary.. they will be in hoary+1
<Kamion> travail101: right, I have a USB stick that requires them
<Kamion> I thought PCI cards worked with the standard Ubuntu kernel though
<travail101> that's what kept me from using th liveCD as my preferred rescue disk =P
<travail101> Kamion, I also have a USB stick... the D-link DWL-122
<Kamion> fabbione: hmm. actually prism2_usb is already in the kernel
<travail101> Kamion, it is?
<Kamion> see wlan-ng-prism2-usb.dpatch
<Kamion> I think it's just a matter of userspace tools
<travail101> Kamion, in the vanilla kernel, or the ubuntu kernel?
<Kamion> Ubuntu kernel
<travail101> oh
<travail101> not in worty though right?
<Kamion> $ dpkg -c /mirror/ubuntu/pool/main/l/linux-source-2.6.10/linux-image-2.6.10-4-386_2.6.10-25.1_i386.deb | grep prism2_usb
<travail101> warty..
<Kamion> -rw-r--r-- root/root     85073 2005-03-09 21:43:26 ./lib/modules/2.6.10-4-386/kernel/drivers/net/wireless/prism2/prism2_usb.ko
<Kamion> $ dpkg -c /mirror/ubuntu/pool/main/l/linux-source-2.6.8.1/linux-image-2.6.8.1-3-386_2.6.8.1-16_i386.deb | grep prism2_usb
<Kamion> -rw-r--r-- root/root     84022 2004-10-12 15:19:14 ./lib/modules/2.6.8.1-3-386/kernel/drivers/net/wireless/prism2/prism2_usb.ko
<Kamion> yes, it's in the Warty kernel
<Kamion> dunno about the live CD
<Kamion> the Warty live CD was built in a strange way, so it's hard for me to guess at exactly what's on it
<travail101> ah, well I know that modprobe prism2_usb doesn't work on it...
<travail101> and I had to use the not so elegent Knoppix to save my computer
<Kamion> I'm pretty sure I got my prism2_usb stick to work with just a Hoary install
<Kamion> and linux-wlan-ng
<Kamion> (userspace)
<Kamion> jdub: opinions on linux-wlan-ng in main for hoary? we've discussed it a few times ...
<Kamion> getting it to work in the installer would be, er, interesting at this stage, but we could at least make it workable in the installed system
<travail101> even if it doesn't automatically set it all up for you, just having it there would be nice for people who can plug in wired to their network whenever they want, or at all
<lamont> warty livecd kernel is 2.6.7+stuff - it's not my friend
<amu> heh
<travail101> but since hotplug will load the drivers, couldn't that initiated a sequence to setup the user tool/scripts and all that
<travail101> can= can't
<travail101> bad typo, bad bad typo
<koke> jdub: about gnome spanish release notes...
<koke> <murrayc> Tell him I'll do it if he wants.
<jdub> Kamion: on phone atm
<pvanhoof> I'll just copypaste it here :)
<pvanhoof>  I've rebuild the software thats available on ubuntu using qc-usb-modules in a more-correct-for-2.6.x kernels build-environment that will be more easy to package and distribute
<pvanhoof>  is this the right channel to tell packagers about it?
<pvanhoof> http://freax.be/wiki/index.php/Quickcam_Messenger_Linux_kernel_2.6_driver
<pvanhoof>  this is a small wiki about it
<pvanhoof> dholbach pvanhoof: i believe you have a better audience for kernel matters on #ubuntu-devel 
<pvanhoof> so ...
<pvanhoof> :)
<lamont> travail101: warty live doesn't use hotplug, iirc
<jdub> Kamion: off the cuff rigid and boring answer is a pretty strong "no" ;)
<travail101> well warty live doesn't even have the drivers
<travail101> so this would be for hoary live
* jdub was intending to be on the phone for a while, but now isn't. grr.
<Kamion> jdub: thought so
<jdub> Kamion: ignoring installer for the moment, does it involve any integration work, or just shipping bits?
<Kamion> jdub: afaik, just shipping; people can install it if they need it
<Kamion> jdub: ideally it'd all be there by default, but the perfect is the enemy of the good :-)
<Kamion> jdub: I can test it out with universe, though
<jdub> Kamion: anything scary about installing it by default?
<Kamion> it installs if-pre-up.d and if-pre-down.d scripts, and stuff like that; makes it not a trivially obvious "yes"
<jdub> mmmm
<travail101> still talking about linux-wlan-ng? or something else?
<Kamion> travail101: yes, linux-wlan-ng
<jdub> travail101: yeah
<travail101> it's not hard to install... set up...
<Kamion> jdub: I also suspect it's not entirely 2.6ish, but I'm not sure of my ground there
<jdub> Kamion: haven't there been maintenance woes upstream, too?
<Kamion> jdub: ah, I don't know anything about that
<travail101> ubuntu doesn't come with a setup build environment does it?
<Kamion> travail101: apt-get install build-essential
<tseng> how many cards really arent supported by prism2 now
<Kamion> tseng: USB devices are not
<tseng> or orinoco
<jdub> the big score for wlan-ng is ppc users stuck with usb wifi
<Kamion> tseng: at least, you need userspace tools to make them work
<jdub> s/ppc/apple+broadcom/
<Kamion> the 12" lot
<Kamion> (no PCMCIA on the 12" powerbook ...)
<jdub> yeah
<jdub> 2nd class machines...
<jdub> my toilet seat is still grumbling along ;)
<Kamion> really it would be better if somebody figured out how to do the linux-wlan-ng integration in a nice hotpluggish way; it's weird and complex atm
<travail101> you could check out the knoppix linux-wlan-ng stuff they even have a configuration script... but it requires human input, that could be changed though I suspect, and you could figure out dhcp for it... I still haven't tried to get my to use DHCP
<Kamion> travail101: we already have a package in universe
<Kamion> it's a question of promoting it, if it works and is supportable
<travail101> Kamion, but a downloadable package does no good without internet
<Kamion>   * New upstream prerelease (Closes: #269678)
<Kamion>  -- Bradley Bell <btb@debian.org>  Tue, 28 Sep 2004 13:42:48 -0700
<T-Bone> heya!
<Kamion> travail101: er, "promoting it" => putting it on the CD
<travail101> oh
<Kamion> travail101: you are preaching to the choir ;)
<travail101> lol
* Kamion is burning a live CD to try it out
<Kamion> boot with normal wireless PCMCIA card, download linux-wlan-ng.deb, remove normal wireless card, insert USB stick ...
<Kamion> in fact this USB stick doubles as a disk and a wireless device, so I could also put the .deb on the disk
* T-Bone notices that he's been highlighted while away, but can't figure why, it's out oh his scrollback :P
<travail101> i should learn more about scripting, and hotplug/coldplug
<travail101> how do you make the system broadcast for DHCP in the background?
<travail101> i want that in my Gentoo system...
<travail101> so it doesn't stop the boot process just to find out I'm not plugged into the LAN
<travail101> a minute later
<jdub> thom: around?
<thom> jdub: ya
<schweeb> travail101: that's more of a #ubuntu question
<jdub> thom: so the ff theme stuff, you planning to do that for 1.0.1 upload?
<travail101> is it?
<thom> which bits?
<jdub> thom: (not kill default theme, etc)
<travail101> it's... kinda a development question no... only devs should no how to set it up
<jdub> thom: (or not display default theme credits)
<thom> jdub: oh, right
<thom> yeah
<jdub> thom: so, i really think the industrial theme is better
<jdub> thom: the icons are much sexier, better coverage, etc.
<thom> i *really* don't
<thom> i'll look at using the icons
<jdub> thom: and it does use the gtk theme
<jdub> i don't get which bits you don't like
<jdub> it's basically good gtk+ theme usage and nicer icons
<jdub> it actually looks HIGgy
<lamont> pitti: btw, it's not clear on the keyboard chooser whether or not one should hit shift, stick to only unshifted keys, or what...
<pitti> lamont: right. smurfix?
<smurfix> You should hit the key which has one of the symbols displayed.
<smurfix> It'll complain about shift keys (I should probably teach it not to).
<thom> i'll try it again
<jdub> thom: let me know what is arse :-)
<lamont> pitti: oops... er. smurfix 
<smurfix> lamont: ;-)
<travail101> well apparently it's a mystery because no one ever knows how to do it... not in #ubuntu, #ubuntu-devel, #gentoo... maybe i'll try #knoppix...
* smurfix monitors his bittorrent clients
<lamont> travail101: my laptop just checks to see if it's plugged in before it tries to get an IP
<smurfix> Uploading >1 Mbit/sec right now. Cool, lots of bandwidth left here.
<lamont> iface eth0 inet dhcp
<lamont>         pre-up mii-tool eth0 | grep -q 'link ok'
<seb128> thom: around ?
<thom> seb128: my eyes are square, but the rest of me is round, yes
<travail101> lamont, hmm... well how do you do that then?
<seb128> thom: we want to quick mozilla to universe, right ?
<travail101> lamont, in a script?
<thom> seb128: i'd love to; not sure if we can for hoary
<lamont> travail101: in /etc/network/interfaces
<lamont> travail101: lets move to #ubuntu
<thom> seb128: i guess evo is the biggest blocker
<seb128> thom: looking to build evo with it
* Kamion accidentally drags a .deb onto his panel
<Kamion> I'm rather surprised that works
<thom> seb128: can't you make the ximian folk use gnutls? ;-)
<Kamion> seb128: pitti surveyed -users, we decided we'd leave it in main for hoary
<seb128> thom: the issue is that it uses heimdal-dev and firefox uses libkrb5-dev ... 
<seb128> Kamion: k
<thom> oh, cripes
<seb128> both conflict, so we need to change one ...
<seb128> any idea on which one is better to pick ?
<seb128> jbailey: here ?
<thom> seb128: none at all
<seb128> k
<seb128> jbailey has some ideas on that IIRC
<thom> i suspect changing firefox to heimdal is saner, but i really don't know
<seb128> anybody with an opinion on that ? jdub ?
<jbailey> seb128: Eh?
<seb128> jbailey: read the log :p
<seb128> jbailey: I'm sure you have an idea on that :)
<jbailey> On kerberos versus heimdal?
<seb128> yep
<jdub> seb128: no opinion here.
<jbailey> Opinion yes, raw fact based "this is the right way", no.
<Kamion> sabdfl: hooray, report on ubuntu-users that the IPW2100 kill switch was detected during install
<seb128> either way we should build evo and firefox with the same
<jbailey> My experiences with heimdal were not good, and I've deployed krb5 in alot of places.
<jbailey> debian-edu uses krb all over the place.
<jbailey> Might make the most sense to match what they have.
<seb128> k, so rather krb
<seb128> thanks
<sabdfl> Kamion: that's worth all the beer i can buy you on the 6th
<Kamion> sabdfl: ubuntu-devel, rather; http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/005379.html
<sabdfl> HE WANTS THE NEKKID PEOPLE BACK!
<Kamion> I should be careful about giving you URLs ;)
<jdub> time for jdub|tv adult edition then?
<Kamion> noooooooooo
<maswan> yay nekkid people! :)
<maswan> jdub: ass.mpeg? :)
<jdub> don't have one of those
<jdub> but i have a pantsoff.mpeg ;)
<dholbach> hehe
<jdub> www.gnome.org/~jdub/random/pantsoff.mpeg
<Kamion> oh, wow, GNOME does the one nifty-UI-thing about Windows I always liked
<maswan> jdub: oh? ass.mpeg was the name I got mmarker's ass signing. :)
<maswan> +of
<Kamion> drag from file manager into terminal, path gets pasted into terminal
<lamont> hrm... damn gstreamer
<jdub> i haven't been signed yet
<jdub> though i signed george
<jdub> Kamion: we love bling terminal crack
<maswan> well, there's a theme for the release party? or kickoff?
<jdub> Kamion: you ever used skey stuff with ssh?
<Kamion> jdub: no
<jdub> Kamion: turns out that was red hat's vpn solution for a long time
<jdub> Kamion: so g-t has a dingus clicky thing and entry dialogue for skey
<jdub> craaaaaaaack
<jbailey> seb128: <stockholm> i am useing MIT now, since it is nicely integrated with AFS, and Sam is developer in both effords and is pretty accessible and helpfull
<Kamion> jdub: geez
<jdub> every now and then someone suggests removing it
<amu> sabdfl: oh no x stuff anymore? we are planning a monthly kubuntu-calendar, something like http://www.kulma.org/linux/kde/kone.php?categ=kubuntu&kuva=konqi_together_blue.jpg
<jdub> and a thousand voices cry out in anguish
<jdub> all wearing red fedoras ;)
<jdub> amu: do it! :)
<torkel> jbailey: on the other hand arla (the other afs) works better with heimdal
<thom> jdub: have you seen Terminal.app ? File/Connect To Server/SSH -> list of servers broadcasting mdns ssh details
<jdub> amu: sabdfl mentioned those to me the other night
<Mithrandir> amu: nekkid dragons!
<seb128> jbailey: k, thanks
<sabdfl> amu: those are excellent :-)
<jdub> amu: hey, we should swap notes on how to make calendar images available for each desktop
<amu> yeah that cool stuff :) i like the idea too much  
<sivang> sabdfl: I'd love for the nakkid people to come back :)
<jdub> amu: for gnome, you just need an xml file in the right dir
<jdub> sivang: nakkid as in knackered? :)
<jbailey> torkel: There I'm just quoting why debian-edu has been going with mit.
<Riddell> jdub: and it automatically uses that background?
<sabdfl> ask jdub he has all the original images and gets to make the monthly selection
<amu> jdub: okido :) asap 3.4 is in i've little more time for those things   
<dholbach> seb128: only one balsa-old-gtkhtml-crack left on the list ;-)
<trulux> pitti: hey Martin
<trulux> pitti: how's going there?
<jbailey> torkel: Since they're probably the biggest user of kerberos in the Debian space, I'd like to match what they do in the absence of any of pulling reason to go one way or the other.
<jdub> Riddell: if you've specifically chosen the 'monthly' background, which is kind of like an alias
<jdub> amu: ok, cool
<jdub> Riddell: so if you look at ubuntu-calendar-march
<jdub> Riddell: there's two images and one xml file
<jdub> the xml file describes the images and how they're used as the background
<torkel> jbailey: I know, I was just raising my voice for the other camp :-)
<jdub> ubuntu-calendar includes one xml file, which defines the monthly calendar
<jdub> which points to symlinks
<jdub> to the current one
<seb128> dholbach: cool
<dholbach> jdub: gnome-bluetooth uploaded too
<jdub> Riddell: if we can do something similar for kde, or at least symlink them into a default backgrounds directory or something, that'd be rad.
<jdub> dholbach: awesome, thanks!
<dholbach> jdub: de rien
<jdub> we'll have to do a MOTU cheer at UDU
<dholbach> YEAH :-)
<amu> Riddell: you know basse? probably he can create a first background for kubuntu? it will rock :) 
<Riddell> amu: yep
<torkel> jbailey: both heimdal and MIT krb are borken in differnt ways, so I guess the best thing is to do a random pick between them, and if it works stay with it ;-)
<Kamion> travail101: hmm. so how am I supposed to bring this interface up again? it's hanging on DHCP here
<Riddell> jdub: how does the ubuntu-calendar.jpg symlink get made?
<jdub> Riddell: that's in ubuntu-calendar
<jbailey> torkel: Yup.  And at least just pick one. =)
<torkel> jbailey: yeah
<Riddell> jdub: ah, and ubuntu-calander gets updated each month with new symlinks and new depends.  sorted.
<travail101> Kamion, I've never tried it with DHCP
<jdub> Riddell: if i integrate the required kde changes into u-c, i can tidy up my calendar package build scripts so we can all use them
<amu> jdub: good idea
<Riddell> jdub: KDE just uses images and .desktop files in /usr/share/wallpaper
<jdub> ah yes, the universal metadata solution ;)
<travail101> Kamion, after loading the modules I run these 4 things
<travail101> wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
<travail101> wlanctl-ng wlan0 lnxreq_autojoin ssid=SMC authtype=opensystem
<travail101> ifconfig wlan0 192.168.2.110 netmask 255.255.255.0 broadcast 192.168.2.255
<travail101> route add default gw 192.168.2.1
<jdub> can you clag me one of the .desktop files?
<Kamion> travail101: DHCP isn't really relevant, no static config either
<Kamion> travail101: oh, ok, I'll try that
<jon1012> (there is an issue in the last gnome vfs update I think... :-/)
<travail101> Kamion, and of course, edit to your network... I don't know what the command line stuff is for setting a WEP key i haven't set WEP up yet on my network
<Kamion> I don't believe in WEP; anyone who wants to drive up to my house and use my network is welcome to, and if they abuse it I can go out and beat them up
<Kamion> :-)
<jon1012> (since loading of an URI into a pixbuf using either gnomeui functions or program functions (in ghtumb or appliworks) doesn't work anymore)
<Mithrandir> I tend to just block them in the router, but else same policy.  Works fine
<Riddell> jdub: http://muse.19inch.net/~jr/tmp/All-Good-People-1.jpg.desktop
<jdub> Kamion: the cops would have a field day with that one
<T-Bone> hey Mithrandir ! Wassup? :)
<Mithrandir> T-Bone: dinner. :)
<travail101> Kamion, that's very... humanitarian of you ;)
<jdub> Riddell: thansk
<travail101> share alike right
<T-Bone> Mithrandir: damn ;)
<T-Bone> Mithrandir: have a good one then :)
<jdub> Riddell: are there any other attributes, such as background colour, whether to stretch or not, etc?
<jdub> Riddell: a doc reference would be uber special
<travail101> it's less dangerous on linux networks anyway, cuz the average dude driving by wouldn't be able to screw with anything on your system... they'd just be able to surf the web and download stuff
<mdz> morning
<Kamion> aha, there it goes
<travail101> Kamion, working?
<Kamion> jdub: ok, linux-wlan-ng works, just takes a bit of hacking
<Kamion> needs better integration, but a wiki page would probably suffice for the time being
<travail101> Kamion, I added those 4 lines to my startup script supposedly their own Scripts do all that work, but they don't work for me or I just don't know how to use them
<mdz> aw, no slashdotting?
<Kamion> travail101: no can do on a live cd ;)
<sabdfl> hey mdz
<zul> mdz: its not even on the main page
<jdub> Riddell: also, does kde store the .desktop or the image as configuration?
<Riddell> jdub: how do you mean?
<travail101> Kamion, well no... a user-input script would work on a liveCD though, hotplug can load the drives, the script can tell it the IPs and turn on the device
<travail101> Kamion, a script burried out of site in either the panel menu... or even loading a console
<mdz> zul: it's not even on the linux page
<jdub> Riddell: what does the configuration setting store, a reference to the .desktop file, or to the image?
<travail101> and typing linux-wlan-ng-setup
<Kamion> travail101: much, much better to make it automatically worked when plugged in
<Riddell> jdub: oh, to the image
<Kamion> s/worked/work/
<Kamion> in this day and age there's no justification for writing a setup script but not going the extra mile and making it hotplugged
<jdub> Riddell: weird! gnome does the same thing. kinda bongtastic.
<travail101> Kamion, better yes... but you need to figure out DHCP for that
<travail101> oh you mean making the setup script automatically start?
<Riddell> jdub: I posted to xdg about a wallpaper standard but thos wasn't interested so it didn't go anywhere
<Kamion> travail101: yes
<travail101> not automatigically configure?
<Kamion> travail101: DHCP really should not be remotely hard
<Kamion> travail101: it's at a higher layer
<travail101> ah, ok, well yes do that then
<Kamion> there is no reason why static configuration should work and DHCP not
<travail101> and when you get these little scripts done, email them to me so I can use them in my Gentoo
<Kamion> I'd rather put them in Ubuntu :P
<jdub> Riddell: hrm, can't find any info about extra attributes in google; know of any docs?
<travail101> Kamion, can't you do both... Ubuntu, my inbox...
<travail101> I want them in Ubuntu live also
<Kamion> you can grab it from Ubuntu :)
<travail101> but only so I can scrap knoppix
<Kamion> I don't plan to do this particularly soon, I have many other things to do
<Riddell> jdub: what sort of extra attributes?
<jdub> Riddell: whether the image is stretched or centred, background colours, etc.
<wasabi__> So what's the word on ifplug or similar?
<Riddell> jdub: there are none, kcontrol takes a wild guess based on the image size but otherwise uses whatever the person tells it to
<wasabi__> I had heard some rumblings of using that by defaul.t
<travail101> Kamion, oh btw, the first two lines I would imagine would need to be done before try dhcp...
<Kamion> wow, this USB stick gets hot when used as wireless
<schweeb> wasabi__: I'm a fan of laptop-net myself
<Kamion> travail101: yeah
<wasabi__> And, as I sit here, waiting for my network interfaces to not configure, I am curious. ;)
<mdz> Mithrandir: how are your torrents doing?
<Kamion> travail101: but the linux-wlan-ng scripts already do those
<travail101> Kamion, so have you tried DHCP yet?
<travail101> Kamion, oh... mine dont...
<travail101> but yes these wireless sticks do get hot
<Kamion> I did, but I was a muppet and tried 'dhclient eth0' I think, which is obviously wrong
<travail101> hahaha
<travail101> good job
<Kamion> and then shut down before thinking about it
<jdub> Riddell: ok, thanks
<Kamion> booting up the live CD again now
<Mithrandir> mdz: unsure as I went home and forgot to screen them.  When I left about one hour ago, I was pushing ~1.5MB/sec
<jdub> Riddell: what are the different ImageTypes?
<Riddell> jdub: pixmap or scaleable
<_d4vid> hi all
<jdub> ala svg
<Riddell> jdub: pixmap or scalaable
<Riddell> scalable I seem to have spelt it
<jdub> why the distinction?
<Riddell> jdub: not everyone has librsvg support compiled in
<jdub> ah, so it won't show scalable;
<Riddell> jdub: if you don't have the support no
<jdub> but shouldn't the backgrounds thingy sort that out by mimetype?
<jdub> anyway
<jdub> this looks good
<jdub> i will do another -march package with the kde metadata
<jdub> for you to test
<Riddell> jdub: ubercool
<schweeb> tseng: around?
<tseng> yes
<Kamion> oh, that -march, not the gcc option
<schweeb> tseng: you pkg monodoc too?
<tseng> sortof?
<tseng> i take what the debian mono team gives me most of the time
<T-Bone> elmo: bdale just uplaoded a new version of efibootmgr, I suppose you just need to sync it into Ubuntu, or do I need to upload it separately? It fixes a bug WRT EFI specs, fwiw
<tseng> and lamont does magic voodoo to sideport it
<schweeb> tseng: monodoc-browser needs some deps added... for the gtk and glade cil pkgs
<travail101> maybe I should start making packages for other systems on my gentoo =P
<tseng> is it fixed in debian?
<tseng> do you have a fix?
<tseng> etc.
<jon1012> Just a proposal, would it be possible to make an human-like .gtkrc for gtk 1.x apps ?
<travail101> Kamion, did it work with DHCP this time?
<schweeb> tseng: I'll check debian... gimme a sec
<tseng> thanks
<lamont> tseng: what magic?  I should only have to do that to break the cyclical build-dep... which hopefully _GOES_AWAY_ once done the first time...
<tseng> yeah
<lamont> that is, if revision X can't build X+1, then it's a bug in X+1...
<tseng> well, 1.1.x will be different
<tseng> mcs + mono are one source package
<lamont> that'll helpo
<tseng> and it bootstraps itself
<travail101> Kamion, do you have your wireless setup with DHCP on your system?
<schweeb> tseng: nope, debian doesn't have those deps either
<lamont> the issue comes in when someone adds a new feature to a language, and then immediately uses it in the source that builds the binary that understands the new feature...
<schweeb> tseng: libgtk-cil libgtk2.0-cil libglade-cil libglade2.0-cil
<dholbach> is there a possibility to kick a just uploaded package? i typed 0.1.4ubuntu1 instead of 0.1-4ubuntu1 *arg*
<schweeb> unsure as to whether there's a diff between the libxxx and libxxx2.0
<lamont> dholbach: ouch
<lamont> and the answer is pretty much 'no'
* dholbach is so stupid
<schweeb> tseng: also, I'd recommend adding those as recommends or suggested on mono itself
* T-Bone notices elmo is currently away, redirects his question to Kamion / mdz
<tseng> mono suggests gtk-sharp?
* dholbach sees  0.1.4ubuntu1.really.is.0.1-4ubuntu1 before his eyes
<tseng> not really..
<jdub> Riddell: http://people.ubuntu.com/~jdub/hoary/ubuntu-calendar-march_5.03_all.deb
* dholbach bites in his desk *grmbl*
<mdz> T-Bone: if it's in Debian, it can be synched
<schweeb> tseng: makes sense to me *shrug* most people who want mono will want gtk on ubuntu...
<T-Bone> mdz: it's just been uploaded (eg 5' ago)
<T-Bone> mdz: (in debian, that is)
<Kamion> travail101: haven't quite checked yet
<Kamion> travail101: I use DHCP everywhere
<mdz> T-Bone: it can be synched once it's in the Debian archive
<tseng> schweeb: meh, so does libc6 recommend gtk+? it doesnt follow
<T-Bone> mdz: roger that. I'll poke around when that happens
<schweeb> alright, fine then
<lamont> T-Bone: and the sync is a request to elmo/jdub/mdz explaining why
<lamont> s/request/email request/
<mdz> since it's ia64-specific I wont't be picky
<T-Bone> lamont: got it
<elmo> dholbach: I removed it - but generally lamont is right, the answer is you can't
<T-Bone> mdz: i hoped so :)
<lamont> mdz: true enough
<lamont> dholbach: you owe elmo dinner
<dholbach> elmo: oh thank you very much
<T-Bone> lol, at least :)
<tseng> speaking of syncing, elmo could you please sync f-spot 0.0.10 at your convenience?
<travail101> Kamion, hmm... I might be overlooking something very obvious, but i can't get the wlan-ng scripts to do anything usefull but load the driver, which hot plug does fine
<elmo> tseng: done
<tseng> thanks :)
<seb128> elmo: poppler in NEW 
<lamont> dholbach: to put it more accurately, if you can beg/plead before cron.hourly gets to it, and elmo has time, then he can remove it with very little pain.  The issue is that cron.hourly runs every 5 minutes, and that really means you have an average of 2.5 min to run in circles, screaming and shouting
<elmo> seb128: yeah, I'm test-building all the stuff in NEW now
<schweeb> tseng: but as far as I can tell, there's no virtual package that installs the commonly used -cils that mono is generally distributed with
<lamont> once cron.hourly runs, it's much more annoying and painful
<dholbach> lamont: that's what i thought
<seb128> elmo: k, thanks
<lamont> and risky
<tseng> schweeb: they are a seperate package
<dholbach> lamont: i already had a look for a new upstream 0.1.5 version or something :-)
<tseng> why would there be a virtual, you need granular depends
<Riddell> jdub: works good
<tseng> I understand your bug, I will look at it
<T-Bone> mdz: it has just hit unstable (efibootmgr): http://packages.qa.debian.org/e/efibootmgr/news/1.html
<Riddell> jdub: going to do a new ubuntu-calendar package too?
<lamont> dholbach: yeah, it's a bitch to have to go plead with upstream for a really illogical next-version number... :-)
<tseng> as far as further changes schweeb.. not right now
<T-Bone> mdz: err no
<T-Bone> mdz: forget what i said
<dholbach> lamont: hehe... :)
<lamont> elmo: speaking of test builds..... it's past wed... :-)
* T-Bone should gets himself a new pair of eyeballs
<dholbach> lamont: and this 1:<version>-stuff looks damn ugly too
<lamont> dholbach: I loathe epocs
<schweeb> tseng: consider this situation... someone has an app that says it requires glade sharp... do a search on "glade sharp" you get nothing
<dholbach> lamont, elmo: learnt my lesson - thanks
<dholbach> ok need to run to she shop... brb
* lamont has actually had discussions with upstream wrt monotonically increasing version numbers, and why we should care... :-)
<schweeb> tseng: don't care if it makes hoary or not... just suggesting
<tseng> its in apt-cache search libglade
<schweeb> yes yes, I know that works
<tseng> if someone is building packages, or from source, they should be sufficiently clued
<tseng> or headed there fast
<tseng> its not a normal ubuntu user use case
<tseng> sorry, dont mean to argue at length about it im more interested in the real bug
<schweeb> understood
<jdub> Riddell: wasn't planning to upload these
<tseng> hey thats probably it
<tseng> Depends: for monodoc-browser doesnt roll in ${net:Depends}
<jdub> Riddell: u-c is just a variation on the theme ;)
<tseng> er, it does looking at wrong one
<Kamion> travail101: DHCP works just fine, just do 'dhclient wlan0'
<jdub> Riddell: actually, i will. in hoary only though.
<travail101> Kamion, thanx
<travail101> I'm gonna reboot at see if I can get this stuff to act the way I like it
<mjg59> fabbione: Hello?
<schweeb> tseng: I suppose I'll argue my point with you in about a month, after release...I think it'd be nice for those pkgs to at least include the name "sharp" somewhere in them, seeing as that's what most users will think to apt-cache search for, as it's the real name of the assembly
<amu> Kamion: whats about suspend with the usb-wlan on ppc? it resumes also? 
<elmo> mdz: okay to do seed syncage type stuff again?
<mdz> elmo: yeah, what's pending?
<mdz> gv was the only thing left the last time I looked
<mdz> polypaudio is probably there now
<mdz> jdub: do you have any post-preview uploads pending?  (e.g., the cursors thing)
<jdub> yep
<Kamion> ok, linux-wlan-ng works fine if I put this in /etc/network/interfaces:
<Kamion> iface wlan0 inet dhcp
<Kamion>         wireless_essid Heresy
<elmo> polypaudio-clients                        | polypaudio                      | Supported seed 
<Kamion>         wireless_mode managed
<Kamion> and then 'ifup wlan0'
<Kamion> I think we should put linux-wlan-ng in ship
<pitti> Kamion: that really works now? last time I tried it didn't; cool
<elmo> which is err, odd, since it's not
<Kamion> amu: suspend-to-ram doesn't work on the test system; I'll try it on the powerbook later
<amu> Kamion: thx, would be interessting
<mroth> has preview been slashdotted yet?
* Kamion fixes live CD performance problems when $LANG isn't in the big 11 or big 13 or whatever
<T-Bone> elmo/mdz: efibootmgr 0.5.1-1 has hit the archive.
<mdz> elmo: it's in kubuntu/supported, fixing
<mdz> mroth: no
<mroth> amazing
<mdz> elmo: fixed
<mroth> it'll be interesting to see how many downloads there are when it does
<jdub> Riddell: same url, grab both of those u-c packages
<mjg59> Gragh.
<Riddell> jdub: works good
<jdub> Riddell: cool
<koke> mvo: I've just replied your mail
<mvo> koke: thanks
<koke> mvo: you can just look at http://www.amedias.org/~koke/arch/ for koke@amedias.org--2005/gnome-app-install--mainline--0.1
<koke> I'm learning arch at last!! :)
<mvo> koke: can I just merge from it ?
<mvo> koke: ah, join the club of arch lovers ;) 
<koke> I guess that :)
<koke> base-0 is the same than Ross' branch, and there are three patches, which are the whole fix :)
<koke> ubuntu-doc $ LC_ALL=C xml2po  -o foo.pot release-notes.xml
<koke> Violacin de segmento
<koke> This is very strange
<koke> first, the error translated, and then a python script saying segmentation fault without a trace
<koke> any python guru could give me some light?? :)
<jdub> koke: are you using cvs g-d-u?
<koke> jdub: yes
<koke> it's the same with the hoary one or the cvs one
<jdub> well, that's my troubleshooting help over ;)
<koke> :D
<koke> jdub: do you know the nick of Danilo egan at irc.gnome.org?
<jdub> danilo usually, i think
<koke> hmm, then he's not online :)
<Mithrandir> T-Bone: I think you owe me beer.
<Mithrandir> T-Bone: look at nekkid:~root/lib32gcc1*deb
<HiddenWolf> ugh, pity we didn't get slashdotted
<Mithrandir> mdz: uploading new ia32-libs which should fix ooo on ia64; sounds good?
<Mithrandir> it shouldn't change anything on amd64
<mdz> Mithrandir: sure
<Kamion> hooray
<Kamion> ooo-amd64 too?
<mvo> koke: I merged your tree, thanks
<koke> great :))
<Mithrandir> Kamion: ooo-amd64 is already working.
<Kamion> Mithrandir: needs ia64 added to Architecture though I thought?
<Mithrandir> Kamion: already there.
<mdz> ooo-amd64 is already building on ia64?
<Mithrandir> mdz: ought to work fine now.
<Kamion> +Architecture: amd64
<Mithrandir> oh, sorry, I think I misunderstood
<Kamion> not in the archive yet, anyway
<Mithrandir> yeah, ooo-amd64 should build fine now, it just needs an upload with that fix.
<T-Bone> w00t!!!
* T-Bone installs and tests
<koke> are there any plans on a bazaar gui at this moment??
<T-Bone> dpkg: error processing lib32gcc1_3.4.2-2ubuntu1_ia64.deb (--install):
<T-Bone>  trying to overwrite `/lib/libgcc_s.so.1', which is also in package libgcc1
<T-Bone> Mithrandir: same player shoot again? :)
<mdz> koke: I don't thinnk so, but you can ask on #bazaar
<Mithrandir> T-Bone: heh, seems like that has to go to lib32, then
<T-Bone> Mithrandir: your call :)
<Kamion> ~/wg 25
<Kamion> oops
<travail101> Kamion, thanx, i got it working now =D
<Kamion> travail101: you missed a later comment from me
<Kamion> 19:02 < Kamion> ok, linux-wlan-ng works fine if I put this in /etc/network/interfaces:
<travail101> what was it?
<Kamion> 19:02 < Kamion> iface wlan0 inet dhcp
<Kamion> 19:02 < Kamion>         wireless_mode managed
<Kamion> 19:02 < Kamion> and then 'ifup wlan0'
<Kamion> you might have to set 'wireless_essid YOURESSID' too
<Mithrandir> T-Bone: ok, lib32gcc1 installed fine now, want to test ooo?
<travail101> hmm... I don't know where I would put that in a Gentoo system though, there is no /etc/network/
<Kamion> but basically it all works with the standard ifupdown tools with a little nudging
<Kamion> travail101: wouldn't work on Gentoo, that's a Debian-and-derivatives thing
<travail101> so do you have the LiveCD autodetecting and running DHCP now?
<Kamion> no because the package is not in the live CD
<travail101> Kamion, there's got to be an equivilent I can do
<Kamion> travail101: I neither know nor particularly care about Gentoo, sorry
<lamont> travail101: and someone in #gentoo would be able to answer that
<Kamion> I cannot help you
<travail101> yeah, I'm already asking #gentoo
<travail101> thanx for the info though
* Mithrandir floodprods T-Bone 
<Treenaks> Mithrandir: Ctrl+G him :P
<Mithrandir> I could boot his ia64 and see if he notices
<Mithrandir> or just power it down
<Treenaks> LOL
<zul> Mithrandir: power it down he wont notice it :)
<Treenaks> ping -f -b <broadcast address>
<Treenaks> he'll notice that..
<Mithrandir> his screensaver is running, though
<zul> do it...give in to peer pressure 
<Mithrandir> I'll rather just download and build ooo-amd64
* maswan hands Mithrandir a pear
<Treenaks> Mithrandir: nice -n -20 debuild -S ?
<Treenaks> uh
<Treenaks> not -S of course
<shaya> is http://archive.ubuntu.com down?
<Treenaks> shaya: no, just busy
<Mithrandir> I need to download the 213MB orig.tar.gz first
<mvo> mdz: permission to upload quagga (postinst changed permissions) and zsh (tab-completion for makefiles) ?
<elmo> shaya: use us.archive.ubuntu.com
<shaya> that works
<elmo> haggai: dude
<sabdfl> mdz: around?
<mako> mdz: it sounded like he was ready to collapse an hour or so ago
<mako> sabdfl: ^^
<mdz> mvo: yes, thanks
<T-Bone> Mithrandir: sorry, i was playing guitar and training piano :)
* T-Bone notices lib32gcc1 is installed, tries ooo
<mvo> mdz: is it ok to ask for more today? or should we rather do it tomorrow so that you can have a bit rest today?
<mdz> mvo: I will be here for some time yet, feel free to ask about anything
<sivang> jdub: yeah, naked people like you said :)
<mvo> mdz: I would like to ask for the python-apt change. it's available for review on http://people.ubuntu.com/~mvo/review/python-apt/python-apt.diff
<sivang> mdz: are we back to bug fix frenzy ? :-)
<mdz> mvo: that's fine; feel free to do a release and send me info about merging it in arch
<mvo> mdz: great thanks :)
<T-Bone> wowowowow
<mdz> sivang: we are being a bit cautious because a lot of people will be upgrading, but yes, we are fixing normal bugs again
<Mithrandir> T-Bone: does it work?
<T-Bone> all packages installed fine
<T-Bone> lessee how it *works*
* T-Bone gets all excited :)
<sivang> mdz: ok, good to know
<T-Bone> Mithrandir: what's your favorite beer?? I'll make sure to pack a full pack of it ;)
* T-Bone has oowriter OPEN AND RUNNING ON IA64!!!
<sivang> T-Bone: wow
<Mithrandir> T-Bone: it works?  Cool. :)
<Mithrandir> T-Bone: I'll grab the sources, make sure it still works correctly on amd64 and upload
<Treenaks> T-Bone: now type something :P
<zul> crashy crashy
<T-Bone> Mithrandir: cool! What about the ooffice package? It needs proper renaming i think
<T-Bone> because apt-get ooffice-amd64 on an ia64 box ain't quite logical :)
<Mithrandir> T-Bone: it's just the source package
<T-Bone> true
<HiddenWolf> T-bone: if you make it work, you get a cookie! :)
<Mithrandir> T-Bone: it's a tad slow over your DSL
<T-Bone> Mithrandir: so it's fine to let it named that way?
<Mithrandir> yeah, should be just fine
<T-Bone> Mithrandir: gotta be kidding?
* T-Bone looks what's going on
<Mithrandir> seems to work fine
<Mithrandir> AA fonts and everything
<Nafallo> I can't add backgrounds to the change background app. what should I file a bug/see if a bug is filled against?
<T-Bone> Mithrandir: i see ~13kB/s outgoing, which is 20% of what that line can do...
<Mithrandir> T-Bone: I've quit it now
<Mithrandir> it's also that X over long-distance networks suck due to latency
<T-Bone> lol, you tried to launch it remotely??:)
* T-Bone hadn't understand that :)
<T-Bone> s/and/ood/
<Mithrandir> yeah, worked just fine
<Mithrandir> 'cept it was dog slow
* HiddenWolf looks at all the patches flowing in after the freeze. -> glad to see the lull in updates is over, his broadband was feeling empty inside
<T-Bone> Mithrandir: that's quite strange, i've been running remote XoverSSH from many machines on my network to the outside and it worked fine. Must be your link sucking :)
<T-Bone> anyway
<T-Bone> Mithrandir: so you upload ia32-libs, and I prepare something for ooffice-amd64?
<Mithrandir> T-Bone: latency's usually the killer.
<T-Bone> heh
<Mithrandir> T-Bone: I wonder if OOO-amd64 should possibly be updated to the latest i386 version
<T-Bone> i'm stuck to 30ms per DSL design
<T-Bone> Mithrandir: no clue
<T-Bone> Mithrandir: it's actually a freakin good news that it works
<T-Bone> i'll roll up something asap so that kamion can sort out the seed stuff.
<T-Bone> i'll check if it fixes the firefox locales bug as well
<T-Bone> this is *just* awesome, you quite unblocked me :)
<Mithrandir> 6762 could be fixed, I think.
<T-Bone> Mithrandir: ok, i'll look in a short while. But first... Dinner! :)
<T-Bone> brb
<Nafallo> aha. my error seems to be #5266, never mind.
* HiddenWolf has a feeling that the ubuntu servers are overloaded atm
<Seveas> HiddenWolf, serious? ;)
<Treenaks> no way!
<daniels> svenl: yes, xresprobe is worth fixing
<HiddenWolf> it'd be amusing to keep stats on the server/bandwith load, and make em available somewhere. :)
<T-Bone> sososo, let's look at this ooo-amd64-ia64 package, and this firefox issue
<Mithrandir> T-Bone: still syncing down here
<T-Bone> Mithrandir: ok np. I'm testing install language-support-en right now
<T-Bone> hmm so firefox still segfaults anyway
<T-Bone> sigh
<sivang> development meeting is stil tommorow right?
<zul> yes
<Mithrandir> uhm?  When tomorrow?
<zul> as far as i know
<sivang> Mithrandir: yes
<sivang> Mithrandir: 1700UTC
<T-Bone> arg
<sivang> Mithrandir: I was just making sure it's still the same time and date :)
* T-Bone will try to be here
<Mithrandir> urf; URL?
<sivang> Mithrandir: http://ubuntuforums.org/showthread.php?t=18122
<Mithrandir> hm, ok
* sivang --> off for the night
<sivang> night all
<T-Bone>  trying to overwrite `/usr/share/locale-langpack/en_CA/LC_MESSAGES/gnome-panel-2.0.mo', which is also in package language-pack-en
* T-Bone wonders why he gets that though he just apt-get update'd
<elmo> iz dpkg bug
<elmo> see ml
<T-Bone> ah yes. I've too quick at reading, didn't notice the upload *just* happened
<T-Bone> +been
<T-Bone> Mithrandir: wanna handle new ooo-amd64 upload? Basically all i did was adding ia64 to target archs
<Mithrandir> sure, I'll do that
<T-Bone> awesome
<mdz> Kamion: around?
<T-Bone> Mithrandir: i suppose you might want to get these changes into Debian, assuming they apply... Or else, Ubuntu will be the only one having ooo working on ia64 ;)
* T-Bone will advertise that status update
<T-Bone> Mithrandir: any ETA for new packages availability (so that I can mention that in my email)?
<Mithrandir> T-Bone: I'm waiting for bdale to say _anything_ about my ia32-libs package.
<T-Bone> ah
<T-Bone> hmm
<Mithrandir> I told him about it like four months ago
<T-Bone> lemme poke him right now :)
<Mithrandir> and asked if he wanted to take it.
<Mithrandir> I could NMU if he prefers that
<Mithrandir> I would prefer not to take over the package and comaintainership would be a bit silly, but I'm open to suggestions
<T-Bone> Mithrandir: roger. Trying to get in touch with him, hold on
* T-Bone updates wiki
<T-Bone> Mithrandir: otherwise, any ETA? Do you plan to upload today/tomorrow for instance?
<T-Bone> (in ubuntu, that is)
<Mithrandir> T-Bone: ia32-libs: today, ooo?  Tonight/morrow, I gues
<Mithrandir> +s
<T-Bone> awesome
<T-Bone> so now, we have to kill that firefox bugs
<T-Bone> trouble is, i haven't been able to reproduce on debian, though I could reproduce with debian debs on Ubuntu
* T-Bone wonders what could be the cause of such a strange thing
<zul> later
<Kamion> mdz: yo. about to go out though, was writing very lengthy e-mail
<mdz> Kamion: was going to ask you about that non-ascii-characters-in-fullname/username issue, since someone mentioned somethig similar in reference to preview, though I thought we had fixed it
<mdz> Kamion: not urgent
<Kamion> mdz: hm, could be that non-ASCII characters in the full name still break some things, I don't know
<Kamion> mdz: people can still try to enter non-ASCII characters in the username; it's not presented to them by default in the installer, and the installer will reject it if they try
<T-Bone> mdz: re 7155, looking at config help I see:
<T-Bone>  If you are unsure how to answer this question, answer N.
<mdz> Kamion: the report on u-d was very vague; I asked for clarification
<T-Bone> CONFIG_SECURITY_NETWORK is a bool, can't be made module...
<lamont> Kamion: wasn't it C!=UTF8 for at least part of the issue>
<T-Bone> now it's true CONFIG_SECURITY is also recommended "No" as well
<Kamion> lamont: installer *should* be C.UTF-8 ...
<lamont> yeah, but post-boot?  what does getty get?
<Kamion> lamont: except maybe it doesn't set a valid locale for second-stage stuff that's pulled back to the first stage, which may not help
<Kamion> lamont: dunno, I thought it was whatever's in /etc/environment but could be wrong
<lamont> yeah -dunno here either
<Kamion> lamont: 'sudo ps axew' suggests getty doesn't get LANG or LC_*
<lamont> and therefore ==C?
<Kamion> yep
<Kamion> but since non-ASCII characters in usernames are rejected ...
<Kamion> I guess non-ASCII stuff in passwords might cause problems
<lamont> anywhere that crosses the UTF-8/non-UTF-8 boundary is going to have issues, yes>?
<Mithrandir> lamont: oh, the joy.
<lamont> anyway, off to fetch the child from school, and hit the store for some CD-R media, etc.
<lamont> back in about 1-2 hours or so
* T-Bone points Mithrandir at the other window
<dholbach> is david sedeo in here?
<Mithrandir> lamont: when you come back -- I have some ideas, possibly crackful, for util-linux.
<Mithrandir> lamont: if you could prod me when you're around and have a little time, I'd appreciate.
* ogra was only five hours away......and finds more then 100 mails in his inbox..... *sighs*
<sivang> ogra: how many mls are you subscribed to?
<sivang> ogra: u-d hasn't seen so much emails since I think :)
<ogra> sivang: u-d = 45, u-u = 50
<Kamion> mdz: it sounds to me as if he's complaining that non-ASCII characters in usernames are rejected, to which I say "good, although we could possibly improve the documentation"
<sivang> ogra: eh :)
<ogra> sivang: but i'm also subscribed to a lot more non ubuntu stuff....
<sivang> ogra: I see
<GheRivero> res
* ogra blows a big (very loud) horn
<ogra> did anyone recognize that dholbach uploaded more then 100 packages already ?
<tseng> I did not
<dholbach> *blush*
<tseng> but in that case.
* tseng gives dholbach a cookie
<mvo> cheers to dholbach 
<dholbach> woohoo :-)
* ogra thinks dholbach should be alled seb129 :)
<ogra> called even
<sivang> night all
<dholbach> bye sivan!
<ajmitch> good work, dholbach  :)
<dholbach> thanks ajmitch :-)
<T-Bone> Mithrandir: don't forget to close bugreports btw :)
<GheRivero> hi! is anyone taking care of NFSv4  and kerberos stuff? which is the state of it?
<T-Bone> thom: ?
<T-Bone> Program received signal SIGSEGV, Segmentation fault.
<T-Bone> [Switching to Thread 2305843009238620048 (LWP 19157)] 
<T-Bone> 0x2000000000136001 in js_strlen () from /usr/lib/mozilla-firefox/libmozjs.so
<T-Bone> that's what causing the firefox segfault
<tseng> pitti: busy?
<pitti> tseng: just with real-life issues
<pitti> tseng: what's up?
<tseng> pitti: im brainstorming with a bunch of people on hardened ubuntu .. pax atm
<tseng> and we're thinking that using softmode might make sense for ubuntu
<tseng> are you familiar with it?
<pitti> tseng: yes, I built the -hardened kernels :-)
<tseng> heh I know
<pitti> tseng: but I don't really like the softmode, it spoils all the fun :-)
<tseng> I havent looked at their config admitedly
<tseng> well, I like having a hardmode kernel available
<tseng> but we could sanely give softmode to everyone
<tseng> or a larger population
<tseng> and start marking daemons noexec
<tseng> also, using PT_GNU_STACK will give us compatiblity with ES if we are forced to replace PaX
<mdz> elmo: still around?
<tseng> and avoid binutils patching to get PT_PAX_FLAGS markings for paxctl
<pitti> tseng: so far I avoided binutils patching, yes
<tseng> chpax works.. but its a deprecated hack
<pitti> tseng: instead I created a linux-hardened-support package which calls chpax every now and then
<tseng> so proper support means PT_GNU_STACK or PT_PAX_FLAGS
<pitti> tseng: i. e. at kernel installation and X installation
<pitti> tseng: right, but binutils patching is too intrusive
<tseng> I'll have to look at it
<tseng> pitti: which is why im thinking of advocating pt_gnu
<tseng> and marking in debian/rules
<pitti> tseng: btw, right now there are no hardened kernels, I removed them because they have this hole
<tseng> right, I noticed that
<pitti> tseng: and I still did not find the way to produce 2.6.11 images
<tseng> I have a 2.6.11 tree in gentoo, but yeah.. for ubuntu will be hoary+1
<tseng> thanks for your vote, ill keep hasing things out
<dilinger> tseng: what's your name?
<tseng> dilinger: Brandon Hale
<dilinger> ah, ok
<dilinger> i was just curious if you were one of the gentoo people i worked w/ on 2.6.10-as stuff.  guess not.
<tseng> was it Adam Mondl?
<tseng> or Daniel Drake
<dilinger> daniel drake
* tseng nods
<tseng> I was using -as in my patchset, but there was a recurring buglet with selinux build
<tseng> do you recall the ipv6 socket fix?
<tseng> selinux assumes socket has ipv6 bits
<tseng> seems fixed in 2.6.11
<dilinger> a few
<dilinger> there were a lot of ipv6 fixes that i skimmed over 'cause they were rather large, and i'm not all that interested in ipv6 yet
<dilinger> skimmed over and ignored, that is
<tseng> would be nice if 2.6.x.y project was more agressive
<tseng> at this point im tracking that, -as, and -ac
<dilinger> i started 2.6.11-as last night
<tseng> =/
<dilinger> already 6 patches on top of 2.6.11.2
<dilinger> i'm going to try and feed them to gregkh, and see what happens
<tseng> -ac mentioned a missed secuirty patch.. and I have one more in gentoo that was never picked up
<tseng> ill post and see if you are familiar with it
<dilinger> i've briefly looked at -ac, but i'm trying to get 2.6.10 wrapped up, first
<tseng> http://dev.gentoo.org/~tseng/kernel/1150_sunrpc-nfsacl.patch
* dilinger is synching -as4 through -as7 w/ debian's 2.6.10.  i shouldn't have put it off for so long
<tseng> summary is remote DoS in nfsacl
<dilinger> hrm.  i hadn't see that
<tseng> http://acl.bestbits.at/pipermail/acl-devel/2005-January/001816.html
<tseng> stuff is still falling through the cracks =/
<dilinger> alright, thanks.  any idea if -mm has it?
<tseng> will look
<tseng> nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch
<tseng>   nfsacl: Return -ENOSYS for RPC programs that are unavailable
<dilinger> he's usually very receptive to patches; i find that to be the best way to get my stuff in
<tseng> hm thats not it
<dilinger> also, there's apparently a security@ address now, although i haven't used it yet
<tseng> theres a bunch of nfsacl patches
<tseng> none sound that promising
<tseng> fom -ac:
<tseng> Security
<tseng> o	AF_ROSE security hole fix - still missing from base
<tseng> o	Bridge failure to check kmalloc argument overflow
<tseng> also, he doesnt document anything from vendor-sec
<elmo> mdz: yes
* T-Bone calls it a night
#ubuntu-devel 2005-03-22
<svenl> daniels: ok, tomorrow i will forward you a patch, i have been thinking about it and it should be trivial to fix, if minifind is smart enough.
<pitti> doko: you don't like postinst scripts any more? :-)
* pitti wonders about doko's postinst removal rage 
<ogra> pitti: at least he broke his naming scheme...there is grep in the list....without any zope prefix :)
<doko> I do hate debconf ...
* dholbach comforts doko
* koke falling asleep...
<pitti> good night everybody
<ogra> night pitti 
<ndim> Hi. lifeless asked me to join.
<ndim> I'm libexif upstream maintainer, number two on the "project admin" list on http://sourceforge.net/projects/libexif
<dholbach> hi ndim 
<lifeless> so ndim was surprised that he hadn't heard about a recent security related update we did
<ndim> Yes, I was a little surprised that I had to read about the advisory in the regular news :-)
<lifeless> and I don't know the details of the security-update-handling policy. I'm hoping someone can clarify what ndim should expect to happen ...
<lifeless> as hes upstream.
<daniels> generally, vulnerabilities are reported to the vendor-sec list, which is a collection of security teams from various vendors
<daniels> vendor-sec then co-ordinates disclosure and everyone agrees on an embargo date, and CAN numbers are assigned
<daniels> sometimes they forget that upstream won't always be aware
<ndim> OK, that happens.
<daniels> in any case, we don't unilaterally issue security updates
<ndim> Would you mind to Bcc the XXX-devel mailing list for future advisories?
<daniels> future ubuntu advisories?
<ndim> If you're publishing the advisory anyway...
<daniels> (i don't handle security for ubuntu)
<lifeless> ndim: so when the advisory is sent, copy to upstream ?
<ndim> lifeless: Exactly. I know that coordinating on vendor-sec and stuff may get hectic, and getting the maintainer into the loop may be complicated/time consuming/whatever.
<lifeless> that sounds reasonable to me... daniels whats the right way to get this to be de rigeur ?
<ndim> Ideally, the maintainer would be included in that process, but at least in the libexif case, coordinating on vendor-sec was the better decision.
<mdz> ndim: it's not always obvious where the advisory would be sent, and it would be a lot of work to collect contact addresses for the thousands of upstreams we have
<lifeless> ok, mdz's here...
<mdz> ndim: iirc, in the libexif case, it was a bug reported to our bugzilla
<mkp> in general vendor-sec notifies the upstream maintainer if there's an obvious one
* lifeless passes de buck to mdz
<ndim> lifeless: Thx :-)
<mkp> sending to a -devel list defeats the purpose of having vendor-sec closed
<ndim> mkp: Right. I'm not complaining about not being included in the vendor-sec stage of the thing. That is a separate problem.
<mdz> ndim: we are going to do that work anyway, eventually, but we don't have the data yet
<mdz> ndim: once we do, it should be a straightforward matter to do what you want (allow you to subscribe to Ubuntu activity regarding your software)
<ndim> mdz: Shouldn't you have the mail address in /usr/share/doc/PACKAGE/copyright ?
<mdz> ndim: no, there is no such requirement
<ndim> mdz: OK.
<mdz> ndim: it's definitely true that in general, open source security process could use some improvement
<ndim> mdz: I'm not trying to raise a stink, or anything.
<mdz> ndim: but it's a complex issue and will require time and effort to get to a point where things are happening the way that we all would like
<ndim> mdz: If it is not too much work to get the right address, a Bcc of the advisory would be appreciated. That's all.
<mdz> ndim: you can tell Martin Pitt that, he releases our security advisories
<lifeless> is there somewhere the address could be put, that we would generally look (even if its not mandated by policy) ?
<mdz> ndim: however, I think it would be a burden on him to try to keep track of the notification preferences for our upstreams
<mdz> lifeless: yes, the copyright file
<mdz> but the information is often not there in the first place and becomes out of date
<lifeless> yah
<lifeless> and in fact the copyright file for libexif doesn't list the list.
<lifeless>   Lutz Mller <urc8@rz.uni-karlsruhe.de>
<lifeless>   Curtis Galloway <curtisg@users.sourceforge.net>
<lifeless> ndim: are you either of those guys ?
<mdz> --- [ndim]  ([U2FsdGVkX@helena.bawue.de) : Hans Ulrich Niedermann
<mdz> apparently not
<mdz> so even if we had a policy of checking the copyright file and notifying the upstream(s) listed there (which I'm sure would displease at least some upstreams), we wouldn't have found you this time :-/
<ndim> No, I'm not.
<mdz> ndim: at any rate, it would be much better to contact you _before_ we release the advisory
<ndim> I'd have supposed that coordinating on vendor-sec, checking upstream for patches and stuff is so much work that finding out the -devel list wouldn't be much additional work. :-)
<mdz> coordinating with the huge number of distinct projects is one of the greatest challenges in working on a distribution
<ndim> mdz: That assumes that the maintainer is as available as you guys are. But a lot of OS projects are maintained by people who may be away for a week or two, so I wouldn't count on that.
<mdz> ndim: it doesn't assume much; I think it would always be at least as good (and often better) to contact upstream earlier, so that they can be involved in reviewing the fixes
<mdz> ndim: are you sure that no one was contacted?  typically upstreams receive notification from _somebody_, even if there's no formal process involved
<mdz> ndim: perhaps one of the people listed above?
<mdz> doko: ping?
<doko> pong
<ndim> mdz: I'll have to ask Lutz whether he got something. Curtis is dead for all practical matters :-)
<ndim> I'll submit a bug report regarding the copyright file.
<mdz> doko: can you do some investigation into the oo.o2 java issue for tomorrow's development meeting?
<mdz> doko: we will discuss there how we can get oo.o2 into good shape
<ogra> ndim: you could also come around again and ask pitti yourself, he is here regulary during german office hours
<ndim> mdz: Right, theoretically, coordinating with the upstream maintainer before publishing the advisor makes sense. Just don't count on upstream maintainers being available within a reasonable timeframe.
<ndim> ogra: Hehe. I'm in .de as well, I'll do that.
<ogra> ndim: i know, saw your dns entry above, gruss aus der eifel ;)
<doko> mdz: didn't realize about the dev-meeting tomorrow ... currently working on oo.o1, not .o2. I'm at Cebit tomorrow. I'll check now.
<mdz> ndim: I've added some notes to the list to discuss at our next Ubuntu conference, we'll work on forging a formal process for working with upstreams on security issues and other bugs
<mdz> doko: I emailed -devel a week ago to announce it
<ndim> mdz: Nice, thank you. Summarizing my point: Don't count on upstream devs reacting fast, but please Bcc them with the advisory when possible.
<doko> ok, I'll have to find an access point at Cebit :-)
<doko> mdz: I'll look at it now, I can talk to Chris tomorrow, he's in Hannover as well.
* ogra gets homesick reading hannover everywhere :/
<ndim> ogra: Bah. Flat boring countryside. Horrible. :-)
<ogra> ndim: yup, but still, i'm born there and spent my first 25 years there......
<daniels> 00:09 < The-Ghost|afk> "bash: sudu: command not found"  ????????????????????????????????????????????+
<ogra> heh
<ndim> sudu? Sounds like science fiction character.
* daniels kicks his mouse.
<daniels> The one downside to this laptop is that the middle mouse button is right below the spacebar, so I accidentally twap it every now and then.
<ndim> thinkpad?
<daniels> yeah
<ndim> You can adapt to that. Or rather, I have, at least.
<ogra> daniels, i have something better here (bit older tho)
<ogra> <ShadeofGrey> krism: sure! but the winner of the arstechnica distribution of the year award shouldnt require backups period
<lamont> Mithrandir: moo
<jdub> doko: sweet baby jebus!
<jdub> zope me harder!
<zenwhen> O;
<zenwhen> tomboy is broken
<zenwhen> L(
<tseng> define broken
<schweeb> daniels: the trackpad on my laptop occasionally loses sync, and middle click pastes for me... not to fun when I'm in IRC a lot
<zenwhen> it wont start for me
<jdub> i think zope killed doko :|
<zenwhen> It simply says All Done! and exits
<tseng> well then
<tseng> you need to a) add the applet, b) do --tray-icon
<zenwhen> oh
<tseng> its been that way for months, actually
<zenwhen> I havent updated it for months
<ajmitch> jdub: that many uploads has to do something to a person
<zenwhen> :P
<zenwhen> its nice tho
<jdub> ajmitch: gnome hasn't killed seb128 yet ;)
<ajmitch> true, but do you really think he's still the same?
<dholbach> good night everyone
<ajmitch> bye dholbach 
<dholbach> *wave*
<zul> hey
<tseng> hi zul 
<zul> hey tseng
<enrico> jdub: if you're around, could you please add me to the moderators of the ubuntu-doc list?
<jdub> sure
<jdub> admin or moderator?
<enrico> admin even would be fine
<enrico> hornbeck said he would do it, but then I heard nothing
<ogra> why the hell is nautilus opening every svg in mozilla by default, grrrr
<jdub> enrico: preferred email?
<enrico> jdub: enrico@enricozini.org
* Amaranth brb
<Amaranth> whoops
<ndim> mdz: If you're gathering package contact addresses... another place where to find a developer mail address in a source package is the third parameter of a new-syntax AC_INIT() statement in configure.{ac,in}. (This just sprang into my mind; it may prove useful somewhere.)
<daniels> ndim: that one's often neglected
<ndim> daniels: Maybe, but it's a simple place for a script to look for.
<daniels> right, but a misleading address is even worse than none at all
<robertj> the new wallpaper is very progenyish...
<ndim> daniels: If you want to contact the maintainer before the bug goes public. If you're just looking for possible Bcc adresses to send the advisory to, that address should work well (if present).
<ndim> Well, it was just an idea to think about.
<ndim> Otherwise... perhaps a standard like .lsm files contain adequated addresses, or a new standard for security management has to be created.
* lamont thinks that tonight might be the night I pay for staying up too late last night
<schweeb> lamont: all day every day is when I pay, heh... always tired
<mdz> robertj: oh?  I haven't seen their background(s).  the Hoary preview background is an original creation, of course
<zul> mdz: the ubuntuhardened kernel stuff im reading in the wiki is going to be kept seperate from what we have now correct?
<robertj> mdz: yeah, It's been a while, but i have a Progeny box around here somewhere and their logo was kinda bubbly and galaxy-like
<robertj> http://www.gudanglinux.or.id/gambar/progencybox100.jpg
<daniels> http://overclockix.octeams.com/snapshot21.jpg
<daniels> that's some serious rice there
<zul> a little busy
<zul> thats a pretty old screenshot 
<zul> gkrelm says kernel 2.6.1
<lamont> daniels: heh
<mdz> zul: I haven't given it much thought, but it probably makes most sense for it to live in universe as a separate package
<zul> mdz: yeah since there is a linux-hardened already in universe
<mdz> zul: oh, there is?  I didn't realize
<zul> yeah i think pitti is maintaining it
<zul> or trying to
<zul> anyways im heading to bed...night folks
<lamont> night zul
<fabbione> morning
<mdz> fabbione: morning
<fabbione> hey mdz
<mdz> fabbione: are you ready to start the hoary kernel bug review? :-)
<fabbione> mdz: i am already doing it
<mdz> oh, I did not see traffic from you on ubuntu-bugs
<fabbione> no because i am not writing in the bugs yet
<lifeless> fabbione: did we end up putting fuse in the stock kernel ?
<lifeless> fabbione: your patch worked perfectly.
<fabbione> no because fuse is an external package.
<fabbione> it's the external package that needs to be fixed
<fabbione> not the kernel :)
<fabbione> fuse -> universe -> unsupported -> if i will ever have the time :-)
<lifeless> fuse-source is external, but I think the module is in the morton tree these days
<lifeless> can I help?
<fabbione> i dunno about -mm
<fabbione> lifeless: just send me the patch again for the fuse source and i will upload it
<fabbione> we can't add stuff at 3 weeks from release
<lifeless> heh. the one in your p.u.c site ?
<fabbione> not for hoary atleast
<fabbione> is it still there?
<fabbione> oh yeah
<fabbione> i can do that :)
<lifeless> it was that + a control tweak
<lifeless> one second
<fabbione> lifeless: yeah i know the control tweaks ;)
<fabbione> mdz: do i have green light to upload fuse?
<lifeless> yeah, just the kernel->linux in the .in
<fabbione> mdz: it's a trivial bugfix
<crimsun> (what version of fuse?)
<fabbione> 1.3
<crimsun> ah, thanks
<lifeless> mdz: it lets the bazaar-fuse module work :)
<fabbione> lifeless: i can't find the .in file you are talking about
<lifeless> might be just control then
<lifeless> I just grepped kernel-image in debian/
<fabbione> Recommends: dpkg-dev, kernel-package
<fabbione> is that in the modules/fuse ?
<fabbione> AHH
<fabbione> yes
<fabbione> found it
<fabbione> lifeless: it's up
<fabbione> let me know if it works
<mdz> fabbione: fuse is in universe, sure
<mdz> sleep now
<daniels> mdz: g'night
<lifeless> thanks
<fabbione> mdz: good night... btw please read the scroolback on u-k
<fabbione> mdz: about that ABI check thingy
<dilinger> abi check thingy?
<fabbione> dilinger: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-kernel-2005-03-10.html
<fabbione> dilinger: 04:45 ~
<dilinger> hm
<fabbione> lifeless: Accepted fuse 1.3-1ubuntu1 
<fabbione> daniels: did you ever get around to check xinerama & xv ?
<daniels> let me try now, my amd64's been offline for a bit
<fabbione> ok
<daniels> oh, frig
<daniels> now I know why I didn't try it earlier
<daniels> actually, no, I can play DVDs; nevermind
<fabbione> i can reproduce it with anything i play
<fabbione> even an evi
<fabbione> avi
<fabbione> or mpeh
<fabbione> mpeG
<daniels> yeah, but I don't have codecs for that on amd64
<fabbione> they are all Horiz doubled
<daniels> gotta dig out a DVD
<fabbione> if you want i have very old avi around
<fabbione> that shouldn't need any codec
<fabbione> or at least the new ones
<fabbione> come on halley! FLY
<fabbione> jdub: ?
<jdub> yo
<fabbione> jdub: permission to upload new kernel
<jdub> anything interesting beyond fixes discussed during preview meltdown?
<fabbione> yes.. 
<fabbione> faster build system, some fixes, new idiotify patch...
<jdub> ha ha
* jdub spanks fabbione 
<amu> moin
<jdub> fabbione: ok
<jdub> hey amu
<fabbione> jdub: ok thanks
<jdub> amu: people.ubuntu.com/~jdub/hoary/
<jdub> amu: grab the ubuntu-calendar packages there
<jdub> amu: peek at the kde backgrounds dialogue ;)
<amu> hey jdub 
<amu> jdub: lemme try :)
<amu> jdub: looks good, you didnt got those cool dragons yet?
<jdub> heh, no, just did it for the ubuntu calendars for now
<jdub> next step is to clean up the build system so we can use it for kubuntu and ubuntu calendars -> and more!
<amu> Ah it is linked to the x releated :)    
<pitti> Morning
<fabbione> hey pitti
<jdub> yo pitti 
<pitti> fabbione: now that the preview is done, time for some photos? :-)
<amu> arg related even 
<pitti> fabbione: -> "galapagos preview"
<pitti> Hi amu
<amu> hi pitti 
<fabbione> pitti: MEH! you did send me enough pile of dildo's that i need to work on
<pitti> fabbione: but I already sorted, described, and named all the patches *sigh*
<fabbione> pitti: they still need to be applied, compiled and tested....
<pitti> sure
<fabbione> anyway i am going out with 26 today to test other changes
<fabbione> all your stuff is for 27
<pitti> oh
<pitti> ah, there will be another kernel?
<fabbione> pitti: 2 or 3 probably before final
<pitti> fabbione: I have an USB WLAN adapter here which uses an Atmel chipset, but is not recognized by default
<fabbione> i did change some stuff in the build system that will allow us to build in less than 2384783743874837 hours
<pitti> fabbione: yesterday I managed to compile an external driver with a little patching
<pitti> fabbione: so today I wanted to try to write a little patch for the Ubuntu kernel to make it work
<pitti> fabbione: hey cool, how is this possible to build faster?
<Treenaks> pitti: optimize gcc ?
<pitti> Treenaks: -O0 ?
<fabbione> pitti: killing all the patch madness and actually forking the kernel build on SMP
<pitti> "patch madness"?
<fabbione> pitti: all the patch/unpatch at the beginning
<pitti> fabbione: I thought the main reason why it takes so long is that we build all modules for n platforms
<pitti> fabbione: hm, I never felt that the patching takes a considerable part of the build time
<fabbione> when you have over 20 revisions.. it takes AGES
<pitti> fabbione: but if it's faster, so much the better :-)
<fabbione> pitti: and the fork on SMP will solve the module problems
<fabbione> up to the point where we hit I/O bottleneck (ccache
<pitti> nice
<amu> someone knows about libsem-dev isnt it a hurd-only package?  
<YokoZar> Hey, I need to get a package removed from Universe.  Who can do that?
<amu> YokoZar: elmo is the right guy for it
<dholbach> hellas!
<YokoZar> Is he around ever?
<YokoZar> Or do I need to wake up way too early? ;)
<jdub> YokoZar: he is on UK time, so should be around soonish
<amu> just ask 
<jdub> YokoZar: probably best to mail ubuntu-devel and cc elmo
<YokoZar> Thanks.  What's his email?
<jdub> james.troup@ubuntu.com
<dholbach> does anyone of you have trouble with his screen turning black after like 15 seconds (and no it's not the screensaver setting - they're reasonable)
<Treenaks> what kind of video chip?
<dholbach> nvidia
<Treenaks> there you have it :)
<fabbione> yes i did
<fabbione> it's random
<fabbione> and i couldn't track it
<fabbione> + i am never away more than 10 secs
<dholbach> hehe
<fabbione> ADDICTION
<dholbach> seems to be the solution
<dholbach> work harder
<dholbach> yesterday it didnt go black too :-)
* dholbach rocks
<dholbach> fabbione: i mean it's nice to have a system that's so worried about my monitor's state... but i have the feeling something was wrong
<amu> ;) 
<fabbione> it is wrong
<dholbach> :-)
<fabbione> but the solution is just to keep moving the mouse
<fabbione> look at the bright side
<fabbione> your hand will be extremely trained
<fabbione> and it will stay warm
<dholbach> hahaha
<fabbione> and due to no blank screen.. you can also get a very good amount of extra radiations
<fabbione> in 20/30 minutes you will die of cancer
<fabbione> and you can blame somebody else
<torkel> dholbach: I have seen it on my laptop too, with an ati chip
<dholbach> fabbione: you're so funny :-)
<Treenaks> dholbach: sit-down comedy
<fabbione> this song is so funny..
<fabbione> Dragostea Din Tea
<fabbione> it's in some weird lang
<fabbione> and it seems to say:
<fabbione> NUMA WAY YEY
<dud-> howdy
<fabbione> punz punz... MORE NUMA WAY YEY
<dud-> is there a  libapache-mod-php4 in hoary?
<jdub> yes
<pitti> dud-: only in universe
<dud-> ok
<pitti> dud-: we generally only support Apache 2
<pitti> dud-: thus, libapache2-mod-php4
<dud-> yeah
<Treenaks> fabbione: I almost didn't survive listening to that song last year!
<dud-> I was sorta hoping I could still use apache1.3
<fabbione> Treenaks: i just found it.. i am not a big fan of disco... not to listen to it at home at least
<dud-> but I guess It's time to learn the apache2 config
<pitti> dud-: This old crack should die^W^W^W^Wit is generally deprecated :-)
<fabbione> dud-: the config files are almost the same
<pitti> dud-: believe me, configuring the new apache2 packages is a _lot_ more fun
<fabbione> dud-: and you won't have big problems migrating
<Treenaks> fabbione: un-find it then.. it'll eat your brain
<dud-> ok
<dud-> even with mod_ssl and all of that?
<pitti> dud-: syntax is the same, and not many keywords actually changed
<fabbione> Treenaks: it already did :-)
<fabbione> dud-: yes
<dud-> cool
<jdub> apache2 is love
<dud-> I've been adding on to my apache1.3 conf for a few years
<fabbione> dud-: trust me... go for a2
<pitti> apache2 is supported
<dud-> sorta have a small attachent to it
<Treenaks> dud-: sentimental attachment?
<dud-> yeah
<dud-> it's gonna be sad to see it go
<fabbione> dud-: yeah so do I
<dud-> hahaha
<fabbione> but i am not sad...
<pitti> dud-: it doesn't "go", it advances :-)
<dud-> that and my samba conf file
<dud-> and I have me some samba questions too
<fabbione> i am just tired of people reporting to me that a1.3 crashes with php
<quarupt> when will hoary have beter AMD64 support?
<dud-> but those can go in the other channel
<quarupt> maybe built in chroot?
<Treenaks> fabbione: a2 crashes with php, too
<fabbione> Treenaks: whatever.. i don't maintain a2 :-)
<fabbione> even if i think i am still listed as Uploader
<dud-> I don't know how all the package manager stuff works, but a mt-daapd package would be awesome
<jdub> dud-: perhaps add to the MOTU list on the wiki
<dud-> ok
<dud-> I'm new to ubuntu
<dud-> I ran debian for about 8 years
<dud-> just installed ubuntu 3 days ago
<jdub> whiprush: HAPPY BIRTHDAY WHIPPERS!
<dholbach> whiprush: WOOHOO! Happy Birthday!
<dholbach> jdub: i dont quite know, what you where talking about... concerning the MOTU list?
<quarupt> wining in AMD64 sux
<jdub> dholbach: adding suggestions to MOTU packages
<YokoZar> quarupt: wining?
<quarupt> "Winie"ing
<quarupt> guess i need to setup a chroot enviroment
<YokoZar> Well, I'll work on the AMD64 Wine package as soon as I get an AMD64 computer, heh
<quarupt> maybe VM'n x86 hoary would be easier
<quarupt> lol
<ajmitch> jdub: thanks :)
<YokoZar> (I make the Ubuntu packages at winehq.org)  But for now I hear that almost no one has gotten amd64 to work on Wine, so it's a longer term project, heh
<quarupt> YokoZar, your on the wine dev team?
<YokoZar> Yeah.  I'm the packager and documentation writer
<jordi> morning mpt_london 
<quarupt> right on
<YokoZar> I'm also playing around with porting aps with winelib
<YokoZar> One of these days there will be an eMule package in Ubuntu
<YokoZar> And it will run on ppc via winelib
<fabbione> pitti: 6749.. why is it assigned to me? is Herbert aware of it?
<quarupt> how about apps, that run standalone from wine, that woulkd be cool
<quarupt> if it was possible i dunno
<quarupt> someway to bind wine with the program, just so it runs as stand alone
<fabbione> quarupt: please these topics are more for #ubuntu
<YokoZar> It's entirely possible, just no one's done it.  And you have to get them to compile with winelib to make them run on all arches
<quarupt> or maybe for #wine
<quarupt> sorry
<YokoZar> Yeah I guess so.  Anyway the point is I'll be doing more wine package work later, and an amd64 version may come out in a way similar to the OpenOffice ones.
<dud-> is there a quick way of removing apache from my rc.blah directories?
<amu> dud-: update-rc.d
<dud-> ok
<dud-> I'll read up on it
<quarupt> So how close are we to seeing Hoary final release?
<fabbione> 3 weeks more or less
<sivang> morning all
<dud-> ok apache2 error, "Call to undefined function: mysql_pconnect()"
<thom> that's a php error
<quarupt> wow, thats close, whats after Hoary, any plans?
<dholbach> quarupt: world domination
<quarupt> lol
<quarupt> But there are plans for another release after Hoary right?
<dholbach> quarupt: it must be on the wiki somewhere
<mjg59> Does Hoary have NTFS resize support in the installer?
<dud-> k
<quarupt> Is anyone doing more work on the installers, i know allot of users want more opions, in the installer, maybe a better package seletcion process?
<fabbione> quarupt: most of these questions are documented in the wiki/FAQ. please check #ubuntu topix
<fabbione> topic even
<quarupt> wtf
<quarupt> why cant i just ask in here? its dead anyways
<quarupt> I like to talk to the developers
<quarupt> and no theres nothing in wiki about adding more package selection in the installer
<quarupt> Lets not have a community like debian
<quarupt> this is the main reason i got away from debian, cause there community is full of grouchy guru's
<daniels> quarupt: one of the problems, though, is that we all live on different timezones, and we're a relatively small team
<daniels> so I rely on looking through the #ubuntu-devel scrollback while I've been asleep/eating/whatever to find out what's been going on that I need to know about
<quarupt> i think most are PST
<daniels> so keeping it as uncluttered as possible is good :)
<daniels> er, not really ... there's me on AEST, other people on UTC, CET, PST, EST, MST
<daniels> we really do span every timezone
<quarupt> so just increase your IRC clients scrollback buffer size to like 4GB
<daniels> to the point where every development meeting, someone gets shafted because of the timezones (tonight it's my turn -- 4am)
<daniels> well yeah, it's already two days, but the point is if I have to spend an hour reading the scrollback, it's just harder to get stuff done.  anyway, sleep time now.
<quarupt> lol, dont worry, the community will grow
<dholbach> good night daniels 
<fabbione> quarupt: all of us are also on #ubuntu. keep this chan uncluttered please
<quarupt> if  this is the way it is to be, why not lock the chan and let only developers in?
<pitti> fabbione: I will handle #6749 with Herbert
<fabbione> because we want people to be able to partecipate. but up to now you asked only questions that are already answered in wiki and FAQ. Also note that i kindly asked you to be on topic. I didn't say you have to shut up
<fabbione> pitti: thanks
<quarupt> and i kindly told you that the installer stuff wasnt on wiki
<fabbione> quarupt: pkg selection is handled via ubuntu-devel mailing list -> seed management and developers approval. it's all on the wiki
<quarupt> Not future plans
<fabbione> you can make future plans yourself and it will be evaluated :-)
<fabbione> the wiki is open to everybody
<fabbione> if you have ideas just stick them there
<quarupt> the final release is 3 weeks away im sure they allready have decided, i was asking, what they decided
<thom> quarupt: please look at the release schedule on the wiki; we've been in feature freeze for a *long* time, the next month is bug fixing only
<quarupt> oh okay thanks
<torkel> quarupt: I guess the guys are dead busy with hoary to be able to release it on time, so that they don't have much time thinking of future plans currently
<HiddenWolf> torkel; dead on
<pitti> Morning sabdfl 
<sabdfl> morning pitti & co
<mpt_london> Good morning jordi
<fabbione> hey sabdfl 
<dud-> ok
<dud-> one quick apache 2 upgrade question because the guys in #apache are dead, how would I fix this error" irtualHost _default_:443 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results"
<thom> your NameVirtualHost line is "NameVirtualHost xxx.x.x.x" but you have "VirtualHost xxx.x.x.x:yy" lines, choose one form and stick with it
<HiddenWolf> dud-: that's really #ubuntu stuff
<dud-> ok
<dud-> thanks
<dud-> I have a bad habbit of asking in the dev channels
<dud-> because the people in them actually know their stuff
<jordi> that's abusing the -dev channel though :)
<dud-> true
<dud-> it won't happen agai
<dud-> n
<HiddenWolf> dud-: I don't blaim you, I have the same tendency, but this is a busy time. stressed-out devs tend to be touchy. ;)
<haggai> elmo: what's up?
<sabdfl> haggai: elmo's likely still en route to the data center
<sabdfl> he says that machine is up and running for you guys
<m_tthew> you mean he ever leaves it?
<Treenaks> sabdfl: did the servers melt?
<sabdfl> Treenaks: no, the flock just needs constant care
<sabdfl> it's growing
<sabdfl> we must be 40+ servers now
<dud-> yeah, I understand HiddenWolf
<dud-> with the freeze and all
<thom> sabdfl: 57
<sabdfl> 57 channels and... 
<thom> #57 servers, in the racks, and if one little server, should accidentally crash
<fabbione> thom: since you have so many toys.. send me concordia :)
<thom> fabbione: hah, no. you can have a dell :P
<fabbione> ahah
<fabbione> ok
<fabbione> send me a dell :)
<fabbione> i am cheap today
<Mithrandir> haggai: ooo2 has conflicting build-deps.
<pitti> Kamion: will it affect the installer in any way if I modify base-files?
<Mithrandir> my machine is still pushing about 1.3MB/sec and has pushed ~66GB of ISOs since yesterday
<sabdfl> ..there'll be thombot, bleeding, underneath the racks
<mjg59> People have seen http://www.theinquirer.net/?article=21724 ?
<Treenaks> mjg59: Finally! I can run Gnome 2.10 on my deskto pat work...
<Treenaks> mjg59: (have to run SuSE here)
<Kamion> pitti: in what way?
<Treenaks> mjg59: it's not very special in other ways, is it?
<pitti> Kamion: #7449, I would like to kill the "staff" group for /usr/local
<thom> sabdfl: *g*
<mjg59> Treenaks: Well, Pavel's been talking about it having improved ACPI support
<pitti> Kamion: I already discussed this with mdz a while ago
<Kamion> urgh, I find the staff group useful
<mjg59> I think we've upped the stakes in that respect :)
<Kamion> yeah, I know it's root-equivalent
<pitti> Kamion: indeed?
<pitti> hmm
<pitti> Kamion: I mean, you indeed think it is useful? I never used it...
<Kamion> but I can see why you'd want to kill it, so don't let me stop you
<Kamion> I can always change it locally; it's /usr/local after all :)
<pitti> Kamion: oh, I always like to listen to your advice :-)
<Kamion> nah, I think you're right to change it by default
<pitti> Kamion: do you think we should leave staff by default?
<pitti> ok
<fabbione> mjg59: when it works....
<Kamion> I don't see how it would affect the installer in any way
<pitti> Kamion: do you need any installer adaptions for a changed package?
<pitti> ok
<mjg59> fabbione: Hah. Yes.
<Kamion> pitti: only rarely
* fabbione kicks halley right in the middle of the CPU's
<fabbione> thom, elmo: any chance to get distcc working on the porting boxes?
<fabbione> perhaps combined with the buildds ?
<pitti> Kamion: What do you think about /home and /var/local?
<pitti> Kamion: I think the latter can stay as group staff, but maybe we should protect /home
<pitti> Kamion: although, over NFS you can already modify /home arbitrarily
<Kamion> pitti: I don't see a need to protect /home in that way
<pitti> yes, right
<pitti> Kamion: the motivation for /usr/local is changing over NFS, AFAICS
<Kamion> programs should use the home directory in the password database rather than looking up /home/*
<m_tthew> kk
<pitti> Kamion: ("any user but root")
* m_tthew blushes
<sivang> bon jour seb128 
<jordi> mr seb128 
<seb128> hi
<pitti> Hi seb128 
<Kamion> pitti: 'sudo chgrp staff /usr/local' is easy enough if that use case is in effect
<Kamion> as long as we respect that change
<pitti> Kamion: hmm, I don't want to change existing installations anyway
<pitti> Kamion: just new installations
<pitti> we can't know whether an admin changed the permissions on purpose
<Kamion> pitti: 'k
<Kamion> seems sensible
<pitti> Kamion: btw, root:staff /home does not really make sense either
<pitti> Kamion: as group staff you cannot chmod/chown home directories
<pitti> Kamion: so I'm inclined to change it to root:root for new installs, too
<GheRivero> res
<dholbach> hai seb128!
<mvo> hey seb128 
<dholbach> hai mvo!
<seb128> hi everybody
<mvo> seb128: has metacity changed recently? I have focus follow mouse with autoraise and it now send gksudo in the background when my mouse is over another window. this is anoying when it grabs my screen :)
<mvo> hey dholbach 
<pitti> haggai: is there any chance to fix apt-proxy-import for hoary?
<seb128> mvo: nop, the code is the same for some weeks
<seb128> mvo: perhaps the new gksu does something different ? Can you try with 1.2.3 ?
<pitti> mvo: this "new windows pop up in the background" bug is actually very old, isn't it?
<mvo> pitti: don't think so. at least it was fixed for a while. I haven't noticed it since a long time
<thom> aaargh
<pitti> mvo: I mostly notice it with gaim
<thom> i hate hotplugs freaking patch systme
<pitti> mvo: sometimes new windows appear at the front, sometimes I can't see them
<mvo> pitti: I think we are talking about different problems. gksudo comes up in the foreground and then goes to the background (because of autoraise). it really shouldn't :)
<pitti> mvo: oh, ok
<mvo> 'cause it graped my mouse :)
<pitti> grabbed?
<mvo> that's what I wanted to say, yes
<seb128> pitti: windows get on the top of screen if you have not used something else .. if you have clicked on an another window it considers that you are using it and doesn't stole the focus
<pitti> I was afraid that it was a feature :-)
<haggai> sabdfl: thanks
<haggai> Mithrandir: ouch, must have changed recently
<mvo> seb128: it looks like it's gksudos fault, I have a idea how to fix it, let's see ...
<haggai> pitti: could be possible
<seb128> mvo: k, feel free to close #7432 if you fix it :)
<fabbione> Kamion: i have one problem with how kernel-wedge calculates modules dependencies
<fabbione> Kamion: do you have time to help me?
<Mithrandir> haggai: e-d-s needs heimdal-kerberos, while kdelibs4-dev wants MIT kerberos
<seb128> this discussion again ?
<thom> seb128: for OOo this time
<Kamion> pitti: yup
<mvo> seb128: will do :) matt assigned me a similar one too
<Kamion> pitti: makes sense
<Kamion> fabbione: sure
<fabbione> Kamion: cool. on ia64 there is the mbcache module that is shared between ext2 and ext3 udeb. The problem is that k-w copies it in both udebs and fails on find-dups
<Mithrandir> seb128: I don't care which works, but if I'm going to look at how feasible it is to get ooo2 working, it would be nice if it actually was _possible_ to build it. :)
<fabbione> Kamion: i did try adding a fs-common-mods
<fabbione> Kamion: now it is copied to all 3
<fabbione> Kamion: how can i tell k-w that i want it only in fs-common and not in ext2/ext3?
<Kamion> fabbione: make ext2 and ext3 depend on fs-common
<Kamion> fabbione: see package-list
<fabbione> Kamion: at this stage ext2 and ext3 are symlinks to what is in k-w
<fabbione> Kamion: is that enough?
<Kamion> yes, you can override their dependencies
<fabbione> ok
<fabbione> thanks
<seb128> Mithrandir: OOo uses both eds and kde ?
<Mithrandir> seb128: ooo2 does, yes.
<Mithrandir> ooo2 will be _fun_ to get into testing in Debian
<Kamion> fabbione: look at powerpc/package-list; basically the same theory
<Kamion> fabbione: but look up what the dependencies of ext2-modules and ext3-modules are in kernel-wedge
<seb128> Mithrandir: I can try to switch eds and friends to mit krb today if you want
<Amaranth> OOo using eds and KDE scares me
<Mithrandir> seb128: yes please.
<Amaranth> hey, do you guys make packages and install those when you are working on things or compile and make install?
<Mithrandir> Amaranth: it's probably just different GUI frontends and integration with the calendar and stuff
<fabbione> Kamion: thanks.. checking
* Amaranth fires up ooo2 writer and waits
<Amaranth> and waits...
<Amaranth> oh, i guess writer wouldn't use eds
<mvo> ping doko
<Mithrandir> Amaranth: I make packages for stuff I write myself, yes.
<Amaranth> hrm, what part of OOo2 would need eds?
<Amaranth> Mithrandir: I mean if you're working on fixing a bug or something. Do you make the fix and create a package or just do a regular install?
<fabbione> Kamion: thanks! that did it :-)
<seb128> openoffice.org2-evolution needs eds I think
<fabbione> Kamion: the Depends: in package-list is a full override or is it parsed to add extra depends?
<Mithrandir> Amaranth: I can't remember the last time I ran make install
<Amaranth> seb128: hehe, i'd hope so. but where in the OOo2 UI do you see calendaring?
<Amaranth> the only thing i can think of would be a mail merge from your evolution contacts list
<Mithrandir> Amaranth: I was just guessing on why it would use e-d-s, I wasn't giving any authorative answer
<seb128>  This package allows OpenOffice.org to access Evolution 2 address books.
<seb128> from the description
<Amaranth> *headdesk*
<mjg59> Hmm.
<fabbione> Kamion: n/m.. it's a full override :-)
<mjg59> At the end of first stage install, the machine has hung rather than reboot
<Amaranth> did gtk2-engines-clearlooks get into the live cd?
<mjg59> Anyone seen that before?
<fabbione> mjg59: it must be an ACPI problem :)
<mjg59> fabbione: Eez ACPI boog?
<fabbione> mjg59: probably :)
<mjg59> It probably is, too. Hrmph.
<mjg59> Oh, I'm very impressed with the NTFS resize support
<jdub> mjg59: yeah?
<mjg59> It just works
<pitti> btw, ISTR that I already saw "Hibernate computer" in the logout dialog, mostly at the live CD
<pitti> however, I don't see this on hoary/preview installs, any idea?
<pitti> this is supposed to be swsups, right?
<mjg59> Yeah
<pitti> swsusp, even
<mjg59> The logout dialog? There's no support for that to work, sadly
<pitti> mjg59: why does it appear at the live CD then?
<pitti> seb128: ^ 
<mjg59> pitti: Dunno
<pitti> hm, okay
<mjg59> I've never actually booted the liveCD...
<mjg59> bicyclerepair?
<mjg59> Great name
<pitti> mjg59: nearly as descriptive as "foobar" :-)
<thom> so, is there any valid reason why a desktop would want to hibernate?
<pitti> thom: yes, there is, but actually I'm talking about my laptop
<pitti> thom: usually I switch off my box before I go to bed, but with swsusp the boot could be much faster
<seb128> pitti: hibernate and sleep are displayed according to the /usr/sbin/pmi query <action> value
<mjg59> seb128: In the logout dialogue? Or in gdm?
<seb128> both
<pitti> logout
<jdub> thom: yeah, totally
<seb128> the logout dialog ask the actions to gdm with gdmflexiserver
<jdub> thom: i hibernate windows xp when i'm not using it
<jdub> thom: and i'd love to hibernate and switch off at night
<Kamion> fabbione: yep, full override
<mjg59> seb128: Oh, you managed to make it work with flexiserver?
<mjg59> Does it still cause a logout?
<Kamion> fabbione: well, sort of :)
<seb128> mjg59: yep, I've hacked gdm to add a new action that doesn't wait to get to the gdm screen
<Kamion> fabbione: funny things happen with Provides and stuff
<pitti> mjg59: for me it causes ppc sleep, but of course no wakeup (doesn't work in iBook G4)
<jdub> seb128: let me know what i need to add in the theme
<mjg59> pitti: It does work on ibook G4s, it just doesn't work on /your/ one
<mjg59> Which is a bit confusing
<mjg59> pitti: Actually, could you file a bug about that?
<pitti> sure :-)
<pitti> mjg59: we already tried to debug this, is there anything I can include in the report?
<Kamion> thom: my amd64 desktop is central heating for my room, as well as white noise generation
<seb128> jdub: about what ? hibernate/sleep ?
<thom> Kamion: heh
<Kamion> thom: in summer or when I actually want to sleep, hibernation would make a lot of sense
<jdub> seb128: yeah
<mjg59> pitti: dmesg, /proc/cpuinfo for now. There's a couple of things to test - can you remember if we tried with init=/bin/bash ?
<thom> ia64 does that here; i can sucessfully sleep with 5 machines on in my bedroom
<pitti> mjg59: I think we didn't; I'll do
<pitti> mjg59: we mostly tried to enable/disable frame buffer and such
<mjg59> Yeah
<mjg59> benh suggested it might be an AGP issue
<seb128> jdub: need to have a look, I've hacked the action for gdmflexiserver for the moment. gdm has a suspend action, I need to hack a bit to get hibernate too, I'll let you know
<jdub> seb128: cool, thanks
<seb128> np
<seb128> jdub: are you ok with a switch from heimdal-dev to libkrb5-dev for eds and friends now ?
<pitti> mjg59: started with /bin/bash, but since pbbuttonsd isn't running, what was the command to put it to sleep?
<jdub> seb128: that's a Q for mdz
<mjg59> pitti: Ugh. Good question. Just start pbbuttonsd? :)
<seb128> jdub: k
<mjg59> You may need to mount /proc first
<mjg59> Hm. The sensitivity on this synaptics pad seems a bit high.
<pitti> /dev/pmu doesn't exist
<pitti> bah
<mjg59> Ah. Heh.
<mjg59> Start udev?
<mjg59> (after mounting /sys)
<dholbach> hellas dredg 
<pitti> mjg59: no luck, udev's init script doesn't work (no /dev/null) and starting udevd and udevstart does not give any devices
<mjg59> pitti: Bah.
<pitti> mjg59: /dev/ and /.dev are both empty
<mjg59> pitti: Can you find the major/minor for pmu and create it manually?
<mjg59> Ok. Clean preview install. Logout/hibernate suspended to disk and then resumed happily.
<mjg59> The new background picture is quite nice
<mjg59> Gah. Yes, the machine hangs when attempting reboot, but halts correctly.
<mjg59> ACPI BOOG
<mjg59> My christ, it boots fast.
<thom> mjg59: so my X40 will only suspend/resume once. then i have to reboot before it'll work again
<mjg59> thom: Seriously? Argh.
<thom> seriously
<Mithrandir> thom: how about hibernate?
<thom> i'll try it again with a clean hoary install
<mjg59> thom: Using vesafb?
<thom> Mithrandir: same deal
<mjg59> Feck. It's probably AGP.
<Mithrandir> thom: weird.  WFM.
<jdub> Kamion: what's your opinion on supportability of snort?
<mjg59> I wonder why mine doesn't behave like that.
<mjg59> So.
<mjg59> HP nc6120. Installs fine, hibernates out of the box, does ACPI suspend/resume once it's enabled.
<mjg59> This is unbelievably sweet.
<pitti> mjg59: hey, resuming works with init=/bin/bash
<mjg59> pitti: Rock
<pitti> mjg59: YOU ROCK
<thom> mjg59: nice.
<mjg59> Now figure out which module stops it working :)
<Keybuk> mjg59: yeah, I've heard the new HPs all "just work"
<pitti> mjg59: now I only have to find out what is stopping it
<pitti> yeah :-)
<Keybuk> that was when Istarted looking at the nc4200
<thom> mjg59: pretty much default kernel arguments, acpi_sleep=s3_bios, elevator=cfq and that's it
<mjg59> thom: lose acpi_sleep=s3_bios
<mjg59> It's not needed with Hoary
<fabbione> Kamion: no plan to use Provides at all
<thom> when did that happen?
<mjg59> When we started using vbetool
<thom> ah, arse
<mjg59> This is all SO MUCH ROCK.
<mjg59> Now I just need to figure out why reboot hangs.
* jdub cuddles mjg59 
<mjg59> Volume hotkeys work after configuration
<mjg59> Ah. Sod.
<Kamion> jdub: I don't know anything about snort, sorry
<jdub> aha
<mjg59> ACPI stops working after the first lidswitch press. No more interrupts.
<jdub> BLACK MARK
<jdub> anyone care to espouse opinions, good or bad, on snort?
<jdub> with regards to supportability :)
<elmo> it's one of these packages with volatile data (i.e. the signatures) that need updating regularly
<elmo> and like ethereal it's security history isn't great
* sladen at last has a Real Internet Connection ...for the first time in two weeks
<elmo> (which is actually far worse, since it's a daemon, and ethereal is something you don't generally leave running indefinitely)
<sladen> elmo: so, they want splitting;  one to capture and one to analyse---the second on which in turn relies on a package of signatures?
<elmo> sladen: probably yea
<mjg59> Damnit. Very broken ACPI.
<mjg59> It's now firing off hundreds of interrupts a second.
<fabbione> dude... this is NOT stuff i want to hear from you at 3 weeks from release
<mjg59> fabbione: It works fine on other machines, just not this one
<mjg59> I'll try to track it down. It's an interrupt issue, by the looks of it.
<fabbione> i don't think you are the only one with that specific machine....
<jdub> elmo: thanks
<jdub> elmo: would you lean towards yes or no?
<ajmitch> elmo: sync gnue-common, gnue-appserver, gnue-forms please :)
<jdub> ajmitch: dude, you so love the weird tech ;)
<mjg59> So, two issues: hang on reboot, problems with acpi interrupt
<ajmitch> jdub: you know what it is? :)
<elmo> jdub: personally - no
<elmo> [NOT Updating - Modified]  gnue-common_0.5.13-1ubuntu1 (vs 0.5.14-1)
<elmo> ajmitch: ok to override ?
<ajmitch> yes
<ajmitch> I put the changes in 0.5.14
<elmo> ajmitch: all done
<ajmitch> thanks
<ajmitch> elmo: can you sync pnet, pnet-assemblies, pnetc too? :)
<ajmitch> jdub: I seem to collect packages that nobody really wants..
<HiddenWolf> Does anyone have any idea why it could be that during boot the ....ok is printed on a new line for me?
<elmo> ajmitch: done
<ajmitch> thankyou
<ogra> elmo: did crimsun already talk to you ? he seems to have problems with uploading
<thom> mjg59: still can only suspend once without acpi_sleep set
<elmo> ogra: hmm, don't think so - I got a msg from wasabi, but I assume that's someone else
<pitti> mjg59: okay, I debugged this a bit
<ogra> elmo: crimsun was approved fo uploading about 6 weeks ago, could you look if his account is set for uploading ? 
<pitti> mjg59: it works with single user mode, and I can even load the radeon module
<pitti> mjg59: but as soon as I start X, and the radeon module actualyl gets used, it doesn't resume correctly any more
<pitti> mjg59: so "radeon" really seems to be the culprit
<elmo> ogra: ok, will check in a bit
<ogra> elmo: great, thanks :)
<mjg59> pitti: Ok, cool. So it's probably some DRI/AGP issue.
<mjg59> Can you file a bug and I'll speak to benh about it?
<pitti> mjg59: sure, thanks
<pitti> mjg59: ROCK! I disabled the dri and glx modules from xorg.conf, and now it works
<pitti> mjg59: I don't need 3D on the laptop, so I can now actually use suspend
* pitti is happy
<pitti> mjg59: I include this into the bug report
<pitti> mjg59: any graphic card-specific debug info I could include?
<mjg59> pitti: Not really, what you have sounds great
<jdub> ajmitch: gnue? yeah :)
<Kamion> whoa, archive-copier bug just occurred to me
<Kamion> I bet that, on an installation from DVD, it will copy the entire contents of main onto the hard disk
<pitti> argh
<Kamion> right, time to fake up an ubuntu-ship task I think
<Kamion> oh, and archive-copier probably won't work properly on kubuntu, hmm
<thom> Kamion: OW
<YokoZar> elmo: you here?
<YokoZar> elmo: I sent out a mail to ubuntu-devel about removing winesetuptk, please do so :)
<dholbach> seb128: fixed and uploaded gdesklets and drivel
<Keybuk> *sigh* at bts
<Keybuk> the worst thing is, I know Ubuntu's bugzilla is about to notice my severity change and spam me again with the same bug
<fabbione> elmo: are you still around?
<seb128> dholbach: cool
<elmo> fabbione: yes
<elmo> YokoZar: is it urgent?
<fabbione> elmo: mind to give a check to the buildds that are munging the kernel??
<fabbione> elmo: i did a few changes and i am kinda curious to see how they are going...
<fabbione> specially compiling with -j200 on buildd...
<elmo> err, seriously?
<fabbione> ahahha
<fabbione> got you
<fabbione> no... only Ncup * 2
<fabbione> Ncpu's * 2
<pitti> fabbione: is inotify now enabled again by default?
<fabbione> pitti: no
<fabbione> it still crashes on me
<fabbione> with one difference
* elmo buys the team a copy of "The boy who cried wolf"
<fabbione> at the second unplug, instead of the first
<pitti> fabbione: just read about the new version on u-changes, that's why I'm asking
<fabbione> elmo: i didn
<fabbione> elmo: i didn't cry :-)
<fabbione> elmo: i am really curious
<elmo> i386 is working
<mjg59> fabbione: I've sorted the reboot problem
<fabbione> cool
<fabbione> mjg59: too late.. -26 is up 
<mjg59> It's going to need a machine-specific dmi quirk
<elmo> our powerpc buildds are running UP kernels, so they won't be affected
<elmo> and our ia64 are single proc anyway
<fabbione> elmo: it will still go * 2
<YokoZar> elmo: urgent, no.  But it would be nice to take care of it before people start wondering why Wine is being difficult
<fabbione> elmo: it gains a lot on ccache if the code is cached already (as it should be)
<fabbione> mjg59: /j #u-kernel
<fabbione> and pester the rest of the team there
<fabbione> i am off for a few hours.. gotta rest a bit and do some hw shopping
<pitti> fabbione: new CD burner? :-)
<jdub> http://lwn.net/Articles/127141/
<fabbione> elmo: thanks btw :-)
<jdub> nice comments
<fabbione> pitti: DVD burner.. i have a CD
<elmo> fabbione: are you explicitly calling ccache?
<pitti> fabbione: yes, that's what I meant
<pitti> fabbione: have fun, and good rest
<fabbione> elmo: no, but ccache is installed on all buildd
<elmo> just wondering why I can see /usr/bin/ccache in the ps output
<elmo> maybe it's an artificat of how lamont wraps gcc
<fabbione> elmo: because ccache is a wrapper to gcc?
<fabbione> nah that's an extra one on top
<fabbione> you never see ccache running
<fabbione> usr/bin/ccache is only for admin 
<fabbione> to check the status of the cache
<elmo> /usr/bin/ccache /usr/bin/gcc-3.3.gcc-opt -mcpu=pentium4 -pipe -Wp,-MD,net/ax25/
<elmo> the buildds beg to differ
<fabbione> that must be lamont artifact
<fabbione> the pure ccache is different
<mjg59> So.
<mjg59> Hoary, from power button to login prompt = 50 seconds
<mjg59> (I hit enter at grub)
<thom> that's pretty respectable
<thom> and then about double that to login?
<mjg59> It's less than 50 seconds from login to desktop
<mjg59> This is a 5200RPM disk
<thom> mjg59: so how do i debug why suspend only works once?
<mjg59> thom: Disable DRI in your X config and see if that makes a difference
<amu> elmo: please could you sync "blender"
<thom> mjg59: already disabled
<mjg59> thom: Really? Hrm.
<mjg59> In what way does the resume fail?
<thom> mjg59: resume doesn't fail; it just doesn't suspend - the script runs, screen blanks wireless down etc etc, then 10 secs later it resumes to the desktop
<mjg59> thom: Ah, interesting. What does dmesg look like?
<elmo> [NOT Updating - Modified]  blender_2.35-1ubuntu1 (vs 2.36-1)
<elmo> amu: ok to override?
<amu> elmo: lemme check ... 
<T-Bone> elmo: can you do as well for efibootmgr please?
<elmo> t-bone: it's in main - did it get approved?
<T-Bone> elmo: it's in main
<T-Bone> elmo: mdz said he wouldn't be picky since it's ia64 only
<T-Bone> i can send you a mail with the summary of the changes if you want
<elmo> I don't care - I'm not part of the approval process, I just work here - all I need to know is that mdz/jdub approved it...
<amu> elmo: yeah, let's try it
<thom> mjg59: interestingly, it appears to be mdnsresponder not stopping any time after the first suspend
<T-Bone> elmo: Mar 10 19:46:16 <mdz>   since it's ia64-specific I wont't be picky
<T-Bone> elmo: that's all i have
<elmo> amu: err, what's that mean?  are the ubuntu changes merged or no longer relevant?
<jdub> T-Bone: i'll approve it given mdz's almost approval there
<jdub> :)
<T-Bone> jdub: thank you soooooo much ;)
<elmo> efibootmgr |    0.5.0-1 |         hoary | source, i386, ia64
<elmo> it's not actually ia64 only btw
<T-Bone> doh
<T-Bone> hmm
<jdub> elmo: only actively used on ia64 i thought
<elmo> jdub: if by actively you mean widely, then, yeah
<T-Bone> i think that there are some high end x86 servers with EFI boot system
<elmo> there is EFI for i386, is just not exactly common and people using it are either paid to do so or sicko sadists who shouldn't be pandered too
<T-Bone> lol
<elmo> (hmm - maybe that day I spent fighting EFI left me somewhat bitter)
<T-Bone> that's quite a nice summary :)
<jdub> elmo: so damage is pretty limited to ia64 ;)
<amu> elmo: didnt check, should i upload *ubuntu* myself? and only ask you if there's no ubuntu in the name? 
<torkel> thom: does it works if you add mdnsresponder to STOP_SERVICES ???
<thom> torkel: yes, it works fine then
<thom> i'm just bemused as to why it works fine the first time
<elmo> amu: err.  deal is this: if you want to sync an unchanged package, ask me.  if you want to sync a changed package, check the differences.  if they're merged or no longer relevant and can be safely overwritten, ask me.  If they're still needed, you need to do a manual merge and upload the result. 
<pitti> Kamion: does the installer touch /etc/console-tools/config in any way?
<thom> that reminds me, i need to push ucf into acpi-support
<Kamion> pitti: yes, localechooser prebaseconfig does
<pitti> Kamion: ah, that might be the reason for #6585
<amu> elmo: all right, i'll try it first, thx4info
<_d4vid> hi all
<mjg59> thom: Ah, right. So fix that :p
<Kamion> pitti: dunno what the right answer is
<Kamion> pitti: it's kind of necessary at the moment to get console fonts set right
<pitti> Kamion: yeah, no problem with this
<pitti> Kamion: it's just causing an upgrade dpkg question
<Kamion> yeah, I realise that
<thom> yeah, i'll add it to the list of default stop services
<pitti> Kamion: I always thought that dpkg wouldn't ask if the original file didn't change...
<Kamion> pitti: I imagine that the version in the package has changed
<pitti> oh, indeed
* pitti discovers that debdiff does _not_ display changed conffiles :-(
<pitti> bah
<elmo> yeah, debdiff's overly minimal
<elmo> it needs a --no-really-show-me-everything option
<pitti> elmo: it should at least display _that_ the file changed
<pitti> Kamion: 
<elmo> T-Bone: done
<pitti>  # Set the following - more euro-friendly default than kernel font.
<pitti> -# SCREEN_FONT=latcyrheb=sun16.psf
<pitti> +# SCREEN_FONT=latarcyrheb-sun16.psf
<pitti> ^ this is the only change
<Kamion> right, my change in response to some bug
<pitti> Kamion: would it be okay to revert this comment, or do you need the comment?
<T-Bone> elmo: thx!
<Kamion> er I don't see how that would help
<Kamion> you can't keep that file static forever
<Kamion> and the original was *wrong*
<pitti> Kamion: hmm, so apart from some ugly preinst hacks, this isn't going to change then
<Kamion> the change had nothing to do with correct operation of the installer or anything, it was just an incorrect comment
<Kamion> pitti: one solution could fix it for the future, I guess
<pitti> ucf?
<Kamion> pitti: make console-tools read another file as well as /etc/console-tools/config
<pitti> /etc/console-tools/screen-font ?
<Kamion> but that would mean that users have to look in two files to work out their console configuration
<Kamion> which sucks
<pitti> hmm, right
<Kamion> ucf would be an option ...
<Kamion> a three-way merge should handle it fine
<pitti> that's still interactive
<Kamion> can't ucf try a noninteractive three-way merge if the diffs don't overlap?
<pitti> dunno, so far I only used it in standard mode, where it asked
<pitti> hmm
<pitti> console-tools: important, ucf: optional
<pitti> :-(
<Kamion> doesn't really matter for Ubuntu, and I can easily see ucf getting promoted in the future
<Kamion> but I don't really
<Kamion> know
<Kamion> maybe the separate-files approach is better; /etc/console-tools/config would have to be rewritten to reflect that
<pitti> I don't see an ucf option to do a noninteractive merge
<Kamion> ok
<pitti> which would probably wrong anyway
<pitti> *mumble* conffiles *mumble* die *mumble*
<pitti> Kamion: nontrivial then, I think about it, but rewriting console-tools might not make mdz happy...
<jdub> pitti: just claim that you're derooting it ;)
<jdub> random derootification
<Kamion> could preinst-hack it for hoary to avoid the upgrade problem
<Kamion> but we'll need to fix it for hoary otherwise this will bite us again in breezy
<pitti> Kamion: we need to transition the screen font to the new conffile, right?
<Kamion> yeah, it's all a bit non-trivial
<Kamion> let me ponder it
<pitti> Kamion: preinst: mv config -> config.dpkg_tmp, postinst: merge
<pitti> bah, if anything goes wrong, you are doomed
<pitti> Kamion: I think if we modify the file in the scripts, it shouldn't be a conffile any more
<Kamion> we have to, for this upgrade alone
<Kamion> I think
<pitti> besides, changing other package's conffiles is an RC bug by itself...
<Kamion> or I suppose maybe if it weren't a conffile any more
<Kamion> there wouldn't be a problem
<Kamion> I think localechooser is probably wrong here, but at the moment it has no other option so Debian isn't going to fix it before sarge
<pitti> sure
<pitti> I don't want to change localechooser for Hoary
<Kamion> we might have to
<Kamion> anyway, I need lunch ...
<pitti> Kamion: we can change conffile -> config file, and not touch an existing one; but copying a template if it isn't present
<pitti> Kamion: so, without ucf
<HiddenWolf> kamion: will sarge ever be out?
<pitti> lunch... good idea indeed :-)
<Kamion> HiddenWolf: yes, following the release meeting in Vancouver stuff is looking a lot better
<Kamion> pitti: conffile -> config file is seeming like the sanest approach to me
<pitti> me too, without ucf
<pitti> Kamion: if we really have to change something nontrivial to the default conffile, we can always handle this more forcefully
<elmo> fabbione: I don't think that was such a good plan
<elmo> Build needed 01:05:48, 1425648k disk space
<pitti> Kamion: okay, I prepare a patch, and ask for review
<elmo> Build needed 00:38:47, 1428100k disk space
<elmo> first is -26, second is -25.2 .  on amd64, same buildd host
<lamont> if you link ccache to say /usr/local/bin/gcc, then you don't see it, you see /usr/local/bin/gcc.
<lamont> we run things as /usr/bin/ccache gcc ...
<lamont> so you do
<elmo> I just export PATH=/usr/lib/ccache:$PATH
<lamont> yeah, that's not what gcc-opt does..
<dholbach> hellas jani!
<jani> hi dholbach
<jani> nice progress on dehowlification :)
<dholbach> YES :-)
<dholbach> jani: how are you?
<jani> busy at work :(
* tseng dumps water on dholbach like a boxing champ
* dholbach comforts jani
<jani> hope tonight this weekend will have some time for motuwork
* dholbach thanks tseng :-)
<jdub> dholbach: was chatting to murrayc earlier, he's very grateful for your work on updating *mm
<dholbach> janc: woohoo
<Mithrandir> lamont: moo.  Got a bit of time for util-linux evilness discussions?
<dholbach> jdub: thanks... just hope i get libxml++ and glom in soon
<lamont> Mithrandir: I have exactly 5 minutes before I run out the door to take kids to school.  couple hours from now would be better...
<jani> has the after preview meeting already happened?
<Mithrandir> lamont: sure, ping me when you're back?
<dholbach> jani: 17:00 utc
<jani> today?
<lamont> Mithrandir: sure
<lamont> should certainly be before the meeting
<jani> it's not in the meeting channel 'headline' :)
* Mithrandir thinks we should _really_ have ical feed of when meetings are scheduled.
<jdub> yes
<jdub> jamesh is working on stuff for that
<HiddenWolf> utc is which timezone?
<jdub> it will be rad
<jdub> HiddenWolf: utc is utc :)
* lamont wonders what #ub is :-)  I think we maxxed the topic in #u-m...
<HiddenWolf> jdub: gmt +/- ? hours?
<Mithrandir> jdub: apt-get install schoolbell? :)
<lamont> HiddenWolf: TZ=UTC date
<jdub> Mithrandir: mmm, but with launchpad integration foo
<jdub> HiddenWolf: UTC is a timezone definition
<jdub> it is arguably == GMT
<jamesh> UTC has a different definition to GMT
* netjoined: irc.freenode.net -> orwell.freenode.net
<jamesh> related to leap seconds, etc
<mjg59> thom: I'm getting about 10 seconds from login to desktop
<mjg59> So if I switched on autologin, I bet we could do power-on to desktop in a minute
* lamont takes kids to school
<dholbach> mjg59: wow
<mjg59> Grah. The 6100 series suspends and resumes fine, the 6200 series doesn't
<jdub> mjg59: autologin might be doable for next release
<jdub> mjg59: with some gdm changes i'm planning
<jdub> (interaction stuff, i know gdm supports it)
<Amaranth> shared-mime-info (0.15cvs20050310-0ubuntu1) <--yikes
<Amaranth> a little recent, isn't it?
<mjg59> On the bright side, I now have a machine with failing ACPI *and* a serial port
<zul> hey
<dholbach> hai zul
<zul> hey dholbach 
<mjg59> Oh yes
<mjg59> 60 seconds from power button to desktop
<dholbach> :-)
<zul> mjg59: got any idea about #7438?
<dholbach> see you later
<mjg59> zul: Oh, argh. Almost certainly unserviced interrupt issues.
<zul> mjg59: ok ill ask him for his /proc/interrupts then
<mjg59> Yeah. Ask him for /proc/interrupts from Fedora, too.
<zul> mjg59: done
<Kinnison> Hi guys
<pitti> Hi Kinnison 
* Kinnison just did a warty -> hoary upgrade and it was (while slow) absolutely fine
<Kinnison> a few too many conffile questions; but I think that's due to my fiddling
<Kinnison> My only concern was that after a reboot, evolution popped up a "thank you for downloading this evaluation release" box
<Kinnison> which seems a wee bit silly
<seb128_> anybody has an idea of why I get this in poppler build logs "libtool: ignoring unknown tag CXX" ?
<seb128_> and not in a pbuilder or my box
<pitti> Kinnison: re conffile questions, I collected them in https://bugzilla.ubuntulinux.org/show_bug.cgi?id=7416
<pitti> Kinnison: if you found anything else, please create a new bug and make it block #7416
<Kinnison> pitti: I'll look through
* Kinnison sits and crys as firefox loses all its config :-(
<pitti> does it?
<Kinnison> well, it disables all my shiny useful plugins :-(
<pitti> seb128: indeed, do you think this evo dialog can be silenced?
<seb128> what dialog ?
<seb128> Keybuk: around ?
<Kinnison> seb128: in apps/evolution/shell/ unset skip_warning and restart evo
<seb128> this should not be set in a stable version
<seb128> is it ?
<mjg59> Hm.
<mjg59> PCMCIA startup is hanging this machine.
<mjg59> Oh, arse, no. That's not hte problem.
<mjg59> It gets to Starting Postfix and then hangs
<mjg59> Disabling dbus startup stops it hanging, so I blame HAL
<seb128> anybody with some libtool knowledge around who know why http://people.ubuntu.com/~lamont/buildLogs/p/poppler/0.1.2-0ubuntu1/poppler_0.1.2-0ubuntu1_20050310-1911-i386-successful has a bunch of "libtool: ignoring unknown tag CXX"
<seb128> ?
<seb128> works fine in a pbuilder
<pitti> elmo: can I please have aalib1-dev and slang1-dev in concordia's hoary-i386 dchroot?
<Mithrandir> seb128: any progress on mit-kerberising e-d-s? :)
<Keybuk> seb128: yo
<Keybuk> seb128: does that after libtoolzeing?
<seb128> Keybuk: nop, the package is not relibtoolized
<seb128> standard ./configure && make
<seb128> works fine on my box and in a pbuilder, and make that on the pbuilder
<Keybuk> g++ installed on the system?
<Keybuk> with build-depend ?
<seb128> correct
<Keybuk> no idea then
<seb128> k
<seb128> that ftbfs evince :/
<Keybuk> got a copy of the generated libtool script?
<seb128> nop
<Keybuk> weird :)
<seb128> Mithrandir: seems to work fine here, need to ping mdz before uploading
<Mithrandir> seb128: ok, thanks
* Kamion gets hold of a copy of the notorious Linux Magazine cover DVD
<zul> is dvd borked or what i didnt read the whole thread
<Kamion> they took a random development snapshot without telling us
<Kamion> I'd like to know what it is :)
<Kamion> hmm, crap, my only DVD reader is in the Pegasos
<zul> heh...the cd copy i got from them was hosed too 
<Kamion> marginally unuseful for testing an i386 DVD
<seb128> Keybuk: hum, the buildd log has no "checking how to run the C++ preprocessor... g++ -E"
<seb128> lamont: here ?
<Kamion> ah, Pegasos in "working better when plugged in" shocker
<T-Bone> lol
<zul> ah...i wouldnt let svenl hear you
<elmo> pitti: done
<Kamion> hmm
<seb128> mdz: around ?
<Kamion> the Linux Magazine DVD has kernel ABI 2.6.10-2
<zul> i think someone should write a letter to the editor
<Kamion> it's the 20050129 DVD build
<Kamion> which is between Array CDs 3 and 4
<elmo> did they call it hoary?
<tseng> seb128: heya, im testing some fixes for gstreamer
<tseng> seb128: theres a buglet with mp3s with playbin
<Kamion> elmo: it's labelled 'Ubuntu 5.04' and '"Hoary Hedgehog" Development Edition'
<seb128> tseng: http://bugzilla.ubuntu.com/show_bug.cgi?id=7359 ?
<tseng> seb128: sounds like it
<Kamion> the blurb inside says 'Ubuntu Linux is a stylish distribution built from Debian and polished for the corporate user. This month's DVD brings you a special pre-release of the upcoming Ubuntu Linux 5.04, which Ubuntu has dubbed the "Hoary Hedgehog" release.'
<seb128> tseng: rock, thanks
<elmo> bah, that sucks
<seb128> tseng: bug flood, not easy to track every single one, thanks for looking on it :)
<seb128> tseng: do you have an upstream pointer for it ?
<tseng> yes I do
<tseng> posting now
<tseng> and rolling my source package as we speak
<Kamion> amusingly, they claim Kickstart support; I didn't upload the first piece of that until 4 February
<pitti> elmo: can I please have xlibs-dev python-gtk2-dev libexif-dev in hoary-i386 (concordia)?
<lamont> seb128: which buildd?
<zul> mjg59: http://lkml.org/lkml/2005/3/11/96
<seb128> lamont: poppler build is weird, any way to get the config.log ?
<elmo> pitti: they're all installed
<pitti> elmo: thanks, worls now
<pitti> works, even
<elmo> pitti: I was just dist-upgrading, that porbbaly confused things
* lamont goes to lokk
<pitti> ah, that probably was it
<elmo> lamont: <random> we should save config.logs from builds</>
<seb128> lamont: it throws "libtool: ignoring unknown tag CXX" messages and the configure has no "checking how to run the C++ preprocessor... g++ -E"
<lamont> seb128: build was successful... so no.
<seb128> lamont: evince ftbfs due to that
<seb128> lamont: any idea on what could be wrong ?
<lamont> elmo: saving config.log... yeah, bob should do that - I'll add it to my list for Kinnison 
<sivang> is a.u.c having bandwidth issues?
<elmo> no
<sivang> (trying to download a source pkg and no go)
<elmo> it's apache is just slow
<elmo> use a mirror
<sivang> 50.6kB/s
<sivang> elmo: ok, I'll try a mirror
<sivang> elmo: thx
<seb128> lamont: any idea on how to debug that ?
<sivang> pitti: how is the germen mirror, up to date?
<pitti> sivang: should be pretty good
<pitti> archive.u.c sucks ATM
<sivang> pitti: ok, I'm switching to it :) I also always used the germne one when I Was using sid :)
<elmo> de.archive.u.c exists and is a good mirror
<lamont> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
* lamont grumbles
<lamont> elmo: and yeah, I know - it's on my end
<sivang> pitti: no security there?   Could not resolve de.security.ubuntu.com
<pitti> sivang: they have security there
<pitti> http://de.archive.ubuntu.com/ubuntu/dists/
<pitti> -> warty-security, hoary-security
<sivang> pitti: k, thx
<sivang> pitti: sweat! :)
<sivang> pitti: works perfectly :)
<pitti> why sweat? does it suck as well?
<pitti> hmm, s/sweat/sweet/ then?
<sivang> pitti: oops :)
<sivang> pitti: sweet
* pitti fixes the n-th package to not ask dpkg conffile question and curses at dpkg not removing conffiles on upgrades
<pitti> Keybuk: ^ any chance that this madness will eventually be fixed in the future?
<Keybuk> not in the immediate future
<Keybuk> because of why dpkg does it
<pitti> no, long-term
<Keybuk> it's in the same class as why dpkg won't replace dirs with symlinks and vice-versa
<Keybuk> maybe when there's richer metadata on installed files
<pitti> Keybuk: but what should be wrong with deleting an unchanged conffile if the newer package version does not ship it any more?
<pitti> Keybuk: is there an use case why this should not happen?
<tseng> why doesnt apt cache sources =/
<wasabi_> what's that mean? cache sources?
<wasabi_> oh you mean for apt-get source don't ya
<wasabi_> yeah it'd be neat. ;)
<enrico> Hello.  Someone knows how to insert the "}}}" string inside a MoinMoin verbatim environment (the one between {{{ and }}}) ?
<Keybuk> pitti: they are dude, it's called purge
<Kamion> enrico: try }``}}
<pitti> Keybuk: I mean on package upgrade, not purge
<Kamion> enrico: I think that should work, might not though
<pitti> Keybuk: upgrading is what I'm fixing
<enrico> Kamion: it shows }''}}
<enrico> an, no, backquote
<Keybuk> dunno if there's any particular technical reason for that
<enrico> It shows }``}}
<enrico> Kamion: it doesn't work forme
<jdub> night guys
<enrico> jdub: night
<jdub> sent apologies for meeting
<jdub> just... can't... keep... eyelids... open...
<Keybuk> it'd take about 1s to fix
<Keybuk>   /* All the old conffiles are marked with a flag, so that we don't delete
<Keybuk>    * them if they seem to disappear completely.
<Keybuk>    */
<Keybuk>   oldconffsetflags(pkg->installed.conffiles);
<Keybuk>   for (i = 0 ; i < cflict_index ; i++) {
<Keybuk>     oldconffsetflags(conflictor[i] ->installed.conffiles);
<Keybuk>   }
<Keybuk> delete that code
<Keybuk> but I don't want to do that without learning why it's there in the first place
<pitti> yeah, sure
<pitti> that's why I wonder whether there is an use case for it
<jbailey> Kamion: I was just about to send you a patch for the resume partition stuff when I saw that you had done it.  Ah well, serves me right for not filing a bug to track.
<Mithrandir> Keybuk: transition from conffile to non-conffile, possibly?
<pitti> Keybuk: the code does not look like a bug, but like purpose
<Keybuk> the best thing would probably be to ask iwj
<pitti> Mithrandir: hm, good point
<jbailey> Kamion: Does the installer allow you to setup swapfiles?  If yes, this will be broken and I'll send mine along anyway.
<Keybuk> Mithrandir: nah, cause then it'd get owned by the new package anyway
<pitti> Mithrandir: but a package should install its version anyway if the config file does not exist
* pitti only talks about removing _unchanged_ conffiles
<Kamion> Keybuk: reason: administrator might have looked at it, gone "oh yeah, I like that, no changes necessary"
<Kamion> jbailey: sorry, yeah, did that in a hurry just before preview, you weren't around at the time
<pitti> Kamion: but if the new package does not need the conffile any more (mostly it was moved to another package), why should it be kept?
<Kamion> jbailey: I don't know of any way to set up swapfiles in partman, but you could set them up by hand
<Kamion> pitti: dpkg doesn't know that
<Kamion> Keybuk: it wouldn't get owned by the new package if it was a transition from conffile to non-conffile configuration file
<pitti> Kamion: why not? in the preinst upgrade phase it should knwo
<Kamion> not without dpkg-registerfile or whatever
<Kamion> pitti: it doesn't know what the packager intended; it might be "I want to manage this as a non-conffile configuration file now" or it might be "I want this file to go away"
<Keybuk> Kamion: yeah, that certainly wouldn't work
<pitti> Kamion: what would be wrong with deleting the conffile if the new version wants to handle it as a config file?
<Keybuk> the simple answer, of course, is the packager should transition correctly in the maintainer scripts
<pitti> sure, but that's a bit boring
<Keybuk> I actually find the fact that dpkg punishes you for moving conffiles about quite nice
<Keybuk> because YOU SHOULDN'T MOVE THEM
<pitti> I DIDN'T
<Keybuk> :p
<Keybuk> suuure, blame upstream
* pitti just fixes stupid packages from other people :-)
<pitti> :-P
<jbailey> Kamion: 'kay.  I've got a simple patch here.  Do you want it in a new bug, or in an email?
<pitti> Keybuk: the bad thing is that it doesn't punish the maintainer, but the user
<elmo> how do I get w3m to auto-reload?
<pitti> Keybuk: --with-maintainer-spanking would be much better :)
<elmo> + a page
<Keybuk> pitti: doesn't really affect the user
<Kamion> jbailey: new bug please
<pitti> Keybuk: on upgrade he has to answer conffile questions
<koke> elmo: shift+R ??
<elmo> koke: no, as in, reload it every 5 mins
<Keybuk> pitti: why?  dpkg no longer knows about the conffile
<Kamion> pitti: only when the package maintainer fucks up
<elmo> without me sitting here pressing R every 5 mins
<Keybuk> that only happens when the maintainer gets things wrong
* pitti invokes dch on concordia and is suddenly greeted with nano
<koke> elmo: ok, I missed the "auto-" :D
<Kamion> you don't set EDITOR=vim everywhere?
<Kinnison> pitti: are you upset?
<pitti> Kinnison: no, what about?
<Kinnison> pitti: nano
* Kinnison is
<pitti> Kinnison: I just wondered why my vim commands produced strange results :)
* Kinnison grins
<Kamion> Kinnison: what why? it's better than vim as default editor
<Kinnison> Kamion: I know it is; unfortunately I hate it :-)
<Kamion> you know where $EDITOR is :)
<Kinnison> I know where sudo update-alternatives --config editor is
<pitti> that must have been changed very recently
<Mithrandir> pitti: it's a nice revenge for emacs not being installed on chinstrap
<pitti> *giggle*
<pitti> Mithrandir: I'm on concordia, btw
<koke> elmo: while true;do w3m -dump $URL;sleep 5;done ??
<Mithrandir> pitti: I read that.  Still a nice revenge
<koke> or is the page too big?
<tseng> seb128: ok.. what I did was
<elmo> koke: well I kinda wanted it interactively
<tseng> seb128: i took the cvs revision of gstqueue.c with the fixes, looks like the only ones since release to that point, and diff'd it
<Kamion> pitti: yes, I changed it a week or two ago
<tseng> that patches werent quite clean
<Kamion> vim 1:6.3-046+1ubuntu4, 1 Mar 2005
<pitti> Kamion: ah, you mean as a general default? Agreed, nano might make more sense
<pitti> Kamion: I thought elmo changed it locally on concordia :-)
<Kamion> pitti: oh no, general default changed, I guess he just upgraded
<pitti> he did
<pitti> because yesterday I still got vim
<tseng> seb128: actually that also pulls in a fix for http://bugzilla.gnome.org/show_bug.cgi?id=166250 .. which isnt adverse
<seb128> tseng: <tseng> that patches werent quite clean
<seb128> tseng: what do you mean ?
<tseng> the patches on bugzilla were against cvs
<tseng> one didnt apply cleanly to our package
<seb128> oh, k
<tseng> so i looked at cvs, and I did it this way
<tseng> pulling in another trivial fix
<tseng> but I think thats fine
<seb128> nice
<seb128> does it fix the issue for you ?
<seb128> where do you have the issue without the fix ?
<tseng> just finished building
<tseng> i have issues with skipping in mp3s in muine
<tseng> so do several others
<seb128> muine also
<seb128> lemme try muine
<tseng> it seems fixed here
<tseng> seb128: do you want my source package, or just the patch?
<seb128> patch is enough
<tseng> np
<seb128> but I would like to have the bug first
<tseng> ok.
<seb128> just listening on a mp3 and it skip during the play ?
<tseng> after 3 seconds
<tseng> it makes a seek
<tseng> missing a few seconds of the song
<tseng> it seems to be every mp3 for me, some people claim some arent affected
<schweeb> tseng: oggs too?
<tseng> schweeb: no
<schweeb> k
<schweeb> I'll test in a few
<tseng> ok
<seb128> tseng: I don't get the bug but I'm happy to use a fix from the CVS in the package if it works for you
<tseng> seb128: http://getsweaaa.com/~tseng/gstqueue-fix.diff
<seb128> tseng: can you attach it to the bug I pointer before ?
<tseng> yes
<seb128> thanks
<tseng> seb128: posted
<seb128> ta
<tseng> np, thanks for having a look
<sivang> does anybody know if pitti is supposed to come back?
<seb128> I think so
<thom> well, given the meeting's in an hour, i guess so
<sivang> pitti: rehi :)
<pitti> reho
<pitti> sivang: changed net connection
<sivang> pitti: better now?
<svenl> daniels: there, patch for xresprobe is in #7144 attachement, i believe it is easy enough to use for hoary-post-preview, and anything beyond that would need a more complete rewrite, which should be post-hoary, but i would gladly participate in it.
<svenl> daniels: adding support for multiple head and such.
<pitti> sivang: no, before I was on WLAN, but I don't get on my desktop with this
<pitti> sivang: now I'm on NAT over my desktop, so I can also ssh to it
<Kamion> svenl: oh, I tested CD boot on pmac with fs_of.diff, worked fine
<Kamion> svenl: haven't yet had time to try either hard disk boot with that diff, or anything with the other diff
<sivang> pitti: ah cool, it's nice to have the desktop as a "development server" when sshing to it from the laptop
<pitti> sivang: any news with the gcm patch?
<sivang> pitti: finished, testing now
<svenl> Kamion: i failed to get fully booting from CD working, but both harddisk booting (provided the kernel is on a filesystem supported by yaboot) and netboot works.
<sivang> pitti: (with all the nitpicking)
<svenl> Kamion: i could mail you the upgrade, and you could try a netboot on occastion, and we fix yaboot-installer to also work on pegasos.
<svenl> this would let only two remaining problems for the pegasos support : 
<svenl> 1) X doesn't failback on pcigart if agpgart doesn't work, but X still works in unaccelerated 2D mode.
<svenl> 2) initial boot from CD is still broken.
<sivang> pitti: bah, there's some assertion failing now, checking to see if it's upstream or my fault
<pitti> sivang: if it didn't occur before, it's yours :-)
<svenl> am working on 1) now, and 2) should be solved by the new OF update i am preparing, don't have an exact date though.
<svenl> Kamion: when is hoary official release date ? 
<thom> april 6
<svenl> Ok, i will try to have the OF update released by then.
<svenl> BTW, i am thinking of bundling a ubuntu/hoary powerpc CD with each pegasos board sold or distributed, is there any formalities on doing so ? 
<svenl> thom: what about the kubuntu release ?
<dholbach> re
<schweeb> tseng: there?
<tseng> yes
<schweeb> tseng: what exactly was the muine bug?
<tseng> schweeb: skipp after 3 seconds on mp3s
<schweeb> a skip in the first few seconds of a song?
<schweeb> yep
<schweeb> got it here
<Nafallo> dholbach: welcome back :-)
<dholbach> hi Nafallo :-)
<tseng> schweeb: ok. standby for a fix
<schweeb> kk
<tseng> latexer tested the patch also
<tseng> schweeb: hopefully have it in ubuntu sometime today
<schweeb> tseng: I noticed that problem like last week, but I thought it was a problem with how the mp3s I had just downloaded were encoded, heh
<Kamion> svenl: mail upgrade> yeah, that'd be good; then I could get yaboot-installer working properly with the confidence that I can test it
<sabdfl> svenl: no formalities required, please go ahead!
<tseng> schweeb: nope.
<sivang> pitti: think I've found it
<tseng> hi sabdfl 
<svenl> sabdfl: hi, you are Mark, right ? 
<Kamion> happy to test pegasos netboot installs at least
<Kamion> and make 'em work
* sivang would love to lay hands on a pegasos machine, desktop OR laptop :-)
<svenl> but i guess that it would be nicer if the pegasos was officially listed as supported.
<svenl> sivang: hehe.
<pitti> Is it just me, or do other people also get nasty authentication error questions with apt-get?
<svenl> no laptop yet
* svenl can't comment on unannounced products and the like :)
<sivang> svenl: I've heared about plans :)
<Kamion> svenl: "officially" => i.e. in the installer manual and such?
<svenl> Kamion: can your email get 640K attachements ? 
<svenl> sivang: "can't comment on unannounced products".
<sabdfl> svenl: if you can work with kamion to ensure it works first time every time, we can integrate patches to docs etc with pleasure
<Kamion> svenl: mail cjwatson@riva.debian.net, I think that should work
<sabdfl> also, we can list the service / products you provide in the marketplace pages, or elsewhere on the site like the hardware database
<Kamion> (batch SMTP hack)
<svenl> Kamion: whatever you mention as officially supported, even if there are some erratas. I have not yet looked at the manual, so i don't know if it entails any change.
<Kamion> yeah, there'll be a manual change and I guess general web site docs
<Kamion> I don't know if the CD packaging has been finalised yet, but if CD boot isn't going to work in time then that's a non-issue anyhow
<svenl> Kamion: as far as i understand, you would just need the right boot cd yaboot line documentation, and the rest should be self documented in d-i :)
<Kamion> oh, cd booting will work?
<svenl> Kamion: no problem, you mention "supported provided you upgrade to OF version xx"
<Kamion> right
<svenl> Kamion: sure, i just didn't manage to fix it until yesterday 16h00 :)
<Kamion> yeah, understood, OF hacking => non-trivial
<svenl> and OF hacking without the board with removable flash is non-fun.
<Kamion> heh
<svenl> nono-productive also, as it stops as soon as you make a mistake and kill the flash.
<sivang> svenl: hehe ok, are you close pegasos company? :)
<svenl> sivang: i am pegasos company :)
<svenl> (well partly).
<Kamion> I really must actually serial-console the Pegasos or get a KVM switch sometime before the heat death of the universe
<sivang> svenl: oh 
<svenl> Kamion: serial console is great.
<sivang> svenl: I'm struck
<svenl> Kamion: well, gnome on serial console doesn't make much sense, but hey.
<Kamion> if I'd thought about it I'd have done it together with the DVD+RW order I just put in
<sivang> svenl: you also work on morphos?
<svenl> Kamion: mmm, there is a little yaboot/keyboard/serial console too.
<svenl> sivang: nope, i did the linux/debian/debian-installer/parted/whatever stuff, organized free giveaway of machines, and do some OF development lately.
<svenl> (among others).
<svenl> sivang: absolutely no link with morphos, don't even have it installed.
<svenl> Kamion: BTW, i guess the livecd will need its own fixing, right ?
<mdz> seb128: here
<Kamion> svenl: for what?
<seb128> mdz: is the meeting planning open to changes ?
<shaya> kernel abi seems to have been broken again
<seb128> mdz: ie: I've some stuff to put on it
<mdz> seb128: certainly
<pitti> Hi mdz 
<mdz> seb128: the gaim/panel crash happened again while I was asleep
<mdz> seb128: this time I had -dbg installed
<seb128> nice
<mdz> I forget the bug#; you closed it right?
<seb128> yep, WORKSFORME
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=7319
<svenl> Kamion: that ubuntu-installer works on peg doesn't guarantee that the live-cd infrastructure works.
<mdz> thanks
<Mithrandir> lamont: I think that mount should be librarified and have callback hooks if it needs to prompt the user somehow (think smbmount).
<Kamion> svenl: oh, I see. but the live CD infrastructure is basically just d-i with a few extra tweaks; if d-i works, then the live CD should too.
<Kamion> svenl: (assuming you can boot it)
<shaya> is there a new -4 kernel package in the works?
<svenl> Kamion: ok, cool.
<Kamion> shaya: 2.6.10-26 was uploaded earlier today
<shaya> madwifi can't load with current image/restricted set
<lamont> Mithrandir: ew
<Kamion> ... but had nothing to do with madwifi
<svenl> Kamion: for documentation, the pegasos will not be able to boot by pressing 'c' like the macs, you need to hand enter "boot cd /path/to/yaboot".
<lamont> Mithrandir: mount is _supposed_ to stay simple...
<Mithrandir> lamont: you also want to be able to prompt the user for stuff like crypto.
<lamont> Mithrandir: is that what you wanted to chat about?
<Mithrandir> lamont: yeah
<shaya> linux-source-2.6.10 (2.6.10-26)  / linux-restricted-modules-2.6.10 (2.6.10.3-5) is causing me problems
<Kamion> svenl: ok, noted, thanks. I didn't really expect the 'c' trick to work on non-Macs ...
<Mithrandir> lamont: basically to see your response and listen to any great ideas you might have. :)
<lamont> yeah..  I understand that... it just makes my brain hurt
<shaya> revert to old -3 kernel and it works
<Kamion> svenl: um - should that be 'boot cd:,/path/to/yaboot'? or is there magic to make the space work?
<Mithrandir> lamont: it would remove the need to patch mount for lots of silly things, though
<mdz> development meeting on #ubuntu-meeting in 2 minutes
<shaya> linux-image-2.6.10-4-686
<Mithrandir> mdz: uhm, isn't that 7 minutes? :)
<mdz> is my clock wrong?
<mdz> Fri Mar 11 16:57:57 UTC 2005
<lamont> 6.5 min, but yews
<svenl> Kamion: also about yaboot, it seems to me that the yaboot.conf in same place as yaboot is disabled in yaboot in chrp hardware.
<svenl> need to check.
<mdz> 11 Mar 08:53:42 ntpdate[20848] : step time server 82.211.81.145 offset -269.973498 sec
<svenl> Kamion: boot <device> <file> <args> is the current syntax.
<Kamion> svenl: oh, do I still need to add /etc/yaboot.conf? will a symlink work there, or does it need to be a copy?
<svenl> but the other should work also, is more involved though.
<Kamion> ok, cool
<svenl> no, a symlink should be ok.
<svenl> (provided your tftp server supports copies).
<Kamion> tftp? on a cd?
<svenl> I believe both yaboot's ext2 code follows symlinks, and i implemented the functionality in pegasos-of ext2 code.
<svenl> ah, well.
<Mithrandir> lamont: do you have any other great ideas?  (Except possibly "fork mount", but I would like to avoid that)
<svenl> for now the symlink would be best.
<svenl> unless you patch yaboot that is.
<Kamion> ok, consider it done
<sivang> we have a development meeting today right?
<zul> yep
<svenl> Don't know how it works on isos, since it uses the OF code, but i will make sure our OF does the right thing.
<svenl> hi zul.
<seb128> mdz: I would like to switch eds and friends from heimdal to libkrb5, any opinion on this ? Firefox and OO.o2 use libkrb5 ... and since heimdal-dev and libkrb5-dev conflict ... any opinion on this ? 
<zul> in 4 minutes if my clock is off
<zul> hi svenl 
<sivang> zul: phew, I thought I missed it
<svenl> Kamion: will you merge the fs_of.c patch ? 
<lamont> Mithrandir: I think the callbacks are probably the best answer..  must poinder it some
<seb128> mdz: I've rebuilt it here with librkb5, seems to work fine, and that's easy to revert if we have an issue before hoary with it
<mdz> seb128: that's OK with me
<seb128> k, I'll do it so, thanks
<Mithrandir> seb128: nice, thanks.
* lamont takes a 1 min typing break
<seb128> Mithrandir: you're welcome
<Kamion> svenl: will have to test more on pmac, but apart from that yeah
<elmo> pitti: is it you looking at this ntp horkage on first start?
<Kamion> svenl: although I might change it around a bit if you don't mind - "is_not_iso = 0;" makes my head hurt :)
<sabdfl> Kamion: any idea how long Apple boxen have had 700MB-capable cd-rw's?
<svenl> Kamion: if you could also try the partition.c patch instead ? I think it is quite broken to have the partition code report one partition on a iso cd ?
<Kamion> sabdfl: no, sorry
<Kamion> the partition.c patch scares me, I don't know enough about why that's there
<Kamion> but I'll give it a go
<pitti> elmo: EWORKSFORME
<pitti> elmo: do you have any further info?
<Kamion> svenl: /etc/yaboot.conf -> /install/yaboot.conf symlink on the CD done
<elmo> pitti: yes, it's entirely reproduceable on any hoary server I have here or warty ones running the ntp backport
<pitti> elmo: _what_ is reproducible?
<pitti> elmo: can you please mail me? meeting begins now
<elmo> pitti: ntp doesn't start because it claims to be able to unfind the ntp user
<pitti> uh?
<svenl> Kamion: and "boot cd install/yaboot" to boot then.
<mdz> amu: #ubuntu-meeting
<Kamion> svenl: ok, no initial slash needed?
<svenl> Kamion: if it works for you i will audit the yaboot code and check.
<svenl> Kamion: nope, it can be put, but per default it adds it.
<pitti> elmo: ntp-simple?
<Kamion> 'k. development meeting now, need to concentrate on that
<Kamion> ok, cool
<elmo> pitti: yep
<svenl> Ok, let you to your meeting.
<elmo> pitti: if you can't multitask, it can wait, don't worry
<pitti> elmo: just installed ntp-simple, now the server runs. what now?
<elmo> pitti: reboot
<elmo> seriously, it only happens post-reboot
<pitti> erm, later then
<pitti> elmo: okay, I will try this after meeting when I can reboot again
<Kinnison> Anyone here successfully got gaim-encryption working in hoary?
<dholbach> Kinnison: yes
<dholbach> Kinnison: if you enabled it in the plugins section, things should be fine
<dredg> Kinnison: yeah. i have 2.35 waiting to be uploaded... after i get some sleep though
<Kamion> Mithrandir: will you be uploading oo.o-amd64 for ia64 support? I'd like to get those seeds sorted out and various hacks removed sooner rather than later
* Kinnison is having problems getting it to recognise a key exchange with a rhel gaim-encryption instance
<pitti> ogra: yeah, 2.6.11 might still contain the broken inotify code
<Mithrandir> Kamion: yes, but there's another hack I want to get in there.
<Kinnison> dredg: did the protocol for key exchange change?
<schweeb> Kinnison: yes, works for me
<ogra> eh, sure, since its form beginning of feb
<dredg> Kinnison: no, just bug fixes iirc
* Kinnison hmms
* Kinnison decides to blame the RHEL end of the thing
<sivang> pitti: ok, fixed it, preparing new debdiff and pkgs
<Kinnison> :-)
<schweeb> it's working fine for me ubuntu->ubuntu... don't have anyone else using it that's not on ubuntu
<dredg> Kinnison:      2.35    Workaround for Jabber bug in Gaim
<dredg> that's it
<ogra> pitti: but its a huge difference in the pci database it seems, in 2.6.10 about 60% of my hal entrys are unknown....with 2.6.11 there are only a handfull of these
<pitti> ogra: then bitch fabbione to build a 2.6.11 final kernel :-) I'd love to have this as well to build hardened kernels :-)
<Kinnison> dredg: how much of a workaround is it?
<pitti> ogra: however, this is loooow priority
<Kamion> 2.6.11.2 rather ...
<pitti> yeah
<Kinnison> dredg: and do you have a hoary deb I could try out?
<Kamion> unless there's been a .3 while I wasn't looking
<pitti> Kamion: even if it was, 2.6.11.2 -> .3 is probably a piece of cake, packaging-wise
* pitti is happy to see a stable kernel branch again
<fabbione> *cough*
<fabbione> it's like.. you can build a kernel :-)
<pitti> fabbione: yeah, if I find some time I try to update the current package
<elmo> fabbione: did you see the timings I posted earlier?
<fabbione> elmo: no. i saw the ones in the log. we need to check with 27
<fabbione> the new idiotify patch did invalidate the cache
<elmo> haha
<elmo> idiotify, how very apt
<fabbione> pitti: with all the change sin 2.6.10 not merged in .11 is understandable
<dredg> Kinnison: tiny. it's to do with jabber stripping html
<pitti> fabbione: do you have the 2.6.11 in an arch repo I should branch, or is it just download, modify, upload?
<fabbione> pitti: the latter
<Kinnison> dredg: oh
<dredg> Kinnison: can you ping me about it tomorrow? i've been on the go for about 40 hours at this point and i'm going to bed very soon
<svenl> Kamion: ah, i remember now , we need a backport of the gigabit ethernet driver too.
<Kamion> svenl: I thought we already had that in the Ubuntu kernel; but talk to fabbione or one of the guys if it needs to be updated
<Kamion> I may be mistaken
<Kinnison> dredg: Go to bed then; I'll be around (if not on channel then on-net) for the foreseeable future :-)
<svenl> Kamion: there is a much better patch we worked out with benh and the montavista marvell guys, which is going upstream.
<svenl> Kamion: will backport it to the debian 2.6.10 kernel, and they can apply it then.
<Kamion> jbailey: isn't the 'tail -n +2 /proc/swaps' needed to strip off the header? your patch removes it
<Kamion> svenl: ok
<jbailey> Kamion: I'm looking in the third column for the word partition and doing a continue otherwise.
<Kamion> oh, ok
<Kamion> jbailey: I also have a suspicion that biggest_partition's value will not be preserved when you exit the 'while read' loop
<Kamion> jbailey: 'while read' has a habit of creating a subshell
<Kamion> but ICBW
<jbailey> $ busybox sh partsize.sh
<jbailey> /dev/hda4
<jbailey> Kamion: Also works with posh and bash.
<sivang> pitti: you can take a look at the debdiff already, http://muse.19inch.net/~sivan/g-c-m/sivan-gcm-crack.diff
<sivang> pitti: and the rest is in http://muse.19inch.net/~sivan/g-c-m/
<Kamion> jbailey: you're right, I think I'm thinking of foo | while read
<Kamion> jbailey: could do with fixing the shell quoting and losing the backslashes, but looks good, thanks
<Kamion> works for me in a test install
<Kamion> I'll upload
<jbailey> Mm, yeah, probably good for safety. I hadn't bothered with the quotes since I know what the values are.
* Kamion <- paranoid :)
<Kamion> but you're right, shouldn't matter unless /proc/swaps goes insane
<jbailey> Perhaps it's a proximity to kinnison and elmo thing ;)
* Kinnison looks confused
<Kamion> :)
<schweeb> Kinnison: he meant kamion
* T-Bone hands over an album of Black Sabbath to Kamion and ducks :}
* Kinnison looks confused still
<dredg> Kinnison: try http://niall.evil.ie/ubuntu 
* Kinnison wonders if bazaar will give him some IO cycles
<Kinnison> dredg: looking
<dredg> Kinnison: if 2.35 kills your family/eats your pets/steals your last rolo then i'll disavow all knowledge of your intentions
<Kinnison> yep
<dredg> :)
<Kamion> schweeb: I doubt he did, actually :)
<schweeb> oh well, heh
<schweeb> Kamion: oh, didn't realize kinnison = daniels
<Kamion> kinnison definitely != daniels :)
* Kinnison gets out the flamethrower and sets it to *Uberburn*
<Kinnison> Kamion: can I burn him, can I can I?
<Kinnison> dredg: well, it didn't kill gaim dead
<schweeb> bah
<Kinnison> dredg: when my RHEL toting friend is back I'll try it
<Kinnison> dredg: thanks for the preview
<schweeb> I'll stfu
<mjg59> zul: Yeah, that swsusp patch is obviously correct
<mjg59> (And fixes some data corruption issues)
<zul> mjg59: ill push to fabbione for -27
* koke 's going to try his new wireless card :)
<Kamion> schweeb: (there's an important extra "Silver" in the name ...)
<dredg> Kinnison: good start :) you'll have to restart gaim (though i assume you know that)
<Kinnison> dredg: Yep; and did
<dredg> Kinnison: good stuff, let me know if it works...
<Kinnison> dredg: I assume I don't need server support for this to work
<dredg> Kinnison: no, it's client<->client
<mantiena> hi all
<schweeb> Kamion: heh, oops.  too similar of names
<Kinnison> dredg: good good
<mjg59> zul: Cool, thanks
<Mithrandir> Kamion: ooo-amd64 uploading later tonight, I need to run off for a couple of hours now.
<dholbach> bye Mithrandir 
<dredg> Kinnison: let me know how you get on. i can install some version of rhel on my laptop or on another partition for testing
<T-Bone> Mithrandir: thank you so much :)
<Mithrandir> T-Bone: my pleasure.  You owe me beer when we meet. :)
<Kamion> Mithrandir: awesome
<T-Bone> Mithrandir: definitely ;)
* lamont brbr
<lamont> brb even
<T-Bone> lamont: think about some mail whenever you can... :)
* T-Bone hides
* lamont is back
<T-Bone> that was quick :)
<lamont> yeah
<lamont> I said brb after all.
<svenl> daniels: ah, i believe i have the pcigart fallback patch, appending to the bug report.
<mantiena> mvo: hi, are you online ? I have some suggestions (sort of bugreports) about package management to you ;)
<mvo> mantiena: can you send to me by mail? I'm in a meeting right now 
<mvo> mantiena: we can talk tonight (in ~3-4h) or tomorrow :)
<mantiena> mvo: ok, I can wait
<mvo> mantiena: thanks! I'm looking forward to talk with you :)
<svenl> daniels: there, i also have the patch for the pci fallback, untested though, but seems transparent enough.
<svenl> Now, X should be solved, and i can see about the kernel patch backport for 2.6.10 kernel marvell gige support, and then test the yaboot stuff once Kamion has tested it.
<svenl> Kamion has ported yaboot-installer.
<mjg59> Anyone with an HP laptop around?
<fabbione> mjg59: i have a compaq
<mjg59> fabbione: HP Compaq or pre-merger?
<fabbione> pre-
<mjg59> Ah, right. Probably not the same, then.
<fabbione> Armada M700
<trukulo> mjg59, me
<trukulo> nx9005
<mjg59> trukulo: Does your sleep button generate ACPI events?
<trukulo> mjg59, yes
<trukulo> i mean, no
<trukulo> i don't have sleep button
<mjg59> Ah. Heh.
<trukulo> but lid does
<mjg59> This has an ACPI sleep button that appears to do nothing
<ogra> sounds like acer
<trukulo> mjg59, use xev to see if key is being logged
<trukulo> you know what i mean
<mjg59> trukulo: Yeah. No keycode that I can see.
<trukulo> mjg59, it's a keyboard problem then, i have the same problem with mute button
<trukulo> there was a patch for kernels, omnibook patch, i think
<mjg59> The DSDT has a sleep button in it, though, which confuses me
<Cym> gday
<Cym> Are there any apache developers around?
<dholbach> Cym: they are all in a meeting
<Cym> awe thanks dholbach
<mjg59> Clearlooks looks funny when things have those bouncy left to right to left progress bars
<T-Bone> https://bugzilla.ubuntu.com/show_bug.cgi?id=7468
<T-Bone> Kamion: ^^^ any clue?
<Nafallo> mjg59: agreed :-)
* T-Bone supposes that's a direct result of cloopfs not building on ia64
<Kamion> T-Bone: correct, the live CD cloop is ancient
<T-Bone> Kamion: ok. I'll post a comment explaining that
<T-Bone> Kamion: the blocker for cloop is mozilla shit, right?
<Kamion> T-Bone: I have the dates and such; I'll reply
<T-Bone> ?
<Kamion> lamont: all cloop builds on ia64 for some time have died with:
<Kamion> rm: cannot remove directory `/build/chroot-livecd//dev': Device or resource busy
<Kamion> lamont: can that be cleaned up so that we can at least see the current status?
<lamont> yeah
* lamont needs to track down exactly why it leaves things in that state upon dying, too
<Kamion> T-Bone: but yes, it's firefox AFAIK
<T-Bone> sigh
<T-Bone> i wonder if we could discuss ia64 a bit during the meeting :P
<T-Bone> Kamion: your "I'll reply" meant you'll reply to the bugreport?
<T-Bone> because it's been assigned to me, you see..
<Kamion> T-Bone: oh, I see; well, you can if you like :)
<T-Bone> err
<Kamion> I just replied though, since I had the date when it was last built to hand
<Kamion> and I figured you would not have that easily accessible
<T-Bone> 'like' might not be the word I'd use ;)
<T-Bone> indeed
<T-Bone> i shall thank you
<T-Bone> 8)
<Kamion> and it seemed like useful information
<lamont> Kamion: fresh build launched
* T-Bone wonders if some firefox guru will stand up...
<T-Bone> though i'm pretty convinced that's a combination of things, since it doesn't affect debian but is reproduceable with debian packages
<T-Bone> unfortunately i'm clueless wrt firefox and that kind of stuff
<mxpxpod> fabbione: ping
<fabbione> pong
<Seveas> ...or tetris
<mxpxpod> fabbione: how long does it take to make a linux-image?
<GheRivero> res
<fabbione> it depends from a lot of things
<fabbione> from 30 minutes to several hours
<mxpxpod> fabbione: I'm waiting for 2.6.11... I tried building my own, but it didn't work quite right
<thom> mxpxpod: how fast is your machine, which architecture, ...
<tseng> daniels: dude. dlloader support for nvidia
<fabbione> .11 is no priority for me right now
<mx|gone> fabbione: I figured :)
<fabbione> we are going to release with .10
<fabbione> and i might ask elmo to remove .11 from hoary
<fabbione> that is the sanest thing to do 
<fabbione> to avoid confusion
<mx|gone> fabbione: ah, ok
<mx|gone> gotta go
<T-Bone> fabbione: definitely
<crimsun> fabbione: I agree with removing .11 from universe
<trukulo> fabbione, i agree
<trukulo> fabbione, and put lion with broken leg as hoary wallpaper
<trukulo> http://mercurio.homeip.net/ficheros/ubuntu-lion.png
<pitti> ogra: you can try to find out the hal slowness; I have no idea about it and it works for me
<ogra> pitti: hal slowness ?
<ogra> pitti: not here
<pitti> ogra: later
<ogra> pitti: was fixed by an upload right before my last patch went in
<pitti> ogra: oh, cool
<ogra> i told you back then ;)
<ogra> youre to busy ;)
<pitti> ogra: #6879 and #6002
<pitti> ogra: I think this might still be an issue
<pitti> ogra: now that you know the hal guts... :-)
<ogra> pitti: i'll look at them
<pitti> cool, thanks
<ogra> :)
<mdke> are you guys in a meeting?
<mdke> don't want to disturb if so
<tseng> yes, but I can try and help you
<mdke> tseng, thanks its simple. I want to know if our wiki can handle icon insertion with the MoinMoin markup.
<tseng> as in an image?
<mdke> specifically the images hosted on the wiki
<mdke> like those which appear on the FrontPage for example
<tseng> can you just try it?
<mdke> i have
<mdke> and i've searched a lot
<tseng> you know more than I do, unfortunately
<mdke> its the sort of thing that one person might know
<sm> I can answer that, if you point me to an example of the markup
<mdke> sm, of moinmoin markup?
<sm> yah
<mdke> erm
<mdke> RestrictedFormats
<mdke> http://www.ubuntulinux.org/wiki/RestrictedFormats
<mdke> for cliccability
<sm> ok, what should I search for at http://www.ubuntulinux.org/wiki/RestrictedFormats/src
<mdke> sm, what do you mean?
<sm> if this is OT, let's go private
<mdke> ok
<thom> Kamion: are you coming down to gllug tomorrow?
<Kamion> thom: yep
<Kamion> thom: see you there?
<thom> coolcool
<thom> indeed
<svenl> Kamion: you have email.
<svenl> Kamion: please tell me ASAP once you flash the prom, as i would like to know the result. There should be no problem, but it is for my own peace of mind.
<Kamion> svenl: ok, will do
* Kamion adds ubuntu-base and ubuntu-ship Task: headers to the CD's Packages files
<svenl> :)
<Kamion> this is to help out archive-copier
<Kamion> I may rename to something other than Task: at some point, to avoid them showing up in aptitude
<thom> so, on the dvd front - buying such a best, should i be looking at dvd-rw or dvd+rw? (assuming i can't find a burner capable of both)
<thom> "such a beast"
<Kamion> I went DVD+RW, not with any actual knowledge though
<Kamion> actually "DVD+-R/RW"
<Kamion> whatever that means :)
<Kamion> 40 quid or so from dabs
<thom> that's pretty good
<Kamion> svenl: yaboot-installer already does the append="console=..." thing :)
<svenl> Kamion: cool.
<svenl> Kamion: i was not sure, as serial console and pmacs, well ...
<Kamion> svenl: it's not for console= specifically, it's for anything after the -- in /proc/cmdline
<svenl> Kamion: ah, ... I added console before -- in yaboot.conf.
* pitti 's gf needs attention -> good night for now
<svenl> Kamion: BTW, there is something fishy again with the modules ?
<Kamion> modules?
<svenl> the kernel modules .udeb.
<svenl> insmod /lib/modules/2.6.10-4-powerpc/kernel/drivers/ide/pci/via82cxxx.ko
<svenl> FATAL: Error inserting via82cxxx (/lib/modules/2.6.10-4-powerpc/kernel/drivers/ide/pci/via82cxxx.ko): Invalid module format
<svenl> mmm, the modules are there, so maybe a module/kernel diff in the netboot images? I just downloaded them from the daily netboot builds.
<fabbione> that smells of ABI breakage
<fabbione> but i386 seems ok
<fabbione> so i doubt it can have destroyed the ppc one
<svenl> fabbione: yeah, but maybe i just got a bad vmlinux for my initrd.gz, but i guess there is no way to check that.
<svenl> oh well more test tomorrow.
<Mitario> hey everyone
<mdz> ogra: I can't talk right now, but will you be here later to discuss hwdb rollout?
<ogra> mdz: sure, for you always
<mdz> thanks
* Kamion finishes off for the evening; night all
* sivang is off to restart network
<jani> mako ping
<zenrox> have a question
<zenrox> the nvidia module ant loading with the new kernel
<fabbione> zenrox: works here fine
<fabbione> zenrox: what kernel are you using?
<zenrox> well i tried to do a modprobe it gives me a fatel error
<zenrox> 2.6.10-26
<fabbione> zenrox: what kernel are you using?
<fabbione> and what version of linux-restricted modules?
<zenrox> same
<fabbione> no
<fabbione> what version of l-r-m are you using?
<fabbione> there is no l-r-m -26
<zenrox> l-r-m 686- 2.6.10-6
<zenrox> so how do i fix it
<fabbione> dpkg -p linux-restricted-modules-2.6.10-4-686 | grep Version
<fabbione> that version is old
<fabbione> you need to upgrade l-r-m
<zenrox> ok
<zenrox> whats the name of it on apt-get
* thom -> cook; sleep
<thom> night all
<ogra> gute nacht thom
<fabbione> the one i pasted above
<daniels> god, why did I give STA in the UK my email address?  they're spamming me to tell me that I could travel to Sydney for only GBP399
<Treenaks> daniels: well, maybe you want to go there some day
<daniels> Treenaks: not likely :P
<daniels> but yeah, it costs me about $au65 (for reference: around GBP27) to fly there
<zenrox> fabbione: i wont install
<zenrox> says its allready upto date
<fabbione> zenrox: you don't have the latest version. 2.6.10.3 is the last one
<fabbione> -5 or something
<zenrox> i have lrm 2.6.10-6
<zenrox> and it wont install the other one casue it says its allready uptodate
<fabbione> and it is not the last one
<fabbione> zenrox: do: dselect update -> apt-get install dist-upgrade OR apt-get install ubuntu-desktop
<metallikop> I have a question about a lintian error I'm receiving for package grubconf
<metallikop> W: grubconf source: unknown-architecture
<metallikop> The arcitectures in the control file are :
<metallikop> Architecture: amd64 i386 hurd-i386 netbsd-i386
<metallikop> is this a legit lintian error, if so, how would I resolve?
<zenrox> fabbione: it upgraded then still wont instert the module
<ogra> metallikop,  hurd-i386 netbsd-i386 ?
<Treenaks> metallikop: try adding commas
<metallikop> it doesn't like commas
<metallikop> Treenaks: I tried that already
<ogra> i dont think the buildds know these arches
<fabbione> zenrox: if your system was inconsistet at kernel level, i would suggest at least to try a reboot
<metallikop> seb128: are you around?
<seb128> ?
<zenrox> fabbione:  ok but it probly still wont work
<metallikop> this package was previously maintained by yourself
<metallikop> grubconf
<seb128> not afaik
<seb128> that's news
<metallikop> grubconf (0.5.1-4ubuntu1) hoary; urgency=low
<metallikop>   * Rebuilt with gnutls11.
<metallikop>  -- Sebastien Bacher <seb128@canonical.com>  Thu,  6 Jan 2005 16:53:59 +0100
<ogra> probably synced
<metallikop> ahh
<fabbione> seb128: everything that starts with *G* is your :-)
<seb128> An upload for a transition is different of maintaining a package
<metallikop> fair enough :)
<seb128> fabbione: ah ah :)
<fabbione> where is jdub when i need him :-)
<metallikop> well, what would be the best way to resolve this?
<metallikop> remove those unknown archs?
<ogra> fabbione: ring him up, he slept enough
<lamont> metallikop: that'd be one way
<metallikop> is that the _preferred_ way?
<lamont> other alternatives include adding an override to make it shut up, or just ignoring the warning
<Riddell> lamont: any idea what the status of kdeaccessibility is?  It's compiled fine but marked as Uploaded not Installed
<lamont> Uploaded for very long == NEW
<lamont> well, almost always anyway
* lamont goes to look for real
<fabbione> who has a webcam and knows how to setup flumotion?
<ogra> metallikop: i dont think we have to expect netbsd or hurd in the near future (at least not before the package needs to be touched aain)
<fabbione> after the wizard it hangs grabbing from the webcam
<lamont> Riddell: it was built a while ago, wasn't it...
<Riddell> lamont: yeah, 8th
* ogra has a axis, no need for additional servers
<metallikop> i'd have to agree
<lamont> Riddell: grumble
<Riddell> lamont: what's the crack?
<lamont> log archived..
* fabbione heads to bed
<Kamion> fabbione: hm, that's two ABI-sounding problems with -26 reported so far, sounds suspicious
<lamont> daemon-20050309-2150.log.gz:Mar  8 12:30:03 buildd-mail: Subject: kdeaccessibility_3.4.0-0pre1ubuntu1_i386.changes REJECTED
* lamont ponders
<lamont>  047f2f41f962decc00acc0222338a1b9 82358 contrib/utils optional kttsd-contrib-plugins_3.4.0-0pre1ubuntu1_i386.deb
<lamont> I'm gonna bet on that one.
<lamont> needs an overrides update by elmo
<lamont> then it'll just be NEW instead of REJECTed
<Riddell> what's the likely problem with it?
<zul> later
<zul> https://bugzilla.ubuntu.com/show_bug.cgi?id=6553
<zul> oops...wrong window
<Riddell> lamont: do I need to poke elmo?
<robertj_> I did a fresh install of the hoary preview and Natuilus doesn't handle sftp by default, is this a known missing package omitted for space reasons?
<mdz> daniels: ping?
<mvo> back
<Mitario> mvo, here?
<mvo> hey Mitario 
<Mitario> heya :)
<mvo> how are you :) ?
<dholbach> wb mvo 
<Mitario> mvo, yeah fine :-) you?
<Mitario> finally have time to do some maintainance work -> weekends
<daniels> mdz: pong
<mvo> Mitario: wonderfull! you are busy with real-life right now? school stuff?
<robertj_> no davs handler either
<lamont> Riddell: well, someone does, but he's ESLEEP
<Mitario> yeah i was this week, school, gf, work :)
<mvo> Mitario: ahhh ... gf ;)
<lamont> Mithrandir: can 6438 be closed?
<Mitario> mvo, =_
<Riddell> lamont: what's the problem with that package?
<Mitario> mvo, =)
<mvo> Mitario: a account for froud would be cool, he is working on the update-manager documentation right now
<Mitario> yes i got the messages :)
<mvo> otherwise, I think we are in pretty good shape for release
<Mitario> was just about to create the account but I don't know a way other than IRC to contact him
<mvo> Mitario: ups, sorry. I should have forwarded you a mail from him :/
<daniels> mdz: pong/me yawns, realises it's after 8am, glares at lamont for making him sleepy, and heads to bed.
<daniels> erk
<Mitario> mvo, oh, and I was wondering if you added the Polish translation and i18n improvements by Zygmunt Krynicki
<Mitario> mvo, oh, i'll check again
<mdz> daniels: er, you're still awake?
<Mitario> mvo, the only message I have here is that fround wants to help us :)
<daniels> mdz: i bleed for ubuntu
<Mitario> wait, i'll beagle for it
<mvo> Mitario: I merged the i18n stuff, didn't I CC you?
<Mitario> mvo, uh i guess not
<daniels> although I have passed out a couple of times
<mdz> daniels: I assumed you missed the development meeting because you were asleep
<Mitario> mvo, but thats fine :) i just wasn't sure if it was comitted already, so good :-)
<daniels> mdz: lurked for most of it, was passed out for some
<lamont> daniels: ??
<daniels> alarmingly, my chair makes a far better bed than my bed (i don't wake up sore)
<daniels> in any case, i wasn't really with it much (still feeling rather unwell, plus it was late), and nothing came up relevant to me, so I just lurked
<lamont> Riddell: kttsd-contrib-plugins needs to be added/fixed in the overrides file, and then the uploads reprocessed
<Mitario> btw, I must say the new Human theme rocks, compliments for the one who created it :)
<lamont> Mithrandir: still around?
<mdz> daniels: what would be the best way to retrieve the string identifier from a monitor?
<mdz> daniels: is that a DDC thing?
<lamont> eep. must fetch kidlets
<mdz> Mitario: I will pass on your feedback
<robertj_> mdz: should I file a but about nautilus not handling sftp/webdav by default?
<robertj_> %s/but/bug
<Mitario> mdz, thanks :)
<mdz> robertj_: it does handle them by default
<Mitario> mvo, oh, by the way i forwarded a Greek update-notifier translation to you
<robertj_> mdz: I just did a fresh install and i'm getting the error that they don't have a handler
<mvo> Mitario: don't you have access to the u-n svn?
<mdz> robertj_: a fresh install of hoary preview?
<robertj_> yeah
<Mitario> mvo, yeah I have, but i still haven't checked out my local copy :)
<Mitario> I can't even remember the address anymore
<mvo> Mitario: heh :)
<mvo> I can commit it
<Mitario> mvo, it is still kerneljanitors right?
<mvo> Mitario: yep
<Mitario> ahh, ok, i found it then :)
<Mitario> damn I really should spend less time reading mail and do more hacking/usefull stuff
<robertj_> mdz: i386 preview cd install, and no love from sftp handlers
<tritium> The latest kernel updates break loading of at least some modules, such as nvidia, and prevents the mounting iso9660
<tritium> from dmesg: disagrees about version of symbol struct_module
<mdz> robertj_: ok, please file a bug.  Please collect as much information as you can (e.g. ~/.xsession-errors), because it's likely that this is working for others (since it works for me)
<Mitario> mvo, so you think we can release update-manager 0.38?
<robertj_> mdz: could it be the ssh server?
<robertj_> and a bogus error msg?
<mvo> Mitario: it depends on latest python-apt and synaptic
<Mitario> latest released? or latest tla
<mvo> python-apt 0.5.36ubuntu1
<Mitario> is it available upstream somewhere?
<mvo> synaptic-svn (but be releaed very soon)
<Mitario> ok
<Mitario> keep me updated :-)
<mdz> robertj_: I don't know
<robertj_> hrmm, not playing nice with my warty machine upstairs :(
<robertj_> nothing in xsession except wining about gnome-cups-icon continaully
<mvo> Mitario: did you commited the translation
<Mitario> mvo, no, not yet, shall I?
<mvo> Mitario: go ahead :)
<Mitario> ok :)
<mvo> Mitario: if you have time
<Mitario> mvo, yeah sure :)
<mvo> cool, thanks :)
<robertj_> mdz: when you initially create the connection do you do it through the connect to server dialog?
<mdz> robertj_: yes
<Mitario> mvo, ok comitted
<mvo> Mitario: great, thanks
<Mitario> mvo, did you have fround's e-mail?
<zul> heylo
<toresbe> g'day
<HiddenWolf> Why does evolution have an icon in the office menu?
<mdz> thom: ping?
<pi> I upgraded to hoary, and XFree is still installed and running by default...does anybody know what i can do to run Xorg instead?
<HiddenWolf> pi: install xserver-xorg
<jon1012> pi, dpkg-reconfigure Xorg ?
<jon1012> oh well, dpkg-reconfigure xserver-xorg if you have already installed it
<pi> it is installed, i will try dpkg-reconfigure
<jon1012> no ? :)
<jon1012> ok :)
<pi> jon: do you know if this configuration does anything other than create an Xorg.conf?
<jon1012> yes, normally it allows you to choose between xservers
<pi> hmm ok i guess i will bare through it then (by nature i tend not to trust the auto config tools because of dual monitors)
<mdz> Kamion: ping?
<mdz> thom: (re: firefox upload)
<mdz> Kamion: (re: $LANG in d-i for xserver-xorg.config, #7138)
<jon1012> ok
<mdz> pi: sudo apt-get install ubuntu-desktop
<mdz> pi: in the future, please ask support questions on #ubuntu, this channel is for development discussion
<dholbach> i'm out ... see you later
<pi> mdz: i was referred here from #ubuntu,  it was "odd behavior"
<mdz> pi: it's a known bug that upgrades from Warty to Hoary are not perfect yet; it is necessary to pay attention to the proposed upgrade before executing it (or packages that you need may be removed)
<pi> mdz: that's understandable, thanks
<mvo> bye dholbach 
#ubuntu-devel 2005-03-23
<ogra> hmmm, /dev  12G  4,6G  5,9G  44% /.dev why is it this big ?
<ogra> ahh, nm, i'm blind
<Seveas> ogra, you know how df works, right? :)
<ogra> partly, yes (never hecked the source ;) )
<ogra> checked even
<GheRivero> res
<zul> lamont: ping
<lamont> ack
<zul> check out kernel
<zul> er, #-kernel
<zul> abi breakage
<thom> mdz: ack
<thom> mdz: sorry, sleep time. 
<zul> kernel is building bbiab
<mvo> mdz: send you a mail about the package-queueing
<mdz> mvo: thanks
<mvo> mdz: do you have a moment for two additional questions?
<mdz> mvo: yes
<mvo> mdz: I think #7419 is a apt bug, how should we proceed? trying to solve it in apt? or trying to work around it?
<ogra> thom: bah, sleep is for past release.....
<mdz> mvo: we should work around it; I think changing the problem resolver would be crazy
<mdz> mvo: maybe for hoary+1 we should think about using aptitude's resolver
<mvo> mdz: I looked at aptitudes algorithm and it's not really seperated, but I agree that we should try to fix it. IIRC apt-rpm has some fixes too that may be usefull
<mvo> (or may not)
<mdz> my standing opinion has been that we need a test suite before we can make that kind of change
<mdz> otherwise by fixing one case, we break another
<mvo> agreed, at least we need some regression testing code
<mvo> mdz: how would you like to see #6761 fixed? as part of apt itself (like the current auto-clean)? or as part of the new apt periodic cron-job 
<mvo> ?
<doko> mvo: pong
<ogra> YokoZar, ?
<mdz> mvo: I think we should add an option to cron.daily/apt
<mdz> mvo: I think the ideal solution would be a combination of the two ideas I presented
<mvo> mdz: all right, will look at it. thanks!
<mdz> mvo: e.g., APT::Cache::Min-Age and APT::Cache::Size
<mdz> (Cache::Archives perhaps)
<mdz> mvo: meaning "Remove files older than Min-Age, until the cache is smaller than Size" or some such
<mdz> mvo: it will be tricky to choose defaults which will be good for both stable releases and development systems, though
<mdz> mvo: perhaps it would be better to keep it simple
<mdz> I'm open to suggestions
<mvo> mdz: what do you think about making it either: age (e.g. 10 days) _or_ size (<300Mb)?
<mvo> mdz: I'll think about it a bit and add something to the bugreport
<mdz> mvo: ok, but let's implement something soon, so that it can be tested for a good long while
<mvo> mdz: ok, I'll make it priority
<YokoZar> ogra: arr?
<ogra> YokoZar: to late, i mailed you back
<ogra> YokoZar: you didnt answer my question in the mail, are winetools 100% compatible with the wine packages currently in universe (does the config work for them ?)
<YokoZar> Yeah
<YokoZar> I thought I did, sorry
<YokoZar> Winetools works in the user's home directory, mucking about with .wine - it works with the debian wine packages, but those only work if a user installs every component (since they're needlessly split)
<ogra> YokoZar: you said they only depend on wine, which was not what i asked ;)
<bluefoxicy> http://www.openoffice.org/issues/show_bug.cgi?id=41966 this issue is fixed in the new openoffice 2.0 beta
<bluefoxicy> but exists on ubuntu
<ogra> YokoZar: thats why i was asking but the above sounds good :)
<mvo> Mitario: got some jabber errors :/
<crimsun> bluefoxicy: in the openoffice.org2 packages, too?
<bluefoxicy> crimsun: 1.9.74 is affected, 1.9.79 is not
<bluefoxicy> Ubuntu uses 1.9.74
<crimsun> k
<bluefoxicy> http://www.openoffice.org/issues/show_bug.cgi?id=44764 has an example file
<YokoZar> When I have evolution open and click a mailto link in firefox it opened a new copy of evolution on me (rather than just a new mail message) - can someone else confirm this behavior?
<ogra> nope, worksforme
<Mitario> mvo, oh :(
<mvo> Mitario: yeah, and I'm about to go to bed now
<mvo> pretty late :)
<Mitario> mvo, indeed :) i'm going too
<Mitario> nite everyone
<Mitario> just finished my little python library :p
<ogra> night 
<daniels> mdz: yeah, it's DDC
* koke 's going to sleep
<koke> an idea before sleep
<koke> it should be nice if the xscreensaver lock dialog showed a warning, like the gdm one, if you have caps lock enabled
<koke> what do you think?
* mvo  <- bed
<mdz> mvo: night
<mvo> night mdz
<mdz> koke: yes, I agree that would be a good idea
<ogra> night mvo
<koke> mdz: ok, I've it noted in my tomboy ;) tomorrow I'll file a bug on that
<koke> my batteries are low :)
<mdz> koke: that isn't what I meant when I said it was a good idea :-)
<koke> bye
<koke> :P
* ogra sees more work coming along *sigh*
<koke> filing a bug does not meant I'm not going to try fixing it myself :)
<mdz> if I thought it would be a good idea to file bugs about every feature that I would like to see in Ubuntu, I would singlehandedly double the number of open bugs easily :-)
<koke> well, maybe change the "filing a bug" to "write to ubuntu-devel@"
<koke> or maybe if I have one of these bright days, to "send a patch to..."
<koke> :D
<mdz> I would like to find a way to better manage feature ideas
<mdz> neither bugzilla nor mailing lists are very good for this
<koke> wiki/IdeaPool ?
<koke> maybe too chaotic
<ogra> wiki, but idea pool ?
<tseng> well, jdub just made a post on this
<tseng> to pgnome
<tseng> you need to have a well defined spec for feature requests
<tseng> http://jimmac.musichall.cz/weblog.php/Design/Speccing
<jdub> ^ not jdub ;-)
<tseng> yeah uh
<tseng> i meant jimmac, maybe i did a tab complete or something
<tseng> or a brain-o
<jdub> mdz: i'm convinced a slightly different frontend and query would really help
<hsprang> mdz: maybe the feature tracking thing is less a problem of tools but of the way you try to tackle it?
<mdz> jdub: for the suspend/hibernate stuff?
<jdub> mdz: feature requests
<mdz> ah
<mdz> yes, I agree
<jdub> which is pretty much what mark talks about wrt malone
<mdz> hsprang: as jdub says, I think tools would help a great deal
<jdub> different interface, different workflow
<mdz> right, feature requests have an entirely different workflow
<tseng> you could build a spec into the interface
<ogra> jdub: if it ever gets ready
<hsprang> mdz: yes, but the tools can only help if you have a clear idea of the process
<mdz> they should be put into a tracking system in order to store the discussion and status, but bug tracking workflow is all wrong
<mdz> I have some pretty good ideas about process
<jdub> interested people could farm the requests, talk to maintainers about them, and answers to the requests can be saved as documentation of the decision
<jdub> hmm, so you'd have a slightly different search interface for features too
* jdub is tempted to storyboard it
<hsprang> mdz: so, you have the process clearly defined somewhere?
<mdz> hsprang: I wouldn't go as far as to say that it's clearly defined, but I have a clear idea in my head
<mdz> based on experience
* jdub just wishes he could reply to bugzilla mails at this point ;)
<hsprang> mdz: so, you'll have to get it outta your head, document and communicate it, and others can help you find the tools
<mdz> hsprang: that's the usual process, yes
<mdz> hsprang: that's what we do at Ubuntu conferences
<mdz> the next one is at the end of April in Sydney
<jdub> and it's going to ROCK
<hsprang> i doubt i will be able to afford such a vacation until then :(
<ogra> vacation ? 
<hsprang> travel
<mdz> hehe
<jdub> mdz: hey, there was a good interview with you in the local paper
<mdz> more like a week of non-stop work
<jdub> http://www.smh.com.au/articles/2005/03/10/1110417596585.html
<daniels> jdub: hahaha
<mdz> jdub: a what now?
<daniels> jdub: if that's what I think it is :)
<jdub> daniels: ;)
<daniels> jdub: yeah.  'twas on the sidebar of theage also
<mdz> oh, my alter-ego
<jdub> mdz: did you see fabio's crazy messages the other day?
<mdz> jdub: I vaguely remember something in all caps trying to wake me up early in the morning :-P
<jdub> mdz: he was calling you his LITTLE BOLD FRIEND
<jdub> he meant BALD
<jdub> but we all agreed he was doubly right ;)
<mdz> my hair is like 2cm long at the moment; it needs cutting
<jdub> yowza
<mdz> it is starting to stick up and curl
<jdub> ('twas an interesting interview though)
<mdz> "It's one of the reasons why George Bush was re-elected," says Moby. "There are a majority of Americans who are scared provincial white Christians.
<daniels> 'provincial'
* ogra hands over one of his ponytail ribbons to mdz
<hsprang> non-stop productive work for a week can be a vacation, too :)
<ogra> hsprang: its rather fun, but you need a week of vacation afterwards ;)
<mdz>      2. Intermission of a stated employment, procedure, or office;
<mdz>         a period of intermission; rest; leisure.
<jdub> heh
<zenwhen> everything was working fine and I did another big upgrade. Now pages are loading slower than molasses. Am I the only person to run into this recently?
<zenwhen> I have no idea what package could be causing it.
<jdub> daniels: 'Since then, though, Goodrem has had 18 months of controversy. She's gone from being the most popular of our recent Neighbours exports to someone described as "the most hated woman in Britain", courtesy of her relationship with a former boy-band singer.'
<jdub> daniels: ha ha 
<zul> hmmm...building kernel fun..
<jdub> yo zul
<jdub> how's inotify in the latest 2.6.11?
<zul> hey jdub how is it giong?
<zul> its inotify 0.20
<jdub> "lazy" saturday morning ;)
<zul> heh
<zul> so its the same that we had in -26
<tseng> zul: you have a .11?
<zul> nope im trying to track down an abi breakage 
<zul> jdub: nice background though for ubuntu desktop though ;)
<mdz> tseng: yes, in universe
<zul> but thats a pre release
<hsprang> bye - need sleep
<daniels> jdub: heh
<daniels> mdz: so udu is an intermission?
<ogra> hsprang: nacht
<mdz> daniels: no?
<daniels> mdz: damn.
<daniels> wtf?  it's more expensive to fly from canberra -> sydney than either of melbourne -> canberra or sydney -> melbourne
<schweeb> was there a kernel upgrade earlier today?  were restricted-modules properly regenerated?  my nvidia module won't load... modprobe says "Invalid module format"
<zul> schweeb: working on it
<schweeb> alrighty, long as someone knows
<zul> yeah thanks 
<tseng> zul: if you get acx in ill test for you
<tseng> zul: i can also test new ipw2200
<tseng> probably neither for hoary
<zul> sure..
<zul> kernel team is just concentrating on 2.6.10 for now, but if you want to do some testing with 2.6.11.x go nuts
<tseng> i care more about those two drivers
<tseng> heh.
<zenwhen> everything was working fine and I did another big upgrade. Now pages are loading slower than molasses. Am I the only person to run into this recently?
<tseng> zenwhen: sounds like you/your isps problem really.
<crimsun> if you rebooted between yesterday and today, possibly.
<zenwhen> tseng, it would sound like that until I boot to windows and dont have the issue with the same nameservers
<tseng> crimsun seems to have a clue
<zenwhen> I was simply trying to see what was causing the issue, not place blame, but it is software.
<zenwhen> crimsun, you have an idea?
<crimsun> zenwhen: it is generally sluggish performance, or specifically network-related or graphics-related, etc.?
<zenwhen> It seems that the DNS resolves, then the page waits about ten seconds to continue loading.
<zenwhen> if I try to load the same page again, it is quick.
<zenwhen> I am really not looking for tech support.
<crimsun> zenwhen: nic spew in dmesg?
<zenwhen> I am wondering if something weird is happenning to other dialup users.
<zenwhen> nope
<zenwhen> nothing since the PPP modules loaded
<crimsun> don't know offhand. Not using ppp* here, however.
<mdz> mako: around?
<jon1012> good night everybody :)
<toresbe> nite
<zul> kernel is still compiling and im going to bed
<crimsun> night zul 
<zul> night crimsun 
<Benoni> Anybody successfully using OpenAFS on hoary?
<svenl> mdz: why your over-cautious remark on #7144 ? and do you think daniels will check it ? he is not usually available all the time, right ? 
<mdz> svenl: daniels works australian hours usually, but he is looking for a new place to live right now and so is on an odd schedule
<mdz> svenl: I am very cautious about changing the X autodetection logic because it is critical functionality and we put a lot of effort into broad testing
<svenl> mdz: well, have you looked at the patches ? 
<svenl> mdz: anyone literate in C will see that it has no effect unless the autodetection failed already.
<mdz> svenl: no, but they are non-trivial, and even trivial patches have introduced bugs for us in the past.  that code is hairy.
<svenl> mdz: please define non-trivial ? Please have a look at them.
<mdz> svenl: there is no need to be aggressive about it.
<mdz> none whatsoever
<svenl> mdz: ok.
<mdz> it will go in if daniels feels that it is safe, otherwise not
<svenl> mdz: sorry, got burned by this whole Ethan/yaboot story.
<mdz> we are very close to release and we _will_ be cautious
<svenl> mdz: but how can you affirm they are none-trivial if you didn't even look at them ?
<mdz> we are in feature freeze since one month, and this is a feature
<svenl> mdz: the xresprobe patch for example, does : 
<svenl> 1) if we failed to find EDID in /proc/device-tree, try the same in /sys.
<svenl> since if you fail to find EDID in /proc/device-tree, your auto-detection is broken anyway, it cannot cause problem.
<_d4vid> hi all
<svenl> mdz: current auto-detection is broken in the multi-head case anyway, for example if the first monitor support more modes than the second.
<mdz> svenl: right, we don't even attempt to support multi-head at this point
<svenl> mdz: and daniels had had a pegasos for over 4 month now.
<svenl> mdz: yep, which is what i noticed, so the patch does exactly the same thing with the radeonfb probed edid as it would have if the /proc/device-tree edid was found.
<svenl> mdz: works on my pegasos and my ibook.
<svenl> mdz: and i am sure you are putting 10 times more intrusive patches in at this time.
<mdz> svenl: it takes some time to adjust to time-based releases, but there is a groove to it
<mdz> and a big part of it is saying "no" at the right times
<svenl> mdz: ok, well.
<mdz> I am not saying that this is necessarily one of those cases
<mdz> because I haven't read the code
<svenl> mdz: Ok.
<mdz> but be aware that we are in that position
<svenl> mdz: yes, i am aware of it.
<svenl> mdz: but it is a bit strange to me how people can claim a patch is non-trivial without even looking at it.
<mdz> svenl: it is a patch to add a feature.  we are in a release phase where we only fix bugs.
<svenl> especially if i know it is of the kind : if (failed to work properly) { do other stuff }.
<svenl> mdz: that is dogmatic.
<svenl> mdz: and exactly the kind of stuff Ethan told me about yaboot, which i find despissable.
<mdz> svenl: it is rigid and boring and it is the way that things have to be in order to get the job done
<mdz> daniels has a list of about a hundred bugs that he has to deal with
<mdz> and they are all higher priority than reviewing your patch
<svenl> mdz: yes, but if you *look* at the patch, dismissing something out of hand without even looking is seriously meprising for the contributors.
<svenl> mdz: yep, but the difference, is that i did the work, that the patches are trivial, and that it would take it at most one minute to decide on them.
<mdz> I don't see why it should make a difference to you whether your patch is merged next week or next month
<svenl> mdz: and i arranged for a free pegasos box for him too, but i ended doing the job.
<svenl> mdz: ah, no.
<mdz> even if it only takes a minute, I would rather that daniels spend that minute fixing bugs for the release
<svenl> mdz: because i would like to have pegasos support in ubuntu, no ? 
<mdz> and apply your patch after the release
<svenl> mdz: yep.
<mdz> but if he has the time to do it, then I think it would be great to have better pegasos support
<mdz> but I understand there is more to pegasos support than this patch
<daniels> svenl: err, when I was sent the Pegasos, I explained very clearly that I could not commit to doing anything for it at all
<daniels> svenl: which you seemed to be OK with
<svenl> mdz: you are aware that i was told pegasos support would come after the release shortly before the warthy release.
<mdz> daniels: morning
<mdz> svenl: you were not told that by me
<svenl> daniels: ok, no problem.
<svenl> mdz: nope.
<daniels> right now, as Matt said, I'm in the middle of looking for a house (and need one ASAP), so I really don't have much time in between 'X doesn't work at all' bugs and looking for houses
<svenl> mdz: but i did the job for the support.
<daniels> but yes, I think better Pegasos support is a worthwhile goal
<daniels> mdz: g'morning
<mdz> svenl: I appreciate that, and your patch will not be dropped on the floor
<svenl> daniels: could you at least look at the patches and give your advice ?
<daniels> mdz: spent most of the morning/afternoon shopping; practically bought a kitchen
<daniels> svenl: yeah, I'm just reading my email now
<svenl> daniels: cool.
<svenl> daniels, mdz: sorry, i maybe over reacted, but dismissing patches as non-trivial potentially release-breaking if this is not the case, well it is really discouraging to participate at all.
<svenl> mdz: especially if you don't even look at the patches.
<daniels> i understand it can be discouraging -- it's just right now that all our X autodetection stuff is on a hairline trigger
<mdz> it is a big adjustment from Debian
<daniels> breathing on it can make it collapse
<mdz> but there is a logic to it
<svenl> daniels, mdz and we lose more time arguing than it would take to review those patches.
<daniels> and I have lots and lots of bugs assigned to me where autodetection completely fails to produce the right result
<daniels> svenl: i'll review them once offlineimap finishes
<mdz> svenl: yes, but this argument will hopefully have long-term benefit
<svenl> daniels: ok, that is all i ask.
<svenl> mdz: you mean, in passing the message that it is not worthwhile to contribute to ubuntu because the patches don't even get reviewed ? 
<mdz> svenl: no, by helping you to understand our development methodology
<svenl> mdz: don't get me wrong, i understand your position.
<mdz> but you're starting to get hostile about it, so I think we should continue this conversation another time
<svenl> mdz: there you pass the message that i am ignorant of it, which is not the case.
<svenl> mdz: well, i don't feel hostile, and really don't intent to do so.
<daniels> svenl: hm, I'm not sure that this patch works properly for all cases
<svenl> mdz: the patches are valid, i did all the job for it, it will take daniels maybe 5 minutes to integrate them, and it adds support for a new architecture.
<svenl> daniels: which of them ? 
<daniels> svenl: depends how the CRTCs are wired up
<daniels> svenl: xresprobe
<svenl> daniels: ah.
<daniels> svenl: i don't know how radeonfb works, but if edid%d is edid data for the head on crtc %d, then it might not generally work
<svenl> daniels: well sure, but it is no worse than the current case.
<daniels> true
<svenl> daniels: so it is a best case, and better handling will wait post-hoary.
<daniels> the pcigart thing *looks* alright, but I want to run it past Michel Dnzer
<svenl> radeon does default to clone mode, so both edid1 and edid2 should be read, and the intersection of the modes chosen, but this may (or not) be more disruptive.
<svenl> daniels: i think he authored it, and it has been in debian since ages, and probably in 4.3.0 upstream too.
<daniels> er, if it was in 4.3.0 upstream, then it would be in xorg upstream
<svenl> daniels: but ask him, no problem, you are better suited for it.
<daniels> given that 4.3.99.2 was merged back into the 6.6 tree to make 6.7
<svenl> daniels: i don't know where it comes from, but it doesn't seem to be in a debian patch, not sure.
<daniels> but yeah, I'll ask Michel about it and see if it's still good, and check out radeonfb to see if edid%d is useful
<svenl> daniels: edid%d will look for both edid1 and edid2 ? I would rather not do that.
<daniels> svenl: i'm just saying in the general case -- if you have something connected to crtc 2 and nothing to crtc 1, then it will fail
<svenl> daniels: it will take the bigger of the two modes, i tested it.
<daniels> what I'm most worried about is if we have an external display connected, and try DDC, and end up getting sync ranges and data from an externally connected monitor
<daniels> svenl: no, what I'm saying is that edid1 may be empty and edid2 may have the real modes
<svenl> daniels: not sure, i am not 100% sure that radeonfb doesn't report edid1 independent of where the monitor is connected. let me test it.
<daniels> but if you have a laptop with an external display connected, and you end up writing sync ranges for a huge 21" LCD or something
<svenl> daniels: this makes for a more intrusive patch though.
<daniels> yeah
<svenl> daniels: notice that in this case, the current xresprobe is also broken.
<svenl> since we have no info on the head used, and if there are two monitors and thus two EDID's, all the modes will be used.
<svenl> let me check with my ibook and an external monitor.
<daniels> right
<svenl> mmm, can't find the external monitor thingy.
<svenl> daniels: anyway, i think the current patch is the less intrusive one, and even if it doesn't work in all cases, it will work in the current case, and don't break existing cases.
<svenl> daniels: i think anything more complexe should wait post-hoary.
<abelli> daniels: ping
<daniels> abelli: sup
<abelli> daniels: it's all right thank you :)
<daniels> err ... ok
<abelli> daniels: what's the main difference between nvidia-glx, and the linux-r-m ?
<daniels> um
<daniels> l-r-m provides the kernel module, nvidia-glx provides the xorg driver
<abelli> so nvidia-glx has no modules in it?
<abelli> ok, is it safe now, to upgrade from warty to hoary (i mean under xorg's perspective)?
<daniels> seems to work fine
<abelli> ok thank you
<schweeb> just a sec abelli, you may not want to upgrade just this sec if you want nvidia... for me at least, the nvidia kernel module is broke... zul mentioned something about compiling a kernel before he went to sleep, but it could be a few hours till a functional nvidia module
<crimsun> abelli: you'll want to use 'nv' instead of 'nvidia' for the time being
<crimsun> (as schweeb mentioned)
<schweeb> ^^^
<abelli> crimsun: i actually use nv..
<abelli> crimsun: that was for a friend.
<crimsun> abelli: ok :-)
<abelli> because, i don't know why, a dist-upgrade from hoary to warty produced bxl (to be read Big Xorg Lock)
<abelli> xfree didnt get uninstalled, and xorg didnt get installed :)
<abelli> but 08:39 < daniels> seems to work fine
<abelli> ;)
<HiddenWolf> abellli: you can't 'upgrade' from hoary to warty, warty is the older version
<abelli> in god we trust.
<abelli> mmmright... switch them :)
<daniels> looks abelli forgot about ubuntu-desktop
<HiddenWolf> daniels: bad for him
<mdz> doko: morning
<mdz> fabbione: morning
<fabbione> hi mdz
<doko> morning all
<fabbione> hi doko
<daniels> fabbione: oh, dude
<daniels> fabbione: it's nothing to do with different agp modules, is it?
<daniels> fabbione: like, if you use agpgart, it fails
<fabbione> nope
<daniels> has that sort of thing seen any update?
<daniels> or drm
<fabbione> i didn't upgrade agpart
<daniels> drm?
<fabbione> the changelog is 99% on the build system
<daniels> hmmm
<fabbione> only update is idiotify patch
<fabbione> and it's an API change. no ABI according to them
<mdz> idiotify :-)
<daniels> heh
<fabbione> i am really tired of this breakages
<daniels> yeah, it sucks :\
<daniels> don't envy your position
<fabbione> i swear god if i ever gonna get back X, i will never complain again!
<fabbione> X = EASY
<fabbione> daniels: perhaps we can switch for a while after hoary ;)
<fabbione> just to gimme a little break :P
<fabbione> mdz: btw.. this is all your fault ;)
<fabbione> <mdz> fabbione: mind to do the 2.6.8.1 -> 2.6.9 transition?
<fabbione> <fabbione> mdz: i imagine nobody is crazy enough to do that.. so yeah
<fabbione> look now!
* fabbione is totally into it!
* fabbione goes to the mental hospital for a few hours
<crimsun> poor fabbione. At least he's married. :-)
<daniels> fabbione: you gave me x, suckah, i'm going to damn well keep it
<fabbione> no that's on top that... my wife will hunt you down.. all of you!
<fabbione> daniels: good boy ;)
<fabbione> daniels: but that's because you are my little kitty :P
<daniels> haha
<daniels> so much so that I took HorizSync and VertRefresh out as the first thing I did :P
<daniels> i'm thinking of putting them back in by default now, though
* fabbione remembers SUGGESTING daniels NOT to do so....
<fabbione> let's look at the bright side of all this mess
<fabbione> sparc is catching up on main :)
<daniels> heh, cool
<daniels> fabbione: ah yeah, but not always, you see
<daniels> fabbione: don't write them out if we get sync ranges back from ddcprobe, or we're on a laptop chipset that we know isn't shit
<daniels> fabbione: so it will still be out of the file in about 95% of cases
<fabbione> yeah i saw your code dude
<fabbione> i keep an eye on my pets :P
<daniels> i remember that we had a bet of sorts about this in kbenhavn
<daniels> i guess this means you win, then :)
<daniels> to some degree
<fabbione> i can't lose :)
<daniels> haha
<fabbione> hmmm eel2 is doomed
<fabbione> where is seb?
<fabbione>  bin/sed: can't read /usr/lib/libhowl.la: No such file or directory
<fabbione> we must rebuild the archive asap to see if everything is ok
<fabbione> i am off.. later fellas
<crimsun> cya
<daniels> seeya dude
<kagou> hi
<svenl> daniels: BTW, after thinking about it, for a laptop with an external monitor, in clone mode, the code i submitted will use the first head only, which will be the panel.
<daniels> svenl: you're assuming the panel exports edid, which it generally doesn't
<daniels> also, the panel isn't always hooked up to the first crtc
<svenl> daniels: ah ...
<daniels> the laptop i'm sitting on now has the panel off the secondary display path
<svenl> daniels: i don't know, my ibook does have a EDID and edid1 in both places.
<svenl> daniels: my code is enabled for powerpc only, and of.c is linked in on powerpc only though.
<daniels> svenl: yes, but iirc powerbook panels don't export edid
<svenl> daniels: ah.
<daniels> svenl: (i think the difference was that the ones with nvidia chips export edid, radeons don't)
<daniels> the radeon lvds code is very clean
<daniels> nvidia's is ... not
<svenl> daniels: you have a powerbook ? which graphic card ?
<daniels> svenl: i don't have one, no, but there have been a lot of bug reports since ... last june, i think it was
<svenl> daniels: mmm, ...
<svenl> daniels: in any case, it would be possible for those powerbooks to be fixed by the radeonfb/sys thingy, but we need to find out what they do have ? edid1 or edid2.
<svenl> maybe they simply don't have anything though, will need to ask benh about this case.
<daniels> errr ... no
<daniels> see, the way panels generally work is that you have a table in the bios with the panel's mode information
<daniels> the lvds tables
<svenl> daniels: in any case, the current patch should have no influence on those.
<daniels> the panels will not respond to ddc queries
<daniels> this is the entire reason why we only run ddcprobe sometimes, and we run Xorg and grep the log other times
<svenl> daniels: but radeonfb is better placed than the EDID code to do its own mode setup and such.
<daniels> because we can't get DDC all the time, so we have to let Xorg read the tables out of the BIOS
<svenl> daniels: maybe we could get the info out of dmesg even, not sure.
<daniels> err, yeah, I'm not disputing that
<daniels> all we really need is the panel size, in which case we fork Xorg and grep the log
<daniels> see xprobe.sh and lcdsize.sh
<svenl> daniels: anyway, the patch i submitted should have no influence on that, and for hoary+1 chances are good that fbdev/fbmon will provide infrastructure for querying this kind of info.
<dholbach> good morning
<svenl> daniels: i will ask benh (who did the powerpc radeonfb stuff lately), if he knows of a way to get said info from radeonfb in 2.6.10.
<daniels> svenl: yeah, but that's irrelevant for i386/amd64 anyway
<daniels> configuring framebuffers by default is a nightmare I'd rather avoid
<daniels> svenl: right, but I think you'll find that the LVDS info is not exported via EDID
<svenl> daniels: euh. yeah, ok, guess i don't really care about non-powerpc and all my patches should not apply on non-x86, since they are #ifdef __powerpc_ed.
<svenl> daniels: yes, altough radeonfb could fake an edid1 with the lvds table or something, or provide the data in some other way.
<svenl> daniels: i think benh mentioned something such.
<daniels> svenl: ideally there'd be a driver-independent interface that xorg, fbdev and dri use that we can hook into
<daniels> svenl: but that's like hoary+9
<svenl> daniels: not sure.
<daniels> svenl: (well, that's the plan upstream, but it's going to take ages)
<daniels> we like it, the kernel guys like it
<svenl> daniels: it would be easy enough to simply use the fbdev facility, we place usefbdev option anyway.
<daniels> on powerpc, yes
<svenl> daniels: i like it too.
<svenl> daniels: ah ..
<svenl> daniels: anyway, are we agreed that the current patch is ok for now, doesn't break existing supported cases, and we can have this discussion with more time post-hoary ? 
<daniels> svenl: it *looks* ok to me -- i will check further, but on initial inspection it doesn't look too badly
<svenl> daniels: if the panel doesn't export EDID, then radeonfb doesn't export edid1 too, i think.
<daniels> ok, but we fork Xorg for laptops anyway and grep the log
<svenl> daniels: the real worry is if the powerpc laptop doesn't provide edid, that a monitor is connected externally, and that radeonfb provides an edid1 for the external monitor.
<daniels> so that doesn't matter
<svenl> ah, ok.
<daniels> right.  that's why we fork Xorg first
<svenl> ok.
<svenl> so no need for me to investigate this ? 
<jdub> YokoZar: replied to your mail on u-d
<daniels> no, just needs me to integrate it, thankyou
<jdub> YokoZar: hope that helps :)
<daniels> jdub: so, like, dbus 0.23.4 for hoary?
<svenl> BTW, can you apply the pcigart fallback to some tree you have, and build the radeon module, and make it available in the bug report for testing ? 
<YokoZar> jdub: thansk
<YokoZar> Thanks, even.
<jdub> daniels: was that ABI/API change dealt with upstream?
<daniels> jdub: not really, no
<jdub> daniels: can we get that upstream, and do we have a good list of the fixage between releases?
<daniels> jdub: but if it comes down to beagle vs !beagle for hoary, i can patch the affected apps (which are few)
<daniels> jdub: i've kicked upstream in the testicles for that one
<daniels> 0.23.x fixage is just fixing a hojillion memory leaks (one that made your app use a few hundred mb in half an hour) and a couple of lockups, mainly in interactions with mono
<daniels> but yeah, upstream are unrepentant and won't commit to a stable api :\
<daniels> brb
<jdub> :-)
<jdub> daniels: you seen that hal-d-m doesn't run?
<svenl> ok, need to go, see you later.
<daniels> jdub: it can be patched away
<daniels> jdub: my argument was that if you're going to change dbus_pending_call_get_reply to dbus_pending_get_steal_reply and change the semantics, just keep the old function around and mark it deprecated
<daniels> then remove it all in one great hit
<daniels> and i mentioned soversions
<daniels> this had the unfortunate effect of possibly placing us in a gal-esque situation
<YokoZar> jdub: reply sent
<jdub> daniels: yeah
<fabbione> hey jdub 
<fabbione> jdub: isn't about time you add some README or documentation to flumotion?
<fabbione> btw.. it hangs on me
<dholbach> elmo: could you please, when you're back sync  mondo  and  mindi  from sid?
<fabbione> daniels: did you ever installed your sparc?
<daniels> fabbione: not yet, I'm afraid
<fabbione> daniels: i still have problems using xvfb-run on sparc
<fabbione> it doesn't work as normal user in certain cases
<fabbione> nothing extremely important for hoary
<daniels> hmmmm, bloody hell
<fabbione> it's one package in main that needs manual love
<daniels> doesn't that fail pyopengl's build?
<fabbione> yes
<fabbione> this is frigging annoying.. my new webcam adds a new audio device
<fabbione> and it renumbered all the other cards
<fabbione> and xine refuses to see the correct one
<fabbione> oh btw
<fabbione> that xinemara problem seems isolated to mplayer
<fabbione> all the other players look ok
<fabbione> i will try later to see if it is only a missing build-dep somewhere
<daniels> weird
<daniels> yeah, it's probably a b-d thing
<daniels> anyway, I need to get some more sleep in
<daniels> on the couch, since my bed makes my back ache, heh
<Seveas> daniels, try a waterbed 
<daniels> Seveas: i'm getting a new bed soon
<Kamion> svenl: OF upgrade seemed to work (although unfortunately I wasn't looking at the screen when the flash program finished, so I'm not 100% certain; looked back and it was back at the OF prompt with variables reset), so I'm re-burning a CD image with modified yaboot
<fabbione> hey Kamion 
<fabbione> Kamion: did you manage to build a new DVD image?
<fabbione> (after preview i mean)
<fabbione> i got my DVD burner back yesterday and i can test during the weekend
<Kamion> fabbione: one should build today
<fabbione> rocking
<Kamion> didn't seem any particular hurry to preempt it :)
<Kamion> you do want today's build, since it has hopefully-fixed archive-copier
<fabbione> yes.. i recall that :)
<Kamion> fabbione: expect it to be available around 13:15 UTC or a little afterwards
<fabbione> Kamion: no rush. i need to unfuck the kernel first anyway
<jdub> fabbione: new packages on their way to universe soon are nicely split out and stuff
<fabbione> jdub: good.. but please add documentation too
<jdub> fabbione: thus far, the flumotion docs have not had a tarball release; i might have to package them anyway
<fabbione> usr/share/doc empty is the SUCKS
<mdz> Kamion: LANG=foo should be sufficient for #7138, right?
<fabbione> jdub: the README file as a starter is perfect
<mdz> no need to mess with any other locale settings?
<fabbione> jdub: the main issue for me is that it hangs when reading from my webcam
<fabbione> xawtv can read from it without any problem
<fabbione> flumotion can't
<jdub> hmm
<fabbione> brb
<Kamion> mdz: yes. what I was thinking was that it'd be best if casper got debian-installer/locale just before pivoting, and export LANG="whatever it got" immediately after pivoting; then you'd only have to do it in one place
<mdz> that's what I've just done
<Kamion> ideal then
<mdz> Kamion: any other environment variables which deserve the same treatment, while I'm there?
<fabbione> re
<daniels> mdz: for 7138, all I need is LANG
<Kamion> LANG's the only one I can think of
<Kamion> note to self: when burning CDs, it helps if you put the CD into the correct drive
<Kamion> what happened to the live CDs? they're taking ages to rsync today
<fabbione> lol
<fabbione> Kamion: winfoss?
<Kamion> not for powerpc
<HiddenWolf> ugh, I just realised hoary shuts down so fast that it clips off the shutdown sound before it's done playing. :S
<sabdfl> morning guys
<Kamion> jdub: "brill"? what decade do you live in? :-)
<fabbione> hey sabdfl 
<dholbach> hi mark
<sabdfl> installer tests... lots of problems today?
<jdub> Kamion: ha ha
<Kamion> sabdfl: hmm?
<daniels> Kamion: as opposed to 'rad'
<Kamion> I said "brill" when I was five
<daniels> Kamion: jdub is still five
<Kamion> good point
<sabdfl> we're trying to install hoary on a laptop for my new PA.
<sabdfl> last night, jane was getting a debootstrap error, "can't find ..."
<jdub> i have moments of youthful exhuberance :-)
<sabdfl> today i just burned a new install daily
<sabdfl> and it's not seeing my network cards
<sabdfl> on an IBM T42
<sabdfl> !
<sabdfl> ?
<sabdfl> jdub: gnarly
<Kamion> sabdfl: that debootstrap error is typically a symptom of a bad burn
<sabdfl> ok
<mdz> as Kamion said
<sabdfl> and... this mornings network error?
<Kamion> sabdfl: the kernel module ABI got screwed yesterday
<fabbione> sabdfl: working on it already
<mdz> not seeing your network card is probably the kernel ABI skew
<sabdfl> oh, that's alreight then :-)
<Kamion> the kernel/initrd and the udebs are almost certainly out of step
<fabbione> mdz: i think the simples way is to make 27 = 25.2
<fabbione> mdz: and 28 with the new ABI
<Kamion> fabbione: please include the #1440 fix in 27
<mdz> fabbione: fine with me
<Kamion> having it alternately progress and regress is confusing bug reporters
<fabbione> Kamion: yes. that was the idea
<Kamion> 25.2 did not have the #1440 fix
<Kamion> but if you mean to roll back the inotify patch in 27, sure :)
<sabdfl> fabbione: i need to get this laptop sorted for jane & claire today, will there be a new installer today to test with?
<Kamion> sabdfl: just use yesterday's image
<sabdfl> Kamion: 'k
<fabbione> sabdfl: it will take not less than 3 hours for the changes to propagate
<fabbione> sabdfl: nothing i can do faster
<Kamion> the kernel build will take a while, then it would take an installer byhand from elmo, and then new CDs will have to be rolled; all this while I'm in London ;)
<jdub> Get:64 http://archive.ubuntu.com hoary/universe libxslt1-python2.4 1.1.12-3ubuntu3 [686B] 
<Kamion> (leaving in ~1hr)
<fabbione> sabdfl:     - CONFIG_CRC32=y on all arches.
<fabbione> ops
<fabbione> s/sadbfl//
<jdub> oh, libxslt1, not libxslt1.1
<mdz> fabbione: why?
<fabbione> i wonder if this could have caused the ABI change
<sabdfl> fabbione: np
<fabbione> mdz: config allignment
<fabbione> mdz: it was giving some problems at udeb levels since it is a shared module between fb and net
<Kamion> the hack-solution Debian applied for that was to put crc32.ko in the kernel-image udeb
<mdz> fabbione: for hoary+1 I would like to explore building fewer kernels on i386
<sabdfl> Kamion: btw we are updating the ubuntu logo slightly (text blue -> black), i'll file a reminder bug for you to get a new isosplash from jdub / cliff
<Kamion> since both fb-modules and nic-*-modules depend on kernel-image
<Kamion> sabdfl: ok, no problem
<Kamion> but certainly building it in seems a sensible option
<fabbione> mdz: fewer? they are only 5...
<mdz> fabbione: "only"
<fabbione> amd64 builds 4, sparc 2, hppa 4, powerpc unlimited....
<mdz> hppa and sparc are irrelevant, powerpc are actually different subarches
<fabbione> so it's in the average
<fabbione> mdz: yes.. but they still get builded
<fabbione> ia64 4
<fabbione> so i mean.. it's there with the others
<mdz> fabbione: hppa and sparc don't delay releases
<fabbione> neither does ia64
<mdz> powerpc and i386 do
<Kamion> svenl: hm, the /etc/yaboot.conf -> ../install/yaboot.conf symlink doesn't seem to work
<fabbione> ok.. than i would say we roll back to 25.1
<fabbione> and we apply the debian fix to the crc32 thingy
<daniels> the other workaround would be to buy concordia, only with 12GB of RAM, run it in 32-bit mode, and build on a ramdisk
<Kamion> svenl: "Config file error: Token is too long near line 0 in file /etc/yaboot.conf"
<fabbione> that should do
<daniels> or tmpfs or whatever's fashionable these days
<Kamion> fabbione: why not just change ABI now?
<Kamion> if we're going to do it anyway ...
<mdz> daniels: the kernel builds use CONCURRENCY_LEVEL now; that should cut the build time in half
<Kamion> mdz: according to elmo, it makes it worse
<daniels> fabbione: i'll deal with lrm for the new abi if you give me a reminder when you upload it
<mdz> Kamion: because it'd be nice to un-screw the users we just screwed by breaking it
<mdz> Kamion: ??
<Kamion> true
<mdz> worse?
<fabbione> no
<mdz> I've used CONCURRENCY_LEVEL many times in the past with positive results
<fabbione> it's not worste
<fabbione> please do not confuse stuff
<fabbione> the last kernel invalidated the ccache
<Kamion> 13:21 < elmo> fabbione: I don't think that was such a good plan
<Kamion> 13:22 < elmo> Build needed 01:05:48, 1425648k disk space
<Kamion> 13:22 < elmo> Build needed 00:38:47, 1428100k disk space
<Kamion> 13:22 < elmo> first is -26, second is -25.2 .  on amd64, same buildd host
<fabbione> that's why it took longer
<Kamion> oh, ok
<Mithrandir> lamont: (6438); not yet, I got distracted by a shiny new WRT54GS last night, so I didn't finish OOo/ia64
<fabbione> you should compare with a version that did invalidate the cache too
<mdz> why would it invalidate ccache?
<Kamion> new config?
<mdz> ccache doesn't seem to be implemented correctly yet anyway
<sabdfl> Kamion, jdub: https://bugzilla.ubuntu.com/show_bug.cgi?id=7514
<fabbione> mdz: because of the new inotify patch
<fabbione> they claim that the ABI was intact
<mdz> fabbione: why would that invalidate ccache?
<fabbione> but apparently it wasn't
<fabbione> because it changes one include file in fs/
<daniels> mdz: touch a core header, watch your cache die
<fabbione> that means basically rebuilding 3/4 of the kernel
<crimsun> fabbione: confirmed that reverting inotify 0.20 -> 0.18 (16 and 15-optional + enable-inotify) allows l-r-m to work.
<crimsun> fabbione: just spent the past hour building and testing.
<fabbione> crimsun: ah good
<fabbione> dilinger: you around?
<fabbione> afaik changing one module from M to Y should NOT break the ABI
<fabbione> and we saw it with the DRM stuff a while back
<fabbione> so if that's the problem we can just revert the idiotify patch
<crimsun> fabbione: I left CONFIG_CRC32=y
<daniels> the drm stuff wasn't changing from M->Y
<crimsun> so that change is orthogonal
<mdz> fabbione: bobmitch claims on ubuntu-devel that firmware for acx100 is missing?
<crimsun> it's purely the inotify 0.20 stuff
<daniels> it was that DRM got reorganised so that all the drivers used core functions, which were built into the kernel
<daniels> and fglrx and drm-core just hated each other
<mdz> fabbione: adding or removing any symbols changes the ABI, AIUI
<daniels> mdz: they're in lrm
<mdz> potpal:[~]  dpkg -L linux-restricted-modules-`uname -r` | grep acx
<mdz> zsh: done       dpkg -L linux-restricted-modules-`uname -r` |
<mdz> zsh: exit 1     grep acx
<mdz> daniels: ^^
<daniels> they're not called acx
<fabbione> mdz: that is weird.. we didn't touch the acx stuff for a long while
<mdke> :(
<daniels> daniels@catsby:~/canonical/kernel/l-r-m/2.6.10.3/linux-restricted-modules-2.6.10-2.6.10.3/acx100% ls
<fabbione> daniels: you have an acx.. can you check?
<daniels> RADIO0d.BIN  RADIO11.BIN  RADIO15.BIN  TIACX111.BIN  WLANGEN.BIN
<mdke> i have acx
<mdke> can i help?
<daniels> fabbione: it's not in my amd64 right now, but I don't see how it would be broken
<mdz> daniels: please follow up on ubuntu-devel;
<daniels> i can check on the other side of sleep though
<daniels> mdz: wlil do
<daniels> alright, off now, later
<Kamion> surely the module is just broken for the same reason every other module is broken at the moment
<mdz> daniels: he says it was a fresh array 6 install
<Kamion> i.e. the ABI change
<mdz> Kamion: the base-installer kernel issue was fixed before or after array 6?
<Kamion> I think after, checking
<mdz> daniels: if it was fixed after array 6, the answer is probably "use preview"
<Kamion> or "install linux-386"
<crimsun> really, it's solely inotify 0.20's fault.
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Mon,  7 Mar 2005 13:11:31 +0000
<Kamion> Array CD 6 was 3 March
<mdz> thanks
<fabbione> ok.. inotify is reverted.. anything else?
<fabbione> mdz: the acx stuff is known to work.. otherwise daniels won't be here irciing...
<Kamion> at some point I must send you a BusLogic hotpluggification patch, but not now
<fabbione> Kamion: just send it.. i will queue it up for -28
<Kamion> I don't have it yet, hence "not now" ;)
<fabbione> mdz: ?
<mdz> fabbione: ?
<fabbione> anything else for 27?
<mdz> fix all known boot failures? ;-)
<fabbione> mdke: does the acx100 driver work for you?
<mdke> yes
<mdz> all the other major kernel bugs too if you have time
<mdke> fabbione, i copied my firmware over from cd
* fabbione summons Linus and adds AI to the kernel
<mdke> fabbione, although it goes down fairly frequently
<mdke> but it works
<smurfix> Anybody know where mako has misplaced himself? We were supposed to have a meeting at 10:00 UTC
<mdz> smurfix: it's before 0600 in mako-land, so I imagine he's misplaced himself in bed
<fabbione> mdz: i would like to unbreak the ABI in 27 and work immediatly on 28
<mdz> fabbione: sounds good
<fabbione> mdz: i have a few tons of security updates to push in
<fabbione> that as usual MIGHT break the ABI
<fabbione> so 28 is a perfect kernel
<smurfix> mdz: he shouldn't have agreed to that time then :-/
<mdz> smurfix: perhaps he overslept
<smurfix> mdz: He's been offline for the last 10.5 hours, that should be enough sleep :-p
<mdz> smurfix: I slept for 11 hours last night
<mdke> mmmm
<fabbione> i think he also has a life :)
<sabdfl> mdz: welcome back to the world of the living :-)
<sabdfl> oww
<smurfix> fabbione: if he agrees to a meeting time he's not supposed to have one in the meantime ;-)
<mdz> bringing me to an average of about 5 hours/night for the past 3 ;-)
<sabdfl> kamion: if it's tricky, don't stress for hoary, but if possible please https://bugzilla.ubuntu.com/show_bug.cgi?id=7515
<sabdfl> mdz: don't push it, ok
<smurfix> mdz: Ouch.
<fabbione> sabdfl: on topic of installer questions...
<mdz> sabdfl: without major surgery, those questions must be asked after the base system is installed
<fabbione> choose-mirror and apt preseeding
<fabbione> (at least on netinstall)
<sabdfl> fabbione: so with the new bustificated kernel, will network also fail on a normal boot if i update to todays versions?
<sabdfl> fabbione: you want those asked, or not asked?
<fabbione> it would be very nice to let choose-mirror to ask the question and preseed apt..
<mdz> sabdfl: taking it easy is occasionally incompatible with meeting release targets, unfortunately
<fabbione> instead of lettign choose-mirror download from archive
<fabbione> and ask later
<sabdfl> mdz: you're preaching to the choir :-)
<mdz> I'm easy like sunday morning
<fabbione> sabdfl: it might fail. problem is that i can't reproduce the problem here.. not even with nvidia
<mdz> sabdfl: if your network device requires a driver from linux-restricted-modules, it's entirely likely that it will fail
<smurfix> Duh? I just updated and locales.postinst is rebuilding every locale *twice*
<mdz> smurfix: Kamion touched it last! ;-)
<Kamion> sabdfl: it's hard; the implementation of those questions fundamentally relies on having the base system installed
<mdz> jdub: thanks for the followup on the wine issue
<jdub> mdz: turned out well
<Kamion> sabdfl: mm, I agree that choose-mirror really should ask its mirror question; it's not on the default CD install path
<Kamion> ah, mdz already said what I said about the base system installation :)
<fabbione> also because it's lame to download from archive.u.c and than ask what mirror to use
<Kamion> nowadays we do at least default to CC.archive.ubuntu.com there, but still
<fabbione> i spend heaps of time downloading from archive each time i need to do a test install
<mdz> how many CC.ubuntu.com point to non-canonical mirrors?
<fabbione> i can imagine admins with local mirrors
<mdz> s/canonical/Canonical/
<sabdfl> mdz: i doubt a T42 needs restricted modules... does it?
<mdz> sabdfl: the T42 is available with 3 different wireless cards
<mdz> one of them is atheros-based, which requires l-r-m
<mdz> one is centrino/intel, which doesn't
<mdz> I forget what the other is
<fabbione> 27 is on the way to incoming
<sabdfl> installed an older image
<sabdfl> mdz: uses ipw2200 and e1000
<mdz> sabdfl: just like my T42, then
<mdz> sabdfl: in which case I guarantee that preview works out of the box ;-)
<sabdfl> fabbione: are we rolling with the latest ipw* drivers?
<fabbione> sabdfl: almost...
<mdz> sabdfl: not latest, no.  we stopped blindly pulling code from upstream some time ago
<mdz> we ship with the December 20th version of ipw2200
<sabdfl> ok
<Kamion> sabdfl: so, any other Ubuntu logo changes, or just the colour? if it's just the colour I can probably gimp it up myself
<mdz> we made a pass over all the third-party drivers before upstreamversionfreeze and updated them
<fabbione> the only exception was inotify in the attempt to get it working
<fabbione> but it has been giving more problems than anything else
<jdub> Kamion: it'll be a full image change
<fabbione> there.. kernel is ACCEPTED and before cron.daily
<jdub> Kamion: to match or complement the splash screen
* fabbione does some baz dance 
<mdz> fabbione: we need to invent the hoary dance for UDU
<Kamion> jdub: oh, that's not what I gathered from #7514
<fabbione> mdz: agreed...
<jdub> Kamion: the logo change will be part of it
<fabbione> mdz: YMCA? ;)
<jdub> Kamion: but it will be a more general change
<Kamion> 'k
<Kamion> I need this a week before release
<Kamion> preferably a bit earlier, so that the release candidate has a better chance of being final
<fabbione> Kamion, mdz: 28 will be up not before the 16
<fabbione> and it will change the ABI
<fabbione> are we ok for this?
<fabbione> or do you want me to delay?
<mdz> fabbione: it is guaranteed to change the ABI?
<fabbione> mdz: it did in 26... so yes
<mdz> RC is the 30th
<fabbione> mdz: i can't disclose before the 16
<mdz> fabbione: I do not understand why we should cause these headaches for the sake of inotify
<fabbione> you know the drill
<mdz> which is disabled per default
<fabbione> mdz: because the last one works way better than the previous one
<mdz> wouldn't it be better to suspend inotify updates until hoary+1
<mdz> ?
<fabbione> mdz: ok for me
<mdz> it may work better, but we have already decided not to use it for Hoary
* fabbione is extremely flexible today
<mdz> fabbione: perhaps even...bendy?
<fabbione> ahaha
<fabbione> bendy +++
<fabbione> i relly can't wait for UDU :)
<fabbione> our meetings are so much fun
<smurfix> Anybody going to linux.conf.au before UDU?
<dholbach> hi mvo
<fabbione> not me...
<mdz> smurfix: yes, several of us
<mvo> hey dholbach 
<mvo> hi all
* smurfix plans o
<smurfix> to, even
<thom> morning
<fabbione> sabdfl: at linux conf.au you need to get me a Linus signature with something on the line as: "To Fabbione.. that poor kernel maintainer" ;)
<thom> mdz: firefox?
<fabbione> hey thom
<mdz> thom: foxfire?
<mdz> fabbione: I thought Linus was not attending this time
<fabbione> no idea....
<fabbione> hounestly
<fabbione> smurfix: is keymapper your toy?
<thom> mdz: SU 47d
<thom> mdz: but let's not talk about russian fighter jets ;-)
<mdz> mozilla-foxbat
<dholbach> can somebody make me feel less uneasy about  http://wiki.ubuntu.com/UniverseUnmetDeps ? i know there are some things based on non-free or amd64 issues, but still...
<smurfix> fabbione: Yeah
<thom> mdz: i'm sure MiG have copyrights on the name ;-)
<Kamion> dholbach: compare it with http://ftp-master.debian.org/testing/unstable_probs.html and contemplate what an easy time you have by comparison
<fabbione> smurfix: keymapper builds fine but console-data will fail on sparc with this message: make: *** No rule to make target `decision-tree-sparc', needed by `decision-tree'.  Stop.
<fabbione> smurfix: can you point me to what i should look at?
<Kamion> (ok, so a lot of that is fucked architectures like sh, but still)
<smurfix> fabbione: Check out consoledata's debian/rules
<dholbach> Kamion: haha... thank you, i'll contemplate all day along
<mdz> Attempts to install the smp kernel subsequently failed. Likely cause: Bad deb package
<mdz> a keenly intuitive diagnosis
<thom> mdz: but yeah, you pinged last night about the 1.0.1 upload?
<fabbione> smurfix: ok
<smurfix> fabbione: There's a gen_keymap there which needs to be fed a list of keyboards likely to be connected to a Sparc box
<fabbione> smurfix: ok...
<dholbach> is everyone ok with a wiki page   MorgueCandidates  ?
<Kamion> svenl: so, turning on yaboot debug suggests that booting yaboot on the Pegasos with the OF update is then trying to of_open "/pci@80000000/ide@C,1/cdrom@1,0:\etc\yaboot.conf"
* fabbione -> food
<GheRivero> res
<mdz> thom: yes
<Kamion> svenl: but doing "boot /pci@80000000/ide@C,1/cdrom@1,0:\install\yaboot" at least starts up yaboot fine (although I get the same config file error)
<mdz> dholbach: what would be the content of this page?
<Kamion> svenl: so I think the path is correct
<dholbach> mdz: packages we don't want to support any more, which don't make no sense and should be blocked from auto-syncs from debian
<Kamion> svenl: yaboot apparently passes part=NULL to of_open here, so I'm not sure why the is_not_iso thing is needed?
<YokoZar> When I take a desktop screenshot, and save it to desktop (as default), it didn't show up until I opened the desktop folder in nautilus and hit refresh
<mdz> dholbach: candidates for removal, then?
<dholbach> mdz: the page would be a place to discuss those packages
<YokoZar> Is this something weird I did?  Or is it something weird gnome is doing?
<dholbach> mdz: i'm going throught the list, but vdk would be such a case (we have vdk2 and it isnt installable anymore), kudzu (in my eyes, because users complained about broken configuration after the use of it)
<thom> mdz: i'm gonna nail down a bunch more bugs before i upload; prolly the middle of the week or so now i have popcon more or less fixed up
<dholbach> mdz: that's all i have in mind atm
<dholbach> mdz: i think it's good to have a discussion place for those and an institution for that, since universe is... well packed with weird stuff :-)
<mdz> dholbach: sounds reasonable
<dholbach> mdz: https://www.ubuntulinux.org/wiki/MorgueCandidates
<dholbach> mdz: perhaps it could be an item on each of the TB's meetings (correct me, if this is the wrong place for it), so elmo could act after the decisions made then
<dholbach> generally users should have the choice, but _a bit_ of a best-of-breed--approach would be a nice thing to focus on
<HiddenWolf> Failed to run /usr/sbin/synaptic as user root:
<HiddenWolf>  Child terminated with 249 status -> :S
<fabbione> Build needed 00:22:01, 1425712k disk space
<fabbione> this is on amd64 with ccache :-)
<fabbione> (kernel build time btw)
<fabbione> almost 50% less than before
<Mithrandir> fabbione: nicey
<fabbione> told ya
<mvo> HiddenWolf: it looks like a message from gksudo that we really should patch out. 
<HiddenWolf> mvo: just filed a bug about it for synaptic, feel free to solve it ;)
<mvo> HiddenWolf: one more for my ever growing list ...
<mvo> HiddenWolf: thanks :)
<mdz> night all
* Amaranth heads for bed
<thom> night mdz
<mvo> night mdz 
<fabbione> night mdz
<dholbach> bye mdz
* thom goes out
<thom> Kamion: cya later
<HiddenWolf> mvo: Relax. ;)
<svenl> Kamion: yeah, i know, this is the same thing i discovered.
<svenl> Kamion: the problem is that the boot command does a "load" while yaboot does only a "read".
<svenl> Kamion: and currently the "read" command bypass the filesystem/partition table detection code, and does a plain read.
<svenl> Kamion: need to fix that, but time was short.
<Kamion> svenl: ok
<zul> morning
<Mithrandir> sabdfl: btw, I'm hoping to have a look at the ooo2 feasability this weekend.  There were some conflicting build-deps, but seb sorted that out.
<fabbione> yay
<fabbione> 46 minutes for i386 to build
<fabbione> that is good considering it munges arch: all
<fabbione> still much better than 1 hour and 30 on my -j15 distcc cluster with only arch: any
<Mithrandir> elmo: could you please un-pas tvtime?  I have no idea why it's marked as "i386 (wine) specific"
<Mithrandir> elmo: it does at least build on amd64
<trukulo> hi ppl
<Riddell> how do I change the widget style used by gnome?
<trukulo> Riddell, you are asking how to change the widget on ubuntu-devel? ask it on #ubuntu please
<Riddell> this is for development purposes
<trukulo> ah
<trukulo> so : System - Preferences - Theme
<trukulo> or you asking files ?
<smurfix> fabbione: Has anything changed WRT ipw2200 and/or power handling? I can power the thing down but I can't get it back up :-/
<fabbione> nope.. please test again with -27
<fabbione> -26 is borked 
<jdub> Riddell: changing a gconf key; for you guys, i'd recommend dropping in a defaults file
<jdub> Riddell: will explain later, have to put pipka to bed
<smurfix> fabbione: Just booted -19, doesn't work there either :-/
<smurfix> fabbione: I'll attack -27 with a debugging mallet if it doesn't behave ...
<fabbione> smurfix: mjg59 is the person to ask.
<fabbione> i really can't do anything about it
<fabbione> i don't have the hw nor the knowledge to fix it
<smurfix> fabbione: I'll bug him if it doesn't work
<smurfix> fabbione: thanks
<ogra> morning
<trukulo> morning ogra
<trukulo> oliver, have you seen news? nero on linux (propietary)
<Kinnison> jeffy.
<zul> hey jbailey 
<jbailey> Danny!  Chuck!
<fabbione> hey jeff
<jbailey> Fabio!
<sabdfl> Mithrandir: thanks muchly!
* Kinnison has reason to use the new hoary update tool
<Kinnison> It's very very cool
* mvo is happy
* Kinnison loves the changelog doobry
<AndyFitz> trash icon concepts,   left or right style .  which one is preferred ?   http://andy.fitzsimon.com.au/trash.png  
<zul> left
<ogra> hehe, right
<AndyFitz> ogra, zul,  any particular reasons ?
<zul> it looks better for me
<ogra> AndyFitz: i just see the left variant in my panel......the outline looks to slim for me for such a small icon (as well as on the evolution,help and ff)
<AndyFitz> good point ...  hrm.  I personally like the style of the left one better  but the right one does have the practicality going for it ..
<jbailey> AndyFitz: I think I prefer the right because it has some colour to it.
<AndyFitz> now that I think about it .. the right one looks like those pipes in maro.. at any moment a giant flower with teeth could come out of your empty wastebasket
<jbailey> In the tiny iteration of the full one, I find it hard to tell the different between full and empty.
<jbailey> (of the left one)
<AndyFitz> they havent been cleaned up yet.   and I don't think they will be able to be ( by hoary's release )
<AndyFitz> will finish the other stuff and come back to it later  maybe  on the mailing list
<torkel> the right ones, they looks somewhat of what we have in sweden :-)
<kent> I would prefer the right one, since the left trashcan does not look half as good as the right one.
<dholbach> fabbione: ping
<jdub> Kamion: around?
<Alessio> sorry, do you have any news about mako? we should have a meeting this morning..
<jdub> hmm, haven't seen mako around myself
<Alessio> do you have know any way for contact him quckly?
<Alessio> *qickly
<Alessio> uhm..
<dholbach> anyone of the TB crew in here? what's the status of kernel-*-2.4* in universe? and the reasoning behind it? :-)
<ogra> smurfix was also waiting for him since 10:00 UTC 
<Alessio> ogra, me too
<Alessio> he have agreed for that time
<Alessio> *has
<Alessio> ok, thanks
<ogra> jdub, is there a chance to use the nice keyboard bell from ppaudio in esd ? 
<jdub> ogra: nup
<ogra> hmm, :-/
<ogra> was one of my favorite features....
<torkel> ogra: you must be kidding? That was the first thing I turned off
<ogra> i loved it
<srbaker> whoa.  straw is *really* buggy.
<srbaker> what's the "official" gnome-sanctioned RSS aggregator these days?
<Nafallo> srbaker: liferea are used by many, myself I use thunderbird :-).
<srbaker> Nafallo, yeah, i was using thunderbird.  just looking at lifrerea now
<Nafallo> I tried liferea until I saw that Thunderbird would be happy to do the trick for me :-).
<jdub> srbaker: blam! is pretty good
<srbaker> jdub, i foudn it a little unstable
<Mithrandir> the problem with using t-b is it's a bit slow, IME.
<Simira> Kamion: ping
<srbaker> Mithrandir, right, that's why i'm switching back to balsa.  and finding something new for reading rss
<Mithrandir> I'm using liferea which works well except for one bug, which is it resets the position in the story window when refreshing the feeds.
<srbaker> huh
<Mithrandir> which can be annoying, but isn't a big thing
<jon1012> hi everybody :)
<fabbione> daniels: mplayer was at fault...
<fabbione> daniels: uploaded the new version right now
<_d4vid> Ubuntu 5.04-preview is released (GNOME 2.10 included)! Downloads are available at http://releases.ubuntu.com/hoary/. Test it NOW!
<Nafallo> _d4vid: this channel didn't already knew that I suppose? ;-)
<Burgundavia> no, the entire dev team has their head in the sand
<GheRivero> res
<jdub> hey ghe
<jdub> got your mail
<jdub> want to reply in detail, but relaxing a bit on the w/e, will reply on monday :-)
<_d4vid> play Silbermond - Symphonie.mp3
<GheRivero> jdub, should i wait good news?
<jdub> GheRivero: i'm really keen for it, is the short summary ;)
<jdub> GheRivero: you coming to UbuntuDownUnder?
<GheRivero> no, i'm really far
<jdub> i went to mataro ;)
<GheRivero> me too, but australia is just in the other side, and my work is not really well paid
<jdub> have you thought about requesting sponsorship?
<jdub> or not enough time to come, either?
<GheRivero> i tough about sponsorship, but i'm afraid i didn't feel comfortable using canonical money. I'm sure there is alot of more people that didn't go to mataro that would like to go to sidney
<zul> the next conference should be in north america imho
<Treenaks> zul: canada then
<zul> even better
<jdub> zul: fairly likely it will be south america.
<zul> doh!
<fabbione> i think the next will be in south africa
<fabbione> south america ++++++!
* ogra votes for mexico
<zul> no no...north america...canada...ottawa *cough* *cough*
* fabbione hunts down zul
<jdub> ogra: that's not south america ;)
<fabbione> CUBA!
<Treenaks> jdub: almost :)
<ogra> jdub: but near ;)
<fabbione> let's go to CUBA!
<doko> fabbione: one time galapagos is enough ... 
<jdub> argentina, brazil, venezuela, ...
<fabbione> cuba has bw
<fabbione> and more...
<Treenaks> jdub: Chile?
<fabbione> expecially a lot of more
<jdub> Treenaks: possibly
<fabbione> GO SPARC GO!
<fabbione> it's catching up
<fabbione> jdub: flumotion? how do i debug that problem with the grabbing?
* fabbione is hyperactive today
<zul> more so than usual/
<jdub> fabbione: try to run a raw gstreamer line with gst-launch-0.8
<fabbione> jdub: is that supposed to handle the grabbing?
<jdub> that will allow you to debug more closely to the problem area
<fabbione> gst-launch-0.8 
<fabbione> ERROR: pipeline could not be constructed: empty pipeline not allowed.
<jdub> you need to enter a pipeline ;)
<jdub> it'll be like this:
<jdub> gst-launch-0.8 v4lsrc ! videorate ! ffmpegcolorspace ! xvimagesink
<jdub> something like that
<jdub> if there's an error, let me know
<fabbione> severals
<fabbione> jdub: see /msg
<fabbione> that's what i get
<jdub> wow
<jdub> that's the kind of error i'd direct you to #gstreamer about ;)
<fabbione> jdub: that's the kind of error the flumotion maintainer should fix for me :P
<smurfix> FWIW, that gst command line works perfectly on my system
<fabbione> smurfix: here the problem seems to be related to IOCTL
<fabbione> xawtv gets along with them
<fabbione> and it works
<fabbione> flumotion or ffmpeg don't
<fabbione> stracing ffmpeg shows that it does some unknown (to the webcam) ioctl
<jdub> fabbione: this is a gstreamer issue
<fabbione> jdub: ok.. you know the guys in #gstreamer, don't you?
<fabbione> i can help debugging and testing...
<fabbione> let me join
<jdub> fabbione: what kind of webcam do you have?
<fabbione> jdub: it's a quickcam from logitech
<fabbione> Bus 002 Device 003: ID 046d:08f5 Logitech, Inc. 
<fabbione> that is supported only by one unofficial driver forked by something else
<fabbione> the driver is also called OOPSorama
<fabbione> but it works generally
<fabbione> at least it doens't die
<jdub> heh
<jdub> i have a quickcam 4000
<fabbione> AH hold on
<fabbione> error was bogus
<fabbione> i forgot the trick to make it working
<fabbione> the one in /msg is the correct one
<jdub> try this
<jdub> v4lsrc num-buffers=2 ! ...
<jdub> the rest is the same as last time
<fabbione>  gst-launch-0.8 v4lsrc num-buffers=2 ! videorate ! ffmpegcolorspace ! xvimagesink 
<fabbione> same error
<jdub> bummer
<jdub> well, combination of weird driver and odd gstreamer output -> #gstreamer ;)
<fabbione> i think there is something else wrong
<fabbione> ERROR: from element /pipeline0/v4lsrc0: Could not read from resource.
<jdub> that's a relatively generic error
<fabbione> it looks like that it can't open the device at all
<fabbione> ok.. dude.. /j #gstreamer
<fabbione> and introduce me to the guys
<fabbione> as your God :)
<fabbione> since i have root on your machine :)
<fabbione> MUHA MUHA
<fabbione> ;)
<sivang> howdy all
<Simira> hi sivang
<sivang> hey Simira, what's up?
<ari> the new python-gtk2 crashes streamtuner on startup :(
<Simira> sivang: not much, really. translations and stuff, as usual :) You're going to Ubuntu Down Under?
<sivang> Simira: no idea :) are you?
<Simira> sivang: I hope so ;)
<Treenaks> I'm not :(
<zenwhen> Haha, i didnt upgrade for a day and got 113MB behind.
<zenwhen> Stupid dialup
<ogra> jdub: do yo know anything about gnome.sound_init() ?
<ogra> (python)
<fabbione> jdub: the value for the minimum buffers is hardencoded
<fabbione> = the sucks
* Mithrandir cooks up a new ooo-amd64
* ogra waits in patience :)
* fabbione boils a new mplayer that should build on amd64 and ppc
<dilinger> fabbione: hm?
<fabbione> dilinger: n/m..
<Nafallo> fabbione: care to generate -nogui for amd64?
<fabbione> hmmm
<fabbione> Nafallo: right now the package build but there is no mplayer binary
<fabbione> drwxr-xr-x root/root         0 2005-03-12 16:39:12 ./usr/bin/ is empty
<Nafallo> hmm, works on i386 I guess?
<fabbione> yes
<fabbione> it simply doesn't build anything
<fabbione> not even on ppc
* Nafallo apt-gets source mplayer-amd64 *
<fabbione> you need to get ubuntu5
<fabbione> i think it is fixable
<Nafallo> fabbione: URL? :-)
<fabbione> Nafallo: it's in the archive
<Nafallo> I better sync then. ubuntu3 showed up here.
<Goshawk> is there someone that have packaged a library here?
<HiddenWolf> ugh, evolution doesn't work well at all with postscript
<Treenaks> HiddenWolf: in what wat?
* ogra wants to know what this is : http://www.grawert.net/wiki_error.png
<Treenaks> way even
<HiddenWolf> Treenaks: printing an html email from evo puts it on two pages, thunderbird does it one one, looking as intended
<fabbione> jdub: i found the problem
<fabbione> jdub: basically gst v4l plugin waits for the camera to send frames
<fabbione> while xawtv does active polling on the camera
<fabbione> the camera doesn't send frames back
<fabbione> and gst hangs
<fabbione> while xawtv keeps going on with IOCTL
<fabbione> i think this should be solved both in the driver and gst
* Nafallo need a faster downstream *
<Treenaks> Nafallo: get one :)
<Nafallo> Treenaks: trying. all ISPs I've tried want's to give me 0,5 maximum :-P.
<Nafallo> they raised the rent, so I'm looking for a smaller apartment anyway.
<_d4vid> http://raus.de/crashme
<jani> mako ping
<HiddenWolf> treenaks: see what I mean: https://bugzilla.ubuntu.com/show_bug.cgi?id=7524
<Nafallo> hmm, maybe I can sync with a faster speed when not downloading livecd's via torrent ;-)
* HiddenWolf hugs his 10mbit up/down line
<dholbach> see you later
<fabbione> jdub: YES!
<fabbione> jdub: found it!
<fabbione> jdub: it's a bug in gstream, but there is a workaround in the driver for the cam
<Nafallo> later all!
<fabbione> jdub: but flumotion still doesn't love me
<jani> mako ping
<mako> jani: oi
<mako> jani: sorry i missed you yesterday
<ogra> mako, :( http://www.grawert.net/wiki_error.png
<ogra> any idea ?
<mako> ogra: um... not really, were you trying to log into the wiki from www.ubuntu.com ?
<mako> ogra: evidently, it only works from www.ubuntulinux.org
<ogra> http://www.ubuntulinux.org
<mako> ogra: but that looks slightly insane
<mako> no idea dude
<ogra> it is
<ogra> heh, ok
<koke> is there any reason to not enabling the zope external editor for the wiki??
<koke> I find it very helpful
<Treenaks> performance, maybe/
<Treenaks> ?
<mako> koke: oh yeah dude, it caused big problems
<mako> koke: i think, in many/most versions of mozilla, in generated screwed up xhtml
<mako> koke: it was buggy and broke our pages frequently
<mako> koke: unless i'm thinking of something else?
<mako> koke: you can use mozex though
<mako> and you can edit any textfield in an external editor
<mako> i couldn't live with out that
<koke> I've used it only a few times, in a personal test plone, so I didn't saw that :)
<mako> mozex.mozdev.org
<mako> recently, there were some firefox configuration bugs
<mako> that were barring normal configuration of mozex
<koke> there's no package?
<mako> it's a mozilla extension
<mako> you install it by clicking a link
<mako> it's just hardly worth packaging unless it's by defaul
<koke> :D
<mako> and also, it has a firefox bug
<mako> but you can set the configuration stuff through about:config
<mako> i couldn't live with out it dude
<mako> i would *die*
* mako is feeling overly dramatic this morning
<koke> I see :)
* HiddenWolf bets he's feeling more dramatic than mako
<koke> mako: which are the keys at about:config?
<jani> mako I'm back
<jani> I wanted to ask you about
<jani> the notary stuff
<mako> koke: mozex.command.textarea is the major one
<pitti> Hi folks
<ogra> hj pitti 
<koke> I don't have any mozex stuff at about:config but I've found an article using user.js
<fabbione> hey pitti
<fabbione> hi mako 
<fabbione> pitti: you have mail
<pitti> fabbione: just read it
<pitti> fabbione: but I'm a bit in a hurry, just a quick email reading
<mako> fabbione: hey dude
<pitti> fabbione: but hey, you digged out _tons_ of crack from Debian :-/
<mako> koke: you don't hmmmmm..
<pitti> i
<fabbione> pitti: i am more concerned about the disclosure
<fabbione> mako: what's up?
<fabbione> pitti: all that stuff is public, so i am not too worried and we have patches handy
<koke> mako: ggrreat it's working :D much better now, thanks
<mako> koke: pretty nice, yeah? :)
<koke> if only vim had syntax highlighting for MoinMoin :P
<Treenaks> koke: easy to write -> some regexps & Done
<Loevborg> Treenaks, that's not so easy with vim :)
<Treenaks> Loevborg: writing vim syntax files is not Hard.. just a lot of manual-reading
<Loevborg> Treenaks, I personally consider reading manuals hard (particularly vim regex syntax).
* Mithrandir looks at his new&shiny ooo-amd64
<Treenaks> Mithrandir: working OOo bling?
<Mithrandir> Treenaks: working ooo bling on ia64 as well, yes.
<Mithrandir> definitively bling
<Treenaks> Mithrandir: wow
<thierry> is there anyway I could change my keyboard configuration the way I like it (my current configuration doesn't work the way I'd like and there's no better one)
<koke> Treenaks: it's done http://www.vim.org/scripts/script.php?script_id=725
<fabbione> holy carp
<Treenaks> fabbione: carp? like.. the fish thingies?
<fabbione> mplayer build rule is total crap
<fabbione> but it can be fixed somehow :-)
<fabbione> ok i can fix it
<fabbione> but not tonight
* doko wonders if mithrandir's new and shiny amd64 OOo includes the SansSerif font fix ...
<mdz> morning
<Treenaks> hi mdz
<zul> hi mdz 
<pitti> Hi mdz 
<doko> morning mdz
<fabbione> hey mdz
<fabbione> mdz: any objections if i fix mplayer for ppc/amd64/sparc?
<mdz> fabbione: none whatsoever
<fabbione> mdz: ok
<fabbione> i still have to understand how did you manage to fly over that rules file
<mdz> what rules file?
<fabbione> the one in mplayer
<fabbione> you touched it last (before me)
<mdz> yes, to fix the FTBFS
<fabbione> yeah
<mdz> perhaps not in the ideal way
<fabbione> ehhe
<fabbione> no problem.. i will make it nicer
<mdz> I didn't even look at rules, I don't think
<fabbione> now i just want to see if it can build on amd64/ppc
<fabbione> mdz: better!
<mdz> it's upstream which is broken
<fabbione> you spared yourself some pain
<fabbione> well more than upstream is the maintainer
<mdz> it uses functions from libvorbisenc but does not link with it
<fabbione> i rememebr compiling tons of time mplayer manually
<fabbione> oh that one yeah
<fabbione> but i mean the build system is the sucks
<mdz> daniels: ping?
<ogra> dholbach, wb
<dholbach> hi ogra 
<dholbach> hi
<fabbione> mdz: i think it's like 6 am there
<GheRivero> res
<pitti> mjg59: here?
<ogra> mdz: ping : your strace of hwdb-gui
<fabbione> later fellas
<zul> toodles fabbione 
<ogra> ciao fabio
<mdz> ogra: pong
<mdz> fabbione: daniels was awake until 8am local recently
<ogra> mdz, are you sure esd was running at all when you tested ?
<ogra> mdz, access("/tmp/.esd/socket", R_OK|W_OK)   = -1 ENOENT (No such file or directory)
<ogra> doesnt look like
<mdz> ogra: no, I am not, in fact I am fairly certain it was not
<ogra> ah, ok
<mdz> apparently, esdplay works without esd
<ogra> yup, but i dount use esdplay :)
<mdz> right, but I used esdplay to test that esd was working :-)
<ogra> so i'll do some more tests on esd....
<ogra> thanks
<mdke> is anyone reporting a major bug in gnome? perhaps it is just my system
<jani> is gcc3.2 still needed in universe?
<Treenaks> mdke: what's the bug?
<mdke> Treenaks, evolution takes 5 minutes to start, gnome-terminal crashes totally
<Treenaks> mdke: look in top -> are there a few processes running at 100% CPU time?
<mdke> looks clean
<mdke> no processes i can see
<Treenaks> ok
<mdke> says 96% id tho
<zenwhen> cd burning with k3b and nautilus has gone from great in warty for me to crap
<mdke> gnome-system monitor isn't happy to start either
<zenwhen> my system just chugs while a dvd burns, and it can only burn at 2.4x, instead of the 8x it could in warty.
<mdke> Treenaks, reboot has solved it. It may have been caused when I added my network device. Bizarre that it should need a reboot tho
<zenwhen> oh good, an old windows issue has returned in linux form. Now gnome wants to beleive that a dvd i ejected is stil there even when it isnt and it isnt mounted
<zenwhen> lol
<dholbach> oh pitti was here *grmbl*
<ogra> dholbach, pitti is back :)
<dholbach> hi pitti 
<pitti> Hi
<dholbach> pitti: want to have the raw iso files?
* pitti tests WLAN suspend/resume, which is brooken for him
<pitti> dholbach: "have"?
<dholbach> for better rsyncing?
<pitti> dholbach: I thought you burn them on DVD?
<dholbach> pitti: i was supposed to send them to you?
<pitti> dholbach: yes, just burn them
<pitti> dholbach: I can get them back with dd :-)
<dholbach> ok
<pitti> dholbach: you already downloaded them?
<dholbach> just another 2 hours and i'm set
<pitti> dholbach: cool, thanks a lot
<dholbach> de rien
<dholbach> pitti: want to see something scary?
<pitti> ?
<pitti> dholbach: the ultimate root hole?
<dholbach> pitti: http://www.ubuntulinux.org/wiki/UniverseUnmetDeps :-)
<pitti> sounds like work for you :-)
* ogra makes a funny face to scare pitti
<dholbach> hehe :-)
<pitti> dholbach: argh, that's huuuge
<dholbach> YES
<ogra> yup
<pitti> bye folks, dinner & dancing waits for me :-)
<dholbach> have fun, pitti!
<Treenaks> pitti: good luck & have fun :)
<dholbach> et bon apptit
<ogra> dancing ?
<pitti> you too!
<zul> mdz: no i havent tested those vfat synchronization patches
<mpt_london> hahaha
<mpt_london> "Generates a D-BUS message when new mail arrives"
<mpt_london> This Evolution checkbox label brought to you by the RTFM Department
<Mithrandir> mpt_london: that sounds plausibly useful
<mpt_london> Mithrandir: ... I'm sure it is, if you're one of the ~0.01 percent of people who know what on earth "D-BUS" is
<Treenaks> it should just send the message and don't care
<Treenaks> you can disable the dbus-sending if you disable the plugin
* mpt_london isn't one of that 0.01 percent yet ;-)
<Mithrandir> mpt_london: yeah, as a pref, it sounds fairly useless.
<Treenaks> mpt_london: man dbus
<mpt_london> No manual entry for dbus.
<Treenaks> hm
<Treenaks> dbus-something then
<Treenaks> or apt-cache shwo :)
<mpt_london> we left Aunt Tillie a long, long time ago, Treenaks :-)
<Treenaks> mpt_london: I know :)
* mpt_london googles
<koke> elmo, ping?
<koke> elmo, I mailed a whitelist to upload@ one week ago, do you know something about?
<rubenv> are the apache2 packages in freeze, or will 2.0.53-5 (as in debian unstable) still leak into ubuntu?
<rubenv> there are debian debs for PHP5 but they depend on 2.0.53-5
<rubenv> hmmm, Maybe I'd rather rebuild them for ubuntu
<ogra> rubenv: there are no syncs with debian until the release....
<ogra> rubenv: at least not without a good reason (heavy breakage etc)
<rubenv> ogra: okay, I'll try to rebuild them manually then
<ogra> rubenv: thats really great, i'd like to see them in universe before release
<rubenv> it's just for development anyway now
<rubenv> i've just grabbed dexter's source pkg, my pbuilder chroot is updating
<rubenv> having php5 (in universe) would be nice though
<rubenv> makes my life a bit easier ;-)
<ogra> rubenv: add it here once its ready for review: https://www.ubuntulinux.org/wiki/MOTUNewPackages
<rubenv> ogra: okay, will take some time, I have experience with building seperate packages, not with the packaging process as a whole
<rubenv> but i'll manage :)
<ogra> rubenv: oh, and i heard roumors that infinity is the debian maintainer
<rubenv> ogra: hmmm, strange
<ogra> ?
<rubenv> let's see if he has more current pkgs then dexter
<rubenv> http://people.debian.org/~dexter/dists/php5/
<Mithrandir> Kamion: new ooo-amd64 with ia64 support now uploaded, so assuming it builds fine, updating the seeds should be fine.
<mdz> seen mvo or pitti today?
<Mithrandir> pitti was around a couple of hours back
<mdz> need someone to test #7138
<Mithrandir> powerpc needed, I guess?
<mdz> hmm, maybe that is all that's needed
<mdz> in which case I could test it myself
<dholbach> oh baby, wiki me harder: http://wiki.ubuntu.com/UniverseUnmetDeps :-)
<Keybuk> mdz: have a bug :p
<ogra> dholbach, why is ooo2 on this list ?
<dholbach> ogra: feel free to remove it... it's not installable, that's why and since i live on amd64 :-)
<ogra> dholbach, me too, but its all haggais, so MOTU doesnt need to touch it
<ogra> dholbach, removed :)
<dholbach> please remove it then... i.e. i won't touch any kernel/mono thing, but it's on the list too - or just put it at the very at of the list
<dholbach> hi enrico 
<enrico> dholbach: hi!
<dholbach> enrico: i saw you're the maintainer of debtags and debtags-edit
<enrico> dholbach: that's me!
<dholbach> could you rebuild them with the current apt?
<enrico> dholbach: problems?
<dholbach> no.. they're just not installable atm
<enrico> gosh, ok
<dholbach> no worry, just wanted to mention it
<ogra> enrico: i looked over the document previews today 
<enrico> dholbach: sure, thanks.  Is there a bug reported for it?
<dholbach> enrico: no, it's just on https://www.ubuntulinux.org/wiki/UniverseUnmetDeps
<enrico> dholbach: I don't understand the issue very well, however I need to chair a docteam meeting on #ubuntu-meeting now: please ping me later
<enrico> ogra: want to come to the meeting and tell how it was/
<enrico> ?
<ogra> already in the channel ;)
<mdz> enrico: the libapt ABI has changed in Hoary (more than once, even), so programs using it need to be rebuilt with the current apt
<enrico> mdz: what I don't understand is: since Hoary has source-only uploads, how come you just don't trigger a rebuild?
<enrico> I'd just need to reupload the source unchanged?
<enrico> Into... Hoary or Debian?
<mdz> enrico: correct, a source upload is required
<mdz> enrico: into Hoary, where the uninstallable package is
<dholbach> but a triggered rebuild would be VERY nice ;-)
<mdz> we don't do bin-only NMUs
<ogra> hmm, we dont do NMUs at all ;)
<psy_> NMU?
<dholbach> non-maintainer upload
<Keybuk> we don't do binary uploads at all either
<dholbach> oh my, seems like most packages on UniverseUnmetDeps are broken badly
<psy_> ah
<psy_> i remember reading something about using different apps to connect to a single gtk-widget. Does anyone here know how that works?
<psy_> ehh, not at the same time of-course, i mean different apps connecting to each-others widgets.
<Keybuk> bonobo? gtksocket?
<psy_> gtksocket? hmm, that sounds familiar (doing a google to see if that's what i mean)
<psy_> Keybuk: you're tha best :) thanx
<mdz> thom: ping?
<mdz> Keybuk: the buildds do binary uploads...
<Keybuk> mdz: the gerbils inside do, you mean :p
#ubuntu-devel 2005-03-24
<fabbione> interesting...
<fabbione> svenl: ping?
<sid77> hi
<YokoZar> Ok, I'm writing a scrollkeeper OMF file to put the Wine documentation in a standard place so it's viewable from the help menu.  The trouble is I'm having trouble figuring out what category to place it in from the list at ( /usr/share/scrollkeeper/Templates/C/scrollkeeper_cl.xml ) - is it possible to add an entry to that list, or is there one I should pick from?
<ogra> YokoZar: the doc team just finished a meeting in #ubuntu-meeting, probably there someone can help
<YokoZar> Thank you
<AndyFitz> clearlooks is the sexiest gtk engine ever
<AndyFitz> probably no chance of getting it into hoary... but damn thats a shame.   
<thully> what do you mean.. hoary preview uses clearlooks
<dredg> niall@malkovich:~(0)$ dpkg -l gtk2-engines-clearlooks|grep ^ii
<dredg> ii  gtk2-engines-c 0.4-0ubuntu2   ClearLooks theme
* AndyFitz drools
<dholbach> hehe
<AndyFitz> copy this gtkrc into your clearlooks human folder...  http://andy.fitzsimon.com.au/gtk-2.0/gtkrc    its a quick colourmod I did to make it look more like industrial.   
<crimsun> AndyFitz: both ubuntu-desktop and ubuntu-artwork depend on gtk2-engines-clearlooks
<AndyFitz> its just so professional. all the widgets look sexy
<AndyFitz> crimsun,  I thought we were using industrial by default ?
<wasabi> Who do I have to go to to get a package moved from multiverse to universe?
<wasabi> I just freed it.
<dholbach> wasabi: maybe the TB *shrug*
<wasabi> TB=?
<dholbach> technical board
<wasabi> oye.
<crimsun> wasabi: you'll need to include documentation of the new license and a copy of the conversation, too
<wasabi> It's not a license problem.
<wasabi> It was contrib previously
<wasabi> in debian
<crimsun> main now?
<wasabi> Will be if it EVER gets thru new.
<wasabi> I hear NEW in debian is pretty backed up though. :0
<wasabi> (I am in close touch with the debian maintainers)
<dholbach> wasabi: we're not debian :-)
<wasabi> yes yes yes, doesn't change the fact though.
<wasabi> It's only in multiverse because of a previous dependency. It is not a license problem.
<dholbach> if you tell it the right people in that way everything should be fine
<wasabi> i dont follow?
<wasabi> TB I can follow. ;)
<dholbach> good night everyone
<crimsun> night daniel
<Keybuk> probably not worth TB, a mail to ubuntu-devel would be sufficient
<dholbach> bye crimsun
<tseng> hi all
<mdz> Kamion: ping, re: LCA registration
<svenl> fabbione: pong
<mantiena> hi all
<fabbione> morning
<fabbione> mdz: ping?
<fabbione> svenl: ping?
<svenl> fabbione: here or on d-k ? 
<fabbione> here.. it's ubuntu related :-)
<fabbione> mind to look at this: http://people.ubuntu.com/~lamont/buildLogs/m/mplayer/1:1.0-pre6-0.3ubuntu6/mplayer_1:1.0-pre6-0.3ubuntu6_20050312-1837-powerpc-failed
<fabbione> and tell me if you have any idea of why it fails?
<fabbione> it's really a strange error (for me at leat)
<svenl> urk, mplayer, never used this one, i thought it was borderline non-free.
<fabbione> svenl: it's in multiverse
<fabbione> not main
<fabbione> it had a very broken build rules
<svenl> I would say bad altivec code at first sight, can you ask me again tomorrow ? Today is my wife's birthday and i promised not to code overmuch :)
<fabbione> yesterday i unfucked it a bit
<fabbione> and managed to get amd64 out
<fabbione> sure!
<mantiena> daniels: hi could you explain me some things about driver autodetection in yours xorg packages ?
<fabbione> svenl: have a nice day ;)
<svenl> fabbione: hehe.
<ace2001ac> fabbione: does mplayer on amd64 do everything that mplayer on i386 does?
<ace2001ac> fabbione: or do you lose some functionality?
<fabbione> ace2001ac: no idea. it builds. that's all i know
<fabbione> clearly there are no codecs around
<fabbione> so it is automatically limited
<ace2001ac> fabbione: ah, cool
<fabbione> it would be even more cool if they stopped this codec madness ages ago
<fabbione> I NEED TO FART!
<mdz> fabbione: pong
<fabbione> *** please install the new farting codec from www.fart.com ***
<fabbione> mdz: morning :-)
<fabbione> mdz: i wrote it in the mail ;)
<fabbione> i had the feeling you were asleep
<mdz> it is later than I thought, but i am not asleep yet
<fabbione> hehe
<fabbione> mdz: i am afraid your approach will slow down the process to hell
<ace2001ac> fabbione: i agree, i would prefer open codecs for everyone :)
<fabbione> that's what i am scared off
<fabbione> mdz: i think we can find another solution on the way of langpacks instead
<fabbione> mdz: exposing a tarball from the buildd that can be fetched by everyone
<mdz> that is much more complicated than I think it needs to be
<fabbione> mdz: it is more complicated the other way imho
<fabbione> specially for arches in "port in progress"
<fabbione> where we have no access
<fabbione> and i am not talking about sparc here :-)
<fabbione> but more generally
<mdz> the architecture is not very important, as far as I am concerned
<mdz> it is not necessary to do builds on every architecture
<fabbione> indeed it is
<fabbione> the ABI file is per arch per flavour
<fabbione> or subarch
<mdz> the ABI has been broken several times already in hoary
<fabbione> or whatever you want to call it
<mdz> and 0 of those times have been arch-specific
<fabbione> well that's because we have never seen nvidia on ppc
<mdz> the point of this exercise is to catch the common mistake
<fabbione> or stuff like that
<fabbione> yes i understand your point but since we are doing it, let's do it full feature
<fabbione> take into account that such manual requirement can delay an upload up to 4 hours
<mdz> I don't want to get involved with transferring this data in and out of the buildds when something simpler would meet the realistic requirements
<fabbione> (due to ppc)
<fabbione> and i am talking for one build.
<fabbione> if that build breaks the ABI the upload will take ages
<fabbione> either to find what breaks
<fabbione> or to change the ABI
<fabbione> otherwise i think we should defer this for hoary+1
<fabbione> and discuss at UDU how to implement it so that it is an easy tool to use
<mdz> by all means, let's discuss for hoary+1 how to do it the way that you want
<mdz> but for now, we can implement it as I propose and get significant benefit
<fabbione> ok i will see with the other guys
<fabbione> and what they think about ti
<mdz> we can't break the ABI this way anymore in Hoary; it disrupts development and testing too much
<mdz> the current set of live CDs are broken because of it
<fabbione> didn't they sync with -27 ?
<mdz> no
<mdz> it requires a d-i build and byhand upload
<fabbione> humpf...
<mantiena> mdz: I've patch'ed casper's package to have installation mode - added boolean casper/install-mode variable into template and when this variable is set to yes, then:
<mantiena> 1.  all casper's post.d scripts are disabled
<mantiena> 2. "pivot_root . initrd" and "kill -USR1 1" are not executed in casper-udeb.postinst
<mantiena> 3. "umount /target", ""mkdir /source" and "mount /dev/mappper/casper-snapshot /source" are executed at the end of casper-udeb.postinst
<mantiena> (look at http://www.gnoppix.org/wiki/index.php/LiveCDInstaller )
<mantiena> could you add my patch to official casper package ? then ubuntu-based liveCD distributions could have a posibility to install liveCD to hard disk without patching casper's package every time, when new casper version is released
<fabbione> mdz: but d-i is builded daily, so it should be there
<mdz> mantiena: not for Hoary, but I already planned to implement such a feature for Hoary+1
<fabbione> ideally the livecd should be able to use it
<fabbione> mdz: how about this:
<mdz> fabbione: it is built daily, but it isn't installed until elmo byhands it
<mdz> and often elmo can't do this until after the daily CD build
<fabbione> ah ok...
<mdz> honestly, the best solution is not to break the kernel
<mdz> it is not only the CDs, but user systems
<fabbione> yes i agree on that :-))
<fabbione> i suggest this approach
<fabbione> we can add an -abi package to distribute the last built abi
<fabbione> at least for people without porting machine access
<fabbione> we do NOT build-dep on it
<svenl> daniels: i spoke some with benh, and it seems that if there is one monitor, it will always be edid1, independently on which port is it connected.
<fabbione> but at least the abi are available for download from the archive
<fabbione> it would make it easier the development
<svenl> daniels: there will be a change to these things later on, but this will be post-hoary, and we need to rework xresprobe to do proper multi-headed stuff though.
<fabbione> in case of a dumb upload the abi checker will make the kernel FTBFS
<fabbione> so there is actually no breakage
<mdz> it can't perform the check without build-depending on the package
<mdz> which is why I specified that it should go in the source package
<fabbione> mdz: no it is still the maintainer job to grab the abi's and put them in proper source
<fabbione> but it gets easier than going around porting machine and fetching them manually
<fabbione> what has been built must still be copied in the source
<fabbione> just a simpler way to distribute them around
<mdz> I had good reasons for specifying it the way that I did, and paramount among them was simplicity
<fabbione> yes but again.. i don't want to build-dep on it
<fabbione> it's just to make it easier to have the abi files available
<fabbione> but if you don't like it.. ok. we can live with that
<mdz> for hoary, let's do it my way, and in UDU, you can take responsibility for specifying the second iteration
<fabbione> ok
<dholbach> hai
<mantiena> mdz: but my patch doesn't nothing if variable casper/install-mode is set to no (default is no), so it would break anythink in hoary
<mantiena> it's very simple, only one if and else ;)
<fabbione> mantiena: we are at 3 weeks from release
<mdz> mantiena: we are a full month into feature freeze, please respect the release cycle
<fabbione> each patch means a big round of testing
<mdz> I like the idea; as I said, I had already planned to implement this for hoary+1
<mdz> but your implementation is not complete, and I see no reason to force it into hoary
<mantiena> mdz: what I should complete ?
<mdz> mantiena: from looking at your wiki page (why is this in the gnoppix wiki rather than the Ubuntu wiki where I would have seen it?), you don't configure the base system at all
<mdz> there is no partitioner
<mdz>  /etc/inittab will be completely inappropriate for the installed system
<mantiena> mdz: it seems you don't understand me
<mantiena> ubuntu-installer already has partitioner
<mdz> not on the live CD it doesn't
<mantiena> mdz: it's not my problem, because older live CD versions (until array-5) contained all needed udebs for installation
<mdz> mantiena: that was a bug which has since been fixed
<mantiena> mdz: I don't call it a bug ;)
<mdz> well, that's what it was
<mantiena> why you think, that /etc/inittab will be completely inappropriate for the installed system ?
<mdz> because you copy it from the live CD
<mdz> according to your wiki page
<mantiena> filesystem.cloop has bad inittab ?
<mdz> oh, you disable post.d
<mdz> so the language is not configured, etc.
<mantiena> hehe :-P
<_d4vid> hi all
<mdz> mantiena: here is how we implement features in Ubuntu
<mdz> first we establish requirements
<mdz> then we write a specification
<mdz> these are discussed among developers
<mdz> and then we write the code
<mantiena> mdz: I already wrote specifications at http://www.gnoppix.org/wiki/index.php/LiveCDInstaller :)
<mdz> from the beginning the feature is targeted for a release, and is incorporated at the appropriate time in the releasae cycle
<mdz> we do not take a feature, which appears from nowhere, and drop it into the release at the last minute
<mdz> this is a post-Hoary feature
<mantiena> mdz: ok, but maybe you could just add my patch into casper sources and don't enable it at build time ?
<mdz> mantiena: why?
<mdz> mantiena: if you are looking for acknowledgement of your work, thank you, I think it is very interesting
<mdz> but it does not belong in hoary, it will need to wait
<mantiena> my patch simply modifies 3 files:
<mantiena> http://files.akl.lt/incoming/casper/casper-check.templates
<mantiena> http://files.akl.lt/incoming/casper/S60casper-check
<mantiena> http://files.akl.lt/incoming/casper/casper-udeb.postinst
<mdz> I have said no, and I will not be pressured on this
<sm> give up mantiena :)
<mdz> don't give up, just be patient and work according to our schedule
<mantiena> it's hard to work with ubuntu developers - they don't want to accept others work, there are no CVS, SVN where other developers could put patches :(
<mdz> the former is demonstrably false
<mantiena> mdz: so, where I should put my patch to be visible ?
<mdz> it is true that we do not have a centralized revision control repository, but the fact that there are many people already collaborating on Ubuntu shows that this is not a requirement
<mdz> mantiena: where would you put it if we had a CVS repository?
<mantiena> mdz: in CVS
<mdz> mantiena: it would not go in CVS for the same reason that it won't go in the Hoary package
<sm> you guys could do with a bunch of darcs repos
<sm> mantiena could publish and ubuntu could pull when ready
<mdz> sm: we're converging on arch
<sm> ah
<mdz> we just don't have everything imported at this point
<mdz> it will happen, though
<mdz> I have been meaning to import casper; I just haven't had time to do it properly
<mdz> mantiena: if I put casper in arch, so that you could branch and publish your patch that way, would that help you?
<mantiena> mdz: YES
<mantiena> my live CD was based on morphix framework and it was great to work together with morphix developers, because they don't force me to follow to they shedule, I always could add my work to official CVS repository if not in main branch, then in another ;)
<mantiena> and then other developers could review and test my work.
<mdz> morphix doesn't have a schedule
<mdz> and so far in your dealings with Ubuntu, you have been aggressive, uncooperative and impolite
<mantiena> mdz: I'm simple
<mantiena> I'm not very good in english, but this was not a problem with lots of other projects, which I work together
<mantiena> mdz: I'm not aggresive and not uncooperative
<mantiena> I simply tell what I think
<mantiena> maybe not in perfect english language
<mantiena> mdz: I'm always happy to critique, so if you see any problem you can tell me.
<mantiena> If you put casper in arch, cvs, svn or something and allow me to put code to separate branch it would be very good for me (and for other developers, like amu from gnoppix).
<mantiena> Maybe then there will be less communication problems between us ? ;)
<mdz> mantiena: baz register-archive http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004
<mdz> mantiena: I had intended to do it for some time anyway
* mantiena goes to learn arch
* mantiena never tried arch ;)
<mdz> mantiena: so if you had asked for it, rather than accusing Ubuntu of being hard to work with, that would have been more productive
<mdz> it is very easy to set up
<mantiena> yes
<mdz> but I am extraordinarily busy, and I am trying to have a weekend off
<mantiena> mdz: I'm happy, that you allow me to work togerher
<fabbione> mdz: you didn't have much of a success up til now ;)
* fabbione kicks mdz out of the internet
<mdz> fabbione: and I still am not; I end up spending my weekend arguing with mantiena
<fabbione> mdz: go and rest dude
<fabbione> mdz: if there is anything important i will send you an sms
<dholbach> mdz: yeah... have a nice weekend
<mdz> I am trying to promote understanding and cooperation :-P
<fabbione> mdz: i am cooperating to let you have a weekend
<fabbione> go out of here
<fabbione> and relax
<fabbione> otherwise i am going to break you in a few pieces at UDU
<fabbione> :P
<fabbione> you must rest
<dholbach> fabbione: you forgot the exclamation marks
<mdz> exclamation marks are not necessary
<dholbach> hi doko
<YokoZar> mdz I am giving you an electronic weekend over the internet so you don't need to find one ok?
<mdz> YokoZar: thanks, but there is no electronic substitute :-)
<YokoZar> We can still be eFriends right?
<doko> good morning all
<HiddenWolf> morning
<mantiena> hi doko
<mantiena> hehe, it seems arch in debian is *very* outdated (more than 3 years old. :( )
<rubenv> mantiena: that's why all the cool kids use Ubuntu ;-)
<mdz> mantiena: apt-get install bazaar
<mantiena> rubenv: ubuntu doesn't have arch package :-P
<mantiena> mdz: ok, it seems at least arch package description in debian should be updated ;)
<whiprush> tla is also available
<mdz> mantiena: don't be ridiculous
<mdz> mantiena: ubuntu has both tla and bazaar, the two main implementations of arch
<mdz> Debian does also
<mdz> Debian's tla is slightly more up-to-date, and Ubuntu's bazaar is slightly more up-to-date
<rubenv> (but main is in freeze now)
<mantiena> GheRivero: hi, how things are going in spain ?
<mantiena> mdz: I don't wanna waste your time, but in any case if some user (who never tried arch) want's to use arch then first thing he tries is apt-get install arch ;)
<rubenv> mantiena: a new time user should rather read a guide on how to use it
<rubenv> and that guide will always mention tla/baz
<mantiena> rubenv: yea, that's why I installed arch
<mantiena> rubenv: and read files in /usr/share/doc/arch
<rubenv> a website always contains better info dude :-)
<GheRivero> hi mantiena! really good! 
<GheRivero> and there?
* rubenv out to breakfast
<mantiena> rubenv: and noticed, that they are more than 3 years old and don't mention not tla nor baz :(
<mantiena> GheRivero: in Lithuanian not so good - fucking government publish almost all document to Lithuanian people only in fucking MS Office formats, also lots of public sector's web pages work only with fucking MS IE :((((((((
<GheRivero> that's a problem,a big problem
<crimsun> mdz: err, sorry about #7556. If Malone's ready, I'll use that instead.
<mantiena> yea, in lithuanian there is a law for government institutions that they should publish all document also in open formats, but majority (about 95%) of government institutions don't follow this law :(
<mantiena> so even when people buy computer with linux, they are forced to buy or pirate M$ Windows, because they simply can't fill tax form or read info from public sectors web pages with Linux :(
<HiddenWolf> mantiena: luckily the EU has put some clout behind legislation that all documents should be oss formats
<doko> mithrandir: around?
<Mithrandir> yes
<doko> can you reproduce the libdl.so error, after removing ia32-libs?
<Mithrandir> which libdl.so error?
<doko> #7542 and #7543
<Mithrandir> given that I haven't read email yet today, no, I haven't seen them and haven't analyzed them.
<mantiena> HiddenWolf: in our country such law is active about 2 years, but problem is, that institutions don't follow law :(
<mantiena> haggai: you are openoffice.org maintainer, right ?
<Mithrandir> doko: give me time to eat some breakfast and I'll look at it afterwards.
<dholbach> does anybody know the specification of the amd64-buildd?
<fabbione> dholbach: they are big fat mother fuckers :)
<dholbach> just want to estimate how long the ACE build is going to take on my box
<dholbach> *cry* it took nearly 1,5h on the buildd
<doko> Mithrandir: thanks
<dholbach> fabbione: i like your explicit use of language, it makes things less virtual :-)
<fabbione> dholbach: ???
<fabbione> in reference to what?
<dholbach> fabbione: "big fat mother fuckers" :-)
<fabbione> ahhhh
<fabbione> i am pretty famous for that
<dholbach> yeah... thanks for that :-)
<fabbione> Mith and thom know :-)
<dholbach> i was nearly lying on the floor, when you talked about dildos, goatse and CAN
<fabbione> ahaha
<Mithrandir> dholbach: iirc, they are dual 246 or 248s with 2G of memory and decent disk systems.
<dholbach> 246 doesnt tell me anything
<Mithrandir> 246 is opteron at 2.0GHz
<dholbach> but sounds like it's about to take 4 hours at my place or something
<Mithrandir> depends on whether the build uses both CPUs or not.
<dholbach> just for a one-line-change
<HiddenWolf> dholbach: then wait untill you've changed more lines. :)
<dholbach> somebody hand me a club... a big one please ;-)
* Mithrandir drops a club on dholbach's foot.
<dholbach> HiddenWolf: run! ;-)
<Mithrandir> fabbione: mplayer seems to be a happy badger here
<HiddenWolf> dholbach: ;)
<dholbach> oh... it's about to finish... "only" 2,5h :-) *YAY*
<Mithrandir> doko: does hoary support the Fritz!DSL adapters now?
<doko> Mithrandir: yes
<doko> Mithrandir: not yet on amd64
<Mithrandir> doko: ok, cool.  Out of the box?
<Mithrandir> If so, I'm pondering doing a reinstall of my router.
<doko> well, you have still to edit /etc/isdn/capi.conf to uncomment one line ...
<Mithrandir> sure, I have a working system so I can duplicate most stuff from there.
<doko> wasabi: is there a need for this really_long_usr_lib_jdk_home_path_that_nobody_can_remember pathname in java-gcj-compat ?
<mantiena> haggai: you are openoffice.org maintainer, right ?
<doko> mithrandir: how do you let a buildd think it runs on i386 instead in a i386 chroot on amd64. unfortunately uname -m tells the truth ...
<Mithrandir> linux32
<mjg59> thom: Got some new crack for power management
<amu> elmo: jackass say "ccache: failed to create (null)/.ccache (No such file or directory)" http://people.ubuntu.com/~lamont/buildLogs/b/blender/2.36-1ubuntu1/blender_2.36-1ubuntu1_20050313-1139-i386-failed
<amu> mjg59: did you find out why sleep doesnt work on a ibook? 
<mjg59> amu: Which ibook?
<mjg59> How does it fail?
<mantiena> amu: hi
<amu> mjg59: ibook g4 ... resume doesnt work correctly, after awacke, there's a black screen
<amu> mantiena: hi 
<mjg59> amu: Try disabling DRI and GLX in your X configuration
* amu tries 
<jordi> d
<amu> mjg59: great, works! only a problem, if a usb-stick is plugined 
<mjg59> amu: Ok. What sort of ibook is it?
<kagou> is there a way to allow a new installation to keep the /home directory ? (single partition)
<amu> mjg59: ibook G4 1200mhz (287), revision 1.2,  12"   
<mjg59> Radeon 9200?
<amu> yep 9200 M9+ rev.01, RV250, 5c63 
<mantiena> kagou: yes
<kagou> mantiena, could you explain me ?
<mantiena> yes ;)
<mantiena> fabbione: ubuntu bug #3609 is assigned to you, what you think about solving this bug ?
<mantiena> currently ubuntu users can't work with firewire devices :(
<HiddenWolf> what is that entire mess with libhowl?
<Treenaks> license mess
<Treenaks> some part of it was licensed under some non-free apple license
<lunitik> Thank you to whoever pushed for Clearlooks as default theme, good choice  :)
* lunitik also appears to have found ClearlooksHuman  8)
<mantiena> fabbione: are you online ?
<ogra> lunitik: thank our sabdfl :)
<lunitik> ogra, 8-)   (still wonder what that means though)
<ogra> lunitik: self applied dictator for life
<ogra> lunitik: Mark Shuttleworth
* lunitik points at the B... 
<lunitik> you don't have that covered  ;)
<Mithrandir> benevolent
* lunitik knew who it was though  ;)
<ogra> oh, shame on me, benevolent indeed
<lunitik> Still cool though to see the person responsible for Ubuntu online with the users and devels though  :)
<seb128> elmo: pwlib / gnomemeeting syncs please
<thierry> Hi, I'd like to make a new ubuntu package for the new version of gdesklets (0.34.1) can anyone give an url or advices how to do this?
<seb128> oh, nice
<seb128> gdesklets is looking for a new maintainer :)
<ogra> lol
<Mithrandir> seb128: "more than 2G memory recommended"? ;)
<seb128> I've planned to mail about some GNOME stuff that need a maintainer
<dholbach> thierry: you could join #ubuntu-motu :-)
<seb128> Mithrandir: gdesklets is really crap
<Mithrandir> seb128: no shit? :)
<seb128> upstream break compatibility and user configuration every 2 new versions
<mantiena> seb128: you are gnome-system-tools maintainer ?
<dholbach> seb128: we put nautilus-media on http://wiki.ubuntu.com/MorgueCandidates?
<ogra> thierry: thats a very brave attempt, respect :)
<seb128> the desklets are a collection of quick and dirty python stuff wroten by guys who don't know how to program, just do a quick hack and don't maintain it
<seb128> etc
<dholbach> seb128: hope it's ok
<seb128> dholbach: read the list and bugzilla please
<seb128> mantiena: correct
<fabbione> hey seb
<seb128> dholbach: there is a bug in bugzilla about nautilus-media
<dholbach> seb128: could we reflect this decision in gnome-desktop-environment?
<fabbione> mantiena: i am now, but not for long
<seb128> the gnome package needs to work to, if somebody wants to send a patch he's welcome
<seb128> hi fabbione 
<seb128> basically we have gnome from debian 2.8
<seb128> gnome/gnome-desktop-environment/... etc
<seb128> I don't really care since we use ubuntu-desktop
<mantiena> seb128: there is one problem for desktop users in users-admin tool - they create a new user with users-admin, but newly created user can't work with audio, cdrom, various usb devices, etc, because newly created user isn't added to needed groups as default
<fabbione> seb128: i am getting this building a bunch of packages on sparc:
<fabbione>  /bin/sed: can't read /usr/lib/libhowl.la: No such file or directory
<mantiena> fabbione: ubuntu bug #3609 is assigned to you, what you think about solving this bug ?
<dholbach> seb128: but waht would be the deal if we just removed the dependency from gnome-desktop-environment?
<fabbione> seb128: is it just question of kicking it back?
<seb128> mantiena: it really should, ping sivang about this, he's working on that
<seb128> fabbione: grep howl /usr/lib/*.la ?
<ogra> mantiena: did you choose the right profile ?
<seb128> dholbach: I don't really care but I would prefer if somebody updates it for GNOME 2.10
<fabbione> seb128: i did it a long time ago when we unrolled the libhowl problem.. apparently some package still search for it, but it's nothing important
<seb128> fabbione: should be a just kick yep
<fabbione> seb128: or urgent
<mantiena> ogra: there are already preconfigured profiles in ubuntu's users-admin ?
<fabbione> seb128: roger that :-)
<seb128> mantiena: correct
<ogra> mantiena: thats what sivang introduced, yes
<mantiena> ogra: hehe, it's what I want to suggest ;)
<fabbione> mantiena: hounestly.. i have 132 bugs assigned on me and that is one with the lowest priority.
<fabbione> (or almost)
<fabbione> so please do not push for stuff
<thierry> seb128: what is the bug for the gnome package thing?
<seb128> thierry: what bug ?
<seb128> move to query for gdesklets
<mantiena> fabbione: but this one could be fixed just adding one line in /etc/udev/links.conf
<fabbione> mantiena: no. it's not. read the bug carefully including the kernel patch.
<mantiena> fabbione: Mandrake developers choosed simpler way ;)
<wasabi> doko, JPackage convention.
<wasabi> doko, there is supposed to be a symlink farm in /usr/lib/jvm that makes it easier to find... but I haven't stumbled onto the code that manages it yet, or the policy docs. I will be doing that soon.
<mantiena> fabbione: users don't care which way developers choose for fixing not working firewire subsystem, they just want to work with firewire devices, for example with digital video cameras :)
<fabbione> mantiena: i do, because a wrong fix can make the hell of maintainace afterwards
<mantiena> fabbione: I understand, that you do ;)
<mantiena> fabbione: could you tell me if this bug is planned to be fixed in hoary or only in hoary+1 ?
<fabbione> mantiena: if you can provide me all the patches to fix major bugs, i can start spending time on normal ones.
<mantiena> fabbione: sorry, I can't provide all patches, I just ask if hoary final version will have /dev/raw1394 or not ;)
<ogra> mantiena: who knows
<fabbione> if i will get to do it yes. otherwise no
<zul> morning
<ogra> mantiena: the fact that its in bugzilla and assigned to a (very good) dev should be enough....
<fabbione> ogra :-)
<ogra> ...no need to poke someone about it all day
<ogra> fabbione, :)
<zul> ogra: stop sucking up ;)
* fabbione goes and dries his feet
<doko> wasabi: for the OOo2 build I have to add gij/gcj symlinks/scripts into the compat package. is this ok with you?
<wasabi> if you can wait one second I can ask some redhat guy what the symlink is supposed to be.
<wasabi> or find it on some jpackage list
<wasabi> it's hte one thing I couldn't find in their policy
<wasabi> I suspect it is simple supposed to be /usr/lib/jvm/java-gcj
<wasabi> I am |    | this close to having Ant working. ;)
<wasabi> Yes. /usr/lib/jvm/java-gcj looks right.
<wasabi> I can add that if you want me too. I was going to do it anyways today.
<doko> and /usr/lib/gcj-java-compat goes away?
<wasabi> Yes.
<wasabi> I won't get rid of that for a bit though. I've been using it. =/
<doko> wasabi: please do so and upload the package (with the gij/gcj scripts similiar to the rmic script)
<wasabi> uh oh.
<wasabi> you need rmic?
<doko> no, did I say so?
<seb128> later
<wasabi> Well you hinted at it?
<Nafallo> fabbione: is mplayer-custom still used? IMO it does what -nogui should do :-P. just that -nogui should build on all platforms...
<HiddenWolf> Is there any utility that can assist me from copying this working ubuntu setup to another computer?
<wasabi> tar
<wasabi> #ubuntu for that though
<psy_> wasabi: or mount ;)
<psy_> mount -t nfs ... ... 
<Goshawk> i've upgraded the sources of a library and built a new library package, do you need a ubuntu sponsor to upload them=?
<dholbach> Goshawk: for universe or for main?
<Goshawk> the update library is libdirectfb that is in main at 0.9.20, i've done 0.9.22
<Goshawk> and the other is a new package
<Goshawk> linked at libdirectfb and it's called lib++dfb (never pacakged)
<Goshawk> i've tried them
<Goshawk> and they works
<ogra> Goshawk: on all arches ?
<Goshawk> no.. only mine
<Goshawk> -__-
<dholbach> Goshawk: ok... you'll have to ask in this channel or write a mail to the mailing list (ubuntu-devel@) - if you don't have really really good reasons for it, i'm not sure if it will be taken into account for hoary release
<Goshawk> since i've only one pc ^__^
<ogra> fb is very architecture critical....
<Goshawk> yes... but they are needed for usplash
<Goshawk> usplash is going to be base on them because they are going to be a standard
<ogra> Goshawk, its unlikely they will get into main for hoary
<Goshawk> ok...
<Goshawk> one question.. do community packages became canonical packages (and added in main) ?
<ogra> Goshawk, but i dont make the decisions for main, ask again if someone of the main team is around who can decide about it, or follow dholbachs advice to mail it
<Goshawk> ok
<ogra> Goshawk: i dont understand...
<ogra> Goshawk: do you mean if universe packages can get lifted to main ?
<Goshawk> yes
<Goshawk> excuse my english
<ogra> Goshawk: if required, yes
<Goshawk> understood
<ogra> Goshawk: mine isnt much better ;)
<lamont> amu: ccache errors during the build should get a bug filed and assigned to me.
<dholbach> hey lamont
<jon1012> I just installed the hoary preview on one of my computers, and I works great, no problem seen for me :)
<dholbach> lamont: i'm trying to tackle some of http://wiki.ubuntu.com/UniverseUnmetDeps, and try to figure out, why drscheme didn't get built on amd64?
<lamont> dholbach: PaS update needed
<dholbach> erm... PaS?
<lamont> %drscheme: alpha i386 powerpc                                         # version 103 does not support other archs
<lamont> packages-arch-specific
<dholbach> OH
<lamont> amd64 is specifically excluded, and should be added to the file - bug elmo
<lamont> I assume that it does, in fact, build on amd64
<lamont> >
<lamont> ?
* lamont must run for several hours..
<dholbach> stupid me... i thought i read amd64 in the architecture line
<lamont> it's quite possible
<dholbach> sorry for bugging, i'll check if it works again
<ogra> lamont: do you have any idea how it can happen that someone is able to upload, recieves katie replys, but none of the mails get forwarded to hoary-changes ?
<ogra> lamont, the packages build ine and seem to appear in the build logs as well as inthe archives
<ogra> fine even
<crimsun> (that someone being me)
<ogra> yep
<ogra> crimsun, i think we'll have to wait for elmo then....
<crimsun> ogra: np, I'll just continue my Xorg march :-)
<crimsun> 2 of 4 done
<ogra> yup
<ogra> WOW
<crimsun> doing afterstep now
<ogra> heh, wipe the dust away before you upload ;)
<crimsun> :-)
<dholbach> lamont: bye *wave*
<zenwhen> wow the livecd has gotten REALLY slick
<mxpxpod> dholbach: have you updated gconfmm to 2.10.0?
<dholbach> mxpxpod: yes
<mxpxpod> dholbach: awesome
<smurfix> Rosetta bugs ("A system error occurred") go where?
<ogra> malone ?
<dholbach> #rosetta ? malone/product/rosetta?
* smurfix duh's himself
<Treenaks> mjg59: You know a bit about ACPI, right?
<dholbach> ok... i'm out with my dog... see you later
<mjg59> Treenaks: Yeah
<mjg59> What's up?
<Treenaks> mjg59: I have a Compaq Armada E500 here, with a kernel panic somewhere in ACPI when I press the volume up/down buttons
<zul> heh sounds familar
<Treenaks> mjg59: I'll get a dump of the panic tomorrow (when I have a serial cable)
<mjg59> Treenaks: Oh, cool
<Treenaks> cool? :)
<Treenaks> the buttons are located in an annoying place, I crash the machine all the time :)
<mjg59> That you have a trace, rather than it just falling over silently
<Treenaks> ah ok :)
<mdke> i am about to file a bug but thought maybe to ask here
<mdke> i have a strange problem. When i disactivate and activate a network device, something goes screwy and gnome gets weird on me. I can't logout, gnome-terminal crashes before I can open it, evolution takes 5 minutes to load, and I can't open any system-tools. Can anyone help?
<mxpxpod> tseng: ping
<blueturtle> anyone here run Eclipse?
<wasabi> me
<wasabi> heh why do you need?
<wasabi> actually #ubuntu might be better
<blueturtle> ah, i'm just wondering about command line specifics
<blueturtle> when i run /usr/local/eclipse/eclipse
<blueturtle> it runs fine, but if i put that into a launcher, it fails
<wasabi> mind msging me or talking in #ubuntu?
<blueturtle> sure
<blueturtle> sry, thought eclipse would fall under dev
<wasabi> Well, this is more for developing Ubuntu itself.
<blueturtle> ah ok
<mako> jdub: hey dude, you can create the brazilian ubuntu mailing list?
<crimsun> daniels: around?
<crimsun> crap, he's probably asleep
<dholbach> hi mako
<robertj> any thoughts on making the livecd background during hardware detection another color besides blue?
<mako> dholbach: hola
<tritium> Hi mako 
<HiddenWolf> will there ever be more than one ubuntu theme to choose from? :)
<robertj> ok, on the live cd, and on my desktop as well, using the connect to server dialog creates the connection but won't connect, giving an error about not having a handler, but clicking it on the desktop works, does this go to bugzilla.gnome.org or bugzilla.ubuntulinux.org?
<HiddenWolf> robertj: I'd file it in ubuntu, they can always take it upstream
<mxpxpod> fabbione: ping
<zul> mxpxpod: he's gone for the day
<mxpxpod> ah, ok
<mxpxpod> zul: thanks :)
<mxpxpod> thom: ping
<mxpxpod> zul: don't tell me he's gone as well :)
<zul> mxpxpod: not sure im not the information booth ;)
<mxpxpod> hehe
<zul> and im gone now as well :)
<mako> tritium: hey dude
<tritium> :)
<ogra> AAARGH
<ogra> http://ubuntu-bp.sourceforge.net hoary-backports/main Packages 
<ogra> its not even out yet
* dredg wonders how many problems backport users will have on upgrade
* dredg doesn't want to think about that actually
<zenwhen> dredg, half of my packages refused to upgrade
<zenwhen> I clean installed.
<dredg> marvellous
<ogra> heh
<zenwhen> hoary's repos lack nothing I need.
* ogra thinks there should be a flashing red warning in 48pt letters on the backports site
<robertj> ogra: speaking of unofficial packages, hula works nicely
<ogra> robertj: which one did you try ? the one thats in revoew for universe ?
<ogra> review even
<stuNNed> ogra: lol
* dredg is just reading the backports page
<dredg> strongly disagree with all of it but hey
<robertj> I googled for hula debs, found a site that said the person doing them was on hoary and testing on sid - deb http://www.eurobob.eclipse.co.uk/hula 
<ogra> hoary-backports -- Stable, tested updated packages for Ubuntu Hoary (5.04)
<ogra> that one really scares me
<HiddenWolf> lol
<mantiena> daniels: hi are you online ?
<ogra> robertj: here are the packages that will soon get include in universe: https://www.ubuntulinux.org/wiki/MOTUNewPackages
<robertj> what is rkae
<robertj> err rake
<ogra> no idea :)
<dredg> heh
<dredg> so anyone want to start a 'universe package a day' writeup? :)
<thully> anyone here who does universe/multiverse work?  I had a few questions/requests...
<pvh> thully: $ubuntu-motu
<pvh> thully: s/$/#/
<pvh> So this morning Evolution stopped working, apparently because I don't have libgtkhtml3.6-15 installed.
<pvh> Unfortunately, there is no installation candidate for that library.
<pvh> Ah, this fixed it:
<pvh> sudo ln /usr/lib/libgtkhtml-3.6.so /usr/lib/libgtkhtml-3.6.so.15
<dredg> looks old
<dredg> my evolution depends on libgtkhtml3.6-18 (>= 3.6.0)
<pvh> I just did an apt-get update && apt-get dist-upgrade
<pvh> dredg: That was my first thought too.
<pvh> dredg: What Evolution do you have installed?
<dredg> 2.2.0-0ubuntu3
<pvh> Yeah, same here.
<pvh> Do you have a /usr/lib/libgtkhtml-3.6.so.15 file?
<dredg> niall@malkovich:~(0)$ ldd `which evolution`|grep gtkhtml
<dredg>         libgtkhtml-3.6.so.18 => /usr/lib/libgtkhtml-3.6.so.18 (0xb7890000)
<pvh> dredg: Ditto.
<pvh> dredg: but I imagine it's one of the other modules in evolution.
<dredg> yes i do
<pvh> dredg: Would you be willing to rename it for a moment to see if you can duplicate the behaviour?
<dredg> niall@malkovich:~(0)$ dpkg -S libgtkhtml-3.6.so.15
<dredg> libgtkhtml3.6-15: /usr/lib/libgtkhtml-3.6.so.15.2.0
<dredg> libgtkhtml3.6-15: /usr/lib/libgtkhtml-3.6.so.15
<pvh> I haven't got it. :)
<pvh> Nor are there installation candidates in any of the hoary repositories.
<dredg> i've moved that lib elsewhere
<dredg> evolution starts fine
<pvh> Hmmm.
<pvh> Curiouser and curiouser.
<pvh> I'd like to file a good bug report for this one. Have you got any other ideas what might be going on?
<dredg> tried an strace?
<pvh> No, I'm not sure what that is or how to use it.
<pvh> But I am reading the man page.
<pvh> dredg: Well, I think whatever the problem is runs deeper than I have time to understand.
<pvh> dredg: I'll just file it without a solution.
<pvh> Thanks for your help.
<dredg> np
<dholbach> re
<zul> +-
<JStrike> Not a totally #ubuntu-devel appropriate question, but nevertheless. gnome-app-install dies on startup complaining that "ValueError: unknown locale: en_ZA". Is this a bug in gnome-app-install or in python?
<GheRivero> res
<mdz> JStrike: neither; it typically means that your locale hasn't been generated.  make sure you have language-pack-en installed
<kent> hmm, is not update-manager in rosetta?
<JStrike> mdz : Thanks
<mooch> hummm
<mooch> the new gnome does not show focus on a maximized window when cycling with alt-tab
<mooch> the non-maxied windows show a black line around the windows
<mooch> the maxied one does not
<robertj> mdz: the bug I talked to you about yesterday and you were unable to duplicate was duplicated by mean today on the LiveCD and by a rawhide user in #gnome, it's filed at http://bugzilla.gnome.org/show_bug.cgi?id=170242
<robertj> Not an ubuntu thing, but I'm very dissapointed for not catching this earlier. Apparently if you have keys setup for the remote host it doesn't b0rk. 
<Riddell> how does gnome-volume-manager mount things when it isn't root?
<tseng> Riddell: it uses pmount
<tseng> Riddell: which you probably haev a manpage for, its an suid mount wrapper
<Riddell> tseng: yep, thanks
<seb128> lamont: here ?
<tseng> np
<psy_> bye
<ogra> seb128: ping
<seb128> pong
<ogra> pitti gave me #6003, do you still see this behavior ?
<ogra> 6002 even
<seb128> ogra: lemme try
<seb128> ogra: seems to work
<ogra> great, here too
<ogra> seb128, so i'll ask thom tomorrow, and if he's fine too, i'll close it, thanks for testing :)
<seb128> np
#ubuntu-devel 2005-03-25
<zenwhen> Me and my pathetic dialup connection have caught you developers again.
<zenwhen> :)
<jdub> seb128: arh!
<seb128> hey jdub 
<tritium> Hello jdub
<ogra> hi jdub
<dholbach> hi jdub 
<Riddell> "dpkg-source: warning: ignoring deletion of file debian/quanta.doc-base" how do I tell it not to ignore it?
<jdub> gooood morning everybody :)
<tseng> hi jdub 
<jdub> very hot for 10:00 :|
<ogra> jdub: come over, we have -5 here
<jdub> any snow?
<ogra> just melting but still a lot
<thully> I have a question - does info on using the itunes music store on Linux belong in RestrictedFormats?
<jdub> thully: sure
<thully> OK
<jlj> thully: regarding your email, which gstreamer packages where you referring to which are not in default ubuntu install?
<jlj> s/where/were
<ogra> jlj: lame
<tritium> jdub, I read a paper last night with an acknowledgement to "J. Waugh for his support of...computational requirements."   Could that be you?
<jdub> tritium: did i lend someone a computer? ;)
<tritium> jdub, dunno :) page 12: http://mip-lab4.ecn.purdue.edu/~rimbert/tobit-mle.pdf
<jdub> probably not ;)
<tritium> quite a coincidence, either way
<thully> yes -lame - that would go in multiverse
<jdub> seb128: woo, gst-ffmpeg ;)
<thully> here's instructions on how to build this:
<thully> http://www.columbia.edu/~jr2075/gstreamer-lame-how-to.html
<seb128> he he
<zul> evening
<Mithrandir> hooray, my hoary box with capi/DSL stuff now works.
<Mithrandir> I think we should move dhcp-server later in the boot sequence, since you might want to run the dhcp server on hotplugged interfaces.
<tseng> thully: hey dude, no need to crosspost that stuff. i gave you specific instructions to do in #-motu
<jlj> thully: the ubuntu PyMusique packages don't need lame
<zul> tritium: it could be a long distant relative of jdub stranger things have happened
<jdub> hey jlj
<thully> tseng: sorry - I saw some people talking in here about LAME - I justnoticed what yousaid in motu now
<jdub> zul: so there's an african-american university football player called "jeff waugh" too
<jlj> hi jdub 
<jdub> zul: now *that's* weird ;)
<tseng> jdub: he's your spitting image, believe it or not
<thully> jlj: I know they don't need lame
<zul> jdub: heh
<jdub> zul: see google images ;)
<zul> the the waugh conspiracy
<thully> gstreamer0.8-lame is for soung juicer 
<tseng> yes i understand you issue completely
<tseng> you dont seem to understand mine
<zul> whoa scarey looks like he is hepped up on somethig
<jlj> thully: then which packages were you referring to in your email by "The Ubuntu packages on the website needed some gstreamer packages, not included in a standard Ubuntu install, which these packages don't have as depends."
<ogra> thully: we discussed it in -motu with you and gave you instruction what to do, why do you start the discussion over again ?
<thully> BTW, what do you have to install exactly for the PyMusique packages - I had trouble and just ended up installing all gstreamer plugins and everything .
<tseng> the howto he posted has little to do with real debian/ubuntu development, sadly
<tseng> argh...
<thully> sorry - I missed whatyoumentioned about LAME over there and saw somebody talking about it here
<tseng> about you building your own packages from source..
<tseng> unless you are working on a package from ubuntu, thats off topic for here
<tseng> read the deps in INSTALL or README
<thully> OK - This should be discussed in MOTU - but someone else started discussing it in here and in all the discussion I missed what was said in motu
<Mithrandir> Kamion: please prod me when you're around next time, I have a bunch of issues which you may or may not be aware of.
<tseng> at this point the discussion is over. post the source packages on MOTUTodo. thanks
<zul> thats cool my usb crappy camera just works
<tritium> zul, heh :)
<ogra> zul: bah, get a new one
<ogra> how boring
<ogra> ;)
<zul> got no money
<zenwhen> every camera i have plugged into my computer running ubuntu has just worked
<zenwhen> its pretty awesome
<zenwhen> even horrible awful cheap ones
<robtaylor> jdub: so whats happeing with esd/polypaudio now? is polyp in or out?
<ogra> esd
<robtaylor> ok, just wondering as esd still runs polyp on my hoary box :/
<ogra> yup, thats a packaging prob
<robtaylor> righty :)
<ogra> will get covered in the upgrade notes i guess
<jdub> robtaylor: install esound
<robtaylor> jdub: installed, thanks :)
<zul> jdub: http://zulinux.homelinux.net/pics
<zenwhen> so its ok to remove all the polyp stuff?
<robtaylor> jdub: just working on the esdsink atm, hence the question :)
<jdub> zenwhen: yes
<ogra> zul: http://www.susus.de/dschunke/zweinasen.jpg
<ajmitch> afternoon
<zenwhen> oh wow
<zul> ogra: cool
<zenwhen> my desktop sounds are back
<ogra> zul: we just got that guy since three weeks http://www.susus.de/dschunke/katerpilderken/
<seb128> right
<seb128> time to sleep
<ogra> zul: and to compete with jdubs tiger, thats my beloved fred: http://www.susus.de/dschunke/allerlei/herrf.jpg
<ogra> :)
<zul> ogra: guinea pigs are cooler though :)
<ogra> you dont need to walk them, ut they tend to get fat ;)
<ogra> but even
<ajmitch> heh
<zul> ours can run from the basement of the house to the cage..but anyways
* ogra thinks he should donate a keyboard to the cage outfit
<zul> must go watch curling
<ogra> bob2: ping
<bob2> pong
<ogra> hey, i was at the docteam meeting yesterday...
<ogra> they have adopted the ubuntuguide for hoary :/
<jdub> ogra: just committed your hackergotchi, will have to wait for elmo to sync tho.
<jdub> ogra: that's bad?
<bob2> it has some dodgy stuff in it
<ogra> bon2 since you are one of the most active supporters i suggested you probably should review the docs too if you like
<ajmitch> jdub: I've made a hackergotchi for myself, now I just need to write a decent blog :)
<ogra> jdub: thanks
<tseng> jdub: my blog is ready for you too, if you are into planet admin
<tseng> jdub: tseng.ath.cx/log
<ogra> jdub: this guide needs a heavy review, and i wouldnt recommend it to anyone unexperienced
<ogra> jdub: but its a nice piece for advanced users once the errors are fixed
<ogra> (i.e. it tells you to add a link in /dev to get your palm working etc...)
<dholbach> jdub's round robin algorithm (concerning talking) seems to have gone haywire 
<dholbach> :-)
<dholbach> too many people :)
<jdub> tseng: already added, but not yet synced
<tseng> ah, thanks
<tseng> i just added the hackergotchi
<jdub> oh, url?
<tseng> http://tseng.ath.cx/images/hackergotchi.png
<jdub> ok, that'll be in the next sync too
<jdub> oops
<dholbach> good night everyone
<tseng> bye dholbach 
<dholbach> bye tseng
<jdub> um
<jdub> $ apt-cache rdepends gtk-smooth-themes
<jdub> gtk-smooth-themes
<jdub> Reverse Depends:
<jdub>   winetools
<jdub> ^ wtf?
<jdub> weird
<ogra> jdub: huh ?
<ogra> jdub: winetools is not even in
<jdub> from scott's repo
<ogra> ah
<ogra> so will we see it in main for hoary ? mark seems to want it...
<jdub> not main
<ogra> hm
<ogra> but universe ?
<tritium> ogra, I just tried winetools tonight.  It appears to be failing, perhaps due to this: http://linux.slashdot.org/article.pl?sid=05/02/17/1318212&tid=125&tid=109&tid=106
<ogra> OUCH
<ogra> !
<tritium> I'll try to confirm that is in fact the real cause.
<tritium> ogra, sorry, that must not have been the cause.  It's able to get downloads after all.  My bad.
<ogra> tritium: ok
<tritium> ogra, jdub sorry for the false-alarm 
* ogra will try to get some windows software to test the stuff himself
<ogra> jdub: btw, has your cat a name, its cute
<ogra> (even if the nose looks rather doggy)
<ogra> night all
<tseng> bye ogra 
<Amaranth> does anyone here know if gimpnet got hit by a botnet earlier today?
<zul> im so going to go see that movie
<mdz> zul: what movie?
<zul> mdz: hitchhikers guide to the galaxy
<zenrox> zul thats an awsome movie (i have the radio programs 
<robertj> mdz: hoary's connect to server problems turned out to be a Gnome problem
<fabbione> morning
<dilinger> hello
<fabbione> hey dilinger 
<zenrox> new drivers from nvidia rock
<zenrox> my x loads faster
<zenrox> 1.0-7176
<mvo> morning fabbione 
<fabbione> hey Mvo :)
* OddAbe19 is away: Gone... Like the French in a battle.
<toresbe> hahaha
<froud> mvo: morning
<froud> mvo: my repos access for update-manager is now working. ;-)
<froud> mvo: do you have a repos for synaptic or should I just use https://oops.kerneljanitors.org/repos/synaptic/trunk/help/C/
<froud> mvo: where is the repos for kynaptic (kubuntu)?
<mvo> froud: morning
<mvo> froud: for synaptic, use the oops repo
<mvo> kynaptic is https://oops.kerneljanitors.org/repos/synaptic/branches/kynaptic
<mvo> froud: I'm not sure if it is worth documenting kynaptic yet, IMO it's not quite there yet
<froud> mvo: ok thanks
<froud> mvo: can you mail me a list of what you see wrong in synaptic manual?
<froud> would save me time in updating it
<mvo> froud: I need to have a look again, but the low hanging fruits are the missing "supported icon" (see Help/Icon Legend) and something about authentication (what it is, what the warnings mean)
<froud> mvo: ok
<dilinger> ah, just the person i was looking for
<pitti> Morning
<dholbach> me?
<dholbach> ah ok
<pitti> Hi dholbach 
<dholbach> hi pitti
<dilinger> pitti: good morning
<dholbach> hi dilinger 
<dholbach> good moooooooorning
<dilinger> dholbach: hello
<dilinger> pitti: what's the url for that CAN page you have?
<dholbach> pitti: have the burnt DVDs
<mvo> hi dholbach 
<dholbach> pitti: will take them to the post office later
<dholbach> hellas mvo
<mvo> morning pitti 
<pitti> dilinger: http://people.ubuntu.com/~pitti/ubuntu-cve.html
<dilinger> thanks
<fabbione> hey pitti
<fabbione> pitti: i am still waiting a mail from you about all the stuff for the kernel
<fabbione> specially CAN-2005-0204...
<fabbione> i must change my signature file one day....
<fabbione> "if CAN were dildos, i would be goatse..."
<dholbach> HAHAHA
<fabbione> "if CAN were dildos, i would at least get some sex...."
<fabbione> or on these lines :)
<dholbach> fabbione: you're soooooooo funny :-)
* fabbione has to keep himself quite in here to look "professional"
<dholbach> you do... no doubt about that
<pitti> amu: ping
<amu> pitti: pong
<fabbione> amu: RUN RUN RUN!
<fabbione> he will hunt you down!
<amu> fabbione: nono pitti is a nice guy he'll never do something bad :P
<fabbione> yeah right!
<pitti> fabbione: oh, just ppc issues this time, no security :-)
<fabbione> ehhee
<amu> btw. g'morning 
<dholbach> good morning, d3vic3!
<d3vic3> morning 
<pitti> daniels: hey
<pitti> daniels: do you still have this UseFWPLL patched  radeon driver for X.org 6.8.2?
<mvo> pitti: daniels is on vacation I think
<pitti> oh
<daniels> just took today as a non-work day as it's a public holiday here
<daniels> did lots of shopping
<daniels> basically bought a kitchen
<daniels> i took the fwpll stuff out, we have a better solution in now
<daniels> it should just work out of the box in all situations in hoary
<pitti> daniels: it doesn't
<daniels> ah cool :)
<daniels> could you please email xorg@lists.fd.o with your Xorg.0.log, xorg.conf, and a full description of the problem?
<pitti> daniels: maybe no patch is required any more, maybe there is a magical option ppc users need to turn on in xorg.conf
<daniels> oh, right
<daniels> hold on a sec, there was one
<daniels> try Option "LVDSProbePLL"
<amu> in the device-section i guess? 
<daniels> yeah
<pitti> daniels: does not work for me
<daniels> hmm
<daniels> ok, email xorg@lists.freedesktop.org
<pitti> I do
<daniels> and say that you're using the latest Ubuntu packages, which has the last patch benh gave me (about two weeks ago or something), and that you tried with and without LVDSProbePLL
<amu> pitti: just found http://lists.freedesktop.org/pipermail/xorg/2004-December/005259.html
<amu> daniels: could that work? ^^
<daniels> amu: shouldn't make any difference, really
<amu> daniels: but i need also your special patched driver version?, or it works out of the box with last xorg packages? 
<daniels> amu: hoary packages are file
<daniels> fine, even
<amu> daniels: ok, thx
<pitti_> Moin seb128 
<seb128> morning
<dholbach> hi seb128 
<Mithrandir> Kamion: I have a few gripes about the preview installer -- not sure if those are fixed later.
<Mithrandir> Kamion: first, when selecting "norwegian (bokmal)" as my language, the keyboard chooser suggests I have a Macedonian keyboard.
<Mithrandir> it also seems like the fact that I chose norwegian wasn't properly propagated, as it installed language-pack-en and generated a lot of en_* locales.
<Nafallo> for swedish it generated ar, de, en, es and what else is there ;-).
<Mithrandir> Kamion: it also sets no_NO, not nb_NO.  no_NO is deprecated and should go away; nb_NO is the way forward.
<Mithrandir> also, language-pack doesn't respect user changes.  I removed all the en_* but en_US, but they were readded.
<Simira> when is the last chance of adding translations to hoary?
<Simira> Kamion: and where can I get the .po-files for Ubuntu installer?
<Kamion> Simira: http://people.ubuntu.com/~cjwatson/installer-po/
<Kamion> Mithrandir: the keyboard chooser defaults are set by console-data, I think
<Kamion> Mithrandir: language-pack-en is deliberately installed, by request of mdz; see #7103
<Kamion> Mithrandir: no_NO> erm, ok, localechooser bug I guess ...
<Mithrandir> Kamion: still, l-p-e shouldn't override my changes to locale.gen
<Kamion> Mithrandir: sure, blame pitti :)
<Mithrandir> pitti: blame you! :)
<pitti> Mithrandir: what does it override?
<Mithrandir> pitti: I removed en_* (except for en_US) from /etc/locale.gen
<pitti> Mithrandir: the postinst should add all the en_* locales, but not remove yours
<Kamion> pitti: if you remove en_WHATEVER from /etc/locale.gen, it adds them back in on upgrade, apparently
<Mithrandir> they were readded.
<pitti> oh, yes
<Mithrandir> I'm sorry, but I _really_ don't care about en_HK and similar.
<pitti> Mithrandir: maybe this shouldn't be done on upgrades then?
<Mithrandir> on a box which has a single user (me)
<Kamion> thom,elmo: around? need somebody with root on little semi-urgently
<fabbione> i still blame gtk :-)
<Mithrandir> pitti: I'd be incluned to agree.
<Mithrandir> inclined, even
<pitti> Kamion: ^ you too?
<fabbione> Kamion: do you need an exploit to gain root on little? ;)
<Kamion> thom,elmo: rm -rf /srv/cdimage.no-name-yet.com/scratch/ubuntu/tmp/hoary-{amd64,i386}/CD1/{bin,disctree,programs} please
<Simira> Kamion: thanks
<Kamion> pitti: yeah
<pitti> Mithrandir: however, this has to wait a bit until I upload new base packages
<Mithrandir> pitti: sure.
* fabbione -> food
<Mithrandir> pitti: it's just annoying to sit around and wait for ten locales to be generated on a pii-300
* pitti curses at getpwnam()
<thom> Kamion: one sec
<thom> Kamion: done
<Kamion> ta
<thom> Kamion: good to see you on saturday; safe trip home?
<daniels> Kamion: oh, you were in Canadia too/
<Kamion> thom: yep, got home a bit later than intended (stupidly slow train) but otherwise fine
<Kamion> daniels: mm?
<thom> Kamion: oh, you wound up on the stopper of destiny? :/
<daniels> Kamion: cool
<Kamion> daniels: no, I wasn't
<daniels> Kamion: oh, nevermind
<Kamion> thom: two hours rather than three, which it can be at worst, but still ...
<daniels> Kamion: yow, that's rather horrid
<thom> yeah, bit unnecesary
<Kamion> daniels: if you mean the release update, no, I just checked in remotely
<daniels> Kamion: right
<Kamion> yay, dvd burner
<Mithrandir> fabbione: just close 2502 now?
<fabbione> Mithrandir: checking now
<sivang> Hi all
<fabbione> Mithrandir: yes we can close it imho
<pitti> Hi sivang 
<sivang> pitti: Hi martin, what's up?
<pitti> sivang: I'm debugging ntpd
<pitti> sivang: this silly thing works everytime but on bootup
<pitti> sivang: so I have to reboot very often for debugging *grumpf*
<Mithrandir> fabbione: ok, closing.
<pitti> sivang: getpwnam() is playing bad with me
<Mithrandir> seb128: any idea how to fix 6618 (except the "make thunderbird quit faster")?
<Kamion> ow, bitten by hardware
<seb128> Mithrandir: nop, evolution does the same ...
* Kamion attempts to type while avoiding using his left middle finger
<thom> yay, it's not just me who gets bled on by stuff
<pitti> Kamion: what's wrong with your finger? Did your cat like it too much? 
<Kamion> 11:37 < Kamion> ow, bitten by hardware
* dilinger wonders what thom is doing that gets him bled on by stuff
<Kamion> no cat; we have a snake, but not the biting kind
<pitti> yeah, the unix stuff - "small sharp tools" :-)
<thom> dilinger: my fingers managed to reverse that sentence for me
<ajmitch> Kamion: I can understand, except it's my index finger that I sliced :)
<sivang> pitti: oh that's bad :-/
<sivang> pitti: anyway, would you like to upload my packages today?
<sivang> hmm, crappy net access? ;-)
<fabbione> Kamion: are you updating the live and cd images?
<Kamion> fabbione: yes
<Kamion> hm, why might my BIOS hang at IDE detection now that I've plugged in a DVD drive?
<fabbione> Kamion: wrong master/slave/cs jumper?
<sivang> pitti: wb :)
<sivang> pitti: crappy network?
<Kamion> fabbione: hm, could be
<pitti> sivang: no, frequent reboots for debugging ntp-server
* fabbione burns install DVD
<sivang> pitti: ah I see. ok, lemme know when you have time to upload the modified g-c-m
<koke> is Michiel Sikkes here? I don't know his nick
<amu> lamont: around? 
<dholbach> koke: mitario
<tp> just a quick question before I post a bug. in /etc/fonts/local.conf .. autohint is now enabled and the panel won't switch it off. Is this correct behaviour (if I uncomment autohint, I return to warty style / autohint disabled behaviour) 
<Treenaks> isn't the autohinter enabled/disabled by the "fonts" config panel?
<tp> it doesn't seem to be
<tp> with auto hint enabled in local.conf, the fonts are fuzzy regardles of hinting
<Treenaks> hm, I'll leave it disabled then
<tp> with autohint disabled, I can get warty style no-autohinting (verticals are clean)
<Treenaks> I don't want fuzzy fonts
<tp> would you like me to post anything?
<jdub> koke: mitario when he's on
<koke> dholbach, jdub thanks :)
<fabbione> jdub: btw. i managed to get gst-launch to work
<fabbione> jdub: but flumotion still barfs
<jdub> fabbione: did you use extra parameters for v4lsrc with your gst-launch line?
<tp> Treenaks: thanks, leave a message if you'd like me to post anything
<fabbione> jdub: no. only gst-launch-0.8 v4lsrc ! ximagesink or something on that line
<fabbione> but it was only one parameter
<jdub> i mean directly after v4lsrc
<fabbione> nope
<fabbione> nothing more than that
<jdub> what changes did you make to have it working?
<fabbione> i solved the 2 frames thingy with a driver setting
<fabbione> it is a specific gst bug that can be workarounded
<fabbione> at least according to the driver documentation
<doko> fabbione: http://listserv.isdn4linux.de/pipermail/isdn4linux/2005-March/001292.html
<Kamion> fabbione: thanks, that was it
<fabbione> Kamion: no problem.. i did nothing :)
<fabbione> doko: reading now
<fabbione> doko: that still doesn't fix the segfault on the avfritz thingy
<fabbione> and in any case it is too late for reinclusion
<doko> the patch that I attached to the bug report had the avmfritz driver disabled.
<fabbione> doko: what was the bug number again?
<sivang> pitti: back?
<pitti> sivang: yes, package build is nearly finished. I need (at least) one further reboot for testing
<sivang> pitti: ok, have you gotten my msg about g-c-m?
<pitti> sivang: I tell you when I'm ready :-)
<sivang> pitti:ok, thx :)  There's also something strange with postgres going on over my system, it won't never stop nicely when rebooting, is this known?
<mvo> doko: I find the mail scary. I mean, the kernel changes a API in the middle of a stable series 
<pitti> sivang: no, please file a bug
<sivang> pitti: ok, is there anythinig to do to retrive logs and backtrac information etc?
<pitti> sivang: output messages, to start with
<Kamion> Mithrandir: did you ask lamont to fix PaS for openoffice.org-amd64?
<Kamion> or actually elmo, I guess
<sivang> pitti: ok, apparently there are none, but I should boot without "quiet" and then recheck.
<Mithrandir> Kamion: it's not PaS-ed
<doko> fabbione: #5193
<Kamion> Mithrandir: it hasn't built on ia64 ...
* pitti reboots again *sigh*
<Mithrandir> : tfheen@shonap ~ > wget -qO - 'http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup' | grep openoffice.org-amd64
<Mithrandir> : tfheen@shonap ~ >
* sivang --> reboot
<Kamion> fabbione: new install CDs up, live CDs building
* fabbione rsync
<Kamion> live bloated a bit, may be broken
<fabbione> hmmm
<fabbione> well i will start with the install ;)
<fabbione> but i need to wait a bit later to test the dvd install
<fabbione> i can't trash the actual installation on that machine
<fabbione> not yet at least
<fabbione> i have to take a full backup.. just in case
<Kamion> hm, I should be able to try out the Linux Magazine DVD now
<fabbione> #define ARCHi386  1
<fabbione> is this a typo in README.diskdefines  ?
<fabbione> (from the DVD)
<Kamion> probably, I'll check
<fabbione> there is another line right on top that define the same...
<Kamion> well, appears to be deliberate
<fabbione> or almost
<fabbione> ok
<d3vic3> Kamion, can i send you a diff and dsc file, so you can upload on my behalf ?
<Kamion> what's that file actually used for, if anything?
<Kamion> d3vic3: what package?
<d3vic3> libxine1
<Kamion> mm, would prefer someone who actually knows about the package ;)
<fabbione> d3vic3: send it here if Kamion is busy
<fabbione> ok send it to me
<fabbione> fabbione@u.c 
<Kamion> thanks fabio
<fabbione> np
<Kamion> fabbione: no, ARCHi386 appears to be deliberate; README.html.in uses that
<fabbione> thanks
<Kamion> dunno why we bother actually shipping that file though, it's weird
<fabbione> probably for the autocd detection thingy?
<Kamion> nah, that generally uses other files, like .disk/info, dists/, or the ubuntu symlink
<fabbione> automount -> detect -> show the nice message "Hey your cdrom is choaking an Ubuntu Hoary cd! wanna upgrade?"
* Kamion watches the Linux Magazine DVD merrily copying all of main to the hard disk, as predicted
<Kamion> yeah, nothing like that uses README.diskdefines as far as I know
<pitti> sivang: ntp works again, now let's tackle g-c-m
<d3vic3> fabbione, incomming 
<pitti> sivang: patch?
<fabbione> d3vic3: ok
<pitti> smurfix: here?
<fabbione> d3vic3: is that correct that you only added an entry in the changelog?
<d3vic3> yup 
<d3vic3> force to rebuild 
<fabbione> d3vic3: yes but that is not enough generally
<fabbione> you should be sure (via debian/control) that the package cannot build with the old version of libflac
<fabbione> otherwise you only partially solve the problem
<d3vic3> I made sure 
<d3vic3> fabbione, tested it also
<fabbione> d3vic3: you need to modify debian/control
<fabbione> to ensure that it gets the right version of libflac
<fabbione> ah pants off
<egli> mdz: re bug 4354: you say that you need more info and you cannot reproduce the bug.
<egli> mdz: the bug report is for warty
<egli> mdz: I'll have to see if I can get a hoary machine to try to reproduce the problem
<pitti> sivang: ping
<fabbione> d3vic3: ok.. never mind..
<d3vic3> fabbione, ??? 
<fabbione> d3vic3: it's ok..
<d3vic3> explain please, in case I'm missing something 
<fabbione> no it's me
<fabbione> i missed something
<fabbione> anyway.. uploaded
<fabbione> Kamion: does the DVD come with combo live/install?
<Kamion> fabbione: yes
<Kamion> type 'live' to boot in live mode
* fabbione adds the extra test to the list
<kagou> hi
<kagou> where can i put options for modules ? I don't have a /etc/modules.conf .... I want to add "options ide-cd dma=1"
<Treenaks> kagou: use /etc/hdparm.conf for setting DMA on IDE devices
<kagou> Treenaks, i have "hdc=noprobe hdc=cdrom" on kernel parameters (if not hal crash)
<Treenaks> is it such a strange config?
<kagou> so i don't have possibility to enable DMA for my dvdrw (hdc)
<kagou> it's a notebook
<Treenaks> hdparm -d1 /dev/hdc
<Treenaks> try that
<kagou> make's an error
<Treenaks> hm
<Kamion> what error?
<kagou> my notebook -> http://forum.hardware.fr/hardwarefr/MiniPCPortablesPDA/sujet-1459-1.htm
<kagou> the error is :
<kagou> "Operation not permitted"
<kagou> i'v read here https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75387 that may be i can pass "dma=1" to the ide-cd module
<kagou> i 'v also tried to load via82cxxx before ide-cd module
<sivang> pitti: pong
<dholbach> see you later
<herzi> is matthias klose around here? what's his nick?
<pitti> herzi: doko
<thom> doko
<herzi> doko: ping
<herzi> thanks guys
<jdub> yo herzi 
<herzi> yo jdub, what's up? i've been ill and busy the last weeks, i'd like to see you on tv :)
<jdub> heh
<d3vic3> O.o
<jdub> so first you should mail the starlight foundation
<jdub> and for ONE MILLION DOLLARS i will appear for you on TV
<herzi> jdub: okay, i'll wait for guadec then :P
<Treenaks> jdub: and specific kind of dollar?
<Treenaks> jdub: and=any
* Amaranth still hasn't seen jdub's TV show ;)
<mvo> jdub: are there plans to update the .desktop files of gnome-app-install? I have a branch of ross repository that contains some i18n updates and it would be nice if they could be included in a upload (along with desktop file updates)
<jdub> mvo: yes
<jdub> mvo: you're welcome to do an upload straight away
<jdub> mvo: ross is away
<doko> herzi: pong
<herzi> doko: just taking a look at the gdb stuff
<mvo> jdub: can we talk in private what other updates are needed to the package?
<jdub> ok
<herzi> a ppc package would have been useful for me
<mjg59> thom: Ping?
<thom> mjg59: ack
<mjg59> thom: Can you take a look at http://www.codon.org.uk/~mjg59/tmp/gdm-signal.tar.gz ?
<mjg59> We need that in order to allow sleep buttons that send keycodes to work
<thom> mjg59: ok, will do
<thom> mjg59: what's the go with radeontool for hoary? can't remember what needs to happen, if anything
<mjg59> thom: I haven't heard back from enough testers.
<zul> morning
<mjg59> And what I have heard back is somewhat contradictory
<herzi> svenl: ping
<svenl> herzi: pong.
<herzi> svenl: what's the status of ubuntu on pegasos?
<svenl> herzi: it should work, provided the patches go int.
<svenl> herzi: it will need an OF upgrade i am working on (only yaboot-from-CD is still broken), X configuration will be fixed provided the two patches in 7144 are merged and not deemed unimportant.
<svenl> herzi: yaboot-installer will need fixing and the new OF upload, but Kamion said he would work on that.
<svenl> herzi: and the 2.6.10 kernel of ubuntu lacks the gigabit ethernet driver patch.
<svenl> herzi: as a workaround to missing yaboot support in pegasos-OF, the mkvmlinuz workaround could be added to the kernel, there was no great interest on that though, altough Kamion said he would like to make it happen.
<svenl> herzi: the rest is user testing and things i haven't really looked in.
<herzi> did you get the amiga-support into yaboot yet?
<herzi> i heard upstream wasn't keen about them
<svenl> herzi: yep.
<svenl> herzi: after 6 month of fighting, it is finally in, there may be other bugs though, like yaboot thinking that a CD iso should have one partition on it i am still working on.
<svenl> herzi: yaboot from netboot and yaboot from disk on yaboot-supported-filesystem works.
<herzi> .oO(partitioned cds....)
<Amaranth> so, what's the deal with grumpy? someone is telling it it'll be like debian's sid
<svenl> herzi: the problem is in the pegasos-of code ignoring the partition/filesystem detection code when called from the client-interface which yaboot uses, but i am working on that.
<Amaranth> is that true?
<herzi> Amaranth: grumpy will the the post-hoary
<herzi> so it's more what "jackie" (iirc) is for debian
<herzi> jessie
<pitti> what's jessie?
<Treenaks> herzi: etch you mean (post-sarge)
<Amaranth> Ok, so the talk about it being like sid and "bendy" being the next release isn't true?
<svenl> herzi: no, it detects a iso filesystem, and then declares a partition table with one partition of empty size, instead of returning NULL, so yaboot passes bullshit to the underlyig OF. bullshit which apple-of knows how to handle.
<herzi> k
<herzi> pitti: jessie is post-sarge
* pitti thought it was "Etch"
<herzi> k
<Mithrandir> pitti: it is etch.
* herzi goes and kicks his v-man
<Treenaks> herzi: it's etch, according to the "nybbles from the d-a team"
<Treenaks> d-r team?
<Treenaks> v-man?
<herzi> http://dict.leo.org/?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&relink=on&sectHdr=on&spellToler=std&search=v-mann
<Treenaks> ah, your informant :)
<pitti> thom: I just cleaned the mozilla-thunderbird-locale-* packages, shall I do the mozilla-locale-* stuff as well?
<pitti> thom: (the bugs are currently yours)
<pitti> elmo: please remove the following source packages from the archive: mozilla-firefox-locale-{da,fr,sv,tr} (superseded by m-f-l-all)
<Kamion> Amaranth: current favourite name for the next release is "breezy", but it's not final yet
<Amaranth> Kamion: So the name hasn't been picked but there won't be a "grumpy" too, right?
<Kamion> Amaranth: grumpy was originally intended to be the release after hoary, but that's no longer going to be the case; it's likely to end up being some kind of autobuilt crack-of-the-day-from-upstream faux-distribution
<Amaranth> like sid
<Kamion> no, not like sid
<Kamion> sid is still maintained by means of source uploads from developers
<Kamion> grumpy will be automatic from upstream CVS repositories and the like, if it ever gets off the ground
<Kamion> rather more like a sort of automatically-maintained experimental
<Kamion> in that you'd be extremely unlikely to want to run grumpy as a whole, but perhaps individual packages from there
<Simira> Kamion: when is string freeze for hoary? 
<pitti> mvo: ping
<sivang> seb128: hey Seb, I'd need to ask you about adding trasnlation support to some code I wrote
<seb128> hi
<seb128> use gettext
<Kamion> Simira: I don't know, sorry
<froud-work> sivang: speak to trickie he is using gettext and pot/po etc for ubuntu-doc
<froud-work> sivang: he can probably help you with the toolchain required
<sivang> seb128: so just process my code with gettext to update the POT file for g-c-m for example?
<seb128> make update-po in po/
<sivang> seb128: ok, btw, the source pacakges are pre translation strip right?
<seb128> ?
<sivang> seb128: (that is , they containt all the translation data)
<seb128> the source is the upstream source
<seb128> sure
<sivang> seb128: how does translation data works in relation with the source packages?
<seb128> I don't get the question
<sivang> seb128: so pitti's scripts eat sources pkgs and strip the translation data from them?
<pitti> sivang: no
<seb128> no, that's a build time stuff
<sivang> pitti: ok
<pitti> sivang: pkgstriptranslations strips mo files from debs
<sivang> pitti: eh
<pitti> sivang: the source pacakges are not altered
<sivang> pitti: mo files are created from the binaries?
<pitti> sivang: from po files, yes
<sivang> pitti: ok,was just interested how we handle the traslations from the source pkgs enter the buildd
<sivang> seb128: do I only have to do _("string") to have my strings added ?
<sivang> seb128: (before running gettext in the /po folder)
<seb128> you are writting a new program ?
<seb128> or changing one ?
<sivang> seb128: changing
<sivang> seb128: g-c-m
<seb128> ok, so you can use _()
<sivang> seb128: cool, thanks!
<seb128> and make update-po should work in po/
<pitti> sivang: you should probably also add the new string to seb's metabug (#???) regarding translations
<sivang> pitti, seb128 : what's that meta bug? ;-)
<seb128> that's as quick to search for you as for me
<seb128> don't be that lazy 
<seb128> search for bug with translation in the title in bugzilla
<seb128> :)
<sivang> seb128: I will search :) just thought there was the number at hand :-))
<lupusBE> seb128, will I have to wait long for hald 0.5 and dbus 0.30 :P I want to do some hacking on g-v-m
<seb128> that's a question for pitti
<seb128> I don't maintain hal or dbus
<seb128> but that's probably not for hoary
<pitti> lupusBE: not for Hoary
<pitti> lupusBE: the new hal is sexy, but it has big architectural changes
<pitti> lupusBE: I'll package it around the start of May
<lupusBE> I wonder if making an app gtk only will make it use less memory
<herzi> lupusBE: usually that's not the case
<herzi> because i need to duplicate code that can be shared in memory in a library
<lupusBE> I find it mysterious that g-v-m needs 6mb of resident memory
<fabbione> seb128: my little french friend.. YOU ROCK!
<Mithrandir> fabbione: Iz not GTK bug?
<seb128> fabbione: thanks, but I've done something special ? 
<fabbione> Mithrandir: well he gave me some good hints to unfucking the sparc buildd from the GTK bugin3zz :-)
<lamont> Mithrandir: oo.o-amd64 is certainly PaS: amd64
<lamont> and it's an elmo fix
<Mithrandir> lamont: not on cvs.d.o
<lamont> right
<lamont> hence elmo-fix
<Mithrandir> elmo: could you please un-pas ooo-amd64?  It should build on ia64 as well.
<lamont> ours is derived from theirs
<Mithrandir> I thought we synced stuff back?
<travail101> how's linux-wlan-ng integration coming along? =P
<Kamion> travail101: it's been added to ship
<Kamion> I've just asked about the live seed too
<travail101> :-D
<travail101> I'm looking forward to having an Ubuntu LiveCD with my wireless supported =D
<travail101> what C(XX)FLAGS does Ubuntu use?
<tseng> mtune=pentium4 -mcpu=i486 -O2 or so
<travail101> wow, what's mtune, I've never heard of that flag
<tseng> its in man/info gcc
<travail101> ok
<travail101> wait... it wouldn't have any advatage over -march when using on a single system would it?
<tseng> no, march uses instruction set specific tuning
<tseng> which is potentially better than tuning, which is still portable
<travail101> so I should stick with march for my own stuff
<travail101> and mtune for making generic packages for friends or whatever
<tseng> you should really not be too worried about it, imo
<travail101> tseng, why's that?
<tseng> because it doesnt matter that much in the scheme of things
<travail101> I hear a lot of talk about whether or not all these aggresive SFLAGS actually do any good in practice...
<travail101> CFLAGS*
<herzi> travail101: with modern cpus you don't get that much benefit
<tseng> some packages certainly benefit, but most by a few fractions of a second
<tseng> at which point, who cares
<tseng> ubuntu careful selected sane defaults for you
<travail101> (i don't use Ubuntu... :-|)
<tseng> then you are more off topic than I thought.
<travail101> I'm trying to learn a little about CFLAGS and i hear from different places that Ubuntu has a pretty responsive desktop
<travail101> and I know that technically if you want full optimization you need to do a lot of homework and tweak the flags spedifically for each package
<tseng> that legend comes from LDFLAGS="-Wl,-O1"
<tseng> well not legend..
<travail101> but I'd like to find the best default, for packages that don't need to be portable, just for use on my system
<tseng> but come back and see us again when you haev ubuntu packaging issues please
<tseng> we arent here to help you optimize your gentoo or whatever
<travail101> well thanx anyway
<Treenaks> wow, #gentoo :P
<lamont> elmo about?  thom?
<travail101> Treenaks, they don't know everything you know
<Treenaks> travail101: I don't know everything, but pissing contests about CFLAGS are really gentoo-ish in my eyes :)
<travail101> I'm not an elitist that stays in the realm of my own Distro/favorite whatever, I like to gather the ideas/knowledge and experience of the entire OpenSource community
<lamont> travail101: ubuntu uses -march=i486 -mcpu=pentium4 -pipe
<lamont> it's the -pipe that makes things run so fast. :-)
<fabbione> ahhaha
* lamont chuckles
* travail101 feels a bit awkward... 
<lamont> travail101: -pipe just tells the compiler to use a pipe instead of temp files for passing things between stages.
<lamont> which is to say, it doesn't do squat for runtime performance
<travail101> that's what I thought
<pitti> jbailey: here?
<travail101> it helps with compile time right?
<Treenaks> lamont: why isn't this default then?
<jbailey> pitti: Yup!
<Kamion> Treenaks: uses more memory
<lamont> Treenaks: history? dunno
<lamont> -pipe means that you get a whole bunch of components (stages) running at the same time - this can slow down compiles on single processor machines
<Treenaks> Kamion: true, but it's also faster if you have it, right?
<travail101> lamont, =P maybe i should remove -pipe then
<Treenaks> lamont: then uniprocessor machines should be outlawed :P
<lamont> which reminds me...  maybe I should turn of -pipe on the UP ia64 build machines...
<Mitario> mvo, hey, you here?
<mvo> Mitario: yes
<Mitario> mvo, everything allright? :)
<mvo> Mitario: yeah, pretty good here :)
<Mitario> ok nice :)
<Mitario> i just did a little mockup of some idea i have for synaptic
<Mitario> (UI stuff)
<travail101> mind if I ask one more non ubuntu question?
<travail101> or would you rather I just leave?
<mvo> Mitario: cool, URL?
<Mitario> mvo, geeklog.eyesopened.nl/wp-content/images/synaptic-mockup.png
<Mitario> woops that - should be a ' '
<mvo> for the download progress? looks nice :)
<Mitario> yeah for the download progress :)
<mvo> not for hoary (and synaptic-0.56) though :)
<Mitario> no i know hoary+1 :)
<Mitario> I'll try and do some patches in some time then :) good oppertunity to learn some C++
* Mitario is a language whoe the last few weeks
<lamont> travail101: as long as it's development related, fire away
<travail101> it's kernel related
<travail101> patchsets and so on
<lamont> prolly devel related, then...
<fabbione> Kamion: tomorrow we will upload a new kernel and we need to bump the ABI
<fabbione> Kamion: that will happen around 14:00 UTC (the upload)
<lamont> fabbione: my mirror hates you
<fabbione> lamont: give him a hug from me ;)
<mvo> Mitario: hehe :) go for it if you want. but chances are there that more parts of synaptic will move into python. I hacked some code in python-apt for a fetcher interface. that means that we can move to a python implementation of downloading and installing in u-m and g-a-i (and we will not need synaptic as backend anymore)
* mvo wonders if that sentence is actually understanable given it's grammar
<Mitario> mvo, hehe, well thats great!
<Mitario> this way we could have a cool native python progress thingy in u-m and g-a-i
<Mitario> mvo, is it in tla somewhere? I'd like to try it :)
<mvo> Mitario: urm, err ... /me checks
<Mitario> but anyways, remember that synaptic won't go away :) so it would be a nice UI thingy anyways
<Mithrandir> lamont: does ia32-libs-openoffice.org exist on ia64?
<mvo> Mitario: right :) my python work is in michael.vogt@ubuntu.com--2005/python-apt--mvo--0 (it needs "baz")
<lamont> libs/ia32-libs-openoffice.org_1ubuntu4: Installed by buildd+weddell [optional:out-of-date] 
<mvo> Mitario: it needs some more flesh, but the "update" method is implemented and doc/examples/action.py contains some example code
<lamont> Mithrandir: (that's a yes)
<Mithrandir> lamont: ok, thanks.
<Mithrandir> lamont: I'm writing a mail to James, since he doesn't seem to be around ATM.
<Mitario> mvo, very cool :)
* Mitario is going to try baz
<lamont> Mithrandir: yeah
<lamont> brb
<sivang> mvo: you're like writing python bindings for lipapt  so python programs could use it natively? :-)
* ogra sees a python synaptic version at the horizon
<jbailey> mjg59: Around?
<mjg59> jbailey: Ish, yeah
<mjg59> What's up?
<Kamion> fabbione: ok
<jbailey> mjg59: Would it be insane to do something where we look at a swap partition and if it has a suspend-to-disk image in it, we just automatically run mkswap?
<mjg59> jbailey: No, that's the right answer
<fabbione> Kamion: it would help if you will be around that time
<jbailey> mjg59: ISTM that if we get that far, the image is already useless.
<mjg59> If we get that far, the image is actively dangerous
<fabbione> Kamion: so that we can push/seed it as appropriate
<mvo> sivang: python-apt is available since a long time now. but it lacks importend bits that are needed if you want to use it as a "real" package manager. e.s. the interface to mark packages for install and the interface to fetch and install
<fabbione> daniels: ping?
<jbailey> mjg59: Lovely.  I'll retitle 5594 to be that, and deal with it.
<sivang> mvo: so you're finishing this work? coool
<mjg59> jbailey: The swsusp signature is well-defined - the script should just check for that, and mkswap the partition if it's there
<sivang> jbailey: hey jeff :)
<jbailey> Heya Sivan
<Kamion> fabbione: yes, should be
<mvo> ogra: could happen :) but I need to see if speed is acceptable. but it's not wasted work as u-m and g-a-i benefit
<ogra> mvo: i guess other (future) tools will too :)
<jbailey> mjg59: Great.  I'll tackle this one.  Thanks.
<mvo> ogra: it may well be that people will start playing with package-managment interfaces and come up with lot's of new ideas. it's pretty interessting
<ogra> yup :)
<ogra> sounds very promising
<jbailey> enrico: Ping?
<pitti> mvo: on warty->hoary upgrade, can we already use system upgrade hooks?
<dholbac1> seb128: i'll package gtkmm and bakery later
<dholbac1> seb128: but i can do bakery on my own... it's universe
<mvo> pitti: no, they depend on a running update-notifier
<pitti> mvo: but doesn't the upgrade install u-n?
<pitti> mvo: the problem is, on upgrading the user will lose all translations because langpacks aren't installed automatically
<pitti> mvo: the upgrade hook would be the perfect place to mark language-pack-$USERLANG as to-be-installed
<mvo> pitti: it does, but it won't be started automatically (because I know of no way to add it to the users session automatically). kde can do it btw with /usr/share/autostart (or something like that)
<pitti> mvo: ah, but it will be started when the user logs in the next time?
<mvo> pitti: we can use it I think (utf8migrator uses them too). but it's not perfect unfortunately
<pitti> mvo: after the upgrade, the user has to reboot anyway (new kernel, new gnome, shitload of other new stufff)
<mvo> pitti: no, as I said I know of no way to add it to the users session automatically. it needs to be started once and then saved with the session
<pitti> ah, I thought you meant the currently running session
<mvo> (started once by the user. new users will get it automatically in the default gnome-session)
<pitti> hmm
<pitti> but then this problem will persist forever
<pitti> mvo: no way to start it at least in the next login?
<ogra> pitti: lets patch gnome-session ;)
<mvo> pitti: I know of no way, any ideas seb128 :) ?
* pitti runs away, passing the torch to seb128
<ogra> hehe
<mvo> we are a bit late for that but I would do it if needed. it bugs me too :)
<pitti> mvo: is "please start u-m" already in the HoaryUpgradeNotes?
<enrico> jbailey: yes?
<pitti> mvo: better write this one thing into it rather than a long list of things to do in addition
<pitti> mvo: and the user will want u-n anyway :-)
<mvo> pitti: agreed
<jbailey> enrico: I was just digging through the meeting minutes, and I don't see where to actually send release note updates to... =)
<mvo> pitti: agreed again :)
<enrico> jbailey: ubuntu-doc@lists.ubuntu.com
<pitti> mvo: so apart from the starting problem, how much effort is it to add this install mark?
<jbailey> enrico: Thanks. =)
<enrico> jbailey: sorry about the missing info: we just gave it for granted that everyone knew the list address
<mvo> pitti: drop a file to /var/lib/update-notifier/user.d :)
<jbailey> enrico: No worries.  I keep finding new corners of this distro that I didn't know existed. =)
<enrico> (but at the same time, we are the first ones knowing to never give things for granted :)
<pitti> mvo: oh, empty...
<pitti> mvo: no system.d/ ?
<mvo> pitti: the format for the file is: http://www.ubuntulinux.org/wiki/InteractiveUpgradeHooks/view?searchterm=upgrade%20hooks
<jbailey> enrico: I'd almost love to assemble one day a big chart of all of Ubuntu, make it like the JDK charts that sun publishes.  It would be interesting to show just how big the scope is.
<mvo> pitti: if it's system-wide, why not use debconf?
<pitti> mvo: where?
<mvo> pitti: where?
<mvo> pitti: oh, where!
<pitti> hey, I asked first :-)
<mvo> EPARSER
<mvo> now I got it
<pitti> mvo: we have no packaage to put this into
<pitti> s/aa/a/
<mvo> pitti: the hooks have the same problem. you drop a file in that dir and the hook is displayed. but the file has to come from somewhere (it's not part of u-n itself)
<pitti> hmmm
* pitti feels the need for an ubuntu-upgrade package
<thom> pitti: please do (moz-locale packages)
<thom> lamont: ack?
<pitti> thom: ack
<thom> pitti: (and thanks)
<seb128> mvo, pitti: patches are welcome :p
* pitti anticipated this answer
<mvo> seb128: do you think it would be accepted upstream?
<lamont> thom: could I get blender build-deps in the chroot on concordia?
<seb128> mvo: not sure
<thom> lamont: by "the" i take it you mean hoary amd64?
<lamont> uh, yeah
<lamont> there's others? :-)
* lamont hangs his head.
<thom> dchroot -l
<thom> Available chroots: hoary [default] , warty, hoary-i386, hoary-clean, bazaar
<thom> ;-)
<lamont> yeah, knew that..
<lamont> .hrm.. actually, if you're gonna do the other thing, maybe hoary-i386 would be less of an impact on others...
<thom> i'm prolly not gonna do the other thing
<thom> you can send mail to admins about that
<lamont> yeah -figured that much
<lamont> lol
<fabbione> hey thom
<thom> :-)
* lamont makes a note to buy thom some asbestos pants
<fabbione> thom: can you please install mplayer build-dep on davis or any ppc chroot in there? even dedicated if you prefer (due to multiverse)
<thom> fabbione: meh
<thom> lamont: done
<fabbione> thom: any direction is fine for me
<fabbione> i don't care...
<lamont> thanks
<dholbac1> i'm packaging bakery2.3, which had the 3 binary packages libbakery-2.3-{common,dev,9}, now ABI broke and i'll have libbakery-2.3-{common,dev,12} around, do i have to Replace: or Conflicts: anything?
<GheRivero> res
* lamont ponders how to do what he needs to do on concordia
<fabbione> lamont: don't mess up concordia ! :)
<metallikop> jdub: are you around?
<lamont> fabbione: that's why I have to ponder
<lamont> fabbione: that was "the other thing" :-)
<fabbione> ehehhe
<lamont> doko around?
<lamont> nm
<dholbac1> bbl
<doko> lamont: yes
<lamont> thom: found a way.  thanks
<thom> fabbione: hoary-multiverse chroot on davis, mplayer build deps installing currently
<thully> I've got quite a few outstanding bugs with no comments from others, or at least no activity in a while.  What should I do with these?
<thom> thully: show patience
<thully> well - some have been around for months - I'm just a bit concerned that they somehow got "lost in the pile" as to speak
<seb128> that's a possibility
<seb128> you can send patches
<thully> I don't really know about GTK and the like, so that isn't really feasible - should I avoid reporting bugs if I can't fix them myself?
<seb128> thully: do you have any such bug assigned to me ?
<seb128> nop, reporting bug is nice
<thully> multiple ones
<seb128> if we feel than the bug has to be fixed quickly we do so
<thully> like 6 to you and another 6 to thom
<seb128> and we don't you just have to wait or to send a patch to help
<seb128> give me some URL here, I'll say why there is no reply
<thully> 6541
<thully> that's the bug #
<seb128> that's probably a dup
<lamont> thom: grumble.  spoke too soon. :-(
<seb128> there is some bugs open about network-admin issue, auto parameters, and network on boot
<seb128> that's on my list of stuff to sort
<thully> About the spelling bug - I installed with U.S.English, and logging in w/default settings I see this.  Was this fixed recently by any chance (I'm lagging a bit on my dist-upgrades)
<seb128> no idea
<seb128> that works fine here by picking "American english" in gdm
<seb128> I've replied on this one
<thully> saw that - I may try a fresh install from preview CD
<seb128> perhaps the installer has set a different locale, that's why I've asked if you have the issue with "American english"
<thully> Also, I just added a new one assigned to you - MP3 not appearing in Sound Juicer, even with the plugins installed (gstreamer-lame, etc)
<seb128> yeah, just read it
<seb128> need to try
<thully> It used to be there, they just hid it
<seb128> I don't read all the bugs, just the ones assigned to me
<thully> I saw something in GNOME help on how to add it, but it was some convoluted instructions that shouldn't be needed
<thom> thully: but basically, the points are: if we reply, we need more info; generally, if you don't get a reply but the bug remains open, it's just low priority for the developer and will get fixed eventually 
<thom> *in general*
<thully> Is there anyone here who wants to comment on the overuse of serif fonts in Firefox I've been noticing?  Slashdot is supposed to use Arial or Helvetica, but uses Bitstream Vera Serif (Vera Sans would be nice as a substitution)
<HiddenWolf> thully: it's called taste
<seb128> usually if I don't reply that's because I don't have an idea on this issue, or that's a details and I don't know what to do about it (like https://bugzilla.ubuntu.com/show_bug.cgi?id=6005 for an example)
<seb128> that and low priority
<thom> thully: way off topic
<mdz> egli: please follow up to the bug so that the information is there for everyone, thanks
<thully> why is font selection in Ubuntu off topic?  Selecting serif fonts to substitute for Arial seems like a bug...
<mdz> pitti: I agree it shouldn't add the locales on upgrade
<pitti_laptop> Hi mdz 
<thom> thully: does it only occur in ubuntu? with the same fonts, does a mozilla.org binary make the same choices?
<mdz> morning
<thom> morning mdz
<mvo> morning mdz 
<fabbione> hey mdz
<seb128> hi mdz
<fabbione> mdz: did you sleep well?
<thully> It occurs in Debian as well - may be more of a freetype bug
<mdz> yes, for once
<fabbione> that's good
<seb128> thully: you can create a profile with gnome-audio-profiles-properties though
<seb128> mdz: got my mail with the meeting log for evince ?
<mdz> seb128: I just woke up
<mdz> oh, yes, that was a few days ago
<seb128> that's from saturday :)
* lamont curses at blender for undefining HOME
<seb128> yep
<mdz> seb128: I feel the same as in my first email on the subject; I think it would be a mistake to make this change a few weeks before release
<seb128> k
<mdz> did we not have evince before preview?  I was not aware of it
<seb128> can we consider moving it on the CD ?
<seb128> it's in universe for some weels
<seb128> weeks even
<seb128> Mon, 10 Jan 2005 14:05:04 +0000
<seb128> even
<seb128> that's 0.1.0 upload for hoary
<thully> seb128: another issue (albeit low priority) why are the GNOME systray applets locked by default?  This makes it harder to customize.
<seb128> thully: so you don't drop them by mistake ... there is some bugs in gnome and ubuntu bugzillas about this, not sure about it
<seb128> you can read the discussions and comment
<thully> OK - I'll close this one
<seb128> [Bug 4267]   New: main menu should be locked by default and locking should mean undeleteable
<seb128> ie
<fabbione> is there anybody working on l-r-m ?
<thully> thom: did you see my ACPI bugs - I reported a new one recently suggesting that PPP connections be terminated on suspend
<thom> thully: yes, i saw them. 
<thully> cced to mjg59
<thully> seb128: also, 4749
<seb128> I don't have the issue, and I've no idea on it. Need some debugging work, but not a big issue and we don't have a lot of dups for it 
<seb128> ie: low priority, will wait
<mdz> thully: I told you before that it really isn't necessary (and in fact it's counter-productive) to point out your bug reports on IRC
<Kamion> anyone here know how to get e-acute on a Swedish keyboard?
<mdz> compose-quote-e?
<Kamion> in the console?
<mdz> ew
<Kamion> apparently it's possible (#7593), just don't know how
<thully> OK - sorry about that, there are just a few that have been floating around for months and I'd like to get that bug count down
<mdz> thully: we are very close to release, and our focus is on high-impact bugs.  Please don't distract developers from those.  It is unavoidable that there will be bugs remaining in the release, as our resources are finite
<Kamion> in any reasonably long-lived project, you'll find bugs that have been open for nearly the lifetime of the project
<seb128> who handles dbus bugs ?
<seb128> daniels or pitti  ?
<thully> sorry - I'm just getting into a bit of an "oh no, if these bugs don't get fixed in Hoary..." frenzy
<pitti> seb128: I don't have much knowledge about dbus... (but I can learn)
<seb128> pitti: that's not a real dbus issue, https://bugzilla.ubuntu.com/6282 ... according the redhat bug that's just an option to pass
<pitti> seb128: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=104393&action=view looks easy enough, worth a try
<seb128> pitti: yep, that's why I'm looking for the dbus maintainer :)
<seb128> dbus-1-utils: /etc/X11/Xsession.d/75dbus-1-utils_dbus-launch
<seb128> if [ -n "$STARTDBUS" ] ; then
<seb128>   STARTUP="$DBUSLAUNCH --exit-with-session $STARTUP"
<seb128> fi
<seb128> grumpf
<pitti_> so --exit-with-sesion doesn't work
<seb128> the package already uses it
<thully> Reprioritizing my bugs right now - less normal bugs, more minor bugs now
<thully> I guess if I want bug-free, I can always use debian stable :)
<fabbione> thully: debian stable is not bug free at all :-)
<thully> (except for the factthat I don't even know if it would BOOT on my 6-month old laptop)
<svenl> fabbione: BTW, how comes ubuntu carries mplayer and not debian ? 
<thully> well, pretty close to bug-free...
<mdz> Kamion: do you recall, we had a brief conversation about failing the CD build process if the kernel ABI didn't match between the live fs and d-i
<mdz> Kamion: how much work would that be to implement?
<thom> thully: not even; it was free from release *critical* bugs
<mdz> Kamion: it looks like we're not finished with ABI changes yet
<sivang> seb128: what does N_("string") mean for gettext?
<mdz> thully: I can say with absolute confidence that Debian stable has more bugs than Hoary
<mdz> Hoary main anyway
<fabbione> svenl: mplayer is not in main
<fabbione> svenl: it's in multiverse
<pitti_> mdz: since you asked for notification, all my bugs are well-classified (major/normal)
<svenl> fabbione: well, its not in non-free in debian too, so ...
<Kamion> mdz: yeah, it's still on my list ... haven't investigated yet
<fabbione> svenl: but i needed a break from the kernel on saturday.. so i decided to fix mplayer on amd64 and ppc :-)
<mdz> pitti_: thank you
<fabbione> svenl: but PPC hates me
<svenl> fabbione: ok, can you paste me the url again ? 
<fabbione> svenl: sure
<svenl> fabbione: BTW, maybe you can help me out on kernel issues.
<fabbione> svenl: http://people.ubuntu.com/~lamont/buildLogs/m/mplayer/1:1.0-pre6-0.3ubuntu6/
<svenl> fabbione: i am doing a pci_find_device in arch_initcall(mv643xx_eth_add_pds);
<fabbione> svenl: i think so.. 
<svenl> but it seems it is too early to do pci_find_device, as the pci tree is empty there.
<fabbione> svenl: what source are you using? so i can look up with you
<mdz> Kamion: perhaps a simpler short-term solution would be to finagle the scheduling so that we don't build CDs between live_fs_build and d_i_byhand
<Kamion> mdz: sure, can do
<mdz> Kamion: does elmo generally do that at the same time of day?
<mdz> (if not, perhaps we could ask that he do so)
<svenl> in the debian svn repo kernel/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/powerpc-mv643xx-eth-pegasos.dpatch
<sivang> seb128: btw, where we talking about bug #7370 ? (the meta bug for translation)
<fabbione> svenl: ok. i need to check it out.. gimme a few secs
<Kamion> mdz: um; I was thinking more of me disabling the cron job while the ABI is known to be in transition
<svenl> fabbione: maybe let's move to debian-kernel for that, altough i am preparing this for an upstream upload and patch for ubuntu's 2.6.10 kernel.
<fabbione> svenl: or #u-k :-)
<fabbione> it doesn't matter for me
<fabbione> i am not THAT formal
<fabbione> since we sync patches between each other
<Kamion> mdz: fiddling the scheduling wouldn't help anyway if nobody remembers to upload debian-installer to account for the ABI change, and since I generally take care of that anyway ...
<seb128> sivang: read the bug, if that matches what you are looking for add a comment
<seb128> I'm busy
<sivang> seb128: sorry, thx
<mjg59> thully: Please don't arbitrarily change the severity of bugs
<thully> it's not arbirtrary - I'm reprioritizing some bugs
<mjg59> If the maintainer hasn't changed the priority when you submitted the bug, and if nothing else has changed, please don't change them
<thully> OK - I just was thinking that this was a major issue - but I forgot suspend is going to be disabled bydefault in Hoary
<fabbione> thully: the priority/severity of a bug is: 1) at submission time to give an idea to the maintainer about the impact of the problem 2) after that it is maintainer discrection to prioritize/downgrade/upgrade severities
<fabbione> the submitter and the maintainer can agree on changing prio/severity
<fabbione> failing to agree is NOT good
<thully> OK - didn't know that
<fabbione> as much as it is to inflate randomically the severity
<thully> Is it ok to downgrade your own bugs?
<fabbione> downgrade is generally ok, given a very good explanation
<thom> thully: please don't private message me; if you need to update a bug, please do so on the bug
<enrico> Who should I ask for removal of ubuntu-doc-faqguide from Hoary
<enrico> ?
<thully> Sorry for the breaches of netiquette - I'm still a bit inexperienced w/dealing with bugzilla bugs and releases.  Also, there is a part of me which gets overexcited when a release is approaching.
<doko> mdz: first OOo2 build, based on the m79 milestone (beta2) succeeded, help files build with the build process, java components don't work yet
<Kamion> enrico: elmo
<GheRivero> res
<thully> mjg59: how's ACPI looking for Hoary?  did you get the cc on the PPP w/suspend bug?
<enrico> Kamion: thanks.  Same as for removal of that from the Desktop seed?
<Kamion> enrico: what seed's it in at the moment?
<enrico> (last docteam meeting we decided not to ship it with hoary)
<enrico> Kamion: it should be in the desktop seed (if it's in a seed)
<Kamion> enrico: generally if it's taken out of a seed, elmo will remove it semi-automatically
<mdz> doko: fantastic!  available for i386, powerpc and amd64?
<Kamion> so after seed removal, there's no need to hassle him directly unless it's urgent
<enrico> Kamion: ok, no, it's not urgend.  Who should I ask for seed removal?
<doko> heh, I said, build, not package ... ;) we need some infrastructure updates ...
<Simira> hi enrico. What's up?
<enrico> Simira: hi!
<enrico> Simira: just normal administration :)
<Simira> enrico: lot's, then, eh? :)
<enrico> Simira: :)
<enrico> Simira: I'm mainly busy with my main work these days
<Simira> enrico: for a change? :)
<enrico> But now, as soon as Kamion tells me about removing ubuntu-docs-faqguide from the desktop seed, I'll go and take a shower
<enrico> Kamion: you're now responsible for my personal hygiene :)
<doko> gcc-3.4 needs an update to the recent branch from the CVS, as well as gcc-4.0. both look uncritical to me, but who knows. I'd like to get a i386 chroot, where these updates can be installed (and built faster than on my current i386 build machine).
<pitti_> doko: hoary-i386 on concordia has the gcc dependencies
<Simira> enrico: scary :p I'm planning to translate the installer to Norwegian, starting to look at it today.
* enrico gives up the seed challenge and goes for the shower
<Kamion> enrico: do you not have a chinstrap account?
<enrico> Kamion: no, I don't.
<Kamion> oh, ok
<Kamion> enrico: I'll do it now
<enrico> Kamion: ok, thanks a lot!
* enrico jumps happy towards the shower
* Kamion curses lack of debconf-copydb in d-i
<doko> pitti: which dependencies?
<svenl> fabbione: would that mplayer build also on my debian box ? 
<bluefoxicy> openoffice.org 1.1.3 seems to bitch about 20-30 times on saving an ooimpress file the first time each load, then works fine
<bluefoxicy> so it's like
<fabbione> svenl: i think it should yes
<fabbione> otherwise you can just do it in a chroot
<svenl> fabbione: COOL.
<svenl> fabbione: mmm, caps went on for some obscure reason.
<bluefoxicy> new presentation or open, edit, save, OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK saving..., edit, save, edit, save, close, exit, ooimpress, open, edit, save, OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK, saving..., edit, save...
<bluefoxicy> And as stated before, ooimpress for 1.9.74 is busted and 1.9.79 has the fix, so the OOo2 betas need updating  badly.
<bluefoxicy> of course those are just universe
<bluefoxicy> (NO workaround for 1.9.74)
<bluefoxicy> is OOo2 planned for Hoary still if it makes it out?
<bluefoxicy> the UI is much better than that aweful hell that is OOo
<Kamion> 17:37 < doko> mdz: first OOo2 build, based on the m79 milestone (beta2) succeeded, help files build with the build process, java components don't work yet
<bluefoxicy> Kamion:  thanks.
<Kamion> folks are working on it; if it makes it then it may still be a candidate for Hoary
<bluefoxicy> *nod* I still hate the OOWriter UI, but it has integrated windows instead of junk floating around i.e. to pick styles from, so it's "better"
<bluefoxicy> so that would be good
<mdz> doko: email admins to get an account on the porting box
<mdz> doko: CC me
<bluefoxicy> Kamion:  I removed oowriter, oocalc, oodraw, but I can't seem to remove openoffice.org2 base
<bluefoxicy> I don't need a database editor
<Kamion> I'm sorry I can't help you
<bluefoxicy> no ideas huh.
<Kamion> well you specifically asked a guy who has no clue about OOo :)
<bluefoxicy> :)
<Kamion> direct questions to the channel unless you really mean that one person ...
<bluefoxicy> well, uhh, same question, for all :)
<crimsun> why can't you?
<pitti> doko: build-deps
<crimsun> sudo aptitude remove openoffice.org2 ?
<bluefoxicy> crimsun:  can't find it
<bluefoxicy> crimsun:  I just want to remove the database part
<bluefoxicy> apt-get remove openoffice.org2-writer
<bluefoxicy> :) drops oowriter2
<crimsun> I'm guessing -core or -common
<Treenaks> mjg59: ping?
<mjg59> Treenaks: Hi
<mvo> crimsun: I'm catching up with the ML right now. is gdeb fully working again? or are there still problems after my upload (a couple of days ago)?
<crimsun> mvo: to be honest, dunno - I was just responding to a request to "make it work again"
<crimsun> mvo: afaik, your upload works fine
<mvo> crimsun: ok, thanks
<crimsun> back after lunch
<Treenaks> mjg59: see #7651
<Treenaks> mjg59: (about the "Panic buttons" I have :))
<mdz> jbailey: ping, re: #1080
<mjg59> Treenaks: Oh, christ, that's horrible
* mvo is away for ~2h
<mjg59> Treenaks: I think you're going to need a better kernel hacker than me to track that down. 
<mjg59> Disabling preempt would probably work, but it's not clear to me why it's exploding like that
<Treenaks> mjg59: ok.. though it does say "es1968_update_hw_volume" somewhere -- which is exactly what it should be doing :)
<Treenaks> I'll wait for fabbione to read the report & explode ;)
<thom> mjg59: any comment on #7029? is doing a vbetool resume reasonable if we can? or is it likely to explode horrifically most of the time?
<mjg59> Actually, no, that's probably a driver bug - it's scheduling while it's in an IRQ handler, which is amazingly broken
<mjg59> thom: Argh. No, that'll explode.
<thom> 'swhat i thought
<mdz> thom: do you have an ETA for the firefox upload?
<thom> mdz: wednesday
<thom> mdz: as i said saturday morning, i'm gonna take the opp. to nail down some more bugs while i have the time
<mdz> thom: it's important to get the new code in as soon as possible if we're going to do it
<thom> yup
* ..[topic/#ubuntu-devel:mdz] : 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
<mjg59> Treenaks: Ok. I /think/ the msleep()s in the es1968 code are dangerous and shouldn't be there
<Treenaks> mjg59: I can't reach the laptop now (it's at my parents' place)
<mjg59> Treenaks: Ok. I think you want to take that function and s/msleep/mdelay/
<Treenaks> what's the difference?
<mjg59> mdelay can be called in IRQ handlers
<mjg59> msleep says Come back to me in this much time, mdelay says Wait for this much time
<Treenaks> ah ok
<mdz> doko: by admins, I meant admins@admins
<Treenaks> mjg59: vanilla 2.6.11 has the msleep(1) calls commented out..
<mdz> doko: elmo doesn't seem to be around right now; is it impossible for you to do the work on your local machine?  it is important to get it into the archive soon
<mjg59> Treenaks: Haha
<mjg59> Treenaks: Does the Ubuntu 2.6.11 kernel work?
<doko> mdz: I continue, but a OOo build takes 9hours + 1/2 for every language
<mjg59> (Oh, though it's not actually 2.6.11, so it may not have that code...)
<Treenaks> mjg59: can't test now
<mjg59> Treenaks: Ok, could you add that to the bug report?
<mdz> doko: how much of that is source code?  are you using ccache?
<Treenaks> mjg59: done already :)
<doko> mdz: ccache doesn't help yet, if I rebuild gcc
<mdz> doko: rebuild gcc?
<mdz> between oo.o builds?
<bluefoxicy> Am I the only one who has a koffice workspace icon in his gnome menu?
<doko> sure, to fix ICE's
<mdz> wonderful, ICEs :-/
<mdz> I thought you said it built OK?
<doko> yes, now :)
<bluefoxicy> 9 hours o.o
<bluefoxicy> doko:  just curious, what hardware are you using to build that on
<doko> athlon 2400
<bluefoxicy> ah
* bluefoxicy has an amd64 2800, OO still takes ungodly long but he can build Xorg or Firefox in 45 minutes
<bluefoxicy> I got to play with a $6000 machine the other day, it had a $1000 AthlonFX chip in it.  Had to install spyware removal stuff and tons of apps on it.  Unfortunately, $6000 machines are out of the reach of open source projects :/
<bluefoxicy> that thing ate SP2 in 8 minutes (it took my uncle's new sempron an hour or two) though.
* mdz laughs at $6000 machines being out of the reach of open source projects, logs into LInux/390
<bluefoxicy> lol
<bluefoxicy> mdz:  why don't you have an Athlon FX socket 939 with 1G ram that can build gentoo in 1-2 hours then ;)
<Treenaks> bluefoxicy: all of gentoo?
<Mithrandir> I won't be getting a FX55 since nobody is able to sell them to me :(
<Mithrandir> only an XP4000+
<dredg> bluefoxicy: what? then the compile text will scroll too fast for me to learn anything from
<dredg> that *is* how people learn linux, right?
<Treenaks> dredg: partly :)
<Treenaks> dredg: I learned to debug other people's C code that way :)
<dredg> Treenaks: oh good. gentoo seems like the best learning distro then
<bluefoxicy> Treenaks: on my 2800+ amd64 I build gentoo in 10 hours, with gnome, abiword, gnumeric, xchat, gaim, xmms, xorg, firefox, gqview, thunderbird, gtk-gnutella, gimp, dia, vim, and vorbis tools in 10 hours
<Hannes_> ;P
<bluefoxicy> it took 29 hours fastest clock-in on my 1.8GHz barton core 2400+ (the 2800+ clawhammer is 1.8G)
<bluefoxicy> it cost me almost exactly $255 to upgrade XD
* dredg doesn't even know what spec desktop he has
<dredg> i know it has 512M ram, and i know it's an AMD something chip...
<bluefoxicy> but yeah, 9 hours is too much time to waste to build something you're not 100% sure is gonna build
<bluefoxicy> debugging could take weeks/months
<Treenaks> dredg: reading debian-bugs-dist helps too :)
<dredg> but i really stopped paying attention to spec after machines were just good enough (tm)
* bluefoxicy wonders htf long it would take him to build OO, probably like 5 hours, not much better :/
<dredg> Treenaks: sounds like a lot of effort. can i not just install gentoo and then tell eveyone that i'm leet?
<bluefoxicy> dredg:  install Hardened Gentoo ;)
<Treenaks> dredg: if you can keep up with debian-bugs-dist, you're even more leet :)
<zul> no you cant its not aloud
<dredg> bluefoxicy: nah, i'm only kidding. i like actually using my computers :)
<bluefoxicy> so do I :p
<dredg> Treenaks: there aren't enough hours in the day
<Treenaks> dredg: exactvly, and you'll know C by the time you catch up :P
<bluefoxicy> dredg:  I just decided it was time to expand out.  I'm still not satisfied with ubuntu's security but I'm interested in seeing how it progresses.
<dredg> Treenaks: technically, i already know C *shrug* it's just been about 7 years since i used it is all :)
<bluefoxicy> (if you didn't figure out already, I like running high-high-high security, just as a point of properness; I'm not really at risk of attacks)
<dredg> bluefoxicy: what's wrong with ubuntu's security? how does spending time rebuilding apps with patches and then rebuilding everything that depends on them make you more secure?
<zul> dredg: well you are always down for one :)
<bluefoxicy> dredg:  I ran with a PIE base, ProPolice, and PaX/GrSecurity.  The Hardened Gentoo guys put a lot of effort into their work ;)
<dredg> zul: :)
<dredg> bluefoxicy: did you audit this yourself?
<dredg> bluefoxicy: i'm not starting a religious war here, i'm just cusrious
<dredg> curious too
<bluefoxicy> dredg:  Overall I think you could run that on like, a 486 without noticing any slowdown; definitely no administrative or user end learning curve increase
<bluefoxicy> though mostp eople look at PIE or SSP or PaX and go "OMFG OVERHEAD" like they're constantly bumping 100% CPU or something
<dredg> and didn't PaX/grsec have a bunch of massive holes in it recently?
<bluefoxicy> PaX had a massive VMA mirroring bug that created a definite local root exploit, but it was fixed
<bluefoxicy> however, that was implementation
<bluefoxicy> the design was not compromised; the concept of VMA mirroring is not inherantly insecure, best proven by pointing out that the bug was fixed.
<dredg> fixing a bug does not prove the inherent security of something.
<bluefoxicy> (in the same way that passwords are not inherantly insecure; but bob wrote his on his monitor with a sharpie, which was bad)
<bluefoxicy> dredg: no, it definitely does not; but there is nothing that indicates that vma mirroring is inherantly insecure
<bluefoxicy> at least not any more insecure than the basic paging logic of the x86 CPU itself is.
<zul> guys you might want to take this somewhere else
<bluefoxicy> dt was a bug in the way he was unmapping pages; basicalyl you could unmap a page without having it cleaned up, and have it mapped into another application as-is, thus you could inject code
<dredg> nah, i'm done now
<bluefoxicy> heh, yeah.
<dredg> i was just curious. i didn't expect a story
<bluefoxicy> I talk a lot :)
<mdz> who here uses irssi?
<Kamion> me
<mdz> -> https://bugzilla.ubuntu.com/show_bug.cgi?id=6893
<Kamion> but my irssi runs on a woody box ...
<helix> oh
<Kamion> mdz: I don't see that problem in woody, even. I suppose it *could* have regressed ...
<mdz> Kamion: irssi-text is a console program, right?  I wonder if they're running it on the bare console and it's a consolefont problem
<helix> ask them what term_type is set to
<helix> it needs to be set to utf8
<mdz> helix: thanks
<helix> there are lots of places for it to screw up though
<helix> if they use it in screen, for example
<mdz> yeah, you need to tweak another knob in screen to make it vaguely utf8-aware, right?
<Kamion> C-a :utf8 on # works for me
<Kamion> although I also have 'defutf8 on' in ~/.screenrc
<[Clint] > or :utf8 on on
<thom> yep; or run screen with -U
<[Clint] > depending
<Kamion> again, that's on woody
<thom> my screen/irssi is on freebsd, so i also can't confirm either way
<Kamion> enrico: you said both ubuntu-doc-faqguide and ubuntu-docs-faqguide earlier; the only similar package I can find is ubuntu-faqguide. Confirm?
<thom> 
<[Clint] > my screen/irssi is on openbsd, so it's inherently more secure
<thom> ok, that musical note showed fine running it in console on hoary
<helix> [Clint] : heh
<helix> mdz: yeah, there are several ways to make it use utf8 (screen)
<thom> [Clint] : :rolls eyes:
<[Clint] > lack of locales is fun
<GheRivero> res
<pitti> sivang: I'm back (network outage, modem now); any news?
<mdz> fabbione: https://bugzilla.ubuntu.com/show_bug.cgi?id=7586
<mdz> fabbione: I'm closing as universe, but FYI
<mdz> Kamion: what's your feeling on #4271?
<ogra> oh, gpm is in universe ? has it ever been there ?
<ogra> s/ever/always
* ogra thinks this should be in main, easily solves X issues with serial mice
<mdz> ogra: the gpm source package is in main, but the gpm binary package is in universe
<ogra> ah, k
<mdz> serial mice are better dealt with through the kernel input layer; that is how we unify ps/2 and usb
<mdz> ogra: since you're here, hwdb status? ;-)
<ogra> found a process to handle the sound and network device names, will upload the changes after my hacking session tonight
<ogra> the send part now has a check for the server and will throw a "no server found message" so we wont recieve bugs about that (i hope)
<ogra> which means i can start improvement and implement the changes we talked about tomorrow :)
<HiddenWolf> ogra: tomorrow? :P
<ogra> with a little luck its all done by next weekend....
<HiddenWolf> ogra: your grammar is seriously messy. ;)
<ogra> yup, didnt sleep tonight, had a very hard day cleaning my last stuff with my company (they will pay me until end of month but i dont have to work for them anymore)
<ogra> so please forgive my broken grammar, will be better tomorrow again :)
<Mithrandir> mdz: if there is a package in NEW in Debian which I would very much like in Ubuntu (even though just universe), is there any way to get it?
<mdz> Mithrandir: you can simply upload it, assuming you can get a copy from elsewhere
<Mithrandir> mdz: ok, I'll do that, then.
<Mithrandir> just a normal upload, no ubuntu1 revision?
<mdz> ogra: it sounds like once you have the above fixes packaged, we can add it to desktop
<ogra> yay
<mdz> ogra: we need to do that as soon as possible to get more testing; when can you have that package uploaded?
<HiddenWolf> ogra: you're forgiven
<mdz> Mithrandir: in order to do it without the diff and dsc being different, you need to craft a .changes by hand or semi-byhand
<Mithrandir> mdz: change the distribution, you mean?
<ogra> as is said above, the send part and device name part is in tomorrow, the additional changes will take a day extra
<Mithrandir> or anything else?
<mdz> Mithrandir: if you have a .changes available, you can just change the distribution, yes
<mdz> and re-sign if necessary
<Mithrandir> yeah
<Mithrandir> (it's mcelog, which is used for decoding machine check exceptions; fairly useful for amd64 stuff)
<bluefoxicy> dredg:  http://usrbac.sourceforge.net/misc/sec_presentation.sxi
<pitti> amu: btw, does kdeedu contain this setuid program (fliccd) or did you already remove this?
<ficusplanet> In hoary's final release, will gnome-app-install include apps from universe (if universe if enabled)?  The current selection seems to skimpy to be useful.
<amu> pitti: was not set :) 
<pitti> amu: relieving, thanks :-)
<amu> pitti: thanks for reminding me, i didnt check it in the new version :) 
* lamont heads off to better bandwidth.  Back online shortly
<mdz> jbailey: ayt?
<jbailey> mdz: Yup!
<mdz> ficusplanet: the selection is small for the very reason that a complete list would be useless
<mdz> jbailey: how is #1080 coming?
<ficusplanet> mdz, I understand that a complete list wouldn't be good.  But I think it would be reasonable to include popular software like muine and rhythmbox in the list.
<zul> later
<bluefoxicy> muine?
<bluefoxicy> since when does mono work
<jbailey> mdz: Alright.  I've got the xmlrpc stuff into libsoup now, and it works well.  I'm organising my pieces into a libbugzilla thing so that it doesn't get too ugly inside.
<jbailey> mdz: I've submitted the bugzilla patch upstream to them too, so that it's there.
<mdz> jbailey: do you have an ETA?  RC is getting awfully close
<ficusplanet> bluefoxicy, I've been using muine since it was released, and it's worked practically flawlessly.
<mdz> ficusplanet: yes, rhythmbox should definitely be there, and that will be added
<mdz> ficusplanet: but we don't plan to add unsupported packages to that list
<ficusplanet> mdz, OK.  Thanks for the info.
<seb128> jbailey: with the xml-rpc stuff we will get all the bug buddy bugs in bugzilla.ubuntu.com ?
<jbailey> mdz: I keep wanting to say that it'll be right there, and then I keep hitting stupid stumbling blocks.  I'm also trying to make sure that I service the other bugs in my set too.
<jbailey> seb128: Yes.
<seb128> doh
<seb128> I'm wondering how we will handle the GNOME bugs
<jbailey> In what way?
<mdz> well, for one, we have no way to contact the submitter for more information :-/
<mdz> seb128: I think we should probably categorize them somehow
<mdz> they will only be useful in order to see common crashes and things like that
<seb128> yeah, but according to upstream that's a lot
<mdz> seb128: we can't simply discard the reports; this apparently makes users upset :-)
<mdz> seb128: if we get a huge number of bugs, we can do some automation to make it manageable
<seb128> I'm not saying that we should not
<seb128> hum, wrong shortkey :p
<seb128> I'm not saying that we should not do it
<seb128> that's just that's not easy to keep with the bug flood atm
<seb128> with bug-buddy that'll get funny to handle
<Nafallo> mdz: ping?
<Nafallo> mdz: nm ;-)
<mdz> seb128: we can auto-assign all of the bug-buddy bugs to a special address or something, if necessary
<seb128> isn't it a plan to make a gnome-bugs-list or something ?
<Nafallo> mdz: anything more than the output of locale for #6894?
<jbailey> mdz: Hey, you mentioned having an amd64, right?
<dholbach> i'm packaging bakery2.3, which had the 3 binary packages libbakery-2.3-{common,dev,9}, now ABI broke and i'll have libbakery-2.3-{common,dev,12} around, do i have to Replace: or Conflicts: anything?
<crimsun> libbakery-2.3-12 needs to Conflicts: libbakery-2.3-9
<dholbach> Replaces?
<pitti> dholbach: no, it seems to have a new SONAME, so it should be okay
<crimsun> oh, it has a new soname completely? nevermind.
<pitti> dholbach: however, please make sure that the *.so file actually has the SONAME in its name :-)
<pitti> huh, why?
<pitti> the two libraries can be installed in parallel
<mdz> jbailey: I have local access to i386, powerpc and amd64
<Mithrandir> dholbach: you don't need to conflict or replace or anything if you don't have file overlaps.
<dholbach> pitti: you're right... they are
<mdz> Nafallo: please keep bug communication in bugzilla; I have a few hundred more bugs to deal with and cannot discuss them all interactively on IRC
<dholbach> Mithrandir: ack
<jbailey> mdz: Can I get you to test something for me a bit later?  I have a sable bug that claims exec stack troubles that I can't reproduce.  But it was reported on amd64 and I don't have access to one at all.
<mdz> jbailey: ok
<mdz> jbailey: there are also several other people in here (probably less busy) who could help
<Nafallo> mdz: oki. I already sent it :-).
<crimsun> dholbach: right, hence my "nevermind" :-)
<dholbach> thanks pitta, Mithrandir, crimsun  :-)
<dholbach> pitti
<Mithrandir> hiya dholbach
<enrico> Kamion: yes, ubuntu-faqguide
<pitti> mdz: may I break libc again for hoary?
<pitti> mdz: I optimized the locale lookup in libc6 "a bit" (factor 35), and the patch is easy
<mdz> pitti: can I see the patch?
<pitti> mdz: http://people.ubuntu.com/~pitti/glibc-lookup.patch
<pitti> mdz: it also fixes install-language-locales, I want to do this in one upload
<ogra> seb128 ?
<pitti> mdz: the previous version sorted the file, which scrambled comments and other stuff (people complained about this)
<pitti> mdz: however, I'm still testing the new libc currently
<seb128> ogra: here
<ogra> seb128, could you have a look here ? i think the guy is wrong, seems he advises to add vfolders: http://www.ubuntulinux.org/wiki/GnomeMenuEditingHowTo
<ogra> seb128, i understodd they dropped them completely, or are there remainig bits ?
<seb128> he describes the warty menu system
<ogra> yup, thats what i thought, sigh....
<ogra> i posted about 10 times the link to the f.d.o standards to the list, nobody seems to read me :(
<ogra> seb128, thanks for the help, i'll care for it further
<seb128> np
<sm> doh.. guess I shouldn't have forwarded that link just now
<ogra> sm: heh, you are simon ?
<sm> yup, hi
<ogra> sm, i'm just replying :)
<sm> thx
<pitti> mdz: please forget the patch for now, it doesn't work correctly
<mdz> pitti: ok
<_d4vid> hi all
<dholbach> seb128: gtkmm2.4-2.6.1 on http://ubuntu.gplan.info/mm  ;-P
<seb128> k
#ubuntu-devel 2005-03-26
<lamont_r> Kamion: you awake?
<jdub> mdz: around?
<mdz> jdub: yes
<seb128> mdz: about #6387, bug to fix for hoary I guess ?
<seb128> any idea on how ? mask this tab ?
<mdz> seb128: is carlosg going to hate us?
<seb128> I don't think he cares if we mask it
<seb128> if we break it, perhaps :p
<mdz> is there anything on that tab which is not scary?
<seb128> hum, in fact I'm messing the 2 tabs
<mdz> changing the shell is OK
<seb128> the username is on the account one
<ogra> mdz, to which bug belongs the gpm patch (for the credits)
<seb128> mdz: changing the username field to a non-editable one ?
<mdz> ogra: I don't remember
<mdz> seb128: that sounds fine to me
<mdz> whatever you feel is best
<seb128> k
<sivang> seb128: more changes to users-admin ?
<seb128> read #gst
<pitti_> "Thou shall not 'mv libc-2.3.2.so libc-2.3.2.so.old' in /lib/tls"
<pitti_> argh
<seb128> lol
<ogra> hehe
<dholbach> ouch
<pitti> Hi Astharot 
<Astharot> hi
<sivang> pitti: the modification of the POTFILES.in should be part of the i18n patch or of the l10n patch?
<sivang> pitti: (I have to add an entry with that file, since it didn't have harcoded strings before)
<sivang> pitti: (view-printers.c)
<pitti> sivang: i18n
<sivang> pitti: k, cool
<sivang> pitti: thx
<lamont_r> mdz: what do you think about importing openafs 1.3.74 from debian/experimental into universe, since what's in universe doesn't believe in 2.6 kernels?
<lamont_r> it's not like it breaks anything worse than it already is.... :-)
<ogra> lamont_r, hmm, a question of belief .....
<lamont_r> although 1.3.79 has been released....
<lamont_r> ogra: will not compile, apparently.  or at least doesn't work.
<lamont_r> my afs-bigot friend is asking after it...
<ogra> so just let it sync then, its universe, as long as you think it will work *shrug*
<lamont_r> and it's a prereq for getting hoary on my (shared) co-lo box....
<lamont_r> ogra: oh, no. it panics the kernel occasionally, but it mostly works.... apparently... :-)
<ogra> hehe
<lamont_r> I'll put the bigot to work on making a package :-)
<lamont_r> ogra: but do you see any issues with uploading it to universe?  When is the universe freeze anyway?
<dholbach> lamont: when we fixed wiki/MOTUTodo
<dholbach> lamont_r: :-)
<ogra> lamont_r, we call it a "soft" freeze ;)
<lamont_r> ok
<lamont_r> kinda like soft-serve?
<ogra> lamont_r, if its required we upload or sync... just trying to avoid unnecessary stuff
<lamont_r> ok.
<ogra> lamont_r, dholbach collects a list for elmo syncs currently....
<lamont_r> I'm going to make him either package 1.3.79, or work with hartmans to update the package in experimental
<ogra> ok
<zul> evening
<dholbach> hi zul
<pitti> mdz: now I have a patch that really works; it's more straightforward, too
<zul> hey dholbach 
* lamont_r wanders off for a couple hours of errands in town.
<mdz> lamont_r: fine with me, if you'll make sure that it builds
<GheRivero> res
<GheRivero> ping jdub
<Riddell> is anyone able to help me with a package
<Riddell> http://jasmine.19inch.net/~jr/away/kubuntu/kubuntu-default-settings/kubuntu-default-settings_5.10.01_all.deb
<GheRivero> what's the problem Riddell ?
<Riddell> doesn't install the files it should install in /etc
<GheRivero> sources?
<Riddell> same directory
<Riddell> or  deb http://jasmine.19inch.net/~jr/away/kubuntu/ ./
<GheRivero> Riddell, are you sure it doesn't install files on /etc?
<Riddell> GheRivero: doesn't seem to for me
<Riddell> GheRivero: have you installed it?  what do you get in /etc/kde-profile/default/share/config/
<GheRivero> which one exactly I have a lot of them there now
<jdub> GheRivero: hi
<pitti> night everybody
<GheRivero> clock_panelapplet_kubuntu_rc  kdeglobals  konqiconviewrc  kpersonalizerrc
<GheRivero> kaffeinerc                    kdesktoprc  konquerorrc     kwinrc
<GheRivero> kbookmarkrc                   kickerrc    konsolerc
<Riddell> so it works for you, why doesn't it work for me?
<GheRivero> jdub, did you get sleep? :)
<GheRivero> Riddell, it should be the same
<sivang> good night all!
<jdub> GheRivero: apart from the mosquitos eating me, yeah ;)
<dholbach> bye sivan
* ogra looks up the word sleep in his dictionary
<sivang> night dholbach 
<zul> oh yah it summer in australia i keep forgetting
<sivang> good night ogra 
<ogra> night sivang 
* sivang detaches
<GheRivero> Riddell, did you try purging the package before installing it?
<Riddell> GheRivero: ah, that fixed it
<Riddell> thanks
<GheRivero> you are welcomed
<Fackamato> hi
<Fackamato> I have a problem with ubuntu
<Fackamato> this is very strange.
<Fackamato> it's not logical or anything, I don't get it
<wasabi_> #ubuntu
<wasabi_> -devel is for development
<Fackamato> well, I figured you might know more about ubuntu core-things than they do, they pointed me here
<Fackamato> you as in you guys
<Keybuk> most of the guys in here hang out on #ubuntu too
<Keybuk> and answer questions there
<Keybuk> this channel is for discussing development of ubuntu
<Amaranth> and me asking stupid development-related questions, of course :)
<Fackamato> let me finish: using fglrx driver, ati card, 2.6.10-k7, i install the driver, i load it, xorg works fine. i reboot, xorg doesn't start, i get this: www.tehjunkyard.net/xorg.log . i modprobe -r fglrx.ko, I copy the fglrx.ko from fglrx package to /lib/modules/kernelversion/kernel/drivers/video/fglrx.ko and modprobe it again. now it works. reboot, doesn't work. I have to rmmod and copy the file again, and it works.
<Fackamato> does ubuntu copy over the file or something?
<Fackamato> the filesizes are the same.
<srbaker> where do i set up an sftp folder in nautilus like edd points out on his blog?
<ogra> guys
<ogra> #ubuntu please
<srbaker> oh, whoops
<wasabi_> Fackamato, if nobody in #ubuntu is answering you, the same people aren't going to answer you here.
<Fackamato> wasabi_: Indeed, there might be more people in here that aren't in #ubuntu though.
<Fackamato> :>
<Keybuk> we'd be in #ubuntu if we were able to help
<Riddell> how does gnome turn on anti-aliasing by default?
<Riddell> seems you have to make a ~/.fonts.conf
<srbaker> hhe.  if debian cuts down to 4 archs, it won't be very useful to me anymore :p
<mdz> jdub: what's the status of the cursor changes (#6172)?
<jdub> local package has the alternative foo re-added
<mdz> is there a waitcondition for uploading it?
<jdub> however i'm having a problem with stuff left behind by the old package, or inability to override
<jdub> here's what's in my alternative
<jdub> sorry, phone
<jdub> gar
<jdub> okay
<jdub> $ update-alternatives --display x-cursor-theme
<jdub> x-cursor-theme - status is manual.
<jdub>  link currently points to /usr/share/themes/Industrial/cursor.theme
<jdub> /etc/X11/cursors/core.theme - priority 30
<jdub> /etc/X11/cursors/redglass.theme - priority 20
<jdub> /etc/X11/cursors/whiteglass.theme - priority 20
<jdub> /etc/X11/cursors/handhelds.theme - priority 20
<jdub> Current `best' version is /etc/X11/cursors/core.theme.
<jdub> 
<jdub> thus,
<jdub> /etc/alternatives/x-cursor-theme -> /usr/share/themes/Industrial/cursor.theme
<jdub> oh, wrong machine
<jdub> anyway
<jdub> so with current package, i get a Human alternative correctly
<jdub> with priority 40
<jdub> but can't find a way to reset the manual alternative (to a file that no longer exists)
<jdub> (phone)
<mjg59> jdub: Yo
<mjg59> jdub: Looks like I'll be joining you in .au
<dholbach> jdub: can't you   update-alternative --something  in the old package's  .prerm?
<GheRivero> drmOpenDevice: open result is -1, (No such device)
<GheRivero> drmOpenDevice: open result is -1, (No such device)
<GheRivero> drmOpenDevice: Open failed
<GheRivero> sorry! not here!
<jdub> dholbach: that seems impolite
<dholbach> jdub: but you say it no longer exists?
<seb128> g'night 
<dholbach> bye seb128 
<dholbach> seb128: thanks for uploading
<seb128> np
<zul> night seb128 
<mroth> fabbione: do you think it will be possible to examine #7258 prior to hoary, or is it too low priority?
<jdub> dholbach: there's no guarantee that it doesn't, however
<dholbach> jdub: and a rigid   update-alternative   to whatever you're trying to update the alternative to? maybe a bit impolite too, hm? :-)
<ogra> jdub: test it before running update-alternative
<jdub> i'm sure there is a general or recommended solution to this, i just don't know what it is
<mdz> jdub: you can't/shouldn't override a manually-selected alternative; why would you want to?
<dholbach> using debconf *duck and run away*
<mdz> if it's being set to manual when it shouldn't, that probably means you're doing things in the wrong order
<jdub> mdz: exactly :-)
<jdub> mdz: what's the status of your x-cursor-theme alternative?
<ogra> jdub: here its broken
<ogra> lrwxrwxrwx  1 root root  41 2005-01-31 11:40 x-cursor-theme -> /usr/share/themes/Industrial/cursor.theme
<jdub> yep
<mdz> jdub:  +    1        /etc/X11/cursors/core.theme
<mdz> (automatic)
<mdz> oh, no it isn't
<jdub> mdz: how fresh is your hoary install?
<mdz> /etc/alternatives/x-cursor-theme is a broken symlink
<jdub> see, i think the old industrial engines package didn't deregister properly or something
<mdz> sounds that way
<mdz> so a new version of the industrial engines package should fix it
* mjg59 swears at HP hardware
<jdub> but it doesn't have the cursor theme any more
<mdz> but it broke the alternative (we think)
<jdub> the old one did, i imagine
<jdub> it was replaced with a package from a different source
<mdz> what package are we talking about here?
<mdz> the one which used to contain themes/Industrial/cursor.theme
<ogra> gtk-engines-industrial i guess
<jdub> mdz: so
<jdub> old gtk2-engines-industrial had the cursor theme
<mdz> gtk2-engines-industrial doesn't have any maintainer scripts
<mdz> at all
<jdub> the new one is from a different source, gtk-engines, not the old, independent industrial source
<jdub> yeah, the new one doesn't need any
<mdz> what a mess
<mdz> this needed to be dealt with much earlier; I didn't realize this was fucked alternatives, rather than just moving files around
<mdz> the prerm in the warty version of gtk-industrial-engine looks reasonable
<mdz> its postinst is fucked though
<jdub> so should the new package have removed the alternative on postinst?
<jdub> or should the prerm from the old package have handled it?
<mdz> the prerm from the old package should have handled it
<jdub> mmm, that's what i had thought
<jdub> so, bad hack to check and change in the new ubuntu-artwork package?
<mdz> but if there were an error during prerm, it would have called postinst to unwind
<mdz> which unconditionally restores the alternative
<mdz> I'd recommend fixing it in gtk2-engines-industrial
<mdz> if /etc/alternatives/foo is a broken link, and the target is bar, then update-alternatives --auto foo
<zenwhen> who is going to get the job of sorting all the data given by the hardware info report tool
<jdub> mdz: and update-alternatives in ubuntu-artwork should only happen on install or upgrade
<jdub> mdz: correct?
<mdz> jdub: where does ubuntu-artwork enter into it?
<mdz> oh, ubuntu-artwork has the new theme
<jdub> yes
<mdz> ubuntu-artwork should do update-alternatives in postinst (install|upgrade) and prerm (remove)
<jdub> (working around upstream screwage)
<mdz> I think
<mdz> I always look it up and check examples because I rarely work with alternatives
<mdz> I wonder why there isn't a debhelper component for alternatives yet
<jdub> hrm
<ogra> zenwhen: some cool AI
<jdub> the old gtk2-engines-industrial removed the icon cache
<zenwhen> ogra, oh thats cool. It has taken five minutes just gathering data.
<jdub> hrm, no, that makes sense here, too
<zenwhen> I hope it works.
<ogra> zenwhen, nope
<zenwhen> oh its broken?
<ogra> zenwhen, i havent uploaded the code for sending yet
<zenwhen> well it sure looks cool
<zenwhen> :)
<zenwhen> really really professional
<ogra> zenwhen, thanks, cross your fingers that it works like it looks too :)
<zenwhen> Hopefully so. I'd like to see Ubuntu call ym video card by name.
<zenwhen> my*
<zenwhen> :)
<ogra> zenwhen, that should be ready during the next two days (naming netcard, videocard and probably soundcard) the last one i cant promise though
<zenwhen> sounds awesome
<mdz> ogra: ETA for the ubuntu-desktop-ready version?
<ogra> wed 23:59 UTC ?
<ogra> to late ?
<mdz> ogra: we need something in array 7
<mdz> that's the final milestone before RC
<ogra> mdz: array 7 was yesterday according to the release schedule
<mdz> ogra: no, it's Wednesday
<mdz> (according to the release schedule ;-) )
<thully> Just did a clean install from preview CD - hibernate was not set up by default (at least the suspend/resume partition wasn't)?  Is this expected?
<mdz> thully: only if you didn't create a swap partition
<tseng> the resume partition is sawp
<tseng> swap.
<mdz> it's been repeatedly confirmed to work under a variety of circumstances otherwise
<ogra> mdz: ok
<thully> OK - whatabout adding resume= - is that necessary?
<mdz> no
<mdz> did you actually check whether it worked?  resume= is no longer necessary
<ogra> mdz: forgot about the 2 day timeshift
<thully> where is that taken care of, then?
<tseng> in the kernel, its all setup for you at install
<tseng> please just give it a try from the logout menu or gdm and let us know if its !working
<mroth> the resume= line is no longer necessary?  waoh.  should I remove it and test for confirmation?
<thully> so -can you use the ThinkPad hibernate shortcut (Fn+F12)
<tseng> theres a really easy way to find out
<tseng> try it :)
<thully> I'll go ahead and try it out
<dholbach> if not: you can reconfigure the keyboard short cuts from the gnome menu
<tritium> does anything check that the swap space is >= the amount of memory in the newer install CDs?
<thully> One unrelated question: is it too late to enable autohinter in Hoary, even if just for a whitelist of fonts?
<tseng> end-user questions belong in #ubuntu btw
<thully> no - this is a question about system defaults, not how do I enable autohinter
<tseng> your last question was not
<tseng> you seem fairly determined to spend up development time on simple things you could find out for yourself
<mdz> thully: yes, it is absolutely too late, and I already told you that the last time you asked about it
<tseng> oh.. and there is the issue of you repeating/cross posting yourself
<mdz> which was earlier today
<thully> OK - I think it may have been lostin my e-mail
<dholbach> good night everyone
<tseng> bye dholbach 
<dholbach> bye tseng 
<zul> thully: google is your friend
<thully> hi - just tested hibernate - on first boot after install, you can't do it using the keyboard and doing it from GNOME shutdown screen causes the system to hang in the middle of the process
<thully> After rebooting, it works fine using keyboard and GNOME menu
<thully> Just reported it on bugzilla - 7667
<thully> not sure of the component, so I specified acpi-support
<jba> not sure if this is an ubuntu devel question but will ask it here anyway
<jba> is there a reason why every time i run the update manager grub re-writes my menu.lst ?
<jba> and removes my windows entry?
<jba> i don't mind re-entering but it seems like this shouldn't be happening?
<jdub> put your windows entry outside the automatically rewritten section
<jba> jdub, aah cool, thanks dude, I did have as the first item (for my wife's sake)
<jba> i'll just have to tell her to pick the last one
<jba> or let it go by default
<lamont> mdz: did you want to know that zsh is ftbfs?
<jdub> you can make it the first entry by putting it above the automatically rewritten seciton
<jdub> and it will be used as the default
<mdz> lamont: it'sawhat?
<mdz> lamont: my upload changed nothing but changelog and Completion/Unix/Command/_baz
<lamont> make[2] : Entering directory `/build/buildd/zsh-4.2.1/obj/Src'
<lamont> ../../config.status
<lamont> make[2] : ../../config.status: Command not found
<lamont> make[2] : *** [mkmakemod.sh]  Error 127
<mdz> lamont: and I test-built it before uploading
<mdz> did the previous version FTBFS too?
<jba> jdub, i thought i did that alreasym will try again
<lamont> mdz: no.
<lamont> mdz: you seem to have a special touch. :-(
<mdz> Clint: any guesses?
<mdz>  Completion/Unix/Command/_baz |    4 ++--
<mdz>  debian/changelog             |    6 ++++++
<mdz> must be some kind of timestamp fuckage
<Clint> mdz: there's a very nasty ugly patch on zsh to prevent it from linking the main binary to -lpcre and -lcap.  it looks like that got a little fragile
<Clint> well, it was fragile to begin with
<Clint> so, yes, it's probably timestamp fuckage
<mdz> Clint: is there a bat^Wworkaround I can apply?
<Clint> if I weren't suffering from extreme sleep-deprivation, I'd say yes
<mdz> http://people.ubuntu.com/~lamont/buildLogs/z/zsh/4.2.1-15ubuntu3/zsh_4.2.1-15ubuntu3_20050314-2238-i386-failed
<mdz> there's the full log
<Clint> is going to 4.2.4 right out?
<mdz> how well-behaved has it been in Debian?
<mdz> I don't mind digging a fix out of it if you can give me a hint where to look
<mdz> for some reason it's looking at toplevel for config.status, rather than in obj
<Clint> ew
<Clint> though that makes no sense
<mdz> it's the mkmakemod.sh target in Src/Makefile
<mdz> mkmakemod.sh: $(dir_top)/config.status mkmakemod.sh.in
<mdz>         $(dir_top)/../config.status
<mdz> mkmakemod.sh.in: mkmakemod.sh.in.in
<mdz>         $(dir_top)/../config.status
<mdz> which makes no sense at all
<mdz> it pretty much explicitly tries to go to the parent dir of where it's supposed to be
<mdz> that bit of code is the same in 4.2.4-1, interestingly enough
<Clint> yeah, I just keep star-merging it along
<Clint> it's gruesome
<mdz> I seem to break timestampish things sometimes by building on a tmpfs
<lifeless> Clint: baz probs ?
<mdz> which is where I generally build stuff, unless it's like, X or oo.o
<Clint> lifeless: well, I can't use baz on that archive
<lifeless> Clint: why not ?
<Clint> lifeless: if I use a revision-library, it chokes to death consistently, and if I don't, it fails in weird and erratic wys
<Clint> er, ways
<lifeless> Clint: thats weird - I'd love to fix that. are you able to spend some time with me identifying the cause ?
* netjoined: irc.freenode.net -> orwell.freenode.net
<mdz> gah, it's re-running autoconf during the build
<mdz> that at least I can fix
<Clint> aha!
<Clint> lifeless: http://bugs.debian.org/297756 describes the reproducible problem
<mdz> though I have no idea why that breaks it
<Clint> lifeless: let me know what else you want me to do
<Clint> it probably touches something that isn't supposed to be touched
<lifeless> Clint: whats the url for the archive
<mdz> wait
<mdz> wtf was autoconf doing in the chroot?
<mdz> zsh build-deps on autoconf, growl
<Clint> lifeless: http://arch.debian.org/arch/pkg-zsh/current/
<Clint> what the?!
<mdz> LAMONT!!!
<lifeless> Clint: ok, reproduced
<lamont> mdz: well, it fixed the build the last time...
<lifeless> Clint: does it work with tla ?
<mdz>   * Build-Depend: autoconf
<mdz>  -- LaMont Jones <lamont@canonical.com>  Fri, 26 Nov 2004 17:36:02 -0700
<Clint> lifeless: nope, same annoying crap
<Clint> lifeless: less wordy though
<lifeless> Clint: ah. betchya its a fuxked tarball
<Clint> any quick fix?
<lamont> have I mentioned how it's bad to patch files that are built from other files?
<Clint> ain't none of my packages meant to be autoreconf'd
<mdz> it's fine as long as the build process doesn't try to magically generated them
<lifeless> the fucker
<lamont> right.
<lifeless> sorry but someone has 'edited' the archive.
<lamont> mdz: and the file in question when I added autoconf was deep in a twisty maze
<lifeless> its corrupt and must be discarded or manually repaired.
<lifeless> Clint: if you look in the tarball, you'll see that it has a patch log for "\{arch\}/zsh/zsh--upstream/zsh--upstream--4.1.1/schizo\@debian.org--2004--pkg-zsh/patch-log/base-0"
<Clint> how do I figure out what needs repairing?
<schweeb> is there a non-ubuntuized kernel source package?  I'm trying to modify some debian Xen packages to work, but doesn't look like there's a vanilla pkg... should I back out the ubuntu patches, or am I wrong?
<mdz> lamont: are you saying that regenerating autoconf during the build was intentional?
<mdz> rather than working around the fact that the build wanted to do it?
<lifeless> what this means is that the archive /really is/ schizo\@debian.org--2004--pkg-zsh and the branch really is zsh--upstream--4.1.1
<Clint> lifeless: so I should remove it?
<lifeless> someone has edited the 'name' meta-info file.
<mdz> http://people.ubuntu.com/~scott/ongoing-merge/zsh/zsh_ubuntu.debdiff
<Clint> ugh
<mdz> looks pretty innocent
<lifeless> now the question is - are the later commits to the same archive *also* for schizo\@debian.org--2004--pkg-zsh ?
<lifeless> if they ALL ARE. then its easy: put the name back were it should be.
<Clint> lifeless: no
<lifeless> if there are mixed commits, then you need to:
<lifeless> 1) decide on the archive name
<lifeless> 2) unpack the base-0 and edit the log, and all metadata to be what you want it to be
<lifeless> 3) repack it
<lamont> lifeless: please note.  I've never done anything this evil to arch. :-)
<lifeless> 4) repeat on every changeset after that.
<mdz> schweeb: there is an Ubuntu package, a Debian package, and a vanilla tarball from upstream; they are all distinct
<Clint> lifeless: great, thanks
<lifeless> goerzen wrote a shell script to do this. I don't know how robust it is.
<lifeless> you'll then need to find every mirror of the archive in existence and get them to zap them selves and start over.
<lifeless> whoever edited 'name' should be tied up and whipped. right after the designer of a non-self-documenting archive format susceptible to this.
<mdz> lamont: let me know if ubuntu15 does better
<lifeless> after you fix this, it should work just fine.
<lamont> mdz: wilco
<mdz> lamont: I mean 15ubuntu4
<lifeless> Clint: also, be sure to nuke ~/.arch-cache/archives/zsh\@packages.debian.org--pkg-zsh
<lamont> right
<lifeless> Clint: talk to lamont about what to nuke when you change history ;)
<lamont> Preconfiguring packages ...
<lamont> gcc-opt: Failed to open /CurrentlyBuilding
<lifeless> '/' ?
<lamont> do I want to know why preconfiguring packages runs the compiler????
<lamont> lifeless: heh
<lifeless> lamont: one reason I like arch's archive format is that rcs scripts are harmless
<lamont> LOL
<lifeless> ;)
<mdz> lamont: dpkg-architecture?
<lamont> ah, ok
<lamont> amazing the things one trips over.. :-)
<zenwhen> oh crap
<zenwhen> that guy is doing backports for hoary already
<zenwhen> http://ubuntuforums.org/showthread.php?t=20044
<lamont> zenwhen: heh
<lamont> sigh
<lamont> well, I mean, UVF was like so 2.5 months ago
<zenwhen> yeah
<zenwhen> I was already bitten by that backports deal once
<zenwhen> I am not convinced he wont screw it up again
<lamont> zenwhen: there's no reason to run backports.  honestly.
<lamont> well, ok.  people have reasons
<mroth> whoops
<zenwhen> Things like Firefox and Gaim that have regular releases are what cause people to use backports.
<mroth> lamont: well admittedly, FF being so high profile, there are going to be a lot of people freaking out if its not the most "bleeding edge"
<zenwhen> regular and highly touted releases
<mroth> esp. since slashdot has scared half of them into thinking that its an "important security release!"
<Clint> lifeless: thanks, looks like that worked
<mroth> (not to suggest that its wasnt a security problem, but its the type of security problem that only affects people who click stupid links in their email)
<zenwhen> my only issue with firefox is how crappy the left side of the left mst tab loks sometimes
<zenwhen> lol
<jdub> "It's only a security issue if you're stupid. Are you stupid?"
<zenwhen> lol
<zenrox> lol
<Keybuk> jdub: "special"
<jdub> (not that i necessarily believe that, for the problem in question, but anyway)
<lamont> 53 binaries in hoary/desktop taht are suid and/or sgid
<jdub> half of those are gnome-games, right? :)
<Keybuk> yeah, it's about time sudo wasn't setuid root
<lamont> lol
<mroth> jdub: is it going to be possible to get FF1.0.1 into hoary?  it might be a good idea as a "public relations" move, since I bet otherwise every single review will mention it.
<lamont> -rwsr-sr-x  1 root    root      7664 2005-03-02 07:03 ./usr/X11R6/bin/X
<jdub> mroth: thom's dropping that in this week, i believe
<lamont> wth?
<lamont> :-)
<jdub> Keybuk: BRING IN THE DEROOTIFIER
<mroth> jdub: good to hear
<Keybuk> /SUMMON pitty
<Keybuk> pitti too
<jdub> not that we make technical decisions base on "public relations"
<Keybuk> oops
<jdub> Keybuk: freudian slip
<Keybuk> *cough* ooo2.0 *uncough*
<jdub> *cough* exactly *uncough*
<jdub> ;)
<mdz> lamont: please file a bug about that
<lamont> mdz: OK
<zenwhen> Myself, being smart enough not to click links in emails, am fine with firefox 1.0.
<mdz> has anyone seen daniels?
<jdub> mdz: want me to call?
<lifeless> Clint: cool
<mdz> jdub: please
<lifeless> Clint: anything you have baz problems on .. just ask ;)
<lamont> -r-sr-xr-x  1 root   root     15000 Oct 26 14:40 ./sbin/unix_chkpwd
<lamont> interesting
<zenwhen> but I am not smart enough right now to us eproper grammer
<zenwhen> ;)
<mdz> lamont: the fact that it's exactly 15000 bytes?
<lamont> yeah
<Clint> lifeless: will do
<mdz> lamont: 14936 on Warty if it makes you more comfortable :-)
<lamont> jdub: 11 of them are sgid games
<zenwhen> I am passing out some preview live and install disks at work tomorrow.
<zenwhen> well not preview. they are from yesterday.
<lamont> mdz: fwiw, X was suid/sgid root on warty, too
<lamont> 2 new suid binaries, one of them a hardlink to sudo
<lamont> the other being hal-dmiwrapper
<mdz> lamont: interesting; I wonder why pitti didn't flag it
<mdz> I know of no reason it should be sgid
<lifeless> can we get screen suid ? its like every time I do pair programming, the first thing is 'make screen suid'
<lifeless> (don't you love randoms like me) ?
<lamont> mdz: especially when it's suid root
<lamont> -rwxr-sr-x  1 root   utmp     297080 Feb 28 15:23 ./usr/bin/screen
<lamont> lifeless: that's what you get
<mdz> lifeless: I'm not sure that suid is required in order to do multiuser
<mdz> it shouldn't be...
* lamont is proud that pmount went from 4750 to 4754
<lamont> we should not be ashamed of our code. :-)
<lifeless> lamont: cool.
<lamont> mdz -15ubuntu4 has no love
<lifeless> mdz: it is required
<lamont> make[4] : Entering directory `/build/buildd/zsh-4.2.1/obj/Src/Modules'
<lamont> Makefile:406: cap.rules: No such file or directory
<lamont> Makefile:1327: pcre.rules: No such file or directory
<lifeless> mdz: the vty it allocates needs to be accessible by all the authorised users.
<lamont> cd ../../../Src/Modules && autoconf pcre.configure.ac >pcre.configure
<lamont> /bin/sh: autoconf: command not found
<lamont> make[4] : *** [../../../Src/Modules/pcre.configure]  Error 127
<mdz> lamont: it really ought to be using a socket rather than a pty
<lamont> screen?
<lamont> oh, X.
<mdz> lamont: screen
<mdz> for communication between users
<lamont> ah, ok
<lamont> mdz: where do you want the suid-diff emailed to?
<mdz> lamont: security-review
<lamont> @u.c?
<mdz> @lists.ubuntu.com
<lamont> mdz: sent
<jdub> ha ha
<jdub> "Don't worry; even if we upgrade to the new version, it still has remote root vulnerabilities in it."
<jdub> ^ mdz doing his slightly verbose bobby mcferrin impression
<lamont> jdub: lol
<lamont> mdz: msg awaits the moderator..
<tritium> Hi elmo.
<lamont> wb elmo
<mdz> lamont: please file a bug about the zsh thing; I can't focus on it tonight
<lamont> ok
<elmo> hi tritium, lamont
<lamont> mdz: and should I just assign it to me? :-)
<mdz> lamont: I fixed half of it; I'll finish the job tomorrow
<mdz> just don't want to forget
<lamont> right
<mdz> I'm too tired to figure out wtf Src/Modules/Makefile comes from
<lamont> will assign to you then
<lamont> mdz: so was I when I got done with it... :)
<lamont> and I apologize. :(
<lamont> 7672
<eruin> who fixed the nb locale? :) I love you!
<tritium> elmo, I sent emails to keyring and upload.  May I inquire about the status of my request, if you have a spare moment?
<elmo> tritium: when/where did you send them?
<elmo> wasabi: ?
<tritium> elmo, yesterday evening
<tritium> elmo, from rimbert@purdue.edu
<elmo> tritium: ok - that was a sunday evening for  me, and I've just got back online after some hardware problems.  I'll process you as soon as I've caught up
<tritium> elmo, no problem.  Thank you.  I know you're busy, so I appreciate your time.
<wasabi> elmo, 
<wasabi> ?
<elmo> wasabi: jsch FTBFS
<wasabi> on i386?
<wasabi> coulda sworn i pbuildered it
<elmo> amd64 actually - not sure it matters tho, doesn't look arch specific
<elmo> http://people.ubuntu.com/~james/paste/jsch.txt
<wasabi> 404
* lamont screams, adds 'wired mouse' to his shopping list for tomorrow
<lamont> 2 wireless mice in one house is a bad thing...
<wasabi> you fell for the wireless trick
* wasabi giggle.
<tritium> they need CDMA wireless mice ;)
* wasabi just pbuilds jsch fine
<elmo> wasabi: again
<wasabi> hmmmm
<wasabi> does /usr/share/ant1.6 exist for you?
<elmo> wasabi: http://people.ubuntu.com/~james/paste/jsch2.txt
<wasabi> is /usr/share/ant1.6/lib/ant.jar readable? that is the check that is failing
<wasabi> if ! test -r "$(ANT_HOME)/lib/ant.jar"
<elmo> -rw-r--r--  1 root root 914084 Oct 26 17:50 ant.jar
<wasabi> well what the heck
<elmo> ANT_HOME        := /usr/share/ant
<elmo>  ?
<elmo> that's in debian/rules
<wasabi> eh... mine has 1.6.
* wasabi digs.
<elmo> this is 0.1.19-1ubuntu1 which is what's in queue/NEW atm
<wasabi> hmm. i have ubuntu2. let me go figure out what i did last night.
<elmo> jsch_0.1.19-1ubuntu2_source.changes
<elmo> REJECT
<elmo> Rejected: jsch_0.1.19.orig.tar.gz file already exists in the New directory.
<wasabi> that would know it out?
<wasabi> knock
<elmo> unfortunately yes - katie's not smart enough to detect they're the same file if it's in NEW
<elmo> just upload without -sa and you'll be good
<wasabi> hey. bit embarressing. can you send me what's in New right now? :)
<elmo> heh
<elmo> wasabi: put them in http://people.ubuntu.com/~james/paste/
<jdub> elmo: planet sync please :)
<wasabi> 403
<elmo> meh
<elmo> wasabi: fixed
<wasabi> thx.
<elmo> jdub: done
<jdub> thanks
<wasabi> elmo, done.
<elmo> dear god, that's ugly compiler output
<wasabi> =)
<wasabi> I searched high and low but couldn't figure out how to disable warnings in ECJ
<elmo> --stfu didn't work?
<elmo> ;)
<wasabi> Someday I will either figure it out, or implement -nowarn
<mdz> -nowarn?
<wasabi> ...
<wasabi> oh yes, it's being called from Ant, not from the command line
<wasabi> that's why it wouldn't work
<wasabi> gave me a heartattack there
<lifeless> oh Clint - care to close that bug ? :)
<lamont> jdub?
<jdub> yo!
<lamont> can I have kernel-bugs@lists.ubuntu.com, me as admin?  and can we point bz at that instead of kernel-team?
<lamont> since that's 99.44% of the list traffic, and we're just not that pure
<jdub> haha
<jdub> i thought you might ask for that soon ;)
<lamont> GRRR
<jdub> give me a minute
<mdz> lamont++
<jdub> lamont: http://lists.ubuntu.com/mailman/admin/kernel-bugs
<jdub> lamont: same pw as kernel-team, please add description/summary and make the list public when you're happy with it
<lamont> woot
<lamont> jdub: you mean same password as _you_ gave kernel-team...
<lamont> hrm,
<jdub> lamont: hmm, should be password you changed it to
<jdub> lamont: let me know if not :)
<lamont> hrm...
<fabbione> morning
<lamont> jdub: either I can't type, or it's not the same
<elmo> ok, if we release with this bloody gaim doesn't get to pop-up windows, I'm switching back to Debian :-P
<elmo> (or something else old enough not to manifest it)
<mdz> elmo: then they could go back to making you out to be the antichrist, instead of Ubuntu
<cc> does anyone know where theres a DEB archive of the Flash player from Macromedia ?
<Treenaks> cc: yes
<Treenaks> cc: but you can also just click the "puzzle" icon in firefox to install it automagicallt
<Treenaks> y
<crimsun> cc: flashplugin-nonfree
<cc> crimsun: ok, thanks
<eruin> can I speak to anyone about the dma settings in linux-image here?
<eruin> I've had to compile my own kernel to set dma on for my standard ide hd/cd drives, and while doing so I noticed the ubuntu config had "CONFIG_IDEDMA_ONLYDISK=y"
<fabbione> eruin: -> #ubuntu-kernel
<eruin> thanks
* OddAbe19 is back (gone 24:05:59)
* OddAbe19 is away: Gone... Like the French in a battle.
<toresbe> that's just lame
<fabbione> morning sabdfl 
<fabbione> how is swiss? ;)
<sabdfl> fabbione: the matterhorn is incredible
<sabdfl> it's like some alien beacon
<fabbione> ehehe
<fabbione> sabdfl: do you have any pic to show us? ;)
<elmo> Mithrandir: ?
<elmo> Mithrandir: why does mcelog not have an ubuntu version number if it's changed?  if it's unchanged, why is it not a sync?
<Mithrandir> elmo: it's not changed.
<Mithrandir> elmo: it's from NEW
<Mithrandir> elmo: I was told to do it this way by mdz.
<elmo> pfft
<Mithrandir> if I can ask you to grab stuff from Debian's NEW, that's fine with me.
<Mithrandir> but I thought you didn't want to mix hats like that.
<elmo> hang on - how did you get it out of NEW?
<lifeless> I was waiting for that ;)
<Mithrandir> elmo: I asked the maintainer.
<elmo> pfft
<Mithrandir> elmo: if you want a different process, that's fine with me, I just did what mdz told me.  :)
<elmo> pfft
<elmo> ;)
* Mithrandir gives elmo a cup of tea.
<Mithrandir> and yes, I did vet the source and yes, I am trusting the developer who uploaded it to have given me the same source as he uploaded to NEW.
<dholbach> goood morning
<doko> mdz, jdub: gcc-3.4 builds finished on i386, powerpc, amd64, built firefox and grub on am64, still works for, ok to update (needed for the OOo2 build)?
<mvo> ping jordi 
<dholbach> hi mvo
<mvo> hey dholbach 
<jordi> mvo: pong
<fabbione> hey pitti
<pitti> Morning
<dholbach> hai pitti
<mvo> jordi: what's the status of utf-8 and nano? we won't get it before 1.4?
<fabbione> pitti: http://people.ubuntu.com/~fabbione/changelog
<jordi> mvo: no.
<jordi> mvo: HEAD should be more or less there, I believe
<jordi> but not yet releasable.
<jordi> mvo: if Ubuntu is going to switch editors because of this, it could be enough pressure for the feature to be completed :)
<pitti> fabbione: wow! nice work
<fabbione> pitti: this is going in later today
<fabbione> pitti: note that the debian security stuff (without CAN) is in the merge log
<Mithrandir> fabbione: you are insane. :)
<pitti> fabbione: this already contains all protentially security relevant patches you mentioned?
<mvo> jordi: I'm tempted to ask for a switch because of this 
<pitti> ah, ok
<fabbione> pitti: yes
<fabbione> Mithrandir: really?
<jordi> mvo: ugh. dude
<Mithrandir> fabbione: yeah.  In a good way.
<fabbione> Mithrandir: i have never noticed it :P
<mvo> jordi: seriously, it's a problem
<jordi> I know, I know
<jordi> it wasn't before with latin1 as default.
<mvo> no patches floating around or something (/me hopes)
<jordi> let me ping the nano list and David.
<jordi> mvo: you've only tried with 1.2, right?
<mvo> jordi: that would be very kind. 
<mvo> yes, I only tried 1.2
<jordi> the current 1.3 in experimental should be pretty unusable, but there's a patch to fix it a bit.
<jordi> mvo: ok. let me see what I find.
<mvo> it's 1.3.5?
<mvo> in experimental?
<jordi> hmm, there's commits in cvs.
<jordi> - UTF-8 support. [DONE except for edit window text wrapping, help window
<jordi>   text wrapping, and the NO_CONVERT flag.] 
<jordi> mvo: want me to cook a quick deb based on HEAD?
<mvo> sounds pretty good
<mvo> jordi: let's what what upstream says first, ok?
<jordi> mvo: yah.
<jordi> creating a deb would take 2 mins tho
<mvo> hehe
<mvo> feel free (if it really takes only 2 minutes) :)
* jordi reautogens. :)
* smurfix reads fabio's changelog and is speechless
<jordi> yeah, it's quite impressive.
<jordi> Fabio the Great
<toresbe> what worries me is that you are severely failing to feel sorry for me
<toresbe> seeing how i'm sick today
<jordi> mvo: so this is for hoary?
<Mithrandir> toresbe: aren't you always sick [by caring that much about so many weird architectures] ?
<toresbe> Mithrandir: well, I'm always mentally sick
<toresbe> Mithrandir: but I have a very soar throat
<toresbe> It hurts to breathe
<Mithrandir> I was about to suggest stop, but I guess that's not a good idea
<toresbe> hehe
<mvo> jordi: yes, hoary
<mvo> is there something like pythons os.path.normpath() for the shell?
<Treenaks> mvo: basename?
<mvo> Treenaks: not quite what I want. I want a nice path afterwards even if I feed it with "/lala//lu/x//" -> "/lala/lu/x"
<pitti> mvo: try readlink -f
<pitti> mvo: oh no, you need a real file for this
<mvo> pitti: yes :/
<mvo> how do other people deal with building a path from e.g. "$dir/$subdir/$subsub" if the user can specify each of the vars and some will add a trailing "/" ? just ignore that there may be the double "//"?
<Mithrandir> mvo: remove the trailing /, if you care?
<Treenaks> s#//#/#g ?
<Mithrandir> mvo: var=${var%/}
<pitti> Treenaks: you need to do this recursively
<Treenaks> pitti: hmm. yes
<mvo> Mithrandir: this will "/var/lib" -> "/var"? but in this case everything is fine and I don't want the path to change. 
<Mithrandir> mvo: it will change /var/lib/ to /var/lib
<pitti> mvo: why does it hurt in the first place?
<Mithrandir> it won't change /var/lib
<mvo> Mithrandir: oh, right
<Mithrandir> : tfheen@shonap ~ > foo=/var/lib
<Mithrandir> : tfheen@shonap ~ > echo ${foo%/}
<Mithrandir> /var/lib
<Mithrandir> : tfheen@shonap ~ > foo=/var/lib/
<Mithrandir> : tfheen@shonap ~ > echo ${foo%/}
<Mithrandir> /var/lib
<mvo> pitti: it does not really hurt, it just does not look nice and I wanted to know how others deal with it and if there is something I missed
<pitti> mvo: if it's a real file, I use readlink -f
<mvo> Mithrandir: thanks
<Kamion> Mithrandir: you don't need to trust the maintainer, .changes files in NEW are readable by developers and have the md5sums :)
<svenl> daniels: mmm, what did you do to the bug report ? I didn't get it.
<svenl> Kamion: did you have any chance to look at the pegasos yaboot-installer issue ? Or even managed to flash the machine ? 
<daniels> svenl: just changed the status from NEW (i.e. untouched) to ASSIGNED (meaning that I'll work on it)
<Mithrandir> Kamion: true, I forgot about that.
<Kamion> svenl: as I said to you, I flashed the machine but then ran into the yaboot-doesn't-boot-from-CD bug; I saw your comment yesterday that yaboot/netboot works fine, so I'm going to try that today
<jordi> mvo: is UTF-8 support necessary for the udeb?
<jordi> mvo: if so, I need to make changes to the packaging, as nano udeb uses SLang
<mvo> jordi: Kamion knowns that better than I do, but I think it is not needed for the udeb (at least not for your testing deb)
<jordi> ok
<jordi> completely untested debs uploading to people.debian.org/~jordi/
<jordi> mvo: initial testing shows some propblems with scrolling
<jordi> but display is good.
<jordi> I'll talk to david. Shouldn't take long to make it good.
<mvo> jordi: thanks, just downloaded
<Kamion> uh
<Kamion> UTF-8 support would be really handy for the udeb; the installer is UTF-8 throughout
<jordi> Kamion: does ubuntu use nano at all during the install?
<mvo> jordi: hrm, it does not let me edit some german umlauts
<jordi> I guess in expert mode it does
<Kamion> but be a bit careful, there's scary libslang-pic packaging there to do with how the initrd is built
<jordi> mvo: what do you mean with edit?
<Kamion> jordi: nothing to do with expert mode, you can switch to tty2 and use nano
<jordi> I can insert accents and  or whatever.
<jordi> Kamion: nod
<jordi> Kamion: I can link the udeb with ncursesw or ncurses if it's enough.
<Kamion> so currently, debian-installer build-depends on slang1-utf8-pic
<jordi> does anything else use ncursesw?
<Mithrandir> daniels (or any other .au-ians): what's a reasonable .au airline?
<Kamion> is that enough?
<jordi> Kamion: according to configure, nope, but I can check more carefully.
<mvo> jordi: when I try to enter certain charackters that are fine in the gnome-terminal and vim (like  <- capital)
<Kamion> jordi: a new dependency on ncursesw? we'd need to figure out scary library reduction stuff for that
<thom> Mithrandir: internal only? virgin blue or qantas are the two i've used
<jordi> Kamion: if it's not in ubuntu's base system we can look if ncurses is enough
<Mithrandir> thom: yeah, from Sydney to Canberra for LCA
<jordi> mvo: there's a flagrant byte vs char issue here.
<Kamion> jordi: no, it's not that; there's no libncurses*-pic so AFAIK library reduction won't work properly; and the contents of Ubuntu's base system are almost entirely irrelevant to what you can assume in the installer
<Kamion> jordi: I think for hoary maybe best just leave UTF-8 support out of the udeb, we can figure this sort of stuff out later
<jordi> Kamion: ok.
<jordi> this will be a lot easier once nano 1.4.0 is released I hope.
<daniels> Mithrandir: virginblue.com.au are cheap, qantas.com.au are good (and better if you're connecting from an international flight)
<jordi> I'll ping Daniel to see what needs to be done.
<jordi> Kamion: is it common to find non-ASCII files when installing?
<daniels> Mithrandir: but Qantas are your only option since Virgin don't fly out of Canberra
<jordi> I guess the autogenerated fstab might have.
<dholbach> hi elmo, could you please sync  mindi mondo (both fix an issue reported on the mailing list)  fuse (needed for gmailfs transition)  asc (new one shouldn't have unmet build-deps anymore)  rox-filer conglomerate afterstep (quite a lot of bugfixes) and  fluxbox (security issues)  from sid, pretty please
<Mithrandir> daniels: ok, thanks.
<Mithrandir> I _hate_ airline booking systems.  They all suck.
<thom> Mithrandir: yes.
<d3vic3> Mithrandir, I tend to agree
<Mithrandir> I'm amazed that they manage to suck in more or less the same way.  All of them.
<jordi> ok, nano-tiny with slang has bad utf-8 issues
<pitti> daniels: here?
<svenl> Kamion: ah, yes, sorry, forgot about that.
<svenl> Kamion: anything i can do for that ? 
<Mithrandir> the qantas site wasn't _that_ bad.
<Kamion> jordi: I was trying to edit UTF-8 files with nano-udeb just yesterday ;)
<Kamion> jordi: not sure I'd call it "common" though
* daniels looks at pitti, SSHes to chinstrap.
<pitti> daniels: :-)
<Mithrandir> Kamion: I think you're a fairly special use-case. :P
<pitti> Hi seb128 
<Kamion> svenl: well, you're already looking at yaboot-from-CD, so apart from that I'll let you know once I get it netbooted :)
<elmo> [NOT Updating - Modified]  conglomerate_0.7.16-1ubuntu1 (vs 0.9.0-1)
<elmo> [NOT Updating - Modified]  fuse_1.3-1ubuntu1 (vs 2.2.1-1)
<elmo> dholbach: ok to override?
<Kamion> in the meantime, time for a DVD test ...
<jordi> Kamion: I see. :)
<seb128> hey pitti 
<dholbach> elmo: conglomerate yes
<dholbach> elmo: will have to check fuse first
<Kamion> jordi: (specifically I was testing UTF-8 names in /etc/passwd)
<seb128> hey elmo 
<dholbach> hi seb128 
<seb128> elmo: openh323 / pwlib / gnomemeeting sync please :)
<Kamion> hmmmmm. initial DVD boot not so pretty.
<seb128> Hi dholbach 
<elmo> [NOT Updating - Modified]  gnomemeeting_1.2.0-2ubuntu2 (vs 1.2.1-1)
<svenl> Kamion: ok.
<elmo> seb128: k-to-override?
<seb128> sec
<seb128> hum
<seb128> I'll merge it, thanks for noticing
<seb128> but I need pwlib and openh323 for that
<seb128> just pwlib and openh323, thanks
<elmo> seb128: done
<seb128> thank you
<dholbach> elmo: fuse will take me some time
<dholbach> elmo: thank you :-)
<elmo> dholbach: ok, done all but fuse
<dholbach> elmo: you rock! thanks a lot :-)
<fabbione> fuse has some fixes to be able to build with our kenrels
<fabbione> and the kernel-image/linux-image changes
<fabbione> that's whay i did basically
<dholbach> fabbione: thanks... i'll check the debdiff of the last two versions
<dholbach> fabbione: an merge manually
<pitti> elmo: can you please remove mozilla-firefox-locale-{fr,tr} ?
<Kamion> whoa, a DVD+RW shows up in parted as writable, so the partitioner offers you the chance to erase it. :)
* seb128 slaps pitti
<pitti> seb128: who needs french anyway? :-)
* seb128 slaps pitti again :p
<pitti> seb128: no, seriously, we already have -fr-fr from m-f-locale-all
<seb128> bah, the question is rather
<dholbach> pitti: we have http://wiki.ubuntu.com/MorgueCandidates for that :-)
<seb128> who needs firefox ? :p
<thom> seb128: uh, you do?
<seb128> right
<seb128> who needs firefox translations ? :p
<svenl> Kamion: is todays daily ubuntu installer supposed to work ?
<thom> seb128: ... especially french ones? :p
* pitti tests new warty kernel, brb
<pitti> thom: ... which nobody understands anyway :-)
<seb128> rooh
<jdub> ha ha
<jdub> oh man
<Treenaks> ?
<jdub> dholbach: is nicole your girlfriend? :)
<dholbach> jdub: hahaaaahaaa, she really sent that mail.... she's my ex-girlfriend :-)
* dholbach can't believe it 
<dholbach> :-)
<jdub> she obviously still thinks highly of you ;)
<dholbach> jdub: i think highly of her too
* thom wonders how many more times people are gonna claim that having a root password is more secure than having locked root when the attacker has physical access
<Kamion> svenl: I haven't tried it yet
<svenl> Kamion: seems to work, two days ago there where modules problems, but maybe i miscopied the vmlinux or something.
<Kamion> svenl: I'm not aware of problems today, although we're about to do another kernel ABI change so it's possible those sneaked in before the CD build or something
<svenl> Kamion: mmm, any chance to get the gigabit ethernet driver fix in for the this new kernel ? 
<Kamion> svenl: -> fabbione
<fabbione> svenl: if you have the patch handy yes
<fabbione> but you have like.. 10 minutes to give it to me
<fabbione> nothing against the fix but i need to start the build orgy prior upload
<Kamion> grr, why does the DVD install want the CD in the second stage?
<Kamion> er, the DVD, rather
<svenl> Ok.
<fabbione> wrong hack in archive-copier?
<Kamion> dunno, it seemed to do its job OK
<svenl> fabbione: get powerpc-mv643xx-enet.dpatch from the debian svn repo, this one went upstream for 2.6.12.
<fabbione> svenl: from 2.6.10 or 2.6.11?
<fabbione> and is it the only one required?
<fabbione> does it build on 2.6.10?
<Kamion> hmm; it wants gs-gpl.deb
* Kamion suspects subtly broken dependencies
<Kamion> oh, and gs.deb
<svenl> from 2.6.10
<svenl> err, 2.6.11
<thom> jdub: you can't have industrial firefox; we're shipping http://people.zeelandnet.nl/marco/pimpzilla/images/pimpzilla.jpg
<svenl> let me check.
<jdub> is that the one with the torn paper?
<svenl> well, it builds, but the i need to check if the patch applies cleanly.
<jdub> oh yeah, that one
<svenl> fabbione: then get http://people.debian.org/~luther/powerpc-mv643xx-eth-pegasos.dpatch
<thom> "upimpu"
<Treenaks> pimpbuntu
<doko> jdub, kamion, mdz: any word on the gcc-3.4 upload, or did I miss your approval? diff on chinstrap:~doko/gcc-3.4.diff
<pitti> daniels: you set #7558 (libxpm4) to pending, do you also have warty packages?
<jdub> doko: i'll leave that one to mdz
<fabbione> svenl: is the patch on people enough or do i need both?
<svenl> fabbione: the patch is split.
<svenl> fabbione: powerpc-mv643xx-enet.dpatch is the arch-indep drivers patch that went upstream via dale fornsworth, while the one on p.d.o is the pegasos specific initialization part.
<daniels> pitti: not right now, but I'm going to make them up later tonight
<pitti> ah, ok
<svenl> fabbione: can you quickly check if it applies, if not let's wait for another time, there is no way i can test this locally in the next 10 minutes, i don't have the source tarball for 2.6.10 here.
<fabbione> ok
<svenl> fabbione: and no ubuntu chroot or such.
<fabbione> testing now
<svenl> fabbione: also, what about adding the mkvmlinuz support script ?
<fabbione> svenl: one thing at a time please
<svenl> fabbione: ok.
<fabbione> i already have enouhg stuff boiling on my desktop
<svenl> fabbione: ok, no problem, just asking, altough the mkvmlinuz support is just to copy one file to kernel-source/debian prior to make-kpkg kernel-image, but this can wait for later.
<fabbione> svenl: just a second please.. i can even add it, but i need to focus on it...
<fabbione> jusst gimme a few secs
<svenl> fabbione: no problem.
<fabbione> svenl: it applies... but noidea if 1) compiles 2) works
<fabbione> what is the patch supposed to do? fix the driver? or is it just an enanchment?
<mvo> ping jdub
<Mithrandir> elmo: sorry to nag you, but could you un-PaS ooo-amd64 for ia64 and tvtime for amd64?
<fabbione> svenl: ok we will keep this changes for the next upoad (given that they won't destroy the ABI)
<elmo> Mithrandir: done
<Mithrandir> elmo: thanks a lot
<Mithrandir> Kamion: ooo-amd64 should be a happy badger on ia64 now.
* aj marvels that what mithrandir just said could possibly make any sense
<daniels> aj: badgerbadgerbadgerbadger
<Kamion> hooray, thanks
<elmo> aj: it should really be called ooo-32bitlibsfor64bitarches
<elmo> or something
<Kamion> ooo-EVIL
<Kamion> damn, no caps in package names
<daniels> either that, or just assume that it's because the ia64 really wants to be an amd64 when it grows up
<aj> daniels: oo, bendy?
<Mithrandir> ooo-3v17
<daniels> aj: grumble
<Mithrandir> daniels: *chuckle*
<aj> hrm
<daniels> ooo-thispackageistollefsfaultblamehim
<aj> maybe that could be the t-shirt prize at this lca, pick a name for ubuntu's next release
<Treenaks> daniels: ooo-izgtkboog
<jordi> daniels: I like this one.
<jordi> Treenaks: in the end, it's thom's fault.
<Treenaks> jordi: as always
* elmo glares at aj
* Mithrandir multiarchifies daniels
<aj> elmo: yes, you're right, mail to mark is the way to suggest this, not mentioning it on irc!
<svenl> fabbione: fix the driver, ok for the next upload, any idea when it will be ? 
<jdub> mvo: pong
<fabbione> svenl: not really... but i can start testing immediatly after this upload
<svenl> fabbione: ok.
<fabbione> svenl: i have the patches here.. if you update them, please let me know
<svenl> fabbione: i will let you know.
<svenl> fabbione: what about mkvmlinuz stuff ?
<fabbione> svenl: let's make it for the next upload too
<fabbione> so we can test everything
<fabbione> it makes me feel unconfortable to make changes now that i have been nuilding this kernel for 5 days
<fabbione> s/nuilding/building
<fabbione> svenl: if the changes are ok (no ABI breakage) i can upload the next kernel even tomorrow
<fabbione> that's not a problem
<fabbione> but i can't spend too much time today on it
<Treenaks> fabbione: have a look at #7651 as well then (microscopic fix for a panic)
<fabbione> Treenaks: please remind me later or tomorrow
<Treenaks> fabbione: ok
<svenl> fabbione: ok, fine with me.
<svenl> fabbione: the changes are not touching the ABI, to my knolwedge, but please check.
<fabbione> svenl: yes i will
<jordi> do you guys expect sabdl to come to IRC sometime this morning?
<jordi> sabdfl, even
<fabbione> jordi: he was here this mornign
<jordi> fabbione: bah, missed him then
<fabbione> Kamion: are you still around?
<fabbione> i forgot to ask you something...
<fabbione> Kamion:
<fabbione>   * Fix hppa FTBFS:
<fabbione>     - Remove debian/d-i/hppa/modules/hppa/nfs-modules.lnk since all nfs is
<fabbione>       compiled in.
<fabbione> do i need to make kernel-image Provides: nfs-modules?
<dholbach> seb128: openh323 seems to deserve a kick, because it depended on newly built pwlib, or am i wrong?
<seb128> dholbach: lemme me check, you are reading the build logs every 5 min or what ? :)
<seb128> dholbach: are you sure it's not in dep-wait ?
<dholbach> seb128: it didnt build first, but now it seems to be alright
<seb128> k
<dholbach> seb128: i'm waiting for them to build, to get  t38modem ohphone asterisk openam openmcu gnugk  synced ;-)
<sladen> Kamion: what's your take on a simplied ''bash completions'' one that just handles sudo/su re-handoff
* fabbione -> shower -> food
* sladen is relieved to find that fabbione washes
<fabbione> sladen: yeah... once a year
<fabbione> you are lucky that UDU is pretty soon ;)
<d3vic3> lol 
* d3vic3 makes note not to share rooms with fabbione 
<pitti> d3vic3: why, he will never block the shower :-)
<d3vic3> pitti, heh, thats the problem 
<pitti> gosh, bugzilla sucks through a slow link
<daniels>   2005-03-15 Alan Hourihane <alanh@fairlite.demon.co.uk>
<daniels>         * programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c
<daniels>         * programs/Xserver/hw/xfree86/drivers/i810/i830_modes.c
<daniels>         Enforce DDC monitor ranges usage if we have them and reject bad
<daniels>         modes. Use NoDDC option to override DDC timings. We currently
<daniels>         only use DS_RANGES, but could use other DDC information, as does
<daniels>         the common layer, to deduce the h/v ranges.
<sladen> pitti: that'll be the SSL
<daniels> HHHHUUUULLLLKKKKK SSSSMMMMMAAASSSSSHHHHHH
<pitti> sladen: I rather think it might be the huuuuuge package list that is delivered with each page?
<daniels> 'we could actually make this driver halfway useful.  but we're not.'
<sladen> pitti: oh yes, that too.  that could really do with being switched to a Google-suggest RPC requestion leetness
<thom> sladen: patches... ;-)
<Mithrandir> pitti: it's not huge, it's 2-300k. :)
<pitti> Mithrandir: it's huge if you download this with a 56 kbps link
<pitti> Mithrandir: my main network is down :-(
<thom> 2-300k of uncacheable, uncompressable joy
<daniels> mjg59: with a little bit of tweaking, this could rescue i8xx acpi/dri for hoary
<daniels> thom: fsvo 'joy'
<Mithrandir> thom: it can be cached.
<daniels> pitti: now you see why I complained so much while I was on dialup
<Mithrandir> just set browser.cache.disk_cache_ssl to true
<Mithrandir> in FF
<thom> Mithrandir: nope, it's ssl, browser won't cache by default
<Mithrandir> thom: "by default".  User can change it. :)
<pitti> daniels: I feel with you
* thom wonders whether this will fix firefox bidi crap
<mjg59> daniels: Mm?
<pitti> daniels: this bastard of admin went to holidays without giving anybody the passwords. *grrrrr*
<mjg59> daniels: Oh, shit. That means Do the DRM patch, doesn't it?
<daniels> mjg59: possibly make i830 usable for desktops -> not booting the HEAD code out
<daniels> mjg59: you know what time it is
<mjg59> Time for me to write my GUADEC paper, do a submission for Debconf, write code for work, do 3 hours of teaching, tell my landlord that we're not paying a bill, organise travel to .au and, uhm?
<thom> mjg59: what should we do with swap after a busted hibernate? is unconditional mkswap towards the end of rcS or so reasonable? 
<daniels> mjg59: yeah, I've still got my LCA paper. :\
<mjg59> thom: I talked to jbailey about this - make the mkswap conditional on there being a swsusp header
<sladen> mmm, that completion list could be cut in 1/3rd just by storing it more efficently
<Mithrandir> sladen: gzip JS decoder?
<sladen> Mithrandir: hahah.  Nope, it's sending both indexs;   a[123]  = "foo";  b["foo"]  = 123;  except that 'a' and 'b' are both 15 characters long and indented;  and the email address is being send (when most are duplicated)
<Mithrandir> sladen: sounds wasted, yes.
* doko wonders if fabbione sees more cpus on davis than me ...
<sladen> grep physical.id | sort -u ?
<svenl> Mmm, what is the "starting periodic command scheduler" supposed to do ? 
<Mithrandir> svenl: cron?
<svenl> Mithrandir: any particular reason why the post-install boot should die at this point (true, i had to hard-reboot it because of missing input but still).
<Mithrandir> svenl: no, not really.  PPc?
<Mithrandir> s/c/C/
<svenl> Mithrandir: yep.
<Mithrandir> you don't have noapic and friends, then?
<svenl> its sitting there since a couple of minutes.
<svenl> ok, i will reinstall, just to be sure i didn't hose something.
<svenl> Mithrandir: no, none of this stuff.
<svenl> Mithrandir: it used to work earlier even.
<Mithrandir> unsure, then
<svenl> ctr-alt-del brings the box down, so its not dead.
<thom> i'd love to know where people come up with the numbers of ubuntu staff
<Mithrandir> thom: oh?
<Mithrandir> where?
<thom> Mithrandir: http://www.grep.be/blog/2005/03/15#release_meeting_retort in this case
<sladen> it gets better!  Aswell as the 659kB file, there's a 295kB .js with a duplicate set of data too
<sladen> 1MB per refresh. r.
<dholbach> elmo: could you please sync  t38modem ohphone zaptel openam openmcu gnugk ?
<Mithrandir> thom: actually, somebody posted ~30 in the big flame thread.
<Mithrandir> thom: somebody interpreted that as "30 DDs working 24/7 working on ubuntu" rather than "30 canonical employees"
<daniels> Mithrandir: someone -> keybuk
<daniels> which is slightly frustrating; canonical has more than 30 employees, and the distro team certainly doesn't have anywhere near 30
<jdub> Mithrandir: ha ha ha 30!
<Kamion> fabbione: yes, provides: nfs-modules would be good for correctness
<svenl> I think someone official from canonical/ubuntu cited 36 somewhere public recently.
<Kamion> fabbione: not critical, but good :)
<fabbione> Kamion: roger that.. done :-)
<elmo> dholbach: done
<thom> svenl: that's total canonical staff, which is utterly not the same thing
<jdub> and it's not even correct
<Kamion> svenl: doesn't sound too far off; but again, that's all of Canonical, only about 15 of those work on Ubuntu
<jdub> we're closer to 50
<Kamion> 50 now? wow
<ogra> DDs ?
<Kamion> ogra: the majority, but not all
<elmo> err?
<Kamion> ogra: majority of those working on Ubuntu, that is
<Kamion> not the majority of Canonical staff
<ogra> thats what i thought
<svenl> thom: well, i am just saying where i believe the idea comes from.
<dholbach> elmo: you rock!
<svenl> Kamion: but then you have to count the whole lot of people who work on ubuntu without working for ubuntu -> non-full-time-employees and such.
<elmo> dholbach: dude, syncs are insanely easy - you should really be less grateful :)
<Kamion> svenl: sure, but those are equivalent to the people working on Debian in the same way
<Kamion> and there are many fewer people working for Ubuntu like that; it's, what, 10, 20?
<svenl> Kamion: the main problem is one of comunication, i personally know more about ubuntu now that a couple of month ago, but i am still not confortable with the whole thing, and i bet many others may feel the same way.
<mvo> elmo: we'll need to sync nessus-plugins soon from debian because upstream claims our version is not redistributable (not now, still wait for a mail from him)
<jdub> Kamion: although being MASTERS OF THE UNIVERSE, they count for like, three people each.
<svenl> Kamion: i think the main problem is the high amount of debian high profile folk working fulltime for ubuntu or something, and especially those in the 'not-enough-time' position to fullfill their debian roles, i don't say this is rational, but this is what i feel the feeling at large are to some degree.
<dholbach> elmo: i _am_ grateful: look at http://wiki.ubuntu.com/UniverseUnmetDeps - i'm absolutely happy for every entry we can kick from it :-)
<Kamion> svenl: for somebody who isn't saying it's rational, you do seem to be mentioning it more than anyone else ... :-)
<svenl> Kamion: because it may not be fully rational doesn't mean we don't feel like it.
<dholbach> jdub: woohoo!
<daniels> svenl: in that case, it probably doesn't help to go around repeating it
<ogra> jdub, yay
<svenl> Kamion: bah, let's go back to work instead, already lost enough time with yesterday's craziness.
<Kamion> daniels: #7664> I wonder if I can come up with a way to allow d-i components to request packages to be installed by base-config
<Kamion> daniels: but thanks, that should solve it
<jbailey> thom: #7463
<daniels> Kamion: mmm ... yeah
<daniels> Kamion: it was either an undeclared dep or stupid package placement in any case (fwiw, it was the latter)
<Kamion> daniels: ok, if you could put a note in that bug when it's sorted, I'll retest and see if that fixes Greek installs; it was a bit subtle so I'm not entirely sure I can pin it down to just one thing
<daniels> Kamion: yeah, should be uploaded tonight
<svenl> Kamion: BTW, what is with this failure to detect that there is no keyboard when using the serial console ? 
<Kamion> although I guess I could comment out the unifont installation and see if that fixes it ... will try that noe
<Kamion> now
<Kamion> svenl: not familiar with that issue
<thom> jbailey: thanks
<svenl> Kamion: the keyboard dialog comes up, and you get asked about three choices. continuing without keyboard fails, asking to detect keyboard with a few keystrokes makes the whole thing continue as it should.
<Kamion> svenl: oh, I blame smurfix :)
<Kamion> I don't think his new keyboard selector has been tested on serial console much at all
<Kamion> kbd-chooser bug would be good
<svenl> ok, will do so at next install, so i have the real message under the eye.
<herzi> seb128: ping
<Kamion> svenl: cool, thanks
<svenl> herzi: you asked me about pegasos support earlier.
<svenl> herzi: do you want the OF upgrade that allows to try an installation with yaboot ? 
<herzi> svenl: yes, but i won't upgrade/install the pegasos now as my other production system went to the vendor yesterday (no image anymore with any graphics device) and I don't plan to break my last production system too
<seb128> herzi: pong
<herzi> seb128: 7686
<herzi> this one seems to be an easy fix
<svenl> herzi: ok, tell me when you are ready for it and i will send it to you.
<seb128> herzi: I'll have a look thanks
<herzi> svenl: i guess we're talking about 4 weeks
<blawk> heya folks
<daniels> mjg59: rock.  this is entirely doable.
<seb128> herzi: 
<seb128> $ find gnome-doc-utils-0.1.3/ -name "*template*"
<seb128> $
<Kamion> Mithrandir: OOo restored to ia64 desktop
<Mithrandir> Kamion: I guess t-bone is happy, then.
<fabbione> re
<Kamion> sladen: no opinion really, guess it seems reasonable as long as it cooperates with the normal completion file
<Nafallo> fabbione: ping?
<fabbione> pong
<Nafallo> fabbione: would it be usefull to drop mplayer-custom and make mplayer-nogui on all arches with only INDEP?
<fabbione> Nafallo: i am not working on mplayer right now. i have more important things to do
<Nafallo> fabbione: oki.
* fabbione kicks pitti
<pitti> fabbione: ?
<fabbione> not another glibc update!
<pitti> fabbione: as always, this will be the really last one :-)
<fabbione> you are killing my buildd :-)
<Nafallo> I asked more of the reason that I would like to work on it. But only if people here liked that idea to happen.
<fabbione> Nafallo: if you want to work on it, go ahead
<fabbione> i have nothing against it
<dholbach> elmo: and if you now please could sync  asterisk and pstngw  i'd be happy for the rest of the day :-)
<Nafallo> fabbione: oki. -custom gets deprecated then :-)
<fabbione> when i enabled amd64/ppc build on saturday i was just bored
<fabbione> make sure to fix the ppc FTBFS
<Nafallo> fabbione: I'll try. I haven't got that ARCH to test on :-/.
<fabbione> neither do i
* Nafallo goes to check the auctions for cheap ppc-machines ;-) *
<jbailey> pitti: Err, I have a bug against glibc that mdz assigned to me yesterday that he wants fixed...  So possibly one more. =)
<pitti> jbailey: D'oh, I uploaded ten minutes ago...
<jbailey> pitti: I haven't triaged this at all, sorry.
<pitti> ah, ok
<ogra> Nafallo, for a start you shoud apply for MOTU if you want to help with that
<Nafallo> ogra: mplayer is in multiverse still, no? :-)
<ogra> Nafallo, yup
<ogra> Nafallo, thats why i said that :)
<Nafallo> ogra: I've found something to study that includes FOSS-development. I want to learn to fix things before taking on any responsibility for those stuff :-).
<Kamion> elmo: is adare down?
<thom> sivang: around?
<thom> (or any other hebrew reader)
<Nafallo> ogra: you /will/ get to see my as a MOTU most likely, but when I feel I can grook that :-).
<ogra> Nafallo, yay, great :)
<thom> sivang: is http://people.ubuntu.com/~thom/firefox-hebrew-current.png rendered the right way round?
<tseng> elmo: can you sync gtkpod 0.88-1 please
<daniels> whoohoo!
<daniels> it looks like we're actually going to support every i8xx device out of the box in hoary.
<tseng> new patch?
* daniels goes to sleep, relieved that we're not actually massively regressing support.
<daniels> tseng: new patches + new ideas
<tseng> rock on
<fabbione> Need to get 0B/47,0MB of source archives.
<fabbione> hell!
<fabbione> l-r-m is bloating at speed light
<daniels> yeah, fglrx is growing by about 20mb every release, i swear
* pitti goes to uni to get some bandwith, bbl
<fabbione> doko: davis has done.
<ogra> daniels, is there a tool to get the currently running display frequency ? from xdpyinfo i can only get size and depth....
<doko> fabbione: thanks
<ogra> daniels, (i need this info for hwdb client)
<fabbione> ogra: probably you can grab them either via libxf86vm
<fabbione> or from the log
<fabbione> i don't think there is too much exposure of these info to "userland"
<ogra> hmm, the log is a good idea...i have it already in a variable....
<fabbione> since nobody, other than the server and user, cares
<ogra> hmm, probably the monitor too ;)
<fabbione> well clearly
<thom> ccache is the single best invention of the millenium
<fabbione> thom: it is buggy tho
<thom> i care not; it works for firefox for me
<fabbione> it tends to deadlock when you build with -j$oddnumber
<fabbione> specially on ppc
<Treenaks> fabbione: build with -j$evennumber then
<fabbione> Treenaks: that's boring
<smurfix> svenl: Gah. Can you reproduce the thing without a serial console?
<zul> heylo
<Treenaks> howdy!
<zul> hey Treenaks 
<dholbach> hai zul
<zul> hey dholbach 
<thom> firefox 1.0.1 uploading, y'all have a nice day now
<dholbach> thom: you rock so hard!
<dredg> nice
<dholbach> wooooohoooo!
<thom> 1.0.1 really is very boring *shrug*
<dholbach> boring in what sense?
<Treenaks> thom: it will make ubuntu more leet!
<dholbach> no funny memory leaks anymore?
<thom> in that it fixes some security problems, most of which we'd already fixed, and thats about it
<dholbach> hm
<dholbach> hrm
<thom> 1.1 is the interesting one, but the schedule for that is that it releases sometime around the same time we release hoary
<dholbach> what about firefox_1.0.1.really.is.CVS-1.1? ;-)
<Mithrandir> dholbach: wrooooong!
<Mithrandir> :)
<dholbach> ;-)
<thom> uh, no :-)
<Treenaks> what's it with huge C++ projects and huge memory leaks going hand in hand? :P
<dholbach> dunno if that's c++ specific
<Treenaks> dholbach: well, gnome has some leaks, but not really major afaik
<Treenaks> dholbach: and they're working on it for .12
<Mithrandir> Treenaks: you mean stuff like FF eating some hundred megs of ram?
<Treenaks> Mithrandir: multiple hundreds, yes
<thom> dholbach: http://www.mozilla.org/projects/firefox/roadmap.html
<Treenaks> Adobe Reader 7.0 for Linux is "final"
* dholbach read too much adobe reader in the last 24h
<dholbach> *shudder*
<zul> bleah..
<ogra> heh
<tseng> dholbach: evince++
<ogra> yeah
<dholbach> tseng: yeah
<zul> well its still better than xpdf
<tseng> meh
<dholbach> thom: oh i see... yes
<pitti> Hi again
<thom> pitti: how are you coping in bugzilla with bugs that only affect warty?
<thom> (ie, how do you mark them?)
<pitti> thom: if we need to fix them, I don't know better than just writing this fact into a comment
<pitti> thom: if hoary is already fixed, you could set the Target Milestone
<trukulo> Treenaks, where is adobe 7.0 "final" ?
* pitti guesses that thom uploaded firefox 1.0.1 :-)
<Treenaks> trukulo: ftp://ftp.adobe.com/pub/adobe/reader/unix/7x/7.0/enu/
<dholbach> trukulo: should be in the trash can finally :-)
<trukulo> dholbach, sure :) but wanna see it first
<dholbach> trukulo: it won't be good for your eyes though
<trukulo> dholbach, probably, but here ppl use very strange things in pdf
<dholbach> i can imagine
<thom> pitti: well, waiting for the fricking tarball to go up, yeah
<pitti> cool
* dredg wonders if phpbb2 can be synced from debian (security fixes)
<thom> hrm, that's quite neat. search results that don't match the regexp ^\[warty\] 
<thom> bugzilla isn't all awfull
<pitti> dredg: new upstream version?
<dredg> pitti: yes
<dredg> pitti: there are a number of holes in the current ubuntu version
<pitti> dredg: yes, I read about them
<dredg> these are fixed in the current debian unstable package
<pitti> dredg: it's amazing how many holes this software has, it's more like a network :-)
<dredg> pitti: i know :-/ it's pretty frightening
<pitti> dredg: I'm fine with a sync, but mdz should confir
<pitti> m
<dredg> i wonder if secunia have a "most hole ridden oftware" award
<dredg> pitti: sure.
<pitti> dredg: oh, ethereal could make rank #1, too :-)
<fabbione> new kernel is ACCEPTED
<pitti> fabbione: thanks
<pitti> fabbione: just released the Warty kenrel
<fabbione> pitti: no problem.
<fabbione> i am waiting for the kernel to build to release l-r-m
<pitti> fabbione: btw, this API break checker sounds really interesting :-)
<pitti> yay for ffox 1.0.1
<tseng> oh rock on thom 
<fabbione> pitti: it will save us from embarassing situation like breaking external modules
<thom> mozilla-firefox_1.0.1-2ubuntu1_source.changes ACCEPTED
<fabbione> but it is still semi-automatic
<fabbione> a lot of work needs to be done manually
<pitti> fabbione: does it reliably work or is it more like a heuristics?
<fabbione> it works
<fabbione> reliably
<pitti> neat, also for future Hoary security update
<fabbione> given that: 1) you feed him proper data 2) you don't enable the overrides
<pitti> fabbione: how does it work, is the build FTBFS if it breaks the ABI without bumping?
<fabbione> pitti: this is the only reason why it has been added pre-hoary
<fabbione> pitti: correct.. check out the code from baz
<fabbione> pitti: because security is all your...
<pitti> rock
<pitti> dildo?
<fabbione> you need to get used to it.. not me :)
<fabbione> ahahha
* dholbach wonders what the security team's t-shirt will look like ;-P
<ogra> dildo ?
<pitti> ogra: <fabbione> pitti: because security is all your...
<dholbach> fabbione surely has some ideas for it
<zul> cigaro
<ogra> heh
<pitti> Hey Keybuk
<Keybuk> heyhi
<fabbione> we will see pitti going around with a huge condom all over his body
<ogra> pitti: dholbach wonders what the security team's t-shirt will look like ;-P
<ogra> ;)
<fabbione> this is security :-)
<pitti> *lol*
<ogra> yeah
<dholbach> hahahahaaaa
<pitti> Keybuk: look behind! a three-headed Replaces: bug
<Keybuk> pitti: it's ok, it'll eat you, not me :p
* pitti has to exercise scaring people much harder
<tseng> what happened to the talk of syncing dbus 0.23.1
<HiddenWolf> holy j; that kernel changelog is massive
<zul> HiddenWolf: isnt it :)
<HiddenWolf> what did you guys do, take a shot at linux 3.0? ;)
<zul> nah, security fixes, and re-sync with debian
<Treenaks> apparently, some people do care about stability :)
<kent> Is some one Lamont Jones here? I just saw from bugzilla that he added "kernel-bugs@lists.ubuntucom" to the inotify-bug, which i think lacks a ".com"  :)
<Kamion> kent: that would be lamont
<HiddenWolf> lots of security fixes; holy hell.
<Mithrandir> kent: bug #?
<zul> kent: ill fix it wheich number
<HiddenWolf> kent; it just misses the .
<kent> zul, Kamion Mithrandir 5431
<Mithrandir> zul: you'll fix it?
<cc> in the LiveCD, where do I configure the firefox startpage ?
<Treenaks> cc: edit -> preferences?
<zul> fixed already looks like it in the q-a contact kent
<cc> Treenaks: no, i'm trying to cook my own LiveCD. so i want it as a default preference
<Treenaks> cc: /etc/mozilla-firefox/pref/firefox.js ?
<kent> zul, Well I just saw what looked like a typo, and have not got a new mail from that bug so I thought perhaps it was not fixed. Did I miss something?
<zul> kent: it has the "." in the q-a contact
<zul> kent: kernel-bugs@lists.ubuntu.com
<kent> zul, ok. I just read the mail I got from bugzilla and there, under Added, it says "kernel-bugs@lists.ubuntucom". Perhaps bugzilla reports wrong then? Or is it fixed in bugzilla it self, so i got not new message about it?  Just curius :)  (and yes, i dont know how to spell that, haha)  :)
<zul> kent: not sure maybe it was a hiccup
<amu> cc: you've to change the source of it 
<cc> amu: yes, thanks. i just did
<ogra_away> hmm, from the topic of #ubuntu: nvidia is broken in hoary with kernel 2.6.10-26
<ogra_away> isnt that a bit obsolete ?
<zul> oh yes
<zul> its fixed in -27
<ogra_away> becaue people starting to compile their ati drivers based on this info :-P
<ogra_away> because even
<zul> if they havent upgraded from -26 then its still broken its been fixed in -27 and above
<ogra_away> so someone with access should change it i guess
<evarlast> what is the prefered way to file a bug on a package?
<zul> bugzilla
<evarlast> for a universe package?
<evarlast> debians bugzilla?
<ogra_away> evarlast, ubuntu-users mailing list 
<evarlast> to file a bug?
<dholbach> yes
<evarlast> hrm.  I'll have to subscribe?
<tseng> we are working on a universe bug tracker
<dholbach> until we have  http://launchpad.ubuntu.com/malone
<tseng> but its not ready for general use.
<evarlast> hrm, ok.
<dholbach> ok everyone... see you later *wave*
<ogra_away> evarlast, btw, which package ?
<evarlast> socks4-server
<evarlast> it should depend on libsocks4 but it does not.
<fabbione> Kamion: both kernel and l-r-m are up.. we only need to wait for the binaries
<Kamion> fabbione: yep, I've just seeded the udebs
<fabbione> perfect
<fabbione> we miss linux-meta.. don't we?
<Kamion> yeah
<fabbione> and elmo to promote the bins
<fabbione> (+ bless them with NEW)
<fabbione> i am off for 30 minutes...
<Kamion> I have a debian-installer upload ready
<fabbione> i need a little break
<fabbione> cool
<fabbione> i think we could actually automate all this mess with a queue
<fabbione> where we stock all the sources
<fabbione> and it will start uploading the kernel
<fabbione> wait 2 hours
<fabbione> upload l-r-m
<fabbione> wait 30 minutes
<fabbione> and so on....
<fabbione> seed in the meanwhile
<fabbione> kick elmo or katie or any of elmo's gf
<fabbione> hmmm
<fabbione> well later :-)
<Kamion> we've kind of got the hang of it, though :)
<thom> woop, i fixored the hebrew madness
<HiddenWolf> thom: are the palestians safe now?
* zul smacks HiddenWolf 
<zul> no politics here :)
* HiddenWolf grins
<HiddenWolf> Sorry zul, couldn't resist this one
<smurfix> Does anybody know where /usr/share/omf/upx-ucl-beta/upx-ucl-beta-C.omf comes from?
<svenl> smurfix: yes, sure.
<smurfix> svenl: It's a malformed XML file.:-/
<jbailey> Anyone here got a sata_via machine?  Looks like another bug...
<thom> smurfix: interesting; it's probably generated by doc-base so there's a bug somewhere
<thom> jbailey: sure
<smurfix> thom: The "&" character isn't escaped.
<smurfix> thom: I'll look at it.
<svenl> smurfix: anything i can do to help ? 
<thom> smurfix: hrm, i'm pretty sure i'd fixed that
<mvo> Kamion: can we do a ntpdate in the installer early? comment #3 in #7536 asks for this
<jbailey> thom: 7630 looks like in order to see the pata cdrom drive, that ide-generic has to be loaded after everything but isn't.  Do you see the same thing?
<thom> smurfix: oh, no
<thom> i'll fix now
<Kamion> jbailey: yes, I have a sata_via; I think the CD-ROM drive is just ATAPI though
<Kamion> I don't see that bug
<smurfix> thom: OK, I'll not look at it then. ;-)
<Kamion> mvo: bah, thought I'd worked around that bug in d-i, didn't realise ubuntu-keyring also cared
<jbailey> Kamion: Thanks.
<mvo> Kamion: I fixed ubuntu-keyring
<Kamion> mvo: it's hard, because ntpdate isn't available at the right times
<smurfix> Kamion: Hmm, do I build an ntpdate-udeb for that, or would it be too late anyway?
<Kamion> smurfix: I think that's the only possible option, but TBH I think it's OK for ubuntu-keyring to just use the GPG option to ignore clock problems
<Kamion> as I think mvo has done
<thom> jbailey: my /etc/modules contains ide_generic already; i'll try rebooting without that and see what happens
<jbailey> thom: Thanks.
<thom> (after firefox finished building ;-) )
<Kamion> smurfix: and, as the bug reporter says, it should be made to work even if the network isn't up
* Mithrandir kicks warty's hotplug
<jbailey> thom: No worries.  =)
<Kamion> hah, two bugs in a row where I know the reporters in person
<smurfix> Kamion: It might make sense to have a sane clock while you're installing, but ... it's something to add post-Hoary I'd say.
<Kamion> smurfix: very little cares, I think gpg is the only thing that's cared so far
<svenl> mm, i did a clean install, and it dies in Starting periodic command scheduler still :/
<smurfix> Kamion: I managed to do that once. Directory mod times somewhen in 2008. Oh well. ;-)
<svenl> Kamion: how can you specify an initrd= argument in yaboot's command line ? 
<svenl> jbailey: notice that yaboot doesn't have grub2's big initrd size problem.
<Mithrandir> yay, hotplug has been running for six minutes now.
<Kamion> svenl: you can't
<Kamion> svenl: initrd booting with yaboot requires a yaboot.conf
<jbailey> svenl: Last I checked, yaboot couldn't load an initrd at all on the pegasos.
<svenl> Kamion: figured so. Is there a way to disable the quiet thingy online to see why it dies in the periodic command scheduler ? It didn't do that last week.
<svenl> jbailey: ah, you need a new OF upgrade.
<svenl> jbailey: email address ? 
<jbailey> svenl: Then perhaps grub2 will work then too?  Who knows.  Marco thinks that there shouldn't be any limitations and was suspecting an OF bug.
<jbailey> svenl: jbailey@ubuntu.com  Is this the one that ate someone's motherboard?
<svenl> jbailey: what i mean by that is that it is probably a grub2 problem in how it allocates memory, not an OF bug.
<Mithrandir> impressive.  /etc/init.d/hotplug start takes about 13 minutes to run on this dual 2.2GHz opteron system.
<thom> smurfix: uploaded
<Kamion> svenl: mm, I guess I'd edit /target/etc/yaboot.conf before the reboot
<jbailey> Mithrandir: Ouch.  Does it take that long on a restart?
<svenl> Kamion: mmm, problem is i already rebooted.
<Mithrandir> jbailey: it takes a fair amount of time at least
<svenl> Kamion: maybe booting in single user will drop me to a shell before that.
<Kamion> should really add a recovery mode to the generated yaboot.conf
<Kamion> svenl: boot with init=/bin/sh
<svenl> Kamion: maybe booting in single user will drop me to a shell before that.
<svenl> yeah, that is an option too.
<jbailey> Mithrandir: Wait, you said this is warty's hotplug, right?  Is it worth fixing?
<Mithrandir> jbailey: it's warty's hotplug, yes.
<Mithrandir> jbailey: it's fixed in hoary.
<Mithrandir> so I'm just going to upgrade
<svenl> Kamion: if i did do that, i probabl would have no keyboard driver or something such.
<svenl> Damn, removing quiet doesn't help, i guess i need to remove splash too.
<Mitario> hi everyone
<Mitario> mvo, we got cvs.gnome.org aproval :)
<Mitario> mvo, hi btw ;-)
<Kamion> svenl: hotplug-in-initramfs will fix that I think, but not for hoary ...
<Kamion> svenl: single-user mode should get you a shell before cron startup, though, yes
<Kamion> svenl: removing quiet won't help, the init script output stuff is not controlled by either
<mvo> Mitario: that's good news, cool!
<fabbione> Kamion: amd64 is all done (and the only one)
<pitti> <bitch>why not arch.gnome.org? </bitch>
<pitti> :-)
<lamont> kent: gah!
<svenl> Kamion: mmm, why doesn't booting with 's' ask for the root password, is this not a security hole ? 
<lamont> zul: it's a _BUNCH_ of them.
<fabbione> hey lamont 
* lamont goes to fix the lot
<fabbione> lamont: can you check if ppc and i386 are building the kernel?
<fabbione> they are taking longer than usual....
<jbailey> svenl: If you have console access, all bets are off, but in general, there is no set root password.
<fabbione> probably they hit a buildd with no ccache
<lamont> fabbione: checking
<fabbione> thanks
<jbailey> svenl: All best are off security-wise that is.
<svenl> jbailey: console access ? you mean ubuntu is useless for unattended machines, right ? 
<lamont> fabbione: royal (ppc) is just finishing, i386 has a ways to go
<fabbione> lamont: cool, thanks
<fabbione> lamont: i know.. see /topic on #u-k :-)
* lamont grumbles at jdub about his "-1 kernel-bugs moderator requests pending"
<pitti> thom: can I please have libreadline4-dev in hoary-dchroot on davis?
<jbailey> svenl: No, as in if you have physical access to a machine, something as flimsy as a root password isn't going to stop you from doing what you want to it.
<svenl> jbailey: well, ...
<HiddenWolf> jbailey: it's still good practice to ask for it.
<svenl> anyway, why would /etc/init.d/cron hang ?
<svenl> ormaybe the stuff after it is hanging :/
<svenl> mmm, the next one would be rmnologin.
<zul> lamont: bitch bitch bitch :)
<svenl> nope, breaks.
* lamont back in a couple
<svenl> Kamion: when did you do a new install last ? 
<Kamion> svenl,HiddenWolf: booting with init=/bin/sh doesn't ask you for the root password either, which is not Ubuntu-specific; if you have an unattended machine you need better measures than a root password, such as a BIOS (or equivalent) password, or physical locks
<Kamion> svenl: about ten minutes ago
<thom> jbailey: confirmed
<svenl> Kamion: and it worked fine for you ? 
<Kamion> svenl: yep, i386 install
<svenl> Kamion: true, just surprising.
<svenl> Kamion: what about x86 ? 
<thom> jbailey: with no ide-generic i see no pata devices at all
<Kamion> it was an i386 install that worked fine for me; just giving information
<svenl> here it dies in crontab on entering runlevel 2. doing /etc/init.d/cron start in single user worked fine.
<svenl> Kamion: what about ppc, i mean.
<jbailey> thom: Can you tell me what's in /proc/ide ?
<Kamion> svenl: haven't tried powerpc yet today
<Kamion> I'm burning the powerpc daily now
<svenl> mmm, i put an exit in /etc/init.d/cron, and it stops at the deffered command scheduler, strange.
<Kamion> is this pegasos? serial console?
<svenl> peg, normal console.
<Kamion> 'k
<svenl> atkbd.
<Kamion> hmmmmm. configuring timezone on live CD considered interesting.
<mdz> morning
<zul> hey mdz 
<fabbione> morning mdz
<seb128> hi mdz 
<thom> hey mdz
<mdz> Mithrandir, elmo: I most certainly did not say to change the version number; in fact I explicitly said that the .dsc and .diff.gz should be identical
<Mithrandir> mdz: yes, which is what happened here.
<Mithrandir> mdz: I just edited the changes file.
<mdz> Mithrandir: where did the ubuntu version number come from?
<Mithrandir> mdz: what ubuntu version number?
<mdz> oh, I misread what elmo said
<Mithrandir> : tfheen@vawad ~ > apt-cache show mcelog | grep ^Version
<Mithrandir> Version: 0.3-1
<Mithrandir> oh, ok
<Mithrandir> :)
<svenl> Kamion: please confirm to me that your install worked on ppc once you did it, ok ? 
<Kamion> hmm
<Kamion> TFTP error 2: Access violation
<svenl> Kamion: you are using tftpboot ? 
<Kamion> maybe it wants yaboot.conf in /
<Kamion> svenl: yeah
<svenl> Kamion: err, tftpd.
<Kamion> tftpd-hpa
<svenl> use atftpd instead.
<Kamion> urgh
<Kamion> can I use tftpd-hpa with a different root directory?
<svenl> ah, don't know about tftpd-hpa variant, but plain tftpd has this idea about searching absolute names in / and not in /tftpboot like it is told.
<Kamion> right, it's configurable in -hpa at least
<svenl> maybe just remove all leading / to make them relative names will fix this.
<Kamion> I have it set to / by default for i386, but ...
<Kamion> I'll try that but I think it's still looking for yaboot.conf
<svenl> Kamion: i don't know for -hpa, but plain tftpd didn't respect me saying it should look in /tftpboot.
<svenl> Kamion: look at your syslog to see what tftpd tried to serve ?
<mdz> doko: libstdc++6 -> libstdc++60?
<Kamion> svenl: it's looking for /etc/yaboot.conf (!)
<svenl> Kamion: yep, but in /etc, not in /tftpboot/etc/yaboot.conf.
<Kamion> even so :)
<svenl> Kamion: install atftpd instead, works much better.
<Kamion>        -s     Change  root  directory on startup.
<Kamion> I'll use that option, then I don't have to have different tftp daemons to cope with different architectures
<svenl> Kamion: i know, it is configured in /etc/inetd.conf, but it fails to respect the configuration.
<svenl> ok.
<jbailey> thom: fabbione says that the -28 kernel has some sata fixes that might solve this in another way.
<svenl> Kamion: maybe i should chop off the leading / in the path OF asks over tftp ? Do you know if apple hardware works with tftpd ? 
<Kamion> svenl: it's worked for me before
<jbailey> thom: Are you able to do another reboot?
<thom> jbailey: sure
<thom> is -28 up for amd64 anywhere?
<Kamion> thom: archive.u.c
<thom> ah, yes
<thom> hoary-changes just finished opening
<svenl> Kamion: next time you netboot a pmac, can you look at syslog to see what /tftpboot served, and if it has a a leading /
<svenl> Kamion: also, you could put a symlink from /etc/yaboot.conf to /tftpboot/etc/yaboot.conf for the time being.
<svenl> Kamion: i still feel that this is a bug in tftpd[-hpa]  though.
<jbailey> Heya Michael.
<doko> mdz: libstdc++6: context?
<azeem> hi Jeff
<doko> mdz: ah, the diff, yes dependent on where you generate the control file, bit anyway, elmo discovered that the patch I wanted to have applied was already applied in 3.4 (but not 4.0)
<Kamion> svenl: any extra parameters to 'boot eth' that I should know about? Trying 'boot eth /tftpboot/ubuntu-powerpc/yaboot', tcpdump just shows it sitting there trying to arp
<Kamion> ah, never mind, got it now
<svenl> Kamion: don't forget : console=ttyS1,115200n8 too.
<Kamion> hm, no, still failing, sitting there with 'R' and the spinner
<Kamion> svenl: not on serial console
* thom reboots once more
<Riddell> Kamion: where can I find a copy of the current isolinux splash image?
<svenl> oh, ok.
<svenl> Kamion: the spinner thingy does turn ? 
<Kamion> Riddell: debian-installer source package, build/boot/x86/pics/ubuntu.png
<svenl> quickly even ? 
<Kamion> svenl: yeah, reasonably so
<Kamion> ok, moving the network cable and using 'boot geth' instead works better
<svenl> Kamion: strange, but it does indeed here too. That said the gige kernel module is broken in ubuntu, so you have to move it back later on.
<Kamion> eek
<Kamion> yay, booted
<svenl> Kamion: yep, i have a patch though.
<Riddell> Kamion: thanks
* lamont looks at 7692 and scratches his head... sounds like !mount...
<svenl> what is the default ubuntuMTA ? 
<schweeb> postfix
<thom> postfix
<svenl> Mmm, i think something id seriously wrong here, and it is not cron or atd. 
<svenl> it stops after that. rmnologin doesn't output anything, and i must check stop-bootlogd, but what is supposed to happen afterward ? 
<Riddell> mdz: can you add kubuntu-default-settings to the kubuntu desktop seed?
<Kamion> svenl: any idea which of the NewWorld, OldWorld, or chrp functions in ofpath should be used for pegasos?
<Kamion> or none of them?
<Kamion> I guess not chrp, it's SCSI-only
<lamont> seb128: you around?
<seb128> yep
<lamont> Kamion: d-i upload for the abi bump... I think it should be ready...
<fabbione> lamont: no.
<fabbione> we are still missing i386 and l-r-m for i386
<lamont> seb128: could I have some remdial help???  the screensaver daemon doesn't start when I login, until I go to preferences/screensaver and it tells me it's not running, would I like to start it...
<fabbione> btw.. read u-k :-)
<lamont> what did I delete from my startup ?
<lamont> fabbione: sigh
<Kamion> lamont: I'm waiting for choose-mirror 1.06ubuntu8 too
<lamont> Kamion: ok.  we're still waiting on a kernel or lrm at least too
<Kamion> svenl: what does 'spi' mean in /pci@80000000/ide@C,1/device_type? ofpath doesn't know about that type
<pitti> Riddell: are there any news about your kdesu patch?
<mdz> Riddell: certainly.  has it been processed through queue/new yet?
<seb128> lamont: good question, I don't know ...
<Riddell> pitti: havn't had a change to make the modifications you suggested yet
<Riddell> mdz: yes, seems to have been
<mdz> Riddell: version 5.10.01?
<lamont> seb128: sigh. thanks anyway, I guess.
<mdz> Riddell: do you want me to remove ubuntu-sounds as well?
* lamont will compare and contrast his daughter's config sometime soon
<seb128> maybe thom knows
<Riddell> mdz: yes version 5.10.01 is current, probably best remove ubuntu-sounds I'll come back to them later if I have time
<Riddell> elmo: any move on kubuntu.org?
<mdz> Riddell: I was wondering why 5.10.01, rather than, say, 5.04.x
<mdz> or if there was some different meaning to the version number
<Riddell> mdz: ah, good question, possibly becaues I can't count
<mdz> Riddell: the seed updates are done. do you know how to do the kubuntu-meta update/
<mdz> ?
<Riddell> mdz: nope, but I'd be interested to learn
<mdz> Riddell: it's way easy
<mdz> Riddell: just wait until the changes are reflected in the published seeds
<mdz> http://people.ubuntu.com/~cjwatson/seeds/
<mdz> then apt-get source kubuntu-meta
<mdz> run the ./update script in the source package
<mdz> then do a normal source build+upload
<Riddell> mdz: doesn't sound too hard, I'll give it a shot
<sivang> hi all
<pitti> Hi sivang 
<pitti> sivang: what's up?
<sivang> hey pitti , 'sup?
<Kamion> erk; can evince's Find not operate across a whole document?
<Kamion> it seems to only work on the current page, which makes it pretty unusable for reading specifications
<Kamion> oh no, now it works, how strange
* mvo is away for ~2h
<seb128> mdz: here now
<seb128> ups, forgotten again about the meeting
<mdz> seb128: no problem, we decided to have a discussion on ubuntu-devel
<seb128> about what ?
<dholbach> $release-updates of gnome
<dholbach> i.e. to have gnome updates to hoary-updates after hoary's release
<Q-FUNK> mdz: my proposition to upload minor gnome releases to $release-updates
<seb128> dholbach: k, thanks
<Q-FUNK> , seb128
<seb128> I'm not sure we should do minor updates
<seb128> but let's talk about this on the list
<Q-FUNK> I'd really like to hear why.
<seb128> that's easy, who is going to do the updates ?
<seb128> maintaining 2 branches is a bunch of extra work
<Q-FUNK> that was my proposition:  I woold take whatever you upload to d/unstable and rebuild for $release-update.
<seb128> that doesn't match
<seb128> we have some specific changes
<mdz> please, guys, let's discuss on the list
<seb128> some stuff break in debian
<seb128> right
<Q-FUNK> or more precisely:  http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda
<mdz> there are other people we need to hear opinions from, who are not in this channel right now
<mdz> elmo: still around?
<elmo> mdz: unfortunately
<mdz> elmo: Treenaks was approved for upload to universe, but he claims not to have upload privileges yet (key 3FA5E031)
<seb128> mdz: do you know who could have an idea on #6945 (font changing with the locale) ?
<mdz> seb128: I have no idea about font selection
<elmo> mdz: yes, as he said, he mailed me yesterday
<mdz> elmo: and is there a problem, or is it just a question of tuits?
<elmo> mdz: I've not had time
<mdz> ok
<mdz> Treenaks: a bit more patience, please
<Treenaks> mdz: OK
* Treenaks goes into sleep()
<lamont> Kamion: ppc ubuntu livecd is current
<lamont> as for kubuntu...
<pitti> jordi: I'm adding some langpacks (including catalan) to the install CDs now :-)
<lamont>   kubuntu-desktop: Depends: kdepim but it is not going to be installed
* jordi dances around pitti.
<jordi> GO pittiiiii!
<lamont> Kamion/elmo: did d-i get into the archive, and we want a new round of livecd rootfs builds?
<zul> later
<jani> anyone familiar with gtk-doc-tools/jade ? I got an error building a package
<lamont> Kamion: ??
<jani> -CAPS suffix in sgml ids ring any bell?
<elmo> lamont: d-i's is in for the big 3
<lamont> elmo: cool - starting livecdfs build then
<pitti> Hi carlos 
<lamont> elmo: is gpgsm gonna make it into main?
<Kamion> lamont: do the live cloops include d-i? I thought they didn't
<lamont> Kamion: don't think so - but they do include the kernel...
<elmo> lamont: I dunno, it's on the promotion list, pending approval
<lamont> anyway, fresh builds running on all 3.
* lamont makes a note to actually try and figure out w-b enough to teach it the ogre-model
<ogra> onions ?
<lamont> ogra: yeah.  that, and it smells.
<lamont> layers.
<Kamion> I must admit that the bloody enormous framebuffer I get when doing installs on Pegasos is pretty nice
<ogra> *g*
<lamont> http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<lamont> ogra: that's why gpgsm has me annoyed today
<Kamion> lots across by 63 down
<Kamion> if I've counted right
<lamont> Kamion: pixels or lines?
<mdz> elmo: d-i in -> with 2.6.10-5?
<elmo> mdz: yes
<mdz> elmo: thanks
<fabbione> mdz: the transition to -5 should be complete once lamont finish to build the Live CD fs afaik
<ogra> lamont, oh, red day...
<fabbione> mdz: everything else is up
<seb128> pitti: any news on this IPP printer issue ?
<pitti> oh, sorry, got completely buried in security stuff today
<fabbione> lamont, Kamion: i dunno you two.. but i think this time it went pretty smooth.. only 8 hours to do a full transition
<pitti> seb128: right, I should tackle this tomorrow
<carlos> pitti: hi
<seb128> pitti: np, we are just waiting for you to update for debian :p
<Mithrandir> hm, I slept over the meeting today.
<seb128> and would be nice to tackle that for hoary too :)
<mdz> mvo: here?
<Q-FUNK> pitti: was 0.29 kosher or was the last good one 0.28 ?
<mdz> fabbione: are those builds in progress now?
<fabbione> mdz: lamont just wrote he was building the livefs ...
<pitti> Q-FUNK: 0.28 was okay, we have 0.30 now which is fine, too
<pitti> Q-FUNK: the problem was the newer libgnomecups, which introduced a regression
<Q-FUNK> pitti: i thought that 0.30 has this regression issue?
<seb128> and which is needed for the new g-c-m
<fabbione> <lamont> elmo: cool - starting livecdfs build then
<Q-FUNK> ah ok
<pitti> Q-FUNK: (that's one of the reasons why I don't want to blindly upload new upstream releases into stable releases)
<seb128> (and me neither)
<fabbione> mdz: in the worst scenario everything will be ok tomorrow morning when the cron will do his automatic build
<mdz> fabbione: that scrolled off my screen while I was paying attention to other things
<Q-FUNK> _minor_ and not blindly :)
<fabbione> mdz: no problem :-)
<mdz> like the 450 bug emails I have in my box
<fabbione> mdz: of which 300 are the kernel bugs qa thing :-)
<seb128> mdz: you read all the bugs ?
* fabbione heads to bed
<ogra> seb128, do you just delete them ? :-P
<pitti> Night fabbione 
<ogra> ciao fabbione 
<fabbione> Kamion: i am going to test svenl patch for that eth driver tomorrow
<pitti> fabbione: wife is waiting? :-)
<seb128> ogra: no, I "just" read the GNOME ones usually
<fabbione> Kamion: i will make an image for you :-)
<fabbione> pitti: she is probably asleep already...
<ogra> seb128, heh
<fabbione> and i am tired too
<Q-FUNK> gnome128
<Q-FUNK> :-P
<fabbione> ahahha
<fabbione> me &
* fabbione &
<sivang> night fabbione 
<Kamion> svenl: well, it all boots fine for me on Pegasos, doesn't stop at cron or anything
<Kamion> fabbione: ok
<Kamion> lamont: lines :-)
* pitti gives his modem a rest, too. CU tomorrow
<Q-FUNK> Kamion: svenl is elsewhere?
<Q-FUNK> oh.. sorry no ;)
<Kamion> Q-FUNK: yeah, I know, he sometimes reads scrollback though
<Kamion> fabbione: right, seemed fairly smooth to me
<herve> hi
<herve> seb128, about the motu howl transition, verbiste recompiles fine
<seb128> cool
<herve> seb128, would I test another package you offered to help on?
<seb128> I don't understand the question
<herve> hey, quite many motu folks here!
<crimsun> we should all be in here :-)
<herve> seb128, if you're too busy to help on that transition
<ajmitch> herve: of course
<seb128> herve: nop, you need somebody to upload the package ?
<herve> seb128, yes I too young to upload myself yet :-)
<seb128> ah ah
<seb128> where is the package ?
<herve> green light to rebuild verbiste in a word
<herve> I'll put it online in a moment
<seb128> sure
<bluefoxicy> control
<bluefoxicy> I need control over polyp or esd
<bluefoxicy> preferably both
<bluefoxicy> MUST LOWER LATENCY.
* ogra yawns
<sivang> seb128: I have something pitti reviewed and besides one thing (which I have fixed now) he said it's fine, would you have time to review?
<seb128> you don't trust pitti review ? :p
<herve> bluefoxicy, was jack considered as an alternative in the end?
<ogra> lol
<bluefoxicy> herve: no :)
<sivang> seb128: I trust him! :-) I just want to finish with this package already :)
<bluefoxicy> polyp should have an arts compatibility library and module too, so we can have arts without having to link with Qt
<seb128> sivang: if he has reviewed it that's fine
<sivang> seb128: the last change he wanted me to do is to use _() straight on a string rather then using snprintf to format it.
<herve> sivang, it's in the course of the motu? then stress out motu uploads need three (?) reviews
<daniels> ogra: xrandr -q
<sivang> herve: not a MOTU upload, main :)
<seb128> sivang: where is the package ?
<herve> ho I shut up then
<sivang> seb128: http://muse.19inch.net/~sivan/g-c-m/sivan-gcm-crack.diff
<seb128> k
* ogra throws away 50 lines of xdpy pattern matching code :-P
<sivang> seb128: please look at the debdiff and oops on whatever you see could be dangerous
<ogra> daniels, thanks :-D
<dholbach> crimsun: 
<dholbach> checking whether make sets $(MAKE)... yes
<dholbach> checking build system type... Invalid configuration `x86_64-linux': machine `x86_64' not recognized
<dholbach> configure: error: /bin/sh config/config.sub x86_64-linux failed
<dholbach> configure: error: /bin/sh './configure' failed for cppunit
<dholbach> make: *** [config.status]  Error 1
<dholbach> pbuilder: Failed autobuilding of package
<sivang> seb128: he also wanted me to include l10n, should I integrate it for te same upload?
<dholbach> oops
<dholbach> sorry, wrong tab
<seb128> sivang: want to l10n ?
<sivang> seb128: yes, I'll add then and then request again your review
<sivang> seb128: should just be another patch right? just as my previous one..
<sivang> ?
<sivang> seb128: with the changes for the he.po file
<seb128> I don't understand what you want to do with the l10n
<seb128> oh
<sivang> seb128: I can provide hebrew l10n
<lamont> Kamion: why would a default hoary install + ssh-server still take passwords, with sshd_config saying PasswordAuthentication no?
<seb128> use the bugzilla bug for the desktop translation for that
<Kamion> svenl: interestingly, X starts up just fine here, without the need for any hacking
<Kamion> lamont: keyboard-interactive
<sivang> seb128: ok, I'll add the app name's there also.
<Kamion> lamont: try ChallengeResponseAuthentication no
<seb128> sivang: do you have an idea on #6945 ?
<lamont> ah, ok
<sivang> seb128: /me looks
<herve> seb128, packages online: http://deb.oursours.net/motu/
<seb128> herve: ok
<sivang> seb128: seems strange, I can't his the difference he is talking about
<sivang> seb128: *see
<seb128> k, thanks
<ogra> sivang, the default should be a sans terminal font, but it changes to a serif one
<ogra> thats how i understand it
<Kamion> svenl: ok, yaboot-installer changes uploaded too, should be ready to test tomorrow
<sivang> ogra: I don't get there over my hoary'
<sivang> ogra: I just tried to reproduce
<sivang> seb128: I cannot reporoduce, maybe I am not seeing the font difference?
<ogra> ah, ok
<Kamion> cron.daily running for new CD images, will do live build once that's finished assuming I'm still up
<seb128> sivang: dunno, I'm not sure to understand the difference/issue
<lamont> Kamion: ubuntu livecd fsimages are all current
<ogra> seb128, selected sans fort changes to serif, even if sans is selected
<ogra> font even
<ogra> seb128, terminal font that is, not the gtk one
<sivang> ogra: my font remaind the same after executing with the he locale
<seb128> ogra: right, but I don't get how the locale change the font
<Kamion> lamont: I've queued it up in my terminal input; assuming that connection stays running, they'll build ... :)
<ogra> seb128, it shouldnt and since this bug is from 26.02 i would tag it NEEDINFO, there changed a lot since then wrt locales and langpacks
<seb128> yeah
<sivang> ogra: how do you see the font changed?
<ogra> sivang, look at the screenshits
<ogra> s/i/o
<seb128> sivang: thanks for the comment on the bug
<sivang> seb128: no prob :) But I hope I didn't talk rubbish given what ogra just said :-/
<seb128> nop, the comment is just fine
<ogra> sivang, you said you cant reproduce, thats not rubbish
<sivang> ogra: I didn't even see the differences between his two screenshots :-) anywaysm, it would be nice to see what font he has before and *after* he changed the locale so it might be useful
<ogra> sivang, before: http://img60.exs.cx/img60/685/img34go.jpg
<ogra> sivang, after: http://img88.exs.cx/img88/3448/img17uq.jpg
<sivang> ogra: ok, thankss, I saw that now, but still I couldn't reproduce :)
<sivang> seb128: I'll do the upload tommorow with martin, I need to get some sleep, night
<sivang> night all :)
<seb128> k
<seb128> 'night
<dholbach> night sivan!
<sivang> night seb128, dholbach 
<jon1011> has someone seen metalikop ?
* Kamion -> bed
<ogra> sivang, night
<dholbach> jon1011: he's kop|gone 
<ogra> Kamion, sleep well
<jon1011> (he maintains the ubuntu .deb package for my app, appliworks, but I wasn't able to contact him for some days... and there is a new version of my app :p)
<dholbach> bye Kamion 
<jon1011> oh ok :)
<jon1011> dholbach: thx :)
<dholbach> jon1011: mail him the location of an rss-feed or something :-)
<jon1011> dholbach: yes I will do this :p
<dholbach> jon1011: good
<jdub> uuugggh
<jdub> man
<jdub> uuuuuuggghhh
<ajmitch> morning jdub 
<dholbach> hellas jdub 
<jdub> ajmitch: uuggghh.
* ogra shakes head about the acrobat thread
<seb128> hey hey jdub 
<ogra> jdub, i conquered main today :) so i could do the xscreensaver patching myself now ;)
<jdub> ogra: rock!
<ogra> yay :)
<bluefoxicy> doko: still at it?
<herve> seb128, thanks for the upload
<seb128> herve: np
<seb128> thanks for the work on the package
<GheRivero> res
<mdz> lamont: livefs builds finished and successful?
<lamont> ubuntu ones were, Kamion has the cd build queued up on his termina
<lamont> l
<mdz> ah, ok
<lamont> <Kamion> lamont: I've queued it up in my terminal input; assuming that connection stays running, they'll build ... :)
<lamont> mdz: that was 13:56 your time
<mdz> looks like there's an install CD build in progress right now
<mdz> complete with jigdo images, so that'll be another hour or so *groan*
<lamont> right
<lamont> I think it's his array 7 candidate, maybe?
<mdz> lamont: I'm still getting bug mail on kernel-team; did you do the search&change-multiple exercise?
<lamont> yeah, but not again since you updated the qa default
* lamont fixes it one more time...
<lamont> mdz: btw, if gpgsm made it into main soon, the buildd's would be happier.
<bluefoxicy> hmm
<mdz> lamont: hmm?
<bluefoxicy> Would timidity enhancements be interesting to ubuntu?
<mdz> lamont: somebody upload a broken build-dep?
<bluefoxicy> I wrote a script, tmidity-update, for Gentoo a while back
<lamont> kdepim build-dep: gpgsm.  kdepim in main, gpgsm in universe.
<lamont> no joy
<bluefoxicy> it lets you manage multiple timidity patch sets by sticking them in a specific directory layout.  There's a system selected patchset, and a user selected one.
<bluefoxicy> the user can run timidity-update and change the patch set easily
<lamont> mdz: 6849 and 7229 are assigned to kernel-team - those should be the only ones getting mail to kernel-team... otherwise, bug #?
<bluefoxicy> the idea is to install midia, freepats, EAW, and shompatches all at once and switch between them
* lamont reassigns 6849
<lamont> ah, was jdub assigned them... :-)
* lamont notes that every time he goes into bz and looks at a bug or 2, he gets a ding on his quota meter.  damn verbosity.
<mdz> lamont: 1440
<mdz> 6849 you mentioned
<Riddell> mdz: kubuntu-default-settings also needs to go in main if it hasn't been put there already
<mdz> Riddell: no problem with kubuntu-default-settings
<mdz> Riddell: but a bunch of new build-deps are present now, and those packages weren't in the original list
<mdz> hence they have not had a supportability review
<mdz> and can't move into main yet
<lamont> mdz: ah, I only changed open bugs... time to go get the rest..
* ogra giggles about the acrobat7 thread
<zul> hey
<lamont> mdz: 23 more bugs tweaked
<jdub> seb128: dude
<jdub> seb128: http://www.xline.fr/index2.php?lang=eng
<jdub> seb128: wtf?
<lamont> mdz: but I'm not going to reopen 7001 just to reassign it.
<robtaylor> mm. who'se the ipv6 guru?
<lamont> mdz: livecd should blow it's brains out more soundly when it runs out of RAM...
<lamont> robtaylor: I think fabbione is the designated one, but what's the question
<lamont> ?
<lamont> mdz: instead of the silent sulk that it seems to do now...
<robtaylor> lamont: on my hoary (of today) box, gethostbyname seems to do an ipv6 query to the dnsserver, then go through the domian search, then finally (30 seconds later..) try an ipv4 query
<seb128> jdub: is that a real stuff ? :)
<zul> lamont: there is no build logs for fglrx-kernel-source?
<robtaylor> (as my nameserver doesnt understand ipv6 ;))
<lamont> zul: see http://people.ubuntu.com/l/linux-restricted-modules-2.6.10/2.6.10.3-5/
<zul> ah ok
<zul> thanks
<lamont> zul: apt-cache show pkg-name | grep Source
<lamont> if it doesn't say anything, that's the source name
<lamont> if it does, that's what you want to use
<lamont> robtaylor: yeah, that'd be a fabbione question.. no clue here... :-(
<robtaylor> lamont: heh, thanks anyway :)
<lamont> robtaylor: I was hoping for something trivial, so I could look like a guru...
<robtaylor> lamont: i was hpoing it'd be trivial too :)
<lamont> oh, it probably is.
<robtaylor> seemed to start sometime middle of last week
<lamont> one might look at the order of things in /etc/hosts, but that'd be a total guess
<robtaylor> lamont: hey, its worth a try..
<jdub> seb128: supposedly it's some ex-mandrake dude
<seb128> where have you read about it ?
<seb128> I've not heard about that before
<jdub> lxer
<seb128> and the website doesn't get a lot of stuff
<jdub> with a very broken english announcement ;)
<seb128> oh, I've switched in the french version directly
<seb128> I'm lazy :p
<herve> regular broken English speak by a French as for me ;-)
<herve> (s/speak/spoken - I'm a good example of broken English...)
<mdz> lamont: silent sulk?
<mdz> lamont: I'd rather expect it to sort of implode spectacularly
<mdz> practically every write failing, that sort of thing
<lamont> well, it kinda seems to go into a vm-thrash mode, at least for my bro
* lamont notes that ubuntu is #1 on distrowatch (last 3 months)
<lamont> and #3 in last 6
<lamont> "last 1 month" stats are kinda scary
<lamont> in a good way
<HrdwrBoB> yeah
<HrdwrBoB> it's a large margin
<seb128> what is scary is the bugzilla flood :p
<daniels> seb128: yeah :\
<zul> seb128: heh...been there done that recently :)
<zul> eh lamont?
<jdub> that's an *impressive* margin
<crimsun> lamont: got a buildd question if you have a sec
<lamont> fire away
<crimsun> lamont: both http://people.ubuntu.com/~lamont/buildLogs/g/gnuradio/0.9-2.1/gnuradio_0.9-2.1_20050301-1305-amd64-failed and http://people.ubuntu.com/~lamont/buildLogs/g/gnuradio/0.9-2.1ubuntu1/gnuradio_0.9-2.1ubuntu1_20050315-0738-amd64-failed show "checking build system type... Invalid configuration `x86_64-linux': machine `x86_64' not recognized"
<crimsun> dholbach and I have checked automake and autotools-dev versions
* lamont fetches
<crimsun> I've searched google as to how I might attempt to resolve the "$architecture not recognized" and can't find much. debian/rules does copy over the newer config.{guess,sub}
<lamont> sigh.. elmo: could I have gnuradio build-deps in the hoary chroot on concordia?
#ubuntu-devel 2005-03-27
<lamont> configure:2059: checking build system type
<lamont> configure:2072: error: /bin/sh config/config.sub x86_64-linux failed
<lamont> you mean that?
<lamont> haven't checked debian/rules and friends, but my bet is that they just update config.guess in the top directory, not in cppunit/
<lamont> -rwxr-xr-x    1 buildd   buildd      43458 Mar 15 07:40 ./config.guess
<lamont> -rwxr-xr-x    1 buildd   buildd      33085 Oct 26  2001 ./cppunit/config/config.guess
<lamont> after the build
<lamont> fails
<crimsun> ah, great catch
<crimsun> thanks much :)
<crimsun> (duh, the configure is for cppunit)
<lamont> elmo: nm on those build-deps.
<lamont> crimsun: :-)
<Riddell> mdz: could we also have kde-style-lipstik in main?
* lamont back in a few
<mdz> Riddell: same process and criteria as for anything else
<Riddell> mdz: of course
<Riddell> just giving warning :)
<mdz> Clint: what creates obj/Src/Modules/Makefile.in in the zsh build?
<Clint> not configure?
<mdz> ah, mkmakemod.sh
<Clint> oh, yes
<mdz> a goddamn maze
<Clint> it's much saner without the patch
<Clint> it's too bad libtool can't do it better
<ogra> could someone fix the topic in #ubuntu finally ?
<ogra> still states the abi breakage for -26
<ogra> mdz, thanks :)
<mdz> Clint: I wonder why you haven't encountered this failure in Debian
<mdz> maybe an accident of .diff.gz ordering
<Clint> if you're not touching any of the build system stuff, I don't see what would have broken
<lamont> mdz: is that really mkmakemod.sh.in.in??
<mdz> Clint: http://people.ubuntu.com/~scott/patches/zsh/zsh_4.2.1-15ubuntu1_unknown.patch
<mdz> Clint: that's all we change, apart from debian/changelog
<mdz> lamont: yes
<lamont> that's a maze.
<ogra> insane
<Clint> feel free to redesign it for me
<dholbach> i'm off to bed
<ogra> dholbach, no more wxwidget love tonight ?
<smurfix> Gah. http://www.ubuntulinux.org/support/, last item. Somebody pease remove that.
<smurfix> s/pease/please/
<dholbach> ogra: don't think so... no love any more tonight 
<Clint> what was the failure again?
* mvo -> bett
<ogra> night mvo
<ogra> night dholbach 
* mvo -> bed
<robtaylor> smurfix: wow, support for large plone folders, just what i've always wanted =)
<mvo> night all
<ogra> dholbach, but you should trigger the build before bed, then its probably done tomorrow :-P
<dholbach> ogra: the build breaks after 3 minutes, where extracting the chroot tarball and ./configure take at least 2m30s
<ogra> ouch, that needs a lot of love then
<mdz> Clint: the failure was it trying to run autoconf during the build
<mdz> Clint: which is what i just finished patching out
<dholbach> ogra: yes :-)
<mdz> Clint: it'll only happen if the timestamps fall the right way
<mdz> (the wrong way)
<Clint> and how are the timestamps getting horked?
<tp_> can I ask where should I report ooffice bug in the 1.1.3 (paste in oocalc inserts rather than overwrites.. http://www.oooforum.org/forum/viewtopic.phtml?t=15527)
<dholbach> *wave*
<ogra> night dholbach 
<tp_> it's down as bug #402004 for oo but it's closed with 'not ooffice bug' (blaming Novell by the looks of it)
<tp_> sorry bug  #40204
<Clint> mdz: okay, that patch is definitely broken
* Clint mutters incoherently.
* lamont must run to town for a bit...  back in a biut
<mdz> Clint: I assume by the .diff.gz ordering
<mdz> and various random buildd factors
<daniels> mdz: mkmakemod.sh.in.in?!?
<mdz> you guys act like you've never seen a .in.in file before
<mdz> there's one in, like, every gettext package ever
<daniels> yeah, I've seen .in.in
<daniels> kde has you write configure.in.in
<daniels> but two levels of abstraction to generate a shell script that apparently calls autoconf and generates Makefile.ins just sounds horrid
<daniels> almost makes me wish for imake
<Clint> it doesn't call autoconf
<daniels> (disclaimer: no, I'm not actually wishing for automake)
<daniels> Clint: ok
<Clint> it generates Makefile.in and other shell scripts which generate other things
<mdz> daniels: the shell script which is eventually generated by that .in.in produces a makefile
<mdz> er, a makefile.in
<mdz> which is turned into a makefile
<mdz> which calls autoconf
<Clint> twice
<daniels> that is so awesome
<daniels> s/wishing for automake/wishing for imake/
<azeem> you wish for automake?
<daniels> i wish for automake, yes
<Clint> automake would be a bit cleaner
<Riddell> does anyone know what hal-hotplug-map does and why KDE needs a symlink to pmount but gnome doesn't?
* ogra smiles
<ogra> ballon help in hwdb :)
<daniels> ogra: nice! :)
<ogra> yay
<ogra> daniels, wait after i hacked me through the night ;)
<ajmitch> ogra: trying to meet deadlines? :)
<ogra> hehe, yup
<daniels> ogra: heh
<tp_> is there a release of ooffice due for hoary (fix to nasty insert bug in oocalc, really nasty if you use it for financial)
* zul beats the drums for ogra 
<tseng> jeez eugenia cant stop
<zul> she ranting again?
<tseng> she "appologized" after restating that gnome doesnt care about users blah blah
<tseng>  On one hand, the controversy was positive, because it introduced a lot of people to the fact that many people believe that Gnome developers have not had an effective channel to receive and interpret feedback from users
<robertj> tseng: I don't know. Part of me says "dont go to he site" but the other part of me thinks noone in here will ever click on a banner there, ever.
<tseng> meh.
<zul> some chick ranting doesnt make me want to read it
<robertj> zul: stupid women ruining our software!
<zul> robertj: not exactly
<tseng> oh man.. fedora core 4 built by gcc 4.0
<zul> its all ranting with nothing good to say really
<crimsun> tseng: yep
<robertj> stupid women wanting to ruin our software ;)
<robertj> Any interesting things going on in fedora? Around Fedora 2 they were doing some nice python applets but after that things seemed to get very stale.
<zul> who cares its nasty fedora
<tseng> they seem to think that networkmanager actually works
<robertj> it doesn't
<robertj> ?
<tseng> not very well.
<robertj> works good enough for me
<bing> which package contains the live-cd partition detection code?
<bing> autopartkit?
<zul> cd 
<zul> oops
<dilinger> zul@freenode:~$
<zul> heh
<zul> i dont mean to
<mroth> pwd
<mike_douglas> Hi, where can I find some more info about using kickstart to automate a Ubuntu Hoary install?
<daniels> mike_douglas: unfortunately it's 2am where our installer guy (who has been doing all the kickstart stuff) lives
<mike_douglas> daniels: damn, could I have his email?
<jdub> mike_douglas: mail ubuntu-devel
<mike_douglas> alright
<dredg> holy crap it is 2am
<dredg> feck...
* lamont tries to fathom why aptitude: Depends: libapt-pkg-libc6.3-5-3.9 but libapt-pkg-libc6.3-3.9 is in the archive (hppa)
<Riddell> jdub: do you have the HTML for the new ubuntu site design?
<daniels> Kamion: new xorg will hit soon, which means that your greek stuff is fixed; mkfontscale moved xbase-clients -> xutlis
<Riddell> jdub: could you check over the two packages here?
<Riddell> http://halls.debian.net/~tom/packages/kubuntu-calendar/
<Riddell> neither they not ubuntu-calendar seem to get picked up by gnome-background-properties
<Riddell> s/not/nor/
<fabbione> morning
<ogra> morning
<lamont> morning fabbione 
<lamont> mdz: you about?
<mdz> lamont: vaguely
<lamont> I sent you some mail...
<mdz> saw it
<Treenaks> morning all
* ogra yawns
<fabbione> mdz: did everything go ok with the CD yesterday evening?
<mdz> fabbione: I was waiting for X to build
<fabbion3> ah ok
<mdz> looks like it's done
<mdz> lamont: what does royal replace?
<lamont> adare
<Treenaks> fabbion3: re: 7651 (2-line crasher/panic fix)..
<lamont> hi AnthonyTowns 
<fabbion3> Treenaks: ok
<AnthonyTowns> i didn't want to, the bad people made me
<dholbach> goooood morning
<ogra> moin
<svenl> Kamion: thanks.
<ogra> mdz, still alive ?
<mdz> ogra: yes
<mdz> watching the DPL debate
<ogra> i have rewritten the whole app (else i had no chance to get the changes in) will take me about 5-6h to finish it, is the CD build started already ?
<ogra> (5-6h given i dont fall asleep)
<mdz> ogra: I just started a build, yes
<mdz> but there will be more
<ogra> so would this timeframe be ok ? 
<mdz> I am very nervous about rewriting the app the day before the milestone release
<ogra> i think it will be ok, i tested it very extensively and fixed some bugs that were in before....but it leaves me at the point where i was yesterday night, having to  glue gui and sendpart together....
<ogra> its only the backend code i rewrote, the app itself couldnt handle repeats of the tests the way it was, it was needed
<svenl> damn, tzsetup-udeb failed with error code 1
<svenl> and there seems to be no /usr/lib/cdebconf/frontend/passthrough.so :/
<svenl> this apparently broke since yesterday.
<fabbion3> Treenaks: 7651 pending upload
<Treenaks> fabbion3: cool, thanks
<dholbach> morning d3vic3 
<whiprush> man dholbach, do you ever sleep? ;)
<crimsun> MOTUs don't sleep  =)
<whiprush> heh
<dholbach> whiprush: ask ogra... he's the hero :-)
<dholbach> whiprush: i slept nearly 6 hours
<whiprush> heh
<kagou> hi
<ogra> crimsun, i can confirm that :)
<crimsun> ;-)
<svenl> Mmm, seems install this morning is fully broken on powerpc.
<dholbach> d3vic3: do you have any idea on vtk?
<dholbach> d3vic3: some guy of a company wrote me a mail and asked how to fix it
<crimsun> hum.
<crimsun> doesn't it need to be __init__.py?
<dholbach> d3vic3: i always get this *GRR* "patented" message
<crimsun> let me apt
<crimsun> err, apt-get source
<dholbach> but herve found out there was a new version in debian
<dholbach> maybe it works better with the one they have
<crimsun> right, please ask elmo for a sync :-)
<dholbach> crimsun: a sync alone won't suffice
<dholbach> at least i fear it won't suffice because of our python2.4 changes
<crimsun> dholbach: right, but at least it will provide a new base on which to build -4ubuntu1
<dholbach> hi pitti 
<pitti> moin
<dholbach> crimsun: hmhmhmhhmhmmhm :-)
<pitti> dholbach: thanks for the DVDs, they arrived yesterday :-)
<dholbach> pitti: WOOHOO!
<dholbach> hai mvo
<mvo> hey dholbach 
<mvo> morning all
<pitti> hi mvo
<mvo> hi pitti 
<d3vic3> morning dholbach 
<d3vic3> dholbach, I haven't looked at it
<dholbach> d3vic3: ok
<kagou> Yes !!!!! -> http://home.btconnect.com/chrisandcarolyn/knoppix38-for-windows.png       An ubuntu version will be greater ;)
<kagou> http://slashdot.org/article.pl?sid=05/03/16/0210216&from=rss
<fabbione> kagou: that is running knoppix in qemu
<fabbione> everybody can do that
<fabbione> even you
<fabbione> with ubuntu
<kagou> it's a cd all made (may be the live cd of ubuntu can do that ?! )
<fabbione> you mean it runs automatically qemu to boot and so on?
<fabbione> yeah i see
<kagou> yes, you put the cd on the drive and it launch automatically this
<kagou> Image, you boot on the ubuntu live and you have ubuntu, you put ubuntu on the drive under windows and you got this (qemu)
<kagou> it's a GREAT feature
<mjg59> That would be neat
<kagou> i always hav my problem with dma. I must had "hdc=noprobe hdc=cdrom" to grub whereas hal crash. So i don't have DMA cdrom enabled. And i can't enable it. Whereas if i boot with ubuntu live my cdrom drive works fine and DMA is enabled.....
<Treenaks> kagou: what kind of controller?
<kagou> via
<Treenaks> via what?
<kagou> via82cxxx on  notebook with amd64
<kagou> Treenaks, http://forum.hardware.fr/hardwarefr/MiniPCPortablesPDA/sujet-1459-1.htm
<Treenaks> I've seen that
<Treenaks> I just don't have a clue about your problem
<kagou> yep nobody have an idea :/
<pitti> daniels: I just saw that you fixed the libXPM issue foar Hoary
<pitti> daniels: in your next upload, can you please add the CAN-2005-0605 to the changelog entry?
<daniels> pitti: oh yeah, sure
<daniels> pitti: i've got an xfree86 source for you in a bit, too
<pitti> cool
<kagou> why can't i open a distant file shared by samba with openoffice. It's seems that only gnome software can do that no ?
<Treenaks> kagou: everything using gnomevfs can do it
<kagou> openoffice do not use this no ?
<Treenaks> not that I know of.. but I don't use openoffice.. only abiword & gnumeric
<kagou> So under gnome, how can i mount a smb share, allowing me to open an xls file with openoffice ?
<Kamion> meh, ok, from what svenl said I guess I hosed tzsetup-udeb. damn.
<daniels> Kamion: g'morning
<Kamion> yo
<fabbione> hey Kamion 
<daniels> Kamion: lost tzsetup-udeb, gained greek support; you win some, you lose some ;)
<Kamion> uh
<Kamion> Replaces: rstart, rstartd, xbase-clients (<< 6.8.3-4), [...] 
<Kamion> daniels: I'm sure that wasn't the version you meant
<daniels> Kamion: FRIG
<daniels> Kamion: i mean, thanks.
<Kamion> ;)
<jordi> mvo: ping
<Kamion> shouldn't be fatal though
<daniels> it's orright, i have some more changes to push anyway
<jordi> mvo: apparently, I fucked up yesterday and failed to link agianst ncursesw.
<daniels> good catch though
<kagou> or is there a way to use smbmount/smbumount with nautilus ? (may be a script)
<jordi> it seems nano should be ok with ncursesw.
<jordi> I will try again now.
<daniels> pitti: chinstrap:~daniels
<mvo> jordi: all right, just keep me updated when there is something new to test
<jordi> mvo: I'm building
* pitti goes to university to get some bandwidth
<daniels> er
<daniels> so does anyone know where you upload warty-security to?
<daniels> do I just fire it at jackass and hope for the best?
<jordi> mvo: wow, this apparently works just ok
<jordi> mvo: introduces libncursesw dep tho
<mvo> jordi: what does upstream think about the snapshot? does he feels it's pretty stable? or should we rather wait ?
<Nafallo> nano? *crosses fingers*
<jordi> mvo: he thinks 1.3.6 is near releasing.
<jordi> I *believe* that would be a good version for Hoary.
<toresbe> hmmm
<toresbe> I'm concidering installing hoary on me laptop
<kagou> i'm sorry but i can't find "File/Script" under nautilus ... is it normal ?
<kagou> or in the help file of nautilus it's like that
<elmo> daniels: please coordinate with pitti
<mvo> jordi: can I download the test-package somewhere :) ?
<elmo> and don't just randomly upload - undoing broken security uploads is an annoying amount of work for me
<jordi> mvo: uploading in a min
<daniels> elmo: i talked to pitti who told me to upload and that he'd prepare the usn text when he got near bandwidth
<daniels> elmo: and this one builds ok for me in a warty chroot
<mvo> Mithrandir: around?
<Mithrandir> mvo: pong
<elmo> daniels: if your conversation didn't include where to upload to, I think you still need to talk to him :P
<kagou> sorry, i must logout and login to make the File/Script menu appear in nautilus ... :/ it's bad
<daniels> elmo: sorta hard given he left before I could ask
<daniels> elmo: but er yeah, it's been fired at jackass in any case (before you responded)
<elmo> sigh
<daniels> recommend killing it now if it needs to be killed
<dholbach> elmo: morning! could you please sync:  asterisk pstngw ?
<fabbione> jdub: ping?
<jordi> mvo: pd.o/~jordi
<elmo> dholbach: done
<dholbach> elmo: thanks :-)
<mvo> jordi: thanks, downloading
<dredg> elmo: what dholbach said, but s/asterisk pstngw/phpbb2/ :)
<Nafallo> mvo jordi: was that nano utf8-support I saw? :-)
<jordi> Nafallo: yah
<Nafallo> jordi: YAY! nice work! :-)
<jordi> Nafallo: http://people.debian.org/~jordi/nano_1.3.5-cvs-0.0_i386.deb
<mvo> jordi: still no luck here, I can type certain german umlauts (,<-capital)
<jordi> mvo: damn
<Nafallo> jordi: yepp, but no amd64 ;-). I'll just take the sources :-)
<daniels> sabdfl: yo!  how are the alps?
<daniels> if that's indeed where you are
<sabdfl> high all :-)
<ogra> pitti, found my bug ;) there as missing a else in another function
<sabdfl> daniels: ^
<ogra> hi sabdfl 
<ogra> hehe
<Kamion> pointy mountains
<jordi> mvo: I see it
<mvo> jordi: you can reproduce it?
<fabbione> hey sabdfl 
<smurfix> hey sabdfl. Good skiing?
<jordi> yes
<jordi> I'll tell david
<sabdfl> smurfix: i'm trying hard to look good moving at high speed on my face
<jordi> sabdfl: hey
<sabdfl> hiya jordi
<jordi> sabdfl: we need to talk about the May thing. Email, phone?
<smurfix> sabdfl: Practice makes perfect ;-)  and the abrasion gives you health-looking skin. Eventually ;-)
<sabdfl> jordi: mail easier, or sms me your phone number and i'll try call this eve
<jordi> sabdfl: basically we need an "official" confirmation that you'll attend, and then plan the other details. I don't know how or who handles this stuff for you.
<jordi> sabdfl: ok
<jordi> enjoy the skiing. (bastards! ;)
<sabdfl> i do try to avoid the skiing bastards and just hang out with other boarding doodz
<pitti> Hi sabdfl, welcome back
<sabdfl> sometimes a collision with a skiing bastard is inevitable, though
<pitti> :-)
<sabdfl> pitti: not quite back yet, just taking a break from my holiday
<pitti> ah
* pitti loves downhill skiing as well
* ogra never had ski on his feet
<Treenaks> pitti: Uphill skiing tends to be harder :P
<jordi> sabdfl: ah, I haven't tried snoboard
<jordi> +w
<daniels> sabdfl: ah, you're boarding?
<smurfix> Treenaks: Uphill skiing is *work*. Not my idea to spend a holiday at.
<pitti> Treenaks: oh, I do cross-country a lot, which involves a lot of uphill :-)
<jordi> mvo: if you see other things, please tell.
<mvo> jordi: ok
<jordi> mvo: I just sent mail to nano devel
<mvo> jordi: thanks!
<Kamion> svenl: just uploaded base-config 2.62ubuntu12 to fix the tzsetup-udeb crash you reported, thanks; will build new CDs as soon as it's in the archive
<svenl> Kamion: he.
<svenl> Kamion: is it possible to do preseeding from the netbooted yaboot.conf to set the url for package download to my apt caching proxy ? 
<Kamion> svenl: might be, but it's fiddly - today's netboot image should ask you for the mirror, though
<svenl> Ok.
<Kamion> d-i mirror/http/countries select enter information manually
<Kamion> d-i mirror/http/hostname string your.hostname
<Kamion> d-i mirror/http/directory string /ubuntu/or/whatever/
<svenl> i just need the new initrd.gz, right ? 
<Kamion> probably want new vmlinux too, we just did a kernel ABI change
<svenl> Kamion: the above is for the preseeding, right ? 
<Kamion> yeah
<svenl> Kamion: well, i downloaded the new vmlinux a couple hours ago, i g...
<Kamion> from /installer-powerpc/current/?
<svenl> wait, i don't even need to download a new vmlinux/initrd.gz
<svenl> yeah, that is something i wanted to ask you, the place i downloaded the stuff from, the last it has is march 10.
<svenl> http://archive.ubuntu.com/ubuntu/dists/hoary/main/daily-installer-powerpc/current/
<Kamion> right, use installer-powerpc/ for the moment rather than daily-installer-powerpc/; not sure what's happened to the dailies
<Kamion> but I uploaded a proper d-i yesterday so that should be good for now
<Kamion> OH
<svenl> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-powerpc/current/ then.
<Kamion> lamont: please re-enable daily d-i builds
<Kamion> d'oh, we forgot to turn them back on after the preview, it seems
<jdub> eek :|
<svenl> BTW, it would be nice if the web pages somehow showed the effective date too or something.
<Kamion> svenl: yeah, dunno why archive.ubuntu.com doesn't over HTTP; if you use FTP instead, it should show you
<dholbach> bon jour seb128! :-)
<pitti> Hi seb128 
<seb128> hi
<pitti> seb128: I'm at the uni again (still no network), but some guy on u-devel mentioned a libgnomecups fix
<seb128> yep
<pitti> seb128: I can't test this here, but it sounds promising :-)
<svenl> Ok, nice.
<Kamion> smurfix: cool, new keyboard selector stuff is nice
<smurfix> Kamion: I sure hope so. ;-)
<smurfix> Kamion: The one major problem I'm having with it is that switching languages confuses kbd-chooser -- it stores translated stuff in debconf
<Kamion> svenl: main thing lacking from the new yaboot-installer is a screen to tell you what OF variables to set
<Kamion> svenl: I'll port that over from nobootloader as soon as I get a chance
<smurfix> Kamion: Fortunately people usually don't do that.
<Kamion> smurfix: yeah, switching languages confuses several things actually
<pitti> seb128: hmm, actually it was a different bug. What a pity :-(
<Kamion> smurfix: like you end up with extra packages installed for all the languages you picked
<jordi> muh
<fabbione> is anybody familiar with usb and usb2 hardware? 
<smurfix> fabbione: somewhat
<smurfix> fabbione: What's the problem?
<fabbione> smurfix: there is something i am not really able to understand. my machine reports to have a USB2 controller. but if i plug a USB2 device in all the ports i can see outside the machine, it always get connected as USB1
<Kamion> smurfix: I'm happy for that to be a "don't do that, then" item for hoary
<fabbione> smurfix: at least according to lsusb
<smurfix> fabbione: Does it work if you load only the ehci driver?
<fabbione> the driver is already loaded
<svenl> Kamion: ok.
<smurfix> fabbione: remove the uhci driver then
<svenl> Kamion: did you have a chance to investigate the post-reboot failure i had ? Or at least see if you can duplicate it ? 
<dholbach> elmo: did you already sync mysql-dfsg-4.1 from sid? if not, could you do please? it contains a security fix
<smurfix> (or ohci, depending on your hardware)
<fabbione> smurfix: but the phisical ports are shared?
<smurfix> fabbione: Yes :-/
<fabbione> smurfix: ahhhh that explains
<fabbione> thanks
<Kamion> svenl: I couldn't duplicate it on my Pegasos
<svenl> Kamion: and should the yaboot executable not be distributed as part of the netboot dir ? 
<svenl> Kamion: strange.
<Kamion> svenl: yeah, it really should
<smurfix> fabbione: driver load order *sometimes* makes the problem go away
<Kamion> pxelinux is for other arches, after all
<smurfix> fabbione: ditto turning off legacy support
<Kamion> added to the ever-growing todo ...
<fabbione> smurfix: i am acutally trying to reproduce #7633
<smurfix> fabbione: Lemme check
<svenl> Mmm, a kernel with fixed gigabit ethernet would be nice too, hopefully we will have that for tomorrow.
<svenl> fabbione: i have the patch, no need to test.
<fabbione> svenl: ????
<svenl> no->now :)
<svenl> Kamion: mmm, it only proposes me us.archive.ubuntu.com, nothing more.
<svenl> and going back and entering the value manually fails.
<Kamion> svenl: which country did you select?
<svenl> us i think.
<Kamion> ok, that's kind of a feature :)
<Kamion> although going back and entering manually should work ...
<svenl> :)
<svenl> mmm, he doesn't like me entering 192.168.1.2:9999
<Kamion> does it crash out (red screen)?
<svenl> yep, but it may be my caching proxy which is playing tricks.
<Kamion> I had it working for my local mirror with expert mode yesterday; haven't yet tried the new choose-mirror
<Kamion> the general intent of which was to offer mirror configuration without expert mode
<svenl> Kamion: as said, need to check my apt-caching proxy setup, since it is a new one i am trying to package.
<Kamion> ah, ok
<Kamion> syslog should have details of what broke
<svenl> Kamion: wget -q http://192.168.1.2:9999/ubuntu//dists/hoary/Release
<smurfix> fabbione: Depending on your hardware you may not be able to reproduce the bug; I've asked the reporter to try swapping the load order / turn off legacy
<smurfix> fabbione: ... and the way the BIOS initially sets up the ports -- all of this is exactly the kind of backwards compatibility mess USB was supposed to prevent ;-)
<svenl> Ah, ... the apt proxy cacher dislike the // syntax.
<svenl> but i am told no kernel modules are found now :/
<fabbione> smurfix: clearly
<svenl> Mmm, the installer Packages file still contains -27 kernel modules :/
<pitti> elmo: please sync: mozilla-locale-de-at mozilla-locale-da mozilla-locale-fr mozilla-locale-it mozilla-locale-ptbr
<svenl> Filename: pool/main/l/linux-source-2.6.10/affs-modules-2.6.10-4-powerpc-di_2.6.10-27_powerpc.udeb
<svenl> when is the ubuntu mirror pulse ?
<svenl> Oh fun, fr.archive.ubuntu.com didn't pick up yet the -28 kernel.
<Kamion> no idea when the mirror pulse is, it'll vary I guess
<Kamion> I doubt they're all push mirrors
<Kamion> could just try archive.ubuntu.com for now
<svenl> fr.archive.ubuntu.com has yesterday's package list.
<Kamion> ok, things looking reasonably good for Array CD 7 with the exception of the incoming base-config bug fix
* ..[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 today; please test uploads to main carefully | Release Candidate: March 30th
<svenl> daniels: ok, the pcigart fallback will not be applied.
<svenl> daniels: what do you propose then ? Adding the BusType PCI if on pegasos ? 
<daniels> svenl: (but the xresprobe patch is good and I'll do that)
<daniels> svenl: to be honest I'm not sure I even want to do that -- that would be the first time we've ever added a custom driver option
<daniels> and I'm not really keen on starting to do so now ...
<svenl> daniels: write in the release notes : if you are on pegasos, and want DRI support, edit /etc/X11/xorg.conf and add option "BusType" "PCI" to the right place ? 
<daniels> svenl: i'm not the release notes man, i'm afraid, but that seems pretty sensible to me
<svenl> daniels: it is not a major problem, as X will work, altough sub-optimally, but it should be documented somewhere.
<daniels> svenl: right
<svenl> daniels: do you have a log of the conversation or something ? 
<daniels> svenl: basically, having a busted gart can give us really weird problems, and I'd rather have perfect rendering everywhere (but slow in some cases) than massive graphical glitches and 3D everywhere
<daniels> svenl: yeah, somewhere
<svenl> daniels: a busted gart -> a busted pci gart ? 
<pitti> seb128: just logged out and back it; I don't have a stale dbus instance any more :-)
<pitti> seb128: do you? if not, then the bug should be closed
<daniels> svenl: yeah, if you have a pci gart where you should have an agp gart, and things end up going wrong
<daniels> pitti: mmm ... i'm going to fix it fo'real in dbus tonight
<svenl> daniels: i don't understand this.
<dholbach> elmo: could you please also sync  libpri  from sid?
<daniels> svenl: well, imagine you have a proper agp radeon right, on a proper agp bus
<daniels> svenl: but your agpgart is broken in the kernel, so you can't set up an agp gart
<daniels> svenl: if you fall back to a pci gart here and try to set that up, there are some cases where things can go badly wrong
<pitti> daniels: does it still happen to you?
<svenl> daniels: this will only be a problem if there is supposed to be an agpgart, but it breaks for something else than your northbridges not being supported by agpgart ? 
<daniels> svenl: right -- if you don't have the right module loaded or something
<svenl> daniels: so what ? It is a kernel bug which needs fixing, no ? 
<daniels> pitti: no, but it should still be fixed properly :)
<daniels> svenl: not really
<daniels> svenl: it could be a configuration issue
<daniels> svenl: what I'm trying to say is that falling back to a PCI GART on AGP cards will cause problems sometimes
<svenl> daniels: so the problem is how to distinguish the case where there is no agpgart from the one where the agpgart is just broken.
<daniels> svenl: michel didn't merge that patch into x.org for exactly that reason
<svenl> yeah, but what alternate solutions can we use, if you refuse to add the BusType, and the fallback solution is broken.
<svenl> i will speak with michel about that, he too has pegasos hardware, so there should be chances that he has some idea.
<svenl> Kamion: there is mkvmlinuz as part of ubuntu base, but no support for it in the kernel ? 
<daniels> svenl: well, ideally there wouldn't be any AGP cards on PCI busses in the world, but it seems that that is not so
<seb128> pitti: I've reassigned the bug to daniels who knows what to do apparently :)
<daniels> svenl: we discussed also walking the PCI tree to see if the parent was a PCI->PCI bridge with AGP capabilites, but that won't work either
<daniels> svenl: in many cases, the bridge will be a sibling of the card, because PCI doesn't specify that the bridge must be the parent (sigh)
<pitti> seb128: gosh, these utopia bugs are killing me. everything works just perfectly for me on both computers...
<svenl> daniels: with such reasoning we would all use windows on lousy x86 hardware.
<pitti> seb128: can you reproduce any of it? (mounting at login, mounting at runtime, etc.)
<ogra> pitti, which one ? 
<pitti> ogra: ALL OF THEM
<pitti> ogra: :-)
<ogra> pitti, thom still has it it seems
<svenl> daniels: what about motherboards where the agpgart is not yet supported in the kernel -> no DRI for them ? 
<ogra> pitti, i dont see it here either
<thom> fraid so, yeah
<pitti> ogra: I think the slow hal is still an issue
<pitti> thom: ^ 
<daniels> svenl: well, yeah
<Kamion> svenl: no, mkvmlinuz is not in Ubuntu base; it's only in main due to a build-dependency from debian-installer
<ogra> pitti, not here...
<pitti> ogra, seb128: I rather mean the g-v-m/hal/gamin issues
<svenl> Kamion: "an error was returned while trying to install the kernel into the target system" :/
<ogra> pitti, h-d-m is fully populated (got it in my session on startup)
<pitti> ogra, seb128, thom: #7616
<thom> seb128: also, 7711 looks like it's a problem with nautilus/gamin
<seb128> thom: an idea on #7717 ?
<svenl> nothing particular in base-installer/kernel/failed-install
<Kamion> svenl: oh, damn. I wonder why I didn't see that.
<thom> seb128: files are downloaded to Desktop and then they don't show up
<jdub> yeah
<Kamion> mdz,jdub: can I add mkvmlinuz to ship, please?
<jdub> desktop handling seems b0rk
<svenl> nothing particular in syslog.
<jdub> there's another gamin released, which i'll upload soon
<Kamion> svenl: oh, of course, I didn't see it on netboot for obvious reasons, will be a problem on CD-ROM
<seb128> where is gamin 0.0.26 ?
<seb128> we can't debug on outdated versions
<seb128> jduuuuuub
<ogra> pitti, i'm pretty sure its not hal
<svenl> Kamion: i don't follow you on this, what is the problem ? 
<jdub> :-)
<thom> seb128: hrm, i'll look
<seb128> and there is no way to speak to DV if you run an outdated version
<seb128> the stock reply is "update first"
<Kamion> svenl: actually - with yaboot support, we can just tell base-installer not to install mkvmlinuz on chrp_pegasos
<svenl> Kamion: i am not sure the mkvmlinuz is the problem, is it ? 
<Kamion> svenl: what's in /var/log/messages?
<svenl> MD5Sum mismatch on linux-restricted-modules.
<svenl> mmm.
<svenl> i will do an install without apt cacher proxy.
<seb128> pitti: #7616 works just fine here
<Kamion> svenl: ah, that would do it, yes
<pitti> seb128: I'm typing a reply; can a non-running g-vfs-daemon be the culprit?
<ogra> pitti, 7616 works here too
<ogra> pitti, sure
<seb128> pitti: could, but I don't see a reason why it would not be running
<ogra> pitti, or a not running g-v-m
<pitti> I just asked for another full debugging cycle...
<pitti> anyway, if it works on many machines, it's certainly not RC
<seb128> right
<ogra> yop
<pitti> seb128: #7641 - this is supposed to work, right?
<thom> seb128: also, dingus clicking is seriously whacky; i have the url underlined, but sometimes don't get the Open Link or Copy Link Location options
<ogra> pitti, works for me with an nfs mount, but it has the user option set
<pitti> ogra: well, it needs the user option anyway, I suppose
<pitti> ogra: but it doesn't work for me, if I change fstab, the new user volume does not appear
<ogra> pitti, the reporter doesnt talk about it
<pitti> seb128: I have an idea; this worked before, but in Warty it directly monitored /etc/fstab. Now g-vfs uses hal, right?
<seb128> hum
<seb128> lemme read the few lines and the bugs
<pitti> seb128: if I add something to /etc/fstab, it should appear in the Computer menu
<seb128> it does here
<svenl> daniels: what about putting bustype into a debconf variable, which we can preseed or set from the installer ?
<daniels> svenl: radeon-specific driver option
<seb128> pitti: if that doesn't work dynamically that could be #6088
<pitti> seb128: oh, indeed. iz gamin boog :-)
<ogra> works here, even with such weird things like /dev/hdx
<seb128> thom: clicking where ?
<pitti> ogra: hmm, doesn't work for me
<seb128> gamin is the crap
<thom> seb128: on g-t, right clicking on urls (aka dingus clicking)
<ogra> pitti, just added:  /dev/hdx        /media/hdx      ext3    user,noauto     0       0
<pitti> ogra: and it appears in computer and places?
<ogra> and i have a hdx in the computer win
<pitti> hmm, not for me
<pitti> at least _one_ bug I can reproduce
<ogra> pitti, not in the places menu
<seb128> that works for sure here, I've taken some screenshots for GNOME 2.10 and computer was changing as soon as /etc/fstab is modified
<seb128> yeah
<ogra> seb128,  what about places ?
<seb128> places menu is #6088
<seb128> gamin monitoring b0rked
<seb128> that does that for gtk bookmarks too
<seb128> and the recent documents
<seb128> clear recent documents works for you ?
<pitti> seb128, ogra: ah, I know
<pitti> it does work if the mountpoint is below /media
<seb128> sometime that works, sometime not
<pitti> but not if it is e. g. /mnt, as in my case
<pitti> seb128: /media is treated specially in gamin, right?
<seb128> right
<seb128> it's doing some polling to not block umount
<seb128> instead of using dnotify
<pitti> so if it works with /media, but not with /mnt, is this #6088?
<seb128> no
<seb128> 6088 is the monitoring of a single file
<seb128> ie: ~/.gtk-bookmarks
<pitti> seb128: okay. g-vfs is also special-casing /media
<pitti> seb128: so I debug this there
<Kinnison> Hi guys
<ogra> why wouldnt it work with recent docs ? 
<pitti> Hi Kinnison 
<ogra> hi Kinnison 
<seb128> nice pitti
<seb128> hi Kinnison 
<seb128> mvo: here ?
<Kinnison> seb128: is there a known issue with evo sometimes not syncing IMAP state when you close it down?
* Kinnison can't nail it down currently; but I'm sure I've seen the behaviour
<svenl> Kamion: mmm, getting the stuff from us.archive.... i have the timezone error again :/
<seb128> Kinnison: not sure if there a bug, but I've noticed that this week
<mvo> seb128: yes
<seb128> mvo: do you know if #6088 is still here ? 
<mvo> seb128: I need to check, but it should work with the dnotify backend I guess
<pitti> bah, now it works even with /mnt. What a mess
<mvo> seb128: are you working on it right now?
<seb128> mvo: we are trying to do some bug cleanup in the gamin/mount/.. issues
<seb128> and I would like to figure what's fixed or not
<Kinnison> seb128: if I can work out how to reproduce it reliably I'll let you know; but I'm glad I'm not the only person seeing the behaviour sometimes
<seb128> Kinnison: k, thanks
<mvo> seb128: give me some minutes and I can tell you
<seb128> mvo: thanks, there is no hurry
<pitti> seb128: can you please upload gamin 1.0.0 which fixes all bugs?
<pitti> seb128: unfortunately I forgot the upstream URL....
<ogra> pitti, mnt works here too, even with hdx
<pitti> ogra: yeah, I try it again with a clean session (just logged out/in)
<ogra> pitti, i'm sure he can quickly wirte it :-P
<seb128> pitti: ask jdub, he's the brave gamin maintainer :p
<pitti> ;-)
<seb128> jdub: give us the crack
<seb128> duuuude
<ogra> quick
<daniels> seb128: that dbus thing totally sounds like a gtk bug, dude
<jdub> seb128: when i get home; at debsig atm :-)
<pitti> this bloody, bloody gvfs
<seb128> aaaaahhhhhhh
<pitti> ogra: /dev/hdx        /mnt            reiserfs        defaults,user,noauto,ro 0 0 -> works
<pitti> ogra: hdx does not exist
<seb128> stop blamin gtk, gvfs or whatever :p
<ogra> pitti, ah, i tried /mnt/hdx
<seb128> daniels: session should handle it ?
<ogra> pitti, here neither
<pitti> ogra: but with /dev/hda4 (which _does_ exist) it doesn_t work
<pitti> ogra: can you please try with a really valid partition?
* ogra has no spare partition
<daniels> seb128: yeah, but gtk is much more convenient
<daniels> seb128: (dbus's Xsession.d file needs to have --exit-with-session)
<ogra> pitti, i ould try with a cf card, wait a sec
<pitti> ogra: just try an existing one which is not mounted
<Kinnison> daniels: does it not?
<pitti> ogra: cf is already hotplugging
<daniels> Kinnison: not afaict
* Kinnison is sure he did that originally
<daniels> Kinnison: but I've been busy with evermore X stuff and not got to 0.23.4 yet
<Kinnison> if [ -n "$STARTDBUS" ] ; then
<Kinnison>   STARTUP="$DBUSLAUNCH --exit-with-session $STARTUP"
<Kinnison> fi
<pitti> ogra: try your swap partition
<Kinnison> on current hoary
<Kamion> svenl: us.archive.ubuntu.com != archive.ubuntu.com, it probably hasn't synced yet
<daniels> Kinnison: cock
<daniels> Kinnison: gtk bug then
<pitti> ogra: swap partition does not work for me either
<Kinnison> daniels: *g*
<seb128> or --exit-with-session b0rked
<Kamion> svenl: gb.archive.ubuntu.com == archive.ubuntu.com, or just use a.u.c directly
<dholbach> bbiab
<daniels> Kinnison: hm, I wonder if --exit-with-session works properly with signals
<daniels> Kinnison: i.e. start it, kill its parent with KILL, watch it fail to clean up?
<Kinnison> daniels: quite possibly not. dbus-launch is utter cock
<daniels> or something
<daniels> Kinnison: yeah
<svenl> Kamion: yeah guessed such.
<ogra> pitti, only moans about the non existing mountpoint
<Kinnison> daniels: sic sjoerd on it :-)
<pitti> ogra: darn, it doesn't display at all with /dev/hda3
<ogra> pitti, but shows up in computer
<Kamion> svenl: I *did* only do the source upload an hour and a half ago or so :)
<svenl> Kamion: :)
<Kamion> but a.u.c has it now
<ogra> pitti, sorry, made a mistake, youre right
<ogra> typo
<ogra> pitti, but my swap is mounted....probably g-vfs knows that ?
<pitti> ogra: dunno, could be
<mvo> seb128: it looks like #6088 works with dnotify
<ogra> did you swapoff ?`
<pitti> ogra: but it doesn't work either with an unmounted partition
<seb128> mvo: k, feel free to close it then :)
<pitti> ogra: no, I kept it mounted
<daniels> Kinnison: nah, I'll take care of it, have other dbus stuff to do tonight anyway
<ogra> pitti, let me try to manually unmount the cf card, then i can play with it...
<Kinnison> daniels: cool
<mvo> seb128: shouldn't we leave it open as a test-case for the inotify stuff?
<seb128> mvo: dunno but any way to make it clear that's it should not be in the hoary scope ? the current situation with gamin issues is a mess
<ogra> pitti, shows up, moans about the non existing mountpoint
<seb128> that's not clear what is an issue or not
<seb128> I don't really care about inotify if we use dnotify, that's just doing noise
<mvo> seb128: I retitled the bug and added a explaination that it does work now with dnotify
<seb128> thanks
<pitti> argh
<pitti> why doesn't the g-vfs package respect DEB_BUILD_OPTIONS?
<seb128> ?
<seb128> gnome-vfs2 you mean ?
<seb128> it uses CDBS and it does
<pitti> yeah
<pitti> DEB_BUILD_OPTIONS=nostrip,noopt debuild -us -uc -b
<pitti> still it's compiled with -O2
<seb128> pitti: weird
<pitti> CFLAGS="-O0"...  is passed to configure correctly
* pitti tries again
<pitti> seb128: hmm, works now, seems I didn't clean properly. Sorry for the noise
<seb128> np
<seb128> pitti: http://lists.debian.org/debian-gtk-gnome/2005/03/msg00031.html
<d3vic3> heh
<seb128> another information that could be useful
<pitti> after hibernating? yeah, I could ask this
<pitti> although my laptop also resumed from sleep when I tried all this
<pitti> (however, I reloaded the usb host controller modules)
<pitti> seb128: gamin 0.0.26? does it fix more? :.-)
<tseng> the fixes arent something that we've seen abundantly
<pitti> seb128: is it possible to start g-vfs-daemon in the foreground in a console?
<seb128> sure
<pitti> everytime I kill it it respawns in the background
<seb128> gnome-session-remove nautilus
<pitti> ah, cool
<seb128> killall gnome-vfs-daemon && /usr/lib/gnome-vfs2/gnome-vfs-daemon
<pitti> thanks
<seb128> np
<pitti> seb128: then I see g_warning() and friends?
<seb128> yep
<svenl> Kamion: where is yaboot post-install ? 
<svenl> usr/lib/yaboot/yaboot ? 
<svenl> Kamion: ok rebooting with the generated yaboot.conf
<Kamion> should be boot/yaboot
<Kamion> I stuck a symlink in
<Kamion> but usr/lib/yaboot/yaboot should work too
<seb128> lunch time, bbl
<svenl> Kamion: Ok, seems to work, the problem i had yesterday is not present.
<svenl> will test boot/yaboot on next reboot.
* Kamion has the Pegasos in the installer, and is waiting for his local mirror to sync before running the rest of the test
<Kamion> cool
<Kamion> I uploaded yaboot-installer half an hour ago or so with some extra nobootloader-like text that gets displayed as a note
<svenl> daniels: xresprobe fix is not yet in though.
* pitti -> lunch
<svenl> Ok, but it was not yet used, i think, will try again later.
<Kamion> yeah, not built yet
<Kamion> in fact source not even in the archive yet
<daniels> svenl: no, I'm still working on xresprobe, have other things to do for that upload
<jbailey> thom: ping?
<Kamion> hmm, I am totally amazed that CDs from the last four days have worked at all; override file generation was geb0rken
<Kamion> oh well, fixed now
<jordi> pitty?
<jordi> er
<jordi> bleh.
<jordi> jbailey: yay. apparently it got accepted into the review queue :)
<jbailey> Kamion: Hey, thinking of which.  ISTR that to create lvm/raid partitions, I used to select that instead of 'ext3', etc., but I didn't see it in the list on yesterday's daily or the one from 4 days before.  Where do I set that up now?
<Kamion> jbailey: should still be there
<jbailey> jordi: Which 'it'? =)
<Kamion> jbailey: "physical volume for LVM" etc.
<jbailey> Kamion: 'kay, I'll dig to figure out why it's not a bit later then.  
<svenl> daniels: ok. you didn't reply to me about using a debconf variable for the bustype thingy though.
<jordi> jbailey: the talk proposal
* Kamion is not especially keen on setting random debconf variables for X in the installer, if he can possibly avoid it
<Kamion> it would be code in two places for no reason
<svenl> Kamion: yeah, well.
<jbailey> jordi: Yes, of course.  What I'm really impressed by is that I've received *no* requests for talks to be added after the deadline.  I think the closest to the wire was an email 8 minutes before. =)
<Kamion> X fetches debconf stuff from d-i, but not the other way around :)
<svenl> Kamion: do you see another solution ? pcigart fallback was rejected, and daniels don't want to do a check for pegasos and set the option.
<svenl> Kamion: euh ?
<Kamion> plus getting debconf questions to X from d-i requires rather special effort
<svenl> Kamion: the idea is that we have per-subarch logic in d-i.
<svenl> Kamion: so we just set one variable if we know we are on pegasos, and X then reads it or something.
<Kamion> nope
<Kamion> if the bustype facility's added at all, X should work it out for itself. I don't want the installer getting involved in that sort of thing.
<svenl> Kamion: ok.
<Mithrandir> jbailey: so I was the closest to the wire?
<Kamion> At the moment, the installer's responsibility ends when X starts, and I very much like it that way
<Mithrandir> yay me. :)
<jbailey> Mithrandir: I'm trying to remember if it was you or taggart. =)
<Kamion> it relieves the installer of having to care about X at all
<svenl> Kamion: seems more logical to me too.
<daniels> svenl: mmm, i'm kind of uncomfortable having debconf variables for specific options for a specific driver for a specific subarch, y'know?
<Mithrandir> jbailey: taggart was like more than an hour.
<daniels> that code is already horrible enough
<jbailey> Mithrandir: Not when I got the email, though.
<svenl> daniels: i still don't understand what metaphysical opposition you have in adding a line checking for pegasos and adding Bustype though.
<Mithrandir> jbailey: possibly OF, since Matt's went through without moderation holdup.
<jordi> jbailey: mine must have been that one
<daniels> svenl: because we've never done it before for anyone.  the debconf code is already really really horrible and unmaintainable, and bloating that up with a whole bunch of hacks for specific machines (which are imo broken anyway) is just not the way to make it better.
<svenl> daniels: would you accept a patch in the radeonfb driver which checks for pegasos and set UsePCI or whatever ?
* jordi tickles daniels.
<svenl> err, radeon X driver even.
<daniels> svenl: that sounds really horrible ... how do you check for that in an X driver, though?
<svenl> daniels: so there is no solution to this ?
<Mithrandir> daniels: fd = fopen("/proc/cpuinfo", "r"); :P
<svenl> daniels: you read for the presence of a marvell MV643xx northbridge in the pci tree ? 
<svenl> daniels: something akin to the following kernel code : 
<svenl>         if ((ret = pci_find_device(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360, NULL))) {
* daniels screams.
<svenl> We know if we find such a northbridge, that we cannot have agpgart, since this northbridge has only pci ports.
<svenl> daniels: why ? 
<daniels> that's ... it's really horrible
<d3vic3> O.O
<daniels> i know it works, but why should radeon_driver.c know about specific northbridges?
<svenl> daniels: there is code in X for looking for the pci tree.
<daniels> yeah, I know
<daniels> but I just don't see why radeon_driver.c should have knowledge of how specific northbridges are wired?
<svenl> daniels: because it otherwise set erroneously the UsePCI field ? 
<daniels> i really, really still think that the root of this problem is putting an agp slot on a pci bus
<daniels> and that no-one should ever does this
<daniels> svenl: how's it erroneous?  the card's all like 'hey yeah i'm agp'
<svenl> daniels: you know there are agp->pci converters and vice-versa ? I have seen those ? 
<svenl> daniels: so what do you propose ? 
<daniels> svenl: i assume those would be smart enough to mask out the agp cap field?
<daniels> svenl: i propose fixing the hardware, honestly ...
<svenl> daniels: mmm.
<daniels> i'm just not sure that dri on those sorts of systems should *ever* be supported out of the box if it means horrible hacks like that
<svenl> daniels: the agp cap field is something found in the pci config region of the card, right ? 
<svenl> daniels: you are being despreciative.
<daniels> svenl: yeah, it's found in the PCI config region
<daniels> svenl: not really -- I mean, I'm sure you could come up with clean code
<daniels> svenl: but radeon_driver.c is a *display* driver, dude!
<daniels> why should it ever need to know anything about northbridges?
<svenl> the pci config stuff is read through RTAS, so in theory i could fix the OF rtas callback to patch the pci config read for the agp bus.
<Kinnison> Won't this change have to be made to every driver which might be for a card which could get plugged into the pegasos' slot?
<daniels> svenl: err ... yeah, that would work, but that's also strikingly horrible
<Kinnison> Or is the radeon wired onto the board?
<svenl> daniels: right, the right place is to have a check in the configuration step to setup the BusType option, it is easy (1 line), and the right place, but you refuses it because you never had to do this before.
<daniels> svenl: this sort of the thing is the reason why very, very few people have ever considered putting agp slots on pci busses, i'd imagine
<daniels> svenl: no, and it should never have to be done
<svenl> Kinnison: basically, the northbridge has two pci-x buses, and one is maskeraded as agp slot so people can easily find graphic cards to plug in it.
<daniels> Kinnison: (iow, yes)
<Kinnison> svenl: Oh dear god!
<Kinnison> daniels: ergh
<svenl> daniels: this is the sort of thing why very very few people do desktop hardware apart from cheap x86 hardware.
<Kinnison> does the pci conf data get read via the kernel?
<daniels> Kinnison: yeah, it's a blob
<svenl> Kinnison: notice that ECS (second x86 motherboard manufacturer) does the same thing with agp-express.
<daniels> http://people.ubuntu.com/~daniels/
<daniels> er
<daniels> http://people.ubuntu.com/~daniels/pcibustype.c
<svenl> Kinnison: via rtas through the firmware.
<daniels> basically, you check one bit to see if you have caps, then you look at a linked list and walk it to see if you have an agp cap
<daniels> but doing that would potentially involve rewriting the entire capability field
<daniels> consider the following situation
<daniels> #1: power management capability, next capability #2
<daniels> #2: agp capability, next capability #3
<daniels> #3: some other capability, next capability 0x0
<svenl> daniels: wait a minute, i have to make a phone call to our hardware guys, maybe there is a firmware level solution to this.
<Kinnison> daniels: ergh!
<daniels> now you can't just kill #2 completely, you'd have to set #1's next field to #2's next field, really
<daniels> which is a really horrible hack
<daniels> svenl: ok ... but honestly, no disrespect, ecs are known to make really cheap and shitty hardware
<daniels> svenl: if you want to compare to x86 oems, ecs is not the one to aim for
<svenl> Kinnison: do you know of a northbridge manufacturer who proposes powerpc northbridge with agp capacity ? If so please give us his coordinates.
<Kinnison> svenl: Dunno; not a platform I care about
<svenl> daniels: they did it, and you will encounter this problem in the future again.
<daniels> svenl: dunno, but apple seem to have it working
<daniels> svenl: ask them? ;)
<daniels> svenl: i know we'll encounter this problem in the future, but that sort of setup is imo just so pathologically broken that we can't expect to support dri out of the box on it
<svenl> daniels: do you seriously think apple will sell us northbridges, when they killed the OEM market a couple year back ?
<svenl> daniels: so you think a release not is less work than a one line shell script fix ? 
<daniels> svenl: i think it's a less bad idea
<Kinnison> daniels: How hard would a server option of something like "-all-agp-is-pci" /
<daniels> daniels@catsby:~xap% wc -l debian/xserver-xorg.{config,postinst}.in
<daniels>  1633 debian/xserver-xorg.config.in
<daniels>   732 debian/xserver-xorg.postinst.in
<daniels>  2365 total
<Kinnison> s@/$@be?@
<svenl> Kinnison: there is a radeon driver config option : BusType PCI for that.
<daniels> svenl: this is the sort of thing I have to contend with already.  now imagine if I start adding in checks for various subarchitectures, subsystems, all that sort of thing.  it's going to get huge, and unmaintainable, and one day I'm just going to snap and kick it all out of the debconf code, and we'll be back to square one.
<daniels> svenl: so I'm just going to keep assuming that, given AGP and PCI are physically different, any AGP card is on an AGP bus
<daniels> any PCIE card is on a PCIE bus, and any PCI card is on a PCI bus
<daniels> there's a reason they're not pin-compatible
<daniels> i think that, given the number of people who have these sorts of 'solutions', this is a reasonable thing to assume when the only penalty is losing DRI support out of the box
* Kinnison thinks daniels has a point
<svenl> daniels: wait i speak with hw guys
<daniels> svenl: ok
<Mithrandir> svenl: dude, finding a supplier who sells AGP and PCIe Northbridges for PowerPC CPUs took me less than five minutes.
<svenl> on the phone.
<mvo> seb128: is nautilus-cd-burner supposed to work with dvd-rams?
<svenl> Mithrandir: let me guess, it is Mai ? 
<svenl> Mai logic even ? 
<Mithrandir> yes
<svenl> they happen to have non-working dma controller though.
<Mithrandir> all their DMA controllers are broken?
<daniels> surely you could say 'we'll pay you for agp+dma'
<svenl> and refused to sell us more chips two years ago because they wouldn't admit their chip was buggy.
<daniels> same to marvell
<svenl> Mithrandir: they consider it a feature that dma or whatever only works in non-cache-coherent mode.
<svenl> Mithrandir: which makes it unusable for desktop linux, or so said benh on debian-powerpc some time back.
<svenl> daniels: ok.
<daniels> not that agp and cache coherency play well together at all :P
<seb128> mvo: I guess so, dunno the difference between the differents DVD types
<svenl> daniels: i will implement a firmware level workaround to map out the agp cap, it is not trivial work though, and probably at least an order of magnitude more involved than fixing that as a config option.
<mvo> seb128: hrm, I just had problems with it (kept telling me to insert a medium), but I will do some more testing
<svenl> daniels: well, if we had unlimited amount of cache available, we could design our own northbridge like apple does.
<daniels> svenl: i understand, but you'll have these problems also if someone plugs in, e.g., an nvidia card
<daniels> svenl: and i know it's frustrating for you, but honestly, radeon_driver.c really isn't the place for it
<daniels> if you put agp slots on a pci bus ... you get to fix it up
<svenl> daniels: nvidia cards are evil, and there is no powerpc 3d support anyway.
<svenl> daniels: i will fix it.
<daniels> svenl: i know that, dude, but i'm just saying that you'll continue to have these problems across more than ati
<jordi> mvo: found anything else?
<daniels> and we'll be carrying that patch forever -- there's no way upstream would ever accept it (i wouldn't even bother trying)
<svenl> daniels: as far as linux on powerpc is concerned, only ati is a solution.
<daniels> so the pegasos would only work with ubuntu and older versions of debian, not with gentoo or whatever
<svenl> daniels: only as long as it takes me to fix the firmware.
<svenl> daniels: but the more stuff i add to the TODO list, the less chance i get to make a new firmware release before the hoary release, which is what i wanted.
<daniels> svenl: right.  again, i understand that this sucks for everyone involved; i'm not doing this just because i hate you.
<daniels> it's just that this is the best option for a) genesi/pegasos, b) ubuntu, c) xorg, d) pegasos users
<svenl> ok, have to go now, will fix the firmware as best i can.
<daniels> cheers
<mvo> jordi: I didn't tested it much more, I don't have that much utf-8 documents (yet)
<svenl> daniels: well, having the one line patch in for hoary and dropping it as soon as i fix the firmware would be another solution.
<svenl> Kamion: ubuntu install finished
<Kamion> cool, working?
<jordi> mvo: nod
<Kamion> I'm still waiting for xorg to mirror, since it's ahead of yaboot-installer in the list <mutter>
<seb128> thom: nice try to blame nautilus :p
<pitti> seb128: hah
<pitti> (process:32655): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path: assertion `local_full_path[0]  == '/'' failed
<pitti> Speicherzugriffsfehler
<pitti> ^ SIGSEGV
<svenl> Kamion: yep, but i have no mouse connected.
<daniels> Kamion: and you win another xorg upload reasonably soon
<seb128> pitti: utch
<svenl> but i loged into X.
<seb128> pitti: what do you do ?
<Kamion> alt-f1 pops up a terminal I think
<pitti> seb128: debug and fix it :-) (at least try to)
<pitti> seb128: but this might be the reason why all the computer/places stuff does not work
<svenl> Kamion: and the yaboot symlink in boot also worked.
<pitti> seb128: becuase g-vfs-daemon starts over and over again
<Kamion> svenl: next yaboot-installer directs people at boot/yaboot via a note
<seb128> pitti: "what do you do" == "what do you do to get the crash"
<ogra> pitti, hmm, could explain the hal slowdown too (if anybody still sees it)
<Kamion> svenl: the symlink means that having separate /boot and / partitions probably won't work, though
<Kamion> svenl: but I ran out of time to hack mkofboot
<pitti> seb128: oh, just start it, and touch /etc/fstab
<svenl> Kamion: mmm.
<ogra> pitti, in fact also thims bug could be covered there
<ogra> thoms even
<svenl> Kamion: can you then : check if we have a separate /boot, and copy yaboot if we do so ? 
<svenl> Kamion: alternatively we could put a symlink in /boot before mounting /boot :)
<Kamion> svenl: as previously discussed, need to make mkofboot/ybin do the copy because there needs to be a trivial way to update the copy of yaboot there
<pitti> seb128: hmm, touch is not enough. but saving in an editor triggers the segfault
<svenl> Kamion: ok.
<Kamion> and mkofboot is really the right place, it's exactly analogous to installing the bootloader in the bootstrap partition on other subarches
<svenl> Kamion: altough i distrust mkofboot, it will just reformat /boot if we are not carefull.
<svenl> Kamion: ok.
<Kamion> and eventually it could update the nvram etc.
<Kamion> (once the OF facility's there)
<pitti> seb128: ah, there is another messsage before, saying "unable to stat /etc/fstab"
<pitti> seb128: this is certainly at the moment when vim creates a new file -> race condition
<svenl> Kamion: i have updating the nvram through rtas also on my TODO list, but as daniels just added me an item, i am not sure i will make it.
<Kamion> that's why I didn't have time, I needed to hit mkofboot with a largish hammer
<Kamion> svenl: the yaboot-installer note's fine for hoary, certainly
<svenl> Kamion: what about making sure /boot or / is a yaboot readable partition though ? 
<Kamion> svenl: oh yeah, probably need to do partman finish.d hooks
<Kamion> I have your list written down
<seb128> pitti: doesn't crash here while editing with gedit
<svenl> i think yaboot can do : ext2/3 reiser and xfs.
<svenl> and apart from that resorts to the OF, which can do the ones of the list i gave you.
<svenl> Something is fishy with yaboot though, since it has iso reading code, so why does it fallback to fs_of for cds ?
<Kamion> it doesn't have ISO reading code
<Kamion> it has fs_iso.c, but if you look at it, it's just a stub
<svenl> fs_iso.c:iso_read(      struct boot_file_t*     file,
<Kamion>      return FILE_ERR_BAD_FSYS;
<Kamion> it's a stub, like I say
<svenl> Ah, ok.
<Kamion>  *  fs_iso.c - a non-implementation for the ISO9660 filesystem
<svenl> makes sense then.
<Kamion> I don't know why it's there
<svenl> nor me, and i am not interested.
<Kamion> I imagine benh meant to write it but never got round to it
<robtaylor_> fabbione: ping?
<svenl> Kamion: the real problem is that benh gave over maintainership to Ethan, who didn't do is job.
<svenl> Kamion: (and that is benh speaking)
* Kamion -> lunch, no point sitting here waiting for the mirror
<d3vic3> Kamion, #7729, #7730, #7731, #7733
<d3vic3> I think this guys just keeps send coz there is no reply 
<d3vic3> s/guys/guy/
<svenl> Kamion: ok, now i only need to get the gige patch in, and daniels needs to upload a fixed xresprobe, and you need to add the note and the partman stuff, and the rest is firmware level support i need to write.
<trukulo> daniels, one thing (this channel for this question) atitvout doesn't work with ati driver, but with vesa in xorg
<svenl> Kamion: or is it something else you see missing ? 
<trukulo> anything related to vbe, do you know anything bout it?
<daniels> trukulo: yeah, i'm working on tv out support for the radeon driver in my free time
<daniels> trukulo: but i haven't had a chance to work on it in weeks, unfortunately
<trukulo> daniels, ati igp i mean :(
<trukulo> does radeon works with igp for tvout? (for normal use, works very well)
<trukulo> if you need test user, here i am
<daniels> trukulo: well, it will when I'm finished with it ;)
<daniels> ah awesome, thanks -- I'll grab you when it's done
<trukulo> when you can, of course
<daniels> might be a while tough, real life is lots of fun right now
<trukulo> i'm not in a hurry :)
<daniels> rad
<Kamion> d3vic3: sigh ...
<Kamion> svenl: the note's done, partman stuff is minor but I'll look at it
<daniels> svenl: fixed xresprobe is already upload
<daniels> +ed
<Treenaks> daniels: scary, scary changelog
<daniels> Treenaks: i try
<kagou> seb128, martin pitt est sur irc ? si oui quel pseudo stp ? (en supposant que tu le connaisses bien sur ;) )
<seb128> pitti
<mvo> does anyone else having problems copy-n-paste text from emacs to gtk-apps?
<kagou> sorry for this french message
<daniels> (for what it's worth: the reason I consider that change worthwhile is because we *can't* just assume every card ever supports 24bpp, so probing to see whether they do is worthwhile)
<pitti> kagou: EDONTSPEAKFRENCH :-)
<kagou> :p
<Treenaks> daniels: there must be an easier way to probe though
<seb128> pitti: that's why you are bothered with language packs :p
<ogra> pitti, er hat gefragt ob seb dich kennt ;)
<jordi> pitti: duuude
<daniels> Treenaks: yeah, we could theoretically probe via vbe, but most vendors seem happy to ship with incomplete vbe mode lists
<seb128> ogra: I spreche deutsch :p
<jordi> pitti: is there any daily iso that includes ca already?
<daniels> Treenaks: also, doesn't work on !i386 until after hoary
<seb128> s/I/ich/
<pitti> jordi: today's should
<ogra> seb128, oops *g*
<jordi> pitti: kewl
<ogra> seb128, mon francais est tres bete
<Kamion> jordi: careful to get 20050316.1, 20050316 was hosed
<seb128> ogra: in fact that's not true, but I can sort of read it (8 years or german at school)
<jordi> Kamion: thanks
<daniels> Kamion: so, uh, you know how your mirror was hurting from xorg?
<Kamion> yeah
<daniels> Kamion: how's it feeling now?
<Kamion> still is, as a matter of fact
<daniels> oh
<daniels> that would be amusing, then
<Kamion> next mirror run won't be until tonight :P
<daniels> heh
<ogra> seb128, i had 5 years of french, was my worst subject, but two months normandie tought me a lot
<daniels> well, don't schedule any other bandwidth-crunching tasks for tonight
<ogra> taught even
<pitti> ogra: I learned Russian for 8 years :-) no french at all
<Treenaks> pitti: in some ways they're alike...
<Treenaks> (like most European languages are "alike")
<ogra> pitti, at lest you could survive in the eastern countrys, i couldnt :)
<trukulo> you don't need language to survive in a country
<trukulo> you better have money ;)
<Kamion> daniels: do I need xorg 6.8.2-5 for Array CD 7, then?
<Treenaks> trukulo: waving a credit card tends to work :)
* Kamion prays for modular X for breezy
<trukulo> Treenaks, or don't lose your pants as jeff
<Treenaks> trukulo: he's good at that
<trukulo> credit card and wearing pants assure you a good stay in a country
<pitti> Treenaks: huh? Russian is not an European language, it has completely different roots
<Kamion> Russian is Indo-European
<ogra> Kamion, breezy is official now ?
<Kamion> ogra: not AFAIK
* ogra heard sabdfl saying it the other day....
<jdub> (*cough* it'll be official in the next couple of hours when my mail goes out *cough*)
<Treenaks> breezy what?
<ogra> Kamion, breezy...not that its official
<jdub> badger
<Kamion> ogra: (notwithstanding jdub's comment, we heard him say "bendy" a lot, too)
<ogra> yep
<ogra> but breezy was the last i heard ;)
<dholbach> BreezyBadger?
<Treenaks> omg
<daniels> Kamion: want, yes; need, no
<daniels> Kamion: -4 is fine for a7
<Mitario> hi everyone
<Kamion> daniels: ok, may well just go with that then
<trukulo> who's the genius putting names to releases?
<Kamion> since otherwise I incur a lot of build time
<trukulo> lol
<Kamion> trukulo: Mark, generally
<mvo> hey Mitario 
<thom> seb128_: i think blaming nautilus is quite reasonable
<daniels> Kamion: right -- the other thing is that, being the last array, it needs to be tested to shit first
<Kamion> with other conspirators
<daniels> Kamion: which knocks things back a fair bit
<trukulo> Kamion, don't let him, he's getting mad
<Kamion> daniels: right. (there's a release candidate in two weeks, though.)
<Mitario> mvo, did the gnome sysadmins respond?
<Kamion> but yes
<daniels> kami	yeah
<trukulo> or tell him next name is LionLeonardo
<trukulo> heh
<thom> jbailey: ack; i'm not eager to reboot right now since my sata controller is not entirely happy
<daniels> Kamion: i'll just use the next daily to go around at my local big weird-shit electronics store and hopefully throw in all the laptops there to test
<daniels> Kamion: they have all the bizzare stuff, like 14" widescreens with 1280x768
<mvo> Mitario: not yet ... once they do, we can start moving :)
<Mitario> mvo, yeah :)
<Kamion> trukulo: I strongly suggest not trolling Mark with naming suggestions; you just might find them getting accepted
<Kamion> daniels: daily-live might be a bit better ;)
<Kamion> but good plan
<trukulo> Kamion, uh oh /clear
<daniels> Kamion: yeah, live
<daniels> Kamion: the plan is to go around with a CD and a USB key and save logs and stuff from everything that doesn't work
<daniels> that's assuming, of course, that they let me
<daniels> i'll go armed with a bunch of warty CDs, my Ubuntu t-shirt, and my radiant charm
<seb128_> http://www.mplayerhq.hu/homepage/
<seb128_> you have seen that ?
<evarlast> seb128_: yes, I shed a tear :(
<thom> daniels: the first two should be fine, the third is utterly doomed
<thom> what ubuntu t-shirt, by the way? :P
<trukulo> daniels, better s/charm/cookies or something like that
<zul> hey
<ogra> thom, we are preparing MOTU shirts ;)
<Treenaks> ogra: cool :)
<daniels> ogra: much better if you just have t-shirts bagging thom
<ogra> and one very special edition.....
<daniels> ogra: http://storetn.cafepress.com/0/15425670_F_store.jpg
<daniels> sorry, that link should be http://www.cafepress.com/keybuk.15425670
<ogra> the "mdz groupie" shirt *g*
<daniels> ogra: 'moby is my cto'
<ogra> yay
<mvo> daniels: your evil today :)
<daniels> i would totally go for a 'moby is my cto' shirt
<Treenaks> daniels: with or without the picture?
<ogra> omg, so much text....the girls have to come very near to read it ....was that intentional by Keybuk ?
* mvo chuckles
<Kinnison> ogra: I doubt it :-)
* mvo chuckles
<ogra> Treenaks, with two....find the right one ;)
<ogra> Kinnison, *g*
<Treenaks> ogra: http://www.cafepress.com/keybuk.15425670?zoom=yes#zoom
<Treenaks> ogra: makes it easier
<daniels> Treenaks: either
<ogra> hehe
<daniels> Treenaks: http://pictures.yukidoke.org/debianweek/aak
<Treenaks> daniels: eeep!
<Kamion> biggest sunglasses EVAH
<d3vic3> heh
<mvo> daniels: sooooooo great :)
<jdub> aaargh, xorg update hurts my mirror! :)
<Treenaks> daniels: how about http://pictures.yukidoke.org/fluffy/aar
<daniels> jdub: THIS IS ONLY THE BEGINNING
<daniels> jdub: dbus, dbus-mono and another xorg to come
<tseng> daniels: 23.2?
<daniels> tseng: .4
<tseng> hm =/
<daniels> ?
<daniels> no api/abi changes
<daniels> just about 97% less memory leakage
<daniels> -> beagle for hoary
<daniels> (not in main, mind)
<evarlast> o_O
<tseng> whiprush said beagle works with .2 and not .3
<tseng> for some reason
<tseng> we'll see.
<daniels> bong
<daniels> we'll find out :)
<tseng> indeed
<tseng> bbl
<jdub> daniels: no api/abi changes?
<daniels> jdub: NONE WHATSOEVER
<jdub> NONE WHATSOEVER?
<Hannes_> hth
<Hannes_> 1617.24 < jdub> daniels: no api/abi changes?
<jdub> daniels: seriously? they fixed the symbol change upstream?
<daniels> jdub: yeah.  it's badly broken for 0.3x, but I managed to convince them to keep 0.2x api/abi-stable.
<jdub> rockin', good stuff :)
<daniels> jdub: they add new shit, which is fine, but afaict everything else should be a-ok
* mvo reboots to test the install-dvd
<thom> jbailey: ping?
<daniels> jdub: so, in other news, can we PLEASE get mono into main for breezy
<jdub> haha
<daniels> jdub: keeping dbus-mono broken out is a serious pain
<jdub> yeah
<jdub> it seems likely
<jdub> hopefully 1.2
<thom> daniels: we'll move to 1.1/1.2 so it should be ok, guess tseng is the man of the moment on that one
<Treenaks> jdub: Now with less memory loss?
* maswan notes that his mirror hasn't complained about too few rsync slots in a while and ups the number of syncs to 4/day instead of 1/day
<daniels> oh, frig
<jbailey> thom: Heya!
<daniels> can we live with all mono apps being rebuilt against new dbus?
<daniels> ** (/usr/lib/tomboy/Tomboy.exe:16946): WARNING **: Could not find assembly dbus-sharp, references from /usr/lib/tomboy/Tomboy.exe (assemblyref_index=4)
<daniels>      Major/Minor: 0,23
<daniels>      Build:       0,0
<daniels>      Token:       9eef2692033670f5
<daniels> noting that build is now 4,0, and token is some other md5sum
<jbailey> thom: DidItWorkDidItWork? =)
<daniels> tseng: do we win?
<thom> jbailey: yepyep
<thom> and my sata controller didn't kamikaze this time, either
<daniels> tseng: afaict, only tomboy and muine depend on libdbus-cil -- is it safe to rebuild these?
<thom> so it's a double win
<daniels> tseng: i.e. will you care if I upload libdbus-cil 0.23.4-1
<jbailey> thom: What?  I don't think you had mentioned that bit before.
<thom> jbailey: oh, yeah. my sata controller had a hissy fit this morning and refused to upload its firmware for a few hours. nothing to do with hotplug#
<jbailey> thom: Oh good.  Just to confirm though.  It loaded ide-generic last in the last of pci bits, right?  It ought to have, but I want to make sure that it didn't wind up calling into pci.rc multiple times.
<thom> jbailey: looked that way, yes
<jbailey> thom: Lovely, thanks.
<thom> np
<tseng> daniels: actually according to tomboy upstream, dbus is flakey in tomboy, and they say build it out
<jbailey> Kamion: It's only the init.d/hotplug file that you replace in the installer, right?  Everything else is from the hotplug package?
<tseng> daniels: ive not seen it, but if we hit problems id be happy to --disable-dbus or wahtever
<tseng> daniels: rebuilding muine *shouldnt* be a big deal
<tseng> thom: mono 1.2?
<sivang> hi all
<tseng> thom: so far ive been pretty hesitant to make changes to the core ahead of debian
<thom> tseng: yeah
<tseng> thom: but they are putting a low priority on it =/
<daniels> tseng: sweet.  i'll give it some testing with hal/tomboy/muine/beagle, and if we're good to go, i'll upload soon
<tseng> daniels: sweet
<thom> meh; you have access to pkg-mono on alioth? i'd just branch in there so they can work and review with you, but this looks like a case where we need to leed
<thom> lead
<daniels> tseng: tomboy's fine
<Kamion> jbailey: yeah
<tseng> rock
<pitti_laptop> daniels: I released xfree86
<jbailey> Kamion: Cool, thanks.
<Kamion> jbailey: um - do we need a hotplug change for Array CD 7? like, urgently?
<sivang> pitti_laptop: hey, still not home network? ;-/
<pitti_laptop> sivang: no, still in the uni
<sivang> pitti_laptop: I see
<pitti_laptop> sivang: this might be so for the next one or two weeks
<daniels> pitti_laptop: awesome, thanks mate
<thom> pitti_laptop: what happened to legendary german efficiency? :-)
<jbailey> Kamion: It's something like looks a bit like 1440, but is solved differently.  I've had one report of it only, though.
<pitti_laptop> thom: wrt my network?
<jbailey> Kamion: I have another sata bug is seems that might be the same thing which definetly won't make array 7.  My best guess is that I wouldn't worry about it for array 7, for this few people I can point them to a nightly.
<pitti_laptop> thom: the admin went to holidays and nobody has the passwords *gar*
<pitti_laptop> thom: I hope that he does not do a three-year world tour
<Kamion> jbailey: ok, good; it'd take a d-i initrd rebuild etc.
<thom> pitti: oops
<daniels> tseng: muine's fine with a rebuild also
<tseng> daniels: sweet
<pitti> thom: and I can't even complain; it's not a company, but a club, and they don't guarantee net access
<daniels> now for BEAGLE
<pitti> thom: (I don't get DSL here)
<ogra> pitti, hey but you got a lot of fiber in the street ;)
<thom> pitti: oh, right. you have a shared T1 for your appartment complex or something?
<pitti> ogra: yeah, that's the irony
<daniels> thom: when I was there for aKademy, a couple of the trains I caught were late.  disappointing. :\
<pitti> thom: in a central place in the city there are 4 DSL wires; access is distributed over the city through directed beams and WLAN
<ogra> thom, when they built up eastern germany they exchanged _everything_ with fiber, even the last mile...so no dsl in e-germany :-P
<pitti> thom: it's called "citizen net"
<thom> daniels: heh
<pitti> thom: yeah, we have the world's most modern telephone net here, but nobody sells you fast connections but the one big monopoly company
<thom> pitti,ogra: weird, and kinda suckful
<pitti> thom: indeed :-)
<ogra> thom, but telecom is still in the decision process wether its usefull to rip out all the fiber again and put copper in again 
<pitti> ogra: not _really_???#
<maswan> ogra: It's still good if you can do the last 100m with copper though, cat5&co is much nicer for the end switches.
<pitti> thom: well, in 8 months I move house anyway
<thom> pitti: heh, hope you get internet connectivity back before then
<pitti> me too :-)
* daniels FEELS THE BEAGLE LOVE.
<ogra> maswan, the prob is that there is no copper in the last 100m now ;) and it costs billions to change it back
<pitti> otherwise I will play Tom Hanks and always hang around at the Uni floor (well, not quite the airport) :-)
<tp_> is anyone aware of the particularly nasty bug in the current hoary oocalc?
<pitti> tp_: I only know the crash if you delete a line
<thom> daniels: on amd64? ;P
<tp_> it's the change in behaviour so inserting cells moves all the rows down by default
<maswan> ogra: copper is what you put in when you do the building network for ethernet to all apartments.
<maswan> ogra: having fiber to rent between your building and an ISP, that's good. :)
<daniels> sensational, and I didn't even break g-v-m
<lamont> Kamion: reenabled
<lamont> want me to kick them too?
<Kamion> lamont: nah, no need
<Kamion> thanks
<tp_> instead of overwriting... It was introduced by novell (not ooo) and is fixed in 1.1.3-24 : http://www.oooforum.org/forum/viewtopic.phtml?t=15527 http://www.openoffice.org/issues/show_bug.cgi?id=40204
<daniels> Kamion: hold on a minute.  when are you rolling a4?
<daniels> er, a7
<Kamion> yesterday's d-i upload is fine for array 7
<daniels> Kamion: as in, should I wait to upload dbus and dbus-mono?
<Kamion> daniels: er, was kind of hoping that the CD build I did earlier would be enough ...
<Kamion> but I haven't confirmed yet
<tp_> pitti: it could seriously mess with peoples data and they may not notice..
<daniels> Kamion: righto
<daniels> Kamion: let me know when you know and I'll uploa
<daniels> d
<Kamion> ok, my mirror is STILL munching on xorg so I don't want to start cdimage downloads yet
<pitti> tp_: please file a bug
<Kamion> if other people want to test 20050316.1, feel free, that'd be welcome
<Kamion> mmm, sorry, make that 20050316.2
<Kamion> 20050316.1 was the broken one
<daniels> Kamion: heh
<daniels> Kamion: (sorry)
<daniels> Kamion: if it's any consolation in the form of karma, my amd64 just hung
<smurfix> Kamion: install and/or live?
* Kamion moves seed structures into STRUCTURE files in the seeds themselves; no longer hardcoded in germinate, hooray
<daniels> Kamion: huzzah
<Kamion> elmo: please update germinate on jackass
<Kamion> smurfix: both
<thom> Kamion: yay, time for ubuntu-server-foo seeds ;-)
<Kamion> thom: I was *slightly* more concerned with fixing germinate on warty, but yeah :)
<sivang> pitti: I have a new debdiff at the same location of my pkgs, would you take a look and confirm then I would continue with l10n?
<jbailey> thom: That reminds me that I should check the wiki bug I filed about it not letting accounts be created.
<pitti> sivang: URL?
<jbailey> thom: I've got a few people around here really interested in helping with serverteam test installs and such.
<smurfix> Kamion: Will test live as soon as rsync'd -- currently it thinks it has 30k bandwidth and needs 5h, both of which is nonsense
<Kamion> oh, I need to look at some server issues with initial-passwd-udeb, yeah
<Kamion> smurfix: rsync often lies
<Kamion> temporarily, at least
<smurfix> Kamion: I know, but knowing that doesn't speed it up ;-)
<tp_> pitti: there has been a bug report since 20th feb? (5679 ) the report seems to suggest the possibility that it's not really a problem unless it affects oo2. The bug is fixed in ooo-build (1.1.3-4 I beleive - it was an upstream build problem) I was wondering if a new oo1.1.3 is being released soon. I will add a bug report though. Thanks for the response
<thom> jbailey: awesome
<thom> Kamion: he
<thom> h
<pitti> haggai: ^ tp_, any idea?
<jbailey> thom: Nope, wiki bug is still there, so I'll be adding things on their behalf for now I guess.  No biggy.
<pitti> seb128: gnome-session-remove nautilus does not help to stop g-vfs-daemon from respawning
<pitti> seb128: and g-s-r gnome-vfs-daemon hangs
<sivang> pitti: http://muse.19inch.net/~sivan/g-c-m/sivan-gcm-crack.diff
<sivang> pitti: sorry, it's not refreshed. I don't get it, refreshing 
<sivang> pitti: ok, refreshed
<sivang> pitti: the same URL
* pitti bookmarks this time
<pitti> sivang: up to the inconsistent indentation in browsing_set(), it looks fine
<sivang> pitti: you want me to correct it?
<pitti> sivang: it's only a nitpick
<sivang> pitti: ok, I will fix those as well as adding l10n
<lamont> 200KB/sec.  not shabby for a 32kbyte/sec throttled rsync of an iso.
<lamont> (neighbor imposed a 256kbps limit, you see... :)
<mvo> Kamion: when today will array-7 be build? I have some medium well tested uploads ready and would like to wait for after that with them :)
<Kamion> mvo: I can't quite say yet
<Kamion> it may have already been built, but I haven't tested those images ...
<Kamion> and I heard a rumour in a bug that they were still broken
<mvo> Kamion: will it help if I download and test? 
<Kamion> mvo: yes please
<mvo> 0316.2 is the current one?
<Kamion> yes
<mvo> ok, downloading
<janc> stupid question: why must the version number of xfonts-* and other data(?) packages like that go up together with those of xorg (or whatever package they are needed for)?
<mvo> I learned today that I can't burn a dvd image to a dvd-ram with nautilus or k3b ... bugger. I guess I need to get a dvd-rw for that
<mvo> (the hoary-dvd image of course :)
<Kamion> janc: because we don't have modular X yet
<Kamion> janc: they're all built from the same source package so they all get rebuilt
<daniels> janc: because the build system, which wasn't even a great idea in 1986, continues on to this day and has been extended and hacked into some several-hundred-megabyte horror show that everyone hates
<daniels> janc: (trust me, I'm not excited about the hour-long rebuilds every time I typo something)
<janc> and it's not easy for an automated build proces to check if they changed I guess...  :)
<Kamion> janc: it's not that, they MUST be in separate source packages if their version numbers are not to increase
<fabbione> robtaylor_: pong
<Kamion> janc: so the build system HAS to be split out in order for that to work
<zul> hey fabbione 
<janc> I was more thinking about the users: not everybody likes to downloads all those megabytes for no good reason  :-)
<daniels> which involves groundbreaking amounts of work
<daniels> janc: oh, I know
<Kamion> janc: we know that, but you asked why, and we told you :)
<daniels> janc: i have to copy the huge debs around, watch the huge builds go past, upload the huge source (new upstream version takes about 45min to upload), and then download the new debs for 4 architectures every time I roll a new version
<cc> daniels: still didn't get your DSL sorted out ?
<daniels> janc: it took around six months to just split out the build system for the server, and even then there were some pretty big gaps in the coverage there; it's a huge task, unfortunately.
<daniels> cc: i've got dsl at home now, but 50mb tarballs aren't generous to any uplink
<janc> yeah, I read something about splitting Xorg before, didn't know how bad/difficult it was though...
<daniels> incredibly difficult, but not at all bad
<daniels> something I've personally been pushing for for over a year now
<cc> daniels: agreed. do xdeltas help?
<daniels> cc: not hugely; since the whole thing gets repacked, it tends to screw everything to hell
<Kamion> cc: the filenames change, which generally makes that sort of thing hard, too
<daniels> cc: (plus, the diff between 6.8.1 and 6.8.2 was >130,000 lines)
<tp_> pitti: thanks... bug comment posted
<cc> gah. 
<Kamion> tp_: he's gone
<sivang> Kamion: did he say when he is coming back?
<lamont> daniels: and to think that the third number is supposed to indicate bug-fix level..... 
<Kamion> sivang: 15:32 -!- pitti [~pitti@141.30.117.20]  has quit ["Have a nice day"] 
<Kamion> sivang: in other words I have no idea
<lamont> sivang: I would expect at least 3-4 hours, given a comment elsewhere
<robtaylor_> fabbione: i've been having some weird ipv6-realated issues on my hoary system recently
<sivang> Kamion: ok, thanks
<robtaylor_> fabbione: when a gethostbyname occurs, 1st a ipv6 dns query is sent out, and then when this fails, it waits up to 30 seconds before continuing with an ipv4 request
<daniels> lamont: i think you underestimate the amount of bug fixing that went on
<robtaylor_> fabbione: this started occuring for me around the middle of last week. any ideas what could cause this?
<lamont> daniels: no.  I just fear its prior state...
<fabbione> robtailor_: bad dns servers. the RFC is clear and your machine is doing the right thing
<daniels> robtaylor_: welcome to my life. :)
<daniels> er
<daniels> lamont: ^^
<sivang> seb128: ping, how should I add my changes for a po file of a package? (g-c-m) 1)cdbs-edit-path my-code-patch; in /po make update-po; exit 0 ;==> added to the code patch or 2)diff -u orig.he.po new.he.po ?
<lamont> daniels: and I'm more glad than ever that you're on it.
<sivang> seb128: doing (1) has bloated my debdiff as it appears that the whole po files has changed.
<seb128> sivang: diff -u po/file.org po/file is fine
<sivang> seb128: and drop that in debian/patches right?
<daniels> lamont: should I take that as a compliment ('I'm glad it's you that's handling it, because you're awesome'), or as a put-down ('I'm glad that it's you that's stuck in this nightmare')? :)
<lamont> daniels: both. :-P
<daniels> heh
<seb128> sivang: correct
<lamont> glad someone capable is on top of it, also glad it's not me...
<Kamion> urgh, apt-setup behaviour on netboot is really not fun
<robtaylor_> fabbione: eh?
<robtaylor_> fabbione: what should the dns servers do?
<lamont> robtaylor_: it sounds like the DNS server is dropping the request, rather than replying with an error??
<robtaylor_> reply to the ipv6 request with an ipv4 reply?
<robtaylor_> no it returns back a 'i didn't understand that  query'
<robtaylor_> fabbione: http://pastebin.ca/7519
<robtaylor_> (trimmed ethereal log)
<daniels> Kamion: ok, I'm rsyncing the CD now (0316.2) to do a test install on amd64, but can't do one on my laptop right now, sorry
<Kamion> sure, np, I'm starting my test cycles now
<daniels> your mirror spankage stopped?
<Kamion> gave up and ctrl-ced it
<jbailey> thom: ping?
<Kamion> it'll catch up overnight
<daniels> (the point I'm working from, though, is a rather old jigdo I did, so it may take a fair while)
<thom> jbailey: ack
<jbailey> thom: Found a slight logic bug.  Do you have a sec to test a new hotplug iteration?  Sending me the output from a hotplug restart will be all I need.
<thom> sure
<thom> jbailey: same place as last time?
<jbailey> thom: Not yet, just tossing it up.  (It's a new rev)
<jbailey> thom: http://people.ubuntu.com/~jbailey/hotplug_0.0.20040329-16ubuntu17_all.deb
<jordi> mvo: ping
<jordi> mvo: I'm doing a new package. :)
<jordi> hmm. only savannah seems broke.
<jordi> muh
<thom> jordi: nano makes the universe cry
<jordi> thom: yeah baby
<sivang> seb128: regarding my last question, I think I have misexpressed myself, other the the changes to he.po file, all the other po files changed due to my new strings in g-c-m, how do I prepare this to be patched?
<jordi> GNU nano 1.2.0 released!
<jordi>      posted by jordi, Thu 02/20/2003 at 05:15 - 0 replies
<jordi> fuck
<seb128> sivang: ?
<jordi> it's been a while since the last stable release.
<jordi> this sucks
<seb128> sivang: you have a patch for the code changes and you "diff -u po/.. po/... > debian/patches/nn_po.patch"
<seb128> that's all
<mvo> jordi: cool!
<mvo> jordi: that was quick :)
<mvo> jordi: ping me when there is something to download
<sivang> seb128: ok cool, I was missing that, so I diff the whole po directory, also, what does "nn" stand for? (in nn_po.patch)
<lamont> jordi: if it's not being maintained, should we just drop it. :-)
<seb128> sivang: a number
<sivang> seb128: what does it represent?
<seb128> nothing
<seb128> you can order the patches by number
<seb128> just follow what the package is doing
<sivang> seb128: ah ok, so the patch would be applied last
<sivang> seb128: thanks!
<jordi> lamont: it is maintained
<robtaylor_> fabbione: if that is non-rfc complient, a) could you give me more info i can go to psinet and tell them, and b) psi net is a very major provider, so this'll hit a lot of other people, and from the reply its obvious to tell that the dnsserver doesnt support AAAA requests.
<jordi> lamont: it is taking a while to complete 1.4.0 though.
<jordi> lamont: there have been 1.2.x releases since then
<jordi> lamont: but 1.4.0 is nearly there.
* sivang is off for the next 4 hours
<lamont> jordi: sorry - just pulling your leg
<jordi> oh, heh.
<jordi> everyone wants to kill nano
<lamont> jordi: only because it's now preferred over vim for $EDITOR
<lamont> and yeah, I _understand_ why.
<ogra> yeah, thats annoying
<lamont> and even agree with it.
<lamont> I just don't like it
<jordi> I know it annoys people. :)
<jordi> lamont: yeah... I guess that's going to be an amusing hoary feature :)
<jbailey> jordi: Is it true that nano 1.4 is taking so long to come out because of the elisp interpretor? 
* jbailey hides.
<jordi> jbailey: nah, it's actually the rewrite to be an emacs component
<thom> jordi: aww, not a bonobo component?
<jdub> DUDES! WHOA!
<jdub> http://lists.ubuntu.com/archives/ubuntu-announce/2005-March/000020.html
<jordi> thom: not in the middle of the debonobisation of half of GNOME. :)
<jordi> heh
<thom> jordi: poor excuse
<jordi> too bad that being around Canonical people makes stuff like that not a secret at all :)
<jordi> thom: I know it'd be cool to embed nano in nautilus.
<jordi> wait, nautilus doesn't do bonobo
<ogra> huh :-O
<jordi> thom: OMG, the gnome-nano-applet.
<jordi> That would rock.
<thom> ROFL
<kylem> you guys get extra points for being more perplexing than debian.
<ogra> hehe
<kylem> at least your announcements are better.
<jordi> jdub: this post is... weird. And you know. :)
<lamont> jdub: woot
<Mithrandir> daniels: uhm, when X goes in a loop trying to access /dev/dri, is there a nice solution?  AMD64, Radeon 9200 card.
<jdub> kylem: ;)
<ogra> Mithrandir, buying a nvidia ?
<lamont> Mithrandir: remove the card from the machine, bring it to UDU, and beat the living &*%^)&% out of daniels with it?
<lamont> then buy nvidia. :-)
<Mithrandir> lamont: that's a possibility.  I do want to use it until then, though.
<lamont> s/then/_then_/
<Mithrandir> and I don't care about 3d, so it's not an issue
<lamont> jdub: how much caffine was involved in writing that announcement?
<Mithrandir> hm, turning off dri seems to fix the problem
<lamont> Mithrandir: and I assume all of the solutions begin with "kill X" :(
<jdub> lamont: you are wise beyond your years.
<lamont> jdub: and that's saying something, to listen to daniels talk.... :)
<Mithrandir> lamont: that's not a problem, I'm just setting this system up.
<trukulo> joder la de cambios que hay en el upgrade
<ogra> hmm, does anyone else see evo collapsing all the threads all the time recently ? 
* lamont always preferred "wise behind your ears"
<trukulo> ups, sorry, i mean
<trukulo> what a lot of problems in aptitude upgrade
<trukulo> s/problems/changes
<trukulo> i need to sleep :P
<trukulo> it's asking me about everything , it's the same for final? or only in devel stages?
<lamont> Kamion: so does hoary-live-powerpc have MacOS versions of the openCD?
<daniels> holy god, I would just like to say that LVM and XFS kick arse
<mvo> ping Mitario 
* daniels just added another 30GB from another drive on the fly.
<daniels> Mithrandir: goes into a loop?  startup?
<Mitario> mvo, pong
<Mithrandir> daniels: yes.
<Kamion> lamont: nope
<Mitario> mvo, ok read the e-mail
<lamont> Kamion: oh right, MacOS already has those. :-)
<Kamion> lamont: Henrik said they'd thought about it but it would be a hell of a lot of work
<Kamion> trukulo: I doubt anyone will be able to answer that without details, bug reports, whatever
<Mithrandir> daniels: as in, SIGALRM, trying to access fd open to /dev/dri/card0 and gets:
<Mithrandir> ioctl(7, 0xc0406429, 0x7fbffff110)      = -1 EBUSY (Device or resource busy)
<daniels> Mithrandir: bonnng
<Mithrandir> daniels: up-to-date hoary.
<daniels> Mithrandir: let me see if I can reproduce
<daniels> Mithrandir: you're not running another X server or something, are you?
<Mithrandir> daniels: no, nothing like that.  Standard LCD display with DVI cabling, ATI Technologies Inc RV280 [Radeon 9200 PRO]  (rev 01) card.
<Mithrandir> sweet machine, XP4000+ and 2G RAM.
<daniels> cracktasmic
<daniels> dude, if it was truly a sweet machine, it would be pcie and amd64 :)
<Mithrandir> I felt I pushed hard enough at my uni budget when I got this machine.  I don't need the pcie performance
* jdub is sorely tempted to get an amd64
<Mithrandir> (and I'm only keeping it until summer anyhow, since I'm finished then)
<Mithrandir> jdub: amd64 is good.
<daniels> amd64 is love
<Keybuk> jdub: me also
<trukulo> Kamion, there's no bug, i only have to re-configure cups, locales, hotplug, debconf, etc, etc... a very long list
<jdub> they're just... so... fast...
* lamont has 'amd64' on his shopping list
<trukulo> also man, alsa, serial...
<jordi> http://people.debian.org/~jordi/nano_1.3.5-cvs.20050316-0_i386.deb, the nano package EVERYONE was waiting for.
<trukulo> i only say it's very difficult for joe-user
<Keybuk> jdub: but will you call it "galactica" ? :p
<jordi> mvo: this means you. :)
<lamont> it just keeps getting bumped down by more urgent things.  like working dvd burners
<thom> http://www.tyan.com/products/html/thunderk8we.html
<thom> *wants*
<jdub> Keybuk: i might call it cockfosters :)
<Mithrandir> lamont: dvd burners are cheap, though.
<daniels> i need to get myself a cheap, crappy i386 motherboard
<lamont> Mithrandir: yeah
<Mithrandir> thom: got a pile of them at $otherwork. :)
<daniels> i have a hojillion agp cards, but no machine to put them in
<Mithrandir> thom: they're sweet
<lamont> daniels: I can bring you a cheap, broken one...
<daniels> which means that the only ati cards i have access to are mach64s, an x300 se, and an x850 xt pe
<mvo> jordi: I'm everyone? even in CAPTIALS? cool :)
<thom> Mithrandir: goddam. wanna send me one? no-one in the uk can get em, apparently
<trukulo> i mean, he's asking me everything again, even more than if i install it from new
<daniels> and the only nvidia card i have access to is a riva128 (and a few geforce pcis)
<jordi> sda
<jordi> ooh
<jordi> look, mvo
<Mithrandir> thom: they cost half a fortune, iirc.
<jordi> you're evil umlauts
<lamont> Mithrandir: dvd burner raided the piggy bank that the amd64 had...
<daniels> thom: the a8n-sli deluxe is very nice, also
<Mithrandir> lamont: poor piggy bank.
<mvo> jordi: ahhh ... looks _much_ better now :)
<thom> daniels: does that do dual opteron?
<lamont> yeah.  I went with the $99 cyberhome unit, instead of the equivalent $199 Sony unit.
<daniels> thom: two gigeth, most everything supported, two pcie x16, two pcie x1, 8 sata plugs, dual-channel ddr400, all the oog stuff.  and cheap.
<trukulo> even he's asking me about mozilla jprefs ...
<Keybuk> my opteron is going to have to wait until after .au and probably guadec too :-/
<daniels> thom: no, it doesn't do dual opteron.  you bastard.  shut up.
<Mithrandir> lamont: expensive stuff -- my dvd burner was about 60EUR
<trukulo> s/jprefs/prefs.js
<jordi> mvo: if you want to advertise the deb here and there and no big regressions are found, I can try to get 1.3.6 out the door and make a diff/dsc that can be sponsored to hoary
<thom> daniels: don't waste my team, weakling :-)
<thom> uh, time
<lamont> Mithrandir: sounds about right, given the conversion rate... that and I bought mine retail, rather than actually shopping online
<thom> man my typing blows today
<jordi> mvo: that probably includes testing the udeb too
<daniels> thom: i was about to say, your team is constantly getting wasted
<daniels> thom: that 'rugby' thing (both forms), darts, cricket, soccer, whatever :)
<Mithrandir> thom: actually, I think the ones we have are the K8Q or K8S or something.
<thom> Mithrandir: yeah, i wasnt smp board with pci-e
<kylem> daniels, wow. that is a sexy board.
<Mithrandir> thom: the only place in .no having the 8WE has -2 in stock. :)
<mvo> jordi: it's a release manangers descision, but I'll talk to them (hey jdub :) 
<thom> -2? rock
<jordi> mvo: you have an ally in Kamion. :)
<Mithrandir> thom: SLI plus dual, that's nice.
<daniels> kylem: the -sli is what I have (although I only run one PCIE card, but I like it better than two 6800 Ultras :))
<daniels> Mithrandir: bah SLI
<trukulo> wtf? upgrade is asking me for root password ???
<jordi> it's even curious to see this crack in a nano buffer.
<Mithrandir> shame the opteron doesn't do throttling.
<jordi> ok. the final test.
<kylem> daniels, have i mentioned i hate you? :-)
<thom> it won't be as l33t as voodoo2 SLI
<Mithrandir> daniels: it has nice stuff such as SATA2 and dual U320 SCSI too.
<mvo> jordi: you sure? even with this additional dependency :) ?
<Mithrandir> thom: what's the prices people are claiming on it?
<kylem> daniels, i don't even have working graphics on my toys.
<jordi> if nano can save a KHOMUT THAI CHARACTER...
<jordi> it is GOLD
<thom> Mithrandir: the WE? I can't find any one in the uk that has one :/
<Mithrandir> thom: so they don't put up a price even?
<thom> nup
<jordi> oh dude it works
<jordi> mvo: does the ubuntu base system not include ncursesw already?
<daniels> kylem: heh
<Mithrandir> daniels: got any ideas for my problem?
<daniels> Mithrandir: mmm, that's pretty rad
<daniels> Mithrandir: not really, but I'll check the code out
<trukulo> Kamion, it seems aptitude upgrade is executing again configuration install of Ubuntu, more detailed even
<daniels> Mithrandir: the only reason I got the -SLI wasbecause it was the only PCIE board I could buy at the time
<jordi> mvo: can you check that in a minute?
<mvo> jordi: it's not listed explicit in the base-seed, but if it becomes a dependency of nano it will be automatically added AFAIK
<Mithrandir> uhm, X seems to have become a kernel thread.  Or something.
<Mithrandir> root@bowah:/etc/X11# ps xa | grep Xorg
<Mithrandir> 11137 ?        R     12:27 [Xorg] 
<jordi> mvo: nod
<daniels> Mithrandir: kernel problem!  fabio's fault!
* Mithrandir throws some a 30 pin RAM sticks at daniels 
<Keybuk> hmm
* Keybuk wonders whether to blame kernel-team, thom or mjg59
<Keybuk> but for some reason, recent kernels break thermal zone polling
<Mithrandir> Keybuk: what about gtk?
<Keybuk> no, iz not gtk bug
<mjg59> Agh cocking christ
<mjg59> Keybuk: Got time to build a test kernel?
<Keybuk> sure
<thom> Keybuk: i think you've found your culprit :-)
<mjg59> Let me find you a patch
<mjg59> (No promises, but it's supposed to fix some ec bugs related to thermal issues)
<trukulo> Kamion, u there? aptitude upgrade is doing debian install process entirely for me
<mjg59> Keybuk: Any messages like acpi_ec_space_handler: bit_width should be 8 appearing?
<Keybuk> mjg59: nothing in dmesg or syslog
<mjg59> Hrm.
<mjg59> Ok, two patches then:
<Keybuk> it reports the right temp, and right trip points
<Keybuk> but doesn't appear to be inclined to turn any fans off
<mjg59> http://bugzilla.kernel.org/attachment.cgi?id=4516&action=view
<mjg59> Just try that one, then
<Keybuk> mjg59: doesn't apply cleanly to linux-source-2.6.9-28
<fabbione> mjg59: that patch is scary and smells of abi change
<daniels> 2.6.9? wtf?
<Keybuk> ah, yes
<fabbione> Keybuk: did you run ./debian/rules monolith?
<Keybuk> clearly I am in the wrong directory
<daniels> sigh, still 2h to go on my CD's rsync
<daniels> obviously my original image was well, well adrift of current standards
<daniels> i might pass out for a couple of hours while it downloads
<daniels> mmm, yes
<mjg59> fabbione: Yes, that's likely to be true
<fabbione> what is supposed to fix?
<fabbione> -spin_lock_irqsave(&ec->lock, flags);
<fabbione> +WARN_ON(in_interrupt());
<fabbione> +down(&ec->sem);
<fabbione> BRRRRRRR
<mdz> morning
<ogra> morning mdz
<fabbione> morning md
<fabbione> z
<mvo> morning mdz
<mdz> Kamion: what is mkvmlinuz?
<robtaylor_> fabbione: i've done a lot more debugging now, and i get exactly the same DNS repsonses from a number of DNS servers (incluin University of cambridge, from within the universities network) talking though various types of nat
<robtaylor_> what gives?
<Keybuk> mjg59: hmm, that outright doesn't apply to 2.6.10 at all
<Keybuk> 3 out of 23 hunks FAILED and stuff
<mjg59> Keybuk: Our 2.6.10, or plain upstream?
<Keybuk> ours
<mjg59> They both have different ACPI code
<fabbione> Keybuk: did you run ./debian/rules monolith ?
<Keybuk> fabbione: no?  what does that do?
<Keybuk> I don't have a debian/rules ?
<fabbione> perhaps apply all our neat acpi patches?
<fabbione> Keybuk: what source are you using?
<Keybuk> linux-source-2.6.10
<fabbione> from apt-get source or apt-get install?
<mjg59> Yeah, then our patches are already applied
<fabbione> the 2 differs ... a lot
<Keybuk> install
<fabbione> as mjg59 sais
<fabbione> well you only one option
<fabbione> fix the rejects :-)
<Keybuk> well, one of them looks like the same patch on both sides
<Kamion> trukulo: I'm sorry, I'm too busy to look at this right now
<trukulo> Kamion, ok, i just inform
<Kamion> mdz: a script that glues kernel and initrd together for some powerpc subarches
<Kamion> mdz: but not so important as I first thought, since it now isn't needed for Pegasos support
<Kamion> hmm. German installations remove mozilla-firefox etc. while installing language-support-de
<Kamion> pitti: 17:22 < Kamion> hmm. German installations remove mozilla-firefox etc. while installing language-support-de
<pitti> Kamion: this is due to ffox 1.0.1, I also noticed it
<Kamion> I suspect this applies to a bunch of locales
<Kamion> yeah
<pitti> Kamion: I have to upgrade the dependencies
<pitti> of all locale packages, yes
<Kamion> how soon can this be fixed? not to rush you or anything, but I think it probably ought to block Array 7
<pitti> ugh, actually I'm in quite a hurry (dance school ball this evening)
<sabdfl> mdz: how's it looking today, sans oo.o2?
<sabdfl> hi all
<pitti> Kamion: but it shouldn't take too long, I try to do it now
<pitti> Hi sabdfl 
<Kamion> pitti: either that or tell me what to do if it's trivial, I guess
<pitti> Conflicts: mozilla-firefox (<< 0.99+1.0RC1-3), mozilla-firefox (>= 1.0.0)
<pitti> hrm
<pitti> I guess I change this to
<mdz> sabdfl: I just opened my eyes, dunno yet
<pitti> >= 1.1
<mdz> Kamion: I rolled a new set of CDs last night with the new xorg, but couldn't wait around for them.  how did they turn out?
<ogra> argh
<ogra> elmo ooo
<Kamion> mdz: today's seem ok
<Kamion> but I haven't really checked xorg in any detail
<mdz> anything on the todo list for array 7?
<Kamion> see above
<mdz> should probably do new livefs images with the new ubuntu-desktop if I missed the daily build
<mdz> to incorporate hwdb-client
<thom> pitti: yeah
<daniels> Kamion: i'll check out xorg on amd64, but that was a pretty low-damage upload
<ogra> mdz: Rejected: hwdb-client_0.5-0ubuntu1_source.changes: upload is signed by 0x13A0E64FD1ED4E737046DFBD4AC393FBA2D06936 but is not in the Maintainer keyring.
<ogra> :(
<daniels> Kamion: i'll be staggered if it broke anything.  which, of course, means that it won't work for anyone.
<Kamion> cjwatson@little:~/cdimage/www/full/daily-live/current$ grep hwdb-client *.manifest
<Kamion> cjwatson@little:~/cdimage/www/full/daily-live/current$
<Kamion> I'll do a new live build
<pitti> Kamion: oh, it's not the -all package, this is correct
<Kamion> running
<mdz> ogra: I couldn't wait any longer on moving it into main; it should be no problem for your uploads to be sponsored until elmo can process your key
<ogra> ok
<robtaylor_> fabbione: well i've found the issue. detailed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140528. you should probably apply this patch :https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=107533 to bind9 
<Kamion> argh, why does /var/log/installer/messages start with 'UTC=yes' instead of actual useful stuff
<Mithrandir> ogra: what do you need sponsored?
<daniels> mdz: fwiw -- xorg, dbus and dbus-mono are all good to go, just waiting on array 7 so I don't inadvertently break that
<robtaylor_> i'll test it at home tonight
<Micksa> if anyone cares
<Micksa> I can't change my mouse sensitivity or acceleration
<Micksa> neither through gnome or with "xset m"
<fabbione> robtaylor: i really don't understand why you keep pushing me these patches... i don't maintain bind
<pitti> Kamion: fixed
<fabbione> and as i just told you before it is a dns server problem
<Kamion> pitti: cool, thanks
<pitti> Kamion: the m-f-locale-de package, that is (which has still its own source package)
<robtaylor_> fabbione: no its not!
<Kamion> pitti: is that the only one left?
<robtaylor_> fabbione: as i've said to you
<robtaylor_> fabbione: so bind patch-> who?
<fabbione> robertj: Component: bind
<robtaylor_> debian maint? i dunno how the ubuntu freeze works
<fabbione> robertj: debian maint = lamont = ubuntu maint
<pitti> Kamion: I check
<robtaylor_> fabbione: ah, didn't notice your reply as i'm not robertj ;)
<robtaylor_> fabbione: and i'm talking to you cos lamont pointed me in your direction for this issue
<fabbione> robtailor_: ah k
<dholbach> jdub: your annouce mail ROCKs :-)
* tseng agrees.
<jdub> ;-)
* jdub is very excited about breezy badger
<ogra> so if someone would do me the favour to upload and sign hwdb-client to main: http://www.grawert.net/hwdb/
<jdub> it's going to be so good
<thom> mjg59: ok, so p4-clockmod is damnably awful, but for those poor folks on p4 laptops, it's better that nothing, i think. is there a better solution, or should we just turn it on if we're on a laptop?
<ogra> jdub, sounded like that
<jdub> it will MELT MY FACE
<ogra> hehe
<tseng> are sponsorships for UDU already finalized?
<ogra> havent heard anything yet
<daniels> jdub: USPLASH
<daniels> jdub: and FULL SICK X RECONFIGURATION
<ogra> neither positive nor negative
<daniels> jdub: (seriously, can we please call it that, a la MPS and TRLS?)
<daniels> fsxr
<ogra> daniels, you sound like someone from the GDR, they used to live in abbreviations there :)
<daniels> ogra: it's all jeff's fault, always
<Kamion> MPS?
<Kamion> monty python support?
<ogra> hehe
<dholbach> hahaha
<thom> mad phat startup
<Kamion> oh yes
<daniels> Kamion: mad phat startup, foo'
<ogra> jdub, xss patch before the weekend i think
<jdub> daniels: full sick? hrm.
<mvo> Kamion: first step of the install looks good so far, second step is now running
<jdub> ogra: tops, thanks
<mjg59> thom: Grah. If they're p4-ms, they should support speedstep.
<thom> they ain't, we have people claiming to be P4s
<thom> https://bugzilla.ubuntu.com/attachment.cgi?id=1661 is a laptop
<daniels> jdub: FULSIK like a VL CALAIS TURBO
<mjg59> People with laptops that have desktop P4s in deserve to catch fire
<mjg59> NOTABUG: buy something better next time
<jdub> flaming plastic intel carnage!
<kylem> mjg59, *hug*
<thom> mjg59: well, yes
<mjg59> But, uh.
<mjg59> People were complaining massively about the performance hit.
<thom> yeah
<mjg59> So we're screwed either way.
* ogra hugs his amd64 laptop....that slowly burns his right thigh
<mjg59> Maybe enable it for laptops, yeah.
<thom> i think i'll do that now and see what people think
* mvo is away for ~2h
<thom> thanks to the wizadry and bling of laptop-detect, it's easy
<thom> ;-)
<daniels> ogra: my HP was really cool.  left thigh burns (i got minor burn marks on one pair of shorts), right thigh freezes due to stupid fan placement
<daniels> thom: l-d isn't bling
<daniels> thom: it's rather understated
<jdub> yeah
<jdub> needs some figlet lovin'
<ogra> daniels, yeh, iv seen such things :)
<daniels> thom: i mean, you could pop up a window that draws a huge 'LAPTOP' thingy with cairo and then composites that so everything below it is still visible
<daniels> preferably in gold, with diamond edges
<jdub>  ___ _  _  __   _____  _   _      _   ___ _ 
<jdub> |_ _| \| | \ \ / / _ \( ) | |    /_\ | _ \ |
<jdub>  | || .` |  \ V / (_) |/  | |__ / _ \|  _/_|
<jdub> |___|_|\_|   |_| \___/    |____/_/ \_\_| (_)
<jdub> 
<ogra> hehe
<thom> daniels: that would indeed be bling
<daniels> jdub: maybe a massive fist with a LAPTOP multi-finger gold/diamond ring
<daniels> jdub: with CAIRO and COMPOSITE ... maybe it could also somehow integrate support for DBUS
<daniels> jdub: that would be the most bling shit ever
<pitti> Kamion: I corrected nb, the others are fine
<stuNNed> LOL
<thom> com.ubuntu.LAPTOPBLING
* mjg59 wonders what the ss flag in the Intel cpu flags is
<jdub> haha
<Treenaks> mjg59: "Maded in Germany"
<jdub> mjg59: secret squirrel
<Treenaks> -d
<dholbach> Treenaks: you're mean
<ogra> Treenaks, got your harsh week ?
<Treenaks> ogra: yeah, sorry :)
<ogra> :)
<thom> mjg59: i was wondering if it's speedstep, but given that we try and load smi and acpi and neither of them apparently work, it might as well be supersekret
<Treenaks> ogra: I have that every once in a while
<ogra> Treenaks, its ok, we live with the original sin
<mjg59> thom: for p4, it would be speedstep_centrino
<mjg59> (If it is actually speedstep)
<mjg59> On the other hand, it appears on systems that almost certainly don't have speedstep
<mjg59> Ah, ss is CPU self snoop
<thom> ahr
<Treenaks> mjg59: maybe it DOES support some speedstep stuff, but only at one speed?
<thom> oh well
<thom> Treenaks: that would be classic intel. "YES WE HAVE SPEED STEP LOVE. YOU CAN CHANGE SPEED... TO THE SAME SPEED YOU WERE AT BEFORE!"
<Treenaks> thom: hey, my laptop has that..
<Treenaks> thom: first-generation speed-locked speedstep!
<Treenaks> (P3)
<mjg59> Treenaks: Usually means that it doesn't have speedstep
<mjg59> The smi driver finds it hard to tell
<Treenaks> mjg59: it was labeled "With Speedstep!" on  the box, but even Windows can't switch :)
<mjg59> Incidentally, we really do have totally rad laptop support
<Treenaks> mjg59: I can switch to another ACPI power mode and make it slow that way though
<mjg59> Ha. Wrong box. Or broken hardware.
<lamont> fabbione == ipv6 god
<mjg59> P state or T state?
<Treenaks> T
<mjg59> Yeah, that doesn't reduce the voltage
<lamont> hrm.. either my monitor or my eyes have convergence isuses
<Treenaks> lamont: or both
<Kamion> urgh, I think the powerpc CD may have overflowed
<ogra> so could someone sign and upload my package, so Kamion can start the CD build ?
<Kamion> I should keep log.list2cds around somewhere slightly more obvious
<dholbach> and ogra could finally go to bed, after how many hours?
<ogra> 30 ?
<dholbach> that's what i thought :-(
* thom -> pub
<ogra> havent counted...
<Mithrandir> ogra: URL?
<daniels> Kamion: over 650MB?
<ogra> http://www.grawert.net/hwdb/
<Kamion> daniels: think so, running a debug build now
<Mithrandir> ogra: should I now go into sadistic mode and pick on everything? ;)
<daniels> Kamion: and, just to be sure, 20050316.2 *does* have xorg 6.8.2-4, yeah?
<Kamion> I should also make cdimage SCREAM when that happens; like, refuse to output the powerpc CD
<ogra> Mithrandir, argh :)
<daniels> Kamion, figlet.  figlet, Kamion.
<Kamion> daniels: .list files, dude :)
<Mithrandir> ogra: I'll be gentle
<Kamion> cjwatson@little:~/cdimage/www/full/daily/20050316.2$ grep xserver-xorg *.list
<Kamion> hoary-install-amd64.list:/pool/main/x/xorg/xserver-xorg_6.8.2-4_amd64.deb
<Kamion> hoary-install-i386.list:/pool/main/x/xorg/xserver-xorg_6.8.2-4_i386.deb
<ogra> Mithrandir, thanks...anoter beer....(hopefully they have that much where we meet next time)
<Kamion> hoary-install-ia64.list:/pool/main/x/xorg/xserver-xorg_6.8.2-4_ia64.deb
<Kamion> hoary-install-powerpc.list:/pool/main/x/xorg/xserver-xorg_6.8.2-4_powerpc.deb
<daniels> Kamion: woah, handy
<Kamion> CD 1 filled with 603297516 bytes ... (limit was 603979776)
<Kamion> CD 2 will only be filled with 6725948 bytes ...
<Kamion> damnit
<Kamion> that limit is so wrong
<Kamion> INFO: Reserving 30 MB on CD 1 for boot files.  SIZELIMIT=629145600.
<Kamion>   INFO: Reserving 4% of the CD for extra metadata
<Kamion>   INFO: SIZELIMIT now 603979776.
<daniels> 'extra metadata'?
<Kamion> ISO9660/HFS garbage
<daniels> agh
<Kamion> the output CD is 620MB
<Mithrandir> ogra: from the README: It's "binaries", not binarys.
<Kamion> i.e. 650618880
<Mithrandir> ogra: and "corresponding"; double r.
<Kamion> so it does lose quite a bit of space, but not quite that much
<ogra> Mithrandir, ok, in the next upload :)
<dholbach> Mithrandir: just change it, sign it and "give tha poo' man a break" :-)
* Kamion adds 10MB to the limit
<Mithrandir> ogra: it's minor stuff, I can sign and upload with that unchanged.
<ogra> Mithrandir, thanks :)
<daniels> ARGH ZWIKI
<Mithrandir> ogra: the copyright year in the hwdb-gui.sgml is 2003
<ogra> urgs
<ogra> Mithrandir, long planning phase :)
<Mithrandir> ogra :)
<Mithrandir> ogra: you have a needless configure-stamp in the rules file
<dholbach> a round of applause for ogra, he doesnt even loose his humour after 30h awake and hacking :-)
<Mithrandir> ogra: if you fix those remarks for the next upload, I'm happy.  Good work, considering you must be totally drawn out.
<mxpxpod> does anyone here use gnome-cups-icon?
<ogra> :)
<Treenaks> ogra: 30h?? omg!
<daniels> oh, I need to be hitting w.ul.o instead of w.u.c to edit the wiki.  even though it happily tells me that I'm now logged in.  when I'm not.
<ogra> Mithrandir, i will do :)
<Kamion> daniels: go plone
<Treenaks> *cough*python*cough* ;)
<daniels> Kamion: this one isn't actually plone's fault, it's zwiki braindamage
* Kamion goes to do recycling; should be back more or less in time to kick Array 7 candidate CD build
<tseng> daniels: so were you planning to reupload muine/tomboy w/ no changes, or should i be watching for dbus to go up?
<daniels> tseng: if you want to do it, that would be great.  my plan is to watch array 7 go out, kick xorg+dbus+dbus-mono uploads, then sleep.
<daniels> Kamion: 3min left on hoary-install-amd64.iso
<tseng> ok ill watch it daniels
<daniels> thanks dude
<daniels> i'll ping you on irc when i upload it anyway
<daniels> so yeah, with .4 we should be good for beagle with hoary
<tseng> ok cool.
<daniels> worship the crack
<Keybuk> ...neat... my laptop hasn't hardly touched the hard-drive compiling this kernel
<tseng> <3 crack
<Keybuk> yay for 750MB of page-cache
* daniels cheers rsync on.
<daniels> you can do it!
<daniels> huzzah!  2:12:21 isn't too bad.
<fabbione> daniels: is the last X upload borked?
<daniels> fabbione: err?
<fabbione> <@bubba-> fabbione: i just updated again, and X is not working now
<daniels> sigh
<daniels> worked for me.  usual log+config thing applies
<fabbione> daniels: yes already asking....
<daniels> thanks mate
<mjg59> thom: Did you have a chance to look at gdm-signal ?
<fabbione> daniels: never mind... usual vmware crap
<daniels> fabbione: hooray
<Mithrandir> ogra: sorry it took a while; uploaded now.
<Keybuk> mjg59: that patch seems to fix it
<daniels> mdz: you've got some phat debugging info on DebuggingXAutoconfiguration now
<Keybuk> though it also makes hald bitch about "the kernel doesn't support capabilities"
<mjg59> Keybuk: It does? And it does?
<mjg59> Could you possibly stick a rediffed version somewhere?
<mjg59> (And what the christ is hald on?)
<daniels> oh, frig
<daniels> Kamion: sorry, my partition table is pretty screwed, and I don't have the inclination to fix it at 0540, to be honest
<daniels> Kamion: (largely because doing so would almost certainly lead to data loss.)
<Kamion> np, as you know I have to build another version anyway ...
<Kamion> how screwed?
<daniels> screwed as in fdisk reports partition 5 being swap, but sda6 is mounted as swap, and there's another plain linux partition in there (10gb) that doesn't seem to be there any more
<daniels> the sort of thing I'm not too keen on attempting to sort out right now ;)
<Kamion> hm, scary
<daniels> it works for now
<daniels> i daren't touch it
<Keybuk> mjg59: I don't make any claims from having resolved the conflicts properly
<daniels> Kamion: how long do you think it'll be till a7, roughly? (no pressure or anything, just trying to work out what I should do right now)
<Keybuk> http://descent.netsplit.com/~scott/acpi_ec_rediff.patch
<Kamion> daniels: at the moment I'm doing ARE WE NEARLY THERE YET on mozilla-firefox-locale-{de,nb} binaries
<daniels> Kamion: heh :)
<mjg59> Keybuk: Thanks
<daniels> Kamion: likely to be in the next 2h or so?
<Kamion> daniels: should be
<Kamion> I bloody well hope so, anyway
<daniels> rad
<fabbione> for i in $$list; do \
<fabbione>  newname="$(shell echo '$$i' | sed -e 's/00list-$(revision)/00list-$(nextrev)/g')"; \
<fabbione> echo $$newname; \
<fabbione> done
<fabbione> spot the error.. i keep getting an empty newname
<fabbione> i don't understand why
* fabbione kicks make
<Kamion> fabbione: can't use $(shell) like that
<Kamion> fabbione: it's expanded at the point when the makefile is parsed, not when that command is running
<Kamion> fabbione: try $$(...) instead
<Keybuk> mjg59: the hald thing could have been that it tries to set cap_net_admin=ep, and it wouldn't've had the wireless driver (atheros, restricted, etc.)
<mjg59> Ah, ok
<fabbione> Kamion: that was ti
<fabbione> it
<Kamion> ah, finally, building CDs now
<mjg59> I can't see why it would have altered capabilities otherwise
<mjg59> I'll try to build a new kernel with that tomorrow and then push it to fabbione
<Keybuk> yeah, just rebooted with an atheros module available and that warning went away
* Keybuk blames pitti
<mjg59> We should check whether that breaks machines that have no networking
<sivang> Keybuk: he hasn't come back, has he?
<Keybuk> "come back" ?
<fabbione> mjg59: no ABI changes please
<sivang> Keybuk: he's not here right now 
<mjg59> fabbione: Between now and release?
<Keybuk> fabbione: it's either that or backing out a few kernel releases until we have one that works on HP laptops
<mjg59> fabbione: It's a regression, but, well, your call
<lamont> mdz around>
<lamont> ?
<Keybuk> mjg59: do the n[cx]  6xxx have the same problem?
<mjg59> Keybuk: Unsure.
<mjg59> I don't /think/ so
<daniels> fabbione: i'm not going to do it now, but if you need l-r-m done, i'm going to be around from about 0000->0700 UTC, then about 1400->1900 UTC tomorrow.
<Keybuk> it's an odd problem; it only appears to be initial fan state that it won't change
<Keybuk> if you can heat the laptop up over the trip point, it then takes control of them
<Keybuk> and if you manually turn off the fans, it'll turn some back on
<Keybuk> and will then happily turn them on and off as required
<mjg59> Yeah. It's just down to it missing some interrupts from the embedded controller.
<Keybuk> unfortunately this means you either get a laptop trying to take off, or doubling as a frying pan until you do something :-/
<lamont> robtaylor_: around still?
<dholbach> could someone chuck out that kdepim-build? i always stop dead and think MY upload went wrong ;-)
<lamont> does bind9.2.5 from debian fix the problem for you?
<Riddell> dholbach: we're in the process of making one that doesn't depend on things still to be moved to main
<dholbach> Riddell: ah ok... sorry :-)
<stockholm> do you use openldap 2.2 or 2.1?
<fabbione> mjg59: we just did bump the ABI yesterday.. and it is 8 hours of people in here working together to get all the bits and pieces
<fabbione> mjg59: if it is a must for release.. well we will do it
<Kamion> as long as you don't do it right now, I'm not bothered :)
* sivang high fives jinty 
<lamont> Kamion: you want it post-array 7, eh>?
<fabbione> daniels: don't worry... know i have seen how to do it :-)
<fabbione> Kamion: when is A7 planned?
<fabbione> Kamion: no i have NO intention to do it NOW
* fabbione has a life!
<fabbione> and a wife...
<Keybuk> it was yesterdays patch that broke it
<daniels> hm, my shoulder's beginning to ache; i'm going to crash now, back at 0000 utc
<daniels> Kamion: g'luck with a7
<fabbione> Keybuk: what patch?
<Keybuk> 2.6.10-27 seems fine
<Keybuk> 2.6.10-28 is broken
<fabbione> Keybuk: can you spot what patch did break?
<fabbione> i know exactly which patches did break the ABI
<fabbione> so if we do not revert one of these 3
<fabbione> we can get the change in -28 reverted
<fabbione> and the laptop fixed
<fabbione> without adding new code or new patches
<Keybuk> fabbione: do you have the patches anywhere so I can look?
<fabbione> Keybuk: apt-get source linux-source-2.6.10 or baz ...
<fabbione> what do you prefer?
<fabbione> i also wrote a nice.. 25K changelog for it...
<Keybuk> did the apt one
<fabbione> it should be pretty easy to track the change
<Keybuk> yeah was just reading the changelog and couldn't spot anything obvious
<fabbione> IPMI sounds an option
<Keybuk> *shrug* bear in mind I know little to nothing about this kind of stuff
<fabbione> so do i
<fabbione> :P
<fabbione> mjg59 is the best one to help over here
* Keybuk gets the sticks to prod mjg59 with
<Keybuk> fabbione: silly question, but where are the patches?
<zul> debian/patches
<Keybuk> ah, I was in the wrong directory again
<fabbione> Keybuk: you need to edit debian/patches/00list-28
<fabbione> to enable/disable them
<fabbione> no need to remove them from the dir
<fabbione> dirty hack: go in debian/config/$arch/
<fabbione> and remove the config files that you do not need
<Kamion> fabbione: building ATM
<fabbione> build
<fabbione> Kamion: ehm.. building what?
<Kamion> fabbione: candidate CD images, will then test, and then release if they're ok
<fabbione> Keybuk: you will find the .deb in debian/build
<Keybuk> how do I build just the linux-image deb?
<fabbione> Kamion: ah ok.. sorry..
<fabbione> Keybuk: exactly as i wrote above
<fabbione> just run the build
<Keybuk> debian/rules build ?
<fabbione> or build-debs
<fabbione> or whatever
<fabbione> yes
<fabbione> actually build-debs
<Keybuk> does that make restricted-modules too?
<fabbione> no
<fabbione> what patches did you back out?
<Keybuk> binary-debs ?
<fabbione> (it will check the ABI compatibility anyway for you)
<fabbione> Keybuk: yes
<fabbione> so if there is no ABI change there is no need for a build of l-r-m
* OddAbe19 is back (gone 37:02:09)
<Keybuk> just the ipmi one for now
<Keybuk> hmm
<Keybuk> apparently debian/control is empty
<fabbione> ok. the 3 patches that breaks the ABI are the inotify, the       . Add patch stolen-from-head_087-ext3_graceful_corruption_fixes.dpatch.
<fabbione> and the JFFS2 that needs the ext3 one
<fabbione> Keybuk: in what dir?
<Keybuk> linux-source-2.6.10-2.6.10
<fabbione> control is updated at build time
<fabbione> via control.stub
<fabbione> it can't be empty
<Keybuk> ah, I need "kernel-wedge"
<fabbione> just cp debian/control.stub debian/control
<fabbione> to recover
<fabbione> i am off for dinner
<fabbione> bbl
<fabbione> Keybuk: if you have problems /j #u-kernel
* OddAbe19 is away: Gone... Like the French in a battle.
<tritium> odd: /usr/share/powernowd/cpufreq-detect.sh: line 40: We're: command not found
<tritium> (on /etc/init.d/powernowd/restart)
<tritium> uh, you know what I mean ;)
<mdz> lamont: here
<dholbach> thanks elmo
<jon1012> oops bug
<fabbione> re
<zul> hey dear
<mdz> Kamion: candidates ready to rsync?
<Kamion> mdz: yes
<Kamion> mdz: well, install, anyway
<Kamion> I'm building live cloops now
<mdz> Kamion: live waiting on livefs images?
<Kamion> yes
<mdz> ok, I'm up-to-date with install, let me know when live is ready and I'll do a test cycle
<tseng> daniels: im going to work soonish. can you please ping dholbach to upload tomboy and muine? he's already aware
<mdz> amu: are you here?
<tseng> daniels: he bumped a hard depend on your version of dbus i believe (0.23.4)
<amu> yes
<amu> mdz: yep
<mdz> amu: once the array 7 candidates are ready, can you run through your test plan?
<mdz> for the live CD?
<amu> mdz: if i have any blank Cd's left :) sure 
* amu checks 
<mdz> amu: you don't use CD-RWs?
<amu> mdz: yes i use them, my last one has some read error's ... 
<amu> mdz: all right, found 1 in m archive-box 
<abelli> ciao a tutti
<Keybuk> fabbione: hey?
<mvo> Kamion: 0316.2 seems to have set a wrong keymap for me. I'm checking 0316.3 next
<kagou> exit
<mdz> Mithrandir: ping, re: utf8-migration-tool
<mdz> mvo: ping, re: warty->hoary upgrades and ubuntu-desktop
* Kamion runs off to dinner
<mvo> mdz: pong
<abelli> sabdfl: ping
<Riddell> jdub: do you have the HTML for the new website template?
<mdz> abelli: he's gone for the day
<abelli> mdz: thank you.
<mdz> mvo: did you find a workaround for the ubuntu-desktop upgrade issue?  (I don't have the bug# atm)
<jdub> Riddell: i'm not doing the new website stuff
<jdub> Riddell: henrik is, but it's not public yet
<mvo> mdz: not sure, I need to test that again
<mdz> mvo: ok, please make upgrade issues your next priority, upgrades need to be solid for RC
<mdz> earlier is better
<mvo> mdz: nod
<Riddell> jdub: ok.  was thinking about using it for the kubuntu website
<smurfix> Would it make sense to point the live CD's Firefox homepage to something other than "blank:"?
<smurfix> (andif so, what ...)
<jdub> Riddell: mail henrik@canonical.com, let him know :)
<dholbach> smurfix: we could do with some   /usr/share/doc/ubuntu-doc/Get-Involved-RSN.html    :-)
<dholbach> or    /usr/share/doc/ubuntu-doc/Can-You-Feel-The-Love.html   :-)
<sivang> smurfix: we'd probably want it to open the fresh about ubuntu page no?
<mvo> mdz: how should we proceed with nessus? I would like to sync nessus-core,libs and nessus-plugins. it is in testing already and looks stable. I tested if it would work to only update nessus-plugins and that works for me. the change between 2.2.0 (current hoary) and 2.2.3 looks harmless too. 
<mdz> thom: what's your take on this bunch of new firefox bug reports?  genuine, or need-to-restart-firefox sort of things?
<mdz> mvo: that's fine with me, it has no reverse-depends, right?
<smurfix> Ooookay.... clicking on Help, then Desktop, says "User Guide for Gnome 2.6". Behind that one is the user guide for 2.8.  :-/  Are there no 2.10 docs available yet, or did somebody forget?
<rubenv> has anyone spoken to infinity recently?
<mvo> mdz: fine with sync the whole nessus or only the plugins?
<mdz> mvo: both, together
<mdz> smurfix: I believe the title is broken, the current docs are 2.8, and there are some 2.10 docs upstream
<mdz> smurfix: ping seb128
<dholbach> ok... daniels being "asleep now.  seriously." probably means, i won't have to stay alert for the upload of mono-rebuilds :-)
<mvo> mdz: I like syncing all of it better too. it's a bit messy with all dependencies: nessus, nessusd, nessus-plugins, libnessus and libnasl2
<smurfix> mdz: That was the idea, thanks
<mdz> mvo: agreed
<mvo> mdz: thanks
* Keybuk prods fabbione gently
<zul> Keybuk: spending time with his wife 
<Keybuk> tsk :p
<Keybuk> the depravity
<zul> yeah i dont want to know the details
<mvo> mdz: it's probably better to wait until tomorrow with the sync? because of array-7 ...
<mdz> mvo: nessus doesn't go on the CD, so it's fine
<mvo> elmo: can you please sync nessus-core, nessus-plugins, nessus-libraries and libnasl from debian? nessus-plugins in the current version is not distributable according to upstream
<zul> later folks
* sivang ==> off for the night
<Kamion> ok, interesting issue with testing install CDs that hadn't occurred to me
<Kamion> when fetching stuff like language-support-* dependencies from the network, the country you select influences which CC.archive.ubuntu.com mirror is used
<Kamion> so, depending on how in-sync the mirror is, the country you select can in fact influence whether the install works or not
<Keybuk> why whether it works or not?
<Kamion> see the mozilla-firefox-locale-de conflicts that pitti fixed earlier
<Kamion> mozilla-firefox-locale-de is out of date on de.archive.ubuntu.com, so German installs still remove mozilla-firefox at the language-support-* installation stage
<lamont> daniels: could you pretty please break out the fonts as one of the 'right after breezy opens' things?  'kthxbye
<Kamion> apt-get has a --no-remove option which could be used to avoid that problem, but aptitude doesn't document such an option
<Kamion> mdz: live CDs ready to grab
<mdz> Kamion: grabbing
<robtaylor> lamont: i am now
<lamont> robtaylor: sent you email instead. :-)
<robtaylor> i'll go read :)
<lamont> 14:49:23.331255 IP 2....32795 > 82.211.81.155.873: P 1:13(12) ack 1 win 1460 <nop,nop,timestamp 83927103 1584306530>
<lamont> 14:49:23.483256 IP 82.211.81.155.873 > 2....32795: F 1:1(0) ack 1 win 91 <nop,nop,timestamp 1584306683 83927103>
* lamont kicks cdimage
<lamont> syn - synack - ack - data - fin :-(
<Kamion> hmmmm. ouch. COMPLICATED issue
<Kamion> so, debootstrap installs udev
<lamont> which launches a daemon
<lamont> which breaks pivot root?
<Kamion> but udevd doesn't actually end up running inside the chroot
* lamont hids
<lamont> hides even
* lamont had md make that change
<Kamion> because we divert stuff
<Kamion> however
<lamont> didn't think we'd sync'ed it yet though...
<Kamion> well, dunno, either way it ain't running, don't care why
<lamont> right
<lamont> and now you have an empty /dev
<Kamion> not quite; it's populated
<Kamion> just enough for most purposes
<lamont> ok'
<Kamion> however, it doesn't catch nodes that were created by modules loaded after debootstrap (or something along those lines)
<Kamion> so when tzsetup probes rtc, /dev/rtc gets created, but /target/dev/rtc doesn't
<lamont> oh. ouch.
<robtaylor> lamont: hmmm, 9.2.5 doesnt seem to make a difference
<Kamion> now, even if udevd *did* run inside the chroot, we'd have to make the outer udevd pass events through to the inner udevd somehow
<robtaylor> i'll try building a 2.94 with that patch
<lamont> robtaylor: ok
<Kamion> ideally we'd just bind-mount /dev -> /target/dev, but the two are running with different rulesets due to d-i's historical devfsness
<lamont> yeah - if it wins, I'll push it isc-wards, and upload
<robtaylor> lamont: cool :)
<Simira> jdub: ping
<lamont> Kamion: sounds like you want to have a chat with Md....  fwiw, if it makes life easier for you, he can revert the change he made for me - I had other problems that resulted in me (livecd) solving it a different way, that'll cope with udevd launching in the chroot
<Kamion> lamont: like I say, I don't know why udevd isn't started inside my chroot, but it isn't; never has been, AFAIK
<lamont> (specificially, I kill every living thing in the chroot, and then I can unmount things...)
<lamont> hrm... was launching in the livecd rootfs build
<mdz> Kamion: is this going to delay array 7?
<lamont> Kamion: but the choices are either make it run, or umount /dev and /.dev after debootstrap, and run with a static /dev
<seb128> ogra: here ?
<lamont> but you know that
<mdz> I think udevd won't be started because it's already running
<mdz> Kamion: bind-mounting should be fine; isn't the devfsness backward-compatible?
<Kamion> mdz: well, we do use compat-full.rules; just not sure I'm comfortable with bind-mounting that at this point in hoary's lifetime
<Kamion> mdz: no, not an array-7 thing, it's an oldish issue I noticed while testing amd64
<mdz> Kamion: new live CD gives me a shitty video mode, where it used to ask and I could specify a reasonable one
<mdz> (my DDC-challenged KVM)
* lamont runs to town for an appointment.  back later.
<dholbach> bye lamont
<Kamion> mdz: maybe xorg got better at guessing, but guessed wrong?
<mdz> Kamion: daniels insisted that he wasn't tweaking the autoconfig stuff for this upload
<robtaylor> lamont: ah, oh well, it appears my issue isn't that one :(
<robtaylor> *sigh*
<robtaylor> lamont: or at least that patch doens't fix it
<dholbach> good night everyone
<mvo> night dholbach 
<mdz> Kamion: daniels is en route
<daniels> da da da da da
<daniels> ok, so in casper, we call dpkg-reconfigure xserver-xorg, right?
<Kamion> uh-huh
<Kamion> with evil debconf passthrough foo, but basically yeah
<daniels> if [ "$1" = "reconfigure" ]  || [ -n "$DEBCONF_RECONFIGURE" ] ; then
<daniels> so that will be satisfied?
<mdz> daniels: correct
<daniels> (arguments to .config)
<mdz> daniels: I can't find xorg 6.8.2-3; can you post a debdiff from -3 to -4?
<daniels> oh, I see
<daniels> it's OK, I see the problem, and if we've already done a7, I can punt -5
<Kamion> haven't quite; mdz, can I release despite this problem?
<mdz> daniels: this bug stopped my a7 test cycle
<Kamion> d'oh
<mdz> it's pretty crap to have a regression like this
<mdz> which is why I insisted that we not change this logic the day before array 7
<Kamion> 'k, I guess it's a late night for me then
<mdz> or we just delay until tomorrow
<Kamion> I'd rather get it out of the way
<Kamion> much rather
<Kamion> while I'm in Array mode, I get precious little else done
<daniels> mdz: this was a -2 -> -3 change, not a -3 -> -4 change
<Kamion> daniels: -3 was never uploaded, as far as I can see
<mdz> daniels: this didn't happen on preview
<daniels> Kamion: err ... me too
<mdz> ah, that explains why it wasn't in the morgue
<Kamion> yesterday's CD images had -2
* daniels scratches his head and stares.
<mdz> I didn't realize we went from -2 to -4
<Mithrandir> mdz: re u8mg, I'm working on a version which DTRT when upgrading from the C locale.  It needs a bit (1-2 hours) more of polish which I'm doing now.
<Kamion> so looks like an unfortunate upload accident
<daniels> mdz: ... me either, because yeah.  i was fairly conscious about *not* changing this sort of thing in -4.
<Kamion> OK, can we have minimal-change to fix that in -5 then, and roll A7 with that?
<daniels> Kamion: yeah, and then -5 can become -6
<mdz> ?
<daniels> mdz: i have a -5 more or less ready to go; that will become -6
<daniels> Kamion: sorry to fuck your evening
<mdz> ah, ok
<Kamion> daniels: *shrug* shit happens
<daniels> mdz: if you change the script from 'dpkg-reconfigure xserver-xorg' to 'RECONFIGURE=true dpkg-reconfigure xserver-xorg', it should work
<mdz> daniels: oh?
<mdz> that would allow Kamion more sleep
<mdz> daniels: can you test that hypothesis?
<Kamion> so just hack casper then?
<Kamion> casper-reconfigure, I suppose
<Kamion> let me see if I can test it
<mdz> that does't look like it would work
<daniels> mdz: yeah.  it's not an installed-system problem, it's a livecd problem
<mdz> if [ "$1" = "reconfigure" ]  || [ -n "$DEBCONF_RECONFIGURE" ] ; then
<mdz>   # if we are reconfiguring, or already have installed the package at least
<mdz>   # once before, we should not let auto_answer stomp on existing answers to
<mdz>   # debconf questions
<mdz>   RECONFIGURE=true
<mdz> else
<daniels> it's a *tremendous* hack
<mdz>   RECONFIGURE=
<mdz> fi
<daniels> mdz: right, but the problem lies in postinst
<daniels> mdz: when we call xresprobeint() in postinst, $RECONFIGURE is not set
<mdz> interesting
<Kamion> hasn't .config been sourced?
<mdz> RECONFIGURE doesn't get set in postinst; where's it supposed to come from?
<daniels> mdz: and it says if [ -z "$RECONFIGURE" ] ; then PRIORITY="medium; fi, which drops the priority on upgrades.  as it happens, this triggers, er, all the time.
<daniels> mdz: *cough*
<Kamion> surely postinst sources the debconf confmodule which sources .config which has DEBCONF_RECONFIGURE set and so sets RECONFIGURE=true
<mdz> I'm pretty certain .config isn't sourced
<mdz> it's run as a subprocess, no?
<Kamion> oh, you're probably right
<mdz> it might not even be written in sh
<Kamion> yeah, ok, you're right
<mdz> I'll try testing RECONFIGURE
<daniels> yeah, I just did that then
<daniels> + echo 'about to source confmodule in postinst'
<daniels> about to source confmodule in postinst
<daniels> + . /usr/share/debconf/confmodule
<daniels> [...] 
<daniels> + echo 'finished sourcing confmodule in postinst; value of RECONFIGURE is '
<daniels> finished sourcing confmodule in postinst; value of RECONFIGURE is
<daniels> so yeah, if you hack casper to ensure that RECONFIGURE=true when postinst gets called, that could mitigate this problem, but my god is it ever horrific
#ubuntu-devel 2006-03-20
<j^> whats the state of ubuntu on intel mac minis?
<Burgwork> j^, currently waiting elilo work, afaik. Ask mjg59 for a more definative answer
<natroll> give me a mac mini and i'll help out :D
<j^> i just got one, wanted to get a powerpc but they are out of stock
<Amaranth> mjg59 has dapper booting and working more or less right on the imac
<j^> i saw that, was just wondering if there is more info than the image with red wine :)
<jdub> j^: sweet
<Amaranth> the extra six weeks should give mjg59 a chance to get his stuff in, right? :)
<LaserJock> ohh, I can't wait until I can get K/Ubuntu on this thing :)
<mjg59> Amaranth: We just need a binutils that can build a bootloader
* jdong gasps
<jdong> are we down to a stock 1 minute boot time?!
<natroll--> 1017 packages to upgrade to dapper from a stock x86 breezy
<mike_douglas> Hey, I ran into a fairly serious bug in gnome-terminal that just appeared today. All curses applications no longer work. Can anyone else confirm this?
<crimsun> no, alsamixer -c0 works fine here.
<jdub> mike_douglas: which apps in particular?
<mike_douglas> ncmpc and irssi
<crimsun> irssi works fine here, too.
<jdub> irssi looks fine here
<mike_douglas> hmm, probably a local problem then, thanks.
<jdub> mike_douglas: worth tracking though
<mike_douglas> Yeah, I'll write something up. Resizing the window seems to fix it.
<sladen> mjg59: can you upload the known working elilo and the duff elilo somewhere?  I'd like to have a poke at them and see if there's anything obviously different
<Burgwork> ok, Ubuntu needs to get another X guru
<LaserJock> ?
<Burgwork> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/28648/
<Ubugtu> malone bug 28648 in xserver-xorg-input-synaptics "Slow movement regression of synaptics touchpad on v0.14.3+seriouslythistime" [Normal,Confirmed]  
<ajmitch> Burgwork: you don't want to step up for the job?
<Burgwork> does it involve code?
<infinity> sladen: http://www.codon.org.uk/~mjg59/tmp/efi/
<jdub> hrm
<jdub> every now and then, the screensaver is kicking in
<Burgwork> noticed that as well
<infinity> jdub: Yeah, some of us have had that bug for months, others seem to have just contracted it (so, possibly two slightly different but very similar bugs)
<jdub> i have been really slack about filing bugs so far during dapper
<bddebian> Lamer
<bddebian> :-)
* bddebian wonders if jbailey is STILL on that support call? :-)
<LaserJock> so are we going to have an macintel install party?
<bddebian> *cough*
* tritium will simply be satisfied to finally have ubunt on his iMac G5
<bddebian> Nice
<tritium> ubuntu even ;)
<LaserJock> I've been waiting to get Ubuntu on this baby
<LaserJock> I've got lots of Gigs to dual boot with
<infinity> "I've got lots of Gigs"... That just sounds strange.
<jdub> infinity: we'll upgrade your 386 soon.
<bddebian> heh
<infinity> It was more the descriptive fragment without a noun to go with it.
<LaserJock> infinity: hmm, does it? sorry if my English is bad. I'm a native speaker ;)
<infinity> Lots of gigs of WHAT?
<LaserJock> hard disk space
<infinity> jdub: s/i386/m68k/ ... And thpt. :)
<infinity> (And I did just upgrade, from a 68060 to a ColdFire...)
<bddebian> LaserJock: :-)
<infinity> (Though the ColdFire doesn't have "lots of gigs")
<tritium> hmm, there's already an ubuntu affiliate in AZ, which is only one state away...
<bddebian> Well at least it wasn't a 68030
<LaserJock> tritium: ?
<tritium> LaserJock: http://www.ubuntu.com/support/marketplace/northernamerica
<LaserJock> tritium: meet in Phoenix? ;-)
<tritium> LaserJock: any time, friend :)
<LaserJock> tritium: maybe we should have a Southwest US loco team 
<tritium> Precisely what I've been contemplating, LaserJock
<minghua> LaserJock: hey, I could be in that team too!  (/me waves from Houston)
<LaserJock> minghua's over at Rice. maybe we can claim him too ;-)
<LaserJock> lol
<minghua> there you go :-)
<tritium> definitely :)
<LaserJock> or maybe it is just the MOTU Science loco team ;-)
<Kyral> meh I'm in New York
<LaserJock> robotgeek is at UT-Arlington
<tritium> I think he moved to Boston...
<LaserJock> Kyral: you apparently need to move West
<LaserJock> hi minghua 
<minghua> hello LaserJock 
<xBeatrix> hello. can anybody help me with remastering?
<xBeatrix> :-/:(:-[
<LaserJock> xBeatrix: you might google or search wiki.ubuntu.com . I'm not sure if you'll get much here right now
<xBeatrix> i did. i came across this: https://wiki.ubuntu.com/InstallCDCustomizationHowTo
<xBeatrix> followed the instructions but got some errors
<dholbach> good morning
<highvoltage> morning, dholbach 
<dholbach> hey highvoltage
<tepsipakki> dholbach: hi! do you think zsh-beta could be synced from debian?-) They've released version 4.3.2 which has better utf8-support.. zsh-beta is in universe
<dholbach> tepsipakki: if it's a new upstream version, it requires a report
<tepsipakki> dholbach: a bug report against it?
<pitti> Good morning
<dholbach> tepsipakki: https://lists.ubuntu.com/archives/ubuntu-motu/2006-February/000545.html
<tepsipakki> hmm, I should probably subscribe to u-m
<ajmitch> morning pitti 
<pitti> hi ajmitch, how are you?
<ajmitch> good, how are you this morning?
<pitti> pretty breezy :)
<tepsipakki> how about the libpam-krb5 sync from debian (1.2.0-1 -> -2), where should I report that?
<minghua> tepsipakki: that does NOT need any special report for approval AFAIK
<dholbach> tepsipakki: same
<dholbach> ah ok
<dholbach> no, now i understand, yes, what minghua said
<irvin> hi devs! is there work underway to have a one-stop hardware compatability list for ubuntu?
<Burgundavia> irvin: thoughts, but nothing underway that i have heard of
<irvin> it would be nice to have one though.... /me scans forums and wiki
<irvin> thanks Burgundavia
<tepsipakki> minghua: ok, but who should I ping to get it sync'd, elmo?
<minghua> tepsipakki: that part I am never sure of
<minghua> tepsipakki: sync'ing seems to be broken right now, I heard the currect accepted workaround is "fakesync"
<minghua> tepsipakki: https://lists.ubuntu.com/archives/ubuntu-motu/2006-March/000572.html
<tepsipakki> minghua: ok, I _really_ need to subscribe :)
<tepsipakki> thanks
<pitti> mjg59: ping
<Mithrandir> ogra: the suspend bug has returned.
<Mithrandir> ogra: also, it seems like gnome-screensaver-preferences can't actually change the prefs when g-s goes into that mode.
<doko> good morning
<ajmitch> morning doko 
<highvoltage> dholbach: sorry, i'm working as hard as i can on it
<dholbach> highvoltage: hm?
<highvoltage> https://wiki.ubuntu.com/UbuntuBugDay/BugsForExtraPoints <- #1
<dholbach> ah nice :)
<G0SUB> are there any known issues with X locking up in Dapper?
<mvo> ping Kamion
<G0SUB> are there any known issues of X locking up in dapper?
<elkbuntu> G0SUB, dont repeat your question like that in here. people in here really are quite busy
<hunger> Anyone else having trouble upgrading ubuntu-artwork in dapper?
<G0SUB> elkbuntu: I understand ... 
<mdke> G0SUB, search the bugtracker, and if you don't find one, report the bug and a developer will look at it
* hunger has no /etc/alternatives/x-cursor-theme and wonders whether he needs to report that.
<elkbuntu> hunger, it's better to report it and have it rejected
<G0SUB> mdke: how can I do that from the console?
<hunger> elkbuntu: OK... I'll venture into the darkness called LP again:-(
<G0SUB> mdke: were there any X updates today? everything was fine before
<elkbuntu> G0SUB, does 'startx' get you into gnome at all?
<G0SUB> elkbuntu: when I start GDM I get a blank screen ... and the lockup is logged in the Xorg logs
<mdke> G0SUB, you can't do it from the console. Maybe use your stable system to do it
<G0SUB> heh, I have only one system :(
<elkbuntu> G0SUB, do you have ssh or a webserver installed?
<G0SUB> elkbuntu: ssh yes
<G0SUB> elkbuntu: I am giving you the exact Xorg logs
<elkbuntu> G0SUB, hmm?
<G0SUB> Error in I830WaitLpRing()
<G0SUB> looks like a driver issue?
<elkbuntu> G0SUB, it'd be better to get the whole logs for the devs to have a look through, rather than just one line
<G0SUB> yes, since I am in the console, I can't copy paste ... I am uploading it to a server
<sivang> morning all!
<pitti> hey sivang 
<sivang> pitti: Hi Martin :)
<mdke> G0SUB, this is more for #ubuntu, but you can copy and paste if you install "gpm" from universe
<G0SUB> ok
<G0SUB> http://zope.gnowledge.org:8080/Xorg.0.log
<ogra> Mithrandir, meh :(
<G0SUB> hello sivang !
<Kamion> mvo: yes?
<G0SUB> elkbuntu: did you check the log?
<mvo> Kamion: we don't do thai currently in the installer as a language in language-chooser, right?
<Kamion> folks, please use dpkg-buildpackage/debuild's -v option when you're building fake sync uploads
<Kamion> check that the .changes file lists all the changes since the last version in Ubuntu
<Kamion> mvo: no - there are no translations yet so it hasn't been added
<Kamion> at least some level of translation is a prerequisite there I think
<mvo> Kamion: ok, thanks
<Kamion> but it's no problem to add it once that's there
* Kamion goes to try out his whizzy new debconf
<sivang> hey G0SUB 
<elkbuntu> G0SUB, were you by any chance using totem-xine?
<elkbuntu> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-i810/+bug/22741 is the bug G0SUB has, tell him if he returns
<Ubugtu> malone bug 22741 in xserver-xorg-driver-i810 "I830WaitLpRing() lockup" [Major,Confirmed]  
<doko> funny, the OOo spellchecker proposes as a correction for "Breezy Badger" -> "Brezel Bagger"
<dholbach> hahaha
<ogra> haha, seems i finally have a track for the flickering screensaver :)
<ogra> morning mdz
<seb128> doko: do you know about that: http://ploum.fritalk.com/ooo_bug.png ?
<Treenaks> Rectangular
<ogra> jordi, ping
<jordi> pong
<ogra> jordi, you had the flicker in your screensaver, right ? 
<jordi> yeah
<jordi> let me try now to see how's it going
<ogra> can you install the xscreensaver package and do a test for me  ?
<jordi> 2.14.0-0ubuntu1 didn't change anything
<jordi> sure
<doko> seb128: nice
<ogra> just run the settings app (no need to start xscreensaver if it complains) and go to a GL screensaver ...
<ogra> GLText for example
<doko> seb128: remove one font after the other, to find out, which font is missing the glyphs
<ogra> then go to settings->advanced, and pick visual = Default from the pulldown list ...
<ogra> or Default-N
<ogra> does it flicker in xscreensaver as well then ? 
<seb128> doko: what font?
<seb128> doko: that's like the font is missing every single glyph :p
<ogra> (mdz said you see it in the preview already)
<doko> seb128: that's not uncommon with indic, tamil, ...
<seb128> I blame mvo so
<doko> seb128: iz no gtk bug!
<jordi> ogra: all is smooth
<jordi> GLText is smooth
<ogra> no flicker ? 
<jordi> all the rest are too
<jordi> ya
<ogra> hm :(
<jordi> let me try GLText in g-s
<ogra> even if you set visual = default and preview it ? 
<jordi> oh I missed that bit
<jordi> wait
<ogra> or default-n
<ogra> seems our g-s-s doesnt know the GL visual ... (no idea how to teach it to use that, but i'll find out if its reproducable)
<jordi> ogra: aha, flicker
<ogra> YAY \o/
<ogra> oki, so i have a track, thanks jordi :)
<jordi> yay
<doko> mvo: ping
<pitti> wb mdz 
<netstar> what happened to ld.so.conf?
<mvo> doko: hello, I got your question yesterday, but the sprint keeps me *very* busy
<mvo> doko: sorry for this, I may try to look at the issue again today
<Mez> erm
<Mez> seb128, ping
<seb128> Mez: pong
<Mez> seb128, ubuntu-artwork is causing errors on upgrade for me
<seb128> Mez: I knew you were going to ask that
<Mez> seb128, known problem?
<seb128> we got already 3 bugs about that, and it was fixed before reading the bugs
<Mez> ;)
<Mez> fair enough
<Mez> I'll go away then
<seb128> you guys are update manics, it's incredible
<seb128> :)
<elkbuntu> seb128, sabdfl sorta lit a bonfire under them
<Mez> seb128, well since I've had adept-notifier I update as soon as possible
<Mez> I hate the "new updates waiting" icon
<Mez> reminds me too much of windows
<seb128> update-notifier doesn't do hourly packages list update, does it?
<elkbuntu> Mez, at least it doesnt just do them then tell you every 10 mins to reboot
<ploum> ehe :-)  I like very much the Frankenstein-Launchpad post !
<Mez> seb128: not too sure
<Mez> I think I have that in my root's crontab
<seb128> Mez: anyway a quick look to launchpad before asking is appreciate, because if 100 people ping me at every bugs that's an issue
<Mez> seb128: apologies :D
<Seveas> seb128, I'm sure you could handle that
<Mez> but trying to find bugs in that thing is amazingly hard
* Seveas runs
<Mez> seb128, plus I thought it was an issue due to running kubuntu
<seb128> Mez: if you know the package is not that hard, but whatever :)
<mvo> seb128: update-notifier does it daily, no idea about this adept thing
<Mez> seb128, lol ;)
<doko> dholbach: are you doing example content?
<dholbach> yes, together with heno - he did the selection
<doko> dholbach: asking, if we could/should promote openclipart from universe to main ... 
<dholbach> doko: in fact heno wanted to drop the cliparts from example-content again
<dholbach> as it grew too big
<dholbach> hey sabdfl
<sabdfl> howdy all
<Mez> mvo: this code looks a little scary
<Mez>     m_timer->start( 1000*60 ); // 60 secs for now
<doko> dholbach: yes, it's 140MB, we should not ship it
<dholbach> doko: i referred to example-content, but yeah :)
<Mez> mvo: though it only checks the apt-cache stamp
<seb128> hi sabdfl
<Mez> (and status)
<Mez> Morning Mark
<sabdfl> hi there seb128, all settled down from last week?
<ploum> seb128: the bogus font (if any) seems to be ttf-opensymbol
<ploum> but I can't remove it : http://pastebin.com/603232
<seb128> doko: for you 
<mvo> Mez: not my code :P feel free to send bugreports
<mvo> Mez: update-notifier uses gnome-vfs monitor feature to do the same
<Mez> mvo: no - I know it's not your code - I was referring to you saying you didnt know how often adept-notifier updated itself
<seb128> sabdfl: yeah mostly, GNOME 2.14.0 has landed to dapper, now I've some good bug backlog to fight :)
<mvo> Mez: ah, right :) 
<ploum> "'m not sure that releasing a product named "Drake" is a good idea in a H5 bird flu context." 
<sabdfl> seb128: the good fight :-)
* ploum rolls on the floor :-)
<Mez> ploum, where did that come from ?
<ploum> Mez: from the ubuntu-devel list !
<mvo> lol
<ploum> That was a serious message !
<Mez> whats the Message Subject?
<seb128> sabdfl: right ;) 
<jordi> heh, that makes it even funnier
<ploum> Mez: "Dapper Drake and Bird Flu"
<Mez> nvm - got it
<Mez> and all we need to do is get mark to change his mind and say it's a dragon ;)
<Mez> :P
<doko> seb128: can you reproduce that on your machine?
<ploum> Mez: making Mark change his mind is sometimes harder than reimplementing the whole operating system ;-)
<seb128> doko: no, but I've a bunch of other font packages ploum doesn't has
<Mez> ploum, I know - I've heard
<gwenald> will ubuntu adopt linspire's click'n'run after all?
<seb128> ploum: why do you think it's ttf-opensymbol ?
<seb128> ploum: sudo apt-get -f install ?
<Kamion> gwenald: why would we want to do that? it's tied into linspire's business model
<ploum> seb128, doko : because I removed all the other fonts and I still have the bug. Also, I cannot remove this package, I don't understand (apt-get -f does nothing)
<gwenald> Kamion: i don't want that to happen. i only fear that would happen and i am anxious to know whether it will or not.
<ploum> but it's maybe not a font that is missing instead
<Kamion> gwenald: seems unlikely
<Kamion> gwenald: AFAIK there are no plans for it
<gwenald> kagou: cool then
<Kamion> gwenald: where did you hear this?
<gwenald> Kamion: osnews, iirc
<Mez> hmm
<Mez> jdub's not gonna be around now is he?
<seb128> ploum: sudo apt-get install openoffice.org-l10n-en-us ?
<Kamion> gwenald: ... ok ;-)
<ploum> seb128: already installed
<doko> ploum: could you move (or remove) your ~/.openoffice* folder, restart OOo and try again?
<ploum> doko: ok, let's do it
<seb128> ploum: your pastebin message makes no sense
<ploum> seb128: it's not "mine", it's the apt message I've got, I swear ! :-)
<ploum> interesting, I've four .openoffice* : .openoffice/                   .openoffice.org1.9.milestone/
<ploum> .openoffice.org1.9.103/        .openoffice.org2/
<jdub> Mez: what can i help you with?
<Mez> jdub: Planet RSS feed seems to be not working
<ploum> jdub: indeed. It's the hackergotchi that brokes the RSS 
<jdub> oh, really?
<ploum> doko: removed without any change
<jdub> i'll have a look - thanks
<gwenald> Kamion: you're mentioning linspire's business model, but what is ubuntu's?
<doko> ploum: strange, can you reproduce it from the live CD?
<ploum> doko: arf, no live CD here. I will try this later
<Kamion> gwenald: it's probably easiest for me to point to https://wiki.ubuntu.com/MarkShuttleworth to answer that
<ploum> thanks for interest ;-)
<Kamion> gwenald: there are long responses there from Mark to a number of questions along those lines
<Mez> ffs - people annoy me
<mvo> Kamion: for the "please run langauage-selector" you will need to put a file in /var/lib/update-notifier/user.d/
<doko> seb128: do you know which glyph is used for the dot in the login screen?
<Kamion> mvo: what deals with removing those files?
<seb128> doko: that's not only the login screen, gksudo does the same, a sec
<mvo> Kamion: nothing, it will use the time-stamp to figure if it needs to be displayed or not
<Kamion> mvo: hmm, it would be preferable if language-selector could install that file, and the installer could just say "display it if it's there, please"
<Kamion> that way I don't have to hardcode stuff about the language selector into the installer
<Kamion> well, not too much ...
<seb128> doko: U+25CF BLACK CIRCLE
<Kamion> but I guess having the installer do it is possible too
<seb128> doko: 0x25cf so
<mvo> Kamion: well, does the install know if it can't install a language complettely?
<sabdfl> gwenald: also, cast your eyes over http://geekz.co.uk/lovesraymond/archive/cancomical-lynchpad
<minghua> mvo: do you think it's worth doing to make scim provide the im-switch support so that each scim module doesn't need to create their own?
<Kamion> mvo: yes
<mvo> minghua: not sure, it depends on how much work it is to make a generic one for scim
<mvo> Kamion: if you know that, it would be enough to create a file in this dir with: "please run language selector to complete the install" (I can send you a file with the correct format)
<minghua> mvo: from what I see, all im-switch support from module packages are almost identical
* sivang -> back
<minghua> mvo: I am asking because I am planning to work on im-switch support of scim-tables
<mvo> minghua: then it is probably a good idea, maybe have one generic and make it possible for the tables to overwrite it
<minghua> mvo: and it turns out to be identical to the one I wrote for scim-hangule
<minghua> s/scim-hangule/scim-hangul/
<minghua> mvo: it's generally safe anyway since the module packages can still use their own if they want
<minghua> mvo: it's not like this approach is going to break anything
<Kamion> mvo: I think I can grok it from existing files in that directory
<ploum> doko: seb128 found the solution to the ooo font problem : removing /usr/share/fonts/truetype/openoffice
<mvo> minghua: great, that sounds good and will get us support for all tables :)
<Kamion> mvo: the problem is, Kubuntu doesn't use language-selector
<mvo> Kamion: thanks. I think this solution is a good one
<Kamion> mvo: and the code has to be the same for all derivatives
<mvo> Kamion: we'll get a frontend for it 
<mvo> right
<Kamion> mvo: by dapper?
<minghua> mvo: we still need to figure out the correct locale names (scim-tables-additional supports at least 6 languages)
<minghua> ;-)
<mvo> Kamion:  yes, it's a pretty important feature
<Kamion> ok
<mvo> Kamion: but derivaties may be a problem :/
<gwenald> sabdfl: LOL :)))
<minghua> mvo: then I'll cook a patch and ask you to review it when it's ready, okay?
<Kamion> I suppose I could use dpkg -l - the desktop is supposed to be installed by that point
<sabdfl> :-p
<ploum> yes, this cartoon is great :-)
<sivang> man, I lol'd when I saw this 
<ploum> but Burgwork's frankenstein-launchpad story is also very good (but less funny)
<sivang> ploum: ah, Burgwork also did soemthing similar?
<ploum> sivang: not in a funny way
<ploum> interesting : http://www.advogato.org/person/Burgundavia/diary.html?start=72
* sivang adds to his TOREAD list and goes back to HUB hacking.
<mvo> minghua: yes, thanks
<gwenald> sabdfl: well... are the losses at least diminishing?
<Seveas> sivang, I'm not too sure whether hubert likes to be hacked on ;)
<sivang> Seveas: heh
<gwenald> sabdfl: (noticeably)
<sabdfl> gwenald: revenue growth rate is greater than cost growth rate, i believe, but i'd need to check
<sabdfl> i'm confident we'll get ubuntu to be sustainable
<sivang> sabdfl++
<sivang> gwenald: also, the fact canonical are opening a support center in Montreal and started to look for people to man it is a good sign I believe , if that helps :-)
<gwenald> sabdfl: how could that happen, considering that ubuntu is more like a non-comercial distro? i think this is a tough mission.
<Seveas> gwenald, have you read the MarkShuttleworth wikipage?
<sivang> gwenald: when you have a good enough reputation, and you build a strong team that does specific needs tailoring and on site services, you can increase revenues.
<gwenald> sabdfl: i mean... even esr would advice you to sell software (i guess) :))
<sivang> gwenald: and what Seveas said :)
<Kamion> gwenald: Ubuntu's non-commercial, but Canonical offer support/services on top of that
<Kamion> well, perhaps "free-as-in-beer" is a better description than "non-commercial" here, but whatever
<gwenald> Kamion: oh, right -- sabdfl: is canonical profitable?
<ploum> Don't forget the Orange sponsoring for this release..
<gwenald> Kamion: right
<sivang> heh
<pitti> ploum: what's this "Orange", a popular company in the US, or whereever?
<ploum> pitti: I don't know in the US but well here in Europa
<ploum> mobile phone operator
<pitti> ah
<Seveas> not just in US, in NL/FR and several other countries too
<sabdfl> gwenald: no, canonical isn't profitable, but i'm working on it and confident
<jordi> pitti: ping
* pitti hugs jordi
<jordi> pitti: so power manager is showing this very green icon
<gwenald> sabdfl: could you please name another company which has an economical model closest to what canonical is aiming at?
<netstar> linspire?
<netstar> :P
<ploum> Microsoft ?
<jordi> Tooltip is: "Computer is running on AC power. Laptop battery charging (100%).
<ploum> 99% is pirate software
<jordi> pitti: do you see that in your apple?
<pitti> jordi: ok?
<ploum> only 1% of their marketshare pay the 99% others ;-)
<sabdfl> gwenald: mysql, mozilla.com
<pitti> jordi: ah, right, 100% and charging
<netstar> (m)anyone running on an iMac G5?
<pitti> jordi: hm, there are some wrong boundary conditions here as well, right, but I need to check
<pitti> jordi: mine's at 89%, charging now and checking
<jordi> pitti: I guess this is hw stuff going on, as in the laptop not sending a "I'm not charging anymore" signal
<pitti> jordi: so hal should grow a light sensor to watch the color of the cable plug :)
<jordi> pitti: PM could detect it's at 100% and go away if it can't be fixed at kernel level too easily
<jordi> pitti: lol
<jordi> pitti: the funny thing is, it's orange right now
<pitti> jordi: well, then it *is* charging
<pitti> jordi: so maybe rather the percentage is wrong?
<jordi> it's at 100% tho
<jordi> hmm
<jordi> It was at 0% at 9AM
<jordi> because I had been.. uhm, "testing" mame last night.
<Kamion> pitti: old mozilla-thunderbird-locale-{ca,de,fr,it,nl,pl,uk} source removed (was it you who asked me for that?)
<pitti> Kamion: yes, I was; thanks
<Kamion> doko: was it you who asked for ia32-libs-dev/amd64 to be removed? there are still build-dependencies on it (fakeroot, grub, etherboot, fakechroot, x86info)
<Kamion> I'll look at grub now
<doko> Kamion: I see, I'll replace them with libc6-i386-dev
<jono_> hey all
<jono_> any word if the delay is happening yet?
<jordi> mdz: here?
<Riddell> jono_: no
<Kamion> it'll be announced when decided
<jono_> Kamion, ahhh cool :)
<jordi> Kamion: we were talking to matt about syncing ttf-freefont from Debian yesterday. mdz seemed ok with this, but we never made the final push. The new snapshot in Debian is iirc 2 months old, no new bugs in the BTS, and our tests showed it helped in a number of ways, Bengali being prominent.
<jordi> Kamion: No upstream changelog, Debian changes look sane.
<Kamion> if mdz's OK with it, it's fine by me ...
<jordi> he appeared to be positive, but cautious at the same time. He avoided saying a clear "yes" at that moment, but said it looked good
<seb128> Kamion, mdz: is that of to update shared-mime-info, that's the freedesktop mime database, the tarball was pretty old they rolled a new one for GNOME 2.14. Quite a bunch of new types definitions and some fixes with it  ...
<jordi> Kamion: the other change I'm proposing is changing fontconfig's default font from bitstream vera to DejaVu. seb128, any comment on this?
<seb128> jordi: we already did that, no?
<jordi> Kamion: Debian #317907 has a comment by keithp accepting the change
<Ubugtu> debian bug 317907 in libfontconfig1-dbg "include ttf-dejavu as one of the alternatives in depends" [Wishlist,Closed]  http://bugs.debian.org/317907
<jordi> seb128: ubuntu doesn't have it
<seb128> jordi: oh, no it was
<seb128>   * fonts.conf.in:
<seb128>     - Add DejaVu fonts immediately after Bitstream Vera, for better i18n
<seb128>       character support love.
<seb128> I don't know the different enough to advocate switch or not
<jordi> seb128: should be swapped, I believe
<jordi> background is DejaVu is a fork of Vera, with a ton of fixes distros had been applying, after Bitstream never released new versions of Vera.
<jdub> jordi: fixes to existing glyphs?
<jordi> Adds fixes for existing glyphs, plus adds lots of support for central/east European languages, etc.
<jordi> jdub: some glyphs that looked bad, afaik
<jdub> hrm, ok, if it fixes existing glyphs then i'd agree
<seb128> doko: I think that would fix the password char issue :)
<jdub> the reason i did it that way around was because it's easier to stick with the vera name
<jordi> jdub: stick in what sense?
<jdub> jordi: actually having the font name work
<jdub> jordi: if we actually remove vera, but make an alias for it to dejavu, that would work too
<jordi> jdub: we need to forget about vera at some point. DejaVu should become  the standard.
<Kamion> jordi: erm, ok, you're overloading my stack here, could you please send exception requests by mail?
<jordi> jdub: works for me too, but is a more aggressive approach I guess
<Kamion> fontconfig font changes are up to the desktop team as far as I'm concerned
<jdub> jordi: that's kinda what i wanted to avoid without there being some kind of wider buy-in :)
<jordi> Kamion: ok. I asked, people told me IRC was ok :)
<jdub> jordi: perhaps this is something we could pitch at guadec
<jordi> jdub: nod
<Kamion> seb128: sounds sensible
<jdub> jordi: feels a bit sucky towards bitstream though (i'd like to try one last time to get their attention)
<jordi> jdub: I agree with that
<jordi> it's been three years though
<jdub> slackeurs
<jdub> i'll mail jim
<jordi> I read "I'll jail me"
<jordi> jdub: ok.
<jordi> jdub: as for the swapping, should I keep looking a this, or should we punt for dapper+1?
<doko> jordi: the problem is that dejavu glyphs don't have the same dimensions, which is bad
<doko> for printing ...
<jdub> doko: yeah
<jordi> this appears to be escalating upstream already, with keith agreeing to the change
<jordi> ah, I didn't know that
<jordi> so it's bad if ou mix vera and dejavu
<jordi> if dejavu goes in first, you're very likely to not see vera at all, right?
<jordi> vera is now a subset of dejavu
<jdub> well, there are two problems there
<jdub> there's the mixing problem
<jdub> but even with just dejavu, different dimensions have an impact on printing
<jdub> and all rendering
<jdub> so, for instance, my presentations will end up out of proportion
<jdub> ;)
<jordi> btw, I loved your "7" entry :)
<jdub> jordi: perhaps the best thing to do is make the generic names map to dejavu first, but install both fonts
<jdub> thanks :)
<jordi> aha
<jordi> right ow debian installs dejavu OR vera OR something OR something
<Treenaks> jordi: OR or XOR?
<jordi> you'd want dejavu and bitstream in fontconfig's deps
<jordi> Depends: debconf (>= 0.5) | debconf-2.0, ucf (>= 0.29), ttf-dejavu | ttf-bitstream-vera | ttf-freefont | gsfonts-x11 | msttcorefonts
<jordi> wow, msttcorefonts
<jdub> *fontconfig* deps? interesting
<jordi> jdub: of course, they need to follow what fonts.conf say is prefered
<jdub> jordi: yeah, i'd change the second two pipes to commas on that line :)
<Treenaks> fontconfig depends on fonts? surely it should be the other way around?
<jdub> Treenaks: naw, this makes sense
<jordi> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317907
* jdub just finds it interesting for debian to do that
<Ubugtu> debian bug 317907 in libfontconfig1-dbg "include ttf-dejavu as one of the alternatives in depends" [Wishlist,Closed]  
<jdub> but i guess it's sufficiently ORed ;)
<doko> seb128, jordi, jdub: some hack at http://people.ubuntu.com/~doko/ttf-dejavu_2.3-0ubuntu2_all.deb
<jdub> doko: what's this?
<jdub> (well, apart from being dejavu)
<doko> jdub: a smaller dot that seb128 can handle
<jordi> let  * 0x25cf hack.
<jdub> oh right
<jordi> that's a cool changelog entry ;)
<seb128> too small 
<seb128> imho
<doko> jordi: I don't plan to upload that
<Treenaks> -hack?
<jordi> doko: I know
<jordi> that's for the passwords thing right?
<doko> seb128: right, I'm asking upstream for a fix, these are about 15 glyphs in 10 fonts ... I don't want to edit these by hand ...
<doko> yes
<jordi> right... I was concerned this was a replacement for other dots
<jordi> ;)
<jordi> jdub: summarizing. What changes would you propose?
<infinity> Kamion: Was that changelog entry dylexic, or does grub really build-depend on libc6-i386-dev (rather than libc6-dev-i386)?
<jdub> jordi: i guess i'd suggest shipping both, using dejavu as the primary choice for the generic names
<infinity> s/dylexic/dyslexic/
<jordi> jdub: alright
<huggymuggy> hi all
<Mez> infinity, did you upload that patch for scim yet ?
<mvo> Mez: what patch is that?
<Mez> mvo: the one to make it backportable
<Kamion> infinity: both the changelog entry and the control file were dyslexic; fixing
<Kamion> infinity: dylexic> oh the irony
<Kamion> infinity: fixed, thanks for the heads-up
<jordi> jdub: depending on both, you mean getting rid of alternatives for vera and dejavu, ie ttf-dejavu, ttf-bitstream-vera, ttf-freefont | gsfonts-x11 | msttcorefonts
<doko> Kamion: please could you promote fdupes to main (reviewed by pitti), so the next OOo upload can use it?
<jordi> that pulls 3 fonts, not two
<jordi> I'd do dejavu, vera | this | and | that
<doko> jordi: pleae not. maybe dejavu is better for the screen, but definitely not for printing
<jdub> jordi: yes
<Kamion> doko: done
<jordi> doko, jdub: yes or no?
<doko> jordi, jdub: both, but prefer bitstream-vera for printing ...
<doko> btw, from the OOo sources:
<doko> # The bitstream fonts never make sense _at all_ they are so metrically odd.
<doko>     s/Bitstream Vera Sans;//g;
<doko>     s/Bitstream Vera Sans Mono;//g;
<doko>     s/Bitstream Vera Serif;//g;
<jordi> doko: for printing only? Not sure how to do that.
<doko> jordi: maybe that was OOo specific ...
<bSON> hi
<slomo> infinity, lamont: please give-back evolution-sharp on ppc, thanks ;)
<jordi> doko: lunchtime here.
<jordi> doko: I don't se eany printing specific config here. It could well be OOo specific.
<jordi> I see your concern though.
* mvo goes to lunch now
<jordi> doko: that issue is not fixed with vera?
<jordi> err
<jordi> with dejavu
<jordi> back later
<doko> jordi: which issue?
<jordi> the sizes issue
<doko> no, addressed on the dejavu ML
<jordi> pitti: hmm. now it's green, pm disappeared
<pitti> Kamion: I cleaned up anastacia output a bit; some package fixes and promotion approvals on https://wiki.ubuntu.com/UbuntuMainInclusionQueue
<pitti> jordi: 10 minutes to go for me; there seem to be hiccups after resuming, if the battery is already full
<doko> abelcheung: minghua (currenty not online) did a first check of OOo and scim. I have no tutorial how to check it for myself (on a western keyboard), so a short description would be nice
<stub> Launchpad is going down in 15 mins for a regular code update. Estimated downtime is 10 minutes. Wikis will be in read only mode during this time.
<martink> doko: there's (very little) scim/ooo documentation in ooo-build/doc/im.txt. You probably want to use the gtk+scim instructions
<Kamion> pitti: noticed some of that, thanks
<infinity> slomo: I'd love to, but it failed because the build-deps are uninstallable, giving it back won't change that.
<sivang> can anybody tell me if to be able to use cdrecord to read last session's offeset, the drive must be an /R/RW drive and not plain read drive (CD/DVD)
<Kamion> infinity: was that due to lack of libxml-libxml-perl making gtk2-sharp-gapi uninstallable?
<sivang> ?
<Kamion> that's on the promotion list
<martink> doko: oh, and the magic key combo to activate scim is Ctrl+Space
<infinity> Kamion: No, gtkhtml and gnomeprintui out-of-datedness, it looks like.
* infinity sorts.
<seb128> infinity: what about those*?
<infinity> Or, just gnomeprint, actually.
<slomo> infinity: oh, right... last time i looked the failure was something else so you have given-back it already some hours ago it seems... sorry for the noise
<infinity> seb128: Oh, nothing, I think I'm just waiting on cron.daily to finish actually.
<infinity> slomo: I'll toss it back to the wolves.  After this cron.daily, it should be okay...
<slomo> infinity: thanks
<pitti> jordi: WFM
<sivang> hrm
<sivang> pooh@tigershark ~/my/upbackup--main/UPBackup/backend $ sudo mount -o loop=/dev/loop0 test.iso test_iso/
<sivang> mount: Not a directory
<sivang> what am I doing wrong?
<Treenaks> sivang: does the 'test_iso/' directory exist?
<Treenaks> sivang: in .
<sivang> Treenaks: yes, it does.
<sivang> Treenaks: weirdness
<ogra> sivang, try  sudo mount -o loop test.iso test_iso
<ogra> let the kernel care for the device
<sivang> okay, let's try.
<ogra> or better sudo mount -o loop test.iso ./test_iso
<sivang> pooh@tigershark ~/my/upbackup--main/UPBackup/backend $ sudo mount -o loop test.iso ./test_iso
<sivang> mount: Not a directory
<sivang> what the..
<sivang> I can swear this worked once
* sivang grumbels
<sivang> ogra: can you try something like that onyour dapper see if it works?
<ogra> sivang, i do it all the time if i test flight isos ...
<sivang> oh bad, that something has went crazy in my system
<ogra> to check the contents and seeds
<Kamion> sivang: you sure that ./test_iso is a directory (and that you typed its name right)?
<sivang> root@tigershark:/home/pooh/my/upbackup--main/UPBackup/backend # ls -la | grep "test_iso"
<sivang> drwxr-sr-x 2 pooh pooh     48 2006-03-15 15:25 test_iso
<sivang> and I use tab completiong, and checked that I typed correctly.
<sivang> I'm on  2.6.15-17-686 #1 SMP PREEMPT
<jono> Kamion, are all filesystem types resizable in espresso ?
* dholbach hugs mvo
<sivang> Kamion: any idea ? has my system gone insane?
<Pygi> mvo: I'd like to help developin' synaptic
<sivang> Kamion: oh, I didn't address you directly, so you may have missed - yes, I am sure that I am using the correct dir.
<sivang> Seveas: yes, I need to . let try to make the calander work thugh before :)
<sivang> argh, this doesn't make any sense
<Kamion> jono: anything that parted knows how to resize is resizable in espresso - that's everything that people care about with the exception of NTFS. In d-i we use a special hack to resize NTFS, and if there's time we'll do that in espresso too.
<jono> Kamion, ok cool
<ogra> Kamion, i installed my GFs new laptop last weekend and resized the existing NTFS partition from a breezy liveCD with gparted ... 
<ogra> worked fine ...
<bddebian> ogra: Awesome, wanna help me get Dapper or Breezy running on my Proliant ML350? :-)
<ogra> bddebian, i'm not a kernel dev :)
<bddebian> Bah :-)
<ogra> doesnt hurd work ? 
<bddebian> On the Proliant? Hahahaha :)
<bddebian> I'm going to try Sarge today :-(
<Kamion> ogra: ah, yes, you're right, it already uses ntfsresize for that
<Kamion> jono: ^--
<mvo> Pygi: great, what particular bits are you interessted in ?
<abelcheung> doko: sorry, I'm back now, was having lunch
<abelcheung> doko: I'll list the testing procedures one by one:
<sivang> bddebian: joining the serer team efforts? :)
<abelcheung> doko: 1. install openoffice.org-l10n-zh-cn and openoffice.org-l10n-zh-tw, and check if the interface shows OOo chinese characters correctly
<abelcheung> doko: s/openoffice.org/openoffice.org2/
<bddebian> sivang: Hmm, maybe I should :-)  But no one likes my type of help.  I annoy everyone :-)
<sivang> re the mount problem, Seveas also tried that:
<sivang> 14:33 < Seveas> stat64("/sbin/mount.iso9660", 0xbfa08fcc) = -1 ENOENT (No such file or directory)
<sivang> 14:33 < Seveas> mount("/dev/loop0", "./test_iso", "iso9660", MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec0000, 0x8074f38) = -1
<sivang>                 ENOTDIR (Not a directory)
<doko> abelcheung: please could you write this down in a wiki page?
<abelcheung> doko: no problem!
<Seveas> (sivang: using full paths for both iso and dir doesn't work either)
<sivang> Seveas: pretty amazing.
<sivang> when I touch a dummy file and use it as the target it works
<sivang> but I can't do anything with the file though
<sivang> as it's not a dir
<sivang> maybe the iso is screwed..
<koke> mvo: the language-selector.desktop file is not being regenerated from the .in
<gwenald> somebody please recommend me a repo with gaim 2.0 beta 2 compiled for ubuntu?
<koke> anyway, try changing Icon: language-selector.png to Icon: config-language to fix #32371
<mvo> koke: oh? not regenerated is bad
<koke> mmm, mvo you have to cd data && make
<koke> then it works
<mvo> koke: right, we should add that to setup.py :)
<koke> yep, just for curiosity, why did you switch to python distutils
<koke> it's rather annoying to have translations regenerated in every build/install
<sivang> Kamion: I find out the source of error with mount. I created an image of a multisession target, when I created a non merged one, it would loopback mount it. the error msg was misleading. Do you have any idea why I can't mount merged multisession images?
<Kamion> sivang: sorry, I have no idea
<sivang> Kamion: okay, np.
<mammoth> hi
<bddebian> Hello mammoth
<mammoth> how r you?
<bddebian> Fine thank you.  You?
<mammoth> fine
<mammoth> i dont work 2day
<mammoth> and what u do?
<mammoth> i mean work
<slomo> Kamion: hi, i uploaded gtkpod-aac (a NEW package) almost a month ago but it didn't get through NEW yet and nobody saw a REJECTED mail... is it still in NEW or what happened to it?
<mvo> Kamion: can we get a upstream version freeze expection for ttf-freefont? the new package has better bengali, tamil etc (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350517)
<Ubugtu> debian bug 350517 in udeb "Please package the last version" [Doubt....,Closed]  
<Kamion> mvo: that bug suggests that there are still bad spacing problems with the new version?
<Kamion> slomo: it's in NEW, sorry, my bad
<sivang> pitti: any complains about my packaging? :)
<slomo> Kamion: ok, np :) it's in general the gtkpod package with a new build-dependency from multiverse and conflicts/replaces/provides magic
<pitti> sivang: no time yet, sorry
<sivang> pitti: sure, np, whenever you have, I just want the package to pass you before it enters the archive, even that it will be universe.
<Kamion> slomo: accepted now
<Kamion> slomo: I have to confess that I generally avoid the stuff with "interesting" licensing in NEW in the hope that elmo will do it instead
<slomo> Kamion: understandable... i won't like to process them too ;) but this one was fortunately simple as it has nothing bad other than a build-dependency :)
<Kamion> slomo: right, although I am somewhat concerned about stuff in multiverse that's GPLed with no exception
<Kamion> isn't there a question whether that's distributable?
<slomo> Kamion: good question... no idea :/ but this would affect almost everything in multiverse
<Kamion> that surprises me, I'm pretty sure most things there are either not GPLed or have an explicit exception clause
<Kamion> slomo: could you check with the upstream author to get an explicit licence exception for linking with whatever non-free/patented stuff you're using?
<pitti> isn't that also a question of patents?
<Kamion> quite so, see GPL section 7
<Kamion> if the upstream author is not content with this, please tell me ASAP and I'll remove the package
<Kamion> sorry, I only thought of this after processing
<Kamion> this is why I hate going anywhere near multiverse :-/
<slomo> Kamion: i'm pretty sure that many things in multiverse are GPL/LGPL without an exception clause... but i'll verify this later... and write a mail to the gtkpod author about that
<Kamion> LGPL + non-free/patents without an exception clause is fine, AFAIK
<Kamion> although I'm not entirely sure about patents
<slomo> pitti: in this case it's only a question of patents ;)
<Kamion> I think it's OK though
<slomo> Kamion: "as a consequence of a court judgment or allegation of patent infringement" there was no court judgment or offical allegation of patent infringement by the patent holders yet from what i know... although that doesn't make it much better as faad definitely infringes patents
<slomo> Kamion: anyway... how would such exception clause look like? do you have an example in mind? :)
<Kamion> you snipped "or for any other reason" from that clause, which is kind of relevant (consider a known patent licence) :-P
<Kamion> slomo: googling for "GPL exception clause" led me to http://lists.debian.org/debian-legal/2001/08/msg00067.html in about four or five clicks; I'm sure you can find others
<Kamion> http://gstreamer.freedesktop.org/documentation/licensing.html has similar stuff
<slomo> Kamion: so knowing that this infringes a patent is "any other reason"? ok, i didn't understand it that way but could be related to my english :)
<slomo> thanks, i'll get a mail ready to the gtkpod author :)
<Kamion> dude, "knowing that this infringes a patent" is *stronger* than "allegation of patent infringement"
<Kamion> if you already know, nobody needs to allege it
<Kamion> the GPL is kind of assuming that you aren't wilfully breaking the law in its wording
<bddebian> "breakin' the law, breakin' the law"
<Kamion> but "any other reason" covers anything that imposes conditions on you contradicting the terms of the GPL
<Kamion> unless there is an exception clause from the authors of all the GPLed material allowing you to do otherwise, then if you can't distribute the work as a whole under the terms of the GPL, you can't distribute it at all
<slomo> Kamion: ok thanks, good to know...
<pitti> off to another espresso install try :)
<pitti> Kamion: is 'sudo env ESPRESSO_DEBUG=1 espresso' the right thing?
<pitti> Kamion: (nevermind, seems so, the log is veeery verbose now)
<Kamion> pitti: I use ESPRESSO_DEBUG=1 sudo espresso, but yeah, same difference
<pitti> meh, I cannot get past that 'dispositivos duplicados' error
<Kamion> ("duplicate mountpoints")
<Kamion> wurgle, why the hell isn't partman offering me the chance to erase the whole dis
<Kamion> k
<Seveas> Ubugtu just got a bit more useful
<Kamion> I have a feeling it didn't manage to detect any disks ...
<Seveas> he will now manage the topic in #ubuntu-meeting and fill it with the fridge ical feed
<Kamion> Oh. That would be because I forgot to add any in vmware. d'oh.
<Kamion> Mithrandir: any idea why /sbin is mode 700 on today's live CD?
<Mithrandir> Kamion: what does dmesg look like?
<Kamion> pretty normal - although some DriveReady SeekComplete Error things about hdc
<Kamion> but that's really weird since this is inside vmware, so I'm inclined to discount it
* Kamion greps the archive for /sbin other than mode 755
<Riddell> I can't confirm the /sbin issue
<Mithrandir> Kamion: it's probably just squashfs smoking something.
<Mithrandir> Kamion: try rebooting and see if it fixes it
<Riddell> Mithrandir: it's a live CD
<Mithrandir> Riddell: yes, and?
<Kamion> I think it's safe to assume Mithrandir is familiar with live CDs
<Kamion> it seems to be incredibly confused about networking too ...
<Kamion> yeah, sod it, I'll reboot :-/
<Mithrandir> Kamion: I'm slightly worried about the "let's go smoke crack" behaviour that we see from squashfs a bit too often. :-/
<Kamion> ich auch
<pitti> Mithrandir: confirmed, /sbin is 0700 here, too
<Mithrandir> pitti: and nothign interesting in dmesg in your end either?
<Kamion> same behaviour after reboot, except that networking isn't randomly broken any more
<bddebian> Fuck, no Dapper, Breezy, or even sarge will install on this ML350.. :-(
<azeem> tried etch beta 2?
<azeem> it got released today
<Kamion> bddebian: what breaks?
<bddebian> azeem: No not yet
<bddebian> Kamion: It just hangs
<Kamion> at what point?
<bddebian> On Breezy I get:
<bddebian> 4294668.82100 ACPI: Looking for DSDT.. not found!
<bddebian> 4292668.92100 not found!
<bddebian> hang
<seb128> Kamion, mdz: read my question about new shared-mime-info some hours ago?
<pitti> Mithrandir: not really, at least nothing that looks like oopes and such
<Kamion> seb128: read my answer some hours ago? ;-)
<Kamion> 12:18 < Kamion> seb128: sounds sensible
<pitti> $ dmesg |grep squash
<pitti> [   59.117343]  squashfs: version 3.0prerelease (2006/1/24) Phillip Lougher
<bddebian> Kamion: Any ideas?  I have tried acpi=off pci=noacpi noapic DEBCONF_DEBUG=5 BOOT_DEBUG=2 to no avail :-(
<Kamion> bddebian: I'm afraid not - kernel folks might know better
<bddebian> I've tried them :-(
<Kamion> hangs before the installer actually really gets started are well outside my area of expertise
<xhaker> bbdebian.. Asus laptop?
<bddebian> xhaker: Compaq Proliant ML350
<xhaker> i've seen hangs with the loading of hw_random module on Asus laptop
<xhaker> 's
<seb128> Kamion: nop, I didn't sorry :) What is sensible about it? That's mainly next type definitions, nothing likely to break the world
<Mithrandir> pitti: I'm off for dinner, so ttyl
<seb128> Kamion: and a good bunch of fixes for differents mimetypes too
<Kamion> seb128: "sounds sensible" == "ok"
<Kamion> as in, go ahead
<seb128> k, /me hides :)
<bddebian> seb128: Did you get the alternatives thing working the way you wanted?
* Kamion gives his acknowledgements in triplicate. :-)
<seb128> Kamion: thank you :))
<pitti> Kamion: is there an easy way (besides rebooting the live CD) to purge the espresso settings? It keeps wanting to format a partition it isn't supposed to
<seb128> bddebian: out of the way that update-alternatives doesn't create the dir if required yep :p
<Kamion> pitti: possibly rm -rf /var/lib/partman; it sounds as if partman is very confused
<pitti> ah, thanks
<Kamion> but I haven't looked at the log yet
<bddebian> seb128: :-)
<pitti> Kamion: (I filed bugs along the installation, I just need some help to actually finish one :) )
<seb128> s/way/fact
<Kamion> pitti: can you wait a minute and I'll have a quick look at the log?
<Kamion> just in case there's something else I need
<pitti> Kamion: oh, sure
<pitti> Kamion: kudos for your fast mail reading, BTW :) do you have a red lamp that flashes whenever a new espresso bug is filed?
<Kamion> pitti: oh, in fact never mind, your comment clarifies exactly why it happened
<pitti> Kamion: alright, then 'insert coin and try it again' :)
<lemsx1> hello all
<Kamion> pitti: yeah, I just need to make PartmanCommit clear out old state
<lemsx1> the sketch program is supposed to work by just calling it from the command line like: sketch ?
<pitti> Kamion: I saved the old /v/l/partman, just in case
<pitti> hm, it *still* knows my name
<lemsx1> i installed inkscape (just to play around) and saw that it suggested a few other programs. sketch gave me a bunch of errors when i tried to execute it
<lemsx1> oh, old bug #5347
<Ubugtu> malone bug 5347 in sketch "sketch does not start" [Major,Unconfirmed]  http://launchpad.net/bugs/5347
<Kamion> well, there are no .debs in main or restricted that ship /sbin as anything other than mode 0755
<Kamion> and no obvious chmods in /var/lib/dpkg/info/
<Kamion> infinity: any clue what's going on here?
<doko> infinity, lamont, Kinnison: any reason why openoffice.org-l10n is not picked up by the buildd's?
<Kinnison> is the source in?
<doko> yes
<Kinnison> only just
<Kinnison> It'll probably all start up in the next few hours as it settles after the problem we had earlier
* pitti_live sighs at xchat-gnome
<doko> Kinnison: what do you mean by "just", the .orig.tar.gz?
<Kinnison> the datetime on the publishing record is seven minutes ago
<Kinnison> so I imagine the buildds haven't got it yet
<doko> ahh, ok
<Kinnison> doko|imatient
<Kinnison> erm impatient too
* Kinnison needs new fingers
<doko> heh ... I did upload these 3 hours ago ;)
<Kinnison> yeah, and we had some db issues today with the lp upgrade
<fstat> hello
<sivang> Kinnison: ruined your fingers with the lp upgrade? :)
<sivang> Kinnison: what's up?
<Kinnison> sivang: Naah, lots of hacking on LP this week
* Kinnison has been having fun doing lots of cool stuff for LP
<sivang> Kinnison: well, tha'ts alwasy good :)
<sivang> Kinnison: I'm sure you had, and paying with fingers is a small price to pay :-D
<sivang> Kinnison: are you able to review a package of mine so I can take it off pitti_live 's busy back? :-)
<Kinnison> sivang: Sure, mail it to me, I.E. the source package
<Kinnison> sivang: If it's not in my INBOX, I won't have it offline later
* sivang rushes up
* pitti_live sighs at Dispositivos duplicados and finally gives up
<sivang> Dispositivos duplicados ?
<Kinnison> doko: BQB is running
<sivang> Kinnison: sent
<sivang> Kinnison: see if you get it
<mdz> seb128: can you repeat it?
<seb128> mdz: what? shared-mime-info stuff? Kamion gave me approval so I've uploaded
<mdz> seb128: ah, ok
<mdz> (yes)
<KaiL> damn f*cking powernowd
<KaiL> it starts to become some tradition, that it breaks on this system ;)
<Kinnison> sivang: where did you send it to, it's still not turned up
<siryes> Hello, good Ubuntu people! I'd like to ask a general question about gksu package.
<mvo> siryes: just ask, that is in general better than asking for permission :)
<siryes> Since the Dapper is going to be released a bit later, and Ubuntu team is intended to provide a long support for it (36-60 months), I'd like to support this basic utility by providing a Polish translation.
<pitti> seb128, Riddell: mmm, fresh language packs on http://people.ubuntu.com/~pitti/langpacks/ - wanna help testing them?
<pitti> grab them while they are hot :)
<Riddell> pitti: any changes to the packaging, or just updates?
<pitti> Riddell: just fresh translations
<pitti> Riddell: maybe you can watch out for amarok
<siryes> I've created a set of updated .po files which can be found on the Polish Gnome Translators' page: http://www.gnomepl.org/gksu ; http://www.gnomepl.org/libgksu ; http://www.gnomepl.org/libgksuui
<seb128> siryes: subscribe to the rosetta team for your locale
<siryes> I just don't know who to ask to put it in the Ubuntu packages. The Polish translations of the aforemntioned packages are horribly outdated... :-(
<siryes> rosetta team, ok. Where to find them?
<pitti> Riddell: darn, it seems that amarok was not updated, might still be the old tarball
<pitti> Riddell: I forgot to check for that before building the new packs
<seb128> pitti: gstreamer-0.8 translation is dropped but no gstreamer-0.10 one replace it
<pitti> Riddell: so it seems we need a no-change upload to get a new translation tarball (currently importet one is 2:1.3.8-0ubuntu2)
<sivang> Kinnison: dsilvers@canonical.com
<siryes> ok, got it: https://launchpad.net/people/ubuntu-l10n-pl
<siryes> Is this team responsive? ;-)
<Riddell> pitti: latest amarok is 2:1.3.8-0ubuntu6, why will uploading it again change which version is used for the translation tar?
<pitti> seb128: hm, find -name 'gstream*' delivers gstreamer-0.10.po, isn't that right?
<seb128> pitti: ups, sorry, was already shipped by previous set in fact
<pitti> Riddell: probably 0ubuntu6 was uploaded while sbuild didn't export tarballs
<seb128> I sort of debdiffed
<Riddell> pitti: ok, I'll do that now
<seb128> and noticed gst0.8 droppage but no new gst0.10 :)
<seb128> pitti: looks good to me
<seb128> pitti: thank you :)
<Kinnison> sivang: Hmm, try again to dsilvers@digital-scurf.org
* seb128 goes for dinner
<sivang> Kinnison: sec
<pitti> Riddell: alright, I'll build the packs again after that
<seb128> pitti: I've installed them and tried some apps, looks fine
<pitti> seb128: better than before? i. e. with gnome 2.14 love?
<sivang> Kinnison: sent
<bddebian> w000t.. Mithrandir, you were soo close
<bddebian> I needed noapic AND nolapic
<mvo> does anyone here has a opinion about the free-ness (main ready) of the OFL license ?  (http://www.sil.org/OFL)
<Kinnison> sivang: looks like one has turned up
* Kinnison asks evo to offline it
<Kamion> mvo: 404
<mvo> Kamion: *cough* make that http://scripts.sil.org/ofl
<pitti> seb128, Riddell: current packs look fine to me; I'll build new ones tomorrow then, when amarok is imported
<sivang> Kinnison: thanks
<sivang> btw, what's with that erro message from cdrecord - Error: Cannot gain SYS_RAWIO capability.Is cdrecord installed SUID root?
<sivang> : Operation not permitted
<Riddell> pitti: no gwenview either, it had the same problem as amarok and was fixed around the same time, I'll re-upload that too for luck
<pitti> yes, thanks
<pitti> Riddell: I can import the two tarballs on their own for a quick test before cranking up the full build
<pitti> wow, our installer is really nice - I now have FOUR partitions which are all labeled '/' and gnome-vfs only shows the label
<pitti> Kamion: any chance to stop labelling the partitions by default? or is that a particular pet feature of you?
<mvo> doko: scim seems to work fine in OOwrtie on amd64 (version from today, tested in vmware)
<doko> mvo: hmm, nice, so how does scim work? it's an extra layer? I'm just wondering, because the modules in /usr/lib32/gtk-2.0 don't exist ...
<sivang> pitti: it seems I need to dpkg-reconfigure cdrecord , and enable SUID root for the binaries to make the SYS_RAWIO error message go away. isn't this supposed to be supported without SUID bit set for the latest kernels?
<Kamion> pitti: I can't decide between "should use better labels" and "gnome-vfs should be a bit smarter when labels clash"
<Mithrandir> sabdfl: X fallback on live cd is basically "if we fail to start X, retry with vesa?"
<Kamion> pitti: I do think the labels are useful - your problem only arises when you have several multiply-booted Linux installs, which I'd venture to suggest is a corner case
<sabdfl> Mithrandir: i don't know, it's just "don't die horribly"
<sabdfl> whether thats "die gracefully and tell the user how to try again with vesa"
<sabdfl> or "keep things under control and come back to offer alternatives"
<sabdfl> we should consider free drivers, non-free and vesa
<Kamion> somebody said the other day that there's a problem using the non-free drivers on the live CD, because they install a version of libGL that's incompatible with the free drivers
<Kamion> I didn't catch the details, but it seemed to me like it might be relevant here; I think infinity knows more
<Mithrandir> I could investigate more, in my copious free time.
<janimo> Kamion, at least fglrx libGL on install diverts the original one, maybe that's what they meant
<Kamion> janimo: right
<GFDL> in dapper the terminal server client doesn't save advanced settings like local resources (e.g. keyboard setting) or username in the rdp file
<GFDL> only the computer name is saved
<GFDL> for complex settings everytime the settings must be reentered
<LaserJock> GFDL: have you reported/searched for an appropriate bug report?
<pitti> re
<GFDL> I will take a look now, I haven't checked yet
<GFDL> the .rdp file contains entries for username, etc. but all are empty
<seb128> pitti: not easy to say, I built a lot of stuff on my box so I've a lot of .mo installed
<seb128> pitti: so my translations are fine without language pack :)
<pitti> seb128: heh, true :)
<seb128> Kamion, mdz: GNOME guys got a new libxklavier 2.2 bug fix tarball for GNOME 2.14.0, is that ok to update?
<seb128> Kamion, mdz: there is 3 changelog entries since the version we have, all bug fixes so it should be just fine
<Mithrandir> seb128: would it be hard to make double-clicking a date in the calendar in the clock applet actually open evolution on the right date?
<seb128> Mithrandir: it has not been done before because evolution lacked the API to do that
<seb128> Mithrandir: need to check if that's still true
<Mithrandir> seb128: it appears to have some support for it, but I haven't been able to get the magic incarnations to work yet.
<seb128> Mithrandir: upstream bug about that is http://bugzilla.gnome.org/show_bug.cgi?id=162305
<Ubugtu> gnome2 bug 162305 in clock "Double click should open calendar with date or the task clicked" [Normal,New]  
<seb128> comment say
<seb128> "evolution calendar:///?startdate=FOO
<seb128> where FOO is an ISO 8601-compliant UTC time string, it is parsed using
<seb128> strftime (ret, 17, "%Y%m%dT%M%SZ", gmtime (&t));
<seb128> For a proof-of-concept, use the shell command
<seb128> date +"%Y%m%dT%M%SZ""
<seb128> I've that on my list to try, but ETOOBUSY, etc
<seb128> if you want to give it a try you are welcome
<sivang> pitti: what are the possible ret codes from pmount/pumount? success / failure == 0 / 1 ?
<sivang> pitti: (man page doesn't talk about it)
<Mithrandir> seb128: thanks.  I didn't get it to work, but I'll investigate.
<seb128> Mithrandir: http://mail.gnome.org/archives/evolution-patches/2005-July/msg00154.html too
<pitti> sivang: I /msg you
<Mithrandir> seb128: already seen that, but thanks
<Mithrandir> you know you're running development stuff when apt-get clean frees up 1.2GB.
<sivang> pitti: thank you :)
<stewski> can totem in dapper play css DVDs?
<tseng> it can with xine and libdvdcss2
<tseng> but not OOTB
<stewski> darn
<_ion> Is anyone working on a network-manager 0.6.1 package for dapper?
<mdke> i think totem gstreamer plays dvds with libdvdcss2
<stewski> so the gstreamer library cannot play
<stewski> thats what Id thought mdke
<mdke> not 100% sure though
<stewski> but its not working
<mdke> stewski, best try #ubuntu
<tseng> the dvd plugin wasnt ported to 0.10 last i heard
<stewski> ] getting the same answer there, didnt like the answer so I came here :-)
<mdke> tseng, oh geez
<mjg59> The dvd plugin is ported, but not fully functional
<stewski> this is a really common requirement great shame if totem wont be able to even support with plugin DVD playback
<mdke> mjg59, will it work for dapper you think?
<mjg59> mdke: I have no idea
<mjg59> seb has been watching the situation
<mdke> seb128, any idea? If not, we'd better update our guides
<seb128> dvd playing works but without menu nor subtitle
<seb128> and anyway that's not something we can ship on CD (mpeg decoder, dvdcss, etc)
<mdke> seb128, sure. I'd make a note of the -menu -subtitle thing in the docs
<xhaker> dvd state: vcd works.. reading .vob work.. .ifo handling doesn't work.. menus doesn't work.. trackbar is buggy
<stewski> seb I appreciate dvd playback cant work out of the box
<mdke> xhaker, thanks. So recommending another library is probably a good idea :)
<stewski> but totem/gstreamer being able to play DVDs would make it easier long run
<xhaker> mdke: gstreamer is under the gnome exception?
<stewski> I read good things about new Gstreamer
<mdke> stewski, there is nothing we can do if it doesn't work from upstream, except make a note of it
<mdke> xhaker, you have to ask seb, I dunno
<stewski> NP mdke I realise (and not trying to detract on some really excelent work for dapper)
<seb128> stewski: it'll for sure, it's just not ready yet
<seb128> stewski: code for menu and subtitle is to CVS now, it just lacks the glue to been used by totem
<stewski> smart
<stewski> excellent hope the extra time lets this get in
<seb128> the issue is that fluendo guys can't work on that
<mdke> seb128, ah so it may be in for dapper?
<seb128> so they have to wait on contributors fo rit
<seb128> for it
<seb128> mdke: might
<mdke> seb128, when will we know? the docs will get frozen soon
<seb128> assume it'll not work
<mdke> seb128, ok. thanks
<Riddell> what is mvo's dist upgrade tool called?
<stewski> anyone able to get multichannel sound playback?
<xhaker> Riddell: i believe it's exactly dist-upgrade
<Riddell> xhaker: no such thing in the archives
<sladen> what's the best way to tag a bug as a regression?
<Burgwork> sladen, raise the severity?
<sladen> Burgwork: I sometimes stick [regression]  in the bug title; there must be a better way
<Burgwork> does malone have bugzilla style keywords?
<sladen> I thought I saw a 'tag' option somewhere, but I can't find it now that looked;
<sladen> there is a 'name' option
<bddebian> OK, I got install to work, now I get the following error on boot:
<bddebian> ALERT! /dev/ida/c0d0p2 does not exist, dropping to a shell?
<sladen> bddebian: so now that you have a shell, what does  ls -l /dev/ida  show you?
<bddebian> nada
<bddebian> No ida dir at all
<bddebian> Keybuk: ping?
<Mithrandir> seb128: it works if I just specify the date, not the time.  It appears time_from_isodate in libecal is broken.
<Mithrandir> seb128: I'm filing a bug now.
<seb128> ok, thank you
<Mithrandir> seb128: is it useful for you to get a patch for the clock applet or is it too trivial for it to save you time?
<seb128> patch are always welcome :)
<seb128> so I don't forget about it and I'm not tempted to be lazy 
<Mithrandir> ok. :-)
<Mithrandir> it's one of my pet bugs that's been around for a while, so.
<Mithrandir> it should also support using Dates instead of Evolution, but that can probably wait for another day.
<seb128> right
<Mithrandir> hmm, actually, it looks like evo needs a fix to not open another shell if it's just one URI given on the command line.
<Keybuk> bddebian: 'sup?
<bddebian> Keybuk: Possible udev problem?
<bddebian>  ALERT! /dev/ida/c0d0p2 does not exist, dropping to a shell?
<Keybuk> none that I'm aware of
<Keybuk> ida?
<Keybuk> what's that?
<bddebian> I don't know
<dianewong> hello
<Keybuk> what's your kernel command-line?
<Mithrandir> i2o
<seb128> $ sudo grub-install /dev/hda
<seb128> /dev/sda1 does not have any corresponding BIOS drive
<dianewong> is there any security feature that the ubuntu livecd provides during autologin?
<seb128> grumpf
<bddebian> Give me a sec but I know root is:  root=/dev/ida/c0d0p2
<seb128> does anybody knows how to fix that?
<Mithrandir> or maybe not.  That's /dev/i2o, iirc
<Mithrandir> seb128: rm /boot/grub/device.map so it'll reprobe
<Keybuk> bddebian: never heard of it
<zul> there is a grub patch that handles i2o
<pitti> dianewong: not sure what you mean
<Mithrandir> zul: ida's not i2o, I jumped the gun
<dianewong> imagine im on the ubuntu livecd
<Mithrandir> dianewong: what kind of security features?
<seb128> Mithrandir: that was easy, thank you :)
<dianewong> it autologs to the user "ubuntu"
<zul> Mithrandir: ah ok
<seb128> brb
<dianewong> does it prevent anyone from internet to drop an eggdrop while im runnin on the livecd ?
<Mithrandir> dianewong: it doesn't run ssh and ssh won't allow users with a blank password to log in.
<dianewong> is the passwd locked ?
<Mithrandir> so unless you install ssh and change the ssh config or install ssh and set a too simple password, there's no way to get into your session
<dianewong> Mithrandir how does it do that?
<dianewong> can i see the codes that prevents this?
<tseng> its just like he said, ssh denies users with no password
<tseng> and also like he said.. ssh doesnt even run to start with
<tseng> if you run netstat --listen --tcp
<Mithrandir> dianewong: : tfheen@vawad ~ > grep PermitEmpty /etc/ssh/sshd_config
<Mithrandir> PermitEmptyPasswords no
<bddebian> Keybuk: "kernel /boot/vmlinuz-2.6.15-18-i386 root=/dev/ida/c0p0p2 ro noapic nolapic quiet splash"
<tseng> you will see that the only listening services are bound to the loopback address
<Keybuk> bddebian: did it work with -17 then?
<Mithrandir> dianewong: also, there's no ssh daemon listening unless you explicitly install one
<bddebian> In looking in /proc/modules, I don't think the Compaq SmartArrary 431 is getting picked up
<bddebian> Keybuk: This is a new install
<Keybuk> bddebian: is that driver in the initramfs?
<bddebian> Hmm, I don't know, sorry.  How do I look?
<Keybuk> modprobe? :)
<bddebian> I don't know which driver it uses? :-(
<Keybuk> CPQARRAY ?
<dianewong> thanks
<bddebian> Probably should be, I'll try it
<dianewong> another question though
<Keybuk> try it, see if /dev/ida turns up
<dianewong> tohow it was ensured that the screensaver never asks for a password
<ogra> it isnt yet ...
<ogra> you can currently use "lock screen" 
<bddebian> Keybuk: module cpqarray not found :(
<Keybuk> iz initramfs bug
<Keybuk> blame infinity
<dianewong> ogra: what to you mean ?
<dianewong> ogra: what do you mean ?
<marcin`> hello guys - I got strange question and I'm sure that you will send me to #ubuntu
<ogra> dianewong, it isnt "insured yet" i have a bug open about that behavior 
<marcin`> but I'm also almost sure that anyone on #ubuntu will know solution so please let me try
<ogra> s/yet"/"yet/
* bddebian blames infinity
<bddebian> OK, so can I fix it?
* zul blames canada
<bddebian> zul: :-)
<marcin`> my problem is - I use Terminus font on Gnome but I also use Ratpoison as WindowManager
<dianewong> ogra: can i view that bug ?
<ogra> bddebian, /etc/mkinitramfs/modules
<ogra> try to add it there
<bddebian> ogra: OK, thx
<marcin`> and if I set my font as default for gtk apps in .gtrc then it work on Ratpoison - but not in Mozilla Firefox
<ogra> and rebuild the initramfs indeed 
<marcin`> could some developer tell me what could be reason of this behaviour?
<dianewong> ogra: can i view that bug ?
<ogra> dianewong, yes, sorry, took a second
<ogra> bug 30118
<Ubugtu> malone bug 30118 in gnome-screensaver "LiveCD: default user password, lock screen problem" [Normal,Unconfirmed]  http://launchpad.net/bugs/30118
<bddebian> ogra: I don't have that dir, or do I need to boot install CD and mount it ?
<ogra> oh, yes, chroot into the system indeed 
<bddebian> Hmm
<ogra> (rescue mode might do it)
<bddebian> OK I'll try.  How do I rebuild initramfs?
<Keybuk> update-initramfs -u
<bddebian> thanks
<dianewong> thanks ogra 
<mjg59> sladen: No, the copying ought to be there
<mjg59> Also, I'm not sure about the panel stuff. Surely that's Intel-specific? Do we have any idea what that would do on other hardware?
<ogra> Mithrandir, would it be possible to add widescreen resolutions to the liveCD bootmenu ?
<Mithrandir> ogra: you realise they're not used by X?
<Mithrandir> it's just for console
<ogra> sadly, yes ...
<mjg59> ogra: No
<mjg59> ogra: They're VESA modes
<seb128> Mithrandir: still around?
<Mithrandir> seb128: yes
<mjg59> ogra: Widescreen ones aren't standardised, to the best of my knowledge
<ogra> mjg59, like video=vesafb:mtrr1280x800-16@72  ?
<seb128> Mithrandir: you craked on xkb stuff right? did you look on xkeyboard-config 0.6 to 0.8 update? I've just built it and tried, it fixed the gnome-settings-daemon when using multiple layouts or compose option by example and add a good bunch of new layouts that could be useful for the l10n goal
<mjg59> ogra: No...
<seb128> Mithrandir: if you didn't I'll ask an UVF for it I think
<ogra> ah, k
<mjg59> ogra: VESAfb can't change mode. That's done by the bootloader or the kernel startup code (I can't remember which)
<Mithrandir> seb128: I haven't looked at it at all, no.  I'm probably going to rush through it tomorrow while waving my amazing Korean keyboard.
<ogra> ah, k 
<Mithrandir> seb128: could we take a look at it tomorrow?
<Tonio_> Kamion: ping ?
<Mithrandir> seb128: given that I'm on my way to bed now.
<Tonio_> hi everyone
<seb128> Mithrandir: sure, I can ask the UVF exception if you want, it was just to not dup work
<Mithrandir> seb128: sure, take the lock on xkb-c and run with it.
<seb128> lol
<Mithrandir> seb128: also, if you could take a look at the evo patch I just posted (#35118) we're a bit closer to the "make the clock applet's integration with evo be way better"
<seb128> I'm happy to give the lock if you want it :) I just want the new version for dapper since it fixes the g-s-d crasher which is one of the frequent GNOME users complain we have
<seb128> will do, thank you
<Mithrandir> seb128: either way works for me.
<Mithrandir> seb128: I'll review it tomorrow and ask for UVF, then.
<seb128> ok, thank you
<Mithrandir> see you around.
<bddebian> ogra or Keybuk: OK, I added cpqarray to /tmpmnt/mkinitramfs/modules  but I can't find update-initramfs ?
<seb128> Mithrandir: 'night
<bddebian> Err /tmpmnt/etc/mkinitramfs/modules even :-)
<ogra> hmm ...
<ogra> do you have a separate /usr ?
<ogra> /usr/sbin/update-initramfs
<bddebian> Well / is the ramdisk, should it be there?
<bddebian> I don't see it in /tmpmnt/usr/sbin/
<ogra> hmm, its in initramfs-tools usually ...
<ogra> which should be installed ...
<sladen> mjg59: 915resolution is intel-specific, and that's the only use-case.  The function it uses is defined by VESA as part of their Liquid-Flat-Panel extensions
<mjg59> sladen: But you'e given me a patch for vbetool
<mjg59> So, uhm.
<mjg59> Or do you mean you want to call vbetool from 915resolution?
<sladen> mjg59: yes, see http://www.paul.sladen.org/ubuntu/upload/915resolution_0.5-1ubuntu2panelid2.debdiff
<sladen> mjg59: auto-detect magic for 915resolution
<mjg59> sladen: Also, the HP stuff is still wrong. 
<mjg59> You're just resetting what's already there
<mjg59> So my suspicion is that the Compaq ones there are also fine
<bddebian> ogra: OK, I lied, I found it in /tmpmnt/usr/sbin
<pitti> Riddell: amarok and gwenview translations have arrived
<bddebian> But it didn't seem to work.  Can I specify /tmpmnt/boot/initrd.img with update-initramfs?
<pitti> Riddell: I'll just have some troubles with gwenview, it has yet another different format for storing translations, so this needs manual special-casing in langpack-o-matic
<bddebian> I.E. something like /tmpmnt/usr/sbin/update-initramfs -u /tmpmnt/boot/initrd.img ?
<ogra> chroot /tmpmnt update-initramfs -u 
<bddebian> Oh duh.. :-)
<bddebian> Well it'll have to wait until tomorrow or I'm getting an ass-whiping from the wife.
<bddebian> THanks ogra and Keybuk.
<sladen> mjg59: which particular part of the HP stuff?  dmi strings, mappings, ..?
<mjg59> sladen: The mappings
<sladen> mjg59: I can run a awk over and comment out any that are setting $value to $value
<mjg59> sladen: Ok
<mjg59> +setkeycodese05f$KEY_SLEEP# Fn+F3Sleep(matches compaq.hk)
<mjg59> That's a noop
* Keybuk boggles at the "1280x1024 is an abomination" people
<_ion> Well, it's perfectly fine if you have a 5:4 monitor.
<Keybuk> which most people do
<_ion> Most people have a 4:3 monitor.
<Keybuk> certainly nearly everyone who'd have that as a recommend resolution has a 5:4 monitor
<Keybuk> no
<Keybuk> TFTs are nearly always 5:4
* Keybuk hands _ion a ruler
<_ion> Maybe TFTs are more popular in your country than.
<Keybuk> most CRTs are 5:4 too
* _ion hands keybuk a ruler. :-)
<HrdwrBoB> most people I know have TFTs
<Keybuk> the really old ones probably aren't, but those can't do 1280x1024 either :)
<Keybuk> I've never seen a 4:3 19" CRT, or TFT
<sladen> mjg59: e05f is 223, the code kernel code is 142
<mjg59> sladen: There is not a linear mapping between these two things
<Keybuk> (that's not to say they don't exist, of course)
<HrdwrBoB>   dimensions:    1600x1200 pixels (402x302 millimeters)
<mjg59> Keybuk: See drivers/input/keyboard/atkbd.c
<mjg59> Uh.
<mjg59> sladen: ^
<mjg59> (sorry)
<mjg59> sladen: atkbd_set2_keycode[223] =142
<Keybuk> HrdwrBoB: what's the pixel pitch of that?  does it have non-square pixels?
<Keybuk> (which a lot of CRTs have)
<mjg59> Keybuk: CRTs don't have pixels...
<sladen> mjg59: okay, based on that I have to grep drivers/input/keyboard/atkbd.c instead...  oooh the indirection turns me on
<Keybuk> mjg59: uh, right
<Keybuk> is "dot pitch" the right term?
<Keybuk> something like that
<HrdwrBoB> yes
<Keybuk> hardware is not my best field :p
<HrdwrBoB> I can't remember the numbers, but it's enough
<HrdwrBoB> 21" trinitron CRT
<HrdwrBoB> 0.24mm Aperture grille pitch
<mjg59> Keybuk: The phosphor dots may be non-square, but it's desirable to use square pixels most of the time
<mjg59> 1280x1024 is strange in that respect
<Keybuk> I do know that 1280x1024 is almost always suggested for TFTs, which are 5:4
<mjg59> Since it's the only "standard" mode that gives non-square pixels on 4:3 CRTs
<mjg59> What shape the TFT is is unimportant. Using anything other than the native resolution is insane.
<Keybuk> CRTs tend to suggest 1152x864 or 1600x1200 instead
<HrdwrBoB> exactly
<mjg59> There was a phase of 1280x1024
<mjg59> It was popular for a long time before TFTs were
<Keybuk> would have thought a CRT would suggest 1280x960 instead
<mjg59> Nope
<mjg59> No idea why
<HrdwrBoB> yes, most 19" monitors suggest 1280x1024
<Keybuk> kooky
<Keybuk> still doesn't make it an abomination, given it's not only the native resolution of most 19" TFTs but also the only correct aspect one :)
<HrdwrBoB> it's also the native resolution of most 17" TFTs
<HrdwrBoB> which means 19" TFTs annoying and pointless imho
<Keybuk> I find the 17" too "high res"
<HrdwrBoB> there is no such thing
<Surak> hello
* Lathiat has 19s, i have 1680x1050 on my 15.4" widescreen tho and thats too high res for me, it looks nice tho :)
<Keybuk> you get less screen space on a 17" with the same (ruler) size fonts as on a 19" monitor
<Surak> which is the person I need to talk to to have ubugtu in #ubuntu-br?
<Keybuk> pixel size, the fonts on a 17" are smaller than on a 19"
<Keybuk> for those of us with wonky eyesight, that's a bad thing <g>
<ogra> Surak, Seveas 
<Surak> ogra: thanks
<Keybuk> whatever your dad told you, size *is* important ;)
<HrdwrBoB> yeah, the 19" is bigger, but I'd rather go up to the 20" where suddenly you get 1600x1200 or whatever
<Keybuk> see, that's my reason for *not* going to the 20" - because then everything would get too small for me to see
<HrdwrBoB> couldn't you just increase the font size?
<Keybuk> font size doesn't increase the width of things like the cursor bar
<Keybuk> or the width of scrollbars, etc.
<HrdwrBoB> this is why everything should be scalable and zoomable.. the dot pitch of your display should be independant of the size of the interface
<Keybuk> sadly most of those things are still fixed size in pixels, which is silly
<HrdwrBoB> that said, I do a lot of work on my X40 which has small pixels and size 8 fonts
#ubuntu-devel 2006-03-21
<Keybuk> I've always wondered why monitors aren't square
<Keybuk> I suspect it originally had something to do with difficulty of electron tubes or something
<HrdwrBoB> peoples vision isn't square
<HrdwrBoB> you have more vision sideways
<Keybuk> hmm, true
<HrdwrBoB> hence widescreen
<Keybuk> that's the theoretical justification for widescreen, isn't it?
<HrdwrBoB> the eye is a terribly ineffecient thing, we have a tiny tiny focus point
<xhaker> HrdwrBoB: i don't think they did it 4:3 first because of that
<LaserJock> hmm, but I like more vertical space so I don't have to scroll as much. I must be brainwashed
<HrdwrBoB> xhaker: no, probably not, it would just have been the easiest way to do it
<HrdwrBoB> LaserJock: yes but you have to focus down the page
<xhaker> LaserJock: do you read much?
<HrdwrBoB> that's a convenience issue, you can't see the whole thing at once
<sladen> Keybuk: principly to do with humans living in the horizontal plane (eg. we don't fly and we don't swim---so food and predators are on the same level)
<Keybuk> don't swim ... clearly you haven't read "The Aquatic Ape" :)
<LaserJock> I recently got a 17" widescreen and I'm having a hard time adjusting to the width. I think I liked the ratio of a CRT better.
<HrdwrBoB> Pixel Pitch 
<HrdwrBoB> 0.264 mm  on my 17" LCD
<Keybuk> LaserJock: see, that's just tempting a reply along the lines of "width is harder to become accustomed to than length ... or so I'm told" :)
* Keybuk hauls his mind out of the gutter
<Keybuk> oh, wait, I was looking at Network Manager ... back into the gutter with me!
<LaserJock> yikes
<Keybuk> damn
<Keybuk> I can't screenshot the logout dialog
<LaserJock> is it bigger than a screen now ;-)
<Keybuk> no, it's missing all of its icons
<Keybuk> which actually looks a vast improvement, tbh
* Keybuk doesn't agree with all this bling
<Tm_T> hmm, what's the purpose of that BT tracker in dapper?
<seb128> Keybuk: did you restart the session since you upgraded?
<seb128> Keybuk: the icons moved to an another place, so code still running doesn't find them ...
<seb128> Keybuk: that's just a dapper to dapper upgrade issue, I'm not sure I want to spend efforts on workarounding it :p
<Keybuk> seb128: I was logging out to restart the session after an upgrade :)
<Keybuk> seb128: btw, GNOME still steadfastly refuses to logout on both my machines
<Keybuk> it eventually gets the idea after sitting there for about a minute
<seb128> Keybuk: usually that's either a bugged app doing session registration wrongly
<Keybuk> seb128: I'm not running anything strange that I'm aware of
<seb128> or lo beeing misconfigured
<Keybuk> tomboy is about the only "alien" thing in my session
<seb128> I've the issue quite often too atm
<seb128> I'll have a look when everything else is settled a bit
<Keybuk> we have time now :)
<seb128> did the decision to shift dapper has been taken?
<Keybuk> yes
<seb128> ah, cool
<seb128> desktop bugs backlog is not nice atm
<Keybuk> https://wiki.ubuntu.com/DapperReleaseSchedule/Slewed
<seb128> I've around 400 mails in my box and I keep usually 1 mail by bug 
<seb128> and I was at ~ 10 mails before going to UI sprint
<LaserJock> Keybuk: when was the decision made?
<seb128> that mean we got new bugs or comments for around  300 or 400 bugs in 10 days
<seb128> which is ... utch
<xhaker> LaserJock: today @ maybe 19:00 UTC
<xhaker> now i get the impression it was earlier
<LaserJock> xhaker: thanks
<Keybuk> LaserJock: earlier at a special meeting of the TB+CC
<LaserJock> Keybuk: hmmm, I think the doc team wanted to make an adjustment to the Slewed schedule. Should they talk to the TB ASAP?
<jdub> seb128: utch is good!
<Keybuk> what was the adjustment you wanted?
<seb128> jdub: urg so
<LaserJock> Keybuk: well, I don't know if it was perfectly decided, but we didn't think the DocStringFreeze should be pushed so much
<seb128> jdub: :)
<Keybuk> LaserJock: it isn't pushed?  there's an extra week between that freeze and the final release compared to the original schedule
<Keybuk> the confusion there is probably that there's more time between Beta and Final on the new schedule than the old
<LaserJock> Keybuk: we were discussing having the DocStringFreeze on April 6th
<Keybuk> LaserJock: that'd put the doc freeze before the UI and Strings were frozen though
<Keybuk> which seems silly
<LaserJock> Keybuk: yeah, I'm noticing that :(
<Keybuk> why such a long freeze?
<Keybuk> it seems odd to freeze dapper's docs two months before it's released
<LaserJock> Keybuk: to allow time for translation
<Keybuk> why would dapper's docs take longer to translate than breezy's?
<LaserJock> Keybuk: I'm not sure but I would guess because there are more docs and perhaps more translations? I'm really not sure
<LaserJock> Keybuk: mdke is the one to talk to but we have been discussing it on ubuntu-doc
<Keybuk> that doesn't seem likely to me
<Keybuk> we certainly haven't given you less time than you had
<Keybuk> and freezing docs before the underlying system is frozen just seems wrong
<Keybuk> you may end up documenting things that change
<LaserJock> Keybuk: sure, but I think we where under the impression that the UI freeze would not be pushed
<Keybuk> UI freeze has been thawed
<Keybuk> because of the Localisation effort
<Keybuk> with the emphasis on other languages being added to dapper, it may be necessary for UI elements to change
<LaserJock> Keybuk: ok, well I'll email the doc team list and we can discuss it some more. We planned on sending an email to the TB once we figured out home much time we needed, etc.
<Keybuk> right
<Keybuk> it does seem odd that you'd need longer to me
<Keybuk> as that wouldn't explain why you wouldn't also need longer for dapper+1
<Keybuk> if you had a two month doc freeze, you'd have to freeze dapper+1's docs at only 4 weeks *into* the release
<LaserJock> Keybuk: I think it might have been more like "we can pretty much be done with the docs by the present Freeze so why not give more time to translations"
<Keybuk> also the later freeze doesn't actually stop you as a team freezing documents and preparing them for translation ahead of the freeze
<Keybuk> though it does mean you'd have to play catch up with the UI
<Keybuk> LaserJock: that was Corey's argument at the meeting
<Keybuk> which doesn't play well with "but what if what you've documented changed" ?
<LaserJock> exactly
<Keybuk> and as I said, if a doc is finished, it can be translated in advance of the freeze
<LaserJock> yeah, for sure
<Keybuk> I'm ambivolent on the issue; the UI and String freezes were given extra time due to the localisation work ... so there could still be a balance there to be struck
<LaserJock> I see what you're saying. I think we just thought the UI Freeze wasn't going to be moved.
<LaserJock> so we just need to take that into account
<Keybuk> the Orange finally proves that dapper is a Duck, I guess
<Keybuk> you don't get Dragon a l'Orange, after all
<LaserJock> lol
<Seveas> Keybuk, the orange represents the dragon's flame
<Keybuk> http://www.carpages.co.uk/ford/ford-focus-st-15-02-05.asp
<Keybuk> it reminds me a lot of that
<Seveas> lol
<Keybuk> all bling, and aimed straight at the chav/ricer market :p
<Keybuk> we should have a Burberry Metacity theme to go with it
* jdub keeps working on his green theme
<Keybuk> as you can guess, I am not a fan of new Human
<Seveas> Keybuk, http://files.datawire.nl/uploads/o8901cyyFFFsz0gM9JcMRQ/5hOQkl6N7fsuzf1c9-GQdA/727-Oranje_supporters_klaar_voor_Duitsland.jpg
<jdub> Keybuk: 'Numan'
<Keybuk> the only human it reminds me of are those who smother themselves in Fake Tan
<jdub> Keybuk: the good thing about 'Numan' is that every time you see someone running it, you can say it the same way Seinfeld does whenever Numan shows up.
<Keybuk> what's that?
<jdub> i'm sure there are samples on the interweb
<Keybuk> plus I hate the new icons
<LaserJock> jdub: lol, that's good
<Keybuk> Holy Segfaulting X-Chat!
<Keybuk> jdub: why do the Evolution header list column titles suck in Human?
<Keybuk> sorry, Numan
<sladen> Keybuk: the intensity?
<jdub> Keybuk: dunno.
<Seveas> sladen, the insanity ;)
<jdub> (i actually haven't run evo with it)
<Keybuk> sladen: they look like a row of buttons, instead of a column title
<Keybuk> ie. rounded corners and gradients
<Keybuk> not to mention borders, instead of inter-column space
<sladen> Keybuk: and the text jumps around in such a cool way
<sladen> Keybuk: it's almost as though it were intentional :)
<Keybuk> the scrollbar edges are *damned* confusing
<Keybuk> it makes it look like there's a little bit of movement available
<Keybuk> (when you're viewing 100% of the whole document)
<sladen> there's a lack of constract betwen what's clickable and what's not.  and the ends should be same colour as the middle section, rather than the outer section
<sladen> an improvement might be to have the whole 'bar' section highlight orange on hover and remove the 5px high end pieces
<infinity> sladen: Did you take an executive decision on the reverse-video slash-down thing?
<infinity> sladen: (FWIW, I still think it's both ugly and unintuitive, but whatever)
<Burgwork> I don't think we need a progress bar or need to show what is happening, but that is just me
<infinity> Burgwork: Well, in an ideal world, shutdown would take no more than a couple of seconds (a goal for dapper+1, to be sure), then I'd agree, progress is pointless.
<infinity> Burgwork: When shutdown can take 30-60 seconds on some machines right now, though, we need to at least give a hint of activity.
<infinity> (There's no reason why a desktop machine shouldn't be able to go from logout to off in 2 or 3 seconds, however.  After the sessions is saved, nothing else should care about state on a desktop box..)
<Amaranth> on my mini shutdown is faster than OS X :)
<infinity> Does OSX suffer from the same traditionally anal UNIX view that "if you started it, you must stop it gracefully before we can proceed with a halt"?
<Amaranth> i guess
<infinity> Cause, while that's pretty true of certain daemons that will muck up log files if they're violently killed, 99% of what the average desktop machine has running should be able to get the plug pulled.
<Amaranth> sometimes it powers off in 10 seconds, sometimes it takes 30
<infinity> Which will be a goal for dapper+1 (which also means the removal of splash-down again, so it was just a temportary hack for one release)
<infinity> temporary, too.
<jdub> infinity: i hope we can remove the log lines from usplash in dapper+1 :-)
<mjg59> Hmm
<mjg59> Implementing a UGA framebuffer looks like it might actually be quite easy
<mjg59> EFI seems to magically have C calling convention
<Amaranth> jdub: get rid of the progress bar too :)
<mjg59> You just end up with a bunch of function pointers into firmware
<mjg59> Which is kind of magic
<Amaranth> neat
<infinity> Amaranth: The progress bar can't go away until the boot time is REALLY, REALLY short, IMO.
<mjg59> And the most basic support is just "Blit this block of memory onto the screen"
<jdub> some status is warranted
<infinity> jdub: I'm all for a default "non-verbose" mode (with an option for verbosity for people who like it)
<Amaranth> infinity: but the progress bar kind of..jumps
<KaiL> anybody in here, who understandy enough about cpufreq, to explain, why it worked in breezy, but doesn't any more in dapper (kernel related problem)?
<infinity> jdub: It's not exactly rocket science for us to do that right now.
<jdub> but if the status could be displayed by a colour-changing spinner or something, that'd be fine
<Amaranth> infinity: something like a throbber would be more appropriate, i think
<jdub> infinity: yes, that's what i've been pushing for since we did usplash
<Amaranth> spinner, there you go
<infinity> I don't see how a spinner/throbber is much improvement over a progress bar that's not quite perfect.
<infinity> At least the progress bar give you SOME indication of how long you have to wait.
<jdub> osx has a spinner, winxp has a non-progress progress bar, but we can actually display real progress, so doing so would be useful
<sladen> infinity: no, _the executive_, made an executive request
<infinity> A throbber just says "I'm doing stuff, you may have enough time to go get coffee, I may be done in 5 seconds, you may have time for a nap, NOBODY KNOWS"
<Amaranth> but some things take 10 seconds, some take 1
<Amaranth> and you don't really know if it froze or not
<infinity> It's an approximation of progress.
<mjg59> jdub: Mm? osx has a spinner and a progress bar
<mjg59> The progress bar appears once the graphics driver is up
<infinity> And, unless your system is completely hardlocked, there's a fair chance that even on a "freeze", your spinner/throbber would keep spinning/throbbing, so that's no help.
<jdub> mjg59: yeah
<Amaranth> last time i paid attention the bar only moves once something finishes
<infinity> (I have a Windows installation that just blindly keeps "progressing" forever, but never actually boots.
<mjg59> Having both seems mad
<mjg59> Having actually used osx now, I'm not terribly keen on it
<mjg59> It's shiny, but I've made it fall over several times
<Amaranth> mjg59: the finder is a wreck
<mjg59> I guess it's the case that people subconsciously realise that certain things will explode and avoid doing them, and then claim that other OSs (where they don't have that) are worse
<infinity> sladen: Fair enough.  Last I heard from him, we were still debating it a bit.  Then you sent me patches with no context (which I was going to follow up on later), but whatever. :)
<Amaranth> mjg59: and the dock is worthless
<Amaranth> mjg59: apple-tab and quicksilver make it usable
<infinity> sladen: When it hits the archive, I'll let the comunity argue about it.  I don't actually care that deeply.
<Amaranth> mjg59: but i've never had OS X kernel panic or anything, except when i ran the ext2fsx driver on tiger
<infinity> I don't panic on Dapper either.
<sladen> infinity: I agree thoughly, my take was that it didn't actually look any worse, so... :)
<infinity> But I do suffer occasional video lockups.  Our video situation is pretty sad.
<Amaranth> i did once, when i tried running with the bcm43xx driver from svn
<infinity> If only we shipped video from exactly two vendors, who were both friendly with us, and employed a mess of hackers to make those two vendors' cards work flawlessly.  Hrm.
<Lathiat> hehe
<infinity> I'm starting to sense that the solution to any of our stability problems is to sell an "Ubuntu Computer", and tell people that you CAN run Ubuntu on other machines, but we won't support it.
<infinity> Oh, and we should charge twice as much for that "Ubuntu Computer" as you'd pay for putting together similar parts yourself.
<bddebian> infinity: I think my initramfs might be jacked, do you want a copy?
<infinity> bddebian: Only if it's not jacked due to -ENOSPACE on /tmp or /boot (in which case, the bug is filed in triplicate, and I need to fix it)
<infinity> bddebian: Anything else, and yeah, I'd love a copy.
<bddebian> infinity: No, it's missing cpqarray
<infinity> bddebian: And a description of the jackitude.
<bddebian> OK, I'll snag a copy when I get back to work tomorrow
<infinity> Erm, how are you adding cpqarray?
<bddebian> How am I "adding" it?
<infinity> (It's not in the default list right now)
<bddebian> Oh, then maybe it isn't broken?
<infinity> Right, if you're not adding it, and I'm not adding it either, we know the breakage.  I don't need a copy. :)
<infinity> I'll add it to the default list.
<bddebian> Install picked it up
<infinity> If you want to stick it in the "scsi" section in /usr/share/initramfs-tools/hook-functions and re-gen your initrd... Tell me if that unjacks it. :)
<infinity> Installer and initramfs do things in entirely different ways.
<bddebian> infinity: Well I was going to stick in in /etc/mkinitramfs/modules and update-initramfs -u   Is that not correct?
<infinity> That would do fine for a test, yes.
<infinity> It'll end up in the other file if your test is successful, though (in my next upload)
<bddebian> OK, thx
<Burgwork> has it become 6-06 or is it 6.06?
<infinity> I'm hoping for 6.06, since 6-06 makes it more difficult to represent in debian package versions in a policy-compliant way. :)
<Keybuk> when have we ever put it in package versions?
<infinity> We've done it in security a few times. :)
<infinity> And ubuntu-docs appears to use a version that relates to the release version.
<LaserJock> umm, this is sort of a stupid question. Is there an easy way to tell the difference between Flight 4 & 5 livecd's?
<Keybuk> LaserJock: what kind of difference do you mean?
* mjg59 does another Mac install
<LaserJock> Keybuk: I download a livecd but I can't remember if it was Flight 4 or 5 :(
<infinity> LaserJock: md5sum.
<LaserJock> mjg59: intel?
<mjg59> LaserJock: Yeah
<LaserJock> infinity: ah, yes. should have thought of that
<LaserJock> mjg59: great!
<sladen> mjg59: have you got a macmini and macbookpro yet?
<sladen> mjg59: you seem like you're about ready to progress to the next level
<mjg59> sladen: I'e got a mini
<mjg59> No macbook
<LaserJock> hmm, I suppose it doesn't bode well if the md5sum doesn't match either Flight4 or Flight5
<mjg59> I'm just working on making the framebuffer sane, so we can avoid this passing of kernel arguments pain
<infinity> LaserJock: rsync it to flight5, then...
<LaserJock> infinity: you can rsync the iso's?
<infinity> Of course.
<LaserJock> mjg59: if you get to the point where  you need an iMac tester, I'm available ;-)
<mjg59> LaserJock: Not quite - I've found the binutils issue that stops us building a bootloader, but once that's fixed we should have test images
<infinity> LaserJock: rsync -v --progress --partial rsync://cdimage.ubuntu.com/cdimage/releases/dapper/flight-5/dapper-live-i386.iso ./my-old-iso.iso
<infinity> LaserJock: Or some approximation thereof.
<LaserJock> infinity: cool, thanks
<sladen> mjg59: out of interest, what was it?  GCC4ism?
<mjg59> sladen: No, scary stuff I don't understand at all
<mjg59> It's fine with gcc 4
<jdub> Kamion: unlikely ping
* Keybuk tries to remember how to include EPS files into a LaTeX-generated PDF
<Keybuk> where's sladen when you need him?
<mjg59> Eh? This machine appears to have no UGA table
<Lathiat> UGA?
<mjg59> EFI's graphics architecture
<Lathiat> ah
<jdub> Lathiat: it's short for AWWWWUGA! (as in the submarine alarm sound)
<jdub> AWWWWUGA! AWWWWUGA! DIVE! DIVE!
<bddebian> hahaha
<mjg59> Uhm.
<mjg59> Can we re-do the UI for the SCIM config applet?
<jdub> haha
<jdub> too late! critical feature!
<mjg59> No, seriously
<mjg59> Why does it not know what my keyboard layout is?
<mjg59> Why does it have three tree heads that are entirely pointless?
<mjg59> Did /anyone/ do UI review on it?
<mjg59> "Embed Preedit String into client window"?
<mjg59> That has so many things wrong with it I'm not sure where to start
<jdub> mjg59: really, this is something that we should integrate / do properly upstream
<Keybuk> jdub: hmm?  UI Freeze is weeks away :)
<Keybuk> plenty of time to fix it
<jdub> where "fix" will involve quite a bit of "rewrite" work
<mjg59> jdub: It's worse than the old Xscreensaver one
<jdub> yeah
<mjg59> It's like those preferences apps that you get with laptops that have plainly been written by some technical guy who didn't run away fast enough
<mjg59> And has a default MFC icon
<jdub> heh
<mjg59> Looking at it, it looks almost as if it autogenerates chunks of the UI (since there are several plugins)
<minghua> mjg59: the but about scim's UI is bug #3635
<Ubugtu> malone bug 3635 in scim "scim-setup isn't HIG compliant" [Minor,Confirmed]  http://launchpad.net/bugs/3635
<minghua> mjg59: I am sure upstream would love a patch/rewrite ;-)
<mjg59> Ha
<mjg59> Yes
<minghua> it has always been like this, it is just much more exposed to public scrutiny recently due to inclusion by ubuntu-desktop
<infinity> minghua: Do you know anything about scim-chewing?
<infinity> minghua: The build (sometimes) gets in an infinitely loop, and it sure would be nice to fix that. :)
<infinity> minghua: http://librarian.launchpad.net/1744038/buildlog_ubuntu-dapper-hppa.scim-chewing_0.2.1-2ubuntu2_FAILEDTOBUILD.txt.gz
<minghua> infinity: yes, a bit
<minghua> oh not again :-(
<infinity> s/infinitely/infinite/
<minghua> infinity: I'll look at it when I gets home (in an hour)
<_ion> My attempt at making a NetworkManager 0.6 package for Dapper: http://johan.kiviniemi.name/ubuntu/
<minghua> infinity: fortunately I know the debian maintainer and upstream author well :-)
<infinity> minghua: You rock.  If you don't have rights to upload it (do you?) feel free to pass patchs through me, and I'll get them in ASAP to make my poor buildds happy.
<minghua> infinity: I have universe upload right.  but let's see how long it takes to figure out the problem first :-)
<infinity> minghua: I'm sure it's not terribly tough to sort out, I'm just running flat-out over here trying to (re)bootstrap hppa, and juggle a bunch of other stuff.
<bddebian> Excuses, excuses :-)
<minghua> infinity: I'll try :-)
* minghua now leaves for home, be back later
<Kyral> lol @ Jeff's blog post
* minghua is back
<minghua> infinity: there is a ubuntu patch for scim-chewing that I don't understand, it adds:
<minghua> AC_SUBST(LIBTOOL_EXPORT_OPTIONS)
<minghua> to configure.ac
<infinity> I am not an autoconf/libtool guru by any stretch, so don't ask me. :)
<minghua> the relevant changelog is "* Add patch for correct the configure.ac for LIBTOOL _EXPORT_OPTIONS"
<minghua> infinity: okay
<minghua> anyone autotools/libtool guru around?  what is this LIBTOOL_EXPORT_OPTIONS used for?
<infinity> Anyhow, I doubt (though can't really prove) that that's what's causing the infinite loop, since the loop seems more touchy than that.
<minghua> freeflying?  (since this is your patch)
<infinity> (Note that it built find on some buildds, and looped on others..)
<infinity> s/find/fine/
<minghua> infinity: yeah, I am just looking at the ubuntu patchs first
<natroll> i see devel people
<mjg59> Hm. Right. So the Mac wakes up happily through the assembly section. Now I just need to check where it's falling over in the kernel, then.
* bddebian hands mjg59 a bigger hammer
<bddebian> natroll: :)
<minghua> infinity: I think I have an idea now
<minghua> infinity: can you modify the file po/Makefile.in.in, after line 259 (in the Makefile target), add
<minghua> infinity: add "touch POTFILES && touch Makefile", and try again?
<minghua> infinity: I can't upload to main so I need you to upload anyway, and I think the patch is trival
<infinity> minghua: I can't try again on that buildd in any meaningful way right now, but I can try in a little while.
<minghua> infinity: do you want me to file an bug?
<infinity> minghua: No, I can use backscroll. :)
<minghua> good, so consider scim-chewing back in infinity's hands now :-)
* minghua goes to work on scim
<minghua> and scim-m17n "not usabel at all" bug :-(
<infinity> Gah.
<infinity> minghua: Will the madness never stop?  I think po/Makefile.in.in is autogenerated during build... From what, I have no idea. :)
<minghua> infinity: no, po/Makefile.in.in is in source
<minghua> infinity: but the debian/rules clean is apparently broken, so always checkout new source
<minghua> infinity: it seems to me that the problem is po/POTFILES and po/Makefile is generated by the same command (cd .. && ./config.status)
<minghua> infinity: but po/Makefile target depends on po/POTFILE, therefore the timestamp skew
<infinity> minghua: Erm, I was using fresh source.  The Makefile.in.in I have halfway through a build is different from the one in the source package.
<minghua> ouch
<minghua> infinity: ah yes, the debian/rules run bootstrap, so Makefile.in.in may well be changed...
<minghua> but I don't think it will be regenerated over and over (but then again, I can reproduce the build failure)
<minghua> infinity: no, in my build the po/Makefile.in.in isn't touched at all
<infinity> I swear I'm not making this up. :)
<minghua> infinity: there is no mentioning of po/Makefile.in.in in the failed build log either...
<infinity> No, there isn't in my log either.
<minghua> infinity: are you sure you are looking at po/Makefile.in.in instead of po/Makefile.in?
<infinity> It doesn't claim to be regerating it, but it's definitely different than the one I have in the source package on unpack.
<infinity> Oh, feh.
<infinity> dpkg-source: warning: ignoring deletion of file po/Makefile.in.in
<infinity> The clean target removes it.  That's hilarious.
* infinity uses dpatch instead, since it's a dpatch package anyway.
<infinity> So much for quick hack testing.
<minghua> infinity: told you that debian/rules clean is broken...
<infinity> Right, so, back to the original question.  Where is Makefile.in.in coming from? :)
<infinity> If clean removes it (and clea is run at the beginning of every build), it's coming from somewhere else. :)
<minghua> good point
<infinity> Perhaps it's an automake template of some sort, and doesn't "come from" the source package at all.
<infinity> Yup, that seems to be the case.
<minghua> infinity: it comes from the configure
<infinity> That'll make it a bit hard to patch. :)
<minghua> it bootstraps (./autogen.sh)
<infinity> Yeah, it comes direct from intltoolize, I guess.
<minghua> infinity: what about hacking scripts/remove-autotool.sh so that it doesn't remove po/Makefile.in.in? ;-)
<infinity> Yeah, that might be the "best" solution.
* infinity fixes.
<minghua> does "pbuilder build" runs debian/rules clean before building as well?
<infinity> I have no idea.  dpkg-buildpackage does.  Does pbuilder use dpkg-buildpackage?
<minghua> yes, but seems it uses dpkg-buildpackage -b, which IIRC doesn't run clean
<infinity> Yes, it does.
<infinity> Only dpkg-buildpackage -nc doesn't.
<infinity> (-nc == no clean)
<minghua> infinity: yeah, you are right, saw clean in my pbuilder log
<infinity> Oh, hrm.  I can't even use dpatch for that, since the clean will whack the file before dpatch gets to run. :)
* infinity sticks this in the diff.gz directly.
<minghua> hehe
<infinity> I feel so dirty.
* infinity tests this on the buildd that hates him.
* minghua wonders why this bug only happens on this buildd
<minghua> scim-chewing apparently went through buildds of all debian archs fine
<infinity> That may be a red herring.  It may just be happening universally with a new intltool, but hppa was behind, so built with a different version.
<infinity> Or something.
<infinity> I dunno.
<infinity> I'd just rather not have it happen at all. :)
<minghua> new intltool... that makes sense
<infinity> (And the fix probably belongs in intltool, really, if it's a breakage in a generic template...
* infinity looks at that for a second.
<minghua> infinity: yeah, the new generated po/Makefile.in.in is indeed different on the parts related to po/Makefile and po/POTFILES
<minghua> stamp-it: Makefile.in.in ../config.status POTFILES.in
<minghua>         cd .. \
<minghua>           && CONFIG_FILES=$(subdir)/Makefile.in CONFIG_HEADERS= CONFIG_LINKS= \
<minghua>                $(SHELL) ./config.status
<minghua> Oops...  where is the "touch stamp-it"?
<minghua> infinity: could that be the problem?
<infinity> That does seem likely.
<infinity> You may want to file a bug on intltool and see if anyone has a clue how those rules are supposed to work . :)
<infinity> I'm just going to upload this dirty hack for now.
<minghua> infinity: okay, I'll file the intltool bug
* minghua never thought he could find a bug in intltool one day
<minghua> wonderful.  now I can reproduce this infinite loop if I run clean before build
<infinity> Excellent.
<minghua> infinity: that would be bug #35161 if you are interested 
<minghua> ah, our dear bug bot has left
<jdub> infinity: thanks for uploading scim-schawing
* infinity does a pelvic thrust.
<hendry> where are the collection of Ubuntu diffs on debian
<Burgundavia> http://people.ubuntu.com/~scott/patches/
<hendry> Burgundavia: cheers
<Burgundavia> hendry: np
<Burgundavia> hendry: beware, I understand some of the diffs there are a little wierd
<hendry> yes. very big
<hendry> it would be nicer to have some interface
<hendry> it's unreadable to me
<jdub> hi kai
<fabbione> morning
<hendry> jdub: hello
<hendry> what are these Italian Ubuntu deriv's called?
<Burgundavia> Uffico Zero
<hendry> Burgundavia: cheers
<hendry> are Debian maintainers considered Ubuntu maintainers?
<minghua> hendry: I think no.  and strictly speaking ubuntu doesn't have "maintainers", only "developers"
<minghua> hendry: it seems being a DD makes it much more easier to apply for an ubuntu developer though
<hendry> http://www.ubuntu.com/partners/become refers to "maintainers"
<minghua> oh okay, then I don't know
<minghua> there must be people who know better than I :-)
<hendry> is there any kind of ubuntu and debian bts syncing?
<Treenaks> Launchpad follows Debian bugs if you tell it to
<Treenaks> it won't post there thoguh
<Treenaks> afaik
<hendry> i hear a lot about the ubuntu desktop
<hendry> is there any marketing for the "server"?
<Burgundavia> not currently
* Treenaks hands the microphone to jdub, Marketing Guru
<hendry> what's the deal with bugzilla? https://bugzilla.ubuntu.com/show_bug.cgi?id=28846
<natroll> hendry, file a bug on bugzilla
<Burgundavia> bugzilla has been replaced
<hendry> natroll: about?
<natroll> hendry, i was kidding
<hendry> Burgundavia: so it should be taken down at some point?
<Burgundavia> hendry: no, the bugzilla is locked and all the open bugs imported into Malone
<hendry> Burgundavia: ok
<jdub> boh. you may not have got my full answer.
<jdub> :0
<jdub> :)
<jdub> my isp is filled with awesome
<jdub> as is irssi
<hendry> are the ubuntu guys going to Debconf6?
<jdub> some might be - kinda badly timed, given schedule previous and current
<netstar> Why was metacity built without compositor?
<jdub> netstar: because it's not ready for inclusion yet by default - search for spifficity
<Mithrandir> jdub: he might have more luck if he looks for spiftacity.
<netstar> ty
<jdub> Mithrandir: you should tell him, lest he miss it
<doko> amazing ... the sparc buildd did finish openoffice.org before the i386 buildd
<doko> fabbione: ^^^
<fabbione> doko: i know
<fabbione> sparcbuildd > *
<hendry> on the wiki my name is Hendry2. how the hell? who is the other hendry? :)
<fabbione> doko: oosmoketest = good :)
<fabbione> doko: just wait that James will reboot in the new kernel..
<fabbione> doko: that will speed up a bit more too.. readding 512MB of ram to the buildds..
<doko> cool, we need to make that run on another display than X:0 as well
<doko> s/make/make sure/
<fabbione> doko: i only have VNC here for testing..
<fabbione> doko: the new iron should arrive either this week or the next
<fabbione> that includes a real desktop
<fabbione> and a real server...
* fabbione can't wait to have his 32CPU's sparc here
<minghua> hendry: also you? :-  https://wiki.ubuntu.com/hendry
* minghua wonders why infinity's scim upload has a "Mar 1st" time stamp in changelog
<dAndy> who owns autofs in ubuntu, and can they take a look at: 31071 ? Thanks
<hendry> minghua: i just made that. Notice the last edited name
<hendry> minghua: "scim"?
<minghua> hendry: oh I see.  I didn't look at the date of the wiki page.
<minghua> hendry: the reason you have hendry2 on wiki is probably due to "hendry" is someone else on launchpad then
<minghua> hendry: apt-cache show scim
<fabbione> dAndy: i have been assigned autofs bugs, it's in the list with the others..
<dAndy> fabbione: ok cool, I added a possible patch to the comments, but then again, I dont know why it was changed between breezy and dapper
<fabbione> dAndy: i have no clue of anything.. i only got the autofs bug assinged to me.. i don't even use it
<dAndy> fabbione: heh ok, well it is a trivial change, and it is only reverting back to how it was in breezy
<fabbione> dAndy: ok thanks for the info
<pitti> Good morning
<dholbach> good morning
<Mithrandir> dholbach: you will soon have a patch for the clock applet to spawn evo on the right day incoming
<dholbach> Mithrandir: oh wow
<Mithrandir> dholbach: it wants the evo patch I put in last night too to avoid spawning two windows, but it's quite trivial
<Mithrandir> dholbach: do you have a bug number for that or should I just file a new one?
<dholbach> i'll take a look at it
<Mithrandir> https://launchpad.net/distros/ubuntu/+source/gnome-applets/+bug/35167 ; enjoy
<dholbach> Mithrandir: merci beaucoup
<Mithrandir> dholbach: it doesn't do the right thing when double-clicking appointments yet, but that should be easy enough to add.
<Mithrandir> (I'd assume)
<Mithrandir> I'm off for a bit, ttyl
<dholbach> see you
<dholbach> and thanks for the patch
<minghua> hello, I need a core-developer to review and upload the patch in bug #35163
<minghua> it's for SCIM's autostart feature
<minghua> I need this to be uploaded first to work on other scim packages
<minghua> and #ubuntu-l10n doen't seem to be very active (asked half an hour ago)
<minghua> anyone?  thanks
<minghua> https://launchpad.net/distros/ubuntu/+source/scim/+bug/35163
<minghua> as our bug bot is gone...
<dholbach> minghua: i'll do that
* minghua hugs dholbach 
<dholbach> minghua: done
* dholbach hugs minghua
<minghua> dholbach: thanks, you rock
<dholbach> thanks :)
<_ion> Anybody willing to try my NetworkManager 0.6.1 packages?
<pitti> _ion: we have 0.5.1
<_ion> pitti: Yes, that's pretty much the reason why i packaged 0.6.1. :-)
<pitti> _ion: Scott explained at length on ubuntu-devel why we can't upgrade
<pitti> patches have to be done against 0.5.1 for dapper
<pitti> _ion: unless you did all of the steps he mentioned there?
<pitti> _ion: i. e. did you port the ubuntu changes, like ifupdown compatibility, removal of name server dependency, etc.?
<pitti> (if so, *that* would indeed rock :) )
<_ion> My package should be compatible with ifupdown and have no name server dependency.
<_ion> I mean no local name server dependency.
<infinity> So, you ported all of Scott's patches, then?
<pitti> so you could port all the current ubuntu patches to your package?
<_ion> Not all of them, but i hope someone could help me in that task. http://johan.kiviniemi.name/ubuntu/
<pitti> which ones are still left?
<pitti> if the job is 90% done, then this would indeed be worth a try (IMHO)
<_ion> Let me see...
<siretart> _ion: does your 0.6.1  support wpa? which version of wpasupplicant do you require?
<siretart> _ion: I'm asking because I'm just preparing an upload of wpasupplicant to debian which has an patch from the 0.5 branch included, which seems to be needed for nm-0.6.1
<mdke> does the TB have an email address?
<jdub> technical-board@lists.ubuntu.com
<Pygi> mdke: they have mailing list if I am not mistaken
<mdke> thanks
<_ion> 10-dbus-api-fix.patch is already in upstream. 20-linux-wlan-ng.patch was not ported (src/NetworkManagerDevice.c doesn't exist anymore in 0.6.1). Ditto for 30-blacklist-devices.patch 50-disable-named-and-vpn-managers.patch 60-dispatch-more-events.patch. 40-ubuntu-backend.patch isn't ported (is it still needed?). 65-dispatcher-script-dir.patch and 70-dont-deactivate-new-devices.patch are ported.
<_ion> Unfortunately i don't have a WLAN card, i hope someone could help me by testing the package in a WPA network.
<pitti> _ion: 40-ubuntu-backend.patch is the central patch that has to be ported
<_ion> At the moment the dependency for wpasupplicant isn't versioned.
<pitti> _ion: 20-linux-wlan-ng.patch is my hack, if the others are cleared with Keybuk, then I will port that one
<pitti> _ion: but I'm afraid 50-disable-named-and-vpn-managers.patch and 40-ubuntu-backend.patch are so central for our needs that they need to be ported to 0.6.1 in a seamless way
<pitti> _ion: please don't feel discouraged by that, to the contrary, your efforts are highly appreciated; we just need to discuss how to get it right :)
<pitti> Riddell: ok, so I hacked langpack-o-matic to import packages like gwenview now; so unless you found any other important missing bits, I'm going to rebuild the packs now
<Mithrandir> _ion: ajmitch has a WPA setup at home, iirc.
<_ion> I'll look at porting NetworkManagerUbuntu.c (from 40-ubuntu-backend.patch) to 0.6.1
<pitti> _ion: cool :)
* _ion doesn't promise anything  i'm quite tired. :-)
<mdke> hey jdub, while you're here. start.ubuntu.com?
<Pygi> _ion; I can help if somethin' i sneeded?
<Pygi> needed*
<minghua> pitti: a question about lang-pack -- should all .po files of main packages be stripped and put into lang-pack?
<pitti> _ion, Pygi: I can assure you, if you manage to get that done for Dapper, you'll have to fight groupies with a stick^W^W^W^W^W^W^Wthe appreciation of the Ubuntu community will be your's :)
<pitti> minghua: ideally yes
<Pygi> pitti: hehe ;)
<_ion> :-)
<pitti> minghua: there are some redundancies for packages which were recently promoted without being rebuilt and such
<minghua> pitti: I was just thinking of the scim-* packages that recently entered main.  Almost all of them have .po files
<pitti> minghua: yes, they need a rebuild to get stripped (universe packages aren't)
<pitti> hi smurf 
* smurf hates NX
<minghua> pitti: but things like "* debian/rules: Add gettext domain to .server and .desktop files to get language pack support for them. (Similarly to cdbs' gnome.mk)" only apply to .desktop files, not .po files, right?
<minghua> pitti: (that was from your change to scim)
<pitti> minghua: right
<minghua> pitti: good to know.  thanks for explaining
<Pygi> pitti: when does it have to be done, so it would have a chance of being included? ;)
<pitti> Pygi: *actually* about four weeks ago, for upstream version freeze
<Pygi> pitti: o joy 
<pitti> Pygi: so it'll need a serious amount of begging, testing, and review to get it approved now
<Pygi> pitti: we'll have masses who will test once they hear package is here ^^
<pitti> Pygi: I'm sure that a lot of folks are happy to test it on u-devel
<tepsipakki> Hi! As dapper is now getting six week more testing and localisation time, is it possible to add openoffice.org-soikko (+libsoikko) which is a hyphenation addon for OO.o. The problem with libsoikko is that it isn't open source, but freely distributable, so they'd go to multiverse
<tepsipakki> it has been packaged for debian and ubuntu for a long time already, and the hyphenation quality is excellent
<tepsipakki> ..but I know that freeze is long gone now
<Tm_T> tepsipakki: oh yes, soikko coulbe useful
<Tm_T> tepsipakki: universe? ;)
<tepsipakki> multiverse
<tepsipakki> because of libsoikko
<tepsipakki> http://users.tkk.fi/~pry/soikko/license.txt
<Tm_T> aah
<Tm_T> tepsipakki: #ubuntu-motu I think
<tepsipakki> i guess.. I'm not sure
<tepsipakki> I know the answer from there ;)
<Tm_T> and that is?
<tepsipakki> "no" :)
<Tm_T> don't be so sure
<tepsipakki> that's what I'd expect at least :)
<tepsipakki> but ok
<_ion> NetworkManagerUbuntu.c from 40-ubuntu-backend.patch is pretty much ported. Next i'll have to modify the autotools stuff in order to compile it and see if it works. :-)
<pitti> _ion: btw, feel free to throw out the autotools changes from that patch and regenerate it as a separate patch (or just inline)
<sivang> morning all
* sivang hugs pitti
<pitti> hi sivang 
<_ion> pitti: Hm. Would it be evil to make the patch just replace NetworkManagerDebian.c with the Ubuntu-specific stuff instead of adding a whole new NetworkManagerUbuntu.c? That way there would be no need to fiddle with configure*, Makefile* etc.
<pitti> _ion: hmm, it would work for me, but please rather ask Keybuk about it; it's his baby
<pitti> _ion: but for the purpose of initial packaging, that's certainly fine
<pitti> _ion: we can always restructure it afterwards if the actual thing works and is accepted
<_ion> Ok.
<jdub> anyone tried today's dapper install cd (not live)?
<Mithrandir> jdub: I tried yesterday's; why?
<jdub> Mithrandir: works ok?
<Mithrandir> jdub: yes, worked fine for me.
<jdub> thanks
<siretart> _ion: for wpa, you will most probably need this package of wpa: http://siretart.tauware.de/wpasupplicant/, version 0.4.8-1
<mroth> ok, maybe its because its 1:30am, but where on earth is the "attach file" function in launchpad?  I'm too used to bugzilla
<mroth> er, nevermind, i knew as soon as I hit "enter" i would find it
<_ion> siretart: Ok, thanks. I don't have a WLAN with WPA, but Pygi does and he said he'd help with the package. I'll mention about that to him.
<siretart> _ion: the network-manager maintainer in debian told me that he needs the ap-scan command in wpa_cli for nm to work with wpa. this command is only in the 0.5 branch available, but the 0.4.8 package I pointed you to has this command backported
<_ion> siretart: Ok, nice.
<siretart> _ion: so both packages should work, but only the 0.4.8 package is a candidate for dapper at all (and even thats undecided)
<Pygi> siretart: no way to get 0.5 branch in?
<kagou> hi
<mpt> Goooooooooooooooooooood morning Londonpadders!
* Tm_T hides
<Tm_T> stop that siren!
<doko> dholbach: examplecontent ping
<dholbach> doko: i'm on the phone
<dholbach> doko: ttyl
<siretart> Pygi: the 0.5 branch is considered as the experimental development branch by upstream. it works for me, but I wouldn't recommend to support that branch for years
<Pygi> siretart: agreed
<siretart> Pygi: the 0.4.8 branch on the other hand was broadly tested and is in maintenance mode. only small and careful updates, perfect for longterm support
<ajmitch> morning siretart 
<siretart> hi ajmitch 
<jordi> jdub: re LAMP, I guess you did see my reference to that after FOSDEM :)
* highvoltage really likes the new LAMP acronym
<sivang> mpt: this is not #launchpad ? :)
<_ion> Btw., in the network-manager-0.6.1 package i put the nm-vpn-properties binary into the nm-applet package. Should it be split to its own package?
<Seveas> you should not include vpn
<Treenaks> Seveas: vpns rock!
<Seveas> currently Ubuntu does not include the VPN stuff for a good reason 
<Seveas> Treenaks, nm-vpn not - it's quite flaky
<Treenaks> Seveas: ok.. so it needs bugfixing ;)
<siretart> Treenaks: it needs a complete development cycle for exhaustive testing. dapper will be supported 3 years on the desktop
<neuralis> seveas: i didn't look, what kind of vpns does nm support?
<siretart> Treenaks: lets better provide add on packages for dapper, and integrate them into edgy
<mpt> sivang, I didn't mention Launchpad :-P
<Treenaks> siretart: oh sure
<Seveas> _ion, please make sure your package has about the same functionaluty as the current Ubuntu package (ie no bind needed, no vpns etc) but does support wpa
<sivang> mpt: you said, launchpadders , but indeed, I guess we're now all lunchpadders as we're using it :)
<_ion> seveas: Ok, will do.
<Seveas> That's the best way of getting it accepted
<mpt> sivang, no I didn't
<sivang> err
* sivang is blind
<mpt> :-P
<sivang> londonpadders
<sivang> mpt: you're also in London now?
<Seveas> sivang, you will be pleased to know that Ubugtus webcal plugin is now fully functional, including your request. 
<mpt> sivang, temporarily
<sivang> Seveas: yay! /me does a happy dance
<sivang> mpt: launchpad sprint ?
<sivang> Seveas: so how can I ask it for the current ongoing meeting?
<mpt> yes
<Seveas> not - it's in the topic from 10 minutes before to 30 minutes after the meeting
<sivang> very good. thank you!
<infinity> dholbach: BTW, goffice is FTBFS.
<infinity> dholbach: All arches.
<mvo> infinity: any news about the auto-dist-upgrade test setup :) ?
<dholbach> infinity: thanks, i'll have a look at it later
<infinity> mvo: Stalled for a bit, we need to discuss it with elmo, who just about choked when I mentioned it to him. :/
<mvo> infinity: hm, can't we get a (cheap) decicated machine then? I mean, if it's too risky to put it on a machine with other tasks? or I can go and put it on one of my own machines early next week (when I'm back from sprinting)
<infinity> mvo: Yeah, we could get one dedicated machine, though we ideally want one per arch.
<seb128> infinity: do you have an idea if other GNOME packages are FTBFSing? Launchpad doesn't make easy to look on daily failures, etc
<mvo> infinity: right. sometimes the problems are arch-specific unfortunately (ia32-libs exploeded yesterday on amd64)
<infinity> seb128: You're right, it doesn't make it easy...
<infinity> seb128: https://launchpad.net/distros/ubuntu/+builds?build_state=failed <-- that may help a bit, though.
<doko> jordi, seb128: btw, see gnome report #334738, gedit examples ...
<doko> mvo: no change in ia32-libs yesterday
<infinity> seb128: Be careful of version numbers, since LP still has a bug where it will happily retry obsolete sources..
<mvo> doko: I didn't explain myself clearly, it was discovered yesterday by a user, but it may well be a problem for some time
<jordi> doko: wrong bug number?
<seb128> infinity: is there a way to filter by arch?
<infinity> seb128: Not yet, no. :/
<doko> jordi: no, "wrong characters in print preview/file"
<doko> opened for gnome-print
<jordi> doko: doh, I was looking at the bts ;)
<seb128> doko: bugzilla.gnome bug
<doko> seb128: yes
<doko> Kamion: please process OOo-l10n binaries in NEW, and promote them to main
<jordi> doko: hmm. Horrible.
<jordi> If what appears i nthe preview is what actually appears in the paper, I see what you're saying now :)
<pitti> seb128, Riddell: new langpacks on http://people.ubuntu.com/~pitti/langpacks/, this time evenn with amarok and gwenview :)
<Kamion> doko: I already did
<Kamion> doko|impatient again ;-)
<doko> jordi: yes, you actually have to check a printout; best thing, if you do that on a postscript printer.
<doko> Kamion: heh, looks like you have an interest in smaller packages ;-)
<Kamion> more an interest in the output of queue not overflowing my screen too badly ... one line per binary package
<jordi> doko: we have no printer here :/
<doko> jordi: not my problem ;-P
<jordi> hehe
<seb128> pitti: is there any need to try new gnomeish package? :)
<seb128> pitti: ie: any change since yesterday?
<pitti> just some updates
<pitti> might have more translations now
<pitti> but I think if I test them, that's good neough
<seb128> lemme try
<doko> seb128: your gtk changelog: "patch for ia32-libs package" should be a32-libs-gtk package, but that's not in Debian
<seb128> doko: I know, that's listed as one of the sync changes, ie: an Ubuntu specific patch
<seb128> doko: noted for the package name :)
<seb128> pitti: /usr/share/locale-langpack/fr/LC_MESSAGES/test.mo ... is that a package? :)
<pitti> hmm, what's in it?
<pitti> nm, I have it here
<pitti> it must come from a package, yes, I didn't add anythign manually
<seb128> k
<pitti> ===== Processing /home/lamont/public_html/translations/20050922/nevow_0.4.1-1.1ubuntu1_i386_translations.tar.gz =====
<pitti> wftl: nevow_0.4.1-1.1ubuntu1: 0 domains, but 1 pot files
<pitti> wftl: nevow_0.4.1-1.1ubuntu1: guessing domain from single POT file: test
<pitti> bah
<pitti> hm, that can't be it
<pitti> seb128: I'll refine dload-strippedtarto show the domains it imports
<pitti> seb128: but for now it doesn't really hurt, I think
<seb128> yeah, just noticed it and was wondering if that's a debug stuff you let :)
<seb128> since that's a new .mo
<ploum> doko: ping ?
<doko> ploum: just ask
<ploum> doko: I upgraded OOo today and it re-created the file  opens___.ttf
<ploum> so OOo interface is completely broken
<ploum> (I know I just can remove the file but I  wanted to told you)
<StevenK> Ran 200 tests in 9.233s
<StevenK> OK
<doko> ploum: no, the file is not there
<StevenK> WHEEEEE!
<ploum> doko: weird...  I removed the file yesterday. Today I just dist-upgraded and the file is here again
<doko> ploum: which version?
<ploum> 2.0.2-1ubuntu3
<ploum> the opens___.tf is marked as modified today at 7:03AM
<ploum> (my computer was off, so I suppose this is the build time of the package or something like that)
<ploum> Well, I remove it and I will tell you if something happens again
<jordi> mvo, daf and I just decided to start an "autoubuntu" derivative
<jordi> with all the autopackage goodness you can get
<ploum> (anyway, thanks for the Print-patch drop. Brochure mode is now working again and I'm happy :-) )
<seb128> jordi: please go troll somewhere else :p
<jordi> seb128: sure, sure. You keep doing those old .deb things.
<ploum> jordi: I'm thinking about launching a messedbuntu distro. Using only RPMs
<doko> pitti: five new OOo help packages ...
<jordi> ploum: we will beat your mess. Our technology is up to it. :)
<Seveas> ploum, jordi: I seriously don't know who of you to lart first...
<Seveas> you should use klik everywhere!!!112!!!one
<pitti> doko: adding them
<pitti> doko: hm, I can't see any new ones? did they just came out of NEW?
* pitti apt-get updates
<pitti> doko: nevermind, got them
<doko> pitti: yes
<doko> ploum: you are right, missed the removal of that file
<doko> ploum: you are right, missed the removal of that file
<ploum> doko: ok. Thanks for looking :-)
<pitti> doko: uploaded
<mvo> pitti: we discussed the font perferences stuff again here and the current prefered solution is to make language selector set the fontconfig stuff
<pitti> mvo: hm, that's not really a solution, it's a nasty hack that won't solve the actual problem :/
<pitti> mvo: but oh well, if nothing else is possible ...
<seb128> mvo: do most of people actually use the language selector?
<mvo> well, the solution to have special fontconfiles depending on the language is a bad hack already
<mvo> and worse, the different chinese variants use different settings apparently
<mvo> so zh_TW and zh_CN have different perferences apparently
<mvo> the alternative would be to ship the file in seperate package (with a single file) or as part of language-{pack,support}
<mvo> it's all pretty bad
<mvo> and the zh_TW and zh_CN problems seems to be "delicate"
<pitti> heh ;)
<fabbione> mdz: do you think it would be possible to have an UVF exception for missingh (universe)? the changes are minor bug fixes, including fix of FTBFS on sparc, that will unleash another big set of pkgs to be built on sparc.
<pitti> mvo: can you please explain to me again why removing latin glyphs from the CJK fonts would be bad? (just trying to understand the reason)
<mvo> pitti: japanese and chinese have overlapping glyths (the same glyth appera in both languages)
<infinity> mdz: missingh is at the base of a twisted maze of haskell build-deps, and the upstream changes look tiny and harmless.
<pitti> mvo: so?
<infinity> mdz: (TBH, I would have just uploaded and asked forgiveness, rather than permission, but given how strict we've been this release, I didn't want to piss anyone off) :)
<pitti> mvo: I didn't intend to split the CJK fonts :)
<highvoltage> weird
<mvo> pitti: well, there are various problems, one is that on a stock install you can have japanese glyths in a otherwise chinese text
<mdz> fabbione,infinity: I have no objection; UVF exception management for universe has been delegated to motu-uvf
<pitti> mvo: how woudl removing latin glyphs from the CJK fonts change that?
<pitti> mvo: s/change/break/
<infinity> mdz: Ahh.  Cool.  Perhaps I should join that group. :)
<mvo> pitti: it wouldn't change that at all, but it wouldn't solve this problem either
<pitti> mvo: why not?
<pitti> mvo: I thought the main itch was that latin looks bad under CJK, and CJK looks bad under latin?
<mvo> pitti: that is true but unfortunately only one of the problems, the other one is that chinese and japanese glyths are mixed 
<fabbione> mdz: danke
<pitti> mvo: I don't think that we can solve *this* problem at all
<infinity> fabbione: Shall I do the fake sync?
<pitti> mvo: not even with the hack you proposed (or can we?)
<fabbione> infinity: go ahead
<infinity> Kay, doing.
<mvo> pitti: the solution to have different perferences based on the language (THE HACK) will solve it because it moves chinese fonts to the top for chinese and japanese fonts for the japanese users
<mvo> pitti: currently it's either japanese fonts have preference or chinese ones. that means one group of to manually fix there setup
<pitti> EPARSE
<mvo> pitti: sorry, network problems
<mvo> pitti: what was the last bit you said/got from me?
<pitti> <mvo> pitti: currently it's either japanese fonts have preference or chinese ones. that means one group of to manually fix there setup
<pitti> <pitti> EPARSE
<Lathiat> you forgot your -
<mvo> pitti: let me try again. there are certain glyths that are in both chinese and japanese fonts (because both languages have the glyth). when the application asks for that glyth fontconfig will pick a font for it. it will use (among other stuff) the order in which the fonts are listed in the fonts.conf file. if a japanese font is before a chinese one fontconfig seems to pick that
<infinity> Lathiat: pitti is unsigned.
<daf> hi pitti 
<pitti> hey daf
<Lathiat> pitti: im sorry
<Lathiat> it must be a boring, but simple life
<daf> stripping latin glyphs would be hacky but possible
<mvo> pitti: that means that you end up with a mostely chinese text with some japanese glyths
<daf> I'm not sure what adverse effects it would have
<pitti> mvo: right, I agree that using the locale hack is acceptable for that overlap
<mvo> ok
<pitti> but not for the CJK <-> Latin conflict
<pitti> there must be a better solution
<pitti> I want to read Chinese spam, and Chinese/Japanese people want to read English
<pitti> or write
<pitti> Firefox/Console/etc.
<mvo> agreed
<daf> Abel is going to join us
<abelcheung> yes, I'm here
<daf> ah, hi Abel
<pitti> hi abelcheung 
<pitti> abelcheung: ok, so we identified two different problems
<mvo> abelcheung is our expert for those matters :)
<pitti> abelcheung: did you see the scrollback here?
<mvo> pitti: freefont has a script btw to strip out glyphs 
<pitti> abelcheung: what would you think about a locale hack to sort out the Chinese/Japanese conflict type, and removig the Latin glyphs from CJK fonts to solve the Latin/CJK conflict?
<abelcheung> about stripping latin chars from CJK fonts... (well I didn't think I'm expect in this area)
<pitti> mvo: fontconfig with LC_ALL=C works fine, btw :)
* mvo always wondered why the world need anything else than monospace and LC_ALL=C ;)
* jordi kills mvo.
<pitti> solution 6 :)
* pitti points toseb128 :)
<_ion>  network-manager (0.6.1-5) dapper; urgency=low
<_ion> * Removed named/VPN stuff in order to have about the same functionality as the 0.5.1 package.
<abelcheung> yes, there is some benefit; one of the Korean font already did that, it's "EunGuseul Mono"
<abelcheung> but....
<jordi> abelcheung: well, it's one of the problems zh users have, clearly
<pitti> _ion: oh, I don't actually think it's necessary to remove features, just the current backend must continue to work as it does now :)
<abelcheung> an uproar might be coming if we really do this
<pitti> abelcheung: 'this' -> remove glyphs?
<abelcheung> pitti: exactly
<pitti> abelcheung: what would you propose instead?
<daf> sounds risky
<_ion> pitti: Well, that's what 50-disable-named-and-vpn-managers.patch does in 0.5.1.
<pitti> I'm aware that this isn't very clean, but I fail to see another solution
<pitti> _ion: alright :)
<jordi> abelcheung: why would that happen?
<daf> what happens if fontconfig specifies latin-only fonts before CJK fonts?
<pitti> AFAICS, if the CJK glyphs look crappy in vera, and Latin looks crappy in CJK fonts, then it's sorta obvious to pick the best of each
<daf> wouldn't it use latin from the latin fonts and CJK glyphs from the CJK fonts?
<daf> Vera has no CJK glyphs
<jordi> daf: afaiui, should work?
<pitti> daf: right, we could also do it this way aroud
<pitti> around, even
<_ion> So, now 40-ubuntu-backend.patch and 50-disable-named-and-vpn-managers.patch _should_ be ported/recreated from 0.5.1.
<pitti> _ion: rock :)
<daf> I don't think DejaVu has any either
<abelcheung> daf: right now latin-only fonts are already located before CJK fonts, but somehow when latin glyphs and non-glyphs touch together, the effect is undeterministic
<daf> ah
<daf> that sounds very much like a bug
<abelcheung> non-latin glyphs
<abelcheung> daf: yes
<jordi> abelcheung: fontconfig bugs?
<pitti> rather gtk ones, I assume ?
<daf> hmm, could be a pango issue
<jordi> pitti: I think this is a joint seb128/keithp sabotage operation
<pitti> jordi++
<daf> it's difficult to know
<pitti> jordi: I tell you, seb128 didn't ever give up solution 6
<seb128> solution 6 is the way to go
<daf> I thought seb likes solution 7
<daf> "make everyone speak French"
<pitti> seb128: only with slightly altered parameters :)
<Robot101> iz gtk boog
<abelcheung> I'd rather use suicide as 6th solution
<jordi> where's seb? He should have started kicking people already
<pitti> abelcheung: seriously again, if we removed ugly CJK glyphs from fonts which have a higher prio than good CJK fonts, that would have the same effect, wouldn't it?
<jordi> oh. he just defended #6.
<jordi> hi seb :)
<pitti> abelcheung: (if removing latin from CJK would be considered impolite/whatever)
<seb128> hey jordi ;)
<daf> would stripping CJK from freefont (e.g.) help?
<ajmitch> jordi: harassing poor seb again?
* seb128 kicks jordi
<abelcheung> pitti: it's mostly publicity effect that makes the stripping action bad.
<seb128> don't worry for me :)
<abelcheung> pitti: not technically bad
<pitti> abelcheung: I don't see how?
<pitti> abelcheung: I mean, we don't strip CJK glyphs altogether, we just select the best ones?
<daf> ajmitch: don't fall for that "poor gnome maintainer" spiel
<abelcheung> say when greek or russian characters were stripped from some fonts, those people will be angry as well
<jordi> ajmitch: it's better over planet, as he never replies
<pitti> daf: interesting to see that 'spiel' is an accepted English word :)
<daf> indeed!
<pitti> abelcheung: hm, I'm really no expert in the PR effect of modifying fonts :)
<pitti> but ugly glyphs on the desktop should have a worse PR effect than what's behind the scenes, or not?
<abelcheung> pitti: latin fonts are already placed beyond non-latin ones, just that they sometimes don't work (worse part is, not always won't work, just sometimes)
<jordi> I really don't understand the "bad press" effect either, but I guess we need to trust abel on that :)
<seb128> "View your computer storage" -> "View your files and disk space"
<jordi> I mean, the change would be for good of zh users
<seb128> for computer tooltip
<tepsipakki> bah, gnome-screensaver doesn
<tepsipakki> 't use pam_sm_setcred()
<seb128> what people think about ""Browse all computer files" or ""Browse your computer drives"?
<pitti> also, having specialized fonts helps to remove redundancy and makes them smaller; modularity rulez :)
<jordi> abelcheung: I appoint you to fix fontconfig, that solves the problem. :)
<mvo> I think it's a solution we should try (removing the glyph) if we get feedback from the font-mainters first (and if they don't oppose it)
<daf> seb128: B
<mvo> if only fontconfig would support the exclusion of certain unicode ranges for fonts ...
<pitti> seb128: where is that string?
<seb128> daf: thank you :) any better suggestion maybe?
<_ion> C) "Format C:"
<seb128> pitti: tooltip of "Computer" to Places panel menu
<pitti> mvo: which would have the same effect without the benefit of saving disk space...
<daf> seb128: I guess "drives" rather than "mounts" is standard
<abelcheung> jordi: me? .......... I can try my best, though there might be some bug down from gtk to fontconfig layer that needs attention from corresponding maintainer
<daf> seb128: maybe "locations" :/
<pitti> seb128: heh, right, the current German translatino for this one is horrible
<seb128> "View your computer storage" is current english
<daf> hmm
<mvo> pitti: yes and it would be a configuration issues, people could revert it (not that easy when they are actually removed)
<seb128> silbs suggested "View your files and disk space" but is not sure about it
<daf> doesn't it also include network mounts?
<seb128> mdz suggested "Browse all computer files"
<seb128> daf: no
<daf> ok
<pitti> mvo: but I guess it is (a) harder to implement and (b) would have an incredible runtime penalty
<pitti> mvo: since then the font selection needs to happen for each glyph, doesn't it?
<pitti> or does that already happen?
<daf> I think it happens for chunks of text
<abelcheung> pitti: besides, does fontconfig scan all fonts to pick the most preferred ones for all glyphs?
<mvo> (a) <- yes (b) I'm not sure, there is a cache for this
<pitti> abelcheung: currently fontconfig only selects per-family, not per unicode block
<daf> I'm not sure, for example, whether Firefox passed the language of each paragraph to fontconfig when selecting fonts
<pitti> abelcheung: so it's not 'all' glyphs
<abelcheung> pitti: I see
<daf> or if it just specifies one language for each page
<pitti> but I don't really know about fontconfig details
<pitti> daf: I hope not :)
<daf> you can do <p xml:lang="zh">...</p>, but I don't know if this has any effect on font selection
<jordi> abelcheung: was kidding, sorry :)
<mvo> pitti: we will try the "remove glyphs" approach here locally after lunch to see what it looks like
<pitti> mvo: yes, that would be nice :)
<mvo> :)
<pitti> good_press('works for everyone' good font config by default) - bad_press('messing up fonts') >> 0 hopefully :)
<daf> :)
<pitti> as for the C/J conflict, the only real solution would be that both C and J glyphs would look equally well in all fonts that provide both, right?
<pitti> s/both/either/
<daf> I'm not sure it's possible to have one font that will please both Chinese and Japanese users
<daf> they prefer different styles
<daf> abelcheung: is that correct?
<pitti> we need one for every family, right?
<pitti> they probably don't have serifes, but certainly a different set of families
<daf> right
<mjr> yes, there are differences in recommended renderings in Chinese and Japanese
<daf> e.g. Japanese has "kochi", "mincho" and "marumoji" families
<daf> sorry, s/kochi/gothic/
<ogra> seb128, redhat has a preferences-merged/ dir in gnome-menus, do we have a equivalent to add <Include>/<Exclude> statements ? 
<abelcheung> daf: yes, that's correct, they prefer different styles
<sladen> killall -9 gnome-screensaver && echo DIE HARDER
<ogra> sladen, good idea :/
<Riddell> pitti: lang packs are good for me
<pitti> Riddell: thanks
<seb128> ogra: what do you mean?
<seb128> ogra: what are you trying to do?
<ogra> seb128, adding a file to g-s-s that hides the xscreensaver entry from the menu
<ogra> i see that redhat just drops a file with an exclude statement into /etc/xdg/menus/preferences-merged
<seb128> ogra: put NotShowIn=GNOME for xscreensaver and you are done
<ogra> heh
<ogra> ok, we're easier ::)
<ogra> seb128, thanks :)
<seb128> np
<ogra> err
<ogra> seb128, that will hide it forever ...
<ogra> i want it shown if g-s-s is not installed
<seb128> from GNOME yeah
<seb128> ah
<BenC> Wow, OOo, gcc, gnome and some xorg all in one night...wish I had uploaded the next kernel to really make it a nice update :)
<seb128> suck to be you
<ogra> :P
<KaiL> hmm, beagle wants those "extendes attributes", out kernel has them - so, why aren't they enabled in /etc/fstab?
<seb128> KaiL: because we don't ship beagle by default?
<KaiL> oops ;)
<pitti> seb128: hm, beagle-dev is still in universe
<pitti> seb128: (for the nautilus issue)
<pitti> seb128: and beagle is not yet approved for main
<dholbach> doko: pong
<seb128> pitti: I though you approved it for main
<pitti> no, reviewed it
<pitti> the bugs are simple enough to fix, I guess
<pitti> but noone did it so far
<pitti> I'd be fine with depending on beagle-dev now if anyone fixes beagle
<seb128> I didn't take your comment as a "must be fixed before promotion"
<seb128> tseng: ping? :)
<pitti> just to avoid promoting, and then forgetting about it
* mvo goes for lunch now
<pitti> mvo: enjoy!
<pitti> mmm, lunch, will do the same
<zul> heylo
<Kamion> Kinnison: gparted seems to be hanging on apply here - all I told it to do was create two partitions
<Kamion> absolutely bugger-all happening in strace
<natroll> doesn't sound very nice
<tseng> seb128: yo
<seb128> tseng: hi
<seb128> tseng: did you have a chance to look on beagle bugs pitti pointed for promotion?
<sivang> tseng: hey
<Kamion> Kinnison: BTW, your emacs appears to be enthusiastically converting tabs to spaces in some of the installer-mode patch, which makes it a bit hard to read in places
<infinity> mdz: Okay to sync db4.2 (no more diff, yay!), db4.3 (manpages added), and db4.4 (manpages, and a hang in libdb4.4 fixed)?
<Kamion> particularly when looking at the ubuntu2 -> ubuntu3 diff
<infinity> mdz: I just merged all the Ubuntu changes into the Debian packages, so it'd be nice to go the other way and have them in sync finally. :)
<Keybuk> heh, under an hour to spare!
<_ion> keybuk: Hi
<Keybuk> hey
<_ion> keybuk: Could you please inspect 40-ubuntu-backend.patch in http://johan.kiviniemi.name/ubuntu/ ?
<Keybuk> what does it change?
<infinity> mdz: And I have no idea why I just asked that, since it's neither an upstream version bump of a feature change, just bugfixes.
<infinity> s/of/or/
<_ion> keybuk: Well, i ported the patch to network-manager 0.6.1 (hopefully correctly :-) ). Also: < _ion> pitti: Hm. Would it be evil to make the patch just replace NetworkManagerDebian.c with the Ubuntu-specific stuff instead of adding a whole new NetworkManagerUbuntu.c? That way there would be no need to fiddle with configure*, Makefile* etc. < pitti> _ion: hmm, it would work for me, but please rather ask Keybuk about it; it's his baby < pitti> _ion: ...
<_ion> ... but for the purpose of initial packaging, that's certainly fine < pitti> _ion: we can always restructure it afterwards if the actual thing works and is accepted
<Keybuk> ok, I'll have a look at it
<Keybuk> see how different it is to my own effort here
<_ion> Thanks.
<Keybuk> no, thank you :)
<tseng> seb128: yes, we have been working alot more on evolution-sharp bug
<tseng> seb128: it looks like slomo fixed it, but i didnt get to check yet.. it was a real showstopper
<seb128> tseng: ah, nice
<seb128> slomo_: ping?
<tseng> seb128: do you still want to promote it?
<seb128> tseng: why not?
<slomo_> seb128, tseng: beagle/evo-sharp seems to work fine for me now... no crashes, no memory filling :)
<tseng> because its late, and its dapper
<seb128> <pitti> I'd be fine with depending on beagle-dev now if anyone fixes beagle
<tseng> ok.
<seb128> tseng: it should have 0 impact on the desktop if beagle is not installed
<tseng> let me look at that autostart
<Kamion> fabbione: I still need the disk selector in partman-auto. How's that going?
<seb128> the fallback is a few lines of code
<tseng> seb128: it looks like novell has their whole desktop relying on it now
<seb128> yeah
<seb128> they have GTK filechooser, yelp, deskbar, nautilus using it
* Keybuk still wants to know how Beagle *doesn't* kill a machine when you login
<tseng> they have gtk 2.10?
<seb128> dunno, I've not figured when yo find srpms for suse
<tseng> they are really hard to find for nld
<seb128> but that's possible they have 2.8 with the beagle patch
<tseng> they are in novell forge
<tseng> Keybuk: it has some semi-intelligent throttling
<seb128> I don't know, I just supposed since federico blogged about it
<seb128> tseng: do you have an URL for that? :)
<tseng> Keybuk: the scheduler slows down on battery power, speeds up when a screensaver is active
<tseng> Keybuk: 0 throttling with EXERCISE_THE_DOG=1
<Keybuk> right
<Keybuk> it still has to "find" on whatever it wants to watch though
<Keybuk> inotify is teh suck
<tseng> better than no inotify
<slomo_> seb128: would you want gsf support in beagle? it's not yet enabled because our gsf-sharp is too old... but seems like something useful to me
<Keybuk> I still want *something* to notify userspace of mounts and unmounts
<seb128> slomo_: what is gsf?
<Keybuk> seb128: I have a HAL/GnomeVFS bug for you ... I have a floppy icon
<seb128> Keybuk: do you have a /etc/fstab floppy entry?
<Keybuk> seb128: yes
<seb128> so you get an icon ...
<Keybuk> I have a floppy drive too
<Keybuk> right, that's not the whole bug yet
<Keybuk> due to the PNP bug, I don't have "floppy" loaded
<Keybuk> if I modprobe floppy; I get /dev/fd0
<Keybuk> and *another* floppy icon
<Keybuk> so HAL/GnomeVFS things I have two floppy drives
<slomo_> seb128: your country... starts with g ;) libgsf is for reading all kind of document formats afaik
<seb128> slomo_: hehe
<seb128> Keybuk: I would be tempted to say that we should not put an fstab entry for it :)
<Keybuk> seb128: some people still like to mount and unmount their floppy the old fashioned way
<Keybuk> HAL/GnomeVFS should be intelligent enough to see the "newly added" floppy drive has the same DEVNAME as the one in /etc/fstab
<Keybuk> (modprobe floppy results in /dev/fd0 ... which is what the entry in fstab has)
<seb128> yeah
<Keybuk> where should I file the bug?
<seb128> gnome-vfs probably
<slomo_> seb128: well, i'll test it here now... and tseng will file a UVF exception for beagle to get us the newest bugfix release
<seb128> thank you
<Keybuk> seb128: either that, or HAL/GnomeVFS should ignore fstab entries for which the device doesn't exist :p
<seb128> that case should be fixed yeah
<seb128> the "look for duplicate" is a bonus then :)
* Keybuk wonders whether running "udevplug" causes more floppies to get added
<Keybuk> no, it's safe against that at least
<Keybuk> bug 35191 anyway
<Ubugtu> malone bug 35191 in gnome-vfs "Duplicate floppy icons" [Normal,Unconfirmed]  http://launchpad.net/bugs/35191
<seb128> thank you
<seb128> what would people use instead of "Log out <username>..." for the menu item name?
<seb128> Mark suggested "Quit", what do you think about it?
<_ion> IMO "Log out foo" is very good, "Quit" would be more confusing.
<daf> what's hte problem with "Log out..."?
<Amaranth> i like "Log out <username>..."
<dholbach> because you not just log out there, you can lock your screen as well, switch user, ...
<janimo> "Finish"
<seb128> daf: Mark doesn't like it 
<seb128> and right
<daf> won't changing this string affect l10n coverage?
<_ion> "Kill self"
<seb128> there is the fact the Ubuntu session dialog allow to does stuff like locking screen
<dholbach> "Leave session"
<pitti> seb128: the only thing that embraces all 7 options is 'Fiddle with my session...' :/
<seb128> dholbach: locking is not leaving it :)
<daf> pitti++
<dholbach> but session was deemed too technical
<dholbach> seb128: you leave it alone for some time :)
<seb128> daf: we have rosetta .... 
<pitti> dholbach: 'log out' is heavily technical, too
<jdub> seb128: "kthxbye"
<seb128> jdub: :)
<dholbach> i like leave session with a funky icon, it should be ok
<pitti> "Don't wanna play any more"
<_ion> jdub: :-D
<seb128> "Are you sure you want to do that"
<_ion> "I'm afraid i can't let you do that, <user>"
<dholbach> "take my ball and play elsewhere"
<jdub> seb128: "Install unpatched gnome-panel..."
<pitti> we really can't split 'End session...' and 'Pause session...'?
<pitti> and we have to accomodate 'switch user', too
<jdub> pitti: upstream does this quite nicely...
<jdub> (using a similar approach to windows xp and mac os x, splitting these two sets of functions)
<seb128> upstream is not the discussion
<jdub> :-)
<seb128> we have to stick with what we have
<seb128> and I would like a panel item title...
<jdub> was getting to explain to pitti that we are specifically not doing it that way
<pitti> jdub: but there is a feature missing: 'Open email client' (8th button)
<jdub> pitti: dapper+1 :-)
* pitti goes to spec it
<tseng> pitti: :D
<pitti> seriously, the current thing is pretty confusing
<_ion> pitti: In addition, i think the dialog should have a "run interactive ruby in shell" button as well.
<jdub> seb128: i think log off ends up being the best compromise for that entry
<jdub> seb128: what's the tooltip for the top right button?
<seb128> "Log out of this session to log in as a different user" beeing changed now by "Leave this session" 
<pitti> jdub: 'log off' says nothing to normal users, or does it have a common non-geek meaning in English?
<seb128> change from silbs mail
<jdub> pitti: it's very widely accepted jargon
<pitti> jdub: does it convey the fact that 4 of the 7 options don't log you out?
<jdub> pitti: no, but it's the most reasonable compromise, considering that's what we have to deal with
<pitti> jdub: what about 'End/pause session'?
<janimo> How about "Back to real life"
<jdub> pitti: session means even less, and end/pause are extremely uncommon in this context
<jdub> windows has 'switch user' behind its 'log off' set of choices too
<pitti> also suspend and hibernate?
<jdub> no
<jdub> as said above, windows xp and mac os x both have the same strategy as upstream
<pitti> 'Go away from the computer'
<pitti> :)
<jdub> (osx splits them by listing sleep/restart/shutdown and "log out <user>..." as separate menu entries
<jdub> sorry: sleep, restart..., shut down... and log out <user>...
<pitti> seb128: hm, so shall I upload the current nautilus, or wait for sb to fix beagle?
<seb128> pitti: go for it
<pitti> yes, give the buildds something to grind :)
<Mithrandir> seb128: xkeyboard-config 0.8 is a tad icky wrt merging, but I think it's doable.
<KaiL> how to raise a bugs importance? Having no X after installing is imho rather critical... https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/+bug/35194
<Ubugtu> malone bug 35194 in xserver-xorg-driver-ati "activated but not usable on X1xxx" [Normal,Unconfirmed]  
<seb128> Mithrandir: do you need merging? I just updated current package to 0.8 which works fine
<seb128> Mithrandir: Debian moves stuff too /usr/share, we don't need that for that cycle
<Mithrandir> seb128: you did? Have you uploaded it already or just waiting so far?
<seb128> Mithrandir: no, I've just tested on my box
<seb128> Mithrandir: but didn't merge anything, just apt-get source xkeyboard-config, copied debian dir to new source and debuild dpkg-i
<Mithrandir> seb128: 'k, if you'd like to drop the packages somewhere I can get at them, I'd appreciate.
<Mithrandir> hmm, ok.  There's a bunch in the .diff.gz, unsure how much we need, though
<seb128> daniels said that's mainly 0.7 stuff he backported I think
<seb128> before 5.10
<seb128> I can ping him about it if you want
<seb128> diff seems quite short
<Mithrandir> I'll ping him and see if there's anything we should be careful about.
<Mithrandir> it seems to include an awful lot of generated files in the source
<Keybuk> Mithrandir: basically I've had three or four reports that a LiveCD has wireless-* options in /etc/network/interfaces
<Keybuk> (which prevents n-m from workign)
<seb128> Mithrandir: 
<seb128> mar 15 23:18:24 <seb128>        do you know if that's a risky update?
<seb128> mar 15 23:18:38 <seb128>        or if 0.8 should be as good or better than 0.6?
<seb128> mar 15 23:19:34 <daniels>       0.8 should be fine, the last really intrusive thing they did was all the fixes that went into 0.7 that I pulled back into 0.6
<seb128> Mithrandir: that's from yesterday
<Mithrandir> seb128: ok, so we're really at 0.7, not 0.6.
<Mithrandir> Keybuk: given that what casper does is:
<Mithrandir> for interface in /sys/class/net/eth* /sys/class/net/ath*; do [ -e $interface ]  || continue i="$(basename $interface)" cat >> "$IFFILE" <<EOF
<Mithrandir> auto $i
<Mithrandir> iface $i inet dhcp
<Mithrandir> that's quite impressive.
<Mithrandir> EOF
<Mithrandir> done
<Keybuk> ok...
<Keybuk> so casper doesn't run anything that does wifi network detection?
<Keybuk> that was basically my question -- I know the installer *does*
<Mithrandir> no, it doesn't.
<seb128> Keybuk: maybe people use the network-admin tool
<Mithrandir> I suspect those people have used a tool themselves or are reports from breezy.
<Keybuk> definitely Flight 5
<bddebian> Heya
<Kyral> hey bddebian
<Mithrandir> Keybuk: very weird.
* Kyral waves as he goes to eat breakfast
<bddebian> Hi Kyral
<jdub> Keybuk: do we need to put in a setting in network-admin for autoconfigure?
<jdub> ie. bugger off all settings?
<seb128> jdub: network-manager you mean?
<jdub> doesn't make sense in the case where they're not using n-m though :(
<bddebian> infinity: Adding cpqarray to /etc/mkinitramfs/modules and doing update-initramfs -u worked.
<Keybuk> jdub: "enabled and dhcp" is sufficient for auto
<jdub> seb128: no, n-a, so /e/n/i settings can be removed
<bddebian> Thanks again ogra and Keybuk
<jdub> Keybuk: ah, ok
<Keybuk> it's when they add other settings like "use only this essid" that n-m buggers off
<jdub> right
<jdub> so, perhaps that would work then
<jdub> on the device page, put autoconfigure
<infinity> bddebian: Great, can you formally file a bug so I don't forget?  (It's 1:30am here)
<bddebian> Ouch
<jdub> (which would just autoconfigure really dumbly without n-m)
<bddebian> infinity: I'd be happy to but what is the "bug"?  Just adding cpqarray to initramfs?
<Kamion> Keybuk: how hard would it be to grow an option in nm-applet to let you say "no, really, manage this interface already"
<Keybuk> jdub: "Enable this connection", "Configuration: DHCP"
<Kamion> ?
<Keybuk> Kamion: VERY.  With extra figlet.
<Keybuk> nm-applet communicates to NetworkManager via dbus
<Kamion> yum
<Keybuk> it would involve a huge amount of pain
<infinity> bddebian: Yeah, "my hardware need cpqarray to boot, and you don't include it, you big jerk"
<bddebian> Hehe, OK
<Keybuk> and stuff *way* outside of my knowledge sphere atm
<jdub> Kamion: see, i'm basically asking the same question, but the other way around :)
<Kamion> but dbus is such a good idea and should be used for absolutely everything :P
* Kamion stops channeling Robot101
<Keybuk> dbus, like the rest of the GNOME and fd.o stuff is *so* well documented
<Keybuk> OH YES
<bddebian> infinity: Are main bugs in LaunchPad now?
<Keybuk> one day I'm going to get a very large hammer and explain to everyone that a file collating the comments above functions is *not* documentation
<dholbach> bddebian: yes
<bddebian> Heya Daniel
<infinity> bddebian: Have been for ages now.
* Kamion spots somebody who doesn't read ubuntu-devel-announce
<Kamion> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000054.html
<bddebian> Well I have been out of the loop for several months :(
<Keybuk> all I've found for dbus so far is a twisty maze of API documentation, with no hints about where to start, or even what the general purpose of any given set of functions is for
<Keybuk> and a tutorial/primer that's so out of date, *none* of the functions mentioned exist in the API anymore
<jdub> Keybuk: talk to Robot101 - i think he had some better stuff
<bddebian> infinity: Sorry, one last stupid question.  File it against initramfs?
<infinity> bddebian: initramfs-tools
<bddebian> OK, thx
<seb128> Mithrandir: what did you hack on for gdm?
<Mithrandir> seb128: the "focus the right window when starting up" bug I told you about.
<Mithrandir> seb128: only affects xinerama setups.
<seb128> right, I remember this one, you got a patch?
<Mithrandir> https://launchpad.net/distros/ubuntu/+source/gdm/+bug/28712
<Ubugtu> malone bug 28712 in gdm "gdm loses focus when mouse pointer is outside window (when initially started)" [Normal,Unconfirmed]  
<Mithrandir> yeah, there's a patch inline
<seb128> ah, nice
<seb128> I'm lagging behind on bugs mails atm
<Mithrandir> I also hacked a bit on libpam-tmpdir/gdm interaction since gdm installs a SIGCHLD handler which, well, is unfortunate when you run stuff and want to catch the exit status.
<tseng> pitti: i just made a patch for your beagle uri bug
<pitti> tseng: cool
<pitti> tseng: adding an autostart .desktop is certainly trivial as well?
<tseng> pitti: yep
* pitti hungs tseng, thanks
* tseng hugs pitti
<xhaker> Keybuk: do you happen to know if n-m allows one to specify the key index of WEP ?
<Keybuk> I would expect so
<Keybuk> I know about -> <- this much about WEP
<Keybuk> which is slightly more than I know about WPA :p
<Treenaks> WEP has 4 key 'slots'. n-m doesn't allow you to specify any key but the primary one.
<Treenaks> afaik
<xhaker> Treenaks: my point :S
<Treenaks> xhaker: But those other keys aren't necessary in 99% of cases
<Treenaks> xhaker: ime
<xhaker> i don't think they did that in the GNOME spirit, they're on crack
<Treenaks> (because you can just choose one of the 4 keys set in the AP to communicate with it)
<Treenaks> xhaker: no, it's just because not many people use it -- so it isn't high-priority for them to add it... I gues they'll gladly accept a patch.
<Treenaks> (probably)
<xhaker> you setup in the AP what key is used to associate with it.. if it's the second you have to specify the  second key an te index 2
<xhaker> in the app of course
<Treenaks> xhaker: you do? I could always select any of the 4 keys in the primary slot and it'd just work
<Treenaks> (and yes, all slots had a different key)
<xhaker> i'm having trouble implementing this feature on gtkwifi, UI wise.. asking for the key index in a dialog is wierd
<Treenaks> xhaker: So I think the original meaning of those key slots has been lost in the void
<Treenaks> xhaker: dropdown
<xhaker> in front of the key text entry ?
<Treenaks> xhaker: no, separate line, with a label 'Primary key
<Treenaks> '
<xhaker> i was thinking hiding it below with a ">"
<Treenaks> could do that too
<Treenaks> together with the _other_ 3 key entries
<xhaker> ohh.. you gave me an idea
<xhaker> have 4 key entry slots and 3 of the hidden
<xhaker> i just don't now what users would prefer
<Treenaks> xhaker: 1 key entry slot, 3 hidden
<xhaker> Treenaks: i have to code a mechanism that disables all entry slots when one has a key written
<Treenaks> why?
<xhaker> so i can send to the ap the right key index
<Treenaks> uhr...
<Treenaks> I still can't figure out what key index is for
<Treenaks> +the
<xhaker> Treenaks: i don't also really, it's like a second secret besides the key! :S
* Robot101 fwaps Kamion 
<Treenaks> xhaker: You can also enter 4 keys... that makes it even weirder
<xhaker> to associate you have to send the pair.. key-index & actual-key
<Treenaks> xhaker: I'd ask the network-manager mailing list about this if I were you
<Treenaks> xhaker: they must have some wifi gurus hanging around there too :)
<bddebian> infinity: Bug submitted, thx
<jdub> pitti: which files are the separated .desktop translations in?
<pitti> jdub: the normal application .mo files
<jdub> ahr
<pitti> jdub: that's where the .desktop translations come from in the first place
<pitti> jdub: (source package build calls intltool-merge for 'untranslated .desktop + .po -> translated .desktop'
<jdub> pitti: so loading the menus means opening every application .mo file?
<pitti> jdub: right, that's what we were concerned about when specing this
<pitti> jdub: but when I did the benchmarks with our implementation, it was negigible
<jdub> cool
<jdub> pitti: have you hit xdg with this idea?
<pitti> jdub: https://wiki.ubuntu.com/LangpacksDesktopfiles has the benchmark
<pitti> jdub: they know the idea, but I didn't show them our benchmark and implementation yet; I planned to, but I can do that closer to the release
<jdub> pitti: ok
<jdub> pitti: great
<pitti> when I have more time for discussion and less opportunities to fix bugs :)
<jdub> pitti: i'm just showing it to some gnome folks now
<janimo> Lathiat: ping
<Keybuk> pitti: is there any reason that dhclient would decide not to deal with an interface?
<Keybuk> does it do anything like check for link?
<pitti> Keybuk: I can't say off-hand, but I doubt it
<pitti> Keybuk: you allude to the bug that n-m sometimes doesn't get an IP with DHCP and uses a zeroconf one instead?
<Keybuk> no
<pitti> Keybuk: if I have my card in /e/n/interfaces, I never have problems with dhcp, just with n-m
<Keybuk> the fact that "ifup -a" on boot runs dhclient on the wifi card, when there's no associated AP
<Keybuk> instead of the one in the background running
<pitti> hm, no idea
<Keybuk> no, me neither
<pitti> but it should pick up an already running dhclient for an interface
<Keybuk> it's annoyingly hard to debug
<pitti> if not, that's a bug
<Keybuk> the problem is that there's no dhclient running for that interface
<Keybuk> it exits, rather than persisting
<Keybuk> and because if exists, ifup registers the interface as "down"
<Keybuk> s/if exists/it exits/  (damn, can't type)
<Keybuk> and because the interface is down, "ifup -a" tries to bring it up again, in the foreground
<xhaker> Treenaks: http://forums.macosxhints.com/archive/index.php/t-15556
<xhaker> Treenaks: i guess apple and gnome are trying to make people forget the other 3 keys
<seb128> ogra: what do you call "make preferences .desktop file an alternative" ?
<seb128> ogra: as in "update-alternative"?
<Treenaks> xhaker: because nobody uses them
<Treenaks> xhaker: (almost)
<xhaker> it's part of the standard though :/
<ogra> seb128, yep
<seb128> ogra: arg, DON'T
<ogra> seb128, why ? 
<seb128> back this off
<ogra> its the only possibility
<seb128> because that's abusing of alternatives
<ogra> thats the reason for alternatives 
<seb128> (and I hate alternatives, that's bug prone)
<seb128> ogra: no, that's not, the reason of alternatives is to make a default program on a generic name
<seb128> not to mask a menu item from GNOME menu
<seb128> that's so ugly and not needed
<ogra> seb128, then implement the masking upstream and others define, i'd happily use .merge files if we'd support them
<seb128> if you don't revert it I'll
<jdub> seb128: ogra is using alternatives for everything now :-)
<ogra> jdub, where its necessary, yes
<seb128> it's so not necessary here
<jdub> nor for distributor-logo ;-)
<seb128> we don't use one for distributor-logo, do we?
<ogra> seb128, so tell me whats the solution please
<ogra> seb128, nope
<jdub> seb128: no, but ogra wanted to ;-)
<seb128> ogra: I gave you one this morning which is good enough imho
* jdub hugs ogra 
<ogra> seb128, no, it isnt
<seb128> if people want xscreensaver under GNOME they can use the menu editor
<seb128> ogra: I've firefox and epiphany to my menu, should I make those an alternative?
<ogra> seb128, completely disabling xscreensaver doesnt make sense if i can solve it 
<seb128> alternatives for every .desktop party
<ogra> seb128, if they would produce 100% identical menu entries, i'd opt for an alternative for ff and ephi, yes
<seb128> change the icon for one of those then
<ogra> so the installed and preferred one is in the menu
<seb128> if that's your only issue
<ogra> nomeata, it isnt
<ogra> grr
<jdub> nice problem
<ogra> nomeata, it isnt
<ogra> ARGH !!!
* jdub thinks
<xhaker> seb128: i do think the browser should not be made an alternative.. but the first panel button should point to the default gnome browser set in preferences
<jdub> hrm, can't use TryExec testing
<seb128> xhaker: already discussed
<xhaker> seb128: it was?
<xhaker> seb128: any logs?
<jdub> ogra: i like this problem
<seb128> xhaker: yep, ubuntu-desktop list
<ogra> jdub, i can exec both if both is installed, i doubt that would solve it
<seb128> mask xscreensaver by default
<jdub> ogra: no, that's why i said "can't use TryExec testing" :)
<ogra> jdub, there is a solution in xdg we dont have impelmented
<seb128> and let people unmask it :)
<jdub> seb128: you are a fascist!
<xhaker> haha
<seb128> jdub: and you like that :p
<seb128> no? :)
<jdub> seb128: hater of cute things and freedom!
<sladen> seb128: even better, you could mask *both* of them.  Then the user wouldn't get confused at all...
<xhaker> especially cute things
<jdub> seb128: lover of fish smelling things!
<ogra> jdub, xdg apparently can use .merge files it merges in the directory files dynamically, there you can include <Include>/<Exclude> directives for entries, redhat uses that for xscreensaver
<seb128> sladen: go troll somewhere else
<seb128> jdub: hum
<jdub> ogra: and, interestingly enough, one user on the system might use xscreensaver, another might use gnome-screensaver
<ogra> sladen, right, since you cant configure the hacks anyway, we could hide the whole configuration ;)
<ogra> jdub, hmm, right ... thats where the alternative fails ...
<ogra> i'm pretty sure the xdg variant would at least work with the menu editor ...
<jdub> ogra: .desktop attribute for "is blah running?" ;-) ;-)
<seb128> having an alternatives for that is not a good idea anyway
<ogra> globally it is ...
<ogra> but jdub is right, individually it breaks
<jdub> ogra: it really isn't what alternatives are meant to be used for though
<ogra> alternatives are used if i have the same file in two packages and want one to be the default, no ?
<ogra> (and want to avoid conflicts)
<Treenaks> ogra: diversions too
<janimo> ogra, why is x-s-s a problem for gnome, is it part of ubuntu-desktop?
<Treenaks> janimo: you don't want both g-s-s and x-s-s running
<xhaker> jdub: you're worse than ogra https://lists.ubuntu.com/archives/ubuntu-desktop/2005-December/000031.html
<janimo> Treenaks: I know but since it's not in the default install why care?
<janimo> or why is k-s-s not in the mix as well?
<janimo> assuming kde has it's own ss
<ogra> because users want to be able to switch back easily to xscreensaver ...
<ogra> k-s-s isnt involved here
<janimo> ogra, so g-s-s is not ready?
<Treenaks> because KDE doesn't like freedesktop standards?
<ogra> janimo, huh ? 
<dholbach> janimo: "linux isn't ready"
<janimo> ogra: why would people consider switching back to x-s-s?
<ogra> janimo, because some want 1000% configurability of everything 
<ogra> g-s-s doesnt (and brobably will never) offer this
<janimo> those are l33t users they will know hwo to figure ot that g-s-s and x-s- do not mix well
<ogra> janimo, they arent
<Treenaks> janimo: it should Just Work
<pitti> well, the most important config options would be enough already...
<janimo> if they arent why do they want ocnfigurabilty 
<janimo> beyind normal
<ogra> l33t users edit /usr/share/gnome-screensaver/themes/*.desktop
<sladen> ogra: could you use the same detection code as for the 'xscreensaver-command' wrapper and use that load the appropriate configuration dialogue.  (eg. Hide both of xscreensaver and gnome-screensaver and then have a pain  Configure Screensaver  wrapper)
<jdub> ogra: (i think g-s-s may do per-hack config at some stage)
<janimo> can't both be patched to watch for some lock in var/lock and do not start if others running or similar?
<ogra> sladen, one is a menu entry and should be properly handled by gnome-menu or xdg, the other is a binary wrapper ...
<xhaker> janimo: they might be running side y side
<ogra> janimo, you dont understand the prob
<janimo> ogra: apparenly not :)
<ogra> its only about .desktop entries
<janimo> aha
<janimo> got it
<ogra> has nothing to do with what starts or not
<ogra> sladen, i'd prefer an alternative to a wrapper in your example ...
<ogra> jdub, not before dapper+1 ... and i'm not allowed to add the preview button patch util upstream adds it as well ...
<ogra> so these features will be missing for dapper
<jdub> ogra: no, i mean, i think upstream will end up doing g-s-s per-hack config
<ogra> jdub, they dont seem fond of it yet ...
<jdub> no, but they will :)
<ogra> (and its *very* tricky if you work across xscreensaver/gnome-screensaver, i have half a patch ready here)
<seb128> jdub: you will use your clue bat for that? :)
<ogra> seb128, so will you fix xdg or can i keep my alternative ? 
<ogra> :)
<seb128> ogra: you will get your alternative out
<jdub> ha ha
<ogra> seb128, and proper xdg handling in ? 
<seb128> ogra: what do you call proper xdg handling?
<seb128> we have proper xdg handling
<CarlFK> I am trying to compose a bug report and stuck on a silly word problem: what do you call the text "About" in regards to an apps Help About menu choice?
<seb128> and I've just checked, FC5 has no gnome-menus patch
<ogra> seb128, being able to use the defined features from the xdg spec
<CarlFK> Label, prompt, menu text...?
<seb128> CarlFK: what is the bug about? seems duplicatish
<jdub> CarlFK: string
<CarlFK> seb128: "there should be consistancy between menu string and dialog titles."
<CarlFK> don't like string...
<seb128> CarlFK: for what app?
<CarlFK> synaptic
<ogra> seb128, from redhats gnome-screensaver.spec: install -D -m644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/xdg/menus/preferences-post-merged/gnome-screensaver-hide-xscreensaver.menu
<CarlFK> https://launchpad.net/malone/bugs/34361
<Ubugtu> malone bug 34361 in synaptic "repo win titled "software preferences"" [Normal,Unconfirmed]  
<ogra> seb128, and gnome-screensaver-hide-xscreensaver.menu contains the proper  <Exclude> directive
<seb128> ogra: that doesn't seems a change for "proper xdg handling"
<seb128> where is the patch or feature they have and we don't have?
<ogra>  /etc/xdg/menus/preferences-merged/ is defined for us, but ignored if i put a .menu file into it
<desrt> typo on the ubuntu website: http://www.ubuntu.com/community/participate/ "...you should contribute to the Art team who on icons, themes."
<ogra> seb128, for our preferences.menu file:   <!-- Read in overrides and child menus from preferences-merged/ -->
<ogra>   <DefaultMergeDirs/>
<ogra> preferences-merged is ignored
<Riddell> Treenaks: that's nonsense and quite insulting
<Treenaks> Riddell: That's what I understood from reading comments on freedesktop.org mailing lists, sorry.
<Treenaks> Riddell: so 'This is my opinion'
<ogra> Treenaks, wrt screensavers, there is simply no f.d.o standard yet that rules screensaver handling, configuring etc ...
<Treenaks> ogra: I thought this was re: autostart
<ogra> so you could say gnome doesnt respect f.d.o as well ... if it come to screensavers
<ogra> its only about the menu entries
<Riddell> Treenaks: you are talking rubbish, kde had autostart long before gnome, we created the spec (not a standard), but have not implemented the final spec since we have not had a release 
<seb128> ogra: seems that moving the  <DefaultMergeDirs/> just before the "  <!-- Menu items to exclude from the toplevel -->
<seb128>   <Exclude>
<seb128>     <Filename>gnomecc.desktop</Filename>"
<seb128> ogra: does the job
<seb128> ogra: from /etc/xdg/menus/preferences.menu
<ogra> seb128, ah, cool, will test that ...#
<ogra> :)
<sivang> sladen: http://muse.19inch.net/~sivan/upbackup/
<sivang> sladen: let me know if this is okay, you can also fetch it from your account I suppose :)
<mdz> seb128: do you know what is causing that problem where logging out stalls?
<seb128> mdz: no, but I had it 2 times yesterday, it's on my list to stuff to investigate ...
<mdz> seb128: I've seen it on my laptop as well; seemed to happen after an upgrade and then not the next time
<seb128> I'm inclined to blame gnome-panel or libbonobo
<mdz> seb128: I saw it on Jane's machine yesterday as well
<mdz> seb128: and then just now a different weird problem
<mdz> she logged out, logged back in, and got the "panel already running" dialog, then no panel
<seb128> mdz: "weird", beeing "panel already running" we discuss on the other chan?
<mdz> seb128: yes
<mdz> which channel?
<seb128> #canonical
<seb128> oh, you are not here
<mdz> right, my xchat doesn't autojoin me
<seb128> <seb128> jbailey: sometime gnome-panel doesn't exit with the session
<seb128> <seb128> so when you log again you get 2 of those
<seb128> <seb128> and they are not friends
<mdz> right, exactly
<mdz> her old gnome-panel process (and a bunch of other stuff, bonobo, esd, etc.) was still running from the previous login
<seb128> I had a quick discussion with vuntz about it yesterday
<seb128> I'll probably work on it tomorrow or monday
<Keybuk> Dear X-Chat.  Please stop SEGVing.  kthxbye
<bddebian> heh
<sivang> hehe
<mdz> seb128: thanks
<seb128> np
<mkde> dapper is to be referred to as 6.06 right?
<ogra> 6-06
<mkde> oh?
<mkde> that's a change from previous conventions, isn't it?
<ogra> yep
<mkde> right, thanks
<ogra> dont ask me, i didnt make the change :)
<ogra> but Keybuk has arguments for it iirc :)
<jdub> ew
<mkde> np, I'll tell the documentation team
<ogra> and sabdfl wanted it as well ...
<mkde> is it decided?
<ogra> Keybuk, ?? ^^ was there consensus abou tthe new versioning scheme 
* ogra isnt sure anymore ... so many changes the last days
<Keybuk> we haven't discussed that
<Keybuk> ask mdz or sabdfl :)
<ogra> it was mentioned several times during all three meetings iirc
<mkde> how about you guys decide, and let the docteam know?
<sladen> Keybuk: I thought the most famous program you're known for writing is an IRC boucer---can't you stick that between XChat the teh intraweb?
<ogra> mdke, pfft that would be to easy :P
* ogra is out for a moment ... bbl
<mkde> is the naming convention to be changed on the website restrospectively? like 5-04, 5-10?
<Keybuk> sladen: I wouldn't say it's the most famous
<sladen> Keybuk: most-widely-installed-by-script-kiddies
<Keybuk> I don't like IRC bouncers though <g>
<natroll-> what's IRC bouncer?
<seb128> mdz: seems that your ogg stations don't work
<kagou> hi
<seb128> mdz: http://ubuntu.hbr1.com:19800/house.ogg by example
<natroll-> i assume something nasty
<mdz> seb128: was working for me when I sent it; I tested first
<Kamion> mkde: I doubt that
<seb128> mdz: it stopped working so :)
<seb128> mdz: http://radio.hbr1.com:19800/house.ogg works fine, http://ubuntu.hbr1.com:19800/house.ogg doesn't
<mdz> seb128: I will mail them
<seb128> mdz: ok, should I use radio.hbr1.com for now?
<seb128> or delay that change time they fix it?
<seb128> or push it now assuming they will fix it quickly? :)
<Kamion> doko: why the extra grub upload? I had already demoted ia32-libs-dev to an alternative build-dep that wouldn't be used
<doko> Kamion: looking ...
<doko> hmm, you are right, not necessary
<mdz> seb128: whatever is easiest for you
<mdz> seb128: just don't forget to change it before release if you use radio ;-)
<seb128> mdz: I've already done the patch, so I'll list them, if they don't fix them I'll drop before dapper
<seb128> s/drop/drop it
<mdz> seb128: the URLs they gave me were .m3u and .pls
<mdz> seb128: but we need the actual stream URLs, right?
<seb128> correct
<seb128> http://ubuntu.hbr1.com/
<seb128> those .mm3u have radio.hbr1.com
<seb128> .m3u
<mdz> seb128: right
<mdz> I've just mailed them
<seb128> k
<fabbione> Kamion: ping?
<mdz> fabbione: there is a strange comment at the top of /etc/init.d/rc.local
<fabbione> mdz: uh such as?
<Kamion> fabbione: hi
<fabbione> mdz: i did copy it almost pristine from another script
<fabbione> Kamion: i was just reading the -meeting report.. i am sorry we misunderstood eachother.. 
<fabbione> Kamion: should we look at it again?
<Kamion> fabbione: no worries - to clarify, you expect me to upload that, right?
<Kamion> which is fine by me
<fabbione> Kamion: my understanding was that i did give you the core functionality and it is working
<fabbione> Kamion: and that you were going to cleanup the strings before upload
<Kamion> http://people.ubuntu.com/~fabbione/pa.diff is the current diff, right?
<fabbione> Kamion: there is only line from that patch you need to change
<fabbione> Kamion: yes
<Kamion> what do I need to change? just the changelog?
<fabbione> Kamion: the changelog and one debugging line
<fabbione> just one sec.. i am searching the line
<Kamion> I had a look, couldn't see it
<fabbione> it's the one that forces to show always the disk selector
<fabbione> we want to see the disk selector only if there is more than a disk
<mdz> fabbione: yes, but the information in the comment doesn't apply to the script
<fabbione> mdz: ok, that's easy to remove
<fabbione> Kamion: gimme 2 minutes and i will fix it for you. i can't find it either.. i might have lost it somewhere by mistake
<Kamion> +# if preseeded we don't ask_for_disk.
<Kamion> +if [ -z "$dev" ] ; then
<Kamion> +    STATE=1
<Kamion> +else
<Kamion> +    STATE=2
<Kamion> +fi
<Kamion> that logic seems the wrong way round, so maybe if I change that -z to -n then it'll be fine?
<fabbione> Kamion: no the logic is fine...
<fabbione> new patch is up
<fabbione> you set the STATE=1 if device is empty and so you ask for it
<fabbione> the new patch will ask for the device only if there is more than one
<Kamion> oh, yeah, misread
<fabbione> but..
<fabbione> hold on.. i am tired..
<fabbione> sorry
<Pygi> _ion: ping
<fabbione> Kamion: ok.. this patch should be good
<fabbione> +# if there is only one device and we are not preseeded
<fabbione> +# we autoselect the device, skip the question
<fabbione> +# and jump to the next.
<fabbione> +if [ $count -le 1 ]  && [ -z "$dev" ] ; then
<fabbione> +  STATE=2
<fabbione> +  dev="$devs"
<fabbione> +fi
<fabbione> that's the diff basically from the one you had
<Kamion> looks reasonable
<Kamion> I'm finishing up for the night soon, but I'll look at it tomorrow morning
<Kamion> thanks again
<fabbione> Kamion: sorry again for the misunderstanding..
<fabbione> i didn't mean to block you at all :/
<fabbione> mdz: i am fixing the comment in a few minutes.. i need to rsync the local mirror first
<Kyral> Is there a meeting going on?
<xhaker> Kyral: no?
<Kyral> hmm
* Kyral shrugs
<ogra> seb128, right, that fixes it, do you want to add the dir and change of preferences.menu to gnome-menus or are you ok with me doing it (i'd like to get rid of the bug)
<seb128> ogra: I would like to understand why we need to do that and not fedora
<ogra> hmm
* ogra looks at the fedora files 
<seb128_> <ogra> hmm
<seb128_> <seb128> ogra: I would like to not change the conffile if not required too
<seb128_> --- Disconnected ().
* ogra looks at the fedora files 
<ogra> was below the hmm :)
<ogra> fedora has no direct call of an Exclude directive in the preferences.menu file itself ...
<ogra> we supress gnomecc in there ...
<seb128_> ogra: should not make a difference
<ogra> it doesnt, just tested
<seb128_> and the gnome-cc is upstream stuff
<seb128_> no distro patch
<ogra> the only distro patch touching the file is 01_preferences-legacydir.diff
<ogra> removing that makes no difference either ...
<joelbryan> the irony of today's gnome image viewers... in gthumb's about dialog says "An image viewer and browser for GNOME.", but has cataloging capabilities, in eog's about dialog says "The GNOME image viewing and cataloguing program.", but can't do any cataloging stuff. sometimes I think eog should be removed..
<joelbryan> what's the big difference between eog and gthumb?
<joelbryan> gthumb can do what eog does
<Burgwork> eog is a basic viewer, nothing more
<Burgwork> and removing it would be bad, trust me
<joelbryan> ok
<Burgwork> my FC4 box at work doesn't have eog and it sucks
<joelbryan> speed is a plus factor for eog.
<joelbryan> and the next and back button, before I hate eog, but with the new button, I'm kinda liking it.
<joelbryan> gthumb is comparible to microsoft office picture viewer, while eog is like windows picture viewer for fax and image
<kent> Finns det ngon skiva med fri programvara fr windows? 
<kent> helst p svenska..
<joelbryan> i'm just posting my past thoughts.. :-) it's what I posted before in fedora mailing lists. just think the irony of their about descriptions.
<Treenaks> kent: Please use 
<Treenaks> kent: English
<kent> sorry, wrong channel. :(
<joelbryan> I'm made a simple interface handling irc:// links for gaim, do you think it'll get approved, it's very simple app, just dialog with text inputs and a button, and currently I'm trying to put a checkbox for the app not to run gaim automatically.
<Treenaks> no, we're past feature freeze
<joelbryan> someone just told me that gaim doesn't handle irc:// links, so I made this app.
<Pygi> joel: perhaps for dapper+1 ;)
<joelbryan> cool!
<joelbryan> I'm trying to help rhythmbox to write to ipod.
<Pygi> joel: xchat-gnome handles irc...isn't that enought, at least for now? ^^
<Burgwork> Pygi, not part of the default desktop anymore
<Pygi> Burgwork: o, really? since when? :-/
<cassidy> and it's a shame ! :p
<Pygi> cassidy: agreed
<joelbryan> Pygi: isn't it xchat-gnome will not be included in dapper, oh well, just wishful.
<Pygi> and what is gonna replace xchat-gnome? don't tell me Gaim IRC capabilities ???
<joelbryan> dapper rocks!, it's now my no.1 favorite opensource software, no.2 is drupal.
<joelbryan> drupal 4.7 also rocks!
<cassidy> Pygi: it seems. It sucks, i know :\
<Pygi> cassidy: O joy, whatever :-/
<Pygi> cassidy: with what update does it come? so I don't do the upgrade ^^
<cassidy> Pygi: if you have x-g installed, it will not be removed
<cassidy> ubuntu-desktop just doesn't depend on it anymore
<cassidy> so it's not installed by default
<Pygi> cassidy: joy ... :-/
<joelbryan> when I first tried gaim's irc for the first time, I liked it alot than xchat-gnome, that's why I think xchat-gnome is a duplicate.
<Burgwork> gaim doing irc has nothing to do with removing x-g from the desktop
<joelbryan> is a "Show All" button in logout dialog a feature? coz I also made some modifications with the logout dialog to display less icons.
<joelbryan> then why not install epiphany since it also handles http://
<Burgwork> umm, it is duplicative of firefox?
<joelbryan> yeah, same with x-c and gaim
<Pygi> joelbryan: for that cause, why not Flock ? ^^
<joelbryan> what's flock?
* Pygi wants no religious wars :-)
<joelbryan> me too
<Pygi> joelbryan: google ;)
<joelbryan> sorry.
<joelbryan> anyone using meld, it's awesome.
<joelbryan> awesome, does flock uses gtkhtml extensively instead of mozengine?
<Burgwork> joelbryan, Pygi this is wandering into offtopic, please keep it focused here
<Pygi> Burgwork: yup, sorry
<joelbryan> me too, sorry
<LaserJock> Seveas: ping?
<mdz> seb128: already a 2.14.1 of gedit?
<dholbach> mdz: we had some other "quick fixes" already :)
<dholbach> mdz: for the rough edges :)
<joelbryan> I tried editing metacity schema using gedit and my pc just hangs, should there be a way for the desktop to be honest, they are running out of memory?
<joelbryan> I think there should be a way to say "honestly I would like to tell you that you are running out of memory and I won't continue loading this application, so I'll just save the changes you have made.and exit the program", this somehow fixes alot of things. (e.g. inkscape memory hog)
<joelbryan> _somehow_
<mario_> _ion: ping
<Lutany> pong
<Pygi> Lutany: ?
<Lutany> :-)
<sharms> shouldn't deskbar automatically install beagle (without it it seems rather useless?)
<Burgwork> sharms, far from it
<sharms> on default dapper install deskbar is available, but does nothing in default installed condition
<sharms> it will, despite it telling you it does, not index your home directory etc
<sharms> that seems like a bug to me
<Pygi> sharms: mono is NOT YET in main
<Pygi> and beagle is not stable enough
<Burgwork> Pygi, umm, yes it is
<sharms> so maybe deskbar shouldn't be in the default install until it is primetime?
<Pygi> Burgwork: buh, I am lost lately :-/ too much "not sleeping"
<sharms> because if the dapper pause is 6 weeks to polish, this is definately a polish issue
<sharms> a component not working and doing what it says it does is a polish issue
<Pygi> sharms: well, at least, beagle is not stable and tested enough
<Burgwork> sharms, there are two issues here
* Pygi should take more sleep 
<sharms> so maybe deskbar should not be included with dapper
<Burgwork> one: everything is turned off by default in dapper
<Burgwork> two: beagle not installed by default
<Burgwork> the first can be fixed without the second
<Burgwork> please file a bug on the first
<sharms> thats what I was going to do
<sharms> I just figured I would run it by you guys
<sharms> and making sure I am not blind
<MrFaber> Anyone experiences problems with cpu scaling in dapper?
<sladen> MrFaber: if _you_ have problems with power-scaling, could you file a bug please :)
<Seveas> LaserJock, ?
<LaserJock> Seveas: do happen to know anything about the @ubuntu.com email addresses?
<jpatrick> you missed a word there
<Seveas> LaserJock, if you're a member you get one that forwards to your prefered address in LP
<LaserJock> Seveas: I changed my preffered email address but it still is forwarding to the other address
<LaserJock> Seveas: I even took the old address off LP and it is still forwarding
<Seveas> for that to change you may need to poke $someone
<LaserJock> Seveas: and do you know who $someone might be? :-)
<Seveas> iirc elmo
<LaserJock> hmmmm
<Pygi> _ion: are you alive actually? ;)
<trappist> where should I complain about mailman, or something else on lists.ubuntu.com, breaking gpg signatures on some emails?
<bddebian> Is there a wiki on creating a mirror?
<Burgwork> jdub, why has there been no official statement about the dapper delay yet?
<Seveas> Burgwork, both CC and TB have to approve all official statements
<Seveas> (about this)
<Burgwork> Seveas, the decision has been made though, no?
<Seveas> if so, it will be announced
<bddebian> Should debmirror work for us?
<HiddenPuppy> Seveas: Burgwork, there is a draft delay announcement on the wiki
<HiddenPuppy> by sabdfl
<mdke> it's running late, Burgwork is right
<Fujitsu> Well, it's been decided...
<kalphegor> how can i help ubuntu with a wallpaper? maybe default wallpaper for Dapper :) is there any visual/art team?
<Burgwork> kalphegor, #ubuntu-art I believe (it might be -artwork)
<TMM> hi all!
<kalphegor> thanks
<tseng> hi Burgwork 
<minghua> Burgwork, kalphegor: it seems to be -artwork
<Burgwork> salut tseng 
<TMM> can someone help me out with cdbs and simple-patchsys? I am trying to apply a patch, that just works cleanly when I operate the normal 'patch' command, and, I have looked at  simple-patchsys.mk and I have extracted the line that does the actual patching, and THAT works as well, but it fails from 'fakeroot dpkg-buildpackage'
<TMM> any ideas? :)
<Treenaks> TMM: use cdbs-edit-patch :)
<tseng> you'll have to be more specific about how it fails
<tseng> Treenaks: thats not useful, a plain diff -ruN would be fine if he started at the top of the souce tree
<TMM> tseng: it fails at all patchlevels with the oh so common 'can't find file to patch at input line 6' which would only make sense either the  $(DEB_SRC) was wrong
<tseng> TMM: yeah
<tseng> did you diff from the top level
<tseng> or did something weird
<TMM> tseng: they are suse patches, from a source-rpm
<tseng> diff -ruN fooapp-0.2.old fooapp-0.2.new
<TMM> tseng: that's apparently what they did, because the diff header looks like they did :)
<TMM> tseng: wait, they should be done with the -R flag?
<TMM> --- linux-iscsi-4.0.1.orig/Makefile     2004-02-09 11:42:27.000000000 +0100
<TMM> +++ linux-iscsi-4.0.1/Makefile  2004-05-25 10:45:26.000000000 +0200
<TMM> that's what the header looks like.... probably not -R then
<tseng> if i eat my words you could do cdbs-edit-patch 01_patchname.diff
<tseng> which gives you a fake shell
<tseng> apply the patch with 'patch'
<tseng> and exit the shell
<TMM> owww... do I have to? there are 15 of 'em :)
<tseng> i see.
<TMM> what if I just run a script of the patches to change all the +'s to -'s and vice-verse? :)
<TMM> wait... that's not going to work
<tseng> linux-iscsi-4.0.1
<tseng> this is the name of your folder?
<TMM> yes
<TMM> but, that should work fine with -p1 right?
<Burgwork> Kamion, do we need a sign "No feeding the fish?" :)
<_ion> pygi: Pong.
<_ion> Just woke up. :-)
<Pygi> _ion: K, will talk later then?
<TMM> what would me the chances of getting iscsi support into the -server kernel before dapper releases? slim? extremely small? near-zero? :) it pretty much doesn't touch any files, it just adds a couple
<Pygi> TMM: #ubuntu-server
<Pygi> and I would guess "zero" :)
<_ion> pygi: Now's okay.
<TMM> Pygi: you are probably right, I only just noticed today it isn't in there, and, I feel it is a pretty darn nasty omission :)
<Pygi> _ion: we should patch drivers as well, you know that?
<_ion> pygi: For WPA support?
<Pygi> _ion: yup, and 802.1x 
<Fujitsu> 802.1x will be supported?
<_ion> pygi: Oh.
<Pygi> Fujitsu: nothing will be or was ever supported ;)
<Fujitsu> Why not?
<Pygi> Fujitsu: 'Cause if I tell you anything now, I would have to shoot you ;)
<Fujitsu> Is it in the works?
<Pygi> _ion: and kernel freeze is in a week (I guess so), so we should do that ASAP
<Kamion> Burgwork: we're discussing the announcement now, shouldn't take too long
<Pygi> if we want it done
<Pygi> Fujitsu: read up :)
<TMM> tseng: do you have any ideas?
<TMM> tseng: or is re-applying all the patches manually the only way (r)?
<tseng> none that i havent thrown out there
<_ion> pygi: Anyway, (this isn't confirmed yet!) the essential patches from the 0.5.1 package should be ported to 0.6.1 now.
<mdke> Kamion, is the timetable fixed?
<Burgwork> _ion, you are a god
<_ion> pygi: I take it someone has already made the patches for the drivers?
<Kamion> mdke: yes
<Fujitsu> That's a yes, I take it... I really need EAP-TLS for NetworkManager to be useful :(
<Pygi> _ion: yes, we should just apply it.... they are on n-m list...
<Kamion> see DapperReleaseSchedule
<_ion> pygi: Ok.
<mdke> Kamion, i'm not very happy with the doc freeze, any scope for negotiation?
<Fujitsu> UserInterfaceFreeze is ages away, I notice, which is good.
<Pygi> _ion: so that should be our priority for now...what do you say
<Kamion> mdke: talk to the TB about that sooner rather than later
<Pygi> ?
<mdke> Kamion, I sent a mail early this morning
<Kamion> mdke: don't need to wait for a meeting, just grab them
<_ion> pygi: Yep, i agree.
<Kamion> I imagine that there is some scope there
<mdke> Kamion, have you got any to hand?
<mdke> mjg59, ?
<Kamion> mdke: no, sorry
<mdke> Kamion, :)
<Pygi> _ion: we should check when exactly kernel freeze is...
<Kamion> in fact I'm about to go for the evening
<Pygi> Kamion: perhaps you know when is dapper kernel freeze?
<Kamion> Pygi: DapperReleaseSchedule, I mentioned it just a few lines up
<Fujitsu> May 18.
<Pygi> Kamion: ah, thx
<mdke> Kamion, have a nice evening, what is left of it :)
<Kamion> my wife likes to see me occasionally
<mdke> be off with you
<Pygi> _ion: please take a look at https://wiki.ubuntu.com/DapperReleaseSchedule, I am unable to find kernel freeze ??
<Kamion> Pygi: try the "find" function in your browser
<_ion> pygi: As fujitsu said, May 18th.
<Pygi> Kamion: heh
<Pygi> _ion: huh, kk
<Pygi> _ion: so, are we going to apply patches against all drivers that can be found on n-m list?
<Pygi> _ion: and it would be really great, if we could pull of the 802.1x as well
* Fujitsu encourages.
* Fujitsu will help if necessary.
<_ion> I'd like to see how big/complex those patches are. I tried to search for "patch" in http://mail.gnome.org/archives/networkmanager-list/ but didn't get any results. Do you have an URL?
<_ion> Yeah, it'd be great.
<Pygi> Fujitsu: hehe ;)
<TMM> tseng: reapplying it is then...
<_ion> Seems like the search function is b0rken at that page.
<Fujitsu> b0rked?
<Pygi> _ion: heh :-/
<_ion> http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00134.html "madwifi-ng driver fix"
<_ion> A quite simple patch.
<Fujitsu> How is ipw2200?
<Fujitsu> That's outrageously short!
<Pygi> _ion: yup, I know...but there are more patche
<Pygi> patches* that we need to apply
<Pygi> _ion: from Seveas: you need the patch from Robert Love (various collected workaround) and a patch from dan williams to make madwifi-ng report wpa capabilitues
<Seveas> (and you need to convince a lot of people that Ubuntu should switch to madwifi-ng)
<Seveas> (or port the latter patch to madwifi-old)
<Seveas> the madwifi patch: madwifi.org/ticket/444
<Seveas> the other was sent to the list on march 3rd 15:35 UTC
<Seveas> (not to discourage you, but I am following that list quite closely and would be surprised if you can get it to work reasonably well)
* Pygi searches for 2nd patch
<Pygi> _ion: found second patch perhaps?
<Pygi> _ion: or is it the one we found earlier on the list?
<Lathiat> JanC: ping
<Lathiat> janc: unping
<Kyral> lol
<JanC> 
<Lathiat> (meant to type janimo, offline so tab complete failed me :)
<_ion> pygi: Hm, there's some patch in here. http://madwifi.org/attachment/ticket/275/active-scan.patch
<_ion> Linked from http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00112.html
<Pygi> _ion: that should probably be applied as well to enable 802.1x support
<_ion> Here's the patch from Robert Love. http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html
<Pygi> _ion: most patches seem rather simple, so it shouldn't be a problem
<_ion> Yep.
<Pygi> disable-named-and-vpn-managers should be ported rather soon
<_ion> Oh, i ported it.
<_ion> I sent an email.
<doko> mjg59: elilo ping
<Pygi> _ion: o joy, you took my job :-P
<_ion> :-)
<Pygi> _ion: so we have applied all ubuntu patches now?
<_ion> It would be nice to receive confirmation that the ported/recreated patches in the package are indeed okay.
<_ion> Hm, let me see.
<_ion> (Or, if they aren't, then we can fix them.)
<Pygi> _ion: yes, but we can't know that until we patch drivers, and test it  out
<_ion> Here's the patch situation: 10-dbus-api-fix: already in upstream. 20-linux-wlan-ng: "< pitti> _ion: 20-linux-wlan-ng.patch is my hack, if the others are cleared with Keybuk, then I will port that one". 30-blacklist-devices: not ported. 40-ubuntu-backend: ported, but waiting for confirmation from Keybuk. 50-disable-named-and-vpn-managers: ditto. 60-dispatch-more-events: not ported; looks like easy to port. 65-dispatcher-script-dir: ported. ...
<_ion> ... 70-dont-deactivate-new-devices: ported.
<Pygi> hm, k, so a few more to port
<mdke> mjg59, when you come back, could you take a look at my mail about the doc freeze for 6.06, and maybe response / poke another TB person on it? Thanks
<Pygi> _ion: all those are essential I suppose?
<_ion> pygi: AFAIK 40-ubuntu-backend and 50-disable-named-and-vpn-managers were the *really* *essential* patches, but the others are there for a reason, so they probably should be ported as well.
<Pygi> _ion: k, agreed
<Pygi> _ion: can we get it all done by monday/tuesday perhaps, so we could put it for massive testing/reviewing?
<_ion> Probably.
<Pygi> k, great
<_ion> I'll probably port 60-dispatch-more-events today, it seems very easy.
<Pygi> _ion: my today is almost over ;)
<_ion> Well, it's 00:29 here, but i woke up a while ago. :-)
<Pygi> _ion: oh, 1 hour difference ;)
<_ion> I might look at the blacklist stuff as well, if i'm not too tired.
<_ion> I have been sick for quite a while, so i don't have very much energy, but i'll see what i can do.
<Pygi> lemme see the blacklist patch
<_ion> Ok.
<Pygi> just rest, I can do some things as well
<holycow> hey all
<holycow> is sabayon being actively considered in ubuntu on any level? 
<_ion> 30-blacklist-devices.patch is simple, but it probably depends on some stuff from 40-ubuntu-backend.patch. I.e. in order to get that blacklist stuff working one needs to port it from both of those patches.
<kent> holycow: its installed on my Dapper-computer. So I assume the answere is yes.  But read the topic about support
<Seveas> sivang, ping
<Burgwork> holycow, as part of gnome, it is available
<Burgwork> holycow, it is not designed to be installed on every desktop
<holycow> kent, indeed and noted, was curious where that project is going as its hard to get a peep out of anyone on that end of things
<Pygi> _ion: kk
<holycow> Burgwork, *nod*, we are piloting ubuntu here and wondering if ubuntu is considering it as 'nice to have' or 'integral part' of the desktop experience
<Burgwork> holycow, sabayon is not the kind of project which attracts a lot of people
<Burgwork> holycow, I would put it in the middle
<holycow> okay
<holycow> cool, good to get an opinion on this :)
<Burgwork> holycow, I believe there is nobody working full time on sabayon
<holycow> thats what it seems like *nod*
<Seveas> Burgwork, would you mind coming to #ubuntu-meeting for a second?
<holycow> thanks for the info Burgwork 
<Burgwork> holycow, np
<Pygi> _ion: time to sleep...if you need anything , please mail me,ok?
<_ion> pygi: Yeah, will do. G'night. :-)
<Pygi> night to you as well _ion
#ubuntu-devel 2006-03-22
<Seveas> _ion, ping
<_ion> seveas: Pong.
<Seveas> _ion, the madwifi-ng patch required for wpa seems to work for madwifi-old too
<Seveas> you need to patch manually, but the spot is easy to locate
<_ion> Ok, thanks.
<Seveas> that combined with robert love's NM patch should give you something much more usable
<_ion> Yep.
<Burgwork> http://www.kdedevelopers.org/node/1868  <-- funny
<LaserJock> Burgwork: lol
<jdub> wow, beineri actually is an all-round prick
<Seveas> jdub, wouldn't know about the shape, but yeah...
<tseng> yay for trolls
<Burgwork> personally, I think it is funny
* jdub is sick of the guy
<xhaker> it is.. but it was not meant to be.. so i think it's abusive
<jdub> hard to find it amusing when you know it's not done for amusement value alone
<Burgwork> I don't have history
<Burgwork> ie, I haven't seen what he has produced before
<xhaker> who here thinks is more ripped off (in the internet bill) than me?
* Kinnison is currently paying 20 EUR/day for utter crap
<Kinnison> well, canonical are
<Fujitsu> Where are you, Kinnison, and why is it so expensive!?
<Kinnison> london
<Kinnison> orange wireless
* Kinnison is at the launchpad sprint
<Kinnison> :-)
<Fujitsu> Ahh
<Fujitsu> What's happening there?
* xhaker pays 43 euro for 512kbits cable (13GB traffic limit)
<Kinnison> Lots of Soyuzery in my case
<Kinnison> xhaker: that's a bit expensive
<Fujitsu> It is pretty expensive...
* Fujitsu is really annoyed.
<Fujitsu> AU$49.95 per month, 10Mbits cable...
<Fujitsu> Wait for it...
<Fujitsu> 1GB traffic limit.
<xhaker> Portugal is so messed up with price fixing in broadband :( 
<xhaker> 1GB?
<Fujitsu> I could download that in less that 10 minutes!
* Kinnison does more than a gig a day on a good day
<xhaker> Fujitsu: 1GB a day? month?
<xhaker> 1GB per month must be a lie
<Fujitsu> Month.
<Fujitsu> OptusNet.
<Fujitsu> It's really great.
<Fujitsu> Stupid parents :(
<xhaker> so you spend those 1000Mb on irc traffic?
<xhaker> .P
<Fujitsu> I can't really do much else :(
<Fujitsu> 30MB a day :(
<Fujitsu> I have to go to friends houses to upgrade every couple of days...
<xhaker> i don't even understand the traffic limits, there shouldn't be traffic limits.. the man that thought of imposing traffic limits must be a rich bastard
<Fujitsu> Yep.
<Fujitsu> Velly lich.
<Fujitsu>  .
<Fujitsu> OOps.
<Fujitsu> Not Russian...
<Fujitsu> Australian broadband prices are, as a rule, expensive.
<xhaker> Fujitsu: my friend phoned the support line of his ISP, and said he wanted to terminate his contract. they offered him 4mbits connection + 30gb traffic monthly for 23euros
<Fujitsu> Heh
<Fujitsu> Not bad.
<xhaker> i think i need him to meet them for me
<Kamion> Ha
<Kamion> Working i18n in espresso, I think
<Fujitsu> Nice.
<Kamion> not perfect, but getting there
<Kinnison> Kamion: cool
<xhaker> now that i think of it..
* Kinnison sends Kamion to bed
<xhaker> i cannot make type the euro symbol on my keyboard :S
<_ion> Fortunately there are no traffic limits in normal ADSL connections here in Finland.
<xhaker> s/make/""
<_ion> 
<Fujitsu> Gar.
<xhaker> _ion: Ludon will have 1Gb connection per house, you lucky "people".
<Fujitsu>   .
<Fujitsu> Not again >_<
<xhaker> _ion: how do you type 
<Fujitsu> "Silly silly Finland."
<_ion> xhaker: I switch to the Finnish layout and press altgr-e.
<Kamion> Kinnison: can't sleep, still waiting for the remaining bolts to arrive so we can put our bed together; bed isn't a terribly appealing option :-/
<Fujitsu> Hahah
<xhaker> _ion: omg.. i was trying altgr+5
<_ion> It works as well.
<Kinnison> Kamion: hehe
<xhaker> mj59 you up?
<xhaker> i meant mjg59
<xhaker> what have you decided to do with Acer "wierd" keyboard keys.. like  and $ ?
<xhaker> they see ignored for now
<LeeJunFan> how does one go about adding a page to the wiki? I'd like to write somethign up for diskless server/clients with dapper.
<LeeJunFan> I see editing, stuff in the docs but not creation.
<_ion> Just type the title to the URL and edit.
<LeeJunFan> _ion: ah, I see - thanks.
<_ion> That's how it works in all the wikis.
<_ion> Or alternatively make a link from another page to the page you want to create, click it and edit.
<jdub> LeeJunFan: have you looked at the ltsp support in ubuntu (or are you writing about exactly that)?
<LeeJunFan> jdub: no, not remote X, just multiple PC's booting w/o disk and then sharing the same filesystem via NFS
<LeeJunFan> I finished setting up my library like that today, 22 diskless workstations. But with 22 workstations and the possibility of many of them running openoffice at the same time I don't think I could buy enough RAM for the server, and the PC's are all new and fast with enough RAM, so let them to the processing work.
<LeeJunFan> my library == my local library, not my workplace.
<Kamion> fabbione: I've fixed a couple of bugs in partman_newlayout (manual partitioning didn't work from the autopartition-one-device menu which meant it was inaccessible if you only had one disk, and backup from that menu didn't work in the single-disk case)
<Kamion> fabbione: uploading in a moment
<bddebian> infinity: You around?
<minghua> bmonty: ping
<bmonty> hi minghua 
<minghua> bmonty: IIRC, you were the one who did m17n-db new version upload, right?
<bmonty> minghua: yes
<minghua> bmonty: we now have https://launchpad.net/distros/ubuntu/+source/scim-m17n/+bug/34851
<Ubugtu> malone bug 34851 in scim-m17n "scim crashes Xchat" [Normal,Unconfirmed]  
* minghua pats Ubugtu: welcome back
<Chipzz> jdub: the guy is a kde developer; what did you expect? ;)P
<infinity> bddebian: Am now.
<bddebian> infinity: Is there any chance I could bug you for a little bit about something?
<infinity> bddebian: Depends on what it is.  Just spit it out.
<bddebian> infinity: Well I am trying to set up a repository and was hoping you'd take mercy on me and help me?
<infinity> Define "set up"... You want to create a Packages.gz and a Sources.gz from a bunch of files in a directory (man dpkg-scan{packages,sources}), do the same for a bunch of files in a tree (man apt-ftparchive), or set up something that allows uploads and does publishing (apt-cache show mini-dinstall)?
<bddebian> I want to pull Ubuntu source packages, tweak them a little, dput them up and have them in /pool/main/foo/bar
<infinity> Then you want mini-dinstall, probably.
<infinity> Or "dak" (which is what Debian uses), but you could spend weeks/months learning how dak works, which is why mini-dinstall was written. :)
<bddebian> Well that's wehre I'm getting a little lost.  mini-dinstall, dinstall, dak, reprepo...
<infinity> dak is serious overkill.
<jdub> Chipzz: for a long time there's been a good relationship between the *developers*, but it has started eroding recently.
<infinity> It's meant for massive installations (like Debian, or like Ubuntu, before we switched to Launchpad)
<_ion> I found reprepro to be very nice.
<bddebian> infinity: Right, but mini-dinstall won't create the binaries right?  Or am I lost as usual?
<bddebian> _ion: Yeah?
<infinity> bddebian: Erm, "create the binaries"?  You mean, you also want a build daemon?
<bddebian> Well that was my question.  I assume I need one?
<infinity> bddebian: Just do source+binary uploads to your mini-dinstall repo. (using whatveer you want to do binary builds, pbuilder, sbuild, whatever you're comfy with)
<_ion> Nicer than mini-dinstall IMHO.
<bddebian> Well it will be basically a copy of xubuntu
<infinity> bddebian: If you really need build daemons, you need more than a "quick chat" with me, I suspect.
<bmonty> bddebian: mini-dinstall works great and is fairly easy to set up
<bddebian> bmonty: I know for local, but I'm looking at 1800/1900 packages :-)
<infinity> I tend to prefer mini-dinstall too, since it behaves a bit like dak, which I'm comfy with.
<infinity> But to each their own.
<infinity> bddebian: If you're only building for one arch, just do source+binary uploads to your repo.  Trust me, that's MUCH less hassle than also maintaining some sort of buildd infrastructure for one user.
<infinity> bddebian: If you're doing multiple arches, you can either feed them all manually, or you may want to start looking at wanna-build, but it's not simple (and without some heavy tweaking, wanna-build will want a dak installation to hang out with)
<bddebian> infinity: Well eventually I hope it's more than one user.. :-)
<infinity> bddebian: One user uploading was what I meant.
<bddebian> Oh, hehe
<bddebian> Well I HOPE there's more than that too :-)
<tritium> bddebian: are you starting ubuntu-hurd?  ;)
<bddebian> tritium: No, though I would still like to :-)
<tritium> hmm, that was my best guess as to what you're up to :)
<Kamion> I got tantalisingly close to getting a bootable hurd-i386 d-i the last weekend I tried hacking on it
<Kamion> but wasn't quite there yet
<bddebian> Kamion: Really?
<infinity> Kamion: Find other ways to spend your spare time, kthx.
* bddebian pokes infinity
<Kamion> yeah, just need to attack the CD boot sequence harder
* bddebian hands Kamion a bribe
<Chipzz> jdub: I realise the irony in my statement (in that I'm "trolling" myself), but note the ";)P" (ie don't take to seriously); but I guess it's mostly individuals, not the whole (kde and/or gnome) community at alrgew
* Lathiat laughs
<Kamion> infinity: any other useful hacking I can think of would be near-term usable by Ubuntu and thus qualify as work not relaxation ;-)
<infinity> Kamion: Hahaha.
<Kamion> and I'm an installer hacker, I like making systems boot when they really don't want to and putting stuff together from tiny pieces all over the floor
<infinity> So, what's so mystical about booting the Hurd?... Is grub still the only bootloader that knows how to boot it, so you have to chain syslinux to grub?
<infinity> Or are we talking failure much later on, like "the system, once booted, refuses to talk to the CD properly", or some such?
<Kamion> no point chaining syslinux to grub, just boot straight from grub
<Kamion> the mystical bit is getting it to boot from CD and have a writable root filesystem
<Kamion> because it has no initrd concept as such
<bddebian> infinity: So mini-dinstall will handle binary+source uploads coming in to incoming?
<infinity> bddebian: That's the theory, yes.
<bddebian> theory? :-)
<infinity> bddebian: Since binary+source is the Debian standard, and mini-dinstall was written to run on people.debian.org, I'm going to go with "yes". :)
<infinity> bddebian: (I say theory a lot, when I really mean, "try it yourself, I know it works, but you won't beleive me anyway until you make it go on your own")
<Kamion> you have to set up a ramdisk translator on the fly that's backed by the compressed filesystem on the CD, before you really get the rest of the Hurd running at all
<bddebian> And we have issues with ramdisk/tmpfs :-(
<infinity> Kamion: That does kinda sound like fun.
<Kamion> it's not conceptually difficult, but the pieces involved are so much different from Linux that it's tricky to get your head around
<Kamion> bddebian: oh?
<Chipzz> infinity: is the hurd actually usefull for anything yet? ;)
<infinity> Kamion: Too bad I have my own useless port to look after (one that actually installs, boots, runs, and has 95% of the archive built), or I'd be interested.
<bddebian> infinity: Hurd boots and runs :-)
<infinity> bddebian: LIES.
<infinity> bddebian: Does it stay up for more than a few days now?
<Kamion> mind you I quit looking at tmpfs as such and started looking at an insane pure-menu.lst storeio-based hack I found Roland McGrath posting about in 1998 or something
<bddebian> And if people didn't use freaking PATH_MAX, MAXPATHLEN, et al, we'd probably have about 95% of the archive too :-)
<infinity> bddebian: (while doing anything strenuous, like running a buildd)
<_ion> chipzz: You can ping localhost.
<bddebian> infinity: http://www.bddebian.com runs on it, check the uptime :-)
<bddebian> Of course it has like 0 load :-)
<infinity> Yeah, I'll reiterate the "strenuous" bit.
<_ion> bddebian: Try running cpuburn for a while. :-)
<Chipzz> last I heard dhcp didn't even work
<bddebian> _ion: All I have to do is build glibc ;-P
<infinity> ISTR the Debian hurd-i386 buildd could never manage more than a couple of days uptime.
<Kamion> Chipzz: that was sorted a while back
<jdub> oh man
<jdub> so when someone does a hurd derivative
<jdub> they can call it hubuntu
<jdub> and the theme song would be
<bddebian> No, it's UbuntGNU :-)
<jdub> huuuuuuuuubuntu, hu-hu, hu-hu
<bddebian> Or GNUbuntu
<jdub> to the tune of who are you?
<Chipzz> or gnubuntu ;)
<jdub> bddebian: whois gnubuntu.org :-)
<jdub> bddebian: and ask rms why he won't let us help gnu by using it :)
<Kamion> gnubuntu could also mean a derivative built without restricted - name clash there
<infinity> Hu's in the buntu, hu, hu, hu!
<Chipzz> ah yes, thats rms ubuntu derivative
<Chipzz> iirc
<jdub> Chipzz: "ask rms why he won't let us help gnu by using it"
<infinity> Kamion: I think the "no non-free" gnubuntu was already proposed...
<Kamion> Chipzz: yri
<bddebian> jdub: Fuck RMS :_)
<Chipzz> jdub: "it"?
<jdub> gnubuntu
<ajmitch> bddebian: play nice :)
<jdub> i so feel like blogging about that
<Gman> fuck rms, please?
<jdub> but i probably shouldn't
<jdub> hrm
<jdub> actually, that's an interesting point
<infinity> bddebian: Anyhow, I'll happily toy with the idea of an Ubuntu/Hurd port when you can demonstrate that we won't have to reboot the buildds every 3 days. :)
<jdub> "does your blog have to abide by the CoC if you're on puc?"
<bddebian> infinity: Fair enough :-)
<Kamion> the other reason to look at porting d-i to the Hurd is general portability
<jdub> infinity: it's okay - jbailey will do it!
<mjg59> jdub: Well, I'm not on puc...
<infinity> jdub: The stuff syndicated to puc should, which is why you should only syndicate based on certain tags/topics, not the whole blog.
<infinity> Kamion: Have the kfreebsd folk done much to get d-i going there yet?
<jdub> mjg59: you have not asked for either of your blogs to be on puc
<Kamion> it's a port that's reasonably accessible from the Debian point of view, but yet gives us the opportunity to start looking at the rampant Linuxisms scattered throughout d-i
<jdub> infinity: but that goes against the whole point of planets
<mjg59> jdub: I never post to one, and you refused to put the other on pgo
<Kamion> infinity: absolutely nothing as far as I'm aware
<Kamion> infinity: AFAIK they'd have similar booting fun, though it's been a while since I talked about it with mjg59
<infinity> jdub: Not IMO... I'd like a certain amount of relevance in my planet, I don't want to read about how J Random Developer just spent the weekend flossing his grandmother's cows.
<jdub> mjg59: this is a bitter stalemate that we may only be able to solve with tequila and blades attached to our fingers
<infinity> jdub: I want some technical/social relevance to the planet in question.
<bddebian> WTF? Canonical registered GNUbuntu??
<jdub> infinity: culture killer
<infinity> jdub: It may also help to note that I'm not a big fan of planets anyway. :)
<infinity> (5 people whose blogs I find interesting, 45 people who I don't care about, I'd be better off reading the 5 individually)
<Kamion> bddebian: the name's been tossed around for a long time, and we'd be happy to let people use it who were going to actually take it in plausible directions
<jdub> gnubuntu was thought up mere moments after we talked about "hey, well, y'know, someone's just gonna add a K to that sucker..."
<Kamion> Canonical has registered rather a lot of domains related to Ubuntu; Gnubuntu isn't particularly special in this regard
<bddebian> Damn you people are tempting me... :-)
<slomo> infinity: ross is doing funny things again... like not wanting to build anything :(
<infinity> slomo: Did it just build banshee?
* infinity looks.
<infinity> Yup.
<infinity> slomo: Fixing.
<slomo> infinity: banshee built fine but that was the last thing... is something broken with the banshee package?
<infinity> slomo: No, something's goofy (but difficult to reproduce and track down) with the removal of one of banshee's build-deps, which someone managed to BREAK OUT of the chroot by accident and reset permissions on /dev/null in the base system.
<infinity> Seriously.
<infinity> FUN.
<infinity> s/someone managed/somehow manages/
<ajmitch> impressive
<infinity> Wow, brain/finger disconnect there.
<_ion> Wow. :-)
<infinity> (Okay, it's easy for a process running as root to break out of a chroot, but it's bizarre for one to do it without trying...)
<infinity> Anyhow.  It's on my list of things to care about when I have free time, but for now it's easier just to clean up after it.
<bddebian> How do I run mini-dinstall on a "system" level rather than via a user?
<infinity> Run it as a daemon.
<infinity> And still have a dedicated user for it, cause running daemons as root is dumb.
<infinity> slomo: Cleaned up; thanks for the heads-up.
<infinity> slomo: You're still waiting on evolution-sharp, aren't you?  That's why you noticed. :)
<infinity> slomo: Thankfully, ross finally seems to be done building the 5-day backlog of OpenOffice and compiler uploads <glares at doko>
<slomo> infinity: exactly... i always watch my uploads until they failed/worked fine everywhere ;)
<infinity> slomo: Good man.  More should follow your example.
* bddebian cowers
<Chipzz> +   512 Mar 17 Fran Hickman        (6513) Microsoft Adobe
<Chipzz> what will those spammers come up with next? microsoft linux? :)
<Lathiat> haha
<Chipzz> Gman: I can shove a cup of tea up his arse next fosdem if you want to ;)
<bddebian> _ion: Still here?
<_ion> bddebian: Yep.
<bddebian> _ion: Where did you put your conf file for reprepro in /dists/ ?
<_ion> bddebian: Here's a live example, http://johan.kiviniemi.name/ubuntu/ . Look at the conf directory.
<bddebian> _ion: Awesome, thanks!
<bddebian> infinity: Still awake?
<infinity> I should hope so, it's only 3pm.
<bddebian> Oh, heh, sorry
<bddebian> Got a suggestion for an ftpd to process incoming?
<bddebian> I used to use wuftp but everyone always gave me shit for it :-)
<infinity> bddebian: I like ProFTPd and vsftpd.
<bddebian> OK thx
<infinity> vsftpd has the advantage of being in main.
<infinity> ProFTPd is really simple to understand if you know Apache configuration.
<bddebian> hmm
<bddebian> infinity: To point /incoming to dir /archive/incoming, use alias like apache?
<infinity> http://www.proftpd.org/docs/
<infinity> In your case, you probably just want a DefaultRoot and DefaultChdir for the anonymous user.
<bddebian> Thx
<bddebian> FUCK, sometimes having to sudo everything pisses me off
<nekohayo> has someone experienced weirdness with nm-applet lately?
<nekohayo> like, networkManager tries to connect me to an impossible local IP (169.254.195.122)
<nekohayo> instead of being assigned something in 192.168.1.x
<bddebian> That looks like it can't find a DHCP server ( if that even makes sense)
<Fujitsu> That means it can't get DHCP.
<Fujitsu> It an automatically self-assigned IP.
<nekohayo> what could cause that?
<Fujitsu> No DHCP server.
<nekohayo> it's totally random it seems
<Burgundavia> no, 169 is a defined spec for address self assignment
<Burgundavia> windows and OS X will also do this
<nekohayo> whew
<Fujitsu> Yes.
<Fujitsu> Everything has to, or it doesn't meet the IP specs.
<Burgundavia> by default, a linux machine will not, afaik
<_ion> 169.254.0.0/16 - This is the "link local" block.  It is allocated for communication between hosts on a single link.  Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.
<_ion>  RFC 3330
<Fujitsu> Linux machines will!
<nekohayo> my dhcp server is a simple linksys router, it always worked fine so far, it's the first time I see this
<_ion> My guess would be that it's used for the mdns stuff.
<_ion> Nope. "Any DNS query for a name ending with ".local." MUST be sent to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).
<nekohayo> would it be safe to assume it's a software misconfiguration or..? how could I determine this?
<nekohayo> it happens with both wired and wireless
<Burgundavia> it might be your router
<bddebian> Gah, why doesn't proftpd wanna start as inetd?
<nekohayo> hmm
<nekohayo> I guess I have to do a full reset to test
<nekohayo> question: does nm-applet conflict with gnome's network-admin in any way? is there something I must be aware of ?
<nekohayo> as I could not find things on that matter on the project page
<_ion> You should disable everything from gnome's network-admin ( from /etc/network/interfaces  except lo, of course). That way network-manager gets to do its job.
<nekohayo> ok I did
<nekohayo> I'll try restarting the router and see if that may be the problem then
<nekohayo> brb (and thanks all)
<nekohayo> nope, not the router
<nekohayo> other ideas? or is there a debug mode or verbose option I could use?
<nekohayo> if it's a bug I'd like to report it, but I'm pretty empty handed ;)
<tritium> Is there a policy or spec on /var/run being a tmpfs, and how to handle that properly in init scripts?
<infinity> The "proper" way to handle it is to make sure it exists with the right ownership/permissions before your daemon starts. :)
<infinity> (Or in the daemon itself, if you're clever)
<infinity> s,it exists,the subdirectory you want in /var/run exists,
* tritium is not very clever, so I'll focus on your first comment.  Thanks!  :)
<infinity> Note that for (at least) everything in main, we're about to run through and fix anything that hasn't already been fixed.
<infinity> And if Keybuk's feeling keen, he may do some/most/all of universe. :)
<tritium> infinity: it's tor (in universe)
<ajmitch> is keybuk really that bored?
<infinity> ajmitch: No, he's just really that responsible for changing /var/{run,lock} to tmpfs, so he gets to clean up the mess. :)
<infinity> (If his cleaning doesn't go well, he'll get help, I suspect)
<ajmitch> something to delegate to MOTUs for universe, as far as it's possible
<tritium> As I learn best by example, I'll look for a package that's handling it cleanly already, and try to fix tor.
<infinity> Sure, and if you guys want to start grepping now and fixing stuff, that's less stuff for him to fix later. :)
<infinity> tritium: apache2 has handled it for ages in its init script.
<tritium> thanks, infinity.  Will check it out now.
<infinity>                 # /var/run and /var/lock could be on a tmpfs
<infinity>                 [ ! -d /var/run/apache2 ]  && mkdir /var/run/apache2
<infinity>                 [ ! -d /var/lock/apache2 ]  && mkdir /var/lock/apache2
<infinity>                 # Make sure /var/lock/apache2 has the correct permissions
<infinity>                 chown www-data /var/lock/apache2
<infinity> (That's in the start target)
<tritium> That helps :)
<infinity> You can get that in one shot by using "install" instead of "mkdir && chown"
<infinity> (If you need to care about permissions)
<tritium> which I do
<infinity> So, for apache, I'd do "[ ! -d /var/lock/apache2 ]  && install -m 755 -o www-data /var/lock/apache2"
<infinity> (Which I may change it to in the next upload)
<Mithrandir> or just do install -m 755 -o www-data -d /var/lock/apache2
<Mithrandir> (unconditionally)
<infinity> Oh, missed the -d on that. :)
<fabbione> iirc install complains if the dir is already there
<infinity> Mithrandir: Will -d foo not return non-zero if it's there?
* infinity tests.
<tritium> This mentoring is great!
<infinity> Oh, it does ignore existing directories.  Spiff.
<infinity> tritium: What Mithrandir says, then.
* infinity hugs install.
<tritium> aye.  Thanks to infinity, Mithrandir, and fabbione.
<infinity> You forgot to thank your mom.
<infinity> And your producer.
<fabbione> what have I done this time?
<tritium> The teleprompter was saying "wrap things up"... :)
<fabbione> i swear i didn't touch the BIG RED BUTTON
<infinity> fabbione: Spoke.
<fabbione> oh ok :)
<Mithrandir> infinity: yeah, seems to DTRT for me.
<infinity> Mithrandir: Yeah, I had to test myself before I believed you. :)
<infinity> You know me.
<Mithrandir> infinity: I had to test myself and look at $? before I believe mee, too.
<Mithrandir> me, even
* infinity starts working on a new apahce2 upload and slips that change in there.
<fabbione> infinity: it's about time :)
<infinity> I curiously noticed that in my last upload, when "removing cruft", I kinda removed too much "cruft"... Didn't notice until I installed apache2 on the sparc buildds (which run dapper). :)
<fabbione> ehe
<fabbione> infinity: monday or tuesday i will give you access to a serious sparc
<fabbione> it depends how fast i can get the blood lines for it
<infinity> I'm happy with my little sparcs.
<infinity> They're fast enough for all but toolchain hacking.
<fabbione> mine is too fast.. even for toolchain hacking
<infinity> Nothing is ever too fast for toolchain hacking.  Ever.
<fabbione> infinity: you joking right?
<fabbione> it's faster than an e10k
<infinity> Until you can do a 10-stage GCC bootstrap in a couple of minutes, anyway.
<infinity> I expect a chroot and an account to test this theory. :)
<fabbione> approx 32 times faster than the toys you have
<infinity> And so help me god, if you impose ulimits, I'll setit on fire remotely... Somehow.
<fabbione> sure
<fabbione> no i don't use ulimit
<fabbione> i hate ulimit
<fabbione> that's how I found a small memory corruption but in the kernel when building with make -j8192
<fabbione> s/but/bug
<infinity> It's impressive that the kernel's makefiles are sane enough that you can build with that level of parallellisation.  I suppose you weren't the first to try, though. :)
<fabbione> well the kernel stops forking at about 7500
<fabbione> that's the amount of files we do build on sparc for our kernel :)
<fabbione> i was the first onn that CPU to do that
<infinity> I assume that years ago, when Linus decided to use an 8-way box as his primary workstation, he started stumbling on a bunch of bugs in the dependencies.
<fabbione> i know IBM did it on some super machines to test stuff
<fabbione> yeah
<fabbione> go alpha!
* infinity still misses Alpha..
<infinity> And DEC, for that matter.
<fabbione> i always wanted one
<fabbione> never able to get one
<fabbione> (for free)
<fabbione> but i will get there sooner or later
<infinity> I have one, but it doesn't (can't) run Linux.
<infinity> I always intended to do a Debian/NetBSD-alpha port, but never found any round tuits.
<fabbione> hey you can run windows on it
* fabbione hides
<Lathiat> hehe
<fabbione> Lathiat: no, it's damn true
<fabbione> at the time there was a version for alpha cpu
<infinity> No, can't run NT on that one either.
<Lathiat> yeh i know, NT runs on alpha
<Lathiat> :)
<Lathiat> infinity: what is it?
<infinity> It's a TurboChannel DEC AlphaServer, they only ever ran OSF and VMS
<fabbione> infinity: doh..
<infinity> The other option has been to port the TurboChannel drivers from Linux/MIPS to Linux/Alpha, but the same round tuit issue cropped up.
<infinity> And now it's in my friend's basement, happily running NetBSD.
<infinity> And probably keeping him awake at night with all the fans. :)
<infinity> (s/OSF/Digital UNIX/ or s/OSF/Tru64/, depending on how old you are)
<infinity> Obviously, I'm an old fart. :/
<fabbione> wow.. hppa managed to build the installer?!?!?
* Lathiat knows OSF as both OSF and Tru64
<fabbione> that's scary
<fabbione> infinity: no. you are not THAT old
<Lathiat> <-- 18
<fabbione> Lathiat: you are a kid
<infinity> fabbione: hppa's coming back.. Slowly. :)
<fabbione> infinity: yeah..
<fabbione> let's hope the new kernels are a bit better
<fabbione> both ia64 and hppa are farting on me
<infinity> It's also hilighting a mess of FTBFSs in the archive that I missed on previous looks through logs, which is nice. :)
<fabbione> ehhe
<infinity> Well, if lamont ever gets that hppa machine to me, I'll happily tweak the kernel a bit.
<fabbione> infinity: we should probably start considering a dapper auto-rebuild-of-death
<infinity> Yes, it's overdue.
<infinity> I meant to get it underway right after FeatureFreeze.
<fabbione> infinity: nah.. it's stuff that not even parisc guys can get fixed...
<fabbione> there is a big issue with the toolchain
<infinity> fabbione: Yeah, but I've been wanting to get my hands dirty in the parisc kernel for a while.
<infinity> (And the toolchain)
<fabbione> where in pa1.0 mode, the code cna't do jump with offset bigger than 17bit
<fabbione> that makes basically a bunch of kernel modules unloadable
<fabbione> it goes very very very very deep into the toolchain
<Mithrandir> infinity: we're aiming for a flight at end of next week, so I would really like to have the buildds not choking at your rebuild of death at that point.
<infinity> Mithrandir: Well, we'll either do the rebuild on the wanna-build buildds (so they don't affect you), or I'll have to talk to the LP folk to get segregation, so we can do rebuilds without affecting the distro.
<infinity> Mithrandir: At this point, the wanna-build option seems more realistic, if we want the rebuild RIGHT NOW (which we kinda do)
<Mithrandir> infinity: or at least being able to tell the buildds that there is more important stuff going on and if they would please drop whatever they're doing and get to useful work, that'd be nice.
<Mithrandir> infinity: sure, I don't mind if they're a tad slower as long as it's not "no, you can't build anything for three days because the buildds are busy".
<fabbione> Mithrandir: did you already write and approved a spec for it?
<Mithrandir> fabbione: is this the point where I ask you to sod off? :-)
<fabbione> Mithrandir: it's the point in which you can autoanswer yourself that it will be done with w-b :)
<Mithrandir> fabbione: oh, the rebuild, no I'm not responsible for that, so I'm not writing a spec for it.
<fabbione> Mithrandir: ehhe
<infinity> Mithrandir: By "end of next week", you mean in ~7 days?
* infinity curses sparc and its Bus Errors...
<fabbione> infinity: what did BusError ?
<fabbione> that usually means that there is a non-64bit alligned access in mem
<infinity> fabbione: ghc6... I'm tossing it back to see if it was random (which some are), and if it's not, it's probably an alignment issue that needs to be patched.
<fabbione> infinity: ok.. mostlikely the second one
<fabbione> too bad ghc6 can't fork in the build
<Mithrandir> infinity: yes.  Or ten days.  Depending on how I feel.
<infinity> Mithrandir: Alright, well, I'll try to get my hacking with cprov in at the beginnning of the week so you have me as a slave at the end.
<Mithrandir> infinity: ooh, slave, fun.
<Mithrandir> infinity: I hope I won't require much from you in the end, but we'll see.
<Mithrandir> infinity: are you going out to visit the PENGUINS next weekend too?
<infinity> Mithrandir: Hey, I'm happy with you taking over Flight releases completely, but one never knows. :)
<Mithrandir> sure, tag-teaming is fun
<Mithrandir> but, I gotta go for a while.  See you around.
<infinity> Mithrandir: No penguins, though I do like to keep my weekends pretty sacred and "non-work", until we're in release crunch mode.
<Mithrandir> sure
<_ion> Now all the patches from the official network-manager package except for 20-linux-wlan-ng.patch should ported in my 0.6 package.
<infinity> _ion: Cool.  And do they appear to work as expected?
<_ion> infinity: Yes so far. Of course the package needs a lot of testing.
<whiprush> _ion: can you please cc fridge-devel@ubuntu.com when you announce widespread testing?
<_ion> whiprush: Will do.
<whiprush> thanks
<infinity> fabbione: Do you have any urge to look at why redland-bindings is FTBFS on sparc, despite building fine everywhere else?
<fabbione> infinity: is that main?
<fabbione> infinity: looking at it
<infinity> fabbione: It claims to be.
<fabbione>  ?1.0.2.1-1ubuntu4
<infinity> https://launchpad.net/distros/ubuntu/+source/redland-bindings/1.0.2.1-1ubuntu4
<fabbione> ok
<infinity> (And yes, I've already retried the build in the past, same failure)
<fabbione> chekcing now
<infinity> So, I assume some sort of toolchain buggery earlier up in the log, and I'm too lazy to look right now. :)
<fabbione> infinity: it builds here
<fabbione> let me check something else too
<infinity> Oh, joy.
* infinity hates "it builds here"
<infinity> Could be something sketchy like a corrupt ccache.
<highvoltage> me hates "it works in windows"
<infinity> Though that's pretty rare when it happens.
<fabbione> infinity: let me try with a super clean buildd chroot
<infinity> You can have the one I'm using, if you have decent bandwidth to the DC. :)
<infinity> Only 42 megs.
<fabbione> infinity: i do.
<fabbione> but i can debootstrap locally..
<infinity> fabbione: chinstrap:~adconrad/
<fabbione> infinity: ok
<infinity> fabbione: To be just like a buildd, just dist-upgrade it when you get in there, and set /CurentlyBuilding appropriately. :)
<fabbione> infinity: yeah i know the trick
<infinity> I know.  Just being "helpful". :)
<infinity> Hrm, ghc6 hasn't failed yet on vivies, I think the BusError was cosmic rays.
<fabbione> infinity: it might be, but it's not a good sign
<infinity> No, it's not.
<infinity> I used to get them (randomly) on Sparc all the time, though.
<fabbione> infinity: do you still mount /proc and dev/pts in the chroots?
<infinity> Yes, though the latter is pointless.
<infinity> (Since they have a full set of legacy PTYs as well)
<fabbione> ok
<fabbione> infinity: it does build here.. even with your chroot..
<infinity> fabbione: Well, that's fantastic.
* infinity grumbles.
<infinity> I'll kick it back one more time. :)
<_ion> seveas: Does this look right at all? http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
<_ion> seveas: It's made against the current linux-restricted-modules source package.
<fabbione> infinity: i am trying different combinations... 
<_ion> seveas: I don't have madwifi hardware, so i can't test.
<dholbach> good morning
<fabbione> infinity: can you try a manual build with a console?
<fabbione> i wonder if it's a tty issue
<_ion> seveas: Another thing: is this patch needed? http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html
<infinity> fabbione: I can in a while.  Though, if it's a TTY issue, the other buildds should have failed too.
<fabbione> infinity: i know.. but the other buildds might have tty1 or so.. sparc doesn't
* infinity will try to build manually if/when the next automagic one fails.
<fabbione> infinity: E: Package espresso-keyboard-setup has no installation candidate
<fabbione>  <- sparc
<fabbione> oh i see
<fabbione> it's generated from new console-data that's FTBFS on sparc
<infinity> Ahh, so it is.
* fabbione attempts a fix
<fabbione> this is embarassing...
<fabbione> running a 350GB /usr/src out of space
<pitti> Good morning
<fabbione> hi pitti
<_ion> 'ning
<ajmitch> morning pitti 
<infinity> fabbione: Yup, failed again, trying a manual build...
<fabbione> infinity: ok
<sivang> Seveas: pong
<sivang> Morning everybody.
<sivang> hey pitti 
<infinity> fabbione: Same failure on a manual build...
<fabbione> HMMMM
<fabbione> that's kind of weird
<fabbione> try disabling ccache?
<kagou> hi
<infinity> fabbione: Yeah, I can.  Though we've ruled out a broken cache, cause I was using a fresh one.
<fabbione> i had ccache enabled...
<fabbione> and disabled..
<fabbione> i wonder if it could be something completely different.. like the host not being updated
<infinity> ...?
<infinity> LP buildds run a dist-upgrade before each build.
<infinity> Or, you mean the base system could be affecting it in curious ways? :)
<fabbione> probably...
* infinity goes to compare with a successful build log on another machine.
<fabbione> i am running a more recent and actually bugfree kernel...
<infinity> Erm, no, the problem is much more obvious.
<infinity> I'm wondering why you're not seeing it...
<infinity> Compare the tail end of these lines:
<infinity> -DPIC -I/usr/lib/ruby/1.8/powerpc-linux redland_wrap.c -c -o redland_wrap.so
<infinity> -DPIC -I redland_wrap.c -c -o redland_wrap.so
<infinity> Where's the ruby include on sparc?  :)
* infinity goes to poke at configure's log...
<infinity> And there's the real problem.
<infinity> fabbione: 
<infinity> buildd@sejong:/build/buildd/redland-bindings-1.0.2.1$ ruby1.8 -rrbconfig
<infinity> Illegal instruction
<infinity> fabbione: ruby is failing when configure calls it to find out the config settings. :)
<fabbione> sec...
<netstar> Anyone noticed MANY panel applets won't load?
<fabbione> is that suppose to give any output?
<fabbione> infinity: ^^
<fabbione> it's does  not die on me
<infinity> fabbione: No, this should:
<infinity> ruby1.8 -rrbconfig -e "puts Config::CONFIG['archdir'] "
<fabbione> ruby1.8 -rrbconfig -e "puts Config::CONFIG['archdir'] "
<fabbione> /usr/lib/ruby/1.8/sparc-linux
<infinity> Fun.  What CPU is in that machine?
<fabbione> cpu             : TI UltraSparc IIi (Sabre)
<fabbione> it's not the IIIi like at the DC
<infinity> This IIIi either hates ruby, or the kernel is seriously confused.
<fabbione> i did already file an RT request for upgrading the kernrel on the buildd
<fabbione> the best would be to try on faure
<fabbione> it already has the latest kernel
<fabbione> (or almost)
<netstar> The panel or something it depends on ( I can't ascertain what) is causing panel applets to die on PPC.  Anythin I can test, anyone having the same problem?
<infinity> fabbione: Well, if I knew that these machines could safely reboot remotely, I'd reboot them with the new kernel...
<infinity> fabbione: I do all the other updates on them, but don't have the balls to reboot them. :)
<netstar> There's nothing that jumps out to me that could be causing this fromt he last 24 hour's update
<infinity> fabbione: I don't suppose you could reboot with a -16- series kernel and see if you get an Illegal insn there as well?
<fabbione> infinity: they can reboot if you do a dist-upgrade, but there is an RT for them.
<fabbione> infinity: they really need to have a new udev
<fabbione> or network won't come up
<fabbione> infinity: i am not even sure i have these images around anymore
<infinity> fabbione: Well, they all have the latest dapper.  It's just the "reboot for the new kernel" step that hasn't happened... <shrug>
<fabbione> infinity: you sure they are all superupdated?
<infinity> Yes. :)
<fabbione> infinity: just check the symlinks /boot
<fabbione> and reboot only one of them
<fabbione> they all have console/ALOM access
<fabbione> in the worst Karl will have to mangle only one of them
<fabbione> btw.. console-data with the fix is uploaded...
<fabbione> espresso will be installable as soon as it builds
<fabbione> infinity: the reboot of these machines takes quite a while
<fabbione> about 2/3 minutes
<infinity> Yeah, I'm used to real hardware.
<fabbione> even longer sometimes
<fabbione> ok
<netstar> http://www.rafb.net/paste/results/c1CtgD69.html is the output I get
<netstar> weird
<infinity> fabbione: No such luck.
<infinity> buildd@sejong:~$ ruby1.8 -rrbconfig -e "puts Config::CONFIG['archdir'] "
<infinity> Illegal instruction
<infinity> buildd@sejong:~$ uname -a
<infinity> Linux sejong 2.6.15-18-sparc64 #1 Thu Mar 9 14:41:32 UTC 2006 sparc64 GNU/Linux
<fabbione> infinity: one second.. please
<fabbione> can we strace it?
<infinity> Ideally, we should disassemble it, but gdb hung on me when I ran it.
<infinity> Go gdb.
<fabbione> use strace please
<fabbione> i know gdb is borked
<fabbione> it's in the endless TODO list
<fabbione> make sure to kill -9 the gdb processes
<fabbione> or they will stay there
<infinity> Yeah, I noticed. :)
<infinity> Anyhow, strace isn't terribly enlightening in the case of an Ill insn.
<infinity> _sysctl({{CTL_KERN, KERN_VERSION, 0, 21ab1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 2, 0xef8fba60, 30, (nil), 0}) = 0
<infinity> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
<infinity> brk(0)                                  = 0x22000
<infinity> brk(0x44000)                            = 0x44000
<infinity> mmap(NULL, 245760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7038e000
<infinity> --- SIGILL (Illegal instruction) @ 0 (0) ---
<infinity> +++ killed by SIGILL +++
<fabbione> the next instruction is a break
<fabbione> ok
<fabbione> let me see if i can reproduce it on Niagara
<fabbione> yeps...
<fabbione> i can 
<infinity> BTW, (other than this), I'm really impressed with the work that's gone into Sparc on Linux 2.6 recently.  Give DaveM some "mad props" from me.
<infinity> These buildds are much more stable than the sparc/linux machines I used to run at work.
<fabbione> ehhe
<fabbione> that's because recently i managed to stress the kernel a bit more
<MrFaber> hi all
<MrFaber> I have problems with frequency scaling with current dapper kernel
<MrFaber> It shows the correct frequency maximum and minimum but it didn't change from the maximum
<MrFaber> A friend of mine has the same problem
<fabbione> MrFaber: file a bug on malone, if there isn't one already
<MrFaber> there are several
<infinity> fabbione: Alright, I'm going to clean up and light up sejong again.  Poke me if you get ruby sorted, so we can retry its reverse deps.
<MrFaber> according to frequency scaling
<fabbione> infinity: i don't think it's a reverse-deps problem.. but i am going there slowly
<fabbione> infinity: i still can't reproduce it locally
<infinity> fabbione: No, I mean so I can retry the stuff that build-deps on it. ;)
<infinity> fabbione: (Once it's fixed)
<fabbione> infinity: ah sure
<tritium> floe (ia64) doesn't like building tor (gs error building docs)
<fabbione> MrFaber: so if there are several, they might get fixed. coming here to push, won't help
<fabbione> MrFaber: or do you have a patch to fix them all?
<MrFaber> fabbione, just wanted to ask
<MrFaber> maybe they are already fixed
<MrFaber> fabbione, Kanotix 2.14 kernel scales my cpu :)
<infinity> tritium: I'm retrying the build now.  If it fails the same way again, can you file a bug on gs with a pointer to the build log?
<tritium> infinity: okay.  It looks like it failed on a previous upload on March 9.
<MrFaber> Then I have some other questions, if you disable splash screen I see some error messages, is this normal? If I mount e.g. a loop-aes device it shows me information messages with red stars but mounting works fine
<infinity> tritium: Ahh, then it's probably a bona fide gs bug, yes.
<infinity> tritium: Please file it, so our gs maintainer (iwj) will poke at it.
<netstar> MrFaber: Yes it is normal (within reason)
<MrFaber> netstar, ok thanks
<tritium> infinity: will do.
<infinity> Oh, for fuck's sake...
* infinity pushes more soyuz changes.
<tritium> infinity: I'm going to get a few hours of sleep before work.  I'll take care of it in the morning.
<fabbione> infinity: davem is on that ruby issue... but he will have to debug it tracing via kernel.. because gdb is useless
<fabbione> infinity: i am ready to bet he will have a fix in less than 1 hour
<Seveas> _ion, how's the nm/driver patching going?
<pitti> Hi Seveas 
<Seveas> hi
<_ion> seveas: /lastlog -hilight
<pitti> hi _ion 
<_ion> Hi
<pitti> infinity: can you please try a give-back for nautilus on amd64?
<pitti> infinity: ... and sparc?
<infinity> pitti: We don't build nautilus on those arches.
<pitti> infinity: ...
<infinity> :)
<_ion> pitti: All the patches except for 20-linux-wlan-ng.patch should be ported now.
<pitti> _ion: rock :)
<pitti> _ion: I'll care for that one, the current patch is far from perfect anyway
<infinity> pitti: Given-back.
<Seveas> _ion, http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html should be covered with the patch collection from robert love I pointed too
<pitti> _ion: did you talk with Scott about releasing this one? And is there an UVF exception already?
<Seveas> _ion, but if you have updated packages for l-r-m and nm, I'll test
<Burgundavia> -
<Burgundavia> _ion: do you need testing on madwifi?
<doko> pitti, Kamion: we maybe want to revert the dependency of language-support-en on openoffice.org-helpe-en-gb, it's +12mb for the CD's
<pitti> doko, Kamion: would be fine for me; I already wanted to ask you about this (2x en help)
<_ion> I haven't touched the l-r-m package yet, but it should be tested whether this works or not: http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
<_ion> I or Pygi will build a patched l-r-m package in the near future.
<infinity> _ion: What needs to be patched in LRM?
<_ion> infinity: It will need to be patched with the diff from the URL.
<_ion> infinity: Or at least so i've heard. ;-)
<infinity> _ion: Erm, that patch is just for networkmanager..
<_ion> http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
<infinity> _ion: Hrm, I fear that patch may be against madwifi-ng...
<infinity> _ion: Can you file a bug on LRM, and I'll chase it up later?
<_ion> infinity: The original is, but that diff is against the current l-r-m source package.
<infinity> _ion: And does it work?
<_ion> infinity: That is yet to be tested. :-)
<infinity> _ion: And, more to the point, not break anything else? :)
<_ion> I really don't know much about the whole madwifi situation. I only saw two patches that allegedly fix the WPA support and modified them to apply against the madwifi-old tree. :-)
<_ion> That diff hasn't been tested at all yet.
<MrFaber> _ion, wpa is very strange under Linux
<MrFaber> some version work, next version doesn't work of wpa_supplicant
<MrFaber> at least for me :)
<Seveas> _ion, if you have the patched version up - poke me and I'll test 
<pitti> infinity: is it possible to build php5-sqlite with libsqlite3? (that worked fine with qt3)
<Seveas> madwifi devs are not interested in supporting WEXT in the near future so you will need the collection of workarounds in NM
<infinity> pitti: Probably? :)
<pitti> infinity: however, I don't know whether the libs just have a different API, or different db format, too
<_ion> seveas: Will do. :-)
<ajmitch> pitti: totally different & incompatible DB format
<infinity> pitti: The database formats aren't backward compatible (and sqlite3 has no support for reading sqlite0 databsases), that's my only concern.
<pitti> hm
<infinity> pitti: At least, AFAIK.
<infinity> pitti: I was going to do a bit more research on it before I comitted.
<pitti> so, all packages but php-sqlite use 3 now, but that doesn't help us much then, I guess...
<ajmitch> infinity: yeah, I've run into it with f-spot
<kagou> do we considere that under a dapper filesystem, ALL files must be encoded in utf-8. Or some files can be encoded in ISO8859-1 ?!
<infinity> pitti: I can transition php to sqlite3 (and call it php5-sqlite3), and then build a php5-sqlite in universe that uses sqlite0, if we're concerned about upgrade paths.
<pitti> if that isn't too much work?
<infinity> kagou: There's no standardisation for text file encoding at all, except in some very rare cases.
<infinity> pitti: Not really much effort, assuming it compiles cleanly and works.
<infinity> pitti: I'll need to chase it up on Monday (I'm already several hours into my weekend) :)
<_ion> The situation would be optimal if everything was encoded in UTF-8.
<pitti> _ion: time will heal all wounds :)
<kagou> Mithrandir, i'm talking of course of your answer in #35045
<Seveas> pitti, and then they will replace utf-8
<infinity> "They" already have replaced it.
<infinity> (or extended it)
<pitti> infinity: ?
<infinity> Windows is UTF-16, n'est-ce pas?
<pitti> infinity: there is sth. even more crackful^Wmodern than unicode?
<infinity> No, still Unicode, just bigger! :)
<pitti> infinity: oh, right, but that has always been there, hasn't it?
<_ion> UTF-$n are just different encoding methods for Unicode.
<pitti> there are even more encodings for unicode 
<infinity> Yeah, UTF-8 and UTF-16 grew up together, I believe, not sure why we standardised on one, and Microsoft on the other.
<pitti> infinity: becuase that's what they always do? :)
<infinity> To be fair, this one might be our fault. :)
<infinity> Windows has been UTF-16 internally for a long time.
<_ion> UTF-8 is very good for networking, file contents and file names. Handling UTF-16 strings is faster codewise.
<Treenaks> UTF-8 is ASCII compatible (it's identical in the 7-bit range)
<pitti> _ion: how is it faster?
<Treenaks> UTF-16 makes ALL characters 2 bytes long
<Mithrandir> infinity: utf16 isn't backwards compatible in the way utf8 is (ascii) and it requires double the space for storage.
<hunger> infinity: utf16 is basically the unicode standard.
<Mithrandir> infinity: so utf8 is "better" than utf16.
<pitti> Treenaks: how does utf16 handle characters above 0x10000 then?
<hunger> infinity: Utf8 is a trick to shoehorn utf16 into 8 bit.
<infinity> Mithrandir: Ahh, I didn't realise it lacked the ASCII backward compatibility.  That would explain why UNIX vendors prefer UTF-8.
<hunger> pitti: Surrogate pairs:-)
<_ion> pitti: It doesn't AFAIK. :-) For that you need UTF-32.
<Treenaks> pitti: http://en.wikipedia.org/wiki/UTF-16
<Treenaks> _ion: it does :)
<pitti> _ion: well, unless you are a hard disk vendor, UTF-32 seems even to be a worse idea...
<_ion> treenaks: Ok.
<robtaylor> pitti: hey, Cardoe was on #dbus last night complaining we (upstream) weren't applying distro patches. Which out of the ubuntu patch set are we currently missing?
<pitti> hi robtaylor 
<hunger> pitti: There are ranges in the 16bit range that encode a couple of bits and must be followed by some other 16bit value that has the rest.
<pitti> robtaylor: shall we go through them in pm? I'm not sure which of them have been applied
<robtaylor> pitti: ok, cool
<pitti> hunger: very muhc like utf-8 then ;)
<hunger> pitti: Somewhat:-)
* minghua is not sure UTF-16 can be called unicode standard
<hunger> pitti: You should only need the stuff > 0xFFFF for really strange languages though, so it is a bit of a progress.
<minghua> there is still UCS-2 and UCS-4 after all
<Treenaks> minghua: UCS-2 == UTF-16
<Treenaks> minghua: "UTF-16 is officially defined in Annex Q of ISO/IEC 10646-1. It is also described in The Unicode Standard version 3.0 and higher, as well as in the IETF's RFC 2781."
<pitti> hunger: for my POV, everything > 0x7F is strange enough already :)
<minghua> hunger: not really, the Chinese in Hong Kong uses characters > 0xFFFF
<hunger> minghua: unicode defines which "number" corresponds to which letter.
<Treenaks> pitti: trange? :P
<pitti> Treenaks: :)
<minghua> hunger: I think I understand the concept of codepoints
<hunger> minghua: Yeap, but only for "strange" letters of that languages (or so the standard claims).
<_ion> trange ndeed. 
<hunger> minghua: utf* is a mapping of the "unicode numbers" into bitpatterns.
<minghua> hunger: from what I heard they use those characters every day
<hunger> minghua: I don't know... I just know the unicode standard:
<pitti> robtaylor: did you get my /msg?
<minghua> hunger: it's a mandarin/cantonese difference
<hunger> minghua: And before 3.0 there were no chars defined > 0xFFFF.
<hunger> minghua: Only after that those were added to cover some more obscure languages.
<minghua> hunger: yeah, I know that story
<minghua> Treenaks: from wikipedia: "The only difference between the two formats is that UTF-16 requires support of surrogates (explained below), whilst UCS-2 forbids such support and thus only encodes the BMP."
<hunger> minghua: I do not know any east asian language (except maybe 50 of the less useful chinese chars that I picked up traveling through china:-)
<Treenaks> minghua: so they're mostly compatible
<minghua> Treenaks: so UTF-16 and UCS-2 are different, UCS-2 doesn't have chars > 0xFFFF, which is the reason we have UCS-4
* hunger would use either utf8 or utf32.
<Treenaks> minghua: yes, but UTF-16 is UCS-2 + a hack which allows characters > 0xFFFF
<hunger> utf8 is shorter for latin-based languages, but longer for east asian languages.
<minghua> hunger: not bad if you can pick up that many chars in such a short time
<minghua> :-)
<hunger> utf32 stays constant wrt. size but is 4times bigger for ASCII when writting english.
<hunger> minghua: I was with a friend who studied chinese and asked him whenever I saw a char I could remember.
<hunger> minghua: So I picked up a really strange cross-section of chars... like "old in the sense of made in dynasty XY":-)
<minghua> hunger: strange indeed.  I am not so sure which chars you are talking about :-)
<fabbione> infinity: ruby with the fix is pending upload..
<fabbione> infinity: i told you less than one hour :)
<MagnusR> p
<hunger> minghua: Whatever looks vagualy recognizeable to a european hanging around in antiques stores and other touristy places.
<mdke> mdz, ping?
<doko> seb128, dholbach, jdub: are icons overwritten by some package?
<dholbach> doko: hm?
<doko> dholbach: I'm wondering, why OOo has different icons on i386 and amd64 ...
<seb128> doko: it uses your theme first, and if the theme has no icon for what you ask fallback to what the theme specify (Tango for Human by example), then GNOME, then hicolor
<seb128> doko: maybe you don't use the same icon theme
<doko> seb128: ohh, right, now everything looks ugly, not just some icons :-/
<seb128> what theme do you use?
<doko> jdub: the folder icon for the menus looks really bad ... too much orange (install menu, open the Debian menu)
<doko> seb128: Human now
<Kamion> doko: ugh, yeah, 12MB on CDs is bad, I hadn't got round to noticing yet
<Kamion> pitti: dropping -help-en-gb should be fine; no British English speaker will have a problem with American English help
<pitti> hmm, is it just me, or has responsiveness during 100% I/O operations vastly deteriorated?
<dholbach> hey mvo!
<dborg> guten morgen!
<pitti> Kamion: alright, will upload a new package now
<seb128> hi dborg mvo
<mvo> hello
<seb128> mvo, pitti: how do one trigger the "restart required" icon?
<mvo> pitti: I noticed the same
<mvo> seb128: click on it
<pitti> Kamion: hmm, do we want to keep l-support-en on the CD in the first place? We might leave it as it is, and just add a subset of the packages to desktop maybe (those which are required by OOo to work)
<seb128> mvo: no, how do you get that icon without installing a package that requires a reboot ... like what file should be created? :)
<pitti> seb128: /usr/share/update-notifier/notify-reboot-required
<seb128> thank you pitti
<pitti> seb128: just call it
<seb128> that's an idea :)
<Burgundavia> pitti: I have noticed the same issue, with regards to IO
<pitti> Kamion: l-s-en currently has two help packages, and three l10n packages
<seb128> that's for https://launchpad.net/distros/ubuntu/+source/gedit/+bug/33087
<Ubugtu> malone bug 33087 in gedit "gedit crashes when restart after update is forced" [Normal,Confirmed]  
<robtaylor> mvo: hey :), i'm just going through distro patches for dbus to commit upstream.. can you give me some history on http://people.ubuntu.com/~pitti/tmp/dbus-patches/patches/int64detection.diff ?
<pitti> Kamion: l10n-en-{us,gb,za}
<pitti> Kamion: not to mention tbird-locale-en-gb and two myspell packages
<Kamion> pitti: I think language-support-en is a good place to put "extra English stuff we want on the CD" at the moment, but if you'd rather that be desktop, I guess I don't mind; the downside of using desktop is that people who don't care about English can't conveniently uninstall it
<mvo> robtaylor: without the patch IIRC the qt bindings didn't worked (compile error with incorrect types) on amd64
<Kamion> the multiple oo.o l10n packages are reasonably small now - it's just the help that's huge
<pitti> Kamion: true
<robtaylor> mvo: but what's the reasoning behind it?
<pitti> Kamion: ok, then I'll throw out -en-gb help for now; it's trivial to change anyway
<Kamion> ok, thanks
<Kamion> doko: how much in the way of common files is there between -help-en-us and -help-en-gb?
<robtaylor> mvo: and what was the build error?
<infinity> fabbione: I'm just glad it wasn't a toolchain bug.
<doko> Kamion: no common files, only thing I can say, there are about 5000 different message strings in the help (out of 40000)
<doko> maybe most s/z/s/g?
<Kamion> pitti: mozilla-firefox-locale-xh-za seems to be disappearing (not built from source); is there a replacement that language-support-xh could use?
<pitti> Kamion: no really, nobody updated the xh translations
<Kamion> that's more different strings than I'd expected; OK
<fabbione> infinity: no, it's ruby crap. it was working on my machine by mistake...
<fabbione> infinity: i am just doing an extra test/build to be sure..
<Kamion> pitti: well, either language-support-xh drops that dependency or it becomes uninstallable, then :-(
<pitti> Kamion: hm, I should provide an empty dummy package for transition
<Kamion> transition to what? :)
<pitti> Kamion: yes, I'll drop the dependency in any case
<Kamion> the old package should be uninstallable now, so I think it should be automatically removed
<pitti> Kamion: oh, right, it shuold uninstall itself in a breezy->dapper upgrade
<infinity> dholbach: gnumeric needs the same fix you just made for goffice.
<pitti> Kamion: both uploaded, thanks
<dholbach> infinity: righto, merci
<doko> seb128: #23049 ping
<robtaylor> pitti: i think the applied fix for dbus-qdbusmarshall-amd64.patch also removes the need for int64detection.diff
<pitti> robtaylor: ok; it's easy enough to check :)
* pitti builds on amd64 without the patch
<robtaylor> heh :)
<Kamion> pitti: did you manage to get far enough through any espresso installs on powerpc to find out if yaboot configuration works?
<seb128> bug #23049
<Ubugtu> malone bug 23049 in openoffice.org "Printer properties: no paper orientation option" [Major,Confirmed]  http://launchpad.net/bugs/23049
<robtaylor> gotta love ubuntu buildd
<pitti> Kamion: no, it always crashes at the keyboard selection, I filed a bug about it
<seb128> doko: what about it?
<pitti> Kamion: it seems to be independent from the language setting :(
<pitti> Kamion: I didn't try the latest CDs though, just the one from about two days ago
<infinity> robtaylor: ?
<pitti> robtaylor: I'm building on my own machine :)
<robtaylor> pitti: ah, cool. CVS, right?
<doko> seb128: can I turn off the options off again?
<pitti> robtaylor: oh, you mean the upstream fix should cure that? well, I just meant the current ubuntu package; anyway, that's something we can sort out in dapper+1, when upgrading
<seb128> doko: why?
<seb128> doko: "All seems to work perfectly. This bug can be marked as fixed for me. Thank you :-)"
<seb128> doko: what is your issue with something that "work perfectly"?
<robtaylor> pitti: yeah, i think that http://people.ubuntu.com/~pitti/tmp/dbus-patches/patches/int64detection.diff is very broken
<doko> seb128: "seems" is not enough. did you _check_ this with different page orientation in the page formats?
<fabbione> Kamion: hey dude.. i am perfectly fine with whatever change you did in partman-auto...
<seb128> doko: ploum did and commented
<robtaylor> pitti: its just fixing for a problem in http://people.ubuntu.com/~pitti/tmp/dbus-patches/patches/dbus-qdbusmarshall-amd64.patch, and breaking abi :/
<seb128> doko: he was the guy who complained about it
<fabbione> Kamion: btw.. i also got espresso running on sparc :) it exits at the keyboard selector, but i will get there :)
<seb128> doko: why of why want you to put the bug back if nobody complain and some people commented it works for him?
<doko> seb128: so he only checks about the things he's interested in
<pitti> robtaylor: ok, can you point me to the better fix for qdbusmarshall?
<seb128> doko: that's better than having people not testing anything
<pitti> robtaylor: then I can throw away the two ubutu patches and use upstream's instead
<seb128> doko: you can't blame an user to have interest to some stuff only and not want to debug all openoffice.org for you
<Kamion> fabbione: was just a small logic tweak
<Kamion> pitti: hmph, ok, I wish I could boot CDs on my powerbook at the moment
<fabbione> Kamion: yup.. i am always fine with your changes..
<fabbione> Kamion: you so much don't need to explain to me :)
<robtaylor> pitti: hmm, hand on a mo, i'm just checking over with qt maint
<Kamion> I imagine your keyboard selector problem is the same as pitti's, basically
* fabbione nails down in front of the d-i/espresso God
<seb128> (s/of/oh)
<seb128> doko: dunno why he used "seems", he tried and it works fine for him
<doko> seb128: no, the behaviour is broken upstream. I'm not in favour of breaking something for a "nice to have" thing
<doko> seb128: you did agree on testing this ...
<seb128> doko: I got ploum to test it, I've no working printer
<robtaylor> pitti: it seems to be correct in 0.61
<fabbione> Kamion:  i didn't check with pitti, but i have no rush to get espresso working.. i need to get X autoconfig going first
<seb128> doko: we tried during UI sprint on fedora or suse (not sure know) and they had the option too
<seb128> s/had/have
<robtaylor> mvo, pitti: we still can't make sense of int64detection.diff
<seb128> doko: k, I'll not bother again for openoffice and users wanting to get it better, break it if you want too
<mvo> robtaylor: have you tried building it on a amd64 without the patch?
<robtaylor> mvo: qt maint has, says it works
<seb128> doko: remove that option again without reason, ploum will complain and search for an openoffice1 package to install and you will be happy
<robtaylor> (0.61 this is)
<doko> seb128: looking at the sources, suse doesn't have this option.
<robtaylor> mvo: that patch breaks abi on amd64
<Kamion> fabbione: I suspect I don't have time to do espresso-silo anyway ...
<mvo> robtaylor: it's possible that it is fix now, then we can drop the patch
<seb128> doko: so that's FC5 :)
<fabbione> Kamion: i might be able to help you for that....
<fabbione> Kamion: silo doesn't ask anything.. just does..
<robtaylor> pitti: ah well, i think we can definitly conclude we can drop both of those for 0.61+ :) our work here is done ;)
<Kamion> espresso-grub and espresso-yaboot should be reasonable examples there
<fabbione> anyway don't worry about it
<fabbione> exactly
<mvo> robtaylor: which one? the int64detection.diff? or the other one?
<fabbione> it's more important for me to get X autoconfig going properly
<fabbione> but now i have the tools to do so
<robtaylor> mvo: int64detection.diff breaks abi
<robtaylor> mvo: i think
<mvo> robtaylor: why? it shouldn't matter
<pitti> Kamion: I just noticed that I forgot to remove python-gdchart from the server seed; this was the only place which still refered to it (which prevented it to appear in anastacia, I guess); is there an associated metapacakage that I need to update?
<Kamion> pitti: no
<pitti> ah, so anastacia looks directly at the seeds for server?
<Kamion> yeah
<Kamion> well, I mean, it always looks directly at the seeds
<Kamion> but sometimes there are metapackages as well
<pitti> aah, ok
<robtaylor> mvo: it means that longlong gets used instead of long for int64 in all the interfaces, does that not change abi?
<Kamion> looks like it should drop out of main in the next hour, then
<pitti> Kamion: thank you
<infinity> pitti: I'm hand-picking some builds to get gnutls11 completely gone... Should be ready to go by Monday.
<pitti> Kamion: is there a possiblity that you will need directfb in main for cdebconf or so?
<pitti> infinity: cool
<pitti> infinity: does that require some no-change uploads for evo? i. e. were the current packages built against 11, or were they just not yet built at all?
<pitti> Kamion: we seeded libdirectfb-dev, which does not have rdepends, and we could get rid of directfb and libmpeg3 (mentioned in duplicated packages) if we don't need it for the installer
<mvo> robtaylor: I don't think so, sizeof(long) == sizeof(long long) on amd64 (8)
<pitti> mvo: it might break ABI on other architectures
<robtaylor> pitti: very good point
<pitti> mvo: i. e. i386 long is 4 byte, long long is 8
<infinity> pitti: Looks like only two packages (evo-exchange, and control-centre) will require rebuild uploads (for ia64), but I'll know for sure when I'm done getting hppa caught up on those rdeps.
<robtaylor> pitti: not in that case, as its comparing against 8
<pitti> robtaylor: OTOH, using 'long' etc. to define fixed-size datatypes is a very bad idea in the first place
<pitti> robtaylor: you should probably prefer stdint.h, with uint64_t, and so on
<robtaylor> pitti: its a configure check on the actual size
<pitti> ah, I see
<pitti> but still, stdint.h is easier and less prone to such bugs, isn't it?
<mvo> robtaylor, pitti: I don't think so, the patch disables "long" as a possible 64 bit datatype, that shouldn't be a problem in any way as long long is still tested. don't get me wrong, the patch is a hack, but I don't think it breaks the abi
<robtaylor> pitti: not necesarilly there on all dbus targets
<robtaylor> mvo: yep, i think your right
<mvo> robtaylor: so I would be more than happy if it could be removed by a better patch :)
<robtaylor> mvo: i just get slightly scared what subtleites lie in eabis ;)
<mvo> robtaylor: don't talk to me about c++ abis ;) 
* mvo stares at libapt
<robtaylor> mvo: well it's certainly the wrong fix, so I'll just make sure thiago checks on amd64 before release
<robtaylor> mvo: exactly ;)
<pitti> robtaylor: uh, there are dbus targets which don't have stdint.h? that's ISO C99
<mvo> robtaylor: I'm happy to re-check it again on monday when I'm back at my amd64 (please remind me again if I forget it)
<seb128> Mithrandir: is your evolution shell patch supposing to make it using the running instance instead of opening a new window? If that's the case seem it doens't work for me
<mvo> robtaylor: thanks for checking/forwarding our patches, that is a great help
<robtaylor> pitti: i have to admit, i dont know the full reasoning ;)
<robtaylor> mvo: np, thanks for the help..
<Mithrandir> seb128: no.  It's supposed to make evolution 'calendar:///?startdate=20050601' (or something similar) open one window, not two.
* mvo invites pitti to #ubuntu-l10n
<seb128> Mithrandir: it was opening 2 windows before?
<Mithrandir> seb128: yes.
<seb128> hum
* seb128 downgrades so
<Mithrandir> seb128: it doesn't reuse the existing instance.  I could probably investigate how to do so, but it's not the primary goal of the patch.
<Mithrandir> seb128: it's basically so double-clicking on a date in the clock applet will give you one window (like today), not two.
<seb128> Mithrandir: hum, it opens only one without the patch
<seb128> dholbach: if you do evolution 'calendar:///?startdate=20050601', how many windows are open?
<Mithrandir> seb128: that's really weird..
<dholbach> two... an evolution window (with mail and stuff) and one with the calendar
<mdke> if someone with main access has a spare 2 minutes, could they have a look at bug #30694, there is a patch on there for the fix. Thanks!
<Ubugtu> malone bug 30694 in xmms "unfriendly menu entry for XMMS" [Normal,Unconfirmed]  http://launchpad.net/bugs/30694
<seb128> dholbach: thank you
<seb128> Mithrandir: it ws just to try, but the patch is simple enough, I'll use it even if I don't get the issue :)
<dholbach> seb128: de rien
<Mithrandir> seb128: do you get just one window if you close all the existing evolution windows too?
<seb128> Mithrandir: no, in that case I got 2
<seb128> but I've a mailer open usually, in which case it opens a new one with the calendar
<Mithrandir> seb128: yes, that's the case I'm trying to address.  One could argue whether doing evolution $uri should reuse the existing shell or not, but it's not what my patch touches.  It's just the initial startup.
<seb128> verified, it fixes the issue
<Mithrandir> excellent, and sorry for poor description of the problem in my bug report.
<seb128> np, thank you for the patch :)
<Mithrandir> I've found getting stuff fixed is _much_ faster if you provide a patch, so I try to do that.
<Mithrandir> even for trivial problems like this one.
<seb128> that's for sure
<seb128> I know we have a ton of small bug like that
<seb128> so even if the patch take 15min to do, we usually tend to ignore a lot of them
<Mithrandir> it'd be nice if we had a month to sit down and work out small patches for them.  I bet 90% of them will have patches that are less than twenty lines.
<seb128> but if that's just a matter to try a patch and push it that's easier
<Mithrandir> yeah, it took me an hour or two, but I don't know the evolution model and didn't have it in my ccache.
<Mithrandir> mhm
<seb128> not to mention that it feel a bit harsh to ignore a patch because somebody put work to it, so I try to make sure patches are used :)
<seb128> Mithrandir: https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/21595 ... look at the list of people subscribed and the number of dups and comments for it
<Ubugtu> malone bug 21595 in xkeyboard-config "alts_toggle breaks instead of overriding ralt -> l3" [Major,Unconfirmed]  
<seb128> Mithrandir: just to give you some motivation for tha xkeyboard-config 0.8 update :) You will win some extra cool points if you manage to get it done :)
<Mithrandir> seb128: that's like half the world. :-)
<seb128> yeah
<fabbione> Kamion: grub-installer/espresso seems really trivial..
<fabbione> Kamion: i think i can do silo easily
<viviersf> fabbione, whats up with grub-installer ?
<fabbione> viviersf: ??
<mdz> seb128: why do we still get so many dupes of #21595?  did the backported fix for breezy not work?
<Kamion> pitti: not for dapper; perhaps dapper+1
<Kamion> viviersf: nothing
<seb128> mdz: I don't know if the breezy-update has been done, accepted and is working for one thing
<seb128> mdz: for an another thing the dapper package is still bugged
<seb128> mdz: I don't know xkb stuff good enough to point a trivial fix, what I know is that I'm running xkeyboard-config 0.8 for 2 days now and it fixes the issue
<pitti> Kamion: ok, so you wouldn't mind if I unseeded it?
<mdz> seb128: xkeyboard-config | 0.6-5breezy1 | http://security.ubuntu.com breezy-updates/main Sources
<mdz> it went in ages ago
<Kamion> pitti: not at all
<seb128> mdz: maybe daniels screwed on that version doesn't fix it so
* jdub hugs the channel.
<pitti> hey jdub
* the_channel hugs jdub
<pitti> I *knew* that someone would jump that :)
<jdub> ;)
<ogra> :)
<_ion> Hehe.
<Kamion> pitti: python-gdchart, libgdchart-gd1, libgd evicted from main
<pitti> \o/
<_ion> Sigh, i can't get sleep.
* pitti ticks off another item in DapperDuplicatedPackages
<jdub> Kamion: (what are your thoughts about pushing our python love out of the desktop seed and into a python seed, and using an 'ubuntu-python' metapackage or something?)
<seb128> mdz: is "breezy-updates" configured by default? there is also the possibility that many people don't use -updates but just -security
<mdz> seb128: yes it is
<pitti> jdub++
<pitti> hey sabdfl
<mdz> seb128: it looks like maybe the reports are mostly dapper though
<sabdfl> hey hey
<seb128> mdz: yeah, atm that's the case
<_ion> Hi
<seb128> hi sabdfl
<ogra> pitti, is thhere a chance to install language packs without firefox-locale packages ? 
<mdz> seb128: so we may have the option of bringing forward that fix rather than 0.8
<sabdfl> seb128: you beating back the flood?
<pitti> ogra: you mean language-support-*? no
<ogra> gah ... k
<pitti> ogra: if you only want specific packages, you can install them :)
<seb128> sabdfl: that's right, we will defeat the bug backlog today :)
<ogra> i was pondering to switch edubuntu to epiphany to gain more CD space ... but if the langpacks need to persist on the CD thats shallow
<ogra> pitti, no, th elanguage selector will need the full langpacks
<pitti> ogra: no
<ogra> no ? 
<ogra> oh
<pitti> ogra: language-pack-* doesn't depend on ffox
<pitti> ogra: language-support-* does, but it's not on the CD anyway
<ogra> ah
<ogra> then i'll do some tests for the next dailies over the weekend ... i bet it saves a lot
<seb128> mdz: diff between 0.6 package and 0.8 is quite short and there is a bunch of new keymaps that would be nice for the l10n goal ... I would recommend using 0.8
<ogra> and will make seb128 happy :)
<seb128> mdz: FC5 is using it, and Debian has it packaged already too
<mdz> seb128: have you already packaged it or are you testing it some other way?
<seb128> mdz: I made a "stock upstream" package, ie: just copied the debian/ dir and rebuilt it and I'm running that
<seb128> there is a bit of .diff.gz to look at for a proper update, Mithrandir is supposed to do that
<seb128> Mithrandir: have you already looked on it?
<seb128> though the .diff.gz is probably mostly CVS fixes than daniels backported to 0.6
<Mithrandir> seb128: I started looking at it yesterday, but didn't make it before end-of-day.
<pitti> mdz: do we consider GFDL suitable for main? we seeded autoconf-doc, but autoconf-nonfree (its source) is in universe right now
<Mithrandir> pitti: we do, yes.
<pitti> ok, so we can promote it, I guess
* pitti writes report
<fabbione> pitti: do you think you can manage to take a look at git-core and see how bad would it be for main inclusion?
<fabbione> pitti: it has all Depends/B-D in main afaik
<fabbione> i am pretty sure it does.. just an extra eye would be helpful
<pitti> fabbione: if you think it's a good idea to support it for 3 years?
<fabbione> it's quite stable now
<pitti> i. e. I don't really see the benefit, but that might be just me
<fabbione> so yes.. considering it's our RCS for the kernel
<pitti> but I can certainly take a look at it
<fabbione> that would be lovely
<fabbione> pitti: quite a bunch of users asked for a linux-kernel-devel meta package
<fabbione> that would include git-core
<fabbione> and it's only bit outside main atm
<pitti> ok
<fabbione> (the metapackage is not in the archive yet, but will be soon)
<fabbione> thanks a lot my german friend
<pitti> ok, I need to write some reports anyway now to clean up anastacia
<fabbione> eheh
<doko> seb128: please could you check #25998?
<pitti> seb128: gst-plugins-ugly0.10 - what exactly is ugly about it? it doesn't really sound suitable for main :)
<mdz> pitti: yes, we do
<seb128> bug #25998
<Ubugtu> malone bug 25998 in openoffice.org2-amd64 openoffice.org2 "French accents not working properly in OOo2" [Normal,Needs info]  http://launchpad.net/bugs/25998
<seb128> pitti: ugly licence, patents, etc
<dholbach> pitti: http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/README?rev=1.12&view=markup
<pitti>  This packages contains plugins from the "ugly" set, a set of
<pitti>  good-quality plug-ins that might pose distribution problems.
<seb128> pitti: mp3, mpeg, those sort of stuff
<pitti> seb128: so we don't want it in main, right? because it's explicitly seeded right nwo
<pitti> s/nwo/now/
<seb128> pitti: it is?
<pitti> o gst-plugins-ugly0.10: gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-dbg
<pitti>    [Reverse-Depends: Dapper supported seed
<Kamion> jdub: python seed> I don't mind, but you get to fight it out with sabdfl :-)
<seb128> pitti: supported: * gstreamer0.10-plugins-ugly-dbg
<pitti> seb128: ah, the -dbg package is seeded
<sabdfl> i'm ready
<pitti> seb128: ok, this time you snapped me :)
<seb128> pitti: I've been optimistic when refreshing the -dbg list it looks like :p
<pitti> seb128: I unseed it, ok?
<seb128> sure
<seb128> thanky ou
<seb128> sorry for the mistake
<pitti> no problem
<Kamion> damnit, why do all emulators suck
<seb128> pitti: upstream creating -ugly to make easy for distribution to separate what to ship or not :)
<seb128> pitti: so -good is for main and -ugly for universe
<jdub> Kamion: it's been rejected in the past, or you don't think it'll score highly on the love chart?
<pitti> right, that's what I like about the current packaging
<Seveas> rraphink, your r seems to be stuck ;)
<Kamion> jdub: python-* in the desktop seed is owned by Mark
<rraphink> lol
<Kamion> jdub: I don't mind, but whether I mind does not matter
<pitti> Kamion: pootle can be removed from the archive, as well as linux-source-2.6.12 (already in universe, and older than in breezy-security)
<pitti> Kamion: (pootle was renamed to translate-toolkit)
<mdz> Kamion: what's your current preference for grouping installer bugs?  subscribing ubuntu-installer, subscribing you, assignment?
<mvo> dholbach: can you have a look at #26308 (arabic problem)
<infinity> Does dholbach read arabic?
<Kamion> mdz: either subscribing ubuntu-installer or subscribing me
<Kamion> subscribing ubuntu-installer is probably better going forward
<dholbach> bug 26308
<Ubugtu> malone bug 26308 in openoffice.org "Ooo2 breaks arabic ligature on entering diacritic" [Normal,Needs info]  http://launchpad.net/bugs/26308
<dholbach> mvo: that looks broken
<dholbach> mvo: it should be joined up as in gedit :/
<mvo> dholbach: join #ubuntu-l10n
<Mithrandir> pitti: how does one get rid of the really annoying "partition $foo is N% full"?
<pitti> Mithrandir: free some space :)
<pitti> Mithrandir: seriously, you only get it now for system partitions which are > 95% full
<pitti> Mithrandir: is that the case for you?
<Mithrandir> pitti: seriously, it's really annoying.
<Mithrandir> and there's no obvious way to get rid of it.
<pitti> do you get it for a partition that shouldn't be watched?
<Mithrandir> I get it for /tmp
<pitti> Mithrandir: unfortunately g-v-m upstream doesn't provide a means to disable it per-partition
<pitti> bug 33967
<Ubugtu> malone bug 33967 in gnome-volume-manager "A way to disable low disk space warnings" [Normal,Unconfirmed]  http://launchpad.net/bugs/33967
<Mithrandir> pitti: ok.  It's also a problem that there's no obvious way to know what makes those messages pop up.
<infinity> That bug title is missing a verb...
* Mithrandir solves the problem with chmod 0 /usr/lib/notification-daemon/notification-daemon
<pitti> Mithrandir: erm, that disables *all* notifications
<Mithrandir> pitti: yes, and?  They're generally just really, really annoying.
<pitti> heh :)
<pitti> Mithrandir: I guess upstream added this notification after all the bugs which complain about your system acting strange and breaking if your disk is full
<Mithrandir> we're getting into the windows popup syndrome.  Way too much which pops up on the screen.
<pitti> we have lots of these bug reports ourselves
<pitti> Mithrandir: if we can find sb who speaks gtk/gconf, we could add it ourselves
<tseng> my favorite is 'i imported 42334 into f-spot, now my disk is full and everything crashes'
<Mithrandir> pitti: sure, but I know how to diagnose bugs and would really like my system to not go "you only have 500MB left in /tmp, it's VERY URGENT to free some space".
<tseng> filed against f-spot
<Mithrandir> pitti: it's g-v-m?
<pitti> Mithrandir: yes
<Mithrandir> pitti: hmm, I'll see if I can find time to fix it, then.
<pitti> Mithrandir: ideally, the bubble would contain an option 'do not warn me again for this drive' 
<pitti> s/drive/partition/
<Mithrandir> pitti: ideally, notification-daemon would have a filter so you could say "please don't show messages from those services" possibly with a bit more filtering.
<pitti> Mithrandir: too complicated for users
<infinity> Not too complicated for a gconf key, but certainly too complex for a GUI configurable thing.
<Mithrandir> pitti: the current scheme is too bloody complicated for _me_. :-)
<doko> infinity: how is thunderbird supposed to handle mail attachments (OOo/Send document as email calls mozilla-thunderbird attachment=file:///tmp/foo.odt , but the send-mail window pops up without the attachment
<Kamion> pitti: all done
<infinity> doko: I'm not sure if it *can* handle attachments from the command line...
<doko> infinity: it did work until some days ago ...
<infinity> ...
<infinity> Days?
<infinity> Nothing's changed in tbird (certainly not in that area) since the 1.5 upgrade.
<infinity> However, this looks suspicious:
<infinity> https://bugzilla.mozilla.org/show_bug.cgi?id=316177
<Ubugtu> mozilla bug 316177 in General "command-line options for "-compose" broken" [Major,Verified: fixed]  
<infinity> doko: Looks like I should apply that patch. :)
<infinity> doko: Will do before the next upload.
<doko> infinity: thanks!
<Mithrandir> mdz: ok to upload xkeyboard-config 0.8?  It works for seb and for me.
<Kamion> pitti: demoted directfb and a slew of dependencies
<pitti> great, thanks; I also saw your wiki changes for the promotions
<pitti> Kamion: libmpeg3 kills another duplicated-packages item :)
<Kamion> libnet-perl doesn't seem to be in anastacia
<Kamion> so I left it alone
<pitti> hm, it was the day before yesterday
<pitti> but so much the better
<Kamion> dunno what's up there, I didn't investigate
<Kamion> I don't understand though, liburi-perl is in main, libnet-perl in universe, and liburi-perl Depends: libnet-perl
<pitti> Kamion: ah, liburi-perl wanted it
<Kamion> oh, perl-modules Provides: libnet-perl
<Kamion> since 2002
<Kamion> so I've got no idea why it showed up in anastacia briefly. Whatever. Ignoring. :)
* pitti smells a race condition in anastacia :)
<pitti> infinity: https://wiki.ubuntu.com/DapperDuplicatedPackages TODO-list looks pretty good now :)
<infinity> pitti: GTK1.2 still isn't gone?
<pitti> infinity: xmms :/
<infinity> Bah.  Make an executive decision and demote it.
<pitti> I so much would love to get rid of it
<infinity> I use it daily, and I don't care if it's in main.
<infinity> (And when's the last time you did a security release for it?... Never, right?)
<_ion> Xmms is teh suxor. ;-)
<pitti> and evms-gui?
<pitti> infinity: never
<infinity> I'm sure it MUST have security holes, given that it's a pretty sketchy network client and server (creepy), but no one's bothered to find and patch any.
<infinity> So like they're going to start now?
<infinity> evms-gui is, from what I've been told, worthless, but perhaps a poll of more than just "me and my buddies" could be taken.
<pitti> "Excuse me, I have a package to demote"
<_ion> In Soviet Russia, packages demote _you_!
<pitti> infinity: we still have evms-cli, which fits the GettingRidOfTheDesktop spec :-P
* Kamion goes off to sit and think hard about espresso's increasingly byzantine control flow.
<pitti> seb128: you can certainly port evms-gui to gtk2, right? shouldn't take you more than 5 minutes :)
<pitti> oh, wait, /me knows the Debian maintainer pretty well
<infinity> pitti: The rest of the page looks pretty darn good.
<Mithrandir> pitti: there exists a patch for evms
<infinity> pitti: As for evms, I may be a bit of an elitist here, but I can't imagine that many people are using evms who A) don't know the CLI well, and B) would prefer a GUI.
<_ion> I agree.
<pitti> infinity: uninstalling it is always one of the first things I do ...
<seb128> desktop: * irssi-text
<seb128> that should be changed forrssi" right?
<seb128> that should be changed for' irssi" right?
<Mithrandir> infinity: I tend to use the curses interface, but that's because the GTK interface is GTK 1. :-P
* pitti asks Sesse in #d-d
<infinity> seb128: Yes.
<Mithrandir> pitti: https://sourceforge.net/tracker/?func=detail&atid=383344&aid=1429537&group_id=25076
<seb128> infinity: k, updating desktop so
<infinity> seb128: You may want to keep irssi-text in supported, though, for smooth upgrades.
<infinity> seb128: I don't recall when the name change happened.
* infinity looks.
<infinity> seb128: Yeah, the name change is from breezy->dapper, so we probably want to keep the transitional package in supported.
<infinity> seb128: For people who don't have universe in their sources.list (whoever these theoretical people are)
<seb128> infinity: that's useful because Provides is not version, right?
<seb128> versionned
<infinity> seb128: Right.
<infinity> A provides won't auto-upgrade a package.
<infinity> Some day, that really should be fixed....
<infinity> seb128: Do you need to upload evolution-exchange for any bugfixes, by any chance? :)
<infinity> seb128: (Cause the next upload will build against gnutls12 on ia64, and clear up one more blocker to dropping gnutls11)
<tepsipakki> does somebody know how LTSP scales, what is the limiting factor with the number of clients?
<infinity> seb128: If not, I can do a no-change upload.
<Mithrandir> tepsipakki: RAM, usually.
<seb128> infinity: not really, go for the no-change :)
<infinity> seb128: Same question for control-center
<seb128> infinity: I've some changes to do for that one probably, but that will probably wait next week so go for a no-change if you want to get that sorted now
<tepsipakki> mithrandir: that's what I thought..
<infinity> seb128: Kay, cool.
<infinity> seb128: I'm just trying to make pitti happy. ;)
<seb128> infinity: that's nice from you :)
* pitti is happy
<seb128> k, I've made the irssi change
<seb128> am I supposed to do the same for server, kubuntu, edubuntu, etc?
<infinity> seb128: If you're feeling nice.
<infinity> seb128: Otherwise, others are (in theory) supposed to merge seed changes.
<seb128> I am, let's do it :)
<pitti> seb128: yes, please merge (not apply manuallY)
<infinity> pitti: In about 2 cron.daily cycles, gnutls11 should fall out of main.
<pitti> yay
<infinity> pitti: Building the hppa stragglers now, and just uploaded for the two ia64 oopses.
<pitti> three DapperDuplicatedPackages items solved on one day :)
<infinity> pitti: Anything else the SCC arches are holding you back on?
<pitti> no, gnutls11 was the only one
<pitti> the others were just seed changes
<Riddell> seb128: if you do seed changes you should at least tell me and orga, else we won't know to merge
<Riddell> seb128: and if you merge yourself them we'll love you all the more
<pitti> Riddell: I did a couple, but I always merge immediatel after them
<Riddell> just like we love pitti
<pitti> heh :)
<seb128> pitti, Riddell: change merged for server, edubuntu, kubuntu
<Riddell> groovy, thanks
<seb128> np
* infinity hugs the hppa build daemons.
<infinity> After some bumpy starts, I think we understand each other now.
<pitti> love on the second sight then :)
<Kamion> infinity: how soon do you reckon I can turn anastacia back on for hppa?
<Kamion> 'cos I'd like to do that, sort anastacia out, and then promote xubuntu
<Kamion> rather than trying to cope with the hppa-induced wreckage when working out what to do with xubuntu :)
<infinity> Kamion: Turn it back on now and see how horrifying it is?
<infinity> Kamion: But hppa should be completely caught up (modulo the usual hiccups) after the weekend, I suspect.
<Kamion> are the toolchain issues I saw vaguely mentioned some hours back likely to hold it back in places?
<infinity> Kamion: The only toolchain issue is in Java, which can be either worked around or completely disabled if a better solution doesn't present itself quickly.
<infinity> The usual "gcj only works on 3 of the 400 architectures gcc works on, and no one really cares, and even on the 3 where it does work, it sometimes doesn't" song and dance.
<pitti> Mithrandir: hm, what's wrong with the about box change? s/DIALOG/POPUP/?
<Mithrandir> pitti: nah, it's the "GTK 2 port by" part I was thinking about.
<pitti> hm, it's a pretty big patch, you think we should remve the credit for it?
<pitti> (as it is now, it looks wrong, though, you are right)
<mdke> Keybuk, sabdfl, mjg59, still looking for a response on the documentation string freeze date... I figure it's important to get it sorted quickly so that's the reason for pinging you on irc
<Keybuk> mdke: I'm still not convinced that UIFreeze and StringFreeze aren't critical-path for the DocStringFreeze
<Keybuk> so far the argument seems to be "we're nearly finished now, so we should freeze now" ... which doesn't necessate moving the freeze date
<mdke> Keybuk, the argument is based on translation
<mdke> the docs don't need more time, translation does
<mdke> the alternative is simply starting translation earlier than the freeze date, but it would make the freeze date pretty meaningless, since the whole point is to ensure that translators get a fair shot at the strings without them changing
<Keybuk> translation is getting more time though, under the new schedule
<Keybuk> how much more time for it would you like?
<mdke> Keybuk, 4 weeks or so. so, moving doc freeze 2 weeks, rather than 6
<Keybuk> that'd mean you were freezing the documentation 3 weeks *before* what you were documenting was frozen
<Keybuk> so we'd end up shipping wrong docs
<mdke> Keybuk, the likelyhood of changes affecting the documents is slim. And if you saw my email, I suggested allowing later amendments for any changes, which would be announced to the translators
<Keybuk> ok
<raphink> i've got a questions about cups
<raphink> -s
<raphink> what are the default admin name and pass for cups ?
<raphink> since we only set one user without a root account by default
<raphink> and this user can't access cups as admin it seems
<pitti> raphink: it can, you need to be member of 'lpadmin' group
<raphink> ah ok thanks pitti
<raphink> pitti: I just checked it doesn't work
<raphink> maybe it's linked to the printing module in systemsettings
<pitti> raphink: and gnome-cups-admin doesn't work?
<pitti> raphink: ah, KDE?
<fiveiron> so where would I go if I was having a major problem getting any of my repositories to work?
<raphink> yep
<fiveiron> using dapper
<pitti> raphink: known broken, yes
<pitti> raphink: bug 33173
<Ubugtu> malone bug 33173 in kdebase kdeprint "kdeprint can not contact cups" [Major,Confirmed]  http://launchpad.net/bugs/33173
<mdke> fiveiron, forum/mailing list/support request on launchpad/#ubuntu irc channel
<raphink> pitti: when I got to systemsettings, in the kdeprint section and choose Server -> Configure Server
<raphink> pitti: no, it's something else
<mdke> fiveiron, or if you think it's a bug, https://launchpad.net/distros/ubuntu/+bugs
<fiveiron> i just know i get md5 sum mismatches/gzip errors/bzip2 errors all over the place... i can barely get anything installed
<mdke> Keybuk, is that an ok, as in "ok from me, ask the rest of the TB", or "ok, consider it changed"?
* ogra goes looking what seb128 changed in his seeds ...
<pitti> raphink: well, kdeprint is known broken with our cups, it just won't work
<Keybuk> mdke: as I said yesterday, *I* don't have any particular problem with moving just that date if you wish :)  however the rest of the TB and CC probably need to vote, as we've already approved the new schedule and stuff
<mdke> Keybuk, sorry, I wasn't around yesterday. So how do I go about getting them to vote?
<seb128> ogra: irssi-text to irssi
<ogra> seb128, thanks ...
<Keybuk> mdke: wait for replies to your e-mail I guess
* mdke is all confused
<seb128> ogra: np :)
<Keybuk> or just grab people on IRC
<seb128> dholbach: lunch time for me too :)
<mdke> Keybuk, ok. hopefully someone will respond. The sooner it is sorted out, the better.
<Kamion> Keybuk: just the TB would be fine I think
<Kamion> if the CC doesn't trust the TB on technical issues we're kinda screwed anyway
<elkbuntu> hmm... is there a known permission bug with nautilus? i'm asking because sometime within the last 12 hours or so, directory permissions have been weird. i think it's just nautilus because ls shows permissions fine. in nautilus when i rightclick -> properties -> permissions, it's saying 'The permissions of 'directoryname' could not be determined.'
<mdke> Keybuk, maybe if you reply to the email, there will be an avalanche effect and the emails will come flooding in.
<Keybuk> mdke: I've already sent another
<mdke> Keybuk, thanks! 
<zul> heylo
<xhaker> dholbach, metacity is not built with libcm7, and i think it should, shouldn't it?
<Mithrandir> xhaker: no, why should it?
<xhaker> Mithrandir: changelog claims compositing manager inclusion :S
<pitti> jdub: ping
<infinity> xhaker: You probably want spiftacity.
<infinity> xhaker: I doubt libcm7 (and hence compositing in metacity) will be in main for dapper.
<xhaker> infinity, again.. see the changelog of ubuntu metacity. dholbach wrote compositing manager
<xhaker> i just find it wierd it's on the changelog
<infinity> xhaker: He's documenting changes to the source (he notes that the feature is disabled)
<infinity> xhaker: The desktop guys often mention stuff in their changelogs that doesn't seem immediately Debian/Ubuntu relevant, it seems. :)
<infinity> (base)adconrad@cthulhu:~$ zgrep Solaris /usr/share/doc/metacity/changelog.Debian.gz
<infinity>     - manually define HOST_NAME_MAX if not already defined to fix Solaris
<infinity>     - Fix Solaris compilation issues
<infinity> (for example)
<xhaker> infinity, oh, as in ifed out? i thought he was talking about gconf schema
<seb128> no
<seb128> that's a configure option
<seb128> and we don't use it
<xhaker> ok then 
<seb128> infinity: would should be pinged for packages removal? a bug triager pointed https://launchpad.net/distros/ubuntu/+source/live-com/+bug/6651
<Ubugtu> malone bug 6651 in live-com "duplicate package" [Normal,Unconfirmed]  
<infinity> seb128: Kamion, probably.
<infinity> seb128: I'm not familiar with the tool used for removals just yet.  (I guess I should teach myself sometime)
<seb128> Kamion: https://launchpad.net/distros/ubuntu/+source/live-com/+bug/6651 suggests live-com should be removed, it's a multiverse package, liblivemedia for universe deprecates it now
<Ubugtu> malone bug 6651 in live-com "duplicate package" [Normal,Unconfirmed]  
<pitti> Riddell: did you try nss-mdns? it's seeded to kubuntu-desktop now
<Riddell> pitti: yes, I've tried it
<pitti> Riddell: there are now some Debian bugs, but they don't look too scary
<pitti> Riddell: so it *only* resolves domains from .local?
<pitti> Riddell: or can you fool it to resolve other domains?
<Riddell> pitti: yes, .local is reserved for zeroconf I believe so that should be hard coded
<pitti> Riddell: e. g. if you accidentially put it first in nsswitch.conf
<Riddell> Lathiat might know
<Riddell> pitti: putting it first in nsswitch isn't a problem
<Riddell> infact it's recommended by the authors I think, not sure why debian puts it last
<pitti> Riddell: hm, so with a modified avahi I can't change the DNS of e. g. www.google.de or so?
<Riddell> pitti: you'd need to ask the avahi people to confirm but I'm pretty sure it's hard coded to only do .local
<Kamion> seb128: done, thanks
<seb128> Kamion: thank you!
<pitti> Riddell: I think the currnet package does not change nsswitch automatically at all; there are just debian bugs
<Riddell> pitti: I have mdns in my nsswitch on this fairly fresh install from a flight CD, no libnss-mdns installed
<pitti> Riddell: oh, ok, I checked the code, it does
<pitti> Riddell: oh, right, me too, so that must already be the default
<Riddell> so it must be the default in nsswitch
<pitti> Kamion: alright, so with the recent fixes and approvals, the universe->main section of anastacia should become empty
<pitti> Riddell: would it be easy to change kicker-applets to not build the xmms remote control, i. e. drop the libgtk1.2 build dep?
<desrt> pitti; know anything about recent hal changes that are causing tonnes of new volumes to show up in gnomevfs?
<pitti> desrt: that was a last-minute patch in upstream gnome-vfs
<Riddell> pitti: I think I already did that, at the distro sprint
<pitti> desrt: they removed all the policy bits
<desrt> pitti; ouch.
<pitti> desrt: I worked around that by adding some volume.ignore policy to our hal package
<Kamion> pitti: cool, thanks! I'll start in on that after this publisher run
<Kamion> pitti: no report for c2man?
<desrt> pitti; sweet.
<pitti> Kamion: c2man is crack and should die
<desrt> <3
<bddebian> heh
<Kamion> ah, so libvformat is being changed?
<pitti> Kamion: I changed libvformat to not use it any more
<seb128> desrt: davydz changed the gnome-vfs code after freezes and changed the behaviour upstream ...
<pitti> Kamion: same for gnulib, I fixed libgd2
<Riddell> pitti: I can't see a gtk build dep 
<Riddell> "* Remove build-dep on xmms-dev to get xmms out of main"
<Kamion> ok, good stuff
<desrt> wow.  i totally love last minute api breaks.
<desrt> ahem
<pitti> Kamion: (the dependency is not necessary)
<pitti> Riddell: ok, so then it's just the wiki page which is outdated. thank you!
<pitti> desrt: yes, that was pretty bad
<pitti> Kamion: argh, libvformat was rejected, uploading fixed pacakge now (s/unstable/dapper/ *brown paperbag*)
<desrt> er.  some bad foo is going down.
* desrt should restart
<desrt> pitti; after a reboot, my 153.7 GB Volume is still here
<desrt> pitti; but my external cdrom drive is now hidden
<desrt>   volume.ignore = false  (bool)
<desrt> on my /mnt/media drive
<pitti> desrt: hm, false is right
<desrt> why?
<pitti> desrt: do you use the latest dapper hal/gvfs, or upstream's?
<infinity> pitti: Speaking of anastacia output, can you make sure that for every libdbX.X we have in main, we have the corresponding dbX.X-util in supported?
<desrt> latest dapper
<infinity> pitti: (Since you're playing with seeds already)
* desrt runs fairly vanilla here
<pitti> infinity: s/are/was/, but I can add it, sure
<pitti> desrt: well ignore = false --> it is shown :)
<infinity> pitti: Having the libs without the utils is pretty bad form (especially since many packages suggest/recommend the utils for recovery and such)
<desrt> pitti; i don't want it shown
<desrt> pitti; /mnt/media is a ext3 filesystem that gets mounted on boot... it's part of my system
<pitti> desrt: you don't want to see your cd-rom drive?
<pitti> ah, that one
<desrt> it's got my oggs :)
<pitti> desrt: right, I left /mnt and /media visible and hide all the rest
<desrt> ah.  i see.
<pitti> it's pretty hard to come up with a default policy which suits everyone
<pitti> s/hard/impossible
<pitti> desrt: this stuff doens't belong into hal at all
<desrt> default policy: if i can mount/unmount it as my user, let me see it
<desrt> if it's fstab root-only then i don't want to see it :)
<pitti> desrt: hal doesn't read fstab, but it would be nice if it did
<desrt> hmm
<pitti> desrt: and second, many peopel statically mount their windows drive and still wnat to see it
<pitti> bah, my typing sucks
<desrt> can we roll back the gnome-vfs change?
<pitti> desrt: we could, of course, but only if upstream does it as well
<desrt> hm
<pitti> which i hope they do
<desrt> excellent.
<pitti> it wasn't well thought out at all
<desrt> in the mean time i wonder why the heck my cdrom isn't in my drivemount applet anymore
<pitti> desrt: I always thought that David wanted to push policy out of hal into gconf
<desrt> it doesn't have an  'ignore' attribute at all
<desrt> which i assume means that it defaults to false
<pitti> desrt: oh, hm, that explains it
<pitti> desrt: not necessarily
<desrt> lemme guess
<desrt> ignore = hal_get_bool(); // returns -1
<desrt> if (ignore)
<desrt>   ...
<pitti> desrt: no, it's FDI policy
<pitti> desrt: but that might still do that approach
<pitti> oh, I'm talking rubbish
<pitti> desrt: ok, so we should make sure that all devices get that attribute :)
<desrt> pitti; hold on a sec
<desrt> pitti; this may not be the problem
<pitti> desrt: can you please send me the hal-device output for your cdrom? I'll deal with that after lunch
<desrt> pitti; under SCSI Host Adapter -> SCSI Device -> SCSI Generic Interface
<desrt> but no 'scsi cdrom interface'
<desrt> and nowhere in lshal do i see 'scd0'
<pitti> oh, iz hal bug then?
<seb128> hum
<desrt> it's recent.
* pitti blames seb128 
<seb128> desrt, pitti: upstream is not going to revert if nobody does complain loud about it
<desrt> seb128; i'm good at complaining loud :D
<pitti> desrt: will you?
<seb128> desrt: so go for it :) I argued it with davydz the day he did the commit and broke it
<seb128> but he somewhere convinced me it was ok
* pitti hesitates to start just another flamewar with David
<seb128> saying using the .ignore hal property stuff works fine, that they are doing it on fedora, etc
* desrt hesitates to start another flamewar, period :)
<pitti> well, but hal is just the wrong place to define that stuff
<seb128> that nobody was using the gconf settings anyway
<pitti> so he made it worse :)
<desrt> can't we take whatever logic was living inside gnome-vfs and move it into hal?
<desrt> anyway.  gotta go to school.  peace.
<infinity> lp_archive@drescher:~$ checkrdepends gnutls11 dapper
<infinity> -- dapper/universe build deps on libgnutls11-dev:
<infinity> [...] 
<infinity> pitti: No more main deps.
<pitti> desrt: no, my point is that it is *wrong* to put it into hal
<desrt> pitti; ah.
* pitti hugs infinity
<desrt> pitti; you'll hear more from me later :)
<pitti> desrt: that's something a user wants to customize
* desrt jets
<pitti> infinity: nice to see my script be useful somewhat :)
<infinity> pitti: Yup, should have had it take nother argument for component, though. :)
* infinity will edit the one on drescher to add that.
<pitti> infinity: so we'll see it in anastacia in 7 minutes
<pitti> infinity: right, easy enough to add
<bddebian> infinity: Sorry to bug you but I have what I hope is a quick question on proftpd.  I set DefaultDir to /archive and created a <Directory> /archive/incoming but when I connect I get dumped into my home dir?
<infinity> pitti: Respecting the ogre model, of course (so, checkrdeps foo dapper restricted would check main/restricted)
<pitti> alright, I'm *finally* going to have some lunch
<pitti> infinity: can you please mail it to me with your fixes?
<infinity> bddebian: DefaultRoot and DefaultChdir are what you want, I htink.
<infinity> pitti: Sure, when I change it.
<infinity> pitti: Which will be later, cause it's 1:30am, and I only stayed up to babysit these builds. :)
<pitti> then, rather enjoy your weekend :)
<infinity> pitti: But I'd written a very similar script last release cycle when I was tracking the libgl-mesa transition. :)
<infinity> (Mine had prettier output, though... Thpt)
<Kamion> pitti: I already added a -b switch to check just one binary package, btw
<Kamion> my bad for not mailing it to you already
<pitti> infinity: I know that I suck at UI :)
<pitti> no problem :) let's just make sure that we unify it at some point
<cpt-carter> Not sure if this is the write channel, but since the official release of Dapper is 1June, will gnome 2.14.1 make it into dapper?
<cpt-carter> Since they are talking about the newer version of KDE
<cpt-carter> gnome 2.14.1 comes out  April 12th
<Treenaks> cpt-carter: yes, it will
* bddebian hugs infinity
<infinity> bddebian: DefaultRoot is a chroot, DefaultChdir defines where the client starts when they login.
<infinity> bddebian: (So, a classic UNIX-life FTP setup would be DefaultRoot /, DefaultChdir ~)
* sivang is back
<cpt-carter> Treenaks: Awesome! Thankyou
<netstar> Does anyone get a warning dialogue pop up for half a second when accessing desktop properties dialogues?  Others are reporting the same.
<giftnudel> how can I debug swsusp hibernating so that I can see some messages (debug if possible) on the screen
<infinity> pitti: Your evms changes are FTBFS...
<infinity> pitti: http://librarian.launchpad.net/1776859/buildlog_ubuntu-dapper-ia64.evms_2.5.4-5ubuntu2_FAILEDTOBUILD.txt.gz
<Kamion> Mithrandir: please merge http://people.ubuntu.com/~cjwatson/bzr/casper/espresso-passwd/ - fixes wrong defaults on espresso's user/password screen
<pitti> infinity: will look at that, thanks; hm, worked for me
<pitti> Kamion: yay, gnutls11 in anastacia :)
<pitti> infinity: bah, that's likely due to the heartbeat installation failure
<Kamion> pitti: and demoted already :)
<Kamion> pitti: indent is a very popular development tool; perhaps we should have it in supported?
<pitti> Kamion: I have no objection
<Kamion> (it was already there anyway as a build-dependency, but wants to fall out recently)
<pitti> Kamion: right, has always been in main, so I can shy around an inclusion report :)
<Kamion> ok, done
<Kamion> and mozilla-thunderbird-locale-* should be in supported for transitional purposes, I think
<pitti> Kamion: right, shall I add them?
<Kamion> pitti: I just did
<pitti> cheers
<pitti> doko: is gcj-4.0 safe to go to universe? we're using 4.1 now consitently?
<pitti> Riddell: konserve is superseded by keep? can it go to universe safely?
<pitti> ogra: if you want gobby in edubuntu, can you please seed it? it currently wants to go to universe again
<ogra> pitti, i dont think pkern fixed it ...
<pitti> ogra: 'it'?
<ogra> howl dependency
<doko> pitti: it should be, but we currently have a problem with hppa
* ogra checks debian
* Kamion seeds mozilla-firefox-locale-* too
<pitti> seb128: AFAIR we added wavpack because gstreamer had a module for it; the current gstreamer hasn't any more?
<infinity> doko: Hopefully we can resolve the hppa breakage next week...
<ogra> pitti, its still depends on libavahi-compat-howl0, even in debian ... i wont be the evil guy pulling the howl compat layer into a 5 year release ... gobby can go to universe :/
<infinity> doko: If 4.0 works on hppa and 4.1 doesn't, the regression can't be too hard to find... Hopefully.
<Kamion> ogra: ok, I'll demote it if nobody objects
<ogra> yup :(
<doko> infinity: 4.1 works on unstable, but not on dapper, pestering jbailey ...
<pitti> Kamion: net6 and obby can go then, too
<Kamion> yep
<pitti> janimo: what about ivman? do you want it for xfce?
<janimo> pitti, we no longer use it
<janimo> it won;t be in default install
<infinity> ogra: What's wrong with libavahi-compat-howl0?
<seb128> pitti: gstreamer0.10-plugins-bad: /usr/lib/gstreamer-0.10/libgstwavpack.so
<pitti> janimo: what's the replacement?
<pitti> seb128: ah, so that's universe now
<janimo> pitti, thunar has built in volmanager
<pitti> janimo: ah, cool
<seb128> pitti: for now, it'll come back probably
<ogra> infinity, upstream will drop it (and support for it) soon 
<janimo> which upstream wants to split out to a sane daemon
<janimo> so ther's going to be a new one apparenyly
<ogra> infinity, thats why we dont build it at all
<seb128> pitti: -bad are stuff lacking documentation, or testing, or maintainer but destined to be moved to ugly or good
<infinity> ogra: Oh, shame.  Kay.  And no work being done (rapidy enough for us, anyway) to port gobby to use avahi natively?
<infinity> ogra: Err, we do so build it.
<ogra> infinity, i havent talked to pkern (upstream) since UVF (where he added that dep one day before)
<janimo> what was the reason for avahi spec not making dapper
<sladen> Kamion: what's the best practice for getting logfiles out of the installer?  Does it have 'scp' or similar in the initramfs at that stage?
<ogra> infinity, what ? 
<Kamion> we do build it, but there was an admonishment in the changelog to never put it in main
<pitti> Riddell: btw, are you aware that *you* are now the bad guy who holds libmad in main? :)
<Kamion> sladen: 'anna-install openssh-client-udeb' to get scp; alternatively, and what I usually recommend to bug reporters, go back to the installer main menu and select "Save debug logs"
<Kamion> one of the items there fires up a mini-web-server so you can fish the logs out
<pitti> Riddell: totem doesn't need it any more, but libakode-dev and libarts1-dev do :)
<Kamion> or you can save to floppy or mounted filesystem or whatever
<pitti> Riddell: and k3b, although this seems to be a stray build dependency
<Kamion> pitti: weird, I wonder why ivman was apparently in breezy main
<Kamion> it doesn't seem to be germinated in breezy
<pitti> Kamion: for KDE maybe
<sladen> Kamion: excellent, thanks
<Kamion> pitti: oh, yeah, it was in kubuntu-breezy desktop
<pitti> Kamion: yep, kubuntu-desktop in breezy
<ogra> Kamion, any idea why ? 
<Kamion> ogra: no
<pitti> well, for autoamtic mounting? 
<pitti> Riddell: what does KDE use now, instead of ivman?
<ogra> the changelog entry doesnt tell a reason ...
<Kamion> "remove ivman since KDE 3.5 includes own
<Kamion> manager
<Kamion> "
<pitti> ah
<Kamion> kubuntu-dapper bzr log
<ogra> slomo, ?? "  * Enable the howl/libdns-sd compat packages. These are to be demoted to
<ogra>     universe and should stay there forever"
<pitti> . o O { it's so nice to clean up the house^Warchive on a Friday afternoon :) }
<Kamion> what about libdvd{nav,read}? that's potentially for gstreamer dvd support, I think
<pitti> ogra: ... so prevent them from ever being demoted :)
<ogra> haha
<pitti> Kamion: AFAIK gst now can read DVDs, but menu support wasn't ported yet
<pitti> Kamion: so I guess dvdnav might stay around eventually
<ogra> pitti, i guess there was a reason for such a sentence :)
<slomo> ogra: that's just a notice that nobody ever gets the idea to promote them to main :)
<ogra> slomo, why ? 
<Kamion> I think part of the question is "why do we build them in the first place?"
<ogra> they are only compatibility layers...
<pitti> Kamion: dvd or howl?
<Kamion> howl
<slomo> ogra: they're to be dropped (and not recommended) by upstream soon and as such not really supportable for 3/5 years...
<ogra> debian builds them ... even for main ...
<slomo> Kamion: because there were many users that wanted them anyway
<Kamion> ok
<ogra> slomo, ok, thats what i thought ...
* pitti wonders why palo is Architecture: any
<Kamion> pitti: it's required on the build machine for building hppa CD images
<pitti> ah
<Kamion> in fact, I should put it in supported for all arches with a comment to that effect, since it's installed on little
<pitti> oh, I just found another excellent cleanup canditate: libxml++2.6 is not needed any more, it's just the doc that keeps it in main
* pitti unseeds, unless anyone speaks up
<pitti> Kamion: do you have a currently pending seed change?
<pitti> Kamion: if so, maybe you could remove libxml++2.6-doc
<Kamion> pitti: will do, just a sec
<pitti> doko: openoffice.org2 can be entirely removed?
<Kamion> pitti: done, will merge
<Kamion> pitti: we might want to keep transitional packages around for upgrades?
<Kamion> (oo.o2)
<doko> pitti: entirely?
<pitti> Kamion: right, but aren't they produced by the ooo pacakge now? doko?
<doko> no, just the binary packages at http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
<pitti> doko: erm, why should we keep the source in main?
<Kamion> doko: those are still built by openoffice.org, I can't just remove them
<Kamion> pitti: I removed openoffice.org2 source a couple of days ago
<pitti> Kamion: the ooo2 transitional binaries shuold stay of course
<pitti> Kamion: ah, my bad, should look closer :) yes, they should be seeded then
<pitti> doko: sorry, nevermind then
<Kamion> as doko observes they're uninstallable at the moment
<Kamion> haven't investigated why
<infinity> Kamion: Is britney not running anymore, or are those binaries hanging around from an old OO.o build?
<Kamion> britney's running ...
<infinity> Kamion: Note that they claim to be from 2.0.1-something, we're at 2.0.2
<Kamion> weird though, I see what you mean
<Kamion> maybe they're ASBA binaries
<Kamion> architecture: any superseded by architecture: all
<doko> Kamion: no, the all packages ...
<doko> yes
<Kamion> soyuz doesn't always manage to kill off the old binaries properly
<infinity> Ouch.
<Kinnison> yeah, that's weird
<Kinnison> We need to track that down at some point
<Kamion> yeah, archive-cruft-check lists them as ASBA
<Kamion> also eclipse and openoffice.org2-evolution
<Kamion> Kinnison: is there any sensible way to get rid of them for now, or should I just leave them there?
<doko> openoffice.org2-evolution is correct
<Kamion> I suppose I could figure out how to make britney ignore them, but that sounds like work
<Kinnison> Kamion: erm, not sure
<doko> that's a binary-arch depdency package (we don't have this for amd64)
<Kinnison> Kamion: they *should* get dominated, but they're not for some reason
<Kamion> openoffice.org2-evolution | 2.0.1oob680m5-0ubuntu2 |        dapper | all
<Kamion> openoffice.org2-evolution | 2.0.2-1ubuntu3 |        dapper | i386, powerpc, sparc
<Kinnison> Kamion: essentially I need to concentrate hard and work it out
<Kamion> presumably it isn't dominated because it's still the newest on some arches
<Kinnison> Kamion: but it's probably a couple of days to reliably reproduce in a small sample set and then a few minutes to fix
<Kinnison> domination is per-arch
<infinity> Do we have the same problem going from any -> all?
<infinity> Or just all -> any?
<Kinnison> I imagine only all->any
<Kamion> I have noticed ASBA binaries disappearing *eventually* sometimes; there used to be four sets in the archive and now there are only three
<Kinnison> Kamion: probably when hppa and sparc catch up?
<Kamion> doko: it can't be correct because it isn't built from newest source
<infinity> Kinnison: hppa, amd64, and ia64 don't build openoffice, you have all the binaries you'll ever have.
<Kamion> unless the old arch: all binary is effectively NBS
<doko> <Kamion> openoffice.org2-evolution | 2.0.2-1ubuntu3 |        dapper | i386, powerpc, sparc
<doko> that is newest sourc
<doko> e
<Kamion> doko: 16:19 < Kamion> openoffice.org2-evolution | 2.0.1oob680m5-0ubuntu2 |        dapper | all
<Kamion> that isn't
<seb128> pitti: "Add missing build dependency libdevmapper-dev and libglib1.2-dev" ... it uses gtk2 but still glib1.2?
<doko> ok
<Kamion> and it's still in the archive, stuck
<pitti> seb128: yes, sadly
<Kamion> Kinnison: what happens if amd64 *never* builds the new binary, as doko seems to be suggesting?
<pitti> seb128: more precisely, the curses interface uses glib
<Kamion> i.e. an arch-specific NBS
<Kinnison> Kamion: probably needs archive-cruft-check to recommend a removal on that arch
<seb128> pitti: hum, k
<Kamion> can I do that if the binary's arch: all?
<Kamion> all - amd64
<seb128> pitti: that's probably trivial to port to glib2.0
<Kinnison> Kamion: I don't know
<jordi> pitti: who do I talk to to get a new pacakge from debian synced into ubuntu?
<infinity> Such confidence!
<pitti> seb128: would be nice :)
<Kinnison> Kamion: I've never tried
<doko> Kamion: "never" in the sense, that we build it still from i386 binaries, which is incompatible with the current 64bit evolution
<pitti> jordi: upload it as Nbuild1, syncs are borked at the moment
* Kinnison is concentrating on getting soyuz mainline into rocketfuel so that infinity can have superseded build support
<pitti> jordi: then pester Kamion to NEW it
<Kinnison> if infinity continues to heckle, I'll remove that patch
<infinity> Kinnison: I'll not heckle. :)
<jordi> ick
<jordi> mvo: ^ can you do that?
* Kinnison tickles infinity under the chin
<Kamion> Kinnison: I think infinity's heckling seb128, not you. :-)
<jordi> pitti: can't upload anything, so...
<infinity> Kinnison: (That patch will reduce hppa's "catching up" from a week to a couple of days, so, yeah. I want it. :))
<bddebian> infinity is still awake?
<Kinnison> Kamion: oh right
<pitti> jordi: which package do we talk about?
<jordi> bddebian: must be pretty late there
<Kamion> infinity: BTW makx is looking for you on #ubuntu-boot
<jordi> ttf-lao; incoming
<bddebian> jordi: Heh, no kidding :-)
<infinity> Kamion: He found me in -kernel. :)
* pitti grabs and uploads
<Kamion> fair enough :)
<jordi> pitti: go for it
<infinity> bddebian: Rumour is that he never sleeps, only sets himself "away" on IRC occasoinally and pretends to not be around.
<infinity> bddebian: I'm not sure if there's any truth to this rumour.
<pitti> jordi: hm, sure? that package is a mere 50kB
<jordi> pitti: checking
<jordi> it's just a font
<infinity> Kinnison: Oh, and for the reocrd, I was heckling you, not seb, though I appreciate Colin's attempt to save my ass. :)
<pitti> jordi: a small one, for a change :)
<jordi> heh
<Kamion> infinity: heh, fair enough :)
<jordi> it covers lao,  and thats all, hopefully
* Kinnison covets his neighbour's ass
<Kinnison> but that's 'cos daf has such a nice donkey
<Kamion> pitti: oh, archive-cruft-check wants to remove libpoppler0c2{,-glib,-qt} but some of them still have reverse-deps
<jordi> pitti: hmm
<pitti> Kamion: oh, right, that requires porting work
<pitti> jordi: ready to upload? I can fire at your command :)
<jordi> pitti: the ttff I've got here is about 120K
<pitti> Kamion: I only ported tetex so far
<jordi> let me check further
<bddebian> infinity: :-)
<Kamion> pitti: oh, right, didn't realise that
<sabdfl> Kinnison: just to be clear. do you want an ass like that of your neighbour?
<sabdfl> or would any old ass do?
<Kinnison> sabdfl: Well, my neighbour's ass is nicer than mine
<pitti> Kamion: *sigh* thanks for reminding me; seb128, did you happen to start with the poppler transition for abiword?
<jordi> pitti: FIRE
* ogra guesses Kinnison wants them furry :)
<Kinnison> ogra: not particularly
<ogra> heh
<pitti> jordi: BOOM, it'll be in NEW in a few minutes
<dholbach> pitti: abiword is built without it
<dholbach> pitti: iirc
* jordi ^5s pitti 
<pitti> $ apt-cache rdepends libpoppler0c2
<pitti>   abiword-plugins
<dholbach> pitti: if we were to use it, the patch is about one line
<dholbach> oh
<dholbach> let me try to find the patch again
<ogra> Kinnison, thats what donkey reminds me on, sorry :)
<ogra> s/on/of/
<Kinnison> are we there yet?
<seb128> pitti: not yet, but seems dholbach has that under control :)
<infinity> Kamion: Would it be possible to get _outdate.txt sorted by package instead of by arch?... It's a bit more informative to see "this is out of date on all arches, probably broken; this is outdated on one arch, should chase up why it failed; etc"
<pitti> Kamion: I'll grab and port kpdf then
<pitti> *sigh* why, oh why did I ever touched that stuff
<infinity> pitti: Masochism.
<infinity> Hrm, britney output for ports is slowly approaching readable again...
<dholbach> pitti: http://www.abisource.com/viewcvs/cgi/viewcvs.cgi/abiword-plugins/wp/impexp/pdf/xp/ie_imp_PDF.cpp.diff?r1=1.2&r2=1.3 :)
<pitti> yay, 48 MB build dependencies for kdegraphics
<jordi> Kamion: any what's the formail way of making you kick ttf-lao in main? mail?
<dholbach> pitti: you want me to do the change for abiword or do you have the source already there?
<pitti> dholbach: YM that s/true/false/ is everything required for libpoppler1?
<pitti> dholbach: no, I haven't, and I'm just scratching my quota with kdegraphics
<pitti> dholbach: can you do abiword?
<dholbach> pitti: ok, I'll poke at it
* pitti hugs dholbach
<pitti> dholbach: it's all Seb's fault anyway, he broke the API with the poppler upload :)
* pitti hugs seb
* dholbach hugs seb too
* dholbach hugs pitti
* seb128 hugs pitti dholbach
<ogra> hey, cant you go to the hug room ? 
<Kamion> infinity: sorted by source or binary?
<seb128> dholbach: I doubt that will fix the FTBFS
<Kamion> jordi: http://wiki.ubuntu.com/UbuntuMainInclusionQueue; pitti reviews main inclusion requests
<dholbach> seb128: I'll be happy to try :)
<jordi> Kamion: thanks
<seb128> dholbach: that's an argument change, I have difficulties to get how it'll fix an API change
<seb128> dholbach: especially it's not even a data type change
<infinity> Kamion: Source would be ideal, same as _probs.html
<dholbach> it's an additional argument
<bddebian> w00t, fucking w00t, dput worked...
<seb128> dholbach: good :)
<dholbach> seb128: good?
<seb128> dholbach: if it fixes the issue that's good no?
<dholbach> I'm quite sure it does... I tried something with abiword before (get an dbg build on amd64 where I needed the patch too)
<dholbach> i'll run it through pbuilder so I'll soon know for sure
<seb128> dholbach: I looked quickly on the patch, I though it was just changing a true but a false
<seb128> dholbach: the CVS commit is misleading
<Kamion> infinity: done
<seb128> dholbach: it says it's a change for poppler 0.5.0, where the API change is poppler 0.5.1
<dholbach> we'll see
<Kamion> yeah, definitely easier to read, that
<infinity> Kamion: Spiffy, that seems immediately much more useful to me.  Thanks.
<seb128> Kamion: got my "enchant" UVF mail?
<Kamion> seb128: yeah, but haven't been looking at UVF exceptions today
<seb128> Kamion: k, this one is trivial ("7 insertions(+), 12 deletions(-)")  if you want to approve it :) 
* mvo wonders if it is only his machine that feel slower when heavy IO is done on current dapper kernels
<dholbach> mvo: pitti wondered that too today
<pitti> mvo: me too
<mvo> pbuilder builds are no fun currently
<pitti> mvo: I noticed it during jigdo
<No1Viking> What to do if  sudo dpkg-reconfigure locales aint working as before? I would like to change so I can use my special characters and UTF-8 in file names.
<pitti> mvo: copying my iso to an iso.old basically locks my machine now
<pitti> BenC: did you recently change anything in the kernel that made reponsiveness during high I/O load drastically worse?
<dholbach> No1Viking: you could use language-selector
<BenC> nothing recently changed that would do that, that I am aware of
<dholbach> pitti, mvo: you guys have been working too long again
<Kamion> No1Viking: or run locale-gen
<No1Viking> Thanks guys!  :)
<pitti> BenC: hmm, I never noticed my machine blocking while copying big files like iso images
<pitti> BenC: anyway, thanks
<BenC> ok
<pitti> BenC: who else can we blame? iz gtk bug?
<BenC> pitti: could be any number of things...does it block when you use cp?
<pitti> BenC: yes, that's what I'm using
<pitti> BenC: (that was just bitching, I don't use gnome stuff in my CD update scripts)
<BenC> ppc, i386, ...?
<pitti> BenC: and I notice it during other heavy I/O operations, too
<pitti> amd64
<infinity> BenC: FWIW, I've noticed it too, but just chalked it up to me being impatient.
<Kamion> seb128: ok, you have mail
<infinity> BenC: -686 here.
<BenC> never noticed it myself, even copying some DVD images around
<pitti> heh, that makes four paranoid people then
<BenC> but I'm on ppc :)
<infinity> Does PPC use libata?
<BenC> does it cause desktop to be jumpy?
<pitti> BenC: not jumpy at all, rather 'frozen'
<infinity> BenC: Jumpy is an understatement.
<BenC> mine's using powermac-ide
<infinity> BenC: It'll just lock the machine hard for a few seconds at a time.
<doko> BenC: it's common on amd64, i.e. when unpacking OOo on a stripe array
<BenC> that's really odd considering 1000HZ and PREEMPT are supposed to prevent that :)
<pitti> BenC: preemt works for I/O, too?
<bddebian> _ion: ping?
<BenC> I have the big-kernel-lock preemptable aswell
<BenC> so yeah, it should preempt i/o aswell
<pitti> hm; lemme try on my slow ppc
<infinity> BenC: I'd guess libata is our common issue here, and perhaps a preempt bug in libata?
<BenC> I have an amd64 and it is using libata, so I can test
<seb128> Kamion: thank you :)
* BenC jumps over to that machine real quick
<pitti> BenC: yep, here it copies around 300 MB without any noticeable responsiveness impact, then it completely locks for 5 seconds
<pitti> BenC: and the hard disk 'sounds' different than in earlier times, as if it would transmit larger chunks now
<pitti> BenC: right, that doesn't happen at all on my ibook; it remains responsive even though it has a much slower hd and cpu
<bddebian> Would anyone happen to know why reprepro is looking for an overrides file?
<BenC> I can't reproduce it
<BenC> I copied 1.5Gigs just now, the whole time dragging my firefox window around while it was loading a large graphic page
<BenC> only a single split second did it jitter
<pitti> BenC: on amd64?
<Kinnison> pitti: on your machine where it locks up, what is your dma/irq settings like?
<BenC> yeah, Athlon 3700+
<pitti>  multcount    =  0 (off)
<pitti>  IO_support   =  1 (32-bit)
<pitti>  unmaskirq    =  1 (on)
<pitti>  using_dma    =  1 (on)
<BenC> I am using sata_nv
<pitti> Kinnison: AFAICT, that didn't change for ages
<Kinnison> multicount zero? yeesh
<Kinnison> but that's not to blame
<pitti> BenC: I have ordinary IDE disks
<BenC> is it on a libata bus though?
<pitti> BenC: I have libata and sata_nv modules loaded as well; my mb has a sata controller, but there's nothing attached to it
<pitti> BenC: how do I find out?
<Kinnison> WTF?
<BenC> is it hda or sda?
<pitti> hda
<BenC> using normal IDE then
<pitti> hdc, precisely
<BenC> I can through a normal IDE disk in there later and try again
<infinity> BenC: Okay, not libata then (though mine is, ata_piix)
<BenC> infinity: is your drive hd or sd?
<infinity> BenC: sda
<BenC> which controller?
<BenC> doh
<BenC> piix
<infinity> Yes. :)
<infinity> ICH6.
<pitti> BenC: hm, am I on crack? after rmmod'ing sata_nv and libata, it just works
<BenC> pitti: what controller is your IDE (dmesg should say)?
<pitti> [   25.045781]  NFORCE3-250: IDE controller at PCI slot 0000:00:08.0
<pitti>    25.045897]  NFORCE3-250: 0000:00:08.0 (rev a2) UDMA133 controller
<pitti> [   25.045906]      ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
<pitti> [   25.045923]      ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
<BenC> amd74xx
<pitti> amd74xx                16944  0 [permanent] 
<jdub> BenC: (should hdparm -i work for libata/sata_sil connected disks?)
<Kamion> bddebian: just use /dev/null as the overrides file if you don't want to override any sections or priorities (which to start with you probably won't)
<BenC> doesn't seem to for mine
<infinity> BenC: Mine's a whacky sata->pata bridge, if that makes a difference (the drive is UDMA133, hanging off the ICH6M sata controller)
<BenC> yeah, that's possible, plus I've heard a lot of shitty things about the piix driver, especially the ata_piix one
<infinity> Gee, good thing that doesn't ship in a lot of laptops with the "Centrino" logo on them, then..
<infinity> Wait...
<bddebian> Kamion: Thx, I just got it.  However it just produced the db "stuff", it didn't move any of the binary files..
<pitti> BenC: is it even remotely possible that merely removing the module fixes it? or shall I measure again?
<BenC> pitti: I'd check again, that would be really odd
<Kamion> bddebian: sounds like you're running something that generates indices, not (say) an incoming package queue processor
<Kamion> not that I've ever used reprepro
<pitti> BenC: ok, will do
<Kamion> and you don't want something that generates indices to move files around!
<Seveas> I found all existing tools to maintain a simple repository so cumbersome I decided to write my own :) 
<bddebian> Hmm, well according to the debian-administration.org it's supposed to create the indices and move the files
<pitti> BenC: ok, I still get the lockups without the module
<BenC> what kind of drive is it?
<BenC> is it really crappy, or a decent drive?
<pitti> BenC: about a year old, a 120 GB hard disk
<pitti> BenC: not really the cheapest one
<BenC> ok
<pitti> SAMSUNG SV1604N
<pitti> oh, 160 GB, but that shouldn't matter
<pitti> BenC: btw, I can reproduce it by continuously doing ls -l on the shell while cp'ing an iso
<pitti> BenC: moving ffox window didn't work, probably because it doesn't trigger (enough) I/O
<BenC> I'll give that a try too
<Pygi> _ion: awake?
<bddebian> If he is, he's MINE :-)
<Pygi> bddebian: lol
<infinity> doko: Do you have any urge to fix up the 3 packages in universe that build-dep on ia32-libs-dev, do it can be safely removed forever?
<_ion> bddebian, pygi: Good morning. :-)
<_ion> pygi: You got my email?
<Pygi> _ion: it's not mornin' ;)
<_ion> Well, i woke up. :-)
<Pygi> _ion: yup, please read response
<_ion> Ah, ok, i looked at my mail server's log  the message's delayed due to graylisting.
<Pygi> _ion: ah, so can you see my response or should I send you to private message here?
<bddebian> Heya _ion :_)
<_ion> pygi: I can't see it until the gmail server tries to resend it. :-) Please /msg it, if you don't mind.
<bddebian> _ion: You were using reprepro right?
<_ion> bddebian: Yep.
<bddebian> _ion: WHen you did reprepro -Vb . include incoming/blah.changes  does it move the .debs for you?
<_ion> bddebian: Not move, but copy.
<bddebian> _ion: Right.  It's not touching the .debs for me :-(
<_ion> bddebian: Oh, actually i haven't tried including some_other_dir/foo.changes, i have always been in the directory where the .changes file is.
<_ion> Try (cd incoming && reprepro -Vb .. include foo.changes)
<bddebian> Then where is your conf/distributions file?  Underi incoming?
<bddebian> Ahh
<_ion> Oh, and the syntax is e.g. "include dapper foo.changes"
<bddebian> Yeah, got that.  Though I'm also doing *.changes, is that ok?
<Pygi> _ion: msg pls
<bddebian> Damnit, it's still just building the db entries, not the pool/for/bar stuff :-(
<_ion> pygi: Hm, i was a bit unclear in my email. I meant that my modified patch should apply to madwifi-old, i made it against the current l-r-modules source.
<Pygi> _ion: o joy, you said -ng ;)
<_ion> pygi: The originals were against -ng, but i applied them manually to the -old source.
<Pygi> _ion: k, great :)
<_ion> And saved _that_ diff to the file in my web page.
<_ion> And, as i said, i have absolutely no idea whether it works. ;-)
<_ion> It needs to be tested.
<Pygi> _ion: perhaps build l-r-m package?
<_ion> bddebian: It doesn't seem to be ok, i have done "for f in *.changes; reprepro ... include ... $f"
<_ion> pygi: Yeah, one of us should do that. :-)
* _ion wonders how long his machine would build that package. It's a 500MHz PIII.
<infinity> Pygi, _ion : I can build a set of LRM packages with that patch for you eight now.
<Pygi> infinity: that would be great...thanks ;)
<_ion> infinity: That would be very nice, thanks.
<infinity> Pygi, _ion : I should have a hot ccache with LRM in it, no big deal.
<_ion> The URL is http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
<Pygi> infinity: your help is appreciated ;)
* infinity freshens a chroot.
<_ion> pygi: Now the e-mail came through. :-)
<Pygi> infinity: can you please send it mine and _ion's mail once you build it? ;)
<Pygi> _ion: o joy ;)
<infinity> Pygi: It won't be that long, I'll just ping you on IRC.
<_ion> pygi: Graylisting is a compromise. It decreases the amount of spam that gets through, but also delays some of the incoming "real" messages.
<Pygi> infinity: kk
<Pygi> _ion: yup, like mine ^^
<infinity> _ion: Who do I credit for this patch?
<_ion> infinity: Well, Robert Love and Dan Williams are the actual authors, i just modified it a little bit in order to apply to the madwifi-old tree. I don't know whether i should be credited about anything, but if you think so, "Johan Kiviniemi <debian@johan.kiviniemi.name>"
<bddebian> _ion: OK, I'm getting closer, any idea on this: ?
<bddebian> Data seems not to be signed trying to use directly...
<bddebian> Missing file pool/main/b/bash/bash_3.1.orig.tar.gz
<bddebian> Does the orig.tar.gz already have to exist?
<bddebian> Or can I get dput to dump up the orig.tar.gz too?
<_ion> bddebian: For the source package, yes.
<_ion> You need foo.dsc, foo.orig.tar.gz and foo.diff.gz
<_ion> And for reprepro's "include" command, the changes file.
<bddebian> _ion: You mean I have to have all that ahead of time?
<_ion> bddebian: Ahead of time?
<bddebian> _ion: They must already exist in pool/main/b/bash/ ?
<_ion> bddebian: Btw., instead of always giving the "-b path" parameters to reprepro, i have 'export REPREPRO_BASE_DIR="${HOME}/src/apt-repository"' in my shell's startup script.
<bddebian> _ion: Well I am going to cron a script at some poin, I just want to get it working first :-)
<_ion> http://archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_3.1.orig.tar.gz
<infinity> bddebian: When uploading a package with no orig, you should build with "-sa", so it gets in the .changes.
<bddebian> infinity: Ahh, thx.
<infinity> (Next upload, of course, you won't have to, cause the orig is already in the repo)
<pitti> dholbach: were you lucky with abiword? It seems I finally managed to port kdegraphics
<Riddell> pitti: what's this being ported?
<pitti> Riddell: new poppler API
<dholbach> pitti: just finshed building :)
<pitti> Riddell: soname 0 to 1
<Riddell> aah
<dholbach> pitti: uploading
* pitti hugs dholbach
<Riddell> what does abiword do with poppler?
* dholbach hugs pitti
<dholbach> Riddell: pdf imp/exp (juding by the filename) ;)
<Pygi> _ion: I have to go now...please send me package once it's done,...also, we won't release just yet...I'll get madwifi card..ok?
<_ion> pygi: Naturally, it will be tested a lot before releasing. :-)
<Riddell> pitti: by the way kpdf in KDE 4 has been ported to poppler so seems like the kpdf authors resolved their differences with the other poppler developers
<pitti> yay, cool
<_ion> pygi: Some people at this chan promised to test the package.
<pitti> Riddell: any hope for kword
<infinity> _ion: uploading packages to pepole.u.c right now...
<pitti> ?
<Pygi> _ion: yup, great ofcourse ;)
<infinity> . o O (pepole?)
<Pygi> hehe :)
<pitti> peephole?
<Riddell> pitti: that's still being planned for, but the kpdf author was having problems last I heard
<pitti> Riddell: I thought kpdf was solved?
<Riddell> pitti: yes, but the kpdf guy was going/is going to do the kword port too
<infinity> _ion, Pygi :
<infinity> deb     http://people.ubuntu.com/~adconrad/networkmanager-lrm/ ./
<infinity> deb-src http://people.ubuntu.com/~adconrad/networkmanager-lrm/ ./
<_ion> infinity: Thanks a lot!
<infinity> NP.
* _ion pokes Seveas.
<Seveas> aight
<_ion> Anyone else with a madwifi card?
<_ion> Oh, hi. :-)
<Burgwork> _ion, yes
<Seveas> _ion, we're gonna need a new NM to test it 
<Seveas> (with the workaround patches applied)
<_ion> So let me see... One needs the network-manager 0.6 package from http://johan.kiviniemi.name/ubuntu/ , the wpasupplicant 0.4 package at http://siretart.tauware.de/wpasupplicant/ and the l-r-m package from infinity.
<_ion> If we're very lucky, WPA _might_ work with that combination. ;-)
<Seveas> _ion, if those nm packages have that patch it may just work ;)
<_ion> seveas: Hm. Is http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00081.html needed? I might have misunderstood your answer the last time (i'm not native English speaker). :-)
<Seveas> there is a patch that supersedes this one
<Seveas> http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00068.html
<Seveas> that one
<bddebian> Fucking A skippy
* bddebian gives _ion and infinity big wet sloppy kisses
<_ion> seveas: Okay, thanks. I'll apply that to my package immediately.
<Seveas> bddebian, I assume you've got something working? I must say i'm glad I didn't help ;)
<bddebian> Seveas: :-)
<bddebian> _ion: Does reprero update Packagages.gz too or do I still need to do something like dpkg-scanpackages?
<bddebian> Packagages.. Heh
<_ion> bddebian: It does everything that is needed when you "include foo bar.changes".
<bddebian> kick ass, thanks again!
<_ion> seveas: The patch didn't apply cleanly to 0.6.1, i had to apply it manually. I'm building the package now.
<Seveas> ah cool, you moved to 0.6.1 already
<_ion> ?
<_ion> My package was 0.6.1 from the beginning.
<siretart> _ion: hi
<_ion> siretart: Hi
<siretart> _ion: whats special about infinity's l-r-m package? (sorry, I didn't follow this channel)
<_ion> It contains these two patches: http://mail.gnome.org/archives/networkmanager-list/2006-March/msg00134.html http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00005.html
<_ion> (backported for madwifi-old)
<shaya> join #latex
<shaya> argh
* _ion thinks he's going to build a binary package from siretart's wpasupplicant 0.4.8 package and put it to his network-manager repo.
<siretart> _ion: dies the new l-r-m package include madwifi-ng?
<_ion> siretart: No.
<siretart> ok
<_ion> Here's the backported patch i came up with, this is what has been applied to infinity's package: http://johan.kiviniemi.name/tmp/madwifi-robertlove-danwilliams.patch
<sabdfl> jdub: ping
<dotwaffle> If I have to mkinitrd once more with dapper, I think I am actually going to scream...
<Kamion> mkinitr*d*?
<zul> welcome to the jungle..
<dotwaffle> Kamion: There are plenty of bug reports out there... The dapper 2.6.15-* kernels don't appear to have a valid initrd for a lot of machines. I know this isnt' tha place to discuss this, so I'll just grunt quietly in the corner ;)
<infinity> dotwaffle: The place to discuss it is to file a bug on initramfs-tools telling me which module(s) your machine needs to boot that I'm not including.
<infinity> dotwaffle: Bug reports "out there" (wherever that is) don't tend to help me much.
<Kamion> dotwaffle: well, my point was more that you shouldn't be using mkinitrd at all with 2.6.15
<dotwaffle> infinity: I can't work out which module - it doesn't detect _anything_ - I've filed a comment on a pre-existing bug, I'll do a little investigation tonight and update the bug to include all the data I can.
<Kamion> if you mean mkinitramfs (or better, update-initramfs), sure
<dotwaffle> infinity: tell me about it - the number of times I get bugs for Xen units with "it doesn't work" under something generic annoys me greatly.
<dotwaffle> ... didn't know there was an update-initramfs - need to get up to date on these new fangled tools =)
<infinity> dotwaffle: Our default initramfs setup doesn't detect anything, it just throws a whole bunch of modules in a fat image and that's what you get.
<infinity> dotwaffle: On BOOT, detection galore occurs, but that's udev, not initramfs.
<Kamion> dotwaffle: if you're trying to use mkinitrd, that would be your problem. :-)
<Kamion> initrd-tools relies on devfs, which is gone
<dotwaffle> infinity: briefly (not to clog up the channel) when the kernel is updated, it will not boot, it gets an alert. To fix, you boot into an old kernel, then do "mkinitrd -o blah bleh" and it works. I've not tried initramfs, I'll give it a go.
<dotwaffle> Kamion: ah, ok.
<dotwaffle> infinity + Kamion: https://launchpad.net/distros/ubuntu/+source/initramfs-tools/+bug/32123
<Ubugtu> malone bug 32123 in initramfs-tools "Cannot find ide hard disk on boot" [Major,Confirmed]  
<dotwaffle> beat you to it ;)
<dotwaffle> let me know if you need anymore info - I'm watching the bug.
<_ion> seveas: Okay, the package in my repo has the patch. Also siretart's wpasupplicant is there.
<infinity> Oh, right, the 4 bugs in one bug bug.
<dotwaffle> i'm new to udev, so i'll have to play around with it, see what's causing the modules not to appear...
<infinity> dotwaffle: Can you produce one of these broken initramfs images on demand?
<infinity> dotwaffle: If so, I'd love a copy of one.
<dotwaffle> infinity: I'll get you one as soon as it next breaks ;)
<infinity> dotwaffle: Thanks.
<infinity> dotwaffle: Bug reports like these are (unfortunately) painfully vague without something tangible to tear apart and examine.
<_ion> seveas: Are there still some patches that should be applied?
<Seveas> _ion, didn't test yet (kinda need my connection at this moment)
<dholbach> bye
<sebest> hello, i'm testing dapper flight 5, but partman isn't starting
<sebest> what should i report to make a good bug report
<Seveas> that partman doesn't start ;)
<Seveas> (and the specifics of your disks)
<Mithrandir> sebest: using debian-installer or espresso?
<sebest> Mithrandir using the debian-installer
<sebest> the strange thing is that it is working with debian
<Mithrandir> sebest: file a bug against partman attaching /var/log/syslog
<sebest> with breezy i mean
<sebest> looking at this file i see nothing unusual
<sebest> the scsi controller is found and the harddisk and cdrom too
<sebest> my previous installation with breezy was using LVM
<sebest> and the last message from partman is that it found the volume group "Ubuntu"
<sebest> but the screen stay blue and empty
<_ion> Blue screen.  :-)
<sebest> Mithrandir : how could i attach /var/log/syslog, i don't have easy way to copy the file, no ssh client or server
<Mithrandir> sebest: install openssh-client-udeb
* sebest googling for openssh-client-udbe
<sebest> it seems that partman was confused by my external usb hard drive
<Mithrandir> sebest: it should handle USB drives just fine.  Dapper supports installing to those just fine.
<Kamion> sebest: you don't need to google for it - just 'anna-install openssh-client-udeb'
<Kamion> then you have scp
<Kamion> or "save debug logs" from the installer main menu
<palong> I can't seem to find where the desicion is made when update-notifier tells the user to reboot. I found the script setting /var/run/reboot-required in the update-notifier sources but I can't figure out when it is called from where. Any hints?
<_ion> Probably from the postinstall scripts.
<wasabi> It's called from each package that needs it, probably.
<wasabi> they probably just touch the file.
<_ion> Confirmed, grep reboot-required /var/lib/dpkg/info/*.postinst
<palong> hm, so there is no way of telling which package is responsible for creating the file afterwards?
<palong> I was thinking of adding this information to update-notifier
<palong> s/no way/no easy way/ :)
<sebest> thanx Kamion, i solved my issue
<wasabi> palong: For what purpose?
<sebest> Mithrandir, i think that partman just took a lot of time to display the UI, and when i swtich to the other tty to see debug message, and switch back to debian-installer the framebuffer didn't accept anymore my input keys
<palong> wasabi: I am often wondering myself if I agree with the desicion that a reboot is indeed necessary. I thought always knowing which upgrade produced the message would help me make that desicion
<_ion> palong: IMO that would be quite nice. Maybe something like this: notify-reboot-required is ran without parameters  just touch the reboot-required file if /var/run is tmpfs. notify-reboot-required with the package name as a parameter: echo "$1" >> /var/run/reboot-required if /var/run is tmpfs. The notifier then shows the list from the file.
<wasabi> palong: I suspect the only reason it makes the message is if the kernel, hal, or dbus are updated.
<wasabi> or udev.
<palong> _ion: but then all the package's postinst scripts would need modification to call the script with the parameter, no?
<wasabi> Maybe udev.
<wasabi> Probably not
<wasabi> Oh, looks like there's more than that now.
<wasabi> But not much. initscripts, ifupdown.
<palong> wasabi: yeah. and if, for example, ifupdown was the cause, I would know, that I don't want to reboot right away, while, if the kernel was it, a reboot might be more important to me.
<palong> wasabi: I know I am probably being a bit pedantic here :)
<_ion> Maybe we should go towards the way Windows works. Just make apt run notify-reboot-required automatically after any install/upgrade operation.
<palong> :)
<lfittl> BenC: ping
<trappist> and run fam on /etc and beg for a reboot if anything there changes
<mroth> sladen: around?
<palong> ok, well, I think I give up, thanks for your kind help.
<sladen> mroth: ack
<Kyral> So D-Day is now in June?
<sladen> Kyral: 2006-06-01
<Kyral> sladen, ty
<sladen> missed opportunity to make it  6.6.6 
<BenC> lfittl: pong
<sladen> that would be such a rocking release date
<lfittl> BenC: when do you plan to upload the 2.6.15-19.28 kernel image?
* Kyral makes a note that for the next Cycle to put down all the dates in an iCal calandar
<BenC> lfittl: tonight
<Kyral> then make it available online lol
<lfittl> BenC: perfect, thanks :)
<mroth> sladen: wanted to get clarification from you on some of the kotkey-setup stuff you wanted me to file re: thinkpad x60
<sladen> Kyral: you still can;  add them to launchpad
<Kyral> "If you are too lazy to remember all the dates, just download this iCal file and import it into your favorite Calandar app" :P
<Kyral> sladen, but does LP allow you to save it :P
<mroth> sladen: for the hotkey-setup bug, which key presses do you want the showkey output from?
<sladen> mroth: yup, can you drop to a console with ctrl-alt-f1 and check what the new fn+(top row) sequences produce.with  'sudo showkey -u'
<sladen> Kyral: you're right, LP maybe be cunningly write-only.  Ask on #launchpad and file a but if you can't export it
<mroth> sladen: entire row?  ok, will do.  and for the acpi-support one, just file as "Fn-F3 is now Battery Not Lock" and include those dmidecode variables?
<sladen> mroth: the Fn+F1-F12 come via ACPI events
<sladen> mroth: it's those new ones (you were having trouble sending  Alt-SysRq and wondering if the Fn-SysRq is actually escaped)
<mroth> sladen: ok, just trying to figure out what you actually want me to file :-)
<sladen> mroth: SysRq, NumLk and Break;  eg. NumLck used to be accessed via  Shift-NumLock  on the IBM ThinkPads
<mroth> sladen: so you want the showkey for SysRq NumLk and Break on the acpi-support bug
<mroth> sladen: filed the acpi-support in #35395, let me know what to add to it.   going to work on getting the showkey values for the hotkey-setup one now
<hunger> Is language-selector giving a traceback on upgrade a known problem?
<jcole> how do i get vnc-java to work with vino? i used to use the X vnc module, but that doesn't seem to work in ubuntu
<sladen> Ubugtu: why didn't you pickup #35395, ?
<sladen> Ubugtu: why didn't you pickup #35395 , ?
<hunger> Why is fontconfig needed on a no-gui system? I assume it is pulled in by cups somehow?
<sladen> Seveas: Ubugtu didn't seem to see the above bug number and turn it into a nice URL
<LaserJock> sladen: go easy on the poor fella ;-)
<sladen> LaserJock: yeah, I wondering if the regex required a space after, rather than a comma
<Seveas> sladen, why would it?
<Seveas> it needs 'bug'|trackername (bug')?
<Seveas> (pseudo-regex style)
<sladen> Seveas: ah, so bug #35395
<Seveas> bug #35395, #35394
<Ubugtu> Malone bug 35395 in acpi-support "Changed Keyboard Layout on new Thinkpad models" [Normal,Unconfirmed]  http://launchpad.net/bugs/35395
<Seveas> -Ubugtu- Error: This bug is private
<Seveas> (for 94)
<mroth> sladen: hotkey-setup as bug #35396
<Ubugtu> Malone bug 35396 in hotkey-setup "New Keyboard Layout in Thinkpad X60 Series" [Normal,Unconfirmed]  http://launchpad.net/bugs/35396
<Seveas> sladen, I doubt that matching #\d+ without preceding bug/trackername would be useful
<jdub> hunger: it's used by various command line programs that use fonts (image rendering libs, document creation tools, etc)
<sladen> Seveas: nod, ta.  I wondering about automatching the same string in the wiki rather than requiring  [https://launchpad.net/bugs/1234 #1234]  everytime
<Seveas> sladen, that would be doable
<Seveas> something like s!bug:#?\d+!http://launchpad.net/bugs/\1!
<Seveas> should be easy to work out for a moin guru
<sladen> mroth: you can use  sudo showkey -u | tee -a thinkpad-x60s-keys.log  to make things easier
<mroth> sladen: hrm, even with showkey running, it seems to like to hibernate on me when I hit Fn-F12, which is what i'm looking into right now
<mroth> and since it cant properly wake up from hibernate, that gets complicated to test ;-)
<sladen> mroth: that sends an ACPI even, you can ignore those since we know what they are
<mroth>  sladen ah, so you want... which ones?  most of them seem to send ACPI events, and not showkeys
<sladen> mroth: But I am interested whether oddities like  Fn-Ins  Fn-Backspace  Fn-Delete still generate events  (but only for my own personal curiousity)
<sebest> is there any hope that apple keyboard will be supported on ubuntu i386 ?
<jcole> does ubuntu's vino have java support?
<sladen> mroth: the combinations marked  SysRq, NumLock, Break, Fn-Left/Right/Up/Down
<jcole> "sudo apt-get install vnc-java" makes vncserver work, but not vino
<sladen> sebest: yes, should work out of the box.  Please ask on #ubuntu
<sebest> sladen: i know how to get it working, but i'd like it to work out of box
<sladen> sebest: please file a bug report with the sequence that you had to use to get it to work
<sebest> sladen: i just installed dapper flight 5 and it doesn't work "out of box" , i suspect it is because my locale is french
<jcole> i usually use a stunnel wrapper around vnc java so i can it access via browser encrypted
<jcole> https
<sebest> sladen: what do you mean by "sequence" ?
<sladen> sebest: the set of operations.  The list of commands that you had to use to configure the Apple keyboard to work correctly.  This is so that that list of commands can be automated.
<sebest> sladen: ok, but i must download a separated package to have the right keymap
<jcole> in conjunction with the /usr/X11R6/lib/modules/extensions/vnc.so module... which is borked in ubuntu for some reason
<sladen> sebest: please include that Link aswell
<sebest> sladen, ok will do right now
<sebest> sladen thanx
<sladen> jcole: run  dpkg -S /usr/X11R6/lib/modules/extensions/vnc.so  and file the bug against whichever package it belongs to
<mroth> sladen: so far the only things with Fn blue text that appear to produce showkeys events are: SysRq, NumLk, Break, and the start/stop/play/pause keys mapped to the arrow keys
<jcole> sladen: there's already a bug report, vnc4server is in universe so who knows if it'll get fixed... i was however the ubuntu way of doing vnc java... ubuntu's "Remote Desktop" uses vino, but i can't figure out how to add java support to it
<sladen> mroth: and tapping and releasing  Fn  without pressing anthing else?
<jcole> s/i was//g
<mroth> sladen: yes, that produces a code too
<sladen> mroth: Do the volume/ThinkPad/Fn-Space/Brightness keys still go via nvram or via a keystroke?
<sladen> mroth: (do  sudo killall thinkpad-keys  first)
<sladen> mroth: btw, thank you for following this up interactively!  Makes it alot easier to catch everything in one go
<mroth> sladen: I have no thinkpad-keys process running (and have never noticed one before).  nope, the volumne, thinkpad, etc don't generate showkeys, so my assumption is nvram?
<sladen> mroth: back and forward  should send keycodes too
<mroth> sladen: yep, documenting them all now
<sladen> mroth: groovy! :)
<jcole> sladen: i'll just hack together another vnc ssl solution
<sladen> jcole: to server up the java-binary you'll need a mini-webserver running I guess?
<jcole> sladen: vnc-java does that
<jcole> sladen: but it needs to tie in with vnc4server
<jcole> sladen: i don't know how to make vino work with it
<jcole> sladen: also, i don't know how to make the ubuntu vino work with the gdm login screen
<jcole> sladen: i think vino is more for simple things like sharing and not for administrating
<jcole> bingo!
<jcole> it works now
<jcole> heh
* jcole tries
<_ion> seveas: Have you been able to test the packages yet?
<Seveas> _ion, no, I've been working on more important things 
<_ion> Ok.
<jcole> dang, doesn't work
<jcole> nm
<jcole> jcole@jcubuntu-p4smp:~$ vncserver
<jcole> Found /usr/share/vnc-java for http connections.
<jcole> i think vncserver (vnc4server) embeds the jvncviewer applet (vnc-java) in a mini webserver
<jcole> who knows, it's a friday... forget it, i'm done for now :)... later all
<carlos> simira: hi, around?
<simira> carlos: on my way off, but I can hold a minute or two for you
<carlos> simira: thanks. It should be fast
<carlos> simira: https://launchpad.net/rosetta/imports/?status=NEEDS_REVIEW&type=po
<carlos> simira: what should I do with those no.po files?
<carlos> import them, import them as nb.po ? as nn.po? ignore?
<carlos> simira: we are importing now Dapper
<carlos> and we are able to block those files from being imported
<simira> carlos: ah, great. Can you rename them to nb.po?
<simira> carlos: great timing, btw, I'm clearing out Ubuntu issues tonight. :)
<carlos> simira: well, more than rename, I can import them as nb
<carlos> simira: but what will happen with nb translations?
<carlos> are they exactly the same?
<simira> carlos: yes
<simira> they should be, at least
<carlos> hmm, then perhaps is better that we just ignore those no.po files
<carlos> as will not be lost because the nb.po files will be imported as usual
<simira> carlos: as long as there's nb.po-files, that would be ok, yes
<carlos> simira: ok, blocking the files mean that they will stay on the import queue for ever
<carlos> simira: with the 'blocked' status set
<carlos> if you miss anyone, you can always ask for a change on that entry and we will import that no.po file as nb.po
<carlos> does it works for you?
<simira> carlos: you can probably throw them away. Do you have any option to import the newer one of nb.po/no.po?
<simira> else, that works fine, yes
<carlos> well, yes, but sometimes, implies some extra work on our side
<carlos> we can try importing the no.po as nb.po and if it adds too much work to us then move to the blocking procedure I just told you about
<simira> ok. Just have the nb ones then
<carlos> ;-)
<simira> sure, that's great. I'm happy to get rid of no :p
<carlos> we are not able to agree :-P
<carlos> I will try to get rid of any other no pofile we already imported by mistake on dapper so we can tag dapper as a 'no' free zone
<carlos> ok?
<simira> carlos: you're an angel if you manage that. I won't crucify you for any no that would happen to show up, I promise
<carlos> simira: ;-)
<carlos> simira: feel free to file bug reports if you find anyone
<carlos> but give me a couple of weeks to clean up the system ;-)
<simira> carlos: I'll have a look on it. You're doing great work anyway. I'll come bother you at the next conference, whenever that is...
<carlos> ;-)
<carlos> I take your word
#ubuntu-devel 2006-03-23
<carlos> does that expression exist in English?
<simira> I think so
<carlos> ok ;-)
<simira> but I think Tollef will be asleep soon if I don't get off. Good night!
<carlos> simira: night
<carlos> simira: thanks for your help
<simira> carlos: np, keep up the good work
<MrFaber> hi all
<MrFaber> Anyone useing a second monitor with dapper?
<Burgwork> MrFaber, #dapper+1
<Burgwork> sorry, make that #ubuntu+1
<MrFaber> nomeata, it is a bug I think
<MrFaber> thats why I ask
<MrFaber> because xorg ignores modes, but ok, I can ask there at first
<Burgwork> if it is a bug, please file it
<Burgwork> this channel is for your discussion of the solution
<MrFaber> I don't know, maybe it is a driver bug
<MrFaber> ok
<_ion> Anyone with a madwifi card and a WPA WLAN willing to test NetworkManager 0.6's WPA support?
<Burgwork> _ion, I have a madwifi card at home I can test. I will be at home in about 3 hours
<siretart> _ion: I can perhaps try tomorrow, but more likley next week
<_ion> burgwork: I'm probably asleep by then, but what i'd like you to test is 1) does WPA work with the newest n-m package from http://johan.kiviniemi.name/ubuntu/ and 2) does it work with that package after installing the patched linux-restricted-modules package from "deb http://people.ubuntu.com/~adconrad/networkmanager-lrm/ ./"
<Burgwork> _ion, will do
<_ion> Thanks!
<MrFaber> just want to report that cpu scaling doesn't work with 686 kernel, only with 386 in Dapper, thx, and cu
<pschulz01> Test message
<Lathiat> pschulz01: Sorry it didn't work
<_ion> I hadn't quite thinked the version numbering scheme for my packages through, so i changed it a bit. I apologize for the inconvenience, but if you had installed the packages from my repository earlier, please run: sudo apt-get update && sudo apt-get install {network-manager,nm-applet,libnm-util-0}'=0.6.1-0ubuntu*'
<Pygi> _ion: ping
<_ion> pygi: Pong
<Pygi> _ion: agreed, we'll setup a wiki page later today,ok?
<_ion> pygi: Ok.
<Pygi> _ion: when I come to IRC, we'll just agree on what to include there, and we'll write it, that shouldn't be a problem
<_ion> Yep.
<Pygi> _ion: it's kinda too late now, but if you really want, we could do it even now?
<_ion> Later today is fine for me, i'm thinking of going to sleep soon. :-)
<Pygi> _ion: o joy ;)
<Pygi> _ion: just thinking ;)
<_ion> Well, i'm considering watching some TV show before going to sleep. :-)
<_ion> Oh, btw., i wrote this just before you joined: < _ion> I hadn't quite thinked the version numbering scheme for my packages through, so i changed it a bit. I apologize for the inconvenience, but if you had installed the packages from my repository earlier, please run: sudo apt-get update && sudo apt-get install {network-manager,nm-applet,libnm-util-0}'=0.6.1-0ubuntu*'
<jdub> Kamion: ping
<jdub> Kamion: ping (now with payload, QA)
* mjg59 hacks the Mac a bit harder
* jdub hugs mjg59 
<mjg59> Almost have autodetection of screen resolution, though admittedly with a rather nasty elilo hack
<jdub> mjg59: i am disappointed that all this hackery on the maccery hasn't resulted in more gargargar on your pigblog
<mjg59> Pff
<mjg59> I am not your dancing monkey, pony or bear
<jdub> Bill odia a los nios!
<jdub> oh
<jdub> i totally misunderstood our relationship
<_ion> I knew from the beginning that he refuses to dance.
<mgalvin> jdub: ping?
<Kamion> jdub: ?
* Kamion is around until his mad espresso hack works, then going back to bed
<Kamion> Woo. Disk selector.
<Kamion> of course exactly what it'll do with only one disk present is still up for debate
<jdub> mgalvin: pong! been wanting to catch up with you :)
<mgalvin> jdub: hey, howdy!
<mgalvin> jdub: you got my email i guess?
<jdub> uh, not yet i don't think - like, very recent?
<mgalvin> yea, the other day, like 2-3 days ago
<jdub> oh
<mgalvin> anyway, was just about getting on ubuntu planet
* jdub was thinking recent in hours ;-)
<jdub> mgalvin: oh yeah, you didn't include an rss url
<mgalvin> jdub: http://people.simplifiedcomplexity.com/~mgalvin/feed/
<jdub> heh
<jdub> that's a convincing start to your blog ;-)
<mgalvin> meh, a small start ;) i have been moving all my stuff on to a new server when i have time, i'll be chatty once the server move is done
<jdub> i like the domain name
<jdub> i've just updated the configs - next cron you'll b on
<mgalvin> cool thanks! :)
<Burgundavia> mgalvin: cool, add more doc people!
<mgalvin> jdub: hey while i have you here, who do i poke about an @ubuntu.com email alias
<jdub> mgalvin: elmo, i think (i thought the procedure was on the website, but that could be a brainfart)
<mgalvin> ok, i will hit him up for that, thanks again!
<Burgundavia> jdub: do we have a strategy for installation reports?
<Burgundavia> jdub: people are mailing them to ubuntu-users
<Kamion> Burgundavia: ubuntu-users is not too bad for installation reports
<Burgundavia> Kamion: don't they contain useful data that we would want to capture somewhere?
<Burgundavia> I guess we need a hardware database before we can start channeling things like that to it
<Kamion> Burgundavia: for the most part the usefulness is more in terms of figuring out what bits need to be turned into bug reports
<Burgundavia> Kamion: true. Maybe they should spat in LP support requests then?
<Kamion> I'm not sure they map well for those
<Kamion> just at the moment, mail is easiest
<Kamion> people are mailing them to ubuntu-users@ because we tell them to, at the moment
<Burgundavia> yes
<infinity> I have issues with them on ubuntu-users for now, though an ubuntu-installer mailing list may become more appropriate as the team is forced to grow to ease Kamion's growing burden (and spread some knowlege around)
<infinity> s/have issues/have no issues/
<Burgundavia> ok, sounds good
<Kamion> there are very few anyway
<infinity> Having them auto-submit to a hardware databse is only useful when the install is actualy successful, and while we do want successful (and semi-sucessful) reports, the most useful reports are the complete and utter failures.
<Burgundavia> successful install stories are good if we can setup a way for people to browse for specific pieces of hardware. That is a not an easy task and may not be worth the efoort
<infinity> It can be done, but not for this release, I'm sure.
<Burgundavia> we would need a backend before we can even start thinking about backends like that
<Burgundavia> frontends, I mean
<sivang> morning all
* sivang glances at the backlog
<sivang> Burgundavia: worth a spec for sure
<Burgundavia> sivang: better to tack it on to a an existing spec on hardware data capturing
<sivang> Burgundavia: even better, yes.
<sivang> Burgundavia: I'm working hard btw so you can see backup hotness ;-)
<Burgundavia> very cool
<Burgundavia> how is the rest of your life?
<sivang> Burgundavia: mostly revolves around this cool project which I hope to deliver soon, my dayjob and a a couple of hours's rest in the weekend, catching up a comdey act once in few weeks.
<sivang> Burgundavia: anh in the remaining time, my gf.
<sivang> Burgundavia: (we were in a good show last night, sort of andy kaufman's type of humor, adopted to Israel current affairs , colors and ethinc groups)
<Kinnison> Remind me never to party with ddaa again
<Kinnison> Nor to let jblack buy me "a" drink
<mpt> haha
<Burgundavia> Kinnison: heh
<Kinnison> mpt: I feel fine
<mpt> It was a very *pretty* row of drinks ...
<Kinnison> mpt: I just didn't wake up until nearly 10
<Burgundavia> Kinnison: I haven't gone to bed yet, so...
<Kinnison> Burgundavia: *g*
<mpt> Kinnison, so you're not the Launchpadder who is reportedly still in the throes of throwing up?
<Kinnison> Burgundavia: We drank the bar out of absinthe and curaao
<Kinnison> mpt: god no, I never vomit from alcohol
<Pygi> _ion: awake? ;)
<mpt> Maybe it's ddaa
<Kinnison> perhaps. He did drink a *lot* of absinthe
<Robot101> Kinnison: nor me, just the blood poisoning the next day.... :P
<Kinnison> Robot101: as I said, I feel fine, no bad head, no aches, no UDIs just didn't wake up until 10 and that's unusual for me
<mpt> Some people get their kicks from alcohol ... I get my kicks from watching the effect of alcohol on others ;-)
<tseng> mpt++
<Kinnison> mpt: I enjoy that too, most of the time that's what I do. Last night I decided I wanted to be the one being laughed at. It was fun
<Burgundavia> ugh. I had to excort a roommates friend home tonight, after my roommate (female) and her fought
<Kinnison> mpt: So you enjoyed Maominoes?
<mpt> Kinnison, generally yes, though I was annoyed by the inconsistency in the way the rules treated what the value of a domino half was
<mpt> i.e. face value vs. effect
<mpt> Thanks for bringing them to the workshop :-)
<Burgundavia> are you lot someone for an LP sprint?
<Kinnison> mpt: there was no inconsistency, just the subtleties of is/matches/acts-like and free ends versus closed ends
<Kinnison> Burgundavia: Yes, this week just gone was the first of two weeks of LP hacksprinting.
<sivang> Kinnison: what was the party reason? how did ddaa manage it? :-)
<Kinnison> sivang: landing the huge (> 21,000 line diff) soyuz patch into mainline launchpad
<sivang> Kinnison: oh god
<Kinnison> Burgundavia: And this was the week of Canonical prototype seven tile double-fifteen maominoes
<Pygi> _ion: Don't tell me you are sleepin' again? ;)
<sivang> Kinnison: (> 21,000) is huge. did pqm like it? :p
<Kinnison> sivang: eventually
<sivang> hehe
<Kinnison> Anyway, it's 11:30 and I have to check out by 12:00 so I need to go, pay the bar tab, and head home
<Kinnison> I get to sleep in my own bed tonight \o/
* Kinnison starts taking bets on whether or not he stays up all night playing Evil Genius
<zyga> sivang: hi
<zyga> sivang: do you have a moment?
<Kinnison> ciau
<zyga> in u-desktop
<sivang> ciau Kinnison 
<Pygi> _ion: please do wake up ^^
<pitti> Kamion: yay, no promotions in anastacia any more ;)
<Mithrandir> why does ejecting a cd-rom say "writing data to device $dev"?
<tseng> Mithrandir: thats been fixed according to changelog
<tseng> it is meant for unmounting usb flash only
<pitti> Mithrandir: hm, does that still happen with the latest nautilus version?
<hendry> I just did a update with dapper
<hendry> and I restarted the computer as suggested. And it hasn't restarted. It frozen on "Checking battery state"
<Fjodor> Hey. I noticed a considerable slowdown when running seti@home on my amd64-system and a 64bit seti client. So far, I think I have found the error to be a missing patch to glibc a la http://forums.gentoo.org/viewtopic-t-376943.html from gentoo. I might be able to create a patch for ubuntu glibc, but would you guys be receptive to such a patch?
<pitti> Fjodor: if the patch is reasonably obvious and nonintrusive, and does not change the API and ABI, then it has a very good change to be adopted
<pitti> Fjodor: and thanks in advance for that effort!
<Fjodor> Goody. I run breezy here, but I would suspect it to be a change for dapper. Is that correct?
<pitti> Fjodor: right
<pitti> Fjodor: we won't change these things in stable releases, it's just too risky
<Fjodor> Seems reasonable. Time to make a new chroot with dapper then
<Pygi> _ion: ping
<_ion> pygi: Good morning. :-)
<Pygi> _ion: yes, yes, good Mornin'
<Pygi> let's discuss it
<Pygi> _ion: pm
<Fjodor> As discussed with pitti, I would like do make some changes to glibc and send a patch your way, but how do I go about extracting the source after apt-get source glibc? I am rather new to debian/ubuntu
<crimsun> it's already extracted if you use apt-get source
<infinity> Fjodor: "debian/rules unpack"
<infinity> crimsun: glibc is tarball-in-tarball, so it's not quite unpacked when you unpack it. :)
<Toadstool> crimsun: it depends, some packages such as glibc (IIRC) contain the debian dir and a tarball dir with upstream tarballs
<crimsun> I stand corrected
<Kamion> debian/rules unpack^Wextract^Wpatch^Wapply-patches^Wstampdir/patch^Wpatch-apply^Woh-god-I-want-to-die
<infinity> Fjodor: And ater the "unpack", "debian/rules patch" if you want to apply all the patches in debian/patches.
<infinity> Kamion: Win'n'Pen is waiting for a hacker to implement (and frickin' ship) it...
<Kamion> people could freaking agree on ONE TARGET NAME without that
<infinity> Kamion: Also, you forgot the oh-so-intuitive DBSism of "source.make"
<Kamion> infinity: and also make -f debian/sys-build.mk whatever-it-is
<Kamion> or is it debian/scripts/sys-build.mk? don't know, don't care
<infinity> That's "source.make"
<Kamion> what gets me is that I've never *once* seen a package that aliases any of the other common target names
<infinity> I saw one just the other day, actually.
<Kamion> just that would improve usability of source packages so much, without anyone having to give up their pet name
<Kamion> oh, which one? I need to send its maintainer flowers
<infinity> I'll let you know when I see it again. :)
<Fjodor> Thanks
<infinity> Kamion: It had extract/unpack as aliases, and patch/dopatch, and something else.
<infinity> Kamion: No source.make, but I can't imagine that's ever anyone's first try.
<infinity> Kamion: My MO when lazy is usually just to do "debian/rules build" and hit Ctrl-C... <smirk>
<infinity> Kamion: I could deal with an optional (but strongly recommended) "debian/rules help" that explains WTF the build system does.
<infinity> Kamion: Might be nice to explain your interesting pet targets for debian/control regeneration, unpacking source, updating upstream stuff, blah blah.
<infinity> Kamion: Perhaps if dh_make included a templated help target that explains the default rules, it would prompt people to add their custom rules to said output.
<Kamion> might not hurt ...
<infinity> (And, sneaking it into dh_make would make it a defacto standard over time, allowing for a policy amendment; see, I'm clever sometimes)
<netstar> gstreamer on PPC is slooooooooooooooooow
<netstar> we're talking 99% CPU
<LaserJock> hmm, sound like fun :(
<netstar> not at all
<pagux> hello can I ask a shell scripting  issue in  this channel ?
<pagux> i am writting a small script ...on ubuntu 5.10
<pagux> how can put result of a command into an variable?
<pagux> $count =/opt/lampp | wc -l    -> does not work ?
<LaserJock> pagux: you are writing a Debian and Ubuntu 5.10 shell script at the same time? ;-)
<netstar> Any PPC users?
<pagux> i want to count of files in paerticular to be put in an variable
<highvoltage> netstar: yes, there are hundreds and thousands
<netstar> Ha
<netstar> Are you running Dapper on ppc?
<LaserJock> pagux: does $count =`/opt/lampp | wc -l` work?
<pagux> no it displays ->/opt/lampp | wc -l rather than output of command
<_ion> pagux: You should read some scripting tutorial. No offence, but everything in that example is wrong (assuming you mean sh scripting). :-)
<highvoltage> netstar: nope, i run on i386
<highvoltage> netstar: i'm sure you'll find some on #ubuntu?
<pagux> actully i am writting a install script for xampp
<netstar> I need some Dapper users
<netstar> gstreamer is mush on my machine
<Fjodor> My glibc is now changed to include the amd patches, and I have made a diff with diff -Naurp build-tree buildtree.patched. Where do I send it?
<highvoltage> pagux: why do you need a script to install it? it's just a tarball that you extract and it works?
<LaserJock> netstar: you could try #ubuntu+1 I suppose
<netstar> thanks yeah
<netstar> should've thought
<wasabi_> Why would hte name of a directory result in anything?
<wasabi_> /opt/lampp
<wasabi_> isn't it?
<pagux> highvoltage: bcos it only works  when extracted in /opt/lampp  directory
<pagux> wasabi_: i want to check there was a previous xampp installation in yes then back it up
<wasabi_> You want to check if the directory EXISTS?
<wasabi_> Or if it has files in it?
<pagux> both 
<wasabi_> Well, small explaination. wc -l counts the number of lines that are piped to it.
<wasabi_> Try this:
<wasabi_> echo 1 | wc -l
<_ion> Has anyone (with madwifi hardware) tested the patched linux-restricted-modules package yet?
<pagux> i know that ...i want to count no files in an directory ....thats working ...but I want store this value into an variable 
<pagux> count='ls /etc | wc -l';echo $count ->> not working 
<_ion> How about reading some scripting tutorial, and reading others' scripts?
<pagux> _ion: if you  solution then tell it otherwise .... ;-)
<Pygi> _ion: heh, you are alive ;)
<Pygi> _ion: Seveas *is* testing
<_ion> Somewhat. :-)
<_ion> Nice.
<pagux> i got the solution 
<Seveas> I'm seeing lots of names of people I don't know on the dapper-changes list
<Seveas> people who aren't in any launchpad teams either
<HiddenPuppy> yeah
<Seveas> How is that possible?
<Seveas> Maintainer: Sam Pohlenz <retrix@internode.on.net>
<Seveas> Changed-By: Sam Pohlenz <retrix@internode.on.net>
<Seveas> Maintainer: Francesco Paolo Lovergine <frankie@debian.org>
<Seveas> Changed-By: Jeremie Corbier <jeremie.corbier@resel.enst-bretagne.fr>
<LaserJock> People upload for other people
<Seveas> Then how are they authenticated?
<LaserJock> A motu or core-dev signs them
<Seveas> ah
<LaserJock> but they don't touch the actual packaging, and hence the changelog
<Seveas> interesting
<Seveas> I really think the name of the person who signs/uploads it should be visible in either the changelog or in the mail to dapper-changes
<LaserJock> I think you can get that info other places perhaps
<LaserJock> Seveas: In reality I don't know if it really matters much with team maintainance. If there is a problem them I suppose there is a log of who uploaded somewhere.
<Seveas> well, in case of theings being uploaded for non-developers the uploader takes responsibility
<LaserJock> sure
<LaserJock> but the non-developer did the work
<LaserJock> but I can definately see both sides of the argument. It is the same way in Debian though
<ajmitch> Seveas: every mail on dapper-changes will be signed by the uploader
<ajmitch> so it's esay to check who uploaded 
<Seveas> ah, nice
<Seveas> thanks
<Fjodor> I talked to pitti about patching glibc with some amd64 patches. I have done so now, and am ready to hand over the patch to you guys. Where do I send it?
<Seveas> try pitti ;)
<Fjodor> Nice idea Seveas :-), but I don't have his address, and he isn't online. Do any of you know him?
<Seveas> Fjodor, martin.pitt(a)ubuntu.com
<Fjodor> Thanks
<_lemsx1_> how can i fix this? 
<_lemsx1_> sudo apt-get install xorg-driver-fglrx=6.9.0-8.23.7+2.6.15.7-1
<_lemsx1_> dpkg-divert: rename involves overwriting `/usr/lib/fglrx/libGL.so.1.xlibmesa' with
<_lemsx1_>   different file `/usr/lib/libGL.so.1', not allowed
<_lemsx1_> dpkg: error processing /var/cache/apt/archives/xorg-driver-fglrx_6.9.0-8.23.7+2.6.15.7-1_i386.deb (--unpack):
<Seveas> _lemsx1_, first remove all fglrx packages then install what you want
<mjg59> _lemsx1_: I'd suggest not trying to install old packages on a different release
<Seveas> _lemsx1_, and #ubuntu-devel is NOT for support - please go to #ubuntu
<_lemsx1_> Seveas: i was planning to open a bug... just wanted to make sure
<Seveas> _lemsx1_, this is probably because you do things you shouldn't (installing non-Ubuntu packages), which will only be rejected in the bugtracker
<_ion> seveas: Sorry for bugging you again, but have you been able to test the n-m stuff with madwifi yet?
<Pygi> _ion: I asked...
<_ion> Ok.
<Pygi> _ion: he's working on ubugtu
<Pygi> _ion: let's stop buggin' people around for now ;) at least until *yours* later tommorow
<Pygi> _ion: agreed? ^_^
<_ion> Yep. :-)
<_ion> seveas: Just in case you didn't notice this the last time i mentioned it on this channel: < _ion> I hadn't quite thinked the version numbering scheme for my packages through, so i changed it a bit. I apologize for the inconvenience, but if you had installed the packages from my repository earlier, please run: sudo apt-get update && sudo apt-get install {network-manager,nm-applet,libnm-util-0}'=0.6.1-0ubuntu*'
<Seveas> _ion, that explains the lack of updates :D
<Pygi> Seveas: hehe ;)
<Seveas> anyway, since Ubugtu is quite broken now I can't test
<Pygi> Seveas: no problem at all...take your time ;)
<LaserJock> Our beloved Ubugtu! Broken? :(
<Seveas> yeah, I'm trying to correct the debian bug handling (which was quite broken)
<_ion> In what language is Ubugtu written, btw.?
<Seveas> python
<LaserJock> I hope him/her/it makes it through the surgery ok ;-)
<Pygi> _ion: lemme guess...python perhaps ? ;)
<Seveas> he will
<_ion> Ok.
<Pygi> joy, seveas was faster :-P
<Seveas> and in a few hours he'll also understand trac
<nekohayo> I think the remote desktop server crashes when someone tries to connect in dapper, could anyone try to confirm this so I file a bug if there isn't one yet?
<dotwaffle> nekohayo: doesn't happen here (assuming vnc)
<dotwaffle> nekohayo: just logged in, no trouble (using Chicken of the VNC on OSX)
<nekohayo> yeah, well the gnome remote desktop thing
<dotwaffle> nekohayo: you mean to connect to ubuntu or to connect from ubuntu to something else?
<nekohayo> connect to ubuntu using vncnviewer or tsclient or anything
<dotwaffle> works fine here :(
<nekohayo> I see this in my .xsession-errors file o_O: +1142720916.875581 Session manager: gsm-remote-desktop.c:107: remote desktop server died, restarting
<nekohayo> oh! it works the other way around
<nekohayo> I'm assuming it is XGL's fault
<nekohayo> what should I file the bug against, xserver-xgl or the remote desktop tool?
<Seveas> why oh why is the debian bts sucking so hard...
<Seveas> </rant>
#ubuntu-devel 2006-03-24
<netstar> How does dapper play video DVDs?
<Amaranth> it doesn't
<Amaranth> without extra stuff not in ubuntu
<netstar> What stuff?
<netstar> :P
<Amaranth> i can't remember, i watch DVDs on my DVD player :P
<Amaranth> this is off-topic for #ubuntu-devel though
<netstar> You're right, I'm being lazy
<LaserJock> what you watch DVDs? your supposed to be working on Ubuntu ;-)
<Amaranth> LaserJock: shh
<LaserJock> Amaranth: don't worry I won't tell if you don't
<Seveas> Does anyone know intersting upstream projects that use trac for project management?
<_lemsx1_> i had to remove all the fglrx packages and force remove the libmesa1 one
<_lemsx1_> now everything is fine
<Amaranth> _lemsx1_: at least you could remove it, i just helped someone who couldn't remove, reinstall, or anything
<_lemsx1_> Amaranth: ouch... well, mv -f always works ;-)
<_lemsx1_> does anybody knows if there is any serious bug in mount?
<_lemsx1_> i lost my /dev/hdb1 driver (xfs formated) for no particular reason... that's a spare drive, so, it doesn't bother me much
<_lemsx1_> when i try to mount it i get a: mount: /dev/hdb1 already mounted or /mnt/shared busy
<_lemsx1_> i'll ask in #ubuntu just to see if somebody knows
<Fjodor> Anyone with glibc experience. Seems my patch wasn't ready afterall, as debian/rules build fails with an undefined reference
<Seveas> Fjodor, I've had my fun with glibc hacking - how big is the patch?
<Fjodor> Rather large. Basically, it's Suse's patches from AMD, but taken from a gentoo bug report about adding them to gentoo. I worked out the parts of the patch that didn't make it, made the patch, and now tried debian/rules build. It fails with ref. to __copysign, that I know is defined somewhere in fpu, but it seems that dir isn't touched yet when it fails
<Fjodor> I'll be glad to send it to you, if you like
<Fjodor> The gentoo page is http://bugs.gentoo.org/show_bug.cgi?id=100289
<Fjodor> I've put the patch in http://daimi.au.dk/~u983179/glibc-2.3.6-amd-patches.patch.bz2
<Fjodor> It is against the build_tree gotten from debian/rules unpack and debian/rules patch
<Fjodor> Seveas: Any ideas?
<Seveas> Fjodor, not yet 
<Seveas> I'll poke some more at it tomorrow, but don't have an amd64 to test
<Seveas> can you put your buildlog online?
<Fjodor> Please excuse my impatience. It does not reflect ingratitude :-)
<Fjodor> Sure, how?
<Fjodor> And if you need a machine, I can give you an account on mine, though it is going offline soon for the night. It's 0202am here
<Fjodor> As for how, I mean what file of course
<_ion> seveas: Finnish .jp fans on IRC always get provoked when someone uses that as a smiley. 
<Seveas> _ion, should I care?
<Seveas> Fjodor, same TZ here - i'm off in less than 10 minutes
<_ion> seveas: No.
<Seveas> _ion, ok 
<Fjodor> Fair enough then, but where is the build log saved?
<Seveas> dpkg-buildpackge -rfakeroot | tee buildlog
<Seveas> dpkg-buildpackge -rfakeroot 2>&1 | tee buildlog
<Fjodor> I'll move the patch and upload the log to http://daimi.au.dk/~u983179/glibc
<Seveas> noted - off to bed now
<Seveas> bye
<Fjodor> Bye, and thanks
<_ion> Good night.
<Fjodor> Hmmm, build-package removes the build-tree dir that I patched. How do I tell it to reapply my patch?
<Fjodor> ls
<_ion> Does the package use cdbs?
<Fjodor> cdbs?
<_ion> glibc doesn't seem to use it. (tarball.mk in cdbs uses a 'build-tree' directory, that's why i asked.)
<_ion> You should save the diff to debian/patches/number-patchname.patch
<_ion> Look at the other patches in that directory.
<Fjodor> Only four are with numbers
<_ion> The number in the beginning is just a convention. They are applied in an alphabetical order.
<Fjodor> I shouldn't add it to 00list.amd64?
<_ion> You should do what has been done with the other patches. I haven't looked at the glibc source package, and different packages might use different patch systems. Some use dpatch, etc.
<Fjodor> Ok. But thanks
<Jamal__> anyone see this? http://digg.com/linux_unix/Ubuntu_Center_Pre-Alpha_Released_-_Web_Based_Ubuntu_Control
<_ion> Eww, PHP.
<Jamal__> what do you like?
<Jamal__> perl?
<Jamal__> I gotta go eat
<Jamal__> later
<_ion> Perl definitely isn't as ugly as PHP, but i like Python and love Ruby.
<na7e> he left
<na7e> i like ruby myself, too bad it's not as good at being a glue language as python
<rob> can someone tell me who maintains xorg currently?
<Fjodor> If anyone other than Seveas wants to take alook at this amd64-optimized glibc, look in http://daimi.au.dk/~u983179/glibc
* mitzi_ grumbles at dapper..
<lamont2> "The system adiminstrator has disabled access to the system temporarily."
<lamont2> I wouldn't mind that so much if it would turn off eventually
<holy_cow> lamont, when does that show up?
<lamont> it shows up when you have ldap passwd/shadow/group, and completely break it
<holy_cow> aha!
<holy_cow> i have yet to try that
<lamont> breaking it?  I recommend against that...
<holy_cow> naw, testing is good, i got lotsa boxes and vmware instances
<lamont> holy_cow: this was my main desktop, you see....
<holy_cow> :/ that sux indeed
<lifeless> where has makeinfo gone ?
<lifeless> oh, nm. my bad, somehow got texinfo uninstalled
<desrt> The path 'file:///store_00010001/DCIM/100K7630' is not absolute.
<infinity> Looks absolute to me.
<desrt> when trying to download pics from the SD card i just bought for my camera
<desrt> using the internal memory is quite fine
<sivang> morning all
<lifeless> desrt: url unaware program
<desrt> lifeless; uhm?
<lifeless> to a url unaware program file:/// is not absolute
<desrt> lifeless; the program generated this url for itself
<ajmitch> desrt: the bug is in malone
<desrt> ajmitch; awesome.  got a # for me?
* desrt was just about to file it :)
<lifeless> desrt: score one for that program
<ajmitch> desrt: you didn't search for it? :)
<ajmitch> bug #34077
<Ubugtu> Malone bug 34077 in gthumb "Can't import photos: The path is not absolute"" [Normal,Needs info]  http://launchpad.net/bugs/34077
<ajmitch> I'm assuming that's what you're seeing?
<desrt> i found it :p
<desrt> ajmitch; i searched... but i'm quite ineffective when it comes to launchpad
<desrt> i searched for 'path is not absolute' and libgnomeprint and subversion came up :p
* ajmitch just searched his bug mail folder, far more efficient :)
<desrt> sad but true
<desrt> today was fun
<desrt> i hacked up an ubuntu livecd for a group project
<desrt> man
* desrt goes to bed for 2hours
<sivang> desrt: tired?
<desrt> yes.
<desrt> final presentation tomorrow :p
<sivang> sleep tight!
<desrt> nite.
<holy_cow> goddamit, i'm starting to hate reading peoples opinions about linux/windows/mac/newbuser needs/poweruser needs
<Burgundavia> holy_cow: hmm?
<holy_cow> its like listening to chicks gossping, none of it makes any sense and none of it is even remotely well thought out, never mind researched
<Burgundavia> it is important to respect peoples opinions, as they can tell you important things
<holy_cow> Burgundavia, i have been a firm believer in that, my faith is starting to slip :/
<Burgundavia> but sometimes people mixed up what they need with what they thyink they need
<Burgundavia> and how they think they are going to get what they did
<holy_cow> i think that fundamentally humans have processing units between their ears that are not designed for complex thought
<Seveas> _ion, *hug*
<Seveas> nm+wpa works
<giftnudel> where?
<Pygi> Seveas: great news ^^
<giftnudel> how?
<Pygi> Seveas: you could say that to me as well, you know ^^
<Seveas> just a quick remark: in your postinst you should do a source /etc/default/wpasupplicant and warn if ENABLED=1
<Pygi> giftnudel: wait a lill'...you'll hear all about it later ;)
<Seveas> because that will mess up nm
<Seveas> now to find the 802.1x patch and apply it
<Seveas> because itherwise nm is still useless to me ^_^
<Pygi> Seveas: if you find it, please send it to mario dot danic at gmail dot com
<Pygi> ok?
<Seveas> bien sr, mon ami
<siretart> Seveas: is there a wiki dokumenting that?
<Pygi> siretart: yup
<siretart> Seveas: I'd like to try it out next week, after my test
<siretart> where?
<Seveas> Pygi, can tell more 
<Seveas> ion_ made very nice packages
<Pygi> siteart: https://wiki.ubuntu.com/DapperNetworkManager
<siretart> thanks
<Seveas> you need a new wpasupplicant, new NM/NM-applet and possible a new l-r-m (if you use atheros)
<Pygi> siretart, Seveas: but we are still do do a lill' modifications, to the repos and the wiki
<Pygi> siretart: the wiki will be updated today, same with repos
<siretart> Pygi: I'll join your work on wednesday
<Pygi> siretart: k, great...
<Pygi> now only Seveas to find that 802.1x patch ;)
<Seveas> Pygi, http://rlove.org/log/2006/Feb
* Pygi is either blind, or I can't find patch there ;)
<Seveas> no, a screenshot 
<Seveas> friggen hell
<Seveas> it's already in ther
* Seveas blind
<Pygi> Seveas: ah, I was testing new n-m as well ;)
<Seveas> this is really, really cool
<Pygi> Seveas: now all we have to do is get it into dapper ;)
<Pygi> testing, a lot of testing first ofcourse
<Seveas> Pygi, I'll be testing WPA and EAP/TTLS 
<Pygi> Seveas: k, great ;) I am testing WPA as well ...
<Seveas> urgh
<Seveas> ok, this sucks: NM constantly scans
<Seveas> which is bad in case of madwifi which can't do background scans
<Pygi> hm 
<Seveas> and thus my connection is gone for a second (kills no connections but is still annoying as hell)
<Seveas> madwifi-ng can do background scans
<Pygi> perhaps we could write a workaround for that? :-/
<Seveas> dunno
<Pygi> yup, but we can't use the -ng
<Mithrandir> Seveas: you can ask NM to just scan when it doesn't have a connection.
<Seveas> Mithrandir, cool - where?
<Mithrandir> Seveas: unsure; my laptop is in my backpack and I'm too lazy to go fetch it. :-)
<Mithrandir> Seveas: I just know you can make it.  Browse with gconf-editor, possibly?
<Seveas> that option should definitely be on by default - more network cards break
<Seveas> hmm, sounds like a plan
<Seveas> hmm, no n-m in /apps
<Mithrandir> maybe we could make it scan when you open the menu?
<Mithrandir> (or when it loses the connection)
<Seveas> that would be ideal
<Seveas> (well, ideally drivers don't break during a scan)
<Pygi> Seveas: yup, but we can't really influence the drivers, unless it is possible to write a workaround
<siretart> Seveas: upstream still considers madwifi-old to be more stable than madiwifi-ng
<Seveas> siretart, no surprise, madwifi-ng is buggy as hell
<siretart> I see
<Seveas> madwifi bug 444
<Ubugtu> Madwifi bug 444 in madwifi: driver "Madwifi does not work with NetworkManager and WPA" [Enhancement,Assigned]  http://madwifi.org/ticket/444
<Seveas> (I added trac support to Ubugtu)
<siretart> nice
<Seveas> and have been swearing for an hour at debbugs 
<Mithrandir> why?
<Seveas> it is NOT possible to de reliable machine reading
<Mithrandir> use the LDAP interface.
<Seveas> can't search on ID
<Seveas> aba is planning to fix that $soon
<Seveas> but in the mean time it's not possible to do reliable machine reading
<Seveas> Pygi, hmm - riddle me this
<Seveas> nm-applet says wireless strength 38%, netstatus-applet says 79%
<tseng> i had to wait a few seconds for nm to catch up with reality
<Seveas> or more exactly, always twice as much as nm-applet says
<Seveas>           Link Quality=38/94  Signal level=-57 dBm  Noise level=-95 dBm
<Seveas> ok, netstatus-applet is weird
<Pygi> Seveas: definetly it is ;)
<Pygi> netstatus-applet being weird, that is ;)
<Seveas> ah well, good riddance
<Seveas> with the new icon it's too big anyway
<tseng> 0.6.1 from the wiki page works nicely for me, fwiw
<Treenaks> Have they fixed the status reporting to be consistent then? (dB vs percentage)
<Treenaks> (in-kernel)
<Pygi> tseng: yup, great ;) but we need to update the page and repos today ;)
<Pygi> once we call for a wider testing, please post all your experiences to the -devel list ^_^ || especially if it doesn't work, and what exactly doesn't work 
<Seveas> will do
<Pygi> Seveas: thx
<infinity> Seveas: If you can backport the background scanning from -ng to -old, I'll (very) happily include it, but I've not had the time to even look at it (and would have no way to test it)
<infinity> Seveas: We're also investigating some cleverly hackish ways to ship both -old and -ng (though -old would still be the default for everyone except a select few PCI IDs that just plain NEED -ng)
<Pygi> infinity: what's your wiki page, so I could link to it as you are a contributor at dappernm wiki
<infinity> Pygi: If I have one, it probably has very ltitle interesting info on it.
<Pygi> infinity: ah, kk
<siretart> Seveas: you're using madwifi?
<infinity> Pygi: https://wiki.ubuntu.com/AdamConrad <-- Very obviously out of date and useless.
<siretart> Seveas: then netstat-applet is right. on madwifi, the 38 is not to be read as percentage, but as RSSI. 
<Pygi> infinity: hm... perhaps we could include part of -ng code inside the old one, and make an internal switch that we could pass, so it would use -old or -ng, depending on the switch? :-/
* Pygi thinks that is higly unlikely to happen, and probably impossible
<infinity> Pygi: Not really doable, no.
<Pygi> infinity: yup, I thought so...
<Seveas> siretart, ah ok
<Seveas> so more is broken in madwifi 
<Lathiat> http://lwn.net/Articles/175976/
<Lathiat> interesting
<Lathiat> combination live/install cd from mandriva
<siretart> Seveas: well, it's not really broken, but a different semantic. To get the number 79%, divide the 56 (or something, this depends on your particular machine) by 38
<siretart> Seveas: IOW, thats intended by madwifi upstream and not considered as a bug
<Seveas> urgh
<infinity> (Alternately, one could say it's a buggy driver for presenting data to userspace COMPLETELY DIFFERENTLY than the other drivers, but hey, just blame userspace, that's easier)
<infinity> madwifi's "oh, standards aren't important, we'll just do whatever" stance can be annoying.
<Seveas> infinity, exactly, they say WEXT 18/19 compliance is just an enhancement...
<Pygi> Seveas: well, if it's really important, I guess it wouldn't be to hard to change that...
<Seveas> Pygi, it's a cosmetic issue, presumably netstat-applet has fixed^Wworked around it and nm-applet not
<Pygi> Seveas: hm, well..should we leave it that way or...?
<Seveas> If i can cook up a patch really quickly I'll send it, otherwise I wouldn't bother
<infinity> Pygi: Special-case it for madwifi (like to many other things in NM) so it's "correct".
<infinity> It's not difficult to do, just a pain to have to do it.
<Pygi> infinity: understandable...
<Pygi> Seveas: k, great...you know the mail ^_^
<Seveas> dennis@mirage:~/temp/gnome-netstatus-2.12.0$ grep -i madwifi -R .
<Seveas> dennis@mirage:~/temp/gnome-netstatus-2.12.0$
<Seveas> dennis@mirage:~/temp/gnome-netstatus-2.12.0$ grep -i madwifi -R .
<Seveas> dennis@mirage:~/temp/gnome-netstatus-2.12.0$
<Seveas> hmm...
<Treenaks> duh
<Treenaks> als het de 1e keer niet werkt werkt het de 2e keer ook niet ;)
<Treenaks> misschien staat er 'atheros' ?
<Seveas> Treenaks, EN
<Seveas> not NL 
<Treenaks> Oops
* Treenaks is on too many channels
<infinity> Seveas: ath_pci
<Seveas> ah: ./netstatus-sysdeps.c:      g_strncasecmp (iface, "ath",  3) &&
<Treenaks> so.. maybe you're looking for the wrong string :)
<Seveas> hmm, I see no special casing for atheros/madwifi...
* sivang glances at turbogears.
<giftnudel> now that nm supports wpa, is there a chance that it will get vpn support?
<Treenaks> giftnudel: once it stabilises upstream, sure
<Treenaks> giftnudel: but not for dapper
<giftnudel> is there an easy way to add that, or do you have to recompile everything
<Pygi> giftnudel: it is not even sure that nm will get into dapper
<infinity> s/nm/nm 0.6/
<infinity> nm is already in dapper.
<Pygi> yes, nm 0.6
<Pygi> sorry infinity, by n-m I reffer to 0.6
<infinity> Anyhow, the VPN issue has less to do with upstream stability and more to do with a complete lack of reasonable integration of the debian/ubuntu NM backend with the VPN stuff, I'd assume.
<infinity> Oh, and the fact that much of its cleverness relies on having a loacl nameserver that supports views, like bind9.
<infinity> (Well, exactly like bind9 right now, since the backend doesn't know how to drive others)
<infinity> Hacking on NSS violently to get it to support local views natively, so you don't need a fullblown nameserver to do so would be a Very Good (and fun) project for someone.
<Treenaks> 'hacking on NSS' scares people. 'violently' even more...
<infinity> Well, yes, that had occurred to me.
<infinity> NSS modules don't look that hard to write, though.
<infinity> You shouldn't need to abuse the libc resolver directly to get the behaviour you want, I don't think..
<Pygi> infinity: perhaps, but there is no way to do that for dapper ;)
<tseng> guys, is autostart .desktop supported in gnome 2.12?
<tseng> or new for 2.14
<infinity> No, for dapper, if you want the VPN stuff you'd have to recompile the package and install bind9
<Pygi> infinity: but perhaps, if situation fixes itself for dapper+1, we could do it for then
<Pygi> perhaps -ng and new wpasupplicant will be way stable then ^_^
* Pygi hopes so, but that is unlikely to be true :-/
<infinity> madwifi-ng is stabilising a bit, but it'll be a long, hard road.
<Pygi> yup, understandable...and probably not ready for dapper+1
<infinity> When I publihed packages for testing, I only got about a 50% success rate from testers, which wasn't promising.
<infinity> That was 2 months ago now.
<Pygi> we've got 90% success rate for this packages we've built. but not many people tried it...and that one that failed, done so by his own mistake
<infinity> I can publish a new SVN snapshot and call for wider testing again, but I fear it wouldn't go terribly well.
<Pygi> that's a good rate, I would say ;)
<infinity> Besides, it's way too late in the release cycle to consider a switch anyway, I tihnk.
<Pygi> infinity: hm, perhaps after dapper is published?
<Pygi> infinity: yup, most probably
<infinity> After dapper is published, I'll switch to -ng unconditionally anyway, and we'll see how many bug we can shake out during the dapper+1 cycle.
<infinity> If I HAVE to switch back, I will, but I don't plan on it.
<Pygi> infinity: if we are to consider switching to -ng, with our patches included, count me in to help writing patches
* Pygi is gonna try to maintain WLAN stuff in Ubuntu now, since he already started with it ;)
<infinity> Well, on June 2nd, I'll switch to madwifi-ng. :)
<infinity> So, if you want to contribute fixes at that point, feel free.
<infinity> I don't currently own any atheros hardware, so I'm flying blind most of the time, and counting on user feedback.
<Pygi> I had to get one few days back, just to test the packages we've built
<Pygi> _ion: have you finally woke up? ^_^
<Pygi> infinity: will the dapper+1 daily images be built since June 2nd, or are we going to wait *some time*?
* Pygi forgot how we did it before :-/
<Pygi> btw. we have 4 months or so for dapper+1 most probably?
<Robot101> is dapper's Xorg patched somehow to make DRI work, that would make it stop working under Xorg-air?
<infinity> Pygi: Not sure when we'll open the archive for dapper+1... Could be a 1-week "cooling off" period before we open the floodgates for syncs, merges, and new uploads.
<Fjodor> Seveas: Are you awake?
<Seveas> Fjodor, yeah
<Fjodor> Did you want an account on my machine for hacking the glibc thing?
<Seveas> may be useful
<giftnudel> oh, and btw, nm 0.6 from the wiki works flawlessly  for me
<Fjodor> 2 secs
<Seveas> Fjodor, I think you need some makefile tweaking
<Fjodor> Ok
<Seveas> that symbol that is missing used to be defined in an S file and now is defined in a c file - no makefiles have been changed and I don't know if the glibc makefile trickery picks it up automatically
<Fjodor> Ah. Seems reasonable
<Seveas> it may very well do that automagically (glibc Makefile is really tricky)
<Pygi> giftnudel: great, but the info is currently obsolete ;)
<towolf_> salve, i've been running nm from cvs since ages but i'd like to help populating the v0.6 testing database with the pkgs Pygi announced on the forums
* towolf_ owns a plain old centrino book
<Pygi> towolf_: great, but please wait until me and _ion announce new packages, and update wiki
<towolf_> fine
<Pygi> we'll call for wider testing today, that
<Pygi> towolf_: thanks ^^
<zyga_> darn
<zyga_> I've just realised that I cannot fix a bug without ngettext that takes two numeric arguments and is expanded to a [N] [N]  array of strings (where N is num-plurals)
<mcquaid> hello, my gf4 burnt out and i've had to go back to my old voodoo3 
<mcquaid> i can't get dri working with this card
<mcquaid> i've since upgraded to dapper hoping it might resolve some issues
<mcquaid> i'm still in the same boat and i notcied a new file available: libgl1-mesa-glide3
<mcquaid> I'm trying to determine what that file is for exactly
<mcquaid> is that for using dri via the tdfx driver or is it using the older (outdated?) glide driver which is not recommended
<mcquaid> i was going to install it to try it but it flags a lot of seemingly unrelated  stuff for removal
<mcquaid> stuff like kdebase-dev libkonq4-dev libsdl-dev etc
<mcquaid> according to the xorg logs, dri is enabled 
<mcquaid> but glxinfo states it's not
<mcquaid> so from what i've read this is a userspace setup issue
<mcquaid> i've googled and search the forums to no end but i just found other voodoo users with the same/similar problem
<siretart> see topic
<mcquaid> i realize this is normally not for end user support
<Pygi> _ion: do not refuse to wake up... abrakadabra, wake up
<mcquaid> but no other end users i've encountered have a clue about voodoo cards
<siretart> mcquaid: file a support ticket in launchpad. this channel is not for support at all
<mcquaid> ok
<Pygi> mcquaid: you also have forums
<bSON> hi
<bSON> does the ubuntu x.org server have the aiglx extensions?
<neuralis> bSON: no.
<bSON> ok
<Amaranth> xserver-xorg-air-core is in universe
<bSON> Amaranth: but you can't make use of it without a composite-enabled metacity and stuff, can you?
<Amaranth> bSON: spiftacity is in universe too
<HiddenPuppy> spiftacity?
<HiddenPuppy> the name alone. :S
<mjg59> metacity with the compositor enabled
<Amaranth> metacity with the compositor enabled
<Amaranth> heh
<bSON> cool
<HiddenPuppy> mjg59: you where eager for some ehm, bling in dapper? ;)
<HiddenPuppy> were
<bSON> Amaranth: and xair will tell me that all renedering is disabled?
<Amaranth> too bad neither one of them appears to work with ppc
<Amaranth> bSON: sudo ln -sf /usr/bin/Xorg-air /usr/bin/X
<Amaranth> bSON: then restart X
<HiddenPuppy> Amaranth: nor most of the drivers, so the pain is everywhere
<Amaranth> HiddenPuppy: I have a 9200, the one that's supposed to have the best support
<Amaranth> radeon 9200, that is
<HiddenPuppy> I should've never tossed that one out. =)
<bSON> Amaranth: i guess i'll have to replace my gnome session's metacity with spiftacity
<Amaranth> bSON: no
<Amaranth> bSON: spiftacity --replace
<bSON> ok, good
<Amaranth> then you need to set a gconf key, but i don't remember what it is
<bSON> that's what i meant...
<HiddenPuppy> Is anyone here familiar with the innards of the networking system?
<Amaranth> oh, i thought you meant permanently
<bSON> Amaranth: i already tried xgl and compiz, now i want to give aiglx a chance :)
<Amaranth> bSON: it's not as shiny but at least it doesn't run two xservers
<Amaranth> and someone on the forums has some packages for compiz and aiglx with the changes needed to make them work together
<bSON> Amaranth: well, wobbly windows will come back soon, then i don't care which of the two i use ;)
<Amaranth> so then you get the shiny and the lower memory usage
<bSON> yeah
<bSON> lets do the X restart...
<Amaranth> wtf
<HiddenWolf> *chuckle*
<Amaranth> X fails to access /dev/dri/card0 twice, then it suddenly works
<HiddenWolf> Right, i'm going nuts here
<HiddenWolf> I took my router out of the connection, fired up pppoeconf, get a perfectly working ppp0, but ubuntu insists on timing out on eth0
<bSON> hi
<Amaranth> (WW) RADEON(0): Video BIOS not detected, using default clock settings! <--annoying
<bSON> Amaranth: Xorg-air can't find the drm module for fglrx...
* Amaranth stops
<Amaranth> bSON: err
<Amaranth> aiglx only works with open-source drivers
<bSON> oh...
<HiddenWolf> open source radeon driver only, right?
<Amaranth> until nvidia and ati add GLX_EXT_texture_from_pixmap to their drivers
<bSON> it's shown in glxinfo on my Xgl
<Amaranth> that's because Xgl provides it
<Amaranth> which works with that because it's a seperate server
<bSON> my radeon 9600 xt has no 3d acceletation with the radeon driver...
<Amaranth> or some crap
<bSON> Amaranth: oh
<Amaranth> bSON: when did you try last?
<Amaranth> there is support for r300 cards in the open-source driver
<Amaranth> it's just not done
<bSON> after installing dapper flight 4
<bSON> Amaranth: at least option "RenderAccel" didn't work
<Amaranth> but did you see if 3d worked?
<Amaranth> doesn't matter though, i know the r300 driver doesn't work with aiglx
<mcquaid> bSON, do you have the dri driver working for ati?
<bSON> dunno, i'll have to try
<mcquaid> do this: export LIBGL_DEBUG=verbose
<mcquaid> then run glxinfo
<bSON> should i maybe try to use "accelmethod" exa?
<bSON> mcquaid: with the "ati" driver? or "radeon"?
<mcquaid> i believe that's with the ati driver only
<HiddenWolf> I wonder what the future of aiglx and xgl is. Something like "use aiglx if possible, fallback to xgl, then xorg"
<bSON> probably
<bSON> til xgl learns to run on its own
<bSON> how can i choose the used dri driver?
<bSON> is that done automatically?
<bSON> bobbens: no success
<bSON> oh, wrong channel...
<_ion> pygi: The spell you cast worked with a slight delay.
<Pygi> _ion: ion, great ;)
<Pygi> we have so much to do now you know, 
<Pygi> first of all, read your mails
<Pygi> second of all, please add l-r-m packages to the repository, and edit the wiki to be valid (to instruct on installing l-r-m) packages
<_ion> pygi: I read the mails and added the warning to postinst. I'm building the packages right now.
<Pygi> _ion: k, and add lrm, and edit wiki pls
<Pygi> I have more news for you as well  ^_^
<_ion> Will do.
<_ion> pygi: Hmm. It would be better if people used the networkmanager-lrm repo at people.ubuntu.com because the package is huge and my repository is behind my home ADSL. :-)
<_ion> pygi: We might as well tell madwifi users to use that repository. Right?
<Pygi> _ion: tonio_ said that we could use his 80Mbit repo if we want...
<_ion> http://people.ubuntu.com/~adconrad/networkmanager-lrm/ is already there, and it's quite fast.
<Pygi> _ion: let's rather keep all on one place...want me to ask tonio_ to host it for us?
<_ion> pygi: Ok.
<Pygi> _ion: k,just tell me when you uploaded the new n-m
<_ion> The updated package (with the check) is available from my repository now.
<Pygi> oh, ok, great
<Pygi> now the wiki ^_^
<_ion> *** Please set ENABLED=0 in /etc/default/wpasupplicant
<_ion> *** if you want network-manager to manage wpasupplicant.
<_ion> It worked. :-)
<Pygi> _ion: o joy ^_ ^
<HiddenWolf> Right, webcam support sucks.
<_ion> pygi: There seems to be something wrong with the l-r-m patch: "With the patch, WPA works, but it's rather buggy. The connection doesn't last very long, and NM doesn't seem to be able to remember my WPA key. Plus, the system will randomly lock up when reconnecting (EDIT: This seems to happen if I choose to show my WPA key with nm-applet)" (from the forum)
<Pygi> _ion: I saw that...
<zyga> pitti: hi
<Pygi> _ion: it was the first report of it's kind, and there is no some actuall info on what happened, and how...
<_ion> pygi: True.
<Pygi> _ion: so we'll have to wait until more people report/confirm somethin' like that
<_ion> Yep.
<zyga> pitti: do you have a moment?
<Pygi> _ion: perhaps it's only a isolated incident cause by *somethin'*
<Pygi> _ion: I'm just waiting until Tonio_ returns, so we can host all
<_ion> infinity: Does this <https://lists.ubuntu.com/archives/dapper-changes/2006-March/007934.html> affect the patched l-r-m package?
<Lure> _ion: that what concerns me too - there is new ipw2200 and I would not like to clash with NM-patches l-r-m
<Lure> _ion: are l-r-m patches only for madwifi or also for ipw2200?
<_ion> lure: The patch is only needed for madwifi.
<Lure> _ion: ok, then concern is only if this new kernel release will not override NM-patched l-r-m
<mjg59> The ABI name has changed. So it will.
<Lure> and breaking madwifi NP support
<Pygi> mjg59: huh, so it will break l-r-m packages we've built? :-
<Pygi> :-/
<Pygi> that is no good
<Lure> mjg59: so we need to wait for release of kernel and rebuild then?
<mjg59> Lure: Yes
<sivang> doko__: ping
<_ion> http://bash.org/?626249
<Lure> _ion: is airo wireless supposed to work with NM (Riddell is testing it)
<Lure> is http://mail.gnome.org/archives/networkmanager-list/2006-January/msg00204.html patch included?
<_ion> Probably not, unless the kernel source maintainers have included it.
<Lure> _ion: you patch to l-r-m (done by infinity) was then only for madwifi?
<_ion> Yes.
<Lure> ok
<_ion> If that patch is needed, it should be probably filed as a bug report to the kernel package.
<Lure> _ion: does it make sense to open bug report for NM-related fixes as we do not know yet if NM will be accepted?
<_ion> That doesn't look like a network-manager related fix.
<_ion> "This patch adds IWENCODEEXT and IWAUTH support to the airo driver for WEP and unencrypted operation.  No WPA though."
<robertj> Lure: it's definately going into Universe right?
<Pygi> Lure: nop
<_ion> I've had the impression that it's definitely not going to main, and the one in universe *might* be upgraded to the 0.6 series if the package is good enough.
<Lure> Pygi: what "nope"?
<Pygi> It cannot go in main, that is not even an option
<Pygi> Lure: sorry, wrong guy ^_^
* Pygi agrees with _ion
* Lure would be very happy if we get it to universe
<Burgundavia> if you are talking about n-m, it pretty much to replace what is already there
<_ion> Hm, /me just realized network-manager 0.5.1 _is_ in main.
<Burgundavia> so we are talking into main
<Burgundavia> n-m is already on the livecd
<Pygi> Burgundavia: ah, yes, really ... haven't saw that ...
<Pygi> _ion: so that's why packages have to be *so* good ^_^
<_ion> pygi: Heh, yep.
<Pygi> everything is working (packages I mean), only repos to fix
<Pygi> but we are workin' on that
<Pygi> _ion: please write info on DapperNetworkManager and DapperKNetworkManager on how to import key
<Pygi> thanks
<_ion> Ok.
#ubuntu-devel 2006-03-25
<Pygi> _ion: you should remove that "isn't signed, bla, bla" as well ;)
<Pygi> but I'll do it
<Pygi> thanks _ion
<Pygi> we've done some changes to the repo, so I am testing now
<sivang> oi, OOP code component re-use in python is SO sweet!
<Pygi> sivang: hehe ;)
<sivang> Pygi: is rather amazing,
<Pygi> sivang: I am aware of that ^_^
<sivang> Pygi: working on home user backup, I am not working on uprestore (the resoration module) as it shares most of the GUI characteristics with upbackup, I just based it's class on the backup one, and 80% if the work is already done :)
<sivang> s/not//
<sivang> Pygi: so I get all the media device detection code and population, user details detection for free, integrated into the gui.
<sivang> I used dyaminc (getattr) method and attribute allocation and designed the module sin advance like this, like the jewish saying goes "He who bothered on friday night will see joy on sat" :-D
<Pygi> sivang: joy :-)
<sivang> completely. :-) /me goes back to hacking
<Pygi> ;)
<Pygi> I am hacking as well
<Pygi> the repository ;)
<sivang> Pygi: hehe, uploading new l-r-m ?
<sivang> Pygi: with _ion's changes in?
<Pygi> sivang: bah, we already have that in ... we just finished polishing all the packages
<sivang> (I saw the bits of wifi discussions with mjg59 and _ion )
<Pygi> packages were bloated, and not really usefull ;)
<sivang> Pygi: which chipset / devices are now supported?
<sivang> Pygi: (you touched only the wifi stuff?)
<Pygi> sivang: please see the ubuntu-devel ^_^
<sivang> eh, okay..sorry
<Pygi> np at all ^_^
<sivang> Pygi: are you already approved for main ? I don't recall I saw you on the CC/TB for that one.
<Seveas> _ion, ping
<_ion> seveas: Pong.
<Seveas> _ion, Errhttp://kubuntu.no-ip.org dapper/main nm-applet 0.6.1-0ubuntu1
<Seveas>   404 Not Found
<Pygi> sivang: nop, we never actually got to that part ^_^ we have time
<Pygi> Seveas: yup, I know
<_ion> seveas: Yeah, Pygi is working on the new repository.
<Pygi> Seveas: please read the -devel mailing list, and follow thingies
<Seveas> k
<Pygi> sivang: when is next CC/TB?
<sivang> Pygi: Me neither, but I'm getting there I think, first get approved for universe.
<sivang> Pygi: 28 Mar 20:00
<sivang>           UTC: Technical Board
<Seveas> Pygi, when will the repo be ready?
<Pygi> Seveas: repos are ready now .... they are signed now, so you need to import the key
<Pygi> sivang: thanks ... do I need to write somewhere that I am going to attend it, etc? ;)
<Seveas> Pygi, I still get 404
<Pygi> Seveas: followed the wiki?
<Seveas> yeah 
<_ion> W: GPG error: http://kubuntu.no-ip.org dapper Release: The following signatures were invalid: BADSIG C80644C88A303107 Anthony Mercatante <tonio@ubuntu.com>
<Seveas> W: GPG error: http://kubuntu.no-ip.org dapper Release: The following signatures were invalid: BADSIG C80644C88A303107 Anthony Mercatante <tonio@ubuntu.com>
<Seveas> rofl
<Seveas> Pygi, fix the Release.gpg
<sivang> Pygi: no, just to show up. 
<Pygi> sivang: kk, and there I ask for it?
<sivang> Pygi: make sure you apply for MOTU through launchpad, or main 
<Pygi> sivang: ah, ok
<_ion> pygi: Make whatever updates the repository update the signature as well. :-)
<Tonio_> hi
<_ion> Hi
<Tonio_> is there a problem with the repo ?
<Tonio_> Seveas: ?
<Seveas> Tonio_, Pygi broke it - lart him
<_ion> Apparently Release.gpg isn't updated.
<Pygi> yup, I have it again
<Pygi> W: GPG error: http://kubuntu.no-ip.org dapper Release: The following signatures were invalid: BADSIG C80644C88A303107 Anthony Mercatante <tonio@ubuntu.com>
<Pygi> W: You may want to run apt-get update to correct these problems
<Pygi> Tonio_: you need to stop that automatic scanning I would say
<Tonio_> grmpf......
<Seveas> Pygi, have you looked at falcon to build a repo? Makes it dead easy ;)
<Pygi> or make it auto update
<Tonio_> Pygi: yes, unfortunately
<_ion> I haven't tried falcon, but reprepro makes it dead easy as well. :-)
<Pygi> Tonio_: just make the key auto updates itself
<Tonio_> we have to generate Release.gpg each time..........
<Tonio_> damn........
<Seveas> well, apparently it's not as easy :D
<Pygi> Seveas: I have, but I didn't found the source
<Tonio_> Pygi: really, is that gpg key needed ?
<Tonio_> it creates so many problems
<Pygi> Tonio_: yes, it is needed  ^_ ^
<_ion> tonio: Yes. :-)
<Tonio_> what for ?
<Pygi> just make it generate the key
<sivang> does anybody know how I can have another user on the system allowed to use X, using xhost ?
<Pygi> Tonio_: for authentification
<Seveas> xhost +
* sivang needs that for testing HUB
<Tonio_> Pygi: impossible, I have to type my password each time :)
<sivang> Seveas: + and nothing afterwards?
<Tonio_> can't be automatic
<_ion> tonio: Nope, use gpg-agent.
<Seveas> sivang, after you finished: xhost -
<sivang> Seveas: thank you
<Pygi> Tonio_: then just make that the script doesnt work... we'll run it manually when needed
<_ion> tonio: keychain makes it easy.
<Seveas> xhost + sets it WIDE open
<Tonio_> _ion: will check
<Pygi> Seveas: where can I find more info on that falcon of urs? ^_^
<Seveas> Pygi, kaarsemaker.net/software or dimply my wikipage
<_ion> Insert the proper keychain lines to ~/.xinitrc and ~/.yourshellrc, and it starts ssh-agent and gpg-agent automatically and configures your environment.
<Tonio_> should be working now
<_ion> tonio: Yeah, thanks.
<Seveas> Do you want to continue [Y/n] ? y
<Seveas> Errhttp://kubuntu.no-ip.org dapper/main libnm-util-0 0.6.1-0ubuntu1
<Seveas>   404 Not Found
<Seveas> still not working...
<Pygi> Seveas: we're on it
<_ion> Oh.
<Seveas> Pygi, Tonio_ said it works, well it doesn't ;)
<Tonio_> hu ????
<Tonio_> Seveas: works here
<Pygi> Tonio_: tried fetching something?
<Pygi> works here as well
<Seveas> Tonio_, try apt-get install network-manager
<Pygi> Seveas: ???
<Tonio_> Seveas: it is okay
<Pygi> Tonio_: I can't fetch files :-/
<Seveas> Tonio_, it's not working - all files give 404 errors
<Tonio_> grmpf
<Seveas> Failed to fetch http://kubuntu.no-ip.org/kubuntu/dists/dapper/main/main/binary-i386/libnm-util-0_0.6.1-0ubuntu1_i386.deb  404 Not Found
<Seveas> Failed to fetch http://kubuntu.no-ip.org/kubuntu/dists/dapper/main/main/binary-i386/network-manager_0.6.1-0ubuntu1_i386.deb  404 Not Found
<Seveas> Failed to fetch http://kubuntu.no-ip.org/kubuntu/dists/dapper/main/main/binary-i386/nm-applet_0.6.1-0ubuntu1_i386.deb  404 Not Found
<Tonio_> this authentication drives me nuts
<Tonio_> it was working before
<_ion> "main/main"
<Seveas> seriously, switch to falcon for your repoing needs ;)
<Seveas> </spam>
<_ion> Yeah, i'd suggest the same. :-)
<Tonio_> Seveas: it is not going to be widely used
<Tonio_> ;)
<Pygi> Seveas: we will...let's just make it workin' for now
<Pygi> Tonio_: perhaps something in configuration?
<Tonio_> should be working now
<Tonio_> at least works for me
<Tonio_> yes config was somehow wrong
<Seveas> yep, works
<Pygi> great
<Pygi> Tonio_: later today (at least for me) we'll look into using falcon
<Pygi> and why doesn't the kubuntu-devel list allows links in a post?
<Tonio_> Pygi: this isn't a dedicated webserver for this
<Pygi> joy
<Seveas> cool
<Seveas> my connection survived an NM restart :D
<Tonio_> i'm hosting many different thigs on it, so I don't wan to install too many stuff :)
<Seveas> Tonio_, falcon is a small script, with very little dependencies
<Tonio_> just need to automate that release.gpg generation
<Pygi> Tonio_: ah,k, we can just leave it as is
<Tonio_> Seveas: okay, I'll have a look then
<Seveas> Tonio_, and it does gpg-signing for you ;)
<_ion> You don't need to install falcon to the web server, you can use it your local machine and make it upload stuff to the public repo.
<Pygi> Tonio_: perhaps we can work later today on that?
<Tonio_> Seveas: I need to test what _ion said
<Seveas> _ion is right, you don't even need it on your server
<Pygi> lol, already mad users are yelling at me
* Tonio_ still wonders the needing of authentication or a testing repo, but well :)
<Pygi> 'cause the repo doesn't work
<Tonio_> it isn't oficial for the moment :)
<_ion> That's how i managed my repo. I had reprepro installed to my desktop machine.
<Tonio_> Pygi: should be okay now no ?
<Pygi> Tonio_: yup, works now...but I got 5 mails from users to which it didn't work
<Tonio_> Pygi: :(
<Pygi> that was before we modified the repo tho
<Pygi> already compliments ^_^
<Pygi> Tonio_, _ion, me: let's apply for MOTU's now
<Seveas> Pygi, you'll need to be a member first
<Tonio_> yep :)
<Pygi> Seveas: oh, and what do I do to become that?
<Tonio_> Pygi: I already am a MOTU :)
<Pygi> Tonio_: great, but me isn't even a member ;)
<Seveas> Pygi, sustained and significant contribution to ubuntu for at least 2 months
<Tonio_> you have to apply :)
<Pygi> Seveas: bah, I have contributed to ubuntu for a lot time
<Seveas> wiki.ubuntu.com/NewMemberHowto
<Pygi> Seveas: at least you know I did ^_^
<Seveas> Pygi, actually I don't 
<Pygi> I am also along with ivoks, founder of ubuntu-hr
<Pygi> ;)
<Seveas> just follow the NewMemberHowto then
<Pygi> Seveas: bah, ok, then don't know :P
* Tonio_ looks into falcon
<Tonio_> Seveas: thanks for the info, didn't knew this
<Pygi> Seveas: hm, ok, thx, and when is this CC meeting?
<Seveas> Tonio_, it's not very well known and still pre-1.0
<Tonio_> Seveas: that's why :)
<Seveas> Pygi, not yet decided, somewhere the coming week
<Pygi> hm, ok, thank you very much ^_^
<Tonio_> I must say I didn't understood _ion's technique to perform the autosigning :)
<Seveas> Tonio_, I'm hoping to release 0.9.9 this week and 1.0 soon
<ajmitch> Pygi: and how much packaging work have you done to go for MOTU?
<Tonio_> Seveas: your developpment ?
<Seveas> yep
<Tonio_> cool :)
<Pygi> ajmitch: not much ^_^
<Seveas> that's why I know it so well ;)
<Pygi> ajmitch: just this thingies we worked on right now ^_^
<Tonio_> Seveas: which language ?
<Seveas> python
<Tonio_> k
<ajmitch> Pygi: ah, then you've got a bit to do
<_ion> pygi: I don't think i will apply for a MOTU right now  i don't really have a lot of energy to do stuff, as i've been ill for a long time. I only packaged n-m 0.6 to scratch my own itch.
<Pygi> ajmitch: It doesn't matter actually... I don't even have to be a member ... I can contribute just like this as well ;)
<Seveas> Pygi, that's the correct spirit - just contribute 
<Pygi> ajmitch: if I contributed this, I believe I can contribute even more, without being a member, so ... ^_^
<Pygi> Seveas: ^_^
<Pygi> ajmitch: the only reason I wanted to apply for MOTU, was to be able to request inclusion of n-m into main
<Pygi> if it gets properly tested, and works
<ajmitch> good luck with that
<Pygi> bah, I'll just bother Tonio_ to do that for me ;)
<_ion> Heh, the fact that n-m 0.5 was moved to main might be a bad thing, because it would probably have been easier to get 0.6 to Dapper universe.
<Pygi> _ion: yup, true ...
<Pygi> much easier
<Tonio_> _ion: true, but the good thing is that we now a bit more time for this
<Seveas> tomorrow I'll do the first EAP/TTLS test 
<Pygi> Seveas: thx seveas... please direct issues, etc. to the -devel list at appropriate thread
<Seveas> no way, I'll just flame you ;)
<Pygi> Seveas: ok, that's fine as well ;)
<infinity> Seveas: Is/was it you who ran the *-changes RSS feeds?
<Seveas> infinity, is
<Seveas> is it broken again?
<infinity> Seveas: None of them have updated for me for a couple of days.
<Seveas> last on dapper-changes is 23:25 UTC
<infinity> mkvtoolnix_1.6.5-4build1 is the last thing I see on dapper-changes.
<infinity> Which is clearly not true.
<Seveas> I see efibootmgr
* infinity tries deleting the feed.
<Seveas> aren't you looking upside down?
<infinity> No, I was looking the right direction, liferea just seemed to be "stuck", I guess.
<infinity> Deleting and recreating it fixed it.
<infinity> Weird.
<Seveas> weird indeed
<Seveas> did you restart liferea in the past days?
<Seveas> I've seen liferea being stuck, restarting the thing fixed that
<_ion> Straw > liferea. ;-)
<Pygi> is there anyone here that would be willing to build 64bit packages for us?
<Seveas> sure, if you give me a 64bit machine ;)
<Pygi> Seveas: agreed ... wanna come and get it ?  ^_^
<Seveas> hehe
<Pygi> we're currently building ppc packages
<Pygi> and we have 32 bit packages
<Pygi> only 64 bit remains ^_^
<Pygi> we will take over the world ^_^
<Seveas> LOL
<ajmitch> Pygi: do you have source packages available?
<raphink> Pygi: are you building ppc packages?
<_ion> Not until we have m68k packages!
<Pygi> ajmitch: yes ;-)
<_ion> ajmitch: Yes.
* ajmitch doesn't see them yet
<Pygi> raphink: nop, not me, but they are being builded, and should be there ^_^
<raphink> Pygi: what are you building them with?
<ajmitch> attack of the smilies in here today..
<raphink> Pygi: well I am the one who is to build them
<Tonio_> Seveas: Iwas reading and I can find docs to autoconnect using ssh and nopassword
<raphink> and I'm not currently doing it
<_ion> Get:2 http://kubuntu.no-ip.org dapper/main network-manager 0.6.1-0ubuntu1 (tar) [1026kB] 
<Pygi> raphink: aha, ok then ^_^
<Tonio_> Seveas: but nothing relative to scripting and automating pg signing
<raphink> so unless you are volunteering to do the work, I don't know how you can say "we" are doing it ;)
<Tonio_> Seveas: would you have a wikipage or doc for this ?
<Pygi> raphink: O joy ^_^
<Seveas> Tonio_, I use a passwordless key for the repo - it's safer to use gpg-agent though
<_ion> It's easy enough with gpg-agent, and _much_ more secure.
<Tonio_> Seveas: okay, but that means I will have to change the key, and now many people are using the repo, thant's not possible
<Seveas> yeah
<Seveas> Tonio_, no, you can remove the password from a key 
<Pygi> Tonio_: it's fine for now
<doko> infinity: OOo starts on ia64, but not, if you install openoffice.org-gnome
<Tonio_> Pygi: except if I have to updateit manually every day.......
<Pygi> Tonio_: yes, I am aware of that ...
<Pygi> Tonio_: we'll change that later today ...
<Tonio_> Seveas: it is my main private key that I use to sign :)
<Tonio_> Seveas: I don't use several keys generally :)
<infinity> doko: Interesting.
<infinity> doko: Missing some libs for -gnome, or just generally broken?
<Seveas> hehe
<Tonio_> Seveas: so removing the password is just........ weired :)
<Seveas> quite
<Tonio_> well, I'll do manually (grmpf.......)
<doko> infinity: no, missing libs would mean that it cannot start on amd64 either
<raphink> ok we're about to build the packages for ppc :p
<raphink> hehe
<doko> infinity: I had to test over ssh X forwarding in a chroot, so maybe lamont or iwj can check this out locally
<infinity> doko: Well, a fair point, but ia32-libs is different between the two arches, so I didn't know if that was perhaps true for ia32-libs-gtk and other stuff as well.
<infinity> doko: Yeah, I don't have a local ia64 either, I was just trying to get it installable, so others could test if it was useable.
<ajmitch> ugh, Build-Depends: @cdbs@
<_ion> ajmitch: Ugh?
<ajmitch> _ion: at least it's not updated on every build
<ajmitch> hi stratus 
<_ion> ajmitch: Of course not.
<_ion> ajmitch: Whenever it's updated manually, the resulting debian/control is inspected.
<stratus> ajmitch, hey fine?
<ajmitch> _ion: so you basically replaced all the packaging for nm?
<_ion> ajmitch: Pretty much, and then ported the patches from the old version.
<Seveas> why did you change the build system?
<_ion> cdbs makes writing and maintaining debian/rules a lot easier.
<Seveas> writing one by hand is just as simple 
<_ion> http://johan.kiviniemi.name/tmp/nm-5-rules  http://johan.kiviniemi.name/tmp/nm-6-rules
<Seveas> I find the first one easier to understand
<Seveas> and definitely easier to write
<_ion> I think it's quite redundant for every single debian source package have the same generic functionality copied to their debian/rules.
<mjg59> _ion: Yes, that 2K of gzippable content is a nightmare for the archive
<_ion> Yeah, and for my Commodore 64.
<mjg59> _ion: More seriously - changing the build system makes it less likely that your packages will be merged in
<Robot101> or in general, changing anything thats not relevant to your real issue is always bad
<Robot101> like editing whitespace in a file when you're submitting a bugfix
<LaserJock> mjg59: First upload to be built on an Apple running Ubuntu <-- sounds promising :-)
<Amaranth> mjg59: hey, i build things on an Apple running Ubuntu all the time
<Amaranth> :P
<LaserJock> lol
<LaserJock> I haven't :(
<paulproteus|lapt> What package do I use to report a bug against the Ubuntu website?
<Amaranth> hmm
<Amaranth> i don't think there is one
<mjg59> Amaranth: That's an i386/ia64-only package...
<Amaranth> hehe, i know
<LaserJock> paulproteus|lapt: I'd probably email webmaster@ubuntulinux.org
<LaserJock> mjg59: you've got a mini, right?
<mjg59> LaserJock: And an imac, but yeah
<LaserJock> mjg59: oh, ok. I was just wondering about the video on the iMac
<mjg59> Supported (unaccelerated)
<LaserJock> sweet
<LaserJock> I remember when they first came out that somebody said that the video wouldn't be supported
<LaserJock> and even though I'm CLI most of the time. I'd like to at least burn my eyes out with orange every once in a while ;-)
* Lathiat grins
<jdong> is the livecd installer (Dapper) supposed to do custom partitioning?
<jdong> just an FYI, it locks on me when I try to
<Amaranth> it's still not done
<Amaranth> right now afaik it only does "wipe the drive"
<jdong> oh, nvm, it did work
<jdong> just the embedded gparted's "Are you sure" dialog got backgrounded
<jdong> metacity bug, or just forgot to set modal?
<jdong> and speaking of that, recently metacity has been loving to background things for no reason :)
<jdong> yeah, Amaranth, definitely espresso is still immature
<jdong> I'm sure glad it gets some extra time 
<infinity> _ion: The new linux-source will require a new LRM for the bumped ABI, yes, but that's a moot point since linux-source doesn't build right now anyway. :)
<_ion> infinity: Yep. Hehe.
<paulproteus|lapt> Oh that's why gaim was using all my CPU....
<stub> Launchpad will be going down for scheduled maintenance in 30 mins. Estimated downtime is up to 3 hours. Wikis will be in read only mode during this time.
<psusi> so is there someone in charge of fixing xserver regressions since breezy now that Daniels is gone?
<seth> what happened to daniels anyway
<seth> if it is not a touchy subject
<infinity> seth: Erm, he doesn't work for Canonical anymore?
<seth> right, just wasn't sure where he went
<psusi> someone said he changed jobs... doesn't work at canonical anymore
<psusi> said something about getting a job at a cell phone company
<Amaranth> yep
<HrdwrBoB> yes, he works at a company ending in okia
<seth> i see, thanks :)
<Amaranth> hehe
<psusi> I've had a bug lodged for a few months now about a regression since breezy where x now thinks that microsoft intellimice have 11 buttons instead of only 9
<psusi> I'd had to see dapper released with a silly regression like that but... who's job is that now?
<infinity> No one's a fulltime X maintainer right now.
<psusi> he reassigned the bug to nobody
<infinity> Fabio and I are attempting to tackle some of the bug list in the next little while as theoretical "team leads" of the X SWAT Team, but not sure how far we'll get.
<psusi> ahhh
<infinity> psusi: The bugs should be assigned to the team.  x-swat in LP, I think.
<Amaranth> X is really a full tiem job
<Amaranth> time
<infinity> (search for "swat" in the search box, should find it)
<psusi> ok... I'll assign it to x-swat then
<infinity> Amaranth: Unfortunately, yes, but we're spread a bit thin.  Community involvement would be VERY appreciated.
<LaserJock> tritium: 
<LaserJock> hi
<tritium> hi LaserJock!
<psusi> I wish I knew more about how X works so I could fix it... but I don't, and I'm working on some kernel fixes and other things persuant to PacketCD and HardwareFakeRaid specs
<tritium> hmm, was hoping today's language-selector wouldn't give "could not open display" runtime errors, like yesterday's did...
<psusi> by the way.... git is a kick ass version control system ;)
<infinity> Except when your branch wedges itself, yes.
* infinity coughs.
* _ion catches some bacteria from infinity's cough.
<psusi> wedges itself?
<infinity> Oh, when halfway through a merge, it decides to just give up trying, and you're stuck with the leftovers.
<infinity> Acestry can get complex to the point where it just decides it doesn't want to try anymore.
<infinity> It's happened to me 2 or 3 times now.
<psusi> if you don't want to manually resolve the conflicts, then just git-reset --hard
<infinity> I'm not talking conflicts.
<psusi> it's just saying it thinks you need to intervene a bit... fix up the files and commit
<infinity> I'm talking ancestry tracing falling over hard, with painful errors and reasonably corrupt branches.
<psusi> hrm.... weird...
<psusi> I thought I had screwed things up like that a few times... but I usually just fix it by cat .git/refs/heads/origin > .git/refs/heads/master
<infinity> Yeah, intuitive. :)
<psusi> then I found git-reset --hard ;)
<stub> Is that an alias to rm?
<holycow> what is the name of the ubuntu notify applet?
<Amaranth> holycow: what?
<holycow> the ubuntu notify applet .. what is the name of that package? i need to remove it
<holycow> bah, called update-notifier heh
<msg43> Hi
<msg43> I hopeing someone can tell me how ubuntu suspends the machine such as what program or kernel patch is used.
<G0SUB> msg43: it just does `echo mem > /sys/pwer/state`
<Lathiat> It's not a kernel patch, its a standard part of the kernel
<msg43> G0SUB, are you serious?
<G0SUB> `echo mem > /sys/power/state`
<msg43> its that simple
<Lathiat> the actual suspending does a bit more work
<G0SUB> msg43: yes
<Lathiat> to make sure everythings in a good state to suspend etc
<Lathiat> btu thast the crux of it
<Lathiat> see /etc/acpi/sleep.sh iirc
<tritium> msg43: and configure acpi-support as I described in #ubuntu
<msg43_> well is there anythign I can do to get my video back?
<msg43> as when I do that I completely go blinded
<G0SUB> msg43: your ACPI is broken most probably
<G0SUB> msg43: which laptop is it?
<msg43> heh it a desktop
<G0SUB> hmm
<Lathiat> are you using the nvidia or ati (fglrx) binary drivers?
<G0SUB> msg43: is the ACPI standards compliant?
<msg43> I believe so
<msg43> its a k8mm-v voard
<msg43> hhmm no idea?
<G0SUB> jdub_: ping
<fabbione> morning
<YukiCuss> Afternoon.
<YokoZar> Is there a place in the filesystem hierarchy that's supposed to be world-writable AND persistant (eg: not /tmp)
<nictuku> yes /var/tmp
<YokoZar> That's not temporary?
<nictuku> it's not deleted on boot, if that's what you're asking
<YokoZar> I was just thinking about Wine.  A few users expressed interest in storing Windows applications system-wide, so different users could run them without having different installations in their home directories
<YokoZar> A sort of system-wide virtual Windows drive for Wine.  But somehow putting it in /var/tmp jives me the wrong way
<crimsun> /var/lib/wine/ ?
<YokoZar> crimsun: And make that world-writable?
<crimsun> that would be Bad.
<nictuku> Bad.
<nictuku> less bad if you use the sticky bit, though
<YokoZar> Well, it's sort of a given that any Wine-user could hose the shared Wine installation, heh
<nictuku> chmod +t
<YokoZar> Make a Wine group would be good
<nictuku> yes, you would have more control
<nictuku> that's more like a spool directory to me, though
<nictuku> hmm or not hehe
<YokoZar> Making it sticky might break some things (Windows apps tend to want to write to their own program files folder a lot...and My documents)
<YokoZar> overwrite, rather
<pitti> Good morning
<zakame> hello pitti
<pitti> hi zakame 
<desrt> pitti; SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu1
<pitti> desrt: hey
<pitti> desrt: what's that about?
<desrt> pitti; why do we advertise our exact version number in a way that makes it extremely easy to scan for possible known vulns in particular versions?
<pitti> desrt: ah, you mean the ID string at negotiation
<desrt> pitti; yes.
<pitti> no idea TBH
<desrt> pitti; why not send as little information as possible to not violate protocol
<desrt> probably something like SSH-2.0-foo
<desrt> k.  i'll file a bug then
<infinity> desrt: It's a catch-22, we've had administrators tell us that it's valuable to have as much info as possible, so they can run scans on their networks without logging in (or having to have accounts)
<infinity> And the bug has been filed.  Repeatedly.  Over several years.
<desrt> then i won't :)
<desrt> just seems really foolish to announce on connect the equiv of "these exploits will work on me...."
<fabbione> desrt: it would work anyway..
<desrt> since anyone scanning probably has a list of version#->exploits
<fabbione> security trough obscurity is almost pointless
<desrt> fabbione; not if the exploits require any degree of effort
<pitti> desrt: what would keep them from just trying?
<fabbione> desrt: if they really want to open it, they will just try
<desrt> pitti; opening a tcp connection and looking is very fast
<infinity> desrt: In theory, that's scary, in practice, I've never seen a worm that actually does version number checks, they all just bang you with exploits until one works.
<desrt> pitti; trying to exploit a flaw may take much longer
<fabbione> desrt: not really...
<desrt> pitti; if i know anything about why people get hax0red these days it's because of scanning
<desrt> nobody targets _you_.  they just scan...
<fabbione> desrt: not true either
<infinity> Yes, they scan ports, again, I've never seen anyone target based on version.
<G0SUB> fabbione: ++
<desrt> muh.
<infinity> (And they definitely scan known ports, since I've seen two machines on a network with identical versions of the same software, one on a standard port, one non-standard, and the non-standard one was left alone)
<infinity> But none of this will keep someone out who really WANTS in.
<desrt> i guess my argument is basically "there's no good reason to have the info there and a good reason (even if it is small) not to"
<infinity> However, the odds of kiddies building version support into tools designed to attempt to penetrate thousand of machines seems ridiculous.
<pitti> infinity: same for me; I moved ssh to another port to avoid brute force scans (which I had to endure for about a week)
<desrt> infinity; this is just my point... nobody really WANTS in anymore
<infinity> It's like worrying that spammers will add X-Debbugs headers to their mail, cause they really want to spam the Debian BTS, when they just want to spam SOMEONE.
<desrt> infinity; people want to collect the most shell accounts in the least time
<infinity> desrt: Right, and the road to "most shell in least time" isn't targetting specific versions, it's hammering everything you have at everyone.
<desrt> eh
<desrt> if i had a sploit that took manual intervention to properly use i'd run a version scanner to get me a list of all hosts that were vulnerable
<infinity> Why go to effort of researching who has what vulns and coding that in your scan tool when you can just attack every port 22 you can find?
<desrt> then i'd attack them
<infinity> If you have an exploit that requires manual intervention, you're already beyond the average script kiddies, mind.
<fabbione> infinity: desrt is a kernel hacker.. he can't be as good as a script kiddie...
<desrt> it isn't about script kiddies
* desrt is _not_ a kernel hacker :p
<infinity> desrt: Of course it is.  You're discussing mass scanning, automation, this isn't about anyone with talent. :)
<desrt> infinity; i'm talking about spammers, etc
<na7e> anyone here who is decent with gimp wanna make a usplash image for me, possibly for an upcoming offshoot of ubuntu?
<desrt> infinity; people with real reasons to control machines on other people's networks
<infinity> (Okay, people with talent will occasionally write the tools, but not use them.  And when writing a tool for mass dissemination, you're not going to hardcode applicatoin version numbers for stuff that has a 10 minute life on the internet before people upgrade)
<fabbione> na7e: you want to try and ask in #ubuntu-artwork
<na7e> ahhhh, thanks :)
<desrt> infinity; people upgrade?  heh.
<infinity> desrt: It's my experience that "spammers" and "kiddies" fit the same category, as far as how they get in. :)
<desrt> infinity; this is the _entire_ point
<desrt> infinity; finding the people who _haven't_ upgraded (a lot of them, i assure you) and focusing your efforts there
<desrt> infinity; ok.  quite possibly true.
<infinity> desrt: Anyhow, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=130876 and its many merged bugs.
<Ubugtu> Debian bug 130876 in ssh "Subject: ssh: -5 discloses too much infomation to an attacker" [Critical,Open]  
<infinity> Ubugtu's not that bright...
<infinity> That bug is wishlist, not critical.  Oh well.
<infinity> (It was filed critical, which I guess is the confusion)
<desrt> debbugs is actually less usable than launchpad :)
<desrt> although, you sort of get the impression that it wasn't designed to be used with a webbrowser as much as an email client
<infinity> Not in my experience..
<infinity> It's designed to be READ with a web browser, which works very well.
<infinity> It can't be manipulated with one, which is fine by me.
<desrt> all the 'download as mbox' links are a bit of a tip-off
<infinity> At least the bug lists are readable, and not limited to 3 per page for fear of query timeouts. :)
<infinity> desrt: Oh, a fair point is made in one comment on this bug...
<desrt> what is that?
<infinity> desrt: If you're running 3.4pl1 (and that's known to have a root hole, say), people with version scanners will attack you ANYWAY.  The addition of -3debian4.1 or something doesn't make you MORE vulnerable. :)
<desrt> i'm advocating the removal of all version information
<infinity> 3.4pl1 PLUS PATCHES!  That one's totally more hackworthy than plan upstream 3.4pl1
<desrt> not just debian stuff
<infinity> That breaks protocol.
<desrt> not if you replace it with crap
<infinity> (You can LIE about the version, but you can't remove it)
<desrt> ssh-2.0-fake0.0
<desrt> of course, for the first little while it becomes known that only ubuntu identifies themselves as "fake0.0"
<desrt> :p
<infinity> <shrug>.. There's a patch in the bug I aimed you at.  Revise it to allow faking the version, and see if Kamion thinks it's not a hideous idea.  I'm assuming he still won't like it unless upstream's all over the idea.
<desrt> upstream doesn't like the idea
<infinity> (The patch currently is for minimising version infO)
<infinity> I know upstream doesn't like the idea.
<desrt> another email here says that they have workarounds coded in the client to deal with certain server versions
<infinity> Yes, they do.
<infinity> Clients and servers both have workarounds to deal with each others' brokennes..
<infinity> ness...
<desrt> in that case, reporting bad info is worse than no info at all
<desrt> since it might enable bad workarounds
<desrt> bah
<desrt> forget i mentioned it :)
<desrt> this issue seems quite entrenched
<infinity> Very. ;)
<Mithrandir> iirc, Kamion is generally quite reluctant to take patches to ssh that upstream doesn't like.
<Burgundavia> Mithrandir, espresso bugs. Worth confirming and triaging or are you and Kamion on them?
<Mithrandir> Burgundavia: bugs or missing features?  https://wiki.ubuntu.com/UbuntuExpress/ToDo has a bunch of stuff we know is outstanding so if the problem is listed there it's probably just as good to comment on the bug saying "This is already on the todo"
<Burgundavia> Mithrandir, actual bugs, like https://launchpad.net/distros/ubuntu/+source/espresso/+bug/34922/
<Ubugtu> Malone bug 34922 in espresso espresso-frontend-gtk "changing the mount point device combobox adds new fields" [Normal,Unconfirmed]  
<dholbach> good morning
<simira> it's morning, at least
* Mithrandir ruffles simira 
<simira> gruff
<Mithrandir> mdz: I never received a response about the new xkeyboard-config?
<Tm_T> Seveas: whoa, somehow I can't send any messages to #ubuntu+1
<sivang> morning all!
<hunger> is language-selector known to fail on upgrade?
<highvoltage> morning, sivang 
<Fjodor> 'morning
<sivang> hey highvoltage , 'sup?
<highvoltage> sivang: rebuilding asterisk server. you?
<sivang> highvoltage: nice, as a debian package? (I'm still hacking on hub)
<highvoltage> sivang: nope, as in, an actual server that runs asterisk :)
<sivang> highvoltage: ah :) very cool. My cousin uses asterisk as a de-facto standard solution in his consultancy bussiness in NYC.
<highvoltage> nice
<sivang> highvoltage: I pushed him into implementing Ubuntu as desktop and server for almost every purpose :)
<Fjodor> pitti: Sorry I sent you a mail about glibc. Seveas told me it should go to Jeff Bailey. You were just the first I talked to...
<pitti> Fjodor: no worries, I forwarded it to Jeff
<pitti> hi sivang 
<pitti> Fjodor: thanks for the patch
* sivang hugs
<sivang> err,
* sivang hugs pitti
<sivang> :)
<highvoltage> sivang: we use ubuntu for our asterisk server, it worked nicely, but it was still running warty, so we decided to just give it a re-install
<sivang> (and everybody else for that matter)
<sivang> pitti: did you get my bug spam? ;-)
<Fjodor> Ah, ok. I subsequently made some changes (much helped by Seveas), and uploaded it to be fetched from my university account. Hope he does that rather than using the one I initially sent you
<Fjodor> And np. It is all in my own best interest :-)
<pitti> sivang: yes, will look at it ASAP
<sivang> pitti: yay!
<pitti> sivang: patch looks fine
<pitti> sivang: I'll add the bug number to the changelog, test, and upload
<pitti> meh, my vim is broken - is that just me?
<pitti> it just hangs at the console at start
<infinity> Works for me...
<pitti> meh, debsign too
* pitti blames the libc dist-upgrade
<pitti> ah, better
<sivang> pitti: /me does the happy dance :)
<pitti> sivang: thanks for taking care of that bug; dooglus is right, we probably have hundreds of simple-to-fix bugs lurking around which aren't assigned to anybody
<sivang> pitti: I've set a goal for myself after HUB and in between, to go over all of his bug which mostly have very good and ready patches, and prepare debdiffs for. Ofcourse until I get approved for main, I will rely on a sponser to get them in :)
<pitti> sivang: it'll already help to just verify bugs and assign them to the most appropriate main uploader
<sivang> pitti: yes, but as you can see doko took a look at it but it somehow got stuck. So I give my help wherever it's applicable, and well, I could use the packaging / fixing experience :)
<pitti> infinity: can you please try something? view /etc/init.d/mountall.sh (assuming that this invokes vi); does vi hang afterwards?
<dholbach> pitti: not for me
<sivang> pitti: which version of vim you have?
<pitti> odd, I reproduced it two times now, and only a reboot seems to fix it; WTF??
<pitti> sivang: dapper latest
<pitti> 1:6.4-006+2ubuntu1
<sivang> same here, doesn't hang
* sivang runs for an AS/400 meeting. be back later
<infinity> pitti: Can't break it here.
* infinity shrugs.
<pitti> hm, the problem seems to be that programs started from the console can't connect to the X socket any more
<pitti> infinity: thanks for testing, though
<pitti> arrgh, /me slaps his forehead
<pitti> mountall.sh cleans /tmp and wipes the X socket
<infinity> Y'know, I was going to upload to fix mountall at some point too.
<infinity> I guess I'm not the only person it bugs. :)
<pitti> sivang: uploaded, thank you
<Kamion> desrt: infinity is quite right, faking the version is a hideously bad idea and there *is* a good reason to have the version information in there, i.e. it's been repeatedly requested by network administrators
<Kamion> the version information wasn't added for fun - originally, it was requested by Cambridge University's Unix network admins who were trying to do friendly probing across all the ssh servers in the university so that they could advise people of vulnerable installations
<Kamion> I have never seen an argument against the version information that's better than the argument for it.
* infinity wonders if Kamion has this in a text file in his ~, so he can rapidly copy-n-paste as new people enter this 4 year old debate.
<Kamion> no :)
<pitti> would it be wrong to set a new default option ('dev.cdrom.lock=0') directly in /etc/sysctl.conf in the procps package? so far it has only comments
<Keybuk> what does that one do?
<Keybuk> (the sysctl)
<pitti> Keybuk: it avoids locking the CD-ROM drive, so that you can eject them using the eject button
<pitti> bug 17764
<Ubugtu> Malone bug 17764 in eject "Ejecting mounted CDs using eject button on drive" [Wishlist,Fix released]  http://launchpad.net/bugs/17764
<Keybuk> is that a kernel thing, or does it appear when you load modules?
<pitti> Keybuk: no idea, it's in /proc/sys/dev/cdrom
<Keybuk> try it, and reboot; and see whether the sysctl is still set
<pitti> yep, that's what I was about to do
<pitti> (just booting with init=/bin/bash)
<fabbione> dholbach: what's the name of the gnome package that sets up keyboards?
<dholbach> fabbione: gnome-control-center?
<fabbione> dholbach: ok.. do you have any opinion on #31524 ?
<fabbione> it looks everything other than an X bug
<dholbach> bug 31524
<Ubugtu> Malone bug 31524 in libxkbfile "character problem in turkish Q keyboard " [Normal,Unconfirmed]  http://launchpad.net/bugs/31524
<dholbach> fabbione: it could be both... he should add the information the dialog asks him for *GAR*GAR*
<Kamion> doko: any chance you could get jline to not need kaffe?
<fabbione> dholbach: ok can you please ask him so?
<Kamion> I assume it needs to be java-gcj-compat-ised
<dholbach> fabbione: done
<fabbione> dholbach: thanks
<infinity> pitti: Setting sysctls globally is a Bad Idea, as it leads to machines having conniption fits on computers without that hardware or those drivers (see the buildds and their anger over warty setting stuff on powerpc that elmo's kernels couldn't do)
<pitti> infinity: agreed, that's why I wonder about the correct place
<pitti> infinity: maybe the default should just be changed in the kernel
<infinity> pitti: That does seem more sensible, if it's a default we want our desktop users to have,
<sivang> pitti: thanks for the upload :)
<pitti> infinity: I get many complaints about the ejct button not working, and it generally works well (I just need to automatically unmount the device after its ejection)
<infinity> pitti: Yeah, then I say we just change it in the kernel directly.
<pitti> infinity: it even works right now, unmounting /cdrom after ejection is merely cosmetical
<pitti> Keybuk, infinity: alternatively, could we set this in an udev rule for cd-rom devices?
<pitti> it would avoid having to modify the kernel
<Keybuk> pitti: I don't see why a udev rule is any good
<Keybuk> setting it in sysctl.conf is better than a udev rule
<Keybuk> it's easier to find to disable, for one
<carlos> pitti: hi, did you see my bug about blender?
<pitti> carlos: I'm not yet through my bugs inbox
<carlos> ok
<Keybuk> also, more pointedly, a udev rule would reset the sysctl every time a cd rom drive was "detected"
<Keybuk> which would annoy anyone who kept turning it off again by hand
<carlos> pitti: the blender guys want to do a kind of translation day but we don't have Dapper's version imported becuase the fix you did for breezy to regenerate the .pot file was lost with dapper
<pitti> carlos: huh? someone dropped it?
<infinity> pitti: I'd change the default in the kernel, and add a commented-out entry in sysctl.conf telling people how to change it back.
<infinity> pitti: But that's just me.
<pitti> ok, I'll ask BenC about it, it sounds good to me at least
<doko> Kamion: looking ...
<doko> Kamion: jline done
<Kamion> thanks, should make the world installable again I think
<doko> pitti, Kamion: looking at CD sizes, we maybe want to remove openoffice.org-thesaurus-en-us from language-support-en again ...
<doko> - 5MB
<Kamion> any gtk/pygtk experts around? I need to create a multi-column list, which is conceptually just one column of data but which is displayed as multiple columns just in order to make better use of horizontal screen space
<Kamion> ideally I'd be able to specify the preferred size / aspect ratio of the resulting view
<Kamion> as far as I can see GtkTreeView doesn't offer this natively, although it might be possible to build it out of the various building blocks provided ...
<Keybuk> a multi-column list would suggest GtkTreeView
<Kamion> see my previous comment
<Keybuk> which has the most evil API that satan ever spawned
<Keybuk> I'm not sure what you mean by "doesn't offer this natively" though
<seb128> GtkTreeView is to make different columns in a same table
<seb128> not different tables placed side by side for the same model
<Kamion> GtkTreeView's existing column interface is designed for rows of data which each have several attributes presented as columns
<Keybuk> not necessarily
<Kamion> it's not designed to dynamically rewrap a single-column list of data into columns
<Keybuk> you can present the same attribute in multiple columns different ways
<Kamion> Keybuk: if you know how, then that is my question
<seb128> Kamion: I don't know any way to do what you want to do, I guess you will have to split the model and make different TreeView for every model or something like that
<Keybuk> Kamion: if you want to do what I think you want to do, then I know how
<Keybuk> but you're not being clear enough
<Kamion> seb128: ouch
<Kamion> Keybuk: example: list of languages in espresso
<Kamion> it's very long
<Keybuk> oh, I see what you mean
<Keybuk> that's evil
<Kamion> displaying it in a single column makes poor use of horizontal screen space
<seb128> Keybuk: he wants to do | column1 || column1 next items || column 1 ....|
<Kamion> I want to wrap this column vertically, newspaper-style
<Keybuk> yeah, I understand now
<Keybuk> no, you can't do that easilyt
<Kamion> can I retain a gtk expert to write a widget to do it for me?
<Kamion> it looks to me as if the various pieces of the treeview interface are separated enough that one could write a replacement for just GtkTreeViewColumn or something that would source all the data from a single list
<Kamion> maybe not GtkTreeViewColumn, I don't know exactly
<Kamion> lots of treeviews as seb128 suggests *might* be possible but it seems to me that trying to make that scroll neatly would be difficult, and making it keyboard-navigable would also be awkward
<seb128> Kamion: maybe mvo has some good idea for that, but afaik there is no easy way to do what you are looking for :/
<Keybuk> yeah, scrolling and navigation would be the bitch
<Keybuk> also working out how many columns you had room for, and responding to resizes
<Kamion> because normal behaviour for horizontally-scrolled tables in UIs I've seen is to make the scrolling jump from cell to cell horizontally, not pan smoothly across
<Kamion> seb128: right, not necessarily expecting there to be an easy way, but this is for espresso and I think it's one of the "please get a gtk expert to handle this" items that mdz wants me to get others to take care of
<Kamion> I saw a reference to some WrapBox widgets in GIMP which somebody claimed might help
<Keybuk> yeah, was just reading that one
<Keybuk> that has an aspect-ratio propery too
<Keybuk> GtkHWrapBox and GtkVWrapBox are the non-abstracts
<Kamion> I haven't checked - can you select individual columns in a normal treeview?
<Kamion> I thought you could only select whole rows
<cmvo> pitti: Hi! I've been referred to you about a possible security update for flashplayer-mozilla and flashplugin-nonfree for breezy and hoary.
<doko> Kamion: need a main inclusion report for jline?
<pitti> hi cmvo
<pitti> cmvo: hm, there has been a recent update for flashplugin-nonfree, is that a different issue?
<Cassidy> there is UVF for this package
<pitti> cmvo: anyway, I'd gladly do updates if anyone (you?) provide me with tested debdiffs :)
<Cassidy> https://launchpad.net/malone/bugs/35425
<Ubugtu> Malone bug 35425 in flashplugin-nonfree "UVF exception 7.0.61 -> 7.0.63.1" [Normal,Confirmed]  
<cmvo> pitti: Adobe has released a security update for the flash player. See http://www.macromedia.com/devnet/security/security_zone/apsb06-03.html
<pitti> cmvo: ah, I remember reading that on bugtraq, right
<Kamion> doko: yes please
<cmvo> pitti: I don't know if the linux version is vulnerable. But it would be nice to have the newest version.
<Keybuk> hmm
<Cassidy> and i think than Breezy and Hoary packages are also broken (https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bug/29214)
<Ubugtu> Malone bug 29214 in flashplugin-nonfree "package is falulty in downloading the binary" [Major,In progress]  
<pitti> cmvo: hm, before updating the version in breezy there should be regression tests and a verification that it is indeed vulnerable
<Keybuk> gtkwrapbox does weird things
<G0SUB> is it possible to put in new language packs of Firefox into Dapper?
<pitti> G0SUB: there are updates?
<pitti> G0SUB: from upstream?
<G0SUB> pitti: no, new languages ... not in upstream yet
<pitti> G0SUB: ah; yes, sure, if someone tosses me an xpi, I can include it
<G0SUB> pitti: do I need to file a bug?
<pitti> G0SUB: you can if you want; would be nice to have references and not forget about it
<G0SUB> pitti: I will do that rightaway :)
<pitti> G0SUB: assign it to me (martin.pitt@ubuntu.com) please
<G0SUB> thanks a lot
<pitti> cool, thanks
<G0SUB> okay
<Kamion> Keybuk: if you could take this on for the espresso GTK frontend language and keyboard selection widgets, I'd be very grateful
<cmvo> pitti: I could test on hoary and breezy in addition to dapper. But I don't know if Adobe will confirm if the linux version is vulnerable.
<Keybuk> the box thing seems to be what gimp uses for its toolbar palette
<Keybuk> so you'd get that behaviour
<cmvo> pitti: Lots of work for something non-free, but some users I support need it for a few webpages.
<pitti> cmvo: I guess the package has no source, so we can either take the new upstream version, or not fix it at all?
<cmvo> pitti: flashplugin-nonfree is an installer, there should be source. But I don't think it gets the newest version automatically.
<pitti> slomo_: ^ any idea about that one? IIRC it was you who proposed the last update, right?
<Kamion> Keybuk: that seems OK, if it works for text too
<Keybuk> Kamion: what's the GTK frontend written in?
<cmvo> pitti: It seems it doesn't, according to bug #35425 in lauchpad.
<Ubugtu> Malone bug 35425 in flashplugin-nonfree "UVF exception 7.0.61 -> 7.0.63.1" [Normal,Confirmed]  http://launchpad.net/bugs/35425
<Kamion> Keybuk: hmm, would need to give it scrollbars though
<Kamion> Keybuk: python
<Kamion> and glade
<Kamion> I do already have a C widget in there though
<Keybuk> I'm not sure wrapbox is appropriate
<Keybuk> it's not scrollable
<Keybuk> is damned slow
<Kamion> ah, ok
<Keybuk> and there's no easy way to make all the contained buttons the same size, fwict
<Kamion> the C widget's for the timezone map, I added python bindings
<pitti> sjoerd: ping
<sjoerd> pitti: pong
<pitti> sjoerd: it seems that we need to run gen-libgphoto-hal-fdi during hal's package build (or even better, at postinst time), right?
<Keybuk> Kamion: http://people.ubuntu.com/~scott/wrapbox.tgz
<pitti> sjoerd: otherwise non-PTP cameras won't be detected by g-v-m
<Keybuk> (unpack in a dir, make, ./gtkwrapbox-test) -- that demos what that would do
<doko> pitti: please review https://wiki.ubuntu.com/MainInclusionReportJline
<StevenK> NEVets1
<StevenK> Oh crap
<siretart> rootpw ;)
<StevenK> No so much
<Kamion> Keybuk: ew, definitely don't want it to be buttons for each language
<StevenK> Er, not
<G0SUB> pitti:  Bug #35704
<sjoerd> pitti: best solution would be for libgphoto2 to include the fdi for hal
<Ubugtu> Malone bug 35704 in firefox "Locale for Bengali-India (bn_IN) is not available" [Normal,In progress]  http://launchpad.net/bugs/35704
<Keybuk> Kamion: indeed; not sure this widget is appropriate
<Kamion> the presentation of a normal treeview with cellrenderertext is appropriate, it just needs to be multi-column ...
<pitti> G0SUB: thanks
<pitti> doko: queued
<G0SUB> pitti: my pleasure :)
<sjoerd> pitti: i talked to the libgphoto maintainer about this once and he thought it was a good idea, but it stayed at that i gues..
<Keybuk> Kamion: yeah, the bitch there is deciding how to scroll it :)
<Keybuk> I guess horizontally is "canon"
<pitti> sjoerd: ok, doing it this way around would probably work, too
<pitti> sjoerd: so we just need to ship that tool in hald
<pitti> s/hald/hal package/
<sjoerd> pitti: would be better if the scripts was in the debian pcakge for libgphoto2.. no need to have it on your system or have the buildd's install hal to build libgphoto
<Kamion> Keybuk: horizontal is fine and what Mark asked for
<sjoerd> pitti: the script is trivial and doesn't really change..
<pitti> sjoerd: true that
<pitti> sjoerd: alright, thanks for your feedback
<sjoerd> pitti: np, thanks for reminding me of the issue ;)
<Keybuk> GOD DAMN CDBS TO HELL
<Keybuk> quest gtk+2.0-2.8.16% debian/rules extract
<Keybuk> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
<Keybuk> I HATE YOU
<Kamion> Keybuk: no, you can't have the source, why did you ask?
<Keybuk> apparently I need to install exim4 just to FUCKING UNPACK a source package!
<dholbach> Keybuk: gtk+2.0 doesnt use cdbs
<Keybuk> dholbach: well, whatever it uses should be burned
<pitti> Keybuk: missing dependency on gnome-pkg-tools?
<pitti> Keybuk: or, rather, you don't have it installed?
<seb128> Keybuk: it uses DBS, so stop ranting about CDBS now :p
<pitti> he should rather rant about packages which modify debian/control :)
<seb128> Keybuk: and how does that make you installed exim4?
<Keybuk> pitti: packages should be able to be unpacked with just build-essential
<Keybuk> I should not need the entire list of build-deps just to read the damned source
<pitti> Keybuk: I fully agree :)
<Keybuk> seb128: gnome-pkg-tools -> svn-buildpackage-> exim4
<Kinnison> svn-buildpackage needs exim4?!?!?!?!
<pitti> I guess that was just an exaggeration
* Kinnison adds some slashes and ones to that
<Kinnison> for added emphasis
<Tm_T> :p
<Keybuk> Kinnison: yes, because subversion-tools depends on a mail-transport-agent
<Tm_T> I'm very frustrated
<Tm_T> I don't get pypanel to work in my dapper
<Keybuk> because it contains one script (out of a hundred) that uses /usr/sbin/sendmail
<Kinnison> odd
* Kinnison has gnome-pkg-tools installed and no postfix or exim4
* Kinnison wonders if he's very out of date
<Keybuk> Kinnison: you don't have the recommends installed then
<Kinnison> god no
<pitti> Keybuk: svn-buildpackage is only a Recommends
* Kinnison doesn't install recommends by default
<Keybuk>           The `Recommends' field should list packages that would be found
<Keybuk>           together with this one in all but unusual installations.
<Keybuk> suggests me to me that Recommends should be installed by default
* pitti never installs recommends either
<pitti> so that should be a Suggests: rather
<Kinnison> I don't install recommends because most packages put stuff in recommends which should be in suggests
<Keybuk> it's still a minor issue compared to the "packages should only use build-essential to unpack themselves "one :)
<Kinnison> Keybuk: get Wig&Pen sorted and I'm sure we can work toward that
<Keybuk> Kinnison: what's that got to do with me?
<Keybuk> that's a dpkg issue
<Kinnison> Keybuk: you're whinging
* Keybuk points you at the dpkg team
<Kinnison> Keybuk: s'your itch
<pitti> Keybuk: debian/control mangling is usually in the clean rule; where else could it live?
<Keybuk> it's an itch of every sensible and right-thinking person in the free world
<Keybuk> damnig
* seb128 doesn't install Recommends neither
* mvo has the "make apt install recommends by default" thing on his todo list
* seb128 will hate mvo if he does that
<Keybuk> mvo: please do
<Keybuk> if people get Recommends by default, they'd stop abusing it
* Keybuk looks at seb128 pointedly
<Keybuk> (Mr. I abuse package fields regularly) :p
<mvo> seb128: sorry, but that's the way forward
<seb128> that's not true :p
<seb128> mvo: sure, you want to make a mess for dapper just do it
<mvo> seb128: I may consider adding --no-recommends ;)
<seb128> mvo: I think we should take a cycle to clean Recommends before doing that
<mvo> seb128: dude, not dapper
<Treenaks> mvo: 99% of Recommends: are crap now
<Keybuk> Kamion: ok, so modifying the GtkTreeView code is a non-starter
<Mithrandir> seb128: did we or didn't we get an UVF exception for xkeyboard-config?  It appears mdz has disappeared off the face of the earth.
<Keybuk> the code is as bad as the API
<mvo> Treenaks: agreed. the only way to fix this is to make them installed by default 
<seb128> mvo: oh, your TODO goes after dapper .... I can find you some dapper items if you want :p
<mvo> seb128: I already start crying when looking on my todo list, don't make it worse
<seb128> Mithrandir: I think he didn't reply to your ping from friday ...
<Keybuk> Kamion: what do you want each cell to look like?
<seb128> Mithrandir: better to wait before uploading imho
<pitti> mvo: hm, what would make a Recommends different from a Depends then? only that you can uninstall it again?
<seb128> pitti: yeah, I think that's the goal. Stuff that should be installed by default because most user need them but than a poweruser may want to uninstall
<seb128> pitti: like libgnomevfs2-extra (smb:)
<mvo> pitti: exactly this
<Keybuk> pitti: Recommends is supposed to be an optional dependency
<Keybuk> "you should really have this, but the world won't end without it"
<Keybuk> "kittens may die, but not the mother"
<Keybuk> etc.
<Keybuk> whereas Suggests is "no kittens will be harmed if you don't install this"
<Kinnison> We have 'Enhances' yes? Do we have 'Enhanced-By' or similar?
<Keybuk> Kinnison: that would be Suggests
<Keybuk> Enhances is the opposite of Suggests
<Keybuk> A Enhances B ~= B Suggests A
<Kinnison> To me, Suggests is stronger than Enhanced-By, but that's probably just my interpretation of the english
<Kinnison> Esp. if Recommends is "Depends which can be uninstalled without breaking the world"
<Keybuk> they both indicate a relationship that should not be followed by default
<Keybuk> from a package manager point of view, what would be the difference between Enhanced-By and Suggests?
<Keybuk> Depends = (follow, unbreakable); Recommends = (follow); Suggests = ()
* Kinnison is trying to rationalise the language in his head to find out if they resolve to the same thing
<Keybuk> Enhances = (), just the other way around
<Kinnison> from a package manager PoV, they're equivalent
<Kinnison> I'm thinking from a user PoV
<Kinnison> give me a minute or two
<Treenaks> You could have external entities creating packages that 'Enhances:' something (but the package can't Suggests: those, because they're external)
<Treenaks> And you might be warned if you deinstall the package that gets enhanced but not the enhancers
<Kinnison> I think the difference is. Suggests are something which the package will use if it finds them and Enhanced-By are things which might be useful to have around which aren't directly related
<Kinnison> But I'm not 100% on that yet
<Kinnison> Keybuk: Nope, I agree, nothing I can think of from a use-case PoV needs Suggests/Enhanced-By to be split into separate fields because each use-case I come up with the result is that either would do. You're right.
<Kamion> Keybuk: each cell should look like a cell in the existing espresso language/keyboard selection widgets
<Keybuk> I don't know what those look like, do you have a screenshot?
<Kamion> Treenaks: that was indeed the original rationale for enhances
<Kamion> Keybuk: http://people.ubuntu.com/~cjwatson/tmp/espresso-sideimage-keyboard.png is an old screenshot which happens to show it
<slomo_> pitti: flashplugin-nonfree? no idea and i didn't propose the last update ;)
<pitti> slomo_: ok, thanks :)
<Keybuk> it'd probably be easiest to modify the old GtkList widget into doing the right thing
<Keybuk> but then seb128 would have "you're using a deprecated widget!" kittens
<Kamion> is there any way at all to do it using the hooks that pygtk provides for constructing custom treemodels and the like?
<Kamion> I'd much rather the widget be in python if at all possible
<Keybuk> I have no idea
<Keybuk> I know more about botany than I do about pygtk
<Keybuk> from what I know of the treeview widget, I doubt it
<Keybuk> each column is a widget in its own right
<Keybuk> the entire column (each row, the spacers, etc.) are all drawn by the same cell renderer widget
<Keybuk> you'd have to have a treeview that when reaching the end of the vertical allocation, created a new column, and assigned the items to that
<Keybuk> and that's just not supported by the model/view interface it uses
<Keybuk> we're pretty much in "write a custom widget from scratch" territory I think
<Mithrandir> you want something like the horrible, horrible cups printer manufacturer widget?
<Keybuk> Mithrandir: ooh, where can I see that?
<fabbione> ogra: ping?
<Keybuk> Mithrandir: the cups "Add a printer" thing here uses the standard widget fwict
<ogra> fabbione, pong
<Kamion> Keybuk: the alternative, I suppose, is just to hardcode a bunch of columns in the calling code, given that the interface is pretty much fixed-size
<Kamion> but that would break different font selections (e.g. accessibility) so is probably a non-starter
<Keybuk> Mithrandir: it's just a single column list of models
<Keybuk> tbh, I'd just use one column :)
<Mithrandir> Keybuk: no, the manufacturer list
<Keybuk> Mithrandir: that's a drop-down here, not a list
<Kamion> Keybuk: Mark explicitly asked me to stop doing that
<Mithrandir> yes, and it's a horrible 3xN matrix.
<Kamion> and I can see his point, the current UI is nasty
<Keybuk> Kamion: yes, well, Mark isn't very good at user interface design
<Kamion> Keybuk: in this case he's absolutely right
<Keybuk> inventing a custom widget that behaves exactly the opposite to every other widget on the system is wrong
<Kamion> if you fire up espresso and look at the language page, it *sucks*
<Keybuk> Mithrandir: hmm, I see what you mean; they've just used a popup menu
<Kamion> there's a huge pile of empty vertical space that there's no easy way to fill
<Kamion> er, empty horizontal space
<Keybuk> why not use the empty horizontal space to display an image of the keyboard layout currently highlighted?
<Kamion> works for keyboard, what do you do for language?
<Keybuk> in fact, almost exactly like the GNOME one does currently :)
<Kamion> I'm not convinced that the GNOME one is the epitome of usability
<Keybuk> no, the treeview on the left is too small
<Keybuk> but having an image of the keyboard is damned useful, you can just scroll with the arrows and match it up
<Mithrandir> Keybuk: no, we can't do that.  We have no idea what the keyboard looks like.
<Kamion> it forces you to scroll a great deal, and to know what your keyboard layout is called in order to have a hope of scrolling to roughly the right place
<Kamion> oh yeah, plus what Mithrandir said due to the limitations of how we're handling keyboards in espresso at the moment
<Kamion> (remember that the GNOME keyboard layout widget has the luxury of only having to select X keymaps)
<Keybuk> *shrug* I still think it's better than inventing a sideways widget
<Mithrandir> we're really forcing d-i to do stuff that it wasn't near being designed to do.
<Kamion> that's not particularly the problem, and that can be fixed after dapper once we move to cxkb or whatever
<Kamion> Mithrandir: how close are you to something we can merge for keyboard selection?
<Kamion> Kinnison: are you still launchpadding this week?
<Mithrandir> Kamion: tomorrow, I hope.  The Korean stuff works now, I'm just waiting for mdz to get around to approving my UVF exception request.
<Kamion> ok, thanks
<Kinnison> Kamion: No, I'm currently catching up on everything for distro
<Kinnison> Kamion: So if you have stuff for me for espresso, then go ahead, otherwise I believe I have the de-tabbing and stage X of Y to implement in espresso
<fabbione> so i just figured that we have an xterm package that sucks
<Kinnison> and other than that, ca. 75 mails from launchpad about bugs in g-p-m etc
<fabbione> the worst part is that the orig is native
<fabbione> what was the trick to switch it have to orig.tar.gz?
<Kamion> Kinnison: right, the breadcrumbs thing was what I was thinking of
<Kamion> fabbione: stick the .orig.tar.gz in .., rebuild with -sa
<fabbione> Kamion: isn't LP going to hate me for that?=
<Kinnison> Kamion: I'll do that before I get to the g-p-m mails then
<Kinnison> fabbione: Ensure it's a newer version too
<Kinnison> fabbione: then it should be fine
<Kamion> fabbione: why would it?
<fabbione> Kinnison: newer as in upstream or debian/ubuntu?
<Kinnison> the latter
<fabbione> Kinnison: ok
<fabbione> Kamion: dunno.. i never had to do it before
<Kamion> "foo.tar.gz" != "foo.orig.tar.gz", which is all that matters
<Kinnison> Kamion: because LP is a grouchy complaining crotchety youngling
<Kamion> if the filenames clashed, then there would be a problem, but they don't
<fabbione> ok
<fabbione> thanks
<carlos> doko: hi, around?
<doko> carlos: yes
<carlos> doko: I have ooo-unused and ooo-help translation domains on dapper for OpenOffice
<carlos> doko: the others are already imported for dapper, what should I do with those two?
<carlos> import? ignore?
<doko> carlos: we did talk about ooo-help, that will be splitted
<doko> -unknown: I can't see that ooo-unknown is still generated
<carlos> doko: i Know, that's why I'm asking, just to confirm that I should ignore that import, right?
<carlos> doko: so I can ignore the unused, ok
<carlos> lunch time
* carlos -> out
<carlos> later
<doko> carlos: don't start your talks before lunch ;-P
<carlos> doko: Is there anything elso to talk? I think I got the info I needed :-P
<carlos> doko: btw, thanks :-D
<doko> carlos: yes, ignore me^Wthem :-D
<Keybuk> Kamion: really doesn't look like it's easy to modify gtktreeview into doing the right thing
<Keybuk> the trouble is that there's no way to find out that you've reached the bottom and need to wrap back to the top
<Keybuk> *and* be scrollable
<fabbione> dholbach, seb128: /usr/share/menu/xterm
<fabbione>  <- is this the correct location?
<dholbach> fabbione: for what? a debian style menu entry?
<dholbach> fabbione: if you want a gnome menu entry, you want /usr/share/applications/something.desktop
<fabbione> dholbach: that's from debian 
<fabbione> so i guess it's fine there
<fabbione> thanks
<seb128> fabbione: that one will give you a Debian menu item
<fabbione> seb128: thanks
<fabbione> i am ok with that
<mdz> Mithrandir: I have no mail in my inbox from you
<Mithrandir> mdz: no, because I asked you about it on Friday and then you went silent.
<Mithrandir> mdz: the diff isn't very useful since we have something resembling upstream's 0.7 as our 0.6
<mdz> Mithrandir: IRC messages over the weekend are not reliably received; sometimes I do actually leave home
<mdz> email is best for that sort of thing
<mdz> come to think of it, I wasn't even logged into IRC on Friday; I was still in transit
<Mithrandir> mdz: you said something at 11:15 UTC at least.  I asked you about 30 minutes later.
<Mithrandir> mdz: anyway, sure, you'll get mail next time.
<mdz> Mithrandir: I left at 11:30 to go to Heathrow
<Mithrandir> mdz: the upstream NEWS file just says: "Maintenance release. Bugfixes. Updated/new translations. Updated/new layouts. Massive patch from Sun Microsystems incorporated.".  seb128 and I have been running the new version for a few days without ill effects.
<seb128> and according to daniels that should be ok
<Mithrandir> mdz: the most important bug it fixes is 21595 which (as you can see) half the world is subscribed to.
<mdz> Mithrandir: the patch we have in breezy was supposed to fix that as well, but it's unclear to me whether it actually did
<Mithrandir> mdz: it appears not to.
<Mithrandir> mdz: also, it apparently fixes a crasher in gnome-settings-daemon.
<Mithrandir> seb128: ^^ is that correct?
<mdz> Mithrandir: I talked with seb about 0.8 last week and I think we should try it, but sooner rather than later
<mdz> Mithrandir: and with an explicit call for testing
<Mithrandir> mdz: sure, I have the upload lined up already.  It also adds Korean support, so we just need to fix some minor faff in Xorg and scim-hangul; then Korean keyboards will work correctly out of the box.
<Mithrandir> mdz: I was just waiting for a go from you.
<mdz> Mithrandir: go
<Mithrandir> uploaded.
<Mithrandir> (and thanks)
<seb128> Mithrandir: yeah, correct
<Mithrandir> seb128: can you send out a call for testing of 0.8?
<Kamion> mdz: did you get round to talking with kiko/elmo about the status of the sync tool?
<Kamion> if it's working, I'd like to try it out by syncing in bcm43xx-fwcutter
<mdz> Kamion: I did talk with kiko but did not reconcile what he told me with elmo yet
<seb128> Mithrandir: hum, keyboard is basically something used by everybody 
<mdz> elmo: ?
<seb128> what call for testing?
<seb128> "let we know if your keyboard is broken"?
<seb128> I think people will complain about it without any invitation :p
<Kamion> "let us know if your keyboard never used to work but now does", perhaps ...
<pitti> seb128: how should they type the answer email? :-P
<pitti> seb128: (if it's broken)
<seb128> selecting chars with the mouse from gucharmap and copying them?:)
<Mithrandir> pitti: they should manage when I've gotten korean keyboards to work without knowing korean
<fabbione> hmm not too bad
<fabbione> from 200 to 183 bugs in one day of X work
<Kamion> mdz: kiko is incorrect
<Kamion> mdz: maybe some bits of it work, but /srv/launchpad.net/codelines/current/scripts/sync-source.py definitely doesn't
<Kamion> oh, hmm, I need LPCONFIG=ftpmaster
<Kamion> still fails though
<Kamion> psycopg.OperationalError: FATAL:  Ident authentication failed for user "ro"
<Kamion> ; used connection string 'dbname=launchpad_prod user=ro host=jubany.ubuntu.com'
<mdz> Kamion: seems like deployment problems rather than incompleteness so far
<mdz> kiko should be awake
<fabbione> hey mdz
* fabbione gets a choccolate cookie 
<mdz> good morning
<lemsx1> good morning
* Mithrandir hugs seb128 
* seb128 hugs Mithrandir
<Robot101> # and caaan you feeel the love tonight...
<jsgotangco> errr
<zakame> oooh
<mdz> jdub: fridge calendar needs updating for the new release schedule
<aquarius> Will a package that has recently gone into Debian unstable make it into Dapper? I don't know when the next sync-with-Debian is, or whether there's one before the release.
<Kamion> aquarius: not in general before release, although we can make specific exceptions
<aquarius> Kamion: ah, OK. Is a recent unstable Debian package likely to work in Dapper? It's gccxml.
<Keybuk> wow, what a hack
<Keybuk> cute, but eeeevil
<Kamion> doko: opinion on gccxml?
* sivang wonders how the horizontal rows issue ended up.
<doko> Kamion: for main???
<doko> no, that's based on gcc-3.2.something
<Kamion> doko: no, to sync from Debian
<doko> universe, why not
<aquarius> doko: the Debian package is based on a CVS gccxml, which works with gcc 4.0.
<fabbione> Kamion: could you be so kind to tell me why ubuntu-desktop is still not installable on sparc? infinity and I fixed the powermanagement-interface this morning, but i can see there might be more around...
<fabbione> Kamion: i would do it myself.. but -ENOSPARC for a couple of days
<aquarius> (or so the ITP and surrounding mails say)
<doko> aquarius: they do write that, but looking into the source, before it went into debian, it had the 3.2 version strings.
<Kamion> fabbione: difficult to say without just trying apt-get install, I'm afraid
<fabbione> Kamion: ok :/
<Kamion> britney isn't particularly big on extra debugging output
<aquarius> doko: ah -- I'm happy to bow to your wisdom on this. I want to use it for wrapping a C library with Python, and I didn't want to compile it myself if it's going to appear in Dapper tomorrow. :)
<fabbione> i don't know why i had the feeling we had a tool to catch that...
<Kamion> fabbione: uninstallable gnome-power-manager seems like a possibility
<fabbione> Kamion: that should have been sorted with new powermanagement.. but i will look.. thanks mucho
<Kamion> mdz: remember the talk at the UI sprint about wanting the language and keyboard selectors to be horizontally-scrolling tabular lists?
<Kamion> mdz: we've been looking at that today, and it's more difficult than expected; getting the right scrolling, keyboard navigation, placement depending on fonts etc. semantics isn't possible with anything GTK gives us at the moment
<Kamion> mdz: Keybuk estimates ballpark 2-3 days to write the widget; do we want it enough to have him spend that time?
<mdz> Kamion: I'm not sure what you mean by horizontally-scrolling tabular lists
<Kamion> mdz: having the list of languages etc. be vertically wrapped, newspaper-style
<Kamion> oh, you weren't there on Friday
<mdz> no
<Kamion> the language and keyboard selectors are currently simple vertical lists
<mdz> can you give me an example of something similar in another program?
<Kamion> the problem with this is that it makes very poor use of screen space, and you end up with big empty spaces in the dialog
<Keybuk> there is nothing similar in another program
<Keybuk> the "closest" thing is the "Add Printer" "Manufacturer" drop-down ... like that, but as a horizontally-scrolling list box
<mdz> oh, I see
<mdz> you are talking about a multi-column layout
<Kamion> sabdfl asked for this to be changed so that it wraps vertically, a bit like say the entries on the Windows start menu
<Kamion> well, at least the start menu circa Windows 95 ;-)
<Kamion> and you then scroll left/right in case not all the languages fit
<mdz> right, I think I understand now
<Kamion> that would allow the widget to take up more of the screen, and increase the chance that your language is immediately visible
<mdz> since the request came from sabdfl, the question would be how badly he wants it
<mdz> I don't think I can speak to that
<Kamion> sabdfl: see the above discussion?
<sabdfl> mdz: i'm watching
<sabdfl> the discussion
<sabdfl> don't have time to fix gtk on this one
<sabdfl> so lets go with a smaller list and find a way to lay it out so it looks reasonable
<sabdfl> this bits us in a couple of places
<sabdfl> maybe ddlb?
<Kamion> ddlb?
<Keybuk> ddlb?
<sabdfl> drop-down list box
<sabdfl> i think that's what the mac os uses for, say, lists of countries
<Kamion> drop-down felt pretty unpleasant to me when I tried it
<Kamion> oem-config uses that
* Keybuk grabs a sandwich
<Kamion> also, since the espresso window is fixed-size based on the largest of any of its pages, that would leave even more empty space on the screen
<sabdfl> yeah, it's not right, but it has the advantage that it can use more of the screen when it's in use
<Kamion> you'd have a tiny drop-down widget sitting in the middle of it :)
<mdz> sabdfl: yes, that's what the OS X installer uses
<sabdfl> i'm wondering if we can't combine that question with other questions
<sabdfl> so we get more efficient use of space
<Kamion> not at all easily, I'm afraid
<sabdfl> but you sort of need that done before you can do anything
<mdz> right
<sabdfl> there is the space where people will type to confirm their keybord is set correctly
<na7e> howdy sabdfl
<sabdfl> hi na7e
<Kamion> in order to do that we'd have to have multiple debconf backends running at once, which is sort of direly painful
<sabdfl> sounds excruciating
<sabdfl> pass on that then :-)
<sabdfl> Kamion: this should not be a blocker for the next round, just do what works, we will prettify later
<sabdfl> how is it coming along based on ui sprint feedback?
<Kamion> although, er, well, maybe in theory, beginblock/endblock could help - but I think that's post-dapper
<sabdfl> is this the last issue on your list?
<Kamion> no, it's the hardest remaining thing outside partitioning
<Kamion> progress is pretty good again now, I just lost a lot of time last week to the breezy installer vulnerability
<Kamion> got the disk selector in this morning
<Kamion> localisation basically works, and I have a nearly-full Portuguese translation to test with now
<sabdfl> does gtk not give you a cell view, like a spreadsheet?
<Kamion> Kinnison: while I remember, there's some badness in gparted at the moment; the ok-to-apply dialog never appears
<Kamion> sabdfl: not that any of us can see - that would be ideal
<Kamion> perhaps there's something thievable in gnumeric
<na7e> would be nice if gtk did
<Kinnison> Kamion: Urgh
<Kinnison> Kamion: it's supposed to
* Kinnison will look at that
<Kamion> ta
<sabdfl> no reason not to embed a spreadsheet in the installer :-)
* Kinnison suggests we just embed colin in the installer
<Kinnison> it'll add intelligence to the mix
<Mithrandir> Kinnison: and you'll only be able to install with an irish accent? :-)
<Kinnison> Mithrandir: no, but it'll karate-kick you if you make a wrong choice
<sabdfl> kiko, jamesh are saying there's a gtk table
<na7e> i was thinking something completely different, hrm
<Kamion> is gtk.Table really appropriate? I normally use it for laying out widgets in the same way I'd use a vbox/hbox
<Kamion> with gtk.Table you'd still have to implement keyboard navigation, I'd expect
<Kamion> and it would not be able to automatically reflow columns based on the available size
<Kamion> tables are for very fixed layout, which this isn't really
<jamesh> Kamion: do you have a web page or mockup of what you are after?
<Kamion> jamesh: no, but think newspaper columns
<Kamion> only with each line on each column being a choice from a liststore
<Kamion> when it runs out of vertical space, it should wrap the list onto the next column and carry on
<Kamion> if it runs out of horizontal space, it should scroll
<jamesh> Kamion: I don't think there is a ready made widget that'll do all of that
<Kamion> that was indeed the general opinion. how hard would it be to write one?
<jamesh> using a list store as a backend?
<jamesh> probably hard
<Kamion> doesn't have to be a list store
<Kamion> I have a big list of strings
<jamesh> there is a GtkWrapBox widget in gimp that does some of what you want
<jamesh> it acts like a GtkBox but wraps when it runs out of space
<Kamion> Keybuk looked at that but seemed to think the result was poor
<jamesh> it has size allocation issues though
<Keybuk> jamesh: the allocation issues were a bit of a problem; and also the fact it's not scrollable
<Keybuk> so Colin would have to make sure the list of languages/keyboard layouts fit on one page
<Keybuk> and then there's the question of what exactly you pack *into* the box; buttons not being that great
<sabdfl> Kamion: http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_screenshots
<sabdfl> http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_project
<sabdfl> kiko says "this may not work today"
<Keybuk> sabdfl: that looks like an ordinary GtkTreeView?
<sabdfl> no, it's a GtkGrid
<Kamion> sabdfl: looks like that doesn't actually wrap vertically, since cells are falling off the bottom and there's a vertical scrollbar
<Keybuk> but I can't see what it's doing that GtkTreeView doesn't do
<Kamion> which isn't what we want
<sabdfl> kamion: we know in advance what language/keybd to put in what cell
<Kamion> sorry, I guess I wasn't quite with-it when I said that a spreadsheet-style cell grid would be perfect - the requirement to wrap vertically makes it very different from a spreadsheet
<sabdfl> we don't need it to figure that out dynamically
<Kamion> sabdfl: but we don't know the font size
<Kamion> which will be completely different if you're running with accessibility support turned on
<Kamion> we can't just hardcode the vertical wrapping
<sabdfl> we can say its a fixed number of vertical cells
<Kamion> but it isn't
<sabdfl> ok
<Kamion> we can't figure this out in espresso
<Kamion> we need the widget to do it based on its preferred size
<Kamion> or available size, something like that
<sabdfl> ok, np, keep going with select box or ddlb
<Keybuk> and we can't figure out the height of the TreeView/Grid because the way GTK+ works with scrolling is to pack it inside a different widget that scrolls around
<Kamion> Keybuk: could you have a look at turning the current widgets into drop-downs, and see how they look?
<Kamion> since you said on Thursday that you wanted to help :)
<Keybuk> this afternoon I'm going to try and get n-m up
<Keybuk> then tomorrow I'll bug you how to get started on d-i :)
<jamesh> Keybuk: when I talked with Owen about GtkWrapBox a few years back, the idea about how to handle size allocation sanely was to make the widget handle its own scrolling (set_scroll_adjustments(), etc)
<Kamion> righto
<Keybuk> I imagine I need some kind of test environment
<Kamion> for espresso, I normally just download and boot a current live CD, rsync the source tree over from my laptop, build it on the live CD, install it, run it
<Kamion> it's fairly easy to get going with that way, actually easier than d-i
<Keybuk> ok
<Mithrandir> as long as you don't need to run it through the whole process, just working in a normal system is fine
<Kinnison> I don't have enough RAM to do the liveCD trick most of the time
<Kinnison> have to rsync .debs
<mdz> Kinnison: which livecd trick?
<Kinnison>  mdz the build-deps and rsync-the-source trick kamion does
<mdz> its build-deps are fairly modest, no?
<Kinnison> the evo stuff weighs down
<Kinnison> and tmpfs only ever uses half ram
<Kinnison> so it gets a bit full
<Kinnison> :-)
<Kamion> mdz: the live CD doesn't have build-essential preinstalled so all that has to go into RAM
<mdz> Kamion: I forgot it had C bits in it
<mvo> why does busybox-initramfs conflicts with every other busybox in the archive?
<mdz> fabbione: why do we even build powermanagement-interface on sparc?
<mdz> fabbione: ubuntu-meta automatically excludes packages which do not exist on the target arch
<Robot101> ghrgh
<fabbione> mdz: because LP doesn't understand Not-For-US or PAS and it gets automaticlly builded. The problem is that we don't support Task: per arch and one of the pkgs in the game is arch: all = you lose
<mdz> fabbione: LP understands Architecture:
<fabbione> mdz: it doesn't understand PAS or NFU
<fabbione> so it gets to build gnome-power-manager
<fabbione> and powermanagement-interface
<fabbione> and it messes up
<mdz> fabbione: I don't see why we need those in this case; we should be able to use  Architecture:
<fabbione> mdz: it doens't work.. infinity and Ihave been there already.. once in breezy in which i had to ask elmo to rm -rf sparc binaries and now to solve it the LP way..
<mdz> fabbione: can you explain to me why?  I don't understand
<fabbione> mdz: because we don't support Task per architecture and one of the packages in the game is arch: all
<fabbione> mdz: so it ends up to be Task: ubuntu-desktop and pulls in stuff that is not installable on sparc
<fabbione> mdz: so we need to stub that package.. more or less what's done on ppc
<mdz> which package?
<fabbione> powermanagement-interface
<fabbione> at least it's one of them.. in breezy there were two
<mdz> pmi has an implementation for ppc which uses pbbuttonsd, no?
<mjg59> Yes
<fabbione> mdz: i said similar to ppc
<mdz> powermanagement-interface is not arch: all
<mjg59> mdz: Well, which replaces pbbuttonsd
<fabbione> mdz: on x86/x86_64/ia64 Depends: acpi-$something
<fabbione> mdz: that does not exists on sparc
<fabbione> mdz: since that package gets builded, and can't be excluded, we need to stub it
<mdz> fabbione: yes, but we don't  try to install _i386.deb on sparc either :-)
<fabbione> mdz: i did ask infinity NOT to build it
<fabbione> and he said that it cannot be avoided
<mdz> Architecture: i386 powerpc amd64 etc. should stop it from being built on sparc
<fabbione> so it lands in the Task: stuff
<fabbione> mdz: apparently it doesn't work that way.. i was told and i have to trust..
<fabbione> the same situation in breezy had to be fixed "manually" the hard way
<Kinnison> mdz: I think I got told off for obeying the Architecture files
<Kinnison> erm s/files/lines/
<Kinnison> It might need a P-a-s entry
<mdz> Kinnison: the build will fail anyway if Architecture: doesn't match
<mdz> no?
<fabbione> and P-a-s seems to be half broken
<mdz> doesn't sbuild check that?
<mdz> this certainly used to be the case pre-soyuz
<Kinnison> mdz: I thought sbuild ignored it too
<xhaker> i just installed dapper on a friends laptop, X failed to start "No Screen". i figured it out: the laptop has 2 graphic cards, the s3 was being detected, but the ati is the active one. it was wierd though, my laptop as 2 gfx card too, one is an intel the other ati too
<Kinnison> mdz: It's possible sbuild checks it
<mdz> fabbione: in breezy, a package with Architecture: i386 would not build on sparc.  it would be attempted but would fail
* Kinnison guesses infinity and cprov need to look into this
<xhaker> im going to see if similar reports exist on malone
<mdz> it resulted in build logs which looked like this:
<mdz> Fetched 10.5kB in 0s (0B/s)
<mdz> Download complete and in download only mode
<mdz> : powerpc not in arch list: i386 amd64 -- skipping
<fabbione> mdz: and perhaps it still works in LP.. i don't know.. i am not an LP buildd admin and i was told that it is partially broken.. hence i report what i am told..
<fabbione> Kinnison: why do you depend directly on acpi-support for g-p-m ?
<fabbione> Kinnison: powermanagement-interface will do that for you
<fabbione> and you already depend on it
<Kinnison> fabbione: I imagine because I was thinking about explicit deps when I did the acpi whitelist support
<Kinnison> fabbione: I'll fix that in my next upload
<fabbione> Kinnison: thanks, that would be awesome
<fabbione> Kinnison: if you want to keep the direct depends, can you please do so that sparc and hppa will have no acpi-support Depends ?
<Kinnison> fabbione: argh, of course
<fabbione> Kinnison: otherwise just let powermanagement-interface do it for you
<Kinnison> fabbione: Sorry
<fabbione> Kinnison: no problem.. i was just puzzled when today i couldn't install desktop :)
<fabbione> Kinnison: i was aware only of pmi with that problem
* Kinnison will try and fix it today
<Kinnison> lots of stuff going into g-p-m soon
<fabbione> Kinnison: thanks a lot
<na7e> do you guys know a way to associate a task with a package?  is the only way in the control file?
<fabbione> na7e: that usually involves to sacrifice a few goats to the ftp-masters together with a jar of gold and one of whisky
<na7e> fabbione, now where did i put that whiskey
<Kinnison> fabbione: can you file a bug on g-p-m so I remember
<fabbione> Kinnison: sure...
<Kinnison> fabbione: I'm currently up to my ears in gtkmm reminding myself of how this patch for gparted works
<fabbione> Kinnison: do you want me to just kill the Depends for you?
<fabbione> Kinnison: and you take over after?
<Kinnison> fabbione: No 'cos I have a non-uploaded version here
<fabbione> ok
<Kinnison> somewhere
<fabbione> sure
<Kinnison> just file the bug so I have something to close
<Kinnison> it'll make me feel more important
<sivang> heh
<fabbione> Kinnison: i can give you a few X bugs if you want..
<fabbione> Kinnison: #35735
* fabbione is disappointed because he did start working on X again and nobody noticed the -17 bugs dropped today
<Kinnison> fabbione: I've got enough bugs without X too
<maswan> If I store 10000 dapper isos in a tape library, do I win something? ;)
<seb128> fabbione: looks like a normal daily desktop count :p
* Kinnison stares at evo, 76 unread bugmails from LP to dealw ith
<Kinnison> still s'less than earlier
<fabbione> seb128: yeah right.. but desktop bugs < X bugs
<Amaranth> yay, x fixes :)
<fabbione> Kinnison: 76 emails.. or 76 bugs?
<seb128> fabbione: I would not bet on that
<fabbione> my bug inbox was about 650 this morning
<Kinnison> fabbione: Dunno 'til I go read, I'd guess somewhere between the two
<fabbione> seb128: do you want to swap for a while?
<seb128> fabbione: that would be a loose loose, you don't know GNOME and I don't know xorg
<fabbione> seb128: i think it's a win to win instead.. we both get to learn something new :)
<Amaranth> but it'd be funny ;)
<seb128> fabbione: but https://launchpad.net/people/desktop-bugs/+subscribedbugs == 2566 bugs atm
<seb128> fabbione: I don't discuss xorg gets load of bugs too, but don't denigrate desktop load :p
<Gwynn> but if you both learn something new that the other knows allready wouldn that spell r e d u n d a n c y ?
<fabbione> seb128: Linux was right.. gnome sucks :P
<seb128> :)
<fabbione> Linus even ;)
<fabbione> ok enough troll for seb128 today :)
* Gwynn is sorry and will shut up again
<fabbione> seb128: we have 1:10 ratio... 
<seb128> fabbione: yeah, let's back to work ;)
* seb128 hugs fabbione for tackling all those xorg bugs today
<bddebian> heh
<fabbione> seb128: :)))
<HiddenWolf> fabbione: bug sabdfl to write something like gnome's bugzilla weekly bug summary :)
<fabbione> HiddenWolf: hmm i would prefer graphs to show peaks of bugs and when/why they get squashed
<G0SUB> pitti: ping
<HiddenWolf> fabbione: right you are
<fabbione> they can give a really good overview of what happens when/why and how to optimize it for the next release
<fabbione> i did something like that for Debian BTS once... but i lost interest in getting it in place once i started to fight with the admins
<pitti> G0SUB: pong
<G0SUB> pitti: there is a language Hindi for which I could get only the translated file tree ... can you make the XPI yourself please ?
<pitti> G0SUB: hm, not sure
<G0SUB> hmm
<pitti> G0SUB: it requires some metadata
<G0SUB> everything that's required is there
<G0SUB> just that it's not zipped up 
<pitti> oh, if it has the manifest and install.rdf, I can certainly zip it myself :)
<G0SUB> the doc is here http://www.mozilla.org/projects/l10n/mlp_packaging.html
<G0SUB> pitti: hmm, it seems they are not there ... I will get back to you with the XPI ... you won't need to handle that pain
<pitti> Keybuk: is there a way to explicitly state in a preinst that a package drops a conffile? so that it doesn't count as owned by that package any more?
<Keybuk> remove it, should work
<pitti> Keybuk: hm, it's actually migrated from postgresql-common to postgresql-client-common, so I can't fully remove it
<pitti> but during the upgrade it's actually removed
<pitti> debian bug 357910
<Ubugtu> Debian bug 357910 in postgresql-common "Subject: Unable to upgrade: conflict between postgresql-common and" [Important,Open]  http://bugs.debian.org/357910
<pitti> Keybuk: i. e. p-client-common's preinst either rm or mv it, and p-client-common's postinst moves it back (with the standard conffile moving recipe)
<Keybuk> and this doesn't work?
<pitti> Keybuk: no, see the bug
<pitti> Keybuk: dpkg complains even although the file isn't there any more (just in dpkg's database, of course, but not on disk)
<pitti> Keybuk: my current solution is to Replace: all versions of postgresql-common
<pitti> Keybuk: before it was Replaces: p-common (<< 45)
<pitti> Keybuk: 357909 has a more complete log, btw
<Keybuk> don't you mean <= 45 ?
<pitti> Keybuk: 45 was the first version which introduced the package split
<pitti> Keybuk: but the versioned Replaces is wrong anyway, I guess, since people might upgrade from 44 to 49 or so
<pitti> Keybuk: so if p-common is already updated before p-client-common, it doesn't apply any more
<Keybuk> oh right
<Keybuk> and iwj's conffile patch breaks it?
<pitti> the versioned conflict shoudl be fine
<Keybuk> versioned replaces
<pitti> Keybuk: no idea which patch is to blame; I just verified it on dapper and sid
<Keybuk> dpkg largely ignores versioned conflicts
<Keybuk> does it work in sarge?
<Diziet> Hello.  My ears are burning.
<pitti> Keybuk: I can try that; it's a bit hard (production system), but should work
<Keybuk> just grab the dpkg from sarge and install it
* desrt gives Diziet some sodium peroxide
<pitti> Hi Diziet 
<Keybuk> or from breezy, actually
<Keybuk> that's more up to date
<pitti> Keybuk: ah, good idea
<Diziet> What's all this about a `standard conffile moving recipe' ?  Is this some other hideous workaround for a dpkg bug ?
<Diziet> It's nearly always a mistake to mess with a conffile in a maintainer script.
<pitti> no, it's a hideous workaround for a hideous situation
<Diziet> What hideous situation ?  Conffiles should move from package to package just fine (assuming an appropriate Replaces, just like you need for any file movement).
<pitti> Diziet: moving a conffile to anouther package is not really something dpkg supports, so preinst/postinst have to make sure that it'll happen without dpkg conffile questions
<Keybuk> Diziet: that broke with the "obsolete" patch, afaict
<Diziet> Did it ?  Not in my tests.
<Diziet> If it broke we should fix it dammit.
<Keybuk> I've seen several bug reports with a conffile still being claimed by a later version of a package and causing an overwrite error with the package that Replaces it
<Diziet> If someone can produce a test case that doesn't involve maintscript fiddling then I'll fix it.
<pitti> Keybuk: ok, so I get the same breakage with breezy's dpkg
<Keybuk> pitti: then I don't understand your bug
<Keybuk> if package A has not got the conffile, and package B has it
<Keybuk> then you won't get that overwrite error
<pitti> well, I understand *part* of the bug
<Keybuk> so either you're lying, and both A and B have the file, or something else is going on
<Keybuk> dpkg: error processing /var/cache/apt/archives/postgresql-client-common_46_all.deb (--unpack):
<Keybuk>  trying to overwrite `/etc/postgresql-common/user_clusters', which is also in package postgresql-common
<Keybuk> that means that postgresql-common has that conffile
<Keybuk> and postgresql-client-common *does not* Replaces it
<pitti> Keybuk: version 44 of p-common has, but not 45+
<Diziet> Maybe I should volunteer to fix all of these kinds of bugs.
<Keybuk> ok, prove it; give me the Conffiles: bit from status :)
<Diziet> pitti: I think what Keybuk means is that dpkg thinks the package still has it even though the new .deb doesn't.
<pitti> right
<Diziet> Would you like me to fix this problem for you ?  I can do it tomorrow.  (No time left today - I have to go in 15m0
<pitti> so, my /v/l/dpkg/status still shows p-common Version 44
<Keybuk> Diziet: that shouldn't matter, postgresql-client-common Replaces it
<pitti> which of course has the file
<pitti> however, the file is not in the system any more (it was rm'ed)
<Diziet> Why was it rm'd ?
<pitti> Diziet: in p-client-common's preinst
<Diziet> Why, not what by.
<Diziet> I'm quite serious.  If you can tell me how to reproduce this bug I can fix it.
<pitti> Diziet: I'm still trying to understand whether it's entirely my fault, or partly mine and partly dpkg's
<pitti> so, let me explain step by step, unless I annoy you
<Diziet> Sure, that's fine.
<pitti> A := postgresql-common, B := postgresql-client-common
<pitti> A 44 has the conffile, A 45 and 46 not
<pitti> B Conflicts:/Replaces: A << 45
<pitti> (version 45 introduced the package split, and the conffile needs to move from A to B
<pitti> now, A 44 is installed, and I dist-upgrade to 46
<Diziet> You mean B 46 C/R A << 45 ?
<pitti> right
<pitti> so, this part of my bug is a bit clear: if A gets upgraded first, then the Replaces << 45 doesn't apply any more
<pitti> so what happens is:
<Diziet> Right.  And the conffile gets put into the weirdo orphan state.
<Diziet> That's what my patch was for.
<pitti> first, B's preinst removes the conffile, since it's unchanged
<Diziet> (I'm assuming your maintscripts don't do anything.)
<Diziet> Why?????
<Diziet> Why would you mess with a conffile in the preinst ?
<pitti> Diziet: it's part of the recipe
<Diziet> Where did you get this recipe ?
<pitti> Diziet: for the case that it has been modified
<pitti> Diziet: from www.dpkg.org
<pitti> Diziet: anyway, I think it doesn't really matter here
<desrt> hm.  the new dapper livecd format is much nicer
<pitti> so then dpkg tries to unpack A 46, but that fails due to the conflict
<pitti> although version 46 doesn't ship that conffile any more
<Diziet> I think dpkg is right here and your maintscript is wrong.
<Diziet> BICBW.
<Diziet> www.dpkg.org is down so I can't even add a note to the page saying `iwj hates this'.
<pitti> so, I see the combination of two different bugs/issues:
<Diziet> Have you tried it without any `recipies' in the maintscripts ?
<pitti> - dpkg still considers the conffile owned by A, even though the deb doesn't ship it; I know that there are reasons for that, though
<Diziet> A is removed but not purged at this point.
<pitti>  - my Replaces: is wrong, since it's versioned
<pitti> or, rather, it doesn't work here
<pitti> an unversioned replaces: works fine
<Diziet> Oh, I /see/.
<pitti> so, dpkg doesn't take into account that B replaces A << 45 if I upgrade A from 44 to 46
<pitti> I mean, I'm not against adding an unversioned Replaces:
<pitti> but it feels a bit ugly to me
<Diziet> No, you probably shouldn't do that.
<Diziet> I see the problem now.
<Diziet> I think this is indeed a dpkg bug.
<Burgwork> sabdfl, ping
<Diziet> I think the right answer is for orphan conffiles never to cause conflicts.
<lifeless> the sab is in deep discussion here
<Diziet> But I'll sleep on it and play with it tomorrow.
<Diziet> All of these .debs are in the Ubuntu archive ?  (Or were ?)
<pitti> Diziet: great; I can provide you with some minimal test debs if you need
<pitti> Diziet: Debian currently
<Diziet> Debian.  OK, NP.
<pitti> Diziet: they are tiny, I can send them to you if you want
<Diziet> Yes, please.
<pitti> Diziet: I can also strip them down to remove all the maintscripts stuff
<Diziet> No, no, I can do that.
<pitti> Diziet: ah, to answer this question:
<Diziet> But send me the `source' if it's not just dpkg -x :-).
<pitti> Diziet: if the conffile is modified, then we need the magic to avoid a dpkg conffile question
<Diziet> Yes, dpkg is supposed to do that.  That's what the orphan conffile thing is for.
<Diziet> (I can't remember whether that patch made it into breezy.  I suspect not.)
<pitti_> yay my network, sorry
<pitti_> <pitti> Diziet: otherwise, installing B on top of an orphaned modified conffile from A would trigger a question
<Diziet> Is the conffile shipped in B different from the one in A ?
<Diziet> Err.  To me `modified conffile' means one locally modified by the admin.
<Diziet> NB that removing it with `rm' (like in your preinst) counts as modifying it.
<pitti> Diziet: the default file didn't change
<pitti> Diziet: right, admin modified
<pitti> Diziet: but the recipe works just equally well if the file changed between A and B
<Diziet> Right.  Then the orphan conffile stuff is supposed to work.
<Diziet> As you can tell, I don't believe in this `recipe'.
<lifeless> if you need him urgently I can ping him, but if it can wait I suggest email
<lifeless> ing 
<Diziet> Anyway, I have to go or I'll be late for my dinner.
<Diziet> Mail me those files and if you say anything else here I'll see it tomorrow morning.  I'll look into it and write you up a diagnosis :-).
<ogra> seb128, ping
<pitti> Diziet: thanks a million
<pitti> and enjoy your dinner
<Diziet> pitti: NP, I enjoy this kind of thing really :-).  Willdo.  TTFN
<seb128> ogra: pong but I've to go for ~1.5 hour soon
<ogra> seb128, just a short question
<ogra> gdm depends on ubuntu-artwork, could you make that ubuntu-artwork | edubuntu-artwork ?
<seb128> sure
<ogra> i want to jget rid of the ubuntu-artwork package from the edubuntu Cd
<ogra> thanks :)
<seb128> np
<ogra> go !
<ogra> :)
<lamont> Keybuk: why on earth would anyone install recommends by default?  if the package needs it for operation, then it's a depends, not a recommends... :0)
<lamont> seb128: stupid question for you....
<lamont> my screen lock button doesn't work on dapper.
<ogra> lamont, do you have gnome-screensaver installed ? it works here 
<seb128> lamont: does the menu item work? or the session dialog button?
<lamont> mind you, historically, I had to pull up the screensaver preferences so that it would complain that the lock daemon was "not running and did I want to start it" before I could lock on breezy... so I think it might be session defaults
<lamont> seb128: either one
<lamont> applet button on the panel, and pull down menu item
<seb128> k, seems to be the screensaver not running
<lamont> ii  gnome-screensa 2.14.0-0ubuntu a screen saver and locker
<lamont> seb128: right
<seb128> deal with ogra about it :)
<seb128> I've to run for now
<lamont> and the new shiny dapper screensaver doesn't notice that it's not running...
<seb128> bbl
<lamont> seb128: np. thanks
<lamont> ogra: so what do I change where to cause gnome-screensaver to actually launch?
<lamont> (and no, "rm -rf .gnome*" is not an option.
<ogra> normally its started by default from the session ... 
<ogra> probably the gconf key isnt set ... let me find it
<lamont> ogra: it hasn't normally been started for my session since somewhere before breezy release... :-(
<ogra> lamont, look with gconf-editor if /apps/gnome_settings_daemon/screensaver/start_screensaver is true
<lamont> wee... X-over-ssh.
<ogra> gconftool-2 --get /apps/gnome_settings_daemon/screensaver/start_screensaver
<ogra> :)
* lamont chuckles at "gnome-screenshot" and "gnome_screenshot"
<lamont> false.
<ogra> ah
<lamont> I guess I want to set it to true, eh?
<ogra> thats it
<ogra> yup
<lamont> --set ... = true?
<ogra> it will default to gnome-screensaver if its installed 
<ogra> gconftool-2 --set /apps/gnome_settings_daemon/screensaver/start_screensaver --type bool true
<lamont> thanks
<tenco> is it possible to run beagled without the --debug option?
<_ion> Good morning.
<Lure> _ion: hi
<_ion> Hi
<Lure> _ion: have your read mbiebl (debian maintainer) response to NM annoncement on ubuntu-devel?
<neuralis> BenC: ping
<xhaker> does sources.list accept smb shares ?
<_ion> lure: Yep, i agree with him.
<neuralis> xhaker: not unless they're mounted. that's a question for #ubuntu, though.
<_ion> lure: I should have noticed the versioning stupidity in the libnl package i downloaded. :-\
<Lure> _ion: are you already working on that?
<Lure> _ion: I have checked mentioned svn, but I do not see that they rename applets :-(
<_ion> lure: I hadn't had time to work on that yet, but i will. I also guess pygi's going to help with that as soon as he gets online.
<Lure> _ion: btw, Tonio_ is also working on cleanup of packages - maybe check with him too
<_ion> Right, i'll /msg him.
<hunger> _ion: I think NM has trouble with /etc/network/interfaces.
<_ion> #define trouble \
<hunger> _ion: From what I understand it expects "inet dhcp" on a different line than "iface whatever".
<hunger> _ion: Unfortunately that is not possible as ifup/ifdown do not understand that syntax then.
<_ion> Hmm. I thought i tested the patch, but perhaps i was careless.
<_ion> I'll check it.
<hunger> _ion: If you have no auto whatever but a "iface whatever inet dhcp" then NM gets a dbus error...
<hunger> _ion: At least that seems to be the problem on my system. I removed the iface lines for now (no more ifup/ifdown), and NM works fine now.
<_ion> Ok. Thanks for the report.
<doko> dholbach, seb128, mvo: who's knowing the atk modules a bit?
<dholbach> doko: I doubt we have an expert for them :)
<dholbach> doko: what are you looking for?
<doko> dholbach: #35747
<dholbach> bug 35747
<Ubugtu> Malone bug 35747 in openoffice.org "OOo crashes with gnome accessability enabled" [Major,Unconfirmed]  http://launchpad.net/bugs/35747
<mvo> doko: it makes synaptic as well
<mvo> crash that is
<dholbach> same/similar backtrace?
<dholbach> mvo: ^
<mvo> dholbach: I look into it in a bit
<dholbach> mvo: thanks
<dholbach> doko: can you give it another try with libatk1.0-dbg libglib2.0-0-dbg libgtk2.0-0-dbg installed? is this most recent dapper? 
<dholbach> doko: libgail-dbg too
<Mez> wtf?
<Mez> dpkg is missing on my system ?
<LaserJock> that's not good
<Mez> sudo: dkpg: command not found
<Mez> oh, it's just not in my path
<Mez> it's there if i sudo -i
<xhaker> Mez: pre flight 3 install?
<Mez> xhaker, I've been using dapper since it was opened for uploads
<dholbach> Mez: dkpg -> dpkg
<Mez> dholbach, o_O how could i not notice that ;)
* dholbach confiscates Mez' crack-pipe ;)
<xhaker> Mez: libpam-something broke path for some people, if the error is not the typo it may be that
<Mez> dholbach, lol - nah - i've just woken up - tis probably why
<Treenaks> dholbach: alias dkpg=dpkg
<Treenaks> :P
<dholbach> Treenaks: I don't need it, thanks ;)
<Treenaks> Mez then
<LaserJock> or maybe dkpg=`echo "wake up!!!"`
<Treenaks> LaserJock: apt-get install sl
<ogra> LaserJock, add a bunch of \a to the echo :)
<_mvo_> is it normal that rsvg-convert from bootchart takes >800mb of my memory? and runs for ages?
<Treenaks> ogra: sl rocks, if you mistype 'ls' a lot
<ogra> heh
<LaserJock> Treenaks: interesting. and sometimes I wonder why Universe has so many packages ;-)
* _mvo_ removes bootchart and wonders why it was installed in the first place
<Treenaks> LaserJock: it's the Debian thing :)
<doko> dholbach: what further information do you expect from the trace back? It's some recursion, which apparently eats up the stack
<dholbach> doko: it'd be nice to have the arguments of the functions
<dholbach> doko: that was on i386, right?
<doko> dholbach: yes
<dholbach> brb
<zyga> did dholbach leave already?
<LaserJock> zyga: he said he would brb
<Amaranth> right before you joined
<zyga> oh, great :-)
<zyga> I keep missing the developers I know ever since I got my new job
<LaserJock> you'll just have to get to know some more developers so you can spread out the TZs ;-)
<zyga> hehe true :)
<zyga> dholbach: hello
<zyga> dholbach: did you get my message yesterday?
<dholbach> yep
<dholbach> zyga: could you follow up on the MOTU UVF exception bug for it?
<zyga> dholbach: yes but before I do I'd like to ask you about something
<zyga> I wanted to fix i18n bug that was basically missing ngettext but I ran into a problem I don't know how to solve
<dholbach> zyga: you should file a bug on ontv, the upstream developer will follow up, he reads those bugs too
<zyga> it basically reduces to the fact that I need a more generic ngettext that accepts a vector of msgid's and a vector of numbers to produce the correct result
<dholbach> zyga: if not, you can subscribe him as well (johan@svedberg.com)
<zyga> I already have an email for him with a diff and the description of my changes :-)
<zyga> I didn't know he reads ubuntu bug reports
<dholbach> yeah, he's great to work with
<dholbach> doko: it works for me :/
<dholbach> doko: nothing funny at all :/
<zyga> dholbach: what should I do with this ngettext problem? there is really no way to implement this correctly using current ngettext+gettext
<dholbach> zyga: I suppose you better talk to him... as he knows the code better than I do
<zyga> dholbach: does he come to irc, ever?
<doko> dholbach: even if you press some of the buttons in the help?
<dholbach> doko: yes, nothing funny at all
<doko> did you turn the speech on?
<dholbach> zyga: I think I met him on irc, but I can't remember his ircnick
<zyga> okay
<zyga> I'll mail him
<dholbach> cool
<doko> strange, because a user reported that as well ...
<zyga> dholbach: mail away, I'll get my patch up and running and look at UVF exception procedure
* _mvo_ goes for the evening
<Robot101> 20:34 <rlaager> Well, if I had a vmware-packager package that would take a vmware tarball and make a vmware-VERSION.deb out of it, do you think I could get said vmware-packager into Debian/Ubuntu?
<Burgwork> sabdfl, unping, dapper press release is what I was pinging you about
<dotwaffle> tsk, annoying the dictator with trivialities such as that, tsk!
<Burgwork> dotwaffle, actually I was offering to help write bits, etc.
<dotwaffle> ah right, excuse me =)
<Pygi> _ion: you there?
<_ion> pygi: Hi! Nice to see you.
<_ion> pygi: Did you see Michael Biebl's reply to the announcement at the u-devel list?
<Pygi> _ion: the one about debian, changin' names and such?
<_ion> pygi: Yep.
<Pygi> _ion: yup, I did ...
<Pygi> perhaps we should rebuild & rename packages
<sabdfl> gotcha, thanks Burgwork
<_ion> First we should fix the versioning stupidity in libnl (i wonder why i didn't notice it immediately...), and i also agree with renaming the packages to be similar.
<_ion> pygi: I sent you an email, btw.
<Pygi> _ion: k, will look into the mail now
<Pygi> _ion: you sure you sent to the right mail?
<dholbach> night guys
<Pygi> night dholbach
<Pygi> dholbach: ah, yes ... I saw the patch
<_ion> To: Mario ani <mario.danic@gmail.com>
<dholbach> Pygi: hm?
<Pygi> dholbach: you said night ... I said night as well ^_^
<Pygi> _ion: right,  it's that patch, isn't it?
<_ion> Yep.
<dholbach> "patch"?
<Pygi> dholbach: for n-m packages ^_^
<seb128> Pygi: I think <Pygi> dholbach: ah, yes ... I saw the patch was not for dholbach
<Kamion> BenC: FYI, you need to add nic-firmware to the various package-list files as well as adding nic-firmware files under debian/d-i/$ARCH/firmware/
<mjg59> BenC: Also, sky2 still seems to be missing from the nic modules udeb
<Kamion> BenC: (the nic-firmware binaries didn't actually get built for hppa/ia64/sparc)
<Pygi> seb128: you'r right  ^_^ wrong typing
<Kamion> yeah, that bug is still outstanding, keep getting reports of it ...
<_ion> pygi: Also the /etc/network/interfaces parsing seems to be somewhat buggy. I'll look at it.
<Pygi> _ion: k, I'll try to look at that background scanning in -ng
<BenC> Kamion: ok
<_ion> pygi: Do you agree with the patch i sent? I think cdbs is a superior build system, but if reverting back to the 0.5.1 build system makes it more probable that the package is accepted, we should do that.
<Pygi> _ion: yup, agreed
* Kamion NEWs the -19 kernel
<Kamion> will somebody do l-r-m and linux-meta? (note, in general you can upload l-r-m without waiting for the kernel to build, since it'll dep-wait; faster that way)
<Kamion> (linux-meta doesn't dep-wait at present, although infinity suggested hacking it about a bit to do so ...)
<_ion> pygi: Oh, the repository suddenly seems not to be signed anymore. :-(
<Pygi> _ion: yes, I do know that
<Pygi> _ion: it's because it was causing a lot of trouble ... we'll move to falcon someday perhaps ^_^ (Tonio_ is, that is ;) )
<Pygi> _ion: we will need new patched l-r-m packages as well, won't we?
<_ion> pygi: The new kernel doesn't seem to be out just yet.
<Pygi> _ion: yup, I know ...
<BenC> mjg59, Kamion: I think I have nic-firmware fixed, and sky2 added to shared/nic-modules
<Kamion> _ion: it's in the accepted queue, will be visible in a little over an hour; I didn't quite make it before the current publisher run
<_ion> Ok.
<Kamion> slomo_: any progress on that GPL exception for gtkpod-aac?
* _ion sips some cheap whiskey and gvims src/backends/NetworkManagerDebian.c
<mjg59> BenC: Rock, thanks
<slomo_> Kamion: nope... got no answer from the author yet... on the other side gtkpod-aac only links to libmp4 which shouldn't contain patented stuff as it's only for reading and writing the mp4 container format
<ivoks> tollef?
<tepsipakki> slomo, kamion: what's the issue with gtkpod-aac? (i'm the packager)
<Kamion> tepsipakki: it's GPL, but as I understand it it links to code that can't be distributed under the terms of the GPL
<Kamion> note the GPL's admonition that if you cannot abide by a patent licence while distributing under the terms of the GPL, then you may not distribute it at all
<Kamion> if there is no patent issue with stuff that gtkpod-aac links to, then that's fine, but then why is it in multiverse?
<tepsipakki> Kamion: d'oh
<Kamion> I assumed that if it was in multiverse, then there was a reason for it to be there
<slomo_> Kamion: libmp4 is in multiverse because it's source package (faad2) is in mutliverse
<Kamion> oh, but libmp4 itself is free?
<slomo_> Kamion: and faad2 also builds libfaad2 which could break some patents
<Kamion> sheesh, that's awkward
<Kamion> really libmp4 ought to be in universe then but that causes closure issues
<Kamion> ok, if libmp4 itself doesn't violate patents then I'll process gtkpod-aac binaries and stop bothering you+upstream :)
<slomo_> Kamion: should be free... i see no reason why anybody could patent such stuff... but as one can patent everything today i'm not sure
<tepsipakki> oh, by the way.. there's a new version of gtkpod, and it is only a bugfix release :)
<slomo_> Kamion: only libfaad2 contains definitely patented code
<lucas> what's the status of package removals ? who can process them currently ?
<whiprush> hey _ion I am about to post a story about the n-m packages, where are users supposed to report bugs?
<Kamion> lucas: I can. What's the problem?
<crimsun> Kamion: please remove flashplayer-mozilla, as it contains a binary of the plugin (illegal distribution), and it is obsoleted by flashplugin-nonfree
<_ion> whiprush: For example by email (debian % johan,kiviniemi,name) or on IRC (_ion at Freenode or Pygi at Freenode). We don't have anything more sophisticated.
<whiprush> ok
<whiprush> that thread ok also?
<Seveas> (*#&^$&*#$(@*& madwifi HATEHATEHATE
<Pygi> _ion: what I did this time? ;)
<_ion> whiprush: Yes, i follow it.
<whiprush> ok
<_ion> pygi: :-)
<Pygi> _ion: thread? what one?
<_ion> pygi: The ubuntuforums thread.
<Seveas> Pygi, _ion: I will no longer test NM: madwifi is giving me the creeps. Sorry.
<Pygi> Seveas: yup, agreed ... I am looking into helping you
<Pygi> Seveas: I'll maybe give it a shoot at porting -ng background scanning to -old
<Seveas> and my office network (802.1x EAP/TTLS +wep) won't work with NM, already sent a mail to the NM list
<_ion> pygi: Actually there seems to be two threads about the package now. :-)
<Pygi> _ion: yup, I saw ;)
<lucas> Kamion: could you please remove ruby-gnuplot and sync libgnuplot-ruby (which is in Debian, but not in Ubuntu yet) ?
<Lure> _ion: yes, there are two - I have linked to both in wiki
<lucas> ruby-gnuplot is uninstallable and very old, while libgnuplot-ruby is the most recent version of the same lib.
<lucas> (ruby-gnuplot was a apt-get.org package)
<Kamion> crimsun: done
<crimsun> Kamion: thanks!
<Kamion> lucas: I can't do syncs (yet); are you sure you still want me to do the removal?
<lucas> yes, remove it anyway. If I upload libgnuplot-ruby with *build1, are chances high that it will be approved some day ? :-)
<lucas> (it will have to go through NEW)
<LaserJock> Kamion: yeah, I'd like to get ruby-gnuplot removed. It isn't useful in its current state
<Kamion> lucas: NEW is a whole six items long right now
<lucas> I'll take my chances I think
<Kamion> lucas: ruby-gnuplot removed
<lucas> thx
<LaserJock> Kamion: ahh, thanks. That has been bugging me for a while ;-)
<_ion> pygi: I'll update this file every once in a while. http://johan.kiviniemi.name/ubuntu/nm-bugs
<Pygi> _ion: agreed
<Pygi> _ion: I really hope we'll be able to port from -ng to -old
<Pygi> otherwise, it's all a mess, big mess
<_ion> Yep.
* sivang_ searches for any awake muse users
<Seveas> sivang_, I regularly listen to muse 
<sivang_> Seveas: heh :)
<_ion> Muse the sequencer?
<sivang_> nahh, muse my host which I do irc from. It doesn't let me connect anymore.
<_ion> I tested it a long time ago, but i have a hw sequencer. :-)
<sivang_> has anyone seen sladen ?
<_ion> Oh.
<sivang_> or daf
<sivang_> ?
<sivang_> _ion: you're sequencing on linux?
<_ion> sivang: I prefer not to use a computer at all for making music. I have a hardware sequencer.
* Pygi rampages because of slow computer :-/
<joelbryan> digital signals sucks for music, the best is vacuum tube amplifiers.
<_ion> joelbryan: Amen to that.
<joelbryan> there's nothing compare to analog music
<joelbryan> vacuum tube amp + 90dB speakers = euphoria
<_ion> Sigh, seems like i can't concentrate at all today.
<_ion> I'll look at that interfaces bug later.
<Gwynn> joelbryan: mount the speakers (slabs of paper you wag around) into marble slabs, resonance of the boxes = bad, remove all furniture, for starters
* Gwynn is sorry, and will shut up again
<HrdwrBoB> Then blind yourself because seeing will corrupt your hearing
<_ion> Furniture is good, it removes echo. :-)
<HrdwrBoB> _ion: not if you have a custom built listening room
<HrdwrBoB> .. anyway, wildly OT
<_ion> How many of us have a custom built listening room? ;-)
<_ion> (I wouldn't mind one for sure. )
<Gwynn> furniture = bad, 90 degrees angles = bad, curtains = good, cover the walls with curtains
* Gwynn is really, really sorry, and will shut up again
<sladen> sivang_: I got a message from jonathan about 10minutes ago that something is "up" with muse
<sivang_> sladen: yeah, for me as well. I see my nick sivang up which is irssi running on muse under screen, but I get connection refused port 22 when trying to connect there.
<sivang_> sladen: I'm currently using another host to irc
* sivang_ wonders as muse didn't have a single glitch since I started using it about 1.5 years ago. impressive record
<sladen> sivang_: try that.  Thanks to the wonders of virtual machines, I've just restarted sshd
<sivang_> sladen: virtual machine? is it a virtual machine? :)
<sivang_> yay!
<sivang_> works
<sladen> sivang_: abstraction machines from the hardware is wonderful thing.
<sladen> abstracting...
<sivang> I see
<sivang> sladen: what are you  using there to do that? is it somekind of blades clustering?
<HrdwrBoB> sladen: well.. out of band access is a wonderful thing
<joelbryan> bug #34886
<Ubugtu> Malone bug 34886 in Ubuntu "displays too many drives" [Normal,Unconfirmed]  http://launchpad.net/bugs/34886
<trappist> fabbione: thanks for /etc/rc.local!
* sivang got his muse back and goes on hacking ;-)
<sladen> sivang: vserver
<joelbryan> #28447
<sivang> sladen: VMWare / Xen ?
<joelbryan> bug #28447
<Ubugtu> Malone bug 28447 in sysvinit initscripts "[PATCH]  two simple errors in /etc/init.d/mountall.sh" [Normal,Fix released]  http://launchpad.net/bugs/28447
<sladen> sivang: no.  "vserver"
<sladen> joelbryan: are you randomly pasting numbers in the channel?
<sivang> sladen: ah, I see now. a nice debian based project.
<Kamion> sivang: did you ever see my comment about your breezy-updates culmus upload being incorrect?
<sivang> Kamion: no, sorry. WHat had gone wrong there? 
<Kamion> sivang: this is the breezy->dapper diff:
<Kamion> -FONTDIR=$(DEB_DIR)/usr/X11R6/lib/X11/fonts/Type1
<Kamion> +FONTDIR=$(DEB_DIR)/usr/share/X11/fonts/Type1
<Kamion> sivang: this is the breezy->breezy-updates diff:
<Kamion> -FONTDIR=$(DEB_DIR)/usr/X11R6/lib/X11/fonts/Type1
<Kamion> +FONTDIR=$(DEB_DIR)/usr/share/X11/fonts/
<Kamion> you have a missing Type1 in the change for breezy-updates
<sivang> yes, I see that now. sorry, I wonder how I overlooked that. Would you like me to prepare updated source diff?
<Kamion> sivang: yes please, just upload it when you're ready
<Kamion> I'll reject -2ubuntu1
<Kamion> you should probably upload the fix as -2ubuntu2
<sivang> (I acutally tested both of them on repsective systems, and didn't see the fonts missing)
<sivang> Kamion: okay, will do.
<sivang> Kamion: have you noticed that only, or has people filed reports about their fonts not working?
<Kamion> I noticed it when reviewing the diff for -updates
<sivang> Kamion: okay, thanks alot, I just feared it already went in the repo.
<Kamion> no, breezy-updates uploads are manually approved
<Kamion> I was going through the queue
<jvw> hrmz, someone should get Mark Shuttleworth to reply to the fake mail sent to debian-devel minutes ago, I guess...
<azeem> I don't think that's needed
#ubuntu-devel 2006-03-26
<jvw> most people will understand/see, I guess (language errors, IP in the US, hotmail address, ...), but certainly some won't
<azeem> that would just give the impression you can get him to comment on things if you troll/fake enough
<jvw> nvm the actual content of course
<jvw> azeem: hrmz, yeah, well, that's true too. Anyway, Mark is prefectly capable of dealing with this himself, so, well.
<Kamion> if you want him to see it, you'd need to e-mail him about it
<Kamion> but I imagine having, well, just about anyone reasonably well-known in Debian/Ubuntu follow up saying "this wasn't Mark, please don't feed the troll" would do fine
<LaserJock> jvw: what email is this?
<sto> LaserJock: http://lists.debian.org/debian-devel/2006/03/msg00894.html
<Kamion> errors> also, er, people generally spell their own names right
<sivang> Kamion: http://muse.19inch.net/~sivan/culmus/breezy-updates/
<Kamion> sivang: it's difficult for me to review it until it actually lands in the queue
<Kamion> sivang: but get somebody to upload it and I'll happily do so
<Kamion> you should keep the changelog entry from the previous upload
<Kamion> have -2ubuntu2 describe the delta from -2ubuntu1 to -2ubuntu2, and upload with -v0.101-2 so that both changelog entries are visible in the .changes file (and thus on breezy-changes)
<Kamion> s/upload/build/
<Kamion> troll posting> followed up with a hopefully-preemptive don't-feed-the-troll
<sivang> Kamion: -v is passed to dput or debuild?
<sivang> ah, debuild
<Kamion> yes, although your sponsor will have to do that too
<Kamion> assuming they don't just sign your source package verbatim, which they shouldn't
<sivang> I'll prepare a detailed email for pitti on that together with metnionting to him the -vVER thingy, but tomorrow. getting too much close to bed time here. thanks for the tips, I'll make sure this won't get rejected this time :)
<Lathiat> do we still need to fakesync stuff from debian?
<Kamion> Lathiat: yes, syncs aren't working yet
<Lathiat> Kamion: cheers
<elkbuntu> is there any reason why apt-get and update-manager are not getting quite the same stuff?
<Amaranth> mjg59: btw, it appears my problem is bug 31543
<Ubugtu> Malone bug 31543 in xserver-xgl "Xgl not working on ppc" [Normal,Confirmed]  http://launchpad.net/bugs/31543
<mjg59> amOk
<mjg59> Nngh.
<mjg59> jdub: Ping?
<mjg59> jdub: What's the situation on new usplash artwork?
<Amaranth> mjg59: the invalid read errors in my xorg log (seem to be related to this) are supposedly fixed in suse
<joelbryan> The Ubuntu Welcome Page is using XHTML Transitional, just wondering if you would plan to make it strict?
<Burgwork> joelbryan, welcome page? ubuntu.com ?
<joelbryan> no
<joelbryan> the one that loads when you start firefox
<Burgwork> joelbryan, ah, you need to talk to someone in #ubuntu-doc
<joelbryan> ok
<setuid> I've pulled the kernel source package, and I'm trying to build ibm_acpi with some patches... how do I do this? (normally I'd do 'make modules SUBDIRS=drivers/acpi', but that doesn't work with Ubuntu kernel source packages) 
<jdub> infinity: did we get that Xorg update?
<jdub> oh, i guess it's not quite so critical for us, as our Xorg is not suid
<infinity> Which update?
<jdub> infinity: http://blogs.sun.com/roller/page/alanc?entry=security_hole_in_xorg_6
<infinity> And is ours really not suid?
<infinity> Hrm.  Doesn't seem to be in dapper...
<infinity> I wonder if startx even works in dapper, then.
<jdub> it wouldn't, no
<Lathiat> no, it doesnt
<jdub> but that is good :-)
<Lathiat> i noticed that
<Lathiat> which is bad..
<jdub> (it could tell you why, though)
<infinity> Surely we're suid root in warty/hoary/breezy...
<jdub> i think it was fixed for breezy
<infinity> The lack of suid in dapper is a packaging error, I'm sure, not a conscious decision.
<jdub> though i don't have any breezy boxes anymore
<jdub> ask pitti. he is fierce. :-)
<infinity> Oh, nice bug.
<nictuku> who cares about parenthesis anyway
<Lathiat> so you see, ruby wouldn't have this problem, parenthesis optional :)
<Lathiat> they should rewrite Xorg in ruby
<LaserJock> :/
<predius_> same 
<predius_> err
<predius_> wrong
<maswan> jdub: I have a +s X, but not Xorg, on my upgraded-to-breezy laptop, FYI
<infinity> Oh, duh.  It's +s on dapper, too, I was looking at the wrong binary.  Thanks maswan. :)
<infinity> (/usr/bin/X being a wrapper around /usr/bin/Xorg)
<infinity> In which case, startx should work on dapper... At least, it should work on my machine..
<nictuku> then the bug is an issue
<fabbione> hmmmm
<fabbione> infinity: should i take care of that X security hole?
<fabbione> well THAT.. there are probably one per line..
<fabbione> but at least that one..
<infinity> You going to upload for all 4 dists?
<fabbione> hmmmm
<fabbione> let's wait pitti
<infinity> I was about to start on it, but if you want to be the X man today. :)
<fabbione> no no
<fabbione> i will keep going on dapper bug list
<fabbione> i want to get down to 160/150 today
<na7e> hi fabbione and infinity 
<infinity> Okay, you keep attacking dapper, I'm happy to do the security updates.
<fabbione> infinity: ok
* fabbione shows his metal fingers around
* infinity notices hppa security builds still trickling in on jackass...
<infinity> Go lamont!
<fabbione> LOL
<fabbione> infinity: speaking of -security.. what about vivies?
<infinity> vivies and I need to sit down and have a chat about security soon, yes.
<fabbione> infinity: we could just get g-p-m fixed and get LiveCD out
<infinity> And we'll chat about livecds too.
<fabbione> good idea :)
<infinity> Neither is much effort, I'm just hunting desperately for tuits of the correct shape and size.
<infinity> SCC tuits!
* na7e wishes he knew half of what you're talking about
<nictuku> probably about a consert of something
<infinity> Oh, neat, the advisory claims 6.8.2 and earlier don't have the bug.
<jdub> infinity: oh, suck
* infinity will double-check this, but we could be safe.
<fabbione> hmm
<jdub> (re: X vs. Xorg)
<fabbione> new xorg-server version or just the fix?
* infinity grabs all our old source right now to check.
* fabbione ponders
<infinity> The fix is two characters.
<fabbione> infinity: yeah i know that
<infinity> Oh, 4 characters, it's in two parts of the code. :)
<fabbione> infinity: i am considering 1.0.2 or just the patch..
<fabbione> it's a hard choise
<infinity> 1.0.2 may make up ABI incompatible with some drivers, if we're really unlucky.
<infinity> (which would make a great excuse to update all the drivers!)
* fabbione takes a look at the diff
<fabbione> going for 1.0.2 is totally harmless
<fabbione> there are 2/3 bug fixes.. one of which is the security and the other one is the sparc i already did in 1.0.1
<infinity> Alright, then that'd be the way to go.
<fabbione> yea me too
<infinity> And don't forget to mention the CVE in the changelog.
<infinity> Or pitti will hurt you. :)
<fabbione> i know
<fabbione> nah
<_ion> hunger: I couldn't repeat the interfaces bug you reported.
<fabbione> infinity: i am going to upload 1.0.1 for now and prepare 1.0.2 for Kamion and mdz..
<fabbione> infinity: it's a no brain anyway
<_ion> hunger: n-m seems to parse interfaces correcty, and i didn't get a d-bus error when i tried many combinations for eth0 settings (with auto, without auto, dhcp, static).
<infinity> fabbione: Okay, panic averted, the bug definitely only exists in dapper.
* infinity deltes all those source trees and carries on with his day.
<ajmitch> great, grub hates me now - looks like the install was not a success 
<fabbione> infinity: ehheeh ok.. i have already fixed dapper.. and i have 1.0.2 almost ready
<fabbione> mdz: you still around?
<mdz> fabbione: barely
<infinity> If you're still in London, you really shouldn't be..
<fabbione> mdz: ok nothing urgent.. it can wait when you are back
<infinity> (shouldn't be around, that is)
<mdz> I'm not; I'm at home
<fabbione> mdz: otherwise it would be nice to have an UVF exception for xorg-server
<infinity> mdz: Oh, phew.
<fabbione> mdz: the only diff from our code and upstream is one bug fix (3 lines)
<fabbione> mdz: but it will allow us to drop 5 local patches
<fabbione> mdz: that are of course upstream..
<mdz> fabbione: sounds fine
<fabbione> mdz: ok.. i will upload after finishing the tests..
<fabbione> mdz: thanks
<mdz> fabbione: how is the bug list for X?
<fabbione> mdz: yesterday i killed 17 bugs.. i started from A and going down to Z
<fabbione> mdz: if malone doesn't lie to me, we had 200 bugs..
<mdz> fabbione: so almost 10% smaller then ;-)
<fabbione> mdz: yeps :)
<fabbione> mdz: these were all stupid bugs.. but i needed to warm up my X knowledge again..
* fabbione streches his wings on X again...
<fabbione> who feels lucky today???
<fabbione> http://people.ubuntu.com/~fabbione/xcrack/
<fabbione> please test ASAP
<fabbione> or be silent forever
<lamont> infinity: the issue is that bld-4 can only build them after they publish, not before
<lamont> infinity: and avahi, koffice are known b0rked, and the rest of kde is d-w libarts1, which is ftbfs (ICE).
<lamont> gcc-3.4 might build if I give it back, or it might just ICE again
<Lathiat> avahi is known b0rked ?
<fabbione> Lathiat: on hppa
<Lathiat> ah
<Lathiat> got a build log?
<fabbione> on LP?
<Lathiat> Status:
<Lathiat> Successfully built
<Lathiat> ?
<Lathiat> doesnt actually work?
<infinity> Lathiat: He may be referring to breezy/breezy-security.
<fabbione> xorg-server 1.0.2 looks good...
<ajmitch> doko: what are we going to do with zope2.x now that various python2.3 bits are missing?
<ajmitch> I know it's in universe, but it's rather useful to have :)
* infinity wonders why he can't right-click on an ISO to have it pmounted automagically in /media ...
<infinity> That would be kinda spiffy.
<_ion> infinity: Install the "Manage Actions" thingy for nautilus.
<_ion> infinity: I haven't created such a menu item, but i do have a "Play as a DVD" item for ISO images.
<_ion> It runs mplayer -dvd-device foo.iso dvd://
<neuralis> infinity: hey. until i manage to grab ahold of benc, do you perchance now the rationale behind the HZ=100 setting for the server kernel?
<neuralis> s/now/know/
<infinity> neuralis: Because it's good and pure and true?
<infinity> neuralis: Lower HZ == less responsive, but faster machine.
<_ion> 100 is also a nice, round number, just like 256.
<infinity> neuralis: For a "server-only" machine, that's the upstream recommended value.
<neuralis> infinity: i'm aware of the O/S theory behind the number, but i also seem to recall a metric poopton of synchronization troubles on linux SMP machines running at HZ=100
<neuralis> infinity: did that get cleared up?
<infinity> neuralis: For shared-task machines, they recommend 250 (we don't ship a kernel with 250, I don't think), and for desktops, something ridiculously high, like 1000 (which we ship)
<infinity> neuralis: I'm aware of no such poopton, but you may want to ask BenC. :)
<neuralis> infinity: yeah, okay. i can't remember when i saw that, so it's possible it was a few years back.
<pitti> Good morning
<ajmitch> morning pitti 
<_ion> 'ning.
<Burgundavia> morning
<Burgundavia> pitti: the new wastebasket icon is part of ubuntu-artwork, no?
<pitti> Burgundavia: no idea TBH
<infinity> pitti: Can pmount do loopback devices?
<infinity> pitti: So I could hack up a cute nautilus action that would allow me to right-click an ISO and mount it to /media/loopX ?
<pitti> infinity: not right now, that's a long-standing wishlist item
<infinity> pitti: Obviously, we'd need some smart defaults to prevent us from, say, mounting an ext3 image loopback with root-owned suid files on it, or something equally bad, but I assume you already have that safety in place for removeable devices with the same scary.
<infinity> In fact, pretend I didn't just mention that, obviously that's already adressed (I hope)
<infinity> pitti: The loopback thing wouldn't be too tough to sort, I suspect.
<pitti> infinity: yes, you can't disable nosuid and nodev in pmount :)
<infinity> pitti: Oh, and BTW, if you have scary stuff in your INBOX about X vulns, I just triple-checked that warty/hoary/breezy aren't vulnerable, and Fabio uploaded for dapper.
<pitti> infinity: I didn't think about mounting loopback devices directly, but pmounting iso images should be easy
<pitti> infinity: I know about X, I planned to fix it today; it's just dapper
<infinity> Yeah, so I saw.  It's fixed now. :)
<fabbione> pitti: we already di
<fabbione> +d
<fabbione> pitti: you need to start to work at "real man" TZ
<pitti> oh, great, thanks guys
<fabbione> or you will always be left out ;)
<fabbione> pitti: since we did spare you the X issue.. could you please reallocate that time for git-core?
<pitti> fabbione: yes, sorry, I forgot
<infinity> Is that the same git-core that causes the hppa buildds to spin incessantly until the build gets killed? :/
<infinity> (seems happy on other arches though, so whatever, I'll investigate later)
<woodwizzle> Hello
<woodwizzle> I'm planning on creating my own distro based on ubuntu
<woodwizzle> liveCD particularly
<elkbuntu> woodwizzle, the guys in here probably a bit too busy for this stuff, did you try #ubuntu-motd?
<infinity> s/d/u/
<woodwizzle> nope, that'll be my next stop, thanks
<neuralis> woodwizzle: he means #ubuntu-motu
<elkbuntu> gah, she and yes
<woodwizzle> I'm just looking for some basic info to get me started, I've never done anything like it before and dunno where to begin
<elkbuntu> those two abbr are too similar :P
<neuralis> elkbuntu: oh, sorry. she :)
<elkbuntu> no prob
<elkbuntu> while people are responding. apt-get result is far different to the update-notifier result. i'm using the mvo (??) version of the notifier i think. someone in here told me to use it instead a few days ago
<mdke> joelbryan, ping
<mdke> elkbuntu, the update-manager doesn't include packages which are upgraded when you do a dist-upgrade. Is that what you mean?
<elkbuntu> mdke doing fresh screenshots now
<elkbuntu> i did some earlier, but theres alot more pacakages listed now
<elkbuntu> and no, a plain upgrade
<elkbuntu> the update manager is doing more than apt-get upgrade
<mdke> how odd
<elkbuntu> or, wanting to
<mdke> you have a custom version of update-manager?
<elkbuntu> mdke, uh, one done by mvo or something like that
<mdke> elkbuntu, all the ones are done by mvo
<elkbuntu> well that makes it hard then
<mdke> you installed one yourself?
<mdke> what version?
<elkbuntu> i came in here a few days ago to ask why both gnome and x screensaver were both installed, and someone told me i wasnt using the right update-manager since it hadnt removed xscreensaver
<mdke> the answer is likely to be that you have been running dapper for some time :)
<mdke> I don't think one gets removed automatically.
<elkbuntu> mdke not really, i apt-get dist-upgraded this install about a month ago
<elkbuntu> anyway 'apt-cache policy update-manager':
<elkbuntu>   Installed: 0.42.2ubuntu8 Candidate: 0.42.2ubuntu8
<mdke> that's the same one I have
<infinity> elkbuntu: The update manager will do "upgrade + new packages", while apt-get upgrade does "only upgrade, if nothing is added or removed"
<mdke> file a bug then, I suppose
<mdke> aha
<elkbuntu> infinity, apt-get is holding stuff back
<infinity> elkbuntu: That's intentional, so we can pull in kernel upgrades (which require new packages) with update-manager.
<infinity> elkbuntu: Yes, read what I said again.
* mdke learns something new
<infinity> elkbuntu: "apt-get upgrade" won't change anything (add/remove packages), it will only upgrade packages.
<infinity> elkbuntu: "apt-get dist-upgrade" will violently add and remove packages to try to upgrade you.
<elkbuntu> so update-manager runs dist-upgrade, not upgrade?
<infinity> elkbuntu: update-manager is halfway between (it will only add packages, never remove)
<elkbuntu> oooh
<elkbuntu> i prefer to use apt-get, since it's a zillion times quicker
<elkbuntu> is there not an apt-get version of 'halfway inbetween'?
<infinity> Then you get to either dist-upgrade and carefully read the output to make sure it's not breaking something, or do upgrade, then manually "apt-get install" each package it's holding back to see why.
<infinity> No, apt-get doesn't have the "add only" option.  (other than the advice I just gave)
<elkbuntu> hmmm... if there's no known explosive issues i guess i'll dist-upgrade :P
<mdke> they are kept back for a reason generally, I think
<infinity> If dist-upgrade isn't threatening to remove anything starting with ubuntu- (ubuntu-minimal, ubuntu-desktop, etc), you're probably fine.
<elkbuntu> mdke i pity the poor person dist-upgrading from breezy at this very minute then :)
<_ion> The reason was just given a few lines above. :-)
<infinity> mdke: kept back package are only kept back because upgrading them will force the removal of something else.  This isn't necessarily a bad thing (in fact, we do it on purpose a lot), it's just stressful for people who are trying to figure out why. :)
<mdke> ah
<infinity> mvo's cute little dist-upgrader tool is meant to take some of the mystery out of this for people going from breezy->dapper who aren't terribly CLI-friendly.
<mdke> I thought some packages are kept back on purpose because they are known to break things
<elkbuntu> mdke, i guess it's about 'potential'
<elkbuntu> anyway, i'll let youse know in a while if it explodes me ;)
<elkbuntu> btw, one other thing.. who broke amarok's xine engine *cries*
<_ion> Hmm. I googled and found this  is this in breezy? http://people.ubuntulinux.org/~mvo/dist-upgrader/dist-upgrade.png
<infinity> _ion: It will be in breezy-updates yes, that's the point.
<_ion> Very nice.
<infinity> _ion: We'll recommend people install it to do their dist-upgrade.
<mdke> that should be added to the releasenotes I suppose
<elkbuntu> speak of the devil
<pitti> hi mvo
<mvo> hey pitti
<_ion> There's a stomach where wrestling happens.
(BenC/#ubuntu-devel) ide-generic is actually causing immediate problems, and the "bus type" thing is just a hack
(Kamion/#ubuntu-devel) and is there any other safe way to fix that hardware?
(mdz/#ubuntu-devel) BenC: what problems?
(BenC/#ubuntu-devel) mdz: problem where SATA isn't detecting fast enough, so ide-generic gets loaded and your SATA controller is suddenly a legacy IDE controller
<BenC> Kamion: not so much a regression as it is that it's much more common
<Kamion> can we do the 10-second thing (although I thought we did it already) and *not* do UUID?
<BenC> that coupled with the fact that we need UUID support in order to make the change from IDE to SATA/PATA drivers next release
<mdz> where does UUID enter  into it?
<Kamion> BenC: we have to cope with migration from breezy anyway, doesn't much matter whether we do that in dapper
<mdz> we made an explicit decision way back at UBZ not to do rely on UUID by default for dapper
<BenC> switching IDE to PATA requires us to do UUID atleast one release before
<mjg59> BenC: No, since we can't enforce UUIDs on upgrades
<jdub> highvoltage: ping
<Kamion> but breezy->dapper upgrades wouldn't switch fstab/grub menu.lst etc.
<mdz> BenC: how so?  I don't see why we couldn't make that change on upgrade
<BenC> ok, UUID makes it _simpler_
<mjg59> Or, if we /can/ enforce that on upgrades, we can do it on upgrade anyway
<Kamion> mjg59: right
<Mithrandir> I'm thinking of an evil hack.
<mdz> mounting root by UUID by default is a completely appropriate dapper+1 feature
<mdz> trivial to switch on early, plenty of time to sort it out, dapper waiting in the wings if it turns out to be chancy
<BenC> UUID is the minor issue here, the ide-generic delay is the major one
<Mithrandir> we could encode the uuid of the current root fs in the initrd and fall back to that if / doesn't appear.
<Kamion> I've got no objection to changing initramfs-tools for that at this stage
<BenC> Mithrandir: there's a sweet idea
<mjg59> BenC: I think we should fix that in any case. It's initramfs-tools that needs fixing - who's working on that right now?
<Kamion> if we get it wrong, it'll be noticed quickly, and it's fixable on upgrades
<Mithrandir> it's a hack, but it'd probably save our backside, wouldn't it?
<Kamion> installer bugs take much much longer for people to notice
<BenC> infinity is the culprit :)
<BenC> ok, so initramfs-tools, record UUID in image, check it if / doesn't appear, if neither shows up, delay 10 seconds, load ide-generic and repeat with current delay (30 seconds?)
<BenC> that sound good?
<Kamion> also, for the IDE->PATA upgrade, I'd actually prefer if dapper didn't do UUIDs so that the upgrade issues from installations made using breezy or earlier were right in our face rather than being hidden
<BenC> Kamion: good point
<Kamion> (since I doubt we have time to get the upgrades right for all boot loaders etc. at this point)
<Mithrandir> Kamion: didn't do, as in, didn't fall back?
<highvoltage> jdub: pong
<Kamion> Mithrandir: no, I mean didn't mount root by UUID by default in the simple way
<Mithrandir> Kamion: or are you talking about what's put on the kernel command line?
<Kamion> not referring to your hack
<Kamion> command line
<Mithrandir> Kamion: sure, so not changing the current state, which is to do it for stuff we see is on removable devices in the installer, but nothing else.
<jdub> highvoltage: hey - mind if i copy those cake images onto the fridge? don't want to punish your server by deep linking to them.
<highvoltage> jdub: i won't mind at all, those images are hosted on some server in the UK with lots of bandwidth :)
<Kamion> Mithrandir: BTW, did you see my casper merge request?
<jdub> wow
<jdub> http://fridge.ubuntu.com/node/300
<jdub> 300th post :)
<Mithrandir> Kamion: yes, sorry, I never got around to it.  What's the URL again?
<Kamion> 15:14 < Kamion> Mithrandir: please merge http://people.ubuntu.com/~cjwatson/bzr/casper/espresso-passwd/ - fixes wrong defaults on espresso's user/password screen
<maswan> hmm..
* maswan ponders
<highvoltage> jdub: congrats :)
<maswan> only debian cakes so far, should perhaps adjust that. :)
<Mithrandir> Kamion: oh, looks good.
* Mithrandir wants tags in bzr.
<Mithrandir> Kamion: uploaded
<torkel> maswan: You know what we expect from you when Sarek is upgraded :-)
<seb128> what is the "standard" file to use to set an environment variable your session?
<maswan> torkel: :)
<neuralis> Mithrandir: someone's working on updating the tags patch for bzr 0.8, iirc.
<seb128> there is a bug on gnome-session than ~/.bashrc is not used by GNOME, it's not supposed to be, right?
<Mithrandir> seb128: it's not.  Why should it?
<Amaranth> heh, the forums folks are freaking out about the 2.6.16 kernel
<Amaranth> "16 is one higher than 15, it must be better! we have to have this!"
<Mithrandir> seb128: gnome has .gnomerc, doesn't it?
<seb128> Mithrandir: for no reason, but I want to point the guy to what to edit 
<Seveas> Amaranth, typical for the forums 
<seb128> Mithrandir: yeah, gnome-session source ~/.gnomerc
<highvoltage> jdub: lol! nice entry. thanks :)
<seb128> Mithrandir: but is there a ~/.environment or something used by xorg whatever desktop you use?
<seb128> Mithrandir: or you have to use /etc/environment? :)
<jdub> mdke: i wonder if your fascist proxy would block 'cocksmoking'
<jdub> i don't think i've said that in my blog yet
<Mithrandir> seb128: ~/.pam_environment, yes.
<jdub> nup
<jdub> it's probably due
<Treenaks> jdub: There is such a thing as "Too much Lugradio"
<jdub> do they say cocksmoking?
<Amaranth> probably
<jdub> i should get a podcast client
* Amaranth too
<jdub> and a portable music player
<Treenaks> jdub: planet works great for me :)
<seb128> Mithrandir: ok, thank you
<Treenaks> planet + wget = all the podcasting I need :)
<jdub> planet doesn't suck down enclosures
<jdub> heh
<Mithrandir> Kamion: ok, people.ubuntu.com/~tfheen/bzr/espresso/trunk/ should be mergeable now.  Note that I need to do two uploads before it's actually installable, though.
<Kamion> Mithrandir: ok, I'm going out to pick Benedict up from school in a moment so you have some time :)
<neuralis> jdub: let me know if you find a podcast client that doesn't suck. 
<Kamion> thanks
<jdub> does rhythmbox suck?
<neuralis> jdub: the podcast support there is pretty young, i haven't gotten around to trying it
<Amaranth> banshee needs podcast support :/
<Mithrandir> Kamion: ok, all uploaded, please new espresso-kbd-chooser and I hope I didn't break anything.
<lbm> mvo: ping
<mvo> lbm: hello
<lbm> mvo: can i msg you?
<highvoltage> jdub: i quit like beep-media-player, although it's not for everyone
<jsgotangco> mvo: hi!
<jdub> highvoltage: it does podcasting now?!
<highvoltage> jdub: oops, missed that part.. erm... no :)
<jsgotangco> heh
<jsgotangco> rhythmbox is pretty solid on that part
<mvo> jsgotangco: hello!
<mvo> lbm: sure
<jsgotangco> mvo: have you given thought on glatzor's mail about the naming conventions?
<mvo> jsgotangco: not, not yet. sorry. I was away the last two weeks and hadn't had time to think about this
<jsgotangco> mvo: same here catching up on emails actually
<mvo> :)
<jsgotangco> GAIM for chat? heh
<spacey> is their some meta package with debug symbols? I want to do a backtrace on epiphany but no idea which debug symbol package i should get
<BenC> Kamion, mdz, mjg59, Mithrandir: Sent a copy of the UUID/ide-generic discussion to u-d-a
<psusi> why does mounting by uuid depend on ide-generic?
<Kamion> psusi: that's a bit of a garbling of the discussion ...
* netjoined: irc.freenode.net -> brown.freenode.net
<Kamion> Mithrandir: you uploaded kbd-chooser to unstable by mistake
<psusi> so the gist of it is that you don't want to load ide-generic until you are sure you have tried all other drivers, but you have no way to know for sure that all the other drivers have given up?
<mjg59> psusi: You don't for sure
<psusi> and this is because the pci ide drivers load and probe for drives asycnrhonously, and have no method of signaling that they have completed their probe?
<Kamion> psusi: that's more SCSI
<Kamion> you load the driver, and at some later point the drive says "oh yeah, hi, I'm here"
<psusi> and the problem is that the driver doesn't ever say "I have completed my scan, and found no drives" right?
<Kamion> no - the problem is that if you load ide-generic during that period, it'll grab anything that hasn't been grabbed by a more specific driver; if it grabs say a SATA drive, performance will degrade lots
<psusi> so if you are hoping that it will find a drive you just have to wait for an arbitrary period of time?  which isn't good...
<Kamion> the driver *does* say that, it just takes a while, and we're doing other stuff in the meantime
<Kamion> oh, sorry, it never says "no drives" AFAIK, right
<Kamion> but it's not really the driver's fault, it's having to ask the SCSI bus
<psusi> right... that's what is needed then... the driver needs to signal when it has completed it's scan so if it found no drives, you can then fall back to ide-generic, right?
<Kamion> as I understand it, the driver has no way to know
<Kamion> it's not scanning, it's standing up and shouting "hello, is anyone there?"
<psusi> sure it does... it knows how it is scanning for drives and when it is done it scans no more
<mjg59> Kamion: Well, there's two issues there
<mjg59> Kamion: The drivers won't start probing for disks before they've registered the interface, so there's no race with ide-generic there
<psusi> well, if we're talking about scsi disks, then it issues a scsi INQUERY command to each possible bus/target
<psusi> once it has done that for all busses/targets, it knows it is done scanning
<mjg59> Kamion: But you have no idea how long they're going to take scanning
<mjg59> Kamion: On the other hand, loading a PCI driver doesn't instantly bind it to the PCI device, and even then it doesn't instantly bind it to the IDE layer
<mjg59> And so ide-generic can grab it if it's loaded at the same time and you get unlucky
<psusi> there has to be some signal you can watch for to see that the pci driver has bound to the device and ide layer right?
<mjg59> psusi: Ngh. Well, ish.
<psusi> something in /proc
<mjg59> When it's bound to the PCI device, there'll be a device link in /sys/bus/pci/drivers/foo
<mjg59> But foo isn't necessarily related to the module name
<Diziet> FFS!  This `recipe' for conffile-mangling in the preinst script _reads /var/lib/dpkg/status_ for the md5sum of the conffile ?!
<Diziet> And it renames things to .dpkg-tmp and  FFS!!
<psusi> you mean the driver name and module name could be different?
<psusi> anyone who does that should be slapped
<mjg59> psusi: Yes
<psusi> with a few phone books
<Kamion> Diziet: I blame Scott
<Kamion> dpkg could really do with a few more built-in ways to work with conffiles though
<Diziet> Amongst the bizarre effects is that it does one thing if you   dpkg --unpack a.deb b.deb   and a different thing if you   dpkg --unpack a.deb && dpkg --unpack b.deb
<Diziet> It could do with having fewer bugs in corner cases.
<pitti> Diziet: what's the prefered way of determining whether a conffile is unmodified?
<pitti> Diziet: whenever a package wants to remove an old confile, it needs to go through this grep/md5sum dance right now
<BenC> pitti: is changing the lock default to 0 really the best thing in the case of cdroms?
<BenC> I saw one report that it caused some weird problems when a second cd was inserted
<pitti> BenC: alternative solutions would be modifying /etc/sysctl.conf, or adding an udev rule, but both were considered evil
<BenC> also, just because "windows does it" doesn't make it right
<BenC> pitti: for instance, macosx doesn't let you just hit eject, you have to do more :)
<Kamion> pitti: I think he means doing at at all, not where it's done?
<pitti> BenC: oh, other distros seem to do it as well, according to the bug reports
<pitti> Kamion: I know that moving conffiles to other packages is not nice, but it just happens from time to time...
<BenC> it seems that gnome-v-m doesn't really handle the cdrom being ejected out from under it all to well
<pitti> erm, Diziet ^
<Diziet> pitti: No package should ever do anything of this kind.  If dpkg doesn't do it right then we should fix dpkg.
<pitti> BenC: right, we need to umount -l the CD after ejection
<wftl> I've checked out https://wiki.ubuntu.com/LiveCDPersistence regarding the creation of a persistent home directory on Dapper live, but it's far from user friendly. Is there any plan (with the extention on the release date) to create some kind of friendly front end for persistence.
<Diziet> There is no reliable way for a package to tell what's going on, let alone safely interfere.
<wftl> Some kind of easy to use GUI.
<BenC> pitti: what if someone ejects the liveCD? :)
<pitti> BenC: then they are doomed, I guess :)
<Kamion> Diziet: as I understand it it is a design decision in dpkg that it doesn't remove conffiles. Packages need to have a way to tell dpkg that this file is now definitely redundant (or even harmful) and should go away now damnit.
<Kamion> I mean, doesn't remove old conffiles except on purge
<Kamion> where "go away now" may certainly include "leave a backup somewhere, but get rid of it from its former location"
<pitti> Diziet: so far packages tend to rm unmodified connfiles, and mv foo foo.dpkg-old modified ones
<Diziet> kamion: Ah, I see.  Yes, there should be a way to tell it that.
<Kamion> also, packages need a way to tell dpkg "this conffile needs to be renamed", and there's no way to do that without maintainer script hackery at the moment (if you leave out the maintainer script hackery, then admin changes in the old file will not be preserved)
<mjg59> Ah, good
<mjg59> Even with elilo installed, it's possible to get the macs to boot macos
<Diziet> If I get rid of the postinst and preinst from postgresql-common_46 then everything works just fine.
<BenC> pitti: I'm a little skeptical of the lock=0 thing, I think the argument that "newbies wont know" is not a good one, because Mac users are definitely newbie types and they deal with it all the time
<Kamion> mjg59: hold down some magic key?
<pitti> Diziet: oh, funny
<Diziet> Let me try it with a modified file.
<pitti> Diziet: so dpkg complains about a conflict if the file is not actually present, and works if it is?
<Kamion> holding down Option at startup would get you the usual menu, I suppose
<BenC> of course, most mac users have a keyboard eject button as opposed to one on the drive
<BenC> pitti: I'll give it some thought
<pitti> BenC: right, on ppc you need to eject with software anyway
<pitti> BenC: ok, thanks
<Diziet> pitti: Your maintainer script creates *.dpkg-tmp !
<Diziet> *.dpkg-tmp is for the use of dpkg, not maintainer scripts !
<mjg59> Kamion: Yeah
<pitti> Diziet: ok, I can rename that to .dpkg-migration, or whatever
<Diziet> No, just get rid of all of this stuff.
<mjg59> kamion: Hold down alt and then hit enter
<Kamion> right, figures
<Diziet> What goes wrong if you don't have it ?
<pitti> Diziet: if the conffile is modified, then dpkg asks silly questions
<Diziet> I just tried that and it worked just fine.
<Diziet> (I haven't tried it with breezy's dpkg.)
<pitti> Diziet: also, if the replacing package's version of the conffile is different from the replaced one, it'll ask as well
<Diziet> I think that case is also covered but I will test it now.
<pitti> Diziet: that was a huge problem in hoary and breezy, we had to apply this hackery to a lot of packages to avoid dpkg conffile questios on upgrades
<pitti> Diziet: if dapper's dpkg gets that right now, so much the better :)
<Diziet> pitti: Yes, that case works just fine.
<Diziet> That's the conffile migration bugfix.
<pitti> Diziet: i. e. a conffile was in gimp in hoary, and breezy moved it to gimp-common, but it had a different version of that file
<Diziet> But the workaround is completely broken in about three separate ways.
<Diziet> pitti: That works just fine now.
<pitti> Diziet: cool
<pitti> Diziet: sorry, I didn't test it with modified conffiles without the magic, since it was necessary up to a few months ago
<Diziet> Three ways: 1. stupid approach; should fix dpkg instead (now done).  2. doesn't get the right hash because /var/lib/dpkg/status is not definitive.  3. uses a private-to-dpkg filename.
<Diziet> So shall I upload postgresql with the hack removed ?
<pitti> Diziet: I'll do that for Debian myself
<pitti> Diziet: and that version isn't in Ubuntu yet
<Diziet> I'm going to grep the archives for similar idiocy and see if I want to do a mass bug filing.
<Diziet> Right, OK.
<pitti> Diziet: yep, you'll probably find lots of packages with that approach
<Kamion> Scott added similar code to a number of packages; I know it appeared in pcmciautils
<Diziet> Debian's dpkg has the fix too (not sure if it's in sarge, but Debian's dpkg maintainers accepted my patch).
<pitti> Diziet: thanks for checking this out
<Diziet> What a huge amount of effort compared to the day or two it took me to fix the problem in dpkg !
<Diziet> pitti: No problem.
<Kamion> Diziet: pcmciautils is probably another good test case for you; in that case it's dealing with an obsolete conffile
<Diziet> Does the file have to be deleted to avoid causing trouble ?
<Kamion> the code was added in version 010-0ubuntu8; I'll fish the .debs out of the morgue
<Diziet> morgue> Don't bother.
<Kamion> I think we could survive if it's not removed, but it would confuse people (since users often go wandering around in /etc/udev/ to try to figure out why hardware detection isn't working)
<Diziet> You could replace it with an empty file or a comment saying `this file is obsolete'.  Not ideal, I know.
<Diziet> Oh, it turns out that my own archive doesn't go back as far as 010-0ubuntu8.
<Kamion> True
<pitti> Diziet: but that would again trigger a dpkg conffile question if it is modified
<Diziet> Yes, but then the user probably wants to know that they modified this now-obsolete file and have to do something to make their changes in the new arrangements.
<Kamion> hmm, looking at it, strictly speaking the conffile was moved ...
<Diziet> Renamed, you mean ?
<Kamion> yeah, we used to install it in /etc/udev/pcmcia.rules and make a symlink to /etc/udev/rules.d/85-pcmcia.rules; now we install it in /etc/udev/rules.d/85-pcmcia.rules directly
<Diziet> I can't remember what dpkg does if you're naive about this but it's probably not good.
<Kamion> but I initially did it very crudely (because the package was very new, not installed on many systems, and frankly I didn't care); then Scott came along and added code to remove the obsolete file that was now hanging around
<Diziet> Do you want me to look into it ?
<Diziet> Anything that messes with *.dpkg-* or /var/lib/dpkg in a maintscript is probably broken.
<Kamion> If you want all examples of such code to go away, then you're welcome to treat it as another test case, but it's not critical for breezy->dapper upgrades or anything (since that package didn't exist in breezy)
<Diziet> Right.  OK, well, I'll just deal with it in my grep results then just as soon as I've written the grep script :-).
<Kamion> I would like to know what the code should now be replaced by though (and if the answer is "nothing", all the better)
<Diziet> Quite so.
<janimo> jdub, any specific gnomey stuff you want to see in xubuntu ;) ?
<sivang> janimo: xubuntu is in main now? :)
<janimo> not yet
<dholbach> mdz, Kamion: are you ok with an update from gthumb 2.7.5 -> 2.7.5.1 (you gave your ok on 2.7.5 and the update fixes an issue, we were going to fix in a patch, which now can be dropped) - or you want another mail for that?
<mdz> dholbach: yes
<pitti> dholbach: does that fix the 'absolute path' bug?
<dholbach> mdz: 'yes' ok or 'yes' mail? :)
<dholbach> pitti: you mean the broken importing?
<mdz> dholbach: yes, if it's only one patch and it's appropriate, go ahead
<pitti> dholbach: yes
<dholbach> mdz: merci
<dholbach> pitti: yes
<pitti> dholbach: rock :)
<Tonio_> hello everyone
<Tonio_> _ion: heard you asked for me ?
<LaserJock> Seveas: ping?
<Seveas> LaserJock, yes?
<LaserJock> Seveas: I was just reading the backlog, did \sh get taken care of?
<Seveas> don't know - still have to poke ogra
<Seveas> let's move to -motu
<setuid> I'm trying to rebuild a patched version of ibm_acpi in 2.6.15-18... I've pulled the source for the kernel, but how do I build _just_ this module, using the Ubuntu process? I'm used to doing "make modules SUBDIRS=drivers/acpi". 
<Treenaks> Why are you doing this?
<setuid> Because I need a patched version running on my Thinkpad
<setuid> I need the fan speed to go 2000rpm higher
<setuid> I have a full-speed option that I pass to it 
<Treenaks> setuid: We're trying to make everything work out of the box, so this is a bug, please file it.
<setuid> Its not a bug, its just an option not in the standard ibm_acpi code
<Treenaks> setuid: That's a bug. EVERYTHING should work correctly out of the box.
<setuid> There's 'enabled' and 'disabled', but I have a 'full-speed' option which brings the fan from 3,000 rpm to 5,000rpm
<setuid> Its a feature, not a bug
<Treenaks> setuid: So if your laptop doesn't, please file this as a bug so it can be integrated in the stock kernel
<setuid> See above
<Treenaks> setuid: Features are wishlist bugs.
<setuid> semantics
* Treenaks gives up
<Kamion> lamont: ia64 systems running 2.4 are guaranteed to have /proc/efi, right?
<Kamion> or no?
<setuid> Treenaks: So that still doesn't answer my questiuon
<Treenaks> setuid: you're not asking the right question, that's what I'm saying
<setuid> I need to rebuild ibm_acpi using the Ubuntu "standard" build process, but *JUST* this module, not all the kernels for all the architectures
<Kamion> what goes wrong when you issue the command you mentioned?
<setuid> So how do I use the Ubuntu-provided kernel sources, patch the ibm_acpi module, and rebuild _JUST_ this module
<lamont> Kamion: uh...
<lamont> 2.4... hrm.
* lamont checks
<lamont> Kamion: "if the module is loaded"
<Kamion> which module?
<setuid> Treenaks: http://rafb.net/paste/results/EgL6nE60.html
<setuid> Treenaks: Was my question not succinct enough? 
<dholbach> ogra: yet another dia for you :)
<setuid> debuild? dh-make? What is the process for properly building this module, in a way that puts the right EXTRAVERSION and such in 
* setuid tries a hacky approach
<Kamion> setuid: your question didn't specify (a) what went wrong when you did what you did, (b) whether you got the source using 'apt-get source' or by installing the source .deb
* Treenaks is tempted to suggest http://bouncer.gentoo.org/?product=gentoo-2006.0-minimal&os=x86
<setuid> Kamion: I pulled the source with apt-get source
<Kamion> dh_make is for creating packages from scratch and is not appropriate here
<Kamion> Treenaks: come on, "bugger off to gentoo" isn't a fair answer for somebody who wants to make a small tweak to their kernel
<setuid> Treenaks: Don't be a troll, I've been running Debian for 8+ years, I know the drill... but Ubuntu is a very different beast. 
<setuid> I typically do 'debuild' in the unpacked source tree
<setuid> but doing that here will take 1-2 days, since it builds every kernel for every arch
<Kamion> setuid: give me a minute to grab the source over wireless and duplicate the problem
<Treenaks> Kamion: I know, but he doesn't seem to want to even TRY to add this to malone and be helpful for other people
<setuid> Treenaks: You clearly don't understand the development/testing process. I can't add it to the 'malone' thing, until I verify that it ACTUALLY WORKS here. 
<Kamion> Treenaks: you don't seem to want to try to help him, either ...
<setuid> Ok, I managed to get it working now
<Treenaks> nevermind
<setuid> Built it standalone, outside the tree
<setuid> Works great
<setuid> # cat /proc/acpi/ibm/fan 
<setuid> status:         disabled
<setuid> speed:          5312
<setuid> commands:       enable, disable, full-speed
<Kamion> setuid: so what actually went wrong when you tried to do what you did?
<Kamion> you gave a command you ran, but not the actual problem
<setuid> Kamion: debuild builds a kernel that doesn't match the one I'm running from the upstream package
<setuid> I had to hack the top-level Makefile and some files below to fool it 
<Kamion> the Ubuntu kernel's ABI is indeed not the same as that of the upstream kernel
<Kamion> unless you mean something different by "upstream package"
<setuid> There's some magical mojo with .configs and such, right? 
<Kamion> sure, but debian/rules takes care of that
<setuid> upstream package in this context == the .deb that installed the kernel in /boot
<setuid> hrm, looks like there's a config in /boot and others in debian/config/i386/
<Kamion> if unpacking the source and running debuild doesn't get you essentially the same thing (not perhaps md5sum-identical, but at least compatible) as the .deb, that's (a) a bug and (b) very odd since the buildds essentially just do debuild (well, dpkg-buildpackage, but who cares)
<setuid> I think I want the one that matches the one I'm actually running
<Kamion> if you're hacking it about and then running debuild, that's a different story
<setuid> I had to hack it about just so it would build a kernel that matched the one I'm running 
<Kamion> debian/config/i386/ has config fragments for each of several different kernel builds; debuild builds them all
<setuid> # uname -a
<setuid> Linux angst 2.6.15-18-686 #1 SMP PREEMPT Thu Mar 9 15:29:22 UTC 2006 i686 GNU/Linux
<Kamion> building on current dapper?
<Kamion> because the buildds really do not do anything magic here
<setuid> $ grep EXTRAVERSION Makefile
<setuid> EXTRAVERSION =.5-ubuntu1
<Kamion> they're just a current dapper installation, and they run dpkg-buildpackage
<Treenaks> doesn't dapper have -19 now?
<setuid> So if I build with the unpacked kernel source from Ubuntu, it'll build a kernel which is different from the running kernel
<setuid> Treenaks: major bugs with -18 and -19, can't boot the system if its docked, or if any other hard drives are plugged in except /dev/hda
<setuid> And some sound-related issues
<setuid> Have to run: amixer sset 'Headphone Jack Sense' off && amixer sset 'Line Jack Sense' off
<setuid> Breezy has no problem in this same situation
<Kamion> if you debuild the kernel source package, it will give you several linux-image packages, not just one kernel
<setuid> Right, and I don't need the other 8 architectures
<setuid> Can I pass it a flag to build just 386/686
<Kamion> they aren't architectures BTW, they're flavours - knowing the right term will help you find what you need
<setuid> well, 6 architectures that is 
<setuid> sparc, amd64, etc. are 'flavors'? In my vernacular they're chip architectures. 
<Kamion> setuid: move the files for the flavours you don't want in debian/config/i386/ to foo.disabled
<Kamion> setuid: debuild does not cross-compile to sparc, amd64, etc. if you're building on i386
<Kamion> sparc, amd64, etc. are architectures
<Kamion> 386, 686, k7 etc. are flavours
<setuid> Ideally, that would allow me to pass the 'flavor' I want to build, but renaming them is a hacky solution I suppose. 
<Kamion> (either that or hack debian/rules)
<Kamion> (the configs := bit)
<setuid> True, either way requires manual editing ;) 
<Kamion> it would be possible to implement an environment variable that let you specify a subset of flavours, I'm sure; BenC would know whether that's sane
<Kamion> the boot problems you mentioned above were discussed here earlier, I think, and will be handled by some fun initramfs-tools hacking
<Kamion> not strictly a kernel issue as such, though kernel changes might happen to avoid it
<Kamion> (as far as I know, anyway)
<setuid> building now...
<blacking> sorry for my intrusion here..
<blacking> probably my post is OT..
<pitti> blacking: as long as you stay on topic, you aren't intruding :)
<pitti> oh
<blacking> i found resources link or other as install a minimal ubuntu into an usb pen drive..
<blacking> for ppc platform..
<blacking> https://wiki.ubuntu.com/Installation/FromUSBStick
<LaserJock> blacking: you should probably try #ubuntu or we can keep talking in #ubuntu-doc
<Pygi> infinity: ping
<Mithrandir> Kamion: bah, silly me.  Did you retarget it or should ?
<Mithrandir> I, even.
<Mithrandir> Pygi: you're being optimistic that infinity is around at 06:38 in the morning? :-)
<Pygi> Mithrandir: ah, sorry ^_^ Didn't knew it was that time in his country ^_^
<Mithrandir> Pygi: I doubt he minds, he's probably asleep, but I wouldn't expect a response for a few hours.
<Mithrandir> Pygi: he lives in Australia
<simira> Mithrandir: you expect everyone to know?
<Tonio_> _ion: ping
<Mithrandir> simira: no, I tell Pygi that he's slightly optimistic and I assume he didn't know (or he wouldn't have tried).
<Mithrandir> Pygi: anyway, he'll probably respond to your question if you just ask your thing, when he gets around.
<simira> :-)
<Pygi> Mithrandir: kk, thanks ;)
<Pygi> infinity: would you be so kind to build new l-r-m modules with patch on this new kernel build? thanks ^_^
<psusi> Mithrandir: still not heard anything back from upstream about the e2fsprogs kernel header conflict on amd64?
<Mithrandir> psusi: no, I should probably ping them again
<Mithrandir> psusi: if you send me a mail (tfheen@ubuntu.com), I'll do it in the morning
<psusi> ok
<Toadstool> ping seb128 
<dholbach> Toadstool: he went away for a bit, can I help you?
<Toadstool> that was to ask him if it is possible to create an ubuntu-l10n-fr mailing-list, as he is the team owner
<dholbach> Toadstool: you can ask jdub (list-super-admin) or smurf (loco super chief)
<Toadstool> that's a little off topic here I know :/
<dholbach> Toadstool: no it's not necessarily off-topic, but that's all I can say :)
<Toadstool> ok :)
<seb128> Toadstool: there is a such list already: ubuntu-fr-l10n@lists.ubuntu.com
<seb128> Toadstool: https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr-l10n
<Toadstool> ah really ? I didn't find it :/
<Toadstool> sorry :)
<seb128> np
<psusi> so how is this ide-generic problem not a bug in the sata driver?  if the sata driver detects the controller, then it should claim the hardware so ide-generic can't... not go ahead and talk to the controler anyhow without claiming the ports while it detects the drives
<mjg59> psusi: It's not clear that there actually is a problem now
<psusi> heh
* infinity grunts himself awake and notices people were looking for him at 6:30am...
<bddebian> Yeah, ya bum :-)
<Burgwork> some of us were up at the crack of 8:45am
<CarlFK> installer still has problems with grub and /boot being on a raid - it should prevent that from being done, but it tries, fails and you end up with a box that won't boot.  
<bddebian> CarlFK: What kind of problem?
<CarlFK> is this worth messing wiht, or would fixing it be... adding a feature which isn't going to happen now
<infinity> Burgwork: Bah, it's 8:00am right now..
<CarlFK> bddebian: grub won't install to /dev/md0
<CarlFK> the "easy" fix would be to not allow /boot to be on a raid or lvm 
<bddebian> CarlFK: It worked fine for me on a Compaq array controller.  Though cpqarray wasn't in initramfs
<blacking> hello dev..
<CarlFK> this is software raid
<bddebian> Ah
<bddebian> Software raid sucks anyway :-)
<CarlFK> you can make it work with some extra steps, you can get grub on a raid1, but I think that should be done outside the Ubuntu installer
<_ion> tonio: Hi
<tseng> putting grub on software raid isnt a great idea
<CarlFK> yeah yeeh - I am looking for redundancy, not performance
<tseng> if its possible at all
<tseng> i mean, /boot
<CarlFK> it is, you just have to trick it (which is why I dont think the installer should do it)
<tseng> the mbr obviously isnt in software raid
<CarlFK> as long as hda1/boot and md0/boot are the same thing, (which they are in raid1) the it will work
<CarlFK> for the mbr, you just install it to hd0 and hd1 
<tseng> thats pretty gross
<CarlFK> one you get it all setup, you can pull any drive and it will still boot
<CarlFK> agreed 
<_ion> But it works. :-)
<Tonio_> _ion: heard you were asking for me today ?
<CarlFK> it would be nifty if the installer would do it all, but for now I think it should just prevent you from even trying
<_ion> tonio: Yep. Did you get my email? I sent some updates to the n-m package last night.
<CarlFK> but if the "prevent from trying" isn't going to happen for dapper, I wont bother with it now
<blacking> is it possible install ubuntu onto an usb drive ppc filesystem?
<_ion> tonio: Would it be possible for me to get write access to the repository? I could send updates and also sign the repo.
<CarlFK> so back to my question - how does "prevent from trying" relate to feature freeze?
<Pygi> _ion: he got the updates...
<Tonio_> _ion: hum, yes of course :)
<Tonio_> _ion: but we removed the signing function
<Tonio_> _ion: honnestly, that's not really usefull for a testing one
<Tonio_> _ion: apart from the patches, do you have others modifications to apply ?
<Pygi> Tonio_: please drop that patch I've gave you in kubuntu-devel
<LaserJock> blacking: like I said before try #ubuntu or lets keep our conversation in #ubuntu-docs. This really isn't an support channel
<Tonio_> Pygi: why ?
<Pygi> Tonio: or perhaps ... fix the patch?
<_ion> tonio: Nothing new since my last email.
<Tonio_> I found the problem :)
<Pygi> well, the package refuses to build?
<Pygi> ah,kk
<Pygi> great ;)
<dholbach> good night guys
<Tonio_> _ion: well, if you have any modification to apply, ask me foor ftp access, the repo is auto updated every 15 minutes
<Pygi> night dholbach
<Tonio_> dholbach: nite ;)
<dholbach> *wave*
<_ion> tonio: The behavior of the /etc/network/interfaces blacklist thing should be modified somewhat, i'll do that maybe tomorrow.
<_ion> pygi: Btw., i have updated http://johan.kiviniemi.name/ubuntu/nm-bugs
<mdke> jdub, "fascist proxy"? It's for my own good *hugs proxy*
<mdke> jdub, as for 'cocksmoking', I have no idea. We should test it.
<_ion> tonio: Oh, i just noticed your mail. If the package version in the repository stays the same even though it's updated, nobody will get the updates when apt-get upgrading.
<_ion> tonio: That's why used -0ubuntu0.$X style version numbers for development. That < -0.ubuntu1 which would be the first "official" Ubuntu package version.
<Tonio_> _ion: if md5sum changes, you still get updates :)
<Tonio_> no problem with this
<Kamion> Mithrandir: I haven't retargeted it; please do
<Mithrandir> Kamion: 'k, I'll just have to find my desk first.
<Mithrandir> (it's buried under a pile of paper)
<_ion> tonio: Oh. I didn't know that. I thought apt-get only upgrades packages if the package's version number is increased.
<Tonio_> _ion: I thought too before testing this a few month ago :)
<_ion> :-)
<Tonio_> _ion: I'm trying to apply a patch
<Tonio_> but fails for a strange reason
<psusi> apt-get does only upgrade packages if the package's versionn number is increased, which is why we use -0ubuntu1 for packages that aren't in debian
<Tonio_> _ion: I'm not espacially a coder, which you seem to be more than me ;) can you have a look ?
<_ion> tonio: Sure.
<Tonio_> psusi: well, when I'm changing the package on my personnal repo, without changing the version name, it works.....
<psusi> and why upstream beta packages are named like foo-0.99+1.00beta3
<Kamion> psusi: that's not quite correct; it will upgrade if the version number stays the same but something else about the package changes
<Tonio_> psusi: I'm doing that for tests since months
<Kamion> psusi: it will not upgrade if the version number *decreases*
<psusi> oh... right.... if it stays the same..
<Tonio_> _ion: http://mail.gnome.org/archives/networkmanager-list/2006-January/msg00141.html
<Tonio_> _ion: two patches possible, but the first one causes problems, cause will need to be changed if madwifi is updated....
<Tonio_> _ion: I'm trying to apply the second one, but build fails....
<Tonio_> there should be something to change or add, but I can't do that myself :)
<_ion> tonio: Ok, i'll try to fix+apply it tomorrow.
<Tonio_> _ion: thanks very much ;)
<_ion> np. :-)
<Tonio_> _ion: when you put my name, can you plz you tab ? because I will not see you pinged me when another channel ;) the icon will not blink
<Tonio_> tonio vs Tonio_ ^^
<_ion> tonio_: I have binded the tabulator to another purpose. :-)
<_ion> tonio_: Maybe /hilight tonio
<Tonio_> _ion: ah ? ;)
<Tonio_> k
<_ion> For example i have /hilight -regexp \<ion
<_ion> So this hilights "ions" but not "lion".
<_ion> In irssi.
* Gwynn is away: Ik ben bezig
<Tonio_> I'm not using irssi, I prefer graphical tool like konversation for IRC ;)
<_ion> Ok. It probably has a similar feature.
<Tonio_> but I will make a highlight rule for this, no pb :)
<Tonio_> it can of course ;)
<_ion> tonio: Could you rename the knetworkmanager package as network-manager-kde, btw.?
<_ion> Oh, i forgot the _ again. :-)
<Tonio_> _ion: hehe
<Tonio_> _ion: we should get the latest source version by the end of the week, I'll apply the changes then :)
<_ion> Ok, thanks.
<Tonio_> _ion: already on my TODO list
<pitti> fabbione: oh, btw, I reviewed git-core today
<pitti> fabbione: http://wiki.ubuntu.com/MainInclusionReportGitcore, it needs a security fix
<Keybuk> Mithrandir: what kind of seeding of /etc/iftab do we do on the Live CD ?
<Keybuk> sivang: ping
<Mithrandir> Keybuk: none
<Keybuk> Mithrandir: ok.  as long as it's "none" or "the same as netcfg" that's fine
<Mithrandir> Keybuk: casper at least doesn't touch iftab
<Keybuk> yeah, there's no reason that it should; we seed it in the installer so the installer and real system have roughly the same idea about network card order
<Keybuk> as there's no installer component to the live cd, I wouldn't expect that to be necessary
<Mithrandir> agreed.
<Keybuk> and we ship n-m by default on the live anyway
<Keybuk> so it doesn't particularly matter whether they change orders
<sivang> Keybuk: pong
<Keybuk> sivang: 100 lines of "I shall not patch debian/* in debian/patches" on my desk by the morning please
* sivang screams.
<sivang> did I do that?
<Keybuk> yes, initscripts
<Keybuk> syndicate sysvinit-2.86.ds1% diffstat -p1 debian/patches/100_mountall_fix_output.dpatch
<Keybuk>  debian/initscripts/etc/init.d/mountall.sh |    4 ++--
<sivang> Keybuk: how many copies of that punishment paper?
<_ion> tonio, pygi: Currently the blacklisting works this way: if (interface NOT listed in /etc/network/interfaces) { blacklist = FALSE } else if (interface is "auto" and "inet dhcp") { blacklist = FALSE } else { blacklist = TRUE }. mjg59 proposed it would be changed to: if (interface IS listed, and IS "auto") { blacklist = TRUE } else { blacklist = FALSE }. Do you agree? (I do.)
<Keybuk> just the one <g>
<sivang> Keybuk: okay, other that that, will a fixed source help?
<Keybuk> _ion: that would reverse the blacklist
<_ion> tonio, pygi: Should i modify the patch to work that way?
<Keybuk> which would be wrong
<Keybuk> sivang: s'ok, I'm uploading a new one anyway
<Tonio_> _ion: sounds good said like that, yes
<Pygi> _ion: lemme check, sec pls
<_ion> keybuk: Why should it work the way it does now?
<sivang> Keybuk: bah so sorry, /me takes a mental note not to work on critical packages after the pm has switched to pm
<Keybuk> _ion: because the way it works now is "a device is blacklisted if there is manual configuration for it"
<Keybuk> you're proposing doing the exact opposite
<sivang> that jsut proved what I said :) s/pm$/am/
<Keybuk> auto *; iface * inet dhcp; is "automatic" configuration
<sivang> Keybuk: thanks btw :)
<_ion> keybuk: Someone might want to let n-m manage the interfaces at the workplace and run "ifup eth0" at home with "inet static" configuration.
<Keybuk> _ion: explicitly out of spec for dapper
<Keybuk> the spec in fact says we won't support that
<Keybuk> to support that without ignoring a user's attempts to stop n-m running on an interface requires changing ifupdown
<pitti> hi zyga 
<_ion> keybuk: Ok, i won't touch the patch.
<Keybuk> for dapper+1 I actually quite fancy getting rid of ifupdown entirely
<zyga> pitti: hey :-)
<Tonio_> Keybuk: hum, yes, that's right
<Keybuk> and instead applying the logic that all interfaces are brought up with DHCP unless explicitly stated otherwise
<HrdwrBoB> n-m has worked perfectly for me with the exception of the airo driver biting it
<zyga> pitti: do you happen to know if flight 5 has broken installer?
<zyga> ppc version doesn't see any partitions on my disk
<pitti> zyga: I doubt it :)
<Tonio_> HrdwrBoB: I think that's a known issue
<Tonio_> HrdwrBoB: many users complaining with the airo driver
<Pygi> Tonio_: yes, it is ...
<zyga> pitti: which version of OS X do you have?
<pitti> zyga: the flights are tested on all platforms, so while there are certainly bugs, it's not broken for everyone
<HrdwrBoB> Tonio_: airo drive has been dodgy since forever, it used to change interfaces on suspend
<HrdwrBoB> *driver
<pitti> zyga: uh, I don't know; the one that was current in July 2004, when I bought the machine...
<pitti> zyga: I never use it :)
* sivang will submit 100 lines of "I shall not patch debian/* in debian/patches" to pitti's desk as well.
<zyga> pitti: well I tried all possible combinations and dapper just dones't see the osx partitions (and vice versa)
<zyga> hmm
<zyga> strange
<Keybuk> *sigh*
<zyga> pitti: if you manage to boot osx someday please let me know
<pitti> zyga: yes, that works fine
<Keybuk> sweet
<pitti> zyga: it never broke
<Keybuk> SEEEEEEEEEB!
<_ion> Patching debian/patches/* in debian/patches would be pretty. ;-)
<HrdwrBoB> Keybuk: how would that work (f-e) on a bonded connection
<pitti> seb128: flee!
<HrdwrBoB> i can use ifupdown to bring up bond0, which is great
<zyga> pitti: I'd love to run some quality tests if I knew what to look for
<Keybuk> HrdwrBoB: you'd supply a configuration for it
* seb128 runs away from Keybuk
<Keybuk> HrdwrBoB: my intent is that all interfaces have *A* configuration
<pitti> zyga: I don't know what's broken for you :)
<Keybuk> where as at the moment some interfaces don't :)
<HrdwrBoB> ah :)
<Keybuk> seb128: X-Chat core dumps
<Keybuk> if you e.g. /whois _ion :)
<seb128> xchat or xchat-gnome?
<Keybuk> xchat
<seb128> I don't care about that one :p
<zyga> pitti: installing flight 5 on ppc doesn't see existing partitions and allows to repartition the drive (only)
<Keybuk> I'll make you care
<Keybuk> with a spoon!
<pitti> Keybuk: WFM
<seb128> backtrace?
<Keybuk> seb128: I'll get you one later when I'm not trying to do some work <g>
<seb128> :)
* sivang notes the sudden awakening in this channel
<lamont> pitti: on the subject of screwed up configs, I'd like my dapper machine (maybe 2-3 days out-of-date now...) to automount removable media.... what got trashed where, I wonder?
<pitti> lamont: hm, I don't know a general recent breakage
<lamont> nah - iz more breakage on my machine
<lamont> and not particularly new
<pitti> lamont: can you please do http://wiki.ubuntu.com/DebuggingRemovableDevices and open a bug or mail the logs to me?
<pitti> lamont: hello, btw :) 
<Keybuk> sivang: it's after supper time, and we're clearly all bored with nothing better to do this evening
<lamont> pitti: thanks
<lamont> and yeah, hello there.
<lamont> pitti: that'll be in several hours, fwiw
<sivang> Keybuk: fine by me, as long as I was included in the happening :)
<zyga> night guys :-)
<zyga> have fun
* Gwynn is back (gone 00:54:28)
<Burgwork> Gwynn, please turn off your public away messages
<Gwynn> burgwork: done, sorry
<Burgwork> Gwynn, no problems, thanks
<Keybuk> man, I love /dev/raw1394
<Keybuk> it's my all-time favourite device
<sivang> fast ?
* Keybuk not for the first time gets an evil inclination to add a udev rule to stop creating it
<Keybuk> muahahaha
<Keybuk> sivang: it's equivalent to inventing a "/dev/usb" device
<desrt> erm
<Keybuk> that lets you read and write whatever you like to any connected usb hub or device
<desrt> doesn't kino, etc require raw1394 access?
<Keybuk> and even better, the Firewire spec allows devices to execute code on the host system in a privileged state
<sivang> oh oh goody
<desrt> how does that work, exactly?
<desrt> some bytecode or does it send native x86 and hope for the best?
<Keybuk> desrt: yes, see all the "why raw1394 owned by root/root and not root/video" bugs
<sivang> I thought it was only for trasnferring data as on USB devices, but in outrageous speeds
<Keybuk> bytecode I think, a bit like ACPI
<desrt> wonky
<desrt> have you see the firestarter demo?
<Keybuk> sivang: no, because there's just one /dev/raw1394 device for the entire stack
<Keybuk> where as with USB, we have /dev/usb/XXX/YYY - one device for each real device
<sivang> yes, I see.
<desrt> someone wrote this demo for macosx
<desrt> it shows a burning fire on your screen
<sivang> Keybuk: so how do you tell one device from the other ?
<desrt> if you plug such a computer into any other mac via firewire then the fire spreads
<sivang> (when there's more the one connected)
<Keybuk> sivang: I've no idea, I guess that's what lib1394 is for
<Keybuk> it's evil
<sivang> heh , if it knows to do things like that, it must be :-)
<HiddenWolf> Keybuk: ping
<Keybuk> heh
<Keybuk> join, ping, quit
<Burgwork> Keybuk, evidentally it was not that important
<Keybuk> indeed
<Keybuk> HiddenWolf: you rang?
<HiddenWolf> Keybuk: yes I did. Got a minute?
<stewart> hi guys anyone know if there is a bug for hauppage tv cards in flight5
<Keybuk> HiddenWolf: always
<HiddenWolf> Keybuk: I'm confused about https://launchpad.net/distros/ubuntu/+source/udev/+bug/29789
<Ubugtu> Malone bug 29789 in udev "tv card audio not working" [Wishlist,Needs info]  
<Keybuk> HiddenWolf: right
<HiddenWolf> Keybuk: I've tried all sorts of blacklist combinations, but I keep having to manually modprobe to get audio for my card.
<Keybuk> ok, so let me explain a bit how module loading works
<Keybuk> for each device on your system, the kernel generates a string that looks a bit like pci:v1834d09214... etc.
<Keybuk> for each driver, depmod generates a string that looks the same, but with wildcards in
<stewart> under flight 3 my hauppage bt484 (I thnk) worked out of the box on a fresh flight 5 tvtime is not seeing it
<Keybuk> modprobe can be given the first string, and match it against all the wildcard ones (in /lib/modules/*/modules.alias)
<Keybuk> and thus get a list of modules to load
<Keybuk> sometimes there may be two conflicting answers
<Keybuk> the common example is where a soundcard is supported by OSS and by ALSA
<Keybuk> so you can blacklist one of them
<Keybuk> blacklisting means that when performing alias expansion, modprobe will ignore that one module
<Keybuk> ok
<stewart> ok wait a min mines a bt878
<Keybuk> so for your tv card, there are two answers
<Keybuk> snd_bt87x (ALSA) and bt878 (OSS)
<Keybuk> and a cute bug where snd_bt87x won't work if bttv has been loaded first
<Keybuk> bttv is a dependency of bt878
<stewart> device manager is finding it just not tvtime
<Keybuk> syndicate scott% modinfo bt878 | grep depends
<Keybuk> depends:        bttv
<Keybuk> unfortunately both of these drivers support a different set of devices; so we don't blacklist one or the other
<Keybuk> and I think your card needs both loaded anywa
<Keybuk> now, if you load them in the order
<stewart> how come the no probs under flight 3? or are you talking to the other guy
<HiddenWolf> seems like it.
<Keybuk> snd_bt87x, bt878
<Keybuk> things work
<Keybuk> if you load them in the other order
<Keybuk> things don't work
<Keybuk> stewart: kinda talking to both of you; specifically answering HiddenWolf but delightfully this is your problem too <g>
<HiddenWolf> :)
<Keybuk> now blacklisting isn't actually useful here
<stewart> :-)
<Keybuk> because bttv is loaded by the dependency mechanism, blacklists aren't consultled
<Keybuk> and there's no way to force modules to be loaded in a particular order
<Keybuk> in fact, we've avoided creating on etoo
<Keybuk> because it would still cause problems if you had two different cards
<stewart> so this isnt a change from flight 3?
<Keybuk> we think (and BenC - our kernel maintainer agrees) that it's a bug in the bttv driver
<Keybuk> I'm not aware of any changes from flight 3 to 5, unless we have a different selection of modules
<stewart> darn I was hoping to have some useful feedback for you :-(
<Keybuk> stewart: there isn't anything useful other than a "this is what we know at this point"
<Keybuk> we know it's a bug
<HiddenWolf> Keybuk: was afraid of that.
<Keybuk> we think it's a kernel driver bug
<HiddenWolf> Keybuk: so it should be reassigned.
<Keybuk> I just did that
<stewart> thats cool then guys Im not chasing my telly just wanted to make sure you'd heard of it
<HiddenWolf> I'm guessing it stands a good chance of being a dapper+1 bug?
<stewart> you dont think its fixable for dapper?
<Keybuk> it's "fixable for dapper" if a fix comes along
<Keybuk> we're certainly a couple of months out from kernel freeze
<HiddenWolf> *chuckle* No kiddin. :)
<Keybuk> however we have no direct in-house experience of this, and it's not something that's ever worked anyway (ie. not a regression from breezy)
<HiddenWolf> Hey, hold on, it worked since warty!
<HiddenWolf> ;)
<Keybuk> it did?  that's probably sheer fluke <g>
<stewart> thats a shame when I saw dapper (flight3) with ootb v4l on my card I thought it would be cool addition
<HiddenWolf> heh
<Keybuk> the best way to get it fixed would be to get the kernel upstream to look into it
<stewart> well on breezy I had to mess with module loading
<Keybuk> and that way if a patch appears, we can merge it into our kernel repository
<Keybuk> stewart: you can mess with module loading now
<stewart> but flight 3 worked both sound an vid straigh away
<HiddenWolf> Someone should set up a good website with supported hardware for dapper, just to tell me what hardware to buy. :)
<stewart> yup
<Keybuk> echo snd_bt87x >> /etc/mkinitramfs/modules
<Keybuk> update-initramfs -u
<Keybuk> (bit of an evil hack, but it works)
<stewart> well if you're after an mp3/ogg player samsung yp just works
<HiddenWolf> Keybuk: heh
<Keybuk> or, less evil
<Keybuk> echo blacklist bt878 > /etc/modprobe.d/blacklist-bt878
<Keybuk> echo bt878 >> /etc/modules
<Keybuk> (blacklist bt878 from auto-loading, but then load it later)
<HiddenWolf> i'll remember taht
<HiddenWolf> that, even
<HiddenWolf> Well, that takes care of one of Dapper's annoyances.
<stewart> is that the same issue as mine
<Keybuk> stewart: as far as I know
<stewart> mines not a sound issue
<Keybuk> what's your issue?
<stewart> tvtime doesnt see any tuner
#ubuntu-devel 2007-03-19
<sladen> delrey: however, the fact that you've raised it, may mean there is a market.  The difficulty might be finding a mentor with suitable knowledge /and/ willing
<BenC> sladen: This cpu thing is going to have to be fixed in userspace
<BenC> sladen: The reason we lose cpufreq reference is because the kernel hot-unplugs the cpu before suspending
<BenC> sladen: So all ref's to it are removed
<BenC> userspace needs to respond to cpu hot plug/unplug and do something with it
<BenC> like restore scaling governor and such
<BenC> sladen: Also, if you're going to help with kernel bugs (and I really appreciate it), can you read over https://wiki.ubuntu.com/KernelTeamBugPolicies
<sladen> BenC: haha, *grin* it makes sense now.
<dsas> BenC: Could you make the bugsquad aware of that page if you haven't already? ubuntu-bugsquad@lists.ubuntu.com
<sladen> dsas: could you? :)  If you send it and CC to BenC you know that it'll get done!
<dsas> sladen: Sure, just checking it hadn't already been sent there. I'm behind on my email.
<dsas> oh, it's already been to devel-announce. I'll forward it on.
<BenC> dsas: Thanks
<dsas> BenC: no problem.
<sladen> wah  "katu kernel: [204078.636000]  Using specific hotkey driver"
<jdong> sladen: mine says that too....
<jdong> sladen: I think it enables some hidden cheat codes :)
<Fujitsu> Mine does that in all its terminals sometimes too :(
<kylem> jdong, what package version?
<jdong> kylem: latest kernel
<jdong> kylem: ever since like -9
<jdong> [   19.656000]  Using specific hotkey driver
<jdong> it will put that on all terminals if bootup is fast enough
<Fujitsu> I've had it since around -9 too, and it appeared several times over the course of a few days (no reboots).
<Fujitsu> I see sladen has filed a bug with the solution :)
<kylem> jdong, odd, i pushed a fix for that to git last week.
<jdong> interesting.... well it still shows up in -20 oddly
<jdong> err, make that -12
<kylem> fucked up.
<sladen> Fujitsu: jdong: can you confirm it
<jdong> sladen: yeah I can confirm ; 
<kylem> what bug #
<Fujitsu> Bug #93564
<Ubugtu> Malone bug 93564 in linux-source-2.6.20 "printk("Using specific hotkey driver\n"); has no prefix" [Undecided,Confirmed]  https://launchpad.net/bugs/93564
<BenC> patches welcome :)
<jdong> lol
<jdong> well in that case I'll just live with it :D
<kylem> uh.
<BenC> I'll fix it real quick
<kylem> i fixed it already.
<BenC> will be in release, not in beta though
<kylem> http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=398c3db849ca235addc3bc16b8c683f180518661
<BenC> kylem: Oh, you're fast
<kylem> no.
<kylem> 4 days ago.
<kylem> KERN_INFO shouldn't be broadcast by syslogd.
<BenC> ah, then it's in -12
<jdong> BenC: it's happenin with -12
<jdong> at least it did once....
<jdong> hmm
<BenC> jdong: I can't see how, even the bug report shows that the printk line has KERN_INFO prefix
<kylem> maybe something else is printing it as well.
<Fujitsu> I had it happen yesterday, and I'd upgraded and rebooted a day prior.
<BenC> the new kernel just came out today
<kylem> eeentaresting.
<BenC> linux-source-2.6.20-2.6.20$ rgrep "Using specific" *
<BenC> drivers/acpi/hotkey.c:          printk(KERN_INFO "Using specific hotkey driver\n");
<BenC> so it's fixed
<Fujitsu> Ah, OK.
<kylem> ah.
<kylem> possibly sladen didn't reboot, but had fetched new src.
<jdong> yeah perhaps I'm imagining it too... never mind :)
<BenC> random people really need to stop marking bugs as "Confirmed" without Importance and Assignee :/
<BenC> Ah, that was Fujitsu :)
<kylem> uhm. on a thought.
<Fujitsu> BenC: Does your new policy forbid that?
<kylem> oh. nm. it includes timestamp. i was thinking there might be some kind of user program. oh well.
<BenC> Fujitsu: I can't see it making any sense to Confirm a bug without having a priority set, and it being assigned
<Fujitsu> ...
<Fujitsu> That makes more sense for In Progress.
<BenC> No
<Fujitsu> But not Confirmed.
<BenC> we have different teams for kernel bugs
<BenC> the "Confirmed, assigned to team" state is used as a list of where to got to work on bugs
<kylem> uhm.
<BenC> a team member pulls the bug into "In Progress" and assigns it to themselves
<BenC> kylem: mainly, we have ubuntu-kernel-team, ubuntu-audio (crimsun)
<kylem> sorry, the uhm, was another thought.
<BenC> Fujitsu: For kernel bugs, Confirmed == assigned to ubuntu-kernel-team, for future reference
<BenC> kylem: ah :)
* Fujitsu thinks that makes very little sense.
<Fujitsu> But it's your call.
<BenC> exactly
<BenC> Fujitsu: wiki.ubuntu.com/KernelBugPolicies...you have to understand, kernel bugs are very different than bugs on other packages, we have a team that needs to coordinate, and we have a large incoming stream of bug reports
<BenC> we need policies like that to keep things straight
<BenC> KernelTeamBugPolicies I meant
<Fujitsu> Yep, I can see that...
<twb> Howdy.  I'm building customized livecds based on Edgy; my script in /etc/rcS.d doesn't appear to be run automatically at boot time.  What am I doing wrong?
<jdong> BenC: oops sorry then I've been guilty of using Confirmed incorrectly in the past, too. I apologize and defend myself on account of ignorance :D
<BenC> jdong: It's no problem, but to be honest, it's a new policy that just started being enforced :)
<BenC> I've been trying to go through the bug reports today and clean things up
<BenC> it's really hard to get a handle on them without some consistency
<jdong> yeah, that's for sure
<LeeJunFan> hrm, there seems to be a missing /etc/init.d/mountnfs - mount-bootclean mentions it as a requirement, and my nfs mounts don't get done at bootup.
<fabbione> morning
<Hobbsee> heya fabbione!
<fabbione> yo yo
* Hobbsee uses her psychic powers on fabbione to make him do more stuff :P
<fabbione> what kind of stuff? :)
<lifeless> be careful what you wish for
<Hobbsee> i'm sure i coudl find something...
<fabbione> well find it :) otherwise i will start to work for real ;)
<Hobbsee> fabbione: fix all the bugs in ubuntu by 5pm.
<Hobbsee> :)
<fabbione> Hobbsee: isn't bug #1 enough by 2pm? i have a meeting then ;)
<Ubugtu> Malone bug 1 in ichthux "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
<Hobbsee> fabbione: heh.  maybe
<fabbione> :)
<matia1> /matias
<doko> good morning
<Hobbsee> heya doko 
<bluefoxicy> I have a question.
<bluefoxicy> The Web host I work at uses Fedora Core but constantly has problems because it goes EOL
<bluefoxicy> FC4 for example is currently EOL, vuln at highest patch level in many instances
<bluefoxicy> It's come to my attention that Ubuntu has 1.5 year support, but Dapper has a 5 year LTS cycle
<bluefoxicy> When Dapper EOLs, will the coinciding release have a 5 year LTS cycle or a normal 1.5 year support cycle?
<bluefoxicy> It just seems like an interesting idea
<LaserJock> bluefoxicy: I think it depends on when the next LTS release is
<bluefoxicy> LaserJock:  is there some sort of criteria?
<bluefoxicy> Like some magic has to happen that makes the developers want to do it?
<LaserJock> when the free software world looks good
<jdong> LaserJock: I'd logically expect another LTS to be available before Canonical decides to unplug dapper.
* jdong lives in happy utopia
<bluefoxicy> I'd not expect two to overlap because then you'd have 5 distros to support :)
<giftnudel> anyhow, there should be an option to update from one LTS to the next LTS
<jdong> bluefoxicy: well I'd expect a smooth upgrade path _somewhere_ :)
<LaserJock> well, you can imagine what makes sense
<bluefoxicy> smooth upgrade paths are important
<bluefoxicy> half the time when we upgrade things the shit hits the fan as hard as it can
<bluefoxicy> BOOM broken server
<LaserJock> but I've been told several times that the LTS releases aren't done as a time release
<giftnudel> bluefoxicy: the fc is probably intentional, as you are supposed to buy the commercial product from redhat, right?
<Fujitsu> I'd except Feisty+2 to be LTS, to allow a reasonable changeover period.
<Fujitsu> *expect
<Fujitsu> Otherwise desktops only have 6 months to change.
<jdong> LaserJock: right, but I dont' think Canonical would strand Dapper EOL without another LTS around...
<jdong> LaserJock: after all, they _do_ have corporate customers, no?
<bluefoxicy> I've had much more luck with Ubuntu than Fedora in that regard; though I've been told that FC6 upgrades from FC4/5 smoothly (Finally; FC4->5 destroys your system and you have to spend 2 hours fixing it)
<bluefoxicy> giftnudel:  probably.  FC is community supported though.  It's like Ubuntu but not as good.  :)
<jdong> bluefoxicy: 6-7 won't yum... gotta use Anaconda
<LaserJock> jdong: I would think so but they have 5 years for the server
<bluefoxicy> jdong:  balls.
<LaserJock> they have quite a bit of time
<jdong> bluefoxicy: but I've managed to yum-ify a lot of Fedora upgrades :)
<jdong> bluefoxicy: no, not balls, just recklessness :)
<jdong> bluefoxicy: did I tell you I booted Ubuntu off ntfs-3g once?
<bluefoxicy> ...
<jdong> bluefoxicy: supported upgrade options are for sissies :)
<jdong> lol
* jdong decided to restore his computer from backups for fun today...
<jdong> and I SWEAR the system runs faster...
<bluefoxicy> now that you've defragged it?  :P
<jdong> guess it doesn't hurt to refresh a 1.5-year-old ext3....
<jdong> bluefoxicy: that might be ;-)
<bluefoxicy> my /home is xfs :/
<jdong> bluefoxicy: hmm... XFS has always rubbed me kinda wrong as a general-purpose FS
<bluefoxicy> reiserfs :P
<jdong> I use it for my media encoding drive
<jdong> bluefoxicy: actually I did that for a few years :)
<bluefoxicy> reiserfs is trash
<jdong> it didn't work out too badly
<jdong> esp. back when ext3 was dog slow
<bluefoxicy> yeah
<bluefoxicy> it was the first journaling file system I was aware of
<jdong> yeah for sure
<jdong> and remarkably fast at its time
<bluefoxicy> I suppose jfs predates it by a billion years
<bluefoxicy> jfs is trash too though
<jdong> its Linux port wasn't stable at that time
<bluefoxicy> if you go down it'll be like ACK
<jdong> reiserfs was the first Linux stable journaling fs
<bluefoxicy> and never come back to life, ever, even after a fsck or log replay
<jdong> "stable" being a relative term of course
<jdong> bluefoxicy: the thing that got me with JFS... you must mount ro, fsck, remount rw after uncleanness
<jdong> bluefoxicy: which doesn't happen automatically for /home
<bluefoxicy> jdong:  I tried JFS last in Breezy.
<jdong> bluefoxicy: I used it in Breezy too...
<bluefoxicy> I cycled power 3 times randomly and it could not recover, fsck said it was clean and mount said "OSHIT CAN'T DO THIS IT'S FUXED HARD!"
<jdong> that was my last runin with it too....
<jdong> bluefoxicy: I used it on an old computer... 33MHz 486/DX
<bluefoxicy> O_O
<jdong> where every other fs but ext2 was absurdly slow
<bluefoxicy> dude, ubuntu doesn't run on its minimum specs, give it up
<jdong> like apt-get upgrade of 1 package was 30 minutes long
<jdong> bluefoxicy: hey hey it runs vim just fine :P
<bluefoxicy> 192MB of RAM == kill GNOME before running Ubiquity.. in fact make Ubiquity your WM
<jdong> bluefoxicy: it's a fully console system
<bluefoxicy> ah
<jdong> bluefoxicy: warty warthog actually :)
<jdong> never upgraded it past that
<bluefoxicy> I actually installed GUI ubuntu dapper on a 350MHz AMD K6-2
<bluefoxicy> with 192MB of RAM
<bluefoxicy> ubiquity kept OOMing
<jdong> bluefoxicy: a 400MHz celeron, 256MB RAM + Ubuntu GNOME was our standard-issue robotics computer
<jdong> our corp sponsor had STACKS of them lying around
<jdong> so we just took them, Ubuntu, and handed out free laptops to all team members interested in programming
<bluefoxicy> Eventually I shut down everything-- cups, hplip, gnome, gdm, lvm/evms, mdadm, everything
<jdong> worked great.
<bluefoxicy> did a startx with ubiquity as the only running process
<bluefoxicy> it barely made it.
<jdong> ha Ubiquity is pushing it :)
<jdong> the alternate installer works with about like 24-38MB of RAM
<bluefoxicy> If I was wiping the disk it would have been fine, I'd have made the swap partition; but I was resizing a win98 partition
<jdong> actually that systme had 24MB RAM and it failed
<jdong> so I installed Ubuntu from another system and transfered the HDD
<bluefoxicy> debootstrap
<jdong> naw had other computers -- easier :)
<jdong> and you have no idea how painful extracting debs is
<jdong> :)
<bluefoxicy> damn small linux
<jdong> reading database.....
<jdong> (4 hours later)
<bluefoxicy> share drive as ntfs
<bluefoxicy> install to that
<jdong> lol
<bluefoxicy> err, as nfs
<bluefoxicy> not ntfs wtf
<jdong> I've done the NTFS thing too :P
<bluefoxicy> I want Ubuntu/MINIX
<jdong> haha
<bluefoxicy> barely any hardware support, networking... only IDE...
<bluefoxicy> but if you're lucky you'll have GNOME with no sound on an ne2000 NIC 
<bluefoxicy> I think it'd be just awesome enough to cause a growth spurt in Minix development.  Maybe.  Hey I love the pure microkernel design, what can I say?
<LaserJock> ah Minix, the first non-MS OS I ever used :-)
<LaserJock> Debian took too many floppy disks ;-)
<bluefoxicy> Minix 3 is up now
<bluefoxicy> it's actually taken on its full form
<bluefoxicy> Minix and Minix2 both represented research; Minix3 capitalizes on that, the effort now aims to produce a desktop-ready OS
<bluefoxicy> jdong:  have you seen the crazy shit I've been throwing on the wiki?
<bluefoxicy> https://wiki.ubuntu.com/UbuntuSecurityCore
<bluefoxicy> I'm actually leaning mostly towards OSSIM.......
<bluefoxicy> it doesn't matter though, it's not like anyone will actually do it
<pitti> Good morning
<Seveas> hi pitti 
<Seveas> pitti, do you happen to have a few spare cycles today?
<pitti> hi Seveas 
<pitti> Seveas: probably not, things are just a matter of priority :) so what's up/
<pitti> ?
<Seveas> I have 3 non-invasive but important patches to various usplash themes that should go in before beta. They fix color issues
<Seveas> I asked Mithrandir, but being release manager he had no time :)
<Seveas> pitti, would you have time to apply & upload them? The only thing they do is change pallette indexes from "completely broken to the point where they may cause segfaults" to "sane and looking ok"
<pitti> Seveas: sure, I can do that, as long as this doesn't interfere with kwwii's work
<pitti> Seveas: where's the new package?
<Seveas> kwwii already cheered for doing it :)
<Seveas> pitti, http://www.kaarsemaker.net/files/usplashcolors.patch http://www.kaarsemaker.net/files/usplashcolors-e.patch http://www.kaarsemaker.net/files/usplashcolors-x.patch
<Seveas> patch for usplash-theme-ubuntu edubuntu-artwork and xubuntu-artwork
<pitti> looks sane enough
<pitti> Seveas: any particular reason why you changed hex to dec?
<Seveas> the hex was a silly mistake and caused the darkblue-text-on-black-background
<Seveas> where it said 0x144, I meant 144
<Seveas> etc...
<Seveas> so addressing portions of memory possibly not under our control (aka segfault...)
<Seveas> well, possible segfault
<Seveas> gotta go to work, if you want to know more, please drop me a mail
<pitti> Seveas: a changelog would have been nice, but I'll craft one
<mitsuhiko> good morning :)
<pitti> cjwatson: funny that d-i moved to -11 kernels one minute after BenC uploaded -12 ;)
<pitti> asac: WDYT about https://wiki.ubuntu.com/DapperFirefoxSupport ?
<pitti> asac: our last attempts with backporting stuff to older major releases were pretty much disastrous; were there some changes upstream or in the inter-distro porting teams which would make it easier now?
<pitti> Mithrandir: I uploaded usplash-theme-ubuntu and xubuntu-artwork with Seveas' color palette indices fixes; patch looks sane, usplash still looks sane, edubuntu-artwork already has the patch applied
<Mithrandir> pitti: coolie, thanks.
<cjwatson> pitti: yeah, I've just been playing catch-up - unfortunately somebody (possibly me, I forget) remove-package.py'ed the old kernels before d-i had moved away from them, so all the d-i-based CDs broke, and I was trying to get them functional again
<heno> does the "No kernel modules were found" problem in alternate/server have a bug number?
<heno> fabio said this was a known issue
<Mithrandir> needs a d-i upload, probably?
<cjwatson> heno: there is never a point filing a bug about that one
<seb128> morning
<cjwatson> yes, it should be sorted as of today's CDs, if not I'll notice
<heno> ok, we were just discussing it in the testing forums
<cjwatson> heno: "No kernel modules were found" means that the kernel version in the installer seed is out of sync with that in the version of d-i on the CD, or that the kernel version in the installer seed is no longer in the archive
<cjwatson> ah, I need to munge the archive for the new d-i
<heno> god news is that the volunteer testers are actually finding things :)
<heno> right
<Mithrandir> seb128: compiz> not needed for beta, right?
<cjwatson> I'll rebuild the CDs after this publisher run
<seb128> Mithrandir: not sure, mdz mailed me to get this patch in
<Mithrandir> seb128: what about gdm?
<seb128> Mithrandir: it fixes the .desktop category, I would accept it
<Mithrandir> BenC: your grub upload in unapproved is incorrect; grub does not work correctly with gcc 4.1 without any changes.
<Mithrandir> seb128: 'k, accepted.
<seb128> thank you
<fabbione> what kind of info are usually required to file a bug on Network Manager? /etc/network/interface?
<seb128> Mithrandir: could you approve gedit also?
<seb128> Mithrandir: it just lists "upgrade" as a known prerm case
<Mithrandir> seb128: oh, sure.
<seb128> gtkhtml3.14 is a one liner which fix the emoticons use
<Mithrandir> fabbione: what is the problem?
<fabbione> Mithrandir: it breaks my static ipv6 setup...
<seb128> and xchat-gnome would be nice to accept, since it's not on the CD anyway ...
<fabbione> Mithrandir: ifup brings up the interface correctly.. nm restarts it without ipv6 
<Mithrandir> fabbione: feel free to file a bug, I doubt it'll be fixed without a patch though.
<fabbione> Mithrandir: well it's a regression from edgy/dapper... but feeeehhh
<Mithrandir> and yes, a copy of interfaces(5) is fine.
<fabbione> now the most funny part...
<fabbione> http://people.ubuntu.com/~fabbione/mount
<fabbione> does anybody have a clue on why /var/run and /var/lock are mounted a few gazillion times?
<fabbione> if i run mount -a again, it will remounted again a few times...
<pitti> hm, not here...
<fabbione> pitti: i noticed only today with the very latest updates 
<Mithrandir> seb128: xchat-gnome; you want that in too?
<fabbione> and machine can't reboot/halt.. hangs at sending KILL signal to processes (but it seems to be a known bug already)
<seb128> Mithrandir: <seb128> and xchat-gnome would be nice to accept, since it's not on the CD anyway ...
<seb128> up to you
<seb128> it can wait after beta if you think it's better, the fixes are easy enough though
<Mithrandir> ah, ok, seems safe enough
<seb128> cool
<siretart> is it possible to see what's in the unapproved queue in launchpad for edgy-proposed?
<Mithrandir> siretart: yes
<siretart> how?
<Mithrandir> https://launchpad.net/ubuntu/edgy/+queue
<Mithrandir> look in the unapproved list, and the "proposed" pocket.
<siretart> hm. then somehow my upload of libaqbanking got lost
<siretart> I got this email from launchpad, but cannot find it anywhere: http://paste.ubuntu-nl.org/11009/
<Mithrandir> hm, it's in the queue on drescher just fine.
<Mithrandir> siretart: can you use 3ubuntu1~proposed1 or something like that as the version number instead, please?
<siretart> Mithrandir: okay. Willdo. shall I reupload right now?
<Adri2000> 3ubuntu0.1~proposed1 even, no?
<Mithrandir> Adri2000: *shrug*; doesn't really matter, given that 2.0.0-3 is in edgy, 2.2.3-3 is in feisty.
<Mithrandir> siretart: yes, please.
<siretart> uploaded
<siretart> Mithrandir: sorry for having it uploaded with the wrong version number in the first place, but was this the cause that it doesn't show up in /+queue?
<jvw> ooi, why the /+foo type of urls in so many of the launchpad urls etc?
<jvw> (I mean the '+')
<Mithrandir> siretart: no, those things are unrelated.
<siretart> k
<siretart> jvw: I suspect because LP is a conglomeration of zope applications
<jvw> ah, that's a zope-ism? Never really worked with zope either
<cjwatson> jvw: ask #launchpad, I guess; my best guess is that since a lot of Launchpad is organised as a taxonomy, they needed something to identify reserved names
<cjwatson> compare /ubuntu/feisty and /ubuntu/+queue
<cjwatson> if it were /ubuntu/queue then you couldn't create an Ubuntu release called 'queue'
<cjwatson> (silly example, but)
<jvw> right, yeah. It does solve a namespace issue that way
<doko> pitti: did you get any negative feedback about your python2.5 patch? if not I would like to apply it to the python2.4 package as well
<pitti> doko: no, not so far
<pitti> doko: I'm still waiting for an upstream response
<dholbach> hellas
<ogra> pitti, i thought about that we should probably see how we avoid the xserver probing completely, the flashing screen might trick users into thinking the new driver is in effect immediately ...
<pitti> ogra: I just fixed it to not automatically probe screen resolutions
<pitti> that might help?
<ogra> hopefully ... what exactly did you do ? i could need it for ltsp as well
<pitti> ogra: I remember xserver-xorg/autodetect_{monitor,mouse}, set it to false, reconfigure, and restore the previous values
<ogra> ah
<cjwatson> heno: current images should have that kernel modules problem fixed
<heno> cjwatson: ok, cool. I'll ask people to confirm it during testing
<termitor> hello, quelqu'un parle un peut francais , c pour un probleme de depots , enfin de cron 
<termitor> so , ubuntu use a cron for make the maj list of packages , and my depot is explose under this mass ask
<termitor> it's possible to set a varaible time for the cron of depot ? is most beter for everybody , i'm thinl
<termitor> thinl
<termitor> thinl
<termitor> sorry , think (arf)
<termitor> s/depot/repository
<Enola_Gay> Hi all, it seems that the hpijs-ppds package is missing in Feisty. Otherwise the automatic installation of e.g. HP Photosmart printers doesn't work out of the box HPLIP Toolbox.
<Enola_Gay> This bug was confirmed through one of the hplip devs but it seems that it hasn't been fixed until now.
<Mithrandir> hpijs-ppds | 2.7.1+1.7.1-1ubuntu2 |        feisty | all
<Mithrandir> seems to be in feisty all right.
<Enola_Gay> Mithrandir: The package works fine but doesn't seems to be installed by default or is it only a kubuntu problem?
<Enola_Gay> I have found a bugreport which points to kubuntu. https://launchpad.net/ubuntu/+source/kubuntu-meta/+bug/84936 How could I check which packages are installed in Ubuntu by default?
<Ubugtu> Malone bug 84936 in kubuntu-meta "hpijs-ppds package does not automatically install in Kubuntu feisty herd 3 install" [Undecided,Unconfirmed]  
<imbrandon> Mithrandir, can you nuke a upload i just made to the NEW queue please ? ( emerald )
<Mithrandir> imbrandon: sure
<imbrandon> thanks
<Mithrandir> done
<imbrandon> you rock
<imbrandon> is it your archive day btw ?
<Riddell> Enola_Gay: hpijs-ppds was removed from the ubuntu seed at the request of till
<Mithrandir> imbrandon: technically, yes, but I'm in RM mode atm.  If you just have minor stuff, I can do it, but I'd prefer to concentrate on getting beta ready.
<imbrandon> Mithrandir, right on , ok
<Riddell> Mithrandir: what's up with the i386 images?
<imbrandon> moins Riddell 
<Mithrandir> Riddell: probably d-i blowup
<Riddell> sounds dramatic
<Mithrandir> as in, mismatch between d-i kernel and what's in the archive
<Mithrandir> or actually, what do you mean what's up with them?  The alternate ones look fine size-wise at least?
<Riddell> Enola_Gay: so there's probably a good reason for it, need to ask when he next turns up
<Riddell> Mithrandir: alternative ones are there now yes, no live ones still
<Enola_Gay> Riddell: Ask whom?
<Riddell> Enola_Gay: till
<Mithrandir> oh, true, that's just the soyuz failure where it falls over trying to unpack the i386 tar.gz.  We have a fix for it, but I didn't want soyuz to change just before beta so it requires handholding until we have the fix in production.
<Enola_Gay> Ok.
<Riddell> Mithrandir: how do I get i386 images then?  I have to ask you?
<cjwatson> Riddell: I already rebuilt yours
<cjwatson> look again
<Mithrandir> Riddell: no, I believe Colin is working on it, and you want to wait a little bit still so you get the latest round of fixes.
<cjwatson> oh, ok, not the live ones
<Enola_Gay> Ok, thanks, cu.
<cjwatson> I'll do those now
<cjwatson> Mithrandir: I'd like to upload http://people.ubuntu.com/~cjwatson/tmp/partman-partitioning.resize2fs.diff and http://people.ubuntu.com/~cjwatson/tmp/partman-auto.resize2fs.diff; they work for me in simple tests
<termitor> where is the file as the time of packages update listing ?
<cjwatson> termitor: it's run from /etc/cron.daily/apt, so it's run with the rest of cron.daily out of /etc/crontab
<Mithrandir> cjwatson: makes sense, please upload
<cjwatson> the only downside is that I think it makes the progress bar situation even worse
<cjwatson> but trying to fish progress information out of resize2fs, while theoretically possible, would be a lot of rather delicate code, so I'd rather not
<termitor> cjwatson: 6h25 the time is the same for all , it's a problem no ?
<Mithrandir> cjwatson: at least not at this point; agreed.  We can always add a machine-readable output mode to resize2fs later.
<cjwatson> termitor: sorry, too busy to discuss it now beyond providing a pointer to the information. I would suggest that you should improve your server if it's having problems
<thom> cjwatson: it /is/ a valid point - i mentioned it to mvo in MV
<cjwatson> we can't easily make the time variable without changing quite a lot of stuff, as right now /etc/crontab is simply a standard conffile shipped in the cron package. You can change it on your machines and it won't be reverted on upgrade
<cjwatson> thom: sure, I didn't say "point invalid", I just don't have time right now ...
<thom> but yes, we didn't come up with a reasonable fix
<cjwatson> and anyway indeed it's mvo's territory :)
<thom> portsnap on freebsd writes a random time out the first time it's run and always uses that, iirc
<cjwatson> I don't think it makes sense to make cron.daily have a variable time, so /etc/cron.daily/apt would need to be moved out of cron.daily
<cjwatson> (cron.daily should run at $obnoxious_local_time_when_you_are_probably_asleep
<cjwatson> )
<thom> ah! i remember how portsnap works. it's run from cron.daily, but then sleeps n seconds, where n is decided at random the first itme it runs
<Treenaks> cjwatson: it runs ay 6:30am for me.. and imho that's too late :)
<cjwatson> viviersf: bug 93635 - eh? since when was the swap partition supposed to be bootable? please provide a reference
<Ubugtu> Malone bug 93635 in ubiquity "Guided partitioning doesnt set swap partition as active" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93635
<Mithrandir> thom: that's evil wrt cron.daily running with --report
<thom> Mithrandir: yeah
* Hobbsee waves
<thom> it's not nice, but better than many thousand machines clobbering a mirror
<Mithrandir> hiya Hobbsee 
<thom> hey Hobbsee 
<maswan> thom: locally, we have a 00-randomsleep cron.* job
<viviersf> cjwatson, uswsusp <---- requires the swap partition to be active to allow hibernation to work. You can mark it as a feature cos Mithrandir said it will be in feisty + 1
<thom> maswan: yeah
<cjwatson> viviersf: that's nuts
<ogra> pitti, do you have an overview of the total size of all language packs anywhere ? or do i have to compute that myself from your table ? i still have ~350M free on the server-addon CD of edubuntu 
<cjwatson> we should boot through a bootloader, not do crackful things like requiring an active swap partition
<cjwatson> on some systems I expect that that would render the main system unbootable
<pitti> ogra: sure, http://people.ubuntu.com/~pitti/tmp/langpack-size.txt
<maswan> because some of the servers contacted by some cron jobs really don't appriciate hundreds of syncronised queries
<viviersf> kay cjwatson 
<ogra> pitti, yes, that has no overall total ...
<pitti> ogra: why not?
<ogra> i want a sum at the bottom :)
<cjwatson> viviersf: also that's not true with current uswsusp according to the changelog
<viviersf> hmmm
<pitti> ogra: just look in the last line ('zu')
<viviersf> the one in feisty moans about it sigh
<pitti> ogra: G+KSum
<cjwatson> oh, actually, not clear
<cjwatson> viviersf: exactly what is the error message, so that I can grep for it and beat up the correct bit of code?
<ogra> pitti, yes, that shows me the summary of the single language ... i want a summary of all langs :) i'll write a script ...
<pitti> ogra: no
<ogra> no ? 
<pitti> ogra: G+K  is Gnome+KDE of the *single* language
<ogra> argh, silly me ...
<pitti> ogra: ...Sum is the cumulative size of that language and all langs before that
<pitti> ogra: IOW, we have 246220438 bytes of langpacks+input support it total
<ogra> yep, undestood now
<viviersf> cjwatson, ok give a moment to disable that active nonsense and get it
<ogra> so that should only eat about 250M cd space 
<ogra> sounds like i can ship them all :)
<pitti> ogra: heh, just use the regex magic then? :) (/^language-pack-[^-] +$/)
<pitti> ogra: same for gnome/kde, of course
<ogra> yeah
<viviersf> cjwatson, suspend: Could not stat the resume device file
<pitti> ogra: well, just /^language-pack-/ is probably enough
<ogra> well, i need to exclude the ones that we have in desktop already, germinate wont like duplication i guess
<viviersf> cjwatson, when you run dpkg-reconfigure  uswsusp it moans about swap
<pitti> ogra: yep, maybe
<cjwatson> viviersf: ok, you misunderstood the error
<viviersf> eh
<cjwatson> viviersf: it doesn't mean active as in "has the active flag set in the partition table"; it means active as in "has been swapon'ed"
<asac> pitti: redhat and novell committed to maintain 1.5.0.x for a while
<viviersf> cjwatson, :( but the swap file is on :/
<cjwatson> viviersf: then it's a uswsusp problem
<viviersf> k
<cjwatson> swap *file*? it may not be able to handle swap files
<cjwatson> only swap partitions
<asac> pitti: http://christopher.aillon.org/blog/2006/12/
<pitti> asac: ah, thanks
<viviersf> cjwatson, it gave an different error earlier, ill reinstall the thing and let you know
<cjwatson> viviersf: doesn't look like an installer problem, anyway
<viviersf> yeh
<viviersf> soz
<cjwatson> ogra: germinate couldn't care less about duplication; it warns but that's about it
<viviersf> cjwatson, reject it then
<cjwatson> viviersf: already done. :)
<cjwatson> thanks for the clarification
<viviersf> hah kay
<ogra> cjwatson, would it install them in both targets even with the warning ? 
<ogra> or prefer one ?
<cjwatson> ogra: it'll use the innermost (i.e. if something's in both minimal and standard, it'll only put it in standard), or if the two seeds in question don't have such a relationship (e.g. ship and live), it'll put it in both
<cjwatson> er, "it'll only put it in minimal", I should have said
<ogra> yep, understood 
<cjwatson> it's just the same as something from desktop depending on something that's already in standard, really
<ogra> well, add-on is slightly different ...
<pitti> ogra: I guess in your case it's similar to 'live' and 'ship', i. e. two distinct targets
<ogra> it doesnt depend on anything ... 
<ogra> i'll just add the regex, lets see what i get ;
<ogra> )
<cjwatson> ogra: sure it does
<cjwatson> see the STRUCTURE file: ship-addon: boot minimal standard desktop server ship
<ogra> oh, ok
* ogra wonders why he always forgets about looking in STRUCTURE first ...
<dholbach> heno, TheMuso: do we want lsr 0.5.0 in for feisty? if so we'd need uvf exception for it
<dholbach> ogra: somebody already told you about (yet another) dia release? :-)
<ogra> huh ?
<ogra> sigh
<ogra> i guess that has to wait until after beta
<dholbach> ogra: 0.96-pre9
<mvo> termitor: yes, its not ideal that the cron job runs at the same time for everybody
<ogra> Mithrandir, ^^^ should i upgrade dia before or after beta ? 
<viviersf> is there a ppc version of feisty planned ?
<Hobbsee> viviersf: cds?  if they fit
<viviersf> huh
<viviersf> i see theres like sparc etc copies of herd 5
<viviersf> but no powerpc
<cjwatson> see cdimage.ubuntu.com/ports/
<viviersf> thx
<Mithrandir> ogra: after.
<ogra> Mithrandir, thanks, thats what i thought
<ogra> pitti, hey, bug 65028 should be fix released, shouldnt it ? i see the patch in the source ...
<Ubugtu> Malone bug 65028 in hal "doesn't dim screen on SONY VAIO (vgn FS215M / Z1 RMP) (regression)" [Medium,Confirmed]  https://launchpad.net/bugs/65028
<cjwatson> Mithrandir: what happened to the "later" milestone? I'd like to resurrect that
<Mithrandir> cjwatson: it's just deactivated, I'll reactivate it
<cjwatson> thanks
<pitti> ogra: no idea; if it is, please close it; thank you!
<Mithrandir> cjwatson: done
<ogra> pitti, i think it is, i'll check twice and close ...
<cjwatson> cheers
<ravi> I want to vote for wicd being in the repos
<Hobbsee> ravi: it's nto a vote.  there is no wand waving here.
<pitti> Mithrandir: I fixed the seven non-wishlist/non-needsinfo restricted-manager bugs; I deem two of them important for beta (broken X), the rest is more or less hardware detection fixes; how do you want to handle this?
<ravi> it's an awesome tool which has better flexibility, in my mind, than Network-Manager for specific scenarios such as hidden broadcasts, etc.
<Hobbsee> ravi: how about you package it for feisty+1, and then discuss it?
<Hobbsee> ravi: and get it into feisty+1
* pitti nags mvo about bug 92524; maybe we should close this now and you reopen when it happens again? r-m now has entirely different logic
<Ubugtu> Malone bug 92524 in restricted-manager "Breaks X when disabling fglrx" [High,Needs info]  https://launchpad.net/bugs/92524
<ravi> Hobbsee: not involved with the project whatsoever but I'll try to let someone know inside the project
<pitti> Mithrandir: http://pastebin.ca/401529 is the complete debdiff
<Mithrandir> pitti: which bugs are the broken X bugs?
<pitti> Mithrandir: bug 92849 and bug 93643, and (less dangerous) bug 92573
<Ubugtu> Malone bug 92849 in restricted-manager "Restricted drivers manager damages my xorg.conf [Nvidia Legacy Drivers] " [High,Fix committed]  https://launchpad.net/bugs/92849
<Ubugtu> Malone bug 93643 in restricted-manager "changes manually set resolution" [High,Fix committed]  https://launchpad.net/bugs/93643
<Ubugtu> Malone bug 92573 in restricted-manager "xorg.conf is updated before driver installation" [Medium,Fix committed]  https://launchpad.net/bugs/92573
<BenC> Mithrandir: I saw nothing in debian/changelog that said gcc-4.1 was broken, so I thought nothing of it
<Mithrandir> BenC: so you didn't build and test the resulting binaries?
<BenC> Mithrandir: Still, grub cannot be rebuilt in feisty, and that's a problem, right?
<Mithrandir> BenC: yes, it's a problem, but I'm not going to let in a change which makes grub non-functional three days before beta. :-)
<BenC> Mithrandir: No, I only built it
<Mithrandir> my blood pressure is going to be high enough as it will be, thanks. :-P
<BenC> Mithrandir: lol, well, should it be dropped back down to gcc-3.4 since that was working before it got bumped to gcc-4.0?
<heno> dholbach: sure, it would be nice to have. How strict are the UVFs for universe?
<Hobbsee> heno: not terribly.  2 ack's
<Mithrandir> BenC: that'd be better, yes.
<BenC> Mithrandir: Ok, I'll upload a new one for gcc-3.4, but feel free to put it on hold till after beta
<Mithrandir> BenC: sure, that's fine.
<BenC> the crashdump change isn't all that important
<Mithrandir> pitti: debdiff, please?
<termitor> mvo_: you are the good personne , so you whant patch for have a randomise time of day of the cron of apt ?
<termitor> mvo_: it's possible include it in feisty or current release ?
<mvo_> termitor: feisty may be a bit late, we are very close to the release already
<mvo_> termitor: but thanks a lot of the offer do make a patch for it!
<pitti> Mithrandir: <pitti> Mithrandir: http://pastebin.ca/401529 is the complete debdiff
<Mithrandir> pitti: ok, looks good.
<heno> ogra: I can add some more Edubuntu winfoss if you want. I left out some nice ones like inkscape
<ogra> heno, inkscape wouold be cool, since we have the linux version on the same CD ... lets see how it looks after the next build if the langpack changes took effect
<ogra> the *shold* be more than 50M free still, but i like proofs first ;)
<heno> ogra: oki, fyi inkscape is 16 mb
<ogra> ok
<ogra> heno, after beta i think
<mantiena> Hello all
<Hobbsee> hiya
<mantiena> doko: hi, are you online ? I wanna talk about OOo maintaining
<doko> mantiena: don't talk, just fix bugs
<mantiena> doko: :)
<Hobbsee> doko: unless mantiena is here to talk about taking over OOo maintaining from you, of course?
<Hobbsee> *g*
<mantiena> Hobbsee: bingo ;)
<Treenaks> "Don't talk just fix" - Right Said Doko ? *hides*
<doko> mantiena: any specific issues?
<mantiena> doko: it seems Ubuntu seeks OOo maintainer pretty long time, at least on ubuntu.com/employment I see this  more than 3 months...
<mantiena> doko: so, it seems you need help with maintaining, I'm right ?
<heno> ogra: does one need a thin client setup to sensibly test the server CD?
<tbf> hi, accidently i've uploaded to upload.ubuntu.com, instead of uploading to revu.tauware.de (why doesn't point dput's config on revu by default?)
<mantiena> doko: so, you need at least comaintainer or not ? ;)
<tbf> so feel free to remove my vala crap :-)
<Hobbsee> tbf: you'll just get a declined message
<Hobbsee> tbf: it auto-rejects if you're not in the keyring
<Hobbsee> or maybe you dont get a message - i dont remember
<tbf> Hobbsee: ok
<Hobbsee> tbf: because the default place to upload is to ubuntu - at least for developers
<doko> mantiena: well, needing help and an open position are two different things, although they may be connected
<mantiena> ;)
<tbf> Hobbsee: well. dunno which group is larget: motu-contribs or core-developers. but guess the default in that config file should be adjusted for the larger and less educated group ;-)
<Mithrandir> tbf: just use a local .dput.cf ?
<tbf> well, but not here to argue
<tbf> Mithrandir: well, just slightly bitter 'cause i forgot to edit my file
<tbf> Mithrandir: but its possible and hopefully i'll remember now, if i should install dput on yet another machine
<Hobbsee> tbf: which is MOTU + Core dev.  it also says in the REVU howto about it, i'm sure.
<Hobbsee> it certainly used to
<tbf> Hobbsee: yup. when installing dput on my desktop i remembered to change
<tbf> but then i decied to build on the notebook, which is faster - and there i forgot
<ogra> heno, its helpful, but no requirement
<heno> ok
<Mithrandir> mvo_: can you do another run of the upgrade testing?
<mvo_> Mithrandir: yes, thanks for the reminder
<mantiena> cjwatson: hi, I've reported bug about not working virtual consoles in LiveCD,  you told me, that I should  show it to you and you will fix it before beta, so, look at bug #92928
<Ubugtu> Malone bug 92928 in casper "casper corrupts virtual consoles creation events (/etc/event.d/tty1 - tty6) " [Undecided,Unconfirmed]  https://launchpad.net/bugs/92928
<ogra> hrm ... when was this notification bubble for share desktop added ? is the a way to supress that ? 
<pitti> Mithrandir: thanks for the review, uploaded
<ogra> *there
<ogra> (thin-client-manager has a function to export your desktop to the whole classroom ... everythime i use it me and indeed all other users as well get that popup warning on the shared screen)
<cjwatson> mantiena: no, please don't misrepresent what I said
<cjwatson> mantiena: I said:
<cjwatson> 19:51 <cjwatson> please let me know the bug number once you file it (or find an existing one) and I'll ensure it's milestoned for beta
<cjwatson> I did NOT say that I would personally fix it.
<cjwatson> mantiena: also please don't nominate bugs for feisty when feisty is the current development trunk. It means nothing and is a waste of effort.
<cjwatson> bugs are "nominated" (or equivalent) for the current development trunk by default
<asac> Mithrandir: ping? -> pm
<mantiena> cjwatson: ok, so, please ensure, that this bug will be milestoned for beta ;) Btw, what you think about reducing numbe of virtual text consoles to 2 ar 3 ? Noone needs 6 virtual consoles on Desktop live CD, they are using RAM, which is very important when you use Ubuntu from Live CD, sometimes even installer crashes if there are less than 256 RAM (for example when computer has video controler, which uses main memory)
<mantiena> s/numbe/number
<cjwatson> mantiena: they use a whole 4KB of non-shared RAM. I don't care.
<mantiena> cjwatson: only 4 kb  how you are counting ?
<cjwatson> rss minus shared
<cjwatson> looks like a one-liner in casper
<Mithrandir> seb128: control-center, vte, do you want those in for beta?
<seb128> Mithrandir: control center is a 3 lines change, would be nice to have (and it only modify a capplet, not likely to break anything)
<Mithrandir> seb128: ok, accepted.
<seb128> Mithrandir: the vte upload fixes a crasher, a refresh bug on desktop switching that several people complained about an another bug, up to you to know if you are happy with the changes or prefer to get them after beta
<seb128> the changes come from upstream (SVN or bugzilla) and they don't break the world on my desktop
<mantiena> cjwatson: btw, what you think if I will attach patch, which fixes bug #25496 ? it's very simple patch - just add one function - parse_cmdline() from Debian's casper, this function just exports TORAM, TODISK and some other variables if toram, todisk or some other boot parms are specified on startup
<Ubugtu> Malone bug 25496 in casper "toRam or copy2Ram (run ubuntu live from ram)" [Wishlist,Confirmed]  https://launchpad.net/bugs/25496
<mantiena> it seems someone forgot to stole this function from Debian,  in latest merge
<cjwatson> I would have no opinion on the subject. I only hack casper when I need to - I'm not the maintainer
<mantiena> cjwatson: oh, sorry, I though, that you are one of comaintainers
<cjwatson> like I say, just when I need to be
<cjwatson> which is basically when it affects the installer
<mantiena> cjwatson: so, who is main maintainer ? ;) tfheen or mdz or .. ?
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/casper/bzr/casper>$ grep Maintainer: debian/control
<cjwatson> Maintainer: Tollef Fog Heen <tfheen@ubuntu.com>
<cjwatson> seems very simple to discover ;-)
<twb> I'm trying to make upstart do Bad Things.  #upstart is dead; anyone here wanna talk about it?
<bddebian> Heya
<twb> bddebian: good day.
<bddebian> Hello twb
<mantiena> cjwatson: thanks
<BenC> Kernel Team meeting in 10 minutes in #ubuntu-meeting for those interested, agenda is at https://wiki.ubuntu.com/KernelTeam/Meeting
<mantiena> twb: I already forced upstart to do Bad Things on sunday ;)
<twb> mantiena: I want an init.d script to be able to ask the user for confirmation.  This worked on Knoppix; the same script doesn't work under Edgy.  I think upstart is connecting the script's input to /dev/null instead of /dev/console.
<twb> ...which makes sense for an async init manager, but I don't know how to work around it.
<Mithrandir> use usplash for user interaction.
<twb> Mithrandir: it's prompting for confirmation before erasing a hard disk, and usplash is not installed.
<Mithrandir> install usplash, then? :-P
<Mithrandir> anyway, afk for a bit.
<twb> I *can* install it, but I'd prefer not to bloat the image any further.
<twb> The script itself is visible here: http://twb.ath.cx/~twb/scratch/knoppix-pers/debian/init.d
<twb> ...so yeah, usplash is only for output; it can't get input from the user, right?
<mantiena> twb: sorry, I never tried to do interactive boot scripts ...
<twb> Yeah...
<twb> How is the install program started on the alternate CD?
<twb> Maybe I should be doing whatever it's doing
<mantiena> twb: simply press enter
<twb> mantiena: I don't understand.
<mantiena> twb: to start installation with alternate CD simply press enter
<twb> I think you misunderstand.  I'm asking how the program that listens for that enter is launched
<mantiena> twb: sorry, it seems I don't understood you :(
<twb> I'll just download the alternate CD and grovel through it
<iwj> OK, I give up.  Can anyone tell me what writes /etc/ppp/peers/ppp0 if you set up a dialup connection in System Administration / Networking ?
<twb> iwj: pump(8)?  Just a guess./
<iwj> I straced network-admin and it didn't touch the file so presumably there's a wild goose chase of plumbing through daemons I could follow ...
<iwj> pump ?  No, that's definitely not relevant.
<twb> Sorry, I dunno then.
<iwj> I've also grepped the source for gnome-system-tools
<cjwatson> twb: the alternate install CD is its own little Linux distribution
<cjwatson> twb: it's probably not applicable - doesn't use upstart, for a start
<twb> cjwatson: I see; thank you for telling me.
<cjwatson> twb: you probably want the INPUTENTER command in usplash, but I think it didn't work right in Edgy. Ben fixed some things along those lines in Feisty
<twb> Hmm.  Well, I'll try Feisty if this Etch/casper image doesn't DTRT
<cjwatson> hmm, isn't there an upstart knob to avoid stdin being /dev/null?
<twb> I don't know.
<cjwatson> 'console owner', I think
<twb> Ah, OK.
<cjwatson> in the relevant upstart job
<cjwatson> oh, no, sorry, that's stdout and stderr
<mdz> Mithrandir: the compiz patch is not critical for beta, but it's trivial and worth rolling in with other pending uploads
<gpocentek> Mithrandir: does http://tiber.tauware.de/~gauvain/xfce-mcs-plugins.debdiff look sane for an upload?
<twb> Darn.
<twb> See, the persistence thing really needs to run and set up the disk before mysql and apache start.
<cjwatson> honestly, I'd e-mail Scott. ;-)
<gpocentek> cjwatson, mdz, any chance to have a look at bug #88470 and bug #88472 ?
<Ubugtu> Malone bug 88470 in goffice "[UVF]  goffice 0.3.5 -> 0.3.7" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88470
<Ubugtu> Malone bug 88472 in gnumeric "[UVF]  gnumeric 1.7.6 -> 1.7.8" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88472
<gpocentek> I'd like to have them in the beta if possible
<mdz> gpocentek: new upstream versions from experimental would require a solid rationale at the last moment before beta
<mdz> like fixing showstopper bugs
<gpocentek> mdz: we use the experimental packages since edgy, and the new tarballs provide a bunch of bugfixes
<mdz> gpocentek: this should have been uncontroversial at the time when you filed it; the process says to email Tollef and Colin (https://wiki.ubuntu.com/FreezeExceptionProcess)
<mdz> gpocentek: maybe tollef didn't see it because it was filed in launchpad
<gpocentek> mdz: right, I missed that part of the wiki page :/
<ardchoille> I just built a .deb package of Tile World: http://www.muppetlabs.com/~breadbox/software/tworld/  How would I go about getting it added to the repos?
<ogra> ardchoille, ask in #ubuntu-motu :)
<ardchoille> ogra: Thank you :) 
<Riddell> Seveas: the text on the kubuntu usplash is still black on black during the CD self-check
<_ion> Now what's wrong with African-American text on an African-American background? Are you a racist?
<kwwii> Seveas: Riddell just mentioned that the usplash still has black text (on the black bg) during the CD self-check, how can I fix that?
<pitti> kwwii, Seveas: FYI, I applied Seveas' palette patches to usplash-theme-ubuntu and xubuntu-artwork this morning; edubuntu was already applied, I didn't have a patch for Kubuntu
<kwwii> pitti: I think Riddell included it already
<kwwii> I'm fetching the current stuff but it is taking forever :-(
<iwj> Who makes a decision on promotions from multiverse to restricted ?  I take it the requirements are MIR plus additional justification ?
<kwwii> dholbach: did those usplash patches make it into launchpad?
<ogra> kwwii, pitti added them according to feisty-changes 
<ogra> kwwii, this morning ...
<dholbach> kwwii: I don't know when you asked me to change them
<ogra> kwwii, pittis upload which added the patches was usplash-theme-ubuntu_0.13 ... the current ubuntu iso still seems to have the 0.12 version on it
<kwwii> dholbach: I didn't know about it till afterwards... pitti just mentioned that he applied them is all :-)
<kwwii> ogra: I was wondering why I cannot see them in launchpad is all
<heno> kwwii: could you send me some SVGs or PNGs with transparency for the latest Ubuntu/Kubuntu/Edubuntu logos (as used in usplash and GDM)? I should update the winfoss artwork at some point
<kwwii> heno: yepp, I'll do that right away so I don't forget this time :-)
<heno> heh, ok
<heno> thanks
<ogra> kwwii, lots of positive feedback about the edubuntu artwork btw :)
<ogra> people are very imprressed by gdm, usdplash and the gnome splash
<ogra> sigh, and i really need a new keyboard
<kwwii> ogra: cool! good to hear :-)
<keescook> mornin'
<dholbach> hey keescook
<keescook> hiya dholbach!
<pitti> hi keescook 
<keescook> hi pitti!
<geser> hi keescook
<keescook> hiya geser :)
<stratus> ogra: hey
<kwwii> heno: pics sent :-)
<heno> thanks!
<thom> mvo/cjwatson: http://www.stdlib.net/~colmmacc/2005/10/05/the-dos-and-donts-of-software-mirroring/ for something one of my colleagues wrote on the whole random updating thing
<mvo> thom: thanks!
<Seveas> kwwii, has the CD been rebuilt?
<kwwii> Seveas: yes, I think that kubuntu has been rebuilt since the patch went in
<Seveas> kwwii, are you on amd64?
<kwwii> Riddell mentioned the problem to me, but I am not sure what I can do about it - the entries look good as they are I think
<kwwii> Seveas: nope, i386...but I did not have the problem :-)
* kwwii runs to the store before the snow gets too deep
<Seveas> ah
<Riddell> Seveas: this is today's CD
<Seveas> Riddell, which resolution does the CD check use?
<Riddell> Seveas: I've no idea
<Riddell> Seveas: I also got it on the reboot message
<pitti> mvo: can you please actually upload update-manager-core for bug 92875, so that I have something to accept? :)
<Ubugtu> Malone bug 92875 in update-manager "Server upgrade tool needs backported update-manager-core" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92875
<mvo> pitti: Subject: update-manager-core_0.56~edgy1_source.changes is NEW
<mvo> pitti: :)
<pitti> mvo: ah, I see
<Tonio_> dholbach: since it is a uvf exception should I 1ubuntu1 the package ?
<mvo> pitti: thanks a lot for the fast reaction on this!
<dholbach> Tonio_: no, syncing is fine, just needs uvf approval
<Tonio_> okay
<pitti> siretart: ping
<siretart> pitti: yes?
<pitti> siretart: I see two libaqbanking uploads from you
<pitti> siretart: (in edgy-proposed)
<Seveas> Riddell, my laptop crashed testing usplash. Could you please repeat what you said after 'I also get it during reboot'?
<siretart> pitti: yes, Mithrandir told me to reupload, because I used a wrong versioning scheme in the first run
<pitti> siretart: but (a) it contains unrelated changes in debian/control which are not suitable for edgy, and (b) this should be 3build1, not 3ubuntu1 -- it has no source modifications after all
<siretart> pitti: oddly, both didn't show up in ubuntu/edgy/+queue
<pitti> siretart: or 3build1~prop1 for -proposed and -3build1 for -updates
<siretart> pitti: yes, a rebuild of the package fixes the reported segfaults. at least on my test system
<Seveas> Riddell, I just tested it, nice blue text on black background here
<siretart> pitti: ok. I'll reupload then with the issues fixed
<pitti> siretart: danke
<pitti> siretart: (please use edgy's dpkg; we didn't test XSBC-Original-Maintainer with the Edgy package tools)
<pitti> would be too bad to have adept, aptitude or whatever stumble over an unknown field
<siretart> oh
<siretart> okay. willdo
<pitti> which they probably won't, but let's be paranoid for stables :)
<siretart> this should be documented then on the wiki
<pitti> it is
<siretart> oh
* siretart sucks
<pitti> 'make no unrelated changes' or so
<pitti> siretart: no, it's great to have people care about stables, I just want to direct their efforts a bit :)
<siretart> :)
<pitti> mvo: u-m-core is Section: admin in edgy/NEW and gnome in feisty; I take it that it should be changed to admin in feisty as well?
<Riddell> Seveas: I didn't say anything after
<pitti> mvo: also, will you eventually split the source in feisty as well?
<Riddell> Seveas: how do I test it?
<Seveas> Riddell, in the usplash source there's a usplash-test.sh
<Seveas> sudo ./usplash-test.ch -v
<Seveas> the -v is for verbose - with text :)
<tsmithe> hi: i'm waiting on enblend and wired in NEW, which have been there since (before) FeatureFreeze. how likely is it that they will be in? UbuntuStudio would really appreciate it if they were. i'm assuming that since they were uploaded before the freeze took place, we won't need an exception. am i right?
<siretart> pitti: (re)uploaded
<Riddell> Seveas: when I do that the text on the left is a very dark green, near black
<pitti> siretart: beautiful; accepted
<Seveas> Riddell, which architecture?
<Riddell> Seveas: i386 and amd64
<Riddell> Seveas: can you send me your usplash-theme-kubuntu.c again
<Seveas> sure
<mvo> pitti: yes, it should be changed in feisty as well. I don't think I will split the source in feisty
<siretart> pitti: w00t :)
<pitti> mvo: update-manager-core/main/gnome/OPTIONAL' binary overridden in feisty/i386
<pitti> mvo: (to 'admin')
<Seveas> Riddell, sent to jriddell@u.c
<mvo> pitti: thanks
<stratus> ogra: http://people.debian.org/~stratus/bzr/stratus-ltspfs/
<stratus> ogra: feedback is appreciated.
<keescook> Mithrandir: should I open a bug for the libwpd feisty UVF/Beta exception that doko also emailed about?
<j-b> Hello !
<j-b> I am looking for someone from the TOMU Team
<j-b> MOTU Media it is /D
<LaserJock> j-b: the #ubuntu-motu channel would be the place to ask
<j-b> LaserJock: thanks
<ogra> stratus, looks cool, my problem is that my usbfloppy isnt liked by the kernel, so i can hardly test it ... i'll oook deeper into it after beta is out ...
<stratus> ogra: np, i've carefully tested that. I'm sure there's a set of usbfloppies supported
<stratus> ogra: at least those who identify itself as floppy
<stratus> ogra: the other hunk not related with the udev rules is needed for the floppy icon and a sane device naming scheme
<ogra> mine does, but the kernel gets into an endless loop and adds floppies over and over until i unplug
<ogra> stratus, also make sure sbalneav takes a look at it to make sure there is nothing clashing, he implemented all the other floppy stuff 
<stratus> it has the interface attribute declaredas floppy?
<stratus> s/declaredas/declared as/
<ogra> it just checks if a device is fd(n)
<stratus> isn't him subscribed to pkg-ltsp-devel? I've filed a wishlist bug with that information since vagrantc asked me to do so
<ogra> i dont think he is ... 
<ogra> ping him in #edubuntu or #ltsp  :)
<stratus> :)
<stratus> about the device check, do you check only if it's fd yeah but I've introduced the interface attribute check for usb floppies
<stratus> usb floppies also use sd* devices like usb (block) stuff
<ogra> yep
<ogra> i just want to be sure we dont clash with the finally resulting floppy device ... i.e. if you have a builtin floppy and put in a usb floppy as well (for copying or whatever)
<ogra> anyway, i have to vanish again, bbl
<stratus> ogra: impossible to clash since usbfloppies are floppy<letter> (sd*) and regular floppies are floppy<number> (fd*)
<stratus> ogra: see you.
<cjwatson> Riddell: is there a way to create a named QHBoxLayout (or equivalent) in qt4 designer?
<cjwatson> Riddell: I can't get it to stick - even if I edit a name into the .ui by hand, designer removes it again
<cjwatson> and it replaced <widget class="QWidget" name="foo"><layout class="HBoxLayout">...</layout></widget> with just <layout>...</layout>
<cjwatson> I just want to have an empty box I can fill up in code later
<Riddell> cjwatson: it doesn't seem to like doing that, you need to create a named QFrame and create the layout at run time
<cjwatson> oh, a frame, ok
<cjwatson> I can't decide whether I dislike glade-3 or designer-qt4 more
<cjwatson> or maybe a named QWidget, I guess
<Riddell> the UI styles of glade and designer have swapped around with the new versions
<Riddell> yes, a QWidget is fine too
<cjwatson> heh, yeah, I noticed that
<cjwatson> I think I prefer old-designer / new-glade
<twb> What packages provide upstart jobs?
<Riddell> the lots of windows style would be better if window managers could handle raising and hiding all windows at once
<twb> Riddell: they can't?
<cjwatson> twb: I don't think any do yet
<cjwatson> replacement-initscripts got deferred
<twb> (map raise (windows (current-screen)))
<twb> cjwatson: presumably only the sysvinit compat package, then
<cjwatson> $ dlocate /etc/event.d/ | cut -d: -f1 | sort -u
<cjwatson> system-services
<cjwatson> upstart
<cjwatson> upstart-compat-sysv
<cjwatson> upstart-logd
<cjwatson> Riddell: (I'm trying to fix a few infelicities in the ubiquity KDE advanced partitioner before beta)
<Riddell> cjwatson: let me know if you need me to test anything
<Riddell> cjwatson: the new oem-installer works (and looks) great
<twb> I was impressed to discover that Debian have a graphical (GTK2-based) installer that fits on a 30MB install CD
<cjwatson> Riddell: thanks
<cjwatson> twb: yeah, we went down that road for some time before starting with ubiquity (I was fairly involved in it for a bit) but eventually decided that it just wasn't possible to get that type of generated UI working as well as a custom-designed one
<cjwatson> twb: we may yet include it as an option, though personally I still think it's pretty roug
<twb> "generated"?
<cjwatson> rough
<cjwatson> all d-i UIs work by having client code (confmodules) send commands to a debconf implementation using the debconf protocol, and then having debconf work out what sort of UI it thinks needs to be displayed based on the questions that have been asked
<cjwatson> so rather than the UI being laid out by hand, debconf says "oh, you want to ask two string questions and a boolean question, ok, *splat*"
<cjwatson> it's functional, and pretty efficient in terms of code reuse, but it doesn't tend to look great
<twb> It does make things significantly easier for highly distributed, modular maintenance.
<twb> Right.
<cjwatson> to do it properly, you need to go through and write plugins for the common UI elements, like the partitioner
<cjwatson> but nobody has done that yet, and there are still some little bits of infrastructure needed (implementation of Debconf-Frontend field for udebs in libd-i)
<LaserJock> cjwatson: does ubiquity have enough modularity for downstreams to add their own "pages"?
<cjwatson> LaserJock: not easily, although I consider that a bug
<cjwatson> you could do it, but you'd have to hack the frontends very carefully :(
<LaserJock> how's the installer team going?
<cjwatson> d-i's a lot easier and more stable for that kind of thing
<cjwatson> couple of contributors, though not nearly as big as I'd like
<LaserJock> I wish I had more time and knowledge for that kind of thing
<LaserJock> it's pretty fascinating
<twb> Looks like there is not upstart equivalent of dh_installinit yet.
<cjwatson> twb: fwiw, ubiquity does use a fair bit of d-i code - I definitely want to take advantage of collaborative maintenance where I can
<twb> Suppose, say, apache was started by an event.d instead of an init.d job.  How would the sysadmin say "don't start apache on boot"?  What's the equivalent of update-rc.d or rcconf?
<_ion> Currently commenting the line 'start on ...' in /etc/event.d/apache, but AFAIK some kind of "profiles" support is being planned.
<twb> OK, so it's coming but not yet here.
<_ion> twb: http://upstart.ubuntu.com/wiki/Profiles
<cjwatson> LaserJock: as far as knowledge goes, I'm happy to help new folks out in their areas of interest
<twb> In debian/rules, how can I tell if the target system is Ubuntu vs. Debian?
<twb> BUILD_SYSTEM?
<twb> Oh, lsb_release --short --id
<twb> (looking through the casper diff.gz)
<Riddell> Seveas: I changed the text forground colour to the same as the success colour, that fixes it fine
<Riddell> Mithrandir: new kubuntu-default-settings uploaded for usplash text colour problem
<Seveas> Riddell, odd but if that fixes it: great!
<twb> Is there an Emacs major mode for editing event.d files?
<Mithrandir> gpocentek: yes, I believe so.
<spike> I've had a look at launchpad but couldnt find anything similar so I'm referring to the debian bug, which I'm experiencing on feisty: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411949
<Ubugtu> Debian bug 411949 in nvidia-kernel-source "nvidia-kernel-source: Version fails to build using linux-image-2.6.20-1-k7" [Normal,Open]  
<spike> hopefully someone can point me in the right direction to get that working
<spike> uhm, wow
<spike> I'm rolling my own kernel, dunno if that matters
<spike> but the error is exactly the same
<Burgwork> spike: you get the error with a stock kernel?
<Mithrandir> Riddell: I'll take a look, thanks.
<spike> Burgwork: nope, I'm rolling one from vanilla kernels 'cause there's a problem with stock kernels and wifi stack
<spike> Burgwork: it seems that disabling paravirtualization supports does the job,I dont really need it on this box
<Burgwork> spike: if you are using a vanilla kernel, it is bug that goes there, not in LP
<mjg59> spike: If you're building vanilla kernels, you're on your own
<mjg59> Well, to be honest, if you're rebuilding anything you're pretty much on your own
<spike> fair enough, being the same problem also happening on stock kernels I thought I could ask in here. anyway, nm. ta for the input
<Burgwork> spike: we barely have time for stock bugs, let alone wierd stuff like that
<spike> agree, again, fair point no probs
<twb> cjwatson: I worked out a dirty hack to let my init.d script talk to the user
<twb> cjwatson: sed --in-place "1iconsole output" /etc/event.d/rcS
<twb> cjwatson: I'll just stick with that until replacement-initscripts has been actioned
<markoa> Who can I talk to regarding a SoC idea?
<markoa> The one at https://wiki.ubuntu.com/MultipleComputersSynchronization
<bluefoxicy> man.
<bluefoxicy> hal.pp.fishpool.fi what the hell is this
<mjg59> A hostname
<bluefoxicy> I'm showing afs3-fileserver port 7000 connections to this server constantly in ntop, from my ubuntu machine.  (ntop is showing me a LOT of strange activity)
<mjg59> Uh.
<mjg59> 7000 is usually IRC.
<bluefoxicy> well I'm not connected to any irc servers on port 7000
<mjg59> Well, it's an IRC server.
<mjg59> Connected to hal.pp.fishpool.fi.
<mjg59> Escape character is '^] '.
<mjg59> :damocles.esper.net NOTICE AUTH :*** Looking up your hostname...
<mjg59> Anything else is your problem.
<bluefoxicy> hmm
<bluefoxicy> nods.  I've still not figured out this google-analytics thing either but that's probably built-in firefox spyware.
<Mithrandir> no, it's not.
<bluefoxicy> firefox says connecting to google-analytics a lot :/  has google taken over the internet while I was /away?
<mjg59> ...
<Mithrandir> bluefoxicy: you could, like, google for google analytics?
<Mithrandir> Riddell: why are you shipping backup files in the kubuntu-default-settings source package??
<Mithrandir> s/.$//
<cjwatson> bluefoxicy: and moreover you appear to be connected to espernet, so ...
<cjwatson> (different nick, but my second guess was correct)
<bluefoxicy> cjwatson: nods, I probably set it to connect on 7000 some time 1000 years ago and don't remember.  The host name and ntop's afs3 thing was throwing me off.  I've got connections out on tons of weird ports, but I'm guessing it may be Web scripts like google-analytics contacting http://someserver:3814/ or such.
<_ion> % getent hosts irc.esper.net | while read ipaddr host; do getent hosts "$ipaddr"; done
<_ion> 213.157.66.81   hal.pp.fishpool.fi
<bluefoxicy> I guess it's not Ubuntu, but just the Internet that has all kinds of weird connections on it
<cjwatson> bluefoxicy: I'd suggest panicking less, as a general rule
<bluefoxicy> I'm probing, not panicking.  There's a hole in my knowledge of wtf's going on.
<cjwatson> don't probe on #ubuntu-devel.
<cjwatson> going "what the hell is this" on the development channel for your operating system constitutes panicking.
<bddebian> What about probing bluefoxicy on -devel? :-)
<cjwatson> I'd rather not, thanks all the same
<bddebian> :-)
<markoa> Er is there anyone here who's a potential mentor for SoC, or coordinator... or am I asking on the wrong place?
<Mithrandir> markoa: yes, there are several people in here who have signed up as mentors.
<Burgwork> markoa: what is your specific question about mentoring?>
<LaserJock> we seem kinda light on projects? didn't we have a lot more last year? or am I remembering wrong
<markoa> Burgwork, not really about mentoring... I'm looking for someone to ask/talk to about the file synchronization and sharing proposal? Is that of higher priority anyway, because I it seems to me that the people subscribed to the launchpad spec are "just" packagers / ...?
<ajmitch> LaserJock: light on suggestions, you mean?
<LaserJock> ajmitch: yeah
<ajmitch> I suspect that people think the list of suggestions is fixed, and shouldn't be added to
<ajmitch> or something like that
<Burgwork> yep
<LaserJock> looks like we had 83 last year
<ajmitch> grab a few ideas from last year then
<bhale> hi
<Burgwork> bhale: !
<bhale> Burgwork: duder
<ajmitch> hello bhale 
<Burgwork> markoa: are you looking to add ideas or be mentored
<Burgwork> ?
<markoa> Burgwork, discuss that idea, as in to set the scope and goals clearly... and hopefully be mentored.
<Burgwork> ah
<Burgwork> you can edit the idea/spec on the wiki
<markoa> someone, a potential mentor, would respond somehow?
<twb> Failed to fetch http://apt-proxy:9999/ubuntu-security/dists/edgy-security/main/binary-i386/Packages.bz2  MD5Sum mismatch
<twb> That error is the bane of my existence.
* twb kicks apt-proxy.
<keescook> twb: apt-proxy is a disaster.
<twb> Yeah.
<keescook> I just use squid.  :P  it's better than nothing.  :)
<ajmitch> keescook: and yet I persist in using it for some reason
<twb> The author of apt-cache is at my local LUV, he always goes on about it
<keescook> ajmitch: you're special!  :)
<ajmitch> keescook: very spethial
<Mithrandir> I just use a fast DSL, but that solution might not work for everybody..
<keescook> Mithrandir: heheh
<ajmitch> Mithrandir: not when some of us have a 30GB monthly data cap
<twb> Mithrandir: I'm repeatedly installing the same package over and over, because I'm building live cds
<Mithrandir> twb: then I'd have a local mirror, but that might just be me.
<twb> So e.g. apache2 might be installed a dozen times in one day.
<keescook> Mithrandir: there are a few big fixes in the delta between unstable and feisty atm.  They're mostly crash fixes (and translations), but I'd love it if we could get a sync.  is there any chance of that?
<twb> Mithrandir: well yes, but there's no need for a FULL local mirror.  apt-proxy mirrors stuff on an as-needed basis.
<keescook> Mithrandir: (in mysql)
<twb> keescook: in what pa- ah
<Mithrandir> keescook: oh, that's main, post-beta at least?
<keescook> Mithrandir: that'd be fine; I just want to make sure it doesn't get lost.  Should I open a bug and mile-stone it to 7.04?
<Mithrandir> keescook: yes, please.
<Mithrandir> and please paste a bit of the irc conversation so I don't go "huh?" in a week.  Or just add the rationale.
<markoa> Guys ah one more question... I sent an application to GNOME. It's a proposal for a new program. I'm not sure how appropriate that was actually. A metadata-based document browser... I think it is something which would be very useful to all users. Would Ubuntu consider such an application as a possible SoC project perhaps?
<sneakums> markoa: have you seen http://www.gnome.org/projects/tracker/ - i think it's slated for inclusion in gnome 2.20
<Burgwork> markoa: got a link to the spec?
<Burgwork> sneakums: tracker is very very iffy
<sneakums> iffier than beagle?
<Burgwork> sneakums: tracker does less and uses less
<markoa> here it is: http://marko.anastasov.name/docs/document_browser_gsoc_proposal.pdf
<markoa> sneakums, yes it would be based on Tracker
<Mithrandir> markoa: I'd be at least happy to look at proposals for the "automatic synchronisation of folders" idea.
<markoa> Mithrandir, I'm the author of USBSink (http://usbsink.sourceforge.net), so I have some experience about this...
<Burgwork> markoa: I would look into conduit
<Burgwork> http://www.conduit-project.org/
<Mithrandir> Burgwork: IMO, tying it to a desktop is very wrong.
<_ion> "Does less"? Tracker has this whole concept of functioning as a generic metadata database for applications.
<Mithrandir> (I'd want to use something like it for publishing images, for instance.)
<markoa> Burgwork, I understand conduit as a program mainly for specific types of data, such as bookmarks etc
<Burgwork> _ion: tracker is mostly a bunch of useless marketing words strung together. Tell me that when it actually does stuiff
<Burgwork> Mithrandir: fair enough. But integration into the desktop is also nice
<Mithrandir> Burgwork: oh, sure, integration is nice too, but it needs to work from the command line too.
<Burgwork> Mithrandir: depends entirely on your goals. conduits goals are to provide a graphically easy way to connect disparate data sources
<_ion> burgwork: Well, it has done stuff for ages, but support for it needs to be added to applications.
<markoa> Burgwork, tracker is not really supposed to do stuff, but to provide means for applications
<Burgwork> _ion: if tracker actually does stuff, then somebody needs to tell jamie to market it that way
<_ion> You could say the same about PostgreSQL, until someone writes a program that uses PostgreSQL.
<Burgwork> lots of people are rather annoyed with Jamie's inability to actually say "Tracker does X"
<_ion> "A bunch of useless marketing words strung together. It doesn't do stuff."
<Burgwork> I could point you at the huge thread about tracker, with jamie constantly saying the same junk about metadata
<Burgwork> rather than "I can categorize albums easier" or "I can find stuff easier"
<markoa> hm yeah on d-d-l... it was quite early, there were no applications yet, true
<_ion> So tracker sucks because you feel its main author doesn't express himself the way you'd prefer.
<_ion> The actual code doesn't matter, of course.
<sladen> kwwii: I love the new OOo orangified splash
<kwwii> sladen: thanks :-)
<Mithrandir> Burgwork: does conduit do many-many-synchronisation or just two-way?
<LaserJock> me two
<LaserJock> too
<Lure> kwwii: will we get blue OOo splash for Kubuntu?
<markoa> Mithrandir, condiut can do one-to-many synchronization
<kwwii> Lure: I have one done, if we can use it (not sure if it is possible to use two different splash's)
<Burgwork> Mithrandir: I am not entirely certain
<Lure> kwwii: yep, this might be an issue - there is -kde package, not sure if splash can be customized there
<kwwii> Lure: if someone looks into the technical part it is ready :-)
<Lure> kwwii: I am not sure if I am brave enough to build OOo myself ;-)
<kwwii> ;-)
<LaserJock> Lure: don't think you want to stretch your newly minted MOTU wings on OOo? ;-)
<Mithrandir> Lure: running debian/rules clean only takes a bit more time than a full apache2 build.  It's not that bad.
<jdong> keescook: ping, oh great security overlord
<Lure> Mithrandir: ;-)
<keescook> jdong: :) pong, sup?
<jdong> keescook: what's the status of clamav in our supported distros?
<Mithrandir> Lure: seriously though, the ooo build system is big and a bit scary, but it's quite neat when you get to know it.
<jdong> keescook: there seems to be some unrest in bugs like bug 53856...
<Ubugtu> Malone bug 53856 in clamav "ClamAV-Daemon Out of date" [Undecided,Confirmed]  https://launchpad.net/bugs/53856
<jdong> are there any outstanding vulns, etc?
<keescook> jdong: yeah, I outlined the state of clamav on u-devel last week, I think.
<jdong> ah, ok
<Lure> Mithrandir: I still recall doko's t-shirt from uds-mtv: I build OOo, do you? ;-)
<keescook> there might be one outstanding vuln; I haven't checked.
<Mithrandir> Lure: heh.  I did build it on my laptop in Mataro, actually.  It only took about 12-ish hours, iirc.
<Nafallo> "only" ;-)
<Nafallo> hi all :-)
<ajmitch> hello Nafallo 
<Mithrandir> Nafallo: yes, and this was 1.x.
<keescook> jdong: ah! it was on u-motu: https://lists.ubuntu.com/archives/ubuntu-motu/2007-March/001440.html
<Nafallo> :-)
<markoa> Has anyone read the proposal linked above? Does it make sense as a Ubuntu project?
<jdong> keescook: ok, thanks, that answers most of my questions :)
<keescook> jdong: great; let me know if have any other questions about it.  I'd love to see the library-tester thingy I mention; with that I'd likely start doing full-version updates.
<jdong> keescook: that thing sounds like heaven; Backports would benefit greatly from such a tool too
<ajmitch> keescook: what does this tester do? check for ABI changes?
<keescook> ajmitch: yeah, that'd be the goal; I'm sure something like this exists, I just haven't had the time to dig it up.
<markoa> Mithrandir, my doubts regarding the file sync idea are whether it is supposed to work only over a local network?
<Mithrandir> markoa: I'd want it to work primarily over a local network, yes.
<Mithrandir> (but with possibility for disconnected operations, for instance)
<markoa> Mithrandir, ok, because the wiki also includes use cases about global transfers.
<markoa> Mithrandir, disconnected operations?
<Mithrandir> markoa: as in, I want to be able to add a file, remove another, change a third when I'm on a plane, then log onto my workstation do some other changes there and stuff should Just Work when I plug my laptop into the network.
<Riddell> kwwii: doko may know if it's possible to have an openoffice kde splash
<markoa> Mithrandir, I see.
<jdong> Mithrandir: can I ask for a quick backport of KTorrent Feisty to Edgy and Dapper to close the security vulnerability in the backports version of KTorrent?
<jdong> (the main version already has security fix; this is solely for the backports repo users)
<Mithrandir> jdong: bug #?
<jdong> Mithrandir: bug 91174
<Ubugtu> Malone bug 91174 in edgy-backports "KTorrent security issue with releases <2.1.2 (Breezy - Feisty)" [Undecided,In progress]  https://launchpad.net/bugs/91174
<Mithrandir> jdong: I'll do it in the morning, it's midnight here now.
<jdong> ok, sure
<YokoZar> Could someone tell me the current version of libgphoto2-2 in Edgy?  I'm having users complain that I built my Wine package with a version newer than the one they have (so they can't upgrade), but I haven't messed with anything to my knowledge.  Was a newer libgphoto2-2 backported recently?
<jdong> YokoZar: yikes, yeah a new one was backported recently
<jdong> YokoZar: you should build your wine in a clean pbuilder without backports enabled
<YokoZar> jdong: hmm...where can I do that?
<jdong> YokoZar: non-backports package I pretty much guarantee/QA to work with a backports system.... the same cannot be said in reverse
<jdong> YokoZar: there's a good pbuilder howto on the wiki
<jdong> https://wiki.ubuntu.com/PbuilderHowto
#ubuntu-devel 2007-03-20
<YokoZar> jdong: thanks.  Guess I'll have to not expect my users to have backports
<jdong> YokoZar: right; not everyone has backports on :)
<YokoZar> jdong: but everyone does have Wine on ;)
<jdong> YokoZar: maybe in your little world :) in mine everyone has backports on :)
<mage___> anyone want to explain the whole restricted modules are in a tmpfs thing?
<mjg59> They're linked on startup
<mage___> but why and where?
<mjg59> /etc/init.d/restricted-modules-common or something similar to that
<mjg59> And to reduce certain licensing issues
<jdong> keescook: would you have any clamav if I object for backporting?
<jdong> whoa
<jdong> that just... made no sense....
<jdong> keescook: nvm, I'm gonna reject it....
<keescook> hahah
* jdong needs sleep
<keescook> :)
<jdong> and..... to double check his essay he finished 10 minutes ago....
<jdong> yikes.
<bluefoxicy> bddebian:  You can try, but I don't have a lot to probe for
<jamesh> doko_: ping?
<mage___> does the automatic mounting of nfs require anything in /var or /usr? 
<mage___> to get around my nfs shares in /etc/fstab not being mounted I'm mounting them in /etc/init.d/waitnfs.sh :)
<mneptok> exit
<mneptok> nihpitoa
<ajmitch> mneptok!
<mneptok> ajmitch!
<doko_> jamesh: pong
<jamesh> doko: Do you handle the subversion packages?
<doko> jamesh: not really; just changed the python-subversion binary; infinity would be more appropriate. but if it's a small change ...
<jamesh> doko: I found a crasher bug in the python-subversion package in feisty
<jamesh> bug 91848
<Ubugtu> Malone bug 91848 in subversion "segfault when importing libsvn.wc in python 2.4 on feisty/amd64" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91848
<doko> which is not seen with 2.5?
<jamesh> correct
<jamesh> not seen on i386 either
<jamesh> doko: I hit it when doing Launchpad development on my desktop machine
<RAOF> I should go confirm that bug, I can reproduce it on my amd64 laptop.
<jamesh> I've got the stack trace and relevant bits of a valgrind log
<jamesh> doko: If you have a chance to look at the bug, it would be greatly appreciated
<doko> jamesh: works in debian/experimental with 1.4.3, however a merged package on ubuntu feisty shows the same segfault (http://people.ubuntu.com/~doko/tmp/)
<jamesh> doko: does the valgrind log help?
<jamesh> doko: I know that some function signatures were changed between python 2.4 and 2.5 w.r.t. lengths (using longs instead of ints)
<jamesh> might the 2.4 modules be using the signatures expected by the 2.5 API?
<doko> jamesh: yes, but those should all use Py_ssize_t now
<jamesh> doko: there is no Py_ssize_t in 2.4, is there?
<doko> correct, but extensions should define that on their own, if they want to be compatible with older python versions. I don't see any restriction that subversion only works with 2.5.
<doko> jamesh: trying to look at it again later this week, not now
<pitti> Good morning
<Hobbsee> pitti!!!!!!!!!!!
* Hobbsee hugs pitti 
* pitti hugs Hobbsee 
<carlos> Riddell: hi, around?
<Hobbsee> :)
* Mithrandir ruffles Hobbsee
<Hobbsee> hiya Mithrandir :)
<Mithrandir> morning, Sarah.
* Mithrandir hopes we can have candidate ISOs before lunch today.
<Hobbsee> Mithrandir: yay!
* Hobbsee still needs to put thru a critical fix for kdepim...argh
<pitti> _ion: ping
<pitti> _ion: unping
<ajmitch> morning pitti, Mithrandir 
<pitti> hey ajmitch 
<ajmitch> hm, someone asking about 'enterprise' ubuntu :)
<pitti> Mithrandir: CD sizes look pretty good; desktop/i386 is on the edge (699 MB), but I guess I won't rip it apart any more unless we actually need the space
<tepsipakki> ajmitch: where?
<ajmitch> tepsipakki: ubuntu-devel-discuss
<tepsipakki> thanks
<Mithrandir> pitti: yay, goodie.
<ajmitch> probably some u-directory stuff
<pbn> Hi there, does sabdfl sometimes answer to queries ? :)
<saispo> hi
<saispo> any ftpmaster admin here ?
<pitti> saispo: yes, some
<saispo> :)
<saispo> a think, file missing in dists/edgy/main/installer-i386/current/images/
<saispo> the file udeb.list
* pitti defers to cjwatson for that
<saispo> argh
<saispo> it's my rsync :/
<saispo> excuse me
<Mithrandir> in edgy?  That'd be weird.
<Mithrandir> heh, ok
<saispo> not in feisty, excuse me :)
<saispo> i relaunch my rsync :)
<saispo> thanks
<giftnudel> it's always interesting how you find an error just by telling someone what goes wrong ...
<pitti> Mithrandir: still time for getting some easy patches in? http://pastebin.ca/403334
<pitti> Mithrandir: can I put the edgy/dapper proposed langpacks into -updates or do you need free buildds in the next few hours?
<Mithrandir> pitti: langpacks> what is the typical per-pack build time?
<Mithrandir> pitti: and no, stuff on the CD is locked down now.
<pitti> Mithrandir: langpacks> trivial, some seconds
<pitti> Mithrandir: with the chroot building overhead, probably a minute or soo
<Mithrandir> ok, then just go ahead, I'll just bump the priority if I need something through in the middle
<pitti> Mithrandir: it's the sheer number of them which make it ugly
<pitti> ok
<pitti> oh, argh, I need to wait until the current daily packages finished building, so I'll do it after lunch
<dam_ned> hi all
<dam_ned> I am looking for information on how to handle a bug when I do not agreee with the maintainer...
<dam_ned> I checked the wiki but could not find information on that
<Mithrandir> dam_ned: which bug is this?
<dam_ned> bug 47827
<Ubugtu> Malone bug 47827 in vmware-player "vmware-player lintian warnings" [Medium,Rejected]  https://launchpad.net/bugs/47827
<dam_ned> Mithrandir: bug 47827
<Mithrandir> hm, I'd probably just ignore it, they have a reasonable argument for why they need it that way, but if you really, really feel the bug should be fixed, I guess you could escalate it to the technical board.
<Mithrandir> I don't think the bug is important enough that that is warranted, though.
<dam_ned> Mithrandir: it is indeed just a qa thing, I know in Debian these bugs should not just be closed, but I cannot find the Ubuntu policy on this
<dam_ned> what is the procedure to escalate?
<Mithrandir> mail technical-board@lists.ubuntu.com
<dam_ned> putting it on the agenda? (it would be nice if the bug could be assigned to them :))
<dam_ned> aha
<cjwatson> dam_ned: I've replied to this bug. I think it should be ignored.
<cjwatson> and I think rejecting it is just fine
<cjwatson> lintian warnings require thought, not automated action
<tepsipakki> can someone explain why the livecd-session gets a wrong resolution compared to running 'sudo xresprobe $DRIVER' when the session is up?`(bug #93996)
<Ubugtu> Malone bug 93996 in xorg "[Feisty]  Samsung SyncMaster 712N Monitor not detected, available resolutions too low, HorizSync and VertRefresh wrong" [Undecided,Needs info]  https://launchpad.net/bugs/93996
<tepsipakki> as if something is missing when casper configures X
<dam_ned> cjwatson: ok, you decide :)
<dam_ned> if it was my distribution, I would leave it as a low priority bug to handle it later 
<cjwatson> dam_ned: I'm not tech board, just an ornery developer
<cjwatson> if it should be handled at all, I think it should be by adding a lintian override
<cjwatson> or possibly by removing that bloody stupid warning from lintian. :-)
<dam_ned> heh
<cjwatson> (well, possibly downgrading it to info)
<dam_ned> depends on how strict you interpret the FHS
<cjwatson> it's not clear to me that anyone actually runs systems like that on Debian/Ubuntu anyway
<Mithrandir> tepsipakki: either because /dev isn't mounted or because it's running under usplash.
<dholbach> hellas
<cjwatson> you would have to take great care to keep all versions exactly in sync, because we certainly don't remotely guarantee that you can mix and match /usr/share and everything-else from different versions of the same package
<dam_ned> good remark
<dam_ned> but why do we have the FHS then ..
<cjwatson> the FHS covers a lot of other situations
<cjwatson> many of its recommendations do make sense
<dam_ned> I was just wondering what the Ubuntu policy is
<cjwatson> in any case there's no "must" in its discussion of /usr/share
<dam_ned> no hard feelings :)
<cjwatson> "be sensible"
<cjwatson> we recommend thinking about bugs :-)
<dam_ned> hehe
<cjwatson> I would say that in general you are correct: bugs should not be rejected just because they aren't going to be dealt with yet
<cjwatson> but I think if a bug really isn't important, then it's not worth worrying about its status
<cjwatson> however, that's just my personal opinion, and I think the handling of unimportant bugs should generally be left to the responsible developers
<cjwatson> dam_ned: I'm going to file a bug against lintian about this
<dam_ned> ah ok
<dam_ned> I am interested to track that one, so please subscribe me :)
<cjwatson> dam_ned: I can't; I'll be filing it in Debian, where the lintian maintainers will actually read it
<dam_ned> hmm, you probably mean in Debian :)
<dam_ned> I will track it myself then..
<cjwatson> I'll cc you so you get the bug number
<dam_ned> thanks!
<tepsipakki> Mithrandir: ok, I remember that there was some talk about mounting /dev..
<Mithrandir> tepsipakki: there was, but nobody did the change needed for it
<tepsipakki> Mithrandir: post-beta, perhaps?
<Mithrandir> yes
<fabbione> who is running latest feisty on i386?
<fabbione> i need somebody to confirm a bug
<tepsipakki> I am
<fabbione> it's a very simple strace test
* Fujitsu puts his hand up.
<fabbione> strace -o foo /bin/ls
<fabbione> and see if you notice:
<fabbione> umovestr: Input/output error
<fabbione> or similar errors
<Fujitsu> Yep.
<Fujitsu> Same one.
<fabbione> ok thanks
<fabbione> pitti: ^^ what do you think? kernel or strace?
<tepsipakki> same here
<pitti> fabbione: no idea really ;(
<fabbione> pitti: can you reproduce it on amd64?
<pitti> fabbione: no, works fine, as I said
<fabbione> oh o
<fabbione> ok
<fabbione> so this is arch specific i think
<fabbione> on ia64 it crashes the entire machine with a watchdog timeout
* pitti tries on ppc
<Fujitsu> fabbione: Niiiice.
<Fujitsu> Yet it outputs the file fine...
<maswan> fabbione: please don't break oprofile and systemtap while fixing that bug, if you can. I just got to the point where both of them are working. ;)
<fabbione> maswan: i am not going to fix anything.. i just need to report it
<Seveas> fabbione, I don't see that error with the second-to-latest kernel
<fabbione> Seveas: you mean .20-10 ?
<Seveas> 20-11
<Seveas> but there's an upgrade waiting according to update-manager :)
<fabbione> latest is .12
<fabbione> -12 i mean
<Seveas> let's upgrade and see what happens
<Fujitsu> fabbione: Thus 20-11 is second-to-latest.
<fabbione> ok
<Riddell> carlos: pong
<carlos> Riddell: do you know whether KDE project has translations for desktop_kmplayer.pot? I don't see anyone being imported and I wonder whether it's something used only by Ubuntu
<saispo> seb128: hi :)
<carlos> mvo: ping
<mvo> hello carlos
<carlos> mvo: hi
<carlos> mvo: is update-manager obsolete ?
<mvo> carlos: no, why? 
<carlos> I have seen update-manager.pot inside another package
<carlos> that seems to replace update-manager
<mvo> carlos: inside update-manager-core?
<stephanbuys> hi there. does anyone know if there is a pygtk binding for the Gnome File Dialog? perhaps a reference to some code showing it? 
<carlos> mvo: hmm, I think it was another name, let me check..
<Riddell> carlos: looks like I need to add that to my list of ones to download
<Seveas> stephanbuys, this channel is for development OF ubuntu, not developing ON ubuntu
<giftnudel> stephanbuys: isn't that gtk.filechooser?
<carlos> Riddell: ok, thank you
<stephanbuys> Seveas, apologies
<giftnudel> stephanbuys: but you would be better of in #pygtk on irc.gimp.net ;)
<stephanbuys> giftnudel, thanks for the tip and the advice - will check it out. (btw gtk.filechooser is a GTK file dialog, but doesn't seem to be the standard Gnome one)
<carlos> mvo: software-properties
<mvo> carlos: oh? that sounds like a bug, I will check/fix
<carlos> mvo: ok, should I import it as software-properties?
<mvo> carlos: yes please
<carlos> mvo: ok
<mvo> carlos: thanks!
* seb128 kicks linux, network card driver bugged again
<carlos> mvo: but it's replacing update-manager, isn't it?
<carlos> mvo: Replaces: update-manager (<< 0.55) from software-properties-gtk
<mvo> carlos: update-manager used to have both software-properties and update-manager in the same source package. this is now split into two source packages
<carlos> oh, I see
<mvo> carlos: it replaces it in the "replaces-some-files-on-the-fs" sense only
<carlos> ok
<viviersf> cjwatson, sorry bout that bug, i found the proper reason for it, im an idiot :/
<cjwatson> viviersf: ok, what was it?
<Seveas> fabbione, no problems with the -12 kernel either (i386)
<viviersf> cjwatson, since it gets installed on a 'build-server' which makes me my cd's, it writes that swap partition into the config, which does not match later on
<carlos> mvo: for Edgy, should I move update-manager translations into update-manager-core?
<cjwatson> viviersf: ah
<mvo> carlos: if "moves" means "copy", then yes please
<carlos> mvo: are both packages valid?
<carlos> mvo: both have the same .pot filename
<carlos> mvo: which means both will conflict
<carlos> mvo: btw, I though we don't add new packages once the final release is done, only updates
<mvo> carlos: this was a exception it is needed for server upgrades with the release upgrader
<mvo> carlos: let me check, there shouldn't be a file conflict
<carlos> mvo: well, update-manager-core has an update-manager.pot file too
<carlos> so either it's exactly the same version as the one in update-manager or there will be conflicts because we can only deploy one of them
<mvo> carlos: please blacklist the one in u-m-core then
<carlos> will it work with current one from update-manager?
<mvo> carlos: it should, its a split from u-m to move the gui independant bits out
<carlos> mvo: if both are different, you should use a different translation domain
<carlos> ok
<carlos> then, it should be enough
<mvo> carlos: right
<Seveas> fabbione, sorry, I didn't look right :/ The strace problem occurs on kernels as old as .20-9 up to and including the latest (don't have older kernels installed, so can't test on those)
<cjwatson> doko: Package: zope3-dbg Depends: python-zope3 (= 3.3.1-0ubuntu2); should that be zope3 rather than python-zope3 (which doesn't exist)?
<doko> cjwatson: yes, will fix it.
<cjwatson> thanks
<cjwatson> doko: your last comment in bug 60063 was "fixed in edgy" - did you forget to change the status?
<Ubugtu> Malone bug 60063 in gst0.10-python "gst-python in edgy installs bogus pygst.py for python2.4" [Medium,Confirmed]  https://launchpad.net/bugs/60063
<iwj> pitti: slmodemd works fine after I added setgroups(0,0); setgid(65534); setgid(65534); setuid(65534); setuid(65534);
<iwj> So all I need to do now is pick a saner uid/gid pair.
<pitti> iwj: yay
<tepsipakki> stupid xserver-xorg, why do you think every owner of Intel 82845 has an Elographic Screen..
<tepsipakki> gah
<pitti> iwj: nice that tty, dialout, and audio are all static groups :)
<pitti> iwj: btw, why do you call setuid()/setgid() twice?
<iwj> I couldn't be bothered to look up the rules about when it sets euid and when it sets ruid.
<pitti> iwj: setuid()/setgid() set all of them
<pitti> iwj: setreuid() sets specific ones
<sladen> pitti: how do we use the retracer?  Subscribe/assign to <apport> in launchpad?  Does it need tagging aswell?
<pitti> sladen: right now you still need DC access, as I wrote on ubuntu-devel
<pitti> sladen: incidentally I just wrote the last building block for an automatic tag-based retracer :)
<pitti> sladen: I'll mail u-devel@ again once it works
<sladen> pitti: fantastic, thanks, I googled the wiki and such, but didn't find the answer, I'll update  wiki.u.c/Apport
<iwj> pitti: Well, I had a superstition about set*uid sometimes needing to be called twice.  Normally I use setre*id and actually look it up ...
<fabbione> Seveas: ok thanks
<pitti> sladen: please don't update it yet, before it's readyy
<sladen> pitti: to update it that it's /not/ ready
<doko> cjwatson: 60063 was fixed, addjusted the status
<pitti> sladen: oh, does it say so?
<sladen> pitti: no, there's a void of information when I went hunting.  I'd prefer to find a definite negative
<pitti> sladen: I guess it can stay like this for another day or so, and then I can just mention how to do it with tags
<iwj> pitti: I think I'll have to create a new dynamic uid since I don't really want to use an existing one.  Or is that too painful to do now and should I use uid nobody (which I think isn't really ideal) ?
<pitti> iwj: dynamic uid is better for a good isolation IMHO, and not too painful either
<pitti> iwj: but using the static group IDs for setgroups() is fine and easy
<cypherbios> hi dholbach, I've noticed that the latest gossip-telepathy package is with unmet dependency... caused by a misspelled in the version number of package libtelepathy2 as follow: The following packages have unmet dependencies:
<cypherbios>   gossip-telepathy: Depends: libtelepathy2 (>= 0.51) but 0.0.51-2 is to be installed
<iwj> It works fine with an empty group list since I put the calls after it has already opened the sound device and made its ioctls and symlinked in /dev and everything.
<dholbach> cypherbios: known bug
<pitti> iwj: aah
<dholbach> cypherbios: I asked for a libtelepathy sync which fixes it - but the archive team is busy with other things atm
<pitti> iwj: I thought that code was binary-only already, but if you can put stuff after open(), then dropping to a private uid and gid provides the best security indeed
<cypherbios> dholbach: ok, thanks... just to be sure that you already know ;)
<iwj> pitti: No, the binary-only code is just some core dsp stuff.
<iwj> Well, I say `just'; there is 1.2Mb of .o but it's pretty isolated.
<pitti> iwj: all the postinst/postrm/getpwent() stuff is quite a lot of overhead, so if this is too intrusive for the current freeze status, then maybe u/gid daemon:daemon is fair enough for feisty as well
<iwj> postrm ?  Surely it's wrong to remove the user/group.
<pitti> iwj: why not? as long as the package doesn't create any files, why not clean up the system user on purge?
<pitti> (it doesn't matter much, of course)
<pitti> iwj: it makes me really happy that this derootification works \o/
<iwj> pitti: If the package is broken in any way then it may leave a leftover file or process or something (think of all the stop scripts that don't quite work properly) and then you'll have those things inherited by whatever gets the new uid.
<cjwatson> pitti: could you merge http://bazaar.launchpad.net/~kamion/langpack-o-matic/depends-fixes, please?
<pitti> cjwatson: oh, of course
<pitti> cjwatson: oh, these ooo packages disappeared?
<cjwatson> apparently so
<cjwatson> checked the archive
<pitti> cjwatson: ok, I'll rebuild the affected l-support packages soon (after the current daily langpack build finished on rookery)
<pitti> cjwatson: thanks
<cjwatson> cheers
<PhinnFort> ping jdong
<PhinnFort> i know what ubuntu needs: http://briefcase.pathfinder.gr/download/areir/26714/315686/0/bsod.jpg
<Keybuk> We actually did one talk about having a pretty kernel panic screen
<Keybuk> however we realised that with our colour scheme, it'd be the Brown Screen of Death
<Mithrandir> Keybuk: with penguins on it?
<Mithrandir> brown penguins wouldn't be nice, I think.
<PhinnFort> make it skinnable
<PhinnFort> maybe use html
<PhinnFort> then you can get <blink> and <marquee> in your kernel panics
<PhinnFort> :D
* Fujitsu uses non-CoC torture methods on PhinnFort.
* PhinnFort saves and takes only half damage
<PhinnFort> oh, wait, i'm a monk, i don't take any damage
<Hobbsee> haha
<Hobbsee> mmm...a picture of somewhere in antarctica would be cool for that :P
<pitti> seb128: yay, malone-crash-digger just retraced the first bug entirely on its own \o/
<seb128> pitti: waouh ;)
<Fujitsu> \o/ pitti 
<seb128> pitti: how does it get its list? tag?
<pitti> seb128: yes, need-{amd64,i386,ppc}-retrace
<seb128> ok
<pitti> seb128: I tested it for amd64 now
* pitti sets up the i386 retracer for this as well
<seb128> ;)
<pitti> seb128: do you have an unretraced i386 crash handy for a test?
<pitti> seb128: there are currently no bugs tagged as need-i386-retrace
<pitti> seb128: the i386 digger is running now, so if you have a crash bug at hand, please add that tag to it
<ajmitch> pitti: yay!
<pitti> amd64 digger now running, too
<Fujitsu> pitti: Will apport do that automatically in the near future?
<seb128> pitti: ok
<pitti> NB that this is still very brittle, if apport-retrace gets stuck, the entire digger does; this still needs timeout detection etc.
<pitti> Fujitsu: yes, it will automatically add the tag, but that needs Malone support
<pitti> Fujitsu: I talked to Bjorn about this; it will happen eventually, but not in the next days
<seb128> pitti: bug #93833
<Ubugtu> Malone bug 93833 in gaim "[apport]  gaim crashed with SIGSEGV in g_cclosure_marshal_VOID__VOID()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93833
<pitti> seb128: watching the log
<pitti> 03/20/07 12:11:00: fill_pool: work pool now: set([] )
<pitti> 03/20/07 12:11:00: work pool empty, sleeping for 30 seconds
<Fujitsu> pitti: Oh yes, I saw that bug.
<pitti> 03/20/07 12:11:32: fill_pool: work pool now: set([93833] )
<pitti> 03/20/07 12:11:32: retracing bug 93833
<pitti> \o/
<seb128> \o/
* seb128 hugs pitti
<pitti> gosh, now I need to teach that thing about speeeeeed
<pitti> uaargh
<pitti> urllib2.HTTPError: HTTP Error 500: Internal Server Error
<pitti> seb128: ^ that thing again for 93833
<pitti> seb128: it's retracing bug 93855 now
<seb128> I got it several times since yesterday
<Ubugtu> Malone bug 93855 in gaim "[apport]  gaim crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93855
<seb128> on different bugs
<pitti> seb128: it currently removes the tag before retracing, to avoid looping on a bug with an error
<seb128> ok
* pitti doesn't have the slightest idea why this happens
<pitti> grr, again a 500
<seb128> :(
<pitti> seb128: so it can successfully request and post /+edit, but not /+addcomment; weird
<seb128> and addcomment seems to work from a browser
<pitti> ok, I'll figure this out with Bjorn, I guess
* pitti sets the inactivity sleep from 30 seconds to 10 minutes to not hammer Malone with bug searches so often
<pitti> seb128: sorry :/
<seb128> pitti: do you know if adding tag on bug filing is being worked on malone already?
<ajmitch> it works for beta
<pitti> seb128: yes, it is, but I don't have an ETA
<StevenK> seb128: There was a message about that on -motu
<StevenK> seb128: What ajmitch said
<ajmitch> not for production yet
<seb128> pitti: no need to be sorry, that's just a detail and not your fault ;)
<StevenK> ajmitch: Aren't you supposed to be sleeping?
<pitti> seb128: do you have an i386 crasher which known-worked from ronne?
<seb128> pitti: does the retrace uses beta?
<pitti> seb128: no, it doesn't
<seb128> pitti: yeah, many of them
<ajmitch> StevenK: it's just after midnight, daylight savings finished here already
<seb128> sec
<pitti> seb128: I don't see why it should, it would only make things slower
<StevenK> ajmitch: Damn timezone changing.
<seb128> pitti: bug #93987
<Ubugtu> Malone bug 93987 in evolution "evolution crashed when trying to view folder subscriptions" [Medium,Confirmed]  https://launchpad.net/bugs/93987
<iwj> pitti: Revised MIR; I've uploaded my new and actually doing-it-sanely version and it works nicely here.
<seb128> pitti: to add retracing tags automatically on bug filling :p
<pitti> seb128: no
<pitti> seb128: that would require the crash *reporter* to be in lp-beta-testers
<Fujitsu> That interface isn't exactly stable either, is it?
<pitti> seb128: and we cannot assume that
<seb128> pitti: ah, right
<seb128> Fujitsu: what interface?
<pitti> seb128: it currently just works with a magic URL, but we want it to specify in the uploaded blob
<_ion> pitti: So, nvidia says in their README, "yo, this list of device IDs is incomplete, look at the following URL for a complete list". Then we use the "complete" list and people say their GPU isn't listed in it. That sucks. :-)
<pitti> _ion: right; I added the two missing ones from the bug reports to bzr head
<Fujitsu> seb128: The ?fields.tag=blah, or whatever it is. That has to stay the same for 18 months at least if apport uses it.
<pitti> seb128: oh, you didn't tag 93987 yet?
<seb128> pitti: it has already been retraced
<pitti> Fujitsu: right, and it's pretty ugly, too, and won't be backported to stable
<seb128> pitti: that's not what you asked for? a bug which retraced fine from ronne?
<pitti> seb128: right, let's just retrace it again for testing
<seb128> ok
<pitti> i. e. add the tag
<seb128> tagging now
<seb128> done
<pitti> iwj: yay
<pitti> seb128: it caught the bug and is grinding away
<seb128> good
<TomaszD> hello, I'm an Ubuntu translator and I need to run restricted-manager GUI to see if everything looks fine, however I don't have restricted hardware so I can't. How can I fool restricted-manager and run it anyway?
<pitti> New attachments uploaded to Launchpad bug 93987
<pitti> 03/20/07 12:28:35: retracing bug 93987 exit status: 0
<pitti> 03/20/07 12:28:37: fill_pool: got new bugs set([] )
<Ubugtu> Malone bug 93987 in evolution "evolution crashed when trying to view folder subscriptions" [Medium,Confirmed]  https://launchpad.net/bugs/93987
<pitti> seb128: yay, seems to have worked
<seb128> pitti: rock on!
<pitti> sladen: ^ see above, there goes your tag-based retracing service; I'll update the wiki/announce to -devel@ after lunch
* pitti leaves for lunch and some errands
<seb128> pitti: have fun
<BenC> Mithrandir: reuploading a grub that uses gcc-3.4
<ajmitch> night all
<Fujitsu> Night ajmitch.
<seb128> 'night ajmitch
<Mithrandir> BenC: cheers
<mvo> Mithrandir: CD content is frozen? if not I would like to do anohter update-manager upload
<heno> mvo: it's frozen, CDs being rolled now
<Mithrandir> mvo: which critical bugs does it fix?
<mvo> Mithrandir: its not critical, its about the CDROM based upgrader that will not update itself from the net (but thats not critical because it will use the version from the CD)
<Riddell> seb128, dholbach: should ubuntu have a wastebin icon on the desktop?
<janimo> gpocentek: hi
<cjwatson> god, ubiquity bugs are such a massive hive of confusion between correlation and causation
<Treenaks> Riddell: I think the rationale for the current situation is "There's a wastebin on one of the default panels, so no need for an icon on the desktop"
<dholbach> Riddell: it should not
<heno> iwj, asac, pitti, mdz, kylem, Riddell, kwwii, rtg, bdmurray, pkl: https://wiki.ubuntu.com/Testing/Matrix Some beta candidate images ready for you to test when you have a moment :)
<dholbach> heno: I'll do the i386 dvd tests
<gpocentek> janimo: hello
<janimo> gpocentek: just uploaded a libxfce4util with the two other bugfixes from svn
<heno> dholbach: not sure if DVDs are updated yet
<janimo> I hope they will fix the many xfce4-session and some of the xfdesktop4 crashes
<dholbach> heno: ah ok
<janimo> I cannot reproduce either but they wer made upstream in response to similar crashes
<gpocentek> ok
<gpocentek> janimo: I've never seen such crashes here
<Riddell> heno: we're using matrix rather than ubuntu-iso-test bugs?
<janimo> gpocentek: yeah me neither but there are quite a few duplicates in the past days
<seb128> Riddell: no
<seb128> Riddell: we have a wastebin on the panel
<janimo> backtraces show xfce4_rc_ fucntions and those are affected by bth upstream patches so fingers crossed :)
<heno> Riddell: no, please use the u-iso-test thing, the matrix is just a schedule
<gpocentek> janimo: :)
<janimo> Mithrandir: hi, is it you that allow packages into main during freeze? There's an xfce fix uploaded 15 minutes ago.
<Mithrandir> mvo: if it's not critical, it's not going in before after beta.
<asac> heno: ok if I just install and do Testing/Short, Testing/Long plans ? Or do I need to test erase disk and auto-resize variants as well?
<Mithrandir> janimo: which critical bugs does it fix?
<heno> asac: you could do one install test on real hardware and one in a virtual machine
<heno> asac: will that work for you?
<heno> but, yes. all tests please :)
<janimo> Mithrandir: it _possibly_ fixes about 5-6 xfce4-session and a couple xfdesktop crashes that have been reported lately
<janimo> Mithrandir: possibly because  I cannot reproduce the crashes
<janimo> Mithrandir: not critical but certainly annoying and flooding LP
<Mithrandir> janimo: does it fix the problem for the bug reporters?
<janimo> Mithrandir: they cannot test until the deb is in the archive :)
<Mithrandir> sure they can, just make them test-build it.
<janimo> Mithrandir:  most are apport geneared backtraces with the users not knowing what happened
<janimo> Mithrandir: I'd rather wait till post beta then and let them update and test that way
<janimo> Mithrandir: they cannot always reporduce the bug
<asac> heno: guess i will install vmware now :/
<janimo> Mithrandir:so  checking it does not crash cannot be done in one run
<heno> asac: or see this handy VirtualBox tutorial https://wiki.ubuntu.com/Testing/VirtualBox :)
<Mithrandir> janimo: I would really recommend against doing the update at this point, but if you want to take the chance, it's your choice.
<heno> written just for the occasion 
<janimo> Mithrandir: please allow it through then, the patches are fixing crashers seen by upstream users
<janimo> I hope they apply to us as well
<seb128> gpocentek, janimo: I've retrace some of the xfce bugs and cleanup duplicates
<gpocentek> seb128: yep I've seen this, thanks
<seb128> gpocentek, janimo: if you want a retrace you an use "need-{iamd64,386,ppc}-retrace" tag now, pitti set up an autoretracer
<seb128> s/you an/you can
<seb128> np
<gpocentek> ok
<dholbach> pitti: the retraced backtraces don't always look good - like bug 93983
<Ubugtu> Malone bug 93983 in kdelibs "weather applet crashes on logout" [Medium,Unconfirmed]  https://launchpad.net/bugs/93983
<janimo> seb128: thanks I saw you just marked soem dupes
<seb128> dholbach: that might be because the crash happened to a package which is not a Depends
<asac> heno: yes VirtualBox looks better. Thanks will try
<dholbach> seb128: what do you mean?
<seb128> dholbach: the retrace install dbgsym only for Depends, if the crash happens, let's say to the GTK theme you are using, it's not working
<dholbach> ok
<dholbach> bug 93958 too
<janimo> seb128: a LP tag you mean? (need-386-retrace)
<Ubugtu> Malone bug 93958 in beryl-manager "[apport]  beryl-manager crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93958
<seb128> other problem can be a version not matching
<seb128> janimo: yep
<seb128> need-i386-retrace
* dholbach tagged a few too
<janimo> seb128: so just tag bugs which have strpped bacjtraces and they'll get symbols automatically?
<seb128> janimo: correct
<janimo> sounds cool
<seb128> janimo: similar to the bug I dupped and which had a retraced crash
<seb128> I used the retracer manually on them
<seb128> now there is a service running doing that automatically
<seb128> janimo: try to retrace your bugs regulary, that only works when the versions match
<janimo> seb128: and when you have time :)
<seb128> tagging doesn't take much ;)
<kwwii> Seveas: ping? I wanted to discuss the "text overlaps the progress bar" bug if you've time
<kwwii> Seveas: in the upslash, that is :-)
<fabbione> Mithrandir: can i upload a redhat-cluster-suite to fix https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232878 ? it's one line change
<Ubugtu> Red Hat bug 232878 in dlm "failed to acquire lockspace [rgmanager related] " [Medium,Assigned: ]  
<fabbione> -        return dlm_release_lockspace(name, ls, 0);
<fabbione> +        return dlm_release_lockspace(name, ls, 1);
<fabbione> switching 0 to 1 forces the kernel to clear the lock space instead of caching it
<fabbione> it's a workaround for a known dlm bug
<Mithrandir> fabbione: sure, feel free to upload; I'll accept it post-beta.
<fabbione> (we will get eventually the dlm fix too but in the meanwhile it will make the suite working again)
<fabbione> Mithrandir: ok then i will wait after beta directly
<fabbione> Mithrandir: perhaps we will get the proper fix quickly
<Seveas> kwwii, poke
<kwwii> Seveas: have you heard about this bug before? https://launchpad.net/ubuntu/+source/usplash/+bug/78324
<Ubugtu> Malone bug 78324 in usplash "non-quiet mode text scrolls over progress bar" [Undecided,Confirmed]  
<Seveas> kwwii, yes, simply means a bug in the theme
<Seveas> check position & size of progress bar and position of textbox
<Seveas> the box may simply need to be moved down
<kwwii> Seveas: that was my first thought too...but I wasn't sure how much, or how the box stuff works in general
<kwwii> so I thought I'd ask you first :-)
<Seveas> that should work 100%
<Riddell> carlos: https://translations.beta.launchpad.net/ubuntu/feisty/+source/kubuntu-docs/+translations doesn't seem to have the new .pot files for the feisty kubuntu-docs, can they be imported?
<carlos> Riddell: I'm doing it right now. mdke already pinged me on that issue
<Riddell> carlos: rocking
<kwwii> Seveas: I am going to change the values of the text box stuff, and hope that I get it right :-) 
<Seveas> kwwii, I'd first see which resolution it is 
<Seveas> and which theme :)
<kwwii> Seveas: it is both the ubuntu and the kubuntu themes
<Seveas> odd
<kwwii> Seveas: and I have no idea how to figure out which res it is :-)
<Seveas> kwwii, cat /etc/usplash.conf
<Seveas> ah, I see it already
<Seveas> text_x is far too low
<Seveas> err, txt_y that is
<kwwii> x? wouldn't that be y
<kwwii> hehe, yeah
<Seveas> oh, no it is not. hmm...
<kwwii> if anything it should be too high on one theme, I guess
<kwwii> since it is displaying over the progress bar
<Seveas> (0,0) is top left
<kwwii> ahhhh, I was thinking bottom left
<Seveas> ah, the widescreen theme is broken
<Seveas> line 233 in usplash-theme-ubuntu.c
<Seveas> should read 400, not 475 for progressbar_y
<Seveas> same bug for kubuntu theme, line 190
<asac> heno: what image to pull? 
<Seveas> kwwii, but other than the widescreen themes it looks ok
<kwwii> Seveas: it appears that it also happens at 800x600
<heno> asac: http://cdimage.ubuntu.com/daily-live/20070320.1/ amd64 desktop in your case
<kwwii> Seveas: but looking at the theme file, I cannot understand why :-(
<Seveas> shouldn't happen with ubuntu theme, with kubuntu theme it's possible
<Seveas> line 108/114: textbox begins above pb
<kwwii> Seveas: yeah, now I see it, thanks for the help :-)
<Seveas> np
<sbalneav> mdz: about?
<sbalneav> Mithrandir: You about, Tollef?
<_follower_> hi, i'm trying to find the source of dbus-raise-service-start-timeout.patch (mentioned here https://launchpad.net/ubuntu/+source/dbus/+bug/62763) and can't find web-browsable bzr source repository--am i missing something?
<Ubugtu> Malone bug 62763 in dbus "dbus activation timeout too short" [Low,Fix released]  
<Mithrandir> sbalneav: yes
<pitti> heno: will test them this afternoon
<sbalneav> Mithrandir: got a potentially sticky problem, mind if we /msg?
<pitti> dholbach: I have a plan how to include the dbgsyms for dynamically loaded stuff as well, just no time yet to implement it
<seb128> pitti: there is case where the retrace give no good backtrace and should, I've not figured why though
<pitti> right, I saw some as well
<pitti> I need to fish out gdb error messages and print them as WARNINGs or so
<pitti> might be corrupted cores or whatever
<seb128> no
<seb128> they work on my desktop
<seb128> like gdb on the coredump works fine
<pitti> oh, I see
<seb128> pitti: bug #94076 for example
<Ubugtu> Malone bug 94076 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV in _dl_fini()" [Medium,Confirmed]  https://launchpad.net/bugs/94076
<seb128> retracer doesn't work
<seb128> dholbach did retrace it correctly though
<seb128> #0  0x0e63d57a in ?? ()
<seb128> #1  0xb7f8b9ce in _dl_fini () from /lib/ld-linux.so.2
<seb128> #2  0xb74a29d9 in ?? ()
<seb128> #3  0x00000000 in ?? ()
<seb128> that's from the retracer
<saispo> hi seb128 :)
<pitti> seb128: oh, retracer got stuck in a loop - bug 91528 'URL does not contain DistroRelease: field'
<Ubugtu> Malone bug 91528 in xfdesktop4 "XFDesktop crashed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91528
<seb128> lu saispo
<seb128> does anybody know about a website where to find details about image formats?
<_follower_> seb128: wotsit.com?
<seb128> image/x-kodak-kdc is listed as image/tiff subclass by the shared-mime-info list
<_follower_> seb128: or seomthing like http://wiki.multimedia.cx/index.php?title=Main_Page
<seb128> tiff viewers don't open them correctly though
<seb128> _follower_: thank you, looking
<_follower_> seb128: http://filext.com/detaillist.php?extdetail=KDC
<pitti> seb128: FYI, I stopped the Malone digger, I'll add a workaround for the bugs which do not yet have a DistroRelease: field, and fix the endless loop
<bddebian> Heya
<_follower_> seb128: http://www.asmail.be/msg0055373256.html "Re: Any info on KDC file format?""
<sbalneav> Mithrandir++
<Hobbsee> sbalneav: you're duplicating Mithrandir?
<Hobbsee> neat!
<sbalneav> Karma + 1
<sbalneav> :)
<Hobbsee> hehe :P
<Hobbsee> awww
<Mithrandir> Hobbsee: he's trying to change my nick to Mithrandiq
<Mithrandir> sorry, Mithrandis
<Hobbsee> but if we had duplicate Mithrandir, then they could do double the archive work!
<heno> tfheen, mvo, bdmurray, mikebro, cburg, BenC - ubuntu-server beta candidates ready for testing https://wiki.ubuntu.com/Testing/Matrix
<Hobbsee> heh.  i didnt think q was after r...
<BenC> heno: Ok
<sbalneav> Unfortunately, the TCP/IP protocol has not been extended to the point where I can ICMP ECHO BEER, so I will have to buy Mithrandir one at the next UDS
<Mithrandir> sbalneav: you're coming to .es?
<sbalneav> Mithrandir: hoping to.
<Simira> Hobbsee: no way! If he was two, I'd definitely keep one at home!
<seb128> grumpf linux
<Hobbsee> sbalneav: heh.  dodgy
<seb128> 4th network driver crash today
<Simira> Hobbsee: he could clean the house and train the dog
<Hobbsee> Simira: haha.  perhaps you need to tripplicate him then?
<Hobbsee> ahhh...that could be fun
<sbalneav> Both ogra and riched have put me on the guestlist.  I'm also speaking at the Ubuntu day in July.
<Mithrandir> I prefer myself as one person, thank you very much.
<Mithrandir> sbalneav: nice, would be good to see you again
<sbalneav> Likewise.
<_follower_> seb128: wow, the kodak web site sucks--good luck trying to get to the developer group pages...
<seb128> _follower_: :/
<mvo> heno: thanks, will do one now
<pitti> oh, argh, where's janimo?
<Hobbsee> pitti: i ate Janimo.  why do you ask?
<pitti> he tagged a whole bunch of old-style apport bugs with need-*-retrace; that will not work
<seb128> oh, I told him about autoretracing
<seb128> I forgot to specify that was only for new crashes :/
<pitti> seb128: no problem
<pitti> seb128: I maintain a 'fail pool' now, so that it doesn't loop on those forever
<_follower_> seb128: did any of those links give you anything new?
<_follower_> btw http://archive.ubuntu.com/ubuntu/pool/main/d/dbus/dbus_1.0.2-1ubuntu3.diff.gz  apparently contains the code i was looking for, but I still wonder if you have a web-viewable source control repo for stuff like that...
<seb128> _follower_: not really, I've found things with google though
<ogra> Mithrandir, my server iso is busted :/
<seb128> _follower_: no, no viewcvs or something like that
<seb128> _follower_: apt-get source the package and look to debian/patches usually
<_follower_> seb128: oh, why not? i always find it handy for "easy access"--was there a policy decision against it, or just no-one got to it?
<_follower_> seb128: thanks for letting me know tho--i'll stop looking for one :-)
<seb128> _follower_: every is over-worked already and it's not on the "top priority list"
<Mithrandir> ogra: that's not an description of an error.
<seb128> everybody
<_follower_> seb128: maybe it could be a faq with the answer. "no". :-)
<seb128> yeah, maybe
<_follower_> anyway, thanks for the feedback i'll leave you all to it... turns out i need to be looking at session.conf...
<ogra> Mithrandir, ltsp xorg keymap setting is broken during chroot creaton, somehow it doesnt like d-i ... fix is here: http://people.ubuntu.com/~ogra/ltsp_5.0.2_vs_5.0.3.debdiff
<Mithrandir> ogra: upload a new ltsp, then?
<ogra> ok with you ? 
<Mithrandir> it'll only affect edubuntu and you seem to need it for beta, so yes.
<ogra> thanks, uploading
<iwj> heno: I don't seem to be able to `Make sure that the build number (like 20070107.1) matches the test number listed on the [WWW]  test tracking page!' because the `test tracking page' is a list of bugs of which the relevant one (bug 93120 afaict for i386 livecd) has no number or md5sum.
<Ubugtu> Malone bug 93120 in ubuntu-iso-tests "beta: Ubuntu i386 desktop" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93120
<seb128> go linux, another network driver crash :/
<superm1> hey is anyone from ubuntu-archive around right now?
<pitti> superm1: yes
<seb128> superm1: don't ask to ask, just ask
<superm1> k
<superm1> there are some backports sitting in binary NEW
<superm1> for dapper
<superm1> since jan
<superm1> for mythplugins
<pitti> seb128: ok, lp crash grabber is back online
<seb128> pitti: rock on ;)
<superm1> so i just wanted to poke and see if there was a chance of getting those acked
<cjwatson> superm1: I'll process those now
<superm1> thanks cjwatson 
<cjwatson> we sometimes miss them 'cos there are so many different queues ...
<superm1> yea i had assumed.  a bug just pointed it out to me that they still didnt get acked
<Mithrandir> I have a plan of making something send a report of "those queues should really be empty" to -archive.
<Mithrandir> maybe just q report on each of the different distroreleases.
<heno> iwj: right, those instructions are not good. I think you know what image to test, but I need to clarify that, thanks
<seb128> Mithrandir: dunno if the message has been sent before network breakage, what do you think about adding "dcraw" to the desktop seed?
<Mithrandir> seb128: I haven't seen it at least.  What can use it?
<cjwatson> superm1: dapper-backports NEW cleared
<superm1> cjwatson, :)
<iwj> heno: daily-live 20070320.1 I presume but do correct me if that's wrong.
<heno> iwj: that's correct
<iwj> Also I edited one of your pages to try to get people not to write crazy middle-endian dates.
<iwj> correct> Good.
<iwj> I had a problem with my electricity last night so 20070320.1 is still rsyncing I'm afraid, but I'll get on with testing it when it turns up.
<seb128> Mithrandir: f-spot apparently, it Recommends it
<seb128> trying now
<Mithrandir> ogra: please make sure to talk with heno so the status of your images is kept track of.
<seb128> Mithrandir: gthumb opens the kdc example from https://bugs.beta.launchpad.net/ubuntu/+source/shared-mime-info/+bug/91488 with it installed also
<Ubugtu> Malone bug 91488 in shared-mime-info "Camera RAW files open with wrong apps" [Undecided,Unconfirmed]  
<ogra> Mithrandir, will do
<Mithrandir> seb128: ok, sounds sensible to have it there.  It's quite small, isn't it?
<seb128> Mithrandir: around 100k
<Mithrandir> seb128: ok, just add it, then.
<seb128> Mithrandir: ok, thank you
<seb128> will do that after the beta freeze
<dholbach> pitti: 
<dholbach> pitti: ok
<giskard> ciao *
<bluefoxicy> FRUSTRATION.
<Simira> who's got kernel issues now? 
<cjwatson> Simira: the kernel team; #ubuntu-kernel
<Simira> cjwatson: thanks. I think it's BenC's bug :)
* bluefoxicy flails with network-admin for a while after a reboot, then breaks down and does an iwconfig ath0 essid Icenet
<mdz> crimsun: dmix works fine on my hardware, but isn't set up automatically (I need to create an .asoundrc).  How do I fix that?
<Tonio_> mjg59: I have tested your proposed patch for alsa/macbook pro, that's way better.
<Tonio_> mjg59: I'll try to ping crimsun once available for review and inclusion
<Tonio_> mjg59: just fyi, latest pommed upstream fixes about all the issues and perfectly works here, I'll make an UVF exception request for this
<mjg59> Tonio_: What do you need pommed for?
<Tonio_> mjg59: lcd and keyboard backlight control, auto managed by the sensor
<Tonio_> as on osx in fact
<mjg59> hal and gpm ought to manage that...
<Tonio_> mjg59: keyboard backlight with the sensor ?
<Tonio_> mjg59: and and I don't know what is the status with ubuntu, but on kubuntu the eject key, although we have patched kmilo for this, doesn't appear to work.... only pommed worked here
* mjg59 shrugs.
<mjg59> I'm not a Kubuntu guy
<bddebian> Well why the hell not? :-)
<Tonio_> mjg59: I'm not an ubuntu one :) I don't know the current status with gnome, but on kubuntu that's not very good out of the box hehe ;)
<dholbach> can an archive admin please take care of bug 92799
<Ubugtu> Malone bug 92799 in libtelepathy "Please sync libtelepathy from incoming" [Medium,Confirmed]  https://launchpad.net/bugs/92799
<Tonio_> basically, just the numlock seems to work, no eject, no lcd or keyboard backlight, sensor is ignored.....
<Tonio_> but as a very simple package works perfectly, that's ok I think
<Nafallo> hi! is universe waved through the queue as usual or is it opened again after beta is released? :-)
<Rocha> hello
<Rocha> how can i report a bug in the desktop effects app?
<Rocha> a serious bug
<LaserJock> Rocha: https://launchpad.net/ubuntu/+filebug
<Rocha> thanks
<pitti> Rocha: ubuntu-bug -p desktop-effects
<Rocha> pitti: that command doesn't work
<pitti> oh? how so?
<Rocha> python error, no route to host
<Rocha> could not upload report data to lauchpad
<pitti> Rocha: erm, but since we talk on IRC, your network works?
<Rocha> yes, it works perfectly
<Rocha> i'm behind a proxy, maybe that's the problem
<pitti> Rocha: can you ping launchpad.net ?
<pitti> Rocha: ah, and you configured firefox to use that proxy?
<Rocha> yes, perfectly
<pitti> Rocha: I'd welcome a bug against apport for that
<Rocha> yes, but the ubuntu-bug app should use the proxy configured in the gnome environment
<pitti> https://launchpad.net/ubuntu/+source/apport/+filebug
<pitti> indeed
<superm1> pitti, u mean "ubuntu-bug -p apport" ;)
<Rocha> i'll report the two bugs
<pitti> superm1: haha
<pitti> Rocha: thank you!
<Rocha> ubuntu-bug not using the environment proxy and desktop-effects installing nvidia-glx when i'm using nvidia-legacy already
<Rocha> pitti: is it too difficult to add proxy support for the app?
<Rocha> i could try to code that
<pitti> Rocha: it would need to get into python-launchpad-bugs
<pitti> Rocha: help greatly appreciated, of course
<Rocha> ok, i'll report both bugs in a second
* heno -> food
<Rocha> pitti: done
<Rocha> i think that to begin coding for you, starting with that apport bug would be easy
<pitti> Rocha: great!
* pitti hugs Rocha
<pitti> Rocha: it might not be that simple actually, I don't know how Gnome sets the proxy
* desrt nods to pitti
<desrt> tepsipakki; wazzup?
<pitti> Rocha: and it shouldn't depend on gnome libraries, p-launchpad-bugs should neither have huge dependencies nor be gnome dependent
<Rocha> pitti: no problem, i'll read the code of an app that does use the gnome proxy
<pitti> hey desrt, how's live?
<pitti> Rocha: so it should just try to read gconf etc., and if that fails, ignore it
<desrt> pitti; stuff is good.  just got an email from claire.  figure i should probably chill here a bit more for the next little while :)
<Rocha> pitti: i'll look into that
<pitti> desrt.make_absolute_location('here')
<desrt> :)
<Rocha> pitti: can you give some hints on how to start coding for you?
* desrt is trying to get a patch into feisty's x server
<Rocha> pitti: just to try to fix that bug
<pitti> Rocha: in what regard? bzr get http://bazaar.launchpad.net/~bugsquad/bughelper/bughelper.0.1 is certainly a good start
<pitti> Rocha: and reading ui.py in the apport source (def upload_launchpad_blob_ 
<pitti> Rocha: s/_$/)/
<Rocha> i'll have to download apport from bazzar right?
<pitti> Rocha: something like launchpadBugs.storeblob.upload(StringIO("hello")) looks like a good and simple test
<pitti> Rocha: not necessarily, but of course you can; apt-get source apport will do, though
<pitti> Rocha: since the proxy handling etc. needs to be fixed in python-launchpad-bugs
<pitti> Rocha: but the single command above should be a good test, you don't need the aport source for this
<Rocha> pitti: i'm completely lost, sorry :(
<pitti> Rocha: let's do that in /msg
<TomaszD> in gdebi, what did the developer had on mind by saying "this package is uninstallable" ?
<TomaszD> does it mean that it's possible to uninstall this package?
<jdong> probably that it cannot be installed
<TomaszD> or does it mean that it's impossible to install the package?
<ivoks> no, it's not possible to install it
<TomaszD> ok, thx
<zyga> hey 
<zyga> I love open source :-)
<zyga> I made that small package some time ago, command-not-found
<zyga> and now it hit the planet :-)
<zyga> with bugs and patches
<Mirv> mvo: now that there was this new update-manager put in edgy, and it generates a lot of untranslated strings, should we have a yet another translation update to edgy before feisty?
<zyga> that's just like winning a lottery :-)
<zyga> you feel great and get stuff for free
<zyga> mvo: thanks for all your help with this
* pitti hugs zyga
<mvo> Mirv: you mean update-manager-core? its tiny and only required for server upgrades
<mvo> zyga: :)
<mvo> zyga: its great, isn't it ?
<zyga> yeah :-)
<zyga> I'm going to fix all those bugs right away :-)
<mvo> zyga: great, let me know when I can merge/upload :-D
<mvo> zyga: 
<zyga> mvo: I'll update my branch on launchpad and maybe add debwatch (I always wanted to learn that)
<mvo> zyga: #92942 is in my tree, I'm not sure about #92862 
<Mirv> mvo: yeah, update-manager-core, rosetta just says there's now untranslated string like "Upgrade tool" partial upgrade texts and 20+ others, are they somethings that are used maybe for desktop upgrades, too? or are they such that translations are fetched by the upgrade tool automatically?
<zyga> mvo: I'll merge from your branch then
<zyga> as for #92862 the frontend can be fixed easily
<mvo> Mirv: for edgy there really shouldn't be 20 new strings, that sounds very strange. for feisty, new strings are very possible, I'm not sure when update-manager was imported, but it may not be too long ago
<Mirv> mvo: https://translations.launchpad.net/ubuntu/edgy/+source/update-manager-core/+pots/update-manager-core/ - all languages have at least 27 new untranslated strings
<Mirv> expect Finnish, which I just fixed
<zyga> but the backend and the actual useful frontend for non apt-get is beyond my abilities as I just have no knowledge of redhat/gentoo/$others
<mvo> zyga: my personal opinion is that people who use dselect or aptitude can easily tranform "apt-get" to the tool for choice :)
<mvo> Mirv: let me check
<zyga> dselect and aptitude can be run in batch mode?
<zyga> (I didn't know that)
<mvo> Mirv: that looks wrong, let me talk to carlos again
<TheInfinity> hmm ... one question to an ubuntu package - i get from cyrus channel the information "if you don't have the deliver binary, then you have a horribly broken cyrus install. reinstall." - seems to be a problem with the ubuntu cyrus package?
<TheInfinity> because my deliver binary is definitly not there ;)
<Mirv> mvo: ok, thanks. no problem though with the strings, if we just can get relevant language pack updates etc., too, and maybe it should be mentioned to ubuntu-translators that people translate those in edgy, too (the strings are same as in feisty)
<mvo> Mirv: it should really have only ~10 strings, so I will make sure that its hidden until this is sorted out
<carlos> Mirv: those translations should land automatically in next language pack update
<Mirv> carlos: well, the current update is already in proposed and does not include those, and the next one will probably come only in May or so (ie after feisty)
<carlos> pitti: ^^^
<zyga> mvo: how can I edit bugs assigned to c-n-f?
<Mithrandir> TheInfinity: it's called cyrdeliver and is in cyrus21-common and cyrus-common-2.2 as you could quite easily have discovered.
<pitti> carlos, Mirv: right, on start of April
<Mirv> pitti: yeah, that sould get enough time for also other teams to translate those new string
<TheInfinity> hmm ... ok i'll look tomorrow - i was quite sure that it was not there ... i'll come again when i have access to the system again :)
<EvanCarroll> I just upgraded to feisty yesterday, needing pg8.2, and I've since been having problems with Evolution of all things. =[
<EvanCarroll> keeps forgetting my password, and moving me to 'work offline'
<EvanCarroll> actually it doesn't forget it, it just doesn't accept it. next time it does it i'll tethereal it and send in bug report
<TomaszD> I'm sorry, which package is responsible for time-admin? gnome-applets? 
<pitti> TomaszD: gnome-system-tools
<TomaszD> pitti, thank you very much.
<pitti> TomaszD: btw, 'dpkg -S time-admin' :)
<TomaszD> pitti, aahh my saviour
<TomaszD> pitti, you're the one developing restricted-manager ?
* pitti runs away screaming
<pitti> yes, I am ATM
<TomaszD> pitti, no, don't worry
<TomaszD> I have an unusual "problem"
<TomaszD> I'm an Ubuntu Translator and I need to see the GUI running on my computer, however I don't have restricted hardware...
<TomaszD> so it just tells me to beat it.
<pitti> oh, heh :)
<TomaszD> :)
<TomaszD> any ideas for an "override"?
<pitti> TomaszD: that's relatively easy
<pitti> TomaszD: -> /query
<BenC> heno: ping
<dholbach> can an archive admin please take care of bug 92799?
<Ubugtu> Malone bug 92799 in libtelepathy "Please sync libtelepathy from sid" [Medium,Confirmed]  https://launchpad.net/bugs/92799
<sjoerd> typical timing :p
<dholbach> :)
<crimsun> mdz: which hardware?
<mdz> crimsun: onboard nvidia
<crimsun> mdz: ac97- or hda-based?
<mdz> crimsun: ac97
<crimsun> mdz: what does ``asoundconf list'' say for that chip?
<mvo> Mirv: the u-m-core pot file is updated, it should be much less noisy now
* cjwatson scratches his head over swap formatting in ubiquity
<_ion> pitti: Please review the changes at http://johan.kiviniemi.name/software/bzr/restricted-manager/
<_ion> % ls /usr/share/restricted-manager/modalias_override 
<_ion> ath_hal  fglrx  ipw3945.manual  nvidia  nvidia.manual
<mdz> crimsun: hmm, unfortunately the BIOS is hiding it now because I installed an SB live (which seems to do hardware mixing). anything  I can get from syslog which would tell you what you need to know?
<_ion> Now the patterns are a lot easier to modify.
<pitti> _ion: ah, great; will do, and merge
<crimsun> mdz: hmm, unfortunately not
<mdz> crimsun: I had completely forgotten that I had an .asoundrc until I started playing with btsco
<mdz> and when I removed it, only one process could use the sound device
<crimsun> mdz: ok, at your leisure the output from ``asoundconf list'' with that chip enabled would help
<mdz> crimsun: ok, thanks
<TomaszD> pitti, ok I got it to work now, however the "Check for new Restricted Drivers" and "Restricted Drivers Manager" are left untranslated despite 100% status in Rosetta for my language. As if the desktop file was unaffected by translations
<pitti> TomaszD: I have those translated, hmm
<TomaszD> pitti, will you be here tomorrow to bother you again if tomorrow's langpack doesn't fix it?
<pitti> TomaszD: yes, I will
<TomaszD> ok cool.
<vdepizzol> jwendell: hello
<jwendell> vdepizzol, hi
<vdepizzol> jwendell: can you join #ubuntu-br-doc? :)
<Mirv> mvo: thanks.
<iwj> Come on launchpad, give me bug numbers!
<_ion> 1
<pitti> seb128, dholbach, asac: come on, guys, the lp retracers want to get some fodder, they are idling around :-P
<dholbach> pitti: your wish is my command :)
<pitti> dholbach: (just kidding, of course)
* pitti actually writes the announcement mail now
<dholbach> ohhhhhhhhhhh :-(((((((((
<dholbach> ;-)
<TomaszD> what's the name of the package which has this "writing data to device, don't remove" elements ? I'm looking for this in vain
<pitti> dholbach: I had to make a small bughelper fix to work around bug 94137
<Ubugtu> Malone bug 94137 in malone "produces invalid HTML in field.title input" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94137
<dholbach> pitti: looking into it
<pitti> dholbach: how do you want the patch?
<dholbach> in the bug report is fine - a branch is fine too
<pitti> dholbach: that bug is a Malone one (invalid HTML)
<dholbach> ah ok
<pitti> dholbach: can I email you the debdiff?
<dholbach> fine too
<dholbach> if i get hit by a bus, there's also bughelper@lists.ubuntu.com
<pitti> dholbach: http://people.ubuntu.com/~pitti/tmp/bughelper.94137.diff
<dholbach> supi
<EtienneG> iwj, I saw your MIR for sl-modem
<EtienneG> I'm looking forward to it
<iwj> EtienneG: :-).
<iwj> I hope you approve of my upload too.
<dholbach> pitti: we'll switch from regexp to xpath in 0.2 :-)
<EtienneG> iwj, I wish I could !
<pitti> dholbach: *phew* :)
<_ion> Couldn't Launchpad provide a SOAP API or something?
<dholbach> _ion: xmlrpc is work in progress afaik
<c5jr> hello
<Seveas> mdke, you here?
<Seveas> sabdfl, elmo: CC meeting in 5 minutes
<seb128> dholbach: do you track bug you tagged?
<asac> pitti: pitti you found why retraces don't work properly for ffox?
<pitti> asac: no idea :(
<seb128> dholbach: https://bugs.beta.launchpad.net/ubuntu/+source/synaptic/+bug/94150 for example, the retracing doesn't work, we need to ask for a new crash file
<Ubugtu> Malone bug 94150 in synaptic "[apport]  synaptic crashed with SIGSEGV" [Undecided,Unconfirmed]  
<pitti> asac: but I didn't look very hard so far
<seb128> asac: does it work with apport-retrace locally?
<dholbach> seb128: if I see bugged retraces, I'll ask for new crashes
<pitti> asac: could you confirm that retracing the same bug works with 0.61 and fails with 0.69 in the same environment?
<seb128> dholbach: ok, just wondering because you didn't subscribe to the bug
<asac> pitti: still waiting for feedback from team members
<asac> will do so on my own later if they don't come up with test results
<seb128> dholbach: trying to figure a workflow to work from the unconfirmed bugs list
<pochu> pitti: if I add a tag 'need-i386-retrace' should a retrace be automatically added by your retrace service?
<pitti> asac: thank you
<pitti> pochu: I just mailed ubuntu-devel@ about that
<dholbach> seb128: let's move to #ubuntu-bugs
<seb128> dholbach: ok
<seb128> pitti: 
<seb128> $ ~pitti/bin/retrace-i386 94140
<seb128> -bash: /home/pitti/bin/retrace-i386: Permission denied
<pitti> seb128: right, second
<seb128> k
<pitti> pochu: short answer is 'yes'
<pitti> seb128: I disabled the scripts for now, since the daemon is running now
<pitti> seb128: you still need to call them manually?
<pitti> seb128: chmod'ed back
<pochu> pitti: it's because I did it this evening, and the retrace service removed the tag, but he didn't attached a retrace! :S
<pochu> pitti: bug 89848
<Ubugtu> Malone bug 89848 in listen "Listen crashes randomly when downloading missing covers" [Medium,Needs info]  https://launchpad.net/bugs/89848
<pitti> pochu: please try again
<pochu> pitti: ok
<pitti> pochu: I fixed a bug about half an hour ago that made attachments break with invalid utf-8
<pitti> pochu: with 'try' being 'stick the tag back on'
<pochu> sure :) doing
<seb128> pitti: well, not really, I'm used to it and it's as quick as tagging to run the command ;)
<pitti> seb128: right, I'm just a bit concerned about the load
<seb128> pitti: and I wanted to have a look at why some retracing don't work
<seb128> but there is not enough debug output for that apparently
<pitti> seb128: btw, if you want to repeatedly retrace a bug, you might be better off with logging into the chroot and calling apport-retrace
<heno> BenC: pong
<pitti> seb128: then you can also use -g and whatever
<pitti> seb128: I'll write some wrapper scripts to log in, second
<seb128> pitti: if I do that I can use debug prints? ;)
<seb128> pitti: yeah, look like a good idea and a way to look why some retracing don't work
<pitti> seb128: once you are logged in, you are welcome to apt-get install any package you like, or hack up /usr/bin/apport-retrace as you wish
<seb128> pitti: another usecase is that for quite some bugs I need extra packages not listed to Depends
<BenC> heno: In regards to ISO testing, I less able to test sparc installs than fabbione. I only have one, and it's my build/dev box, and it takes 12 minutes to cold boot, and 3 to soft boot
<pitti> seb128: right
<BenC> heno: I would like to add to your list some tests that I do anyway, and which may help the testing cycle anyway. I always do a VMWare (vmi+paravirt) guest install (server and desktop), as well as a kvm (kernelbased virt) guest install (server and desktop)
<heno> BenC: ok, thanks. Let me see if cburg in Montreal is making any progress on that
<heno> BenC: OK, cool what platform?
<BenC> heno: I can actively test Intel 64-bit/32-bit installs easily on a dual-core box
<BenC> heno: I do it on 32-bit and 64-bit Intel
<BenC> so basically I install on the bare metal, install vmware and kvm, and do guest os installs on that
<BenC> for 64-bit host, I test 32-bit and 64-bit guest
<pitti> seb128: ~pitti/bin/retracer-login-{i386,amd64}
<pitti> seb128: root@ronne:/#  -> feel the power :-P
<heno> Right, we have good coverage on i-32 and i-64 is not officially a concern I guess
<heno> but interesting cases nonetheless 
<heno> I should make a page for 'other tests'
* seb128 hugs pitti
<seb128> pitti: thanks, so I can stop pinging you every 5 min and do some work myself ;)
* pitti hugs seb128 
<seb128> pitti: I'll try to figure why some retraces don't work
<pitti> seb128: NB that there is no LP cookie in the chroot
<pitti> seb128: it's copied there by apport-chroot at runtime
<seb128> no need ot that
<pitti> seb128: so you need to use -s or -o file 
<pitti> or -g
<seb128> I just want to retrace
<seb128> k
<pitti> right
<pitti> seb128: remember to use -u and --no-purge to save time
<seb128> ok
<BenC> heno: It's not ia64, it's 64-bit x86_64 (amd64)
<heno> oh, right
<heno> that we do need testing on
<BenC> heno: Virtualization is becoming a bigger deal for us, so guest OS testing should probably start being considered the same as hw testing
<BenC> heno: If I had virtualbox, I'd test that too, but I don't have that setup yet :)
<heno> BenC: agreed. I've been known to write about it at length :)
<c5jr> yeah
<c5jr> i like that feisty will have .20 in it
<heno> I failed to get that set up on amd64 for some reason
<wereHamster> who's ubuntu's wine maintainer?
<heno> I guess their binary is i386
<c5jr> does ubuntu ship for sparc now?
<giangy> wereHamster: https://launchpad.net/ubuntu/+source/wine
<heno> fabbione: are you able to do some test installs on sparc server for beta? just default and LAMP+LVM install
<c5jr> i can do test installs on many different sparcs
<giangy> wereHamster: Stephan Hermann is probably the right person to contact :)
<c5jr> older and newer
<c5jr> i can even give shells for testing, etc, etc to any interested parties
<cjwatson> fabbione: could you translate bug 70487 into English for me, please? There isn't much to it ...
<Ubugtu> Malone bug 70487 in ubiquity "Non riesco ad installare" [Undecided,Needs info]  https://launchpad.net/bugs/70487
<wereHamster> giangy, thanks
<c5jr> I wonder if the Ubuntu build system by kaimon works now.
<wereHamster> I guess he's away right now.. \sh_away
<c5jr> My ex-coworker JTV submitted some changes upstream, but still no love with the build
<c5jr> I could never get a cd to do anything but fail a md5sum test while building my own from source (dl all packages, run build scripts (even get unneeded britney, etc, etc)
<c5jr> It is really a shame
<c5jr> its like, linux for humans, by aliens
<giangy> cjwatson: "I can't install...I have a problem with the hd?"
<c5jr> unless you want to pony up the 700euro to get an easy cheesy third party install cd if i understand correctly
<giangy> cjwatson: poor report btw :)
<c5jr> that wasnt the direction i thought ubuntu was going in when i met mark and malcom a year ago
<ogra> Mithrandir, can you kick off a -server iso build for edubuntu ? 
<ogra> ltsp is there 
<cjwatson> giangy: yeah, it's awful - I'm going through rejecting lots of that kind of bug against ubiquity at the moment. Thanks for the translation
<dholbach> pitti: uploaded and pushed your changes
<pitti> dholbach: uploaded? we're in freeze...
<pitti> dholbach: thank you
<dholbach> pitti: uploaded and it will be considered after freeze or during it if there are free build cycles :)
<shawarma> pitti: The automatic apport retrace stuff looks really cool! Great work!
<pitti> shawarma: \o/
<shawarma> pitti: \o/ all over the place. :-)
<_ion> Automatic apport retrace? Yay!
<shawarma> _ion: Indeed. Just announced on u-d-d.
<_ion> Now if only the crash dumps were moved from bug report attachments to a separate service better suited for, well, crash dumps. :-)
<_ion> With links to both directions between bug reports and collections of crash dumps from different users related to the same crash.
<_ion> And top-N lists of specific crashes reported.
<pitti> _ion: https://wiki.ubuntu.com/CrashReporting
<heno> seb128: could you look at bug 93120 -- the failure to start gnome-settings daemon -- where should that be filed?
<Ubugtu> Malone bug 93120 in ubuntu-iso-tests "beta: Ubuntu i386 desktop" [Undecided,In progress]  https://launchpad.net/bugs/93120
<giangy> cjwatson: np :)
<heno> iwj: you might also want to look at the modem issue in that one (if you are still working on modems)
<_ion> pitti: This "Launchpad Oops" sounds nice. :-)
<seb128> heno: I'm wondering if that's an another dbus timeout bug, 10min is long
<seb128> heno: default choice would be control-center with a ~/.xsession-errors attached
<heno> seb128: ok, I'll recommend that, thanks
<iwj> Modem issue in err feisty livecd you mean ?
<heno> iwj: yes, people are filing real bugs under the ISO tests and I have to find real homes for them
<heno> iwj: the last comment on that bug
<iwj> I don't have the problem described there by Michael Losonsky.
<iwj> I think you should probably slap them down and ask them to file a separate bug so we can ignore it :-/.
<heno> iwj: slapping down is not the new community building way :)
<heno> but yes, I will suggest he file a different bug
<iwj> Sorry.
<heno> what should it be under?
<iwj> But it does WFM.  Well, aside from all of the stuff I said in the sl-modem MIR (which I should file bugs about ...)
<iwj> gnome-system-tools or something IIRC
<heno> ok, and the odd text you noted is that the dark blue on black?
<iwj> Yes.
<heno> that's a known issue in that case, ok
<iwj> Right.
<iwj> I thought it probably would be :-).
<iwj> heno: But I have to say I'm much happier stumbling across the bugs I'm finding now than in three weeks' time.
<heno> iwj: yep. I just hope not too many get lost in the 24000 list of open bugs
<heno> but that's another discussion 
<cjwatson> I closed 100 over the last day ;-)
<heno> cjwatson FTW!
<heno> I've only closed tracker bugs today
<cjwatson> greasemonkey scripts FTW
<pochu> pitti: doesn't work (the retrace)
<giangy> firefox 2.0.0.3 on the road.
<pochu> pitti: I added it, and the retrace service removed the tag again, but hasn't attached it
<pitti> pochu: bug#?
<pochu> pitti: bug 89848
<Ubugtu> Malone bug 89848 in listen "Listen crashes randomly when downloading missing covers" [Medium,Needs info]  https://launchpad.net/bugs/89848
<pitti> pochu: i386?
<pochu> yep
<pochu> need-i386-retrace tag
<pitti> pochu: 
<pochu> pitti: there is no coredump!
<pochu> hehe
<pochu> sorry :(
<pitti> report file does not contain required fields: CoreDump Package ExecutablePath
<pitti> pochu: :)
<pochu> I have a duplicated with a Coredump :)
<pochu> (I asked the reported to report it again with the cd)
* pitti just discovered that '/' works in screen's copy mode - nice
<Treenaks> I never understood copy mode properly
<pochu> pitti: you may want to disable the "short report" if there are no symbols
<pitti> Treenaks: so far I just used it to get scrollback in screen
<Treenaks> me too
<pitti> pochu: right, there's a bug for it
<pochu> ah, fine :)
<pitti> pochu: bug 87430 (poorly named, I know)
<Ubugtu> Malone bug 87430 in apport "do not accept short crash reports for firefox" [Low,In progress]  https://launchpad.net/bugs/87430
<seb128> pitti: k, I figured why a part of the crasher don't work with the retracer
* pitti hugs seb128, enlighten me! :)
<seb128> pitti: libc6 gets and not libc6-i686
<seb128> gdb complains about /lib/tls/i686/cmov/libc.so.6
<seb128> and backtrace is dump when the crashes happen to strdup, malloc, strlen or any libc function
<seb128> s/gets/gets installed
<pitti> seb128: /gets/ -> no match
<pitti> dump -> unusable?
<seb128> sorry, it was not clear ;)
<pitti> ah, I see
<seb128> it looks for /lib/tls/i686/cmov/libc.so.6
<seb128> which comes from libc6-i686
<seb128> but libc6 is installed
<pitti> seb128: apt-get install libc6-i686 helps?
<seb128> yep
<seb128> it fixes it
<pitti> seb128: so, let's just install this permanently into the chroots
* pitti fixes this in apport-chroot as well
<seb128> would be a good idea
<seb128> danke
<seb128> #0  0xb73078bc in _int_malloc () from /lib/tls/i686/cmov/libc.so.6
<seb128> (gdb) bt
<seb128> #0  0xb73078bc in _int_malloc () from /lib/tls/i686/cmov/libc.so.6
<seb128> #1  0xb7308ed5 in _int_realloc () from /lib/tls/i686/cmov/libc.so.6
<seb128> #2  0xb730b06e in realloc () from /lib/tls/i686/cmov/libc.so.6
<seb128> #3  0xb756b18b in IA__g_realloc (mem=0x85ad240, n_bytes=16) at gmem.c:168
<pitti> asac: ^ this could very well be the reason for your complaint as well
<seb128> #4  0xb757f85c in g_string_maybe_expand (string=0x8b0a0d0, len=<value optimized out>) at gstring.c:261
<pitti> seb128: argh flooding
<seb128> that's the retrace from bug #94158
<Ubugtu> Malone bug 94158 in nautilus "[apport]  nautilus crashed with SIGSEGV when having problems to access a SFTP folder" [Medium,Unconfirmed]  https://launchpad.net/bugs/94158
<seb128> http://librarian.launchpad.net/6875341/%3Cfdopen%3E is what the retracer did
<seb128> pitti: sorry, that was only 4 frames ....
<fabbione> cjwatson: ok. i will do it tomorrow. i am off for the evening
<pitti> seb128: urgh @ retracer output
<asac> pitti: hmmm interesting
<seb128> pitti: the flood is with libc6-686 installed
<seb128> it was doing the same than retraced without it
<pitti> seb128: thanks a million for figuring this out
<seb128> my pleasure ;)
<fabbione> cjwatson: oh i see it has been translated already
<seb128> pitti: let me know when you have the chroot update for that, I'll give a retry to #94158
<pitti> seb128: FYI for learning the tools: apport-chroot -p libc6-i686 -p libc6-i686-dbgsym -v upgrade chroots/feisty.tar.gz
<pitti> (doing now)
<seb128> pitti: ok, thank you
<pitti> done, digger started again
<seb128> bug tagged
<pitti> it is grinding away on that bug now
<mdz> mvo: I just tried do-release-upgrade -d and it says there is no new release
<pitti> seb128: seems we really need the ProcMaps scanning feature
<pitti> seb128: I mean, not just complain about missing libs, but actually find their packages and isntall them
<pitti> this would have caught this issue as well
<seb128> yeah, that would rock
<mvo> mdz: oh? it worked for me fine today, are you behind a proxy or anything?
<mdz> mvo: er, the second attempt failed as well, but the third seems to be working
<seb128> and that would make the retracer work when the crash doesn't happen to a Depends
<seb128> like apps crashing to scim
<seb128> or to a theme
<mdz> mvo: it is reproducible if I try several times
<seb128> or aspell, or whatever ;)
<mdz> mvo: maybe there is a problem with the server?
<mdz> mvo: it prints "No new release found" and then later a Broken pipe error comes through
<mvo> mdz: possible, can you strace it?
<mvo> mdz: let me check if I can reproduce it here
<pitti> seb128: yay, we have Contents.gz, so this should actually be possible
<mdz> mvo: ok, I have an strace of the failure
<mvo> mdz: could you put it to a pastebin or mail it to me? please?
<cjwatson> fabbione: yep, thanks
<fabbione> cjwatson: no problem..
<mdz> mvo: sent
<mvo> mdz: thanks! 4/4 tries worked here - lets see what the strace will tell me
<mdz> mvo: it seems to get the meta-release file OK (2168 bytes)
<mdz> mvo: and when I look inside it, I see feisty there
<mdz> mvo: nothing is written to /var/log/dist-upgrade
<pitti> seb128: argh, gdb failed with exit code 11 on that
<mvo> mdz: the only thing that I could think of (broken-pipe) is that something with lsb-release is breaking. it spawns that to get the currently runing distro
<seb128> pitti: :(
<mfd> mdz: hello
<pitti> seb128: hm, but it worked for you just after installing these two?
<mdz> mvo: there is no epipe or sigpipe in the strace
<pitti> seb128: i. e. worked in the fakechroot?
<mdz> mfd: hello
<pitti> seb128: trying myelf
<pitti> myself
<seb128> pitti: I used retracer-login-i386, apport-retrace -g -u --no-purge 94158, got the empty bt
<seb128> pitti: then I tried "apport-retrace -g -u --no-purge -p libc6-i686 94158"
<seb128> and that one worked fine
<orangey> hey all!
<orangey> Ben Collins has accepted a patch into the kernel that makes ide-acpi.c, however, it is not enabled in the kernel binaries
<orangey> what config do I play with to patch?
<orangey> I want to add the line: CONFIG_BLK_DEV_IDEACPI=y
<dholbach> orangey: best to try #ubuntu-kernel
<orangey> ah! thanks : )
<mvo> mdz: I think I found it, a race in the code. I will do a update tonight
<mvo> mdz: thanks for reporting!
* mvo -> dinner
<mdz> mvo: great, thanks
<hunger> How does HAL decide that suspend to disk is possible?
* hunger has 1GB RAM, 128MB video and 512MB swap and still hal thinks it can suspend to disk.
<mdz> it might very well be able to.  it's difficult to predict
<hunger> mdz: How so? tap says it has almost all the swap in use and only about 200MB in buffers or free.
<hunger> s/tap/top/
<hunger> Does it do compression?
<mdz> hunger: it depends very much on how your memory is being used, which varies depending on what's running and what you're doing.  much of that might be backed by files or otherwise able to be freed.  
<pitti> seb128: you tried with -g, right?
<mdz> we don't really know whether it will succeed until the kernel tries
<seb128> pitti:  pitti: then I tried "apport-retrace -g -u --no-purge -p libc6-i686 94158"
<seb128>  and that one worked fine
<pitti> seb128: that bug seems to have a infinitely recursing stack; I stopped gdb at stack level 3000 or so
<seb128> pitti: that's the command I tried
<seb128> ah ok, bad example then :/
<hunger> So hal actually calculates the ammount of swap a suspend to disk will take and uses that number to deterimine whether there is enough swap?
<seb128> pitti: I've another example if you want ;)
<pitti> seb128: with -s it sits there for literally minutes and then gives up
<pitti> seb128: tricky case :(
<pitti> seb128: oh, please
<mdz> hunger: no, hal probably only knows whether it's possible to attempt or not
<seb128> pitti: bug #94076, should I just tag it?
<Ubugtu> Malone bug 94076 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV in _dl_fini()" [Medium,Confirmed]  https://launchpad.net/bugs/94076
<pitti> seb128: I have the gnome environment here, it should be quick
<pitti> seb128: don't worry about tagging
<seb128> pitti: I tried retracing this morning it did work
<seb128> s/did/didn't
<hunger> mdz: So starting an attempt with half the RAM as swap space is safe to try?
<seb128> pitti: ok
<pitti> seb128: produces a wonderful trace now
<pitti> apport-retrace -s -u --no-purge 94076
<seb128> ;)
<mdz> hunger: if it won't fit, it gives up and your session continues
* seb128 hugs pitti
<sharms> hunger: if you have a reproducible issue with it, launchpad.net will get things done.
<pitti> seb128: ok, please go ahead and tag it, so that it'll land in the bug as well
<hunger> sharms: I dunno whether it is an issue, as it does indead suspend to disk but never wakes up again:-)
<mdz> hunger: the issue isn't a lack of swap space then
<hunger> mdz: I know. I just hoped reducing the swap size would trick that damn hal in declaring that suspend to disk is not an option.
<pitti> asac: please retry retrace tagging on some crashes which previously produced bad results
<asac> k
<hunger> mdz: I'll just buy more RAM and hope that it will then stop declaring suspend to disk to be working:-(
* pitti gets a really bad conscience about hogging both rookery and ronne with Python Scripts Of Doom
<mdz> hunger: it won't
<hunger> Or is there any way to stop hal from thinking suspend to disk is an option?
<mdz> I thought I just explained that
<_ion> pitti: Have you had time to review the restricted-manager modification? No hurry at all, i'm just curious whether the change was okay.
<pitti> _ion: sorry, not yet
<mdz> hunger: I'm not sure whether the current infrastructure still honors /etc/default/acpi-support, but that would be worth a try
<mdz> if you want to force disable it
<pitti> mdz: gpm should, hal shouldn't, AFAIR
<hunger> mdz: It does not:-( The powermanager explicitly override that setting.
<hunger> mdz: tracking down how to disable this in gnome-power-manager, guidance-power-manager and kpowersave (which are all the different PMs we use in our family) just sucks:-(
<hunger> All of them seem to not document how to do this (if it is even possible).
<hunger> Changing the hal settings just get reset to the default state on reboots:-(
<mdke> Seveas: only now
<mdke> Seveas: anything I can still do?
<Seveas> mdke, yes, right on time
<mdke> shoot
<Seveas> plase join #ubuntu-meeting, when _MMA_'s membership application is done, MagicFab has a question on wiki licensing
<mdke> sure
<pitti> Mithrandir: I uploaded four language-support- packages to remove some openoffice-help- dependencies which don't exist any more; this does not affect CD images
<jtholmes> can someone point me to the wiki page outlining the procedure for altering source code packages and getting them back into the devel stream
<jtholmes> once they are changed
<jtholmes> and approved
<pitti> jtholmes: https://wiki.ubuntu.com/MOTU/School/PatchingSources might be interesting
<pitti> (the altering part)
<jtholmes> pitti: thanks
<jtholmes> ok
<pitti> jtholmes: https://wiki.ubuntu.com/UbuntuDevelopment
<jtholmes> thanks again, wonder who the author is on the patchingsource doc??? 
<pitti> jtholmes: me :)
<jtholmes> appreciate both references
<jtholmes> yes that is why i asked
<jtholmes> btw how do you put a smiley face on the msg
<pitti> jtholmes: maybe your IRC client translates colon-parenthesis to real smileys
<jtholmes> yes i just got on chatzilla help and it does :-)
<jtholmes> thanks :-)
* pitti -> off for the evening, cu tomorrow
<ajmitch> morning
<Mithrandir> ogra: edubuntu> building new ISOs
<Mez> Errors were encountered while processing:
<Mez>  /var/cache/apt/archives/hotkey-setup_0.1-17ubuntu6_i386.deb
<Mez> E: Sub-process /usr/bin/dpkg returned an error code (1)
<Mez> http://rafb.net/p/SSg1vy75.html
<ajmitch> filed a bug?
<Mez> getting that on my latest dist-upgrade
<Mez> ajmitch, nope... just posting in here quickly incase its a known issue
<ajmitch> that misses the error completely
<ajmitch> ah, the paste has it
<Mez> ajmitch, indeed :D
<Mez> I realised that which is why I made the paste
<ajmitch> doesn't appear to be filed, at a glance
<Mez> second time I've hit it actually :D
<Mez> ajmitch, file against feisty, or the package ?
<ajmitch> against the package
<Mithrandir> ogra: build complete, both ports and normal.
<wereHamster> \sh, hi
<\sh> wereHamster: hey :)
<wereHamster> \sh, I've heard you were the ubuntu wine maintainer.. correct?
<\sh> wereHamster: well, I package scotts wine packages for ubuntu, but yes, somehow
<\sh> s/package/repackage/ better to say
<wereHamster> situation: when one user used my software together with ubuntu's official wine package it wouldn't work, but after he compiled wine himself it worked.
<wereHamster> question: does ubuntu patch vanilla wine somwhow? Is there something that could make wine not compatible with my software?
<\sh> wereHamster: well, when he is using the provided build-essentials from ubuntu, and the same source package from ubuntu, he will normally get the same result as from our build servers
<wereHamster> oh.. 'my software' = http://neopsis.com/projects/yukon/
<Burgwork> wereHamster: likely the version of wine is old
<wereHamster> by 'he compiled wine himself' I mean not from a deb source package, but from a clean wine tarball
<\sh> wereHamster: neither scott nor I patch wine with patches from dev tree of winehq or something...there was only one version where I patched away a bug from upstream (with a patch provided by upstream)
<\sh> wereHamster: and since 0.9.32 it's fixed in upstream already...so the tar balls are from upstream...(means what you can download from winehqs sf.net pages)
<\sh> wereHamster: most likly it's a problem with old .wine profiles.
<\sh> wereHamster: if you have bugs, please open it on lp for the package wine...I need the compile settings etc. and a backtrace is also very useful when using ubuntus wine packages...
* \sh needs to go to sleep now...still sitting in the office :(
<\sh> cu tomorrow
<Riddell> Mithrandir: is there a decent chance of the current ISOs being the betas (is the nightly cronjob disabled etc)?
<Mithrandir> Riddell: yes.
<Riddell> I'll download the DVDs overnight
#ubuntu-devel 2007-03-21
<racarr> Has anyone had a chance to look at the Beryl package set in NEW yet?
<geser> racarr: you might have a better chance to get an answer during day hours in europe
<geser> it's past midnight here
<racarr> geser: Ok, it's not that important presumambly someone will look over them in the near future, I was just curious
<hikenboot_> why is it every version of ubuntu has it system depend upon stupid things like serpentine audio cd creator and bittorrent...how about making these this optional without removing one causing ubuntu-desktop to be uninstalled...at least fiesty fawn made openoffice optional!
<keescook> Mithrandir (or other archive admin): please shove the breezy/dapper/edgy inkscape updates.  :)
<sharms> hikenboot_: because those packages are what composes the "ubuntu desktop"
<hikenboot_> right but removing them prevents upgrading
<sharms> you can still upgrade without bittorrent or the ubuntu-desktop package
<racarr> sharms: But you wont get new packages added to ubuntu-desktop
<racarr> it seems to me like some sort of Install-Depends field would make sense
<sharms> racarr: if you are removing items included in it, then it is clear you dont want them anyway
<sharms> if you dont like the defaults, install what you want.  Issue solved.
<racarr> sharms: ...I don't think it's fair to assume that because someone doesn't want open office they don't want every other package added to ubuntu-desktop in the future
<hikenboot_> when i went to remaster this last time I had a problem where when I was trying to install the packages I did want it would try and reinstall ubuntu desktop and all the packages I removed
<Burgwork> hikenboot_: a bunch of things have been moved to desktop-recommends, from desktop
<racarr> err, right I forgot about recommends, hehe
<Burgwork> hikenboot_: you are welcome to upgrade by other means
<sharms> hikenboot_: if a package depends on ubuntu-desktop that shouldn't, use launchpad to file a bug
<Hobbsee> sharms: "shouldnt" is a relative term.  sure you mean a package depending on ubuntu-desktop, or ubuntu-desktop depending on a package?
<mdz> hikenboot_: as you noticed, we've already changed this for many applications in Feisty, and that work will continue.  we're now approaching beta status now, though, and we'll be focusing on stabilization instead for the next month
<sharms> Hobbsee: I mean if a package depends on ubuntu-desktop
* Hobbsee tries to figure out how that works
<mdz> sharms: nothing should depend on ubuntu-desktop unless it is meant to imply the rest of the default desktop install (e.g., a derivative metapackage)
<hikenboot_> yes i have noticed that the worst one...open office was moved to recommends...this is greatly appreciated...at least now I can use it for my purposes
<sharms> mdz: from what he was saying, apparently he had a package that did
<sharms> that is why I invite him to report it :)
<racarr> err
<Hobbsee> the dist-upgrader requires ubuntu-desktop, yes...
<racarr> I thought we were talking about ubuntu-desktop depending on packages 
<mdz> sharms: it sounds more like he wanted to install a package which conflicted with a dependency of ubuntu-desktop
<sharms> "when I was trying to install the packages I did want it would try and reinstall ubuntu desktop and all the packages I removed"
<mdz> the upgrader does that
<hikenboot_> thanks guys and have a great night
<sharms> good luck!
<sharms> Hobbsee: is that "shouldn't" issue a UK thing?
<Hobbsee> sharms: well, forums keep saying that network manager shouldnt be a dep of ubuntu-desktop, as it's too buggy, etc, etc...so i was hoping to avoid those kind of bugs
* Hobbsee waves to jono 
<jono> hi Hobbsee :)
<sharms> Hobbsee: oh no, I meant I thought you were correcting my usage of the english language
<Hobbsee> sharms: ahh.  nope :)
<Dabian> How do I get rid of a broken package?
<Dabian> (sorry for asking here .. but I don't think I can go anywhere)
<Hobbsee> Dabian: you shoot it.
<sharms> #ubuntu can help
<Dabian> sharms : It didn't so far.
<Hobbsee> #ubuntu can help, especially if you give them more information.
<Hobbsee> like, maybe which package it is.
<Dabian> sharms : I have trouble with irda-utils for amd64.
<Hobbsee> and which release you're on
<Dabian> Hobbsee : I am not sure
<Dabian> Hobbsee : My system borked while I was upgrading.
<Dabian> Hobbsee : To fiercy dawn, from 6.10
<Dabian> edgy?
<sharms> Dabian: if you want to kill it, then apt-get remove --purge packagename works for me
<sharms> I am running fiercy dawn right now
<Dabian> sharms : Can I paste the errors I get from that now?
<Hobbsee> feisty fawn, you mean.
<Hobbsee> Dabian: try #ubuntu+1 for feisty support.
<sharms> Personally I like fiery dawn
<Hobbsee> hehe
<Dabian> dpkg: error processing irda-utils (--purge):
<Dabian>  Package is in a very bad inconsistent state - you should
<Dabian>  reinstall it before attempting a removal.
<jdong> ow.
<jdong> that's more like fubar down
<Dabian> yah
<Hobbsee> depends on why it's actually broken
<jdong> Dabian: at that point I usualy start taking a text editor to /var/lib/dpkg/state
<cjwatson> Do what it says; 'dpkg -i /var/cache/apt/archives/irda-utils_*.deb'
<Dabian> jdong : Thanks.
<jdong> but listen to cjwatson 
<cjwatson> DO NOT EDIT /var/lib/dpkg/status BY HAND UNLESS YOU ARE AN EXPERT
<Hobbsee> jdong: stop giving out crackful info.
<Dabian> cjwatson : Heheh .. or a complete idiot, right? :)
<Hobbsee> on that basis
<sharms> cjwatson: he is running fiercy dawn, he should be fine
<jdong> sorry :)
<cjwatson> i.e. unless you can competently fix bugs in dpkg
<Dabian> cjwatson : I get error from that as well.
<cjwatson> the dpkg -i above may error out, but it should let you get further; 'dpkg --configure -a' is often the next step
<cjwatson> then repeat the upgrade
<Dabian> heh .. yeah .. why didn't I try dpkg --configure -a 
<Dabian> I get the same error as pasted above though.
<cjwatson> what was the error from dpkg -i? (if it's long, use paste.ubuntu-nl.org or similar)
<cjwatson> fwiw, that error from dpkg usually means that it was interrupted hard (e.g. segfault, poweroff) at a very bad point
<Dabian> how do I redirect to file?  2>&1 > file.txt 
<Dabian> ?
<cjwatson> >file.txt 2>&1
<Dabian> hehe .. better prepend with "LANG=C" :)
<jdong> cjwatson: yeah I've done that "package is very inconsistent" thing after a few hard resets....
<jdong> it was a pain to get out of it
<calc> anyone know of a simple way to effectively evict all cached pages on a system
<calc> eg read a bunch of zeros into memory or something
<Dabian> http://paste.ubuntu-nl.org/11271/
<Burgwork> calc: please use #ubuntu for support, this is a development channel
<Dabian> I powered off the computer last night .. I don't know how far the upgrade was.
<Dabian> Actually I was just turning off teh stereo, I forgot the computer was on.
<Dabian> (I hoooked my system up so that turning off the stereo automagicly turns off the computer w/monitor at the same time)
<cjwatson> Dabian: first run 'sudo start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/irattach.pid --exec /usr/sbin/irattach'
<cjwatson> Dabian: then edit /var/lib/dpkg/info/irda-utils.prerm (as root) and change 'invoke-rc.d irda-utils stop || exit $?' to ': invoke-rc.d irda-utils stop || exit $?' (i.e. put colon-space in front of that line)
<cjwatson> Dabian: then repeat the dpkg -i from earlier, which should let you continue
<sharms> cjwatson: did you just know that off the top of your head?
<cjwatson> calc: install moreutils, then 'sponge </dev/zero'
<cjwatson> ctrl-c when you get bored
<Hobbsee> sharms: cjwatson lives in this kind of stuff, and debian-installer
<cjwatson> sharms: no, I looked up what the prerm did and determined how to safely replicate it
<Hobbsee> cjwatson: can i ask what the : in front does?  or point me to somewhere where it's documented?
<cjwatson> these aren't exactly user-serviceable parts normally
<cjwatson> Hobbsee: man :
<cjwatson> hmm, or not
<cjwatson> Hobbsee: help :
<Hobbsee> hehe
<Hobbsee> or not
<Hobbsee> ahhh, nice
<cjwatson> it's the same as /bin/true
<Hobbsee> gotcha
<calc> cjwatson: thanks
<cjwatson> it's better than # in this case because if you use # there'll be no command between the then and the else and you'll get a syntax error
* calc feels like he lost most of his linux knowledge in the past year :\
<calc> i need to stop using xp
<calc> it makes my brain rot
<sharms> calc: we're not stopping you from running Ubuntu
<calc> sharms: i'm running it now
<calc> sharms: i only had one pc until a few months ago and my gf made me run xp ;)
<sharms> General chitchat for ubuntu type people: #ubuntu-offtopic
* calc needs to upload new versions of his abandoned packages
<Hobbsee> cjwatson: ahhh....
<Dabian> calc : Just tell her .. "OK, I'll run XP .. but no sex as long as XP is on that computer, comprende?"
<Dabian> cjwatson : You're amazing!  I got rid of it painlessly!
<bddebian> hah
<Dabian> I wonder if commercial support of this level is available here in Denmark.
<cjwatson> Dabian: woo, good to hear
<Dabian> cjwatson :)
<Hobbsee> Dabian: quite likely.  
<Dabian> Would be nice .. they're not listed though.  Well a few is listed .. judging from their webpage its hard to say; I guess.
<Hobbsee> Dabian: http://www.ubuntu.com/support
<Dabian> Hobbsee : Yess.
<cjwatson> I think Canonical's support operates globally, FWIW.
<Hobbsee> it seems to
<Dabian> http://www.ubuntu.com/support/commercial/marketplace/europe
<Hobbsee> Canonical Global Support Services are deployed around the world to enable a true 24x7 support infrastructure. Support requests are handled through telephone, e-mail and the web.
<Dabian> Hobbsee : Its not in danish though, I guess.
<Hobbsee> Dabian: true that.
<sharms> But if I call Canonical support, I dont hear "Hello, this is cjwatson.  How can I help you?"
* Hobbsee tries to remember who here's with linux2go.dk
<Hobbsee> one of the guys in -motu, iirc
<Dabian> Hobbsee : You can recommend linux2go?
<Dabian> Hobbsee : I vaguely remember having checked their website.
<cjwatson> sharms: you don't want me doing support full-time, trust me; I don't have the patience
<Hobbsee> Dabian: well, i've never dealt with them myself, obviously, not speaking danish, but one of the guys there, Soren Hansen, is oftne on #ubuntu-motu
* Hobbsee just recognised the address
<Dabian> -motu?
<Hobbsee> Dabian: ubuntu universe packagers / developers
<Hobbsee> Dabian: http://wiki.ubuntu.com/MOTU for reference
<Dabian> cjwatson : Hehe .. I get we got a taste of that when you saw him recommending me to fumble with that status file ;-)
<Hobbsee> hehe
<Hobbsee> yes - in here, a lot of support queries, in fact, almost all, get redirected elsewhere, as it's not on topic.
<Dabian> Yeah .. I thought my request was special .. otherwise I wouldn't have bugged you.
<cjwatson> prerm failures are unfortunately notoriously hard to work around
<Hobbsee> true that.  once there was enough info in it, of course :)
* cjwatson -> bed
<Hobbsee> night cjwatson 
<Dabian> now the upgrade is slowly rolling like it should in the background... I guess next time I better put a warning on the computer "don't turn off now!" ;-)
<Hobbsee> hehe
<Hobbsee> that would *always* help, yes
<Hobbsee> shawarma: ah, you are in -devel.  see Dabian when you get back.
<Dabian> Since ext3 .. I'm often too lazy to do a clean shutdown.
<Dabian> btw
<racarr> a lot more goes on during a shutdown than syncing the disks :p
<Dabian> WHen I have upgraded .. I'm going to try and install "jde" .. if its still broken in fiesty fawn, and I want to help fix it .. how do I go about it?
<Dabian> racarr : Yeah .. but a desktopcomputer should be able to cope .. or there is an error in a userspace program. :)
<Dabian> racarr : I try to do a clean shutdown .. but I admit, sometimes I am too lazy .. if I am heading out the door or something.
<Dabian> I made it so that I can just click the powerbutton, and it will shutdown.
<Dabian> No questions asked. :)
<Hobbsee> Dabian: determine how it's broken, make a patch, submit it.  it installs on feisty, it seems
<Dabian> Hobbsee : You code java?
<Hobbsee> Dabian: nope
<Hobbsee> Dabian: not a bit
<Dabian> ahh .. you just installed it to check?
<Dabian> Do I need an email that will be exposed to the web to submit a patch?
<Dabian> racarr : What in paticular do you think I miss by simply cutting the power?
<racarr> Dabian: https://wiki.ubuntu.com/Teardown has a list of that Teardown does, and you can workout what you miss by just cutting the power :p
<_ion> An idea about how Upstart jobs might interact with the user regardless of what's the visible interface: virtual console, boot splash or X. http://johan.kiviniemi.name/blag/2007/03/21/upstart-and-interaction-with-user/
<Hobbsee> Dabian: yep.  yes - well, it'll be hidden on launchpad, so it shouldnt get spammed
<Dabian> S30urandom
<racarr> _ion: I think that's the wrong direction personally 
<Dabian> Hobbsee : Thats good news.
<_ion> racarr: What would you propose?
<Dabian> Hobbsee : That was one of the major reasons I didn't even consider contributing to debian.
<Hobbsee> ahhh
<Dabian> I dislike spam.
<racarr> _ion: Aiming for eliminating the transitions, heh, I know Kristian Hogsberg (I tihnk it was Kristian? it was someone from redhat) has done some work on X in the initramfs, I'm not sure that's the solution
<Dabian> I get my mail on yahoo, so I can't just run spam-assassin.
<racarr> And it's impossible to have two email addresses...
<racarr> (Sorry, I couldn't resist)
<_ion> racarr: This should work even with boxes with no monitor, only a serial console.
<Dabian> racarr : Isn't it Kristian Hgsberg?
<Dabian> sorry .. lets try again in UTF8 :)
<Dabian> racarr : Isn't that Kristian Hgsberg ?
<Hobbsee> Dabian: ahhh, yes.  that's annoying.
<Dabian> Many prefer latin-1 still.
<racarr> Dabian: Yes, but I assumed people would forgive me for just using an o :p
<Dabian> :)
<Dabian> racarr : Actually you can use "oe" instead of '', if yor keyboard support it not.
<Dabian> racarr : I even do that in subjects of mail, to obey rfc822.
<racarr> _ion: I suppose that's a reasonable advantage, yes
<racarr> Dabian: Eh, I can just use the Compose key, just too lazy
<Dabian> (I know there is a mime-rfc that says the mta needs to convert it to qouted printable .. but that is disgusting. :)
<cjwatson> sharms: any luck on bug 85835 (maybe retest with a newer milestone)? I'm going to have to reject it if there's no more information
<Ubugtu> Malone bug 85835 in ubiquity "New partitioner does not work with NTFS existing drives" [Undecided,Needs info]  https://launchpad.net/bugs/85835
<Dabian> or is it the MTU?
<_ion> racarr: Not to mention blind users.
<_ion> racarr: They need to interact with fsck as well.
<sharms> cjwatson: haven't done a fresh install since I initially tried it, so no further information
<Dabian> not mtu ... MUA of course
<Dabian> darn ... I've been having it too easy too long.
<racarr> _ion:  I don't see why that requires everything to be done through a terminal, theres no reason a screenreader/all the other accessibility stuff couldn't be used
<cjwatson> sharms: do you plan to?
<_ion> I didn't say the support for blind users should be done through a terminal.
<sharms> cjwatson: no, could only reproduce it on my production station which I can't fuss with
<racarr> _ion: then why is this library required to allow blind users to interact with things during the startup process? things can just use the preexisting accessibility frameworks?
<_ion> It gives the option of *any* implementation for *any* use case regarding user interaction.
<cjwatson> sharms: probably bug 89004; rejected anyway, thanks
<Ubugtu> Malone bug 89004 in partman-base "Wonky partitioner choices in alternate cd" [Critical,Fix released]  https://launchpad.net/bugs/89004
<sharms> cjwatson: yeah I hate it when those bug reporters don't provide enough information :)
<racarr> _ion: I suppose, but  as you suggested upstart integration it seems like it would be reasonable to assume it would be however Ubuntu is set up (which will hopefully be less transitions in the future)
<sladen> BenC: is there anything useful I can do on the ICH6 non-boot issue in -12?
<BenC> sladen: bug number?
<sladen> BenC: bug #93648
<Ubugtu> Malone bug 93648 in linux-source-2.6.20 "2.6.20-12 fails to boot with ICH6 SATA (ahci_init_one/pci_iounmap BUG at lib/iomap.c:254)" [Critical,Confirmed]  https://launchpad.net/bugs/93648
<sladen> 10 dups
<mjg59> sladen: Figure out why it's hitting the BUG_ON in iomap.c
<sladen> mjg59: while you're here, any new ideas on bug #90883
<Ubugtu> Malone bug 90883 in acpi-support "wireless.sh cannot use 'device/power/state' to power-off wireless card anymore (dup-of: 89763)" [Undecided,Confirmed]  https://launchpad.net/bugs/90883
<Ubugtu> Malone bug 89763 in acpi-support "Changes in sysfs power/state handling has broken 'ibm-wireless.sh'" [Medium,Confirmed]  https://launchpad.net/bugs/89763
<mjg59> It's unfixable
<sladen> is it an option to just add back in the code upstream removed
<mjg59> To an extent
<sladen> my understanding is that you can put the device to sleep by writing to the raw PCI registers in a gash way anyway
<mjg59> But the driver won't know that
<mjg59> = explode
<sladen> the code in the drivers has remained unchanged, just the functionality to call the code from userspace via sysfs has gone
<mjg59> Yes
<racarr> Can anyone get to archive.ubuntu.com right now?
* Fujitsu prods archive.ubuntu.com
<Fujitsu> (that was a no)
<Fujitsu> Can somebody poke somebody appropriate about {archive,cdimage}.ubuntu.com
<Fujitsu> *?
* Hobbsee feeds Fujitsu a clock
<Fujitsu> Gah.
<sladen> works for me.  What IP address are you getting from  'host archive.ubuntu.com' ?
<Fujitsu> 91.189.89.8
<Fujitsu> I've seen 2 others confirm that it's dead.
<BenC> sladen: I checked into that...looks like a bug where the device is not getting created fully during probe, and the error path is unmapping an io region that was never mapped
<_ion> I get 91.189.89.6 and 91.189.89.8 and neither seems to work.
<BenC> sladen: Probably best bet is to find out why the probe is failing in sysfs creation
<Fujitsu> _ion: Same.
<Fujitsu> Doesn't get out of cogentco.
<Fujitsu> Gets to London, that's all.
<racarr> sladen: What are you getting for archive.ubuntu.com? (so I can add to /etc/hosts and do an update/upgrade :p)
<Fujitsu> Same from a box in the US...
<racarr> I'm in the US and get 91.189.89.8
<sladen> ah welcome to cogent, the box-shift of the IP transit world
<sladen> shifter
<KurtKraut>  When I insert a USB pendrive on Feisty it is automounted without giving me write permissions. I suppose this is a bug. In what package I should file it as  bug on Launchpad ?
<hile> there is just a maintenance break on archive.ubuntu.com - I got a mail for that, just dont remember which list
* Fujitsu is on an insane number of Ubuntu lists, and didn't get one.
<hile> maybe I was dreaming ;)
<mdz> Fujitsu: was the same here, I started to escalate it but it seems to have cleared itself up here
<Fujitsu> Indeed, it's fine now.
<sharp5> is GSoC stuff on-topic in here?
* Starting logfile irclogs/ubuntu-devel.log
<sladen> Mithrandir: acpi-support_0.93 to fix various wireless/hotkey things;  there's some state-saving stuff still to do later
<giangy> 'morning
<wringer> hello
<wringer> can you guys give feedback on ideas for the google summer of code?
<doko> wringer: any specific project?
<wringer> doko: is the the place to talk about it?
<wringer> you guys are kind of specific on what topics of conversation are allowed in this channel
<doko> wringer: you can email ubuntu-soc-owner@lists.ubuntu.com as well
<wringer> doko: but this place is fine too, right?
<doko> wringer: sure
<wringer> doko,  thanks
<nekomancer> hello?
<Hobbsee> h
<Hobbsee> i
<Treenaks> morning
<nekomancer> doko: one of my friends directed me here to see about two different ideas i am considering to try for in google's soc
<doko> nekomancer: did you write a spec for these ideas?
<nekomancer> doko: not as of yet
<nekomancer> doko: i just discovered that the soc program is underway today
<nekomancer> doko: i was mostly wondering if ideas would fit into anything here at all
<nekomancer> doko: the one i like would be to see about improving the dual boot use ability of ubuntu/windows
<nekomancer> doko: adding a reboot menu like SUSE use to have, a FAT32 partition to the default partition layout if they are dual booting with windows, and 
<nekomancer> doko: a ap that would collect .exe locations in 'program files' and try to set them up with wine in their own menu
<nekomancer> doko: it just didn't sound very deep in the ubuntu ideals, but more of a thing you would expect novell to do now
<nekomancer> doko: having said that, something like that would be nice for people who are changing from windows to Ubuntu
<doko> nekomancer: you have to apply for a project until Mar 24; based on these details projects are choosen. if you can up with something more specific by this date, submit the project
<nekomancer> doko: would that be an ok general idea to peruse further?
<nekomancer> doko: thanks for listening
<doko> nekomancer: sure, but applying is not yet the same thing as beeing accepted for the project
<nekomancer> doko: i know
<nekomancer> doko: i have read over the rules and such.  I was just wondering if that idea, in general, was valid or not
<nekomancer> doko: it doesn't seem much like a 'free software' appeal
<nekomancer> doko: i remember the uproar about adding nvidia drivers to Fawn
<doko> nekomancer: I don't see anything wrong with improving the dual-boot options for the user; I currently cannot say anything about the size of the project (if it's suited to the SoC)
<nekomancer> doko: Thanks.  I wanted to know if that general idea would be seen as non free software-ish
<nekomancer> Have a good night/morning all
<Mithrandir> keescook: unsure where and how to shove; I can't find any in the queue.
<Hobbsee> heya Mithrandir - can you accept klamav please?  (it's universe)
<Mithrandir> Hobbsee: sure, done.
<Hobbsee> Mithrandir: thanks :)
<Hobbsee> Mithrandir: can non-core devs use the milestones?
<Hobbsee> ie, are tehy allowed to
<Hobbsee> ?
<Mithrandir> Hobbsee: allowed to assign bugs to them?  Sure, but please tag the title with [universe]  or something if it's not a bug in main.
<Hobbsee> Mithrandir: it's main.  i didnt think you could assign bugs to a milestone...
* Hobbsee is finding bug fixes made upstream that are marked as critical, that arent in ubuntu
<ajmitch> Hobbsee: using upstream bug lists, or the rc bug list I made?
<Hobbsee> ajmitch: using my email, actually.  does yours do kde bugs?
* ajmitch knows we should get working through that list
<ajmitch> it does all debian RC bugs
<Mithrandir> Hobbsee: I would much, much rather have to remove a bug from the milestone list because I don't think it's critical than missing out on a critical bug because somebody thought they shouldn't use the milestone feature.
<Hobbsee> Mithrandir: gotcha.  at the moment, i've just assigned those ones to myself, wehther i upload them or not
<Fujitsu> pitti: How long does a retrace normally take? (I tagged a bug, the tag vanished a few minutes ago, but there is no result yet)
<dholbach> good morning
<ajmitch> daniel!
<ajmitch> good morning :)
<dholbach> hey andrew
<pitti> Good morning
<pitti> Fujitsu: when the tag vanished, it was processed
* dholbach hugs pitti
<pitti> Fujitsu: there was something wrong with it, what was the #?
<pitti> hi dholbach 
<ajmitch> morning pitti 
<pitti> hi ajmitch, how's it going?
<ajmitch> good, how are you?
<pitti> great!
<Fujitsu> pitti: Does it remove the tag when it takes it for processing, or when it uploads the trace?
<pitti> Fujitsu: when it takes it, to avoid endless loops when something goes wrong in the retracing
<pitti> Fujitsu: I can have a look into the log, what was the bug number?
<Fujitsu> It eventually got retraced, so it's fine.
<Fujitsu> Just took a while.
<pitti> ah, cool
<pitti> Fujitsu: usually takes ~ 5 minutes for large packages/many dependencies
<pitti> I need to speed it up by a magnitude, but ENOTIME :/
<hunger> Is archive.ubuntu.com down?
<Fujitsu> I wonder if a retrace-in-progress tag might be useful, otherwise we're likely to have a few people each putting a retrace tag on, when it is already retracing.
<pitti> hunger: seems so, cdimage.u.c. is down as well
<Fujitsu> It's up here, but is pointing to a different place to what it was earlier.
<Fujitsu> It went down, came back pointing to prat, and is now at forster (again?)
<Mithrandir> cdimage.u.c is fine.
<Fujitsu> Ah, I see it points randomly to either.
<Fujitsu> It's all fine for me, anywya.
<Fujitsu> *anyway
<hunger> Wow, great, restricted-manager got me fglrx support but I can not turn it of again using it since my xorg.conf is customized:-(
<ajmitch> Mithrandir: blktrace confirmed
<Mithrandir> ajmitch: cheers.
<dholbach> can somebody please sync libtelepathy
<dholbach> bug 92799
<Ubugtu> Malone bug 92799 in libtelepathy "Please sync libtelepathy from sid" [Medium,Confirmed]  https://launchpad.net/bugs/92799
<hunger> Why does changing the x graphics driver change all font sizes? They are 2pt smaller than they used to be after going to fglrx and back.
<pitti> dholbach: will do
<ajmitch> hunger: DPI detection, I think
<dholbach> pitti: thanks a lot
<hunger> ajmitch: Why does that change the actual font sizes?
<ajmitch> hunger: does the configured font size change, or just how it appears?
<hunger> ajmitch: I could understand that the fonts are rendered at a different size, but I used to have 12pt fonts set and after switching to fglrx and back I only have 10pt.
<ajmitch> odd
* ajmitch has only seen that in the past with gnome-settings-daemon not starting properly
<ajmitch> which was awhile ago now
<pitti> ajmitch: that might have been fixed with moving dbus from S20 to S12 again
<HiddenWolf> hunger: same here
<pitti> dholbach: done
<dholbach> pitti: you rock :-)
<hunger> HiddenWolf: Good, I was already doubting my sanity.
<dholbach> pitti: after rebuilding gossip-telepathy with it people can install it again :-)
<HiddenWolf> hunger: not messing with a user-modified config-y file is quite sane though.
<pitti> Mithrandir: is 20070320.1 still the latest live image? I can't reach cdimage.u.c AT>
<pitti> Mithrandir: s/>/M/
<hunger> HiddenWolf: You are talking about the not going back from fglrx with restricted-manager thing?
<hunger> HiddenWolf: My config file was modified and it did convert it to use fglrx instead of the ati driver. Chickening out of reverting that seems rather strange to me.
<Mithrandir> pitti: yes, 20070320.1 is the latest.
<HiddenWolf> hunger: ah. 
<Mithrandir> pitti: can you reach it through chinstrap?
<pitti> Mithrandir: ah, yes, I can
<pitti> thanks, going to do the final test with that on real hardware then
<Mithrandir> cheers.
<dholbach> hey mvo
<mvo> hey dholbach!
<LaserJock> when does seb usually show up? or is he on vacation?
<dholbach> LaserJock: in a bit, I guess - he's not on VAC
<dholbach> LaserJock: it's 09:53 in his part of the world
<doko> ogra, Mithrandir: is the size of the edubuntu dvd really correct? 860172288 
<dholbach> heya doko
<doko> hi dholbach, late morning for you ;)
<dholbach> doko: late morning? I was up at 7:20 already ;-)
<dholbach> (but yeah, started working a bit later than that :-))
<LaserJock> doko: that seems wrong to you? the size for Edubuntu dvd
<doko> LaserJock: it's 800MB ... for a DVD
<LaserJock> well, at least it's >700MB :-)
<racarr> err, I seem to think I downloaded an Edubuntu DVD a while ago
<racarr> and that it was a lot larger than that
<LaserJock> doko: that's about the size of the contents of the CD
<LaserJock> so I'd guess it lost the rest of the DVD contents
<dholbach> hey seb128
<seb128> hi dholbach
<seb128> dholbach: not sure than retracing mono crashes is useful
<seb128> I skip them usually
<dholbach> seb128: I think I successfully retraced one already and it looked better than before
<dholbach> but I'll try to make sure
<seb128> dholbach: you retrace the interpreter, doesn't give much information on the bug afaik
<seb128> no?
<dholbach> ok, that depends on where the crash happens - in my case it was maybe in the C lib
<seb128> dholbach: I was not pointing a particular crash, I just thought that crash file were not useful for mono apps atm
<seb128> will ask slomo about it
<dholbach> ok
<dholbach> Mithrandir: the gnome-games update is nothing urgent
<heno> asac, cjwatson, dholbach, doko, ogra, pkl: any luck with ISO testing yesterday? 
<Enola_Gay> hi all
<heno> I'm not seeing many reports on https://bugs.launchpad.net/ubuntu-iso-tests/+bugs
<Enola_Gay> Wasn't there plans to integrate a failsafe vga mode or something like that in Feisty?
<Mirv> Enola_Gay: well, at least the safe vesa mode works now, unlike in ubuntu 6.10. however, the "bulletproof-x" spec has not been updated so I don't know if there's automatic fallback in all of the error cases.
<Enola_Gay> Mirv thanks, I thought there would be an extra grub option like the safe mode
<doko> heno: no, the edubuntu dvd images has a size of just 800MB which seems to be wrong
<heno> doko: it does indeed, thanks
<Enola_Gay> current Feisty  xorg seems to be broken, at least on my system
<Enola_Gay> And does anyone know if Feisty has a grub repair option on the desktop or installation cd?
<Mithrandir> Enola_Gay: no, there was no time for bulletproof-x.
<Enola_Gay> Hm, that was quite important, at least in my oppinion.
* hunger agrees.
<Enola_Gay> But who cares if Feisty is stable.
<hunger> Enola_Gay: But what can you do... other stuff is important as well.
<Enola_Gay> I know :)
<dholbach> heno: were the DVD images updated? if so, I'll give it a go now
<hunger> Enola_Gay: At least it does soom to boot for you:-) my kernel is hosed:-(
<Enola_Gay> It is just for new users a grub repair function and a safe xorg would help a lot.
<Enola_Gay> hunger The default kernel?
<asac> heno: yes ... let me finish some tests :) ... wait an hour
<hunger> Enola_Gay: Yeap. -12-generic.
<hunger> THe -9-generic works great though, so I can at least work.
<Enola_Gay> strange, seems to work fine for me. At least X doesn't start again with 11. I am going to check the xorg.log. cu all
<heno> dholbach: the timestamp is later than the CD builds by 3-4 hours, but Mithrandir would know
<heno> Mithrandir: were the dvds updated?
<heno> asac: ok, thanks :)
<Mithrandir> heno: they were rebuilt around 1600 UTC yesterday.
<dholbach> i just cleaned a fast disk, so i can do it now
<heno> Mithrandir: the edubuntu ones seem broken, fyi
<heno> 800MB
<asac> heno: so far went well ... however i killed my vmware run yesterday - trying to start glxgears :) ... that killed my vm and I forgot to finish :)
<heno> ah, ok. yeah graphics is still tricky in VMs
<asac> heno: any need to investigate vmware crash due to glxgears?
<pitti> did anyone recently test i386/desktop and could check/confirm/nack bug 94359 for i386?
<Ubugtu> Malone bug 94359 in linux-restricted-modules-2.6.20 "amd64 live system does not have nvidia/fglrx kernel modules" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94359
<pitti> Mithrandir: ^ or does this happen to be deliberate? (no non-free drivers on live CD)
<asac> pitti: i would have to reboot to test this, but judging from screen was projected to monitor the fglrx drivers had not been used
<pitti> asac: right, they are not supposed to be enabled by default; but they should be available
<asac> pitti: let me see
<pitti> after all, we already ship l-r-m and the .o files, but the .ko ones are not built
<Mithrandir> heno: looks like a bug in the edubuntu two-cd setup.
<pitti> but we do ship other .ko files
<pitti> asac: vmware :)
<asac> yes
<Mithrandir> cjwatson,ogra : ^^ edubuntu DVD seems wrong; it's just 800MB and log refers to CD2.
<heno> asac: I would suggest you try to follow it up on real hardware (as you are doing) and not worry if it only happens in VMware
<Mithrandir> pitti: they're intentionally disabled.
<asac> heno: yeah thought so
<pitti> Mithrandir: I see; well, I'll talk to mdz about our goals; as long as bug 94361 isn't solved, too, we cannot use the compiz stuff on the live system anyway
<Ubugtu> Malone bug 94361 in Ubuntu "live CD does not ship nvidia-glx" [Undecided,Confirmed]  https://launchpad.net/bugs/94361
<cjwatson> heno: no, sorry, I've been trawling through bugs in an attempt to make sure that installer problems don't slip through the net
<cjwatson> Mithrandir: ok, will check
<heno> asac: I got this funky result yesterday testing kubuntu in virtualbox http://people.ubuntu.com/~henrik/temp/installer-wierdness.png
<heno> but it's a CM problem, not kubuntu
<cjwatson> oho, real info on bug 89463
<Ubugtu> Malone bug 89463 in ubiquity "Crash: Error removing mouseemu" [Undecided,Needs info]  https://launchpad.net/bugs/89463
<Enola_Gay> X works fine. It was a strange xorg.conf. Maybe it has something to do with kde-guidance.
<cjwatson> Mithrandir: ^-- that'll probably break all Intel Mac installs, hmm
<heno> cjwatson: ok, you're on Ubuntu DVD amd64 -- I can try having a poke at that now if you want
<Riddell> heno: CM?
<heno> Riddell: ?
<Mithrandir> cjwatson: ouch.  How hard is that to fix?
<heno> could you expand the term?
<Riddell> heno: "but it's a CM problem"  what's CM?
<heno> Riddell: a sorry, typo. VM - virtual machine
<Riddell> ah
<Enola_Gay> Another question. NetworkManager seems to work great on Centrino platforms in Feisty with wpa and even hidden ssid. But if you have no gui for some reasons connection isn't established. Is it somehow possible to activate NetworkManager in console?
<cjwatson> Mithrandir: Edubuntu DVDs should be fixed if you rebuild
<cjwatson> couple of minor bugs
<cjwatson> Mithrandir: mouseemu> not sure, right fix is probably to make sure /proc is mounted in ubiquity while installing packages
<cjwatson> I'll get some coffee and think about it
<cjwatson> (this is exactly why I'm trawling bugs now ... ;-))
<Enola_Gay> Ok, couldn't work since the passwords are safed in the gui stuff.
<Enola_Gay> Cu all.
<Mithrandir> cjwatson: ok, I've at least milestoned it
<Mithrandir> new edubuntu DVDs spinning
<asac> pitti: yes from what i see restricted modules has no fglrx module
<pitti> asac: thanks for confirming
<pitti> asac: it's a deliberate thing ATM, so it's clear now
<cjwatson> Mithrandir: it's my top priority now
<Mithrandir> cjwatson: thanks.
<pitti> _ion: I pulled your branch; your changes look fine
<pitti> _ion: thank you!
<dholbach> doko: you think it'd make sense to sync the newest aspell from debian?
<doko> dholbach: I don't see a ChangeLog, nor a NEWs files ...
<tepsipakki> does anyone know why we still use discover1?
<janimo> pitti, hi what do you think about getting the patch that replaces gnomelib dependencies for gnome-mount from upstream svn? It is uncertain when a real release is going to be made
<pitti> janimo: sounds good, as long as it does not change the UI/behaviour significantly?
<janimo> pitti: if not, I can still use exo-mount and make it call itslef with gksu, but it would be better to use one mount util
<pitti> *nod*
<janimo> pitti, it;s the GnomePasswordDialog copy pasted from gnome lib, it does not change behaviour or UI
<dholbach> doko: we had a few crashers with aspell (not terribly much) and looking at http://packages.debian.org/changelogs/pool/main/a/aspell/aspell_0.60.5-1/changelog I wondered if it fixed some of those and if you knew something about the update
<SynrG> ubuntu differs from debian in becoming superuser (sudo vs. su).  how does this difference play out in the .desktop files?  i'm working with daniel baumann and marco amadori in the debian-live project which adapts casper for debian to setup a passwordless root account and sudo for the casper user ...
<SynrG> the menu entries, however, all either user the 'menu' package su-to-root wrapper, or, in the case of .desktop files, the gksu wrapper is called
<SynrG> (or the kde equivalent)
<ajmitch> gksu should handle both su & sudo
<ajmitch> (iirc)
<SynrG> aha.  does it?  i thought there was a separate gksudo wrapper
<cjwatson> there used to be; it was unified recently
<SynrG> superb
<cjwatson> the difference is handled by a gconf key
<cjwatson> /apps/gksu/sudo-mode according to the man page
<SynrG> so if we frob this gconf key in the casper account all should be well
<SynrG> this is better than i had hoped
<doko> dholbach: I wouldn't mind an update, but would like to see the upstream changelog or something similiar
<Riddell> SynrG: we also use X-KDE-SubstituteUID=true in all the .desktop files that need to run as root, this tells KDE to run it through kdesu and has another use which I forget just now (pitti?)
<pitti> Riddell, SynrG: the other use is for checking whether or not the menu item is displayed in the first place (depending on whether the user is in the admin group)
<Riddell> oh aye
<AnRkey> who does dev work on compiz here?
<SynrG> Riddell, Riddell: interesting.  thanks!
<SynrG> good stuff.  i've conveyed this back to debian-live and will work with them to implement it
<ogra> cjwatson, 
<SynrG> cheers
<ogra> edubuntu/dvd: Uninstallable packages:
<ogra> linux-meta 2.6.20.12.8 produces uninstallable binaries:
<ogra>   * linux-backports-modules-386 (amd64)
<ogra> is that a seed mistake ? 
<ajmitch> hi ogra 
<ogra> why would it try to install -386 on amd64 ?
<dholbach> doko: they have html changelog :-) hang on
<dholbach> doko: http://daniel.holba.ch/temp/aspell - not much and not sure if it fixes our bugs
<SynrG> oh, one more thing ... the KDE part.  is that forking Debian's .desktop files and/or having patches accepted back into Debian?
<SynrG> debian-live doesn't want to have to provide custom KDE .desktop files, you see.
<Riddell> SynrG: all KDE desktop files come with that anyway if they need them, it's the non KDE ones that change
<SynrG> examples of non-KDE ones i can check in debian?
<Riddell> gnome network setup thing?
<SynrG> o
<SynrG> ok (where'd my "k" go? :)
<SynrG> thanks again
<Mithrandir> meh, I downloaded the wrong dvd.
<doko> dholbach: well, no new features, can we prove that "* Large number of bug fixes." actually fixes outstanding bug reports?
<dholbach> doko: not easily, none of the crashes happened to me
<janimo> cjwatson: hi, I removed 3 langugage support packages from the xubuntu ship seed yesterday in an attempt to reduce the size. Are those not used for todays CD build?
<janimo> as the size seems to be the same as yesterday
<Mithrandir> janimo: cd builds are on manual now.
<cjwatson> ogra: I fixed that yesterday (linux-backports-modules-386 shouldn't have been built for amd64 at all) - it's in the unapproved queue for post-beta. Just ignore it for now.
<cjwatson> ogra: the seeds use wildcards which is why it appears. It's not worth the hassle of fixing it there
<janimo> Mithrandir: does that mean they use a snapshot of the seeds of last time it was not manual?
<ogra> ah, ok
<cjwatson> janimo: no, it means that a build probably hasn't been run since you changed the seeds
<ogra> i thought it was my mistake ... something i merged wrong or so
<Keybuk> Random thought of the day: The likelihood of me reading a post on Planet is directly proportional to the number of screenshots or other pictures in it
<cjwatson> janimo: sorry, I didn't respond to your mail - I don't know why your CDs grew, but indeed taking out language-support packages is the obvious approach. It's quite possible that it's due to language packs expanding following the Feisty translations import
<Mez> acpid broke?
<pochu> what's the kde partitioner name?
<janimo> cjwatson: I committed the seeds last night, and got the health check mail a few minutes ago. although the build is still for the 20th... I'll wait till today's image and cross my fingers :)
<Riddell> pochu: qtparted is one (it's not very good), feisty includes a new one in the installer
<pochu> Riddell: yeah, I mean your partitioner (the one in the livecd)
<cjwatson> it doesn't have its own name; it's part of ubiquity
<pochu> ah, ok
<cjwatson> it's a frontend over partman, the d-i partitioner
<pochu> cjwatson: so bugs should go to ubiquity, or ubiquity-kde?
<pochu> err, ubiquity-kde doesn't exists :)
<cjwatson> pochu: ubiquity
<stockholm> is there a good channel for cdbs questions?
<klichota> Can someone tell me how to proceed with Google SoC application - I am looking for mentor and feedback for my idea (https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-March/000611.html), but got no reply and the deadline is close. Should I just submit my application to Google without mentor?
<_ion> FWIW, i'd really like to see that happen.
<Adri2000> stockholm: #ubuntu-motu for help with packaging
<stockholm> thanks
<doko> seb128, pitti: we currently don't have debug symbols for OOo, so requesting retraces doesn't make much sense (pitti: or did that change?)
<pitti> doko: any idea why we don't have them?
<doko> pitti: no
<doko> klichota: please make sure that you register your project with google. See Scott's announcment to ubuntu-devel-announce
<Fujitsu> pitti: The automated retracing only works with the new bug format, right?
<pitti> Fujitsu: correct
<klichota> doko: OK, I will check that
<Keybuk> klichota: student applications gain mentors by being in the Google SoC webapp :)
<klichota> Keybuk: so I should just submit it and wait?
<Keybuk> yes
<Keybuk> make sure it's submitted by Mar 23
<Amaranth> Submit early and often :)
<Mithrandir> cjwatson: edubuntu dvd build blew up; tar complains about a missing CD2 directory.
<klichota> I can submit it soon, I just wanted to get feedback and ideas to improve it
<klichota> And if it is really needed :)
<Amaranth> klichota: you'll get feedback in the webapp
<Amaranth> klichota: and if it's a bad idea that's where 'submit often' helps
<Amaranth> get a couple ideas in there
<klichota> OK :)
<klichota> doko: I cannot find the e-mail about Soc from any Scott on ubuntu-devel-discuss, can you give some more details?
<Treenaks> klichota: it's on ubuntu-devel-announce
<klichota> Thanks, I will look there :)
<klichota> Thanks everyone for help, I will now try squeezing my application to 7500 characters :) Bye!
<Treenaks> klichota: gzip -9
<klichota> Yeah, kind of ;)
<doko> klichota: create a wiki page on wiki.ubuntu.com, if you need more space, and reference that from the SoC application
<klichota> The application is already on the web, I just need to shorten it to fit in web app
<Amaranth> klichota: just put a smaller overview of the idea in the webapp and link to the full version
<klichota> Yes, that's exactly what I am going to do :)
<siretart> pitti: could you please have a look at #81893? if the submitter is right, there might be a lot more packages affected as well...
<siretart> bug #81893
<Ubugtu> Malone bug 81893 in schroot "libc6 update breaks dchroot, recompile fixes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81893
<pitti> bug 91993
<Ubugtu> Bug 91993 on http://launchpad.net/bugs/91993 is private
<pitti> whoops :)
<pitti> siretart: right, this looks like an adequate SRU
<siretart> pitti: adequate or not, why does the libc6 update break dchroot in the first place, and how can we sure that dchroot is the only affected binary?
<pitti> siretart: still, this is worrying me -- was this an ABI change or so?
<ogra> Mithrandir, meh and ltsp 5.0.3 isntz on the CDs ... 
<ogra> just exploded on me
<Fujitsu> I'd say it is rather worrying, personally.
<pitti> siretart: can't say yet, I'd need to look at a stack trace and check if downgrading indeed fixes it
<siretart> pitti: I'll add this conversation to the bug so it doesn't get lost, okay?
<pitti> siretart: also, the architecture would be interesting; there had been some issues on amd64, and rebuilding libc with a new compiler in edgy might have caused that
<pitti> siretart: yes, thank you
* pitti hugs siretart 
* ogra feels like cursed with this beta
* siretart hugs pitti back
* ogra scratches his head
<heno> pitti: not sure if you still need this info: I get the same result in r-m "you don't need restricted drivers", but I have an Nvidia 7300 (on amd64)
<_ion> Sigh, we gotta figure out a way to get a *complete* list of the PCI IDs supported by the nvidia driver.
<Treenaks> _ion: the X one?
<_ion> Yeah.
<Mirv> mvo: now the update-manager-core does not show at all in edgy's Rosetta, I don't know if that was supposed to happen or not. only the regular update-manager is there, and there's no new strings at all there.
<mvo> Mirv: my upload was not yet approved by the archive-admins, sorry for that
<Mirv> mvo: ah, ok, I was just too hasty then
<mvo> pitti: could you please have a look at update-manager-core for edgy? it would be cool if that could go in as it fixes one race and also fixes some translation issues
<Mithrandir> ogra: does that mean you need respins?  If you're not doing them yourself, feel free to ask me for them.
<pbn> Hello is it possible to view the changelog of packages using the www ?
<ogra> Mithrandir, no, all fine, seems my iso didnt get updated in my last rsync run ...
<ogra> the .list file shows ltsp 5.0.3, must be me ... 
<cjwatson> Mithrandir: ok, looking
<Mez> ogra, ping (regarding jack support in libasound2-plugins
<ogra> Mez, there is none ...
<Mez> ogra, yes, you diabled it
<Mez> disabled *
<ogra> right, else the package wouldnt have gone to main
<Mez> indeed, but what abut those who need it
<Mez> and you're misleading the people who read the package description
<ogra> i'll update that one ...
<racarr> would anyone have a particular problem with me rewriting desktop-effects to not use Glade? I have to do some patching, etc for Beryl, but I can't stand Glade
<ogra> i havent seen ansy biugs about it yet ...
<ogra> *bugs
<Mez> ogra, I've just installed it so I can use alsa-jack
<ogra> and the change was done in agreement with crimsun
<Mez> and I've found it's not there
<Mez> so now I need to make my own packages to do it
<ogra> feel free to send me a patch to split out a -jack binary for universe 
<Mez> ogra, but it wont build without jack in main
<Mez> or can we now do that?
<Mez> oh, apparently we can do it now
<iwj> cjwatson: Against which package should I report that  Guided partitioning / resize  doesn't WFM ?
<Mez> ogra, can you remember what you changed (so I can reinstate it rathr than just getting an old package)
<cjwatson> iwj: partman-auto and tell me the bug number. I need syslog and partman logs
<ogra> i'm currently extremly busy (as everyone here ) with beta testing, can we talk about it after beat or can you file a bug or something ? 
<ogra> *beta
<iwj> cjwatson: Noted, willdo.
<ogra> look at the changelog, it should say it ... 
<Mez> ogra, it just says disabled jack support
<ogra> well, i assume i just added --disable-jack to configure then :)
<Mez> ogra, and I assume changed the B-Ds ?
<ogra> right
<pitti> mvo: oh, you uploaded a new version? sure, looking
<pitti> heno: no, it's clear why this happens; the live fs build scripts remove the nvidia.ko module, so I need to add a respective special case hack to r-m
<pitti> heno: thanks you, thouhg
<Mez> ogra, and as the dependency is in universe, then it wont build as the buildds will only build a main package against main
<pitti> mvo: bug number?
<Mez> ogra, hence my issue
<mvo> pitti: for the u-m-core upload? none, mdz told me about the race last night
<pitti> ah, ok
<ogra> Mez, after beta please, we cant change it now anyway
<pitti> oh, *two* new versions
<mvo> pitti: I can create one if you need it for reference
<pitti> mvo: don't worry; we already have that one SRU bug anyway
<mvo> pitti: yes, take the later one :) the other contains a update of the translations (just pull i nthe ones from feisty as the strings are the same)
<Mez> ogra, after that I'll have forgotten
<cjwatson> Mithrandir: Edubuntu DVDs rebuilding now with extra fix; looking better
<Mez> I'm just building my own package for now
<ogra> cjwatson, thanks 
<ogra> Mez, thats why i said you should file a bug ...
<cjwatson> also, I hate whatever it is that's making my iMac's CD drive dog slow
<cjwatson> guess I'll just arrange to reproduce the mouseemu thing in vmware.
<pitti> mvo: why bother with adding .po files? they will be stripped out anyway, and they should instead get into the next langpack update
<Mithrandir> cjwatson: thanks.
<pitti> mvo: also, using an entirely new domain name ('update-manager-core') seems bad to me; why not keep update-manager, to share translation efforts with feisty?
<mvo> pitti: dosn't rosetta import the ones I upload so that people will not have to re-translate?
<pitti> mvo: right, see above
<pitti> duplication of identical strings -> bad
<mvo> pitti: there is already a translation domain update-manager in edgy 
<pitti> mvo: right
<pitti> mvo: so it is in feisty, right?
<pitti> mvo: does feisty's u-m-core use 'u-m' or 'u-m-c'?
<mvo> pitti: right, feisty uses update-manager again for all update-manager releated translations
<pitti> mvo: then edgy should do so as well IMHO
<mvo> pitti: how? u-m and u-m-core are different source packages and AFAIK the pot file can not be split across two source files
<mvo> source packages
<pitti> ah, right, I see
<pitti> mvo: yep, usually one package should ship the complete template then
<pitti> grr, this silly split/non-split is really weird
<mvo> pitti: I totoally agree that it is not ideal, but it was the best solution I could come up with for edgy
<mvo> pitti: its only ~10 strings in u-m-core and only in edgy, in feisty all is sane again :)
<pitti> mvo: hm, why wouldn't it have been better to just let r-m source build the -core package, just as in feisty?
<pitti> s/r-m/u-m/
<mvo> right, but then I would have to have uploaded a  new u-m and that would have been more work and more potential damage (if something goes wrong with the backport etc)
<pitti> ok
<mvo> the u-m, u-m-core split was done in feisty and before that the seperation in the source was not as good as it is now
<pitti> mvo: accepted
* mvo hugs pitti
<mvo> carlos: new u-m-core for feisty uploaded that should have a much saner u-m-core.pot file
<ogra> Keybuk, ping
<carlos> mvo: ok
<carlos> thanks
<carlos> I will reactivate the template once I see the .pot file imported
<Keybuk> ogra: yo
<iwj> cjwatson: bug 94410 (auto-resize failure)
<Ubugtu> Malone bug 94410 in partman-auto "auto resize fails "writing changes to the storage devices"" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94410
<cjwatson> ta
<pirast> kwwii, could you maybe have a look at bug 93231?
<Ubugtu> Malone bug 93231 in gnome-system-monitor "Gnome-system-tools needs rebranding" [Wishlist,Confirmed]  https://launchpad.net/bugs/93231
<heno> fabbione: would you be able to do some sparc test installs today? (default and LVM+LAMP)
<fabbione> heno: i am already doing a few of them but it seems something is breaking console install during the boot
<heno> fabbione: ok, thanks
<fabbione> AHHHH
<fabbione> there it is
<fabbione> who writes /etc/event.d/ttyS0 ?
<fabbione> cjwatson: ^^ is it something in  d-i that creates that file?
<fabbione> Mithrandir: uploaded silo-installer as we agreed a couple of days back.
<fabbione> Mithrandir: it's not a requirement for Beta
<cjwatson> fabbione: finish-install
<fabbione> cjwatson: ok, the generate ttyS0 is wrong.. we need to fix it :(
<cjwatson> ah, there's a mistake in there, it says respawn rather than exec
<fabbione> the speed is wrong... sec
<cjwatson> I bet it's the respawn vs. exec thing, really
<fabbione> #exec /sbin/getty 38400 ttyS0
<fabbione> exec /sbin/getty -L ttyS0 9600 linux
<fabbione> no it's a speed problem and you need to set the terminal..
<fabbione> # <- generated
<cjwatson> listen to me
<cjwatson>                 sed -e "s/^\(respawn.*getty \).*/\1-L $console $ttyspeed $ttyterm/" \
<cjwatson>                     -e "s/tty1/$console/g" \
<cjwatson>                     /target/etc/event.d/tty1 > /target/etc/event.d/$console
<cjwatson> that is what is done at the moment
<cjwatson> the reason that it is not setting the speed is that it says respawn rather than exec
<fabbione> ahhh
<cjwatson> and the syntax of that file changed
<fabbione> ok
<fabbione> sure
<fabbione> do you want me to test before you upload?
<fabbione> this is really kind of nice to have for beta
<fabbione> at least on sparc server cd
<cjwatson> uploading now
<fabbione> ok thanks
* fabbione sends a hug to cjwatson 
<cjwatson> iwj: hmm, ok, it's a race, the device node went missing JUST as we were running resize2fs
<cjwatson> iwj: I'll stick an update-dev in there
<ogra> phew, ltsp chroot building works ... 
<cjwatson> Mithrandir: partman-partitioning 47ubuntu3 for iwj's resizing bug. Up to you whether it's beta-critical; if we're rebuilding ubiquity for the mouseemu thing anyway I'd like to include it there, but you may not want to rebuild all the alternates as well!
<cjwatson> Edubuntu DVDs seem to have worked properly now
<kwwii> pirast: I still haven't found the logo you mean - exactly where is it?
<Mithrandir> cjwatson: it affects both alternate and desktop?
<ogra> cjwatson, ok, rsyncing
<pirast> kwwii, open gnome-system-monitor and open the tab "System"
<cjwatson> Mithrandir: I think so :(
<cjwatson> Mithrandir: only if you resize though
<pirast> kwwii, on the left side, there's a gnome logo
<cjwatson> and even then only if you resize ext2/ext3 or maybe ntfs
<Mithrandir> hmm
<cjwatson> and it's a race so not guaranteed to break
<Mithrandir> I'm tempted to just put it in the release notes.  Is there a workaround?
<cjwatson> try again until you win the race, probably? :-)
<cjwatson> that's probably easier in the alternate install CD
<ogra> dholbach, hmm, did the place of the vendor logo icon change somehow ? i have the ubuntu icon in my edubuntu menu
<pirast> kwwii, found?
* ogra grrs at NM for killing the dhcp server interface once again
<kwwii> pirast: yepp, but that is not a simple pic that does that
<TheInfinity> hello
<kwwii> pirast: it seems to be a logo overlay on a code-drawn box with rounded edges and a gradient
<pirast> kwwii, ho hum.. just saw a nice picture in opensuse :)
<TheInfinity> yesterday i asked for an bug in the ubuntu cyrus package - where someone told me that the binary deliver is called cyrdeliver in debian and it is part of cyrus-common-2.2. well - it is just not there ;)
<pirast> kwwii, so they have some way to do it
<kwwii> pirast: oh, I am sure it is possible, but it is not as simple as swapping out pics
<pirast> kwwii, hmhm
<TheInfinity> against some descriptions its in /usr/sbin - is that ok ... ?
<pirast> kwwii, okay, nevermind :)
<cjwatson> Mithrandir: erm. Have you been following BetaProcess? We haven't fixed debian-cd/CONF.sh
<Mithrandir> cjwatson: argh, I knew I had forgotten something :-(
<Mithrandir> so we need new images anyway.
<cjwatson> Mithrandir: what about the gnome-app-install db and the readahead list?
<cjwatson> CONF.sh updated now
<Mithrandir> I've asked for them and they have been updated, afaik.
<cjwatson> ok
<cjwatson> mouseemu thing nearly fixed, final testing
<Mithrandir> what about the partman fix?
<cjwatson> ?
<ogra_> mvo: are you still working on the fsck bug ? 
<mvo> ogra_: I looked at it, but no conclusion yet
<ogra_> i just saw it here again ... want any logs from this install ? 
<mvo> ogra_: you have it?!? great, can I have ssh access please :-D
<Mithrandir> cjwatson: I'll get the mouseemu fix in too, then, please tell me when it's uploaded.
<fabbione> Mithrandir: if we need to rebuild all images, can i also get silo-installer please?
<cjwatson> Mithrandir: which partman fix? you mean the partman-partitioning thing for resizing?
<fabbione> (not critical)
<Mithrandir> cjwatson: yes, and it's accepted.
<cjwatson> ah ok
<Mithrandir> fabbione: no, it's not critical.  I want to make minimal changes at this point.
<fabbione> Mithrandir: ok
<ogra_> mvo:  my telecom router doesnt have port forwarding capabilities :/
<ogra_> hmm, why isnt qcad on my addon cd ?
<pochu> pitti: is it possible that if a bug is marked as a duplicate, the retrace service doesn't make a retrace?
<pbn> hm, sorry but isn't qcad commercial now ?
<pbn> also hum
<pbn> Hello is it possible to view the changelog of packages using the www ?
<ogra_> mvo: qcad is on the add-on CD and has a .desktop file, but an .xpm icon it seems ... it doesnt show up in app-install
<ogra_> is .png mandatory ? 
<danohuiginn> pbn: yes, go to the package page (packages.ubuntu.com/feisty/web/firefox, or whatever) and click on 'debian changelog'
<ogra_> mvo: same for rasmol
<cjwatson> Mithrandir: uploading now; gotta run, I'm five minutes late for a lunch date 5-10 minutes away
<ogra_> the fonts in the vte widget in app-install are very blurry for me here ...
<Mithrandir> cjwatson: cheers.
<Mez> how do i get the realtime lsm in my kernel? other than recompiling my kernel?
<pbn> danohuiginn: thank you
<heno> pbn: qcad uses qt3 AFAIK, which is free on Linux but non-free on Windows. qcad is commercial on Windows only, AFAIK
<pbn> heno: aaah that I didn't know :)
<pbn> Also hum, the printed output of bug reports on launchpad.net is quite ugly, and there seems to be no "printable view" option... uhhh would be nice if the printed result wasn't that ugly...
<heno> pbn: -> #launchpad please :)
<pbn> uh oh... and http://packages.ubuntu.com/dapper/kde/kvpnc gives me a 404 Not found ...
<ogra_> seb128_: shouldnt gimme-codec offer me something if i import mp3's in RB ?
<Riddell> cjwatson: new ubiquity means new desktop images needed?
<ogra_> seb128: shouldnt gimme-codec offer me something if i import mp3's in RB ?
<seb128> ogra_: it should, patches are welcome
<seb128> ogra_: easy codec has been implemented for totem only atm
<ogra_> ah, ok
<ogra_> well, in totem it offers codec installation to an unpriveleged user here ... it should test for the admin group i guess
<seb128> so many bugs :(
<ogra_> yeah :/
<bddebian> Heya
<dholbach> ogra: where is your icon placed? which icon themes does edubuntu use? in which order?
<ogra_> gartoon
<dholbach> ogra: where is your icon placed? in which order does it inherit other icon themes?
<Mithrandir> ogra_: do you have any shiny server stuff you wish to add to the beta announcement?  It had some bits about LTSP 5.0 for the last beta.
<mvo> ogra_: can you please file a bug about those two?
<ogra_> dholbach: /usr/share/icons/gartoon/24x24/apps/distributor-logo.png i havent set up anything to tell it a particular inheritance order
<dholbach> ogra_: try adding the other sizes too
<ogra_> Mithrandir: edubuntu being on two CDs and shipping 142 langs would be something i guess ....
<mvo> ogra_: hm, if no ssh, then lets talk on PM, I need the tune2fs -l outpur of the fs that is checked
<ogra_> Mithrandir: for ltsp a new sound implementation and full locale support out of the box would be noticeable
<Mithrandir> ogra_: can you give me a blurb?
<ogra_> Mithrandir: will do, i need to get back to my working machine again .... installing on it atm, until when do you need it ?
<Mithrandir> ogra_: or just edit https://wiki.ubuntu.com/FeistyBetaAnnouncement?action=edit yourself.
<ogra_> mvo: but i bet before the fsck runs, right ? 
<Mithrandir> ogra_: having it in a couple of hours would be good, so I can send it off for proofreading, etc before I leave for the day.
<ogra_> ok
<ogra_> edubuntu server i386 and serveraddon look good btw ... :)
<Mithrandir> ogra_: they need respins.
<Mithrandir> I forgot one step in the beta process, setting OFFICIAL
<Mithrandir> which means their names are wrong.
<ogra_> as long as this doesnt cause regressions they should still be good then :)
<Mithrandir> or, labels.
<mvo> ogra_: well, if the fsck is run on every boot, then that should be easy :) before and after would be ideal. what did you do to trigger the problem? 
<Mithrandir> it shouldn't cause regressions, but we need to do the full testing dance.
<ogra_> mvo: it only runs on first boot
<ogra_> mvo: saying its 49710 days without check ... the clock is correct in teh installer as well as in teh installed system though ...
<ogra_> cjwatson: does the XKBLAYOUT of console-setup have any effect on teh real X settings ? apparently i have a german keyboard in my thin client even though i didnt specify one particulary 
<ogra_> but i have  :)
<mvo> ogra_: at least in ubuntu we do not set a check interval, so I wonder why it does it. or does edubuntu has a differnt default here?
<ogra_> no
<mvo> ogra_: can you please check if check interval is set in your install? and does it re-check on every boot?
<ogra_> edubuntu uses d-i as ubuntu does ... there is only the ltsp-client-builder run additionally
<heno> ogra_ you could mention Edubuntu WinFOSS if you feel so inclined
<mvo> ogra_: ok, please put the tune2fs output on a pastebin, I'm really curious about it
<ogra_> heno: right, thankls for the reminder :)
<ogra_> mvo: http://paste.ubuntu-nl.org/11345/
<ogra_> thats after first boot and check indeed
<pbn> hm, perhaps a "newbie" question, but at the bottom of http://packages.ubuntu.com/dapper/net/kvpnc.html I can see "view the Debian changelog file"... I guess that means "view the Ubuntu changelog file"... right ? :)
<bddebian> Yes, they are synonymous
<sacater> sometimes when my computer starts up there is no internet connection, i checked this on the router, and it is denying 82.211.81.132. My machine is trying to connect to it but the router stops it, what is the IP and why is my machine trying to connect to it
<Mithrandir> it's trying to set your clock
<Treenaks> sacater: please ask support questions in #ubuntu
<Treenaks> and what Mithrandir says ;)
<sacater> Mithrandir: how do i disable, (if you dont mind me asking)
<Mithrandir> sacater: please ask support questions in #ubuntu, not here, as Treenaks asked you to.
<mvo> ogra_: thanks, that is very strange
<ogra_> mvo: since i have to re-test all isos anyway i'll check the difference next install
<ogra_> (before and after the check i mean)
<pbn> bddebian: well hum... you mean, Ubuntu uses exactly the same package structures as Debian, such as debian/rules and stuff ?
<bddebian> pbn: We use Debians packages period :-)
<mvo> ogra_: thanks, just be sure. this fsck happened *only* after the first boot? or on every boot? and it was a fresh edubuntu server install?
<ogra_> only after first boot, and yes a fresh edubuntu server install
<mvo> ogra_: thanks
<ogra_> dholbach: i have it in 24x24 and 48x48, just not in scalable ...
<pbn> bddebian: yes but :) ... for instance I have a problem with some package in Ubuntu and that problem does not happen in Debian...
<ogra_> pitti: r-m is in the menu of an unpriveleged user here ... known ? 
<Riddell> doko: openoffice seems to have lost the KDE style open dialogues
<bddebian> pbn: Well for some packages we do make Ubuntu specific changes but we generally start from the Debian package first.  Though there are exceptions to that.
<doko> Riddell: known, will be fixed with the next upload
<Mithrandir> Riddell: the screen locker on the kubuntu dvd doesn't seem to accept blank passwords.
<Mithrandir> Riddell: is this known or do you want a bug (against which package?)
<Riddell> Mithrandir: it's a known problem
<Riddell> doko: great
<Riddell> doko: did you say if it's possible to have a kubuntu themed splash for open office?  (I presume not easily)
<doko> Riddell: no, just one
<Riddell> doko: thought so
<Riddell> kwwii: ^^
<kwwii> Riddell: yeah, that is what I thought
<BenC> Anyone here experiencing bug #93648?
<Ubugtu> Malone bug 93648 in linux-source-2.6.20 "2.6.20-12 fails to boot with ICH6 SATA (ahci_init_one/pci_iounmap BUG at lib/iomap.c:254)" [Critical,Confirmed]  https://launchpad.net/bugs/93648
<PF-Away> i'm trying to debug this bug a bit: #91399
<hunger> BenC: That kernel version does not boot for me, I hase SATA as well.
<PF-Away> but when i add "echo" statements to the postconf script, none of they get output
<BenC> hunger: Can you boot without the quiet/splash kernel command line options and see if it's showing the lib/iomap.c:254 bug?
<BenC> hunger: or just boot to rescue mode, either way should work
<hunger> BenC: Not right now... I am just compiling.
<hunger> BenC: In a couple of minutes I can try.
<BenC> hunger: Ok, I'm hoping to see if it's worth holding off beta to fix this
<Mithrandir> uh-huh?
<hunger> BenC: It is:-)
<tritium> BenC: I may be.  I just upgraded to 2.6.20-12 this morning, and my Thinkpad T43p won't boot from it now.
<hunger> tritium: I got a T43p as well.
<BenC> Mithrandir: This bug has 12 dupes, and there's no work around :/
<tritium> hunger: ah, very interesting...
<Mithrandir> BenC: ouch.  Do you have a known fix for it?
<BenC> Mithrandir: I have some patches pulled in, and test deb's
<tritium> hunger: but -11 works just fine, yes?
<hunger> Mithrandir: The 2.6.20-9 kernel works for me... last one I was using before I tried to upgrade to -12:-)
<tritium> (aside from Atheros AR5212 being useless)
<hunger> tritium: I have not tried any kernel between -9 and -12.
<tritium> hunger: -11 should work, other than wireless
<hunger> tritium: THe -9 works fine, even with WLAN.
<hunger> Ah... we are getting close to a release... stuff starts to break again:-|
* hunger sights.
<tritium> hunger: AR5212?
<hunger> tritium: Yeap.
<Mithrandir> BenC: I need to go to the shop and pick up some groceries, can you see if you know anything more when I get back?
<BenC> Mithrandir: this bug has my full attention right now
<tritium> hunger: hmm, maybe I should revert back to -9 then...
<Mithrandir> BenC: thanks.
<hunger> tritium: At least wep works... have not tried wpa in a while.
<tritium> k, thx
<BenC> need to see if I can shove some boxes into ahci mode and reproduce this
<tritium> BenC: I can test on my T43p later this evening, if need be.
<hunger> BenC: Same here.
<sladen> Mithrandir: try simira's Canonical laptop;  that's the same era as the other laptops affected and like ICH6
<sladen> likely
<Treenaks> sladen: what's the problem? :)
<cjwatson> Riddell: new desktop> yeah :(
<cjwatson> ogra: XKBLAYOUT> er I think that or something related is used by xserver-xorg.postinst to set the default layout; once that's done they're separate from then on
<sladen> Treenaks: lack of booting on people with 2005-era machines, see above
<Treenaks> sladen: ah.. I think I remember proper booting using the latest kernels on my laptop (almost the same as Simira's laptop)
<Treenaks> sladen: but I'd have to try
<sladen> pbn: if something isn't working in a package, please file a bug at  http://launchpad.net/ubuntu/+filebug  along with the information about which version is working in Debian and isn't in ubuntu
<sladen> Treenaks: try  lspci -n | grep 8086:2653
<BenC> I really need a tester now if anyone can do it
<sladen> tritium: same with you, should give you an idea of whether it's worth testing
<Treenaks> sladen: hmm.. I should have installed sshd
<sladen> BenC: me me!
<sladen> BenC: do you have a deb handy?
<Treenaks> sladen: from the Xorg log (from a bug report ;)) : (II) PCI: 01:00:0: chip 1002,5653 card 103c,0940 rev 00 class 03,00,00 hdr 00
<BenC> sladen: Let me prepare one for you
<BenC> kyle just found the commit we need
<sladen> the upstream fix, or the one that broke it?
<BenC> upstream fix
<mdz> morning
<jdong> morning, mdz
* lamont wonders what broke in the login process that it no longer correctly gets all the groups that are in ldap
<lamont> ah.  nsswitch.conf seems to have changed meanings. :-(
<pitti> pochu: right, dups are not considered, since Malone does not return them by default; and it wouldn't make sense either?
<pitti> ogra: oh, not known; can you please file a bug for that?
<BenC> sladen: I'm 99% sure this fixes the problem...do you need amd64 or i386 -generic package?
<lamont> "groups: files ldap" used to get you both sets of entries in your gidlist.  Now if you're in files at all, you don't get anything from ldap.
<lamont> pitti: that something you knew about?
<sladen> BenC: i386 generic
<BenC> sladen: Ok, 30 minutes, and it will be yours
<\sh> lamont: my nsswitch.conf reads: groups: compat ldap ;) 
<pitti> lamont: no, I don't know about that
<sladen> BenC: I'll go and have breakfast
<TomaszD> pitti, langpack still doesn't include desktop file entries of r-m
* lamont tries compat ldap just for giggles
<pitti> TomaszD: hm, the .pot file has them; does Rosetta have them?
<TomaszD> pitti, indeed, that's why it's strange
<TomaszD> Polish translation: 100% done
<\sh> lamont: installed it some minutes ago :)
<\sh> lamont: 
<\sh> passwd:         compat ldap
<\sh> group:          compat ldap
<\sh> shadow:         compat ldap
<TomaszD> pitti, you're entirely sure it's parsing utf-8 correctly? maybe that's the trouble.
<TomaszD> there are three things that are not translated, the label of the main window titlebar, the tooltip of the desktop file and the deskop file itself
<mdz> Mithrandir: are the current dailies beta candidates?
<TomaszD> pitti, https://launchpad.net/ubuntu/feisty/+source/restricted-manager/+pots/restricted-manager/pl/+translate?start=30 - last two are the deskop entries
<pitti> TomaszD: does the current langpack have the translations in the .mo file?
* pitti looks
<\sh> any reason why sudo-ldap is in universe? 
<pitti> \sh: I guess mainly because noone was interested in testing and maintaining it
<TomaszD> pitti, all the strings on that page have been accepted at the exact same moment, because I've been using rosetta. And I can see the other strings from that page properly translated, but not the last two.
<heno> mdz: no, we are rebuilding them all ATM
<\sh> pitti: hmm...just asking, because it breaks ubuntu-minimal ... 
<pitti> TomaszD: the Polish .po file in the langpack does have the strings
<_ion> pitti: Do you happen to have an Ubuntu box without a nVidia GPU? Could you please check whether it gives an error if you try to load the nvidia module? Then i'd know whether it's the kernel module or the X module that must contain the ID list *somewhere*.
<heno> get the latest updates at https://wiki.ubuntu.com/Testing/Community/Status :)
<pitti> _ion: no, I don't; just a powerpc with a Radeon, but there's no nvidia module there
* TomaszD shrugs
<mdz> heno: can you bring me up to date with what's happening?
<_ion> Anyone here who could do that test, please?
<pitti> TomaszD: can you msgunfmt the restricted-manager.mo file on your desktop and check whether it has the strings?
<heno> mdz: we missed some steps in the beta process, like setting CONF.sh to OFFICIAL
<heno> so the images don't have the right names
<cjwatson> mdz: (a) CDs still said "alpha" (b) resizing race noticed by iwj (c) Intel Mac installation crash that we only got the logs for recently (d) probably a couple of other minor things I forgot
<heno> BenC: is also looking at a kernel bug that may be bad
<pitti> _ion: mvo and ogra have ATI cards <= could you please try to modprobe nvidia and see what happens?
<cjwatson> nothing really earth-shattering but enough was mounting up that Tollef decided to respin
<heno> causing boot failures on SATA drives
<cjwatson> oh yes and that ICH7 bug
<TomaszD> pitti, if I knew where that .mo file is
<mdz> that's not fixed in the respin, though, I take it
<BenC> the ahci bug has a definite fix
<mdz> BenC: bug#?
<BenC> I'm build a test package and an upload tarball at the same time
<heno> I assume the respins are on hold for that
<BenC> mdz: 93648
<mdz> bug 93648
<Ubugtu> Malone bug 93648 in linux-source-2.6.20 "2.6.20-12 fails to boot with ICH6 SATA (ahci_init_one/pci_iounmap BUG at lib/iomap.c:254)" [Critical,Confirmed]  https://launchpad.net/bugs/93648
<heno> Tollef stepped out for a bit as well
<pitti> TomaszD: /usr/share/locale-langpack/pl/LC_MESSAGES/restricted-manager.mo
<cjwatson> iwj's resize failure was bug 94410
<Ubugtu> Malone bug 94410 in partman-partitioning "auto resize fails "writing changes to the storage devices"" [Undecided,Fix released]  https://launchpad.net/bugs/94410
<BenC> Tollef's aware of the bug, just getting it fixed as quickly as I can
<TomaszD> pitti, yes, found it already :)
<mdz> BenC: you know what the change is which introduced the regression?
<BenC> mdz: No, kyle found the commit that fixes the bug
<mdz> ah
<BenC> mdz: drivers/ata/ updates exposed the bug
<iwj> cjwatson: It does it for me when I try to resize during manual partitioning, too, but I assume that's the same bug.
<ogra> hmm, i cant scroll with the cursor keys in websites in firefox on the beta, does anyone else see that ?
<cjwatson> iwj: indeed, it's in common code
<TomaszD> pitti, they're there
<cjwatson> iwj: I'd be academically interested to know if you can win the race by retrying
<cjwatson> I think we're now finally down to one code path for resizing filesystems in the installer :P
<mvo> pitti: $ sudo modprobe nvidia
<mvo> Not loading nvidia module; not used in /etc/X11/xorg.conf
<bluemax> i'd be academically interested if you can design a ufo
<_ion> mvo: Could you please add it to xorg.conf temporarily, just to see whether the module loads then?
<ogra> i dont have nvidia on my system 
<_ion> ogra: That's the point. :-)
<ogra> i only get a 2module not found"
<ogra> and r-m doesnt think it can do anything for me, even though i have an ati card here
<bluemax> gees you guys are dry
<ogra> oh, wait .... no fglrx on amd64, right ? 
<jdong> what?
<jdong> there certainly is....
<ogra> hmm, apt agrees 
<jdong> well upstream offers fglrx for amd64
<ogra> i rarely use amd64 on recently ... but then r-m is broken for me
<ogra> -on
<ogra> hmm
<ogra> no restricted modules installed ? 
<mvo> _ion, pitti: $ sudo modprobe nvidia
<mvo> FATAL: Error running install command for nvidia
<iwj> cjwatson: retrying> Well, it happened to me first time both times and I didn't retry.  But I'm about to be in a position to try it again :-).
<cjwatson> iwj: ok, maybe the race window is wider than I thought
<ogra> seems l-r-m amd64 wasnt installed at all here ...
<ogra> that doesnt seem right ...
<_ion> mvo: Could you try to load the module directly with insmod?
<Mithrandir> mdz: current dailes beta candidates> no, I finished a publisher run a little ago with some critical fixes and now we have this SATA problem.
<TomaszD> pitti, they're there
<mdz> Mithrandir: planning to delay then?
* TomaszD is lost
<Mithrandir> mdz: unsure, I wanted to chat with you about it.  "Does not boot on modern Intel boards using SATA" (if that's the scope of the bug) is quite bad.
<PF-Away> is there any guides/information on prevu anywhere?
<jdong> PF-Away: what do you need to know?
<PF-Away> jdong: how to use it;)
<PF-Away> i've run prevu-init, but running "prevu" in a source dir just prints usage info
<mdz> Mithrandir: it seems clear that we ought to fix it for beta, as it's a hardware support regression
<mdz> Mithrandir: though I'm interested in how we can avoid such a problem at the last minute in the future
<jdong> PF-Away: when run without arguments, prevu checks for debian/
<jdong> if debian/ exists, it builds it as a source package
<Mithrandir> mdz: "not have kernel uploads late", but this one was a couple of days ago so I wonder why nobody caught it until now.
<PF-Away> ah... so if no debian/, no fun?
<jdong> if it odesn't exist, it prints out source info
<mvo> _ion: # insmod ./volatile/nvidia.ko
<mvo> insmod: error inserting './volatile/nvidia.ko': -1 No such device
<mdz> perhaps syncing the latest driver updates from upstream over the weekend before beta should be avoided
<jdong> PF-Away: right; prevu only builds debian packages
<mdz> Mithrandir: I think it takes several days, possibly more than a week for a new kernel to shake out
<jdong> it's not an automatic debianizer
<PF-Away> how can most easily create a debian dir?
<jdong> PF-Away: -> #ubuntu-motu
<PF-Away> ok
<_ion> mvo: Thanks! Now i know that the module contains a check for the existence of compatible hardware.
<jdong> PF-Away: it involves packaging the software
<mdz> Mithrandir: let's deal with the current problem first and then discuss it
<Mithrandir> mdz: we might want to have a small kernel freeze before beta, but yes, discuss post-beta sounds good.
<Mithrandir> mdz: what do you reckon is a good time to delay for?  Until Tuesday or so?
<mdz> Mithrandir: eek, that long?  I thought one day would be sufficient
<Mithrandir> mdz: I was thinking so we make sure we don't have more regressions.
<pitti> TomaszD: do you have a /usr/share/locale/pl/LC_MESSAGES/restricted-manager.mo ?
<cjwatson> Mithrandir: I thought we'd had problems along these lines for a while
<Mithrandir> mdz: hence why I wanted to discuss it with you rather than just say "we delay".
<cjwatson> there've certainly been quite a few SATA bugs
<ogra> mvo, very intresting, the amd64 install i just did had no fsck
<jdong> cjwatson: -11 and below had hanging issues with JMicron/P965 IDE chips
<TomaszD> pitti, different, /usr/share/locale-langpack/pl/LC_MESSAGES/restricted-manager.mo
<jdong> it's kinda funny how fixing JMicron always leads to AHCI borking
<jdong> and vice versa :)
<cjwatson> right, and IIRC the problem that introduced this fixed that?
<jdong> yeah
<ogra> mvo, exactly the same HW and install, just amd64
<pitti> _ion: so in theory we should be able to parse out the hex numbers from the module directly?
<cjwatson> we need to ensure test results on both those systems, then
<cjwatson> BenC: ^--
<cjwatson> I'd be happier with one day than until Tuesday, though
<_ion> pitti: That's what i'm attempting.
<iwj> cjwatson: On this machine I seem to lose the race every time.  3 times in a row just now.
<pitti> _ion: hm, but looking at the strings output they seem to be integers, not strings any more
<BenC> cjwatson: the fix we have the ata_piix/ahci is in lib/iomap.c error handling, so it wont regress jmicron
<cjwatson> iwj: lucky we're rebuilding everything, then
<cjwatson> BenC: I missed a logical leap in there, but I assume it makes sense ...
<_ion> pitti: Yeah, there is no neat plaintext list of IDs anywhere.
<BenC> cjwatson: I missed a few words, but you get the idea :)
<pitti> _ion: the other way round, I can modprobe -i fglrx without having an ATi card
<_ion> pitti: Of course, the nvidia module might as well do something like "Any nVidia devices from the VGA class? Request a capability list from them and decide whether i should support it based on that."
<_ion> That would make things more difficult.
<mdz> Mithrandir: have we been able to do most of a testing cycle yet?
<pitti> _ion: parsing the source code at l-r-m build time might in fact be easier if it contains a product id list, but I didn't check
<pitti> _ion: oh, wait, ENOSOURCE; ignore me
<Mithrandir> mdz: yes, and it looks mostly good.  There's a breakage on intel macs and there's a race in the resizing, both fixed with binaries in the archive
<mjg59> We still have to deal with the HPA regression, but that's clearly going to have to be post-beta
<_ion> Darn, disassembling a >5 MiB file with objdump takes a *long* time.
<kylem> mjg59, we reverted it already.
<mjg59> kylem: Right, that's the regression
<mdz> Mithrandir: I'd say we should fix the known regression and get it out
<kylem> mjg59, feh.
<kylem> mjg59, worksfor me.
<mjg59> Yeah, just not anyone who's blown away their restore partition
<kylem> imeant the code...
<mjg59> Heh
<sladen> Mithrandir: it was caught two days ago, reported, marked critical
<kylem> mjg59, what chipset is in your macbook?
<mjg59> 965
<kylem> ICH7?
<mjg59> Uh, no
<mdz> Mithrandir: please send an update to -devel-announce so that the rest of the world knows what's happening
<mjg59> 945
<mjg59> So yeah, I'd guess ICH7
<kylem> right, ICH7.
<kylem> bummer, i only have ICH8 and like, ICH3.
<Mithrandir> mdz: ok.
<ogra> apart from not having l-r-m installed for some obscure reason, edubuntu server and serveraddon amd64 look ok
<BenC> http://people.ubuntu.com/~bcollins/kernels/bug-93648/linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<BenC> 8172368b874be9ed6777c818052e08a4  linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<BenC> sladen: ^^
<BenC> and anyone else experiencing that bug
<sladen> BenC: fetching
<Keybuk> kylem: I have an ICH7 Wintel, not a mactel
<\sh> re
<Mithrandir> mdz: so just one day delay, then?
<BenC> We have one confirmed on the new kernel
<dholbach> cjwatson, Riddell: do you know anything about bug 93289?
<Ubugtu> Malone bug 93289 in debconf "[apport]  dpkg-preconfigure crashed with SIGSEGV in xcall_QGroupBox()" [Medium,Unconfirmed]  https://launchpad.net/bugs/93289
<sladen> BenC: that boots, though with the following two lines in dmesg
<mdz> Mithrandir: fix today, test through tomorrow, out friday? sounds like a reasonable estimate
<sladen> [    3.320000]  PCI: Unable to reserve I/O region #1:8@1f0 for device 0000:00:1f.2
<sladen> [    3.320000]  ahci: probe of 0000:00:1f.2 failed with error -16
<BenC> sladen: expected, not a problem
<BenC> sladen: thanks for testing
<BenC> mdz, Mithrandir: that's two confirmed, so I'm uploading -12.20 now
<cjwatson> dholbach: YA dup of a libqt-perl bug (or lower)
* cjwatson punts it over
<mdz> BenC: excellent
<dholbach> cjwatson: ok, with bughelper I found those 12 dups of it :)
<FordCapri>  is there a good mailing list to post to if you want to get involved in Google SoC?
<Riddell> dholbach: yes, I've seen that bug reported before
<BenC> Mithrandir: this still wont fix ia64 build, so expect that
<sladen> FordCapri: http://wiki.ubuntu.com/GoogleSoC2007  and talk to Keybuk if that doesn't cover anything
<mdz> Mithrandir: I can wait for the kernel build and respin if you send me instructions
<cjwatson> pitti: the retraces in bug 93289 aren't exactly useful ...
<Ubugtu> Malone bug 93289 in libqt-perl "[apport]  dpkg-preconfigure crashed with SIGSEGV in xcall_QGroupBox()" [Medium,Unconfirmed]  https://launchpad.net/bugs/93289
<pitti> cjwatson: looking
<Mithrandir> mdz: I'll be fine doing it since I have it all lined up anyway.
<Mithrandir> mdz: but fix today, test tomorrow, release friday is a good plan.
<Mithrandir> BenC: ia64 is a ports arch, i.e. nice to have, but not a beta blocker.
<ogra_> cjwatson, looking at my installer syslog, it seems the installer always picks linux-image as Kernel-Stem, never just linux
<ogra_> so i end up without l-r-m
<pitti> cjwatson: weird, I just looked into the log of the retracer, and it doesn't even appear there
<pitti> dholbach: did you happen to have retraced bug 93289 manually/
<Ubugtu> Malone bug 93289 in libqt-perl "[apport]  dpkg-preconfigure crashed with SIGSEGV in xcall_QGroupBox()" [Medium,Unconfirmed]  https://launchpad.net/bugs/93289
<dholbach> pitti: no
<cjwatson> ogra_: can I see that log?
<ogra_> cjwatson, sure, wait a sec
<ogra_> cjwatson, http://people.ubuntu.com/~ogra/syslog
<ogra_> linux-generic is on the CD ...
<cjwatson> ogra_: URL to CD?
<ogra_> em, wait
<ogra_> it isnt on the CD
<ogra_> hmm, how can that happen
<cjwatson> it is on the CD I looked at
<cjwatson> ah, it's that stupid hack in base-installer I wish I could kill
<ogra> http://cdimage.ubuntu.com/edubuntu/daily/20070320.3/feisty-server-amd64.list agrees with you
<ogra_> ogra@edubuntu:~/seeds/ubuntu.feisty$ ls /cdrom/pool/main/l/linux-meta/
<ogra_> linux-headers-generic_2.6.20.12.8_amd64.deb  linux-image-amd64-generic_2.6.20.12.8_amd64.deb  linux-image-generic_2.6.20.12.8_amd64.deb
<ogra_> doesnt
<ogra_> cat /cdrom/.disk/info 
<ogra_> Edubuntu 7.04 "Feisty Fawn" - Alpha amd64 Binary-1 (20070320.3)
<cjwatson> ogra_: it's in /restricted/l/linux-meta/
<ogra_> meh
<ogra_> sorry
<ogra_> but it still doesnt get installed
<cjwatson> yeah, base-installer bug, fixing
<cjwatson> thanks
<ogra_> thanks as well :)
<soc> hi
<soc> is there a plan when kile will be updated to 1.9?
<soc> it's currently 1.8 on amd64
<soc> it seems it was forgotten when syncing with debian
<l3mr> i'm trying to port my app from os x tiger to linux; GL_FRAMEBUFFER_EXTs are not recognized. Do i need special includes on linux to use FBOs? I'm using Kubuntu with the latest nvidia drivers...
<sladen> soc: check back after Ubuntu 7.04 has released, it should get synced then
<soc> sladen: that's quite sad, the package is broken since edgy!
<soc> and it seems no one cares
<cjwatson> Mithrandir: can I please have base-installer 1.70ubuntu6 approved for beta? fixes ogra's bug above
<soc> the surprising thing is, that it works flawless if you use the package from debian.org
<sladen> soc: what's the bug number?
<soc> mom
<Riddell> soc: hobbsee was working on it, not sure if she got anywhere
<soc> https://bugs.launchpad.net/ubuntu/+source/kile/+bug/94084
<Ubugtu> Malone bug 94084 in kile "kile doesn't install with aptitude and texlive" [Undecided,Unconfirmed]  
<soc> I added my description
<soc> it seems that the orignal author had the same problem
<soc> but couldn't connect it to the outdated version
<sladen> soc: the best place to follow it up would be with hobbsee in #ubuntu-motu and on the bug report (which is probably a dup if it's already being worked on)
<soc> and the outdated version breaks lyx, and the whole tetex/livetex packages
<Riddell> l3mr: you need to ask on a programmers channel
<soc> http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=kile&searchon=names&subword=1&version=all&release=all
<sladen> soc: could you include that information in the bug report so that it doesn't get lost
<soc> ok, what's the name of the programmers channel?
<soc> motu?
<sladen> soc: #ubuntu-motu
<soc> ok thanks
<l3mr> Riddell: in #ubuntu and #kubuntu i was advised  to ask here.. but ty
<soc> I'll go there
<dushko> soc: Ridell wasn't talking to you
<sladen> l3mr: GL_FRAMEBUFFER_EXT is an /extension/ and therefore by definition may not be available.  try googling for  'mesa GL_FRAMEBUFFER_EXT'  
<l3mr> sladen: yeah but i'm pretty sure that nv7900 can do fbos :) ty, anyway
<sladen> l3mr: if you're using an nvidia driver, check that it is supported.  http://www.nvnews.net/vbulletin/showthread.php?t=58486  suggests that it is on Windows, but nvidia may not have added it to their Linux driver.  Either way, this isn't really the best place to be asking;  perhaps an OpenGL programmers' specific forum would work.
<l3mr> sladen: yeah i'm also in #opengl and #c++ :)
<ogra_> cjwatson, seems bug 94361 might be related to mine
<Ubugtu> Malone bug 94361 in Ubuntu "live CD does not ship nvidia-glx" [Undecided,Confirmed]  https://launchpad.net/bugs/94361
<ogra_> and bug 94359
<Ubugtu> Malone bug 94359 in restricted-manager "live system does not have nvidia/fglrx kernel modules" [Medium,In progress]  https://launchpad.net/bugs/94359
<cjwatson> ogr	doubt it
<cjwatson> the live filesystem doesn't touch base-installer
<ogra_> ah, right ...
<tbf> CRAP!
<tbf> wtf feisty believes a boot partion of 50MB is too small?
* tbf cannot resize that partition :-/
<cjwatson> that shouldn't be too small unless you have a number of kernels installed
<tbf> cjwatson: update-manager says it is
<cjwatson> though you can probably only fit about three in there
<cjwatson> you might need to remove some old kernels first
<tbf> "Die Systemaktualisierung bricht jetzt ab. Bitte machen Sie mindestens 6701k Plattenplatz auf /boot frei. Leeren Sie Ihren Mlleimer und entfernen die temporre Pakete von frhreren Installation mit 'sudo apt-get clean'."
<tbf> cjwatson: there is only the current kernel left
<tbf> in english: "The upgrade aborts now. Please free at least 6701k of disk space on /boot. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'."
<cjwatson> 'df /boot' and => #ubuntu+1 probably ...
<sladen> tbf: does  du -sch /boot/*  tell you where that space has gone?
<BenC> probably filled up with old kernels and initrd's
<tbf> # LC_ALL=C du -sch /boot/
<tbf> 8.2M    total
<tbf> # LC_ALL=C df -h /boot
<tbf> /dev/hde5              45M  8.9M   33M  22% /boot
<tbf> ok, just 45M
<Mithrandir> cjwatson: ok.
<DarkSun88> Hi
* lamont wonders who it was that broke dch so that it assumes I mean feisty
<asac> oh ... my bzr branch appears to be corrupted ... i just tried to push like: bzr push sftp://asac@bazaar.launchpad.net/~asac/firefox/trunk
<asac> now i always get
<asac> bzr: ERROR: Not a branch: sftp://asac@bazaar.launchpad.net/~asac/firefox/trunk/.bzr/branch/
<asac> anyone seen this?
<Riddell> asac: do you have python-paramiko installed?
<Riddell> asac: tried taking the ".bzr/branch/" off the end
<asac> hmm 
<Riddell> Mithrandir: are new ISOs coming today?
<Mithrandir> Riddell: yes, but waiting for new kernel so don't hold your breath.
<asac> Riddell: riddel yes its installed
<Mithrandir> probably around 00:00 UTC
<fabbione> new kernel?
<Riddell> Mithrandir: ok
<pochu> fabbione: bug 93648
<Ubugtu> Malone bug 93648 in linux-source-2.6.20 "2.6.20-12 fails to boot with ICH6 SATA (ahci_init_one/pci_iounmap BUG at lib/iomap.c:254)" [Critical,Fix committed]  https://launchpad.net/bugs/93648
<asac> Riddell: maybe look here
<asac> https://code.beta.launchpad.net/~asac/firefox/trunk
<fabbione> feeeh
<asac> there is an error : "Launchpad could not mirror this branch 9 minutes ago.  The error was: Not a branch: /srv/sm-ng/push-branches/00/00/0c/45/.bzr/branch/"
<Riddell> asac: try asking ddaa
<asac> where?
<asac> ok
<BenC> mdz, Mithrandir: just for warm fuzzy sake, I've gotten 4 more confirmed from the bug report for that kernel
<fabbione> Mithrandir: could you please respin sparc-server only? i am happy to have an older kernel on it. I just need to have the latest finish-install to fix the ttyS0 issue
<ivoks> who should i contact regarind ubuntu trademark issues? :)
<Mithrandir> fabbione: preferably not, I'd like everything to be in sync for beta.
<Keybuk> ivoks: which trademark?
<Keybuk> (and what kind of issue)
<ivoks> Keybuk: one computer seller in croatia want to distribute ubuntu and is interested in printing covers for CD
<fabbione> Mithrandir: understood, but is testing ISO tomorrow an option?
<ivoks> Keybuk: so, they would like to add their logo and ubuntu logo on CD
<Mithrandir> fabbione: yes, we are delaying release until Friday.
<fabbione> Mithrandir: ok. perfect.
<ivoks> Keybuk: like 'CompanyX distributes Ubuntu for you'
<ivoks> Keybuk: or something like that...
* fabbione powers off the nuclear reactor and heads offline
<ivoks> Keybuk: this is only biggest computer provider in croatia :D
<Keybuk> for that, I'd say Jane Silber
<ivoks> ok, thanks
<Nafallo> LOL
<Nafallo> I wondered where I recognized that serial from :-P
<wereHamster> \sh, regarding wine, the problem is this: my little piece of software points LD_LIBRARY_PATH to a directory with a modified libGL.so
<wereHamster> but wine never seems to load the modified lirary, it seems as someone wiped LD_LIBRARY_PATH clean
<wereHamster> well.. there are two possibilities: wine tries to load the modified library but it's incompatible or wine doesn't even try to load it.
<wereHamster> since it works with other apps (glxgears and a game, don't remember the name though), it's can't be the incompatiility
<cjwatson> wereHamster: two things I'd investigate (and haven't): something might be set-id, or some script might set LD_LIBRARY_PATH rather than prepending to it
<cjwatson> (or appending)
<wereHamster> cjwatson, the stupid winelauncher does the prepending thing.. pure evel if you ask me :(
<wereHamster> but why would the wine deb use that and the normal install not?
<wereHamster> s/evel/evil/
<\sh> wereHamster: what you can do is to compare your "native install of wine" with the installed files of the wine package
<\sh> wereHamster: and as I said yesterday, we (scott the wine-hq ubuntu package maintainer) and I are not patching anything into wine
<\sh> wereHamster: when I start wine (wine 0.9.33 on feisty now) and read the strace file, I can see it loads the systems libGL.so.1
<wereHamster> \sh, I assume you didn't start it using yukon
<\sh> wereHamster: no...I just check what it searches and where :)
<\sh> wereHamster: did you try to use EXTRA_LD_LIBRARY_PATH ?
<wereHamster> \sh, the problem is when you point LD_LIBRARY_PATH to a directory with a libGL.so.1, it won't use it
<wereHamster> it will still use the one from the system
<\sh> wereHamster: yepp I see it :(
<hunger> BenC: I am at home now and can test kernel updates if that helps you.
<\sh> wereHamster: problem is, I don't find anything which sets the environment of LD_LIBRARY_PATH to ""
<BenC> hunger: http://people.ubuntu.com/~bcollins/kernels/bug-93648/linux-image-2.6.20-12-generic_2.6.20-12.20_i386.deb
<BenC> hunger: I've already had about 10 confirmations, so it's just a matter of whether you want to get a working system :)
<hunger> BenC: So I guess this will end up on archive.u.c soon. I'll wait till it gets there.
<BenC> hunger: probably by this evening
<BenC> hunger: or in about 4-8 hours to avoid TZ issues with "this evening" :)
<\sh> wereHamster: but I can see, that it honors LD_LIBRARY_PATH
<\sh> wereHamster: but it searches the system dirs before the LD_LIBRARY_PATH (/usr/bin/../lib/...) and I think that's the problem
<wereHamster> \sh, http://www.pastey.net/8836
<wereHamster> I installed wine myself from sources
<\sh> wereHamster: can you paste more then the 40 lines? best to to load of libLG.so.1 :)
<wereHamster> \sh, first reference to libGL.so.1 is: open("/usr/lib32/yukon/libGL.so.1", O_RDONLY) = 9
<wereHamster> .. on line 2827
<\sh> hmmm...something is really wrong with the path search order 
<wereHamster> \sh, yours searches '/usr/bin/../lib' before the one specified in LD_LIBRARY_PATH?
<wereHamster> .. or doesn't it look into LD_LIBRARY_PATH? at all?
<\sh> wereHamster: yepp...it searches first in /usr/bin/../lib/... and when it doesn't find  the lib it searches in LD_LIBRARY_PATH
<wereHamster> weird
<psusi> I'm a bit confused on the construction of the livecd/desktop cd.... most of the packages are installed already and just copied wholesale during isntallation from the live filesystem image to the target system?  but some packages are not installed but instead are in the archive?
<\sh> what could trigger something like this
<cjwatson> psusi: virtually everything is just copied wholesale. One or two things are on an archive on the CD. Language packs may be downloaded from the network.
<cjwatson> and some things are removed after being copied if they aren't needed
<psusi> cjwatson: it looks like there are a few dozen packages in the archive.... I'm wondering why?
<psusi> including gcc, build-essential, ndiswrapper-utils and -common
<wereHamster> \sh, since LD_LIBRARY_PATH is parsed before what is in /etc/ld.so.conf, the only explanation is that LD_LIBRARY_PATH contains '/usr/bin/../lib/'
<BenC> psusi: Has a lot to do with space on the CD
<\sh> wereHamster: no...I started a new login...LD_LIBRARY_PATH is in my home env empty. 
<psusi> BenC: how so?  there is room for the packages but only in their uninstalled form?  that seems odd
<psusi> should take up pretty much the same space either way no?
<psusi> since the whole cd is squashfs'd
<cjwatson> psusi: convenience. the installer doesn't install any of those but you might need them to get online.
<BenC> psusi: You've lost me then, you mean packages in pool/ on the CD?
<psusi> yep
<cjwatson> psusi: see http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.feisty/ship-live
<psusi> ty
<wereHamster> \sh, maybe a shell script that starts wine?
<\sh> wereHamster: nope../usr/bin/wine 
<\sh> wereHamster: the path itself is very strange..../usr/bin/../lib/... who would set something like this
<Treenaks> \sh: looks generated
<wereHamster> \sh, yes, it's wien always uses that path
<\sh> Treenaks: jepp..and only with ubuntu packages...
<wereHamster> open("/usr/bin/../lib/tls/i686/sse2/libwine.so.1", O_RDONLY)
<wereHamster> I see it, too
<\sh> now, what process is changing the search order ... LD_LIBRARY_PATH needs to be honored first, as far as I remember
<wereHamster> it would be nice to printf(getenv("LD_LIBRARY_PATH")) from within wine (or better yet, opengl32.dll.so, just before it dlopen()'s libGL.so.1)
<giangy> oi oi
<\sh> wereHamster: can you get the ubuntu source packages of wine (add to /etc/apt/sources.list the line deb-src http://archive.ubuntu.com/ubuntu feisty main restricted universe multiverse, then apt-get source wine) and try to build this package on your machine...and install your generated package
<\sh> wereHamster: I'll do it here as well, and check if it could be something with the binary itself
<wereHamster> \sh, problem: I'm not running ubuntu. The bug report is from a user, http://neopsis.com/projects/yukon/ticket/8
<wereHamster> he's on IRC, too
<wereHamster> and quite capable, I think he'd test it if you told him what to do
<wereHamster>  /msg Intangir
<Intangir> wereHamster: yo ;)
<\sh> I think we found one of the problems already ;)
<\sh> but the main problem is, why is wine putting LD_LIBRARY_PATH behind anything else
<wereHamster> some startup script?
<Intangir> i dont think any scripts are used in the binary install
<\sh> wereHamster: check your wine startup script..is it a script or a binary
<Intangir> i dont see any used.
<\sh> Intangir: yepp.....
<Intangir> but if that winewrapper script is used from the source install, somehow it magically works ;)
<Intangir> i tried launching it with exec, or exporting LD_LIBARY_PATH like you see in the winewrapper, but that didnt fix it
<wereHamster> /usr/bin/wine is a elf executable
<\sh> wereHamster: which distro are you using?
<wereHamster> gentoo, but I installed wine myself
<Intangir> with make install?
<\sh> wereHamster: but via make install and in the normal system directories (usr/{bin,lib,...})
<wereHamster> yes
<Intangir> so if you do make install, it doesnt use scripts? and it works?
<Intangir> with yukon?
<\sh> wereHamster: and you don't see this problem...on gentoo it works...
<wereHamster> yes, it works
<Intangir> did you add your /usr/lib/yukon path to ld.so.conf and do ldconfig ir something?
<\sh> Intangir: it doesn't have anything to do with yukon...it's a general problem with something in/on/with Ubuntu
<Intangir> wonder if that would be a easy way around this..
<wereHamster> no, I just use the yukon script
<\sh> Intangir: because the packages from winehq for ubuntu are having the same problems
<Intangir> this is confusing, so if you make install, it works ..?
<Intangir> even without any winewrapper script
<Intangir> ill try that when i get home later
<\sh> and more weired, that it only happens with wine 
<sladen> wine is in Universe, perhaps we could take this across to #ubuntu-motu
<Intangir> motu?
<Intangir> wine is in universe? since when?
<\sh> yepp..universe packages are normally discussed in #ubuntu-motu
<wereHamster> how badly do you require the packages to be autotoolized (to be accepted as a ubuntu package)?
<shawarma> Intangir: wine has always been in universe.
<shawarma> Intangir: http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=wine
<Intangir> ive never seen it there, i alw.. am i getting something confused
<Intangir> ive always had to add another repo to get it to show wine in the list of packages
<Intangir> weird i dont get it
<Intangir> ;)
<shawarma> heh..
<Intangir> ive been adding deb http://wine.budgetdedicated.com/apt dapper main
<Intangir> to install wine
<mvo> ogra: you haven't submited a bugreport about the missing icon in g-a-i
<mvo> ogra_: you haven't submited a bugreport about the missing icon in g-a-i and the addon-cd
<ajmitch> morning
<shawarma> ajmitch: No it's not.
<shawarma> :-P
<pbn> godverdomme
<Seveas> pbn, behave...
<Rocha> hello, i'm trying to fix a bug in apport
<Rocha> my first attempt at fixing a bug in a ubuntu program
<Seveas> Rocha, beware, pitti will hug you ;)
<Rocha> i'm having a little trouble with python and https urllib support
<Rocha> Seveas: he hugged me yesterday :)
<Seveas> Rocha, heh ;)
<Seveas> Rocha, what's the problem?
<Rocha> the trouble is that i'm working at college and found a bug in desktop-effects app, tried to report it using apport and it didn't work because i'm behind a proxy
<Rocha> i learned python to try reading the source code..
<Rocha> i'm found that the problem is that i didn't have the https_proxy environment variable set
<Rocha> i've set it and it gives me a "http error: not implemented"
<Rocha> i suppose it's a problem in urllib's implementation
<Seveas> Rocha, are you sure your proxy can do https?
<Rocha> perfectly, i can access gmail and launchpad
<Rocha> i use the same proxy with firefox
<Rocha> Seveas: and "wget --proxy=on https://launchpad.net" works too
<Rocha> it downloads the index.html file
<pepsiman> Hi, I've upgraded to feisty and the cx88-dvb module isn't loaded at boot, it was in edgy.  Any idea why it has changed?  The other modules for this card are loaded correctly
<Rocha> Seveas: using urllib.retrieveurl("https://launchpad.net","index.html") it doesn't work
<Rocha> Seveas: i mean, it downloads the index.html but it's an error page
<Rocha> "Unsupported Request Method and Protocol" page error from my proxy
<Seveas> Rocha, hmm, I must confess I'm not that familiar with urllib
<Seveas> I generally use urllib2 
<Seveas> https_open
<Rocha> "Squid does not support all request methods for all access protocols. For example, you can not POST a Gopher request."
<Rocha> ok, i'll try using urllib2 to see if it works
<Seveas> Rocha, ah, that's an error in the proxy
<Seveas> so apparently urllib is being weird :)
<Rocha> it's an error in the proxy but i think it's in the request that urllib is making
<Rocha> due to my python inexperience i won't be able to fix the urllib bug
<Seveas> too bad it's https, can't sniff what's being sent :)
<Rocha> i'm apt-getting python2.5 source
<Rocha> if it's written in C, i'll understand
<maswan> Seveas: just mitm it? ;)
<Seveas> maswan, heh
<pochu> Mithrandir: do you know when the new images will be available, so we can start to test them? :)
<Mithrandir> pochu: probably around 0100 UTC or so
<pochu> ok, thanks :)
<Rocha> Seveas: i think i've found the error, python is sending a post request to the proxy
<Seveas> Rocha, it needs to do that
<Seveas> for launchpad/gmail (which work) firefox does the same :)
<Rocha> strange...
<Rocha> wget works, python doesn't so it's definitely a python bug
<Rocha> i guess i'll ignore this error then
<Rocha> Seveas: btw, do you know if it's possible to plug a vga cable on a laptop and X automatically expand to two monitors like windows does?
<Seveas> Rocha, not yet
<Seveas> hopefully for feisty+1 with xorg7.3
<pepsiman> Hi, I've upgraded to feisty and the cx88-dvb module isn't loaded at boot, it was in edgy.  Any idea why it has changed?  The other modules for this card are loaded correctly
<Rocha> Seveas: i'm asking this because i'll try to code something for sonypi to enable me to control the screen brightness
<Rocha> Seveas: and it would be great to code that too
<_ion> It occurred to me that libwhat could be used to implement the "type your username and password while usplash is still on" functionality as well.
<Seveas> _ion, evil
<Seveas> _ion, I like the idea of libwhat though
<_ion> I added an usplash mockup to the page as well, btw.
<Burgwork> Rocha: that requires xserver 1.3, which isn't out yet
<Burgwork> it is unlikely to make Feisty
<Rocha> Burgwork: ok, i won't try to work on that
<Burgwork> _ion: linky?
<_ion> burgwork: http://johan.kiviniemi.name/blag/2007/03/21/upstart-and-interaction-with-user/
<Seveas> _ion, why aren't you on plant ubuntu?
<_ion> seveas: For starters, i haven't applied for membership.
<_ion> Also my blag posts aren't all Ubuntu-related, and i haven't bothered to install a blog engine that allows me to set categories as of yet.
<niktaris> cjwatson, hi, localization does not work with the ubiquity-gtkui.desktop file. only way to make it work is to remove Categories=GTK;System;Settings; OnlyShowIn=GNOME;XFCE; X-Ubuntu-Gettext-Domain=ubiquity
<niktaris> cjwatson, how important are those ?
<cjwatson> niktaris: "does not work"? Also, file a bug rather than asking me on IRC please
<cjwatson> preferably with more detail. :-)
<niktaris> cjwatson, this is only to get a first opinion from you. :-) a bugreport will follow. By not working I mean that the word "install" does not get translated in greek when greek is the default language
<keescook> anyone else having problems reaching LP?
<sistpoty> keescook: yes
<keescook> sistpoty: okay, I didn't want to be alone.  :)
<sistpoty> :)
<Mithrandir> the DC seems to have fallen off the planet.
<keescook> Mithrandir: is archive.u.c hosted elsewhere?
<Fujitsu> Mithrandir: archive, cdimage, releases are fine.
<zyga> lp is fine for me
<zyga> does anyone know how to use python-apt bindings to check which repositories are enabled?
<Fujitsu> Seems to be the same sort of thing as with archive and cdimage last night... Dead for only some people.
<Fujitsu> How encouraging.
<LaserJock> Fujitsu: I think dead for a lot of people
<zyga> okay it's dead for me too
<Mithrandir> cjwatson: do we need a new d-i?
<Mithrandir> cjwatson: the bug was in the core kernel, but I don't remember if debian-cd does the right thing and grabs the kernel from the latest kernel or if it uses the stuff in installer-$arch
<Amaranth> zyga: I seem to remember that not being possible (checking repos)
<zyga> Amaranth: hmm, might be better
<zyga> I thought that loading apt is heavier than parsin the sources file anyway
<niktaris> cjwatson, X-Ubuntu-Gettext-Domain string is causing the problem.... looking....
<zyga> niktaris: could you priovide some detail, please?
<cjwatson> Mithrandir: hmm, yes, a new d-i would probably be safest
<cjwatson> Mithrandir: is the new kernel built everywhere?
<Mithrandir> cjwatson: yes, and published.
<Mithrandir> publisher is on manual
<Mithrandir> should I do the upload or do you want to?
<cjwatson> I'm preparing it
<Mithrandir> thanks
<cjwatson> I'd like to remove-package the -11 kernels ttoo
<cjwatson> too
<Mithrandir> please.
<niktaris> zyga, I am trying :). ubiquity-gtkui.desktop file is not translated on the desktop if the default language is Greek. Removing X-Ubuntu-Gettext-Domain=ubiquity from the .desktop file seems to solve the problem
<zyga> niktaris: curious, could you check something for me?
<zyga> niktaris: could you locate the ubuquity.mo file on your system and tell me their paths?
<niktaris> zyga, sure wait
<zyga> ubiquity.mo (sorry for bad spelling)
<cjwatson> bear in mind that I haven't updated the ubiquity desktop translations since edgy, although Greek seems to be up to date anyway
<cjwatson> Mithrandir: removed. (sucks to be ia64 now, though)
<niktaris> zyga, not found
<cjwatson> Mithrandir: d-i accepted
<zyga> hmm
<niktaris> no .mo file
<cjwatson> er, wait
<cjwatson> d-i accepted now
<zyga> niktaris: not even one?
<niktaris> nope
<zyga> niktaris: oh wait
<zyga> ubiquity is the cd installer and it might do some magic do load translations as it changes them on the fly
<cjwatson> not the desktop files it doesn't
<Mithrandir> cjwatson: thanks a lot; I'll see it through
* Mithrandir sees a fairly long night in front of him
<zyga> could you check if the desktop file has the greek translation iside?
<Mithrandir> pochu: that 0100 UTC estimate won't hold, btw.
<LaserJock> poor Tollef
<niktaris> zyga, note that all is ok in the system- > prefrences menu
<niktaris> zyga, yes it does
<niktaris> if I remove the line X-Ubuntu-Gettext-Domain=ubiquity it displays OK
<cjwatson> yeah, but doing that kills langpacks, iirc
<zyga> niktaris: file a bug on ...
<zyga> wait 
<cjwatson> I'm not doing that
<niktaris> cjwatson, strange thing is that other apps (eg gcalctool) that also have a X-Ubuntu-Gettext-Domain sting has no problem
<niktaris> so it should not be general 
<cjwatson> let me revise that, I'm not doing that unless/until pitti tells me I can
<zyga> darn I cannot remember the package
<zyga> I wrote that code
<mdke> can anyone else not boot with the latest kernel? Some kind of modprobe error? If it's known I won't bother investigating further
<niktaris> I am wondering why it works in the gnome menu
<zyga> niktaris: there are separate code paths in several libraries
<Mithrandir> mdke: can you please update to the latest kernel?  Unless you updated in the last half hour, your version is old.
<Mithrandir> mdke: (and the bug is fixed in the absolute newest one)
<mdke> Mithrandir: great news. The archive doesn't have it yet I don't think, I just did an update
<cjwatson> hmm. all the ubiquity.mo files seem to be in language-pack-kde-*-base
<zyga> niktaris: the menu uses different code than the desktop
<zyga> the desktop used glib's stuff
<Mithrandir> mdke: you're using archive.u.c directly?
<zyga> to parse .desktop files
<cjwatson> you may well find that X-Ubuntu-Gettext-Domain causes the system to require the correct language pack to be present
<mdke> Mithrandir: yah
<pochu> Mithrandir: ok, np
<zyga> I patched that but I really don't understand why it takes the internal translations away
<cjwatson> niktaris: try installing language-pack-kde-el-base
<zyga> it's supposed to take the external translations ONLY if they are available
<zyga> cjwatson: that's not the problem - the translation SHOULD be shown - it's a bug non the less
<cjwatson> zyga: correction, it's half the problem
<zyga> cjwatson: how so?
<cjwatson> you're correct that the code needs to be fixed
<cjwatson> however it is wrong for ubiquity.mo to be in language-pack-kde-*
<zyga> cjwatson: yeah I guess it's not right 
<zyga> ubiquity is quite special
<cjwatson> not special in this regard
<pochu> good night folks!
<pochu> and happy rebuilding ;)
<cjwatson> special in lots of other ways, yes, but ...
#ubuntu-devel 2007-03-22
<zyga> cjwatson: I don't use gnome anymore and I have no desktop so that I could fix this
<zyga> let's start by filling a bug :-)
<zyga> niktaris: could you file a bug on glib in ubuntu (not in upstream) using lanchpad?
<zyga> describe the issue, make sure you say that you had no ubiquity.mo installed
<zyga> make sure you say that the file HAS greek translations
<zyga> make sure you say that this is related to the patch made in ubuntu to support x-gettext-domain 
<zyga> and finally make sure you say that if you remove that line (the x-yada-yada) it's working 
<zyga> If you could do that I'll look at it in a second
<zyga> and please attach the desktop file
<cjwatson> please also create a bug task on that bug on the langpack-o-matic upstream product to say that the .mo is in the wrong place in the language packs and should be moved
<zyga> niktaris: oh and most important - file it on the appropriate VERSION of your system and glib
<niktaris> zyga, I don't like launchpad. but will do
<niktaris> zyga, update
<zyga> niktaris: update?
<niktaris> when using: X-Ubuntu-Gettext-Domain=ubiquity no-go
<zyga> ok
<niktaris> zyga, status-update :)
<niktaris> when using X-Ubuntu-Gettext-Domain=gcalctool in the same file OK
<niktaris> this is with a fresh .desktop file . let me reboot and check again
<zyga> hmm?
<zyga> no wait
<zyga> what is the string in question
<zyga> what gets translated?
<cjwatson> "Install"
<niktaris> yes
<zyga> hmm
<zyga> install is a common word
<zyga> I bet it's translated in gcalctool somewhere
<zyga> niktaris: which version of ubuntu are you using?
<niktaris> 6.10
<cjwatson> it's not, AFAICS
<cjwatson> at least not with the couple-of-days-out-of-date feisty langpacks I have here
<zyga> cjwatson: it's not translated?
<cjwatson> not in gcalctool
<zyga> hmm, queer!
<cjwatson> could be in edgy though, *shrug*
<zyga> I'll check the source
<zyga> looking at it now (in edgy)
<zyga> hmm, my patch was updated - it's no longer that simple 
<niktaris> zyga, trying to replace X-Ubuntu-Gettext-Domain=ubiquity with X-Ubuntu-Gettext-Domain=gcalctool did not work with the original .desktop file
<niktaris> removing X-Ubuntu-Gettext-Domain=ubiquity works though
<zyga> okay
<zyga> that makes is more sane at least
<niktaris> zyga, u still want that bugreport ?
<zyga> niktaris: yes please
<zyga> so that the details don't slip if I cannot fix this in a moment
<niktaris> zyga, against glibc stating installed version and ubiquity version  ?
<zyga> not glibc, just glib
<zyga> ubiquity is not relevant to me, only the desktop file and glib version
<niktaris> sorry tupo
<niktaris> tupo/typo
<zyga> those are the only components (as long as we are talking about a gnome desktop icon on the desktop (not in the panel)
<cjwatson> glib2.0 not glib
<niktaris> zyga, panel is OK
<zyga> cjwatson: right, sorry
<zyga> hmm
<zyga> I have an idea
<niktaris> zyga, will file the bug tomorrow . have to go
<niktaris> cu 
<zyga> niktaris: okay, thanks for your help
<zyga> bah, basically someone broke the code :P
<zyga> does anyone know what is the language code for greek?
<cjwatson> zyga: el
<zyga> thanks
<jtholmes> does anyone know if the 20070321  iso  images get created today I dont see them
<Mithrandir> hiya Hobbsee 
<Hobbsee> hey Mithrandir!  :)
* Mithrandir yawns
* Hobbsee gives Mithrandir some coffee
<mdz> Mithrandir: how goes it?
<Hobbsee> tiring, it sounds like
<Mithrandir> mdz: the final publisher run is almost finished, once that's done, I'll start the cd builds, catch a shower and crash.
* Hobbsee wonders, based on mako's comments, who's butt to kick repeatedly.
* bhale hopes to be on Hobbsee's good side
<Hobbsee> heh, yes.
<bhale> phew
<Mithrandir> Hobbsee: thanks, but I don't do coffee very well.  Especially not when I should be crashing RSN
<Hobbsee> ahh
<Mithrandir> mdz: I'll mail -devel once I'm done for today.
<mdz> Mithrandir: ok, thanks
<Burgwork> Hobbsee: mako's comments?
<Hobbsee> irc stuff
<Burgwork> Hobbsee: private or public?
* Hobbsee checks.  oh, private.
<Hobbsee> oops
<Hobbsee> issue was originally public
* Hobbsee shuts up
<Burgwork> ahh
<j1mc> were the xubuntu iso's re-rolled today?  i only see isos as of march 20th in the /current folder
<Mithrandir> j1mc: they are being now.
<j1mc> Mithrandir, thanks
<Mithrandir> oh well, shower, then bed.  See you all around tomorrow, please test ISOs as soon as they appear.
<Mithrandir> I've also mailed -devel with a short status report.
<jdong> mako: can I tap into your wisdom?
<mako> jdong: whatever i have :)
<Hobbsee> heya mako 
<mako> Hobbsee: hola
<Hobbsee> mako: see query..
<jdong> mako: see query.
<jdong> :)
<_ion> mako: see query
<jdong> yeah, I love you all too.
<keescook> Mithrandir (or other archive admin): please shove "file" (breezy, dapper, edgy) and "mysql-dfsg-5.0" (dapper, edgy) through.  (security updates)
<Riddell> "No alternate CD for i386!"
<Hobbsee> oh?
<Riddell> Mithrandir: that doesn't sound good
<Hobbsee> Riddell: has it just been not-rerolled yet?
<Riddell> "cp: cannot stat `/srv/cdimage.ubuntu.com/ftp/dists/feisty/main/installer-i386/current/images/udeb.list': No such file or directory"
<Riddell> logs suggest it's broken
<cjwatson> gar
<cjwatson> that bloody thing again. willfix
<Riddell> cjwatson: what causes it?
<cjwatson> soyuz bug
<cjwatson> should be fixed soon, but ...
<cjwatson> it's failing to unpack bits of d-i into the archive
<cjwatson> fixed, publisher running
<FordCortina> do i need to post somewhere or talk to someone to apply for google SoC?
<desrt> FordCortina; online via the google SoC website
<FordCortina> do i use their webapp then?
<desrt> yes.
<FordCortina> there's no interview or anything else to do?
<desrt> no.  you just write up a good application
<desrt> and try and convice us that you know your stuff and can finish successfully
<FordCortina> yeah your probably going to get a truck load i bet :)
<desrt> this is why you try and distinguish yourself from the crowd
<FordCortina> ill see what i can do
<desrt> it's the only fair way -- not good to prefer people who get in touch personally with the developers
<FordCortina> yeah, it seems that different sponsor have different ways to do things. I had to check :)
<desrt> if you wanted to give yourself a leg-up a good approach might me to start investigating the issues on the project you're interested in and provide insights you gain during that process as part of your application
<desrt> having some code also helps.. but that might be more work than you're willing to do :)
<FordCortina> i might be a bit tight for time, but we'll see
<FordCortina> i have plenty of experience with the issues involved so i'll definately cite those
<mdz> cjwatson: what's happening with rolling candidates?  I can take over driving it if needed, I'll be up for a while
<cjwatson> mdz: I've just this minute set off all the rebuilds needed to cope with the Soyuz bug mentioned above
<cjwatson> mdz: everything else is apparently being done automatically from Tollef's terminal
<cjwatson> mdz: all running as cdimage@lithium, so you can monitor those processes if you like
<mdz> cjwatson: ok, thanks
<cjwatson> actually I think some are running as tfheen@lithium, but no matter
<cjwatson> mdz: I'm off back to bed now - I think that's everything I can realistically do
<mdz> cjwatson: good night
<TheMuso> Anybody noticed that http://cdimage.ubuntu.com/daily/current/MD5SUMS only has the alternate i386 cd listed now due to the rebuild?
<TheMuso> Or is that because amd64 is still being rebuilt also?
<mdz> mdke: the help center is looking good
<mdz> TheMuso: it may be a bug, or it may be temporary
<mdz> amd64 seems to be finished now
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> morning guys
<jdub> hey fabbione 
<jdub> nice to see you blogging again!
<fabbione> jdub: ehhe after only 15 months of silence :)
<bddebian> Has it only been that long?
* bddebian ducks
<bddebian> j/k
<fabbione> md1 : active raid5 hdd2[4]  hda2[0]  hdc2[2]  hdb2[1] 
<fabbione>       1170632256 blocks level 5, 64k chunk, algorithm 2 [4/3]  [UUU_] 
<fabbione>       [>....................]   recovery =  0.6% (2367744/390210752) finish=6249.2min speed=1032K/sec
<fabbione> those are the kind of things you *hate* the day before release
<Lathiat> yay :(
<joejaxx> fabbione: :\
<racarr> my patched desktop-effects enables universe before installing Beryl from it if the user chooses to install Beryl, what kind of warning do I have to give them about enabling universe?
<Burgundavia> racarr: see the gnome-app-install one
<LaserJock> racarr: so are the users given a choice between compiz and beryl?
<LaserJock> and do compiz and beryl conflict?
<racarr> no, they don't
<fabbione> too bad beryl can trigger a memory leak in nVidia and everything goes south
<racarr> don't conflict that is LaserJock
<racarr> and yes a little combo box to choose (combo box makes more sense than enable beryl/compiz buttons because combo box has a default)
<racarr> and err, I've never heard of that fabbione
<fabbione> racarr: beryl forum is full of that report... windows become black
<racarr> That's not a memory leak
<fabbione> and enabling the workarounds makes everything very slow
<fabbione> ok.. it did look like a memory leak
<LaserJock> racarr: ok cool, just wondered how that would work
<fabbione> or something running out of GFX mem
<racarr> Yeah, due to a bug in the drivers when they run out of VRAM their texture_from_pixmap implementation goes haywire
<racarr> nvidias said they will fix it at some point :p
<racarr> LaserJock: Probably not the best solution (throwing two names "Compiz" and "Beryl" at a user is kind of strange), but eh
<fabbione> racarr: well something along those line, but at the end it makes beryl unusable
<fabbione> the workaround just makes everything too slow
<racarr> well, you can use XGL
<fabbione> it's not a big deal.. eye candies are optional for what i need
<fabbione> i will just wait for nvidia to fix the drivers
<fabbione> racarr: i assume the 9755 don't have the fix
<fabbione> (we ship 9631 in Ubuntu)
<racarr> fabbione: I havent' read the release notes, but if they do I haven't heard about it
* fabbione checks for the fun
<racarr> I guess since I rewrote desktop-effects in python  it has to go through NEW again?
<fabbione> racarr: not if the package name is the same
<racarr> (The C implementation would have been a real pain to work with because it was set up to differentiate between Compiz == enabled and Metacity == disabled and I would have had to have mostly rewritten it anyway, so rewriting it in python seemed like a good choice)
<racarr> fabbione: ah, ok, good
<fabbione> nope. it's a new feature release
<Burgundavia> racarr: have you been in touch with the desktop-effects devs from Fedora? Fedora uses a fair amount of python as well, so they might accept your new version
<racarr> Burgundavia: No, I can send them an email though, I'm guessing it's probably Sorren or Kristian Hogsberg and history makes me think neither one of them would be excited about a desktop-effects that installs Beryl :p
<racarr> and that's the biggest difference
<Burgundavia> racarr: it is meeting a user demand
<racarr> Burgundavia: Maybe, which is why I will send them an email anyway
<pitti> Good morning
<Mithrandir> not really a good morning, no, sorry
<LaserJock> hi pitti 
<pitti> Mithrandir: FUBAR? :(
<Mithrandir> pitti: new i386 ISOs spinning now, at least.
<Mithrandir> rest should be testable, modulo DVDs.
* pitti rsyncs amd64
<Mithrandir> but it's more the fact that I've slept for about six hours, which isn't really enough.
<Mithrandir> keescook: publisher back on auto
* pitti hugs Mithrandir
<StevenK> Mithrandir: So you'll release the beta and sleep for 2 days?
<Mithrandir> StevenK: release postponed to Friday, but yes.
<doko> Mithrandir: do you have an estimated time for the dvd images (edubuntu)?
<Mithrandir> it needs the new livefs-es, so a fair bit, say in three-ish hours
<Mithrandir> ubuntu-server ready for testing.
<fabbione> Mithrandir: roger that
<fabbione> Mithrandir: can you give me also i386 netboot and sparc netboot for testing?
<fabbione> (as meta bugs)
<fabbione> netboot/netinstall
<fabbione> they don't really fit in iso testing.. but AFAIK we don't have another section.. do we?
<Fujitsu> pitti: Is there a reason that apport would be creating reports without a Package field here?
<fabbione> and it's missing i386 DVD afaict
<fabbione> Ubuntu i386 DVD
<Mithrandir> all dvds are out of date
<fabbione> yes i read before. i will test them as last
<pitti> Fujitsu: --verbose, please
<Mithrandir> ask Henrik about getting more tracker bugs, he's doing that bit.
<pitti> Fujitsu: you mean files in /var/crash?
<Fujitsu> pitti: Yep.
<Fujitsu> I've had three so far generated while testing crash bugs, and I've had to add Package fields manually.
<LaserJock> fabbione: what do you do to test the server .isos? just basic installation?
<pitti> Fujitsu: that's normal
<pitti> Fujitsu: it's not added until you call the GUI, and it's not written back to disk any more
<Fujitsu> Ah.
<Fujitsu> That is a little irritating when attempting to retrace them.
<fabbione> LaserJock: install / install on lvm /install with LAMP / install on LVM with LAMP
<fabbione> and other options like DNS server
<LaserJock> cool
<pitti> Fujitsu: it was to save some time mainly, but I can put it back if needed
<pitti> Fujitsu: in fact, it should be relatively easy to append the new stuff
<pitti> Fujitsu: I'd appreciate a bug report
<Fujitsu> pitti: I'll file one, thanks.
<fabbione> grrr
* fabbione reboots
<fabbione> brb
<cjwatson> Mithrandir: what was wrong with the i386 images I built last night?
<Mithrandir> cjwatson: nothing apart from me not knowing about them due to not reading scrollback well enough.
<cjwatson> ah
<Mithrandir> did you build DVDs too?
<cjwatson> no, the DVDs should have built after I republished d-i
<cjwatson> I rebuilt precisely what needed to be rebuilt
<Mithrandir> I didn't do DVD builds last night since they would want new livefs-es.
<Mithrandir> I'll do them as soon as the current round of builds is done.
<cjwatson> ok, I should have said "the DVDs didn't build before I republished d-i"
<Mithrandir> ah, ok.
<Mithrandir> if you don't mind, I'll ask for testing on this latest round of images, they should be identical to the earlier ones.
<cjwatson> no skin off my nose :)
<Mithrandir> ubuntu alternate and desktop images ready to test.
<pitti> Riddell: mh21 did it again -- this time a CLI apport frontend :)
<pitti> Riddell: what else do we need -- email, apache module, ircbot, ... :-P
<StevenK> pitti: An XML-RPC frontend... :-P
<pitti> StevenK: speaking xmlrpc doesn't sound particularly user friendly to me ?!?
<StevenK> pitti: Neither does maintaining an crash handler that speaks to SMTP, web and IRC services. :-P
<LaserJock> pitti: I don't suppose there's documentation for apport around?
<pitti> StevenK: no, I meant a GUI for crash reports
<pitti> StevenK: i. e. a web frontend for displaying current crashes on your server, etc.
<pitti> LaserJock: there are manpages, a doc about package hooks, and https://wiki.ubuntu.com/Apport with some links
<mdke> mdz: cheers. We could probably do some work on the design, but no one has really had the time so far
<viviersf> where does /etc/network/interfaces come from ( which program generates it )
<LaserJock> pitti: thanks, the wiki page was pretty much what I ws looking for
<pitti> Mithrandir: http://cdimage.ubuntu.com/daily-live/20070322.1/MD5SUMS only shows i386, and the amd64 desktop timestamp shows 20070322
<pitti> Mithrandir: oh, that's because you just regenerated i386?
<pitti> Mithrandir: 'Install with driver update CD' -- this is not covered by the current testing methods; can we test this at all ATM?
<siretart> Mithrandir: if you have a spare sec, could you please have a look and comment on bug #91676? 
<Ubugtu> Malone bug 91676 in wpasupplicant "wpa_supplicant crashes in: wpa_supplicant_dbus_notify_state_change (wpa_s=)" [Medium,Confirmed]  https://launchpad.net/bugs/91676
<hunger> I see "No module named "ScanPCI" during bootup (in S36displayconfig-hwprobe.py). Is that a known message?
<pitti> Fujitsu: Kees has a fix for that problem in his branch; apport-retrace now has a -R/--rebuild-package-info option
<poningru> just making sure but beta is prolonged till friday right?
* \sh is cursing his new toy
<heno> fabbione: you wanted netboot meta bugs?
<fabbione> heno: well yeah but i already added netboot info the corresponding iso install...
<fabbione> heno: netinstall would be more appropriate
<heno> fabbione: ok, that should be fine then. I'll post those next time
<fabbione> heno: that's fine with me.. it's not a blocker ;)
<\sh> anyone around who has fingers on an hp dl320s?
<fabbione> cjwatson: is there any reason why we don't ship scsi-firmware in the installer?
<fabbione> (d-i to be more precise)
<Mithrandir> pitti: yes, strange MD5SUMS is fine
<pitti> Mithrandir: thanks
<Mithrandir> pitti: I'm not sure what the driver update CD is; maybe Colin knows.
<cjwatson> fabbione: not particularly
<cjwatson> pitti: http://wiki.ubuntu.com/Ubiquity/DriverUpdates
<cjwatson> I don't think we have a test image prepared for it
<pitti> ok, so we should ignore this for now
<fabbione> cjwatson: ok. i only noticed because the qla24xx driver was complaining about not being able to load the fw, but it's not fatal
<Mithrandir> siretart: how does the diff to new upstream look?
<Mithrandir> edubuntu and kubuntu dvds building.
<Mithrandir> heno: all images but edubuntu and kubuntu DVDs should be current.
<heno> Mithrandir: thanks, just updating the status page with this morning's testing
<Mithrandir> heno: thanks a lot.  You might want to note that for !i386, the 20070322, 20070322.1 and 20070322.2 images are the same.
<Mithrandir> in case anybody has tested one of the older ones.
<heno> Mithrandir: ok, only server test results for i386 so far by fabio
<siretart> Mithrandir: will investigate and attach a diff. from my experience, the changes are moderately. no new features, mainly bugfixes, new development starts in the 0.6 branch
<cjwatson> fabbione: added for my next d-i upload
<cjwatson> unfortunately bumps image sizes by 300K or so, but ...
<Mithrandir> siretart: ok, I won't give you ack/nack before I see the diff, but it sounds promising
<siretart> ok
<fabbione> cjwatson: ok thanks, but as i said it's not fatal, so up to you if you want to bloat or not. I am ok either way
<\sh>  how do you kill a sles9? do an update and kill passwd/shadow
<heno> the new kernel seems to have fixed bug 94301 as well
<Ubugtu> Malone bug 94301 in control-center "Feisty i386 DesktopCD does not boot on slower machine (g-s-t race condition?)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94301
<heno> fabbione: your recent test of Ubuntu desktop, do you remember what install type that was (erase disk, etc.)?
<fabbione> it was a clean disk.. so use full disk
<fabbione> nothing was there.. not even a partition table
<dholbach> good morning
<fabbione> heno: i think i have completed Ubuntu sparc server.. mind to check if we need more install tests?
<fabbione> heno: otherwise i will keep going on i386
<JonRob> can anyone in here give some advice about the livecd?
<heno> fabbione: you posted under i386 desktop but I guess it should have been under server, because the default test there is not reported
<heno> If that's the case I can just adjust it
<fabbione> heno: i don't understand what you mean
<fabbione> i only added one entry to i386 desktop
<heno> right, I was wondering if that was meant to go under server, nevermind
<heno> fabbione: but my first question was, what install test did you use?
<heno> erase disk, manual partitioning, etc?
<fabbione> <fabbione> it was a clean disk.. so use full disk
<fabbione> <fabbione> nothing was there.. not even a partition table
<fabbione> heno: ^^
<fabbione> and i did answer immediatly after :)
<heno> ok, thanks, by bad
<fabbione> no problem :)
<fabbione> heno: i can add that.. just gimme a sec
<fabbione> done
<fabbione> heno: i would be glad if you want me to test more cases on sparc.
<heno> I'm marking the results here https://wiki.ubuntu.com/Testing/Status (in pretty colours)
<fabbione> heno: i think i covered pretty much all
<heno> I think it's covered, yes
<fabbione> ok perfect
<Mithrandir> heno: that page looks like a great overview.
<heno> Mithrandir: cool. One test failure though, on alternate
<doko_> hmm, what was the ftp host for security uploads?
<Mithrandir> heno: yeah, looks like it.
<Mithrandir> cjwatson: bug 94647; do you have any idea of the cause?
<Ubugtu> Malone bug 94647 in partman "Resize operation failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94647
<tepsipakki> I just did my first ubiquity-install, and it worked like a charm :)
<tepsipakki> on a Lenovo TC M55
<cjwatson> Mithrandir: not yet
<hunger> BenC: My kernel oops is fixed with your new version. Just to add another confirmation;-)
<heno> bug 84964
<Ubugtu> Malone bug 84964 in linux-source-2.6.20 "modprobe abnormal exit - Kernel 2.6.20-8/9/10/11/12 does not boot" [Critical,Confirmed]  https://launchpad.net/bugs/84964
<heno> A boot failure on ICH8 still being reported on 12-20
<Fujitsu> heno: Sounds like fun :-/
<cjwatson> Mithrandir: can't seem to reproduce it here
<heno> 2.6.20-12.20 that is
<hunger> heno: -9 worked for me all the time, -12 did have that bug here yesterday, but today's update works-for-me(TM)
<heno> hunger: and what chip set do you have?
<hunger> heno: ICH6.
<heno> the ISO report is bug 93121
<Ubugtu> Malone bug 93121 in ubuntu-iso-tests "beta: Ubuntu amd64 desktop" [Undecided,In progress]  https://launchpad.net/bugs/93121
<hunger> heno: So it is probably something different:-|
<heno> hunger: right, so it seems ICH6 and ICH7 have been fixed, but not ICH8
* hunger comforts heno. BenC will work his magic.
<hunger> heno: I am surprised that it ICH8 stayed broken for so long.
<heno> but he's not up yet, looking for some other kernel devs
<cjwatson> pkl should be around soon
<heno> yep
<tepsipakki> heno: the Lenovo I just installed has ICH8
<tepsipakki> and it works
<tepsipakki> but that was i386
<Mithrandir> tepsipakki: was it SATA or PATA?
<tepsipakki> SATA
<Mithrandir> ok
<cjwatson> fabbione: so can you reproduce 94647 at will?
<cjwatson> fabbione: before selecting the auto-resize option in the partitioner, could you edit /lib/partman/automatically_partition/10resize_use_free/do_option and put 'set -x' near the top? then get me /var/log/syslog after it fails and you've gone back to the menu
<tepsipakki> cjwatson: /bin/preseed_fetch: 16: protocol_fetch: not found
<tepsipakki> netboot
<tepsipakki> oh
<tepsipakki> maybe an error on my conf
<fabbione> cjwatson: yes i was able to reproduce it without problems. I will just complete this test install and I will do
<tepsipakki> cjwatson: /lib/preseed/fetch-methods/http is empty, file is the only one with content ("protocol_fetch()")
<cjwatson> tepsipakki: err, bizarre, it isn't empty in the udeb
<tepsipakki> hum, I'll check again
<cjwatson> tepsipakki: looks fine in the ubuntu17 initrd
<cjwatson> haven't checked 18, don't have that locally yet
<tepsipakki> bizarre indeed..
<fabbione> cjwatson: gahhhh it doesn't offer me to resize now....
* fabbione sighs
<fabbione> ah never mind.. i know why
* fabbione reinstalls once again
<JonRob> hi, i'm not sure if this is the right place to ask so if not could you point me in the right direction: is there a max size for /etc/skel on the livecd?
<Mithrandir> JonRob: no
<JonRob> Mithrandir: thanks, would you have any suggestion what would cause the error initramfs jobcontrol turned off when i boot it after adding apporx 1.4gb to /etc/skel?
<Mithrandir> JonRob: uh, you have an initramfs which is that big?
<JonRob> no not an initramfs - i put in /etc/skel to be moved to the home directory
<JonRob> like the example media already there
<Mithrandir> does your machine have more than 3GB of memory?
<JonRob> ram!? no
<Mithrandir> how are you going to have space to copy 1.4GB around when you add the user, then?
<JonRob> smeg, not something i'd thoguht through!
<JonRob> so you think that's likely to be the problem
<Mithrandir> yes
<cjwatson> Mithrandir: initramfs jobcontrol turned off> that means it couldn't figure out how to mount the root filesystem and dropped you to a prompt
<cjwatson> generally
<cjwatson> er
<cjwatson> JonRob: ^--
<cjwatson> Mithrandir knows this already ;-)
<Mithrandir> you can look in casper.log in the initramfs, but I would think you would be better off with just a symlink and not an actual copy of the files.
<JonRob> ok...but if i symlink to the files on the root direcotry of the disc, say, would that work on all systems?! what happens if there disc is in a differently labled disc?
<JonRob> their*
<Mithrandir> hm, pressing and letting go of ctrl in konqueror is very useful.  Firefox should grow something like that.
<cjwatson> fabbione: any luck?
<fabbione> cjwatson: i did the test install with LVM.. so i am reinstalling normal to get to the resize option
<fabbione> vmware isn't particularly fast on this machine..
<fabbione> cjwatson: i just ordered 4GB of ram for this machine.. from next week it will be a tad bit faster
<cjwatson> hmm, I was trying with just one partition there - I'll try install-then-install
<Hobbsee> Mithrandir: why, whta's it do?
<Hobbsee> oh, i see.  press and hold
<Mithrandir> shows you the accellerator keys for all the links on the page.
<Treenaks> sounds useful
<Hobbsee> yep
<heno> ok I get the 94647 bug too on alternate i386
<heno> that's trying to resize an ext3 that we just created with a previous desktop install though
<heno> (which I've read elsewhere is known not to work)
<heno> cjwatson: ^
<heno> any point trying it on a FAT32 disk?
<cjwatson> I would like to know whether it affects NTFS
<cjwatson> known not to work> what do you mean? until mdz filed that bug I thought it should work
<cjwatson> oh, you're referring to the resize_inode problem; that's meant to be fixed
<fabbione> cjwatson: ok.. got it to fail.. grabbing the syslog
<cjwatson> cool, it'll be about 15 minutes before I get there
<heno> cjwatson: I think I've see you write in a ubiquity bug report or somewhere that autoresizing newly created ext3 partitions doesn't work
<fabbione> cjwatson: both partman and syslog attached to the bug
<cjwatson> heno: old
<cjwatson> heno: that's what I believed I'd fixed earlier this week; the bugs we're currently seeing are likely fallout from that fix
<ogra> mvo, i think i have the cause for my fsck ... my bios clock isnt set to gmt but the fs creation happens before setting the clock, the timestamp on the created filesysstem is in the future
<cjwatson> ah, resize2fs is complaining that we didn't run e2fsck -f first
<cjwatson> was the partition cleanly unmounted?
<fabbione> cjwatson: yes.
<fabbione> i did a reboot
<fabbione> normal reboot
<fabbione> cjwatson: for my experience i have seen resize2fs fail that way even immediatly after an e2fsck.. i suggest you force e2fsck -f like one or two time before running resizee2fs
<heno> hm, just tried it with an empty ntfs disk and didn't get a resize option
<fabbione> cjwatson: but that will slow down stuff on big fat disks
<fabbione> anyway.. food time
<cjwatson> twice is superstition, only once is required
<cjwatson> but yes, looks like that's necessary
<cjwatson> heno: I can check why given /var/log/partman
<cjwatson> Mithrandir: comment in 94647 with workaround for at least Fabio's problem
<heno> cjwatson: it's just a 3gb disk, should that offer me a resize?
<cjwatson> heno: I can check why given /var/log/partman
<cjwatson> I don't think it's an effective use of time to speculate
<heno> cjwatson: ok, I'll have to complete the install to get that
<cjwatson> why?
<cjwatson> 'anna-install openssh-client-udeb' and scp it out
<heno> the basic shell is very heno-unfriendly
<cjwatson> ah, point
<heno> cand to things like > or | 
<cjwatson> there's the "save debug logs" option on the main menu - is that any better?
<heno> can't
<cjwatson> allows it to bring up a web server that you can browse from another machine
<heno> I can, but I'd still need bash or gnome to get it out
<heno> it's on virtualbox
<cjwatson> oh, no networking from the host box?
<heno> if I complete the install it will keep the right /var/log/partman
<heno> ?
<mvo> ogra: thanks, that makes sense
<cjwatson> ok, 3gb is too small
<heno> cjwatson: there is networking, yes
<cjwatson> (went and checked)
<cjwatson> elif longint_le "$(expr 3 \* 1024 \* 1024 \* 1024)" $bestfree; then log "Found resizable partition '$bestpart' ($bestpath) with $bestfree bytes free"
<cjwatson> ...
<cjwatson> else
<cjwatson>     log "Found resizable partition '$bestpart' ($bestpath), but not offering because only $bestfree bytes free"
<heno> ok, fine I'll use an 8gb one with some stuff in it
<cjwatson> need at least 3gb free in the resizable filesystem
<cjwatson> other requirements: fewer than 4 primary partitions; if there's an extended partition, fewer than 3 primary partitions; if there's an extended partition, resizable partition has to be adjacent to it so that we can create logical partitions sufficiently freely; must be <2GB free on the disk already (that number needs to be updated, or that check removed, IMO)
<cjwatson> sorry, 2.2GB
<heno> ok, I'll just start with a clean 8gb ntfs disk
* cjwatson removes the 2.2GB check
<ogra_> hmm, intresting ... i cant paste to any pastebin from the beta firefox ... it always wants to open the index.php file with gedit after hitting submit ...
<ogra_> asac ^^
<ogra_> no matter if i use paste.ubuntu-nl.org, th eltsp pastebot or pastebin.ca
<ogra_> does anyone else see that ?
<pitti_live> hi
<heno> cjwatson: on the 8gb ntfs drive is resizes and installs fine
<heno> *it resizes
<pitti_live> wow, this migration tool actually shows stuff
<pitti_live> cjwatson: who should I contact about weirdnesses in that migration tool?
* Fujitsu wonders about the interaction between migration-assistant and the account creation stuff. It's rather confusing at the moment.
<ogra_> mvo: http://www.grawert.net/tune2fs_right_after_fs_creation.txt and http://www.grawert.net/tune2fs_after_reboot.txt 
<pitti_live> Fujitsu: I just wondered why it can import gaim from both breezy and feisty, but evolution only from breezy
<ogra_> mvo: Filesystem created is in the future in the rebooted one
<Fujitsu> It worked really nicely on a work machine, except for confusion resulting from the duplicate account creation question.
<Fujitsu> ogra_: I had the same on a new Feisty install last week...
<ogra_> Fujitsu: your hwclock isnt set to gmt ?
<Fujitsu> ogra_: It's not this machine, but it was previously Windows-only, so no.
<ogra_> right, then thats the reason ... the clock setting should move in front of partitioning then
<Fujitsu> Probably.
<Fujitsu> A little bad to have a forced fsck on the first boot.
<ogra_> yes
<ogra_> looks a bit scary
<Fujitsu> Yep.
<ogra_> cjwatson: ^^ can we do that ?
<Crescendo_> Suggestion for Ubuntu Developers: When there are updates to the system, it needs to be super easy to click and find out more about the updates (changelog)
<StevenK> Crescendo_: ... It is
<Crescendo_> Maybe I missed something then. :P
<StevenK> Crescendo_: I'd suggest you ask in #ubuntu
<Crescendo_> <censored> Crescendo, #ubuntu-dev for suggestions to devs
<Fujitsu> Crescendo_: Note the Changelog tab in the updater.
<cjwatson> pitti_live: evand
<cjwatson> heno: great
<cjwatson> ogra_: no, we can't
<StevenK> It's already implemented, and has been since Dapper, so #ubuntu to find out how, surely?
<pitti_live> cjwatson: thanks
<cjwatson> ogra_: clock-setup relies on the output of partitioning to set a suitable default
<pitti_live> evand: hello
<Mithrandir> heno: are you lagging updating Testing/Status or is testing just taking time?
<Crescendo_> StevenK, nah - I just completely missed the feature.  I was running updates this morning, and didn't see it.  My bad!
<ogra_> cjwatson: hmm, can we touch the timestamps of the fs then ? 
<cjwatson> ogra_: possibly. I'd like to think about it a bit
<Fujitsu> ogra_: That looks to be the best idea... We can't exactly have each install fscking first.
<heno> Mithrandir: I'm just updating it in batches. will do one now
<cjwatson> Fujitsu: like I say, I'd like to think about it rather than diving in
<Fujitsu> cjwatson: Saw that right after I sent my message. Of course, it's a good idea to not just jump into it.
<heno> Mithrandir: I get all the notices by email and update from here
<StevenK> Fujitsu: It probably won't be every install
<StevenK> Fujitsu: But you have a point.
<Crescendo_> Something needs to be done about having windows pop up over the keyring password entry - especially when the default button is cancel or close, or the ONLY button is close
<ogra_> Fujitsu: well, not each install, only the ones where the bios doesnt use gmt :)
<Fujitsu> ogra_: Isn't that everything that runs Windows?
<pitti_live> heno: is that wiki page autogenerated from the Malone bugs? cool
<Crescendo_> Default buttons in general are not nice, and if they pop up while I'm typing...
<Hobbsee> Crescendo_: --> wishlist on the bugtracker.
<heno> pitti_live: that was the original plan, but ATM it's heno-powered
<ogra_> Fujitsu: most of them, yes
<pitti_live> heno: ah; do you know about editmoin? it's an incredibly rocking tool for editing wiki pages
<cjwatson> Crescendo_: focus stealing *is* considered a bug
<cjwatson> by GNOME as well as us, generally
<Crescendo_> cjwatson, okay - I'll file it as such in the future, thanks
<StevenK> I usually just sigh, and deal with it. Maybe I should file bugs.
<cjwatson> ogra_: and that's exactly why clock-setup needs to go after partman - detecting whether you're planning to make it a Linux-only machine or not
<ogra_> yep
<cjwatson> problem with fiddling it after the fact is that you'd need an implementation of said timestamp-fiddler for every fs
<ogra_> i understand ... 
* pitti_live reboots into installed system, brb
<cjwatson> actually I don't think it would make any difference where you put it anyway. clock-setup only asks a question and prods files in the target filesystem for later - it doesn't actually touch the clock itself
<cjwatson> so it might as well go later in order to have maximal information
* siretart feels some "if in doubt, it's always xine-lib's fault for crashing totem..." attitude from seb128 while looking at bug #94154
<Ubugtu> Malone bug 94154 in xine-lib "[apport]  totem-video-thumbnailer crashed with SIGSEGV in _int_malloc()" [Medium,Unconfirmed]  https://launchpad.net/bugs/94154
<siretart> ;)
<seb128> siretart: no
<seb128> ==978== Invalid read of size 4
<seb128> ==978==    at 0x113AC6AE: (within /usr/lib/xine/plugins/1.1.4/xineplug_decode_ff.so)
<seb128> ==978==    by 0x112B8D07: (within /usr/lib/xine/plugins/1.1.4/xineplug_decode_ff.so)
<seb128> ==978==    by 0x112B9D58: (within /usr/lib/xine/plugins/1.1.4/xineplug_decode_ff.so)
<seb128> ...
<cjwatson> maybe it would be sufficient to actually adjust the clock in clock-setup
<seb128> siretart: ^
<seb128> siretart: that's likely the corruption
<siretart> seb128: it looks to me like some bug in the included ffmpeg copy
<siretart> seb128: in fact, I have an updated ffmpeg ready, and could link xine against that
<siretart> seb128: but mithrandir would kill me if I uploaded that one. ;)
<seb128> siretart: yeah, likely, still the problem is to xine not totem ;)
<siretart> seb128: I plan to switch back to external ffmpeg for goofy, as soon as it opens
<seb128> cool
<siretart> seb128: I *think* the problem will go away. in any case, the bug is no longer against xine
<seb128> why not?
<seb128> /usr/lib/xine/plugins/1.1.4/xineplug_decode_ff.so is shipped with xine-lib no?
<siretart> because xine will use then the external ffmpeg,
<seb128> ah
<seb128> yeah, it'll not be when you stop using the copy
<seb128> it still is atm
<siretart> currently, feisty's ffmpeg package is dated from august, xine's copy is from november I think
<siretart> the new package is the codebase from march
<siretart> so I cannot really update the ffmpeg package
<siretart> and I don't really feel like updating the xine-lib included ffmpeg copy, you know...
<heno> asac, dholbach, Riddell, kwwii, pkl, ogra, doko: any progress on testing today's images? See status on https://wiki.ubuntu.com/Testing/Status (still lots of red fields)
<pkl_> heno: downloaded Tuesdays, didn't manage to test.  Currently downloading today's build...
<heno> pkl_: cool, thanks
<Riddell> heno: how does that page get filled in?  you do it manually from the bug reports?
<heno> Riddell: I do yes
<Riddell> heno: pass added to bug 93114, desktop CDs just finished downloading
<Ubugtu> Malone bug 93114 in ubuntu-iso-tests "beta: Kubuntu i386 alternate" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93114
<heno> Riddell: thanks
<pitti> heno: in case you are still editing, bug 93121 is now complete as well
<Ubugtu> Malone bug 93121 in ubuntu-iso-tests "beta: Ubuntu amd64 desktop" [Undecided,In progress]  https://launchpad.net/bugs/93121
<heno> ok
<Mithrandir> kylem: I realise you just got in, I assume you haven't had a chance at testing the alternate CD yet?
<pitti> Mithrandir, kylem: I can give a hand with testing amd64/alternate if you want me
<Mithrandir> pitti: if you're not busy with your two remaining -desktop tests, then please.
<pitti> Mithrandir: I finished those half an hour ago, I am currently looking into the r-m failure on a fresh install (config.dat is 0600); but I can tackle this later
<pitti> kylem: I grab check, erase, auto-resize for now then
<Mithrandir> pitti: thanks a lot.
<asac> heno: will try a minimal run later ... as i am not here today officially :)
<heno> asac: it's ok pitti has covered those cases now
<Mithrandir> cjwatson: how is your amd64 dvd testing going?  Do you need help with it?
<pitti> kylem: grabbing check as well, because I need it to prepare auto-resize anyway
<heno> Mithrandir: I'm just burning cjwatson's DVD now
<pitti> kylem: erm, rescue, I mean
<Mithrandir> heno: as in, you're grabbing the test case?
<heno> Mithrandir: yes
<heno> (or send it to him in the post, whichever is quicker)
<heno> Mithrandir: I've got the i386 DVD going in a VM now as well
<Mithrandir> ok
<Mithrandir> ogra: haven't you managed to test a single image today?
<Riddell> bdmurray: when you testing i386 alternate did it ask you for the screen resolution for X?
<heno> mvo: what's the status of upgrade testing? can the results from yesterday be carried over? (note that we have a new kernel)
<pitti> heno: no CLI test on alternates?
<mvo> heno: I will do a re-test then
<heno> pitti: I didn't add it to the list no. It would probably be good to do some though
<ogra> Mithrandir, i386 server and addon are good, amd64 is running
<Mithrandir> ogra: can you please update the bug statuses, then?
<TomaszD> pitti, /usr/share/applications/restricted-manager.desktop code only has German translation in place, I'm using the latest langpack
<TomaszD> pitti, and /usr/share/app-install/desktop/restricted-manager.desktop doesn't even have a German comment field, only the name.
<pitti> TomaszD: /usr/share/applications/restricted-manager.desktop is what counts
<pitti> TomaszD: indeed this has a German translations
<TomaszD> pitti, alright, so that only has the German translation, nothing else
<pitti> TomaszD: aaaah
<pitti> TomaszD: please edit that file and add the line:
<pitti> TomaszD: X-Ubuntu-Gettext-Domain: restricted-manager
<pitti> TomaszD: that should help
<siretart> pitti: what is this X-Ubuntu-Gettext-Domain field for?
<pitti> siretart: it tells the desktop file which .mo file to use for translations
<TomaszD> pitti, you mean X-Ubuntu-Gettext-Domain=restricted-manager
<TomaszD> it works wonderfully now
<TomaszD> :D
<pitti> TomaszD: right
<pitti> TomaszD: splendid; can you please file a bug about this?
<TomaszD> pitti, shall I file a bug report or will you not forget about this?
<TomaszD> hah, ok
<pitti> TomaszD: :)
<TomaszD> duh, I always get lost in lp
<ogra> Mithrandir, as soon as i'm donw and back on my normal machine 
<dholbach> who takes care of vbetool?
<Mithrandir> dholbach: depends
<dholbach> it crashes quite often for people
<TomaszD> pitti, there https://bugs.launchpad.net/restricted-manager/+bug/94754
<Ubugtu> Malone bug 94754 in restricted-manager "restricted-manager.desktop needs X-Ubuntu-Gettext-Domain property" [Undecided,Unconfirmed]  
<pitti> TomaszD: thank you
<dholbach> is there a new upstream version or something?
<TomaszD> np
<AlinuxOS> Hello developers, on my PC, kernels: vmlinuz-2.6.20-8-generic, vmlinuz-2.6.20-9-generic, vmlinuz-2.6.20-10-generic, vmlinuz-2.6.20-11-generic, vmlinuz-2.6.20-12-generic are not able to boot. The unic kernel that works is: vmlinuz-2.6.20-6-generic. What's wrong? My system hangs up at the begining of boot.
<stgraber> bug 84964 ?
<Ubugtu> Malone bug 84964 in linux-source-2.6.20 "modprobe abnormal exit - Kernel 2.6.20-8/9/10/11/12 does not boot" [Critical,Confirmed]  https://launchpad.net/bugs/84964
<stgraber> AlinuxOS: can you do a "lspci" and check if you have something like : ICH8 Family
<BenC> Anyone here experiencing bug #84964?
<Ubugtu> Malone bug 84964 in linux-source-2.6.20 "modprobe abnormal exit - Kernel 2.6.20-8/9/10/11/12 does not boot" [Critical,Confirmed]  https://launchpad.net/bugs/84964
<stgraber> BenC: AlinuxOS may have it or at least has the same symptoms
<AlinuxOS> yes I confirm that bug too.
<stgraber> BenC: everything >-6 doesn't work
<AlinuxOS> for me it's the same.
<BenC> AlinuxOS: Can you join #ubuntu-kernel to discuss this?
<Mithrandir> Riddell: how is your testing going?
<Lutin> BenC: hum, yep, experiencing here too
<BenC> Lutin: Could you join #ubuntu-kernel as well then, if you have maybe 15-30 minutes to do some Q&A?
<BenC> Lutin: Are you sure your problem isn't the bug that showed up in -12 and was fixed yesterday?
<cjwatson> Mithrandir: mail in your inbox with a workaround for that resizing bug. I've tested my patch successfully, and it's your call, but I think it would be best applied after beta rather than before
<cjwatson> since in this case the workarround is fairly straightforward
<Lutin> BenC: I was experiencin the same with -9
<Mithrandir> cjwatson: thanks.  Can you add that to the release announcement?
<cjwatson> Mithrandir: where?
<Mithrandir> cjwatson: https://wiki.ubuntu.com/FeistyBetaAnnouncement
<heno> Keybuk, doko: Any luck we Edubuntu testing? https://wiki.ubuntu.com/Testing/Status
<Keybuk> heno: I haven't even begun any
<heno> Keybuk: can you do Edubuntu alternate?
<Keybuk> heno: I'm not going to be able to today, I have a stack of CVs and interviews to do
<heno> the interns Chris and Mike are not at work today
<Keybuk> (so I kinda need this machine <g>)
<heno> Keybuk: ok, thanks, let me find a different home for it
<Riddell> Mithrandir: i386 both good, onto amd64 now
<bddebian> Heya
<heno> Riddell: will update, thanks -- is that all tests?
<heno> kylem: around?
<Riddell> heno: no, only done manual for kubuntu i386 alternate and desktop
<Riddell> heno: although wipe disk for i386 alternate is half way there
<heno> ok, thx
<ogra> heno, i'm done with edubuntu alternate 
<heno> ogra: can I sign off all the tests? i386 and amd64?
<ogra> just got a grub prompt on amd64, need to find out why, apart from that it looks ok ...
<ogra> i386 is good, i'll update the bugs as soon as i have a sane machine in my fingers again
<heno> ogra: I can do it directly, if you can just confirm that I should OK all the test types (erase, manual, rescue, etc.)
<ogra> erase manual and rescue as well as selftest were fine for i386 
<ogra> manual had a grub prompt for the installation device ... but was fine apart from that. i didnt perform selftest and rescue yet for amd64
<ogra> s/manual/manual amd64/
<amayera> hi
<amayera> I wanted to ask if it is planned for usplash to support cryptsetup so one can enter his dmcrypt passphrase while still seeing the nice uslpash screen and not the console?
<cjwatson> ogra: you'll get a grub prompt if another OS is installed that grub-installer can't figure out how to boot
<ogra> cjwatson, well, there is my other ubuntu on hda1  ....
<ogra> nothing else
<carlos> glatzor: pint
<carlos> glatzor: ping
<glatzor> carlos: pong
<carlos> glatzor: just saw your email to ubuntu-translators
<carlos> glatzor: you don't need to do that
<carlos> either provide me with fixed .pot files and I will do a manual upload
<carlos> or ask us (Rosetta team) to hide those templates to prevent people working on it
<carlos> it's safer
<glatzor> carlos: ok. that is true.
<glatzor> carlos: the new packages are already in the upload queue.
<carlos> of course, the announcement should be sent anyway
<carlos> glatzor: will they be automatically built?
<glatzor> carlos: so could you hide python-apt and software-properties until the end of the beta freeze?
<carlos> sure
<carlos> glatzor: please, remind me to enable them again once the packages are built
<glatzor> carlos: the pot file and the po files get updated during the build process but I updated them locally in the source repository too. 
<carlos> but Rosetta doesn't get them until the build is finished
<glatzor> carlos: right.  that is why I wrote this mail :)
<carlos> glatzor: is update-manager affected by that problem too?
<glatzor> carlos: good question. I will check this now. I just finished python-apt and software-properties
<carlos> ok
<carlos> glatzor: python-apt and software-properties are hidden now.
<glatzor> thanks a lot carlos
<carlos> np
<sladen> amayera: I think there maybe a bug open for that;  if there isn't, can you open one please
<bdmurray> Riddell: yes, I recall that in one of the tests
<heno> good morning bdmurray :)
<amayera> sladen: this should go to usplash-bugs, right?
<iwj> heno: Just to check I'm not missing anything here, there aren't yet any new images to test, right ?
<sladen> amayera: cryptsetup might be a better place
<sladen> amayera: if it's non-functional, that's a bug and needs filing
<heno> iwj: the latest were rolled at 1.00ish GMT last night
<amayera> sladen: well it works, but usplash stops running as soon as you need to enter the passphrase.
<pitti> kylem: amd64/alternate update: I now did everything except OEM and expert
<heno> iwj: https://wiki.ubuntu.com/Testing/Status the community I and fabio have been testing ubuntu desktop 386
<amayera_> sladen: well it works, but usplash stops running as soon as you need to enter the passphrase.
<heno> but there is one remaining test, auto-resize
<Riddell> bdmurray: seems like a bug then
<Riddell> heno: any reports of ubuntu alternate asking for X screen resolution during install?
<heno> Riddell: no, just yours
<heno> Riddell: that would not be speciffic to Kubuntu I guess
<heno> I've not seen it myself on Ubuntu alternates
<iwj> I'm sure I looked in Testing/Status.
<heno> pitti: thanks, I'll update
<iwj> Yes, indeed, look there are no version numbers in that page!
<pitti> heno: well, cli and manual partitioning are still running
<iwj> heno: Would you like me to take the dvd instead ?
<pitti> heno: I can do the last two ones, too, if its urgent
<bdmurray> Riddell: which install did you see it in?
<pitti> heno: but I'd rather prefer someone else do them, to cover different hardware
<iwj> At least one of livecd or d-i.
<Riddell> bdmurray: i386 alternate (but not amd64)
<heno> iwj: I'm on the Ubuntu DVD myself. Could you look at the Edubuntu DVD?
<iwj> Err, OK.  Let me see what my download looks like if I ask for it.
<bdmurray> Riddell: I don't recall it in every install method of the alternate
<iwj> heno: What version number ?
<Riddell> bdmurray: I did manual
<heno> iwj: 20070322
<heno> for the dvd
<Riddell> bdmurray: can't imagine the partioning type would affect it
<iwj> heno: Please put that in the wiki page.
<iwj> heno: This getting the version number via irc is absurd.
<Riddell> heno: a virtual box alternate install gets stuck at ejecting the CD, is that known?
<bdmurray> Yeah, probably not.
<heno> iwj: perhaps you can help me with that? That would be useful :)
<iwj> Sure :-).
<heno> thanks, (as you were volunteering your efforts anyway)
<iwj> Testing/ReportingResults promises the version numbers will be in the tracker bug titles but they're not.
<iwj> I don't know what all of the version numbers ought to be for all of the other images.
<heno> iwj: it's whatever is in current 20070322.x
<heno> where x is 1 or two for desktop (they are identical)
<heno> and nothing for DVD
<heno> bdmurray: can you give a hand with Edubuntu or Kubuntu testing? still some blank tests there
<bdmurray> heno: I'm getting the edubuntu server image now
<bdmurray> And I was going to start expert i386 alternate soon
<heno> bdmurray: cool thanks. can you coordinate with ogra? he's doing some as well
<bdmurray> heno: are my alternates from yesterday valid?
<ogra> heno, i'm doing the desktop run now ...
<Mithrandir> bdmurray: no.
<iwj> heno: Quoted you in the wiki :-).
<heno> iwj: great, thanks for your help
<mdz> cjwatson: documenting the resize issue seems appropriate to me
<iwj> heno: It looks like my dvd seed is a bit out of date so I'm downloading the jigdo template instead.  This will be some hours at this rate.
<iwj> Is cdimage.ubuntu.com very overloaded atm ?
<heno> iwj: I'm wondering if it's worth it. My Edubuntu DVD sync is just about to complete
<mdz> Mithrandir: 20070322.1 still stands as a candidate for Ubuntu?
<heno> iwj: anything else on that page you could test, Ubuntu i386 alternate?
<pirast> keescook, could you approve the nominations in bug 94792?
<Ubugtu> Malone bug 94792 in asterisk "Asterisk 1.2.17 fixes SIP DoS vulnerability" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94792
<pirast> thanks
<iwj> heno: Sure, updating my image now.
<superm1> BenC, I noticed that you marked the bug related to saa7127 missing in 2.6.20 as fix-committed.  do you know which kernel release this will be reflected? (I'm going to add a note to the wiki page for ivtv feisty)
<iwj> jigdo's mkimage should have a --best-effort option for when you're just trying to prime your rsync.
<mdz> cjwatson: I'm surprised that the resize ever worked if it didn't force a fsck; I always seem to need to do that before resizing ext3
<pitti> ogra, slomo: btw, I just tried the bcm43xx-mac80211 driver with the 4.x firmware; it works at least; I didn't try WPA though, I don't have one of those here
<BenC> superm1: -13, which will probably get uploaded Saturday
<superm1> Ok.  thanks :)
<pitti> heno: btw, I did test auto-resize, but not OEM for amd64/alternate; this is mixed up on TEsting/Status
<dholbach> cjwatson: should we merge in the debconf change of debian bug 413509? it would fix our bug 87641 - which has 34 dups now :-)
<Ubugtu> Debian bug 413509 in x11-common "x11-common: config script hangs or fails" [Serious,Closed]  http://bugs.debian.org/413509
<Ubugtu> Malone bug 87641 in libqt-perl "[apport]  dpkg-preconfigure crashed with SIGSEGV in xcall_QGroupBox()" [Undecided,Confirmed]  https://launchpad.net/bugs/87641
<seb128> there is a zillion of dup of that bug
<seb128> I've already closed a bunch like a week ago
<dholbach> 34 now :)
<dholbach> i added a clue about both debconf and libqt-perl to bughelper
<seb128> ok
<pitti> dholbach: a bug pattern as well, perhaps?
<seb128> is there a way to say to debhelper "run all the known clue"?
<heno> pitti: thanks, will fix
<dholbach> seb128: i want to let that run on rookery with a cronjob and generate html reports
<dholbach> seb128: (and have some config file for that script, so you can easily add bug* jobs to it)
* Starting logfile irclogs/ubuntu-devel.log
<cjwatson> dholbach: ok, I'll look later today, thanks
<dholbach> seb128: 1) reorganisation of the launchpad specific code (like make it easier, deal with attachments better, make it saner, etc), 2) work on that data center version of it, 3) work on gtk bits for it
<dholbach> cjwatson: super
<seb128> dholbach: cool ;)
<dholbach> seb128: glad you like it
<ogra> heno, x86 edubuntu live: manual, erase and live_session are good
<evand> pitti: sorry, I was out earlier.  Is .gconf/apps/evolution/mail/%gconf.xml present on both systems?
<heno> ogra: thanks. will update
<pitti> evand: well, in Feisty I only have the monolithic ~/.gconf/%gconf-tree.xml
<pitti> evand: that one does have some evolution keys
<_ion> I wonder whether something like SQLite would be a better database for gconf.
<_ion> It would have indexing etc.
<_ion> Of course gconfd caches stuff, but anyway...
<evand> pitti: interesting, any idea how the monolithic tree gets created?  I'm running Feisty as well and I have the keys broken down by directory.
<evand> But that would definitely explain why it isn't finding Evo
<pitti> evand: I think dapper or edgy created them
* evand investigates
<pitti> evand: we originally had the flat files, then a later distro compressed them into one file, and then this was reverted (seb128 should know more)
<evand> pitti: ok thanks
<pitti> evand: so you don't actually use the gconf library, but parse the stuff manually?
<evand> pitti: yeah, it makes the deps smaller
<pitti> evand: I can send you my gconf tree after some cleanup
<evand> as this should also work in d-i on the alternate cd, but isn't included
<evand> pitti: that would be a great help
<seb128> evand, pitti: waht is the question?
<pitti> evand: anyway, it's just a corner case anyway
<pitti> evand: most people will probably want to import from Windows, not from Linux (sharing /home is so much easier...)
<evand> seb128: what conditions create %gconf-tree.xml.  That is, was there a specific version of Ubuntu that created this?
<pitti> seb128: when did we switch to monolithic .gconf/%gconf-tree.xml and when back?
<pitti> seb128: I still have the monolithic one
<evand> Gotta run, will follow up later
<seb128> we merged the the gconf database during the breezy cycle
<seb128> just during the unstable cycle
<pitti> seb128: oh, it has never been in a release?
<seb128> we undo that change because it's not working fine on NFS due to the locking
<seb128> pitti: no
<seb128> pitti: we do merge the system one
<pitti> seb128: so I better keep it around, if it speeds up my system ;-P
<seb128> yeah ;)
<_ion> pitti: We probably should contact nVidia. Perhaps they would share a complete list of IDs supported by each version of the driver.
<keescook> mornin'
<keescook> pirast: sure, done.  thanks!
<pitti> _ion: and put it online somewhere, right; or just fix that damn module to declare it
<pitti> hi keescook 
<keescook> hiya pitti
<_ion> pitti: Yeah
<stdin> what would be your thoughts on adding something about the root account being disabled and use of sudo on the installer? I see soooo many questions in forums about "why can't I log in as root" and "what's the default root password"
<ogra_live> heno: edubunu amd64 live erase, manual and live session good as well :)
<ogra_live> seems i got a complete set :)
<heno> ogra_live: cool! 
<ogra_live> (apart from the dvd which might still take until tomorrow to finish the rsync)
<heno> ogra_live: what babout DVDs? I have the i386 one downloaded
<heno> amd64 will take me another 7 hours
<ogra_live> my rsync says something about 10h for amd64 :(
<ogra_live> silly big media :/
<heno> have you done i386? If not, I'm on that one
<ogra_live> ok
<evand> pitti: If you could scrape out any sensitive data and send me that monolithic gconf file via email (evand@ubuntu.com) or a m-a bug report whenever you have a chance, it would be much appreciated.
<ogra_live> i'll do it as well but wont priorize it
<ogra_live> i.e. do it on friday afternoon or something, just to see how it goes
<pitti> evand: I could do that, but since it seems to be such a corner case, I don't think you should worry about it too much
<evand> ok
<pitti> evand: I could only come to this gconf situation because I always keep my /home partition; and in those cases people will certainly continue to do so ;)
<evand> ah
<pitti> evand: people who regenerate their /home with every new install won't have the monolithic tree, nor will people who only installed stable releases
<evand> ok
<pitti> evand: thanks for looking into it; I thought it was somehting much more serious
<heno> ogra_live: did you do auto-resize for the desktop CDs? I don't have that marked off
<evand> me too :)
<ogra_live> nope, i didnt
<ogra_live> i usually only do manual and erase ... 
<ogra_live> as i usually dont have anything to autoresize :)
<pitti> my current approach to this is to create a single large vfat partition, put a file onto it (in the live system), and then reboot
<heno> ogra_live: ah, well it seems stgraber has just done it :)
<ogra_live> heno: i'm extremly sure there wont be many differences between ubiquity on edubuntu vs ubuntu so i'd be fine if i know all the package stuff thats different in the installs is handled ...
<heno> right, makes sense
<ogra_live> indeed it's nicer to have them all tedsted :)
<aitor> im looking for some feedback
<aitor> I write an application for Summer of Code 2007 about synaptic
<aitor> the main idea is to add rating and comments to packages in synaptic
<mvo> aitor: hello! you write or you plan to write :) ?
<aitor> you can see my application in http://mysummerofcode.blogspot.com/2007/03/ubuntu-possibility-to-comment-and-rate.html
<mvo> aitor: that sounds very interessting, but it seems to me like a good approach is to make it webbased. is that what you plan to do?
<aitor> two ways
<TomaszD> any bluetooth experts around? what about this little showstopper https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/92866
<Ubugtu> Malone bug 92866 in bluez-utils "Inquring for devices from GUI doesn't work due to misconfiguration" [Undecided,Unconfirmed]  
<aitor> rate and comment in synaptic, sort by rate...
* mvo reads the blog entry
<aitor> setting up a store system that could be used to make a web based application 
<mvo> aitor: I need to lave for the evening in a bit, please mail me or just ping me on irc tomorrow again
<Keybuk> (random) the rhythmbox album cover plugin is the bong!
<pitti> Keybuk++
<Keybuk> I like it even better when it gets the wrong album cover, because it's usually funny
<heno> doko: did you get a chance to download the Edubuntu amd64 DVD?
<aitor> hi, sorry Im down
* heno takes a break from testing
<shawarma> pitti: How often does the malone retrace magic thing run?
<doko> heno: will do tonight; downloaded today
<pitti> shawarma: permanently ATM, dholbach gave it a huge bulk of stuff to do :)
<pitti> shawarma: if the queue is empty, it sleeps for ten minutes and then checks again
<shawarma> pitti: ah.. Is it triggered when we set the flag or does it just run every once in a while and checks if there's any bugs tagged with the magic tags?
<dholbach> heno: were the Testing/ tables wiped clean again?=
<pitti> shawarma: the latter; I don't see how the former is possible, and it wouldn't make much sense either (it needs to be queued anyway)
<_ion> pitti: Another, somewhat evil idea: a program that dlopens a proprietary driver and bruteforces the IDs it supports by pretending to be X and running the driver's Probe function in a for loop. I haven't studied whether that would work, though.
<shawarma> pitti: Well, it could be triggered by e-mail and be subscribed to ubuntu bugs.. but this works fine, too.
<pitti> shawarma: I guess after all a Malone search is cheaper than parsing that bug flood
<pitti> _ion: h4ck! ;)
<shawarma> pitti: Probably. :-)
<dholbach> heno: ah no... sorry - you want me to do server amd64?
<shawarma> pitti: Well, I just asked because there as a bug that was tagged 4-5 hours ago and I was curious if it had missed it, but if it's just that there's a backlog I'll take it easy.
<pitti> shawarma: if the tag is still there, everything is alright; if the tag was removed without a retrace, ping me to look in the logs
<shawarma> pitti: Nono, it's still there. I just have a very impatient nature. :-)
<pitti> understandable :)
<hunger> WLAN is broken since I upgraded my kernel:-(
<hunger> I am using the madwifi drivers.
<hunger> Works with the -9 kernel.
<hunger> Will somebody do something about all the warnings/error messages that appear during bootup?
<Mithrandir> mdz: .2 on i386, but yes.
<mdz> Mithrandir: which i386?  I was testing .1 and got no indication that anything  had changed
<\sh> guys, can someone have a look on bug #38311..is it ok, to recompile it without openssl support?
<Ubugtu> Malone bug 38311 in ekg "Please build libgadu without openssl support" [Wishlist,Confirmed]  https://launchpad.net/bugs/38311
<Mithrandir> mdz: all i386; you should have gotten notification via ubuntu-iso-tests bug subscription, surely?
<Riddell> slomo: your blog is broken?
<slomo> Riddell: yes... i'll fix it when i find some free time
<Riddell> cool
<mdz> Mithrandir: I'm not subscribed to ubuntu-iso-tests; only to the bug where I'm testing
<_ion> pitti: I have to investigate more, but there seems to be something that looks very much like an ID list immediately in the beginning of the .rodata section of the kernel module.
<mdz> Mithrandir: and furthermore, products can only have one bug contact, and I'm not one
<mdz> henrik is
<mdz> Mithrandir: have you talked this through with heno?
<pitti> gnomefreak: sorry that those tbird/ffox packages are so resistant against good traces :( do they have some particularly agressive compiler flags or so?
<pitti> gnomefreak: did you ever saw a 'good' retrace for ffox/tbird?
<gnomefreak> pitti: not sure asac would be better to ask
<pitti> ok
<gnomefreak> pitti: i got one that i did this morning but it was already done by hjmf it was great. most of the good ones are gtk_style_attach
<pitti> gnomefreak: high on apport's TODO list is evaluation of ProcMaps and installing the packages/dbgsyms that belong to them; that should help in some cases
<iwj> cjwatson: Err, this perfectly ordinary d-i install seems to have failed to install X and gdm and so forth.
<iwj> The only weird thing I did was select to mount the /home from another feisty test install on /home again.
<cjwatson> iwj: I have no brain right now; happy to inspect logs when brain returns
<iwj> cjwatson: *sympathy*  OK, shall I file a bug and keep the install ?
<pitti> iwj: FWIW, I do that all the time (reusing /home) for installs of my production machine and it never did that for me
<gnomefreak> thank you. im doing as much as i can to work around them but that isnt going so good.  The bug this monring that the coredump was bad cant find # atm. is that apport or is that LP or the packages she has?
<cjwatson> please - probably on pkgsel
<iwj> Maybe I hit the `server install' option by mistake but I don't _think_ so./
<pitti> gnomefreak: bug 90348?
<Ubugtu> Malone bug 90348 in mozilla-thunderbird "[apport]  mozilla-thunderbird-bin crashed with SIGSEGV in __kernel_vsyscall()" [Medium,Needs info]  https://launchpad.net/bugs/90348
<gnomefreak> we will never get a good crash on thunderbird
<pitti> gnomefreak: I can't really say; might be missing packages/dbgsyms, might be broken dbgsyms, might be scrambled memory
<gnomefreak> not sure why but the dbgsym package doesnt give us anything
<pitti> gnomefreak: do you get good traces with the dbgsyms in a 'laborarory' crash? like killall -SEGV thunderbird?
<pitti> laboratory, even
<iwj> cli.preseed it says.
<iwj> Hmmm.  Let me just check ...
<cjwatson> cli == server install
<cjwatson> "command-line installation"
<pitti> gnomefreak: when I find some time, I shall try this myself and check more thoroughly what the problem is
<gnomefreak> i havent seen one say killall. if you have a bug# handy i will try it. or give me a day and i will see if i can find a bug with that
<iwj> That's what I suspected.
<pitti> gnomefreak: I meant, start tbird, killall -SEGV it, and analyze that crash report
<iwj> Right, err, PEBKAC.
<cjwatson> ok, could be worse :)
<gnomefreak> pitti: i built dbg package for tb just erased /home/ by mistake but i thin i uploaded it
<pitti> gnomefreak: that's guaranteed to not scramble any memory and such
<iwj> I wonder how that happened.
<gnomefreak> ah ok
<pitti> gnomefreak: rm ~> ouch 
<cjwatson> day of testing => scrambled attention span?
<gnomefreak> yeah i rm -rf /var/chroot/edgy :(
<gnomefreak> with sudo of course
<iwj> Maybe my hindbrain translated `I want "install in text mode"' to `I want a "command-line install"'.
* gnomefreak will remember to unmount it first
<cjwatson> rm needs a --one-file-system switch ...
<pitti> gnomefreak: with /home bind-mounted into it, I guess
<gnomefreak> yep
<iwj> cjwatson: mkfs :-).
<cjwatson> ideally --one-file-system by default actually and a --cross-file-system option but they probably wouldn't break compatibility like thatt
<cjwatson> chalk another one up for the list to take in the time machine when we go back to redesign Unix
<gnomefreak> pitti: also on the bug with dpkg --unpack failing it seems to be failing due to libgcc1-dbgsym libnspr4-dbgsym libnss3-dbgsym
<pitti> gnomefreak: that sounds like exactly those packages with broken epochs
<gnomefreak> pitti: i get teh update-manager telling me it failed running apt-get -f install removes those packages
<gnomefreak> thats the only thing i have found on that 
<pitti> gnomefreak: right, I need to fix pkg-create-dbgsym to respect those weird binary-specific version numbers; there's a bug about that already; it doesn't prevent -u from working, though
<gnomefreak> with -u is when i get it now
<gnomefreak> i havent tried without -u yet
<Mithrandir> mdz: we didn't close the bugs, we just reused the old ones so you should have gotten notifications if you subscribed to the same bug.
<mdz> Mithrandir: I am subscribed to bug 93122 but there's nothing in the comments to indicate that my testing was invalidated, what the problem was with the ISO i had tested, or that a new ISO was available for testing
<Ubugtu> Malone bug 93122 in ubuntu-iso-tests "beta: Ubuntu i386 alternate" [High,Confirmed]  https://launchpad.net/bugs/93122
<Mithrandir> mdz: Henrik commented on a lot of other bugs invalidating them, I assumed he had done so on the i386 alternate one too.
<Mithrandir> mdz: anyway, there shouldn't be any code changes whatsoever between them, so I'm confident that if one boots correctly, the other should too.
<mdz> Mithrandir: what was the bug?
<Mithrandir> mdz: I didn't see that cjwatson rebuild the ISOs between me going to bed and waking up, so I redid them.
<Mithrandir> s/rebuild/rebuilt/
<cjwatson> next time I'll send mail in that event
<Mithrandir> cjwatson: I would have seen it if I had either been more awake or you had highlighted it for me.
<gnomefreak> pitti: one more thing while i got you here. the retrace stated cant find libflashplugin.so in path/bleh but its there. is that file in all flash type apps example gnash or libflash-mozilla
<cjwatson> Mithrandir: Riddell had highlighted the problem for you, but indeed I appear not to have done
<gnomefreak> it ignores it but i check my path and its there
<cjwatson> our processes close to release time ought not to assume that the RM is awake, given the hours usually required :-)
<pitti> gnomefreak: is it from an actual package? it might complain about not finding a *package* for it
<pitti> gnomefreak: thus it cannot get a dbgsym for it
<Mithrandir> cjwatson: yes, so I saw the problem, but not that you fixed it.  Anyway, I can publish the .1 if mdz would prefer that.
<eV64> !java
<Mithrandir> cjwatson: not awake> true enough..
<Riddell> carlos: bug https://bugs.beta.launchpad.net/rosetta/+bug/92518 says it's fixed but there's no translations at https://translations.beta.launchpad.net/ubuntu/feisty/+source/kopete/+translations
<Ubugtu> Malone bug 92518 in rosetta "Kopete translations are not used, because source package has changed" [Undecided,Fix released]  
<gnomefreak> i will look into it more i havent seen one since i have been rebuilding /home/ and chroots
<Riddell> carlos: oh, ignore me, that's the URL that should have nothing at it
<mdz> Mithrandir: I'm not fussed about .1 vs. .2, but we do need to be more rigorous about the process in general
<Mithrandir> mdz: agreed.
<Mithrandir> I wonder if I could make the CD builds mail the bugs by keeping tracking bugs in malone and a mapping from image name to bug # on lithium.
<Mithrandir> heno: ^^ would that make your job easier?
<heno> Mithrandir: that would help yes
<heno> though I think we need to redesign the tracking system anyway, too many manual gaps
<Mithrandir> and we can have a "daily build between herd 5 and 6" bug so I wouldn't have to keep filing bugs.
<heno> I'm doing a GSoC project on it now
<Mithrandir> yes, manual work is error-prone and icky.
<gnomefreak> pitti: WARNING: library /var/cache/flashplugin-nonfree/libflashplayer.so not found in system packages -- ignoring
<pitti> gnomefreak: right, what I assumed. -- /var/cache/ ???
<pitti> gnomefreak: ah, that's where libflashplugin-nonfree downloads it, I figure
<gnomefreak> i did have it there i check path against path given. atm i done have flash installed yet
<pitti> gnomefreak: but it doesn't matter much anyway in that case
<pitti> gnomefreak: there's no way how we can get debug symbols for that one anyway
<gnomefreak> ah
<gnomefreak> so flash will always be mininal stacks
<pitti> so if it crashes in that lib -> it's nonfree, screw upstream
<pitti> gnomefreak: not necessarily; if it's a genuine crash in the browser itself, it shouldn't matter
<gnomefreak> ah ok
<pitti> gnomefreak: a stack trace doesn't become useless just because a library without dbgsyms is loaded; it does as soon as the stack goes 'through' this library
<pirast> keescook, thanks also :)
<gnomefreak> ah
<cjwatson> or at least if the stack ends in that library
<cjwatson> if it goes through and comes back out (possible with some plugin architectures) it might still be salvageable. :-)
<pitti> right
<mdz> pitti: that's where it downloads it, but surely ti isn't run from there, or if it is, that's a bug
<pitti> mdz: right, but even if it moves it to /usr/local or anywhere, it won't be part of a package (dpkg -S wise)
<mdz> pitti: right, I'm just saying it sounds like there might be a different bug there
<mdz> pitti: it copies the .so to /usr/lib/flashplayer-nonfree, and that's the one which should be used by the browser...
* pitti is so happy that his browser doesn't crash *ever*
<pitti> mdz: ah, makes sense
<mdz> mine rarely crashes, but occasionally spins
<_ion> pitti: Please pull the changes from my restricted-manager branch. Now it should contain a complete listing of nVidia IDs.
<pitti> gnomefreak: this silly flash plugin seems to cause so much trouble, maybe we should have an apport hook and some magic field DoNotFile: to avoid spamming us with crashes when the flash plugin is loaded
<pitti> _ion: yay!
* pitti hugs _ion 
<gnomefreak> pitti: +1
<pitti> _ion: funny; modalias_override_scripts/nvidia_supported is both deleted and added
<_ion> pitti: It's intentional. I first removed the old one and then wrote a new one.
<pitti> _ion: wow, that looks like a crazy hack :)
<_ion> Hehe, yeah
<_ion> But it seems to work.
<pitti> rock
<pitti> _ion: right, thanks for the bc03, in case of false positive integers
<_ion> I compared its output to the previous listing. There were no deletions, only some additions, and the additions contained the IDs that were previously manually added to nvidia.manual.
<pitti> it looks very reasonable, too
<pitti> pulled/pushed
<desrt> tepsipakki; ping
<mdz> pitti: is there enough information in the crash file to determine whether flash is loaded?
<pitti> mdz: yes, you should see it in ProcMaps
* pitti searches an example crash
<keescook> dholbach: re 86974, where did you see it was the autopackage version?
<mdz> pitti: seems perfectly reasonable to exclude those, then.  probably not even necessary to tell the user anything
<keescook> dholbach: oh, duh, I can read.  nevermind.
<mdz> though it would be nice if we could provide a URL where they could contact adobe
<pitti>  af277000-af474000 r-xp 00000000 03:07 7716868    /home/kirill/.mozilla/plugins/libflashplayer.so
<pitti> ^ for example
<pitti> asac, gnomefreak: if I make the apport UI recognize a field 'UnsupportableReason: <text>' and display <text> instead of filing the bug, would you two like to work on the firefox apport hook?
<pitti> this hook should be shipped in firefox itself
<gnomefreak> i will get with asac and see what he wants to do. hes building 2.0.0.3 before beta so hes been a bit on the busy side
<pitti> certainly not for beta
<gnomefreak> oh god no
<rbrunhuber> Is there a plan to integrate the debian installer (the new one) with encryption support into feisty?
<cjwatson> rbrunhuber: not feisty (cryptsetup wasn't glued into usplash in time), but as soon as all the necessary bits are in place after that then it's easy enough to pull in those partman changes
<keescook> pitti: apport> what do you think of including md5sums of the Exec/InterpPath file during the "add_package_info" stage?  bugs like 86974 would be more obviously rejectable that way.
<cjwatson> I think we already have the code in fact, just didn't put it all in main because it wasn't working right
<pitti> keescook: we already check the integrity of Package: and all Dependencies:
<rbrunhuber> cjwatson : thank you. Although i had better liked the cryptsetup than usplash. Because  usplash does not work for me since ages
<pitti> keescook: that bug has a huge [modified: ]  line
<keescook> oh duh! I forgot about "modified"!
<sladen> rbrunhuber: do you have a bug number?  What do you mean by "not work" ?
<cjwatson> rbrunhuber: I'm afraid usplash is a core part of our system and we're not going to drop it in favour of cryptsetup
<pitti> keescook: I like retroactively fixed feature requests!
<keescook> pitti: the best kind.  :)
<sladen> rbrunhuber: if you notice something stop working, if you file a bug report /immediately/ then it's easier to track down which commit might have broken it on your system
<rbrunhuber> sladen : I have a bugreport: 71004 and 72216 
<sladen> bug #71004 bug 72216
<Ubugtu> Malone bug 71004 in usplash "[kubuntu edgy and feisty]  with boot parameter splash (usplash) shutdown is not working (dup-of: 72216)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/71004
<Ubugtu> Malone bug 72216 in usplash "Usplash sometimes hangs during shutdown/reboot and displays strange characters" [Undecided,Unconfirmed]  https://launchpad.net/bugs/72216
<Ubugtu> Malone bug 72216 in usplash "Usplash sometimes hangs during shutdown/reboot and displays strange characters" [Undecided,Unconfirmed]  https://launchpad.net/bugs/72216
<sladen> Seveas: ^^ ubugtu could work out which ones it's going to print in one go, and avoid printing multiples caused by dupes
<Seveas> sladen, ack
<sladen> rbrunhuber: that bug appears to be about usplash on shutdown, not on bootup
<rbrunhuber> sladen: or the bug number spitting user (me) could be smart enough :-)
<rbrunhuber> sladen : what is the problem if start or shutdown? usplash is usplash?
<sladen> rbrunhuber: I don't think it's actually usplash at all;  I think it's one of the machines where we just fail to manage to make the machine power-off/reboot  (BIOS/ACPI brokenness)
<poningru> quick question
<sladen> rbrunhuber: cryptsetup would only occur at start-up;  but you said that you'd stopped using usplash because it was broken anyway;  though it sounds like it's only usplashdown that is having issues
<poningru> beta is still not recommended on production environments right?
<proppy> cjwatson: ping
<poningru> anyone? need to do this for release notes
<rbrunhuber> sladen : i made the most obvious thing. remove splash from the kopt line in menu.lst. 
<LaserJock> poningru: I would think it would be recommeneded
<LaserJock> sorry
<LaserJock> *wouldn't
<Mithrandir> poningru: I would not recommend people upgrade production systems to beta, no.  I would recommend it as "please try this out, even if you don't want to spend lots of time debugging it"
<poningru> ok cool thanks
<rbrunhuber> sladen : but why should the computer shut down reliable if no usplash down is used?
<rbrunhuber> sladen : if this is a bios/acpi problem
<Seveas> sladen, fixed
<carlos__> Riddell: yeah, the translations are inside kdenetwork
<sladen> Seveas: result!
<sladen> rbrunhuber: okay, and that's been tested/confirmed
<Seveas> hmm, reading the topic: I have a machine that never shut down but always rebooted
<Seveas> with kernel 2.6.20-9
<Seveas> somewhere between there and th latest, that's solved
<rbrunhuber> The bug has a duplicate and i often tested it. but i can't confirm my own bug.
<sladen> rbrunhuber: I've got an i945GM here, I'll keep my eyes open
<mdz> cjwatson: alternate install just asked me for a proxy; it's never done that before. does that mean a download failed or something?
<rbrunhuber> sladen : This is not specific to i945GM AFAIK
<_ion> pitti: Now it should be possible to generate all the needed ID lists from within the linux-restricted-modules build process, btw.
<pitti> _ion: or even at restricted-manager runtime
<pitti> but build process would be better, right
<_ion> That would require the existence of the ATI driver.
<sladen> rbrunhuber: okay, if you have it confirmed on any other systems, can you make sure those details are included
<rbrunhuber> sladen: I'll do. Is usplashdown writing any logfile?
<janimo> is the source NEW  queue visible from outside?
<Toadstool> janimo: by "outside", you mean visible to regular people, not only archive gods?
<Toadstool> if that's the case, then you can take a look at https://launchpad.net/ubuntu/feisty/+queue
<janimo> Toadstool, that's what I was looking for, thanks!
<Toadstool> you're welcome ;)
<HiddenWolf> tepsipakki: ping
<tepsipakki> HiddenWolf: pong
<HiddenWolf> tepsipakki: updating bug 40422 now with the info you asked. Anything else I can do?
<Ubugtu> Malone bug 40422 in xresprobe "Dell 2405FPW and resolution 1920x1200" [Medium,Confirmed]  https://launchpad.net/bugs/40422
<tepsipakki> be patient? :)
<tepsipakki> oh, run /usr/share/xresprobe/ddcprobe.sh
<HiddenWolf> just added. Identical. :)
<svu_> is there a chance to get latest swfdec in feisty? youtube is must have:)
<tepsipakki> HiddenWolf: oh, indeed
<HiddenWolf> Wasn't trying to rush you btw, just wondering if I could be helpful while at it.
<tepsipakki> HiddenWolf: ok then.. you need to run some commands
<tepsipakki> np
<tepsipakki> first 'ddcprobe > foo'
<HiddenWolf> attached
<tepsipakki> we can handle it here
<HiddenWolf> first off, it says analog signal, but it's on dvi
<tepsipakki> I don't think it matters
<tepsipakki> next, run 'cat foo| egrep '^[cd] *timing:' | sed -e 's/^[cd] *timing: \([^x] *\)x\([^ @$] *\).*$/\1x\2/;'
<tepsipakki> there is a space between 'timing: \(...'
<tepsipakki> what is the last entry?
<HiddenWolf> 1920x1200
<tepsipakki> right
<tepsipakki> oh god
<tepsipakki> you're right
<tepsipakki> the crt-thing does matter
<tepsipakki> since it doesn't allow to use the highest resolution on crt's
<HiddenWolf> clever
<tepsipakki> now how to work around it..
<tepsipakki> there is no clean way to do it
<HiddenWolf> about the only thing that pops to mind might be whitelisting monitors somehow, but I know about as much about X as my granny, so I doubt I can help there.
<tepsipakki> it should be glued in ddcprobe.sh
<tepsipakki> or making a list and then parsing it from there
<tepsipakki> "match these strings"
<HiddenWolf> seems sensible to me.
<HiddenWolf> I will have to tuck in now.
<HiddenWolf> Thanks for the help and the work on X.
<tepsipakki> HiddenWolf: thanks for pushing me in the right direction ;)
<tepsipakki> sheesh it was simple
<HiddenWolf> Glad to be of assistance in my limited way.
<HiddenWolf> Good night.
<tepsipakki> night
<cjwatson> proppy: pong, just leave a message and I'll respond later
<cjwatson> mdz: the installer does a test wget from archive.ubuntu.com, and if that fails it asks for a proxy
<proppy> cjwatson: about the mouseemul bug, i searched for duplicate before posting, but by default bug search doesn't include "resolved,release", so sorry :)
#ubuntu-devel 2007-03-23
<keescook> Mithrandir: with main frozen, how do you want me to handle security updates that need to go in?  should I open a freeze-exception bug for each one, email you a list, or just upload them?
<racarr> has anyone found problems with the Beryl packages in NEW, or just no time to look at them?
<Fujitsu> racarr: It takes time, and beta is the priority at the moment.
<racarr> Fujitsu: I know, not complaining, just making sure there were no issues
* iGama at amanha
<Bartman007> is there a known issue with locales on the feisty herd 5 amd64 alternate cd?
<ravi_master> one quick suggestion: make better network installs
<ravi_master> ubuntu < most distros out there when it comes to being able to install the OS over the network
<Burgundavia> ravi_master: create a spec about it
<Burgundavia> be nice to have some official netboot images, plus an easy way to provision them
<Burgundavia> or just use ltsp fat clients
<Hobbsee> Burgundavia: i thought they existed.  LCA ubuntu ppl were doing ubuntu-on-tap, installing edgy
<Burgundavia> hmm
<elmo> official netboot images have always existed
<Burgundavia> once ogra finishes ltsp fat clients, there is no reason to net install in a large environment
<elmo> dists/$distro/main/installer-$arch/current/netboot
<Burgundavia> right
<Burgundavia> cool
<elmo> (actually current/images/netboot)
<Burgundavia> hmm, we have three netboot installation instructions
<ravi_master> i'm sorry but netboot stuff is disgusting as opposed to being able to install from remote or local ftp/http mirrors
<DaSkreech> Hello
<DaSkreech> I've had an issue with urls/routes working in GUI programs till after they have been pinged
<DaSkreech> I've seen it happen across 6 computers and I have two people in #ubuntu now with similar experinces
<DaSkreech> Would it make sense to discuss it here?
<winterborne> *knock knock* anybody home?
<winterborne> more importantly... could somebody tell me how close we are to a beta release?
<reitblatt> Friday
<reitblatt> is the current plan I've heard
<winterborne> very cool
<winterborne> is there a place to look for updates online other than the ubuntu-devel/devel-announce mailing lists?
<winterborne> I notice that there's very little on there. And while launchpad has some good information, it's not.... well, a CVS log.
<DaSkreech> RSS?
<DaSkreech> Fridge?
<Fujitsu> winterborne: What do you mean by updates?
<winterborne> er... like news about exactly what is being added, or being patched
<DaSkreech> winterborne: Oh granular news
<Fujitsu> The feisty-changes list shows every change.
<winterborne> cool
<winterborne> daskreech: :o there's a term for it?
<DaSkreech> No :)
<DaSkreech> You want svn commit info
<DaSkreech> Or .. bazaar I guess
<Fujitsu> But only a tiny fraction of the packages is maintained in bzr.
<winterborne> feisty-changes shows a mind-boggling number of 'accepted' messages
<winterborne> what's the bazaar for, exactly? (or is this something that's well documented and I've just been too impatient to read about)
<winterborne> oh, it's like a cvs, of sorts?
<Fujitsu> winterborne: That's the point of feisty-changes, to show the accepted changes...
<Fujitsu> bzr is somewhat like CVS. Some packages are maintained in it.
<winterborne> okay. have you got an example of which packages would/wouldn't be maintained there?
<winterborne> looks like most of the stuff in bzr is about bzr itself
<Fujitsu> mplayer is, for example. Few others are.
<fabbione> morning
<Fujitsu> Hi fabbion.
<Fujitsu> *fabbione
* Fujitsu has bad XChat habits.
<gabriel_> hi everyone! I just wanted to shout out about the first install fest in Tampico, Mexico
<gabriel_> 26 Ubuntu installations total
<gabriel_> its a great number for a very small university
<DaSkreech> :-)
<gabriel_> plus we gave out 40 Ubuntu disks to people that couldnt bring their systems
<gabriel_> but wanted to try it out or install it by themselves at home
<gabriel_> no cds were given to random people, only interested ones
<gabriel_> so, I guess there's gonna be at least 20 more installations at home today
<gabriel_> some details are posted on my blog (in spanish) at http://blog.nethazard.net
<gabriel_> i did notice some things that we would like to fix for next year's install fest
<gabriel_> codecs, flash and java, and network manager are a must
<gabriel_> and sometimes hard to get
<gabriel_> considering we had lots of installations to do, plus assistance and introduction to a new system
<jetsaredim> is there any good information on making changes to the installer?
<jetsaredim> ubiquity, that is
<Mithrandir> keescook: if they're ok to go into -security, then they're ok to go into -release.  If you have a diff you think is too big so you are unsure about whether to backport or include new upstream version, please contact me/the release team
<Mithrandir> morning, Hobbsee
<Hobbsee> heya Mithrandir!
<viviersf> Mithrandir, does /etc/network/interfaces get generated by casper or ubiquity ?
<jetsaredim> can anyone answer my question from earlier?
<reitblatt> jetsaredim: what kind of changes do you mean?
<Mithrandir> viviersf: yes.
<jetsaredim> some people are looking into adding a mythtv-specific screen for a specialized distro
<fabbione> morning Mithrandir 
<LaserJock> jetsaredim: would that be mythbuntu or ubuntu mce?
<jetsaredim> mythbuntu
<viviersf> Mithrandir, which one :(
<Mithrandir> viviersf: both.
<Mithrandir> morning, Fabio.
<Mithrandir> viviersf: but it's changed in the installed system through a casper-provided hook
<LaserJock> jetsaredim: I don't know that there is a ton of documentation, but cjwatson is the guy who wrote it and there is #ubuntu-installer
<jetsaredim> ah
<jetsaredim> didn't know that
<jetsaredim> i'll poke around in there
<jetsaredim> thanks
<viviersf> Mithrandir, im just trying to figure out which packages to file a bug against, when all network devices are managed by network manager, the ethernet devices shouldnt be in there, it makes booting on especially ibm notebooks very slow
<tritium> viviersf: my thinkpad would be at least one counter-example.  It boots just fine.
<viviersf> tritium, the ones here sit and wait for bout 4 mins for a dhcp lease then goes on, its stupid for it to do it that way, since networkmanager does it anyways
<reitblatt> weird
<reitblatt> my tp works fine as well
* reitblatt hugs his T43
<Mithrandir> viviersf: it shouldn't do that, no.
<tritium> Yeah, my T43p doesn't do that...
<viviersf> these ibm's are a R60 and a X60s
<reitblatt> 3945 wireless?
<viviersf> yep 
<viviersf> reitblatt, it a known issue ?
<reitblatt> not that I know of
<reitblatt> but that's a newer card
<Burgundavia> Mithrandir: you up yet?
<viviersf> reitblatt, :(
<Mithrandir> Burgundavia: yes
<Burgundavia> Mithrandir: regarding the beta announcement, we have a small hitch. We the ubuntu.com changeover, I honestly have no idea how to get content to the website. Further, the wiki one really isn;t finished...
<giangy> 'morning
<Mithrandir> Burgundavia: hm, ok.  If I solve the former, can you solve the latter problem?
<reitblatt> viviersf: go ahead and file a bug against Ubuntu
<reitblatt> and give me the bug number here
<Burgundavia> Mithrandir: I will try. What is my timeframe?
<fabbione> Burgundavia: yesterday :P
<Burgundavia> heh
<Burgundavia> I was busy with work, dammit! :)_
<Mithrandir> Burgundavia: technically yesterday, but in the next six hours would be good, if possible..
<Burgundavia> ok, I will try and scare somethign up
<Mithrandir> thanks.
<viviersf> reitblatt, file a bug against which package :/
<reitblatt> just Ubuntu
<reitblatt> viviersf:  leave the package blank
<viviersf> k
<viviersf> reitblatt, #94993
<dholbach> hellas
<reitblatt> bug 94993
<Ubugtu> Malone bug 94993 in Ubuntu "long network delay on bootup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94993
<pitti> Good morning
<Fujitsu> Hi pitti.
<Hobbsee> hey pitti!
<dholbach> hey Hobbsee
<Fujitsu> pitti: Is the auto-retracing having issues, by any chance?
* pitti looks
<Fujitsu> I see a number of bugs that haven't been retraced, when they've been tagged for almost 12 hours.
<pitti> Fujitsu: indeed, it seems stuck
* pitti restarts
<reitblatt> viviersf: left a comment for you on the bug report
<Fujitsu> Thanks pitti.
<pitti> Fujitsu: but the queue is still huge, blame dholbach :)
<viviersf> reitblatt, cool
<Fujitsu> It's going to have quite a number to work on
<Hobbsee> hi dholbach!
<dholbach> :-D
<reitblatt> viviersf: let's move this over to #ubuntu-bugs
<viviersf> k
<pitti> for some weird reason, dpkg sometimes hangs indefinitely
<Fujitsu> pitti: Is the libgcc epoch-related installation failure likely to be fixed in the near future?
<mlankhorst> I feel like testing out upstart, does anyone have a start with custom boot scripts that replace sysvinit compat, or at least making a start with it?
<pitti> Fujitsu: probably not in the next days; use -u as a workaround for now
<Fujitsu> Aha, thanks pitti. Didn't know that existed.
<isis>  /help
<pitti> gnomefreak: I just committed support for "UnsupportableReason: <text>" to apport
<gnomefreak> pitti: ty
<Fujitsu> pitti: Where does that go?
<pitti> Fujitsu: into the crash report file in /var/crash; intended to be set in a package hook
<Fujitsu> Ah.
<pitti> Fujitsu: the idea is: check report['ProcMaps']  for libflashplugin.so, and if so, set report['UnsupportableReason']  = _('Flash is b0rked blabla')
<pitti> gnomefreak: ^
<pitti> see /usr/share/doc/apport/package-hooks.txt
<Fujitsu> Oh, I see.
* pitti adds a complete example for this to the doc, to lower the entry barrier
<gnomefreak> ok cool, this will be pushed after beta release?
<pitti> yes
<gnomefreak> ok i will let asac know. I havent seen him sinse we spoke earlier about writing a hook
<pitti> gnomefreak: you should also speak to David Farning; we two had several rounds of package hooks discussions already
<gnomefreak> i will next time i see him or ill email him after i wake up once i go to bed
<dholbach> only 100 old apport crash reports left - and ~60 of them are mono ones
<dholbach> yoohoo
<tepsipakki> dholbach: thanks for going through them, especially the X ones
<dholbach> no problem
<dholbach> after that I hope we'll stay up to scratch
<cjwatson> winterborne: http://wiki.ubuntu.com/BzrMaintainedPackages FWIW
<dholbach> all untriaged apport bugs done - only mono crashes left - yoohoo
* pitti hugs dholbach 
<dholbach> pitti: the retracer will have a busy weekend I guess ;-)
* dholbach hugs pitti back
<pitti> indeed
<seb128> dholbach: no need to ask for a dump for python crashes ;)
<seb128> dholbach: https://beta.launchpad.net/ubuntu/+source/gaim/+bug/85069
<Ubugtu> Malone bug 85069 in gaim "[apport]  gaim-url-handler crashed with DBusException in __call__()" [Medium,Needs info]  
<seb128> dholbach: all done? you needinfo the ~400 outdated ones also?
* seb128 hugs dholbach, good work
<dholbach> seb128: sorry - must have missed that (gaim bug)
<seb128> dholbach: np, just pointing in case you are not subscribed and want to reply to the guy
<mlankhorst> !netboot
<mlankhorst> !netinstall
<mlankhorst> hm no bot here?
<fabbione> mlankhorst: http://doc.ubuntu.com/ and i am not a bot
<fabbione> google is your friend too :)
<mlankhorst> I'm aware, but those are usually shortcuts :-)
<fabbione> not in this channel no
<fabbione> they are offtopics
<fabbione> specially when people are busy getting beta out of the door
<cjwatson> indeed. there are other places to go if you want a bot
<pitti> heno: what's the testing status? shall I do the remaining amd64/alternate tests?
* pitti does them
<heno> pitti, Mithrandir: ^? I beleive we are happy with the testing done to this point
<Mithrandir> heno: more testing never hurts, but it's not required, no.
<pitti> heno: ok; we don't have a single OEM or expert test on amd64, for example
<Mithrandir> so if pitti is happy to do them, it'd be nice to have them
<pitti> ok, I set them up now and let them run while I'll have some breakfast
<heno> pitti: I've done oem tests on both i386 and amd64, but on the dvds
<pitti> ah, ok; shouldn't be much different there
<pitti> but anyway, I'll just do them nwo
<heno> pitti: that should be the same, but more testing is appreciated :)
<heno> cool
<dholbach> pitti: seems that the crash digger removed the tag on bug 87039 but didn't attach a retraced backtrace
<Ubugtu> Malone bug 87039 in at-spi "[apport]  gdmgreeter crashed with SIGSEGV in XInternAtom() on feisty" [Medium,Unconfirmed]  https://launchpad.net/bugs/87039
<pitti> dholbach: I'll have a look in a minute
<mvo> ogra: you want me to upgrade test edubuntu again? it seems like this entry is missing in the status page?
<dholbach> pitti: take your time
<pitti> dholbach: ugh, it's still busy retracing this one; I guess it got stuck again
<pitti> no idea why
<pitti> I'll restart the retracer
* dholbach hugs and comforts pitti
<dholbach> . o O { crasher king pitti }
<pitti> heno: right, testing a super-complicated multi-partition LVM install is fun, too :)
<heno> pitti: yeah, I think we should encourage more variety in testing in the future actually
<heno> everyone testing the same cases on identical VMs does us little good
<mlankhorst> loop-aes patches should be added to kernel :p
<Fujitsu> mlankhorst: Aren't they?
<mlankhorst> not sure, thought not
<mlankhorst> i played around a little with initramfs, made loop-aes working with update-initramfs
<mlankhorst> requires static linked losetup and gpg but apart from that it's all done in scripts
<mlankhorst> however each kernel update means extracting kernel source, building loop + bzImage putting them in place and regenerating initramfs, then putting it on usb stick
<Fujitsu> What are you using it for?
<mlankhorst> a 1 step putting it on usb stick would be more fun :-)
<mlankhorst> encrypted loop + encrypted swap, software suspend/resume works fine
<mlankhorst> s/loop/root/
<Fujitsu> dm-crypt is the less-obsolete method to do that.
<mlankhorst> cryptoloop is obsolete, loopaes not
<mlankhorst> different methods
<ogra> mvo, if you have a running edgy already, indeed :)
<mvo> ogra: I have a image for that :)
<ogra> oh
<ogra> nice :)
<mvo> ogra: do you maintain schooltool? it seems to have issues with the upgrade
<ogra> see pm :)
<Fujitsu> school{bell,tool} are somewhat beyond dead.
<mlankhorst> small patch to initramfs actually, http://cross-lfs.org/public_html/initramfs-loopaes.tar.gz  - my gpg and losetup are not included and were linked against uclibc, since i no longer have the toolchain that created it i didn't include them here for legal reasons
<ogra> Fujitsu, they have a userbase in edubuntu 
<ogra> but it wasnt ported to a recent zope ... so we'll have to drop it for feisty i fear
<Fujitsu> ogra: Upstream is looking at a proper release for Feisty+1, but there are no plans for Feisty.
<ogra> i know
<ogra> Mithrandir, is the announcement already final ? it just struck me that i forgot to add edubuntu over the testing ...
<Mithrandir> ogra: the announcement isn't final until it's sent. :-)
* ogra quickly tries to get a text together
<StevenK> mvo: What environment did you try these [can-not-install]  bugs? My ubuntu-minimal Feisty chroot has /etc/inittab. (bug 93673)
<Ubugtu> Malone bug 93673 in runit "[can-not-install]  maintainer script failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93673
<mvo> StevenK: pbuilder chroot seems to work fine to reproduce the problem. my environment was a big install (~19000 pkgs) but most of them I verifided again in a chroot
<pitti> dholbach: I had to cancel retracing of bug 86607 - can you please retrag it again? I'll do some small optimizations to the retracer that should speed it up a little and make it more robust
<Ubugtu> Malone bug 86607 in totem "[apport]  totem-plugin-viewer crashed with SIGSEGV in _start()" [Medium,Unconfirmed]  https://launchpad.net/bugs/86607
<dholbach> pitti: you rock
<StevenK> mvo: I'm just not sure about fixing runit.
<StevenK> mvo: Just based on the fact that we have upstart.
<HiddenWolf> Mithrandir: is the "the ubuntu team is proud to announce" line intended in the "why are some features not enabled by default" faq section of the announcement?
<cjwatson> StevenK: it should conflict
<mvo> StevenK: my opinion is that maintainer scripts should not fail. never. so I think we should either fix it or remove it (remvoing is fine with me)
<StevenK> Removing works for me too, to be honest.
<Mithrandir> HiddenWolf: probably not; I would think it's a C&P error
<cjwatson> adding Conflicts is the right answer. other packages do that
<cjwatson> that option would be syncable to Debian too
<StevenK> Oh right, upload a runit that conflicts against upstart.
<HiddenWolf> Mithrandir: removed then.
<dholbach> why is gftp in main?
<dholbach> seb128: ^ do you think we should unseed it?
<dholbach> it's somewhat unmaintained
<seb128> dholbach: to what seed?
<seb128> dholbach: I think it's nice to have a graphical GTK ftp client to main
<dholbach> nautilus is one :)
<seb128> no it's not
<mvo> and firefox
<seb128> neither
<seb128> that's like comparing eog to gimp
<dholbach> why isn't nautilus an ftp client?
<seb128> because it sucks as ftp client
<dholbach> hrm
<dholbach> HRM
<dholbach> seems it's in supported
<seb128> it's fine there imho
<cjwatson> StevenK: runit-run probably, since that's the thing that ships /sbin/init
<seb128> dholbach: do you think it's that buggy?
<cjwatson> should really conflict with sysvinit too - no idea why it doesn't even do that
<cjwatson> unless it diverts it
<ogra> HiddenWolf, are you still editing ? 
<dholbach> seb128: we got quite some bugs (not THAT many) but there were no upstream reports
<dholbach> s/reports/updates
<ogra> (wiki has a lock)
<cjwatson> oh, hmm, apparently it does divert it
<HiddenWolf> ogra, no I'm not.
<ogra> thanks
<seb128> dholbach: I know aurel32 do some work on it for Debian and they use bugzilla.gnome so we can forward bugs
<dholbach> ok
<dholbach> i wasn't saying he does a bad job
<seb128> dholbach: maybe mail the discuss list to know who uses it?
<dholbach> popcon should know
<dholbach> now that it finally works
* dholbach pats mvo on the back
* dholbach looks it up
<cjwatson> StevenK: ok, sorry, I misunderstood the problem
<seb128> dholbach: the things is that nautilus has no option to use things like passive mode, limite the bandwith, the number of connexions to open, etc
<dholbach> place 1314 - 6427 people
<cjwatson> StevenK: change the postinst to make it add /etc/event.d/runit instead?
<dholbach> looks like a bunch of people use ist
<seb128> yeah, so keep it to supported?
<dholbach> maybe
<dholbach> yes
<cjwatson> if upstart is in use that is
<ogra> Mithrandir, i added an LTSP section to the server part and the edubuntu block below that, please check for spelling/formulation errors
<StevenK> cjwatson: Aye. Thanks.
<StevenK> mvo: I also can't reproduce your jadetex install failure.
<StevenK> mvo: Shall I stop looking at your bugs, since they seem to work for me? :-P
<mvo> StevenK: there may be false positivies in there, but I verified most of them :)
<StevenK> mvo: What troubles me is you said "Can be easily reproduced in a clean pbuilder chroot"
<pitti> dholbach: ok, digger is running again; I pre-installed a large number of gnome-related libraries, as well as firefox and tbird
<dholbach> NICE
* dholbach hugs pitti
<mvo> StevenK: can you give me the bugnumber please? I re-check
<pitti> wow, that's much faster now
<pitti> dholbach: please re-tag bugs 94766 and 82475 if they got lost; I need to roll out some more fixes
<Ubugtu> Malone bug 94766 in evolution "crashes when i start it up" [Medium,Unconfirmed]  https://launchpad.net/bugs/94766
<Ubugtu> Malone bug 82475 in granule "[apport]  granule crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/82475
<mvo> StevenK: pbuilder login ; apt-get install jadetex on a current feisty pbuilder chroot seems to fail here (as expected) (updmap-sys failed). amd64
* mvo -> lunch
<Tonio_> pitti: as you're here, may I ping you concerning package klavier ?
<Tonio_> pitti: still in NEW while I uploaded it juste before the universe freeze....
<Tonio_> pitti: Riddell and I would like to get it in the archives as it is quite important que the accessibility part of kubuntu
<pitti> Tonio_: I'll have a look at it later
<Tonio_> pitti: thanks
<heno> Tonio_: interesting. I'd like to have look. Do you have a.deb somewhere?
<pitti> dholbach: WTF??? bug 82962  -> DistroRelease: Debian 3.2
<Ubugtu> Malone bug 82962 in bayonne "[apport]  bayonne.bin crashed with SIGSEGV in strcpy()" [Medium,Unconfirmed]  https://launchpad.net/bugs/82962
<pitti> dholbach: :)
<pitti> dholbach: sorry, I cannot retrace those ATM
<Tonio_> heno: I can build it to let you test, will take a couple of seconds
<heno> Tonio_: cool, thanks
<pitti> heno: I just finished bug 93123
<Ubugtu> Malone bug 93123 in ubuntu-iso-tests "beta: Ubuntu amd64 alternate" [Undecided,In progress]  https://launchpad.net/bugs/93123
<heno> pitti: great, thanks
<pitti> seb128, dholbach: lp-crash-digger on duty again; let's cross fingers that it runs smoother now
<seb128> pitti: cool
<seb128> pitti: do you have some retracer log?
<seb128> pitti: do you know why retracing #94737 didn't work? 
* pitti activates screen logging
<seb128> pitti: it worked fine my desktop and and ronne 
<seb128> maybe it was a case of stuck on dpkg
<pitti> seb128: entirely possible; please just re-tag it for now
<seb128> pitti: I retraced it there I wanted to do some gdb printing anyway
<pitti> seb128: I have logging enabled now, so in the future I can tell more
<Hobbsee> when's that freeze lifting?
<seb128> ok
<seb128> Hobbsee: when beta is available?
<Hobbsee> seb128: well, yeah.  but any ETA on that?
<seb128> Hobbsee: when it's ready? ;) dunno ... 
<seb128> Hobbsee: today
<Hobbsee> today being....right
<Tonio_> heno: http://ubuntu.tonio/homelinux.org you'll find src and i386 package there
<Tonio_> http://ubuntu.tonio.homelinux.org sorry :)
<heno> Tonio_: great, thanks
<heno> Tonio_: seems to work well. Are you planning to put it on the CD?
<Tonio_> heno: nope, since it'll probably be a bit late to get it in main....
<Tonio_> heno: we'll discuss that for feisty+1
<Tonio_> heno: also, we are running out of space on the cd
<heno> Tonio_: yep. I can suggest a few tweaks for it for feisty+1
<heno> Tonio_: it's 60k :)
<Tonio_> heno: me too, as for the fonts scalling etc... :)
<Tonio_> hum, true, but we are currently counting the bits hehe :)
<heno> and layout options
<Tonio_> heno: want to discuss this on #kubuntu-devel with Riddell and I ?
<heno> yep
<cjwatson> dholbach,Riddell: I've merged debconf from Debian and it's in the unapproved queue for post-beta; I'll close the bugs currently on debconf, but I think those already assigned to libqt-perl should stay open there as there's clearly a bug there
<cjwatson> apparently if you initialise the Qt perl module but then don't do anything with it, it segfaults
<cjwatson> (on destruction)
<StevenK> cjwatson: Nice!
<cjwatson> I think it's a *bit* more complicated than that, as it doesn't reproduce with entirely trivial scripts
<StevenK> cjwatson: I remember readline perl-perl doing that, but that's a *nasty* bit of Perl.
<cjwatson> $ perl -MDebconf::FrontEnd::Kde -e '$frontend = Debconf::FrontEnd::Kde->new; $frontend->init_kde'
<StevenK> Well, something similar.
<cjwatson> DESTROY created new reference to dead object ' Qt::SpacerItem' during global destruction.
<cjwatson> that's probably a starting point to reproducing it
<tepsipakki> is this bug 68267?
<Ubugtu> Malone bug 68267 in xorg "x11-common loop asking 'Please enter an integer between -20 and 19.' at debconf medium or higher" [Medium,Confirmed]  https://launchpad.net/bugs/68267
<tepsipakki> cjwatson: ^^
<cjwatson> it's one of the side-effects of that. x11-common was buggy in its own right
<tepsipakki> ok
<cjwatson> tepsipakki: I thought that bug had been fixed in xorg ...?
<Riddell> cjwatson: thanks, looking at that is high up on my todo list for post-beta work
<tepsipakki> cjwatson: nope
<tepsipakki> cjwatson: I'll poke the XSF dudes again for their feedback
<cjwatson> tepsipakki: has anyone got a DEBCONF_DEBUG=developer log of that yet?
<cjwatson> the discussion on the bug appears to be mostly debugging by guesswork and isn't obviously helpfulu
<cjwatson> -u
<tepsipakki> true, there are no logs available
<tepsipakki> lunch ->
<cjwatson> or even a way to reliably reproduce it
<pitti> seb128: ah, I found out the reason for the dpkg hangs
<seb128> pitti: ah?
<pitti> seb128: it affects packages which ship files not owned by root
<pitti> seb128: dpkg tries an fchown() on them, that fails, and then it segfaults
<pitti> seb128: and it seems to try that in a loop
<iwj> Freaky.
<seb128> utch
<iwj> Is this bug 94764 ?
<Ubugtu> Malone bug 94764 in dpkg "After dist-upgrade dpkg crashed (Dapper to Feisty)" [Medium,Unconfirmed]  https://launchpad.net/bugs/94764
<pitti> iwj: well, it fails because it's fakeroot
<iwj> Ahm.
<iwj> Probably not then.
<pitti> iwj: I'm abusing dpkg in horrible ways which are probably not relevant to real systems
<iwj> OK, I'll still put 94764 down to hardware then :-).
<iwj> pitti: Mmm.
<StevenK> pitti: dpkg is telling you to please make the pain stop. :-)
<pitti> but in chroots I should probably not care about using dpkg at all, and just unpack it manually
<hunger> Does madwifi work again with the -12 kernel series?
<pitti> seb128: ok, I guess I'll fix that once and for all now instead of continueing to hand-hold the digger
<seb128> ok
<seb128> lunch time here ;)
<cjwatson> tepsipakki: patch in the bug which I think is more correct
<aki_scorpion> hiya ... :)
<aki_scorpion> hey is this the right place to talk about SoC ... Pyracy tools
<aki_scorpion> oops privacy tools
<tepsipakki> cjwatson: thanks, noticed the latest entry ;)
<pitti> dholbach: sorry, most of the retraced bugs are really crappy; those who are a month old apply to an older gnome release, thus there's nothing to rescue any more :(
<_ion> Bug #94239 is somewhat serious-ish. In the right conditions (and a crafted tarball), the version of atool in feisty (and all earlier releases) may essentially rm -r /
<Ubugtu> Malone bug 94239 in atool "Current version may cause files to be deleted inadvertently" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94239
<Amaranth> _ion: yikes
* mvo hugs StevenK for fixing the can-not-install bugs
<siretart> mvo: may any developers edit https://help.ubuntu.com/community/FeistyUpgrades to link/warn of upgrade issues and/or bugs? I'd like to have a warning about bug #75681 in the release notes...
<Ubugtu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<pitti> Mithrandir: ok to flush-syncs and have some items in the unapproved queue? they can wait, I just don't want to forget about them
<mvo> siretart: I can do that, can you give me a one or two line summary that I should put in?
<siretart> mvo: "if you are running your root filesystem on lvm and/or raid, please don't upgrade to feisty as your system might not be able to boot."
<mvo> siretart: urgh, is it that bad?
<siretart> mvo: see bug #75681 
<Mithrandir> pitti: sure, no problem
<Ubugtu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
<siretart> mvo: I have to drop to initramfs shell and start up my raid and lvm volumes by hand in order to boot my workstation
* mvo reads the bugreport
<siretart> bug #38409 is pretty critical as well, imo
<Ubugtu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
<siretart> fabbione: any news about that one? ^^
<Fujitsu> Doesn't 38409 kill off your VG?
<siretart> Fujitsu: sometimes. I have to restore the cfg backups from dapper live cd
<Fujitsu> Has lvm2 been put back on the Live CD for Feisty?
<siretart> Fujitsu: not that I knew. it was a deliberate decision to take it out I think. however you can install it via apt-get
<Fujitsu> Not nice if you have no network connection, really.
<siretart> true
<mvo> siretart: thanks, added
<siretart> perhaps one should do a 'server rescue ubuntu live cd edition' or something with mdadm and lvm added
<siretart> mvo: thank you!
<Fujitsu> It's somewhat irritating if you're using WPA and stuff up LVM (although NM-by-default helps that)
<Fujitsu> Why would it have been removed?
<sistpoty> pitti: can you please route supertux-stable through new? UVFe: bug #94417. It's basically supertux from debian/unstable, whereas feisty's supertux is the newer (and from upstream unsupported version) from experimental. thanks
<Ubugtu> Malone bug 94417 in supertux-stable "UVF-exception: supertux-stable" [Undecided,Confirmed]  https://launchpad.net/bugs/94417
<siretart> Fujitsu: because of space constraints and because of bad interaction with ubiquity
<Fujitsu> 305k is too big? Interesting.
<cjwatson> Fujitsu: it was removed from the standard installation as it didn't belong on everyone's desktops, and never explicitly put back in for liv
<cjwatson> live
<siretart> cjwatson: can we add it back for feisty's live seed?
<racarr> Why would https://launchpad.net/ubuntu/feisty/+source/beryl-settings-simple/+builds?build_state=all fail to build on amd64 complaining XML::Parser is needed for intltool, but build fine on i386 (same dependencies obviously)
<Hobbsee> pitti: https://beta.launchpad.net/ubuntu/+source/kdar/+bug/94274  - kdar doesnt seem to build with any recent release of kdar at all.
<Ubugtu> Malone bug 94274 in kdar "please remove kdar (source and binary) from the archive." [Undecided,Needs info]  
<pitti> Hobbsee: right, but is it easily fixable? and is the package useful?
<Hobbsee> pitti: no - i think about 3 people have tried.  it used to be advertised as not compatible, it's only semi-compatible now, iirc.  and this is backup software - i'm not sure that we want a few bits shoved together and manhandling the deps
<pitti> Hobbsee: ok, then I'll remove it; you take the bullets ;)
<Hobbsee> pitti: :) okay
<Hobbsee> pitti: i keep getting blasted over it anyway, as i was the last to upload it, or one of the last.
<pitti> swoosh, it's away
* Hobbsee appears to keep getting bulleted anyway
<Hobbsee> hooray!
<seb128> pitti: we can sync main packages during freeze?
<seb128> pitti: I was not sure, I didn't sync ndesk-dbus wednesday because of that
<pitti> seb128: sure, they'll get stuck in unapproved just like any other upload
<seb128> pitti: they are on -changes
<seb128> ok
<pitti> seb128: and Mithrandir is fine with the queue filling now
<seb128> well, other uploads don't show on -changes
<seb128> so I was not sure
<pitti> hm, maybe we're unfrozen again?
<seb128> danke
<Mithrandir> I'm just going to do q -Q unapproved accept anyway, so whether there are one or a hundred things is at that point irrelevant.
<Mithrandir> pitti: no, we haven't.
<seb128> pitti: no, all the things I synced from universe showed on -changes also
<pitti> I do hope that sync-source is a normal upload instead of some 'sidetrack the unapproved queue' magic...
<pitti> urgh
<seb128> well, normal uploads don't show on the changes los
<seb128> list
<pitti> indeed
<bddebian> Heya
<seb128> so can we sync main during freeze or not?
<cjwatson> siretart: *shrug* you're in core-dev, so you can commit to the seeds
<seb128> just to know for next freeze
<cjwatson> I don't feel all that strongly about it as long as you don't cause the images to overflow too badly
<pitti> seb128: I guess not
<pitti> seb128: I thought they would be held in the queue
<seb128> pitti: ok
<siretart> cjwatson: I'm not entirely sure about the implications (read, what gets broken if I do that), and I haven't had enough time to rebuild test live cds myself, so I refrained up to now
<cjwatson> siretart: the live CD will boot more slowly for everyone because it'll try to check LVM at boot
<cjwatson> basically the same reason we removed it from desktop
<pitti> Tonio_: klavier is not in NEW
<siretart> cjwatson: perhaps some day I find out how to make a 'sysadmin recovery' editon of the ubuntu live cd ;)
<pitti> sistpoty: supertux-stable it's not in the new queue
<Tonio_> pitti: hu ?
<pitti> sistpoty: oh, wait, now it is
<Tonio_> pitti: klavier_0.3-0ubuntu1_source.changes is NEW
<Tonio_> pitti: email sent 02/22/07
<sistpoty> pitti: ah, k. thanks
<pitti> Tonio_: oh, right, it's here now; seems to have been a glitch in the queue tool
<Tonio_> pitti: okay ;)
<BenC> Mithrandir: ping, who's doing the beta release notes?
<Mithrandir> BenC: they're on the wiki, if you want something in them, add it there.
<BenC> Mithrandir: added a note about bug #84964
<Ubugtu> Malone bug 84964 in linux-source-2.6.20 "Crash from ide_pci from generic.ko for jmicron controllers" [Critical,Fix committed]  https://launchpad.net/bugs/84964
<pitti> Mithrandir: we can't actually find printers with avahi ATM, I remove that, ok?
<Mithrandir> pitti: we can't?  Don't tell my home printer.
<pitti> Mithrandir: really? how does that look?
<Mithrandir> pitti: I can give you a screenshot when I get back home?
<pitti> we only support cups browsing ATM, cups doesn't know about avahi AFAIK
<pitti> Mithrandir: sure
<pitti> Mithrandir: thank god we do not advertise compiz in the release notes ;)
<Mithrandir> pitti: shhh!
<iwj> `mdadm segfaults on my machine sometimes'  Oh FFS
<pitti> iwj: apport! :)
<pitti> (0.70 will actually ship a CLI frontend for servers)
<Treenaks> pitti: whoo!
<thom> pitti: sweet
<iwj> pitti: In the initramfs.
<pitti> iwj: <marketingspeech>that'll be supported in the next version
<bddebian> Anyone:  uswsusp was updated in Ubuntu to use libusplash-dev but now the Debian package has added libsplashy-dev.  Any suggestions on how to handle that?  Rip out libsplashy and re-add libusplash or is libsplashy moderately compatible?
<sn0> hey peeps, noticed a possible typo on the WinFOSS, wondered where i would file a bug against it?
<sn0> it says 6.06 on the title bar :) (kubuntu ubuntu i386/amd64)
<cjwatson> initramfs> that woulld just need /var/crash to exist in the initramfs and something to copy the crash reports over, wouldn't it?
<cjwatson> sn0: bug already exists
<cjwatson> sn0: https://bugs.launchpad.net/ubuntu-winfoss/+bug/71119
<Ubugtu> Malone bug 71119 in example-content "Version numbers are wrong on 6.10 LiveCD" [Low,Confirmed]  
<cjwatson> (they're still wrong on 7.04 ...)
<pitti> cjwatson: hm, and /proc (not sure whether we have that) and the apport package including python etc.
<cjwatson> oh, Ubugtu is unhelpful, but you want https://launchpad.net/ubuntu-winfoss
<sn0> yea its the same on the latest beta candidate, i will add to that one thx cjwatson 
<cjwatson> pitti: ah, python would be awkward
<cjwatson> sn0: I don't think it needs a "me too", it's been confirmed on feisty herd 5 already
<sn0> h'ok :)
<sn0> i will scuttle behind the rock i came then
<sn0> cheers
<cjwatson> heno: can we get that fixed for final please?
<heno> sn0, cjwatson: I have it fixed here. Will upload after beta is out
<sn0> woo :)
<cjwatson> ah, great, thanks
<sn0> i noticed that windows vista one, might be able to test that later on another system
<sn0> bug 61575
<Ubugtu> Malone bug 61575 in ubuntu-winfoss "OpenCD doesn't work in Windows Vista" [Undecided,Unconfirmed]  https://launchpad.net/bugs/61575
<sladen> bddebian: ideally it should figure out which is preferred, so  build-dep: libusplash-dev | libsplashy-dev  then detect which headers are available and build for that, I guess.  Or just change it for the Ubuntu environment and rip out splashy references
<sladen> bddebian: you need to preserve the Ubuntu changes in this case
<bddebian> Ugh, thanks sladen
<Treenaks> hmmm.. does this logo look familiar? http://www.fysioforum.nl/e107_themes/exas_fysio/images/logoleft.png
<sladen> pitti: what happened to pmount?
<pitti> sladen: it's pretty much obsolete in Feisty
<sladen> pitti: yeah, noticed that it wasn't even installed when I tried to run it.  Replaced by hal?
<pitti> sladen: right, by hal's mounting backend
<pitti> in edgy, pmoutn was hal's mounting backend, but feisty hal's backend is sane enough now
<sladen> pitti: y'okay.  thanks
<pirast> hi
<pirast> wrong window
<pirast> sorry
<dholbach> hi pirast :)
<sladen> mjg59: ah, one for you  bug #94911
<Ubugtu> Malone bug 94911 in usplash "[apport]  usplash crashed with SIGTRAP at vesa_setmode->LRMI_int->run_vm86" [Medium,Unconfirmed]  https://launchpad.net/bugs/94911
<mjg59> Crashing in BIOS code? Turns out to be hard to fix.
<sladen> mjg59: can it be hooked, caught and just "failed" rather than leading to a crash?
<mjg59> No
<mjg59> Eh.
<mjg59> You could have a sigsegv handler.
<mjg59> But that is clearly not the right answer
<sladen> vesa_setmode() could catch SIGTRAP before lrmi is called and cleanly exit on failure/trap
<mjg59> I'm not sure how this is preferable
<mjg59> The code either crashes or it doesn't
<fabbione> siretart: no i didn't work on lvm2 for a while.. probably iwj knows
<sladen> it's the equivalent of   try { setmode() } except { printf("failed"); }
<siretart> fabbione: I remember you told me some weeks ago that 'a fix was in the pipe'
<mjg59> sladen: The code tried to write to memory it didn't own. It really should crash.
<sladen> rather than just dying.---in which case apport catches the crash and will want to report it
<mjg59> The right fix is to tell apport to ignore it, not to pretend we're not crashing when we are
<sladen> which is pointless if there's nothing to be done about it
<fabbione> siretart: well did you check it? i know iwj did fix some race conditions between udev/devmapper and lvm2
<pitti> mjg59: you can actually do so now in 0.70
<siretart> fabbione: well, I haven't crashed my vg for some time now, but creation of lvm snapshot still fails unpredictibly
<fabbione> siretart: then i don't know sorry. i thought that the race condition fix was enough
<mjg59> pitti: Score
<pitti> enblend-3.0/VIGRA_LICENSE
<pitti> ugh, at first sight I read that all wrong...
<pirast> hi dholbach though :)
<sladen> pitti: it can be told to automatically ignore crashes within  usplash: .*run_vm86() ?
<pitti> sladen: well, usplash can ship a package hook which sets a particular field
<superm1> hey guys who should I talk with to setup a mailing list @lists.ubuntu.com?
<pitti> sladen: that package hook can examine the current crash report and decide wehther or not to ignore it
<Seveas> superm1, mailman@l.u.c
<superm1> k thank Seveas 
<sistpoty> pitti: iirc enblend is dual-licensed gpl + VIGRA (though it was some time ago when I looked over it)
<sladen> pitti: ah right, the hook goes inside the usplash package...
<pitti> sladen: right
* sladen updates the bug report further
<pitti> sistpoty: right, I just read it as 'viagra' and thought 'OMG, spam in source packages' :)
<sladen> superm1: rt@admin.canonical.com
<superm1> hm conflicting answers here?  Seveas just said mailman@lists.ubuntu.com
<sladen> superm1: is the issue-tracker for the sysadmins
<Seveas> superm1, mailman@ forwards to rt@ 
<superm1> ah okay
<superm1> that will work then
<superm1> would be that the same place to get a logging bot to join our channel?
<xerxas> pitti,  ? 
<pitti> xerxas: yes?
<xerxas> I'm using your apt source with dbgsyms 
<xerxas> but cannot run the binary 
<xerxas> do you know why ? 
<pitti> xerxas: details, please
<pitti> xerxas: 'the binary' -> the program shipped in the corresponding ubuntu package?
<pitti> that would be a bug in that package, not in the dbgsyms
<xerxas> apt-get install dhelp-dbgsym
<xerxas> root@lion:/tmp# file /usr/lib/debug/usr/sbin/dhelp_parse
<xerxas> /usr/lib/debug/usr/sbin/dhelp_parse: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
<xerxas> and I cannot execute /usr/lib/debug/usr/sbin/dhelp_parse 
<pitti> xerxas: ah
<pitti> xerxas: as the package says, those are *only* debug symbols, no executables
<pitti> you have to run the normal /usr/sbin/dhhelp_parse
<xerxas> and I will use debugging symbols ? 
<xerxas> I don't understand how 
<pitti> xerxas: by PURE MAGIC :)
<xerxas> do I need to tell gdb where they are ?
<xerxas> ok 
<sladen> xerxas: executables are in the normal packages;  the symbols are split off and placed in the -dbgsym files
<xerxas> I trust you then :)
<xerxas> I like magical stuff :)
<xerxas> that's nice 
<pitti> xerxas: or, rather, objdump -x /usr/sbin/dhhelp_parse | grep debuglink
<xerxas> I know gcc -G 
<pitti> xerxas: with this debug link, gcc will find the symbols automatically
<xerxas> ok 
<xerxas> great 
<xerxas> think I got it 
<xerxas> thanks then ! 
<xerxas> pitti,  if it worked it's suppose to show the lines of code ? 
<xerxas> I mean , the real code 
<xerxas> the C one ? 
<pitti> xerxas: the line number, yes, not the code
<xerxas> following these instructions:  https://wiki.ubuntu.com/Backtrace 
<pitti> xerxas: for that to work, you'd need to unpack the source in the same directory as on the buildd
<xerxas> I don't get more informations with installing the dbgsym package 
<sladen> Red Hat kludge all the source file locations to be  $fixed_location/packagename/path
<sladen> and the debug packages then also include any files referenced at $fixed_location/packagename/path
* sladen awaits  -dbgsrc  packages :)
<pitti> yay for archive duplication :)
<keescook> pitti: if you have a quick chance, can you process bug 95107?  That should be the last of the remaining sync requests for security updates.
<pitti> xerxas: no idea why the dbgsym doesn't work without further information; I guess I have to take a deeper look
<Ubugtu> Malone bug 95107 in libwpd "Please sync libwpd (main) from experimental (0.8.9-1)" [Undecided,Confirmed]  https://launchpad.net/bugs/95107
<xerxas> no so magic ;)
<pitti> keescook: oh, right, I saw that vuln; but there was no sync request some hours ago
<xerxas> not 
<keescook> pitti: yup, I just added it.  I went through my list of outstanding feisty stuff that I built up during the beta freeze.  :)
<pitti> keescook: done
<keescook> pitti: great! thanks.  :)
<sladen> are we out of beta-freeze now?
<pitti> sistpoty: why should we introduce an older version of supertux, when a newer one is already in the archive?
<sistpoty> pitti: because the newer version is unsupported from upstream (and not yet stable), and upstream kindly asked us to also ship the stable versoin
<sladen> pitti: acpi-support 0.94 got stuck in the freeze
<sistpoty> pitti: see bug #84084 and https://lists.ubuntu.com/archives/ubuntu-motu/2007-February/001314.html for the discussion
<Ubugtu> Malone bug 84084 in supertux "SuperTux 0.3.0 is officially unsupported!" [Undecided,Fix committed]  https://launchpad.net/bugs/84084
<pitti> sistpoty: hmmkay
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Beta released
<heno> \o/
<sladen> wow!
<dholbach> yeeha!
<kylem> Mithrandir, rock on
<sladen> timing
<pitti> Mithrandir: congrats!
<_ion> Congrats
<Mithrandir> congratulations everybody
<sistpoty> congrats!
* pitti does the feisty dance
* pitti invents one first
<pitti> "it's just a jump to the left..."
<Keybuk> and then a step to the ri-i-i-i-i-ght
<sladen> "then pause for a day, take another jump to the left, than a jump to the riiight"
<_ion> and a little headbanging...
<pitti>  
<pitti> Mithrandir: happy 72 hour sleeping!
<doko> Mithrandir: is the archive unfrozen?
<Mithrandir> doko: no, that doesn't actually happen until tomorrow according to the schedule, in case we have to backpedal hard.
<doko> ok
<sn0> \o>
<pitti> Mithrandir: want me to stop doing source/binary NEW, since those apparently aren't affected by freezes?
<Mithrandir> pitti: no, feel free to do them
<pitti> ok
<pirast> congrats, also :)
<pirast> from me
<sn0> beta dir is empty ? :p
<cjwatson> sn0: wait for mirroring
* ..[topic/#ubuntu-devel:sladen] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Beta released, Main still frozen for 24hours
<Nafallo> hi! does anyone know about a bug where /dev/sdb is created but not /dev/sdb? ? :-/
<iwj> Nafallo: USB stick ?
<Nafallo> iwj: SCSI harddrive :-/
<iwj> Oh.
<Nafallo> the kernelmodule finds sdb[123] , and so does fdisk. they just suddently disappered when I rebooted :-/
<Nafallo> and I rebooted cause /dev/sde disappered while I was reshaping an RAID5 :-P
<Nafallo> s/an\ /a\ /
<Nafallo> I'll try to see what might have gone wrong in about 2h, when the reshape is finished.
<lemsx1> hello all
<lemsx1> something changed in the ssh client on Feisty that makes connection take 10 seconds to engage
<Nafallo> ehrm?
<lemsx1> i did a test on Dapper and one on Feisty going to the same box
<lemsx1> time ssh server echo
<Nafallo> real    0m0.810s
<Nafallo> user    0m0.024s
<Nafallo> sys     0m0.012real    0m0.810s
<Nafallo> user    0m0.024s
<lemsx1> it takes 10 seconds on Feisty and .5 on dapper
<Nafallo> sys     0m0.012sreal    0m0.810s
<Nafallo> user    0m0.024s
<Nafallo> gaah. sorry for the spam
<Nafallo> anyway. not 10 seconds :-)
<lemsx1> Nafallo: are you using IPs or names?
<_ion> Perhaps a DNS problem
<Nafallo> thats ssh ogre + ctrl+d when logged in :-)
<cjwatson> lemsx1: had some reports about that which generally seem to be due to half-broken kerberos configuration
<Nafallo> lemsx1: mdsn
<Nafallo> mdns even
<lemsx1> Nafallo: are you going to another Feisty box? try something else
<Nafallo> yes. feisty -> feisty
<cjwatson> lemsx1: it doesn't happen to everyone.
<lemsx1> cjwatson: exactly! kerberos is it. because i get: Default realm not set
<lemsx1> cjwatson: what does that mean?
<Nafallo> aha. I have kerberos turned off :-)
<cjwatson> no idea, if I'd diagnosed it I would have also fixed it
<lemsx1> cjwatson: does Feisty use kerberos?
<cjwatson> no but ssh is built with support for it so that we can kill off ssh-krb5
<lemsx1> Nafallo: how do you turn kerberos off? in the sshd ... why would different clients work?
<cjwatson> see if you have anything in /etc that looks like a kerberos credentials cache
<cjwatson> if you have it and you aren't using kerberos, remove it
<Nafallo> lemsx1: I have it off in sshd yes.
<lemsx1> Nafallo: ... well, but why would dapper clients not be affected by this (going to the same server)
<lemsx1> Nafallo: there has to be something client-wise that we can do 
<Nafallo> lemsx1: well, cjwatson is the maintainer IIRC :-)
<lemsx1> Nafallo: ahh, good to know ;-)
<racarr> did there used to be a virtual package libdbus1-dev ?
<lemsx1>         libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7cf4000)
<lemsx1> indeed
<cjwatson> lemsx1: dapper didn't have that support in the client
<cjwatson> lemsx1: I will *not* remove it - I'd rather fix it
<lemsx1> cjwatson: ah, good to know. who uses Kerberos anyway?
<cjwatson> I haven't had a chance to investigate it and I can't reproduce the problem locally
<cjwatson> quite a lot of people
<cjwatson> I didn't add it just for fun
<lemsx1> cjwatson: can't you have 2 ssh clients? ssh-client-krb5 and ssh-client ?
<cjwatson> no.
<cjwatson> hello, combinatorial explosion.
<cjwatson> that's what we used to have and it was hell.
<lemsx1> cjwatson: ah, that sux... what do you need to troubleshoot this? i can help you
<cjwatson> somebody to independently debug it and discover the solution
<lemsx1> cjwatson: -vvv does talk a lot about not default realms selected
<cjwatson> never paraphrase error messages - makes it impossible to grep for them
<lemsx1> cjwatson: perhaps there should be an option to not attempt to use kerberos auth at all
<lemsx1> debug1: An invalid name was supplied
<lemsx1> Configuration file does not specify default realm
<lemsx1> sorry about that
<lemsx1> that happens 4 times before the connection goes to another method of auth
<lemsx1> and then it works
<cjwatson> there is, but I'd rather you helped debug it rather than working around it and then disappearing ;-)
<lemsx1> cjwatson: ok, i got the source code for ssh now. i'll look through it and try to understand how it works
<cjwatson> that error is actually from the kerberos libraries (source package: krb5)
<dholbach> Mithrandir: what do you think about bug 94156?
<Ubugtu> Malone bug 94156 in gthumb "UVF gthumb: 2.9.3 -> 2.10.0" [Medium,Confirmed]  https://launchpad.net/bugs/94156
<lemsx1> cjwatson: i'll get back to you in a few hours
<lemsx1> cjwatson: ok, i'm getting them now. 16mb!
<lemsx1> sorry 12.6 ;-)
<lemsx1> cjwatson: my brain. let me go eat ... bbl
<cjwatson> lemsx1: do you have /etc/krb5.keytab?
<cjwatson> or /etc/krb* in fact
<lemsx1> cjwatson: no krb* files in /etc here
<lemsx1> cjwatson: this is a clean Feisty install (i have 3 PCs with clean Feisty installations here)
<cjwatson> odd
<Seveas> Mithrandir, congratulations on getting the beta out the door!
<lemsx1> cjwatson: should that file be there?
<lemsx1> cjwatson: hey, but dapper's ssh client did have libkrb5.so.3 linked as well...
<cjwatson> oh, the default for GSSAPIAuthentication didn't change until feisty though
<lemsx1> cjwatson: no /etc/krb* on that dapper box either
<cjwatson> no, that file shouldn't be there AFAIK, I just wanted to know
<lemsx1> cjwatson: oh, so now we are narrowing the problem down
<cjwatson> the first error has the symbolic name GSS_S_BAD_NAME, FWIW
<lemsx1> cjwatson: ok. i'll be back in a bit
<cjwatson> oh, here, I can reproduce *a* problem like this with one server
<cjwatson> just seems to be doing a DNS lookup
<cjwatson> ah, I think the slowness is avahi
<cjwatson> lemsx1: strace -f clearly shows it sitting in a RESOLVE-ADDRESS query to avahi, for me
<Mithrandir> dholbach: mail me.
<Mithrandir> Seveas: thanks. :-)
<dholbach> Mithrandir: I thought that 'ubuntu-release' was the team that took care of stuff like that
<dholbach> Mithrandir: but yeah, I can close the bug and mail you everything ...
<Mithrandir> dholbach: yes, just mail me with a reference to the bug.
<Adri2000> Mithrandir: did you reject libclass-trait-perl from NEW?
<Mithrandir> Adri2000: no
<Adri2000> ah, seb128, pitti: did you reject libclass-trait-perl from NEW?
<seb128> not me
<pitti> Adri2000: I did, I mailed you
<Adri2000> I only have the rejected mail :/
<cr3> when booting from the live CD over NFS, the boot process stalls at "Running local boot scripts". Is there a way to know what's going on?
<pitti> Adri2000: 229  s  23.03.07 17:04 Martin Pitt       Rejecting libclass-trait-perl from source NEW
<pitti> TomB_: Adrien Cunin <adri2000@gmail.com>
<cr3> the other terminals aren't available, there is just a blinking underscore prompt, is that normal?
<pitti> TomB_: erk, sorry, that wasn't for you; xchat auto-expanding 'To:'
<pochu> pitti: it would be fine if apport-retrace-service attach both stacktrace and threadstacktrace in the same comment, to have less spam :)
<pochu> pitti: I can file a bug if u prefer it
<pitti> pochu: itz malone bug :/
<pitti> pochu: yes, please do
<pitti> pochu: against Malone, though; there's nothing I can do about it on my end
<pochu> pitti: though you're already doing it with crash reports, right?
<pochu> attach 8 files in the report
<pitti> pochu: yes, Malone deflates them into one mail when filing them
<Adri2000> pitti: sorry, blame gmail, he sent it to "spam" :/
<pitti> Adri2000: I try to use fewer 'p3n1s' and 'v14gr4' in my archive emails in the future :)
<Adri2000> :P
<pitti> mvo: there's no dapper-updates upload for bug 35291; is that deliberate?
<Ubugtu> Malone bug 35291 in popularity-contest "popcon tries to send mail when http submission does not succseed (was: popcon@ubuntu.com does not exist)" [Medium,Fix committed]  https://launchpad.net/bugs/35291
<cjwatson> lemsx1: does the host you're talking to have working reverse DNS?
<mvo> pitti: no, I do that in a bit
<cjwatson> lemsx1: and are you using ProxyCommand?
<nox-Hand> Hey hey
<nox-Hand> Wrong channel, topic tells me, laters! :)
<gnomefreak> pitti: do you want apport/memory bugs filed or do you know about it already?
<pitti> gnomefreak: memory bugs?
<gnomefreak> i got a trace back that ended in memoryerror
<gnomefreak> ill file it and let you know when done 
<JonRob> hi all - i'm sorry if this isn't the right place to ask
<JonRob> but i have a really puzzling question abut the ubuntu live cd
<JonRob> and am trying to get in touch with a developer who might be able to help me solve it
<JonRob> or trying to find anyone who might be able to help me solve it!
<pitti> gnomefreak: oh
<pitti> gnomefreak: then I guess it just ran out of it :)
<pitti> gnomefreak: don't bother
<gnomefreak> ah ok didnt know apport would run out
<pitti> gnomefreak: the GUI will intercept it, and for retrace there's not much else to do than to give up
<gnomefreak> pitti: ok
<pitti> gnomefreak: it's probably an endless loop in the stack trace from gdb
<pitti> gnomefreak: bzr head limits that, and thus might even fix that problem
<gnomefreak> ok cool :)
<seb128> hey, python guys
<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
<cjwatson> JonRob: what's the problem?
<seb128> 
<seb128> would you consider that a python bug?
<JonRob> making the iso with the -dvd-iso tag in mkisofs and it doesn't boot
<JonRob> yet -dvd-iso tag under knoppix boots fine
<seb128> launchpad has quite some bugs about that
<seb128> doko: ^
<cjwatson> JonRob: we don't use -dvd-iso for our images, and our mkisofs doesn't document that option
<cjwatson> so just drop that option?
<JonRob> cjwatson: i meant -dvd-video
<cjwatson> we don't use that either
<JonRob> cjwatson: do you know if it would be possible to make it work?
<cjwatson> the mkisofs man page says that you need special preparation
<JonRob> there's a good reason why i want to include it
<cjwatson> JonRob: what is that reason?
<JonRob> i'm making a dvd to promote free culture
<JonRob> i've prepared a dvd that will play in your dvd player some movies that introduce the ideas
<cjwatson> from the mkisofs man page, it looks like the DVD-Video requirements are quite strict, and I don't think we can meet them
<JonRob> and then loads of other free cultural media for you to watch on your computing
<JonRob> but i'd like to include a gnu/linux live cd for people to try to
<cjwatson> all-caps filenames and that sort of thing
<JonRob> hmm ok
<cjwatson> I may misunderstand; better information welcome
<JonRob> i'm surprised it works with knoppix?
<cjwatson> I don't know much about Knoppix
<JonRob> cjwatson: no worries
<JonRob> probably best just to use knoppix then!
<cjwatson> are you creating a VIDEO_TS directory yourself?
<JonRob> how do you mean myself?!
<cjwatson> oh, I suppose it's also possible that it's incompatible with Rock Ridge or Joliet or something, although the man page doesn't say
<cjwatson> well, from the looks of things, your video files need to live in VIDEO_TS?
<cjwatson> so yourself or your software
<JonRob> yeah...i've made that directory
<JonRob> yeah software
<JonRob> has created video_ts and audio_ts
<JonRob> which i put in the dvd root directory
<JonRob> the dvd plays fine when i do it
<JonRob> but ubuntu fails to boot with initramfs saying something about jobcontrol being turned off
<cjwatson> that means that it failed to find the root filesystem
<JonRob> hmm ok
<cjwatson> you can debug this by booting with break=premount, then poke around by hand
<JonRob> what does break=premount result in?
<cjwatson> oh, hmm
<cjwatson> a shell prompt that you can use to help debug it
<cjwatson> JonRob: what version of Ubuntu is this?
<JonRob> 6.10
<JonRob> i'll take a look at break=premount but i'm not the most advanced user
<JonRob> thanks a lot for your help though
<JonRob> definatley a step in the right direction :D
<cjwatson> wonder if it's mounting it as iso9660 before trying udf
<JonRob> ?
<cjwatson> have to go out now, will look when I get back
<JonRob> cheers
<tepsipakki> cjwatson: your patch for xorg got accepted in debian ;)
<pitti> _ion: argh, the recent hw detection fixes caused a regression: I now see both the legacy and the new nvidia driver
<pitti> _ion: it seems that the new parsed-from-module product IDs overlap?
<cr3> anyone happen to know where respawn is defined, as used in /etc/event.d/tty1? I'm getting "Unknown stanza" but that's probably because of my setup
<pitti> cr3: /etc/inittab
<pitti> cr3: oh, sorry, that was until dapper; now we have upstart
<cr3> pitti: sorry, I forgot to mention I'm using feisty-beta
<cjwatson> tepsipakki: oh good
<pitti> cr3: sorry, I cannot find the pendant in upstart; Keybuk?
<cjwatson> cr3: it should be 'respawn' and 'exec SCRIPT' rather than 'respawn SCRIPT'
<cjwatson> we've had to change a few things to cope with that
<cjwatson> cr3: see /usr/share/doc/upstart/NEWS.gz
<Keybuk> cjwatson: we had to change things?
<cr3> cjwatson: it is, but I can't find where 'respawn' is defined. filesystem.squashfs doesn't have a binary or script called 'respawn' and the /lib/lsb/functions doesn't define it either.
<Keybuk> cr3: respawn is an upstart config directive
<_ion> pitti: Yeah, both modules are shown if both modules support a given card. It would be trivial to write code that removes any nvidia IDs from the nvidia_legacy list. Should that be done?
<Keybuk> it's defined in the upstart source code, init/cfgfile.c, cfg_stanza_respawn () :p
<pitti> _ion: I think so, otherwise it's confusing
<cr3> Keybuk: but /etc/event.d/tty1 is called by run-parts, how does run-parts know about that?
<_ion> pitti: I'll do that a bit later.
<Keybuk> cr3: err, why is it?
<pitti> _ion: people will wonder which one to take
<pitti> _ion: great, thanks!
<Keybuk> are you confusing /etc/event.d and /etc/dbus-1/event.d ? :p
* pitti has to leave now, have a nice weekend everyone!
<cr3> Keybuk: maybe I'm misunderstanding something, but filesystem.squashfs/etc/init.d/dbus contains: run-parts --arg=start $EVENTDIR || true
<thom> enjoy pitti!
<pitti> thom: and you!
<Keybuk> cr3: EVENTDIR=/etc/dbus-1/event.d
<cr3> Keybuk: and you're absolutely right! :)
<Keybuk> ( the event.d name for the upstart config directory is bad, but I've not yet come up with anything better )
<cr3> Keybuk: darn, so the problem is elsewhere.. any ideas why I might be getting "Unknown stanza" about respawn when attempting to boot the ubuntu-7.04-beta-desktop-i386 CD from NFS?
<cjwatson> Keybuk: yes; casper and finish-install
<JonRob> cjwatson: i've poked around with break=premoun option but not found anything useful looking
<cr3> Keybuk: I'm not getting any ttys so the boot process is being very difficult to debug at this point, not being able to access log files
<JonRob> got it open in a virtual machine now
<Keybuk> cr3: upstart 0.3.x will say that if it's trying to parse an upstart 0.2.x config file
<Keybuk> cjwatson: oops, sorry about that
<Keybuk> I'd forgotten the installer wrote files there
<Keybuk> cr3: the config file probably says "respawn SOMETHING" no?
<cjwatson> cr3: you certain that's beta? I thought I fixed that in casper 1.83 just before beta
<Keybuk> e.g. respawn /sbin/getty ...
<cjwatson> JonRob: what mkisofs options are you using?
<cr3> Keybuk: nope, just respawn and I'll get the exact line as I attempt to see it fly by the screen again :)
<JonRob> cjwatson: the command i'm using is...
<cr3> Keybuk: init:/etc/event.d/tty1:15: Unknown stanza
<Keybuk> cr3: "initctl version" says?
<cr3> Keybuk: so I was only assuming that line 15 was "respawn" as gathered from filesystem.squashfs. 
<JonRob> ... mkisofs -r -V "FreeMe" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o /path/to/output /path/to/folder
<JonRob> cjwatson: with -dvd-video right after mkisofs
<JonRob> forgot to includ
<cr3> Keybuk: I don't have terminals from which to run anything, that's the crux of my problem :(
<Keybuk> cr3: I really think that the file it's erroring on has something after "respawn"
<cr3> Keybuk: so I'll try to determine what is generating files under /etc/event.d then
<thom> gar, why isn't -i default for dpkg-buildpackage
<Nafallo> *s*
<cjwatson> JonRob: how do I go about creating a trivial VIDEO_TS directory?
<cjwatson> just so that I can test this locally
* cjwatson tries dvdauthor
<elmo> is anyone else seeing gnome-terminal paste random bits of other desktops onto the terminal?
<JonRob> cjwatson: dvdauthor would be the best bet - but i think you'll need to have the files at one of the correct bitrates/sizes
<Keybuk> cjwatson: that's quite complex
<JonRob> i used mandvd frontend
<Keybuk> you need a bunch of files, and some XML to use it though :-/
<cr3> Keybuk: yep, casper-bottom/25configure_init generates: respawn /bin/login...
<JonRob> cjwatson: really appreciate your help with this :D
<Amaranth> if you want to make a VIDEO_TS directory the easiest way is to use devede
<Keybuk> cr3: that should be respawn\nexec /bin/login...
<Amaranth> it's a gtk gui on top of all those commands
<JonRob> devede is also handy :D
<jdong_> cjwatson: I'd recommend devede or tovid
<jdong_> both are great frontends (CLI and/or GUI) to dvdauthor
<cr3> Keybuk: cheers, I'll let you know how that goes in a minute or two :)
<jdong_> which I've personally found unintuitive to do by hand :(
<cjwatson> I don't actually want to bother with, you know, videos
<jdong_> lol
<cjwatson> I just want something that mkisofs won't barf on
<cjwatson> cr3: I fixed that in casper 1.83, I know I did
<Keybuk> cjwatson: the thing about dvds is that they aren't just a filesystem with some magic filenames
<jdong_> devede/tovid :)
<cjwatson>   * scripts/casper-bottom/25configure_init: Support for "respawn COMMAND"
<cjwatson>     has been dropped from upstart jobs; cope with /etc/event.d/tty* using
<cjwatson>     "respawn" plus "exec COMMAND" now instead (LP: #92928).
<cjwatson> cr3: ^--
<Keybuk> the actual position of files, etc. matters more than the filesystem structure :p
<JonRob> Keybuk: but that's what mkisofs -dvd-video option handles right?
<Keybuk> right, I just mean that having video is kinda useful :p
<jdong_> yeah, and growisofs's -dvd-compat option does the rest of the magic.
<JonRob> how does growisofs relate to mkisofs?
<JonRob> i'm looking at the man now
<cr3> cjwatson: if that's the version that should be in feisty-beta, that means I have another problem somewhere
<jdong_> JonRob: growisofs uses mkisofs on the inside for part of its job
<JonRob> cheers, yeah i've seen that now
<jdong_> or at least "can use mkisofs .... "
<jdong_> as one of its modes of operation.
<jdong_> I've had near 100% success rate using tovid to make dvd's
<jdong_> todisc -files "test.avi" -titles "Test AVI" -o out/
<jdong_> then makedvd -burn out/
<LeeJunFan_> can anyone verify with feisty that the nfs mounts in fstab actually mount before I file a bug report? To me it seems that there is no mount init script for mounting nfs shares, dapper had mountnfs.sh, and feisty has mountnfs-bootclean which says it requires mountnfs - but it doesn't exist.
<LeeJunFan_> I can mount them manually like mount /home, but it doesn't get done at boot time.
<LeeJunFan_> OIC, it's done when the device is ifup'ed, I'll have to symlink it in on this diskless client so it does it on boot instead of ifup.
<JonRob> cjwatson: have you seen the -root [dir]  command on mkisofs?
<JonRob> forget it - i need to read more carefully before speaking!
<cr3> cjwatson: I had first changed 25configure_init to substitute respawn.* for respawn\nexec... but then I saw your patch which was a bit different and yours works. thanks, I finally have a shell from which to get some diagnosis!
<cjwatson> JonRob: seems to work for me with feisty
<cjwatson> trying edgy now
<JonRob> cjwatson: with the -dvd-video option!?!?
<cjwatson> yes
<JonRob> lol ok
<cjwatson> casper has changed so it could have been accidentally fixed
<cjwatson> oh, duh, I suck, was booting the wrong image
<JonRob> lol - little things like that can drive you crazy!
<zyga> mvo: hey
<mvo> hey zyga!
<zyga> mvo: I just came across a bug in gnome-update-manager
<mvo> zyga: tell me more
<zyga> it was unable to parse a deb cdrom: line from my sources file
<zyga> the line was added via synaptic (manually)
<zyga> with yesterday's feisty alternate i386 cd
<zyga> I already removed that line but I'm confident I can reproduce this if you'd like
<mvo> zyga: interessting, can you please put the sources.list and the error message to a pastebin (or mail it to me)?
<mvo> zyga: yes! please reproduce it for me
<zyga> sure, just a sec - I'll add the cd again
<zyga> thank the maker for .viminfo :-)
<zyga> I could just undo the change
<jdong> cjwatson, if you're not terribly busy with beta stuff, can you perform backport bug 94807?
<Ubugtu> Malone bug 94807 in edgy-backports "nexuiz-data not backported with nexuiz (uninstallable)" [Undecided,In progress]  https://launchpad.net/bugs/94807
<cjwatson> JonRob: I think the problem is that udf.ko isn't in the initramfs
<Nafallo> jdong: betaisout :-)
<jdong> (data package of the already done nexuiz backport....)
<cjwatson> although I can mount it -t iso9660 without problems, but vol_id says it's udf
<JonRob> cjwatson: ok...is there anythign that can be done about it!? (and thanks a million again!)
<jdong> Nafallo, okcool :)
<zyga> mvo: http://paste.ubuntu-nl.org/11707/
<cjwatson> jdong: done
<jdong> cjwatson, thanks :)
<cjwatson> JonRob: depends how much in the way of changes you're willing to make :)
<JonRob> could you give me an idea? I've got time!
<cjwatson> JonRob: easiest approach is probably to add udf.ko to /lib/modules/2.6.17-10-generic/kernel/fs/udf/ in the initramfs
<JonRob> cjwatson: ok, the kernel wouldn't need rebuilding or anything?
<cjwatson> nope
<JonRob> i'll give it a try and see what happens...
<JonRob> if you're interested in the project at all btw, after spending all this time figuring this out! you can find it at http://questionsplease.org/freeme
<cjwatson> JonRob: the initramfs is a gzipped cpio archive; you can unpack it by 'mkdir tmp; cd tmp; zcat /path/to/casper/initrd.gz | cpio -id' and repack it using 'cd /path/to/unpacked/initramfs; find . | cpio --quiet --dereference -o -H newc | gzip -9 > /path/to/casper/initrd.gz'
<cjwatson> then just make sure you're using the udf.ko from edgy
<cjwatson> there's another possible approach by hacking the casper script, but I think this is probably easier
<JonRob> cjwatson: thanks! i'll try it and see how i get on :D
<zyga> mvo: is that all what you need?
<mvo> zyga: let me check
<cjwatson> Mithrandir: any objections to me changing casper to include the udf module in the initrd? or do you think it should go in initramfs-tools instead?
<mvo> zyga: how did you add it?
<JonRob> cjwatson: i've already got a udf.ko in the folder /lib/modules/2.6.17-10-generic/kernel/fs/udf
<mvo> zyga: or what CD did you add?
<zyga> mvo: I tried using apt-cdrom but that failed
<mvo> zyga: it lacks the components (main restricted ...)
<zyga> then I tried using synaptic -> software properties and that did work
<zyga> yeah I noticed now
<zyga> apt-cdrom was unable to identify the CD
<Mithrandir> cjwatson: we don't ship udf, nor does isolinux support udf, but udf.ko is about 115kb, so I don't really mind.
<mvo> zyga: interessting. s-p and then "add-cdrom" ? the button on the second page?
<cjwatson> JonRob: in the initramfs?
<zyga> (I think it was not aware of anything besides debian)
<cjwatson> Mithrandir: right, we don't, but it's useful for JonRob's use case
<JonRob> oh perhaps not...lol sorry i got a lil confused there
<mvo> zyga: what CD did you use? I will try to verify it here
<zyga> mvo: wait
<zyga> mvo: I tried to reproduce that but I got a working sources.list this time
<mvo> hrm :/
<zyga> I'm using daily current from yesterday, I can md5sum it if you'd like
<zyga> I'll try to use apt-cdrom again
<cjwatson> Mithrandir: I think I'll do it in initramfs-tools
<Mithrandir> cjwatson: yeah, more like "*shrug*; sure."
<mvo> zyga: did you click on the add-cdrom button? second page?
<zyga> maybe that's what caused this
<zyga> mvo: yes I did
<zyga> on the second tab
<mvo> zyga: thanks
<JonRob> cjwatson: i just copy udf.ko from /lib/modules...etc to the unpacked initrd.gz and then repack and put it back?
<JonRob> sorry for being so slow!
<cjwatson> JonRob: yeah
<JonRob> ok
<cjwatson> need to be careful, it won't be very tolerant of the initrd being in the wrong format or anything like that
<zyga> mvo: I really don't know how I got that line
<zyga> apt-cdrom managed to work this time
<zyga> but I'm after upgrade so it's not the same state now
<mvo> zyga: did you do it on a edgy system?
<zyga> mvo: no, on feisty - fresh from the cd
<mvo> ok
<mvo> thanks
<zyga> I did a clean install yesterday 
<mvo> I will try to reproduce it
<zyga> I'll be back in half an hour, good luck and thank you
<zoli2k> Hi! I would like to ask an advice about a project derived from the ubuntu distribution. In my company we develop a complete router solution based on ubuntu linux, with web interface and additional scripts. We want to sell it but not harm to the open source community.  What is the best way to form the profile of such product?
<JonRob> cjwatson: i got a problem with the repackaging
<JonRob> i got this error:
<Mithrandir> JonRob: it's a cpio archive.
<JonRob> Mirthrandir: ? I was following the command cjwatson gave me
<cjwatson> JonRob: what's the error?
<zoli2k> maybe it is not a right place, but I think here are the most competent people in open source world.
<JonRob> two seconds
<JonRob> "cpio: you must specify one of -oipt options"
<cjwatson> the command line I gave you used -o
<JonRob> yeah i thought that
<JonRob> and i put it in
<cjwatson> paste the command line you're using?
<JonRob> i'll triple check :p
<JonRob> find . | cpio --quiet -- dereference -o -H newc | gzip -9 > /home/jon/Desktop/Free\ Me/live/extract-cd/casper/
<cjwatson> JonRob: --dereference not -- dereference
<JonRob> quick spot!
<JonRob> cheers i'll try it
<cjwatson> also gzip -9 > .../initrd.gz not > .../
<cjwatson> JonRob: I've updated initramfs-tools in Feisty (once the archive unfreezes after beta) to include udf.ko in the initramfs
<JonRob> cjwatson: good to know :D
<JonRob> cjwatson: i got permission denied, even when run as sudo
<JonRob> with*
<cjwatson> sudo sh -c '...'
<kiv> hi
<JonRob> ?!
<kiv> is there a channel for security information/fixes?
<sladen> zoli2k: sounds like you want to do some co-marketing.  I'm sure the business-development team with Canonical would be very interested in doing a case-study with you
<cjwatson> (even with sudo, the redirection happens as a normal user; sudo sh -c 'COMMAND' means it all happens as root)
<JonRob> cool
<cjwatson> or easier, just sudo -s
<keescook> kiv: what are you looking for in particular?  if you want to discuss security updates, here or #ubuntu-motu is good.
<sladen> kiv: the best way to ensure that security information doesn't get lost, is to ensure it's filed on the bugtracker at  http://launchpad.net/ubuntu/+filebug
<cjwatson> since you have a space in your directory name, which is (a) best avoided, no, really, just don't, and (b) I can't remember how that interacts with sudo sh -c 
<sladen> kiv: then even if nobody's around, it won't get lost
<kiv> well, i'm just wondering why there is still no update for firefox.. it has been know for a few days and mozilla updated their builds 2 or 3 days ago
<JonRob> cjwatson: point taken...bad habits!
<kiv> the transition from 2.0.0.1 to 2.0.02 took quite long as well
<JonRob> that commands worked now tho...i'll rebuild the disc and iso and test it
<JonRob> thanks for all your help again!!
<keescook> kiv: our firefox maintainer is working on it; we've all been busy with the feisty release.  :)
<cjwatson> JonRob: great
<kiv> keescook, i can understand that, but to be honest i think security should be number one priority
<Seveas> kiv, no, not breaking working systems takes that plac
<Seveas> so firefox updates need to go through regression tests
<kiv> so the patch is quite huge? i thought it's some kind of a one-liner :)
<Seveas> no idea, I'm not the firefox guy :)
<kiv> :)
<cjwatson> kiv: firefox security updates are rarely one-liners
<kiv> ok, good to know
<JonRob> cjwatson: i've just booted it and all seems well :D
<JonRob> now i'm burning the disc to test on a dvd player
<cjwatson> great
<JonRob> how did you figure it out?
<cjwatson> tried manually mounting -t iso9660 and -t udf (I knew that UDF was the filesystem for DVDs), observed the difference in behaviour, and made an educated guess
<cjwatson> I had an up-front educated guess that it was something to do with udf anyway
<cjwatson> you can mount udf as iso9660 but it sometimes isn't what you want; casper always mounts as the detected fs type though
<JonRob> well i'm impressed!
<JonRob> been impressed with ubuntu as a whole lately
<cjwatson> thanks, but it's just experience and practice really. :)
<JonRob> well i'm heading off to test it...my thanks again!!
<JonRob> bye
<lowtek> Does Ubuntu offer a replacment like software for MS Exchange?
<lowtek> or a SMTP server
<Burgwork> lowtek: not currently
<poningru> Burgwork: actually...
<poningru> groupware and a dozen such thing
<poningru> hmm I wonder if someone has packaged calendarserver
<Burgwork> never seen it
* mvo reboot
<mdz> Riddell: are the kubuntu upgrade instructions up-to-date?
<mdz> Riddell: e.g., is edgy-proposed still required?
<shawarma> Why is it that we run scrollkeeper-rebuilddb once a month?
<shawarma> ...the man page even explicitly says it's not necessary  unless the database has been corrupted for some reason.
<JonRob> cjwatson: if you're still around; I used the wrong image, the right one didn't work :(
<JonRob> just wanted to check i put the udf.ko file in the right place
<poningru> whenever one hears the name cjwatson, one should break into the IBM cjwatson song
<JonRob> what is the IBM cjwatson song!?
<poningru> zomg
<poningru> hold on
<poningru> http://www.users.cloud9.net/~bradmcc/ibmsongbook.html
<poningru> keep in mind its Tjwatson
<poningru> but minor discrepency
<JonRob> haha ok
<poningru> hold on writing something up
<JonRob> is it my imagination or are there a lot of songs dedicated to tjwatson
<poningru> http://pastebin.mozilla.org/5054
<poningru> nope not your imagination
<JonRob> haha, so who exactly is cj? i know he was very nice and helpful to me earlier!
<mjg59> tepsipakki: Hm. X fails to start on a Macbook Pro
<mjg59> tepsipakki: It's bringing up vesa, but without a good mode defined
<mjg59> To make things more amusing, I have no login prompts
<poningru> jonibo: colin watson
<Riddell> mdz: yes, edgy-proposed it still required, but there's no problems with the packages so I'll look to get them into -updates next week
<mdz> Riddell: ok, thanks
<mjg59> Why does the CD have xforcevesa in the default command line?
<Mithrandir> it only has it if you choose safe mode, afaik?
<mjg59> If I hit F6, it comes up with that
<mjg59> Also, my missing consoles seem to be an upstart issue
<mdz> mjg59: was the cursor on the safe option when you pressed f6?
<mjg59> I get "unknown stanza" errors on boot
<mjg59> mdz: Ah, that could be it
<mdz> there was a casper/upstart issue with the consoles, but I thought it was fixed before beta
<mjg59> mdz: Doesn't /seem/ to have been
<mdz> I forget the bug number. Mithrandir?
<mjg59> X fails to start for me, and then I get no consoles to fix it...
<mbiebl> mjg59: probably the changed respawn syntax
<mjg59> Yes, it's complaining about the respawn line
<mbiebl> respawn is now a single keyword
<mjg59> mbiebl: Got it
<mbiebl> you should use exec instead
<mjg59> The LiveCD has "respawn /bin/login -f ubuntu </dev/tty1 >/dev/tty1 2>&1"
<mbiebl> ah, that should be exec /bin/login ...
<mbiebl> and a single respawn in a separate line
* mjg59 hacks
<mjg59> mbiebl: Hm. My laptop seems to have exec /sbin/getty
<mjg59> But I guess that's equivalent
<mjg59> Gah. Not that that's actually resulted in me having any terminals
<mbiebl> yeah for tty? it should be
<mbiebl> exec /sbin/getty 38400 tty?
<mbiebl> respawn
<mdz> for casper it should run login instead; the live user's password is locked
<mbiebl> I don't know the live cd, so use whatever is apt there.
<mjg59> mdz: Ok, well this is entirely broken right now :)
<mjg59> Do you want a bug?
<mdz> mjg59: I'm pretty sure there is one, looking
<mdz> mjg59: I can't find it, please do file it
<mdz> mjg59: scratch that
<mdz> bug 92928
<Ubugtu> Malone bug 92928 in casper "casper corrupts virtual consoles creation events (/etc/event.d/tty1 - tty6) " [Undecided,Fix released]  https://launchpad.net/bugs/92928
<mdz> was supposed to be fixed in casper 1.83
<mdz> ...which has been uploaded but not built
<mjg59> mdz: Beta is 1.82
<mdz> right, it must have been queued until after beta
<mdz> so it's building now
<mjg59> Oops.
<mjg59> Oh well.
<mjg59> So, now, why is X broken...
<mjg59> hsync out of range. Ngh.
<sladen> is the queue still frozen?
<sladen> in upstart, isn't 'resprawn' a separate command/config option to 'exec', which is the actual gubbins to run
<mjg59> Yes
#ubuntu-devel 2007-03-24
<StevenK> Can someone please kill the upload of list 1.9.93-1ubuntu1 from the unapproved queue? My fix in it is still prone to breakage.
<sladen> http://lwn.net/Articles/227567/#Comments  "Oh, and upstart (which is now the default) really is quite a bit faster than sysvinit.
<sladen> ...all in the psychology I tell yer
<mc44> placebo ftw
<Burgwork> yep
<_ion> Hehe
<mdz> andi5: hi
<andi5> rehi
<mdz> andi5: seb128 is the person to talk to about this, but he's in France and so hopefully asleep right now
<andi5> i am in germany, what the... ;-)
<mdz> andi5: we can surely figure something out to get gnucash working again for feisty (I'm a pretty heavy user myself), but it's not clear what the best solution is yet
<andi5> i thought about patching 2.0, but it is a much bigger change than one might expect, really
<Fujitsu> It FTBFS, doesn't it?
<andi5> yes
<mdz> andi5: I've subscribed seb128 to the bug and asked for his input there
<andi5> so i have verified that 3.13.6-0ubuntu1 has the symbol and 3.13.91-0ubuntu1 does not.... too bad that the latter still uses libgtkhtml3.8-15
<mdz> andi5: that appears to have been an upstream mistake, they forgot to update the soname
<andi5> yep
<andi5> mdz: thanks a lot :-)
<rpereira> Hi, does someone knows who is the coordinator of "Summer of Code" project on Ubuntu?
<Hobbsee> argh...why's main still frozen?
<Athensman> is xubuntu good for a 366 celeron and 256 ram??
<David_Repa_FG> Hello, BFTD from #ubuntu-women suggested I come in here and let you folks know what we are doing up here with Free Geek in Vancouver, BC, is that ok?
<adamant1988> Athensman it's great for that hardware
<glick> hi
<glick> hey can someone help me set up a driver development enviornment?
<glick> i am reading Linux Device Drivers and want to compile some of the example code
<racarr> Can someone give some beryl uploads to universe a shove in to the archive (freeze) ?
<racarr> aquamarine, beryl-settings-simple, beryl-plugins, and beryl-core
<mdz> racarr: uploads of packages which are already in the archive, during non-freeze periods, don't require any manual intervention
<racarr> mdz: I thought the archive was in a freeze right now
<mdz> racarr: we are, but only because beta just went out.  feisty will unfreeze shortly (tomorrowish)
<mdz> and everything queued will go in as normal
<racarr> Ok, will just wait then
<scorpion> heya :)
<scorpion> wanted to work for gSoC .. is this the right place to discuss for ubuntu ideas
<LaserJock> scorpion: I'm not sure if there is a specific channel for SoC or not
<LaserJock> scorpion: do you have a specific question?
<scorpion> LaserJock: I just wanted to know more about privacy tools 
<scorpion> I am eager to work on them
<scorpion> may I know if some one is working on these tools
<LaserJock> well, I'm guessing that's why it's a SoC idea
<scorpion> LaserJock: may i konw if you are a mentor
<LaserJock> scorpion: yes
<scorpion> may i know if you are into this privacy tools 
<LaserJock> not particularly
<scorpion> LaserJock: hey i was thinking of going ahead with a normal RSA encryption to encrpt the home directory by changing the key every week depending on the date
<scorpion> the home directory  is to be kept encypted untill the user wants to work
<scorpion> may i get some help on this
<LaserJock> hmm, it's late Friday/early Saturday
<LaserJock> there might not be lot of people up yet
<scorpion> thnx
<Mithrandir> Seveas: hiya, could I get Ubugtu into a channel and tell me each time somebody milestones a bug for a particular milestone?
<Treenaks> t
<scorpion> hey may i get some help on privacy tools
<Seveas> Mithrandir, maybe -- have to check whether lp sends out that info in a not-too-hard parseable way
<tepsipakki> Mithrandir: a new discover1 was released yesterday, and it's going into etch as well. Fixes at least bug #90175
<Ubugtu> Malone bug 90175 in discover1 "vesa driver used instead of radeon for R300" [Medium,Confirmed]  https://launchpad.net/bugs/90175
<tepsipakki> maybe we could have that
<tepsipakki> s/have/want/
<Mithrandir> tepsipakki: sounds useful.
<Mithrandir> tepsipakki: can you just follow normal UVFe procedures?  I try not to work on weekends..
<tepsipakki> of course :)
<Mithrandir> cheers
<StevenK> Mithrandir: Would you mind killing list from the unapproved queue (if it still lives there) ?
<Mithrandir> StevenK: as in, reject it?  Sure, I can do that.
* StevenK will upload a complete fix in a few minutes.
<Mithrandir> rejected
<StevenK> Thanks
<siretart> Mithrandir: regarding the wpasupplicant crash, I attached a changelog diff and a diffstat to bug #91676
<Ubugtu> 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
<Enola_Gay> hi all
<Enola_Gay> Why is the lowest value in power manager 11 minutes?
<Enola_Gay> It is a very, very long time imho especially with a battery.
<Enola_Gay> I am using Feisty maybe it only happens there.
<Enola_Gay> Please, at least a reason or is there a possiblity to change it without recompile parts of gnome?
<Enola_Gay> HP-Toolbox ist installed by default but couldn't be started in Ubuntu Feisty because of dependency problems.
<_ion> Hi pitti
<_ion> Please pull the changes from my branch
<pitti> hey hey
<pitti> _ion: will do
<Hobbsee> hiya _ion, pitti 
* pitti hugs Hobbsee 
<_ion> Hi Hobbsee
* Hobbsee hugs pitti :)
<ajmitch> hey pitti 
<Enola_Gay> Why is the lowest value in gnome power manager 11 minutes?
<astopy> screensaver time is probably 10 minutes
<astopy> the power manager time is screensaver+1 minute for some reason
<pitti> _ion: pulled/pushed, thank you!
<gnomefreak> pitti: when you get a minute i have a question about the corrupted coredump traceback i get here and there.
<DarkSun88> Hello
<cjwatson> JonRob: hmm, I guess depmod might need to be run or something, it's unclear
<JonRob> cjwatson: have you just got my message from earlier!?
<cjwatson> JonRob: might be easier to get a stock edgy install, install casper on it, edit /usr/share/initramfs-tools/hook-functions to find the bits that say "isofs" and add "udf" to them as well, 'update-initramfs -u', and copy the resulting /boot/initrd.img-2.6.17-10-generic to /casper/initrd.gz
<cjwatson> JonRob: I went to bed early last night, and it's Saturday today so I'm not working much
<JonRob> sure...i'm never working much :s
<cjwatson> JonRob: oh, for the record and to my knowledge, I'm no relation of T. J. Watson ;-)
<JonRob> haha ok - how have you seen all these back logs?
<racarr> Is anyone else able to use rgba colormaps with the latest version of pygtk in feisty? it works fine with GTK, but not with pygtk, and worked recently, but I can't find aynthing in pygtk that could have set it off
<JonRob> sorry - prob wrong place to ask!
<JonRob> to copy the /boot/initrd.img-2.6.17-10-generic to /casper/initrd.gz - need to be cpio again?
<cjwatson> JonRob: I leave my client connected overnight and it sits at the last place I read anything until I page down
<cjwatson> JonRob: no, it's in the right format already, and already gzipped etc.
<cjwatson> just cp will do
<JonRob> oh ok awesome
<cjwatson> Mithrandir: were you planning to unfreeze today?
* cjwatson just let through all the universe stuff in the queue, but ...
<Mithrandir> cjwatson: yeah, I guess I should.
<Mithrandir> even though I'm pretending not to look at IRC today.
<JonRob> cjwatson: could i not just edit the extracted iso?
<cjwatson> JonRob: what do you mean?
<JonRob> well, i've got the extracted iso image of the livecd with casper on it - could i not just edit the boot/initrd.img-2.6.17-10-generic
<JonRob> on there
<JonRob> if i chroot
<cjwatson> no, you can't chroot into the ISO9660 filesystem
<ajmitch> Mithrandir: good news, I have an initial fedora dir server package
<ajmitch> something to clean up for feisty+1
<JonRob> cjwatson: even after mounting and cp the files over to a temp folder?
<cjwatson> JonRob: it doesn't have e.g. /bin/sh or a C library
<cjwatson> it doesn't look anything like a Unix root filesystem - you can't chroot to it
<JonRob> ok sure
<cjwatson> not and do anything useful, anyway
<JonRob> so once i've done what you've suggested, how do i put that back in to being a livecd?
<Mithrandir> ajmitch: coolie
<cjwatson> JonRob: you copy in the updated /casper/initrd.gz and then just do the same mkisofs thing you were doing earlier
<JonRob> oh ok - wow easy :D
<JonRob> i'll give it a go
<cjwatson> that's the theory, anyway
<sabdf1> ajmitch: sweet!
<JonRob> lol ok, i'll let you know how it goes
<sabdf1> ajmitch: is that the old netscape directory server codebase?
<cjwatson> my tests used a different approach involving editing casper code to force it to mount as iso9660 instead, but mounting as udf should work fine once the kernel module is available
<JonRob> cjwatson: Before i do this - is there a quicker way than repartioning my drive for the tmep install?
<sladen> Mithrandir: unfrozen, shall I change the topic then? :)
<ajmitch> sabdf1: yep
<ajmitch> cleaned up, using autotools in cvs head
* ..[topic/#ubuntu-devel:Mithrandir] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Beta released
<sabdf1> i have an old mate who worked on it then - John Hines - any sign of him still actively committing?
<ajmitch> I haven't seen his name on the list, but I haven't been watching the cvs logs
<mr_pouit> Could someone help me for Bug #95469 ? I am unable to reproduce it in a pbuilder, it may be buildd-specific... :/
<Ubugtu> Malone bug 95469 in ucspi-tcp "[feisty]  FTBFS" [Undecided,Confirmed]  https://launchpad.net/bugs/95469
<cjwatson> JonRob: oh, you don't need to repartition - use debootstrap to create an edgy chroot
<JonRob> cjwatson: can i point it at an iso instead of downloading?
<cjwatson> JonRob: not a live CD, no
<JonRob> ok...so point it at a mirror
<cjwatson> debootstrap only installs a base system, though, and doesn't take that long. You'd just need to install casper on top of that.
<JonRob> oh ok - cool
<JonRob> i'm learning alot here!
<Mithrandir> cjwatson: can you change OFFICIAL back again now that beta's out?
<cjwatson> Mithrandir: yep
<Mithrandir> cheers
<cjwatson> done
<mdke> who knows which languages are shipped on the cd?
<cjwatson> mdke: http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.feisty/ship and http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.feisty/live
<mdke> cjwatson: thanks
<cjwatson> substitute kubuntu.feisty etc. as appropriate
<mdke> blimey some strange ones there
<cjwatson> xh is the only real anomaly; the rest are by population
<mdke> right
<mdke> although population is not necessary the same as ubuntu users
<mdke> (necessarily)
<cjwatson> that's true, but we have no fair way to measure that
* mdke nods
<cjwatson> and really, the ones that seem "odd" are probably the best targets for growth
<mdke> is producing other isos with different languages out of the question?
<cjwatson> for the core project, pretty much yes, IMO
<cjwatson> combinatorial explosion is a huge problem if you embark on that
<cjwatson> I think a more tractable approach is to continue to make it easier for locos to produce them
<mdke> agreed
<cjwatson> if I could believe that images would just work when they looked like they'd just work, maybe it wouldn't be a problem
<cjwatson> but we've had so many problems in the past with problems that we could never have anticipated following what looked like totally harmless changes
<mdke> hmm, even just with language-packs?
<cjwatson> hell yes
<cjwatson> there was the squashfs bug that only happened with live filesystems of a certain length, or something like that
<mdke> ah right
<cjwatson> while that's been fixed, it's an excellent example of how we can't afford not to at least test-boot images - and there've been similar kinds of installer problems that would have been just as bad if allowed to slip through
<mdke> makes sense
<cjwatson> like I say, if software were perfect, everything would be a lot easier ;-)
<mdke> ok, is it correct to say (on the website derivatives page):
<mdke> Due to space considerations on the Ubuntu CDs, only English, Spanish, French, Arabic, Xhosa, Bengali, Russian and Portuguese are included out of the box. Support for many other languages can be added from the internet. The following derivatives have full language support for the relevant language on the CD:
<mdke> <end>
<cjwatson> that information is very specific to certain images
<cjwatson> the seeds are mutable; they have changed and will change again
<cjwatson> I'd suggest just saying "only some languages", or else qualifying by release
<mdke> oh, ok
<cjwatson> it also depends on the architecture
<cjwatson> even amd64 and i386 have different amounts of space available for language packs
<mdke> yeah, I saw that
<cjwatson> basically we fill up whatever space is left at the end with language packs
<JonRob> cjwatson: i think i might be missing something, i've done the debootstrap and chrooted, edited hook-functions and update-initramfs -u but nothing in /boot/
<cjwatson> JonRob: oh, you need to install the kernel as well - debootstrap won't do that
<cjwatson> JonRob: install linux-generic
<JonRob> lol ok
<JonRob> yep
<cjwatson> doing that should create the initramfs for you - no need to run update-initramfs again afterwards
<JonRob> linux-image-generic
<cjwatson> add restricted after main in /etc/apt/sources.list, apt-get update, and use linux-generic
<JonRob> ok
<cjwatson> unless you're ok dropping support for stuff like atheros wireless
<JonRob> smeg...connections never seem to go thru when you want them to!
<JonRob> cjwatson: casper is installed but there's no /casper directory? create it?
<DarkSun88> Any main-sponsor out there?
<DarkSun88> could you please review bug #95238?
<Ubugtu> Malone bug 95238 in check "Please sync check 0.9.4-3 (main) from Debian (unstable)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95238
* mjg59 fixes synaptics properly
<cjwatson> JonRob: no I mean the /casper directory on the ISO filesystem
<JonRob> yeah sure - i've figured that now
<JonRob> just burning the disc now
<WaqasToor> need help with gnome localization ... where to put those files that rossetta send ... i.e. PO files
<sladen> if anyone is using binary Nvidia and has broken suspend/resume, could they test the fix suggested in bug #34043 (adding "Option NvAGP 1" to xorg.conf)
<Ubugtu> Malone bug 34043 in acpi-support "Nvidia binary driver requires Option "NvAGP" "1" for reliable suspend/resume." [Medium,In progress]  https://launchpad.net/bugs/34043
<JonRob> cjwatson: it works! just used the same disk to boot and watch videos :D
<JonRob> only problem was the graphical boot disappeared, no kind of feedback
<WaqasToor> need help with gnome localization ... where to put those files that rossetta send ... i.e. PO files
<cjwatson> JonRob: oh, you maybe need to install usplash and usplash-theme-ubuntu and regenerate the initramfs again. sorry, forgot that
<JonRob> lol no problem - just awesome that it works!
<JonRob> thanks for all your help with this - know it's not exactly a common use case :p
<WaqasToor> any body ??????
<superm1> BenC, ping
<BenC> superm1: pong
<superm1> heya BenC, i wanted to ask you about the possibility of building lirc modules off the kernel build process now.  keescook and i straightened out the lirc package a few weeks ago, and now everything builds cleanly on feisty kernels (except parallel since its not smp safe)
<superm1> the problem before was that i2c and gpio were badly broken when i last brought this up in edgy
<BenC> superm1: If you can provide a patch to put it in ubuntu/ in our git tree, I can maybe do it
<superm1> okay, i'll look to see how bad it is to make it into a patch
<DarkSun88> Any main-sponsor out there?
<bf> where (in launchpad?) can i see a list of bugs in feisty?  https://bugs.launchpad.net/ubuntu/feisty/+bugs  only lists 9 (?!?)
<superm1> appears that we are doing a pretty good job ;)  i think those are just bugs that are specifically associated with the feisty release
<bf> yeah, is there a place to see roughly what's left?
<superm1> afaik, just using https://bugs.launchpad.net/ubuntu/+bugs is the only way to see all of the bugs, because some may have been reported in say edgy, but are still troubles in feisty
<bf> interesting.  so by that theory, the 9 listed in feisty are the only regressions?
<superm1> well not necessarily.  if someone is to report a bug during feisty, but not mark feisty as a release, it may still be a regression
<Enola_Gay> hi all
<cjwatson> bf: we don't actually really use /ubuntu/feisty/+bugs - only confused people use that :)
<cjwatson> for the mainline development branch we just use /ubuntu/+bugs
<cjwatson> but https://launchpad.net/ubuntu/+milestone/ubuntu-7.04 may be what you're actually looking for
<cjwatson> the targeted features there haven't been triaged, though, so ignore them
<bf> cjwatson: thanks!
<yacoob> Hi. Does upstart, as it is right now in Edgy does something more than old init-based config did?
<beuno> yacoob: I don't think so no. It starts using some event based scripts in Feisty
<yacoob> beuno, can you give me some examples?
<beuno> yacoob: sadly, no, I'm no expert
<beuno> but I'm sure you will get a good response from their mailing list
<yacoob> I just pranced around /etc/event.d, and discovered that there's nothing special about it... :)
<beuno> it's a long-term effort
<beuno> if I recall correctly, feisty+1 will only event-based in startup
<fabbione> it's a process that takes time to evolve
<fabbione> changing everything cannot be done overnight
<fabbione> specially if you think how many packages you need to change, test and merge
<fabbione> you ought be patience young padowa
<yacoob> I'm in no hurry, rather curious.
<yacoob> but basically I got my information I was lacking.
<yacoob> It will require extra extra work, because debian would probably stick to standard init scripts
<beuno> yes, it seems so, but since we're getting more and more distros based off Ubuntu, who knows  :D
<fabbione> yacoob: debian will probably support both at some point
<fabbione> and stick with both forever
<fabbione> the point is that you can theoretically support both from a standard package point of view
<fabbione> the issue is that you can't have upstart and sysvinit installed at the same time
<yacoob> sure, but I'd like to see the stick you use in order to beat packagers to do the extra work :>
<fabbione> yacoob: there is no stick.. otherwise it would have been done for edgy :)
<fabbione> it's on a best effort base
<fabbione> if somebody will force a change then he/she will also do all the changes :)
<yacoob> appologise me for being sarcastic, lately I've been a bit dissapointed about debian :|
<fabbione> yacoob: sarcasm is ok.. sorry i might not have catch it
* fabbione is dead tired after an entire day babysitting a little terrorist
<lifeless> fabbione: dude, you MADE that terrorist
<fabbione> lifeless: i know..
<lifeless> we should call you osama
<lifeless> ;)
<fabbione> ehehhe
<robertj> ajmitch: is anything going on with authtool these days?
<ajmitch> yep
* ajmitch has set aside this weekend for hacking on that sort of thing
* LaserJock kicks ajmitch 
<robertj> where does that code live?
<LaserJock> in ajmitch's head
<ajmitch> haha
<ajmitch> LaserJock: I said kick me to remind me later :P
<robertj> is there an arch repo with something newer than .2 ?
<ajmitch> last night I was busy with other important stuff :)
<ajmitch> not really, wait a day & I'll update & push the latest
<ajmitch> robertj: what do you need from it, specifically?
<robertj> nothing, just interested
<ajmitch> ok
<robertj> I've just got a vendetta against auth guis after dealing with OS X server
<robertj> (as soon as my funding comes through, hello vmware)
<ajmitch> hah
<ajmitch> so you're looking for something else to hate :)
<ajmitch> especially as the ui in the authtool in feisty sucks, badly
<robertj> vmware has been fine, I've already got my edgy smb vm all set up, I just need a machine with 1.5 tb to put it on
<ajmitch> hm, that's a fair bit
<robertj> ajmitch: I was just thinking that disclosure triangles could'nt be long in coming
<ajmitch> oh no, I've been reworking the GUI so it doesn't suck
<robertj> going to support sub-ous on A?
<robertj> err AD?
<ajmitch> problem is that it's only partly there, and I needed to do some fixups today to get something else uploaded
<ajmitch> if possible, and if I know how :)
<robertj> ajmitch: on the command line net ads join gets replaced with net ads join myou, and optionally you have some ldap prefix foo that gets added to smb.conf
<ajmitch> alright, thanks
<robertj> vital for me because I don't have access to add outside my sub ou, so I can't join machines to the domain unless i put em in the sub ou. I'm sure most computer labs using active directory in education would have similar needs
<ajmitch> ok
<robertj> does Workgroup make sense in the context of AD?
<ajmitch> most things don't
<ajmitch> most of the stuff there doesn't need to be asked
<ajmitch> or can be guessed & changed later
<robertj> domain, user, pass, and advanced/more/whatever hig dictates
* ajmitch will come back to this later, must go out now
<mdke> where are the xubuntu isos? the links on the beta announcement are broken and I'm looking for the right ones
<mdke> I can see edubuntu/kubuntu here: http://releases.ubuntu.com/releases/
<cjwatson> http://cdimage.ubuntu.com/xubuntu/releases/feisty/beta/
<cjwatson> it's linked from the front page of releases.ubuntu.com, too
<mdke> cjwatson: thanks, will update
<mdke> cjwatson: any reason there isn't a link on that url I posted above, like for the others?
<cjwatson> there is
<cjwatson> "Although they are not directly supported by Canonical, releases of Xubuntu are available from the cdimage server."
<mdke> oh, I thought xubuntu was supported
<cjwatson> it's not in the directory listing there because it's not served from releases.ubuntu.com.
<cjwatson> no
* cjwatson <- gone
<lengau> Hi.
<lengau> does anyone know where I can find that recommendation to install some form of revision control in a future Ubuntu for the home directory (makes it something like Time Machine on Mac)
<LaserJock> lengau: the SoC project ideas page?
<lengau> @LaserJock - Thank you! That's where it is!
<Tonio_> hi
<Tonio_> I just saw my aquamarine upload was rejected.
<Tonio_> current package ftbfs due to missing autoconf and automake builddep
<Tonio_> Mithrandir: any idea why it was rejected ?
<superm1> BenC, I have a patch almost ready that i wanted to try for lic, but i can't debuild locally here since it appears whenever i increment the chanelog, it wants a copy of 2.6.20's abi in debian/abi
<superm1> s/lic/lirc/
<Mithrandir> Tonio_: because another version was already accepted.
<Mithrandir> Tonio_: hm, no, sorry, I'm not sure, that was something else.
#ubuntu-devel 2007-03-25
<Tonio_> Mithrandir: I'mm make a point and eventually reping you on monday if there is no other package accepted in the archives :)
<Tonio_> s/mm/ll
<Tonio_> Mithrandir: probably another package accepted, since there is no reason to reject this appart from that
<Tonio_> Mithrandir: the only thing I changed is add missing builddep to fix ftbfs
<BenC> superm1: Don't rev the changelog
<superm1> Benc, I saw https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28kernel%29 after pinging you
<BenC> superm1: Your patch should not touch anything in debian/* (at least what you send me shouldn't)
<superm1> i'm building that way locally
<BenC> no need, that's meant for people who want to keep their changes even after an update from the repo
<superm1> oh?
<BenC> s/repo/archive/
<superm1> well whats the appropriate way to make sure this patch builds right then?
<BenC> superm1: the parts to change the changelog are for when you don't want ubuntu kernels to overwrite your own
<BenC> superm1: apply patch, "fakeroot debian/rules binary-debs flavours=generic"
<superm1> okay thats what i was doing 
<superm1> BenC, and if the build fails, is there an easy way for me to make it pick back up where it left off after fixing the file?  (hasn't gotten to the ubuntu/* directory yet, but in case it does)
<superm1> i'd imagine debian/rules binary-debs calls debian/rules clean first
<glick> hi
<Hobbsee> mpt: +1 at the suggestion to remove the "report a bug" option.  although kde does it.
<mpt> Hobbsee, oh, I got moderated through to ubuntu-devel@? yay
<Hobbsee> mpt: seems so.  if you only sent it to -devel that is
<Hobbsee> yep, you did
<glick> hey can anyone recommend any reading for someone wanting to get started in kernel devel?
<Hobbsee> glick: probably ask someone like BenC or look on the wiki
<Hobbsee> not sure where exactly, as i dont do kernel stuff
<Hobbsee> or see #ubuntu-kernel
<glick> hmm thanks
<glick> whose BenC ?
<mpt> Ben Collins, Ubuntu kernel maintainer
<glick> cool
<Fujitsu> mpt: We haven't had a whole lot of bugs from the menu option yet... But that's probably because the current audience is more technically competent.
<Hobbsee> we stiill get some really...stupid...bugs though
<Fujitsu> We're always going to get really stupid ones.
<mpt> Fujitsu, there's a useful difference between "lots of stupid ones" and "a few stupid ones" :-)
<Fujitsu> True.
<pax> stupidity keeps the balance, without it the 'haves' will have nobody to impress. The 'have-nots' nobody to blame.
<Fujitsu> Well, actually, not really. We already have 25000 bugs open now, a few thousand extra won't make a difference.
<Burgundavia> keescook: you around?
<benb> where is the best place to read about becoming a developer for ubuntu?
<benb> note to self...  read the topic
<sladen> benb: :)  Yup, and hit the wiki (google for  ubuntu motu)
<NoSense> hi
<NoSense> my ps/2 doesn't work in feisty fawn beta
<NoSense> ihave only upgraded from edgy
<Fujitsu> This isn't a support channel, NoSense. Try #ubuntu+1
<NoSense> thanks, but it can be a bug
<bluefoxicy> oh
<bluefoxicy> the ps/2 thing is probably.. no, nevermind.  It's not that.
* bluefoxicy has been alternating kernels because every other upgrade breaks his USB optical mouse.
<bluefoxicy> been meaning to mention that but haven't gotten around to it.  Anyway.
<desrt> nice to see the archive grind to a halt as feisty beta gets dugg :)
<Burgundavia> heh
<Fujitsu> Hehe, it'd be nice to have traffic graphs around releases.
<jhernandez> Hi :)
<jhernandez> I have a problem with my deb package, all my files are installed in / directory.
<Admiral_Chicago> can someone point me to the bazaar branch for apport?
<Admiral_Chicago> wait, google did
<zyga> hello
<doko> Mithrandir: please could you requeue glibc/amd64 on another buildd? the build failure is unreproducible on ronne
<eternalswd> Just wondering about coreutils version numbers.  Feisty has 5.97 as it's package version but the most recent stable version available at the gnu site is 6.9  Is this just a version numbering issue where ubuntu numbers it differently, or is that particular package really that far behind?
<Mithrandir> doko: no, it's a kernel limitation; fix scripts/check-local-headers.sh to use xargs.
<doko> Mithrandir: so why do we have to make such changes during release phases? ...
<Mithrandir> doko: I have no control over which kernel the buildds run.
<Mithrandir> doko: also, it seems it died of inactivity.  It was probably hung.
<doko> Mithrandir: correct, the scripts/check-local-headers.sh is unrelated; it's a parallel build.
<Mithrandir> doko: but that's an error too. :-P
<Mithrandir> (and should be fixed)
<doko> Mithrandir: maybe, but it's not the cause for the build failure
<doko> Mithrandir: please requeue to check if the timeout is showing up on another buildd
<Hobbsee> Mithrandir, or any other archive admin, when you have time/inclination, could you shove the rest of the beryl stuff?  i think it's in binary NEW, and i'm wondering how much crack's in it.
<Mithrandir> Hobbsee: doing so already
<Hobbsee> Mithrandir: thanks :)
* Hobbsee hugs Mithrandir 
<Mithrandir> (-:
<racarr> Thanks
<Hobbsee> Mithrandir: any chance you could push through kuickshow as well please?  :)
<ajmitch> you're asking for a lot today
<Hobbsee> ajmitch: yes, i'm mean, like that.
<ajmitch> heh :)
<tsmithe> Mithrandir, do you know why wired was rejected?
<Mithrandir> tsmithe: no, the uploader should have been mailed by the archive admin doing the rejection.  I can ask who did it tomorrow.
<Mithrandir> Hobbsee: already done.
<tsmithe> Mithrandir, cheers.
<tsmithe> Adri2000 should have been pinged, but he's been away for a while
<Hobbsee> Mithrandir: great, thanks :)
<tsmithe> Mithrandir, do you know of any case where that mail would not get sent. it would seem Adri2000 got nothing
<tsmithe> (he uploaded ubuntu2, but both ubuntu1 and ubuntu2 were rejected)
<Mithrandir> tsmithe: usually to the uploader, with a Cc to ubuntu-archive, but given that it didn't happen this time it was either a mistake (reject instead of accept) or the admin forgot
<tsmithe> hrrmh
<cjwatson> tsmithe: pitti sent a mail to you about it
<cjwatson> Date: Fri, 23 Mar 2007 15:35:45 +0100
<cjwatson> From: Martin Pitt <martin.pitt@ubuntu.com>
<cjwatson> To: Toby Smithe <toby.smithe@gmail.com>
<cjwatson> Subject: Rejecting wired
<cjwatson> Message-ID: <20070323143545.GB5443@piware.de>
<tsmithe> really... i received nothing, or at least i thought i received nothing
<Adri2000> tsmithe: look into your gmail spam ;)
<cjwatson> check your spam bin
<tsmithe> i'll have a look again
<tsmithe> thanks
<tsmithe> cjwatson, i don't seem to have it anywhere, which is annoying
<tsmithe> hmm so pdf files are a no-no
<tsmithe> if i get want to get it included now, i'll need an exception, right?
<cjwatson> only PDF files without source
<tsmithe> yes
* tsmithe wonders if the files in question are ./src/portaudio/docs/portaudio_icmc2001.pdf ./src/portaudio/src/hostapi/asio/Callback_adaptation_.pdf ./src/portaudio/src/hostapi/asio/Pa_ASIO.pdf
<mjg59> Is anyone here using the wistron_btns driver?
<ivoks> mjg59: umm... synaptics is now almost useless... :/
<mjg59> ivoks: How so, and on what hardware?
<ivoks> mjg59: i was just going to LP and provide info
<mjg59> Feel free to just let me know here
<ivoks> mjg59: scroll is slow; i have to seep finger two-three times to scroll like one can scroll with arrow-pad
<mjg59> ivoks: scroll as in horizontal and vertical scrolling, rather than scroll as in moving the pointer across the screen, right?
<mjg59> Is this a synaptics device or an alps one?
<ivoks> mjg59: vertical
<ivoks> mjg59: alps
<mjg59> Ok.
<ivoks> AlpsPS/2 ALPS GlidePoint
<mjg59> Ah, I suck
<mjg59> Hang on, let me build you a test package
<ivoks> man, you don't suck
<ivoks> :)
<mjg59> ivoks: http://www.codon.org.uk/~mjg59/tmp/xserver-xorg-input-synaptics_0.14.6-0ubuntu7_i386.deb
<mjg59> ivoks: Install that, restart X and then let me know if it works any better?
<ivoks> ok
<mjg59> I think I just got a couple of calculations the wrong way round
<ivoks> brb
<ivoks> mjg59: it's faster, but not like it use to be :)
<mjg59> ivoks: Ok, it's arguably correct now and slightly broken in the past :)
<ivoks> if you say so :)
<mjg59> The default speeds should now be the same regardless of what sort of pad you have - before, it varied depending on whether it was an Apple, ALPS or Synaptics device
<mjg59> If you think it's too slow, I can bump it up slightly?
<ivoks> maybe other users should give feedback too
<tepsipakki> there are bug reports on synaptics :)
<ivoks> :)
<mjg59> Hrm.
<mjg59> Yeah, previously alps was set much faster than synaptics
<mjg59> They should now both be much the same
<ivoks> before, i would sweep my finger and it would scroll all the way, to the end
<mjg59> Oh, hm.
<ivoks> now i have to sweep 4-5 times
<mjg59> No, maybe I've still screwed up.
<ivoks> take your time...
* mjg59 adds two extra 0s
<mjg59> ivoks: Can you re-download the same package, install it again and restart X again?
<ivoks> sure
<ivoks> brb
<mjg59> tepsipakki: Seen 95253?
<tepsipakki> mjg59: yes
<tepsipakki> I guess..
<ivoks> great! even better than before :)
<mjg59> ivoks: Super
<ivoks> my hero :D
<mjg59> tepsipakki: Also, if we're setting defaults for synaptics, it should probably be done in the driver rather than xorg.conf
<tepsipakki> oh wait, that's an intel machine and not powerpc.. attach your 'lspci -vvnn' to that
<mjg59> tepsipakki: It's using vesa, which is correct
<mjg59> The issue is that there's no useful values in the monitor section
<tepsipakki> are there any values written?
<mjg59> For hsync and vertrefresh? No
<tepsipakki> so it needs an exception in xserver-xorg.postinst
<tepsipakki> that's what the lspci is for ;)
<tepsipakki> -log
<mjg59> I don't think I understand. Why would it be an issue with this specific machine?
<tepsipakki> err, output
<mjg59> Rather than all of them using vesa?
<tepsipakki> look at the postinst..
<tepsipakki> there are exceptions all over the place
<mjg59> I can't find any vesa-related exceptions...
<andre_pl> very sorry to intrude in the devel channel, but i'm having a showstopper of a problem and nobody else can help.  every time I reboot my laptop the nvidia kernel module is gone. the file doesn't exist in /lib/modules and I have to uninstall and reinstall the nvidia-glx and linux-restricted-moudles package to get X to start... then if I reboot again, same deal.
<tepsipakki> mjg59: not yet anyway :P
<mjg59> tepsipakki: Sorry, I'm really not understanding this at all. Why do you think it's something that's specific to this machine, rather than an issue affecting everything using the vesa driver?
<tepsipakki> when did it work?
<mjg59> Worked fine in edgy
<mjg59> andre_pl: Please file a bug at launchpad.net
<ivoks> andre_pl: i've seen that...
<andre_pl> mjg59: i intend to as soon as I can get to a browser thats a little more useful than links
<ivoks> andre_pl: is that amd64 version?
<mjg59> andre_pl: Also, make sure you have linux-restricted-modules-common installed
<andre_pl> ivoks: no, its the generic kernel
<ivoks> andre_pl: so... 32bit version of ubuntu?
<mjg59> tepsipakki: I haven't been updating this machine religiously - the previous install on it was fesity, but pre-7.2 transition
<andre_pl> ivoks: yes.
<tepsipakki> mjg59: and it worked with pre-7.2?
<andre_pl> mjg59: linux-restricted-modules-common is installed
<mjg59> tepsipakki: I believe so, yes
<ivoks> andre_pl: sudo apt-get --reinstall install linux-restricted-modules-`uname -r`
<tepsipakki> mjg59: could you attach Xorg.0.log from a non-working and a working X to that bug
<andre_pl> ivoks: just waiting for it to finish removing the 386 modules.  why do they get pulled in along with the generics?
<mjg59> tepsipakki: Not trivially, due to the breakage in casper that leaves me with no consoles
<mjg59> tepsipakki: I'll see what I can do
<tepsipakki> mjg59: thanks, hopefully we'll get somewhere
<tepsipakki> the vesa driver was updated 1.2.1 -> 1.3.0 post herd5
<ivoks> andre_pl: cause you didn't install linux-generic first
<tepsipakki> mjg59: what chip does it have?
<andre_pl> ivoks: I'll have to try that.  first priority is figuring out why this driver keeps disappearing though.
<mjg59> r500
<tepsipakki> http://librarian.launchpad.net/6772731/vesa-1.3.0-range-hack.patch
<tepsipakki> that's included in the latest version, it's from fedora and it was specifically meant for r5xx
<Ubugtu> Announcement from my owner (Seveas): ubugtu will be taken offline and integrated with ubotu - epect some downtime
<tepsipakki> mjg59: see bug #89853
<mjg59> tepsipakki: That's a post-beta upload?
<tepsipakki> nope
<tepsipakki> hmm
<tepsipakki> check your version
<cr3> in casper, what creates /dev/loop0? I see that the loop module is being loaded and /sys/block/loop0 is created, but still no /dev entry :(
<tepsipakki> oh
<tepsipakki> "published 2007-03-24"
<tepsipakki> so it wasn't in beta
<tepsipakki> ..and now I see the acceptance mail from yesterday :)
<mjg59> tepsipakki: Haha
<mjg59> tepsipakki: Ok, sounds good
<tepsipakki> mjg59: I'll just mark your bug as a dupe of that other one
<mjg59> tepsipakki: Sounds good
<tepsipakki> I have another vesa upload waiting, and that should make it perform better and fix a potential crash with randr
<imbrandon> Mithrandir, ping ( beryl-plugins , source universe / binary main !? ) 
<imbrandon> is that a booboo
<imbrandon> brandon@hood:~$ sudo apt-cache madison beryl-plugins
<imbrandon> beryl-plugins | 0.2.1-0ubuntu2 | http://archive.ubuntu.com feisty/main Packages
<imbrandon> beryl-plugins | 0.2.1-0ubuntu2 | http://archive.ubuntu.com feisty/universe Sources
<racarr> Small 'booboo'
<mjg59> Anyone here using the acerhk driver?
<zyga> anyone here has access to a mirror of all packages?
<zyga> main + restricted + universe + multiverse?
<shawarma> Er... Everyone has? They're public.
<zyga> shawarma: I mean like on their filesystem with fast access?
<shawarma> zyga: Ah.. No. Why?
<zyga> shawarma: due to the inclusion of command-not-found into main I got some bugs to squash and I need my dataset
<zyga> previously I mirrored everything but I'm not that bold now :P
<zyga> (AFAIR it's about 50GB)
<Seveas> zyga, more than doubled now :)
<zyga> now I have a slightly better infrastructure so I can scan here and process there
<shawarma> zyga: So you want access to a machine with a complete mirror on the file system?
<zyga> shawarma: not access, just someone who will run a python extraction script
<zyga> that script reads some basic info from each package and serializes it to a file
<zyga> I can then process that file to generate data sets for cnf
<shawarma> zyga: Ah, ok. Nothing that can be extracted from Packages and perhaps Contents?
<zyga> shawarma: hmm?
<Seveas> zyga, look at apt-file :)
<zyga> shawarma: ah, unfortunatly no
<Seveas> (if that's up-to-date for feisty)
<zyga> apt-file doesn't know anything apart form the name
<shawarma> zyga: I'm just curious about exactly what information you need that's not readily available.
<zyga> shawarma: symlinks, hardlinks permissions and postinst script 
<zyga> apt-get source command-not-found
<zyga> and check out UnifiedDataExtractor/scan.data 
<zyga> it's from the previous version but it's enough to understand what's going on
<zyga> oh and architecture and repository 
<shawarma> zyga: I'm probably slow, but which part of that file cannot be extracted directly from http://archive.ubuntu.com/ubuntu/dists/feisty/Contents-i386.gz ?
<zyga> shawarma: none, everything is there 
<shawarma> zyga: ..and the corresponding ones for other archs.
<zyga> shawarma: hmm?
<zyga> shawarma: I'd have to download each package
<zyga> that's an option but it's usualy alot faster to just ask someone to run the script and be done with it ;] 
<shawarma> zyga: No, http://archive.ubuntu.com/ubuntu/dists/feisty/Contents-i386.gz contains a list of files in each and every package in the archive for i386.
<zyga> hmm
<zyga> w8
<shawarma> zyga: You'd only have to fetch one for each arch.
<zyga> I'll check it out
<shawarma> zyga: Do that. :-)
<zyga> I still need postinst contents
<zyga> (for every damn package)
<shawarma> zyga: For what?
<zyga> I'm looking for update-alternatives 
<shawarma> zyga: To check for update-alternatives or stuff?
<shawarma> zyga: Right,ok.
<shawarma> gotta go
<zyga> bye
<tsmithe> who is in charge of planet ubuntu?
<tsmithe> are they aware of http://ubuntu-linux.withishow.com/ ?
<tsmithe> i don't feel comfortable with them taking the feed and spitting it out with adverts, and generating revenue on that
<tsmithe> i didn't realise that by consenting to being aggregated by planet ubuntu, my work would be exploited elsewhere
<mjg59> tsmithe: As the copyright holder of your content, you're free to send them a DMCA notification
<tsmithe> DMCA?
<tsmithe> i don't live in the USA, so i'm not sure what good that would do
<mjg59> They're in the USA
<mjg59> Therefore, they're subject to US laws
<tsmithe> and that's all that matters?
<tsmithe> good :)
<mc44> yes
<tsmithe> should i also notify the planet ubuntu operators?
<mjg59> I don't see how that would help anything
<andre_pl_> O-M-F-G. you people are amazing.  I thought Feisty was nice until I saw the WPA Support, and now I'm blown away... I have tried to get WPA working under edgy and gentoo for weeks and weeks to no avail.  wih festy is no harder than wep or unencrpyted networks.  Big HUGE Kudos.
<tsmithe> well, canonical putting in a word might have greater effect than any word than me
<tsmithe> even though that is an awful thing to admit
<tsmithe> (why should a corporation have greater impact than an individual's voice?)
<zyga> tsmithe: the fear of mighty lawyer army
<mjg59> tsmithe: Canonical don't own the copyright
<tsmithe> true. but they are providing the feed
<mjg59> Yes. But they have no obvious legal standing here.
<tsmithe> ok. so i'll just contact the owner of that site...
<tsmithe> whoever that is
<PriceChild> tsmithe, there's no details that I can find, and only dreamhost in the whois info
<Mithrandir> send it to dreamhost, then.
<tsmithe> sure thing
<tsmithe> the hosting company have the power to bring it down
<Mithrandir> or gwh@withishow.com, it seems
<mc44> tsmithe: they even have a DMCA contact there :) jeff@dreamhost.com
<tsmithe> juliux, what is this general admis list?
<tsmithe> Mithrandir, so who is that?
<juliux> tsmithe, i will search for it
<tsmithe> i'll e-mail it to gwh@ and cc jeff@
<Mithrandir> tsmithe: from http://withishow.com/about/ 
<tsmithe> aha
<PriceChild> gah how did I miss that :)
<tsmithe> :)
<hugo> BenC, hi
<hugo> BenC, have anyone proposed the device manager suggested by you?
<hugo> BenC, i am talking about the gsoc proposals.. =)
<alex-weej> "    For computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon). It is not necessary for all (even most) processors made by AMD -- only their 64 bit chips."
<alex-weej> that reads "[The AMD64 CD]  is necessary for their 64-bit chips."
<alex-weej> this is wrong, no?
<cjwatson> It => the CD
<alex-weej> Yeah
<cjwatson> oh, I see
<alex-weej> http://releases.ubuntu.com/7.04/
<mjg59> cjwatson: Any idea why migration-assistant appears to run depmod -a?
<cjwatson> mjg59: fixed post-beta
<mjg59> cjwatson: Rock
<cjwatson> was just a mistake in os-prober
<alex-weej> my friend installed the AMD64 version and i had to let him down that he has no flash player, skype, or win32 codecs
<cjwatson> alex-weej: right, I guess the text is slightly off
<alex-weej> cjwatson: should i launchpad it?
<cjwatson> alex-weej: suggest better text to me and there's no need
<mjg59> cjwatson: Also, I managed to break the partitioner - I deleted the existing partition that covered most of the disk, then hit new and set up a 10GB partition. Busy cursor appeared and nothing happened for 5 minutes, then I hit the cancel button and it quit
<mjg59> parted_server was waiting for input from the fifo, not doing anything
<cjwatson> mjg59: bug, /var/log/syslog + /var/log/partman
<cjwatson> I'm not dealing with ubiquity bugs on IRC, I'd never get anything done. :)
<mjg59> cjwatson: Are they archived anywhere post-install?
<cjwatson> mjg59: /var/log/installer/
<mjg59> Got them
<mjg59> Will file later on
<cjwatson> thanks
<cjwatson> I know of 64-bit arithmetic breakage in the beta, but that's probably not what this is
<mjg59> Oh - I restarted the installer and redid partitioning. Would that have blown it away?
<cjwatson> no, it appends
<mjg59> Cool.
<cjwatson> alex-weej: how about I just replace the last sentence with "For non-64-bit processors made by AMD, use the i386 images instead."?
<alex-weej> cjwatson: "Choose this if you have an AMD64 or EM64T based processor and wish to take full advantage of it. Note that you may still run the Intel x86 version on these processors. _Click here for more information_"
<alex-weej> with a link to the wiki
<alex-weej> because there are some advantages to running i386 on an amd64 (the 32-bit app support)
<alex-weej> and you don't want to overwhelm the user at that stage
<cjwatson> there are also considerable advantages to running amd64 on an amd64
<mjr> s/may/can/ perchance
<alex-weej> yes, but things like flash player / skype matter more to joe average :)
<cjwatson> (funny how everyone thinks joe average == people they know)
<mjr> I mean, it's not like it'd be forbidden to run it even if it wasn't possible ;] 
<alex-weej> i can't make assumptions for people i don't know, cjwatson :P
<cjwatson> no, but if you don't know you don't get to make statistical claims
<alex-weej> just change it so that it doesn't claim that it is "necessary" for amd64
<alex-weej> but then amd64 users will still be confused when given the choice
<cjwatson> that's tough, it's a valid choice which we can't simplify away
<alex-weej> a wizard would be nice
<alex-weej> Q. What's your processor? A. AMD64 | Q. Do you care about 32-bit application support? A. Yes | -> i386
<cjwatson> I'm happy to add text, links, whatever, but not a wizard - there's enough complexity there already. Anything like a wizard belongs on www.ubuntu.com, not releases.ubuntu.com.
<alex-weej> cjwatson: agreed
<alex-weej> cjwatson: in that case, maybe even simplify it
<alex-weej> oops.
<cjwatson> Choose this to take full advantage of computers based on the AMD64 or EM64T
<cjwatson> architecture (e.g., Athlon64, Opteron, EM64T Xeon). If you have a non-64-bit
<cjwatson> processor made by AMD, or if you need compatibility with 32-bit
<cjwatson> applications, use the Intel x86 images instead.
<cjwatson> how about that?
<alex-weej> sounds good to me
<cjwatson> maybe s/compatibility with/support for/
<alex-weej> yeah "support for"
<cjwatson> actually, "full support for"
<cjwatson> because the amd64 system *does* have some support for 32-bit applications - actually it's only really plugins that have a problem
<alex-weej> btw, my friend tried to install the i386 skype deb and it whinged at him about the arch mismatch
<cjwatson> or things with complex library dependencies
<cjwatson> well, indeed
<cjwatson> but that's not 32-bit applications, that's i386 .debs
<alex-weej> because the deb package stuff still isn't quite multi-arch yet
<cjwatson> I know.] 
<alex-weej> do you know what happened to that? i thought it was "close" about 2 years ago? :S
<cjwatson> -> somebody else
<alex-weej> shame
<cjwatson> afaik just hasn't had time
<alex-weej> oh well
<alex-weej> but given that, it's /not/ just plugins that are the problem then is it?
<alex-weej> at least atm
<cjwatson> *shrug* "no support for 32-bit applications" is still inaccurate
<alex-weej> but we're not saying it has no support there
<alex-weej> we;re saying that for the best support, use i386
<cjwatson> "if you need support for 32-bit applications, go here instead" implies that there is no support for 32-bit applications
<cjwatson> "full support" is ok
<alex-weej> well there's no support for i386 debs
<cjwatson> yes but that's NOT THE SAME THING
<alex-weej> i know
<alex-weej> but to most people it would be :P
<alex-weej> in a utopian world, where everybody ships debs :P
<cjwatson> look, can we stop this? I said I'd say "full support" and that should be fine
<cjwatson> you're kind of hammering on and on
<alex-weej> i wasn't arguing otherwise...
<alex-weej> sheesh
<cjwatson> it's a Sunday night, tetchiness is to be expected :)
<alex-weej> you were the one saying "compatibility with"? no, "support for"? no, "full support for"? no... :P
* cjwatson restrains himself from typing /part and coming back when he's actually at work
<alex-weej> ctrl+W is easier in the heat of it all
<alex-weej> (i didn't mean that :P)
<cjwatson> I'll just say "if you need full support for 32-bit code" I guess and dodge the issue
<cjwatson> ok?
<alex-weej> fine by me
<cjwatson> right, cool
<alex-weej> but you could also just dodge it entirely and simply describe what the ISO is with no description of the implications
<alex-weej> and leave it to a "wizard" on w.u.c
<cjwatson> too late, committed, I'm going to do something more fun now ;)
<alex-weej> ok :P
<Mithrandir> alex-weej: dude, stop it now.
<cjwatson> I appreciate the bug report and am grateful for it, but I don't really want to end up in an endless discussion of it ...
<mjg59> Hm. Ok, so that didn't quite work.
<hunger> Now that the vitualbox kernel module is in feisty, do you consider adding the rest as well?
<superm1> BenC, ping
<shawarma> hunger: /win 3
<shawarma> whoops
<hugo> BenC, are you there?
<superm1> hugo, i pinged him about 20 min ago, wasnt here at that point
<superm1> BenC, i've gotta run, but i just wanted to bring bug 69534 to your attention.  i finished up the patch and wanted to see if you could look it over and let me know what you think of it.
<ubotu> Malone bug 69534 in linux-source-2.6.20 "Add lirc to linux-source build tree" [Undecided,In progress]  https://launchpad.net/bugs/69534
<hugo> superm1, thanks
<superm1> i'll stop in later
<zyga> does anyone around have any *practical* experience with debugging memory leaks in python programs?
<desrt> i guess you mean finding memory leaks in C code called from python?
<zyga> no 
<desrt> python has memory management
<zyga> I'm wondering what the heck in a rather small program keeps hogging memory
<desrt> it doesn't leak.
<zyga> I'm using several pythonic libraries, some from python some from ubuntu/debian
<zyga> okay: s/python/python-script/g
<desrt> right... python scripts don't leak memory... unless you're linking to some C that does
<zyga> the fact is: it seems to leak 
<desrt> so start looking for things that aren't leaks but seem like leaks
<zyga> it can sure 'leak' in a sense that something keeps holding memory when you didn't mean to 
<zyga> I do get the difference I just want to get this over with
<zyga> I tried gc.debug but it's worthless IMHO
<desrt> i guess yr looking for some tool to backtrace where memory allocations are made from (ala massif?)
<zyga> I'd like to be able to see a snapshot of the memory allocation tree 
<zyga> s/tree/graph/
<zyga> and check out what's there that was not supposed to be around so long
<desrt> tall order :)
<zyga> gc.get_objects() is somewhat tricky as it tells me just that
<zyga> but I need a smart way to make use of it
<desrt> finding the objects probably won't be too much help
<zyga> it might
<desrt> yr gonna want to know what code path allocated them
<zyga> the program is dead-simple
<desrt> i guess you suspect a library?
<zyga> I will know the objects once I see them
<desrt> gotcha.
<zyga> bah
<zyga> apt_inst is binary 
<desrt> you already know more about this than i do.  clearly :)
<zyga> so is apt_pkg
<zyga> I don't know how to debug them :/
<zyga> I really suspect there is a leak - a simple program that streams stuff from one place to the other just keeps getting bigger
<zyga> after scanning several gigs of data it's over 400MB 
<zyga> and it should _not_ grow 
#ubuntu-devel 2008-03-17
<lamont> how do I tell growisofs to erase the dvd, I wonder?
<slangasek> lamont: -Z ?
<lamont> slangasek: it bitched and whined at me... I'll see if it the proceeds to DTRT
<slangasek> well, -Z is how it's meant to happen anyway
<lamont> ok
<lamont> :-[ RESERVE TRACK failed with SK=5h/ASC=21h/ACQ=00h]: No space left on device
<lamont> and then proceeded to write on the disk anyway
<lamont> slangasek: now I remember... the burn finishes, but I have a coaster.
<superm1_> slangasek, if you can release the mythtv build at some point when you're around, i'd appreciate it
<Hobbsee> bah.  who actually needs releases?
<superm1_> Hobbsee, you have magic keyboard keys though too don't you?
<superm1_> can you release it :)
<Hobbsee> superm1_: nope.  ENODRESCHER.
<Hobbsee> superm1_: i don't work for canonical, so i don't have teh switches.
<superm1_> boo :(
<Hobbsee> superm1_: i don't even have the proxy switches anymore, although that was fun.
<superm1_> what happened to those?
<Hobbsee> superm1_: they found a RM
<superm1_> oh i didn't realize they were temporary for that purpose
 * Hobbsee never had DC access
<Hobbsee> hi spam
<emgent> heya
<slangasek> lamont: ummmm, are these rewritable DVDs?  Or else why are you telling growisofs to zero out a DVD?
<slangasek> Hobbsee: hrm?  You should have access to the unapproved queue through LP, has this changed?
<Hobbsee> slangasek: i do for that.  i think it even works.
<Hobbsee> slangasek: but i can't do releases, etc
<slangasek> ok, I'm pretty sure that's what superm1_ was referring to... :)
<Hobbsee> oh, i thougth he meant doing the mythtv release, and setting those cds as final
<superm1_> Hobbsee, yeah i was meaning to pull 'mythtv' through the queue since its in multiverse and affected by beta freeze.  'mythbuntu' alternate disks are something completely different
<jdong> ok it's official
<jdong> using a simple bash loop to convert rcS.d to upstart does NOT work.
 * jdong wonders if keybuk is having nightmares right now because of how I've been abusing upstart
<ScottK2> Laughing more likely.
<jdong> yeah, udev not starting is pretty painfully funny.
<jdong> particularly on a macbook where the keyboard is USB and activated by udev.
<jdong> I'll have to catch him sometime and pick his brain about this
<ion_> Heh
<ion_> Probably better wait for Upstart 0.5 before actually making the whole system boot on it.
<fabbione> cody-somerville: pong
<pitti> Good morning
<nixternal> mornin' pitti
<LaserJock> hiya pitti
<LaserJock> nixternal: yo yo homeskillet
<LaserJock> what the blazes are you doing up?
<nixternal> not even 02:00 yet
<nixternal> I will prolly go upstairs in a few and watch the boobtube
<LaserJock> man, I'm toast
<nixternal> hrmm, after spelling that, that doesn't look like a really PC way of saying television does it?
<LaserJock> I got the "bright idea" that maybe I should rewrite my data fitting program for school in C++ rather than Python
<Fujitsu> Hi LaserJock, nixternal, pitti.
<nixternal> hiya Fujitsu
<nixternal> LaserJock: that's a smart man :)
<LaserJock> nixternal: well, I had a look at the library I need and am thinking that might not be the best idea ;-)
<nixternal> which library?
<LaserJock> GNU Scientific Library
<nixternal> boost has a nice scientific library :)
<nixternal> boost might be better documented and more recent too
<LaserJock> well, it's specifically the "it's written in C" part that's getting me
<LaserJock> I'm not sure I feel like really learning C/C++ in 2 days
<nixternal> int main(int argc, char* argv[]) { // go to town!!! } :p
<nixternal> I have been trying to come up with an app so I can better learn Python myself
<LaserJock> python's great for learning
<nixternal> for some reason, I found C/C++ and Java easier to learn
<LaserJock> but I am trying to do some data analysis and C/Fortran are the tools for the job for the most part
<nixternal> F77 baby! :p
<LaserJock> yeah, that's what my advisor would use
<LaserJock> he hasn't quite gotten to F90
<LaserJock> but C is pretty much just as good for what I've got to do and a bit more ubiquitous
<nixternal> that it is
<LaserJock> my program is < 500 lines in python though, I hate to know how much more it'd be in C :/
<nixternal> someone in #kubuntu-devel said to change Ubuntu 8.04 LTS to Ubuntu 8.04 as there will not be an LTS until the point release...rumor or fact? and if rumor who is spreading it besides the guy in #kubuntu-devel?
<dholbach> jamesh:
<nixternal> hola dholbach
<jamesh> dholbach: hmm?
<Fujitsu> I heard something similar a while back, but I don't recall it being from a reputable source.
<nixternal> ahh, so there is a rumor mill then...first I heard it was an hour ago and he never responded to tell me where he heard it
<dholbach> jamesh: oops, sorry - nevermind
<dholbach> good morning :)
<dholbach> hi nixternal
<saivann> pitty : Yes, it was an oversight (I was sure that I verified it twice). At that point, we will have to fix it with another upload I guess?
<dwa> hi, if i click the new message button in evolution my cpu goes nuts untill i close the whole program. Top show evolution and gconfd-2 eating up my cpu. Does anyone know how to fix this?
<pitti> saivann: right
<seb128> hello pitti
<pitti> hi seb128
<pitti> dholbach: http://daniel.holba.ch/5-a-day-stats/> oh, so adding more than 5 per day is ok? :)
<dholbach> of course :)
 * pitti reads about five-a-day-applet ... awesome!
 * pitti hugs dholbach
<dholbach> pitti: thekorn's work :)
 * pitti hugs thekorn
<thekorn> :)
<pitti> mdke: just answered your u-docs problem
<seb128> pitti: the retracer seems to just untag some bugs recently, I've tried to look to it but without luck, apport-retrace -s bug_number wants a cookie for some reason, it's not supposed to, right?
<pitti> seb128: wants a cookie> p-lp-bug
<pitti> seb128: hm, just untag? does the log say anything? an exception or so?
<seb128> pitti:
<seb128> "  File "/usr/lib/python2.5/site-packages/apport/report.py", line 429, in add_gdb_info^M
<seb128>     assert os.path.exists(self.get('InterpreterPath', self['ExecutablePath']))^M
<seb128> AssertionError^M
<seb128> Exception exceptions.ImportError: ImportError('No module named shutil',) in <bound method __AptDpkgPackageInfo.__del__ of <\
<seb128> apport.packaging_impl.__AptDpkgPackageInfo instance at 0x839f8ac>> ignored^M
<seb128> 03/16/08 23:30:12: retracing #203017 exit status: 0^M
<seb128> "
<seb128> pitti: that's on example of bug which has just been untagged
<pitti> oh, ugh
<pitti> seb128: can you please stop it for now?
<pitti> seems it does not install the affected Package: properly
<seb128> pitti: stopped, i386 and amd64
<iwkse> hi all, I was searching for a duplicate of a bug i'm experiencing but i could not find. In few words, livecd can't boot and give the (initramfs) prompt when is used a usb-cdrom device. The problem seems to be due to initramfs which mount too fastly the new root before the cdrom is probed. It's a known bug?
<MacSlow> Greetings everybody!
<[[thufir]]> where does the Make and Model:		Samsung ML-2550, 1.0  driver come from which Ubuntu installs?
<blackjack> hi
<[[thufir]]> hi
<[[thufir]]> I'm just trying to figure out what ubuntu does differently to get this printer working.  some sort of special driver?
<asac> superm1_: http://bazaar.launchpad.net/%7Eubuntu-core-dev/network-manager/ubuntu.0.6.x ... please test the ath_pci tweaks
<asac> superm1_: (revno 100)
<twi_> hey pitti, lool, thanks for your work re #186647
<asac> if anyone else here uses ath_pci and has problems with nm in hardy, please test the above branch as well :)
<pitti> twi_: you're welcome
<soren> ogra_cmpc: I managed to redo the grub installation stuff, by the way. Now grub does all the hard work for me. Do you still need something like that?
<ogra_cmpc> soren, for intrepid, i resorted to syslinux
<ogra_cmpc> and for hardy i wont change that anymore
<soren> ogra_cmpc: Ok. It turned out to be quite simple.
<ogra_cmpc> right, but it would require me to change the whole design
<soren> Sure. Well, if you want to change back for intrepid, give me a shout.
<ogra_cmpc> being bound to vfat forces certain things on me for the installer image i build (i.e. an initramfs that uses images instead of partitions for cow)
<ogra_cmpc> i will,  for sure
<cristi> hello
<ogra_cmpc> even though intrepid might be the grub2.0 relese, who knows :)
<cristi> i would like to talk to somebody about an openal replacement
<cristi> more specifically, something that would solve https://bugs.launchpad.net/ubuntu/+source/openal/+bug/194919
<ogra_cmpc> that would solve such probs at the base
<ubotu> Launchpad bug 194919 in openal "libopenal needs replacement" [Undecided,New]
 * ogra_cmpc twiddles thumbs looking at 
<ogra_cmpc> Setting up scrollkeeper (0.3.14-15ubuntu1) ...
<ogra_cmpc> Rebuilding the database. This may take some time.
<ogra_cmpc> sigh ... that thig makes up nearly a quater of the overall image buildtime
<cjwatson> ogra_cmpc: do you divert it during image build?
<cjwatson> (i.e. does it run more than once, or just from scrollkeeper.postinst?)
<ogra_cmpc> the cron entry
<ogra_cmpc> but beyond that i dont ... i didnt have the balls to make it inexecutable from initramfs :)
<pitti> dendrobates, soren: btw, is anyone in the server team looking after dhcp3 bugs? if not, I think we need to find half-a-maintainer for it
<ogra_cmpc> pitti, i always kept half an eye on it due to it being essential to ltsp
<soren> pitti: Hm... For some reason ubuntu-server is not a bug contact for it. We should be.
 * lamont would like something better than "chmod o+r /var/lib/misc/shadow.db" for making screen unlocking work on gutsy (with shadow: compat db in nsswitch.conf)
<dendrobates> pitti: not currently, but I think that it makes sense for us to support it.
<soren> dendrobates: Do you want me to subscribe ubuntu-server to dhcp3 bugs?
<soren> dendrobates: I've got the page open, I just need to click "Ok.. Go!".
<pitti> mdke: wrt bug 110983, where does ubuntu-docs get its translations from?
<ubotu> Launchpad bug 110983 in language-pack-gnome-de "translation english-german" [Undecided,Confirmed] https://launchpad.net/bugs/110983
<pitti> mdke: I'd like to fix it in LP translations
<dendrobates> soren: Ok, sÃ¦t i gang!
<soren> Done.
<seb128> hum
<seb128> is
<seb128> somestruct = function(somestruct->option) something safe in C?
<broonie> seb128: Yes.
<seb128> hum, ok
<seb128> I'm wondering what's going on there
<seb128> I've a case where it crashes when using -O2 or -O1 but it works using -O0
<seb128> and the function parameter changes between the call and the function apparently
<seb128> that is really weird
<ScottK> doko: When you dropped python-xml to suggests for python-reportlab did you consider that solves the issue of python-xml removal for that package or is there more work that needs to be done?
<cjwatson> ogra_cmpc: hmm. Does anything in Edubuntu care about tasks any more? That is, would it matter if Task: edubuntu-desktop because Task: edubuntu-desktop-addon?
<cjwatson> since that's what the seeds currently want it to be
<cjwatson> seb128: that works (see the C FAQ section 2.7), but note that data in the structure is copied by reference, not by value, so if anything in the structure was filled in using pointers in the stack in that function then its value will be corrupt
<cjwatson> s/will/may/
<seb128> cjwatson: http://paste.ubuntu.com/5772/ is basically the concerned code
<cjwatson> seb128: e.g. struct foo func(void) { struct foo bar; char baz[32]; ...; foo.baz = baz; return foo } is broken
<cjwatson> seb128: oh, that's returning a pointer, not the whole struct. Should be perfectly safe.
<seb128> alright
<seb128> I hate this bug
<cjwatson> unless RROutput is a struct?
<seb128> output->info changes between the call and the function
<cjwatson> oh
<cjwatson> you have no sequence point in there
<cjwatson> *and* you redefine output in a nested scope
<cjwatson> asking for trouble
<cjwatson> seb128: what is "output->info" in the function arguments? more relevantly, what is "output"?
<seb128> cjwatson: output is a RWOutput struct
<cjwatson> seb128: trying to figure out how to explain this
<seb128> cjwatson: if you want to see the code, apt-get source gnome-desktop; debian/rules apply-patches; editor libgnome-desktop/randrwrap.c
<cjwatson> seb128: no, it's clear what's wrong from the paste
<cjwatson> seb128: "output" must be declared in some outer scope, otherwise that code wouldn't work
<seb128> cjwatson: that's the infamous "gnome-settings-daemon crashes on some cards" bug which has a zillion duplicates in the code bryce brought for the xrandr1.2 capplet
<seb128> let me read carrefully what you wrote and think a sec about it ;-)
<cjwatson> seb128: it would probably work a lot better if you had "RWOutput *rw_output = rw_output_by_id (output->info, info->clones[i]);"
<cjwatson> seb128: does that clarify it?
<seb128> yes, I did that change in fact
<seb128> and that fixes the bug
<seb128> I was trying to figure why now
<seb128> alright, makes sense after some thinking
<cjwatson> I'm betting that it isn't defined which scope output->info is resolved in
<cjwatson> (after some thought, sequence points aren't relevant here)
<seb128> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/198951 current comment is the valgrind error
<ubotu> Launchpad bug 198951 in gnome-control-center "gnome-display-properties crashed with SIGSEGV in screen_info_new() - i855, fglrx, radeonhd" [High,In progress]
<jdong> stupid upstart question: is "stop on shutdown" assumed to happen or must be explicitly stated?
<jdong> i.e. will a post-stop script atuomatically run on shutdown?
<seb128> l606 is "	RWOutput *output = rw_output_by_id (output->info, info->clones[i]);"
<cjwatson> seb128: annoyingly, I've been unable to find chapter and verse, but it's clear to me that at the very least renaming the inner-scope "output" will make it a lot easier to debug
<cjwatson> maybe to clone_output rather than rw_output, looking at the context
<cjwatson> in theory you might also want to drop the "RWOutput *" from the start of the line (the exact meaning is ambiguous), but from context I don't think that would be right
<seb128> cjwatson: so using
<seb128> RWOutput *new_output;
<seb128> new_output = rw_output_by_id (output->info, info->clones[i]);
<seb128> ?
<slytherin> pitti: May I suggest a small correction to MIR for elisa? You don't have to manually edit config files for adding folders of music. D&D from nautilus is supported.
<cjwatson> seb128: it can be "RWOutput *new_output = rw_..." if you like; using a different variable name should be enough
<cjwatson> seb128: (and, obviously, use new_output rather than output for the rest of that block)
<seb128> cjwatson: yes, right, that's what I tried before asking, that does the trick, I was just not sure of why because the function doesn't do any change, it just iterates through the structure and return a pointer which seemed to be fine to me
<seb128> cjwatson: thanks
<slytherin> I have one question. Synaptic does not yet display the 'Homepage:' field from control file. It is becoming increasingly difficult to know the homepage of an app. Is this known already? Or should I file a bug?
<cjwatson> seb128: I think the reason that fails is that output->info refers to the output you've just declared, which is uninitialised
<ScottK> pitti: I was wondering if you'd have time to look into fixing Bug #198183.  Becuase of it I'm afraid I'm missing lots of guidance crash bugs.  I've added several patches recently and this has me concerned.  Additionally, my experience with Guidance is that if I can get it to not crash it will eventually DTRT, so finding these bugs could make for a big difference at release.
<ubotu> Launchpad bug 198183 in apport "Apport dies when it tries to catch displayconfig bug" [Medium,Confirmed] https://launchpad.net/bugs/198183
<cjwatson> seb128: exactly what's in that memory might depend on the optimisation level, hence hard-to-reproduce failure
<cjwatson> s
<seb128> cjwatson: right, I though the declaration and assignation were supposed to be done after the function return but that seems to not be the case when using optimization
<mvo_> slytherin: thanks for the reminder, its sort of known, but a bugreport is probably a good idea
<cjwatson> seb128: I think you're deep in undefined behaviour territory
<slytherin> mvo_: will do after about 2 hours. :-)
<cjwatson> seb128: C99 is not terribly explicit, but I think the scope actually begins with the first mention of the identifier in the scope
<cjwatson> seb128: under optimisation, it might reuse the same register for it or something
<cjwatson> seb128: which would mean you'd get a pointer to the old structure by dumb luck
<seb128> cjwatson: alright, anyway I think that was rather an error than upstream picked the same variable name
<seb128> I've fixed that locally, testing in a second and uploading
<seb128> nice to get this one fixed ;-)
<siretart> do we really want to have /etc/init.d/checkfs.sh fail that badly if fsck is unable to resolve an UUID? (filed as bug #203165)
<ubotu> Bug 203165 on http://launchpad.net/bugs/203165 is private
<siretart> err, that bug doesn't seem private to me.. hmrpf
<cjwatson> seb128: I'm told by somebody with a newer revision of C99 than me that it says "Any other identifier has scope that begins just after the completion of its declarator" which is pretty clear
<cjwatson> ("other" means "not a label" in context)
<seb128> alright
<seb128> so the code is confusing and wrong ;-)
<cjwatson> apparently so :-)
<cjwatson> interesting digression into C99 innards though
<seb128> indeed
<soren> Could someone please give back virt-manager on i386 and amd64, please?
<soren> cjwatson: Thanks for looking into the JeOS thing. *Very* much appreciated.
<superm1_> asac, that branch fixes my card perfectly
<superm1_> i'll add a note to the bug in case you miss my response here
<emgent> heya people
<asac> superm1: thanks
<asac> superm1: can you test suspend/resume?
<asac> superm1: and if possible please test if it can connect to hidden AP
<hellboy195> asac: news about nspluginwrapper?
<asac> hellboy195: didn'T i sign it of?
<hellboy195> asac: nooo :)
<asac> hellboy195: bug id?
<hellboy195> asac: bug #196540
<ubotu> Launchpad bug 196540 in nspluginwrapper "Merge nspluginwrapper 0.9.91.5-2 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/196540
<asac> hellboy195: ok i am doing a lunch break now. will look once i return
<hellboy195> asac: k ,thank you
<soc> hi
<soc> currently on gutsy the fx3 builds have crappy font rendering because they don't use the system's cairo lb but their own ... will this fixed atleast in hardy?
<pitti> ScottK: ugh, WTH? sys.argv not existing? weird
<seb128> anybody wanting to approve my nautilus, gnome-desktop-, pygobject uploads?
<seb128> the nautilus one is a change to the "connect to server" dialog to make it actually mount locations, it's limited to the dialog and comes from upstream svn
<seb128> the gnome-desktop one fixes gnome-settings-daemon crashing on startup in xrandr code which is a crasher recently lot of users have recently
<seb128> the pygobject change is a new revision from debian fixing the -dbg build
<pitti> seb128: looking (you weren't online when I saw your q on -desktop)
<pitti> seb128: pygobject isn't un unapproved; wasn't that a sync?
<seb128> pitti: I did a sync yes, is that an issue, ie does it bypass the freeze?
<pitti> seb128: yes, syncs go straight through
<pitti> other two accepted
<seb128> pitti: ok, sorry about that, thanks
<jwendell> seb128, Hi, have you seen my comment in a tsclient bug?
<seb128> jwendell: the comment is in my bugmails box, it lacked context to be useful and I didn't open the corresponding webpage yet
<seb128> jwendell: ie, it's on my unread stack
<jwendell> seb128, it's about a crasher bug fixed on upstream, which just needs a backport...
<seb128> jwendell: will do, thanks
<ScottK> pitti: All I know about that apport issue is that I found lots of Guidance bugs with that problem.
<mario_limonciell> Keybuk, your changes for fingerprint reader didn't make it into the pam that got recently uploaded it looks.  Still going to come in post beta?
<Keybuk> mario_limonciell: there are some security implications of the fingerprint reader support that make it difficult to justify it being enabled by default without a lot more work
<bryce> morning
<Keybuk> specifically it is possible to change the registered fingerprint as long as you have access to a user's account
<Keybuk> (it is not possible to change a user's password in the same manner)
<mario_limonciell> Keybuk, ah i see
<mario_limonciell> Keybuk, would a debconf question to pam be more feasible?
<mario_limonciell> to turn it on and off then
<Keybuk> mario_limonciell: the PAM change is just one line added to a config file, it will definitely be possible to document that in a HOWTO (along with the security implications)
<mario_limonciell> Keybuk, but if debconf could/would be possible, this change could then be at least preseeded..
<Keybuk> mario_limonciell: I think that would have component implications though
<Keybuk> since pam is required, whereas debconf is merely important
<Keybuk> I'd have to check with slangasek about that
<mario_limonciell> ah i see.  the interdependencies of those really low underlying sorts of things do end up getting forgotten (minimal,standard,desktop).  Perhaps in the postinst checking for the presence of debconf, and if it's available to do that $stuff, but otherwise normal postinst
<warren_> hi
<jpatrick> hi warren_
<warren_> can someone look at this very important bug report i've just created: https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/203199 ?
<ubotu> Launchpad bug 203199 in gdebi "Gdebi(-Kde) can't install any package!" [Undecided,New]
<warren_> it would be nice to fix for hardy!
<jpatrick> warren_: better place would be #kubuntu-devel and it's known...
<warren_> ok
<warren_> are they fixing it?
<Keybuk> mario_limonciell: the amount of testing that would require, and the very core level of that package, makes me somewhat nervous
<Keybuk> especially post-beta :-/
<mario_limonciell> :(
<Keybuk> mario_limonciell: my plan instead was to ship a binary in thinkfinger-tools that turned it on (making the PAM change)
<mario_limonciell> Keybuk, well that's very acceptable
<Keybuk> (well, it'd be a very simple script in fact :p)
<mario_limonciell> did you have a plan for when you were going to implement that?
<Keybuk> mario_limonciell: already done, will be uploaded post-freeze
<Nafallo> next cycle is a crap cycle, no? :-)
<mario_limonciell> Keybuk, thinkfinger-tools is universe though is it not?  could go in through the freeze?
<Keybuk> mario_limonciell: it has an MIR open
<Keybuk> so it's "on the way to main"
<mario_limonciell> ah
<mario_limonciell> well we'll look forward to seeing that post beta then.  Thanks :)
<\sh> who must I bribe to let the last upload of lighttpd flow into our archives? ;)
<cjwatson> Keybuk: debconf is Priority: required, whatever its control file might say
<Keybuk> d'oh
<cjwatson> joeyh doesn't like it much, so it's never been reflected in debian/control, but it has to be required to make debootstrap work
<cjwatson> (given the current implementation)
<Keybuk> you'd think that I, of all people, would know not to confuse the output of dpkg -s with reality
<cjwatson> interesting, that's one case where I'm pretty sure it's been like that since Ubuntu started
<infinity> At least, yes.
<cjwatson> does dpkg grab that from control in the .deb, then?
<Keybuk> cjwatson: yeah
<Keybuk> dpkg -s famously doesn't include details of overrides ;)
<Riddell> calc: what makes openoffice chose its widget style?  I'm wondering if the kde 3 style will be chosen when running under kde 4
<calc> Riddell: not completely sure, i'll have to look around at the code to see, there is a known bug in the fallback for icons though that I need to fix
<Riddell> calc: I don't suppose you've heard of anyone doing an oxygen openoffice theme?
<cjwatson> calc: I happened across the relevant code last week; it looks for various KDE variables in the environment, I believe
<\sh> slangasek: could you approve lighttpd 1.4.19-0ubuntu2? :)
<calc> Riddell: no, but then I don't use KDE so haven't been actively looking for one either
<calc> cjwatson: ah ok
<cjwatson> and it only had one case for KDE
<cjwatson> calc: see vcl/unx/source/plugadapt/salplug.cxx; it looks for KDE_FULL_SESSION in the environment, and also checks whether the netwm atom is "KWin"
<cjwatson> then the theme is in vcl/unx/kde/
<calc> cjwatson: thanks :)
<calc> i am a bit over halfway done sending all the bugs upstream :)
<calc> then need to make a second pass to deal with the 36 remaining new bugs
<calc> most of the bugs i have sent upstream are marked to be fixed for ooo 3.0, whee :-)
<Amaranth> calc: it seems like _every_ bug sent upstream is marked for OOo 3 :P
<slangasek> bryce, tjaalton: why is xserver-xorg-video-i740 a dependency of -video-all on i386, but not on amd64?
<bryce> slangasek: hmm, not too familiar with i740, let me take a peek
<slangasek> bryce: not that I should complain too loudly, currently this is one of the packages that make the difference between viable amd64 desktop CDs and oversized i386 CDs ;)
<bryce> heh
<slangasek> calc: fix for the uninstallable openoffice.org-l10n-en-us is still in the pipe?
<bryce> well it supports such cards as the famed "Spacewalker Hot-158" video card, how could we neglect that?!?  ;-)
<bryce> slangasek: anyway, it says it supports 'any' architecture, so I've not yet spotted a reason why it shouldn't be included for amd64
<bryce> it looks like it's a driver for a variety of bargain bin video cards which presumably would work on either
<bryce> I do wonder though if -intel supersedes i740 like it did for i810, but I've never heard talk to that effect
<bryce> I can dig further if you'd like?
<slangasek> I know nothing about i740, I was just looking at the diff and that one seemed odd
<bryce> it looks like at least for edgy, amd64 was targeted:  https://launchpad.net/ubuntu/edgy/amd64/xserver-xorg-video-i740
<slangasek> maybe the i740 was only ever used as an integrated chipset on 32-bit boards
<bryce> hmm, possibly, but from the card names in the readme "Joymedia Apollo 7400", "Machspeed Raptor i740", "Winfast S900 i740", etc. they sound a tad more like discrete consumer boards
<Amaranth> is there a reason usplash isn't using uvesafb?
<Amaranth> isn't the i740 one of the original 3D accelerator cards?
<Amaranth> like, from the quake 1 days
<bryce> the driver's readme is dated 1999 so it seems to come from that era
<Amaranth> i suppose the reasoning there is "why would you put one of these in an amd64 box?"
<Amaranth> if the amd64 box would even have a slot for it
<bryce> heh
<Amaranth> iirc, carmack really loved that card :)
<_MMA_> Since we're on graphic issues here and Amaranth mentioned Usplash, https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-March/003499.html Any ideas?
<jdstrand> mathiaz: thinking about the apparmor/upgrade/complain issue
<jdstrand> mathiaz: here is my thinking so far:
<jdstrand> mathiaz: "$2" lt <first version of app where a profile existed> == complain
<jdstrand> 'profile existed' means either in the package or apparmor-profiles
<jdstrand> that is the easy case-- use complain when upgrading froma version where we didn't have a profile for it
<jdong> upstart officially boots me now
<jdong> Keybuk: pre-poke, I'll need consultation in a bit
<jdstrand> mathiaz: the other easy case-- don't do anything special for version higher than the first version that shipped the profile
<jdstrand> (eg hardy -> intrepid)
<jdstrand> mathiaz: the harder case is what to do if going from apparmor-profiles to profile in the package
<jdstrand> mathiaz: eg bind9 upgrade from gutsy -> hardy
<jdong> Keybuk: what I wanted to ask was, if I define states using only a pre-start script and the service keyword, startup is still parallelized, right?
<jdstrand> mathiaz: checking for dpkg-old seems error prone, as dpkg-old could be really quite old
<calc> slangasek: yea still in the pipe, i'll be uploading it in the next week or so
<calc> Amaranth: a lot of bugs in upstream bts are either not confirmed at all or marked later (as in they will never get fixed) :-\
<jdstrand> mathiaz: I could stat it, but that seems hacky
<mathiaz> jdstrand: what would you do in the case? put in complain or in enforce mode ?
<jdstrand> mathiaz: that is what I am thinking about
<Amaranth> jdong: whoa, you've got a full upstart boot?
<jdstrand> mathiaz: I'd like to peek inside the old version, then make a decision
<Keybuk> jdong: -> #upstart
<jdstrand> mathiaz: by old version, I mean the existing profile that apparmor was using prior to the upgrade
<jdstrand> mathiaz: but that won't get me what I want either
<jdstrand> mathiaz: I could just always put these into complain mode
<jdstrand> mathiaz: that is safest from a usability point of view
<cjwatson> pitti: bug 199129 hurts my brain. This looks like hal. Are we supposed to call hal-disable-polling on each drive to get it to go away?
<ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New] https://launchpad.net/bugs/199129
<mathiaz> jdstrand: yes - I think the main reason we're doing this is to not break existing configuration
<jdstrand> mathiaz: so I could just do "$2" lt <first version an enforcing profile was shipped> == complain
<jdstrand> that logic is simple, and should not break anything
<jdstrand> mathiaz: it will turn off a previously enforcing profile though
<mathiaz> jdstrand: yes
<mathiaz> jdstrand: which may not be good
<mathiaz> jdstrand: could you grep in the profile for enforce mode ?
<cjwatson> pitti: although hal-lock looks sort of promising too
<pitti> cjwatson: hi
<jdstrand> mathiaz: so really, what I want is "$2" lt <first version an enforcing profile was shipped && <user said to keep the existing profile" == noop
<pitti> cjwatson: disable-polling? that's just for CD-ROM drives
 * pitti looks at bug
<jdstrand> mathiaz: or flip that and say ... && <user said to use the new profile> == complain
<pitti> cjwatson: right, the old automount bug
<pitti> cjwatson: until gutsy, gnome-volume-manager does the automounting, now this is triggered by nautilus
<cjwatson> pitti: it sets media_check_enabled to false, which seems to be checked in the fdi that invokes hal-storage-mount
<jdstrand> mathiaz: I could grep for enforce mode (which is what I was thinking), but if they had enforcing, and get the new profile, something could break
<cjwatson> we're already setting the relevant nautilus gconf settings
<mathiaz> jdstrand: I'm not convinced you need to use first version an *enforcing* profile was shipped
<pitti> cjwatson: with the recent fix in casper to not ask for PK passwords for 'ubuntu' any more, you won't even get the dialog any more
<mathiaz> jdstrand: right - but they would be prompted for a configuration file change.
<pitti> cjwatson: hm, weird; we entirely ripped out mounting from g-v-m
<mathiaz> jdstrand: it's up to them to merge correctly then.
<pitti> and aside from nautilus, nothing else does automount
<jdstrand> that is a good point
<mathiaz> jdstrand: that doesn't change from any other configuration file change
 * jdstrand nods
<cjwatson> pitti: the password isn't the bug
<pitti> cjwatson: right, I know
<cjwatson> pitti: I think hal's doing the automount all by itself, without nautilus intervention
<pitti> cjwatson: no, hal never automounts
<mathiaz> jdstrand: I think you need: $2 lt <first version where an apparmor profile was available> then complain
<pitti> cjwatson: however, I think running ubiquity under hal-lock is the canonical way to block these things
<pitti> instead of writing fake fdi files, meddling with gconf, etc.
<cjwatson> or maybe just the partitioning bit. Yes, that was sort of what I was looking at
<jdstrand> mathiaz: yes, that was the first case I mentioned
<jdstrand> eg dapper - hardy
<jdstrand> I absolutely agree
<cjwatson> actually, the whole of ubiquity would probably be fine; I don't want it bailing out if it can't start the partition manager ...
<jdstrand> then nothing for the other cases-- up to user to merge the changes?
<pitti> cjwatson: at least this prevents mounting at a more fundamental level than gnome, thus also applies to KDE, and should be more stable against changes in gnome
<jdstrand> mathiaz: ^^
<jdstrand> mathiaz: that seems sane
<jdstrand> mathiaz: if the profile exists in this scenario, then the user is prompted
<cjwatson> pitti: ok, thanks, I've asked Henrik to see if he can reproduce this under hal-lock
<mathiaz> jdstrand: hmm.. Considering that apparmor-profiles wasn't installed by default in gutsy, upgrading to hardy would prompt for a profile change for named
<pitti> cjwatson: sudo hal-lock --interface org.freedesktop.Hal.Device.Storage --exclusive --run gedit
<pitti> cjwatson: that works for me
<pitti> cjwatson: without sudo it doesn't
<pitti> (quite understandably)
<jdstrand> mathiaz: if the profile existed, then yes.  and that is good
<mathiaz> jdstrand: we could assume that the user knows a bit about apparmor since he installed apparmor-profiles
<cjwatson> hal-lock's argument passing conventions are irritating
<cjwatson> you have to pass command and arguments as a single argument
<cjwatson> unlike sensible adverbial commands
<jdstrand> mathiaz: I can say for the non-installed apparmor-profiles but the profile exists case, this is exactly what we want
<jdstrand> mathiaz: prompting on a profile change
<mathiaz> jdstrand: correct
<mathiaz> jdstrand: however, if the system as a default profile upgrade should be transparent
<jdstrand> mathiaz: really what we are worried about is the case where:
<jdstrand> 1. apparmor-profiles is installed
<jdstrand> 2. the profile migrated from apparmor-profiles to the package
<jdstrand> mathiaz: so we need to decide if in this case, we want to enforcing mode
<jdstrand> s/to//
<mathiaz> jdstrand: well - if the profile is the default, we should enforce the new one. If the existing profile has been modified, we shouldn't enforce it
<mathiaz> jdstrand: and leave it to the sysadmin to decide
<jdstrand> mathiaz: I don't think we can do that.  the default apparmor-profiles package is in complain mode.  therefore the user could have done anything with her configuration, and it was working.  we flip to enforce and boom
<mathiaz> jdstrand: good point.
<mathiaz> jdstrand: so that means if apparmor-profiles was installed, we should put the profile in complain mode always
<jdstrand> mathiaz: except that gets us back full circle to when the user has apparmor-profiles installed, *and* enabled enforcing mode
<jdstrand> mathiaz: we just turned it off
<jdstrand> mathiaz: but, the user would have been prompted
<jdstrand> for the config change
<jdstrand> conffile change
<keescook> mvo: hi! which piece of software is responsible for the "Preconfiguring packages ..." text?
<jdstrand> mathiaz: that seems sane
<jdstrand> mathiaz: it doesn't break anything, and the admin was alerted to a change in the profile-- up to her to check it out
<mathiaz> jdstrand: hmm. So we shouldn't change anything in that case.
<mathiaz> jdstrand: no enforce or no complain mode
<mathiaz> jdstrand: just leave it as it is.
<mvo> keescook: debconf usually - why?
<jdstrand> mathiaz: oh, so if apparmor-profiles is installed, just let dpkg and the admin handle it
<jdstrand> mathiaz: ?
<mathiaz> jdstrand: yes -
<jdstrand> mathiaz: let me think about that
<mathiaz> jdstrand: don't try to put the profile in complain mode.
<JanC> anybody know if there is a reason why python-wxgtk2.6 in hardy now suddenly depends on python2.4 instead of python2.5 before, or should I file a bug?  ;)
<mathiaz> jdstrand: the issue I see with your proposal about a complain/ directory is that there will be two places in the system where you can set a profile in complain mode
<mathiaz> jdstrand: that will be... confusing
<ScottK> JanC: Is it instead of 2.5 or in addition to 2.5?
<jdstrand> mathiaz: yes, but the tools are modified to make it look consitent
<jdstrand> mathiaz: eg aa-enforce and aa-complain will manage the symlinks
<mathiaz> jdstrand: hm.. but if you edit a profile by hand, and set it to enforce, it can still be in complain mode
<keescook> mvo: okay, was just looking at bug 203262 and saw the /tmp filename, wanted to double-check /tmp-usage-sanity
<ubotu> Launchpad bug 203262 in hwtest "hwtest fails preconfigure" [Undecided,New] https://launchpad.net/bugs/203262
<jdstrand> mathiaz: true enough, but our documentation says to use aa-enforce and aa-complain to switch between these modes
<mathiaz> jdstrand: correct.
<jdstrand> mathiaz: I had initially considered calling complain/ force-complain/
<JanC> ScottK: it depended on "a python >= 2.4 and << 2.6" and "python2.5" in the past, and it depends on "a python >= 2.4 and << 2.6" and "python2.4" now
<jdstrand> but thought that had the potential to be even more confusing
<ScottK> JanC: Please file a bug then.
<mathiaz> jdstrand: may be we should add a sanity check - if there is an inconsistency between the profile and the state in complain/ a warning message should be emitted
<ScottK> JanC: Assign it to Adri2000 since he did the last upload.
<JanC> k
<jdstrand> mathiaz: eg 'Warning: found /etc/apparmor.d/complain/foo, using complain mode'
<jdstrand> mathiaz: ad like you said-- *only* if inconsistent
<mathiaz> jdstrand: yes
<jdstrand> mathiaz: I like that
<JanC> aah, someone beat me by 5 minutes to file this bug  ;)
<jdstrand> keescook: have you uploaded the new apparmor yet?
<jdstrand> keescook: with my patch?
<qense> are there hal developers on? I think they might find bug 203094 interesting
<ubotu> Launchpad bug 203094 in libsmbios "hal cannot set brighness on Dell notebook computers if a BIOS password is set" [Undecided,New] https://launchpad.net/bugs/203094
<qense> (btw, maybe there should be a function added to this channel that you can poke a group)
<keescook> jdstrand: no, but was going to soon, should I wait for updates?
<jdstrand> keescook: mathiaz suggested I add a sanity check warning message in the case that complain/foo exists but the profile is in enforcing mode
<keescook> jdstrand: yeah, good idea
 * jdstrand nods
<jdstrand> keescook: so I'll do that and ping you
<keescook> okay
<LaserJock> qense: the problem would be that there isn't really such groups to poke
<qense> maybe it would be good if people could subscribe to specific keywords
<keescook> mvo: what creates the files in /tmp prior to debconf running?  while I know the number isn't a PID, the path still makes me nervous: /tmp/hwtest.config.155713: ...
<JanC> so I assigned https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.6/+bug/203266 to Adri2000  ã
<ubotu> Launchpad bug 203266 in wxwidgets2.6 "python bindings of wxwidgets2.6 depends on python-2.4 instead of 2.4 and later" [Undecided,New]
<LaserJock> qense: again, that requires such people being available I think
<qense> yes
<mvo> keescook: I suspect tat this file created by debconf, but its just a educated guess currently
<qense> but it could be client side
<LaserJock> qense: how do you mean?
<keescook> mvo: it seems to read files from STDIN
 * mvo checks
<qense> a plugin for the client
<qense> wait, that's not the work of the channel maintainers
<Amaranth> bryce: is it possible to make bulletproofx not wipe out the xorg log file?
<mvo> keescook: have you checked /usr/sbin/dpkg-preconfigure ?
<bryce> Amaranth: you can turn it off in /etc/gdm/gdm.conf via the failsafe* options
<mario_limonciell> Amaranth, it just saves it to /var/log/Xorg.$DISPLAY.log.old
<mvo> keescook: eh, hold on
<mario_limonciell> doesn't it?
<LaserJock> qense: what I'm saying is that most of the time we don't necessarily have set people working on specific packages, or it's just one person perhaps. Filing a bug is much more effective than trying to ping people in IRC
<keescook> mvo: I haven't, I assume it's something in dpkg, and I'm nearly positive it's using /tmp safely, but the all-numeric suffix bothered me.  I would expect letters if it's using mkstemp()
<qense> ok
<keescook> jdstrand: I pushed your changes-so-far to the primary apparmor bzr tree, if you want to merge to that
 * jdstrand nods
<LaserJock> qense: so when you ask for hal people, well there aren't any specific hal people that I know of
<Amaranth> mario_limonciell: yeah, someone is telling me on their system that gets wiped out too
<Amaranth> *shrug*
<LaserJock> qense: but somebody will take a look at a bug report
<qense> aha
<qense> can I confirm the bug or should the reporter give more information?
<qense> that was what I actually wanted to ask
<qense> I think the largest part of the information is given
<qense> and the dev can decide which specific information (s)he needs
<mathiaz> keescook: bug 141295 is still relevant ?
<ubotu> Launchpad bug 141295 in linux-ubuntu-modules-2.6.22 "apparmor: kernel fix for missing audit type" [High,Incomplete] https://launchpad.net/bugs/141295
<mathiaz> keescook: I've seen you've submitted a couple of kernel patches for apparmor
<LaserJock> qense: yeah, if you can confirm it go ahead. Adding information is always encouraged
<qense> not that way ;)
<qense> I'm a member of BugSquad
<qense> I wanted to set it to confirmed(status) so the dev can decide what is needed more
<qense> since things like this can be very system specifix
<qense> c
<LaserJock> I don't think setting it as Confirmed will do much
<qense> ok
<LaserJock> if you can confirm it or get somebody else to do so then set it as Confirmed, otherwise I'd say leave it as is
<psyke83> hi, I'm the author of this bug report, and I'm concerned that a fix or workaround will not make it into Hardy: https://bugs.launchpad.net/bugs/195929
<ubotu> Launchpad bug 195929 in gtk2-engines-murrine "Cosmetic bug: rectangular white outline surrounding rounded buttons (dup-of: 180962)" [Low,Fix committed]
<ubotu> Launchpad bug 180962 in xulrunner "new GTK widgets could look better" [Unknown,Confirmed]
<psyke83> I have already posted a fix for buttons, but GtkEntry boxes are still not rendering properly... this issue impacts Firefox 3, and since it's going to be the default browser, IMHO we should have some eyes look over the code
<mario_limonciell> Amaranth, that's a bit surprising.  I've always had that log for failing back to
<qense> psyke83: post your patch again in the main report
<qense> (the one your original report was marked as a duplice of)
<qense> or maybe even post the fix at the mozilla bug tracker
<qense> because that's where it finally has to be fixed
<psyke83> qense, damn, I didn't see it had been marked as duplicate.. IMHO my bug has more useful information
<qense> I think they did that because your report is a bit 'untidy' ;)
<psyke83> qense, the fix is only for buttons, not GtkEntry/GtkCombo boxes, and the fix is actually in the GTK2 engine code
<qense> well, if I were you I'd post the information again in the main report and/or at moz
<keescook> mathiaz: oh, yeah, I couldn't find that bug
<keescook> (I opened a new one, bug 202888 I think)
<ubotu> Launchpad bug 202888 in linux "aa-logprof unable to process logs without "type"" [Undecided,Triaged] https://launchpad.net/bugs/202888
<mathiaz> keescook: I'll mark 141295 as Won't fix
<keescook> mathiaz: well, I intend to fix it -- I have the patch in my hardy kernel git tree.
<mathiaz> keescook: right - but the bug is against linux-ubuntu-modules-2.6.22
<mathiaz> keescook: I could also mark it as a duplicate of bug 202888
<ubotu> Launchpad bug 202888 in linux "aa-logprof unable to process logs without "type"" [Undecided,Triaged] https://launchpad.net/bugs/202888
<keescook> ah, right
<mathiaz> keescook: now I wonder - this patch had to be applied otherwise the genprof doesn't work in gutsy
<LaserJock> man UUIDs can be a pain
<ion_> laserjock: Huh?
<LaserJock> they seem to change a lot on me, especially swap
<ion_> Well, that seems strange.
<LaserJock> I was trying to figure out why my computer wouldn't hibernate, then a look around and I've got no swap
<LaserJock> and sure enough the UUID had changed
<ion_> I can't think of what could cause that.
<LaserJock> well, this time it happened after I booted into a different OS
<LaserJock> it's usually related to an install or another OS
<LaserJock> but it's rather aggravating
<keescook> LaserJock: swap changing UUID is a bug :(  bdmurray might know more about it
<LaserJock> yeah, I think I know the bug
<LaserJock> I've been having this problem since I think edgy or so
 * keescook nods
<keescook> I haven't been able to reproduce it, but I also don't multiboot
<LaserJock> initially I made the mistake of using the same swap partition for multiple OSs
<LaserJock> which makes sense that hibernation might cause problems
<LaserJock> so now I have a swap partition for each OS
<keescook> well, it seems like there is an OS that just mkswap's for fun.
<LaserJock> which wastes a lot of space
<cjwatson> keescook: it's apt-extracttemplates
<keescook> cjwatson: yeah, mvo and I switched to privmsg, all is fine.  :)
<cjwatson> keescook: the code looks scary on the face of it, but I think it is just about safe
<cjwatson> ok, cool
<LaserJock> but the thing for me is that it's just a problem in using UUIDs, if I use the actual name of the partition it's all fine
<keescook> cjwatson: yup, I figured it must be, but the tmp name didn't feel like mkstemp so I wanted to see for myself.  :)
<emgent> heya people
<keescook> heya emgent
<LaserJock> it seems that while UUID is handy it's also fragile
<keescook> LaserJock: well, generally only in this weird case.  you can use other names too
<LaserJock> yeah, I would hope that UUIDs of non-swap partitions would stay the same :-)
<cjwatson> LaserJock: you're not the first person to report this for swap, by a long shot; I'd love to know what's causing it
<LaserJock> cjwatson: this time it was a tad strange
<LaserJock> what I did was install Fedora 8 on another partition
<LaserJock> made sure it wasn't using the Ubuntu swap
<LaserJock> but I swear I've rebooted a couple times into Ubuntu without a problem before today
<LaserJock> anymore the first thing I check after doing an install is that swap still works
<LaserJock> perhaps Fedora does a mkswap anyway
<LaserJock> even if I tell it I don't want to use that partition for swap
<keescook> cjwatson, bryce: what are your thoughts on bug 190370?  this seems like an improper "escape" from bullet-proof mode?
<ubotu> Launchpad bug 190370 in xorg "privilege escalation when canceling the low-graphics warning prompt" [High,Confirmed] https://launchpad.net/bugs/190370
<cjwatson> I commented on it already, I definitely think it's a bug and seems like a possible vulnerability
<cjwatson> well, maybe not, since you have to have physical access
<keescook> yeah, has me worried -- though I'm a bit on the fence due to the physical access part
<bryce> keescook: is that actually bulletproof-x mode?
<keescook> bryce: not sure, I haven't had time to reproduce it yet.
<cjwatson> bryce: it's unclear, but it does seem vaguely like the failsafe mode
<cjwatson> they don't quote exact text, but displayconfig-gtk does mutter about low graphics mode
<cjwatson> I suspect it's more likely to be a gdm bug than anything else
<cjwatson> or at least that that's a better place to start than xorg
<cjwatson> but didn't want to reassign it, not being Bryce or Timo
<bryce> ted said he reproduced it; perhaps he can give more details
<ogra_cmpc> soren, could i get a look form a virtualization expert on bug #134865 ?
<ubotu> Launchpad bug 134865 in ltsp "x11-common segfaults in ltsp chroot in xen dom0" [Undecided,Fix committed] https://launchpad.net/bugs/134865
<ogra_cmpc> does that fix sound sane to you ?
<mdke> pitti: we download the translations from translations.lp.net/ubuntu/hardy/+source/ubuntu-docs - you can see the relevant template for each document
<soren> ogra_cmpc: The fix being that it installs libc6-xen?
<soren> ogra_cmpc: Yes, that sounds sane.
<ogra_cmpc> it installs libc6-xen if thats installed on the server
<ogra_cmpc> ok, fine then, i'll commit it after he fixed it up a bit
<mdke> pitti: reference is at https://wiki.ubuntu.com/DocumentationTeam/Translation which is always worth a read if you haven't translated docbook xml before
<murlidhar> http://sourceforge.jp/forum/forum.php?thread_id=7399&forum_id=5768
<murlidhar> can anybody port cabos application to linux
<murlidhar> please
<wasabi> I suspect you'll have more luck doing it yourself.
<cristi> hello
<cristi> is there any developer here
<cristi> with whom I could discuss some openal issues?
<cristi> more exactly https://bugs.launchpad.net/ubuntu/+source/openal/+bug/194919
<ubotu> Launchpad bug 194919 in openal "libopenal needs replacement" [Undecided,New]
<cristi> have I perhaps asked the wrong room?
<_MMA_> People are most likely busy of not working atm.
<cristi> thanks
<cristi> but is this the right room?
<keescook> asac: I've filed bug 203306 -- you'd asked me to do so a while back but it had fallen down my TODO list until now
<ubotu> Launchpad bug 203306 in firefox "when upgrading to FF3, some about:configs are reset" [Undecided,New] https://launchpad.net/bugs/203306
<asac> keescook: those are booleans, right?
<keescook> asac: yeah
<LaserJock> oops, I seem to have killed the hwtest app :/
<asac> keescook: ok i attached a patch that still applies cleanly :). don't ask me if it still works though.
<keescook> hehe
<\sh> slangasek: please approve php-xdebug (universe) thx :)
<\sh> s/slangasek/whoever has the mighty powers to approve stuff/
<warp10> Hi all!
<alex-weej> bryce: hey. any idea what's going on with xorgs tendency to detect screen dimensions incorrectly lately?
<bryce> alex-weej: not sure what you mean.  Hardy does rely more on the automatic screen detection rather than the debconf heuristics, so there is possibilities that if your screen had been set up correctly before, it may work differently now, but that change went through a few months ago
<alex-weej> maybe i just hadn't noticed it as gnome has my DPI set in gconf at 96
<alex-weej> have you seen my bug?
<seb128> slangasek: bug #202193 is somewhat noticable and you might to milestone it
<ubotu> Launchpad bug 202193 in ubuntu-gdm-themes ""incorrect user name" errormessage displays in a wrong place" [High,Confirmed] https://launchpad.net/bugs/202193
<bryce> alex-weej: perhaps one of the most common issues people have run into is if they have a tv-out; on some cards X ends up using that output's resolution (typically 1280x1024), instead of what's expected.  In these cases, we generally can just quirk your card to ignore the tv-out
<bryce> alex-weej: I've likely seen your bug, which # is it?
<alex-weej> i'm trying to find it, 2 secs
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/201491
<ubotu> Launchpad bug 201491 in xorg "Screen DPI detected incorrectly" [Undecided,New]
<alex-weej> basically xdpyinfo gets the physical dims wrong
<alex-weej> but ddcprobe gets it right
<alex-weej> where is xdpyinfo getting its numbers from?
<alex-weej> also there is this sort of related issue with Firefox getting its DPI settings directly from X without checking GNOME's configuration
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/201487
<ubotu> Launchpad bug 201487 in firefox-3.0 "Firefox uses the wrong DPI" [Undecided,Confirmed]
<alex-weej> which some people have also added more information on
<alex-weej> but they are two separate problems
<slangasek> bryce: if displayconfig-gtk is no longer to be included in the menus, should it also be unseeded?
<cjwatson> keescook: I have a security vulnerability in gfxboot for you
<keescook> cjwatson: seriously?
<cjwatson> keescook: </troll> elmo reckoned you might help if I claimed that ;-)
<keescook> hah
<cjwatson> (super-weird memory corruption in the middle of assembly code, though :-/ )
<keescook> yerg.  bug #?  or some pointers?
<cjwatson> ah, I'm on it, I've just been on it for two hours and needed light relief
<keescook> heheh
<cjwatson> it's breaking the Kubuntu and Xubuntu boot processes at the moment
<cjwatson> as in, completely; CD boot menu hangs
<keescook> whoa.  but only [kx]ubuntu?
<keescook> what's different with them beyond theme?
<slangasek> the number of letters in the name, for one :)
<cjwatson> right
<keescook> I get enough of this literalness from soren.  ;)
<cjwatson> no, he's serious
<cjwatson> I've isolated it to that
<keescook> *lol*
<keescook> but mythbuntu doesn't hang?
<cjwatson> haven't tried Mythbuntu, but Ubuntu and Edubuntu are just fine
<cjwatson> (I know Edubuntu doesn't have a bootable CD, but I was just changing the labels in isolinux.cfg on the fly)
<slangasek> seb128: 202193 milestoned for release, thanks. (anyone working on it yet?)
<_MMA_> cjwatson: What days image. Ill try Ubuntu Studio.
<_MMA_> *image?
<nxvl> where is that i request for givin-backs
<cjwatson> _MMA_: today's, but I don't need more tests - it's at a hideously low level
<cjwatson> and, as I say, I was doing this just by editing isolinux.cfg
<cjwatson> not using whole different images
<_MMA_> cjwatson: Ok
<keescook> cjwatson: at what point does it freeze?  is it arch-specific?
<seb128> slangasek: (no idea, that's an artwork issue)
<cjwatson> keescook: it freezes in the middle of a 'savescreen' op in the xmenu.init function in gfxboot-theme-ubuntu/xmenu.inc
<cjwatson> savescreen is defined in gfxboot/bincode.asm
<bryce> slangasek: no, it's still needed for the bulletproof-x mode (no getting away from that via xrandr - this use case requires patching up the xorg.conf, and only dcg does that now)
<cjwatson> I would love advice, but on the other hand I'm aware that anyone else will need a while just to get up to speed on this code
<slangasek> bryce: ok
<keescook> I can read asm quickly.  gfxspamasm I'll need to grok a bit longer.  ;)
<slangasek> bryce: btw, I had occasion to be grumpy with the new, not-recorded-anywhere-in-xorg xrandr handling when my first attempt to play with the new GUI crashed X, and then afterwards my display was coming up sideways after login... :)
<keescook> cjwatson: okay, reading savescreen, one sec
<cjwatson> alloc_fb ends up in a malloc implementation
<keescook> I assume "prim_" prefix just means its callable?
<cjwatson> corresponds to ops in the interpreted language, pretty much
<cjwatson> primitive
<keescook> what's your methodology for debugging gfxboot?
<bryce> slangasek: yeah
<cjwatson> prayer
<keescook> hahah
<keescook> so, no gdb under it, etc?
<cjwatson> you can stick 'dtrace' ops wherever you like, and then you get a debug console
<cjwatson> shows you the stacks, and you can single-step
<slangasek> bryce: but I guess that's just an instance of the one bug you're already tracking, isn't it ;)
<cjwatson> you can't do any more serious inspection, but it's a good start
<cjwatson> you can only debug at the interpreted language layer, though
<keescook> can I run it on a local console sanely?
<bryce> slangasek: bug 197673 (second in importance only to bug 197645 which I'm finalizing a (hopeful) fix for)
<cjwatson> kvm
<ubotu> Launchpad bug 197673 in gnome-control-center "gnome-display-properties should revert change automatically if not acknowledged" [High,Confirmed] https://launchpad.net/bugs/197673
<ubotu> Launchpad bug 197645 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,New] https://launchpad.net/bugs/197645
<cjwatson> you can't run it under Linux - it's bootloader hooks
<cjwatson> s/Linux/Linux directly/
<keescook> okay, yeah, it's doing direct BIOS stuff, I assume.
<bryce> slangasek: I share your xrandr gui grumpiness
<cjwatson> keescook: I have a vague suspicion here that snprintf might be writing off the end of a memory region or something
<bryce> slangasek: but these are all top priorities for me (unfortunately I was sick most of last week - was hoping to have more of them resolved by now)
<keescook> cjwatson: you're suspecting that an sprintf is corrupting soemthing that prim_savescreen, save_bg, or alloc_fb use?
<keescook> cjwatson: are there any async things that happen in gfxboot?  any timers, interupt handlers, etc that might be firing?
<cjwatson> there are, but none of those seem relevant; I've reproduced this entirely consistently
<cjwatson> I'm suspecting that snprintf is corrupting the malloc arena in pretty much the usual way, albeit transferred to this environment
<keescook> right... so, if the diff between ubuntu and kubuntu is litterally 1 letter, can you reproduce by modifying the otherwise-working ubuntu theme and making it fubuntu or something?
 * keescook reads prim_snprintf
<cjwatson> keescook: I considered Kubuntu and Xubuntu good enough proof
<cjwatson> I might just be *using* snprintf wrongly, conceivably
<keescook> the themes are just read from the .cfg file?
<cjwatson> the terminology is misleading
<cjwatson> gfxboot-theme-ubuntu is actually the implementation for all flavours
<keescook> I guess I want to ask, "How do I reproduce this?"  :)
<cjwatson> should be able to do it by taking an Ubuntu CD, editing isolinux/isolinux.cfg, and making the menu label entries that mention Ubuntu say Kubuntu instead
<cjwatson> changing it to "Fubuntu" has the same effect
<keescook> more stupid questions: and this does not happen with the 3.3.28-0ubuntu2 (gutsy) version?
<LaserJock> can I get an archive admin to give back mysql-gui-tools please?
<seb128> LaserJock: no, you need a buildd admin there
<LaserJock> ah
<cjwatson> keescook: string lengths were different in the configuration associated with that
<cjwatson> I haven't tried otherwise
<keescook> okay
<LaserJock> I thought archive admins could do give-backs
<cjwatson> it's worth noting that we hardly ever call malloc directly - it's almost always through a 'string' wrapper that deals with adding 1 to the length
<keescook> cjwatson: yeah, not reading through the prim_length and other things in bincode
<keescook> er s/not/now/
<keescook> i'm uncomfortable with the memory "type"ing being done...
<cjwatson> seems to work pretty well in general
<keescook> yeah, I'm sure it's okay -- it's just hurting my poor eyes
<keescook> (this is the first time I've actually tried to seriously read the gfxboot code)
<cjwatson> I rarely have to try to read the assembly, fortunately
<cjwatson> ok, it's specifically the "^Install Kubuntu" string that it hates
<keescook> you'll have this fixed by the time I'm understanding the primitives ;)
<cjwatson> don't hold your breath, it's been three hours now
<cjwatson> oh, if you want documentation rather than grokking it from first principles, run make in doc/
<Amaranth> so gfxboot hates kubuntu? good to know ;)
<seb128> slangasek: any reason you didn't accept the gnome-power-manager update?
<keescook> cjwatson: any docs on the memory management design?  it seems to make distinctions between memory locations for doing memory sizing
<keescook> cjwatson: I'm trying to convince myself that the "sprintf" definition is safe.  :)
<cjwatson> I'm wrong, it's the "^Try Kubuntu without any change to your computer" string
<keescook> the  dup cvp length  seems right, unless "length" malfunctions
<cjwatson> keescook: the stuff in doc/ is all there is
<keescook> cjwatson: I suspected.  ;)
<cjwatson> oh, and the comments in bincode.asm ...
<slangasek> seb128: because I did?
<seb128> slangasek: hum, just received the -changes mail, you can ignore the question
<slangasek> :)
<keescook> cjwatson: yeah, that's what I've been reading.  seems like a fun tool -- just insanely difficult to debug.
<cjwatson> I have to say that it's normally been slightly easier than this
<cjwatson> provided you can wrap your head round an RPN language, but gfxboot is hardly the only such
<Kopfgeldjaeger> n8
 * slangasek whimpers in pain at the amount of time it takes to get a bzr co of ~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
<keescook> cjwatson: yeah, I'm cool with the RPN -- it's just reading what each prim is doing that's taking me time.
<keescook> I'm now trying to convince myself that the sprintf definition doesn't need a "1 sub" to the length before calling snprintf
<LaserJock> slangasek: hehe,  imagine how long it took to push it
<LaserJock> slangasek: I think it was something like 5 days
<seb128> slangasek: how restrictive are you on changes right now? I've a patch to make libgnomeui uses gio for thumbnails which is in fedora for some time and has been commited upstream now, it fixes bug #203151
<ubotu> Launchpad bug 203151 in libgnomeui "Image thumbnails are not shown in Trash" [Low,Fix committed] https://launchpad.net/bugs/203151
<seb128> slangasek: the change would be nice to have but there is no hurry, I'm fine delaying to after beta
<slangasek> seb128: I think I'd prefer that one to wait until after beta
<slangasek> LaserJock: what format is this branch in?
<slangasek> maybe it needs some bazaar guru lovin'?
<LaserJock> slangasek: don't know actually
<LaserJock> slangasek: well, I believe lifeless helped get it all set up
<keescook> cjwatson: *hah* prim_snprintf aims the gfx buffer at the alloc'd region and calls "printf"! hahaha. I love reading asm.
<cjwatson> keescook: I think I've convinced myself of that after staring at it: in get_length_40, LOOPNZ decrements ECX before the test, so an empty string will end up with ECX == -1, and NOT ECX => 0
<slangasek> LaserJock: hrm, ok.  OTOH, how long ago did he do that, and how much has the state-of-the-art moved since then :)
<LaserJock> slangasek: you might want a lightweight check out
<seb128> slangasek: ok
<keescook> cjwatson: ewww
<LaserJock> slangasek: very true, it has been a while
<cjwatson> NOT -2 => 1, etc.
<cjwatson> ones-complement negation FTW
<slangasek> LaserJock: right, for what I'm doing with it that's probably a good idea
<keescook> cjwatson: should be easy to test?  have it print out the length of various strings?
<keescook> cjwatson: these func_NN names keep making me think I'm reading BASIC.  ;)
<superm1> asac, suspend/resume was finicky before, but i'll try it
<cjwatson> keescook: ok, this is seriously freaky. This seems to work around it (with other problems, but still): http://paste.ubuntu.com/5804/
<cjwatson> so copying the characters one-by-one breaks, but strcpy succeeds?
#ubuntu-devel 2008-03-18
<cjwatson> (zapping the '^' check and copying the entire string one-by-one breaks too)
<keescook> that leaves the "^" though, right?
<cjwatson> right
<cjwatson> oh, hmm, I wonder if 'put' needs to be given a pointer type
<cjwatson> I bet it's type-sensitive ...
<keescook> cjwatson: it's performing a forall against menuitemmap.text while changing the contents of menuitemmap.text...
<cjwatson> the forall is against the string returned by translate, actually
<keescook> er, or not? the forall is the translation -- yeah
<cjwatson> I'm trying to replace it by for though in case forall is the problem
<cjwatson> hmm, that sentence could have used some punctuation
<cjwatson> nope, using a for loop instead doesn't help
<keescook> it was easier to parse than gfxboot code ;)
<cjwatson> coffee
<slangasek> "by for though in case" - who needs punctuation, just declare it to be a new dialect of python
<cjwatson> keescook: as far as I can see, any attempt to write into menuitemmap.text using 'put' breaks it
<mathiaz> jdstrand: re bug  202706 - did you forward the patch to Debian ?
<ubotu> Launchpad bug 202706 in mysql-dfsg-5.0 "MySQL 5.0.51: ORDER BY not working with GROUP BY" [High,Fix released] https://launchpad.net/bugs/202706
<jdstrand> mathiaz: not yet, plan to
<keescook> cjwatson: odd, very odd
<keescook> cjwatson: are there other cases of string-putting working?
<cjwatson> keescook: loads
<cjwatson> it's used all over the place
<keescook> cjwatson: what happens if you drop "translate" and leave everything else?
<ion_> FilenameType		Size	Used	Priority
<ion_> /dev/compcache0                         partition	30416	22380	100
<keescook> I don't really see why the source of the put should matter, though
<ion_> Uh, sorry.
<cjwatson> keescook: I think that worked, would have to check again
<emgent> heya people
<keescook> cjwatson: does forall include the terminating null?
<keescook> oh, nm, it's nulled at the end.  hrmf
<cjwatson> shouldn't
<cjwatson> gfxboot is at 4.0.1 upstream
<cjwatson> yarrr
<cjwatson> though no changes in bincode.asm so I guess that isn't relevant
<mathiaz> Is there a way I can figure out which packages depends on mysql-server (excluding Recommends and Suggests) ?
<jdstrand> mathiaz: apt-cache rdepends?
<jdstrand> (don't know how it deals with Recommends and Suggests off-hand)
<keescook> cjwatson: interesting update to /split def
<mathiaz> jdstrand: hum - it includes Recommends and Suggests
<cjwatson> keescook: hmm, where?
<keescook> in the upstream system.inc
<keescook> +  % split does not work if str1 is in a special memory region (where
<keescook> +  % 'cvp length' does not work). So we dup it first.
<keescook> cjwatson: you want the full diff pasted somewhere?
<cjwatson> keescook: no, I have it. I think that might be referring to string literals in the bytecode
<keescook> yeah... ow my head
<cjwatson> keescook: stripping out a bunch of keymaps also works around it, as Riddell suggested earlier on #ubuntu-release
<cjwatson> I think we're overflowing gfxboot's available memory, perhaps
<Volans> Hi, lool can I ask you a thing about the automount of a crypted partition of a USB HD?
<cjwatson> I might be able to fix it by stripping out some unused strings
<jdstrand> mathiaz: apt-rdepends?
<jdstrand> mathiaz: I think it goes too far though
 * Riddell hugs colin and kees and goes to bed
<keescook> I don't understand why reducing the memory footprint would solve it -- both strcpy and put operate on the same already-malloc'd region.  hmpf
<cjwatson> yeah, I know
<mathiaz> jdstrand: awesome - that's what I was looking for
<cjwatson> this is all very, very weird
<cjwatson> if I rip out dia_install.inc and everything related to it (since it was unused in Ubuntu anyway), it all works
<keescook> cjwatson: the bootloader defines available memory? it's not yet obvious to me where that happens.
<cjwatson> err. somewhere in syslinux and/or gfxboot, I'm not entirely certain where
<keescook> looks liek gfxboot reads it from a "sysconfig" area of the boot loader
<keescook> I've haven't looked at the memory areas yet, but maybe the stack is crashing into malloc? strcpy is smaller than forall
<keescook> I have no idea where code vs stack vs data vs malloc is stored yet :{
<cjwatson> it could be that, yeah
<cjwatson>  58 files changed, 3 insertions(+), 3042 deletions(-)
<cjwatson> I have to say I'm happy with that kind of change on principle
<keescook> hah -- what's that? 4.0 release?
<cjwatson> no, ripping all this stuff out
<keescook> oh haha
<cjwatson> including translations
<keescook> eek
<keescook> cjwatson: so, what produces the syslinux config that launches gfxboot?
<cjwatson> http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
<keescook> cjwatson: my brain is melted enough for one day -- sounds like we have a viable workaround.  :P
<Hobbsee> mmmm....brains....
<cjwatson> keescook: me too
<keescook> (I don't see any hard-coded memory limits in config files -- perhaps isolinux has one internally, but I'm going to stop looking)
<keescook> cjwatson: I feel kind of up to speed on gfxboot now, though.  ;)
<cjwatson> yay
<cjwatson> a victim
<cjwatson> :-)
<keescook> hehe
<cjwatson> the discussion was useful even if the solution was a lot cruder than we might have hoped
<cjwatson> we might need those associative memories again in the future ...
<keescook> yup, I figure I might actually be useful Next Time.  :)
<cjwatson> you were :)
<keescook> heh
<bryce> slangasek: aforementioned fix posted to bugs 197645 and 199960 for validation of the fix before uploading.
<ubotu> Launchpad bug 197645 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,In progress] https://launchpad.net/bugs/197645
<ubotu> Launchpad bug 199960 in gnome-settings-daemon "error starting GNOME Settings Daemon" [High,Confirmed] https://launchpad.net/bugs/199960
<vlowther> bug #ï»¿198808, what is up with that?  Who though it would be a good idea to pass all the video quirks unless specifically told not to?
<Amaranth> hmm, seems i spend 10 seconds in initramfs on boot
<jdong> lol you're really motivated to fix that, huh? :)
<RAOF> Amaranth: Fujitsu was also seeing something like that (although 30 sec or something)
<Amaranth> jdong: was watching a movie :)
<Amaranth> jdong: and i want my < 20 second boot :D
<jdong> Amaranth: lol
<jdong> everyone wants my 19s boot :)
<Amaranth> jdong: not fair that you get 19s with 19MB/s and I get 32s with 47MB/s :P
<Amaranth> i can see why you have me start udev on starting readahead though, i guess I have the IO to spare :P
<pwnguin> is this something that shows up before bootchart begins loggin?
<Amaranth> no
<Amaranth> http://www.realistanew.com/random/hardy-20080317-3.png
<Amaranth> jdong: also, you start a lot less stuff
<pwnguin> oh wow
<Amaranth> pwnguin: yeah, it's upstart scripts calling init scripts
<Amaranth> but in parallel and event driven
<Amaranth> jdong did it
<pwnguin> what?
<pwnguin> made it tank?
<jdong> Amaranth: nice, your real boot is 22s if initramfs didn't suck.
<Amaranth> oh, the 10 second stall isn't jdong
<Amaranth> i'm pretty sure it's been doing that all along
<jdong> pwnguin: the solid blue from 23 to 30 is all me :)
<pwnguin> but look at that green line
<pwnguin> that's all seek =(
<Amaranth> jdong: yeah, i think if i trim down what i start and try that defragment thing i can get 12-15 seconds :)
<jdong> Amaranth: try an easy cheap defrag replacement first
<Amaranth> pwnguin: the whole boot is seek except for readahead
<pwnguin> even readahead
<Amaranth> that's why readahead is there :P
<Amaranth> eh? during readahead I peak at 47MB/s
<jdong> Amaranth: tar up all the files in /etc/readahead/boot
<jdong> Amaranth: then unpack it back into /
<jdong> actually cpio probably works better with a list of files ;-)
<Amaranth> that's...sneaky
<pwnguin> heh
<jdong> Amaranth: for me that halved readahead time.
<pwnguin> if it works
<jdong> Amaranth: cheaper than defragging
<Amaranth> i see why it works
<jdong> lol it is really sneaky and cheap :)
<Amaranth> gimme a script or something? :)
<pwnguin> xargs?
 * Amaranth lazy
<jdong> Amaranth: lol one sec
 * jdong whips out the command he used
<jdong> Amaranth: cat /etc/readahead/boot | xargs sudo tar cvpf /tmp/init.tar
<ion_> Wasn't someone working on actually rearranging blocks on the partition based on usage patterns? That would entirely remove the need for readahead, i'd think.
<jdong> Amaranth: sudo tar xvpf /tmp/init.tar -C /
<Amaranth> tar cf foo `cat /etc/readahead/boot | xargs`
<Amaranth> alright, i'll use yours
<jdong> lol yours works too :)
<jdong> I'd use p with tar though
<jdong> you never know what permissions some of those files might need :)
<pwnguin> then pipe that back out to tar ;)
<jdong> pwnguin: LOL that sounds like... fun :D
<pwnguin> jdong: so how expensive is ext3 defrag?
<pwnguin> im not even aware of an application that does that
<jdong> pwnguin: e2defrag
<jdong> psusi patched it to work with ext3
<jdong> it works... just is a lot more destructive than this
<jdong> this operation is more or less atomic
<pwnguin> define destructive
<Amaranth> wow that went way too fast
<jdong> pwnguin: lose power in the middle of the process
<pwnguin> ah
<jdong> Amaranth: yeah it's instantaneous and yields a measurable performance for me
<jdong> Amaranth: btw I'm really impressed by how deep your bootchart is
<jdong> that's amazing
<Amaranth> ok that was scary
<Amaranth> deep?
<jdong> must be at least 50 processes in parallel
<Amaranth> ah
<pwnguin> tall
<Amaranth> yeah, my CPUs freak out for a bit :P
<Amaranth> brb, seeing if i destroyed anything
<jdong> :)
<pwnguin> now for an after picture
<pwnguin> one hopes that green line shows considerable improvement
<jdong> indeed
<jdong> my green line is still rpetty abysmal
<jdong> pwnguin: http://jdong.mit.edu/~jdong/macbook/bootchart-upstart.png
<jdong> actuallly
<jdong> http://jdong.mit.edu/~jdong/macbook/hardy-upstart-defragged.png
<jdong> that's after the "defrag"
<pwnguin> nice
<jdong> pwnguin: yeah, at this point unless readahead or modprobe (udevtrigger) drastically improves, I think I'm at my peak boot speed
<pwnguin> like someone else said, you could potentially group files together based on access patterns
<pwnguin> ie, config files at boot grouped togethre
<jdong> pwnguin: I generated a dependency diagram of my upstart boot at http://jdong.mit.edu/~jdong/macbook/depchart/upstart-dep.png
<jdong> pwnguin: it's nicely massively parallel
<Amaranth> whee
<Amaranth> jdong: http://www.realistanew.com/random/hardy-20080317-4.png
<Amaranth> peak went down but throughput seems to have gone up overall
<Amaranth> only cut a second off though
<pwnguin> readahead's much shorter that time
<jdong> shows some improvement
<pwnguin> theres a wierd exe though
<Amaranth> i think that's upstart
<jdong> how the hell is your readhead so short?
 * jdong cries
<pwnguin> because it's faster?
<jdong> Amaranth: move up udev
 * lamont wonders why it is that,  when I have "shadow: compat db" in nsswitch.conf, the gnome screen lock needs read access to /var/lib/misc/shadow.db before I can unlock the screen.
<Amaranth> jdong: i don't have the sad excuse of a harddrive that apple puts in their laptops
<pwnguin> heh
<pwnguin> 12? ouch
<jdong> Amaranth: /etc/event.d/udev, "start on starting readahead"
<Amaranth> jdong: this HD was the fastest you could get for a laptop until a year after i bought it
<jdong> Amaranth: try that for size. That should reduce the readahead bottleneck
<jdong> (hopefully no races :D)
<pwnguin> i should probably rerun profile
<jdong> Amaranth: same for lrm-manager
<Amaranth> yeah but i still can't go fast until i fix initramfs
 * jdong looks at dep chart
<Amaranth> what could make it slow?
<pwnguin> reiserfs?
<Amaranth> /etc/event.d/udev is already "start on starting readahead"
<Amaranth> you told me that one before
<Amaranth> pwnguin: no, ext3
<jdong> Amaranth: oh, do the same for lrm-manager
<Amaranth> alright, done
<Amaranth> i wish this was a pdf so i could search through it
<jdong> Amaranth: are you booting verbosely?
<Amaranth> yeah
<Amaranth> don't do that?
<jdong> Amaranth: you should be able to see where it hangs up in initramfs then
<jdong> right?
<jdong> I'm guessing probably the probing of some sort of hardware, either USB or disk
<jdong> initramfs runs a udevtrigger IIRC, which could be costly
<Amaranth> it sits at "Starting up" then "Loading", then it seems to start for a little bit at setting up cfq
<jdong> you might win by removing all USB stuff from initramfs
<Amaranth> but it does sit for a second or two on "Starting up"
<jdong> Amaranth: ok, I *DARE* you to....
<jdong> Amaranth: http://jdong.mit.edu/~jdong/macbook/event.d.new.tar.gz
<Amaranth> my keyboard and touchpad are ps/2 so... :P
<Amaranth> what is that?
<jdong> Amaranth: diff that against your event.d
<jdong> Amaranth: it's my updated event.d after shaving 2 secs off my boot
<jdong> Amaranth: it sets the IO scheduler to AIO and disabled pdflush during boot
<jdong> Amaranth: btw, you're responsible in rc.local to revert those two changes :D
<jdong> see event.d/pdflush
<jdong> Amaranth: that should further reduce seek and write pressure during boot
<jdong> and HERE, we cross into the realm of voodoo boot magic
<Amaranth> you changed udevtrigger?
<jdong> Amaranth: I did?
<jdong> Amaranth: my memory kind of fails
<Amaranth> -start on stopped lrm-manager
<Amaranth> +start on started udev
<jdong> Amaranth: oh, I wanted to trigger a bit earler as I didn't have any LRM devices
<Amaranth> ah
<Amaranth> but i do :P
<jdong> Amaranth: yeah so you shouldn't do that :D
<Amaranth> gimme your rc.local :P
<jdong> Amaranth: my rc.local is slightly scary :)
<Amaranth> is your change in load-modules the same thing?
<Amaranth> +start on stopped udevtrigger
<ScottK2> jdong: As long as you don't say worksforme and then insist everyone should do it this way.
<jdong> Amaranth: right, I think load-modules should start on udev instead.
<jdong> Amaranth: http://jdong.mit.edu/~jdong/macbook/rc.local
<jdong> ScottK2: lol, this is hack central, anyone who dares try this is at minimum insane :D
<jdong> Amaranth: useful stuff are the last line and the 2nd line
<jdong> Amaranth: the rest of hacks to save about 2W of power on my system
<jdong> and note the modprobe usbhid for when I couldn't get udev started correctly :D
 * jdong puts on his hack shame hat
<Amaranth> jdong: should it really be initctl emit shutdown in rc6?
<emgent> heya
<jdong> Amaranth: well, shutdown and reboot meant the same thing when I just wanted Pulse to save mixer levels.
<Amaranth> hehe
<jdong> :)
<Amaranth> i don't ever reboot anyway
<jdong> Amaranth: good, I'm not sure rebooting works all that gently
<jdong> Amaranth: it's kind of the extreme end of the "faster shutdown" spec from 2 releases ago
<jdong> :D
<Amaranth> yeah, i see lots of devmapper errors on shutdown
<Amaranth> because stuff goes away in the wrong order
<Amaranth> but screw it, it's shutdown :P
<jdong> :)
<jdong> good enough, tear things down, sync, umount, good neough
<jdong> Amaranth: since you're conveniently syndicated on planet, you should probably do a quick blogpost once you're done :D
<Amaranth> uh oh
<Amaranth> i knew there was a catch
<jdong> :)
<Amaranth> brb, i hope
<pwnguin> heh
<jdong> he didn't have it nearly as bad as me
<pwnguin> adventurous to do that one one machine
<jdong> let me  tell you, screwing up udev mount order on a USB keyboard system is NOT fun
<pwnguin> haha
<pwnguin> you mean apple notebooks dont have a serial debugger port?
<jdong> gasp :)
<jdong> pwnguin: I'm lucky to have an optical drive and a mouse button.
<pwnguin> but just the one button, no more
<jdong> pwnguin: watch multitouch replace that 6 months from now.
<pwnguin> ?
<jdong> pwnguin: I doubt trackpads will have buttons at apple's rate
<jdong> everyhting's gonna be encapsulated in touch and drag type gestures
<pwnguin> like a multitouch screen, or the trackpad just gets even smarter
<jdong> the trackpad getting smarter
<travis> jdong: ok, something went bad
<jdong> eep
<Amaranth> I got a desktop but I've got three sleeps running and got no bootchart
<jdong> hmm
<jdong> Amaranth: is rc.local hanging?
<jdong> Amaranth: initctl status, look for anything in starting phase
<Amaranth> jdong: initctl: missing job name
<jdong> Amaranth: sorry, list.
<Amaranth> grep says nothing
<Amaranth> oh, wait
<Amaranth> i've got a bunch of stuff in 'waiting' but i think some of it is supposed to be there and some of it isn't
<Amaranth> oh, no, that's all for on stop
<jdong> Amaranth: what's bootchart's status?
<pwnguin> man. i have this five second "resume" crap
<Amaranth> jdong: waiting :/
<jdong> Amaranth: follow up the chain: http://jdong.mit.edu/~jdong/macbook/depchart/upstart-dep.png
<jdong> Amaranth: usplash->gdm->acpi_support->laptop_mode->rc_local->stop_bootchart
<Amaranth> jdong: http://rafb.net/p/ZelU1G27.html
<Amaranth> it's waiting for gdm? that doesn't make sense
<jdong> Amaranth: no stopped is the normal state for that
<Amaranth> i should probably go through here and remove all the things i don't have init scripts for
<jdong> Amaranth: those are all "script / end script" relationships, which enter stopped/waiting once they finish
<Amaranth> oh, i did have a typo in my rc.local
<Amaranth> cfg instead of cfq
<Amaranth> :P
<jdong> Amaranth: well that'll do it :)
<jdong> Amaranth: yay set -e.
<Amaranth> so those jobs should be started to not need ok
<jdong> Amaranth: agreed
<Amaranth> err, i hope that made sense :P
<jdong> Amaranth: try "start on starting shutdown" for size :)
<Amaranth> stop-bootchart should not depend on rc.local working
<jdong> stratus: right, it should just depend on rc.local stopping
<jdong> err, wrong person entirely
<Amaranth> wait, waht?
<Amaranth> start on starting shutdown? for what?
<jdong> Amaranth: for an oxymoronic statement
<jdong> Amaranth: it was quite awkward writing rules that sounded like that :)
<jdong> Amaranth: that's where upstart's UI falls
<jdong> (and yeah blame it on PEBKAC)
<Amaranth> alright brb again
<jdong> good luck
<pwnguin> hmm
<Amaranth> jdong: man you're killing me here: http://www.reaistanew.com/random/hardy-20080317-5.png
<pwnguin> http://people.cis.ksu.edu/~jld5445/after-readahead-tar.png
<pwnguin> Amaranth: ye olde 404
<Amaranth> http://www.realistanew.com/random/hardy-20080317-5.png
<jdong> Amaranth: hmm
<Amaranth> pwnguin: you did the upstart thing too?
<pwnguin> Amaranth: no
<Amaranth> wow
<Amaranth> oh you start almost nothing
<jdong> Amaranth: so perhaps we should concentrate all the modprobing together instead, and start readahead after that's done
<pwnguin> i start X and gdm
<jdong> Amaranth: it seems like hwenever we do modprobing everyhing else grinds to a halt
<Amaranth> jdong: sounds good to me
<pwnguin> Amaranth: what am i not starting/
<Amaranth> although i should really take some time to figure out where my initramfs bug is
<jdong> Amaranth: so I guess move udev*, lrm load-modules to "start on stopped mount-kernel-filesystems ok"
<Amaranth> pwnguin: i dunno, i seem to start about twice as many things
<jdong> Amaranth: and move readahead to the last thing in the module loading chain.
<pwnguin> Amaranth: keep in mind that bootcharts elide short lived processes
<pwnguin> maybe my computer's fast enough that things don't show up in the charts ;)
<jdong> pwnguin: Amaranth seems to have a larger bluetooth stack, ntfs mount, and firestarter/iptables
<pwnguin> those are all valid points ;)
<pwnguin> ntfs in particular would be painful
<Amaranth> yeah, firestarter is for connection sharing, ntfs can go away
<Amaranth> and bluetooth? wtf
<jdong> pwnguin: your blotchy stuff towards the end of bootup looks like could be optimized.
<pwnguin> jdong: im sure it can be
<jdong> pwnguin: it would seem like resources are heavily underutilized the last quarter of your boot
<jdong> pwnguin: so.. either join the dark side or creatively use ampersands :)
<pwnguin> jdong: i agree, but im more curious about the first quarter where nothing's going on and a process called resume is sitting there
<jdong> pwnguin: yeah that's annoying too
 * pwnguin should drop bluetooth
<Amaranth> don't suppose you guys have any idea where to poke to figure out initramfs troubles
<wasabi> /usr/share/initramfs-tools
<wasabi> or -utils
<wasabi> i forget. ;)
<pwnguin> i recall someone saying there was an interactive boot version of initramfs stuff
<Amaranth> i think thinking more "what would likely cause the stall" :P
<jdong> pwnguin: break={init, top, premount, mount, postmount, bottom, magic, other voodoo}
<wasabi> Ahh. Yes. All that stuff.
<wasabi> When I'm debugging the initramfs I braek premount usually.
<wasabi> Then just step through it manually.
<wasabi> Which is a bit hard with such a crappy shell.
<pwnguin> hmm. well, just touching rc to use CONCURRENCY=shell seems to have broken hal
<pwnguin> which is a shame, since it went about 5 seconds faster
<jdong> pwnguin: haha see ya still need those dependency things :)
<pwnguin> it was quick enough to undo :P
<pwnguin> hmm
<pwnguin> "/scripts/local-premount/resume: /scripts/local/premount/resume: 57: log_begin_msg: not found"
<jdong> pwnguin: I wonder if we can put some sort of mini-upstart in initramfs :)
<pwnguin> just use make ;)
<pwnguin> im not even sure what that message means, or which file to look for line 57 on =(
<wasabi> jdong: it's been mentioned a few times that I remember
<wasabi> I'd like to see upstart used for desktop session stuff.
<jdong> pwnguin: /usr/share/initramfs-tools/scripts
<jdong> wasabi: well right now I'm wasting over 5s in bootup because udevtrigger is called once in initramfs and once in mount
<jdong> wasabi: I'd like to see some of that duplication removed, as initramfs is nearly 1/3 of my bootup right now
<wasabi> udevtrigger is async though, and does not reload modules... which is the slow part. No?
<jdong> wasabi: seems like things that close to touching the kernel aren't async
<jdong> wasabi: and right, it doesn't reload modules but it does waste time that could be spent loading the rest of the modules :)
<jdong> wasabi: maybe instead I need a really big initramfs with all my modules :)
<wasabi> Hehe.
<wasabi> Does it really waste time? I find that odd.
<wasabi> I'd think it'd be nearly instant to finish it's work after it's already run once.
<Amaranth> jdong: http://www.realistanew.com/random/hardy-20080317-9.png
<Amaranth> we seem to be doing the same amount of work in the same amount of time just in a different order :P
<jdong> Amaranth: I guess that's a good sign of hitting a bottleneck :)
<Amaranth> hehe, yeah
<jdong> Amaranth: that bootchart would be SO sexy if the first 11s were stripped.
<Amaranth> so to get faster i just need to trim down services and fix initramfs
<Amaranth> i wonder if bootchart is the one breaking my initramfs :P
<jdong> Amaranth: lol that would be funny
<jdong> Amaranth: have you tried what happens if you zap out readahead altogether? Does your disk seek fast enough ? :)
<Amaranth> because i don't remember whether or not it paused this long before before starting usplash
<Amaranth> hmm
<jdong> Amaranth: easiest way to test would be to move aside /etc/readahead/boot and replace it with a blank.
<Amaranth> or comment out the exec
<jdong> Amaranth: replace it with exec true :)
<Amaranth> jdong: yes, my HD can seek fast enough :P
<jdong> really?
<Amaranth> jdong: 36 seconds
<jdong> Amaranth: slight loss though not too bad
<Amaranth> jdong: same location, -10 instead of -9
<Amaranth> i dunno how else to optimize this
<Amaranth> what i should do is start from a clean install
<Amaranth> i've got a lot of cruft i'm too lazy to clear out
<Amaranth> eh, i never boot anyway
 * Amaranth leaves if for now
<StevenK> Never, you say?
<Amaranth> since 2.6.24 suspend is _really_ reliable
 * StevenK removes the battery from Amaranth's laptop and then cuts the power
<Amaranth> i only reboot when i get a kernel upgrade or something
<nxvl> is there any way to tell a .desktop file to use gkdu or kdesu depending on if it is KDE or GNOME?
<RAOF> You could ship 2 desktop files, one with OnlyShowInGnome, the other OnlyShowInKDE?
<pwnguin> well i found the problem with resume
<pwnguin> # Default delay is 5s
<pwnguin> which leads into an interesting question: what's the point of uuids if they change between releases?
<nxvl> RAOF: and where should i add OnlyShowInGnome? on the desktop file?
<RAOF> nxvl: It's actually a desktop file field, IIRC.  OnlyShowIn=GNOME
<Amaranth> I would to NotShowIn=KDE; for the gksudo one and OnlyShowIn=KDE; for the kdesu one
<Amaranth> because you're more likely to have gksudo (XFCE)
<Amaranth> s/to/do/
<pwnguin> hmm
<pwnguin> if [ "x${resume}" = "x" ]; then
<pwnguin> i presume this means to check if resume has something to it
<nxvl> RAOF: thanx
<dholbach> good morning
<ion_> good night
<pwnguin> interesting
<pwnguin> Google announced the summer of code organizations
<RAOF> pwnguin: Do expound, dear chap.
<pwnguin> i dont see ubuntu on the list
<pwnguin> http://code.google.com/soc/2008/
<Amaranth> interesting
<pwnguin> see?
<Amaranth> but yay, Xorg got accepted this year
<pwnguin> well that's good
<dmb> no ubuntu SOC?
<pwnguin> i asked a few weeks ago
<pwnguin> and someone pointed to brainstorm and that was about the end of the conversation
<pwnguin> well, at least debian's on there
<dmb> ubuntu is normally in it
<dmb> thats weird
 * pwnguin wonders if ubuntu even applied
<dmb> theres no good debian ideas
<pwnguin> debgraph looks good
<pwnguin> i thought i saw something like that done already though
<Amaranth> so much for telling people to propose compiz ideas to ubuntu for soc :P
<pwnguin> from now on i think i'll just put questions on the council agendas
<superm1_> asac, most certainly didn't come up nicely from suspend
<superm1_> but i dont know that's regressible for me.  i had video related suspend problems previously (that appear to be better now).  I haven't suspended for months due to them
<RAOF> Man.  I want to do the liboiljit GSoC project :)
<Amaranth> liboiljit?
<RAOF> http://gstreamer.freedesktop.org/wiki/LiboilJIT
<RAOF> Turn liboil into a small JIT'd runtime.
<RAOF> Compiler writing is always fun.
<RAOF> * for certain values of "fun".
<Mirv> bryce: hi. do you have that i18n-fixed screen resolution tool coming up? after beta I assume?
<bryce> Mirv, indeed I have the package posted and am just waiting on seb128 to upload it:  http://people.ubuntu.com/~bryce/Testing/XrandrGui/gnome-control-center_2.21.92-0ubuntu3_source.changes
 * Fujitsu is impressed to have found a page that crashes both webkit- and xulrunner-based browsers.
<Mirv> bryce: hmm, it seems seb128 has already uploaded version 2.22.0-0ubuntu1 without those patches on Mar 11th
<bryce> Mirv, oh yeah; I updated it today:  http://people.ubuntu.com/~bryce/Uploads/gnome-control-center_2.22.0-0ubuntu2_source.changes
<pitti> Good morning
<TheMuso> Morning pitti.
 * bryce waves to pitti
<ion_> Good night
<Mirv> bryce: ah, ok. great!
<warp10> Good morning
<superm1> bryce, gah, displayconfig-gtk's showing up in the "Other" menu all alone now.  I thought the goal of that last upload was to disable it in the menu system :)
<bryce> yeah it was.  I removed all the categories for it
<bryce> does the desktop file need some other modification to get rid of it?
<superm1> i'm not sure..
<superm1> maybe just dont install the desktop file?
<superm1> or at least install it somewhere that it doesnt get populated for now until you want it to show up
 * TheMuso checks the desktop file variable needed to hide an item.
<TheMuso> Hang on a sec.
<TheMuso> NoDisplay=true should do the trick.
<TheMuso> Thats used in the gnome-orca package, as well as others to hide the desktop icon.
<bryce> TheMuso: aha, thanks
<TheMuso> bryce: Welcome.
<superm1> much more appropriate solution :)
<soren> cjwatson: I just took a peek in http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/etc/crontab to figure out when I could expect the new JeOS image to be built, but it's not listed. I could have sworn that it used to be?
<mdke> slangasek: was there a problem with the ubuntu-docs upload? I don't see it in Launchpad
<kagou> hey seb128, i will redo login time test with the daily-live iso, to see impact of prefetch etc.
<seb128> hello kagou, thanks
<kagou> there are no daily(live) isos today ?
<asac> superm1: maybe try ;)
<slangasek> mdke: no problem, I just had an X crash and lost track of the fact that I hadn't pushed it through the approved queue yet
<pitti> erk
<pitti> seb128: 'sudo users-admin', does that work for you? I can't do anything in it
<pitti> seb128: I just noticed that on the current live system all PK stuff is broken due to that (also gnome-mount -vbd /dev/sda1, etc.)
<seb128> pitti: admin tools use policykit and need a bus session to connect, etc, don't run those using sudo?
<pitti> seb128: longer context: on the live CD we change PolicyKit.conf to grant all access to 'ubuntu'
<pitti> to avoid asking for an empty password
<seb128> looks good
<seb128> still you should not need sudo?
<pitti> I konw
<pitti> seb128: it just more or less emulates the situation
<seb128> hum
<seb128> I'm not sure I understand
<seb128> you should be able to run users-admin
<pitti> ah, nevermind
<seb128> and click on unlock
<pitti> I get a parse error
<seb128> and it should work
<pitti> seb128: right, but ideally root wouldn't need to unlock
<pitti> it should just work for root
<seb128> the sudo case it different, you run with an user with has no dbus session available
<pitti> and indeed root doesn't need to unlock
<pitti> hm, why does it need a session dbus?
<seb128> not sure, does policykit use it for authentification?
<pitti> nevermind, I found the bug in casper
<seb128> ok
<pitti> there's an extra blank line at the start of PolicyKit.conf
<seb128> still the question on why it needs a bus stands
<pitti> thus XML parsing error
<pitti> seb128: right, I wonder about that, too
<pitti> slangasek: I need to upload a new casper to unbreak PolicyKit in the live system, sorry
<pitti> cjwatson: that'll include your committed-but-not-uploaded fix for bug 202699, I guess that's ok?
<ubotu> Launchpad bug 202699 in casper "[Hardy] casper-snapshot wrongly labels squashfs as cpio.gz" [Undecided,Fix committed] https://launchpad.net/bugs/202699
<seb128> pitti: the session bus is used for policykit apparently
<seb128> pitti:
<seb128> 	message = dbus_message_new_method_call ("org.gnome.PolicyKit",
<seb128> 						"/org/gnome/PolicyKit/Manager",
<seb128> 						"org.gnome.PolicyKit.Manager",
<seb128> 						"ShowDialog");
<cjwatson> pitti: should be, your call of course
<seb128> 	dbus_connection_send_with_reply (priv->session_bus, message, &pending_call, -1);
<seb128> pitti: ^
<cjwatson> casper-snapshot is only ever run by hand so I can't see how it'd break anything
<pitti> right, was just going to say
<pitti> seb128: interesting
<slangasek> pitti: ok, eta on that upload?
<pitti> slangasek: give me 5 minutes, so that I can test it
<slangasek> ok
<RAOF> asac: Why is nspluginwrapper (Universe) maintained in a bzr repository only core-devs can push to?
<asac> RAOF: i guess thats a bug :)
<RAOF> asac: I've finally picked that merge-from-debian up.  Shall I push bzr to somewhere ubuntu-dev can write to? :)
<pitti> slangasek: uploaded
<asac> RAOF: yes, please push to ubuntu-dev and change control accordingly
<slangasek> pitti: cheers
<asac> RAOF: can you try to resurrect the .debian branch as well?
<asac> e.g. so we can merge using bzr means?
<Fujitsu> asac: Or you could just delete the -core from the owner.
<asac> i can?
<asac> let me see
<RAOF> asac: Not right now, but that'd be nice.
 * pitti does some test installs
<Fujitsu> asac: `Change registrant' if you hadn't found it already.
<pitti> slangasek: I take it it gets a little late for new langpacks?
<asac> Fujitsu: is that field really used for permission control?
<asac> Fujitsu: ok i changed the author to just ubuntu-dev, but i don't think that this helps
<asac> i think the easiest way is just to push that to -dev and let me know so i can abandon the other branch
<stgraber> moin
<asac> Fujitsu: oh. you were i right i guess
<asac> no all is fine
<asac> thanks
<Fujitsu> asac: Yes, that controls it.
<slangasek> pitti: yes :/
<Fujitsu> that's good
<Fujitsu> arrrgh, x on the other hand is not good.
<asac> doing the same for the upstream and debian branch
<pitti> slangasek: ok, then I better upload fresh ones after the beta; the current CDs don't have a lot of langpacks anyway, right?
<asac> but someone should push at least a bzr revision with the adapted Vcs header
<slangasek> pitti: yeah, currently we're down to around 5 languages due to lack of space
<pitti> :(
 * cjwatson blinks at the last comment in bug 199048
<ubotu> Launchpad bug 199048 in partman-partitioning "swapoff before swapon" [Medium,In progress] https://launchpad.net/bugs/199048
<cjwatson> took me a moment to get the reference :-)
 * pwnguin guesses the karate kid
 * pitti wonders whether he'll ever get used to those new progress bar
<cjwatson> yes
<pitti> slangasek: casper is in unapproved, and my ssh is currently broken again; can I ask you to accept it?
<slangasek> yes, looking
<pitti> slangasek: thanks
<james_w> Does the installer ever ask anything about the root account? (I don't know whether they used the alternate or not).
<cjwatson> james_w: the alternate/server installer will ask if and only if you also use expert mode
<james_w> cjwatson: thanks, I'll ask if they used the alternate then.
<cjwatson> (otherwise known as "I am an installer developer and want lots of noise" mode)
<slangasek> pitti, cjwatson: this casper change to rename the images according to the image type isn't going to break builds, is it?
<cjwatson> casper-snapshot is only run by hand
<slangasek> ok
<cjwatson> nothing in the CD build process uses it
<stgraber> slangasek: Is 20080318 good for early testing or is there another set of ISO to come in the next hours ? (gfxboot fix ?)
<slangasek> stgraber: there'll be another set for the gfxboot fix
<slangasek> the Ubuntu ones should be ok for early testing despite being superseded later; the Kubuntu and Xubuntu ones are known not to boot
<slangasek> (well, presumed not to boot, given the gfxboot breakage)
<pwnguin> i've been redirected to here with a questions, so I'll pose it: what on earth is the initramfs-tools resume script doing waiting five seconds for?
<stgraber> oh, and daily-live is oversized on i386
<slangasek> stgraber: ack; that was one of the things I was checking for with this run, ohwell...
<slangasek> pwnguin: according to the source, it only sleeps that long if that's how long it takes your resume device to become available
<pwnguin> slangasek: the trouble im having is that i didn't hibernate
<pwnguin> and it's still going off
<soren> cjwatson: Your tasksel fix for JeOS worked perfectly. Thanks very much!
<slangasek> pwnguin: well, yes, that seems like a plausible bug to me; if it's waiting for a disk that will never exist, for instance
<pwnguin> slangasek: hmm
<slangasek> pwnguin: the script I'm looking at *implies* that this only happens if you've booted with a 'resume=' option
<pwnguin> slangasek: thats the thing i cant figure out -- where is resume getting set from?
<pwnguin> kernel          /boot/vmlinuz-2.6.24-12-generic root=UUID=4cd91330-31b1-4a9b-aa9f-0f8b0c729420 ro quiet splash
<slangasek> pwnguin: afraid I don't know the answer to that
<TheMuso> pwnguin: It gets set from initramfs configs in /etc/mkinitramfs
<TheMuso> err /etc/initramfs-tools
<TheMuso> pwnguin: /etc/initramfs-tools/conf.d/resume to be exact.
<soren> pwnguin: /etc/initramfs-tools/conf.d/resume
<cjwatson> soren: woo. I left the JeOS project bug task open, so I guess you can close that bit now
<pwnguin> i swear
<pwnguin> UUIDS are worthless
<soren> pwnguin: Eh?
<pwnguin> looks like that's a uuid to a device that doesn't exist
<pwnguin> never did
<pwnguin> or at least, doesnt anymore
<pwnguin> the other day, i discovered that swap was using the wrong uuid, so i had no swap
<pwnguin> err, fstab was using the wrong uuid for swap. dont know why
<cjwatson> which is because something remade the swap partition; unfortunately we don't know what
<pwnguin> at any rate, thanks for the help here
<pwnguin> cjwatson: ive always wondered where uuids come from -- are they in the partition table?
<cjwatson> pwnguin: they're in the filesystem itself
<pitti> mdke: hm, https://translations.edge.launchpad.net/ubuntu-doc/ is obviously not where I should go to fix a translation bug in ubuntu-docs?
<pitti> mdke: ah, found it
<pitti> ah, my test installs look reasonably well
<mvo> ogra_: have you seen bug #201230 yourself at some point? I was not able to reproduce it
<ubotu> Launchpad bug 201230 in kdeedu "kverbos "breakes" the gui-installer" [Undecided,Incomplete] https://launchpad.net/bugs/201230
<Riddell> mvo: could we add ksplash-engine-moodin to dist upgrade tools list of packages to remove?
<mvo> Riddell: sure, added
<Riddell> thanks
<Riddell> mvo: oh, its probably too late but app-install-data is preferring KDE 4 .desktop files over KDE 3 ones
<Riddell> mvo: ideally it would list both, but I guess that would be notable changes
<mvo> Riddell: meh, sorry for that. do they have the same name?
<Riddell> mvo: yes, in most cases
<mvo> Riddell: ok, I have a look later
<Riddell> mvo: if its complex to fix, don't worry about it.  but if there's an easy way to have both kde 3 and 4 files in there that would be nice
<mvo> ok
<Riddell> stgraber: kubuntu 20080318.1 are up and needing testing
<stgraber> Riddell: ok, thanks
<kagou> seb128, WoW 17.4sec for gnome login (as fast as Mandriva)
<seb128> kagou: excellent ;-)
<seb128> kagou: how much did we have before the changes?
<kagou> seb128, yes :) login time as increased too but just for 2 sec
<kagou> before : 39 + 29
<kagou> now : 41 + 17
<kagou> knowing that compiz is not activated, and no more deskbar+tracker
<ion_> What was changed?
<kagou> seb128, i should retest last mandriva to compare with hardy
<seb128> ion_: update-manager and jockey delay their work, gdm does preloading and we stopped using deskbar and tracker
<seb128> 29 seconds to 17 is not too bad ;-)
<ion_> Nice
<kagou> mvo, seems that apturl don't work with firefox beta4 ?!
<kagou> someone can confirm this bug ?!
<seb128> pitti, slangasek: would it be ok to uploade a yelp with updated translation now for beta?
<seb128> kagou: no need to use extra ponctuation ;-) How do you I test apturl?
<pitti> seb128: an upload is certainly ok, but I'm not sure whether we'll get it on the CD; IIRC Riddell will/did trigger the last/next CD rebuild
<kagou> open apt://inkscape
<bardyr> does not work
<kagou> under firefox it would prompt to install inkscape
<bardyr> kagou, it prompts to select a handler for apt://
<kagou> ok i open a bug. thanks
<bardyr> but it works if you select to open it with /usr/bin/apturl
<kagou> bardyr, please could you confirm Bug #203538
<ubotu> Launchpad bug 203538 in apturl "Don't work with Firefox3 beta4" [Medium,New] https://launchpad.net/bugs/203538
<bardyr> yea 2sec
<bardyr> kagou, confirmed
<soren> ogra_cmpc: Do you have a moment to fill in a few blanks for me?
<soren> ogra_cmpc: I'm working on iscsi support in initramfs.
<ogra_cmpc> sure, if i can :)
<soren> ogra_cmpc: I want to try to configure iscsi if I have network setup.
<ogra_cmpc> check for a default route ?
<soren> ogra_cmpc: Is there a simple way to determine whether I have that?
<soren> Hm..
<soren> Yes, I suppose that's a reasonable heuristic
<soren> Do you have an ipconfig command line handy to do that?
<ogra_cmpc> NETWORKUP=$(route -n |grep -c ^0.0.0.0)
<ogra_cmpc> if its 1 youre online
 * soren hugs ogra_cmpc 
<soren> Awesome! Just what I needed. Thanks very much.
<ogra_cmpc> :)
<kagou> thanks bardyr
<Riddell> Ubuntu Desktop beta candidate CDs up for testing( 20080318.1)
<cgregan> Hello all, I wanted to introduce myself here on the community pages. I just joined Canonical as Ubuntu Mobile QA Engineer. If there is anything I can do to improve the relationship between community devel and test, please let me know. Thanks
 * _MMA_ waves hi to cgregan.
<pedro_> hey cgregan welcome
<stgraber> hi cgregan
<cgregan> Thanks....glad to be a aboard
<Hobbsee> hey cgregan
<soren> ogra_cmpc: How does the nic driver land in the initramfs? Do you manually add it to /etc/initramfs-tools/modules?
<ogra_cmpc> depends what kind of initramfs you use
<ogra_cmpc> if your config uses MODULES=most it should be in
<ogra_cmpc> same for MODULES=netboot
<soren> Oh, and that's the default, I suppose.
<soren> most, that is. Not netboot :)
<jpatrick> welcome cgregan :)
<mvo> asac: could you tell me about bug #203538 ? does firefox need a different location than /usr/share/firefox/defaults/pref in beta4?
<ubotu> Launchpad bug 203538 in apturl "Don't work with Firefox3 beta4" [Medium,Confirmed] https://launchpad.net/bugs/203538
<asac> mvo: yes. we have now /usr/lib/firefox-3.0b4/defaults/syspref -> /etc/firefox-3.0/pref
<asac> is it ok to put it in /etc/..
<asac> ?
<mvo> asac: aha, ok. I will change the package then
<asac> mvo: please test before upload. but it should work
<kagou> Riddell, ok let's go testing :)
<asac> mvo: you can keep the old place and depend on '| firefox-2' if you want
<Riddell> ogra_cmpc: you're wanting CDs for beta presumably?
<ogra_cmpc> sure
<pitti> mvo: do you have some time in the next days for verifying bug 198129?
<ubotu> Launchpad bug 198129 in tzdata "Chile delay in 3 weeks the daylight time transition" [Undecided,Fix committed] https://launchpad.net/bugs/198129
<pitti> mvo: (right, deja vu, we had to update tzdata again for that)
<mvo> pitti: aha, sure. how urgent is it? if super urgent, I squeeze it in today
<pitti> mvo: no, it's not; by mid next week would be good, though
<pitti> mvo: the bug will occur on March 29
<pitti> (tzdata is probably the only package which allows us to predict future bugs that precisely :-P)
<mvo> heh :) we should have more of those
<pwnguin> hmm. its too bad CONCURRENCY=shell doesn't work, because it brings my boot down below 20 seconds =(
<pitti> TheMuso, cjwatson: as "happy" broadcom wifi users, do you have an idea about bug 197819?
<ubotu> Launchpad bug 197819 in b43-fwcutter "[Hardy]b43-fwcutter install script fails to fetch firmware in first run" [Undecided,Confirmed] https://launchpad.net/bugs/197819
<Riddell> soren: ready for ubuntu server beta candidates to be built?
<Keybuk> *blink*
<Keybuk> my gpg public key just vanished off my box
<pitti> Keybuk: secret key still intact?
<Keybuk> yes
<jdong> meh you never need your own public key anyway ;-)
<soren> Riddell: Yes, I think now is a good time.
<superm1> asac, well yeah no video issues this time around, but still the wifi doesn't come up nicely on 0.6.6
<soren> Riddell: Er.. Hang on.
<soren> Riddell: When is the beta due out?
<Riddell> soren: thursday
<soren> Riddell: Ah, I somehow convinced myself it'd be today. In that case, I have more stuff I'd like to sneak in, so not today.
<soren> Riddell: Is that cool? I'm not familiar with the processes involved.
<Riddell> soren: hmm, we're in quite deep freeze already
<zdzichuBG> will hardy get mobile broadband support like in fedora? maybe via updates/backports?
<Riddell> soren: it should be important changes only by now
<soren> Riddell: Oh, it's important alright.
<soren> Riddell: I'll run it by slangasek, when he shows up. Cool?
<asac> superm1: so even not with the patch?
<asac> superm1: is there an improvement at all?
<Riddell> soren: fine with me but he won't be awake for another 4 or so hours
<superm1> asac, the improvements with the patch get me connected
<superm1> but not after suspend
<asac> ok
<asac> please attach that information to your bug and post a new syslog
<seb128> asac: do we need to have this network manager editor in the menus?
<asac> superm1: ^^
<superm1> asac, alright
<soren> Riddell: I'm not the one who's in a hurry :)
<asac> seb128: well ... except that there i bugs i don't see why we wouldn't want that
<asac> seb128: ?
<asac> i see that its in multiple places. we can probably fix that
<seb128> asac: it doesn't really seem to be useful, isn't the context menu entry on the applet enough?
<pitti> ryanakca: since you fixed some jockey-gtk bugs (thanks!), are you interested in some more cosmetical things?
<pitti> ryanakca: (in particular bug 197777)
<ubotu> Launchpad bug 197777 in jockey "Need space in error message" [Undecided,Confirmed] https://launchpad.net/bugs/197777
<asac> seb128: its bug 270663
<asac> oops
<asac> seb128: bug 201127
<asac> feel free to milestone if you want it removed
<seb128> asac: thanks
<seb128> asac: well, rather discuss it, I got comments about the preferences menu not fitting on a 1024x768 screen in the default installation
<seb128> asac: so I'm trying to see what we can move away from there
<asac> seb128: i have such a screen on x61 ... it fits here
<seb128> asac: ok, somebody told me that it was touching the bottom panel, I didn't verify
<seb128> asac: maybe it depends of the dpi you are using ;-)
<asac> hmm ... i have both panels on auto-hide
<asac> didn#t change dpi
<_MMA_> seb128: Maybe remove "Main Menu" (Alacarte) as right-click on the menu itself launches it also?
<asac> seb128: without autohide its stiill a bit above the bottom panel
<seb128> ok
<asac> seb128: this is a clean hardy install i did about 3 weeks ago
<seb128> _MMA_: I think people argued it was not discovrable enough
<seb128> asac: anyway I don't want to argue about a few pixels, we have lot of items there and I was just looking if we could simply it a bit
<seb128> maybe we should use applications, system tools again
<asac> sure. if you milestone it on behalf of the desktop team, i will go on and remove it
<seb128> looks like something is installing the hardware testing application there already
<seb128> asac: ok, thanks
<asac> but for final plesae :)
<asac> beta is too close. if i upload anything i will include this fix of course
<seb128> right, not for beta
<seb128> 8.04 is good
<seb128> milestoned
<_MMA_> seb128: Ok. One could argue that windows users are doing the same thing now to edit the Start menu. They seem to find it fine. *If* they are our target audience. I don't mind either way. :P
<seb128> ;-)
<mathiaz> Riddell: what do you think about bug 197476 ?
<ubotu> Launchpad bug 197476 in mysql-dfsg-5.0 "akonadi  does not work with the apparmor rules introduced for /usr/sbin/mysqld on hardy." [Low,Incomplete] https://launchpad.net/bugs/197476
<mathiaz> Riddell: "akonadi starts a user-specific mysqld to store it's PIM data.
<Riddell> mathiaz: I think it should be fixed :)
<Riddell> on the apparmour side
<mathiaz> Riddell: It's unusual that a program would start its own mysqld process
<mathiaz> Riddell: why can't akonadi use the system databases ?
<\sh> relmgr: please approve claws-mail and claws-mail-extra-plugins to hit the buildds/archives
<wasabi> I don't find that really unusual. Completely removes any consideration of security.
<wasabi> To an extend I'd prefer more apps worked like that.
<wasabi> extent
<soren> Could someone please give back virt-manager?
<ogra_cmpc> wasabi, but then its really cleverer to use a serverless db like sqlite
<mathiaz> wasabi: I agree with ogra_cmpc
<mathiaz> wasabi: sqlite has been designed for that
<Riddell> mathiaz: let me try and ask someone
<wasabi> So?
<wasabi> Not everybody wants to use sqlite. ;)
<mathiaz> Riddell: I think the concerns raised by the reporter are valid
<mathiaz> Riddell: I question the use of mysql as a storage backend to fix their concerns.
<Hobbsee> soren: given back
<soren> Hobbsee: Thanks very much.
<Hobbsee> yw
<Riddell> mathiaz: sqlite doesn't work well enough
<mathiaz> Riddell: could you be more precise about what doesn't work well enough ?
<mathiaz> Riddell: or point me to a channel where these things are discussed ?
<Riddell> mathiaz: not really, I'm not an akaonadi developer
<Riddell> mathiaz: #kontact
<wasabi> I think arguing about what technology a given app uses is not helpful.
<wasabi> They chose to use MySQL. They might have had more experience with it.
<wasabi> Or a hundred different factors.
<mathiaz> wasabi: well - I'd like to know why they're using it.
<ogra_cmpc> wasabi, if it doesnt fit our security model its at least friendly t0o suggest something that works right
<wasabi> I agree... I just wonder what's different from using MySQL per-user vs SqlLite per-user.
<ogra_cmpc> or to find out why they cant use something that fits in
<SupaFly> hey how can i participate in ubuntu's development?
<ogra_cmpc> wasabi, one starts a server daemon, the other doesnt ?
<wasabi> But he said it was per-user, no?
<wasabi> Starts a per-user instance of MySQL.
<wasabi> Maybe I misread.
<ogra_cmpc> yes thats what he said
<wasabi> Oh. Does it listen on external ports or something?
<Riddell> ogra_cmpc: you have 20080318.2 CDs to test
<ogra_cmpc> no idea ... but if the policy is to lock down servers to a certain extent for security reasons and such a corner case comes around that doesnt work through that, do you drop the whole policy or do you ask the dev if he cant use something thats supported ?
<ogra_cmpc> Riddell, gracias
<pitti> ryanakca: nevermind, I fixed it myself
<pitti> yay mastering pyqt ;)
<emgent> heya pitti :)
<pitti> Riddell: for bug 193985: is there only myWindowObject.exec_() or a static method like gtk.main() in PyQt?
<ubotu> Launchpad bug 193985 in jockey "jockey-kde crashed with AttributeError in ui_main_loop()" [Undecided,Confirmed] https://launchpad.net/bugs/193985
<cjwatson> Keybuk: is MINKVER="2.6.17" in /usr/share/initramfs-tools/hooks/udev still accurate?
<Keybuk> cjwatson: I think so
<pitti> Riddell: basically I need to process events for the tray icon until it gets clicked; would KApplication.kApplication().exec_loop() work for that?
<Keybuk> untested, obviously
<Keybuk> but there's no reason it shouldn't work
<Keybuk> we include both sets of rules for the old usb devices, etc.
<Riddell> pitti: not for a qt4 app, you need   QApplication.exec_()  I think
<pitti> Riddell: oh, great; I'll try that
<cjwatson> Keybuk: ok, just following up on bug 190281
<ubotu> Launchpad bug 190281 in linux "Segfault in initrd with 2.6.24-7 on intel x86_64" [Medium,In progress] https://launchpad.net/bugs/190281
<Keybuk> err?
<seb128> pitti: do you have any idea of why the policykit-gnome translations are not in the current language packs?
<cjwatson> oh, it's the other way round
<cjwatson> hardy kernel on feisty
<seb128> pitti: danilo said that the template has been imported in rosetta some weeks ago and the translations should be available
<pitti> seb128: oh, I see; I was just going to check for a .pot build
<seb128> pitti: I did check that, and talked with him, the template has been imported correctly
<pitti> argh argh ssh
<pitti> seb128: do you see them in rookery:/srv/language-packs.../hardy/sources-base/ somewhere?
<seb128> pitti: yes
<seb128> pitti: for some locales but not the ones I'm interested in ;-)
<pitti> seb128: upstream package only has Danish translations, nothing else
<seb128> pitti: right, but it has been translated in french on rosetta for example
<Mirv> seb128: and they're translated in Rosetta you're looking at? at least Finnish has made its way to language packs.
<seb128> pitti: though that seems to be recent, so maybe in next update round
<pitti> seb128: right; the previous export came too late and was broken, so I'll do another update on Friday, after beta
<seb128> pitti: ok, seems to not be a bug
<seb128> pitti: ok, thanks
 * pitti hugs seb128
 * seb128 hugs pitti
<Riddell> evand: ready for gobuntu CDs for beta candidates?
<evand> Riddell: hrm, allow me to give them a quick look over.  Pulling downnow.
<\sh> cjwatson: bug #107326 do we have any possibility to fix this in time for hardy?
<ubotu> Launchpad bug 107326 in parted "non working gpt labels" [High,Confirmed] https://launchpad.net/bugs/107326
<cjwatson> \sh: are you in a position to test the result?
<cjwatson> it should be doable, and it's definitely on at least one "fix by hardy" list
<\sh> cjwatson: hopefully next week yes...I'm getting back a machine with 7TB...
<\sh> cjwatson: amd64 that is
<cjwatson> I'll see if we can have a look after beta
<\sh> cjwatson: if it's only a matter of replacing parted with a new version on the alternate cd..I can try over the weekend to tweak the alternate cd we have...
<cjwatson> \sh: no, it's not just a matter of that
<cjwatson> Actual Coding is involved.
<\sh> cjwatson: you mean the sync problem on macs?
<cjwatson> yes
<cjwatson> curiously, http://developer.apple.com/technotes/tn2006/tn2166.html claims that Apple uses a protective MBR
<cjwatson> whereas (we think) it's actually a legacy MBR for legacy BIOS compatibility
<\sh> when I reported the bug regarding broken GPT lables, these days the problem was parted, not writing correctly the partition tables...because I never booted from partitions >2TB...but all partitions >2TB were not usable, because they had a msdos label and not GPT label
<\sh> dapper worked correctly
<\emgent> heya
<cjwatson> \sh: thank you, I understand the problem
<\sh> cjwatson: well, I'm confused now ... I'm trying to figure out what grub has to do with it (reading some comments)
<cjwatson> \sh: not much these days
<cjwatson> well, it impedes better solutions
<cjwatson> I don't really want to explain it now, I'm trying to figure out other things
<cjwatson> like whether there's actually a standard for Intel Mac >2TB disks
<\sh> cjwatson: and I'll try to stop being confused with further readings
<\sh> cjwatson: and if you need someone to test on amd64 hw, next week I'm able to do it
<maswan> you need some testing with >2TB partitions? anything I can help out with?
<maswan> I can find a server or two with a decent ammount of storage
<\sh> maswan: always the very same people, I think ;)
<maswan> We usually don't partition those filesystems though
<cjwatson> 2TB is the (relatively) easy bit; the problem is that what you have to do to cope with >2TB and what you have to do with Intel Macs conflict, and I'm trying to work out what will happen if somebody puts a >2TB disk in an Intel Mac and tries to dual-boot OS X and Ubuntu on it
<maswan> Ah, no macs around here
<cjwatson> which will very likely be the case in the lifetime of Hardy
<\sh> maswan: well, I had to, and it looks like I have to do this in the very near future again :(
<pitti> Riddell: ok, I think I got the jockey-kde notifications fixed; the kde test suite is still a mess, but at least the app itself works now
<\sh> maswan: and again with *censored* areca raid
<cjwatson> (note that I am not saying that the above should impede the >2TB case in general from being fixed in hardy, but it seems like something we need to consider)
<maswan> \sh: oh, they are still bad? hm. hope ours won't be too horrible, we'll get a few delivered soon.
<\sh> maswan: well, the ones we had during combots time ;) which were crashing because of broken firmware...and old kernel drivers...the native ones in newer linux kernels are much better, but firmware was again very bad these days...let's see what the new firmware gives me
<maswan> \sh: ok, hope we'll have less issues. anyway, delivery seems to be delayed, so we might run hardy on them from the start. :)
<\sh> maswan: when you get hands on your controllers, just send me the model number :) so I can think of replacing those old ones :)
<maswan> \sh: sure, if they work. now off.
<cjwatson> I think it may be that >2TB disks on Intel Macs simply have to be an error :-/
 * ogra_cmpc wonders why his rsync is lagging so heavily
<ogra_cmpc> does anyone else have slow rsyncs or is it just me ?
<mvo> siretart: if you don't mind, I would like to upload http://paste.ubuntu.com/5811/
<\sh> cjwatson: >2TB disks in intel mac laptops, for sure...;)
<mvo> bryce: when you uploaded displayconfig-gtk, did you put your changes in bzr?
<Riddell> ogra_cmpc: other people are grumping too
<Riddell> evand: shall I build gobuntu?
<evand> Riddell: it seems the seeds need to be updated
<evand> the install is failing on the missing hwdb-client-gnome issue from a few days back
<ogra_cmpc> my first one was flying ... the second one sits at 4k with 28h to go since 30min already
<evand> working on that now
<Riddell> evand: ok, let me know if you need uploads approved
<evand> Riddell: will do, thanks
<pitti> bryce, tjaalton: hm, can you please tell me if http://launchpadlibrarian.net/12724433/xorg.conf is actually valid? I particularly mean the "  screen 0 "aticonfig-Screen[0]" 0 0
<pitti> " line in ServerLayout
<ogra_cmpc> did anyone try alternate yet ? i'm getting a ton of perl errors here
<ogra_cmpc> hmm, but seems that only spams the log
<evand> Riddell: gobuntu-meta 1.11 whenever you have a free moment.
<mvo> pitti: I updated the information in bug #174128  - if you are happy with the debdiff I will upload it
<ubotu> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/174128
<jdstrand> hi lamont
<jdstrand> lamont: just sent git patch for bug #203528
<Riddell> evand: accepted
<ubotu> Launchpad bug 203528 in bind9 "apparmor profile should be in complain mode on certain upgrades" [Undecided,In progress] https://launchpad.net/bugs/203528
<jdstrand> lamont: this follows the (updated) ApparmorProfileMigration
<evand> Riddell: thanks
<lamont> jdstrand: ok.  for beta, or post-beta?
<jdstrand> lamont: basically, it just makes sure pre-apparmor bind9 upgrades are in complain mode, as well as forcing complain mode the apparmor-profiles is unchanged
<jdstrand> lamont: that was why I wanted to talk to you
<jdstrand> lamont: I *doubt* there will be many dapper-hardy upgrades for beta, but there will be gutsy-hardy
<lamont> true
<jdstrand> lamont: therefore, it probably should go in before
<lamont> ok.  I'll upload and request the sync tonight-ish
<jdstrand> lamont: cool, thanks!
 * jdstrand now goes to update mysql and openldap in the same way
<pitti> mvo: looking
<lamont> jdstrand: if you have a patch for the host-doesn't-print-nameserver list bug too, that'd be wonderful. :-)
<lamont> jdstrand: bug 191530
<ubotu> Launchpad bug 191530 in bind9 ""host" cannot see sites in .org" [Medium,Triaged] https://launchpad.net/bugs/191530
<pitti> mvo: ah, so it was never really a conffile prompt?
<jdstrand> the one we talked about on saturday? sorry, no
<pitti> mvo: does the default DTRT?
 * lamont yawns at bug 203476 - does anything actually _use_ that inet_ntoa>?
<ubotu> Launchpad bug 203476 in bind9 "[libbind9] [CVE-2008-0122] off-by-one error in the inet_network function" [Undecided,New] https://launchpad.net/bugs/203476
<jdstrand> lamont: rh said they don't, in their bug report
<mvo> pitti: frankly, I don't know if the initial thing was "needs-start" or "files-moved-around", I could be mixing the initial report up
<mvo> pitti: the default should be fine, its just a debconf note
<lamont> jdstrand: yeah, and debian has the bug sitting there stale for some time as well.
<jdstrand> I saw that, went 'oh my', and then went, ohh-- backburner
<pitti> mvo: ah, great
<lamont> yeah
<lamont> jdstrand: every now and then, as I read the bug page, I go "HUH!?!?!" and then go "yeah. right."
<jdstrand> haha
<mvo> pitti: ok, if all is cool with the diff I will upload (at this stage of the freeze I like to always double check :)
<pitti> mvo: sure
<lamont> jdstrand: maybe I'll backport that patch from 9.4.3 (or the report) just to shut that up
<jdstrand> oh the fedora one? I haven't looked at it
<lamont> the CVE-2008-0122 thing
<ubotu> Off-by-one error in the inet_network function in libbind in ISC BIND 9.4.2 and earlier, as used in libc in FreeBSD 6.2 through 7.0-PRERELEASE, allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted input that triggers memory corruption. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0122)
<lamont> ah u\botu got smart about CVE too
<jdstrand> yeah, it certianly seems harmless enough
<jdstrand> certainly
 * lamont isnt' on the good mailing list anymore
<jdstrand> https://bugzilla.redhat.com/attachment.cgi?id=292030
<jdstrand> not private
<jdstrand> https://bugzilla.redhat.com/show_bug.cgi?id=429149 is the bug
<ubotu> Red Hat bug 429149 in vulnerability "CVE-2008-0122 libbind off-by-one buffer overflow" [Low,Verified: ]
<infinity> lamont: Aww, quitting HP got you knocked off vendor-sec?
<lamont> infinity: well, it was through hp, so yeah
<ryanakca> pitti: sorry, I'm at school :)
<pitti> ScottK: I don't quite understand why we keep the remaining delta for cyrus-sasl2-heimdal
<pitti> ScottK: libdb-dev is by and large equal to libdb4.6-dev?
<slangasek> soren: what are you running by me? :)
<milli> lamont: you get my patch against 9.4.2?
<pitti> ryanakca: NP, I fixed them all :)
<emgent> asac: ping
<emgent> there is a critical problem in nm-applet on hardy
<emgent> seems dont work with new Intel PRO/Wireless 3945ABG
<emgent> with iwconfig working fine in hardy, but GUI dont work
<asac> emgent: hidden network?
<emgent> asac: no
<asac> everyone i know that has 3945 could connect
<ogra_cmpc> asac, can we get rid of the NM console messages on shutdown for final ?
<ogra_cmpc> they look scary
<emgent> it's an open A.P.
<asac> ogra_cmpc: i never shutdown my system. how do they look like?
<asac> emgent: hmm
<asac> emgent: can you try WPA?
<ogra_cmpc> asac, console messages, debug stuff
<emgent> tried first, same problem
<emgent> i think that it's a problem with device name
<ogra_cmpc> it only blinks up shortly before usplash kicks in with the shutdown screen
<emgent> new ipw driver generated "wlan0_rename" device
<ogra_cmpc> but on first glance it looks like an error msg
<asac> emgent: i have several reports that it works with WPA
<asac> emgent: how far does nm get?
<emgent> asac: false i used WPA TKIP
<asac> do you see one green light at least?
<emgent> nope led too dont work.
<asac> please try to connect now and post your complete syslog somewhere
<emgent> but ipw driver working fine
<emgent> asac: it's impossible, i can only connect with iwconfig, but not in GUI
<asac> emgent: most likely it doesn't work fine; otherwise nm would work :)
<emgent> i cant see the possibility to connect with it :P
<asac> ah
<asac> post /etc/network/interfaces then
<emgent> http://nopaste/p/aJWKMiQGH
<Keybuk> I had that the other day
<Keybuk> it was because something had installed the -386 kernel for me
<emgent> seems see eth0 and lo
<Keybuk> and since -386 < -generic, that's what grub picked
<Keybuk> emgent: what does uname -a say?
<slangasek> bryce: can you help me understand the gnome-control-center upload?  199549 is about settings not taking effect on an i965, doesn't that support xrandr 1.2?  and bug #198951 isn't assigned to gnome-control-center at all; are these fixes that are important for beta?
<ubotu> Launchpad bug 198951 in gnome-desktop "gnome-display-properties crashed with SIGSEGV in screen_info_new() - i855, fglrx, radeonhd" [High,Fix released] https://launchpad.net/bugs/198951
<emgent> 2.6.24-12-generic
<emgent> on i686
<Keybuk> ok, not the same problem then
<emgent> only GUI dont work
<Keybuk> what does iwconfig say?
<emgent> driver working fine to me
<Keybuk> (when run without arguments)
<bryce> slangasek: they could wait until after beta, I think the gnome-settings-daemon fixes may cover us sufficiently.  the gnome-control-center changes just make the new xrandr gui more useful
<slangasek> bryce: ok, I'll sit on it, thanks
<Keybuk> emgent: driver is clearly not working fine, or the GUI would work
<emgent> Keybuk: http://nopaste/p/aI3ckLUNw
<Keybuk> ok
<emgent> i'm connected to wifi no, but only with iwconfig.
<Keybuk> emgent: sudo mv /etc/udev/rules.d/70-persistent-net.rules /root
<Keybuk> then reboot
<emgent> k
<emgent> just a moment.
<lamont> Keybuk: /root... is that your version of a persistent /tmp ? :-)
<Keybuk> lamont: exactly
<emgent> heheh :)
<asac_> emgent: sorry reconnect. did you answer what Keybuk asked you?
<emgent> yes
<Keybuk> he did, just waiting for him to reboot
<asac_> so why does -386 break NM?
<emgent> now working fine..
<emgent> udev rules..
<Keybuk> asac_: it doesn't have the iwl driver in it if you don't install the modules package :)
<Keybuk> asac_: I only got the kernel by some upgrade bug
<asac_> strange
<asac_> but it appears to have ipw3945
<emgent> Keybuk: ok thanks
<asac_> or is that independent?
<Keybuk> asac_: isn't that in linux-ubuntu-modules ?
<asac_> yes i think so
<Keybuk> right
<Keybuk> that's what I didn't get installed
<asac_> but not 100% source
<Keybuk> just linux-image
<asac_> yeah, but emgent appeared to have at least some driver :)
<asac_> thats why i wondered
<Keybuk> I suspect he just had some transient problem
<Keybuk> the reboot cured it
<Keybuk> maybe caused or not caused by that udev rename bug
<asac_> right. lets keep it that way :)
<dneary>  Hi
<dneary>  I've got a .dsc, .diff.gz and _orig.tgz from a Hardy package that I'd like to build on Gusty
<dneary>  Anyone mind running me through generating a .deb from the package files?
<dneary> I'm not exactly starting from scratch, and I've been having lots of trouble going in circles in the packaging guide
<jdstrand> bryce: hi!
<bryce> jdstrand: hey
<Keybuk> dneary: dpkg-source -x DSCFILE ; cd DIRECTORY ; debuild
<jdstrand> bryce: are you aware of any weird bugs with /tmp/.ICE-unix ?
<jdstrand> access to it
<Keybuk> (with build-essential, dpkg-dev, devscripts and fakeroot installed)
<bryce> nope
<jdstrand> hrmm
<zul> mvo: is there a howto to do a LTS->LTS on the wiki somewhere?
<jdstrand> bryce: I can't open terminals, vim hangs, and probably other things
<jdstrand> bryce: strace xterm gives:
<jdstrand> connect(4, {sa_family=AF_FILE, path="/tmp/.ICE-unix/9709"}, 21) = 0
<jdstrand> fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
<jdstrand> write(4, "\0\1\0\0\0\0\0\0", 8)         = 8
<jdstrand> read(4,
<jdstrand> then hang forever
<jdstrand> bryce: I really have no idea what could be causing that-- ever seen anything like it?
<bryce> jdstrand: no I haven't seen bugs with errors in /tmp/.ICE-unix.
 * jdstrand scratches his head
<bryce> jdstrand: I would guess to look first at what changes have happened to your system recently...  we've not done many significant X uploads lately, so my first guess would be something non-X related, but who knows.
 * jdstrand nods
<bryce> jdstrand: also I'd doublecheck resources are okay, clear tmp, restart, etc. etc.
<jdstrand> did all that
<mvo> zul: yes: https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1
<bryce> possibly the .ICE-unix is just a symptom of an underlying issue
<dneary> Keybuk: Thanks
<zul> mvo: thanks!
<dneary> What package does debuild come in, I don't think it's installed?
<mvo> devscripts
<jdstrand> bryce: ok thanks
<mvo> command-not-found should know that too
<dneary> Do I also need fakeroot?
<dneary> thanks mvo
<jdstrand> bryce: was X built since the latest libc6 update?
<mvo> cheers
<dneary> So, yes, I need fakeroot :)
<dneary> or I have to build as root
<dneary> Woohoo! autoconf output!
<bryce> jdstrand: last upload was Mar 13th it looks like
<slangasek> jdstrand: fuser -vm /tmp/.ICE-unix/9709?
<mvo> Riddell: could you please check http://paste.ubuntu.com/5819/ ? this is dapper->hardy
<jdstrand> slangasek: http://paste.ubuntu-nl.org/60069/
<Riddell> mvo: mm, right
<dneary> Keybuk, mvo: Thanks a lot, that's just what I needed.
<Riddell> mvo: any other koffice issues?
<dneary> keysign didn't work because I'm missing the private key, it says
<slangasek> jdstrand: er, oops - I meant fuser -v /tmp/.ICE-unix/9709
<dneary> Anyone know where I can get that?
<mvo> Riddell: not that I'm aware of
<dneary> (OK, I was joking there...)
<jdstrand> /tmp/.ICE-unix/9709: jamie      9709 F.... x-session-manag
<jdstrand> slangasek: ^^
<jdstrand> slangasek: it exists, perms are ok
<jdstrand> I checked the obvious stuff...
<slangasek> jdstrand: yes; the question is really, what's happening at the other end of the socket - x-session-manager may be broken on your system
<slangasek> I don't know if it's sane to try stracing that process, but that would be my next step
<mvo> Riddell: I can have a look later too if you are too busy
<slangasek> (don't know if it's sane -> don't know if your session will survive ;)
<jdstrand> slangasek: I'll wait til my non-screen'd build finishes
<jdstrand> :)
<Riddell> mvo: I can do it
<jdstrand> slangasek: $ strace -p 9709
<jdstrand> Process 9709 attached - interrupt to quit
<jdstrand> restart_syscall(<... resuming interrupted call ...>
<jdstrand> tried launching stuff, but nothing
<jdstrand> oh, let me try -f
<jdstrand> aha!
<jdstrand> [pid  9790] read(24,
<jdstrand> hangs there
<jdstrand> I don't have a pid 9790...
<slangasek> a thread, perhaps
<slangasek> what is x-session-manager on this system? gnome-session?
<slangasek> (x-session-manager is an alternative)
<jdstrand> slangasek: yes
<jdstrand> gnome-session
<slangasek> ok
<jdstrand> I do have /usr/bin/seahorse-agent --execute x-session-manager
<slangasek> well, all I can say is that the two sides of the socket don't agree about whose turn it is to write :/
<Keybuk> mathiaz: really don't add a status to udev
<Keybuk> it'd encourage people to think that "start" and "stop" are useful commands
<Keybuk> when they're not
<Keybuk> if you run either on a real system, you'll break it
<jdstrand> slangasek: somewhat disturbing, as I wasn't actively fiddling with anything.  just 'working'
<mathiaz> Keybuk: sure - for udev it doesn't make sense
<jdstrand> slangasek: this happened once before-- around the libc6 madness (but I never installed the bum version on the system)
 * jdstrand scratches his head more
<Keybuk> mathiaz: it also struck me that your list is pretty much the list of packages that are likely to be the first to go to upstart
<Keybuk> so I'm not sure how much effort it's worth putting into a complex status() command
<mathiaz> Keybuk: well - my target is really hardy
<slangasek> Keybuk: well, I don't think the proposed command was terribly complex either?
<Keybuk> right, but you're adding a potentially complex thing to debug and support
<Keybuk> especially if you're doing more than just pidof()
<mathiaz> Keybuk: as you mentionned, Intreprid would use upstart which is fine by me
<mathiaz> Keybuk: Hardy is going to be around for some time and adding status action to init script is valuable IMO
<mathiaz> Keybuk: I wouldn't defend this idea if hardy wasn't an LTS
<Keybuk> ironically it's precisely because it's going to be around for a long time that it makes me nervous ;)
<mathiaz> Keybuk: I see your point.
<mathiaz> Keybuk: IMO it's worth the tradeoff - the code to add a status action is small and isolated.
<cjwatson> is it good to have a status option for just a few init scripts in an LTS, thereby confusing people because it isn't there across the board?
<mathiaz> Keybuk: I don't think it's worth adding a complex status action that does more than check if the pid is running.
<cjwatson> I don't think you should do a half-baked job of it for an LTS, and I don't think we have time for you to do a full job
<kirkland> cjwatson: it's already in a couple...  postgres, mysql
<Keybuk> mathiaz: what pid?
<mathiaz> cjwatson: well - I think it's better than nothing. Moreover it's already available in some of them.
<cjwatson> kirkland: right, but a tiny minority
<Keybuk> where do you get the pid ?
<mathiaz> Keybuk: it depends on the init script.
<slangasek> mathiaz: btw, your count is off, zul already took the liberty of adding this option to /etc/init.d/samba in his latest upload..
<mathiaz> Keybuk: some init scripts define a PID file.
<Keybuk> mathiaz: exactly, then we start to get into more complicated territory
<Keybuk> and you'll have race conditions with when pid files appear/disappear
<cjwatson> I don't have a problem with it being done gradually, but I don't think it's worth breaking feature freeze for
<mathiaz> Keybuk: some don't.
<mathiaz> slangasek: I know - but I think you mentionned that it reports only smbd.
<mathiaz> slangasek: nmbd should also be checked.
<slangasek> mathiaz: hrm, if you mean my bug reopen, that was about the if-up.d script that was added that doesn't do anything useful
<mathiaz> cjwatson: well - some people would argue that it's a bug.
<cjwatson> it's not
<mathiaz> cjwatson: now I do think it's a new feature
 * lamont mutters about cups/printers.conf having &*)*^*)_ timestamps in it from when cups was last started...
<lamont> that's not something that belongs in /etc
<mathiaz> cjwatson: but looking at the required changes and the testing to be done, it's worth the tradeoff.
<kirkland> slangasek: i had already posted patches for samba, apache, and cron to Launchpad before we started thinking about how to solve this more generally, and posted the lsb- note to ubuntu-devel
<mathiaz> cjwatson: as I said, it's really something that stands out when compared to other distros such as redhat or suse
<Keybuk> I guess I also wonder ...
<Keybuk> *why* would cron ever not be running?
<cjwatson> it won't stand out if we do a partial job
<lamont> what binary is it that implements the gnome session screen lock?
<Keybuk> lamont: gnome-screensaver
<lamont> danke
<lamont> Keybuk: I just restarted cron on a dapper machine where it was not running... nfc why it decided to walk away from the table, though.
<mathiaz> cjwatson: well - some scripts already have a status action. so it's already a partial job.
<cjwatson> why is it worth pushing through feature freeze if it's not going to be complete?
<kirkland> Keybuk: cron, udev -- exactly should always be running.  it would be nice to determine through a common mechanism if they're not, such that a monitor or ebox or a human or some such could take evasive action ;-)
<Keybuk> kirkland: I'd prefer to fix things so that they're never not running
<lamont> nagios?
<lamont> Keybuk: that'd be wonderful
<Keybuk> people actually building things on these status arguments makes me even more against them than before :)
<Mithrandir> Keybuk: software has bugs, systems run out of memory and processes get killed, those kinds of things.
<mathiaz> cjwatson: when we posted the patch to add status to samba init script to the Debian bts, we got a reply right away from users to include it.
<Keybuk> Mithrandir: "respawn"
<mathiaz> cjwatson: so I take the approach that users are really requesting it.
<Mithrandir> Keybuk: people hack on those daemons too, in which case respawn often isn't what you want. :-P
<mathiaz> cjwatson: and I don't think to do everything in one go - it won't be possible.
<Keybuk> Mithrandir: "stop" :-)
<mathiaz> cjwatson: in that particular case, we can really implement it step by step
<kirkland> Keybuk: is it preferable to have people building things on `ps -ef | grep foo | awk bar` ?
<mathiaz> cjwatson: package by package - it's not a big rollout. We just fixe annoyance in everyday life or sysadmin
<Keybuk> kirkland: I'd prefer people waited for the proper fix
<cjwatson> mathiaz: and potentially introduce little niggling bugs
<Keybuk> mathiaz: that's fine during the usual development stages
<Keybuk> but the whole point of freezes is that after them we concentrate on fixing bugs
<Keybuk> rather than the continued deployment of features
<lamont> Keybuk++
<siretart> mvo: ugh darn. good catch! thanks!
 * lamont grumbles at jdstrand for his commit messages
<jdstrand> lamont: ?
<lamont> fix for LP: #203528 (force complain for apparmor on certain upgrades Signed-off-by: Jamie Strandboge <jamie@canonical.com>
<jdstrand> hey, I didn't touch changelog this time!
<lamont> heh
<mvo> siretart: thanks, no problem
<lamont> so the change is that if the package is upgraded, then it's just complain-mode, and enforce-mode on clean installs?
<jdstrand> lamont: not exactly
<jdstrand> lamont: it is complain on pre-feisty package to enforcing package upgrade
<jdstrand> lamont: it is also complain on pre-enforcing but apparmor aware OS
<jdstrand> lamont: and the apparmor profile on the system prior to upgrade is in complain mode
<jdstrand> this is documented in ApparmorProfileMigration
<lamont> apparmor: force complain-mode for apparmor on certain upgrades
<lamont> Set complain mode on upgrades from 1:9.3.4-2ubuntu2 and earlier,
<lamont> rather than enforcing mode.  See also
<lamont> https://wiki.ubuntu.com/ApparmorProfileMigration
<lamont> Addresses-Ubuntu-Bug: 203528
<lamont> Signed-off-by: Jamie Strandboge <jamie@canonical.com>
<lamont> so like that?
<jdstrand> lamont: well, that covers the first case, yes
<lamont> see, if you wrote real commit logs, then I wouldn't have to rewrite  them and get it wrong... :-)
<jdstrand> lamont: but not when upgrading from feisty or gutsy and apparmor-profiles is installed, or usr.sbin.named exists
<lamont> the first line gets added as the changelog entry, with the relevant Addresses-{Ubuntu,Debian}-Bug: entries.
<lamont> the Signed-off-by comes from git commit -s, if you're actually using git to do the formatting... :-)
<lamont> s/formatting/committing/
<lamont> and if there was a bzr UI that actually read _and_wrote_ git backends, then you could just use bzr
<jdstrand> I used git
<lamont> ok.  just throw the -s in and it'll add the signed-off-by line
<jdstrand> that's what I did
<lamont> then something smashed it all together.
<lamont> because it was one line after the git-am
<mvo> Riddell: could you please check http://paste.ubuntu.com/5821/  too ? this is dapper->hardy
<jdstrand> but, I didn't want to be too wordy on the commit, as I quoted the bug, that talks about it and has the link.  *shrug*
<jdstrand> I'll admit I forgot you used the commit message to get the changelog
<lamont> the changelog creation script uses the first line, and the addresses-* lines.  the rest of the log is for posterity and can be as verbose as you want
<jdstrand> ok
<jdstrand> somewhat terse first line, the rest as descriptive as need be
<cjwatson> heno: any word on bug 199129?
<ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New] https://launchpad.net/bugs/199129
<lamont> which also means that the first line wants a 'apparmor:' or such prefix to say what part of bind9 it's mucking with
<cjwatson> heno: especially https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/199129/comments/8, if possible
<ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New]
<Riddell> mvo: ok, fixing
<afflux> screen brightness does not change at all, even echoing to /sys/class/backlight/acpi_video0/brightness does not work. Is this a bug in the kernel?
 * lamont slaps 191530 around, before going back to work for another 20 minutes
<mvo> asac: could you please have a look at http://paste.ubuntu.com/5823/ ? (dapper->hardy)
<heno_> cjwatson: looking
<asac> mvo: looking
 * heno tests it again
<asac> mvo: does dapper have a network-manager-gnome package or is it "all-in-one"?
<mvo> asac: dapper has a network-manager-gnome
<asac> hmm
<asac> mvo: ok that file appears to be shipped by nm inself now
<asac> strange
<amitk> afflux: yes it is known, fix will go in after the beta AFAICT
<afflux> amitk: oh, okay, thanks
<asac> mvo: would a versioned conflict ensure that the package getes removed _before_ unpacking is attempted?
<mvo> asac: I haven't looks at it, but all you need is probably a "Replaces: n-m-gnome (<< version-where-the-file-moved-from-nm-to-nm-gnome)
<mvo> asac: I can have a closer look if you want me
<asac> mvo: yes its NN replaces or conflicts nm-gnome < XXX
<asac> mvo: just not sure if conflicts would be enough
<mvo> asac: ok, replaces should be fine
<mvo> asac: a conflicts is the needed, a replaces really means "replaces files " and that is what happens
<mathiaz> slangasek: I don't see any ubuntu-server iso in iso.qa.ubuntu.com. What's your testing plan for the server isos ?
<mvo> asac: a conflicts is too strong if its just files moving around
<slangasek> mathiaz: to click this 'add build(s)' button right now so they appear
<asac> mvo: well, but we don't want version of NM-gnome considerably lower than NM :)
<mathiaz> slangasek: ah ok. I was just to impatient then...
<asac> mvo: thats why i thought that its more accurate to use conflicts.
<asac> mvo: but i will go with whatever you prefer
<slangasek> mathiaz: no, your comment was what reminded me that I hadn't clicked the button yet, thanks :)
<mathiaz> slangasek: is this the first iso candidates ?
<mvo> asac: heh :) I have no idea aobut the nm package relations - let me have a look first before I make more unqualified comments
<mathiaz> slangasek: I remember heno sending an email about two phases testing or something like that. I wonder how would that apply to the ubunu-server iso
<slangasek> mathiaz: we're in phase two at this point
<slangasek> i.e., full validation of all images
<mathiaz> slangasek: hum... was there something planned for phase one for ubuntu-server iso ?
<asac> mvo: indee
<asac> mvo: independent of that its questionable if that file belongs to NM at ll
<slangasek> mathiaz: I don't know; if so I guess it was coordinated just among #ubuntu-testing
<mvo> asac: yeah, that may actually be the right solution to move it to the -gnome package - the nm package does not have a glade or gtk dependency AFAICS
<asac> mvo: i think the upstream source split led to that. no idea if they forgot to move it
<asac> mvo: added to my todo
<mvo> asac: looks like bug #123772 caused the move
<ubotu> Launchpad bug 123772 in network-manager-openvpn "network-manager-applet no longer produces/provides usr/bin/nm-vpn-properties" [Low,Fix released] https://launchpad.net/bugs/123772
<mvo> asac: that is what the old changelog says
<mvo> asac: I think http://paste.ubuntu.com/5826/ should be enough
<mvo> asac: if you are happy with it, I will commit and upload
<asac> mvo: let me do that
<asac> mvo: i need to add bugs to the other changelog entry thats already on the branch
<amitk> top line from 'top':  5959 amit      20   0 1756m 1.4g 3012 S    0 70.9  12:52.29 compiz.real
<mvo> asac: ok, thanks (even better :) - my changelog is a bit short, you may want to add somehting like "fix file overwrite problem on dapper->hardy upgrades" or something like this
 * mvo hugs asac
<mvo> amitk: is that with nvidia?
<amitk> umm... is it normal for compiz to show 70.9% memory?
<amitk> mvo: no... I have a poor old Intel graphic adapter
<amitk> mvo: Intel Corporation 82G33/G31 Express Integrated Graphics Controller, FWIW
<mvo> 1.4g is quite impressive
<mvo> Amaranth: ---^ have you seen numbers like this already?
<Keybuk> doesn't compiz directly map video memory on newer drivers?
<Keybuk> amitk: can you nopaste /proc/5959/maps somewhere?
<Amaranth> no idea
<amitk> Keybuk: http://pastebin.ubuntu.com/5828/
<mvo> amitk: how long is that system running (i.e. do you always suspend/resume it?)
 * mvo wonders if exa may have anything to do with that
<amitk> Keybuk: result of uptime ->  23:22:01 up  9:22,  6 users,  load average: 0.09, 0.17, 0.34
<Keybuk> amitk: it's all heap
<amitk> Keybuk: no, this machine doesn't suspend/resume, only reboots when there are upgrades to the kernel
<Keybuk> so looks like a genuine leak
<amitk> Keybuk: want me to file a bug?
<Keybuk> amitk: --> mvo ;)
<mvo> amitk: please
<hunteke> where can I find more information about upstart?  will it be included in hardy?
<mvo> amitk: anything special in the plugin settings (i.e. have you played with ccsm)?
<amitk> mvo: I might have, though I could restore it to defaults. Any way to dump current CCSM settings?
<Keybuk> hunteke: what would you like to know?
<mvo> amitk: yeah, it has save current settings in the left-hand side under preferences
<mvo> amitk: the more information you can gather, the better :)
<hunteke> Keybuk: what's holding it back, how a noob can help/get involved with only about 3 hrs/wk to commit to it, why only a few devs care about it . . . I guess some of the esoteric things of "more about it"
<soren> slangasek: I wanted to get your opinion on whether to build the beta now or to wait until I had finished my iscsi changes. It's moot now anyway, though, as I'm not done, and we should get the iso built sooner rather than later.
<SwissPhoenix> Hi folks, I'm using hardy and getting a PANIC on my RAID Controller, files a bug ten day ago, but nobody noticed - just wondering if anybody cares to fix it to the release or if I have to do something more....
<Keybuk> hunteke: to answer your last question first, I guess the primary reason only a few people care about it is that it's beneath the level most people tend to look
<Keybuk> we have some kind of service management today, it just sucks
<Keybuk> and only a few very strange people actually care that it sucks, and want to do something about it to fix it
<Keybuk> and much of the energy of those kinds of people is already distracted by things at the same level like D-Bus, HAL, udev, etc.
<hunteke> Keybuk: I know. :-(  although I'm looking at it from an end-user perspective of "I want linux to beat windows"
<hunteke> :-)
<SwissPhoenix> hunteke: Never use the force to do harm ;
<Keybuk> hunteke: Upstart, at best, gives us feature parity with Windows
<Keybuk> Windows (NT branch, at least) has always had a service management framework
<hunteke> Keybuk: well, then, call it more a "I want a faster boot because sleep is so sketchy right now" less harm oriented for SwissPhoenix ;-)
<amitk> mvo: https://bugs.edge.launchpad.net/ubuntu/+bug/203715
<ubotu> Launchpad bug 203715 in ubuntu "compiz eats lots of memory" [Undecided,New]
<Keybuk> hunteke: Upstart won't give you a faster boot
<Keybuk> it will just give you a boot where the order that things happen is no longer important
<asac> slangasek: network-manager 0.6.6-0ubuntu2 knocks on your door
<Keybuk> (which means we can take out a lot of sleep statements and busy loops)
<hunteke> no? I thought it was event based so a lot of the serialization could be parallelized
<hunteke> but I suppose also sleep statements removed
<Keybuk> it's event based so we can do things when we can do them
<Keybuk> rather than doing things in the hope that we can do them
<hunteke> hehe, point
<Keybuk> the first question is that it's not being held back
<Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk/changes
<Keybuk> there's been a vast amount of development in bzr
<Keybuk> this hasn't reached Ubuntu because Ubuntu is doing an LTS release
<Keybuk> and some of the development is a bit exciting
<Keybuk> (I've been hanging around cjwatson too long and am getting conservative in my old age)
<SwissPhoenix> If anybody cares: Its bug#199934, so far I'm using an gutsy kernel which works...
<hunteke> oh gosh, Keybuk, you're main dev on upstart (just whoised you).  Before I go any farther, let me say thank you for your work.
<Seveas> Keybuk, how's they grey hair doing? :)
<Keybuk> Seveas: heh, if I was taking that much after Colin it'd be going red, not grey
<Seveas> lol, true that
<Seveas> it'd also be a tad longer
<Seveas> Keybuk, do you plan to break intrepid the minute hardy has been released, or will we have to wait for upstart goodness a bit longer?
<Keybuk> depends
<Keybuk> D-Bus and I have yet to become friends
<Seveas> that's tough love
<Seveas> I'm fighting the pythin bindings now, there seems to be something in there that's less than optimal when sending a message
<Seveas> and I'm sending a lot of messages :)
<jdong> what are the hard dependencies of starting gdm?
<jdong> of course x11-common and checkroot'ed
<jdong> but is dbus actually needed before login?
<Keybuk> absolutely
<Keybuk> since the gdm greeter will need dbus
<Keybuk> and hal, and policykit, and consolekit, etc.
<jdong> oh ok
<jdong> so I'm getting too greedy :)
<jdong> Keybuk: is there a way to use initctl to block until some event has happened? (i.e. start X first then have early gdm init block until dbus is ready)
<Keybuk> gdm starts X
<Keybuk> that's kinda the point
<Keybuk> GNOME *DISPLAY MANAGER* :)
<jdong> Keybuk: well the VT switching into X on my macbook takes like 3-4 bloody seconds
<jdong> Keybuk: I'm wondering if that could be taken care of in a more parallel manner :)
<Keybuk> jdong: that's fixed by other bits of work in progress
<jdong> that's good to hear
<wasabi> I hear mode switching will move into the kernel, so modes won't have to be switched when changing VTs and such, unless resolution actually changes.
<Keybuk> exactly
<Keybuk> getty-gtk ;)
<wasabi> usplash should leave it in the right res for GDM
<wasabi> getty-gtk sounds awesome.
<wasabi> How far are we from all that?
<Keybuk> I've seen people actually using it now
<wasabi> Seriously? Wow.
<Keybuk> which is a good step up from seeing people demo it
<Keybuk> so end of the year maybe before it's in shippable drivers
<Keybuk> (where it = kernel mode setting/TTM/Gallium3D/etc.)
<soren> I've seen interfaces get renamed to eth?_renamed a few times before... What's that all about?
<wasabi> That's exciting stuff. Can't wait to see it all come together.
<Keybuk> soren: interface renaming
<soren> Keybuk: No kidding? :)
<Keybuk> soren: it's about renaming interfaces from one name to another :)
<Keybuk> so, the kernel is a bit thick
<soren> Keybuk: Oh. This is very enlightening.
<soren> :)
<Keybuk> it has a counter
<soren> Right.
<Keybuk> every time it sees a new interface, it increments that counter, and names it that
<soren> I realise why we rename them.
<Keybuk> so the first interface the kernel sees is eth0
<Keybuk> the second one is eth1
<Keybuk> and so on
<soren> Sure, sure.
<soren> I got that.
<soren> I also get the persistent naming and all that.
<Keybuk> unfortunately the kernel doesn't see them in any kind of consistent or useful order
<wasabi> So usplash starts, puts monitor in right mode, initramfs finishes quickly, upstart comes up, something can send job status text from upstart to usplash if we care, then X appears. No clicking or anything.
<Keybuk> so we have to rename them
<Keybuk> the problem is when the kernel sees A=eth0 and B=eth1
<Keybuk> but we want B=eth0 and A=eth1
<Keybuk> the only way to resolve that deadlock is to rename them to something else
<soren> Keybuk: Ah.
<Keybuk> so udev names A=eth0_rename B=eth1_rename
<Keybuk> then renames A=eth1 and B=eth0
<soren> Makes sense.
<Keybuk> sometimes this comes a bit unglued when it tries to rename A and B to the same thing
<Keybuk> so you end up with A=eth0 and B=eth1_rename
<Keybuk> this tends to happen with mac80211 devices which have both a wmaster0 and wlan0 interface
<soren> Right. This is in the installer with two identical NIC's (different MAC's though).
<Keybuk> and udev thinks they should both be wlan0 or eth1
<Keybuk> it shouldn't ever try and rename two things with different MACs to the same name
<soren> These are realtek 8139 nic's.
<Keybuk> address matching is on MAC
<ion_> Obvious solution: create a program that changes the bytes directly in /dev/kmem.
<soren> Yeah, I know.
<soren> Hmm..
<Keybuk> wasabi: upstart starts in initramfs, hands over to upstart in real system
<wasabi> We're going to get it to that?
<soren> Maybe the peristent-names-generator is racy somehow.
<Keybuk> soren: shouldn't be
<wasabi> I saw your latest upstart release thing fly by. I was excited to see it coming along.
<soren> No, persistent-net.rules looks fine.
<soren> Hm...
 * soren scratches his head
<Keybuk> it happens *inside* the installer?
<soren> Yeah.
<Keybuk> that's not doing anything crazy like killing udev, right?
<soren> Ah, sorry. I've booted into rescue mode on the server cd, but I belive I saw the same in the real installer.
<Keybuk> do you have /var/log/udev you can nopaste for me?
<soren> 70-persistent-net.rules *is* odd, now that I think about it.
<soren> The rules look like:
<Keybuk> can you nopaste that too? :)
<soren> SUBSYSTEM=="net", ACTION=="add"; ATTR{type}=="1", NAME="eth0"
<Keybuk> there's a ";" there?
<soren> Mistyped.
<Keybuk> ok
<soren> The interesting bit is the lack of a mac.
<Keybuk> yeah that's VERY interesting :)
<Keybuk> that means there was no address node in sysfs for that card
<Keybuk> is there one now? :)
<Riddell> ogra_cmpc: edubuntu dvds for beta?
<soren> Keybuk: Yep.
<Keybuk> weird
<Keybuk> can you nopaste both for me?
<soren> Quite.
<soren> Keybuk: Do you have kvm capable hardware?
<Keybuk> soren: how do I find out?
<soren> Keybuk: grep -E '(vmx|svm)' /proc/cpuinfo
<Keybuk> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
<soren> Great.
<soren> Then you do. install kvm, and fire it up like so:
<seb128> soren: I guess that virt-manager limiting cursors move to the wrong area until you move it on the right is a known issue?
<Keybuk> soren: I do?
<Keybuk> soren: neither of those things is in there
<mvo> amitk: thanks!
<soren> Keybuk: Oh, I thought that was the output of the grep.
<soren> Keybuk: (the output would be the empty string if you didn't have them)
<Keybuk> :)
<soren> ..so I didn't really look all that closely.
<Keybuk> no, I was mentally grepping and pasting in case I had anything else useful in there that you recognised
<Keybuk> in fact
<Keybuk> none of my machines have either of those
<soren> Shame.
<Keybuk> this is an Athlon 64 X2
<Keybuk> the laptops are Intel Core Duo U2500 and Core 2 Duo T5550
<Keybuk> they don't have it either
<mvo> ogra__: do you handle moodle? I get a upgrade problem from stock dapper->hardy with it
<soren> Keybuk: Yeah, there are a few models of C2D's that don't. Those might be the ones :)
<soren> Keybuk: You want the udev log and the persistent-net.rules?
<soren> Keybuk: Was that it?
<Keybuk> yup, please
<LaserJock> mvo: what kind of problem?
<soren> wtf... There's no /var/log/udev.
<crimsun> LaserJock: keep in mind the delta between dapper and dapper-{security,updates}
<soren> Keybuk: I'm finding myself increasingly unable to construct coherent sentences. I need sleep :) I'll look at it tomorrow morning.
<crimsun> LaserJock: namely, debian/{postinst,templates}
<mvo> LaserJock: not sure yet, it seems to got stuck at a ucf prompt at dapper->hardy, I need to investigate further
<LaserJock> crimsun: sure. I was going to say that a lot has changed in moodle since dapper
<LaserJock> mvo: ucf?
<crimsun> mvo: dapper's stock moodle has that nasty debconf bit (i.e., fails to install)
<mvo> crimsun: interessting, I have it in my dapper image, that indicates that it somehow got installed without failure
<mvo> LaserJock: package urc: Description: Update Configuration File: preserve user changes to config files.
<mvo> LaserJock: meh, make that "package: ucf"
<crimsun> mvo: was moodle installed before or after apache?
<crimsun> I vaguely remember discussing this with Martin a couple years ago
<ScottK2> pitti: On cyrus-sasl2-heimdal, yes, today libdb-dev and libdb4.6-dev is the same, but there's no guarantee in the future.  Since cyrus-sasl2-heimdal needs the same version as cyrus-sasl2, we needed an ubuntu1 version in any case and so we might as well keep the better build-dep.  That's my view anyway.
<mvo> crimsun: that is a very good question :)
<pitti> ScottK2: ah, right, that version identity; I see
<pitti> ScottK2: thanks for confirming
<pitti> ScottK2: btw, I just fixed that 'apport crashes on guidance' bug (I hope), in unapproved now
<mvo> crimsun: hm, it seems like moodle is a fresh install, not a upgrade (brought in by edubuntu something)
<Riddell> evand: gobuntu oversized :(
<evand> ARGH!
<ScottK2> pitti: Great (I hope).  At least I'll know the truth then ..
<soren> Keybuk: No /var/log/udev in the proper installer either (I was in the installer's rescue mode before)
<Keybuk> that's odd
<Keybuk> maybe they don't make one
<mvo> crimsun: I can not install moodle in a pbuilder chroot here, it hangs and the process list shows me there is something ucf releated going on (but no prompt or anything)
<mvo> (not sure that I should talk to you about it :)
<mvo> or is ogra a better person to ask here?
<mvo> hm, pressing "\n" helped
 * mvo scratched his head
<crimsun> mvo: the last time I touched moodle was for dapper-updates
<crimsun> so no, I'm probably not the best WRT hardy
<mvo> ok, thanks crimsun
<LaserJock> mvo: the newer packages were done by moquist
<mvo> LaserJock: does he do irc?
<LaserJock> in #edubuntu sometimes
<mvo> last update in gutsy ... hmmm
<soren> Keybuk: Oh.. I think I may have an idea.
<LaserJock> mvo: yeah, that's when we did a major repackaging and got it into Main
<mvo> LaserJock: thanks a lot, I will look into it and see what I can do
<LaserJock> mvo: we did a lot of changes to debconf stuff, it's possible something broke when we did so
<Keybuk> soren: what is your idea?
<soren> Keybuk: I just noticed the persistent-net-generator.rules weeds out nic's with locally assigned mac addresses.
<soren> ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
<moquist> mvo: LaserJock clued me in. What's up?
<soren> Keybuk: Hm.. The macs start at 52:54:00:12:34:56 where the last octet is increased for each nic.
<soren> Keybuk: They should be alright.
<mvo> hello moquist! I was having trouble with moodle and was wondering if you might help, I can not install it in a pbuilder chroot, it hangs and only continues if I press "enter" (but there is no prompt)
<mvo> moquist: it hanged in my auto dapper->hardy upgrade test, this is why I came to it
<mvo> moquist: I run with DEBIAN_FRONTEND=noninteractive, so it might be something that is not easily triggered
<soren> Keybuk: Er... No. I'm on crack.
<soren> Keybuk: That *does* match that pattern, so the mac is cleared.
<soren> Anyhow.. Bed time.
<soren> Long over due.
<mvo> moquist: I suspect its something to do with debconf and/or ucf - something like a leftover file descriptor or something equally crazy
<mvo> (in the postinst)
<moquist> mvo: You're working with a version of the package that I've never touched; I didn't work on it until gutsy, really.
<mvo> moquist: this happens in a hardy pbuilder chroot too
<mvo> moquist: but give me a bit, I'm looking into it - I *think* the call to dh_stop might be the problem
<moquist> mvo: ah! And thanks for all the diagnosis.
<mvo> moquist: so if I move handle_config before db_stop all seems to be fine. I have little clue about this package, so if you could double check that I'm not on crack, that would be much appreciated
<moquist> mvo: I'm checking into it now.
<mvo> moquist: great, thanks a lot!
<nxvl> i'm having a problem with Bug #203710
<ubotu> Launchpad bug 203710 in mysql-dfsg-5.0 "mysql-server-5.0 does not prompt for conffile update on upgrades" [High,Confirmed] https://launchpad.net/bugs/203710
<nxvl> i can't find out why is that it isn't recognizing the configfile as changed
<jdstrand> nxvl: conffile
<Keybuk> is it a conffile or a config file?
<nxvl> conffile
<Keybuk> sure?
<jdstrand> Keybuk: it's a confile as seen in /var/lib/dpkg/status
<jdstrand> hrm conffile
<Keybuk> jdstrand: what are the exact two packages involved here?
<Keybuk> (URLs to .deb files, please)
<jdstrand> Keybuk: well, the 'upgrade to' package was one I was working on, but I didn't change anything
<jdstrand> Keybuk: with the conffiles
<nxvl> Keybuk: http://paste.ubuntu.com/5837/
<jdstrand> Keybuk: nxvl has some IIRC
<Keybuk> jdstrand: do you have the one you were working on and the one you had before?
<nxvl> i do it upgrading from gutsy to hardy
<jdstrand> Keybuk: nxvl confirmed it with gutsy version to hardy version
<jdstrand> Keybuk: if you give me a minute, I can fire up a gutsy vm and upgrade
<nxvl> i did it from: https://edge.launchpad.net/ubuntu/gutsy/+source/mysql-dfsg-5.0/5.0.45-1ubuntu3
<nxvl> to https://edge.launchpad.net/ubuntu/hardy/+source/mysql-dfsg-5.0/5.0.51a-3ubuntu2
<nxvl> using pbuilder environment
<Keybuk> nxvl: i386?
<nxvl> Keybuk: yep
<jdstrand> Keybuk: mine was amd64
<Keybuk> which package?
<nxvl> mysql-server-5.0
<jdstrand> nxvl: did you also see it with mysql-common (with my.cnf)?
<nxvl> jdstrand: with my.conf it asked
<Keybuk> d'ling...
<Riddell> ogra_cmpc: your dvds are nastily oversized
<mvo> lamont: this http://paste.ubuntu.com/5841/ is probably a bug for you, right?
<nxvl> jdstrand: it seems that it isn't recognizing it as a conffile -> http://paste.ubuntu.com/5843/
<ScottK2> doko: If you're around I'd like to discuss python-xml transition for a moment?
<jdstrand> Keybuk: just confirmed bug bites on a gutsy to hardy upgrade (both clean installs) on amd64
<jdstrand> Keybuk: during install happened to get:
<jdstrand> $ md5sum ./debian-*
<jdstrand> 7ac6cab7c0c2efaaaca2691b4ec3d6ec  ./debian-start
<jdstrand> 4272e4d740c8ae651ac35bbf4d2ed6dc  ./debian-start.dpkg-new
<jdstrand> and of course /var/lib/dpkg/status had:
<jdstrand>  /etc/mysql/debian-start 4272e4d740c8ae651ac35bbf4d2ed6dc
<nxvl> jdstrand: how did you get that?
<nxvl> got*
<jdstrand> nxvl: just lucky timing :)
<Keybuk> so you installed 5.0.45
<Keybuk> modified debian-start
<Keybuk> then installed 5.0.51a ?
<jdstrand> nxvl: ran md5sum after unpack but before postinst
<Keybuk> and it didn't prompt?
<nxvl> Keybuk: yep
<jdstrand> Keybuk: yes
<jdstrand> it's kooky
<nxvl> jdstrand: oh!
<jdstrand> nxvl: -v
<nxvl> jdstrand: yes, i already did that
<jdstrand> Keybuk: I did not know of a way to prevent dpkg from prompting on a conffile
<Keybuk> jdstrand: ?
<jdstrand> Keybuk: I am simply puzzled by the behavior
<jdstrand> Keybuk: I have not seen it before
<Keybuk> someone remind me how I disable debconf? :p
<mvo> export DEBIAN_FRONTEND=noninteractive
<Keybuk> thanks
<Keybuk> D000020: process_archive conffile `/etc/mysql/debian-start' no package, no hash
<Keybuk> ok, so that's sensible on first install
<nxvl> Keybuk: where did you get that output?
<Keybuk> nxvl: dpkg
<jdstrand> nxvl: --debug
<nxvl> thnx
<nxvl> :D
<Keybuk> -D77777 actually
<Keybuk> D000020: deferred_configure `/etc/mysql/debian-start' (= `/etc/mysql/debian-start') useredited=-1 distedited=-1 what=204
<Keybuk> ok
<Keybuk> sensible on first configure
<Keybuk> I have edited that file
<Keybuk> Conffiles:
<Keybuk>  /etc/init.d/mysql 4f0c573e38f141149bd19e4a929305b9
<Keybuk> and edited to
<Keybuk> 347d7585c6ba7936e4d11ed0b1df8b0e  /etc/mysql/debian-start
<Keybuk> err
<Keybuk>  /etc/mysql/debian-start 4272e4d740c8ae651ac35bbf4d2ed6dc
 * Keybuk pastes the right line from status
<doko> ScottK: discuss what? just remove it ;)
<Keybuk> ok, so now let's unpack 51a
<Keybuk> D000020: process_archive conffile `/etc/mysql/debian-start' package=mysql-server-5.0 same hash=4272e4d740c8ae651ac35bbf4d2ed6dc
<Keybuk> and install
<chadmiller> Hi.  I haven't made a new .deb in /years/.  What's the recommended tool these days to boostrap making a new package?
<chadmiller> I mean, initialization with example debian/* files and such.
<ScottK2> chadmiller: Packaging questions are best on #ubuntu-motu
<Keybuk> D000020: deferred_configure `/etc/mysql/debian-start' (= `/etc/mysql/debian-start') useredited=1 distedited=0 what=2
<Keybuk> nxvl, jdstrand: I am seeing no bug here
<Keybuk> could you be a little more specific about what you're expecting to happen
<Keybuk> and more importantly, *why* you're expecting that to happen
<chadmiller> ScottK2: Thanks.
<jdstrand> Keybuk: why didn't it prompt on upgrade?  the file changed, the package installed a new version
<jdstrand> scratch
<nxvl> Keybuk: if i edited debian-start, dpkg should ask me if i want to keep the edited file or update it
<Keybuk> file hasn't changed
<jdstrand> ist didn't install a new version, but should have prompted to install the new version
<nxvl> Keybuk: and it's not asking, just ignoring it
<Keybuk> no it shouldn't
<nxvl> so
<jdstrand> Keybuk: it isn't the same as the old one, so it is non-default
<jdstrand> granted, it didn't overwrite it
<Keybuk> why should it prompt?
<nxvl> what you ar saying is that as the packaged debian-start from old and new version are the same, dkpg shouldn't ask?
<Keybuk> right
<nxvl> s/ar/are
<jdstrand> and I agree
<jdstrand> it is that the file on the system changed and is like neither the old installed version, or the new
<nxvl> so, if i change debian-start on the new package and try to install it, then it should promt, didn't it?
<jdstrand> s/new/new installed version/
<nxvl> jdstrand: yes, but as the 2 packaged conffiles are the same, there is no problem with the changes i have done to the file (if i have understood correct)
<nxvl> Keybuk: didn't it?
<Keybuk> right
<jdstrand> oh-- because the md5 of 5.0.45 and 5.0.51a were the same, we can keep the changes and be reasonably sure things are ok
<nxvl> jdstrand: yep
<jdstrand> and that just happened to also be the case for the file I was working with
<jdstrand> man, I feel like a dumbass
<jdstrand> Keybuk: thanks for your time on this
<nxvl> i'm rechecking packing a changed version of debian-start, just to be sure
<nxvl> well, at least i learn a lot about packages wasting my time on this bug :D
 * jdstrand goes and makes a note of this subtelty
 * nxvl HUGS Keybuk and jdstrand 
 * jdstrand and appreciates dpkg even more
<jdstrand> nxvl: I invalidated the bug
<jdstrand> nxvl: thanks for your time
<jdstrand> too
<nxvl> jdstrand: heh, i was doing it right now
<nxvl> :P
#ubuntu-devel 2008-03-19
<jdstrand> lamont: *sigh* I forgot a postrm snippet in the bind9 patch
<jdstrand> lamont: I didn't see that you committed yet
<ScottK2> jdstrand: Would that explain: Reloading AppArmor profiles /sbin/apparmor_parser: Unable to replace "/usr/sbin/named".  Profile doesn't conform to protocol
<jdstrand> ScottK2: no, this is an uncommitted patch
<ScottK2> OK.
<jdstrand> ScottK2: was that on hardy?
<ScottK2> jdstrand: Is ^^^ something I should file a bug on then?
<ScottK2> Yes
<jdstrand> ScottK2: absolutely
<ScottK2> Just dist-upgraded from Gutsy to hardy.
<ScottK2> That was during the upgrade.
<jdstrand> ScottK2: oh-- no that is expected until reboot
<ScottK2> Ah.  OK.  So if it perists after reboot, then file a bug?
<jdstrand> ScottK2: yes
<ScottK2> perists/persists.
<ScottK2> OK.
<ScottK2> Rebooting then...
<jdstrand> ScottK2: the protocol did change in the kernel, and the profile takes advantage of it
<ScottK2> That was the most exciting thing that happened using apt-get dist-upgrade.
<ScottK2> So that's good news then.
<slangasek> asac: thanks for triaging your milestoned bugs :)
<jdstrand> ScottK2: heh
<lamont> jdstrand: I didn't push it
<jdstrand> lamont: yeah I saw
<jdstrand> lamont: I just emailed to LP
<lamont> want me to push so you have something to fetch and generate a change against?
<jdstrand> lamont: no, I'm good
 * lamont goes looking
 * jdstrand *just* sent it
<lamont> well, I'm after-hours so I'm not exactly looking at my mailbox and such
<jdstrand> lamont: I wasn't sure LP or your mailbox would have it yet ;)
<jdstrand> LP does though
<lamont> heh.  yeah, we'll want that patch
<jdstrand> yeah, a dangling symlink would be a no-no
<jdstrand> thanks lamont!
<lamont> meh.  -s dude
<lamont>   [Jamie Strandboge]
<lamont>   * apparmor: force complain-mode for apparmor on certain upgrades.  LP: #203528
<lamont>   * debian/bind9.postrm: purge /etc/apparmor.d/force-complain/usr.sbin.named Signed-off-by: Jamie Strandboge <jamie@canonical.com>
<lamont> what version of git are you running???
<jdstrand> 1:1.5.4.3-1ubuntu1
<lamont> hrm
<jdstrand> I did:
<jdstrand> git add foo
<lamont> and it looks like you said -s
<jdstrand> git commit -s
<lamont> and something wrapped it up onto line 1.
<lamont> maybe it wants a blank line or it sucks them together?
<lamont> so you're ready for me to upload -8 then?
<jdstrand> lamont: that would be fantastic
<lamont>   bind9_9.4.2-8_i386.changes: done.
<lamont> Successfully uploaded packages.
<lamont> jdstrand: there you go.  convincing slangasek to take it before beta is left as an exercise
<lamont> if he blesses it, I'm happy to upload a -7ubuntu1 == -8
<jdong> lol I'm not sure how to argue a bind security vuln in an esoteric function as a beta blocker :)
<slangasek> lamont: what's the incentive for this being in beta?
<lamont> jdong: nah - that was just there and I kicked it
<jdong> It doesn't help with heart attacks for certain.
<jdong> (apologies for medical pun)
<lamont> slangasek: it fixes apparmor the way jdstrand and the rest of the crackheads want it
<lamont> which gets bind9 testing on upgrades prior to release
<slangasek> jdong: you only need to apologize for coming up with a medical pun before I had a chance to
<lamont> and why am _I_ trying to argue his point for him???
<jdong> slangasek: I'm sorry :)
<lamont> slangasek: it's certainly not a beta-blocker.
<lamont> nor even an alpha-blocker
<slangasek> lamont: because you're here and I'm here :)
<lamont> hell, it's not even desktop.  although ISTR it _is_ shipseed, yes?
<lamont> heh. point
<slangasek> it's on server, whatever that seed's called
<jdong> slangasek: I'll save the alpha blocker pun for you. It could be inflammatory.
<slangasek> heh
<lamont> slangasek: the issue I have is that, well, it's _tuesday_.  and I don't personally see it as worth holding the show for.  OTOH, it's barely _in_ the show, since next to nothing actually depends on the packages.
<lamont> i guess bind9-host or dnsutils might have made it into standard?
<lamont> yep
<lamont> *2.  I win
<lamont> slangasek: I _DO_ most certainly want it in before beta is a couple of days old.  I don't particularly care which order they arrive in
<lamont> esp since doing it "right" means waiting until after tomorrow's dinstall run...
<slangasek> lamont: ok,well, to have it in for beta I think I would need a more eloquent justification than "the crackheads want it". :)
<lamont> slangasek: given that if I was in your shoes, the answer would be "-1 until friday", I have a hard time coming up with a better argument....
<slangasek> pitti: hnngh, this apport is making me want to take out a red pen and correct the spelling of the python class names
<slangasek> pitti: but somehow I don't think that's appropriate during a beta freeze ;)
<lamont> slangasek: if you stab it in the eye, it doesn't have to start as a red pen...
<slangasek> s/apport/& diff/
<ScottK> slangasek: It would be nice to have pitti's apport upload at or soon after beta as we are currently getting almost no automatic crash reporting on Guidance bugs due to an issue that's fixed in that upload.
<slangasek> ScottK: already accepted
<ScottK> slangasek: Thanks. (need to be careful what I ask for, I may get it).
<xjkx> i have a question that i believe only the devs know. i am studying the boot thing, trying to boot it using a grub config, i put the kernel to be the casper/vmlinuz, and the initrd to be casper/initrd.gz. But it stops booting in the middle of the process and gives me a simple bash ! what am i missing ? i've read the isolinux.cfg file trying to figure out any cool parameters, and i found boot=casper and some others but nothing seems to work
<xjkx> on isolinux.cfg we have  file=/cdrom/preseed/ubuntu.seed is it important ? i dont think grub has that special word "file"
<xjkx> so i am not using the "file" thing on grub config
<xjkx> i forgot to mention i am trying to boot the livecd, on grub.
<xjkx> i have a grub in disk
<wasabi> Hmm. So any plans to do stuff to the updator that asks to replace config files?
<wasabi> It's sort of going to hit people as we start introducing more user friendly ways to edit config files (system-config-printer comes to mind)
 * lamont ->home
<wasabi> I don't think my mom is capable of making a decision on which lines of cupsd.conf she should merge.
<xjkx> wasabi, are you a dev ?
<wasabi> Define 'dev'?
<wasabi> xjkx: Sounds like it's not able to find /   Does it say unable to mount ROOT?
<wasabi> And it sounds like you're screwing with casper. Which most likely means a livecd
<xjkx> wasabi, errm, developer...? no it doesn't say unable to mount root. i think it does mount, it gives me a shell i can do some simple commands, wait, i will bot it now and tell you how exactly it is
<wasabi> (initramfs)?
<xjkx> yes
<wasabi> You need to start by explaining what you're trying to do.
<xjkx> i have a grub inside the disk, and i want to load ubuntu trough it :)
<xjkx> i told where the kernel is, and it boots the kernel, but i think it wants something else
<wasabi> You need to start by explaining what you're trying to do.
<xjkx> "Busybox v 1.1.3 (debian 1:...) built-in shell (ash) initramfs." this is what i get, no error messages :( what i am trying to do is to boot the livecd from grub ;)
<wasabi> So you're in the initramfs.
<xjkx> yes
<xjkx> which is not where i want to be
<wasabi> And a message was spit out to the initramfs?
<xjkx> no, just the initramfs, like if it was bash $
<wasabi> There should have been a message printed out.
<wasabi> Above the prompt.
<wasabi> I fnot, read the casper script. :)
<TheMuso> wasabi: That doesn't always happen.
<xjkx> busybox v 1.3...enter help...is that ?
<xjkx> thats what is above
<wasabi> Nope.
<wasabi> Read the casper scrpt.
<TheMuso> wasabi: I actually reported a bug against the kernel this morning related to similar simptoms, usually udev/kernel can't resolve a device node/block device type etc.
<wasabi> udev should be async. initramfs waits for ROOT
<TheMuso> In my case, there was no message.
<wasabi> After 5 minutes, you should get a message.
<wasabi> He's doing stuff with casper.
<wasabi> which I'm just not familiar enough with
<TheMuso> wasabi: Sorry, this was also related to the live CD.
<TheMuso> And particular modes that my new machine's mobo's SATA controllers can be set to...
<xjkx> where is the casper script
<TheMuso> Within the initramfs, it is /scripts/casper
<wasabi> boot=casper refers to /scripts/casper-*
<TheMuso> It may be easier however to download the casper bzr branch and read things that way.
<wasabi>  /scripts is in the initramfs. Just install casper on a desktop machine and look at it in /usr/share/initramfs-tools/
<wasabi> Or use bzr
<wasabi> or cat from the initramfs. :)
<xjkx> maybe /scripts is on a installed system, i see no scripts folder anywhere inside the live mounted image, but there is a /casper
<wasabi>  /scripts is in the initramfs
<xjkx> oh
<xjkx> will check
<xjkx> wasabi, i am reading with cat file |more. and seeing no reason for it to stop there :p
<xjkx> usually, it stops on initramfs for what reason ?
<wasabi> ROOT does not appear.
<wasabi> Or it hits a break point.
<wasabi> xjkx: break it early in the process and run each step manually.
<wasabi> And just see what does not work right
<xjkx> speaking of root, i did not specify any root= parameter on grub part "kernel /casper/vmlinuz", if i am supposed to put, what should i ? root=/cdrom ? or it should not have the root= on kernel anyway ? By typing F6 to see what parameters casper gets, i saw no root= :p
<xjkx> not sure if it means something but the root folder on initramfs is empty
<xjkx> wasabi, i found a way to get a error message above, by removing some parameters :p here it is: check root= bootargs. or missing modules, dropping to a shell
<xjkx> i am almost sure its the root= thing
<xjkx> just not what to put on it
<TheMuso> xjkx: A live CD normally does not have a root= specified.
<TheMuso> I'm running an amd64 disk now on another box, and its nowhere to be found in the kernel command-line.
<TheMuso> When you specify to boot casper, its assumed that you are booting into a live filesystem.
<xjkx> yea, it should work the way it is :/ grub has the vmlinuz, and the initrd, what else it wants...not even god knows i think hehe
<TheMuso> xjkx: Got another box you can try on?
<xjkx> i tried both my father's and mine
<xjkx> not sure if you were reading since the beginning what i am trying to do. i am trying to boot it not the normal way, but using grub, ever tried doing that ? :p
<TheMuso> xjkx: Yes, but in this case, I don't think grub is the problem.
<TheMuso> However, the output of cat /proc/cmdline from within the intiramfs would help to make sure of this.
<TheMuso> initramfs
<StevenK> I thought the LiveCD used syslinux, anyway
<wasabi> It does. No reason you can't load the kernel/initramfs with grub.
<xjkx> it uses isolinux to boot, if thats what you mean
<superm1> and actually i have loaded it's kernel/initramfs from grub
<wasabi> I have a flash based system using casper that does that.
<superm1> make sure you use the one in the casper/ directory though
<wasabi> Stores the root file system on a FAT32 partition on a CF disk.
<superm1> (there are two kernels on the disk)
<xjkx> someone here recommended me a cat /proc/cmdline, and it shows only the parameters i gave to kernel, in this case, i have a boot=casper, i had more, i even copied all the F6 button shows on the normal booting
<xjkx> when i pass nothing to kernel, cat /proc/cmdline is empty
<TheMuso> xjkx: Mind posting the contents of /proc/cmdline please?
<xjkx> thats it. boot=casper, only :P
<xjkx> what were you expecting ?
<TheMuso> More than that, thats for sure.
<xjkx> maybe we found the problem, if there should be that lot of things
<xjkx> here it just shows the parameters i pass to kernel
<TheMuso> xjkx: Sounds to me like you haven't included everything on the command-line that is found in isolinux.cfg.
<xjkx> if i want it to don't return anything by cat /proc/cmdline, i'd just remove the boot=casper in the kernel arguments
<xjkx> not this time, but i had one more complete, wait, i will show you my last one
<xjkx> file=/preseed/ubuntu.seed boot=casper quiet splash
<TheMuso> hrm ok.
<xjkx> its what we see in isolinux.cfg: ppend  file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz quiet splash --
<TheMuso> xjkx: And the standard live CDs boot fine, i.e with isolinux?
<xjkx> yes
<TheMuso> I'm out of ideas.
<xjkx> yea its a bit complex hehe
<lifeless> whats up
<xjkx> all the other distributions worked on that grub thing just reading isolinux.cfg, and only ubuntu is driving me crazy with that :p maybe i should try older versions
<xjkx> lifeless, trying to boot the live with grub. whats up there ?
<lifeless> well it should work
<lifeless> reading scrollback
<xjkx> TheMuso, my last guess is that grub doesn't know the word FILE that isolinux uses
<xjkx> yea, it should :/
<lifeless> you need a full valid grub config, I am pretty sure grub can't parse isolinux.cfg
<xjkx> yea, what would you put on grub to load the casper kernel on the live ?
<lifeless> I can't remember offhand
<lifeless> but basically I'd read the isolinux.cfg, then tell grub the kernel, init, and the boot parameters
<lifeless> which will need ot include root=, boot=, etc
<xjkx> yea, i kinda did that, except the root= part, because there is none on isolinux.cfg
<xjkx> and i woldn't know what root= would look like
<xjkx> to a cdrom
<lifeless> boot up using isolinux
<lifeless> and look at proc/cmdline
<xjkx> good idea :p but it wouldn't stop on initramfs
<lifeless> add break=premount to the command line using advanced mode
<lifeless> or boot the etnire way and look once its loaded
<xjkx> :o lets see
<lamont> jdstrand: Mar 18 21:33:29 mix kernel: [178113.278726] audit(1205897608.689:44):  type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/var/lib/misc/shadow.db" pid=31082 profile="/usr/sbin/cupsd"
<lamont> I find that annoying.
<lamont> (nsswitch pointing at 'db' makes lots of stupid things try to read the shadow.db file.  this is a bug.
<lamont> (including gnome-screensaver... most annoying when one cannot unlock the screen...)
<neh> is there anything I can do with bug 172300 so that it doesn't get overlooked for hardy?
<xjkx> lifeless, i passed the exact same parameters and still did not work, i am giving up :P
<xjkx> exact same as cat /proc/cmdline on the normal live
<TheMuso> xjkx: Any reason why you want to use grub?
<xjkx> yes, multiboot
<TheMuso> xjkx: Does isolinux not work for that?
<xjkx> not sure
<xjkx> never really used isolinux :p and i am much more familiar with grub anyway
<sladen> xjkx: never boot an Ubuntu CD ?
<sladen> xjkx: never booted an Ubuntu CD ?
<xjkx> i did, but never edited the things myself
<xjkx> i used the config they created for me, i mean, you created for me
<xjkx> TheMuso, but thats a good point, i will google isolinux to do what i want
<xjkx> maybe there is a hope
<xjkx> TheMuso, sladen are you a dev?
<TheMuso> xjkx: Yes I am.
<TheMuso> But my knowledge of isolinux/grub is practically non-existant.
<xjkx> can i ask what do you do as a developer ? i frankly have no clue on how they split the jobs, and i wouldn't know how to help if i could, or what to study to help out
<TheMuso> xjkx: Well, I got involved because I was interested in helping improve a particular area of Ubuntu, and thats how everybody else gets involved. Find something that you are interested in, and learn about it. If you want to make it better, thats the perfect place to start.
<TheMuso> xjkx: You always tend to want to learn more if it is for something you are interested in working on.
<xjkx> oh, I see. thanks.
<TheMuso> xjkx: You're welcome.
<ogra_cmpc> WOAH
<ogra_cmpc> did anyone here ever try "gnome-session --help" in a commandline ?
<ogra_cmpc> *try
<ogra_cmpc> (dont do it)
<TheMuso> ogra_cmpc: lol
<ogra_cmpc> thats *evil*
<TheMuso> Let me guess. It starts GNOME dispite the --help flag?
<ogra_cmpc> yeah
<tjaalton> not here
<TheMuso> Why am I not surprised.
<ogra_cmpc> tjaalton, what do you get ?
<tjaalton> gnome is running already though :)
<tjaalton> ogra_cmpc: a summary of the options
<ogra_cmpc> i didnt let it start up fully, but it attempts to start the session here
<slangasek> neh: currently that bug is marked as 'incomplete'; do you know what information is missing, and can you provide it?
<slangasek> neh: bug #172300, that is
<ogra_cmpc> tjaalton, is that hardy ?
<tjaalton> ogra_cmpc: yep
<ogra_cmpc> strange
<ogra_cmpc> hmm, k, might haven been fixed since 2.21.93-0ubuntu1 (which is what this classmate image has)
<ogra_cmpc> i'll check again on another image before filing a bug
<tjaalton> this box was dist-upgraded yesterday
<ogra_cmpc> yeah, dist upgrading is a bit to much for that tiny thing here
<neh> slangasek: not sure I can provide the requested info for that bug, so I'll try to get in touch with ogasawara_ and see how I can help
<neh> ogasawara_: let me know how I can help with bug #172300 ... I made the latest comment on it and would be happy to help get it fixed if I can.
<ogra_cmpc> asac, cant answer you in pm with that account :) but had my mobile ready ;)
<ubotu> neh: Error: Could not parse XML returned by Ubuntu: HTTP Error 404: Not Found
<Amaranth> Hobbsee: seems your bot has problems...
<slangasek> neh: currently, the missing information is "what happens if you boot with the irqpoll" option - do you know how to edit your boot options?
<Hobbsee> Amaranth: damn.  it was working.
<neh> slangasek: my machine boots fine with irqpoll, and never finishes booting without it
<slangasek> neh: then I guess that's the missing info ogasawara_ requested, perhaps you could send that to the bug report?
<slangasek> neh: and follow the link on the side panel to 'nominate' the bug for hardy
<neh> slangasek: I mentioned that in the comment I already made on the bug
<slangasek> neh: oh, so you did; sorry, I'm half blind and half distracted
<Hobbsee> Amaranth: has there been a LP release or something in between?
<warp10> Good morning
<Amaranth> Hobbsee: probably
<slangasek> neh: in that case, nominate the bug as I mentioned; I'll also reset the bug state to 'triaged'
<neh> slangasek: heh, I guess it is buried in the comment, easy to miss.
<neh> and I just nominated it
<slangasek> ok
<slangasek> that should get it on the radar, I think
<Hobbsee> Amaranth: *mutter*  *grumble*
 * Amaranth wonders how psyco would make a completely IO bound python app go faster
<RAOF> Amaranth: Is this something that you're seeing?
<Amaranth> RAOF: No, something a user claims to see in a bug report where they ask me to add psyco support
<neh> slangasek: Great. I really hope it gets fixed, it would be strange to have an ubuntu release not boot on my machine. :-)
<RAOF> Amaranth: To what?  Alacarte?
<Amaranth> yeah
<RAOF> Um... yeah.  Right.
<RAOF> Completely _user_ bound.
<ogasawara_> neh:  care to attach your dmesg output to the bug report
<neh> ogasawara_: from a regular gutsy boot?
<Hobbsee> Amaranth: yeah, iehter i'm using it wrong, fo they've changed the xml.  *sigh*
<ogasawara_> neh: preferably hardy
<Amaranth> RAOF: hey, that's part of the I ;)
<RAOF> Amaranth: True :)
<asac> ogra_cmpc: thx ;)
<dholbach> good morning
<Hobbsee> morning dholbach
<Amaranth> wow, some guy gave me _way_ too much information for what is an obvious dupe of the "broken titlebar on maximized windows" bug
<Amaranth> morning dholbach
<dholbach> hiya Hobbsee
<dholbach> hey Amaranth
<neh> ogasawara_: ok, I can only boot hardy with irqpoll when both drives are attached, so will that do?
<ogasawara_> neh: that's fine.  would you also be able to maybe attach a digital photo of your screen when you boot without irqpoll?  Just curious what the errors are.
<ogasawara_> neh:  it's bedtime here for me so I'll check the report again in the morning
<neh> ogasawara_: sleeptime for me as well, I'll get you the info as soon as I can. thanks for looking at the bug. :-)
<ogra_cmpc> asac, the first image didnt rip out the cron scripts for scrollkeeper and mandb, i guess cron kicked in
<asac> ogra_cmpc: ok. i can do a fresh install if you say that there are better images available
<ogra_cmpc> asac, the 20080318 one should be the best so far, just running the build for  the 19 image
 * highvoltage is on the 20080318 image and it installed and seems to be working without a hitch
<highvoltage> (will do some proper testing tonight though)
<asac> ogra_cmpc: if you provide me a link i can test it
<ogra_cmpc> http://people.ubuntu.com/~ogra/classmate/images/hardy/
<asac> though this particular bug probably takes a day to show up
<ogra_cmpc> you can now zsync the images if you like
<ogra_cmpc> instructions are on the page
<pitti> Good morning
 * ogra_cmpc waves at pitti 
<pitti> slangasek: apport spelling fixes> bug report appreciated :)
<StevenK> Morning pitti
<slangasek> pitti: s/subscribtion/subscription/g :)
<pitti> slangasek: that's a bug in p-lp-bugs...
<pitti> oh, heh, it was fixed recently
<pitti> bugbase.py:    subscribtions = subscriptions = (property decl)
<slangasek> oh, ok :)
<pitti> slangasek: fixed in trunk, thanks
<ogra_cmpc> heh, why did i read bugbabe.py above
<pitti> ogra_cmpc: Freud would have an answer, I'm sure
<ogra_cmpc> heh
<slangasek> probably one involving insects, given Freud
<Amaranth> asac: the only other useful information i could automatically grab from the system is .xsession_errors and output from lspci but that's only useful for blacklisting bad cards/drivers
<Amaranth> i can't make apport automatically run compiz under valgrind :)
<slangasek> heh
<asac> Amaranth: hmm. nothing else that might help to narrow down? ... e.g. like loaded kernel modules and so on?
<Amaranth> asac: apport does that automatically
<Amaranth> well, it tells me whether they use nvidia or not, anyway
<slangasek> are there any lighter-weight memory debuggers than valgrind that we could try building a special compiz binary against?
<Amaranth> *shrug*
<Amaranth> tbh I barely know how to use valgrind :P
<asac> i am not sure, i had luck that crashes happened earlier if run under gdb.
<Amaranth> never run compiz under gdb
<Amaranth> unless you have a second machine handy and ssh server enabled
<asac> thats a bad start i'd say :)
<Amaranth> when you run into the crash gdb stops compiz
<slangasek> valgrind is the king because it lets you debug binaries post-hoc; but the overhead is nasty, it might be better to get something like ElectricFence into the picture
<Amaranth> compiz is the thing updating your screen...
<slangasek> Amaranth: well yes; that's why you run it from tty1 :)
<Amaranth> and hope alt-sysrq-r works because ctrl-alt-f1 won't
<asac> Amaranth: ... you could run that in a screen or something
<asac> oh
<asac> right
<slangasek> erm, ctrl-alt-f1 should still work
<Amaranth> i think it depends on what compiz was doing when it crashed
<slangasek> it's handled by the X server... or is compiz just evil enough that it stops X/kernel from resetting the tty? :)
<Amaranth> but i don't think building compiz with electricfence is going to help much if i haven't even gotten volunteers for valgrind :P
<Amaranth> no one has said "that's too hard" or "that is too slow"
<stgraber> you can still install a SSH server on your box and then connect from another one to run gdb/debug tools, no ?
<Amaranth> yeah
<slangasek> Amaranth: well, my point is that you seem to have stopped trying to get volunteers in the most obvious place :)
<asac> yes, but everything that cannot easily done by a tweaked test-package is most likely too much to get wide spread feedback
<Amaranth> oh, electricfence is no good
<slangasek> because?
<Amaranth> would be harder to use than than valgrind
<Amaranth> because it stops the process and launches gdb
<slangasek> mm
<Amaranth> and that requires two computers and ssh
<slangasek> that's a bit much, yes
<slangasek> is libdmalloc any better?
<slangasek> (sorry, I usually rely on valgrind, I just don't think that's a likely choice here)
<Amaranth> dmalloc seems to just spit out a log, might be better
<slangasek> does it trap memory errors and send a sigsegv?
<slangasek> that would be crucial
<Amaranth> not sure, it seems rather complicated
<Amaranth> it probably makes breakfast for you too
<Amaranth> i'll look into it tomorrow
<fabbione> morning guys
<fabbione> pitti: you around by any chance?
<pitti> hey fabbione! *hug*
<Hobbsee> morning fabbione, pitti
<fabbione> hey Hobbsee
<fabbione> pitti: hey dude....
 * pitti hugs Hobbsee, too
<fabbione> pitti: one very quick question... what's the reason why there are no ddebs for make-dfsg?
 * Hobbsee hugs pitti back :)
<fabbione> pitti: last time make was built was in feisty
<fabbione> pitti: could that be the reason?
<pitti> fabbione: the .ddeb retrieval system really sucks
<pitti> fabbione: ah, that could be as well
<fabbione> pitti: ok.. thought so
<pitti> sometimes the apt-ftparchive processes get stuck, etc.
<fabbione> pitti: are you still in charge of it?
<fabbione> (i mean do you have powers to go and poke?
<pitti> yes, I think so
<fabbione> would you mind to check that for me please?
<pitti> fabbione: there's not even a m/make directory
<fabbione> indeed
<pitti> so, since it hasn't been built for ages, there's no chance to revive it from teh buildds, sorry
<fabbione> ok
<fabbione> thanks
<pitti> they remove ddebs after 7 days
<pitti> so this needs a no-change rebuild
<fabbione> what do you mean they remove ddebs after 7 days?
<pitti> fabbione: the buildds only keep them for 7 days, otherwise the buildds would explode size-wise
<fabbione> ah ok
<fabbione> yes that makes sense
<pitti> thus we have to fetch them within a week to ddebs.u.c.
<fabbione> gotcha
<fabbione> thanks a lot
<soren> Oh, they're not moved around automatically by sbuild or something?
<pitti> usually we fetch every 4 hours
<pitti> but sometimes solar radiation breaks something
<fabbione> or lunar rays...
<pitti> soren: I wish soyuz would fetch and archive them automatically :)
<soren> pitti: Yeah, I can imagine. :)
<ogra_cmpc> oooh fabio is here
<fabbione> pitti: keep wishing.. it might happen at some point in 2020 :P
 * ogra_cmpc hugs fabbione 
<fabbione> hey ogra_cmpc
<soren> pitti: I wonder what would happen if they were added to the binary .changes file.. :)
<pitti> soren: I guess soyuz would either ignore them or reject the upload
<Hobbsee> pitti: or blow up.
<soren> pitti: In the long term, that seems like the right approach, though.
<pitti> absolutely!
<cprov> soren: it would failed-to-upload, since we don't know yet how to process dddebs.
<pitti> I already discussed that with Daniel Silverstone years ago
<soren> cprov: Ok.
<asac_classy> ogra_cmpc: install worked fine
<asac_classy> :)
<ogra_cmpc> cool
<ogra_cmpc> do you like the new artwork ?
<ogra_cmpc> :)
<stgraber> ogra_cmpc: got screenshots ?
<ogra_cmpc> not yet :)
<ogra_cmpc> it looks like edubuntu :)
<ogra_cmpc> just a lot smaller :)
<stgraber> ok :)
<asac_classy> ogra_cmpc: yes the new background looks fine
<ogra_cmpc> did you do a german install ?
<asac_classy> did the icons in application change as well?
<asac_classy> not german... i can do if you want
<ogra_cmpc> they should be gartoon all over the place
<asac_classy> yeah i can confirm that there is no icon that doesn't fit in the theme
<ogra_cmpc> good
<asac_classy> but i am probably the wrong person to ask on artwork opinion
<ogra_cmpc> the Places menu used to have the wrong folder icons
<ogra_cmpc> but that should be fixed
<asac_classy> places is fine, right
<ogra_cmpc> good
<asac_classy> there is still no discharge info btw
<ogra_cmpc> i just found that putting /tmp in a tmpfs if you have limited ram is a vetry bad idea :P
<ogra_cmpc> *very
<asac_classy> obviously
<asac_classy> how about swap :)
<asac_classy> loike to add 64M more
<ogra_cmpc> not for hardy, but there is compcache i'd like to examine for intrepid
<ogra_cmpc> http://code.google.com/p/compcache/
<ogra_cmpc> swapping kills the flash drive
<ogra_cmpc> so no opportunity to swap to disk
<slangasek> hmm, why does rhythmbox come with a list of default radio stations pointing at a non-existent ubuntu.hbr1.com?
<saispo> hi
<saispo> vim maintainer is in this room ? :)
<ogra_cmpc> there is no vim maintainer :)
<saispo> a team ? :)
<asac_classy> ogra_cmpc:  sounds tricky
<ogra_cmpc> all packages are group maintained in ubuntu
<asac_classy> but most likely an option
<seb128> slangasek: bug #183825
<saispo> ogra_cmpc: vim is not synced to the latest debian version
<ubotu> Launchpad bug 183825 in rhythmbox "rythmbox switching radio streams brings up error "Couldn't start playback: Unknown playback error"" [Low,Incomplete] https://launchpad.net/bugs/183825
<saispo> hi seb128 :)
<ogra_cmpc> asac, well, compcache seems to be the right thing
<seb128> lut saispo
<seb128> slangasek: it's on my list of unread mails = to upload after the freeze
<asac_classy> ogra_cmpc: how
<seb128> slangasek: nobody noticed that they changed those before
<asac_classy> important is testing german?
<ogra_cmpc> not really
<ogra_cmpc> i do it anyway
<asac_classy> ok
<asac_classy> i guess its covered  enough by your tests then
<slangasek> seb128: ok, cheers :)
<ogra_cmpc> for the asian langs testing is important, but that needs someone whio actually can read that stuff :)
<asac_classy> if you have more images to test let me know
<asac_classy> i will see if this thing locks up in a day or two again
<ogra_cmpc> i do dailies ... testing every once in a while would help
<asac_classy> you do any official beta?
<ogra_cmpc> nope
<ogra_cmpc> but an official release
<seb128> slangasek: about bug #147045, could I see the gtkrc?
<ubotu> Launchpad bug 147045 in gnome-control-center "gnome-appearance-properties hogs processor even after close" [Medium,Confirmed] https://launchpad.net/bugs/147045
 * ogra_cmpc kicks gvfs in the nuts
<ogra_cmpc> you bad bad thing you
<seb128> slangasek: do you have gtk-qt-engine installed and did you use KDE on this machine?
<pitti> ah, thanks to whoever fixed displayconfig-gtk to say that resolution change only happens after re-login
<seb128> ogra_cmpc: heh!
<seb128> ogra_cmpc: gvfs rocks, be nice with it ;-)
<slangasek> seb128: I don't use KDE; I had a hand-modified gtkrc from long ago to get me emacs-compatible keybindings
<ogra_cmpc> seb128, nautilus is to slow in unmounting lopp devcies ... my scripts are scattered with sleep commands since we switched to gvfs
<ogra_cmpc> *loop
<slangasek> seb128: but yes, can send the .gtkrc over
<seb128> ogra_cmpc: slow to umount? what do you do and how slow is it?
<asac_classy> ogra_cmpc: just experienced a d&d hang ... e.g. hadn to kill ffox before i could use desk again
<ogra_cmpc> asac, remove the /tmp line in fstab, that fix is only in the latest installer
<ogra_cmpc> its likely atht ff runs out of ram
<asac_classy> k
<ogra_cmpc> seb128, i'm mounting a unionfs from squashfs and ext3 image ... two loop mounts and the union on top ... on unmount i remove the dirs ... all that runs on my ltsp server whch also runs a desktop constantly ... so for every loop mount i get a nautilus win ...
<slytherin> are there any archive admins here? package 'freemind' is using openjdk to build. And it;s other dependencies are in main (ant, imagemagick). It should be moved to universe
<asac_classy> ok let me umount
<asac_classy> rather reboot i guess
<ogra_cmpc> if i come to umount there is susally still a nautilus accessing the dir
<asac_classy> :)
<ogra_cmpc> yeah, reboot :)
<dholbach> thekorn: good morning
<asac_classy> ogra_cmpc: looks better
<ogra_cmpc> yeah
 * asac_classy back to other work
<ogra_cmpc> feels faster i guess as well
<asac_classy> yes
<ogra_cmpc> :)
<ogra_cmpc> thanks for testing
<asac_classy> welcome
<mvo> lamont: if you have a moment, review/comment on #203849 would be great
<ogra_cmpc> hey hivo-cmpc
<davmor2> soren: ping
<Yoe> hi -- is it still possible to ask for a sync of nbd? or are you guys too far into a release to do that at this point?
<hivo-cmpc> hey  ogra_cmpc!
<hivo-cmpc> I'm supposed to be working real hard now, but saw you and asac-classy talking and couldn't resist :)
<ogra_cmpc> hehe
<ogra_cmpc> yay for toys
<asac> hivo-cmpc: thats ok :)
<soren> davmor2: Wazzup?
<davmor2> soren: are you working on virt-manager?
<soren> davmor2: Yes.
<davmor2> soren: is there a reason I can't select cd-rom?
<soren> Probably.
<soren> :)
<soren> Are you connected to qemu:///system or are you running as root?
<davmor2> qemu:/// I think not root
<seb128> does anybody has an opinion on bug #83604 (see current comment)
<ubotu> Launchpad bug 83604 in ntp "ntpdate 1:4.2.2.p4+dfsg-1ubuntu2 has a flawed configuration file." [Undecided,Confirmed] https://launchpad.net/bugs/83604
<\sh> seb128: question is, if we still want to use ntpdate .. ntpd configured to sane ntp servers should be enough in this case, and no doubled work
<seb128> \sh: time-admin has a "sync now" button using it
<siretart> Yoe: it doesn't seem to be a new upstream release that would bring in new feature, right?
<Yoe> eh, nobody?
<\sh> seb128: grmpf...:(
<Yoe> siretart: eh, well, there are some new features in the debian packaging
<seb128> \sh: and if we have ntpdate installed it should be working
<Yoe> such as initramfs support etc
<Yoe> other than that, no
<\sh> seb128: yes, I agree...how do we come around the problem "ntpd is running, ntpdate will fail" in this case (just asking)?
<seb128> \sh: time-admin enable the sync now button only when ntp is not used
<seb128> \sh: you can select manual or automatic syncing there
<siretart> Yoe: I would think that after the beta release it was reasonable to sync nbd. but I'd need to investigate the debdiff more closely
<seb128> automatic is ntp
<seb128> manual is no syncing but it let you trigger ntpdate
<Yoe> siretart: okay. Do I need to poke you a few more times, or will you take care of it?
<ogra_cmpc> siretart, ugh
<ogra_cmpc> siretart, whats in new nbd we need ?
<seb128> I'm wondering why we have an empty /etc/ntp.conf installed in fact
<siretart> Yoe: I think ogra is more familiar with the nbd package. perhaps you two could clear the matter directly?
<seb128> it's shipped by no package according to dpkg
 * ogra_cmpc is worried, ltsp relies 100% on nbd
<Yoe> well, I don't know how close you guys are to a release, I don't follow ubuntu
<ogra_cmpc> i wouldnt want to break that
<Yoe> I just care about it, and would think that these new features would be nice to have
<ogra_cmpc> Yoe, the nbd patches come from ltsp ... likely a patch that vagrantc sent in
<Yoe> but if you are too close to a release, there's nothing critical in there
<seb128> soren: please fix virt-manager to boot not only when ran for the first time, I've enough to delete images and recreated those at every run ;-)
<siretart> Yoe: see topic. we are pretty close to beta release
<ogra_cmpc> right
<Yoe> oh, okay
<\sh> seb128: the answer is in the bug
<Yoe> well, hold off then
<soren> davmor2: That's your problem then.
<soren> seb128: Er... What? :)
<Volans> Hi, I have a question about the dialog of gnome-volume-manager in case of encrypted partition, it does not display the device to be mounted as in Dapper, can I ask someone (maybe seb128 or lool ? I'm not sure :) )
<\sh> seb128: it looks like, that the ntp.conf is generated somehow when you hit sync now at least on feisty
<davmor2> soren:  So you need to run virt-manager as root then?
<ogra_cmpc> Yoe, i will take a look, but its unlikely that i'll pull it in if there isnt any improvement in the areas we use anyway
<Yoe> ogra_cmpc: okay.
<soren> davmor2: No.
<seb128> \sh: ah, right
<Yoe> ogra_cmpc: like I said, I don't think there's anything critical
<\sh> seb128: and I just reproduced it on hardy
<soren> davmor2: You can choose to connect to qemu:///system instead (if you're a member of libvirtd group).
<seb128> Volans: gvfs is used now there
<ogra_cmpc> YokoZar, thanks for the pointer though
<seb128> \sh: alright, should be easy enough to fix, just not create the empty file
<ogra_cmpc> bah
<seb128> soren: I try using virt-manager for iso testing
<seb128> soren: I don't want to do an install, just boot the iso when I try bugs
<seb128> soren: but when I stop the machine and start it again it doesn't boot it, it just complains about not bootable disk
<seb128> soren: not sure if I'm clear ;-)
<\sh> seb128: I wonder if we can find the bugger in NTP.pm of system-tools-backend
<Volans> seb128: I'm in Gutsy now, I dont'have tried in Hardy... you think it will change?
<seb128> Volans: yes, it changes, hardy uses gvfs and not gnome-volume-manager
<seb128> \sh: that's a task for somebody who likes perl, ie not me ;-)
<davmor2> soren: ta I'll try again
<Volans> ok, I will wait for Hardy :) The only strange thing is that in Dapper it will show the device, and in Gutsy not. Thnaks
<Volans> *Yhanks
<soren> seb128: Ah, right. Yes, it behaves differently the first time you boot a vm.
<soren> seb128: This is by design, and for most use cases it's really what you want it to.
<seb128> soren: well, it boot the first time you mean
<seb128> then it doesn't
<soren> seb128: First time it boots from the CD. Subsequently, it'll try to boot from the hard drive.
<seb128> couldn't it do what  a really bios do
<seb128> try one device and then the next one
<seb128> like disk first and then cd drive?
<seb128> so if I've no bootable OS installed it would still boot the cd image
<ogra_cmpc> seb128, is there a fix already for hiding the /cow and /rofs mounts on the CD ? i'd like to look at it for the classmate as well
<seb128> ogra_cmpc: I've no clue about the CD and how it hides mounts
 * ogra_cmpc forgot the bug # but i know there is one open
<soren> seb128: Well, kvm supports it, but virt-manager doesn't expose it. :(
<soren> seb128: For now, you need to specify which (one) device you want to try to boot from.
<soren> seb128: Except the first time, where it'll always try the cd.
<seb128> soren: is there a way without editing the config file by hand?
<soren> seb128: Er.. Sure, there's a gui option to change the boot device.
<soren> seb128: On the VM details page -> hardware tab -> boot options.
<seb128> soren: ok, will try that, thanks
<soren> seb128: :)
<\sh> seb128: I'll have a look on a fix this evening...
<seb128> \sh: thanks
<ogra_cmpc> seb128, thats bug #188229
<ubotu> Launchpad bug 188229 in nautilus "[Hardy] rofs and cdrom icons shown on LiveCD desktop" [Medium,Confirmed] https://launchpad.net/bugs/188229
<ogra_cmpc> wasnt /cow, sorry i remembered wrong
<\sh> crimsun: any update on the flash -> no sound issue?
<\sh> whoobs...ogra is maintainer for libflashsupport?
<ogra_cmpc> WFM
<ogra_cmpc> just tried youtube on classmate :) doesnt seem that libflashsupport is ion the way here
<ogra_cmpc> *in
<\sh> ogra_cmpc: libflashsupport doesn't work properly actually
<\sh> ogra_cmpc: select another soundoutput device then the default one (e.g. usb headset) and you only hear sound from the onboard card (the default device)
<ogra_cmpc> its used since over a year in ltsp ... i'm unsure if you should have it for non networked sound though
<ogra_cmpc> i didnt add it to the deps
<\sh> ogra_cmpc: remove libflashsupport and it works as expected
<\sh> ogra_cmpc: well it's a dep of flashplugin-nonfree
<\sh> and yiour education-desktop-other
<ogra_cmpc> my ?
 * ogra_cmpc doesnt know that package
<ogra_cmpc> thats likely from debian-edu  ... nothing to do with me
<\sh> ogra_cmpc: oh it's debian-edu
<ogra_cmpc> and i didnt add it to the flash deps
<ogra_cmpc> no idea who did that
<ogra_cmpc> i only did the libflashsupport package ...
<ogra_cmpc> simply because we need it in ltsp
<\sh> ogra_cmpc: I wonder if it's a reasonable change to remove it from flashplugin-nonfree as dep and add it to a package which needs it...(imho somewhere in your ltsp packages)
<ogra_cmpc> dont blame me for stuff others did with it :)
<stgraber> it probably was added to flash's depends when we switched to pulseaudio
<\sh> ogra_cmpc: I don't blame anyone :)  I need to fix this problem somehow...
<\sh> Timo Aaltonen <tepsipakki@ubuntu.com>  harhar
<stgraber> but IIRC flash can use alsa's dmix and so does pulse so I don't see why we would need it ... (except for LTSP of course)
<ogra_cmpc> stgraber, right
<\sh> stgraber: yes..
<ogra_cmpc> it's only really helpful with networked sound i think
<\sh> stgraber: so I would remove this dep from flashplugin-nonfree
<ogra_cmpc> but the person that added it might have had reasons
<\sh> ogra_cmpc: well, it just doesn't work on plain desktop installs
<ogra_cmpc> i think the nspluginwrapper setup needs it in lib32
<ogra_cmpc> (for amd64 arch)
<\sh> ogra_cmpc: the problem occurs on amd64 :) dpkg -r --force-all libflashplugin fixes it
<seb128> ogra_cmpc: what are the mountpoint of the things listed in the desktop which should not?
<\sh> ogra_cmpc: same applies on i386
<ogra_cmpc> seb128, you actually done really have mountpoints for them, they are bind mounted from before the unionfs gets merged out of /cow and /rofs
<ogra_cmpc> well, you have mountpoints but no real devices
<seb128> ogra_cmpc: right, just to know, debian has a patch to not show /live/cow, but if we use /cow rather we need to update it
<ogra_cmpc> we do
<ogra_cmpc> can you point me to the patch ?
<ogra_cmpc> i need to skip all my local mounts on the classmate
<seb128> ogra_cmpc: look to the current glib2.0 debian patches
<ogra_cmpc> ugh, its a glib patch?
<seb128> yes
 * ogra_cmpc was hoping for some easy option
<seb128> did it use to work before hardy?
<seb128> because we had a similar gnomevfs change
<seb128> but it listed /live/cow and not /cow too
<ogra_cmpc> i didnt see the loop devices with gnomevfs
<ogra_cmpc> i have a lot of loop mounts on a classmate
<ogra_cmpc> and some bind mounting magic
 * ogra_cmpc thinks generally that loop devices should be ignored though
<seb128> ogra_cmpc: we had a patch to ignore ltspfs mounts though
<ogra_cmpc> yeah, thats not needed anymore
<ogra_cmpc> that was because we had two mounts per ltspfs device ... that was merged into one
<ogra_cmpc> in any case it should ignore bind mounts
<seb128> ogra_cmpc: feel free to open a gvfs bug about it with a small testcase
<ogra_cmpc> ok
<ogra_cmpc> hmm, actually it doesnt show the bind mount .. but the (hidden) device the mount originates from
<stgraber> ogra_cmpc: anything you want me to test for Edubuntu addon ?
<stgraber> ogra_cmpc: I installed everything from the add-on CD without internet access, worked well
<stgraber> and I tried iTalc, worked fine too
<stgraber> the notification message about the new artwork was there too
<ogra_cmpc_> stgraber, fine, there is nothing else atm ... (the menu still shows TeacherTools and LightDesktop though, got to find out why after beta)
<DktrKranz> Could a buildd-admin give-back ocamlcreal on amd64? Thanks.
<stgraber> ogra_cmpc_: oh, btw about the NM debug message on shutdown you spoke about yesterday : it's something like cb_data->data->... and assertion error
<ogra_cmpc_> is it actually an error ?
<ogra_cmpc_> i saw it has a debig prefix for each line
<stgraber> well, looks like a dbus thing to me but it's really hard to read as it's disappearing quite fast
<\sh> ogra_cmpc_: so you need libflashplugin for ltsp sound?
<ogra_cmpc_> i thought it was just a debug opton asac didnt drop from the code yet
<ogra_cmpc_> stgraber, right, thats my prob as well...
<ogra_cmpc_> probably its better to catch without usplash
<ogra_cmpc_> \sh, iodeed
<ogra_cmpc_> *indeed
<ogra_cmpc_> *libflashsupport btw :)
<stgraber> ogra_cmpc_: or with VMWare and the record video thing, but I don't have vmware installed anymore
 * ogra_cmpc_ neither
<ogra_cmpc_> vbox only here
<\sh> ogra_cmpc_: yeah...I just wrote  a mail to u-d@l.u.c to discuss this issue
<ogra_cmpc_> just ask the person who added it :)
<ogra_cmpc_> i dont think there needs to be much discussion
<\sh> ogra_cmpc_: adding without testing is a bad thing ;)
<\sh> whois tepsipakki
<\sh> grmpf
<ogra_cmpc_> well, addin for testing is a good thing
<ogra_cmpc_> \sh -> tjaalton
<\sh> ah :)
 * \sh needs to write a nick -> lp email  plugin for irssi ;)
<ogra_cmpc_> \sh, so your prob is with nspluginwrapper ?
<\sh> ogra_cmpc_: no..the problem is libflashsupport only :)
<ogra_cmpc_> \sh, do you use nspluginwrapper ?
<ogra_cmpc_> (you said youre on amd64)
<\sh> ogra_cmpc_: if it's needed for amd64 to run flashplugin-nonfree then yes...I'm not sure...the problem occurs but on both archs ...i386 and amd64 ...reproducable
<\sh> ogra_cmpc_: there is also a bug report for that
<ogra_cmpc_> what i want to find out is which package you are uninstalling there, we dont build the native amd64 package of libflashsupport anymore, only the lib32 version for amd64
<ogra_cmpc_> that changed very recently
<Robot101> with nspluginwrapper, flashplugin-nonfree, and i386 libflashsuport unpacked into lib32, audio works here
<ogra_cmpc_> Robot101, thanks :)
<lamont> mvo: good catch
<lamont> mvo: post beta, I assume?
<\sh> Robot101: change sounddevice to usb headset and start over pls
<\sh> Robot101: sound works with libflashsupport but only on the non-selected sound device, e.g. your onboard card...
<stgraber> ogra_cmpc_: did you test LTSP install using Ubuntu alternate ? I don't see any result on the tracker yet
<Robot101> ah - via pulseaudio, and I unpacked the i386 pulse plugins into lib32/alsa/
<\sh> Robot101: so even if you select in sound settings a usb headset for default output/input you get sound from your speakers attached to your desktop :)
<ogra_cmpc_> \sh, did you by chance generate an ~/.asoundrc.asoundconf that forces a card ?
<Robot101> so the sound device selection is made outside via pulseaudio
 * lamont wanders off
<Robot101> any problems you encounter are due to  not using pulseaudio. :)
<\sh> ogra_cmpc_: yes...tested everything with crimsun already
<\sh> Robot101: killing pulseaudio helps too
<\sh> Robot101: but dropping libflashsupport looks more sane
<ogra_cmpc_> \sh, pulse should hook into alsa ... and what you change with the gnome tool are the alsa settings
<ogra_cmpc_> that sounds very much like a misconfiguration
<Robot101> \sh: no, killing pulseaudio doesn't help at all. that just breaks the rest of my desktop.
<stgraber> asac, ogra_cmpc_: http://www.stgraber.org/download/NM-msg.png
<Robot101> 1. use pulseaudio. 2. configure pulseaudio as you wish. 3. make everything send its audio to pulseaudio.
<asac> evand: 1. it took me 4 minutes to hit the berlin timezone on the map
<\sh> Robot101: it breaks the rest yes :)  but not flash
<Robot101> success
<asac> evand: using a touchpad
<asac> evand: and how the new partition size is displayed in the guided option is confusing
<Robot101> \sh: flash works fine for me with nspluginwrapper, flashplugin-nonfree, i386 libflashsupport, and the pulse alsa plugins in lib32/alsa/
<Robot101> \sh: and yes, it will play through my selected pulseaudio sound device(s)
<\sh> Robot101: how do I say pulse to use my usbheadset?
<asac> evand: i didn't understand which partition would be which (e.g. a) was yellow reading hardy (development) 8.04, b) was grey reading hardy 8.04)
<Mirv> what should be done for bug #106756 still which has "verification-done" for the move from gutsy-proposed to gutsy-updates, but the move hasn't been done even though it's been there for over a month?
<ubotu> Launchpad bug 106756 in gnome-app-install ""Search for suitable codec" dialog not translated/translatable" [Undecided,In progress] https://launchpad.net/bugs/106756
<Robot101> \sh: use the device chooser applet
<Robot101> "PulseAudio Device Chooser"
<Robot101> select desired audio device from menu
<\sh> Robot101: do i need to install additional software for that?
<Robot101> it comes from the padevchooser package
<\sh> Robot101: there is no such thing as device chooser somewhere...the only stuff which is installed comes from ubuntu-desktop
<Robot101> but ideally, the gnome thing would change the pulseaudio settings if you had pulseaudio
<\sh> Robot101: that's crap...honestly...this package is not default...the settings in g-s-s are what the user uses...
<Robot101> fedora might have patched it thusly
<ogra_cmpc_> it has
<Robot101> yes, those settings are basically failure
<ogra_cmpc_> its used by default in fedora
<ogra_cmpc_> (libflashsupport)
<stgraber> ogra_cmpc_: Is that the same warning you saw ?
<mvo> lamont: probably, but if you are happy with it, I upload it and it will get unfrozen after the beta (if you have more fixes pending or prefer to upload it yourself, that is of course fine with me :)
<\sh> Robot101: so if the problem is solved with using different tools for pulse we need to fix it asap...or just drop pulse as default
<ogra_cmpc_> i worked a while with warren togami on it, he cared for licensing fixes in fedora because they install it by default
<ogra_cmpc_> stgraber, differetly wrapped, but i think so
<lamont> I have a couple of template .po translation files committed in git already
<asac> stgraber: that message wasn't there with 0.6.5?
<Robot101> \sh: dropping pulse is unlikely to make things work better. :P
<ogra_cmpc_> i think that meassage was there since we use 0.6
<\sh> Robot101: the issue is still there...even with a known workaround
<stgraber> asac: not sure, in most cases it's hidden by usplash or just appears during a too short amount of time to notice it
<lamont> mvo: if you do upload, I won't complain at all if you want to grab the git tree and branch off of the right place (before the merge with wietse that I did yesterday of 2.5.2-rc1)
<ogra_cmpc_> asac, its hard to catch because it vanishes very fast
<lamont> otherwise, I'm happy to manually apply the patch for you
<lamont> as in resync later this week
<lamont> mvo: in fact, please upload.
<stgraber> ogra_cmpc_: I had to use a LiveCD image with usplash turned off to catch it :) (as we have the "remove the CD" prompt to avoid the reboot)
<lamont> I'll just plan on dealing with the merge later in the week/early next
<ogra_cmpc_> \sh, can you remove ~/.asoundrc.asoundconf and run asoundconf set-pulseaudio ? and then try again
<ogra_cmpc_> that way you force pulse to use the alsa backend
<asac> stgraber: is it reproducible if you shut down hal _before_ dbus?
<\sh> ogra_cmpc_: sec
<asac> without shutting down your system
<asac> i guess it should appear in syslog
<\sh> ogra_cmpc_: and then setting g-s-s settings back to use headset?
<ogra_cmpc_> as you like
<asac> \sh: i akes on ml. are you using pulseaudio?
<ogra_cmpc_> the g-s-s settings should only apply to alsa
<ogra_cmpc_> pulse sits on top
<\sh> asac: I'm using g-s-s and say "use usb headset" ... PA is running though...bug firefox + flash gives me "sound over default onboard device, not the choosen one"
<asac> hmm
 * \sh is on i398 now
<soren> \sh: Wow!
<asac> might sound ignorant, but what is pulse good for?
<\sh> hmm
<soren> i398 sounds awesome!
<\sh> i386
<ogra_cmpc_> self invented ?
<ogra_cmpc_> heh
<\sh> ogra_cmpc_: no change...I think I need to relog to get this setting started?
 * ogra_cmpc_ imabgines \sh with soldering iron upgarding his CPU to 398
<\sh> hehe
<ogra_cmpc_> \sh, might be, not sure
<\sh> ogra_cmpc_: brb...
<asac> anyone can give me insight why we have pulseaudio in hardy? which use-cases does it tackle?
<ogra_cmpc_> \sh, pcm.!default { type pulse }
<ogra_cmpc_> ctl.!default { type pulse }
<ogra_cmpc_> thats the content your .asoundrc.asoundconf should have atm
<\sh> ogra_cmpc_: yepp...that's in .asoundrc.asoundconf
<\sh> ogra_cmpc_: but no sound via flash + headset
<stgraber> asac: doesn't seem to reproduce the message by stopping hal before dbus. I get some CK messages, hcid too but nothing scary from NM (seems to shutdown correctly)
<ogra_cmpc_> asac, because gnome sucks and isnt capable of implementing dings and doings and plings using gstreamer
 * asac goes to AC-mode and reads package description
<asac> stgraber: and the other way around?
<asac> e.g. dbus before hal?
<ogra_cmpc_> asac, oyu should see it on the classmate btw ... its slow enough to expose it before usplash comes up
<asac> ogra_cmpc_: yes, but not a good environment to work on it :)
<\sh> ok...again...asoundconf set-pulseaudio + system/Prefs/Sound -> setting to usb headset...
<asac> ogra_cmpc_: i need a way to reproduce this on a running system :)
<\sh> no sound at all over headset
<ogra_cmpc_> asac, bah, lamer ... i'm working on my classmate sionce 4 weeks wothout probs
<ogra_cmpc_> (apart from typing right :P)
<asac> yeah ;) ... and you attach gdb during shutdown.
<\sh> setting it to pulse in g-s-s works for normal sound..now check flash
<\sh> no sound for flash #
<stgraber> asac: same result (dbus stops hal anyway)
<ogra_cmpc_> we should just switch to 0.7
<ogra_cmpc_> it has proper initscripts
<asac> stgraber: right. ok. did you try to stop nm after hal (but dbus still running)`
<asac> ogra_cmpc_: indeed
<asac> ogra_cmpc_: in fact we would want to not stop NM during shutdown at all
<asac> same for package upgrades
<ogra_cmpc_> yeah
<ogra_cmpc_> sad that we'll have to support that for three years
<stgraber> asac: "Shutting down normally" it says ...
<asac> strange.
<asac> whatelse could trigger this?
<ogra_cmpc_> \sh, i start to suspect that your flash doesnt use pulse at all
<ogra_cmpc_> for whatever reason
<asac> you need libflashsupport for that :)
<stgraber> asac: "Terminatting all remaining process" is what it does before the arning
 * asac ducks
<stgraber> *warning
<stgraber> asac: so it receives a kill message
<asac> so its a KILL?
<stgraber> looks like yes
<\sh> ogra_cmpc_: I just checked this: 1. libflashsuport is installed...no sound with setting asoundconf set-pulseaudio and set to usb headset
<stgraber> asac: I don't see why though, from my point of view we should just call /etc/init.d/dbus stop and that will shutdown all the necessary bits ...
 * asac wonders if dbus or hal get a SIGKILL as well
<asac> stgraber: right
<asac> thats why i wonder
<asac> isn't that called at all?
<\sh> ogra_cmpc_: removing libflashsupport and restarting firefox+flash doesn't work either...setting asoundconf back to usb headset, with libflashsupport installed -> no sound for flash, dropping libflashsupport restarting everything..sound works with flash
<\sh> ogra_cmpc_: fun part...sound works with libflashsupport on the onboard device still
<stgraber> asac: find /etc/rc*/ | grep udev
<stgraber> asac: I don't see any K entry for it here ...
<stgraber> asac: oops :)
<stgraber> asac: dbus of course
<stgraber> asac: and it actually has K entry
<asac> in postinst there is update-rc.d dbus start 12 2 3 4 5 . stop 88 1
<asac> e.g. i have /etc/rc1.d/K88dbus
<asac> and /etc/rc1.d/K16hal
<pitti> lool: argh, elisa-plugins-bad wants more packages, like python-{bluez,coherence,daap}
<pitti> lool: would it be possible at all to move the GUI into plugins-good? (and wouldn't that make more sense in the first place?)
<\sh> ogra_cmpc_: and libflashsupport is used...shermann@wz-pc-006:~$ lsof |grep libflash
<\sh> firefox   10773   shermann  mem       REG        8,3    10848  67155089 /usr/lib/libflashsupport.so
<\sh> ogra_cmpc_: usb headset tested via padevchooser -> works...inside ff + flash-nonfree -> doesn't work
<jdstrand> slangasek: speaking for the 'crackheads', the apparmor changes in bind9 force certain upgrades into complain mode, to not break existing installs
<jdstrand> slangasek: eg dapper - hardy
<jdstrand> gutsy with apparmor-profiles installed - hardy
<jdstrand> slangasek: the second is probably more important in terms of beta testing, but I don't have the numbers on how many are doing that
<jdstrand> s/are/will/
<ogra_cmpc_> \sh, find others that can reproduce it ...
<\sh> ogra_cmpc_: 4 different desktops ? one amd64 rest i386 ... it could be still a regression from upgrades from gutsy to hardy...
<ogra_cmpc_> \sh, my only concern with changing the dep is that i didnt hear anybody but you complaining yet
<\sh> ogra_cmpc_: https://bugs.edge.launchpad.net/ubuntu/+source/libflashsupport/+bug/144356 :)
<ubotu> Launchpad bug 144356 in libflashsupport "Audio from Flash in Firefox does not go to correct sound device (dup-of: 151849)" [Low,Confirmed]
<ubotu> Launchpad bug 151849 in libflashsupport "Sound Broke in Ubuntu Gutsy firefox" [Undecided,Confirmed]
<_MMA_> \sh: Luke (TheMuso) might also be able to test as I believe he has multiple sound cards. He's in AU and might be up in a few hours. He said he was gonna start his day early.
<\sh> _MMA_: well, I'm really wondering what the bugger is...just because usb headset microphone works as expected (in flash) ...it's just the sound which doesn't come up
<\sh> ogra_cmpc_: you see I'm not the only one ;)
<ogra_cmpc_> thats all about the lib32 issue
<\sh> ogra_cmpc_: the dupe yes...the 144356 not
<ogra_cmpc_> and: ALSA lib ../../../src/pcm/pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave is pretty much what the upstream bug has
<ogra_cmpc_> that looks rather like amd64 with nspluginwrapper wont work *without* it installed
<ogra_cmpc_> (not talking about the dupe here)
<pitti> StevenK, lool: hildon-desktop is uninstallable since mobile-basic-flash dependency is in universe
<\sh> ogra_cmpc_: it seems that 144356 is not a dupe of 151849
<ogra_cmpc_> well, it seems they are both mixed up
<\sh> yepp
<\sh> well...to fix the amd64 issue we need to add the 32bit libs to ia32-libs somehow (if this is reasonable)
<StevenK> pitti: Oh, argh.
<ogra_cmpc_> the lib32 issue should be fixed now ... but according to the comments flash wont produce any sound if the lib is missing there
<ogra_cmpc_> thats getting tricky
<\sh> ogra_cmpc_: more tricky the i386 problems, still...
<lool> pitti: It would make more sense to have the GUI in -good; it's the immediate thing I complained about when I saw the -bad dep
<lool> pitti: But I'm not too hot on diverging from upstream on that
<lool> I could further split -bad though
<pitti> lool: ah, it's split upstream like that?
<lool> pitti: These are all upstream packages
<pitti> hm, so split into -ui and -bad, so that the extra dependencies are only on -bad?
<lool> mapped one to one from upstream tarballs to binary packages
<lool> pitti: Exactly
<pitti> lool: I guess the actual question is: do we want to support the plugins in bad?
<lool> pitti: -passable, -mediocre and -nottoobad are also on the table :)
<lool> pitti: In a perfect world, we would be good with -good alone; unfortunately, they applied strict criterions to triage plugins, and the UI was in a shape which only allowed to ship it in -bad
<lool> Ideally, the UI plugin(s) is fixed and promoted to -good soon
<lool> And we can drop the elisa -> -bad dep
<pitti> lool: I mean, are the plugins in -bad bad enough so that we wouldn't like to support them?
<\sh> grmpf...brb
<lool> pitti: This is similar to gstreamer plugins split
<lool> pitti: We ship these (in universe), but we don't pull these by default
<pitti> lool: so if they are bad/broken enough, IMHO we should leave them in universe and split the binary out, perhaps? WDYT?
<\sh> asac: btw...do you know why firefox -width 300 -height 300 doesn't work properly?
<\sh> asac: neither in ff3 nor in ff23
<\sh> ff2 even
<ogra_cmpc> did that ever work in firefox ?
<DktrKranz> pitti, could you please give-back ocamlcreal on amd64? Thanks.
<\sh> ogra_cmpc: a mozilla option regarding firefox --help :)
 * ogra_cmpc only actually saw that working in mozilla
<ogra_cmpc> right
<ogra_cmpc> i dont think ff ever supported that option
<lool> pitti: The reason for badness can be quite different, it could be anything from a license issue to a lacking documentation issue
<pitti> hm, licensing would be fatal -- it's in universe and needs to be DFSG-free
 * pitti -> lunch, bbl
<lool> pitti: Licensing might still be DFSG free, but considered bad
<lool> pitti: For example in GStreamer, it's quite bad when a plugin is GPL and not LGPL as it "pollutes" the LGPLing of the whole gst stack you're using
<\sh> ogra_cmpc: bah...
<\sh> ogra_cmpc: so what browser someone should use for setting the default x/y width/height to actually remote control it ;)
<evand> asac: aware of the problem and on it.
<asac> evand: ok both?
<ogra_cmpc> \sh, write your own :) http://people.ubuntu.com/~ogra/LightBrowser/
<ogra_cmpc> took me some hours on a boring weekend to get to that state
<evand> not the latter, actually, but I'm not sure how to solve that.  Suggestions?
<ogra_cmpc> its all javascript
<asac> \sh: i think nobody really cares about that feature. its more an old suite thing
<\sh> asac: well...if you want to automate screen recordings (e.g. start firefox at pos x/y with width/height, recordmydesktop -x <pos inside firefox> -y <pos inside firefox> -width <foo> -height <bar> -o myscreencast.ogg) this could be helpful :) (e.g. recording example flash output, or other moving objects)
 * \sh is doomed...
<\sh> let's see if galeon + flash works somehow
<\sh> bah...I need a pause...
<asac> \sh does gnash work properly in this regards?
<asac> (i assume it does ... just to confirm)
<nemo> I know y'all are devs and busy, but if anyone happens to be familiar with checkinstall and knows what:
<nemo> grep: /var/tmp/AHXgVEkmBVqAMUSYXXaaX/newfile: No such file or directory
<nemo> Copying files to the temporary directory... FAILED!
<nemo> might mean in my attempt to install an ffmpeg with faac/faad support, I'd really appreciate it
<nemo> checkinstall 1.6.1
<cjwatson> Does compiz have a plugin to fade out the screen after a period of inactivity? I noticed that it kicks in while ubiquity is running, even though ubiquity takes steps to poke gnome-screensaver every so often
<cjwatson> And if so, is there a way to inhibit it?
<seb128> cjwatson: could be gnome-power-manager
<cjwatson> point
<nemo> heh
<cjwatson> though the preferences don't seem relevant here
<seb128> cjwatson: run gnome-power-manager --no-daemon --verbose and look at the log when screen is dimming
<nemo> appears my checkinstall error is very common
<nemo> hm
<cjwatson> nemo: it's not obvious from the error message; though I wonder if perhaps you have /var/tmp mounted separately and noexec
<cjwatson> (just a guess, though)
<seb128> cjwatson: could be https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/137598
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [High,Fix committed]
<cjwatson> seb128: hmm, will be awkward to set up, but I'll see what I can do
<cjwatson> seb128: (this is a desktop system, BTW)
<nemo> cjwatson: naw. pretty standard setup
<nemo> everything under /
<_MMA_> nemo: Might save yourself some effort by looking at Medibuntu. Their version might have the support you're looking for.
<seb128> cjwatson: (hum, not likely this issue then)
<nemo> _MMA_: sure. although, I might need to do this in future...
<cjwatson> seb128: I wasn't really looking at the screen when it happened, but based on peripheral vision it looked exactly like gnome-screensaver kicking in
<cjwatson> screen dimmed to black over a period of a second or two, and then came back upon pressing a key (with a delay because the system was busy)
<cjwatson> I could try using gnome-screensaver-command --inhibit instead, I suppose
<nemo> looking around, I keep seeing folks running into this error, but no one with a solution except "do something else besides checkinstall"
<nemo> I wonder if checkinstall is completely broken
<nemo> seems to be even on, like, Solaris
<nemo> ah-hah
<nemo> http://oclug.on.ca/archives/oclug/2004-May/038916.html
<nemo> hm. or not
<nemo> dammit
<nemo> _MMA_: I think you're right on the medibuntu thing - that could explain why I had it working before. probably had set that up and forgot.
<nemo> darn. the medibuntu one doesn't link against faac either
<nemo> oh well. gentoo it is
<dholbach> Word Up: http://www.murrayc.com/blog/permalink/2008/03/19/getting-my-microphone-to-work/
<ogra_cmpc> dholbach, with the USB mic working i would suspect its an alsa bug with his card driver
<ogra_cmpc> seems the upper layer works fine
<dholbach> I had the same problem - no usb mic
<ogra_cmpc> same card probably ?
<dholbach> no, different, but Intel too
<ogra_cmpc> "The laptop is using a USB microphone built in to a webcam, and that works fine." somewhat indicates that its at low level
<mvo> I had the problem with a gutsy system from a friend
<mvo> but I have no usb mic to test myself :/
<ogra_cmpc> intel card as well ?
<mvo> bno
<mvo> no
<mvo> ogra_cmpc: didn't read careful enough, I had the trouble with a usb thing
<ogra_cmpc> ah
<ogra_cmpc> me heard people mention before that they had probs with mics on intel cards being to silent ... apparently you can get something out of them but very very quiet
<mvo> aha
<sistpoty|work> infinity: can you increase the lp timeout for ghc6 on sparc? it doesn't produce any output for ~800 minutes on my sparc test box, but the build succeeded there w.o. problems (bug #194912). Thanks!
<ubotu> Launchpad bug 194912 in ghc6 "ghc6 6.8.2-1ubuntu1 FTBFS on sparc" [Undecided,Confirmed] https://launchpad.net/bugs/194912
<pitti> cjwatson, evand: hm, did you recently try the OEM time zone selector? the zoom is way too high, it's very sluggish, and the dots are misplaced (there's no dot where Berlin or London are)
<pitti> it works quite fine in ubiquity
<asac> pitti: i think evand said that he is working on improving the time zone selector
<asac> pitti: for me it took minutes to actually hit berlin
<asac> using touch pad
<pitti> asac: I didn't even find it in the oem configurator :)
<stgraber> selecting Zurich was really hard as Vaduz is pretty close :) and that zoom effect looks weird to me
<asac> really? strange. for me it was about where it should be on todays livecd
<asac> evand: i am not sure ... you might want to talk to mpt about how to better visualize that
<asac> evand: (about the guided resizing preview)
<seb128> siretart: could you make xine-lib stop shipping the pulse plugin? the totem upstream requested that because it's really buggy and they get lot of crashes due to it, http://bugzilla.gnome.org/show_bug.cgi?id=449658
<ubotu> Gnome bug 449658 in xine-lib backend "Broken PulseAudio plugin in xine-lib (work-around in comment 79)" [Critical,Resolved: notgnome]
<seb128> siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471676 too
<ubotu> Debian bug 471676 in totem-plugins "Crash when see video from internet" [Normal,Open]
<siretart> seb128: thanks for the hint, will investigate
<seb128> siretart: thank you
<siretart> seb128: ok, we will take out the pulse plugin. Is this something for the beta release?
<seb128> siretart: no, it's late for beta anyway and we use totem-gstreamer
<siretart> or shall I wait for after the release?
<siretart> ok
<seb128> siretart: it was just a request from upstream so they stop getting duplicates
<siretart> can I upload anyway and expect it to be accepted only after release?
<seb128> yes
<siretart> ok. on my way
<seb128> thanks
<seb128> siretart: we are on sync with debian, I can do sync if you fix it there
<siretart> hm. I thought mvo had uploaded a patch for dapper->hardy upgrades
<siretart> mvo: do you intend to upload that, or have you asked me to upload the debdiff?
<mvo> siretart: I uploaded a xine-lib yesterday, but it got not accepted (yet)
<seb128> ah ok
<seb128> freezes suck
<mvo> siretart: feel free to grab the debdiff and apply it on top of your changes
<seb128> or a least not having frozen versions listed on launchpad
<mvo> seb128: yeah, or do packages in bzr ;)
<siretart> we manage the xine-lib in hg
<seb128> mvo: don't get me started on bzr ;-)
<siretart> a working bzr-hg plugin would be great here...
<mvo> or git-bzr ...
<cjwatson> pitti: evand has a FF/beta freeze exception request open for that
<cjwatson> I think it may be too late for beta though
<pitti> ok, so it's known
<pitti> cjwatson: fine, using the combobox works good enough
<cjwatson> bug 203292
<ubotu> Launchpad bug 203292 in oem-config "Freeze exception: zoommap changes port to oem-config" [Undecided,New] https://launchpad.net/bugs/203292
<pitti> at least one nontrivial bug in the beta :)
<pitti> cjwatson: thanks
<\sh> seb128: any workaround to tell the gnome screenshot util to fetch window borders under compiz?
<cjwatson> pitti: does fsck usplash integration not work on /?
<seb128> \sh: take a fullscreen screenshot
<pitti> cjwatson: it's supposed to, but there are a few reported bugs
<\sh> seb128: so no single window can be captured with a window border  when running with compiz as wm...
<\sh> it's not my day today
<cjwatson> yeah, I just noticed it drop to text mode for me
<seb128> \sh: correct
<pitti> cjwatson: bug 203322 and bug 197667 ?
<ubotu> Launchpad bug 203322 in sysvinit "fsck/usplash: ESC does not kill fsck" [Undecided,In progress] https://launchpad.net/bugs/203322
<ubotu> Launchpad bug 197667 in sysvinit "problem with new display of FSCK" [Undecided,In progress] https://launchpad.net/bugs/197667
<cjwatson> pitti: I don't think so - it *does* drop to console. It could be 203322, though, didn't check process lists
<pitti> cjwatson: hm, when I'll deal with those bugs, I'll test it again with the root file systems
<mvo> Keybuk: could you pleae have a look at http://paste.ubuntu.com/5880/ and tell me if such a change would be ok with you? it helps the apt resolver to calculate the upgrade from dapper->hardy
<mvo> bdmurray: I analyized the problem you had with your test-upgrade and I think that I have a workaround (if Keybuk is happy with it :) - otherwise I will work around it by hinting in update-manager
<Keybuk> mvo: why doesn't Breaks work in this situation?
<Keybuk> isn't Breaks for forcing an upgrade of libdevmapper?
<kirkland> pitti: ping
<kirkland> pitti: testing the server iso's I'm hitting bug #203920, postgresql not starting
<ubotu> Launchpad bug 203920 in postgresql "postresql task in ubuntu server edition (hardy) doesn't start the database" [High,Triaged] https://launchpad.net/bugs/203920
<kirkland> pitti: /etc/init.d/postgresql-8.3 status does NOT return non-zero, and doesn't really demonstrate that the backend isn't running
<kirkland> pitti: was wondering if you'd consider that a bug, against the status() function in /usr/share/postgresql-common/init.d-functions ?
<mvo> Keybuk: yes, it forces a upgrade, but libdevmapper1.02 is no longer available and that confuses the resolver (a bug there). the resolver is better in hardy, but gutsy still has the buggy version
<Keybuk> heh
<Keybuk> oh I see
<mvo> Keybuk: the result is that it will held back udev
<mvo> and that is not good :)
<Keybuk> you know best when it comes to the resolver not keeping its toys in its pram ;)
<mvo> I wish I would sometimes ;)
<Keybuk> so go right ahead :)
<mvo> thanks Keybuk!
<pitti> kirkland: pong
<bdmurray> mvo: I ran across bug 203385 yesterday and thought it was interesting
<ubotu> Launchpad bug 203385 in friendly-recovery "Recovery menu cannot be controlled with keyboard" [Medium,Confirmed] https://launchpad.net/bugs/203385
<kirkland> pitti: just bouncing that 'issue' off of you before opening a bug
<pitti> kirkland: is there actually a cluster running? pg_lsclusters shows them
<kirkland> pitti: nope, no cluster running.  no postgres at all, in fact.
<pitti> kirkland: ah, seems that's the bug mathiaz found then?
<kirkland> pitti: yes, that bug is the root cause, but it sort of unearthed a second one, perhaps
<kirkland> pitti: the fact that I run "/etc/init.d/postgresql-8.3 status", and there is no postgres running...  but that DOES NOT exit non-zero, and there's nothing that tells me that my postgres install is b0rked
<pitti> kirkland: hm, that's indeed a pathological case
<pitti> kirkland: if you have zero configured clusters, are all of them running or not? :)
<kirkland> pitti: :-)  chicken, or the egg?
<kirkland> pitti: yeah, mathiaz suggested I talk to you first
<pitti> I'm not fussed about exiting with nonzero if there are no clusters at all
<mathiaz> pitti: if there are not cluster then we shouldn't exit 0 IMO
<mathiaz> pitti: it's a valid case.
<kirkland> pitti: so the init script status is actually more about the clusters, and not so much about the status of the local postgres daemon?
<pitti> kirkland: if you don't have any clusters (instances), there is nothing to run a postgres daemon against
<pitti>     pg_lsclusters | awk 'BEGIN {rc=0} {print; if ($4 == "down") rc=3} END { exit rc }'
<pitti> that's the current implementation of status
<kirkland> pitti: yep, found it
<pitti> which is a bit arbitrary, granted
<pitti> since with several clusters there are so many ways to define 'success' or 'failure'
<pitti> IOW, it fails if there is any non-running cluster, and succeeds otherwise
<pitti> kirkland, mathiaz: if you think that a different semantics is better, please file a bug against postgresql-common and assign it to me
<kirkland> pitti: so it starts out thinking "all is well", and only returns "not so well" if any cluster is "down"
<pitti> in fact, I ponder replacing status() with
<pitti>   echo "use pg_lsclusters to display the status for all configured clusters"
<pitti> or so :)
<soren> Quick question: In a udev rule, I can expect /dev%k to expand to a device node for the device in question, can't I?
<kirkland> pitti: i think that would be more true to it's form
<kirkland> pitti: LSB has a spec for what "status" in an init script is supposed to return
<kirkland> pitti: http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
<kirkland> pitti: not that we're anywhere close to LSB compliance :-)
<pitti> kirkland: maybe it should return 4 for zero clusters then?
<kirkland> pitti: yeah, that would help
<kirkland> pitti: 0 tells me all is well
<kirkland> pitti: and in this case, that's not entirely true
<kirkland> pitti: you mind if I file a bug against postgres-common, and attach a suggested patch?
<kirkland> pitti: and you can do with it what you will?
<pitti> kirkland: no, please do
<pitti> kirkland: just specify the desired semantics
<kirkland> pitti: perfect, thanks.
<pitti> I'll need to change the test suite accordingly
<pitti> and then I'll see to changing the code
<kirkland> pitti: sure, i'll suggest what I think is best.  you can decide for yourself how much is enough/too-far for beta-freeze changes
<pitti> kirkland: as long as it's only status(), that's fine
<pitti> kirkland: I did follow it
<pitti> kirkland: that went far beyond fixing this local function, AFAIR you spoke about introducing some infrastructure and PID guessing functions?
<kirkland> pitti: did not introduce pid-guessing functions; used ones already there
<kirkland> pitti: but yes, it did go too far beyond fixing a single local function, i recognize and agree with that now
<mantiena-baltix> Hi all
<mantiena-baltix> hi cjwatson
<cjwatson> hello
<mantiena-baltix> cjwatson: I'm wonder how to fix bug #138252 - you wrote in last comments:
<mantiena-baltix> 21:42 <cjwatson> ah, I see! you have them in the .desktop files but not the .mime files
<mantiena-baltix> 21:42 <cjwatson> should be trivial to fix
<ubotu> Launchpad bug 138252 in openoffice.org "[Ubuntu] [hardy] Office Open XML (OOXML) is not associated with OpenOffice.org, opens with File roller" [Low,In progress] https://launchpad.net/bugs/138252
<mantiena-baltix> cjwatson: also you wrote: "With an updated Hardy system at the time of writing, double-clicking a .docx file opens it in OpenOffice.org for me."
<mantiena-baltix> cjwatson: so, maybe you can tell me what changes are in hardy, but are missing in gutsy ?
<mantiena-baltix> because in gutsy docx opens with file-roller, not with openoffice :(
<seb128> mantiena-baltix: what mimetype is that?
<pitti> ogra_cmpc: just doing an LTSP test install (on amd64 alternate) and got some problems; do you have a second?
<ogra_cmpc> pitti, sure
<mantiena-baltix> seb128: in gutsy I see MIME type: application/zip in file properties
<mantiena-baltix> seb128: what Mime type shows in hardy ?
<seb128> mantiena-baltix: I've no example to try on
<mantiena-baltix> seb128:  example is attached to bug #138252
<ubotu> Launchpad bug 138252 in openoffice.org "[Ubuntu] [hardy] Office Open XML (OOXML) is not associated with OpenOffice.org, opens with File roller" [Low,In progress] https://launchpad.net/bugs/138252
<seb128> mantiena-baltix: the mime database suggests "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
<mantiena-baltix> seb128: could you tell me which file has this line ?
<seb128> mantiena-baltix: /usr/share/mime/packages/freedesktop.org.xml
<seb128> mantiena-baltix: the nautilus properties indicate the correct mimetype on hardy and it uses the correct association
<mantiena-baltix> seb128: yea, so, it seems I should just steal /usr/share/mime/packages/freedesktop.org.xml from hardy ;)
<seb128> mantiena-baltix: what are you trying to do?
<seb128> mantiena-baltix: hack locally to get it working?
<mantiena-baltix> seb128: sort of - include M$ OpenXML support in our local distro, based on gutsy
<pitti> ogra_cmpc: got my /msg?
<ogra_cmpc> err
<ogra_cmpc> i asnwered, but indeed i'm not regged
<seb128> mantiena-baltix: you can try to backport shared-mime-info from hardy, it should be safe, that's mainly mimetype definitions
<mantiena-baltix> seb128: ok, thanks for help
<seb128> mantiena-baltix: you are welcome
<mantiena-baltix> you too ;)
<seb128> cd ..
<seb128> ups
<seb128> mantiena-baltix: the gutsy version already had those definitions apparently, weird it's not working for you
<mantiena-baltix> seb128: are you sure, that gutsy has MS OOXML mime types ? I don't find them in shared-mime-info package from Gutsy and Nautilus displays MIME type: application/zip in file properties
<seb128> mantiena-baltix: no, I'm not sure, I just diffed the gutsy and hardy versions and those definitions are not in the diff
<mantiena-baltix> seb128: I've downloaded gutsy and hardy packages and see openxml in hardy, but not in gutsy ;)
<seb128> mantiena-baltix: ah, that's 210_OOXML_types.patch in the patches in the hardy version
<mantiena-baltix> :)
<seb128> so you can backport the hardy package or just this patch
<mantiena-baltix> seb128: I think I will backport whole package in my PPA
<cjwatson> mantiena-baltix: calc is going to deal with it before hardy
<cjwatson> it's the obvious .desktop files in debian/ in the openoffice.org source package
<cjwatson> I don't remember the exact file names right now but I'm sure they aren't hard to guess
<seb128> cjwatson: deal with what? the ooxml support? that's fixed in hardy already
<cjwatson> seb128: still needs to be fixed in the openoffice.org source as well; with the fix in shared-mime-info it works partially but not entirely
<seb128> cjwatson: hum, weird
<mantiena-baltix> cjwatson: AFAIK cals, writer and impress .desktop files have openxml support since Gutsy
<seb128> cjwatson: the openoffice desktop declare handling the mimetype and the definition is in shared-mime-info, that should be just working
<cjwatson> (as I understood it when looking at the bug)
<cjwatson> they definitely didn't when I looked at the bug last week
<seb128> cjwatson: and that's working just fine here
<cjwatson> I did check
<seb128> /usr/share/applications/ooo-writer.desktop has application/vnd.openxmlformats-officedocument.wordprocessingml.document listed on my hardy
<seb128> but I didn't upgrade since box since monday I think
 * seb128 looks at available upgrades
<seb128> no openoffice upgrade pending
<cjwatson> sorry, I should have said the .mime files, not the .desktop files
<cjwatson> as you observe the desktop files are fine
<seb128> .mime are still used by something nowadays?
<mantiena-baltix> shared-mime-info (0.23-4) unstable; urgency=low
<mantiena-baltix>   * Apply freedesktop bugzilla patch for some OOXML support. (Closes: #469599)
<mantiena-baltix>  -- Filip Van Raemdonck <mechanix@debian.org>  Thu, 06 Mar 2008 06:56:47 +0100
<cjwatson> but things like /usr/lib/mime/packages/openoffice.org-writer are incomplete
<cjwatson> might not be used in GNOME, but our OOo packages may be installed elsewhere
<seb128> alright
<cjwatson> it makes a difference to e.g. see(1)
<cjwatson> and we can't legitimately claim the bug to be closed until that's fixed too, since we still ship those files
<mantiena-baltix> cjwatson: does KDE use these mime files ?
<cjwatson> mantiena-baltix: I have no idea
<seb128> no
<seb128> all the modern desktop environment use the freedesktop mimebase
<cjwatson> it's trivial enough to be easier to fix than to argue about it
<Riddell> mantiena-baltix: yes
<seb128> Riddell: you are not using shared-mime-info?
<Riddell> seb128: we are
<ogra> seb128, did oyu drop the fusa/ltsp patch ? pitti just told me it ofrfers switching
<seb128> Riddell: the question was whether KDE is use the old .mime I think
<ogra> meh ...
<pitti> seb128: I clicked on the other user, and it answered with an error message dialog saying something about 'blabla Xauthority blabla permissions" (and the close button is broken, but oh well)
 * ogra excuses for his typing
<Riddell> seb128: oh, no
<mantiena-baltix> cjwatson: I'm not argue, I'm just asking :)
<seb128> ogra: no, we still have the patch
<ogra> hmm
<ogra> ten there should be no switch option ... strange
<seb128> is LTSP_CLIENT defined in the session?
<cjwatson> mantiena-baltix: for a backport, I imagine it's simplest to make the obvious changes to ooo's .desktop and .mime files, and to backport the shared-mime-info change
<cjwatson> you may only need some of that in practice but a test run will probably take significantly longer than just doing it all
<mantiena-baltix> ;)
<seb128> well, if they only care about desktop environment they don't need to backport openoffice, just shared-mime-info
<ogra> seb128, yes i think the patch is buggy, i'll take a look after beta
<kirkland> pitti: debdiff attached here: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/203966
<ubotu> Launchpad bug 203966 in postgresql-common "init script status action does not reflect dead postgresql service" [Undecided,New]
<Riddell> evand: for the non-live-session ubiquity install the qt frontend still offers an option of reboot/continue using CD which seems like a bad idea.  is that fixed on the gtk side?
<TheMuso> I see that iso.sq.ubuntu.com is stills aying images from the 18th, and thats what cdimage appears to have. Should I be waiting for new images?
<TheMuso> iso.qa.ubuntu.com even
<evand> Riddell: it is, it's been on my todo list for the KDE side as if memory serves the KDE side still just instructs you to reboot, rather than actually giving you a button option.
<evand> it is fixed on the gtk frontend, that is
<Riddell> evand: I changed the KDE side to offer an option now
<Riddell> evand: ok, I'll look into that after beta
<evand> ah fantastic
<cjwatson> Riddell: is that bug 203931? It's filed against oem-config, but I think that must be a mistake
<ubotu> Launchpad bug 203931 in oem-config "kubuntu oem-config allows you to "continue using Live CD"" [Undecided,New] https://launchpad.net/bugs/203931
<cjwatson> bdmurray: ^--
<bdmurray> cjwatson: yes, that's a mistake
<cjwatson> bumped over to ubiquity
<Riddell> cjwatson: I don't know what's going on there, you should never see kdm on a live session
<cjwatson> Riddell: sounds like an additional bug then ... wouldn't you see it if you logged out?
<evand> ubiquity-dm spawns kdm on exit
<cjwatson> (briefly, until it autologgedin)
<Riddell> I've never logged out of a live CD, I usually just reboot, I thought logging out would reboot too
<cjwatson> doesn't in Ubuntu
<calc> where should squashfs errors on resume be filed?
<bdmurray> calc: I saw that too - the kernel I think
<calc> after suspending and resuming the beta cd i get squashfs errors and it doesn't completely resume
<calc> bdmurray: ok
<bdmurray> I haven't reported it yet though
<calc> bdmurray: ok i'll report it
<calc> i copied off all the log files in case any of them are useful
<Amaranth> whoa you can suspend/resume with the live cd?
<Amaranth> i figured that'd be disabled
<bdmurray> Hibernate is disabled not supsend
<Amaranth> ah, right
<calc> suspend/resume works on the i386 cd just not the amd64 for me
<calc> on amd64 i get squashfs errors
<calc> the kernel source package is now called 'linux' right?
<bdmurray> calc: that's correct
<ogra> it always was
<TheMuso> calc: yes.
<ogra> oh, source ...
<ogra> sorry
<calc> ogra: iirc it used to be a versioned package name for the source
<ogra> yeah
<ogra> i read to fast and skipped "source" :)
<calc> ogra: heh :)
<cjwatson> not always linux-* either
<cjwatson> it was kernel-* for a period before warty released
<ogra> and -di is still kernel- isnt it ?
<_MMA_> Before I go filing bugs I'm wondering if anyone has seen this. When using sudo or things that need "admin privileges" I get a "Unable to resolve host" error. Not that it does it all the time. Maybe 1/10. And when it does work, asking for the password is slow to come up. On Hardy. Up-to-date. Something unknown?
<calc> bug 203984
<ubotu> Launchpad bug 203984 in linux "[hardy beta] [amd64] squashfs errors on resume from desktop cd" [Undecided,New] https://launchpad.net/bugs/203984
<calc> thats the squashfs bug i reported
<bdmurray> calc: thanks
<calc> i'm not entirely sure if my system would completely resume even without the squashfs issue, but that can't be helping things, heh
<jdong> _MMA_: is your host name set properly and defined in hosts.conf?
<_MMA_> yes
<jdong> _MMA_: ok I give up :)
<_MMA_> 1st thing I looked at. :P
<bdmurray> calc: which log file has the squashfs errors?
<bdmurray> ah, found it
<calc> bdmurray: should be in kern.log and dmesg
<calc> since its kernel error
<calc> i attached the other files in case they were of any use in tracking down the issue
<calc> too much info usually doesn't hurt ;-)
<_MMA_> jdong: TBH, I can only say "yes" by comparing the Hardy one to Gutsy. They look the same so I can only assume. Something might need to be added for all I know.
<calc> bdmurray: did your resume work even with the squashfs errors?
<bdmurray> It did one time not the second time
<calc> bdmurray: ah ok
<calc> bdmurray: one time i got continually scrolling squashfs errors
<cjwatson> ogra: -di> yes
<calc> oh btw, why do we have separate live session and install session now?
<calc> i haven't tried the install part yet, but it seems redundant since the live session has the installer icon on the desktop?
<cjwatson> hardy-bootloader-review spec
<bdmurray> calc: one is ubiquity only without a full desktop
<cjwatson> also, the install-only mode is lighter on memory
<ion_> Sounds good.
<ion_> Let's add compcache to the next release, and it will install on even smaller amount of RAM. :-)
<cjwatson> and bug 109064
<ubotu> Launchpad bug 109064 in ubuntu-cdimage "Boot-up option 'Start or install Ubuntu' scares new users" [Undecided,Fix released] https://launchpad.net/bugs/109064
<cjwatson> ion_: already on the list :-)
<calc> bdmurray: oh ok
<calc> 109064 didn't scare me but confused me due to the perceived redundancy :)
<ion_> cjwatson: Btw, i made a compcache-utils package with an init script that loads the module and swapons, with a /etc/default file you can set the cache size, e.g. "" for the module's default, "50%" for 50% of RAM, "512M" for 512 MiB etc. The package also builds a compcache-source package which can be used with module-assistant, but that of course will become unnecessary when compcache makes it into linux-ubuntu-modules.
<calc> oh also is the language selector supposed to automatically pop up?
<calc> on my system it did
<calc> it showed the boot menu then almost immediately after it popped up the language selector
<ogra> calc, yes
<ogra> it looks a bit scary but the functionallity is good
<calc> looks a bit ugly too since it automatically pops up obscuring most of the screen
<cjwatson> ion_: thanks, that'll be great
<cjwatson> calc: I agree it looks ugly; there's a bug for it
<ogra> but it forces you to select a lang first, which is the important point here
<cjwatson> I'm not sure how to make it better with the time available :-/
<ogra> surely something to revisit in intrepid
<cjwatson> perhaps just a "Select your language" heading would do?
<ogra> it fulfills the purpose
<cjwatson> would make it look less like a mistake
<ogra> can you have scrollboxes in gfxboot like whiptail --menu ?
<ion_> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/200765/comments/6
<ubotu> Launchpad bug 200765 in linux-ubuntu-modules-2.6.24 "Add compcache modules, allowing ubiquity installs on 256MB machines." [Medium,Triaged]
<ogra> i think putting that up centered like a popup win would look a lot better
<calc> ogra: yea it would look a lot better, I don't know if its possible though
<ion_> cjwatson: (The OLDDEV thing is just temporary, it's not going to go to Ubuntu.)
<cjwatson> ogra: would need implementation :-/
<cjwatson> it's possible, but there's no widget for it yet
<ogra> right, intrepid, as i thought
<ogra> i think its good as is even it doesnt look so nice
<cjwatson> I'll look at adding a heading
<cjwatson> I think that would be the smallest change that reduces the confusion
<ogra> yup
<TheMuso> Does the language selection on the disk have a timeout?
<cjwatson> 30 seconds
<cjwatson> in fact after 30 seconds it will simply boot
<cjwatson> urgh, I forgot about accessibility; I guess the instructions need to be updated to say press Enter then F5, sorry :-/
<TheMuso> cjwatson: Thats alright, I'm letting the community know.
<soren> what's the policy for uploading stuff right now? I have a rather serious bugfix for multipath-tools, I'd like to push.
<soren> ...but I'm not sure who frozen we are at this point?
<pitti> soren: uploading is always fine, it'll land in unapproved
<pitti> soren: depending on how critical it is we can accept/respin images, or just release-note it  have people upgrade after install
<soren> pitti: Ah, point.
<pitti> since this doesn't sound install-critical, I guess the latter is adequate?
<soren> Yeah, that'll probably be fine.
<davmor2> are there any xubuntu devs here?
<mvo> bdmurray: I suspect the menu bug is actually caused by the udev being held-back
<bdmurray> mvo: Right, up and down arrows didn't work for me but I thought his point about root shell being the default was valid.
<james_w> davmor2: #xubuntu-devel is probably your best bet.
<mvo> bdmurray: aha - right
<jdstrand> hi slangasek!
<slangasek> jdstrand: hey
<jdstrand> slangasek: would you mind looking at bug #203898
<ubotu> Launchpad bug 203898 in openldap2.3 "slapcat broken when default apparmor profile is enabled" [Undecided,In progress] https://launchpad.net/bugs/203898
<slangasek> looking at it, or approving an upload for it...? :)
<jdstrand> slangasek: I have a packaging patch that seems sane, but wanted to run it by you
<jdstrand> slangasek: look at
<slangasek> ok, peeking
<slangasek> so making them hard links really fixes the issue?
<jdstrand> slangasek: yep
<jdstrand> slangasek: it is a 'feature' of apparmor
<slangasek> hmm - because then the canonical path of the binary doesn't get rewritten to /usr/sbin/slapd
<slangasek> understood
<jdstrand> symlinks are normalized to the binary pointed to
<jdstrand> but hardlinks are evaluated as itself
<slangasek> you've confirmed that they end up correctly as hardlinks within the binary package?  (ISTR that this works with dpkg, but just to be sure...)
<slangasek> otherwise, I don't see any problem
<jdstrand> slangasek: yes
<slangasek> ok, go for it then
<jdstrand> slangasek: ran it through qa-regression-testing (with added tests for slapadd and slapcat for good measure)
<slangasek> cool
<jdstrand> slangasek: cool thanks.  I'll upload with the added goodies for apparmor migration (like what I did for bind9)
<jdstrand> slangasek: since I read your answer on bind9, that'll be post-beta
<slangasek> speaking of qa-regression-testing, you should be able to drop the hardy special-case for SASL passwords again; it's supposed to work now, and if it doesn't we should know about that
<jdstrand> slangasek: goes to check that-- I thought I already did
<slangasek> jdstrand: feel free to upload it any time, it can sit in the queue with a dozen other packages until after beta
 * jdstrand nods
<slangasek> oh, maybe you have; you hadn't last I looked
<jdstrand> slangasek: seems the server overlays are fixed too (I marked the bug as fix released)
<slangasek> ... ok then :)
<jdstrand> (and I did already handle the sasl bits)
<slangasek> I don't think I touched the server overlay stuff, so glad to hear it fixed itself ;)
<jdstrand> well, I think a new version or two of openldap came in and I hadn't checked it in a while
<slangasek> true, I just don't know why the new versions fixed it
<slangasek> (I'd been running the tests here before upload, too)
<jdstrand> it ran passed three times in a row, so I figured "it's fixed!"
<jdstrand> s/ran/ran and/
 * ogra pokes google carefully ....
<ogra> hmm
 * \sh thinks about a beer tonight ... after this day of bad buggers
<stgraber> _MMA_: Ubuntu Studio ISOs are waiting for testers http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all
<_MMA_> stgraber: Already done actually. If I have another day to call it Beta, I'd like to do another build once 2 fixes hit. Should be today.
<stgraber> _MMA_: please report your result so we can coordinate testing :)
<_MMA_> stgraber: Added.
<slangasek> _MMA_: I'm happy to roll new images for you as needed, just say the word
<stgraber> _MMA_: thanks
<slangasek> _MMA_: the Ubuntu beta will still happen tomorrow, but you don't have to do your beta at the same time (it just means you won't be in the announcement that /I/ send out, but no big deal)
<_MMA_> slangasek: I see. The 2 fixes are small but I'c like to have 'em in. I'll talk to my guys. If they feel its not a big deal we'll go with the build from today.
<_MMA_> s/I'c/I'd
<TheMuso> slangasek: I just uploaded genpo, which has a fix we would like for UbuntuStudio. When you get the chance, could you please accept it, and respin disks once the binary is built? Thanks.
<LaserJock> who's archive day is it today?
<slangasek> TheMuso: genpo accepted
<TheMuso> slangasek: Thanks.
<slangasek> bryce, tjaalton: so if someone were to provide some insight into bug #204035, that could be of certain indirect benefit for the beta release, since it's hard for the release manager to get things done while he has to keep resetting his desktop... :)
<ubotu> Launchpad bug 204035 in xserver-xorg-video-intel "945GM: server crashes with "Fatal server error: lockup"" [High,Confirmed] https://launchpad.net/bugs/204035
<TheMuso> Ouch.
<\sh> slangasek: I'm asking you as relmgr...how should MOTU deal with patches introducing LPIA changes? just forgetting them during release cycle, or should we push them to mobile devs, who couldn't deal with the speed of new versions, regarding universe only?
<bryce> slangasek: hmm, we've had a few of these i830WaitLpRing errors reported, though I suspect they're caused by a few different things.  I'll investigate and see what workarounds exist.
<slangasek> \sh: universe is not governed by beta freeze, only by feature freeze; so the patches should be handled accordingly
<slangasek> bryce: ok, cheers
<\sh> slangasek: this is not the problem :) the problem is: 1. a small ammount of motu knows about LPIA 2. the speed of change inside universe is much higher then mobile-devs can provide patches to new versions...it's now my second time I ran into this very special problem (now it's claws-mail which is universe, patch against 3.3.0 and 3.3.1 was pushed yesterday to the archives)
<slangasek> \sh: err, so why is whoever's updating claws-mail not incorporating the existing patch?  how much patching could lpia possibly need?
<slangasek> zul: I don't understand your followup to bug #180493 - how long does it take to get what message?
<ubotu> Launchpad bug 180493 in samba "nmbd shuts down when network disconnected" [Medium,Confirmed] https://launchpad.net/bugs/180493
<bryce> slangasek: with #176377 (which I reported upstream), it sounds like the workaround is to downgrade to -intel 2.1 which makes the issue go away.  Users are in the process of git-bisecting to see which change between 2.1 and 2.2.1 introduced the failure.  Upstream seems unable to reproduce the issue themselves (nor have I, although I have similar hardware), but a number of users confirm it, and evidence so far suggest its the same
<bryce> root problem for everyone.
<zul> slangasek: how long for that message to show in your log files
<infinity> \sh: I'm with slangasek on this one.  I did a lot of the original lpia patches, despite not being a "mobile dev", and most are only a line or two, and are incredibly obvious.
<slangasek> zul: which message?
<infinity> \sh: For some desktop software, it might be 3 or 4 lines (ie: changing some ./configure options, etc), but again, painfully obvious.
<slangasek> zul: I cited three different chunks of log file there
<\sh> infinity: most stuff is ui changes...which is hard to add to new versions for a non-lpia-guy :) I, e.g. would need a device for testing to know what changes are incorporated, and to know how to port those changes to a new version...regarding the special example, it's not just few lines, but see for yourself in bug #198861  which is already outdated, because 3.3.1 hit the archives
<ubotu> Launchpad bug 198861 in claws-mail "There's no flag to enable hildon interface when building for lpia" [Undecided,New] https://launchpad.net/bugs/198861
<zul> slangasek: the "No subnets to listen to" yeah I was trying to reproduce the problem
<zul> slangasek: nm..:)
<\sh> infinity: I'm not talking about simple build fixes...I'm talking about ui changes which are not easily to see when you don't have anything to do with such a device
<slangasek> zul: for all intents and purposes, that one should be instantaneous after you kill -HUP the process
<zul> slangasek: gotcha
<slangasek> \sh: oh, hildon; that's a somewhat different story than lpia
<\sh> slangasek: right :)
<infinity> \sh: Okay, fair enough, that patch not only expect MOTU to understand debian/rules, but to also understand autotools...
<davmor2> slangasek: any idea how long these new images will be?
<infinity> \sh: It still doesn't demand any understanding of hildon, really.
<nixternal> hey, is the display settings with Ubuntu missing or something with these latest hardy isos?
<infinity> \sh: (ie: I can divine what's going on there, and I'm not a hildon dev)
<slangasek> davmor2: still a half hour out; I've been delayed by my X bug, am firing the build now
<davmor2> slangasek: NP
<nixternal> bah, Screen and Graphics Preferences is hiding under the Applications menu right now if nobody has seen that
<bryce> nixternal: yeah, I need to commit something to shut that out
<nixternal> groovy
<\sh> infinity: reading the gtk stuff is not difficult...I'm thinking about stuff like, adding new glade xml templates for hildon etc. regarding me, I would be able to deal with this stuff, when I would have an simulator/emulator for this stuff, as I have for symbian phones ;)
<nixternal> dude, I was going nuts trying to figure that one out
<\sh> infinity: I just want to make sure, that those patches are not lost, just because there is no one who takes care about it
<bryce> nixternal: I assumed just removing all category entries for it would make it disappear, but instead it seems to make it go to a default location
<emgent> heya people
<infinity> \sh: For complex patches, it's entirely appropriate to put the patch author in the patch header (I'm talking debian/patches here, not tiny changes to debian/rules), and beg them for help on upgrades if integrating the patch with the new version is beyond the skills of the person doing the upgrade.
<infinity> \sh: Those cases should be rare, but I realise sometimes a patch can be opaque to some people.
<\sh> infinity: as I said, galculator was the first one, which we didn't updated in time, because of a new patch missing ;) and if someone could point us to a hildonizing emulator or whatever it needs to show up with the different ui, I'll be happy to deal with all this on motu side :)
<infinity> Hrm, does anyone have a quick fix for "The font in the gdm input box is so huge that it spills vertically out of the login prompt"?
<infinity> I assume it's related to "tiny screen + huge resolution = weird DPI"
<slangasek> I hadn't heard of that one at all
<infinity> Just ran into it on the new laptop.
<infinity> 14 inch screen, 1400x1050, hence why I'm guessing it's DPI-related.
<infinity> May also be DPI auto-sensing issues with the nvidia binary driver, since nv doesn't identify my display.
<slangasek> right, what does xdpyinfo claim for your physical dimensions and resolution?
<bryce> infinity: ah, those are typically caused by buggy EDID reported by the monitor, such as reporting physical screen dimensions as cm when they meant mm, etc.
<slangasek> I'm not sure why the text would be scaled differently than the login box itself, though; surely both bits should have the same concept of the display size
<slangasek> bryce: so quirks to fix it?
<bryce> infinity: slangasek's right that you should check xdpyinfo first, then also review the EDID (via Xorg.0.log, or ddcprobe or get-edid | parse-edid)
<bryce> slangasek: righto
<mjg59> bryce: In my case, it seems to be that X forced my DPI to 96
<mjg59> bryce: FWIW, I see this despite my EDID data being correct
<bryce> mjg59: did you also get massively out sized fonts, or just slightly?
<mjg59> Slightly. THe bottom part of the font spills outside the widget.
<infinity> bryce: "dimensions: 1400x1050 pixels (291x210 millimetres), resolution: 122x127 DPI"
<infinity> bryce: Yeah, it's not 3 times the size of the widget or anything, but it spills out (where I'm used to the "dots" being well inside the widget)
<slangasek> well, those numbers come out right then
<bryce> ok, the 96 dpi font forcing was done to combat the hugely outsized font issues people were seeing due to wacked out edid's.  I don't know if we've accumulated sufficient quirks to let us drop the dpi forcing, but presumably that would resolve the slight font missettings
<slangasek> Daviey, superm1: how are things looking for mythbuntu to have a beta at the same time as Ubuntu?
<mario_limonciell> slangasek, should be very feasible.
<mario_limonciell> we can generate live disks and have them on our mirrors and then use the alternate ones generated by you guys
<infinity> bryce: Ahh, kay, so it's not a driver bug, but a forced font thing.  Check.
<slangasek> bryce: mmm, not a good change to make this late in the cycle then, "don't know how many broken EDIDs are left" isn't very tractable :/
<infinity> bryce: And only with gdm, I assume?... Since my fonts on the desktop are sufficiently cute and tiny.
<infinity> bryce: (Which is why I don't care deeply... Having an ugly login box beats having an ugly desktop)
<slangasek> mario_limonciell: ok; you guys are doing your own ISO testing, and things look good?
<mario_limonciell> slangasek, this past weekend tested out the alt's and they looked good
<mario_limonciell> when will the candidate's be in place?
<slangasek> mario_limonciell: the candidate images are already in place
<mario_limonciell> slangasek, okay great.  I'll tell our folks to grab them today and try them out
<mario_limonciell> set to announce beta on Friday right?
<slangasek> Thursday...
<mario_limonciell> ...
<mario_limonciell> i'll let them know irght now then :)
<slangasek> ok :)
<Daviey> mario_limonciell: are we following the same time line as Ubuntu from now?
<mario_limonciell> Daviey, that's the plan provided things stay stable enough for us
<mario_limonciell> Daviey, can you generate a live i386 right now, test it and push it around the mirrors provided things look good then?
<mario_limonciell> have tgm or DaveMorris do an amd64.
<Daviey> great.. we should talk about a testing framework
<mario_limonciell> yeah well for 8.10 I want to get our live disks generated by cdimages.ubuntu.com too, and then we can join the standard testing framework
<Daviey> mario_limonciell: ok, i'll just have to jump on a pc
<mario_limonciell> thanks Daviey
<Daviey> would be good to get out live cd's built daily :)
<mario_limonciell> Daviey, also ask laga to particularly test the diskless stuff on the disk
<bryce> slangasek: I agree.  Sounds like a good thing to do once intrepid opens.
<bryce> slangasek: quirks are usually pretty viable backport candidates so if in intrepid we find the font situations' sorted out, we could consider un-forcing 96 dpi for 8.04.1 perhaps
<bryce> infinity: I don't grok grub 100%, but yeah the dpi situation is separate for gdm and for the logged in X.  I suspect something may be fixing things post-login
<Daviey> mario_limonciell: I've been working on a script to test mirror consistency btw
<Daviey> ie, are they current
<mario_limonciell> didn't tgm throw something like that together alreadY?
<infinity> bryce: Whacky.
<mario_limonciell> check his home...
<infinity> bryce: Now, the million dollar question (for local tweaking, not for distro bugs/changes), is the gdm DPI-forcing in a conffile, or compiled-in?
<bryce> infinity: that I don't know
<infinity> seb128: ^^
<seb128> infinity, bryce: gdm is not forcing anything that I know, it's just using whatever xorg determine as the right value
<seb128> infinity: GNOME is forcing 96 dpi though (after the login)
<infinity> seb128: Oh, hrm, so the issue is rather the inverse... That makes more sense.
<infinity> seb128: The GDM widget itself doesn't scale, but the font does, and since my display is 122dpi (or so), the font is too big for the widget.
<infinity> seb128: Sound about right?
<seb128> yes
<infinity> seb128: Forcing the DPI in xorg.conf would "fix" that, I assume?
<seb128> yep
<infinity> seb128: Danke.
<seb128> infinity: you're welcome
<infinity> seb128: Worst part about a new computer, is tweaking all the little bits that annoy me. :)
<ogra> infinity, nah, admit, its fun ... :)
<infinity> "Yay, it works, but... It's... Not quite right!"
<infinity> ogra: It used to be fun when I was younger, now it's just tedious.
<ogra> dont talk to me about age :P
<infinity> ogra: Just because you're ancient doesn't mean I don't still feel the big three oh.
<ogra> heh
<\sh> ogra: there are still people much older then the two of us ;)
 * heno updates tracker with new Live Ubuntu images
<heno> please test ^
<heno> http://iso.qa.ubuntu.com
<slangasek> heno: thanks, you just beat me to it
<heno> :)
 * TheMuso syncs new live images...
<TheMuso> slangasek: Any ETA on ubuntustudio? I'd like to try and test today before I head off for the weekend if possible...
<slangasek> TheMuso: thanks for the prod, spinning it now; shouldn't take more than 15 minutes or so, IIRC
<TheMuso> slangasek: Thanks.
<_MMA_> :)
<slangasek> TheMuso: images built, mirroring now
<TheMuso> slangasek: Thanks.
<alex_joni> greetings, short security-related question
<alex_joni> how is access to repository signing keys kept in ubuntu?
<jdong> they are stored in a high-security fort guarded with gatling guns.
<jdong> or maybe that was the gold reserves. I always get those two confused in my mind :)
<jwendell> pochu, could you fix bug #201440?
<ubotu> Launchpad bug 201440 in anjuta "Please sponsor anjuta 2.4.0 into hardy" [Undecided,New] https://launchpad.net/bugs/201440
<TheMuso> _MMA_: It seems like one of the fixes that was accepted, genpo, didn't make it onto the disks. Your call as to whether you really want this included, as it is only an icon update after all...
<pochu> jwendell: sure, on it
<jwendell> pochu, thanks :)
<alex_joni> jdong: I was actually beeing serious :)
<jdong> alex_joni: I wish I knew :). Probably one one of the central servers the archive admins have access to.
<infinity> alex_joni: Only a tiny number of us have access to archive signing keys on the master (not world-visible) server.
<cjwatson> alex_joni: do you mean the central repository, as in archive.ubuntu.com signing keys?
<alex_joni> cjwatson: yes
<alex_joni> and I am *not* interested in gaining acces or the like, I'd just like to know the policy if it's public
<cjwatson> alex_joni: the normal signing key is kept on the master archive machine (restricted access, inside datacentre, few logins), since it needs to be used automatically every time the publisher runs
<slangasek> oh, well since you've told us you're not interested in gaining access, that makes all the difference then ;)
<ion_> If you ever lose the private key, just give me a shout, i have a backup.
<alex_joni> I need to set up a sub-repo for custom packages, and would like to do it properly
<infinity> alex_joni: Ideally, the signing should not happen on an internet-facing machine.
<cjwatson> alex_joni: in the event that that is compromised, there's a master signing key which is never kept in full on the network, but which is split up among seven pieces of offline media held by senior Canonical staff
<infinity> alex_joni: So, build your rep and sign it on an internal machine, then mirror it to your "public" archive.
<cjwatson> alex_joni: this is probably overkill for a small archive. :-)
<alex_joni> infinity: that's the current scenario.. but
<cjwatson> what infinity says is generally the most practical, sane approach
<alex_joni> we have a board of directors for the project I work on..
<infinity> alex_joni: Going beyond that for a small archive is likely overkill, as Colin says.
<alex_joni> and the members change yearly
<alex_joni> so having one member holding a key, could result in .. oddness for the next board
<cjwatson> give them a fragment of the key rather than the whole key
<alex_joni> cjwatson: so have the full key somewhere to do the automated signing
<alex_joni> and each member holding a subset of it
<wasabi> Two keys.
<wasabi> no?
<cjwatson> alex_joni: it sounds more reasonable to sign the automatic key with a master key that's held in fragments by the directors
<wasabi> Yeah. Two keys.
<infinity> Two keys, if you're doing the fragment method, yes.
<cjwatson> we use libgfshare-bin for this
<infinity> Master key always offline, you can rotate the archive key (and resign it) whenever you feel the urge.
<wasabi> This way if it is compromised, you can use the master key to issue a new one.
<cjwatson> apt has special support for this type of scheme as of hardy
<cjwatson> see the two keyrings in hardy's ubuntu-keyring.deb
<alex_joni> well, thanks you a lot for the pointers.. I'll look into these, and hopefully figure things out
<wasabi> Though if you rotate board, and a board member refuses to give his piece back.
<wasabi> Split it into redundant pieces.
<wasabi> So N-1 board members are required. ;)
<infinity> RAID5 keys.
<wasabi> Yeah
<alex_joni> our main platform atm is dapper.. but we are working on hardy support :)
<cjwatson> you should use an N-of-M scheme anyway in case one gets lost, or a board member is unavailable
<cjwatson> schemes such as 3-of-5, 3-of-7, 4-of-7 are fairly usual
<infinity> RAID15, works.
<alex_joni> we are 5, so 3-of-5 sounds best
<infinity> In most organisations, this is probably overengineering, unless you suspect a board coup. :)
<cjwatson> on dapper, you may just have to suck up occasionally having to tell your users to change their key
<infinity> But, yeah, the general principle, tailored to your current situation, should do.
<cjwatson> (by some out-of-band trusted method)
<wasabi> YOu also have to ask what type of organization you are, and whether you can reasonably expect a board member to basically violate a contract.
<alex_joni> cjwatson: I don't expect out of the ordinary situations to appear (where the key needs to change), but it would be best if we are prepared for such an event
<alex_joni> wasabi: open source project, voluntary stuff
<cjwatson> I agree that it is better to plan for such things in advance when you have time to do so
<alex_joni> so basicly anyone can decide any given day to throw the towel ;)
<infinity> s/violate a contract/violate a contract that could result in criminal action/
<wasabi> Yeah.
<alex_joni> then there's the bus-scenario .. so having a single point of failure is not the best thing to rely on
<wasabi> I prefer the cliff scenario.
<alex_joni> infinity: that's quite slim as a chance (with the current board)
<wasabi> It's much more imaginative.
<infinity> Lots of people will violate contract if the only remedies are civil, fewer people want to be brought up on criminal charges, oddly enough.
<wasabi> Imagine that.
<LaserJock> cjwatson: you mean Mark doesn't have a sticky note somewhere with the archive key passphrase? :-)
<alex_joni> but having a proper policy, will ensure things for the future..
<infinity> And, especially in the US, but elsewhere too, gaining unauthorised access to systems is a criminal offense.
<cjwatson> LaserJock: correct
<infinity> alex_joni: Yes, the better your processes the better, security is all about balancing "effort" with "possible outcomes", since nothing is ever "perfect".
<infinity> (In a 3-of-5 scenario, you could still have a mutiny, but again, how likely is it?)
<alex_joni> infinity: indeed
<alex_joni> well.. thanks again for all the insight
<alex_joni> (and for the work on ubuntu)
<alex_joni> our users are quite happy working with it
<infinity> alex_joni: While it may seem redundant, it can also be a helpful security practice to point out the very real possibility of criminal action should such a mutiny occur. :)
<infinity> alex_joni: Fear can be much more secure than any technical solution, with the right group.
<infinity> (ie: Not worth mentioning with "screw the man" hacker types, but worth mentioning to people with families who don't dig jail)
<alex_joni> oh, we are aware of the things a criminal can do with a signing key
<infinity> alex_joni: No, no.  I mean "criminal action" as in, "if any of you screw over our archive with your key fragments, we will pursue criminal action".
<infinity> (ie: call the cops, press charges, be very grumpy)
<alex_joni> infinity: hmm, don't think I got that
<infinity> alex_joni: Criminal action = "We'll press charges and you may go to jail", Civil action = "We'll sue you for some random amount of money"... Compromising computer systems is a criminal offense in most western countries these days.
<alex_joni> ok, I get that
<infinity> alex_joni: Making people aware that if they abuse the trust you give them, they could go to jail, can often be more effective than any attempts to split keys 15 ways.
<suweid> Hello, I want to write a transliteration utility for Ubuntu, that would take into account phonetic translitteration of different languages instead of one-to-one mappings currently availible, for example my native tongue - Russian. There exists a set of rules for how russian is most often translitterated into ASCII (for example www.translit.ru), and it involves mappings such as "s" maps to one char, but "sch" maps to another, so to complete 
<suweid> task i need to hijack the keyboard quite early on... Is there a way to do that? Easily. :)
<cjwatson> suweid: hooking into scim would be the usual way to do this
<infinity> alex_joni: Like I said, fear shouldn't be the backbone of your security infrastructure, but having it footnoted in a contract when the keys are handed out isn't a bad plan to make people realise the severity of the responsibility being given to them. :)
<cjwatson> suweid: scim-tables-additional already ships an input method for Russian ...
<alex_joni> infinity: well, a short downside for that is that our board is not a formal entity
<suweid> Is that so, let me investigate.
<alex_joni> I mean, not a registered entity
<infinity> alex_joni: Formal entity makes no difference, if you formally empower (and disempower) each keyholder, on a time-limit or such.
<cjwatson> suweid: we don't enable it by default, but you can turn it on in System -> Administration -> Language Support -> Enable support to enter complex characters, then log out and log back in
<alex_joni> infinity: ok, got your point.. don't think it will ever get that far though :P
<infinity> alex_joni: Much like an employee becomes a "cracker" the moment he's fired, even if he still has access to his employer's computers.  Your board members become rogues when their board term expires.
<suweid> Hey, that's great! I feel a little silly that i tried to reinvent the wheel though...
<infinity> alex_joni: In the end, should someone abuse your trust, there's little you can do about it that doesn't involve the police (or hiring someone's grandmother to chastise them), so it doesn't hurt providing fair warning. :)
<cjwatson> suweid: it appears to support "qawerty", which doesn't seem like what you're talking about
<cjwatson> so it might need a new method - but that's the framework
<suweid> Okay, thanks again, I'm going to investigate.
<alex_joni> infinity: well, I haven't heard of any OSS project going that far
<alex_joni> hope the OSS comunity stays that way :P
<infinity> alex_joni: Not that you know of, at any rate.
<Kopfgeldjaeger> n8
<infinity> alex_joni: I can't imagine many projects that would want to publicise having raised criminal action against "one of their own" for being an idiot. :)
<alex_joni> infinity: haha, surely not
<alex_joni> maybe just about "for beeing an ass.."
<infinity> Well, fine, s/idiot/ass/, then.
<infinity> We only punish people for idiocy by ridiculing them on IRC. :)
<alex_joni> I mean ill-intended person
<alex_joni> infinity: can you describe the difference between master key and archive key?
<infinity> alex_joni: Archive key exists in full on the machine that auto-signs the archive.
<infinity> alex_joni: Master key exists in fragments, and is used to sign the archive key.
<alex_joni> so once set up, the master key has no use, until a new archive key is needed?
<infinity> alex_joni: Exactly.
<infinity> alex_joni: It's used only to sign new keys or revoke old ones.
<infinity> (Well, revoke signatures from old ones, since an outside entity can never revoke a key outright)
<alex_joni> hmm.. here's a thought.. currently we have no *dedicated* server which is not a user-owned server, or a server where more than one board-member has access
<alex_joni> so I'm not sure if the scenario can be implemented as *cleanly* as you do for ubuntu
<alex_joni> could somebody go to the *offsite* server, and just reissue a new archive key?
<alex_joni> or would that one be an invalid key?
<infinity> It would be invalid if not signed by the master key, if you're using the chaining method from hardy.
<infinity> (The trick is to only distribute the master key to your users, so their apt only trusts the archive key implicitly, not explicitly)
<cjwatson> we distribute both, as otherwise they'd need network access to verify any packages we shipped
<alex_joni> ah, I see now
<infinity> cjwatson: Oh, feh.  We need to find a clever way to fix that too.
<cjwatson> surely gpg can't do two-level checks without having the public key in the middle
<cjwatson> that seems kind of fundamental
<infinity> cjwatson: (I haven't looked at the current apt implementation)
<infinity> cjwatson: Can we not distribute both keys, but only trust one?
<cjwatson> it has a scheme to update from the net and trust anything signed by the master key
<infinity> trusted.gpg and keyring.gpg?
<cjwatson> that's what we have
<infinity> Right, assumed, but your last comment confused. ;)
<cjwatson> you said "only distribute the master key to your users", but you have to distribute both
<calc> Riddell: i just realized something that is fairly obvious... all of dapper (not just the ubuntu cd) needs to be upgradable to hardy properly since a user could have installed various things outside of whats on the cd (including parts of kde, etc)
<infinity> cjwatson: Yeah, bad wording.  "Only trust the one key".
<cjwatson> calc: yup
<calc> cjwatson: do we have any kind of testing to make sure that works?
<cjwatson> calc: meet mvo
<Riddell> calc: yes, mvo has been testing the whole world
<calc> cjwatson: heh ah
<calc> cool :)
<cjwatson> otherwise known as "upgrade test machine"
<calc> i used to have a script that i used on kde that would spit out what conflicts/replaces items i needed, so i wouldn't break upgrades on debian, but it was not automated at all
<cjwatson> there's a file conflict checker for Ubuntu, FWIW
<pochu> jwendell: I've requested a sync for it
<cjwatson> http://conflictchecker.ubuntu.com/possible-conflicts/
<cjwatson> for instance http://conflictchecker.ubuntu.com/possible-conflicts/hardy/main.txt has "openoffice.org-hyphenation_0.2_all[gutsy/main, hardy/main, feisty/main], openoffice.org-hyphenation-en-us_2.3-5_all[hardy/main] ['usr/share/myspell/dicts/hyph_en_US.dic']"
#ubuntu-devel 2008-03-20
<cjwatson> which means that the version of openoffice.org-hyphenation in hardy (and incidentally also feisty and gutsy) shares a file with the current version in hardy
<cjwatson> more usually the second named package will be from an older release, and you can use that as a hint for the << you need to use in Replaces
<calc> ok
<cjwatson> it looks like that particular one is out of date, mind you
<jwendell> pochu, thanks
<cjwatson> ah, it's because it was in hardy, and therefore you need a Replaces to account for that
<cjwatson> not necessarily that it is currently in hardy - it keeps historical information
<cjwatson> note that those lists will have false positives where dpkg-divert is involved and appropriate manual overrides haven't been added
<calc> oh ok
<calc> yea that list looks really nice :)
<alex_joni> g'night all, and thanks again for the info
<Prometheus> is the release still on for tomorrow?
<Hobbsee> morning sabdfl
<PaulOgle591> #ubuntu-motu
<PaulOgle591> #ubuntu-devel
<PaulOgle591> I have a question about wubi?
<PaulOgle591> #ubuntu
<TheMuso> rats.
<TheMuso> Just missed him.
<ogra> he is in #ubuntu i think
<theunixgeek> What's the difference between a delete_event and a destroy event in GTK?
<nxvl> is there any way to debug a postinst without building the package?
<cjwatson> you can edit them in place in /var/lib/dpkg/info/
<cjwatson> most are shell, so adding 'set -x' near the top will give you an execution trace
<nxvl> cjwatson: the problem is that i need it to be on fresh install
<nxvl> mm
<nxvl> cjwatson: i will try to check what to do, thanks :D
<cjwatson> nxvl: 'dpkg --unpack foo.deb', edit /var/lib/dpkg/info/foo.postinst, 'dpkg --configure foo'
<cjwatson> debugging the preinst is harder; for that you need to unpick the deb with ar and tar and then put it back together again the way you want it
<cjwatson> doable but tedious
<nxvl> cjwatson: oh! thanks i will unpack it :D
<nxvl> mm
<nxvl> but unpack is running postinst
<cjwatson> incorrect
<slangasek> no
<slangasek> postinst is the --configure stage, which happens after unpack
<nxvl> i'm doing dpkg --unpack and it is running things i have write on .postinstt
<cjwatson> then you have made a mistake somewhere. dpkg --unpack does not run the postinst.
<nxvl> can it be running the .config?
<cjwatson> (except in cases where it needs to roll back from errors)
<cjwatson> it might run the .config if you have '. /usr/share/debconf/confmodule' in your .preinst script
<ogra> swapped postinst with preinst ?
<cjwatson> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
<cjwatson> dpkg doesn't call .config directly, only when you source the confmodule
<nxvl> cjwatson: thanks
<cjwatson> (because debconf is only integrated into dpkg with spit-and-sawdust)
<nxvl> cjwatson: thats the why
<nxvl> wooohooo
 * nxvl HUGS cjwatson 
<cjwatson> the difference between config and postinst is rather important ... :-)
<nxvl> if i run "dpkg --reconfigure foo" it will run the scripts on /var/lib/dpkg/info/ doesn't it?
<nxvl> err
<nxvl> dpkg-configure
<cjwatson> there is no such program. Do you mean dpkg-reconfigure?
<cjwatson> read its code and look around line 96 for what it does
<cjwatson> it's quite a short program
<bryce> is there a way to set upstart to boot up a system without starting gdm?
<bryce> essentially, boot into root level 2?
<bryce> er run level 2
<slangasek> the default runlevel with upstart is 2; though I understand what you mean, that runlevel layout is RH-specific
<j1mc> hi all - i asked in #ubuntu-motu earlier, but got no response.  the xubuntu-docs are finished. (you can view them at: http://doc.ubuntu.com/xubuntu/ ) would someone be willing to build them for me, or to help me build them?
<TheMuso> slangasek: Ok, _MMA_ and I are happy with UbuntuStudio images.
<j1mc> https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/xubuntu-hardy
<slangasek> TheMuso: http://iso.qa.ubuntu.com/qatracker/build/all/all doesn't show any test results, is that validation in progress?
<TheMuso> ugh hang on
<TheMuso> _MMA_: ^^^
 * TheMuso only tested a manual partition install with creating new partitions... I have no time to do other tests, so I supposed I'll have to leave it up to the others to give the final word then. _MMA_  stated that he was happy, dispite having only done one form of install, which one I am not sure...
<bryce> hrm, well guess I can just have them twiddle /etc/X11/default-display-manager
<slangasek> bryce: so in theory, you could get what you wanted by mv /etc/rc3.d/{S30,K30}gdm, and then, if upstart's sysvinit emulation is feature-complete, append '3' to the end of the boot line in grub
<bryce> ok
<bryce> brb (rebooting fresh upgrade from gutsy to hardy, wish me luck)
<bryce> yay
<_MMA_> slangasek: Sorry. Had alot going on here. I did 2 tests. Added the results.
<slangasek> _MMA_: ok, cheers
<calc> are there any negatives to using wubi?
<tritium> You have to have Windows?
<bdmurray> heh
<ash211> you'll be running two OSs at once, so things will be slow
<ash211> at least Windows-slow :)
<RAOF> ash211: But you won't, right?  You boot into linux on the metal; it's not virtualised.
<ash211> I'm pretty sure it is, actually.
<ash211> It's homepage says you don't need to modify partitions or bootloaders, so I'm thinking it must run as an app within windows
<ash211> everything I'm reading seems to point that way
<ash211> http://wubi-installer.org/
<RAOF> It doesn't change the partitions because it makes a filesystem in a file on your existing NTFS partition, and it doesn't add a *new* bootloader because it uses Windows' existing bootloader.
<calc> ash211: it doesn't run on top of windows
<ash211> hmm, didn't know that
<ash211> looks like I had a fundamental misunderstanding in how it works
<calc> evand: any ideas?
<calc> i need to blow away my laptop anyway so i was considering just reinstalling ubuntu in wubi form since it appears ubuntu supports ntfs write properly now
<calc> i need windows occasionally on bare metal (not via vm) to update stuff
<bdmurray> stuff sounds mysterious
<calc> hmm sounds like hibernation/suspend may not work on it
<calc> which isn't good for a laptop
<Griswold> Wonder if wubi runs in Wine...
<ash211> now that's a headache!
<Griswold> Yeah :P
<Griswold> Recently, we got Cygwin running in Wine :)
<Griswold> Like in the last couple weeks, iirc.
<Griswold> There are still some problems, like GCC doesn't work properly, etc.
<Griswold> But the basic shell runs.  :)
<Griswold> Wubi edits the bootloader?
<calc> wubi is just an installer i think
<calc> that causes the windows bootloader to load something to bootstrap a loopback linux boot
<calc> so no it wouldn't run under wine
<calc> or at least would be very unlikely to do so properly
<Griswold> Yeah
<bdmurray> there is some info at https://wiki.ubuntu.com/Testing/Cases/Wubi
<calc> looks like hibernation doesn't work according to the wiki beta page
<calc> but sleep should
<calc> anyone familiar with virt-manager?
<slangasek> I know it can be used to administer guests on a remote server, because that's what the release notes in front of me say ;)
<calc> heh yea
<calc> well i am trying to get virt-manager/kvm setup so i can get rid of vmware
<calc> but it won't let me select the "enable kernel/hardware acceleration" option
<slangasek> 64-bit system?
<calc> yea
<slangasek> laptop?
<bdmurray> slangasek: I'm having issues using my wubi install of ubuntu should that be a wubi bug?
<calc> 64bit desktop that has the vmx extension
<slangasek> bdmurray: as I starting point, I suppose so?
<slangasek> calc: then you're already a step ahead of me in the analysis :)
<calc> thats all i know to do
 * calc thinks there should a setup page on the wiki about it
<slangasek> I agree
<calc> keescook: you awake?
<calc> iirc keescook was mentioning he was using it earlier today
<calc> i was going to host all my images on my desktop to get rid of the space issue on my laptop
<calc> and then found out it is supposed to run it faster with hardware accel, but its still grayed out
<calc> my laptop is one of the cheapo chips with it disabled
<calc> apparently the chips they use in store laptops don't have it (or didn't last june)
<slangasek> my laptop was not cheap, but it's still disabled :P
<slangasek> I'm told that it's largely a BIOS issue
<calc> slangasek: oh
<slangasek> at least for mine
<calc> i think for some its disabled in cpu itself, and iirc mine is like that
<calc> its a C2D T5300
<slangasek> right, mine's a T5500; I hadn't heard about the possibility of disablement within the CPU
<slangasek> I just know "no worky"
<calc> ah ok
<Amaranth> as i understand it it's just your BIOS locking it out because you didn't buy the business laptop
<Amaranth> not that it helps
<calc> Amaranth: so its not something that the kernel can just override like it can in most other cases?
<Amaranth> I guess not
<Amaranth> what laptop is this?
<Amaranth> oh, desktop
<Amaranth> hrm
<calc> well on my desktop it shows that it supports it in cpuinfo
<calc> but virt-manager won't let me select the box
<calc> on my laptop it doesnt show that it supports it in cpuinfo
<Amaranth> ah, so what laptop?
<calc> toshiba satellite A205-4577
<Amaranth> of course the hardware extensions don't really speed things up
<Amaranth> vmware will still blow it away
<calc> Amaranth: oh :-\
<Amaranth> the vmware guys found that when they made vmware use the hardware extensions things got slower
<calc> http://www.intel.com/products/processor_number/chart/core2duo.htm
<calc> according to intel, whether its in bios or not, my and slangasek's cpus don't do VT
<Amaranth> ah, sucks
 * calc wonders what Intel Trusted Execution Technology is
<Amaranth> i guess they had to do something with the chips that failed testing
<calc> its not the execute disable bit, so wonder what tha tis
<calc> all of the T7XXX series does it
<dholbach> good morning
<warp10> Hi all
<highvoltage> good morning dholbach
<dholbach> hi highvoltage
<keescook> calc: yeah, check with soren just in case.
 * dholbach hugs keescook
<keescook> hi dholbach!
<keescook> lamont: say, I'm tracking down an issue, and I've traced it back to swapon in feisty.
<keescook> lamont: between feisty and gutsy 30swsusp-resume.dpatch vanished without reference in the changelogs.
<keescook> lamont: the patch seems to be the cause of the "zomg my swap UUID changed" bug, and lacking is the cause of the "ack, I have no swap anymore" bug.
<keescook> lamont: seems the correct fix is to teach mkswap how to re-use and existing UUID, and then update 30swsusp-resume accordingly -- that should fix both bugs.
<hunteke> so, I see http://brainstorm.ubuntu.com/idea/94/ (#1 idea, suspend), and have read some of the comments, such as this is extremely difficult for many factors.  Is there any momentum on this front, in spite of the many factors?
<keescook> lamont: oh, hey, hardy mkswap supports UUID.  :)
<pitti> Good morning
<superm1> slangasek, verified the i386 works for us.
<superm1> (on the mythbuntu alt disk that is)
<slangasek> superm1: great, thanks
<slangasek> pitti: morning
<pwnguin> hunteke: it's something that will take more than ubuntu to fix. it's not just attention to a few details and patches away from "just working"
<pwnguin> hunteke: I think mjg59's been doing a decent job cataloging the problems with the current "architecture"
<superm1> unfortunately too, issues lie in the videobios sometimes
<hunteke> pwnguin: alright, I'll buy that.  But is there a discussion somewhere about it?  The only thing I see from Canonical/Ubuntu are borked scripts/hibernate,sleep buttons, and details through brainstorm.
<hunteke> pwnguin: cool where do I find that?
<hunteke> mjg59's stuff that is
<pwnguin> linuxconf. lemme grab a link real quick
<superm1> which on the windows side of things, that's part of the reason why they will only qualify a particular driver release to that machine.  they have a special code path to work around a bad vbios
<hunteke> k, thx
<pwnguin> http://mirror.linux.org.au/pub/linux.conf.au/2008/Fri/mel8-139.ogg
<pwnguin> http://linux.conf.au/programme/presentations
<hunteke> superm1: yeah, I sorta figured, part of the buying-through-a-vendor-service and MS tax, I expect
<hunteke> pwnguin: oh excellent! it's a movie presentation.  :-)
<superm1> well not even that.  it's exclusively that vendors don't always stick to the "spec"
<hunteke> much easier to digest
<pwnguin> well, broken video bioses etc can probably be avoided by intelligent linux laptop vendors
<pwnguin> but even in such limited and advantageous, I dont think the current suspend / hibernate regime is helping
<hunteke> pwnguin, superm1: so perhaps a better question, how can I help tilt against this windmill?
<pwnguin> hunteke: read LKML?
<superm1> the problem with them is that they typically freeze a month or two before the laptop is about to be released, so if linux is an afterthought by the vendor, they won't have much leeway in getting vbios fixed.
<hunteke> pwnguin: no, just the digest I get through LJ
<pwnguin> hunteke: which is that?
<hunteke> Linux Journal
<hunteke> sort of more oriented towards beginners
<pwnguin> oh. not liveJournal.
<hunteke> that say, linux magazine
<pwnguin> makes more sense
<hunteke> heh
<thekorn_> morning dholbach, I added a dialog to choose teams to https://code.edge.launchpad.net/~thekorn/five-a-day/teams.applet
<pwnguin> hunteke: well, aside from patience and learning more, you could perhaps found a kernel forum on the subject?
<pwnguin> or fund one ;)
<abogani> keescook: Are you around?
<dholbach> abogani: he might have gone to bed (0:52 at his place)
<dholbach> thekorn: you ROCK - looking at it in a bit
<abogani> dholbach: Ops Sorry!
<hunteke> pwnguin: sorry had to run away for a min.  hehe, seeing as how I'm basically a poah-ass-student, funding isn't an option.
<hunteke> I would like it to be though.  so perhaps after I make my first million or something . . .
<hunteke> are there other things I, as a peon could do?
<hunteke> read lkml I suppose
<slangasek> the options basically involve "practice patience", or "become an expert and get irreversibly sucked in to the development process" ;)
<hunteke> hehe, alright.  I guess I was looking for more social things
<hunteke> perhaps analogous to "writing my congress/senator"
<keescook> abogani: while dholbach would normally be right, I'm addicted to fixing a swap/resume issue at the moment.  what's up?
<dholbach> keescook: wow
<slangasek> hunteke: in reference to fixes for laptop support? you have far less leverage with your laptop vendor than you do with your senator :-P
<hunteke> hah
<slangasek> keescook: pff, who are you kidding, I see you keeping late hours all the time :)
<hunteke> say, where're you all?
<pwnguin> kansas
<keescook> slangasek: I want to deny!  ... but it's true.
<hunteke> it's almost 4a here, well past my bedtime
<pwnguin> (yes, it is way late here)
<slangasek> Cascadia!
<dholbach> and I thought I was mad getting up early because my girlfriend had to (after a very short night) :)
<abogani> keescook: Sorry for bother you but #107209 is already fixed. Please set it accordingly for Gutsy and Hardy. Dapper seems not affected.
<slangasek> dholbach: oh, don't let the presence of either kees or myself leave you with any doubts about your own madness
<slangasek> I assure you, I'm also quite mad
<dholbach> slangasek: I wouldn't dare to excuse my own madness with that of other people :)
<keescook> abogani: dapper is affected (it lacks the "fix" that was attempted in 2.6.17).  Yes, Hardy is fixed (which is why there isn't a "linux" task)
<keescook> I knew I was in trouble when I'd say thing like "Am I crazy, or $blah", and people would say "yes".
<abogani> Why bug is marked "In Progess" fro Hardy and Gutsy? :-?
<keescook> abogani: not sure where you're looking ... linux-* tasks are a bit oddball (there is no "hardy" version of linux-source-2.6.15 e.g.)
<abogani> Opss i' looking wrong bug report!
 * abogani really need a coffe!
<keescook> abogani: oh! haha. okay, sanity returns
<keescook> lamont: debdiff attached to bug #66637 for your examination.
<ubotu> Launchpad bug 66637 in util-linux "After running mkswap, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Fix committed] https://launchpad.net/bugs/66637
 * keescook goes to bed
<dholbach> good night keescook
<TomaszD> pitti, when will langpacks be released? it's been over a week I think
<pitti> TomaszD: right after beta freeze is over
<TomaszD> pitti, thanks
<soren> calc: "Executable Disable" bit is the ability to mark certain pages in RAM non-executable. It foils buffer overflow attacks.
<soren> calc: You may have heard about it as the NX bit.
<mvo> pitti: I commited a small fix for dapper->hardy upgrades into the hal bzr, please review and if you are happy, I'm going to upload
<soren> calc: It's true that certain C2D's don't have the IVT extensions, namely the T52x0, T5300, T54x0, T5500 with stepping "B2", E2xx0, E4x00 and E8190 models. (reference: http://en.wikipedia.org/wiki/VT-x#Intel_VT_.28IVT.29)
<slangasek> soren: so if I see stepping: 6, does that mean the chips support it and my bios is ornery?
<\sh> if somebody is so kind, and can explain how to setup a sane and clean chroot for building lpia apps on archs like i386 or amd64...reading this maemo-sdk-setup-doing-manually-stuff on nokia pages scares me...are the any possibilities to do it in a debian way? :)
<soren> slangasek: If you're looking at the cpuinfo anyway, just look for "vmx" in the cpuflags.
<slangasek> \sh: debootstrap --arch lpia?
<soren> slangasek: (Notice how I avoided exposing my lack of ability to actually answer your question)
<slangasek> soren: yeah, no vmx in the cpuflags; I was vaguely hoping that was because the BIOS had hidden it from me :/
<soren> slangasek: No.
<soren> slangasek: The cpuflags will show it regardless.
<soren> slangasek: When you try to load the modules, they'll tell you that the BIOS doesn't like you.
<slangasek> heh, ok
<\sh> slangasek: if this is so easy...is it compiling to i386 or ARM arch?
<soren> lpia is i386 compatible.
<\sh> soren: thx
 * soren wanders off again (seeing as he's supposed to be on holiday)
<pitti> how can I reduce the 'wait for root fs' delay again?
<ogra> pitti, isnt that just waiting until the device shows up (HW dependant)
<pitti> right, but in my special case I need to fix the initramfs first, and I'm sick of waiting one minute :)
<emgent> heya people
<seb128> is the language selector menu item not working on the CD a known issue?
<slangasek> ummm
<slangasek> which one?
<slangasek> the one that opens right at boot?
<seb128> slangasek: system, administration,  language support
<slangasek> Ubuntu? Kubuntu?
<mvo> seb128: what happens if you click on it?
<mvo> seb128: and what is printed on the terminal if you run: gnome-language-selector?
<seb128> mvo: the desktop has "/usr/bin/gnome-language-selector -n" as a command
<seb128> mvo: the "" are breaking it
<slangasek> there was a bug reported against language-selector-qt only
<slangasek> so I guess the gnome one wasn't tested
<seb128> clicking on it gives a "no such file or directory"
<mvo> seb128: that is strange, my bzr looks fine
 * mvo investigates
<seb128> withou the "" around the command name it works correctly
<seb128> hum, I don't get it, the version installed on my desktop doesn't have the bug
<seb128> ah, 0.3.1 on the CD
<mvo> I think its because the desktop file is modified for the language-selector ..
<seb128> how come?
<mvo> in livecd build (or whatever the script is called :)
<mvo> its run with -n there to supress the message about missing language-pack packages
<seb128> ah ok
<seb128> so whatever does this change is buggy
<seb128> cjwatson: ^?
<mvo> it probably happend when we swichted it from root to use and removed the gksu
<pitti> \o/ I managed to do an encrypted LVM installation with the desktop CD
<cjwatson> ./scripts/casper-bottom/35fix_language_selector:24:    sed -i '/^Exec/ s|/usr/bin/gnome-language-selector|"& -n"|' /root/usr/share/applications/language-selector.desktop
<cjwatson> seb128: that code dates from October 2006
<cjwatson> seb128: have the semantics of Exec changed?
<seb128> cjwatson: not that I know, but could be a side effect of the gnome-desktop switch to gio
<seb128> I'm not sure it's correct to use "" there or if the fact it was working before was a bug
<seb128> let me look at the spec
<cjwatson> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html seems to suggest it was a bug that it worked before
<davmor2> ogra ping
<cjwatson> is there a bug number for this?
<seb128> cjwatson: not that I know, I was asking what would be the right component
<cjwatson> casper
<slangasek> calc, bdmurray: does bug #203984 really refer to suspending *from* the CD, or from a system installed using it?
<ubotu> Launchpad bug 203984 in linux "[hardy beta] [amd64] squashfs errors on resume from desktop cd" [Medium,Triaged] https://launchpad.net/bugs/203984
<seb128> cjwatson: bug #204185
<ubotu> Launchpad bug 204185 in casper "language-selector menu entry broken due to extra quote use" [Undecided,New] https://launchpad.net/bugs/204185
<cjwatson> the history suggests that in fact it was necessary at one point
<cjwatson> "Make sure to quote arguments to properly" is the (slightly mangled, apparently) log message
<ogra> davmor2, pong ?
<davmor2> ogra: edubuntu failed to install from netboot (mini.iso)
<ogra> oh, crap, we need to stop building that
<cjwatson> seb128: thanks, fixed in bzr
<seb128> cjwatson: thank you
<cjwatson> ogra: no we don't, mini.iso is common to everything
<cjwatson> you just need to stop testing it ;-)
<ogra> hmm
<ogra> well, it shouldnt be in the task list
<cjwatson> davmor2: Edubuntu is only installable as an add-on CD now; discard all test cases that involve testing it directly
<davmor2> think it is to do with italc-client
<cjwatson> oh, netboot
<cjwatson> that actually should work
<cjwatson> ogra: no reason why not, if installing over the network
<ogra> oh, right
<ogra> that should j8ust install edubuntu-desktop
<cjwatson> davmor2: post syslog
<davmor2> ogra: I'm letting stgraber know the error
<davmor2> cjwatson: How do get the syslog?
<ogra> italc-client only depends on libitalc libqt4-core libqt4-gui
<ogra> so i wonder what can go wrong ther
<ogra> e
<cjwatson> davmor2: back up to the installer main menu and select "save debug logs"
 * ogra tries to apt-get it 
<stgraber> I tried edubuntu addon yesterday on i386 and it worked well, italc was installed and working after rebooting
<stgraber> and I'm running the devel package for iTalc on my lappy (amd64)
<ogra> works fine from apt-get as well
<ogra> and runs with no problems ...
<slangasek> yes, speculation is moderately pointless without the log file :)
<ogra> yup
<ogra> hum
<ogra> actually i dont understand why it gets pulled in at all
<ogra> its only a dep in the addon seed, not of edubuntu-desktop itselrf
 * ogra wonders if tasksel exposes edubuntu-desktop-addon instead of edubuntu-desktop
<pitti> mvo: ugh, good catch; please upload
<davmor2> guys goto www.davmor2.co.uk
<davmor2> cjwatson: ogra: stgraber:
<mvo> thanks pitti, will do
<slangasek> davmor2, stgraber: use of deprecated chown syntax in postinst
<davmor2> slangasek: no idea it just stopped installing :)
<slangasek> stgraber: but I guess the more significant problem is that the package assumes group 'admin' exists when it doesn't?
<stgraber> indeed
<stgraber> when is the admin group created ?
<ogra> i would be more intrested why its pulled in at all
<slangasek> dunno; it's not part of base-passwd, I would suggest that you simply try to create the group yourself before using it
<stgraber> slangasek: hmm, wouldn't that cause a fail for the package that actually creates it ?
<slangasek> shouldn't
<stgraber> "addgroup admin" when "admin" exists returns 1
<slangasek> all such packages *should* know how to handle a group that already exists; I'm looking for the responsible package to verify, though
<davmor2> guys anyone who needs the log if you can copy it that would be great then I can carry on testing
<slangasek> stgraber: well, the only package I see creating the group in postinst on my system is jockey-common
<stgraber> davmor2: for me that's ok, I know what to change
<slangasek> I don't think you want to depend on that :)
<stgraber> indeed :)
<stgraber> so it's probably created by the installer when adding the user to the system
<slangasek> but, jockey-common does have a good example of how to do this idempotently
<slangasek> yes, probably
<davmor2> anyone else need the log?
<davmor2> stgraber: the same thing happen on 64bit too
<slangasek> yes, it's not architecture-dependent
<stgraber> slangasek: how can I quickly check if the group exists ? (!= parsing /etc/group)
<slangasek> stgraber: see the jockey-common postinst -- "getent group admin"
<stgraber> ok, will be fixed after beta (I need to upload a fix anyway)
<ogra> ogra@ceron:~/devel/seeds/edubuntu.hardy$ apt-cache show edubuntu-desktop|grep italc
<ogra> ogra@ceron:~/devel/seeds/edubuntu.hardy$
 * ogra scratches head
<stgraber> what's exactly the problem ? the edubuntu desktop task installs the content of edubuntu desktop addon task ?
<slangasek> ogra: education-thin-client-server suggests it, though it's a bit odd if that causes it to be pulled in
<ogra> i wonder if -meta is out of sync
 * ogra tests an update run
<slangasek> the Packages file lists italc-client as part of edubuntu-desktop-addon task, yes
<ogra> right
<stgraber> that's right
<ogra> but its not in -desktop
<stgraber> so netinstall installs edubuntu-desktop-addon instead of edubuntu-desktop ???
<ogra> -addon creates -desktop
<ogra> or: is the base for *
<ogra> Added italc-client to desktop-addon-i386, desktop-addon-amd64, desktop-addon-powerpc, desktop-addon-ia64, desktop-addon-sparc, desktop-addon-hppa, desktop-addon-lpia
<ogra> Removed thin-client-manager-gnome from desktop-kde-i386, desktop-kde-amd64, desktop-kde-powerpc, desktop-kde-ia64, desktop-kde-sparc, desktop-kde-hppa, desktop-kde-lpia
 * ogra cries
<ogra> slangasek, fine with you to fix that after beta ? i dont want to delay anything
<stgraber> does that only affect the netinstall ?
<slangasek> ogra: yes, after beta should be fine
<ogra> there is no other method i know of that would allow you to use edubuntu-desktop dirctly on install
<mdz> my fonts in mutt are borked after last week's updates; it can't display line drawing characters or international characters
<ogra> so likely only the netboot is affected
<mdz> has anyone else seen something similar?
<slangasek> not here, mutt displays fine for me
<ogra> mdz, checked your locale ?
<stgraber> if that's only netboot, it'll be fixed as soon as the fix is uploaded so will be fixed hours after Hardy's beta.
<stgraber> _MMA_: Ubuntu Studio Alternate i386 (20080319.1) needs testing
<Riddell> mvo: what would you think to adding a Kubuntu KDE 4 Desktop file in app-install-data?
 * Hobbsee wonders when jono will appear.
<Riddell> Hobbsee: do you need him for something?
<davmor2> Hobbsee: after the hard work is done ;)
<Hobbsee> Riddell: got some questions on dealing with abuse of power, and how to do that.
<Riddell> Hobbsee: he's on #kubuntu
<Hobbsee> Riddell: oh, he's in -women too.  should have checked for that, thanks.
<Riddell> good to know he knows his place in life :)
<davmor2> Riddell: you'd think the beard was a give away though wouldn't you :)#
<Hobbsee> Riddell: heh :)
<Seveas> davmor2, or the duck :)
<mvo> Riddell: that sounds good, that will install kubuntu-kde4-desktop ?
<Riddell> mvo: yes
<Riddell> mvo: can I add that somehow or do you have to do it?
<mvo> Riddell: I added it to my bzr tree
<Riddell> mvo: groovy
<pitti> mdz: mutt WFM
<pitti> argh, just got that g-settings-daemon start failure on the live system
<timlinux> Hi. Can someone point me to the correct channel to ask questions relating to PPAs
<Fujitsu> timlinux: #launchpad
<timlinux> Fujitsu: many thanks
<timlinux> launchpad seems to be missing from the wiki: https://help.ubuntu.com/community/InternetRelayChat
 * timlinux will see if he has perms to add it
<Fujitsu> It's not part of Ubuntu.
<timlinux> cheers
<timlinux> ah
<timlinux> what is it part of?
<cjwatson> stgraber: the admin group is indeed created by user-setup while adding the user to the system; please use addgroup --system admin to create it, not just addgroup
<Fujitsu> It's not part of anything.
<timlinux> Fujitsu: :-)
<timlinux> Fujitsu: everything is part of something
 * timlinux is going meta
<timlinux> ok thanks for the info, cheers
<ogra> Fujitsu, well, ts part of the public conspiracy to lower microsofts market share :)
<Fujitsu> ogra: Heh. True.
<ogra> even thought i'm not actually sure there is such a thing like a public conspiracy :)
<persia> One can conspire publically.  Conspiracy is a matter of intent :)
<ogra> ah
<ogra> i thought secrecy was mandatory
<highvoltage> ogra: nah, the secrecy just makes it more sensational once it gets out. it's a marketing trick :)
<persia> Also, it's typically easier to conspire secretly.  When your opponent can see your plans, they are more able to counteract.
<_MMA_> stgraber: Sorry. I had. Just forgot to add the results there. I just added 64bit results. Added now.
<stgraber> cjwatson: ok, thanks
<stgraber> _MMA_: thanks
<stgraber> _MMA_: btw, during release time you may want to join #ubuntu-testing for ISO testing related stuff
<Kopfgeldjaeger> hi
<mdz> ogra__: haven't changed my locale
<mdz> still en_US.UTF-8
<mdz> changing to .ISO-8859-1 gets it displaying properly again
<mdz> but I don't know why
<_MMA_> stgraber: Sure. I try to. Just been hectic around here.
<stgraber> davmor2: Do you have a bugnumber for the iTalc problem you found earlier ? (I have the fix but would like to link to LP)
<davmor2> stgraber: not bugged it yet was trying to find out what to report it against when you said you could fix it
<davmor2> stgraber: I can throw one to gether now for you if you want
<stgraber> davmor2: please report against /+source/italc/
<stgraber> https://launchpad.net/ubuntu/+source/italc/+filebug
<davmor2> stgraber:          Bug #204235
<ubotu> Launchpad bug 204235 in italc "Edubuntu fails to install from netboot" [Undecided,New] https://launchpad.net/bugs/204235
<stgraber> davmor2: perfect, thanks
<evand> calc: sorry to be so late in reply, but it doesn't use virtualization and suspend should work but hibernate does not
<saivann> Is there a developer that can take a look at bug 192845 ? A patch is attached so this bug might be easy to fix before Hardy and avoid regressions
<ubotu> Launchpad bug 192845 in udev "[Hardy] Intel 3945ABG Long boot delays while "Loading hardware drivers"" [Medium,Triaged] https://launchpad.net/bugs/192845
<Hobbsee> Keybuk: would be the one
<Keybuk> the patch is almost certainly invalid
<Keybuk> (without looking at it)
<Keybuk> yes
<Keybuk> the patch is invalid
<Keybuk> though it's a nice hack ... :)
<saivann> Heybuk: invalid? Does it gives some hint on what caused the regression?
<saivann> Heybuk: No matter, I just seen your comment on bug, thanks for your work :)
<Adri2000> slangasek: can you please push wxwidgets2.8 (universe) through the queue, it fixes a postinst-failing bug (bug #203526)
<ubotu> Launchpad bug 203526 in wxwidgets2.8 "python-wxgtk2.8 uninstallable due to post-installation script error" [Medium,In progress] https://launchpad.net/bugs/203526
<calc> slangasek: yes suspending while booted off the cd
<calc> slangasek: works fine on i386, on amd64 kernel it gives those weird errors
<cody-somerville> Is it possible for me to get rid of openoffice.org or is Xubuntu forced to ship with it because of the lang-pack dependencies?
<ogra_cmpc> cody-somerville, its only lang-support that should pull in oo.o stuff
<ogra_cmpc> use the lang-pack packages
<cody-somerville> Okay
<cody-somerville> Would someone be kind enough to merge ~xubuntu-devel/ubuntu-seeds/xubuntu.hardy/, regenerate xubuntu-meta, and upload for me? :)
<superm1> cody-somerville, I wasn't aware those language packs actually translated xfce anyhow.  do they ?
<cody-somerville> Probably not anymore
<superm1> in the mythbuntu alternate disk at least, the part of d-i that picks languages has been taken out
<cjwatson> cody-somerville: merged; ship seed changes don't need a xubuntu-meta upload
<cody-somerville> cjwatson, okay, thanks
<cody-somerville> Also, could someone upload the xubuntu-docs for me?
<cody-somerville> The bzr branch is located at http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/xubuntu-hardy/
<sistpoty|work> pitti | Mithrandir: can you please give back haskell-regex-base on sparc? thanks!
<pitti> sistpoty|work: done
<sistpoty|work> :)
<sistpoty|work> pitti: will soyuz automatically retry builds that are in dep-wait?
<pitti> sistpoty|work: yes
<cjwatson> ogra_cmpc: have you encountered bug 203844 during testing?
<ubotu> Launchpad bug 203844 in moodle "Hangs when installed in chroot in hardy" [High,New] https://launchpad.net/bugs/203844
<sistpoty|work> pitti: excellent, then I hope that I won't need to bother you with too many give backs to complete the haskell transition on sparc :)
<pitti> sistpoty|work: don't worry; a give-back is that much --><--- effort for me
<sistpoty|work> heh :)
<ogra_cmpc> cjwatson, intrestingly not, the package also didnt change since gutsy afaik
<pitti> sistpoty|work: as long as your list does not use commas, giving back one or 500 packages is the same amount of work
<ogra_cmpc> but i never tried it in a chroot though (even though i dont see why that should matter here)
 * pitti pats his script to drive the LP UI
<sistpoty|work> :)
<Adri2000> pitti or cjwatson: can you please approve wxwidgets2.8 currently in the queue? (see above, slangasek doesn't seem to be here)
<pitti> Adri2000: will do soon (I currently have ssh hanging again)
<cjwatson> I'll do it
<cjwatson> ogra_cmpc: I'll push it to post-beta
<ogra_cmpc> mvo reported it just yesterday, we talked about it alredy
<ogra_cmpc> crap
<cjwatson> seems to be a fix in Debian
<ogra_cmpc> and io know why i didnt see it
<ogra_cmpc> my ucf on the server is outdated gah
<cjwatson> or maybe not
<cjwatson> does that mean it *should* be beta-critical?
<ogra_cmpc> moodle ?
<ogra_cmpc> nah
<ogra_cmpc> iots just the order that needs to change as i understand it
<cjwatson> ah, it's only shipped not installed by default
<ogra_cmpc> right
<ogra_cmpc> there are no server bits that are installed by default in edubuntu anymore
<mvo> ogra_cmpc: anything new on moodle?
<ogra_cmpc> mvo, just discussing
<mvo> ogra_cmpc: I think the fix is just moving the dh_stop further down, but I only glanced at it
<ogra_cmpc> yeah, thats how i understood the linked report
<ogra_cmpc> just change the ordering
<Artimus> libpam-foreground should probably be pulled in as a dependency on ubuntu systems.  Otherwise, errors show up in auth.log when using sudo (https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/195880).  I was directed here to ask what package I should recommend depend on libpam-foreground
<ubotu> Launchpad bug 195880 in ubuntu-meta "ubuntu-standard doesn't depend on libpam-foreground" [Undecided,New]
<cjwatson> revno: 1138
<cjwatson> committer: Martin Pitt <martin.pitt@ubuntu.com>
<cjwatson> branch nick: ubuntu.hardy
<cjwatson> timestamp: Thu 2007-11-22 17:07:54 +0000
<cjwatson> message:
<cjwatson>   remove libpam-foreground; packages which need it need to depend on it explicitly
<Artimus> sudo is what causes the error itself...
<cjwatson> I'll reassign the bug to the proper place
<Artimus> Assigning it as under sudo?  Or another package?
<cjwatson> see the bug
<cjwatson> /etc/pam.d/sudo doesn't refer to pam_foreground; there is no reason why it should have the responsibility of delivering the dependency/recommendation
<Artimus> cjwatson: Right.  Looks good.
<jdong> speaking of bzr, do we plan on importing bzr 1.3 into Hardy? It seems imminent for release and the guys produce quality releases.
<ScottK2> We were uploading new tool chain bits up to the beta freeze, so I don't see why that would be a problem.
<jdong> :) cool
<jdong> btw, how's the beta going?
<cjwatson> largely OK except for screwed DVDs
<cjwatson> we'll probably have to just not ship those
<jdong> meh that's probably not a big problem for the beta phase
<mario_limonciell> cjwatson, what happened with the dvds?  oversized or failling alltogether?
<cjwatson> mario_limonciell: bizarre gfxboot explosion
<cjwatson> I clearly did something very bad in a previous life, because I'm sitting tracing through its memory allocator at the moment
<mario_limonciell> ooh yuck.  don't they use the same gfxboot code though?
<cjwatson> they do, but it depends on exact layout of stuff in memory, which depends on other things in the /isolinux directory on the image
<mario_limonciell> whew, didn't realize things were that hardcoded..
<mario_limonciell> but then again I do remember you poking around at some of the code at UDS
<mario_limonciell> and it sure didn't look pretty
<jdong> I like the old SYSLINUX put-up-a-splash-image days...
<cjwatson> mario_limonciell: not hardcoding as such - I think it's a bug in its memory allocator which crashes on certain sizes of allocations, or something like that
<cjwatson> the debug output shows a chunk with negative size
<cjwatson> which I think is making it oops
<pitti> tkamppeter: hi
<pitti> tkamppeter: thanks for the cups patches
<pitti> tkamppeter: BTW, I recently committed all our remaining patches to Debian, except the ones we just need for daper->hardy upgrade (which don't fit to Debian)
<pitti> tkamppeter: so, in the future we should try to avoid adding a patch to the ubuntu branch only
<pitti> tkamppeter: (you did that correctly, I just want to point it out explicitly)
<pitti> so after hardy we can just sync cupsys
<tkamppeter> pitti, on today's patch I need to do a small correction, so wait a little with the upload. I will inform you.
<seb128> pitti, tkamppeter: do we need to default printer menu item in the preferences menu? isn't that something that system-config-printer can also do?
<pitti> seb128: hm, s-c-p usually needs 'lpadmin' privileges; I'm not 100% sure, though, I currently don't have a local printer
<seb128> ok
 * pitti tries, I forged a printer now
<seb128> because I was testing on the CD and having a list with only pdf is not really useful ;-)
<tkamppeter> seb128, the default printer menu item in the preferences menu is for every user being able to set his personal default printer. s-c-p can set a system default printer (for all users without personal default printer), but it needs lpadmin privileges.
<sistpoty|work> pitti: please give back haskell-regex-posix on sparc
<pitti> seb128: I tried it, doesn't work; it asks you for the password
<pitti> seb128: since it wants to set the global default, not the per-user one
<seb128> ok
<tkamppeter> pitti, I have committed the corrected patch to the cupsys SVN (both Debian and Ubuntu) now, now I am doing a build test
<keescook> doko: I've gotten the PIE patches working for attach and core, but not "run".  should I upload that, since it's at least progress?
<keescook> doko: (context is "gdb")
<keescook> doko: also, I enabled the testsuite.  was it intentionally disabled?  it looked like a typo.
<doko> not intentionally. I'd upload for hardy
<tkamppeter> pitti, I have tested the new cupsys patch now. Can you upload the current SVN snapshot into Ubuntu? Thanks.
<pitti> tkamppeter: we are still in freeze
<tkamppeter> pitti, can you then upload cupsys after the beta release? The patch is not so urgent.
<sistpoty|work> doko: could it be that the gutsy-update of libc6 (2.6.1-1ubuntu10) has somehow broken lbreakout2? (bug #196334)?
<ubotu> Launchpad bug 196334 in lbreakout2 "segmentation fault - lbreakout2" [Medium,Incomplete] https://launchpad.net/bugs/196334
<pitti> tkamppeter: yes
<slangasek> tjaalton: hi, what kind of "progress" is bug #189343 "in" currently? :)
<ubotu> Launchpad bug 189343 in linux-restricted-modules-2.6.24 "DRI doesn't work with fglrx 8.01" [Critical,In progress] https://launchpad.net/bugs/189343
<tjaalton> slangasek: good point, I think it can be closed since 8.3 is in. at least it fixed the issue for the reporter
<slangasek> ok, I wasn't sure how to check that 8.3 was in - thanks
<tjaalton> 1:7.1.0-8-3+2.6.24.11-12.31
<tjaalton> see, it's clearly fixed :)
<cjwatson> OBVIOUSLY
<tjaalton> :P
<slangasek> oh, sorry, I didn't know that "8.3" was supposed to be read as a regexp ;P
<slytherin> Can any of the buildd admins give back nautilus-share?
<tjaalton> AMD can't decide whether to use . or - :)
<slangasek> heh
<Riddell> tkamppeter: where are the specs for the common print dialogue?
<slytherin> pitti: Can you please give back nautilus-share and mysql-gui-tools?
<cjwatson> Adri2000: done
<wasabi> this is odd. I have a DVD which I cannot seem to read on Linux
<wasabi> plain ol' data dvd.
<Adri2000> cjwatson: thanks
<wasabi> Looks like it's attempting to access beyond the end of waht it thinkgs is the device.
<wasabi> Wonder if this is a bug in the iso9660 fs driver or something wacky about this DVD
<wasabi> or just a screwed up device driver.
<wasabi> Yeah... weird. blockdev shows it as only being 1.1 GB. Disk is much longer than that.
<wasabi> the mounted FS says it's 3.8G
<slangasek> superm1: so has mythbuntu alt amd64 gotten any testing?
<mario_limonciell> Daviey, ^
<slytherin> cjwatson: Are you one of the buildd admins?
<slytherin> wasabi: did you burn the DVD in XP?
<wasabi> It's not mine. Came from MS though. It's a MSDN DVD.
<wasabi> I'm thinking it might be the two SATA DVD drives reading the disk length wrong.
<wasabi> "or something"
<cjwatson> slytherin: no - ~launchpad-buildd-admins
<wasabi> It's been pressed. No idea where the original FS was built. Also I don't know how disk length stuff works with a DVD>
<wasabi> I'd assume it is some disk metadata at the beginning which only the drive cares about
<slytherin> wasabi: or may be there is problem with UDF driver in Ubuntu
<wasabi> The UDF driver would not lie about block device size. Only about it once it's been mounted. No?
<wasabi> Seems to be iso9660 anyways.
<slytherin> cjwatson: thanks. But it is hard to find who is awake at this time
<Daviey> slangasek: AFAIK amd64 alt has recieved _no_ testing
<slangasek> Daviey: will it, in time for us to be able to confidently include mythbuntu in the beta today?
<slangasek> Daviey: doing your own beta later is always still an option if you need more time...
<Daviey> hmm
<_MMA_> Daviey: Well, I as well as TheMuso did 64bit installs of Ubuntu Studio Alt. Pretty much the same thing as the Ubuntu disk. Mostly.
<Daviey> I don't have an amd64 dev machine..  i can only test it in vm :/
<Daviey> one mo.
<slangasek> _MMA_: that's not the same thing.  I'm not willing to announce, and take up archive space, for completely untested images that may be broken for unforeseen reasons
<slangasek> each image needs to get tested before it goes out in this mail...
<Daviey> slangasek: yep, just trying to pull someone to test it physically
<Daviey> If anybody else in here wants to help, that would be MUCH appreciated!
<tjaalton> pitti: does bug 202848 seem valid? Jockey writes "Defaultdepth" which is wrong
<ubotu> Launchpad bug 202848 in linux-restricted-modules-2.6.24 "GeForce FX5200 drivers xorg bug" [Undecided,New] https://launchpad.net/bugs/202848
<_MMA_> slangasek: I never suggested otherwise. :)
<tjaalton> should be DefaultDepth
<tkamppeter> Riddell, the specs for the Common Printing Dialog are in the works by Peter Sikking and his current student. They will be ready end of May when we will have the coding kick-off for the dialog end of May (directly before LinuxTag) in Berlin.
<tkamppeter> If we are lucky, we will have two GSoC students working on the implementation of the dialog. The coding session of the GSoC begins end of May. See also https://www.linux-foundation.org/en/OpenPrinting and https://www.linux-foundation.org/en/Google_Summer_of_Code. I am GSoC admin for the Linux Foundation.
<doko> cjwatson: are there known problems with non-working keyboard at the boot screen (new MacBook Pro)?
<stgraber> doko: is that with DVD ?
<jdong> doko: macbooks don't always bring up legacy keyboard support
<jdong> doko: I have to use rEFIt to reliably have keyboard on bootloader
<slytherin> doko: If you are not too busy, can you please give back nautilus-share and mysql-gui-tools?
<cjwatson> doko: if it's DVD, that's known
<cjwatson> doko: if it's not, could be USB issues
<cjwatson> holding down shift at boot might help
<mario_limonciell> cjwatson, that's the only known issue on the dvd right?  We don't use gfxboot for our factory install, so it wouldn't affect us then.
<mdz> pitti: I had some fsck related issues on boot yesterday; would you like to talk about them?
<cjwatson> mario_limonciell: we can't tell because we can't boot it ;-)
<mario_limonciell> hehe
<mario_limonciell> cjwatson, well you can probably boot a usb stick with grub (or similar) installed, and call upon the initrd and vmlinuz files in casper/, I suppose, but fixing gfxboot is more of priority
<cjwatson> I've found the gfxboot problem, so we shouldn't need workarounds
<cjwatson> too late for beta though
<mario_limonciell> going to re-generate one shortly after beta then at least?
<doko> stgraber: yes, dvd
<nxvl> can someone explain me how the XubuntuY.Z versions work
<stgraber> doko: ok, so it's a know gfxboot bug
<nxvl> y know that on debian a package versioned by -X is versiones as -X.Y if it is a NM upload
<stgraber> known
<nxvl> but on ubuntu why to we use ubuntuX.Y?
<jdong> nxvl: X.Y is used for security and stable release updates, where we need something between X and X+1
<slangasek> cody-somerville: I see quite a few outstanding tests on the xubuntu images, according to http://iso.qa.ubuntu.com/qatracker/build/xubuntu/all; do you have anyone available to help round out this testing?
<nxvl> jdong: that's what i thougt, thanks for it!
<doko> slangasek: given back
<slytherin> nxvl: XubuntuY specifies that it is a X version from Debian with added changes made in Ubuntu
<slytherin> doko: what that for me?
<cjwatson> mario_limonciell: right, if I get it sorted before going on holiday
<doko> ahh, yes
<slytherin> doko: Thanks. :-)
<slangasek> doko: I'm sure I'm also grateful for it being given back, whatever it is ;)
<cjwatson> (I know where the problem is - just a matter of finding an efficient fix)
<nxvl> slytherin: yes, that i know
<nxvl> slytherin: i wanted to know why does ubuntuX.Y exist
<slytherin> nxvl: ok
<thom> they're updates after the distribution has been released
<thom> ie, security or critical fixes
<cody-somerville> slangasek, I'll see about trying to round some people up
<nxvl> thom: thnx
<slangasek> cody-somerville: cheers
<pitti> slytherin: given-back
<pitti> mdz: still there? sure
<slytherin> pitti: doko did that already. And the builds have succeeded. :-)
<pitti> tjaalton: hm, that's done by guidance-backends
<pitti> tjaalton: so, entirely possible that it is a bug, but so far it didn't matter
<pitti> xorg.conf has been pretty much case insensitive so far?
<tjaalton> pitti: right, maybe some drivers are more picky about it, intel at least works with both cases
<pitti> tjaalton: it's not that trivial to fix in guidance-backends unfortunately, I already tried it a while ago
<pitti> but if it's actively  breaking stuff instead of just being cosmetical, we should do something about it
<ScottK2> tjaalton: I've subscribed to that bug.  If there are pointers towards guidance-backends that I can do something with, I'll take a shot at it.
<ScottK2> pitti: I've got some more Guidance work planned after beta, so if we can narrow it down, maybe I can hack something out that'll work.
<tjaalton> cool, maybe I'll ask for the log with the broken setting, that should confirm it
<ScottK2> I know exactly where to patch to look for the downcased letter when guidance reads xorg.conf in and change it if that would be useful.
<sistpoty> doko: you know some bits about wxwidgets, right? Are there any caveats allowing an update of wxformbuilder (bug #203781)?
<ubotu> Launchpad bug 203781 in wxformbuilder "new upstream release 3.0.56 (RC8)" [Undecided,New] https://launchpad.net/bugs/203781
<doko> sistpoty: I didn't follow upstream too close ...
<sistpoty> doko: ah, ok... whom could I asked then?
<sistpoty> doko: ok, package is from bug reporter, so nevermind ;()
<keescook> doko: is there an up-to-date "here's how to make a python package from scratch" document anywhere?  From my perspective things keep changing (python-central, -support, -foo) -- I can't keep up.  :)
<doko> keescook: ok, I should write such a doc ...
<keescook> doko: I'd really like that.  :)  even a "use pkg $BLAH as an example" in a wiki page would rock.  :)
<pitti> bah, seems that hardy started to make some pling and plong noises on suspend/resume. WTH???
<jdstrand> keescook: I don't know how up to date it is, but I've been using http://wiki.debian.org/DebianPython/NewPolicy
<pitti> is that pulseaudio?
<jdstrand> keescook: noone has complained with auth-client-config or ufw :)
<jdstrand> keescook: and by up to date, I mean relevant
<jdstrand> doko: is http://wiki.debian.org/DebianPython/NewPolicy
<jdstrand> what we should be working off of?
<keescook> jdstrand: cool, yeah.  I just wanted to get some kind of officially blessed cookbook.
<doko> jdstrand: yes, this still looks fine, just add that we prefer python-central for new ubuntu packaging, because it handles upgrades better and lets dpkg/apt doing the file conflict/replacing stuff
<jdstrand> doko: cool, thanks!
<slangasek> pitti: gnome-power-manager, fix is in the queue
<slangasek> er, or maybe it's in the queue; I talked to ted about it, not sure if it's been sponsored just yet
<ScottK2> doko: Speaking of Python - I'm not sure pushing python-xml removal late in the cycle is turning out to be such a great idea.  I've seen more than one package inadvertently broken.
<doko> ScottK: unfortunate, but ... which packages are broken?
<ScottK2> doko: The most recent was wxwidgets2.8.  The guy that broke it was looking after it, but I don't know if he's fixed it yet.
<ScottK2> I'm more worried about breaking things and then not finding out until after release.
<ScottK2> That and most of the remaining ones that I've looked at need code copied into them.
<ScottK2> doko: Did you consider dropping python-xml to suggests for python-reportlab solve the transition or should it be removed entirely?
<doko> ScottK: can be completely removed for reportlab
<ScottK2> doko: OK.  I can do that one.
<pitti> slangasek: g-p-m> what fix?
<slangasek> pitti: the pling/plong noises on suspend/resume
<pitti> aah
<slangasek> pitti: it's not in unapproved though, so someone needs to sponsor it for ted still
<pitti> great that it's not considered a bling feature *phew*
<Tm_T> hi kids
<ion_> Hi mom.
<Daviey> slangasek: Mythbuntu beta amd64 alt seems fine
<slangasek> Daviey: lovely, thanks :)
<Daviey> have done, hit the wrong channel first :(
<cody-somerville> Is there a rebuild of the cds in progress?
<slangasek> cody-somerville: no, is there some reason you would expect rebuilds?
<cody-somerville> I thought we were planning to release the beta this evening
<slangasek> yes
<infinity> cody-somerville: Which is precisely where there are no rebuilds. :)
<cody-somerville> Well, could you please rebuild Xubuntu alternative for i386?
<cody-somerville> It is over sized and I committed the fix earlier today
<slangasek> it can be rebuilt, but it won't be included in the beta
<slangasek> that fix should've been committed weeks ago, when I was trying to get someone to pay attention to it for alpha6
<cody-somerville> Unfortunately Xubuntu has been going through a leadership crisis
<slangasek> if the Xubuntu developers want to release Xubuntu beta alternative CDs after the fact, that's fine with me and I'm happy to assist, but I can't hold back the beta for all the other flavors
<cody-somerville> Can you start the build and we can just slip in the new iso when it is ready?
<slangasek> not at this precise moment, my hands are busy with beta publishing
<mjg59> slangasek: Were you planning on doing an acpi-support upload at some point?
<slangasek> mjg59: to drop the suspend/resume code?
<mjg59> slangasek: Because the toshiba_acpi.modprobe file that someone removed needs to go back, or Toshibas are broken
<slangasek> oh
<infinity> mjg59: Beta is already on its way out...
<mjg59> infinity: Then it'll have to be post-beta
<slangasek> mjg59: is there a bug report about this?
<mjg59> slangasek: I doubt it, I just noticed it in the changelog
<slangasek> ok - if I'm to upload it I'll need to understand why the change was wrong, so I can properly document it against further oopsery
<mjg59> I pointed out that this wasn't a good idea on ubuntu-devel, but getting anyone to listen to me nowadays is effort :)
<slangasek> so if you're around in a few hours we can talk about it, or if you file a bug and milestone it I can take it from there
<mjg59> Yeah, I'll do that
<slangasek> hrm, I don't recall seeing anything about this on ubuntu-devel recently :/
<mjg59> Might have been devel-discuss
<ion_> slangasek: You have a 108x88 DPI monitor?
<slangasek> ion_: 1400x1050, 15", so sayeth xdpyinfo
<ion_> slangasek: 108x88 DPI would mean non-square pixels.
<slangasek> ion_: er, sorry, 1280x800, 15"
<infinity> Most laptop screens are non-square, ish.
<slangasek> yes, I'm aware that implies non-squareness; you're welcome to deduce xdpyinfo's math error if you like :)
<ion_> slangasek: Try measuring the display's size and adding a DisplaySize setting to xorg.conf and see if it the X and Y DPIs are still different.
<infinity> ion_: Mine is 122x127 DPI.
<infinity> Although, 108x88 seems a bit more extreme.
<mjg59> slangasek: 199888
<mjg59> blueyed: Please don't delete files from packages without trying to find out why they were added in the first place. In this case, you broke hotkeys for all Toshiba owners.
<mjg59> blueyed: Also, there was no point adding any suspend/resume related code to acpi-support in hardy. It's entirely unused.
<mjg59> blueyed: In summary, please try to work out what a package is meant to do before uploading new versions :)
<blueyed> mjg59: I know, it was a bunch of collected patches/supposed fixes.
<mjg59> blueyed: Yes, but it, well, wasn't
<mjg59> It was a bunch of fixes and breakage
<mjg59> slangasek: I can't milestone any more
<slangasek> mjg59: ok, done
<mjg59> slangasek: Argh. You'll need to delete events/lenovo-eject as well.
<mjg59> It's a dock eject button, not a CD eject button
<slangasek> mjg59: is there something that makes it work for that?
<mjg59> The firmware ought to basically handle it
<mjg59> But I don't have a dock to test
<slangasek> hmm
<mjg59> Using it as a CD eject button is definitely wrong, though
<slangasek> then isn't it also a problem that I'm able to see an acpi event for it at all?
<keescook> mjg59: say, my crazy disasming friend of mine is coming over shortly, got a tarball of the usplash+libdisasm goo handy? I don't want to reinvent the wheel...  :)
<mjg59> keescook: I've been trying to think through the possible ways of doing it
<mjg59> keescook: I'm beginning to think it's not practical without an nx machine
<mjg59> Oh, no, wait
<blueyed> mjg59: toshiba hotkeys problem because of bug 180678 ?
<ubotu> Launchpad bug 180678 in acpi-support "dmesg: toshiba_acpi: Unknown parameter `hotkeys_over_acpi'" [Medium,Fix released] https://launchpad.net/bugs/180678
<keescook> nx in this context is?
<mjg59> blueyed: Yes
<mjg59> blueyed: Don't delete that file. It's there for a reason.
<mjg59> blueyed: And #194609 even has someone commenting that the proposed patch is wrong!
<blueyed> mjg59: but it said "toshiba_acpi: Unknown parameter `hotkeys_over_acpi'"?!
<mjg59> blueyed: Yes, but that was a *kernel* bug
<mjg59> Not an acpi-support bug
<mjg59> The kernel's been fixed
<mjg59> slangasek: #194609 could do with milestoning as well
<blueyed> mjg59: oh, I see. I'll fix it
<slangasek> how's about I just talk someone into sticking a milestoner bit back on you... :)
<mjg59> slangasek: I think that's it for now :)
<mjg59> keescook: Ok, so here's roughly how I think it should work:
<mjg59> keescook: Map the BIOS
<mjg59> keescook: Register a SIGILL handler
<mjg59> keescook: Disassemble the instruction at the IP. Place an illegal instruction immediately after it
<pwnguin> is fixing that why my power button works again?
<mjg59> keescook: If the instruction is a jump or a loop, also place an illegal instruction at the destination
<pwnguin> (toshiba laptop)
<mjg59> keescook: If it's a call, place an illegal instruction at the destination
<mjg59> pwnguin: Unlikely
<mjg59> keescook: Enter vm86 mode
<slangasek> mjg59: but the thinkpad one really should go away, right?
<mjg59> slangasek: Yeah, I think that's ok
<slangasek> (I mean, as soon as I killed it locally, my hotkeys started working again, so)
<mjg59> keescook: In the sigill handler, invalidate the mapping and repeat
<mjg59> keescook: Oh! And print the instruction and registers, obviously :)
<keescook> mjg59: heh.  yeah, that part.  :)
<keescook> that mapping/unmapping is not currently happening?
<mjg59> keescook: None of this is currently happening
<mjg59> I was trying to find some way of avoiding some of this awkwardness, but I think this is the cleanest way
<keescook> mjg59: right, -- i'm just trying to understand how vm86 works -- I haven't spent too much looking at it.
<cjwatson> keescook: I found the gfxboot bug!
<keescook> cjwatson: ooooh! what was it??
<cjwatson> (sorry, not to distract you)
<mjg59> keescook: vm86 is given a structure with original register state, and then executes stuff
<slangasek> yes, let's not distract kees from his bios sigill handling with discussions of forth code... :-)
 * keescook cries
<mjg59> keescook: So, in theory, when you hit the sigill handler, the registers are now what they would have been after you executed that instruction
<cjwatson> keescook: files read by gfxboot aren't zero-terminated (it gives you back a pointer to the middle of a cpio archive in memory), but we were using strstr on them and strstr expects zero-termination
<pwnguin> heh
<mjg59> asac: Is there still no way to add https exceptions in epiphany?
<cjwatson> and then we plonked a zero byte after the end of the string which happened to sit on top of the metadata for the next malloc chunk
<keescook> mjg59: right, so, the BIOS mapping part -- do you mean duplicate the bios memory elsewhere so we can modify to with the illegal intrs?
<mjg59> keescook: mmap it from /dev/mem with PROT_FIXED
<keescook> cjwatson: oooh snap.  nice catch.  how much longer did you spend on that madness?
<mjg59> keescook: That's done already
<mjg59> keescook: The issue is that you need to modify that mapping to include the illegal instructions
<mjg59> keescook: So you need to munmap() it and then mmap() it again afterwards to get the original contents back
<keescook> mjg59: err.. and it'll let me _change_ the memory?  right, this is where I'm a bit confused
<mjg59> keescook: It's the difference between physical and virtual address space
<cjwatson> keescook: about two or three hours; I discovered a gfxboot primitive that dumps out all the malloc metadata, and discovered that it printed "oops: <blah>" when stuff went wrong, so given that I was able to binary-chop and figure out what was corrupting memory
<keescook> ah, it'll let me mod it, but it's only for my mapping
<mjg59> keescook: You're mmapping 0xc0000 of physical address space into 0xc0000 of your virtual address space
<keescook> cjwatson: nice -- did you submit that upstream?
<mjg59> And yeah, you can make it COW
<cjwatson> keescook: not relevant
<keescook> cjwatson: ah, dang
<cjwatson> keescook: the code that was broken was entirely written by me
<keescook> cjwatson: erf. heh.
<sistpoty> mjg59: (not to interrupt you), do you have any opinion if we want eeepc-acpi-scripts as FFe (bug 195724)
<keescook> mjg59: this'll be ... not fast.  ;)
<ubotu> Launchpad bug 195724 in ubuntu "[FFe] Please sync eeepc-acpi-scripts 1.0 from debian unstable" [Undecided,Incomplete] https://launchpad.net/bugs/195724
<mjg59> sistpoty: Erm. No clue.
<sistpoty> mjg59: ok, thanks
<mjg59> I'd need to take a look at the package first
<mjg59> keescook: Yeah, but nor is x86emu, so...
<mjg59> keescook: The trick is then to try to get the debug output to look like the x86emu debug output
<keescook> mjg59: you had said something the other day about bios memory and how it wasn't going to work?
<sistpoty> mjg59: if you could do so, and comment on the bug, that would be great :)
<mjg59> keescook: Yeah, that was based on my original idea
<mjg59> But I think the current one avoids that
<keescook> mjg59: ah, okay.  yeah, this is just single-stepping.  should work fine.  ;)
<keescook> why does it need to look like x86emu debug output?
<mjg59> keescook: So we can diff them
<mjg59> And figure out where it's going wrong
<keescook> ah! heh.
<keescook> so, remind me, we're just trying to do a simple POST, right?
<keescook> or is it deeper?  I'm realizing I need to actually get a "reproducer" of the calls that are failing now that I've got my hands on hardware
<keescook> better yet -- what do I need to tweak to get the x86emu debug output?
<mjg59> keescook: We want to know why usplash dies on nvidia with x86emu, but not with vm86
<mjg59> Hang on...
<mjg59> keescook: http://www.codon.org.uk/~mjg59/tmp/x86_debug/
<keescook> mjg59: eexcellent.  so that for libx86 -- how do I run usplash with x86emu?
<mjg59> I believe it's nobbled so it always runs with x86emu
<mjg59> keescook: Oh, and remember that this all has to be on a 32-bit kernel
<mjg59> sistpoty: No, that package shouldn't exist
<sistpoty> mjg59: ok, thanks, then I'll reject it
<mjg59> sistpoty: acpi-support should already do all of it
<sistpoty> mjg59: thanks again for the info :)
<keescook> mjg59: okay, I think I know where my confusion lies.  vm86 is a syscall.  x86emu is a library, libx86 is a library.  usplash is linked against libx86.  where is x86emu, and who is currently using vm86 calls?  :P
<mjg59> libx86 ( by default) uses x86emu on x86_64 and vm86 on x86
<mjg59> The magic code needs to be added to lrmi.c in libx86
<mjg59> lrmi is the layer that does the vm86 handling
<keescook> ah, gotcha.  (currently reading http://www.codon.org.uk/~mjg59/libx86/)
<keescook> okay, so, then why do I want to run a 32bit kernel?  just to get the "it works" debug log?
<mjg59> Yes
<keescook> okay.  same page achieved.  :)
<mjg59> vm86 doesn't work on 64-bit kernels
<keescook> right -- that part i got.  you didn't mean "all work will be done on 32bit kernels"
<mjg59> Oh, right
<mjg59> Once we've got a vm86 log, the bugs can be fixed on 64-bit
<keescook> you meant, get a working dump on 32bit, then attack 64
<mjg59> Yeah
<keescook> groovy
<mjg59> But x86emu runs on 32-bit as well
<mjg59> And fails in the same way
<keescook> and to force x86emu when running 32bit, I'll want the libx86 package from your tmp dir you just sent me?
<mjg59> Yup
<mjg59> Which also does the debug output
 * keescook claps stupidly
<emgent> heya people
<keescook> hi emgent
<emgent> keescook: about pentest team, next Security meeting (26th) we can start the project.
<emgent> :)
<keescook> cool
<emgent> report-tool it's ready, i will update bzr branch to it
#ubuntu-devel 2008-03-21
<keescook> mjg59: looks like the code is the same on gutsy -- I assume this will be meaningful under gutsy still?  (person with nvidia is running gutsy...)
<emgent> keescook: https://code.edge.launchpad.net/~emgent/+junk/security-tools
<mjg59> keescook: Yup
<keescook> mjg59: are the "outside process range" changes in 0.99-1.2ubuntu2 needed for this?  (i.e. should I migrate your debug changes on top of that before attempting my debugging?)
<mjg59> keescook: Nope
<mjg59> Something similar would be useful at some point, but a misery to get right
<blueyed> mjg59: fix attached to #199888, can you sponsor it?
<keescook> mjg59: in your blog you talked about discovering missing opcodes.  was that related to this?
<mjg59> blueyed: Afraid not
<mjg59> keescook: That was thinking about emulating all the branch instructions, but I figured out that that was unnecessary
<blueyed> mjg59: ok, subscribed u-m-s. Thanks for notifying and explaining it to me.
<mjg59> blueyed: No problem
<slangasek> blueyed: assign it to me, please; I'm happy to follow through on that
<slangasek> I still want the isAnyWirelessPoweredOn() function fixed too :)
<keescook> mjg59: where is the upstream x86emu in X.org?  I just want to make double-sure everything is up to date...
<keescook> mjg59: nm, I knew if I asked you, I'd find it.  ;)  xorg/xserver/hw/xfree86/x86emu whee
<keescook> mjg59: I'm going to try a fork-lift upgrade of x86emu first -- several opcodes were implemented and a few fixes added
* slangasek changed the topic of #ubuntu-devel to: Archive: Beta freeze | 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 | glibc was broken, now fixed: https://launchpad.net/bugs/201
<slangasek> \o/
* elmo changed the topic of #ubuntu-devel to: Archive: Beta freeze | 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
<bddebian>  /0\
<jdong> *gasp*
<j1mc> \0/
<bddebian> heh
<Fujitsu> Beta freeze still in effect, but beta released?
<slangasek> yes
<slangasek> elmo: care to twiddle the archive status, since I still don't have the bit for it? :)
<elmo> slangasek: done
<slangasek> thanks
* slangasek 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
<mthaddon> if anyone's listening, just wanted to say that I just upgraded to hardy, and it was completely flawless - no issues, and very smooth. Nice!
<slangasek> hurray :)
<mneptok> mthaddon: next time we'll make sure to overwrite your smug sense of self-satisfaction >;)
<sabdfl> well done all
<mthaddon> mneptok, please do - it scared me how smug I felt
<mneptok> mthaddon: i upgraded last night. it went very well. so much so, i decided that i drop acid after work any more. just in case.
<mneptok> s/i/i\ won't/
<mthaddon> :)
<mneptok> but yeah, it was a nice upgrade. some network issues at the office, but the home connection sorted those without intervention
<mneptok> sabdfl: how're the slopes?
<sabdfl> mneptok: full of fast-moving trees :-) am now up in BC
<mneptok> sabdfl: BC is noted for its angry ent population.
<mneptok> (like jkakar)
<sabdfl> :-)
<thom> sabdfl: boarding in canada?
<sabdfl> mmmmuuuuussstttt hhaaaaavvveeeee dddddiiiinnnneeeerrrr ;-)
<sabdfl> thom: indeed!
<thom> nice!
<mneptok> sabdfl: when you say it like that, you have to add "BRAAAAAAAAAAAAAAAAAAAAAAAAAAIIIIIIIIIINS!!!!" at the end
<emgent> keescook: ping
<sabdfl> only when Ng is around
<sabdfl> cheers all, and conrats again
<emgent> I found a security issue on launchpad
<sabdfl> errr
<sabdfl> congrats
<mneptok> enjoy the rest of the downtime
<j1mc> thanks, sabdfl
<emgent> hi sabdfl :)
<sabdfl> emgent: might be worth taking to #launchpad
<sabdfl> night
<emgent> sabdfl: I'm thinking to open security bug on LP
<mneptok> emgent: i would recommend to talk to kees on a more secure channel about it.
<emgent> mneptok: sure np, i know method to work. :)
<mneptok> emgent: public IRC is probablt not the best approach vector, unless kees ahs asked you to handle things this way.
<emgent> mneptok: i'm just ping him for see if he is up
<emgent> canonical dont search new security personal for auditing ?
<mneptok> emgent: ah, capisco
<emgent> :)
<pwnguin> mthaddon: you upgraded, from dapper or gutsy?
<mthaddon> pwnguin, gutsy
<pwnguin> ah, that's not nearly as impressive ;)
<pwnguin> or daring
<mneptok> pwnguin: i upgraded from PDP-OS
<compbrain> Anyone doing kernel flavor builds that gocould lend me a hand for a minute?
<compbrain> I'm having issues with the abi build step
<Hobbsee> slangasek: one of the users doing a dist-upgrade with adept got http://pastebin.com/m1018a09c.  The dist upgrade is effectively the same, at http://paste.ubuntu-nl.org/60389/ (gutsy --> hardy upgrade).  Has anyone else reproduced that?
<slangasek> Hobbsee: I don't believe so; none of mvo's upgrade tests indicated any upgrade problems from gutsy, and I haven't heard anyone else reporting this
<slangasek>   libc6-i686: PreDepends: libc6 (= 2.7-5ubuntu2) but 2.7-9ubuntu2 is installed
<slangasek> Hobbsee: that's very suspect; the user seems to have a libc6-i686 installed that's not from either gutsy or hardy
<Hobbsee> slangasek: oh, it's a very old hardy version.  nvm.
<Hobbsee> strange.
<Fujitsu> slangasek: Are upgrade tests run by you guys for universe too? If not, how do we run them?
<slangasek> Fujitsu: I'm not sure whether mvo's upgrade tests include universe, that's a question to ask him
<Fujitsu> slangasek: Thanks, I'll poke him when he appears.
<lool> pitti: I consider adding a -include langpack.mk in Debian's avahi; ok for you?
<lool> Hmm it's probably a Feiertag in Germany
<siretart> lool: it is.
<lool> Hey siretart
 * siretart hugs lool 
 * lool crushes under the pressure
<siretart> lol
 * siretart sighs at gstreamer-ffmpeg using the removed imgres feature of ffmpeg :/
<lool> Eh, it wouldn't be ffmpeg if it didn't break API
<siretart> lool: well, yes, but gstreamer-ffmpeg could also at least try to track ffmpeg upstream
<lool> siretart: Perhaps they do in CVS, but they prefer staging with a ffmpeg snapshot
<lool> siretart: As they need to QA/stabilize this ffmpeg tree before outputting a gst-ffmpeg
<smurf> Does anybody know why there seems to be no libglade2.*dbg package?
<TomaszD> pitti, I see you've uploaded avahi with po template, but you missed one thing https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/198859
<ubotu> Launchpad bug 198859 in avahi "Make .desktop files translatable (diffs included to fix this)" [Undecided,New]
<TomaszD> bbl
<seb128> TomaszD: the cdbs magic does update the desktop files automatically
<seb128> TomaszD: didn't read the bug, hint if you want somebody to read your issue you could describe it on launchpad rather pointing to an another bug tracker
<geser> Hobbsee, Mithrandir or pitti: please give-back ldtp. Thanks.
<pitti> lool: hi
<pitti> lool: include langpack.mk in Debian's avahi> won't work, Debian's cdbs doesn't have that
<pitti> lool: if you want to do that in Debian, you should add sth like
<pitti> common-post-build-arch::
<pitti>      cd po; intltool-update -p --verbose
<pitti> TomaszD: hm, langpack.mk should take care of this; it didn't?
<pitti> geser: done
<seb128> TomaszD: in fact the bug is about the desktop not being listed in POTFILES.in
<seb128> pitti: ^
<pitti> ah, I see
<pitti> I wasn't aware of that bug, sorry
<seb128> pitti, lool: not as easy as calling intltool-update because you likely want to add the X-Ubuntu-Gettext-Domain to the desktops too
<pitti> but not to Debian
<pitti> since they don't have our 'use gettext for .desktop' patches?
<seb128> pitti: right, but the question was about being in sync with debian no?
<pitti> I suppose so, yes
<seb128> so we need something doing that
<seb128> pitti: btw lool merged the gettext patch to glib
<pitti> gosh, maybe we should start another attempt to convinve the fd.o guys to add an optional "Gettext-Domain:" to the spec
<seb128> and theorically adding this to the debian desktops doesn't hurt, it just do nothing there
<pitti> it wouldn't cost them much, and doesn't require other distros to change their implementation
<pitti> right
<pitti> lool: hm, e-p-bad is now depwaiting on python-elisa (>= 0.3.5); hardy has 0.3.4-2
<pitti> lool: looks like we shuold just sync this unless it has new features?
<Fujitsu> pitti: lool requested a sync of that earlier, I believe.
<pitti> ah, bug 204555
<ubotu> Launchpad bug 204555 in elisa "Please sync misc elisa* packages from unstable (or incoming)" [Undecided,New] https://launchpad.net/bugs/204555
<TomaszD> How about this pet peeve https://bugs.launchpad.net/nautilus-sendto/+bug/197145 :]
<ubotu> Launchpad bug 197145 in bluez-gnome "REGRESSION [hardy] nautilus-sendto not compatible with bluetooth-sendto" [Low,Confirmed]
<TomaszD> there's a patch available from Bastien tha applies cleanly to hardy's source package
<TomaszD> *that
<seb128> TomaszD: that patch is far to be trivial
<TomaszD> seb128, I'm certainly aware that it isn't trivial,  but it's used in Fedora, I've tested it myself and it doesn't break anything
<seb128> lool: ^ do you think you could have a look to this bluez change? you have bluetooth devices to try I think? Mithrandir has not been responsive on the sponsoring request
<lool> Mithrandir is in leave ATM
<lool> I can have a look
<seb128> lool: thanks
<Hobbsee> geser: given back
<geser> Hobbsee: pitti was faster. I guess I should send an un-ping next time.
<pitti> geser: or I should send the 'done' to hobbsee as wel
<pitti> l
<lucas> who wrote the code for patches.ubuntu.com? the patches are directly taken from MoM?
<pitti> lucas: Keybuk; yes, it's part of the MoM output
<Hobbsee> pitti: yeah, that'd be nice :)
 * Hobbsee tried, anyway
<cody-somerville> Hobbsee, Can you take care of merge #166 for me?
<cody-somerville> or anyone else who wants to for that matter
<slomo__> slangasek: ping? :)
<Hobbsee> cody-somerville: ?
<cody-somerville> Hobbsee, Can you merge the xubuntu seeds?
<cody-somerville> https://code.edge.launchpad.net/~xubuntu-devel/ubuntu-seeds/xubuntu.hardy/+merge/166
<pitti> yay, suspend-to-ram works so mindbogglingly perfect now
<ompaul> pitti, that is worth at least yippee not a yay ;-)
<pitti> YIPPEEEE!
 * pitti will upload that new hal soon
 * seb128_ hugs pitti
<sjoerd> pitti: Could you forward the patchset ubuntu has in hal-info to upstream/debian ? :)
<pitti> sjoerd: hi
<sjoerd> morning :)
<pitti> sjoerd: I did that already when I applied them
<pitti> sjoerd: they should all be upstream
<sjoerd> hmm
<pitti> sjoerd: well, at least the music players are
<pitti> sjoerd: I forwarded a few quirks, too, but they haven't been applied
<sjoerd> aah, the ubuntu version is still the old one
<sjoerd> that explains :)
<pitti> sjoerd: if you mean above suspend patches, I'm just sending a followup with the patches to my mail from yesterday
<pitti> sjoerd: yes, haven't updated yet; still on my list
<sjoerd> I should learn to read :)
<pitti> but this suspend stuff was nagging my brain since yesterday, I had to resolve this (even if it's holiday and all that)
<sjoerd> cool
<sjoerd> i'll commit them upstream if they aren't controversial
<pitti> sjoerd: ok; they should all be on hal@, but I'll merge hal-info now and see what's left
<sjoerd> thanks
<elmargol> Hi I try to create a vlc pakage using the --enable-mediacontrol-python-bindings setting... and i get a permission problem for /usr/lib/python2.5/site-packages/vlc.so any ideas?
<\sh> pitti: it's karfreitag...you should not be sitting in front of IRC ;)
<pitti> \sh: see above, had to get that out of my brain :)
<\sh> pitti: right...I know that feeling ;)
<Kopfgeldjaeger> aloha
<pitti> sjoerd: ok, down to 2 patches again :)
<sjoerd> \o/
<pitti> sjoerd: both are on hal@, BTW
<pitti> http://lists.freedesktop.org/archives/hal/2007-November/009903.html
<pitti> http://lists.freedesktop.org/archives/hal/2008-February/010897.html
<pitti> sjoerd: shall I send you the actual patches again, or the debdiff, or are those ^ enough?
<sjoerd> should be enough
<pitti> seb128_: you are in a sync-y mood today :)
<seb128_> pitti: yes, GNOME 2.22 has been uploaded to debian while we were frozen so I'm syncing what we can now that we are unfrozen ;-)
<\sh> oh sync time :)
<sjoerd> pitti: hummm, syncing on sysfs_paths is a bit nasty.. can't 02_laptop_panel_brightness_in_hardware.patch be done by matching on linux.subsystem instead ?
<pitti> sjoerd: I really don't know, it was mjg59's patch
<sjoerd> mjg59: ^^
<pitti> mjg59: ^ any idea?
<pitti> sjoerd: BTW, the Dell CD-ROM problem is bug 48499
<ubotu> Launchpad bug 48499 in hal-info "hald blocks ide bus if cdrom on same bus with harddisk(was:Extremly slow IO performance with dapper, high wa% on Dell Inspiron 8200)" [Medium,Fix released] https://launchpad.net/bugs/48499
<sjoerd> I remember that one :)
<pitti> it got reverted upstream without explanation
<emgent> heya sabdfl :)
 * pitti -> holiday mode again, cu all
<seb128_> pitti: enjoy
<pitti> and you!
<ubuntu> hi everyone - may I ask here for problems in installing hardy beta 1 from live cd?
<DRebellion> ubuntu, you probs want #ubuntu+1
<ubuntu> thx
<cody-somerville> Fujitsu, Can you setup a mdt thinger for Xubuntu?
<jdong> mdt thinger
<jdong> why does that sound X-rated?
<cody-somerville> multi distro tool
<cody-somerville> could be lethal
<persia> jdong: http://people.ubuntuwire.com/~fujitsu/mdt/
<jdong> cool!
<mjg59> pitti: Heard from Intel - the resume code doesn't like i855 right now
<mjg59> pitti: They suggest that the easiest thing to do is to look at the PCI IDs for i830 and i855 - there's only 4 of them
<mjg59> And then if we have one of those, perform the quirks
<wasabi> Does wubi use ntfs-3g?
<mjg59> Yes
<wasabi> Hmm. Does Fuse do file->device mappings or does each read require traversing through the daemon?
<wasabi> (ntfs3g is fuse, right?)
<mjg59> It's fuse, yes
<mjg59> I've no idea about the implementation details
<jdstrand> hi seb128_!
<jdstrand> seb128_: are you working today?
<seb128_> hey jdstrand, sort of, it's officially an holiday day for me but I'm around and doing some desktop cleanup now than hardy is unfrozen
<seb128_> jdstrand: if you have a question feel free to ask ;-)
<jdstrand> seb128_: well, I don't want to give you any more work, but you can always say 'no' :)
<seb128_> right
<jdstrand> seb128_: can you look at my last comment on bug #58171 ?
<ubotu> Launchpad bug 58171 in gnome-session "Connection to ICE-unix/.. socket times out so programs take minutes to start" [Medium,Confirmed] https://launchpad.net/bugs/58171
<jdstrand> seb128_: it started biting me lately
<jdstrand> seb128_: when this happened the other day, I had these syslog entries too (I believe), but I didn't note them
<jdstrand> since I can control vnet1, I'll work on a reproducer
<seb128_> jdstrand: that's a weird issue and I've no real clue about IPv6, I don't think I'll be of real help there
<jdstrand> seb128_: I thought it odd too
<jdstrand> seb128_: but it just started happening to me lately
<jdstrand> and it is *extrememly* annoying as I have to restart X
<jdstrand> extremely even
<jdstrand> seb128_: perhaps it'll be more interesting with a reproducer?
<seb128_> jdstrand: does it happen without using ipv6?
<seb128_> jdstrand: for sure it would yes
<jdstrand> seb128_: I don't know yet
<jdstrand> ;)
<jdstrand> seb128_: I just found the bug today
<seb128_> comments seem to suggest it's ipv6 specific
 * jdstrand nods
<jdstrand> seb128_: you know, it was only recently that I enabled ipv6 (for my ufw work)
<jdstrand> seb128_: I'll play with it
<seb128_> jdstrand: let me know if you figure an easy way to trigger the issue
<seb128_> jdstrand: btw would also be nice to try the avahi bug without ipv6
<mdke> seb128_: do you happen to know what happened the the Multimedia tab on "System->Preferences->Removable Drives and Media"? I can't find a way to change the default application for playing DVDs, and we need to amend the documentation
<mdke> (we don't recommend totem-gstreamer for playing dvds as it doesn't seem to support menus)
<seb128_> mdke: nautilus, preferences, media tab
<seb128_> mdke: what do you recommend?
<mdke> seb128_: gxine...
<mdke> seb128_: thanks for the nautilus tip - is there a reason that has disappeared from the Removable Drives and Media tool? It's a bit hidden in nautilus
<mdke> ah, can't specify to open gxine in nautilus anyway
<seb128_> mdke: implementation details let's say
<mdke> it's only totem, do nothing or open folder
<seb128_> mdke: it was handled by an external software and it's handled by gvfs now
<seb128_> mdke: the gxine desktop needs to list the mimetypes
<mdke> hmm.
<mdke> seb128_: do you think we should recommend totem-gstreamer for DVDs anyway, given that it will open automatically for the user even if they install gxine?
<seb128_> yes
<seb128_> and you have the chapters in the playlist
<seb128_> which is not that bad
<mdke> do you happen to know if menu support is far away?
<seb128_> no
<seb128_> it's not that far away for quite a while
<mdke> heh
<seb128_> it "just" require somebody doing the work
<mdke> the alternative is to recommend gxine and tell users how to set "Do nothing" in nautilus
<mdke> then start gxine manually
<seb128_> what do you mean?
<seb128_> they should select gxine there if they want to use it
<mdke> but it isn't there...
<seb128_> mdke:  mdke: the gxine desktop needs to list the mimetypes
<seb128_> mdke: that's a 1 line fix
<seb128_> I'll fix it today
<Chokes> hi all
<mdke> seb128_: aha! Thanks. In that case I'll document how to add it to the nautilus dialog
<Chokes> i have a goog question
<Chokes> good*
<mdke> seb128_: do you know if there are plans for gnome to move that preferences back to the capplet maybe for the next release?
<Chokes> will the fakeraid be supported someday?
<seb128_> mdke: I doubt of it, this "capplet" is a separate thing running for no real need now and we should rather get ride of it
<seb128_> mdke: we can discuss an improved location for the UI next cycle if required though
<Chokes> ???
<mdke> seb128_: yes, that's what I mean. It should be accessible from System/Preferences or control-center or whatever
<Chokes> can someone respond to me please?
<caci> Chokes: maybe.
<jdong> I see great fortune in your future.
<Chokes> so when the fakeraid will be supported?
<superm1> slangasek, might you recommend a good way to test improvements to seeds aside from the daily disk generation?  laga wanted to fix the -diskless stuff inside the alt disk, but waiting a day each time ends up not being a very good solution
<laga> slangasek: i can test the diskless stuff better now (wget the udeb from somewhere and install it).
<laga> slangasek: we're more concerned about adding 'tasks' to the alternate disk..
<jdong> Chokes: to answer your question, I don't think there is any active work going towards supporting fakeraid at the moment
 * xhaker enters fortune on the terminal after reading what jdong wrote
<Chokes> ok....
<superm1> jdong, would you mind looking over the mythstream backport on gutsy-backports?  been getting bugged about it several times this week
<Chokes> so the bes distro cant support the fakeraid
<Chokes> best*
<jdong> Chokes: fakeraid can be used on Ubuntu by post-install configuration, but there doesn't seem to be anyone interested enough in fakeraid support to implement it into the installer
<mdke> seb128_: ok, this is what I've written (a middle ground) - http://mdke.org/tmp/DVD.png
<jdong> Chokes: nobody is stopping anyone from doing it. If you want to implement fakeraid support you are more than welcome to
<Chokes> yeah but im not a dev.....
<mdke> seb128_: I'll leave the gxine bit to you :D
<jdong> superm1: *grumble* packing up for a plane ride this afternoon currently; bug#?
<superm1> jdong, bug 202988
<ubotu> Launchpad bug 202988 in gutsy-backports "Please backport mythstream 0.18.1 from hardy" [Undecided,New] https://launchpad.net/bugs/202988
<Chokes> i can say "Wow" on all the features
<xhaker> Chokes: just file a bug and get enough subscriber to that bug, it will be noticed then.
<jdong> Chokes: what do you need with fakeraid, out of curiousity?
<Chokes> jdong : i want to install ubuntu on my fakeraid setup
<jdong> Chokes: have you seen https://help.ubuntu.com/community/FakeRaidHowto, by the way? It's not pretty but it'll work
<Chokes> maybe load a script or something that we can coose on the boot menu coulb be great
<Chokes> that what ill retry later
<Chokes> it didnt work for me
<seb128_> mdke: alright
<jdong> I'm not sure if GRUB would boot directly off fakeraid
<jdong> somehow I doubt it. At which point you should be begging $other_people for fakeraid support :)
<Chokes> it should
<Chokes> mmm
<Chokes> the problem her is ubuntu is supposed to be easy to use and install ok?
<jdong> I don't know nearly enough about fakeraid implementations on hardware to know if it provides enough block device emulation for booting to be successful with GRUB
<Chokes> so take the one who dont know about linux
<Chokes> he want to install linux on his fakeraid setup
<jdong> the last I heard about fakeraid is that it's essentially a couple bit flags that say "oh yeah treat this as a RAID please"
<laga> they probably wont have a rakeraid then ;)
<Chokes> maybe
<Chokes> but they will see that they dont see the raid...
<jdong> because it's not really a RAID.
<Chokes> yeah i know
<Chokes> its fake
<laga> Chokes: i'd hope that.. otherwise they'd be desyncing their array if they installed on just one disk
<xhaker> jdong: what is your stance about transmission? 1.10 for FFe?
<Chokes> when i install dmraid
<Chokes> the i start the installer
<Chokes> then*
<jdong> xhaker: I am not very comfortable with the idea, but it will depend on the final diff size
<Chokes> the installer see the fakeraid config
<jdong> xhaker: I've been tracking trunk on subversion and it all looks quite invasive
<jdong> but it won't boot because the installed system won't know about fakeraid.
<Chokes> =_=
<xhaker> jdong: my take exactly, but looking at the NEWS file it gets pretty interesting
<jdong> bug 191557 has the official position on it, Chokes
<ubotu> Launchpad bug 191557 in dmraid "Main inclusion report." [Undecided,Won't fix] https://launchpad.net/bugs/191557
<Chokes> it wont install at all
<jdong> please read the last comment on that bug
<jdong> xhaker: if transmission were still just another azureus or deluge in Universe, I'd be more willing to consider it. But it's not. It's the main torrent client that comes associated by default for all Hardy installs. Way too risky
<jdong> xhaker: at this point, we've got like 2 or 3 crasher bugs unresolved in our 1.06, I'd say fix via backporting specific patches from this point forward, and defer 1.10+ for backporting possiblity.
<jdong>    + Stop torrents when downloading and the disk becomes full
<jdong> on a side note.... how would that help?
<Chokes> jdong its a mac osx bug......
<jdong> when the disk becomes full, stopping the torrent isn't gonna fix much.
<Chokes> ok
<Chokes> now i got it
<xhaker> jdong: might avoid the application to crash
<jdong> superm1: myth done
<jdong> superm1: rather, myth confirmed :)
<superm1> jdong, now the interesting situation here is that mythstream was already backported once
<superm1> same upstream version
<superm1> just different ubuntuX revision
<superm1> this one has a patch to allow it to now FTBFS against the new libmyth
<jdong> superm1: well it was a soyuz bug in 2005, 2007 is congruent to 2005 mod 2.......
<superm1> so could a sourceful upload be done one it since its not a new version, and won't go through NEW?
<jdong> superm1: so by that logic it's probably going to be a soyuz bug that the backport gets rejected post-build :D
<superm1> argh, that won't be good
<jdong> superm1: wait. Clarify that again?
<superm1> jdong, so earlier in gutsy's cycle, we backported this version of mythstream
<superm1> this upstream version
<superm1> but it needed to be rebuilt after the libmyth backport
<superm1> in order to rebuild, it needs a patch present in the hardy version (hence the new backport)
<jdong> superm1: barring the old soyuz bug, a direct backport from hardy should work as long as the libmyth backport is done first, correct?
<superm1> which is was
<superm1> so i was just wondering if we'd still need to go through an archive admin for this
<superm1> or if just upload directly to gutsy-backports
<superm1> since it was already backported once
<jdong> superm1: no all uploads to gutsy-backports land in the queue
<jdong> superm1: regardless of if it's NEW
<superm1> jdong, ah okay then normal process it is :)
<jdong> yay :)
<jdong> barring the soyuz bug mod 2 :)
<jdong> I think I've found a working model of soyuz regressions! :D
<cody-somerville> slangasek, Did you start the rebuild for Xubuntu? :)
<orbisvicis> i have this ubuntu package i changed, how can i increment the version number ?
<jdong> dch -i
<orbisvicis> so what am i seeing here ?
<thesurvivorman> the matrix
<orbisvicis> lol
<orbisvicis> and which file does dch -i change ?
<james_w> debian/changelog
<slangasek> slomo: pong
<james_w> it should have spawned an editor to allow you to add a changelog entry.
<orbisvicis> yeah it did
<slangasek> superm1, laga: sorry, I'm not sure of a good way to test seed changes besides running them through the image generation
<orbisvicis> just wasnt sure what to change till i compared dch with dch -i
<orbisvicis> but thanks, got it
<slomo> slangasek: hi, just wanted to ask you about a FF exception that needs some discussion :)  we currently have gtkhtml3.8 in main just because of f-spot->gnome-sharp2 which is bad... now the solution could be, to get gtk# 2.12.0, gnome# 2.20, gnome-desktop# 2.20 (packages in debian/unstable, just need trivial merging), get the latter into main and build f-spot against it (required patches in debian too). in debian there are no known problems with th
<slomo> e new versions yet, they're part of the gnome 2.22 release (so iirc covered by the general gnome exception) but unfortunately introduce some new features :)
<slangasek> cody-somerville: I hadn't started an xubuntu rebuild; everything is in place such that you're ready for me to do so?
<cody-somerville> slangasek, Uno momento
<slangasek> slomo: if they're part of the gnome 2.22 release, that covers FFe
<cody-somerville> slangasek, can you take care of this? https://code.edge.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.hardy/+merge/166
<slomo> slangasek: ok, even now after beta was released and considering the changes?
<slomo> dashua: ping? regarding banshee svn building... --enable-external-boo (and all the other --enable-external-* parameters) for configure will fix it
<slangasek> slomo: if you do it right away and don't make me think too much about what I'm saying... :/
<slomo> ok ;)
<dashua> slomo, Hello
<dashua> Ok, thx
<slangasek> cody-somerville: merged
<cody-somerville> slangasek, Okay. Those merged seeds should be good to go
<cody-somerville> slangasek, did you push it after merging it?
<slangasek> I merged it into the relevant branch, yes
<cody-somerville> Launchpad must be slow. I usually get an e-mail notification by now.
<cody-somerville> Ah, there we go
<cody-somerville> slangasek, should be all good :)
<dashua> slomo, Built rev. 3505 and it's still not recognizing the device.
<hefe_bia> cjwatson: Do you know whether somebody is working on bug #54776? It's marked "In Progress" but not assigned to anyone.
<ubotu> Launchpad bug 54776 in openoffice.org "[Ubuntu] [hardy] font hinting does not work with libfreetype6 v. 2.2.1" [High,In progress] https://launchpad.net/bugs/54776
<slomo> dashua: ok, so it's at least not my fault :) anything useful printed when starting it? could you pastebin the complete output from starting banshee until everything is done?
<dashua> Sure, I know this device definitely works and I help gabaug test it in #banshee.
<dashua> slomo, http://paste.ubuntu-nl.org/60426/
<slomo> dashua: no idea, better file upstream :)
<slomo> dashua: or talk with scottp in #banshee (iirc he wrote the mtp support)
<dashua> slomo, Will do thx.  I'm not sure if something changed in the past month or not. Thx.
<slomo> dashua: yes, something changed ;)
<james_w> hefe_bia: you're probably best asking calc about that.
<cody-somerville> I'm definitely recreating the branch for Intrepid
<slangasek> slomo: heh, why does gtk-doc build-conflict with openjade and build-depend on docbook-dsssl?
<slomo> slangasek: because it needs exactly these two... it can't work with openjade but needs docbook-dsssl which shouldn't be a problem as the latter depends on all 3 jade packages conditionally
<slangasek> slomo: right, well, the buildd didn't see it that way http://launchpadlibrarian.net/12784304/buildlog_ubuntu-hardy-i386.gtk-doc_1.10-1_FAILEDTOBUILD.txt.gz
<slangasek> seb128: and why are you uploading packages that has slomo's name in the changelog, OMG confusing. :)
<seb128> slangasek: those are called "syncs" ;-)
<slangasek> seb128: heh, true
<slangasek> slomo, seb128: so I guess an explict build-dependency on jade would fix this...
<slomo> slangasek: like "Build-Depends-Indep: jade (>= 1.2.1-35)"?
<slomo> slangasek: the buildd doesn't like it because it's in b-d-i maybe
<seb128> slomo: those didn't change in the new version right?
<seb128> seems to be a soyuz issue
<slomo> no, that didn't change
<slangasek> slomo: mmm, yes :)
<theunixgeek> Where can I download all the docs at http://library.gnome.org/devel/gtk/stable/, preferably in a PDF?
<Festor> Would it be possible to add transmission 1.10 to 8.04 Ubuntu repositories?
<Festor> It launched the first beta
<Festor> http://forum.transmissionbt.com/viewtopic.php?t=4365
<Festor> added libnotify support
<Festor> more translations
<Festor> and more bugfix
<Festor> complete changelog
<Festor> http://trac.transmissionbt.com/query?status=closed&milestone=1.10
<Festor> hi?
<seb128> Festor: are you upstream for it?
<Festor> sorry seb128? I do not understand what you mean
<seb128> Festor: are you working on this software or just an user asking for a new version?
<jessica> do you know when the realtek RTL8187B wireless driver will be incuded
<Festor> ehh
<Festor> I am a packager
<Festor> but not a official packager of ubuntu
<Festor> I work for GetDeb
<Festor> But I would like to know if that was possible
<jessica> dose anyne know when the realtek RTL8187B driver will be incuded in ubuntu
<Festor> The current version of the program which comes in hardy is perhaps something old
<Festor> jessica, i think that this first in vanilla kernel
<james_w> jessica: do you know what package provides the RTL8187 driver, it seems like they should be the same driver.
<james_w> or at least the 8187 could be made to support the 8187B
<jessica> i dont know much about it im a linux noobie
<seb128> Festor: no it's not old, but if the new version is a bug fix one there should be no problem
<Festor> http://trac.transmissionbt.com/query?status=closed&milestone=1.10
<seb128> Festor: maybe it would benefit to everybody if you were working to get those new versions in Ubuntu rather than on GtkDeb?
<seb128> s/GtkDeb/GetDeb
<jdong> Festor: I just talked to someone 2 hours ago about this
<jdong> xhaker: ^^
<seb128> btw could anybody talk to upstream about fixing the menu item to give an idea of what the program is doing?
<Festor> seb128, It is not easy to be part of MOTU
<jdong> Festor: as the administrator of the MOTU P2P team, it's my opinion that this is too late in the release cycle to introduce a new upstream version of the default Ubuntu torrent client
<seb128> Festor: that's not true
<jdong> Festor: you do not have to be MOTU at all to contribute
<seb128> Festor: did you try?
<jdong> Festor: I did fine as a contributor for over 2 years before becoming a MOTU.
<seb128> Festor: and you don't need to be a MOTU to send update diff on launchpad and subscribe the sponsor team
<jessica> i want to start helping ubuntu do i need to learn a programming language if so which ?
<seb128> jessica: no
<jdong> Festor: at this point, any defects in transmission 1.06 should be handled as an isolated patch backport
<seb128> jessica: you can do user support, fix or triage bugs, do translations, etc no need to code
<jdong> (of course if any core-devs/ubuntu-release folks want to override this opinion they are more than welcome!)
<seb128> jdong: no, new bug fix versions are welcome
<jessica> how do i like because part of it
<seb128> jdong: there is no UVF now, only FF
<jdong> seb128: 1.10 is not a bufix version though, from what I see
<jessica> at the moment im just helping on the forum but i want to do more
<seb128> jdong: that was my question
<jdong> seb128: even the GUI has been rearranged/redesigned
<bobbo> jessica; bugs in Launchpad tagged with 'bitesize' are often useful for getting started
<Positronic> there is no data
<Positronic> only XUL
<jdong> seb128: there *are*, however, mentions of some bugfixes, which I would be interested in isolating :)
<seb128> jessica: try on #ubuntu-motu maybe, that's where people start usually
<james_w> jessica: that's useful, thanks. If there is a certain area that you would like to do more in you can tell us and we can try and point you in the correct direction.
<james_w> jessica: also, for your driver question it doesn't seem like it will be anytime soon I'm afraid.
<jessica> i dont really mind and ok i will just complie the driver
<steveire> Hi. I just tried a s/gusty/hardy/g and an update, and I got an unmet dependancy: 'librdf0-dev: Depends: libdb-dev but it is not installable' Is this a missing metapackage or a librdf packaging bug?
<jessica> i just want to do more for ubuntu
<steveire> http://packages.ubuntu.com/search?suite=all&searchon=names&keywords=libdb-dev
<jessica> i dont mind learning a coding language or something
<jdong> Festor: as soon as Intrepid opens, I'd be happy to put transmission in backports
<Festor> jdong, Sorry but I believe that almost 40 errors corrected is a bubfix release
<jdong> Festor: please don't resort to getdeb packages for this, at least not without consulting one of us MOTU-P2P folks. We don't need to diverge packaging.
<jdong> Festor: it has bugfixes but is *NOT* a bugfix *ONLY* release
<Festor> ehhh
<Festor> ok
<jdong> Festor: I have been tracking and watching subversion trunk on transmission these weeks
<jdong> Festor: if I have some time this weekend I'll look at backporting all the bugfix-only fixes, but charles_ and I agreed that 1.06 would be the last version to go into Hardy
<seb128> GetDeb is grrrrrr
<Festor> I dont understand " please don't resort to getdeb packages for this"
<seb128> why people need to fork efforts rather than contributing
<seb128> s/contributing/contribute
<jdong> and I'm frankly a bit disappointed that Transmission team decided to make bugfixes ONLY for a brand new branch.
<jdong> Festor: I meant, Ubuntu and Debian have a coordinated effort and infrastructure for packaging Transmission. There is no reason to fork from this infrastructure and diverge packaging
<jdong> unless it's in your interest to risk introducing incompatible transmission packaging.
<Festor> I dont like backports
<jdong> let's work together to achieve some solution on this. Nobody's going to fall over and die if they do not get the latest transmission in the next 24 hours.
<Festor> is not the same use a repositorie
<Festor> than download only a deb package
<jdong> backports *is* a repository.
<jdong> you can download single debs from backports off packages.ubuntu.com
<Festor> and libs?
<Festor> ~~
<jdong> Festor: if you don't want to use the backports repository, at least use the backports *packaging*
<Festor> what?
<jdong> uupdate from Debian/Ubuntu packaging of Transmission
<jdong> do not go reinventing these packages
<steveire> Here's the rest of the errors. It looks like libc6, libdb and tzdata have issues.
<steveire> http://kde.pastey.net/84190
 * YokoZar notices the mirrors are really slow today due to beta release and begins having crazy ideas about apt-torrent
<jdong> YokoZar: indeed
<steveire> YokoZar: I think apt-torrent is a brilliant idea
<jdong> YokoZar: I did my best... I seeded 150GB onto the two desktop torrents
<Festor> "at least use the backports *packaging*"  <- why?
<jdong> steveire: the downfall is it needs to daemonize
<jdong> Festor: I just told you. Otherwise you risk introducing breakage and incompatibility once Ubuntu officially releases transmission 1.10 packaging.
<steveire> downfall of apt-torrent or my update attempt?
<jdong> steveire: apt-torrent
<steveire> What does it mean to daemonize?
<jdong> steveire: apt-torrent must go into background and continue running beyond the duration of getting the update
<jdong> steveire: otherwise the swarms are going to be total crap health if everyone just grabs enough to get the package and runs off
<YokoZar> It also means abstracting the torrent engine out of the torrent client if we don't want to duplicate things
<jdong> YokoZar: we could theoretically use a transmission-daemon for doing that :)
<YokoZar> Actually, it'd be pretty nice if I could check a box or slider in transmission that said "use my bandwidth to share updates with other Ubuntu users" and it communicated using DBus calls
<jdong> :)
<jdong> Festor: so are you interested in helping get the bugfixes from transmission 1.10 into Hardy?
<Festor> http://pastebin.ubuntu.com/5975/
<Festor> only added libnotify-dev
<jdong> that is not helpful to us
<Festor> sorry
<jdong> that's 100% different from Ubuntu's packaging in Hardy
<jdong> that's what I meant, not to reinvent the packaging
<Festor> what?
<Festor> only changes Debian Policy
<Festor> 3.7.2 -> 3.7.3
<Festor> not?
<jdong> where's transmission-cli, transmission-common and transmission-gtk?
<Festor> ahhh
<Festor> ok, ok
<jdong> we don't need to reinvent the packaging from scratch, because we have existing packaging for it
<Festor> but, only changes are add libnotify-dev
 * jdong nods
<Festor> jdong, getdeb is not a repos
<Festor> is a web
<Festor> more packages -> not good
<jdong> yes but installing your package right now will cause dpkg overwrite errors on transmission-gtk and transmission-common
<jdong> you are causing dpkg breakage by distributing these packages
<Festor> only if you had installed those packages before
<jdong> also, 1.10b1 is > 1.10
<jdong> which means even final ubuntu 1.10 package will be overridden by these packages
<Festor> 1.10b1 is temporaly
<Festor> it is not will publisehd
<jdong> Festor: it is getdeb's responsibility to ensure previous packages are not installed, then.
<Festor> sorry for my bad English
<jdong> Festor: if you would like to help with getting these bugfixes into Hardy, please file a launchpad bug on transmission, including that Trac link from earlier detailing all the bugfixes
<YokoZar> Festor: Please use 1.10~whatever for any packages you publish.  The ~ means they'll be "lower" than anything that's the same before the ~ and will upgrade cleanly.  So 1.10 > 1.10~b1
<jdong> Festor: I will lookthat over once I get back in town and make a decision on whether to isolate all the bugfixes or request that 1.10 in its entirety be put in Hardy.
<Festor> ok, thanks YokoZar :D
<jdong> Festor: does that sound reasonable?
<YokoZar> Festor: Thanks :)  I do this with the unofficial Wine packages I make, by the way.  Works really well
<Festor> yeah! I am a unofficial deb packager of aMule
<Festor> http://forum.amule.org/index.php?topic=13836.0
<emgent> hello people
<YokoZar> Festor: do you do more amule development or just packaging?
<Festor> packaging, translations, and a few patches
<Festor> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/204600
<ubotu> Launchpad bug 204600 in amule "[hardy] Fix Spanish translation of aMule" [Undecided,Fix committed]
<Festor> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/197332
<ubotu> Launchpad bug 197332 in amule "[hardy] aMule SVN warning on first run" [Undecided,Fix committed]
<Festor> I like ubotu :D
<slomo> dependency-wait is handled automatically, right?
<ScottK2> slomo: Unless there's a soyuz bug.
<slomo> ok, let's see what happens ;)
<Festor> Well ... I will try to enter the MOTU again... xD
<slytherin> Can anyone give me any pointers about OOo build failure on powerpc?
<LaserJock> what's the best way to debug Network Manager?
<\sh> gdb and attaching to NM pid?
<slangasek> aptitude purge network-manager ;)
<LaserJock> slangasek: not a bad idea, but I was hoping to be more helpful :-)
<LaserJock> it seems like after the post-Beta update blitz NM no longer works for me
<cody-somerville> slangasek, for some odd reason, I lost network connectivity when I ran that command.
<slangasek> LaserJock: mm, I don't think network-manager was part of that blitz... hal and udev were though?
<slangasek> (not sure if either of those is relevant either)
<LaserJock> yeah, I first looked to see if somebody had uploaded a new NM and there wasn't
<slangasek> slytherin: that build failure may point to an issue with debian/control listing different packages for powerpc than are actually being built
<LaserJock> so I'm trying to figure out what it's having a problem with
<slytherin> slangasek: Oh. I will check diff.gz But how come there is no problem in Debian? Or is it failing in Debian too?
<slangasek> slytherin: the packaging is not the same between Debian and Ubuntu
<slytherin> ahh
<LaserJock> ok ... so NM dies a horrible death when it tries to connect but leaves a process eating up 99% of my cpu
<Griswold> Is it possible to internationalize Gtk labels found in a .glade file?
<slangasek> or rather, most of the packaging *is* the same, but the build takes very different paths through the packaging depending on which platform it's building fore
<slangasek> s/e$//
<LaserJock> I gotta run to lunch but if people have ideas I'll read the scrollback
<slytherin> slangasek: is there anyone whom I can bug about this if I myself can't figure out?
<slangasek> slytherin: calc, I imagine
<slytherin> slangasek: Ok Thanks.
<seb128> slangasek: I know it's really late in the cycle now, but do you think installing nautilus-share by default is still doable?
<stgraber> I have the same problem as LaserJock with NM (taking 99%)
<stgraber> the bug only appeared a few hours ago
<slangasek> seb128: it's sufficiently limited in scope that I'm comfortable with that, yes
<slangasek> seb128: do we also get to ditch shares-admin?
<seb128> slangasek: ok, good
<stgraber> asac: around ?
<seb128> slangasek: yes, it's not working for anybody anyway
<seb128> slangasek: it requires people to use smbpasswd from the command line to get anything shared
<seb128> slangasek: for nautilus-share we should fix bug #204703 though
<ubotu> Launchpad bug 204703 in samba "usershare: insuffisant permissions for anonymous login" [High,Triaged] https://launchpad.net/bugs/204703
<slangasek> seb128: hmm?  I'm confused; didn't I just see (...reassign) a bug report /complaining/ that shares-admin makes all shares available anonymously?
<slangasek> for that matter, nautilus-share manages usershares, and the default is to disallow anonymous access to usershares
<seb128> oh, so it's not a bug?
<seb128> mathiaz: ^
<slangasek> I didn't think that it was a bug...
<ScottK2> This is from Bug #204768: "The latest HAL update has changed the keys for checking for suspend and hibernation support." - Would someone please assure me we aren't uploading crack that changes function names after the beta without testing what it breaks?
<ubotu> Launchpad bug 204768 in kde-guidance "[hardy] Latest HAL breaks guidance powermanager" [Undecided,New] https://launchpad.net/bugs/204768
<seb128> slangasek: well, from a desktop point of view I'm looking for a way to share things over smb easily for user, and it looks like there is no way to do that at the moment
<seb128> slangasek: we don't allow anonymous share and don't sync the user database on samba
<ScottK2> slangasek: Do I patch Guidance to learn HAL's new language or is the above ^^^ some kind of mistake?
<seb128> slangasek: which means it's not possible to share folder anonymously nor by using the user login setting
<mathiaz> slangasek: even if the default is to disallow anonymous share, even if you define an anonymous share it doesn't work
<slangasek> seb128: yes, but the plan discussed at UDS was "make it easy to integrate pam_smbpasswd so that all users have samba passwords by default"
<seb128> slangasek: well looks like that didn't happen and mathiaz told me he thinks that's late now for hardy
<slangasek> seb128: "let people share stuff anonymously" is a huge step back from that; I understand desktop users need sharing, but anonymous sharing gives me the hives
<seb128> slangasek: I'm trying to limite damages there, if there is no way we should just remove any GUI doing smb sharing
<slangasek> mathiaz: it's the smb.conf policy; you don't want to let usershare users override the global policy on anonymous sharing
<mathiaz> slangasek: hm - so if smb.conf doesn't allow guests, then usershare with gest_ok = yes are not respected ?
<seb128> slangasek: I think there is really a difference between user expectations and what we provide right now
<slangasek> mathiaz: correct; you have to explicitly enable anonymous usershares before guest_ok=yes will work
<seb128> slangasek: most of them want to share thing easily, which means they don't want to have to give login informations to let people browse their shares
<slangasek> seb128: I agree; I'm just reluctant to address this by giving users an easy way to do anonymous shares with no way to do password-protected shares
<seb128> slangasek: if we don't want to provide that I think we should just remove any sharing facility
<seb128> slangasek: the way nautilus-share works is that shares are password protected unless you click on the anonymous option
<slangasek> which everyone will have to do because we don't have the smbpasswd integration right :/
<seb128> slangasek: but right, the pam integration didn't happen and we have to graphical way to add users to the smb database
<slangasek> but yes, I concede that this is better than nothing
<slangasek> mathiaz: usershare allow guests = yes
<slangasek> let me see if I don't have a samba upload pending already, that I can add that to
<seb128> the smbpasswd integration is not going to happen for hardy, right?
<slangasek> I expect not
<slangasek> I think the only option we had available for right now was auth-client-config
<seb128> what is that?
<mathiaz> jdstrand: ^^
<slangasek> jdstrand's tool for swapping out pre-made PAM config settings
<jdstrand> actually, it is pam and nss
<slangasek> ScottK2: I didn't upload the hal change, and I don't believe it was cleared via FFe before upload; I guess you should check with pitti
<seb128> the hal update is just a git snapshot to a stable candidate
<ScottK2> slangasek: OK.  I'll check with him on Monday I guess.  Thanks.
<seb128> which is likely a good thing
<seb128> monday is an holiday
<ScottK2> Tuesday then.
<seb128> yes
<seb128> but expect the current version to be a wanted change rather than a mistake
<slangasek> ScottK2: in the source, I see a fdi/information/10freedesktop/01-deprecated-k
<seb128> that's a git version to stable candidate one as said
<slangasek> ... eys.fdi that lists both keys
<slangasek> ScottK2: so it looks like this wasn't supposed to break
<ScottK2> slangasek: OK.  I haven't looked into it beyond being annoyed at post-beta interface changes.  Thanks.
<slangasek> seb128: if it's *wanted* to break interfaces post-beta, I agree with ScottK2 that this is not a good thing...
<jdstrand> slangasek: on the topic of auth-client-config-- do you think a fix for this is appropriate for hardy-- https://bugs.launchpad.net/auth-client-config/+bug/179919 ?
<ubotu> Launchpad bug 179919 in auth-client-config "No netgroup support" [Wishlist,In progress]
<ScottK2> The rdepends for HAL, excluding meta packages is ~ two dozen, so I guess some testing is needed.
<jdstrand> slangasek: I haven't done anything with the patch, as I thought this was a 'feature'
<jdstrand> but maybe it's a bug...
<slangasek> jdstrand: doesn't look appropriate to me
<jdstrand> slangasek: that is what I thought.  thanks for looking at it :)
<slangasek> looks like a feature enhancement, not a bugfix :)
<jdstrand> tomato, tomato... wait...
<seb128> slangasek, ScottK2: can_hibernate is the right interface for ages
<slangasek> seb128: so?  you don't go deprecating interfaces post-beta without some kind of testing.  Anyway, I think this is just a packaging error, the new fdi file needs to be added to the Debian packaging
<seb128> right, I think so
<seb128> just pointing that upstream didn't change it between the git snapshot and the new update
<seb128> that's just a compatibility patch not applied correctly most likely
<seb128> but still, would be better to fix KDE to not use things deprecated for ages
<seb128> and to fix hal to still have the compatibility thing in case something else is using it ;-)
<slangasek> yes
<seb128> ScottK2: those keys have been deprecated in 2006 btw, just for information
<seb128> ScottK2: is this applications maintained?
<seb128> slangasek: btw do you think it'd would be unreasonable to have samba installed but not running by default at some points? out of the CD space issue
<slangasek> "at some point" meaning intrepid, right? :)
<seb128> yes
<slangasek> seems possible
<seb128> at the moment we have this "you need to install samba to share this folder, do you want to install that now" dialog
<seb128> but that requires people to have internet access, download it, etc
<seb128> well, that's a one time thing, but still would be better to just have to enable something already installed
<slangasek> yes
<ScottK2> seb128: It's slightly maintained, but will not transitionto KDE4.
<ScottK2> seb128: It's just awfully late in the process to be breaking stuff.
<seb128> ScottK2: it doesn't seem to be a wanted breakage and as written those key are deprecated for years, anyway will like be fixed next week but you should still update your broken software to not use deprecated things
<seb128> s/like/likely
<slangasek> ScottK2: hal uploaded
<seb128> slangasek: that was quick ;-)
<LaserJock> stgraber: find anything about NM yet?
<slangasek> why wait? :)
<seb128> slangasek: right ;-)
<slangasek> cody-somerville: xubuntu alternates are built and right-sized, 20080321; would you like me to put these on the ISO tracker for consideration as beta candidates?
<stgraber> LaserJock: not really, I tried a rebuild of the package (in case it was related to the new hal) but that didn't help
<cody-somerville> slangasek, yes please
<cody-somerville> link?
<LaserJock> where are the -dbg packages located? I don't see them on LP
<ScottK2> slangasek: Thanks
<stgraber> LaserJock: ddebs.ubuntu.com
<LaserJock> nvm, found them on archive.u.c
<ScottK2> seb128: The software is unlikely to exist past Hardy, so more fixing that is absolutely needed is a waste of time.
 * ScottK2 is busy enough fixing python-central related breakage.
<stgraber> LaserJock: the dbg package doesn't help that much here
<slangasek> cody-somerville: added
<stgraber> LaserJock: the missing symbol was just 0x00007f01beb02cc6 in poll () from /lib/libc.so.6
<LaserJock> I see
<LaserJock> no indication of why it crashes?
<stgraber> not really, if only it crashed completely, that would help :)
<LaserJock> yeah
<slangasek> stgraber: strace?  lsof?
<stgraber> in my opinion it crashes exactly when it's supposed to start wpa_supplicant
<slangasek> (to find out what it's polling so urgently)
<LaserJock> I don't have wpa
<LaserJock> I do have a funky device showing up though, wlan0_rename
<stgraber> it enters some kind of segfault loop here
<stgraber> [pid 14801] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
<stgraber> [pid 14801] rt_sigreturn(0xb)           = 0
<LaserJock> stgraber: you don't suppose it's a HAL issue do you?
<stgraber> well, I checked hardy-changes between the time NM was working and the time it was not working
<stgraber> then I had a look at NM's build-dep and only found hal
<ScottK2> Maybe NM uses one of the deprecated keys too?
<LaserJock> that's what I'm wondering
<\sh> .oO(surprise surprise?)
<ScottK2> LaserJock: You could grab the source for the latest upload build it and see if it helps (or just wait for it to appear on your local mirror).
<stgraber> I shouldn't break my whole system by downgrading hal right ?
<LaserJock> ScottK2: if I'm lucky and have all the build deps on my machine. I have to build it on the one with no network
<ScottK2> Yeah.
<ScottK2> LaserJock: What architecture?
<stgraber> I'm uploading to my local builder, starting with amd64
<LaserJock> ScottK2: amd64
<ScottK2> LaserJock: OK.  Can't help you there.  Sorry.
<LaserJock> stgraber: you're building an amd64 .deb?
<stgraber> LaserJock: yep
<LaserJock> stgraber: mind sharing the love :-)
<stgraber> sure, will upload that somewhere
<LaserJock> awesome, thanks
<stgraber> LaserJock: http://www.stgraber.org/download/ubuntu/hal/
<YokoZar> Will Hardy be available on DVD for things like shipit?  On Gutsy the DVD image seemed less official in a way since there was no packaged version.
<stgraber> LaserJock: it works here !!!
<LaserJock> stgraber: what kind of wifi card do you have?
<stgraber> LaserJock: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection
<stgraber> that's a ABGN card
<LaserJock> ah, mine is an intel 4945 I think
<seb128> what is the issue?
<LaserJock> so because of the hal thing NM couldn't find the driver
<LaserJock> in syslog it said the driver was 'null'
<LaserJock> now it says 'ipw3945'
<stgraber> seb128: NM entering in a segfault loop with pitti's hal
<ScottK2> stgraber: Pretty please make the 4965 work.  My production laptop (that's still on Gutsy) has that one.
<stgraber> ScottK2: works just fine here :) (when hal is not broken)
<seb128> stgraber: what version it's pitti's one?
<seb128> stgraber: or you mean current hardy one?
<stgraber> hal (0.5.11~rc2-1ubuntu1)
<LaserJock> seb128: right, the one before slangasek fixed it :-)
<stgraber> hal (0.5.11~rc2-1ubuntu2) from slangasek fixes it
<seb128> ok
<seb128> so it's already fixed ;-)
<LaserJock> so I guess NM needs to be fixed to not use the deprecated keys :-)
<ScottK2> stgraber: Thanks for setting my mind at ease.
<ScottK2> LaserJock: For Intrepid, I agree.
<slangasek> oh, -1ubuntu2 fixes NM as well?
<slangasek> interesting
<LaserJock> slangasek: yep
<ScottK2> slangasek: You're way more of a hal fixing genius than you even knew.
<\sh> or NM is far beyond time ;)
<seb128> slangasek: network-manager seems to be using net.physical_device which is a 01-deprecated-keys.fdi thing
<slangasek> aha
<seb128>       <!-- *.physical_device - finally removed: 2008-03-03 -->
<seb128> that is a recent thing
<seb128> compared to the can_suspend and can_hibernate
<seb128> slangasek: anyway well done for the quick fixing ;-)
<slangasek> :)
<seb128> asac: ^ you might want to update network-manager to use the new net.originating_device
<LaserJock> slangasek: yeah, I would have had to work  in OS X all day if you hadn't of :-)
<slangasek> heh
<Kopfgeldjaeger> affili.net reflink?
<sebner> slangasek: still around?
<slangasek> sebner: yes
<sebner> slangasek: would you mind unsubscribing ubuntu-release from bug #203298 and bug #203314 ?
<ubotu> Launchpad bug 203298 in gtk-sharp2 "[FFe] Merge gtk-sharp2 2.12.0-2 from Debian(Unstable)" [Undecided,Fix released] https://launchpad.net/bugs/203298
<ubotu> Launchpad bug 203314 in gnome-sharp2 "[FFe] Merge gnome-sharp2 2.20.0-2 from Debian(Unstable)" [Undecided,Fix released] https://launchpad.net/bugs/203314
<slangasek> sebner: if it's "fix released", it doesn't matter?
<sebner> slangasek: though I set it to Fix Released? ^^
<cjwatson> hefe_bia_: calc (Launchpad id ccheney) has been marking OOo bugs in-progress to indicate that he's planning to work on them for hardy
<hefe_bia_> cjwatson: thanks, good to know :)
<cr3> might it be possible that python-lxml has been removed from the hardy repositories? I can't seem to find it under: http://archive.ubuntu.com/ubuntu/pool/(main|universe|multiverse)/p/
<slangasek> cr3: because the source package name is lxml
 * ScottK hands cr3 https://launchpad.net/ubuntu/+source/lxml
<cr3> not that I'm sure it was ever there
<cr3> slangasek: cheers man, my repo cache seems b0rked :(
<cr3> all good now, always helps to know what's supposed to work :)
<ion_> I wonder what has added commit=360 to my root partition's mount options? Didn't find the string under /etc/init.d or /usr/share/initramfs-tools.
<ion_> Ah, laptop-mode-tools.
<sistpoty> doko: please give back missingh on sparc, thanks!
<mi> can i do upgrade 7.10 to 8.04 with envy driver or i must first uninstall evny ?
<ScottK> You should ask wherever you got envy or in #ubuntu+1
<mi> tq
<emgent> heya imbrandon :)
<slomo> hrm, can someone tell me why mono fails to build in ubuntu but builds fine in debian with the same source? see http://launchpadlibrarian.net/12799642/buildlog_ubuntu-hardy-i386.mono_1.2.6%2Bdfsg-6ubuntu2_FAILEDTOBUILD.txt.gz for example, only happens on x86/amd64/lpia
<doko> why doesn't mono use the system boehm-gc?
<slomo> doko: because of mono specific changes... one can build it with the system one but it's very unreliable then
<Kopfgeldjaeger> n8
<rhineheart_m> hello. is this bug has been fixed already and added to the repo? Bug #156748
<ubotu> Launchpad bug 156748 in iperf "Thread library bug for kernel >= 2.6.21" [Unknown,Fix released] https://launchpad.net/bugs/156748
#ubuntu-devel 2008-03-22
<slomo> slangasek: ok, mono should now build again (not my fault, was broken before :P ) on x86 and friends... could you care for give-backs of gnome-desktop-sharp2 and everything else that failed because of broken mono dependencies after things are working again? :)
<slangasek> slomo: you need a buildd admin for that
<slomo> doko: ^--- :)
<doko> slomo: what is "everything else"?
<doko> will do that tomorrow, if you could give some list
<slomo> doko: nothing else it seems... well, if i find something else i'll tell you. i thought f-spot or mono-tools could've failed too but they're fortunately still on dep-wait
<slomo> doko: so that's only gnome-desktop-sharp2
<cody-somerville> There might be a possible regression occurring with Hardy.
<cody-somerville> A few people have said that network-manage has quit working after the latest updates
<slangasek> nope, it quit working after the previousupdates
<slangasek> it works again with the latest updates
<cody-somerville> Okay
<cody-somerville> So Bug #204897 is Fix released?
<ubotu> Launchpad bug 204897 in network-manager "[hardy] Network manager causes CPU load to go to 100%" [Undecided,New] https://launchpad.net/bugs/204897
<slangasek> yes
<pwnguin> good to know
<sectech> My network manager just crashed and came back with a dup from bug #85113
<ubotu> Launchpad bug 85113 in network-manager "[apport] NetworkManager crashed with signal 5 in main()" [High,Fix released] https://launchpad.net/bugs/85113
<ScottK> sectech: That's correct.  The problem is in hal.  There's a new package that's been built and should show up on a mirror near you soon.
<sectech> There was a second update released for it
<sectech> ok
<sectech> Was your fix  0.5.11~rc2-1ubuntu2
<sectech> ?
<sectech> whoops... hal  0.5.11~rc2-1ubuntu2
<sectech> because that was the one that caused the report.... The version before was the one with the original regression
<slangasek> sectech: how have you determined that it's a duplicate of bug #85113?  I don't see that any new bugs have been marked as duplicates of that
<ubotu> Launchpad bug 85113 in network-manager "[apport] NetworkManager crashed with signal 5 in main()" [High,Fix released] https://launchpad.net/bugs/85113
<slangasek> and if it's not a duplicate, we probably need more information (such as a current backtrace) to track it down
<posingaspopular> hey all, im trying to open the source for _gobject.so, under/var/lib/python-support/python2.5/gtk-2.0/gobject, and when i run 'sudo gcc _gobject.so' i get a bunch of compiler errors
<posingaspopular> how can i open it to actually read/edit the file though
<slangasek> sorry, you're trying to do what?  the source is in the source package, not in /var/lib/python-support
<posingaspopular> hmm okay, where do i get the actual source then?
<posingaspopular> sorry im new to this
<slangasek> apt-get source python-gobject
<slangasek> but what do you plan to do with the source?
<posingaspopular> unable to find source package
<posingaspopular> im looking at a bug right now
<slangasek> then you need to add the right deb-src lines to your /etc/apt/sources.list
<posingaspopular> which ones?
<slangasek> you need a deb-src line for "main", corresponding to the deb lines for your mirror
<cody-somerville> posingaspopular, Applications > System > Software Sources
<cody-somerville> posingaspopular, Check off the source repositories
<posingaspopular> thanks cody
<slangasek> ITYM  System -> Administration -> Software Sources
<posingaspopular> either way, im running kde :P
<posingaspopular> http://paste.ubuntu-nl.org/60485/
<posingaspopular> it's not working
<slangasek> sudo apt-get update; sudo apt-get source python-gobject
<slangasek> is this about the "PySignal_SetWakeupFd" error in your blog?
<posingaspopular> yea
<posingaspopular> here are my sources list: http://paste.ubuntu-nl.org/60486/
<slangasek> which version of python-gobject do you have installed?  The current version doesn't appear to reference that symbol.
<keescook> mjg59: solved the libx86 issues.
<posingaspopular> hmm how do i check
<slangasek> apt-cache policy python-gobject
<mjg59> keescook: Really?
<keescook> mjg59: yup.
<mjg59> keescook: Please don't tell me it was just an updated x86emu :)
<keescook> yup
<mjg59> Gah. Misery.
<posingaspopular> version 2.1.4-2
<keescook> I extracted your patches (that took most of the time) and applied the updated x86emu
<mjg59> keescook: Well, update it and win :)
<mjg59> s/update/upload/
<keescook> mjg59: yup, doing final packaging now.
<mjg59> Ah well
<keescook> mjg59: I basically have 3 patches I extracted: 1 appears to be an ancient version of the inline asm calls, which I have left unapplied.
<mjg59> I blame cpuid
<keescook> cpuid or rdtsc
<keescook> 1 is the process memory patch
<mjg59> Hm. Yeah.
<keescook> and the other (the real nasty one that took me so long to find) was the "exit when CS==0 IP==0"
<slangasek> keescook: is "solved the libx86 issues" as momentous as it sounds? :)
<keescook> why is that in our x86emu but not upstream?
<keescook> slangasek: yeah, bug 147623
<slangasek> w00t
<slangasek> posingaspopular: 2.1.4-2 is not the current version; can you upgrade to 2.1.4-2ubuntu1 and see if that fixes it?
<slangasek> (I believe that it does)
<mjg59> keescook: Thanks for dealing with that!
<keescook> mjg59: you bet, it was kind of fun.  ironically, my friend's EDID-lacking BIOS still eludes me.
<keescook> mjg59: any thoughts on the extracted patches?  I'd like to understand the CS==0 IP==0 one at least
<mjg59> keescook: Oh! I think that's just to make sure that when we return, we immediately bail
<keescook> mjg59: without that, upslash freaks out pretty badly.  I'm curious why the lack of that difference isn't an issue for xorg
<mjg59> keescook: Yeah, not sure off-hand.
<posingaspopular> it works!
<posingaspopular> thanks slangasek
<mjg59> keescook: But the aim is certainly to ensure that there's a halt instruction when it exits
<keescook> slangasek: the debdiff for libx86 is rather sizeable -- should I just shove it in anyway?
<slangasek> keescook: is it all bugfixes? :)
<keescook> slangasek: in theory :)
<slangasek> heh
<slangasek> keescook: let's run it through an FFe so we know what we're getting
<keescook> I think people will scream loudly if there is a regression in it.  but at the very least, it should fix nvidia and possibly other cards.
<slangasek> right, but the people hitting the regression might not scream at just the right time
<keescook> slangasek: okay.  worst-case I can extract just the cpuid/rdtsc instruction additions.
<slangasek> posingaspopular: no problem
<sistpoty> keescook: the 8000er problem? \o/ feel free to abuse me as guinea pig ;)
<keescook> sistpoty: sweet.  I'll throw it in a PPA
<sistpoty> keescook: source is fine for me as well ;)
<mjg59> slangasek: It's basically entirely addition of emulated opcodes
<mjg59> slangasek: I can't see any issue with it
<keescook> sistpoty: I'll have a debdiff up shortly
<sistpoty> :)
<keescook> mjg59: well, I could extract _just_ those bits -- but since xorg was so different, this is actually a full refresh
<slangasek> mjg59: what does it currently do with opcodes it doesn't know how to emulate?
<keescook> aborts.  :P
<slangasek> ok, push it :)
<keescook> slangasek: err, no FFe?
 * keescook is hovering over "submit bug report" button
<slangasek> keescook: if the new code is just adding emulated opcodes, and unemulated opcodes cause an abort, I don't see how this can be a regression
<slangasek> so I'm fine with that being uploaded without an FFe
<keescook> slangasek: I would agree, if that's what I've got packaged presently.  what I have at the moment is a full refresh, which includes other fixes, re-arranged headers, etc.
<slangasek> ok, then go ahead and click submit and we'll look at it in more detail :)
<flipstar> hi, are there plans to integrate dmraid into the installer?
<keescook> slangasek, sistpoty: FFe for libx86 is 204936
<slangasek> cody-somerville: is there any sort of timeline for getting the xubuntu alternate CDs tested for release as a beta/
<cody-somerville> well
<cody-somerville> Sorry, the big bus that brings the testers is late.
 * cody-somerville shrugs.
<cody-somerville> slangasek, Unfortunately, I can't give any sort of timeline since I can't predict who is willing to volunteer to test and when.
 * sistpoty tests, brb
<cody-somerville> I'll send an e-mail off to xubuntu-devel to see if I can round up some people who aren't on IRC
<slangasek> ok
<slangasek> shall I just hold off on xubuntu daily rebuilds in the meantime?  (since turning them on means that these images may be aged out)
<slangasek> oh, these images have the broken hal, does that affect anything on xubuntu?
<sectech> slangasek,  The crash reporter stated it was a duplicate bug... I'm going to reboot to see if I can reproduce the problem, I'll try and provide more information if it happens again
<sectech> one minute
<cody-somerville> We use network-manager
<jono> has anyone had any network manager breakage when upgrading to the beta?
<slangasek> jono: it was a post-beta breakage, should be fixed now in hal -1ubuntu2
<slangasek> jono: if not, we need more info, because it's fixed for some people
<jono> slangasek: ok, dist-upgrading now
<slangasek> cody-somerville: ok, then let me reroll the images /again/, so you get a working n-m :)
<slangasek> sectech: quick reboot, how's it look?
<sectech> I just rebooted but was unable to reproduce the error from network-manager.   It looks like everything is okay
<slangasek> sectech: ok, thanks :)
<sectech> thank you for the quick fix :)
<slangasek> if it does show up again, please file a bug report; even if it gets marked as a duplicate, it may still give us new information (such as version numbers, etc)
<sectech> okay sounds good
<keescook> oh, whoops -- I had two checkouts of xorg...
<mjg59> slangasek: In principle, it gives a failure. However, I suspect that cpuid was giving it something that gave /an/ answer, just not one that made sense to the BIOS
<jono> slangasek: have some pretty significant b0rkage here
<sistpoty> keescook: works for me \o/... however there's quite some flickering in usplash and tty1 contains lots of assembly now
<jono> slangasek: firstly, I have two kernels -12 and -14 - I need -14 to even see my wireless interfaces, and NetworkManager allows me to manually set the wireless interface but can't enable it
<jono> also, the -12 kernel is booting as the default instead of the -14 which seems odd
<sistpoty> keescook: also unrelated (since my update of today), my monitor says no signal, when having usplash not installed
<sistpoty> s/update/upgrade/
<keescook> sistpoty: can you capture the output?  I was missing an options in the previous debdiff.  Can you try the new one?
<keescook> s/an options/an instruction/
<sistpoty> keescook: sure
<sistpoty> (give me a sec)
<jono> are these network manager issues known with the beta?
<sistpoty> keescook: is there any log where the output might be stored? (if not, I've just taken a photo *g*)
<keescook> photo works -- you can also just run "usplash -c -v" manually as root and capture stdout/stderr
<keescook> slangasek: I've extracted just the new instructions from upstream, not the whole mess of everything.  this fixes it too -- however, an interesting side effect (that sistpoty has already seen) is that switching to a console vt ... doesn't work.  it needs to do a POST, it seems.
<keescook> slangasek: (at least on gutsy)
<jono> ok I have to get to bed
<jono> night all
<sistpoty> gn8 jono
<keescook> mjg59: possible regression is putting the video card in a _worse_ state.  :P
<sistpoty> keescook: http://www.potyra.de/vt1.photo.jpg
<keescook> hrm, fun.
 * keescook goes looking for where he missed the debug output
<keescook> sistpoty: I've got yet-another-patch to try (same bug).  This one is a minimal debdiff with only the new opcodes.
<sistpoty> keescook: ok, rebuilding
<sistpoty> keescook, slangasek: should I add my findings to the bug report for documentation, or should I rather not clutter it?
<sistpoty> (as /me dislikes cluttered FFe's for universe *g*)
<keescook> sistpoty: if the 3rd one behaves the same, then document it.  I'll invalid the FFe if the third one fixes it sanely for you.
<sistpoty> ok
<sistpoty> brb ;)
<keescook> aaaah, upstream changes made debug sane, and thunk.c still had it enabled.
 * keescook holds his breath
<sistpoty> keescook: 3rd one still works, but tty1 is cluttered with assembly as well
<keescook> sistpoty: okay, I think I tracked down the cause of the clutter, but I'm curious why I don't see it on my system.  :P
<sistpoty> keescook: should usplash display some text? (the first one did, but I was bitten by a fsck then)
<sistpoty> heh
<keescook> sistpoty: not unless you have "quiet" removed from your boot arguments
<sistpoty> ah, k
<sistpoty> keescook: if it helps, I've got a "VGA compatible controller: nVidia Corporation GeForce 8500 GT (rev a1) (prog-if 00 [VGA controller])" (amd64x2, not too sure what's interesting from cpuinfo ;)
<keescook> mostly I'm just scratching my head over why I don't get debug output on my system.
<keescook> oh!
<sistpoty> keescook: hm.. I've installed the kubuntu usplash thingy, and am running kdm
<sistpoty> (and I'm usually one day behind with updates, since I use a german mirror)
<keescook> yeah, it's all self-contained in libx86 -- it's just weird.
<keescook> sistpoty: what were you saying earlier about "no video signal" ?
<sistpoty> keescook: if I don't have usplash installed, I don't get a video signal until kdm starts (since an earlier upgrade from this afternoon already, so I guess it's unrelated to libx86)
<sistpoty> might be just, that my monitor doesn't support a specific mode though
<keescook> sistpoty: hm, i'm seeing an identical situation in my test system -- once x starts, I can't switch to a vt
<keescook> or, I can, it's just "no video signal"
<keescook> hmpf
<sistpoty> keescook: no, once X starts, I *can* switch to a VT when not having usplash installed, but not before that
<keescook> sistpoty: and if you have usplash installed, you can switch to/from X okay?
<keescook> (this may be simple an issue with the gutsy nvidia driver -- my test machine isn't hardy)
<sistpoty> keescook: yes, seems like it doesn't matter if I have usplash installed for that behaviour
<keescook> okay, then I don't think there's a regression.  now, the spewing of asm instructions to your console -- is it actually visible?
<keescook> (during boot?)
<sistpoty> keescook: not during boot, only when switching to it afterwards
<keescook> okay, that sounds something we can fix later.  ;)
<sistpoty> yes, right now it's still a big improvement.. (and interestingly, when usplash starts, I can see text on my monitor, so I guess switching to tty's would work then, in contrast to not having usplash installed ;)
<keescook> hahah true
<superm1> what's this big regression that you've been working on exactly keescook ?
<keescook> slangasek: okay, sounds like the minimal "only new instructions plus fixes for busted ones" patch is sane.
<keescook> superm1: bug 147623 (not a regression, but missing usplash on 64bit nvidia)
<superm1> ah
<keescook> slangasek: okay to upload it?
<keescook> slangasek: based on your earlier "I'm okay with only new opcodes", I'll upload it (and mark the FFe invalid -- I'll upload that bundle for intrepid)
<j1mc> slangasek: do you have an ETA on when cody somerville's re-rolled xubuntu-alternate ISO may be ready?
<YokoZar> Could someone please retag this bug to much higher priority than low?  It resulted in data loss for me: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-utils/+bug/194127
<ubotu> Launchpad bug 194127 in gnome-utils "gnome-screenshot closes when chosing not to overwrite an existing file" [Unknown,Confirmed]
 * ScottK2 looks
<ScottK2> YokoZar: Please comment to that effect in the bug.
<YokoZar> I lost my screenshot as a result, since the window had changed
<YokoZar> Sure.  It's sort of in the first comment though
<YokoZar> ScottK2: how do I get triage permissions, btw?
<ScottK2> I think you have to be a member of one of the bug triage teams.  MOTU will get it for you or you can talk to bdmurray in #ubuntu-bugs if you don't have to wait.
<YokoZar> I'll wait a bit then to see if this MOTU thing happens :)  I guess being an Ubuntu member doesn't give it by default.
<ScottK2> No.  IIRC it's ubuntu-qa you have to be in.
<ScottK2> YokoZar: Is this a regression do you think?
<mjg59> keescook: Yeah, make sure the debug enabling code doesn't end up in the distro :)
<mjg59> keescook: Any text output should be fatal in the non-debug build...
<YokoZar> ScottK2: no I think this bug has been that way since gutsy at least...probably earlier
<ScottK2> OK.  I made it medium.  If it'd been a regression I'd have gone for high.
<mneptok> may the next month not require a more empty ban list. amen.
<pwnguin> what?
<pwnguin> that very closely skirts "double negative" territory
<mneptok> as all good religion does.
<sudobash> yeah i didnt follow that but its cool that you are removing bans
<sudobash> remove mine from Ubuntu and Ubuntu-ops
<sudobash> please
<mneptok> he leaves after i try to find the op that banned him.
<mneptok> hrmf. children. ALL OF YOU OFF MY LAWN!
 * LaserJock streaks across mneptok's yard
 * mneptok waves his fist impotently, in bermuda shorts and black dress socks
<slangasek> they have pills now to help with fist impotence, you know
<slangasek> or "fistile dysfunction", as they say in the biz
<mneptok> AND STAY OFF!
<slangasek> heh
 * mneptok goes back to his stories and gin
<mneptok> ok, no i don't
<keescook> mjg59: that's the part I don't understand -- the diff between what I uploaded and what was already uploaded contains no changes to debugging.  (perhaps sistpoty was already using a debug-enabled one?)
<keescook> mjg59: I haven't seen the output in my tests.
<keescook> mjg59: btw, doesn't an update of libx86 require a update-initramfs run?
<keescook> (I could just version-bump usplash....)
 * pwnguin has a question about deb tarballs versus the .diff
<pwnguin> if you upgrade a package to a new svn revision from upstream, does that go in as a new tarball or a large .diff?
<cq> where is the transition from the debian to ubuntu archives controlled, i.e. which debian packages make it over and which don't?
<pwnguin> cq: partly, its a matter of the schedule. new packages can come in up until the appropriate freeze, after which there's only exceptional circumstances allowed. but i imagine you're curious about the automated part
<cq> no, actually the process... do you take stable or testing, and then freeze it for a release, and rinse, lather, repeat?
<pwnguin> you're close
<pwnguin> the process is branch unstable where appropriate
<pwnguin> then try to stablize that code with various freezes
<pwnguin> during that time bugs are filed, patches are applied, etc
<cq> ok. so the changes between 7.10 and 8.04 are a whole bunch, depending on what got taken and frozen
<pwnguin> can be
<pwnguin> and in whole, absolutely different
<pwnguin> if no changes come in in six months, that's either  a pretty stable program or a pretty stagnant one
<cq> and how do kubuntu and ubunto differ, kubuntu sits on ubuntu with a different installer and KDE, or is there more?
<pwnguin> at this junction, kubuntu is a set of packages and an installer within ubuntu repos, no different than say ubuntu-server
<pwnguin> originally, it was a small community formed in protest to the decision to select gnome formally ;)
<cq> lol ... the usual free software discussions :)
<pwnguin> right, and the usual free software response: more software :)
<cq> isn't it possible to make ubuntu a subset of debian the way kubuntu is a set of packages?
<cq> or is the process to get stuff into debian too long, or is ubunto too different in installation?
<pwnguin> ubuntu orginated as a fork of debian for many reasons, and this is starting to veer away from -devel related topics
<cq> I'm just interested in teh technical ones, not the political ones...
<cq> politics takes too much time :)
<pwnguin> well
<pwnguin> heh, precisely
<cq> i mean, ubuntu feeds stuff back upstream to debian as far as I know
<pwnguin> the basic problem with debian that I, having no formal relationship or status within Ubuntu, is that debian is slow and adversarial
<pwnguin> rather than attempt to change from within, i think ubuntu has set forth a few good examples of how to do things better socially
<cq> man what a lot of distributions... just looking at what distributions are around.
<pwnguin> theres a lot of different kinds of people out there
<pwnguin> cq: as an example of the difficulties with merging ubuntu back, imagine a scenario where you'l like a patch included as an ubuntu developer, but the debian developer who owns the package disagrees
<pwnguin> you can go further upstream
<cq> just leaves me wondering where linux would be with 50% less distributions...
<pwnguin> it'd be without a flagship USB drive distro, and a ps3 distro, and a build from scratch distro, and a handicap accessible distro, and a forensics distro
<pwnguin> and a live cd distro
<cq> ...but probably a lot closer to the desktop
<cq> i guess the splinter experiments are necessary to show the big ones what to integrate
<pwnguin> thats a pretty huge sacrifice
<cq> yeah
<pwnguin> if you look at the millions apple's spent in the name of marketshare, i'd say throwing all that away in the name of unity is silly.
<slomo_> doko: when you're back you could give-back gnome-desktop-sharp2 where it failed, i.e. sparc and powerpc and ia64
<superm1> the splinter experiments are appropriate for some corner cases though.  it's the ones that try to re-invent the window and have a better "desktop" OS that hurt
<pwnguin> heh, there should be some disclosure here
<pwnguin> superm1 works on mythbuntu ;)
<superm1> hehe :)
<pwnguin> speaking of which, i demand joystick support!
<superm1> well but i mean all our development happens in ubuntu though, so we don't do too much harm
<superm1> its in
<persia> superm1: If you get joystick support, could you also do remote control support for games?
<cq> that's what I  mean though, if you get a good base that's configurable, then you need less splinters and the whole thingmoves faster
<superm1> well joystick support works, remote control support in games is a challenge to be honest though
<superm1> depends on how you have your remote configured if it would be even considered to be possible at this point
<persia> How did you do joystick support?  Separate driver support, or merge of Lirc and /dev/input ?
<cq> if all you do is change package groups etc. and feed everything back, great.
<pwnguin> honestly, i havent tested joystick support since the backport
<superm1> persia, the joystick support works off a normal X input device
<superm1> well not even X
<superm1> just /dev/jsX
<superm1> should have said
<pwnguin> cq: ubuntu distinguishes itself from debian by embracing, rather than hiding, from users, and predictable release cycles
<persia> Ah, but lirc is still separate?  That's what I thought, and was wildly excited for a brief period.
<superm1> yeah lirc is still separate.  quite the little bastard kid too
<pwnguin> personally, i'd just as soon use a wiimote
<superm1> i'm hopefully going to try to triage a bunch of its offspring bugs tomorrow
<superm1> not enough buttons on it to be useful
<persia> Always good to prune the orchard :)
<cq> does ubuntu run on all the systems debian runs on? or is it more focused on the core PC systems
<pwnguin> cq: oh, debian still has more arch ports
<pwnguin> persia: how many buttons would you need to be useful?
<persia> pwnguin: I have four input devices with over 100, and I'm still not happy :p (but I think you didn't mean to ask me)
<superm1> pwnguin, you mean to direct that at me ?
<pwnguin> ah, yes
<superm1> pwnguin, 2x vol, 2x chan, play/pause, stop,ff,rr,skip+,skip-, esc
<pwnguin> 2x volume?
<superm1> vol+/vol-
<superm1> stop and esc can be combined
<superm1> so that's 10 buttons to be useful for me
<superm1> well and up/down/left/right of course
<superm1> 14 :)
<persia> 10?  I count 11 (or 15)
<pwnguin> the wiimote itself has 11 plus extensions
<superm1> play/pause is one
<superm1> pwnguin, but they're hardly intuitive however you spin it
<pwnguin> home = esc seems reasonable
<persia> Ah.  Right.
<superm1> okay so arrows = arrows, +/- = either vol +/-, 1/2 is chan+/-, but then you still have all the skips
<superm1> and the play pause
<cq> http://distrowatch.com/dwres.php?resource=major seems like a good distro comparison
<pwnguin> what are the arrows for?
<superm1> menus
<pwnguin> shouldnt that be seperate?
<superm1> you mean external controller?
<pwnguin> no, i mean, menu controls seperate from mplayer controls ;)
<superm1> oh i'm saying mythtv controls, not mplayer controls
<pwnguin> well, im still using mplayer for playback
<pwnguin> no tvtuner
<superm1> with 0.21, the internal player is fairly nice.  don't necessarily need to call an external player for stuff
<pwnguin> what do the arrows do with the internal player?
<superm1> large skips
<superm1> and if you hit menu to choose menu stuff
<pwnguin> i think you could define a set of contexts wherein 10 or 11 buttons would work
<pwnguin> but right now, wminput needs work first
<superm1> i see.  well if you come up with a good layout, i'll pair one of my wiimotes and give it a shot some day
<superm1> :)
<pwnguin> no need to pair
<pwnguin> just turn off the wii and hit 1+2
<superm1> its a standard BT device?
<pwnguin> yea
<superm1> it doesnt need to pair?
<pwnguin> you can tell it to be promiscous
<superm1> oh neat
<superm1> well that's far more useful then
<superm1> i didn't like the idea of having to pair back and forth between the two
<pwnguin> lemme have a look at my current binding
<pwnguin> it's not the greatest
<pwnguin> but it passes for navigation so far
<superm1> well i can't test until at least early next week anyhow.  my little usb/bt adapter for pc is in the office
<pwnguin> the thing to watch out for is that wminput doesn't set lights
<pwnguin> or disconnect on long idle sessions
<pwnguin> or handle multiple wiimotes readily yet. and it seems to crash on daemon mode for me on the mythbox
<pwnguin> but not on my desktop
<pwnguin> i guess what im saying is patches welcome ;)
<superm1> hehe
<cq> cannot remove /var/lib/apt/lists/lock: read only filesystem  huh??
<cq> I have one huge partition, and it's mounted RO for some reason... any ideas?
<slangasek> check dmesg for signs of a kernel problem
<slangasek> (kernel/disk)
<cq> argh.
<cq> had that yesterday. "attempt to access beyond end of device".  just did a clean reintsall, still there
<cq> memory check was OK... ran that yesterday too
<cq> would a fsck solve that problem, or is that a disk or other hardware problem?
<TomaszD> pitti, langpack update? Please?
<slangasek> cq: I don't know; "attempt to access beyond end of device" could mean that the filesystem and the partition table don't agree about the size of the disk
<slangasek> it could mean your hardware has problems accessing very large disks, if this is a new disk?
<slangasek> (in an old system)
<cq> hm. system is a few years old, not sure how old, disk is 30GB and newer.
<cq> fujitsu siemens amilo k 7600
<cq> would reinstalling to a smaller partition, say 8gb help?
<cq> and use the other one as a user partition?
<pwnguin> fg
<YokoZar> Do packages pushed to ppa have to have source in tar.gz format, or can I have orig.tar.bz2?
<cq> or how can I test if the HD works with the machine?
<persia> YokoZar: You may get a better answer to that in #launchpad
<YokoZar> persia: do you know of any source restrictions for officially uploaded packages?
<persia> I know almost nothing about launchpad internals
<pitti> TomaszD: tonight we'll get the latest Rosetta export, and tomorrow early morning the cronjob will build and upload them
<TomaszD> pitti, ok
<pitti> mjg59: ah, that sounds easy enough; thanks
<Festor> Hi all
<Festor> Does anyone know why the command update-mozilla-firefox-chrome is not available in beta 4 of firefox 3?
<Festor> I am in the beta of Hardy now
<pitti> slangasek: thanks for cleaning up after me (hal)
<doko> gnome-desktop-sharp2 given back
<doko> slomo_: ^^^
<slomo_> thanks :)
<slomo_> slangasek: if you're awake, can you get the gnome-desktop-sharp2 binary packages accepted from binary NEW? they're finally built on all archs and two packages from main are waiting for it (or more specific libgtkhtml3.16-cil)
<Festor> Is there anyone ...?
<slomo_> pitti: or you? :)
<pitti> slomo_: me?
<pitti> ah
<pitti> looking
<slomo_> you can move gtkhtml3.8 out of main afterwards iirc
<pitti> yay
<pitti> slomo_: hm, why didn't it build on i386?
<pitti> NEW only has sparc, ia64, and powerpc
<slomo_> pitti:  	 buildlog_ubuntu-hardy-i386.gnome-desktop-sharp2_2.20.1-2ubuntu2_FULLYBUILT.txt.gz
<slomo_> it has :)
<slomo_> but that was last night
<pitti> ah, they are already NEWed
<slomo_> pitti: oh, since when? because f-spot, mono-tools and gnome-rdp are still on dep-wait (hm, MANUALDEPWAIT it says, does this need manual intervention?)
<pitti> hm, pretty weird actually
<pitti> https://edge.launchpad.net/ubuntu/+source/gnome-desktop-sharp2/2.20.1-2ubuntu2 shows them as DONE
<pitti> but they are not in the archive
<pitti> slomo_: accepted the ports arches from NEW
<pitti> slomo_: I see the .deb on drescher, though; maybe it was just NEWed some 30 minutes ago, and currently being published
<slomo_> ok
<lool> Cool, gold released
<lool> http://sourceware.org/ml/binutils/2008-03/msg00162.html
 * Hobbsee looks for when uds starts
<Hobbsee> oh, may, 2 months away
<zul> hey Hobbsee
<Hobbsee> hi zul
<Festor> jdong, are you here?
<delfick> hello. I just tried compiling this here https://bugs.launchpad.net/ubuntu/hardy/+source/sane-backends-extras/1.0.18.12 (released an hour ago) and got these errors http://paste.ubuntu-nl.org/60522/
<_MMA_> Hmm....On the SANE subject, I cannot open any of the devices seen buy it. Tells me they're all busy. Grr...
<stgraber> my network scanner worked fine last I tried, but the server which it's attached to isn't running hardy only clients are
<_MMA_> stgraber: Yeah. I bought a 8 year old flatbed because I knew it fully worked. Worked under Hardy 2 days ago. Not today. :( Everything that I can pick through the SANE dialog wont. Webcam either.
<mjg59> keescook: Hm. Yeah, I guess so.
<slomo_> doko: about libffi... what's the -dev package exactly called? pygobject b-d on libffi-dev, is that fine? if so you can request binNMUs for pygobject, totem and rhythmbox at least (the last two dep-wait on the binNMU of pygobject)
<doko> slomo_: hmm, well, yes, hope somebody does ...
<slomo_> doko: so... libffi-dev 3.0.4-1 is the new thing?
<doko> slomo_: yes
<slomo_> doko: ok, so that essentially means: pygobject binNMU and binNMU of all rdepends of pygobject that depend on libffi4... good
<doko> slomo_: how is this ubuntu related? ;-p
<slomo_> doko: not at all, but you're here ;)
<ion_> seb128: Oh dear. The archive backend in gvfs would have been sooo awesome. I take it there's absolutely no way to get libarchive to main?
<seb128> ion_: what are you speaking about?
<seb128> ion_: did you read the "for now" in the changelog entry?
<seb128> ion_: there is no such hurry that I should start annoying people during a weekend and holidays to get libarchive promoted right now, that will wait for next week
<ion_> seb128: Alright
<seb128> ion_: you are welcome to write the mir bug if you want to get it quickly though ;-)
<ion_> No hurry, just something that would be really nice to have, perhaps even as a default unpacker.
<seb128> ion_: the code is really new and not tested, I doubt than making it the default for anything now would be a good idea
<ion_> Ok
<seb128> ion_: we will likely use it to allow to browse iso for examples which is is not possible right now but that's about it
<ScottK2> doko: Is the python component of gnome-menus really significant enough to warrant it being in Pythoneers?  I seem to get a lot of non-Python bugmail on that package (being a KDE user, I really don't know anything about that package).
<doko> ScottK: maybe not, but I've still a report about it pending in python-central
<ScottK2> OK.  Just thought I'd mention it.
 * ScottK2 finds it somewhat distracting, but I ignore enough bugmail as it is, I little more isn't a major burden.
<slomo_> doko: the mono-CPPFLAGS issue is fixed in svn now btw :)
<doko> \o/
<slomo_> slangasek: present for you, mono-tools builds now too :)
<jono> hey
<jono> has anyone had any network manager problems with the beta?
<stgraber> jono: like eating all your CPU ?
<jono> stgraber: networking brokewn
<jono> my wirless interface doesnt seem to work anymore
<stgraber> there was a problem with NM entering an infinite loop when starting wireless but that was yesterday and was fixed by the new hal
<stgraber> so your issue is probably another bug
<jono> also - there seems to be two kernels on my system and the older one is booting
<jono> any idea about that?
<superm1> jono, somehow a -386 and a -generic?
<jono> superm1: I have versins -12 and -14
<superm1> oh
<stgraber> AFAIK only -12 isn't complete yet (miss the module packages)
<jono> so I should use -12?
<jono> werm
<jono> -14?
<stgraber> erk, I meant -14
<stgraber> so you should use -12
<superm1> i dont see a -14 in apt.  is it 2.6.24-14-generic?
<jono> so I should use -12?
<stgraber> superm1: I don't see it either on amd64 but saw linux-source uploaded last week
<superm1> ah
<jono> ok, let me test -12 again
<jono> its odd - I see three Wired network interfaces
<jono> no wireless interfaces
<jono> I have this thing called wlan0_rename
<jono> any idea what that is?
<seb128> that's the one you should be using
<jono> seb128: it says eth0 ad eth1 have no wireless extensions
<seb128> use the wlan0_rename
<seb128> it's udev doing the renaming or something
<jono> but in the NM manual config - it lists Wired connecton, Wired connecton, wired connection and Point to point connection
<jono> seb128: any idea what it could be?
<seb128> no
<jono> ok, will file a bug
<mbt> Heya... does anyone know if there is a reason that the "bitchx" package is missing from Hardy?
<johanbr> jono: Sounds like an old udev bug (that I thought was fixed?).
<jono> johanbr: any way I can check?
<johanbr> jono: You can try moving /etc/udev/rules.d/70-persistent-net.rules out of the way. It should be regenerated, and if you're lucky that'll fix your bug.
<johanbr> Do you have a Broadcom card, by any chance?
<jono> nopew
<jono> johanbr: so I need to reboot after moiving that udev rule?
<johanbr> yes
<jono> ok doing so
<jono> lets see if this works
 * _MMA_ is having a issue with SANE between Alhpa6 and Beta where SANE tells me all my devices are busy. I don't know if it's a SANE or underlying system issue. :-/
<jono> johanbr: no change
<johanbr> jono: Okay, then it may be a bug slightly different from the one I was thinking of, but one that manifests itself in the same way.
<johanbr> Can you connect with the wlan0_rename interface?
<jono> johanbr: let me try
<jono> nope, and I now have no option to Enable Wirless since I renamed that udev rule
<johanbr> jono: But it did regenerate the file? Maybe you should move the old one back in any case. And file a bug, I guess.
<jono> johanbr: it did re-generate it
<jono> will move it back
<jono> hmm in gutsy I needed a restricted driver for this card
<jono> but it is not listed in restricted manager here
<johanbr> What kind of card is it?
<jono> not sure - its the intel card in the Dell XPS1330
<jono> sorry, the M1330
<johanbr> That's normal, I think it uses the iwl driver now.
<jono> right
<jono> johanbr: see https://bugs.edge.launchpad.net/ubuntu/+bug/205215
<ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New]
<jono> ahh :)
<johanbr> jono: Discovered something?
<jono> no
<jono> just ubutu showing my bug description :)
<johanbr> jono: Can you attach the output of "ifconfig -a" and "iwconfig" to the bug?
<jono> ok - one sec, will need to put it on a usb keyring
<jono> johanbr: ok, bug updated - https://bugs.edge.launchpad.net/ubuntu/+bug/205215
<ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New]
<johanbr> jono: Alright. Looks like wlan0_rename is your real wlan interface and eth1 is the master interface that goes along with it. This is probably caused by a bug in the udev scripts.
<jono> johanbr: right
<jono> johanbr: is there anything else I can do to help fix this?
<johanbr> jono: Maybe also attach the contents of 70-persistent-net.rules. I'm not sure why you can't connect, though. This bug should just be cosmetic.
<jono> johanbr: will do, what do you mean by cosmetic?
<johanbr> That apart from your interfaces having weird names, it shouldn't hurt anything.
<johanbr> Your connection problem may be a separate issue.
<jono> right
<jono> johanbr: see https://bugs.edge.launchpad.net/ubuntu/+bug/205215 no
<jono> now
<ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New]
<jono> added the udev bits
<jono> and some details of the network card
<xhaker> jono: bug 205215 i've just commented
<ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New] https://launchpad.net/bugs/205215
<xhaker> jono: you also do not need a restricted driver since the driver for 3945 no longer needs the binary only daemon from the previous driver ipw3945
<jono> xhaker: will try editing the file now
<xhaker> jono: it should work after that, but someone needs to do some migration script
<nosrednaekim> hey, is there someone here who is familiar with the system-config-printer code?
<slangasek> pitti: no problem :)
<slangasek> slomo_: mono-tools> nice, thanks :)
<slangasek> jono: there is no 2.6.24-14 kernel in the archive, what exactly are the kernel versions you're seeing on your machine?
<ion_> Wow, sabdfl has apparently been funding GEGL development. Awesome.
<sebbar> hi, is there a reason why xv isn't in the repositories?
<sistpoty> sebbar: imo it was removed from unstable ages ago, so we followed debian there
<sebbar> sistpoty: hm that's a pity, I think it still has quite a user base (at least it's the standard tool at my university...)
<mjg59> There were distribution issues
<sistpoty> doko: can you give back hslogger on sparc? Thanks!
<doko> sistpoty: done
<sistpoty> thanks!
<laga> slangasek: can you enlighten me how to tell d-i (or whatever is responsible on the alternate disks) to install a udeb?
<slangasek> laga: is this a udeb that you're including on a CD?
<laga> slangasek: yes.
<slangasek> laga: do you want it installed unconditionally?
<laga> slangasek: no.. only when the users chooses it in gfxboot. we've already got the part in place (copied from LTSP). that's our current preseed: http://www.pastebin.ca/953113
<laga> (although i have noticed that mythbuntu-client-builder/run is the wrong template name, maybe it'll work automagically once it's fixed? i have *no clue* how d-i works)
<slangasek> laga: hmm, that's more complicated than I was thinking
<laga> slangasek: i think LTSP is doing the same with ltsp-client-builder. i just dont know how they do it
<slangasek> I don't either
<laga> i'll have to bug ogra then..
<superm1> well maybe at least get the template fixed right now
<superm1> and see if that resolves it
<slangasek> I would be inclined to just make the udeb a priority: standard udeb, and give it a postinst that only triggers based on the preseeded values
<laga> slangasek: okay. and how do you make it so it gets installed?
<slangasek> laga: if it's to be installed unconditionally, you can do that just by setting the udeb package priority right
<slangasek> i.e., Priority: standard
<bigon> does somebody know who is in charge for calling external thumbnailers on gnome? nautilus?
<sistpoty> doko: I guess you don't have a quick fix to the build failure of atlas on i386 as well (https://launchpad.net/ubuntu/+source/atlas/3.6.0-21.1ubuntu2/+build/510163)... If not, I'll upload a version, which simply doesn't bail out on failed tests, though I know that's not fixing the real bug :(
<sistpoty> (of course any good advice would be highly appreciated as well ;)
<doko> sistpoty: I don't care that much, of course if you could get a working 3.8 into hardy, that would be even better
<doko> but kmap already tried, it's non-trivial
<sistpoty> doko: I doubt I have the skills to do so... atlas is a beast for me
<doko> not just for you
<lamont> do we still support 486 machines, or is pentium the new bottom-class machine?
<sistpoty> heh
<doko> lamont: yeah, we should drop that for hardy+1
<lamont> doko: meh.
<lamont> they're still nice machines...
<lamont> and fast with no fans :-)
<doko> lamont: and please fix gcj for hppa ;-p
 * lamont tries to remember which of the languages he doesn't know is implemented by gcj
<sistpoty> lamont: do 486 machines exist with enough mem to actually install hardy? I know that p5 exist with large mem, but 486?
<slangasek> I was going to joke that it was the "GNU compiler for Japanese", but then I remembered
<Nafallo> slangasek: not that big difference or what? ;-)
<slangasek> Nafallo: that fails the "that lamont doesn't know" criterion
<lamont> slangasek: heh
<Nafallo> :-)
<lamont> sistpoty: nfc.  I think I have one out in the shed - maybe I'll give it a go
<lamont> minimal install, of course.
<ion_> What's a typical amount of memory for a "high-end" 486 box? 32 MiB? I think that should be enough for hardy (that is, ubuntu-{minimal,standard} installed)
<doko> no, we should just have 686 as the default for hardy+1
<Nafallo> doko: agreed
<doko> anything else should be built as an embedded target
<lamont> it's also possible that gcj is one of the packages blocked on waiting for debian to switch over to nptl so that enough people care that the (alleged) bugs in hppa's nptl impl get sorted.
<ion_> At least 64 MiB is far more than enough. :-) (Running on a laptop with 64 MiB of RAM right now)
<sistpoty> ion_: I tried imo dapper once with an 8mb laptop. I stopped, after locales generation wasn't finished after a night ;)
<ion_> Hehe
<lamont> doko: what I need is a small and simple test program that reliably fails.  gcj doesn't fit the "small and simple" criteria.
<doko> lamont: a HelloWorld.java does fail
<lamont> also not exactly "small and simple" once it drags in the jre.
<doko> lamont: yeah, but apparently *this* is the problem. the testsuite itself looks ok
<lamont> doko: there should be a porter machine for hppa sometime soonish
<doko> lamont: that would be cool, although I do offer my A500 to everyone who wants to have access
<lamont> cool
<ion_> My brain has been hardwired to expand "A500" as "Amiga 500".
<doko> your brain is likely to fail ...
<lamont> ion_: doko has that m68k hppa emulator running there
<ion_> lamont: :-)
 * lamont undertakes to understand why gnome-screensaver needs to have read access to /var/lib/misc/shadow.db when 'db' is present in nsswitch.conf
<doko> I refuse to setup this beast on amd64 as well ,-p
<lamont> because, well, that's stupid
<lamont> and making gnome-screensaver run sgid shadow doesn't help, since it politely throws away all its privs, or some such
<jdong> ah, beautiful bug
<jdong> networkmanager CPU-spins connecting to a WPA2 network
 * lamont ultimately just files bug 205345
<ubotu> Launchpad bug 205345 in gnome-screensaver "if passwords are in nss 'db', gnome-screensaver requires world read access to shadow.db" [Undecided,New] https://launchpad.net/bugs/205345
#ubuntu-devel 2008-03-23
<slangasek> lamont: are your permissions on /var/lib/misc/shadow.db different than your perms on /etc/shadow?  Does /sbin/unix_chkpwd have appropriate s[ug]id bits for reading both?
<lamont> ls -l /etc/shadow /var/lib/misc/shadow.db
<lamont> -rw-r----- 1 root root   1454 2008-03-17 12:28 /etc/shadow
<lamont> -rw-r----- 1 root shadow 8192 2008-03-17 06:01 /var/lib/misc/shadow.db
<lamont> ls -l /sbin/unix_chkpwd
<lamont> -rwxr-s--- 1 root shadow 21216 2007-10-01 12:49 /sbin/unix_chkpwd
<lamont> that's in the mode where I get to login on another vt and kill the screensaver.. :-)
<lamont> slangasek: oh, and I've only confirmed this on gutsy, btw... :-(
<StevenK> lamont: I note my /etc/shadow isn't root:root
<lamont> StevenK: what is it?
<StevenK> lamont: root:shadow, like /var/lib/misc/shadow.db
<lamont> interestingly, it's root:shadow on some other boxen... hrm
<StevenK> It isn't Gutsy, it's that install? :-)
<lamont> well, making /etc/shadow root:shadow didn't change the fact that it wouldn't unlock
 * lamont brb
<slangasek> lamont: er, so why are other users not allowed to execute unix_chkpwd?
<slangasek> that's brokez0r
<slangasek> and not the permissions shipped in the package in gutsy
<StevenK> Hey, yeah. That doesn't help either.
<slangasek> rather, it's specifically what breaks it
<slangasek> jdong: what version of hal do you have installed?
<lamont> meh.
 * lamont goes to close his bug as invalid
<slangasek> hurray! :)
<lamont> there is a certain wrongness in closing one's own bugs as PEBCAK
<slangasek> so how did the perms end up that way, exactly? :)
<lamont> iz long storry
<lamont> nothing like filing a bug to get educated. :-)
<Fujitsu> Can somebody please give back ikiwiki?
<brazil> hi - mobile-player_0.4_all.deb and mobile-application-service_0.9-5_i386.deb in hardy universe have 10 extra bytes over what the Packages file says, and the md5s don't match. Who should this be reported to?
<Fujitsu> I thought they fixed that.
<brazil> I'm using archive.ubuntu.com (was using uk at first)
<brazil> have run multiple times, checked by hand etc.
<Fujitsu> It must have unfixed itself, I guess.
<Nafallo> ehrm... isn't uk the same one?
<brazil> I get different IPs
<Fujitsu> a.u.c has several.
<brazil> hmm - there's 3 IPs for archive - let me try each
<StevenK> uk.archive != archive
<Nafallo> oh. uk is gb :-)
<Nafallo> didn't know that one was mapped :-P
<StevenK> *.archive.ubuntu.com is, actually
<Nafallo> StevenK: yea, which was why I was surprised uk was mapped to gb :-)
<brazil> .31 .45 and .46 are all bad
<StevenK> Do they actually download via apt-get?
<brazil> I'm using reprepro to build a hardy mirror
<astheglorious> hey peeps
<astheglorious> how's it hanging
<brazil> so who needs to be told about this to get it fixed up?
<astheglorious> I have no idea
<adrian2002ca> so how do i get started developing...im a pretty good programmer, pretty new to ubuntu(a month)...ive looked at the wiki and I still don't know how to get an <experienced developer to help me along>
<elkbuntu_> Adri2000, #ubuntu-motu is a better place to ask :)
<adrian2002ca> okey-dokey :P
<emgent> heya people
<sladen> iwl3945 b0rkage
<jdong> slangasek: whatever's latest on Hardy as of 48 hrs ago
<xhaker> Hobbsee: could you please reupload your ubuntu-restricted-extras
<xhaker> Hobbsee: now with open-jdk-6
<slangasek> jdong: then you probably have the broken hal installed, please see my follow-up to the n-m bug
<jdong> slangasek: ah, ok, so I need to catch-22 a new hal :)
<jdong> I'll deal with that
<slangasek> yeah, not a nice thing to have hit the archive the day after beta :/
<slangasek> sladen: your laconic comment suggests the same issue to me...
<Hobbsee> xhaker: why?
<xhaker> Hobbsee: the packages are openjdk-6* sorry
<xhaker> Hobbsee: because every package that was built with icedtea7 is being transitioned to openjdk-6
<xhaker> so you should use openjdk-6 for sanity :D
<xhaker> the dependency should be on icedtead-gcjwebplugin
<xhaker> that package installs the browser plugin and pulls openjdk-6-jre
<xhaker> icedtea-gcjwebplugin, it's late here.
<xhaker> right Hobbsee ?
 * Hobbsee is looking
<jdong> slangasek: ok, fair enough, thanks for your insight, I'll get out a USB disc
<slangasek> it's possible that all of the other wpa2 problems people are reporting right now all come down to the same thing, but I'm not sure because so far I've only gotten confirmation from anyone that hal fixes the "eats my CPU" problem, which not everyone has mentioned seeing
<Hobbsee> slangasek: how do you use sed to delete a line, and not leave blank space there instead?
<xhaker> Hobbsee: you'll see an upload from doko today, for the new openjdk code drop. there is a bug somewhere to trac the transition, but i don't know the number
<slangasek> Hobbsee: /thingymatched/d
 * slangasek worries that his reputation as a sed glutton may have preceded him
<Hobbsee> slangasek: ah, thanks.
<xhaker> Hobbsee: found it, it's bug 203636
<ubotu> Launchpad bug 203636 in openoffice.org "replace icedtea-java7 references with openjdk-6 references" [Undecided,In progress] https://launchpad.net/bugs/203636
<xhaker> filed by doko himself :)
<Hobbsee> xhaker: done, thanks
 * xhaker hugs Hobbsee
 * Hobbsee hugs xhaker back
<Hobbsee> i'm beginning to hate all this java stuff, w.r.t. all the versions.
<xhaker> now, why is licwidget0 and libcwidget3 installed side by side by default? licwidget0 is a dependency of aptitude and licwidget3 is orphaned :S
<Hobbsee> xhaker: of what?
<slangasek> because aptitude is FTBFS with the new cwidget and needs to be updated in a freeze-appropriate way
<Hobbsee> heh
<slangasek> it's libcwidget0 which is supposed to go away
<xhaker> ic :)
<Fujitsu> slangasek: Have you not pushed out the syncs you've performed yet?
<slangasek> Fujitsu: not yet, no
<Fujitsu> slangasek: OK, thought it was a bit late for you to not have.
<slangasek> not in this time zone? :)
<Fujitsu> Hobbsee: Can you please give back ikiwiki?
<Hobbsee> Fujitsu: given back
<Fujitsu> Hobbsee: Thanks.
<Fujitsu> Gr, how'd that fail again.
<Fujitsu> It succeeded twice in archive rebuilds two weeks apart.
<Fujitsu> Hum, shouldn't Priority: required stuff be installed in the buildd chroots?
<Fujitsu> liblocale-gettext-perl isn't.
<slangasek> you should still explicitly build-depend on anything that isn't essential: yes or part of build-essential
<slangasek> (I think the buildds use a stripped-down package set for this reason, maybe?)
<Fujitsu> Ah, thanks.
<Hobbsee> it's interesting about how a lot of hte ubuntu iso's for the beta are being downloaded by ktorrent.
<Fujitsu> Hobbsee: It's because KTorrent was the only graphical torrent client that didn't utterly suck, until Hardy.
<Hobbsee> Fujitsu: ahhh
<Fujitsu> That's why I and most other Ubuntuers I know used it.
<Hobbsee> fair enough
<Method> i'm trying to add a patch to the kernel package but can't figure out how the kernel package works, how do i get a real source package rather than the linux_meta package?
<Hobbsee> Method: probably #ubuntu-kernel, but it is a public holiday.
<laga> cjwatson: where do you keep the preseed files for the alternate disks? is there a bzr repo somewhere?
<Loevborg> Scripts /etc/acpi/resume.d used to be run on resume. Is there an equivalent for this in hardy's hal-system-power-suspend-linux?
<mjg59> You can add stuff to /etc/pm/sleep.d
<Loevborg> mjg59: thanks. Any chance that /etc/acpi/suspend.d will get cleaned up or removed? It's really confusing to have several acpi subsystems in the system.
<j1mc> hello, all.  there don't seem to be new images created for xubuntu, but there are no problems being reported as part of the xubuntu daily cd health check.
<j1mc> is there a reason for this?
<j1mc> http://cdimage.ubuntu.com/xubuntu/daily/current
<mjg59> Loevborg: Comment should probably be added - we won't delete any user-added files, though
<Loevborg> mjg59: sure, I was talking about a clean hardy install, where these files should not be necessary any more
<j1mc> even the most recent daily-live builds are from the 18th: http://cdimage.ubuntu.com/xubuntu/daily-live/current/
<hunmaat> hi. can you explain me, what the msgid 'Frobnicate!' of policykit-gnome means? And how is it different from 'Tweak!'?
<vykmorod> I'm just wondering if anyone can tell me something about Python + OpenGL + Tk/tcl core dunos in FiestyFawn
<vykmorod> *dumps
<persia> hunmaat: When one frobnicates, one is adjusting something as one wishes.  When one tweaks, one is typically seeking to improve the results.
<hunmaat> thanks, I thought something like this. but do not know distinct hungarian words for them :/
<hunmaat> [I don't now if it makes sense to translate these examples...]
<hunmaat> k
<persia> hunmaat: Frobnicate is jargon (http://catb.org/jargon/),  If you translate it, "Tweak" is good.  The distinction is mostly arbitrary.
<hunmaat> I see, but the next string is 'Tweak!' :(
<persia> Maybe translate "Tweak" from English to Hungarian, and simply conjugate "Frobnicate" as jargon?
<hunmaat> this might be an ability, but the English knowledge in Hungary is quite poor, so lots of people will have no idea about it's meaning
<persia> hunmaat: True, but "Frobnicate" isn't really an English word either, and I'm not sure of any other solution.
<hunmaat> I think I will simply skip the full examples section (~40 string). I can't find it on GUI.
<johanbr> I'd say "Frobnicate" shouldn't be present in anything user-visible in English either.
<hunmaat> I haven't seen the source, but based on the filenames I think, this is an unused example policykit implementation.
<hunmaat> with dummy actions
<sistpoty> doko: please give back missinh on sparc, thanks!
<sivang> does anyone remember how to inspect contents of a package using python apt?
<laga> sivang: there are lots of examples in the python apt package
<laga> maybe you can find something there?
<sivang> laga: I will try, thank you
<jwal> Hi.  I am looking for some documentation, preferably a risk assessment, for the decision to try and include Firefox 3 in Hardy and what will happen if Mozilla have not released it in time.  Any pointers?
<sistpoty> jwal: maybe asac can help you there
<asac> jwal: what for do you need that info?
<jwal> asac: I'm just curious
<asac> jwal: there are several compromises involved in this.
<asac> jwal: not being officially final is not the most important things for us (though its what we have hoped for). Its more important that we ship a product that rocks, while being able to guarantee our users security support throughout the whole hardy support cycle for instance.
<asac> doing a major version upgrade in a LTS because it turns out that we cannot provide security support is just not a good idea.
<jwal> I hadn't even considered that.  Do Mozilla make any promises about how long they will provide security fixes?  (I am now starting to research this on mozilla.org)
<asac> jwal: 6 month after the next version is released
<asac> so consider that 3.0 is final in may, we will get a security support for 2.x till december or something
<asac> jwal: we (distros) entangle to extend the security support, but unless thats proven to work we cannot rely on that
<asac> we do that for 1.5.0 (as in dapper) for now
<jwal> Sounds like you are no longer expecting to be able to ship a final Firefox in 8.04 LTS
<hunmaat> afaik, nor 1.5 was final
<asac> jwal: you never know ;)
<jwal> asac: Presumably this has been discussed with the people at Mozilla.  Have they been able to make any promises?
<orbisvicis> making sure im doing this right: get source, extract .tar.gz, extract diff.gz, patch -p <diff.gz
<asac> jwal: they are aware, yes. you never get any promises though
<soren> orbisvicis: It might help if you said what you were trying to do. If you're trying to make pancakes, you're not doing the right thing at all.
<soren> If you're trying to extract the source for ubuntu packages in the hardest possible way, you're close :)
<orbisvicis> soren this is an ubuntu dev channel, its about modifying/patching ubuntu source ; )
<mjg59> orbisvicis: apt-get source packagename
<mjg59> Or dpkg-source -x foo.dsc
<orbisvicis> um unfortunately this is alsa-plugin_1.0.15 for 8.04 while i need it for 7.10
<orbisvicis> so I dl'd it off the ubuntu website
<orbisvicis> oh i was so close
<jwal> soren: It's about 41 days too late for pancakes.  More likely trying to boil an egg.
<orbisvicis> then move the debian folder into the source folder
<jwal> asac: If, for example, Hardy ships with Beta 5 will the final version be included in the security update stream, the updates stream or the backports stream?
<jwal> asac: Sorry if this is on the wiki or launchpad somewhere (but I have been unable to find it)
<soren> orbisvicis: Just add a deb-src line to your sources.list and do an "apt-get source alsa-plugin/gutsy"
<asac> jwal: we will track upstream through security
<orbisvicis> soren, that is a viable option
<soren> jwal: Aw, I'm too late for pancakes?
<asac> jwal: as always
<orbisvicis> but theoretically this was works as well ?
<soren> orbisvicis: Or dget http://archive.ubuntu.com/ubuntu/pool/main/a/alsa-plugins/alsa-plugins_blahblah.dsc, followed by dpkg-source -x.
<soren> orbisvicis: Not necessarily.
<soren> orbisvicis: Depends on how the package maintainer applies patches.
<orbisvicis> oh
<orbisvicis> patch -pX, or even a different patch program ?
<soren> orbisvicis: The .diff.gz might patch stuff outside debian/.
<orbisvicis> i hadnt thought of that, though in that case i could move the diff file before patching it
<soren> orbisvicis: There are quite a few patch management system. If the package maintainer always uses one of those, it's usually not a problem to just move debian/ around. If they don't use a patch management system or just doesn't always do it (it's sometimes troublesome), the .diff.gz will contain diffs against stuff outside debian/
<orbisvicis> though i like the dpkg-source -x method >elegant
<soren> "apt-get source" uses "dpkg-source -x", too.
<soren> it just fetches the source first.
<soren> And yes, dpkg-source -x is the one true way.
<orbisvicis> heh
<orbisvicis> how did you get that link ... b/c it shows all the newest packages, what if say i needed the 7.10 version ?
<soren> orbisvicis: That one is there as well.
<soren> orbisvicis: I just typed it.
<soren> orbisvicis: Every version from dapper to hardy should be tehre.
<soren> there, even
<laga> TentakelFrau: scary.
 * asac out for a while
<orbisvicis> yes
<TentakelFrau> ;d
 * orbisvicis ^^ blind
<hunmaat> has the policykit-gnome developer ever heard about gnome hig?
<jwal> asac: Thanks for your help
<hunmaat> The UIF means strict stringfreeze?
<laga> eMo: _scary_
<eMo> laga: only if you don't know the context :)
<eMo> but, well, ok, it's enough ;)
<slangasek> asac: does ubufox not use the "Npp" metadata in Packages to figure out what plugin packages to install? bug #177514, icedtea-java7-plugin has been removed from the archive but firefox still won't automatically pick up icedtea-gcjwebplugin in its place
<ubotu> Launchpad bug 177514 in icedtea-java7 "firefox 64-bit IcedTea java not working." [High,Confirmed] https://launchpad.net/bugs/177514
<slangasek> asac: do you need any help triaging the information in bug #50214?  the set of permutations is huge, and a fair number of wireless drivers appear to still have the problem; are you expecting all of these to get fixed in the kernel for final?
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [High,Confirmed] https://launchpad.net/bugs/50214
<slangasek> (... and if so, does the kernel team know this?)
<asac> slangasek: help appreciated, i think i forked out individual bugs for specific chipsets i know of
<asac> for instance the iwl drivers appear to lack a patch in its own mac80211 module
<asac> slangasek: we might consider to unmilestone the generic bug.
<slangasek> asac: I guess I'd like to be sure first that it's empty of any remaining per-chipset problems that haven't been broken out, before unmilestoning it
<asac> Ill look
<asac> but thats definitly on my radar
<ScottK2> asac: Is Bug #204868 on your list too?
<ubotu> Launchpad bug 204868 in network-manager "NM can't use wireless networks" [Undecided,Confirmed] https://launchpad.net/bugs/204868
<slangasek> ScottK2: isn't 204868 really 204768 in disguise?
 * ScottK2 loooks.
<slangasek> nice that 145652 is marked as a duplicate of 204868 :P
<slangasek> 204768 was the hal issue
<slangasek> is this issue reproducible even with current hal?
<ScottK2> slangasek: No.  Apparently it's not the same thing.
<ScottK2> slangasek: 868 has a debdiff attached that multiple people claim has fixed nm for them.
<ScottK2> It does appear to persist with the new hal.
<slangasek> ScottK2: yes, but AFAICS the only reason kernel_driver is NULL in the first place is because of the hal bug...
<slangasek> "guard against a NULL kernel_driver value" does not address the root issue
<slangasek> and I believe the root issue is the hal bug, unless someone can confirm they're seeing this with current hal
<ScottK2> I see what you mean.
<ScottK2> slangasek: It does seem like the bulletproofing would be generally a good thing.
<slangasek> I agree
<ScottK2> I'd say that 204768 exposed 204868.
<warrendae> hi
<warrendae> can i ask a question that is not related to ubuntu here about C ?
<stgraber> warrendae: please read the topic first, it'll probably answer your question
<warrendae> ok :)
<stgraber> btw, I wondered where we are supposed to redirect people looking for help with development on Linux, we usually redirect people to #ubuntu but it's probably not the right channel for you :)
<bryyce> stgraber: google maybe?  ;-)
<ion_> Yay, no alsaconf, and the module's autoprobe fails for the non-PNP ISA card integrated to this laptop.
<stgraber> bryyce: would probably be a good start indeed :)
<dmb> hey, we need someone to upload https://bugs.launchpad.net/ubuntu/+source/inspircd/+bug/201941 , is this the place to ask?
<ubotu> Launchpad bug 201941 in inspircd "FreezeException request-- Sync with  Debian unstable" [Wishlist,New]
<ScottK2> dmb: The archive administrators have been subscribed.
<dmb> so i just wait and it should be good?
<ScottK2> dmb: They'll get to it in the next few days.  No need to do anything else.
<ScottK2> Yes
<dmb> just making sure :D
<dmb> ScottK2: you were one of the ackers wern't you?
<ScottK2> For motu-release, yes.
<slangasek> asac: so what needs to happen to make ubufox happy with icedtea-gcjwebplugin?  It looks like the source package only looks at gutsy Packages files currently?
<asac> slangasek: yes, the plugin db needs an update run.
<slangasek> asac: is that something only you're able to do because it's hosted somewhere, or is it something that should be doable within the source package and I'm just not understanding?
<asac> slangasek: no ... thats on people.ubuntu.co
<slangasek> ok
<asac> so i until now i run it regularaly
<slangasek> asac: I guess I'll leave that bug to you then, and you'll close it when the db is updated?
<hspaans> someone here responsible for gnome in Hardy?
<asac> slangasek: yes.
<asac> ill treat it with high priority
<slangasek> asac: ok, cheers
<asac> slangasek: please assign to me
<slangasek> done
<slangasek> OMG these NM/hal bug reports are driving me batty >_<
<slangasek> it's probably going to take us to the middle of the week to stop getting false-positive confirmations from people with the bad hal
<LaserJock> slangasek: well, the forums have it, that's usually a contributor
<slangasek> the forums encourage users to send "me toos" to bug reports?
<sistpoty> can't you give and lp hing or s.th.? (thought lp would have such a feature nowadays, but I might be wrong)
<sistpoty> hint even
<slangasek> sistpoty: the issue is that people are sending follow-ups with incomplete information to the *wrong* bug reports
<sistpoty> oh
<LaserJock> slangasek: not specifically no, but if they give a LP bug number they'll all jump on it
<slangasek> "yes, I have this driver and it's still broken" - ok, but what version of *hal* do you have installed?
<ScottK2> slangasek: Be sure to share your pain with however did the hal upload the broke everything.
<ScottK2> however/whoever
<slangasek> pitti: <share>
#ubuntu-devel 2009-03-16
<savvas> cjwatson: sorry about bug 316579 - I didn't know it was under copyright :)
<ubottu> Launchpad bug 316579 in soyuz "Soyuz needs to switch to obtaining Packages-arch-specific from non-obsolete source" [High,Triaged] https://launchpad.net/bugs/316579
<ScottK> savvas: As a general rule anything not explicitly not copyrighted is copyrighted.  So unless you KNOW it's not ....
<Mavericks> ScottK: were you being sarcastic?
<Hobbsee> Mavericks: no?  That's standard practice, actually
<Mavericks> never mind understood - it took a while to wrap my head around that statement of ScottK
<Mavericks> thanks Hobbsee for the response
<JanC> actually, in many countries it's not possible or very difficult to make something "not-copyrighted"
 * directhex copyrights Hobbsee 
 * StevenK claims prior art and sues directhex 
<Hobbsee> heh
 * Hobbsee attacks directhex with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢
<directhex> StevenK, prior art? you're thinking of patents ;)
 * directhex patents StevenK 
<StevenK> Meh
<JanC> to make something public domain you would obviously have to be the author, and an author can't put something in the PD in many countries  ;)
<maco> i believe the US is one where public domain only occurs after copyright expires or when it's a work of the government
<crdlb> copyright never expires :>
<nixternal> kees: pingalicious
<nixternal> hrmm, I guess if you were from mexico or such, that might sound a little bit off :)
<nixternal> if you don't respond in the next 4 hours, you can ignore that one
<kees> nixternal: sup?
<nixternal> damn, now I probably missed you kees...was just wondering if I could get added to the Core Dev Sponsors team
<StevenK> nixternal: As in u-m-s?
<nixternal> ya, that's the one
<tjaalton> jdong: you disabled vblank from the compiz configuration?
<tjaalton> the default is off, but you can break it by enabling it there
<jdong> tjaalton: I had to manually disable vblank from gconf in an alpha 6 install
<jdong> is the default vblank off supposed to be the case as of alpha-6?
<maco> StevenK: do you know who handles moderation for ubuntu-devel mailing list?
<StevenK> maco: According to https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel ; cjwatson
<maco> figures, just needed to scroll further down.
<maco> thanks
<Hobbsee> maco: anything in particular you were wanting?
<maco> to be whitelisted
<maco> i think i fit in the white rectangle on https://wiki.ubuntu.com/UbuntuDevelopers so i'd like to get whitelisted instead of always going through message moderation
<Hobbsee> ahhh
<Hobbsee> People who consistently post sensible, on-topic material should be added to the whitelist. To edit the whitelist, use the administrative interface (with the moderator password) and navigate to Privacy options... -> Sender filters -> accept_these_nonmembers. Please be careful when editing this field to avoid accidents of the select-all type that might lose the previous list contents; if you suffer such an accident, don't save your changes!
<Hobbsee> yeah, you fit that. cool
<Hobbsee> maco: fixed.
<maco> Hobbsee: awesome! you rock!
<Hobbsee> maco: :)
<tjaalton> jdong: yes, but I'm not sure if the compiz configuration enables it
<tjaalton> but the dri driver default is off
<pitti> Good morning
<Hobbsee> heya pitti!
<slangasek> hmm, why does nm-applet believe that NM is notrunning
<slangasek> ** (nm-applet:19035): WARNING **: nm_client_get_devices: error getting devices: The name org.freedesktop.NetworkManager was not provided by any .service files
<slangasek> \o/
<Lure> transition to python 2.6: this just needs no-change upload, right?
<mvo> Lure: sometimes the setup.py install line needs to be modified
<mvo> to include --install-layout=deb
<mvo> and sometimes the debian/*.install (or rules) because "site-packages" chagned to "dist-packages"
<Lure> mvo: ok, thanks for hints
<slangasek> directhex: hrm, mono seems to have transitioned from having separate /usr/share/doc directories to having symlinks pointing to mono-common?  but the -cil packages all think they still own the files under /usr/share/doc, so if you remove one of them your copyright file disappears
<savvas> As a general rule anything not explicitly not copyrighted is copyrighted.  So unless you KNOW it's not .... < ScottK: Noted! thanks for the tip :)
<directhex> slangasek, the reverse is the case - the ubuntu's mono has historically had a buggy docdir symlink thing going on, the current package has individual docdirs
<directhex> apparently there's a policy issue w/ symlinking, which is why it's not done in debian
<slangasek> directhex: then the transition to separate docdirs was not managed correctly
<slangasek> because they're not separate dirs on my system
<slangasek> dpkg will not automatically switch between a directory and a symlink on upgrade; this is documented in Debian policy
<directhex> blarg
<directhex> i'll have a word with meebey when he's about, then
<pitti> thekorn: wow, you are really into the guts of launchpadlib
<thekorn> pitti, I do my best, hopefully it makes sense ;)
<pitti> thekorn: btw, do you happen to know whether the remaining usages of p-lp-bugs (ubuntu-qa-tools, ubuntu-dev-tools, python-bughelper) are going to be transitioned in jaunty?
<thekorn> pitti, I'm sure bughelper won't make it until jaunty, ubuntu-dev-tools is using launchpadlib, I think py-lp-bugs is optional
<thekorn> not sure about u-qa-tools
<pitti> thekorn: u-dev-tools still Depends: on it, though
<pitti> $ dpkg -L ubuntu-dev-tools|xargs grep launchpadbugs
<pitti> /usr/share/pyshared/ubuntutools/ppaput.py:    import launchpadbugs.connector as Connector
<pitti> hm, that shouldn't be hard to change, just one file left
<thekorn> looks like I missed it when I did the transition ;)
<seb128> sjoerd: hey, what is the issue with telepathy-glib?
<sjoerd> seb128: build-depends on python, but used python2.5
<sjoerd> *uses
<seb128> ok, so it's a package bug
<sjoerd> yeah and a slight upstream one as well
<seb128> bigon was saying it's a buildd bug apparently
<seb128> bigon: ^
<sjoerd> for debian it's fine as python is still 2.5 or lower
<sjoerd> we'll fix upstream so it can use 2.6 as well, but the ubuntu package should b-d on python2.5 for now
<seb128> sjoerd: ok, we are on sync with debian so it would be nice to fix it there since debian will have the issue sooner or later too anyway
<seb128> but we can add an ubuntu diff for now I guess
<sjoerd> sure
<sjoerd> i wouldn't mind putting python2.5 in the debian packaging as a build-dep for now
<seb128> would be nice, thanks!
<sjoerd> is telepathy in main now btw or still universe ?
<seb128> universe
<savvas> pitti: ignore bug 332120 - it's a bit outdated, I was "educated" to rebuild them - I forgot to set it as invalid :)
<ubottu> Launchpad bug 332120 in boost1.35 "jaunty - boost (1.34) to boost1.35 transitional dummy packages" [Undecided,Invalid] https://launchpad.net/bugs/332120
<pitti> savvas: ah, okay
<pitti> savvas: unsub'ing sponsors then
<savvas> pitti: thanks :)
<TheMuso> seb128: There appears to be some sort of race condition with GNOME session startup, gnome-session and at-spi-registryd. On the live CD, logout dialogs are accessible, whereas on an installed system they are not. Starting at-spi-registryd-helper from a file in /etc/X11/Xsession.d proves that things are not starting in the right order.
<TheMuso> seb128: I'm wondering whether you may have any suggestions as to how this could possibly be fixed.
<TheMuso> seb128: I could start at-spi-registryd from /etc/X11/Xsession.d, but I think it would be better to sort the problem out relating to the GNOME session itself.
<seb128> TheMuso: no suggestion but open a gnome-session bug upstream I would say
<TheMuso> seb128: ok sounds reasonable.
<YokoZar> Does 5-a-day ever work? I've gotten bazaar internal errors the last month when I've tried to use it (with 5-a-day --add)
<pitti> asac: please pull lp:~pitti/mobile-broadband-provider-info/mobile-broadband-provider-info.20090309 into lp:~network-manager/mobile-broadband-provider-info/mobile-broadband-provider-info.ubuntu/ (or make ubuntu-core-dev a member of ~network-manager)
<pitti> asac: I just uploaded the new upstream release to jaunty
<yao_ziyuan> can i run update-notifier (not update-notifier-kde) at kde startup for update notification?
<ttx> asac: ping
<pitti> evand: hey; I hope you don't mind, I fixed usb-creator FTBFS and did an upload yesterday, since it didn't work at all with persistency
<evand> pitti: no problem at all.  Thanks a bunch!
<pitti> cjwatson, bdmurray: heh, did you notice that the numbers on http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html actually go *down*?
<asac> pitti: hmm. ok thanks. thought actually we were waiting for something
<asac> pitti: but that was only libmbca0 i guess
<pitti> asac: waiting> all bugs mentioned in the sponsoring bugs were fixed upstream
<pitti> asac: that's what you was waiting for before
<cjwatson> joaopinto: just make sure that /etc/default/console-setup is set up properly in the chroot before you install console-setup there
<cjwatson> pitti: blink, so they do. that's odd ...
<cjwatson> pitti: perhaps a change of rules in how sponsored uploads are counted?
<pitti> cjwatson: maybe, I don't know
<seb128> pitti: what is the question?
<joaopinto> cjwatson, thanks, meanwhile I was able to install with DEBIAN_FRONTEND set to noninteractive, I just needed to bind mount /proc first, otherwise the console-setup start script fails (without providing a meaningful reason)
 * slangasek tries restarting NM to see if that lets nm-applet find it again; if I go quiet, you'll know I broke my network
<ttx> asac: I'm looking into the n-m/wpasupplicant shutdown mess... Apparently wpasupplicant has support for sendsigs omission in its ifup/down scripts, but they aren't called when used from n-m ? I'm still a little confused as to what in that behavior is by design and what is a bug.
<asac> ttx: NM wpasupp is started through dbus activation
<asac> ttx: could be that it dies when dbus goes down
<ttx> asac: imho it dies when killed by sendsigs... since there is nothing in sendsigs.omit.d created to avoid that fate
<ttx> asac: the omit things are normally created in the ifup scripts
<ttx> but n-m must bypass that iirc
<asac> ttx: so have you tried to not kill nm nor wpasupp? what happened?
<ttx> if I run my N-M branch /and/ manually add the pid for wpa_supplicant in /lib/init/rw/sendsigs.omit.d then the network fs get properly unmounted
<ttx> asac: supposing you run in "network connection available for all users" mdoe
<ttx> mode, even
<slangasek> well, that's fun.  nm-applet can see NM again as soon as I restart it; but I can't connect to my home wireless anymore, only to the neighbor's open AP. :P
<ttx> asac: it still fails when run in "my connection, MINE !" mode.
<asac> slangasek: you dont see your wireless in applet? or association just fails?
<ttx> asac: but I don't see any way out of that... mounting network filesystems and running per-Gnome-session network is obviously not compatible.
<slangasek> asac: clicking on my home network fails to get it to associate. Mar 16 03:25:45 dario NetworkManager: <WARN>  get_secrets_cb(): Couldn't get connection secrets: Rejected send message, 5 matched rules; type="method_call", sender=":1.1383" (uid=0 pid=29469 comm="/usr/sbin/NetworkManager --pid-file /var/run/Netwo") interface="org.freedesktop.NetworkManagerSettings.Connection.Secrets" member="GetSecrets" error name="(unset)" requested_reply=0 ...
<slangasek> ... destination="org.freedesktop.NetworkManagerUserSettings" (uid=1000 pid=30394 comm="nm-applet ")).
<seb128> pitti, slangasek: is one of you doing syncs?
<pitti> seb128: no
<slangasek> asac: any thoughts?
<asac> slangasek: sounds like dbus
<asac> slangasek: what kind of system is that? jaunty?
<asac> slangasek: the /etc/dbus/system.d/ policy files got updated in one of the recent uploads (security).
<slangasek> asac: not sure which of my messages made it through; did you get the get_secrets_cb() error I quoted?
<asac> slangasek: yes
<asac> thats the last one
<asac> 11:26 < slangasek> ... destination="org.freedesktop.NetworkManagerUserSettings" (uid=1000 pid=30394 comm="nm-applet ")).
<slangasek> wow, the neighbors' ISP sucks. ;)
<asac> 1:29 < asac> slangasek: what kind of system is that? jaunty?
<asac> 11:32 < asac> slangasek: the /etc/dbus/system.d/ policy files got updated in one of the recent uploads (security).
<asac> ttx: i would think that user mounted nfs is not really supported by our Desktop. last week i searched for UI to setup a nfs mount in gnome and didnt find any.
<asac> ttx: so yeah. lets fix the system connection case ... and keep the other issue open
<slangasek> asac: jaunty, yes
<slangasek> asac: suggestions on how to fix this?  (and which package updated those files?  this breakage is not correlated with an upgrade of network-manager for me)
<asac> slangasek: when did this start?
<slangasek> asac: this part of the problem started a couple hours ago, when I restarted NetworkManager because nm-applet couldn't see it
<asac> slangasek: have you restarted your system afterwards?
<slangasek> that error was: ** (nm-applet:19035): WARNING **: nm_client_get_devices: error getting devices: The name org.freedesktop.NetworkManager was not provided by any .service files
<slangasek> asac: no?
<asac> slangasek: check that you dont have modified dbus policy files. if that doesnt help restart dbus and see if that helps
<slangasek> I don't have modified dbus policy files
<slangasek> at least, not modified by me
<asac> slangasek: heh
<slangasek> let me do a conffile check
<asac> slangasek: yeah. you never know; mine is: http://paste.ubuntu.com/131887/ (/etc/dbus-1/system.d/nm-applet.conf)
<slangasek> yeah, no modified conffiles under /etc/dbus-1
<asac> good.
<slangasek>                 <!-- Only root can get secrets -->
<slangasek> ok... isn't that the problem? :)
<joaopinto> cjwatson, I noted that some other scripts already check for /proc availability, does it make sense to file a bug against console-setup ?
<cjwatson> joaopinto: feel free to file a bug
<asac> slangasek: well. there is no reason for anyone else to get the secrets
<asac> slangasek: or are you running NM daemon as a special user;)?
<asac> slangasek: also you have: sender=":1.1383" (uid=0 pid=29469
<asac> which seems to be ok
<slangasek> asac: it's running as root.  The error message in my log is precisely about querying secrets.
<asac> slangasek: right. but root is allowed to get secrets. thats why i think your dbus needs a restart or something
<slangasek> asac: except that file is older than my last reboot
<slangasek> ugh, ok, now I can't even see my AP; hang on, let me troubleshoot that
 * asac running out to buy some coffee-food; few minutes ...
<slangasek> asac: restarting dbus crashed X. :P
<slangasek> it also caused nm-applet to again be unable to see NM
<slangasek> so I restarted NM; now things are working, but I had to reenter my WEP key
<slangasek> (which is supposed to be stored as part of a system connection profile, but of course that still doesn't work properly anyway...)
<doko> slangasek: did you rebuild gcc-4.3 for #328035, or do you need a package?
<slangasek> doko: rebuild it?  I was just going to roll back to the earlier version of the package that was used to build -1ubuntu1
<doko> ahh, ok
<slangasek> seb128: well, haven't seen bug #332342 again, but apparently gnome-keyring-daemon is unhappy if dbus disappears. :)
<ubottu> Launchpad bug 332342 in gnome-keyring "gnome-keyring-daemon crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/332342
<asac> slangasek: thats strange. i run wpa psk secret system connection on my laptop without applet ... no problems with secrets
<slangasek> do you use it as a system connection?
<asac> slangasek: yes. "all userse"
<slangasek> asac: ok, well, as I've said before, the system connection here has never worked properly as a system connection
<slangasek> I expect that it'll keep track of my WEP key again now that I've re-entered it, but that it will continue to fail to bring up the connection prior to login
<slytherin> seb128: Have some free time? Need to discuss broken DVD playback in jaunty. I have the solution but I am not able to understand root cause.
<seb128> slytherin: shoot
<asac> slangasek: for system connections the secrets have to be entered int he "connection editor"
<seb128> slangasek: hey, is that you doing syncs?
<asac> if you see a popup asking for passphrase its not a system connection
<seb128> slytherin: so...?
<slytherin> seb128: DVD playback is broken with latest libdvdread. The solution I have found is to use old configure script instead of current configure2/Makefile combo being used. But I have no idea why one works while other doesn't.
<seb128> slytherin: configure for what?
<slangasek> asac: frankly, suggestions that this is an error on my part are only going to piss me off, because I have clicked *every* *possible* *button* in nm-applet, repeatedly, to try to get it to do something sensible with a system connection
<slytherin> seb128: for build. Upstream ships a configure2 script and using autogen.sh creates another configure script.
<slangasek> asac: so if I've failed, it's because the UI is braindamaged
<seb128> slangasek: what pakage are you speaking about? libdvdread?
<seb128> ups
<slangasek> seb128: I'm doing syncs today, yes
<seb128> slytherin: ^
<slangasek> asac: I have a profile under /etc/NetworkManager/system-connections.  It contains the secret.  The connection is only ever brought up when I log in and nm-applet starts.
<asac> slangasek: i dont say that its your fault. its just odd. i will check whether i can see similar things with WEP
<slytherin> seb128: yes
<seb128> slangasek: ok, I will need to do some GNOME syncs later when you are done
<asac> slangasek: do you see whether NM at least tries to connect for you?
<asac> before login?
<seb128> slytherin: weird, I tried to use libdvdread3 which is still installed on my jaunty box some days ago and it didn't work better
<slytherin> seb128: Now it is libdvdread4
<slytherin> seb128: will be back in 10 minutes
<seb128> slytherin: right, but libdvdread3 should still be working
<seb128> slytherin: if that was a libdvdread bug, since that's the intrepid version and that was working in intrepid
<seb128> slytherin: later
<seb128> brb trying an another round of updates
<slangasek> asac: hmm, I think we're repeating a conversation we've had in the past about this. :)  I think I should just make sure I have a bug filed about the problem...
<slangasek> seb128: I'm already done with the syncs, go ahead
<seb128> slangasek: thanks
<asac> slangasek: ok got your bug now
<slangasek> asac: bug #321442?
<ubottu> Launchpad bug 321442 in network-manager ""system"-level connection doesn't start up until nm-applet is launched" [Undecided,New] https://launchpad.net/bugs/321442
<asac> slangasek: yeah
<slytherin> seb128: I am back. Actually all the applications have migrated to libdvdread4 now.
<seb128> slytherin: what do you call migrated there?
<slytherin> seb128: I mean linked against libdvdread4. mplayer, VLC, gstreamer plugins etc.
<seb128> slytherin: right, I just did try totem using libdvdread3 to see if that was due to the new libdvdread4 and that didn't work better here
<seb128> slytherin: what change do you do to get it working? I will give it a try and have a look
<slytherin> seb128: Just a minute
<seb128> Hobbsee: why did you confirm bug #342890 as being a totem issue if it happens on all dvd players?
<ubottu> Launchpad bug 342890 in totem "Cannot play DVDs - Could not open location; you might not have permission to open the file" [High,Confirmed] https://launchpad.net/bugs/342890
<Hobbsee> seb128: because i've not moved it yet
<slytherin> seb128: I rebuild libdvdread using this in debian/rules file - ./autogen.sh, ./configure --prefix=/usr -DHAVE_DLFCN_H (note the currently used script is configure2). I had to add libtool, autoconf and automake to build-depends.
<slytherin> seb128: one more thing, configure.ac needs patching to change DVDREAD_LT_REVISION=2 to DVDREAD_LT_REVISION=3
<seb128> slytherin: why?
<seb128> slytherin: I will have a look to that after lunch
<slytherin> seb128: sure, take your time.
 * seb128 is away for lunch now, bbl
<slytherin> Hobbsee: I am changing the package for that bug to libdvdread.
<Hobbsee> slytherin: cool, thanks
<asac_> slangasek: ok. after playing around i could now reproduce; it gets revealed because of managed=false in nm-system-settings.conf and having eth0 configured in ifupdown; managed=true should workaround this for now
<slangasek> asac_: won't that also cause NM to try to manage eth0, then?
<asac_> slangasek: yes. if you have a not supported setup you have to wait for the fix
<slangasek> "not supported"?
<asac_> slangasek: not supported by the ifupdown system settings plugin that is
<asac_> e.g. if you use managed=true, nm ifupdown plugin will parse your ENI and manage that as a system connection
<slangasek> ah
<asac_> instead of keyfile
<slangasek> well, I'll turn it on and see; having it twiddle with eth0 is certainly going to be a lesser evil
<slangasek> since eth0 is never plugged in :)
 * asac_ sets AP back to WPA
<slangasek> mvo: gksu is dep-wait on sng?
<mvo> slangasek: oh, let me check
<seb128> pitti: http://launchpadlibrarian.net/23910885/buildlog_ubuntu-jaunty-i386.glib2.0_2.20.0-1_FAILEDTOBUILD.txt.gz
<seb128> pitti: "pkgstriptranslations: tarball already exists" is that a warning or an error?
<seb128> the build failed but I'm not sure to understand why
<pitti> seb128: no, it's just logging
<seb128> ok
<pitti> seb128: it happens if a source builds multiple binaries and thus it's called several times
<seb128> weird build log
<pitti> seb128: if it exists, it updates the existing one
<seb128> I see nothing wrong there
<pitti> seb128: urgh, glib again?
<seb128> yes
<pitti> seb128: previous builds failed because the buildds run builds in parallel
<pitti> (AARGH! to whoever enabled that in that way)
<pitti> seb128: but I thought I fixed that in pkgstriptranslations
<cody-somerville> md5sum: usr/share/locale/da/LC_MESSAGES/glib20.mo: No such file or directory
<cody-somerville> md5sum: usr/share/locale/de/LC_MESSAGES/glib20.mo: No such file or directory
<cody-somerville> dh_md5sums: command returned error code
<cody-somerville> make: *** [binary-indep] Error 1
<mvo> slangasek: I put a uudecoded version into the gksu source for now. is there a reaosn to keep sng out of main? or is just a MIR report required for it?
<pitti> cody-somerville: indeed, that's further up
<pitti> cody-somerville: it seems that one pkgstriptranslations runs in parallel with another dpkg-deb
 * cody-somerville nods.
<cody-somerville> Indeed.
<cody-somerville> The next line after that error is "make: *** Waiting for unfinished jobs...."
<pitti> seb128: bah, fixing parallel dh_* runs properly is utterly hard
<slangasek> mvo: MIR would be required; not my department, I'm just reviewing the out-of-dates list :)
<seb128> pitti: what do you suggest doing? retrying the build? ;-)
<pitti> seb128: we can do
<seb128> let me retry
<pitti> seb128: but ideally glib would just stop doing parallel debhelper
<pitti> it's a gamble like this
<seb128> it doesn't do anything special that I know about
<slangasek> asac: edited nm-system-settings.conf to set [ifupdown] managed to true; restarted NM; network still doesn't come up without nm-applet
<doko> mvo: how do you suggest to handle bugs like bug 320745 and bug 322739 ?
<ubottu> Launchpad bug 320745 in openjdk-6 "package openjdk-6-jre-lib None [modified: /var/lib/dpkg/info/openjdk-6-jre-lib.list] failed to install/upgrade: short read in buffer_copy (backend dpkg-deb during `./usr/lib/jvm/java-6-openjdk/jre/lib/ext/localedata.jar')" [Undecided,New] https://launchpad.net/bugs/320745
<ubottu> Launchpad bug 322739 in openjdk-6 "package openjdk-6-jre-lib 6b12-0ubuntu6 failed to install/upgrade: short read in buffer_copy (backend dpkg-deb during `./usr/lib/jvm/java-6-openjdk/jre/lib/charsets.jar')" [Undecided,New] https://launchpad.net/bugs/322739
<mvo> doko: the ones I have seen that look like this are file system corruptions, I have a closer look
<seb128> mvo: there is several bugs with the same error on dpkg
<seb128> mvo: I tend to reassign the ones we get for desktop packages there since the short read seemed to be a dpkg issue
<seb128> slytherin: ok, I don't know why because I don't think I changed anything special since friday but dvd playing work on my jaunty laptop today
<seb128> so either one of the GNOME 2.26 updates fixed it which would be weird
<seb128> or it's murphy law in action
<mvo> doko: I commented
<asac> slangasek: sudo killall nm-system-settings to apply your .conf changes
<slangasek> asac: right, ok
<slytherin> seb128: That is weird. I was having problem till yesterday. Currently I am in office. SO I will let you know if it works for me when I go home.
<asac> (yes, we will do that in init script)
<slytherin> seb128: In what timezone are you usually available?
<seb128> slytherin: european work hours and often after dinner too
<seb128> slytherin: if I'm on IRC I'm available that's easy ;-)
<slytherin> seb128: ok. :-)
<asac> a bit odd: on my desktop with usb wifi thing i cannot reproduce "nm not activating system connection" bug ... no matter what. seems i have to do the debugging on the laptop then.
<slangasek> asac: hmm, still the same problem
<asac> darn
<slytherin> seb128: you have latest updates installed right?
<seb128> slytherin: I did upgrade on friday and I've been doing GNOME updates since this morning
<asac> slangasek: as a last attempt you could try to remove eth0 lines from ENI and killall nm-system-settings, restart NM and everything.
<seb128> slytherin: trying to play protected dvds was not working on friday, I did try a no change libdvdread rebuild after lunch today and now that works
<seb128> slytherin: I did try to reinstall the jaunty version and that works too
<asac> slangasek: anyway, i could reproduce something similar on my laptop so i will just debug that and hope that this fixes your issue too
<seb128> slytherin: I did reinstall the libdvdcss too and that's still working
<slytherin> seb128: Ok. The only thing in gstreamer stack that has changed since Friday is -ugly. So I am really clueless.
<slangasek> asac: ok :)
<seb128> slytherin: so either it's murphy's law or the glib update or something fixed it, but I doubt GNOME updates would impact on libdvdread
<seb128> slytherin: I didn't install this update yet
<seb128> and I was having the issue in totem-xine too
<seb128> which is working fine now
<Amaranth> mvo: have you seen any problems with compiz on intel with UXA?
<slytherin> seb128: I didn't have any issues with any xine players. Anyway, going offline now. Will login later.
<seb128> slytherin: ok
<seb128> slytherin: xine-ui was not working for me on friday I think
<seb128> neither was totem-xine
<Lure> pitti: thanks for approving exiv2 FFe
<Lure> pitti: does universe approval need 2 ACKs and main only one
 * Lure read this in FFeProcess
<jdong> tjaalton: well from my experience, compiz DOES enable vblank syncing by default and that makes UXA very unhappy to render the screen more than once every 5 seconds :D
<Amaranth> jdong: we don't enable vsync by default
<Amaranth> ack, we do, when did that change?
<Amaranth> sure enough, that was the problem
<Amaranth> I thought we disabled vsync because it caused problems with nvidia
<jdong> yeah, maybe we should turn that off...
<mvo> Amaranth, jdong: uxa> yes its pretty slow currently. if its the sync_to_vblank, then I will chnage the default
<Amaranth> mvo: it is, I just turned that option off and it flies again
<Amaranth> I was getting sick of the metacity compositor, so slow and limited
<jdong> mvo: likewise; with UXA and vblank OFF, the speed is more or less acceptable (I don't feel Compiz any slower than Intrepid)
<jdong> but with vblank on, all hell breaks loose :)
<mvo> thanks guys, I prepare a fix
<mvo> "fix
<mvo> "
<jdong> thanks!
<mvo> hm, this should be set to false already
 * mvo looks a bit deeper
<Amaranth> mvo: that's what I said too :P
<ogra> for me ebaling UXA makes X crash randomly
<Amaranth> afaik nvidia still falls over on it because they use refresh rate to store configuration information
<ogra> *enabling
<mvo> Amaranth: yeah, the changelog says it causes issues with suspend
<Amaranth> yep, that too
<Amaranth> we really need a way to make sure certain options are on/off per video card/driver
<mvo> Amaranth: heh :) core.xml.in is now core.xml.in.in
<Amaranth> *headdesk*
<soren> Keybuk: Hey. You dropped ndb-client's modprobe option to set max_part to 15, claiming the default was already 16. This is not the case (you've probably mistaken nbds_max for max_part). Since you broke it, would you mind taking care of fixing it in the kernel? I mean, how much difference will one patch make in your anti-modprobe-options crusade? :)
<Keybuk> soren: ?
<Keybuk> drivers/block/Makefile:obj-$(CONFIG_BLK_DEV_NBD)	+= nbd.o
<Keybuk> oh, no, wait, you're right ;)
<Keybuk> I did confuse the two
<ogra> i think he means devices != partitions
<ogra> Keybuk, btw, i get a "file not found" error if i use an empty modules.dep ... i know its just cosmetic, but would be nice if it wouldnt moan
<Keybuk> ogra: you can't get an empty modules.dep
<ogra> sure
<ogra> if i run depmod -a without having any modules under /lib/modules/$(uname -r)
<Keybuk> it should still generate the empty file
<ogra> that creates an empty file /lib/modules/$(uname -r)/modules.dep
<Keybuk> not to mention an empty binary bindex
<Keybuk> oh, no, it shouldn't
<Keybuk> it generates a file with lots of "filename:" lines
<ogra> on boot i get a file not found: /lib/modules/$(uname -r)/modules.dep
<Keybuk> hmm
<Keybuk> that sounds more like a bug somewhere else
<ogra> i used it like that on my early ARM kernels
<Keybuk> what is outputting that error?
<ogra> to get an initramfs even though i have no kernel modules
<ogra> i think there is been a "modprobe:" at the start of the lines
<ogra> i have no such system around atm
<Keybuk> modprobe doesn't *use* modules.dep ;)
<ogra> it was pretty close tro something like: "modprobe: /lib/modules/$(uname -r)/modules.dep: not such file or directory"
<Keybuk> which is odd, because you're saying there is such a file, it's just empty <g>
<ogra> right
<ogra> it might refer to the content ... if i have it again i'll note down the exact message
<ogra> my assumption was that some script in module-init-tools tries to parse the file and ends up with an empty var where it shouldnt
<ogra> trying to open a file it would read from /lib/modules/$(uname -r)/modules.dep normally
<soren> Keybuk: modprobe doesn't use it? What does, then?
<Keybuk> soren: nothing
<Keybuk> it's generated because if it wasn't, some people would get hysterical
<Keybuk> soren: got a bug# about the nbd thing?
<soren> Keybuk: https://launchpad.net/bugs/342563
<ubottu> Ubuntu bug 342563 in nbd "[jaunty] /sys/module/nbd/parameters/max_part is 0, which prevents /dev/nbd0p* devices from getting created" [Wishlist,Confirmed]
<soren> Keybuk: How are module dependencies handled nowadays, then?
<ogra> by the modules themselves
<soren> Oh, symbo... Right, ok.
<soren> ogra: Erm.. No, I don't get that  :)
<calc> doko: have you seen my follow up to bug 329903 yet?
<ubottu> Launchpad bug 329903 in xom "xom FTBFS in Jaunty on the i386 buildd but not on personal amd64" [Medium,Confirmed] https://launchpad.net/bugs/329903
<ogra> ogra@osiris:~$ modinfo mcs7830|grep depends
<ogra> depends:        usbnet,mii
<soren> ogra: I see. So how does that get mapped to filenames?
<ogra> by assumptions?
<ogra> no idea
<soren> I see modprobe opens modules.dep.bin for something.
<soren> "modprobe  expects an up-to-date modules.dep file, as generated by depmod (see depmod(8))." from modprobe(8)
<bdmurray> pitti: How do you figure?
<pitti> bdmurray: last time I looked at the page (a week ago perhaps) I had some 159 fixes, and now it's 140something
<rtg> cjwatson: hey mr. debootstrap. I'm having some issues with a Jaunty lpia chroot on a Jaunty server. '/usr/lib/gcc/i686-linux-gnulp/4.3.3/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory'. Does that look familiar? I've re-installed from scratch, but no joy. Seems to work fine on an Intrepid host.
<Keybuk> soren: it lies
<Keybuk> modprobe uses modules.dep.bin now
<bdmurray> pitti: its possible the bug is no longer Fix Releaed but that does seem excessive
<soren> Keybuk: Which holds the same information, but in a different formaT?
<Keybuk> soren: right
<soren> Keybuk: Ok. So the "depends info" from modinfo is only informational?
<tjaalton> jdong, Amaranth, mvo: DRI2 (which is used when UXA is) doesn't support sync-to-vblank, so maybe compiz tries to do something weird to compensate, which makes it slow
<soren> Err.. "depends" info, I mean.
<cjwatson> rtg: can you give me a quick recipe to reproduce this?
<pitti> bdmurray: maybe you changed some rules wrt. sponsoring?
<mvo> tjaalton: the default should be fixed now
<cjwatson> rtg: sounds like a broken runtime linker path or something
<mvo> (in compiz)
<Keybuk> soren: the depends info from modinfo is the hints in the .ko that depmod reads and turns into modules.dep{,.bin}
<Keybuk> likewise the alias info from modinfo is what depmod turns into modules.alias{,bin}
<tjaalton> mvo: oh, it used to cause problems with nvidia? maybe that's why mine is freezing a lot when changing the user or crashes on resume/thaw
<rtg> cjwatson: I'm just running debuild on the Jaunty kernel tree in an LPIA chroot
<tjaalton> mvo: great :)
<cjwatson> so any invocation of gcc I guess
<rtg> cjwatson: 64 bit Jaunty server, LPIA chroot.
<soren> Keybuk: Now I'm confused :) I just strace'd modinfo and it opens modules.dep (not .bin)... Any idea what it might be using that for?
<cjwatson> rtg: I don't have a 64-bit machine handy, but let me build a test chroot here and I'll get back to you
<Keybuk> soren: mailed the patch for you to kernel-team and the bug
<cjwatson> rtg: in the meantime an strace of the failing compile command wouldn't hurt
<soren> Keybuk: How about lkml?
<rtg> cjwatson: Thanks. I'll see what I can figure out
<Keybuk> soren: not appropriate for that?
<soren> Keybuk: You sent all the similar ones further upstream, didn't you?
<Keybuk> soren: not the options ones
<soren> Keybuk: I noticed the one on the linux-bridge mailing list, so I assumed that was your general approach.
<soren> Keybuk: Oh, only aliases? I see.
<slangasek> rtg: is the libmpfr1ldbl package installed in this chroot?
<rtg> slangasek: libmpfr1ldbl                      2.4.0-1ubuntu3
<rtg> slangasek: hang on, lemme get inti the chroot
<Keybuk> soren: options are our own hacks, usually
<Keybuk> ie. ignoring HBA
<rtg> slangasek: indeed, it is not.
<cjwatson> bdmurray: my number dropped from 122 to 109, so I can confirm pitti's comment
<slangasek> rtg: ok - so either your chroot is broken, or something that's supposed to have a dep on that package is missing it
<cjwatson> hence why I was wondering if it was something to do with sponsored changes, for which that would seem about right
<soren> Keybuk: Right, good point.
<rtg> cjwatson, slangasek: that fixed it.
<slangasek> rtg: but it looks like there's a real bug here, that should also be fixed :)
<Keybuk> soren: if the nbd upstream think this option is the right default, they are the upstream for that kernel subsystem too :p
<bdmurray> I'll look into it then, thanks
<rtg> slangasek: I vote for the missing dep
<rtg> slangasek: is that a gcc package bug?
<soren> Keybuk: That's true :)
<slangasek> rtg: I'm not sure, because Contents-lpia.gz says that /usr/lib/gcc/i686-linux-gnulp/4.3.3/cc1 doesn't exist at all
<slangasek> ah, 4.3.3 -> 4.3
<slangasek> rtg: yeah, it's a bug in gcc-4.3
<slangasek> the cpp-4.3 binary is supposed to have this dep
<rtg> slangasek: so, I can annoy doko with it?
<slangasek> sure :)
<rtg> will do
<rtg> slangasek: why doesn't this fail in other chroots?
<slangasek> you mean other than lpia?
<rtg> yeah
<slangasek> apparently they have the right dep
<rtg> on the other hand, I also have not reinstalled other chroots from scratch recently
<slangasek> no, I just checked and i386's cpp-4.3 does have the dep
<rtg> why is lpia special?
<slangasek> I don't know
<Keybuk> soren: modinfo? no idea
<Keybuk> soren: ahh, yes I do
<Keybuk> modules.dep also happens to serve as a handy file that lists the full names of modules
<Keybuk> if you did "modinfo foo" it has to turn foo into the filename of a .ko
<cjwatson> slangasek: thanks for sorting it out before my debootstrap had finished ;-)
<highvoltage> heh
<slangasek> :-)
<soren> Keybuk: Ah, makes sense. Thanks.
<Keybuk> though why it uses that and not the .bin is probably just a mistake
<soren> Keybuk: It seems every time I think I've sorted out how all of that works, it changes completely.
<Keybuk> it doesn't change much ;)
<Keybuk> it's actually been pretty stable for a couple of years
<Keybuk> kernel source Makefiles import config and define what's built-in and what's a module
<soren> And I was *just* about to get it :)
<Keybuk> modules declare their parameters which are just static variables
<Keybuk> modules also declare tables of devices that they support
<Keybuk> this information ends up specially marked in the .ko
<Keybuk> so things like modinfo can pick it up
<Keybuk> depmod reads this information and turns it into the index files in /lib/modules/$(uname -r)
<Keybuk> previously this was all those modules.*map things
<Keybuk> then we got modules.alias
<Keybuk> now we use binary indexes
<Keybuk> the device tables are strings with wildcards in them
<Keybuk> pci:vXXXXdXXXX... and so on
<Keybuk> with any bits the module supports "any" of as a "*"
<Keybuk> devices themselves have the same style strings with all the bits filled in
<Keybuk> therefore loading the right module for a device is simply a matter of calling "modprobe $MODALIAS" (from the device)
<Keybuk> and letting modprobe do the fnmatch() against the wildcarded aliases it has in its list
<Keybuk> it sorts those based on modules.order (the file from the kernel tree that lists the official order), then expands deps
<Keybuk> module loads
<Keybuk> and the kernel does basically the same thing again to bind the driver in the module to the device
<Keybuk> that's all there is to it ;)
<soren> What calls modprobe? udev?
<Keybuk> right
<Keybuk> devices have kobjects associated with them when their subsystem discovers/detects/adds them
<Keybuk> the add of the kobject makes it show up in /sys
<Keybuk> and triggers a uevent (netlink message to userspace) informing it of the new entry in /sys
<soren> Aha!
<Keybuk> udev picks that up, and one of the rules tells it that any entry in /sys with a MODALIAS has modprobe called
<soren> I knew about the kobject->sysfs mapping, but didn't know about the link to udev and from there to modprobe. That's clever.
<Keybuk> udev also gets messages from the kernel when any object in /sys is removed
<soren> You realise, of course, that now that I'm at the brink of understanding all of this, it will inevitably change completely, right?
<soren> I'm just saying.
<Keybuk> and "change" messages when the subsystem feels that the object has changed significantly enough for userspace to care
<Keybuk> as well as loading modules if there's a MODALIAS
<Keybuk> udev also creates nodes in /dev if there's a MAJOR/MINOR pair
<Keybuk> (and removes them again on remove)
<Keybuk> as well as all sorts of other interesting and fun things
<Keybuk> the latest bit of udev fun (which davmor2 *adores*) is that udev creates inotify watches on block devices it makes
<Keybuk> ie. /dev/sda1, /dev/md0, /dev/mapper/root, etc.
<soren> Why?
<Keybuk> if something opens the block device for writing, then when it closes it again, udev triggers a "change" event on the sysfs object
<Keybuk> (and thus reacts to it itself)
<soren> Oh. That sounds potentially useful.
<Keybuk> ls -l /dev/disk/by-uuid
<davmor2> soren: because it hates me being able to run one test after another :)
<Keybuk> 1234-5678 -> /dev/sda1
<Keybuk> mkfs /dev/sda1
<Keybuk> ls -l /dev/disk/by-uuid
<Keybuk> dead-beef -> /dev/sda1
<soren> Keybuk: Cool. This is a recent change, isn't it?
<Keybuk> ie. udev runs vol_id on block devices to find out what's in them
<soren> Keybuk: Right.
<Keybuk> if you write to the raw block device, it'll run vol_id again to see what you changed
<Keybuk> and update things like it's symlinks
<Keybuk> this means /dev/disk/by-* now automatically update
<soren> Keybuk: I'm rather sure I've mkfs'ed something before and had to poke udev before the symlinks were updated.
<superm1> Keybuk, so if you say write a new mbr  to a device, you wouldnt need to use sfdisk to re-read the partition table again?
<soren> I might have been a while, though. Like a year or so.
<Keybuk> and will mean that the Emergency-HAL-Hologram will be always up to date ;)
<soren> superm1: You've always been able to do that with blkdev.
<Keybuk> superm1: if you change the partition table, you still need to tell the kernel you've done it
<soren> superm1: Err... blockdev, I mean.
<Keybuk> udev doesn't do that
<superm1> Keybuk, okay that's what I was thinking.
<Keybuk> soren: easier with partprobe ;)
<Keybuk> soren: right
<Keybuk> this is very new stuff
<Keybuk> ie. the last three upstream releases of udev or so
<soren> Keybuk: So post-intrepid for us.
<soren> Ok, that explains. Cool stuff, though.
 * soren needs to run for a while...
<doko> calc: does it fail on i386?
<doko> rtg: current package in jaunty?
<rtg> doko: which package? gcc-4.3.3 ?
<doko> rtg: I don't know, you did raise the issue ...
<rtg> doko: https://bugs.edge.launchpad.net/ubuntu/+source/gcc-4.3/+bug/343724
<ubottu> Ubuntu bug 343724 in gcc-4.3 "gcc-4.3 does not depend on libmpfr1ldbl for the LPIA arch" [Undecided,New]
<rtg> dunno if my analysis is correct
<calc> doko: only fails on i386 it works on amd64
<doko> calc: so no buildd problem?
<calc> doko: fails seemingly every time on i386 and passes every time on amd64
<calc> doko: buildd fails since it is i386
<calc> doko: also fails for me in testing on i386 (to be clear)
<doko> dh_shlibdeps -pgcc-4.3
<doko>  /etc/magic, 4: Warning: using regular magic file `/build/buildd/file-4.26/debian/tmp/usr/share/file/magic'
<doko> dh_gencontrol -pgcc-4.3 -- -v4.3.3-5ubuntu3 '-Vgcc:Version=4.3.3-5ubuntu3' '-Vgcc:EpochVersion=1:4.3.3-5ubuntu3' '-Vgcc:SoftVersion=4.3.3-1' '-Vgpc:Version=' '-Vgdc:Version=' '-Vgcj:Version=4.3.3-5ubuntu3' '-Vgcj:SoftVersion=4.3.3-1' '-Vgcj:BaseVersion=4.3' '-Vgnat:Version=4.3.3-5ubuntu3' '-Vbinutils:Version=2.19.1' '-Vdep:libgcc=libgcc1 (>= 1:4.3.3-5ubuntu3)' '-Vdep:libgccbiarch=' '-Vdep:libcdev=libc6-dev (>= 2.5)' '-Vdep:libcb
<doko> iarch=' '-Vdep:libcbiarchdev=' '-Vdep:libunwinddev=' '-Vdep:libcxxbiarch=' '-Vdep:libcxxbiarchdbg=' '-Vdep:libgnat=' '-Vdep:ecj=libecj-java (>= 3.3.0-2)' '-Vdep:libgomp=libgomp1 (>= ${gcc:Version})' '-Vdep:gcj=gcc-4.3 (>= 4.3.3-1)'
<doko> dpkg-gencontrol: warning: unknown substitution variable ${dep:libssp}
<doko> dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
<doko> dpkg-gencontrol: warning: unknown substitution variable ${gcc:multilib}
<doko> so there seems to be a problem with dh_shlibdeps
<doko> rtg: ^^^
<doko> no package has the shlibs:Depends information
<doko> see http://launchpadlibrarian.net/23822107/buildlog_ubuntu-jaunty-lpia.gcc-4.3_4.3.3-5ubuntu3_FULLYBUILT.txt.gz
<rtg> doko: thats quite a bit outside of my skill set. shall I just assign the bug to you?
<doko> rtg: yes, please do. will make a no change upload to the PPA first to see if this is a buildd issue
<rtg> doko: done. feel free to change the bug subject if I've not gotten it correct.
<rtg> kirkland: why do my chroots annoy me with ecryptfs cruft after exiting the session: 'keyctl_search: Required key not available. Perhaps try the interactive 'ecryptfs-mount-private'
<rtg> intrepid host, jaunty chroot
<bryce_> morning rtg
<rtg> bryce_: no update from Alex yet this morning
<bryce_> I see he put out 6.12.0 over the weekend, so I'll be merging that in today
<rtg> bryce_: thats an xorg driver?
<bryce_> yes
<doko> slangasek: any update on #328035 ?
<doko> rtg, slangasek, infinity: lpia is broken, no recently built package has the shlib:Depends substituted
<pitti> eww!
<Riddell> bryce_: pitti mentioned there were new intel drivers that needed testing, do you know where I'd find them?
<doko> first broken upload is network-manager_0.7.1~rc3-0ubuntu1
<doko> just after the file upload
<NCommander> ScottK, ping?
<ScottK> NCommander: Pong.
<NCommander> ScottK, feel like considering a feature freeze exception? I need a new package to go into the archive (well, two).
<NCommander> (I also need a second +1 on REVU)
<ogra> NCommander, i think our mobile-team delegate is StevenK
<ScottK> Probably not, but I assume you wouldn't ask unless it was important ....
<ogra> (though i'm sure ScottK can overrule)
<ogra> ScottK, it is
<NCommander> ogra, I thought for delegations only applied for existing packages; they need the team support for new
<ScottK> If it's for Mobile, then I'd say talk to your delegate first.
<NCommander> (I may be wrong)
<ScottK> NCommander: Nope.
<NCommander> Oh
<NCommander> Well
<NCommander> ScottK, can you +1 my package?
<ScottK> Particularly if it's StevenK then he can also agree to New them and not impact anyone else ....
<ScottK> NCommander: Not right now.  Maybe tonight.
<NCommander> ScottK, thanks
<ogra> ScottK, would be really appreciated by the ARM branch of our team :)
<ScottK> NCommander: What package?
<NCommander> ScottK, ecosconfig-imx
<ogra> http://revu.ubuntuwire.com/p/ecosconfig-imx
<NCommander> ScottK, http://revu.ubuntuwire.com/p/ecosconfig-imx
<ScottK> Thanks.
<NCommander> Ooh, ogra beat me to it
<ogra> :)
<NCommander> thanks ogra (BTW, you still haven't plused 1 it :-P_
<pitti> Riddell: Do you figure I can remove the X-KDE-SubstituteUID=true from jockey-kde's .desktop, now that there's a working policykit-kde?
<ogra> NCommander, ??
<NCommander> ogra, on REVU
<ogra> NCommander, i checked the "advocate this upload" box
<ogra> what else do i need to do nowadays ?
<NCommander> Oh, you did?
 * NCommander just didn't refresh in the last 30 seconds
<NCommander> :-)
<ogra> heh
<NCommander> wow, nifty
<NCommander> on needs-packaging bugs, if you have a *package*/ubuntu branch, it auto assiocates the branch.
<ScottK> NCommander: I don't suppose you'd be able to look at kdeaccessibility on armel?  FTBFS due to what looks like your speciality.
<Riddell> pitti: good question.  just needs testing I guess.  remind me again how I'd test it?
<NCommander> ScottK, sure, I've been meaning to look at it, but things have been a little crazy.
<ScottK> OK.  Good.
<ScottK> NCommander: Amarok too if you feel motivated (it finally built on power pc).
<NCommander> ScottK, I'm going to make one final pass of the main ARM FTBFS (and any obvious fix universe ones) just before beta freeze
<ScottK> OK.
<NCommander> Riddell, you got five minutes? I need a +1 on REVU
<ScottK> Riddell: Make him fix kdeaccessibilty and amarok on arm first.
<ScottK> ;-)
<pitti> Riddell: just remove the X-KDE-SubstituteUID=true from the .desktop, or call "jockey-kde" as user from a terminal, and try to install a driver
<pitti> Riddell: if you don't have nvidia/ati, I can toss you a test driver
 * cjwatson attempts to think of a sane way to detect UTF-8 strings that are not also ASCII strings using only the facilities in busybox
<cjwatson> (so no iconv, which would make it easy)
<pitti> Riddell: you can drop http://people.ubuntu.com/~pitti/tmp/pkg.py into /usr/share/jockey/handlers/, sudo killall jockey-backend, and try to install that handler
<cjwatson> really I suppose all I need is a bytewise check for top-bit-set bytes
<pitti> Riddell: it'll just install pmount
<NCommander> cjwatson, I thought busybox had an iconv module (although if we compile it in is another story)
<pitti> cjwatson: I had that problem a while ago and eventually just resorted to perl :(
<cjwatson> NCommander: it does not
<cjwatson> maybe LC_ALL=C tr '\0-\177' '' and check for equality
<cjwatson> hmm I mean tr -d '\0-\177' obviously, although that doesn't seem to work
<Riddell> pitti: doesn't seem to work with or without sudo :(
<Riddell> pitti: if I click Activate the list item is greyed out and nothing else happens
<pitti> Riddell: uuh; I guess I'll take a close look at jockey-kde tomorrow morning on my box
<ogra> cjwatson, dd and stty magic ?
<ogra> i assume there is a reciepe for conversion somewhere
<ogra> but it will be a slow bloated parser script
<cjwatson> tr -cd '\000-\177' works in coreutils tr but not busybox. hmm.
<cjwatson> ogra: I certainly don't want to do full-blown conversion by hand
<ogra> yeah, its painful
<estan> hm. i've built my own linux-ubuntu-modules package, is there a way to forcefully replace the one i have installed with my own using dpkg? sorry i'm a bit new to debian stuff.
<estan> trying to remotely help a friend get his webcam working on his old hardy laptop, i'm suspecting the camera is in fact supported by the gspca module, just that the model id is not recognized, so i'm patching the driver and rebuilding a linux-ubuntu-modules package for him to test.
<Stskeeps> dpkg -i file.deb? :P
<estan> and also, why is there no Ubuntu-2.6.24-23.48 tag in linux-ubuntu-modules ? (e.g. git tag | grep Ubuntu*)
<estan> Stskeeps: uhm. that easy huh? ;)
<Stskeeps> if i understand you correctly :P
<estan> indeed it seems it's working.. man his laptop is a slow piece of crap, heh.
<estan> ok. i haven't actually done the modification yet, just want to see that i can build a deb first.. so after i do the modification, and then build it again, i can just install it with dpkg -i again, or will it complain that it's already installed?
<estan> (i'm building the deb with `debian/rules binary-debs`)
<estan> err i mean: fakeroot debian/rules binary-debs flavours="generic"
<cjwatson> estan: dpkg -i will upgrade if it's already installed, yes. (also, #ubuntu ...)
<estan> cjwatson: alright. thanks.
<mpt> Can anyone tell me what the process is for getting something into Ubuntu's release notes?
<estan> cjwatson: hm. do you know how i can kick it into building the modules again after i made a modification? just running fakeroot debian/rules binary-debs flavours="generic" again it doesn't seem to pick up that there's been modifications (i.e. it's not running make again).
<doko> ohh, all ppa buildds used by mozilla ...
<cjwatson> estan: you may have to remove a stamp file. Look at debian/rules.d/2-binary-arch.mk or whatever it is to see what file the relevant target touches.
<estan> ah figured it out, just removed debian/stamps/stamp-build-generic.
<cjwatson> mpt: open a bug task on the ubuntu-release-notes project, preferably with suggested text although it isn't mandatory. It's best if it's a task on some existing bug that documents the problem so that it's all right there for us
<mpt> thanks cjwatson
<kees> doko: so if I figure out how to fix 3 regressions (out of 3900 tests) you'll enable fortify for openjdk-6 again?
<Riddell> tjaalton: do you know about the new intel driver that needs testing?
<doko> kees: sure. maybe I should do the same with gcc-4.3 so you fix these regressions as wel ;p
<doko> I don't mind jdi regressions if there are any.
<kees> doko: gcc> please don't.  :P
<kees> ct
<kees> erk
<kees> cjwatson: any update on how to move forward with the compiler mismatch in hardy?
<cjwatson> kees: given security team signoff (which I have, right?), I think it's in my queue to Just Do
<ryu> hi
<cjwatson> kees: do I need to give you a couple of hours' warning or something for a USN?
<slytherin> can any of the core developers please give back update-manager on powerpc? the build failure looks to be some archive problem.
<cjwatson> kees: and intrepid is affected according to the most recent mails on the bug. I don't get it - that wasn't a major version bump
<cjwatson> slytherin: looks more like some kind of chroot breakage to me? I think the python-distutils-extra package should be checked on powerpc before give-back to make sure there isn't anything else wrong with it
<slytherin> cjwatson: I am currently building the package just to make sure.
<slytherin> cjwatson: build failed with totally different error :-(
<slytherin>  - make[1]: Leaving directory `/tmp/buildd/update-manager-0.101.0/po'
<slytherin> cp: cannot stat `/usr/share/jockey/modaliases/nvidia-*': No such file or directory
<slytherin> make: *** [binary-indep] Error 1
<kees> cjwatson: just let us know when it's been copied.  it's going to be a rather weird USN anyway.
<cjwatson> kees: done, for hardy-security
 * kees holds onto his hat
<jturek> exit
<ion_> Is jaunty going to use Firefox 3.1 by default? 3.1 is already in beta and gutsy was released with 3.0 *alpha*.
<ion_> Oh, sorry. It seems i remembered incorrectly. Gutsy didnât use 3.0 by default after all.
<ScottK> ion_: Hardy was released with 3.0 beta but only because 2.0 support wouldn't be long enough for an LTS.
<ion_> Ok
<cjwatson> also firefox 3.0 beta in hardy got negative feedback in practically every single review of Ubuntu. (I still think it was the right thing to do, and have defended it in a number of places; but all the same we'd need a good reason)
<tjaalton> Riddell: no, but I think bryce has one in his ppa
<bryce> heya tjaalton
<bryce> tjaalton: what's that in reference to?  I've just put -ati 6.12.0 into ubuntu.
<bryce> tjaalton: if it's in reference to -intel 2.6.3, no that won't build until we get some kernel changes in
<tjaalton> bryce: hey, yeah he asked about -intel
<Riddell> tjaalton, bryce: I'm getting funny corruption on qt apps, which I don't think anyone else is getting and wondered if it was down to something in X
<bryce> Riddell: seems likely
<bryce> Riddell: if you're using EXA, try UXA.  If using UXA, try EXA.
<bryce> a lot of corruption issues go away when moving to UXA
<bryce> unfortunately, it brings its own set of issues, so isn't something we can just upgrade to safely
<Lure> Riddell: something like bug 279727 - I have this too
<ubottu> Launchpad bug 279727 in xserver-xorg-video-intel "Display Corruption w/ Intel 4700MHD" [Undecided,Confirmed] https://launchpad.net/bugs/279727
<Riddell> Lure: that could be it, although he has it much worse than I do
<Lure> Riddell: I get this from time to time and also a bit less than the screenshot
<directhex> slangasek, do you have any packages you can suggest as examples for coping with symlink->dir transition properly?
<cjwatson> directhex: symlink->dir not dir->symlink?
<directhex> cjwatson, aye. symlinked docdirs in mono packages in past ubuntu releases are apparently a big debian policy nono, and moving to unsymlinked is causing problems on upgrades
<cjwatson> directhex: just check if it's a symlink in the preinst and rm it
<directhex> preinst? gotcha
<cjwatson> directhex: right, then dpkg-deb unpacks the tarball after the preinst has run, and it sees "aha, nothing there, I shall unpack the new directory"
<cjwatson> directhex: oh, hmm, one other thing for correctness
<cjwatson> two other things actually :-)
<cjwatson> directhex: firstly, you'll be doing this in preinst install|upgrade, but add a dpkg --compare-versions guard too
<cjwatson> directhex: secondly, you should reverse the action in postrm abort-install|abort-upgrade, with the same version guard
<directhex> cjwatson, meebey's currently spouting version comparisons at me in #debian-mono
<directhex> ;)
<directhex> okay, ta for tips
<cjwatson> presumably 'if dpkg --compare-versions "$2" lt-nl "version you made this change in"'
<cjwatson> bigon: infinity has resolved my RT ticket about removing python2.5-minimal from chroots
<Laney> any inside info on the broken i386 buildds?
<soren> Laney: They're not b0rken. fontconfig is, apparantly.
<seb128> hey, asac broke fontconfig apparently
<seb128> not only i386
<seb128> all builds are failing on all arches ...
<Laney> heh
<Laney> alright
<Laney> I've just had failure mails for i386 so far
<Laney> oh, others are more backed up is all
<seb128> I just got 17 build failure emails
<seb128> asac 1 - 0 soyuz
<Laney> awesome
<JanC> eh, does that mean the currently available fontconfig packages are broken or fixed again?  :P
<asac> JanC: upgrades seem to be not the issue .. rather fresh installs on the buildds
<JanC> ah, okay, just wondering if installing those was a good idea  ã
<asac> JanC: which version are you running?
<JanC> 2.6.0-1ubuntu5, but 2.6.0-1ubuntu7 is available now
<slangasek> doko: no, 328035 will take me a while to find time for
<slangasek> directhex: not offhand.  But the rune is preinst: rm -f $symlink
<petski> bdmurray: your last change to https://wiki.ubuntu.com/Bugs is incorrect
<bdmurray> petski: I see, fixing
<petski> bdmurray: ok :) thanks
<directhex> slangasek, cjwatson, it's the edge cases like abort-install that concern me. "just an rm" is easy, but also a little unlikely to fly
<cjwatson> directhex: I'm pretty sure what I described is complete
<directhex> cjwatson, at least i have one cheat up my sleeve - the test for "affected" versions is reasonably simple, as only XubuntuY packages below 2.0 are affected, i can use that in the test
<cjwatson> I can't find any examples that get rollback right
<cjwatson> which is a bit sad
<directhex> i'm not 100% sure how to deal with rollback cleanly
<slangasek> directhex: every version up to the current version is affected...
<cjwatson> directhex: just as I described above?
<directhex> slangasek, you're right, i wasn't considering full semantics properly
<cjwatson> 21:49 <cjwatson> directhex: secondly, you should reverse the action in postrm abort-install|abort-upgrade, with the same version guard
<calc> does the lpia build problem mean we need to upload all those source packages again, or does Ubuntu have the concept of a binNMU for cases like this?
<cjwatson> i.e. ln -s there
<cjwatson> maybe ln -nsf || true for safety
<slangasek> calc: they'll have to be reuploaded
<calc> fun... new OOo needed then
<calc> is there a reason we don't support binNMUs?
<infinity> calc: Because the times when they might be useful don't outweigh the annoyance of source<->binary mismatches, when we don't actually have issues with architectures that can't keep up.
<infinity> calc: (And the more entertaining side-note is that you usually want binNMUs on the slow arches ANYWAY, so it's not saving them much)
<directhex> so i need 90 new preinsts...
<calc> infinity: ok
<calc> unless someone decides they want to upload OOo i'll leave it until I do a new upload sometime in the next week
 * calc is sure the buildds could use some rest from the multiple rebuilds of OOo lately
<calc> esp arm ;-)
<bigon> cjwatson: ok thx :)
#ubuntu-devel 2009-03-17
<Amaranth> tjaalton: wtf, DRI2 doesn't support sync to vblank? I thought intel wanted to have everything do sync to vblank
<e1z0_> hi
<kees> Keybuk: hrrrm.  I encountered an md/udev race failure this morning on reboot.  one of my raids wasn't all the way up (1 dev of 2), yet the 2nd (missing) device existed.  seems like md's incremental bring-up failed.
<kees> rebooted again and it went away (didn't get unlucky that time)
<Arkain> exit
<pitti> Good morning
<dholbach> good morning
<dholbach> does anybody know what do do about  http://paste.ubuntu.com/132328 ?
 * maxb wonders if this FTBFS error means anything to anyone - is it just skew in arch-all vs arch-specific dependencies getting published? - http://launchpadlibrarian.net/23960162/buildlog_ubuntu-jaunty-amd64.totem_2.26.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<maxb> (likewise lpia, ia64, ftr)
<RAOF> How old is that log?  libgtk2.0-0 >= 2.15.0 should have been satisfiable for some time.
<maxb> less than 12 hours old
<RAOF> Oh.  Don't mind me.  I can't read properly.
<maxb> likewise gnome-panel and evolution-data-server - though it seems gnome-panel/amd64 may have been given back already
<slytherin> maxb: yes, it looks like the skew in publishing.
<maxb> Oh, e-d-s is all successfully built now
<slytherin> who maintains the package human-icon-theme? There is a small problem in that package which is too small to file a bug.
<pitti> slytherin: what's the problem?
<slytherin> pitti: typo in filename - ./scalable/apps/gnome-session-hebirnate.svg
<pitti> slytherin: uploaded
<slytherin> pitti: thanks
<maxb> What is the right channel to suggest give-backs? here?
<tjaalton> maxb: probably so, yes
<slytherin> maxb: depends on the component, main/restricted here, universe/multiverse in #ubuntu-motu
<maxb> If so: https://launchpad.net/ubuntu/+builds?build_text=totem&build_state=all and https://launchpad.net/ubuntu/+builds?build_text=gnome-panel&build_state=all <-- totem/{amd64,ia64,lpia}, gnome-panel/{ia64,lpia}, all appearing to be fails due to publishing skew
<tjaalton> maxb: given back
<maxb> thanks
<maxb> tjaalton: launchpad doesn't seem to agree that gnome-panel/lpia has been given back. The other 4 are, though
<maxb> oh, now it does
<maxb> caching, I suppose
<tjaalton> nah, just forgot to apply :)
<tjaalton> too many tabs
<bryce> how does one make a bash script translatable?
<bryce> #!/bin/bash
<bryce> echo "Hello world"
<bryce> is there a way to turn that into something that can be translated?
<slytherin> seb128: good morning
<ion_> bryce: I have a faint memory of seeing some sh script use gettext.
<bryce> so like
<bryce> echo $(gettext "Hello world")
<bryce> ?
<seb128> hey slytherin
<ion_> bryce: . /usr/bin/gettext.sh; eval_gettext foo probably.
<slytherin> seb128: bad news, all the updates installed, dvd playback didn't work for me last night.
<seb128> slytherin: not really bad news so you can still debug it ;-)
<seb128> slytherin: I will try on my desktop when 2.26 updates are done
<slytherin> seb128: sure, I will upload my modified package to my ppa tonight so that you can do the analysis whenever you get time. I am not very good at C and autotools
<seb128> ok thanks
<bryce> ion_: thanks
<ion_> bryce: You probably already noticed this, but the eval_ variants substitute shell-style variables in the strings from callerâs environment. If that is not needed or wanted, just use gettext directly.
<bryce> ion_: yep, thanks
<taavikko> seb128: any info if vino can use ssh-keys only to authorize usage on remote-desktop?
<seb128> taavikko: no idea I never tried that
<taavikko> vino used to have it IIRC in intrepid.. Now only password for security
<taavikko> might as well check changelogs and such to figure it out, there's nothing like added security...
<directhex> slangasek, i'm thinking i'd like to put off this docdir problem for another cycle - i.e. merge mono, and re-add the symlink magic so the issue goes away until karmic
<directhex> i'd need to maintain SOME kind of workaround up until loquatious lombax anyway, since i need to support upgrades from hardy. so the first release where it stops mattering is masticating mastodon.
<DreadKnight> updates ate my totem :O
<slytherin> DreadKnight: what do you mean by ate?
<directhex> om nom nom
<DreadKnight> totem got removed.. and many more stuffs will get removed as well if i update.. i guess dependencies need to be sorted out
<slytherin> DreadKnight: dependencies are fine. you upgraded in the middle of large uploads related to gnome
<DreadKnight> slytherin, indeed
<slytherin> DreadKnight: so wait for another day by when these uploads will be finished probably.
<DreadKnight> ok thanks
<pitti> thekorn: thanks for your reply wrt. wadllib and nose; nose fixed now
<pitti> thekorn: however, now I have bug 344166 :-(
<ubottu> Launchpad bug 344166 in wadllib "test suite for iso_strptime fails" [Undecided,New] https://launchpad.net/bugs/344166
<thekorn> pitti: this smells indeed like just another python2.6 incompatibility
<pitti> thekorn: right; just followed up on the bug
<thekorn> time.struct_time == tuple does not seem to work anymore
<pitti> right, time.localtime() is the same effect
<pitti> thekorn: I think I'll just update the docstring accordingly
<thekorn> sounds good
<pitti> thekorn: ah, with print() it works
<pitti> ah, no, ignore me
<thekorn> pitti: maybe tuple(d.timetuple()) works for all python versions
<thekorn> can't check python2.6 here
<pitti> thekorn: ah, indeed
<MacSlow> mvo_, hey Michael
<MacSlow> mvo_, this one https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/331564 is due to the missing patch for notify-osd to be part of the window-match rules for the animation-plugin
<ubottu> Ubuntu bug 331564 in compiz "sometimes notification flickers when fading in" [High,New]
<MacSlow> mvo_, did you have to drop my patch I sent you, because it didn't apply anymore?
<MacSlow> mvo_, I can redo it, if you want and send you the new one
<Mirv> could someone review https://code.launchpad.net/~timo-jyrinki/example-content/folder_i18n/+merge/4416 before beta freeze, since it's a biggish change in how the package is built?
<tkamppeter> Can someone please fix the e-mail notification of Rosetta? I get 66 spam mails on every upload of system-config-printer.
<cjwatson> tkamppeter: you're not the only one waiting for a fix, and this channel is not empowered to fix it
<cjwatson> the fix has landed in trunk and we're waiting for a rollout
<wgrant> cjwatson: Why wasn't it cherrypicked? There's still two weeks until the next release...
<elmo> wgrant: asking the wrong people
<tkamppeter> cjwatson, OK. Then I know that it will be fixed soon.
<dholbach> Mirv: I just had a look at your example-content branch - is there an easy way to test this on a livecd?
<wgrant> elmo: Well, he seemed well informed of the situation otherwise.
<cjwatson> wgrant: I know little more than the above and have already been badgering people
<mvo_> MacSlow: I will double check, it should not be dropped, but patches where shuffled around due to the 0.8.2 release
<Mirv> dholbach: the live cd part is afaik not affected really, since that's only about installing the /etc/skel file which gets installed on users' home folders. I guess the live cd symbolic link on the desktop is not done by example-content, so the original title of the bug is a bit wrong.
<Mirv> (which leads me to update the bug title to something more sophisticated, though it's explained in the comments)
<cjwatson> Mirv: casper does     mv /root/home/$USERNAME/Examples /root/home/$USERNAME/Desktop/
<dholbach> Mirv: ah right, so it might need changing in casper
<cjwatson> Mirv: therefore it would need to be updated if Examples changed
<cjwatson> (preferably in a way that copes with both old and new)
<Mirv> cjwatson: ok, so it should be updated in casper as well then, if that symbolic link is now changed into examples.desktop
<dholbach> cjwatson: Mirv's idea was to change to a translatable .desktop file instead of a symlink to the directory
<Mirv> I now updated the description to include what casper does, and that it would also need updating if examples.desktop is used
<cjwatson> dholbach: yes, I read it
<dholbach> ok
<Mirv> and in the bug report there is this link to the change in use: http://launchpadlibrarian.net/23784986/Kuvakaappaus-test%20-%20tiedostoselain.png (icon could be changed if the default link icon is not wanted)
<cjwatson> I haven't reviewed the branch but assuming that casper is changed as well then it all makes complete sense to me
<dholbach> Mirv: I'll play with it some more and let you know what I find
<ogra> Keybuk, so i still see a 11sec modprobe run in my bootchart in jaunty (making my boot take 33sec)
<ogra> Keybuk, http://people.ubuntu.com/~ogra/osiris-jaunty-20090317-1.png
<Keybuk> ogra: could you throw me the tarball and udev log?
<ogra> Keybuk, sure
<ogra> Keybuk, http://people.ubuntu.com/~ogra/osiris-jaunty-20090317-1.tgz and http://people.ubuntu.com/~ogra/udev
<ogra> Keybuk, i see a long pause in the early stage of usplash
<ogra> which seems to match the udev/modprobe delay shown in the bootchart
<Keybuk> add      /devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/0003:1CB6:6680.0003 (hid)                                              0.45  10.63  10.19
<Keybuk> add      /devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0 (usb)                                                                  0.02  10.63  10.61
<Keybuk> add      /devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/usb_endpoint/usbdev5.2_ep81 (usb_endpoint)                             0.02  10.63  10.61
<Keybuk> what's the device?
<Keybuk> could you give me the modalias of it
<Keybuk> (ie. cat /sys/blah/modalias)
<ogra> Keybuk, like that ? ogra@osiris:/var/build/babbage$ cat /sys/bus/usb/devices/5-1\:1.0/modalias
<ogra> usb:v1CB6p6680d0100dc00dsc00dp00ic03isc00ip00
<ogra> i have a usb mouse and usb kbd plugged in atm ... additionally the laptop has a touchscreen and fingerprint reader that are usb devices
<Keybuk> 11.63..22.15  1680 (modprobe)
<Keybuk> it's a single modprobe call
<ogra> oh, and a usb->serial adapter
<Keybuk> hmm
<ogra> but neither of them takes 10 secs when hotplugged
<ogra> (touchscreen and fingerprint reader are indeed not hotpluggable :) )
<Keybuk> is there a /sys/devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/0003:1CB6:6680.0003/modalias ?
<ogra> Keybuk, ogra@osiris:/var/build/babbage$ ls /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/0003\:1CB6\:6680.0003/
<ogra> driver  power  subsystem  uevent
<Keybuk> ogra: what about the other two?
<Keybuk> ogra: what's the driver symlink expand to?
<ogra> ogra@osiris:/var/build/babbage$ cat /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/modalias
<ogra> usb:v1CB6p6680d0100dc00dsc00dp00ic03isc00ip00
<ogra> ogra@osiris:/var/build/babbage$ ls -lh /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/0003\:1CB6\:6680.0003/driver
<ogra> lrwxrwxrwx 1 root root 0 2009-03-17 13:44 /sys/devices/pci0000:00/0000:00:1d.2/usb5/5-1/5-1:1.0/0003:1CB6:6680.0003/driver -> ../../../../../../../bus/hid/drivers/generic-usb
<ogra> no modalias in /sys/devices/pci0000\:00/0000\:00\:1d.2/usb5/5-1/5-1\:1.0/usb_endpoint/usbdev5.2_ep81/
<ogra> Keybuk, ah, lshal seems to tel mee its the touchscreen
<Keybuk> yeah, that's what it looks like to me
<ogra> which has no particular driver, it just registers as /dev/input/eventX with the hid driver normally
<Keybuk> you're stuck inside kernel driver init() at that point
<ogra> (at least it did that up to intrepid)
<Keybuk> so iz kernel bug
<Keybuk> to test
<Keybuk> echo 'KERNEL=="0003\:1CB6\:6680.0003", OPTIONS+="last_rule"' > /etc/udev/rules.d/00-ignore.rules
<Keybuk> see if that speeds it up
<Keybuk> without the \:s
<Keybuk> echo 'KERNEL=="0003:1CB6:6680.0003", OPTIONS+="last_rule"' > /etc/udev/rules.d/00-ignore.rules
 * ogra reboots
<ogra> Keybuk, err, i guess i need update-initramfs, right ?
<Keybuk> no, shouldn't do
<ogra> ok
<ogra> ehmmm
<ogra> since when is my computer supposed to skip the bios on reboots ?
<ogra> my machine just went from usplash in shutdown mode directly to usplash in bootup mode without powering off
 * ogra tries again
<ogra> hmm, i'm confused
<ogra> same behavior
<Keybuk> try different udev rules to match the device
<Keybuk> it may be any of those three
<Keybuk> or even all of them
<ogra> well, first i would like to be able to switch off my computer
<ogra> it just jumps from one usplash to another and boots up directly ... there is no BIOS or power down inbetween
 * ogra scratches head
<ogra> oh, ah !
 * ogra apt-get removes kexec-tools :P
<ogra> thats funny ... i didnt know it had that effect
<hyperair> seb128: ping.
<ogra> ok, next try
<seb128> hyperair: contextless ping = no pong
<hyperair> seb128: that's pong enough for me ;)
<hyperair> seb128: regarding nautilus-share... you've added some stuff to debian/rules
<hyperair> seb128: something about intltool. could you tell me what that's about?
<hyperair> seb128: examining the debs with/without the intltool stuff seems to show no difference
<seb128> hyperair: it's about building a translation template after the build which rosetta imports
<seb128> hyperair: so the strings are listed on rosetta for translation
<seb128> hyperair: we do that for everything in main actually, why?
<hyperair> seb128: i just adopted nautilus-share in debian, and am updating
<hyperair> seb128: this is one of the things i'm not sure about. the other is that your diff.gz seems to have config.guess/config.sub changes. why is that?
<seb128> hyperair: cdbs magic I guess
<seb128> that's a debian thing
<seb128> the clean target might be buggy or something
<hyperair> seb128: no... it seems that it's an ubuntu-only change
<ogra> Keybuk, hmm, the one rule didnt change a thing
<seb128> hyperair: it's nothing we did it's coming from the build system, as said probably buggy clean target
<seb128> hyperair: try to debuild && debuild clean && debuild in debian
<seb128> hyperair: and see if you get the same
<seb128> hyperair: debian build tools update those when they are outdated
<hyperair> regarding the clean target, i found a snippet in clean which does that
<seb128> well dunno and I don't care
<seb128> config.guess and config.sub has updated at build time using the system version if outdated
<hyperair> http://pastebin.com/f47525987
<seb128> that change is just noise, not useful not creating an issue
<hyperair> okay then i'll leave it out
<seb128> I don't care enough to look at why it's there ;-)
<seb128> it's not an on purpose change
<seb128> but it's not an issue
<seb128> you can take the intltool update call though
<ogra> Keybuk, is there a way to match on "product" ?
<seb128> it's not useful in debian but doesn't cost a lot
<seb128> and so we can probably sync or lower delta
<hyperair> seb128: alright then.
<ogra> Keybuk, or on something shorter (like 0003:1CB6 only)
<ogra> Keybuk, nope, no speedup
<unCONDITIONAL> yo
<directhex> that was productive :|
<jelmer> slangasek: ping
<tvakah> I'm having a problem upgrading, dpkg --purge sivp results in: http://pastebin.com/f34bb92f1
<tvakah> adding --force-all changes nothing, and this package is currently sticking all the rest of today's updates
<tvakah> tried force installing scilab first in the thought that sivp needed to go first, scilab installs and purges jsut fine, but sivp still fails to purge
<tvakah> nvm, looks like upgrading sivp to 0.5 first then removing it will fix this
<BUGabundo> question: is update-manager supposed/able to jump from hardy to jaunty or any other future devel branch without going throuth all versions in between ?
<pitti> BUGabundo: LTS->LTS only, or going through all intermediate releases
<BUGabundo> pitti: thants
<pitti> tseliot: jockey currently disables nvidia 71 and 96; are they still busted?
<tseliot> pitti: 96 works while 71 doesn't
<pitti> tseliot: right, it checks "version < 96", sorry
<pitti> so it's still correct; thanks
<tseliot> pitti: np
<slangasek> jelmer: pong
<bdmurray> cjwatson, pitti: wrt to the bug fixing report I did fix an issue last week where duplicate bug tasks were being shown, perhaps that caused the change in quantity.
<cjwatson> ah, that would make sense
<doko> ubuntu-archive: please accept the xom binaries in NEW
<pitti> bdmurray: ah, entirely plausible; thanks
<bdmurray> let me know if you see any other drastic changes
<pitti> so now I have to break the 150 mark a second time :)
<bdmurray> some fluxuation due to bugs being reopened is possible but not a lot
<pitti> doko: thanks for fixing xom!
<doko> pitti: openjdk error, just a work around
<rtg> bryce: bug #334101 isn't really targeted to the right packages, is it?
<ubottu> Launchpad bug 334101 in xserver-xorg-video-ati "FFe: Xv and EXA not supported on R6xx/R7xx chipsets" [High,Fix released] https://launchpad.net/bugs/334101
<bryce> rtg: what would be the right packages?
<rtg> bryce: well maybe the package is correct, but why is my name assigned to it?
<asac> TheMuso: ping at-spi crash status? are there concerns with my patch?
<bryce> rtg: do you not use bug assignments for tracking bugs you're working on?  I can remove your name if it's a problem...
<rtg> bryce: I just keep getting all of these annoying emails about it :)
<bryce> rtg, sorry I know each team does things a bit differently, so may be assuming things
<rtg> bryce: well, my patch part is done, right?
<pitti> rtg: how else do you keep track of them, if not by email?
<rtg> pitti: my oblique point was that my name should not have been on this bug 'cause I don't have anything to do with (I think)
<rtg> with it
<MacSlow> mvo_, compiz uses quilt, right?
<pitti> ah, ok; I thought you wanted to merge the kernel bits
<bryce> rtg: this is the bug I've been using for tracking the r6xx/r7xx patch work stuff from Alex
<bryce> rtg: if you've uploaded those, then yeah the bug can be closed as fixed.  I'll take your name off too, to save you from any subsequent emails
<rtg> bryce: no, you're correct. I thought it was being tracked by another bug, but I see that I completely messed up.
<bryce> rtg: fwiw, when we do uploads in the X team, we typically need a bug report for the issue being fixed to reference in the changelog
<mvo_> MacSlow: yes
<bryce> rtg: so I was just thinking we could share this one, assuming you guys do similarly in kernel land (which may be a bad assumption on my part)
<rtg> bryce: during the dev process i don't always have a bug number, but I should have for this one.
<mvo_> MacSlow: "bzr bd-do " and then "export QUILT_PATCHES=debian/patches; quilt push 029_default_options"
<MacSlow> mvo_, ok I'll try to create a distro patch for the fade-plugin (which is part of compiz) to skip notify-osd windows if it is enabled
<bryce> ok cool
<mvo_> MacSlow: that should do the trick
<mvo_> MacSlow: and quilt add metadata/fade.xml.in afterwards
<mvo_> MacSlow: when you finished editing "quilt refresh"
<mvo_> quilt pop -a
<mvo_> exit
<mvo_> :)
<mvo_> sorry, quilt is a bit "verbose"
<pitti> MacSlow: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20(example%20package:%20xterm) FYI
<MacSlow> bzr bd-do didn't work
<davmor2> bryce: I've confirmed the fix for bug 309482 but I think it's linked to upstream too so do you still want it closing?
<ubottu> Launchpad bug 309482 in xserver-xorg-video-nv "jaunty: Kubuntu OEM enduser setup fails with black screen (nv driver fails)" [Wishlist,Fix released] https://launchpad.net/bugs/309482
<MacSlow> mvo_, I'm using an apt-get'ed compiz-source not a checked out branch
<MacSlow> this is gonna take long then I think
<MacSlow> pitti, ah... that was what I was looking for
<rtg> bryce: I can see now why my comment confused you. I guess I need some coffee :) I updated the report, but the bot won't update with a changelog 'cause I don't have a  bug number in the changelog.
<bryce> davmor2: yep, bug looks fine.  Upstream can pick up the patch from the upstream report whenever they'd like
<MacSlow> pitti, I remember to have read this once (about a year ag0)
<bryce> rtg: ah ok, then we can close it manually.  Do you have any comment to add?  If not I'd be happy to do the deed.
<pitti> rtg: ah, so 2.6.28-10 has the ati bits now? awesome
<rtg> bryce: I added the commit URL, beyond that I don't have anything more to say
<bryce> ok great
<rtg> p-itti-11 bits
<rtg> pitti: -11
<pitti> ah
<rtg> which will get uploaded later today
<elmo> cjwatson/wgrant/seb128/etc: the alleged LP fix for that rosetta spam has been CPed into production
<pitti> yohoo!
<mvo_> wonderful
 * pitti shuts down his 10 extra mail servers :)
<bryce> rtg: bug updated.  Thanks again :-)
 * seb128 hugs elmo
<MacSlow> mvo_, before I can successfully do "bzr bd-do" I've to "bzr branch lp:compiz" right? apt-get'ing compiz source will not get me the .bzr directory afaik
<mvo_> MacSlow: correct
<MacSlow> mvo_, I need to check that out _into_ the directory I got from "apt-get source compiz"?!
<mrooney> mvo_: hello fellow michael :)
<mvo_> MacSlow: no, just check it out and let bzr-buildpackage /bzr bd-do deal with all the rest :)
<mvo_> hey mrooney!
<pitti> bryce: can you please ping me when fglrx lands? then I'll re-enable it in jockey
<cjwatson> elmo: great, thanks
<bryce> pitti: will do.  Still waiting on the final drop from AMD, but expecting it today.
<pitti> bryce: right, not hurrying, just saying that we should coordinate this
<bryce> okie doke
 * pitti ^5s bryce
<Lure> MacSlow: https://wiki.ubuntu.com/Kubuntu/Ninjas/QuiltMagic
<MacSlow> mvo_, done
<MacSlow> mvo_, would it be enough to email you the updated file debian/patches/029_default_options ?
<MacSlow> Lure, thanks but I already finished it
<mvo_> MacSlow: yes, that is fine
<MacSlow> mvo_, sent
<mvo_> MacSlow: thanks, checking mail
 * MacSlow takes an evening-break
<mpt> MacSlow, mat_t: Do either of you know why the Jaunty live CD counts down at GDM, "ubuntu will log in in 10 seconds"?
<mpt> It's not as if you can really do much else
<ogra> mpt, i think thats a gdm restriction, autologin only works with timed login set, 10 sec is the smallest it accepts
<ogra> mpt, seb128 might know more about that
<mpt> hm, maybe I imagined it, but I thought the live CDs for previous Ubuntu versions skipped quickly past GDM
<ogra> the first boot shouldnt show that
<ogra> only if you manually logged out
<seb128> mpt: it does autologin
<mpt> yes it does
<seb128> so what do you do to get the count?
<ogra> doesnt count down here with an alpha6 image
<seb128> here either
<seb128> I did some CD testing for alpha6 and autologin worked correctly
<superm1> Keybuk, i'm seeing some weird udev behavior while in the initrd when running casper early scripts w/ 9.04 a6 testing.  stuff like where a call to "chroot /root/ parted -s /dev/sda rm 3" will hang for a few minutes, followed by a line "udevadm settle - timeout of 180 seconds reached, the event queue contains:" "/sys/devices/virtual/vc/vcs12".  any pointers, or recommendations to prevent this happening?
<ogra> though you get the countdown if you log out once
<Lure> can somebody give-back pyexiv2 (now that exiv2 0.18 binaries are published)?
<ogra> which is expected behavior (at least from former releases ... maybe not mpt expected behavior :) )
<Keybuk> superm1: no idae
<Keybuk> strange thing to hang on
<doko> ubuntu-archive: please accept jaxme binaries in NEW (-doc to main)
<Keybuk> what's in the process list?
<Keybuk> otherwise udevd --debug ftw
<mpt> seb128, I don't do anything special to get the count, I just choose "Try Ubuntu without any change to your computer" or whatever it's called
<Keybuk> either that, or udevd has crashed ;)
<superm1> Keybuk, well being in the middle of the initrd, I'm not sure I can pull another term up to check the process list or what not
<Turl> hi
<Turl> is it normal for nautilus-cd-burner to be uninstalled with the updates?
<Keybuk> superm1: it's not easy ;)
<ogra> break=top and do all steps manually :)
<seb128> mpt: ok, so that's a new bug
<seb128> mpt: is that daily CD?
<mpt> seb128, alpha 6
<seb128> weird
<superm1> ogasawara, i suspect some racey conditions though that i'm not going to expose unless i'm typing fast...  :)
<mat_t> mpt, dunno
<superm1> oops, ogra ^
<seb128> maybe xorg or the session is crashing
<Keybuk> superm1: random
<Keybuk> have you actually checked udevd is running?
<ogra> superm1, add a script to initramfs doing the same and call the script then
<seb128> mpt: does the login after the count work correctly or does it go back to gdm again?
<Keybuk> it only runs for a smallish part of the intird
<seb128> mpt: I would check your CD to start
<Keybuk> udevadm settle will wait for three minutes if udevd isn't running
<mpt> seb128, I ran a CD check first. I think the same thing happened with alpha 5, but I forgot about it.
<superm1> Keybuk, i see it on mostly atom hardware, i've not seen it on any regular laptops.  i'll add some checks into the the scripts to check for udev running and try to have it blurt things like that out every other command so I can see better
<seb128> mpt: ok so maybe xorg or gdm is crashing on first try, it goes back to gdm and do the counting
<seb128> mpt: I'm busy with GNOME 2.26 today so I will pass on debugging that for now but maybe somebody else can have a look to that with you
<Keybuk> superm1: you're playing around with the partition table inside the initrd?
<mpt> seb128, ok, thanks for the suggestions
<superm1> Keybuk, yeah... kind of have to for factory installs to make sure it's what ubiquity expects when it starts
<apw> slangasek, we have a checkbox update pending, and i am wondering who needs to be informed to make sure it hits the beta
<slytherin> pitti: is there any plan to update ekiga to 3.0.2? ekiga 3.2 is released today but there are too many features for updating this late in cycle. So we should at least get 3.0.2 (it adds settings migration from 2.x).
<seb128> slytherin: kenvandine_wk is working on getting 3.2 before beta I think, you think it's too late in the cycle?
<slytherin> seb128: looking at the changelog. I think there are too many features additions.
<kenvandine_wk> it is a long list
<slytherin> also it is unclear from changelog if the gstreamer support for audio/video capture is finished or not.
<NCommander> Any archive admins around to answer a licensing question? (I need to know if a four-clause BSD license is going to end up in universe or multiverse)
<NCommander> (I think its the later, but I'd like to make sure)
<IntuitiveNipple> Is there any way to get the new libx86-based read-edid package (which works on amd64 as well a x86/lpia) sponsored to replace the existing 32-bit only package? bug #242043
<ubottu> Launchpad bug 242043 in read-edid "[needs-packaging} read-edid-2.0.0 for amd64" [Wishlist,In progress] https://launchpad.net/bugs/242043
<NCommander> IntuitiveNipple, you need a feature freeze exception
<IntuitiveNipple> Who's best for that, would you say?
<NCommander> IntuitiveNipple, just subscribe to motu-release, and follow the feature freeze exception rules, and hope for the best
<IntuitiveNipple> right, thanks
<NCommander> IntuitiveNipple, if you get a freeze exception, I can sponsor it.
<IntuitiveNipple> thanks.
<Keybuk> yay Windows Vista installer
<Keybuk> Please chose between
<Keybuk>  (A)
<Keybuk>  (B)
<Keybuk> note that (A) has been disabled
<NCommander> Keybuk, that's an improvement from Windows XP in automatic mode
<NCommander> :-)
<NCommander> (I got a lot of STOP: No error (OK) boxes while getting the bugs out)
<Keybuk> we can't bitch
<NCommander> We can't?
<Keybuk> someone sent me of a screen shot with an error dialog that said "Never show this error to a user" or something
<NCommander> Fair enough
<Keybuk> GIO/GVfs related iirc
 * NCommander kicks RedBoot
<NCommander> Bah
<NCommander> So does anyone know if a four-clause BSD license will end up in universe or multiverse?
<Keybuk> I believe that it is considered DFSG-free
<Keybuk> thus it's unlikely that we'd be more restrictive
<Keybuk> though note that it's considered a deprecated licence, even by BSD themselves
<NCommander> Keybuk, legacy code used in RedBoot unfortnately. I would think it would end up in universe, but I plan to get this package promoted; I have concerns about it in main just because of the adversing cause ....
<NCommander> (I dunno if I'm crazy or not)
<mrooney> NCommander: did james_w ever get back to you on that update?
<Keybuk> NCommander: my recollection is that the 4-clause BSD is DFSG-free not *not* GPL compatible
<NCommander> mrooney, not as far as I could tell, if I don't see someone soon, I'll do something.
<mrooney> It will make babies cry if those bugs aren't fixed in Jaunty, like this --> ;_;
<mrooney> okay thanks :)
<NCommander> Keybuk, there is an exception in the GPL code in RedBoot
<NCommander> Keybuk, the copyright file is absolute fun. It breaks 1,000 lines
<Keybuk> indeed, the DFSG directly references the BSD licence as free; and I believe that at the time it was written, the 4-clause would have been the standard
<Keybuk> NCommander: if the copyright file is that long
<NCommander> no wait, scratch that, 792, since I removed the full text of the Apache 2 license in lew of the full text.
<Keybuk> I would say that the software needs a very careful copyright audit
<NCommander> I know :-/
<Keybuk> since it is likely that a conflict has been overlooked
 * NCommander sighs
<NCommander> RedBoot used to be in the archive, it was removed due to it being unmaintained.
<Keybuk> at least some of these licences are likely to be incompatible
<Keybuk> and it's all well and good adding an exception to the GPL bits
<Keybuk> but you need to make sure *ALL* of the GPL bits, even those linked to, have the same exception
<Keybuk> and that the exception has been approved by all copyright holders
<NCommander> *sighs*
 * NCommander wonders if he can shoot himself now.
<Keybuk> I've seen situations before where people have slapped an exception on top of GPL code, without checking
<Keybuk> thus violating the licence of code in there
<NCommander> Keybuk, we need this package for full iMX51 support :-/. I've done a look over, but its a massive package (I'm talking 16MB of source, and thousands of files; although we could probably strip out chunks of it)
<Keybuk> I need iTunes to update my phone, but that can't go in main either ;)
<NCommander> Keybuk, we could put it in restricted ... *hears a gunshot*
<Keybuk> no, we can't
<NCommander> I was kidding :-P
<Keybuk> I'm not
 * NCommander wonders where one can find a crack team of copyright auditers.
 * slytherin is glad he does not own a smart phone yet
 * NCommander gave up trying to get his blackberry and PC talking ages ago.
<ion_> I want one that runs on free software (and is therefore entirely hackable). And preferably doesnât suck much. :-)
<Turl> ion_: an openmoko phone?
<NCommander> ion_, I would say Android Development Platform phones, but I dunno how good Android is
<ion_> Yeah, i know about them. Iâll take a look at the market at the point iâm actually buying one.
<NCommander> I need something that support tethering.
<NCommander> Keybuk, so what do you recommend w.r.t. to the copyright audit on Redboot/eCos?
<KaiL> ...I guess, the intel display driver is a good candidate for the "daily upstream builds"
<Turl> will 2.6.3 from -intel be included in jaunty?
<KaiL> I hope 2.7 will be ready then
<Turl> the current one is a bit slow
<KaiL> because that version is required for the Asus Eee Top :/
<KaiL> Turl, eben 2.6.99 isn't really that much faster
<Turl> yeah, but it improves a bit
<KaiL> but at least a step into the right direction ;)
<kklimonda> hey guys, anyone has problem with booting after last uprades of jaunty?
<kklimonda> i'm getting invalid or unsupported executable format when i select kernel in grub
<Turl> kklimonda: I updated the kernel today, still didn't reboot
<kklimonda> i've tested it with -10 and -9 releases
<kklimonda> i'm using ext4
<kklimonda> and 64bit
<KaiL> for me only the CPU stays a 1,6GHz after booting
<kklimonda> ok, fixed - i had to manually run grub-install after i've changed ext3 to ext4..
<KaiL> grr
<KaiL> bug 341573 still there
<ubottu> Launchpad bug 341573 in linux "system stays on full CPU clock" [Undecided,New] https://launchpad.net/bugs/341573
<Keybuk> KaiL: I've an update pending for it
<KaiL> ah, ok
<KaiL> so it's at least recognised ;)
<Keybuk> oh, yes
<Keybuk> I didn't realise the kernel team were going to push an update so fast when I asked them to set the default back to performance
<KaiL> the idea behind is "booting on performance mode"?
<Keybuk> right
<KaiL> ..which gave maximun 1 second here ;)
<Keybuk> "maximum 1 second" ?
<KaiL> sometimes I get 33, sometimes 34 ;)
<Keybuk> ??
<Keybuk> boot speed you mean?
<KaiL> between grub and the drums
<KaiL> yes
<Keybuk> doesn't mean much without detailed knowledge of your hardware, etc.
<KaiL> I've read somewhere in the blueprint, that most testing for this is done on a netbook
<kklimonda> anyone knows how to fix virtualenv?
<KaiL> don't forget, that their SSDs have must better access times than normal laptop and even desktop disks..
<Keybuk> yes, we know
<Keybuk> that's why we use SSD
<KaiL> imho you mostly shorten times, which are eaten by the disk
<KaiL> loading X and gdm takes half the boot time here
<Keybuk> doubtful
<Keybuk> I'd imagine that the disk readahead takes the most significant portion of your boot
<KaiL> hm, ok... 1/3 from usplash disapearing until the drums
<Keybuk> do you have a bootchart?
<KaiL> I can try to make one
<Keybuk> apt-get install bootchart
<KaiL> hm.. main-package depending on universe-package ;)
<Keybuk> it recommends it, iirc
<KaiL> ah, yes
<KaiL> http://moba.linuxfaqs.de/bilder/frog-jaunty-20090317-1.png
<KaiL> interesting, that it ends at 25, but the drums are at 33s
<Keybuk> yeah, you have to mess about to graph the whole thing
<Keybuk> but that neatly shows you're spending almost you're entire time in I/O wait
<Keybuk> and the disk throughput is dreadfully low
<Keybuk> with apallingly high utilisation
<KaiL> in short: that hd sucks?
<Keybuk> what is that?  A Dell?
<KaiL> Asus M2N
<Keybuk> why do you boot with nolapic?
<KaiL> but the hd isn't original (that one was worse)
<Keybuk> HDDs in general suck
<directhex> i still need a solution to network mounts causing painful slowdown on shutdown.
<KaiL> there was a bug
<KaiL> maybe it's gone...
<Keybuk> directhex: ?
<directhex> Keybuk, on intrepid, if using n-m, a cifs mount in fstab means a 60 second timeout on shutdown, presumably as networking is killed before the umount happens
<directhex> delay is per-mount
<Pedobearishere> O HAI GUISE
<Pedobearishere> LOOKS LIKE UBUNTU KICKED ME INTO HERE
<directhex> sigh
<Pedobearishere> O_O
<KaiL> hm... lapic lets it take one second more
<Pedobearishere> I CAN LAST LONGER THAN A SECOND
<Pedobearishere> ASK GOLDILOCKS
<directhex> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Keybuk> damn ;)
<Seeker`> too slow :(
<Keybuk> I had a "who's been eating MY porridge" /kick message all lined up
<directhex> hm, patrick, why does that ring a bell
<slangasek> "this kick message was just right"?
<ikonia> Pedobearishere again....
<ikonia> just did some other channels
<directhex> hi2u ikonia
<ikonia> hey
<superm1> Keybuk, okay so i'm still seeing rather mixed results.  *should* udev be started and running by the time 24preseed is being ran in the initramfs?  I see references that udevadm gets ran before it in 23networking
<directhex> slangasek, was the guy a few weeks ago talking crap about helix a patrick, or am i misremembering?
<Keybuk> superm1: no, I think udev will be long dead by then
<slangasek> directhex: different Patrick
<Keybuk> but I may be wrong
<Keybuk> I've not looked at casper in ages
<Keybuk> jonmasters: SPIES!
<superm1> Keybuk, okay i'll keep grep'ing around then to try to ge ta better idea
<jonmasters> Keybuk: :)
<Keybuk> jonmasters: where's that kernel patch? :p
<jonmasters> Keybuk: oh thanks for reminding me to finish that
<directhex> hm. can bootchart chart shutdown as well? or is that an oxymoron, given the process will get killed
<Keybuk> directhex: there are ways to do that
<Keybuk> how is left as an exercise to the user
<jonmasters> Keybuk: only problem with being on here aswell is Freenode has a 10 channel max.
<jonmasters> Keybuk: which means I'll probably need to connect another client too
<directhex> Keybuk, i'd really like to resolve why samba umounting sucks so hard, it's bugged me for years
<ikonia> directhex: locking is the quick answer
<kees> doko: I've got 1/3rd of the gcc testsuite cleaned up.  how should I approach upstream with it?
<Keybuk> jonmasters: I'm on >10
<directhex> ikonia, afaik the cifs module insists in doing a "clean" umount when unmounting, i.e. sending a "im disconnecting now kkthxbye" to the samba server. it's got a hard-coded timeout of some kind on that
<directhex> ikonia, try mounting something, pull the cable, then unmount it
<ikonia> how delightful
<Keybuk> directhex: smb mounts sound like the kind of thing that should be done by fuse these days
<superm1> jonmasters, yeah and i just joined an 11th to check.  wfm too
<Keybuk> in fact, fuse-nfs; when?
<directhex> Keybuk, i'm approx 112.6% in agreement on that.
<jonmasters> Keybuk: oh, I mean 20
<directhex>   smbnetfs
<directhex> i'll try that
<soren> jonmasters: If you ask nicely, they'll let you join more.
<soren> jonmasters: "/whois soren" for proof.
<directhex> argh, except... argh! it doesn't have its own mounter, and fuse isn't considered a network filetype by /etc/network/if-up.d/mountnfs, so it would be mounted all funny-like
<soren> jonmasters: Hi, by the way :)
<directhex> nothing simple is ever easy
<jonmasters> soren: the limit seems arbitrary :)
<jonmasters> soren: who do you ask?
<jonmasters> soren: hi too :)
<soren> jonmasters: I forget whom I asked specifically. Any freenode op, I suppose.
<slangasek> Keybuk: your desire to convert people to fuse notwithstanding, there are plenty of users who use the kernel cifs support and this is a bug that should be fixed.
<directhex> it is reasonable to have a timeout on connection drops, so IMHO the question is how to ensure netfs is unmounted before network dies
<Keybuk> directhex: depends, how is the network up?
<directhex> Keybuk, n-m wired dhcp
<Keybuk> so there you have the egg
<Keybuk> and the network is the chicken
<Keybuk> N-M and its various bits are all on /usr
<Keybuk> so they're killed (forcing the network done) before we umount filesystems (including network filesystems)
<Keybuk> because we support /usr on separate filesystems
<Keybuk> indeed, it's one of the most common scenarios for NFS
<directhex> so perhaps n-m could be made to not bring down the network on shutdown? what purpose does killing the network serve, exactly?
<directhex> DHCP release i suppose
<directhex> hm, tricky
<slangasek> is the interface actually taken down when NM is killed?
<Mithrandir> I wonder why we bother about dhcp release.
<KaiL> is there a visible difference for the dhcp server, if there's a ifdown or just a "poweroff"?
<slangasek> well, if the interface is actually *deconfigured*, that's an easier case for the cifs code to check and handle correctly
<slangasek> which if you're doing a wired network + N-M, I guess that's the case
<directhex> is there a pre-down we can abuse?
<directhex> mounting netfs in post-up works great
<slangasek> directhex: not sanely, because you have to determine that *this* interface is the one associated with the mount in question
<directhex> oh christ
<slangasek> i.e., check whether taking down this interface takes down the route
<superm1> Keybuk, well i'm thinking my resolution to the problem is bind mounting /dev to /root/dev while running any commands in /root from the initramfs.  udev is indeed running, but it looks like the /dev and /root/dev easily get out of sync
<directhex> this sounds like a job for sitting down & brainstorming :/
<slangasek> but it *is* a bug that the kernel cifs implementation has to time out when asked to unmount a share and it gets a no route to host
<soren> slangasek: that's not really that difficult, is it? "ip route get <samba server> | grep -q \\\<$IFACE\\\>"
<slangasek> soren: oh, I didn't know we had that, that's useful :)   But you do need to check that this is the *only* interface with a route to it, rather than checking that this interface has a route to it...?
<soren> slangasek: Hence the question mark. :)
<soren> slangasek: Well.. You could add a check for other interfaces with a route to it, and with the same source address.
<kees> Keybuk: you're op'd.
<soren> slangasek: I think that is complete enough.
<soren> slangasek: More than complete enough, even. :)
<slangasek> soren: and then lazy unmount?
 * soren reads context again
<soren> slangasek: I'm not sure I'd do it lazily. Does that block at all? I want the umount to finish before the route is gone.
<slangasek> soren: the trouble is that the unmount won't finish at all if there are processes still using the mount
<soren> slangasek: Right you are.
<soren> Err..
<slangasek> if the interface goes down because you lost sight of the AP, and you're sitting with an open shell with the smb mountpoint as cwd, and...
<soren> slangasek: In that particular case, I'd prefer not to unmount at all, I think.
<soren> I kind of like being able to walk closer to that AP again and have things just continue where they left off.
<directhex> so now we need some kind of heuristic to determine whether we really want to do a speed-unmount. i propose an advanced genetic algorithm
<soren> I know a certain office in London where dropping off of the wifi is not an uncommon occurrence.
<slangasek> soren: well, there's no way to distinguish that case from the shutdown case then, using pre-down
<directhex> slangasek, not even from the runlevel?
<KaiL> soren, and same for "i need to sort the cables" on a wired LAN?
<slangasek> unless you check runlevel :P
<directhex> hax!
<directhex> i like hax.
<soren> KaiL: Very much, yes.
<soren> I always get a warm, fuzzy feeling when I've suspended my laptop for half a day, come back, resume, and my ssh connections are still live.
<KaiL> hehe
<soren> How this relates to this discussion, I'm not sure.
<soren> I'm very tired.
 * directhex wonders when more exciting details on UDS are coming
<soren> directhex: When you least expect it.
<directhex> so thursday, then? totally not expecting it on thursday
<KaiL> so we need to separate beween a ifdown manually issued (including shutdown) and one issued by link loss
<jussi01> jcastro: ping
<TheMuso> asac: no, I'll get it uploaded this morning.
<dtchen> cjwatson: / mdz: / Keybuk: sorry about the RT spam, not sure how to prevent that
<Rocket2DMn> TheMuso, im looking at bug 243226 - you said you were going to prepare a SRU for Hardy for it but the bug status was never updated.
<ubottu> Launchpad bug 243226 in initramfs-tools "Panic messages are not displayed when usplash is running" [Wishlist,Fix released] https://launchpad.net/bugs/243226
<TheMuso> Rocket2DMn: I got sidetracked. I'll get to it once beta freeze is in effect for jaunty, since I'm rather busy till then.
<Rocket2DMn> ok no problem, thanks for looking
<cjwatson> dtchen: it's ok, we have explicitly asked to be subscribed to all traffic on that RT queue
<cjwatson> dtchen: so it isn't spam for us
<cjwatson> mpt: that's an interesting bug (autologin). When you first mentioned it I thought you meant you'd logged out and then seen a countdown, and in that case it does make some sense since if you've logged out from the live environment you probably had some curious reason to do so (such as creating a new user in the live environment)
<cjwatson> mpt: I don't believe I've ever seen it act that way on initial boot, though
<jpds> a/41
<bryce> pitti: btw I've packaged/built -fglrx and will be uploading soon once I've done a little testing
<bryce> pitti: version is going to be 8.600-0ubuntu1
<directhex> there's a new catalyst?
<directhex> or is this a private build again?
<NCommander> ScottK, ping?
#ubuntu-devel 2009-03-18
<bryce> directhex: this is the public build
<bryce> well, ubuntu public build.  Dunno if it's released to the world in general yet.
<directhex> latest version on ati.com is catalyst 9.2
<bryce> directhex: so?
<directhex> which is... hm... 8.582
<bryce> I'm sure 8.600 will be available from their website before too long, meanwhile you can have it in jaunty today
<directhex> and it adds xserver 1.6 support, presumably, since you're bothering to upload it?
<bryce> that is correct
<directhex> hm, i heard xserver 1.6 support wasn't due until the release after next. good to know there's no horrible driver migration needed in the release upgrade this time
<directhex> or hang on, wasn't the latest version gonna dump support for a bucket of cards?
<bryce> sorry, I'm not at liberty to comment on that
 * Laney tests
<directhex> Laney has a radeon?
<Laney> x1950 gt
<Laney> I know nothing about it other than it makes pretty pictures appear on my screen
<Laney> (and plays l4d and tf2 ^_^)
<directhex> i have a 4870 on my toolbox i'm meant to test
<bryce> I tested both the latest -ati and -fglrx on an hd4850 and it worked beautifully
<directhex> i'm meant to re-examine the old "who sucks more under linux" chesnut, and was handed the 4870 as ~equivalent to my geforce. i'm putting off testing until i have a screen that can do the HD video playback test without scaling
<bryce> directhex: good luck with that.  Actually I'd be interested in the results.
<directhex> bryce, still not happy about the number of tests available to me - apparently we don't have any current contacts at epic so i can't squeeze unrealengine3 from them for testing with... which leaves limited options for modern tests
<bryce> directhex: ever tried phoronix test suite?
<directhex> bryce, the test suite itself is a great tool, but i don't think michael at phoronix fully understands which benchmarks are appropriate when and why
<directhex> bryce, so it's a good starting point
<bryce> sort of was my take too
<bryce> on my (overwhelmingly lengthy) todo list to play with it some day
<directhex> one detail makes me go "o_O" at it
<directhex> console apps written in php do that
<bryce> heh, yeah
<directhex> i need to better understand unigine, so i can exert more scripted control over detail levels over multiple runs
<directhex> oh, and any idea whether you still need to restart X to change ansiotropy/antialiasing on a radeon?
<directhex> years since i've used one
<adelie42> question: Setup virtualbox to do some patch testing, and after installing guest additions, only start up to a CLI. Guest addidions removed X, which I figured was normal... What did I miss here?
<adelie42> Jaunty alpha 6 install, fully updated
<tjaalton> asac: dropping the no-bitmaps link from fontconfig made some pages really ugly in ffox
<tjaalton> bug 344629
<ubottu> Launchpad bug 344629 in fontconfig "Subpixel rendering for some fonts in Firefox and Konqueror is disabled after a fontconfig update" [Undecided,New] https://launchpad.net/bugs/344629
<tjaalton> and a screenshot from bug 305394 to illustrate: http://launchpadlibrarian.net/24015504/fontconfig_firefox.png
<ubottu> Launchpad bug 305394 in fontconfig "No subpixel smoothing" [Medium,Fix released] https://launchpad.net/bugs/305394
<dholbach> good morning
<bryce> heya
<dholbach> hi bryce
<pitti> Good morning
<pitti> bryce: nice! I'll watch out for it
<bryce> pitti: it's uploaded now, so go ahead and put jockey changes in at your convenience
<dholbach> doko: can you check out bug 324708? :)
<ubottu> Launchpad bug 324708 in python2.5 "Please backport fix for http://bugs.python.org/issue4150 (r67000)" [Undecided,In progress] https://launchpad.net/bugs/324708
<mvo> doko: could you please have a look at bug #338395 ?
<ubottu> Launchpad bug 338395 in python2.6 "distutils appends '/local' to to user-specified install prefix" [Medium,Confirmed] https://launchpad.net/bugs/338395
<doko> dholbach. mvo: yes, on my list
 * dholbach hugs doko
<doko> mvo: any news on the short reads?
<mvo> doko: no feedback from the user yet
<doko> had one report for gcc as well
<mvo> oh?
<mvo> hm, I should probably add some debug code to dpkg to see if we can get more information if that error happens
<KaiL> new intel driver; new fglrx - today seams to be a good day ;)
<taavikko> Any news on upstart 0.5 to make it in jaunty or +1 ?
<maxb> Well, we're in FeatureFreeze so it seems rather unlikely for jaunty
<KaiL> who killed the clock applet? ;)
<Hobbsee> ME!
 * Hobbsee MUHAHAHAHAHAHA
<KaiL> Hobbsee: so if anybody misses a meeting today, they all will blame you ;p
<Hobbsee> KaiL: oh, whacko.  I'll switch all the meetings on to aussie time too, then?
<Hobbsee> KaiL: in all seriousness, WFM.  I'm not sure it is broken, or if so, how
<KaiL> crashes here after todays updates on loading
<Hobbsee> did you check for bugs?
<KaiL> none yet, as it looks
<KaiL> I guess, then it's time to fill one ;)
<KaiL> oh, wait..
<KaiL> this time it loads?!
 * Kamping_Kaiser suspects Hobbsee is toying with you KaiL 
<Hobbsee> haha
<Hobbsee> go figure
<KaiL> Kamping_Kaiser: as that damn applet does... now it's back again
<Kamping_Kaiser> hehe
<KaiL> hm, which packages does the authentification to be able to load gdm?
<seb128> load gdm? or log in?
<KaiL> I try to update as few a possible before I can get an X session to do a short test on the new fglrx
<seb128> I don't understand the question
<seb128> update what?
<seb128> you don't need to update anything to have gdm working it didn't change for years
<KaiL> strange
<KaiL> but we'll see after the full update is done
<KaiL> I hoped, it would be possible to only update the xserver from an intrepid-install to try the new fglrx before everything get's updated
<KaiL> I know, silly idea ;)
<directhex> i'm just uploading an intrepid version to my ppa, actually
<directhex> #  fglrx-installer_8.600-0ubuntu1~intrepid~dhx1.dsc  (1.4 KiB)
<KaiL> now it's to late ;)
<directhex> well, you see where impulsiveness gets you now!
<KaiL> that "8.600" gives some hope for more improvements than only x-server 1.6 ;)
<KaiL> like working sensors without a manual xorg.conf
<directhex> there IS a changelog
<asac> tjaalton: hmm. thats for site specific fonts?
<asac> tjaalton: is that ffox 3 or 3.1?
<directhex> the changelog only mentions closed bugs though
<KaiL> which is a quite good looking list ;)
<tjaalton> asac: 3.0
<tjaalton> asac: on the forums someone suggested to link ../conf.avail/70-no-bitmaps.conf
<asac> tjaalton: no bitmap? hmm
<asac> tjaalton: do you see this? can you go to font preferences and disallow sites to use their own fonts?
<asac> maybe that fixes it=
<asac> Ã
<asac> ?
<taavikko> ffox 3.1 is showing also weird fonts in some sites
<tjaalton> asac: yes, it started when the new fontconfig was installed
<tjaalton> will try
<tjaalton> asac: seems to help
<philwyett> Can someone with ubuntu-devel list admin rights please give the awaiting moderation list of posts a kick. Thanks
<Keybuk> bah
<Keybuk> /etc/init.d/exim4 reload is not Ronseal-Compliant
<soren> Whuh? Why is tracker-indexer suddenly running on my system?
<KaiL> oh, new intel driver seams to have a usable performance again ;)
<soren> Keybuk: "Ronseal"?
<Keybuk> soren: it does NOT do what it says on the tin
<Keybuk> in fact, it stops your mail server altogether
 * Keybuk watches all the e-mail come back
 * directhex paints a fence with exim4
<lool> pitti: around?  http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt you mention debian-maintainers # pitti, not relevant for Ubuntu
<lool> pitti: I think it's helpful for things like who-uploads or dget -x to work without warnings on Ubuntu when fetching Debian sources
<lool> We have other keyrings in the archive for similar reason (such as to debootstrap a Debian chroot from an Ubuntu install), so I would like it if we could get that package in Ubuntu as well
<cjwatson> lool: bug 180323
<ubottu> Launchpad bug 180323 in debian-maintainers "Please remove debian-maintainers package from Ubuntu" [Wishlist,Fix released] https://launchpad.net/bugs/180323
<cjwatson> (for history)
<cjwatson> justification's rather weak
<lool> I think I'll reopen with my above comments
<directhex> isn't it just a keyring?
<lool> It is
<directhex> isn't that useful, given source packages may be signed with keys inside it?
<lool> directhex: Exactly the argument I made earlier
<asac> slangasek: when you have a minute, could you please set your lp.199140 network-manager branch to "merged" ... so it disappears from the active branches list ;)?
<directhex> lool, saves a meg or two of archive space though!
<oly> hi, Any one able to tell me where to look to make applications show up in system-services application ??
<lool> cjwatson: I reopened the bug with above rationale and a bit more
<lool> I wonder what motivation Kmos had
<Laney> would an Ubuntu dev keyring be useful?
<apw> pitti, thanks for that checkbox upload
<lool> cjwatson, pitti: Submitter agrees with the rationale for keeping the keyring; would you mind reverting the removal and closing the bug as wontfix?
<cjwatson> lool: done
<lool> cjwatson: thanks!
<seb128> ogra: do you know if edubuntu-desktop really requires screem? it's the only thing in main still using gtksourceview1
<seb128> and one the few things using libgnomeprint*
<ogra> seb128, i dont do edubuntu anymore, ask LaserJock ... i know there was a discussion for a screem replacement though
<seb128> does edubuntu require main or can it use universe?
<lool> cjwatson: 2009-03-18 11:10:31 WARNING Upload was rejected:
<lool> 2009-03-18 11:10:31 WARNING     Unsupported custom section name 'raw-keyring'
<ogra> seb128, currently still main afaik
<lool> cjwatson: Should I upload a version manually to allow us to set an override, and then we sync it again?
<cjwatson> lool: I think it needs an Ubuntu upload that removes the dpkg-distaddfile bit
<cjwatson> we can't do anything useful with that in our archive; its purpose is special communication with the Debian archive software
<lool> wow never met that yet
<KaiL> bryce: that ATI "8.6" driver does not only work; it runs like hell ;)
<directhex> KaiL, 8.600
<directhex> KaiL, 8.6 is something else. yay for consistency
<KaiL> eh, yes..
<KaiL> only interesting, that glxgears slowed down from 10k to 1k
<KaiL> maybe because of better power management
<directhex> catalyst 8.5 has an internal version number of 8.501
<directhex> bah
<directhex> 8.6 = 8.501
<KaiL> ah, yes
<KaiL> the 9.1 previously in jaunty was already a big boost in performance over the intrepid-Version
<KaiL> and this version gives another quite good step forward
<lool> cjwatson: Done in NEW
<lool> +,
<directhex> 9.1 = 8.573
<lool> cjwatson: thanks for the hint, sent a debdiff to Anibal
<asac> tjaalton: ok. so are the bad fonts MS fonts?
<asac> tjaalton: maybe check which of the files i removed in the last few uploads needs to be resurrected for you
<cjwatson> lool: I don't think it's suitable for Debian; it's an inevitable Ubuntu diff surely?
<cjwatson> lool: turning off the raw-keyring bit in Debian would break the ability of new Debian maintainers to upload
<lool> cjwatson: I provided a diff to only run the BYHAND chunk based on lsb_release output
<cjwatson> ah, ok
<cjwatson> cool
<ogra> asac, why do my browser fonts look so odd since the last update ?
<asac> ogra: try to select "dont allow website to select fonts" ... does that fix it for you?
<ogra> where do i find that ?
<ogra> ah, got it, yes
<asac> ogra: in preferences -> content -> (fonts) advanced
<ogra> well, though it switches everything to serif indeed
<ogra> but now i see aliased fonts
<davmor2> Guys I got a query about ssh/sftp between the desktops and console.  If you do ssh username@server your in the /home/username directory the same applies for sftp in kubuntu and xubuntu the only one in fact that doesn't do this (which I'm guessing is expected behaviour) is Ubuntu's sftp which drops you in /.  I know I was told before that this is deliberate I'm just wondering why when every other desktop and console d
<asac> ogra: ok. so the other fonts are probably your mstcorefonts
<cjwatson> urk, who accepted linux-ports on i386? its binaries are all in the wrong component
<asac> ogra: please do sudo ln -s /etc/fonts/conf.avail/70-yes-bitmaps.conf /etc/fonts/conf.d/70-yes-bitmaps.conf
 * cjwatson wheels out security-kernel-overrides to fix it up
<ogra> oh, i wasnt aware i installed that :)
<asac> ogra: i am not sure ;).
<asac> ogra: when did you install this system? was it before feisty?
<ogra> no, hardy
<ogra> hmm, the link didnt fix it
<ogra> (not even after a browser restart)
<asac> ogra: yes. i am not saying that that link is the problem ;) i just guessing
<asac> ogra: so remove it again ;)
<asac> ogra: do you have 10-autohint.conf in etc/fonts/conf.d?
<asac> if not please link it similarly
<cjwatson> (linux-ports) ia64 too
<tjaalton> asac: just adding the link to 70-no-bitmaps.conf seems to be enough
<Riddell> asac: could bug 344629 be from your recent fontconfig changes?
<asac> tjaalton: no bitmaps?
<ubottu> Launchpad bug 344629 in fontconfig "Subpixel rendering for some fonts in Firefox and Konqueror is disabled after a fontconfig update (dup-of: 305394)" [Undecided,New] https://launchpad.net/bugs/344629
<ubottu> Launchpad bug 305394 in fontconfig "No subpixel smoothing" [Medium,Triaged] https://launchpad.net/bugs/305394
<asac> Riddell: yes.
<asac> almost certainly.
<asac> we try to figure out which file we need
<ogra> no change
<asac> ogra: did you try the no-bitmaps thing?
<tjaalton> asac: /etc/fonts/conf.avail/70-no-bitmaps.conf, you removed that and a bunch of other links :)
<asac> tjaalton: yes i did a cleanup
<asac> tjaalton: but but but ... i didnt remove the 70-no-bitmaps.conf
<asac> tjaalton: i removed no-bitmaps.conf
<tjaalton> asac: you cleaned the link to it
<asac> but those are not even shipped anymore
<asac> so if you still had them it was luck of an old install
<ogra> sudo ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/70-no-bitmaps.conf and restarting FF fixes it
<tjaalton> not shipped since when?
<asac> ogra: ok
<asac> tjaalton: not sure since when. purge fontconfig ... install the version from intrepid. its not there
<tjaalton> asac: this is a fresh jaunty
<asac> tjaalton: thats odd.
<tjaalton> conf.avail/70-no-bitmaps.conf surely comes from the package
<asac> tjaalton: yes. but there is no link to conf.d
<asac> but let me check
<tjaalton> in conf.d you mean?
<tjaalton> _to_ conf.avail :)
<asac> tjaalton: whatever. you know what i mean ;)
<tjaalton> yes :)
<Hobbsee> out of general curiousity, where does lsb-core actually use alien?
<ogra> Hobbsee, rpm
<ogra> lsb compliance requires you to be able to install rpms iirc
<Hobbsee> ahhhh
<broonie> LSB packages are RPMs.
<cjwatson> Hobbsee: lsb-core doesn't actually call it, but part of the purpose of lsb-core is to provide an LSB-compliant environment, so you can think of it as a metapackage
<Hobbsee> so it's not actually required for the package, but it's for compliance.  OK then :)
<cjwatson> README.Debian explains
<Hobbsee> apparently i didn't read that closely enough ;)
<cjwatson> hmm, alternates oversized
<cjwatson> 10MB jump on i386 from yesterday
<cjwatson> seems to be the language pack update
<tjaalton> asac: purge/reinstall of fontconfig confirms that conf.avail/70-no-bitmaps.conf is included in the current package
<cjwatson> although some of GNOME has grown quite a bit
<cjwatson> oh, no, that's an FP due to packages disappearing off cdimage's mirror
<asac> tjaalton: err. i never said it isnt
<asac> tjaalton: i said. that it wasnt linked by default before
<asac> but well
<asac> it might have slipped through
<tjaalton> ah
<asac> tjaalton: can you purge and install ubuntu4?
<asac> or ubuntu5
<asac> tjaalton: https://edge.launchpad.net/ubuntu/+source/fontconfig/2.6.0-1ubuntu4
<tjaalton> I'll build it and compare the result with the current one
<asac> tjaalton: the binaries are there too ;)
<pitti> lool: debian-maintainers> sure, I don't have a strong opinion about it; it's just potentially out of date, and wrong, in Ubuntu
<pitti> lool: seems that cjwatson dealt with this; thanks, cjwatson
<directhex> pitti, debian-edu-archive-keyring is right?
<lool> pitti: It has been dealt with; I think it's like the other keyrings and useful by default, even if slightly out of date
 * directhex runs gpg --refresh-keys in celebration
<pitti> directhex: it's in ubuntu; anything wrong with it?
<directhex> pitti, no, but i don't see why it's any more useful than the debian-maintainers keyring
<cjwatson> goodness, what's up with the kubuntu/alternate/amd64 daily? it's massive
<KaiL> hm... what's that "ata1: softreset failed (drive not ready)"? A bug in the hardware or in the kernel?
<Riddell> cjwatson: I'm trying to work that out
<davmor2> cjwatson: live is 4 meg bigger than daily :)
<tjaalton> asac: ah right, the postinst linked it
<tjaalton> asac: so the debconf default used to be to disable bitmap fonts, which meant that postinst made the link
<asac> tjaalton: ok thanks.
<asac> tjaalton: if thats what we want, i will add that link again
<asac> have to check whether it has regressions for good fonts
<pitti> Riddell: btw, contrary to my belief I didn't actually find a policykit-kde package; is that functionality shipped in some libkde* package, or was it postponed for jaunty?
<pitti> Riddell: bah, ignore me; must have been blind yesterday evening
<KaiL> oh dear, what happened to firefox font rendering?
<tjaalton> KaiL: bug 305394
<ubottu> Launchpad bug 305394 in fontconfig "No subpixel smoothing" [Medium,Triaged] https://launchpad.net/bugs/305394
<KaiL> what I see on packages.ubuntu.com looks much worse than missing subpixels to me..
<KaiL> somebody killed launchpad :/
<Keybuk> oh noes!
<Keybuk> you bastards!
<Keybuk> (WFM btw :p)
<KaiL> grr
<pitti> tseliot: do you think it makes any sense to keep nvidia -71 in jaunty at all?
<KaiL> pitti: doesn't work with 1.6?
<pitti> right
<pitti> and it's been like that for a while now
<KaiL> crap - so no driver at all for GF2
<KaiL> and everybody cries at ATI...
<pitti> KaiL: both the free as well as the proprietary ati driver should be pretty good nowadays
<pitti> KaiL: fun isn't it, how blame and praise shift around in a matter of a year
<KaiL> pitti: yes
<slytherin> do those high end HD cards from ATI 4xxx series have any support in jaunty?
<KaiL> slytherin: I have a 4670 working here ;)
<KaiL> fast like hell (even compared to 9.1) and looking quite stable
<slytherin> KaiL: Cool. One of my friend has 4850 and I am planning to install jaunty on his PC.
<pitti> Lure: great job on the exiv2 transition!
<KaiL> 1002:9460 in modalias, so the driver even knows the 4890
<tseliot> pitti: maybe Nvidia will update it sooner or later
<Lure> pitti: thanks - that what you get if you really want something ;-)
<KaiL> tseliot: like "somewhen in mid april", as always? ;)
<tseliot> KaiL: maybe ;)
<asac> ogra: why is usb-imagewriter not in archive?
<pitti> asac: you mean usb-creator?
<asac> pitti: no. i mean the package referenced on the UNR page ;) ... wait
<asac> https://wiki.ubuntu.com/UNR#Using%20Usb%20Imagewriter
<asac> http://ppa.launchpad.net/ogra/ubuntu/pool/main/u/usb-imagewriter/usb-imagewriter_0.1-1~ppa1_all.deb
<pitti> ah
<asac> just think if thats the primary way for installing the UNR image on a key, we should have that in the archive
<Riddell> cjwatson: well I'm pretty confused on this oversized amd64 issue.  there's a whole load of extra gnome packages on the amd64 CDs.  on the desktop CDs they're in the shipped repository not in the squash filesystem
<ogra> asac, we would if pitti hadnt objected my upload and u wouldnt have been to lazy to re-implement dd in python ;)
<ogra> s/u/i/
<asac> ogra: so you use dd command line tool in that package?
<ogra> asac, right, its a pygtk wrapper doing some ugly stuff with dd
<ogra> though it works ...
<superm1> ogra, wasn't the (eventual) intention to have such support pulled into regular usb-creator to be able to write vfat filesystems?
<ogra> right
<ogra> or to use isos for everything and have usb-creator to convert them
<superm1> ooh i think i'd like that best, then you can still burn them with windows boxen to real CDs
<pitti> ogra: oh, did I? I'm afraid I can't remember any more
<ogra> pitti, yes, you did (with valid concerns :) )
<pitti> ogra: but dd? isn't that more or less just a read()/write() in a loop?
<ogra> pitti, yes, but progress reporting is tricky
<Cimi> resuming does not work here, on the ubuntu lpia release. it works if I add resume=/dev/sdXY to grub
<pitti> I guess I have to see the code and my previous concerns
<pitti> ogra: it seems much more tricky to me to parse it from dd than to just have a counter in the read/write loop?
<ogra> well, you asked to rip out the dd and implement it in py ... which is the right thing
<cjwatson> Riddell: that's odd, oem-config-gtk is being installed as well as oem-config-kde
<pitti> ogra: hm, while that is true, I don't see why it is a reason for rejecting from the archive
<cjwatson> Riddell: I think everything else is Recommends-following from that
<ogra> pitti, i sadly cant remember in detail anymore
<Cimi> https://bugs.launchpad.net/bugs/332365
<ubottu> Ubuntu bug 332365 in acpi "hibernation doesn't work with samsung nc10 + LPIA" [Undecided,New]
<cjwatson> germinate says:
<cjwatson> * Chose oem-config-gtk out of oem-config-frontend-1.54.8 to satisfy oem-config
<cjwatson> Riddell: oh, it's due to build desync. oem-config-kde is architecture: all but oem-config (and oem-config-gtk) are architecture: any
 * ogra wonders why he cant get cups to restart on armel
<ogra> that breaks my dist-upgrade ... hrm
<cjwatson> Riddell: oem-config/amd64 failed to build due to some transient installability problems: http://launchpadlibrarian.net/23960563/buildlog_ubuntu-jaunty-amd64.oem-config_1.54.9_FAILEDTOBUILD.txt.gz
<cjwatson> Riddell: I've kicked off a retry of that, and will look at improving dependencies so that this doesn't happen again
<Riddell> thanks cjwatson
<soren> What's the syntax in grub's menu.lst to make it use uuid's to determine its root device? In a way that update-grub can deal with, that is.
<liw> if one wants to test a really old upgrade (breezy to dapper), are the breezy isos and package archives available somewhere?
<soren> http://old-releases.ubuntu.com/releases/
<ogra> old-releases
<soren> http://old-releases.ubuntu.com/ubuntu/ for the archive.
<liw> soren, cool, tackar och bockar
<ogra> asac, did something in NM recently change ? my arm systems are suddenly all called localhost.localdomain
<mcnicholls> hi. i am looking to get petsc rebuilt te remove a dep on an NBS package, but i found it doesn't build due to something to do with libhypre. I have rebuilt and installed hypre from the source package, installed it and petsc rebuild fine after that. Is it reasonable to submit a rebuild request for hypre citing that it is needed for petsc to recompile, or would i actually have to work out what has caused the problem with hypre to get it rebuilt?
<ogra> asac, seems it applies the 127.0.0.1 value from /etc/hosts instead of whats in /etc/hostname
<asac> ogra: nope ... maybe your nm-system-settings process isnt running?
<ogra> hmm, right
<asac> ogra: crashed because of /etc/network/interfaces maybe?
<asac> ogra: if so i want that file as a bug
<ogra> nope, interfaces has only lo
<ogra> i guess its fallout of another bug
<ogra> i cant start cups either on that system
<ogra> there are actually a bunch of services it cant start
<ogra> i just wasnt aware that nm would set localhost.localdomain by default now
<ogra> running hostname.sh manually and doing a re-login helps though
<ogra> pitti, why is cups always trying to reload apparmor (which we dont compile on armel)
<soren> ogra: It should be checking for the existence of /etc/init.d/apparmor first. Doesn't it do that on your system?
<pitti> ogra: it ships an apparmor profile, so shouldn't it?
<ogra> soren, it might, indeed thats existing
<ogra> but we dont/cant compile apparmor on armel
<ogra> so there is no module
<pitti> ogra: but it doesn't actually do that in the init script
<pitti> ogra: but in the postinst
<ogra> right
<pitti> ogra: and it does check for /etc/init.d/apparmor first
<ogra> which indeed exists
<pitti> ogra: also, if invoke-rc.d apparmor force-reload, it doesn't fail installation
<pitti> ogra: so that's about as much as cups can do
<pitti> (it's || true'ed
<ogra> ah
<ogra> i just wonder if apparmor is responsible for all my probs in userspace if the module is missing but the profiles and tools are installed anyway
<ogra> (my user shells get sigkilled, nm doesnt start, gdm commits suicide and cups hangs on startup are the current symptoms)
 * ogra goes afk for 30min
<pitti> mvo: hm, no luck with overwriting InstallProgress.fork() in bug 280291  :-(
<ubottu> Launchpad bug 280291 in jockey "python-apt output does not go to log file" [Undecided,Triaged] https://launchpad.net/bugs/280291
 * lamont wonders wtf this error comes from: http://launchpadlibrarian.net/21050486/DpkgTerminalLog.txt (and more to the point, whether he should toss but 315410 at dpkg or apt)
<lamont> bug 315410 even
<ubottu> Launchpad bug 315410 in bind9 "package dnsutils 1:9.5.0.dfsg.P2-1ubuntu3 failed to install/upgrade: failed in buffer_read(fd): files list for package `texlive-base'" [Undecided,New] https://launchpad.net/bugs/315410
<sbeattie> ogra: no, if apparmor is disabled kernel side, the only thing that should fail is the apparmor init scripts; there is no enforcement done in userspace, only configuration and reporting.
<ogra> sbeattie, hmm, i still got my sigkill prob with user shells though
<ogra> i removed all traces of apparmor in userspce now though
<ogra> i'm pretty sure the other probs i see are caused by it
<mvo> pitti: let me have a look
<pitti> mvo: it's not urgent, please don't waste time on it
<pitti> Riddell: ah, just saw policykit-kde in live action
<Riddell> pitti: cor
<Riddell> does it work?
<pitti> Riddell: yes, looks fine
<pitti> Riddell: btw, davmor tested current jockey on current Kubuntu, both with kdesu and polkit-kde; worked fine
<pitti> Riddell: and I tested it here as well (with a mock handler); what broke for you?
<Riddell> pitti: when I click Activate or Remove it greys out the list item and doesn't do anything else
<pitti> Riddell: after it does that, could you send/pastebin /var/log/jockey.log?
<pitti> Riddell: I also uploaded an important bug fix on Monday or so
<pitti> (but it shouldn't completely break like this)
<mvo> pitti: I added a patch that hopefully helps, a nice change between hunting a orbit crash
<pitti> mvo: to python-apt, you mean? or to the bug?
<mvo> pitti: to the bug
<Riddell> pitti: http://www.kubuntu.org/~jriddell/tmp/jockey.log
<mvo> pitti: its a bit rought, sorry for that
<pitti> mvo: oh, interesting! so it works with os.open(), but not with TemporaryFile and .fileno()?
<pitti> mvo: many thanks! *hug*
<calc> how do i reset keyboard repeat rate in X?
<pitti> Riddell: hm, that doesn't even attempt to do something; you opened jockey-kde and tried to click "activate"?
<calc> it seems vmware disabled it for me
<calc> setxkbmap doesn't seem to help
<calc> at least by itself
<Riddell> pitti: clicked remove (it did one time successfully activate the pmount "driver")
<mvo> pitti: I have not looked at your patch in detail, I suspect it might be some disagreement between the python higher level code and the low-level os.dup2() ?
<mvo> pitti: cheers, my pleasure :)
<pitti> mvo: I have successfully used that approach in other places (apport), but only with pure python
<calc> ah 'xset r on'
<ogra> Keybuk, i'm desparetely looking for someone who can help me with my SIGKILLed user shells on armel
<Keybuk> KILL?
<Keybuk> that's a mighty unfriendly signal you got there
<ogra> http://pastebin.com/f759fd172
<ogra> i suspeced apparmor but apparently thats not at fault
<ogra> that strace output is the result of "strace -f -s 1024 sudo -u ubuntu -s  2>/tmp/shell.log"
<mvo> pitti: i wonder if sys.stdout() it not the system stdout (but __stdout__ instead)?
<sbeattie> ogra: is there anything in dmesg when that happens?
<ogra> seems shells die if i exec them as a normal user and if processes start that change the user from an initscript they hang forever
<ogra> sbeattie, no, sadly not
<pitti> mvo: $ python -c 'import sys; print sys.stdout.fileno()'
<pitti> 1
<pitti> mvo: that should be alright
<mvo> yeah, odd
 * mvo scratches head
<pitti> mvo: I guess it's rather something in TemporaryFile().fileno() that it doesn't lie
<pitti> like
<pitti> mvo: I'll try it with os.open() and clean up temp files manually
<ogra> sbeattie, Mar 18 17:08:13 babbage init: tty1 main process ended, respawning in daemon log ... but thats only fallout
<ogra> (if i try to log in as a user)
<ogra> i dont know where to look further, it all seemed to start when amitk started building kernels with apparmor enabled but now we have one thats completely without any trace of apparmor and the prob still persists
<ogra> so i start to think apparmor was a red herring
<ogra> i'm happy for every idea anyone might have where to look
<ogra> as silly as the idea might be :)
<ogra> gdm doesnt start ... but i can startx as root ...
<ogra> so there seems to be something wrt privilege changes/separation
 * ogra wonders is slangasek has an idea as the declared pam god here :)
<ogra> (though i dont know why pam should sigkill anything)
<slangasek> no pam module that I claim responsibility for will sigkill anything
<slangasek> it's not a ulimit problem?
<ogra> ulimit -a : http://paste.ubuntu.com/133100/
<ogra> looks like on any other of my systems
<slangasek> right, those look sane and normal
<Keybuk> the only thing I can think of that sends SIGKILL is the OOM killer
<ogra> root@babbage:~# free
<ogra>              total       used       free     shared    buffers     cached
<ogra> Mem:        482824      96864     385960          0       6304      74292
<ogra> -/+ buffers/cache:      16268     466556
<ogra> Swap:       996020          0     996020
<Keybuk> though is the KILL always on execve()?
<ogra> hmm, is gdm calling execve when changing to the gdm user ?
<Keybuk> no idea
<ogra> might be
<Keybuk> does gdm receive SIGKILL too?
<ogra> well, it hangs in the process of starting X, not sure where
<ogra> cupsd as well
<ogra> what i noticed was that its a lot of the processes that switch users during initscript execution
<ogra> but apparently not all of them ... i.e. hald runs atm
<Keybuk> on ARM is this?
<lool> yes
<ogra> Keybuk, yup
<ogra> oh !
<Keybuk> so the first thing I'd do is stop trying to do a full boot
<ogra> ps aux gives me uids instead of names for some
<Keybuk> and instead figure out, from something as basic as init=/bin/bash what you *can* do without getting SIGKILL
<ogra> syslog    2496  0.0  0.1   1928   688 ?        Ss   16:05   0:00 /sbin/syslogd -
<ogra> 106       2541  0.0  0.1   2704   868 ?        Ss   16:05   0:01 /bin/dbus-daemo
<ogra> root      2568  0.0  0.2   5572  1304 ?        Ss   16:05   0:00 /usr/sbin/sshd
<ogra> 109       2615  0.0  0.7   7016  3724 ?        Ss   16:05   0:01 /usr/sbin/hald
<Keybuk> that's normal
<ogra> right, intresting that i never noticed :)
<ogra> Keybuk, well, root can do everything apparently
<ogra> as i said above i can startx as root
<ogra> but gdm commits suicide after it restarted once or twice
<Keybuk> yes, yes
<Keybuk> gdm big pile of thing
<Keybuk> start SMALL
 * ogra boots with init=/bin/bash ... i think i tried that before and couls exec all initscripts manually, but i'll try to confirm
<ogra> *could
<Keybuk> stop!
<Keybuk> don't play with init scripts
<Keybuk> SMALLER
<Keybuk> stop drying to debug with a 200 lb lump hammer
<ogra> smaller like ?
<Keybuk> "su"
<Keybuk> "exec"
<Keybuk> "&"
<ogra> root@(none):/# su ogra
<ogra> bash: no job control in this shell
<ogra> ogra@(none):/$
<ogra> aha
<ogra> so here we dont die
<Keybuk> isn't that interesting
<ogra> it is
<Keybuk> work up from there
<Keybuk> if you're bold, try "login" :)
<ogra> works fine
<ogra> so do i see an upstart bug ?
<Keybuk> no
<ogra> or something thats missing in the kernel to give upstart all it needs ?
<Keybuk> it's probably a syscall the ARM kernel maintainers haven't bothered to implement
<ogra> note that a patch for ppoll/pselect is in that kernel i use
<Keybuk> "setuid() ?  when someone needs that, I'll get around fo it"
<ogra> the issue showed up before the patch was in though
<Keybuk> all you proved is that it's not a fundamental problem
<Keybuk> as in the kernel is clearly behaving when there's nothing else running
<Keybuk> so now you need to try and replicate the problem
<Keybuk> maybe figure out a minimal set of commands on the console that always receive SIGKILL
<Keybuk> and figure out *when* in the timeline that starts happening
<Keybuk> if the set fails after boot
<Keybuk> but works with init=/bin/bash
<Keybuk> try single user mode
<ogra> works fine
<Keybuk> if that works, try starting rc2 scripts
<ogra> single is how i started working on that
<Keybuk> and then you'll find something where if you do it, things stop working
<ogra> and couldnt reproduce
<Keybuk> you can reproduce though
<Keybuk> you pasted an strace ;)
<Keybuk> so something was clearly different between the time you did reproduce and the time you didn't
<ogra> oh, indeed
<Keybuk> and that difference is going to be what's causing the problem ;)
 * ogra hugs Keybuk ... it fails after calling /etc/rcS.d/S17procps
<Keybuk> interesting
<Keybuk> that one sets sysctls
<ogra> right
<Keybuk> look in /etc/sysctl.d
<Keybuk> also check for an /etc/sysctl.conf
<slangasek> grep -rvh ^# /etc/sysctl*
<LaserJock> I need to get ubuntu-edu-{preschool,primary,secondary,tertiary} metapackages promoted. Should I file a bug or is a archive admin around who could do it?
<slangasek> LaserJock: does something depend on them already?
<LaserJock> slangasek: no, edubuntu-desktop will but germinate doesn't like adding them until they are in Main
<ogra>  /etc/sysctl.conf is all commented as it should be, i cant imagine 10-console-messages.conf or 10-network-security.conf to be at fault here so i suspect its vm.mmap_min_addr = 65536 in /etc/sysctl.d/10-process-security.conf
<LaserJock> slangasek: I'm just splitting the edubuntu-desktop's deps into sub-groups so no new dependencies are there or anything.
 * ogra comments that and reboots
<slangasek> LaserJock: hrm? germinate should like it fine, the standard practice is to seed then promote
<LaserJock> slangasek: germinate says it's skipping them
<slangasek> hmm
<LaserJock> slangasek: perhaps cjwatson knows but I tried first to just seed then promote
<ogra> YAY !!!!
<slangasek> LaserJock: so that doubly doesn't make sense to me, because the binaries are all built from the same metapackage, which ought to have enough sense to add the deps on its own
<ogra> Keybuk, thanks so much for taking my hand and leading me ... vm.mmap_min_addr = 65536 is the reason ...
<cjwatson> slangasek: germinate-update-metapackage indeed doesn't add things until they're in main
<slangasek> ah
<slangasek> ok, promoting
<cjwatson> slangasek: but the seed should be sufficient
<Keybuk> ogra: really?
<ogra> yep
 * Keybuk wonders why that is done as a sysctl config override at all and not a kernel patch
<LaserJock> cjwatson: sufficient for what?
<slangasek> apparently null dereferences are an integral part of the ARM platform? :P
<Keybuk> I wonder whether it's something the ARM link loader does?
<ogra> well, it started when amitk enabled something in the kernel ... now to find that something :)
<Keybuk> CONFIG_SECURITY probably
<Keybuk> ya know
<Keybuk> ...
<ogra> ogra@babbage:~$ grep CONFIG_SECURITY /boot/config-2.6.28-10-imx51
<ogra> # CONFIG_SECURITYFS is not set
<ogra> CONFIG_SECURITY=y
<ogra> # CONFIG_SECURITY_APPARMOR is not set
<ogra> CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
<ogra> hmm
<Keybuk> a) that sysctl change is pointless, because it's the default
<Keybuk> arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
<Keybuk> b)
<ogra> CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 ??
<ogra> yeah
<Keybuk> I find it mighty suspicious that the ARM arch is missing a def for that entirely
<ogra> not here
<Keybuk> "not here" ?
<cjwatson> LaserJock: for promotion
<ogra> no, i got a newer kernel than you :)
<Keybuk> I'm looking at Linus' git
<Keybuk> there's a default for that sysctl defined for blackfin
<Keybuk> for mips
<Keybuk> for powerpc
<Keybuk> for x86
<Keybuk> but not ARM
<ogra> ah
<Keybuk> this vaguely implies to me that nobody's tested this stuff there ;)
<Keybuk> it's not massively critically serious of course
<Keybuk> but it _is_ interesting
<Keybuk> (more interesting is that our own kernel configs override it back to 0 again <g>)
<ogra> well, its in the middle of being properly merged with the default ubuntu config
<ogra> thats the reason we talk here, since i do the userspace testing of amits builds atm
<Keybuk> I can't see anything particularly in the kernel that would send you SIGKILL of course
<ogra> well, i think thats something the security team should be able to elaborate on
<Keybuk>         if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
<Keybuk>                 return -EACCES;
<Keybuk> EACCES is not SIGKILL
<ogra> indeed
<ogra> and my strace doesnt have any mentioning of EACCESS
<Keybuk> apparmor has a slightly more complicated variant
<Keybuk> but still fundamentally the same
<Keybuk> so I'd be cautious of declaring that it's definitely the cause
<Keybuk> it's more likely that the bug is something else
<Keybuk> and this just happens to trigger it
<ogra> right, but i know how to work around it and can file a bug with a pointer now
<kees> uhm...  ?  arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
<kees> when did that become a kernel default?
<lool> nice
<kees> I mean, I'm for it, but the reason I created the sysctl for it in the first place was to avoid a kernel delta.
<Keybuk> 5cb04df8 arch/x86/configs/i386_defconfig (Ingo Molnar    2008-05-04 19:49:04 +0200 2130) CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
<ogra> seems no defconfig for arm has it anywhere though
<kees> \o/
<kees> GO INGO
<Keybuk> kees: surely it's better to have a one line kernel delta (esp. just to our own configs!) than something in userspace that costs time and can go out of sync?
<ogra> wasnt there an issue with wine ?
<kees> Keybuk: if it's upstream, we can drop the sysctl.  I'm just shocked and delighted that it got made the default.
<Keybuk> ahh, maybe there wasn't a kernel config before
 * ogra vaguely remembers a ML thread
<Keybuk> looks like the kernel config option was added only very shortly before
<kees> Keybuk: I don't think there was.
<kees> I love how all the stuff we cram into Ubuntu eventually becomes the upstream default.
<kees> I wonder if I can convince gcc to do the same.  ;)
<Keybuk> ogra: I would _guess_
<Keybuk> that the ARM tool chain is trying to use the bottom 64k of memory with mmap
<Keybuk> and sulking when it can't
<Keybuk> maybe even the link loader
<Keybuk> this would fit the "you get SIGKILL on exec()" pattern
<ogra> Keybuk, heh, amits kernel is built in a cross toolchain ...
<ogra> i'm waiting for the build in the ppa to finish
<Keybuk> and this didn't happen before perhaps because CONFIG_SECURITY wasn't enabled
<Keybuk> (and that entire bit of the kernel goes missing if you remove that config option)
<ogra> which is building with our own toolchain
<Keybuk> this is all wild hand-wavy speculation
<ogra> right, but i can prove it soon, i was suspecting a toolchain issue though because of other things we had before ... not particulary for this one
<sbeattie> Keybuk: zap_process from within do_coredump() in fs/exec.c does a sigaddset(&t->pending.signal, SIGKILL); but it does it for threads in the group that aren't current.
<Keybuk> sbeattie: ?
<sbeattie> just another possible way sigkill might be getting "sent" from the kernel
<Keybuk> oh, sure
<Keybuk> but that doesn't fit with the "if I turn of the mmap_min_addr sysctl it all works" scenario
<Keybuk> isn't that just when it KILLs threads when the leader dies?
<Riddell> pitti: the notification used by jockey is still the Qt ones which doesn't fit at all with KDE, I ported it to KNotify but don't know if it's a suitable change at this stage (it's a one line change though)  bzr+ssh://bazaar.launchpad.net/~jr/jockey/trunk
<Cimi> is there someone who could help me?
<Cimi> https://bugs.launchpad.net/bugs/332365
<ubottu> Ubuntu bug 332365 in acpi "hibernation doesn't work with samsung nc10 + LPIA" [Undecided,New]
<pitti> Riddell: you have RM powers for Kubuntu, so you tell me :)
<pitti> Riddell: I fixed a few other things, working on one bug fix, and I'll do an upload in an hour or so, thus it would be a good time
<Riddell> pitti: let's go for it then
<Keybuk> Cimi: https://wiki.ubuntu.com/DebuggingKernelSuspend https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting
<pitti> Riddell: aye, will merge; thanks!
<Cimi> Keybuk, the thing is, it *does* suspend
<Cimi> but resuming only works if I add resume=/dev/sda5
<Cimi> it seems something doesn't work in the initram
<kees> Keybuk: another weird bit is that it shouldn't kill if it's an mmap failure -- that should just disallow the mmap.
<pitti> Riddell: is kde/jockey.notifyrc something that needs i18n'ing?
<Keybuk> kees: right, so I'm thinking something else is doing that mmap, failing, then sending itself SIGKILL to get out
<kees> is it perhaps trying to mmap into a 0 location during the loader?  (or is that what you were saying earlier?)
<pitti> Riddell: and it doesn't use the title/text arguments (which are already translated) at all?
<Keybuk> kees: that's what I was trying to say
<Keybuk> or mmaping into a low location anyway
<kees> ARM is weird.  :)
<Keybuk> the link loader is the only thing I could think of which doesn't normally show up in strace ;)
<kees> Keybuk: btw, since that's a default now, I'm going to drop the procps delta.
<Keybuk> kees: it's kinda a default
<Keybuk> kees: it's the upstream default
<ogra> kees, Linux version 2.6.28-10-imx51 (root@everest) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #32 Tue Mar 17 20:18:30 EET 2009 (Ubuntu 2.6.28-10.32-imx51)
<Keybuk> but then our kernel team override that back to 0
<Keybuk> and then we set it back to 64k again
<Keybuk> so you want to co-ordinate that with rtg to fix our kernel config
<kees> Keybuk: oh?  I just looked at our git repo?
<ogra> lets see what a natively built kernel does ...
<Riddell> pitti: it does use the text from the application
<kees> it's correct (64k) in our repo
<Keybuk> is it?
<Keybuk> it's not correct in this build ;)
<ogra> amit uses code-sourcery to cross compile
<Riddell> pitti: but the title comes from the .notifyrc, which should be i18n'ed
<pitti> Riddell: ah, I see, just not the title
<Keybuk> debian/config/i386/config:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
<kees> oh... hrm, I see what you mean now.  i was looking at i386_defconfig  :)
<pitti> Riddell: so I could name this .notifyrc.in and integrate it into POTFILES.in and the rest of magic?
<pitti> Riddell: or is there any way to set the notification title at runtime? (which would ease matters)
<Riddell> pitti: I don't think you can set the title at runtime (it's something I'd quite like the dx people to look into)
<Riddell> pitti: so PITFILES.in would be the way
<pitti> Riddell: ok, I'll look into that
<Riddell> pitti: in the packaging that file needs to be installed to /usr/share/kde4/apps/jockey
<lool> Keybuk: Do you know how we can tell the toolchain to work when it's 65536?
<pitti> Riddell: ok, that needs to happen in setup.py
<lool> or do we need to rebuild the toolchain?
<Keybuk> lool: no idea
<Keybuk> at this point it could be anything
<TheMuso> is an archive admin able to fix up the missing package metadata for linux-ports-headers-2.6.28-5 on hppa/powerpc/sparc? Seems it is present for ia64, but no others.
<Riddell> pitti: if that's the build system being used then yes
<ogra> lool, lets wait for the PPA build to finish, i'll test it then
<lool> Oh wait, it's the kernel binary
<pitti> Riddell: a static title breaks some cases, since ui_notification() is called with differnet ones depending on the situation
<pitti> Riddell: if you can live with that, I'm happy to merge it
<kees> ogra:
<kees> "On arm and other archs it should not be higher than 32768"
<ogra> aha !
<ogra> where is that from ?
<kees> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blob;f=security/Kconfig;h=bcc25d0cf3c3edee1f5535840f71fb47919fbac4;hb=HEAD
<kees> under the help for SECURITY_DEFAULT_MMAP_MIN_ADDR
<ogra> yep, i see it
 * ogra sets it to 32768 to test
<Riddell> pitti: maybe we should change the title to something generic then "Driver Manager" and make the text  "text + title"
<pitti> Riddell: '%s\n\n%s' % (title, text), would that work?
<pitti> well, I have that test suite, I'll find out
<kirkland> bryce: hi, i'm processing the ArchAdmin queue for today, and I'm looking at https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/343014
<ubottu> Ubuntu bug 343014 in xserver-xorg-video-nouveau "[Sync Request] Please sync xserver-xorg-video-nouveau (1:0.0.10~git+20090205+4dfd0b1-1) from Debian [experimental] (universe)" [Wishlist,Incomplete]
<kirkland> bryce: it looks like slangasek sync'd it earlier this week
<Riddell> pitti: yes
<kirkland> bryce: it's marked incomplete, possibly due to the last comment posted?
<Riddell> pitti: actually, it might need html  <br>
<pitti> Riddell: ah, I see; I'll test it
<bryce> kirkland: looking
<lool> ogra: Could you try with 32768 and tell rtg to use that if it works (instead of 0)
 * ogra hugs kees 32768 is fine 
<kees> ogra: ah-hA!  excellent.
<TheMuso> kirkland: were you by chance the person who newed linux-ports binary packages today? If so, linux-ports-headers-2..28-5 has not been correctly added for hppa/powerpc/sparc.
<TheMuso> linux-ports-headers-2.6.28-5 that is
<kirkland> TheMuso: i don't think i touched linux-ports
<TheMuso> kirkland: ok np
<kirkland> TheMuso: I just accepted: http://pastebin.ubuntu.com/133133/
<TheMuso> kirkland: np thats fine
<bryce> kirkland: ok I didn't check if there were already bug reports for -nouveau when I filed mine, so maybe it's just a dupe report
<cjwatson> TheMuso: what's wrong with it? I noticed it was wrong earlier and I made some adjustments
<bryce> kirkland: also I see that it failed to build on some platforms like amd64, but succeeded elsewhere
<TheMuso> cjwatson: linux-ports-headers-2.6.28-5 which is arch all is on ports.ubuntu.com however package metadata for hppa/powerpc/sparc doesn't appear to have it included, hense the problem showing up in ports jaunty probs
<TheMuso> Tested by installing the linux-ports-headers package by hand and apt-get installing an arch linux-headers package, so the dependencies in the packages are correct
<bryce> kirkland: and the last comment on that bug looks to be mistaken; I think he ran into an "ordinary" crash with nouveau
<bryce> kirkland: oh I see, that user reopened the bug.  Silly guy, I think he's mistaken.
<cjwatson> TheMuso: that's weird
<cjwatson> TheMuso: that isn't normally something an archive admin *could* break
<kirkland> bryce: okay, i'll close, and ask that user to open a new bug
<TheMuso> cjwatson: ok, I thought it was something an archive admin had influence over.
<cjwatson> TheMuso: I'll ask the Soyuz wizards
<TheMuso> ok
<TheMuso> wii cjwatson
<TheMuso> woops sorry
<bryce> kirkland: already done
 * TheMuso thought you were in a soyuz channel on freenod.
<TheMuso> freenode
<\sh> moins
<pitti> mvo: argh, I'm dumb; I used "if p:" instead of "if p == 0" in my previous patch
<pitti> mvo: (with p being the result of os.fork())
<\sh> does anyone know how to prevent d-i from asking if I would like to initialize Serial ATA Raid while auto preseeding? on my HP server it always asks me if I want to use Serial ATA...and I don't find any documentation on how to stop d-i to ask me
<\sh> and reading partman-auto-raid pkg source doesn't help me either
<pitti> mvo: so the TemporaryFile() approach works perfectly as well
<cjwatson> \sh: disk_detect/activate_dmraid=false on command line
<cjwatson> \sh: and perhaps file a bug on dmraid, it seems like a bug if it's misdetecting that
<cjwatson> TheMuso: ^- might be worth working with \sh to get details here?
<cjwatson> \sh: sorry, I made a typo, disk-detect/activate_dmraid=false (note s/_/-/)
<\sh> cjwatson: hmm...i thougn partman-dmraid is removed from archives since ages.. or is it merged somehow into partman-{md,auto-raid} ?
<cjwatson> \sh: that is not relevant
<cjwatson> firstly, this question is asked before partman starts; secondly, yes, it's been merged
<TheMuso> \sh: If a question gets asked like the dmraid one, does that mean its automatically preseedable, or does more have to be done with the debconf code for the question to make it so?
<TheMuso> cjwatson: ^^
<TheMuso> \sh: sorry not meant for you. :p
<\sh> cjwatson: ah ok...lemme test it right away...brb 5 mins
<\sh> TheMuso: I just inserted the mentioned option inside the preseed file nwo...if that doesn't work I'll give it a try via kernel append in pxelinux.cfg like the locale stuff
<TheMuso> \sh: ah ok
<cjwatson> TheMuso: generally it's automatically preseedable unless the code is doing something funny, such as explicitly setting its value or clearing the seen flag
<cjwatson> TheMuso: a straightforward input/go/get will Just Work
<\sh> TheMuso: works like a charm now :)
<TheMuso> \sh: great.
<\sh> cjwatson: thx for saving me :)
<TheMuso> cjwatson: right makes sense.
<cjwatson> \sh: np
<\sh> cjwatson: is it documented somewhere, I didn't find anything about this case on the d-i wiki
<cjwatson> no, sorry
<cjwatson> file a bug on installation-guide in Ubuntu
<\sh> cjwatson: har...installation-guide in Ubuntu needs a lot of changes ...
<\sh> cjwatson: so yes..I'll file some bugs :)
<ogra> patches accepted
<\sh> ogra: he
<cjwatson> \sh: I don't know that it's *that* bad
<\sh> and now for the raid of the "tell d-i to not ask for private encrypted directories...."
<cjwatson> \sh: I assume you're starting from the Ubuntu documentation and not the Debian documentation
<cjwatson> for example, the Ubuntu documentation describes that point
<\sh> cjwatson: I was going through the ubuntu documentation...
<\sh> cjwatson: the first steps already broke my heart...nobody tells the admin that some d-i preseed settings needs to be addressed on the kernel append line
<cjwatson> the installation guide does discuss that
<cjwatson> oh, drat, encrypted private directory preseeding was only documented in the first jaunty upload, not for intrepid, sorry
<\sh> cjwatson: it is somehow documented, but not really understandable (when you come from something else like preseeding or kickstarting ;))
<cjwatson> it is documented if you read it in order
<cjwatson> https://help.ubuntu.com/8.10/installation-guide/i386/preseed-intro.html
<cjwatson> \sh: http://bazaar.launchpad.net/~ubuntu-core-dev/installation-guide/ubuntu/revision/435
<\sh> cjwatson: thx :) that's helping a lot :)
<cjwatson> TheMuso: hey, I'd claimed that rpm bug :P
<cjwatson> ah well
<TheMuso> cjwatson: woops, sorry, I missed that.
<TheMuso> I'
<TheMuso> I'm not entirely with it this morning. :)
<mvo> pitti: aha, thanks. that solves the mystery
<pitti> Riddell: is there any way I can test knotify with a small command line tool? I get the icon and knotify4 is running, but I don't see any bubble
<Riddell> pitti: you need to  sudo killall knotify4    before it'll pick up the new .notifyrc file
<pitti> ah
<pitti> Riddell: got it
<Riddell> yay
<pitti> Riddell: hm, the notification has a small and a big icon
<pitti> that looks weird
<pitti> it probably should have only the big one?
<Riddell> pitti: hmm, I don't remember that
<maxb> If a bug is sitting in the "Nominated for Jaunty" state, and I think it's an important blocker, should I assume someone will review all of the nominations in time, or should I be seeking attention more explicitly? (LP: #319825)
<maxb> LP 319825
<ubottu> Launchpad bug 319825 in linux "acer_wmi in Jaunty on Aspire One exposes non-functional (always disabled) rfkill device" [Medium,Triaged] https://launchpad.net/bugs/319825
<Ax3> a ./gdm restart using the jaunty alpha livecd, didn't restart X, is this typical?
<Ax3> it's just idling in a VM: "* Checking battery state...."
<Cimi> didrocks, sorry :( https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-murrine/+bug/344154
<pitti> Riddell: I think I'll title the notification "Hardware Drivers", then we get existing translations for free; okay? ("Restricted" is too special, since we advertise free drivers as well)
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/344154/+text)
<Riddell> pitti: sounds good
<ScottK> maxb: Is it milestoned?
<didrocks> Cimi: just saw it. I am thinking of murdering someone/something :p
<didrocks> Cimi: I'm on it ;)
<Cimi> didrocks, oh sorry
<Cimi> symbol lookup errors
<maxb> ScottK: no
<didrocks> Cimi: no problem, just kidding ^^
<Cimi> oh ok ;)
<Cimi> thank you anyway
<ScottK> maxb: Then it'll probably be looked at, but not at a high priority.
<didrocks> Cimi: that's where I am happy to use bzr for packaging :)
<didrocks> Cimi: can you please comment on the bug during I am performing the new changes?
<Cimi> which kind of comment do you want?
<Riddell> pitti: don't worry about the second icon, if you run plasma it uses much more pretty notifications which look much better
<didrocks> Cimi: just that you released a new version :)
<pitti> Riddell: oh, okay
<Cimi> didrocks, I already did
<didrocks> Cimi: ok, you was faster that LP to send me the e-mail so ;)
<Cimi> maybe ;)
<didrocks> Cimi: hopefully, there is no patch with autotools changes in this packages ^^
<Cimi> didrocks, also 0.60.1 had the wrong link to the website
<Cimi> it is http://www.cimitan.com/murrine
<Cimi> and not cimi.netsons.org/pages/murrine.php
<didrocks> Cimi: 0.90.1 or 0.60.1?
<Cimi> I don't know if it was updated in the 0.90.x series
<Cimi> didrocks, 0.60.1
<Cimi> the .deb package I mean
<didrocks> Cimi: ok, seeing it in debian/control. I change the Homepage: value
<pitti> Riddell: this works well for me now, modulo double-icon: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/529
<pitti> asac: bug 278153 is a beta-release blocker, but wishlist; given that it's not a regression, I don't think it should be a release-targetted bug at all? WDYT?
<ubottu> Launchpad bug 278153 in network-manager-vpnc "NetworkManager VPN plugins should be installed by default in ubuntu" [Wishlist,Triaged] https://launchpad.net/bugs/278153
<Riddell> pitti: looks good
<pitti> Riddell: uploaded now
<asac> pitti: yeah. basically i wanted a decision until beta ... which is why i marked it as such
<pitti> I see
<asac> pitti: i will let you know tomorrow ... have to check with upstream about committments etc.
<ScottK> asac: What's your support plan for firefox-3.1?
<directhex> hide under a big blanket until the users have gone past?
<asac> support until EOL
<ScottK> asac: OK.  That sounds great.  Thanks.
 * pitti sighs at component-mismatches
<asac> ScottK: lets see how well i can scale ;) ... but security infrastrcture has become better. riding upstream shouldnt be a big problem
<directhex> i thought they decided to name it 3.5 instead
<ScottK> asac: OK.  You know my concern about FF supportability by MOTU.  As long as you and mozillateam are behind it, then I'm fine.
<asac> ScottK: yeah. fwiw, its not branded. so basically any MOTU can touch it without risking of getting whipped ;)
<asac> not saying i think MOTU will do that until EOL ;) ... just because thats could be a concern for mozilla stuff in universe
<ScottK> That's something at least.
<ScottK> Agreed.
<ogra> pitti, please note that bug 322798 is verified to not show up anymore in recent hal builds (though the patch might still make sense)
<ubottu> Launchpad bug 322798 in hal "Segfault in hald startup (hald/linux/devices.c)" [High,In progress] https://launchpad.net/bugs/322798
<LaserJock> cjwatson: since the edubuntu.jaunty seeds inherit ubuntu.jaunty can edubuntu's supported seed to be "in addition to Ubuntu's supported seed"?
<pitti> ogra: oh, nice; I just spotted it on the milestone list and assigned it to me, but didn't look at it
<ogra> pitti, as i said, makes sense, but not urgent
<pitti> ogra: ok, thanks; taking off the release radar then
<Stskeeps> ogra: ran into same problem as bug 322798 on n8x0s (alternate patch we used: http://bazaar.launchpad.net/~carsten-munk/hal/led-problem/revision/2 )
<ubottu> Launchpad bug 322798 in hal "Segfault in hald startup (hald/linux/devices.c)" [High,In progress] https://launchpad.net/bugs/322798
<ogra> Stskeeps, did you try the latest hal ?
<ogra> the OP verified it didnt show up with it anymore
<Stskeeps> ogra: as i recall my debugging of it, the patch indicated in the bug would definately fix it
<Stskeeps> from code logic point of view
<ogra> Stskeeps, you should mention all that on the bug ;)
<Stskeeps> ogra: and HAL didn't die constantly, just quite occasionally, so that might cloud the issue
<ogra> please note that on the bug too, so pitti is aware, i only had feedback from the OP and didnt even see it myself
<Stskeeps> yeah, done so now
<ogra> good
<geofft> Anyone online who can comment on the Intrepid SRU for mit-scheme (bug 341832)?
<ubottu> Launchpad bug 341832 in mit-scheme "SRU: mit-scheme uninstallable on Intrpepid" [Undecided,New] https://launchpad.net/bugs/341832
<slytherin> seb128: did you get any time to look into DVD playback problem?
<seb128> slytherin: no
<seb128> slytherin: will do that after the beta freeze, there is no hurry it's not in main
<seb128> ie that can be uploaded during the freeze or after beta
<slytherin> seb128: ok. I was planning to upload it before beta but I will wait.
<seb128> slytherin: well you can upload if you get confirmation that the change fixes the issue
<seb128> we can still adjust later
<slytherin> seb128: I am asking people on #ubuntu+1 currently.
 * calc thinks he found the source to all the xsl related problems in OOo
 * calc is doing a test build and if it works an upload later tonight
<cjwatson> ogasawara: maxb asked up ^- there about bug 319825's jaunty nomination; seems like your department
<ubottu> Launchpad bug 319825 in linux "acer_wmi in Jaunty on Aspire One exposes non-functional (always disabled) rfkill device" [Medium,Triaged] https://launchpad.net/bugs/319825
<doko> cjwatson: I don't have a list, do you still can do the db queries?
<fta> slangasek, the last libfreetype update broke some of my stuff using ia32. there's a problem with the new FT_Get_Advance symbol that is detected in the headers (2.3.9) but not in the ia32 lib
<fta> would be nice to update ia32libs
<slangasek> fta: I don't claim any particular responsibility for the ia32-libs eyesore; you're a MOTU, so are also able to do the update?
<slangasek> if you do fix it, perhaps you'd like to fix it at the same time so that gtk isn't missing symbols :-P
<fta> well, i pinged you to inform you that your libfreetype update broke some stuff. that's it
<fta> i can sure update ia32 but from experience, a lot of stuff are old and/or missing from there
<slangasek> yes, this is part of why ia32-libs is a horrible hack
<slangasek> another part is that it takes an obscene amount of time to do an upload of ia32-libs from my Internet connection, and I'd sooner avoid that in favor of getting more productive things done
 * ScottK really wished people wouldn't call something 'Ubuntu Drupal' when it isn't actually in Ubuntu.
<ScottK> wished/wishes
<kees> asac: hm, I think something weird happened to fontconfig.  my ~/.fonts.conf seems to be ignored now.
<asac> kees: what makes you think that?
<asac> kees: which pkg version?
<kees> asac: I *think* it's fontconfig -- it could be other things, but basically my ~/.fonts.conf-defined fonts vanished on update (2.6.0-1ubuntu9 vs 2.6.0-1ubuntu4)
<asac> kees: what was in that file?
<kees> http://www.outflux.net/blog/archives/2008/06/22/bold-fonts-in-libvte-gnome-terminal-terminator/
<kees> it might be that something else is overriding the "Fixed" family.
<asac> kees: we had a regression in u9 that you can workaround by ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/
<asac> kees: check that its not what you are seeing.
 * kees checks
<tjaalton> Fixed is a bitmap font
<kees> tjaalton: correct.
<asac> yeah. that makes sense then i guess
<tjaalton> so something else might've broken it
<tjaalton> but it sounds weird not to honor .fonts.conf
<asac> tjaalton: i dont think it doesnt honour .fonts.conf
<andersk> Not sure if this is related, but fontconfig-config 2.6.0-1ubuntu10 is installing a /etc/fonts/conf.d/10-no-sub-pixel.conf that reappears on upgrades even if removed.
<tjaalton> asac: but it should override the system-wide settings
<kees> Ah! sweet font is back
<tjaalton> kees: adding the link helped?
<kees> asac: yeah, that fixed it.  it's because other bitmaps were appears that resolved to "Fixed" and my 1 enabled bitmap fonts was getting obfuscated.
<kees> tjaalton: yeah
<tjaalton> huh :)
<asac> kees: right. good
<asac> so its fixed in ubuntu10 for oyu
<kees> my ~/.fonts.conf explicitly enables my local bitmap font
<kees> asac: sweet, thanks, I see that from the changelog now.  I'd missed that I didn't have ubuntu10 installed.
<cjwatson> doko: err, maybe, but I don't know how offhand - do you still have the necessary SQL to hand?
<doko> cjwatson: unfortunately not, maybe cprov has?
<cjwatson> might as well just ask him to run it then :)
<doko> cprov: ^^^
<cprov> doko: what was the question ?
<doko> cprov: https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027772.html
<cprov> doko: checking
<doko> cprov: subtracting the packages which have been built after 2009-03-16 and which only build binary-indep packages
<cprov> doko: anything built on lpia from -13 to -16, right ?
<ArthurLiu> hi, who is admining the GSoC program at ubuntu ? the wiki pages don't mention it
<doko> cprov: hmm, more specific: between the two file uploads: 2009-03-11 14:00 UTC+1 and 2009-03-16 20:00 UTC+1
<doko> ArthurLiu: looks like Ubuntu was not accepted this year
<ArthurLiu> wha?
<directhex> debian was. go work on sexy debian projects
<ArthurLiu> err, on #gsoc they say you are accepted
<Stskeeps> look at second part of the first box, in http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009 - says accepted :P
<doko> interesting. this did change within the last hour
<kblin> hi filks
<kblin> *folks
<kblin> ArthurLiu tells me you can't find your org on the GSoC accepted list...
<kblin> I'm happy to walk you through the steps needed to get Ubuntu to show up on that list
<lh> doko: ping
<kblin> or let lh tell you directly
<bryce> heya lh
<kblin> hi bryce, btw :)
<lh> bryce: greets!
<bryce> heya kblin
<doko> lh: pong
 * kblin is Kai from WorldForge :)
<bryce> kblin: hey small world :-)
<lh> hello everyone, leslie hawthorn, google open source team
<lh> so first of all, ubuntu *was* accepted
<SRabbelier> still is
<lh> http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009?limit_1=50&limit_0=100&offset_1=50
<lh> SRabbelier: smart alec
<SRabbelier> :D
<doko> hmm, my bad, I didn't see this when checking
<SRabbelier> apparently some people are confused
<SRabbelier> need to be crystal clear :P
<lh> doko: now an issue on file for this
<lh> so for your ideas list.
<slangasek> kblin: nuh-uh, you're Kai from Samba!
<slangasek> you're not fooling me
<lh> there's some stuff already on there, but let's talk about how to improve and refine it.
<lh> for each idea
<lh> try to think of something that needs to get done to help move the project forward, bonus points if it is sexy. doesn't have to be fun and exciting, but always helps to have a few of those.
<lh> please classify ideas as easy, medium, hard or beginner, intermediate, something along those lines. scale of 1-10
<lh> helps students decide which ideas to explore first and what is best for them to tackle
<kblin> slangasek: oh, darn, foiled
<lh> also each idea ought to be accompanied by links to documentation
<doko> ok, will address this tomorrow. there's another criteria which dserves bonus points: be able to find a mentor
<lh> e.g. if you want to work on foo, check out the documentation for foo here, here and here, and this documentation on baz over here is also useful
<lh> doko: absolutely. ideas need to have an assigned mentor and that person needs to be able to devote no less than 5 hours per week to mentoring.
<lh> if you don't have time to mentor, don't sign up. better an idea not get worked on than a potential contributor to your community has a bad experience.
<lh> also list where someone should ask for help or guidance, maybe that is this channel, maybe another, maybe it is a mailing list. make sure that's explicit on your ideas page.
<lh> if you want me to review drafts, can do.
<doko> yes, the ml is mentioned on the ideas page.
<lh> okay great. that's all the guidance i've got for the moment. i am around on freenode frequently so if you need help i am here.
<bryce> lh: whew, scared me a bit; I didn't see inkscape on the list, but found it buried.  Wow that's a very confusing page
<SRabbelier> bryce: what's confusing about it 0.o
<SRabbelier> its' the standard code.google.com style list... :-/
<bryce> SRabbelier: there's two lists on the page, and it's unclear which of the two lists to look at (ubuntu was on the 1st, inkscape on the 2nd).  Also the lists appear to be alphabetized, so I didn't think to look at the second page, but in fact it isn't fully alphabetized and inkscape is just sorted towards the bottom for some reason
<SRabbelier> bryce: both
<SRabbelier> bryce: it even explains on the second list
<SRabbelier> bryce: what the purpose is
<SRabbelier> bryce: the list is sorted by link_id
 * lh heads back to her overflowing inbox
<lh> peace y'all
<bryce> SRabbelier: fair enough, but I wouldn't have guessed inkscape's link_id would be "sxc"
<SRabbelier> first list, actually
<ArthurLiu> is there a specific ubuntu soc irc channel ?
<SRabbelier> bryce: that's their fault
<SRabbelier> bryce: don't blame me
<SRabbelier> bryce: sxc seems like a particularly bad one, if you ask me
<SRabbelier> "inkscape" wouldof made more sense
<fta> Keybuk, I can't update ia32-libs because the last isdnutils wasn't built: https://edge.launchpad.net/ubuntu/jaunty/+source/isdnutils/1:3.12.20071127-0ubuntu4
<bryce> SRabbelier: I'm not blaming anyone, just explaining why I got confused
<SRabbelier> bryce: sorry, true :)
<bryce> SRabbelier: so it appears an organization only gets one chance to set that, and if they make a mistake, they can't change it??
<SRabbelier> bryce: yup
<SRabbelier> bryce: exactly the same way with your personal link_id
<SRabbelier> bryce: the notice about that is like, THIS BIG
<bryce> SRabbelier: heh, expecting users to read docs... you're certainly optimistic ;-)
<SRabbelier> bryce: oi, if they don't, I'm not helping them ;)
<SRabbelier> bryce: you lost your right to my time when you decided not to read the docs (with "you" not referring to you personally)
<SRabbelier> if you can't take the time to read the docs, which we wrote for this purpose, then I'm sure as hell not going to spend my time rewarding you :P
<bryce> wow, that would save me *sooo* much work if I did that
<tkamppeter> Any Python expert here? I can build system-config-printer without problems on my local Jaunty (updated today) and I have also uploaded it successfully yesterday. Today I upload it again (tiny patch) and get an FTBFS: setup.py says "options --install-layout and --prefix are exclusive". The same call worked yesterday.
<SRabbelier> bryce: I dont' do it as strict as I portray it here :P
<SRabbelier> bryce: I'm exagerating by a lot
<SRabbelier> bryce: but I don't have the time to worry about "what if people don't read notices THIS BIG" :(
<crdlb> tkamppeter: just drop the --prefix usage?
<SRabbelier> anyway, if you have any suggestions on how to improve melange, please do file a  http://tinyurl.com/new-issue or drop us a note in #melange
<SRabbelier> and even if you didn't read the documentation, I'll do my best to reply ;)
<SRabbelier> no guarantees though :P
<sbeattie> tkamppeter: I don't know the answer, but in your next system-config-printer upload, could you include http://launchpadlibrarian.net/23529565/system-config-printer_1.1.3%2Bgit20090218-0ubuntu5.debdiff (from bug 338442)
<ubottu> Launchpad bug 338442 in system-config-printer "bug reports would benefit from an apport hook" [Medium,In progress] https://launchpad.net/bugs/338442
<tkamppeter> crdlb: The "make install" runs
<tkamppeter> /usr/bin/python setup.py install --install-layout=deb --prefix=/build/buildd/system-config-printer-1.1.3+git20090218/debian/tmp//usr
<tkamppeter> This worked yesterday but today it gives the error. My patch does not touch setup.py.
<bryce> SRabbelier: http://code.google.com/p/soc/issues/detail?id=331 seems to already describe the UI design problem that leads to the user confusion
<SRabbelier> bryce: that one's fixed
<SRabbelier> it was a duplicate of... another one
<SRabbelier> lemme find it, and close it as duplicate
<ebroder> tkamppeter: I think you want to --root=$(DEB_DESTDIR) or whatever it's called instead of --prefix
<crdlb> shouldn't that sort of thing be done with DESTDIR (--root with distutils I guess)
<tkamppeter> crdlb: debdiff is here: http://launchpadlibrarian.net/24068667/system-config-printer_1.1.3%2Bgit20090218-0ubuntu8_1.1.3%2Bgit20090218-0ubuntu9.diff.gz
<SRabbelier> bryce: I'm /part-in #ubuntu-devel, please do join #melange ;)
<bryce> SRabbelier: anyway, I didn't set up the inkscape thingee so dunno what the problem was exactly.  But really the issue now is that there seems to be no way to fix the mistake now that it's been made
<SRabbelier> bryce: yeah, I know what you mean, but it's a technical limitation I'm afraid :(
<SRabbelier> bryce: if we made it mutable things would be a lot slower
<tkamppeter> crdlb: The "make install" call has the DESTDIR, the shown command line is what "make install"does internally and what worked on the build server until; yesterday and what is still working on my box.
<crdlb> tkamppeter: it was apparently changed in the fix for bug 338395
<ubottu> Launchpad bug 338395 in python2.6 "distutils appends '/local' to to user-specified install prefix" [Medium,Fix released] https://launchpad.net/bugs/338395
<pygi> hey folks
<pygi> where is your list of gsoc09 ideas?
<kirkland> mako: ping
<dtchen> kirkland: mako or maco?
<kirkland> dtchen: good call
<kirkland> dtchen: maco, actually
<TheMuso> dtchen: anything we need to get in for pulse before beta freeze?
<dtchen> TheMuso: yes, quite a bit
<dtchen> i'm working as fast as i reasonably can given i'm traveling for work.
<TheMuso> dtchen: ok np
<TheMuso> dtchen: anything I can help with?
<dtchen> TheMuso: for pa, not yet. i think alsa-driver has a pending merge for ~ubuntu-core-dev.
<TheMuso> oh ok will check up on that
<maco> sorry my keyboard decided to pretend not to exist right when you pinged...well, all of the keyboard except ctrl alt backspace
<maco> kirkland: whats up?
<kirkland> maco: hiya, just looking at https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/317895
<ubottu> Ubuntu bug 317895 in ecryptfs-utils "netboot newuser and ecryptfs fails to login" [High,Triaged]
<maco> oh right
<kirkland> maco: tried to reproduce that again, no luck
<maco> need to re-test that here
<tkamppeter> sbeattie: Uploaded your debdiff as 0ubuntu10, thanks for the reminder.
<kirkland> maco: cool, that would be muchly appreciated on this end
<kirkland> maco: i'm about to blast an update of ecryptfs-utils that fixes 4 or 5 bugs
<sbeattie> tkamppeter: thank you!
<kirkland> maco: was trying to fix that one too, but still don't see where the problem actually lies
<maco> kirkland: alright, installation starting. at some point i need to learn to automate such things
<kirkland> maco: yeah, that helps
<maco> is there kickstart for ubuntu?
<kirkland> maco: mathiaz is really good at such magic
<kirkland> maco: ack, there is.
<maco> thought so...will have to look into it for karmic play time
<kirkland> mathiaz: how about a blog post to communicate some of your automated installation magic you use for testing?
<maco> whats the good of having two laptops if they dont both get some testing
<mathiaz> kirkland: it's on my todo list
<kirkland> mathiaz: \o/
<mathiaz> kirkland: I plan to write a blog post (or two) about that aspect of testing
<mathiaz> kirkland: maco: I've already wrote a post presenting the big picture: http://ubuntumathiaz.wordpress.com/2008/09/18/automate-ubuntu-server-iso-testing/
<maco> mathiaz: thanks
<doctormo> kirkland: hey there, got a jaunty box that had ecryptfs, which has now failed, the mount doesn't seem to mount anything, no errors.
<maco> on the topic of testing: laserjock says vm image distribution was talked about to ease testing before but was dismissed for some reason or other. he suggested possibly because vms are bigger than isos. meh, torrents, i say. so i put a jaunty alpha 6 vm for virtualbox up at http://thepiratebay.org/torrent/4780245 if you wanna point potential testers there.
<dtchen> it'd be more useful to have vms generated from the daily and daily-live
<dtchen> the same rsync system could be harnessed
<maco> thats true
<maco> well generating from the cd could be hard. running an update on the vm each day would be easier
<maco> but distribution on the initial vm could be painful. that's 1.1gb after i lzma'd it
<mathiaz> maco: I've looked at ubuntu-vm-builder?
<maco> mathiaz: its for kvm only, right?
<maco> well kvm / qemu?
<mathiaz> maco: it can build a vm in a couple of minutes
<maco> granted i made the default hard disk decently sized, but an empty .vdi is sparse
<mathiaz> maco: not only. I think it supports other format as well.
<maco> mathiaz: does it do virtualbox? that seems to be the popular one
<mathiaz> maco: not sure about virtualbox though.
<maco> (i've only used it for kvm)
<maco> virtualbox is definitely more user-friendly
 * calc found a workaround to the problem of saving xsl related files in OOo
<mathiaz> maco: if not, it should be easy to add virtualbox support?
<mathiaz> maco: virtualbox more user-friendly -> how so?
<maco> easier to reconfigure
<maco> easy to configure to begin with. can keep the command line nicely hidden away
<mathiaz> maco: virt-manager makes things easy to setup
<mathiaz> maco: for kvm setup.
<maco> i remember there's a gui somewhere for it
<maco> it was the intimidating sort of gui that makes one say "i might as well use the command line. *gulp*"
<dtchen> generating from the cd is not difficult; see VBoxManage
<maco> im thinking of the class of users that dont know the command line well or at all and thus should not be using devel versions on metal. setting up kvm would be icky for them. it was icky for me, and i was following a howto on the wiki.
<mathiaz> maco: which how-to are you refering to?
<mathiaz> maco: what was *icky* for you?
<maco> the first annoyance was that i was on hardy and trying to test intrepid in a vm. hardy refused to let me tell it i wanted intrepid. it'd only let me choose stable releases.
<maco> i think the stable releases ought to offer devel releases for the vm, since that's a nice way to test
<maco> i was on https://help.ubuntu.com/community/KVM/CreateGuests (well that used to be a chunk of a larger page). i attempted to follow the "use an iso" way to get intrepid, but that got pretty hairy. i think i had issues with what type of image to create and whether that image already existed or not. i gave up and told ubuntu-vm-builder to install a hardy vm then did a do-release-upgrade on it
<maco> virt-install was what i found most "icky"
 * TheMuso likes virt-install
<maco> well finding that the docs claimed an --os-variant existed that did not was fun...
<tkamppeter> crdlb: Thanks for the hint with the "--root", system-config-printer vuilds again (0ubtuntu11).
<maco> i suppose documentation explaining how to use it without sudo privs would be nice. unfortunately, i cant answer that question, so i cant write that documentation
<maco> im pretty sure its possible to use a vm without root privs though (if not: why?)
<maco> sorry, dont mean to be whiny about the tools, i just dont think id suggest them to anyone that's used linux less than a year
<maco> if you can figure out how to use them without extra help, you're also probably perfectly capable of troubleshooting weird breakage on actual hardware
<kees> tjaalton: in bug 342198, do you mean that we should change /var/run or /var/db to /var/cache ?
<ubottu> Launchpad bug 342198 in apparmor "wrong path in abstractions/nameservice" [Undecided,New] https://launchpad.net/bugs/342198
<maco> oh just remembered something.  there's a problem for kubuntu/ubuntu users (people with both) where if you run gnome first, seahorse sets up ~/.gnupg/gpg.conf blank because it just creates the file if it doesnt exist. that breaks things in kde because it doesn't say use-agent. the skel file has use-agent in it. can something be done to make sure the skel file is copied in before seahorse-agent starts the first time?
#ubuntu-devel 2009-03-19
<maco> that may have been fixed since i noticed it last month...im not sure. i didnt see any updates for it or receive bugmail for that bug though
<LaserJock> slangasek: how long 'til Beta Freeze?
<slangasek> LaserJock: a sunset and a sunrise again
<LaserJock> slangasek: so end of Thursday UTC?
<slangasek> afternoon/evening Thursday UTC
<LaserJock> k
<LaserJock> thanks
<cjwatson> slangasek: heads-up: http://people.ubuntu.com/~cjwatson/lpia-rebuilds-20090319
<cjwatson> slangasek: IMO we need to fix the affected libraries (esp. in main) ASAP but can perhaps defer big things like OOo
<slangasek> cjwatson: these should be pretty automatable, yes?  just rebuilds?
<cjwatson> I'm going to try to construct something that vaguely resembles a topological order
<slangasek> ok
<cjwatson> just rebuilds, but the ordering makes it exciting
<slangasek> well, we could do all the uploads now before the freeze and sort out the ordering in LP :)
<cjwatson> we could, but that scares me a bit more
<slangasek> ok
<StevenK> cjwatson: I have a few scripts I use for mass rebuilding for NBS, so if you want me to clean up after the exciting rebuilds are built, I can do it
<cjwatson> I'll see how far I get. Thanks
<cjwatson> I'll write a simple script for myself that fits my source tree layout, I've needed one for a while anyway
<Hobbsee> blah.  Thanks, exploding jaunty!
<Hobbsee> i presume the dist-upgrader called from the recovery mode is in update-manager or something?
<Hobbsee> i've forgotten what it's acutlaly called :(
<Hobbsee> oh, found it.
<mrooney> Anyone know if this is a dupe / known issue? bug 344954
<ubottu> Launchpad bug 344954 in acpi-support "stop suspending on lid-close while shutdown/hibernate running" [Undecided,Invalid] https://launchpad.net/bugs/344954
<mrooney> hrm I wonder who changed it to a question
<bryce> mrooney: is that with -intel?
<stgraber> hmm, is there something broken with gtk on powerpc ?
<bryce> mrooney: if so, see the lid-close quirk in the X section of the wiki.
<bryce> mrooney: oh nm, seems not to be a lid close crash.
<mrooney> right, just that it will suspend if set to on lid close, even when already shutting down / hibernating
<mrooney> bryce: is that out of your area, then?
<bryce> mrooney: yup
<mrooney> okay, thanks then :)
<mrooney> (hopefully see you again at UDS)
<bryce> I'll be there :-)
<maco> oh that one's annoying
<maco> mrooney: or suspend twice ;)
<mrooney> maco: haha oh no!
<mrooney> bryce: I might be, I'll know when the sponsorship results come out!
<mrooney> maco: have you seen that bug before?
<maco> on kde if i click suspend then shut the lid before it finishes suspending, when i resume, itll immediately suspend again
<mrooney> haha, killer feature
<maco> i found a bug on gnome-power-manager that said fix released...that it wouldnt send both events. i filed a bug in kde's bug tracker for power devil doing it
<maco> i think it was something to do with hal changes that both g-p-m and power devil handled wrong?
<TheMuso> stgraber: whats the problem?
<kees> anyone familiar with nscd?
 * slangasek hisses
<maco> mrooney: https://bugs.edge.launchpad.net/ubuntu/+source/acpi-support/+bug/306310 is the one i was thinking of
<ubottu> Ubuntu bug 306310 in acpi-support "Resume (from memory) goes back to sleep automatically" [Medium,Fix released]
<slangasek> 306310 is specifically about multiple events showing up on ThinkPads when a single key is pressed
<slangasek> kees: that was an affirmative 'hiss'
<kees> slangasek: ah!  I thought in the negative.
<kees> I'm trying to sort out the apparmor abstraction for it
<kees> it seems that   /var/cache/nscd/{passwd,group,services,host}    r,
<slangasek> no, the affirmative answer to that question sounds like "ha-ha"
<kees> is desired
<kees> heh
<cjwatson> doko: could you fix python-tcpwrap? I'm not sure I know distutils well enough to know what I'm supposed to do
<Ampelbein> hmm. some help please, i got a build-error for powerpc on package i updated, the buildlog says:   libebook1.2-dev: Depends: libgnome2-dev but it is not going to be installed. Full log under: http://launchpadlibrarian.net/24082853/buildlog_ubuntu-jaunty-powerpc.cheese_2.26.0-0ubuntu1_FAILEDTOBUILD.txt.gz . is this a problem with my package or can i ignore this error?
<cjwatson> Ampelbein: that usually means that there's a problem with the archive at the moment, not with your package
<cjwatson> or rather with the relevant build-dependencies in the archive
<cjwatson> Ampelbein: http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html shows that some things are in a bad way
<cjwatson> Ampelbein: usually you can retry once the build-dependency no longer appears in the page above, which may happen naturally
<Ampelbein> cjwatson: ok, thanks. is the package automatically retried or should i inofrm my sponsor about this?
<cjwatson> no, it's not automatically retried, although the buildd administrator may do a "mass give-back" (i.e. retry everything)
<slangasek> kees: sorry, was that the extent of the question?
<cjwatson> your sponsor has a button to retry it, although should use it responsibly to avoid tying up buildd resources
<kees> slangasek: yeah, though I resolved it with a chroot.  var/cache is desired (not /var/run)
<slangasek> mmk
<Ampelbein> cjwatson: then i wait for the package to disappear from the problem list and let my sponsor know. thanks for helping me.
<slangasek> not sure why it would be "r" though - perhaps things have changed since the last time I used nscd, but I didn't think anything accessed the cache directly aside from nscd, which would also need to write to it
<IntuitiveNipple> Two identical Vaio notebooks. default Xubuntu installations. During boot one shows the usplash graphic the other goes blank until log-in. Where do I start looking for clues? I've already compared dmesg and kern.log line-by-line.
<slangasek> the grub config?
<slangasek> usplash being enabled by the 'splash' boot option
<IntuitiveNipple> slangasek: nothing different there at all, that's the weirdness. Standard default installs. The issue is that one seems to fail to set a workable video mode.
<kirkland> siretart: around?
<IntuitiveNipple> The new artwork that arrived for Xubuntu today is really nice :)
<kirkland> siretart: i think the screen-profiles package is in good shape now, for your ITP for Debian
<Ampelbein> Can someone from ubuntu-main-sponsors have a look at bug #345168 and sponsor if everything is ok?
<ubottu> Launchpad bug 345168 in nautilus-cd-burner "Please sponsor version 2.25.3 in jaunty" [Wishlist,Confirmed] https://launchpad.net/bugs/345168
<mrooney> I thought that was dropped in favor of brasero?
<mrooney> or am I just thinking of the right-click action?
<Ampelbein> mrooney: can you give me a hint where i can find the decision to drop it? desktop-mailing list?
<mrooney> Ampelbein: I am not a main sponsor, just an observer with a comment, you would know more than I, I suspect
<mrooney> Ampelbein: here is what I was thinking of: http://live.gnome.org/TwoPointTwentyfive/Desktop#head-1200774a23d2266553d34d77a891d4d9a3b36ff0 , the last deprecation
<Ampelbein> mrooney: not really. i'm not that deep with ubuntu-development and (as my questions suggest) have to rely heavily on guidance/help by others.
<Ampelbein> mrooney: ok, but i think as long as we have nautilus-cd-burner in ubuntu we should ship the latest available version.
<mrooney> Ampelbein: yeah I suspect you are correct
<mrooney> hopefully someone here can help you
<cjwatson> anyone know enough about sparc to tell me authoritatively how to fix http://launchpadlibrarian.net/24086899/buildlog_ubuntu-jaunty-sparc.debian-installer_20081029ubuntu26_FAILEDTOBUILD.txt.gz?
<cjwatson> doko: ditto cx-bsdiff, another --install-layout/--prefix conflict
<ebroder> cjwatson: is there a list of those anywhere yet that people can help go through?
<cjwatson> doko: what's http://launchpadlibrarian.net/24087393/buildlog_ubuntu-jaunty-sparc.python-pysqlite1.1_1.1.8a-3ubuntu2_FAILEDTOBUILD.txt.gz about?
<cjwatson> ebroder: I posted to ubuntu-devel, but noted that I actively don't want help with it yet
<cjwatson> well, except feel free to look at the FTBFS
<cjwatson> reason is I'm taking some care over dependency ordering
<cjwatson> http://people.ubuntu.com/~cjwatson/lpia-rebuilds-20090319
<\sh> guys, I just updated some packages for jaunty, and after that, xorg is freezing totally with weired graphics, and a total freeze of the system...
<stgraber> \sh: ati ?
<\sh> stgraber: yepp
<\sh> trying to find any hint on the error...
<stgraber> had that yesterday, installing fglrx and forcing it solved it for me though I saw a new -ati has been uploaded an hour or so ago
<stgraber> starting X from SSH it crashed on a libdri call IIRC
<stgraber> at least on my lappy it was only X that crashed taking the video card with it, ssh access to the laptop (had to install it from rescue mode) worked fine
<ion_> fglrx diverts some libdri file. Try the free ati driver after removing fglrx if you have it installed.
<\sh> ion_: you mean complete remove everything which name sounds like fglrx...
<ion_> dpkg -S libdri and remove the fglrx package it prints.
<\sh> ion_: ok..removed fglrx completly...only xserver-xorg-core remains with a hint on libdri
<\sh> giving it another try ,-)
<\sh> brb
<emgent> emorning people
<bryce> heya emgent
<emgent> ;)
<bryce> ion_: you can refer people to https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver if they're having trouble going from -fglrx -> -ati
<ion_> Thanks
<bryce> stgraber: yea let me know what you think of the new -ati.  Looks like it fixes a variety of bugs.  Would be nice to know if we can close any in LP as a result.
<bryce> ion_: yeah I've been trying to flesh out https://wiki.ubuntu.com/X/Troubleshooting with pages for sorting out all the common classes of X errors people run into
<stgraber> bryce: sure, will try it.
<Ampelbein> question: what is the difference between the -dbg and the -dbgsym packages? for example libglib2.0-0-dbg and libglib2.0-0-dbgsym both exist.
<cjwatson> Ampelbein: -dbg: explicitly produced by the source package build, may (or may not) be a separate build pass with significant extra debugging options turned on; -dbgsym: automatically generated from the normal build process by just saving off the debugging symbols to separate files
<Ampelbein> cjwatson: ah, ok. thanks again.
<\sh> re
<\sh> ion_: well, the trick with removing fglrx worked for ati..but when it's starting up into X, I lose now my whole usb stack
<\sh> while being in textmode(rescue mode now) usb input works fine
<\sh> tried 2.6.28-10 and 2.6.28-11
<\sh> kernel wise
<ion_> Anything interesting about hal in /var/log/Xorg.0.log?
<\sh> lemme check
<\sh> config/hal: couldn't initialize context (((null)) ((null)))
<\sh> only hint about tha
<\sh> t
<ion_> Iâd begin by googling that error message. I havenât encountered such problem myself.
<YokoZar> I seem to remember pitti saying something about the keyring prompts for network manager going away in Jaunty.  Was that going to happen?
<\sh> ion_: much better...
<\sh> ion_: Xorg can't find core input devices (keyboard and mouse), complains about hal to be the one who gives this information
<\sh> and it tells me to reconfigure HAL or to disable AllowEmptyInput
<ion_> The message about being unable to locate core devices is normal. The one about being unable to initialize context is not.
<\sh> ion_: the only match for ubuntu bug #318129 ,-)
<ubottu> Ubuntu bug 318129 in xorg "xserver-xorg (EE) config/hal: couldn't initialise context: (null) ((null))" [Undecided,Fix released] https://launchpad.net/bugs/318129
<ion_> sh: I take it lshal works and thereâs an entry for your keyboard with âinput.x11_driver = 'evdev'â in its output?
<\sh> ion_: checking
<\sh> ion_: hmm..I'm in the rescue system...and /etc/init.d/dbus start works.../etc/init.d/hal start doesn't
<\sh> brb
<calc> cjwatson: i'll be uploading OOo in a few minutes, iirc it is on the list of lpia affected packages
<\sh> ok..hald is not running
<\sh> ./etc/init.d/hal start|restart doesn't give a sound...
<\sh> ok back in business
<\sh> thx ion_
<ion_> What was wrong with hal?
<\sh> ion_: wasn't installed correctly...whysoever
<\sh> --reinstall helped here
<maco> did the archive signing key change recently?
<maco> hello sherms
<\sh> maco: looks like got some key warnings, too
<\sh> from our de.a.u.c mirrors
<maco> im using the gb mirror since the mini iso decided thats where it's going to default
<ion_> Heh, a hole in seccomp. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5b1017404aea6d2e552e991b3fd814d839e9cd67
<calc> Uploading openoffice.org_3.0.1-7ubuntu1  :-)
<seclm193> hey all
 * stgraber uploads one more LTSP, should be the last :)
<seclm193> i'm currious on helping with the ubuntu development
<calc> seclm193: http://www.ubuntu.com/community/participate gives an overview, or is there something specifically you would like to know about?
<seclm193> not really, this is my first opensource project, and i'm really feel like a newbie all over :(
<calc> seclm193: good luck, if you have any questions feel free to ask here or in #ubuntu-motu
<seclm193> ok, thank you
<tjaalton> kees: well neither of those are used on ubuntu, but maybe just add /var/cache
<tjaalton> kees: oh you fixed it already :)
<kees> tjaalton: yeah, I went and installed nscd to figure out where it was keeping stuff.  :)
<tjaalton> I'd still like to debug why some apps fail to create new files on NFS when protected by apparmor
<tjaalton> heh
<kees> yeah, NFS is a bit weird.  I use NFS for my home directory and it gets... confused.
<jdong> ouch really?
<tjaalton> anything to be done for jaunty?
<jdong> and I thought me with ecrypfs was unlucky enough
<tjaalton> because it's quite serious in our usecase
<bryce> slangasek, pitti: See what you think of (and ref'd linux-acpi thread) at http://cgit.freedesktop.org/xkeyboard-config/commit/?id=7b3bfb3ec4bd9bd57d7276e792f144e8f79d19ce and let me know whether or not you'd like me to pull that patch (I'm skipping for now)
<kees> Keybuk: what do you think of this for /lib/init/bootclean.sh?  http://pastebin.osuosl.org/24959   I had a giant /tmp and I had nothing in system start telling me what was taking so long...
<tjaalton> jdong: noticed that you published some apparmor profiles.. I've got one for acroread and opera, which work fine on a local $HOME but not on NFS. the acroread one is here http://users.tkk.fi/~tjaalton/foo/usr.bin.acroread
<jdong> tjaalton: awesomeness :)
<tjaalton> jdong: so if you have such a setup, could you try it out?
<tjaalton> to see it's not just our environment
<jdong> tjaalton: I will forward that to bodhi_zazen who is hosting the place, and yeah I'll play with that on my mini which has acroread
<jdong> tjaalton: so this breaks on NFS?
<tjaalton> jdong: cool, thanks
<tjaalton> jdong: yes, fails to start unless you've run it on complain mode first
<jdong> tjaalton: neat
<tjaalton> stracing reveals that it cannot create some file, when the profile does allow that
<jdong> tjaalton: nothing interesting in the audit logs?
<tjaalton> jdong: nothing that can be fixed :)
<jdong> :)
<tjaalton> you get: operation="inode_create" info="Failed nam
<tjaalton> e resolution - object not a valid entry" error=-2 requested_mask="a::" denied_mask="a::"
<jdong> yeesh
<sbeattie> is it getting lazily unmounted via automounter/autofs?
<tjaalton> jdong: looks like the acroread profile isn't complete, it'd like to poke ~/.fontconfig/
<tjaalton> sbeattie: no, in fstab
<tjaalton> the server is a netapp
<sbeattie> Hrm, curious. I can reproduce it locally if I umount -l the nfs mount, but that's not terribly surprising.
<wgrant> What is turning my active tab orange in an ugly fashion?
<wgrant> Ah, probably the new Murrine.
<mrooney> wgrant: :)
<dholbach> good morning
<maco> hello
<LordKow> moo
<YokoZar> Does this mean the germans are awake
<YokoZar> Or just dholbach
<Mithrandir> it's 0745 in CET now, so they should be waking up
<dholbach> YokoZar: funny you say that when didrocks turns up ;-)
<maco> so did something happen with the archive signing keys. a net install i was doing quit mid-way through saying the keys were bad
<maco> er, thats supposed to be a question
<siretart> kirkland: it seems that the screen-profiles-extra package is empty for me. I cannot imagine that's intended, is it?
<siretart> kirkland: and I really wonder where the installation commands for the screen-profiles-extras are. because there indeed seem to be profiles installed in the -extras package..
<slangasek> bryce: hmm, I'm inclined to say we should omit that patch for jaunty because I'm not sure it won't have knock-on effects
<soren> siretart: I thought you just said it was empty?
<bryce> slangasek: okie, I suspected so too
<bryce> heya tseliot
<siretart> soren: on my laptop, but obviously not in the ubuntu archive
<siretart> soren: I wonder what I'm doing wrong
<tseliot> hey bryce
<siretart> hi soren, btw :)
<ttx> slangasek: about the CIFS timeout at shutdown, I already asked Steve French (CIFS) to comment on that bug. If you read his comments, he doesn't ack it as a bug in CIFS. See https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631/comments/84 and https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631/comments/91
<ubottu> Ubuntu bug 211631 in wpasupplicant "Network is brought down before network filesystems are unmounted (CIFS timeout at shutdown)" [Medium,Confirmed]
<slangasek> ttx: ah; the fact that statfs has to query other bits would be a bug not specific to cifs, yes
<ttx> also apparently it bugs with NFS as well, see bug 113095
<ubottu> Launchpad bug 113095 in network-manager "nfs timeout on shutdown" [Undecided,In progress] https://launchpad.net/bugs/113095
<ttx> slangasek: or with openvpn, see bug 41794
<ubottu> Launchpad bug 41794 in openvpn "VPN tunnel is closed before network drives are unmounted when shutting down" [Medium,Confirmed] https://launchpad.net/bugs/41794
<slangasek> ttx: IME, shutting down NFS mounts when the network is absent works just fine
<slangasek> if we're going to generalize to things like openvpn, I think an if-down.d script is the only way to do it
<ttx> slangasek: yes, I have to look into how NM interacts with ifdown.d scripts though, istr it changed.
<doko> pitti, slangasek: any ideas why tk8.5 is not installable on some archs? https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.1-1ubuntu3/+build/910158
<NCommander> doko, its installable on ia64 ATM
 * NCommander just tried it
<doko> NCommander: hmm, ok, requeued, seems to be installable now
<NCommander> doko, any other architectures you'd like me to test?
<doko> NCommander: no, requeued for now
<pitti> Good morning
<pitti> YokoZar: keyring prompts> the discussion died upstream, and it sort of fell through the cracks
<pitti> doko: did the rebuild work?
<doko> pitti: still building, but it seems so
<dennda> Is there a list of mentors for ubuntu for GSoC 2009?
<cjwatson> maco: no, the Ubuntu archive key has never changed
<cjwatson> calc: ok, I hadn't finished with its build-dependencies so hopefully it worked ;-)
<cjwatson> calc: I'll check it once i386 is published so I have a basis for comparison
<doko> dennda: no, not yet
<dennda> doko: Ok, thanks.
<doko> dennda: subscribe to the soc ML mentioned on the ideas page
<Keybuk> kees: I think we should just make /tmp a tmpfs ;)
<cjwatson> seb128: is there a gtk+2.0 upload in the works? it's next on my list for lpia shlibdep-fix rebuilds
<seb128> cjwatson: no
<cjwatson> ok, cool
<seb128> cjwatson: when did the bug stopped? ie do you have the whole GNOME to reupload?
<PecisDarbs> is tracker disabled/not installed by default in Jaunty?
<pitti> PecisDarbs: the latter
<PecisDarbs> pitti: design decision I suppose?
<pitti> yes
<PecisDarbs> allright
<pitti> it's just too much of a resource hog by default, especially since many people don't use it at all
<PecisDarbs> yes, I agree
<pitti> it remains in main, though, so you are welcome to install and use it
<PecisDarbs> I do already
<PecisDarbs> it is very usable for my document mess :)
<cjwatson> seb128: 11th to the 16th
<cjwatson> seb128:
<cjwatson> http://people.ubuntu.com/~cjwatson/lpia-rebuilds-20090319
<cjwatson> seb128: so not all, but some - if you have anything there that you need to rebuild anyway, let me know
<cjwatson> seb128: I'm not so worried about applications, but I want to get the misbuilt libraries the hell out of the archive quickly :-)
<cjwatson> asac: speaking of which, network-manager was one of the ones misbuilt on lpia. Are you planning an upload for it soonish? (not quite yet though)
<asac> cjwatson: do we need a respin for lpia? if so i will upload something tomorrow
<asac> or even later today
<seb128> cjwatson: well, we will get GNOME 2.26.1 before jaunty, not sure how much you are in a hurry to fix everything
<seb128> cjwatson: I don't plan to rebuild a lot now before beta though
<asac> cjwatson: just tell me when we are ready to rebuild
<pitti> wow, reading -changes@, lots of goodness went in yesterday \o/
<cjwatson> seb128: misbuilt libraries scare me, so any misbuilt libraries I want to fix ASAP
<seb128> cjwatson: I will upload rhythmbox now so you can cross it on your list, dunno if you keep count of everything
<cjwatson> seb128: (${shlibs:Depends} was expanded to nothing, so it's entirely possible that configure could misdetect things from dependencies)
<cjwatson> seb128: I'm keeping count, can you push it to a bit later today though?
<cjwatson> seb128: it would be nice for the fixed gtk to build first
<seb128> cjwatson: it's a new version and I want it in before the freeze which should be in 30 minutes from what slangasek said yesterday ;-)
<cjwatson> ok, maybe I'll score it down
<seb128> well I guess slangasek will not be up before some hours
<seb128> I will upload after lunch
<cjwatson> not sure I'll be able to do that before it starts building
<seb128> we really need bin-NMU support in soyuz
<pitti> cjwatson: since you did a nice mini-rebuild-test, was there any FTBFS fallout you need help with?
<cjwatson> pitti: flagged as FTBFS in http://people.ubuntu.com/~cjwatson/lpia-rebuilds-20090319
<cjwatson> two due to distutils --install-layout and --prefix no longer being compatible, and one other python one that I don't understand
<pitti> ok, thanks; none of these seem urgent to me right now; I keep the page open, and can help out with those during the beta freeze
<MacSlow> pitti, within the next 30 min. or so you'll get a new notify-osd release (0.9.6)
<cjwatson> phew, gtk built in time for this publisher run anyway
<cjwatson> [on lpia]
<apw> did we just get new backgrounds?
<cjwatson> openldap might not make it though
<tjaalton> hum, shouldn't the failsafe-mode be password protected if root password is set?
<pitti> MacSlow: understood
<seb128> pitti: did you look at the merge request from ted for the message-packaging and evolution-indicator yet?
<pitti> seb128: no, I can do that now
<pitti> seb128: hm, just rebooted after dist-upgrade, and now the ssh agent seems broken
<tjaalton> which package/script is responsible for the recovery menu?
<seb128> pitti: thanks! I'm slightly busy with other things but I can do notify-osd after lunch in exchange ;-)
<pitti> tjaalton: friendly-recovery
<seb128> pitti: gnome-keyring didn't change since monday, did you reboot since?
<tjaalton> pitti: thanks
<pitti> seb128: that's fine, I can do them, too
<pitti> seb128: rebooting every day
<pitti> seb128: I just did a suspend/resume, for testing whether the X hang is fixed with the new -intel driver
<seb128> pitti: dunno then, maybe the agent crashed?
<pitti> /usr/bin/ssh-agent is running
<tjaalton> pitti: isn't it a toolchain problem?
<seb128> what about gnome-keyring-daemon?
<pitti> seb128: ah, that's it
<pitti> seb128: I think I crashed it when setting up my 3G connection
<seb128> pitti: ok, get me a stracktrace making sure there is no dump of your ssh key ;-)
<pitti> will figure this out later
<seb128> ok
<pitti> asac: is network-manager intended to tear down my 3G connection when I just log out and back in?
<pitti> (i. e. nm-applet restarts)
<asac> pitti: unless you use a system connection yes.
<pitti> asac: ah, if I tag it "make available for all users", it won't?
<asac> user connections die when applet (or user settings seervice to be exact) goes away
<asac> pitti: yes. thats the idea
<pitti> asac: ah, thanks
<pitti> asac: I did that now; It tore down the connection again, but I'll see how it behaves now :)
<pitti> asac: where does it store system-wide connections, btw? (I saw policykit coming up)
<asac> pitti: /etc/NetworkManager/system-connections/
<asac> its a glib keyfile for each connection
<pitti> ah, I see; thanks!
<asac> pitti: do you hav eissues with the prober?
<asac> pitti: like you see two or three modem entries?
<asac> or re-plugging the device will leave a zombie device in your applet?
<pitti> asac: I see two after suspend/resume, or after pulling it out and plugging it in
<pitti> but that was like that in intrepid as well
<asac> pitti: did you have the duplication for replugging in intrepid or only for resume?
<pitti> asac: also for replugging, I think
<pitti> asac: it also times out a lot for me now
<pitti> I repeatedly had to delete the connection, shut down nm/hal/nm-applet, replug, start up everything again and then enter the pin
<asac> pitti: is that when you have duplicated devices?
<pitti> I'll file a more detailled bug later
<asac> ok thanks
<pitti> today is beta rush
<asac> true
<pitti> asac: I didn't do a lot of debugging right now, I just wanted to get online (main internet is still broken)
<asac> pitti: thats ok ;)
 * pitti hugs asac
<asac> just wanted a confirm that you see it
 * asac hugs pitti 
 * ogra wonders why the gksu window is so dark under compiz ... feels totally out of theme
<ogra> MacSlow, ^^^ is that on purpose ?
<wgrant> ogra: I feel the same about the new session termination dialogs.
<wgrant> They seem to be the same style - it's not used outside there and gksu, AFAICT.
<ogra> hmm, i didnt keep them long enough in my face yet
<ogra> just clicked through quickly ...
<ogra> but you are right
<ogra> looks odd
<ogra> like the brushed metal theme
<wgrant> Yes. Somebody brought these strange translucent dialogs out of nowhere.
<wgrant> I thought it was a Windows thing to make applications disregard the system widget libraries.
<directhex> apple is worst for it ime
<MacSlow> ogra, yes and no ... you're running under compiz (or metacity+compositor), right?
<ogra> well, i'm fine with the widget look, its just the color that totally doesnt fit the rest of the theming
<ogra> MacSlow, compiz since yesterday again
<ogra> my X crashed to often to actually use compiz, i'm just giving it a try again
<ogra> under metacity without composite it did fir the theme
<ogra> *fit
<MacSlow> ogra, there the drop-shadow of the window shows through ... I've not been able to update the patch against libgksu to use the better shadow-rendering I now use in notify-osd
<ogra> ah
<wgrant> Can we convince Nautilus to not fade the desktop background?
<ogra> ok, understood ... how about making them rounded but non-transparent ?
<MacSlow> ogra, it should look like the notify-osd bubble (but using the theme-bg color)
<ogra> (on transparent seems easier than hacking out the shadow)
<apw> i just did an update and for the shortest time i had 60 second timeout boxes on my logout, restart and shutdown buttons on the userswitcher
<MacSlow> ogra, I like that ... for these kinds of "windows"
<apw> and now they have gone away again ... but i still have the ... at the end of the names
<apw> i assume i should have them always, if so what bit is broken
<ogra> MacSlow, well, they are modal to the whole desktop anyway ...
<wgrant> apw: I updated 15 minutes ago and it still works for me.
<apw> hrm, i have never had them on any of my installs (3) and on one of the two i did today
<apw> they appeared and confused me
<apw> then i saw that the ...'s have appears on the two i have upgraded
<apw> but now the box has gone away again
<apw> i just get instant off
<wgrant> Hmmm.
<apw> which bit is respnosible for that, there are soooo many components
<apw> oh hrm, i now have one on logout, but not restart
<apw> this thing is taking drugs when i am out
 * amitk wonders why his Jaunty fonts become bigger when he right-clicks his way to "Change desktop background"
<Mithrandir> amitk: g-s-d starts up?
<amitk> yes
<amitk> Mithrandir: restarting X gets it back to being smaller again.
<amitk> 96 dpi...hmm
<seb128> do you have g-s-d running at session start?
<amitk> seb128: I think so ->
<amitk> amit      4285  0.3  0.2  29428  9180 ?        Ssl  13:39   0:00 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
<seb128> dunno then
<seb128> cjwatson: ok, I've gdm and rhythmbox updates waiting let me know when I can upload
<ogra> grrr
<ogra> seb128, after each upgrade the indicator applet comes back in my panel even though i deliberately removed it
<seb128> ogra: why do you remove it? ;-)
<ogra> because i started using my own mail notification again after the one we have is so broken
<ogra> so i dont want that constant mail icon that forces me to use a submenu to open evo if there is new mail
<seb128> ogra: gconftool-2 --get /apps/panel/need_add_indicator_applet
 * wgrant points out that indicator-applet's button outline isn't visible at all in New Wave.
<ogra> seb128, its off
<seb128> DOH
<ogra> but i just remved the applet
<ogra> not sure what it was when i started the session
<seb128> mvo: you don't use the gconf key in your migration code, you only set it but don't read it before
<seb128> ogra: obviously bug, I will sort that with mvo when he's back from lunch
<ogra> oki
 * ogra would just prefer the mail notification to work right ...
<seb128> what do you expect from it?
<ogra> it took so many years for the builtin evo one to DTRT
<ogra> to work like the one thats in evo now
<seb128> which means?
<seb128> I dislike the flashing icon
<ogra> only show an icon if there is new mail
<seb128> the message indicator is not evolution specific
<ogra> else i would use the mail-notification applet
<seb128> it lists pidgin too
<seb128> and other softwares which will use it later
<ogra> i dont use pidgin
<seb128> you have an IRC client right?
<ogra> i liked the evo icon before, i agree the flashing could have been opmitted
<seb128> whenever it start using it you will get the IRC pings listed in the indicator
<ogra> xchat
<ogra> what annoys me most about the evo icon is that it enforces that silly submenu
<ogra> and only duplicated the taskbar
<mvo> seb128: the xdg startup deskto pfile thing reads it
<seb128> mvo: oh right!
<seb128> doh, I'm stupid, I even made sure it worked for me yesterday, him
<seb128> hum
<seb128> ogra: do you use gnome-session?
<ogra> seb128, what else should i use, indeed
<seb128> ogra: dunno if you are on some special mobile or arm config
<ogra> no, its my laptop
<seb128> grep GNOME /etc/xdg/autostart/indicator-applet.desktop?
<ogra> ogra@osiris:~$ grep GNOME /etc/xdg/autostart/indicator-applet.desktop
<ogra> OnlyShowIn=GNOME;
<ogra> AutostartCondition=GNOME /apps/panel/need_add_indicator_applet
<seb128> ok, so there is the autostart condition and the key is set to false
<seb128> weird
<ogra> a i said, i dont know what the key had whne i started the session
<seb128> well nothing will change it to true if that's not you
<ogra> i removed the applet before you told me to look at the key
<seb128> the applet has nothing to do with this key
<ogra> but removing it might change it to false
<ogra> ah
<seb128> it's true by default and see to false when the migration code is run
<seb128> see -> set
<seb128> ie once
<seb128> then the code should never be run again
<seb128> if you want to debug it run a non gnome session
<seb128> run gnome-session --debug &>log
<seb128> and copy the log somewhere or grep for indicator
<seb128> to see if the migration code get ran
<mvo> ogra: when you login again, do you see add-indicator-applet.py message in your .xsession-errors log?
<ogra> seb128, will do, i have mobile meeting now, so you need to wait a bit :)
<seb128> ok
<seb128> brb testing the new gdm version
<mvo> sebner: did you see any other complains/reports yet ?
<mvo> smb_tp: re bug #341334  - so you can still reproduce this or is that only reproducable on a fresh jaunty kubuntu install?
<ubottu> Launchpad bug 341334 in python-apt "python2.6 crashed with SystemError in markInstall()" [Undecided,New] https://launchpad.net/bugs/341334
<ogra> asac, ugh, my url bar font in FF is totally screwed up since the last upgrade
<ogra> err, hmm, changing focus to another window and changin it back fixed it
<ogra> but it was swallowing half the letters
<cjwatson> seb128: gdm is ok to go, but rhythmbox isn't yet
<asac> ogra: ffox 3.0 or 3.1?
<ogra> current jaunty, no idea
 * ogra checks
<ogra> 3.0.7
<asac> ogra: if you have official logo its 3.0 ;)
<asac> yeah
<asac> ogra: my guess is that firefox needed a relayout after fontconfig/gconf changed under the hood
<ogra> ah
<ogra> well, i cant reproduce it
<asac> ogra: you can downgrade and upgrade again ;); but i guess we have more important things todo ;)
<ogra> yeah
<cjwatson> seb128: rhythmbox has a bit of a stack involved, unfortunately - looking at it
<cjwatson> bluez -> pulseaudio -> gnome-media -> rhythmbox
 * pitti hugs james_w for bzr bd awesomeness
<pitti> james_w: doing "bzr merge" and "bzr bd -S" for a sponsoring request makes things too easy! :-)
<liw> if I see a bug that is clearly marked for the wrong package, I should fix that in launchpad, right?
<seb128> liw: yes, where else do you want to fix it?
<liw> the alternative was asking someone else to fix it
<liw> (launchpad still scares me)
<seb128> don't be scare just change it ;-)
<seb128> scared
<seb128> launchpad is nice once you are used to it ;-)
<elmo> woah
<ogra> if not you are allowed to poke it with a stick :)
<Scix> pitti: When i call "jockey-gtk -e kmod:wl" from a bash script called by rc.local, the drivers doesn't get enabled. If i call this script manually it works. Do you have any idea about why this doesn't work?
<pitti> Scix: I guess it has problems with not opening $DISPLAY
<pitti> Scix: it's not a full blown CLI frontend yet, I'm afraid
<Scix> pitti: I see. Then i have to find another solution to it. I have 20 laptops that uses this driver, and it has to be installed automagicly. Tanks for quic help :)
<pitti> Scix: I can probably toss you a 3-line python script which does that
<pitti> Scix: just busy ATM, I'll get back to you in a bit
<Scix> pitti: tank you. That whould be lovely :)
<danbhfive_jaunt1> #ubuntu-xorg
<rtg> Keybuk: re: module-init-tools. Once I've done a debcheckout and 'bzr commit', how do I then push it? The bzr URL is http.
<Keybuk> checkout with lp
<Keybuk> there's probably some way to tell debcheckout that
<cjwatson> debcheckout -a
<cjwatson> otherwise, 'bzr push --remember lp:~ubuntu-core-dev/module-init-tools/ubuntu'
<Keybuk> does debcheckout do a checkout or a branch?
<cjwatson> assuming you've done 'bzr launchpad-login'
<cjwatson> branch, oddly
<cjwatson> that might be my fault
<rtg> I think I'm just gonna stick to kernel packages in the future and make you guys do all the changes.
<KaiL> does udev really need to wait until readahead it ready loading everything?
<Keybuk> KaiL: ?
<cjwatson> KaiL: it's faster to let readahead get on with it in one go, rather than interrupting its steady I/O
<KaiL> ah
<Keybuk> indeed, I posted a message on this very subject to ubuntu-devel barely days ago
<KaiL> only saw that in my bootchart ;)
<smb_tp> mvo, That seems to happen only on fresh system runs.
<rtg> Keybuk: please check that I haven't borked module-init-tools, Pushed up to revision 135
<Keybuk> rtg: looks fine thanks
<rtg> Keybuk: thanks. I'll try to remember in the future to look for vcs line in control.
<smb_tp> mvo, Hm, and (just verified that) after creating a new user and logging in first time. There is this window "starting akonadi server" which seems to vanish a bit quickly. A little later the crash is picked up
<ion_> The new backgrounds are nice, but isnât the default one simpler than the âSimpleâ one? :-)
<mvo> smb_tp: thanks, I will try to reporduce it here
<radix> pitti: Hi pitti, I'd like to point out the last comment in bug #343954
<mvo> smb_tp: could you please pastebin the output of ls /var/lib/apt/lists ?
<ubottu> Launchpad bug 343954 in landscape-client "Update landscape-client to 1.0.28" [Undecided,Confirmed] https://launchpad.net/bugs/343954
<radix> oops, he's busy
<mvo> smb_tp: I do not have a kubuntu CD yet, so I can not easily reproduce it (downloading now)
<smb_tp> mvo, sure just a sec
<pitti> radix: just saw and replied
 * pitti -> lunch, bbl
<radix> pitti: thanks
<smb_tp> mvo, https://pastebin.canonical.com/15171/
<cjwatson> wtf, nmap runs configure on clean
<cjwatson> lamont: ^- madness
<ogra> cjwatson, ...
<ogra> <ogra> TOTAL_RAM=$( grep MemTotal /proc/meminfo |tr -d ': [A-Z][a-z]')
<ogra> <ogra> # Do not use compcache on the liveCD if we have more than 512M
<ogra> <ogra> if [ "${BOOT}" = "casper" ]; then
<ogra> <ogra>     if [ "${TOTAL_RAM}" -gt 524288 ]; then
 * asac off for testing nm 
<ogra> but on the babbage i have:
<ogra> (initramfs) cat /proc/meminfo
<ogra> MemTotal:         482808 kB
<lamont> cjwatson: yeah, it does that
<ogra> cjwatson, any objections that i lower the default a little bit ? else i end up with compcache enabled on a babbage boot by default
<lamont> something to do with lack of a makefile for doing distclean at
<apw> anyone remind me the name of the release notes package?
<Hobbsee> apw: ubuntu-release-notes?
<apw> Hobbsee, erms doesn't seem to be
<mvo> smb_tp: could you please run http://paste.ubuntu.com/133644/ and let me know if that gives you more debug output
<Hobbsee> apw: hrm.  No, it really seems that it is - I believe https://bugs.edge.launchpad.net/ubuntu-release-notes is what you're after?
<apw> yeah its not a package it seems but something else under the first button
<apw> wibble
<cjwatson> lamont: so if there's no makefile, don't bother calling distclean. :-)
<smb_tp> mvo, just a sec
<cjwatson> ogra: I don't mind
<ogra> good
<lamont> cjwatson: ah.  maybe
<ogra> though i wonder why it was enabled first place, i didnt boot with boot=casper
<lamont> it's not alone in the insanity
<ogra> hrm
<cjwatson> [ ! -f Makefile ] || $(MAKE) distclean is a pretty common idiom
<Keybuk> I just do -$(MAKE) distclean
<robbiew> i just do rm -rf :P
<robbiew> j/k
<cjwatson> Keybuk: lintian warns about that now, because it ignores all errors rather than just the one that should be ignored
<cjwatson> obviously in some cases it doesn't matter
<ion_> Cool, xserver-xorg-video-savage 1:2.2.1-4ubuntu1 fixed a problem i never got around to investigating: OpenGL apps used to hang the system after suspend.
<cjwatson> asac: could you upload network-manager when you have a moment? gnome-keyring is done now
<seb128> cjwatson: still something blocking rhythmbox?
<ni|> anyone good with init scripts in here?
<doko> cjwatson: your lpia list: python3.0, python-tcpwrap, python-pysqlite1.1, cx-bsdiff fixed, will address the other py* packages after the last python2.6 upload is built
<cjwatson> seb128: just uploaded pulseaudio, after that needs gnome-media
<cjwatson> doko: thanks, noted
<calc> cjwatson: ok
<ni|> http://www.pastie.org/private/wuleto3riecw8bkelthva
<ni|> i can't even get to the usage aspect
<ni|> i'm a cpp programmer not really good with bash
<asac> cjwatson: yes. looking now
<smb_tp> mvo, got a bit sidetracked, sorry. actually I just upgraded the whole system to latest level (it got a bit neglected since iso testing) and I am not sure this still happens
<cjwatson> doko: not seeing your python-pysqlite1.1 upload?
<doko> cjwatson: was just a give back
<cjwatson> ah
<mvo> smb_tp: ok, thanks. when my daily image is there, I see if I can still reproduce it
<smb_tp> mvo, probably I should retry with that as well
<mathiaz> does a binary package move to main require a full MIR? (in this case bacula is already in main, but we'd like to move some of the binary packages to main)
<cjwatson> mathiaz: no, not if the source is already in main
<cjwatson> any archive admin can do that on request
<cjwatson> blink, I'm sure http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt ought not to be empty!
<mathiaz> cjwatson: great thanks.
<cjwatson> oh, I just caught it at a bad time
<cjwatson> doko: nmap FTBFS, I think the same thing as the others
<doko> cjwatson: yes, will give back after python2.6 is built. the check was too strict
<cjwatson> ok
<ni|> where is asio for boost
<ni|> for god sakes
<ni|> i installed libasio
<ni|> -dev
<smb_tp> mvo, That machine is still behaving a little strange (at least it looks to me). I got one jockey crash report (only the file) after logout and now it seems logging out and in, that special Desktop widget does not come up any more... I do a reboot and see what is happening
<mathiaz> nijaba: how does the supported for 3 vs 5 years system works with the seeds?
<mathiaz> nijaba: ie where should I put packages supported for 5 years in the seeds (for jaunty+)?
<nijaba> mathiaz: let me refresh my mind.  would help to know what packages you are talking about
<mathiaz> nijaba: ok - I've just added the bacula-directory-sqlite3 package to the dvd seed.
<mathiaz> nijaba: does it mean that bacula-director-sqlite3 will be supported for 5 years?
<nijaba> mathiaz: nope, you need to add it to one of the server specific seeds
<ni|> so nobody uses boost for programming in here?
<seb128> Keybuk: did you have any number on how login time the nautilus animation takes?
<mathiaz> nijaba: server specific seeds =? the ones that are on the -server iso?
<cjwatson> ni|: see the "not app development on Ubuntu" bit in the topic
<cjwatson> ni|: this channel is for the development of Ubuntu itself, I'm afraid
<nijaba> mathiaz: a good way to get a clear vision is to make a jpg from the .dot file that is generated by germinator
<nijaba> mathiaz: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/structure.dot
<ni|> cjwatson: apologies
<ni|> cjwatson: any suggestion then for how to find a boost package
<asac> ok i think i am done for pre beta
<ni|> i've done apt-cache
<mvo> smb_tp: seems to be fine on hte live cd, I will add a bit more robustness to install-package nevertheless
<ni|> i'm a bsd programmer playing with linux at work
<mathiaz> nijaba: how do I generate a jpg file from the dot file?
<nijaba> mathiaz: using the 'dot' command
<smb_tp> mvo, those initial crash reports seem to be gone now. But it seems the same applies to that widget. On first login it is there, all later logins it is gone.
<ArneGoetje> slangasek: when do you want to have new base language-packs? And when the final ones?
<nijaba> mathiaz: dot structure.dot -Tjpeg > structure.dot.jpg
<nijaba> mathiaz: pick the most appropriate seed that you see pointing to supported-server
<mathiaz> nijaba: excellent - thank you
<mathiaz> nijaba: so 5 years == supported-server while 3 years == supported-desktop only?
<nijaba> mathiaz: correct + server-ship
<nijaba> mathiaz: the rule is: everything that is shipped on cd + whatever is in support-server
<mathiaz> nijaba: ^^ supported for 5 years - the rest is 3 years only
<cjwatson> ni|: seems to be in libboost1.35-dev in 8.10 or newer
<nijaba> mathiaz: supported-desktop + whatever is on the desktop cd yes
<cjwatson> ni|: please move further questions to another channel, though
<mathiaz> nijaba: is there a script/place to look for the supported time for a specific package?
<nijaba> mathiaz: but for example, you do have kde package in the seeds, which for 8.04 were only supported as a normal release
<nijaba> (18mo)
<nijaba> mathiaz: yes, I wrote such a thing
<mathiaz> nijaba: ah oh.. this starts to be complicated.
<mathiaz> nijaba: there are some packages that are only in the dvd seed
<mathiaz> nijaba: for how long are these supported?
<ni|> cjwatson: thanks
<nijaba> mathiaz: https://code.launchpad.net/ubuntu-maintenance-check
<mathiaz> nijaba: example: exim4
<nijaba> mathiaz: dvd seed only == normal maintenance period (18mo)
<ivoks> this should be much easier
<ivoks> if devs don't understand it, how will users be able to do that?
<nijaba> mathiaz: there might be mistakes though, and should be signaled as such
<ivoks> kiss
<nijaba> ivoks: did you try https://code.launchpad.net/ubuntu-maintenance-check ?  this is the user interface
<ivoks> i haven't yet
<asac> cjwatson: so nm is up and building for a while now.
<nijaba> ivoks: and I did not decide of the seed structure, I just sorted things a bit so that we the above script could produce something intelligible ;)
<ivoks> nijaba: i wasn
<ivoks> nijaba: i wasn't accusing anyone, i'm just thinking that this should be much easier
<nijaba> ivoks: I did not felt accused, so no issue here.  I am sure any good proposal would be gladly accepted :)
<ivoks> tag in binary package
<ivoks> we have 'Maintainer'
<ivoks> it shouldn't be hard to add 'Supported-for' and 'Supported-by'
<nijaba> mvo had in project to use the output of Ubuntu-maintence-check to tag the package in Synaptic I think.  Do not know if he ever got to it, though
<cjwatson> ivoks: this is one of the many things we're trying to do as part of ArchiveReorganisation
<cjwatson> (too many, perhaps)
<cjwatson> asac: thanks
<ivoks> cjwatson: and i support that project - i think it would be great to have per-package ACL
<cjwatson> that's the permissions side of it, which we're now treating separately from things like exposing supportedness information
<ivoks> i know
<mvo> Riddell: I uploaded a new install-package and put the bzr tree into a shared location (~ubuntu-core-dev) hope thats ok with you
<nixternal> seb128: thanks for removing me from that Evolution bug...why I was even assigned to it is beyond me
<seb128> you're welcome, you can unassign yourself though next time if you want
<nixternal> didn't even know I was assigned :)
<tkamppeter> slangasek, I want to fix bug 338442 for HPLIP before Beta freeze. Usually, I always upload the current state of the Debian SVN (using an XubuntuY version number if I did the last change). Now your changes on SVN are in release 3 but your Ubunru package is 1ubuntu3 which does not appear in the SVN. Are there any reasons why you exclude Marc Purcells bug fixes in release 2 and 3?
<ubottu> Launchpad bug 338442 in system-config-printer "bug reports would benefit from an apport hook" [Medium,Fix released] https://launchpad.net/bugs/338442
<Riddell> mvo: oh?  what's new?
<mvo> Riddell: just a little bit of robustness against the apt resolver falling over
<mathiaz> nijaba: I'm reviewing the dvd seeds and have some suggestions - should I just send them to the ubuntu-server mailing list?
<mathiaz> nijaba: suggestions about moving some packages from the dvd seed to supported-misc-servers (thus changing their support period)
<nijaba> mathiaz: are they mistakes or just suggestions?  if the later, then the mailing list is appropriate, I think
<mathiaz> nijaba: some are mistakes but I've already fixed them (ex: libvirt-bin was both in dvd and server-ship)
<nijaba> mathiaz: if they are mistakes, then fix them (ie exim should be in it already)
<wasabi> woh. not good.
<wasabi> i just had lvm destroy a lv during a pvmove
<mathiaz> nijaba: most of them are suggestions (like exim -> supported, and bunch of others)
<JontheEchidna> mvo: I have a patch for some enhancements for the KDE software-properties frontend
<nijaba> mathiaz: exim should already be supported, AFAIK, so I would consider this a mistake
<mathiaz> nijaba: ok. Other question (you may already have answered it though).
<mathiaz> nijaba: packages only in dvd are supported for 3 years for LTS?
<JontheEchidna> mvo: It's mainly more KDE integration plus one or two more small items
<mvo> JontheEchidna: if you give me the bzr branch / uri I can have a look
<JontheEchidna> ok
<nijaba> mathiaz: not AFAIK, they should be considered 18mo, unless in desktop/supported-desktop -> 3y or server-ship/supported-server -> 5y
<mathiaz> nijaba: ok - so for LTS there are actually *3* different periods of support
<nijaba> mathiaz: yes
<nijaba> mathiaz: even 4, if you consider universe
<mathiaz> nijaba: right - by support I meant what's is looked after by the Ubuntu Security team in main
<nijaba> mathiaz: which should, IMHO, be called maintenance, but that is another story
<mathiaz> nijaba: agreed.
<nijaba> mathiaz: oops, mistake in my above statement:  3y support depends on a packages being in ship or suported-desktop.  My reference is lines 287-288 of my maintenance-check script
<mathiaz> nijaba: http://paste.ubuntu.com/133720/
<mathiaz> nijaba: ^^ this is my suggestion for packages to be moved from dvd to supported-misc-servers
<nijaba> mathiaz: these are not suggestions, but mistakes, as most should already be maintained for 5y
<mathiaz> nijaba: ok - I'll commit the changes then :)
<nijaba> mathiaz: bacula, exim, freeradius, rddtool were all part of our review during hardy UDS in boston, IIRC
<nijaba> mathiaz: I think we should have a page on wiki.ubuntu.com summarizing all we just exchanged, don't you?
<mathiaz> nijaba:  I can send an email to ubuntu-server@
<mathiaz> nijaba: the wiki page seems redundant with the bzr history.
<JontheEchidna> mvo: https://code.edge.launchpad.net/~echidnaman/software-properties/pykde4
<nijaba> mathiaz: the email would not hurt, but the wiki was more to answer questions about seeds, duration, dot files, etc..
<mathiaz> nijaba: ah right. I think there is already a similar wiki page.
<nijaba> mathiaz: then it should be updated, do you know were it is?
<mathiaz> nijaba: https://wiki.ubuntu.com/SeedManagement
<nijaba> mathiaz: great.  I'll update it a bit then, hoping that archive admin are subscribe to it so that they can verify what I will be adding
<mvo> JontheEchidna: looks good to me, but I'm no pyqt wizard - if Riddell is ok with it at this point (relatively close to beta), I'm happy to sponsor it
<JontheEchidna> Riddell: https://code.edge.launchpad.net/~echidnaman/software-properties/pykde4
<LaserJock> mvo: ping
<mvo> LaserJock: pong
<ion_> The documentation for admins mentions /srv/launchpad.net. Just out of curiosity, which network filesystem do you (Canonical) use there?
<mathiaz> nijaba: should sqlite3 be also moved to a 5 year support?
<LaserJock> mvo: I'm trying to use the new g-a-i flag but some .desktop files make g-a-i crash
<mathiaz> nijaba: I think the libraries are probably supported for 5 years as a dependency for a bunch of packages.
<LaserJock> mvo: what's a good way to debug?
<nijaba> mathiaz: the library are for sure, yes and it does not make sense to not include the rest.
<Riddell> JontheEchidna, mvo: go for it
<LaserJock> slangasek: would you happen to have any room on the CD for a 32K .deb?
<cjwatson> ion_: it's not a network filesystem
<ion_> cjwatson: Ah, ok
<mvo> LaserJock: what is the backtrace?
<cjwatson> just a local filesystem that serves the launchpad.net service
<ion_> Yeah, i see
<LaserJock> mvo: is a bt from gdb python good enough?
<bluefoxicy>  7443 bluefox   20   0 1407m 671m  26m S    0 18.1  35:53.76 nautilus
<bluefoxicy> Mem:   3797500k total,  3627972k used,   169528k free,    12860k buffers
<bluefoxicy> Swap:   787072k total,   773852k used,    13220k free,   576452k cached
 * bluefoxicy killall nautilus.
<mathiaz> nijaba: done - sqlite3 moved from the dvd seed to the supported-sysadmin-common seed.
<LaserJock> mvo: http://paste.ubuntu.com/133734/
<bluefoxicy> Mem:   3797500k total,  3162160k used,   635340k free,    14040k buffers
<bluefoxicy> Swap:   787072k total,   591016k used,   196056k free,   641136k cached
<bluefoxicy> 12800 bluefox   20   0  597m 142m  19m S    0  3.8   0:03.06 nautilus
<bluefoxicy> wow, it starts up hot needing 142megs of RAM... ubuntu system requirements++  O_O
<LaserJock> mvo: it works fine until I click on the Education menu then it pegs the CPU. I removed some of the new .desktop files and it then worked
<mathiaz> nijaba: The last item left in the dvd seed I'm not sure about is system-config-cluster
<LaserJock> mvo: but I don't see any real difference between the .desktop files that worked and those that didn't
<nijaba> mathiaz: it is definitely maintained as part of the RH cluster suite
<mvo> LaserJock: is this a slow system?
<mathiaz> nijaba: redhat-cluster-suite is on the cd
<mathiaz> nijaba: the *server* cd
<nijaba> mathiaz: but the config tool is not?
<mathiaz> nijaba: nope - it's on the dvd
<LaserJock> mvo: no, but I tried it in a Jaunty VM which would kinda slow and it did it as well
<mathiaz> nijaba: note that it will all the X stuff with it.
<mathiaz> nijaba: note that it will *pull* all the X stuff with it.
<LaserJock> mvo: totally I had 6 .desktop files floating. Do you think it's a matter of overloading the sorting function?
<nijaba> mathiaz: eheh, that's why...
<nijaba> mathiaz: I thought it was a CLI
<mathiaz> nijaba: should I leave it in dvd or move it to a supported desktop seed?
<nijaba> mathiaz: supported-sysadmin-desktop woudl make sense
 * mathiaz nods
<mvo> LaserJock: oh, might be a bug in the sorting code with multiple floating ones
<seb128> Keybuk: hey
<seb128> Keybuk: did you see my question about the nautilus login speed difference before?
<seb128> I see that you have uploaded nautilus now ;-)
<seb128> upstream seems to not really with the change though ...
<mathiaz> nijaba: allright - I don't see anything else relevant to the server team in the dvd seed.
<LaserJock> mvo: I'll play with various combinations to see if it's specific to a .desktop or just number specific
<cjwatson> is somebody sorting out the nautilus-cd-burner vs. brasero conflict?
<mathiaz> nijaba: I'll send an email to ubuntu-server@ to summarize the changes I made
<seb128> cjwatson: there is nothing to sort?
<nijaba> mathiaz: it would also make sense to back push the changes to the previous versions of the seeds as well
<cjwatson> seb128: clearly not true since livefses are failing to build
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/ubuntu/20090319/livecd-20090319-amd64.out
<seb128> cjwatson: how come? I though we deprecated n-c-b and dropped it to supported?
<cjwatson> seb128: nautilus recommends it, that could be it
<cjwatson> I haven't investigated
<seb128> cjwatson: ok, that's the issue then it's not meant to be installed
<seb128> cjwatson: or you get cd recording items duplicated in nautilus
<cjwatson> probably best to weaken that dependency in nautilus
<seb128> will do that
<cjwatson> ta
<cjwatson> seb128: gnome-media has built now, so rhythmbox will be good to go as of about 80 minutes from now
<cjwatson> seb128: sorry about the annoying delays
<seb128> cjwatson: thanks
<mvo> LaserJock: could you please try the following patch: http://paste.ubuntu.com/133746/http://paste.ubuntu.com/133746/http://paste.ubuntu.com/133746/
<mvo> LaserJock: http://paste.ubuntu.com/133746/
<seb128> that's not your fault and there is no issue ;-)
<Keybuk> seb128: about 3-4s difference
<pitti> Riddell: kwwii mentioned that you have some trouble with a new usplash theme
<LaserJock> mvo: trying now
<pitti> Riddell: is that with the one in jaunty, or one in some bzr branch?
<calc> anyone know how to do a secure erase (ata) under linux?
<calc> eg the built in disk feature
<pitti> calc: wow, that exists?
<Keybuk> seb128: gnome-panel is of the same order
<pitti> calc: my kneejerk response would have been "a 1000 degrees oven"
<LaserJock> mvo: \o/  that did it
<cjwatson> seb128: BTW sorry in advance if I've missed any desktop packages maintained in bzr - I think I've made bzr commits where appropriate but it's possible that I missed the odd one
<seb128> Keybuk: what sort of config do you have? that seems really a lot for something which should just be using cpu where the hang on io usually
<calc> pitti: yea many drives have a built in secure erase feature, but i don't know how to issue the command under linux
<mvo> LaserJock: cool
<mvo> LaserJock: thanks for the quick test!
<ion_> pitti: Btw, is it expected for usplash to use 1280Ã1024 on a monitor with a native resolution of 1680Ã1050? The monitor is really to blame for screwing up the aspect ratio instead of showing the image centered or something, but would it be possible for usplash to use the native resolution?
<calc> ah hdparm --security-erase /dev/sd*
<Keybuk> seb128: Dell Mini 9
<Keybuk> seb128: the GNOME login is *extremely* CPU bound
<seb128> cjwatson: I will check but no problem don't worry
<Keybuk> nautilus alone consumes several seconds or 100% CPU initialising its modules
<calc> our manpage doesn't list the option so i'm not sure if its actually in it
<Keybuk> brasero seems a notable culprit
<Keybuk> meanwhile compiz is using a lot of CPU initialising
<calc> http://howflow.com/tricks/secure_erase_how_to_erase_a_hard_drive
<Keybuk> having two desktop components draw pointless little animations during that time, when they don't even reach the screen, costing 3-4s each is silly
<calc> "The advantage of this procedure is that it even overwrites bad blocks. âEnhancedâ means, that it overwrites the data with a random pattern."
<seb128> Keybuk:
<seb128> mars 19 15:51:02 <halfline>	this shouldn't be cpu intensive at all
<seb128> mars 19 15:51:08 <halfline>	we're doing the compositing server side
<seb128> mars 19 15:51:18 <halfline>	so this may be a NOTGNOME fix the driver type thing
<seb128> Keybuk: that's from the #nautilus discussion early today
<Keybuk> they're doing the compositing *before* compiz is started!
<Keybuk> that's the fundamental problem here
<pitti> calc: I like "wipe" for individual files, but so far I haven't heard about something to delete the reserved blocks; thanks for the link
<calc> pitti: ah it is in the manpage i just didn't search properly it seems
<Riddell> pitti: it's the Kubuntu one in jaunty
<calc> pitti: i've been getting weird messages from my drive so i am going to reinstall this weekend after writing to the whole drive and running smart long test
<nijaba> mathiaz: cjwatson: I've updated https://wiki.ubuntu.com/SeedManagement, review welcome
<Riddell> pitti: I can't test the ubuntu desktop one, the CDs didn't build
<pitti> Riddell: ok, I'll give that a whirl
<Keybuk> seb128: though you can see how badly this performs just in gnome itself
<Riddell> pitti: this is booting off the live CD, it may well work fine at other times
<Keybuk> change the background back and forth several times
<Keybuk> it takes seconds to even react after a while
<seb128> Keybuk: I've a less than 1 second cpu spike here and not user visible impact
<seb128> but can be config dependant
<Keybuk> seb128: on login?
<Keybuk> remember that resources are highly contended on login
<Keybuk> and one of the other things starting is the compositing window manager
<seb128> my login is IO bounded, no CPU bounded
<Keybuk> sending it 100s of full-screen textures with minor changes is not going to be a plan of awesome
<Keybuk> seb128: http://people.ubuntu.com/~scott/black-jaunty-20090310-4_cropped.png
<Keybuk> seb128: GNOME Login is very CPU bound if you take I/O out of the equation
<Keybuk> far more than the rest of the boot
<Keybuk> while your login might have high I/O, it turns out that it's not "all I/O"
<seb128> right, but I can't take IO out of the equation, I've a normal old slow disk ;-)
<Keybuk> but actually the GNOME login is vastly CPU bound *as well* :p
<seb128> anyway as said I don't really care either way
<seb128> upstream thinks the animation is slick and should not impact on cpu since it's mostly xorg work and will not likely drop it
<seb128> but I'm fine having the one liner as a distro change
<Keybuk> right
<Keybuk> I didn't disable the animation when changing the background image
<pitti> Riddell: oh, I see
<Keybuk> just on startup
<seb128> yeah
<Keybuk> there are far *better* ways we can be slick next release
<Keybuk> like panning/fading/zooming in the entire desktop when it's ready
<seb128> they are speaking about having gnome-bd doing performance's estimation to enable it or not ;-)
<Keybuk> I know, that's kinda silly
<seb128> gnome-bg
<Keybuk> the problem isn't that the machine isn't especially fast
<Keybuk> it's just that it's VERY busy
<Keybuk> at some point we should look into why nautilus takes *so long* to start
<Keybuk> it's weird
<Keybuk> it gets into the main loop very quickly
<Keybuk> and even has most things responsive
<Keybuk> but then spends another 7s or so working in the background
<Keybuk> note that on Ubuntu, nothing is shown on screen until gtk-window-decorator is actually running
<Keybuk> and by that point, everything is loaded
<calc> looks like most newer drives (past year or two) support security erase
<seb128> Keybuk: http://www.gnome.org/~federico/news-2006-03.html#08
<Keybuk> I'm counting the boot as 25s simply because gnome-panel and nautilus are busy
<Keybuk> otherwise it'd be 22, since that's when you can click on things
<seb128> Keybuk: that might be outdated though
<seb128> Keybuk: I blame gconf for a good part of it
<seb128> and bonobo
<Keybuk> seb128: yeah I saw
<pitti> Riddell: does it work for you on your installed system?
<Keybuk> I thought nautilus was de-bonobo'd ?
<seb128> Keybuk: it is but gconf isn't
<Keybuk> ah, right
<Keybuk> that graph matches my own rough notes too
<seb128> what is desrt doing, where is dconf ;-)
<seb128> Keybuk: "This is the time from calling gtk_main() until the desktop gets painted: an enormous 2.1 seconds. Why is there such a large gap between entering the main loop and actually loading/painting the desktop? The ~/Desktop in that account is empty (it's a test account with no data in the home directory apart from dotfiles). "
<seb128> Keybuk: yeah, he basically has the same remarks than you
<Riddell> pitti: not tried, let me try
<calc> hmm supposedly security erase has existed since ~ 2001 but i don't see it on my ~ 2 year old drive
<pitti> Riddell: I'll try here as soon as the current dist-upgrade from hell finishes
<Keybuk> seb128: did you see http://people.ubuntu.com/~scott/boot-performance/stig-20090208-0940.png ? :p
<mathiaz> nijaba: the project description of https://code.launchpad.net/ubuntu-maintenance-check states to not trust the output of the script
<mathiaz> nijaba: is this still a valid statement?
<mathiaz> nijaba: https://launchpad.net/ubuntu-maintenance-check
<seb128> Keybuk: xfce does nothing that's easy ;-)
<Keybuk> seb128: I dunno
<Keybuk> *their* session manager supports ... sessions
<nijaba> mathiaz: oversight, /me fixing it
<nijaba> mathiaz: done, thanks
<seb128> Keybuk: the jaunty gnome-session one too now ;-) (only on logout for now though)
<Riddell> pitti: works fine on my installed system
<pitti> Riddell: ok, then it doesn't seem to be an issue with the THEME_VERSION or so
<pitti> Riddell: I'll give it a shot here anyway and test it with 640x400 (which is what the live CD uses AFAIK)
<pitti> i. e. the default resolution if /etc/usplash.conf doesn't exist
 * pitti -> quick break
<slangasek> ArneGoetje: new base langpacks before beta seems like a good idea to me - so ASAP, I guess, given how long they take to export?
<seb128> hey slangasek
<slangasek> tkamppeter: because I was fixing a bug, not following the Debian SVN tree?
<slangasek> LaserJock: currently the alternate CDs are oversized, so... no.
<slangasek> seb128: hi :)
<LaserJock> slangasek: that's OK, I figured it out
<tkamppeter> slangasek, OK, I have brought HPLIP up-to-date again now with the SVN.
<tkamppeter> I get an FTBFS with gutenprint, probably due to packages missing on the server. It complains about
<tkamppeter> libgimp2.0-dev: Depends: libgtk2.0-dev (>= 2.10.0) but it is not going to be installed
<tkamppeter> libreadline5-dev: Depends: libreadline5 (= 5.2-4) but it is not going to be installed
<tkamppeter> It is on i386
<slangasek> ember: why did you add a Conflicts: with nautilus-cd-burner to brasero?
<slangasek> is there some reason they don't coexist?
<ember> they provide the same thing . i.e icons on nautilus
<LaserJock> they both add "burn to disk" menu items to the nautilus right-click menu
<slangasek> ember: "provide the same thing" is not the definition for conflicts, though
<seb128> slangasek: nautilus-cd-burner is not installed by default
<slangasek> and your added conflict is breaking the CD builds
<slangasek> seb128: yes, it is... nautilus recommends it
<seb128> slangasek: I demoted the nautilus recommends to suggests
<slangasek> seb128: oh, good :)
<seb128> slangasek: cf discussion with cjwatson one hour ago
<slangasek> heh, ok
<ember> slangasek the only thing missing for n-c-b is nautilus which is done by seb128
<ember> and on meta-gnome2 package
<ArneGoetje> slangasek: they take about 2 - 3 days. Next export will start tomorrow (Friday 22:00 UTC)
<seb128> slangasek: the issue is that if you have both you get items duplicated in nautilus
<slangasek> yes, that still doesn't really explain why it should be a 'conflicts', which is normally meant to handle packages that cannot coexist on the filesystem
<slangasek> seb128: well, right
<seb128> slangasek: how do you assure than n-c-b is uninstalled on upgrade?
<davmor2> slangasek: look at the http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/jaunty/ubuntu/20090319/livecd-20090319-i386.out current live is dated 17 and 64 bit 16
<slangasek> seb128: <handwave> :)
<cjwatson> davmor2: we know, it's being sorted
<seb128> slangasek: the conflict is not optimal if you have a better idea on how to do that you are welcome ;-)
<kees> Keybuk: I use tmp for more space than I have physical memory, so in the mean time, would it be okay for me to add that note to bootclean (especially since nearly no one runs with "verbose"...)
<seb128> slangasek: we should perhaps make dist-upgrade clean it and declare that command line user can figure they have to clean n-c-b to not have the duplicated item issues...
<Keybuk> kees: well, if we had swap files, that wouldn't be a problem
<seb128> Keybuk: alex would be interested by some sort of nautilus start profile in the cpu bound case if you can get one
<slangasek> seb128: meh.  <handwave> ;)
<Keybuk> kees: do you use tmp for more space than you have _virtual_ memory
<seb128> slangasek: understood ;-)
<Keybuk> seb128: sure, if he mails me instructions
<kees> Keybuk: sometimes, yes.  :)
<Keybuk> kees: you're weird ;) but yes, that note is ok
<kees> okay, I'll add it and send it to Debian.
<seb128> Keybuk: yeah, it's probably not trivial ... strace -ttt -o log could give some datas but that's probably not really useful
<Keybuk> seb128: trace isn't very revealing sadly
<asac> rtg: what should i tell users that have issues with ath5k?
<asac> are there any test packages or something they can try to provide input?
* slangasek changed the topic of #ubuntu-devel to: Archive: feature freeze, beta freeze | 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
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html - what on earth
<LaserJock> hmm, germinate looks screwed
<mvo> lets hope this is not the actual state of the archive :)
<cjwatson> it is, lots of build failures ATM
<LaserJock> I got LP build failures for edubuntu-meta on most arch's because germinate is uninstallable
<cjwatson> I'm building a chroot to try to drill down
<cjwatson> LaserJock: germinate depends on python and that's uninstallable
<cjwatson> you'll see a lot of knock-on effects
<LaserJock> yeah
<calc> shouldn't the old 2.6.28 kernels be removed from the archive?
<LaserJock> seb128: screem is gone now
 * calc notices 9 and 10 are still there
<seb128> LaserJock: you find something else to use?
<seb128> LaserJock: it's in universe now?
<LaserJock> seb128: it's unseeded
<seb128> Keybuk: so maybe sysprof?
<LaserJock> seb128: and no packages dep on it
<seb128> LaserJock: ok good thanks
<cjwatson> calc: they will be at some point soon
<slangasek> calc: yes, standard NBS material
<LaserJock> seb128: I didn't find a replacement this late but I think it's worth dropping for Jaunty, I (we) don't have time to deal with all the bugs anyway
<ogra> did we recently drop /etc/init.d/loopback ??
<slangasek> never heard of it?
<cjwatson> my lenny system does not have that init script
<calc> slangasek: ok
<ogra> hmm, i did get it with debootstrap when i created http://people.ubuntu.com/~ogra/arm/build-arm-rootfs
<seb128> cjwatson: your gnome-media upload is not on -changes, expected?
<cjwatson> seb128: I didn't upload it, it was a retry of an older upload that failed
<cjwatson> (conveniently)
<seb128> cjwatson: ah ok, good
<seb128> I was just checking ;-)
<cjwatson> hmm, a jaunty chroot from this morning is perfectly *upgradeable* to current
<seb128> thanks
<cjwatson> including python2.6
<tkamppeter> slangasek, I have worked on athe foo2zjs package to fix bug 338442 and uploaded it, but now it went into "waiting for approval" state, as it seems that it arrived shortly after beta freeze. What will hapen now? Will you simply approve it (it is a small change)? Or will you approve it in one week (after beta)? Or do I need to re-upload it in one week?
<ubottu> Launchpad bug 338442 in system-config-printer "bug reports would benefit from an apport hook" [Medium,Fix released] https://launchpad.net/bugs/338442
<rtg> asac: ath5k on Jaunty?
<asac> rtg: yes
 * cjwatson tries a debootstrap straight off archive.ubuntu.com
<slangasek> tkamppeter: the answer would never be 'reupload'.  I'll review it to see whether it should go in now or later, but I would assume 'now'.
<rtg> asac: if the stock ath5k driver does not work, then LBM is keeping pace with upstream. Also, pitti implemented jockey support yesterday to blacklist madwifi by default, so that driver collision should go away.
<tkamppeter> slangasek, OK. Thanks.
<pitti> to be precise, I implemented support for unblacklisting it and blacklisting ath5k instead in jockey
<pitti> rtg, asac ^
<asac> fta: ^^
<asac> rtg: what does "keeping pace with upstream" mean? are you providing latest from .29?
<asac> or which tree are you tracking?
<rtg> asac: yes, its currently up to date as of March 17
<asac> rtg: so you track linus tree?
<rtg> asac: I use compat-wreless in LBM which provides back porting support for wireless-testing. Those are the bits that go into the current upstream kernel, e.g., 2.6.29-rc8
<rtg> so yes, in essence I am tracking Linus
<asac> rtg: ok thanks for explaining.
<asac> rtg: one more thing. seems we dont mirror the sources in kernel.ubuntu.com
<asac> rtg: or am i looking at the wrong tree?
<rtg> asac: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty-lbm.git;a=summary
<asac> rtg: yes, but tree has no sources there how is that done?
<rtg> asac: I don't understand. It is a  git respository of the LBM sources, which contains the current compat-wireless snapshot.
<rtg> asac: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty-lbm.git
<asac> rtg: yeah. my denseness. all ok i think.
<asac> rtg: problem is i dont see upstream commits
<asac> that confused me
<cjwatson> archive fuckedness is cleared up now
<kees> pitti: so, what do we do about packages like cups which are entirely outside of Ubuntu VCS now?
<kees> pitti: e.g. had it been a few weeks ago, I could have directly done a commit and upload for 270663.
<rtg> asac: see debian/scripts/misc/prepare-compat-wireless.sh. It pulls stuff from the upstream repos in a chunk, though I usually reference the LBM commit message with an upstream tag from Linville's tree.
<pitti> kees: two possibilities really
<pitti> kees: method (1) which everyone else uses: just upload, and let me pick the diffs from launchpad
<asac> rtg: great. that should help me to spot what i need to track in order to know whats going on in LBM. thanks
<pitti> kees: (2) create a branch, put it on LP, and ask me to merge it
<pitti> kees: for changes which are appropriate for Debian, method (1) is sufficient
<pitti> kees: if you want to be nice to me, attach the patch to the bug and subscribe me, so that I can pick it from there :)
<kees> pitti: heh, that's what I did for 270663, but I figure it still means you need to touch it.  I wanted to get it totally squared away without bothering you, and that seems not possible now.
<pitti> kees: right, someone has to commit it to the debian branch
<pitti> kees: well, if you want to, I'm happy to give you write access ;)
<kees> pitti: I'm fine if that's how you want to handle it; I just wanted to save you some trouble.  :)
<pitti> it's not like cups would have too many active maintainers..
<pitti> kees: (run!) :)
<kees> hehe
<calc> anyone here running kde?
<calc> i have a bug i would like someone to check if they have a minute
<Keybuk> Dear Rosetta .... STFU!
<ScottK> +1
<stgraber> pitti: did you hear of some kind of crash of usplash at boot time ? (haven't looked in LP yet but heared a few user reports and I have that on my netbook)
<YokoZar> pitti: could we talk about keyring prompts briefly?  I just migrated a machine to Intrepid and spent about 10 minutes + google time trying to figure out how to disable it, and only at the end of that managed to do so (in a less secure way I believe).
<YokoZar>   The main problem is we have no "change keyring prompt" password, no way to easily set it to be just the system login password on upgrade (do we do thsi by default?), and we also have three separate places one would reasonably go to change this
<YokoZar> Applications->Accessories->Passwords and Encryption keys, System->Preferences->Encryption and Keyrings, and System->Administration->Authorizations
<YokoZar> The latter I quickly learned has nothing to do with this, but the second and first are very easily confused
<ogra> pitti, seems the new usplash artwork breaks on various ltsp clients
<stgraber> https://bugs.edge.launchpad.net/ubuntu/+source/usplash-theme-ubuntu/+bug/345269
<ubottu> Ubuntu bug 345269 in usplash-theme-ubuntu "Display gets corrupted with 0.22" [Undecided,New]
<stgraber> when you have encrypted LVM you just can't boot
<stgraber> (unless you remove splash from your boot parameters)
<bluefoxicy> that was odd
<bluefoxicy> I got a full kernel lock-up, then rebooted and it did it again when X started
 * bluefoxicy has 4 gigs of ram and runs out of memory using normal desktop apps (e-mail, web, chat, IM, accounting, music player) ... guesses he needs 8 gigs.
<Keybuk> amd64 I assume?
<directhex> you can't run out of memory & get a real lock-up on an ubuntu system. 5 minutes of lock-up with system in an inconsistent state afterwards, sure
<directhex> run out of ram, oom_killer swoops in & kills things at random for fun
<Keybuk> it's not at random
<Keybuk> it's very methodical in its killing spree
<YokoZar> can it kill itself?
<Keybuk> more of a serial killer than mere random violience
<directhex> hardly. the badness scoring doesn't take into account the time it takes to clean things up, so whilst if you're lucky it'll declare the real runaway process to be baddest, it'll start on other things whilst waiting
<directhex> fortunately sshd is unkillable on ubuntu. i suppose you could get a lockup if sshd fills your ram
 * Keybuk doesn't know what happens if the OOM killer runs out of things to kill
<Daviey> directhex: sudo killall -9 sshd, does a pretty good job of killing sshd
<directhex> Daviey, i mean by oom_killer
<Daviey> ahh
<directhex> Keybuk, hard lockup. fyi.
<Keybuk> directhex: looks like a kernel panic to me
<Keybuk>                         panic("Out of memory and no killable processes...\n");
<Keybuk> so at least the keyboard lights would be flashing ;)
<directhex> keyboard lights?
<Keybuk> kernel panic causes the keyboard lights to flash
<directhex> you assume i've done this on machines with a keyboard
<Keybuk> caps lock, num lock, scroll lock, etc.
<directhex> yeah, i know, i get that on occasion on my laptop. silly intel wifi
<Keybuk> have you filed bugs?
<directhex> frankly i'm astonished the driver went in at all, given it appeared on intel's git repo in alpha form a month before intrepid released. i'd need to re-test with jaunty
<pitti> stgraber: sorry for delay, ETOOMANYCONVERSATIONS today
<stgraber> hehe
<pitti> stgraber: I actually didn't, but is it the bug that ogra just cited?
<stgraber> yes
<stgraber> we discussed it in #edubuntu first :)
<ogra> right, it should mention the ltsp clients ...
<ogra> which it doesnt
<stgraber> it's not limited to LTSP
<stgraber> I have it on my netbook with a standard install
<ogra> but the description matches what i heard
<pitti> YokoZar: hi
<pitti> YokoZar: I don't think there's a possibility to configure the prompt
<pitti> configurable security prompts are quite pointless
<pitti> YokoZar: but this confirmation should really just be quiesced completely
<pitti> security-wise it's pointless, and usability wise it's a nightmare
<YokoZar> I agree with you that it should have gone away (and use the login password by default)
<YokoZar> The question is if there's some easy workaround we can do in the meantime (there's a keyring-pam module that can be set to use the login password I think, though I'm not sure what happens if that changes)
<pitti> YokoZar: login password> it does that; oh, you mean the dialog for the password?
<pitti> YokoZar: I thought you meant the dialog which ask you whether you want to grant access to the keyring (to whatever)
<YokoZar> Yeah that seems to have gone away, I mean the keyring password dialog
<YokoZar> It is not at all obvious how to change that, or to have that just use the login password all the time by default
<YokoZar> The current method for changing it is to open seahorse (applications->Accessories->Passwords and encryption keys), go to passwords, right click default, and then hit change password (nowhere is the word "keyring" used here)
<YokoZar> pitti: clarifying, the password prompt asking for my keyring key is still there
<pitti> YokoZar: ah, so you are saying that initially it works for you, but once you chagne your password, the gnome keyring passsword isn't changed alongside
<YokoZar> Not in all cases, certainly.  In Intrepid I had both as the same password, but I would still be prompted to type the same password twice (at login and then at the keyring).  When I put Jaunty on the machine I gave it a new password in Ubiquity, but keyring is still the old one
<TheMuso> Is there a plan to fix up the conflicts between brasro and nautilus-cd-burner, which is preventing installs/livefs builds?
<pitti> YokoZar: ah, I see; you upgraded, or installed jaunty over intrepid, with keeping /home?
<YokoZar> The latter
<pitti> YokoZar: I guess in this case pam-keyring didn't have a chance to notice
<YokoZar> Does update-manager have some voodoo to fix this that I missed?
<LaserJock> TheMuso: I believe so yes
<pitti> YokoZar: if you reinstall instead of upgrade, that's not update-maanger, but ubiquity
<YokoZar> Right, hence I didn't run update-manager and missed it's magical voodoo ;)
<cjwatson> TheMuso: yes, nautilus' recommendation of nautilus-cd-burner is being dropped
<pitti> YokoZar: in that case, the magical voodoo is pam-keyring intercepting the passwd call :) (or rather, not being able to since you aren't using PAM for changing the password)
<pitti> stgraber: oh, is that only lpia?
<pitti> stgraber: I'd have an explanation for that
<pitti> but less so for !lpia
<TheMuso> Ok.
<cjwatson> nijaba: reviewing
<cjwatson> nijaba: (I'll just fix errors directly in the page)
<YokoZar> pitti: so other than in this one case, keyring and login password are generally the same?
<pitti> YokoZar: yes, they should be (modulo bugs in pam-keyring, but it's pretty behaving)
<stgraber> pitti: it's a regular i386 install on a Asus EEE 1000H (atom)
<pitti> stgraber: ok; might be similar to Riddell's issue in kubuntu usplash; I'll ask some debugging questions in the bug report
<stgraber> pitti: sure, I'd also increase the priority if you haven't done it yet, in my case I just can't boot with usplash ...
<YokoZar> pitti: I guess we can more or less table this discussion till UDS and our next upstream talk so we can bring up removing it again.  My case was pretty narrow (although it's still hard to disable the keyring if you want to)
<cjwatson> nijaba: surely desktop and server support are defined as the union of seeds, not the intersection
<nijaba> cjwatson: what was I thinking...
<cjwatson> fixed
<nijaba> ta
<cjwatson> (just wanted to double-check)
<cjwatson> right, that's enough for today
<nijaba> have a good evening then
<maco> is the message indicator applet tied to gdm the way fusa is?
<pitti> stgraber: confirmed here; I'll update the bug and debug it tonight
<LaserJock> maco: how do you mean?
<LaserJock> fusa does things like restart, log out, etc., indicator applet doesn't do anything like that
<maco> LaserJock: well i'm 99% sure the reason fusa doesnt work for me is that i use kdm and it cant get the domain sockets for gdm that it relies on (was reading comments in fusa's code).
<maco> starting gnom from kdm instead of gdm is the only odd thing i can think of about my session, and the indicator applet doesnt work
<maco> it shows "no notifications" at all times
<LaserJock> maco: so switch to gdm and see
<maco> wow...going to go file a wishlist bug for quassel now...netsplit detection
<maco> kirkland: on that ecryptfs/home/preseed bug, the original report included a preseed file
<kirkland> maco: ah, okay, i'll dig that up
<maco> http://launchpadlibrarian.net/21266763/ubuntu-desktop-experimental.seed
<maco> my attempt at installing from the mini yesterday failed. it didnt like the archive keys, and the iso was old enough to complain about archive kernels being different. trying with a new cd
<maco> hi
<fargiolas> ubuntu lpia packages are specific for ubuntu-mid distribution? or is there a standard ubuntu distribution for lpia architecture?
<fargiolas> (it's not a support question I'm evaluating opening a bug report)
<LaserJock> fargiolas: there are CDs just like any other arch
<fargiolas> LaserJock: so a lpia package it's not necessarly meant for use with ubuntu-mid environment, right?
<LaserJock> well, ubuntu-mid is a part of Ubuntu so I'd say it's meant for use with an ubuntu environment
<LaserJock> but I'm not a MID person so I can't say for sure
<fargiolas> LaserJock: the thing is that cheese package is built with --enable-hildon on lpia archs but if lpia != ubuntu-mid it's not implied that the package will run in a hildonized desktop
<fargiolas> (to complicate the thing even more there is a separate cheese-hildon package..)
<LaserJock> my guess is that it's the best solution people could think of
<fargiolas> LaserJock: the best solution is have a cheese-hildon package and build the cheese package without hildon support on every architecture
<ScottK> fargiolas: A fair amount of work has been done to separate MID and lpia.  I'm sure it's not done.
<fargiolas> ScottK: ok, I'll open a bug then.. btw cheese hildon mode is broken as far as I remember, but that's another story, will look into it when I have some spare time
<pitti> Riddell, stgraber, ogra: I found the usplash theme problem
<ogra> fargiolas, erm, cheese-hildon is already built separately
<stgraber> pitti: cool :)
<pitti> Riddell: I'll fix it in the kubuntu theme as well
<ogra> fargiolas, since november ... mcasadevall worked on that
<fargiolas> ogra: sure, but if architecture is lpia cheese (not cheese-hildon) is built with --enable-hildon
<ogra> Package: cheese-hildon
<ogra> Conflicts: cheese
<ogra> Replaces: cheese
<ogra> Architecture: any
<ogra> no, its built on all arches
<fargiolas> ogra: let me look for the debdiff to show you what I mean
<fargiolas> ogra: cheese-hildon is not involved in this issue, I'm talking about the cheese package
<ogra> talk to mcasadevall but i'm pretty sure he fixed it to build hildon and non hildon packages on lpia
 * ogra hugs pitti 
<fargiolas> ogra: clearly he didn't :P, from cheese_2.26-0ubuntu1.diff:
<fargiolas> +ifeq ($(DEB_BUILD_ARCH),lpia)
<fargiolas> +	DEB_CONFIGURE_EXTRA_FLAGS += --enable-hildon
<fargiolas> +endif
<ogra> as i said, talk to him if his patch doesnt DTRT it needs fixing
<TheMuso> pitti: what is the problem?
<TheMuso> pitti: I'm just wondering in terms of whether the studio theme may need more tweeking.
<pitti> Riddell: I'm willing to bet that this bug (bug 345269) is the reason for the kubuntu crash as well
<ubottu> Launchpad bug 345269 in usplash-theme-ubuntu "Display gets corrupted with 0.22" [High,In progress] https://launchpad.net/bugs/345269
<pitti> Riddell: it crashes on 640x400, but works for e. g. 1280x1024
<fargiolas> ogra: oh sorry, I've read "thanks to" instead of "talk to" :)
<pitti> TheMuso: there's a typo in the pulsating code which makes it crash and corrupt screen for some resolutions
<ion_> Huh. I have https://wiki.ubuntu.com/SeedManagement open in Firefox. The page is fine otherwise, but the tab and page titles read âThe Kernel Virtual Machineâ where it should read âSeed Managementâ. If i open the page in a new tab, itâs fine.
<ogra> fargiolas, :
<ogra> cheese (2.24.1-0ubuntu2) jaunty; urgency=low
<ogra>   * Split out Hildon specific compontents into cheese-hildon
<ogra>   * Changed hildon build-dep to no longer be lpia specific
<TheMuso> pitti: ah, I think our pulsating code is somewhat different. Will need to try it out at some point.
<TheMuso> to see if we are affected.
<pitti> TheMuso: did you ever get reports about screen corruptions halfway in?
<ogra> fargiolas, there were various changes from other people and new upstream merges, it can easily be that his changes were broken and regressed
<TheMuso> pitti: not so far, but unfortunately our users aren't really testing jaunty as heavily as we'd like.
<fargiolas> mcasadevall: ping?
<pitti> TheMuso: downloading usplash-theme-ubuntustudio to check
<ogra> fargiolas, i.e. there were four new upstream releases since his fix
<pitti> TheMuso: there's a lot of cut'n'paste going on in the themes, after all
<TheMuso> pitti: yeah
<pitti> TheMuso: nope, your t_animate_step() functions are entirely different, and they look ok
<fargiolas> ogra: well, I'm almost sure we (upstream) didn't change anything hildon related since some time (I believe the hildon mode is almost broken) probably mcasadevall missed that ifdef
<pitti> TheMuso: well, s/look ok/aren't affected by this bug/
<TheMuso> pitti: right
<ogra> fargiolas, not upstream, the person who did the merge
<fargiolas> ogra: oh ok
<ogra> fargiolas, i know michale fixed it properly, but afterwards four other people merged new upstream versions :)
<fargiolas> ogra: I see :)
<maco> if we've got the message applet and tedg's fixed pidgin so it doesnt go invisible for everyone that's not using that applet...why is pidgin still defaulting to showing the icon in the notification area at all times?
<tedg> maco: It doesn't as of the upload today.
<maco> guess that hasnt hit updates yet then?
<tedg> maco: Updates meaning intrepid updates?
<maco> no, jaunty updates
<maco> i have a gnome-only vm to see what's breaking because i combine gnome and kde and what's breaking just fo the sake of breaking
<maco> updated it 20 minutes ago and ran pidgin for the first time, and it defaulted to show always
<tedg> maco: I think that it has, it should be pidgin 2.5.5-1ubuntu2
<maco> ok, will wait for that update to reach me
<ogra> slangasek, err, beta freeze already ? i thought that was monday
<maco> thanks
 * ogra curses for having read the release schedule wrong
<ion_> keybuk: Why was the initial panel animation removed?
<slangasek> ogra: I also sent mails... :)
<ogra> slangasek, yes, that just got in my face on my way to bed
<pitti> slangasek: please approve the usplash-theme-ubuntu fix I just uploaded; it's a major regression and an obvious fix
<slangasek> sebner: is the fact that you uploaded monodevelop-java an assertion that this is bugfix-only and doesn't require motu-release approval?
 * ogra goes to bed anyway
<slangasek> pitti: sure, will have a look at it soon
<seb128> slangasek: please approve the rhythmbox new version, I would have uploaded before freeze but I got asked to wait due to lpia rebuilds ;-)
<slangasek> heh, ack
<seb128> slangasek: the current jaunty version was a candidate version from a week ago, there is almost no change, that one is the stable version
<ion_> pitti: usplash-theme-ubuntu.c seems to be missing usplash_theme_1680_1050, which is quite common a resolution.
<pitti> ion_: it should pick the biggest theme that's smaller than that
<pitti> ion_: but we can certainly add it (not beta critical, though)
<ion_> pitti: Yeah, it picks 1280Ã1024 and the aspect ratio is totally wrong. The monitor can be blamed for not preserving the aspect ratio, though.
<pregier> I'm seeing some pretty bad behavior between sun-java6-plugin and firefox-3.0 in hardy (seems to be a sour java_vm process after a couple successful applet [re]loads), but I'm not seeing any directly related reports on launchpad even though I suspect this is an old issue; does anyone know if there's a good reason (such as this likely being an upstream bug or firefox bugs being too random to consistently reproduce) why this shouldn't be reported on
<maco> kirkland: k yeah i cant reproduce the bug again either.
<didrocks> jelmer: around? There is a new version of evolution-mapi currently building in my ppa (~didrocks). Can you test it with an exchange server and tell me if everything's ok?
<kirkland> maco: cool, with the preseed file?
<pitti> slangasek: corresponding kubuntu-default-settings uploaded, too (for the kubuntu usplash screen/VT corruption)
<maco> kirkland: no, i did it with a normal mini install, same options i chose last time when i ran into that bug
<kirkland> maco: cool, that's what i tried yesterday, didn't see the issue
<kirkland> maco: next, to test with a preseed file
<maco> kirkland: i installed on the same machine where i hit it before though, so i cant see if chmod'ing the home dir back 500 brings it back
<maco> probably shouldve used a vm
<kirkland> maco: heh
<pitti> Riddell: please pull lp:~pitti/kubuntu-default-settings/fix-345269 into lp:~kubuntu-members/kubuntu-default-settings/ubuntu
<TheMuso> slangasek: I'd like to upload a new revision of casper to fix a long standing bug where changing orca settings would require a restart of orca, rather than orca picking up the settigns immediately. Just got to create a caster task for the bug in question.
<TheMuso> gah typing
<slangasek> TheMuso: sounds to me like a straight bugfix, go ahead with the upload and it'll get reviewed in the queue
<TheMuso> slangasek: ok thanks.
<ia> hello. i've asked about this in #ubuntu-motu and i've got advice to ask this here - i have a question about apport implementation. if i make apport-cli -f -p <package>, then it gathers information and takes me via my browser at https://bugs.launchpad.net/ubuntu/+source/package/+filebug/ID. so, the question is, does exist some way to change that url to https://bugs.launchpad.net/package/+filebug/ID ? for example, if i make some project, and would like use lp
<ia>  with apport, but my package is not in ubuntu.
<stdin> I think looking at /usr/lib/python2.5/site-packages/apport/crashdb_impl/launchpad.py and /etc/apport/crashdb.conf would start you off
<pitti> slangasek: xubuntu-artwork uploaded as well, while I am at it
<pitti> ia: indeed there is
<pitti> ia: but it's very rough right now
<slangasek> pitti: ok; coming up I'm going to have to hide from the queue from a while so that I can get the release meeting agenda off :P
<pitti> slangasek: it's not *that* urgent, just commenting on the stuff I'm uploading, since I won't approve them
<seb128> slangasek: nice that you sponsor changes I disagree with ... ;-)
<pitti> ia: you can set APPORT_REPORT_THIRDPARTY=1 somewhere
<pitti> ia: e. g. when filing the bug
<pitti> ia: but you can't specify the particular project name (for cases where package name != project name)
<pitti> ia: that will be improved in the future
<slangasek> seb128: well, ted persuaded me that the changes were sane; if you feel strongly, I'll accept your upload to revert it, too :-P
<maco> haha
<seb128> slangasek: I'm tempted
<seb128> slangasek: that breaks string freeze, translation, has no upstream bug reference not tagging and use theme specific icon
<cody-somerville> are we talking about rhythmbox?
<seb128> cody-somerville: no, xchat
<seb128> cody-somerville: what about rhythmbox?
<cody-somerville> I can't wait until it builds :)
<ia> pitti: oh, thank you very much - "APPORT_REPORT_THIRDPARTY=1 apport-cli -f -p git-tracker" doesn't work in intrepid, but looks like, that it works properly in jaunty; and i think, that it's really useful and amazing feature :-)
<mr_pouit> pitti: merged, thanks for the fix :)
<kklimonda> is there something wrong with firefox today? because i'm getting a lot of SIGSEGV and it wasn't like that yesterday.. or earlier..
<slangasek> seb128: the package is in universe, so isn't covered by the string freeze.
 * calc is dangerously close to 0 NEW bugs on OOo :)
<calc> quick someone file a bug ;-P
<jelmer> didrocks: not until next week :-( I'm away from home, don't have my VMs with me
<ia> and another question about bug reporting - could anyone point me, please, to some howto/docs about integration app with apport - in case, that if my app crashes/quits incorrectly, then system runs apport for such app automaticly?
<seb128> slangasek: right, it's even better so we are sure this string will be in english for all users now since there is no language packs in universe
<seb128> I should rent again about english speaker never considering people not using english ;-)
<seb128> rent -> rant
 * slangasek reuploads, adding French translations
<slangasek> :-P
<seb128> ah ah
<slangasek> sorry, "translation", there's only one :)
<seb128> I don't care enough to argue longer
<seb128> but I really see such changes are no win, they add delta, break translation, use theme specific icons ... for what
<calc> 0 new bugs! yipee :)
<seb128> brb
<slangasek> seb128: well, I agree with the objection that the existing notifications are overly-verbose, and think this ought to be considered a UI bug.  The translation regression is unfortunate, but not IMHO overriding; and I was only half joking about reuploading with translations
<seb128> slangasek: well the choice is between a bit too much verbosity and no translation, easy choice for an english speaker I would say ;-)
<seb128> my approch for such changes would be to send upstream and wait for the next version
<seb128> so they can get it translated etc
<seb128> anyway that's a detail, people who care about that should be using xchat-gnome which get it right ;-)
<seb128> slangasek: gnome-settings-daemon sent your way, that's a one line change to get a notify-osd icon for eject
<slangasek> we could revert the last of the changes only, leaving no meaningful regression in translations
<seb128> right, that's what I was saying to ted when he decided to convince you rather than argue with me ;-)
<slangasek> ah, hmm
<seb128> there is still the icon being theme specific
<seb128> but shrug as said that's a detail
<seb128> let's focus on jaunty beta now ;-)
<seb128> hum, Laney has gdm counting on the liveCD, that's the second mention of a such issue this week
 * Laney raises hand
<seb128> is that an on purpose change or a new bug?
 * seb128 didn't do CD testing since alpha6, let's rsync
<seb128> slangasek: btw bug #328167 seems to be architecture or installation specific
<ubottu> Launchpad bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [High,Triaged] https://launchpad.net/bugs/328167
<slangasek> seb128: yes, from the bottom of the bug log I gather that it was really a broken kernel
<seb128> slangasek: ie we got no such bugs from non-arm users
<Laney> wow, good job on the new timezone chooser btw, great improvement
<TheMuso> well I have the latest live CD here, and besides the livefs being a few days old, I get no GDM counting here.
<Laney> this is today's daily
<Laney> i386
<TheMuso> let me try i386 as well then
<TheMuso> Laney: trying in KVM first, and I'll try on real hardware next.
<Laney> sure
<TheMuso> ok expected behavior in KVM.
<TheMuso> burning a disk and will try on my notebook.
<seb128> Laney: can you look to system logs if gdm or gnome-session or xorg crashed?
<Laney> seb128: Actually now that you mention it, it did flicker a couple of times
<TheMuso> Laney: what video card are you using?
<Laney> uhm, whatever the MB 5.1 has
<TheMuso> nvidia
<TheMuso> that might explain it
<TheMuso> sounds like the xorg nv driver doesn't know enough about that card.
<Laney> aha
 * Laney spies xorg backtrace
<TheMuso> Laney: yeah I have an MBP 4.1 and the open source nvidia driver has no trouble with it, given its an 8600MGT.
<TheMuso> afaik the MB 5.1 has a 9400M
<Laney> That's right
<Laney> http://dpaste.com/16698/ <- xorg log
<seb128> Laney: ok, so it's an xorg crash indeed, weird that it works then
<Laney> seems to have recovered, which is commendable
<Riddell> pitti: k-d-s merged, thanks
<DnaX> Emesene LibNotify patch: https://bugs.edge.launchpad.net/ubuntu/+source/emesene/+bug/345660
<ubottu> Ubuntu bug 345660 in emesene "Emesene Libnotify plugin don't check for actions" [Undecided,New]
<DnaX> to be fixed in Jaunty!
<DnaX> mpt: ping
<TheMuso> Is it just me, or are gnome-terminal fonts rather big no
<TheMuso> now
<slangasek> I haven't seen any change here
<TheMuso> hrm ok, will see if I have some lingering gconf settings
<seb128> that's asac's font change
<slangasek> what change is that?
<seb128> slangasek: bug #345189
<ubottu> Launchpad bug 345189 in libgnome "Change to 13.333px is a regression for me - fonts far too large" [Undecided,Confirmed] https://launchpad.net/bugs/345189
<Laney> TheMuso: I see it in my clean installation
<seb128> slangasek: the change to fix the issues on high dpi screen which have been raised since we use the xorg detected value and not 96dpi
<slangasek> hrm
<asac> TheMuso: yes. its a gnome-terminal bug
<asac> TheMuso: try gnome-terminal from my ppa
<asac> its fixed there
<TheMuso> asac: ok thanks for the heads up.
<asac> TheMuso: if you dont want to volunteer on participating on other font fixes, just pick the terminal bits
<asac> TheMuso: e.g. i have a changed gtk and and settings daemon in there too.
<TheMuso> asac: ok
<asac> but you dont need it ;)
 * slangasek reads https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/310353/comments/24 and shakes his head sadly
<ubottu> Ubuntu bug 310353 in gnome-control-center "Default font size too large if using native DPI" [High,In progress]
<asac> slangasek: its a misunderstanding ... from what i understand this, pt has never been right except for 72 dpi screens
<slangasek> asac: pitti has the correct definition of "pt" in that comment, so if GNOME is doing something different, that's, oy
<asac> and px is what measures absolute size (yes, its confusing. and lots of folks complain on the net about choosing this already used word "pixel")
<slangasek> "confusing" is one way to put it...
<slangasek> "ass-backwards use of pre-existing font terminology" is another
<asac> its just that "pixel" for fonts doesnt mean "pixel" on screens ;)
<slangasek> yes, it does
<slangasek> just apparently not in libgnome
<asac> its not libgnome
<seb128> libgnome has just a gconf value
<slangasek> then where?
<asac> everywhere ;)
<slangasek> pango?  xft?
<asac> yes
<directhex> cd Riddell
<directhex> gah
<asac> slangasek: it comes from the html standard from what i found
<slangasek> um
<slangasek> the CSS standard didn't get this wrong
<asac> they had pt defined and needed something new for something thats properly dpi adjusted
<asac> hmm
<asac> i understood CSS did what i ment with html
<asac> i will research. but either its upside down everywhere or its like i thought it is ;)
#ubuntu-devel 2009-03-20
<asac> "Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 i
<slangasek> asac: URL?
<asac> http://www.w3.org/TR/CSS21/syndata.html
<asac> 4.3.2 Lengths
<asac> slangasek: so scaling of pixel unit seems to be explicitly encouraged
<asac> of course we dont know how far the user is away
<slangasek> it says to scale it to account for viewing distances
<slangasek> not to screw with it based on DPI
<asac> so we scale blindly by dpi
<YokoZar> and while we're talking about pixel values the latest updates from today seem to have made the DPI for my display even more wrong (pidgin fonts are even bigger now)
<asac> slangasek: its a combination of distance and density from what i understand
<slangasek> # pt: points â the points used by CSS 2.1 are equal to 1/72nd of an inch.
<asac> so in theory we would need three profiles or somthing like:
<asac> handheld, laptop, desktop
<slangasek> the spec also says that, which is the correct definition of points
<slangasek> pitti: is bug #27622 still 'in progress' somewhere?
<ubottu> Launchpad bug 27622 in langpack-locales "Paper Size is wrong for locale es_CO (A4 -> Letter)" [Medium,In progress] https://launchpad.net/bugs/27622
<slangasek> asac: yes, and I say that tampering with the definition of a pixel based on DPI is worse than doing nothing at all, because DPI is not correlated with viewing angle
<asac> slangasek: yeah i agree. and maybe pt really does that
<asac> but it looked like it doesnt ... could be relative of course
<asac> i dont have a high dpi device here to compare the real size
<asac> but px does definitly things based on dpi too ... not sure if thats all a bug or not ;). probably needs some discussion with the right folks
<PerryArmstrong> ikonia; you there??
<directhex> it's past 1am, so probably not
<PerryArmstrong> it depends on the country where they stay...here its 7 am
<directhex> yes, it does indeed depend on that.
<PerryArmstrong> i just came here seing this IRC name in GSoC
<directhex> and it's past 1am where he is
<TheMuso> Considering the person in question has been idling at least 11 hours, I'd say they are not currently around at a guess.
<PerryArmstrong> thank you directhex, TheMuso for the info
<PerryArmstrong> any discussions on GSoc
<PerryArmstrong> i am sarching for maria who is the mentor for ubuntu in GSoC
<t3rm1n4l> how do i build cheese on ubuntu 9.04
<t3rm1n4l> ?
<t3rm1n4l> latest cheese sources require latest gnome
<t3rm1n4l> which is latest than on 9.04
<TheMuso> slangasek: new linux-ports uploaded, no ABI bump, based on the most recent jaunty kernel upload, with the only change being the config change mentioned which was done in jaunty mainline.
<jdong> kees: out of curiousity, where would we fit in on http://www.awe.com/mark/blog/200801070918.html that chart?
<slangasek> james_w: hrm, is bzr-builddeb known to be broken in jaunty right now?
<slangasek> possibly only when the upstream tarball is missing
<slangasek> hmm, nope, broken even if I grab it
<james_w> slangasek: not known to me
<maco> i used bzr builddeb today just fine
<maco> slangasek: bug 345727 is problematic for people that use both gnome & kde.
<ubottu> Launchpad bug 345727 in seahorse-plugins "Seahorse-agent writes an empty ~/.gnupg/gpg.conf on first run, breaking email signing in KDE" [Medium,In progress] https://launchpad.net/bugs/345727
<maco> ScottK and i talked about it, and having seahorse-agent do what gpg-agent does and just put the skeleton file in place seemed like the right thing to do. there's a branch attached to fix it. is that something to bother you about for release?
<maco> (that bug is why i used bzr builddeb :P)
<slangasek> james_w: mmk, bug will be coming then
<maco> (read today as: 2 hours ago)
<james_w> slangasek: thanks
<slangasek> maco: if by 'bother me about' you mean 'upload', sure? :)
<maco> slangasek: email said release people need to give permission before uploads happen
<maco> so i figured id ask you (release people) before bugging someone about uploading
<slangasek> maco: yeah, I suppose the email does say that :)
<slangasek> maco: permission granted
<maco> ok thanks :)
<slangasek> Hobbsee: how does having libavcodec51 installed break libavcodec52/libavformat52?
<maco> oh i can answer that: "aptitude says so"
<slangasek> heh
<maco> aptitude full-upgrade says i have to remove libavcodec51 so libavformat52 can be installed and then brasero is not allowed to update once that occurs
<slangasek> well, libavformat52 is marked Breaks: libavcodec51, and I don't understand that one either; but adding a conflicts besides seems like the wrong solution
<slangasek> and you're sure that's not just the brasero/nautilus-cd-burner issue?
<maco> oh if theyve got an issue of their own then that could explain those two
<maco> when this apt process finishes, ill get it to spit out the "omg libavformat52 is gonna break things!" message again
<james_w> slangasek: are you blocked on the bzr-builddeb bug?
<slangasek> james_w: nah, I used debuild instead :-P
<james_w> excellent
<james_w> I shall stop torturing myself on this free wireless connection and deal with it when I return home
<james_w> toodle pip
 * slangasek waves
<dholbach> good morning
<maco> long update
<maco> anyway...aptitude says "libavformat52: Breaks: libavcodec51 but 3:0.svn20080206-12ubuntu3 is installed.
<maco> " and then offers to remove libavcodec51
<slangasek> that's the right thing for it to do
<maco> (the updater killed my net connection, no idea why it keeps doing that)
<slangasek> and in fact, the latest ffmpeg-debian upload only causes libavcodec51 to be removed sooner
<maco> maybe its just bcause of the brasero/nautilus but it gives a "score 270"
<maco> presenting it as "unmet dependencies" seems like an odd way to deal with that
<maco> i assume update-manager/do-release-upgrade would gloss over that?
<slangasek> james_w: bug #345747 filed against the bzr-builddeb package
<ubottu> Launchpad bug 345747 in bzr-builddeb "backtrace when running bzr bd --source" [Undecided,New] https://launchpad.net/bugs/345747
<Hobbsee> slangasek: if i've got it wrong, feel free to kill that upload and upload whatever *is* the fix, and point me at it
<maco> Hobbsee: i think he's saying its doing the right thing
<maco> we just find it ugly
<slangasek> maco: yes, 'unmet dependencies' is a bit odd; yes, update-manager would do something less odd
<slangasek> Hobbsee: is what maco described above the issue that you were trying to fix?
<Hobbsee> maco: oh, aptitude offers to remove it?  I don't recall you mentioning that earlier.
<Hobbsee> slangasek: yes
<maco> pretty sure i said that. quassel's going nuts trying to do a /lastlog though
<maco> Hobbsee: ok your memory wins. i only saw & repeated the part of aptitude's spew that says it was going to not-update brasero
<Hobbsee> maco: oh good.  So i'm not going *entirely* mad.
<slangasek> I'll reject the upload then
<Hobbsee> ok, cool
<Hydrant> hey all... I want to install gcc 4.4 alongside everything else on my system.... how can I do that?
<J-_> Just an idea: http://brainstorm.ubuntu.com/idea/18694/ </spam>
<Hobbsee> J-_: no need to spam that here as well.  Besides, jaunty's in beta freeze by now.
<Hobbsee> J-_: and looking at that, the answer will be "Mark says no", fwiw
<J-_> Ah okay.
<maco> yep
<maco> though id love if we could alt+click or ctrl+click or something
<maco> then it wouldnt interrupt using the window behind, which is the reason they're currently not clickable
<crdlb> maco: but you can't accept one type of mouse input without accepting them all
<maco> crdlb: what if it glowed when you held down the necessary modifier key?
<maco> that'd add discoverability!
<tkamppeter> pitti, hi
<mvo> evand: I have a haning partman in front of me (bug #345785) - anything I can do to resurrect it or will I have to redo the partitioning and kill ubiquity (with todays daily)
<ubottu> Launchpad bug 345785 in ubiquity "hangs in advanced partitioner" [Undecided,New] https://launchpad.net/bugs/345785
<evand> mvo: can you kill it, but also when you run the installer again, can you pass ubiquity the -d flag and then attach /var/log/installer/debug to that bug report?
<mvo> evand: sure, I will do that. I'm not sure I will be able to reproduce it again, but I will try. I paritioned back and forth (I need a complicated layout to test my free space code :)
<evand> ah, fingers crossed then :)
<mvo> evand: *pff* now it works (I tried exactly the same steps)
<evand> very odd
<evand> mvo:  have you rebooted since?  If you haven't, is there a traceback anywhere in your /var/log/installer/debug?
<crazybyte> evand, hi. may i take a few minutes of your time?
<evand> crazybyte: sure
<mvo> evand: I have not rebooted yet, but killed / restarted ubiquity (to run it with -d)
<mvo> will that overwrite the log ?
<mvo> evand: no Traceback, sorry
<evand> mvo: no worries
<crazybyte> evand, after a short discussion with janimo (i'm not sure that you know him but he recomended you) and browsering around I want to poke around and try to implement a grub-restore and some gui for grub as posted on brainstrom and janimo told me that i can ask you a bit about ubiquity
<crazybyte> i want to familiarize myself with the code and also and i'm sure that i will came up with some questions for things that i don't really understand
<evand> crazybyte: sure, why don't you jump in #ubuntu-installer and we can take it from there
<crazybyte> ok
<crazybyte> thank
<crazybyte> i can't right now because i'm at work and trying to figure out the cause of some very ugly bug but if later i can i will gladly. is that possible?
<crazybyte> evand, ^^^
<evand> sure
<evand> if email works better for you, mine is evand@ubuntu.com
<crazybyte> ok
<crazybyte> thank you
<evand> anytime
<pitti> slangasek: 27522 (wrong paper size) still on my list, just not very high-prio; but I'll get it done for jaunty
<pitti> asac: do you agree to slangasek that bug 310999 should have the targetted tasks removed? or closed at all?
<ubottu> Launchpad bug 310999 in nss "comodo seen issuing certificates unwisely" [Unknown,Confirmed] https://launchpad.net/bugs/310999
<pitti> Riddell: do you have someone to work on bug 308060?
<ubottu> Launchpad bug 308060 in libmsn "Include libmsn in main" [Medium,Confirmed] https://launchpad.net/bugs/308060
<asac> pitti: yes. thought that was already done
<asac> just wont fix it
<pitti> asac: okay
<pitti> asac: the floating task as well? or just the release tasks?
<asac> pitti: you can keep the floating "nss" open. personally we wont do anything in the distro on our own
<pitti> okay
<asac> so either open or close
<asac> i dont mind
<pitti> okay, closing then
<pitti> thanks!
<pitti> Riddell: if not, and libmsn is too buggy/too unmaintained, is it possible to drop the dependency?
<Riddell> pitti: it's not buggy or unmaintained, I'm working with upstream on a patch, he commented on that bug
<pitti> Riddell: ah, thanks
<pitti> Riddell: final harrassment from me from today, bug 339902 seems to be in discussion upstream, so we're just waiting for them?
<ubottu> Launchpad bug 339902 in notify-osd "notifications visible through the screensaver" [High,Invalid] https://launchpad.net/bugs/339902
<Riddell> pitti: right, hopefully a fix will be in 4.2.2 out shortly after beta
<pitti> great
 * pitti is a bit concerned to see the desktop team's list of RC bugs grow instead of shrink
<pitti> but that's just because less and less "critical" bugs are put into it, not because they don't get fixed (they do)
<pitti> so, by and large, we're in good shape
 * pitti -> off again
 * cjwatson looks at his huge pile of build failure mails, sighs, and starts digging into ports uninstallability
<cjwatson> libgnome given back on sparc ia64 hppa armel, which should clear up quite a bit of uninstallability
<cjwatson> and libgnomekbd on hppa ia64
<mdz> pitti: is there any simple way to query for bugs  where apport-collect was used (i.e. which were not reported originally using apport)?
<mdz> pitti: I'm interested in seeing how much it's being used
<cjwatson> infinity: phonon is going to need manual bootstrapping on hppa, assuming that the weird segfault in http://launchpadlibrarian.net/23279114/buildlog_ubuntu-jaunty-hppa.phonon_4%3A4.3.1-0ubuntu1_FAILEDTOBUILD.txt.gz doesn't happen again
<cjwatson> infinity: phonon Build-Depends: libqt4-dev Depends: libqt4-webkit which is uninstallable because phonon is too old
<BUGabundo> pitti: ping
<BUGabundo> any know bug on jaunty's jokey and nvidia?
<infinity> cjwatson: Fun.
<infinity> cjwatson: Oh, if you're deeply interested in failures, you might want to get a jump on https://lists.ubuntu.com/archives/ubuntu-autotest/2009-March/thread.html before I start filing bugs today...
<cjwatson> infinity: interested, but probably not interested enough to beat you to it
<infinity> cjwatson: I'll note that doko's the only person actually subscribed to that list.
<infinity> cjwatson: Might be nice to find some folks in your team who'd be keen on actually watching it?
<cjwatson> infinity: hmm, yes - can you mail me+Robbie a reminder?
<infinity> cjwatson: When I find myself a bit more awake, sure.
<doko> infinity, cjwatson: I would assume that doing rebuild tests would include filing reports for the real failures?
<cjwatson> doko: that was what I understood from infinity's comments above ...
<infinity> doko: I try to get them all filed (or even fix the really trivial ones), but more eyes (and people beating me to it) wouldn't hurt, since it really is distro's domain.
<doko> ahh, ok
<cjwatson> infinity: do you tag the autotest bug reports somehow, BTW, or make them RC, or whatever?
<infinity> cjwatson: I target them to the current release.
 * cjwatson nods
<cjwatson> that should be fine
<infinity> cjwatson: And make them RC if it's a fatal, all-arches sort of failure, rather than a "gee, this doesn't work on PPC" thing.
<doko> infinity: I take python-docutils, lxml and clientcookie
<cjwatson> pychecker looks as if it just plain hasn't been updated for 2.6
<cjwatson> ryanakca: your revision 34 in kdebindings looks wrong, and has caused python-kde4-dev to be uninstallable
<cjwatson> +Conflicts: python-kde4 (<= 4:4.2.1-0ubuntu4)
<cjwatson> ryanakca: shouldn't moving a file from one package to another normally be expressed using Replaces not Conflicts, anyway?
<MacSlow> pitti, will it make sense to work on a patch (on the weekend) to fix these libgksu-glitches (http://people.ubuntu.com/~mmueller/libgksu-clearlooks.png http://people.ubuntu.com/~mmueller/libgksu-murrine.png) so GtkEntry-widgets will look like http://people.ubuntu.com/~mmueller/custom-app-clearlooks.png http://people.ubuntu.com/~mmueller/custom-app-murrine.png (note: just GtkEntry not the brushed metal bg)
<MacSlow> pitti, will that be able to still make it to the repo?
<MacSlow> pitti, if not I will just not do it and waste my spare time on that ... just wondering
<mdz> my fonts just changed with the latest updates; is that expected?
<ogra> mdz, where exactly ? i had some issues with firefox antialiasing that were fixed by a recent upload from asac
<mdz> ogra: the application font (text in xchat, menus, etc.)
<geser> infinity: your rebuild sbuild has that bug that the provided modules from the perl package are counted for versioned build dependencies, see https://lists.ubuntu.com/archives/ubuntu-autotest/2009-March/020856.html
<ogra> hmmm, for me it turned out that there were some links from /etc/fonts/conf.avail/ to /etc/fonts/conf.d missing, but the latest upload should have fixed that, probably it causes other fallout
<geser> doko: if you have time to review and sponsor: bug 345860
<ubottu> Launchpad bug 345860 in nevow "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/345860
<infinity> geser: Yeah.  Ignore that, I'll fix it...  Forgot to port the fix to that sbuild fork. :/
<ogra> mdz, just finished an upgrade and my fonts stayed the same
<asac> mdz: it depends on your dpi
<mdz> it's a "thinner" looking font
<asac> at least if you refer to font size
<asac> mdz: ah ... yeah. thats a change in fontconfig ... before we shipped -medium while itshould have been -slight hinting
<mdz> asac: should have been?
<asac> mdz: yes. thats what we default for in gnome
<asac> so now fontconfig and gnome agree
<asac> mdz: the other change is that we use 13.333px for /desktop/gnome/interface/font_name ... before we had "10"; but that only makes a real difference on screens != 96 dpi
<nightwish> sorry, we have to perform emergency maintenance on this host so it will go down now. i hope we'll be back within the next 10 minutes
<asac> mdz: you can try to set that to "Sans 10" ... which is the value we used before
<cjwatson> nightwish: wrong channel?
<Hobbsee> cjwatson: or an /ame, presumably
<Hobbsee> er, or similar
<nightwish> cjwatson: hum?
<cjwatson> 12:24 <nightwish> sorry, we have to perform emergency maintenance on this host so it will go down now. i hope we'll be back within the next 10 minutes
<cody-somerville> cjwatson, I think nightwish means the IRC Server is going down
<cjwatson> there is no one "this host" that everyone on this channel would be using
<cjwatson> and there are better places for notices of IRC server outages than mentioning them in individual channels
<nightwish> arrrgh sorry seems my irc client is buggy. this msg shouldn't go to people on freenode :/
<ogra> cjwatson, pfft, thats just because you didnt pay attention to his index finger when he said "this host"
<superdump> i think this may not be the right place to ask, but i was wondering whether the ffmpeg packages (ffmpeg, libav*, libswscale...) with the svn20090303 version name were taken from the 0.5 branch that we made or from trunk
<ScottK> siretart: ^^^
<superdump> oh, ok
<superdump> if siretart did it, i already know :)
<superdump> i didn't realise he managed ubuntu packages as well as debian
<superdump> it's good to have him hanging out in our irc channel, then we know what's going on
<superdump> thanks
<ScottK> Ah.
<cjwatson> lool: do you want an installer change to install libc6-vfp on armel?
<cjwatson> lool: if so, can I have something suitable for around line 564 of http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/ubuntu/annotate/head%3A/hw-detect.sh ?
<cjwatson> lool: alternatively, perhaps libc6-vfp should be seeded in minimal?
<lool> cjwatson: I'm happy you noticed, I don't have to tell you about NEW-ing it and selecting it in the installer then   :-)
<lool> cjwatson: It would be welcome to install it indeed; thanks for looking into that
<pitti> mdz: apport-collect> not right now, I'm afraid; I guess I can make it add an apport-collect tag if that helps?
<lool> cjwatson: Ok, will cook you something
<cjwatson> lool: I think it's probably simplest to put it in minimal, so I'll just do that. After that the hw-detect change would only be necessary if Debian wanted to have the same thing
<pitti> MacSlow: not sure what you are asking for?
<lool> cjwatson: It will work if you pull it in minimal; perhaps we wont need that next cycle though if we build everything vfp, in which case we'll have to think of reverting it
<cjwatson> right, but trivial
<MacSlow> pitti, you saw the screenshots, right?
<lool> Yes, just mentionning it for compleness
<cjwatson> lool: (NEWed as well)
<lool> thanks
<pitti> MacSlow: I did, but my bling-untrained eye can't see what you mean
<MacSlow> pitti, the nasty rectangle frame behind a GtkEntry-widget
<pitti> MacSlow: since those are very different dialog
<pitti> ss
<MacSlow> pitti, just focus on the GtkEntry-widgets in each screenshot
<pitti> MacSlow: oh, I see
<pitti> MacSlow: that's such a minor detail, I personally consider that more like a bug fix
<MacSlow> pitti, you should clearly see that the ones of libgksu have nasty "non-bg-cleared" frame
<MacSlow> pitti, so it would be accepted?!
<pitti> MacSlow: however, somehow you need to indicate which input field has the focus?
<MacSlow> pitti, the focus-ring is not touched by this
<pitti> MacSlow: looks fine to me
<pitti> MacSlow: I mean, fixing this after beta
<MacSlow> pitti, cool ok then
<mdz> pitti: nah, I was just curious if we could infer from the existing data
<pitti> mdz: in theory yes, but not with a simple LP search
<pitti> mdz: such a bug would have a Dependencies.txt attachment added after several comments were already made
<pitti> mdz: i. e. it can be told by looking at the activity log
<pitti> mdz: I guess it's possible to craft a custom SQL query
 * pitti hugs mvo
<Riddell> jdstrand: there's a patch on bug 308060 now, can you check if that looks like it fixes the issue you had?
<ubottu> Launchpad bug 308060 in libmsn "Include libmsn in main" [Medium,Confirmed] https://launchpad.net/bugs/308060
<jdstrand> Riddell: sure
<Bester_Penner_fo> please help with your clicks: http://change.pennergame.de/change_please/8610636/
<Bester_Penner_fo> http://change.pennergame.de/change_please/8610636/
<Bester_Penner_fo> please, it is important for me!!!!!!!!!!!!!!!
<Bester_Penner_fo> http://change.pennergame.de/change_please/8610636/
<superdump> :)
<cjwatson> beat me to it
<superdump> hehe
<ion_> :-)
<superdump> could still give him a ban in case he comes back
<superdump> depends on your policies
<liw> mvo, should Synaptic show the priority of a package, especially as modified by /etc/apt/preferences and pinning?
<cjwatson> they usually morph before coming back
<superdump> true
<cjwatson> I'll wait and see
<mvo> liw: it does not currently, but it would be nice to do it
<liw> mvo, ack; #52158 was the context, but shouldn't require attention from you rightn ow
<ScottK> cjwatson: I can confirm the powerpc gcc bug is fixed as another package that had the same ICE as qt4-x11 just built after I retried it.
<cjwatson> ScottK: oh good, I didn't know there was another one. What was that?
<ScottK> kde-style-skulpture
<ScottK> I had it on my TODO to replicate you change for that package, but just retried it instead.
<PecisDarbs> anyone ran into such bug in jaunty - put empty cd-rw in a drive and suddenly nautilus goes mad and trying to open itself for some 5 - 7 times, crashes, and tries again
<PecisDarbs> [   92.577853] nautilus[3962]: segfault at a346008 ip b1da755d sp b65cffc0 error 4 in libbrasero-media.so.0.1.1[b1d97000+1e000]
<PecisDarbs> uhhh ohhhh
<liw> mvo, looking at #76740 - I can see in the glade file that several of the dialogs are indeed missing window titles; should I add them and send you a patch (or branch to merge, whichever is easier for you)? or is it too late to fix this in jaunty?
<jdstrand> Riddell: assuming all the length calculations are correct, then yes it looks fine. Those calculations are a bit hairy to verify, but appear correct. I wonder if it would be easier/safer to error out if c2 is larger than c1?
<jdstrand> Riddell: that said, if this is the patch upstream wants, I have no problems
<Riddell> jdstrand: it's not by upstream, it's by one of us, hello agateau
<Riddell> 15:05 < jdstrand> Riddell: assuming all the length calculations are correct, then yes it looks fine. Those calculations are a bit hairy to verify, but appear correct. I wonder if it would be easier/safer to error out if c2 is larger than c1?
<agateau> hi
<agateau> jdstrand: what do you mean with "easier/safer to error out if c2 is larger than c1?"
<jdstrand> XMLSTR _tcscpy(XMLSTR c1, XMLCSTR c2)
<agateau> if c2 is larger, c1 will only contains the amount of char it can hold
<jdstrand> agateau: assuming the length calculation is correct
<agateau> jdstrand: true
<jdstrand> agateau: I'm not saying it isn't, I'm saying this code is a bit swirly and hard to verify :)
<agateau> jdstrand: i see what you mean :)
<jdstrand> agateau: not your additions, mind, just how it processes the string
<agateau> I would have been more confident if there was some unit test
<agateau> but I played a bit with msntest program
<agateau> and I have been chatting with a friend (who was surprised to find me on msn again) for an hour now
<jdstrand> agateau: so two things could be done-- you can simply write a '\0' at the end of the string, based on your length calculation or based on your calculation, error out
<agateau> so at least it does not introduce immediate crash
<agateau> jdstrand: my patch does write \0 at the end
<jdstrand> agateau: yes, I mean before that (ie, not in _tcscpy())
<jdstrand> then you could use strlen in tcscpy
<mvo> liw: too late for jaunty, because of the UI freeze
<jdstrand> agateau: that seems a bit weird though
<agateau> jdstrand: oh, you mean write '\0' at the end of the source string?
<jdstrand> agateau: yes
<liw> mvo, ack, then I won't work on the patch
<mvo> liw: but if you fix it in bzr or assign to you and tag later that would be cool
<agateau> jdstrand: that would be less invasive indeed
<liw> (now)
<jdstrand> agateau: it should already be there, so there shouldn't be a problem with normal strings
 * agateau looks at what it would imply
<agateau> jdstrand: the thing is: it means one has to take care of every call to _tcscpy(), and missing one call won't cause a compile error
<jdstrand> agateau: the other option is to not change _tcscpy at all and instead treat it like strcpy(), and error out if source is longer than dest, based on your calculations
<jdstrand> agateau: well, you are doing that anyway, aren't you?
<jdstrand> agateau: oh I see what you mean, bec you changed it, the compiler will blow up
<agateau> jdstrand: yes
<agateau> and I had to propagate the changes up to where i know the buffer size
<apw> pitti on the apport thing, i guess my point was that it all depends if there is a 1:1 correspondance from the type to the dialog or from the type to the tags
<apw> i was seeing the type as essentially the dialog to use, and would expect us to have more than one tag possible from that type
<pitti> apw: to both actually (well, currently anyway, since I had no reason to do it in any other way)
<apw> right its that way right now
<jdstrand> agateau: if you are confident that the patch introduces no regressions, I feel ok with it. the length calculation doesn't seem like it should be grossly off (if at all) and a 1 char heap overflow with jaunty's gcc protections would be very hard to exploit
<apw> but i was envisioning makeing the tag changable was the easiest way to fix it
<pitti> apw: if you are happy with the dialogs, and it's just a matter of tags, then it's easy to add a "Tags" field to the report object, that launchpad.py appends to the standard tags
<apw> i think the dialog had become changable dependant on the kernel error type anyhow
<agateau> jdstrand: in my (limited) testing it worked ok
<apw> we might want to say use Tags in preference to main tag or something
<apw> though i think we already have Tags adding tags as it were
<agateau> jdstrand: I am quite new to Ubuntu development, so I will let Riddell handle the rest
<pitti> apw: ah, indeed
<pitti> apw: gosh, seems apport grew too big for me to remember every impleemted detail :/
<jdstrand> agateau: perhaps think about what we talked about for a bit, then decide how to proceed. I'll leave the regression testing in the capable hands of Riddell, you and the kde team
<pitti> apw: so, apportcheckresume already adds that; shouldn't that suffice?
<apw> pitti, right now we have apport-oops and resume always on suspend or hibernate bugs
<apw> so we can tell them appart, i thought that someone other than
<apw> us had an issue with it being -oops or something
<agateau> jdstrand: yes, sounds wise
<pitti> apw: seems this was a misunderstanding then; mdz might have looked at older reports which didn't tag themselves with "suspend" yet?
<jdstrand> agateau: regarding all calls to tcscpy()-- keep in mind that tcscpy is only used by xmlParser.cpp, and libmsn just imported this file wholesale, so I think as long as you get everything in there, you would be fine.
<jdstrand> agateau: if that is the route you choose
<agateau> jdstrand: true
<mdz> pitti: it is possible to tell them apart,  but it's not always convenient
<tkamppeter> pitti, you are aware that the Apport hooks for printing do not capture the most important part due to permission issues? On all printing-related bugs I get CupsErrorLog: Error: [Errno 13] Permission denied: '/var/log/cups/error_log', ex: bug 345866
<ubottu> Launchpad bug 345866 in foomatic-db "Insufficient quoting of filenames" [Undecided,New] https://launchpad.net/bugs/345866
<mdz> pitti/apw: you can get all of the suspend/resume bugs by looking for apport-kerneloops+suspend, but you can't get all of the non-suspend kerneloops bugs
<mdz> (of which there will be many once kerneloops is working)
<pitti> tkamppeter: right, that's a bug in cups; we need to make the log files readable for the adm gruop
<apw> apport-kerneloops+resume
<tkamppeter> pitti, will this get fixed for beta, as with the beta we will probably get many testers and bug reports.
<pitti> tkamppeter: I'm not currently working on it (it doesn't even have a bug); -EOVERLOADED :(
<pitti> tkamppeter: can you please file a LP bug for it, and assign it to me?
<tkamppeter> pitti, which package
<pitti> tkamppeter: cups
<lool> cjwatson: I pushed libc6-vfp installation in hw-detect to lp:~ubuntu-core-dev/hw-detect/ubuntu happy if you can review it
<mdz> slangasek: I have a pretty bad feeling about 328035
<cjwatson> lool: thanks, looks fine aside from the "greq" typo :-) Fixed that
<mdz> like it will turn out to be the heisenbug which resurfaces post-RC
<cjwatson> lool: I don't think this needs to be uploaded pre-beta though
<mdz> and be an obscure kernel race condition rather than an X driver bug
<lool> Pff I suck
<lool> cjwatson: Fixed; no certainly not needed pre beta
<lool> oh no, you pushed
<lool> err bzr is really confused
<cjwatson> you need to use bound branches :)
<lool> It's fixed in bzr though
<cjwatson> I definitely beat you to it, bound branches wouldn't lie to me. P)
<cjwatson> :)
<tkamppeter> pitti, bug 345953
<ubottu> Launchpad bug 345953 in cups "Apport hook for printing does not capture CUPS error_log: Permission Denied" [High,Triaged] https://launchpad.net/bugs/345953
<lool> What'ss weird is that I don't see your revision in my local log after a merge
<cjwatson> you probably want to uncommit and pull again ...
<lool> But I do stand corrected and that's a point in favor of bound branches for the future
<pitti> lool: you can also rebase
<lool> pitti: Yes, I was surprized that this actually works fine
<lool> albeit I had this uncommit filed I added in a checkout once, but I'm not sure whether rebase or me broke it
<slangasek> mdz: yes, plausible that it's a kernel race; but only varying the X driver version has so far made the crashes disappear for me
<slangasek> pitti: acpi-fakekey: it will work in the specific case that the first keyboard device that acpi-fakekey tries to open is one that happens to have that hotkey in its keymap definition :-P
<slangasek> pitti: so yes, that's roughly equivalent to "completely broken", but on the off chance that it's not equivalent in practice, I'd rather just leave the junk there until we have it replaced
<pitti> slangasek: agreed
<pitti> slangasek: I was just curious about the state
<pitti> slangasek: a lot of those are hopefully obsolete with current kernels, but I don't know a good way to check which
<slangasek> buying more laptops... :)
<ScottK> Sending them to community developers for testing ....
<MacSlow> pitti, how do I get qa-team membership as fast as possible
<MacSlow> pitti, not being able to change the importance of bugs on the ubuntu-package of notify-osd is really hampering my triaging work
<davmor2> MacSlow: have a word with bdmurray maybe
<MacSlow> davmor2, yeah speaking with bdmurray  might be best
<MacSlow> bdmurray, can I perhaps get change-permission to alter the importance of the ubuntu-package notify-osd?
<MacSlow> bdmurray, I'm also the upstream lead and developer of this ... and having the ability to change importance-levels for this would speed up my bug-triaging work
<MacSlow> bdmurray, seb128 always (rightfully) complains I'm not fast enough with commenting/triaging bugs filed on notify-osd (in ubuntu)
<bdmurray> MacSlow: Are you familiar with apport crash reports and the private information that might be contained with in?  https://wiki.ubuntu.com/Apport
<MacSlow> bdmurray, nope
<bdmurray> MacSlow: As a member of Ubuntu Bug Control you'd be able to see private bug reports that are from apport crashes and may contain sensitive data
<bdmurray> MacSlow: here's a better link https://wiki.ubuntu.com/Bugs/HowToTriage#Apport%20crash%20reports
<bdmurray> MacSlow: so once you've familiarized yourself with that since you are an upstream developer I'd be happy to add you to the team
<MacSlow> bdmurray, ok after the call I'll read that
<calc> who should i contact to get my ppa quota bumped quickly? i hit the limit on my last OOo upload and it got rejected
<cjwatson> calc: #launchpad
<calc> cjwatson: ok
<shaya> vlc seems very messed up on jaunty
<shaya> none of the text in menus or dialogs displays correctly
<shaya> qt issue?
<directhex> shaya, when in doubt, blame qt/gtk bridge stuff
<cjwatson> lool: armel uninstallables just dropped from 201 to 62 thanks to libgnome
<cjwatson> I'll poke through a few other things I know about shortly
<clarc> hi
<clarc> would it be possible to put a new vlc version in hardy backports?
<Lure> would just like to point to kernel panic with today update (something to look into before beta): bug 339423
<ubottu> Launchpad bug 339423 in update-manager "Borked installation of latest updates in jaunty, now kernel panic on boot" [Undecided,Confirmed] https://launchpad.net/bugs/339423
<lool> cjwatson: wee!
<thiebaude> does anyone know when bug 304871 will be fixed?
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [Unknown,Confirmed] https://launchpad.net/bugs/304871
<mvo> Lure: could you please attach /var/log/apt/term.log (if you haven't alrady)?
<Lure> mvo: done that, but I did not have any apt-get issue, so I suspect problem is elsewhere
 * Lure thinks is it initramfs-tools or kubuntu-default-settings
<\sh> bah.../me runs into bug #329403
<ubottu> Launchpad bug 329403 in linux "Dont Boot After Installation on HP DL380GS" [Undecided,New] https://launchpad.net/bugs/329403
<maco> how long does apt-listchanges --apt $package usually take to run? i'm trying to figure out if this is "normal" or if i should go report a bug
<cjwatson> thiebaude: it came up in the release meeting, but there's no known fix at present and upstream are not responsive
<cjwatson> thiebaude: so it's being tracked at the highest level, but there's no ETA yet
<thiebaude> ok, cjwatson thanks
<DnaX> mpt: see this https://bugs.launchpad.net/emesene/+bug/345660
<ubottu> Ubuntu bug 345660 in emesene "Emesene Libnotify plugin don't check for actions" [Wishlist,Triaged]
<DnaX> update notify osd wiki page ;)
<mpt> DnaX, thanks, I saw that this morning but I didn't link to it from the spec because our preferred solution would be for emesene to integrate with the messaging menu instead
<\sh> cjwatson: looks like d-i + grub have some problems with /dev/cciss/ devices (intrepid wise)
<mpt> DnaX, we don't have docs on how to do that yet, but tedg and/or dbarth in #ayatana may be able to help you out when they're there
<cjwatson> \sh: file a bug
<DnaX> mpt: can you explain better "messaging menu"?
<\sh> cjwatson: someone did already bug #329403 I attached some more info files from /var/log/installer/
<ubottu> Launchpad bug 329403 in linux "Dont Boot After Installation on HP DL380GS" [Undecided,New] https://launchpad.net/bugs/329403
<cjwatson> \sh: there are some known things that are fixed in jaunty, but I won't be able to tell whether your problem is one of them without checking
<cjwatson> \sh: please do NOT attach additional information to existing installer bugs; instead, file a new bug
<cjwatson> \sh: it is more work to untangle multiple issues from one bug than it is to mark duplicates
<\sh> ok...I'll file a new one :)
<mpt> DnaX, the menu that shows up in Jaunty when you're running Evolution and/or Pidgin, and has items for each person who's messaged you recently
<mpt> DnaX, huh, from the screenshot on <http://dnax.netsons.org/rendere-emesene-compatibile-con-notify-osd> I see that the old notifications didn't let you reply etc anyway.
<mpt> oh, I see
<mpt> clicking anywhere on the bubble let you reply
<mpt> so just removing that function would be a bit of a regression
<johanbr> DnaX: http://bugzilla.gnome.org/show_bug.cgi?id=574744 has some information
<ubottu> Gnome bug 574744 in General "Empathy could take advantage of the Messaging Indicator" [Minor,Unconfirmed]
<DnaX> mpt: you say? uhm...
<DnaX> i don't know how integrate emesene with fast-user-switch indicator...
<\sh> cjwatson: bug #346001 ... error is already seen in grub-.log
<ubottu> Launchpad bug 346001 in debian-installer "[Intrepid] HP DL36xx + Smartarray , no boot after installation " [Undecided,New] https://launchpad.net/bugs/346001
<cjwatson> the error in grub.log isn't interesting, didn't need that :-)
<cjwatson> it's just a symptom
<DnaX> mpt, johanbr: there is a python binding of libindicator?
<cjwatson> \sh: oh, this is your system that thinks it's dmraid when it isn't
<mpt> DnaX, I'm sorry I don't know the technical details, you'd need to chat with tedg or davidbarth when they're back on Monday (or post to the ubuntu-desktop@ mailing list)
<johanbr> DnaX: kind of... https://bugs.launchpad.net/indicator-applet/+bug/343837
<ubottu> Ubuntu bug 343837 in indicator-applet "libindicate needs python bindings" [Undecided,New]
<mpt> ah :-/
<\sh> cjwatson: yes...but I got rid of it...now it's only the grub...and it fails also from cd
<DnaX> johanbr: good...
<cjwatson> \sh: you did, but grub-installer doesn't realise you did
<\sh> cjwatson: oh...cool
<cjwatson> I hate dmraid
<DnaX> mpt: so... my patch can't be accepted?
<\sh> cjwatson: any quick fix that I can try out?
<cjwatson> \sh: wait
<\sh> cjwatson: well, it's funny..because actually it's a raid but hardware raid ;)
<cjwatson> \sh: yeah, but it has metadata on it that dmraid thinks belongs to it
<cjwatson> apparently
<cjwatson> \sh: this is a bug, of course
<cjwatson> \sh: if you haven't already, please do file a bug on dmraid about the misdetection
<\sh> cjwatson: I can move the bug I filed to partman-dmraid or dmraid?
<mpt> DnaX, well it's a bit better than the status quo. :-) Not in Ubuntu for another week, unfortunately, because we're in beta freeze. But you could submit it upstream.
<cjwatson> \sh: no, I already moved it to the proper place, which is grub-installer
<DnaX> mpt: i've just submitted to upstrem ;)
<cjwatson> \sh: the misdetection is a separate bug, which should be filed on dmraid and investigated
<\sh> cjwatson: ok..I'll file another bug :)
<DnaX> too later for jaunty? :(
<cjwatson> \sh: do you need automatic installation support here?
<\sh> cjwatson: yepp :)
<cjwatson> \sh: netboot or CD or both?
<\sh> cjwatson: netboot
<cjwatson> bah, it'd have to be the hard one
<mpt> DnaX, I don't know sorry. You could try proposing it for Jaunty and see what happens.
<cjwatson> \sh: just 8.10?
<\sh> cjwatson: jepp...or actually I could use jaunty too...
<\sh> cjwatson: I just used 8.10 because of latest stable release...we need it for tomcat crap..and intrepid is the first one with a good tomcat6 packaging
<cjwatson> \sh: well, I'll get it fixed in jaunty, but this should do it for intrepid, I think:
<cjwatson> d-i partman/early_command string sed -i '/^if.*dmraid/s/; then/ \&\& false; then/' /usr/bin/grub-installer
<cjwatson> \sh: actually it'd be nice to have confirmation of that before I shove this into jaunty :-)
<cjwatson> (I'll use a slightly more sophisticated fix in jaunty that doesn't break dmraid, of course)
<\sh> cjwatson: give me a couple of mins I'll put this in my preseed and come back to you
<cjwatson> cool, thanks
<\sh> cjwatson: ok..installing :)
<\sh> cjwatson: btw...how can I disable apt-setup-udeb apt-setup/services-select multiselect security, which is set by default, and slows the preseed installation down, when there is no real internet connection...I tried to set it with an empty string, but it just waits there for security.ubuntu.com
<eeejay> hey DnaX, need python bindiings for libindicate?
<cjwatson> \sh: it must be something else that's waiting, then; setting that to empty does disable apt-setup's security generator
<eeejay> DnaX: did you get hold of the bzr branch?
<cjwatson> \sh: from your logs, it's a much earlier point
<DnaX> eeejay: i'm not a python developer... but my knowledge is sufficient for a small patch :P
<eeejay> DnaX: a small patch for what?
<cjwatson> \sh: you could set apt-setup/security_host (and apt-setup/security_path if necessary) to a local mirror of -security, or at least to something that will fail quickly
<DnaX> eeejay: Emesene
<eeejay> DnaX: ah, cool.
<DnaX> eeejay: bug #345660
<ubottu> Launchpad bug 345660 in emesene "Emesene Libnotify plugin don't check for actions" [Wishlist,Triaged] https://launchpad.net/bugs/345660
<DnaX> eeejay: however I will try bzr branch
<\sh> cjwatson: it comes before the udeb loading...
<LordKow> hey is it possible to get some pidgin 2.6.0 fixes backported to pidgin 2.5.5? it involves a memory leak.
<cjwatson> \sh: right, the apt-setup/security_{host,path} hacks should take care of it
<\sh> cjwatson: cool...ok..going into lab and checking installation
<LordKow> bug 345774
<ubottu> Launchpad bug 345774 in pidgin "AIM buddy list unavailable window repetition" [Low,Confirmed] https://launchpad.net/bugs/345774
<LordKow> fix available from upstream, requires a backport from their current devel branch (2.6.0).
<\sh> cjwatson: good news...that worked :)
<cjwatson> great
<cjwatson> I'll get a proper fix into grub-installer
<\sh> cjwatson: cool :) and thanks for the quick fix :) now I can install some more machines in no time :)
<DnaX> mpt: XD released https://bugs.launchpad.net/bugs/345660
<ubottu> Ubuntu bug 345660 in emesene "Emesene Libnotify plugin don't check for actions" [Wishlist,Fix released]
<\sh> cjwatson: btw...dmraid bug #346011 with reference to #346001
<ubottu> Launchpad bug 346011 in dmraid "dmraid recognizes raid signature on hp smartarray" [Undecided,New] https://launchpad.net/bugs/346011
<mpt> impressive
<cjwatson> \sh: ok, thanks
<\sh> cjwatson: anyways...thx a lot for the quick fix :) 10 new test servers installed in no time :)
<\sh> and now...weekend time :)
<cjwatson> good stuff
<cjwatson> lool: ok, I think I've now done something about almost all the armel uninstallables, and at any rate all of the ones I expect you to care about
<cjwatson> it'll take a few hours for all the builds to churn though
<ScottK> cjwatson: Do you have any hints for easily figuring out why something is uninstallable on an arch one doesn't have access to?
<cjwatson> ScottK: chdist
<ScottK> cjwatson: Thanks.
<cjwatson> it's great, once you have it set up you do 'chdist apt-get jaunty-armel install <foo>'
<cjwatson> absolute godsend
<ScottK> That sounds like what I've been looking for.
<cjwatson> or even build-dep rather than install
<ScottK> For build failures the logs are reasonably useful.  But for install failures, I hadn't found anything.
<cjwatson> you still have to drill down in the usual way with apt-get, but it no longer takes an eternity of staring at the screen
<siretart> superdump: in fact, the ubuntu ffmpeg packaging is even in the debian pkg-multimedia git, because that's easier fo rme
<superdump> siretart: :)
<slangasek> pitti: interested in your opinion on bug #345531; do you think that's something we should try to get into powerdevil+gpm for jaunty, or should we restore the acpi-support bits that act on the ACPI events instead of the key events?
<ubottu> Launchpad bug 345531 in acpi-support "fn keys for backlight (brighness) not working : geforce 8 card on sony vaio" [Medium,Confirmed] https://launchpad.net/bugs/345531
<shaya> has anyone tried to build vlc from source?
<shaya> it tries to run itself in the installation and fails due to running as root
<shaya> heck, not even root as rebuilding it in fakeroot
<slangasek> shaya: seems to be up-to-date in the archive across 8 architectures?
<shaya> then I don't know how you build it
<shaya> fakeroot dpkg-buildpackage fails
<slangasek> well, not like that at least
<slangasek> 'dpkg-buildpackage' alone
<infinity> shaya: dpkg-buildpackage -rfakeroot is what you want.
<shaya> http://pastebin.com/m6634164d
<slangasek> -rfakeroot is now the default
<infinity> shaya: "fakeroot dpkg-buildpackage" does the whole process as (fake) root.  "dpkg-buildpackage -rfakeroot" only does clean and binary-* as (fake) root.
<shaya> ok
<shaya> makes sense I guess
<shaya> I guess I need to get out of my old 90s methods :)
<shaya> trying to figure out this
<shaya> this is vlc for me
<shaya> http://yucs.org/~spotter/vlc.png
<slangasek> mvo: in this update-manager change to no longer account for space for initrd .bak files, won't that potentially bite us if the kernel is upgraded before initramfs-tools on dist-upgrade, or do you already account for ordering elsewhere?
<slangasek> mvo: (the kernel package deps don't enforce this, for sure)
<gnumm> hi
<gnumm> are ubuntu package maintainer here?
<dtchen> generally, yes, though you may find your question more succinctly addressed in #ubuntu-motu
<gnumm> ok
<Turl> hi
<Turl> is the new splash screen final?
<Turl> usplash, I mean
<slangasek> to the best of my knowledge, it is
<Turl> :S
<Turl> it's completely unpretty
<slangasek> superm1: do you know whether nvclock 0.8b4 would be appropriate to suck in from Debian for jaunty?  It appears there are some compatibility fixes there with newer hardware
<kklimonda> anyone know what's going on with virtualenv ?
<kklimonda> i can't get it to work in jaunty with python 2.6
<lool> cjwatson: thanks a lot
<calc> anyone know if bug 256058 is actually a bug?
<ubottu> Launchpad bug 256058 in freetype "Fonts not rendered correctly in OOo - Times New Roman looks bold above 13pt" [Medium,Confirmed] https://launchpad.net/bugs/256058
<calc> i can't tell if it is a hinting bug or an issue with stem width?
<thiebaude> calc: a couple of people were talking about extra large font like 13.3
<calc> thiebaude: this is a different issu
<calc> thiebaude: http://launchpadlibrarian.net/21512305/bug256058.png
<thiebaude> calc: i see what you mean
<calc> http://launchpadlibrarian.net/16642799/openoffice_fonts.jpg is another example of it
<thiebaude> it's different bug then what i was saying
<calc> compared between gutsy and hardy
<calc> i saw the 13.33 bug myself a few days ago
<thiebaude> ok
<RainCT> uhm.. isn't notify-osd supposed to pause the timer when the icon is above a bubble?
<RainCT> ah, there's a bug about it
<slangasek> mdke: do you have moderator access on ubuntu-doc?  you might want to let through the latest notice regarding a UI freeze exception :)
<slangasek> kees: need an MIR opinion on nvclock
<slangasek> (an initial impression)
<kees> slangasek: #?
<slangasek> kees: we have smartdimmer in main, which is an old fork of some code from nvclock that's pulled in by acpi-support; it's stale and doesn't work on current nvidia-based laptops
<slangasek> kees: no bug yet
 * kees fetches
<slangasek> kees: so we can fix this bug by killing off the smartdimmer source package, merging the new upstream version of nvclock from Debian, building a new smartdimmer binary package, and yay
<slangasek> nvclock is currently in universe, so y'all are the first stop :)
<kees> right, reading through it now
<kees> it has a pile of lintian warnings, but it is being maintained (updated Feb 20th).  Perhaps we could pull it before it goes into main?
<slangasek> "pull it" --> "do the merge first"?
<kees> yeah
<kees> it'd be nice to clean up the lintian warnings too.
<ilowe> where can I read about the build process for the official livecds?
<slangasek> could do; requires two uploads instead of one then, since that implies not hijacking the smartdimmer binary initially
<slangasek> but if that's you're preference, I'll get started there
<ilowe> I found the Debian/Live project but I'm looking for the Ubuntu-specific stuff
<kees> I think that would be a good way to go -- the more recent one closed several Debian-reported bugs.
<kees> oh goody
<kees>   * Update 01_fix_buffer_overflow dpatch.
<kees> I was just going to say that the code looked a little scary
<slangasek> :)
<kees> in what context does this run?  as the user or as root?
<slangasek> kees: rooty
<slangasek> twiddling hardware, nom nom
<slangasek> there's no unsanitized user input to it, though
<slangasek> (when running as root)
<kees> yeah, was trying to make that determination
<slangasek> it's not suid, currently nothing /at all/ invokes it by default; cf. bug #345531, asking for the smartdimmer integration to be readded to acpi-support for jaunty
<ubottu> Launchpad bug 345531 in acpi-support "fn keys for backlight (brighness) not working : geforce 8 card on sony vaio" [Medium,Confirmed] https://launchpad.net/bugs/345531
<slangasek> yuck, why does that buffer_overflow patch take 122 lines to fix a single buffer overflow :P
<kees> slangasek: yeah, I think if this got general packaging cleanups, I think it would be in a "supportable" shape.  I would +1 it after a merge, standards update, and misc fixes to get rid of the various lintian warnings.  they all look trivial, but annoying to have in main.
<slangasek> ok
<kees> slangasek: trailing white-space updates.  ftl
<slangasek> kees: haha, the lintian warning about "menu-item-creates-new-section" refers to menu-policy 2.1, where nvclock-gtk is given as an example for one of the sections \o/
 * kees holds his face
<directhex> http://farm3.static.flickr.com/2373/2048486298_2a6444b4c2.jpg ?
#ubuntu-devel 2009-03-21
<emma> Hi.
<nhandler> Hi emgent
<nhandler> * emma
<emma> Out of curiosity how come ubuntu comes with pulseaudio but not with pavucontrol ?
<emma> hi there nhandler
<nhandler> Well, for one thing, pavucontrol is in universe.
<emma> nhandler: have you also found that pulseaudio is fragile and difficult to understand?
<emma> maybe it isn't working correctly because only some of its components are installed?
<emma> (I don't really know. I'm just trying to figure it out)
<nhandler> emma: I really don't play much music/movies, so I don't deal with pulseaudio much. I'm also on a live cd right now, so I haven't had a chance to see how it is in jaunty
<emma> That's cool.
 * calc gets to learn git today
<calc> apparently gnome switched to git, so ooo-build did as well and moved to freedesktop.org in the process
<emma> nhandler: There are some applications that are going to touch upon the ordinary users experience so much that I think in order to make Ubuntu a consistently attractive product, they really need to be given special attention.
<TheMuso> calc: Yeah I think we need someone from the kernel team like apw to give a good git session at UDS etc, since he knows it extremely well.
<calc> TheMuso: yea that would be helpful i think
 * calc is finally happy with his OOo bug numbers now: 87.56% 84.98% 98.62%
<calc> asac: should i tag bug 341940 as RC, you mentioned something about it might should be RC when i filed it originally...
<ubottu> Launchpad bug 341940 in network-manager-applet "Ericsson F3507g - name displayed very long in nm-applet" [Undecided,New] https://launchpad.net/bugs/341940
<calc> asac: also bug 341803 is still marked incomplete but i think i provided all the parts you wanted?
<ubottu> Launchpad bug 341803 in network-manager "Ericsson F3507g - reports 3 mobile broadband connections" [High,Incomplete] https://launchpad.net/bugs/341803
<calc> is there a known issue with nautilus on live cd spawning windows infinitely
<calc> pitti: ping
<calc> pitti: is bug 325973 supposed to happen immediately on boot of a live cd?
<ubottu> Launchpad bug 325973 in nautilus ""Starting File Manager" windows open uncontrollably" [Unknown,Fix released] https://launchpad.net/bugs/325973
<calc> pitti: i saw you intending to release beta with this bug and wanted to make sure you realize at least some people see this on a completely stock boot of a live cd
<calc> pitti: some people including me ;-)
<calc> pitti: according to that bug show_desktop needs to be disabled for the bug to show up, is that default behavior now on the live cd's?
<slangasek> hrm.  is there a way to push a stacked branch on LP that has a sane point of reference to the LP branch it was based on, instead of the original import branch?
<wgrant> slangasek: --stacked-on http://bazaar.launchpad.net/~path/to/branch
<slangasek> ah
<wgrant> (note that that will only work for public branches)
<slangasek> yeah; I hadn't had much luck finding the right syntax
<slangasek> since there are so many ways to refer to LP branches, and none of the others seem to work. :)
<wgrant> lp: won't work because it's probably resolved client-side.
<wgrant> bzr+ssh: won't work because it requires auth.
<slangasek> heh, of course, now that I try it bzr tells me the source branch doesn't support stacking
<wgrant> That's fine.
<wgrant> Or should be.
<slangasek> bzr: ERROR: KnitRepository('http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/.bzr/repository/')
<slangasek> is not compatible with
<slangasek> KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Evorlon/hal/lp.277589/.bzr/repository/')
<wgrant> Woah.
<wgrant> That is one old repo format.
<wgrant> Is there a good reason for that?
<slangasek> because I don't know how to upgrade it ;)
<wgrant> bzr upgrade lp:~ubuntu-core-dev/hal/ubuntu
<slangasek> won't that upgrade it to the bleeding edge by default?
<wgrant> No - 1.6 at most, IIRC.
<wgrant> But let's see what's defualt now.
<wgrant> pack-0.92 is the default.
<wgrant> So anything >= bzr 0.92 can read it.
 * slangasek tries 1.6 anyway, then
<wgrant> (this is Jaunty, with bzr 1.13~rc1)
<wgrant> 1.6 is what I usually use.
<slangasek> ok, this one seems to be working.  I tried upgrading my local branch earlier and it whined at me, dunno what that difference is
<wgrant> What was it whining about?
<slangasek> let's hope my laptop doesn't crash or anything before it manages to finish upgrading, I'd prefer not to be picking up the shards remotely :P
<slangasek> not knowing how to upgrade between format $foo and format $bar
<wgrant> If that breaks, you do need something like lftp, yes.
<slangasek> hmm, distinct lack of progress reporting :)
<wgrant> slangasek: Using Jaunty's?
<slangasek> yes
<wgrant> slangasek: Did it finish?
<slangasek> wgrant: nah, I was being too ambitious and trying to do --1.6.1-rich-root, and got a "Does not support nested trees" for my trouble
<wgrant> slangasek: rich-root is useless for your case.
<wgrant> (it's only needed for bzr-svn)
<slangasek> trying with --1.6 now
<slangasek> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack5>.  Does not support rich root data.
<wgrant> slangasek: Which repo are you converting? lp:~ubuntu-core-dev/hal/ubuntu?
<slangasek> yes
<wgrant> slangasek: What does it say the repo format is if you bzr info it? LP says Knits 3, but that doesn't do rich roots either AFAICT.
<t3rm1n4l> hi
<t3rm1n4l> is there a seperate google summer of code channel here ?
<slangasek> wgrant: Format <RepositoryFormatKnit3>
<slangasek> well, in the "is deprecated" message
<slangasek> after that, it says Standalone branch (format: unnamed)
<wgrant> I'm checking it out to have a look at it myself (though it's not the same copy you're looking at, unfortunately), but it's of course being very slow because it's knits.
<slangasek> if I ask the local branch, it says dirstate-with-subtree
<wgrant> So it does.
<wgrant> I just saw that.
<wgrant> That is the problem.
 * wgrant tries some things.
<wgrant> I can't upgrade dirstate-with-subtree to any format, but I *can* create a new 1.6.1-rich-root branch and pull into there.
<slangasek> https://lists.ubuntu.com/archives/bazaar/2008q3/046400.html
<slangasek> so that's the recommended approach, yeah (and I think that's what we had to do for the d-i repo when upgrading it)
<wgrant> Aha, exactly.
<wgrant> And then you have to work out how to clobber the LP branch.
<slangasek> yep
<slangasek> are you doing that, or shall I?
<wgrant> I'm not core-dev.
<slangasek> oh
<slangasek> then I guess I'll do it, won't I
<wgrant> I suspect so.
<wgrant> You might need an lftp to do it
<wgrant> As I don't think --overwrite will change the format.
<wgrant> But, hmmm...
<wgrant> slangasek: Do you recall how you did it with d-i?
<slangasek> the overwriting part?  not exactly
<slangasek> we may have just deleted the branch out of LP and pushed
<wgrant> Then you lose all the metadata and branch links.
<wgrant> s/branch/bug/
<slangasek> then we may not have done that
<slangasek> cjwatson: what was the trick to clobber the format of the d-i branch on the server when upgrading?
<wgrant> Without knowing better, I'd remove the remote .bzr and push with --use-existing-dir.
<slangasek> haha
<slangasek> Using default stacking branch /~vcs-imports/hal/main at bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/
<slangasek> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%7Evcs-imports/hal/main/.bzr/)
<slangasek> is not compatible with
<slangasek> KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/.bzr/repository/')
<slangasek> different rich-root support
<wgrant> Hahah.
<wgrant> --stacked-on= ?
<slangasek> trying
<slangasek> heh, actually, it created the .bzr before it failed, so it no longer wants to stack...
<wgrant> Convenient!
<slangasek> though it's still being awfully slow
<wgrant> I'm a little concerned that '--stacked-on=' stacks on the current directory.
<wgrant> I wonder if there is actually a way to force non-stacking...
<slangasek> nope, that's bug #328146 :/
<ubottu> Launchpad bug 328146 in launchpad-bazaar "Pushing a non-stacked rich-root branch to a project using stacked non-rich-root branches fails" [Undecided,Invalid] https://launchpad.net/bugs/328146
<wgrant> slangasek: Ah.
<wgrant> slangasek: Is the push working?
<slangasek> I restarted to fiddle; let me see
<slangasek> seems to be working, though slower than I expected
<wgrant> slangasek: You should probably get ~registry to unset the dev focus, as that's clearly not right any more.
<wgrant> Which will mean they won't autostack at all.
<slangasek> I don't follow you
<slangasek> you want the upstream branch to not be marked as 'development' as a workaround?
<wgrant> lp:hal is a vcs-imports mirror which is three years out of date. It's misleading, and it's causing the stacking problem, so it's good all-round to kill it.
<slangasek> oh, hmm, it is rather old isn't it
<cjwatson> slangasek: pretty sure we removed the remote branch
<wgrant> Since they moved to git, I presume.
<cjwatson> (d-i)
<slangasek> cjwatson: ok - so we just dealt with the loss of any bug metadata?
<slangasek> (and merge metadata)
<slangasek> s/merge/merge proposal/
<wgrant> There probably weren't BMPs back then to lose.
<slangasek> "back then" - it was in February... :)
<wgrant> Oh.
<cjwatson> slangasek: I don't think I cared that much about bug metadata on the Ubuntu trunk, no
<cjwatson> and I don't think there were any merge proposals at the time
 * slangasek nods
<wgrant> I wonder how many other dirstate-with-subtree branches there are around.
<wgrant> ~bzr seems to have liked to forget about that format - it's a dead end and isn't listed even in the legacy formats list.
<slangasek> hmm, new branch is there, wonder what it is
<wgrant> LP hasn't scanned it yet, apparently.
<slangasek>     repository: Packs 5 rich-root (adds stacking support, requires bzr 1.6.1)
<slangasek> and darn speedy to checkout, now \o/
<wgrant> Excellent,.
<wgrant> And now, you can stack on it!
<wgrant> Yep. Knits are awfully slow.
<cjwatson> dirstate-with-subtree was what you got when bzr-svn first arrived, I think
<cjwatson> so I suspect "several"
 * slangasek nods :/
<wgrant> :(
<wgrant> At least the conversion process is worked out now.
<slangasek> yes, it just requires patience :-P
<wgrant> LP still hasn't picked up the format switch.
<wgrant> Maybe it won't until there's a new rev.
<slangasek> but the initial investment was worth it, lp:~vorlon/hal/lp.277589 is light now
<cjwatson> the last time I tried to look at this across the board, I found bug 264902 and left a comment on it explaining that fixing it would be useful for this
<ubottu> Launchpad bug 264902 in launchpad-bazaar "Expose a person or teams branches through the launchpad api" [Medium,Triaged] https://launchpad.net/bugs/264902
<wgrant> It's also got a very strange error on it.
<wgrant> slangasek: What do you make of that scary-looking error on the branch page?
<wgrant> I had a similar one (but for file://) before, when I pushed a branch stacked on a local branch.
<cjwatson> is the "stacked on" meant to show the lp: bit? LP doesn't normally
<wgrant> cjwatson: It does.
<slangasek> wgrant: heh, apparently I stacked it on https: instead of http; it worked, but I should probably correct that
<wgrant> I filed a bug to make it do so.
<cjwatson> ah. yes, I see it does in some other contexts but not all
<wgrant> cjwatson: Those are regarded as bugs - I've filed a few, and they were fixed within a few days.
<cjwatson> e.g. https://code.edge.launchpad.net/~vorlon/hal/lp.277589 has "Branch: lp:~vorlon/hal/lp.277589" but the large-font title has "~vorlon/hal/lp.277589"
<wgrant> Ah. Hm.
 * wgrant hopes slangasek just deleted that.
<slangasek> yep
<slangasek> redoing with stacking against http to see if lp likes that better
<wgrant> It detected it fine, but wouldn't mirror. There's a bug there somewhere.
<cjwatson> right, armel uninstallables down to 48, almost all of those should disappear over the next couple of publisher cycles
<slangasek> yay
<wgrant> cjwatson: Is lpia super-installability entirely fixed?
<slangasek> wgrant: the page looks less errorful now?
<wgrant> slangasek: Indeed, but still not scanned.
<slangasek> sure
<wgrant> There we go.
<slangasek> do merge proposals automatically get emailed to the branch owner even if you indicate a different reviewer?
<wgrant> slangasek: They will be emailed to people subscribed to merge proposals.
<wgrant> slangasek: Check the first <select> on the core-dev subscription on the target.
<wgrant> By default the owner will get them.
<slangasek> so even if submitting a merge proposal and specifying a different reviewer, it'll spam people, bah
<wgrant> slangasek: Unless you reconfigure the subscription, yes.
<cjwatson> wgrant: super-installability?
<wgrant> cjwatson: Lack of shlibdeps.
<cjwatson> oh, right
<cjwatson> wgrant: doko was finishing up that work, I don't know how far he got
<cjwatson> wgrant: the worst things likely to infect other packages were fixed, though
 * mdz tears his hear out over 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
<slangasek> mdz: you're still seeing it then? :(
<wgrant> I see something like that most times that I switch VTs back to X.
<wgrant> (i915)
<wgrant> I once managed to see the original VT uncorrupted, and there was the tail of a traceback like that.
<mdz> slangasek: just reconfirmed this morning with the latest -intel
<mdz> wgrant: yes, it writes it out to /dev/tty so it ends up on some inconvenient VT
<slangasek> hrm, is there an explanation somewhere of what the subdirs of /usr/share/hal/fdi mean?  So I know which one a given file goes in
<mdz> I'd like to temporarily tell apport to dump a report for SIGABRT to make it easier to capture
<wgrant> mdz: I saw an upload from kees this morning that looked like it fixed that.
<slangasek> yes, xserver-core got a fix to capture those backtraces somewhere more useful
<mdz> oh, so kees is seeing this too?
<wgrant> https://edge.launchpad.net/ubuntu/+source/xorg-server
<wgrant> Note the last upload.
<mdz> yes, just saw it on -changes
<slangasek> kees is seeing other bugs
<slangasek> or was, before he upgraded
<mdz> where does stderr end up? the log?
<mdz> hmm, the gdm log
<mdz> I'm not seeing any errors there
<mdke> slangasek: ok, will check it out (ubuntu and canonical addresses should be whitelisted afaik)
<slangasek> mdke: might've come in from a kubuntu address, fwiw
<mdke> slangasek: ok, looks like someone has taken care of it
<slangasek> ok
<mdz> slangasek: were the circumstances of your crash similar to mine, i.e. the system had been suspended for some hours?
<slangasek> mdz: didn't always have to be a long suspend
<mdz> slangasek: as I've written in the bug now, a suspend/resume stress test failed to trigger it
<slangasek> I saw the same crash on any number of resumes of varying lengths, as well as when twiddling my video out
<mdz> slangasek: you're using the VGA output I assume?
<slangasek> mdz: yes
<mdz> I wonder what else is common
<mdz> slangasek: do you use Xvideo regularly?
<mdz> Xv I mean
<slangasek> I use it sometimes; I hadn't noticed any correlation with the crashes though
<slangasek> but that could just mean I hadn't noticed
<mdz> slangasek: what sort of input devices do you have attached?
<slangasek> mdz: I have a USB KVM that I use when I'm 'docked'.
<slangasek> I have seen crashes related to disconnecting the USB cable; as has kees I believe
<mdz> I have a USB X10 remote
<mdz> and at one point I suspected it was related, as I saw a crash when connecting it when no resume was in progress
<mdz> but I've never been able to reproduce a problem by repeatedly connecting/disconnecting it
 * slangasek nods
<slangasek> it's hard to even guess how many separate bugs we're dealing with here, since there haven't been good crash reports up to now
<mdz> slangasek: did you have any luck with valgrind?
<slangasek> I ended up downgrading the driver first and then looking at the toolchain
<slangasek> so never ran under valgrind
<mdz> slangasek: is there anything else you have changed along the way which may have affected it?
<slangasek> possibly; I tried to keep the changes to the driver isolated, but there may have been other packages upgraded in between restarts
<mdz> slangasek: anything other than upgrading? (as I've upgraded as well)
<slangasek> no
<Nafallo> damnit.
<Nafallo> mdz: I have that bug, as described in mdz's next to last comment.
<Nafallo> except I don't watch DVDs, and not sleep...
<mdz> Nafallo: always during resume?
<wgrant> It's VT switching, not always resume, for me.
<wgrant> And i can't reproduce by stress-testing either.
<Nafallo> mdz: yes. basically I suspend in one data centre, head to the next and on resume I have a GDM prompt :-/
<Nafallo> the usual applications I have open is gajim, terminator, firefox and thunderbird.
<Nafallo> so no DVDs or anything fancy like that :-)
<mdz> do any of you see [ 5381.180500] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1 ?
<mdz> (dmesg)
<mdz> I see that every time I switch VTs
<slangasek> no
<wgrant> I get that on all VT switches.
<mdz> bug 341363
<ubottu> Launchpad bug 341363 in xserver-xorg-video-intel "[i945GME] drm:i915_getparam *ERROR* Unknown parameter 6" [Low,Triaged] https://launchpad.net/bugs/341363
<Nafallo> [50311.489997] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<Nafallo> [50317.837740] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
<Nafallo> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<mdz> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<Nafallo> hmmm
<slangasek> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
<wgrant> 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
<slangasek> so maybe it's fixed now for the 945
<mdz> or not triggered
<mdz> Nafallo,wgrant: any unusual input devices?
 * slangasek nods
<wgrant> mdz: Synaptics touchpad + basic Microsoft optical mouse.
<wgrant> Only using LVDS, not VGA.
<mdz> Nafallo: are you docking or using VGA out?
<Nafallo> mdz: not that stays in the laptop when I suspend.
<Nafallo> mdz: neither. just using the laptop screen.
<mdz> I think at least some of the chatter on bug 315965 is about this bug
<ubottu> Launchpad bug 315965 in xserver-xorg-video-intel "[i965,jaunty] x server crash on resume from suspend" [Undecided,Confirmed] https://launchpad.net/bugs/315965
<slangasek> should I post a .deb somewhere of 2.6.3-0ubuntu2 built with gcc 4.3.2-2ubuntu14 for people to try?
<slangasek> (that's the toolchain originally used to build the 2.6.1-1ubuntu1 that worked)
<Nafallo> slangasek: that's the one that fixed it for you yes?
<slangasek> Nafallo: downgrading to 2.6.1-1ubuntu1 worked; rebuilding 2.6.1-1ubuntu1 with the current toolchain reintroduced the crash; upgrading to the current package fixes it again for me (so far as I've seen)
<Nafallo> slangasek: might be worth trying indeed.
<cjwatson> mdz: since you were concerned about it in yesterday's meeting: armel uninstallables are now down to 16, with three or four more due to disappear shortly, and the remainder are not a concern for the mobile project
<cjwatson> (16 in main, that is)
<mdz> cjwatson: great news, thank you
<cjwatson> fixing uninstallables is a bit like being a surgeon confronted with somebody covered in blood. Usually the actual problem is in a rather small number of places :-)
<slangasek> Nafallo: http://people.ubuntu.com/~vorlon/238035/
<mdz> ConnectBot on the G1 has turned out to be a very handy debugging tool
<mdz> I can walk around the flat with a live screen+gdb session in my pocket
<slangasek> :-)
<mdz> I'm running out of ideas for how to reproduce this blasted thing
<mdz> at least in Nafallo's case, it doesn't require leaving the system asleep for very long
<mdz> Nafallo: how long would you estimate between sleep and wake?
<mdz> I've done a few dozen VT switches and haven't been able to break it
<mdz> likewise for suspend/resume
<Nafallo> mdz: about 40mins to an 2h...
<Nafallo> that's just of the top of my head calculating on tube times fwiw...
<mdz> that's better than 8 hours, but still not very hopeful for analysis if it's part of the formula
<mdz> nafallo,wgrant: i386 or amd64?
<wgrant> mdz: i386
<Nafallo> mdz: x86_64
<mdz> wgrant: and your symptoms match 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
<mdz> the rest of us are all running amd64 I think
<wgrant> mdz: X crashes after VT switch and on resume, and I sighted a glibc stacktrace on one occasion. I think so.
<crdlb> hmm, am I the only one on radeon (RV200) with this bug?
<slangasek> crdlb: if you mean the bug described above, then you're almost certainly seeing a different bug with similar superficial symptoms
<crdlb> but it's identical; I even see the glibc bt sometimes
<slangasek> that's really not meaningful.  glibc has a generic error handler that generates backtraces when it detects memory corruption.
<crdlb> k, I'll file a separate bug then; it just seems like quite a coincidence
<mdz> if they are the same, that would be very bad news indeed
<mdz> I still have hope that this is isolated to the driver
<apw> cjwatson, the grub upload for jaunty.  will that trigger a grub-install automatically on upgrade from intrepid, does it need a release note or anything?
<maxb> grub package updates do not usually trigger grub-installs. IIRC Debian release-noted and NEWS-ed the last one that was required over there
<superm1> slangasek, can't say I know for sure.  i dont recall ever using nvclock
<asac> calc: can you please check your f3507g modem with latest NM bits from jaunty ... at least it should work now if you choose the right entry (out of the three). thanks!
<ubuntuNEWUSR> anyone help for me?
<ubuntuNEWUSR> i like the install windows driver for my belkin wireless G pcmci card with chipset Ralink RT2500
<ubuntuNEWUSR> anyone help for me?
<ubuntuNEWUSR> i like the install windows driver for my belkin wireless G pcmci card with chipset Ralink RT2500
<Mithrandir> ubuntuNEWUSR: ask in #ubuntu for support
<directhex> not only that, but ralink have a proper gpl driver
<delicowa> what exactly do we do here?
<ion_> Try to stay alive until successfully producing offspring, so that the species lives on.
<mdke> if an upload is done now while the archive is frozen, will it go through normally once it is unfrozen post-beta?
<DktrKranz> mdke, if you upload it now, it will stay in unapproved until approval and get processed automatically when beta freeze is over
<mdke> DktrKranz: great
<grom_> hey.  Is BlowFish have better security than AES?
<directhex> cool kids use double-ROT13
<grom_> ...
<magcius> Can we make more tools in Ubuntu use PolicyKit instead of gksu/gksudo?
<magcius> Or is that a GNOME decision.
<asac> magcius: its probably a patch decision ;)
<cjwatson> apw: what maxb said. Since it only affects people who've done manual filesystem changes anyway, and who would already have had to run grub-install on upgrade from <=intrepid, I'm not that worried
<magcius> asac, I'm not in favor of downstream patches.
<asac> magcius: i didnt talk about downstream
<magcius> asac, then what do you mean by a patch decision?
<cjwatson> apw: (i.e. intrepid's grub couldn't boot ext4 anyway)
<asac> magcius: i mean if someone provides patches its likely that upstream will accept them
<magcius> May I ask how gksudo is integrated into the system utilities?
<cjwatson> kirkland: ubuntu-virt-server is uninstallable on everything except amd64 and i386. Should the kvm dependency be removed except on those architectures, or should ubuntu-virt-server simply be built for only amd64 and i386?
<cjwatson> for the most part gksudo "integration" just consists of using it in a .desktop file, or in rare cases of a wrapper script that calls gksudo
<cjwatson> mostly we consider this a bug
<asac> magcius: i dont understand that question.
<magcius> cjwatson, thanks.
<asac> heh ok.
<apw> cjwatson, that makes sense.  thanks
<Adri2000> archive admin needed to sync weechat to fix an important security vulnerability, bug #342790~[4~[4~[4~[4~[4~
<ubottu> Launchpad bug 342790 in weechat "DoS crash when receiving a certain color code" [High,Confirmed] https://launchpad.net/bugs/342790
<Adri2000> s/~[4~[4~[4~[4~[4~//
<savvas> Does anyone know a python library / function that checks for user input, keystrokes and mouse clicks? I need to check if a user is idle :)
<slangasek> superm1: ok; was just asking because you TiL
<crazybyte> Hi! Perhaps someone knows. Is Ubuntu participating as mentoring organization at GSoC 2009? I cannot find it's listing anywhere. Thank you!
<pedahzur> Hello!  Pidgin versions less than 2.5.5 are reporting errors logging in to ICQ (see: http://www.pidgin.im/).  Since Hardy is still a supported release, is there going to be a backport of the Pidgin 2.5.5 package to Hardy?
<pedahzur> Shall I file a bug/backport request?
<pedahzur> Backport has been requested...nvm.
<pedahzur> I'll take than back...the backport request was marked invalid...I wonder why.
<jpds> pedahzur: bug number?
<pedahzur> jpds:  https://bugs.launchpad.net/hardy-backports/+bug/319547  I changed it with the comment that hardy was still supported.  Not sure if that was the right thing to do.
<ubottu> Ubuntu bug 319547 in hardy-backports "The version you are using is not supported by ICQ. Download a free authorized ICQ version from ICQ's official website." [Undecided,Confirmed]
<GuyFromHell> hey all, i'm trying to make a patch for a package but `debuild -S` keeps croaking on http://rafb.net/p/UYndq787.html
<GuyFromHell> although i can `echo "foo" | gpg --sign` properly and it says the correct key
<Mithrandir> don't worry about that, if you just want to create a patch you don't need to sign it.
<Mithrandir> though in general, make sure your entry in the changelog exactly matches what's on your key
<GuyFromHell> it indeed does :/
<GuyFromHell> I don't need it even if i'm patching a patch?
<GuyFromHell> or should i not even do that in the first place; just make a new patch..
<Mithrandir> patching patches is generally icky and it's more readable to just create a new patch
<GuyFromHell> I figured it out, my secret key was for "Name (comment) <email>"; not "Name <email>"
<GuyFromHell> alright, i'll try this again making a new patch instead; thanks
<Mithrandir> #ubuntu-motu might be a better channel for asking those kinds of questions, btw.
<cjwatson> Adri2000: done
<Adri2000> cjwatson: thanks
<slangasek> Nafallo: anything interesting testing that intel .deb?
<TheMuso> c
<davmor2> bryce: I got a wacom tablet for testing purposes.  I got everything working in intrepid (stylus, mouse & pad buttons)  I've since done a fresh install of Jaunty to test it out there.  Mouse sends the cursor over to the left of the screen and it doesn't move.  I'm assuming that the new driver doesn't like the setting I copied from here https://help.ubuntu.com/community/WacomTroubleshooting any clues on how to fix this
<zyga> hello
<zyga> I have found something that might be familiar to python developers using python3 and especially pydoc
<zyga> apparently our pydoc from python3.0 package is utterly bronken when generating module documentation
<zyga> a simple one-line patch fixes pydoc
<zyga> the sad thing is that nobody noticed this so late in python3000 process
<patapouf> Hi, I'm looking into some help to use autogen.
<jldugger> davmor2: i probably need to update my jaunty install, but last i checked wacom was workable
<zyga> it's even more ironic when you realize that 2to3 is actually automatically fixing it! :-(
<zyga> but anyway
<zyga> I'd like to share my patch
<davmor2> jldugger: to be honest it almost certainly is something I've done I'm just trying to figure out what :)
<zyga> http://pastebin.com/m600b85d7
<zyga> I'd love if someone push this all the way to upstream and everone else
<ArthurLiu> hi, http://socghop.appspot.com/org/show/google/gsoc2009/ubuntu ?!
<davmor2> jldugger: is your xorg.conf similar to the one in the link above?
<davmor2> jldugger: the stylus is amazingly accurate it only seems to be the mouse that is having issues
<jldugger> ArthurLiu: im told whoever applied withdrew their application
<jldugger> ive no idea who applied, but if it's been given to another project it seems unlikely it'll come back
<jldugger> ArthurLiu: consider it an opportunity to work very closely with upstream
<ArthurLiu> a lot of people are going to be really confused
<jldugger> why?
<ArthurLiu> well, you already had a few students at least interested
<ArthurLiu> someone should update the wiki page and send a notice on the soc mailing list
<jldugger> SoC is always a speculative thing; there's no guarentee that ubuntu would be accepted if it applied
<ArthurLiu> well, you *were* accepted this year
<jldugger> unfortunately, it seems that none of the ubuntu governance attempts to monitor SoC
<ArthurLiu> never understood that
<jldugger> its not quite clear who gets the money
<jldugger> i dont think you can cut a check to the ubuntu foundation
<ArthurLiu> you mean the 500$ ?
<zyga> doko: ping
<jldugger> 500 per student could mean 5000 or more
<ArthurLiu> well, if you *really* don't know, you can just give them back to the mentors..
<jldugger> im assuming that whoever (no clue who) applied on ubuntu's behalf decided they didn't have the time to mentor
<ArthurLiu> one "maria_r"
<ArthurLiu> "Maria Randazzo"
<jldugger> taking the 5000 and commissioning a mentor from MOTU or whatnot seems reasonable
<jldugger> no clue about tax but it seems like a nightmare
<jldugger> you would think the foundation would be a non-profit capable of handling this but i challenge you to find two foundation board members who have any idea the finances
<jldugger> ArthurLiu: im taken to understand the xorg.conf thing may not work the same anymore
<jldugger> somethin about HAL etc
<jldugger> and evdev
<BUGabundo1> question: everyone knows that most SiS HW sucks on most Linux distros, but I've seen a few working flawlessly (specially wired and wifi card, asac). could the drivers be fetch from those distros and improve ubuntu, or are most of those closed drivers handed over by the manufacture to the Distro?
<jldugger> doh
<jldugger> davmor2: im taken to understand the xorg.conf thing may not work the same anymore
<slangasek> ArthurLiu: what wiki page are you asking to have updated?
<directhex> BUGabundo1, core issue: nobody cares about SiS
<davmor2> jldugger: That's what I was thinking.  But how would you go about enabling the mouse part now then?
<BUGabundo1> I know that a Portuguese distro (CaixaMagica) based on mandriva is one example
<ArthurLiu> https://wiki.ubuntu.com/GoogleSoC2009 and https://wiki.ubuntu.com/GoogleSoC2009/Ideas
<ArthurLiu> that's a shame, there were some intriguing projects
<BUGabundo1> directhex: I guess.. I know it sucks too... but many pt users are getting this HW and can't use Ubuntu
<directhex> BUGabundo1, specific bugs help
<ArthurLiu> I suppose some of them could take refuge at Debian :)
<BUGabundo1> directhex: just let me get my hands on one, and ill file all you want! any thing specific ? I did file a few about wifi a few weeks back
<BUGabundo1> but the user/owner did what most SiS users do... post on LP or foruns and then move to another distro
<BUGabundo1> since nobody helps
<asac> usually other distros shouldnt be much better if the drivers are not there
<asac> unless its a special distro focussed on SiS or something
<asac> BUGabundo1: which distro are they moving to?
<BUGabundo1> most aren't
<BUGabundo1> I know that CaixaMagica works
<BUGabundo1> we have this student give way laptops (like OPLC)
<slangasek> ArthurLiu: ok. and where does the dangling link http://socghop.appspot.com/org/show/google/gsoc2009/ubuntu come from?
<BUGabundo1> I'll see if I can get some data from a livecd
<BUGabundo1> but since most wifi or wired cards won't either get an IP or if they do, not have network access
<BUGabundo1> its hard to post in real time
<ArthurLiu> slangasek, a page I hadn't refreshed, but I suppose that by know, there should be a dozen places over the internet linking to it
<ArthurLiu> it's been in the selected mentor organisation for 4 days..
<ArthurLiu> *list
<slangasek> ArthurLiu: hmm, ok.  Well, I'll check with the folks I know were wanting Ubuntu to participate and see if they know what happened.
<c_korn> hello. can someone review my patch for fast-user-switch-applet please? https://bugs.launchpad.net/ubuntu/+source/fast-user-switch-applet/+bug/345480/comments/7
<ubottu> Ubuntu bug 345480 in fast-user-switch-applet "Add an option to disable shutdown/restart/logout confirmation " [Undecided,New]
<ArthurLiu> I just found this :
<ArthurLiu> Ubuntu had applied and was accepted, but they have subsequently chosen not to participate in GSoC 2009. You can ask for details in #ubuntu on Freenode.
<ArthurLiu> Cheers, LH
<ArthurLiu> on the gsoc-discuss ML
<slangasek> oh, well, this isn't #ubuntu
<slangasek> maybe someone in #ubuntu actually knows more than I :)
<ArthurLiu> hum
<ArthurLiu> well, since nobody knows, everyone knows more or the same as everyone
#ubuntu-devel 2009-03-22
<calc> ugh i found a fun bug to fix for jaunty... debian bug 517782
<ubottu> Debian bug 517782 in openoffice.org "[openoffice.org] debianize and redistribute l10n extensions" [Normal,Open] http://bugs.debian.org/517782
<calc> it appears the naming of some myspell dictionaries are not lang_country which cause OOo 3.0 not to see them
<calc> at least someone else already found all the packages i have to fix
<bryce> hi calc
<calc> bryce: hi
<slangasek> calc: hrm, why is that not considered a bug in OOo itself?  TTBOMK, all other locale handling deliberately falls back to ll when ll_CC is unavailable.
<calc> slangasek: hmm perhaps it is a bug in OOo then i didn't know how that fallback worked
<calc> of course normally OOo doesn't even use system dictionaries it uses weird plugin crap for that, so the patch may just not be sufficient
<cjwatson> unexpectedly I can't find confirmation of this in 'info gettext', but I agree with slangasek - that's the way gettext works and that's the way I've made sure man-db implements it (one of the relatively few other bits of free software I'm aware of that needs to have its own locale handling)
<cjwatson> we only use country codes where necessary in the rest of Ubuntu, because for instance Austrians don't want to do all their de_AT translations independently, mostly they just want to reuse the German ones
<cjwatson> there are a few cases where it is necessary - the classic ones are pt vs. pt_BR and zh_CN vs. zh_TW
<calc> ok, i'll see if i can find the code that checks for the dictionary so i can make it fall back
 * calc wonders if this is in libhunspell or in OOo
 * calc wonders where in the 3gb of source code the dictionary selection code happens to be
 * calc thinks he found the code
<calc> looks like it should fall back to the language but it is using c++ operator overloading so it must be buggy somewhere
<cowbellemoo> Hyia all.  Can anyone recommend a good print manual for source management, compilation, and package creation for ubuntu?
<calc> hmm actually it looks like it doesn't use that part of the code, heh
<xxtjaxx> Hi guys I want to make a patch for the network manager that is constantly disturbing people along each and every new boot is somebody here who is involved in it?
<Ampelbein> erm... is http://launchpadlibrarian.net/24200096/buildlog_ubuntu-jaunty-amd64.seahorse_2.26.0-0ubuntu2~ppa6_FAILEDTOBUILD.txt.gz a problem with my package or with the build-farm? it complains that: After installing, the following source dependencies are still unsatisfied:gnupg2(still installed)
<cjwatson> Ampelbein: something in your build-depends pulls in gnupg2, which is then listed in your build-conflicts so it has no other alternative but to fail
<cjwatson> Ampelbein: seahorse Build-Depends: libgpgme11-dev Depends: libgpgme11 Depends: gnupg2. (The last bit is a recent addition; I haven't looked into why.)
<cjwatson> bug 305565 apparently
<ubottu> Launchpad bug 305565 in gpgme1.0 "kleopatra complains that gpgme should be compiled with gpgconf support" [Undecided,Fix released] https://launchpad.net/bugs/305565
<cjwatson> I've left a comment in that bug
<Ampelbein> cjwatson: ok, thanks for looking into the issue.
<cjwatson> I've also filed bug 346591 and marked it release-critical
<ubottu> Launchpad bug 346591 in seahorse "unbuildable due to fix for bug 305565" [High,New] https://launchpad.net/bugs/346591
<Ampelbein> cjwatson: i've looked into debian bug #407800 which was resolved by adding the build-conflicts. i will see if seahorse builds and works without it, since the code has been rewritten since.
<ubottu> Debian bug 407800 in seahorse "seahorse: quits when entering SSH passphrase then disables all subsequent" [Grave,Closed] http://bugs.debian.org/407800
<Ampelbein> i remember there being a conflict when both gnupg-agent and seahorse-agent are running. let's see... bug #217270
<ubottu> Launchpad bug 217270 in gnupg2 "seahorse does not recognize seahorse-agent/ssh-agent as a caching agent" [Low,New] https://launchpad.net/bugs/217270
<Ampelbein> and i think the build-conflicts is rather pointless without the appropriate conflict for gnupg-agent.
<UsamaAkkad> hello
<UsamaAkkad> http://paste.ubuntu.com/135186/
<UsamaAkkad> please check this , should I report a bug or it's just brainstorm
<calc> UsamaAkkad: bug report, i think the bug report should be worded such that when installing and network is available to ask user if they want to install updates at that time
<calc> UsamaAkkad: netinstall means something somewhat different and is already available without a gui
<UsamaAkkad> yes in the minimalcd
<calc> adding a gui to the netinstall cd would probably make it much larger
<calc> UsamaAkkad: where is the debian gui netinstall cd? last time i worked with debian it didn't have a gui one, but that was some time ago
<UsamaAkkad> http://www.debian.org/CD/netinst/
<UsamaAkkad> I talked on #debian and someone told me that it has GUI
<calc> wow they are huge
<calc> 180MB
<UsamaAkkad> yeah
<calc> debian does have a small iso as well but apparently its not mentioned on that page
 * calc thinks he remembers where those are
<JanC> IIRC debian's netinstall is larger than Ubuntu's anyway  ;)
<calc> eg http://ftp.debian.org/debian/dists/sid/main/installer-i386/current/images/netboot/mini.iso
<UsamaAkkad> by the way nice talking to someone that was in Debian team :)
<calc> that is equivalent to the Ubuntu net install iso i think
<UsamaAkkad> ok but you don't have equivalent to their 180 iso :)
<calc> http://ftp.debian.org/debian/dists/sid/main/installer-i386/current/images/netboot/gtk/mini.iso <- hmm that is interesting
<JanC> yeah, and seems like it's smaller than I remembered too
<calc> i wonder what that does
<calc> if that is really a gui netboot install then that would be a nice thing to have for Ubuntu as well i suppose
<JanC> calc: probably the Gtk frontend for debian-installer ?
<UsamaAkkad> yeah
<calc> JanC: yea maybe so
<calc> JanC: its only 15MB though which isn't bad
<calc> i had expected it to be much bigger
<JanC> I think it doesn't use X, just fb
<JanC> but I have to go to sleep, have to get up again in 2h   ;)
<UsamaAkkad> so do I have to report any thing or you will take care of it
<calc> wow yea its gui
<calc> UsamaAkkad: i don't do installer stuff so yes report it
<calc> UsamaAkkad: probably both as wishlist bugs
<vieq> calc, what he means replace Ncurses with ubiquity
<calc> cjwatson: ^ perhaps interesting ideas for installer
<calc> vieq: yea
<UsamaAkkad> the big netinstall iso and the live cd with network installation choice right?
<calc> i've worked on the installer for debian before but that was like 8 years ago, heh long time ago
<vieq> calc, :) old guy
<calc> vieq: :-P heh
<calc> i'm young enough that my first real *nix experience was with linux at least :)
<calc> it just happened to be 14 years ago, lol
<iulian> Hehe
<vieq> :D
<vieq> calc, seriously how much would it expand the minimal-cd
<vieq> I mean if ubiquity was added
<calc> vieq: looks like gtk for debian doubles the size of the i386 cd (~ 7-8MB extra)
<calc> not sure how big ubiquity is
<calc> however its also possible that it is ncurses to dissuade people from using it ;-)
<calc> since netinstall does use a lot of bandwidth
<vieq> it would be cool if the whole thing was like 30-50MB ISO
<calc> not more than a cd download but if people did it every time that way instead of sharing a cd then it adds up
<vieq> :|, yub
<vieq> thanks guys
 * calc is less than 1% away from 90% triaged :)
<TheMuso> /c/c
<UsamaAkkad> hello, I could not find the name of the installer while I'm trying to report a bug
<UsamaAkkad> what is its name
<RAOF> Ubiquity is the livecd installer; debian-installer is the alternate CD installer (I believe).
<UsamaAkkad> thanks
<zyga> doko: ping
<YokoZar> hmm, ubuntu-restricted-extras isn't installable from add-remove
<zyga> YokoZar: does it have desktop files?
<YokoZar> zyga: No it's there but when you click it it tells you to open synaptic
<YokoZar> zyga: probably because it depends on something that conflicts with libavcodec which comes by default
<Hobbsee> YokoZar: patches welcome.  I hear rumours about this every once in a while, but no one's done anything about it
<zyga> oh
<zyga> I think that having synaptic+add remove by default is a bad idea
<zyga> add/remove should be a syntaptics tab called "applications"
<YokoZar> most users should never open synaptic as it is
<zyga> but it's in the menu
<zyga> and you have to use it because add/remove tells you to
<YokoZar> the system administration menu
<zyga> especially when removing stuff
<YokoZar> the same scary place we put all the other tools people don't want to touch
<zyga> but they have to because add/remove is incomplete
<YokoZar> zyga: the fact that add/remove tells you to is a bug which is why I said hmm about it ;)
<zyga> fair enough
<UsamaAkkad> hello , I want to report a bug . it's read but can you take a  look at it before I post it
<UsamaAkkad> http://paste.ubuntu.com/135277/
<UsamaAkkad> *ready
<UsamaAkkad> and this report confused me
<UsamaAkkad>  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/154245
<ubottu> Ubuntu bug 154245 in ubiquity "Allow the user to skip installing updates during install" [Wishlist,New]
<YokoZar> UsamaAkkad: does the live cd session make an internet connection for you?
<UsamaAkkad> yes it can make
<YokoZar> Ubiquity won't even bother looking for updates if there's no network connection active I don't think
<YokoZar> In such a case it has to install as is and reboot before updates are viable
<YokoZar> But in the other case the point is well understood.
<podman99b> hey guys and gals... how long till ubuntu support n-trig multi-touch??
<UsamaAkkad> so I should go with reporting the bug right?
<Hobbsee> podman99b: please don't cross-post
<podman99b> soz... but some peeps are not in all rooms ... and all rooms seem relevant post... but +1 has my back. Thanks ne way and sorry
<UsamaAkkad> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/346682
<ubottu> Ubuntu bug 346682 in ubiquity "when installing and network is available to ask user if they want to install updates at that time" [Undecided,New]
<UsamaAkkad> calc, I've reported the firs issue :)
<maco> Hobbsee: up for a sponsorship?
<Nafallo> slangasek: so far so good. survived the night :-)
<UsamaAkkad> I want to report this bug too. any idea
<UsamaAkkad> http://paste.ubuntu.com/135295/
<cjwatson> UsamaAkkad: there is no need to report that
<UsamaAkkad> why
<cjwatson> UsamaAkkad: because it's already in progress and will hopefully happen for 9.10 if we can get all the libraries in order
<UsamaAkkad> nice , did  you see the other bug ?
<UsamaAkkad> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/346682
<ubottu> Ubuntu bug 346682 in ubiquity "when installing and network is available to ask user if they want to install updates at that time" [Undecided,New]
<cjwatson> yes, but it's not sensibly fixable
<cjwatson> a GUI netinst is a much more practical approach
<UsamaAkkad> mmm
<UsamaAkkad> it's reported any way. maybe someone will take care of it :)
<cjwatson> ubiquity, by design, installs the system by copying it file by file from the live CD; it doesn't install most of the system by installing packages
<cjwatson> installing updates in ubiquity would basically just mean installing the system and then running an upgrade
<cjwatson> and why bother, update-manager is much better at that
<cjwatson> it would be extra complexity in ubiquity for very little benefit
<cjwatson> if ubiquity were installing the updated packages from the network in the first place, that would be different, but it can't really do that. That isn't what ubiquity is for
<UsamaAkkad> yeah I see
<UsamaAkkad> thanks for taking time to look at these things
<cjwatson> Debian unstable's GUI installer, I believe, is currently broken for the exact same reason that made us be unable to do a GUI netinst for 9.04 ;-)
<UsamaAkkad> :)
<UsamaAkkad> which is?
<cjwatson> UsamaAkkad: it relies on the GTK directfb frontend, which isn't very well-maintained upstream and was completely broken in GTK 2.14
<cjwatson> sorry, GTK directfb backend, not frontend
<UsamaAkkad> thanks
<UsamaAkkad> can any one tell me what is missing from this bug report https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
<ubottu> Ubuntu bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Undecided,New]
<freddyav> Hi all! I'm sorry if this is a misplaced question; I'm looking at converting a 32bit app/lib to 64 bit and I would need some help since all I get is a seg fault. Where do I go for this kind of help> Please>
<frevi645> I tried to port a 32bit-only app & lib to 64 bit. Got is to compile and link and now I get this: http://pastebin.ca/1368040 Is there any way to get more information on what is going on??
<cardona507> hello?
<BUGabundo> question: what's the easiest way (aka nongeek) to add PPA keys to Softwares Sources?
<BUGabundo> question: what's the easiest way (aka nongeek) to add PPA keys ?
<BUGabundo> I use that
<BUGabundo> sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com
<BUGabundo> but can't keep telling new users to open a terminal and write that
<jdong> BUGabundo: there's a Software Sources GUI app in system->administration for a reason ;-)
<BUGabundo> should Software Sources have a field to enter key as well as PPA line?
<jdong> I believe it's a separate tab of the same application.
<BUGabundo> jdong I know about that.. but it doesn't have a way to enter a PGP key
<BUGabundo> just file import
<jdong> correct.
<BUGabundo> so back to my question: easiest way?
<jdong> the process of receiving keys is the job of the GPG utility :)
<BUGabundo> too apps its not easy
<jdong> frankly the easiest way is "open up a terminal and paste this:"
<BUGabundo> not for new users
<BUGabundo> I know!
<BUGabundo> duh
<BUGabundo> eheh
<BUGabundo> but Ubuntu is for Human Beings
<jdong> there's nothing "wrong" with opening up the terminal and pasting things you don't understand.
<BUGabundo> not geeks that love Terminator
<jdong> lol I used to work Windows TS and we did the same thing in Windows land.
<BUGabundo> jdong actually there is
<jdong> "ok I'm gonna e-mail me this .reg file, just double click it"
<BUGabundo> I teach my students not to do it
<BUGabundo> if they don't trust source
<jdong> lol from someone you trust.
<jdong> if you haven't established trust on how to add the repo you shouldn't be adding the repo in the first place :)
<BUGabundo> jdong we are breaking the webring of trust
<BUGabundo> there's no use for PPA signed keys
<jdong> PPA signatures are just for tamper evidence.
<jdong> I don't think there's much of a point apart from that
<BUGabundo> with an anoyning POPUP
<BUGabundo> ok.. filing a wishbug
<cjwatson> the reason for PPA signatures is to ensure that packets are not being tampered with in transit, which is useful
<cjwatson> BUGabundo: https://help.launchpad.net/Packaging/PPA has non-console directions
<cjwatson> every single PPA page links to that ...
<BUGabundo> cjwatson: I know! but the reason is that common Users should NOT have to use a terminal
<cjwatson> BUGabundo: did you read what I said, or the page I linked to?
<BUGabundo> opening
<cjwatson> it includes directions that do *not* involve using a terminal
<cjwatson> although as it happens the terminal directions are probably simpler :-)
<BUGabundo> 4 steps??
<BUGabundo> copy, paste into gedit (doesn't mention how to open it), save, import?
<jdong> sigh do we really need *TRUSTIFY ME NOW* buttons everywhere like impulse buying on Amazon? :)
<BUGabundo> not trust me
<BUGabundo> ... just a field to paste the key!
<BUGabundo> and then cross check with server
<jdong> your key came from launchpad via HTTPS anyway. What else is there to cross check?
<BUGabundo> already opened https://bugs.edge.launchpad.net/ubuntu/+source/software-properties/+bug/38781
<ubottu> Ubuntu bug 38781 in software-properties "Enh: confirmation dialog for adding an apt-key" [Wishlist,Triaged]
<BUGabundo> jdong well then why do we get a popup telling us, we don't trust it?
<BUGabundo> its either a bug of UI
<cjwatson> remember that anyone can create a PPA, including Dr. Evil
<cjwatson> so I'm not sure we want to make it too trivial
<BUGabundo> or apps not trusting what they should
<BUGabundo> cjwatson: having a field to paste *manually*
<BUGabundo> is not any unsecure then terminal paste
<cjwatson> I don't believe I used the word "secure", which would be a silly word to use in this discussion
<cjwatson> security is not a binary state
<BUGabundo> ok
<BUGabundo> sorry for assuming so
<BUGabundo> it should be Trust
<calc> does lack of binary packages cause something to be NEW?
<calc> if it drops a binary package i meant to say
 * calc will be dropping a couple of broken packages with his next OOo upload
<cjwatson> calc: no
<calc> ok
<cjwatson> calc: they won't vanish from the archive immediately though; they will show up in our not-built-from-source (NBS) listing
<calc> ok
<Nafallo> slangasek: so far three suspend/resumes without crashes.
<Pollywog> I am confused about how to specify debugging when building a deb, apparently this has changed. I am not certain which is correct, DEB_CONFIGURE_EXTRA_FLAGS:= --enable-debug or DEB_CONFIGURE_EXTRA_FLAGS+= --enable-debug
<Pollywog> and I have tried to find the information on my own
<cjwatson> Pollywog: unless DEB_CONFIGURE_EXTRA_FLAGS was previously set to something else, those two will have exactly the same effect
<Pollywog> cjwatson: ty
<cjwatson> see the documentation on setting variables in 'info make' for more information
<Pollywog> thanks I will do that
<Pollywog> I thought it was Debian-specific so I did not look there
<Pollywog> since it is part of debian/rules
<Pollywog> looking at it now
<cjwatson> DEB_CONFIGURE_EXTRA_FLAGS is a cdbs variable and so Debian-specific; the difference between += and := is just make syntax
<Pollywog> thanks
<maco> Keybuk: i hear you're the person to talk to about patches to util-linux
<Keybuk> maco: as in writing some?
<Keybuk> or wanting to apply some?
<Keybuk> or being blamed for some?
<maco> applying
<Keybuk> I can certainly take a look
<Keybuk> though you should probably get it upstream
<maco> ther's a bug with a patch attached to define HFS+ in fdisk
<maco> it's bug 318871
<ubottu> Launchpad bug 318871 in util-linux "fdisk: HFS/HFS+ Reports as unknown and not listed in partition information" [Wishlist,Triaged] https://launchpad.net/bugs/318871
<maco> is upstream for util-linux the same as upstream for linux
<maco> ?
<Keybuk> no
<Keybuk> I'll take a look at the patch on Monday, and submit it upstream if so
<Keybuk> need to make a package of git master anyway
<maco> ok
<Keybuk> ooh
<Keybuk> AJAX duplicate marking
 * Keybuk swoons
<maco> hahaha
<maco> now if only "you cant mark this as a dup, it has dups" would auto-resolve itself...
<directhex> tsk, AJAX
<ion_> AJAX the term sucks, but AJAX the functionality is for the win. :-)
<ion_> Except for the stupid restrictions for cross-domain requests.
<Keybuk> I always assumed it was a joke about flash
 * directhex dispatches war rocket Keybuk, to bring back its body
<Keybuk> flash and ajax are both kitchen cleaners
<directhex> i thought ajax was more of a bathroom scouring powder
<maco> er...AJAX is an acronym though....
<maco> (the not-cleaner AJAX)
<directhex> ajax is EVIL MICRO$HAFT TECHNOLOGY
<directhex> needs a good hard boycottin'
<Keybuk> why?
<directhex> well, teh micro$ofts! why else?
<Keybuk> :D
 * Keybuk hides his vista pc
 * ogra secretly injects a virus into Keybuk's vista PC while he doesnt look 
 * Keybuk secretly inserts a running chainsaw into ogra while he's not looking
<ogra> *Grin*
<Keybuk> give me a version of iTunes and Lightroom for Linux and I'll get rid of it ;)
<directhex> bloody hate itunes. still praying for a banshee port for windows
<calc> oh no, i just noticed (again) i have no way to see bugs that are not upstream (eg upstream == valid) that are triaged (ie bugs i need to fix myself)
<Keybuk> 1) banshee can't talk to my iPhone
<ogra> directhex, i doubt banshee can connect to the store
<Mithrandir> Keybuk: it can, if you flip a bit.
<Keybuk> 2) banshee is so abysmal that it uses 1.5GB of virtual memory, and brings my machine to a near halt, just to play a couple of tracks
<directhex> Keybuk, well there's your problem right there
<directhex> hm, problem 2 sounds odd
 * calc thinks he has a bug filed about this against soyuz perhaps i need to bump it up to critical
<calc> er launchpad not soyuz
<cjwatson> calc: YM a search that the advanced search page doesn't let you perform?
<cjwatson> calc: have you tried using the Launchpad API to do it?
<calc> bug 291968
<ubottu> Launchpad bug 291968 in malone "status_upstream=hide_upstream seems to hide bugs with 'invalid' upstream status" [Undecided,New] https://launchpad.net/bugs/291968
<directhex> someone who cares ought to start a "buy the guy who broke the last iTunes encryption crap an iTouch" fund
<calc> if you hide upstream bugs then even bugs that are marked invalid are hidden
<Mithrandir> Keybuk: http://iphonefreakz.com/2009/03/06/howto-sync-your-iphone-20-with-linux/ lets you at least sync from Linux.
<cjwatson> you could at least get a list of bug numbers that way and unblock yourself
<Mithrandir> whether you like the UI or not is something else, of course.
<Keybuk> Mithrandir: requires me to jail break the iphone, no?
 * Keybuk isn't doing that
<Keybuk> (though I did cheerfully upgrade it to a beta OS :p)
<Mithrandir> Keybuk: sure.
<calc> cjwatson: hmm i'll see if i can determine how to do it with launchpad api, thats just via python right?
<directhex> my banshee-1 process is marked as using 79.5 meg of rams right now
<directhex> so 3x less than firefox
<cjwatson> calc: right, with the python-launchpadlib package installed
<directhex> more than evo though. how sad
<cjwatson> it takes a bit of getting used to but I've found it insanely useful
<calc> cjwatson: ok i'll see what i can do with it
<calc> cjwatson: essentially with large numbers of bugs there is no longer a way via the website to determine which bugs are Ubuntu bugs and which are really upstream :\
<calc> for small numbers of bugs you can just look at them and see individually, heh
<directhex> you know, i've never run gnome-system-monitor on my altix. someone remind me to try it on monday, to see whether it tries to graph all 256 cores
<cjwatson> calc: you probably want to keep the launchpadlib-based query reasonably small just to make things easier, so you just need the search with status_upstream=hide_upstream, plus a search for bugs with invalid upstream tasks
<cjwatson> the latter via launchpadlib
<calc> ok
<calc> cjwatson: are there any example scripts for basic use of the launchpadlib?
<cjwatson> calc: help.launchpad.net/API, and try looking around in the ubuntu-dev-tools package or in ~ubuntu-archive/ubuntu-archive-tools/trunk for some random examples
<calc> ok thanks
<cjwatson> and indeed help.launchpad.net/API/launchpadlib specifically
<ruiserra> need help with a problem with a firewire camera. if someone can help me please
<nhandler> ruiserra: Try #ubuntu for support
<calc> wow i just had a discussion with a debian person who thinks the fact that Ubuntu is user-friendly is the main problem with it, lol
 * calc shakes his head, engrained elitism is alive and well in Debian it seems
<ebroder> Are there any particular rules for getting a package added to ubuntu-standard? I think that "patch" falls under the metapackage's description :)
<calc> ebroder: i don't see any developer tools in ubuntu-standard list
<calc> ebroder: i think its already pulled in by other things like dpkg-dev
<ebroder> *shrug* Ok. Maybe I have a skewed view of what a "comfortable command-line Unix-like environment" is. I can accept that
<calc> ebroder: you might want to install build-essential as well
<calc> ebroder: it pulls in a few other things that might be of use to you, devscripts as well
<ebroder> Sure - I have that on most of my machines, except the ones that I don't do dev work from
 * calc hardly ever uses patch when doing dev work
<calc> cjwatson: how do you get all the bugs for a given package in Ubuntu?
<calc> cjwatson: i'm not seeing the way to pull a bug list for a package but i might not be looking in the right place
<cjwatson> calc: get hold of the distribution_source_package object and then use getBugTasks on it
<cjwatson> (and then you can use .bug on each task if you like)
<calc> ok, looking for that now :)
<calc> ah launchpad.distributions["ubuntu"].main_archive
<calc> cjwatson: ok i found how to do the getBugTasks, but i don't see what you mean about .bug is that a method of some part of launchpadlib because i don't see it... do you mean iterate over the list and pass them to launchpad.bugs ?
 * calc is trying to make sure he doesn't end up doing something that gets him banned ;-)
<cjwatson> calc: well, for example:
<cjwatson> >>> man_db = launchpad.distributions['ubuntu'].getSourcePackage(name='man-db')
<cjwatson> >>> man_db.getBugTasks()[0]
<cjwatson> <bug_task at https://api.edge.launchpad.net/beta/ubuntu/+source/man-db/+bug/337302>
<ubottu> Ubuntu bug 337302 in man-db "FF exception: sync man-db 2.5.4 from Debian" [Undecided,Fix released]
<cjwatson> >>> man_db.getBugTasks()[0].bug
<cjwatson> <bug at https://api.edge.launchpad.net/beta/bugs/337302>
<calc> ah ok thanks :)
<calc> that cleared it up for me :)
<cjwatson> a package only has tasks attached to it, but in order to query whether there's an upstream task on a bug, you'll want to go from the package tasks to the main bug object
<calc> i forgot and tried dir on the whole object not on an item in it
<cjwatson> obviously be careful to iterate over the task collection in an LP-friendly way - I think the help.lp.net documentation makes some mention of iterating over large collections
<calc> cjwatson: ok
<cjwatson> once you have a bug object, there's a bug_tasks collection on that
<calc> is there a way to determine how many entries are in bug_tasks, or do you just have iterate across them?
<calc> len fails but that might be the wrong method
<TheMuso> cjwatson: over the weekend I noticed some weird errors with some ports arches and CDs not building. Tracking it down as far as I could, libcap1 is not ending up in the ship seed for ports arches.
<TheMuso> cjwatson: This was after running parts of cdimage locally to get germinate to do its thing to go through dependencies etc.
<TheMuso> However this is not for all parches, I think sparc still is getting built
<TheMuso> oh and hppa is building also. :p
 * cjwatson looks
<cjwatson> actually I think that's due to incorrect priorities
<cjwatson> see http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt
<TheMuso> I saw that, but couldn't work out from that why the supported arches build, but some ports arches don't.
<cjwatson> debootstrap thinks it needs libcap1 because it has Priority: important in the archive; cdimage's germinate run says that it doesn't need it so it doesn't put it in
<TheMuso> ah ok
<cjwatson> my guess would be that on some architectures libcap1 is still depended upon
<TheMuso> Right.
<cjwatson> ah yes, of course - libcap1 is only pulled into ship by dhcp3-server by ltsp-server-standalone
<cjwatson> and the seed entry is:
<cjwatson>  * ltsp-server-standalone [amd64 hppa i386 ia64 sparc] # for LTSP-on-install
<cjwatson> anyway, it's a clear archive overrides bug which I'll fix now, thanks
<TheMuso> np
<calc> cjwatson: do any upstream bug tasks always show up as bug_watches, even if they aren't linked?
<calc> cjwatson: i pulled using bug.bug_watches for 100 bugs and didn't it claimed none of them had status Invalid
<calc> oh crap remote status it the real remote status not what is show in the webpage
<calc> looks like bug_watches are just properly linked bugs
<calc> ugh
<calc> looks like there is no generic way to see what it considers to be upstream for purposes of revealing what hide_upstream hides from me
<calc> hmm actually looking closer i think i might be wrong
 * calc does a larger search for invalid upstream bugs
<yghannam7388> hello everyone, has anyone worked on a way to restore the Grub bootloader from the install CD? I think I might have a solution.
<RainCT> yghannam7388: not sure, but the alternate CD might have an option for this
<yghannam7388> RainCT: there was an idea on Ubuntu Brainstorm for developing a menu entry on the Ubuntu LiveCD to restore Grub. This would make it much simpler for most people. I'll check out the alternate CD and see if that is what is available
<thiebaude> dtchen: what is the kernal link again?
<thiebaude> o i got it
<dtchen> thiebaude: right, other channel, but for reference, also http://kernel.ubuntu.com/~dtchen/
<ii> Hi.  Been using Ubuntu since 5.10 and there's been a common problem of BADSIGs when running apt-get update until 8.10 ... forums always have a number of posts about this error.  I recently found a webpage with a solution that works first time and I was wondering if one of the developers can comment on whether it is a true solution or not.
<thiebaude> thanks
<ii> Wrong forum?
<ii> Hello?
<ion_> ii: Install ubuntu-keyring. If that doesnât fix the problem, the mirror is probably just syncing and you just need to run apt-get update later. And now please read the topic. And have some patience.
<ii> No, I'm not requesting support.
<yghannam7388> I just downloaded the alternate CD to see what it does to reinstall GRUB. You have to go to Rescue a Broken System, from there it loads up a lot of stuff before you can even get to restoring GRUB. What is proposed on Ubuntu Brainstorm is having a menu entry on the LiveCD that restores it very quicky.
<ii> ion_: On the following site: [http://parijatmishra.wordpress.com/2008/07/28/ubuntu-bad-signature-problems-prevent-apt-get-update-from-working/], it was suggested to delete the incorrectly signed Release and Release.gpg files (i.e. sudo rm -f /var/lib/apt/lists/partial/*Release*) - then run sudo apt-get update -o Acquire::http::No-Cache=true ... this has worked first time, every time for me.  All other solutions don't necessarily work first time.
<yghannam7388> So far I've been able to add Grub4Dos to the LiveCD and use it to restore Grub without having to load any thing else
<ion_> The real solution would probably be making the mirrors do syncs atomically and making apt-get redownload the lists along with their signatures up to a couple of times when signature checking fails.
<jldugger> bizaare
<jldugger> from the new svn release: "We now require SQLite to build both the server and client."
<yghannam7388> would anyone be interested in mentoring the "restore bootloader" for Google Summer of Code?
<ii_> ion_: Apologies if this is a duplicate but I just lost my internet connection for a few moments.  This mirror sync thing - is it being worked on?
<jldugger> yghannam7388: who'd be your organization sponsor?
<yghannam7388> jldugger: i haven't found anyone to sponsor the idea yet. the mailing list seems kind of dead so i decided to be more active in looking. i'm sorry if this isn't the right place to discuss this.
<jldugger> yghannam7388: last i observed, Ubuntu is not in the SoC as a mentoring project
<thiebaude> jldugger: ubuntu was approved for google SoC, but they dont want to participate this year
<yghannam7388> thiebaude: is there a reason why they don't want to participate?
<jldugger> "they"
<thiebaude> yghannam7388: i just remember seeing that somewhere on a canonical website, but i didn't see why they don't
<jldugger> yghannam7388: i think its safe to assume that if there's nobody willing to handle ubuntu's application as a mentoring org, there won't be many mentors around either
<jldugger> If there's specific technology you're interested in related to ubuntu and SoC, the Debian project may be a place to send your application
<Pollywog> I can't seem to get kmail to compile from deb-src with debugging symbols, even though in the debian/rules file I added DEB_CONFIGURE_EXTRA_FLAGS := --enable-debug=yes
<Pollywog> the format of the rules file has apparently changed in the past few months
<cjwatson> Pollywog: well, is that an option that kmail's configure script accepts?
<cjwatson> Pollywog: I think your error is in assuming that this sort of thing can be the same across all packages
<Pollywog> the normal (not Debian) configure accepts it
<yghannam7388> jldugger: i'm sorry if i seem stubborn about this, but Ubuntu applied and filled out an organization profile. There is also a couple of pages on the wiki about GSoC this year, and a number of people have posted ideas that they'd like to mentor for. is there any way to be sure that Ubuntu will not participate this year?
<cjwatson> the "format of the rules file" has not changed since sometime in the mid-90s
<Pollywog> kmail is in the kdepim package
<jldugger> yghannam7388: well, you could email the SoC and carbon copy the ubuntu community council ;)
<cjwatson> DEB_CONFIGURE_EXTRA_FLAGS is not part of the "format of the rules file" - it's an environment variable implemented by one particular reasonably popular set of helper build scripts
<Pollywog> well I formerly did this without any problems but since the kmail source was included in the larger package, I have been unable to do it
<Pollywog> ic
<Pollywog> I am trying to find some documentation but have been unsuccessful
<cjwatson> this stuff is in general not documented; the maintainer is expected to figure out how to enable things
<Pollywog> cjwatson: that explains it
<Pollywog> I will have to go to the ddebs then
<cjwatson> it's not something users are expected to change
<Pollywog> k
<cjwatson> kde4 uses cmake, not autoconf as far as I can tell, and thus I wouldn't expect DEB_CONFIGURE_EXTRA_FLAGS to be used
<Pollywog> cjwatson: yes but this is kde3
<Pollywog> I do not understand cmake so I am staying away from that for now
<Pollywog> I understand that things have changed with KDE4
<cjwatson> /usr/share/cdbs/1/class/autotools.mk is the make fragment that uses DEB_CONFIGURE_EXTRA_FLAGS
<cjwatson> AFAICT the upstream configure script shipped with kdepim 4:3.5.9-0ubuntu3 in hardy does provide an --enable-debug=yes option, but you'll have to trace through it to figure out what it's supposed to do
<yghannam7388> jldugger: i'm sorry, what do you mean by "carbon copy"?
<cjwatson> building a package from source typically produces verbose output that includes the configure options being passed (among many other things), and you're expected to read those when trying to track down problems
<cjwatson> if you use debuild, it'll be recorded in a .build file in the parent directory
<Pollywog> cjwatson: ty I think it would be easier for me to use the ddebs
<Pollywog> I have not used ddebs before but I found something to help me with it
<cjwatson> if all you need is debugging symbols and not a separate debugging build pass, then yes, that's what ddebs are for so you might as well if they're available
<Pollywog> thanks
<Pollywog> I am beginning to think developers are born, not made
<calc> cjwatson: btw thanks for the help earlier, i got my script working to show me the hidden bugs :)
<cjwatson> good stuff
<cjwatson> Pollywog: there's a component of talent/intuition/whatever and a component of learning/experience/whatever; it takes both
<cjwatson> like most skilled occupations
<Pollywog> so it would seem
<cjwatson> if you're looking into development-type things because you think it's fun, then you should probably persist even if you run into some roadblocks. OTOH if you're just doing it to solve an immediate need, then it's usually best to solve that need in whatever way is most expedient and move on to something you find more interesting ...
<Pollywog> cjwatson: yes I have the same problem in almost everything I try to do
<Pollywog> I understand that sometimes people do not have time to write documentation for beginners
<cjwatson> documentation is generally going to be focused on things we actually expect users to use
<cjwatson> (although of course documentation is lacking in many of those areas too :-/)
<Pollywog> I am one of those users who eventually wants to figure out how to do things most users don't want to do
<Pollywog> Sometimes this gets me into trouble  :)
<yghannam7388> jldugger: i'm sorry, nevermind that last message
<yghannam7388> jldugger: thank you for you help
<cjwatson> Pollywog: while cdbs is not very well-documented, the format of Debian packages is extensively documented; wiki.ubuntu.com/UbuntuDevelopment links to the policy manual etc. which describes this
<Pollywog> I have been looking at the wiki
<YokoZar> Hmm, I have two movie files of the same resolution and length, both encoded with h264 and ac3 audio, and both of about the same file size.  Both worked on Intrepid, but now one of them plays back really slowly.  This is a regression, but I'm not even sure where to start and file a bug
#ubuntu-devel 2010-03-22
<cousteau> hi, I've made a small program that fixes the numeric keypad functionality on laptops. I think it could be of interest for someone else so I made a .deb package, is there anything useful I can do with it?
<psusi> something seems really wrong with the way the kernel is handling pipes... tar -cf - > /dev/null takes 15 seconds... tar -cf - | cat > /dev/null takes 3 minutes, 15 seconds
<xnox> are .desktop for mozilla (e.g. Thunderbird) bet translated in Rosetta? or Suspended in Rosetta? or is it manual?
<xnox> s/ bet / get
<micahg> xnox: manual right now
<xnox> ok so I'll get the patch in then =)
<xnox> micahg, manual as in usuall mozillateam branches, right?
<micahg> xnox: yes, I need know though if we need a UIFe or FFe for it
<nigelb> micahg: my bet is neither
<micahg> we have some requests pending and I'd like to commit them if an exception isn't needed
<xnox> it's translation of a desktop file and it's not translation freeze yet AFAIK
<nigelb> robert_ancell: can you review the patch in bug 501054 and if not going to be integrated add your comments so I can reject the patch?
<ubottu> Launchpad bug 501054 in gcalctool "gcalctool 5.29 hides switch for display format in its settings window" [Low,New] https://launchpad.net/bugs/501054
<persia> micahg: If you're just adding translations, but not changing strings, you don't need a UIFe.  If you're changing strings, you need approval from the docteam.
<robert_ancell> nigelb, looking now
<nigelb> robert_ancell: thank you :)
<micahg> persia: so new ones are ok even though it displays something new in a foreign language?
<persia> micahg: Yes, because the *meaning* of the string hasn't changed.
<micahg> persia: ah, ok, great
<xnox> micahg, https://code.edge.launchpad.net/~dmitrij.ledkov/thunderbird/desktop.es/+merge/21824
<persia> For example, if a program is based in French, and someone adds a new English translation, that might change the screenshots for English documentation, but few people will complain, because they can now read it in their preferred locale.
<persia> *but* if the original French changed and broke all the translations, this annoys the docteam (who has to change) and annoys all the translators (who have to update).
<xnox> and annoys all people where docs talk about one thing and it's actually called something else in the software =)
<micahg> persia: what about adding to categories in Software Center?
<persia> I suspect that's enough of a change that you'd want to contact the docteam.
<persia> translations are a special case, and the langpacks get continually updated post-release, which leads me to believe that even post-release translations are acceptable (but take great care, as rebuilding code can change behaviour in unexpected ways).
<ebroder> Anybody from ubuntu-release that could look at bug #543888?
<ubottu> Launchpad bug 543888 in open-vm-tools "FFe: New upstream release of open-vm-tools" [Undecided,New] https://launchpad.net/bugs/543888
<lamont> so I burn a CD, and it ejects, and keeps on trying to eject until it says "oh, sorry.  I couldn't eject it - you'll need to do it manually" shortly after I finish labeling the disk that I removed when it initially ejected it... known bug?  and against what do I file it?
 * lamont guesses wodim
<RAOF> I recall a discussion in #u-kernel (?) about not locking the CD drive during normal use, and that cd writers would need to explicitly lock the drive.
<superm1> lamalex, https://lists.ubuntu.com/archives/kernel-team/2010-March/009315.html
<superm1> er lamont
<RAOF> Maybe wodim or whatever burning software you're using is confused?
<lamont> superm1: well, the burn finished fine, it says it's ejecting, ejects, and keeps on trying until it eventually decides that it has failed.  closing the tray during that time results in a re-eject, and still eventually gets to failure
<lamont> not particularly happy that the laptop locked up during the do-release-upgrade, either
<lamont> RAOF: almost certainly
<RAOF> It might be... interesting... to try ejecting the CD while it's being written.  No responsibility for superpowers gained by being hit by CD writing lasers is accepted.
<lamont> heh
<lamont> I wonder if I can get it to spit out the tray 4 times
<TheMuso> Isn't not locking the drive when a disk is mounted unsafe, in terms of copying data from the disk?
<TheMuso> although on the other hand, it does make sense.
<RAOF> The read will just fail, surely?
<persia> I think it's on;y unsafe for hardware that makes assumptions.
<persia> So for hardware that is either open or locked, there will be bugginess.  For everything else, it's probably better.
<persia> And I think there's only a small number of raised-lid readers without hardware eject buttons that might act like that.
<pitti> Good morning
<pitti> StevenK, persia: terribly sorry for the cdbs blunder, and thanks for handling that!
<persia> pitti: wgrant deserves most of the credit, really.
<StevenK> pitti: You're welcome ;-)
<pitti> superm1: checking for dkms sounds good; would that suit your use case, too?
 * StevenK wasn't expecting to get dragged into uploading a bunch of stuff on Saturday night
<pitti> wgrant: thanks a lot for handling the cdbs breakage!
<wgrant> persia orchestrated most of it.
<wgrant> Thanks StevenK -- sorry for dragging you away from whatever you were doing.
<pitti> lamont: hm, it seems jackfruit's http server hangs forever (noticed from hanging ddeb-retriever, but also reproducible with w3m)
<pitti> doko_: hm, does that directory have strange permissions?
<pitti> didrocks: so, Q-FUNK just pointed out that gthumb 2.11 is an unstable series, and not fit for release
<pitti> directhex: was there a pressing reason to upgrade to it? or should we downgrade to 3:2.10.11-3build1?
<pitti> sorry, didrocks ^
<directhex> moo?
<pitti> directhex: sorry, tab completion error
<Q-FUNK> pitti: actually, others that responded to my blog post pointed it out and, now that I'm taking pictures again, I cannot help but notice that it indeed is unstable, as in constant random crashes and features no longer working.
<Q-FUNK> pitti: it also seems ot be used as a sandbox for testing new UI paradigms.
<Q-FUNK> pitti: by the time something as simple as re-saving a JPEG as a PNG makes the application crash, I think that we can safely conclude that this is not fit for an LTS release.
<pitti> I agree
<Q-FUNK> pitti: just to be sure, I pulled a slightly more recent upstream from debian that supposedly fixes a lot of bugs, but it still doesn't.
<pitti> amitk: did you happen to see bug 427925? it seems that pm-powersave-policy's sata link power management doesn't actually work in a lot of cases?
<ubottu> Launchpad bug 427925 in linux "unable to modify scsi host link_power_management_policy" [Medium,Triaged] https://launchpad.net/bugs/427925
<amitk> pitti: I didn't. Thanks for pointing it out. I've passed on my work to Chase Douglas who will be carrying on futher work on pm-powersave-policy. I'll point him to it.
<pitti> amitk: thanks
<didrocks> Q-FUNK: pitti: the older one didn't work at all with the new udev/devicekit layer we have for camera detection. So, it was better than nothing. I saw that debian was going to package a new one (didn't check yet which version) a little bit better in term of stability. We should sync that one
<pitti> didrocks: hm, the old one had a patch to gvfs-umount the camera before talking to it through libgphoto
<didrocks> pitti: it wasn't working IIRC (I tried it with 3 devices before asking for sync)
<pitti> didrocks: hm, then perhaps we should restore that old patch; nothing changed wrt. gvfs/libgphoto since hardy
<pitti> udisks etc. is just underlying maic
<pitti> magic
<didrocks> pitti: can do that if you want. I have many crashy devices to test it :)
<Q-FUNK> didrocks: import works fine for me.
<didrocks> Q-FUNK: tried with 3 different devices, but I can revert the sync (or you can, if you want :))
<didrocks> Q-FUNK: just that it was crashing on 2 laptop with 3 devices at home
<Q-FUNK> didrocks: it's a bit more complicated than it appears.  we'll need to either introduce an epoch or end up with an ugly version number like pulseaudio.
<Q-FUNK> and the minute we introduce an epoch is the day we can no longer sync from debian.
<didrocks> Q-FUNK: avoid epoch, use newer-version.is.older-veresion
<Q-FUNK> here, the latest 2.10 works fine on all my hardware.
<didrocks> Q-FUNK: maybe I had bad luck with mine but I tried with a camera, a video recorder and a mobile phoneâ¦
<didrocks> Q-FUNK: I could see them in nautilus, but gthumb didn't import anything
<Q-FUNK> didrocks: that's a different bug altogether.   nautilus has incorrect import apps defaults.
<Q-FUNK> that was already reported... back in jaunty, IIRC
<didrocks> Q-FUNK: hum? I just told I can see the devices in nautilus, but not import using them in gthumb
<Q-FUNK> didrocks: yes, because nautilus prevents you from importing, with its default media application settings.
<Q-FUNK> its instance of libgphoto2 locks the camera
<didrocks> Q-FUNK: oh, that was the issue so, and how do you achieve that? you have to close nautilus (even when daemonize) to import with gthumb?
<Q-FUNK> here, getting this to work required two things:  1) pitti's unmount script that shipped with 2.10 2) changing the media application defaults in nautilus 3) purging gnome-mount 4) purging hal.
<Q-FUNK> right, make that 4
<Q-FUNK> actually, I cannot recall if purging hal was needed or not, but disabling anything else that could access libgphoto2, yes.
<didrocks> Q-FUNK: ok, understanding better now. Well, step 0 is to revert gthumb, I'm fine with this if we can workaround the importing from devices. Do you want to do it or that I do it?
<Q-FUNK> didrocks: can we work on this later this afternoon?  then we can compare notes about testing this and making possible changes to nautilus gconf keys as needed?
<didrocks> Q-FUNK: sure, ping me when you are ready to work on that with me :)
<Q-FUNK> didrocks: cheers! :)
<didrocks> Q-FUNK: see you ;)
<seb128> didrocks, was that discussion about downgrading gthumb?
<didrocks> seb128: right
<seb128> didrocks, why
<seb128> ?
<Q-FUNK> seb128: because it's totally unstable
<Q-FUNK> and because it's a development version that won't mature into a stable version on time for Lucid.
<didrocks> seb128: it's an unstable version, still a little bit crashy but no issue for me in one day. Apparently some people has crashes with it regularly. I looked with upstream who told me (when I decided to upload new version) that the new stable one will be really soon available (before beta1), unfortunately, there are late
<seb128> did you try syncing from debian?
<Q-FUNK> seb128: I filed a bug about the sync. needs to be acted upon.
<seb128> the crashes will likely go down once synced
<seb128> I would stay on the new serie
<seb128> it will be easier to mainin forward that an outdated versiojn
<Q-FUNK> the outdated version is rock-solid.  much better suited to an LTS.
<seb128> it also use old technologies and has issues
<Q-FUNK> it did not have any issue.  it simply never was ported to GIO.
<seb128> softwares with no issues, we don't have any of those
<pitti> Q-FUNK, didrocks: hal doesn't access libgphoto, that's fine
<pitti> gthumb is supposed to try and gvfs-unmount the libgphoto mount
<didrocks> pitti: thanks for the info :)
<geser> pitti: Hi, do you have a minute for a question about the doc symlinking code in cdbs? (it's for the gdb FTBFS)
<pitti> geser: sure
<pitti> geser: that build log looked like the directory wouldn't be accessible or wouldn't be a directory in the first place
<pitti> like a broken symlink
<geser> pitti: yes, gdb symlinks the whole /usr/share/doc directory
<pitti> ah, that'd be it
<geser> the doc symlinking code has some guards but they only check debian/$(cdbs_curpkg)/usr/share/doc
<geser> isn't there a "/$(cdbs_curpkg)" missing at the end? or did I miss something this tests check?
<pitti> geser: "symlinks the whole /usr/share/doc" -> apparently that was done only recently?
<pitti> this will lead to trouble either way, though
<pitti> dpkg does not replace directories with symlinks during upgrade
<pitti> doko_: ^
<geser> pitti: yes, this changes got introduced with the recent gdb upload (merge)
<pitti> that's why cdbs does not symlink directories, just files
<geser> pitti: is there a reason to only check if debian/$(cdbs_curpkg)/usr/share/doc is not a symlink and a real directory and not the directory below it (the one with the doc files for the package)? in what case could usr/share/doc not be a directory?
<persia> Never underestimate what is possible as a result of an upstream build.
<pitti> geser: you mean the if [ -d debian/$$dep/usr/share/doc ], righht?
<geser> pitti: yes
<pitti> geser: I don't think it was deliberately written that way
<pitti> i. e. it could be /$(cdbs_curpkg) too
<geser> pitti: no, the one 4 lines above: [ -h debian/$(cdbs_curpkg)/usr/share/doc ]
<geser> and the next one: [ ! -d debian/$(cdbs_curpkg)/usr/share/doc ]
<pitti> geser: ah, that was introduced for some reason
<pitti> geser: when we introduced this, this already stumbled over packages which do such crazy things
<pitti> geser: but we could add an additional check for /$(curpkg)
<tseliot> pitti: do you know why the xorg-driver-fglrx package is still available in the archive? Shall I make it a transitional package?
<tseliot> (the package is named "fglrx" now)
<pitti> tseliot: hm, wasn't that the official name until now? yes, it'd need a transitional package then, for lucid
<tseliot> pitti: ok, I'll take care of it then. Thanks
<pitti> geser: you don't happen to have a built gdb tree around, do you?
<geser> pitti: no, but could have it in around 10 min
<pitti> geser: how does http://paste.ubuntu.com/399192/ look to you?
<pitti> geser: oh, I can test-build it myself, too
<pitti> geser: I'll reproduce the ftbfs and test this patch then
<pitti> thanks for pointing out!
<geser> pitti: looks good, I did a similar change to test my idea (but I changed the original one instead of adding a new one)
<geser> pitti: and you could add an "i" to my surname in your changelog entry: Bienia
<pitti> geser: whoops, sorry; fixed
<tseliot> pitti: do you know why dpkg-trigger complains when I call it from the postinst?
<tseliot> dpkg-trigger: dpkg-trigger must be called from a maintainer script (or with a --by-package option)
<tseliot> I call it with dpkg-trigger gmenucache
<pitti> hm, it sohuld be able to figure that out
<pitti> apparmor.postinst:        /usr/bin/dpkg-trigger update-initramfs
<pitti> that looks very similar, and apparenlty works
<pitti> tseliot: does adding an explicit --by-package fglrx help?
<pitti> (or nvidia*, whereever you call it from)
<tseliot> pitti: I'll try it, thanks
<pitti> geser: confirmed to work, I'll upload that
<doko_> pitti: thanks, not a change which I did introduce myself, therefore the question to fix it in cdbs ...
<pitti> doko_: fixed cdbs uploaded
<pitti> doko_: right, it should, I was just pointing out that symlinking dirs is brittle
<doko_> replacing a dir with a symlink isn't a problem if you know that the package is the only one placing files in this dir
<cjwatson> doko_: you do still need a preinst hack
<cjwatson> i.e. rm -rf old-directory in the preinst, probably with a version guard, assuming that there are no configuration files in there
<geser> there should be no configuration files in /usr/share/doc/$pkg
<doko_> cjwatson: really? we'll see with gdb-dev, gdbserver or gdb64, but isn't a package first removed before the new one is unpackacked?
<doko_> coffee first ...
<pitti> I definitively know that dpkg will never replace a symlink from the old version with a directory from the new one; I'm not sure about the other direction (replace dir with symlink)
<directhex> nafaik
<persia> I believe dpkg unpacks *over* the existing package, rather than removing the package first, preserving any symlinks, etc.
<cjwatson> doko_: no, as persia says.  removing the package first would cause other problems
<cjwatson> pitti: definitely in neither direction
<cjwatson> it's quite deliberate
<pitti> cjwatson: yes, it'd make sense, but I haven't tested it myself in that directio
<cjwatson> too easy to make mistakes, so you have to explicitly force it by removing the old object in the preinst
<pitti> thanks for the heads-up
<cjwatson> geser: indeed - I was just trying to make my statement general
<pitti> apw: 2.6.32-17.26 binNEWed, FYI
<tseliot> pitti: any ideas as to why I've just received 5 messages about my uploads of fglrx-installer being rejected?
<pitti> tseliot: yes, I do
<pitti> tseliot: those were the binaries for older uploads
<pitti> tseliot: I just kept the ones for the current version, makes review a bit easier
<pitti> tseliot: please ignore
<tseliot> pitti: ah, ok, I was starting to think that I did something wrong ;)
<lamont> pitti: jackfruit is, um, interesting
<highvoltage> lamont: hi! If I understood you correctly last week, the ltsp squashfs should appear on the disc around any day now right? or was there something we sill needed to do?
<lamont> the CD image building side of things needs to actually deliver the file that it now has available
<lamont> and that bit is in the "not me" category
<siretart> asac: did you have a chance to take a look at bug #542506? - or can you name someone else who can comment on this issue?
<ubottu> Launchpad bug 542506 in gxine "gxine fails to start: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory" [High,Triaged] https://launchpad.net/bugs/542506
<lamont> highvoltage: sadly, it would appear that they're not building 'edubuntu', but rather 'edubuntu-dvd' :(
<highvoltage> lamont: would you be able to fix it?
<lamont> yeah - I'll add that to the dvd target as well, and upload a new livecd-rootfs today
<highvoltage> thanks!
<sistpoty|work> asac: I don't exactly parse your rationale for bug #544085, can you explain why we really want to have it in for lucid?
<ubottu> Launchpad bug 544085 in ubuntu "[FFe] sync ntrack 006-1 from debian/testing" [Undecided,New] https://launchpad.net/bugs/544085
<asac> sistpoty|work: simply to get upstreams easier adopt this
<sistpoty|work> asac: ah, k. you've got a "not" that mislead me in the description
<sistpoty|work> asac: would a backport be ok as well?
<sistpoty|work> (we're past beta1 so I'm very hesitant wrt. new packages)
<asac> sistpoty|work: backport wouldnt work as its not considere in-lucid
<ogra> is anyone deeply familiar with dh_make here ? according to the manpage -p should override the directory check but apparently it doesnt
<sistpoty|work> asac: hm... I guess I'm ok with it but you'll need to find and bribe an archive admin willing to denew it ;)
<asac> sistpoty|work: yeah. thats understood
<sistpoty|work> :)
<lamont> bug 542955
<ubottu> Launchpad bug 542955 in bind9 "/sbin/ldconfig.real: File /usr/lib/libdns.so.64 is empty, not checked. " [Undecided,New] https://launchpad.net/bugs/542955
<Keybuk> argh
<Keybuk> my git-fu is not strong today
<Keybuk> lamont: every time I try and do any merge in util-linux, I get conflicts all over the place
<lamont> Keybuk: ew.  I'm afk for a few hours, can we chat after that?
<lamont> or toss me what you're trying to merge from->to and I'll see about bludgeoning my way through
<lamont> I have to rebuild my laptop, because lucid ate it.
<lamont> well, to be fair, I fed it
<Keybuk> I'm trying to merge ubuntu/master into your stable/v2.17
<lamont> in your git tree, and you've pushed the current state?
<Keybuk> no, can't push cause just lots of conflicts
<lamont> let me rephrase that - if I pull your published tree, will I have what you started with?
<Keybuk> yes
<lamont> ok
<lamont> and afk
<Keybuk> I guess it's just a "commit on both sides" issue?
<Keybuk> GIT seems to be quite bad at those
<Keybuk> (worse than bzr, and that's saying its shorter than Ronnie Corbet)
<Keybuk> aha!
<Keybuk> it is just that
<amitk> Keybuk: commit on both sides?
<Keybuk> amitk: right
<Keybuk> the same commit has been applied to both sides
<Keybuk> ie. to master and to stable/v2.17
<Keybuk> so is in the history of master
<Keybuk> and in the history of where I'm merging from
<Keybuk> so git is helpfully conflicting it
<c_korn> don't you have to rebase in this case ? (just guessing)
<amitk> Keybuk: because they applied as different shaids, I guess?
<amitk> c_korn: rebase would still conflict
<Keybuk> right
<nigelb> pitti: apport seems to not like forms like "GST_DEBUG=*cheese*:3 cheese -v" for the command_output function.  any thoughts on this?
<pitti> nigelb: That's not a program invocation, but shell syntax :)
<nigelb> pitti: which means I can do that?
<nigelb> can't
<pitti> nigelb: simplest is probably to use ['env', 'GST_DEBUG=*cheese*:3', 'cheese', '-v']
<pitti> i. e. call env explicitly
<nigelb> pitti: ah, and one more question :) how do I do 'killall cheese' this way?
<pitti> nigelb: the more general method is to call[ '/bin/sh', '-c', command]
<pitti> nigelb: you don't want killall :)
<pitti> nigelb: but that doesn't work with the simple command_output any more
<nigelb> pitti: the idea is to start cheese in debug mode
<nigelb> so if its already running, I want to kill it
<pitti> nigelb: use subprocess.Popen(), wait ten seconds (or similar), and then call .kill()
<pitti> nigelb: hm, that sounds a bit ... unexpected; it might be "data loss" in some cases?
<Keybuk> pitti, nigelb: even Upstart calls /bin/sh -c "command"
<pitti> nigelb: you could ask for it interactively
<nigelb> pitti: oh, wait I'm not clear
<pitti> nigelb: i. e. ui.yesno("Blabla rationale need to restart cheese in debug mode")
<nigelb> The idea is, if uses calls Help> report bug and I want to start in debug mode, cheese needs to restart
<pitti> nigelb: sure
<pitti> nigelb: but you shouldn't "just do" this without warning, I think
<nigelb> the warning is thre
<nigelb> but the code to do it isn't working yet ;)
<pitti> nigelb: well, unless there's no way to have unsaved changes in cheese (I'm not that familiar with it TBH)
<nigelb> so l[ '/bin/sh', '-c', 'killall cheese'] would work?
<pitti> no
<pitti> nigelb: just ['killall', 'cheese']
<pitti> that's a proper command
<nigelb> that didn't work
<pitti> nigelb: but again, that's not what command_output is meant to be used for. Use subprocess.call() for that
<nigelb> pitti: ah, I will try that :)
<pitti> superm1: http://bazaar.launchpad.net/%7Eubuntu-core-dev/jockey/ubuntu/revision/400 -> ok for you?
<pitti> superm1: oh, nice round commit :)
<nigelb> Keybuk: thank you too :)
<pitti> fabbione: Padre! how are you?
<fabbione> pitti: wrong question today... just come back with 28 hours delay on my flight
<fabbione> need to settled down the kids
<pitti> urgh, that sucks
<fabbione> pitti: sorry, I'd love to talk but I am sort of busy :)
<pitti> fabbione: np, good luck with settling in!
<ccheney`> how do you tell dpkg to unapply patches in an extracted fmt 3.0 source?
<pitti> quilt pop -a ?
<directhe`> RAOF, ping. can you look at kamujin's super ghetto gnome-keyring-sharp replacement & see if it provides what f-spot needs?
<ccheney`> pitti: ah thanks
<pitti> ccheney`: although it's not immediately visible, it should still be quilt underneath
<ccheney`> pitti: hmm quilt isn't installed does dpkg have an internal version too?
<pitti> ccheney`: yes, it does
<ccheney`> pitti: ah ok so just install quilt to work with it then, thanks
<pitti> ccheney`: if you haven't worked with it, you might want to set QUILT_PATCHES=debian/patches
<pitti> ccheney`: (it defaults to ./patches)
 * persia` notes that not all Format: 3.0 packages are Format: 3.0 (quilt)
<maco> persia`: well thats confusing
<persia`> maco: Why?
<pitti> persia`: there's also (native), but also somethign else?
<maco> i thought all v3 packages used quilt by default
<persia`> No.
<persia`> Lots of packages use patch systems just like Format: 1.0
<maco> i thought quilt was a patch system
<pitti> AFAIR there was some discussion about "3.0 (bzr)" and "3.0 (git)", but I don't think either works today
<persia`> Tbe base means of Format: 3.0 is essentially just a tarball diff.
<maco> or do you mean *other* patch systems
<maco> pitti: so you cant use quilt and bzr together? i guess that makes sense...
<pitti> maco: you can, but it's really ugly
<pitti> so far I avoided converting bzr or git maintained packages
<pitti> it's confusing
<persia`> quilt is 1) a tool for working with sets of packages, 2) a system that can be used as a substrate for a primitive VCS, 3) a patch system for debian format package, 4) a format specification for patch application in one flavour for debian format 3.0 packages, ...
<pitti> git-buildpackage actually DTRT and applies the patches in the build-area
<muelli> which packages does ubuntu automatically pull? suggests? Recommends?
<cjwatson> pitti: I actually find it works really well for me
<pitti> cjwatson: I find it confusing to both apply patches and have them in debian/patches; that will still take a while to get used to for me, I think
<cjwatson> pitti: in 3.0 (quilt), the tree generally stays in patched state except when you're actively working on the patches, so I find that tools like 'bzr blame' work much better than they do with old-style patch systems
<cjwatson> pitti: definitely a feature as far as I'm concerned :)
<cjwatson> pitti: http://paste.ubuntu.com/399335/ for example
<cjwatson> it just means that when you commit a change you effectively see it twice in 'bzr diff', but *shrug* doesn't really bother me
<cjwatson> maco: openssh is an example of using quilt and bzr together
<maco> cjwatson: ok, ill have a look
<maco> muelli: depends and recommends. if using apt on command line (dunno about guis) itll mention the existence of suggests
<cjwatson> the only real glitch I found was the one I filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
<ubottu> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open]
<cjwatson> persia`: IME you have to be fairly perverse to use format 3.0 with some other patch system, and the last (and only) time I encountered this I filed a bug and the maintainer said "er, yeah, sorry"
<cjwatson> part of the point of format 3.0 was to unify all the patch system mess, so I think using it with an old-style patch system is very definitely Missing The Point
<persia`> I'll agree with that, excepting when it's useful to add extra tarballs.
<cjwatson> right, didn't say it was the whole point :)
<pitti> yay for unifying patch systems indeed
<pitti> I tried to package with bzr loom some months ago
<cjwatson> bzr loom is still definitely in the "nice idea but experimental" bucket for me, I think
<pitti> while that worked pretty well, everyone else will just ruin your tree, though, so doing it for some packages isn't worth the trouble
<pitti> but it still feels weird to have to deal with debian/patches/ stuff if we have all that VCS magic already
<pitti> especially now that you have to do _both_ (in-tree and separate patch)
<cjwatson> I like the principle that patches should be an export format, but I'm not willing to deal with lots of scary experimental VCS technology just for that; having to commit to the original files and debian/patches/ together is IMO a small price to pay for the benefits
<directhe`> someone wake me when bzr and multi-tar work nicely together. things like pristine-tar need to deal with multi-tar
<ccheney`> gah
<superm1> pitti, yes i believe it should help me.  i'll double check today and let you know if it doesnt
<Keybuk> Should not be doing an Octopus.
<Keybuk> ...
<Keybuk> thanks git.
<aboSamoor> Keybuk, I read your post on ubuntu forums and I checked the GSoC regarding the boot performance. I talked to Riddle and he forwarded me to talk to you. I am asking for any advices regarding making a proposal for improving boot performance that can satisfy for GSoC proposal.
<Keybuk> aboSamoor: what kind of thing did you have in mind?
<aboSamoor> Keybuk, on personal level, I am just annoyed by the frequent re-profiling mechanism. As a power user using all the time pre-release software I am all the time updating the software. So according to the re-profiling policy I loose much of the ureadahead advantage. Apart from that, I was following the efforts of the boot performance team, and I am interested in going faster than what I have now. My laptop boots in 22 seconds.
<siretart> asac: around?
<Keybuk> aboSamoor: in terms of reprofiling, what we've been missing is the kernel side of tracking which blocks in the page cache were actually used -- that's a kernel patch we've written but haven't tested yet
<Keybuk> in terms of ureadahead performance in of itself, what we need here is the ability to load blocks from disk into the page cache without needing to open a file first -- since the open()s take up a number of seconds
<Keybuk> I suspect that's way beyond GSoC level
<Keybuk> boot performance > what ways of booting faster can you think of?
<cjwatson> oh, come on, lists.gnu.org, archive things faster so that I can have a URL for my patch file
<ccheney`> ext4 defrag would be nice for booting faster :)
<aboSamoor> Keybuk, I read the post yesterday, and it make my mind busy. I am not a computer engineer, but my work does not deal with PCs usually, more of embedded systems. If you do not mind I would like to ask questions regarding the mechanisms used now, so it helps me to understand better.
<ccheney`> hopefully that doesn't eat your data in the process
<Keybuk> aboSamoor: of course
<Keybuk> ccheney`: would you trust an ext4 defrag that wasn't written by ext4 upstream?
<Keybuk> (then again, would you trust an ext4 defrag that *was* :p)
<psusi> ARGH!@#  fuckign gnu.... I've been starting to think I was going insane because of all of these bizare performance results I've been seeing with tar while trying to compare it with dump.. .turns out gnu tar cheats and doesn't bother actually reading the input files and writing them to the output if it detects that the output is /dev/null... it just stats the input files
<Keybuk> that seems like a sensible optimisation to me
<psusi> no, that's like the old compiler "optimization" that explicitly detected if it was compiling a drystone benchmark and "fixed" it to not bother with all of the computations
<Keybuk> no, that's "tar is not a benchmark"
<psusi> and simply not naming the input file drystone.c would defeat the "optimization"
<cjwatson> and the reason why tar does that is in ChangeLog.1
<cjwatson> "Corrections to speed-up the sizeing pass in Amanda:"
<ccheney`> Keybuk: perhaps, ext4 upstream has shown to be somewhat odd in the past :)
<psusi> no, but if I want to see how long it takes to read the files, without having the output compete with the read IO... it should do that... not run me around in circles not doing what I expect it to do when I redirect the output to null, I mean I want the output to go there
<Keybuk> ccheney`: "ext4 defrag corrupted my data!" ... "no, you can't have your pony back"
<ccheney`> Keybuk: definitely would want it well tested before use, i remember using xfs defrag and it eating all my data in the past
<Keybuk> psusi: could you take this to #beingwrongontheinternet plz
<Keybuk> psusi: it's not really relevant
<psusi> hehe
<Keybuk> and we're not going to patch tar ;)
<psusi> now maybe tonight I can get around to testing defrag packing ureadahead boot files at the start of the disk in order...
<asac> siretart: yes on a call, but whats up?
<siretart> asac: I wanted to hear your opinion on the libmozjs.so issue. it breaks applications like gxine
<siretart> asac: see bug #544085 for details
<ubottu> Launchpad bug 544085 in ubuntu "[FFe] sync ntrack 006-1 from debian/testing" [Undecided,Confirmed] https://launchpad.net/bugs/544085
<siretart> err
<siretart> make that bug #542506
<ubottu> Launchpad bug 542506 in gxine "gxine fails to start: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory" [High,Triaged] https://launchpad.net/bugs/542506
<Keybuk> #	modified:   disk-utils/fsck.minix.c
<Keybuk> #	modified:   disk-utils/mkfs.c
<Keybuk> ... no I didn't, *you* did
<cjwatson> patch system?
<Keybuk> cjwatson: just GIT being unhelpful
<aboSamoor> sorry, I am computer engineer I made typos. I was reading the lastest updates to the post, so avoid redundant questions. Now, you cache all the files you will read during the boot in pack files and store names and some attributes. But what about making binary image of the memory for the files have been read, so we are sure that we are reading contiguous data from the hard disk? That will consume 200-300 MB from the hard disk space but i
<aboSamoor> t is not problem on many of the HDD drives
<asac> siretart: what does gxine use js for?
<Keybuk> cjwatson: it's having fun by duplicating blocks in all the files
<Keybuk> aboSamoor: because there's no way to tell the kernel that the binary image you're loading into memory is really the contents of blocks of other files on the filesystem
<Keybuk> aboSamoor: as soon as the real files were needed, the kernel would just re-read them all over again
<siretart> asac: you can script it with js
<siretart> asac: on the command line with parameter '-c'
<cjwatson> Keybuk: hah
<Keybuk> cjwatson: when lamont made the 2.17 release, he merged "ahead" of the release on master and made that the release
<Keybuk> cjwatson: unfortunately the release was the branch point for 2.17.1 - so now I have the "commits with different sha1s on two different branches that are otherwise the same" problem
<cjwatson> Keybuk: this reminds me of doing the parted 2.2-1 release; it took ages to glue all the git history together, and I had to do something like three separate merges to clue git in to what was going on
<cjwatson> I did eventually get to the point where it wasn't giving me spurious conflicts, but it wasn't straightforward
<aboSamoor> Keybuk, if I am not wrong, there is something called ramdisk that will create file system in ram. If we build the filesystem out of the binary image and forward all the files known to be cached to be read from that ram disk, i think it will help. sorry if this looks unrealistic or naive.
<Keybuk> aboSamoor: it's the "forward" bit that's missing
<Keybuk> all copying the files into a ramdisk will give you is a ramdisk with a copy of the files in it
<Keybuk> which is a second copy of the file
<Keybuk> so it'll mean you read the file twice into memory
<Keybuk> instead of once
<aboSamoor> Keybuk, you mean the kernel see the ramdisk as another hard disk ? I meant by forward that if we need file as /bla/foo.conf we can use a table that will give us the version that is stored in memory. /ramdisk/bla/foo.conf
<Keybuk> aboSamoor: yes, the kernel literally just sees it as another hard disk
<Keybuk> albeit one that is stored in RAM and vanishes when you turn off the power
<Keybuk> the kind of "table" you're talking about sounds a *lot* like a union filesystem
<Keybuk> those things are very problematic, and there isn't a good one available
<Keybuk> they also tend to go in the wrong direction
<Keybuk> you'd need things set up in such a way that updates to the file went to the hard drive underneath, and removed the entry from the ram disk
<Keybuk> not to mention the difficulty of generating that ram disk
<Keybuk> that's quite deep kernel-level engineering
<Keybuk> aboSamoor: the thing as well is that the kernel already has a mechanism for storing files from a hard disk in memory
<Keybuk> it's used every time you open any file, a kernel fetches bits of it into memory, and it's actually from memory that read() returns
<Keybuk> that way if you, or any other process, read that same bit of the file - it's already in memory
<Keybuk> this is called the page cache
<Keybuk> ideally any solution should simply pre-populate the page cache
<Keybuk> rather than add another layer on top
<Keybuk> plus I've seen a lot ideas like "put all the content of the files we need into one big file and read that"
<Keybuk> without fixing the obvious problem that the one big file can get fragmented just as much as the individual files can
<Keybuk> so probably doesn't help ;-)
<aboSamoor> Keybuk, what about if that big file stored in special filesystem ? I think some databases perform better in file systems that fit with their needs. Maybe the restriction that the filesystem makes is what brought swap to be different partition. I think windows7 is now using the same approach.
<Keybuk> aboSamoor: then you'd not only have to write the kernel VFS patches to redirect lookups to the "cache file", but you'd also have to write an entirely new filesystem
<Keybuk> this is going a little over-scope for GSoC
<aboSamoor> Keybuk, Even it is within the range of GSoC, i believe it is more of what I can learn and learn in the time provided. However, hypothetical scenarios help to understand the problem better. In the booting process what does take the largest percentage ? the boot loader, reading the pack files lists, processing the read files, or hardware initialization ?
<Keybuk> aboSamoor: reading the files from disk
<Keybuk> aboSamoor: well, strictly speaking, most of the time in the boot process is desktop
<Keybuk> aboSamoor: reading files from disk takes about 7s
<Keybuk> aboSamoor: core OS boot takes about 6s
<Keybuk> aboSamoor: initialising the desktop, drawing it, etc. takes 12s
<aboSamoor> Keybuk, that is strange how the guys behind chrome-os are planning to do less than five seconds boot if drawing the desktop take all that time. They can tweak the other factor as they do not plan to run general hw and instead they will optimize the hardware.
<Keybuk> aboSamoor: Chrome OS doesn't have a desktop environment!
<Keybuk> there are no panels, no file managers, no little services to notify you of interesting things, etc.
<Keybuk> it's just a big fullscreen web browser
<Keybuk> aboSamoor: having control over the hardware means you can specify a solid-state disk and a specific disk controller
<matumba> and kill the slow BIOS crap :P
<Keybuk> right, exactly
<psusi> will be nice when bios is dead and we're using EFI to boot
<psusi> seems that the video drivers though still rely on the video bios for mode setting, which is a problem for EFI
<Keybuk> sadly EFI does not appear to be making any difference
<psusi> what do you mean?
<Keybuk> machine EFI implementations are just as bad as their BIOS implementations
<Keybuk> pitti: what is the package that mounts things under /media nowadays?
<Keybuk> I've lost track of where that code has gone :p
<ccheney`> NCommander: uploaded the new OOo with your patch :)
<ccheney`> rickspencer3: uploaded new OOo that should hopefully fix the bug silbs had
<rickspencer3> thanks ccheney`
<YokoZar> Is the text highlight color a property of the theme?
<YokoZar> (eg orange for checkboxes)
<superm1> pitti, yes i can confirm that works properly
<pitti> Keybuk: udisks
<pitti> superm1: great
<Keybuk> pitti: btw, your e2fsprogs upload wasn't committed to the repo
<pitti> Keybuk: wouldn't the auto-importer take care of it?
<pitti> you mean lp:ubuntu/e2fsprogs?
<Keybuk> pitti: the auto-importer can't commit to GIT
<Keybuk> no, http://kernel.ubuntu.com/git?p=scott/e2fsprogs.git;a=summary
<pitti> hm, could that be added as Vcs-Git: ?
<pitti> Keybuk: can I commit to that one?
<Keybuk> yeah will do
<Keybuk> but it missed this upload
<Keybuk> pitti: no
<Keybuk> pitti: git doesn't really do shared repos, after all
<pitti> ok, sorry about that
<Keybuk> and tbh, I prefer not to patch e2fsprogs - it's better to get the patches into upstream and just update
<pitti> I didn't even know it was in git
<Keybuk> patches in e2fsprogs adds pain from Ted Tso
<Keybuk> pitti: of course, it gets even more confusing with util-linux ;)
<Keybuk> since the Vcs-Git header for that is correct
<Keybuk> even though it's a Debian one :p
<pa> hi
<pa> if i dist-upgrade my lucid alpha, will it become lucid beta now?
<Pici> !final | pa
<ubottu> pa: If you installed a Alpha/Beta/RC version of Ubuntu 10.04 (Lucid Lynx) and have been keeping it up to date, then you are already running the latest version of Karmic. To make sure, type Â« sudo apt-get update && sudo apt-get dist-upgrade Â» in a console.
<Pici> pa: Also, further Lucid support is in #ubuntu+1
<pa> ah ok
<pa> sorry :)
<pa> but thanks
<sbeattie> need to do s/Karmic/Lucid/ for ubottu
<Pici> sbeattie: darn, I just fixed it, but missed the second one in there... /me fixes now
<Pici> Thanks for pointing it out.
<nosse1> Hi. What do I need to put up my own private apt repo?
<nosse1> We have a handful of application/packages private to our organization and I want to create a apt repository for our users. Are there any tools/script available for creating the neccessary files and structure?
<cody-somerville> nosse1, This isn't the place to ask about that. However, you might look at http://mirrorer.alioth.debian.org/
<nosse1> cody-somerville: Thanks
<lamont> cjwatson: out of curiosity, when I wound up bailing out of the install because "install grub" failed totally, what other bits of "finish the install" do I want to have emulated?
<lamont> and is it just me, or did we completely eliminate the option of using a partition for a filesystem without reformatting it (in the installer)
<lamont> because, frankly, I'd like my old /home back
<benkong2> I have the strangest problem but am not sure of the info needed to file a report.
<benkong2> When I do sudo apt-get install build-essential I get http://pastebin.com/Wiitjz59
<benkong2> The above is the terminal output
<bdrung> james_w: regarding sync request bug #539990: can you sync version 1.1.1-2 instead of 1.1.1-1?
<ubottu> Launchpad bug 539990 in openshot "Sync openshot 1.1.1-2 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/539990
<bdrung> i updated the title, but forgot the description
<geser> benkong2: what error do you get when you also try to install g++?
<benkong2> geser, g++: Depends: g++-4.4 (>= 4.4.3-1) but it is not going to be installed
<benkong2> Broken Packages
<james_w> bdrung: please file a new reuqest
<benkong2> The following packages have unmet dependencies:
<benkong2> bdrung, is that for me?
<benkong2> oops
<bdrung> benkong2: no, it was for james_w
<benkong2> ok sorry
<benkong2> geser, this is a fresh install
<sebner> james_w: thx for syncing gpsd but wondering about LP (maintenance ?) as I can't see the update there
<james_w> sebner: it's still in progreee
<sebner> james_w: ah, ic. just wondering because you closed the sync bug 1 houra go :)
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<sebner> ubottu: hahah!
<cjwatson> lamont: I'm not sure I'm comfortable with advising on that, can I find out why it broke instead?
<cjwatson> lamont: and I certainly wasn't aware that we'd eliminated that option.  did you file a bug?
<lamont> cjwatson: I'm still in the process of recovering access to the world
<lamont> cjwatson: I was kind of off-script when I got dead.
<cjwatson> grub-installer is the last thing before finish-install, but finish-install does various things
<james_w> sebner: there were a lot of syncs today, and it's not the quickest process in the world
<bdrung> james_w: ok, filed bug #544440
<ubottu> Launchpad bug 544440 in openshot "Sync openshot 1.1.1-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/544440
<lamont> laptop is encrypted-disk-with-lvm, where I split /home onto its own partition, and created a few alternate root partions.  There isn't an option in d-i to say "just mount the ^%&*(%&%( disk in luks, thanks"  at least not that I could see - it would happily create a _NEW_ encrypted partition stomping on the entire thing, but not give me access.
<sebner> james_w: kk, np :)
<lamont> so... cryptsetup luksOpen, vgscan; vgchange -a y; and back to the partitioner
<lamont> not sure if it was because I failed to pick the same name, or because I failed to tell the system how we got the encrypted partition and LVs there, but it was sadly confused and very pissed when grub-installer went to do its thing
<lamont> mind you, I got to _THIS_ point because I was trying to save the state of the root partition when the upgraed locked up hard.
<lamont> and the first thing the new install did was happily format the /home partition.
<lamont> needless to say, this did not leave me too happy with it
<lamont> cjwatson: so far, I know that update-initramfs and actually creating the initial user are on the list of finish-install tasks...  just wondering what else is waiting to bite me
<lamont> once I finish syncing my firefox profile over, I'll go file a bug or 9
<Pretto> is there a way to check if a repository is ok? os if it is faling?
<slangasek> Pretto: a repository is ok when you're able to install from it, and not when you aren't? :)
<Pretto> slangasek: i mean this, that information is not that usefull http://paste.ubuntu.com/399499/
<zyga> Pretto: that's someone's ppa
<Pretto> suppose i have set up 10 ppa's
<slangasek> Pretto: so you're trying to figure out which one that you've set up is broken?
<Pretto> how can i know if that ppa is for emesene for example?
<Pretto> slangasek: yes, not easy to do because apt will show only the launchpad main address
<slangasek> Pretto: you can comment them out one-by-one in /etc/apt/sources.list or /etc/apt/sources.list.d and re-run 'apt-get update' to see if the error goes away; or you can pull the URLs out of the config and browse to them in your browser
<cjwatson> IMO that's an apt bug
<Pretto> slangasek: i know, but this way i will be guessing
 * slangasek nods to cjwatson 
<cjwatson> I never thought it was a helpful truncation even before PPAs
<Pretto> cjohnston: bingo
<slangasek> Pretto: not guessing, just an exhaustive search
<cjohnston> :-(
<cjwatson> Pretto: your tab completion is buggy
<Pretto> cjohnston: sorry :D
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317576
<ubottu> Debian bug 317576 in apt "display full url and path, not only url" [Normal,Open]
<Pretto> if there's a broken one, apt must say it in a helpfull way
<Pretto> that's not hard to do
<lamont> so how the heck do I tell compiz to give windows more than 1 pixel boarders?
<lamont> borders, too
<cnd> anyone know of an interface like packages.ubuntu.com for the -proposed archives?
<wgrant> cnd: For what purpose? Launchpad is the canonical source of information on the Ubuntu archives, and provides most of the information that p.u.c does.
<cnd> wgrant: you're right, I didn't remember that the info I wanted was in lp
<cnd> I just wanted the latest changelog
<wgrant> We don't currently expose the raw changelog (but that will change in a few weeks). You can approximately see the new entries in each version, though.
<NCommander> ccheney: woo, win!. We need to test on Debian to make sure thebug fully fixed there though
<psusi> can someone with a little more knowledge of udev than me take a look at bug #534743 and see if the more complex solution would be appropriate or not, and maybe see about applying one or the other in time for the next lucid beta?  this is a show stopper for many users for lucid.
<ubottu> Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [Undecided,Confirmed] https://launchpad.net/bugs/534743
<Keybuk> psusi: any particular reason that dmraid opens the block device for writing?
<Keybuk> if it opens it read-only, it won't trigger a change surely?
<psusi> Keybuk, it doesn't.... what it does is delete the kernel partition table on the activated devices, since they are invalid
<psusi> I think the proper way to fix this is to have udev delete those tables as soon as blkid decides the disk is a dmraid member rather than have udev do it, but just removing the |change from the rule worked around it for me
<Keybuk> removing change would have other side-effects
<Keybuk> and certainly this late in a beta we wouldn't want to make that change
<psusi> I figured it likely would, but I couldn't think of any...
<psusi> I mean what else generates a change event on a raw disk other than updating the partition table?
<Keybuk> various disk controllers do
<Keybuk> if you unplug and plug the disk in
<Keybuk> for example
<psusi> wouldn't that do a remove then add?
<Keybuk> no
<psusi> and I don't think it handles a surprise removal anyhow ;)
<Keybuk> change can mean medium change
<Keybuk> change can mean a device that was previously disabled has been activated
<psusi> fixed disks.. no medium to change
<Keybuk> (ie. at the add point, the device probe returns error codes, and only after the change can it be read)
<Keybuk> it might be only fixed disks in your setup
<psusi> no, I mean only fixed disks are possible... dmraid is bios raid support.. the bios only deals with fixed disks ;)
<Keybuk> ah, well, that's different then
<psusi> in an idea world, you're right, which is why I think the proper solution is to have udev remove the partitions when blkid says it's a raid member rather than having dmraid do it on activation, then it can continue to activate on change or add
<psusi> but practically speaking, dmraid disks don't have any circumstances where they emit a change event other than this, AFAICS
<psusi> another possibility is to use watershed maybe
<psusi> like lvm does
<Keybuk> that would work too
<psusi> waterhshed I think would stop the infinite loop, but would still have more activations run than needed
<Keybuk> yeah you'd get two for each one
#ubuntu-devel 2010-03-23
<ccheney> NCommander: ok
<psusi> how do you like that... mke2fs now defaults to using the 256 byte inodes... I really need to fix e2defrag to understand those...
<quentusrex> Anyone know of a 'very' stable network driver?
<quentusrex> forcedeth and r8169 so far have proved unstable for me.
<j^> http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx lists Canonical Limited as licensee of h264 anyone around who knows more about that?
<Keybuk> quentusrex: tg3 works for me
<Keybuk> quentusrex: the e1000 family are probably the best
<psusi> wow... starting with a clean filesystem then restoring a dump of my stable karmic root fs, e2fsck reports only 4.2% fragmentation.... after defragmentation, dumping the fs went from 2:14 to 1:24, taring the fs went from 5:10 to 4:09
<quentusrex> Keybuk, any idea who or how to debug an unstable driver issue?
<Keybuk> no idea
 * psusi really needs to get defrag working on ext4
<TheMuso> psusi: I thought file fragmentation was not such an issue on ext filesystems.
<psusi> TheMuso, uh-huh....
<psusi> strange thing is that e2fsck reports only 0.2% fragmentation on the original karmic filesystem... dumping and restoring to a clean fs should give LOWER fragmentation...
<Keybuk> because it's talking about inode fragmentation
<Keybuk> not data fragmentation
<psusi> what do you mean?
<Keybuk> do you know the difference between the two?
<psusi> if a file's data is in 2 non contiguous chunks, fsck counts it as fragmented.... it used to count it as fragmented if it was in two chunks because its indrect block was in the middle, which I would not consider fragmented... but it seems they have fixed that
<Keybuk> sooooorta
<psusi> since it now reports 0.0% fragmentation after an e2defrag run, but it used to say otherwise since the indirect blocks were interleaved with the data
<psusi> so what do you mean by inode fragmentation?
<Keybuk> look it up ;)
<Keybuk> bed for me
 * psusi has fun digging into debugfs
<ccheney> TheMuso: fragmentation can be a huge issue especially if you do any torrent transfers
<ccheney> TheMuso: i've had isos so fragmented i couldn't burn them without constantly running the buffer out
<TheMuso> ccheney: ah ok.
<jdong> yep, agreed with ccheney
<jdong> if you have extremely slow growing files like torrents mixed with other ordinary write traffic, ext*fs fails at preventing fragmentation
<jdong> when I used ext3/4, after a torrent is done I'd cp it once before playing.
<jdong> on my 5400rpm laptop hard drive at times the fragmentation was so bad I couldn't play a movie file in realtime
<psusi> looks like the lucid beta 1 iso I downloaded and am still seeing diwth transmission only has 16 fragments.... not bad at all
<jdong> ext4 helped a lot with delayed allocation if you've got no other IO traffic at the time.
<jdong> but if you mix in other write traffic or out-of-memory pressure, you're back to square one.
<jdong> in my experience, XFS has been the best filesystem at preventing fragmentation in torrent-like workloads
<jdong> though it has a wealth of other caveats, of course.
<lifeless> jdong: there is an API you can use to tell the os the file size
<psusi> weird.... if I restore a dump to a clean fs it shows some fragmentation under e2fsck... copying the original fs the dump was taken from to the same clean fs with cp -a and fsck shows 0.0% fragmentation
<lifeless> which torrent should ue.
<psusi> of course the cp takes about twice as long as restoring the dump...
<jdong> lifeless: yeah, nowadays torrent clients are using it more; wasn't the case 2-ish ubuntu releases ago
<psusi> I just wish restore was a true inverse of dump
<lamont> I remember when pluggable devices automatically mounted for me...
<lamont> what did I break when I upgraded to lucid?
<lamont> this time, at least I have a ck session
<lamont> start: Unknown job: squid
<lamont> did we mean to kill squid?
<lifeless> lamont: try squid2/squid3 perhaps?
<lamont> start: Unknown job: squid2
<lamont> 2.7 is installed, and I'd kind of expect apt-get install squid to actually succeed in launching the process
<ScottK> Interesting theory.
<lamont> https://bugs.edge.launchpad.net/ubuntu/+source/squid/+bug/523621 seems relevant to my interests
<ubottu> Ubuntu bug 523621 in squid "squid_2.7.STABLE7-1ubuntu5 fails to install with " Unknown job: squid" error " [Undecided,Won't fix]
<ScottK> At least we've established no one cares.
<lifeless> lamont: is there an old style script ?
<lamont> dpkg --contents /var/cache/apt/archives/squid_2.7.STABLE7-1ubuntu9_amd64.deb | grep init.d
<lamont> drwxr-xr-x root/root         0 2010-03-22 08:45 ./etc/init.d/
<lamont> lrwxrwxrwx root/root         0 2010-03-22 08:45 ./etc/init.d/squid -> /lib/init/upstart-job
<lamont> lrwxrwxrwx 1 root root 21 2010-03-22 20:50 /etc/init.d/squid -> /lib/init/upstart-job
<lamont> the package is delivering what doesn't work
<ScottK> Working is highly overrated.  That's well accepted these days.  The important thing is it uses Upstart.
<lamont> yeah - reopened bug 523621
<ubottu> Launchpad bug 523621 in squid "squid_2.7.STABLE7-1ubuntu5 fails to install with " Unknown job: squid" error " [Undecided,Won't fix] https://launchpad.net/bugs/523621
<lamont> and stuffed it back to confirmed
<lamont> -console output
<lamont>  expect fork
<lamont> -respawn
<lamont> I wonder if that was important
<stgraber> lamont: are you starting it in a chroot or on a regular system ?
<lamont> plain old regular out in the real root box
<lamont> was working before upgrading to 1ubuntu9 today
<stgraber> lamont: the initial bug report was about running it in a chroot which doesn't work with upstart unless using the workaround Chuck posted in the bug report
<stgraber> so that explains why that bug report was marked Won't fix but the upstart job being broken still remains a bug to be fixed :)
<lamont> ah, true.  it's a poorly titled bug
<lamont> meh.  filing a new bug then
<stgraber> yeah, you need to read the first line of the bug report ... title should have been updated accordingly
<ScottK> It's not clear to me that anyone verified zul's fix works
<ScottK> So it may well have been prematurely wontfixed since lamont had the same problem outside a chroot.
<stgraber> ScottK: indeed, though it's true that "start squid" shouldn't work in a chroot and zul's procedure be followed to have squid installed in the chroot (though it'll have to be manually started if one wants it to actually run in the chroot)
<lamont> and the prior version worked just fine, -1ubuntu9 regressed.  bug 544760 - go ahead and install it...
<ubottu> Launchpad bug 544760 in squid "fails to start: Unknown job: squid" [Undecided,New] https://launchpad.net/bugs/544760
<lamont> just try
 * stgraber looks
<lamont> fwiw, having a mixture of "upstart bitching about using init.d" and "init.d only not yet upstart" jobs on the system is going to be a royal annoyance
<stgraber> found the issue
<stgraber> now trying to fix it ;)
<lamont> and now to file my fun "nah, I didn't need to actually work on monday" bugset
<stgraber> was that thing even tested ? the upstart job is simply invalid ...
<stgraber> lamont: http://pastebin.com/ZCWNRwkw
<stgraber> I'll upload a fixed package in a few min, would be great if you could confirm the fix
<stgraber> ok, I have -0ubuntu10 ready to upload with the fix
<fcuk112> ;/wc
<stgraber> lamont: ?
<lamont> stgraber: sure
<lamont> sorry for the delay there
<lamont> was filing bugs
<lamont> 544762 544763 544764
<lamont> 3 _IN_A_ROW_!
<lamont> stgraber: where u got the fix?
<lamont> bouncing back and forth a bit, so kinda laggy
<stgraber> lamont: I wrote a few upstart job for LTSP recently, simply looked at the script and saw that something was a bit off ...
<lamont> heh
<lamont> stgraber: any clues on my "why don't removable media drives mount anymore"?  or even what package to throw that against?
<stgraber> lamont: I'm guessing it's somewhere between udev => udisks => gvfs
<persia> lamont: Start with nautilus, although the issue may live in udisks or udev
 * persia is certain it's not gvfs
<lamont> ta
<stgraber> lamont: btw, as you're around :) I see in the livefs build logs that the LTSP squashfs is building correctly, any idea of when it'll start being included in Edubuntu's DVD .iso ?
<lamont> when the bugtask gets done by the cdimage builder
<lamont> added the task to the bug earlier today when I was chatting with cjwatson about it
<stgraber> oh, looks like I have some backlog in my LP mailbox ;)
<lamont> https://bugs.edge.launchpad.net/ubuntu-cdimage/+bug/531546 <-- stgraber
<ubottu> Ubuntu bug 531546 in livecd-rootfs "Have a LTSP chroot built and placed on the Edubuntu DVD" [Undecided,Fix released]
<stgraber> thanks
 * lamont prepares and uploads 1.108
<ccheney> any inkscape experts around to look at bug 529625 ?
<ubottu> Launchpad bug 529625 in inkscape "Sync openclipart 0.18+dfsg-9 (universe) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/529625
<ccheney> it appears to be a bug in inkscape causing openclipart to not be compilable anymore
<ccheney> it spews seemingly forever, I killed the build after a 10GB logfile
<ccheney> the previous build log was apparently 500KB
<git__> hi
<git__> has anyone created a file versioning plugin for nautilus?
<git__> i don't want to duplicate effort by writing my own
<lamont> sigh.  so what updated today to break my ability to log into my bank
<lamont> gonna bet on "java" in some form
<persia> lamont: That would probably be openjdk then, as that was a recent rebuild.
<lamont> it's also possible that it's apparmor being mean to it,  since I have it somewhat locked down
 * lamont sleeps
<xnox> Is "package (<= 2.20.1+), package (>= 2.20.1~)" good way to depend on a particular upstream release version?
<xnox> Such that 2.20.2 nor 2.20.0 won't work
<persia> xnox: It ought work, yes.
<xnox> persia, thanks =) i've been testing with --compare-versions but wasn't 100% convinced
<pitti> Good morning
<StevenK> pitti: Morning
<micahg> pitti: does adding apps to the proper category in software center require an FFe or UiFe?
<pitti> micahg: fixing a wrong category? neither, I think
<micahg> pitti: how about adding a missing category
<pitti> same case
<micahg> pitti: ok, thanks
<pitti> zul: I uploaded a new nut which unbreaks the udevadm trigger, as discussed in bug 535152
<ubottu> Launchpad bug 535152 in nut "FFE for nut 2.4.3" [High,Fix released] https://launchpad.net/bugs/535152
<dholbach> good morning
<StevenK> dholbach: Hi! I got an e-mail about my membership in u-m-s expiring, can you fix?
<dholbach> hey StevenK
<dholbach> StevenK: no, but I'll add you to ubuntu-sponsors :)
<dholbach> StevenK: done
<StevenK> dholbach: \o/ Thanks!
<dholbach> anytime :)
<xnox> dholbach, good morning =) do you know how many students slots was ubuntu allocated in gsoc - tentatively ? =)))))
<dholbach> xnox: no
<dholbach> I don't - sorry
<xnox> =( kk thanks
<cjwatson> oh, smeg, uploaded d-i last night and forgot to change the seeds
<glatzor> cjwatson, hello, could you please have a look at debian bug #575070 of debconf. the new exclusive lock on file databases breaks debconf support in aptdaemon/software-center
<ubottu> Debian bug 575070 in debconf "Exclusive read-write lock in file db driver breaks running debconf as non-root" [Normal,Open] http://bugs.debian.org/575070
<cjwatson> glatzor: why aren't you using a separate database?
<lifeless> bug 522225
<ubottu> Launchpad bug 522225 in mysql-dfsg-5.1 "permissions incorrect on libmysqlclient16_7.0.9-1_amd64.deb" [High,Fix released] https://launchpad.net/bugs/522225
<cjwatson> glatzor: oh, I see
<glatzor> cjwatson, DEBCONF_DB_REPLACE doesn't work :(
<glatzor> cjwatson, and the non-root deconf-communicate even doesn't want to write to the database at all
<cjwatson> yeah, that's nasty
<cjwatson> glatzor: fixed in svn
<glatzor> cjwatson, that was fast :) thanks a lot
 * mvo hugs cjwatson 
 * cjwatson wonders why that bug doesn't show up on debconf's bug list
<cjwatson> glatzor: would appreciate it if you could try debconf 1.5.30 once it's available (uploaded)
<glatzor> cjwatson, I already tested the svn version and it seems to work
<glatzor> cjwatson, thanks a lot once again
<Laney> cjwatson: I removed that mailing list from the ~mono team. Could you set ~ubuntu-cli-mono-dev to have ubuntu-mono@l.u.c as its contact address now, please?
<Laney> (well, ajmitch did it actually)
<Laney> I'll create a script to subscribe to all the packages soon
 * jelmer cheers on james_w
<jelmer> james_w: thanks for syncing cabal
<Laney> http://orangesquash.org.uk/~laney/haskell-installability/i386.png
<Laney> lookin gooooooooooood
<chrisccoulson> Laney - that makes my eyes hurt ;)
<Laney> heh, I just look at it zoomed out
<dholbach> mvo: would it make sense to add archive.canonical.com and ppa.launchpad.net to /etc/squid-deb-proxy/mirror-dstdomain.acl?
<dholbach> mvo: if squid-deb-proxy-client is installed, will it fall back to "regular http" if the proxy can't deliver?
<cjwatson> Laney: LP still won't let me
 * cjwatson asks #launchpad
<Laney> cheers
 * Laney rips off edit_acl.py
<mvo> dholbach: archive.c.c I think makes sense, not sure about ppa
<dholbach> mvo: what about the other question? :)
<dholbach> mvo: will apt fallback to regular http if the proxy doesn't do "ppa.launchpad.net" for example?
<davmor2> pitti: what would stop my camera showing up at all?  Is is a dbus thing I want to file a bug but I'm not sure against what.
<davmor2> pitti: infact scrap that, things just got weirder my camera is showing up as a media player in RB rather than as a camera
<tkamppeter> pitti, hi
<znh> Hello. Are there any plans for releasing Firefox 3.6? It fixes a serious remote exploit bug.. My 9.10 only offers 3.5.8
<pitti> davmor2: can you please do "ubuntu-bug storage" with the camera? that'll collect all the necessary info for me
<pitti> hi tkamppeter
<davmor2> pitti: np's thanks
<lool> mvo: Heya; when creating a pbuilder env today, I got: /usr/lib/apt/methods/http: symbol lookup error: /usr/lib/apt/methods/http: undefined symbol: _Z14maybe_add_authR3URISs
<lool> mvo: I'm quite surprized that /usr/lib/apt/methods/http breaks -- it's from the apt package and should move with the rest of the APT ABI?!
<tkamppeter> pitti, it is about HPLIP FTBFS, our buildds does not identify itself as a Ubuntu box with lsb_release and so a Ubuntu-only patch does not work.
<pitti> tkamppeter: they should
<pitti> tkamppeter: I have many packages which rely on that
<pitti> tkamppeter: did you add an lsb-release build dependency?
<davmor2> pitti: bug 544994, I've assigned it to you and added a snapshot of it showing up in rb and not nautilus.
<ubottu> Launchpad bug 544994 in linux "Fugi FinePix S5800 is showning up as a media player and not a camera" [Undecided,New] https://launchpad.net/bugs/544994
<tkamppeter> pitti, no, I did not, I simply assumed that it is standard.
<Keybuk> 15 conflicts encountered.
<Keybuk> zsh: exit 1     bzr merge lp:plymouth
<Keybuk> *cry*
<pitti> davmor2: thanks
<lool> mvo: Apparently specific to cowbuilder, worked with pbuilder so I've used that
<geser> pitti: is apport tested with the new 1.0 LP API? as the beta API is EOL in April 2011. A quick grep shows that apport/crashdb_impl/launchpad.py still uses "transitionTo..."
<pitti> geser: oh, did that change?
<pitti> geser: I'm usually testing against staging, but unfortunately +storeblob is terminally broken on staging, so the test suite doesn't work any more
<geser> pitti: the beta API is still available but only till April 2011 (EOL of karmic), the 1.0 API is supposed to stay till EOL of lucid (April 2015) [see https://edge.launchpad.net/+apidoc/]
<pitti> geser: would you mind creating/assigning a bug to me about it? (I've been knee-deep in gdm/gsd keyboard code for 4 hours now, and want to finish this first)
<geser> pitti: the main difference between the "beta" and "1.0" API is that the removal of mutator methods (for e.g. status, importance, assignee)
<geser> pitti: sure
<pitti> geser: danke
<mvo> lool: very odd indeed
<mvo> lool: reproducable?
<lool> mvo: No, but I upgraded my system in the meantime
<lool> I had already updated this morning though
<lool> This is really werid
<lool> mvo: I don't know what happened the first ime
<lool> sudo cowbuilder --create --distribution lucid was how I got it
<Keybuk> note-to-self ... teach slangasek about "sending patches upstream" :p
<matumba> davmor2, just confirmed bug 544994
<ubottu> Launchpad bug 544994 in linux "Fugi FinePix S5800 is showning up as a media player and not a camera" [Undecided,New] https://launchpad.net/bugs/544994
<pabs3> where would I complain about unsolicited email from Canonical?
<highvoltage> pabs3: would that be an email to test landscape perhaps?
<pabs3> yes
<cjwatson> pabs3: apparently this was only meant to have been sent to people who were current candidates for jobs at Canonical, but was mistakenly sent to rather more people than that; the Landscape people are looking into it
<cjwatson> pabs3: (it has nothing to do with me ...)
<directhex> pabs3, yours is the second complaint i've seen
<libv> why would this interest even current candidates?
 * pabs3 agrees with libv
<highvoltage> 4th I've seen, but I just pasted them all what cjwatson said :)
<elmo> it wasn't meant to be sent to current candidates
<highvoltage> (mistakes happen)
<libv> i also wasted time on this, not knowing what it was.
<davmor2> matumba: Thanks :)
<pabs3> cjwatson: thanks for the info, I'll refrain from mailing abuse@c.o and mark
<cjwatson> current candidates> oh, ok
<cjwatson> highvoltage: I've accepted the invitation for developer-membership-board to join edubuntu-dev; can you make it an admin?
<blackxored> Hello guys, I've received an invitation for Landscape through mail, what's the meaning of it, Pici told me it was a mistake of some sort, can you enlighten me with this?
<highvoltage> cjwatson: done
<cjwatson> highvoltage: thanks
<directhex> blackxored, <cjwatson> apparently this was only meant to have been sent to people who were current candidates for jobs at Canonical, but was mistakenly sent to rather more people than that; the Landscape people are looking into it
<cjwatson> I was wrong about "current candidates", I'm told, but I don't have further details
<blackxored> directhex, thanks
<ogra> Riddell, can you let u-boot-omap out of binary NEW ?
<Keybuk> silly xorg-edgers PPA
<highvoltage> Keybuk: do you perhaps happen to know how to dry-run plymouth to test a theme?
<Keybuk> sure
<Keybuk> plymouthd ; plymouth --show-splash
<Keybuk> :D
<Riddell> ogra: accepted!
 * ogra hugs Riddell 
<ogra> just in time for mobile meeting :)
<Keybuk> highvoltage: try it in X ... you may be surprised
<highvoltage> Keybuk: ok :)
<highvoltage> Keybuk: nice, thanks!
<Keybuk> plymouth quit to get rid of it, obviosuly
<Keybuk> you have two windows of different sizes so you can make sure your theme works with multi-head
<sivang> hi all, I am trying to registera new blueprint
<highvoltage> Keybuk: ah, clever!
<sivang> choosing hte Ubuntu project says it is too wide and I Have to narrow my search
<sivang> what is the correct project name for hte operating system project?
<tkamppeter> pitti, thanks, new HPLIP is uploaded and did not give any FTBFS.
<sivang> anybody knows if davd ben simon lurks around here ?
<sivang> *david
<cjwatson> stgraber: where does the LTSP squashfs need to go on the Edubuntu DVD?
<nigelb> pitti: are you aware that python throws up a small error while apport attaches the hardware information (only seen on cli)?
<mrand> I asked in upstart and they recommended I move here.... Is  $LANG  an acceptable (and expected to be future supported) way to support locales in upstart?  If not, could someone recommend something else?  This is in reference to this potential patch for MythTV that is attached to https://bugs.launchpad.net/bugs/541042
<ubottu> Ubuntu bug 541042 in mythbuntu "locale is not set up before mythtv-backend start" [Medium,Triaged]
<stgraber> cjwatson: ltsp/i386.img would be great
<stgraber> highvoltage: ^ just so you know where it'll be ;)
<highvoltage> stgraber: ok thanks
<cjwatson> stgraber: that's the path from the root of the image?  how about amd64 images?
<cjwatson> stgraber: is it necessary to put the architecture name in the image filename?
<highvoltage> cjwatson: for now we're going to stick with only i386 images for the live infrastructure, if someone needs amd64 they'll have to install
<cjwatson> so I should do this only for the i386 Edubuntu DVD image?
<highvoltage> cjwatson: the i386 chroot will work on the amd64 disc (or at least, there's no reason why it shouldn't), so we'd like it on the amd64 discs as well
<highvoltage> right stgraber?
<cjwatson> hmm.  cross-architecture stuff might be tricky.
<cjwatson> I'll see what I can do
<highvoltage> cjwatson: many people use amd64 servers with i386 ltsp chroots, it's a common use case.
<highvoltage> cjwatson: ah you meant from a built perspective? sorry I think I'm with you now.
<highvoltage> (s/built/build/)
<cjwatson> that's what I mean, yes
<stgraber> cjwatson: it's the i386.img for both amd64 and i386, so path is the same on both
<stgraber> looks like highvoltage was a lot faster than me on that one ;)
<highvoltage> stgraber: there shouldn't be any build issues right? you'd just have to pass --arch for the debootstrap on the amd64 build host?
<cjwatson> nah, will just fetch the i386 build for the amd64 CD build too
<cjwatson> no point building it twice if it's just the same
<highvoltage> that sounds good.
<stgraber> highvoltage: sure we could build it twice but we'll save quite a few mins of build time if we don't
 * Keybuk crosses his fingers and does the "please don't crash my X server" dance
<Keybuk> COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
<Keybuk> Xorg       1027 root    5u   CHR    4,7      0t0 1302 /dev/tty7
<Keybuk> lt-plymou 18140 root    0u   CHR    4,7      0t0 1302 /dev/tty7
<Keybuk> lt-plymou 18140 root    1u   CHR    4,7      0t0 1302 /dev/tty7
<Keybuk> lt-plymou 18140 root    2u   CHR    4,7      0t0 1302 /dev/tty7
<Keybuk> hmm
<Keybuk> I wonder if there's a magic lsof flag to tell me which of those is the process group leader for the tty
<psusi> you mean between 1027 and 18140?  ps should tell you no?
<mrand> Keybuk: ps -f lists parent PID
<Keybuk> no, that tells you their pgid ;)
<Keybuk> I want to know which one is controlling that terminal
<doko_> smoser, any feedback on 542395?
<smoser> doko_, i will test right now. i'm at a hotel with 40k download cap
<smoser> spent last night downloading
<smoser> :)
<doko_> smoser: thanks, no haste!
<smoser> doko_, fixed. thank you.
<doko_> smoser: ok, closing
<smoser> already did.
<cjwatson> stgraber,highvoltage: er, yeah, so ignore the Edubuntu DVD build I just did please, it turns out it helps to use the correct squashfs
<cjwatson> rebuilding ...
<highvoltage> ok
<rafiyr> Does the 10.04 installer account for ssd block sizes when partitioning and setting up file systems?
<highvoltage> Keybuk: # #2c001e --> 0.16, 0.00, 0.12 <- how does that conversion work!?
<Keybuk> highvoltage: ask tseliot ;-)
<highvoltage> Keybuk: ok :)
<Keybuk> though it's roughly right isn't it?
<highvoltage> I'm not sure what 0.16 means. afaik 2c = 44.
<Keybuk> 0.16 means 0.16
<Keybuk> 16%
<Keybuk> etc.
<highvoltage> ah! got it
<tseliot> highvoltage: I'm pretty sure I put this bit of information in the code but anyway, you need the rgb values
<Keybuk> tseliot: though, 2c isn't 0.16 ;-)
<tseliot> highvoltage: and then you'll have to divide them by 256
<highvoltage> tseliot: heh, it seems mentioned everywhere in the theme except where I was working on atm (the background colours), I'll add it there for the edubuntu theme just in case someone wonders again
<tseliot> example: #ffffff => RGB 255 255 255 => 1 1 1
<tseliot> :-)
<Riddell> apw: linux-meta-qcm-msm for main or universe?
<tseliot> Riddell: news on the kubuntu bootsplash theme?
<pitti> kirkland: http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html
<pitti> kirkland: I caught up! :-)
<Riddell> tseliot: we have some designs, nothing final yet.  maybe it's worth making the package now with a filler logo to get the technical side sorted?
<tseliot> Riddell: it's bug ##507238
<tseliot> bug #507238
<ubottu> Launchpad bug 507238 in plymouth "No alternatives support for default theme yet, all themes in main package" [Medium,Triaged] https://launchpad.net/bugs/507238
<tseliot> Keybuk: I won't upload my smooth transition patch for kdm (which I need to clean up anyway) until you upload your fix for plymouth so that quit and deactivate work correctly when X fails
<Riddell> bryceh: do we want wacom-tools back in the archive?  removal log says "renamed to xf86-input-wacom"
<cjwatson> rafiyr: yes, though it's a first attempt at doing so and it may be wrong
<Keybuk> tseliot: that should be today
<Keybuk> I have it merged in my working tree
<Keybuk> and I'm just fixing your plugin ;-)
<rafiyr> cjwatson: thanks.
<tseliot> Keybuk: nice. Do you mean the 16 colours renderer or my theme?
<Keybuk> tseliot: your theme
<Keybuk> adding Window.GetX() + to various bits where you center them
<Keybuk> to be fair, Charlie only realised that this was needed yesterday
<cjwatson> rafiyr: are you having problems with it?
<Keybuk> but damn you for being insufficiently prescient :p
<tseliot> Keybuk: hehe. Why is that necessary? In case of multiple heads?
<Keybuk> tseliot: yup!
<rafiyr> cjwatson: not yet.  Just planning for a new machine, wanted to know if I should prepartition or let the installer have a go at it.
<Keybuk> multiple heads that are hardware offset
<Keybuk> ie. one overlapping the other
<Keybuk> plymouth gives you one big screen with two windows then
<Keybuk> apparently
<cjwatson> rafiyr: it should basically work it out - if nothing else, if it can't figure out anything better, it tends to align things to 1MiB boundaries now
<cjwatson> which is better for most SSDs, slightly less friendly to 1980s-era Winchester hard disks, and makes little difference on anything else :-)
<rafiyr> cjwatson: Good to know.  mostly thinking about performance.
<rafiyr> cjwatson: ya wouldn't be so good to give the first 1MB to the partition table and boot block on my 5MB drive.
<tseliot> Keybuk: BTW the version of plymouth I've been working with didn't have getters for coordinates yet, so no GetX(), etc. That would allow me to clean up my code a bit
<rafiyr> cjwatson:  Though I mostly just keep the 14" platters hanging on the wall instead of trying to run bloated systems like linux off them.
<Keybuk> tseliot: is all pushed if you want to play
<Keybuk> plymouthd;plymouth --show-splash works just fine in X now
<Keybuk> so you can send messages, get keys, etc.
<cjwatson> rafiyr: was more thinking about the fact that disks that really had 63-sector cylinders tended to like partitions to be aligned on them
<Keybuk> and see the different effect on the two "heads"
<cjwatson> rafiyr: which is why most people's /dev/sda1 is 32.5KiB from the start of the disk
<tseliot> Keybuk: very nice. The only problem with the X renderer, from what I remember, was that hiding the splash would freeze X as plymouth seemed to mess with drm
<rafiyr> cjwatson: fair point.
<Keybuk> tseliot: I fixed that :p
<Keybuk> (current lucid has the fix)
<tseliot> Keybuk: fantastic. We should add your photo to the Ubuntu logo in the bootsplash :-)
<tseliot> (but then you would have to render it in 16 colours :-P )
<Keybuk> haha, why my photo?
<tseliot> because without you plymouth in Lucid would still be in a rather sorry state ;)
<Keybuk> as long as I get the credit, and someone else gets the blame :p
<tseliot> let's rename it as it Plybuk or PlyScott :-P
<matumba> a bit OT: how about not naming the purple color PLY_TERMINAL_COLOR_BLACK? :P
<kusum> cjwatson: Hello SIr
<Keybuk> matumba: because it's black
<Keybuk> matumba: we don't invent a new terminal colour called PURPLE and use that
<Keybuk> matumba: we reprogram the VGA to make the existing black colour more purple ;-0
<matumba> Keybuk, i see
<kusum> matumba: Keybuk : Hello
<cjwatson> kusum: hello?
<Keybuk> matumba: http://people.canonical.com/~scott/purple.py
<Keybuk> matumba: ^ run on a text VT
<Keybuk> kusum: hello
<Keybuk> tseliot: so OOI
<Keybuk> tseliot: is the background supposed to be #2c001e or #27001d ?
<kusum> cjwatson: Could you give me some guidelines on how to go about it
<tseliot> Keybuk: let me check
<cjwatson> kusum: I don't know how Pardus is organised.  We integrated Wubi into the Ubuntu installer so that Wubi just had to set up a preseed file and then press go
<cjwatson> kusum: but the expertise required for the changes I made was expertise in the Ubuntu installer, not expertise in Wubi
<cjwatson> kusum: since I don't know how the Pardus installer works, I'm not well-placed to advise on what you would need to do to it
<kirkland> pitti: woohoo!
<kusum> Could you tell me your primary changes you made in Ubuntu installer?
<cjwatson> kusum: you need something that can automatically create loop-mounted filesystem images on NTFS and install the operating system into those; and you need something that can deal with booting from that (sufficiently recent version of grub2, but you need to be careful with the integration; also something in your initramfs)
<cjwatson> kusum: mainly writing the 'partman-auto-loop' component to do the automatic partitioning and loop-mounted-image creation
<cjwatson> kusum: and tweaking the boot loader installation component to handle slight differences in the configuration file it needed to write
<kusum> now that will differ for pardus or can i port partman-auto-loop directly to pardus?
<cjwatson> I have no idea what installation system pardus uses
<Keybuk> right, time to read the update-alternatives man page again
<Keybuk> if you don't hear from me within a couple of hours, send rescue parties
<cjwatson> unless it's pretty closely based on the Debian or Ubuntu installer, you'll have to rewrite it
<kusum> cjwatson: so partman-auto-loop works while ubuntu installation is in progress ??
<cjwatson> similarly, unless Pardus' initramfs framework is initramfs-tools, you'll have to rewrite the stuff that deals with booting off a Wubi-created image
<cjwatson> yes
<kusum> how does it know when the installation has taken place via wubi and when a normal installation is being taken place?
<cjwatson> Wubi tells it, using a preseed file (which is the standard way to automate the Debian/Ubuntu installer)
<cjwatson> if you aren't using d-i as your installation system, you'd have to invent some other way
<kusum> ohh ok
<kusum> do you have some idea about what happens on windows when wubi starts till the restart option is pressed?
<lamont> asac: I was recovering from my lucid upgrade yesterday
<tseliot> Keybuk: I think it's #2c001e why are you asking?
<cjwatson> kusum: very little - Agostino Russo did most of the Windows-side stuff
<kusum> cjwatson: Can you tell me the best way i can reach him ??
<Keybuk> tseliot: because that's not what you render ;-)
<Keybuk> tseliot: you render 27001d ;-)
<cjwatson> kusum: I don't like giving out other people's contact details, but I'm sure if you hunt around in the Wubi source code you'll find him
<tseliot> Keybuk: some rounding madness perhaps?
<Keybuk> tseliot: no, I just think you can't add ;-)
<tseliot> let me check
<asac> lamont: hi
<Keybuk> tseliot: 2e=44 44/256 = 0.17*something*
<cjwatson> him -> his e-mail address
<asac> lamont: all fine now? ;)
<tseliot> Keybuk: it could be :-P
<kusum> cjwatson: i did contact him on his gmail
<kusum> no reply
<cjwatson> kusum: that's the only address I've ever used; he's probably just busy
<cjwatson> kusum: he hasn't been around a great deal recently
<kusum> I wish to apply for this project in Google summer of Code 2010
<lamont> asac: fine is a relative term.  my home directory is now roughly 280GB smaller
<lamont> some would consider this a positive thing
<kusum> so any details like you just mentioned would be of really great help to me for getting selected
<lamont> in fact, that's the one thing left for me to do - recreate the home partition and migrate /home off this root to that one.  though maybe I won't until I've verified that I can tell d-i to put /home $THERE without formatting the partition.
<cjwatson> kusum: it looks like Pardus uses its own entirely custom installer, so my suggestion would be to get very familiar with how it handles partitioning configuration and boot loader installation
<kusum> cjwatson: Thanks  a ton for patiently telling me everything
<tseliot> Keybuk: right, it was definitely a typo (as I don't do any kind of calculation myself when I'm tired)
<cjwatson> kusum: you can download the wubi, lupin, and partman-auto-loop components from launchpad.net and study them to figure out roughly how they work
<kusum> cjwatson: yes i will do that
<cjwatson> maybe the Ubuntu version of grub-installer too
<asac> lamont: poor thing your /home ;). so i guess no new builders anytime soon? if you could get one up i would like to try one build that fails because of thumb2 SIGILL on our current builders
<asac> otherwise i can just upload with -marm
<lamont> asac: assuming I can get it to do something, builder today.
<asac> we decided that that was good enough for libplist
<tseliot> Keybuk: also, I have some experience with alternatives (see nvidia, fglrx), so if you have doubts on update-alternatives, just let me know
<asac> lamont: cool. i will wait. ;)
<lamont> when they power up, these boards should spew at the serial, yes?
<asac> lamont: let me know if youz want to run a pipecleaning build ;)
<cjwatson> asac: has anyone sent this klibc patch upstream, and is it ready to upload or not?  (presumably for upstream inclusion it might need conditionals or something, since I assume it breaks older arm chips?)
<asac> lamont: yes. you need to tweak kernel command line though
<lamont> asac: what's your favorite package these days
<lamont> asac: I meant from boot rom...
<asac> lamont: libplist ... a give back on more modern builders should help
<asac> lamont: yes. boot rom gives you console
<asac> on serial
<asac> cjwatson: let me check
<lamont> right.  off to do the investigative stuff.
<lamont> 9600 8N1? or what speed?
<asac> cjwatson: what patch are you talking about? is that in the package or just in a bug?
<asac> lamont: 115200 works for us
<cjwatson> asac: the one you filed as bug 527720
<ubottu> Launchpad bug 527720 in klibc "thumb2 porting issues identified: klibc uses mov.*pc" [High,Triaged] https://launchpad.net/bugs/527720
<cjwatson> I'm not sure why you filed a bug rather than just uploading it, but I assumed that maybe this was because it needed some kind of review or something?
<lamont> asac: ta
<stgraber> cjwatson: that build would be 23.2 right ?
<cjwatson> stgraber: it would be, but it fails
<cjwatson> failed
<asac> cjwatson: bx is safe for armv4t and above
<asac> thats pretty old stuff
<cjwatson> asac: could you send it upstream?  klibc@zytor.com
<Keybuk> cjwatson: if I do Recommends: plymouth-theme-ubuntu-logo | plymouth-theme - will germinate do the right thing?
<cjwatson> what do you want the right thing to be? :)
<Keybuk> include that package on the CD
<cjwatson> then yes
<Keybuk> while allowing people to remove it and replace it with silly animated stars
<cjwatson> not Depends, given the alternative dep?
<cjwatson> you want it to be entirely removable as well?
<Keybuk> I'm going to make Plymouth a Depends of mountall
<Keybuk> but people still should be able to remove the themes
<Keybuk> if you remove its themes, it'll go back to just ordinary text mode
<cjwatson> hmm
<cjwatson> debootstrap doesn't follow Recommends
<Keybuk> ah, meh
<cjwatson> I'd recommend that you seed a plymouth theme package explicitly
<Keybuk> right
<Keybuk> that makes sense
<ccheney> anyone familiar with inkscape that could look at bug 529625?
<ubottu> Launchpad bug 529625 in inkscape "Sync openclipart 0.18+dfsg-9 (universe) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/529625
<lamont> asac: 115200 gives me line noise
<asac> strange. then i guess i am looking at the bootloader output
<asac> do you have a SD card inserted
<asac> ?
<lamont> could be "no"
<lamont> were they shipped with them?
<lamont> or do we need to get them?
<asac> lamont: you need to get one, yes.
<asac> lamont: they also came with one, but not with our
<asac> lamont: without SD card this thing shouldnt stay on at all?
<asac> does it stay on?
<lamont> ah, right.  so I do all the magic and love, write the sd card, then stuff it in the machine and boot?
<asac> yep
<lamont> how big?
<asac> lamont: ogra can give you a bootable image
<asac> either installer image (from our cdimage server)
<asac> lamont: 4G is what we usualy use to be safe
<lamont> ah, cool
<asac> lamont: i would suggest to take the alternate installer ... want to install lucid right away?
<asac> or rather karmic? (i think lucid would be better if you dont mind that its not final yet)
<lamont> lucid
<lamont> assuming I can just dist-upgrade it once installed
<asac> lamont: you can either use installer and install it on harddisk or get a special image from ogra, so the main system stays on SD
<lamont> well, make that: I assert that I can dist-upgrade it once installed, regardless of the karmic vs lucid discussion
<lamont> hard disk
<asac> you then mount the builder disk from there
<ogra> lamont, how about http://ports.ubuntu.com/ubuntu-ports/dists/karmic/main/installer-armel/current/images/imx51/netboot/babbage-TO2/babbage-TO2-sd.img
<ogra> :)
<asac> lamont: yes, you can dist-upgrade ... even if you use a sd
<lamont> that's a win
<ogra> thats d-i netinst .... just dd to an SD card
<lamont> ogra: so write that image to the SD, stuff it in, and it should boot into the installer?
<ogra> yep
<lamont> ta
<lamont> dd to card, yes?
<asac> yeah
<ogra> yep
<ogra> the card will be re-used as bootfloppy
<ogra> dont pull it out after the install :)
<unggnu> hi all
<cjwatson> asac: hm, you seem to have missed a few instances of code matching 'mov.*pc'
<asac> cjwatson: we are checking something here atm
<asac> cjwatson: currently its build with armv4 etc.
<unggnu> Is it a known "bug" that with the standard theme of Lucid Firefox URL suggestions are hardly readable?
<lamont> ogra/asac: once installed on the HD, does the SD card need to remain?
<ogra> yes
<asac> cjwatson: so we might not need it if there is a rason its using that
<lamont> unggnu: it's even a filed bug
<ogra> it is turned into a bootfloppy
<unggnu> blue und dark grey isn't so great
<lamont> ogra: ah, so the install process overwrites the SD card?
<cjwatson> oh, maybe not, some of this is in an ifdef
<ogra> right
<unggnu> lamont, ok
<asac> on a call now
<lamont> ogra: ta
<cjwatson> asac: I'm getting confused by the fact that half of your patch is a unified diff and half of it is a context diff, I think. :-)
<asac> cjwatson: yes. ignore that for now. i will sort that and let you know ;)
<cjwatson> asac: ok, please just go ahead and upload once you're happy with it, and send it upstream
<asac> yep
<asac> will do
<unggnu> lamont, Do you have the bug number?
<asac> cjwatson: we are unsure about the whole options currently used. when is klibc exactly used?
<cjwatson> unggnu: google 'ubuntu firefox blue grey site:bugs.launchpad.net' - first hit
<cjwatson> asac: in the initramfs
<cjwatson> bug 532259
<ubottu> Launchpad bug 532259 in light-themes "Dark text on Dark background dropdown list firefox" [High,Confirmed] https://launchpad.net/bugs/532259
<unggnu> cjwatson, I used the bug tracker search :/
<unggnu> thx anyway
<lamont> ogra: them bits want to go on p1 or the non-partition base of the card?
<ogra> the bootloader, kernel and initramfs, yes
<lamont> ogra: so the .img file... do I just stuff that on /dev/mmcblk0 or on ...p1?
<ogra> mmcblk0
<ogra> just dd it to the device
<lamont> cool.  I suspected such
 * cjwatson sighs and runs edubuntu-dvd again
<highvoltage> cjwatson: thanks!
<unggnu> Is there an ubuntu channel for the music store?
<jcastro> unggnu: #u1msbeta
<unggnu> thx
<cjwatson> stgraber,highvoltage: http://cdimage.ubuntu.com/edubuntu/dvd/20100323.4/ - would appreciate testing (it might not have the i386 image yet, but it's on the master machine so it should get round to it)
<highvoltage> cjwatson: ok, starting an rsync...
<mathiaz> cjwatson: hi
<mathiaz> cjwatson: I'm trying to run a preseed -server install using the beta1 amd64 iso
<mathiaz> cjwatson: I run into an warning: debootstrap warning
<mathiaz> cjwatson: Warning: restricted/binary-amd64/Packages was corrupt
<kusum> mathiaz: Can you tell me what exactly a preseed file does?
<mathiaz> cjwatson: I'm using a local http webserver where I've exploded the content of the beta1 server iso
<mathiaz> cjwatson: using bsdtar
<kusum> mathiaz: Hello
<mathiaz> kusum: https://help.ubuntu.com/9.10/installation-guide/amd64/appendix-preseed.html
<cjwatson> mathiaz: um, no idea, I have to say I've never supported exploding a CD image like that although people keep trying to do it
<cjwatson> mathiaz: you'll have to trace through the files it's downloading and try to figure out which checksum it's comparing against, I think
<kusum> mathiaz: thank you
<mathiaz> cjwatson: I guess I'll have to run the installation in debugging mdoe?
<mathiaz> cjwatson: the syslog I have doesn't seem to mention anything with mismatch checksum
<cjwatson> mathiaz: debugging mode probably won't help, you'll have to figure out what command it's running and dig into it from there
<cjwatson> get the debootstrap source and search for the error message there (it's in the 'get' function, look for CORRUPTFILE)
<mathiaz> cjwatson: ok - thanks for the pointer
<cjwatson> maybe put 'set -x' at the top of /usr/share/debootstrap/functions to get a shell trace
<cjwatson> mvo: any news on whether the python-apt FFe is going to happen?
<Sarvatt> cjwatson: if you remember the the grub2 gfx-payload=keep efifb problem from a month or two ago, once lucid+1 has a new kernel it shouldn't be a problem anymore because efifb was fixed in .33 to properly handoff to a KMS fb
<cjwatson> Sarvatt: still not sure it makes a whole lot of sense to cause efifb to start when the system *isn't EFI*
<mvo> cjwatson: the exception got granted, I will upload today
<bdrung_> i am member of ubuntu-sponsor, but i can't unsubscribe ubuntu-{main,universe}-sponsor.
<mvo> cjwatson: the bzr tree is ready, I just need to silence the deprecation warnings by default now
<cjwatson> mvo: cool, thanks
<cjwatson> seb128: is there any chance that bug 519035 could be fixed for lucid?  it particularly affects the installer.  I tried to apply Thomas' patch to test this out, but I think I screwed something up - see the upstream bug trail
<ubottu> Launchpad bug 519035 in hundredpapercuts ""(as superuser)" is appended to titles of windows owned by root" [Low,Triaged] https://launchpad.net/bugs/519035
<seb128> cjwatson, in a meeting right now but I will try to have a look later
<cjwatson> seb128: mm, actually, the upstream bug I'm thinking of is https://bugzilla.gnome.org/show_bug.cgi?id=605137, which merely asks for a way to turn it off, not quite the same as that Ubuntu bug
<seb128> I didn't touch that package for ages though
<ubottu> Gnome bug 605137 in general "way to suppress "(as superuser)" message" [Enhancement,Assigned]
<cjwatson> seb128: but a way to turn it off would be lovely
<seb128> so if you or mvo just want to back out to change or whatever please do
<cjwatson> ok, is didrocks the person to talk to?
<seb128> we sort of don't have a maintainer for this one, or nobody really active on it, so I guess it's first one who has a free slot for it sort of thing
<ccheney> after looking at the inkscape bug list it looks like it is in pretty bad shape with the number of high heat crasher bugs
<cjwatson> hm, ok, I don't know how I feel about backing it out totally
<didrocks> cjwatson: can maybe have a look at it on Thursday
<asac> cjwatson: so discussing this in -arm we wondered why klibc is in ubuntu at all? seems curently klibc uses a complete different abi for arm - is it really worth investigating rather than moving the stuff that still build depends on it to glibc?
<cjwatson> although compiz has no such superuser notification, I think
<cjwatson> didrocks: thanks
<cjwatson> asac: too much effort to unwind its use from the initramfs
<asac> dmart  summon ;)
<didrocks> cjwatson: not sure how it works, I'll just give it a try :)
<seb128> cjwatson, no compiz doesn't, I would just drop it
<dmart> cjwatson: On #ubuntu-arm we're discussing klibc.  It looks like it may be unused in the initramfs, and built with incompatible compiler options from the distro defaults for armel.  Do you know the background to why klibc is present / needed?
<cjwatson> dmart: it is most certainly used in the initramfs.
<asac> cjwatson: what is that? we need to double check that that is using the same options at least
<cjwatson> not as extensively as it used to be, but it's used
<asac> i see dmraid, rootskel and cowdancer
<asac> as the only build-rdepends
<cjwatson> if you don't have klibc in your Ubuntu initramfs, your initramfs will (if nothing else) fail to chain to upstart
<cjwatson> some of the programs from klibc-utils are used in core initramfs code
<cjwatson> /usr/share/initramfs-tools/init:264:exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console 2>&1
<cjwatson> for instance
<cjwatson> eventually we'd like to get rid of that, quite possibly by moving to dracut or similar - I don't feel good about trying to unpick that stuff after beta though
<ogra> but couldnt run-init and friends just link against glibc ?
<cjwatson> run-init is part of the klibc source code
<cjwatson> sure, you could rewrite it, and you'd have to track down all the new bugs
<ogra> ah
<ion> keybuk: I wonder, could Plymouth launch the text plugin ASAP and just switch to a FB plugin when a FB becomes available?
<cjwatson> I'd have been happy to take that on at the start of a release cycle
<cjwatson> but definitely not for lucid
<Keybuk> ion: how would that help?
<cjwatson> dmart: in this case, does it really matter if it's using a different ABI?  it's a couple of small programs that don't really interact with much else
<ion> keybuk: The screen would say âUbuntu 10.04â or whatever instead of being blank with just a cursor for several seconds.
<cjwatson> they're essential in and of themselves, but ...
<Keybuk> ion: *shrug* I'd rather shorten the several seconds
<asac> cjwatson:  for stuff that build-depends against on it we need to check that they use the same abi etc at least (if they link against it)
<bdrung_> can someone unsubscribe ubuntu-main-sponsors from bug #544904?
<ubottu> Launchpad bug 544904 in xserver-xorg-video-sis "please sync xserver-xorg-video-sis 1:0.10.2-2 from Debian unstable main" [Wishlist,Triaged] https://launchpad.net/bugs/544904
<asac> cjwatson: but thanks. we will check those now
<cjwatson> the rootskel dep is for code not used in Ubuntu
<ion> keybuk: Until we have magic filesystem block reordering, weâll probably need ureadahead, and as long as computers have HDDs, ureadahead needs to defer everything else, and as long as that happens, weâll have the uncomfortable period of screen being blank.
<dmart> cjwatson: We could have an incompatible ABI for klibc and the binaries built on it, but I'd prefer if we could synchronise with the defaults --- otherwise there's a problem keeping compile options in sync between klibc and its build-rdepends.
<Keybuk> ion: no ;)
<dmart> asac, shall we give the lucid defaults a try for this and see how we get on?
<asac> dmart: yes. lets try that .. see -arm
<asac> if nothing works we just need to remember to review all rdepends
<cjwatson> the dmraid dependency is, I think, stale
<cjwatson> I can't say I care about cowdancer, and haven't looked
<cjwatson> and klibc-utils will certainly be built with the same compiler options as libklibc
<lamont> asac: is it supposed to say something after finding the USB hub and freeing init memory?
<asac> right. what does "stale" mean?
<cjwatson> so I think we're fine
<lamont> please tell me it doesn't require dhcp
<cjwatson> asac: dmraid has a klibc configure option, but I don't think we ever turn it on
<asac> lamont: are you at bootloader ?
<asac> or booted?
<cjwatson> bdrung_: done, do you want to subscribe ubuntu-sponsors?
<lamont> Freeing init memory: 176K
<lamont> usb 1-1: new high speed USB device using fsl-ehci and address 2
<lamont> u
<lamont> and 7 ports on the usb hub.
<lamont> and full-stop
<bdrung_> cjwatson: nope. i acked it.
<asac> lamont: you might need to add console=ttymxc0,115200  to the kernel line
<lamont> ah, can I interrupt the boot process to get control to do that?
<asac> lamont: i think its ctrl-c
<asac> ogra: ^^ how to aboard bbg boot?
<asac> lamont: i think its printed on the serial line what to do
<ogra> yeah ctrl-c
<lamont> woot
<ogra> i think redboot even says so
<asac> it tells you something like "3.00 seconds (hit ctrl-c for a prompot)"
<bdrung_> cjwatson: if you want to unsubscribe ubuntu-main-sponsors and subscribe ubuntu-sponsor take these: https://bugs.launchpad.net/~ubuntu-main-sponsors
<lamont> ok... now that I'm sitting at the redboot prompt... what do I type?
<lamont> (iz wiki page I should read?)
<ogra> you shouldnt even have to be there at all
<lamont> well, lack of network might have something to do with it.  no dhcp
<lamont> nor can I fix that
<lamont> not this month anyway
<ogra> if the thing doesnt boot the redboot prompt wont help you
<lamont> well, I get as far as freeing init memory and device discovery.. then it just sits
<ogra> the point is that d-i and its initrd.gz are contained in the SD img
<ogra> it should get you to a d-i screen
<ogra> oh, hmm
<lamont> well, then.  let me say 'reset' and see how much better it does.
<ogra> do you have a DVI capable monitor around ?
<lamont> heh.  not a chance
<ogra> it might default to DVI
<ogra> so lets do that
<ogra> at the redboot prompt type fconfig
<ogra> hit enter
<ogra> it goes to "do you want to run a bootscript"
<lamont> do these things at least power on on power application?
<ogra> i dont think the new ones do
<ogra> but they dont crash :)
<ogra> so the power issue is a lot less critical
<lamont> ok.  remote hands have cycled it again for me.
<lamont> ogra: so... I do want to update the config at the end of all those questions, having dropped console=tty0 from the string
<lamont> ?
<lamont> oh, look.  DI
<ogra> :)
<cjwatson> Sarvatt: actually, having looked at the efifb code, it might not be so bad, it doesn't really seem to do anything EFI-specific once it's set up properly
<cjwatson> Sarvatt: so thanks
<cjwatson> bdrung_: certainly not doing that by hand in the web interface, but I'll have a look via the API
<bdrung_> cjwatson: you could extent the script to support ubuntu-universe-sponsors, too
<cjwatson> bdrung_: somebody else could, I'm not a member of u-u-s
<mrand> I asked in upstart and they recommended I move here.... Is  $LANG  an acceptable (and expected to be future supported) way to support locales in upstart?  If not, could someone recommend something else?  This is in reference to this potential patch for MythTV that is attached to https://bugs.launchpad.net/bugs/541042
<ubottu> Ubuntu bug 541042 in mythbuntu "locale is not set up before mythtv-backend start" [Medium,Triaged]
<lamont> ogra: lunch for me, then I have a little bit of network config to do to make the machine have connectivity, then should be happy happy
<ogra> lamont, it might be that you need multiple runs of the network setup, the NIC is a bit nasty to bring up in the d-i env
<ogra> its not integrated with the kernels PHY layer ...
<AnAnt> Hello, regarding plymouth theme, will there be some technique (such as update-alternatives) to ease branding ?
<highvoltage> AnAnt: yep, there is
<AnAnt> highvoltage: how ?
<highvoltage> AnAnt: for Lucid, you'll run something like /usr/sbin/plymouth-set-default-theme --rebuild-initrd edubuntu-logo
<highvoltage> AnAnt: that replaces the symlink in /lib/plymouth to that theme
<highvoltage> AnAnt: in Lucid+1 it will probably be changed to use alternatives
<AnAnt> highvoltage: I see, thanks
<highvoltage> you're welcome
<AnAnt> ok, another question, it seems that xsplash isn't used anymore, why is it still installed in lucid ?
<highvoltage> probably a bug.
<cjwatson> it's not still installed in new installations, as far as I can see
<cjwatson> but nothing conflicts with it, so it doesn't necessarily get removed
<highvoltage> cjwatson: when I do an apt-cache rdepends xplash, I see a bunch of desktop meta-packages that depend on it, could that information perhaps be outdated?
<AnAnt> cjwatson: it is in beta1 live CD
<cjwatson> AnAnt: it's not in current dailies
<AnAnt> ah, that's good !
<cjwatson> dropped in ubuntu-seeds/ubuntu.lucid r1677
<mathiaz> cjwatson: so it seems that the Release on the isos includes a reference to the Packages file
<mathiaz> cjwatson: however the size of the Packages file is zero and is not included on the iso
<mathiaz> cjwatson: I'm referring to the -server beta1 iso
<cjwatson> mathiaz: the Packages files on the CDs only include the packages that are actually on the CD; furthermore, Packages itself is never included, as Packages.gz is sufficient and we need to save space
<cjwatson> mathiaz: so what you've described so far is as expected
<mathiaz> cjwatson: ok
<cjwatson> mathiaz: did you get that set -x trace of debootstrap?
<mathiaz> cjwatson: well - it's in the installer
<mathiaz> cjwatson: so I'm not sure how I can set debootstrap to run with set -x in the installer
<cjwatson> mathiaz: edit /usr/share/debootstrap/functions before it runs
<cjwatson> say, while it's sitting at a partitioning screen
<mathiaz> cjwatson: ah ok.
<mathiaz> cjwatson: I think I'll just hit the enter key for now
<cjwatson> bdrung_: practically all of those were in something other than Ubuntu (probably just old bug tasks).  I'm working through them
<cjwatson> bdrung_: in an lp-shell session, I entered http://paste.ubuntu.com/400105/, and then I'm just doing convert(lp.distributions['ubuntu']); convert(lp.projects['compiz']), etc.  I couldn't find an equivalent of ~person/+subscribedbugs across all distributions/projects, but TBH I didn't look very hard.
<smoser> pitti, are you around ? I've got an apport suggested change i'd like you to take a look at
<smoser> http://paste.ubuntu.com/400107/
<jdstrand> kirkland: hey. I see you fixed bug #545302 (thanks! :). fyi, examples/apparmor/libvirt-qemu did not need to be patched as it is installed as documentation (and quilt is in use)
<ubottu> Launchpad bug 545302 in libvirt "allow seabios in libvirt apparmor" [High,Fix released] https://launchpad.net/bugs/545302
<kirkland> jdstrand: ah, okay, sorry
<jdstrand> kirkland: no worries, just fyi
<kirkland> jdstrand: i was trying to get a fix published ASAP
 * jdstrand nods
<kirkland> jdstrand: b/c i think a lot of libvirt/kvm users were DoA
<jdstrand> sure
<cjwatson> mvo: did you notice that fglrx-modaliases is in restricted now?  causes update-manager to dep-wait ...
<kirkland> jdstrand: i don't need to undo that change, do i?
<mvo> cjwatson: oh, thanks. I did not notice
<mvo> why are the aliases in restricted?
<cjwatson> that I haven't looked into
<mvo> who moved it there?
<davmor2> mvo: Uncle Bulgaria from the wombles
<cjwatson> mvo: I don't think it's explicitly logged :(
<mvo> cjwatson: thakns, I will ask around to figure out more then
<mvo> thanks even
<barry> james_w: optimistic ping
<james_w> barry: surprising pong
<barry> james_w: wow, hi!  i've been doing a little more udd and had a couple of questions for you, if you have some time
<james_w> of course
<barry> james_w: thumper asked me to package lazr.enum for him, and i need the practice so i gave it a try.  there were two things (so far ;) that makes it a bit painful.  was wondering if you had ideas about how to improve things
<cjwatson> bdrung_: all done for main
<barry> 1) python setup.py --command-packages=stdeb.command sdist_dsc is painful
<barry> 2) debian/watch for launchpad download tarballs is painful
<barry> james_w: ^^.  there's an open bug on #2 but nothings been done about it
<james_w> 1) I'm not familiar with what that does, could you expand?
<james_w> 2) open bug on LP or uscan?
<barry> james_w: #1 is setuptools plugin that creates the debian directory, but it puts it in an inconvenient place and the results need some hackery
<barry> james_w: #2 on lp
<barry> james_w: bug 231797
<ubottu> Launchpad bug 231797 in devscripts "no sensible way to use debian/watch files with launchpad hosted tarballs" [Undecided,Invalid] https://launchpad.net/bugs/231797
<barry> james_w: i'm thinking it would be nice to have 'bzr debi' or some such to build the debian/ directory template maybe?
<james_w> bzr dh-make
<james_w> but that uses dh_make rather than stdeb to build the template
<barry> james_w: ah, that exists?
<james_w> if they are significantly different then we should improve on that
<james_w> yeah, in lucid
<barry> james_w: nice.  i didn't know about that.  will try
<james_w> pass it a tarball
<james_w> if upstream has a bzr branch then run it in a copy of that too
<barry> james_w: so i would have to build or download the tarball first?
<james_w> yes, currently
<james_w> well
<james_w> it takes http/ftp/sftp/etc. URLs too
<cjwatson> bug 231797 is a *closed* bug
<ubottu> Launchpad bug 231797 in devscripts "no sensible way to use debian/watch files with launchpad hosted tarballs" [Undecided,Invalid] https://launchpad.net/bugs/231797
<barry> james_w: e.g. if i just 'bzr branch lazr.enum' i just have a source branch.  i can build the tarball easily w/ python setup.py
<cjwatson> with a working example at the end
<barry> cjwatson: yeah.  the solution is just fairly well buried (non obvious)
<cjwatson> it sort of sucks that you need to type much of the URL twice
<barry> cjwatson: yep
<james_w> barry: do you not want to work from http://launchpad.net/lazr.enum/trunk/1.1.2/+download/lazr.enum-1.1.2.tar.gz ?
<barry> james_w: in this particular case, it's probably fine.  just wondering for general case when there's only a source branch and no download available
<james_w> in that case you have to build a tarball yourself
<pitti> ev: wrt bug 503808, any particular reason why usb-creator suppresses crashes like that instead of letting them be filed through apport?
<ubottu> Launchpad bug 503808 in usb-creator "usb-creator-gtk does not start (GtkFrontend instance has no attribute 'cancelbutton')" [Undecided,Confirmed] https://launchpad.net/bugs/503808
<pitti> smoser: looking
<smoser> thanks.
<barry> james_w: cool
<barry> james_w, cjwatson thanks.  let me try 'bzr dh_make' and i'll update the wiki
<james_w> barry: I could add support for generating one with "bzr export", but we don't have a solution yet for where that isn't enough (e.g python setup.py sdist doing more than just tarballing the contents)
<james_w> please file a bug on the issue
<barry> james_w: cool.  will do
<pitti> smoser: hm, I'm not sure how useful that is -- attachments get compressed during upload anyway
<pitti> smoser: what's your use case?
<smoser> pitti, they do ?
<smoser> if htye get compressed during upload then you're right, not needed.
<pitti> smoser: well, binary attachments do
<pitti> pure text files aren't
<pitti> (by default)
<smoser> oh.
<smoser> ok. so the log files that i want to attahc are massive (dozens of Meg) and plaintext
<smoser> what would you suggest ?
<pitti> smoser: however, you don't actually need to reimplement it, problem_report.py has that built in already
<pitti> smoser: you can do
<pitti> report['FooFile'] = ('/tmp/foo.log', True)
<pitti> which will force compression of that file
<barry> cjwatson, james_w i reopened bug 231797 on launchpad with a suggestion for improvement
<ubottu> Launchpad bug 231797 in devscripts "no sensible way to use debian/watch files with launchpad hosted tarballs" [Undecided,Invalid] https://launchpad.net/bugs/231797
<pitti> smoser: python -c 'import problem_report; help(problem_report.ProblemReport)'
<pitti> smoser: and look for "write"
<james_w> thanks barry
<smoser> pitti, i think i'm missing something. i guess i dont understand how i should use that.
<smoser> are you suggesting i use it from the eucalyptus apport hook, or utilize it rather than my gzip code in read_file... ie do you think apport needs to be changed?
<barry> james_w: what's the package name for bzr-dh-make?  i'm not finding it
<mathiaz> cjwatson: hi - has the iscsi component of the installer changed since beta1?
<pitti> smoser: the euca hook can just use that syntax (a tuple with a path, instead of a string value)
<james_w> barry: it's in bzr-builddeb
<barry> james_w: ah! thx
<pitti> smoser: (I just commented on the bug)
<smoser> pitti, thanks.
<cjwatson> mathiaz: no
<mathiaz> cjwatson: trying to install from the archive using netboot
<mathiaz> cjwatson: the installer isn't able to find any block devices
<mathiaz> cjwatson: however /dev/sda is there
<cjwatson> mathiaz: have you run 'login to iscsi targets'?
<cjwatson> oh, if it's there then you shouldn't need to
<cjwatson> mathiaz: sorry, I need to go out right now, I'll be back in a bit
<mathiaz> cjwatson: ok
<mathiaz> cjwatson: I've restarted the installer with a default debconf priority
<mathiaz> cjwatson: and I saw the screen where there is a list of driver that should be listed
<mathiaz> cjwatson: stating that no block device had been found
<kirkland> slangasek: http://people.canonical.com/~kirkland/libplymouth2.png
<kirkland> slangasek: was this expected to have been fixed?
<barry> james_w: bug 545361
<ubottu> Launchpad bug 545361 in bzr-builddeb "Pull in some functionality from stdeb" [Undecided,New] https://launchpad.net/bugs/545361
<james_w> thanks
<lamont> ogra/asac: so... about this network that doesn't seem to like me so much
<lamont> is it the address assignment, or the link up bit that is lacking?  or both?
<slangasek> kirkland: bug #540091
<ubottu> Launchpad bug 540091 in plymouth "libplymouth2<->mountall circular dep prevents upgrade from karmic" [Critical,Invalid] https://launchpad.net/bugs/540091
<kirkland> slangasek: thanks
<jdstrand> seb128: hi! I recently upgraded a system from karmic to lucid and noticed that the gdm theme was still karmic's. I had to dpkg --purge gdm and then install from scratch. I did make some gdm gconf changes prior before upgrading
<jdstrand> seb128: is this a known issue?
<bdrung_> cjwatson: thanks
<lamont> sd 0:0:0:0: [sda] Attached SCSI disk
<lamont> ogra/asac: how come d-i doesn't see the drive, when the firmware and kernel clearly do?
<mathiaz> lamont: which version of the d-i are you trying out?
<okn> hi everyone
<okn> I looking for someone who can help me
<okn> about wubi-installer
<lamont>  http://ports.ubuntu.com/ubuntu-ports/dists/karmic/main/installer-armel/current/images/imx51/netboot/babbage-TO2/babbage-TO2-sd.img <-- mathiaz
<lifeless> slangasek: ipng
<slangasek> lifeless: opng
<lamont> so.. how come my mouse is about an inch above where the arrow is on the screen (when I highlight text in xchat for cut-n-waste)?
<mathiaz> lamont: ah - karmic.
<lamont> oh gar
<lifeless> slangasek: there was a recent bug about a package in the mirror system with noone-can-read-permissions; I'm curious why we didn't just delete the package
<mathiaz> lamont: I don't know then.
<slangasek> lifeless: physically delete it from the mirrors?
<lamont> mathiaz: any reason not to use lucid?
<lifeless> slangasek: yeah
<okn> I am trying to develop a wubi like software for pardus
<mathiaz> lamont: oh - I tried to use the latest netboot install from lucid
<lifeless> https://bugs.edge.launchpad.net/lmirror/+bug/542409 is why I'm asking
<ubottu> Ubuntu bug 542409 in lmirror "journal should record timestamps and file modes" [Wishlist,Triaged]
<okn> which is another linux distro
<mathiaz> lamont: and it seems that it's not able to find block devices
<lamont> ah, ok
<mathiaz> lamont: using beta-1 netboot install works
<lamont> URL?
<slangasek> lifeless: primarily because, while we were in the process of sorting it, there were still references to the file both in the Packages files and in the db; a 404 isn't all that much more friendly to the package manager than a 403
<lamont> ah
<lifeless> slangasek: ok; I guess I mean 'is it a big deal if you did not have the option of a 403'
<slangasek> lifeless: there are designs for a way to mark a bad package out-of-band so that it's mirroring-safe, but those are Not For Lucid
<slangasek> lifeless: arguably, we already don't have the option of a 403 where most mirrors are concerned, because if it's chmod 000 mirrors have a hard time retrieving it :P
<lifeless> slangasek: I've written a replacement for rsync, for mirroring things like the ubuntu archive; it doesn't currently support file modes.
<lifeless> slangasek: If file modes are important for the Ubuntu archive, I'll make supporting them a critical bug, to get it to beta testing level; if they aren't, I won't - this is what I'm trying to assess.
<slangasek> lifeless: is this going to land in our tier-one mirrors any time soon?
<lifeless> slangasek: jpds is very excited by it; for all its a personal project of time its moving pretty quickly. So 'perhaps'.
<lifeless> s/time/mine/
<jpds> Hi.
<lifeless> jpds: hi :)
<slangasek> lifeless: right; then we should feel out with the rest of the team (ubuntu-archive + soyuz) whether people are comfortable with 'rm' instead of 'chmod 000' here, but I can't see any technical reason it wouldn't work
<lifeless> slangasek: thanks
<jpds> slangasek: It will do with, and once I've tested the crap out of it. ;)
<lifeless> slangasek: they can always say 'must have modes', at this point your assessment is sufficient.
<jpds> with time*
<slangasek> jpds: EPARSE - "it will do with"?
<jpds> slangasek: ^--.
<slangasek> ah
<slangasek> jpds: I'm not asking whether the switch to lmirror will be accepted, I'm asking whether people will find removing files that are still referenced in the db to be ugly / messy
<slangasek> if we change our minds, it's a pain to get the files back on disk
<jpds> Ah, right.
<crimsun> jdstrand: WRT gdm, it doesn't appear to be known (I checked the bugzilla and launchpad entries), but I can confirm your symptom
<jdstrand> crimsun: ok. I'll file a bug
<lifeless> slangasek: so the key thing is that we'd need a mode like 400, or else the mirror code itself won't be able to propogate the bad file.
<lifeless> slangasek: what list[s] should I query this on?
<slangasek> lifeless: ubuntu-archive is the list, but I'm not subscribed to it and am not sure who else on the team is.  Grab the list of team members from https://launchpad.net/~ubuntu-archive/+members ?
<seb128> jdstrand, "known" in the sense there is a bug a bug about it
<seb128> jdstrand, it should not happen if you never changed your config though
<seb128> jdstrand, did you ever run gconftool manually or sudo gnome-appearance-properties before?
<seb128> sudo -u gdm
<seb128> rather
<seb128> I didn't confirm on the upgrade test I did there
<jdstrand> seb128: I just found bug #532659
<ubottu> Launchpad bug 532659 in gdm "new theme not applied" [Low,New] https://launchpad.net/bugs/532659
<seb128> .gconf is not shipped by the package
<jdstrand> seb128: I made gconf changes to disable sound, but never touched the theme
<seb128> I have to check
<seb128> it might be that playing with the accessiblity option on the login screen write a key or something
<seb128> since it changes the theme
<jdstrand> seb128: this was on two systems-- my desktop and my netbook
<seb128> otherwise I don't know why you would have had a custom config there
<jdstrand> I didn't even know there was a new gdm theme until I did a fresh install on my laptop...
<seb128> ok, it's clearly an issue for quite some user
<seb128> users
<seb128> but I don't know why yet
<jdstrand> then I was like "oh, hey, why doesn't my desktop have that?"
<seb128> I will try to play on a karmic box to see what action can write that config
<seb128> you never ran gnome-appearance-properties for the gdm user right?
<seb128> ie sudo -u gdm gnome-appearance-properties
<seb128> do you remember if you clicked on the login screen accessibility icon at some point?
<seb128> it changes the theme to the accessibility one
<jdstrand> seb128: I am totally unaware of that command, so I would have to give a tentative 'no'
<seb128> it's possible that when turning that on and off let the theme set an user one
<jdstrand> seb128: I don't think I ever played with accessibility, but I'm not sure. it's possible on the desktop, less so on the netbook
<seb128> ok thanks
<jdstrand> seb128: I did use the methods in bug #437429 to disable sound though
<seb128> jdstrand, I will ping you back later if I've other questions
<ubottu> Launchpad bug 437429 in ubuntu-sounds "No GUI to configure/disable login sound" [Undecided,Invalid] https://launchpad.net/bugs/437429
<seb128> I will try if one of those commands does trigger some other settings writting in the user config
<jdstrand> sudo -u gdm gconftool-2 --set ...
<seb128> jdstrand, k, that might be useful, I will check on that later, thanks!
<jdstrand> seb128: on the netbook I also adjusted /apps/gdm/simple-greeter/disable_user_list, but not on the desktop
<jdstrand> bug #445123
<ubottu> Launchpad bug 445123 in gdm "No GUI option to disable face browser" [Wishlist,Triaged] https://launchpad.net/bugs/445123
<seb128> jdstrand, so basically you did use sudo -u gdm gconftool to set some gconf keys for the login screen but not the themes ones
<jdstrand> seb128: sure! thanks for looking into it
<seb128> jdstrand, I will check if that could have some side effects
<seb128> jdstrand, you're welcome
<seb128> I've to go now
<seb128> bbl
<cody-somerville> oh god. I'm getting all the edubuntu bugsquad bug email now.
<cody-somerville> highvoltage, Why is Ubuntu Core Development Team a member of edubuntu-developers?
<cody-somerville> highvoltage, can you set a contact address for either the edubuntu developers team or edubuntu bugsquad team so that I don't get edubuntu bug mail?
<slangasek> cody-somerville: so that core-dev has commit access to the seeds when needed
<pitti> cody-somerville: eww, yes; /me blacklists
<pitti> but for a general solution, edubuntu-dev would need a contact address indeed
<tkamppeter> pitti, I did the "bzr push"now.
<YokoZar> Whatever happened to the caff package in Lucid?
<pitti> tkamppeter: thanks
<YokoZar> for key signing?
<YokoZar> (hoping I'm not doing something dumb like misremembering the name)
<cnd> anyone know what gnome-power-manager does for suspend outside of actually calling pm-suspend?
<cnd> I have an issue where calling pm-suspend manually works fine in lucid, but closing the laptop lid leaves the backlight off on resume
<lifeless> cnd: what happens if you configure gpm to do nothing on lid closes, call pm-suspend and close the lid quickly ?
<cnd> lifeless: not sure, got an idea?
<highvoltage> cody-somerville: eek, ok, will do
<cnd> I'm booted into karmic, so I can't test easily right now
<highvoltage> cody-somerville: I set a contact address, you shouldn't get edubuntu-bug spam anymore
<cody-somerville> highvoltage, merci
<cody-somerville> highvoltage, also, I think the DMB should probably be the owner of edubuntu-dev instead of a member as its theoretically possible that non core-devs could be a member of DMB and AFAIK being a member of the DMB shouldn't grant you any extra upload permissions.
<dmb> ok
<geser> cody-somerville: it's not only theoretical, I'm a DMB member but no core-dev
<cody-somerville> geser, ugh
<cody-somerville> actually you are
<cody-somerville> DMB is a member of core-dev :P
<asac> lamont: on bbg the driver doesnt give carrier detect yet - if thats what you wondered about
<highvoltage> heh. so then it's not theoritically possible!
<asac> so you manually have to connect if you use NM
<asac> lamont: i dont know about netboot
<asac> maybe thats broken
<asac> lamont: sorry if thats the case. let me check with folks what works best for beta1
<AnAnt> Hello, what's the license of the ubuntu-logo plymouth artwork ? I don't see anything explicit about it in /usr/share/doc/plymouth/copyright
<cody-somerville> cjwatson, ^^ Is it intended by the TB for membership on the DMB to implicitly grant Ubuntu core developer status?
<cody-somerville> geser, And I think you should apply for core-dev :P
<chrisccoulson> hey seb128
<chrisccoulson> i've been looking at this terminal profile issue this evening, and i think i've got a slightly better solution for it now
<seb128> chrisccoulson, hey
<seb128> which one?
<chrisccoulson> the issue we discussed in the team meeting earlier about overwriting config on upgrades
<chrisccoulson> i've got a solution which involves adding no extra profile, and implementing it all in the gtk theme instead
<chrisccoulson> well, i will have that solution in about 30 minutes ;)
<seb128> sorry the "which one" was not clear, it was a "which solution" ;-)
<seb128> good!
<Riddell> bryceh: ping
<lamont> asac: yeah - the current issue is that the fw sees sda, but dd of the device finishes with the first read, 0 bytes, EOF, kthx
<cjwatson> YokoZar: I think you're looking for signing-party
<YokoZar> cjwatson: indeed I am.  And command-not-found could have told me that if I had thought of it
<cjwatson> cody-somerville: can't speak for the whole TB, but (a) I think the current situation is a bug (b) I would expect DMB members to be responsible enough not to abuse their access
<cody-somerville> cjwatson, I agree. However, once we get rid of components it'll be very easy I imagine to accidentally upload a package you shouldn't have access to but do.
<cjwatson> cody-somerville: sure, we should certainly fix it
#ubuntu-devel 2010-03-24
<bluefoxicy> why is empathy retarded and pidgin broken?
<bluefoxicy> empathy:  because if you get a message from someone not on your buddy list, there should definitely be no way to talk to them.
<RAOF> There's a bug # for that, I presume?
<RAOF> That sounds like pretty obnoxious behaviour, and I don't think I've hit it.
<bluefoxicy> RAOF:  if someone messages you do you get a new tab?
<bluefoxicy> or does their username flash in your buddy list?
<RAOF> The latter, last time I checked.
<bluefoxicy> RAOF:  and which username flashes when someone not on your buddy list messages you?
<RAOF> No idea.
<RAOF> I presume that for you the answer is ânoneâ.  And is there a bug report for this?
<bluefoxicy> RAOF:  there shall be soon.
<lifeless> I need a 'which package to file on' consult
<lifeless> ugprading grub-pc in a UEC instance, the AMI is running a slightly older lucid
<lifeless> I get this - http://paste.ubuntu.com/400297/
<lifeless> and its looping, its gone around 30 or 40 times now
<amstan> Lauraxia: hi
<Lauraxia> hi
<amstan> Lauraxia: what's new?
<psusi> woohoo!  first try patching e2defrag to handle the new larger size inodes and it works!
<lifeless> StevenK: ping
<xnox> how long does it take between debian upload & update on launchpad.net/debian/+source/package?
 * xnox can't wait to request sync
<slangasek> xnox: from 1 to 7 hours, since Debian's publisher only runs 4x daily
<xnox> slangasek, thankx =(((((((((
<StevenK> lifeless: Pong
<xnox> 2 hours to go then.
<lifeless> StevenK: hey
<lifeless> StevenK: so, see scroll back for me chatting with slangasek; are you subscribed to ubuntu-archive, or the appropriate list I should email for an opinion ?
<StevenK> lifeless: What time roughly, since I didn't see it at a glance, and yes, I am
<lifeless> 07:14
<StevenK> lifeless: Right, I think file permissions are important, at least in the short term, since that is how we currently stop people grabbing broken stuff when it's critical
<lifeless> StevenK: how hard would it be to simply start using rm ?
<soren> I /think/ there's a rationale for the current approach on the wiki somewhere.
<lifeless> StevenK: I don't see it being more than 's/chmod 000/rm/' in your blacklist script
<soren> lifeless: Possibly on one of the DWCIU sub-pages.
<lifeless> https://wiki.ubuntu.com/FoundationsTeam/Specs/LucidUpdateManagerStopTheLine ?
<soren> lifeless: No.
<lifeless> right, have read it now ;)
<soren> I forget what the rationale is, though. Something about mirrors, I think.
<lifeless> mirrors propogate deletes though
<lifeless> and cached things in e.g. squid will equally become inaccessible when a file goes, as when the access bits change.
 * soren didn't write the wiki page, nor come up with the rationale :)
<lifeless> sure
<lifeless> I appreciate the pointer, but I can't find the rationale
<soren> You found the relevant DWCIU page?
<lifeless> StevenK: so /where/ do I discuss this? implementing support for permissions is easy; but propogating a mode 000 file is /impossible/
<lifeless> I'm frankly amazed that rsync doesn't blow up in everyones face
<lifeless> soren: no
<soren> lifeless: Hm. Well, I obviously can't help you find it. :)
<soren> lifeless: that is, if it's there at all. This may all be a figment of my imagination.
<StevenK> Doesn't rsync just go "Argh, can't read, skipping" ?
<lifeless> soren: oh, internal wiki ?
<lifeless> StevenK: which implies that mirrors that didn't have the file already *won't get it*, so it acts like its been deleted.
<soren> lifeless: Indeed.
<lifeless> what does DWCIU expand to then ?
<lifeless> StevenK: and if thats the case, then why not just delete from day one ? :)
<soren> lifeless: DealingWithCrisisInUbuntu
<StevenK> lifeless: I'm not sure, it's always been the case to chmod 0000 the file, not delete
<lifeless> q/win goto StevenK
<lifeless> so
<lifeless> I've found the doc
<lifeless> and it explicitly says that we can't mirror because rsync will blow up
<lifeless> StevenK: As I see it, deleting, or replacing with a zero-length file, should be friendlier to the mirror process, propogate further with less issues, and be functionally equivalent
<StevenK> lifeless: Then I'd suggest asking elmo why it's chmod 0000 rather than rm
<lifeless> ok
<lifeless> will do
<lifeless> elmo: ^
<lamont> meh. that whole notification thing in the upper right of my screen?  interferes with what I'm using that part of the real estate for.. how movable/killable is that, I wonder?
<stgraber> lamont: right click + unlock + right click + move should do the trick. Removing it should also fallback to the old behavior.
<stgraber> lamont: or you mean notify-osd ? (too much notifications in that corner ;))
<lamont> it covers up several channels in xchat.
<lamont> more of an irritation - it started with karimc, after all
<lifeless> lamont: remove notify-osd
<stgraber> ok, so that's notify-osd. Removing notify-osd should fallback to notification-daemon (the old notification system) though it'll likely uninstall ubuntu-desktop so I'd be careful with that
<stgraber> or actually, IIRC notification-daemon takes priority on notify-osd (I had that "bug" happening a few times at customers), so installing notification-daemon + logout/login should revert to the old notification system (<= jaunty)
<lamont> ta
<wgrant> StevenK, lifeless: Why do you play with the file at all?
<wgrant> Don't you really want to delete the broken package and revive the old one?
<lifeless> wgrant: I don't play with it :P. and yes.
<wgrant> I've heard of this thing called Soyuz. It's pretty cool, and just about lets you do that.
<wgrant> (and I wish people would stop trying to work around it)
<lifeless> wgrant: the internal process doc uses soyuz commands
<lifeless> wgrant: and says 'a future soyuz command to reinstate old version of same package' or something approx == to that
<lifeless> wgrant: so I think its mischaracterisation to say working around it; soyuz is not the end of the deployment process
<wgrant> Playing around in archives generated by Soyuz because nobody has spent 10 minutes to write the Soyuz tool -- that *is* working around Soyuz.
<wgrant> (it's probably <10 minutes, actually. it just needs a fix in copy-package.py to look at deleted versions as well)
<xnox> I'm cross-compiling gcc as a debian package. Any ideas how can I modify debian/rules to play around with binary target without cleaning & rebuilding it?
<xnox> Cause build target takes forever on my machine
<persia> xnox: Why cross-compile?
 * xnox has nothing to do.....
<xnox> I'm trying to build mingw-w64 toolchain bootstrapped from scratch without mingw32 dependencies without using pre-build binaries
<persia> xnox: Have you considered unmetdeps, NBS, or RCBugs?
<StevenK> lamont: No fair uploading livecd-rootfs without commiting your changes to the bzr branch
<xnox> persia, good point
<xnox> the real goal is to make mingw-w64 awesome on ubuntu/debian
 * hyperair finds it interesting that aptitude in a lucid chroot takes up 50% CPU on a dual core machine just to install things.
<hyperair> it's almost like aptitude is busy-waiting for something..
<hyperair> ah damnit, it is >_>
<hyperair> wait4(27698, 0x7fffa041e688, WNOHANG, NULL) = 0
<hyperair> pselect6(36, [0 35], NULL, NULL, {1, 0}, {[], 8}) = 1 (in [0], left {0, 999996927})
<hyperair> repeated endlessly
<hyperair> this is ridiculous
<pitti> Good morning
<cooloney> hi, does anybody know how does NetworkManager know this "<info>  (eth0): driver 'fec' does not support carrier detection"?
<slangasek> cjwatson: I think in all the rush last week, we didn't pick a chair for this week's foundations meeting? :)
<spm> slangasek: a chartreuse comfy leather chair perhaps?
<slangasek> I didn't know leather came in chartreuse
<spm> you haven't seen the chartreuse cows? tho tbh, possibly not; they blend in well with some grasses. evolution at work - camouflage.
<slangasek> must be an .au thing :)
<spm> possibly - I heard some noise that it was a defence against Yowies and/or drop-bears. But well... you do wonder at some of the tales... Drop Bears work off vibrations; the colours wouldn't stop them. and Yowies are smell. so...
<micahg> is there a trigger to get something to appear in Software Center after changing the .desktop file?
<persia> You have to wait for an update to app-install-data
<micahg> persia: ah, does that rebuild it?
<micahg> or is it stored there?
<persia> dpkg -L app-install-data will tell you more than I could explain :)
<micahg> persia: ok, so if I update the desktop, the next time the package is spun, it'll be picked up then
<persia> That's been my experience.
<micahg> persia: k
<persia> (although I think we ought find a better way than storing duplicate copies of 2500 .desktop files to handle this :) )
<micahg> persia: i modified the .desktop in that package and it didn't help
<persia> micahg: What are you attempting to accomplish?
<micahg> persia: I wanted to verify that Thunderbird will be added under Mail
<persia> What is your Categories value?
<micahg> persia: now: Application;Network;Email;
<persia> Ah, that's why.
<micahg> I added Email as I saw that in the other programs that appeared
<persia> You want "Office;Network;Email"  See http://standards.freedesktop.org/menu-spec/latest/apa.html
<micahg> persia: nope, that didn't do it
<micahg> persia: is there a guide to the software center categories?
<ion> See âSee http://standards.freedesktop.org/menu-spec/latest/apa.htmlâ
<persia> micahg: Not to my knowledge, but I've a tendency to go source diving before looking very hard.
<ion> Are you sure the software center is reading your updated desktop file? It may have a cache of some kind.
<dholbach> good morning
<micahg> ion: that's what I'm wondering
<ion> Hi dholbach
<dholbach> hi ion
<ion> update-software-center, anyone?
<micahg> found the cache :)
<micahg> actually not :(
<cjwatson> slangasek: hm, possibly not.  are you volunteering? :)
<pecisk> hi people, It is known bug in Gwibber that it doesn't honor GNOME proxy settings. Well, I have investigated and find out, that it uses pycurl and it is very easy to patch for this. Question is - if we want to get this feature into Lucid, it is a) new feature or b) fixed bug?
<mvo> that is a bugfix
<pitti> pecisk: sounds like a bug fix to me
<pecisk> pitti: cool, then I will work on patch and will let you know where to get it and test it
<pitti> pecisk: please let kenvandine know; I'm not that attached to gwibber
<pitti> pecisk: thanks for fixing this!
<pecisk> ok :)
<pecisk> np
<nipas> Hello!
<nipas> I have 10.04 beta installed, with all updates. Since my first update after a clean beta 1 install , the boot logo does not show correctly
<nipas> Is this a common bug?
<Keybuk> depends what you think correctly is
<Keybuk> and what you actually see
<pecisk> nipas: nvidia graphics card?
<nipas> yes
<pecisk> nipas: it is known bug with plymouth, people working on it
<nipas> aha, ok
<pecisk> one sec, will provide bug numbers
<Keybuk> err
<Keybuk> pecisk: what's a known bug?
<pecisk> Keybuk: plymouth and nvidia
<Keybuk> no it isn't
<pecisk> no? :)
<Keybuk> no.
<nipas> I just wanted to be sure that it is reported :)
<Keybuk> nipas: you haven't reported anything yet
<Keybuk> you just said the logo does not show "correctly" ?
<nipas> nop
<Keybuk> for all I know, that means you think the logo should have more dancing monkeys
<nipas> not thit bug
<nipas> this*
<nipas> yes
<nipas> i can see graphics
<nipas> , but
<nipas> there is no backround
<nipas> (that urple backround)
<Keybuk> perhaps you could take a photo of what you see?
<pecisk> nipas: you can see mouse moving and nothing else?
<nipas> I can do that with a photo camera
<pecisk> do it
<nipas> ok
<nipas> I will be back in 2-3 mins
<nipas> will send a link
<nipas> it is being uploaded on imageshack
<nipas> http://img535.imageshack.us/img535/7742/dsc07208.jpg sorry about the quality
<Keybuk> that looks normal?
<nipas> no
<nipas> of cource
<nipas> course*
<nipas> sth goes wrong
<Keybuk> looks fine to me
<nipas> fine??
<pecisk> nipas: it is disk check, not sure what a problem is :)
<nipas> it wasn't like that when booting from the live cd
<nipas> and before the update
<Keybuk> that's because you hadn't installed evil, proprietary, binary, non-free, freedom hating drivers when you booted the Live CD
<Keybuk> you only did that after you installed
<Keybuk> because you like 3D more than you like freedom
<Keybuk> :p
<pecisk> hhehe
<nipas> aha heh
<nipas> and now what i'm supposed to do?
<pecisk> nipas: well, I don't quite get where is the problem. this is disk check, let it pass and it shouldn't bother you anymore for a while
<Keybuk> feel free to write to your nvidia support representative and ask them to add a true-colour frame-buffer API to their crap stupid idiotic driver :p
<pecisk> :D
<nipas> you 're right....
<nipas> it might be isc check.....
<nipas> It also happens on shutdown
<pecisk> just let it pass and try again clean booting process
<nipas> ok , will do it now
<nipas> brb
<nipas> I removed the nvidia driver and now,
<pecisk> and?
<nipas> at the first reboot there was no splash screen
<nipas> at the following 3 reboots
<nipas> i could not even
<nipas> enter login screen
<Keybuk> sounds like the driver wasn't removed
<nipas> I could see some random colora
<nipas> now i selected the previous kernel and managed to login
<nipas> ...
<nipas> no there is no driver installed
<nipas> what a mess..
<nipas> what do you suggest?
<Keybuk> I don't suggest anything
<nipas> :p
<Keybuk> people on #ubuntu may be able to help more
<pecisk> nipas: #ubuntu+1
<nipas> just entered :)
<pecisk> go, ask your question again
<nipas> I try to do sth first...
<pecisk> in that channel
<nipas> have a nC day
<pecisk> see ya
<nipas> cya
 * pecisk sights
<Keybuk> welcome to my life ;-)
<bdrung> persia: can ubuntu-sponsors be a member of ubuntu-{main,universe}-sponsors?
<lamont> StevenK: it's more one of forgetting to push it back.  done
<StevenK> lamont: Thanks!
<ogra> lamont, so did you succeed ?
<ogra> lamalex, the network issues are very likely caused by the NIC driver only being half implemented, see bug 457878
<ubottu> Launchpad bug 457878 in linux-fsl-imx51 "imx51 on board ethernet plug/unplug events not detected" [Medium,In progress] https://launchpad.net/bugs/457878
<lamont> ogra: successfully got network, totally failed to have a disk, other than seeing it in dmesg.
<lamont> reads return EOF on inital read of the device
<lamont> iz plugged directly into the board
<ogra> directly like the SATA interface ?
<lamont> yes
<ogra> well, thats USB as well :)
<ogra> just pretends to be SATA
<ogra> but doesnt give you any advantage over a plain USB disk
<lamont> so we've been told
<ogra> i havnet seen any issues with it though, butu i use external power, it might be a prob if you power the disk from the board
<lamont> ogra: ok.  he should be at the DC in the next hour or so, at which point we'll be able to swap things around
<lamont> we'll try external power
 * ogra has a real 5 1/4" disk attached, power coming from an ATX supply ... i only got an SSD with proper interface a week ago
<lamont> any reason not to use the beta1 image?
<ogra> no reason at all :)
<ogra> the kernel might even be better
<lamont> cool
<ogra> the karmic and jauntyx kernels both were forward/backports of the BSP patches, lucid is actually the plain BSP kernel and the ubuntu patches being ported instead
<ogra> so you can expext better results with it
<ogra> and expecially there is a fix for the PHY NIC issue in the pipe atm
<ogra> which i suspect to solve a lot of ethernet issues
<ogra> though note that i dont know how well the netinst image is tested in lucid
<pecisk> kenvandine: here? I have question about bug fix for gwibber
<pecisk> /whois pecisk
<pecisk> yah, sorry
<persia> bdrung: Ideally not, because that would create a loop (as both those teams are members of ubuntu-sponsors).
<stgraber> cjwatson: ping
<stgraber> cjwatson: seems like Edubuntu DVD built before the i386 LTSP chroot was built (or something similar) causing a build failure for amd64.
<bdrung> persia: but then i can't unsubscribe ubuntu-{main,universe}-sponsors
<stgraber> cjwatson: oh, nevermind, just saw -release ;)
<persia> bdrung: I know.  It's a bug.  We're hoping it goes away soon, because all the docs and tools have been updated to point at ubuntu-sponsors.  Just ask for help, and someone else will unsubscribe.
<dmart> cjwatson: Hi there, I've been playing with the klibc build configuration for armel.  Are there tests I can run?  make test builds a lot of test binaries, but I can't see how the binaries should be invoked or what the expected results should be.  Some segfault if not supplied with the proper args.
<asac_> dmart: do you see the same segfaults with default options?
<sladen> YokoZar: is it not in the 'signing-party' package?
<kenvandine> pecisk, pong
<cjwatson> dmart: I think in practice testing will involve installing it, building an initramfs, and booting ...
<cjwatson> dmart: you could try fstype on a filesystem as well (we should replace this with blkid, but)
<pecisk> kenvandine: I have a patch for Gwibber to honor GNOME proxy settings, can I attach it to this bug and you will review it? https://bugs.edge.launchpad.net/gwibber/+bug/259830
<ubottu> Ubuntu bug 259830 in gwibber "Honor gnome proxy setting" [Medium,Confirmed]
<kenvandine> pecisk, sure
<kenvandine> thx
<kenvandine> pecisk, of if you have a bzr branch, propose it for merging
<pecisk> kenvandine: I would do that, but I'm behind firewall and bzr stuff doesn't work correctly, so I better of with patch. It is one file anyway.
<kenvandine> pecisk, a patch is fine
<kenvandine> pecisk, thx!
<kenvandine> pecisk, ping me when you attach that patch, i am anxious to check it out
<pecisk> kenvandine: sure thing :)
<kenvandine> thx
<pecisk> I'm testing it to be sure that it works nicely
<StevenK> lamont: Still can't see your changes at lp:~ubuntu-core-dev/livecd-rootfs/trunk
<lamont> prolly because I pushed them the wrong place
<lamont> bzr push
<lamont> Using saved push location: bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/
<lamont> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/.bzr/)
<lamont> is not compatible with
<lamont> CHKInventoryRepository('file:///srv/mix.mmjgroup.com/src/Others/livecd-rootfs/livecd-rootfs/.bzr/repository/')
<lamont> different rich-root support
<lamont> thoughts?
<lamont> bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/livecd-rootfs/lucid/ is where the tree _is_ pushed
<cjwatson> lamont: I've hit the "Upgrade this branch" button on https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk.  Wait for the "An upgrade of this branch is in progress" message to go away from the top of that web page, and then try again
<lamont> ah. doh
<lamont> thanks
<dmart> asac_: For the particular test program (fnmatch) the crash is just caused by deferencing argv[1] etc. -- providing options solves it.  The tests all build, but there is no definition of how to run them etc. that I can see...
<dmart> cjwatson: I'll try installing the debs and rebuilding the initramfs
<lamont> afk for those few minutes
<ari-tczew> please review SRU bug 421684 before intrepid EOL which is going
<ubottu> Launchpad bug 421684 in obexd "bluetooth send malformed files " [Undecided,Confirmed] https://launchpad.net/bugs/421684
<cjwatson> lamont: it's upgraded now
<didrocks> seb128: cjwatson: as Compiz doesn't show the "as username" string, I will be in favor of removing the functionality from metacity. (upstream is also wondering about that: http://blogs.gnome.org/metacity/2010/02/08/as-superuser-considered-harmful/). What do you think?
<Ng> if one were booting a lucid beta ISO in a VM (Parallels on OSX specifically) and the initramfs said it was unable to find a medium containing a live file system, would one confirm bug #543875 or file a new one? (that bug is about real hardware)
<ubottu> Launchpad bug 543875 in ubuntu "unable to find a medium containing a live file system" [Undecided,New] https://launchpad.net/bugs/543875
<lamont> cjwatson: why yes, yes it is.  ta.  and diverged.. le sigh
<seb128> didrocks, +1
<cjwatson> didrocks: fine by me, I don't think Thomas will mind
<didrocks> seb128: cjwatson: ok, doing it so and reporting it in upstream bug report too
<cjwatson> lamont: if you branched from the automatic import, then it probably has no revisions in common at all
<cjwatson> didrocks: thanks!
<cjwatson> Ng: always better to file a new one
<didrocks> y/w ;)
<cjwatson> Ng: that's just a generic symptom of "errr - hardware detection failed, somewhere"
<lamont> cjwatson: very true, that
<lamont> I'm thinking I'll just do one commit of love, though
<Ng> cjwatson: is there any particular arrangement of options which will yield a more useful amount of information to debug? I'm about a hundred miles away from this system and I'm unlikely to have much opportunity to capture stuff from it later
<dmart> cjwatson: sorry - I've been away for a while... What did you mean by trying fstype on a filesystem, how does this relate to klibc?
<cjwatson> Ng: https://wiki.ubuntu.com/DebuggingCasper
<cjwatson> $ dpkg -L klibc-utils | grep fstype
<cjwatson> /usr/lib/klibc/bin/fstype
<cjwatson> dmart: ^- is how it relates to klibc
<cjwatson> it's an executable klibc ships that is used in some situations during boot, although not in all situations IIRC
<Ng> cjwatson: fantastic, thanks
<dmart> cjwatson: ah, OK
<cjwatson> $ sudo /usr/lib/klibc/bin/fstype /dev/sda5
<cjwatson> FSTYPE=ext3
<cjwatson> FSSIZE=50001444864
<dmart> cjwatson: That seems to work for me
<dmart> cjwatson: Do you know anything about the homebrew dynamic linking system in klibc?  This could have arch-specific risks, but I'm not sure what to review
<cjwatson> dmart: nothing, I'm afraid
<cjwatson> dmart: if it works well enough for booting, IMO that's good enough
<primes2h> pitti: Hello. giving a look at this https://bugs.edge.launchpad.net/ubuntu/+source/udev/+bug/536914 could you give me a quick suggestion about it so I can make a patch for itplease ? It's really trivial but I need a small hint.
<ubottu> Ubuntu bug 536914 in udev "[Lucid Alpha3][khk-004 testcase failed] Click on Internet hotkey opens Home folder on Acer Laptops" [Low,Triaged]
<dmart> cjwatson: OK.  I'll have a quick dig, but I've no special reason to believe it doesn't work.  I'll build an initramfs and try booting it.
<lamont> StevenK: pushed, and 1.109 uploaded
<StevenK> lamont: I was about to upload one as well
<pitti> primes2h: sure, I followed up on the bug report
<StevenK> lamont: The changelog and control disagree. :-P
<lamont> gah
<lamont> yeah - fix that pls?
<lamont> or shall I?
<StevenK> lamont: Sure, I can fix
<primes2h> pitti: Thanks a lot.
<mvo> Riddell: hi, do you think you (or someone from kubuntu) could check bug #546024 ?
<ubottu> Launchpad bug 546024 in phonon "file overwrite error" [High,Confirmed] https://launchpad.net/bugs/546024
<Riddell> mvo: yes can do
<barry> mvo: or anybody else.  any thoughts on updating update-manager's trunk branch to 2a format?
<mvo> barry: just go for it
<barry> mvo: awesome, thanks
<barry> mvo: ah, i can't.  'm not a member of ~ubuntu-core-dev
<pitti> barry: want me to run it?
<barry> pitti: that would be great
<pitti> is that still lp:/~ubuntu-core-dev/update-manager/karmic ? (there's no /lucid)
<barry> pitti: actually i was thinking trunk branch, e.g. 'bzr upgrade lp:update-manager'
<pitti> barry: running
<pitti> ah, /main
<pitti> mvo: you should fix Vcs-Bzr: :)
<barry> pitti: but i'm always so confused about the relationships between upstream trunks in launchpad and ubuntu release branches.  i wish there was a better relationship between the two.  but i digress (gotta talk w/ james_w about that ;)
<pitti> barry: there is in fact: lp:ubuntu/update-manager ;)
<barry> pitti: yeah ;)
<barry> pitti: actually, i guess you should upgrade that one too
<pitti> barry: that's 2a already
<pitti> package branches are quite recent
<pitti> and mostly come from the auto-importer
<barry> cool
<pitti> committer: Bazaar Package Importer <james.westby@ubuntu.com>
<pitti> yep
<pitti> I guess mvo isn't actually using that
<pitti> barry: upgrade in progress (had to remove the old backup.bzr on the server first)
<barry> pitti: cool.  i'm sure it'll take a little while.  can you ping me when it's done?
<pitti> sure
<barry> thanks!
<pitti> you're welcome
<mvo> I don't use lp:ubuntu/update-manager
<mvo> pitti: Vcs-Bzr points to lp:~ubuntu-core-dev/update-manager/main
<primes2h> pitti: ehm... What does it mean #define KEY_SCREENLOCK          KEY_COFFEE in keymaps file? Should it be numeric?
<primes2h> KEY_COFFEE ? :-)
<robbiew> mvo: ping
<pitti> mvo: ah, sorry, I have additional karmic deb-src in apt, and just saw the last output
<pitti> primes2h: KEY_COFFEE is defined numerically, and KEY_SCREENLOCK is an alias
<mvo> robbiew: pong
<mvo> pitti: no worries :)
<mvo> james_w: you can make lp:ubuntu/update-manager and lp:~ubuntu-core-dev/update-manager/main have a common history so that they can be merged? can I do that myself too? is there a process to follow (file a ticket, bug?)
<primes2h> pitti: Oh, sorry. I didn't catch it just a line above.
<james_w> mvo: I think there's already a bug open for it
<mvo> james_w: is there anything I can do/help with?
<james_w> mvo: afraid not
<mvo> ok, no worries, its not urgent
<mvo> I know you have *tons* to do
<barry> james_w: istm that this will be a common theme for packages now.  do you have A Plan for how to address that in general?
<james_w> barry: a long term plan for the general case, but this case is easier, with just a couple of kinks to work out
<barry> james_w: cool.  i've been thinking about the general case more and it's hurting my brain ;)
 * mvo brains is already hurting even without thinking about this particular problem
<ogra> seb128, hey, i'm trying to write a CD from rhythmbox, i installed the cdwriter plugin but it seems to not show up anywhere
<cjwatson> barry: so, I'm doing the "argh, action for today's meeting I haven't followed up on" thing - I basically want https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.milestone=21447 with an extra "assignee" column (and probably removing "heat"), so I'm actually just having a go at doing that myself
<cjwatson> barry: unless there's a really easy secret way to do this with Launchpad :-)
<seb128> ogra: dunno, is it on in gconf-editor?
<barry> cjwatson: not that i know of
 * ogra didnt check gconf-editor ... i dont see it in the plugins list in RB
<barry> cjwatson: sounds good though
<ogra> seb128, active and hidden are checked
 * ogra tunrs off hidden
<seb128> ogra; that's ok
<seb128> the hidden is to show it in the ui or not
<ogra> uh, and RB doesnt like that i unchecked it
<seb128> dunno open a bug if there is none yet
<lamont> which gconf-edit key do I want to tweak to get multi-pixel wide window borders?
<cjwatson> barry: ridiculously raw first cut: http://people.canonical.com/~cjwatson/ubuntu-10.04-beta-2.html
<cjwatson> not sortable for some reason
<cjwatson> oh, the original page isn't sortable either
<cjwatson> well then, that should do, now to produce the same thing for lucid as a whole
<barry> cjwatson: +1
<barry> cjwatson: upload the script somewhere?
<cjwatson> barry: http://people.canonical.com/~cjwatson/tmp/task-assignments.py (haven't run this version yet so may be broken, takes a while)
<cjwatson> *cough* at the massive cargo-culting from LP
<barry> cjwatson: ;)
<cjwatson> I should probably run it in the DC rather than shipping a bazillion JSON requests back and forward over ADSL
<pitti> barry: conversion just finished
<barry> pitti: thanks
<cjwatson> barry: moved that to http://people.canonical.com/~cjwatson/task-assignments/ubuntu-10.04-beta-2.html, and the script is in that directory too
<cjwatson> lucid.html not so happy though!
<bdrung> can a ubuntu-release member have a look at bug #544075?
<ubottu> Launchpad bug 544075 in eclipse "[FFe] Please sync eclipse 3.5.2-2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/544075
<sebner> bdrung: eclipse \o/
<bdrung> sebner: FYI: http://overbenny.wordpress.com/2010/03/19/eclipse-3-5-2-1-in-debian-unstable/
<iulian> bdrung: Looking.
<sebner> bdrung: yeah, I wanted to ask you if you will sync it so I'd have build it from Debian source myself but it's not that urgent and if we bug the archive-admins enough we'll have it soon :P
<bdrung> iulian: thanks
<sebner> cjwatson: ^^^
<ari-tczew> MOTU SRU, please more activity until end of march, because intrepid is going to EOL
<pitti> ari-tczew: "more activity"?
<ari-tczew> pitti, yea, take a look sometimes
<pitti> all queues are empty, and everythign verified got moved to updates
<pitti> ari-tczew: the SRU team isn't responsible for verifying updates
<ari-tczew> huh? I'm waiting to review
<sistpoty|work> maybe motu-sru vs. ubuntu-sru mismatch?
<pitti> (it's the same team now)
<Laney> ari-tczew: what bug are you talking about?
<sistpoty|work> (yes, but not everyone may know... like I see things in the queue for motu-release here and then ;))
<ari-tczew> Laney bug 421684
<ubottu> Launchpad bug 421684 in obexd "bluetooth send malformed files " [Undecided,Confirmed] https://launchpad.net/bugs/421684
 * sebner waves at sistpoty|work :)
<pitti> ari-tczew: erm, you just submitted that 18 hours ago..
<sistpoty|work> hi sebner
<iulian> bdrung: Accepted.
<bdrung> iulian: thanks.
<ari-tczew> pitti: I know, but I'm impatient because there is no time
<pitti> ari-tczew: "no time"?
<sebner> bdrung: yeah, now we need a archive-admin. Let's ask pitti :P
<pitti> ari-tczew: karmic has been out there for 4 months, it hardly makes a difference whether we push SRUs a day earlier or later?
<bdrung> sebner: eithar that or i do it by myself.
<pecisk> kenvandine: ping? :)
<pecisk> kenvandine: https://bugs.edge.launchpad.net/gwibber/+bug/259830
<pitti> sebner: hm?
<ubottu> Ubuntu bug 259830 in gwibber "Honor gnome proxy setting" [Medium,Confirmed]
<pecisk> kenvandine: patch is there
<sebner> bdrung: nah, I consider this bad pratice
<kenvandine> pecisk, thx
<sebner> pitti: do you mind to sync bug #544075?
<ubottu> Launchpad bug 544075 in eclipse "[FFe] Please sync eclipse 3.5.2-2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/544075
<pitti> speaking of impatience... :)
<ari-tczew> pitti, omfg! I'm wrong! mistake intrepid with karmic shit, nevermind :P
<sebner> *hrhrhrhr*
<pitti> ari-tczew: SRUs for intrepid are pretty much closed anyway now
<cjwatson> ari-tczew: and in any case, a release about to go EOL means we do less work on it, not more
<sebner> pitti: I still prefer (if time allows) archive admins sync >>>> manual sync upload (with your script)
<cjwatson> no point doing lots of hard work when it's about to go away anyway
<sebner> cjwatson++
<pitti> also, intrepid is so old now that any bug that is in it is hardly important enough now to get fixed
<pecisk> kenvandine: will be here for some ten mins, if you have any questions, then to home, will be back at after half and hour
<pitti> people have either upgraded to a newer version, or abandoned Ubuntu, or learned to live with the bug
<kenvandine> pecisk, looks straight forward... i just wish there was a way we could do that without importing gconf in the backend :/
<pitti> sebner: right, but syncs are much more efficient to be done in batches during regular archive days
<pecisk> kenvandine: why?
<kenvandine> pecisk, we desparately want to keep the service light
<pecisk> well
<pecisk> it is your decision :)
<kenvandine> and not gnome specific
<pitti> sebner: anyway, syncing now
<kenvandine> pecisk, i don't see any other way though...
<sebner> pitti: hrm, yes but in reality this is something between 1 and 10 days tells my experience. Thanks! :)
<pecisk> kenvandine: if you keep this for Ubuntu only, then python-gconf is already in deps
<ari-tczew> pitti, cjwatson: so security updates are too not necessary? for intrepid
<sebner> bdrung: see ;)
<kenvandine> pecisk, yeah... the dep is the least of it, it is memory footprint
<pitti> ari-tczew: they are
<pitti> ari-tczew: but usually not SRUs any more
<kenvandine> pecisk, but really there is no straight forward way to do that any other way
<bdrung> great
<ari-tczew> okay, thanks! and I'm waiting for response to SRU for karmic :)
<pecisk> kenvandine: you can grep gconf xmls, but it will take much more resources
<kenvandine> pecisk, ideally gnome settings like proxy info would just automatically be exported in your login shell so the whole desktop has access to it
<kenvandine> eeww
<pitti> kenvandine: it is
<pitti> kenvandine: $http_proxy
<pitti> GNOME sets that
<kenvandine> pitti, not in a terminal
<pitti> so that it's working with wget and just about any other program
<pitti> kenvandine: sure it does
<kenvandine> really?
<pitti> if not, that's a bug
<pecisk> pitti: no, it doesn't
<kenvandine> then why is this even an issue :)
<pitti> pecisk: WFM..
<kenvandine> pitti, how are you testing it?
<pecisk> pitti: I am siting behind nice firewall without any other access than proxy, and I have tested this well :)
<kenvandine> gnome-terminal gets it from gconf, i think
<jdstrand> ari-tczew: fyi, intrepid is fully supported until the end of April
<pitti> system -> prefs -> proxy
<pitti> select my "proxoid" profile (for my G1)
<pitti> open terminal
<pitti> $ echo $http_proxy
<pitti> http://localhost:8080/
<kenvandine> pitti, how about from like xterm?
<ari-tczew> jdstrand, ah until end of April? okay, thanks! :)
<pitti> kenvandine: doesn't work in xterm for me
<pecisk> hmmm
<pecisk> pitti, you're right
<Laney> kenvandine and pitti: We talked about this earlier
<kenvandine> yea... gnome-terminal sets that up for you
<kenvandine> Laney, i know :)
<pecisk> kenvandine: but it doesn't let Gwibber work anyway
<pitti> but why doesn't the proxy thing just export it to the entire session..
<Laney> you have to read it from gconf on a per app basis basically
<pitti> that would work so much better
<Laney> pitti: mvo gave some reasons in scrollback
<pitti> I don't think we should fix each and every program to work with that
<kenvandine> pitti, it would solve lots of potential for problems...
<Laney> kenvandine: did you try libproxy?
<Laney> that was the suggestion
<kenvandine> no
<Laney> it's supposed to abstract all of this
<mvo> pitti: see scrollback, I'm not opposed at all, we just need to think about the corner cases
<Laney> scrollback in #ubuntu-desktop
<kenvandine> Laney, can you get at libproxy from python?
<pitti> mvo: you mean opposed to exporting $http_proxy to the session?
<Laney> kenvandine: yeah there are binding
<Laney> s
<pitti> mvo: I actually thought that's what it would do anyway
<bdrung> pitti: thanks
<kenvandine> mvo, i can't think of a case where you wouldn't want that
<kenvandine> if you set it for your desktop, you likely need it
<pecisk> pitti: if proxy has auth, how http_proxy looks like then? http://user:password@host:port/
<Laney> I have to set it for work and then unset when I get home
<kenvandine> Laney, yeah... but you do that via gnome right?
<Laney> yep
<pitti> pecisk: I don't know, probably?
<kenvandine> pecisk, yes
<Laney> apps won't be able to tell when the env var changes, so they'll have to be relaunched
<kenvandine> humm
<Laney> not that that's any worse than the current situation where they don't work at all
<kenvandine> that is ugly
<pecisk> kenvandine: in nutshell, I think reading it from gconf would be proper and easier way to do this, but that's just me :)
<kenvandine> sure
<kenvandine> pecisk, for now... i just wonder how much memory that takes :)
 * kenvandine will profile
<Laney> but maybe the libproxy api supports events for this
<kenvandine> i do know the libproxy author :)
<pecisk> kenvandine: will do profiling now or later? :)
<kenvandine> pecisk, soonish :)
<kenvandine> fixing a u1music store bug atm
<pecisk> kenvandine: ok, you will be here after 2 hours?
<kenvandine> pecisk, yup
<pecisk> nice
<pecisk> see ya later
<kenvandine> pecisk, give me a ping when you get back
<kenvandine> thx for the patch!
<pecisk> np ;)
<mrenouf> Packaging question: I've got a couple custom packages. I'd like a new version of one to replace the other. Each "Conflicts" with the other, and the new one is marked with "Replaces" the other. The other one does get uninstalled, but it seems to remain selected, aptitude prompts be to resolve a conflict by putting things back (reinstall the removed one, downgrade the other). How can I prevent it ending up in this state?
<pitti> Keybuk: do you plan to update udev to a new upstream version in lucid still? or should I start cherrypicking keymap changes to the ubuntu package?
<Keybuk> pitti: no, kay changed something fundamental that I don't want to include in lucid
<Keybuk> can't remember what that is, but I remember reading the patch and putting the safety catch on the upload button ;)
<pitti> ok
<Keybuk> so yes, backport keymap fu
<pitti> Keybuk: would you mind if I backport a bug fix or two, and some rules for keymaps?
<pitti> ok, that's fine
<pitti> the next bzr merge should get along with it
<Keybuk> (though 151 is still the latest)
<pitti> Keybuk: at least it means that I don't need to coordinate with you any more to do the git-> bzr dance :)
<mrenouf> sorry if this is not the right place ;-) #ubuntu was no help
<pitti> Keybuk: okay, thanks
<Keybuk> pitti: yeah, you only need that for new upstream versions
<cjwatson> pitti: should bug 445852 be assigned to you?
<Keybuk> the *day* that they get the udev import into lp working, I'm going to cheer very loudly
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/445852)
<Keybuk> so loudly that for a brief moment, you won't be able to hear elmo laugh
<pitti> lol
<pitti> Keybuk: what about StevenK?
<pitti> cjwatson: uh, I'll have a look at this, yes
<Keybuk> pitti: nothing is that loud
<Keybuk> pitti: that's the libatasmart bug that Lennart claims is deliberate behaviour, or something
<pitti> Keybuk: that, too?
<Keybuk> even though it's not doing the same thing as smartmontools
<Keybuk> and if it was doing the same thing as smartmontools, it wouldn't kill people's SSD
<pitti> Keybuk: I recently fixed the libatasmart bug that says "OMGyourdriveisbroken!!"
<pitti> where lennart said it'd be deliberate
<Keybuk> this is the libatasmart that *causes* you to say OMG MY DRIVE IS BROKEN!
<pitti> I haven't seen that one yet
<Keybuk> in the bugzilla bug
<highvoltage> Keybuk: I couldn't find the text-fallback theme settings in the theme script, where would I find that?
<Keybuk> highvoltage: the what?
<Keybuk> pitti: read through the bug, and see the associated kernel.org and fd.o bugs
<Keybuk> basically libatasmart does something invalid and invasive to the SSD that can kill the firmware of some of them
<Keybuk> (it ended up on udev at one point, so I aided in debugging back then, and traced it to devkit-disks)
<pitti> Keybuk: yes, will do; as I said, I haven't seen #445852 yet; I just dealt with bug 438136 the othher day
<ubottu> Launchpad bug 438136 in libatasmart "palimpsest bad sectors false positive" [Medium,Fix released] https://launchpad.net/bugs/438136
<Keybuk> yeah
<Keybuk> bug #445852 is more fun
<ubottu> Launchpad bug 445852 in libatasmart "devkit-disks-probe-ata-smart causes HSM Violations on SSD, and potential hardware death" [Unknown,Confirmed] https://launchpad.net/bugs/445852
<Keybuk> popey has the smouldering remains of some hardware iirc
<Keybuk> (he first alerted me to it)
<popey> :)
<popey> its fixed now after maximum prejudice with dd
<popey> although if I did install karmic, it would break again
<Keybuk> popey: does it not break on lucid?
<highvoltage> Keybuk: sorry, I'm talking about plymouth
<Keybuk> highvoltage: yes, but I didn't understand your question
<popey> i dont know, I haven't installed clean karmic on it
<popey> due
<popey> gah
<popey> s/karmic/lucid
<popey> i upgraded from a fixed karmic install to lucid
<highvoltage> Keybuk: for the edubuntu theme, it still shows the purple background and "Ubuntu" in the text fallback mode, how can I change the background and text for the fallback mode?
<Keybuk> highvoltage: you can't
<highvoltage> Keybuk: ok
<Keybuk> you could write an edubuntu-text theme that had a different background color and text ;)
<highvoltage> Keybuk: would you mind if I file a feature request for that for lucid+1?
<Keybuk> highvoltage: only if you also supply a patch <g>
<highvoltage> Keybuk: sounds like an interesting project, I might just take you up on that
<Keybuk> there might be a way to do it
<Keybuk> themes in plymouth are ini files
<Keybuk> if there's a way to add custom fields to those ini files, and source them from the plugin that actually draws it
<Keybuk> then we could make ubuntu-text pick up the colours and text from its theme ini
<Keybuk> so we'd have one ubuntu-text.so
<Keybuk> but /lib/plymouth/themes/ubuntu-text
<Keybuk> and /lib/plymouth/themes/edubuntu-text
<Keybuk> which both just contained an ini file that re-used the same plugin
<Keybuk> if you can find out, that would be AWESOME!
<pitti> Keybuk: is lp:~ubuntu-core-dev/udev/ubuntu still "the" branch? or did you switch to lp:ubuntu/udev now?
<Keybuk> I think lp:ubuntu/udev
<Keybuk> but I may have pushed to both
<davmor2> meh wifi isn't connecting, it's showing AP but not connecting to them after yesterdays kernel update.  BCM wifi card using sta driver.
<pitti> for lp:ubuntu/udev we should drop vcs-bzr:
<Keybuk> pitti: right, but last time I pushed there, the branch vanished again
<Keybuk> so I haven't "definitely" pished yet ;)
<Keybuk> ah
<Keybuk> no
<Keybuk> lp:ubuntu/udev has been overwritten *again*
<Keybuk> so carry on using lp:~ubuntu-core-dev/udev/ubuntu
<pitti> Keybuk: ack
<Keybuk> all the time the udev import fails, it seems the importer retaliates by wiping and restarting
<pitti> Keybuk: there is a magic "bzr mark-uploaded" (or so) command
<pitti> I'm not sure what it does, though
<pitti> I didn't need to use it for the last couple of uploads I did with package branches
<cjwatson> mark-uploaded => bzr tag $(top thing from debian/changelog)
<Keybuk> yes
<Keybuk> it doesn't help ;)
<Keybuk> it still wipes branches every now and then
<pitti> cjwatson: ah, is that like debcommit -r?
<Keybuk> but only if they're problem branches
<cjwatson> pitti: yes
<pitti> cjwatson: ah, that's why I don't need it then
<pitti> dch -r/debcommit -r is hardwired in my fingers by now
<mdz> Keybuk: I've been helping mfrey isolate a race which causes mountall to stall waiting for the root filesystem to be mounted. can I run a theory by you for sanity checking?
<Keybuk> mdz: of course
<Keybuk> is this different to "the kernel calls the root filesystem /dev/root, and there's no symlink for that in udev" bug?
<mdz> Keybuk: I looked at that one, and yes, this looks different
<mdz> Keybuk: what I think is happening is that it's missing udev events while blocking in ply_event_loop_run()
<Keybuk> event queue overflowing?
<Keybuk> or because it's blocking, it's not actually waiting for events?
<mdz> Keybuk: because it's blocking in ply_event_loop_process_pending_events, which I don't think will wake up if there are udev evetns
<mdz> because it's only polling on the plymouth fd
<mdz> and not the udev monitor fd
<Keybuk> right, but when it comes out of that poll - it should see the pending udev events, right?
<mdz> Keybuk: it blocks there forever without timing out
<Keybuk> yes
<Keybuk> it's waiting for you to press a key in plymouth ;-)
<Keybuk> this is a bug
<Keybuk> we shouldn't do it that way at all
<Keybuk> but I was in a rush when I wrote that code
<Keybuk> better code is on my To Fix list this week
<Keybuk> (about to get kicked out of coffee shop - but on IRC at __keybuk :p)
<mdz> Keybuk: should I open a bug? do you want to describe the fix and maybe one of us can take a stab at a patch?
<mdz> __keybuk: ^^
<__keybuk> Sure
<mdz> __keybuk: on plymouth?
<__keybuk> Though bear in mind that all the Plymouth code in mountall is going to change anyway
<mdz> or mountall?
<__keybuk> No on mountall
<__keybuk> The epoll fd of Plymouth can be stuffed into libnih's own main loop
<__keybuk> So mountall never needs to block on it
<mdz> __keybuk: how ought it to work? should it run nih_main_loop instead of ply_event_loop_run?
<__keybuk> This also fixes the waits for a filesystem that shows up while waiting issue
<mdz> __keybuk: in fact I think it already does watch the plymouth fd
<__keybuk> It should not block at all
<__keybuk> It should put a message up, and deal with key events in the normal main loop
<mdz>         NIH_MUST (nih_io_add_watch (NULL, *(int *)ply_event_loop,
<mdz>                                     NIH_IO_READ,
<mdz>                                     (NihIoWatcher)ply_event_loop_process_pending_events,
<mdz>                                     ply_event_loop));
<__keybuk> Right that's what it should use
<__keybuk> Rather than a separate one for the prompts
<mdz> __keybuk: so I think I know how to get rid of the ply_event_loop_run call, but I don't know how to avoid ply_event_loop_process_pending_events blocking
<__keybuk> That should never block
<__keybuk> If it does Plymouth has a bug
<cjwatson> barry: lp:~ubuntu-foundations-team/+junk/task-assignments - feel free to commit directly
<__keybuk> It will only get called when the epoll fd polls true
<__keybuk> And that means epoll_wait should not block on that fd
<mdz> __keybuk: I agree, though it would be nice if this could be coded more defensively
<mdz> since it ends up stalling the boot if there is a bug
<__keybuk> I think fixing the bug is better than assuming the code is buggy
<mdz> __keybuk: which reminds me...I noticed along the way that if plymouth exits while we are blocked in this state, mountall remains blocked
<mdz> so there are surely other cases where this could be triggered, e.g. a plymouth crash
<mdz> I'm not sure whether that's because epoll() is blocking, or it's not noticing the error when it does
<__keybuk_> Oops
<mdz> __keybuk_: did you miss my previous few messages?
<__keybuk_> Probably
<mdz> __keybuk_: pasted to /query
<doko> ttx: https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/544459 any opinion on this? applications getting their updates (not just extensions and plugins) over the web and shadowing parts of the system libs?
<ubottu> Ubuntu bug 544459 in netbeans "netbeans downloads it's own updates over the web" [Undecided,New]
<__keybuk_> Probably neither l
<highvoltage> __keybuk_: sorry I was away a bit, I'll check it out, thanks for the insight
<__keybuk_> Epoll will go true cause fd polls true for Reading etc
<__keybuk_> Plymouth runs epoll twice
<__keybuk_> Argh
<__keybuk_> It sounds more like Plymouth runs epoll twice
<__keybuk> If select/poll/epoll had bugs, we'd know about them ;)  they'd affect more than half-finished code I wrote on a train :p
<mdz> __keybuk: so...bug on mountall (should avoid calling blocky libply function) and bug on plymouth (function shouldn't be quite so blocky)?
<__keybuk> I'd blame my code in mountall first :)
<__keybuk> Mountall has to call into Plymouth to process events - so a "should avoid" bug is nonsense
<mdz> __keybuk: so...bug on plymouth (ply_event_loop_process_pending_events shouldn't block) and leave mountall using ply_event_loop_run()?
<__keybuk> Right
<__keybuk> And make sure mountall is actually behaving
<__keybuk> Which it definitely isn't in many paths
<mdz> and there are at least two cases in which it can block, one of which is unknown and the other is when the plymouthd process exits
<mdz> the unknown one may be when it's waiting for a keystroke, but I haven't confirmed
<__keybuk> The "boredom" code is definitely wrong
<__keybuk> Fd close > I may not have set a handler for that
<__keybuk> Mountall is next on my todo list after Plymouth
<AnAnt> ah, Hello, what's the license of the ubuntu-logo plymouth artwork ? I don't see anything explicit about it in /usr/share/doc/plymouth/copyright
<AnAnt> or who can I ask ?
<pecisk_> kenvandine, I am back :)
<kenvandine> hey
<kenvandine> looks like libproxy is much lighter weight and we could easily use your existing patch with slight modifications
<kenvandine> if we went the libproxy way
<kenvandine> just instead of using gconf to get it, use libproxy to get the values
<pecisk_> kenvandine, libproxy can get values from GNOME proxy settings?
<kenvandine> yes
<kenvandine> it is like 1/3 the size, memory wise
<kenvandine> pecisk_, and it isn't dependent on gnome... i think it works in other environments
<pecisk_> nice :)
<pecisk_> kenvandine, it won't make gwibber depend on libproxy?
<pecisk_> on python-libproxy I mean
<kenvandine> it would, but we ship with that anyway
<pecisk_> allright then
<kenvandine> well we could just include enough libproxy code in gwibber for now
<kenvandine> license is friendly to do that, and it is super small
<pecisk_> :)
<pecisk_> kenvandine, ok, seems fairly easy, I will try to modify patch right now
<kenvandine> pecisk_, awesome... thx!
<ccheney> how do you manually create a deb with ar?
<ccheney> assuming i have the three pieces already? control.tar.gz  data.tar.lzma  debian-binary
 * ccheney is trying to test a change in install scripts and didn't want to rebuild OOo to do it
 * ccheney bets he probably added the files in wrong order
<ccheney> yea order of files matters, must be in order of: debian-binary control.tar.gz data.tar.lzma
<Caesar> slangasek: before I do the work to write up a FFe for rsyslog, what's the likelihood of it being approved?
<highvoltage> Caesar: well, usually you'd put the rationale/risks/etc in the FFe, how would he be able to tell you that without having seen that?
<Caesar> highvoltage: it's true
<highvoltage> Caesar: there's a lot of packages going through every day, I think that if the reasons are sound there's a good chance
<Caesar> The reasons that I'm being asked to do it relate to the current version being old, and the version currently in Debian testing is the last development change to that branch
<Caesar> Bugfixes only from here on
<Caesar> I'll go ahead and write up an FFe as time permits
<beuno> pitti, hi  :)   who do I talk to about aptitude segfaulting all the time in lucid?
<beuno> I've reported the bug with the dump attached, but I rarely can due to things to being up to date
<beuno> which is usually why I'm running aptitude  :)
<slangasek> Caesar: I assume that you will be giving me a clear FFe that presents a reasonable analysis of the tradeoffs, and that it is likely both to be approved and to be approved quickly.
<slangasek> :-)
<Caesar> slangasek: I'll do my best
<cody-somerville> For lp #507238, does the fallback text theme also have alternatives support?
<ubottu> Launchpad bug 507238 in plymouth "No alternatives support for default theme yet, all themes in main package" [Medium,Fix committed] https://launchpad.net/bugs/507238
<jdstrand> ttx, kirkland: I am working on a merge of libvirt 0.7.7-4 as part of my apparmor work this cycle (the plan was to work off newer code and backport my work to 0.7.5-5ubuntu15 which is in lucid now)
<jdstrand> ttx, kirkland: that said, I looked at http://libvirt.org/news.html 0.7.6 and 0.7.7 do not offer many new features, but offer a ton of bugfixes. are you interested in 0.7.7 for lucid?
<jdstrand> ttx, kirkland: if not, that's fine, I just thought since I was doing a merge anyway, you might be interested
<okn> hi eveyone
<okn> I looking for help
<okn> to develop wubi-like software for another linux distro
<okn> namely pardus
<Some_Person> Why does gdm conflict with usplash?
<slangasek> Some_Person: because usplash and gdm no longer play well together on the question of VT management (and won't in the future, plymouth now owns this at boot time)
<Some_Person> So I can't ditch plymouth and use usplash instead
<slangasek> any attempt at doing so would fail horribly for reasons deeper than gdm
<superm1> would it be worthwhile removing it from the archive then too to prevent allowing people to break so bad?
<slangasek> superm1: probably; though perhaps we should explicitly push plymouth a bit farther down the stack before doing so (e.g., mountall doesn't currently depend on it)
<cjwatson> okn: I explained this in depth to somebody else just a day or two ago, so rather than me repeating it, I'd recommend you read the logs - they're on irclogs.ubuntu.com, this channel, you should only have to look back a couple of days
<okn> cjwatson: thx
<arpu> hello
<arpu> anyone can help me find out the problem on this bug https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/531556
<ubottu> Ubuntu bug 531556 in gdm "[Lucid] Blank Screen after login" [Undecided,Confirmed]
<arpu> same problem on intel grafic card
<Some_Person> slangasek: Why would replacing plymouth with usplash fail horribly? That's what karmic used
<slangasek> Some_Person: a) I guess you haven't seen the bug list for karmic, b) the software hasn't stood still since then, and a fair amount of code has changed since karmic to use plymouth to the exclusion of usplash, precisely to fix the bugs on that list :)
<jbebel> cjwatson or superm1, Are ubiquity plugins the new method of adding custom hooks to oem-config?  And is there any relatively simple method of converting old oem-config hooks to ubiquity plugins?
<Some_Person> slangasek: You're right, I have not seen the bug list
<Some_Person> slangasek: But what about all the people with plymouth not working?
<lifeless> Some_Person: we should fix those bugs
<cjwatson> jbebel: you can still add post-install hooks as before, and that's still the simplest approach for noninteractive hooks
<cjwatson> jbebel: if that worked for you before, you shouldn't need to change.  plugins allow you to do interactive things
<Pretto> what is the package for shutdown option in the memenu?
<jbebel> We need these to be interactive.  For instance, this is where we get the users real password and apply it to LUKS.
<slangasek> Some_Person: the only place where plymouth is known to outright not work is on nvidia with the nouveau driver and multiple displays; everything else should be at various stages of "working", and getting better
<jbebel> relating to the email you should have received about preseeding a default crypto password.
<Some_Person> On my intel graphics, I don't see plymouth on boot but do on shutdown
<cjwatson> jbebel: Ubiquity/Plugins on the wiki has the interface docs, but ev and superm1 have done much more than I on that
<slangasek> Some_Person: bug #535108 - there's a one-liner you can use to force the boot splash on startup, and the expense of boot speed
<ubottu> Launchpad bug 535108 in plymouth "Hide console messages while Plymouth is running" [Low,Fix committed] https://launchpad.net/bugs/535108
<cjwatson> Some_Person: on hdds, we don't show the splash until after ureadahead has finished, because the alternative approach slows down boot
<cjwatson> Some_Person: we have a plan for lucid+1 that will fix that, but it requires a newer kernel and is generally too intrusive for lucid
<jbebel> I didn't write the previous oem-config hooks, but it looks like we dropped some things into oem_config/components and oem_config/frontend which asked the questions for us.
<jbebel> This was for hardy.
<cjwatson> jbebel: ah, so not the post-install hooks I was thinking of then.  you'll need to migrate those, but I don't know of a howto
<jbebel> right.  We have a post-install hook as well, but it's the interactive part I need to migrate.
<cjwatson> your component should turn into the main plugin file, and you'd migrate the frontend changes into PageGtk etc. classes in the plugin file
<Some_Person> cjwatson: I did notice that the live CD's splash seems to work
<cjwatson> Some_Person: yes, the live CD starts the splash in the initramfs instead because that typically takes much longer and live CD boot speed isn't critical
<cjwatson> and we don't do ureadahead on the live CD anyway
<jbebel> Ok.  Thanks.  I'll read through the doc and experiment.
<Some_Person> cjwatson: Is the speed difference really noticible?
<slangasek> Some_Person: yes - the liveCD uses the equivalent of the one-liner change in that bug
<cjwatson> Some_Person: yes, it can be
<Some_Person> So this will not be fixed with lucid's release
<cjwatson> Some_Person: you basically end up doing nothing else for a bit except waiting for the framebuffer to come up (can take seconds) or else ruining ureadahead's perf by doing something else while it's running
<slangasek> the fact that boot splash doesn't show up on every boot on all systems will not be fixed for lucid, no
<cjwatson> on the upside the lucid+1 plan is *really* cute
<Some_Person> What's the plan for lucid+1?
<slangasek> however, slightly more importantly, the boot splash *will* show up reliably when you need to interact with the boot scripts because, say, your hard drive needs surgery
<cjwatson> we should be able to run in graphical mode all the way from the bootloader, and in many cases without a mode switch
<cjwatson> using efifb with handoff to a kms driver as necessary
<cjwatson> we won't have to change bootsplash system to do this, so we won't lose the reliability benefits of multiplexing I/O through plymouth
<Some_Person> Another big question: why do 2 old themes still in the repos require a now-unsupported GTK+ theme engine?
<RAOF> cjwatson: Then all we'll need is some hardware that supports EFI?
<barry> RAOF: like a mac?
<RAOF> barry: And aren't they shiny! :)
<barry> RAOF: they are indeed
<cjwatson> RAOF: that's what I thought initially, but it turns out I was wrong
<cjwatson> RAOF: probing efifb from scratch requires EFI, yes, but actually running it only requires a simple linear framebuffer region in memory
<cjwatson> RAOF: so if grub2 sets up efifb's screen information structures in memory at boot (it already knows how to do this), then it works on non-EFI systems too
<ttx> jdstrand: about libvirt, I think it's interesting, but I'd wait for kirkland's advice -- I know he planned to work on libvirt soon
<cjwatson> RAOF: the thing we're missing in lucid is handing off from efifb to a KMS driver
<RAOF> cjwatson: Sweet!  That sounds surprisingly simple.
<cjwatson> RAOF: this is what gfxpayload=keep in grub2 does, and is why lots of people are raving about it
<cjwatson> it's just not *quite* ready for general use yet
 * ttx disappears
<RAOF> Aaah.
<cjwatson> but apparently it's fixed in 2.6.33
<RAOF> Does that mean I'd miss out on Keybuk's awesome text-mode plymouth theme, though? :)
<cjwatson> afraid so ;-)
<RAOF> Awwwww!
<petn-randall> Hello, I've found a way to squash two bugs in Lucid, how do I get to upload the packages? I've got a launchpad account
<slangasek> you can console yourself by installing grub-invaders
<petn-randall> Is there some mentoring program like in Debian?
<cjwatson> (also I'm definitely not willing to switch how the boot framebuffer works a few weeks before release!)
<RAOF> Is that what I think it is?  Space invaders from the bootloader?
<cjwatson> petn-randall: https://wiki.ubuntu.com/SponsorshipProcess is probably a decent place to start
<petn-randall> thx
<cjwatson> grub-invaders> it's actually booted from GRUB, rather than running in GRUB directly
<cjwatson> it's multiboot-compliant, hence the grub- prefix
<petn-randall> hmmm .... how can I sign up as a MOTU developer with upload rights?
<petn-randall> Is this a lengthy process like becoming a DD?
<cjwatson> it's on the same general order of magnitude as joining Debian, but I think usually somewhat quicker
<cjwatson> https://wiki.ubuntu.com/UbuntuDevelopers
<cjwatson> (that's maybe not the best entry point, but it's one I had to hand)
<petn-randall> ok, I'll work my way through from there, thanks again cjwatson :)
<petn-randall> cu
<slangasek> bryceh: bug #545832 has just come in; it appears users who are using the fglrx driver still see the radeon KMS driver used at boot time - probably a kernel bug, do you know for sure / have you seen this bug before?
<ubottu> Launchpad bug 545832 in plymouth "System fails to boot with plymouth+radeon+fglrx" [Undecided,New] https://launchpad.net/bugs/545832
<barry> slangasek, bryceh i saw some problems with my radeon when i upgraded to lucid.  switched to using the xorg-server-edgers ppa (or whatever it was called).  that fixed things, with a small glitch here and there
<slangasek> barry: what sort of problems?
<bryceh> slangasek, weird, probably more a question for tseliot though
<bryceh> or apw maybe
<barry> slangasek: system crash after getting purple splash screen
<slangasek> bryceh: I was hoping you could channel him since he logs off in the evening :-)
<RAOF> That'll be a failure of the fglrx packgae to properly blacklist radeon, surely?
<bryceh> RAOF, yeah that's what I'm thinking
<slangasek> ah, it adds blacklists? ok
<slangasek> "it" --> "nvidia"
<barry> dont ask me, i know so little about this stuff ;)  but i'm willing to be a guinea pig for anything you want to test.  i'd like to not use the ppa packages if possible
<slangasek> barry: do you have fglrx installed?
<bryceh> it's possible people can louse up their systems if they manually install things without updating initramfs
<barry> slangasek: is there an easy test of that?
<barry> bryceh: i just did update-manager -d :)
<slangasek> barry: 'dpkg -l fglrx', I believe :)
<bryceh> afaik as long as you use update-manager it should blacklist radeon for fglrx
<bryceh> tseliot would know better
<barry> slangasek: ah :) no, not installed
<bryceh> barry, aha
<slangasek> bryceh: hrm, would've thought that's jockey's job to do the blacklisting, or the package itself, not u-m
<bryceh> barry, did you uninstall it yourself or did it get uninstalled by the upgrader?
<barry> bryceh: i've been meaning to ping you about this since i upgraded last week but have just been kind of swamped ;)
<bryceh> slangasek, specifically (IIRC) it's in the post-inst script of the package
<barry> bryceh: i had some weird stuff going on when i upgraded because it had some nvidia stuff loaded.  i think i might have uninstalled fglrx
<bryceh> slangasek, so update-manager and jockey should both be triggering the same thing
<barry> bryceh: ftr, i have an HD 4670
<slangasek> bryceh: heh, quite
<bryceh> barry, ah then that is probably what happened
<barry> bryceh: but i don't think i did that until *after* i noticed the crashes
<bryceh> the upgrader is not super smart about cleaning up situations where the user manually installed/uninstalled stuff
<barry> bryceh: iow, update-manager -d; reboot; crash; boot from live cd; chroot + fix; reboot
<slangasek> bryceh: I'm not aware of any cases where the upgrader itself isn't smart about this; are bugs filed an update-manager?
<barry> bryceh, slangasek: /me -> dinner.  if you need a guinea pig i can check back later or tomorrow and retry standard packages
#ubuntu-devel 2010-03-25
<slangasek> bryceh: ok, the fglrx package appears to check out as DTRT, I think the submitter of that bug simply didn't use the Ubuntu fglrx package
<bryceh> slangasek, yep, that's what I thought.  It's sort of a known donut hole.  I put it in our spec and test plans to try to handle the corner case better but I think tseliot had too many other tasks to juggle
<superm1> the problem is that the changes for the fglrx packaging don't trickle into AMD's releases for 2-3 releases
<psusi> hrm... seems the disk UUID mapping gives preference to the snapshot over the original volume.... not good.
<soren> psusi: What, still?!?
 * soren facepalms
<soren> kees: Would you say bug 460906 is important enough to be fixed this late in the cycle?
<ubottu> Launchpad bug 460906 in lvm2 "disk/by-uuid/foo symlink points to snapshot rather than the origin" [Undecided,Confirmed] https://launchpad.net/bugs/460906
 * soren thinks so
<hyperair> that suonds like a potentially problematic bug
<soren> Indeed. I spotted it quite late in the karmic cycle (a few days before release, apparantly) and then forgot all about until just now.
<kees> soren: I still don't have much of an opinion about it.  I think by-uuid for a snapshot is kind of meaningless (i.e. the lv name is the unique part)
<kees> soren: there is logic for the link either direction.
<slangasek> doko_: I've confirmed that bug #417757 *is* still present in lucid
<ubottu> Launchpad bug 417757 in eglibc "[karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups" [High,Fix released] https://launchpad.net/bugs/417757
<twb> Can I make pbuilder automatically run lintian on the .changes file it generates?  If so, how?
<pitti> Good morning
<pitti> beuno: aptitude> hm, not sure; mvo?
<dholbach> good morning
<[reed]> anybody know why Ubuntu's apache2 doesn't link against libssl like Debian's does?
<twb> [reed]: from the PTS page (http://packages.qa.debian.org/a/apache2.html) you can find a link to the patch between Debian and Ubuntu.  That usually explains why.
<twb> I can't see anything obvious there, so maybe you misdiagnosed it?
<primes2h> pitti: Hello, please wait a moment before closing bug 536914. I found out there are other few keys that needs fixing (<255) I'll tell you when I finish.
<ubottu> Launchpad bug 536914 in udev "[Lucid Alpha3][khk-004 testcase failed] Click on Internet hotkey opens Home folder on Acer Laptops" [Medium,Fix committed] https://launchpad.net/bugs/536914
<pitti> primes2h: hm, I thought I reopened it already?
<pitti> ah, I did
<pitti> primes2h: ok, waitin gthen
<primes2h> pitti: Yes, I mean, there is still other 2 keys  I have to triage
<primes2h> pitti: thanks
<primes2h> pitti: I also sent a message to our Italian Testing ML asking Simona (Aspire 1640) to tell me about her full keyboard layout.
<primes2h> pitti: I'll let you know ASAP
<TheMuso> pitti: Would I break anything if I were to include the checking of hd[a-z] in the 60-cdrom_id.rules udev rule? This is needed for lucid only, as there is no libata version of powerpc/mac's IDE driver. A driver is supposedly in 2.6.33, so this rule change is only needed till lucid+1, and its safer than backporting a driver in the kernel.
<mkarnicki> lwindow 1
<mkarnicki> oops sry guys ;)
<pitti> TheMuso: this sounds very similar to what Debian has to do; I thought mbiebl already had a patch for IDE CD-ROMs, let me check
<pitti> TheMuso: http://git.debian.org/?p=pkg-utopia/udisks.git;a=blob;f=debian/patches/10-ide-cd-support.patch;h=59a19e4eaf414b9b8bdf0588898d964ff95613f3;hb=HEAD
<pitti> TheMuso: it basically adds the blkid call for ID_CDROM_MEDIA hd*
<pitti> TheMuso: is that what you need?
<TheMuso> pitti: No, I mean actually editing 60-cdrom_id.rules to check for add|change nodes on hd[a-z] for IDE CD devices that are on the pmac driver in 2.6.32 and below, which doesn't have a libata equivalent.
<TheMuso> I'm just wondring whether checking those nodes shoudl they exist will break anything.
<TheMuso> so the change is in udev itself.
<pitti> ah, I see
<pitti> TheMuso: hm, Debian should have that change as well then, otherwise mbiebl's udisks patch couldn't work at all
<TheMuso> true
 * TheMuso checks sid's udev.
<pitti> TheMuso: so, I don't think it would hurt at all, but it'd be the first and only delta to upstream that we have in udev, and I don't think Keybuk will like it a lot
<pitti> TheMuso: OTOH there's nothing wrong with shipping a 60-cdrom_id-ide.rules in a powerpc specific package :)
<TheMuso> pitti: RIght, I can understand that.
<TheMuso> pitti: There is that too. I'll have to see how that could be included in d-i, as d-i installation from alternates on powerpc are broken due to this issue.
<pitti> TheMuso: oh, right, I could just stuff the new rule into debian/ in udev
<pitti> TheMuso: and only install it on powerpc, to be on the safe side
<TheMuso> pitti: that works
<TheMuso> pitti: there is an LP bug for this, reported by someone else. I'll fetch the number.
<pitti> TheMuso: confirmed, sid's udev has the rule like that
<TheMuso> pitti: oh ok you beat me to it.
<pitti> TheMuso: ok, please assing it to me; I'll have a quick discussion with Keybuk about how he wants this packaged, and get to it
<TheMuso> bug 534912
<ubottu> Launchpad bug 534912 in udev "[Lucid powerpc alternate] No common CD-ROM drive was detected." [Undecided,Confirmed] https://launchpad.net/bugs/534912
<TheMuso> pitti: ok thanks.
<mvo> cjwatson: hi, are you ok with the name "SUPPORTED_OVERWRITES.hints" for the fine-tuning file for lucid-support-timeframe? I will put it in lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid - I'm happy about better matching names
<mvo> cjwatson: or maybe SUPPORT_TIME_OVERWRITES.hints ?
<pecisk> kenvandine: hi, are you here? :)
<jibel> mvo, hey, I need advice to fix bug 130289
<ubottu> Launchpad bug 130289 in apt "Encode any ":", "@" or "/" within the user and password field in proxy settings." [Medium,In progress] https://launchpad.net/bugs/130289
<mvo> jibel: let me have a look
<jibel> mvo, the problem is with the way apt reads it's configuration and parse encoded characters.
<jibel> e.g %40 is stored internally as @
<jibel> It's then really difficult to parse an URI with password containing these characters
<jibel> mvo, Is there any way to read the raw value of a configuration item ?
<jibel> If there's no trivial solution I'll update the URI parser.
<mvo> jibel: something like QuoteString etc from apt-pkg/contrib/strutils.cc does not help I assume?
<jibel> mvo, no it will quote the whole string. if there something like Acquire::http::Proxy "http://user2:p%40s%2Fs%3Aword@localhost:3128";
<jibel> mvo, I need the value http://user2:p%40s%2Fs%3Aword@localhost:3128 not user2:p@s/:word or worse user2:p%40s%2Fs%3Aword%40localhost%3A3128
<mvo> jibel: could we read the string from the config, use the URI class to convert it, and then QuoteString/UnQuoteString only on URI.User, URI.Password?
<mvo> jibel: I guess it would make a lot of sense to add a GetRaw to the configuration class in apt itself, let me have a look
<ion> I love seeing fixes for race conditions by adding âsleep 3â. :-) (foo2zjs changelog)
<jibel> mvo, That's what I was thinking too. Add a FindR method and a RawValue member to the Item struct
<ion> tkamppeter: Isnât having a udev script call sleep EBW?
<pecisk> kenvandine: so far I couldn't get libproxy to recognise different server for https, and also it ignores auth. user and password in GNOME proxy settings
<slangasek> ion: elephantine beyond words?
<slangasek> oh, "evil bad wrong"?
<ion> bingo
<slangasek> yes, udev doesn't allow long-lived child processes
<jibel> mvo, the problem is elsewhere. apt reads and stores its configuration correctly but it converts and stores the string a second time.
<pecisk> kenvandine: seems like we will have to patch libproxy to support more than simple proxy handling to have proper support.
<cjwatson> mvo: all-caps is reasonable to avoid clashes - how about SUPPORTED-HINTS?
<cjwatson> EBW> I like "B&R" (Bad and Rong)
<mvo> cjwatson: thanks, SUPPORTED_HINTS is fine, I will use that
<lamont> asac/ogra: http://launchpad.net/builders/gourd
<lamont> this will especially be a win if eglibc is FTBFS on imbe
<jibel> mvo, the problem is in  pkgAcqMethod::Configuration where all the config items are "dequoted" I guess
<mvo> jibel: ohh, that makes sense
<lamont> asac/ogra: since my testbuild of that version of eglibc on gourd resulted in bug 546808
<ubottu> Launchpad bug 546808 in eglibc "armel v7 test failure: test-fpucw, tst-cpuclock2, tst-eintr1, tst-timer" [Undecided,New] https://launchpad.net/bugs/546808
<kenvandine> pecisk, can you check in #libproxy first?
<kenvandine> pecisk, i would be surprised if that was the case
<kenvandine> pecisk, nevermind... i see you did
<kenvandine> rock on :)
<pecisk> kenvandine: i run trough code, it is very simple, they handle only http now
<tjaalton> is there a long backlog of builds or other problems, since ppa packages seem to take many hours before getting built
<pecisk> problem is - if you want to use libproxy in Lucid, it would have rather large feature set to add, and it is kinda no no as far as I know
<pecisk> nevermind that code is kinda simple
<mvo> jibel: apt-get update -o Debug::pkgAcquire::worker=true will show you the configuration messages that are send
<pecisk> run/ran/s
<lamont> tjaalton: lots of uploads, and the extra machines that we generally steal to be ppas are being used for their primary role atm, it would appear
<lamont> at least "many of"
<tjaalton> lamont: ok, I'll wait then
<tjaalton> though at least i386/amd64 buildd's don't have any "'currently building' build records"
<lamont> https://edge.launchpad.net/builders
<jibel> mvo, that's it. I removed the DeQuoteString and the password is ok.
<tjaalton> hah, a lot accurate it seems :)
<tjaalton> +more
 * tjaalton bookmarks
<tjaalton> damn daily/nightly builds ;)
<jibel> cjwatson, hi, could you have a look at bug 545790, 545738, 454354. This is an odd error and there's an increasing number of reports since a few days.
<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
<ubottu> Launchpad bug 545738 in dpkg "package PACKAGE failed to install/upgrade: error writing to '<standard output>': No such file or directory" [High,Confirmed] https://launchpad.net/bugs/545738
<ubottu> Launchpad bug 454354 in dpkg "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Input/output error" [Medium,Confirmed] https://launchpad.net/bugs/454354
<jibel> cjwatson, there error is triggered when dpkg fflush an error message but the fflush fails.
<jibel> cjwatson, The scenario seems to be: user run update-manager, system crash, reboot, apport triggers and report those errors.
<ogra> lamalex, i dont think the test is a HW specific failure (fails on pegatron as well as on babbage afaik)
<ogra> lamont, ^^^
<jibel> mvo, do you think adding an untouched raw config value is the right solution ?
<cjwatson> jibel: any idea when it started appearing?
<cjwatson> jibel: (BTW I really appreciate this sort of active triage/collation work and direct contact with developers on the hot bugs - it's invaluable)
<cjwatson> $ wcgrep 'm_output.*standard output' | wc -l
<cjwatson> 35
<cjwatson> oh dear
<jibel> cjwatson, in karmic, but the rate is higher since the latest beta
<cjwatson> could just be increasing number of upgrades, then
<mvo> jibel: you removed the UnQuoteString in ::Configuration ? or where?
<mvo> jibel: there was a crash bug for a couple of hours in update-manager that may have triggered this
<jibel> mvo, yes, but that's definitely not the right solution ;)
<mvo> jibel: that is why I asked :)
<jibel> mvo, but that confirms that's the problem since there's no more 407 from the proxy.
<mvo> jibel: hm, hm, tircky to solve
<lamont> ogra: hence the bonus points if it does fail on pegatron
<mvo> jibel: but great that we know excactly what the problem is now
<jibel> mvo, have some lunch. cu
<mvo> jibel: see you (and thanks!)
<asac> lamont: can you try to build libplist on one of the newer builders?
<lamont> asac: assuming it builds, how long does it run?
<asac> lamont: really quick
<asac> a couple of minutes
<asac> lamont: its the one that failed because of thumb2 instructions in the test binaries
<lamont>  /home/buildd/libplist-1.1/obj-arm-linux-gnueabi/swig/plistPYTHON_wrap.cxx:9369: warning: deprecated conversion from string constant to 'char*'
<lamont> giggle
<lamont> ah, cool
<lamont> tests 100% passed.
 * asac happy!
<asac> lamont: was that a real archive build? or just a test build?
<asac> e.g. are the bits now in ?
<lamont> just a test
<asac> ah ok
<lamont> forcing the build to happen there requires, um, more work
<asac> heh
 * lamont goes to throw it against the wall a little
<ogra> but that smells very good already :)
<ion> keybuk: You might find a udev script doing âsleep 3â interesting. Oh, and the âsleep 3â is a also âfixâ for a race condition. ;-) The package is foo2zjs.
<Keybuk> *shrug*
<Keybuk> probably works just fine in mandriva
<pecisk> libparted segfaults in daily lucid server cd when trying to get partition tables from hard drives
<cjwatson> pecisk: please submit a bug report with full logs
<pecisk> c
<pecisk> will do
<mvo> jibel: I updated bug #130289 with a possible solution, I would be interessted if it helps
<ubottu> Launchpad bug 130289 in apt "Encode any ":", "@" or "/" within the user and password field in proxy settings." [Medium,In progress] https://launchpad.net/bugs/130289
<tkamppeter> ion, the sleep is called in a script which the udev rule starts in the background. The udev rule exits while the script is still running.
<Keybuk> tkamppeter: why does it sleep though?
<cjwatson> pitti: what's the easiest way for me to test that new ntfs-3g still works with udisks?
<pitti> cjwatson: create an USB stick with an NTFS partition, plug it in, and see if it automounts?
<pitti> cjwatson: I also have a test suite for udisks, which covers NTFS as well
<pitti> http://cgit.freedesktop.org/udisks/tree/tests/run
<pitti> you can just run that
<pitti> cjwatson: but if an NTFS usb stick automounts, it should be okay; I don't suppose it changed the mount.ntfs-3g CLI, did it?
<cjwatson> shouldn't think so
<xnox> Please sponsor sync Bug #546482. It's bugfix & translation lucid-special LTS upstream release.
<ubottu> Launchpad bug 546482 in xiphos "Sync xiphos 3.1.3-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/546482
<mvo> Riddell: I attached a patch to bug #546024, you may want to check if the version is correct and commit to bzr (I don't think I have commit access to the relevant branch)
<ubottu> Launchpad bug 546024 in phonon "file overwrite error" [High,Confirmed] https://launchpad.net/bugs/546024
<lemsx1> Please see bug # 546929 as this affect new installations in today's netboot installer
<cjwatson> pitti: thanks, ntfs test passes, uploading
<pitti> \o/ thanks
<cjwatson> didn't have a handy USB stick but I guess "fs: NTFS ... [cli] [ud] ok" is good enough
<cjwatson> lemsx1: *please* don't file bugs against the 'lucid' project
<pitti> cjwatson: right
<pitti> cjwatson: out of interest, how much of the tests passed for you?
<cjwatson> lemsx1: read the text in ALL CAPS on https://launchpad.net/lucid
<pitti> s/much/many/
<cjwatson> pitti: oh, I just did './run FS.test_ntfs'
<pitti> cjwatson: ah, fair enough
<pitti> cjwatson: I was just curious, since I didn't get a lot of feedback from other people/distros about it yet (except from mbiebl)
<pitti> but nevermind
<cjwatson> lemsx1: I've reassigned your bug to the proper place
<cjwatson> lemsx1: of course the developers of that text editor will keep on getting mailed about it, but ...
<ScottK> mvo: We get phonon from qt4-x11 now.  I moved the bug to the right package.
<mvo> ScottK: thanks
<ScottK> doko_: Does your gcc4.4 ia64 fix mean we can drop the ia64 specific work around in our next qt4-x11 upload?
<pecisk> hi people, if I configure GNOME proxy settings with auth. user and password, I can't get http_proxy as http://user:password@host:port, but simply as http://host:port. It is intentional?
<doko_> ScottK: yes
<ScottK> doko_: Thanks.
<jibel> mvo, it doesn't help. the problem is really with the global dequotestring in pkgAcqMethod::Configuration
<jibel> mvo, we want some config vars to be unquoted and some other not to be.
<jibel> mvo, more precisely, not dequoted at this moment.
<jibel> mvo, couldn't we had an exclusion list of config vars ? And do not apply the DeQuoteString in the Cnf.Set call for those parameters ?
<jibel> pecisk, hi, I can't reproduce.
<mvo> jibel: I think that will work, could you attach a dump of the debug output please to the bugreport (from the pkgworker). I wonder if we can not quote some stuff specially so that on unquote its fully restored or have a different unquoe that ensures only what was quoted before gets unquoted. it sounds like this really what we want, that quote/unquote are fully reversible
<pecisk> jibel: proxy problem?
<jibel> pecisk, sorry, I cannot reproduce the proxy problem
<pecisk> jibel: it gives you correct http_proxy value?
<jibel> pecisk, set a proxy with user/pass. Open a new terminal and echo $http_proxy -> http://user2:p%40ssword@localhost:3128/
<pecisk> strange
<pecisk> doesn't work for me
<jibel> pecisk, file a report, I'll have a look. ubuntu-bug gnome-control-center. Thanks.
<tseliot> PlyBuk, err... Keybuk, how are things going with plymouth?
<Keybuk> tseliot: stalled for the moment
<tseliot> Keybuk: can I have access to that patch/commit of yours which makes sure that deactivate and quit work correctly (just for testing locally), please?
<Keybuk> tseliot: why not just pull from the branch and build that?
<tseliot> Keybuk: well, what kind of problems are you facing (so that I can be prepared)?
<Keybuk> oh, just irritating messages on boot ;-)
<tseliot> I think I can deal with that
<tseliot> ;)
<Keybuk> it may not show a splash screen also
<tseliot> now you're making it too easy for me to blame it on your work if my patch messes things up
<tseliot> :-D
<mvo> jibel: could you please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/apt/+bug/130289/comments/4 ?
<ubottu> Ubuntu bug 130289 in apt "Encode any ":", "@" or "/" within the user and password field in proxy settings." [Medium,In progress]
<mvo> jibel: unless I'm missing something it should help
<mvo> jibel: actually I guess QuoteString() should always quote % to ensure its reversible on DeQuoteString()
<jibel> mvo, log attached to the bug report.
<cjwatson> lemsx1: thanks, this looks pretty widespread, I've cranked up the priority
<lemsx1> cjwatson: thnx
<mvo> jibel: thanks! with or without the patch
<mvo> ?
<lemsx1> cjwatson: sorry. i didn't see the text about the Lucid project... I'll follow that next time ;-)
<lemsx1> cjwatson: wtf is Lucid editor... lol good one
<lemsx1> cjwatson: I have another system that I ran into issues and I was able to fix the problem. it's an OQO (mobile device). I needed to blacklist the viafb driver. Is this something that I should file as a bug too? (hardware specific issue)
<cjwatson> lemsx1: err, I'm not a kernel hacker so I don't know
<cjwatson> lemsx1: I imagine you should file a bug if you're having problems
<zul> pitti: when you get a chance can you review 522509 please? thanks
<lemsx1> cjwatson: against what package? or just Lucid in general?
<cjwatson> lemsx1: the linux package in Ubuntu I assume, since it sounds like a kernel bug
<sebner> bdrung: I think java is b0rken and that breaks eclipse: http://pastebin.com/9D3VEsXD  (Just started a new project, wrote 1 line of code, pressed ENTER, crash)
<bdrung> sebner: result of "xulrunner --gre-version"?
<sebner> bdrung: 1.9.1.8 , I read the bug report but it doesn't crash at startup, I can create a new project without problems, it crashes when writing code
<bdrung> sebner: it crash only on startup if the welcome page should be loaded, but it's the same issue
<sebner> bdrung: aye, I'm seeing you are already working on it?! It's not urgent so I can wait some hours/days for the update. Else I would just have to use new xulrunner right?
<bdrung> sebner: launch eclipse with "eclipse -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.9.2"
<sebner> bdrung: works :)
<bdrung> sebner: k, i was right :)
<sebner> bdrung: :) I guess you just need to change xulrunner-dev (>= 1.9.1.3-2) ?
<bdrung> sebner: nope. it was build against xulrunner-1.9.2.
<sebner> bdrung: ohohoho
<sebner> bdrung: so you have to hardcode xulrunner 1.9.2 in Depends?
<pitti> seb128, kees: mind eyeballing http://bazaar.launchpad.net/%7Eubuntu-desktop/gnome-keyring/ubuntu/annotate/head%3A/debian/patches/04_clean_session_keyring.patch ?
<bdrung> sebner: nope - we B-D on xulrunner-dev, which pulls xulrunner-1.9.2 in lucid.
<bdrung> it's dynamically
<sebner> bdrung: oh, Ic. Sorry for the noise, I'm not really up to date what uses and pulls in what :D
<pitti> seb128, kees: I don't have a session.keyring, so I created a fake one, and tested in various situations (within session so far; building package and doing end-to-end testing with a full reboot now)
<bdrung> sebner: eclipse's xulrunner detection is totally fucked up. so we have to set it in our wrapper script.
<sebner> bdrung: heh, wondering, how xulrunner can break eclipse when writing java code O_o
<seb128> pitti, ok, will have a look in a few minutes when I'm done with what I'm doing now
<pitti> seb128: cheers (not that urgent, I'll do more tests and then do other stuff)
<bdrung> sebner: type "System." and a dropdown list will open and a "tooltip" (rendered with xulrunner) will explain its details
<sebner> bdrung: ah. now I understand, thx :)
<sebner> bdrung: maybe they should switch to webkit :P
<Keybuk> slangasek: so, I'm thinking, let's ship lucid without a splash screen?  what do you think :p
<bdrung> sebner: i doubt that this will help
<sebner> heh
<tseliot> Keybuk: +1 :-P
<bdrung> sebner: except webkit will be rewritten in java :P
<sebner> bdrung: urgh, java ...  xulrunner != java too
<directhex> bdrung, http://twitter.com/migueldeicaza/status/10930739689
<slangasek> Keybuk: well, at least I'll be in London for the release sprint already and will be able to attend your funeral :)
<sebner> directhex: hÃ¤Ã¤? webkit-sharp!?!
<bdrung> webkit-sharp and then jwebkit :D Eclipse 6 with jwebkit
<Keybuk> slangasek: I think that, ultimately, as Release Manager, all failures are your fault
<Keybuk> Captain is responsible for the actions of his Crew, and all that :p
<sebner> Keybuk: may the grass be green above and the worms not that hungry beneath :)
<jcastro> Keybuk: needs to go down with the ship also iirc
<sebner> The Captain goes down with the ship!
<sebner> Vice-captain (Keybuk) too of course :P
<slangasek> Keybuk: I don't think I'm cut out for the navy :P
<Keybuk> I'm just the cabin boy
<bdrung> is it a release goal to let the ship go down in ten seconds? ;)
<cjwatson> Keybuk: roger that
<Keybuk> cjwatson: I'm having a dpkg-source failure
<Keybuk> and it keeps whining to me about v3
<Keybuk> dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1)
<Keybuk> dpkg-source: unrepresentable changes to source
<Keybuk> etc.
<hyperair> Keybuk: it means you've modified a binary file.
<Keybuk> hyperair: how does v3 help here?
<hyperair> Keybuk: 1.0 only supports textual changes
<hyperair> Keybuk: v3 consists of multiple tarballs.
<hyperair> debian.tar.gz, orig.tar.gz
<hyperair> v1 consists of diff.gz, orig.tar.gz
<hyperair> the diff.gz can't contain binary changes
<hyperair> so you'll have to uuencode whatever it is you're doing
<Keybuk> right
<hyperair> or use 3.0
<Keybuk> how can debian.tar.gz contain binary changes
<Keybuk> is it just unpacked over the top?
<hyperair> i think so
<hyperair> not sure
<Laney> it can't
<hyperair> oh it can't?
<Laney> it only touches stuff in debian/
<hyperair> well at least debian/ can contain a binary file
<Laney> you can have binaries in there though
<hyperair> unlike in v1
<Keybuk>  Note that the debian tarâ
<Keybuk>        ball must contain a debian sub-directory but it can also contain binary
<Keybuk>        files outside of that directory (see --include-binaries option).
<Laney> oh, cool
<Keybuk> Laney: dpkg-source(1) disagrees with you
<Keybuk> ok...
<Keybuk> so how do I make one of these source packages?
<cjwatson> Keybuk: debian/source/include-binaries is your friend
<hyperair> echo "3.0 (quilt)" > debian/source/format
<hyperair> and dpkg-source handles the rest
<hyperair> oh you'll have to disconnect your patch system from rules
<hyperair> and control
<hyperair> dpkg-source will take care of that
 * cjwatson digs up an example
<hyperair> and only uses quilt
<Keybuk> I don't have a patch system
<cr3> is there an equivalent to lshal -m (for monitor) since the halsectomy?
<Keybuk> (there is no debian/patches)
<Keybuk> cr3: udevadm monitor
<cjwatson> you don't need one
<Laney> looks like you just put the filename of the binary in debian/source/include-binaries
<cr3> Keybuk: thanks
<cjwatson> so, for openssh
<cjwatson> $ cat debian/source/format
<cjwatson> 3.0 (quilt)
<cjwatson> $ cat debian/source/include-binaries
<cjwatson> debian/ssh-askpass-gnome.png
<cjwatson> that's only in bzr, I haven't uploaded that yet
<Keybuk> can I put wildcards in there? :p
<cjwatson> browser-history has one too
<hyperair> Keybuk: try it and see =p
<Keybuk> :D
<cjwatson> I don't think so
<cjwatson> you can build with --include-binaries once, and it'll dump them all in there
<cjwatson> you can probably even put that in debian/source/options
<Keybuk> any idea how to make pristine-tar not convert the bz2 to tar.gz ?
<cjwatson> if you're completely confident that your clean rule works :)
<cr3> I used to be able to troubleshoot brightness issues by echoing 50 (for example) into /proc/acpi/video/.../brightness, but one netbook on which the brightness keys don't work returns: write error: invalid argument
<Keybuk> that's probably why the brightness keys don't work, then
<cr3> Keybuk: I'll try to rebout with noacpi
<jibel> mvo, with the patch
<\sh> UDS-M approved by company , means we are coming :)
<cody-somerville> w00t
<\sh> well...one week sponsored by our employer
<kees> pitti: reading it now...
<kees> pitti: looks good to me.
<pitti> kees: thanks
<tseliot> pitti: is there a bug report about fglrx and jockey already?
<pitti> tseliot: for what?
<tseliot> pitti: to be able to install it again
<pitti> tseliot: ah; I'm not aware of one
<Keybuk> do we care about fglrx anymore?
<tseliot> Keybuk: yes, in some cases we do
<tseliot> pitti: ok, I'll look for it and file a new one if necessary (and assign it to me) just to keep track of things
<pitti> tseliot: thanks
<tseliot> np
<kees> pitti: re bug 546436, it's esata (I commented on the bug too)
<ubottu> Launchpad bug 546436 in udisks "Does not detect LUKS storage device as hotpluggable" [Medium,New] https://launchpad.net/bugs/546436
<pitti> kees: ah; itz kernel bug then; AFAIR I saw a similar one, I'll dupe it
<kees> pitti: how is it a kernel bug?  I didn't think it could distinguish between "internal" and "external" for esata, so it was simply the sudden appearance that should trigger the mount?
<primes2h> tseliot: you mean this?  bu 494699
<primes2h> bug 494699
<ubottu> Launchpad bug 494699 in fglrx-installer "Does not support current Lucid kernel (2.6.32) or xserver (1.7)" [Critical,Fix released] https://launchpad.net/bugs/494699
<primes2h> tseliot: ups, sorry
<primes2h> tseliot: misunderstand
<pitti> ah, that was bug 153768
<ubottu> Launchpad bug 153768 in hal "External SATA (eSATA) removable disk detected as system-internal" [Unknown,Confirmed] https://launchpad.net/bugs/153768
<tseliot> primes2h: I guess this one would be more like it: bug #496225
<ubottu> Launchpad bug 496225 in jockey "Jockey cannot install fglrx driver" [Undecided,Confirmed] https://launchpad.net/bugs/496225
<pitti> kees: well, what is "sudden"?
<primes2h> tseliot: sure ;-)
<pitti> kees: did that ever work? the original bug (153768) is ancient
<pitti> kees: so, I don't think we'll ever be able to automount esata drives which are already plugged in during boot, but I think we can do something in udisks for stuff that got plugged in at runtime
<psusi> does it matter when it is detected?  either way it should show on the places menu shouldn't it?
<tseliot> Keybuk: any ideas on this? bug #532436
<ubottu> Launchpad bug 532436 in nvidia-graphics-drivers "nvidia driver sometime does not load at boot" [Undecided,New] https://launchpad.net/bugs/532436
<tseliot> or can I assign it to plymouth?
<kees> pitti: yes, worked in jaunty and karmic fine
<kees> pitti: right, I'm plugging it in at run time
<pitti> kees: I'd really be interested in a devkit-disks --monitor-detail and udevadm monitor -e --udev logs from karmic when you plug in an esata drive
<pitti> I don't see how this should ever have worked, TBH, but maybe there was something funky
<Keybuk> tseliot: sounds like a kernel issue
<Keybuk> "driver does not load" => linux
<tseliot> Keybuk: driver loads if plymouth is uninstalled => plymouth, no?
<Keybuk> no
<Keybuk> still linux
<tseliot> heh
<tseliot> Keybuk: can you comment on that in the bug report, please?
<Keybuk> if it's the glx driver, it's in the right place
<kees> pitti: hm, will that work off a karmic liveCD?
<pitti> kees: yes, it should
<tseliot> Keybuk: ok, thanks
<kees> pitti: okay, I'll give it a shot.
<pitti> kees: cheers
<Keybuk> all he's done by uninstalling plymouth is change a race
<Keybuk> what he's describing is "driver doesn't load sometimes, but does if I restart sometimes, add sleep, etc."
<Keybuk> and
<Keybuk> more to the point
<Keybuk> The problem is still happening at random, but not at frequently since I uninstalled plymouth.
<Keybuk> DkmsStatus:
<Keybuk>  nvidia-current, 195.36.03, 2.6.32-15-generic, i686: installed
<Keybuk>  nvidia-173, 173.14.22, 2.6.32-15-generic, i686: installed
<Keybuk> he should stop hating freedom and use nouveau <g>
 * psusi has been very pleased with the mesa drivers on his radeon these days
<tseliot> Keybuk: oh, I misread what he said. You're definitely right
 * tseliot -> off for the night
<psusi> Keybuk: my initial tests using e2defrag to pack the ureadahead file list at the start of the disk showed a few seconds shaved off the boot time and a moderate increase in peak disk throughput under karmic... need to test on lucid next since karmic appeared to still spend a lot of time doing things other than read the disk during boot
<pitti> slangasek, cjwatson, Keybuk: so, I completely read bug 445852 now, including the upstream linux/atasmart bugs; I have some things I'd like to try now, but given how much this wreaks havoc, what would you think about disabling dk-disks-probe-ata-smart in the udev rules for now in a karmic update? (then people can turn it on again if they want, but it'd be on the safe side); we only use it for
<pitti> monitoring SMART status and failures (which would then stop working, of course)
<ubottu> Launchpad bug 445852 in libatasmart "devkit-disks-probe-ata-smart causes HSM Violations on SSD, and potential hardware death" [Critical,In progress] https://launchpad.net/bugs/445852
<pitti> but at least we can investigate and test solutions in lucid a bit more thoroughly
<bdrung> where is the best place for asking question about developing a C library?
<slangasek> pitti: that sounds suitable for SRU to me
<pitti> we could then consider re-enabling it in karmic later on, once we have a suitable fix in libatasmart
<Keybuk> slangasek: btw, you still haven't sent your plymouth enter patch upstream
<slangasek> Keybuk: right - what's the recommended method of forwarding it to upstream?
<Keybuk> slangasek: git format-patch usually
<slangasek> oh hey, life on #plymouth, that's different
<slangasek> Keybuk: and send it where?
<Keybuk> plymouth@lists.freedesktop.org
<slangasek> thanks, that was the bit I was missing :)
<slangasek> ok, will send that off today/tomorrow
<Keybuk> I have a couple of bug fixes to send too
 * Keybuk wonders what the right term for a double-brown-paper-bag is
<slangasek> "double-bagging" doesn't quite encompass it
<Keybuk> hey, if it keeps you safe ...
<pitti> slangasek: uploaded to karmic-proposed queue; do you have a minute to review? (it's just commenting out the udev rule, should be fairly safe)
<slangasek> pitti: ok, checking
<slangasek> pitti: should there be a task on this bug against devicekit-disks for tracking?
<pitti> slangasek: there is
<pitti> slangasek: but for karmic only
<pitti> slangasek: for lucid I'd rather fix it in libatasmart, and dk-disks doesn't exist in lucid
<slangasek> pitti: oh, so there is; having trouble seeing it through all those declines, heh
<pitti> yeah, smart probing was new in karmic, so I declined all the ealier requests
<slangasek> pitti: ok, accepted
<pitti> slangasek: thanks
<slangasek> yes, it would be nice if people wouldn't randomly nominate bugs for series where it didn't exist
<kees> cjwatson: heh, we collided on bug 547016.
<ubottu> Launchpad bug 547016 in gcc-4.4 "gcc optimization problem related to varargs" [Undecided,Triaged] https://launchpad.net/bugs/547016
<Keba1> hi there
<Keba1> how many bug jams have been partipicated (including the one starting tomorrow)?
<_lemsx1_> launchpad appears to be having problems? I can't report a bug
<ScottK> _lemsx1_: #launchpad is the place to complain about that.
<_lemsx1_> should I post error IDs and stuff like that here or this is not the right place to talk about launchpad :-)
<_lemsx1_> ScottK: ah, thanks
<kees> pitti: hrm, karmic didn't automount either.  I wonder if I'm remembering this from my laptop where the drive is USB.  trying on jaunty now...
<pitti> kees: jaunty had hal, and that didn't see them as hotpluggable either
<pitti> the bug was originally filed against hal
<kees> hmpf
<kees> pitti: yeah, jaunty doesn't even see it appear.
<pitti> kees: so it's evolution in the sense that karmic sees it but requires a password, lucid sees it and requires no password
<kees> well, it does require the password -- I just still had the session.keyring on disk.  ;)
<pitti> kees: well, the encryption password, yes
<kees> so, I simply misremembered since this drive has both eSATA and USB interfaces
<pitti> kees: I mean the policykit authorization
<pitti> kees: I'll talk to davidz if he agrees on considering such devices non-system internal if they appeared much later than the system boot
<kees> oh, okay.  well, lucid is clearly better than before since the drive is there, and if I click on it, it prompts for the encryption password.  it just doesn't _auto_ mount it.
<kees> which I can live with.
 * psusi wonders why gparted stopped seeing his dmraid disks in lucid
 * ccheney thinks apt-get should be a bit more verbose on downloading new multi tar sources
<ccheney> it currently says stuff like the following:
<ccheney> Get:2 http://approx/ubuntu/ lucid/main openoffice.org 1:3.2.0-4ubuntu1 (tar) [14.6MB]
<ccheney> Get:3 http://approx/ubuntu/ lucid/main openoffice.org 1:3.2.0-4ubuntu1 (tar) [13.2MB]
<YokoZar> Is there another mesa update coming soon?  It's been a while and there's a "fix committed" but I'm waiting on
<crimsun> NCommander: please provide the necessary amixer output for bug 451635 to be fixed
<ubottu> Launchpad bug 451635 in alsa-utils "alsamixer defaults need adjustment on dove boards" [High,Confirmed] https://launchpad.net/bugs/451635
<crimsun> I'm currently blocked on someone with access to the hardware to actually provide the info in the bug report...
<NCommander> crimsun: ah, I got it right here
<iscape> hi there, tangogps and probably some other apps broke due to the upgrade of gpsd to 2.92. anything i can do to fix this?
<iscape> i am the dev of tangogps
<NCommander> crimsun: attached, does that help?
<NCommander> (oh, amixer, I might have given you the wrong file)
<iscape> debian has a fix already in, but it needs to propagate
<ScottK> iscape: If you can file bug(s) with patch(es) to fix the problem, we can get them sponsored into Ubuntu.
<ScottK> iscape: Or if just syncing an update from Debian makes more sense, that's good to know too.
<crimsun> NCommander: yeah, that asoundrc snippet is not useful, unfortunately. Specifically what will help is your specific mixer settings for all devices.
<iscape> ScottK: just syncing
<NCommander> crimsun: ugh, I might need to do a clean reinstall, I *really* mucked around with my setup. How can I dump amixer settings?
<iscape> I'll file a bug against tangogps then. do i need to put some keyword in to trigger syncing?
<crimsun> NCommander: also, that user-specific asoundrc bypasses PA completely - the implication is that any verification you've done won't apply at all to PA, which I presume is part of the equation if PA is being used
<crimsun> NCommander: amixer > txt
<ScottK> iscape: You needs to say it needs syncing and then subsrcribe the ubuntu-sponsors team to the bug for review.
<NCommander> crimsun: I removed pulseaudio to get sound working
<crimsun> NCommander: booting from a live image and dumping amixer after you've made whatever necessary changes will help, too
<NCommander> crimsun: I've not been able ot get sound working short of removing pulse :-/
<crimsun> NCommander: err, there are two separate parts, though the bug report doesn't make that clear
<crimsun> that bug seems titled to deal only with alsa-utils portion
<NCommander> crimsun: ok, what do you need specifically, I *really* want this fixed :-)
<crimsun> NCommander: what I've requested above regarding amixer
<NCommander> crimsun: I may need some helpin trying to get this to work, I am not had any luck with ALSA configurations in the past :-/
<crimsun> NCommander: which part specifically? 'cat /proc/asound/cards' should show the specific card, which you can then use with 'amixer' or 'amixer -Dhw:X' (where X is denoted in brackets from /proc/asound/cards)
<NCommander> crimsun: does that change the default? The problem is that audio tries to go out something that doesn't appear to be pinned out on our SoC
<crimsun> NCommander: amixer by itself (with no addition parameters beyond -Dfoo) does not change the default
<NCommander> crimsun: right, the problem her eis I just need the default changed (and MAYBE HW switch, not sure yet)
<crimsun> NCommander: are you implying that hw:0,0 is not correct but that hw:0,2 is?
<NCommander> crimsun: yes, I am
<crimsun> ugh, that's a completely different bug :(
<NCommander> crimsun: welcome to the world of ARM sound
<crimsun> ok, I've opened an alsa-lib task for the necessary addition
<NCommander> crimsun: your santiy may be left at the door
<GrueMaster> NCommander: crimsun:  Thought I'd pop over and see what trouble I can cause with dove as well.
<NCommander> crimsun: there are two different sound out devices on this board that hang off DoveDB. Analog Out, and Headphone Out
<crimsun> NCommander: so, in short, for your particular Dove board (and it isn't Y0, I presume?), the control has nothing to do with ...
<NCommander> crimsun: pulse sees these, but I can't get either to work through pavucontrol
<NCommander> crimsun: this effects Y0->X0
<NCommander> We only care about X0 however
<crimsun> NCommander: can you please attach your amixer dump?
<NCommander> crimsun: stand by, I'm rebooting off a clean livefs so you can see how it is "out of the box"
<crimsun> NCommander: thanks
<GrueMaster> NCommander: You are not entirely accurate with your HW description.  There are two devices, DoveDB and mv_i2s1.
<NCommander> asac__: *sigh*, looks like something we broke
<NCommander> asac__: works properly with pre-compiled Marvell kernel
<GrueMaster> The DoveDB has 5.1 on the RCA jacks, and a separate HP & Mic jack.
<NCommander> er, EWRONGCHANNEL
<asac> NCommander: bcc_test works?
<asac> wow
<NCommander> asac: no, the dmesg isn't crack
<asac> ah
<asac> try bmm_test
<asac> not sure if i put that in the -dev package
<asac> otherwise just spin locally and run
<asac> oh
<crimsun> GrueMaster: does X0 still need 'Line HP Swap' unmuted?
<GrueMaster> yes, for the HP jack to work.
<GrueMaster> It is a simple toggle.  No volume control.
<crimsun> ok, that change is queued already in the linked bzr branch. I'm waiting to see if anything else needs to be set for alsa-utils. Now, does the default device also need to be set to hw:0,2?
<crimsun> for reference, that's the conversation above with NCommander and in https://bugs.edge.launchpad.net/ubuntu/+source/alsa-lib/+bug/451635/comments/12
<GrueMaster> Not sure.  Where would I set that? (note - it's been a while since I worked on alsa).
<ubottu> Ubuntu bug 451635 in alsa-utils "alsamixer defaults need adjustment on dove boards" [High,Confirmed]
<crimsun> GrueMaster: NCommander mentioned that he had to create an ~/.asoundrc with the contents in https://bugs.edge.launchpad.net/ubuntu/+source/alsa-lib/+bug/451635/comments/12
<iscape> ScottK: bug filed - https://bugs.launchpad.net/ubuntu/+source/tangogps/+bug/547228
<ubottu> Ubuntu bug 547228 in tangogps "need syncing for compatibility with gpsd 2.92" [Undecided,Confirmed]
<GrueMaster> I'm looking at it.
<NCommander> crimsun: booting up clean now
<GrueMaster> crimsun: Here's the amixer output.  http://pastebin.ubuntu.com/401357/
<crimsun> GrueMaster: right, so that's 1) without ~/.asoundrc or /etc/asound.conf, and 2) muted, correct?
<crimsun> (at least the latter is implied by 'Line HP Swap' being muted)
<GrueMaster> correct an all accounts.
<crimsun> GrueMaster: great. And unmuting 'Line HP Swap' results in audible sound through the hp jack next to the serial port, correct?
<GrueMaster> I am currently getting audio through the rear RCA jacks (which would be the normal speaker out on an Intel board).
<GrueMaster> yes
<crimsun> GrueMaster: all right, so which is considered the "default" desired output jack?
<GrueMaster> It also mutes the rear "front speakers" ports.
<NCommander> crimsun: http://paste.ubuntu.com/401359
<GrueMaster> That I don't know.  I guess the hp since most people in the group don't have rca to 3.5mm hp converters like I do.
<crimsun> asac: any guidance on ^^ ?
<NCommander> GrueMaster: I can test here, I have a TV at Lex I can plug the dove in
<GrueMaster> NCommander: I can test all plugs.
<GrueMaster> (and have been since Y0).
<NCommander> crimsun: so does that help at all?
<crimsun> plars: ping, which of the rear rca and hp jacks should be considered 'default'?
<NCommander> crimsun: there's only one HP jack
<crimsun> NCommander: yes, it corroborates GrueMaster's earlier statement here and in the other bug report
<ccheney> grr checking extracted OOo into bzr takes forever :-\
<plars> crimsun: right, only one hp jack, not sure on the RCA, I don't have proper cables to check those  but I know GrueMaster has looked at it before
<crimsun> plars: ok, so the necessary change for that on the alsa task is already queued, and I'll upload that momentarily. It doesn't look to need an alsa-lib task, then.
<GrueMaster> crimsun: The board layout is "similar" to a standard 3stack, except instead of 3 mini plugs in the back, there are 3 pairs of RCA jacks for Front, Surround, and Center/LFE
<crimsun> GrueMaster: ah
<asac> crimsun: so you got all info you needed?
<asac> doko_: does icetea need to link against libxul.so?
<crimsun> asac: presuming that the hp jack is the desired default, yes
<asac> doko_: maybe we should try to use mozilla-plugin.pc now that they redid stuff for 3.6?
<asac> crimsun: yeah. i think thats a reasonable choice. thanks for your help.
<NCommander> crimsun: if you have a patch today, I'd be glad to test it
<crimsun> NCommander: I just uploaded alsa-utils 1.0.22-0ubuntu4 for that
<crimsun> NCommander: note that it's effected on a fresh install/live image boot. Otherwise you'll need to nuke /var/lib/alsa/asound.state first
<NCommander> crimsun: WIN
<GrueMaster> crimsun: what change to asound.state was made?
<GrueMaster> Just for quick sanity testing.
<iscape> ScottK: thanks
<ScottK> iscape: You're welcome.  Thanks for letting us know.
<iscape> ScottK: it was an ubuntu user who notified me :)
<crimsun> GrueMaster: I don't have a machine to generate one, but the value for that switch should be true instead of false
<GrueMaster> got it.  That's what I thought.
<pitti> kees: wrt. bug 542372, are you okay with python3.1 in main? (it doesn't seem very security prone to me)
<ubottu> Launchpad bug 542372 in python3.1 "MIR for basic python3 stack" [Undecided,Fix committed] https://launchpad.net/bugs/542372
<kees> pitti: bleh.  why so late?  what needs it?
<kees> pitti: python gets a fair share of updates, so having lots of copies gets unhappy.
<robert_ancell> mdke, do you know about the state of gnome-user-docs?  Should it be updated to 2.29.2 or does it need patching for Ubuntu?
<nixternal> is jockey broken for everyone?
<psusi> Keybuk,  in bug #460906 it seems that you and Kees Cook are saying that the real fs should have the link so won't change, but they don't... I made a snapshot of my root and when I rebooted, was running off the snapshot instead of the original and this is not supposed to happen
<ubottu> Launchpad bug 460906 in lvm2 "disk/by-uuid/foo symlink points to snapshot rather than the origin" [Undecided,Confirmed] https://launchpad.net/bugs/460906
<doko_> asac: $ ldd /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so |grep libx.*found
<doko_> 	libxul.so => not found
<doko_> 	libxpcom.so => not found
<asac__> doko_: you tried initially to build with just mozilla-plugin, right?
<doko_> asac: I think so. it's in the configure.ac (or acinclude.ac)
<psusi> soren, actually seems you said you were going to fix this... but still is doing the wrong thing in lucid
<snow_ru> hi
<snow_ru> How can the developer  add his program to ubuntu repository so that other people can use it ?
<micahg> snow_ru: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<snow_ru> thanks
<snow_ru> micahg, should all packages in MAIN be compatible with 64Bit system ?
<RAOF> Almost certainly, yes.
<nixternal> superm1: b43 or sta for the mini 10v?
<micahg> snow_ru: doesn't work like that...main means supported free software
<RAOF> Failing to build on amd64, or failing to work on amd64 is generally indicative of stupid code :)
<snow_ru> it implies that the package may not work for 64 bit system ;)
<snow_ru> RAOF, built and worked are two different things ;)
#ubuntu-devel 2010-03-26
<cjwatson> snow_ru: problems with 64-bit environments are not unheard of, but are rare in Ubuntu in general these days, and rarer still in main
<snow_ru> cjwatson, yes, as soon as programmers are aware of the 32 and 64
<xorl> snow_ru: they are for the most part, people just get lazy.
<xorl> snow_ru: The "new" still scares them even though it's not new tech by any means.
<snow_ru> "new"?
<xorl> I've been running 64bit since before most supported it.
<cjwatson> snow_ru: all one has to do is abide by standards - you generally don't need to special-case them, and usually these days compiler warnings pick up the most common bugs
<xorl> snow_ru: yeah, people fear change.
<xorl> snow_ru: mostly large corporations.
<snow_ru> xorl, many guys still assume they will run on 32
<cjwatson> anyway, amd64 (or x86-64, whatever you want to call it) has been a first-class supported architecture on Ubuntu since the project began, so "new" is not particularly relevant.
<xorl> snow_ru: exactly.
<snow_ru> and do crazy tricks
<xorl> I program myself and have to modify all kinds of code.
<xorl> working with apps that only support 32bit memory stacks is hell.
<snow_ru> xorl, with the assumption of 32, they do very "clever" tricks and it's very hard to figure out
<xorl> snow_ru: Oh I find em most of the time.
<cjwatson> it doesn't seem like this conversation is directly about Ubuntu - please take general discussion of how programmers suck elsewhere. :-)
<xorl> Not very hard to tell crappy math.
<xorl> cjwatson: haha, sure deal :)
<snow_ru> any statistics on the languages used in the main ?
<cjwatson> not that I know of
<cjwatson> vast majority will almost certainly be one of C, C++, Perl, Python, with a smattering of various others
 * snow_ru wants to apply for ubuntu dev position 
<davidvasta> anyone here
<davidvasta> ???
<psusi> wow... I found an old copy of dd I had modified to use aio and it does 242 MB/s reading my ssd compared to 230 from stock dd with same settings
<psusi> iirc, the manufacturer specs only say it does 230
<psusi> ohh dear.. make that 247 when I turn ncq back on
<slangasek> vvsz-
<superm1> nixternal, the fact that you have to ask implies a bug that they aren't voiced correctly to you as the user in jockey
<nixternal> well it says sta is preferred
<nixternal> the non-free one
<nixternal> it doesn't support scanning which sucks
<superm1> sure it supports scanning
<superm1> iwlist scan?
<ccheney> what is the syntax to do in place sed replacement?
<ccheney> doh i just need to read better
<ccheney> -i does it
<slangasek> Riddell, stgraber: any progress on the branding question?
<pitti> Good morning
<pitti> kees: python> mind to comment on bug 542372 then?
<ubottu> Launchpad bug 542372 in python3.1 "MIR for basic python3 stack" [Undecided,Fix committed] https://launchpad.net/bugs/542372
<dholbach> good morning
<maxb> If I had a bug assigned to me + "In Progress" whilst working on it, am I supposed to unassign myself and put it to another status when I request sponsorship?
<slangasek> maxb: the sponsorship queue isn't based on bug status, so I don't think you need to
<Jeeves_> Hi all
<Jeeves_> If I have a general complaint about Canonical software/packages, where should I drop the complaint?
<RAOF> Jeeves_: Bug reports go on Launchpad of course; other comments may find a more appropriate venue, depending on what the actual package is.
<Jeeves_> RAOF: Well, it's more a observation about Canonical packages. So I guess it would be more efficient to drop the complaint than to file bugs against all packages. Don't you agree?
<RAOF> What packages are you talking actually about?
<Jeeves_> pyhton-software-properties, for example
<Jeeves_> Packages in the main archive, without manpages.
<ogra> Jeeves_, thats definately a bug, file it
<Jeeves_> ogra: I have
<mvo> Jeeves_: add-apt-repository lacks a man-page. that is correct and a bug. help is much appreciated in fixing it
<ogra> great
<Jeeves_> mvo: I would expect the developer (you?) to be able to write a manpage in about five seconds. Instead of releasing it without a manpage and sat 'go ahead, fix it. You've got the source'.
<Jeeves_> I would expect Canonical to have a quality standard, which says 'We dont release software about which Lintian complains'
<mvo> Jeeves_: its a valid complain, but its not always that easy, there are a lot of things to do and a lot of bugs to fix.
<Jeeves_> mvo: By creating new bugs, you don't make your work much easier, do you?
<mvo> Jeeves_: sorry, I have no interesst in continue a conversation like this. please note that I understand that its a valid complain and I don't like it either, but its not that simple. I don't think its unfair to call in this cases for help from the community (and I'm certain someone will step up and help wit hthat task)
<Jeeves_> Ok, so back to my original question. Where can I drop complaints about this, other than at the developers which are to busy?
 * pitti suggests /dev/null
<pitti> complaints are just about the worst possible way to motivate people
<Jeeves_> pitti: Ok, let me rephrase. Whom should I talk to, to motivate Canonical to uphold a quality standard that gives them credit and prevents complaints, and useless bugreports?
<pitti> Jeeves_: there are certainly much more pressing bugs which need attention first
<pitti> so by putting more resources into things like writing manpages, we had to drop resources from fixing really nasty things
 * pitti points to bug 445852
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/445852)
<pitti> Jeeves_: but in general, ubuntu-devel-discuss@ is not a bad place to start discussions about the project's direction and workflow
<Chipzz> Jeeves_: wow. that's some astouding arrogance there
<Chipzz> may I suggest you take it elsewhere?
<Jeeves_> Chipzz: I don't recall being arrogant. Explain?
<Jeeves_> pitti: That's a nasty bug indeed.
<pitti> For starters, you claim that workign on missing manpages should be the #1 priority, without apparently knowing what the project is working on
<pitti> and overgeneralize this as if we wouldn't care about quality
<Chipzz> "09:02 < Jeeves_> mvo: I would expect the developer (you?) to be able to write a manpage in about five seconds."
<pitti> that, too
<Chipzz> Jeeves_: and no offence, but maybe it's more important to have something FUNCTIONAL than to have something perfect to the tiniest detail
<Chipzz> and yes, I call supplying a manpage a MINOR detail
<Jeeves_> Obviously, functionality is more important than documentation. What would you document if it doesn't work?
<Chipzz> Jeeves_: you obviously did not consider the fact that canonical has a limited amount of manpower, and a certain amount of goals to reach.
<Jeeves_> pitti: I never stated manpages are a #1 priority. I did say that I expect a manpage for professionally written sofware.
<Jeeves_> Chipzz: Ofcourse I did.
<Chipzz> you obviously did not
<Jeeves_> Chipzz: Are there other things I did or did not do without knowing about it myself?
<Chipzz> I suspect there are :P
<Chipzz> but
<Chipzz> obvious troll is obvious
<Jeeves_> pitti: I also did not say that canonical doesn't care about quality. The existance of LTS releases proof the opposite, so why would I say that?
<Chipzz> one for the /ignore list
<Chipzz> Jeeves_: lol. I think you did
<Jeeves_> Chipzz: Where, how?
<Chipzz> at least the tone of what you said and how you said it implied hat
<Chipzz> *that
<pitti> Jeeves_: "motivate Canonical to uphold a quality standard that gives them credit and prevents complaints, and useless bugreports"
<pitti> we do what we can, and we know Ubuntu isn't perfect. we wouldn't have 50.000 open bugs otherwise
<Jeeves_> pitti: That's because you did not approve complaints because complaints are unmotivating.
<pitti> so we have to prioritize :)
<Jeeves_> pitti: I know it's not perfect, but it is one of the better Linux distributions. And I'm happy with it.
<pitti> that's great to hear
<Jeeves_> I'm just trying to make a point, that if you write a manpage in a few minutes, it save you a bugreport, it saves you replying to that bugreport etc etc etc
<Jeeves_> And, it makes your users even happier
<pitti> I agree
<Chipzz> Jeeves_: writing a manpage doesn't take 2 minutes
<Chipzz> it takes a lot longer than that
<pitti> but still, writing a good manpage is not a "5 s" job, it's more like 30 minutes..
<Tm_T> Jeeves_: I'm happy to receive manpage contributions from you ;)
<Jeeves_> Chipzz: That kinda depends on the piece of software you're documenting, don't you think?
<pitti> and more people are able to write manpages, that's why FOSS projects use bug trackers, so that everyone can contribute
<Chipzz> pitti: I would estimate that writing the manpage content would take that much. but obviously a manpage also needs layout elements (groff or whatever is used markup)
<Chipzz> Jeeves_: I would consider your complaint more valid if canonical were to write closed source software. but most of it is open source, so you can read the source...
<Jeeves_> Chipzz: But it's allready released, so too late. And obviously everyone can write a manpage. But by then it allready costs more time and bugs than necessary.
<cjwatson> Chipzz: honestly, I don't think your aggressive defensiveness is helping the tone of this conversation.
<cjwatson> tone it down, please.
<cjwatson> Ubuntu developers can look after themselves and don't need others to defend them from criticism
<Chipzz> cjwatson: ok, noted. although I think that Jeeves_' attitude is inappropriate and was reacting to that
<Chipzz> cjwatson: I appreciate the work the canonical employees do, which is why I'm "defending them from criticism"
<cjwatson> I think Jeeves_ should just file bugs where appropriate; Canonical doesn't have separate quality standards from Ubuntu for Ubuntu development, so it doesn't make sense to make this about Canonical; there is plenty of Ubuntu software maintained by Canonical employees that does have man pages, though doubtless it has different problems instead, nobody's perfect
<Jeeves_> Chipzz: Who's says I don't appreciate them? If I would care about it, I wouldn't be critical.
<cjwatson> Chipzz: I can't speak for everyone, but I know I would prefer it if you were a little less vigorous. :-)
<Chipzz> Jeeves_: you can be critical in a constructive way. but you attitude is hardly constructive...
<Chipzz> *your
<Tm_T> like I hear often, "complaints are welcome, especially wrapped with patch"
<Jeeves_> Tm_T: :)
<hyperair> mvo: i'm curious. what are these more complex issues that prevent add-apt-repository from sprouting a manpage? i'm more than willing to spend 5 minutes to write one, but i don't fully understand what add-apt-repository, nor the options it provides.
<mvo> hyperair: I'm happy to help you with that, there are no more complex issues really, just someone needs to sit down and do it.
<mvo> hyperair: and I'm currenly busy with other fixes that are higher on my priority list
<Chipzz> 09:30 < Jeeves_> Chipzz: But it's allready released, so too late. And obviously everyone can write a manpage. But by then it allready costs more time and bugs than necessary. -> bugs don
<hyperair> mvo: okay, for starters, what options does add-apt-repository provide?
<Chipzz> ugh
<Chipzz> bugs don't cost anything, and time... in case a bug is files it doesn't necessarily take up time of a canonical employee, like pitti pointed out, anyone can contribute a manpage
<hyperair> you got truncated at "bugs don"
<hyperair> ah
<Chipzz> hyperair: accidently hit enter. hence the subsequent "ugh" ;)
<mvo> hyperair: it takes a single line for the form "deb http://foo.bar.com/ubuntu main universe"
<hyperair> Chipzz: ah =p
<Jeeves_> Or it can do stuff with ppa:
<mvo> hyperair: it also supports a shorthand synatax for PPAs (and possible others in the future)
<pitti> hm, and also something like ppa:pitti/postgresql, no?
<Chipzz> and now I'll stfu :)
<hyperair> pitti: yes, that.
<mvo> hyperair: like the line that pitti pasted
<hyperair> mvo: options? are there any?
<hyperair> -h doesn't document any besides -h
<mvo> hyperair: no other options
<hyperair> okay then
<mvo> hyperair: it needs to run as root (obviously)
<hyperair> mvo: right. =p
<cjwatson> Jeeves_: the main root problem, if you must make it about Canonical, is that our staff are often overloaded with feature development, and something often has to give.  Personally I usually write man pages first, but then on the flip side I tend not to do enough regression testing, which creates more bugs than forgetting to write a man page
<mvo> hyperair: PPAs end up in sources.list.d dir
<cjwatson> our internal standards are biased towards regression testing
<hyperair> mvo: and other things?
<geser> could someone please give-back apr-util? Thanks.
<mvo> hyperair: it will get/add keys for PPAs automatically too
<mvo> hyperair: I think thats it :)
<hyperair> mvo: okay cool
<mvo> hyperair: wonderful, thanks a lot! just mail it or attach it to the bugreport
<hyperair> mvo: okay, will do
<Jeeves_> cjwatson: It's not really about making it about Canonical. More about the 'main' archive, which iirc, is Canonical responsibility because Canonical officially supports it.
<hyperair> mvo: er for non-ppa external repositories, where is it put? sources.list or sources.list.d?
<mvo> hyperair: to the main sources.list
<hyperair> mvo: okay cool
<mvo> hyperair: I guess that is something where a "--file=" option would come handy in the future
<hyperair> mvo: that would be cool
 * mvo adds a FIXME in the source
<Jeeves_> hyperair: Thanks
<cjwatson> Jeeves_: main does have elevated standards (https://wiki.ubuntu.com/UbuntuMainInclusionRequirements), but currently manual pages are not among them
<cjwatson> and, even as the man-db maintainer, I'm not sure that that would make sense in all cases
<Jeeves_> cjwatson: I'm ofter curious for a description of a running daemon.
<Jeeves_> There's no direct need for extensive texts about options and so on
<cjwatson> I'm not saying they shouldn't have man pages - merely saying that I don't think it makes sense to make it a requirement for main
<cjwatson> I've probably put more effort into man pages than most people here :)
<Jeeves_> cjwatson: I'm not sure if I should be happy with that. :P
<cjwatson> but it's not the most important thing
<Jeeves_> No, and I never said that
<cjwatson> so, in particular, I don't think it would be appropriate to adopt a standard saying that we don't release software about which lintian complains
<cjwatson> lintian is a tool to help developers, but many of its messages are inappropriate in certain situations, and the importance of the messages that are appropriate varies
<Jeeves_> That's true.
<cjwatson> ubiquity produces a stunning number of lintian messages because it's so weird - but very few of those messages relate to the actual bug problems that it has in practice
<Jeeves_> Anyways, thanks for your time. Have to go in a meeting.
<Jeeves_> ttyl!
<bdrung> pitti: let's defer the units policy fixes to lucid+1 (including nautilus).
<pitti> bdrung: okay
<bdrung> pitti: great. changing half is worse than changing nothing.
<pitti> bdrung: well, wrt. nautilus it's already "half" right now
<pitti> but yes, we certainly have more pressing bugs right now
<bdrung> pitti: yes, but the German translation uses "MiB" for example.
<geser> Could someone please give-back apr-util? Thanks.
<bdrung> pitti: my current plan is to write a library that can be configured to the users preferences. then we can port all apps to this library.
<pitti> geser: done
<pitti> bdrung: hm, I'm not sure whether this should really be user configurable, but if the GNOME guys agree with it, fine for me
<bdrung> pitti: reading all user comment there should be an option for base-2
<pitti> bdrung: ok, so like a gconf key for "geek" mode?
<bdrung> pitti: yes, gconf or something similar. the library should work with GNOME, KDE, XFCE, LXDE apps.
<seb128> you don't want to add a new library only for that do you?
<seb128> using glib seems right there
<bdrung> seb128: i think a new library is better, because not every app uses glib.
<pitti> a separate lib seems quite overkill to me, too, TBH
<bdrung> seb128: there are some glib dev that didn't liked the g_format_size_for_display function. i don't know if they like to have 10+ new functions.
<seb128> bdrung, GNOME will not use yet another lib for that details
<pitti> units don't need translations, etc. so apps could just do the formatting themselves
<bdrung> pitti: but how do you want to have one configuration key to change all apps (including the Qt+ apps you are using in GNOME)
<pitti> well, I don't want a configuration key :)
<seb128> neither do I
<pitti> at most this could be locale specific
<bdrung> but many user want
<seb128> if you need one get a common configuration and let glib and qt respect this one
<pitti> so that "2 kg" becomes "4.1 lb" for our American friends, or so :)
<bdrung> seb128: common configuration? does something like this exists?
<seb128> bdrung, write a file on disk, both glib and qt should be able to read a file on disk no?
<bdrung> pitti: locale specificity does not work. preferring base-2 or base-10 does not depend on the location.
<vorlock> hi guys, I'm trying to aply quiet patch for grub but in ubuntu wiki there is advice to change 'quietboot' option to 'quiet' in a patch but I can't find option like this just function called 'quietboot_func', any hints?
<hyperair> manpage for add-apt-repository: http://people.ubuntu.com/~hyperair/add-apt-repository.1
<hyperair> mvo: what do you think?
<pitti> jdstrand: do you have some time to catch up with https://edge.launchpad.net/~ubuntu-archive/+subscribedbugs during your archive day today? there's quite some backlog with approved FFE syncs, and the like
<cjwatson> hyperair: newline after the end of each sentence (nearly everyone gets this wrong)
<cjwatson> the NAME section is formatted wrongly
<hyperair> cjwatson: really?
<hyperair> er how should i format it?
<cjwatson> .SH NAME
<cjwatson> add-apt-repository \- Adds a repository into the /etc/apt/sources.list or /etc/apt/sources.list.d
<cjwatson> drop the .B and the two bits on separate lines
<cjwatson> "really" to which?
<hyperair> nevemrind
<cjwatson> ok
<hyperair> it was to newline after ...
<cjwatson> see lexgrog(1) for documentation of this
<cjwatson> ah, that's in 'info groff' somewhere
<hyperair> hmm
<cjwatson> info groff --index-search Sentences
<hyperair> other than those two issues?
<cjwatson> those were the two I noticed, I didn't see other serious typesetting issues; not qualified to review the substance though
<hyperair> imo we should have a wiki page documenting how to write a proper man page
<hyperair> i picked my things up from numerous places
<hyperair> cjwatson: okay, updated.
<cjwatson> hyperair: personally I recommend groff_mdoc(7) anyway :-)
<cjwatson> although that's a different macro set
<cjwatson> it's logical markup rather than physical markup
<hyperair> hmm i see
<cjwatson> invented by the BSD people, so you'll find it in use for e.g. ssh(1)
<cjwatson> its only downside at the moment is that it doesn't interact very well with making the man page translatable, or at least I haven't been able to get po4a to cooperate with it
<cjwatson> I think that's probably more of a po4a bug though
<hyperair> hmm
<hyperair> oh hell, they shut down my campus's ubuntu mirror
<matumba> hello everyone, i'm having a problem with nouveau not recognizing my CRT (bad EDID) - against which package would i file a bug or which channel should i join?
<IntuitiveNipple> What package do I assign bugs to for the PowerPC Alternate installer, suffering SEG faults ?
<cjwatson> IntuitiveNipple: default for the alternate installer is debian-installer
<cjwatson> (seg is not an acronym, BTW, it's short for "segmentation")
<IntuitiveNipple> yeah, I know, I was being economical with keystrokes
<IntuitiveNipple> Would you happen to know of a resource that might help me catch and debug the segfault? As it's running from the alternate CD its a bit basic!
<cjwatson> IntuitiveNipple: usually it's bloody hard :-)
<cjwatson> IntuitiveNipple: the dmesg should at least say which process is segfaulting
<cjwatson> sometimes situational analysis is enough, or if it's late enough in the installer then you can 'anna-install strace-udeb' and try to get a strace
<IntuitiveNipple> on tty4 I can see the syslog output that just says "segmentation fault". I've just found https://wiki.ubuntu.com/Installer/FAQ#How%20do%20I%20debug%20the%20installer? which suggests using strace
<IntuitiveNipple> It's during the base-install phase - and I've already verified the CD is free of errors
<mvo> hyperair: thanks! I have a look now
<IntuitiveNipple> it seems to repeatedly happen as packages are unpacked
<IntuitiveNipple> cjwatson: dmesg doesn't report the faulting process. I'll have to figure out this strace method
<jdstrand> pitti: yeah, I was planning that today
<mvo> hyperair: looks good, many thanks. added to bzr
<pitti> jdstrand: thank you
<IntuitiveNipple> cjwatson: It's writing stack-traces of seg-faults to tty1; into the ncurses-style windows so its all over the screen. Is there any way to separate that so it can be captured?
<cjwatson> IntuitiveNipple: the kernel is just writing that to the foreground console, I think.  your best hope is probably to boot with DEBIAN_FRONTEND=text and hope it reproduces with that frontend
<IntuitiveNipple> cjwatson: Thanks, I'll try that later. What is weird is, the installer does seem to be making progress beyond the base-install, it's now asked for user details and is fetching stuff from the mirrors *fingers crossed*
<IntuitiveNipple> I'll capture the syslog into USB key so it can be added to a bug report
<IntuitiveNipple> cjwatson: Interesting: just seen an "Illegal instruction" report in syslog whilst setting up language-selector-common. Can you recommend someone I can talk to who knows about the PPC port?
<ttx> jdstrand: planning to do some syncs today ? i'd need bug 543443 to be covered soon
<ubottu> Launchpad bug 543443 in maven-repo-helper "Sync maven-repo-helper 1.0.4 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/543443
<jdstrand> ttx: yes I am
<ttx> jdstrand: cool :)
<jdstrand> ttx: can you or kirkland respond to my email regarding libvirt 0.7.7 (sent to kirkland, cc'd you and ubuntu-server so it might have gotten filtered somewhere)
<ttx> jdstrand: yes, it's on my TODO list
<jdstrand> cool, thanks
<ttx> jdstrand: still catching up, been at a conference those last days
<jdstrand> ttx: no worries, I just wanted to make sure people saw it :)
<ttx> jdstrand: nothing can escape my GTD system, resistance is futile
<jdstrand> hehe
<cjwatson> IntuitiveNipple: it used to be me, but it's been years; it sounds like something is miscompiled, but I don't know who you'd talk to
<IntuitiveNipple> cjwatson: OK, thanks, I'll poke about a bit. It's a G3 iMac I thought would be useful for testing! Runs OSX 10.4 nicely though
<ev> Just to confirm, Xubuntu 10.04 is *not* an LTS release, correct?
<charlie-tca> wrong
<charlie-tca> xubuntu 10.04 is an lts
<ev> charlie-tca: okay, thanks a bunch!
<charlie-tca> no problem
<charlie-tca> 8.04 was also an LTS for xubuntu
<ttx> jdstrand: about libvirtn read and commented
<ttx> s/n/,/
<jdstrand> ttx: thanks! :)
<pecisk> hi people know, does libsoup respects GNOME proxy settings?
<pecisk> jeesh that came out wrong
<primes2h> crimsun: Hello, if you need help and info about bug 400682 just ask me.
<ubottu> Launchpad bug 400682 in linux "[Karmic stac9227 regression] No sound after upgrade from Jaunty to Karmic" [Medium,In progress] https://launchpad.net/bugs/400682
<primes2h> crimsun: I mean on the Lucid side
<Jeeves_> mvo: Thanks for the fix
<mvo> Jeeves_: cheers, credits go to hyperair for writing it
<Jeeves_> !hyperair++
<hyperair> =)
<Jeeves_> dumb bot :)
<hyperair> it's only in #ubuntu-mirrors i think
<ScottK> bdrung: I think upstream is really the right place to be dealing with the units issues and so now is the time to work on it for 10.10.
<bdrung> ScottK: and what to do with not-glib applications?
<ScottK> I think KDE already complies (at least KDE4 apps).
<ScottK> It's a matter of evangelizing upstreams about the issue and choosing which are most important.
<kees> micahg: any luck finding the thing that causes middle-button-pastes to disappear from my config every time I start firefox?  :)
<bdrung> ScottK: with a separate library we can go to XFCE, LXDE, and so on and ask them to use this library.
<ScottK> Presumably.  I'm not sure what the best approach is, but I think Ubuntu carrying a permanent difference from upstream on this topic is bad on many levels.
<micahg> kees: sorry, not yet...probably will not get to this cycle unless you think it's really pressing
<kees> micahg: that'll be a regression -- asac fixed it in earlier versions before.
<micahg> kees: ok, do you have the bug handy, we should target for lucid then
<snow_ru> yes
<bdrung> ScottK: i want upstream to use the library. carrying a permanent diff is not a solution
<kees> micahg: bug 548866
<ubottu> Launchpad bug 548866 in firefox "forgets middlemouse.contentLoadURL on upgrade" [Undecided,New] https://launchpad.net/bugs/548866
<micahg> kees: I found bug 535465
<ubottu> Launchpad bug 535465 in firefox "middlemouse.contentLoadURL config option gets reset on every upgrade" [Undecided,New] https://launchpad.net/bugs/535465
<kees> micahg: ah-ha yes
<micahg> I'm trying to find where it was fixed in teh past though...
<jjardon> Hello, Could combody take a look to this bug: https://bugs.launchpad.net/ubuntu/+source/gtk-doc/+bug/526794
<ubottu> Ubuntu bug 526794 in gtk-doc "Please sync gtk-doc-tools from debian stable/unstable main" [Undecided,New]
<jjardon> gtk-doc version in lucid is 1.11, but seems that 1.13 is available
<jjardon> in launchpad
<kees> micahg: I assume it's related to the changes from 1.5.dfsg+1.5.0.1-1ubuntu1 "Change various preferences: middlebutton paste disabled"
<kees> micahg: but I can't find where asac fixed it.
<asac> in xulrunner iirc
<micahg> asac: kees: found it
<kees> micahg: cool!
<kees> micahg: I duped the older bug to 548866 since mine has a "reproducer"
<micahg> kees: great, I'll test the patch and commit as soon as we know that 3.6.2 is clear
<asac> micahg: i think to test you need to touch .autoreg and maybe change the version in application.ini
<asac> micahg: e.g. to simulate upgrade
<ccheney> doko: ping bug 417009
<ubottu> Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,In progress] https://launchpad.net/bugs/417009
<ccheney> NCommander: is one of the buildds buggy? i heard 4ubuntu1 failed but didn't see how before it was retried and worked, now 4ubuntu2 fails as well, not sure if it is the same way
 * kees hugs micahg
<ccheney> NCommander: and/or the same machine
<doko> ccheney: ?
<ccheney> doko: i can't find reference to the jaunty stuff in the copyright file, but maybe i am misreading it?
<ccheney> doko: also 4ubuntu2 which didn't change anything relevant is failing to build with segfault, should that just be retried?
<ccheney> doko: i think probably 4ubuntu1 did as well but it was retried before i saw what caused the failure
<doko> looks it is removed in 1:3.2.0-4ubuntu2
<doko> it's the usual buildd failure on armel. these are not reproducible locally unfortunately
<ccheney> well i didn't remove it in 4ubuntu2 as you can see in the debdiff, not sure why it showed up for you under 4ubuntu1 :)
<ccheney> doko: ok
<emgent> hello
<emgent> cjwatson, urgent ping
 * iulian has tried to install Lucid Beta 1 on his laptop and failed. :-(
<iulian> All I got on my screen was this http://people.ubuntu.com/~iulian/DSC05679.JPG.
<nigelb> pitti: got a few minutes to help out with that cheese hook?
<nigelb> It opens up, but the debug does not get saved
<nigelb> correction, the debug gets saved, but not attached
<cjwatson> pitti: bug 432631 is on the foundations list for the release meeting, but AFAICS all the rest is either desktop or assigned to you.  slangasek asked whether the remaining tasks still needed to be fixed for lucid.  Could you comment?
<ubottu> Launchpad bug 432631 in apt "clean up system/per-user proxy handling" [High,Fix released] https://launchpad.net/bugs/432631
<GrueMaster> crimsun: ping - I tested your fix to pulseaudio for dove HP select switch, and it doesn't work as expected.  It only adds the switch to the mute button in the sound-applet.
<pitti> cjwatson: right, that's on our list now
<crimsun> GrueMaster: hmm, make it a port
<GrueMaster> ???
<GrueMaster> Before we release a new version of pulse for this issue, lets make sure we have a completely working solution.
<crimsun> GrueMaster: switch = select, then enumerate the options
<GrueMaster> Ok.
<emgent> hello
<emgent> cjwatson, up ?
<emgent> seems that deboostrap have some turbles
<cjwatson> emgent: I'm here, but it would help if you gave me all the detail up-front rather than saying "urgent ping" and then quitting
<cjwatson> makes it rather hard to actually respond to you
<emgent> deboostrap seems faild always (lenny && ubuntu 9.10) after the packages download, with error: W: Failure trying to run: chroot /home/chroots/1 mount -t proc proc /proc
<emgent> if you try to mount chroot by hands, skipping the mount apt-get is not avail, and also if you try to install it via dpkg and /var/cache/apt/archives/, show some lib perl errors
<emgent> debootstrap --arch amd64 lenny /home/chroots/1 http://debian.fastweb.it/debian
<emgent> cjwatson, take a look.
<cjwatson> no, I'm not going to debug it with that level of detail, sorry
<cjwatson> "some lib perl errors"
<cjwatson> I can't run that command myself, I'm on i386 here, and I'm certainly not going to run debootstrap off a random mirror I don't know
<emgent> -.-
<emgent> cjwatson, what you prefer.. but anyway debootstrap is broken.
<emgent> and you are the maintainer, np for me.
<soren> debootstrap is run thousands of times each day on thousands of different systems in dozens of different contexts and varieties.
<soren> I'm not saying you're lying, but you're clearly using it in a special way that makes it fail, so providing more detail on what exactly you're doing would probably be a good start.
<soren> emgent: ^
<sistpoty|work> actually debootstrap is broken on lenny for unstable, iirc due to Build-Essential flags, which results that apt is not available. maybe that's connected to the problem your seeing?
<soren> emgent: If debootstrap was just plain proken, noone (in their right mind) would be able to install Ubuntu.
<emgent> sistpoty|work, yes i think so
<emgent> sistpoty|work, i found the same problem in lanny and ubuntu 9.10, 8.04
<emgent> s/lanny/lenny/
<emgent> sistpoty|work can you provide the bug id in debian tracker ?
<sistpoty|work> emgent: sorry, can't find it right now
<emgent> ok np
<cjwatson> emgent: feel free to file a bug with full logs.  but if you just turn up, yell at me on IRC, and don't provide enough detail, I can't help you.  sorry
<emgent> will do.
<snow_> cjwatson,
<dmart> emgent: Your chroot failure could be caused by not running as root, or typing to bootstrap an arch which can't run natively on the machine running debootstrap (in which case you would need --foreign).  I take it these aren't the problem/
<dmart> s/typing/trying/
<Keybuk> cjwatson, slangasek: there will be a slight delay to plymouth testing
<Keybuk> I got an assertion error
<emgent> dmart, stop to dream.
<Keybuk> and hurled the netbook out of the window in fury
<Keybuk> and some wild marmosets ate it
<Keybuk> hmm
<Keybuk> here's one of those things I wish I knew
<Keybuk> when you compile source with debugging, gdb prints the source as you trace
<Keybuk> ... how does it know where the source code is?
<zyga> hello
<jjardon> Hello, Could combody take a look to this bug: https://bugs.launchpad.net/ubuntu/+source/gtk-doc/+bug/526794
<ubottu> Ubuntu bug 526794 in gtk-doc "Please sync gtk-doc-tools from debian stable/unstable main" [Undecided,New]
<jjardon> gtk-doc version in lucid is 1.11, but seems that 1.13 is available too
<zyga> does anyone know if alice paul uses IRC or is around here somewhere/
<sistpoty|work> Keybuk: http://en.wikipedia.org/wiki/DWARF for a start? ;)
<Keybuk> yes, I know that bit
<Keybuk> but when you move the source, I've never figured out how to tell gdb it's moved
<Keybuk> not properly anyway
<Keybuk> not without gdb getting confused that there's 8 different files called plugin.c
<cjwatson>    In addition to the source path, GDB provides a set of commands that
<cjwatson> manage a list of source path substitution rules.
<cjwatson> is that what you're looking for?  I've not used it myself ...
<zyga> Keybuk: does the debug data contain relative source pathnames?
<Keybuk> cjwatson: no, that never seems to work
<cjwatson> 'set substitute-path', apparently
<cjwatson> ah
<Keybuk> cjwatson: ooooh
<Keybuk> and, of course, the info file I was reading was from gdb 4.17
<Keybuk> so no wonder it didn't mention it
<cjwatson> what mausoleum were you looking in? :-)
<cjwatson>        gdb | 6.4.90.dfsg-1 |     oldstable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
<Keybuk> just google
<Keybuk> "info gdb" on Ubuntu gives you the dbm info page
<cjwatson> really?  works for me
<Keybuk> which is Not What I Was Looking FOr
<cjwatson> oh, you might need gdb-doc
<Keybuk> ahh
 * Keybuk is having a fail day, clearly
<zyga> mvo: hello, did you manage to run the script I sent you on the mirror?
<Damascene> hello, I wonder about the "Generate dowload script" of Synaptic
<Damascene> it's really a good feautre but it miss one thing.
<Damascene> it should be able to generate update script
<Damascene> so user can genreate update script then chose what programs and updates he want to install then he generate download script
<Keybuk> cjwatson: ahja
<slangasek> Keybuk: would another set of eyeballs be of any help to you this evening?
<Keybuk> set substitute-path /tmp/buildd/plymouth-0.8.1 plymouth
<Keybuk> :D
<slangasek> (for looking, not for feeding to marmosets)
<Keybuk> slangasek: a set of eyeballs that can look at the bugs I haven't
<Keybuk> e.g. that plymouth/sendsigs bug
<Keybuk> that should be a nice one to debug for somebody
<Keybuk> it's easy to replicate
<slangasek> is it? I haven't replicated it yet
<Keybuk> and just needs decent triage to go "aha!"
<Keybuk> slangasek: happens to me most reboots
<slangasek> which is why I haven't tackled it
<slangasek> yah, I haven't seen it *at all*
<exco> any news on poulsbo @lucid?
<Keybuk> slangasek: try changing renderer plugin?
<Keybuk> I think I see it more with text
<exco> there are quite some devices out ther with that us15w chipset right now ... and some particularly nice one in the near future ;-)
<slangasek> ok
<Keybuk> slangasek: mountall-wise
<Keybuk> I know of "one" bug with mountall
<Keybuk> when it does the whole boredom thing (and fsck failure, etc.)
<Keybuk> rather than writing the message, then going back to the main loop
<Keybuk> it basically blocks for input
<Keybuk> this means you get
<Keybuk> Waiting for /porn [SM]
<Keybuk> when in reality, /porn just took a second or two more to actually appear
<Keybuk> (or was waiting for you to type your passphrase)
<Keybuk> so that message should just vanish
<Keybuk> what I don't know is, how many of the "MOUNTALL TOOK A CHAINSAW TO MY LVM! I'M USING GENTOO NOW!" bugs are just dups of that
<Keybuk> ie. in reality, mountall worked "fine" it just got bored too quickly
<Keybuk> and once it was bored, didn't give them the option to try again
<slangasek> hmm, mountall may be too large of a context switch for me today; but I'll see what I can do on that after I clear my own critical stuffs
<Keybuk> or you could help smoser debug his fog problem
<slangasek> Keybuk: yep, will try to pick from that list as time allows
<cjwatson> Keybuk: FWIW I asked barry to look into the mountall/LVM bug; it may take him a little while to get started as it's not particularly his area
<slangasek> Keybuk: though more immediately, I was really asking whether you thought a fresh perspective would be of any help with your plymouth woes - guess not :)
<Keybuk> slangasek: oh, no, not really
<Keybuk> it's just fixing-one-bug-reveals-another
<Keybuk> and the cost of all the reboots and gdb traces and stuff to find them
<Keybuk> and the interruptions on IRC, of course
<Damascene> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
<ubottu> Ubuntu bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Low,Invalid]
 * cjwatson wishes once again that /var/log/partman were timestamped
<Damascene> I'v reported this old time ago
<GrueMaster> crimsun: I'm not getting very far with pulse audio.  In the Sound-applet->preferences window under the Output tab, it has a connector window for selecting "Analog Headphones" or "Analog Output".  So far, anything I create in /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf works when I select Analog Headphones.  Adding a switch=select and options for it creates additional entries in the connector window (i.e. "Analog
<GrueMaster> What I really want is to enable the switch in Analog Headphones (done), and disable the switch in Analog Output (how?).
<Keybuk> slangasek: and I'm hesitant to upload anything
<Keybuk> because then I'll just get a zillion bug reports about the new bug
<Keybuk> and a thousand people uninstalling plymouth again
<Keybuk> and it'll take me so long to get through them
<Keybuk> that I'll have lost the time I could have been fixing them
<ScottK> Sounds like robbiew needs to hire a bug wrangling minion for you.
<robbiew> oh man...don't get him started
<slangasek> Keybuk: what is the new bug?
<Keybuk> slangasek: "could not write bytes: broken pipe" on screen, no visible shutdown screen
<slangasek> ok
<Keybuk> may cause machine not to shut down at all
<Keybuk> curiously, in this state, it replicates that sendsigs bug every time too <g>
<slangasek> ah, then I should evidently update from bzr :)
<Keybuk> bzr is buildable and installable
<Keybuk> -r 1277 will give you a pre-release 0.8.1-1
<Keybuk> just has bugs
<Keybuk> (which I think I has fixed :D)
<Keybuk> 1277 may have been the bug fix I needed
<crimsun> GrueMaster: currently in conference, will have free time in an hour
<GrueMaster> k
<slangasek> Keybuk: btw, I'm trying to resolve several of the "passphrase display is goofy" bugs; I think the right way to fix this is to keep the passphrase prompt down in the same spot as the keys: message, and put the entry box below that, but then we don't fit on anything shorter than 1024x768 - if I scoot the text boxes up across the board on shorter displays, will I be lynched by the design team?
<slangasek> (should I clear the change with them first before committing?)
<Keybuk> no ;)
<Keybuk> just move them around
<slangasek> ok
<Keybuk> right
<Keybuk> if you build from bzr
<Keybuk> and you install plymouth, libplymouth2, plymouth-x11 and plymouth-theme-ubuntu-text *only*
<Keybuk> you should replicate the sendsigs issue :p
<slangasek> ack, will test :)
<Keybuk> not all of the time, but some of the time, mind you
<Keybuk> interestingly I always see the "could not write bytes" and "terminated by KILL" together
<Keybuk> I think this version is "good"
<Keybuk> it's at least no worse than what we had before
<Keybuk> except mostly no console messages, and vga16fb, etc.
<Keybuk> though I'm pretty sure the ubuntu log is wandering off to the right of the screen :p
<Keybuk> logo
<jdstrand> bryceh: hi, what is going on with wacom-tools? it is in source NEW for lucid. seemed it was dropped from the archive for lucid
<jdstrand> s/seemed/seems/
<tjaalton> jdstrand: should be removed from the queue
<Keybuk> slangasek: could you handle NEW for me
<Keybuk> slangasek: the intent is that only plymouth-theme-ubuntu-* are in main
<Damascene> could I find syanptic developer here?
<jdstrand> tjaalton: thanks
<slangasek> Keybuk: sure, looking
<Keybuk> slangasek: it'll need to build first I guess, they're new binaries
<slangasek> oh, well then
<slangasek> yes, in theory I can handle that when they arrive :)
<hyperair> jdstrand: banshee-extension-* source packages are meant to be deleted and superseded by b-c-e. i meant to request their deletions after b-c-e was accepted. was my ordering wrong?
<jdstrand> hyperair: it isn't that it is out of order, I just think that the whole plan should be in the bug and ACKd so we can do it all in one go
<andersk> Does anyone know why 534843 got marked Incomplete?
<andersk> bug 534843
<ubottu> Launchpad bug 534843 in dkms "Sync dkms 2.1.1.2-2 (main) from Debian testing (main)" [Undecided,Incomplete] https://launchpad.net/bugs/534843
<jdstrand> andersk: I do. it was your comments #4 and #5 that made it unclear for how ubuntu-archive should proceed
<andersk> I think ubuntu-archive should just do the sync; it is only bugfixes.
<jdstrand> andersk: if someone from ubuntu-release can comment and mark the bug back to Confirmed with all the necessary ACKs, then we can do that
<andersk> Is ubuntu-release going to look at a bug thatâs marked incomplete?
<jdstrand> andersk: ubuntu-release is subscribed. you can ask them in the bug for a on whether a FFe is required/granted
<jdstrand> s/for a/
<andersk> Okay, Iâll try that.  Thanks.
<jdstrand> np
<hyperair> jdstrand: ah okay.
<hyperair> jdstrand: so i should document everything and reupload?
<jdstrand> hyperair: no, it is still in NEW
<hyperair> jdstrand: it says rejected.
<hyperair> jdstrand: well i got an email saying rejected anyway
<jdstrand> hyperair: well, yes, document everything, but don't reupload
<hyperair> okay
<jdstrand> hyperair: I rejected ubuntu1
<jdstrand> hyperair: ubuntu2 is still there
<hyperair> jdstrand: ah okay, thanks
<hyperair> jdstrand: okay, i've posted it as a comment.
<jdstrand> hyperair: thanks. someone from ubuntu-release can now ACK it and mark it as confirmed, and then we can process it
<hyperair> okay
 * lamont looks around for an ltsp-literate person... stgraber?
<barry> i've been trying to reproduce bug 527666 (mountall hang) but have been unable to.  i am not sure my environment is the same as the reported problem.  i've commented on the bug but if anybody has ideas for other things to try, i'm all ears
<ubottu> Launchpad bug 527666 in mountall "multiple LVM volumes not mounted in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666
<fabrice_sp> barry, I was having this same issue with root on real partition and home on lvm
<snow_> apps in main are supposed to be under GNU v3 license ?
<barry> fabrice_sp: any other partitions, real or lvm?
<fabrice_sp> lvm: data and var/chroot
<fabrice_sp> no other real partition
<barry> fabrice_sp: swap on lvm?
<fabrice_sp> yes
<fabrice_sp> (IIRC: I had to reformat everything since then)
<barry> fabrice_sp: okay, so... real: root; lvm: swap, home, data, var/chroot
<fabrice_sp> yes
<barry> fabrice_sp: ok, thanks.  was this on a vm?
<fabrice_sp> no: on a real desktop
<barry> fabrice_sp: okay, thanks.  i have only vms available atm, but i'll give that a shot and try to dig up a machine to try this on
<barry> fabrice_sp: just curious, was this 32bit or 64bit, single proc or multi?
<qense> Plymouth maintainers/developers: thank you for the great release that just landed in Lucid!
<ScottK> snow_: No.
<snow_> ScottK, !!
<snow_> wonder why launchpad, not googlecode !!!
<ScottK> Apps in Main are all under free licenses, but that's a lot more than GPL V3.
<ScottK> If you look at Launchpad you'll find it does a lot of things that googlecode doesn't.
<snow_> code reviews
<Damascene> hello, could you provide a package that will install the files /var/lib/apt/lists/
<geser> that won't work as that are the files which tell apt which packages are available (and those lists are updated hourly for the development release)
<randomaction> Thanks to whoever has given back failed builds of apr-util.
<geser> I asked and pitti pressed the buttons :)
<slangasek> Keybuk: incomplete update-alternatives conversion?: /usr/share/initramfs-tools/hooks/plymouth: 39: /usr/sbin/plymouth-set-default-theme: not found
<slangasek> Keybuk: ah right, because that hook's not used by default :-)  I'll clean it up
<sistpoty> Keybuk: when an upstart job should wait for network to be available, is the patch provided at bug #522509 the correct procedure, or is there a more general approach than waiting for eth0?
<ubottu> Launchpad bug 522509 in tftp-hpa "[FFE] tftpd-hpa doesn't start on boot" [High,In progress] https://launchpad.net/bugs/522509
<ScottK> Not all systems have an eth0
<slangasek> sistpoty: nope, that patch is wrong
<slangasek> sistpoty: in fact, *both* start conditions are wrong
<slangasek> it needs to be 'start on filesystem and net-device-up IFACE!=lo'
<sistpoty> ScottK: that's why I ask, I used to have an br0 then an eth2...
<sistpoty> slangasek: thanks for double-checking, do you comment on the bug?
<slangasek> sistpoty: yes, was already on my todo list
<sistpoty> thanks! (going through the list atm, trying to do my share)
<slangasek> Keybuk: so, um.  plymouth doesn't seem to be using the x11 renderer now in my tests.
<sistpoty> ogra: looking at bug #542662, I'm completely incompetent: what is a TI OMAP board and how does such a board boot in the first place?
<ubottu> Launchpad bug 542662 in ubuntu "[needs-packaging] x-loader for omap needs to be packaged to build beagleboard images" [High,New] https://launchpad.net/bugs/542662
<ScottK> sistpoty: It's a new armel subarch.
<slangasek> didn't the mobile team's report say those new packages would be deferred to M?
<slangasek> Keybuk: ah - apparently this is a pitfall of trying to use the x11 renderer with only the text theme installed ;)
<sistpoty> slangasek: sorry, still trying to put things together when reading the relevant FFe's. Hope I'm not causing more harm then benefit :(
<slangasek> sistpoty: it's not your fault if they didn't update the bug status appropriately if they mean to defer
<sistpoty> yeah, but I could have added one to one, but didn't *g*
<slangasek> <asac> so omap being a bit behind made a late MIR for x-loader and uboot go away
<slangasek> <asac> we will rely on the flash being properly setup for omap this cycle
<slangasek> so ... MIR, not FFe
<slangasek> dunno what their intent is there, then
<Caesar> slangasek: do you happen to know Scott's reasoning behind making service foo status always exit 0?
<slangasek> nope, sorry
<Caesar> This is going to make managing services with Puppet a little bit of fun
<slangasek> didrocks: after recent updates, under metacity my notify-osd windows can no longer be hidden on mouseover - was there anything in the latest metacity upload that would account for this?
<slangasek> Caesar: in code I've written that needs to know the status, I've been parsing the output, which is fairly straightforward; in some cases I want to know a PID anyway, and there are cases where plymouth declares the job is 'started' but there's no PID and that's /wrong/...
<slangasek> (though always a bug in the upstart job, AFAICS)
<Caesar> slangasek: yeah, it just seems a bit dirty to have to scrape the output of service
<slangasek> oh, wait
<slangasek> 'service'
<Caesar> I think I'll cross-post a thread between upstart-devel and puppet-dev
<slangasek> that's a bug, then
<Caesar> Puppet currently has no native Upstart support
<Caesar> But assuming it gets it at some point, I imagine it's going to be wanting to shell out to service, not the legacy init script?
<slangasek> 'service' is meant to be an abstraction around upstart jobs and sysvrc scripts, and I expect *its* status command to return a sensible exit code
<Caesar> I agree
<slangasek> if it has native upstart support, the native upstart command is "status <job>"
<Caesar> fwiw, status foo also exits 0 regardless of state
<slangasek> yeah; that's just not a design decision that should necessarily pass through to 'service'
<Caesar> So you think it's okay for status foo to exit 0 always?
<Caesar> Which interface should Puppet use? service or start,stop,status?
<slangasek> I don't like it, but I think that's a conversation we'd need to have with Keybuk
<Caesar> Yeah
<Caesar> I'll do up an email a bit later
<slangasek> I have no opinion on which interface you use; obviously if service handles parsing of 'status' output to generate a meaningful exit code, and puppet elects to use 'status' directly, there'll be code duplication
<slangasek> didrocks: it seems this is bug #546348; but I'm not sure what component actually changed to cause the behavior change
<ubottu> Launchpad bug 546348 in notify-osd "notify-osd does not disappear on mouseover" [High,Confirmed] https://launchpad.net/bugs/546348
<chrisccoulson> slangasek - gtk changed
<chrisccoulson> there's a similar bug about not being able to click through with compositing
<slangasek> chrisccoulson: ah, thanks - is there a bug on gtk tracking this?
<slangasek> 546650 maybe?
<chrisccoulson> slangasek, yeah, that's the one
<chrisccoulson> sorry, i was waiting for LP to catch up there ;)
<chrisccoulson> i might do a bisect tonight if i have time
<slangasek> chrisccoulson: Macslow posted a git commit ID to the bug already
<chrisccoulson> ah, ok. i haven't looked at it since this morning
<kobrien> so, best ide for deving ubuntu c code?
<showard> Hi, I'd like to point some attention to bug #539049 and bug #457688
<ubottu> Launchpad bug 539049 in boost1.40 "boost::python & python>=2.6.3 broken (karmic, lucid)" [High,Confirmed] https://launchpad.net/bugs/539049
<ubottu> Launchpad bug 457688 in boost1.38 "[SRU, 9.10] libboost-python1.38 issues with __doc__ property in Python >= 2.6.3" [High,Confirmed] https://launchpad.net/bugs/457688
<showard> both are actually the same bug, but one is a SRU and one is a bug fix upload for lucid
<showard> we're cherry picking an svn commit from upstream and applying it to the packages
<showard> it causes several depending packages to segfault frequently, and has been fixed for a few months. I've recently turned the patches into debdiffs, and would appreciate someone sponsoring the uploads (and a release team member to check out the SRU)
<showard> (it has been fixed upstream and in a ppa for testing for a few months). Thank you! There has been a bunch of duplicates and pings on it lately.
<slangasek> Keybuk: so, um... plymouth doesn't seem to be working from the initramfs any more; it seems to fall over if /proc isn't mounted
<slangasek> (but I can't spot a relevant change in the diff)
<Caesar> Is there a known issue with the alternate installer not finding disks?
<Caesar> If I search for 2.6.32-17 in the kernel bugs nothing is jumping out at me
<slangasek> Caesar: bug #546929
<ubottu> Launchpad bug 546929 in linux "most PATA/SATA modules missing in Lucid netboot" [Critical,Fix released] https://launchpad.net/bugs/546929
<Caesar> slangasek: thanks
<cjwatson> speaking of which, could somebody in an American timezone upload debian-installer once linux has built and published on all architectures?
<Caesar> Please :-)
<slangasek> if I notice it's available and I'm not stuck in initramfs hell at the time, yes
<cjwatson> there's a bugfix in bzr, so build from there
<cjwatson> should just be dch -r
<Caesar> Fun times?
<slangasek> now I understand Keybuk's frustrations with plymouth - things are broken that haven't been touched :)
<mrooney> james_w: whoa, the GSoC project "Automated optimistic merging and testing of new upstream releases" sounds awesome! I'm sad I'm not a student anymore!
<Keybuk> Caesar: err, that's a bug ;)
#ubuntu-devel 2010-03-27
<Keybuk> slangasek: tell me about it
<Keybuk> status should exit non-zero if the job isn't running
<Keybuk> I think my notes say that it should even exit non-zero if job is starting or stopping - but different non-zero to "not running at all"
<Caesar> Keybuk: excellent, you've saved me an email
<Caesar> Can you fix it for Lucid?
<Keybuk> huh
<Keybuk> if slangasek lets me ;P
<Keybuk> oh, I see - it got lost in the move to using D-Bus Properties
<Caesar> Keybuk: I thought service had a few exit 0's in places as well
<slangasek> Keybuk: perfectly fine
<slangasek> Keybuk: now, can you tell me why plymouth now falls on its face in the initramfs looking for /proc/cmdline, when it didn't before? :)
<slangasek> hmm; maybe that's not the reason it's falling over
<slangasek> apparently break=bottom is too late to test, because /proc has already been unmounted again by that point :P
<jbebel> cjwatson, using the previous installer (the one that actually supports hard drives), we're now failing to set up encryption when the crypto partman method is used.  Is that known?  I don't find a bug for it.
<jbebel> Partitions get created, but there's no LUKS header.
<slangasek> jbebel: is that the bug that was in the beta1 release notes about LVM+encryption?
<jbebel> That's a different bug, I think.  We were seeing that one, and this is substantially different.
<slangasek> Keybuk: aha, got it - --attach-to-session doesn't work without /dev/pts :P
<jbebel> with the release notes bug, partitioning, LUKS, LVM, and the root filesystem were setup, just swap wasn't created.  now, we aren't even making it past LUKS.
<slangasek> hmm, ok
<Keybuk> slangasek: which is why I patched initramfs-tools to mount it ;-)
<slangasek> Keybuk: ah, but without a versioned dep
<Keybuk> it doesn't break it
<slangasek> right, I'll grab that then
<Keybuk> it just means you get console splurge
<snow_> hm
<Keybuk> (the parent exits 69, but it seems that the child carries on regardless)
<snow_> quickly can be used for C/C++ ?
<slangasek> Keybuk: actually, after plymouth fails to start in the initramfs, it *also* fails to start in the root fs; haven't diagnosed that yet to see if it's the same cause
<slangasek> and since I was testing post-initramfs passphrase prompting at the time, I had a right mess
<slangasek> the post-initramfs failures may just be unhappiness with my /usr-as-separate-partition
<slangasek> Keybuk: ah, and after upgrading initramfs-tools, can't reproduce the failure of the plymouth job post-initramfs. <shrug>
<slangasek> so I guess things are working :)
<Keybuk> http://news.opensuse.org/2010/03/25/opensuse-11-3-milestone-4-release/
<Keybuk> THE APOCALYPSE HAS COME! :D
<slangasek> Keybuk: congratulations, your vga16fb renderer has been reported as a bug. :-)
<Keybuk> "My $1,000 nVidia card should be able to do more than 16 colors" ?
<slangasek> yep
<slangasek> though it would be nice to have a crisper logo on vga16fb, that's certainly not the renderer's fault
<Keybuk> right, Design were supposed to have furnished us with one long ago
<Keybuk> we made them aware of the need for it from the very beginning
<jjardon> Hello, could be automake 1.11 upgraded to 1.11.1 ? Automake 1.11 are known to be suffering from critical security issues
<jjardon> https://bugs.launchpad.net/ubuntu/+source/automake1.11/+bug/526035
<ubottu> Ubuntu bug 526035 in automake1.11 "Upgrade package version to 1.11.1" [Undecided,Fix released]
<jjardon> the request is for karmic, lucid already have the 1.11.1 version
<jjardon> should I file a new bug?
<slangasek> jjardon: given that the justification for an update in karmic is a security issue, you should talk to the Ubuntu Security Team, who are already subscribed to the bug; I've added a new bug task for karmic on that bug
<jjardon> slangasek, thanks a lot
<ion> Le sigh, an apparmor update broke the system again.
<ls_a> hi
<_minerva> anyone who would be interested in mentoring "truely system wide proxy" for gsoc
<_minerva> anyone who would be interested in mentoring "truely system wide proxy" project for gsoc !!
<RAOF> _minerva: It's either Friday evening or Saturday for everyone now; it's not a good time for finding people online :)
<_minerva> RAOF: k thanks anyway
<jdstrand> ion: can you file a bug?
<ion> jdstrand: Bug #458299
<ubottu> Launchpad bug 458299 in linux "apparmor_parser: page allocation failure. order:5" [Medium,Confirmed] https://launchpad.net/bugs/458299
<jdstrand> ion: thanks
<dholbach> ArneGoetje: what's going to happen to the branches in Bug #46318 - I'll try to get them from the sponsors' list
<ubottu> Launchpad bug 46318 in tutos2 "Change dependency from postgresql to postgresql-client" [Medium,Fix released] https://launchpad.net/bugs/46318
<yofel> hey, are there any amd64 builds of UNR planned for lucid? (or lucid+1)
<sistpoty> gilir: just looking at bug #523433. how about deferring that to lucid + 1 and then making a backport for lucid?
<ubottu> Launchpad bug 523433 in ubuntu "[need-packaging] [FFe] pcmanfm2" [Wishlist,New] https://launchpad.net/bugs/523433
<Kalidarn> yeah it'd be good if were amd64 builds because the new N450 atom processor is 64bit
<Kalidarn> it's in the MSI Wind series atm http://www.msi.com/index.php?func=prodpage2&maincat_no=135&cat2_no=582 other vendors will follow
<kklimonda> what are the benefits of amd64 on netbooks anyway?
<Kalidarn> i would have figured it was worthwhile if the chip supported it.
<Kalidarn> http://ark.intel.com/Product.aspx?id=42503 :P
<tjaalton> slangasek: plymouth-set-default-theme went missing in the last plymouth upload, was that intentional?
<tjaalton> *latest
<Tm_T> there seems to be plenty of mess with plymouth nowadays
<gilir> sistpoty, there is incompatible changes in pcmanfm2, if you use a backport version, you need also changes in others packages
<gilir> sistpoty, it will also be less easy to switch for v1 to v2, as the backport will override the previous one automaticly if you are using backports
<tjaalton> slangasek: nevermind, seems like some theme packages have not migrated
<sistpoty> gilir: what needs to be changed in other packages? why would the backport override the previous one?
<ari-tczew> can anybody review SRU? bug 421684
<ubottu> Launchpad bug 421684 in obexd "bluetooth send malformed files " [Undecided,Confirmed] https://launchpad.net/bugs/421684
<otro_viajero7> hello, how do I specify in my Makefile an "Input file with spaces.c" in gnu make?
<sistpoty> otro_viajero7: escape the space with \   ... not too sure how well make handles spaces though (I think I read that there are limitations, but can't find it right now)
<otro_viajero7> I tried that, but it does recognize it as two files
<sistpoty> otro_viajero7: that works for me: http://paste.ubuntu.com/402439/
<sistpoty> otro_viajero7: however you won't be able to use $^ then, obviously
<otro_viajero7> thanks sistpoty ;)
<sistpoty> yw
<gilir> sistpoty, because for lucid +1, it will stay as pcmanfm, there is no need to keep a pcmanfm2 after lucid
<sistpoty> gilir: ah, I see, thanks
<pecisk> kenvandine, ping?
<MaximLevitsky> I need to know exactly how compiz is started on ubuntu
<bens_> Ahoi.  Already talked to #virt about this, and no ideas.  Ubuntu 10.04 Beta or 9.10, most recent kvm/libvirt available for either.  Linux guests get ~20MBps disk throughput, windows xp guests get <3MBps at best.  Tested both guests with all possible img types, preallocated.
<bens_> I can push >40MBps to the linux guests dev/shm, but only 20MB to disk.  the host disk is capable of 170MBps
<bens_> the host disk is ext4 on lvm, on top of mdraid5 10 disks.
<bens_> When I put the  guest image in /dev/shm instead, I get proper performance.
<bens_> Can't find any reference to this problem on the intarwebs.
<bens_> Ideas?
<bens_> (p.s. install time for a tinyxp guest (<300MB) was >10 hours with the guest image on the raid.  <5  minutes on shm.
<ari-tczew> should do we update-maintainer in SRU?
<ScottK> ari-tczew: No.  Minimal diff.
<ari-tczew> thanks
<psusi> cjwatson, I am working on that libparted code and I'm not sure if it is throwing the correct type of warning because gparted seems to happily ignore it
<geser> ScottK: so we (Ubuntu) need to update the Maintainer when modifying packages in the development release, but can "skip" it in SRUs?
<ScottK> geser: That's my understanding.  SRU is supposed to be a minimal diff.  Changing maintainer isn't actually needed for the SRU, so I'd call it not minimal.
<ScottK> I could certainly be wrong.
<geser> I would have excepted that we need to update the maintainer in SRUs too (especially as it is risk-free). But I could be wrong too.
<geser> I remember that we didn't do it for SRUs in some older release before we started to systematically update the Maintainer field.
<ari-tczew> men, please specify a consensus
<cjwatson> I must say, I
<cjwatson> 've generally updated Maintainer in SRUs
<cjwatson> but I can see the argument for not doing so; I don
<cjwatson> 't think it matters either way
<ScottK> Clearly don't do it for a Dapper SRU.
<ScottK> I'm not sure either.  I'm also not on the SRU team.
<cjwatson> (sorry, ' is symbol-shift-m on the N900, while ctrl-m of course generates CR, and I keep missing)
<ari-tczew> okay, but if I made update-maintainer on lucid for package from lucid-1 and older is it OK?
<ari-tczew> men, please answer, I don't have a lot of time
 * sistpoty thinks a change of the maintainer value doesn't effect the value of an SRU, so it's safe to do it
<ari-tczew> sistpoty: but not necessary right?
<sistpoty> ari-tczew: if anything else is fine, changing maintainer or not can be done by the uploader, whatever the best practice is.
<cjwatson> ari-tczew: nobody will argue if you omit the change; people might argue if you include the change
<cjwatson> so it seems clear that if you are in doubt then there is a safe option
<ari-tczew> ok
<cjwatson> ari-tczew: also, "men" sounds weird as a way to address a group like this (even leaving aside questions of sexism); I'd suggest not using that form
<sistpoty> (might be lost in translation... good movie btw :))
<psusi> cjwatson, so have you any idea why gparted seems to happily ignore libparted warnings when it can't sync the partition table?  from your comments on bug #540940 I got the feeling you are more familiar with it than I
<ubottu> Launchpad bug 540940 in parted "Regression: Unable to add a partition to a disk that has another partition in use" [High,In progress] https://launchpad.net/bugs/540940
<ari-tczew> cjwatson: okay, so s/men/dear developers
<cjwatson> psusi: can't look today - but it could well just be catching the exception and ignoring it?
<cjwatson> psusi: can't look today - but it could well just be catching the exception and ignoring it?
<cjwatson> psusi: gparted didn't inspire much confidence in me when I last looked at it, though at least most of the partitioning logic is still left to libparted
<psusi> cjwatson, that's what it seems to do... but I'm wondering why... it seems it ignores the warning, then judges that everything seems ok, and continues
<cjwatson> I stopped using it in ubiquity for several good reasons :)
<cjwatson> anyway, got to put my daughter to bed, later
<psusi> I'm also confused about extended partition handling... I swear that if you had primary slot 4 used for the extended partition, the kernel did not make a /dev/sda4, it just skipped straight to 5 and on for any logical partitions in the extended
<psusi> but now it seems it makes /dev/sda4 with a size of 2... it maps the pseudo mbr and the next sector for some reason
<ogra_cmpc> cjwatson, n900 ?
<ogra_cmpc> welcome to the club :)
<sistpoty> psusi: yes, that's what I recall for extended partitions
<sistpoty> psusi: actuall it still seems to be true for me with 2.6.32-16-generic #25
<sistpoty> +y
<sistpoty> (amd64)
<psusi> sistpoty, you sure?  because for me I get a dev node for the extended partition of size 2
<sistpoty> psusi: that's what I get: http://paste.ubuntu.com/402553/
<sistpoty> psusi: so indeed, there seem to be devices for extended partions (not sure if that changed though), which contain the header as expected
<cjwatson> psusi: it's certainly what I remember, although I don't know whether it's always been that way.  It seems moderately useful for things like installing a boot loader to the EBR
<sistpoty> psusi: /dev/sda3 doesn't have size 2 though: http://paste.ubuntu.com/402556/
<cjwatson> not maybe the most useful thing ever, but not useless either
<cjwatson> ogra_cmpc: yeah, it's a pretty nice device
<cjwatson> been meaning to blog first impressions
<ogra_cmpc> yep, i'm in love with it since i got mine
<sistpoty> yep, makes inspecting a partion easier (and yes, I did write a program to look for partition header once, since I was an idiot who deleted a partition)
<cjwatson> getting a bit late possibly :)
<cjwatson> the keyboard isn't quite perfect, and there are a few annoying bugs, but it beats the hell out of S60
<cjwatson> and it seems competitive with Android - haven't any direct iPhone experience so can't say there
<ogra_cmpc> definately, to sad that maemo is dead though, imho it was a bad decision to drop it
<cjwatson> mm
<ogra_cmpc> meego simply will take a while to get into such a state
<cjwatson> I'm sort of reserving judgement until I see how meego turns out, though dropping the .deb format is a shame
<ogra_cmpc> yeah
<cjwatson> yeah, switching technologies is going to suck
<ogra_cmpc> well, we have omap images since today ... people can start proting to it ;)
<ogra_cmpc> *porting
<cjwatson> but at least meego will work (to some extent) on the n900, so we won't have to get new devices
<cjwatson> I need to start developing for it in some way
<cjwatson> at the very least fix the annoying xterm enter bug
<cjwatson> anyway, OT I suppose :)
<ogra_cmpc> oh, btw, ppc d-i didnt find anna after my upload it seems (/me didnt have time to debug that yet)
<cjwatson> grr, that might be a recurring buildd bug
<cjwatson> lamont fixed that ...
<cjwatson> is there a permission error on sources.list in the log?
<ogra_cmpc> i'll ping him on monday and will give it back (if no other upload happened)
<ogra_cmpc> hmm, i didnt notice one but i scrolled directly to the error msg
<cjwatson> if so, don't just give it back, it needs a launchpad-buildd (re)fix
<cjwatson> it was a consequence of upgrading the powerpc buildds to karmic
<ogra_cmpc> ah
<lamont> cjwatson: which buildd?
<lamont> cjwatson: monday I plan to roll a new lp-buildd, there's some dogfood testing first, then we'll blat it to the world
<cjwatson> lamont: adare
<kusum> cjwatson: Hello
<kusum> cjwatson: Doest the code keep changing from new releases of Ubuntu ?
<lamont> cjwatson: best way to find the umask of a running process?
<cjwatson> kusum: of course; which code in particular?
<lamont> GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH
<lamont> fixored
<kusum> i am sorry
<lamont> when one edits the init.d, one should restart the service.
<cjwatson> lamont: um, not sure, suppose it's somewhere in /proc but I can't check right now
<cjwatson> lamont: ah :) thanks
<kusum> i forgot to mention partman-auto-loop code
<lamont> no worries - process older than init.d
<lamont> so adare is fixed
<lamont> giveback left as an exercise
<cjwatson> kusum: hasn't changed a huge amount, but sure, it's changed
<kusum> cjwatson: what are .nsh files ?
<kusum> i did not really find useful info about them
<cjwatson> something windowsy.  I don't write Windows code so I don't know
<kusum> ok
<kusum> cjwatson: it is for ui code in windows ?
<sistpoty> lamont: btw, did you reschedule ghc6 on armel? I'm a bit worried if it does make any process, though Laney is certainly  more competent to tell this
<sistpoty> lamont: (it seems to not progress since a few days, but as I wrote, Laney is the better person to ask)
<cjwatson> kusum: I said I don't know :)
<lamont> sistpoty: the jaboticaba build? yeah, I'm ignoring that on the grounds that it'll be interesting to see if it finishes before release
<lamont> it's known/expected to not make progress.
<lamont> OTOH, armel is keeping up just fine these days, so tying up jaboticaba to find out isn't really hurting anything.  ergo, meh.
<kusum> cjwatson:  thanks for the information
<cjwatson> kusum: did you try googling for "windows nsh"?  links related to nsis should be relevant
 * lamont wanders off to break networking
<kusum> cjwatson: i finally understood when i googled "compile nsh files"
<kusum> i was thinking nsis was wrong link
<kusum> got it now :)
<exobuzz> hi
<slangasek> tjaalton: yes, it's intentional that it's gone missing, theme packages need to use update-alternatives now instead
<exobuzz> i have made a useful bash script I call "ubuntu experience". you can run it from within gnome, to add that unique ubuntu touch to your desktop windows. http://pastebin.com/DafZTLuk
<exobuzz> (Yes its a joke, forgive me. i couldnt help myself).
<kusum> cjwatson: thank you
<cjwatson> kusum: you're welcome
<psusi> sistpoty, what does cat /sys/block/sda/sda3/size say?
<ari-tczew> please review SRU bug 262235
<ubottu> Launchpad bug 262235 in clutter "Does not work on 64bit properly" [Unknown,Fix released] https://launchpad.net/bugs/262235
<sistpoty> psusi: 2
<sistpoty> psusi: is that in blocks? then 2 would make perfect sense for an extended partition, I guess
<psusi> sistpoty, yea... I think so... what's it map the second sector for?
<psusi> I and I swear the kernel used to just not map them.... if you only had a extended partition you got sda5 and that was it... no 1-4... seems odd to map the extended container
<sistpoty> psusi: not too sure, I admit that I don't recall the format for an extended header, but I think that I recall that it was two blocks (which you really shouldn't take for granted)
<psusi> sistpoty, I noticed this because I had an error while testing my fix to parted... tried to create a logical partition starting at the start address of the extended+1... parted thinks it should work and tries, and the kernel rejects the addpart since it overlaps the second sector mapped by the extended partition
<psusi> sistpoty, I thought it was just another pseudo mbr so should only be 1 block
<sistpoty> psusi: there must be documentation somewhere to prove that speculation (both yours and mine :))
<psusi> hrm... seems fdisk doesn't want to start the logical partition for 63 sectors into the extended
<sistpoty> psusi: crap, thought that I might help you but reading the wiki article shows that I really don't recall any details, sorry (http://en.wikipedia.org/wiki/Extended_partition)
<psusi> oh weird... if I turn off the dos compat flag, fdisk won't start the logical until sector 2111
<psusi> hrm... yea, it should only be one sector
<psusi> though due to customary cylinder alignment, typically has 62 unused sectors following it before the logical partition
<arand> psusi: When I dd my extended partition, I only get 1024b.
<arand> psusi: If it remember right.
<psusi> arand, right... 2 sectors
<psusi> I'm wondering first, why the extended has a dev node at all, I swear this did not used to be the case, and secondly, why it is 2 sectors long
<psusi> when you put parted in sector mode it seems to think you can create the logical partition on the very next sector, but the kernel doesn't like it
<arand> psusi: I'm quite happy it has, since my main bootrecord is on there :)
<psusi> what do you mean?
<psusi> extended boot records are not bootable
<arand> psusi: I have my main mbr (vbr) residing in that 1024 space, yes.
<psusi> arand, that doesn't make sense... by definition the mbr is sector 0
<arand> psusi: Well, actually my proper mbr picks up which start key I press and delegate to either sda1 or sda4.
<psusi> and sda4 is an extended partition?  weird... what boot loader is this?
<arand> psusi: The one on the mbr-proper is some Dell mediadirect thingy ref. http://digiwanderlust.blogspot.com/2008/04/dual-boot-boot-linux-using-dell-media.html, on the extended vbr I have a 466b grub bit I dd:d over from a logical partitions vbr (since grub2 wasn't happy about installing to the extended's bootrecord).
<psusi> hrm.... yea, and when I use parted to create several logical partitions, they start on the sector immediately following the ebr.... no second sector unused...
<psusi> arand, ack... so you're using blocklists ;)
<stgraber> join #hackus
<stgraber> oops
<psusi> damnit.... hw_sector_size and optimal_io_size in /sys/block/sdd/queue are not writable....
<psusi> nice to see that the kernel does not respect the hidden flag on gpt partitions
<cjwatson> psusi: imo, none of this extended partition stuff should block your patch; if it's a problem, it isn't a new one
<psusi> cjohnston, agreed... just cleaning it up now... think I have it working pretty good now
<jbebel> When might I expect linux 2.6.32-18.27 to get built/uploaded?
<jbebel> assuming it allows us to test Lucid installs again.
<jbebel> Also, I suppose a new d-i will need to be built too.
<geser> jbebel: the new linux debs are in the NEW queue and waiting on an archive admin looking at them. if they don't get a special treatment on this weekend, they should get accepted during the week (probably on monday)
<rawkasaur> When 10.04 is released, is it recommended to do a fresh install, or will updating be enough?
<ScottK> Upgrading should be fine.
<rawkasaur> Alright, thanks.
<cjwatson> jbebel: um, didn't this morning's d-i build fix the missing modules already?
<jbebel> cjwatson, it doesn't appear to have.
<cjwatson> well, can't look now ...
<jbebel> it's still using -17 and doesn't have sata modules.
<jbebel> I was going to take a closer look at why drive encryption was failing, but without drives that's a bit more difficult.
<cjwatson> oh, for goodness' sake, I didn't realise they were going to bump abi and obviously ogra didn't check ...
<ogra_cmpc> no, i didnt
 * cjwatson pulls out the laptop then
<ogra_cmpc> i would have noticed if the meta had hit ml laptop during the upgrade this morning but thats obviously still in new
<ogra_cmpc> s/ml/my/
<slangasek> ups, sorry; smb had mentioned there'd be NEW processing, didn't realize that hadn't been communicated
<ogra_cmpc> sorry for that
<cjwatson> oh well, I'll sort it out now
<cjwatson> jbebel: thanks for the note
<jbebel> cjwatson, np
<Sarvatt> how about having a plymouth-i-want-a-pretty-boot package that forces plymouth into the initrd? :)
<cjwatson> I'll just upload d-i in advance, it can dep-wait or whatever if it likes
<jbebel> cjwatson, do you think this new d-i and/or kernel has any chance of fixing drive encryption?  I haven't gotten far figuring out what's wrong yet.
<cjwatson> no.
<cjwatson> well probably not
<cjwatson> d-i's just the core, the initrd doesn't contain partitioning code
<jbebel> I filed a bug with partman-auto-crypto, but I'm thinking that was the wrong place.
<slangasek> Sarvatt: does it need to be a package?  It's a one-line change to /etc/initramfs-tools/conf.d/
<cjwatson> jbebel: it'll do
<cjwatson> jbebel: I prefer not to waste time reassigning between packages until I've actually analysed it; any vaguely plausible installer package is fien
<cjwatson> *fine
<jbebel> fair enough.
<Sarvatt> just thinking about user friendlyness for that change even though it is easy to do and it is a common complaint :) guess it'd be more appropriate for something like ubuntu-tweak
<cjwatson> jbebel: the race with swap creation is top of my list right now; if that doesn't turn out to fix your problem too, I'll look at it after that
<jbebel> Right now we're not even making it to the swap creation step though.  I suspect you'll find the same thing.
<cjwatson> I just mean that I want to debug one thing at a time. :-)
<jbebel> Sure. :)
<cjwatson> races in this sort of area sometimes have multiple consequences, so we'll see
<cjwatson> I kind of doubt that this is specific to swap creation, but I haven't narrowed it down yet
<Sarvatt> just worked through a problem where someone wasnt getting a splash for almost 30 seconds into the boot with this fstab setup - http://pastebin.com/tYgACis9 would adding nobootwait to one of those partitions fix that?
<jbebel> I can't even set up encrypted partitions manually anymore.
<cjwatson> Sarvatt: many perfectly normal situations in lucid result in not having a splash for that sort of length of time; it may not be fixed for lucid
<cjwatson> I wouldn't advise mucking with fstab to try to influence that
<cjwatson> the problem is a conflict between boot performance and boot experience, that needs non-trivial work to resolve
<cjwatson> on hard disks, the most efficient way to boot is to run ureadahead to load everything, *and do nothing else while it's running*
<Sarvatt> yeah thats why I was suggesting maybe we should have a package people can install that puts plymouth in the initrd with OPTION=FRAMEBUFFER=Y without requiring manual editing
<cjwatson> any disk activity at all will spoil its seek pattern and ultimately slow things dodwn
<cjwatson> down
<cjwatson> but it turns out that getting the splash up before that involves bottlenecking on waiting for the graphics drivers to initialise
<cjwatson> Sarvatt: I assumed you didn't understand the problem because you were talking about fiddling with fstab :-)
<cjwatson> therefore I thought an explanation might be worthwhile
<cjwatson> though you were talking about efifb the other day so I assume you've looked into it ...
<ogra_cmpc> Sarvatt, did you actually make that user create a bootchart ?
<ogra_cmpc> might be an issue with dmraid or some such
<Sarvatt> ah ok, it looked like it was waiting for everything in this guys custom fstab to be ready before continuing because / was ready pretty early into the boot which is why I asked that. it wasn't loading gpu modules until after everything was mounted because they weren't in the initrd and packing in plymouth fixed that
<cjwatson> I might be wrong, but I don't think it should wait for filesystems to be up
<cjwatson> plymouth starts on starting mountall, and plymouth-splash starts on started plymouth and (your primary graphics device appeared, or other stuff)
<slangasek> right
<cjwatson> I'm not actually sure what forces ureadahead to be serialised ahead of that, although my understanding is that it is
<slangasek> the usual problems we see are 1) ureadahead takes so long that the user is sitting at a blank screen for 30s or more before mountall actually starts mounting anything, or 2) the single-partition SSD install is so fast that gdm is ready to start as soon as udev has announced the video device
<slangasek> cjwatson: actually, I don't think anything *does* force it to be serialized; I think we may have just found a bug
<slangasek> it may be a bug we don't currently hit because upstart always walks /etc/init in the same order
<slangasek> but I don't think we're meant to rely on that
<cjwatson> reverse alphabetical order? :)
<jbebel> cjwatson, I could be wrong, but I think the end-of-disk gap for md is what broke crypto somehow.
<cjwatson> jbebel: seems odd, why would that make any difference?
<cjwatson> it gets a fractionally smaller container, that's all, surely?
<jbebel> I agree, but it stopped working for us just about with that release of partman-base
<cjwatson> I think I'd rather analyse first
<jbebel> Sure
<jbebel> oh... Hmm.  It might have been something else in 139.  I forgot that our mirrors got a bit behind.
<cjwatson> it would be good if you could attach syslog as well as partman
<cjwatson> jbebel: I fixed the bit about /boot landing at the end of the disk, BTW, I just haven't uploaded that yet
<jbebel> Ah.  Excellent!
<slangasek> cjwatson: actually, since ureadahead itself doesn't block, /alphabetical/ order would be the one that gives better performance by starting plymouthd first instead of starting it while ureadahead is in the middle of running :)
<cjwatson> partman-auto-lvm 33ubuntu3 will clear that up
<cjwatson> slangasek: right, but I mean right now doesn't upstart block due to the 'expect fork' trick in ureadahead before it gets round to starting plymouth?
<slangasek> cjwatson: oh, I don't know - I was going by the comment in the job, which says "Forks into the background both when reading from disk and [...]"
<slangasek> maybe this all works the way it's supposed to, but if so it's sorely underdocumented :)
<cjwatson> nih_dir_walk_scan sorts the list of filenames
<cjwatson> I imagine it then inserts them into a linked list such that the last one ends up run first, or something
<cjwatson> but haven't bothered to check that
 * slangasek wonders if someone can decipher what's really going on in bug #541700, given that the submitter's statements are not credible :/ (aubergine screen with no ubuntu theme installed)
<ubottu> Launchpad bug 541700 in plymouth "plymouth: blank/unanimated screen at boot (cat /proc/fb: 0 VGA16 VGA)" [Undecided,New] https://launchpad.net/bugs/541700
<jbebel> We did get bitten by suddenly needing to include partman/confirm_nooverwrite in the preseed after 139.  That should probably be added to the example-preseed in the installation guide.
<cjwatson> oh, yeah, I meant to do that
<cjwatson> kickseed too
<cjwatson> I thought about that and everything and forgot.  Sorry
<jbebel> It's fine for us. I figured it out. :)
<jbebel> I can file a bug to add it to the manual if that would help.
<cjwatson> no need, already committed a fix
<cjwatson> and upstream
<cjwatson> partman-base 139ubuntu1 is even less likely to have caused this; the core changes there were minimal compared to 138ubuntu4
<cjwatson> 138ubuntu3 and 138ubuntu4 were big changes
<cjwatson> in fact all the 138ubuntu* series
<jbebel> Maybe our mirrors were more behind than I thought.
#ubuntu-devel 2010-03-28
<psusi> cjwatson, well I'm trying to attach what I think is the final draft of that patch to the bug report but firefox is being fubar and won't select the right file.... going to see if an update and reboot fixes it...
<siddhartha> hello,sorry about the noob-ness.. i have a question: i was running a karmic installation.. i somehow managed to change change my release type to eeebuntu after adding some package repos.  Recently i added lucid repos. Is there any way to change the distribution release type ? lsb_release -a tells me im still running eeebuntu.
<siddhartha> hello,sorry about the noob-ness.. i have a question: i was running a karmic installation.. i somehow managed to change change my release type to eeebuntu after adding some package repos.  Recently i added lucid repos. Is there any way to change the distribution release type ? lsb_release -a tells me im still running eeebuntu.
<arand> siddhartha: -> #ubuntu or #ubuntu+1
<Sarvatt> slangasek: I'm guessing its the vga=795 (aka 1280x1024x24bpp) boot option they are passing to a vga16fb.. :D
<siddhartha> leave #ubuntu-devel
<slangasek> Sarvatt: nope, the fact that they're *using* VGA16 is proof that the vga= option had no effect (which probably means they're using grub2)
<slangasek> Sarvatt: if vga= had worked, /proc/fb would show vesafb as fb0 instead of vga16fb
<nixternal> slangasek: any pointers on creating a custom plymouth theme? the one I created yesterday will not work with the new plymouth, it always falls back to the ubuntu one
<slangasek> nixternal: are you using update-alternatives?
<nixternal> yes
<nixternal> update-alternatives --config default.plymouth
<slangasek> er - you're not doing that in the maintainer scripts, are you?
<nixternal> no no, I am doing this locally
<slangasek> ok
<nixternal> not in packaging at all
<slangasek> well, the only fallback path is between default.plymouth and text.plymouth
<slangasek> does /etc/alternatives/default.plymouth point where you expect?
<nixternal> yup
<slangasek> can you post the theme somewhere?
<slangasek> sounds like the theme is simply failing to load
<nixternal> oh, no it doesn't
<nixternal> there is the problem
<slangasek> ok :)
<nixternal> hrmm
<nemo> Did you guys drop libcaca from libSDL?
<nemo> (Karmic/Lucid)
<nixternal> hrmm
<nixternal> still falls back to ubuntu dangit
<nixternal> I am guessing we can't use the fade-in example with anything other than ubuntu now slangasek?
<slangasek> ScottK: so there's one flaw in the proposed methodology on foundations-lucid-supportable-binaries: we know whether the source package FTBFS at the beginning of the cycle, but we don't know whether there were binaries *of that version* in the archive at the time without doing a lot of LP parsing; so if the package was FTBFS /at the time it was uploaded/, but has subsequently built, we have no good way to distinguish those binaries that we
<slangasek> ... successfully built *afterwards* from those that were built *earlier*.
<slangasek> nixternal: what do you mean?
<slangasek> the fade-in theme isn't Ubuntu-specific; it doesn't even include an Ubuntu logo
<nixternal> but it uses the ubuntu logo no matter what
<nixternal> wth...I just did the xubuntu-logo theme, and on shutdown it worked, but on startup it went back to the ubuntu logo again
<slangasek> did you forget to rebuild an initramfs?
<nixternal> shush :p
<nixternal> slangasek: ok, got it working, however the fade-in theme is locked to the ubuntu logo...i have another fade-in theme from fedora that was the stars and it worked yesterday
<slangasek> ScottK: so - if we remove all the binaries that are built from source <= the version that failed in the rebuild test, we risk nuking some that do actually build successfully now, and only FTBFS then because of a bug in a different package
<slangasek> ScottK: I can't say how many packages will be affected by this - if I could say, I wouldn't have to worry in the first place :) - but the number of source packages showing up in my report is much lower than the number in Lucas's latest rebuild
<slangasek> ScottK: so I'm inclined to propose them all for removal anyway
<slangasek> nixternal: ah yes, I can confirm this in the source - the logo path has to be compiled into the splash plugins, and points at /lib/plymouth/ubuntu-logo.png
<slangasek> nixternal: so if you want to use one of the other splash plugins with a different logo, you'll need to dpkg-divert /lib/plymouth/ubuntu-logo.png
<slangasek> nixternal: note that if you do a dpkg diversion of this file in a package, you will need to also Conflict: with any other theme packages that want to divert the same file
<slangasek> (maybe this should have also been an alternative, hmm)
<nixternal> slangasek: yeah, I don't feel like doing a divert, so I will go with something else in the mean time
<slangasek> nixternal: oh, and if this is for packaging, the only base theme that integrates with mountall is the ubuntu-logo theme; so I don't advise basing off any of the others if you're planning to ship this by default for a flavor release
<nixternal> right, that is what I am basing the kubuntu one off of now
<superm1> slangasek, is there going to be an alternative for just replacing the logo in the ubuntu-logo theme?  it seems kind of silly to reproduce all the logic in the script in individual themes and have to keep up with syncing it all the time then
<slangasek> superm1: if you're only replacing the logo and want to leave the colors and fonts the same, dpkg-divert on the logo would do the job; but an alternative may be the better way to go for scalability, so I'd suggest filing a bug on plymouth about this and I'll talk to Keybuk on Monday
<superm1> oh yeah, i forgot that the default background for ubuntu-logo isn't black, so some folks might not want that
<superm1> i'll file a bug though still
<slangasek> superm1: hum, see my follow-up
<slangasek> superm1: perhaps that unblocks you for what you're trying to do
<superm1> slangasek, yeah that should help a lot, thanks!
<ScottK> slangasek: What about doing on the list at the start of the cycle and still out of date?
<ScottK> I think that gets us to the same place.
<slangasek> ScottK: that misses packages that are up-to-date because they built prior to lucid and haven't been uploaded since
<slangasek> ScottK: so do we want the false-positives, or the false-negatives?
<ScottK> Right.
<ScottK> slangasek: On the list at the start of the cycle and (still out of date or version == the version on the list)?
<slangasek> that runs into the same false positives as before
<slangasek> it doesn't tell us if it was on the list at the start of the cycle because of a bug in the package, or a bug in its build-deps
<ScottK> slangasek: We don't care why, just that we can't build it.
<slangasek> it doesn't tell us we /can't/ build it, it tells us we /couldn't/ build it then
<ScottK> OK.  One more try.
<slangasek> I'm ok to say "yes, we may be removing packages that build fine now in the rare case that they built before, failed to build in November, and are buildable again today"
<slangasek> I just want to be clear that this is what we're saying
<ScottK> Check that list against the latest rebuild list.
<slangasek> ah, that works
<ScottK> If it isn't on that list, then it's OK.  If it's not out of date, ignore it, if it's out of date, give it a retry.
<ScottK> Does that work?
<slangasek> yep (hmm, which of us is lagged? :)
<psusi> well that was messed up... had to delete my firefox profile to get it to stop inserting the wrong file in the upload dialog on lp... it kept putting in the one above the one I clicked.... in the process I noticed two other things really fubar... the first was ctrl-alt-F1 no longer switches to a tty, and the second is when I logged in a guest session, it got access denied trying to ls /home despite the fact that /home is world readable
<psusi> were either of those last two intentional?  and if so, how the hell was the second one done? ;)
<slangasek> the guest session is done with apparmor
<slangasek> ctrl-alt-f1 is not intentional
<psusi> plymouth bug?
<slangasek> no
<slangasek> not unless you're running an old version of plymouth
<psusi> just upgraded
<ScottK> slangasek: I was lagged.  My wifi router was bought when we had one wifi device in the house.  I think we have about 10 now.  Every now and then it has a conniption.
<ScottK> Also we have 4 7 year olds over for a slumber party tonight, so every now and then, I have to go restore order.
<psusi> grrr.... well I guess that explains it... still very frustrating getting access denied on something world readable, heh...
<slangasek> ScottK: right - cross-referencing with http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi removes 103 source packages from the cull list, leaving 125
<ScottK> I'm suprised it's not more.  That's good news I guess.
<ScottK> Of the 103 are any currently out of date and needing to be tried again?
<ScottK> If there are, shoot me a list and I'll take care of them.
<slangasek> hmm, let me see
<slangasek> ScottK: libpoe-component-client-dns-perl is the only one
<ScottK> OK.  I'll have a look
<ScottK> Thanks.
<ScottK> Retried, we'll see.
<ScottK> slangasek: Odd.  The retry on that failed.
 * ScottK throws up his hands and says "Perl, meh!"
<slangasek> is it possible that it failed to be included in lucas's latest rebuild run at all?
<slangasek> (the page I'm pulling from only shows me confirmed failures, it doesn't confirm the names of the packages that succeeded)
<ScottK> Perhaps.
<ScottK> Maybe lucas will read the scrollback and check.
<slangasek> lucas: ^^ :)
<slangasek> "t/06_hosts.t" - looks suspiciously like a test suite whose success depends on the buildd environment's network config
<ScottK> Wouldn't suprise me.  Since it's arch all it never hits a buildd in Debian.
<genii> I'm affected by bug 545585  , 2 days ago the bug report says "This bug was fixed in the package linux - 2.6.32-18.27"   Is there a timeline when -18 will be in the repositories?
<ubottu> Launchpad bug 545585 in linux "lucid iwlagn free more than tfds_in_queue" [Medium,Fix released] https://launchpad.net/bugs/545585
<crimsun> genii: it's already in the repo.
<genii> crimsun: Weird. dist-upgrade reports nothing available (I'm still on -17 but using -16 for stability due to this bug)
<crimsun> genii: your mirror probably hasn't synced yet
<genii> Strange. apt-cache search shows it but dist-upgrade reports no kernel updates.
 * genii manually installs
<wgrant> It looks like the new linux-meta isn't out yet.
<wgrant> That's required to pull in the new ABI.
<diwic> How do I easiest make a debug build of a package?
<wgrant> diwic: There are pre-built debug symbols for all packages in the archive. See ddebs.ubuntu.com
<diwic> wgrant, yes, I've tried that, but when I try to debug the line just jumps up and down, I guess I need to build with -O0 to avoid that
<diwic> i e when I press "next" in ddd/gdb the next line is often not the expected one
<diwic> I guess, due to aggressive inlining and other optimizations
<lucas> slangasek: yes, tests hanged, so I had to kill it manually => did not fail, but did not succeed.
<slangasek> lucas: could you give me a list of those?
<lucas> slangasek: on http://people.ubuntuwire.org/~lucas/ubuntu-nbs/, there are files with the full results on i386 and amd64
<slangasek> lucas: so the 'Unknown's in http://people.ubuntuwire.org/~lucas/ubuntu-nbs/res.lucid.{i386,amd64} are what I'm looking for?
<pecisk> kenvandine, ping? :)
<geser> slangasek: removals in Debian are still imported into lucid, right? or are removal bugs needed?
<gnomefreak> were the daily alt. ISo's moved?
<gnomefreak> http://cdimage.ubuntu.com/daily/current/ doesnt have them
<lifeless> gnomefreak: releases.ubuntu.com
<gnomefreak> lifeless: those are daily builds? why wasnt desktop image moved
<gnomefreak> http://cdimage.ubuntu.com/daily-live/current/ has daily desktop
<gnomefreak> releases.ubuntu is the latest released ISO (beta1)
<sabdfl> slangasek: what's the protocol to request a sync from Debian now, for schroedinger?
<lifeless> sabdfl: well, its a new upstream, so requestsync --lp -d unstable -e schroedinger
<lifeless> unless 1.0.8->1.0.9 is bugfix only from upstream, in which case drop the -e
<mattn> hi
<mattn> i'm trying to build a package that adds a new entry to /etc/services
<mattn> is there a debian-way to do this?
<pecisk> mattn, why would you do that?
<mattn> to see the service when doing netstat -l for my package ;)
<mattn> or should one not add local services at all?
<lifeless> submit a patch to netbase
<aburch> Actually, ask IANA (see the header of /etc/services)
<lifeless> aburch: actually, I think you need to see the header :)
<Laney> I'm getting this aptitude core reasonably reliably now
<lifeless> "or are needed by a Debian package" is in that header.
<lifeless> mattn: you could see the nmap package, a comment in services suggests that nmap might add more, in some fashion.
<mattn> good idea - thanks
<mattn> looks like it delivers some own service file
<cjwatson> lifeless: (gnomefreak has left, but FYI) daily builds are never on releases.u.c - if they're missing from cdimage, it's because the build failed (probably several times in succession)
<cjwatson> geser: you need to file removal bugs - semi-automatic removal processing stops at DIF
<lifeless> cjwatson: oh, ok
<lifeless> cjwatson: thanks
<WoAnerges> hi guys!
<WoAnerges> have VAIO with "ATI mobility radeon HD 4570" and Intel Core2 DUO T6600 @ 2.2GHz.
<WoAnerges> can't install ubuntu 10.04 normally. problems with video appearance.
<WoAnerges> need help.
<WoAnerges> i know - the image in attachment - it looks like video card owerheat, but it's not an owerheat of vc processor. i am sure about that, because i had a vc that was damaged by owerheating. this is not that case. i think there's a compability problem with laptop hardware. dear development team,,, you must fix it :S
<WoAnerges> don't leave me without ubuntu. (=
<WoAnerges> http://ubuntuforums.org/attachment.php?attachmentid=151676&d=1269750326
<azeem> WoAnerges: please ask in #ubuntu
<WoAnerges> they sent me here
<WoAnerges> :(
<WoAnerges> i feel like in a hospital!!!
<lucas> slangasek: yes
<BenHoltz> hey everyone i need some help with my ubuntu instalation.  I have upgraded to the 10.04 version and I'm having problems with grub loading.  Can someone point me in the right direction to re-configuring grub?
<BenHoltz> i just  read the topic, i will take this to #ubuntu
<slangasek> geser: I think a removal bug is a good idea
<ari-tczew> can we add a patchsystem in SRU?
<blistov> oi. Lucid Beta, up to date as of this minute, host disk is a single 7500RPM SATA2 disk which moves ~90MBps, ext3/ext4 fs, libvirt/kvm linux guests get ~20MBps max, and windows guests get <4MBps max, using any emulation mode (ide/scsi/usb, and virtio for linux)
<blistov> If I put the guest image on dev/shm, I get about 20MBps in Windows guests and about 250MBps in Linux guests.
<blistov> Any idea's?  Haven't found any bug report yet.
<sladen> blistov: file one please
<blistov> sladen, do you think this should be filed under kvm or libvirt?  Same response from qemu.
<cnd_mini> I'm working to clean up the linux-firmware-nonfree package, and I've come across the lintian tag stating that there's no valid copyright statement in debian/copyright
<cnd_mini> I'm not sure who the copyright should be assigned to
<cnd_mini> it's a native package with no upstream, and it's just a bunch of non-distributable firmware files
<sladen> blistov: you can attach the same bug to both
<sladen> blistov: eg. created it again qemu, then click "also affects distribution (Ubuntu)" and add kvm/etc
<cjwatson> ari-tczew: please don't - just work with whatever's in place right now
<cjwatson> cnd_mini: there doesn't have to be a single answer - you're supposed to list all the copyright statements and licences and which parts of the package they apply to
<psusi> cjwatson, you get a chance to look at my last revision of the parted patch?
<jono> can anyone tell me where the purple ubuntu wallpaper lives on an ubuntu system
<zyga> jono: I think it's called warty-final
<zyga> just dpkg -S warty
<zyga> it should find it
<zyga> it's in /usr/share/backgrounds AFAIR
 * psusi kicks debugfs... says there are extra inode fields there, but won't show what they are or let you manipulate them
<rlameiro> what is the name of the propietary drivers installer?
<crimsun_> jockey?
<rlameiro> ok
<rlameiro> ok jockey gives me this error SystemError: installArchives() failed
<rlameiro> trying to install a broadcom driver
<rlameiro> does anyone here come into this?
<zyga> rlameiro: did you run it from command line?
<rlameiro> yes
<rlameiro> zyga, it doesnt output nothing
<rlameiro> does it have a verbose option?
<rlameiro> no it doesnt have verbose option
<rlameiro> it just output a error message saying
<rlameiro> SystemError: installArchives() failed
<zyga> hmm, if it's written in python (SystemError hints that)
<zyga> it probably has a log file somewhere, can you check the source code of what it does?
<rlameiro> try to look at it
<cjwatson> psusi: I haven't been at my laptop all day, sorry
<zyga> rlameiro: me?
<rlameiro> zyga, no, me :D
<rlameiro> I didnt find anything
<psusi> cjwatson, ahh, ok... well I'm satisfied with those parted changes and have gone back to working on e2defrag... hope you get them in for beta 2
<cjwatson> psusi: I certainly intend to!  I want to get those bugs closed
<zyga> rlameiro: did you run jockey-gtk or jockey-text?
<cjwatson> psusi: it's on my list for Monday
<rlameiro> gtk version
<rlameiro> zyga running the text version now
<zyga> rlameiro: I'm checking the source now, please run the text version
<rlameiro> it outputs nothing
<rlameiro> just says searchinf for available drivers and then quits
<zyga> rlameiro: I ran jockey-gtk via strace to check if it opens any files but it seems not to
<zyga> so chances for log files are none
<rlameiro> in text mode i made this
<rlameiro>  sudo jockey-text -e kmod:wl
<rlameiro> and the result was exactly the same
<rlameiro> i think there are some bugs already
<rlameiro> but this on beta1,
<rlameiro> i am running ubuntustudio, could it be for that?
<zyga> rlameiro: I think that some part of jockey is catching exceptions and not showing the backtrace
<zyga> rlameiro: I don't know
<rlameiro> zyga, maybe jockey is calling some lib or other script ...
<rlameiro> do i have a way to know that?
<zyga> rlameiro: most likely apt stuff
<rlameiro> without having to read all the code :D
<zyga> rlameiro: yes, check what it imports
<zyga> no
<zyga> :-)
<zyga> just see the imports
<rlameiro> lol
<zyga> and imports of imports that don't look like standard python stuff or gtk stuff that cannot possibly install software
<rlameiro> well it imports a lot of dbus stuff
<rlameiro> and oslib...
<zyga> rlameiro: I think the actuall stuff is somewhere inside jokey's libraries
<rlameiro> zyga, well
<rlameiro> i will ty to reboot now and see how it goes
<rlameiro> cya
<rlameiro> zyga, it works now
<zyga> rlameiro: I checked oslib, it imports apt module
<rlameiro> It seams that the problem might be related with the indexing of the apt list or something...
<rlameiro> this is straight from install
<rlameiro> it shouldn't happen
<rlameiro> fort the firstcommers this can be very scary :D
<zyga> rlameiro: you should file a bug about that though
<zyga> rlameiro: include the output from jockey
<zyga> if anything the error handling code should be more user friendly
<rlameiro> zyga, what is the handling code?
<zyga> well the details are not important unless you want to fix this and dig deeper
<zyga> but the part that broke was this:
<zyga> the UI was bad
<zyga> something was not working
<zyga> but the UI didn't tell you anything about which part is broken
<rlameiro> yeap
<zyga> didn't include any logs or any other reference for tracking this for power users
<rlameiro> but the text version had the same problem also
<zyga> did you run apt-get update or similar before rebooting?
<zyga> rlameiro: yes, both versions didn't handle that error condition very well
<rlameiro> no
<rlameiro> ok
<zyga> rlameiro: so it was fixed by magic, that's not good
<zyga> I was hoping you can still reproduce it
<rlameiro> ok i will file that bug
<rlameiro> so i will file that on jockey bugs
<rlameiro> is there some tool to give info of my sistem, so devs can now?
<rlameiro> zyga, for reproducing it i will need to do a fresh install again :D
<zyga> since jockey itself didn't crash nothing can help us directly
<zyga> I think it's best to include the actual output
<rlameiro> ok
<rlameiro> maybe i go and ask about it on ubuntu-bugs
<zyga> (and the commands you launched)
<zyga> as well as the fact that reboot fixed the problem
<rlameiro> ok
<rlameiro> zyga
<rlameiro> !bug #550503
<ubottu> Launchpad bug 550503 in jockey "at first boot, Jockey cant activate the broadcom driver" [Undecided,New] https://launchpad.net/bugs/550503
<rlameiro> you can go ther if you want
<rlameiro> i did mentioned you
<rlameiro> :d
 * psusi is deeper into the innards of the ext4 fs than any human ever should be...
<dottedmag> psusi: So Theodore Ts'o is not a human? Is he a superhuman officially now? :)
<psusi> hehehe.... if I could have him over my shoulder working on this ancient code of his I would ;)
<psusi> this stuff was written when dinosaurs ruled the earth...
<psusi> and now I'm going over the new headers trying to figure out what has changed and update it to use the new features... like extents
<psusi> didn't ted used to hang out in here?  not seen him lately
<arand> Daviey: If not already aware (sorry if), plymouth-theme has now switched over to be provided by lubuntu-plymouth-theme instead of mythbuntu-default-settings, also Bug #550237 exists.
<ubottu> Launchpad bug 550237 in plymouth "[lucid] update to lucid shows as mythbuntu and doesn't work" [Undecided,New] https://launchpad.net/bugs/550237
<Daviey> arand: I don't think it's a bug with mythbuntu tbh
<superm1> arand, i think the recommends of plymouth need to be fixed to recommend "plymouth-theme-ubuntu-text | plymouth-themes" instead.
<Daviey> lubuntu-plymouth-theme is alphabetically before myth*, which is why you are now seeing lubuntu*
<superm1> Yup
<arand> Yea, it's in the recommends  pulled in by plymouth that the issue lies, I assume
<slangasek> hmm, fixoring plymouth then
<arand> Wouldn't recommending plymouth-theme-ubuntu-logo have a place as well?
<slangasek> arand: metapackages will already pull in -ubuntu-logo by default, and it's an open question whether we want that on server; we only need to recommend one default, so -text should be it
<arand> Ah, ok
 * slangasek uploads the fix
<arand> So I can set a confirmed for the plymouth task then at least, to get some communication out to the bug-lookers?
<slangasek> if you do it fast :)
<psusi> hrm.... odd.... /etc/mke2fs.conf says in the defaults section to use 256 byte inodes, but does not set the extra_isize flag... I don't think you're supposed to do that... if it isn't 128 bytes that flag should be set....
<slangasek> arand: please also advise them to manually remove lubuntu-plymouth-theme / mythbuntu-default-settings
<arand> slangasek: Done, so the updated package won't solve things automatically for people who alreadty installed it?
<slangasek> arand: nope, an update won't cause these theme packages to be kicked out
<Daviey> the joy of running beta :)
<superm1> slangasek, as it stands today, plymouth-theme-ubuntu-logo appears to be a dependency of ubuntu-standard.  should that perhaps be moved to the desktop and netbook seeds respectively so that server doesn't pull in the logo'd themes too?
<Daviey> superm1: I think the logo'd theme is "as designed" :(
<slangasek> superm1: as I said, it's "an open question" :)
<Daviey> i'm meaning to see how that works with serial console.
<arand> slangasek: Are those reasonable instructions: http://pastebin.ubuntu.com/404764/ ?
 * Daviey will sulk and throw his toys if serial console is busted. :)
<slangasek> arand: sure
<slangasek> superm1: bug #548954
<ubottu> Launchpad bug 548954 in ubuntu-meta "Ubuntu servers should display information during boot by default" [Undecided,New] https://launchpad.net/bugs/548954
#ubuntu-devel 2011-03-21
<brucee> hi all. I have a query about natty. Is this the right place
<RAOF> That depends on the type of question.  This is a channel for the development of Natty, so if your question has to do with that, yes :)
<brucee> well, I installed it (alpha3) on an older lenovo z61m laptop and I
<brucee> I'm having some difficulty with the network. does that qualify :) ?
<RAOF> MAybe; it perhaps sounds more like a bug report, though. :)
<brucee> probably. Or just me being braindead. So you recommend launchpad?
<RAOF> Or #ubuntu+1 for support.
<brucee> great idea - I'll head there !
<slangasek> ogasawara: gcc-4.5 4.5.2-6ubuntu5 uploaded; TTBOMK this is the last upload needed before beta
<pitti> cjwatson, slangasek: I uploaded a new scour with dropping rsvg, and reverted cdbs; that should do
<pitti> Good morning
<slangasek> pitti: morning!  Yes, saw your mail over the weekend, thanks for taking care of this
<pitti> sorry for the mess
<slangasek> n/p, I'm glad you found a better solution than my "kick it out of cdbs" one :)
<cdbs> out of me?
<nigelb> This is precisely why you need a new nick :P
<slangasek> cdbs: are you the personification of a package helper? :)
<cdbs> slangasek: yes, but I prefer debhelper over myself
<slangasek> heh
<nigelb> lol
<nigelb> the irony.
<TheMuso> lol
<cdbs> no, the advantage of this nick is that whenever someone mentions 'cdbs' I get pinged
<nigelb> deserves a bash.org
<cdbs> giving me the chance to kick into the conversation and recommend others to use dh
<cdbs> okay, enough offtopic conversation, and slangasek just /ctcp versioned me :{
<slangasek> cdbs: /hilight cdbs would do for that ;)
<Chipzz> cdbs: that's a... weird attitude :)
<Chipzz> cdbs: that or a very strong dislike of cdbs ;P
<\sh> moins
<didrocks> good morning
<dholbach> good morning
 * slangasek waves
<jamespage> slangasek: good morning
<jamespage> slangasek: re bug 737603 - I can either provide you with details on how to reproduce in Jenkins (its fairly easy)
<ubottu> Launchpad bug 737603 in openjdk-6 (Ubuntu) "JNI unable to find libpam.so" [High,Triaged] https://launchpad.net/bugs/737603
<jamespage> or happy to test a deb now if you want me to.
<slangasek> jamespage: I don't have any .debs built in a useful place, but I guess you can rebuild openjdk-6 from source more quickly than I could get you one (given that it's 1:30am here)
<jamespage> slangasek: OK - I'll do a local rebuild and try out the patch; I'll also append test case details into the bug.
<slangasek> jamespage: sounds good :)
<jamespage> thanks for looking at this
<slangasek> no prob
<jamespage> :-)
<slangasek> pitti: so, are you happy for me to upload eglibc with this change?
<pitti> slangasek: yes, except I'd like to understand why it's only a transitional pacakge
<slangasek> pitti: ah, replied in the merge log, darn slow email :)
<slangasek> pitti: "transitional" in the sense that it exists only to enforce fully upgrading libc6 before upgrading anything else; once everything's upgraded (after next LTS), we can drop it
<pitti> slangasek: ah, thanks
<pitti> slangasek: updated MP again
<slangasek> w00t
<slangasek> just noticed a (non-linux-specific) bug there, which I'll fix up before uploading
<slangasek> pitti: yay, eglibc uploaded, thanks for the review
<slangasek> that just leaves glib2.0 for me to break
<slangasek> er, I mean, convert ;)
<dholbach> can anyone review my lp:ubuntu-packaging-guide branches please?
<seb128> hey, does anybody know if soyuz support.tar.xz tarballs?
<mr_pouit> seb128: Bug #619152 (there's a branch but it doesn't seem merged yet)
<ubottu> Launchpad bug 619152 in Launchpad itself "Add data.tar.xz support" [Low,Triaged] https://launchpad.net/bugs/619152
<mr_pouit> oops, no
<mr_pouit> I misread, sorry
<cjwatson> pitti: did you notice the livefs build errors which seem to be caused by language-pack-kde-es and language-pack-kde-oc having file overlaps with the non-KDE versions?
<pitti> cjwatson: uh, no, I didn't
<pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/kubuntu/latest/livecd-20110321-i386.out seems fine?
<cjwatson> try kubuntu-mobile
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/kubuntu-mobile/latest/livecd-20110321-i386.out
<pitti> cjwatson: ah, thanks; will check that
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/latest/livecd-20110321-i386.out
<cjwatson> (more inclusive)
<cjwatson> seb128,mr_pouit: I guess I should work on the infrastructure needed for that
<seb128> cjwatson, so soyuz doesn't handle it yet?
<seb128> cjwatson, GNOME is thinking to switch to .tar.xz tarballs
<seb128> cjwatson, that's why I was asking
<cjwatson> it doesn't - https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152/+merge/32868 explains the situation
<ubottu> Ubuntu bug 32868 in espresso (Ubuntu) "Autopartition doesn't warn" [Medium,Fix released]
<cjwatson> oh shut up ubottu
<cjwatson> huh, I apparently have most of the work done locally - I must have got sidetracked
<seb128> cjwatson, thanks
<seb128> cjwatson, does that cover all orig.tar.xz use?
<cjwatson> oh, wait, you said orig, my branch was just for data
<cjwatson> let me check status of that
 * cjwatson misread in the same way as mr_pouit
<seb128> cjwatson, sorry for not being clear ;-)
<cjwatson> dpkg-dev/lucid supported orig.tar.xz, at least
<cjwatson> I think it's just a matter of extending a few regexes and enumerations and the like in LP
<seb128> cjwatson, is there any way we can make sure it's on the launchpad team list to get working for next cycle?
<cjwatson> I can probably just submit a branch for it
<seb128> cjwatson, no hurry, I'm just trying to make sure we don't get blocked at some point because the switch happen for GNOME and in Debian and our bits are not in place for it
<seb128> but that's not before some months, they are still discussing it
<cjwatson> it falls in the category of rather-do-it-now-than-in-a-hurry-later for me
<seb128> right
<cjwatson> seb128: note that Debian doesn't support it yet either
<cjwatson> fwiw
<seb128> cjwatson, seems pochu is on it,he said he talked to the debian ftp-masters and the topic is on the agenda for their next meeting
<cjwatson> that's useful to know, thanks.  there's no bug report.
<seb128> cjwatson, in fact pochu mentioned it on debian-project@l.d.o in reply to the reminder email sent there
<seb128> oh, buxy mentioned it first it seems
<seb128> well anyway it's being discussed there
<emgent> mdz ping
<dholbach> bdrung, pushed harvest tool to ubuntu-dev-tools again
<dholbach> bdrung, let me know if it'S alright this time
<dholbach> seb128, ^
<seb128> dholbach, thanks
<bdrung> dholbach: grep hugdaylist harvest
<dholbach> fixed
 * dholbach now takes the dog for a walk - see you in a bit
<bdrung> dholbach: pylint found some unused variables
<hallyn> jdstrand: kees: hey, debian has security updates for libcgroup and libvirt-bin.  Has someone already started on merging those?  (I don't care toduplicate work)
<Riddell> TheMuso: how do I get orca to read me something?
<JackyAlcine> o/
<jdstrand> hallyn: I am preparing libvirt-bin. I don't think anyone is working on libcgroup atm, though you might ask in #ubuntu-hardened
<jdstrand> kees: ^
<hallyn> jdstrand: thanks
<cnd> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: cnd, smoser
<cjwatson> ogra_: hi, could you apply http://paste.ubuntu.com/583309/ to jasper-initramfs, please?  using ubuntu-devel as Maintainer means that upload acknowledgements go to the reviews list; ubuntu-devel-discuss is more conventional
<ogra_> cjwatson, oops, doing so
<cjwatson> thanks
<pitti> cjwatson: btw, if the kernel team asks you to copy kernels around, this should help quite a bit: http://people.canonical.com/~ubuntu-archive/pending-sru.html#kernelppa
<Riddell> pitti: is b43-fwcutter still needed on the CDs?
<cjwatson> pitti: neat!  thanks
<pitti> Riddell: not urgently, I think; we don't even offer b43 any more in jockey, wl is the standard driver now
<Riddell> pitti: so broadcom is all free now?
<pitti> cjwatson: to avoid confusion: the sru-accept.py thing does not include the automatically generated CVE bugs, as they don't get verified by QA
<pitti> Riddell: no, wl is proprietary
<pitti> Riddell: there is an experimental broadcom driver in staging, but still too unstable; we don't offer it in jockey yet
<Riddell> hmm, confusing
<hallyn> the free broadcom driver doesn't do ad-hoc though still, right?
<hallyn> which seems to really imply we should have b43 in jockey...  it's actually half the reason why i'm back on lucid on my netbook
<pitti> I took it out since it deterioates quickly; I got tons of kernel oopses/crashes with b43, and people kept picking the wrong one
<hallyn> yeah having two is confusing, for sure
<hallyn> i just need someone with spare time to implement ad-hoc in the free one :)
<hallyn> s/implement/fix/ (as the source suggests it thinks it implements it)
<cnd> SpamapS, I'm reviewing bug 533985
<ubottu> Launchpad bug 533985 in bash-completion (Ubuntu) "Bash completion whitelisting returns no results when it could return some that do not match" [Wishlist,Triaged] https://launchpad.net/bugs/533985
<cnd> oh wait, I thought there was an issue
<cnd> but I realized I was working on the wrong computer
<mterry> What's the most useful way to report a kernel panic?  I don't see anything in /var/crash, and I don't get an apport prompt
<cjwatson> seb128,mr_pouit: https://code.launchpad.net/~cjwatson/launchpad/tar-xz/+merge/54215, FYI
<ubottu> Ubuntu bug 54215 in ubiquity (Ubuntu) "debconf frontend went away (dup-of: 52682)" [Undecided,Confirmed]
<ubottu> Ubuntu bug 52682 in ubiquity (Ubuntu) "debconf frontend went away -- kde-ui" [Undecided,Invalid]
<seb128> cjwatson, thanks
<cjwatson> and the data.tar.xz bit is now waiting on sysadmin
<seb128> ok
<seb128> mterry, try asking on #ubuntu-kernel I guess
<cjwatson> (orig.tar.xz doesn't need any sysadmin action)
<seb128> mterry, you want kerneloops-daemon for oops issues, not sure about panic ones
<ari-tczew> pitti: are you apport developer?
<pitti> ari-tczew: yes
<ari-tczew> pitti: look http://paste.ubuntu.com/583335/
<pitti> ari-tczew: I see the problem, hang on
<pitti> ari-tczew: fixed in trunk, thanks
<ari-tczew> pitti: 7 minutes needed, wow! :)
<pitti> dpm: oh, thanks for pointing to the https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam stuff, that's useful!
<dpm> pitti, no worries :) - btw, after we have a locale for a new language in langpack-locales or upstream, are there any other technical steps to enable it and ship a langpack for it? I've meant to ask you for ages, I've just remembered now
<pitti> dpm: yes, one: we need to add it as a supported locale to langpack-o-matic
<pitti> dpm: ah, that could actually do with a bit of automation, hang on
<dpm> ok :)
<pitti> dpm: done; ./update-maps in langpack-o-matic now updates maps/supported-locales as well
<pitti> dpm: we need to do that as we usually run this under lucid, and the local /usr/share/i18n/SUPPORTED is older than the releases we are building for
<dpm> pitti, thanks, automation ftw!
<pitti> dpm: so once we have a locale, we run that, and once the LP exports have files for the locale, they'll get shipped
<pitti> dpm: lucid's gdm would need an update as well, but since maverick it doesn't any more either
<pitti> so I'm not aware of anything else that needs to happen for this
<dpm> pitti, ok, but what's the gdm stuff? I'm not sure I can follow that. Why does it need to be updated in Lucid and why does it not need to on Maverick?
<pitti> dpm: in lucid, gdm had its own language/locale list
<dpm> oh, I see
<pitti> doko: FYI, I talked to the debian gnome folks again, and they are ok with doing the pysupport -> dh_py2 transition for pygobject and friends; we'll ship a compatibility symlink until the reverse dependencies were converted, does that sound okay to you?
<doko> \o/ still starting in natty?
<micahg> pitti: was the 0317 langpack supposed to fix the file overwrite issue?
<pitti> micahg: the 0317.1 ones for kde-{oc,es}, yes
<micahg> ok, so I'll wait for the point update
<seb128> zul, hi, do you have a vcs for samba? Could you review and check the fix bug #668368 in if you have one?
<ubottu> Launchpad bug 668368 in samba (Ubuntu) "Default [homes] share template uses incorrect %S macro." [Low,Triaged] https://launchpad.net/bugs/668368
<seb128> it's a one char change, I don't want to an upload for that ;-)
<doko> pitti: ^^^
<pitti> doko: I hope so, I'm working on it right now (it's more complicated than a symlink, though)
<zul> seb128 sure on a call right now
<seb128> zul, no hurry, thanks
<AnAnt> Hello, I get a UnicodeEncodeError message when I try to login on wiki.ubuntu.com, where should I report that ?
<davmor2> AnAnt: goto #canonical-isd as a first port of call
<debfx> kirkland: shouldn't console-setup register /etc/console-setup/vtrgb.vga as an alternative? kubuntu-default-settings could then switch to it if it's in auto mode
<AnAnt> davmor2: thanks
<kirkland> debfx: no, it can't;  otherwise, every time console-setup upgrades it would overwrite the alternative priority that kubuntu-settings sets
<kirkland> debfx: ie, it could register it at a lower priority, say 20
<kirkland> debfx: but every time it upgrades it would re-register it at 20 again
<debfx> kirkland: yes, console-setup would register it with a lower priority and k-d-s runs updater-alternatives --set ... in postinst
<kirkland> debfx: right, but what happens when console-setup upgrades later?
<kirkland> debfx: at least the way i'm calling update-alternatives in console-setup.postinst, it's going to overwrite it
<kirkland> debfx: unless i'm misunderstanding you...
<debfx> kirkland: it's not supposed to overwrite it if it's in manual mode
<debfx> update-alternatives --install is a no-op if the alternative is already installed (with the same priority)
<kirkland> debfx: interesting...
<kirkland> debfx: can you propose a debdiff to console-setup.postinst, test it, and show me how you recommend we do it?
<kirkland> debfx: and newt's postinst too
<kirkland> debfx: note that newt takes about 20 seconds to build, and console-setup takes about 20 minutes
<debfx> kirkland: will do, thanks for the hint :)
<debfx> the tricky part is in k-d-s as update-alternatives doesn't have a --only-if-in-auto-mode option
<kirkland> debfx: sure thing
<kirkland> debfx: i do like the idea of having the originals registered as lower-priority alternatives, such that they're more discoverable
<kirkland> debfx: i just want to make sure it's done in a way that other optional packages (like the kubuntu themes one) can override and make their alternatives stick and maintain across upgrades
<debfx> kirkland: aha, just revert the changes from the last newt upload :)
<kirkland> debfx: okay, if so, then what's the proper syntax for update-alternatives in the kubuntu settings postinst?
<debfx> kirkland: the easiest way would be: update-alternatives --set newt-palette /etc/newt/palette.original
<kirkland> debfx: ah, okay, cool
<jcastro> wendar: there appears to be nothing on Wednesday UDS, if you want to try "fun" lightning talks or something clever, that would be the night to do it
<debfx> but that overwrite all user choices so guarding that with a check if the alternative is in auto mode would be good
<wendar> jcastro: could be fun
<debfx> kirkland: newt doesn't remove the alternatives in postrm
<kirkland> debfx: good catch
<slangasek> kirkland: hi, do you feel like NEWing eglibc today? :)
<kirkland> slangasek: i can have a look ....
<debfx> kirkland: we could use something like this in kubuntu-default-settings: http://paste.ubuntu.com/583394/
<kirkland> slangasek: https://launchpad.net/ubuntu/natty/+queue keeps timing out on me
<slangasek> curses
<kirkland> slangasek: okay, it landed
<kirkland> slangasek: oh, a binary deNEW, that's easier :-)
<kirkland> slangasek: looking now ...
<slangasek> yep, trivial, just a new package added to the base system ;)
<kirkland> slangasek: multiarch support :-)  trivial :-)
<kirkland> slangasek: hmm, http://pastebin.ubuntu.com/583405/
<kirkland> slangasek: there isn't actually anything in that package?
<slangasek> correct
<slangasek> kirkland: let me grab you a link to the explanation
<slangasek> kirkland: https://code.launchpad.net/~vorlon/ubuntu/natty/eglibc/multiarch-support/+merge/54135
<ubottu> Ubuntu bug 54135 in libapache2-mod-python (Ubuntu) "when php5 is enabled mod_python cacls md5 wrong" [Undecided,Invalid]
<kirkland> slangasek: cool, works for me
<kirkland> slangasek: needs to go to main, i presume?
<slangasek> kirkland: yeppers
<slangasek> as Priority: standard, in fact
<slangasek> er, Priority: required even
<slangasek> (but I can poke that once it's in the archive, if there are any issues)
<kirkland> slangasek: OK: eglibc, eglibc_2.13-0ubuntu8_armel_translations.tar.gz(main/(unchanged)/(unchanged))
<kirkland> slangasek: so i missed your priority note
<slangasek> no problem
<kirkland> slangasek: so yeah, poke that once it's in
<slangasek> Laney: how are things with ghc6?  Everything good, now that libffi is fixed?
<Laney> slangasek: Mostly. I see a perplexing failure that I think is due to a newer binutils; mailed d-haskell@ to ask for insight earlier.
<Laney> At least the libffi fix is good.
<Laney> http://launchpadlibrarian.net/66834248/buildlog_ubuntu-natty-amd64.haskell-happstack-util_0.5.0.2-2build2_FAILEDTOBUILD.txt.gz
 * slangasek checks the mail to make sure it's really a binutils bug and not a multiarch bug ;)
<Laney> it's in a library, not ghc6 itself (thankfully)
<kirkland> slangasek: okay, it's taking a few button pushes to get past all the launchpad timeouts for the other arches
<kirkland> slangasek: okay, done
<slangasek> kirkland: your pain is appreciated, as this puts us one package upload away from 'sudo apt-get install flashplugin-installer:i386' working in a chroot :)
<kirkland> slangasek: heh :-)
<slangasek> now to upload glib2.0
<cjwatson> slangasek: 'sudo apt-get install libc6:amd64' doesn't seem to work for me, with a 'deb [arch=i386,amd64] ...' line in sources.list; what am I missing?
<cjwatson> it just says "E: Unable to locate package libc6:amd64"
<slangasek> cjwatson: APT::Architectures { "i386"; "amd64"; }; also, dpkg --foreign-architecture amd64 (can set in /etc/dpkg of course); finally, I think but have not yet confirmed that there's a change in the apt cache format before and after multiarch, requiring rm /var/cache/apt/*cache* && apt-get update to get everything where it's supposed to be
<cjwatson> aha
<cjwatson> (is there user documentation for multiarch yet?)
<slangasek> cjwatson: the UI is still a little rough, probably will remain so for natty as I don't see us turning this on by default - I'll work on user documentation next week
<slangasek> given that today is the first day that it's possible to run that apt-get command against the archive and have it succeed (and only once the NEWed eglibc is published), I didn't want to encourage foot-shooting too early :)
<cjwatson> heh, yeah
<hyperair> ari-tczew: weird, your coredump seems truncated. or so gdb says =\
<cjwatson> slangasek: without flushing the apt cache, 'sudo apt-get install libc6:amd64' now seems to list a reasonably plausible set of things to do
<cjwatson> (this is before your latest eglibc change ...)
<slangasek> cjwatson: right, the cache bit pertains to how Multi-Arch: foreign, Architecture: all packages are handled (which are only an issue once you get a little farther up the stack)
<slangasek> cjwatson: and apt will happily start downloading the packages and only fail when it tries to configure the dependency loop :)
<cjwatson> ok ...
<ari-tczew> hyperair: so what's the conclusion?
<hyperair> ari-tczew: the conclusion is that the coredump is completely useless ^_^
<hyperair> sorry to say
<mterry> slangasek, do you know what the deal with bug 739575 is?
<ubottu> Launchpad bug 739575 in apr-util (Ubuntu) "Bad path in libapr-util-1.la" [Undecided,New] https://launchpad.net/bugs/739575
<mterry> (seb128 promised you would  ;))
<seb128> ;-)
<seb128> that's going to be a fun transition if we need to start rebuild .la in order
<slangasek> mterry: .la files should not reference other .la files in their dependency_libs field (Debian Policy 10.2); see clean-la.mk in gnome-pkg-tools for an example fix
<slangasek> seb128: well, I assumed most packages were already DTRT on this point, since it's in policy... I see I was too optimistic :)
<slangasek> mterry: a quick-n-dirty fix is to just reupload the package that has the broken reference, but that's a bandaid
<Riddell> ev: I got usb-creator built on suse https://build.opensuse.org/project/show?project=home%3Ariddell%3Ausb-creator
<ev> Riddell: that's awesome!
<seb128> slangasek,
<seb128> $ grep [.]la *.la | grep dependency_libs | sed 's#:.*##' | sort | uniq | wc -l
<seb128> 29
<seb128> in /usr/lib on my natty system
<lamont> (etherape:25852): GLib-CRITICAL **: g_ascii_strcasecmp: assertion `s2 != NULL' failed
<lamont> Segmentation fault
<lamont> I'm pretty sure it's not supposed to do that
<mterry> slangasek, well that's the interesting thing, when I rebuilt the package, it stopped referencing the other .la file in its own .la.   It started using -l syntax
<mterry> Not sure how the original path got in there
<slangasek> mterry: <cough> that's because libtool doesn't know to look in the multiarch directories at all for its .la files
<ari-tczew> hyperair: so how can I do with that bug?
<mterry> ah...  so that's a fix by way of a different bug?  :)
 * hyperair shrugs
<lamont> slangasek: I thought that was because libtool is just plain not  your friend
<lamont> kinda like .la files, iirc
<mterry> slangasek, could you rebuild apr-utils for me?  I'm not core-dev atm
 * doko doesn't ask when to start the rebuild test ...
<slangasek> mterry: the .la is the expected behavior with libtool, when the dependent library has a .la of its own; but we really want it to be *empty*, not just switched to use -l
<slangasek> lamont: libtool *isn't* my friend, and I really wish it would stop sending me these messages on LinkedIn
<slangasek> mterry: sure thing
<mterry> :)
<lamont> slangasek: heh
<slangasek> seb128: 29 doesn't seem so bad... :)
<seb128> slangasek, I'm happy that you are not scared about those ;-)
<slangasek> seb128: care to paste me the list of actual lib names?  That way I can bump them proactively :)
<slangasek> seb128: and no, 29 libs uploaded for a trivial .la change, compared to what I've /been/ doing, is not scary at all ;)
<seb128> slangasek, http://paste.ubuntu.com/583439/
<slangasek> seb128: sweet, thanks
<seb128> slangasek, http://paste.ubuntu.com/583442/
<seb128> slangasek, that's the corresponding sources
<seb128> if you prefer that list
<seb128> ups, binaries rather
<seb128> I can do the sources version if you want ;-)
<slangasek> seb128: binaries are fine, no problem
<Keybuk> SpamapS: you realise that there is no benefit to constructive discussion with Lennart, right? ;-)
<Keybuk> his entire reason for even being on the upstart list and IRC channel is simply to be disruptive
<ogra> Keybuk, not to pick up clever ideas ?
<Keybuk> ogra: well, given he generally describes Upstart as "wrong", I doubt that
<SpamapS> Keybuk: I guess I'm like the guy who makes funny faces at the gorillas just to see if they'll fling excrement, event hough everybody has told me thats whats going to happen. ;)
<Keybuk> lol
<Keybuk> actually it's always fun to have more people make funny faces at him
<Keybuk> because then he'll reply that he's tried, and I'm not interested in working together
<Keybuk> and I'll point out that I've repeatedly said that I am, but that I don't consider "working together" to be "do what Lennart says"
<Keybuk> and then I attempt to get him to agree to something
<Keybuk> and he goes silent
<Keybuk> and then turns up with "NAK, I'm doing this differently in systemd" or something
<walters> Keybuk: 1) your movie twitter post was hilarious  2) i think he's doing the right thing; give him a little bit to come up with another approach
<Keybuk> cf. https://bugs.freedesktop.org/show_bug.cgi?id=34526#c1
<ubottu> Freedesktop bug 34526 in core "Support service activation via Upstart" [Enhancement,New]
<SpamapS> Keybuk: I suppose all we can do to counter that is to be open and ask for comments on major changes... since... you know.. there are somewhere around a million more upstart users than systemd.. we should probably ask upstart users before Lennart. ;)
<Keybuk> SpamapS: at Google alone, there is probably 1,000 *times more* upstart installs than there are Fedora installs in the entire world ;-)
<Keybuk> walters: I'm not interesting in Lennart coming up with another approach - I'm interested in Lennart actually discussing with me, and others, what the other approach should be
<walters> sure, so give him a bit of time to post that
<Keybuk> walters: I've given him a year so far; how much more time should I give?
<Keybuk> (the LISTEN_FDS discussion started April last year)
<Keybuk> sadly this approach of "the only valid decision is the one made by the Fedora+SuSE cabal" is starting to infect other projects
<Keybuk> see the recent udev announcement that all systems must support /dev/.run as a tmpfs throughout boot that's later bind-mounted to /var/run
<Keybuk> and then the creation of /run after that
<Keybuk> without, at any point, asking any other distribution - many of which have *already solved this* - what they think the approach should be
<Keybuk> or going via the FHS or some other neutral body
<highvoltage> /run!?
<walters> Keybuk: i'm not involved in that really so i can't comment on it usefully
<Keybuk> lunch, bbl
<Keybuk> omnomnom
<\sh> hmmm..could it be that we are right now in the "Everything what Ubuntu does and did is wrong, nasty, evil and totally useless?" unity vs. gnome-shell, upstart vs. systemd , multi-arch ubuntu vs. multi-arch debian? (WRT http://jackyf.livejournal.com/115703.html)
<broder> \sh: our multiarch spec is the same as debian's
<broder> which is to say, we're using a spec developed at debconf, and for all intents and purposes is a "debian spec", not an "ubuntu spec", but just implementing it sooner
<highvoltage> \sh: nah, Ubuntu does quite a few things really good
<\sh> broder: I thought so, but it sounds different from the post I just read on p.d.o.
<cjwatson> jackyf is several years too late to the party
<broder> \sh: that post is complaining about not understanding the spec that's being implemented
<broder> and suggesting an alternative that they're asserting makes more sense
<ScottK> cjwatson: If their blogging on livejournal, that's a given.
<\sh> broder: I'm just concerned about "bad PR" with regards of the latest happenings
<ScottK> \sh: Bad PR can happen whether you deserve it or not.  I think we should just minimize the deserving it and not worry about the rest.
<ScottK> \sh: It would be interesting to hear about the distros that started transitioning to System D in 2006 when we started our Upstart transition.
<ScottK> Some people don't understand the notion that time move in one direction for most mortals.
<nigelb> kirkland: hey, add a warning to your blog.  The presentation linked on the scale website is wrong :P
<kirkland> nigelb: thanks
<\sh> ScottK: actually I don'
<kirkland> nigelb: i wonder what's up with that
<ScottK> \sh: You don'?
<nigelb> kirkland: I poked Gareth, I figure he'll get it fixed :)
<\sh> 't care about what system we will or others will use...I just want to use the best technique and this technique needs to be supported for a long time
<\sh> moment...phone call
<kirkland> nigelb: cool, thanks
<kirkland> nigelb: any chance you can ask them where my video is?  :-)
<nigelb> kirkland: yup, will do.  I wanna see it too :)
<\sh> back...
<ScottK> \sh: Also keep in mind the author of that blog post decided apt was hopeless and is re-implementing it, so some level if disagreement from that source is not particularly suprising.
<slangasek> yes, reimplementing it in perl
<nigelb> ScottK: heh, lol about livejournal comment :)
<cnd> I'm trying to help someone get their game into Ubuntu, but there are possible issues with media licensing (fonts and audio)
<cnd> the audio files clearly aren't gpl compatible, but I don't know if they really need to be
<cnd> is there some place where these issues can be reviewed?
<ScottK> cnd: We don't require GPL compatiblity.  To get into Universe it needs to be ~DFSG free (was also allow GFDL with invariant sections that Debian doesn't).  To get into Multiverse it just has to be legal to distribute.
<ScottK> cnd: Any archive admin can answer questions, so just ask.
<slangasek> jamespage: any luck with jenkins?
<slangasek> or with openjdk, I should say
<cnd> ScottK, I should have mentioned that the source code is GPL, but here's a merge request with the important information: https://code.launchpad.net/~libavg-team/geneatd/packaging.cleanup/+merge/53538
<ubottu> Ubuntu bug 53538 in samba (Ubuntu) "Not install package (dup-of: 9208)" [Undecided,New]
<ubottu> Ubuntu bug 9208 in gnome-system-tools (Ubuntu) "Samba upgrade failure due to broken rc.d symlinks" [High,Fix released]
<cnd> there's audio files that are CC-sampling 1.0
<cnd> and the game source code is GPLv3+
<ScottK> I'd have to look up that CC license, but IIRC it's problematic to combine those into one work.
<slangasek> however, it's questionable whether a game engine + accompanying audio files are considered "one work"; it depends a lot on the specific license wording
<ScottK> I guess.
<cnd> ScottK, so where do I go from here to get a more definitive answer?
<GatoLoko> hi
<ScottK> cnd: Get the package uploaded to REVU and then one of us archive admins might review it if we have time.  We don't have even a rough equivalent of debian-legal.
#ubuntu-devel 2011-03-22
<errordeveloper> hi
<errordeveloper> i'm getting a problem with ath9k interface
<errordeveloper> just update all packages
<errordeveloper> and installed 2.6.38-7
<errordeveloper> still bloody hangs
<errordeveloper> also I changed from NM to wicd
<errordeveloper> and it persisted
<errordeveloper> (that was the first step I did)
<errordeveloper> any ideas .. ?
<errordeveloper> may be it's not ath9k driver ..
<errordeveloper> i.e. could be something else, hm ..
<errordeveloper> well, it sort of hangs quite badly
<errordeveloper> and then panics
<cnd> ScottK, ok, will do
<ScottK> cnd: Keep in mind anything now is for oneric at the earliest.
<cnd> ScottK, hmmm... ok
<ScottK> errordeveloper: If you are running Natty, you want #ubuntu+1 for help, otherwise #ubuntu.
<ScottK> cnd: We're well past feature freeze.
<cnd> ScottK: we've been working through FFe's
<cnd> they're to highlight some multitouch work
<ScottK> You can always ask.
<cnd> yeah
<cnd> we've got FFe's open for the games
<errordeveloper> ScottK: well, it says devel branch on the vt login prompt
<cnd> one of them has been approved
<cnd> the others are still waiting
<ScottK> Frankly I think the touch people should have planned their work better and got this stuff done on time.
<ScottK> errordeveloper: #ubuntu+1 then.
<errordeveloper> ScottK: tbh, I am having big issue with #ubuntu channel, they just drive me crazy
<errordeveloper> ok, shall check +1
<errordeveloper> :)
<ScottK> errordeveloper: That doesn't make this a support channel.
<errordeveloper> ScottK: that wasn't my intention
<ScottK> OK
<errordeveloper> I wanted to sort of check if anyone here know of ath9k issue or anything related
<cnd> ScottK, I understand the sentiment, though I think if you had a peek behind the curtain you might understand why things are the way they are
<ScottK> cnd: Then they should have planned less.
<errordeveloper> there plenty of commits on linux-wireless
<ScottK> We have feature freeze for a reason and I don't think landing large chunks of work afterwards is a great idea.
<errordeveloper> oh, by the this devel branch make like ubuntu, ..
<errordeveloper> well, I hasn't been a big fun tbh
<cnd> ScottK, there are a few outliers
<cnd> but by and large, our large code was all landed before FF
<errordeveloper> and now seeing where you guys heading, (dropping off gnome) etc
<cnd> these are just some games that the community has developed, for example
<ScottK> The stuff that didn't seems to be a rather large fraction of the FFe's we're getting, but I could be wrong.  It's not like I'm counting.
<ScottK> errordeveloper: Desktop specific development work for Unity would be in #ubuntu-desktop or #ayatana.
<errordeveloper> I only said that I like, and that had been a complement to all of you guys  :)
<cnd> ScottK, I have no clue how many FFe's you guys get, nor what is considered "reasonable"
<cnd> all we can go by is that a wiki page says there's a process
<cnd> and we've tried to follow the process to the letter
<cnd> if you feel we're unreasonable, then feel free to start denying
<cnd> we are ok with that
<ScottK> What I've been doing is not approving them.
<ohsix> is the multitouch stuff the thing causing the enormous input latency and precision slowdown in natty? my touchpad is going nuts too, random right clicks (even from pressing the left click hard button)
<ScottK> If other team members think they're OK, I don't feel a need to block it.
<ohsix> multitouch or gestures
<cnd> ohsix, we've not seen any bug reports about those issues
<ohsix> ok
<ohsix> thanks
<cnd> there could be something there
<ScottK> ohsix: This means you should file one.
<cnd> yeah
<ohsix> ya i get it ;]
<ScottK> (not go away, it's not a problem)
<ohsix> there was touchpad slowness during the mav beta too; but it was fixed, by what, i do not know
<cnd> though I can't think of what would cause random right clicks
<ohsix> well they're not random, but in place of left clicks, probably 30% of them
<cnd> ohsix, the new natty kernel has multitouch enabled for some synaptics trackpads
<cnd> and it could be causing some issues
<ohsix> hm k
<cnd> ohsix, do you have a dell mini?
<ohsix> i know mine doesn't have any features for multitouch, from messing with it ages ago; i'll have to look into that
<cnd> ohsix, then there's near 0% chance it has anything to do with multitouch/gestures
<ohsix> nope, compaq cq60, the netbook i do have doesn't have any input problems with respect to the touchpad, neither speed or wrong button events
<cnd> (can't be sure it's 0% chance though :)
<ohsix> wait a minute  ...
<ohsix> if i tap with 2 fingers it reliably delivers a right click
<ohsix> and occasionally does it with one fat finger
<ohsix> well that explains that
<ohsix> first place i looked when i was trying to change the sensitivity or other settings that might be new, was the mouse applet; but it still has the options it's had for ages in the touchpad page
<ohsix> all this fancy stuff is great, but i'd like my touchpad disable button to work again some day :D
<ohsix> would the component for reporting all these things basically be the kernel?
<ohsix> the misclicks seem to be rooted in the fact that my touchpad only reports one point, but there are sensitity/area settings to fake it, by assuming over a certain size is 2 fingers; if i enable 2 finger scrolling i can do the same thing with a fat finger
<cnd> ohsix, there are knobs you can configure for these issues
<ohsix> xinput list-props has some new things for the acceleration profiles too
<cnd> they just aren't exposed by default
<ohsix> that might be the slowness
<cnd> yeah, xinput list-props
<cnd> sometimes the defaults change for those knobs upstream too
<cnd> one change in natty is the addition of kinetic scrolling
<ohsix> as far as i know it could only ever be faked for this touchpad, the 2 finger stuff shouldn't even be displayed because it takes hairy manual setup, and can change with temperature and humidity D: (fingers get fatter, static settings to emulate stuff don't work reliably)
<cnd> ohsix, you can turn off the two finger stuff in the mouse preferences
<cnd> so it doesn't do two finger right click or scrolling
<ohsix> that's just the thing, ic an disable 2 finger _scrolling_ but the 2 finger click is new, and isn't in there
<cnd> oh, I think you're right
<cnd> there's no option to enable/disable it in the prefs
<ohsix> though i didn't know before a few minutes ago that the misclicks were actually 2 finger clicks in disguise :D (i use my touchpad rather sloppily on occasion)
<cnd> heh
<ohsix> using the thumb just to deliver a click when you don't need to move the mouse usually registers as 2 fingers
<ohsix> theres sensitive area around the hard buttons on t his laptop too, so resting your fingers anywhere near it causes fatfinger right clicks as well
<ohsix> one thing xinput doesn't display, or seem to know; is that theres a protocol level flag that says wether a device can do more than one point reliably, i confirmed a while ago that mine can only do one point; seems to me that a default that involves 2 finger anything could be picked properly if that info was there
<cnd> ohsix, yeah, there's a protocol flag
<cnd> but you wouldn't be getting any multifinger data if that flag wasn't set
<cnd> that's my understanding at least
<ohsix> it's not getting multifinger info persay; but the driver, last time i looked; would use a contact area number/heuristic to infer if 2 fingers were on the touchpad, to do 2 finger scrolling (as i said, 2 finger click is new)
<ohsix> it does the same for palm detection to disable mouse movements for input over a certain area
<cnd> ohsix, oh right, I remember that now
<ohsix> it sends the click, not the 2 point events
<cnd> yeah, so you don't have multifinger, but just a touch size
<cnd> there's too many iterations of synaptics hardware :)
<cnd> ohsix, I haven't been working on synaptics too much for non-multitouch hardware
<cnd> but I haven't heard anyone else complain about how it works
<cnd> I'm sure others have
<cnd> but it's not reached a noticeable threshold for someone who works in that area of the code
<ohsix> alright
<ohsix> the reason i was looking back then in the first place, was to try 2 finger scrolling; which _sort of_ worked in a usable manner with the windows drivers, but i found out in the end that it was faked and if i wanted to use it i'd have to deal with it being tempermental
<cnd> ohsix, I'm not sure how best to try to make that noticeable though :(
<ohsix> and back then there was no checkbox in the mouse applet to just turn on 2 finger scrolling, had to do it with xinput set-prop
<cnd> it's not like there's an easy way to say "if your trackpad sucks in just this way too, hit this button"
<ohsix> yea :\
<ohsix> if xinput knew how many fingers it could report (or does it? and it's implied it does if the prop isn't present indicating how many points?) it could show the ui for the stuff, though 2 finger click and 2 finger scroll still might be desirable if the touchpad or its driver can fake it :\
<ohsix> picking 2 finger anything by default for one of the area heuristic touchpads is already annoying me though :P
<ohsix> not sure how to file a straight up bug, need to file 2, one is the acceleration profile is wrong for this touchpad, and the other is the 2 finger clicking thing
<cnd> ohsix, that sounds good
<cnd> ohsix, you should search to see if anyone already has a similar bug report for either issue
<ohsix> good idea
<ohsix> apport should offer a choice for input problems with "linux" and the default stuff (the one that lets you pick X.org, after you do you can only pick display and stuff, should have input :D)
<cnd> yeah
<ScottK> slangasek: Does "/usr/bin/ld: cannot find crti.o: No such file or directory" seem like it might be multi-arch related?
<ScottK> (libc6-dev is installed)
<ohsix> yes
<ohsix> crti is one of the startup stubs you need to link executables, not being able to find it cuz of the arch path is likely
<ohsix> (though i haven't been following close, afaiu the paths are being changed to arch tuples and such a thing would be moved into one of them)
<ohsix> cnd: should i file everything against "linux"? i wanna file one for my touchpad disable key, but i'm not sure what happens after X gets ahold of it and if it's more appropriate
<cnd> ohsix, you can file against xserver-xorg-input-synaptics
<cnd> it doesn't really belong against the linux package
<ohsix> ok
<cnd> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: smoser
<pitti> Good morning
 * slangasek waves
<ohsix> where do i read this "Policy 10.2" that i keep seeing mentioned
<didrocks> good morning
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, good morning
<tkamppeter> pitti, I have sent you an e-mail. It is an error_log from trying to use the CUPS web interface on a fresh standard installation of Natty. Looks like there is a PAM problem.
<pitti> tkamppeter: the PAM libraries moved during the multiarch transition indeed
<pitti> tkamppeter: from /lib/security to e. g. /lib/x86_64-linux-gnu/security/
<pitti> tkamppeter: does cups assume that they are in /lib/security, for dlopen()ing them? if it only uses libpam, it shouldn't even notice
<slangasek> cups probably needs to be restarted after the library is upgraded
<slangasek> libpam0g has code to handle this, but I didn't think to bump the version check for the multiarch move
<pitti> slangasek: that even happens after a reboot, though
<slangasek> oh?
<slangasek> is there a bug report about this?
<pitti> I can reproduce it as well; http://localhost:631 doesn't accept my password
<pitti> slangasek: not sure, I just saw tkamppeter's email about it a few minutes ago
<pitti> I'm currently trying a no-change rebuild, just in case it checks pkg-config etc.
<slangasek> no, cupsd is linked to libpam, and libpam does the lookups against the path
<tkamppeter> pitti, for me tyhe web interface worked yesterday, I am currently updating my system ...
<dholbach> good morning
<pitti> I don't see a relevant dlopen() either
<pitti> hey dholbach, guten Morgen
<tkamppeter> pitti, can it be that the guy does not have libpam-modules installed?
<dholbach> hey pitti
<pitti> tkamppeter: unlikely; it's pretty much impossible to remove it without shredding your system
<pitti> tkamppeter: also, I can reproduce it here as well, and I do have it
<slangasek> it is possible to have upgraded libpam-modules without upgrading libpam0g
<slangasek> I'll fix that
<slangasek> and the restart issue
<slangasek> but I don't know if either of those explains the bug in question
<pitti> I didn't do a partial upgrade
<pitti> both are version 1.1.2-2ubuntu4
<tkamppeter> pitti, slangasek: The web interface still worked for me with 2ubuntu3.
<slangasek> oh, /usr/lib/cups/cgi-bin/admin.cgi is a separate process and is not linked against libpam, hmm
<pitti> tkamppeter: ok, it's not just a rebuild; I'll check out admin.cgi later on, when I'm done with my current task
<pitti> shouldn't be hard to fix
<tkamppeter> pitti, OK.
<slangasek> blast, my glib2.0 changes didn't make it to the repo and have been clobbered :(
<mr_pouit> yep, robert overwrites everything if it's not in bzr ;D (he did the same to me for some xscreensaver changes ;p)
<slangasek> what's sad is that I did all my work in bzr, and just failed to push
<lifeless> slangasek: then its on your local disk, yea?
<slangasek> yes
<slangasek> but it's still a waste of buildd time
<slangasek> and it means I currently can't dist-upgrade my multiarch chroot :)
<pitti> doko_: is there a command which outputs /usr/lib/python2.5/site-packages/ vs. /usr/lib/python2.6/dist-packages/, so that I do not have to do the version comparison and hardcoding these paths in debian/rules?
<tkamppeter> pitti, slangasek, my system update has completed and the CUPS web interface still works for me.
<pitti> tkamppeter: even after a reboot, or restarting cups?
<slangasek> tkamppeter: ok.  interestingly, I can reproduce the failure here, but I don't understand it at all :)
<tkamppeter> pitti, the update included CUPS, so it must have been restarted, but I will restart it again.
<doko_> pitti: /usr/share/python{,3}/python.mk
<tkamppeter> pitti, browser is Firefox 4.0 final ...
<pitti> doko_: ah, thanks
<tkamppeter> pitti, CUPS restarted, browser restarted, still works.
<pitti> strange
<pitti> doko: do I use py_sitename_sh with $(call) as well?
<doko> pitti: afaics, yes
<pitti> doko: cool, that works; thanks!
<debfx> slangasek: oh dear, multiarch makes gcc-3.3 (libstdc++5) ftbfs
<debfx> I guess it needs to be patched to search in the new lib dirs
<cjwatson> ohsix: google for debian policy manual
<ohsix> ah i thought it was a version, not a section in something
<debfx> kirkland: are you going to upload newt? kubuntu-d-s fails to install when palette.original isn't registered
<jamespage> Morning all
<jamespage> Does dlopen() required a fully versioned library name or should it work with 'libpam.so' for example?
<Chipzz> jamespage: the latter I think
<Chipzz> I see no reason why it shouldn't work
<jamespage> Chipzz: Hmmm - thats what I thought
<jamespage> don't appear to be getting that behaviour (although it is a little hard to tell as sitting behind a java native access bridge)
<cjwatson> 'man dlopen' documents what's supposed to work
<cjwatson> (though the last point in its bullet list may need to be updated for multiarch)
<jamespage> cjwatson: yeah - I've read that a few times; ldconfig -p contains libpam.so.0 but not libpam.so so I don't think it will work
<cjwatson> $ ldconfig -p | grep libpam.so
<cjwatson>         libpam.so.0 (libc6) => /lib/i386-linux-gnu/libpam.so.0
<cjwatson>         libpam.so (libc6) => /usr/lib/libpam.so
<cjwatson> dlopening libpam.so is only going to work if the -dev package is installed; for runtime use, it'll need to be 'libpam.so.0'
<jamespage> cjwatson: thanks - could be challenging
<jamespage> the Java library that I'm looking at tries to guess without a version number
<jamespage> if it can't find it it then searchs a path which is currently not multi-arch compatible - hence it can't file the library.
<jamespage> /file/find
<mdz> didrocks, can you check into bug 723056 for me? I responded with the requested info but haven't heard back from the person you assigned
<ubottu> Launchpad bug 723056 in compiz (Ubuntu) ""Toggle whether a window is on all workspaces" shortcut no longer works" [Medium,Confirmed] https://launchpad.net/bugs/723056
<didrocks> mdz: looking at it
<mdz> didrocks, thanks
<didrocks> mdz: yeah, I asked sam to have a look. Will ping him again :)
<pitti> ugh, what happened yesterday to grow desktop CDs by 50 MB..
<pitti> +eglibc-source 2.13-0ubuntu8
<ogra_> fun
<pitti> +glibc-doc 2.13-0ubuntu8
<ogra_> finally you can build your own libc right after install !
<pitti> and we got -dbg, -pic, -prof, and -xen as well
<pitti> and -amd64 on i386
 * pitti files bug 740124 about it
<ubottu> Launchpad bug 740124 in eglibc (Ubuntu) "2.13-0ubuntu8 grew a lot of extra dependencies, causing CD explosion" [Undecided,New] https://launchpad.net/bugs/740124
<abhinav-away> pitti, I have pushed a branch for bug-340970 but I did not propose it for merging as I was not able to make it run. the code for checking obsolete packages doesn't seem to be getting triggered. I think this feature wont be merged in this release anyways
<abhinav-away> https://code.launchpad.net/~er-abhinav-upadhyay/apport/bug-340970
<cjwatson> pitti: it may just be busted priorities
<cjwatson> I'll check germinate output
<cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt certainly has a slew of stuff, suggesting incorrect NEW processing
<Riddell> ev: hmm, usb-creator on suse doesn't want to work http://susepaste.org/48914863
<pitti> cjwatson: ah, interesting
<pitti> cjwatson: the required->optional list is exactly the list of extra packages
<cjwatson> yes
<cjwatson> fixed
<pitti> cool, thanks
<ev> Riddell: what happens if you manually spawn /usr/share/usb-creator/usb-creator-helper?
<ev> as root
<Riddell> ev: ImportError: No module named gobject
<Riddell> hmm, possible dependency issue
<ev> yeah, it needs gobject for the main loop
<Riddell> ev: seems to be working now
<ev> yay
<bdrung> kenvandine: Breaks & Replaces should be used instead of Conflicts & Replaces if the conflicting package is versioned
<bdrung> kenvandine: synaptic fail to find a proper upgrade path for gstreamer-plugins-{good,bad}
<Riddell> ev: failed at the last task  http://paste.opensuse.org/79402602
<ev> Riddell: make sure you have /usr/lib/syslinux/mbr.bin and /sbin/parted
<ev> also, kill any running usb-creator-helper
<ev> and run it manually in a shell with sudo /usr/share/usb-creator/usb-creator-helper, which should produce some sort of crash when you hit bootloader installation again
<Riddell> ev: I have /usr/sbin/parted
<ev> ah, usb-creator assumes it's in /sbin
<Riddell> ev: and /usr/share/syslinux/mbr.bin
<Riddell> ok trying with those modified in the source
<Riddell> ev: well, some progress http://paste.opensuse.org/6716340
<Riddell> ev: do you know what package supplies python lsb_release in ubuntu?
<ev> lsb-release
<Riddell> clever
<ev> :)
<oubiwann> cjwatson: congrats on multiarch!
<cjwatson> oubiwann: congratulations should go to slangasek - he's been driving it
<oubiwann> slangasek: congrats!!!
<oubiwann> cjwatson: thanks :-) I'd assumed you were still on it, from last year!
<cjwatson> only poking at the odd thing from the sidelines
<cjwatson> and trying not to get in the way :-)
<ogra> cjwatson, fyi, properly preseeding debian-installer/framebuffer=false finally works ... but i needed to actually implement preseeding in jasper through debconf-communicate (nice sideeffect)
<ogra> sadly its close to unusable, the terminal is pretty screwed up
<cdbs> dholbach: hi, could you re-add me to sponsors? ~bilalakhtar Thanks!
<ogra> (i cant see what is selected)
<cjwatson> ogra: as I said, it was more to narrow down where the problem was than a serious workaround suggestion
<cjwatson> ogra: remind me of the bug number?
 * ogra digs
<ogra> bug 736111
<ubottu> Launchpad bug 736111 in ubiquity (Ubuntu Natty) "oem-config does not respect the console on serial tty" [High,New] https://launchpad.net/bugs/736111
<ogra> cjwatson, well i have preseeding support in jasper now and we want the option to be user switchable on cmdline
<ogra> so its not bad to have it that way
<cjwatson> I suspect that it is not tty1 that's hardcoded, but /dev/fb0
<ogra> bah, but i have no user
<ogra> funnily the new hostname is set
 * ogra wonders what failed there
<OdyX> ScottK: we are next week now; what about FFE'ing the pyside stack ?
<cjwatson> ogra: commented.  just to be clear, I don't expect the main installer team to be able to deal with this, other than by offering advice
<ogra> cjwatson, well, i'm happy we have a wrokaround for the short term
<ogra> i'll try to add the fronend stuff somehow
<ScottK> OdyX: Did you file the bugs?
<ogra> *front
<OdyX> ScottK: Nope. Will do then.
<cjwatson> ogra: well ... see my more recent comment :)
<ScottK> OdyX: FFe is only needed if there are feature differences between what's in Debian and what we have now.  If not, a regular sync request will do.
<ogra> cjwatson, will add some screenshots ... though first i want to find out why i have no user
<OdyX> ScottK: thing is I don't know what the status of pyside under armel is (as it is BD-Uninstallable in Debian, waiting on qtwebkit4)
<ogra> cjwatson, its also weird that while i have the caption "Installing packages..." the text inside the screen is "Ready when you are" and nothing more ... right afterwards it switches to debconf package removal
<ScottK> OdyX: Not a problem.
<OdyX> ScottK: would it be possible to get a natty armel build of PySide ?
<evdvelde> hi all, how stable will btrfs be in 11.04?
<ScottK> OdyX: we'd have to fix apiextractor to build first (symbols issues, IIRC).
<OdyX> ScottK: I removed the symbols tracking now (see 0.10.0-4)
<ScottK> OK.
<OdyX> ScottK: status in Debian is: https://buildd.debian.org/status/package.php?p=qt4-x11%2Cqtwebkit%2Chorizontal-void-line%2Capiextractor%2Cgeneratorrunner%2Cshiboken%2Cpyside&suite=sid&compact=compact
<ScottK> I'm familiar with the qtwebkit issues in Debian as my python-qt4 upload is waiting for them to be resovled as well.
<cjwatson> ogra: sure, I expect that the dual-debconf-stack code in the installer doesn't deal perfectly with the fallback case to a plain debconf frontend
<OdyX> yeah, right.
<cjwatson> ogra: some fixing there is no doubt required
<ogra> yup
<ScottK> OdyX: Let's get apiextractor sync'ed then.  Can you file a sync request for that?
<OdyX> filing
<OdyX> ScottK: we need the whole chain anyway.
<ScottK> OK.
<OdyX> ScottK: four sync request mailed
<Riddell> ev: what does usb-creator use the lsb-release python module for?  suse doesn't support it
<Riddell> it's easy enough to patch but I don't want to break anything
<ev> Riddell: to somewhat deal with the incompatible versions of syslinux problem
<Riddell> mm, so I should just hard code it to the appropriate version
<ev> see http://bugs.launchpad.net/bugs/608382 for the hairy details
<ubottu> Ubuntu bug 608382 in usb-creator (Ubuntu Karmic) "Maverick images burned to usb key on lucid fail to boot - different syslinux version" [High,Triaged]
<ev> I was hoping to solve this with some MBR trickery a la isohybrid, but ran out of time in natty
<kirkland> debfx: sure
<ogra> cjwatson, bug 740183 for the missing user
<ubottu> Launchpad bug 740183 in ubiquity (Ubuntu Natty) "oem-config in debconf mode under serial console does not create a user" [High,New] https://launchpad.net/bugs/740183
<kirkland> debfx: done!
<psusi> cjwatson: I was trying to fix a bug where users can't install to a dmraid raid10.  I set up a qemu on an emulated 4 disk raid10.  The installer only presends /dev/mapper/foo-0 and -1 as targets, which are actually subsets of the main array, foo.  How does it decide what to show and what not to?
<cjwatson> psusi: grab the partman-base source package and look in init.d/parted and parted_devices.c
<psusi> hrm... ok
<debfx> kirkland: thanks
<kirkland> debfx: you got it;  thanks for the approach, that's much nicer
<psusi> cjwatson: it looks like this asks parted for a list of all devices, then does some custom filtering on them... shouldn't either parted already avoid returning those devices, or the filtering be based on udev attributes rather than lower level poking about?
<cjwatson> psusi: I don't think parted should change, but feel free to submit a branch to improve the filtering
<psusi> cjwatson: hrm.. ok...
<cjwatson> (if that's what the problem is)
<mr_pouit> kirkland: http://lionel.lefolgoc.net/misc/ceci_est_une_aubergine.png (with xfce4-terminal and dialog, and sudo dpkg-reconfigure debconf)
<mr_pouit> kirkland: I don't know if that's expected, but if I ever see an aubergine like that, I'll tell you ;-)
<mr_pouit> apart from gnome-terminal, all other terms I tried showed this ugly color
<ogra> wow, readline is a painful frontend on 80x24
<ogra> cjwatson, hmm adding debug doesnt produce /var/log/installer/debug ... weird
<cjwatson> ogra: oh, it may just make /var/log/oem-config.log more verbose
<ogra> ah, yeah
<ogra> i was checking syslog
<ogra> cjwatson, k, attachede to the bug
<ogra> *attached
<ogra> ah
 * ogra sees open /dev/tty: No such device or address
<ogra> Failed to open terminal.debconf: whiptail output the above errors, giving up!
<ogra> but i dont think that should affect the user creation
<cjwatson> ogra: does it ask you for a username?
<ogra> yes
<cjwatson> ok, good
<cjwatson> I saw that in the log and wanted to check
<ogra> seems all correct from an UI POV
<cjwatson> so the problem is just that we need to suppress the dual-debconf-stack stuff when using the debconf frontend
<ogra> there seem to be readline realted errors at the very end but nothing around the time it should apply the debconf settings
<cjwatson> actually, hmm, it might in fact be that plugininstall is never run for the debconf frontend
<cjwatson> that's believable from the code
<ogra> ouch
<cjwatson> not desperately ouch, it should be easy to correct
<ogra> weird is that every other bit seems to have run
<ogra> i.e. as i said, i have a proper new hostname
<bcurtiswx> slangasek,  http://paste.ubuntu.com/583809/ http://paste.ubuntu.com/583810/
<bcurtiswx> left is errors, right is build deps.  Said you might know about recent issues with building
<cjwatson> ogra: sure, anything that's not in install plugins should have worked
<cjwatson> that's not weird
<ogra> ah, i thought plugininstall applies everything
<cjwatson> well, hostname actually *is* in plugininstall - but maybe I'm missing something, I don't think that angle is worth pursuing for the moment
<sforshee> is there any key code that userspace interprets as "rotate display orientation" ?
<ion> Heh. Apport adds to my bug reports: UpgradeStatus: Upgraded to natty on 2009-06-11 (649 days ago)
<sforshee> I haven't found anything that looks appropriate
<Riddell> siretart: what's the crack with libav?  ffmpeg forked?
<Riddell> siretart: is there really not ment to be any sources in libav-extra?
<bjf> pitti, dapper kernels look like they got fully tested so can go to -updates  (no rush on this)
<siretart> Riddell: indeed, I'm replacing ffmpeg with libav, that's on purpose
<siretart> Riddell: and yes, libav now builds a 'libav-source' package, on which libav-extra build depends
<siretart> Riddell: this makes updates to the -extra packages easier
<Riddell> siretart: so ffmpeg and ffmpeg-extra source should be removed?
<siretart> Riddell: yes, they should
<siretart> with libav going to main and libav-extra to multiverse
<siretart> exactly like ffmpeg/ffmpeg-extra
<Riddell> siretart: why is libav-extra in multiverse?
<siretart> because of its build dependencies
<Riddell> siretart: groovy, accepted
<siretart> \o/ - thanks a lot
<pitti> hey bjf
<pitti> bjf: yup, will move them ASAP
<bjf> pitty, thanks
<tkamppeter> pitti, any news about PAM?
<pitti> tkamppeter: just finished my previous task, catching up
<Riddell> tjaalton: what are you expecting to happen with bug 735602 ?
<ubottu> Launchpad bug 735602 in Ubuntu "FFE: add xinput-calibrate to natty" [Undecided,New] https://launchpad.net/bugs/735602
<ogra> oh, cool
<tjaalton> Riddell: asked for feedback on debian-x@
<tjaalton> upstream said to fix some bugs
 * ogra smells working touchscreen calibration
<Riddell> tjaalton: there doesn't seem to be any archive admin tasks so I'll unsubscribe ubuntu-archive
<tjaalton> ogra: yeah, you should test it :)
<tjaalton> Riddell: yeah
<pitti> kees, jdstrand: publishing dapper kernel to -u/-s: linux-source-2.6.15 linux-backports-modules-2.6.15  linux-meta
<ogra> tjaalton, if i find the time i will
<ogra> i dont even know if my touchscreen works at all in natty, havent tested it since upgrading
<micahg> smoser: you're still listed as a pilot BTW
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: micahg, smoser
 * dholbach hugs micahg
 * micahg hugs dholbach 
<cyphermox> hi, could someone please do a no-change rebuild of udev, libgudev seems to have the old paths for the libgobject-2.0.la file, which would now be in a different path (since it was rebuilt for multiarch support)
<micahg> cyphermox: whichever .la file is providing that needs to be emptied
<bjf> pitti, there is now a linux-meta-ec2-2.6.32.315.16 in our ppa ready for -proposed
<micahg> cyphermox: err, dependency_libs needs to be emptied
<kees> pitti: 10-4, thanks
<cyphermox> micahg, heh, whatever works. there's probably a reason why it's not empty though. I'd think udev was looked at early on when cleaning up la files / dependency_libs
<pitti> kees: "10-4"? perhaps you mean 10-3.94? :-)
<kees> pitti: sorry, using tencodes. :) http://en.wikipedia.org/wiki/Ten-code
<Riddell> sladen: what are you expecting ubuntu-archive to do with bug 736502 ?
<ubottu> Launchpad bug 736502 in ubuntu-font-family-sources (Ubuntu) "FFe: New upstream version Ubuntu Font Family 0.71.2" [Wishlist,New] https://launchpad.net/bugs/736502
<pitti> kees: clearly too 1337 for me ;)
<kees> pitti: heh, nah, just a north americanism. 10-4 just means "affirmative"
<pitti> kees: but it was sooo close to 10-3.96 :)
<pitti> erm, 3.94
<mdeslaur> slangasek: so, I'm a bit concerned that we'll be shipping a lot of stuff in natty that FTBFS because of multiarch, which will complicate things for security updates
<mdeslaur> slangasek: is there a plan for a rebuild test and fixing all the FTBFS before release?
<sladen> Riddell: meh.  ubuntu-archive -> ubuntu-release.  Can you unsub -release
<ogra> cjwatson, ok, seems if i run minicom with TERM=vt100 the dislog frontend is ok (i get a cursor) just doesnt seem to work with xterm or linux
<micahg> cyphermox: it's probably liborbit2-dev, so take a look at what I did for gtkglext or look at clean-la.mk in gnome-pkg-tools
<pitti> bjf: there's also an l-b-m linux-backports-modules-2.6.32
<pitti> bjf: and linux-backports-modules-2.6.35; shoudl they wait, or go as well?
<ogra> *dialog
<seb128> micahg, slangasek cleaned the orbit .la yesterday
<seb128> micahg, what issue do you have?
<bjf> pitti, looking
<bjf> pitti, yes, those should go out as well, thanks for catching that
<micahg> seb128: cyphermox was having an issue with something
<cyphermox> seb128, nm ftbfs because libgudev still have /usr/lib/ as a path to the gobject .la file
<seb128> that's the bug elmo filed that we were discussing on #ubuntu-desktop before
<seb128> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/740224
<ubottu> Ubuntu bug 740224 in udev (Ubuntu) "libgudev-1.0.la has broken dependency_libs (hardcoded /usr/lib)" [Undecided,New]
<pitti> bjf: /me pats http://people.canonical.com/~ubuntu-archive/pending-sru.html#kernelppa :)
<micahg> oh, the problem is in udev then :_)
<cyphermox> seb128, weird, no change here, jsut rebuilding and it's fine on amd64
 * micahg thought the problem was udev building, not nm...
<seb128> check with slangasek
<cyphermox> micahg, sorry, I wasn't clear enough, my bad :)
<seb128> the uploads he did yesterday clean the .la dependencies
<pitti> bjf: ok, so all PPA packages should be in -proposed now
<bjf> pitti, many thanks
<cjwatson> seb128: can we make sure that we get bug 736159 released before beta?  it looks like it's affecting boot performance regression analysis
<ubottu> Launchpad bug 736159 in gsettings-desktop-schemas (Ubuntu) "gsettings-data-convert crashed with sigabrt in g_object_newv()" [Medium,Fix committed] https://launchpad.net/bugs/736159
<pitti> dpm: FYI, disabling natty langpack cron job and requesting full export for Friday, for beta-1
<dpm> ok, thanks pitti
<shadeslayer> dholbach: any particular reason i don't see you in #gsoc ? :D ( they're explaining why orgs didn't make it this year )
<dholbach> shadeslayer, I just joined - I thought that it was obvious enough (417 orgs applying, 175 accepted, 25 more accepted than last time, 50 new ones)
<shadeslayer> dholbach: well ...a explanation ( even if it's of 2 lines ) would be great :)
<shadeslayer> so that we can improve next year ( if it happens again )
 * dholbach nods
<shadeslayer> dholbach: i think you need to be in #gsoc-rejects too
<dholbach> thanks shadeslayer
<slangasek> mdeslaur: FTBFS> yes, my understanding is that doko is planning to snapshot the archive soon for a rebuild test
<mdeslaur> slangasek: ok, thanks
 * doko is just waiting for slangasek to tell that multilib is in a somehow buildable state
<slangasek> cyphermox: udev> blast, I missed that because my search was only against the .la files that were themselves in /usr/lib (!).  Did someone else get this for you, or does udev still need a rebuild?
<elmo> slangasek: http://paste.ubuntu.com/583877/ is the patch I'm testing
<elmo> fwiw
<elmo> it mimics the gnome-pkg-tools clean-la.mk a little closer
<elmo> although the $(wildcard ...) stuff didn't  work for me
<slangasek> ScottK: hi, sorry, apparently I missed a comment from you earlier that I'm catching now in scrollback.  ld cannot find crti.o - that's definitely multiarch related, is this bug #737887 or are you running into this in another context?
<ubottu> Launchpad bug 737887 in gcc-4.4 (Ubuntu Natty) "binutils/binutils-multiarch file conflict" [High,Fix released] https://launchpad.net/bugs/737887
<slangasek> debfx: gcc-3.3 will need patched, yes
<slangasek> jamespage: it's 100% wrong for java to dlopen('libpam.so') instead of 'libpam.so.0'.  If the ABI changes, all bets are off for what symbols you'll find - and the soname of libpam has never changed on Linux!
<slangasek> kirkland: fyi, bug #740124 might have had to do with your new'ing of eglibc?
<ubottu> Launchpad bug 740124 in eglibc (Ubuntu Natty) "2.13-0ubuntu8 grew a lot of extra dependencies, causing CD explosion" [High,Fix released] https://launchpad.net/bugs/740124
<slangasek> bcurtiswx: telepathy-glib> thanks, definitely looks like a multiarch issue; though I thought I was very careful not to move the gir files around, so I'm going to have to dig to understand this
<bcurtiswx> slangasek, OK, thx :)
<slangasek> bcurtiswx: can you confirm the GLib typeinterface is still where it was before the upgrade?
<bcurtiswx> slangasek, i performed a build on the current natty release, and it fails at that point as well
<bcurtiswx> slangasek, so that would make me think it was once there
<slangasek> doko: oh, yes, aside from a few bumps with glib right now, things are good - shall I ping you for the rebuild once this is settled?
<seb128> bcurtiswx, dpkg -L gir1.2-glib-2.0 | grep GLib
<slangasek> elmo: yes, the gratuitous $(wildcard) stuff evaluates the wildcard when the rule is invoked so doesn't pick up on any files created during the running of that rule.  BTW, I see that the second chunk is redundant, obviously find debian/tmp/usr/lib finds stuff in subdirs too
<bcurtiswx> slangasek, bcurtis@weather:~$ dpkg -L gir1.2-glib-2.0 | grep GLib     /usr/lib/girepository-1.0/GLib-2.0.typelib
<seb128> slangasek, ^ so yeah seems it's still at the same location
<slangasek> bcurtiswx, seb128 yep, digging deeper
<elmo> slangasek: ah, I see
<elmo> so - hey, udd says natty is at 165-0ubuntu2 - what am I missing?
<elmo> sorry, natty udev
<slangasek> http://package-import.ubuntu.com/status/udev.html#2011-03-15%2021:02:25.173640 :(
<seb128> elmo, the import job is likely not working for some reason
<seb128> some reason being what slangasek just indicated ;-)
<slangasek> elmo: there's a separate maintained bzr branch for udev at lp:~ubuntu-core-dev/ubuntu/natty/udev/ubuntu, it seems
<slangasek> (which is the one I touched when multiarching libudev)
<elmo> slangasek: ok
<slangasek> pitti: how did cups shake out?
<pitti> slangasek: still in my queue, sorry; had some other long tasks to work on before
<pitti> but I'll get to it asap
<slangasek> pitti: no hurry - just wondering if there's anything there I should be adding to my tasklist this morning :)
<pitti> slangasek: not yet, I think; I might need to come back to you with some questions, but right now this looks both well-defined and reproducible
<slangasek> ok
<bambee> http://paste.ubuntu.com/583892/  <--- update-alternatives issue with console-setup
<bambee> (I can be wrong)
<elmo> hmm wow, I hope that MP didn't just spam ubuntu-core-dev
<elmo> I have a horrible feeling it did
<elmo> (this UDD thing is a little rough around the edges)
<elmo> slangasek: anyway, there's a branch up on the bug, that fixes the unnecessary second loop thing.  I realise it's beyond trivial for you to fix yourself, I was mostly just experimenting with UDD, so feel free to ignore that
<slangasek> it shouldn't spam core-dev, fwiw :)
<slangasek> thanks, I'll have a look at the branch
<slangasek> bcurtiswx, seb128: ok, very strange, I'm not able to reproduce this vapigen failure in an up-to-date chroot; it's not a clean chroot right now, but I wonder what could interfere
 * slangasek tries again with a fresh build
<bcurtiswx> slangasek, i will try again after another update if you can't reproduce, to see if it's fixed on my end
<mdz> anyone else get a long string of these with the latest software-center update?
<mdz> 2011-03-22 17:53:11,282 - softwarecenter.db.update - WARNING - The file: '/usr/share/app-install/desktop/kde4___kbruch.desktop' could not be read correctly. The application associated with this file will not be included in the software catalog. Please consider raising a bug report for this issue with the maintainer of that application
<mdz> I seemed to get one for every .desktop file on my system
<kirkland> slangasek: yes, that was me;  you asked me to set priority: required, did you not?
<slangasek> kirkland: only for multiarch-support - apparently the priority: required got set for all the binary packages
<kirkland> slangasek: arg, fail
<slangasek> kirkland: so whatever button you pushed seems to have been the wrong one :-)
 * kirkland should have just let you handle that part
<bcurtiswx> gotta head out for a bit, bbl
<doko> slangasek: please do, maybe away for a while tonight
<cjwatson> kirkland: see bambee's query above?
<kirkland> bambee: dpkg -l console-setup
<bambee> kirkland: 1.57ubuntu17
<kirkland> bambee: upgrade to 1.57ubuntu17 and that should solve your problem
<cjwatson> blink
<bambee> the problem occurs when I upgrade to this version :)
<kirkland> bambee: hmm
<kirkland> bambee: one second
<bambee> ok
<debfx> kirkland, bambee: I'll fix it shortly
<kirkland> bambee: oh, it's newt
<kirkland> bambee: dpkg -l newt
<cyphermox> mdz, I did get one line like that today
<mdz> cyphermox, I got a *lot*
<kirkland> bambee: dpkg -l libnewt0.52
<bambee> kirkland: not installed
<bambee> ohh
<kirkland> bambee: newt >= 0.52.11-2ubuntu7
<debfx> kirkland: it's a copy'n'paste error: update-alternatives --set newt-palette /etc/console-setup/vtrgb.vga
<kirkland> debfx: doh
<bambee> kirkland:  0.52.11-2ubuntu7
<kirkland> debfx: okay, you'll upload the fix to kubuntu?
<kirkland> bambee: okay, debfx is on it
<debfx> kirkland: yep
<kirkland> bambee: thanks for the report
<bambee> yw :)
<kirkland> debfx: thanks for handling the kubuntu side
<slangasek> bcurtiswx, seb128: ok, this telepathy-glib build failure is definitely unreproducible for me in a clean, up-to-date chroot.  if you can still reproduce it after update, let me know; for the moment I'm assuming it's resolved itself
<cyphermox> mdz, I only see it for gnome-do here... but I also don't have kbruch installed (which was your example)
<seb128> slangasek, ok, I didn't try myself yet since I'm not uptodate, will do in a bit and let you know, thanks for have a look to it
<mdz> cyphermox,
<mdz> perseus:[/var/log/apt] sudo grep -c '^2011-03-22.*softwarecenter.db.update - WARNING' term.log
<mdz> 4780
<cyphermox> yikes
<cyphermox> seems I do have kbruch installed on one of my systems too, after all
<mdz> I doubt I have *that* many buggy .desktop files :-)
<cyphermox> yeah
<cyphermox> maybe specific to the version of softwarecenter you were upgrading from?
<mdz> cyphermox, I can reproduce by running update-software-center manually
<mdz> it's a catch-all exception handler
<slangasek> cjwatson, mvo: are there any changes in the default debconf stack in Ubuntu that would explain use of /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm on the desktop? (Bug #740334)
<ubottu> Launchpad bug 740334 in pam (Ubuntu) "package libpam0g 1.1.2-2ubuntu5 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/740334
<cjwatson> slangasek: aptdaemon uses passthrough
<slangasek> cjwatson: ok, that explains that side of it at least, thanks.  Have you seen anything to suggest there are bugs on the debconf side of this?
 * slangasek starts poking at pam-auth-update itself
<slangasek> oh, except there are no p-a-u line numbers anywhere in that output
<cjwatson> nothing springs to mind; that looks like something chatting on the debconf pipe when it shouldn't be ...
<slangasek> hmm
<cjwatson> it's hard to tell for sure.  I don't suppose it's possible to rerun with DEBCONF_DEBUG=developer?
<slangasek> I'll ask the submitter for that, thanks
<cjwatson> may be tricky if it's going through some pile of layers
<cjwatson> I guess find out what package manager they're using, in the first instance
<mdz> cyphermox, bug 740372
<ubottu> Launchpad bug 740372 in software-center (Ubuntu) "update-software-center fails on every .desktop file" [Undecided,New] https://launchpad.net/bugs/740372
<slangasek> elmo: udev uploaded, thanks!
<slangasek> cjwatson: fwiw, none of the code in p-a-u has changed this cycle, but the latest upload bumps the compat version number to force service restarting for the module path change - so this is the first time this cycle pam is asking debconf questions, and it seems to have triggered 3 bug reports so far
<cjwatson> slangasek: yeah, I think the problem is much higher up the stack than debconf though
<slangasek> sure
<cjwatson> that slew of debconf errors is just debconf's ugly way of saying "help, I was expecting a reply to a command and the frontend went away"
<slangasek> ah :)
<pitti> directhex, hyperair, Laney: https://launchpad.net/ubuntu/+spec/packageselection-desktop-n-application-selection has an item "[ubuntu-cli-mono-dev] Clean up deps on appindicator extensions so that we use the pure sound menu for 11.04" -- do you know what's going on with that? TBH I don't understand it at all
<pitti> seb128, kenvandine: CC: ^
<cjwatson> or actually, in this case, "the thing on the other side of passthrough went away"
<directhex> pitti: i guess it's asking that we drop building support for appindicator, to remove that dependency, leaving only the mpris stuff?
<directhex> pitti: this is hyperair's domain
<pitti> directhex: ah, thanks
<directhex> that's how i understand it anyway
<directhex> i could be wildly incorrect
<pitti> hyperair: that is marked for beta -- do you think that's still happening, or should we rather postpone this? (which might be safer at this point)
<pitti> directhex: that's what kenvandine seemed to remember as well, anyway, so I guess that's what it means
<directhex> pitti: seems like another conditional --disable, which is no big deal to implement, but it's part of hyperair's workflow and i won't stomp on it
<EtienneG> hello everyone.  Per https://bugs.launchpad.net/ubuntu/+source/udev/+bug/659258, the Infiniband udev rules have been dropped from udev-152 (and hence from Ubuntu post-lucid).  Perhaps this was intentional, I am not sure, the upstream changelog is silent on the subject.  Anybody knows what happened there?
<ubottu> Ubuntu bug 659258 in udev (Ubuntu) "Infiniband/RDMA rules absent" [Undecided,New]
<directhex> i'm curious about who would be using IB on ubuntu
<EtienneG> directhex, well, I know at least one place that does
<EtienneG> although, sadly, I cannot share whom and for what :(
<Laney> i thought appind was a part of bce?
<micahg> slangasek: chromium's dev channel failed to build with the newer libgcrypt build: http://launchpadlibrarian.net/66991055/buildlog_ubuntu-natty-amd64.chromium-browser_11.0.696.16~r78799-0ubuntu1~ucd~dev1_FAILEDTOBUILD.txt.gz, the daily channel was built with 1.4.6-4 and it worked
<directhex> Laney: is it? http://bit.ly/bb8RWS
<Laney> dunno, thought so. can't surf - on phone
<Laney> maybe it got moved to mainline
<slangasek> micahg: looking, but I don't think anything in the multiarch patch should have caused a change in the fPIC option used to build gcrypt; is this reproducible if you rebuild gcrypt without multiarch?
<micahg> slangasek: I don't think so, the other builds with gcrypt w/out multiarch worked
<slangasek> micahg: where do you have another copy of gcrypt that's built with the current toolchain but without multiarch?
<micahg> slangasek: this build of a slightly newer version of chromium with the 1.4.6-4 (pre-multiarch version)  https://launchpad.net/~chromium-daily/+archive/ppa/+buildjob/2335823/+files/buildlog_ubuntu-natty-amd64.chromium-browser_12.0.711.0%7Esvn20110322r78963-0ubuntu1%7Eucd1_BUILDING.txt.gz
<ubottu> Error: Launchpad bug 2335823 not found
<slangasek> 1.4.6-4 was not built with the current toolchain, that's why I asked if it's reproducible /if you rebuild gcrypt/
<doko> TheMuso, mterry: how should we handle dbus-c++ and libconfig maintenance?
<micahg> slangasek: ah, I saw it was uploaded yesterday, so I guess everything changed again yesterday?
<micahg> slangasek: sorry, ignore that
<micahg> slangasek: I can do a test rebuild with the old libcrypt against the new toolchain and see what happens
<slangasek> micahg: that would be great, thanks
<mterry> doko, is it still orphaned?
<doko> mterry: dbus-c++: yes
<mterry> doko, isn't that the sort of thing that's bad for main?  No one wants to take it?  I'd feel better if it was at least maintained in Ubuntu by someone...
<doko> mterry: yes, I didn't ping you alone ;)
<doko> mterry: ahh, I see, somebody updated to a new snapshot in unstable
<mdz> cyphermox, it's because I don't have apt-xapian-index installed
<mterry> doko, oh neat, that's a good start
<mterry> doko, so what mir is this blocking again?
 * mterry has short term memory
<mterry> ah, libffado
<cyphermox> mdz, ok
<mterry> I guess I'm curious what results TheMuso has got from the pkg-multimedia/ubuntu-audio teams
<ari-tczew> slangasek: IIRC you handle with new palette colours, right?
<slangasek> ari-tczew: no
<micahg> mterry: there was an offer to co-maintain dbus-c++ using CDBS outside of pkg-multimedia
<slangasek> ari-tczew: I think you're looking for kirkland
<ari-tczew> slangasek: ah, thanks
<slangasek> micahg: so thinking about it, I'm guessing the problem is that chromium is meant to be looking for the .so, not for the .a, so it probably is a multiarch problem after all; digging deeper
<ari-tczew> kirkland: could you look on this issue? http://paste.ubuntu.com/583934/
<mterry> micahg, interesting.  an offer that was followed up on?
<micahg> mterry: let me see if I have any more info
<micahg> mterry: no response after that on the ML, idk about private e-mails
 * micahg gets link to thread
<micahg> mterry: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2011-March/017057.html
<kirkland> ari-tczew: hi there, debfx is uploading a fix for this
<pitti> doko: pcsc-lite dependencies fixed, thanks for spotting
<kirkland> ari-tczew: he's fixing this in kubuntu-settings
<mterry> huh
<kirkland> ari-tczew: thanks for bringing that up
<doko> pitti: just desperately trying to keep the archive in a buildable state ;p
<pitti> a great thing to have at any time!
<micahg> slangasek: should I skip the chromium rebuild or start it anyways
<slangasek> micahg: skip it, I think I know what's going on here now
<micahg> slangasek: awesome, thanks
<ari-tczew> kirkland: ok. thanks debfx
<cdbs> requestsync --lp is failing. Using the latest daily build. Anyone else with a similar problem?
<Laney> what error?
<cdbs> Laney: no error, it just hangs
<cdbs> and if I do Ctrl+C, I get to know that it is in lazr.restfulclient's _browser_and_retry function
<cdbs> and is sleep()ing for some time
 * cdbs works-around by using syncpackage
<Laney> a better workaround would be to use mail mode
<Laney> sounds like a bug in python-launchpadlib or lp though
<slangasek> micahg: sorry, it's taking longer than it should to get a fixed libgcrypt11-dev; I'm about to start stabbing cdbs
<slangasek> cdbs: no, not you
<cdbs> Laney: hmm, this is a faster way anyway
<cdbs> slangasek: heh, I understood already
<bcurtiswx> back
<slangasek> oh, figured it out
<slangasek> and I should stab myself, not cdbs
<micahg> cdbs: syncpackage isn't a workaround, why not downgrade to the stable version as a workaround
<micahg> slangasek: thanks
<cdbs> micahg: Why isn't syncpackage a workaround?
<cdbs> Its way better sometimes
<chrisccoulson> doko, i'm trying to get webkit support working in swt-gtk, but i'm seeing a crash that i'm a bit stuck with. what seems to be happening is a pointer that gets returned from webkit_get_default_session gets truncated to 32 bits (i'm on a 64-bit machine) before being passed to the JVM. i took a look at the assembler for the native call in the JNI, and i see this: http://paste.ubuntu.com/583951/
<chrisccoulson> there seems to be a rogue cltq after returning from webkit, but i don't know why :/
<ari-tczew> anybody noticed that console (terminal) can't remember used commands?
<chrisccoulson> ^^micahg - you will have the same issue with eclipse ;)
<chrisccoulson> doko - i'm not sure if you're the right person to ask, but it seems to be toolchain and java related ;)
<slangasek> micahg: ok, -4ubuntu2 uploading.  Sorry, I saw that libgcrypt-dev wasn't quite right when I was doing the conversion, but didn't recognize all the implications at the time - things should build fine against it, now that libgcrypt.so is in the compiler's default path
<slangasek> micahg: if you still have problems, at this point it'll be something that needs fixing on the chromium side
<micahg> cdbs: syncpackage does the upload, requestsync requests a sync
<cdbs> micahg: so, you use syncpackage to upload instead of depending on AAs
<micahg> slangasek: ok, thanks quick fix!
<cdbs> micahg: and, if I had the upload rights, then there's no advantage of using requestsync
<micahg> cdbs: the use of syncpackage is discouraged, someone else will have to explain why
<micahg> cdbs: there's a note in the manpage about it
<cdbs> I did hear of people exclaiming that, but I never got to know about what it was
 * cdbs mans syncpackage
<cdbs> ah, got the warning
<slangasek> doko: ^ with the latest udev and libgcrypt11 uploads, all the multiarch build breakage that I'm aware of today is resolved (not counting the toolchain issues you and I discussed), so this is probably a fine time for a snapshot rebuild
<mvo> slangasek: could it be the ""  gdm: reloading...FAILED! (1)" that makes the script fail ? and that in turn kill one side of the debconf communication?
<doko> slangasek: ok, thanks, still cleaning up component mismatches
<mvo> slangasek: I have seen a similar report a while ago
<fta> slangasek, thanks for the fix, good i don't have to workaround it in chromium
<slangasek> mvo: shouldn't be; we're not outputting any differently on our fds in the failure case than the success case, the only thing that a non-null "failed" set does is trigger another debconf question
<doko> chrisccoulson: probably, is this targeted for natty?
<mvo> slangasek: ok
<slangasek> mvo: now, it's possible that the reload command *itself*, that we're calling to try to restart gdm, is failing and outputting something wrongly - but we are redirecting 2>&1 when calling that, too
<chrisccoulson> doko, it's not targetted yet. it's part of a bigger chunk of work to drop xulrunner from main
<pitti> in a sense it is targetted to natty, as we can't keep the old xulrunner-1.9.2 in main
<RoAkSoAx> pitti: around?
<pitti> RoAkSoAx: yes (but kinda busy)
<RoAkSoAx> pitti: no worries, when you have the time could you please take a look at bug #738757
<ubottu> Launchpad bug 738757 in hdparm (Ubuntu) "spindown settings lost on pm-suspend indirectly affects powernap power savings" [Undecided,New] https://launchpad.net/bugs/738757
<RoAkSoAx> pitti: as this affects pm-utils either directly/indirectly
<pitti> RoAkSoAx: opened tab, will reply in the bug (but probably only tomorrow morning)
<RoAkSoAx> pitti: sure, whenever you have the time is fine. Thank you!
<RoAkSoAx> pitti: it affects powernap indrectly but it is not really necessary for until next release cycle
<jelmer> doko, hi
<doko> jelmer, want to write a MIR? ;)
<jelmer> doko: I'm a bit puzzled about bug 713038
<ubottu> Launchpad bug 713038 in subunit (Ubuntu Natty) "Sync bzr 2.3.0-1 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/713038
<jelmer> doko: MIR.. is the issue that subunit isn't in main but bzr is?
<doko> jelmer: yes
<jelmer> doko: Ah, whoops. I'll prepare a patch to get rid of that build dependency.
<jelmer> doko: thanks
<pitti> jelmer: (FWIW, subunit doesn't sound bad to have in main, as long as it's properly maintained in Debian)
<pitti> slangasek: ah, so the auth log actually has entries for the cups auth fail
<pitti> cupsd: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file: No such file or directory
<pitti> which is quite understandable :)
<slangasek> pitti: ok, so where does that path come from?
<pitti> good question
<slangasek> does cups have an embedded copy of libpam somewhere?!
<pitti> pam-start() seems to work, but pam_authenticate() returns PAM_MODULE_UNKNOWN
<pitti> #    include <security/pam_appl.h>
<slangasek> pitti: this is from the cupsd daemon process?
<pitti> slangasek: yes; I run through it with a debugger now, to ensure
<slangasek> pitti: ldd, lsof  | grep pam ?
<pitti> cupsd     22259       root  mem       REG                8,2    51712    1045403 /lib/x86_64-linux-gnu/libpam.so.0.82.3
<pitti> slangasek: I'll isolate the code and produce a standalone test case for now
 * slangasek scrunches his nose
<slangasek> pitti: thanks
<slangasek> pitti: there aren't any hard-coded /lib/security paths in /etc/pam.d/* on this system, are there?
<pitti> grep lib /etc/pam.d/* -> nothing
<pitti> slangasek: su and friends obviously work
<slangasek> right
<pitti> /etc/pam.d/cups just has the three standard @includes
<pitti> same as su has (su has more stuff, though)
<slangasek> does su generate any errors in the log?  It's /possible/ that the errors are spurious
<pitti> but su works fine
<pitti> slangasek: no, already tested that
<slangasek> but in fact, pam should be trying the multiarch path first
<slangasek> ok
<pitti> that's debian/patches-applied/lib_security_multiarch_compat, I suppose
<slangasek> pitti: it is indeed
<pitti> so, the same code in a standalone binary works just fine
<Laney> pitti: yeah I don't know about that WI; appindicator is in a separate universe package and was never a dep/recommend of banshee AFAIR
<Laney> I'd just make the WI go away
<pitti> Laney: ok, thanks for the heads-up
<Laney> maybe it was from a time when soundmenu was in bce
<slangasek> pitti: does apparmor know about /lib/$arch/security?
<pitti> ooooh, good point
<slangasek> courtesy of jjohansen
<pitti> [51445.388937] type=1400 audit(1300827302.687:49): apparmor="DENIED" operation="file_mmap" parent=1 profile="/usr/sbin/cupsd" name="/lib/x86_64-linux-gnu/security/pam_deny.so" pid=22259 comm="cupsd" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
<slangasek> jjohansen: good catch :)
<jjohansen> jdstrand: ^
<pitti> jjohansen: thanks so much, that saved a lot of trouble
 * pitti stops nemiver and updates the AA profile
 * jjohansen points slangasek at aa-notify its has saved me a few times
<pitti> slangasek: that's in /etc/apparmor.d/abstractions/authentication
<pitti> jdstrand: ^ mind if I upload apparmor to update ^ for the multiarch pam libs?
<slangasek> pitti: should the kde abstraction be updated preemptively?  also, the base abstraction has now-broken gconv refs
<slangasek> looking for other things that need updating
<slangasek> /lib/tls/i686/{cmov,nosegneg}/lib*.so* -- that's also wrong now, needs to be /lib/i386-linux-gnu/tls/[...]
<pitti> slangasek: kde> you mean for /usr/lib/*/{qt3,qt4,kde3,...}/... ?
<slangasek> pitti: and /etc/apparmor.d/abstractions/nameservice also needs to be extended, as does /etc/apparmor.d/abstractions/kerberosclient
<slangasek> pitti: yes, precisely
<slangasek> similar issue in /etc/apparmor.d/abstractions/gnome, for the gtk/pango/gdk modules
<jdstrand> pitti: no, but you might want to coordinate with sbeattie. I think he is planning an upload, but probably not today. We made a few changes (last week?), but apparently that was only for the beginning of the multiarch changes
<pitti> jdstrand: hm, and the new patch 0004-lp736870.patch doesn't seem to be in bzr; forgot to bzr add?
<jdstrand> slangasek: are you up to date? I specifically made changes for gconv
<pitti>   /usr/lib/*-linux-gnu/gconv/*.so          mr,
<pitti>   /usr/lib/*-linux-gnu/gconv/gconv-modules mr,
<slangasek> jdstrand: sorry, I'm actually looking at maverick at the moment because it was closer to hand
<pitti> is that the fixed one already?
<slangasek> jdstrand: if you've already started multiarch handling, I guess I should look somewhere more recent
<jdstrand> pitti: that is the one I fixed lst week, yes
<pitti> jdstrand: mind to bzr add/push?
<jdstrand> pitti: let me see...
<slangasek> jdstrand: is this syncing with Debian?  *-linux-gnu matches all of our archs obviously, but won't cover all of Debian's
<jdstrand> pitti: added/pushed
<jdstrand> slangasek: apparmor is not in Debian. I did the best I could by looking at what I could find in Ubuntu at that moment
<jdstrand> pitti: fyi, r1419
<pitti> jdstrand: got it, thanks
<pitti> slangasek: http://bazaar.launchpad.net/~ubuntu-core-dev/apparmor/master/view/head:/debian/patches/0004-lp736870.patch
<ubottu> Ubuntu bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released]
<slangasek> jdstrand: ok; the above ramblings cover everything I see in the maverick one that need updating for multiarch, at least
<pitti> so that's missing pam, kde, gnome
<pitti> and kerberosclient
<slangasek> so we still need to fix /lib/tls (libc6-xen), kde, gnome, kerberosclient
<slangasek> + pam of course :)
<slangasek> pitti: are you taking it from here?
<pitti> slangasek: yes, thanks for the guidance
<pitti> slangasek: already confirmed that cupsd is happy with the updated profile
<jdstrand> slangasek: we'd (upstream apparmor) like to have the Debian archs too, but that isn't as important atm (feel free to file a bug against apparmor and we can add those later)
<slangasek> pitti: y/w - wouldn't have gotten there if I hadn't grumbled on a back channel where jjohansen heard me, heh ;)
<slangasek> jdstrand: file bug in LP or elsewhere?
<pitti> slangasek: bug 736870
<ubottu> Launchpad bug 736870 in apparmor (Ubuntu Natty) "abstractions need multiarch support" [High,Triaged] https://launchpad.net/bugs/736870
<jdstrand> slangasek: yes, LP
<jdstrand> or reuse that one :)
<pitti> ah, for the non-linux ones; that might be a separate thing
<jdstrand> pitti, slangasek: keep in mind that gnome and kde already #include <abstractions/base> so may not need fixing
<pitti> jdstrand: hm, weird; if I do "quilt push -a" in a clean checkout, it fails on 0002-lp727478.patch
 * jdstrand raises eyebrows
<slangasek> jdstrand: they do, they have non-multiarched paths for /usr/lib/$this_lib_module_dir/**
<jdstrand> slangasek: ok
<pitti> jdstrand: e. g. /usr/lib{,32,64}/pango/**
 * jdstrand nods
<pitti> jdstrand: debian/rules patch does the same..
<jdstrand> pitti: are you using UDD? cause it might not have imported..
<pitti> jdstrand: no, I'm using the Vcs-Bzr: branch
<jdstrand> hmm
 * jdstrand goes to look
<bcurtiswx> slangasek, has the tp-glib issue been resolved?
<slangasek> jdstrand: oh, and on armel the path is /lib/arm-linux-gnueabi/, so doesn't match your glob at all
<slangasek> bcurtiswx: I have not been able to reproduce the failure in an up-to-date build environment
<slangasek> jdstrand: bug #740510 for the !linux stuff
<ubottu> Launchpad bug 740510 in apparmor (Ubuntu) "multiarch paths in abstractions should not be Linux-specific" [Low,New] https://launchpad.net/bugs/740510
<pitti> so, getting a bit late; I'm off to bed
<slangasek> pitti: can you fix the *-linux-gnu globs to *-linux-gnu* while you're in there?
<slangasek> oh, n/m
 * slangasek takes the baton :)
<pitti> slangasek: yes, just made a note in the other bug about that
<pitti> slangasek: but currently blocked on the invalid patches; I guess I let jdstrand sort out the patches, and can continue on that tomorrow morning (unless Jamie or you beat me to it :) )
<slangasek> I'll try my best to beat you to it ;)
<jdstrand> pitti: fixed
<jdstrand> slangasek: ^
<jdstrand> as in the bum commit in the Vcs
<slangasek> jdstrand: thanks
<speakman> Hi devel folks. Is there any way to measure what's causing "/usr/bin/X" to be extremely CPU intensive sometimes?
<slangasek> jdstrand: fix pushed to bzr.  You said this should be coordinated with sbeattie ?
<slangasek> bcurtiswx: so are you still seeing problems with telepathy-glib in an up-to-date env?
<bcurtiswx> slangasek, it's weird, my local build fails there, but when i use pbuilder it doesn't
<sbeattie> slangasek: looking at your patch now.
<slangasek> bcurtiswx: I think you have some old packages installed locally
<slangasek> bcurtiswx: possibly an old version of gobject-introspection
<bcurtiswx> slangasek, yeah could be. thx for your help tho :)
<slangasek> bcurtiswx: no problem
<slangasek> micahg: how does chromium look?
<micahg> slangasek: idk, we'll know tomorrow when the dailies are built
<micahg> slangasek: unless you want me to rebuild it now?
<slangasek> micahg: ah, I think you should trigger a rebuild now, not wait another day
<micahg> slangasek: will do
<micahg> slangasek: ok, we should know in 3-4 hours
<slangasek> ok :)
<slangasek> YokoZar: ping :)
<sbeattie> slangasek: +1 from me on your patch
<slangasek> sbeattie: ta.  should I push to the archive now, or do you have other changes you want to go in with it soon?
<sbeattie> slangasek: go ahead and push; I have other changes, but I won't get to them until tomorrow.
<slangasek> ok, uploading'
<slangasek> thanks for the review :)
<jdstrand> sbeattie: yes, thanks for looking at it :)
<sbeattie> slangasek: no problem.
<RAOF> I've just had a debconf question pop up for the new libpam0g upgrade (the âwhat services would you like to restartâ question) having run update-manager.  Is that intentional or expected?
<slangasek> RAOF: the services have to be restarted for the pam upgrade due to multiarch; whether the question is meant to show depends on how you ran your upgrade and how you have debconf configured
<RAOF> I ran the upgrade through update-manager (and it was a partial upgrade).  I've not changed the default debconf proirties.
<slangasek> RAOF: it's meant to not be shown when running through update-manager
<slangasek> well, wait
<slangasek> RAOF: what services did it prompt you about?
<slangasek> if you have non-default services installed on your desktop, it will still prompt
<RAOF> Hm, it's entirely possible that I do.  I can't remember the list now.
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: smoser
<slangasek> RAOF: you may be able to get the list with: echo 'get libpam0g/restart-services' |  debconf-communicate libpam0g
<RAOF> squid gdm cups cron atd
<RAOF> There it is.  Squid.
<slangasek> right
<slangasek> so: yes, expected behavior :)
<RAOF> Um, squid?  Why does that use pam?
<slangasek> ask lifeless :)
<YokoZar> slangasek: hey
<ScottK> slangasek: It was another context.  I was trying to package a new pymilter release and got that error trying to test build last night.
<RAOF> slangasek: Oh, incidentally?  Rockin' multi-arch!  Yay!
<cleary> hi folks - I'm interested in getting some information on the live desktop development tools. Currently I'm building/deploying ubuntu based livecd for desktop use - the tools I'm using for the cleanroom mastering process are adapted from sidux/aptosid (pyfll)
<cleary> I'm wondering if the ubuntu team have freely available tools that I can look at using instead though? Currently it's quite a lot of work to maintain concurrency between the aptosid/debian changes and ubuntu new release changes
<cleary> I'm even just interested in talking with someone involved - regardless of how the tools are licensed
<cleary> if this isn't the right channel to be making this request, please point me to the correct one
<RAOF> cleary: This is the right channel to ask, although it's skirting the edges of on-topic.
<cleary> RAOF: I figured as much - I've struggled in the past to get any sort of traction on this type of enquiry though, hence doing it solo
<cleary> I think there's potentially some value for canonical (curiousity sake if nothing else), I work for a large australian winery - currently deploying this setup on ~150 or so desktops
<cleary> I'm sure I don't have to be doing it so tough though as far as tools go, but I have not been able to make headway
<cleary> in so far as talking to the right people in the ubuntu/canonical ecosystem
<poolie> hi scottk, can you please explain more on bug 739909?
<ubottu> Launchpad bug 739909 in Bazaar "Delete remote branch through bzr" [High,New] https://launchpad.net/bugs/739909
<poolie> did it crash or just not do anything?
<ScottK> poolie: --> #br.
<RAOF> cleary: Colin Watson could be one of the people to ask, as would Martin Pitt.
<ScottK> err #bzr
#ubuntu-devel 2011-03-23
<cleary> RAOF: thank you :)
<YokoZar> what exactly does the "package foo" instruction do in /usr/share/binfmts ?  Can it be a virtual package?
<slangasek> YokoZar: hey, what are your plans as far as updates to ia32-libs this cycle?  I fully expect the next upload is going to take some work, to teach the package how to extract bits from multiarched libs and install them to the right biarch target directories, etc.
<slangasek> ScottK: is that problem reproducible for you with an up-to-date natty?  reproducible with the existing pymilter?  Is something bypassing gcc to call ld directly?
<slangasek> RAOF: :-)
<YokoZar> slangasek: my plan was to 1) add some gstreamer-related codecs and their dependencies, and 2) remember to freshen the packages as close to release as possible
<YokoZar> I currently have a huge ia32-libs in maverick wine ppa with a delta of a good chunk of packages
<YokoZar> slangasek: but, yes, putting a bandaid on ia32-libs does scare me
<slangasek> right - so I would suggest trying to freshen it sooner rather than later
<slangasek> (and freshen it again later)
<slangasek> and yell if it's not working for you :)
<YokoZar> all right, I'll take a stab at it tonight and see if it balks at trying its magic on any of its current packages
<slangasek> I'm pretty sure it will :)
<YokoZar> It will need some multiarch magic for sure, although it should be doable in a generic way...
<slangasek> yes, /usr/i386-linux-gnu -> /usr/lib32 should do the job
<slangasek> er, I mean /usr/lib/i386-linux-gnu -> /usr/lib32
<slangasek> and the same for /lib32
<ScottK> slangasek: Let me try it again.
<ScottK> slangasek: It works now.  chroot was outdated.  Thanks for looking into it.
<lifeless> barry: https://bugs.launchpad.net/launchpad/+bug/608173
<ubottu> Ubuntu bug 608173 in Launchpad itself "View all (or more) PPA package build statuses" [Undecided,Expired]
<ohsix> o noes humidity went up a bit and the 2 finger clicks are being exacerbated
<micahg> slangasek: fta, chromium is good again \o/
<slangasek> micahg: ok, great :)
<hyperair> pitti, directhex: i don't recall ever creating that spec O_o
<hyperair> is it for disabling the appindicator extension in bce?
<ogasawara> slangasek: around?  I'm getting armel build failures for the kernel since the gcc-4.5 update.  unfortunately it's not providing me any logs -> https://launchpad.net/ubuntu/+source/linux/2.6.38-7.38/+buildjob/2336688
<ubottu> Error: Launchpad bug 2 not found
<slangasek> ogasawara: lamont was hard-killing builds on armel earlier, saying there was some problem requiring a reboot
<slangasek> ogasawara: so I don't think it's related to the gcc-4.5 upload; retry the build?
<StevenK> If there is no log, it was killed by failure counting.
<ogasawara> slangasek, StevenK: hrm, ok will retry it once more.
<micahg> ogasawara: also, lamont did a mass give back of armel
<lamont> StevenK: assuming it's really marked failed not just needs-build...
<lamont> rescuing build logs is one of the small services that I can provide, sometimes.  I just need the build to take long enough, and me to be around when it's running, so that I can make it stay harvested locally...
<lamont> which I prefer to avoid if possible
<lamont> since it does not scale
<slangasek> pitti: I see that there's only one package in lucid...natty, aside from pango itself, that ships a pango module - pango-graphite in universe.  How would do you feel about using Breaks: and force-moving the module directory all at once rather than providing a backwards-compatibility patch?
<pitti> Good morning
<pitti> slangasek: that sounds a lot cleaner and easier indeed
<pitti> slangasek: (re pango)
<didrocks> good morning
<dholbach> good morning
<dholbach> smoser, HAPPY BIRTHDAY
<cdbs> smoser: Happy Birthday!
<ari-tczew> slangasek: could you look on debian bug 619344 ?
<ubottu> Debian bug 619344 in ocaml "Not ready for multiarchified libx11-dev" [Normal,Open] http://bugs.debian.org/619344
<diwic> hi, compiz crashes on the live-CD. How do I replace the window manager with metacity on the fly?
<diwic> that's natty.
<pitti> didrocks: try just restarting the session, that usually works
<pitti> sorry
<pitti> diwic: ^
<pitti> diwic: it's still on my list to investigate
<diwic> pitti, how do I restart the session?
<pitti> diwic: one way I know is ctrl+alt+f1, "kill -9 -1"
<soren> diwic: metacity --replace
<diwic> pitti, thanks, that worked!
<diwic> soren, tried that from a VT but it couldn't connect to X
<pitti> diwic: "DISPLAY=0:0 unity" that works as well
<pitti> sorry, DISPLAY=:0
<soren> diwic: "DISPLAY=:0 metacity --replace"  It just needs help :)
<diwic> soren, ok :-)
<cjwatson> YokoZar: the point of 'package' in binfmt files is just to allow update-binfmts to refuse if multiple packages accidentally try to install the same format
<cjwatson> YokoZar: technically it can be any string, so I suppose you could make it a virtual package, but I don't see what you'd gain - there should normally only be one package installing the format file anyway.  Can you explain more?
<cjwatson> ah, you e-mailed
<mdz> mvo, is there a mirror file a la http://mvogt.wordpress.com/2011/03/21/the-apt-mirror-method/ for Debian as well?
<mvo> mdz: weasel did some work on this, there is a alpha service available and some discussion on the mailinglist
<mdz> mvo, ah, ok
<mvo> mdz:  I will be happy of course to help debian with the mirror stuff, the client should just work (tm)
<mdz> mvo, all that's needed is to create a text file with a list of mirrors, right?
<mdz> seems trivial
<OdyX> mdz: the text file is geodns-based generatedâ¦
<mvo> mdz: yeah
<mdz> OdyX, mvo, oh, I see, so mirrors.txt is actually dynamically generated for each client?
<OdyX> mdz: it seems so.
<mvo> yeah
<mvo> ups, sorry I should have said this before. its indeed (in ubuntu) country specific, its cached of course, but each country gets a different one
<mdz> mvo, btw, your blog is already on planet debian, but only posts tagged 'debian'
<mvo> mdz: oh, thanks! good to know, I will add it to the post.
<chrisccoulson> Daviey, ok, i uploaded the new swt-gtk to https://launchpad.net/~chrisccoulson/+archive/xulrunner-universe-transition now
<Daviey> chrisccoulson, thanks!
<lool> bdrung: Oy
<lool> bdrung: Not sure you saw that but your lintian 2.5 upload was dep-wait, doko fixed the dep-wait part but it's now FTBFSing
<lool> bdrung: Would be nice to dig out what's wrong in the testsuite and fix it before release, or upload an older lintian
<bdrung> lool: i worked yesterday on it.
<lool> bdrung: Perfect, thanks
<bdrung> lool: but one issue remains - a bug in another package.
<lool> So you have staged lintian fixes?
<lool> bdrung: what's the other package?
<lool> Maybe it's fixed in Debian experimental
<bdrung> lool: we have http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619287 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619290
<ubottu> Debian bug 619287 in lintian "lintian: dpkg-source excludes ".la" from tarball causing tests to fail" [Important,Open]
<ubottu> Debian bug 619290 in lintian "lintian: Future dpkg will not accept "libssl0.9.8 (>= abcd)" in Depends" [Normal,Open]
<bdrung> the latter is easy to fix
<lool> bdrung: ok; thanks for chasing these
<bdrung> lool: then we should pull d435b99 and 94ac59c
<bdrung> lool: then we are here: http://paste.ubuntu.com/584244/
<roxdragon> hi all
<bdrung> lool: search for "Use of uninitialized value" in it
<lool> bdrung: There seem to be other failing tests in your output
<bdrung> lool: the other problem comes from ubuntu entries in d/changelog
<mok0> Hm, I am seeing a directory listing like this:
<mok0> drwxr-xr-x+  72 ruki     ruki     12288 2011-03-22 10:51 ruki
<mok0> '
<mok0> what does "+" mean?
<mok0> something quota?
<mok0> No that's not it
<mok0> hyperair: hi
<hyperair> mok0: hi =
<hyperair> )
<hyperair> er
<mok0> hyperair: just asked a question while you were away
<hyperair> =)
<mok0> Perhaps you can answer? In a directory listing, I get this:
<mok0> drwxr-xr-x+ 72 ruki ruki 12288 2011-03-22 10:51 ruki
<mok0> What does '+' mean?
<hyperair> huh that's werid
<hyperair> i've never seen a +
<mok0> hyperair: me neither.
<hyperair> use the sources? =D
<cjwatson> it's documented in the ls info documentation
<hyperair> mok0: could you stat the directory?
<mok0> cjwatson: oh? I looked but couldn't find it
<cjwatson> mok0: http://paste.ubuntu.com/584247/
<Riddell> ev: well usb-creator on suse now completes the install but booting up just gets stuck at the syslinux credit line, anything I can try to work around it or should I just give up?
<cjwatson> mok0: you can probably use getfacl to find out more
<mok0> Ah, perhaps it
<mok0> it's an ACL thing...
<hyperair> aha.
<bdrung> lool: help to fix the remaining issues is welcome
<ev> Riddell: credit line? That one is going to be tricky. usb-creator needs to compare the version of syslinux on the local system against the one on the CD.  Right now we're doing this by Ubuntu versions.
<Riddell> ev: I did try it with  our_os_ver =  both larger and smaller than lucid but no difference
<mok0> It means additional access rules are defined using ACL. Thanks hyperair, cjwatson
<hyperair> so it seems.
<hyperair> setfacl stuff eh
<mok0> I'm helping my friend make a friendly front end to repquota, that will pop up a notification when users are logged on to a workstation
<mok0> So mucking about in the file server :-)
<lool> james_w: Mind adding oneiric to bzr-builddeb's bzr tip?
<lool> bdrung: Ok, will keep it in mind, but TBH I find it unlikely that I dive into the lintian issues; I just wanted to make sure you were aware of them; in the worst case, I think we should revert to an older lintian
<lool> but it seems there will be required changes for the new dpkg no matter what
<ev> Riddell: that's peculiar
<ev> no matter what, it should create the usb disk
<ev> you should only see the error once you try to boot it
<Riddell> ev: yes the files are all on the disk, it just doesn't boot
<ev> ah, hm
<ev> does it complain about a malformed line?
<ev> what's the exact error?
<Riddell> ev: it just shows "syslinux" and nothing else
<ev> Riddell: can you pastebin syslinux/text.cfg?
<ev> off the created usb disk
<Riddell> it shows "syslinux 3.86 EBIOS Copyright..."#
<Riddell> ev: syslinux/txt.cfg ?
<ev> yes
<Riddell> ev: http://paste.kde.org/7968/
<ev> Riddell: huh, that looks okay.  If you manually run syslinux /dev/sdb1 (or whatever it is) and replicate that dd line of the syslinux mbr, does it boot?
<Riddell> ev: from suse or ubuntu?
<Riddell> ev: how do you mean replicate that dd line?
<ev> suse
<ev> Riddell: dd if=/path/to/syslinux/mbr.bin of=/dev/sdb bs=446 count=1 conv=sync
<ev> again, assuming the usb disk is /dev/sdb
<Riddell> ev: linux@linux:~> sudo syslinux /dev/sdb  says  "syslinux: this doesn't look like a valid FAT filesystem"
<ev>  /dev/sdb1
<Riddell> ev: no change
<Riddell> still shows the syslinux line and nothing else
<ev> two things to try. A) does syslinux -s /dev/sdb1 fix it? B) does it work when Ubuntu is used to create the usb disk?
<ev> just trying to narrow this down
<Riddell> ev: I'm onto it
<ev> cool, thanks
<bdrung> ScottK: someone needs to get eclipse to use webkit instead of xulrunner
<abhinav-> bdrung, why so ? if it has got strong reasons, then it might be a good idea for SoC :-D
<bdrung> abhinav-: bug #740815
<ubottu> Launchpad bug 740815 in couchdb (Ubuntu) "[FFe] Updates to enable us to drop xulrunner from main" [Undecided,In progress] https://launchpad.net/bugs/740815
<ScottK> bdrung: OK.  I guess that's not going to happen before release ...
<bdrung> ScottK: unlikely, but possible
<ScottK> bdrung: It would be nice just to get rid of it.  Mozilla things in Universe just collect unfixed security bugs.
<jdstrand> fyi, I think micahg and/or the mozillateam is looking at eclipse, but in the context of xul2
<bdrung> micahg: you are looking into eclipse?
<Riddell> ev: no change from syslinux -s /dev/sdb1, using usb-creator with the same iso image in ubuntu does boot fine
<ev> what version of syslinux is installed in suse, what version do you have installed in ubuntu?
<ev> very odd
<micahg> ScottK: xulrunner-1.9.2 will be dropped from main before release and hopefully from the archive, hopefully we can drop xulrunner-2.0 as well
<micahg> err, drop xulrunner-2.0 from main
<ScottK> micahg: I'm really interested in seeing them all the way out of the archive.  Once they drop to Universe they just accumulate security bugs.
<micahg> ScottK: I have an idea about that, but I have to see where it goes
 * jdstrand agrees, fwiw
<ScottK> micahg: Great.
<micahg> ScottK: at least to keep it supported, otherwise I agree as well :)
<micahg> *unofficially supported :)
<ScottK> If it'll be supported, then I'm less insistent about removal.
<ScottK> Sure.
<ScottK> Chromium isn't 'supported', but I don't worry about it.
<Riddell> ev: on ubuntu it's syslinux 4.02  on suse it's 3.86
<doko_> siretart: any idea about the xine-lib build failure?
<siretart> doko_: well, you disabled the pvr plugin but the dh_install still tries to install it. it doesn't exist so the build fails
<doko_> siretart: hmm, will have a look. there was a reason to disable it ...
<siretart> for ppc64. do we support ppc64 after all?
<doko_> seb128, pitti: could somebody in the gnome team look at the libgda4 build failure on powerpc?
<seb128> doko_, not this week
<seb128> doko_, trying to land things before the beta freeze
<seb128> well not today at least
<seb128> change the rules to not fail on testsuit issues if you need it to build
<smoser> mvo, around ?
<smoser> i had a question on https://mvogt.wordpress.com/2011/03/21/the-apt-mirror-method/
<mvo>  smoser: in a call but availalbe
<smoser> 2 questions actually. 1.) does it only select the mirror once?  2.) is any attempt made to make sure the mirror is reachable ?  question 2 is largely seeded towards mirrors us-east-1.ec2.archive.ubuntu.com, which do not allow traffic in from outside that region.
<mvo> smoser: it re-selects it on each apt-get update. if a server fails to connect it tries the next one
<smoser> the way it works now is that cloud-init selects a mirror based on its location on first boot. i was wondering if i could, instead, specify mirror:// and have it "just work".
<smoser> inside us-east-1 region, the physically closest mirror is [surprise] the one we run in that data center
<mvo> smoser: its a matter of ensuring that our mirrors.ubuntu.com server know about the IP range of hte various DC and then it should work
<mvo> smoser: i.e. if the server gets updated to this, then mirror should be fine
<smoser> oh, so that list is dynamically generated based on source i
<smoser> ip
<smoser> is that right ?
<mvo> smoser: yeah, based on geoip
<mvo> smoser: slagado was doing the server work, probably worth talking to him about adding the DCs
<smoser> and then the client tests to see if it can get to it ?
<mdeslaur> is there a standard way to figure out if we're on a desktop or a server in a postinst script?
<bjf> pitti, there is a dapper kernel in our ppa that can go to -proposed (no ABI bump)
<amitk> bjf: do we keep logs of how many times the dapper archive is hit every month? Would be interesting to know...
<bjf> amitk, sconklin and i were talking about exactly that yesterday
<bjf> amitk, we think there is a way, you can get some stats from the archive now
<bjf> amitk, would be nice to get those numbers for all series
<amitk> bjf: agree
<pitti> bjf: hm, any idea how this ended up with having no Launchpad-Bugs-Fixed: header? that way LP won't auto-notify the bugs about release etc.
<pitti> bjf: (in http://launchpadlibrarian.net/67005417/linux-source-2.6.15_2.6.15-57.95_source.changes)
<pitti> bjf: did you build that in a non-ubuntu chroot perhaps, what confused dpkg-buildpackage?
<bjf> pitti, i built it in a dapper chroot
<pitti> bjf: ah, of course; nevermind
<pitti> bjf: done
<pitti> bjf: seems I forgot to copy linux-meta-lts-backport-maverick, doing that, too
<mvo> jhunt: a quick upstart question, I have a pre-start and a pre-stop script and want to have a common "FOO" constant in both scripts, is that possible to declare it only once? something like env I guess but for the upstart job file instead of the job itself
<jhunt> mvo: so you want a variable that is accessible to pre-start and pre-stop script sections?
<mvo> jhunt: yes
<jhunt> mvo: env will do what you want I think??
<mvo> jhunt: aha, excellent :)
<shadeslayer> doko_: poke ... around?
<jhunt> mvo: env foo=bar and then $foo is accessible to all script sections.
<mvo> jhunt: I wasn't sure from the description, let me just try it out
<mvo> nice!
<mvo> thanks jhunt!
<jhunt> mvo: you're in for a treat when we have our meeting. We have an Upstart surprise announcement :-)
<mvo> does it involve systemd?
<mvo> â¦ just kidding
<doko_> shadeslayer: ?
<shadeslayer> doko_: okay, so i was looking at google go
<shadeslayer> and it says that gcc can be compiled with support for google go
<shadeslayer> doko_: http://golang.org/doc/gccgo_install.html
<kim0> Hi folks, just letting you know "Ubuntu Cloud Days" starting about now in #ubuntu-classroom .. Thanks
<ogra_> could someone please bump build priority for https://launchpad.net/ubuntu/+source/compiz/1:0.9.4git20110322-0ubuntu2/+buildjob/2338979
<ubottu> Ubuntu bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]
<cjwatson> ogra_: done
<ogra_> thanks
<cjwatson> not that it helps hugely
<chrisccoulson> ubottu, you are stupid
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<cjwatson> ah, there we go, that's better
<ogra_> well, unity is in the queue
<ogra_> and it needs it so i wuld like to have compiz ready asap
<chrisccoulson> ScottK - i thought about package removals for bug 740815, and, if i was going to pick one package to remove now, it would probably be google-gadgets....
<ubottu> Launchpad bug 740815 in Mozilla Firefox "[FFe] Updates to enable us to drop xulrunner from main" [Medium,In progress] https://launchpad.net/bugs/740815
<chrisccoulson> ....but....
<chrisccoulson> ...that's depended on by plasma-scriptengine-googlegadgets, which seems to be a kubuntu package
<chrisccoulson> would you object if that went?
<ScottK> apachelogger: ^^^
<ScottK> (ask someone who knows)
<ScottK> But removing one rdepend doesn't reallly help unless we remove them all.
<chrisccoulson> google-gadgets seems fairly dead upstream, and it also uses both JS and XPCOM (which prevents me from linking it against a stable JS library)
<Riddell> I don't think plasma-scriptengine-googlegadgets is much used, I wouldn't mind it disappearing if it's causing hassle
<chrisccoulson> and bug 722611 gives an idea about the level of work to maintain google-gadgets ;)
<ubottu> Launchpad bug 722611 in google-gadgets (Ubuntu) "Needs to be either ported to xulrunner 2.0, or drop it's dependency on xulrunner entirely" [High,Triaged] https://launchpad.net/bugs/722611
<chrisccoulson> a 100KB patch and it still isn't complete ;)
<apachelogger> ScottK: aseigo will know what to do
<roxdragon> hi all
<ogasawara> doko_, slangasek: I see there has been another gcc-4.5 upload.  what code generation impact does it have on the kernel?  ie. am I needing to spin another no-change upload of the kernel.
<apachelogger> chrisccoulson, ScottK: <aseigo> apachelogger: lots of people use it (we get bug reports when libgooglegadgets has bugs ;) ... but it's an add-on, so feel free to do whatever you want as a downstream
<apachelogger> isn't the plasma scriptengine in universe anyway?
<ScottK> In fact we split the source out of kdebase-workspace to be able to provide it in Universe.
<apachelogger> in particular due to the fact that googlegadets is such a horrible piece of software
<ScottK> apachelogger: It is, but I was suggesting maybe xulrunner should just die.
<chrisccoulson> apachelogger, my concern is that nobody appears to be maintaining google-gadgets upstream
<apachelogger> well, as long as it works
<chrisccoulson> and i did make a start to port it to the latest xulrunner version, but it's a big chunk of work
<chrisccoulson> and xulrunner-2.0 (the current version) is not going to be supported within 3 months of natty release
<doko_> ogasawara:   * Fix issue with volatile bitfields, default to -fstrict-volatile-bitfields
<doko_>     again on armel for Linaro builds. LP: #675347.
<chrisccoulson> (ie, no more security updates)
<apachelogger> 3 out of 19 ggadgets bugs in KDE came from ubuntu users it seems
<slangasek> ogasawara: I thought the issue was the kernel had a naive check for compiler version number that prevented out-of-tree modules from rebuilding after *every* gcc rev, whether or not there are code changes?
<apachelogger> chrisccoulson, ScottK: probably we can drop it, popcon only has 432 installs, so I think the UX loss would be non existent
<chrisccoulson> apachelogger, thanks
<ogasawara> slangasek: I was never aware of that, but it's likely true.  /me consults with tgardner
<slangasek> ogasawara: right, so TTBOMK the whole problem we have with needing kernel rebuilds after gcc updates is that having the kernel check for the things that actually matter at build-time was too hard so there's a compiler version "fingerprint" check instead
<slangasek> I honestly don't know why /any/ changes we might make to gcc-4.5 would upset the kernel ABI, and I think this is something we ought to explore at UDS to see if we can solve it - make less work for you guys, and less unnecessary pressure on doko_ to avoid revving the toolchain when needed
<ogasawara> slangasek: sounds like a good plan, /me makes a note to add it to the agenda
<slangasek> cool, thanks :)
<Pendulum> SpamapS: hey, just want to remind you that your class is in #ubuntu-classroom in about 5 minutes
<slangasek> doko_: I guess you didn't have a chance to review my patch for python2.7 multiarch build fix - should I go ahead and upload it?
<seb128> ev: hey, there?
<sladen> "familiarity with Ubuntu or Dabian".  This would be amusing.
<sladen> If it wasn't a Canonical job advert :)
<SpamapS> what, canonical doesn't want people familiar with the Guangxi province of China?
<highvoltage> sladen: how so?
<chrisccoulson> Daviey, did you have any luck with euca?
<Daviey> chrisccoulson, I'm sorry, but i've been swapping other tasks today.
<Daviey> hggdh, Are you around?
<hggdh> Daviey, yes
<Daviey> hggdh, Are you swamped at the moment, or would you be able to add an extra PPA to the euca install we were on the other day - to see if the web ui still functions?
<Daviey> chrisccoulson, is trying to break it :)
<chrisccoulson> heh :)
<hggdh> Daviey, please give me 20min
<Daviey> hggdh, That is awesome, really helps...  give me a ping when you are good.
<hggdh> Daviey, certainly
<hggdh> Daviey, OK, rebooting and we will get on with it. Just 2 min or so
<hggdh> Daviey, ready now :-)
<Daviey> hggdh, If you can enable this PPA... https://launchpad.net/~chrisccoulson/+archive/xulrunner-universe-transition .. upgrade, restart the CLC, and check that the WEB UI still works.. that would be awesome.
<hggdh> Daviey, getting thru it now
<Daviey> thanks.
<ev> seb128: I am now.  What's up?
<hggdh> Daviey, what exactly are we trying to upgrade there?
<Daviey> hggdh, swt-gtk
<hggdh> Daviey, OK. rebooting the beast, and I will check if it got upgraded
<hggdh> Daviey, there are no hits for any of the swt-gtk binary packages
<hggdh> Daviey, but libgwt-user-java got upgraded
<chrisccoulson> yeah, that's the interesting one
<Daviey> hggdh, try apt-cache policy swt-gtk ?
<chrisccoulson> gwt has no run-time dependency on swt-gtk
<Daviey> pah. sorry for confusing you hggdh
<chrisccoulson> i'm not sure whether the build-depends is really necessary ;)
<hggdh> heh
<chrisccoulson> so, all i've done is build gwt against the latest swt-gtk, but i'm not sure if it actually changes anything really ;)
<hggdh> chrisccoulson, at least on this install it does not seem so (no depends, and no libswt\* installed)
<hggdh> so far...
<hggdh> now, let's see what happens when I http in the beast
<hggdh> Daviey, chrisccoulson: all seems to work
<hggdh> Daviey, BTW, did you see the last email from Dan re. our karma?
<chrisccoulson> hggdh, excellent, thanks
<chrisccoulson> Daviey, you can upload to main can't you?
<Daviey> chrisccoulson, yes
<chrisccoulson> Daviey, would you mind sponsoring swt-gtk for me?
<Daviey> chrisccoulson, certainly, want me to pull the one from your PPA?
<chrisccoulson> Daviey, yeah, that one's fine. the only thing it needs is a bug reference in the changelog (bug 740815), and the ~ppa1 dropping from the version number
<ubottu> Launchpad bug 740815 in Mozilla Firefox "[FFe] Updates to enable us to drop xulrunner from main" [Medium,In progress] https://launchpad.net/bugs/740815
<chrisccoulson> that saves me hosting the files somewhere :)
<Daviey> chrisccoulson, ack
<chrisccoulson> thanks :)
 * Daviey hopes post beta we can take a breath of relax.
<chrisccoulson> yeah, me too :)
<chrisccoulson> i'm hoping to get bug 740815 fixed before beta, so it's going to be a busy day for me tomorrow too
<ubottu> Launchpad bug 740815 in Mozilla Firefox "[FFe] Updates to enable us to drop xulrunner from main" [Medium,In progress] https://launchpad.net/bugs/740815
<bdrung> doko_: can you please have a look at this build failure: https://launchpadlibrarian.net/67047805/buildlog.txt.gz
<YokoZar> Riddell: Does MPL really require we distribute source alongside binaries?  Or were you referring to the optional LGPL/GPL distribution?
<YokoZar> Or can we point to the source code and the build steps on the internet?
<YokoZar> I ask because in wine1.2-gecko (and wine1.3-gecko)'s case, one of those build steps needs to be done on Windows
<slangasek> ari-tczew: thanks for the pointer to Debian bug #619344; ocaml uploading now
<ubottu> Debian bug 619344 in ocaml "Not ready for multiarchified libx11-dev" [Normal,Open] http://bugs.debian.org/619344
<ari-tczew> slangasek: you're welcome, uploading directly to Debian?
<slangasek> ari-tczew: uploaded to Ubuntu only; for Debian the maintainers should take care of it
<ari-tczew> slangasek: ok, do you uploading -2ubuntu1 or did you grab -4 from Debian and then patch?
<slangasek> ari-tczew: -4ubuntu1 - -2 FTBFS with current binutils in natty
<ari-tczew> slangasek: nice :)
<ari-tczew> I'm pretty sure your patch will be accepted, one uploader wrote on the bug that he is interested in fix.
<tkamppeter> ScottK, hi
<ScottK> Hello tkamppeter.
<tkamppeter> ScottK, it is about bug 740140, if the problem is not a problem of Python, is it a problem of the site not conforming to standards?
<ubottu> Launchpad bug 740140 in hplip (Ubuntu) "hp-plugin -i plugin download error" [Undecided,Triaged] https://launchpad.net/bugs/740140
<tkamppeter> ScottK, or is urllib for very special cases but not for this simple text file download?
<ScottK> tkamppeter: I didn't look at the hplip code, but I can tell you that the proposed change in python2.7 is not correct.
<ScottK> So I'm not sure where the problem is, but that's not it.
<tkamppeter> ScottK, for me it looks like that if you request a file from the web via http you get a header at first andd this header contained "Content-Length=7054" for all the years and now SourceForge updated something on their server and after that the server sends "Content-Length=7054,7054" and urllib cannot cope with this. Either it is a new standard and urllib needs to be updated to support it or the SF server has a bug.
<tkamppeter> Is some http expert around?
<ScottK> Sounds to me like a SF bug, but I'm not a URI expert.
<Daviey> tkamppeter, according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 ... it looks wrong with SF.
<poolie> barry, do you think it would be ok if i forward your udd summary mail to u-d?
<poolie> mm, maybe it's not quite interesting enough news yet
<barry> poolie: you're certainly welcome to
<lifeless> bryceh: ping
<lifeless> barry: ping
<bryceh> lifeless, contentless pong
<lifeless> bryceh: hi
<barry> lifeless: pong
<lifeless> I'm looking at your message perf bug
<lifeless> barry: hi, I have a bug from you I'm looking at
<lifeless> bryceh: I find the trace a little hard to read
<barry> lifeless: hit me
<lifeless> bryceh: wondering if you can step me through what api call you ar e making at each point
<lifeless> barry: https://bugs.launchpad.net/launchpad/+bug/608173
<ubottu> Ubuntu bug 608173 in Launchpad itself "View all (or more) PPA package build statuses" [Undecided,Expired]
<bryceh> lifeless, is that the bug I attached the reproduction script to?  did you try running it directly?
<barry> lifeless: yeah, i did need/want that at one time, but right now i'm not doing huge amounts of package builds in ppas.  i don't mind that it got expired i guess
<lifeless> bryceh: no, I haven't - I'm in a different continent, different tradeoffs
<lifeless> barry: if you can answer julians question
<lifeless> barry: we can see if its a dupe or not
<lifeless> barry: or already done
<barry> lifeless: will do, but right now i have to run.  will follow up tomorrow
<lifeless> thanks
<tkamppeter> Daviey, thanks, so SF has a bug? Is there a program with which I can download and see the original header?
<ScottK> If the download isn't ssl encrypted you can capture the download with wireshark and inspect it.
<ScottK> tkamppeter: It's likely possible to change hplip to catch this error, fix the data, and then try again.
<dinexi> Hi all. Is there anybody familiar with the package ecryptfs-utils? I have just reported a bug but I am still confused. https://bugs.launchpad.net/ubuntu/+bug/741364
<ubottu> Ubuntu bug 741364 in Ubuntu "libecryptfs_key_mod_openssl.so does not exists in ecryptfs-utils" [Undecided,New]
<dinexi> Yep, that's mine.
<dinexi> Sorry for my bad English, it's 5:53am here.
#ubuntu-devel 2011-03-24
<cjwatson> tkamppeter: I at least used to be an HTTP expert, although I'm pretty rusty these days.  I've posted an analysis to the bug with reference to the governing RFC.
<Ampelbein> dinexi: I could be wrong but I think the openssl mod had a license issue.
<dinexi> Ampelbein: Hm... that's bad. Do you know if it is included in the source package?
<dinexi> Ampelbein: Silly me. Nope, it shouldn't be there. So what to do? Build this thing myself?
<Ampelbein> dinexi: I don't know, maybe ask a question on https://answers.launchpad.net/ecryptfs/+addquestion?
<dinexi> Ampelbein: did it already. But transformed it to bug because there is a bug in the manpages then. :( But it is the worst news for today.
<Ampelbein> dinexi: kirkland is one of the authors of the software
<jcole> using debian preseed, im trying to enable all repos in sources.list by adding this multiselect:
<jcole> d-i	mirror/udeb/components	multiselect	main, restricted, universe, multiverse
<jcole> (maverick)
<jcole> but its not working
 * kirkland waves
<jcole> only main and restricted show up
<jcole> mainly for this project -> http://linuxcoe.sourceforge.net/
<Ampelbein> kirkland: dinexi had a question about the openssl mod in ecryptfs-utils and if it got removed.
<kirkland> Ampelbein: dinexi: right, Ubuntu and Debian's policies prevent us from linking gpl code against the openssl libraries
<slangasek> which is to say our policy of respecting the license we're given? :)
<kirkland> Ampelbein: dinexi: so, yes, you would need to build it yourself, until such time as we rewrite the code to use a different library that is GPL-compatible
<jcole> are preseeding server installs supported on ubuntu?
<Ampelbein> kirkland: ok, thanks for the explanation.
<slangasek> jcole: certainly, but this is not a support channel and the people who are most intimately familiar with the installer are not around, it being past their bedtime; you might try #ubuntu
<kirkland> slangasek: it's a tough situation to explain to someone who cares not about internal license politics :-)  -- but yes, of course, you are correct
<kirkland> Ampelbein: dinexi: http://www.openssl.org/support/faq.html#LEGAL2 and http://people.gnome.org/~markmc/openssl-and-the-gpl.html
<dinexi> kirkland: thanks! but I have two questions. 1) it is very easy to change the manpage, why it can't be done? 2) can I build the package from the source from the ubuntu repos?
<dinexi> kirkland: thanks a lot!
<jcole> slangasek: can you give me an irc filter for all the "smart" people in #ubuntu so i dont see all 1500 users
<kirkland> dinexi: yes, i think you can;  i have not done it in a very, very long time, but I think you merely need the openssl-dev packages installed on your system when you build/install ecryptfs-utils
<kirkland> dinexi: i *think* that the ./configure auto detects the presence of openssl and links it in
<kirkland> dinexi: like i said, been a long time since i did that
<slangasek> jcole: afraid I don't know such a filter :)
<jcole> slangasek: *sigh* ok here goes...
<cjwatson> jcole: #ubuntu-installer
<cjwatson> (I will help you there)
<jcole> cjwatson: thanks!
<dinexi> kirkland: sorry for the newbie question. I am in /var/cache/apt-build/build/ecryptfs-utils-83, made the change in the debian/rules file. What should I do now to build the package?
<Chipzz>   
<kirkland> dinexi: #ubuntu-motu is usually the best place to ask package building questions, but I'll give you a couple of hints here ...
<kirkland> dinexi: mkdir foo; cd foo; apt-get source ecryptfs-utils; sudo apt-get build-dep ecryptfs-utils; # make your changes here; dch -i ; debuild
<dinexi> kirkland: Thank you very much. debuild was a blocker.
<kirkland> dinexi: no problem;  good luck
<Chipzz> kirkland: didn't that change quite a while ago?
<kirkland> Chipzz: huh?
<Chipzz> at least that's what I was told the last time I redirected someone to #ubuntu-motu regarding packaging questions
<Chipzz> kirkland: #ubuntu-motu being the place to redirect ppl to if they have packaging questions; they're not "OT" here anymore
<kirkland> Chipzz: oh, really?  i guess i missed that policy change then
<Chipzz> kirkland: maybe I misunderstood (but don't think I did); but that change is several months old already (at least 3 or 4 months I think)
<lifeless> kees: ping
<dsalvetti> Hi there, I have a weird (packaging?) issue with munin-node on 10.04
<dsalvetti> when installing the package the file /etc/munin/munin-node.conf is missing
<dsalvetti> even though dpkg think the file is there
<dsalvetti> I have tried purging and reinstalling without success
<micahg> dsalvetti: file is in the package
<dsalvetti> any suggestion on what I could try next to find out where the issue is?
<dsalvetti> micahg: yes I've confirmed that with dpkg -c /var/cache/apt/...
<dsalvetti> dpkg --status also report the config file being present
<dsalvetti> but it's not there and because of that munin-node fails to start properly
<micahg> dsalvetti: maybe try #ubuntu-server, I don't see any bugs or questions filed on launchpad for it
<micahg> dsalvetti: oh, you could try #ubuntu-cloud
<dsalvetti> micahg: thank you, I'll try
<psusi> hallyn, hey... I'm here on irc if you want to chat a bit about those bugs btw
<YokoZar> slangasek: I tried a test rebuild of ia32-libs last night...and nothing seemed to break?!
<slangasek> YokoZar: er, define "break"?
<slangasek> YokoZar: is everything from /usr/lib/i386-linux-gnu getting copied into /usr/lib32?
<kees> slangasek: so, the -dev packages will ship .a files in /usr/lib/$triplet/libFOO.a but not be Multi-Arch?
<slangasek> kees: yes, because they're not reliably co-installable; that's something we need to go back and visit in round 2
<slangasek> some headers, for instance, contain arch-specific info, and we'll need to pick those apart
<kees> okay, cool. but they will still move to the triplet because they're built from the same --libdir target, etc.
<slangasek> yep
<kees> slangasek: uhm... does -dbg packages need the Pre-Depends?
<slangasek> no, because they don't need to be found by ld.so
<slangasek> (it doesn't hurt to have it added, I think, because the substitution will just be empty... but I haven't been bothering)
<kees> okay, that's what I suspected.
<kees> multiarch tiff passes the security team's regression test suite. ;)
<slangasek> I should hope so :)
 * kees suddenly realizes he has to teach his system about i386 tuples to test coinstallability
<slangasek> hmm, I don't have that part written up yet, do I
<slangasek> 'APT::Architectures { "amd64"; "i386"; };' in apt.conf, and 'foreign-architecture i386' in dpkg.cfg
<kees> slangasek: do I need a i686-linux-gnu.conf in /etc/ld.so.conf.d too?
<slangasek> no, libc6:i386 adds that
<kees> ah-ha, righto
<kees> is something like /etc/apt/apt.conf.d/60multiarch and /etc/dpkg/dpkg.cfg.d/60multiarch sane?
<slangasek> sure
<kees> oh whoops, didn't actually add Multi-arch: same. har har
<slangasek> :-)
<kees> slangasek: btw, I added this section quickly: http://wiki.debian.org/Multiarch/Implementation#Usingmultiarch
<slangasek> ok
<kees> heh, vim syntax needs updating! :)
<slangasek> eventually I think that should be its own page, but that's great for now
<slangasek> oh? updating for what?
<kees> syntax hilighting "Multi-Arch:" correctly :)
<slangasek> ah :)
<kees> slangasek: okay... what am I doing wrong? The "Multi-Arch: same" field doesn't seem to be making it's way into the binary package. *scratch head*
<slangasek> kees: pastebin?
<slangasek> kees: or control.in? :)
<kees> wait, no, I know what stupid thing I did. disregard. :)
<wgrant> slangasek: What changes will be needed from the LP/buildd end, and when?
<wgrant> I guess we'll need a new sbuild resolver.
<slangasek> wgrant: nothing at all this cycle
<StevenK> wgrant: s/ resolver//
<wgrant> "this cycle" being natty?
<slangasek> yeah
<wgrant> But that's over in a month :)
<slangasek> yeah ;)
<StevenK> IE, please file bugs now so LP has time? :-)
<slangasek> wgrant: we'll need to sit down at UDS and start figuring out what a sensible policy should even be for permitting cross-build-deps
<wgrant> slangasek: Yeah.
<YokoZar> slangasek: I mean fetch and build completed and the package built, although it probably is missing some things now
<twb> Stupid question: why is it "from debian_bundle import deb822" in lucid, when in wheezy it's "from debian import deb822"?
<slangasek> YokoZar: yes, I expect a lot of libs are either just plain missing, or installed to the wrong path
<slangasek> twb: someone changed their mind about the name?
<twb> I just ran into it because <script> barfed and it seems like a pointless change :-/
<wgrant> debian_bundle has been deprecated for a while.
<wgrant> It must have finally been removed.
<twb> Note that this is lucid; I don't touch non-LTS releases
<twb> OK, I checked the changelogs.  It's not an ubuntuism, the module name just changed upstream in Debian (0.1.16)
<twb> Sorry to bother you
<SpamapS> twb: err.. wheezy is the current testing isn't it?
<twb> SpamapS: yes but I'm not using that in production, just my personal laptop :-)
<SpamapS> looks like your *testing* of testing.. produced fruit. :)
<StevenK> SpamapS: Boo, hiss
<StevenK> RAOF: WTB Do plugin for Quod Libet
<YokoZar> slangasek: is there an easy list of multiarch-ready libs that I can cross reference the list with?
<slangasek> YokoZar: grep-dctrl -FMulti-Arch same -sPackage
<StevenK> Compat level 9? Wow, where did 8 go ...
 * StevenK idly wonders how brutally slangasek will slay him if he provides a recipe for converting a yada using source package to multi-arch ...
<kees> StevenK: compat level 8 is too mainstream
<kees> (hipster dh)
<slangasek> StevenK: I figure if you survive the attempt, you deserve to live
<StevenK> Haha
<RAOF> StevenK: To do what?  Just play/pause/forward/backward?
<StevenK> RAOF: Yah
<RAOF> That should be trivial to whip up.  Does it support mpris?  If so, I could just do a generic mpris control plugin.
<RAOF> Incidentally, the âfocusâ Do action is quite useful when you're scared of alt-tabbing because unity crashes :)
<StevenK> RAOF: How do I check if it supports mpris?
<RAOF> You could see if it exports the appropriate interface on dbus.
<RAOF> But, really, I could just install quod libet myself and see :)
<StevenK> RAOF: That sounds better to me. :-P
<kees> sudo apt-get install libc6:i386  <- so much hotness
<linuxuz3r> hi
<linuxuz3r> where do i get sys/processor.h
<linuxuz3r> where do i get sys/processor.h
<RAOF> From the package found by âapt-file search sys/processor.hâ
<linuxuz3r> RAOF, do you have the library for it
<RAOF> No, but I've pointed you at the way to find the package which contains sys/processor.h.  Which apparently doesn't exist, and least on amd64, so you'll need to give more information.
<RAOF> Probably in a different channel, because this doesn't sound like a question related to the development of the Ubuntu distribution :)
<linuxuz3r> RAOF, last question
<linuxuz3r> do you know if 32 bit ubuntu has it?
<RAOF> No.  I'd *guess* that the package that you're after is linux-headers-generic, but since you've not given any context as to what you'd like to *do* with processor.h, that's just a guess ;)
<linuxuz3r> its for a project that im doing
<StevenK> RAOF: So, uh, does it? :-)
<dholbach> good morning
<YokoZar> slangasek: so that grep-dctrl command has been running for two hours and not returning anything...
<cjwatson> YokoZar: it's waiting for input
<cjwatson> YokoZar: try s/grep-dctrl/grep-aptavail/
<YokoZar> cjwatson: ah hah, great ;)
<YokoZar> cjwatson: btw did you have a theory about the binfmt warnings on wine1.2->wine1.3 switch?
<cjwatson> YokoZar: not yet, haven't had a chance to think about it
<pitti> Good morning
<pitti> cjwatson: yesterday I added a gir1.2-* Extra-Include: to the supported seed, FYI; I don't think it makes too much sense to move all the autogenerated bindings of libraries to universe, as (1) we are going to need them in the near future, and (2) we really support them as well now (i. e. want to make sure that they work)
<pitti> cjwatson: does that sound ok to you? if so, I'd like to promote the remaining girs to main (see c-m.txt)
<cjwatson> pitti: sure
<didrocks> good morning
<amitk> is it normal (in the brave new world of unity) to *not* have a application launch when you click on the icon; instead you get taken to the existing instances of application. Nice for browsers, *very* annoying for terminals. I guess Ctrl-Alt-T will get more users...
<pitti> amitk: middle click opens a new instance FYI
<amitk> pitti: thx! where is all this documented? Is there a Unity starters guide?
<pitti> http://askubuntu.com/questions/28086/unity-keyboard-mouse-shortcuts/28087#28087
<pitti> (don't ask me for an easier address, I got it from https://wiki.ubuntu.com/Unity/KeyboardShortcuts
<amitk> heh :)
<didrocks> yeah, that's the best uptodate place :)
<pitti> I hope that will get a slightly more discoverable address :)
<didrocks> pitti: jcastro wants the askubuntu post to become the principal adress for it. But yeah, we need the officiel doc mentionning it with a link redirection
<pitti> slangasek, doko__: seems the multiarch transition is still missing a bit for libgcj-bc; that one has a symlink ./usr/lib/libgcj_bc.so.1 -> libgcj.so.11 which doesn't currently even get *installed* (does dpkg not install broken symlinks? apparently so); I guess that path should be fixed
<pitti> slangasek, doko__: want me to fix this?
<pitti> Sweetshark: so I guess what's happening is that dpkg simply ignores broken symlinks; that sounds wrong to me, but I have no other explanation as the libgcj-bc doesn't have any maintainer scripts
<Sweetshark> pitti: k
<pitti> smb`, cjwatson: it seems that linux-ports-meta is obsolete in natty, linux-meta builds the ports as well; correct?
<cjwatson> that's what I vaguely remember but I'd check Sources/Packages before believing me :-)
<cjwatson> it certainly looks that way
<pitti> cjwatson: I looked at the binary packages produced by linux-meta
<pitti> I better wait for smb's confirmation, though
<cjwatson> $ M -S linux-ports-meta
<cjwatson> linux-ports-meta | 2.6.35.24.18 |         natty | source
<cjwatson> suggests so
<pitti> cjwatson: man brainstorm implementation> awesome turnaround time! *applauds*
<cjwatson> pitti: you're welcome :)
<doko__> pitti, slangasek: sounds fine. I assume we need to move /usr/lib/gcj, used by the -gcj packages in the mid-range term too
<pitti> doko: hm, that dir is not shipped by gcc-defaults, is it? I don't have it here, anyway
<doko> pitti: yes, but used/created in update-gcj-db
<fta> popcon needs a fix for the multiarch thing
<smb> pitti, cjwatson ports and the rest had been building from the same source package before but I think that I remember something about merging back the meta package as well for natty. Let me check to be sure
<smb> pitti, So the normal package generates omap, versatile and powerpc stuff. And afaik powerpc is the only ports things left beside of arm
<pitti> smb: right now linux-ports-meta does not produce any binaries any more, and wants to go to universe; so I wondered if we should just remove it completely as it's obsolete
<smb> pitti, At the danger of getting beatings from Andy, but I would also think that is obsolete and can go.
<pitti> smb: well, easy enough to reupload if it should get useful again :)
<pitti> doko: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gcc-defaults/natty/revision/58 works here
<smb> :) right
<ubottu> Error: Launchpad bug 58 not found
<pitti> doko: ok to upload that? (kinda urgent, as it breaks the LibO build)
<doko> pitti: sure, looks good. would be nice to introduce a with_multiarch macro to be able to build on older releases
<pitti> doko: you mean dynamic by parsing debian/changelog, or just a switch on the top?
<doko> switch on the top
<doko> # is this a multiarch-enabled build?
<doko> ifeq (,$(filter $(distrelease),lenny etch squeeze wheezy sid dapper hardy jaunty karmic lucid maverick))
<doko>   with_multiarch_lib := yes
<doko> endif
<pitti> doko: shouldn't that be natty only?
<pitti> ah, nevermind
<pitti> sure, doing
<yofel> pitti: why does apports postinst script error out again if it can't start apport? (bug 723670 and bug 741436)
<ubottu> Launchpad bug 723670 in apport (Ubuntu) "package apport 1.18-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Triaged] https://launchpad.net/bugs/723670
<ubottu> Launchpad bug 741436 in apport (Ubuntu) "apport won't install in a natty chroot on a Debian squeeze machine, due to missing upstart" [Undecided,New] https://launchpad.net/bugs/741436
<yofel> it runs 'invoke-rc.d apport start || exit $?' - shouldn't that be '|| exit 0' ?
<yofel> or is that a bug in dh_installinit?
<pitti> yofel: that seems to be a regression in either dh_installinit or in upstart itself
<pitti> yofel: the pre-start script is meant to exit with nonzero if the service shouldn't be started, AFAIUI (and it was Keybuk himself who wrote this code, too)
<yofel> ah, it doesn't though, it checks "[ "$enabled" = "1" ] || [ "$force_start" = "1" ]" which both return 1 in this case and thus the script itself returns 1
<pitti> right, that will keep it from starting
<pitti> and in maverick the postinst didn't freak out because of that
<pitti> there might be a newer way of blocking a service from starting, of course
<pitti> jhunt_: ^ did that change recently?
<pitti> doko: does that snippet come from another package? do you parse $(distrelease) from dpkg-parsechangelog?
<pitti> doko: or from lsb_release?
<doko> distrelease     := $(shell lsb_release -cs)
<pitti> ah, ok
<jhunt_> pitti: is this bug 707971 once again?
<ubottu> Launchpad bug 707971 in upstart (Ubuntu Natty) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [Critical,Fix released] https://launchpad.net/bugs/707971
<jhunt_> pitti: if so, I believe it's with slangasek
<pitti> jhunt_: looks like it; at least it's the same symptom
<chrisccoulson> dholbach, does opening links in tbird work for you now? it works for me, but the reporter of bug 709216 says it isn't fixed for him
<ubottu> Launchpad bug 709216 in thunderbird (Ubuntu) "clicking on a link dont open the page " [Low,Triaged] https://launchpad.net/bugs/709216
<chrisccoulson> (although, he did say it was fixed once already and then changed his mind again, so i'm not sure how much i trust him)
<pitti> doko: tested for both cases, works; pushed
<doko> Sweetshark, pitti: libtextcat tries to pull in automake1.7 ... whoever did propose/sync this ...
<pitti> doko: already at it
<pitti> (fix uploaded already)
<doko> ;p
<pitti> hm, I tried to revive the three broken armel buildds, but no luck; I'm afraid that's a lamont problem
<lamont> pitti: yes.  and many thanks to the big phat packages that keep knocking them down in a row as they get retried on subsequent builders
<pitti> poor armel :(
<lamont> I'm specifically waiting for a new openjdk before I even worry about the buildds, since it's just gonna knock them over again
<lamont> (and that's inbound, I'm told)
<pitti> ogra_, didrocks: sorry, I think we already talked about it, but what was the decision about ubuntu-netbook{,-efl}-default-settings? remove or demote?
<didrocks> pitti: I think we decided to remove it, isn't it ogra_ ?
<ogra_> pitti, keep in universe for someone to adopt
<pitti> they want to go to universe, but no point in keeping them in the archive if nobody will look after them any more
<didrocks> ogra_: do you stil have the netbook-efl-launcher?
<didrocks> still*
<pitti> isn't it unity-2d now?
<ogra_> no
<didrocks> so, no point to have the settings package? no more netbook-launcher nor its -efl brother
<ogra_> we dont use it, but there are some linaro partners that have interest in taking oveer efl stuff
<ogra_> -settings can surely go
<ogra_> buut keep the binaries
<pitti> ok; I see we have netbook-launcher-efl in universe still as well, so we shoudl keep the efl-default-settings as well
<ogra_> if nobody adopted it by OO we can still drop it
<pitti> but I think we should remove ubuntu-netbook-default-settings
<ogra_> efl-default-settings can go too
<pitti> ok
<ogra_> just keep the binaries for the apps
<pitti> right
<ogra_> so there is something for someone to pick up and work with
<pitti> *flush*
<soreau> Ok guys, can someone please clarify this for me about jockey? What do you have to do to make drivers appear in jockey?
 * didrocks waves byebye to the settings :)
<pitti> ogra_: x-loader-omap4 wants to go to universe as well; is it still being used?
<soreau> It seems removing the modalias packages removes drivers from the list but reinstalling them does not make anything reappear in jockey
<pitti> soreau: have hardware who needs them, usually
<pitti> soreau: the modalias packages are obsolete and shoudl be removed on upgrade
<ogra_> pitti, i dont think so, need to check, but i think it can actually be removed
 * ogra_ checks code 
<soreau> pitti: I dont get it though. You have a card supported by binary drivers, remove modalias packages and disappears from jockey
<pitti> ogra_: no rdepends, anyway
<soreau> Install modalias and they do not reappear
<soreau> what is the deal?
<pitti> soreau: hang on, are you on 10.10 or natty?
<soreau> How do you make drivers appear in jockey? (provided you have the hardware)
<ogra_> pitti, thats a binary ?
<soreau> pitti: It doesnt matter what I am using
<pitti> ogra_: source package
<ogra_> hmm
<pitti> soreau: it matters a lot
<soreau> this is a question so I can do better support
<soreau> pitti: Not my problem, I use all open drivers
<pitti> soreau: in 10.10 we used the modalias packages, in natty we dropped them
<soreau> But you are avoiding my question
<ogra_> pitti, can go, the new package is "x-loader" ... note that our bootloaders never have rdepends ;)
<pitti> soreau: I can't give you a definitive answer before you tell me which release you are running on
<soreau> <soreau> pitti: Not my problem, I use all open drivers
<pitti> soreau: so *shrug*, my answer is: if you are on 10.10 or below, you need to have the modalias packages installed for jockey to work
<soreau> Ok thats all you had to say
 * pitti is confused now -- was I being offensive?
<Kmos> not at all
<pitti> ogra_: aanyway, x-loader-omap4 is both a source and a binary, and no rdepends at all
<pitti> ogra_: package was introduced in maverick
<nobuto> mvo: I have gathered affected locales list for Bug #573502 in Ubuntu Translators mailing list.
<nobuto> mvo: It would be great if you will disable loading translations to the locales on the list https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/573502/comments/13
<ubottu> Launchpad bug 573502 in Ubuntu Japanese Kaizen Project "unreadable characters in recovery mode" [High,Triaged] https://launchpad.net/bugs/573502
<ubottu> Ubuntu bug 573502 in Ubuntu Japanese Kaizen Project "unreadable characters in recovery mode" [High,Triaged]
<mvo> thanks nobuto
<pitti> Kmos: (sorted it out in /query now..)
<ogra_> pitti, right, in natty linaro introduced x-loader (with no suffix) so the source with suffix can go
 * pitti cruft busting more
<dholbach> chrisccoulson, works for me too
<ogra_> hmpf ... so i uploaded metacity 2.30.3-0ubuntu7 but didnt get any mail for it
<chrisccoulson> dholbach, thanks. i guess the reporter has either messed up their configuration or hasn't actually upgraded everything yet
<pitti> ogra_: didn't land on LP either; the most common cause is an unsigned source.changes
<dholbach> chrisccoulson, or not restarted the session
<chrisccoulson> dholbach, yeah, possibly ;)
<pitti> ogra_: looks better now :)
<ogra_> yep
<ogra_> i re-rolled the source package
<ogra_> weird thogh, i'm sure i signed the first time too
<mvo> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: smoser, mvo
<doko> bdrung: lintian ping
<soren> pitti: for me, dput refuses to upload unsigned .changes.
 * dholbach hugs mvo
<bdrung> doko: i made some progress, but still some issues left: http://paste.ubuntu.com/584244/
<doko> bdrung: nice!
<bdrung> doko: two issues remain: 1. dpkg-source fails in one test. 2. the test complains about the ubuntu changelog entries
<ximion> hi!
<ximion> could someone please apply my patch against packagekit pkg and upload the new packagekit package?
<ximion> https://bugs.launchpad.net/ubuntu/+source/xulrunner-2.0/+bug/740815/+attachment/1936588/+files/packagekit_0.6.11-2ubuntu2.debdiff
<ubottu> Ubuntu bug 740815 in Mozilla Firefox "[FFe] Updates to enable us to drop xulrunner from main" [Medium,In progress]
<ximion> solves the bug mentioned above
<ximion> (I cannot request sync with Debian this time, cause we're still waiting on some deps for the new PK version to enter unstable)
<bdrung> kees: your last upload of tiff let's vlc 1.1.8-1ubuntu1 fail to build: libtool: link: `/usr/lib/libtiff.la' is not a valid libtool archive
<fta> slangasek, multiarch? http://paste.ubuntu.com/584828/
<micahg> bdrung: whichever file references that one needs dependency_libs emptied
<bdrung> micahg: that's the end of the build log: http://paste.debian.net/111812/
<micahg> bdrung: here's the culprit: libsdl-image1.2-dev
<micahg> bdrung: dependency_libs needs to be emptied at build time
<ari-tczew> ogra_: https://code.launchpad.net/~om26er/ubuntu/natty/metacity/metacity-fix-717216/+merge/52199 you should upload with Omer's d/changelog entry.
<ubottu> Ubuntu bug 52199 in darcs (Ubuntu) "darcs-server cache dir" [Low,Fix released]
<ogra_> ari-tczew, to late :)
<ari-tczew> ogra_: yes, but please remember about that in future.
<ogra_> hard to do if you have to mangle the patch
<bdrung> micahg: what's the best way to do that?
<ogra_> but yes, next time if we have more time i'll ask him to do the origin and upstream bug entries himself
<ari-tczew> ogra_: it is possible, trust me ;)
<ogra_> i know that its possible
<ari-tczew> debuild -kYOURKEYOREMAIL
<micahg> bdrung: I did it in gtkglext, following the example of gnome-pkg-tools clean-la.mk file, there have been several similar uploads in the past week
<ogra_> ari-tczew, the version was outdated, i had to do changes to the patch too ... so i decided to make a new changelog entry
<bdrung> micahg: thanks
<ari-tczew> ogra_: your choice, but it makes sometimes contributor unhappy.
<ogra_> its not that i didnt mention him or anything
<ari-tczew> I know
<ari-tczew> but some contributors like to have his patch as uploaded package
<ogra_> well, then i would have had to ask him to do the changes
<ari-tczew> and sponsoring means that we should keep their changelogs
<ogra_> which would likely have resulted in that patch not making the freeze
<ari-tczew> if wouldn't be there entry in d/changelog, then fine
<ogra_> i'm happy to explain what i do if i do it to people that want to complain to me
<ari-tczew> ogra_: I'm stopping this discussion at this moment as some persons here will take this as attack (which is not...). I gave you only my views.
<matttbe> Hello,
<matttbe> I'm from Cairo-Dock team and I want to update Cairo-Dock packages on Ubuntu. I've opened two bug reports (cairo-dock and its plug-ins) one month ago with two linked branches: https://code.launchpad.net/bugs/723994 & https://code.launchpad.net/bugs/723995
<ubottu> Ubuntu bug 723994 in cairo-dock (Ubuntu Natty) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version" [Wishlist,New]
<ubottu> Ubuntu bug 723995 in cairo-dock-plug-ins (Ubuntu) "Please update Cairo-Dock Plug-ins to 2.3.0~0rc1 version " [Undecided,New]
<matttbe> The merge proposal status is still marked as "Needs Review" and micahg said to me that I've to contact mvo about these merge proposals: https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock/2.3.0-0rc1/+merge/51034 & https://code.launchpad.net/~cairo-dock-team/ubuntu/natty/cairo-dock-plug-ins/2.3.0-0rc1/+merge/51035
<ubottu> Error: Launchpad bug 2 not found
<ubottu> Error: Launchpad bug 2 not found
<mvo> matttbe: I have a look now
<matttbe> I also want to note that we can't use the Debian versions because they don't respect what the upstream want to have (a bug has been reported about that) and the sponsoring said that "the merges were missing the original tarballs from upstream (upstream tag in UDD)"
<matttbe> mvo: thank you!
<slangasek> YokoZar: sorry, I was assuming you were familiar with grep-dctrl already - you have to pass it a path to your natty Packages file as an argument
<slangasek> pitti: odd, I know I tested libgcj_bc.so.1 earlier
<pitti> slangasek: it seems to work now, anyway
<mvo> matttbe: this needs a feature freeze exception from the release team, if that is granted I'm happy to sponsor the upload
<matttbe> mvo: thank you but how can I receive this FFe? (an ACK?) Who can I contact?
<BlackZ> matttbe: https://wiki.ubuntu.com/FreezeExceptionProcess
<matttbe> BlackZ: thank you :)
<mvo> matttbe: #ubuntu-release may help, but the usually process them via bugreports, not via irc (and what BlackZ said)
<jelmer> barry: hi
<Sweetshark> pitti: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest <- there is a libreoffice version in there, l10n is in /home/bjoern/lo33/ on chinstrap
<slangasek> pitti: did you have to change something to get it to work?
<matttbe> mvo: ok I will do that!
<mvo> good luck :)
<Sweetshark> pitti: ok, Im 20 minutes late, but I still get twiddlefingers from libreoffice packaging.
<barry> jelmer: hi.  wanna chat about udd+uds?
<pitti> slangasek: yes, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gcc-defaults/natty/revision/58
<micahg> mvo: skaet said to ping her when it was in shape, I already discussed with her before but the actual update was some days off
<ubottu> Error: Launchpad bug 58 not found
<micahg> mvo: re cairo-dock
<pitti> slangasek: (and r59 for beautification)
<slangasek> pitti: oh, this symlink is in gcc-defaults... that'll be how I missed it, sorry
<pitti> slangasek: no problem at all :)
<pitti> slangasek: this libgcj-bc is a horrible hack..
<slangasek> jhunt_: hmm, what's this about bug #707971 resurfacing?
<ubottu> Launchpad bug 707971 in upstart (Ubuntu Natty) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [Critical,Fix released] https://launchpad.net/bugs/707971
<Sweetshark> pitii: freedesktop bug 33915 / launpad bug 731556 seems not to be ubuntu only, but I still dont like it.
<pitti> Sweetshark: sponsoring..
<ubottu> Freedesktop bug 33915 in Libreoffice "user settings get lost after several restarts" [Major,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=33915
<ubottu> Launchpad bug 731556 in LibreOffice Productivity Suite "LibreOffice erases user settings, and block the use of interface styles..." [High,Confirmed] https://launchpad.net/bugs/731556
<mvo> micahg: aha, ok. was that writen in the bugreport? i did not see it there. happy to sponsor it if it has approval
<pitti> Sweetshark: did you get some more data for it?
<micahg> mvo: it was a "let's evaluate when it's ready type of thing", so no explicit ACK yet
<Sweetshark> pitti: well: it happens with our build and with the LO build, it happens on OpenSUSE. So its not just us. However, it still happens with 3.3.2, which I hoped would solve it (because some werent experiencing it anymore). Unfortunatly, still no easily reproducable scenario.
<jelmer> barry: Yes, that'd be great
<jhunt_> slangasek: sorry - it's not the same problem now I look at it more closely. But bug 741436 is rather nasty - invoke-rc.d calls /lib/init/upstart-job which fails since the environment outside the chroot doesn't have upstart installed.
<ubottu> Launchpad bug 741436 in apport (Ubuntu) "apport won't install in a natty chroot on a Debian squeeze machine, due to missing upstart" [Undecided,New] https://launchpad.net/bugs/741436
<jhunt_> slangasek: we can detect from within the chroot whether upstart is available outside it, but what I don't know is what we should do if upstart *isn't* outside. return 0 and not start the job? or error (as is currently happening anyway)?
<slangasek> jhunt_: ah; isn't the right behavior here to divert /sbin/initctl? :)
<jhunt_> slangasek: /bin/true?
<slangasek> yeah
<slangasek> that's part of a normal chroot setup, I think :)
<jhunt_> I haven't honestly tried that and I don't know what happens with the new version of upstart which... err... "sort of" has chroot support.
<jhunt_> slangasek: where "sort of" equates to "is broken" :)
<slangasek> heh :)
<jhunt_> slangasek: I guess we stick with divert until I've fixed chroots, which makes that bug invalid presumably as the chroot environment isn't setup as expected.
<jhunt_> slangasek: maybe we should package upstart to auto-detect when it's installed in a chroot and do the divert automatically?
<slangasek> I wouldn't
<slangasek> note that all server installations start out as a chroot unpack
<slangasek> for that matter, so do liveCD builds at some point
<jhunt_> slangasek: ah! right :)
<Chipzz> is there a proper way you can detect if you're being run in a chroot?
<Chipzz> can't immediately think of one myself
<jhunt_> Chipzz: "stat /" seems to work :)
<Chipzz> I'm wondering... how hard would things break if you did chmod o-x / ? :P
<Chipzz> or rather, what would not break :P
<cjwatson> there's a set of chroot detection runes that exists in various packages' maintainer scripts.  I'm with slangasek on this though
<Chipzz> cjwatson: well I was going to say (but I think you already guessed that) detect it at runtime
<cjwatson> (though perhaps, if it's emitting an error message, the error path could be augmented with chroot detection to make the message more helpful)
<Chipzz> then again, you would have to manually start upstart IN the chroot, which makes little sense I guess
<Chipzz> jhunt_: so what was the reason for diverting not being a valid solution?
<Chipzz> uh
<Chipzz> nevermind
<Chipzz> head full of snot, not focussed, meh. sorry
<jhunt_> Chipzz: I'm not saying it's not valid, but we're trying to add full chroot support to upstart atm, so the advice might change when that happens. Also, I was wondering at the possibility of not having to have to manually do the divert.
<Chipzz> jhunt_: right, I read the last lines of the discussion, then went to read the top of my screen, and somehow I managed to overlook "16:04 < jhunt_> slangasek: I guess we stick with divert..."
<Chipzz> jhunt_: hence why I said nevermind :)
<Chipzz> jhunt_: but how exactly are stat / inside and outside of a chroot supposed to differ?
<Chipzz> looking at the 2 and can't spot any obvious differences, but I'm probably overlooking it
<cjwatson> you stat / inside the chroot and compare it with /proc/1/root
<cjwatson> if they're different you're in a chroot
<Chipzz> ah k
<jhunt_> Chipzz: or [ `stat --printf="%i" /` != 2 ] && echo "in chroot" || echo "NOT in chroot"
<Chipzz> sth that did catch my eye too, is "Inode: 2"
<cjwatson> yes, though I wouldn't want to trust that as not being fs-specific
<jhunt_> cjwatson: true!
<Chipzz> inode 1 is the journal I think?
<cjwatson> also, it only means you're at the root of a filesystem; it does not mean you aren't in a chroot, since the chroot might start at the root of a filesystem
<Chipzz> thx :)
<Chipzz> that would make for a good question on a google interview :)
<SpamapS> yaaay.. bug #696996 is fixed now.. I can run unity all the time.
<ubottu> Launchpad bug 696996 in unity "Unity is offset down by difference in resolutions when Nvidia twinview is used" [Undecided,Triaged] https://launchpad.net/bugs/696996
<kim0> Hi folks .. Letting you know Ubuntu Cloud Days starting in 10mins in #ubuntu-classroom .. You can discuss in #ubuntu-classroom-chat .. Thanks
<shadeslayer> mdeslaur: Hi!
<mdeslaur> shadeslayer: hello
<shadeslayer> mdeslaur: Just wanted to inform you on the issue with the revoked certs and how rekonq/konqueror will handle it, a patch for QSslSocket is being formed as we speak, will track it and get back to you :)
<mdeslaur> shadeslayer: cool...thanks
<Pilif12p> I'm probably in the wrong channel, but in the 11.04a3 installer it has a screenshot of OpenOffice but it says LibreOffice.. I know that they're pretty much the same but it still says "OpenOffice.org" in the title bar.
<ScottK> Pilif12p: Please report a bug against the ubiquity-slideshow-ubuntu package.
<Pilif12p> okay
<pitti> kees, jdstrand: releasing lucid and maverick linux-mvl-dove linux-meta-mvl-dove to -updates and -security
<mdz> cjwatson, pitti, kees, TechnicalBoardAgenda says 1800 UTC but the calendar says 1700 UTC (US DST damage)
<cjwatson> mdz: earlier is better for me, but pick one I guess
<pitti> mdz: ^ same for me
<doko> Sweetshark: misusing the buildds as test machines? ;-P
<mdz> cjwatson, pitti - Keybuk is supposed to chair, and I believe he said he couldn't make the earlier time slot (when we were setting the new meeting time)
<mdz> I guess it depends on what kees and Keybuk are expecting
<pitti> ok, so 1800 UTC
<mdz> I have a dinner engagement this evening which I scheduled based on the 1700 time slot, so if it's 1800 I will have to leave early
<mdz> 1830 or so
<pitti> ok, 1830 WFM
<Sweetshark> doko: "yesterday it still worked"
<cjwatson> mdz: ok, let's make it 1800 and be snappy then
<mdz> cjwatson, ack
<mdz> pitti, thanks a lot for working on the brainstorm review
<jamespage> slangasek: are you avail. to discuss bug 737603 and how we resolve it?
<ubottu> Launchpad bug 737603 in openjdk-6 (Ubuntu) "JNI unable to find libpam.so" [High,Triaged] https://launchpad.net/bugs/737603
<slangasek> jamespage: sure
<jamespage> slangasek: excellent
<jamespage> so first things first - I am in no way saying that loading unversioned libraries is a 'correct' thing todo in Java
<slangasek> jamespage: yep - and I'm not meaning to block you from getting things fixed, I'm just pointing out that anything that does load_this_library("pam") is broken in all kinds of ways and I want to make sure we're not adding extra hacks we shouldn't need to in support of a fundamentally broken model
<jamespage> slangasek: I don't particularly like the way either the JVM or JNA does this stuff; but ultimately there is a bunch of code out there that depends on load_this_library("pam") working in some fashion on Ubuntu
<jamespage> (mainly because thats what Sun said should work way back in Java time)
<jamespage> slangasek: fundamentally libjna-java is a bit of a hack to make Java and native libraries work in some sort of fuzzy fashion
<pitti> mdz: you're welcome; first responses are already trickling in :)
<jamespage> slangasek: I'll fix to specific versions where I can in the Jenkins codebase (which will help not make this any worse)
<slangasek> jamespage: and was that working reliably before the switch to multiarch, as a result of the code in the standard library that pokes around the filesystem for something that matches the pattern lib${arg}.so.*?
<jamespage> slangasek: yes - but only because of the fuzzy matching that libjna-java provides as you state
<slangasek> and libjna-java is all bytecode, no jni bits of its own I guess? :)
<jamespage> So it does provide one native library which gets installed into /usr/lib/jni
<slangasek> ok
<jamespage> this is used to bypass the normal JVM loadLibrary call which does not work
<jamespage> it calls dlopen directly
<jamespage> but theres a bit of Java infront of that which scans an automatically generated library path to determine which absolute path name to pass to dlopen
<slangasek> but the path resolution is done in the java code, not in the native lib, so it's non-trivial to fix things to just pick up the correct library path at build-time -hmm
<jamespage> you got it - hence the nasty code in Java to build the path based on cpu etc... to be multi-path compatible.
<jamespage> sorry - mutli-arch
<jamespage> or even multi-arch
<jamespage> :-)
<slangasek> right
<slangasek> so yes, this is all very nasty, but I don't see any other viable short-term solutions
<jamespage> I agree - I think the best longer term solution is to work with dependent packages to fix to specific versions of libraries (which it does support) rather than using wildcards.
<slangasek> long-term, I think we should skip right over trying to handle the multiarch path in the native code and instead try to propagate the news that calling loadme("pam") is wrong
<slangasek> yep, seems like we're aligned
<slangasek> and just needed to get the realtime exchange here to verify this :)
<jamespage> agreed
<jamespage> So I'll complete the patch for libjna-java for Natty; hopefully we can then drop this at some point in the future
<slangasek> sounds good to me
<slangasek> so you'll fix up the armel handling and resubmit?
<jamespage> I'll also post to debian-java to generate some discussion around this; specifically moving to using versioned .so's with libjna-java.
<slangasek> (armhf can be deferred for now)
<jamespage> Yep - I'll update the branch to handle armel correctly as specified in the merge proposal.
<slangasek> great, thanks :)
<jamespage> I just need a quick check on what openjdk defines for os.arch on armel so if anyone has a bit of arm kit that could confirm much appreciated.
<slangasek> jamespage: toss me a quick'n'dirty java prog I can use to grab that from an arm system?
<jamespage> slangasek: OK - I'll stick something together now
<ScottK> slangasek: Aren't dirty and java program redundant?
<slangasek> ScottK: "quick" and "java program" aren't, and "quick&dirty" is a package deal ;)
<ScottK> True.
<ScottK> First time my wife did a program in Python after having done Java stuff she was SURE she was missing something because it was too easy.
<jamespage> slangasek: http://pastebin.com/Y2GEjz7a - drop it into a file called OSArch.java; javac OSArch.java; java OSArch should do the trick
<jamespage> ScottK: I know exactly how she felt :-)
<jamespage> slangasek: thanks for doing that.
<slangasek> ScottK: haha :)
<slangasek> jamespage: is it safe for me to build it on x86 and copy the result over to armel?  Otherwise I'll be waiting a bit for openjdk to install on my beagle :)
<jamespage> slangasek: should be - Java bytecode is mean't to run anywhere
<psusi> I still claim that Java was invented by C programmers as a means for universities to crank out crappy programmers so they couldn't compete for the older guys's jobs ;)
<slangasek> jamespage: yeah, I know that's the /theory/ ;)
<psusi> and I FINALLY decided to give python a shot recently and it's pretty sweet
<jamespage> slangasek: well you never know...... :-)
<kees> slangasek: how do I get a list of the i386 packages I have installed on my amd64 system? apt-cache policy isn't much help
<slangasek> kees: dpkg -l '*:i386'
<kees> oh-ho! nice.
<jdstrand> pitti: hi! I am trying to use 'apport-collect 741908', and then get the familar "Waiting to hear from Launchpad about your decision..." in the terminal, but it opens in firefox and I get "Not allowed here" (logged in as jdstrand)
<pitti> jdstrand: le huh?
<jdstrand> pitti: I feel I am missing something-- does apport stash its creds somewhere?
<pitti> jdstrand: yes, it's supposed to, and seems to work her
<pitti> e
<pitti> ~/.cache/apport/launchpad.credentials
<jdstrand> k
<pitti> jdstrand: that should even continue to work with the old tokens (by-app), it shouldn't insist on a per-machine one
<jdstrand> pitti: ok, I removed that and it worked. I had removed a bunch of crufty authorizations a little while ago and it seems apport was using a cached one that I removed in LP
<jdstrand> pitti: all is well now, thanks!
<pitti> jdstrand: ah, good
<ScottK> pitti: Would you have a moment to do the sync in Bug 741886?  It'd be nice to get it in before Beta 1 freeze.
<ubottu> Launchpad bug 741886 in python3-defaults (Ubuntu) "Sync python3-defaults 3.2-1 (main) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/741886
<pitti> ScottK: sure
<ScottK> pitti: Thanks.
<kees> slangasek: I'm completely at a loss on how ia32-libs loads libraries. in a chroot, /usr/lib/nspluginwrapper/i386/linux/npviewer.bin loads fine. LD_DEBUG=libs ... shows the /lib32 paths. "ldconfig -v" does not. and on my real machine, I cannot run npviewer.
<slangasek> jamespage: $ java OSArch
<slangasek> arm
<slangasek> kees: hrm, I'm not sure how that's meant to work
<slangasek> let me poke around here
<slangasek> kees: ldconfig -v doesn't show it because ldconfig belongs to the 64-bit libc, which doesn't know about lib32, and ia32-libs doesn't install anything to /etc/ld.so.conf*
<slangasek> kees: or rather, libc6-i386 doesn't
<cjwatson> Keybuk: are you available to chair the TB meeting today?
<cjwatson> (hi :-) )
<slangasek> kees: so the question is whether libc6-i386 still has the right built-in library path, or if we managed to break that with multiarch
<slangasek> kees: er... no, more than that.  if you have libc6:i386 installed, this *replaces* libc6-i386's linker
<slangasek> because they're the same filesystem path, obviously
<Keybuk> cjwatson: yup
<cjwatson> great
<cjwatson> whoops
<slangasek> kees: so I guess as a bandaid, libc6:i386 needs to know about /lib32
<kees> slangasek: hhmmm.
 * cjwatson hears dinner being dished up
<cjwatson> perhaps I ought to have warned Kirsten about the meeting :-/
<kees> I uninstalled libc6:i386... perhaps I need to reinstall ia32-libs now
<slangasek> kees: oh, haha
<slangasek> yeah, that would also do it
<kees> slangasek: well, I mean, I uninstalled libc6:i386 as part of the debugging process.
<slangasek> as /lib/ld-linux.so.2 would be missing now
<slangasek> ah, right
<slangasek> so yes, reinstalling ia32-libs should bring back the linker that knows about lib32
<slangasek> I think we should have libc6-i386 install an ld.so.conf snippet to deal with this, rather than embedding lib32 knowledge in libc6:i386
<kees> sudo apt-get --reinstall install libc6-i386  <- fixed it
<slangasek> yep
<slangasek> and sudo apt-get install libc6:i386 should break it again
<kees> and all that snippet should look like would just be adding /lib32 and /usr/lib32 ?
<slangasek> yep
 * kees attempts
<kees> winning
<xjunior> My sound device stopped work. I'm on natty, living in the edge. can you help me to figure out why, maybe fix it or at least help the ubuntu dev team to fix this for future releases?
 * bcurtiswx drum hits
<shadeslayer> xjunior: support in #ubuntu+1
<kees> slangasek: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/741949  look right?
<ubottu> Ubuntu bug 741949 in eglibc (Ubuntu Natty) "libc6-i386 co-installed with libc6:i386 breaks ia32-libs" [Low,New]
<slangasek> kees: yeppers
<pitti> ev: for bug 723813, should we now close the ubiquity task as "wontfix" as well?
<ubottu> Error: Launchpad bug 723813 could not be found
<psusi> keybuck is a frigging genious.  he made mountall so smart, at first I thought it was a bug for ignoring the fsck order argument in fstab, but he actually figures out what fs are on the same physical disk, and uses ionice to make sure only one fsck at a time has priority access to the disk.
<jamespage> slangasek: thanks - made a good first guess in that case!
<ev> pitti: I don't agree with the decision, but far be it from me to co-opt the entire installer team in such a manner. Go ahead.
<pitti> ev: ok; at least it's not through your own hand then :)
<ev> indeed
<Keybuk> psusi: I'm afraid I can't take the credit ;)
<Keybuk> ion wrote that code
<pitti> Laney, directhex, hyperair, RAOF: we are currently trying to get rid of the obsolete xulrunner-1.9.2 (discontinued upstream, open security holes), see bug 740815; the one remaining rdep is libgluezilla, which is only needed by libmono-webbrowser0.5-cil, which is only needed by libmono-cil-dev and libmono-winforms2.0-cil
<ubottu> Launchpad bug 740815 in xulrunner-1.9.2 (Ubuntu) "[FFe] Updates to enable us to drop xulrunner from main" [High,In progress] https://launchpad.net/bugs/740815
<chrisccoulson> pitti - xulrunner-1.9.2 isn't quite discontinued yet, but it probably will be soon
<pitti> Laney, directhex, hyperair, RAOF: as libmono-webbrowser0.5-cil does not have any other dependencies, would it be possible to just disable this?
<directhex> pitti: it will have no adverse effects on in-archive apps, but will prevent any apps written on Windows which use the WebBrowser widget from working
<chrisccoulson> directhex, so, we don't have any applications in the archive using it?
<pitti> directhex: I guess there is no way to use webkit for that?
<pitti> chrisccoulson: if so, they should depend on it surely?
<directhex> pitti: i can give you a slight improvement, a gluezilla snapshot which will build (but not run) against 2.0. well, it'll run until the garbage collector tries to work, at which point it'll go "clunk"
<pitti> directhex: by "no way" I mean "already supported in the source", not "someone with infinite time could code it"
<kees> micahg: wow... a _lot_ of packages have bad dependency_libs :(
<chrisccoulson> directhex, the issue is that 2.0 will be unsupported 3 months after natty release
<chrisccoulson> and we just can't realistically provide security support for it
<pitti> directhex: we are eliminating xulrunner-2.0 from main as well, though
<directhex> chrisccoulson: which is why i've been encouraging andreia to move from gluezilla to webkit-sharp to provide that widget. it's now possible with webkit 1.3, but only half finished
<pitti> directhex: ah, it's great to hear that this is already underway, though!
<directhex> she was going to push to git, let me see if she did
<chrisccoulson> thanks
<directhex> i've pinged her
<directhex> she did mention something about the webkit gir files being wrong, though
<pitti> directhex: oh, mono is using GIR and GI now?
<pitti> directhex: perhaps you can get her in contact with me, I might be able to help fixing up the annotations
<directhex> pitti: there are a few efforts underway to produce (for now) static bindings from .gir source, by converting from gir to mono's gobject codegen format (gapi)
<pitti> directhex: I did quite some GTK and other library annotation fixes in the past
<pitti> directhex: awesome; that's similar to the current vala approach
<pitti> directhex: fixing the webkit gir would be useful for other areas as well
<pitti> directhex: perhaps she could file a bug somewhere and subscribe me?
<directhex> pitti: i'll try to get her in direct contact with you, once she shows signs of being online
<pitti> directhex: cool, thanks
<directhex> pitti: she's in .pt timezone, so that shouldn't be too difficult to do
<pitti> Portugal?
<directhex> yeah
 * pitti toddles of for some late dinner at last
<directhex> yeah, i need to go cook
<chrisccoulson> directhex, pitti - thanks!
<directhex> chrisccoulson: i hoped it had a little more time for this one. i first noticed there was an imminent issue when rebuilding gluezilla against xulrunner in debian experimental
<directhex> although the debian mono team has always advocated s/xulrunner/webkit/ for everything we do, since the binding is so much cleaner. apparently this wasn't possible for replacing gluezilla due to lack of DOM access, until webkit 1.3 added it
<chrisccoulson> yeah, webkit seems more supportable right now
<directhex> i've been bugging andreia to move gluezilla to webkit for about 2 years now ;)
<slangasek> kees: yeah, I'm cleaning up libgd2 just now, so I can finish fixing the php5 ftbfs.  Are you looking into the bad dependency_libs problem as a whole?
<kees> slangasek: I am, yes.
<kees> slangasek: I have _34_ packages in the archive that ship .la files with dependency_libs listing /usr/lib/libjpeg.la
<slangasek> kees: we obviously want to prioritize the ones that point at .la files that have moved for multiarch... right, like those :P
<slangasek> 34 source or binary?
<kees> binary. source is...
<kees> 28
<kees> 7 in main
 * slangasek nods
<RoAkSoAx> howdy, is there a tool that checks if the dependencies for a certain packages are already in main?
<RoAkSoAx> or to see if all the packages in a seed are in main?
<kees> anyway, I have an optimized archive searching tool that can find these, so I can try just handing it a list of all the libs that are multiarch now
<slangasek> kees: cool - would love to have at that list
<slangasek> 28 is probably too many to want to fix up properly, we might just fire some no-change rebuilds to get this unblocked
<kees> slangasek: I'm going to build a list of the shipped .la files in multiarch libs and then from there generate the list of packages listing them...
<slangasek> ok
<slangasek> I was thinking in terms of : grab the list of multi-arch: same libs; grab all -dev packages that are reverse-dependencies of those libs; grab all -dev packages that are reverse-dependencies of those, and look for non-empty dependency_libs
<kees> slangasek: a no-change rebuild will fix up the paths, but not really solve the problem ultimately, right?
<slangasek> correct
<kees> http://paste.ubuntu.com/585027/ <- my work plan
<slangasek> yep, that can also work
<slangasek> and will pick up those -dev packages that are broken because they don't actually have deps on the other -dev packages
<slangasek> like libjasper
<kees> yeah. grr :)
<kees> slangasek: do you have a la-cleaner snippet for "classic" debhelper? I've only found dh(1) and cdbs
<slangasek> kees: Debian bug #619210 for an example
<ubottu> Debian bug 619210 in meanwhile "meanwhile: please wipe out dependency_libs from .la files (Policy 10.2)" [Normal,Open] http://bugs.debian.org/619210
<kees> thx
<kees> hm, maybe I'll use $$(find debian/tmp/usr/lib -name '*.la') ...
 * slangasek reads over that bug report and goes cross-eyed.  "As long as meanwhile"? Stupid plain english package names
<slangasek> kees: yeah, that's more future proof; otoh it's a minor thing to fix up the path when multiarch arrives
<slangasek> frankly, it's libtool - whatever stops it is good enough IMHO ;)
<kees> can't we fix libtool instead?
 * slangasek waves his hands vaguely
<slangasek> part of the problem is that libtool is embedded in upstream software releases
<kees> yeah, I figured "no" since it could break non-distro builds
<kees> yeah
<mvo> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature 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: smoser
<slangasek> lool: Debian bug #458851 is a problem for avahi multiarchification.  what would you recommend here?
<ubottu> Debian bug 458851 in libavahi-common-data "Ships arch-dep file in /usr/share" [Minor,Fixed] http://bugs.debian.org/458851
<RoAkSoAx> cjwatson: howdy! You might be able to help me. I need to know if all the packages(and dependencies) of a seed (UEC) are in main.  Is there a tool that allows me to do that?
<hallyn> jbernard: hey, are you familiar with the libcgroup security update in squeeze?  I just did a 'bzr branch lp:debian/squeeze/libcgroup' but don't see the claimed fix...
<cjwatson> RoAkSoAx: everything in the ubuntu.natty seed collection (which contains uec) is either in main or will show up as a candidate for promotion on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<sladen> cjwatson: is there anything that uses connman.  There a request for a missing icon, but if it's not shipped somewhere as a default and not subject to UI freeze I won't bother
<cjwatson> sladen: it's in universe; if there is, it can't be anything we ship by default
<slangasek> lool: disregard, --libdir is automatically putting the db file in /usr/lib/<triplet>, so I guess it can be M-A: same
<lool> slangasek: Eh ok
<lool> slangasek: was just closed apparently?
<lool> From unknown Thu Mar 24 21:12:03 2011
<lool> slangasek: sjoerd just closed with an upload
<slangasek> that's weird
 * kees wonders why lintian doesn't scream about dependency_libs
<slangasek> lool: I didn't even notice that, I was looking at a comment you made about this bug in an /old/ changelog :)
<slangasek> lool: indeed, the closure is from 2008
<slangasek> really, the question was whether to move this file to the multiarch dir or to figure out how to make it arch-indep
<slangasek> the naive solution does 1) for me, so I'm happy
<pitti> RoAkSoAx: I checked bug 738757, will take care of it
<ubottu> Launchpad bug 738757 in hdparm (Ubuntu) "spindown settings lost on pm-suspend indirectly affects powernap power savings" [Undecided,Triaged] https://launchpad.net/bugs/738757
<bdrung> pitti: i can't install libtextcat-dev, because it wants to install libtextcat-data and remove libtextcat-data-utf8, which leads to a libreoffice removal
<pitti> bdrung: -utf8 is gone indeed; we currently have a libo rebuild going on which ought to fix that, though
<bdrung> ok, thanks
<kees> slangasek: 119 source packages need dependency_libs cleaning. 20 in main. (minus 2, since you just did libgd2 and I just did jasper)
<slangasek> kees: manageable.  Where's the list?
<kees> http://paste.ubuntu.com/585057/
<slangasek> kees: which end of the alphabet do you want to start from? :)
<kees> djvulibre fontforge imlib2 libgphoto2 libwmf are already on my list due to libjpeg6b upload breakage
<slangasek> ok, I'll start from the tail end then
<RoAkSoAx> pitti: awesome! thank you!
<RoAkSoAx> cjwatson: ok thanks ;)
<RoAkSoAx> win 21
<RoAkSoAx> arg
<kees> /usr/share/cdbs/1/rules/clean-la.mk:38: *** missing `endif'.  Stop.
<kees> aaarg
<pitti> weird, when did that break? we ahve used clean-la for ages
<pitti> ah, r192
<pitti> kees: want me to upload a quick fix?
<pitti> or are you at it?
<kees> pitti: I'm stuck in some other things; if you have it handy, that would be great
<bdrung> doko: bug #742092
<ubottu> Launchpad bug 742092 in lintian (Ubuntu) "lintian FTBFS" [High,New] https://launchpad.net/bugs/742092
<shana> evening
<directhex> moo!
<shana> aah!
 * shana pokes cow
<shana> so
<shana> who do I need to poke?
<shana> pitti?
<pitti> hello shana, how are you? you are the mistress of mono webkitification?
<shana> yesh
<pitti> pleased to meet you :)
<pitti> shana: directhex mentioned that you had some trouble with the webkit gir, and I wondered if I could help out
<shana> I was appointed the browser bindings mistress as a consolation prize for not working on the moonlight hackathon back in 2008
<shana> yeah, all the parameter names on signals are wrong
<shana> for instance, <glib:signal name="hovering-over-link"> has <parameter name="object" transfer-ownership="none">
<shana> note the "object" name on the parameter
<shana> all parameters seem to follow the pattern "object", "p0", "p1", "p2", etc
<pitti> shana: that sounds like default names due to missing annotations indeed
<pitti> shana: do yo know if there is a bug report for this already, perhaps even with a small test case?
<shana> I just stumbled upon it last night, haven't opened any bugs on it yet
<pitti> shana: I'm about to go to sleep, and won't have time tomorrow, but I think I could work on that next week
<shana> I just finished fixing up the gir for 1.3 with the proper names, some signals are hard to figure out
<shana> pitti: cool cool
<pitti> kees: there, fixed cdbs
<shana> pitti: I can get you versions of the 1.2.5 and 1.3 gir files with correct names, if it helps
<kees> pitti: great, thanks!
<pitti> shana: you hand-edited them, or you patched the source to build them correctly?
<shana> hand-edit, haven't had time to go through the source yet to fix it
<directhex> i couldn't even see where the gir is generated in the webkit source
<pitti> shana: it certainly can't hurt, then at least we could compare the autogenerated one to your's
<directhex> there's no .gir.in or anything fancy like that
<shana> pitti: do you want me to open up a bug somewhere?
<pitti> directhex: no, it's generated from the source .c files (or .cpp)
<pitti> shana: that would be useful, with above example signal (and attach your files there)
<shana> nod
<shana> where?
<pitti> much easier for tracking
<pitti> shana: upstream or launchpad, whatever you prefer
<pitti> we'll need an upstream bug eventually anyway, of course
<directhex> i wonder if anyone in the office knows about this issue
<shana> oh man, I haven't been to webkit's bugzilla in such a long time
<pitti> oh man, most critical bug ever -- stop shipping webkit! https://bugs.webkit.org/show_bug.cgi?id=19371
<ubottu> bugs.webkit.org bug 19371 in Evangelism "WebKit Needs T-Shirts" [Enhancement,New]
<shana> seriously?
<shana> hehe
<pitti> shana: I can't find an existing upstream bug report, anyway
<shana> I don't think anyone is really using gir actively
<pitti> shana: well, we do in Ubuntu now
<pitti> shana: we have about 6 packages ported from pygtk to pygi
<pitti> more to come in oneiric
<shana> I still don't quite understand why there's virtual-method and glib:signal nodes for the same things
<shana> where's the xsd for the gir format?
<seb128> GNOME3 does as well, well for a definition of  'actively', they don't use python a lot
<pitti> shana: http://www.piware.de/tag/gobject-introspection/
<pitti> seb128: they do use it with javascript, though?
<pitti> shana: I don't think they have a schema
<seb128> pitti, well, they have the gnome-menus gmenu-simple-editor or some applets ported to gi pygtk3
<pitti> seb128: I thought gnome-shell is all over this stuff
<seb128> rather "pygobject gi gtk3"
<seb128> pitti, right, it is, I was speaking about python gi
<shana> it's a shame people don't rely on schemas, you can do some really nice things with xsd
<seb128> pitti, g-s is gjs and gi indeed
<shana> like generate instant parsers
<shana> anyways
<shana> pitti: why virtual-method and glib:signal for the same thing (but not all)? what do they represent exactly?
<pitti> shana: I don't know details about these virtual-method thingies either, I'm afraid; the ones I saw were not something I'd ever call from a binding
<shana> hmmm
<shana> I need to figure out who's responsible for gir
<shana> if this thing is going to be a standard way of describing apis, it better be well nailed down
<pitti> #introspection on irc.gnome.org would know (in particular, J5 and tomeu)
<shana> ah, thanks!
<shana> pitti: I'll let you know about the webkig bug when I open it, bit on the tired side now :)
<directhex> aha, i knew i'd be able to blame someone at work
<shana> directhex: who?
<pitti> shana: thanks
<shana> in the meantime
<shana> webkit# bindings for 1.2.5 and 1.3 are almost done here
<directhex> shana: tomeu is a collaboran
<shana> and gluezilla is dead
<shana> well, suffering
<shana> directhex: aaaah, fingers to point, that's good :)
<directhex> shana: i've relaid your complaint on our internal irc ;)
<shana> yayness :)
<directhex> reaction from kov, that's a good sign
<shana> I wish I was there when it was drawn up, the multitude of non-default namespaces makes for very verbose xpaths
<shana> but I do like the way it turned out
<shana> minus the quirky signals thing
<pitti> shana: oh dear, http://launchpadlibrarian.net/66063126/buildlog_ubuntu-natty-i386.webkit_1.3.12-0ubuntu3_BUILDING.txt.gz shows two metric tons of annotation errors
<seb128> pitti, check with kov on #debian-gnome maybe if there is any work going on on that before starting
<pitti> but I still don't see an obvious error in the annotation
<directhex> each error weighs 4.29184549?
<pitti> seb128: yeah, will doo
<slangasek> pitti: cdbs> ah, missed that other ifndef up top, mistook the endif there for one I'd added :/
<directhex> kg, that is
<pitti> but before I'll get some sleep :) good night everyone!
<shana> missing transfer annotations
<seb128> pitti, he's maintaining webkit in debian and working on it upstream as well
<seb128> 'night pitti
<shana> those are important :P
<pitti> shana: yeah, all those will turn out to be not introspectable (i. e. not usable from bindings)
<directhex> seb128: kov implies it's not been seriously worked on
<seb128> ok
<shana> well, I ignore missing transfer annotations currently
<pitti> shana: but that doesn't affect signals
<pitti> shana: hmm, that sounds kinda dangerous
<shana> they're important for strings, for other objects not as bad
<shana> as in, things don't blow up for non-strings if the annotation is missing
<shana> but it's not good
<pitti> how so? treating "full" for "none" is a crash, treatin "none" for "full" is a memleak
<shana> exactly, they don't crash
<pitti> so just eating tons of memory then?
<shana> doesn't mean it doesn't leak and that's bad
<shana> engxactly
<shana> which is bad on a level 4.5, blowing being level 5 bad
<pitti> heh
<pitti> shana: what's the worst level on that scale?
<shana> I think that, in webkit's case, all those missing annotations are full
<shana> since webkit returns loose objects on the dom
<pitti> shana: stuff like webkit_dom_node_get_previous_sibling() is almost certainly "none"
<pitti> it would be very weird to return full copies during iteration
<shana> or none, orry, I might be confused
<shana> webkit returns shallow wrappers that can be disposed off at any time
<shana> iirc
<shana> it's not the actual real dom object, it's just a disposable accessor
<pitti> ah
<shana> which is totally annoying when you're trying to compare objects
<shana> I had to hack up a solution for that on moonlight for chrome
<shana> if there's a standard ownership for returned dom objects on webkit, even if the annotations are missing you can assume an ownership value on the gir
<shana> I don't know, I haven't eaten for a few hours and my brain is starting to go, so don't take my word for it :)
<pitti> shana: so, when I resume work on this I'll talk to kov?
<pitti> shana: I can certainly give a hand with fixing the annotations, but I'd like to coordinate this to get the patch merged quickly (as it'll be quite large and thus will bitrot quickly)
<pitti> shana: as for the signal ones, that needs a deeper look (and a built tree), will do that next week
<shana> kov does gir, right?
<pitti> shana: well, it was you who brought him up, wasn't it?
<shana> that was directhex
<shana> I think
<shana> :D
<pitti> shana: the gir gurus are mostly tomeu and J5, but there's a lot more people involved, of coruse
<shana> I think we're a bit too tired for this conversation :D
<shana> when you have the time to fix up the annotations, ping me and we'll coordinate
<shana> I think it might be useful for projects of this size to have a global default annotation for ownership that would be assumed for all methods unless otherwise defined there
<pitti> shana: I think webkit is a bit of a special case here due to the magic accessors, but it would be handy here indeed
<slangasek> kees: I think your search missed a few; I can't rebuild pacemaker to clear its .la because cluster-glue also has broken .las and is a build-dep of pacemaker
<slangasek> (and cluster-glue is not in your list)
<kees> slangasek: hrrrm
<kees> slangasek: ah, I only looked at packages named -dev
<kees> let me see what happens if I invert the list
<kees> yikes, this is a long list
<kees> only up to "e"...
<slangasek> invert it?
<kees> slangasek: "not -dev"   http://paste.ubuntu.com/585103/
<kees> slangasek: those are the source packages that ship binary packages in main not ending in "-dev" with offending .la files
<kees> slangasek: however, I see that cluster-glue is still missing
<slangasek> kees: well, cluster-glue's binary packages end in -dev anyway
<kees> weird.
<kees> egrep '^dependency_libs=.*lib(acl|atk-1|attr|db-4|db_cxx-4|db_java-4|curl-nss|curl|expat|expatw|freetype|gdbm|gdbm_compat|gio-2|glib-2|gmodule-2|gobject-2|gthread-2|gnutls|gnutls-extra|gnutls-openssl|gcrypt|gpg-error|jpeg|tasn1|pango-1|pangocairo-1|pangoft2-1|pangox-1|pangoxft-1|sqlite3|tiffxx|tiff|udev|gudev-1|ossp-uuid\+\+|ossp-uuid).la' $(find . -name '*.la')
<kees> ./stonith/plugins/stonith2/drac3.la:dependency_libs=' /usr/lib/libcurl.la -lbz2 /usr/lib/libxml2.la -lc -luuid -lrt /usr/lib/libglib-2.0.la /usr/lib/libltdl.la -ldl'
<kees> it certainly hits.
<kees> back later...
<kees> imlib2 hates me. won't build even before changes.
<kees> taking a break for a bit.
<slangasek> heh, heartbeat is /also/ a build-dep of pacemaker, right
<slangasek> guess I'll be doing that whole cluster
<jbernard> hallyn: you should see patches in debian/patches for CVE-2011-1006 and CVE-2011-1022
<ubottu> Heap-based buffer overflow in the parse_cgroup_spec function in tools/tools-common.c in the Control Group Configuration Library (aka libcgroup or libcg) before 0.37.1 allows local users to gain privileges via a crafted controller list on the command line of an application.  NOTE: it is not clear whether this issue crosses privilege boundaries. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1006)
<ubottu> The cgre_receive_netlink_msg function in daemon/cgrulesengd.c in cgrulesengd in the Control Group Configuration Library (aka libcgroup or libcg) before 0.37.1 does not verify that netlink messages originated in the kernel, which allows local users to bypass intended resource restrictions via a crafted message. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1022)
<hallyn> jbernard: hm, maybe the bzr tree didn't get updated
<jbernard> hallyn: very possible; the patches are in squeeze currently
<hallyn> jbernard: ok, i'll dget it.  thanks.
<hallyn> jbernard: oh, well - were you already planning to merge those into ubuntu's packages?
<hallyn> (i'd like to get the natty one in asap, obviously :)
<jbernard> i can prepare a debdiff, i just need someone to sponsor the upload
<hallyn> drat, that's not one of the ones i got access for :)
<jbernard> perhaps just a sync-request is all that's needed?
<hallyn> i think so
<ohsix> oog icons keep changing
<ohsix> so, this probably fixed 2 bugs i filed the other day https://bugs.launchpad.net/ubuntu/natty/+source/xorg-server/+bug/723905 what do i do with those bugs? close them or somehow point it to that bug?
<ubottu> Ubuntu bug 723905 in xorg-server (Ubuntu) "Semi-multitouch devices should be disabled in Natty" [High,In progress]
<hallyn> jbernard: yeah, natty is same as sid, so, cool.
<sladen> pitti: slangasek: still have a few design-team originated non-code UI Freeze changes to push (#741804, #740579, #741813/#741862), but they aren't going to get done in 10 minutes.  So I'm going to sleep on it for a bit.
<cjwatson> bryceh: is there a bug# for this fglrx black-screen-on-VT-switch bug?
<ohsix> cnd: oh, it was you i was talking too; kudos! :D
#ubuntu-devel 2011-03-25
<ohsix> thought the process still seems rather nebulous to me, i'll call that a result
<ohsix> (-t, agh)
<bryceh> cjwatson, no, since that is a private unreleased version of -fglrx the issues mostly are just email, no bug #'s unfortunately
<cjwatson> bryceh: OK - is it urgent for beta?
<cjwatson> bryceh: (I may have another upload coming anyway, and I've queued it up)
<bryceh> cjwatson, it depends on whether we get -fglrx in time for beta, which is uncertain (no eta's given)
<cjwatson> ok, well let me know as early as you can if it looks like we're going to be out of sync
<cjwatson> it's in lp:~ubuntu-core-dev/ubuntu/natty/grub2/natty
<ohsix> oh boy, my logoff dialogue and some polictkit windows earlier were showing broken font unicode boxes, i fear a reboot
<ohsix> who keeps changing the wifi icon D: the elements are almost too small to resolve now, and the bottom looks misshappen
<cnd> ohsix, which bug was it that you were hitting?
<ohsix> cnd: the 2 finger gestures on SemiMultitouch (well put) devices
<ohsix> though it appears to still be doing it
<cnd> ohsix, do you have the bug link?
<cnd> I just want to make sure everything is as expected
<ohsix> these are the bugs i posted yesterday after our discussion, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/739916 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/739922 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/739924
<ubottu> Ubuntu bug 739916 in gnome-control-center (Ubuntu) "gnome-mouse-properties doesn't offer touchpad options for 2 finger clicks" [Undecided,New]
<ubottu> Ubuntu bug 739922 in xserver-xorg-input-synaptics (Ubuntu) "touchpad disable key does not work (acts as if no key was pressed, no event in xev)" [Undecided,New]
<ubottu> Ubuntu bug 739924 in xserver-xorg-input-synaptics (Ubuntu) "device acceleration profile incorrect for synaptics touchpad in natty" [Undecided,New]
<ohsix> the one related to 2 finger clicks is the first, guess i assumed a bit that it was desired, but didn't have configuration
<cnd> oh yeah, ok
<cnd> I work on so many bugs I just forget what is what
<ohsix> alright
<cnd> ohsix, I don't really think the change should have had any effect
<cnd> so I'm not sure what to think :)
<ohsix> it didn't, i just read a little into it
<cnd> ahh
<cnd> ok
<ohsix> i thought it'd disable the 2 finger gestures when the touchpad only fakes it
<cnd> sorry...
<ohsix> not a problem
<cnd> ohsix, I don't think the scroll issue is going to be fixed for natty
<ohsix> that's fine, it can be disabeld in gnome-mouse-properties
<ohsix> the reason i filed the bug that way was to get something like that for the 2 finger right click
<ohsix> since it's probably desirable for someone, but it happens way too often with one finger for me; and i'd rather it disabled
<cnd> yeah
<cnd> that should be fixed, but probably won't be for natty either...
<ohsix> agh
<cnd> it would require too big of a change at this point
<ohsix> can you pin it disabled then, if theres no ui to do it
<cnd> well, some people may like it, and it may work well for them
<cnd> so we can't really make that kind of a change either at this point
<ohsix> it could
<cnd> because we don't really know how well it works for everyone
<ohsix> except on these touchpads where it's almost assuredly wrong, without being able to adjust the threshold for it
<cnd> we don't really know which touchpads it's definitely wrong though
<ohsix> there are 2 very clear classes of synaptics touchpads, ones that fake it and ones that don't; the ones that fake it use heuristics that aren't always correct (can change with temperature and humidity even)
<cnd> it may work fine for some people who have the "fake it" kind of touchpads
<ohsix> well, you do; i could tell you too, they have different protocols
<cnd> yeah, we can tell the two device types apart
<cnd> but perhaps it works great for some of the "fake it" kinds, and it doesn't work for some other "fake it" kinds
<ohsix> the ones with heuristics need extra input that there isn't ui for either; to make it work well
<ohsix> i get your position but i can't help but think it's arguing against changing it, it personally annoys me and does not work well; it may work well for some unknown mass of people,  but i'm at least here telling you it doesn't
<ohsix> i could enable it manually before natty as well; it did not work well then, and i had no desire to
<cnd> ohsix, I do agree with you in that it probably should be disabled by default
<cnd> and it's something we probably want to attack upstream
<cnd> in the X community
<ohsix> but now it's on by default and theres no ui for the sensitivity so it can't even be made to work sort of well
<cnd> where the driver is setting it on by default
<ohsix> probably
<cnd> ohsix, this is a change in behavior from maverick?
<ohsix> yes
<bryceh> are we in freeze for beta?  do I need to get a freeze exception for an xserver bug fix?
<cnd> (if you already said that, sorry)
<ohsix> along with the acceleration profiles being wrong (takes 4 swipes to get to the other side of a small screen with sens/accel all the way up)
<cnd> bryceh, we might want to patch out auto-enabling two finger tap for right click when only touch size is available (for ohsix's issue)
<ohsix> when mav was in alpha/beta the sensitivy stuff changed as well; but by the time it was released it was fixed
<cnd> bryceh, I don't know if you've kept up with the issue
<bryceh> cnd, I haven't, no
<cnd> bryceh, I'll try to summarize
<cnd> there's two types of synaptics trackpads that are concerned here
<cnd> multifinger trackpads and trackpads that just give you some touch area size
<cnd> in natty, the default of x synaptics is to enable right click on two finger taps
<cnd> including a heuristic to enable right click on non-multi-finger trackpads when the touch size looks like two fingers
<cnd> maverick didn't default to this
<cnd> and according to ohsix, the touch size heuristic just doesn't work well for all trackpads when set to the default thresholds
<ohsix> (and there is no ui to adjust the thresholds either)
<bryceh> ok
<cnd> so I wonder if we shouldn't leave two tap for right click disabled for the touch size type trackpads
<ohsix> since ui cant be added to enable/disable it like the 2 finger scroll, it would be best to disable it on the one type of touchpad until there is, so i can turn it off like the 2 finger scroll, and fwiw, if i could adjust the threshold that applies to both (click and scroll) i could probably use 2finger scroll as well
<cnd> ohsix, the one thing I would note is that I'm very resource stretched myself
<cnd> so although I agree with you
<bryceh> ohsix, yeah ui for configuration would be nice.  Might be hard given the various interrelating drivers though, plus some of this is a moving target.  In any case don't think we have people on hand to write gtk config stuff presently
<ohsix> right
<cnd> I may not be able to fix the bug in time for natty release
<ohsix> it all comes down to setting properties with xinput; which is what i'll have to do manually in either case
<cnd> I may not be able to fix it myself that is
<cnd> but if you or someone else has a patch, I'd be happy to review it
<ohsix> hm
<ohsix> i wouldn't know where to start
<bryceh> apt-get source xserver-xorg-input-synaptics   ;-)
<ohsix> yea i'm reading it now
<cnd> $ bzr branch lp:ubuntu/xserver-xorg-input-synaptics
<cnd> if you like bzr
<bryceh> even better
<ohsix> should i be looking through ubuntu's version of it? or is upstream enough for the likes of natty
<bryceh> cnd, I'm going to go ahead and upload the xserver package with that fix you put in from earlier.  My reading of beta devel policy is that once freeze is in effect changes are held for review, so it'll automatically fall to the release team to allow targeted fixes through
<bryceh> cnd, so it'll give them the option of including the fix in beta without forcing it
<cnd> bryceh, that's fine
<cnd> I don't think the release team likes me right now though...
<cnd> :|
<bryceh> ohsix, either one should be fine (they should be fairly close to the same code, and we can take care of porting fixes one way or the other once there is a validated/reviewed fix)
<bryceh> cnd, oops, did you break something?
<cnd> bryceh, no, I never break anything!
<cnd> though that's not the issue :)
<bryceh> hehe
<bryceh> uploaded
<ohsix> awesome, just about everything has changed since i last looked
<cnd> heh
<ohsix> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ee99d4f7bc3374e8bac083ac4ea159f5da43db06 huhu, not it, but related
<bryceh> [ubuntu/natty] xorg-server 2:1.10.0-0ubuntu2 (Accepted)
<ohsix> cnd: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ffa6dc2809734a6aaa690e9133d6761480603a68
<bryceh> interesting; perhaps beta is not quite frozen yet?
<cnd> bryceh, I blame you if xserver is broken :)
<ohsix> emulateTwoFingerMinZ defaulted to a really high value so never let Synaptics devices to emulate 2-fingers by default. Changed default to a low value (same as FingerHigh)
<ohsix> (from commit message)
<ohsix> that min z is the threshold used in the heuristic i was talking about
<bryceh> cnd, heh.  Well, I installed the debs on my desktop here and have been running it no prob, but this has a mouse not a touchpad so ymmv
<bryceh> in any case, can't be any worse than what happened this morning
<bryceh> (huge leak in water main due to tree roots breaking a pipe in my front yard)
<bryceh> ((fun))
<ohsix> cnd: i cheated and asked the guy who did it :D
<TheMuso> bryceh: Ouch that is certainly not fun.
<cnd> bryceh, oh man, not fun!
<cnd> ohsix, hmmm, we could reverse patch that
<cnd> bryceh, check out the commit ohsix pasted ^^
<bryceh> cnd, reverse patching that is certainly doable
<bryceh> will that solve it?
<cnd> ohsix, do you know how to add that as a reverse patch to a debian package?
<cnd> generate the reverse patch, stuff it into debian/patches/
<cnd> and add it to debian/patches/series
<ohsix> yea, but it probably wouldn't hurt to go over it again
<cnd> yeah, then you would build and test it :)
<cnd> and then you can post a debdiff in the bug or a merge request
<ohsix> apparently EmulateTwoFingerMinW can be changed as well, rather than reverting it
<cnd> ohsix, if you have something you want me to review, please subscribe me to the bug
<cnd> my lp id is chasedouglas
<cnd> that way I'll see it :)
<cnd> eventually..
<ohsix> what's the kung fu to generate a patch to revert automatically? i've always just edited the patches
<ohsix> (mind you, not large patches)
<ohsix> nm
<rezbit> Quick question: I am interested to know if libsdl is compiled with GCC SSP and I don't know where in the documentation to find such information. https://wiki.ubuntu.com/GccSsp lists a few specific packages with problems.
<bryceh> rezbit, I'm not familiar with libsdl, but in general you can 'apt-get source <package>' and then look in that package's debian/control to see what flags get passed to configure
<ohsix> ok remind me how to build a package, fakeroot debian/rules or something? :D
<YokoZar> hmm, why would one of the binary packages (of a multi-binary source package) not have a copyright file while the others would?
<cnd> ohsix, did you use apt-get source?
<cnd> or bzr?
<ohsix> apt-get
<RAOF> YokoZar: Because cdbs has symlinked it to one of its dependencies?
<cnd> ohsix, ok, I'd suggest using debuild
<YokoZar> RAOF: debhelper in this case
<cnd> ohsix, just running debuild should do it
<ohsix> ok
<RAOF> YokoZar: I'm not entirely sure at what level the hoovering is done; it could be further down.  When you install the package is the copyright missing?
<YokoZar> RAOF: yup, no copyright in the .deb...nor a symlink
<ohsix> does whatever that applies patches not like diff --git format patches?
<cnd> ohsix, it should work
<bryceh> I usually use diff -Nurp fwiw
<ion> Nurp derp, herp
<RAOF> YokoZar: Well, then it would appear to be not what I'm thiking of.
<YokoZar> RAOF: and thus stumps me too :(
<micahg> YokoZar: cdbs package?
<YokoZar> micahg: debhelper
<micahg> no idea then
<ohsix> maybe it would help if i checked out the right version ubuntu uses instead of using HEAD :D
<RAOF> micahg: Yeah, we've covered that :)
<cnd> ohsix, that would help :)
<cnd> ohsix, if you'd rather, the real ubuntu packaging branch is kept in git
<cnd> I forgot to mention that
<lifeless> barry: reminder: https://bugs.launchpad.net/launchpad/+bug/608173
<ubottu> Ubuntu bug 608173 in Launchpad itself "View all (or more) PPA package build statuses" [Undecided,Expired]
* slangasek 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: smoser
<ohsix> well i checked out the right version & i'm probably doing other things wrong, but it doesn't apply when i run debuild, http://paste.ubuntu.com/585153/
<cnd> ohsix, have you tried applying it manually?
<cnd> to check that it will work
<rezbit> bryceh: heh... http://svn.debian.org/wsvn/pkg-sdl/unstable/libsdl1.2/debian/patches/222_joystick_crash.diff?op=blame&rev=0&sc=0
<rezbit> This is what caused me to look around for SSP in the first place. Apparently this isn't upstream yet.
<ohsix> i cant figure this out D:
<cnd> ohsix, I can try to help you out later
<ohsix> k
<ohsix> i'm gonna check out the bzr thing and try there
<rezbit> hm... well it is in upstream SVN fwiw, but it's not in 1.2.14
<cnd> ohsix, just to be clear, my definition of later is sometime next week
<ohsix> i'll have it ready soon
<cnd> I didn't want you waiting around for me in a few hours
<cnd> :)
<cnd> cause I'll be asleep
<bryceh> rezbit, typically you can put in a bug to request the patch be backported.  If you don't get a response on it within a week (i.e. after beta is out) feel free to sub me to the bug and I'll sponsor
<ohsix> ok
<ohsix> patch applies
<cnd> cool
<ohsix> i just copied the file to a .new and edited it D:
<ohsix> http://paste.ubuntu.com/585159/ looks pretty much the same to me, brb testing it
<rezbit> bryceh: Well I don't have Ubuntu and gentoo doesn't have aptitude either. http://packages.ubuntu.com/source/maverick/libsdl1.2 is the closest I've seen to getting the source for the currently shipping libsdl1.2
<rezbit> The bug exists in upstream 1.2.13-14
<ohsix> yay, works
<cnd> great
<cnd> ohsix, do you know how to propose it using bzr and lp?
<psusi> cjwatson, oh crap, beta freeze.. does that mean my dmraid/parted fixes didn't make the cut, or can you still sneak that through?
<ohsix> cnd: nope
<cnd> ohsix, ok, push to lp:
<ohsix> with what credentials
<cnd> bzr push lp:~<your lp id>/ubuntu/natty/xserver-xorg-input-synaptics/<some branch name>
<cnd> the branch name could be lp<bug number>
<cnd> or something descriptive
<ohsix> does bzr have changesets, do i need to apply it there then push; i've never used bzr
<cnd> like "no-touch-size-emulation"
<cnd> bzr, oh, you need to commit locally
<cnd> bzr commit
<psusi> holy crap! multiarch support has arrived?  I thought that was given up on years ago!
<ohsix> psusi: you didn't notice all those FFe's for multiarch? :D
<RAOF> psusi: No; like a peat fire it merely simmered underground :)
<psusi> ohsix, feature freeze exceptions?  where would I have seen those?
<ohsix> psusi: in changelogs for package updates in natty
<psusi> ohsix, I've actually not switched to running natty yet.. still on maverick with just a few packages upgraded to natty versions
<ohsix> i see
<slangasek> given up, hah
<cnd> slangasek, is this revenge after being the release manager for previous releases?
<psusi> it didn't seem stable enough yet and then a bug cropped up in partman-auto that hangs the installer for me a few weeks ago... I guess I need to just take a dump and dist-upgrade
<psusi> slangasek, I remember being very interested in that and discussing it a good bit with some people I think are no longer around back in like, 2005
<psusi> then I wondered off and got sucked into an MMO for a few years...
<slangasek> cnd: hmm?  I hope no one finds it vengeful :)
<cnd> heh
<bryceh> ohsix, for -synaptics if you have tested the patch and verified it works, and gotten a thumb's up from cnd, I can take it the rest of the way in for you if you'd like
<bryceh> ohsix, just need the bug # and patch
<ohsix> bryceh: that would be great
<cnd> bryceh, I'd like to take one last review of that block of code
<psusi> I didn't think it was really even very desirable anymore... haven't all of the issues been worked out?  64 bit flash support and such?
<ohsix> the bug isn't exactly apropos, it was about asking for ui to change it, not disable it https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/739916
<ubottu> Ubuntu bug 739916 in gnome-control-center (Ubuntu) "gnome-mouse-properties doesn't offer touchpad options for 2 finger clicks" [Undecided,New]
<ohsix> i could add a comment about the ui not being able to be changed, and the patch to disable it if it's needed
<cnd> ohsix, I think we should open a different bug then
<slangasek> psusi: there are lots of little reasons to want multiarch, flash is just one of them
<slangasek> (and no, I wouldn't say 64-bit flash has been "worked out")
<ohsix> cnd: the reason i filed that way is i can't think of a good way to file the other bug, spurious right click events? i know too much! :D
 * psusi pours gasoline on flash and lights it on fire, then does the same for pdf
<rezbit> flash... argh
<ohsix> i'll file another
<bryceh> cnd, ok
<bryceh> ohsix, cnd, agreed that a new bug for this specific issue would be best; ohsix would you mind filing one?
<ohsix> should i put like, caused by git commit hash, or just propose the patch
<cnd> ohsix, it would be a good idea to reference the git commit
<cnd> but attaching the patch would also help
<cnd> since you've got it handy
 * lamont wonders why cups is asking for a root password when shadow has root:!:...
<ohsix> does lp detect comments made as patches as patches, or do i need to attach a file
<psusi> wait, what about the libraries needs "transitioned" to multiarch?  I thought the whole point was to take an unmodified i386 package and install it on amd64, moving things to the correct 32bit directories in the process?
<psusi> ohsix, attach file
<cnd> ohsix, when you make the new bug report, subscribe me to it
<ohsix> ok
<cnd> thanks
<cnd> and thanks for testing the change out :)
<slangasek> psusi: no, the point of multiarch is to fix the packages so that there's no "moving" things upon installation, since that breaks compile-time path references
<ohsix> all done https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/742213
<ubottu> Ubuntu bug 742213 in xserver-xorg-input-synaptics (Ubuntu) "spurious right click events" [Undecided,New]
<psusi> slangasek, what do you mean?  I thought the main problem was dynamic linking.. and the 32 bit dynamic linker looks in /lib32 instead of /lib or /lib64, and when installing an i386 package, anything that says /lib got redirected to /lib32?
<slangasek> no, the *main* problem is the many libraries that load plugins from a predetermined path
<rezbit> bryceh: I The fact that this bug is two years leads me to speculate that it's triggered by SSP and silently corrupts information otherwise. Maybe I am jumping to conclusions?
<rezbit> oops. well he's not back from the netsplit yet.
<psusi> ohh... isn't that a big no-no to begin with?  it's supposed to let ldconfig resolve paths
<slangasek> psusi: not in the least.  ldconfig is for resolving library paths, it doesn't help for plugins
<slangasek> not when you want them in per-application directories
<psusi> plugins are libraries
<slangasek> no, they aren't
<slangasek> they're dynamic shared objects
<psusi> dso = library by another name?
<slangasek> a library is a specific kind of dynamic shared object - one with an soname, that you link against
<slangasek> psusi: e.g., how would you propose libpam manage to use ld.so to look up the modules in /lib/security?
<psusi> slangasek, readdir() or a config file and then ldopen()?
<slangasek> ld.so doesn't implement either of those things for you
<slangasek> and where do you put the config file so that it's unique on a per-architecture basis?
<psusi> by the time Linux started really adopting shared libs, I had already gotten used to dlls on windows, so my understanding of shared libs quite likely makes some assumptions that things are the same as a dll when they aren't
<slangasek> you've just moved the pieces around, you haven't solved the problem of conflicting paths built into the binaries
<psusi> slangasek, I see... so the config file says load foo.so, which is assumed to be in /some/path, and so it calls ldopen() on that path, which bypasses ldconfig?  ldconfig is only used for libraries that were linked at compile time?
<slangasek> dlopen() can resolve relative paths for you by searching the system path, and the system path can vary by architecture, but almost no upstreams do it that way in practice
<psusi> slangasek, so basically, plugins need to be loaded from /lib32 or /lib64 explicitly, rather than /lib?
<psusi> though I thought dlopen() was going to be patched to automatically rewrite /lib to the appropriate one
<slangasek> er, I don't know who proposed doing /that/, but it wasn't me :)
<psusi> iirc, the idea was that since a different ld.so is run by the kernel depending on if the executable is 32bit or 64bit, it would know whether references to /lib ( or /usr/lib, etc ) should really be 32 or 64
<slangasek> I understand the idea, but that's not what's been agreed and implemented
<psusi> ohh... why is that?
<RAOF> It would seem pretty magical.
<slangasek> for one thing, having ld.so doing magic to rewrite paths out from under you is horribly ugly
<slangasek> for another, there are other kinds of architecture-dependent files besides DSOs at issue
<rezbit> bryceh: Nevermind, this is fixed in maverick release. The fact that this bug is two years with no issues on gentoo leads me to speculate that it's triggered by SSP and silently corrupts information otherwise. Thanks for your help anyway.
<rezbit> two years old*
<StevenK> RAOF: Did you end up looking at Quod Libet?
<RAOF> Oh!  *That's* why I've got the software centre open!
<RAOF> (You may take that as a ânot yetâ)
<TheMuso> heh
<ohsix> you know the quod libet guy can't ride a bike or swim
<StevenK> What does the have to do with the price of fish?
<ohsix> and started the ill fated dx11 on xp project :D
<ohsix> it's a fun anecdote :D
<ohsix> he worked for linspire & theres a video floating around of him trying to ride a bike
<RAOF> You know, mesa could probably provide dx11 on XP reasonably easily.
<ohsix> it's not just adapting the rendering api though; there are places where it leaks into windows implimentation
<RAOF> Hands up all those who can't right click on anything in the launcher without compiz crashing! o/
<ohsix> s/dx11/dx10
<ohsix> it was only a sideshow until he started charging people to get releases that didn't do anything D:
<RAOF> Well, there's a dx11 state tracker in mesa at least.
<RAOF> Heh.
<RAOF> The nux crash in GrabPointer has been fixedâ¦ and replaced by a crash in GrabKeyboard!
<ohsix> drag & drop on the panel is also broken, though how; i have no idea
<StevenK> RAOF: Does that mean it's installed now? :-)
<RAOF> StevenK: Indeed it is.
<robbiew> RAOF: apologies for have the old kernel....REALLY weird...apt-get dist-upgrade won't budge on it
<RAOF> robbiew: The other logs attached to that bug suggest that you've actually *got* the 2.6.38-7-generic kernel installed, you're just not using it.
<robbiew> yeah...but I don't
<robbiew> I checked
<RAOF> Oh.
<robbiew> system is confused
<RAOF> You've got nvidia-current built against it, though :)
<StevenK> robbiew: You have the headers, but not the kernel itself?
<robbiew> hmm...maybe
<robbiew> yep
 * StevenK wins.
<robbiew> but how the hell did I get the headers only
<ohsix> not having the virtual that pulls them all in?
<StevenK> robbiew: /var/log/dpkg.log might help tell you.
<RAOF> StevenK: Booo.  Quod Libet doesn't mpris it up.  That said, it's got a simple dbus interface, so it'd be the work of Â½ an hour to whip a plugin up.
<StevenK> RAOF: I can't see a mpris plugin for Quod, either.
<StevenK> RAOF: Pity I don't know C# :-)
<RAOF> You could try an IronPython plugin :)
<RAOF> Or IronRuby.  How about F#? :)
 * StevenK books a flight so he can stand over RAOF until he writes it. :-P
<StevenK> RAOF: http://code.google.com/p/quodlibet/source/browse/plugins/events/mpris.py?spec=svn06b6519551f11dc084e7465cde47b8e520837c74&r=06b6519551f11dc084e7465cde47b8e520837c74
<RAOF> StevenK: Ah, sweet.  I'll just go and write an mpris-control plugin then.
<StevenK> RAOF: Is that even easier?
<RAOF> No, but it'll work for more players.
<RAOF> It's almost exactly as easy, but more general.
<NCommander> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<NCommander> @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: NCommander, smoser
<NCommander> evening all
<phsi> hmm, newest pulse in natty has pulseaudio-module-raop as hard dependency
<phsi> which in turn depends on zeroconf
<phsi> and this then brings in all the avahi shit
<phsi> is this getting fixed?
<RAOF> Is there a bug filed?  I'm not sure if there's some reason why -raop can't be Recommended rather than Depended on.   Also:
<RAOF> !ohmy > phsi
<ubottu> phsi, please see my private message
<pitti> Good morning
<nigelb> Guten Morgen pitti :)
<bryceh> heh
<bryceh> !ohmy > bryceh
<ubottu> bryceh, please see my private message
<bryceh> kewl
<micahg> !msgthebot > bryceh
<micahg> :)
<bryceh> micahg, what you don't like me playing with my bots in public?  ;-)
<cdbs> micahg: It creates unnecessary backlog
<cdbs> oops
<cdbs> bryceh: ^
<micahg> as does this whole conversation ;)
<cdbs> bryceh: When you can !msgthebot its better, and cleaner
<dholbach> good morning
<didrocks> good morning
<mvo> kklimonda: hi, I just looked at your pangomm (and friends) branches, thanks for them! it appears Murray has a new tarball without the need for mm-common
<kklimonda> mvo: does it really matter? mm-common already got a MIR, so I've assumed it's only a matter of uploading packages that depend on it to pull it to main? I've not yet read email, so I may be missing something :)
<mvo> kklimonda: it does not much matter, no :)
<pitti> tseliot: oh, so can we remove displaydepth for 96 and 173 as well? that would indeed make xorg.conf a lot simpler
<tseliot> pitti: I'm not sure as to whether that option is automatically applied if a xorg.conf exists. Sarvatt should know more about this
<pitti> tseliot: ok, thanks; it at least was confirmed that it works for -current
<NCommander> @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: smoser
<soren> How is component-mismatches generated?
<soren> I'm trying to generate a list of packages that would need an MIR if a particular package were to be seeded. I'm not sure if the tool that generates component-mismatches might be of use.
<soren> So far I'm using germinate, but by default it only looks at main, and just refuses to add packages that have dependencies in universe, so there must be something else that can help me out.
<soren> Hmm... Or perhaps it's refusing to add the package because it itself is in universe, but it seems to me the result is the same.
<soren> cjwatson: Perhaps I could borrow your brain for a couple of minutes? Pretty please? :)
<cjwatson> soren: you can tell germinate which components to look at - it's a command-line option
<cjwatson> so you run germinate against all components, and then compare against what's currently in main
<cjwatson> the rest is basically bookkeeping
<soren> cjwatson: Indeed.
<soren> cjwatson: How does component-mismatches do it?
<soren> surely not like this?
<cjwatson> why not?
<soren> Does it?
<cjwatson> (actually, Launchpad has already run germinate for it; it just uses the output.)
<soren> But for germinate to consider stuff in universe at all.. Err..
<cjwatson> it's perfectly reasonable if you're asking conditional questions
<soren> Does Launchpad run germinage with universe "enabled"?
<cjwatson> yep
<soren> Oh.
<soren> Oh, ok.
<soren> ..and then component-mismatches compares with Packages (and Sources, I suppose)?
<cjwatson> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/cronscripts/publishing/cron.germinate <- how LP runs germinate
<cjwatson> I'll mail you the dire hacky scripts that do c-m
<cjwatson> I doubt they'll be runnable directly out of context
<soren> cjwatson: Thanks very much.
<StevenK> When I do MIR work to see what needs to be promoted, I do it all by hand. :-/
<soren> cjwatson: I tried to find that cron thing, but I don't have an lp checkout handy and I'm working out of a coffee shop today.. Checking out lp would take days :)
<soren> StevenK: That's very useful info. Thanks.
<cjwatson> it's not in LP
<cjwatson> well, cron.germinate is, the other bits aren't
<soren> ~launchpad-pqm/launchpad/devel looks very..
<soren> Ah, right.
<StevenK> And yes, that's LP main trunk.
<soren> Exactly, hence my confusion about "it's not in LP" :)
<mdeslaur> @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: mdeslaur, smoser
 * dholbach hugs mdeslaur
<dholbach> smoser, you might want to unpilot yourself :)
<MadRobot> Hi all.
<MadRobot> May make a small suggestion?
 * mdeslaur hugs dholbach 
<MadRobot> Why don't you replace the default media player "Mplayer" with another one such as VLC?
<directhex> mplayer isn't the default media player.
<MadRobot> directhex, what is?
<Pici> Totem.
<directhex> totem
<MadRobot> I see.
<MadRobot> lol, I thought they were the same thing. :P
<directhex> vlc plays more or less anything. which is good. but there are two downsides.
<directhex> first, it's not possible to split vlc's codec support up. totem uses the gstreamer framework to install codecs on demand. this is important from a legal standpoint, since the mp3 patent holders demand a license fee for preinstalled mp3 players - and other codecs may suffer similar issues. codecs are a patent minefield, and gstreamer makes it easier to ship only a subset by default
<directhex> secondly, it's a usability disaster. although i wish totem were more configurable, vlc goes waaaaaay too far
<MadRobot> directhex, I see.
<directhex> MadRobot, i don't think anyone's opposed to a better media file player if one comes along, but i don't think vlc is a possible move
<MadRobot> Anyways, I guess you're right. Totem can stick around, and if I'm not  comfortable with it, I can simply use something else. :)
<MadRobot> directhex, I agree.
<MadRobot> Or, there's another option, that Totem receives some more polishing and improvements.
<directhex> yes, that's a good option
<MadRobot> The fellows at the Totem project need to put some more effort at making Totem a little less buggy, imho. -_-
<directhex> MadRobot, if you have specific issues, you should file bugs about them
<MadRobot> directhex, yeah, but the problem is that I'm not sure how to write and document these bugs.
<MadRobot> They have to do with it
<MadRobot> streaming .avi videos.
<MadRobot> It some times slows down, or even crashes.
<mdeslaur> pitti: what's your opinion on the patch in #711549?
<pitti> mdeslaur: ah, I think I saw these fly by
<pitti> mdeslaur: back then I thought kay wanted to use the in-kernel polling (which is really the right way to fix this)
<mdeslaur> pitti: yes, but meanwhile it's a big user-visible bug
<mdeslaur> pitti: (and one of my personal pet-peeves for the past couple of releases...)
<pitti> mdeslaur: yeah, I guess we need to revisit applying it until the in-kernel stuff gets used
<mdeslaur> pitti: should I ask for a freeze exception and push it to natty?
<pitti> mdeslaur: I don't think it's urgent enough to squeeze into beta-1
<pitti> mdeslaur: I'd really like to avoid distro-patching; I'd prefer pushing it upstream and then applying in Debian and syncing
<pitti> we've been through this in hal
<mdeslaur> pitti: ok, I'll leave it be. thanks
<pitti> mdeslaur: so feel free to discuss with kay or davidz in #udev, otherwise I'll add it to my queue
<ari-tczew> wgrant: are you going to upload a fix for loggerhead for natty?
<pitti> mdeslaur: the spirit of the patch seems fine, but the implementation should be improved IMHO
<pitti> mdeslaur: e. g. udisks already knows whether a device is mounted, no need to parse /proc/mounts etc.
<mdeslaur> pitti: ah, ok....I'll let you handle the bug then since you're familiar with udisks
<pitti> mdeslaur: I'll keep the tab open; doing HR stuff and release meeting today, but something nice to hack on next week
<mdeslaur> pitti: cool, thanks
<hallyn> jbernard: so, to do a libcgroup sync request we first need the fix in debian unstable, right?
<mdeslaur> patch piloting during freeze isn't very productive :)
<pitti> mdeslaur: yeah :(
<wgrant> ari-tczew: We'll sync it from Debian in a day or two.
<pitti> mdeslaur: well, universe isn't frozen
<ari-tczew> pitti: but new features needs FFe right?
<ari-tczew> wgrant: so can I unsubscribe sponsors from bug?
<wgrant> ari-tczew: Indeed.
<hallyn> is there a workaround for using apport-collect to an existing bug from a console (which fails due ot no launchpad login)?
<hallyn> or, if it failed at that stage, is the data cached somewhere so the user can later log in and manually post the files collected by apport?
<pitti> ari-tczew: right
<jdstrand> didrocks: hey, would you mind milestoning bug #741942 (the one I reported yesterday)?
<ubottu> Launchpad bug 741942 in nux (Ubuntu) "compiz crashed with SIGABRT in raise()" [High,Triaged] https://launchpad.net/bugs/741942
<didrocks> jdstrand: hum, seems launchpad timeouted, I milestoned it already as well send it in the priority list for dx
<didrocks> jdstrand: done :)
<jdstrand> didrocks: thanks! :)
<didrocks> jdstrand: you can thank me and dx once it's fixed ;-)
<jdstrand> didrocks: you can bet I will. I miss my unity :)
<didrocks> heh ;)
<didrocks> jdstrand: if we get some fixes that can't go into beta, I'll maybe setup a backported version in a ppa so that you can test it
<jdstrand> didrocks: I'd be happy to
<mterry> Heyo, general announcement: I'm considering applying for core-dev and would appreciate comments/endorsements if anybody has any https://wiki.ubuntu.com/mterry/CoreDev
<smoser> @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: mdeslaur
<cjwatson> jibel: can you confirm whether the Asus U3SG system you had where Plymouth failed to cope with the framebuffer switch (https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard) is now working more smoothly?  I believe that it should, now that we don't do the vesafb->KMS dance any longer
<jibel> cjwatson, I haven't rebooted it for quite some time. I'm trying that right now, brb
<jibel_> cjwatson, not back as fast as I expected, but well I'm here.
<jibel_> cjwatson, first there is something strange, the grub background is a debian background
<jibel_> cjwatson, then the screen becomes black for 4s, then ubuntu log + dots, then quick flicker and the logo is back but the dots are not blinking anymore and finally it switch to X
<cjwatson> jibel_: you probably have desktop-base installed
<cjwatson> jibel_: the rest of it sounds largely as expected for the moment - thanks!
<jibel_> cjwatson, okay, desktop-base is installed because of the dependencies: gnome-accessibility -> gnome-core -> desktop-base
<kirkland> does anyone here have a thinkpad x201 working with a docking station and external video in Natty?
<kirkland> bryceh: ^
<cjwatson> jibel_: that issue is on https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard though
<cjwatson> it's the last one that has known specifics
<ari-tczew> vish, cdbs: I'm looking on amule package and it seems to be fine for me for sync. However, there is your delta to fix description in d/control. Debian didn't accept it. What's next?
<ari-tczew> mvo: what do you think, should do we keep delta in Ubuntu for improve description? bug 602717
<ubottu> Launchpad bug 602717 in amule (Ubuntu) "Description: aMule" [Low,Fix released] https://launchpad.net/bugs/602717
<jbernard> hallyn: yep, im working on a new upstream release now
<hallyn> jbernard: awesome, thx
<jbernard> hallyn: i should have some time this weekend to finish it up
<cdbs> ari-tczew: Merge then
<ari-tczew> cdbs: my question is whether it's really necessary to store in ubuntu
<zul> pitti: i just uploaded landscape-client for maverick-proposed can you reject it please?
<mvo> ari-tczew: ideally we would have a overwrite mechanism via LP, but that is not done yet
<pitti> zul: not in the queue yet
<zul> pitti: ok nm then
<zul> pitti: just a preemptive strike but its not needed
<pitti> zul: how so?
<zul> pitti: it got rejected before it hit the queue thanks anyways
<cdbs> ari-tczew: It very much is
<pitti> zul: ah, heh :)
<cdbs> ari-tczew: We have sometimes diverged from Debian just for that
<cdbs> ari-tczew: Its an Ubuntu effort. If debian rejects, we keep the delta
<ari-tczew> mvo: ok but what's your decision - keep it and merge or drop it and sync?
<pitti> jdstrand, kees: releasing the missing linux-restricted-modules-2.6.15 for dapper; not sure whether that needs an USN?
<ScottK> cdbs: Not always.  You have to ask if it's worth the effort of merging all the time to keep the benefit of the change.
<ScottK> For small edits in the package description my answer is usually no.
<ari-tczew> +1 ^^
<vish> ScottK: then what is the use of actually fixing issues, if we are going to revert them later?
<cdbs> ScottK: Well, I heard jcastro did ask the DDs about it, who had a mixed opinion on the description changes. So we decided to keep it when we can
<mvo> ari-tczew: I look after the call
<vish> we could just as well say we dont want to fix such bugs in Ubuntu
<cdbs> +1 ^
<cdbs> ari-tczew, ScottK: We are building up a system aimed at newcomers, not geeks
<cdbs> ari-tczew, ScottK: Let me give you an example:
<jdstrand> pitti: ack. I'll review it, thanks
<cjwatson> we also have finite resources which should be spent carefully
<cjwatson> (not that I feel strongly one way or the other in this case, but it's not true that one consideration uniformly outweighs the other)
<cdbs> Package frozen-bubble had a description containing information about some rumour which blamed the package frozen-bubble responsible for the delay of Debian Woody release
<cdbs> ari-tczew, ScottK: Such a description won't be relevant for display in something like software center
 * ari-tczew is off for lunch. afk.
<ScottK> I'm not saying there aren't cases where maintaining such a diff is inappropriate, I'm just saying usually not.
<pitti> ScottK +1
<vish> cjwatson: ACK, but we need to be clear with what we want to do. We are requesting people to file bugs, then we have people reviewing those bugs and later we have people actually writing a new description for those packages and finally someone fixes it â¦ why all this work when we are going to revert later?
<pitti> and less so for a rather harmless joke like in f-b IMHO
<pitti> vish: IMHO the correct course of action for this is to forward the patches to the Debian BTS, and declare it done on our end
<cjwatson> vish: this just means that it's also worth spending effort in persuading people upstream of us to accept the change
<pitti> (if that would be the only delta we have)
<cjwatson> rather than considering the job done when it's in Ubuntu
<vish> pitti: we do forward,, but debian rejected.. saying it is not an issue
<vish> for them*
<cjwatson> and that will happen occasionally, but it doesn't mean it isn't worth trying to minimise our delta in general
<cdbs> Because Debian has its own guiding principles which clash with ours at times
<cjwatson> it's just the same for code changes - occasionally we have to decide whether keeping a delta is worth it, and sometimes the answer is yes and sometimes no
<cdbs> Well, I fixed the bug. At a time when I wasn't MOTU. At that time even a small upload in my name made a huge difference.
<Sarvatt> hello libx11 klingon.. :P
<pitti> Sarvatt: nuQneH?
 * cdbs g2g
<Sarvatt> that's one delta we'll carry forever because noone wants it :)
 * vish just a middleman stuck between the design team and MOTU :D
<cjwatson> mvo: are you ready to upload that sudo change?
<cjwatson> mvo: oh, never mind, I see it in the queue
<mvo> cjwatson: its uploaded, waiting for review
 * cjwatson reviews and accepts
<cjwatson> mterry,TheMuso: any further progress on deciding on bug 730759?
<ubottu> Launchpad bug 730759 in dbus-c++ (Ubuntu Natty) "[MIR] b-d for libffado" [High,New] https://launchpad.net/bugs/730759
<mterry> TheMuso, cjwatson: putting dbus-c++ back in libffado is sort of sleight of hand.  It's still arguably unmaintained code.  But it does highlight the fact that we've had this chunk of unmaintained code already in main...  I remember that the Debian folks wanted it to remain a separate lib
<cjwatson> yeah, I don't see shoving it back into libffado as being a particular improvement
<mterry> TheMuso, so I'm not clear on the end result of the offer to co-maintain it?
<cjwatson> I don't know much about it, I'm just conscious of its continued presence on c-m
<superm1> mtaylor, it's a bit unclear to me why this MIR needs to happen though; ubuntu studio can build from universe, no?
<mterry> superm1, was that to me?
<superm1> you were the one approving the MIR on libffado right?
<mterry> superm1, sure, you just asked mtaylor is all
<superm1> oh yeah, oops, tab completion :)
<mterry> superm1, I don't know about studio building from universe.  I thought it didn't.  I guess the question is who rdepends on libffado
<superm1> well originally it was a set of packages common to ubuntu studio and mythbuntu; jack
<superm1> mythbuntu dropped all the jack depends to get out of this mess
<superm1> clearly mythbuntu can build from universe/multiverse, so i had *thought* ubuntu studio could too
<holstein> hello
<holstein> im noticing some ubuntustudio talk
 * holstein reading scrollback
<mterry> superm1, what's the rule for that?  I assume officially supported flavors must build from main only, others whatever?
<cjwatson> superm1: libffado is in main because jack uses it
<mterry> cjwatson, sure, but question was then why is jack in main?
<cjwatson> its (build-)dependencies need to be in main, regardless of what mythbuntu/studio use
<holstein> and having it in main means as an end user, we can have JACK support out of the box
<cjwatson> pulseaudio and a bunch of other things build-dep on jack
<holstein> in most aps
<cjwatson> alsa-plugins, gst-plugins-good0.10, portaudio19, xine-lib
<cjwatson> so it has to be in main for those
<mterry> k
<superm1> ok that's clearer to me
<cjwatson> barry: are the recent comments on bug 711225 enlightening?  Martin seems to need interpreter help at this point
<ubottu> Launchpad bug 711225 in python2.7 (Ubuntu Natty) "subprocess.Popen() crashed with TypeError in _cleanup(): an integer is required" [Medium,Confirmed] https://launchpad.net/bugs/711225
<cjwatson> barry: also, can you update me briefly on the state of bug 724327?
<ubottu> Launchpad bug 724327 in python-launchpadlib (Ubuntu) "lp-shell crashed with ImportError in _ensure_keyring_imported(): No module named keyring" [High,In progress] https://launchpad.net/bugs/724327
<cjwatson> ISTR some MIR activity there ...
<barry> cjwatson: looking...
<cjwatson> hmm, python-launchpadlib seems to depend on python-keyring now
<ari-tczew> pitti, cjwatson: so do you confirm that we can drop this one change in description?
<barry> cjwatson: yes, i think that's been so for several weeks now
<cjwatson> ah, dup bug - I'll close that
<pitti> ari-tczew: for frozen-bubble? sure
<ari-tczew> pitti: no, for amule - discussion with vish and cdbs
<ari-tczew> from other hand they see a problem in workflow in Ubuntu - community give patches which will be dropped in future
<ari-tczew> but that's the system - if Debian rejects patch, we're dropping it
<barry> cjwatson: re: bug 711225.  no, the comments just add to the confusion. ;)  but pitti provided a way to reproduce it so i'll investigate that today.
<ubottu> Launchpad bug 711225 in python2.7 (Ubuntu Natty) "subprocess.Popen() crashed with TypeError in _cleanup(): an integer is required" [Medium,Confirmed] https://launchpad.net/bugs/711225
<vish> ari-tczew:  then why even have a system that supports uploading a patch in Launchpad :)
<ari-tczew> vish: uploading? do you mean attaching to bug?
<vish> i like Kubuntu workflow, they are clear where the bug and issues need to be fixed
<vish> this is like flip-flopping, if some MOTU later doesnt have time to merge, we will drop your earlier effort
<vish> ari-tczew: yea, i meant attaching â¦
<pitti> barry: I really can't make head and tail of that one :/ I started at the python code for quite some time, but I don't see anything wrong with it
<ari-tczew> vish: I think the best way to resolve this issue (in general, not in this case) is send an e-mail to TB.
<vish> probably.. but I'm not sure this is such a huge issue to poke TB
<barry> pitti: indeed, the description is pretty confusing!  i'll probably need to gdb the python process to dig deeper.  sounds like a fun one for a friday :)
<vish> ari-tczew: what happens if we dont sync/merge?
<cjwatson> barry: thanks
<barry> cjwatson: should i assign it to myself?
<cjwatson> barry: if you could, please
<ari-tczew> vish: then we won't get news in amule in Debian
<cjwatson> vish: as I say, this underlines that the job is not done when the patch is in Ubuntu - there is still care and feeding involved as long as there's a delta, and I think some of that should be on the shoulders of the people who incorporated the patch into Ubuntu
<vish> right, then we could wait for cdbs to do a merge
<tumbleweed> vish: (sorry haven't been following this from the start, but here goes) why not push these to Debian as soon as possible? I don't want to create a delta in ubuntu for just a description change, I'd rather push it to Debian first
<ari-tczew> tumbleweed: Debian has rejected patch
<vish> tumbleweed: Debian rejected the patch
<tumbleweed> ari-tczew: aah
<vish> yea
<pitti> barry: may the source be with you! yes, it looks like a "fun" one..
<tumbleweed> I guess if we really want it we have to do the work then
<barry> pitti: hopefully it will result in a blog post a little less fascinating and frightening as cjwatson's on the wubi bug :)
<vish> IMO, if no one has the time to merge, let's just not have the new package, if someone feels strongly about having the new package, they could do the merge
<tumbleweed> generally we try to encourage the person who made the change to do future merging
<vish> yea, thats why i mentioned, we could just wait for cdbs to get to a merge
<ari-tczew> vish: look, when you want to keep this small change you have to spend a time on merging package every time when Debian has released new reiviosn
<ari-tczew> revision
<ari-tczew> there is a question whether the time which has spent on merging is worth?
<ari-tczew> because it won't be one time on merging
<ari-tczew> every time
<cjwatson> vish: Ubuntu policy is to merge globally; while there are exceptions where it's hard, any case where we aren't keeping up to date is a problem
<vish> ari-tczew: why not wait for cdbs ? has cdbs refused to merge? he is a MOTU too
<Riddell> jdstrand: I think it's your archive admin day, bug 742377 has an upload in hardy-backports -Q unapproved
<ubottu> Launchpad bug 742377 in qt4-x11 (Ubuntu Karmic) "blacklist fake Comodo SSL certificates" [Undecided,New] https://launchpad.net/bugs/742377
<cjwatson> (that said, we are in feature freeze.  there should be no reason to worry about merging now - the merge push is in the first part of the release cycle)
<vish> if the previous uploader doesnt care about his effort, then dropping seems reasonable. but why just not let the MOTU do his work
<tumbleweed> vish: I think this is being morphed into a more general question: is keeping a patch like that worth the effort for the MOTUs in general
<vish> tumbleweed: yup. :)
<jdstrand> Riddell: ok, thanks
<ari-tczew> for me it's not worth
<ari-tczew> and cjwatson has got a good point, ATM merge is not really needed
<ari-tczew> however, they added some small fixes
<ari-tczew> vish: feel free to merge it, this is your time
<ari-tczew> personally I wouldn't spend time on that small change
<vish> ari-tczew: previous uploader is cdbs :) , I'm not MOTU, lets just wait for him
<ari-tczew> vish: no, it's not cdbs
<ari-tczew> it's shankhao and tumbleweed has sponsored this one
<vish> hmm..
<vish> oh well, this is my opinion:  "<vish> IMO, if no one has the time to merge, let's just not have the new package, if someone feels strongly about having the new package, they could do the merge."  I'm not a MOTU, so i dont really have much say in this do I? ;p
<cjwatson> I'm afraid standing policy is otherwise
<cjwatson> I mean, obviously it's reality that somebody has to have the time to deal with it, but the policy of the development community as a whole is that somebody should make time. :-)
<vish> :-)
<cjwatson> (either for a merge or a sync, one way or the other)
<tumbleweed> vish: you do. All that's needed here is a sponsor. You can request a sync or a merge and if the sponsor agrees that it looks like a good idea, it'll happen
<vish> tumbleweed: it would be like me chasing my tail, next cycle again this same question will arise..
<vish> however, I'm all for cloning mvo , if we have more of him we might have less of this problem ;)
<tumbleweed> hah. indeed, which is why syncing might not be a bad idea (I don't know what package this is, so I haven't looked at the change)
<ari-tczew> right, we still don't have mvo's feedbach. the change is related to be useful for software center.
<ari-tczew> tumbleweed: amule
<vish> ari-tczew: there is a roadmap to allow user-generated descriptions, but mvo is stretched too thin :)
<vish> *LP roadmap
<tumbleweed> aah. It doesn't look like a particularly important description change, I'd have no objection to reverting it. Not all patches are accepted upstream, sometimes we need to throw away work
<mvo> ari-tczew, vish, tumbleweed: sorry, was distracted. I think ideally we add a additional layer so that we can have chnages to the presentation (desktop file or even package description) without the need to touch the package itself. but we are not there yet. in the meantime I think we need to decide case-by-case
<mvo> if its not a terrible important changes, we can throw it away, but it slightly worries me that a simple merge like this is difficult to find people for :/
<ari-tczew> mvo: probably vish and cdbs love to merge it
<mvo> I'm happy to sponsor a merge (if that helps)
<ari-tczew> vish: btw. I don't agree with you that this case is too small to be discussed by TB. I was a witness in case when one small patch was discussed by TB. (w3m or something IIRC)
<vish> yea, maybe, I think I was just being frightened of "talking to the TB" .. :)
<cjwatson> I don't think any of this should involve talking to the TB
<vish> i still believe, that if someone feels they definitely want to get the new version into Ubuntu, they could try to make some extra effort and do the merge. right now this discussion seems more like my time is more precious than the previous person's,  so I'm just going to drop it.
<vish> (this is cause an upload that has already been done)
<vish> s/that//
<vish> if we dont want to have such changes, we should not even upload such patches
<seb128> the issue is that having to merge a package rather than to sync means extra efforts are required and that the package tends to stay behind in versions and bug fixes because often there is no enough manpower to keep up with debian updates
<seb128> where sync are just flowing in
<seb128> well at least during the first part of the cycle
<seb128> it's ok for one source
<seb128> but if you start updating random source for description update that will be an issue
<vish> seb128: ACK, then we should just not allow any such patches in Ubuntu
<vish> we should be like Kubuntu
<vish> they are very clear, they just close the bugs in LP if it is not their issue
<seb128> we had this discussion before but you and design said we should take it at least for some popular packages
<vish> :-)
<seb128> which seems a fine tradeoff for a few source
<Laney> didn't we agree to try to start (revive? was there one before?) a Debian initiative for descriptions?
<vish>  i think we might have only a handful 10-20 max packages with such description changes.. which does not seem to huge
<vish> Laney: we did, and the person incharge of starting the discussion retired from Ubuntu, :(
<Laney> Someone else who cares about the project could do it instead. :-)
<vish> yea, i know! ;p
<Laney> btw, I imagine it would carry more weight were Debian to have the software centre too (so maintainers can see their descriptions being presented up front)
<seb128> the descriptions are also in update-manager etc
<seb128> not discussing having it in debian but fixing description is not only useful for it
<Laney> I just mean that they aren't so prominent in Debian so it could be hard to convince maintainers of the need for a campaign
<mdeslaur> @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:
<cjwatson> doko_,ScottK: http://qa.ubuntuwire.com/ftbfs/ certainly shows several not-current failures
<cjwatson> e.g. randomly https://launchpad.net/ubuntu/+source/collectd/4.10.1-2.1/+buildjob/2101837
<ubottu> Ubuntu bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released]
<ScottK> Agreed.
<ScottK> I found some that failed on 3/8.
<ScottK> Certainly not "this week".
<doko_> hmm, lamont ^^^
<cjwatson> I was going to craft an LP-API-based mass-give-back script if lamont didn't already have one ...
<cjwatson> it's irritatingly not quite as easy as it ought to be
<ScottK> "Ask lamont to do it" is hard?
<ScottK> ;-)
<cjwatson> lamont is great, but I'd like us to be able to do it independently
<ScottK> I told lamont recently his mantra ought to be "lamont doesn't scale".
<lamont> ScottK: I totally do not scale
<lamont> <lamont> cjwatson: the buildds get disabled because the packages they're being asked to build so massively overtax the buildd that either (1) it falls over dead, or (2) launchpad decides it has, even though it hasn't.  in either case, launchpad then moves the build onto the next buildd and we knock that one over in turn
<lamont> <lamont> and since gcc, gcj, openjdk, and such are (1) examples, (2) needs-build/building, and(3) in main, it really really sucks to be a universe package
<lamont> bah.  just to make sure it's in an actually-relevant channel
<cjwatson> http://paste.ubuntu.com/585462/ is (a) horrible (b) wrong and (c) running
<cjwatson> (and I'll be unimpressed if people run that casually without agreement and DoS the builders ...)
<pitti> cjwatson: OOI, what's wrong about it?
<pitti> (aside from the DoSing part)
<cjwatson> it has to iterate over lots of old builds because I couldn't see an interface which returns only the current ones
<cjwatson> so it's harder on LP than it ought to be
<pitti> I though that was the (a) horrible part
<cjwatson> (d) hyperbole
<nigelb> kirkland: ping
<kirkland> nigelb: on the phone for the next 35 minutes
<kirkland> nigelb: ping me after that
<nigelb> kirkland: sure, thanks :)
<cjwatson> OK.  Mass give-back done.
<cjwatson> 78 packages retried
<cjwatson> s/packages/builds/
<cjwatson> (fewer than I expected, but looks right-ish from http://qa.ubuntuwire.com/ftbfs/)
<cjwatson> builders say the queue time is 23m (amd64), 10h (armel), 2h20m (i386), 14h (powerpc), which looks pretty tolerable
<jcastro> mvo: would you recommend people using the deb mirror line in sources.list if behind a squid-deb-proxy? I imagine the download URL changing each time wouldn't cache?
<tgardner> slangasek, how does one deal with conf files when upgrading to the next release if the options in the conf file are no longer correct (or just plain wrong). For example, module-init-tools-3.12/debian/modprobe.d/intel-5300-iwlagn-disable11n.conf
<tgardner> just release note it?
<mvo> jcastro: yeah, its not necessarly a good idea behind squid-deb-proxy, I will investigate if there can be done anything to teach squid that certain curls are mirrors and actually the same resource
<mvo> jcastro: but I have n oclue if that is possible or not
<bdrung> doko_: i fixed lintian \o/
<pitti> cjwatson: nice, the rebuilds are already by and large done
<psusi> cjwatson: since beta freeze went into affect, does that mean my dmraid/parted fixes missed the window, or do you think you can still merge them?
<slangasek> tgardner: there's 'dpkg-maintscript-helper', a tool that you can use in the next version of the package to cleanly handle removal of the conffile on upgrade
<slangasek> tgardner: dpkg-maintscript-helper rm_conffile /etc/modprobe.d/intel-5300-iwlagn-disable11n.conf module-init-tools 3.12-1ubuntu4 <-- called from the maintainer script; the manpage has more details
<slangasek> sorry, reverse those last two options
<cjwatson> psusi: I'll have a look at them
<ricotz> cyphermox_, hello :), if it is possible it would be great if you could look into syncing wpasupplicant from debian/experimental 0.7.3-1 was finally release there
<cyphermox_> ricotz, I opened a bug about it, hold on
<cyphermox_> ricotz, bug 740164  -- if someone could ack/ process it it would be cool ;)
<ubottu> Launchpad bug 740164 in wpasupplicant (Ubuntu) "FFe: Sync wpasupplicant 0.7.3-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/740164
<ricotz> cyphermox_, great
<cjwatson> psusi: uploaded, though it will need somebody else to approve it from the queue; sorry for the delay
<tgardner> slangasek, cool. thanks for the advice.
<slangasek> tgardner: no problem - I'm also happy to review once you have a prelim package fix
<tgardner> slangasek, k, gimme a bit.
<doko_> bdrung: thanks!
<pitti> bdmurray: hm, is the truncation on http://reports.qa.ubuntu.com/reports/bug-fixing/natty-fixes-report.html (and also per-team pages) known?
<bdmurray> pitti: it is now, thanks
<pitti> bdmurray: ah, thanks
<pitti> bdmurray: want a bug report somewhere?
<bdmurray> pitti: the ubuntu-qa-tools project would be great
<pitti> bdmurray: done (bug 742675(
<ubottu> Launchpad bug 742675 in Tools used by the Ubuntu QA Team "natty fixed bugs reports are truncated" [Undecided,New] https://launchpad.net/bugs/742675
 * pitti appends )) to bring the universe's parentheses parser back into balance
<tgardner> slangasek, chinstrap.canonical.com:~rtg/module-init-tools
<seb128> slangasek, hey
<slangasek> seb128: hey there
<seb128> slangasek, I think you didn't notice, but http://launchpadlibrarian.net/67265214/pango1.0_1.28.3-4ubuntu2_1.28.3-4ubuntu3.diff.gz
<seb128> slangasek, your commit in the autoimport vcs conflicts with the upload mvo did today which is waiting in the queue
<slangasek> seb128: this is why everyone should use the bzr branches! ;)
<slangasek> seb128: ok, will have a look at his upload and readjust, thanks
<seb128> slangasek, yw
<seb128> slangasek, well to be fair the vcs is lp:~ubuntu-desktop/pango/ubuntu
<seb128> but we got in sync so the info got dropped from the control ;-)
<slangasek> seb128: heh
<seb128> don't bother about the vcs
<slangasek> yes, those are not the bzr branches I meant ;)
<seb128> we should get back in sync next cycle
<mvo> slangasek: I used the bzr branch first (the debcheckout one) but it was out of date and I dod not sync it up, my mistake
<slangasek> mvo: debcheckout wouldn't have pointed to a bzr branch, afaics
<slangasek> anyway, don't worry about it
<slangasek> it all just means you get me to process the queue for you :)
<mvo> slangasek: indeed, its not recorded in the src record, I probably had a local checkout or something. but yeah, the current situation is a bit of mess, ++ for unification
<slangasek> unification doesn't solve the problem of where to commit when we /do/ need to upload to Ubuntu
<bdrung> doko_: strange. it fails again: http://launchpadlibrarian.net/67283011/buildlog_ubuntu-natty-i386.lintian_2.5.0~rc1ubuntu3_FAILEDTOBUILD.txt.gz and i have no clue why.
<hallyn> zul: hey, so if I did 'debcommit -r -R'; 'bzr push';  'bzr uncommit'; (make a change);  'debcommit -r -R';  'bzr push'
<hallyn> zul: will the tag in the end be ok?  :)
<cjwatson> no, you'll get an error from debcommit because the tag already exists
<cjwatson> however you can manually do 'bzr tag -f' and that should work
<cjwatson> sorry, --force not -f
<cjwatson> and you would need bzr push --overwrite
<hallyn> cjwatson: i went ahead and re-uncommited and did 'bzr tag --delete' then redid the debcommit,
<hallyn> which seems to be working so far
<hallyn> ah, there's the error you predicted pushing :)
<hallyn> cjwatson: thanks, --overwrite did the trick for that
<hallyn> cjwatson: oh, hey, zul mentioned on ubuntu-cloud you'd fixed some bug with the amd64 cd image perhaps relating to kim0 finding that 'debootstrap' is not installing netbase when it is on 'Depends:' for one of the packages he'as asking for with --include?
<james_w> https://bugs.launchpad.net/ubuntu/+source/davfs2/+bug/459998
<ubottu> Ubuntu bug 459998 in davfs2 (Ubuntu) "davfs kernoops can't mount partition as user" [Undecided,In progress]
<james_w> the kerneloops user has a silly homedir of /
<james_w> changing the postinst will fix it for new users, but what should be done for existing users
<james_w> is it ok to delete and then re-add the user?
<ScottK> I don't think there's a guarantee it will get the same UID.
<ScottK> If it owns any files on disk, that would be problematic.
<james_w> hmm, yeah
<james_w> I don't think it should in this case, but I'm not 100% sure
<james_w> is there a command to alter a homedir after the user is created?
<james_w> usermod -d looks likely
<james_w> definitely without the -m option in this case :-)
<bdrung> doko_: fyi bug #742832
<ubottu> Launchpad bug 742832 in dpkg (Ubuntu) "lintian FTBFS" [Undecided,New] https://launchpad.net/bugs/742832
#ubuntu-devel 2011-03-26
<psusi> cjwatson, oh man.. I don't know how the hell that happened, but dmraid failed to build because somehow DP() got changed to Dp() the last time I refreshed that patch.  I need to bump the package rev and propose another merge don't I?
<cjwatson> psusi: nope, I beat you to it and fixed it already :)
<psusi> heh, cool... I can't believe that happened...
<cjwatson> ah well
<cjwatson> I ought to have build-tested before upload
<psusi> I literally typed in the opening while() { and then just highlighted that whole block and ran indent-region and appended the }... nothing should have changed except the indent there...
<psusi> cjwatson, I've also tracked down that raid10 problem... we have a patch to parted that tries to identify the partition devices and omit them, but it does so by looking to see if the dm device has another dm device as a target, which is also true for the main raid10 device.  I think I can fix it by modifying the patch to actually look at the target, make sure it is only one target, and that it is a linear mapping, and THAT should only be true for a part
<psusi> ition device.  Is that something that can still get in this cycle if I get it done this weekend?
<cjwatson> psusi: I'd have to look at the patch, but yeah, I recognise the problem; I expect this weekend should be fine, as the archive will reopen for a period of a bit over a week after beta-1
<psusi> oh wait, that would unhide the main raid10 device, but you also want to hide the lower level raid0 devices it is built on instead... so I guess that idea doesn't fully address it... maybe have to let this one go for next cycle and see where this discussion I got going about changing the uuid prefix to flag devices as internal or partition vs "disk" goes...
<cjwatson> it's certainly in principle possible to follow the whole dm chain up with just libm
<cjwatson> libdm
<cjwatson> whether you want to bother is another question, and I expect it would mean grovelling around in /dev/mapper beyond just the device the user asked for
<cjwatson> maybe
<psusi> right, but I don't think parted should be guessing about whether a given device is internal or intended to be partitioned and used like a disk... I think dmraid/lvm/whatever should explicitly indicate that
<cjwatson> perhaps
<psusi> lvm snapshots also create a few internal devices that you don't want showing up in things like parted, and so does pvmove
<psusi> cjwatson, say, I thought when a build failed, it got stuck in the upload queue and to re-upload it you had to bump the revision?
<cjwatson> I did bump the revision
<psusi> strange... bugs were closed saying 4.1-ubuntu2, lp page says last upload was 4.1-ubuntu3, but current natty rev is 4.1-ubuntu2
<cjwatson> source uploads close bugs
<cjwatson> 1.0.0.rc16-4.1ubuntu3 is working its way through but has not been published yet
<psusi> ahh
<cjwatson> everything is functioning normally; there is no cause for concern
<zubin71> hello everyone, is there any kind of an apt-get hack which can get me a listing of deb packages(in the ubuntu repo, of course) written in C?
<cjwatson> FYI, https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032789.html
<sven777> does keybuk ever come around anymore?
<directhex> NCommander, ping
<directhex> NCommander, try installing libmono-addins0.2-cil from debian experimental to fix breakage of apps like banshee on mono 2.10
<c2tarun> how can I check whether a pacakge is in universe or multiverse?
<kklimonda> apt-cache show, apt-cache policy will tell you, apt-cache showpkg
<c2tarun> kklimonda: some packages on this ftbfs tracker are not ftbfs http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi how come?
<kklimonda> c2tarun: maybe they've already been fixed by someone?
<c2tarun> kklimonda: fixed and uploaded by same version number??
<c2tarun> kklimonda: for example check package elektra its versio in tracker and in archive is same, and the one in archive build successfully on natty
<kklimonda> c2tarun: a package can fail to build because of problems in other packages, in this case you can just retry a build when the other package is fixed.
<c2tarun> if a package is not following any packaging system or patching system, its just an ubuntu application how can we create a patch for it?
<thekorn> c2tarun: bzr branch lp:ubuntu/package_name; cd package_name; "do your changes"; bzr diff > yourpatch.patch
<c2tarun> thekorn: that package is not on lp I think, but ya diff will do :) thanks
<c2tarun> what is meaning of 1.0 in debian/source/format file?
<directhex> c2tarun, debian source fomat 1.0
<directhex> man dpkg-source
<c2tarun> directhex: how to  apply a patch in this case, quilt push -a is not working :(
<directhex> c2tarun, did you export QUILT_PATCHES=debian/patches?
<c2tarun> oops ... sorry its and ec2 machine I forgot :(
<directhex> c2tarun, you need to integrate quilt into debian/rules yourself if it's debsrc 1. depends on the debhelper compat version as to how
<ScottK> directhex: However if Debian doesn't use a patch system we generally discourage adding one in Ubuntu.
<directhex> yes
<directhex> i assumed there was one already, given the talk of qult
<c2tarun> can anyone please help me with this error http://paste.kde.org/8149/
<Laney> does that file exist?
<c2tarun> Laney: error se no  and I check in previous version's manual folder there is no such file
<c2tarun> Laney: ping
<Laney> I don't know
<Laney> you should find out why it's not there
<op_amp> This might be OT but I need an answer for this ques. Previously, I worked on a project,written in python mostly. In that I used to directly modify the code in the installation director and check after running
<op_amp> But, what if whole project is written in c++ and wxwidgets? Then will I need to modify the source first, built it(takes time :() and then after installing see the code change effect
<op_amp> *?
<Gulfstream> is it possible for someone who learned to program with VB to help develop Ubuntu?
<bregma> Gulfstream, absolutely, VB skills are transferable to, say, Python
<ScottK> Gulfstream: Yes.  You'll need to be ready to learn new things but much of the development work does not require complex programming.
<ohsix> smegma D:
<ohsix> oops, wrong channel for such shenanigans
#ubuntu-devel 2011-03-27
<abhinav-> barry, Hi, I wanted to ask a question
<menecio> hi do you think that could be possible to include ubuntu's live installer in a debian-live image?
<ari-tczew> how long natty universe is closed? what's the deadline?
<hyperair> until beta, i expect.
<hyperair> https://wiki.ubuntu.com/NattyReleaseSchedule
<hyperair> that says march 31st.
<geser> ari-tczew: what you mean with universe "closed"?
<ari-tczew> geser: that every upload needs approve by archive admin
<geser> ah that, till beta release, but if nothing has changed then uploads to universe are only on "manual" (an archive admin has to manually accept them during the freeze)
<ari-tczew> closing universe is for me nosense, main OK
<geser> LP doesn't support only setting "main" to manual, so "universe" is affected too
<ari-tczew> so this is an issue
<ari-tczew> kenvandine: if you're doing only rebuild, please use version *build1 instead *ubuntu1 https://launchpad.net/ubuntu/+source/libmusicbrainz-2.1/2.1.5-4ubuntu1
<ubottu> Error: Launchpad bug 2 not found
<ari-tczew> kenvandine: you can use command 'dch -R'
<ari-tczew> slangasek: is it possible to get this change in Debian? package is QA https://launchpad.net/ubuntu/+source/libmusicbrainz-2.1/2.1.5-4ubuntu2
<ubottu> Error: Launchpad bug 2 not found
<B_Lizzard> Hi, I'm having an issue with notify-osd, not sure where to ask.
<B_Lizzard> I'm on Archlinux, not on Ubuntu but I figured someone might know of the problem I'm having
<B_Lizzard> After updating to libnotify 0.7.x, notifications from notify-send no longer replace one another if coming from the same source or even stack
<B_Lizzard> Instead, it waits for the previous notification to time out to display the next one etc.
<azeem> B_Lizzard: file a bug on launchpad (if there's none already), I'd say
<B_Lizzard> Well, I see that Natty has libnotify 0.7.2 but I'm not sure if this is a bug on Ubuntu.
<kklimonda> it is
<B_Lizzard> I'll have to boot the Alpha or something
<B_Lizzard> Ah
<B_Lizzard> OK, I'll post a bug report
<B_Lizzard> I guess this is a problem with notify-send, because other stuff which use notify-osd via library calls behave normally
<kklimonda> actually, I haven't seen any applications stacking their notifications correctly in natty so far
<B_Lizzard> I use notify-send for my volume buttons on my Thinkpad, and it worked correctly with libnotify 0.5.x and notify-osd 0.9.28
<B_Lizzard> Once I updated to libnotify 0.7.x notify-send stopped working like it did.
<B_Lizzard> Ugh.
<rigved> hi everyone. is it possible to make pbuilder use more than one core on a multicore machine?
<penguin42> rigved: I guess it comes down to whether you can set a DEB_BUILD_OPTIONS some where
<geser> not really as it depends if the packaging of that software and the software itself support building in parallel
<rigved> penguin42, geser: don't know really. i'm just following this guide from ubuntu dev week. thanks for your help. :)
<penguin42> rigved: I know if I'm building outside of pbuilder with dpkg-buildpackage then setting   DEB_BUILD_OPTIONS=parallel=10 works nicely
<rigved> penguin42: wow. thanks.
<penguin42> rigved: Looks like /etc/pubilderrrc ?
<penguin42> rigved: The man page for that says that you can set DEBBUILDOPTS=
<rigved> penguin42: yes. it says to use that. should i try to add the options there?
<rigved> penguin42: ohh. ok. will give it a try
<penguin42> rigved: I'm not too sure, not tried it in pbuilder
<rigved> penguin42: ya. i checked it. it seems like the way to go
<penguin42> rigved: Incidentally, the parallel-10 is on an i7 with plenty of ram; so 4 real cores, 8 threads - giving it 10 takss keeps it busy if it waits for disk; the value is always a bit of a guess
<rigved> penguin42: ya, it figured that you had atleast that much. mine will probably be just 3 or 4, as i only have 2 real cores
<vijo> Is this the appropriate forum for glibc problems
<vijo> I am getting an error from eglibc when I setup a cross-compilation environment.
<vijo> I havent looked at eglibc much, but if there is an expert here, that would be helpful.
<vijo> No one here wants some good karma, huh? ;)
<OdyX> ScottK: could you please comment on shiboken #740176 pyside #740177 ?
<OdyX> s/6/& and /
<ScottK> Yes.
<ScottK> OdyX: These are bug fix updates from what we have already, right?
<OdyX> ScottK: yes.
<ScottK> thanks.
<OdyX> ScottK: and they are the "1.0.0" release from upstream, so nice to have.
<ScottK> Agreed.
<OdyX> (and afaik, there are no bugs in Debian nor in Ubuntu about shiboken/pyside)
<ScottK> I've given them approval as sponsor, so we just need to wait for an archive admin to process sync requests.
<aroman> hey, what is this button state called? http://i.imgur.com/y5m7J.png
#ubuntu-devel 2012-03-19
<pitti> Good morning
<pitti> bdmurray: ubuntu-bug does accept executable paths, but only the full one; it does not search $PATH
<pitti> slangasek, Sweetshark: LibO did use it, but it seems not any more?
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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
<ion> Morning
<micahg> hi pitti :), how long are you around for?
<pitti> micahg: today? for about 30 mins
<micahg> pitti: oh, ok
<pitti> couldn't sleep any more, my brain told me all the stuff I still need to do today before I get sedated :)
 * micahg will need some copies in a few hours, but will find another AA
<alkisg> stgraber: I filed LP bug #959037 about not starting the local resolver if network-manager detects that a dns server (bind9, dnsmasq) is already installed
<ubottu> Launchpad bug 959037 in network-manager (Ubuntu) "Don't start local resolver if a DNS server is installed" [Undecided,New] https://launchpad.net/bugs/959037
<rickspencer3> pitti, beer and all green in the smoke tests this morning
<rickspencer3> !
<pitti> rickspencer3: yep, sorted out the remaining bits on Friday evening :)
<rickspencer3> pitti, nice work, will put us in a good position for beta freeze
<rickspencer3> pitti, was it hard to get the archive problems sorted?
<pitti> rickspencer3: no, not particularly
<pitti> just some discussion involved, and then pressing a few buttons
<rickspencer3> thanks pitti
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt needs some work still
<pitti> apw, janimo`: are linux-{ac100,n900} really supposed to get into main?
<pitti> infinity: d-i FTBFS on powerpc, presumably those kernel images went away in favor of -smp?
<infinity> pitti: Yeah, we're holding off on resolving that while we decide if we need to resurrect powerpc.
<infinity> pitti: (ppc-smp doesn't boot on my UP G3, at least, so we may need to revert the mess)
<infinity> pitti: And linux-ac100 and n900 are *not* main kernels, no.
<pitti> ^ that's what I thought
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt says open-iscsi-udeb and others now want them
<infinity> pitti: Seems like a virtual package oops, maybe?
<infinity> pitti: Confused resolver...
<pitti> it's fairly new on c-m
<infinity> pitti: Yeah, but neither of those kernels are new, so the fault lies elsewhere.
<micahg> pitti: AIUI, we don't want keywords for random universe packages just like we don't want the quicklists
<micahg> or rather don't want ATM
<pitti> quicklists need translations, but keywords not necessarily?
<pitti> but it was forwarded upstream, so it seemed harmless enough
<pitti> but I see that it's debatable
<pitti> ok, http://reports.qa.ubuntu.com/reports/sponsoring/ is down to 13 now, and that's about as much as I'm comfortable with sponsoring
<pitti> and I need to disappear anyway
<micahg> pitti: I'll take a look at the rest in ~20 hours when I pilot
<micahg> pitti: BTW, that was something else I saw the conversation about, not quicklists, so I might be confused, I'll check with seb128 when he gets online
<pitti> micahg: there's two or three SRUs which can still be sponsored, and the grub2 stuff if you feel up to it
<pitti> but there's a couple which still need some baking/upstreaming/fixing in precise first
<pitti> @pilot ot
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<micahg> pitti: ok, I'm sure there will be a few more by the time I get around to piloting
<pitti> heh, or that :)
<micahg> pitti: you have time for a quick copy?
<pitti> micahg: really need to run now, sorry
<pitti> doctor appointment
<micahg> pitti: np, I'll find someone else, thanks
<pitti> off for today, sick day
<rickspencer3_> bye pitti, hope you feel better
<rickspencer3_> wow, down to 13 items in the patch pilot queue?
<rickspencer3_> what a day
<micahg> StevenK: are you still around to do a copy from a PPA?
<infinity> micahg: If you ask nicely, I might be able to do something for you.
<infinity> rickspencer3_: dholbach's shaming has had an effect.
<rickspencer3_> infinity,  good ;)
<infinity> No one likes Daniel upset with them.
<rickspencer3_> infinity, combined with 0 archive problems and all smoke tests passing ... we're in good shape
<infinity> It's like accidentally kicking a puppy.
<rickspencer3_> I feel chuffed
 * infinity shoves a few archive problems under the rug.
<infinity> rickspencer3_: And yeah, +1 maint really does seem to be doing the trick.  I'm curious to see how well we can do during one of the "insane" cycles, rather than during a conservative LTS.
 * infinity has fond memories of edgy never actually being usable.  Like, ever.
<infinity> micahg: Last chance before I go and get some sleep (yes, I really do sleep sometimes, honest).
<micahg> infinity: ah, sorry, I stepped away for a minute, still available?/
<infinity> micahg: No, I left in the 15 second gap there.
<infinity> micahg: What's up?
<micahg> infinity: xulrunner-1.9.2/lucid from ubuntu-mozilla-security to lucid-security
<infinity> micahg: Just that?
<micahg> yeah, I still have a wee bit more testing on the other stuff
<infinity> Err, wait.
<micahg> I copied maverick and natty already, lucid timed out
<infinity> To security, not to proposed?
<micahg> infinity: yes
<infinity> Isn't there some USN magic that should happen with that?
<micahg> infinity: we have tools to unembargo, but they timeout when there are a lot of binaries
<infinity> Oh, or you just need manual intervention due to lp API lolz.  Check.
<infinity> 2012-03-19 07:43:06 INFO    49 packages successfully copied.
<infinity> Confirm this transaction? [yes, no] yes
<infinity> 2012-03-19 07:43:10 INFO    Transaction committed.
<infinity> 2012-03-19 07:43:10 INFO    Done.
<infinity> micahg: Enjoy.
<micahg> infinity: thanks
<dholbach> good morning
<tkamppeter> slangasek, hi
<apw> infinity, if you are still concious there are powerpc kernels here: http://people.canonical.com/~apw/master-next-precise/
<janimo`> pitti, linux ac100 doe snot need to be in main as far as I know, we have been making images for ac100 just fine so far. Unless tooling or policies have changed it can stay a simple community supported image seeded from universe
<apw> ev, when woopsie is at the 'you had a problem' stage and has yet not collected details, does it have the binary name of the crash?  i would quite like to be able to see that before details is collected if so, and am suggesting perhaps making it a tooltip on the detail button or something subtle
<hrw> uf. according to my script we have 4717 packages without -dbgsym ones
<geser> how many of those have a -debug package?
<hrw> http://paste.ubuntu.com/890445/ is list and http://paste.ubuntu.com/890445/ is script if someone is interested
<hrw> geser: -dbg check is my next step. but amount of packages may be lower as I have some external ppas
<seb128> hrw, how many of those are not candidate to having a debug?
<seb128> hrw, like a shell script
<hrw> seb128: many probably - have to go though list and improve script
<geser> hrw: and you linked the same paste twice
<seb128> hrw, there is no reason we would miss dbgsym out of publishing bugs (which happen)
<hrw> ops
<hrw> geser: 890444
<seb128> hrw, basically anything calling dh_strip (i.e stripping binaries) should have a dbgsym
<hrw> I know
<hrw> or ones which call pkg-create-dbgsym by hand (like binutils)
<seb128> hrw, what are you trying to get at?
<hrw> seb128: I am working on creating ubuntu based sysroots for Linaro's binary toolchain. Making sysroot imge with -dev packages is quite easy. problem starts when someone also wants debug symbols
<hrw> seb128: so based on one of my scripts I wrote extra one which checks fo packages without dbgsym support
<seb128> hrw, your script is buggy
<seb128> hrw, like gnome-session is listed but it has ddeb support, http://ddebs.ubuntu.com/pool/main/g/gnome-session/
<hrw> seb128: yes, it is - fast written
<wzssyqa> why there is an symbol link "ubuntu" in archive.ubuntu.com/ubuntu to .?
<seb128> hrw, so what's the point of making boggus number claims on that channel? ;-)
<seb128> hrw, I'm still not sure what feedback you were aiming for claiming that 4700 "packages" don't have a dbgsym there
<hrw> seb128: sorry, just wanted to share yet-another-rather-useless-for-most thing
<seb128> hrw, well it would be useful if you didn't come with boggus numbers ;-) it seems like a finger pointing on Ubuntu or something
<hrw> sorry, does not planned to offend anyone
<seb128> hrw, it would be useful if you came with a list of packages than should have a dbgsym and don't rather
<hrw> seb128: will post such one during this/next week
<seb128> hrw, rather than coming stating "css themes and shell scripts don't have a dbgsym"... sure what would be a dbgsym for a css ;-)
<hrw> ;)
<hrw> seb128: thank you for it - added notes
<seb128> hrw, thanks, looking forward having a reasonable list of what is buggy and we should fix ;-)
<hrw> seb128: css themes and shell scripts are usually 'architecture:all' so I skip them. but there are some false negatives on my list still
<seb128> hrw, well you have weird stuff like hundred of language-support packages
<seb128> hrw, and you have bugs, i.e gnome-session is listed but it has a dbgsym
<seb128> hrw, oh, i.e gnome-user-docs is listed but it builds only gnome-user-guide which is arch all and documentation
<seb128> hrw, so your arch all filtering is somewhat not working I guess
<hrw> seb128: I started next run with some fixes
<dholbach> is it normal to have 65 "/usr/lib/cups/notifier/dbus dbus://" processes running?
<dholbach> tkamppeter, ^ :)
<hrw> dropping oneiric from apt config helps ;D
<MacSlow> mvo, poing
<tkamppeter> dholbach, no.
<dholbach> tkamppeter, what could be the cause for having that many?
<tkamppeter> dholbach, never heard about that. Perhaps you should report a bug and I will forward that straight upstream.
<tkamppeter> dholbach, who is dbus expert here?
<dholbach> will do
<dholbach> tkamppeter, a lot of people know about dbus in here
<htorque> dholbach: i see this on two of my systems (52 instances on one, 100 on the other - each ~1.7mb)
<dholbach> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/959195
<ubottu> Launchpad bug 959195 in cups (Ubuntu) "65 cups notifier processes running" [Undecided,New]
<dholbach> tkamppeter, htorque: ^
<dholbach> you might want to subscribe to it or at least "affects me too"
<htorque> done and done
<dholbach> cool
<hrw> ok, 2568 packages to check
<hrw> but later
<vibhav> htorque: could I pm you?
<vibhav> Can*
<htorque> vibhav: sure
<htorque> hi all! to complete an answer on ask ubuntu, i'd like to know if using one's real name is mandatory for code contributions in general and for signing the 'Canonical CLA' in particular.
<ev> apw: bug 938707
<ubottu> Launchpad bug 938707 in apport (Ubuntu) "Hard to see which program crashed for "Internal error" reports" [Medium,Fix committed] https://launchpad.net/bugs/938707
<apw> ev, ta
<brendand> htorque, i would imagine that as long as the email that the 'signed' CLA was sent by and the contributors LP email are the same it should be ok
<brendand> htorque, i'm not an authority though
<sladen> htorque: do you have an exact example?
<htorque> sladen: for example, "Duffy Duck <duff.duck@gmail.com>" contributes to one of the projects that require signing the CLA - is that possible?
<htorque> brendand: thanks, do you know who to contact for getting a more official answer?
<sladen> htorque: ultimately you can put anything you want on the Commit ID
<sladen> htorque: the key comes to getting somebody to accept that
<sladen> htorque: which means the person-accepting-it needs to be sure that they are allowed to do so
<sladen> htorque: eg. that acceptor needs to be happy that a CLA exists that covers that contribution
<sladen> htorque: and that the CLA is valid
<brendand> htorque, i think in our environment the only secure way to confirm someone is who they say they are is that they can access the same email account for two purposes
<htorque> sladen: but are there any legal problems when signing the CLA with anything else than your real name?
<htorque> *than/but
<sladen> htorque: what's actually going to happen in practice, so that you'll probably push a proposed branch (using Bzr-over-SSH) to  launchpad.net/~htorque/+junk/proposed-patch-for-bug-1234
<sladen> is that
<sladen> htorque: and somewhere separate, that account will be on the ticklist for accounts that have signed the CLA
<sladen> htorque: and when filling out the CLA you will have put in sufficient details to allow you to be contacted
<sladen> htorque: (I perhaps understand your problem to some extant, as having a _boat_, that doesn't have a fixed address of its own)
<slangasek> bryceh: right, no sense in uploading it if we know it's going to FTBFS - I just thought you were uploading it already before that.  no matter :)
<slangasek> pitti: as I understand it, the libO that uses it has not yet been uploaded
<slangasek> tkamppeter: hi there
<sladen> htorque: if you can convince somebody else that you're called Duffy Duck, you can give it a shot
<sladen> htorque: though since there are several humans in the chain, one of them would likely spot and double check it
<sladen> htorque: in which case you'd probably have to pursuade a lawyer that you're called Duffy Duck
<sladen> htorque: OTOH, if it's tied to your Launchpad and there a GPG key on there signed by 20 Debian Developers confirming you _are_ known as Duffy Duck then that would probably solve it :)
<imbrandon> /win 6
<sladen> htorque: as those people are lending a small part of their own credibility into reenforcing that identity
<htorque> sladen: yeah, i guess it's hard to get it signed by even one person. ;-) so, to summarize: if there's no CLA, than it's basically up to the one accepting the contribution. if there is a CLA, it depends on the requirements of that CLA?
<sladen> htorque: there are a number of Canonical back projects that require CLA to contributions, in order to allow them to be relicensed in a flexibly and legally-sound way.  Getting people to sign CLAs is _not_ generally hard
<sladen> Canonical-backed projects
<sladen> htorque: (this does not stop you from contributing to Ubuntu)
<sladen> htorque: and is somethere for some of the upstream projects that Canonical steers
<sladen> htorque: and is only there for some of the upstream projects that Canonical steers
<htorque> sladen: but there are people in the ubuntu community that prefer to not use their real name for any activity. they are definitely ruled out by the canonical CLA?
<vibhav> as far as i am aware, any real names that are on signed contributor agreements  are not made public
<sladen> htorque: I don't think anyone stops that
<htorque> vibhav: but the signed contribution itself is
<vibhav> oh yes
<vibhav> hmm
<sladen> htorque: yes, Canonical care about having a legally-sound basis for the projects they steer.  If you're wanting to contribute to a Canonical Upstream project then you need to do that (with Canonical) in a legally sound way
<sladen> htorque: the options are generally:  (1) an employment contract  (2) a contracting agreement  (3) a legally-sound CLA
<htorque> i see. the Canonical CLA seems to require: first name, last name, email, phone, address, country
<sladen> htorque: if you have some specific situation (eg. war-torn country, stalking issues, living a boat without a fixed address), then we could look into it.  But both yourself and Canonical would have to be happy that the result was a legally-sound understanding entered into in good faith by both parties
<sladen> htorque: (and not that this is only about contributing code upstream, _to_ Canonical upstream projects.  It doesn't apply to eg. Ubuntu, or to forked your own versions of Canonical upstream projects)
<sladen> and note
<htorque> sladen: thanks, that pretty much answers the question (not "my" question, it's on ask ubuntu â http://askubuntu.com/questions/112434/is-there-a-real-name-policy-in-the-ubuntu-community).
<sladen> htorque: (and if you'd prefer to discuss this in private, I'm happy to do that aswell)
<sladen> htorque: ah ha.  Well in that case, I can just answer there then :
<htorque> sladen: vibhav won't like that (due to the bounty going on) :P
<htorque> he basically answered all the other points, just the code contribution was left.
<vibhav> htorque: :(
<sladen> htorque: vibhav: well, I _hope_ the aim is to get a high-quality answer up there, not who gets the prize
<vibhav> sladen: sure
<sladen> htorque: vibhav: PS. next time you've got a similar query, could you try and post the link giving the high-level summary _first_, not _last_!
<htorque> sladen: right, sorry. i just mentioned ask ubuntu - forgot the link.
<vibhav> me too
<apw> pitti, we hold ddebs 14 days from when the master binary packag
<apw> package is reaped right ?
<ScottK> sladen: I think it's a mis-statement to claim the CLA is in any way required for Canonical to be "having a legally-sound basis for the projects they steer".  If that were true, Ubuntu would be legally unsound.  It's not.
<ScottK> htorque: There's no real name policy in Ubuntu.
<htorque> ScottK: but then, why require a CLA at all?
<ScottK> htorque: Ubuntu doesn't require one.  It's other Canonical projects that do.
<htorque> (if not for legal reasons)
<ScottK> htorque: It's so that they can also ship code in their other projects under a proprietary license if they want to.
<ScottK> So it's not needed for any legal reasons related to Ubuntu.
<ScottK> It may be needed for legal reasons for other proprietary stuff.
<ScottK> I guess that's a more correct way to put it.
<htorque> ScottK:  however, it's needed for the contribution to be accepted (in ubuntu) in the first place?
<ScottK> htorque: Not in Ubuntu, just those other projects.
<infinity> ScottK: Jumping immediately to proprietary is a bit unfair, it's for ease of relicensing, period.
<htorque> ScottK: but then the code cannot be merged into the upstream project and ubuntu would need to carry a patch around, right?
<ScottK> infinity:  True, but they could solve a whole world of trouble by just saying "sign the CLA or submit your changes with a BSD like license".
<ScottK> htorque: For those projects that's true, but there's a huge amount of Ubuntu that's nothing to do with them.  Also Ubuntu has carried patches for such projects in the past.
<infinity> ScottK: I suppose the FSF could do that too, but they don't.
<sladen> ScottK: that is basically what the CLA (now) says
<sladen> (CLA != CCA)
<ScottK> Yes, but the FSF isn't a for profit company.  Even if I trust Canonical, I can't assume they won't eventually be bought (cf Sun/Oracle), so I think the comparison with the FSF is irrelevant.
<sladen> ScottK: charities can make a profit, and companies can make a loss.  Why would a random label of "for profit" have anything to do with it
<ScottK> sladen: OK.  That's shorthand for a corporation.  At least in the US, non-profit entities can't be bought and sold.
<ScottK> There are not for profit corporations, so the for profit isn't 100% correct, but they are rare.
<sladen> ScottK: occasionally like-minded people with a cause in common club together to form an organisation of some sort.  Be it familes, or charities, or foundations, or companies, PLCs, LLPs, amateur radio clubs, canoe clubs etc
<sladen> Charities can be usurped, such as companies can
<ScottK> In the US, these are formed under section 501(c)3 of the tax code.  They have a governing board and a charter to do certain things to which they are limited.
<ScottK> I haven't read the FSF charter, but I expect it includes some reference to free software, so I believe there would be some legal reprocussions if somehow it's board were packed and it's policies flipped to be proprietary friendly.
<ScottK> I'm not saying it's impossible, but it's an entirely different thing than a corporation being sold.
<ScottK> The latter is a normal, expected thing.
<pitti> janimo`: ok; not really sure why it's on c-m right now
<pitti> apw: yes
<htorque> sladen, ScottK: who would you need to talk to if there were any problems with signing the CLA? the project's contact listed at http://www.canonical.com/contributors? just want to add that to the existing AU answer (unless sladen is going to add his own answer).
 * ScottK has no idea.
<ScottK> htorque: My main request is that you not say Ubuntu requires the CLA.  It doesn't.
<htorque> ScottK: yeah, sladen made that clear already. :-)
<ScottK> OK.  Just making sure.
<sladen> htorque: if in doubt, you can post the query to me
<sladen> htorque: I think my name is still in the CLA PDF metadata ;-)
<sladen> htorque: and wendar will be able to give some detailed insight too
<DiegoTc> Hi guys, just wondering was ubuntun accepted on the gsoc 2012?
<MacSlow> didrocks, seb128: the patches from https://bugzilla.gnome.org/show_bug.cgi?id=671780 are not yet part of libgnome-desktop-3-2, right?!
<ubottu> Gnome bug 671780 in libgnome-desktop "gnome-bg: improve "representative colour" algorithm" [Enhancement,Unconfirmed]
<ScottK> DiegoTc: It was not.
<seb128> MacSlow, didrocks: they are in precise
<ScottK> (missed the application deadline by 10 minutes)
<MacSlow> didrocks, seb128: sorry... wrong bug URL... one sec
<seb128> MacSlow, didrocks: I backported them
<seb128> MacSlow, I know what bug you talk about, that's in precise for a week
<MacSlow> seb128, didrocks: ah ok... thanks
<sladen> htorque: vibhav: ScottK: is  http://askubuntu.com/questions/112434/is-there-a-real-name-policy-in-the-ubuntu-community/114250#114250  any use?
<htorque> sladen: thanks. are you going to add an answer to that question (the bounty is still open for three days), or do you want me to edit it into an existing one (or do it yourself)? it's really up to you if you want to go for the reputation. :-)
<htorque> sladen:  ah
<ScottK> htorque: There's no requirement for a key signed by other people.
<ScottK> I have, for example, generated a new key, added it to my LP account, and used it immediately to upload packages when I was traveling somewhere I wasn't comfortable taking my existing key.
<ScottK> Debian has such a requirement, but Ubuntu doesn't.
<ScottK> What's needed to upload directly is to be accepted as an Ubuntu developer.
<sladen> ScottK: okay, so the crucial thing is actually that the DMB sets membership of ~ubuntu-dev in Launchpad
<sladen> ScottK: and everything ease hangs off that
<ScottK> It's not just the DMB.
<ScottK> For example, for kubuntu-dev, it's done by Kubuntu Developers (which gets you in ubuntu-dev).
<ScottK> But generally, yes.
<ScottK> Which is why I say there's no real name requirement in Ubuntu.
<ScottK> It does have to look like a name, because (IIRC) LP people get grumpy about things that don't appear to be names.
<Laney> not sure it does https://launchpad.net/~wookey
<Riddell> Laney: that is his name (it makes getting through customs in a hurry hassleful)
<Laney> Riddell: My point was that it only has one part
<Riddell> Laney: he only has one part to his name
<Laney> yes, I am aware
<sladen> Laney: that name matches his passport :)
<m_3> cjohnston: pong
<Laney> I wasn't trying to say that it's not a real name (how could Launchpad know that?), just that it only has one component.
<Laney> so Launchpad isn't so prescriptive about the form names have to take.
<tkamppeter> slangasek, I only want to tell you that Ghostscript upstream guys tell that freetype 2.4.9 has a bug which breaks Ghostscript, so please avoid an FFE to update from our 2.4.8 to 2.4.9.
<slangasek> tkamppeter: 2.4.9 also includes security fixes (as nearly all of them do).  Can you give me a pointer to the bug?
<tkamppeter> slangasek, please join #ghostscript. They can explain the problems to you.
<slangasek> tkamppeter: can't look at it right now, sorry; will someone be around later if I drop in there?
<tkamppeter> slangasek, I will ask.
<tkamppeter> slangasek, see https://savannah.nongnu.org/bugs/index.php?35847 and https://savannah.nongnu.org/bugs/index.php?35833
<tkamppeter> slangasek, Chris Liddell (IRC: chrisl) has made patches for Freetype which are committed to the Freetype repos but are not in 2.4.9. You will have to backport these patches.
<tkamppeter> slangasek, Chris will be available on #ghostscript until 5pm UK time today.
<apw> cjwatson, i am perlexed, i just added one module to the d-i configuration for the virtio udeb, and the alternate image no longer have any of the modules in it, whereas before they did
<apw> cjwatson, actually lets say --- whereas they are claimed to have been there before ... i don't have an old enough ISO to confirm
<apw> cjwatson, indeed i even see the d-i build installing virtio-modules-3.2.0-19-generic-di as if it was going to use it ... hrm
<BenC> My memory fails meâ¦what package builds the alternate cd's?
<apw> BenC, it might be the debian-installer ... as it knows about kernel versions etc
<ogra_> BenC, debian-cd
<ogra_> (and a bunch of scripts called cdimage)
<BenC> apw: had already checked thatâ¦it just builds the initrd's and boot compnents
<BenC> ogra_: thanks
<ogra_> (check the branches of the ubuntu-cdimage team on LP
<apw> ogra_, you may know, how does one know which udebs are included in a specific iso ?
<mhall119> seb128: what options do we have to fix icons on packages in partners?
<mhall119> any?
 * mhall119 is specifically looking at skype
<seb128> mhall119, dunno, I'm not the person to ask, I've no clue about partners, ask mvo maybe
<mhall119> mvo: ^^ ??
<ogra_> apw, look at the respectinve .list file for teh iso on cdimage
<mvo> mhall119: sure, a new app-install-data-partner is needed
<ogra_> and grep for .udeb or so
<seb128> mvo, that don't include runtime icons for unity does it?
<mhall119> mvo: what does that mean? (please forgive my ignorance)
<mhall119> mvo: specific case of skype: we have a 24px and 48px PNG, which look terrible in alt-tab switching.  If we were to get an SVG for it, can it be used?  Or does any image have to come from Skype?
<apw> ogra_, and if what i want is missing, where are the master copies?
<cjwatson> apw: let me have a look
<infinity> Riddell: Which "corner image" are you referring to in bug 942543?
<cjwatson> apw: there's a manifest in the d-i output
<ubottu> Launchpad bug 942543 in ubiquity (Ubuntu) "[KDE] UI needs graphics to match wallpaper" [Medium,New] https://launchpad.net/bugs/942543
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/MANIFEST.udebs
<apw> cjwatson, i think virtio is not a udeb used in the images ... if i have done what ogra asked correctly
<mvo> seb128: oh, runtime icons? no, just software-center icons
<cjwatson> ogra_: no, the .list file is no good for udebs in the initrd
<ogra_> oh, indeed
<cjwatson> apw: ogra_'s instructions are not correct here :)
<ogra_> only for the installable ones
<ogra_> sorry
<mvo> mhall119: we need to talk to skype about this, I don't think we can simply change that
<mhall119> ok,that's what I figured the answer would be
<apw> cjwatson, ok ... the manifest claims its in there
<mhall119> thanks mvo
<apw> virtio-modules-3.2.0-19-generic-di 3.2.0-19.30 amd64
<seb128> mvo, the question for mhall119 was "can we add a svg icon for skype to the skype package in partner", ie can we do such changes or do they need approval from the partners who submitted them?
<cjwatson> apw: only for some images
<seb128> mvo, ok, I see you replied while I was typing :p
<cjwatson> apw: so which image were you expecting virtio-modules to be in?  the build system only puts it in netboot images
<apw> oh oop
<apw> cjwatson, ahh as the main server images include the -virtual kernel i was sort of assuming virtio was in them ... so that implies the 'they were there' is completly erroneous from the reporter
<mvo> seb128: sorry, I missed some context
<cjwatson> apw: -virtual isn't used for installation
<cjwatson> it may be *installed*
<seb128> mvo, no worry ;-)
<mhall119> mvo: who would be a good person for me to talk to about getting better icons for those packages? (currently skype and adobe-flashplayer)
<apw> cjwatson, yeah these images are being booted in virtual environments, even though they are non -virtual kernels for booting
<cjwatson> apw: virtio_blk is in block-modules right now, and virtio_net is in nic-modules - those are probably better
<cjwatson> apw: but I'd need to know exactly which module you're talking about
<apw> cjwatson, these are hyper-v modules, modules for disks and network for that
<apw> it sounds like i may have put them in the wrong hole
<cjwatson> mind you, {block,nic}-modules depend on virtio-modules
<infinity> apw: Is that a frequent complaint?
<cjwatson> so that actually ought to be dragged in
<mvo> mhall119: the foundations team took this over, so slangasek I would think
<cjwatson> oh, of course, block-modules doesn't actually go in the cdrom initrd
<apw> cjwatson, i definatly am not seeing them in the /install/initrd.gz on todays ubuntu-server daily
<cjwatson> the cdrom initrd should only have enough to load stuff off the cdrom, not general block modules
<apw> infinity, that they are missing ?
<mhall119> slangasek: I'm trying to get SVG icons for skype and flash-player-properties, do you happen to know who I can talk to about that?
<cjwatson> are these modules necessary for talking to a virtualised cdrom?
<Riddell> infinity: in the ubiquity KDE frontend
<apw> cjwatson, i don't believe they are no, so they may be confused about needing them then
<infinity> apw: No, putting tihngs in the wrong hole.
<apw> infinity, *slap*
<cjwatson> apw: then they aren't meant to be in the initrd - the installer loads more stuff at run-time
<infinity> Riddell: I gathered that, yes, I meant which image.  The swirly watermark looking thing in the bottom left?
<apw> infinity, there is no wrong hole
<apw> cjwatson, ok i will go and debug this with them, thanks for your help
<cjwatson> apw: either virtio-modules or {block,nic}-modules as appropriate ought to work, based on what you've described, and it isn't necessary for them to land in the initrd
<cjwatson> feel free to point me at the bug
<apw> cjwatson, yep i think we have a clear case of reporter not being at all clear what the issue is and we may actually have no issue at all
<apw> or the issue is at a different level ... please flush from your mind until i have something that makes more sense
<cjwatson> flushed :)
<infinity> apw: Hrm, while you're around, I suppose I should test your new kernel for my G3.
<apw> infinity, eeep
<Riddell> infinity: that's the one
<infinity> Riddell: Kay.  That's not being pulled from a theme distributed with kubuntu, then?  I'll poke it after I test a kernel on my firewall.
<apw> cjwatson, so i am hearing you say that the d-i boot kernel can use the udeb off the CD to suppliment its modules
<Riddell> infinity: I don't remember, it'll be the KDE frontend pointing to a .png file but that file is either shipped with Ubiquity or elsewhere in KDE
<Riddell> infinity: we can just get rid of it so this doesn't reoccur
<infinity> Riddell: Seems fair enough to me, the UI will look nice enough without it.
<nigelb>  /ws 20
<nigelb> grar
<cjwatson> apw: yes, that's central to how d-i works
<apw> cjwatson, thanks one day i'll learn enough to run away from it
<cjwatson> apw: the initrd only has enough bits to allow d-i to fetch more of itself
<cjwatson> it's like a base system
<apw> yeah very logical when you have to have the rest on there anyhow
<cjwatson> d-i has rough analogues (though much less capable) of dpkg and apt
<infinity> apw: New kernel boots fine.
<apw> infinity, oh dear, thanks
<infinity> apw: Did we really expect otherwise?
<apw> infinity, i try and not expect testing results one way or the other, tends to lead to madness
 * infinity did, however, run into a weird initrd issue he needs to try to reproduce sometime...
<jamespage> any fglrx guru's around? bug 865984 is killing me frequently ATM
<ubottu> Launchpad bug 865984 in Ubuntu "firegl_sig_notifier crash on shutdown or reboot" [Undecided,Confirmed] https://launchpad.net/bugs/865984
<apw> cjwatson, ok the issue seems to be that the virtio udeb seems to missing en-toto from the images all of a sudden
<MacSlow> didrocks, seb128: what's your acceptance-window in regards to notify-osd (with the avg-bg-color fixes) ... do you want a new tarball-release or do you want to distro-patch it?
<seb128> MacSlow, do you plan to fix any of the other bugs? like the multiscreen support to match the new unity design?
<apw> cjwatson, it was in there on the 14th and not now
<MacSlow> seb128, yes
<seb128> MacSlow, I would recommend you roll a tarball once you get those ready
<MacSlow> seb128, d'accord
<slangasek> mhall119: so the idea is you're going to provide an SVG icon and want to know if we can put it in the package?
<mhall119> slangasek: or who can I talk to about requesting an SVG file from the upstream
<infinity> apw: So, where do we go from here?  Resurrect powerpc, or try to figure out how to make powerpc-smp work?
<cjwatson> apw: which image exactly?
<cjwatson> oh, never mind, I know, infinity uploaded d-i but didn't bump the kernel-version lines in the seeds :)
<apw> http://cdimage.ubuntu.com/ubuntu-server/daily/current/precise-server-amd64.iso <-- cjwatson
<cjwatson> so that'll have hosed the alt/server images
 * cjwatson goes to fix that
<infinity> cjwatson: Oh, derp.
<infinity> cjwatson: Can I blame St Drinking Day?
<cjwatson> only if you celebrated it
<apw> we celebrated it by beating them at rugby :)
<infinity> cjwatson: I celebrated it quite heavily.
<infinity> Enthusiastically?
<infinity> I may still be feeling the effects.
<slangasek> mhall119: I think requesting one from upstream is unlikely to be fruitful, given past success at getting the skype download page changed to not point people at the wrong package for 64-bit Ubuntu
<cjwatson> apw: rebuilding images
 * cjwatson is slightly surprised jenkins didn't explode at this
<apw> cjwatson, yeah ... how long does a rebuilt take ?
<cjwatson> minutes
<apw> cjwatson, wow, i was expecting you to day hours
<apw> cjwatson, i have a keen tester so if there is some way i can tell they are done ...
<infinity> apw: Alternates are fast.
<infinity> apw: Nervously refresh cdimage.ubuntu.com/whatever/image/you/want and look for a new directory? ;)
<cjwatson> don't have to wait for an archive cycle either since it's just seed changes
<apw> infinity, so thats when i see like a 210120319.1 form?
<infinity> apw: Aye.
 * apw clicks reload furiously
<smoser> cjwatson, around ?
<cjwatson> smoser: yes, albeit sprinting
<smoser> k. well...
<smoser> i was looking at https://bugs.launchpad.net/qemu/+bug/957622
<ubottu> Launchpad bug 957622 in qemu-kvm (Ubuntu) "kvm -kernel with grub multiboot kernel dumps core or exits" [Medium,In progress]
<smoser> and i got a bug fixed in kvm locally, so i can load the "grub loader image"
<smoser> and all seems well when I use the kvm -kernel <grub-image> with a partition'd disk image.
<smoser> but when i use it with a image of a partition (ie, with no partition table)
<smoser> i see something like this:
<smoser>  http://paste.ubuntu.com/890852/
<smoser> that 'multibooting' comes from the grub image that is built via http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/mk-image-mb-loader
<cjwatson> smoser: chances of looking right now: minimal - could I have a bug with full instructions on how I can reproduce this *without* having to spin up a full cloud toolchain and I'll queue it up?
<smoser> i'm pretty sure the rescue prompt is coming from the core.img that has then been loaded.
<smoser> cjwatson, you really dont need anything other htan kvm  to reproduce.
<smoser> (and download of a largish image)
<smoser> i can do that.
<cjwatson> shouldn't it just be a grub-mkimage command to build the core.img?
<smoser> build what core.img ?
<smoser> you mean rather than mk-image-mb-loader ?
<cjwatson> the grub image you're talking about
<smoser> well there are 2 grub images :)
<cjwatson> surely your script is basically just calling grub-mkimage with a load of options?
<smoser> yes.
<smoser> and that grub image then tries to find and load core.img from inside a disk
<cjwatson> oh right
<smoser> its *that* one that i think is giving me the errors
<cjwatson> well, the shorter the instructions the better but basically I will need something that can be run in a grub build tree without assuming that it's all packaged and installed
<smoser> ok. i can work on getting na nice bug gtogether.
<smoser> but once i'm in that rescue image, it likes to print
<smoser> "error: no such partition."
<smoser> ie:
<smoser>  grub rescue> insmod (hd0)/boot/grub/echo.mod
<smoser>  error: no such partition.
<smoser> cjwatson, what builds core.img ?
<smoser> in a normal ubuntu install
<cr3> how can I configure apport to create bugs on staging.launchpad.net?
<pitti> cr3: APPORT_LAUNCHPAD_INSTANCE=staging apport-bug ...
<cjwatson> smoser: grub-mkimage via grub-install
<smoser> right.
<cr3> pitti: thanks, does APPORT_STAGING=1 still work then?
<smoser> so how tied is a core.img to a disk layout (partitioned or non-partitioned)
<pitti> no, it doesn't
<cjwatson> smoser: (a) prefix hardcoded by either grub-mkimage or grub-setup, depending (b) modules built into core.img.  but please, I would prefer not to have a pre-debugging pass :)
<slangasek> mvo: question for you on bug #876298
<ubottu> Launchpad bug 876298 in update-manager (Ubuntu) "[MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [Critical,Triaged] https://launchpad.net/bugs/876298
<slangasek> mvo: two-part question, actually :)  1) if we use a dpkg trigger, is the trigger supposed to fail on download failure or succeed? 2) if the trigger succeeds, how are we supposed to let the user know, if at all, that the software they selected for install isn't usable at the time of install?
<nxvl> pitti: around?
<nxvl> pitti: i just got a fresh installed ubuntu system and for some reason jockey-text -l return nothing
<nxvl> pitti: and i have an nvidia card and restricted wireless card
<mvo> slangasek: 1) I think the trigger should succeed in any case 2) I don't know - maybe via a update-notifer interactive upgrade hook message?
<mvo> slangasek: but I'm happy to discuss this in the bug itself :)
<slangasek> mvo: not sure I understand what an "update-notifer interactive upgrade hook message" is/would be
<mvo> slangasek: sorry http://wiki.ubuntu.com/InteractiveUpgradeHooks I should have put that into my answer
<slangasek> thanks for the link
<mvo> slangasek: this will trigger a dialog during the upgrade
<mvo> slangasek: for if there is no UI during the upgrade on the next login
<slangasek> mvo: cool; I've updated the bug with this, thanks
<mvo> slangasek: thanks a lot!
<apw> cjwatson, ok testers confirm that those images are much better (as expected); thanks for you help with that, most appreciaited
<nigelb> ws 34
<nigelb> Ws 34
<nigelb> oh shoot
<kiko> hey
<kiko> is there an easy way to disable the cross-workspace mouse edge?
<kiko> sorry, not cross-workspace
<kiko> cross-monitor
<kiko> hmm, something in ccsm did it
<ogra_> heh
<ogra_> instead of using ccsm you could shoot both your feet directly, quicker and has similar effects :P
<smoser> bdrung, you around ?
<smoser> i had a question about distro-info
<tkamppeter> slangasek, did you see the FreeType bug report? Did you contact chrisl at #openprinting (he is still on the IRC).
<cjwatson> apw: great
<slangasek> tkamppeter: it's going to be late afternoon here before I can look into it, but I caught your comments about the upstream patches that need cherry picked - thanks for that
<PaoloRotolo> Hi all!
<slangasek> mvo: so do you suppose the code for this should go into update-notifier-core and packages depend on that?  or do you prefer a separate package?
<mvo> slangasek: I have no strong opinion either way, maybe its own package as it should be really lightweight and I would love to share it with debian
<mvo> slangasek: if mail is availalbe we would probably send mails on failure instead/in-addition of using the u-n hooks
<slangasek> mvo: well, Debian has update-notifier too, if an old version? :)
<mvo> slangasek: I believe so, a old version
<slangasek> mvo: ok - if you have no strong opinion, I'm going to prototype it within u-n, and if we want to split it out later we can
<mvo> slangasek: sounds prefect
<mvo> slangasek: you will work on this ?
<slangasek> yeah
<mvo> cool!
<bdrung> smoser: now
<ScottK> SpamapS: Did you do the landscape-client upload?
<SpamapS> ScottK: yes, did I jump the gun?
<SpamapS> Or did it FTBFS ? :-/
<ScottK> SpamapS: No, but it's trying to pull python-central back into Main.
<SpamapS> ScottK: Oh because its listed as an | ?
<ScottK> Could be.
<SpamapS> Or is it getting picked up? I didn't check closely
 * SpamapS looks
<ScottK> Dunno.  I just saw the components mismatches mail.
<SpamapS> it shouldn't even be run.. its only used on lucid
<ScottK> OK.  Maybe make a TODO to discuss with pitti how come it showed up on C-M?
<SpamapS> I'm checking more closely
<ScottK> OK.
<SpamapS> entirely possible it built in a way I didn't expect
<SpamapS> ty for the heads up, hadn't seen that yet
<slangasek> SpamapS: the upload reintroduced the build-dep on python-central | python-support, *neither* of which are in main
<SpamapS> AHH I thought that looked problematic
<slangasek> was this bit of debian/control autogenerated?
<SpamapS> Its in there entirely for backportability to lucid
<SpamapS> slangasek: no I doun't believe so
<slangasek> ok... so it's just that doko's distro changes were clobbered
<SpamapS> slangasek: indeed.. I'll un-do that clobbering shortly.. test building
<slangasek> ok :)
<cnd> slangasek, are you able to review FFes?
<cnd> we have one for an X package we'd like to get in before beta 2
<cnd> bug 959791
<ubottu> Launchpad bug 959791 in xutils-dev (Ubuntu) "FFe: Sync xutils-dev 1:7.7~1 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/959791
<infinity> cnd: Ack, and synced.
<cnd> infinity, ahh, thanks :)
<infinity> cnd: To be clear, the rebuild testing you intend to do is in a PPA, right, you're not just going to gratuitously no-change-rebuild every X package in the archive?
<cnd> infinity, I believe that's correct
<cnd> RAOF, Sarvatt?
<RAOF> infinity: Indeed.
<infinity> RAOF: Cheers, just wanted to make sure. ;)
<Sarvatt> yep indeed, that would be absolutely silly :) thanks muchly infinity!
<cnd> infinity, what time zone are you?
<infinity> cnd: Mountainish.
<cnd> ok
<infinity> cnd: Though something more akin to Easter this week.
 * cnd notes for future reference
<infinity> Eastern, too.
<smoser> bdrung, still ?
<bdrung> smoser: yes
<smoser> good.
<smoser> so my question was about distro-info
<smoser> i think this is a much needed tool
<smoser> so, thank you for that.
<bdrung> you're welcome
<smoser> my assumption is that the goal is to have one place to add new names / versions rather than each package update
#ubuntu-devel 2012-03-20
<smoser> right? and you can SRU that to stable releases.
<bdrung> yes
<bdrung> that's the plan
<smoser> i added code to use it in cobbler, but then was pointed at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<smoser> (i just dropped the Recommends in distro-info of cobbler to a Suggests)
<smoser> as it was showing mismatch for build-depends on distro-info of haskel
<smoser> so..
<smoser> so...
<smoser> to the question
<smoser> are you insistent on haskell?
<bdrung> i fail to see haskel in that diagram.
<smoser> right. its gone now.
<smoser> but there was a long line hanging off cobbler into some haskell libraries
<bdrung> the haskell version is way faster than the python version and therefore i like to keep the haskell version
<bdrung> there was a haskell transition
<smoser> hm.. well, since its a build-depens, it doesn't really gain us to do separation (like you've done with the -data)
<ScottK> bdrung: The problem is that haskell isn't and won't be in Main.
<smoser> ie, we sitll get all the build-depends pulled into main of the source.
<smoser> so, i guess my question is going forward would you be open to even splitting out source packages ? or something else that removed a dependency on haskell ?
<smoser> i think its absolutely silly to have to SRU a package to get a string change.
<Laney> you could feasibly have haskell bindings to a C lib
<Laney> in a separate package
<bdrung> smoser: what do you really want? distro-info in main?
<Daviey> I think what smoser is getting at, would you be happy having two source packages.. a distro-info-data (containing csv's) and a distro-info tool?
<smoser> well, i supose distro-info and distro-info-data.
<Daviey> That would mean that A) you don't need to recompile for SRU
<Daviey> and secondly, peope can cuse a shell or python version if they want. (in main)
<smoser> i'd like distro-info in main
<smoser> (or some shell usable utility, i dont really care about speed)
<Daviey> bdrung: I must say, that a 1.5M binary + csv is pretty nuts.
<bdrung> other user's care about speed
<smoser> because if the shell utility is not in main, then i have to write the same thing in shell
<smoser> (or python)
<smoser> people dont care about speed that much.
<smoser> and really, why would you call this program 1000s of times ?
<smoser> it changes once per 6 months
<bdrung> bash completion and bashrc
<smoser> thats fair.
<smoser> but i bet i can write native bash that are faster
<smoser> :)
<bdrung> Daviey: the binary size is due to haskell
<smoser> or very close.
<bdrung> smoser: i am willing to adopt a shell script if it can do the same as the haskell script and comes with a test suite
<smoser> well.... that'd only get us part of the way.
<bdrung> i can split distro-info-data into a separate package
<smoser> ok.
<smoser> yeah, so that'd work.
<Daviey> bdrung: Do you agree or not that a tool for this function, is crazy being 1.5M ?
<smoser> Daviey, i dont think we need to be rude :)
<smoser> i'm really thankful for the utility.
<bdrung> Daviey: yes, 1.5M is huge (but this is a restriction of Haskell)
<Daviey> Oh i am aswell.. i think that came out wrong.. Sorry bdrung
<bdrung> smoser: which interface do you use?
<smoser> i just wish i would have realized it needed some help for main inclusion.
<smoser> i'm using the shell interface.
 * bdrung wasn't offended.
<smoser> and i'd prefer that just because i dont care to do the date math.
<smoser> (shell interface == command line == distro-info --supported)
<bdrung> btw, the csv file shouldn't be used directly. so there are: command line, python, perl
<smoser> right. i guess i hadn't thought of using python library.
<bryceh> slangasek, hey in looking into a key mapping issue I notice our console-setup is quite diverged from debian's
<bryceh> slangasek, there's been quite a bit of change.  I'm figuring I should just cherrypick out the specific fixes I need, but wanted to check with you if we should think about a larger import of some sort
<bdrung> Daviey, smoser: which programming languages can be compiled in main?
<bdrung> or should this tool be codified in shell?
<smoser> i dont think there is a hard reason for shell.
<smoser> if you wanted to write it in C, that'd be fine.
<bdrung> i would prefer C over shell.
<Daviey> bdrung: I was going to also mention vala, but it's been demoted this cycle..
<smoser> that'd be fine. the only advantage of shell over C would be executable size.
<bdrung> vala would be a nice tool to learn
<Daviey> smoser: You don't think there is a slight speed advantage in C?
<bdrung> smoser: really? shell would be smaller than C?
<smoser> $ ls -l /bin/true
<smoser> -rwxr-xr-x 1 root root 22896 Nov 20 12:42 /bin/true
<Daviey> smoser: I imagine true is a compelx tool :)
<bdrung> running u-d-t 100 times takes 0.330s and running the python version of it takes 3.045s
<smoser> bdrung, where is "the python version" ?
<bdrung> smoser: in the source in python/
<bdrung> but it lacks some parameters
<ScottK> jtaylor: Why does python-numpy recommend gcc, but python3-numpy does not?
<infinity> bdrung: shell, C, C++, perl, python, there are a few options.
<infinity> bdrung: As much as it's taboo to mention it, Perl would do this same job MUCH faster than Python. :P
<smoser> infinity, FOR SHAME!
<bdrung> infinity: nope
<infinity> bdrung: (And it could be done entirely in perl-base, and have no deps outside Essential, I'm sure)
<bdrung> infinity: the perl version was the slowest
<infinity> bdrung: That's a pretty bold nope.
<bdrung> infinity: you can either blame perl or tumbleweed for that slowness ;)
<infinity> I'll go with the latter.
<bdrung> i would ask you to write a faster one, but perl is not readable.
<infinity> But other than the slightly larger disk footprint, C seems like a fair choice.  It's a simple enough thing to write bug-free on the first go.
<cjwatson_> bryceh: it's a pain to merge and historically merges have introduced a lot of fragility, so I would be -1 on a merge at this point.  feel free to cherry-pick, though.
<bryceh> cjwatson, sounds good, will do
<cjwatson> that's why it tends to "fall behind" as some people see it
<cjwatson> we'll deal at some point
<bryceh> yeah I can tell; the patch I'm dealing with appears to be a whole bunch of different changes all mashed together.  picking out what I need will be interesting
<cjwatson> hope you aren't trying to work with lp:{debian,ubuntu}/console-setup
<bryceh> cjwatson, am I interpreting correctly that at least some of the keyboard mapping is duplicating code elsewhere?
<cjwatson> almost certainly
<bryceh> cjwatson, no, git checkout from debian
<cjwatson> good
<cjwatson> yeah, some of the committers aren't ... quite perfect at separating out logical changes
<Sarvatt> ok so I want to file a bug about how apport hooks with questions present all questions twice if you click "show details" on the "Sorry, Ubuntu 12.04 has experienced an internal error." window to figure out what package the bug is for. Where would that go now?
<Sarvatt> whoopsie or apport? :)
<Sarvatt> xorg bugs are no fun when you have to click show details to figure out that its even the xorg bug you want to file now that it shows that generic info and walk through all of the questions to see what package its for, then again to actually file it
<Sarvatt> i usually have at least 10 .crash files in /var/crash that i've already filed bugs for so clicking show details on each is required to see if i'm wasting my time filing the same one
<smoser> bdrung, still around ?
<bdrung> smoser: yes
<smoser> i have a version of ubuntu-distro-info in shell that compares favorably in load times to the haskel
<smoser> http://paste.ubuntu.com/891634/
<smoser> i think the --date= needs some work.
<smoser> but it shouldn't add too much
<smoser> locally, 1000 runs shows http://paste.ubuntu.com/891636/
<smoser> but i have to run now.
<smoser> i'm willing to polish that some more.
<bdrung> smoser: you are fast. it could use "set -e". some comments would be nice.
<bdrung> smoser: --devel and --lts produce wrong output
<slangasek> bryceh: console-setup isn't a safe package to be doing large imports of post-FF... I'd say cherry-pick what you need
<ScottK> slangasek: He got the lecture from cjwatson already today.
<slangasek> heh, ok
<bryceh> slangasek, yeah picked out the bit I needed.  I gather all changes are direct applied rather than use a patch system?
<slangasek> it's a native package maintained in a VCS - a patch system would be unhelpful :)
<bryceh> er...
<komputes> hi bryceh how are you?
<bryceh> hi komputes I'm good
<komputes> thats good to hear, long time no talk. are you strictly maintaining xorg these days?
<bryceh> komputes, I would say more indulgently
<komputes> it's in your blood :D
<dholbach> good morning
<ZeroKewl> hi
<ZeroKewl> where did xbox controller started working out of box in ubuntu 12.04
<ZeroKewl> when* -where
<Riddell> janimo`: libva-cedarview-vaapi-driver for restricted?
<apw> can anyone tell me what an package flagged 'un' in dpkg -l means ?
<apw> un  linux-image-3.0
<apw> and indeed how one gets rid of em
<geser> apw: see the header of "dpkg -l" for an explanation (un: Desired=Unknown, Status=Not Installed)
<apw> geser, hmm oh desired ... so once you install a packge its in your db forever even if its not longer installed
<smb> That does not seem to be what happens when I uninstall things
<smb> Those seem to either become rc (removed configured) or go away (purged)
<geser> apw: I guess that's also true for any package dpkg knows about (because it's listed in Recommends, Suggests, Conflicts, etc)
<apw> geser, hmmm, i'd expect them to be singletons as they are all test kernels once installed long ago
<apw> un  linux-image-3.0-0-generic                             <none>                                                (no description available)
<apw> so that one i literally just purged it and its gone to that state
<geser> IIRC dpkg has a list of package names it has ever seen
<geser> check if it's listed in /var/lib/dpkg/available
<apw> geser, yep it is in there
<geser> try "dpkg --forget-old-unavail" (or ask someone who knows dpkg better than me how to get rid of those old entries)
<smb> So the difference is in how one uses dpkg -l: "dpkg -l|grep linux-image" won't show un, but "dpkg -l linux-image-*" will do
<jhojho> has anyone actually tried out the openssl package on 64bit precise?
<jhojho> i'm getting much slower speed timings for one and secondly, it seems to be dropping back to sslv3 vs tls1 for some reason
<jhojho> even when i have what I think is a correct config.....
<janimo`> Riddell, please purge that package, there will be a newer upload later, with fixed copyright
<Riddell> janimo`: rejected!
<janimo`> Riddell, thanks!
<janimo`> pitti, the acpi-support deprecation wikipage is almost 3 years old. https://wiki.edubuntu.org/AcpiSupportDeprecation . What is the status of this package? I lookoed at the hotkey debugging pages that mantioned it is being phased out but no details
<nailora> could someone un-private bug #930677 if possible? thanks!
<ubottu> Error: Launchpad bug 930677 could not be found
<nailora> it is referenced in Bug #952577
<ubottu> Error: Bug #952577 is a duplicate of bug #930677, but it is private (https://launchpad.net/bugs/930677)
<sladen> nailora: what is your Launchpad ID?
<sladen> nailora: poke
<brendand> sladen, i don't see anything private in there so it's un-privated
<sladen> nailora: see brendand above ^^
<nailora> https://launchpad.net/~nailor
<nailora> brendand: thanks
<MacSlow> mvo, ping
<mvo> MacSlow: pong
<slangasek> janimo`: acpi-support hasn't been phased out yet because there are some hotkeys that nothing else in the stack has handling for (antenna, touchpad toggling keys)
<seb128> slangasek, the pad enable,disable is handled by gnome-settings-daemon (just for info) but maybe you need something not desktop specific for those ;-)
<slangasek> seb128: when did it start handling them?
<seb128> slangasek, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=1c8f64d1dc6beb7d27a6dce74fa29e27e8c34583
<seb128> slangasek, so in the natty version it seems
<seb128> slangasek, if that's the same keys we are talking about
<slangasek> seb128: ah, I'm pretty sure X can't actually receive that keypress due to the core input limitation
<janimo`> slangasek, Riddell the acpi-support changelog mentions dropping power.sh when kubuntu starts using upower, not sure if that is the case, it is an old comment
<janimo`> slangasek, and are there better suited packages for the things acpi-support is still needed for or it is here as a catch-all for the forseeable future?
<seb128> slangasek, well, it works for most people it seems
<slangasek> janimo`: if there were better-suited packages, it wouldn't still be needed :)
<seb128> slangasek, we got bugs about the notify-osd corresponding images being reversed previous cycle
<slangasek> seb128: hmm, I'll have to test then
<seb128> slangasek, which indicates the g-s-d action get triggered
<seb128> slangasek, ok ;-)
<slangasek> seb128: right, but we just recently (this cycle) got a report from someone else wanting touchpad toggle support in acpi-support for a new device
<janimo`> slangasek, well what I meant was there may be other packages but migrating is ongoing and not terribly urgent
<janimo`> as opposed to noweher to migrate yet :
<janimo`> :)
<slangasek> janimo`: power.sh should definitely go away if kubuntu is using upowerd now
<seb128> slangasek, https://bugs.freedesktop.org/show_bug.cgi?id=31300#c2 might be interesting
<ubottu> Freedesktop bug 31300 in Protocol/Core "Add XF86XK_TouchpadOn/Off" [Normal,Resolved: fixed]
<seb128> slangasek, well not sure what happened since and if that works for laptop that have a physical action connected to the key or not
 * slangasek nods
<seb128> slangasek, seems it's the same issue than sound, some hardware require you to handle to action, some others don't
<slangasek> well, seems like those should be represented as different types of events
<slangasek> not sure why a button press that the software isn't expected to handle should ever show up as a key event
<slangasek> anyway, I'll test with my T60 and see what I get
<seb128> slangasek, because you still want the notify-osd bubble
<slangasek> there's no reason to logically represent that as a *keypress* though
<seb128> slangasek, what is doing the action doesn't matter much, but you want a consistent feedback mechanism
<slangasek> it's a notification event
<seb128> right
<seb128> that's a good point ;-)
<slangasek> so there should be a different channel for that from the kernel to g-s-d... and maybe that's the one that actually works now
<slangasek> anyway, I know thinkpads *don't* handle it in hardware, so I'll check it out and report back :)
<seb128> slangasek, thanks ;-)
<stgraber> dpm: can you add me to the translation team mailing-list whitelist so I can reply to mails without having them go through moderation, yet don't need to subscribe?
<dpm> stgraber, I can at least try :) IIRC there is a filter to accept any ubuntu.com address, but it seems not to be working. Let me have a look...
<stgraber> dpm: I usually do it through the moderation queue, when you accept my next e-mail, you can tick a box saying any other e-mail from my address is accepted
<dpm> stgraber, ah, I see. I never use the admin interface, I use listadmin, which is much quicker
<dpm> in any case, you're now whitelisted
<stgraber> dpm: thanks
<cjwatson> it'd be awesome if listadmin could understand that bit of the moderation queue interface
<cjwatson> popey: bug 960092 - can you tell me about your partition/filesystem layout?
<ubottu> Launchpad bug 960092 in grub2 (Ubuntu) "Latest update renders system unbootable "error: no such partition"" [High,Confirmed] https://launchpad.net/bugs/960092
<soren> debconf is confusing me.
<soren> When I add a template to a package  (which already used debconf)... How does its new templates get added to the debconf cache?
<soren> dpkg and debconf are separate, so it's not dpkg itself.
<cjwatson> the frontend loads templates from whatever it's operating on
<cjwatson> dpkg-preconfigure does it too, via apt-extracttemplates
<soren> Ah.
<soren> It's a bit special. I'm building something very much like dbconfig-common, so my package ships the templates, but doesn't actually use debconf itself.
<soren> ...so that's why they're not getting loaded (and why I can't reference them with db_register from another package).
<cjwatson> there's debconf-loadtemplate if you really have t
<cjwatson> o
<cjwatson> or you could load the confmodule in your postinst, but do nothing else with debconf
<soren> The latter sounds like a better idea.
<cjwatson> likely, yes
<soren> I guess I eventually will want to actually use debconf in this package too.
<soren> I wonder how the first set of templates got added..
<popey> cjwatson: left comment on the bug
<soren> I guess I must have triggered debconf at some point. I can't imagine how or why, but meh.
<cjwatson> popey: hm, so 1.99-17ubuntu1 worked but 1.99-18ubuntu1 failed?
<cjwatson> (wtf?  I didn't touch partition handling.)
<popey> cjwatson: well, it may have been a day or more between updates on that box. but it is my main desktop, and doesn't get rebooted that often, often suspended
<cjwatson> popey: you said you reinstalled grub to get it back to a bootable state, so presumably you know what version you reinstalled?
<popey> cjwatson: I just did grub-install
<popey> cjwatson: sorry, "grub-install /dev/sdb"
<cjwatson> oh, you were probably misconfigured to start with then.  I left a question in the bug ...
<soren> cjwatson: Fantastic, that did the trick. Thanks!
<popey> cjwatson: sorry, pasted, should have attached.
<cjwatson> no matter
<soren> cjwatson: What if I'm updating an existing template rather than adding a new one? The new ones are in /var/lib/dpkg/info/<my package>.templates, and I do include confmodule in my postinst, but /var/cache/debconf/templates.dat still has the old templates.
<cjwatson> soren: that normally just works
<cjwatson> sorry, not sure what the problem might be in your case
<smb> cjwatson, Just to make sure I understand right: so the multipath udeb would only carry dm-multipath and dm-round-robin ? I am not sure abotu the scsi device handlers. They might be only used for multipath setups but on the other hand are grouped into the scsi subsystem.
<soren> Perhaps it refrains from refreshing because there are multiple owners?
<cjwatson> smb: {dm-multipath,dm-round-robin} -> multipath-modules, scsi device handlers -> scsi-modules sounds o
<cjwatson> ok
<cjwatson> smb: I'm just trying to claw things back into being slightly more in line with Debian because it means less unnecessary divergence in the userspace installer code
<smb> cjwatson, ok thanks. will look to get it done. Less divergence is good and it should not be a really big change, so it makes much sense to get it done right now that there need to be changes anyway
<cjwatson> smb: great, thank you
<cjwatson> soren: I would have expected it to add an owner in the case of any shared templates, and just add any non-shared ones
<soren> cjwatson: *blush*
<soren> cjwatson: I had a copy of the templates file in another package.
<soren> cjwatson: With all the same names.
<soren> cjwatson: So each time I installed that, I'd get the old version.
<soren> cjwatson: And my test-debug cycle included: Install the config-common package -> isntall a package that consumes it -> test.
<soren> cjwatson: So it always overwrote the changed templates.
<cjwatson> whoops
<cjwatson> yeah, easy to make that kind of mistake with shared templates
<soren> cjwatson: Ironically, I'm doing this to *avoid* sharing templates, and just ship them in a single package (and use db_register <common package>/$question <consumer package>/$question). I just copied the templates file over at some point by mistake.
<soren> I never noticed because so far, I've only been *adding* new templates. Added templates got through just fine.
<soren> *headdesk*
<cjwatson> heh
<cjwatson> ah well
<tsdgeos> what's the best way to store a dictionary inside a gvalue?
<tsdgeos> i went the way of gvalue being a variant and the variant being a dictionary
<tsdgeos> sounds ok?
<Riddell> janimo`: yes we use upower in KDE
<slangasek> mvo: I'm not sure I understand the right way to pop up a notification about a package's download failing; from what I can see in the code, /var/lib/update-notifier/user.d/ is only processed when a new file is added there or when the applet starts, is that right?
<slangasek> mvo: in which case it seems I want the script to add/remove a file to that directory, and not use DisplayIf?
<mvo> slangasek: yeah, add it or touch it (to display the notification again)
<slangasek> ok
<smb> cjwatson, Oh, I just remembered something else. I think you at least sponsored some updates to dmraid user-space. I think I found some discrepancy in the initramfs-tools scripts/hooks. Unfortunately lost the bug reporter for now... bug 948291 (comments 37 and 38)...
<ubottu> Launchpad bug 948291 in linux (Ubuntu) "New 12.04 beta Kernel doesn't support booting from dmraid" [Medium,Confirmed] https://launchpad.net/bugs/948291
<smb> (afraid it is a bit in the middle of things... just the difference between output and input seemed like one thing more likely broken...)
<cjwatson> smb: sponsored, but I don't feel confident to make changes on my own initiative
<cjwatson> smb: if you can get hold of psusi, he tends to be useful on this
<smb> cjwatson, Ok, I'll try... Saw his name too
<ricotz> smoser, hi, could you have a look at qemu-kvm which installs /usr/etc/qemu/target-x86_64.conf, i guess this should go to /etc/qemu/target-x86_64.conf
<smoser> ricotz, can you open a bug ?
<ricotz> smoser, i was hoping pinging you might be enough
<smoser> well, i was just going to ping hallyn
<smoser> but ... a bug would still be helpful.
<ricotz> ok
<slangasek> mvo: do you know what creates /var/lib/update-notifier/user.d/firefox-restart-required nowadays?  The only thing I find in the firefox postinst is 'touch /var/run/firefox-restart-required'
<slangasek> mvo: I'm trying to find this to see how they've handled localization so I can copy it
<ricotz> smoser, https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/960359
<ubottu> Launchpad bug 960359 in qemu-kvm (Ubuntu) "config file "target-x86_64.conf" in wrong location" [Undecided,New]
<mvo> slangasek: sorry, I don't know
<mvo> slangasek: maybe the ubufox stuff?
<mvo> slangasek: but chrisccoulson should know
<slangasek> I'll look there, thanks
<smoser> ricotz, gracias
<chrisccoulson> mvo, slangasek, we haven't had that in firefox since lucid
<slangasek> chrisccoulson: hah, ok
<slangasek> chrisccoulson: why did it go away?
<slangasek> (OOI)
<chrisccoulson> slangasek, it was sort-of redundant. we already have the restart notification banner inside firefox, so we just use that rather than relying on update-notifier
<slangasek> fair enough
<slangasek> (though personally, the restart banner drives me crazy ;)
<chrisccoulson> slangasek, it's meant to make you want to restart :)
<chrisccoulson> although, i think i changed the timings this cycle so that it doesn't remind so often
<slangasek> chrisccoulson: it doesn't make me want to do that, it makes me want to swear off web browsing! :)
<chrisccoulson> lol
<slangasek> ah, looks like the french translation is statically encoded here, ah well
<chrisccoulson> slangasek, we might get rid of the restart banner at some point (and turn it in to a notification panel inside firefox instead, which doesn't shift the content down when it appears)
<mdeslaur> slangasek: fyi: #952556
<slangasek> mdeslaur: are you seeing this behavior?
<mdeslaur> slangasek: I haven't checked personally, but it looks like something we should take a look at
<mdeslaur> I'll try it on my test laptop, one sec
<slangasek> mdeslaur: looks like I can reproduce it here
<slangasek> which is strange, because I definitely *didn't* see this earlier in the cycle when making that change
<slangasek> cking: why are you sure bug #952556 isn't a kernel bug?  I don't think this was the behavior in January at the time I changed the hdparm apm_battery setting, and hdparm hasn't changed at all since
<ubottu> Launchpad bug 952556 in hdparm (Ubuntu) "[Precise] [Hardware-killer] HD restarts every few seconds" [High,Confirmed] https://launchpad.net/bugs/952556
<slangasek> so I think something has changed in the kernel
<mdeslaur> slangasek: well, some of the desktop power optimisations may have decreased regular disk activity
<slangasek> yes, that was actually a precondition of me changing hdparm
<mdeslaur> ah! i see
<slangasek> before, the root problem wasn't the spin*down* time, it was the spin *up* frequency
<cking> slangasek, well, it still happens when the user uses an oneiric kernel
<slangasek> cking: ok
<slangasek> that's pretty conclusive then
<cking> and I checked it on an hpmini this afternoon
<slangasek> let me see if something's regressed on the desktop to cause these spin-ups
<cking> I also factored out the pm-utils changes just to sanity check things
<slangasek> so, setting a higher spindown time by default is probably reasonable in any case
<slangasek> and would guard against destroying disks
<slangasek> so I think we'll go ahead with that
<mdeslaur> fwiw, my count increased by 3 in 5 minutes
 * slangasek breaks out fatrace \o/
 * mdeslaur tries fat race too :)
<slangasek> kinda looking like a firefox regression
<slangasek> or possibly a google regression :P
<cking> slangasek, yep I think a higher spindown time is a good solution
 * micahg pops his head up
<doko> is there a known issue with usb disks in the precise kernel? getting now I/O errors with the second usb disk. just do not want to believe that both external disks are damaged
<mdeslaur> wow, fatrace is awesome
<slangasek> mvo: I notice as I'm testing this u-n change that u-n only processes hooks when something touches /var/lib/update-notifier/dpkg-run-stamp.  It seems to me that the two should be somewhat independent?
<ahasenack> SpamapS: ping, around?
<psusi> ok, so multipath-tools has a binary package named multipath-tools-boot that contains the initramfs hook to add multipath-tools and kpartx to the initramfs... dmraid needs kpartx to be in the initramfs.. so, should I add a hook to dmraid to copy the kpartx binary, or split the multipath-tools hook in two, so there is on efor multipath-tools-boot, and one for kpartx?  hrm...
<cjwatson> we generally put the hooks in the package that ships the binary because that means that the initramfs gets updated every time the package that actually ships the binary is updated, which is important
<cjwatson> so maybe in kpartx itself but with something to arrange that it only actually goes in the initramfs when needed?
<psusi> ahh.. hrm.. what would that something be?
<cjwatson> not sure :-)
 * cjwatson handwaves merrily
<ahasenack> hi, quick (I hope) question about bzr merge-upstream, it seems it is bzr deleting all files and then bzr adding all the new files, that's not a merge
<ahasenack> bzr st shows it removing and adding the same file, even though that file didn't change regarding the upstream version
<ahasenack> like, the LICENSE file, it's exactly the same
<psusi> what is it that makes the initramfs update when you upgrade the package anyhow?  does it need to call update-initramfs from its postinst?
<cjwatson> psusi: right, and that ends up activating a trigger
<psusi> hrm... this is odd... multipath-tools-boot has a postinst that runs update-initramfs to process the included hook... the hook checks for the existance of /sbin/multipath-tools and exits if it doesn't exist.  multipath-tools-boot does not depend on multipath-tools... so strangely, you can install it and it effectively does nothing unless you also install multipath-tools
<psusi> I think I'll fix the existing hook so that it just skips the multipath-tools parts if it is not found, but if kpartx is found, will copy that in... then add multipath-tools-boot as a depend of dmraid
<broder> psusi, cjwatson: you could use the initramfs-tools variable thing that plymouth uses to trigger
<broder> so then i think anything that wanted kpartx would ship a file in, uh, /usr/share/initramfs-tools/conf-hooks.d/blah
<cjwatson> broder: thank you for concretifying my handwaving
<mvo> slangasek: sorry for the delay- that is correct, it was designed to not popup in the middle of a upgrade, originally this handled stuff like the reboot required. but indeed, its no longer a valid reason (as reboot-required is done differently these days)
<slangasek> mvo: ok, I'll adjust the code then to process the hooks anyway, thanks
<mvo> thanks
<mvo> for a bit of background, I had hoped we could get rid of update-notifier in favor of upstart user session event scripts, but we are not there yet
<mvo> (it seems at least)
<slangasek> ah :)
<SpamapS> ahasenack: howdy
<ahasenack> SpamapS: \o/
<ahasenack> SpamapS: so I tried a bit bzr merge-upstream, can I make some questions?
<ahasenack> SpamapS: are you on the udd mailing list?
<micahg> https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2012-March/001052.html
<ahasenack> micahg: thanks! :)
<SpamapS> ahasenack: I'm not
<ahasenack> SpamapS: my question is above in the archive link that micahg pasted
<ahasenack> SpamapS: basically, seems like bzr merge-upstream deletes and adds all files again
<ahasenack> regardless if they had changes or not
<SpamapS> ahasenack: hm
<SpamapS> ahasenack: I would not expect it to do that.
<ahasenack> SpamapS: good :)
<SpamapS> ahasenack: I am trying it now.. I've never used the bzr branch with --revision and --version before.. it may work differently
<ahasenack> SpamapS: I tried a few combinations, but got the same result
<micahg> it might be treating it as a bzr branch instead of an upstream tarball, but I'm not sure how the upstream tarball behaviour works TBH
<SpamapS> ahasenack: as micahg is eluding to.. try it that way
<SpamapS> with bzr exported to a tarball
<ahasenack> SpamapS: I think it's what merge-upstream ends up doing, because I saw a tarball in the parent directory
<ahasenack> SpamapS: but let's try
<ahasenack> SpamapS: yeah, now it worked as expected
<ahasenack> SpamapS: http://pastebin.ubuntu.com/892732/
<SpamapS> ahasenack: so, I would suspect that when doing a bzr branch, there is some extra magic being attempted..
<ahasenack> SpamapS: what you did yesterday, was with a tarball?
<ahasenack> SpamapS: and, did you just try with a branch? Did you get the same add/remove outcome as I?
<SpamapS> ahasenack: what I did yesterday was upload a pure source package. The package importer pulled that into ubuntu:landscape-client
<ahasenack> SpamapS: ok, and did you try merge-upstream with a branch just now, just to see if you get the same outcome as I?
<SpamapS> ahasenack: I did, and got the same outcome.
<ahasenack> ok
<ahasenack> looks like we should avoid that for now
<ahasenack> SpamapS: thanks!
<bernie> anyone knows why there have been no new chromium snapshots in the ppa for a couple of months?
<micahg> bernie: various reasons, I'm trying to get it sorted, hopefully by the time precise releases
<bernie> micahg: cool thanks
<rsalveti> ogra_: do you know why the installer slideshow is still broken on arm?
<rsalveti> don't remember if it was simply something we decided to drop, or that wasn't enabled properly after that bug we had with webkit
<rsalveti> I'd like to have it working again as then we can have a similar installer experience as we have for other archs
<rsalveti> let me try to find a bug for it
<rsalveti> ogra_: neither universe nor multiverse is enabled by default
<rsalveti> it's also lacking the deb-src lines as well
<rsalveti> guess a bug at livecd-rootfs
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: TheMuso
<popey> cjwatson: just seen someone else with the same grub issue I had
<popey> cjwatson: https://plus.google.com/u/0/115941496951821782702/posts/1vwCLcQtFY4
<popey> pointed him at the bug report
#ubuntu-devel 2012-03-21
<cjwatson> popey: it's not entirely uncommon, but it's nevertheless a misconfiguration
<cjwatson> popey: I blogged about it a while back, although the specific circumstances were different - http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-06-21-grub2-boot-problems.html
<TheMuso> infinity: Does the debdiff in this bug look sane to you? Looks ok to me, but a second opinion from someone with livecd-rootfs experience would be nice. I'm happy to handle the bzr update and upload. https://launchpad.net/bugs/960688
<ubottu> Launchpad bug 960688 in livecd-rootfs (Ubuntu) "Slideshow not enabled by default at the pre-installed images" [Undecided,New]
<TheMuso> Asking you too because of your ARM work for livefs/pre-installed image stuff.
<TheMuso> Or anybody else who has worked on the livefs stuff, opinions welcome.
<infinity> TheMuso: Looking.
<TheMuso> Thanks,.
<infinity> TheMuso: The fix doesn't belong in livecd-rootfs, IMO.  I already fixed this once last cycle, something's gone wrong.
 * infinity tries to remember what was wrong last time.
<TheMuso> infinity: Ok, I suspected that this should be fixed elsewhere, thanks for confirming.
<infinity> TheMuso: Oh, maybe I fixed it last cycle by making oem-config just use the regular slideshow, and someone unfixed that.  *trying to recall*
<infinity>   * Allow fallback from oem-config-slideshow to ubiquity-slideshow for
<infinity>     cases where the former doesn't exist.
 * infinity looks.
<infinity> TheMuso: Cause, in the ARM case, we don't actually want the oem-config slideshow, it's not an OEM install.
<TheMuso> Right.
<TheMuso> So its not a bug.
<infinity> TheMuso: Well, it's a bug if the slideshow's not showing at all.
<TheMuso> Right.
<TheMuso> rsalveti: See above re your bug about the slideshow on arm pre-installed images.
<infinity> TheMuso: Oh, I think stgraber may have broken this yesterday.  In a patch I reviewed.  That's embarassing.
<TheMuso> heh ok. :)
<infinity> Or not...
 * infinity scratches his head.
<rsalveti> infinity: slideshow is not showing at all
<infinity> rsalveti: There's really no slideshow on ARM right now?
<infinity> Jinx.
<rsalveti> and there's not any oem specific thing at this slideshow
<rsalveti> it's provided by ubiquity any way
<infinity> rsalveti: It's mean to possibly have OEM-specific stuff, hence the fallback.
<rsalveti> it's just enabled by default because the package is not isntalled by default at the pre-installed images
<infinity> rsalveti: (I realise it mostly doesn't right now)
<rsalveti> I just added both because during natty I believe we were using them
<infinity> rsalveti: Trust me, this used to work properly not long ago, oem-config-slideshow* doesn't need to be there.
<rsalveti> on oneiric I don't remember what happened
<infinity> On oneiric, it uses ubiquity-slideshow.
<infinity> Or are you saying that's not being installed either?
<infinity> Cause that would be a seed issue.
<rsalveti> infinity: yup, not even installed
<infinity> It's in the live seed...
<rsalveti> as livecd-rootfs requests oem-installer during the config step, I just added the slide show there
<rsalveti> but as I said at the bug, might not be the right place, just don't know what would be the right one
<rsalveti> don't know if it should be part of the live seed
<infinity> S'ok, I'll sort it out.
<infinity> It *is* in the live seed.
<infinity> Something's gone pear-shaped.
<rsalveti> hm, so another issue then
<infinity> ubiquity-slideshow, that is.
<rsalveti> hm, it might be the case that ubiquity-slideshow is installed
<TheMuso> Thanks guys, can now move onto pilotting other stuff. :)
<rsalveti> let me check it again
<rsalveti> O ubiquity-slideshow-ubuntu
<infinity> rsalveti: If it is, then it should work, but I can see if we broke it.
<rsalveti> I'm sure ubiquity-slideshow-ubuntu is not
<rsalveti> infinity: shouldn't we also install  ubiquity-slideshow-ubuntu or  ubiquity-slideshow-kubuntu?
<rsalveti> depending on the flavor?
<infinity> The live seeds take care of that.
<rsalveti> seems this package is what is really providing the slideshow in the end
 * infinity curses livefs-build-log mirroring being broken again.
<infinity> rsalveti: Anyhow.  Yes, I absolutely agree that it should be installed, no, I'm not sure why it isn't, yes, I'll sort it.
<infinity> rsalveti: And no, oem-config-slideshow shouldn't be. ;)
<rsalveti> infinity: perfect :-)
<rsalveti> it was in the past, that why I got confused :-)
<infinity> apt-cadconrad@shiva:~$ apt-cache show ubiquity-slideshow-ubuntu | grep ^Task
<infinity> Task: ubuntu-live, ubuntu-usb-live, edubuntu-usb-live, ubuntustudio-dvd-live
<infinity> ^-- It clearly should be.
<infinity> rsalveti: You're dead positive it's not?
<infinity> I kinda don't want to wipe my Panda to test. :P
<infinity> (But I suspect I might have to)
<rsalveti> infinity: http://paste.ubuntu.com/893117/
<infinity> Bizarre.
<rsalveti> this is with the latest daily image
<rsalveti> for omap4
<infinity> Yeahp, I'll hunt it down.
<infinity> rsalveti: Although, we haven't had a successful image for two days, maybe it was transient.
<rsalveti> infinity: got from http://cdimage.ubuntu.com/daily-preinstalled/20120320.1/
<rsalveti> don't know if it's just a copy of an older image
<infinity> rsalveti: It's just a copy of an older one. :P
<rsalveti> or the latest one generated today
<infinity> Looks like we have issues thanks to clutter...
<rsalveti> great
<rsalveti> hahah
<rsalveti> I really think we shouldn't be copying older images to show as the current one when it fails :-)
<infinity> rsalveti: Want to fix the ARM clutter-gst FTBFS?
<rsalveti> infinity: is that the one blocking the images?
<infinity> rsalveti: Looks like.
<infinity> rsalveti: clutter-gst -> empathy -> sad panda.
<rsalveti> infinity: ok, let me check
<rsalveti> infinity: where can I find the image build logs
<rsalveti> ?
<rsalveti> don't know if it changed again
<infinity> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/
<rsalveti> great, thanks
 * infinity does some local testing to see if he can reproduce the "no slideshow" thing anyway.
<infinity> ubiquity-slideshow-ubuntu definitely gets pulled in with ubuntu-live^ here.
<infinity> So, I think I'll have to wait for the images to be buildable again and do an end-to-end test.
<rsalveti> yeah
 * infinity assigns your bug to me, so no one else tries to fix it. :P
<infinity> Man.  I ignore the FTBFS list for a week, and everything goes to crap.
<infinity> 7 packages...
<infinity> slangasek: You around?
<rsalveti> infinity: clutter-gst seems to be related with opengles, will check the bug
<jk-> infinity: able to test a patch, backported to stable branch 2.6.27.y?
<infinity> jk-: If 2.6.27 can boot a precise userspace without exploding, sure.
<infinity> jk-: My G3's not wildly flexible on what sort of testing I can do. :P
<jk-> oh, btw, the yacht club called, they want their boat anchor back
<infinity> jk-: What are you testing?  Just backporting that SMP-on-old-cores fix through the ages?
<jk-> yeah, sending a fix for the 2.6.27.y longterm stable branch, and would like to test it first
<infinity> 2.6.27 isn't dead upstream yet?
<jk-> (there has been a slight change to powerpc/smp.c, so I needed to rework the fix)
<jk-> it's still being maintained in stable
<infinity> Oh, it was 2.6.32 that Greg KH recently announced he was washing his hands of.
<infinity> I'm getting my ancient kernels confused.
<jk-> last commit to .32 was on the 17th
<infinity> Although, there's some hefty sarcasm with .27 releases...
<infinity> "Linux 2.6.27.61 is out for those of you who feel that 2.6.32 is too new and "fancy" for your needs."
<jk-> infinity: might be a good match for your machine then? :D
<infinity> jk-: *glare*
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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:
<micahg> infinity: both 2.6.27 and 2.6.32 are now maintained by the old-stable kernel maintainer and had releases last week: http://lwn.net/Articles/487020/rss
<Bluefoxicy> ugh how do I even search for a bug for this
<Bluefoxicy> ok so in precise, stupid alt+gr key failed, I don't even know what this is
<Bluefoxicy> my right alt was  level 3 shift (graves, umlaut, etc) and my right meta windows key was compose (grossen, ae, etc) and now they're just normal and the configuration options have disappeared :|
<Bluefoxicy> I can't tell if bug #781100 is this or not
<ubottu> Launchpad bug 781100 in unity (Ubuntu) "Unity overrides compose key setting" [Undecided,Confirmed] https://launchpad.net/bugs/781100
<infinity> Bluefoxicy: Try setting them in /etc/default/keyboard?
<infinity> Bluefoxicy: (for instance, I have XKBOPTIONS="compose:menu" for my compose)
<Bluefoxicy> infinity: this is not a regression?  Not being able to set compose/altgr in keyboard settings?
<ScottK> Unity's key layout conflicts with other things too.  Bug #940562
<ubottu> Launchpad bug 940562 in unity (Ubuntu) "Global hotkeys of amarok for rating conflict with Unity (Meta-1 to Meta-5) " [Undecided,New] https://launchpad.net/bugs/940562
<infinity> Bluefoxicy: To be fair, I've never tried.  Heck, I just now found the GUI settings. :P
<infinity> Bluefoxicy: The options aren't gone, just remarkably well hidden.
<infinity> Bluefoxicy: Settings -> Keyboard, see "Layout Settings" on the bottom left, then select your variant, and click Options.
<Bluefoxicy> infinity:  aha.  Finally.  it used to be a separate tab.  hmm mine are checked, lemme uncheck and recheck ... ÃÃ«Ã«Ã©Ã¼
<Bluefoxicy> Qa'pla!
<Bluefoxicy> k then I won't file a bug for this.
<infinity> Bluefoxicy: The fact that yours were checked but didn't work may still be some curious gconf->gsettings migration issue or something, but it would be a more generic GNOME bug on whatever provides that dialog, not a unity bug.
<infinity> (gnome-keyboard-settings, or something equally creatively named, I'd imagine)
<infinity> Though, I'm not sure how committed we are to migrating user desktop tweaks completely, as opposed to just having a functional machine after upgrade.  You'd have to ask the desktop guys.
<slangasek> infinity: mmmmnope
<infinity> slangasek: Apparently not. ;)
<infinity> slangasek: There was mention that the whole "Waiting for network config" business may relate to "broken" interfaces files.  Well, mine's not broken, since it clearly does the right thing for me, but perhaps you can look at it and see if something might consider it broken? :P
<slangasek> infinity: sure :)
<infinity> slangasek: http://paste.ubuntu.com/893202/
<slangasek> infinity: and all of those interfaces are present and working?
<infinity> slangasek: Perhaps something's a sad panda about eth1 and wlan0 not being explicitly configured?
<slangasek> not at all
<infinity> slangasek: Yes, they all are present and functional.
<slangasek> infinity: ls -l /run/network, please
<infinity> -rw-r--r-- 1 root root 34 Mar 20 01:07 ifstate
<infinity> -rw-r--r-- 1 root root  0 Mar 20 08:05 ifup.br0
<infinity> -rw-r--r-- 1 root root  0 Mar 20 08:05 ifup.eth0
<infinity> -rw-r--r-- 1 root root  0 Mar 20 08:05 ifup.lo
<infinity> -rw-r--r-- 1 root root  0 Mar 20 01:07 ifup.tun0
<infinity> I'm guessing ntpdate happened in there somewhere, given the 7 hour skew. :P
<slangasek> heh
<slangasek> infinity: missing is the /run/network/static-network-up-emitted directory; maybe you can see why /etc/network/if-up.d/upstart would have failed to consider all interfaces up if all four interfaces are up?
<infinity> slangasek: Oh, the directory is there, I just omitted it from the paste.
<slangasek> oh
<infinity> I figured you wanted the timestamps on interfaces, my bad. :P
<infinity> (It's also 1:07)
<slangasek> in that case, /etc/init/failsafe.conf should have cleared the screen post haste
<slangasek> oh wait
<slangasek> this is that other race condition I spotted the other day
<infinity> Well, note the (if we assume it's a timezone shift) 2 minute difference between the first 3 interfaces and the last.
<slangasek> the order of events you're seeing is 'net-device-up IFACE=lo'; 'static-network-up'; 'filesystem'
<infinity> Given that I live in -7, it seems likely it's just a timezone shift.
<slangasek> so failsafe isn't yet started when 2) happens, so isn't stopped
<slangasek> so when 3) happens, it's started
<infinity> It makes sense as a race, I only see it about half the time.
<infinity> Maybe more than half, I haven't rebooted enough to confirm.  But "often enough".
<slangasek> complicated filesystem setup on this machine?
<infinity> Nope.  Just root.
<infinity> slangasek: There is, however, the udev storm. ;)
<slangasek> ah
<slangasek> oh, wait
<infinity> slangasek: So, that could be causing serious delays.
<slangasek> 2 minutes fits perfectly; you have an 'auto' network device that's not event-drive
<slangasek> +n
<slangasek> tun0
<slangasek> hmm, or does it
<infinity> How else does one auto a virtual iface?
<slangasek> no, that's the right way to do it, I was just getting ahead of myself in the diagnosis
<slangasek> however, udev is implicated in /etc/init/networking.conf
<slangasek> so your udev storm could actually play a part
<infinity> It could indeed cause some delays, but I'm not sure why that should then trigger a script that forces me to twiddle my thumbs. ;)
<infinity> There must be a saner way.
<infinity> Unless I really am not getting my interfaces for two minutes...
<slangasek> it does what it does to prevent accidentally trying to start network services before the network is up; and upstart doesn't know any better definition of "up" than "all 'auto' interfaces in /e/n/i present and accounted for"
<infinity> I just find the 2 minutes between the last two interfaces, both of which are virtual, kinda odd.
<infinity> I suppose hostapd could be choking for 2 minutes?
<slangasek> no
<slangasek> the br0 interface is brought up immediately because you have bridge_ports configured correctly :)
<infinity> Gah, it still drives me nuts that lightdm doesn't write to wtmp/utmp.
<infinity> 0 users, my ass...
<slangasek> (/lib/udev/rules.d/40-bridge-network-interface.rules)
<infinity> slangasek: Well, when I'm bored, I can throttle scsi_id/ata_id, or unplug the zip drive, and do a bunch of reboots.
<infinity> slangasek: If taking out the udev storm fixes this too, fair enough.
<infinity> Though I didn't start seeing this until quite recently, while the udev storm's been around longer.  That's all kinda wishy-washy, though, the machine's only rebooted on kernel updates.
<slangasek> yeah, I don't know why it would've regressed recently
<slangasek> you could try booting with --verbose and get a look at the timing / ordering of the upstart jobs
<jalcine> Which would be better for spellcheck? hunspell or aspell?
<infinity> jalcine: Or myspell!
<jalcine> oi, the options, lol.
<slangasek> jalcine: are you asking about which you should integrate in a program, or which you should use yourself?
<infinity> jalcine: hunspell's probably the most feature-rich, libaspell has a nice API and is blindingly fast.
<jalcine> the former, slangasek
<infinity> And I don't know much about myspell.
<jalcine> Well, I just need to spellcheck a few words for a dictation application of mine.
<slangasek> hunspell is the best for localized spellcheck support
<jalcine> that's a deal closer.
<jalcine> Thanks :)
<slangasek> the others tend to assume languages that work like English
<infinity> So, English?
<slangasek> infinity: they can cope with most European languages... just not Hungarian, Basque, and Finnish ;)
<infinity> I can't cope with Hungarian either, and I spent 5 years trying.
<infinity> I can curse quite convincingly, though.
<infinity> (My ex-wife's grandmother wasn't exactly lady-like)
<jalcine> Heh
<infinity> slangasek: Oh, booting with --verbose would require being able to type "e", wouldn't it?
<infinity> slangasek: That's right out unless I buy a new keyboard. ;)
 * slangasek squints
<slangasek> or modify the boot args over the network? :)
<infinity> The array of keys from 2 to 4 down to x through v don't work. :P
<infinity> slangasek: BootX, I haven't sorted out how the heck I can modify it's config from Linux.
<broder> infinity: so...you couldn't type...4/7 of the characters in verbose?
<infinity> slangasek: I have a feeling it requires some sort of resource editor.
<broder> wait, 5!
<slangasek> infinity: ah right, I forgot about that bit of masochism
<infinity> slangasek: Works great, as long as I just close my eyes and La la la about using MacOS as the world's most bloated bootloader.
<infinity> But yeah, anyone have an old ADB keyboard with all the keys working? ;)
<slangasek> I might :P
<infinity> Every kernel upgrade on that machine is a small anxiety attack due to the complete inability to use the console. :P
<slangasek> not that I've tried it in a while
<infinity> It might just need me to unscrew it and clean it, I suppose.
<infinity> Or could be a cold solder connection.
<infinity> The machine already has a PSU being held together with electrical tape, may as well get dirtier.
<infinity> (And, entertainingly, it's still the most stable computer I own)
<jalcine> And hunspell comes with an example, let's go :)
<jalcine> Thanks guys, again.
<infinity> slangasek: I commend you, by the way, for not making any snide comments about that tunnel's use.
<slangasek> you can safely assume I didn't parse it fully ;)
<jalcine> Kind of wish everything had a CMake module.
<jalcine> Hence my writing one if I don't find one :)
<pitti> Good morning
<sladen> morgan
<sladen> und morgen
<chilicui1> hi there, is anyone from here part of the sru team?, I'll like someone could nominate bug #953753 for oneiric
<ubottu> Launchpad bug 953753 in klavaro (Ubuntu) "Klavaro is not completely translated even when the .po is completely translated" [Undecided,Fix released] https://launchpad.net/bugs/953753
<micahg> actually need someone from the SRU team to say if it's SRU acceptable
<pitti> chilicui1: I added an oneiric task; seems ok for an SRU
<chilicui1> pitti: nice, so then, can I now suscribe the sru team?, or u'll take care of it?, sry, it's my first sru
<pitti> chilicui1: no, someone needs to prepare a patch and upload it, then we'll review it
<micahg> pitti: there's a patch attached, I wasn't sure about the size/type of it, hence i suggested asking you
<chilicui1> I've attached a patch for oneiric in the report
<pitti> ah, I subscribed sponsors
<chilicui1> ok, great, thanks a lot =)
<ricotz> infinity, hello
<ricotz> infinity, is it possible to restart https://launchpad.net/~ricotz/+archive/ppa/+build/3302242 ?
<micahg> ricotz: cancelled PPA builds cannot be restarted
<ricotz> micahg, yeah, you said so some time ago, i was hoping there is still some way
<micahg> #launchpad would be more appropriate, but I think you'll get the same answer
<ricotz> micahg, ok
<dholbach> good morning
<jdthoodEtrawsfyn> Someone filed a bug which turns out to be a duplicate of #349469.  Looking at the latter I see that it has 413 duplicates dating back to 2007... and only Importance: Medium! Hmm.
<cjwatson> jdthoodEtrawsfyn: that bug is really a symptom of something else, not a debconf bug - either user error in attempting to run multiple debconf frontends at once for the same database, or programming error in trying to do the same
<cjwatson> so sure, lots of dups, which is because it's a single symptom of likely multiple causes that are very difficult to untangle
<cjwatson> it would be more productive to help untangle it than to comment about the importance!
<dholbach> DMB members: somebody pinged me and said the wiki agenda and dates had not been updated yet and wanted to make sure his application was on there - can somebody go and update the wiki? then I'll get back to him
<jdthoodEtrawsfyn> cjwatson: I intend to help, despite the fact that the importance setting initially suggests to me that the bug isn't highly important.  ;)
<jdthoodEtrawsfyn> Anything with 413 dupes is causing a LOT of irritation out there.
<cjwatson> But it's very likely not in fact a single problem with 414 occurrences.
<cjwatson> It's sort of like a bug saying "my compiler exited non-zero". :-)
<cjwatson> So it's misleading to treat it as 414 reports of something that's definitely all the same problem.
<soren> I'd be surprised if it were really more than 2-3 different problems, though. It seems likely that there are only a few things in that common use that uses debconf and doesn't close its handle properly.
<Daviey> Wouldn't there be 1000's since *2007* if it was systematic.. Clearly there is something which differentiates these people..
<Daviey>  .. i've hit that bug, but i think it was my own fault.
<soren> Since dpkg isn't also locked, it has to be something that uses debconf outside of maintainer scripts. Doesn't it?
<Daviey> nice!
<jdthoodEtrawsfyn> I am able to reproduce the bug: "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable"
<soren> Hm... I guess unless you call db_stop, but some daemon didn't close its fd's (one of which it might have inherited from debconf) on start.
<soren> jdthoodEtrawsfyn: Cool. Can you tell which other process has it open?
<soren> jdthoodEtrawsfyn: PErhaps do a "ps -efl" and pastebin the result.
<Daviey> soren: I think next cycle, consider porting debconf into gconf :)
<jdthoodEtrawsfyn> Method of reproducing: while : ; do dpkg-reconfigure <package-that-calls-debconf> ; done & update-manager # Then agree to Install Updates
<soren> Hm... Doesn't dpkg-reconfigure lock the dpkg database? I guess it might not.
<soren> Nope, it doesn't.
<soren> I just kind of doubt that's the problem we're seeing here. One of those hundreds of people would have thought of mentioning that they were running "dpkg-reconfigure" in another terminal.
<soren> Otherwise, I've just lost a bit more faith in human kind.
<Daviey> particularly running it in a while true loop :)
<soren> I don't see why that's necessary.
<soren> I just ran it, and left it with an open prompt.
<soren> That'd do it.
<jdthoodEtrawsfyn> soren: dpkg-reconfigure was just my way of ensuring that debconf was being called at the moment update-manager started to Install Updates. If someone does "apt-get upgrade" then many debconf calls will result. If update-manager spontaneously starts while that is happening...
<soren> I've you're savvy enough that you know dpkg-reconfigure exists, there's a fair chance you'd know to mention it in a bug report that complains about a locked debconf db.
<soren> jdthoodEtrawsfyn: That shouldn't matter. apt-get upgrade will have locked other tihngs that update-manager will complain about (or step back from) way before we reach debconf land.
 * soren looks at "jdthoodEtrawsfyn" and finds renewed gratitude for tab completion
<jdthoodEtrawsfyn> (Not to be confused with jdthoodPtriffid which is jdthood logged in from triffid using Pidgin.)
<apw> pitti, hey ... on blueprints there are now a new 'work items' box, is that in the same format as the old ?  and doe we stilll look in both?
<pitti> apw: new LP feature; yes, it's the same format
<pitti> apw: WI tracker looks in both
<pitti> apw: we'll use whiteboard for precise (no reaason to change them all), and the new one for Q
<apw> pitti, ok so we can ignore it for now and use the new one in Q, but if you do use the new one now it will work just fine too ... right?
<pitti> apw: it should, yes; I haven't tested it
<apw> pitti, thanks :)
<bryceh> apw, the work items box is a new feature developed by linaro; but we're not switching to it until uds.
<apw> bryceh, yep, i see it does validation, nice
<jdthoodEtrawsfyn> soren: In one of the dupes (#380491) the submitter says that running tasksel (not as root) simultaneously with "dpkg --configure --pending" (as root) results in the error message.
<jdthoodEtrawsfyn> Do we now conclude that both dpkg-reconfigure and tasksel have bugs?
<jdthoodEtrawsfyn> ... different bugs, that is ... and that #380491 should be de-duped and reassigned to tasksel and I should file a new report against dpkg-reconfigure?
<seb128> ev, hi, bug #960757 is high on the retracers list, you might want to have a look
<ubottu> Launchpad bug 960757 in whoopsie-daisy (Ubuntu) "whoopsie crashed with SIGSEGV in g_object_newv()" [Medium,Confirmed] https://launchpad.net/bugs/960757
<soren> jdthoodEtrawsfyn: I'm not sure what the bug would be in that case.
<soren> jdthoodEtrawsfyn: tasksel uses debconf.
<soren> jdthoodEtrawsfyn: So does lots of packages' maintainer scripts.
<soren> jdthoodEtrawsfyn: If you try to use both at the same time, you'll get locking issues.
<soren> jdthoodEtrawsfyn: This is not a bug. This is expected behaviour.
<jdthoodEtrawsfyn> 414 people didn't expect it, so there's still a problem.
<soren> You don't know that 414 people were running tasksel.
<soren> And even if they were: The problem might be their expectations. Not a bug in the software.
<soren> Two people can't drive the same car at the same time. That doesn't mean the car is broken.
<jdthoodEtrawsfyn> It looks as if they were all doing two things at once, both of which tried to run debconf. In many cases one of the things was update-manager starting spontaneously, so it's possibly not all cases of user stupidity.
<soren> If they are actively using two things that use debconf at the same time, this is what will happen.
<soren> Now, if something has used debconf earlier and for some reason still keeps a handle open, *that
<soren> 's* ab ug.
<soren> a bug, even.
<soren> ...and at least one of those bug reports seems to be something along those lines.
<Daviey> soren: Your analogy fails, If i'm driving a car.. and you try to drive it, the 'lock' is my slap in your face. :)
<soren> Daviey: I'd say that's a perfect analogy :)
<soren> At any rate, you won't pull over and start scratching your head wondering "what the heck is wrong with this car since we can't both drive it at the same time?"
<soren> That would be fun, though.
<nigelb> 9/ws 24
<ivoks> cjwatson: hi; any chance to talk to you for 5-10 minutes? it's about images built with live-build
<apw> cjwatson, the latest precice kernel contains those dm changes you requested, thats poped it into new
<apw> (the new udeb)
<Kaleo> hey guys, who are the patch pilots?
<gema> soren: if 414 users reported a problem and their expectations are wrong, then the problem is in the documentation, isn't it? the expectations need to be reset. Since applications are expected to run concurrently on modern pcs, and they don't know about the internals of the implementation, their assumption is correct, our documentation is wrong
<tumbleweed> Kaleo: none right now. But any ubuntu developer who wants to do it, can
<Kaleo> tumbleweed: ok, thanks
<soren> gema: For all we know, only 1 person is doing anything wrong (and has wrong expectations).
<soren> gema: The remaining 413 might be seeing an actual bug.
<gema> soren: ahh, ok, I misread you , then
<soren> gema: Or there might actually be 414 all doing it wrong and having wrong expectations. We just don't know. :)
<gema> soren: ack, it'd be good if we could follow up with some of them on how to reproduce
<gema> soren: if they can actually reproduce it
<vibhav> .
<jdthoodEtrawsfyn> cjwatson: OK, I've posted my findings to #349469.
<nigelb> 	/ws 24
<astraljava> cjwatson: Hi there! Thanks for taking care of US's casper/jackd2 problem! However, I'm a little puzzled how you came to that conclusion. I'm trying to install yesterday's image, and it hangs, as it should since the fix didn't make it into those, but I don't see any mention of jackd2 in any casper-related logs. Only "/usr/bin/casper-reconfigure: package 'gnome-power-manager' is not installed"
<astraljava> cjwatson: So my question really is, how do you debug these ubiquity hanging issues?
<cjwatson> ivoks: please just ask your question ...
<cjwatson> astraljava: I used 'ubiquity --debug' as a general "more debug output" thing, checked what processes were running when it hung, and eventually resorted to strace for the detailed work
<cjwatson> IIRC --debug was enough to show the general location of the hang
<ev> seb128: indeed, I'm on it this morning.
<ev> thanks for the heads up
<seb128> ev, yw
<ev> err where this morning is the US/Eastern timezone that Foundations is working in today
<seb128> ;-)
<cjwatson> astraljava: I can't give you a general "how to debug everything" guide, though, since debugging is a creative process
<ivoks> cjwatson: sorry about that; i've managed to build iso-hybrid image, image boots, syslinux kicks in, but then it complains that it can't load kernel; i get the same result with lubuntu (from livecd-rootfs) and lp:~ivoks/cloud-live/precise
<ivoks> cjwatson: but the kernel is there; everything looks good
<ivoks> cjwatson: one thing i've noticed is that lb_binary_disk assumes LB_INITRAMFS_COMPRESSION is gzip and uses zcat when creating initramfs, while it might be lzma
<ivoks> s/creating/extracting
<cjwatson> sounds plausible, could you prepare a patch?
<ivoks> yes
<cjwatson> also in general try comparing piece by piece against the official images
<ivoks> i would love to do that; i just don't know where official images are :)
<ivoks> not images by it self, but rather config/ generated by lb
<cjwatson> the configuration is in livecd-rootfs
<cjwatson> (ignore the legacy livecd.sh there)
<ivoks> maybe i'm using it wrong, but i used /usr/share/livecd-rootfs/live-build/auto/config for config
<ivoks> of course, i export project and arch before building
<ivoks> i've only tried building lubuntu and that failed
<ivoks> well, build finished; kernel couldn't boot
<cjwatson> then download the lubuntu image from cdimage.ubuntu.com and compare your self-built image with that to see what's different
<ivoks> yeah, that's my next step
<ivoks> cjwatson: thank you for your time!
<ogra_> rsalveti, universe and multiverse should be enabled by jasper, the slideshow i thought was fixed by a patch from infinity a while ago, i must admit i didnt check
<ivoks> cjwatson: that gzip/lzma issue is already fixed in lp:live-build (commits 1940 and 2105)
<cjwatson> ivoks: ok, please raise a bug in Ubuntu and assign to me, to backport that
<ivoks> cjwatson: i've reported it, but LP doesn't allow me to assign it to you (bug 961166)
<ubottu> Launchpad bug 961166 in live-build (Ubuntu) "lb_binary_disk doesn't check compression of the initramfs" [Undecided,New] https://launchpad.net/bugs/961166
<cjwatson> ivoks: I've done so, thanks
<astraljava> cjwatson: Yeah, that'll do, thanks! I don't need to load everything in at once. Thanks a bunch! :)
<ivoks> cjwatson: i found why it doesn't work; another bug in live-build in ubuntu; syslinux doesn't like long filenames for initrd and vmlinuz (commit 2100 in live-build); renaming them tu initrd.lz and vmlinuz makes wonders :)
<ivoks> cjwatson: it does make me wonder how we build ubuntu images at all atm :)
<cjwatson> ivoks: they're called initrd.lz and vmlinuz in our images.  perhaps you aren't using livecd-rootfs' auto/build script
<ivoks> cjwatson: i am not
<cjwatson> though I forget how the renaming to initrd.lz works for us
<cjwatson> that's odd, but I'll have to defer looking at this for today
<ivoks> at least i know where to go from
<ivoks> thanks for the help and guidance
<seb128> ev, why did you "also affect glib" on that whoopsie bug? adding a comment explaining why you reassign a bug would be welcome
<ev> on first blush it looks like a bug in the gnetworkmonitor code
<ev> but sure
<seb128> ev, oh, isn't that code in glib-networking and not glib?
<seb128> hum, maybe not
<seb128> ev, I can ask desrt to have a look if you think it's a gio issue
<ev> by all means
<ev> I haven't completely ruled out it being my fault
<ev> but I wouldn't mind another set of eyes on it, especially as I cannot reproduce it locally yet
<ev> but https://launchpadlibrarian.net/97677128/Stacktrace.txt looks like it's happening entirely within glib
<ev> so unless I'm corrupting memory, I suspect it's a bug there
<ev> oh and cheers :)
<seb128> ev, desrt looked at it and said
<seb128> <desrt> seb128: my verdict here is memory corruption
<seb128>  seb128: g_slice_alloc() is returning some bullshit
<ev> seb128: cheers
<seb128> yw ;-)
<hrw> seb128: checked ubuntu-meta/amd64 for missing -dbgsym packages - only 21 entries found and few interesting questions
<jbicha_> sladen: ping
<sladen> jbicha_: yus
<jbicha_> sladen: do you know when the default precise wallpaper will land?
<jbicha_> or we could just keep the oneiric wallpaper ;)
<sladen> jbicha_: ah, man, what happened, everyone has been asking in the last five minutes
<jbicha_> sladen: that's probably my fault, I wanted it for screenshots for ubuntu-docs
<sladen> jbicha_: if it does change it will be a subtle incremental change a la bug #741253 and bug #833990 before  (It's an LTS, so nothing drastic)
<ubottu> Launchpad bug 741253 in ubuntu-wallpapers (Ubuntu) "Incremental tweaks to the default wallpaper for Ubuntu 11.04" [Undecided,Fix released] https://launchpad.net/bugs/741253
<ubottu> Launchpad bug 833990 in ubuntu-wallpapers (Ubuntu) "UIFe: Incremental tweaks to default wallpaper for Ubuntu 11.10" [Medium,Fix released] https://launchpad.net/bugs/833990
<sladen> jbicha_: yeah, it will likely be subtle enough that unless it's actually a full-screen shot of the desktop it probably won't/shouldn't be noticable
<jbicha_> it peaks through all of the Dash screenshots
<jbicha_> I'm counting 5 screenshots in the bzr tree that show pretty much fullscreen of the wallpaper
<sladen> jbicha_: I think Otto has been playing with a tweaking of the blue on one side, I guess the thing for the moment would be to highlight + itemise those
<sladen> jbicha_: and we can stick those on the bug report so they get remade (if required) (if it happens)
<sladen> major wallpaper change will probably be the next cycle as it builds up from scratch to another LTS
<jbicha_> well I'd rather not redo the screenshots, could he really try to get it finalized this week?
<sladen> jbicha_: hopefully the contest wallpapers should land at some point this week, and it would make sense to have them all go up together
<sladen> jbicha_: (whether using the old packaging or your new packaging)
<jbicha_> sladen: thank you
<adam_g> ScottK: ping
<adam_g> ScottK: disregard. :)
<ScottK> OK
<adam_g> any archive admins around? theres a nova upload sitting in https://launchpad.net/ubuntu/precise/+queue with a new binary package. is there anything i can do to help nudge this along? the new package (nova-consoleauth) contains just a script previously packaged in 'nova-console' plus a manpage and an upstart job
<PaoloRotolo> Hi all!
<cjwatson> hrw: uh - "none of them is using debhelper", but your list includes pcmciautils, which definitely does use debhelper (in fact, it uses dh)
<cjwatson> ah, the problem is that the upstream build system calls strip
<smoser> wondering if anyone here has thoughts...
<smoser> bug 961226
<ubottu> Launchpad bug 961226 in cloud-init (Ubuntu) "cloud-init should run resize2fs in the background" [Undecided,New] https://launchpad.net/bugs/961226
<smoser> right now, cloud-init runs a 'resize2fs' early in boot and blocks on it.
<smoser> that patch bug suggests I dont need to block on it.
<smoser> I dont have to, as ext3/4 suport online fs resize up.
<smoser> but *should* i anyway. its one thing to support it, its another to do it under intense (first boot) disk io
<smoser> slangasek, jodh ^ ?
<slangasek> hmm
<slangasek> is this being run from the initramfs?
<smoser> no. this is part of the live filesystem.
<broder> smoser: i've definitely done online ext3 resize while actively using my computer, though it probably wasn't quite as i/o intensive as first boot
<mfisch> anyone know how to fix this (when I open a new terminal): *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
<mfisch> also, don't update *vte* today
<smoser> broder, oh yeah, it definitely works.
<smoser> and i would generally consider fs (and fs-tool) developers to be conservative
<smoser> so i trust its good.
<smoser> good to not lose data
<smoser> but i suspect its possible that during boot it might be (at least sometimes) better to just block on it.
<smoser> or maybe i'm just making up non-sense.
<broder> smoser: the rest of the boot process with cloud-init does things like install packages, right? what are the chances that that step's success is dependent on having the full disk space available to it?
<smoser> well, it could install package, so yes, you have to assume it is.
<smoser> broder, yeah, that is possible i guesss, but i bet realistically unlikely
<smoser> ie, you'd be literally racing to fill up the disk before e2fs resize would grow it.
<broder> right, or alternatively if people assume that they can start to shove data into the instance once the boot is finished
<smoser> it seems like i should at lesat allow config option of turning it off.
<broder> i wonder if it's better to block the rest of cloud-init from running, but not the rest of the boot (i.e. sshd would come up, but the cloud-init scripts wouldn't). but my experience has generally been that if you give people bad semantics they will fail to try to understand them
<broder> (c.f. the rails attr_accessible thing)
<smoser> broder, i've come to the conclusion of running it blocking by default.
<smoser> and allowing user to non-block in config (user-data or system config)
<ahasenack> SpamapS: hi, around? Can you sponsor another ladnscape-client upload? bugfix only
<ahasenack> hi, can somebody sponsor an upload of mine? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/961131
<ubottu> Launchpad bug 961131 in landscape-client (Ubuntu) "Update landscape-client to 12.04.1" [Undecided,New]
<ahasenack> it's bug fix only
<ahasenack> SpamapS: hi, around? Can you sponsor another ladnscape-client upload? bugfix only
<infinity> jbicha_: Disappearing symbols in clutter seems ungood...
<jbicha_> infinity: http://git.gnome.org/browse/clutter/commit/?id=4da1c3efb8fcea58854
<infinity> jbicha_: That doesn't seem to relate to the dropping of all the clutter_gdk symbols?
<jbicha_> infinity: ah, you're talking about the ftbfs instead
<infinity> Aye.
<infinity> Though dropping any symbols in a stable SOVER is bad, if there were others you already fudged. :P
<jbicha_> crazy part is it built locally fine, I think it just needs a configure flag
<infinity> Configure flag or missing build-dep, if local went fine.
<infinity> Perhaps something with *gdk*-dev in the name, based on the missing symbols. :P
<infinity> jbicha_: Also, what are the odds that this new clutter (when fixed) will also fix bug 960893?
<ubottu> Launchpad bug 960893 in clutter-gst (Ubuntu Precise) "Clutter is unable to find a valid input backend and abort the execution on ARM" [High,Confirmed] https://launchpad.net/bugs/960893
<jbicha_> infinity: I'll have a look at it later tonight if the clutter build is still broken, I have to go now
<jbicha_> I'd be surprised if that fixed ARM, but I don't understand ARM either
<sbeattie> doko: are you planning another eglibc upload before beta 2 freeze?
<doko> sbeattie, no
<sbeattie> doko: hrm, can you push the patches for bug 953171?
<ubottu> Launchpad bug 953171 in eglibc (Ubuntu) "Please fix CVE-2012-0864 in precise" [High,In progress] https://launchpad.net/bugs/953171
<infinity> sbeattie: I could be talked into it.
<sbeattie> infinity: I would greatly appreciate it.
<infinity> sbeattie: Sure, I'll do it later this afternoon/evening.
<sbeattie> infinity: thanks!
 * doko hurrays the eglibc takeover \o/
<infinity> doko: :P
<infinity> doko: Do you know if there have been discussions in Debian about switching back to glibc, BTW, now that upstream's had a change of management and process, and seems sane finally?
<doko> not that I know of
<infinity> Or are we just going to wait for eglibc to get absorbed by glibc and have it happen organically?
<broder> there was a management/process change in glibc? did i miss an article or has this generally not been reported on yet?
<infinity> It's not been widely publicised, to my knowledge.  I only know about it because jbailey pointed it out to me in passing.
<infinity> But drepper no longer controls with an iron fist, and glibc upstream has been pulling in eglibc patches and closing the divergence window like mad.
<broder> fascinating
<infinity> I thought so too.
<infinity> They've even been pulling "weird ports" patches, like Debian k*BSD stuff, which would have been unheard of a year ago.
<cnd> slangasek, infinity: would switching a package to multi-arch run afoul of the feature freeze?
<cjwatson> cnd: It requires a feature freeze exception, yes.
<cnd> ok
<cnd> I'll branch our packaging for precise then
<cjwatson> Multiarching packages can cause things that depend on them to start failing.
<cnd> yeah, makes sense
<cjwatson> s/depend/build-depend/
#ubuntu-devel 2012-03-22
<kees> jcastro: how do I submit a juju charm to the massive repo of them?
<jcastro> http://juju.ubuntu.com/Charms
<jcastro> has the steps
<jcastro> kees, push to your branch, file bug, attach branch, tag it "new-charm" when you want a review
<jcastro> kees, is this for the contest?
<kees> jcastro: well, I thought I did all that before, but I figured I'd try it again as long as there was a contest. ;)
<jcastro> link me up with the bug # when you have it and I'll pile it on the queue!
<jcastro> kees, nice to you have you around rocking it still.
<kees> jcastro: thanks!
<kees> https://bugs.launchpad.net/charms/+bug/961819 tada
<ubottu> Launchpad bug 961819 in Juju Charms Collection "New "sbuild" charm for build environments" [Undecided,New]
<kees> okay, looks like I had just missed that last step then. heh
<adam_g> any tips for dealing with test suites in packages that call libraries (python library, in this case) that try accessing things that are off limits on the build system (/dev/log, in this case)
<jamesh> adam_g: fixing the test suite not to access things that are off limits?
<adam_g> jamesh: its not the test suite, its a library that the test suite requires. suppose there is no fix other than skip those tests
<jamesh> adam_g: or provide a fake implementation of the library function
<jamesh> or perhaps one of the mock libraries
<jhojho> can someone sponsor some attention to this bug. given that it's openssl, it will likely affect quite a few installs and packages. this applies to 64bit installs that do not have processors with AES-NI
<jhojho> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/940230
<ubottu> Launchpad bug 940230 in openssl (Ubuntu) "openssl on 64bit is much slower than before" [Undecided,New]
<jhojho> it should be easily fixable with compile flags. i.e. do not compile ASM in for the x86_64  build...
<pitti> Good morning
<scientes> unity-2d in precise use to work and now it doesn't
<scientes> at 800x480 on fbdev @ 16 bpp
<RAOF> scientes: Can you be more specific than âdoesn't workâ?
<scientes> it crashes at launch
<scientes> it takes al long time to time out before apport comes up
<scientes> but then its "cant acess memory at XXXXX"
<scientes> i tried with guest login too
<scientes> and i purged xorg-edgers
<scientes> the desktop also gets posted
<scientes> *desktop image
<scientes> how do i launch unity from the command line?
<vibhav> scientes: unity
<scientes> unity-2d
<scientes> pooh wow, that worked
<scientes> maybe its a multi-seat problem
<scientes> oh no, its using llvmpipe, and slow as balls
<scientes> and horribly corrupt
<scientes> how do i run unity-2d from command line?
<vibhav> #ubuntu might know
<scientes> unity-2d-shell: [FATAL] Settings schema 'com.canonical.Unity2d.Launcher' is not installed
<jalcine> balls move quickly when kicked.
<jalcine> just saying, hehe
<scientes> old version, fixed
<alkisg> Hi, I'm using python-distutils-extra, and when I build under Lucid, data_files are missing from POTFILES.in, while under Precise everything is OK. I'm currently using a potfiles-workaround/ dir with symlinks to the files that need translations, but that's too ugly, any better solutions?
<hrw> cjwatson: ops, screwed check then
<pitti> micahg: what's the state of the lightdm gtk greeter?
<alkisg> Hi, I'm using python-distutils-extra, and when I build under Lucid, data_files are missing from POTFILES.in, while under Precise everything is OK. I'm currently using a potfiles-workaround/ dir with symlinks to the files that need translations, but that's too ugly, any better solutions?
<dholbach> good morning
<cjwatson> hrw: well, I fixed pcmciautils, anyway
<hrw> cjwatson: thx
<hrw> cjwatson: what would you suggest to do with rest of packages?
<hrw> cjwatson: ignore, convert to debhelper?
<cjwatson> hrw: not sure :)
<cjwatson> it doesn't seem desperately vital that ed doesn't have debug symbols, say
<hrw> sure, but would be nice to have one for bzip2 for example
<cjwatson> maybe an Ubuntu-specific change to call pkg_create_dbgsym in the appropriate place
<cjwatson> I don't think converting packages to debhelper as an Ubuntu delta is a good idea
<hrw> like binutils do ;)
<hrw> no, sending delta back should be done
<cjwatson> it would have to check /CurrentlyBuilding
<cjwatson> there are cases where maintaining a delta is the right thing to do
<hrw> btw - can package has arch specific dependency? build-dependencies can do that but I am not sure about dependencies
<cjwatson> you probably aren't going to make many friends by sending patches that completely change the packaging
<hrw> I know
<cjwatson> yes, provided that the package is not Architecture: all
<hrw> thats the problem
<cjwatson> then no
<hrw> laptop-detect is shellscript which is arch:any cause on x86 it has one more dependency
<cjwatson> that's a legitimate reason to be arch: any
<cjwatson> it doesn't just mean "compiled code only"
<hrw> I know, just wondered
<toabctl> mvo, can you have a look at https://bugs.launchpad.net/apt/+bug/960914 ?
<ubottu> Launchpad bug 960914 in update-manager (Ubuntu) "Can not update packages - nothing happens after package download" [Undecided,New]
<mvo> toabctl: sure, let me check that one
<mvo> toabctl: let me follow up in the bugreport I asked a bunch of questions there
<mvo> (now)
<pitti> hey mvo, good morning
<mvo> hey pitti good morning to you as well
<pitti> mvo: in bug 950676, do you think it would help to remove libseed0 early with a breaks: or even conflicts:? it seems to be pretty close to the root of the evil
<ubottu> Launchpad bug 950676 in apt (Ubuntu Precise) "lucid->precise upgrade failure due to gir1.0->gir1.2 conflicts" [High,New] https://launchpad.net/bugs/950676
<jamespage> StevenK, hey - any change you could accept the zentyal-* binary packages into precise please?
 * StevenK reaches for cocobanana.
<StevenK> jamespage: I'm a little concerned some of the source packages are 2.3.4 and some are 2.3.3, but they all look good, so I'm accepting them.
<jamespage> StevenK, great - upstream release each component separately hence the different minor version numbers...
<jamespage> thanks v much
<mvo> pitti: sorry, I was deep in a code review, let me check
<mvo> pitti: getting rid of libseed0 early would certainly help
<mvo> pitti: from what I see in the logs
<pitti> mvo: still not sure whether this is a real apt bug, or just bad dependencies
<pitti> mvo: ok, I'll try to upload a seed with that conflicts, we'll see how far we'll get
<pitti> s/try to//
<mvo> I wonder why its installed in the first place
<pitti> mvo: some universe package in lucid apparently pulled it in
<mvo> pitti: give me some minute to read the log some more
<mvo> at least:
<mvo> Broken libseed0:i386 Depends on gir1.0-glib-2.0 [ i386 ] < 0.6.8-1 > ( libs ) (>= 0.6.3)
<mvo>   Considering gir1.0-glib-2.0:i386 17 as a solution to libseed0:i386 -1
<mvo>   Removing libseed0:i386 rather than change gir1.0-glib-2.0:i386
<mvo> looks like its doing the right thing
<jhojho> openssl-1.0.1 is released.  is it too late to ship for precise?
<cjwatson> I was actually pondering that myself
<cjwatson> planning to look into it today and do some testing, and get a feature freeze exception request in if it looks good; there are some problems I've not been able to solve otherwise
<jhojho> there are numerous improvements. which would be beneficial for a LTS
<cjwatson> yeah, I know
<jhojho> if you look at it, it would be much appreciated.
<cjwatson> I'm not averse to it, it would be better than giant hairy backports
<cjwatson> but there is certainly a risk so I need to do due diligence
<jhojho> also if you could disable asm for ubuntu x86 64bit build
<cjwatson> I'd rather investigate first
<jhojho> there's a big regression of using asm vs. C starting with 1.0.0
<cjwatson> I'm aware of that bug but I do not propose to agree to any particular solution until I've looked into it myself
<jhojho> no worries. i have a bug opened for it. with a bunch of links that should explain.
<jhojho> as well as timings.
<cjwatson> heh, there's already an FFe open.  I do so love it when non-developers open FFes ;-)
<jhojho> i was just hoping to get these all fixed given that precise is LTS and openssl affects so many other packages that perf would be fixed. =)
<jhojho> what's the url to that FFe?
<mvo> pitti: so what is still depending on the old gir? is it just a incomplete transition?   Considering gir1.0-gtk-2.0:i386 3 as a solution to gir1.2-gtk-2.0:i386 3 shows that there are probably 3 rdepends  (but they might be still on the installed system)
<cjwatson> jhojho: it's got no useful information in it yet; I'd rather people didn't pile on it please
<mvo> pitti: the log is a bit confusing, nevermind I keep diging
<jhojho> i wasnt planning on adding anything to it.
<jhojho> just to watch/track.
<cjwatson> jhojho: also are you sure that 1.0.1 still has the performance regression on 64-bit?  the thread at http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19836 suggests this shouldn't be so
<cjwatson> aside from some slowdown to resist cache timing attacks
<mvo> pitti: aha, I think that contributes to the problem that there are no direct gir1.2-gtk-2.0 dependencies, this means apt has a harder time figuring out if the package is important or not
<cjwatson> the FFe is bug 958430
<ubottu> Launchpad bug 958430 in openssl (Ubuntu) "[FFe] Please sync openssl 1.0.1 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/958430
<mvo> pitti: I think that moving gir1.0-gtk-2.0 from option to extra (and the other gir1.0 stuff) fixes the bug too
<dholbach> sladen, do you think you could have a look into the ubuntu-font MP again?
<pitti> mvo: we can't, the gir1.0-* packages have gone long ago
<jhojho> cjwatson: it's not clear. I'm happy to do some timing tests if a package is built.
<jhojho> cjwatson: looking at the changelog, the constant time implementation that I see, is the stuff contributed by google
<jhojho> for elliptic curve
<jhojho> so not the same thing.
<pitti> mvo: "Installing gir1.2-gtk-2.0 as Depends of gir1.2-dbusmenu-gtk-0.4
<jhojho> "Specify "enable-ec_nistp_64_gcc_128" on the Configure (or config) command
<jhojho>      line to include this in your build of OpenSSL"
<jhojho> for 64bit only
<jhojho> cjwatson: in that gmane link you posted, the last sentence says "If non-AES-NI
<jhojho> performance in FIPS context is important to you, contact
<jhojho> opensslfoundation.com."
<jhojho> so I'm thinking it's probably not fixed for asm (or considered a priority item). and since using the asm codepath drops off about 50% for aes, it's kind of a big regression.
<sladen> dholbach: if it's going up, I'd like it with the ~medium  (as we have different combinations in different PPAs and this means the combinations are clear)
<dholbach> sladen, can't you upload it with that change?
<dholbach> sladen, we are going to have Beta 2 Freeze today
<jhojho> cjwatson: here's what I've found so far.. https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/940230
<ubottu> Launchpad bug 940230 in openssl (Ubuntu) "openssl on 64bit is much slower than before" [Undecided,New]
<dholbach> so better get it in quick before
<sladen> dholbach: however it is a massive (but minor) kludge that could be done at any point, and so I think this it makes sense to do it at T-5/6 weeks when it's probably possible to get a real fix in that time
<therve> hi there!
<dholbach> T-5/6 weeks? you mean after the release?
<sladen> dholbach: and additionally; if it's happening, I don't want to do it before the wallpapers go up, so I don't lose the CD space
<cjwatson> jhojho: I think I'm more worried about non-FIPS context for Ubuntu
<sladen> dholbach: release is 5 weeks away
<cjwatson> so I disregarded that last sentence
<pitti> mvo: do you think a conflicts: libseed0 or breaks: will be better?
<mvo> pitti: ohhh
<jhojho> cjwatson: i dont need FIPS so i'm fine with that =)
<mvo> pitti: I think a conflict will be (slightly) better
<pitti> mvo: ok, that's my gut feeling, too
<pitti> mvo: "oooh" sounds promising
<dholbach> sladen, ok, I don't understand what you're saying, but I'll leave the decision to you - the merge proposal looked like you wanted Florian just to update the version number, which looked like a minor thing to block on
<pitti> mvo: will a replaces: help to ease apt's mind?
<mvo> pitti: no, sorry, it was about that its gone from the archive :/
<mvo> pitti: as the optionl->extra would be a nice fix IMO
<pitti> mvo: it was renamed for parallel installability, but now it _is_ the libseed library
<sladen> dholbach: that one merge results in 3-4 other uploads needing to go into PPAs so they keep ahead
<sladen> dholbach: I'm not keen on doing it
<sladen> dholbach: however, if it's done, I'd prefer it being done in the prettiest way
<dholbach> ok, I'll leave it to you - shall I mark it as "WIP"?
<mvo> pitti: the conflict should be good enough (I think), but a C/R/P will not hurt if its really the same
<dholbach> it doesn't seem to make sense to have it in the sponsoring queue
<pitti> mvo: "provides:" would be exaggerating, and technically wrong
<pitti> mvo: I have C/R now
<mvo> ok
<mvo> fingers crossed :)
<pitti> mvo: uploaded; looking forward to tomorrow's run then
<pitti> mvo: danke!
<mvo> cool
<jhojho> cjwatson: anyways thanks for looking at it as not having to wait another 2 years for TLSv1.1 and TLSv1.2 would be nice.
<pitti> infinity: eek, that d-i FTBFS looks unhealthy..
<infinity> pitti: Nah, it's fine.
<infinity> pitti: Images just grew a bit when nic-firmware.udeb got more stuff added.
<pitti> oh, "disk full"
<infinity> pitti: Either Colin will fix it while I sleep, or I'll fix it when I wake up.
<pitti> ok, thanks
<infinity> pitti: Yeah, "disk" being the FAT image, not the buildd's disk. ;)
<pitti> right, I just missed that at my first look
<cjwatson> it's running through sbuild locally now
<hrw> can someone try to rebuild mawk? it fails for me on testing
<cjwatson> hrw: works fine here in a precise/i386 sbuild instance
<hrw> thx
<cjwatson> hrw: do you want the log?
<hrw> no, built fine in pbuilder here as well
<cjwatson> ok
<jhojho> gcc 4.7.0 is outâ¦ http://article.gmane.org/gmane.comp.gcc.devel/125441
<jenni82> hello. i've got a question on ubuntu audio dev ppa. i'm missing alsa-driver-1.0.25 package for precise x64. does anybody know if this one will be part of the release?
<jenni82> right now there seem to be only x86 packages
<geser> have you the package name at hand?
<cr3> can I express a dependency on a version like this: postgresql (8.4 | 9.1)?
<cjwatson> no
<cjwatson> the policy manual has a complete syntax for dependencies
<cr3> cjwatson: right, I was looking at this page but it wasn't mentionned. I wasn't sure whether it was because it wasn't supported or just wasn't mentionned: http://www.debian.org/doc/debian-policy/ch-relationships.html
<cjwatson> anything not there is not supported
<jenni82> package should be like this: http://packages.ubuntu.com/en/source/precise/alsa-driver
<jenni82> but there seem to be no builds for x64
<jenni82> i'm confused
<cjwatson> jenni82: all the binary packages in the alsa-driver source package are Architecture: all, so it only needs to be built on one architecture
<geser> jenni82: this source package only builds arch:all packages (can be installed on any architecture), so it only needs to get build once (which is done on the i386 buildd)
<jenni82> hmm ... but why does "$ cat /proc/asound/version"  deliver Advanced Linux Sound Architecture Driver Version 1.0.24.
<cjwatson> That's up to the kernel packages.  In Ubuntu the alsa-driver source package really just delivers configuration
<jenni82> i was hoping to get rid of some sound-issues. so this means i have to install 1.0.25 manually?
<cjwatson> I don't know whether the kernel team plan to bump to 1.0.25
<jenni82> ok. thank you.
<pitti> jdstrand, apw: sorry, in bug 947254 I accidentally also copied to -security :/
<ubottu> Launchpad bug 947254 in Kernel SRU Workflow "linux: 2.6.38-13.57 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/947254
<pitti> but I can't just remove the current package from -security again, as we actually want to keep 2.6.38-13.56 there
<pitti> so we'd either need to reupload, and cause yet another update, or do an USN explaining this?
<pitti> or find a Launchpad DB hacker to unpublish it?
<pitti> cjwatson: ^ if you happen to have a brilliant idea
<cjwatson> I suspect you're better off leaving it there, unless it's really bad
<pitti> it was regression tested and everything, it's just not a security update
<pitti> ... for the first time in months, I guess I got way too used to always copying everything to -security
<pitti> saw too late that the "promote-to-security" task was "invalid"
<jdstrand> jjohansen: ^
<jjohansen> pitti: okay, we can write a USN to explain this
<pitti> jjohansen: thanks; and sorry
<pitti> ok, I think I got the other umpteen kernels correctly
<apw> pitti, i think i'd vote for just leaving it
<micahg> pitti: re lightdm-gtk-greeter> I've got one more thing to finish before I finish that, should be ready by 19:00 UTC
<pitti> thanks
<adam_g> is there an archive admin around who can bump the nova  upload thru https://launchpad.net/ubuntu/precise/+queue ?  the new binary package is just a launch script that was previously packaged with nova-console, plus a manpage and upstart job
<bdmurray> pitti: do you recall what checks are done by apport before filing a bug in Launchpad?  I'm looking at bug 960851 from a Zorin OS install
<ubottu> Launchpad bug 960851 in ubuntu-meta (Ubuntu) "package ubuntu-desktop 1.245 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/960851
<nxvl> seb128: is my desktop on precise supposed to be completely broken?
<nxvl> seb128: i log in an i see nothing on unity or gnome3
<nxvl> didrocks: or it's your fault?? ^^
<didrocks> nxvl: before asking "who's fault it is" you should look at what you did upgrade
<didrocks> as there has been no unity upload at all in the official repo, I would doubt of it
<nxvl> didrocks: the "fault" think was just a joke, not actually looking for whos fault is, sorry about confussion
<nxvl> didrocks: i did an upgrade earlier this week and my desktop is completely gone
<didrocks> no worry :)
<dholbach> hey nxvl
<nxvl> didrocks: is that known or just randomness?
<nxvl> dholbach: hi daniel!
<didrocks> nxvl: not known from here at least
<didrocks> sorry, handling unity release, don't really have time for debugging it
<didrocks> look at what you upgrade
<didrocks> upgraded*
<nxvl> didrocks: funny part, when i get to lightdm i get no icons, just blank squares with red 'x'
<didrocks> there has been some new lightdm as well
<pkt> Does i18n/keyboard.txt actually have any effect in ubuntu-defaults-builder / ubuntu-defaults-image ?
<pkt> The context is that I 'm trying to build a localized image for Greek
<pkt> and I noticed that in the resulting image there was no english keyboard :(
<pkt> grepping the various scripts I see no reference to keyboard.txt besides verifying it
<pkt> fwiw the source of the package is here: https://github.com/ubuntu-gr/ubuntu-defaults-el-gr
<pitti> slangasek: are we planning to switch to a tmpfs /tmp/ in 12.10?
<cjwatson> depends, you volunteering for the installer work? :-)
<pitti> cjwatson: well, there are certainly programs to be fixed
<pitti> I can instantly think of Firefox (uses it for downloads)
<pitti> and presuambly also some CD burners
<pitti> these should use /var/tmp/ for large things
<pitti> cjwatson: OOI, what needs fixing in ubiquity? that's not somehing that sprang to my mind
<pitti> (just got a question about it)
<cjwatson> I think there's a reasonable argument that tmpfs /tmp ought to be selectable in the partitioner rather than mandated
<cjwatson> and it may well require adjustment of autopartitioning limits and such
<pitti> ah, ok
<pitti> https://blueprints.launchpad.net/ubuntu/+spec/server-karmic-tmp-as-tmpfs refers to bug 386554 as a blocker, I haven't checked yet whether that's still current
<ubottu> Launchpad bug 386554 in linux (Ubuntu) "System behaved as if OOM when it had plenty to spare" [Medium,Triaged] https://launchpad.net/bugs/386554
<pitti> so either way, it's not a trivial change for multiple reasons
<pitti> I was just curious whether I was missing a spec, or a bug (there's none against mountall)
<cjwatson> that was the canonical spec for it, I think, yes
<pitti> but I'm fairly sure I read about it on some ML
<pitti> or some bug, or other place
<pitti> damn memory
<pitti> parts of my brain are on tmpfs, too :)
<stgraber> pitti: it was mentioned recently on the TB ML IIRC
<pitti> ah, perhaps that one, thanks
<yofel> mvo: do you have a good suggestion on how to fix bug 944876? Just shifting the mapping is more of a hack than a fix, although s-p-kde would probably need a rewrite anyway at some point
<ubottu> Launchpad bug 944876 in software-properties (Ubuntu) "changed mapping of release_upgrades_policy causes software-properties-kde to set the wrong policy" [High,New] https://launchpad.net/bugs/944876
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: bryceh
<pitti> bryceh: enjoy the flight :)
<cjwatson> ivoks: patch in bug 961166 - was that tested?  there's a .. vs. ../.. discrepancy, which seems to be due to having backported only half of 8316bd2d9813cbc7b2b8288b6618eec2c2004028
<ubottu> Launchpad bug 961166 in live-build (Ubuntu) "lb_binary_disk doesn't check compression of the initramfs" [Medium,Triaged] https://launchpad.net/bugs/961166
<ivoks> cjwatson: let me revisit that
<ivoks> cjwatson: ups... my bad, sorry
<cjwatson> it might be worth taking the whole of that patch
<bryceh> pitti, thanks, actually since we're nigh-frozen, probably just going to tend srus
<pitti> bryceh: there might be a couple of universe fixes, too
<pitti> but yeah, ther's a fair number of SRUs, too
<bryceh> pitti, is universe not included in this freeze?
<pitti> bryceh: it is, but it's feature/UI freeze just like main
<pitti> but UI is "less" frozen for universe
<pitti> the definition even says it doesn't apply to universe
<pitti> and of course they are less dangerous usually
<bryceh> pitti, ok, thanks.  I still plan to make srus my focus; like you say there's a lot of 'em.
<ScottK> pitti: I thought the discussion we had a (few) weeks ago concluded in a general consensus that U/I freeze applied to everything (like FF), but that for unseeded packages that aren't in any docs package they would be trivially approved?
<pitti> right, that's why I said "less" frozen
<pitti> I haven't checked whether there are any UI breaks in teh sponsoring queue, and whether they have UIFE bugs
<slangasek> agateau: are you sure 'libqt4-gui' is the package you meant to ask me for in bug #915801?  Because libqt4-gui:i386 isn't installed (it's not a dep of skype:i386)
<ubottu> Launchpad bug 915801 in sni-qt (Ubuntu Precise) "sni-qt seems to no longer let skype show up as an indicator in precise" [High,Confirmed] https://launchpad.net/bugs/915801
<agateau> slangasek: ahah, maybe that is the problem
<slangasek> really
<slangasek> ?
<agateau> is your skype package statically linked against qt?
<slangasek> well, it's the stock package
<slangasek> let's see
<slangasek> $ ldd /usr/bin/skype |grep QtGui
<slangasek> 	libQtGui.so.4 => /usr/lib/i386-linux-gnu/libQtGui.so.4 (0xf6b07000)
<agateau> ah no, I was wrong
<agateau> it is libqtgui4
<slangasek> ok
<agateau> libqt4-gui is a transitional pacakge
<agateau> *package
<slangasek> ok, versions sent to the bug
<pitti> this is really a curious one; sni-qt has worked fine here all the time
<pitti> I wonder what the heck is different
<pitti> (with skype)
<ScottK> pitti: Right, but I think we need to update the definition on the wiki to match that.
<slangasek> pitti: yeah, I'd also like to know ;)
<slangasek> mvo: hey, do you have any time to talk about bug #876298?
<ubottu> Launchpad bug 876298 in update-notifier (Ubuntu) "[MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [Critical,Triaged] https://launchpad.net/bugs/876298
<mdeslaur> slangasek: #962378 is making me cry
<mdeslaur> bug #962378
<ubottu> Launchpad bug 962378 in ca-certificates-java (Ubuntu) "ca-certificates-java tries to call "java" binary before it's installed" [Undecided,New] https://launchpad.net/bugs/962378
<slangasek> mdeslaur: that's not a new issue, the circ dep has been there for quite some time IIRC - what's making you cry now?
<mdeslaur> slangasek: I'm trying to fix bug #920758
<ubottu> Launchpad bug 920758 in ca-certificates-java (Ubuntu Precise) "DigiNotar Root CA still present in ca-certificates-java" [Undecided,Confirmed] https://launchpad.net/bugs/920758
<slangasek> and the circ dep is getting in the way of fixing, or in the way of testing the fix?
<mdeslaur> hrm, actually...just testing, so I'll work around it for now
<slangasek> bdmurray: can we block new reports of bug #929219 please?  launchpad is starting to creak
<ubottu> Launchpad bug 929219 in eglibc (Ubuntu) "chromium-browser crashed with SIGSEGV in __nscd_get_mapping()" [High,Triaged] https://launchpad.net/bugs/929219
<slangasek> bdmurray: the duplicate signature should check for that __nscd_get_mapping() call in any package, not just chromium-browser or eglibc; I just duped bug #929437 to it, which was reported via gvfs+software-center
<ubottu> Launchpad bug 929219 in eglibc (Ubuntu) "duplicate for #929437 chromium-browser crashed with SIGSEGV in __nscd_get_mapping()" [High,Triaged] https://launchpad.net/bugs/929219
<slangasek> mdeslaur: right - we may be able to improve handling of the circular dep, but I'd like doko to weigh in and he's out today
<mdeslaur> slangasek: ok, thanks
<bdmurray> slangasek: nscd_get_mapping only appears in the retraced stacktrace which isn't patternable.  do you have another suggestion?
<slangasek> bdmurray: heh, darn
<slangasek> bdmurray: gethostbyname2_r() + the eglibc version may be sufficient?
<slangasek> bdmurray: yeah, that should be enough to identify it
<slangasek> libc6 version >= 2.15~, <= 2.16-0ubuntu6
<slangasek> sorry, 2.15-0ubuntu6
<jhojho> cjwatson: can you confirm if the perf regression is fixed in 1.0.1?   nehalem, sandy bridge and ivy bridge all have aesni  support
<jhojho> so it's not a perf issue on those processors.
<jhojho> the regression is on 64bit processors without aesni
<pitti> jibel: would it be possible to re-trigger precise-upgrade-lucid-universe ?
<pitti> jibel: as long as it fails, it "only" takes 1:45 hours
<pitti> jibel: but we got that seed fix today which hopefully helps
<pitti> jibel: (seed as in the package, for the libseed0 -> libseed-gtk3-0 transition and the gir1.0 mess)
<jibel> pitti, it's in the queue and will start after lucid server. ETA 3min 9sec according to jenkins :)
<pitti> jibel: thanks!
<slangasek> pitti: what was the fix for seed, OOI?
<slangasek> ah, pushing libseed0 out manually, ok
<pitti> slangasek: we made libseed-gtk3-0 conflicts/replaces libseed0, to force the removal of libseed0 instead of trying to fulfill its dependencies in precise
<pitti> it seems apt did not clean it up by itself
<slangasek> yeah... it's a shame to need to do that
<slangasek> but certainly quicker than figuring out why apt isn't happy to remove the lib :/
<pitti> well, I looked at that apt log for over an hour, and this seems to be the root cause
<pitti> I guess if I do that ten times more, I'll write a script to graphvizise apt.log :)
<slangasek> yeah, it's the root package cause certainly
<slangasek> but the *root* cause is apt keeping an obsolete lib when it should throw it away :)
<mvo> slangasek: sure, the bits in comment #22 ?
<slangasek> mvo: well, and the merge proposal which I marked you a reviewer on :)
<mvo> slangasek: rigth, I was off yesterday and crazy day today, but let me scan over it
<cjwatson> jhojho: my results are in the bug
<cjwatson> jhojho: based on the assertions I've seen that there was some deliberate slowing down of AES to defeat cache timing attacks, I'm reluctant to assume that slower is necessarily a showstopper here
<jhojho> i see the bug report but no actual timings.
<pitti> slangasek: yeah, workarounds'r'us
<jhojho> cjwatson: that makes no sense as processors with aesni exhibit no slowdown
<cjwatson> I posted timings from a Core 2 Duo and a Nehalem to the FFe bug
<mvo> slangasek: I will reply in the bug and in the MP
<cjwatson> Anyway, I'm not going to change it further before beta 2 at this point unless there's some kind of serious regression from 1.0.0g, so there should be plenty of time to collect data
<jhojho> ah I see the timings now. let me go check them out.
<cjwatson> I'm afraid I didn't post comparative timings from lucid; I can do that later if necessary
<cjwatson> on the "one step at a time" principle I wanted to get 1.0.1 sorted out first
<cjwatson> anyway, it's thoroughly pub time now
<jhojho> please if you could.
<jhojho> there is one thing I would ask for on the amd64 build
<jhojho> its the inclusion of the config flag that turns things on for the google contributed elliptic curve code
<cjwatson> well, let's talk with the Debian maintainer about that; 1.0.1-2ubuntu1 very significantly reduces the delta against Debian and I'm pretty happy about that
<cjwatson> (makes it easier to maintain)
<jhojho> for whatever reason, they made things so that you have to explicitly pass that flag.
<jhojho> ok
<cjwatson> that's "enable-ec_nistp_64_gcc_128"?
<jhojho> yes
<dobey> actually i guess i should have asked that over here insteadâ¦
<dobey> hrmm. is apport retracer blocked/disalbed for amd64 bugs?
<bdmurray> slangasek: so the bugpatterns are regular expression would 2.15~pre work?
<bdmurray> ah no also need one for 2.15-0ubuntu6
<slangasek> bdmurray: as a regexp, I'd do '2\.15\(~pre\|-0ubuntu[1-6]\)'
<jhojho> cjwatson: it does look like things are a tad faster between 1.0.0 vs 1.0.1
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | 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: bdmurray, bryceh
<jhojho> cjwatson:  just installed to 1.0.1 and it looks like Lucid is still faster.  here's the pastebin for lucid and precise (2 results, 1.0.0 and 1.0.1)  http://pastebin.com/FG6mfabw
<Sarvatt> jhojho: wouldn't that be dependent on the kernel instead?
<jhojho> why?
<jhojho> this is a userspace test. it has nothing to do with the kernel
<Sarvatt> the fact the aes numbers dont change here either make me think its using the kernel aes stuff but i really have no clue
<Sarvatt> sha1 rc4 md5 all change drastically
<PaoloRotolo> Hi all!
<mvo> slangasek: I followed up in the MP
<slangasek> mvo: seen, thanks
<bdmurray> How does the app-install-data-ubuntu menu-data get generated?
<pitti> slangasek: sni-qt> *chuckle*
<pitti> slangasek: I'm glad that the mystery is resolved
<slangasek> pitti: :/
<slangasek> pitti: I feel bad now for wasting people's time
<pitti> [ubuntu/precise] lightdm-gtk-greeter 1.1.4-0ubuntu1 (Accepted)
<pitti> \o/
<slangasek> and am running debsums -s now :P
<pitti> thanks micahg and mr_pouit !
<infinity> pitti: What, no love for the guy who put all the effort into pressing the "accept" button?
<slangasek> infinity: not unless you can prove it was you who pressed it ;)
<infinity> slangasek: There's a bug for that. :P
<infinity> slangasek: And I can prove I filed it!
<Beret> I'm sure someone will pick it up eventually, but if a sponsor is lurking, I could use one for https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/962448
<ubottu> Launchpad bug 962448 in landscape-client (Ubuntu) "update package to 12.04.2" [Undecided,New]
<skaet> msg chanserv topic #ubuntu-devel Precise Beta 2 Freeze in Effect.  Archive: pre-release freeze | Development of Ubuntu (not support, not app development) | 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: bdmurr
<skaet> ay, bryceh
<bryceh> skaet, yes?
 * Daviey paases skaet a / :)
 * skaet accepts the / from Daviey 
<skaet> :)
 * maco wonders if the linebreak indicates it wont all fit in /topic either
<bryceh> heh, max topic length?
<Daviey> suck it and see.
 * maco eyebrow
<skaet> it looks ok to me...
<bryceh> yeah ok here too
<maco> i dont see the topic as having changed...
<skaet> topic seem to be longer than the line limit.   interesting.
<ScottK> Missing two letters off of the patch pilot's nick here.
 * skaet edited out the redundant info about the Archive, Beta 2 Freeze in Effect pretty much summarizes it.
* Daviey changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Development of Ubuntu (not support, not app development) | 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: bdmurray,
<skaet> ScottK,  better?
<maco> skaet: wasnt bryceh also supposed to be a patch pilot?
<ScottK> I only see bdmurray,
<ScottK> Getting there.
* Daviey 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: bdmurray, bryceh
<Daviey> \o/
<ScottK> There we go.
<skaet> Thanks Daviey
<skaet> sigh...
<skaet> bryceh was on the last version i thought... oh well.   sorted now.   Thanks ScottK, maco.  :)
<ScottK> You're welcome.
<bryceh> having it go over length is probably a sign the topic needs some cleanup ;-)
<slangasek> so um, why is libvte suddenly complaining about a missing /etc/termcap?
<slangasek> (and as a result, failing to correctly handle PgUp/PgDn and others)
<slangasek> gnome-terminal not restarted for 18 days; not sure if it needs restarted, or if trying to restart it is the worst idea ever
<infinity> slangasek: I see no such whining from my xfce4-terminals (which also use vte)
<infinity> slangasek: I say restart gnome-terminal, and if it all goes south, we'll see you from your console? ;)
<bdmurray> @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: bryceh
<bryceh> @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:
#ubuntu-devel 2012-03-23
<smoser> skaet, around ?
<broder> slangasek: you need to restart gnome-terminal
<broder> the new version of the library embeds the termcap instead of shipping it as a separate file
<broder> rather, all of your terminals
<skaet> smoser,  just back from dinner,  what's up?
<kees> I am impressed that the resolvconf postinst contains a detailed error about having an immutable resolv.conf file :)
<ajmitch> there are probably quite a few blog posts telling people to make resolv.conf immutable to stop it being clobbered :)
<kees> indeed. it's the only way I could get n-m to behave itself.
<stgraber> ajmitch: no, the recommendation is to simply replace the symlink by a regular file
<kees> and it looks like resolvconf DTRT for my system, which I find very pleasing
<stgraber> ajmitch: doing so will never convert it again to a symlink
<ajmitch> stgraber: so that's the case now, but I've seen plenty of suggestions to use chattr to stop it being overwritten
<stgraber> ajmitch: yeah, this check was added in resolvconf when it was being prepared for 12.04
<stgraber> ajmitch: the "old" resolvconf wasn't doing as many checks ;)
<ajmitch> figures :)
<slangasek> broder: why in the world would that have changed as part of a "memory-based scrollback stream backend"?
 * kees looks around
 * slangasek looks at kees
<kees> I did upload vte yesterday...
<slangasek> why did your upload break termcap handling for running processes? :)
<kees> that part, I don't know
<slangasek> well, broder asserts that "the new version of the library embeds the termcap instead of shipping it as a separate file"
<slangasek> that doesn't seem like a trivial change to make accidentally :)
<kees> unless that was is a result of a rebuild on a dep, I didn't make that change.
<slangasek> ok
<ajmitch> kees: does gnome-terminal use vte or vte3?
<kees> oh yay, did vte fork now too?
<ajmitch> looks like the change was in vte3, also uploaded yesterday
<slangasek> oh sigh, of course
<slangasek> yeah, that's why the changelog made no sense :P
<kees> hrm, does this mean I need to get the memory-backed stuff into vte3 too?
<broder> slangasek: pitti uploaded a new upstream release that i believe is to blame
<slangasek> broder: yeah... I was looking at the wrong generation of libvte :)
<broder> :)
<kees> hrm, does nothing in oneiric provide the /usr/include/sys directory?
<micahg> kees: apparently not
<kees> wow.
 * micahg doesn't see it in precise either FWIW
<kees> that's a pretty bad regression. oh well, I guess no one uses /usr/include/syscall.h that much then?
<kees> it's there in precise.
<kees> drwxr-xr-x 2 root root 12288 Mar 22 16:34 /usr/include/sys/
<kees> $ ls -la /usr/include/sys/syscall.h
<kees> lrwxrwxrwx 1 root root 33 Mar 21 17:43 /usr/include/sys/syscall.h -> ../x86_64-linux-gnu/sys/syscall.h
<jalcine> Is it safe to add icons into /usr/share/icons/hicolor ?
<jalcine> Like via a package install?
<micahg> kees: oh, that's there in oneiric, packages.ubuntu.com seems to be weird
<kees> oh, hrm, I think it's done differently in oneiric... the compiler has the right paths. ah well
<slangasek> kees: /usr/include/sys is only there for compatibility if you have the gcc biarch packages installed
<pitti> Good morning
 * pitti gratefully extends his thanks to infinity as well :)
<pitti> broder: what's up? yes, new vte3 embeds that now
<broder> pitti: sorry, didn't mean to ping you. the upgrade dropping the file caused problems for running gnome-terminal (if you opened a new terminal, which would have been in the old process)
<pitti> broder: oh, I see; so just a temporary glitch
<broder> yeah
<vibhav>  
<vibhav> oops
<pitti> slangasek: acked bug 962124 FTR
<ubottu> Launchpad bug 962124 in upstart (Ubuntu) "Feature Freeze Exception request for Upstart in Precise" [Wishlist,Triaged] https://launchpad.net/bugs/962124
<slangasek> pitti: great, thanks :)
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<shadeslayer> pitti: re bug 858970 : it's already fixed in precise ( the fix was incorporated into 6.1.4 )
<ubottu> Launchpad bug 858970 in virtuoso-opensource (Ubuntu Oneiric) "Virtuoso 6.1.3 cause nepomuk encoding error" [Undecided,New] https://launchpad.net/bugs/858970
<shadeslayer> the problem is specific to version 6.1.3
<pitti> shadeslayer: ah, can you please close the precise task then?
<pitti> shadeslayer: that SRU was a bit confusing, it refers to two bugs, and the other looks like a synthetic meta-bug
<shadeslayer> pitti: done, yeah, I thought that you had to open SRU bugs seprately to get packages SRU'd ... will take care next time :)
<pitti> shadeslayer: no, please don't do that, it's confusing and actually detrimental to getting testing feedback
<pitti> shadeslayer: the SRU policy page mentions this, too
<pitti> shadeslayer: ok, thanks; will have another look at it
<shadeslayer> thanks! sorry for the confusion
<pitti> shadeslayer: accepted now, thanks
<shadeslayer> \o/
<dholbach> smoser, happy birthday!
<seb128> ev, hey, those are the retracers dups from this week, most of the top 10 is whoopsie: http://pastebin.ubuntu.com/896289/
<seb128> ev, if you could look at the ones listed there
<ev> seb128: indeed, I'm on it. I had a chat with njpatel about it this morning and have a number of things to try an uncover the underlying memory corruption issue with.
<seb128> ev, cool
<seb128> ev, valgrind is your friend I would say ;-)
<seb128> mvo, hey, I've assigned bug #938116 to you it's a quite frequent one as well
<ubottu> Launchpad bug 938116 in apt (Ubuntu) "update-manager crashed with SIGSEGV in DescriptionList()" [High,Confirmed] https://launchpad.net/bugs/938116
<ev> indeed, I've been using it extensively, but it hasn't turned up the corruption on my local system.
<ev> I've also worked with mudflap a bit, but it looks like you need to compile the world with it in order to not get a ton of false positives
<mvo> seb128: its a segfault? in the python code?
<mvo> seb128: oh, ok
<seb128> mvo, no, in libapt-pkg.so.4.12
<mvo> ta
<seb128> mvo, thank *you* ;-)
<hrw> hi
<hrw> bug 962997 - can someone take a look?
<ubottu> Launchpad bug 962997 in debianutils (Ubuntu) "FTCBFS: Cross build calls wrong-arch strip " [Undecided,New] https://launchpad.net/bugs/962997
<MacSlow> seb128, didrocks: I'm just about to merge an approved fix for LP: #716458 to notify-osd and will do a release today too... so we get fixes for average bg-color and the multi-monitor issues.
<MacSlow> seb128, didrocks: I hope you're ok with those for a new release.
<seb128> MacSlow, great
<seb128> MacSlow, yes
<Laney> cjwatson: Just looking at bug #948848, what Conflicts are you proposing to add? Is it adding mono-gac << fixed-version to perl-base to ensure that the new version of mono-gac is unpacked early enough?
<ubottu> Launchpad bug 948848 in perl (Ubuntu Precise) "cil packages fail to uninstall on lucid->precise upgrade due to prerm script use of perl-modules via /usr/share/cli-common/gac-package-remove -> /usr/share/cli-common/runtimes.d/mono (Can't locate File/Basename.pm in @INC)" [High,Triaged] https://launchpad.net/bugs/948848
<smoser> dholbach, thanks.
<semiosis> SpamapS: ping?
<alkisg> Hi mvo, sorry for the ping, ogra told me it'd be a good idea to notify you about https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/782953
<ubottu> Launchpad bug 782953 in software-center (Ubuntu) "Software Center doesn't detect changes in sources until update-apt-xapian-index is ran by cron" [Medium,Triaged]
<alkisg> I just verified it, removed the cron jobs and software-center isn't aware of the new sources, even after running apt-get update, 1 hour later...
<cjwatson> Laney: mono-gac/perl - correct, we need the new mono-gac to be at least unpacked before perl-base is unpacked so that when /usr/share/cli-common/runtimes.d/mono is invoked it isn't trying to use a Perl module that isn't currently in the configured state - this is the only way I know of to deal with this condition reliably
<Laney> cjwatson: OK, got it. It seems odd that this situation arises; is using perl modules from pre* maintianer scripts just a bad idea?
<Laney> i.e. what if we had actually been making use of that module?
<cjwatson> Laney: well, you aren't pre-depending on perl, so you aren't entitled to expect perl to be configured, only perl-base, and File::Basename isn't in perl-base
<cjwatson> Laney: but quite a few situations (config, sometimes prerm, postrm, triggers, basically anything that's asynchronous with respect to package state) can really only safely use Essential packages
<cjwatson> regardless of (pre-)dependencies
<cjwatson> hooks provided for use by other packages' maintainer scripts are really best advised to stick to Essential, IMO
<Daviey> cjwatson: Ubuntu doesn't respect Essential, does it?
<cjwatson> Daviey: ??!
<Daviey> cjwatson: A package declaring itself essential, isn't necessarily published as Essential, is itt?
<Laney> got it, the discussion about skew between perl-base and perl-modules skewed my mind also
<cjwatson> Daviey: not true at all
<cjwatson> Daviey: Priority and Section are overridden (also true in Debian); Essential is absolutely not
<hrw> ok, another ftcbfs fixed - bug 963047
<ubottu> Launchpad bug 963047 in klibc (Ubuntu) "Fails to cross build" [Undecided,New] https://launchpad.net/bugs/963047
<mvo> alkisg: cool, thanks
<alkisg> You're welcome, if you could also have a look at https://bugs.launchpad.net/ubuntu/+source/dbconfig-common/+bug/962393 I'd appreciate it :)
<ubottu> Launchpad bug 962393 in software-center (Ubuntu) "Installation loops in db-config-common when ran from software-center" [Undecided,New]
<alkisg> "...Maybe the problem is that software-center spawns debconf-communicate with the user id instead of as root"
<smoser> cjwatson, around ?
<smoser> i have a more clear question for you now regarding my grub issue. then i can dig some more,.
<smoser> when we build the image files, we generally do so for a "full disk image" (with partition table).
<smoser> where i was failing was where i was then trying to use the core.img file from inside that image when there was no partition table on the disk.
<smoser> does that have any chance of working?
<cjwatson> I think in principle it ought to but you're into much less well-tested code paths
<cjwatson> you *should* be able to treat any device, disk or partition, as a filesystem
<smoser> cjwatson, so if core.img is loaded
<smoser> how does it know where modules and things are ?
<cjwatson> smoser: it has a prefix baked into it
<smoser> what does the prefix look like ?
<smoser> (and when does it get baked in?)
<cjwatson> depends on the platform; you can set it using the -p option to grub-mkimage, or sometimes grub-setup will add it depending on where you're installing the image to
<cjwatson> the prefix is a full GRUB file name, as in http://www.gnu.org/software/grub/manual/grub.html#File-name-syntax - it should probably typically include a device
<cjwatson> it ought to point to an equivalent of /boot/grub
<smoser> cjwatson, well, i'm pretty sure my core.img gets built during dpkg install of a debootstrap
<cjwatson> I'm pretty sure it doesn't
<cjwatson> GRUB isn't in the base system
<smoser> (then i'm pretty sure you're right)
<smoser> oh
<smoser> not debootstrap, sorry.
<smoser> but installation in a similar manner. ie, in a chroot on a real disk that has no relavance to the end goal
<cjwatson> so depends how (if) grub-install gets invoked within that environment, really.  you may have to call it by hand.
<cjwatson> (or grub-mkimage / grub-setup manually, depending)
<smoser> and later, we fake grub-probe and call grub-install.
<cjwatson> use 'grub-install --debug' and see which mkimage/setup commands it's actually calling
<smoser> but i didn't think grub-install touched core.img.
<cjwatson> that's incorrect
<cjwatson> it generates a new one
<smoser> ah.
<smoser> but not if --grub-setup=/bin/true
<smoser> so that then at least makes sense to me. (i think).
<cjwatson> why not if --grub-setup=/bin/true?  it's the grub-mkimage call that generates the core.img.
<cjwatson> But certainly if you have --grub-setup=/bin/true it won't install it anywhere, and it's possible that the default prefix will be wrong
<smoser> well, mhm..
<smoser> i think i'm not explaining myself.
<smoser> i have 1 core.img
<smoser> and i was hoping that I could grub multiboot load that core.img
<cjwatson> What I mean is that --grub-setup=/bin/true does not stop grub-install from generating a core.img.
<smoser> but you're saying that that core.img has a prefix of some sort baked in.
<smoser> so either that path is (hd0)/boot/grub/grub.cfg or (hd1,7)/boot/grub/grub.cfg
<smoser> but i was hoping that the same core.img would work when it's view of the world was *either* (hd0,1)/boot/grub or (hd0)/boot/grub
<cjwatson> Well, it can sometimes be device-independent as well, it depends on a few factors.  Can I go and write the foundations weekly report and then I'll get back to you?
<cjwatson> 'cos I'm overdue.
<smoser> no, cjwatson, you must do my bidding NOW
<smoser> oh wait,
<smoser> no, you can do that firts
<smoser> thank you for your help.
<smoser> cjwatson, when you do return, heres maybe a bit cleaner description
<smoser> http://paste.ubuntu.com/896460/
<dupondje> Did the ABI get bumped of openssl yesterday?
<cjwatson> yes, though backward-compatibly
<dupondje> Weird, cause freerdp nla auth is broken now. Tried a rebuild of the package, without changes, and it works ...
<cjwatson> dupondje: is the source package 'freerdp'?
<dupondje> Yes
<cjwatson> It doesn't seem to do anything deeply horrible.  Let me poke around a bit ...
<cjwatson> How do I reproduce the problem?
<cjwatson> (Note, I don't have Windows)
<dupondje> xfreerdp --sec nla <randomwindowsserver>
<dupondje> :D
<dupondje> but i'm doing some tests atm
<cjwatson> I'll probably want to compare the binaries
<cjwatson> smoser: I'll have a look at this image.  I probably need to meditate on it a bit
<smoser> ok. thanks.
<cjwatson> (ETA >1h for the download though)
<smoser> cjwatson, you have canonistack credentials?
<cjwatson> not quite sure why I'm only getting 50kb/s, that's even worse than usual
<smoser> there, download is at 40M/s
<Darxus> I just let update-manager do an automated upgrade, on Precise.  It failed, and now apt-get can't fix it:
<Darxus> dpkg: error processing libfreetype6 (--configure): libfreetype6:amd64 2.4.4-2ubuntu1.2 cannot be configured because libfreetype6:i386 is in a different version (2.4.4-2ubuntu1.1)
<cjwatson> I want it locally
<cjwatson> it's worth waiting a while for downloads when it lets me work more quickly interactively once it's down
<smoser> well, i can't help you there. but i can set up an instance for you if you'd like.
<cjwatson> nah, no particular need I think
<cjwatson> oh, heh, I have an sbuild-update running, that would explain it
<cjwatson> dupondje: could you file a bug about this in the meantime?
<dupondje> i'll do after some more tests :)
<Darxus> Sorry, that was on Oneric that multiarch just broke hard.
<dupondje> cjwatson: i'm unable to reproduce it now on another system.
<dupondje> weird
<jdstrand> pitti: hi! whenever you had a spare moment, would you mind deNEWing hamster-indicator (bug #686062)? I sponsored it, so I can't and it seems you are sympathetic to its inclusion :)
<ubottu> Launchpad bug 686062 in Project Hamster "FFe: hamster-applet should have appindicator support" [Medium,New] https://launchpad.net/bugs/686062
<jdstrand> s/you had/you have/
<jdstrand> pitti: it isn't urgent or anything
<cjwatson> pitti: do you agree that I should add LC_IDENTIFICATION to Gunnar's list in https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/926207/comments/7 ?
<ubottu> Launchpad bug 926207 in ubiquity (Ubuntu) "Set formats related LC_* variables when applicable instead of LC_MESSAGES, LC_CTYPE and LC_COLLATE" [Undecided,New]
<cjwatson> (I went through the list in glibc)
<pitti> cjwatson: hm, that's a good question -- there is no obvious "right" locale when you are using two at the same time
<pitti> cjwatson: so if we want to be strict about the "preserve current behaviour", we'd need to
<pitti> as we currently don't
<cjwatson> as I read Gunnar's proposal it's just to flip the set round, so I think he just missed one
<pitti> it feels a bit weird to set it explicitly, but I don't think it matters much either way
<pitti> we can update accountsservice to do that as well
<cjwatson> yes, it does, but meh, my gut feel has been overruled by fiat I think
<cjwatson> and I don't care that much
<jdstrand> mterry: hey. thanks for the MIR reviews. I wanted to mention to you that my focus for the last couple weeks has been almost entirely security reviews for MIRs, and it continues to be
<mterry> jdstrand, :)  thanks
<slangasek> SpamapS: I notice that you set the severity on bug #936667; do you care about giving ppa:jamesodhunt/upstart-testing a spin before we upload to the archive?
<ubottu> Launchpad bug 936667 in upstart (Ubuntu) "Upstart early job logging causes boot failure for systems with no initramfs (error is "No available ptys")" [High,Confirmed] https://launchpad.net/bugs/936667
<tkamppeter> infinity, hi
<SpamapS> slangasek: I have that PPA enabled, but have not rebooted yet.. let me do that now.
<jdstrand> tkamppeter: is is normal for me to now have 20 '/usr/lib/cups/notifier/dbus dbus://' processes?
<jdstrand> tkamppeter: hi btw :)
<slangasek> SpamapS: did you survive? :)
<SpamapS> slangasek: still closing things down to be ready to reboot...
<SpamapS> slangasek: < 5 min
<slangasek> oh man
<slangasek> :)
<slangasek> here, let me throw you a critical bug in gnome-session to help speed things up
<dholbach> jdstrand, I just reopened https://bugs.launchpad.net/ubuntu/+source/indicator-printers/+bug/959195
<ubottu> Launchpad bug 959195 in indicator-printers (Ubuntu) "65 cups notifier processes running" [Undecided,Confirmed]
<jdstrand> dholbach: ah, thanks :)
<dholbach> jdstrand, ha! I even have more processes than you :)
<jdstrand> hehe
<jdstrand> quite a few more! :)
<SpamapS> slangasek: looks good
<SpamapS> slangasek: have we tried a cloud image yet?
<SpamapS> slangasek: IIRC, cloud-init was a victim of the early job logging problems
<slangasek> SpamapS: I don't know that anyone has; could you swing that as well?
<SpamapS> slangasek: yes doing so now
<tkamppeter> jdstrand, this is a known bug. It is fixed already. Do all updates and after that stop CUPS, "rm -r /etc/cups/subscriptions.conf /var/cache/cups/*", start CUPS again and the processes should go away.
<jdstrand> tkamppeter: actually, so dholbach's comment, above ^
<jdstrand> s/so/see/
<jdstrand> tkamppeter: I did what you suggested and it didn't work
<jdstrand> I commented in the bug
<larsu> jdstrand, dholbach, hi
<tkamppeter> jdstrand, dholbach, larsu will come up here and help you.
<dholbach> I need to rush out now
<dholbach> but I'm subscribed to the bug report and can do further testing if necessary
<larsu> dholbach, cool, thanks
<dholbach> see you later :)
<tkamppeter> infinity, around?
<infinity> tkamppeter: Yep.
<larsu> jdstrand, argh, you're right, the commands I posted on that bug don't seem to work
<SpamapS> slangasek: cloud instance boots fine w/ 1.5
<slangasek> SpamapS: woot
<SpamapS> slangasek: logging working fine too
<htorque> larsu: they worked for me, what did i do wrong? :)
<tkamppeter> infinity, it is about the p11-kit crash, bug 911436. It breaks CUPS and so very many people get Apport pop-ups when updating and there is CUPS or some printing package in the update, and these users probably also cannot print.
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<larsu> htorque, I don't know. They worked for me yesterday but not today
 * larsu wonders where CUPS could cache subscriptions
<SpamapS> slangasek: does upstart automatically re-open log files that get renamed?
<tkamppeter> infinity, therefore I have raised the bug to "Critical" and added the rls-p-tracking tag. It has > 200 duplicates.
<slangasek> SpamapS: dunno, ICMP REDIRECT jodh
<SpamapS> jodh: does upstart automatically re-open log files that get renamed?
 * SpamapS obeys the RFCs
<infinity> tkamppeter: I'm aware.  Looking into it.
<slangasek> tkamppeter: actually, I added the rls-p-tracking tag... please note that you shouldn't set this tag for other teams :)
<jodh> SpamapS: yes.
<SpamapS> jodh: *cool*
<htorque> larsu: iirc, there was a second file like /etc/cups/subscriptions.0 - i removed that too.
<SpamapS> jodh: I'm really excited about having job logging in upstart.. such a tiny thing but such a big win. :)
<tkamppeter> larsu, htorque, jdstrand, I had to stop cups, then to remove /etc/cups/subscriptions.conf and /var/cache/cups/* and /var/cache/cup[s/rss/*. After that I have restarted cups.
<larsu> htorque, nice, you're right. I wonder where that comes from (cups docs don't say anything about that)
<jodh> SpamapS: tiny, but we've seen a few interesting corner cases ;)
<SpamapS> jodh: whenever I hear "corner case" I think of The Blair Witch Project and "Mike" standing in the corner. ;)
<slangasek> lool: hmph, mawk uploaded but no bug forwarded to Debian?  I had to wait for Ron to report it ;)
<lool> slangasek: My changelog mentions a commit from collab-maint/mawk.git, isn't that from Debian?
<slangasek> oh, ffs
<slangasek> lool: that's not the package's repo, no
<slangasek> lool: oh, also I was checking the wrong version of the package
<larsu> jdstrand, please try again with the updated instructions I just posted
<larsu> tkamppeter, ^^
<lool> slangasek: I remember a weird situation around its Debian maintenance back then, but it's all fuzzy memories; I'm happy to forward remaining bits if any
<slangasek> lool: apparently it's bryceh I need to be glaring at
<lool> slangasek: this is http://paste.debian.net/160783/ e2e6d7ad490a7b19c562af5874a08a4168382b57
<bryceh> slangasek, ?
<slangasek> lool: yeah, don't worry about it, it's 1.3.3-16ubuntu3 I was referring to, I checked the sig on the wrong source package and came up with your name
<tkamppeter> larsu, htorque, jdstrand, larsu's comment #4 should remove all these. Seems that cups has complex mechanisms to protect subscriptions against data loss.
<slangasek> bryceh: patch not forwarded to Debian (where I'm the maintainer)
<lool> Ok; /me paints himself with invisible paint
<bryceh> slangasek, mind narrowing it down?
<slangasek> bryceh: mawk
<slangasek> LP: #955791
<bryceh> slangasek, ah, the reporter claimed it to be fixed upstream, so I didn't think forwarding would be needed.
 * slangasek snorts
<slangasek> ok
<bryceh> slangasek, also our mawk is way behind upstream
<tkamppeter> larsu, should it not be "sudo rm -r /var/cache/cups/*", the empty /var/cache/cups/ directory is probably still needed by CUPS. Or will CUPS regenerate it?
<slangasek> yeah, it's not "fixed upstream" because mawk doesn't have an upstream
<larsu> tkamppeter, it regenerated it
<slangasek> it has Thomas Dickey as a self-appointed upstream who throws tarballs over the fence
<bryceh> slangasek, particularly, it has hardly changed since lucid (which is why the sru was so simple!)
<slangasek> bryceh: but ok, understandable why you didn't forward in this case
<tkamppeter> infinity, thanks.
<bryceh> slangasek, https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/955791/comments/3
<ubottu> Launchpad bug 955791 in mawk (Ubuntu Oneiric) "Source and destination overlap in memcpy" [Undecided,In progress]
<slangasek> bryceh: right, thanks :)
<tkamppeter> infinity, a side effect is that some of the CUPS installation problems not caused by p11-kit got overlooked under the flooding.
<semiosis> SpamapS: ping
<SpamapS> semiosis: pong, sup?
<semiosis> SpamapS: got a question re: glusterfs in precise... upstream just did a new patch release, 3.2.5 -> 3.2.6, and i'd like to put in a sync request for precise, but also want to be sure that the new version gets my upstart job merged in
<semiosis> SpamapS: question is, do i need to do anything special beyond just filing a sync request bug?
<SpamapS> semiosis: thats not a sync, thats a merge. :)
<semiosis> true
<semiosis> so my answer is file a merge bug then :)
<SpamapS> semiosis: should be a pretty easy merge
<semiosis> we did it once already for 3.2.5-1
<SpamapS> semiosis: you should be able to submit your upstart job to debian maintainers for inclusion, then they can stay in sync
<semiosis> i actually am co-maintainer of the debian package :)
<SpamapS> semiosis: Ah, then you should be able to just put it in there!
<semiosis> problem was (and i'm not 100% sure about this) that in my tests including the upstart job broke the package on debian
<SpamapS> slangasek: dh_installinit should be fixed for shipping an upstart and an init file in Debian now, right?
<semiosis> i'll go back and do the tests again
<slangasek> SpamapS: not yet
<SpamapS> oh
<SpamapS> darn
<semiosis> :D
<semiosis> yeah...
<semiosis> you can def. put the upstart job in the package, problems happen when you try to use that package
<semiosis> iirc
<semiosis> oh and another thing, even if upstart jobs were generally compatible with debian... this one in particular is specific to mountall, and it depends on wait-for-state, which afaik are ubuntu-specific additions to upstart
<semiosis> is that right?
<slangasek> semiosis: that's largely beside the point, as both mountall and wait-for-state will be landed in Debian as part of the process of making upstart usable for Debian packages
<semiosis> slangasek: thats great to hear!  i hoped so
 * semiosis looks forward to that day
<semiosis> thanks SpamapS & slangasek for the info
<SpamapS> semiosis: anyway, how about putting it in the package and doing some conditional logic to move it into place only when building for Ubuntu?
<semiosis> SpamapS: thats a great idea, i never thought of that.  still pretty new to debian packaging.  i'll start working on that... could you point me toward any relevant docs/examples?  a package which does that would be a huge help, I like looking at source
<semiosis> gotta go afk, bbiab.  thanks again!
<PaoloRotolo> Hi all!
<danel> anyone use this?
<danel> If I'm writing helloworld.c
<danel> and the main input argument is
<danel> #include <stdio.h>
<danel>    main()
<danel>    {
<danel>      printf( "Hello, world" );
<danel>    }
<danel> I open it with ./helloworld.c
<danel> but compile it... with gcc -o helloworld.c?
<jtaylor> this is the wrong channel for these questions, but its gcc helloworld.c -o helloworld; ./helloworld
<danel> don't I need another tag for the output file name, in which case ./helloworld.c wouldn't open the file, since the input file is helloworld.c
<danel> ok
<Daviey> Pop Quiz:  If i really want postgres running during the installer, is running invoke-rc.d --force postgres start, evil.. from a postinst of a different package, that needs to use it?
<Daviey> obv. ignoring policy.d
<broder> yes. case in point: chroots. i never, ever, ever want any services running in one of my chroot, and a package shouldn't be able to override that want
<azeem_> Daviey: why do you need to have it running?
<slangasek> Daviey: if you insist on having it running, why call invoke-rc.d --force instead of calling the init script directly?
<slangasek> though I think azeem_'s question may be the more fundamental one :)
<Daviey> slangasek: I need to populate a database at d-i install time.
 * slangasek nods
<Daviey> slangasek: well sure, i thought that slightly cleaner than using /etc/init.d/foo start
<slangasek> I guess there's no offline way to do that for postgres without using the db server?
<Daviey> slangasek: NAFAIK
<slangasek> yeah; I think calling the init script directly is cleaner than using --force on an interface that exists solely to give admins control over whether services are started
<slangasek> (I'm surprised --force even exists, and wonder whose hare-brained idea that was)
<Daviey> slangasek: the only other thing would be to have a pre-start job that checks some tmp file, to see if it is 'FIRST_RUN', and populdate at application start time.
<Daviey> not sure i agree.. but i won't argue :)
<Daviey> slangasek: --force implies retry, right?
<Daviey> slangasek: do you think --force is /wrong/ to use, or just a taste thing?
<slangasek> Daviey: --force is not part of the interface specified in Debian policy, so I think it's a) pointless and b) more likely to be rendered buggy in the future
<Daviey> slangasek: Okay, thanks.. will use init.d.. thanks :)
<azeem_> Daviey: interesting, what's the use case?  Can't you query a remote pgsql server?
<Daviey> azeem_: It' an all in one, application needs a database.
<Daviey> slangasek: is policy-rc.d return 101, the only metric that the user is in d-i?
<slangasek> Daviey: I wouldn't say that it's an indicator at all, that's the same policy all of my chroots use :)
<slangasek> I'm not sure what a better indicator would be
<Daviey> slangasek: well, when i say metric.. i mean the closest to an indicator i have :(
<slangasek> why do you need to check if it's really d-i?
<slangasek> in broad strokes, what's the outcome you want here?  "Ensure postgres is always started, do our load, and if we started postgres, stop it again"?
<Daviey> slangasek: I'd like to have slightly different behaviour on the cd, that i would if you apt-get'd.
<slangasek> ah
<slangasek> different how / why?
<azeem_> can't you do that with debconf preseeding
<Daviey> slangasek: dbcommon-config option to setup database.. i'd like to hide from the cd (as the option selected *owns* the box, and the choice is to run the database locally).. if you apt-get'd, i'd like to offer the user the choice.
<Daviey> slangasek: yeah, i think preseeding is the best way
<slangasek> yeah, I think so
<Daviey> $package/dbconfig-true = True
<Daviey> Okay, thanks for your help slangasek
<slangasek> sure
<shnatsel> I'm not sure if this is the proper place to ask this, but what writes /etc/adduser.conf ? I need to change DSHELL there and I can't find the relevant package to patch
<dobey> shnatsel: dpkg -S $file tells you which packages own $file
<shnatsel> dobey: it says none own it, that's the problem
<shnatsel> dobey: I've also checked casper, just to be sure, but nothing there either
<dobey> adduser: /usr/share/adduser/adduser.conf
<dobey> shnatsel: /etc/adduser.conf seems to be old and no longer used
<dobey> at least, i'm pretty sure i've upgraded my system since aug 2009
<dobey> which is when that file was created
<slangasek> no
<dobey> or last modified rather
<slangasek> /etc/adduser.conf is the config file which is created at install time by the adduser package, using /usr/share/adduser/adduser.conf as a template
<slangasek> standard non-conffile handling
<shnatsel> slangasek: oh, thanks a lot!
<dobey> slangasek: then why does mine have a date of Aug 22 2009 on it?
<shnatsel> dobey: "at install time"
<shnatsel> dobey: and you've probably upgraded
<shnatsel> I've just realized I should have grepped $(dpkg -L adduser) :/
<shnatsel> thanks for your help!
<slangasek> dobey: because config files for something like adduser don't change very often :)
<slangasek> (in part because it's a pain to do it correctly)
<dobey> slangasek: but i'd expect the dates on the two files to at least match (as in it just wrote the file out again from the updated package)
<slangasek> not at all
<slangasek> it's a *config* file; overwriting it on upgrade is exactly the wrong thing to do
<dobey> except for all those times when i get debconf asking me to keep, replace, or merge the changes?
<slangasek> I mean overwriting it silently is the wrong thing to do
<slangasek> and there haven't been any changes upstream to this file lately
<dobey> unless it's unchanged, in which case it's fine. but yeah, i agree it's hard to do right
<SpamapS> hmm.. this is odd
<SpamapS> I have a very minimal rules file..
<SpamapS> with a package that has a single binary package..
<SpamapS> and yet, dh_install is looking for files in debian/tmp ..
<SpamapS> any ideas?
<SpamapS> the files end up in debian/$packagename already because there is a single one
<SpamapS> Ahh
<SpamapS> because I have .install files
<SpamapS> which I don't need anymore
<bdmurray> slangasek: I'm looking at bug 274421 and while the gnome bug that would set the proxy to http://:8080 is fixed I wonder if that is enough
<ubottu> Launchpad bug 274421 in msttcorefonts (Ubuntu) "Cannot download fonts, "Error parsing proxy URL http://:8080/"" [Medium,Triaged] https://launchpad.net/bugs/274421
<slangasek> bdmurray: I don't think individual packages should be expected to work around broken system proxy settings
<bdmurray> slangasek: sure, I was thinking about fixing stored entries in debconf
<slangasek> oh, is that getting set in debconf?
<slangasek> bdmurray: feel free to mark it as a duplicate of bug #876298 then
<bdmurray> comments 34 and 35 seem to indicate that
<ubottu> Launchpad bug 876298 in update-notifier (Ubuntu) "[FFe] [MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [Critical,Triaged] https://launchpad.net/bugs/876298
<slangasek> ... although maybe that would be bad for LP :)
<bdmurray> yeah, I think I'll close menting the proxy configuration tool changes
<bdmurray> mentioning even
<bdmurray> slangasek: also looking at bug 541595 no recent versions of apt seem to be implicated
<ubottu> Launchpad bug 541595 in dpkg (Ubuntu) "[Master] package failed to install/upgrade: package is already installed and configured" [High,Confirmed] https://launchpad.net/bugs/541595
<jhojho> Sarvatt: the numbers do change quite a bit. look again (carefully)
<Sarvatt> jhojho: i meant between 1.0.0 and 1.0.1 where the kernel didnt change when i said that, sorry
<Sarvatt> http://paste.ubuntu.com/897098/
<Sarvatt> aes hardly changes here so i attributed it to an outside source like it going through the kernel using CPU hardware acceleration for it, i dont know if thats actually the case :)
<Sarvatt> was just a guess
<jhojho> that's aesni.  not true here.
<Sarvatt> i can't boot a lucid kernel on this machine to try it
<jhojho> my processor does not have aesni
<jhojho> so the use case of 64bit with no aesni is affected.
<jhojho> and since the c version is faster, i would rather ubuntu use that instead.
<jhojho> im fine with the asm version being slower for resistance to timing attacks but my point then is to just use the c version.
#ubuntu-devel 2012-03-24
<infinity> roaksoax: You around?
<infinity> roaksoax: That cobbler upload.  You correctly ditched the apache2ctl call in one maintainer script, but left it in others.
<infinity> roaksoax: All start/stop stuff should be going through invoke-rc.d
<jhojho> Sarvatt: even hardy is faster http://pastebin.com/XrFUT8Zq
<jhojho> more usage of aes-128 than aes-256
<roaksoax> infinity: yes I am aware of that. But if you can figure out a way of not having it failing on the postrm when using invoke-rc.d, then please, provide a patch
<roaksoax> it is just not enough changing it to invoke-rc.d cause it will fail
<Eren> how can I delete a package without calling its prerm, postrm scripts?
<Eren> I've detected a problem with the package I'm working on. While upgrading the package, the new version adds user/group in preinst script, after the old package is removed and its postrm script is called. However, postrm deletes the user/group so the new package's postrm script cannot chown some directories
<JontheEchidna> Eren: I've no idea if this is safe, but I suppose you could comment out the contents of the script by editing it in /var/lib/dpkg/info/
<slangasek> roaksoax: why are you calling invoke-rc.d in the postrm?  Stopping services is a prerm operation
<Eren> what's a common practice for user/groups in ubuntu?
<Eren> "if needed, add user/group and leave forever?"
<tumbleweed> Eren: yes. removing users and groups is problematic. There could be files owned by them
<PaoloRotolo> hi all!
<sladen> danjared: gcc -o helloworld helloworld.c
<infinity> roaksoax: Eh?  How will apache2ctl work, but invoke-rc.d fail?
<infinity> roaksoax: I'm not suggesting you remove the guards to make sure /etc/init.d/apache2 and invoke-rc.d exist or anything, just that you stop invoking apache2ctl directly.  And given how hard it is to have apache2ctl installed without /etc/init.d/apache2, I'm curious how it fails.
<slangasek> oh, it's postrm because it's a reload command, right ;)
<infinity> slangasek: Probably.  I've already mostly forgotten. :P
<infinity> slangasek: My objection is that the postinst and postrm both had [ -x apache2ctl ] || [ -x invoke-rc.d ] (ish) logic, and the postinst was fixed to stop being silly, the postrm wasn't.  I can't quite sort out why.
<slangasek> right
<alabd> Good day all , my home partition was full and seems my laptop has been turned off cause of battery lack , after booting again ubuntu and while logging in my user , it return an error that "could not update /home/alabd/.ICEauthority ", , now there is free space and permission of the file is 777 , but error remains ...another problem ocurred is that it adds  /home/alabd  to /bin/ address like this >  alabd@alabd:~$ ping bash: /home/alabd/bin/ping: cann
<ikonia> alabd: this is not a support channel
<ikonia> alabd: as you know
<alabd> any opinion ?
<ikonia> alabd: this is NOT a support channel
<ikonia> alabd: do you understand yes/no ?
<Nafallo> hmm. my mini does not like -proposed at the moment.
<Nafallo> I've got lots of flickering all over the screen.
<Nafallo> I think I'll just revert to a previous snapshot, because this is painful.
<Nafallo> brb
<Nafallo> hrm
<Nafallo> apt-btrfs-snapshot set-default is broken...
<roaksoax> infinity: invorke-rc.d apache2 restart --> http://paste.ubuntu.com/898444/
<roaksoax> infinity: invoke-rc.d apache2 reload --> http://paste.ubuntu.com/898446/
<roaksoax> infinity: /etc/init.d/apache2 restart --> http://paste.ubuntu.com/898447/
<roaksoax> infinity: all of the above, failures
<sabdfl> smoser, cloud-init is lovely stuff
<roaksoax> infinity: apache2ctl restart --> http://paste.ubuntu.com/898451/ --> success!
<roaksoax> slangasek: I'm not stopping a service in the postrm in cobbler. apache2 needs to be installed after purging cobbler as cobbler symlinks config for apache2, so when removed, it needs to restart as the configs are gone
<Daviey> Anyone know if live-build supports putting the full binary in an intiramfs, rather than dependant on an external disk image?
<infinity> roaksoax: Looks like it just needs a >/dev/null
<infinity> roaksoax: Because it's taking the output of the init script as debconf input.
<infinity> Daviey: I'm not sure I understand the question.  You want to build an initrd, and then throw away the rootfs (easy), or make the rootfs an initrd (live-build doesn't make initrds, initramfs-tools does)?
<infinity> roaksoax: Or you need to stop debconf before you restart the webserver.  Take your pick.
#ubuntu-devel 2012-03-25
<roaksoax> infinity: cool, thanks for the info I'll try either
<roaksoax> s/either/both
<smoser> sabdfl, thanks.
<chelz> is there anything like a preview release of beta 2 that is bootable? (besides beta 1)
<chelz> the daily builds i'm guessing aren't guaranteed to boot
<ScottK> chelz: They aren't guaranteed, but AFAIK should be pretty good.
<ScottK> I booted yesterday's dailies just fine.
<chelz> ah alright. is there any archive of previous daily builds so i could try older ones if the latest doesn't work?
<ScottK> Yes.  If you look at cdimage.ubuntu.com and the directory with the type of image you want, you'll see a few days worth.
<chelz> ScottK: ahh neat, thanks
<ScottK> You're welcome.
<PaoloRotolo> Hi all!
<tumbleweed> bdrung: why did distro-info FTBFS? it test built for me...
<tumbleweed> ah, I probably wasn't using distro-info-data 0.7
<bdrung> tumbleweed: year 2038 bug on i386. i will fix it
<tumbleweed> bdrung: ah :)
<erguerghii> Hello*
<erguerghii> I would like to report a bug, because I can't use Launchpad and Apport doesn't work.
<jelmer> erguerghii: what about launchpad isn't working?
<jelmer> (you might want to talk to us in #launchpad, that's a more appropriate channel than #ubuntu-devel)
<erguerghii> jelmer: Just because I already have a account and I lost the old password and e-mail, and I want not to create a new account :/
<erguerghii> ok for #launchpad
<dr3mro> I know basic vala GTK / GLADE  and good experience in python GTK .. but I need to focus on one programming language to master it as I  take it as hobby only and I work as a physician but enjoy programming when I have some little free time in my vacation.... so do you suggest me continue the vala way or go python way .. for the future ot ubuntu develeopment what will be most widely used vala or python ??
<ScottK> jelmer: Do we want to sync evolution-mapi from Debian?
<jelmer> ScottK: not as-is, as unstable has a newer openchange that is incompatible with the current version of evolution-mapi in sid
<ScottK> jelmer: OK.  Do we want to update samba4/openchange/evolution-mapi before release?
<jelmer> ScottK: ideally, yes (probably would have to include ldb too though).
<ScottK> OK.
<ScottK> Could you prepare an FFe that explains what's needed?
<ScottK> That seems like an area where having the latest crack for release is generally a good idea.
<jelmer> ScottK: Yeah, I agree
<ScottK> If you could put that together, it would be helpful.
<jelmer> I've been holding off on that mostly for (irrational?) fear of having to deal with a large number of FFe and limited spare time
<jelmer> *FFEs
<jelmer> I'm happy to prepare the FFes though, and at least try.
<ScottK> Make it one bug that explains them all together.
<ScottK> Since it's interlinked it makes more sense to review it that way anyway.
<jelmer> ok
<Bluefoxicy> what do I do if reproducing a bug is doable with copyrighted content?
<Bluefoxicy> on VLC I can watch Yu Yu Hakusho rip in english
<Bluefoxicy> in Totem it plays in Japanese
<Bluefoxicy> I found the sound track thing in totem, but when I switch to English it plays music, and when someone talks it mutes all audio until they shut up
<Bluefoxicy> obviously, totem or gstreamer has no idea how to handle multiple audio tracks...
<Bluefoxicy> ... also obviously I can't just attach non-distributable copyright material to bugs o.o
<JanC> Bluefoxicy: I'm pretty sure that in most countries providing copyrighted content (which you have a legal copy of) directly to a developer (so not attached to a public bug report) for debugging purposes is fine
<JanC> Bluefoxicy: alternatively, provide a very short "citation"?
<JanC> Bluefoxicy: is it supposed to play multiple audio tracks in parallel?
<Bluefoxicy> JanC: no it has English and Japanese voice acting for different markets
<JanC> Bluefoxicy: hm, I've seen files with multiple audio tracks and apart from having to choose the right one manually (as Totem doesn't seem to be very clever about that) it always worked for me (not really tested on precise though)
<lifeless> barry: mailman, storm, datetime
<lifeless> barry: are you using postgresql ?
#ubuntu-devel 2013-03-18
<jbassett> Hello
<jbassett> I have a suggestion for Ubuntu interface, is this the right place to put it forward?
<jbassett> A user has an external monitor on a laptop and generally only uses the external monitor when at home, so turns off the laptop screen using the Ubuntu Displays interface.  They have found that unplugging the external monitor in order to wander elsewhere in the home for example, does not automatically reactivate the laptop screen.  In such a use case I would have expected this to have been the case.  I would ther
<jbassett> efore recommend such addition or even a checkbox in the Display area to facilitate the toggle of this feature on or off.
<sladen> jbassett: it's more likely a particular hardware in a particular laptop causing this behaviour at a lower level
<ScottK> TheMuso: Could you have a look at Bug #1127461 ?  It's causing enough problems it's getting blogged about on Planet KDE.  The recommended solution is uninstalling qt-at-spi.
<ubottu> bug 1127461 in qt-at-spi (Ubuntu) "qt-at-spi crash in Krita and other applications" [Undecided,New] https://launchpad.net/bugs/1127461
<TheMuso> ScottK: Right, I'd say the solution for raring at least is for you to stop shipping qt-at-spi, as the Qt accessibility code for QT4 is no longer maintained, given the move to Qt5.
<TheMuso> But I'll take a look.
<ScottK> TheMuso: Thanks.  I''m particularly concerned about precise though.
<TheMuso> Ah right.
<ScottK> The issue, as described in the blog post I saw, affected people in Unity sessions as well.
<TheMuso> RIght.
<ScottK> TheMuso: I checked and it's not in the Kubuntu seeds, but it is in Ubuntu desktop seed for raring.
<ScottK> Thanks for looking into it.
<TheMuso> ScottK: Right, a result of people using KDE apps in general. I'll see what I can do, no promises as I am unfamiliar with the code base. Hopefully newer code in the qt-at-spi git repo fixes, it, but I doubt it.
<TheMuso> np
<ScottK> Thanks.  I pinged you since I saw you did the last upload ...
<TheMuso> Fair enough.
<pitti> infinity: udev-acl conditional> splendid, thank you!
<pitti> Good morning
<dholbach> good morning
<pitti> stgraber, slangasek, ScottK: I followed up to bug 1153224 with a current status, FYI
<ubottu> bug 1153224 in systemd (Ubuntu) "[FFE] Move to logind for session tracking" [Wishlist,New] https://launchpad.net/bugs/1153224
<pitti> NB that I won't be totally disappointed if you say "not for raring"; I'm mostly pushing for a decision now to see how to go on with this
<pitti> (but I think the desktop team and even more so the GNOME Ubuntu flavor teams may want this more than I do)
<dholbach> pitti, can you reject texlive-base_2012.20120611-5~12.04_source.changes please - it was meant to go my ppa... O:-)
<pitti> dholbach: *zap*
<pitti> *splatter*
<dholbach> thanks pitti
<tjaalton> is the consolekit/logind migration complete now?
<pitti> tjaalton: no, still waiting on above FFE
<tjaalton> pitti: ok, just wondering if jbicha is/was using some ppa with it that might cause bug 1156074
<ubottu> bug 1156074 in xserver-xorg-video-intel (Ubuntu) "[raring] after updates, i965 driver won't load" [Undecided,New] https://launchpad.net/bugs/1156074
<pitti> could be, following up
<tjaalton> I added a question, refresh if it wasn't there yet :)
<pitti> ah, I added a similar one
<pitti> but it's not a PPA any more actually, you can just use the universe package
<pitti> cjwatson: FYI, I committed your aptdaemon updates to bzr, thanks for those! I also added the missing pep8 test dep in bzr now, and looking at the other failed test
 * pitti fixes the three PEP-8 violations upstream
<mardy> tvoss: hi! Are you subscribed to the ubuntu-phone ML? I'd like to start a topic there about how implementing the keyring on the phone/tablet, and I think that your participation would be very important :-)
<tvoss> mardy, I'm subscribed, yes.
<tvoss> mardy, I think lool should be involved with the discussion, too. Perhaps explicitly list him as recipient?
<tvoss> lool, are you subscribed to ubuntu-phone?
<lool> tvoss: yes
<tvoss> lool, thx
<LyzardKing> I need help with the ubuntu-sdk
<LyzardKing> When I run the tutorial  I get errors regarding like file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/Toolbar.qml:112: TypeError: Cannot read property 'visible' of null
<LyzardKing> and other similar ones
<dholbach> LyzardKing, you might want to ask in #ubuntu-phone or #ubuntu-app-devel
<LyzardKing> ok
<cjwatson> pitti: thanks
<cjwatson> pitti: I think I looked at bzr and it was just an auto-import; I must have been looking at the wrong branch
<pitti> debcheckout / Vcs-Bzr: are right
<pitti> anyway, I can reproduce the "debian-security/nonfree" failure in a VM
<pitti> it works on my normal workstation
<mlankhorst> debcheckout? awesome
<ogra_> oh, wow, multiarch on my 12.04 desktop fails miserably if i add armhf
<ogra_> (apt-get update chokes on security.ubuntu.com)
<lool> pitti, cjwatson: woot, should Mark's proposal be on the techboard agenda for today?
<pitti> lool: yes, I think it should
<lool> pitti, cjwatson: https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html that is
<cjwatson> Yeah
<cjwatson> pitti: ah, my bad for trusting my old checkout :)
<lool> added, thanks
<pitti> bdrung: FYI, uploading libsoxr to fix autopkgtest failure
<bdrung> pitti: thanks. i will forward your patch upstream.
<pitti> bdrung: danke!
<bdrung> bitte :)
<jamesh> pitti: I was moving some tests for an app over to using your dbusmock library, and found it was leaving dbusmockobject processes hanging around.
<jamesh> pitti: the docstrings imply that these processes should automatically exit when the bus they connect to goes away, so is this a bug?
<pitti> jamesh: yes, that's a bug
<jamesh> pitti: okay.  I added explicit terminate()/wait() calls as the dbusmock examples do.  So I was wondering if it was a code bug or a docs bug
<pitti> jamesh: they should listen to their attached bus going down and terminate themselves
<pitti> jamesh: yeah, the examples do that manually indeed, but automatic termination sounds nicer
<henrix> @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: henrix
<jamesh> pitti: I filed https://bugs.launchpad.net/python-dbusmock/+bug/1156561 so it won't be forgotten
<ubottu> Launchpad bug 1156561 in python-dbusmock "DBusTestCase.spawn_server() says spawned daemon will exit when bus closes, but process is left behind" [Undecided,New]
<pitti> jamesh: thanks
<melodie> hello
<melodie> cjwatson I just read what you told me last night about the dangling symlinks. I will try to give an example, and I was not from outside chroot but once inside then in the live in virtualbox, and after that in the installed os in virtualbox.
<pitti> sl-modem-dkms has failed to build for quite a while, as exposed by the ubuntu-drivers-common autopkgtest
<pitti> do we still actually care about this one?
<lool> pitti: I have an intel graphics card and updated earlier this morning, I have 175-0ubuntu24 and I get LP #1156074
<ubottu> Launchpad bug 1156074 in xserver-xorg-video-intel (Ubuntu) "[raring] after updates, i965 driver won't load" [Undecided,Incomplete] https://launchpad.net/bugs/1156074
<pitti> lool: are you running standard raring with consolekit or logind?
<lool> pitti: actually, not sure it's the exact same bug
<lool> pitti: I've rebooted and I'm now getting relatively low res graphics
<pitti> lool: do you have an acl on /dev/dri/card0 ?
<lool> but glxinfo works
<lool> yes
<pitti> ok, so not the same bug
<lool> and I have facl permission on it
<pitti> well, at least the one above said it was due to having no ACL
<lool> I have consolekit but not logind
<xnox> pitti: i'd say we do care about sl-modem-dkms, but it often lags behind linux kernel & debian patches it only up to debian's kernel, which is usually less than ours....
<pitti> xnox: there's even a bug for it, but I wonder if I should keep ubuntu-driver-common's tests fail eternally for this
<pitti> I guess that autopkgtest should move to sl-modem rather
<xnox> pitti: dkms FTBFS tests should be all in each dkms module package. I guess ship a test script in the dkms module, and add/symlink it in each -dkms package?
<lool> apparently, xrandr believes I have a screen connected when I dont
<xnox> pitti: ... or with some jenkins magic auto-add them the way autopkgtests are added?
<pitti> xnox: that'd be possible, yes; I also have some test in u-d-common to detect that sl-modem is necessary, but that one could drop the actual installation
<xnox> pitti: /me ponders about dh_installdep8 which would detect and add typical tests (e.g. initctl checkconf for all upstart jobs, dkms module FTBFS, abi-compliance-checker)
<pitti> tseliot: so we have a nvidia-experimental-304 AND nvidia-304? same with -310?
<tseliot> pitti: do you mean in raring?
<pitti> tseliot: as nvidia-current isn't what it used to be any more, I'm adjusting u-d-common's autopkgtests and wonder which versions we shoudl cover
<pitti> tseliot: yes
<tseliot> pitti: I don't remember if I'm doing this already but ideally nvidia-experimental-304 should be a transitional package of 304 (or maybe 304-updates), same as with 310 and its experimental flavour
<pitti> apparently not
<pitti> also, we have a nvidia-313-updates, but no nvidia-313, is that intended?
 * pitti adds -310 to autopkgtest
<tseliot> pitti: ok, I'll deal with the transitional packages this week. Furthermore, 313 is not an LTS series, so it won't get a non updates flavour
<pitti> ok, so I'll just add a test for 313-updates
<tseliot> right
<melodie> cjwatson in the installed version, in Virtualbox, here are the results for "find -L /usr -l", the for /etc then for /var:
<melodie> http://pastebin.com/0cjYFLv2
<melodie> http://pastebin.com/Bim1Mk3m
<melodie> http://pastebin.com/D4kBPDMQ
<melodie> I will start the live version in vbox just now and do the same to compare
<mlankhorst> for MRE's and backports of those MRE's to the lts-stack, do I need to run piglit for both on all hardware, or is a smoke test for the lts-stack enough?
<cjwatson> melodie: ah, OK; well I suppose you could clean up the help symlinks, but that will just mean that if people install the langpacks later then they won't get localised help whereas otherwise they might have done
<cjwatson> i.e. it's intentionally breaking stuff for the sake of a few inodes, which is rarely worth it
<cjwatson> Some of the /usr/share/doc/ ones are probably bugs
<cjwatson> No idea where /usr/lib/pkgconfig/python2.pc comes from, I don't have that here - but probably a bug
<melodie> cjwatson this is what I thought (languages sake) when I saw what the major number of lines were : not worth trying to remove them
<melodie> perhaps ?
<cjwatson> Indeed, I don't think this is worth even the amount of time spent discussing it so far :)
<cjwatson> It will have only a negligible effect on the system
<melodie> cjwatson yes, but I could not know before trying to discover why it was there
<melodie> thank you very much
<cjwatson> It might be worth tracking down why some of the other symlinks (i.e. not the obvious localised ones) are dangling
<cjwatson> libnss_db.so is odd too
<melodie> it might be there after I removed some packages to priviledge others
<melodie> I look in my install to see if I find a clue
<melodie> in my install it is also a dangling link and it points to /lib/i386-linux-gnu/libnss_db.so.2
<xnox> some of the automatic package mangling-foo was spotted to generate broken symlinks in /usr/share/doc in the past. Also it seems like a few things are "waiting" on language packs, if all of them were installed most of gnome-docs would be fine.
<xnox> python2.pc looks like a bug it should be python.pc only.
<melodie> hi xnox, is this likely to lead to improvements ?
<xnox> melodie: no.
<melodie> not important enough ? :)
<melodie> ok, I go work on something else thank you
<xnox> melodie: installing all language packs, will just use up a lot of disk-space. These documentation dangling symlinks is actually an optimisation, we bundle all translations in language-packs, such that one doesn't carry ~ 4GB of translations to languages one does not speak.
<xnox> (~4GB of translations can be stripped from default Mac OS X installation last time I did it)
<melodie> xnox I was asking about the two dangling links which should not be there and which you consider as probable bugs
<melodie> I know all language packs can't be inside a 700 MB max iso
<xnox> melodie: the only "win" will be a couple of bytes saved from the entries in the file system. I'd think one would win more by removing a single /usr/share/doc/$package/changelog.Debian.gz
<xnox> (which was proposed to do by default in the past)
<melodie> and it seems these broken links don't even take any space
<xnox> melodie: yeah broken links are almost zero cost in terms of disk space.
<melodie> in my system, python2.pc points to -> python-2.7.pc
<melodie> which does not exist
<melodie> it is is Precise
<xnox> melodie: yeap, cause it's multiarched.
<xnox> see /usr/lib/x86_64-linux-gnu/pkgconfig/
<melodie> xnox ok, then I suppose it is normal
<melodie> I don't have a 64bits system here
<bdrung> xnox: re debian bug #703323, can you update the man page?
<ubottu> Debian bug 703323 in devscripts "devscripts: [wrap-and-sort] add trailing comma" [Wishlist,Open] http://bugs.debian.org/703323
<xnox> bdrung: *sigh*, yes.
<bdrung> xnox: i am merging the ubuntu change back to debian, but the tests fail in experimental.
<pitti> there, 9 autopkgtest failures less than than this morning
<xnox> bdrung: i had no test-failure here. Is it related to ubuntu's switch to python3, which is not possible in debian yet?
<xnox> (here as in ubuntu)
<bdrung> xnox: yes. the python3 switch is possible in debian too. i poked the file maintainer to add python3 support and he did it.
<bdrung> xnox: http://paste.debian.net/242557/
<xnox> bdrung: interestingw, will look into it later.
<bdrung> xnox, tumbleweed: the test suite is broken: http://paste.debian.net/242561/
<bdrung> the test fails even if the timeout is set to 10 mins.
<xnox> bdrung: what if you revert my adding a new option? or is that even with /bare/ devscripts without my patch?
<bdrung> xnox: i haven't applied your patch. so it's not the fault of your patch. you can try building devscripts 2.13.0ubuntu1 on experimental with the same result.
<xnox> bdrung: fun.
<bdrung> tumbleweed: do you object to add a copy of devscripts.logger to ubuntu-dev-tools?
<xnox> bdrung: i'm for it. that means dropping python2 module from devscripts on ubuntu side and syncing ubuntu-dev-tools from debian once again =)
<xnox> i mean the devscripts.logger delta will go away, and we can switch to python3 on debian side as well that s.
<hallyn> all right so to get openbios-sparc, i guess i'd need to look at gcc-ppc-linux-gnu and get the analogous for sparc
<ogra_> janimo, sad, you arent in #ubuntu-release ... you just missed the dead of cdimage-private :)
<janimo> ogra_, I got a mail from LP with the WIs set to DONE so did not miss it :)
<ogra_> oh, there were still WIs ?
<ogra_> haha
<janimo> ogra_, yes, there was an old blueprint
<ogra_> yeah, i was looking for it but couldnt find it
<janimo> ogra_, https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-image-build-tools
<ogra_> ah, there it is
<ogra_> i guess i wasnt subscribed
<ogra_> i searched in my mail
<cjwatson> I happened to run across it the other day and thought I might as well claim them
<bdrung> xnox: okay. i will do that after the build failure ( http://paste.debian.net/242557/ ) is fixed.
<henrix> @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:
<lamont> bdmurray: around?
<lamont> update-manager -d tells me: The requested URL /ubuntu/dists/raring/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html was not found on this server.
<lamont> bdmurray: is that expected?
<jbicha> stgraber: could you upload a newer lintian version as suggested at https://lists.ubuntu.com/archives/ubuntu-release/2012-December/002140.html ? I noticed that my computer still had the old one installed
<stgraber> jbicha: I think the hope was that we would be able to sync from Debian and get something slightly higher than what we have in extra. I'd have to check what they have in Debian nowadays. Will try to do that once I'm done with my meetings
<bdmurray> lamont: that's from a quantal system?
<lamont> current quantal running update-manger -d
<lamont> quantal + security + udpates only
<bdmurray> lamont: okay thanks
<lamont> bdmurray: does it deserve a bug?
<psusi> smoser: it seems some work has already been done to accelerate d-i... it no longer uses debootstrap, but copies a pre debootstraped squashfs for the base install... scaling this up a  bit may get you to where you want for fastpath install... adding eatmydata for the subsequent part of the install took my total install time for 7m to 3m, how fast did you have in mind?
<bdmurray> lamont: no, I'll just try and fix it
<lamont> 0.192.4 had the file, 0.192.5 dropped the .html versions
<bdmurray> lamont: the file is really missing http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/
 * lamont finally notices that there is still an 'upgrade' button at the bottom of things
<lamont> bdmurray: it is in fact
 * lamont actually went and verified it on the master
<smoser> psusi, well,it is much faster, yes. and that avoids many dpkg -i.
<smoser> however, it still makes sense to use eatmydata for *all* dpkg during an install (squashfs just gets the "base image"), and then any additional packages are installed with dpkg.
<psusi> smoser: right.. I tested that and it dropped install time from 7m to 3m
<xnox> slangasek: why unionfs? =) we got overlayfs in nexus7 landing soon and heading upstream as well.
<psusi> scaling up the squashfs to contain more of a typical virtual install instead of just required/important packages might be a way to improve on it too
<cjwatson> it's the minimum subset of all the possible things that that image can install
<cjwatson> or was last I checked
<psusi> cjwatson: right... it's just required/important packages, i.e. what debootstrap used to install
<cjwatson> I know what it is - my point is that it can't be expanded without suddenly having to teach other bits of d-i about how to *remove* packages
<psusi> but you could add in more packages if you wanted to.. so maybe identify the set of packages that all cloud installs will want and throw them in too
<cjwatson> I started out with it larger and had to scale it back
<psusi> ohh, right.. adding packages means they basically aren't optional to install any more
<cjwatson> it could be expanded to standard if the server team decided to drop the minimal-virtual-machine install type
<cjwatson> (I think I discussed this with the server team at the time)
<psusi> or if you choose to do that, then fall back to debootstrap instead?
<cjwatson> can't, files aren't present
<psusi> ohh, wait.. the required and important packages have already been removed from the pool?
<cjwatson> from the CD image pool
<psusi> ahh... nice...
<cjwatson> also the bootstrap-base udeb isn't present
<psusi> wait.. what about a dual squashfs?  one with the base, and a second one with -standard?  then you just unpack the second one after the first, or not..
<cjwatson> if somebody can figure out how the heck to make it all work *shrug* - I think dropping the minimal vm install type is a much more rational use of time personally
<psusi> I agree
<xnox> cjwatson: psusi: well there are server images with squashfs containing everything pre-installed what is needed to become an openstack node and it's in use in the jenkins lab for automatic bare-metal deployment of openstack clouds.
<xnox> see qa talk from fosdem by james page.
<xnox> there is ongoing work to open up this method and make it more generic and less speciliased on openstack-only.
<xnox> it's the fastpath installer work.
<smoser> xnox, well, i'm not sure what jamepage said at fosdem.
<xnox> smoser: =)))))
<smoser> but the fast path installer largely overlaps with much of what d-i does.
<smoser> and doesn't use squashfs images.
<xnox> smoser: it was so fluid and so well rehersed everyone believed anything he was saying ;-)
<psusi> xnox: it sounded to me like the current proposal for fastpath is to reinvent a whole new installer, rather than modify d-i... I'm just pointing out that maybe modifying d-i would be better and doable ( and some work has already been done )
<slangasek> xnox: I'm using unionfs as a generic term here
<ogra_> xnox, slangasek, dont forget that we have to deal with (possibly old) android kernels when aiming for union/overlayfs
<bosyi> hi. i have problem in 13.04. after awaking from sleep notebook gets slow. mouse pointer move like with delay.
<bosyi> it's ok to ask here?
<ogra_> nexus7 should be safe though, we use the same in the desktop and touch images
<xnox> slangasek: ack.
<ogra_> but in general i think it will make porting for people problematic if we require huge kernel changes
<xnox> slangasek: ack.
<xnox> bosyi: no. #ubuntu+1 is a better channel.
<bosyi> xnox: thanks
<seb128> xnox, cjwatson: hey, is there any known issue with the installer and username pre-seeding?
<cjwatson> The only thing I've heard of that's related is bug 1155704, but I suspect that's a wider problem
<ubottu> bug 1155704 in Wubi "13.04 installer doesn't create user account" [High,Confirmed] https://launchpad.net/bugs/1155704
<seb128> cjwatson, http://ubuntuone.com/6g6zED1AQpXiDFmAL6qJ0H
<xnox> seb128: not that I know of, but u1 plugin started to fail for me with today's images.
<seb128> xnox, ^
<seb128> the username in the error is "root"
<seb128> where the entry has "jenkins"
<cjwatson> I certainly haven't changed anything near there in ages ...
<seb128> k
<cjwatson> Would need to see logs I guess, ideally debug logs
<seb128> could be a #qa issue
<seb128> cjwatson, thanks, I'm asking the #qa guys to come here to discuss it directly
<seb128> mmrazik is the one who got the screenshot
<seb128> but he doesn't have access to the logs apparently
<seb128> mmrazik, hey ;-)
<mmrazik> cjwatson: let me fwd the screenshot
<cjwatson> screenshots aren't logs :)
<seb128> mmrazik, I shared the screenshot
<cjwatson> seb128 already posted the screenshot
<mmrazik> great
<cjwatson> 17:46 <cjwatson> Would need to see logs I guess, ideally debug logs
<mmrazik> cjwatson: what are logs? /var/log/syslog?
<mmrazik> cjwatson: its going to be a bit difficult, though
<mmrazik> as the machine has no networking AFAICS and is in Lex
<cjwatson> /var/log/installer/syslog
<cjwatson> well, /var/log/syslog at this stage actually
<cjwatson> and /var/log/installer/debug
<mmrazik> nuclearbob: do you have access to any of those ^ ?
<cjwatson> feel free to come up with a way to reproduce the problem that doesn't involve jenkins in a remote lab ...
<nuclearbob> mmrazik: I can look at them over a kvm-over-ip and get screenshots, I'm trying to find a better way to get them on the machine
<nuclearbob> yeah
<nuclearbob> I can try the same preseed on a bm
<nuclearbob> *vm
<slangasek> hallyn: edk2 persistence issues> so step one is to figure out how to do a proper debugging build of ovmf, since I'm failing at that so far ;) any ideas?
<cjwatson> xnox: I'm still testing, but any opinions on http://paste.ubuntu.com/5625860/ and http://paste.ubuntu.com/5625861/ ?  It seems to have improved things for the ruby1.8 build, at least
<cjwatson> (As in it actually detects Tcl/Tk now)
<mmrazik> nuclearbob, cjwatson: I'll have the logs in a minute
<hallyn> slangasek: no.  but i need to learn about the upstream source and package, so i'll look into that.
<cjwatson> whoopsie dialog of the day: "Sorry, the application crash.jar has stopped unexpectedly"
<cjwatson> Ya think
<mlankhorst> :X
<mlankhorst> it didn't crash in the way it should, perhaps?
<cjwatson> I think it's part of the apport testsuite
<ev> poor whoopsie, always taking a bad rap for apport
<cjwatson> Yeah, my bad, had the wrong package that pops up annoying dialogs :)
<ev> cjwatson: everyone conflates the two :)
<mmrazik> cjwatson: /var/log/syslog: http://pastebin.ubuntu.com/5625877/
<tumbleweed> bdrung: no
<mmrazik> cjwatson: /var/log/installer/debug: http://pastebin.ubuntu.com/5625879/
<cjwatson> mmrazik: is it possible to start the machine with the 'debug-ubiquity' boot parameter?  things are a lot more informative that way
<mmrazik> nuclearbob: I actually don't know how to do that easily with utah, etc ^^^
<nuclearbob> mmrazik: adding -b debug-ubiquity to the utah command line should do it, I can try that as well
<mmrazik> nuclearbob: thanks
<mmrazik> I need to leave soon
<nuclearbob> recreating this on a VM doesn't seem to be working either, unfortunately and to nobody's surprise
<xnox> cjwatson: looks correct. as long as nothing drops out of main, like with my first defaults upload ;-)
<cjwatson> As in tcl-lib?  I think I avoided that trap
<infinity> xnox: If at first you don't succeed?
<xnox> cjwatson: yeah. I think you did it all correctly.
<cjwatson> xnox: I might wait until tomorrow morning to upload it, since I'm getting pretty tired and prefer to be fresh before hitting enter on this kind of thing.  But I do seem to have managed to climb up to the point where ruby-ffi builds, which was the original point of this yak-shaving exercise.
<jmleddy> cjwatson: hi there
<cjwatson> jmleddy: Finishing for the day as the above indicates.  Is it quick?
<slangasek> cyphermox: hmm, what needs "solved" wrt polkit/consolekit on the tablet for NM?
<cyphermox> slangasek: err, I don't know?
<slangasek> cyphermox: I ask because of the ongoing ck->logind migration discussion
<cyphermox> ok
<jmleddy> cjwatson: yeah, I was just wondering if you had an estimate for bug 967229
<ubottu> bug 967229 in plymouth (Ubuntu) "Text mode shown briefly with various "cryptic" texts when logging out or shutting down" [High,Triaged] https://launchpad.net/bugs/967229
<slangasek> cyphermox: oh; sergio just assigned a work item to you for it :)
<cjwatson> jmleddy: I thought that had been handed over to bdmurray
<cyphermox> ok
<cyphermox> can you link?
<jmleddy> slangasek: particularly the part about starting plymouth before lightdm stops
<cjwatson> It came up a foundations meeting or two ago
<jmleddy> cjwatson: yes, I think he is working on it
<cjwatson> I haven't heard anything about progress
<cjwatson> bdmurray: ^- ?
<slangasek> jmleddy: hrm, you aren't mixing up me and cjwatson, are you? :)
<jmleddy> slangasek: oh, perhaps o_O
<slangasek> sweet
 * slangasek dyes his hair
<jmleddy> slangasek: I though he jumped in
<cjwatson> He's the talented one, I'm just ruggedly handsome
<bdmurray> slangasek's last idea did not improve the situation
<jmleddy> haha,
<slangasek> bdmurray: improved vs. what?
 * cjwatson goes to try to scavenge dinner, in a hunter-gatherer kind of way
<bdmurray> I still see messages when shutting down
<slangasek> jmleddy indicated that clearing the VT before lightdm starts takes care of some of it
<jmleddy> bdmurray: slangasek: basically a manager asked me for a date when we would have a complete fix (ie, plymouth starts before lightdm stops)
<slangasek> and clearing the VT /after/ lightdm starts will take care of more of it
<jmleddy> huh, I had success with turning the text color black and clearing the vt
<slangasek> bdmurray: so from my POV, this is a per-se correct change to the lightdm job
<slangasek> well, turning the text color black is a workaround
<jmleddy> agreed
<jmleddy> but yeah even just doing a clear > /dev/tty7 fixed it for the startup text
<jmleddy> still saw services shutting down though
<bdmurray> right, and that is what I still see
<slangasek> bdmurray: so we do need to clear at boot, even though that doesn't solve the full problem for shutdown; can you drive that piece forward on lightdm?
<jmleddy> bdmurray: okay, that makes more sense
<slangasek> for shutdown, I think we need to change things so that the plymouth /daemon/ starts before lightdm stops, so that we get the console indirection in place, but that we only start the plymouth /splash/ after lightdm exits
<bdmurray> slangasek: right clearing on boot solves logout and log back in issues
 * slangasek nods
<jmleddy> slangasek: how hard is that to change?
<slangasek> jmleddy: it's easy to change, hard to get right
<slangasek> the ordering of all of this is fiddly and the architecture is not fully documented
<jmleddy> okay
<slangasek> but basically, the plymouth upstart jobs need to be split differently
<jmleddy> I think as long as we're actively working on it I can hold off the OEMs
<bdmurray> I believe the ordering is the last thing we'd talked about and the change had no effect
<slangasek> bdmurray: which change?
<jmleddy> but ideally they'd like to have a target for when this will be fixed
<infinity> I suppose there's a reason why the old "start the splash from the DM on shutdown" method that we used eons ago doesn't work?
 * infinity has always been a bit annoyed that this used to be a solved problem until it was all torn out.
<slangasek> infinity: you still have to stop the X server first
<infinity> Is that actually true in a KMS world?  The kernel is perfectly happy with writing my oopses to the same FB as my X session.
<infinity> s/oopses/panics/
<slangasek> infinity: the X server has to be stopped before you can start the plymouth splash.
<slangasek> because only one process can own the VT at a time
<slangasek> and it's important that the VT have an owner
<infinity> Well, yes, I get what you're saying.  I'm arguing that if that's true, it may be a design/implementation issue with plymouth, not actual architectural fact.
<bdmurray> slangasek: http://pastebin.ubuntu.com/5626006/
<infinity> Anyhow, that same limitation should have been true with gdm and usplash too.  How did my old splash-down crap handle it?
<infinity> Oh, I didn't use the same VT as X, I bet.
<infinity> So, I did a chvt, then splashed away.
<slangasek> now, this doesn't mean that X has to switch it into text mode when it exits, but in most cases it *is* important that X switch back to text mode, so implementing this correctly means changes to the X server and lightdm
<jmleddy> infinity: to me, that's the ideal solution, put the kernel console to a different vt
<slangasek> switching to a different VT still implies a race
<infinity> jmleddy: This is what we used to do.  There's exactly one valid and cool argument not to, which is panics.
<slangasek> it doesn't matter which VT you're on if that VT is in text mode (however briefly in theory) and things are writing to it
<jmleddy> infinity: yeah, that's what I was worried you would say ;)
<slangasek> the point is that we should *not* have services writing to the desktop's console on startup/shutdown except in the case of errors (panics)
<infinity> slangasek: You bind your splash to a VT, then chvt to it.  In that order.
<infinity> slangasek: But yes, we shouldn't have output in the first place, I agree.
<slangasek> bdmurray: so given that didn't help, can you post a screenshot to the bug of what output you were still seeing?
<bdmurray> slangasek: sure
<bdmurray> slangasek: added
<slangasek> bdmurray: thanks; that's more or less consistent with the remaining race condition I expected (although I don't know why acpid is talking to the console since it's an upstart job that doesn't have 'console' set), I think the next step is to think about changing /etc/init/rc.conf to no longer be 'console output'
<slangasek> bdmurray: but I think we need to coordinate this with the server team to make sure we don't disrupt that case
<slangasek> smoser: what's the right answer for where init script and upstart job start/stop messages should be going on the server images (and cloud in particular)?
<smoser> slangasek, i dont know what the right answer is.  cloud-init jobs writes with 'console output'.
<smoser> but even that is proxied through plymouth.
<slangasek> smoser: I'm not asking about the mechanism, I'm asking about where you want it to show up
<smoser>  /dev/console is right.
<slangasek> ok
<smoser> the fact that that is busted in some cases is something that has to be fixed.
<slangasek> yep
<smoser> slangasek, do you have thoughts on a more appropriate place?
<smoser> (other htan /dev/console)
<slangasek> no, my opinion doesn't matter :
<slangasek> :)
<slangasek> this is for the server team to decide where they want these messages to go
<lool> cjwatson, pitti: Sorry, where/when is the techboard meeting?
<lool> fridge suggests it's either now or was an hour ago on #ubuntu-meeting, but nothing there
<stgraber> lool: in an hour in #ubuntu-meeting
<mdz> my calendar says now
<stgraber> lool: the meeting time is 21:00 London time
<ogra_> fridge too
<mdz> bloody time zones
<lool> thanks
<mdz> who is chairing? I can't find the minutes and have a funny feeling that it's my turn
<stgraber> mdz: hehe, I actually just went to the agenda to confirm myself as I wasn't sure with the DST change :)
<ogra_> lol, then you picked a really bad one to chair
<stgraber> mdz: you're chairing
<stgraber> mdz: or so we said at the end of last meeting
<mdz> ok
<mdz> who chaired that meeting? they didn't send out minutes yet
 * ogra_ humms .... ".... rollin, rollin, rollin .... "
<cjwatson> My calendar says now, but it's DST confusion month
<cjwatson> An hour from now works better for me, but meh
<mdz> I have a conflict but I think I can juggle it
<stgraber> mdz: kees was the last chair
<stgraber> cjwatson: I remember us deciding to pin it to whatever timezone London happens to be on, but I guess the fridge is still tied to some other random timezone...
<ogra_> fridge says GMT at the bottom
<stgraber> ogra_: right, so that's wrong ;)
<mdz> why is the meeting scheduled for so late in the day? seems odd given our composition
<cjwatson> Who the hell knows what calendars are going to do
<ogra_> heh
<stgraber> mdz: not sure, but I'm not particularly looking forward to going through the whole doodle mess again if we can avoid it ;)
<cjwatson> I think Keybuk had a problem with the earlier time when he was on the board
<cjwatson> Anyway, if we're doing it now I'd like it if we could start :)
<stgraber> anyway, it'll move an hour earlier for all the US+Canada folks by next meeting as Europe will have its DST change by then too (that's assuming I'm not doing DST backwards, which I've been known to do on occasion, damn I hate that thing)
<mdz> I've changed the Google calendar to schedule it for 2100 London time going forward
<mdz> including today
<cjwatson> Aha
<cjwatson> yay
<stgraber> mdz: nice, thanks!
<sarnold> London Time isn't the same as UTC.
<cjwatson> I shall wander off for 45 mins then
<cjwatson> sarnold: We know
<sarnold> okay :)
<stgraber> mdz: good to know you've got power over that Calendar. I always had to randomly poke people within Canonical until I find someone had access
<cjwatson> That is the point
<sarnold> (incidentally, having a UTC clock widget in our phone would be keen. :)
<mdz> stgraber, I've always set it to "guests can modify"
<stgraber> sarnold: we're using London as a UTC+DST so we don't need to re-schedule twice a year for DST
<stgraber> mdz: ah, cool, was I a guest? I can't remember seeing an invite for it until just about now when you changed it :)
<sarnold> stgraber: aha :)
<lool> you guys should rather have it at 2200 Paris time, it would feel less rainy
<mdz> stgraber, you were already a guest when I looked at it today
<stgraber> I don't know what's that whole thing about London and rain, I can't recall ever seeing any rain over there! (yeah, I've been there THOSE two weeks)
<stgraber> mdz: hmm, okay
<mdz> you should have an "edit event" link when you look at it
<mdz> (as opposed to "more details")
<lool> cjwatson: bzr branch lp:ubuntu-cdimage: bzr: ERROR: No such file: 'buildlive-20130315144326-j37epwgp79kvsxht-1'
<stgraber> mdz: ah, I know why, I think Google can't cope with the fact that my @ubuntu.com isn't hosted on gmail
<lool> bzrin surgery needed
<mdz> stgraber, ah, yes
<mdz> it only works if your address is associated with a gmail or google apps account
<mdz> stgraber, let me know if you have another address I should add
<lool> stgraber: ah so you had snow I guess?  ;-)
<bryce> btw I posted an mre proposal for xserver to the tb list; it's in the moderation queue
<stgraber> lool: I wish ;) it was just grey and cold though I vaguely remember being there one day where we could actually see the sun ;)
<slangasek> awe_: ping
<awe_> slangasek, pong
<slangasek> awe_: hey, so cyphermox tells me NM (or rather, consolekit) isn't happy on the phablet snapshots, and that there's some different plan for dealing with this on Mir
<slangasek> awe_: I'd like to make sure we're on the same page regarding what that "different plan" is, given that we have a migration from ck to logind in flight
<awe_> you are correct sir
<slangasek> and logind is *not* tied to X, and I was expecting we would be converging around logind
<awe_> we disabled polkit & session tracking due to the lack of X
<awe_> was a bit of a short-cut
<awe_> slangasek, ricmm has an action item on the Mir blueprint, but I left an item for cyphermox to coordindate with the Mir team
<slangasek> ok
<slangasek> ricmm: ping
<slangasek> :)
<cjwatson> lool: hmph
<awe_> slangasek, I think their plan involved logind too.  ;)-
<cjwatson> I might repush - had a stacking problem earlier
<slangasek> awe_: I hope so, but want to confirm ;)
<awe_> no prob
<awe_> slangasek, we need to schedule a power mgmt session later this week.  Who on your team should invite?
<slangasek> awe_: "power mgmt" being rather broad, can you be more specific?  there isn't currently anybody on Foundations assigned to power mgmt, unless they've been taking WIs on the side that I haven't seen yet ;)
<awe_> power mgmt plumbing on ubuntu touch
<awe_> ( or lack thereof )
<slangasek> awe_: in practice, I think pitti is the domain expert on our PM stack
<slangasek> awe_: we can certainly participate, but I think you'll find it's more important to have pitti there
<awe_> ack
<awe_> if you think of someone else you'd like to be involved, let me know.  Will probably shoot for Wed/Thur
<ricmm> slangasek: pong
<cjwatson> lool: try again now
<slangasek> ricmm: hi, question came up regarding NM session management and the future of consolekit wrt Mir
<slangasek> ricmm: it's been implied that there will be "a solution" for session management in Mir, and I want to make sure it's aligned with the work we're doing to replace ck with logind
<ricmm> slangasek: right, we did take a shortcut before demo by disabling session tracking, pk and ck
<ricmm> I have a WI to bring a discussion forward about the convergence of Mir+lightdm to plug the holes in ubuntu-touch
<ricmm> I didnt think of it in terms of CK -> logind at the time but it can be all part of the same
<ricmm> we can either leave mine or your action item and just do a bigger discussion with tvoss and others
<ogra_> awe_, slangasek, i'm not volunteering for WIs, but have some experience with cpufreq governor stuff on arm, so i'l like to attend ...
<lool> cjwatson: woot!  thanks
<slangasek> ricmm: well, we are getting rid of ck and replacing it with logind; this solves the X dependency problem; so anything further that's needed for Mir should be limited to logind integration
<cjwatson> lool: Great.  Things can get a bit confusing if you switch the development focus branch around in an incautious order
<slangasek> ricmm: as long as we're on the same page, I don't think I need to be directly involved - I just wanted to make sure nobody was thinking in terms of NIHing something else
<awe_> ogra_, ack
<ricmm> slangasek: ok, I'll track this from the Mir side of things then
<slangasek> ogra_: +1
<slangasek> ricmm: perfect, thanks
<awe_> ogra_, do you remember who it was that did the analysis of the power code in gsd recently?  Was it seb?
<ogra_> awe_, i dont remember exactly, but i think jibel did some stuff there
<awe_> alright, I'll ping seb in the morning.
<xnox> awe_: there was seb, gemma, plars and pitti doing extensive power measurement & hacking at the n7-squeeze-it-down sprint week.
<awe_> thanks xnox!
<marga> I'm trying to debug a crash in gnome-screensaver.  I have the debug package and I have the core dump, but I my bt is still just ??... is there anything I can do to get more info>
<xnox> awe_: then based on their graphs there was a clear indication what to target, which the rest of us did.
<awe_> xnox, fyi, this conversation is more of an architecture discussion focused on Ubuntu Touch, than measurement/targets ( which are important too ).
<xnox> awe_: i was just observing =) but together they should be able to answer anything top->down and bottom -> up.
<ogra_> and i guess much of the data isnt relevant
<ogra_> since it was measuring desktop setups only
<ogra_> and apps there speccifically
<ogra_> -c
<awe_> xnox, sure... I think most of them are on my short list, but appreciated
<xnox> ogra_: yeah, android kernel has special hooks to measure on per app basis, which mainline does not....
<ogra_> well, and a totally different userspace
 * xnox is educated more about android kernels after recent lwn.net article about "what's the delta between android and mainline today"
<lindi-> marga: check /proc/$pid/maps to see which ELF file is mapped to the address where you see just ??
<marga> lindi-, this crash report was not created in my machine... Which pid would that be?
<lindi-> marga: ah, and you can't reproduce the crash?
<marga> Not likely... It's a gnome-screensaver crash that is triggered randomly after some amount of inactivity
<lindi-> marga: I'm bit unfamiliar with ubuntu crash report but there should be ProcMaps.txt?
<geofft> marga, have you played with apport-retrace?
<marga> geofft, retrace complains that the crash doesn't include a Package.
<marga> lindi-, yes, I do have ProcMaps
<geofft> you could try faking that file. :) but hmm, I'm surprised by that if it's actually in gnome-screensaver
<lindi-> marga: each line in ProcMaps has an address range, now just find out which file was mapped to that mysterious address where you only got "??" in the backtrace
<lindi-> marga: might be easier to explain if I'd have some concrete example at hand
<marga> ok, I think I found it.  It's a file in dconf-gsettings-backend.  Will install that debug deb and see if I get real info. Thanks
<marga> No, still ?? :(
<marga> The address is: 0x00007f45bc27415c. ProcMap says 7f45bc270000-7f45bc277000 is mapped to /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
<geofft> If you want entirely too much info, you can run objdump -d on that file (pipe to less, probably)
<geofft> and look at offset 0x415c within it
<geofft> on my quantal machine it's in g_io_module_query
<geofft> right after a call to g_queue_is_empty and a conditional jump
<geofft> which should be enough to find it in the source, if you're inclined.
<marga> Ok, this is precise so it's probably something else, but I'll take a look, thanks.
<lindi-> marga: if you think you have found the right place you can verify it by running "x/16i $rip" or similar in gdb and then compare the disassembly
<marga> Sorry, I really don't know what you are talking about now.
<lindi-> marga: the core dump has a copy of the memory. objdump -d shows what is on the disk. it's a good idea to verify that they match: there could be some memory corruption at play as well
<marga> Right
<marga> but what's x/16i and what's $rip ?
<lindi-> marga: x/16i is a gdb command that shows up to 16 instructions from the address that you give to it. $rip points to the current instruction on amd64
<lindi-> these are bit cryptic I admit, there's a "disassemble" command but it only works for functions I think
<marga> => 0x7f45bc27415c:	Cannot access memory at address 0x7f45bc27415c
<marga> That's why I get ??, I guess
<lindi-> marga: well, according to maps that should be mapped but maybe this is some apport thing I don't know about...
<marga> Yeah, I should probably do this with apport-retrace and not with gdb
<marga> but apport-retrace doesn't like that the package is missing :(
<marga> oh, I tricked it!
<stokachu> doko: ping
<bdrung> tumbleweed: no = you are fine with adding a copy of devscripts.logger to ubuntu-dev-tools?
<doko> stokachu, ?
<bdrung> tumbleweed: can you have a look at the bug in the testcase when building on experimental: http://paste.debian.net/242561/
<stokachu> doko: question about bug 778627 update comment #27, im not quite sure what kind of test i should write for validating "
<stokachu> A set of heuristics that reduce the number of times special characters
<ubottu> bug 778627 in bash (Ubuntu Precise) "In natty, bash completion now quotes shell variable references rather than expanding them" [Undecided,In progress] https://launchpad.net/bugs/778627
<stokachu>         such as `$' are quoted when the directory name is not expanded.
<stokachu> "
<stokachu> doko: do you have any recommendations?
<stokachu> only thing ive come up with is testing to make sure if multiple shell variables are used in readline that none of them are escaped
<xnox> stokachu: the description on the bug as it is now, is suffiently good for me to sponsor/upload this SRU.
<stokachu> xnox: cool i was just making sure i covered all your test cases
<stokachu> xnox: do you want me to subscribe the relevant teams or will you handle it now?
<tumbleweed> bdrung: no, as in no objection
<xnox> stokachu: the idea is that people who complain/notice this broken new bash, can be pointed to the bug description and they get sufficient information about what has changed, what are the symptoms, what needs configuring / changing to enable previous behaviour.
<bdrung> tumbleweed: okay. then i will go ahead and do it.
<stokachu> xnox: gotcha
<bdrung> tumbleweed: do you have an idea why the testcase fails on experimental? the timeout doesn't work correctly.
<tumbleweed> bdrung: what do you mean by "on experimental" ?
<stokachu> xnox: i went ahead and subscribed sponsors team
<stokachu> xnox: lemme know if you need anything else from me
<bdrung> tumbleweed: debian experimental
<tumbleweed> bdrung: but building for experimental is the same as sid, unless yuo have dependencies that can't be met in sid
<bdrung> tumbleweed: we need python3-file from experimental
<tumbleweed> bdrung: master doesn't. what branch is this?
<doko> stokachu, xnox, I'm not sure I'm the right person to ask for a SRU-compatible testcase ...
<bdrung> tumbleweed: master + http://paste.debian.net/242685/ OR devscripts from raring
<tumbleweed> ah. looks...
<bdrung> tumbleweed: and we have an unrelated test failure on raring: https://launchpadlibrarian.net/134570548/buildlog_ubuntu-raring-amd64.devscripts_2.13.1~daily%2Bbzr2631~raring1_FAILEDTOBUILD.txt.gz
<stokachu> doko: no worries i think its sorted
<tumbleweed> bdrung: builds for me, with that patch
<bdrung> strange
<tumbleweed> bdrung: also. that doesn't actually look like a timeout. but rather a syntax error, from using u'strings' with python < 3.3
<cody-somerville> I just tried to install today's daily for amd64 and it crashed and burned horribly. network-manager segfaulted in some dhcp related function when I tried to connect to wireless network which caused install to abort and launch session. I plugged in ethernet port to send in bug report but nm was unable to bring up the network on ethernet port either. I also got segfaults in gsetting-daemons. Also not sure if I caused this when I
<cody-somerville>  was trying to bring the network back up but the system-wide dbus daemon crashed which made it difficult to communicate with upstart to bring up/down services. Anyhow, is nm issue a known issue?
<bdrung> tumbleweed: strange. now it builds on experimental.
<bdrung> tumbleweed: now only https://launchpadlibrarian.net/134570548/buildlog_ubuntu-raring-amd64.devscripts_2.13.1~daily%2Bbzr2631~raring1_FAILEDTOBUILD.txt.gz needs to be fixed
<slangasek> cody-somerville: first I've heard of it.  Maybe you're looking at a hardware problem?
<tumbleweed> bdrung: scripts/devscripts/control.py:68 doesn't match the exception in your earlier paste
<tumbleweed> the u was removed
<bdrung> right. i removed that u after i found an older python3-port.patch on my system
<cody-somerville> slangasek: Do you know if there is a way to get apport to save reports to disk and then be able to submit it once I boot back into 12.10?
<slangasek> cody-somerville: if it's a crash, it gets written to disk under /var/crash already; you'd just need to copy them over
<tumbleweed> bdrung: whitelist Popen in the pylint config
 * tumbleweed -> bed
<bdrung> tumbleweed: thanks. will do that.
<cody-somerville> Also, I found that there is a significant (and rather annoying) delay in the hover-over label displaying for items in the dash compared to 12.10 (which displays them immediately). Is this intentional?
 * cody-somerville is going to collect those crash reports.
<xnox> doko: i guess stokachu involved you in the conversation because you are bash maintainer =)
<robert_ancell> bdmurray, was that lightdm MP for packaging or trunk? You've merged it against trunk but it's about 500 revisions behind
<robert_ancell> bdmurray, https://code.launchpad.net/~brian-murray/lightdm/bug-967229/+merge/153953
<bdmurray> robert_ancell: ah, for packaging
<bdrung> xnox: all devscripts issues resolved. i am waiting for an updated patch for debian bug #703323
<ubottu> Debian bug 703323 in devscripts "devscripts: [wrap-and-sort] add trailing comma" [Wishlist,Open] http://bugs.debian.org/703323
#ubuntu-devel 2013-03-19
<ogra_> slangasek, so i discovered a quite bad bug with multiarch and am pondering what to file it against ...
<xnox> stgraber: do we have wallpapers contest selected?!
<ogra_> if you enable any ports arch apt-get update chockes (rightly) on security.ubuntu.com ...
<stgraber> xnox: no idea
<xnox> ogra_: yes. noticed that as well. hardly new news, one should limit arches on security.
<xnox> stgraber: i'll poke seb128 tomorrow.
<xnox> bdrung: kk.
<xnox> good night all =)
<ogra_> xnox, one ?
<ogra_> xnox, i used dpkg --add-foreign-arch or some such ...
<ogra_> and afterwards apt-get update was broken
<ogra_> if we provide that level of automation, the automation should work :)
<cjwatson> jamespage,zul: looks like python-babel needs an MIR?
<cjwatson> Or else the dep needs to go - can't quite make it out from the diff
<zul> cjwatson:  yeah will get to it tomorrow
<cjwatson> Ta
<ini> are any contributers free for a 5 minute conversation? i'm working on a paper about open source, and would love to hear from a developer
<ikepanhc> @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: ikepanhc
<pitti> Good morning
<RAOF> pitti: Yo!
<elky> Either apport just sent me to the page for a non-existent bug or to a bug locked for security. Is it supposed to do that? Known issue?
<elky> I suspect the former, because incrementing/decrementing the number isn't bringing up any visible bugs.
<StevenK> What's the number?
<elky> 1142546
<elky> doesn't seem to be anything within a range either side of it.
<elky> either that, or a few dozen security bugs landed at once.
<StevenK> It's private
<elky> apport should probably check that...
<StevenK> There's an open apport bug about it
<elky> heh
<StevenK> IIRC
<elky> private too, i assume :P
<StevenK> I don't think so, but I can't recall the number.
<elky> Probably for the best, we'd risk overdosing on irony.
<StevenK> elky: People keep blaming LP for this, but I don't think it's an LP problem.
<elky> StevenK, for what, the apport not checking that value in the api response or whatever?
<StevenK> I'm not sure how apport decides it's already reported as <private bug>
<ScottK> Maybe apport has too many privileges on LP.  If it couldn't see the private bugs, it would never dupe against them ...
<pitti> there is https://launchpad.net/~apport which owns all private crash bugs until they get retraced and the core dumps removed
<pitti> then ~ubuntu-crashes are subscribed to them
<StevenK> ScottK: And then you have tonnes of dupes.
<StevenK> But we sort of do already
<dholbach> good morning
<dholbach> Quintasan, happy birthday! :)
<mmrazik> cjwatson: morning
<mmrazik> cjwatson: did nuclearbob follow up with you yesterday regarding the installing issues?
<ikepanhc> @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:
<seb128> gema_, hey, did you guys notice any issue with raring daily installs recently? mmrazik was looking at why jenkins/utah is failing to run on the unity setup and think it's a platform issue and that you guys probably ran into it as well?
<mmrazik> gema_: nuclearbob was looking into that yesterday
<gema_> seb128, mmrazik I had a problem installin yesterday but not sure if it is related
<gema_> mmrazik: do you have a bug numbeR?
<mmrazik> seb128, gema_: I'm just reporting a bug. Will paste the # in a minute here
<gema_> mmrazik: ack
<gema_> mmrazik: nuclearbob was investigating a problem with bootspeed testing that we had over the weekend as well, not sure if it is the same, though
<mmrazik> it most likely is
<gema_> mmrazik: ack, it doesn't look solved to me, he attempted to run bootspeed 6 times yesterday
<gema_> with 0 success
<mmrazik> gema_, seb128, cjwatson: Here is a bug with the issue: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1157065
<ubottu> Launchpad bug 1157065 in ubiquity (Ubuntu) "preseed install fails with "The username you entered (root) is reserved.."" [Undecided,New]
<mmrazik> I hope all the logs are there
<mmrazik> if not, let me know
<zyga> utlemming: ping
<seb128> mmrazik, thanks a lot, I think it has the debug logs needed, let's wait for cjwatson
<mmrazik> seb128: I just don't see anything obvious there :-/
<mmrazik> hope cjwatson will see more
<OdyX> pitti,tkamppeter: Damn, cups 1.6.2 is out, time for a big^2 merge; I'll likely have 'some' time to work on it this week and will start in a different branch (so that master stays buildable at all times)
<gema_> mmrazik: thanks a lot
<zyga> utlemming: vagrant got 7 new releases, we are still at 1.0.3 which refuses to start on raring with virtualbox 4.2, current vagrant upstream is 1.1.2, do you think we can work on getting FFE and get that package updated?
<mpt> ev, did you hear any more from m4n1sh after helping him with the activity-log-manager integration?
<ev> mpt: not yet
<ev> we exchanged a couple of emails
<ev> but I haven't heard anything since
<mpt> hmmm
<mpt> that's unfortunate
<ev> mpt: he did say he felt it unlikely to get done in time for FF
<OdyX> win 25
<pitti> slangasek: I took the liberty to retarget https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration to s-series and milestone ubuntu-13.05 to reflect the declined FFE
<tkamppeter> OdyX, pitti, we can go ahead of getting CUPS 1.6.2 into Ubuntu, seb128 is OK with it as the new release is bugfix-only.
<OdyX> tkamppeter: I pushed master-1.6.2 to the git repository, now it needs patches review, refresh and drops, I'll do that later today, if you don't beat me to it.
<tkamppeter> OdyX, great, if it gets tready today there is plenty of time that it gets tested in the Ubuntu environment. Please tell me when you are ready and I will sync it into Raring.
<mmrazik|lunch> gema_: regarding the pre-seed stuff and lp:1157065 -- there is an utah-related question I can't answer. Can somebody look there?
<cjwatson> Yeah, it looks to me as if the preseed file is simply not being applied
<cjwatson> You're preseeding some questions successfully, but as far as I can see only because they're listed directly on the kernel command line (which doesn't scale) rather than relying on the preseed file for them
<ogra_> oh, i didnt chgeck the cmdline ...
<ogra_> *check
<xnox> cjwatson: using that preseed and seeding it with url, still the keyboard page, where i had to manually click continue. watching the slideshow now.
<xnox> (debian-installer/locale did work before, I'll test that with nexus7 as well, before filing a bug)
<gema_> mmrazik|lunch: we'll have a look
<cjwatson> xnox: the keyboard is being preseeded on the kernel command line, not in the preseed file
<cjwatson> (in this case)
<xnox> cjwatson: is it one of those that must be presseded before ubiquity (e.g. on the command line) anyone, i'd think many people would notice quickly if keyboard was getting people stuck.
<xnox> s/anyone/anyway/
<mdeslaur> @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: mdeslaur
<cjwatson> xnox: the command line vs. preseed file distinction is only relevant to d-i, not to ubiquity
<xnox> ok.
<cjwatson> xnox: with ubiquity, *everything* is preseeded before ubiquity anyway, because ubiquity doesn't process preseed files - that's casper's job
<mpt> Any geolocation experts in the house? I'm trying to write a caption to explain the effect of turning off GPS on Ubuntu Phone
<xnox> mpt: considering we yet to have GPS capable framework in the OS, currently turning gps on/off makes no difference =)
<ogra_> but you can talk about it in the UI :)
<seb128> mpt, you can maybe try #ubuntu-touch if nobody on -devel has an opinion
<ogra_> yeah
<mpt> As I understand it, geolocation with GPS + Wi-Fi is excellent, GPS only is pretty good, Wi-Fi only is patchy, and with neither is down to the country level. Is that right?
<ogra_> #ubuntu-touch would likely be better
<seb128> xnox, speaking about geoclue, is this bug about hongkong not being in the ubuntu geoname db still on your list? we got a similar one that singapore is missing as well
<xnox> mpt: there is also 3G network signal tower location based detection, if one is provided by your operator. That is usually "bundled" into GPS chip though.
<xnox> seb128: yes, I was pondering about it. We used to have a bug of having too many duplicates, now I'm thinking we remove way too many. I'll add some unit tests.
<seb128> ok
<cjwatson> I don't think it's necessarily true that "with neither [it's] down to the country level" - it depends on the quality of the geoip database in use
<xnox> mpt: yeah, with virgin media cable broadband it's down to roughly first part of the post-code at times.
<xnox> for example.
 * cjwatson tries to remember how to get geoname-lookup.ubuntu.com to actually give him an answer
<xnox> cjwatson: http://geoname-lookup.ubuntu.com/?query=Kong
<cjwatson> xnox: no, I mean for my IP
<cjwatson> But anyway with the maxmind database installed there it's often at at least city level.  I suspect quality varies
<cjwatson> Ah, what I actually meant was http://geoip.ubuntu.com/lookup
<cjwatson> That claims I'm in London, so it's obviously not all the way there yet ...
<cjwatson> Pretty sure I've seen it do better
<mlankhorst> well there should probably at least be some validation the country is correct..
<mpt> thanks xnox, cjwatson
<xnox> mpt: http://geoip.ubuntu.com/lookup for me is just two digits away on the first part of the zipcode.
<mpt> Thinks I'm in Bexley
<cjwatson> zipcode?  American :P
<ogra_> my zipcode is backwards ...
<ogra_> (05 instead of 50)
<ogra_> ah, wait, no, its the region code
<ogra_> it doesnt actually show a zip code
<cjwatson> Putting "ZipPostalCode" in the DTD for an allegedly geographically-agnostic service was a pretty bad design :)
<cjwatson> (ZIP -> Zone Improvement Plan, a term used specifically by the US Postal Service)
<ogra_> but at least it has improvement in the name :)
<seb128> gema_, did you found anyone to answer the utah question in that bug? (would be good to see that fixed, it's blocking unity changes to land for some days)
<gema_> seb128: I am waiting for nuclearbob to go online to ask him
<nuclearbob> gema: ask me wt?
<seb128> gema_, hum, k
<gema_> nuclearbob: can you read the history on this channel
<cjwatson> nuclearbob: question from me in bug 1157065, specifically
<nuclearbob> gema: looks like seb128 was asking about a bug, do either of you have the bug number?
<ubottu> bug 1157065 in ubiquity (Ubuntu) "preseed install fails with "The username you entered (root) is reserved.."" [Undecided,Confirmed] https://launchpad.net/bugs/1157065
<nuclearbob> cjwatson, thanks
<nuclearbob> cjwatson seb128: do you want me to answer in the channel or respond to the bug?
<cjwatson> bug, I guess
<nuclearbob> thanks, doign that now
<seb128> whatever works for cjwatson
<seb128> thanks
<gema_> nuclearbob: any chance we've changed something that may have broken the preseeding code?
<nuclearbob> gema: we haven't updated the code on magners-orchestra yet, and the problem occurred before I even branched the testing code there
<cjwatson> I followed up again.  I wonder if the new busybox might be implicated
<cjwatson> Has this been broken perhaps for about four or five days?
<seb128> cjwatson, we noticed yesterday the issues for the first time, but nobody is watching during the w.e
<gema_> nuclearbob: ack
<cjwatson> I'm grabbing a current image to see if I can tell whether casper-set-selections is just generally broken
<zyga> utlemming: ping
<zyga> mpt: do you think that clicking on the trash / rubbish bin icon should "focus" that icon in the launcher?
<zyga> mpt: right now it opens nautilus which to me, feels wrong/confusing
<cjwatson> casper-set-selections doesn't seem obviously broken
<seb128> zyga, what do you mean "focus the icon"?
<seb128> zyga, which is opening the "rubbish bin" location wrong when clicking on the corresponding icon?
<zyga> seb128: show the triangle on the left side
<zyga> seb128: start with an empty desktop
<zyga> seb128: click on the trash can
<zyga> seb128: you get nautilus, which is one of the fist few icons (counting from top)
<zyga> seb128: I would have expected the tash window to be "active/focused" (correct me on the right term) and the nautilus icon remained as is
<cjwatson> nuclearbob: another information request in that bug
<zyga> cr3: hey! :)
<seb128> zyga, known issue, same with device icons (usb sticks, cds, ...)
<zyga> seb128: ah, thanks
<seb128> zyga, it comes down to the fact that all those are nautilus views and the matching is not smart enough to make the difference
<zyga> seb128: I just realized it and wondered if there should be a bug on that or not
<seb128> trevinho from the unity team has been working on improving that
<zyga> seb128: yeah, I realize that it's probably that :) I was thinking about the design aka how-it-should-work
<seb128> like with the current version it will open locations only one
<nuclearbob> cjwatson: I'll try to recreate that with that option on.  I'm seeing the same error on debian-installer based images as well, if that makes a difference
<seb128> where it used to open new views every time you clicked
<cjwatson> nuclearbob: Possibly.  What would help is a way to reproduce this outside of utah
<cjwatson> Or at least locally without a big lab setup
<nuclearbob> cjwatson: so far I can't even consistenly recreate it in utah, but I'm working on both.  as I've looked at it, we do set DEBCONF_DEBUG=developer on all server installs, but not desktop.  I'm trying to run with that on desktop now
<cjwatson> Commonality with d-i would not conflict with the hypothesis that it's a busybox regression, but that's still a wild guess hypothesis
<nuclearbob> okay
<nuclearbob> I haven't had any luck recreating it on a vm so far, unfortunately, I'm still working on that
<OdyX> tkamppeter: lol; no ipp14 is shipped in cups 1.6.1, at all.
<OdyX> spotted that with unrelated lintian warnings
<cr3> zyga: hi there, any updates on adopting subunit?
<zyga> cr3: no, we're deep in SRU stuff, trying to get stuff to work enough to switch SRU process to plainbox
<zyga> cr3: I was talking about the way we submit data to certification website but we don't expect any changes in that area until after we get all of plainbox + gui done
<cjwatson> nuclearbob: FWIW d-i is usually easier for me to debug
<cjwatson> nuclearbob: so if you can reproduce it there, especially if any more reliably, then we should start with that
<nuclearbob> cjwatson: I can get it to show up more easily on d-i, I just don't know how to get the logs out then.  If you have access to the lab vpn, I can get you a system where it's failing
<nuclearbob> cjwatson: I'm still trying to setup a recreate outside of the lab as well
<cjwatson> nuclearbob: boot with serial console and the logs should come out there?
<cjwatson> nuclearbob: can you link me to the directions for setting up the lab VPN so I can compare them against what bits of network I have?
<cjwatson> I use VPNs so rarely that I honestly can't remember
<cr3> zyga: when do you think plainbox will finally replace checkbox?
<nuclearbob> cjwatson: we don't have anything attached to the serial port on most of these machines, but there's one I can try
<nuclearbob> cjwatson: I'll see if I can find the lab vpn info
<zyga> cr3: never, checkbox will stay as a project name and something people use, it will just use plainbox for everything not specific to checkbox itself
<zyga> cr3: as for when it will be rolled out in any form
<zyga> cr3: the SRU process is still using checkbox but we're doing a test SRU on one machine with plainbox, so far it does nothing but we're plugging the pieces, we basically have everything needed, it's just not plugged into that command
<zyga> cr3: once that works and we iron out any bugs we'll look at what's the next step
<cr3> zyga: very exciting!
<zyga> cr3: probably GUI and then full replacement
<zyga> cr3: I wrote a proposal for new job description format that hopefully plugs one issue with current jobs, would you like to have a look at that?
<zyga> cr3: http://jobbox.readthedocs.org/en/latest/jobspec.html#jobbox-job-definition the interesting parts that matter are around parse-job-pattern
<zyga> cr3: the rest is not essential, just 'cleanup'
<zyga> http://jobbox.readthedocs.org/en/latest/jobspec.html#parse-job-pattern this is a better link
<zyga> cr3: the idea is to be able to discover dependencies across local jobs
<zyga> cr3: by creating 'maybe' jobs that _might_ be generated by a particular local job
<zyga> cr3: so I could run for example "bandwith_test_wlan0" (hypothetical example) and have plainbox discover the dependencies to discover and run that job
<cr3> zyga: I don't have enough brain to allocate to understand what parse-job-pattern does, I'm starting to swap
<zyga> cr3: hehe, sorry to try to drag you into this parse-job-pattern is just a way to tell plainbox that a particular local job can only generate jobs that match some specified pattern
<zyga> cr3: so that "bandwith_test_wlan0" job would come from "bandwith_tests" local job (all examples so far) that has parse-job-pattern equal to "bandwith_test_{interface}"
<zyga> cr3: so any job that is not know to the core, that matches any of the local job patterns can be traced via that possible route to a local job, where we can already discover dependencies needed to run it
<cr3> zyga: oh, that's nice indeed. thanks for the explanation!
<mpt> zyga, I think that as long as the Launcher includes either the Trash or Web apps, and especially if it shows both,  it shouldn't try to highlight the focused app at all.
<mpt> (And double-especially if it ever gets the ability to hold other folders and bookmarks.)
<zyga> mpt: I wasn't clear, it's not just focus
<zyga> mpt: it's the triangle that shows the app is running (correct me on how that is called)
<zyga> mpt: unlike webapps, the trash is never 'active' in that sense
<zyga> mpt: having both the trash and nautilus having triangle as with webapps would be a good consistent compromise probably
<zyga> mpt: (actually focus is entirely not related to that, I just used the wrong term earlier)
<mpt> zyga, I don't care about that. It was included as an issue in past Unity usability tests -- difficulty in telling which applications were running -- and I thought, "why is that even a problem?"
<zyga> mpt: I'm not sure what that means, I'm trying to figure out if that's a problem according to you and if so, should there be a bug about that
<zyga> mpt: if you mean that the function of the triangle is not relevant and that it will go away entirely then that's probably fine
<mpt> zyga, I think you're confusing me with someone involved in the design of Unity. :-)
<zyga> mpt: re-reading your first statement it makes the launcher act as a bar with buttons that each "do something to show the application", in that context it is accurate and especially with more mobile-like application lifecycle it's wrong to try to show the state of any application as we're building an ilusion that apps always work
<zyga> mpt: sorry, you seem like a go-to person for questions regarding design issues, if you know who should I be talking to instead please redirect me
<mpt> zyga, try #ubuntu-design perhaps
<zyga> thanks
<xnox> zyga: or #ubuntu-touch and #ubuntu-unity
<zyga> I'll try -desing and -unity
<ogra_> nuclearbob, does your casper script actually do more than just copying the preseed to / ? (might probably make sense to attch it too)
<ogra_> *attach
<nuclearbob> ogra_ yeah, it copies some other files we use in the success_command.  I'll attach it to the bug
<ogra_> nuclearbob, but it doesnt have any code to apply the preseed ?
<cjwatson> Not necessary anyway
<cjwatson> casper applies it itself
<cjwatson> As long as it's called /preseed.cfg in the initramfs, which AFAICS it is
<ogra_> i'm not sure there is anything doing that by default
<ogra_> ah k
<nuclearbob> cjwatson and ogra_: during my testing, having it in the initramfs wasn't enough, I had to get it into the live fs for it to work.  I may have been doing something else wrong, but at this point, we copy it from the initramfs to the livefs with a casper-bottom script I'm about to uploda to the bug
<cjwatson> I wish you'd reported that ...
<cjwatson> Because it is meant to work
<nuclearbob> sorry about that, at the time I was mostly assuming that all the process problems were my fault
<nuclearbob> we also copy an rsyslog configuration file in that script, I'll upload it as well
<cjwatson> In fact I'm really not sure whether copying the preseed achieves anything at all, although it's perhaps useful documentation
<slangasek> pitti: retargeted> sounds good, thanks
<tkamppeter> OdyX, you need to conserve the ipp14 patch. I have added ipp14 as Mike is refusing to fix certain regressions which came in with CUPS 1.5.x as he made the ipp backend more IPP-conforming. For the few people with these problems I have made avaialable the ipp backend of the old CUPS 1.4.x as ipp14.
<mitya57> fginther: is there any reason why you didn't propose a merge for your branch lp:~fginther/+junk/python-coverage-fix-1109090 ?
<mitya57> I've just run into the same issue
<mitya57> fginther: nevermind, this is an issue in Debian patch so should be fixed there, not by adding a new patch. I'll now do this.
<fginther> mitya57, sorry.  I was refresshing my memory
<mitya57> will have a MP in 5 minutes
<fginther> mitya57, yes, that sounds right. I realized it wasn't the right fix and never got around to doing it correctly
<fginther> mitya57, I'll review
<mitya57> fginther: https://code.launchpad.net/~mitya57/ubuntu/raring/python-coverage/lp1109090/+merge/154123
<OdyX> tkamppeter_: build in progress, will push to Debian experimental 'soon'
<fginther> mitya57, approved
<mitya57> fginther: thanks!
<mpt> katie, bug 1084979
<ubottu> bug 1084979 in apport (Ubuntu) "Submitting error report asks confounding questions" [Medium,Triaged] https://launchpad.net/bugs/1084979
<slangasek> jodh`: daily upstart build failure on armhf that I don't understand: https://launchpad.net/~canonical-foundations/+archive/upstart-daily/+build/4381411
<slangasek> jodh`: has this been ongoing, or is it new?
<jodh`> slangasek: I think this might be the issue xnox has seen?
<slangasek> jodh`: I don't know :)
<jodh`> slangasek: I'll see if I can recreate...
<xnox> jodh`: yes, that's what i have been seeing.
<xnox> slangasek: we exhaust inotify watches in some parts of the test-suite, but if system makes one watch free, then the part of the tesuite that is running in "no inotify available" can fail as suddently inotify became available and e.g. jobs got automatically reloaded instead of manual reloading.
<xnox> jodh`: make -C init -j4 check : is the quickest way to reproduce. Assuming you have multiple core machine.
<OdyX> tkamppeter_: cups 1.6.2-1 uploaded to Debian experimental
<slangasek> xnox: ugh, we're *exhausting* inotify?  This sounds like it could be a problem at runtime too, especially with user sessions
<mdeslaur> @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:
<xnox> slangasek: on purpose hitting the limit, to see what happens when there are no inotify watches left.
<slangasek> ah, well then
<xnox> otherwise it is quite large per user, and unlimited system wide.
<xnox> slangasek: well the limit is max # of open file descriptors per process.
<jodh`> xnox: well, the magic number happens to correspond to the same value on the buildds; we should really query that rlimit :)
<jono> didrocks, hey, I noticed that most of these scopes in the PPA don't seem to display in the dash results
<jono> is that normal?
<didrocks> jono: the server is sending fake scope recommendations
<didrocks> jono: so it's always starting the same
<didrocks> the ETA to get it fixed is in 2 days IIRC
<jono> didrocks, ahhh cool
<jono> didrocks, it seems there is also an issue with queries happening after every keystroke
<didrocks> jono: please opens bugs and tag them 100scopes
<didrocks> jono: https://bugs.launchpad.net/unity/+bugs?field.tag=100scopes
<jono> didrocks, will do now
<didrocks> thanks :)
<jono> didrocks, https://bugs.launchpad.net/unity/+bug/1157263
<ubottu> Launchpad bug 1157263 in Unity "Network queries happen after each keystroke" [Undecided,New]
<didrocks> jono: thanks!
<tkamppeter> OdyX, thanks for updating CUPS on Debian, I am now waiting for Debian's build servers so that I can sync the new package.
<ogra_> tkamppeter, oh since i saw you asking on the ML ... http://www.heise.de/open/artikel/Dells-Ubuntu-Ultrabook-im-Test-1823594.html there is a dell XPS review
<tkamppeter> ogra_, thanks, will look ...
<awe_> seb128, ping
<seb128> awe_, hey
<awe_> looking at the bt indicator I just reviewed https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1123115
<ubottu> Launchpad bug 1123115 in indicator-bluetooth (Ubuntu) "Needs to break/replace gnome-bluetooth" [Low,Fix released]
<awe_> and https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1116292
<ubottu> Launchpad bug 1116292 in indicator-bluetooth (Ubuntu) ""Set Up New Deviceâ¦" item is missing" [Medium,Fix released]
<cjwatson> tkamppeter: FWIW you don't need to wait for Debian buildds to sync a package, only for the source package to be published in the archive and (shortly afterwards) noticed by the cron job in Launchpad that imports it into launchpad.net/debian/+source/<package name>
<awe_> doesn't "Breaks/Replaces" cause gnome-bluetooth to not be installed?
<awe_> and if so, doesn't that break support for "Setup New Device"?
<seb128> awe_, no, it does "Breaks: gnome-bluetooth (<< 3.6.1-0ubuntu2)" which force a newer version to be installed
<seb128> awe_, newer version = one without our indicator patch
<awe_> ah OK
<awe_> sorry I misunderstood
<seb128> no worry ;-)
<seb128> we still use gnome-bluetooth
<seb128> that's what has the wizard ui
<awe_> I missed the << part
<awe_> looks like indicator-bluetooth is missing "sendto" though
<seb128> awe_, you mean?
<seb128> I've a "send files" entry in the submenu for my phone
<awe_> wow, I'm batting 0 for 2
<awe_> I really haven't worked with vala all that much, and it looks like "sendto" and "wizard" are handled differently
<seb128> what do you call "sendto"? sending files to a device ?
<seb128> and yes, it's possible things are different
<seb128> I think robert_ancell tried to follow mpt's spec
<awe_> correct
<seb128> where the previous one was maybe not 100% conform to the spec
<awe_> the wizard is launched via Process.spawn_command_line_async()
<awe_> whereas as send_to is invoked via GnomeBluetooth.send_to_address()
<seb128> is that an issue?
<awe_> that's what threw me
<awe_> I was just trying to confirm that these were both supported
<awe_> also, they may need to be re-implemented for touch
<BenC> cjwatson: where do I update the initrd on the server ISOs so I can include an IDE driver in it (for QEmu)?
<awe_> seb128, just trying to ensure we have all of our work items in line for BT UI
<seb128> awe_, yeah, I'm sure tweaks will be needed
<seb128> awe_, I doubt we will want to keep the gtk wizard on touch anyway
<seb128> so those parts will need to be reimplemented
<awe_> right, and same for send-to
<awe_> however neither of those are being tracked atm
<cjwatson> BenC: those initramfses are built by debian-installer, but the change you probably actually need to make is to add the module to one of the udebs generated by the linux-ppc source package
<awe_> maybe I'll add pending TODO items in the BT spec, and we can move them if needed
<awe_> s/maybe//
<seb128> awe_, yes, please do
<awe_> k
<awe_> thanks
<seb128> awe_, yw, thanks for looking into those details
<BenC> cjwatson: I suspect it is, but I need it to be in the initrd else it can't find the cdrom
<awe_> seb128, np
<seb128> awe_, we probably need to add "port the indicator to the new libindicator api/gmenumodel" as well
<seb128> that one was not available so robert_ancell did the work using the current apis
<awe_> larsgk, already has that covered
<cjwatson> BenC: debian-installer already includes pata-modules in the cdrom initrd for powerpc
<seb128> awe_, larsu you mean? ;-)
<cjwatson> BenC: so just add it to pata-modules and it'll be picked up at the next debian-installer rebuild (which are frequent)
<awe_> oops, yea
<seb128> awe_, good
<BenC> cjwatson: Ah, ok, thanks
<roaksoax> slangasek: howdy!! where you able to review MAAS (maas, maas-provision)?
<seb128> gema_, hey again, do you know if that utah issue is likely to be fixed today at this point? still blocking unity...
<seb128> hum
<seb128> so we didn't have any langpack update this cycle
<seb128> is anyone looking at this? I would usually ping dpm but he's on holidays this week
<pitti> for the record, we need Launchpad translation exports
<seb128> pitti, is that purely launchpad issue? do you know if there is a ticket?
<pitti> no, I don't
<pitti> TBH I didn't deal with translations much this cycle, except asking dpm for exports a month ago or os
<pitti> "so"
<seb128> pitti, ok, thanks, trying to ping on the launchpad side (dpm is out, will have to wait next week otherwise)
<xnox> seb128: speaking of which, it was in my todo to run the archive export & update app-install-data, let me start that now.
<seb128> xnox, thanks, don't forget to fix geonames' db as well :p
 * seb128 hides from xnox
<slangasek> roaksoax: sorry, I failed at it on Friday - but I'm looking now
 * xnox ponders how strange is it to look up instructions on how to do stuff...... in my own sent mail folder.
<seb128> gema_, ?
<lunitik> I noticed in Raring that gksu is no longer used to authenticate in the GUI, what is used instead?
<seb128> pkexec in most places
<lunitik> seb128: Makes sense, actually, thank you... and also thanks for all your great work still with Ubuntu/Gnome  :)
<seb128> lunitik, yw, thanks for the nice comment ;-)
<slangasek> roaksoax: this doesn't look right: +Pre-Depends: ${misc:Pre-Depends}, ${misc:Depends}
<slangasek> roaksoax: pretty sure you want ${misc:Depends} in the Depends field
<roaksoax> slangasek: ok cool. I'll update that
<gema_> seb128: you need to talk to nuclearbob or doanac`
<gema_> nuclearbob: ^^
<seb128> gema_, k, I though you were tracking the issue/making sure things don't get stalled in your team
<seb128> which they seem to be...
<gema_> seb128: they are working on it, and they are in US time, I have all the confidence they are doing their best
<gema_> seb128: I will have an email tomorrow morning with status whenever I get to work
<seb128> gema_, thanks
<nuclearbob> gema, seb128, are we still talking about the install issue?
<seb128> yes
<seb128> that's blocking unity tests for several days
<seb128> so it's blocking any update to land as well
<nuclearbob> an environment variable in jenkins changed, and we don't know why.  We've configured utah to ignore that environment variable while we figure out why it changed, and our tests are now working
<nuclearbob> our attempt to rerun the autopilot tests seemed to work as well
<seb128> oh ok, would have been good to update the bug saying that
<doanac`> seb128: we just figured this out over lunch
<nuclearbob> seb128: sorry abou tthat, good point.  I was hoping to have a more definitive answer than "something went wrong and we don't know why" but I'll post info about the workaround
<doanac`> still can't say why jenkins has changed
<seb128> things should be in shape enough for unity's tests to be retried on jenkins then?
<slangasek> roaksoax: not SRU-critical, since misc:Depends is empty in this case
<doanac`> seb128: yes.
<seb128> doanac`, thanks, we are giving a retry to unity's stack
<roaksoax> slangasek: ack!
<doanac`> seb128: we've run this successfully as a test: http://10.97.0.1:8080/view/autopilot/job/ps-unity-autopilot-release-testing/122/
<doanac`> nuclearbob: to double-check - we do still have the conf.d fix deployed, correct?
<nuclearbob> doanac: correct
<seb128> doanac`, ok, great, cyphermox is going to give a retry to http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/
<seb128> oh, seems there is one running
<seb128> cyphermox, ^
<cyphermox> yup, just noticed
<nuclearbob> cyphermox seb128: the job was started while we were testing the current deployed workaround, and thus not affected by the workaround.  I'm retrying it now that the workaround is in place
<seb128> ok, thanks
<slangasek> roaksoax: checking my IRC logs, I see that I wrote: however, looking at the package that's in raring, the /other/ Conflicts (on maas (<= ...) and maas-region-controller (<= ...)) should almost certainly be Breaks rather than Conflicts, since they're paired with Replaces
<slangasek> roaksoax: I think this definitely should be fixed for the SRU, maas-region-controller shouldn't Conflicts: the old version of maas
<slangasek> roaksoax: even if it doesn't cause any known issues, it's the wrong package relationship to use
<roaksoax> slangasek: ok. I'll fix that and re-upload
<cjwatson> It will at least cause suboptimal upgrade ordering
<cjwatson> Which can turn into total upgrade failure when you least expect it, so indeed best to avoid
<slangasek> roaksoax: ok.  The same applies to the Conflicts added on the python-maas-provisioningserver package; anywhere that you use Replaces: $pkg (<= $ver) + Conflicts: $pkg (<= $ver), you should be using Breaks instead of Conflicts
<slangasek> and python-maas-client
<slangasek> ... etc
<cjwatson> You should probably also be using << first-version-with-new-layout rather than <= last-version-with-old-layout
<cjwatson> It's friendlier to anyone producing modified versions of your packages
<roaksoax> slangasek: yeah i'll update all of those
<slangasek> roaksoax: not relevant to the SRU, but "BSD" and "MIT" in debian/copyright are both ambiguous; per http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/, these should be listed as BSD-3-clause and Expat
<cjwatson> gema_: I have some fine-details-of-jenkins questions regarding better integration of smoke testing with cdimage, but it's probably a bit complex for IRC; whom would it be best for me to mail?
<roaksoax> slangasek: thanks for the review! I'll address all of these and upload a new package.
<slangasek> roaksoax: is there an authoritative Vcs branch for the maas package?  It's not listed in debian/control; I see a number of things in the maintainer scripts that I think should be cleaned up but shouldn't block the SRU, so I'd rather raise a MP
<roaksoax> slangasek: there's various branches. Raring has its own, quantal has its own, and precise has its own (which is basically quantal + precise specific changes)
<slangasek> roaksoax: well, the raring one is where I would start :)
<slangasek> roaksoax: where would I find it?
<roaksoax> slangasek: lp:~maas-maintainers/maas/packaging, lp:~maas-maintainers/maas/packaging.quantal, lp:~maas-maintainers/maas/packaging.precise.sru
<slangasek> roaksoax: ta
<roaksoax> slangasek: could you please rebase your MP? There was another branch that needed to land first, which will conflict with debian/changelog
<slangasek> roaksoax: you guys don't fix changelog conflicts on the merge side?
<slangasek> I can fix it up, sure
<roaksoax> slangasek: no i don't think so, since its the bot that actually lands the MP's
<slangasek> ah
<slangasek> roaksoax: done
<roaksoax> slangasek: awesome thanks!!
<slangasek> roaksoax: whoops, just spotted a typo in the branc
<slangasek> h
<roaksoax> slangasek: hehe no worries, it wasn't landed :)
<slangasek> roaksoax: fixed and repushed
<stgraber> xnox: I just updated https://wiki.ubuntu.com/ImageBasedUpgrades/Mobile to include what I discussed with lool last week. I'll likely be doing a few more edits soon but it at least better covers the current state of things.
<ogra_> stgraber, geez, that became a gigantic wikipage over time
<stgraber> ogra_: could have been worse, I removed a few paragraphs in the update I did earlier today (and added a bunch more obviously ;))
<ogra_> well, it reflects the complexity of the task :)
<bdrung_> if raring is support for 9 month, raring will eol before quantal. how to upgrade from quantal once raring is eol? will upgrading directly from quantal to raring+1 supported?
<cjwatson> bdrung_: yes, that will be a necessity
<cjwatson> (and is a good idea anyway!)
<cjwatson> the whole business of not supporting direct upgrades from N+1 to N+3/N+4 while expecting to be able to support direct upgrades from N to N+4 was always total madness
<cjwatson> we only did it that way in the beginning because we didn't have anything resembling an upgrade autotest setup and so it was too hard to QA
<cjwatson> but times have changed and supporting more flexible combinations will make it *easier* to get LTS-to-LTS upgrades working reliably in a timely fashion
<bdrung_> cjwatson: thanks. upgrades beyond LTS are not intended, are they?
<ScottK> No.
<bdmurray> xnox: is there any progress on bug 915626?
<ubottu> bug 915626 in usb-creator (Ubuntu) "usb-creator-gtk crashed with SIGSEGV in _dbus_watch_invalidate" [High,In progress] https://launchpad.net/bugs/915626
<cjwatson> I don't think it's necessary to go that far, and it may not be practical due to Debian tending to drop support for upgrades beyond single Debian releases in at least some cases
<cjwatson> (lots of maintainers do keep support for longer, but you only need one complex thing not to be supported and it can become a real tangle)
<bdrung_> i am asking because it affects if transitional package can be dropped after a LTS
<ScottK> Fortunately you've got a while before you need to worry about that.
<seb128> I think having the LTS as "forced upgrade point" makes sense
<ScottK> Agreed.
<cjwatson> Yep.  I think we have fairly widespread agreement on that.
<cjwatson> I don't object to developers keeping upgrade support for longer, of course, but it seems a step too far to demand it
<cjwatson> Skip-upgrades in Debian are reportedly not awful if you know what you're doing, but come with roadblocks.
<geofft> I skip-upgraded my desktop from Natty to Quantal via apt-get a few months ago. I was slightly surprised it worked.
<geofft> But I haven't had any trouble with it.
<geofft> So I guess that's a testament to good packaging quality in everything!
<seb128> well, the issue is not so much quality than "how long to carry packaging tweaks to support upgrades"
<seb128> we usually tend to drop delta after a lts, especially if Debian already dropped it and we carry that in an ubuntu specific way
<cjwatson> Yeah, lots of those tweaks make upgrades easier / more automatic but their removal doesn't make it impossible
<cjwatson> Hence things like geofft's experience
<geofft> I think I had to do a bit of dependency-fighting, but it mostly just worked out.
<geofft> I wouldn't recommend it to someone not literate in reading other people's packages, though. :)
<robert_ancell> Laney, could you have a look at bug 1157475? Basically the same request as the Shotwell FFE
<ubottu> bug 1157475 in gexiv2 (Ubuntu) " [FFE] new gexiv2 version" [Wishlist,New] https://launchpad.net/bugs/1157475
<xnox> bdmurray: nope. I gave up on it, and later slangasek said that bindings potentially generate it unfortunately for us when we didn't ask them to do so. A bit of a rabbit hole.
<xnox> stgraber: awesome, I'll go through that tomorrow.
<slangasek> xnox: "generate it when we didn't ask them to" - the segfault?
<xnox> yes.
<slangasek> ok
<xnox> slangasek: how would you say that sentence?
<slangasek> was not sure under what circumstances we would ask a program to generate a segfault ;)
<slangasek> xnox: it's a perfectly good sentence ;)
<slangasek> roaksoax: fwiw I'm concerned about maas-region-controller.config; I have no idea what the set_question() function is meant to do, but I'm reasonably certain that the second if [] block does not work as intended
<slangasek> roaksoax: $RET is only set by db_get or db_metaget; you're not calling either of those here, so "$RET" != false
#ubuntu-devel 2013-03-20
<bdmurray> slangasek: could you have a look at https://code.launchpad.net/~brian-murray/lightdm/bug-967229/+merge/153958 ?
<roaksoax> slangasek: set_questions prevents dbconfig-common from asking a question to whether we want it to configure the db.
<roaksoax> slangasek: and does it by default
<roaksoax> slangasek: and you mean this? if ([ "$1" = "configure" ] && [ -z "$2" ]); then
<roaksoax> ?
<roaksoax> as the second if block?
<roaksoax> slangasek: well that block calls set_question, and those variables dbc_* are for dbconfig common
<cjwatson> slangasek: db_fget sets RET too
<cjwatson> Indeed all db_* commands do, but db_fget sets it meaningfully for this purpose
<cjwatson> RET there (in the second if block within set_question) is the value of the seen flag on $1
<cjwatson> That function is an obvious descendant of d-i code, FWIW
<cjwatson> (Well, obvious to me :) )
<cjwatson> I rather suspect that I may have been the vector for it ending up in cloud-related packaging code ...
<cjwatson> Though I don't see it at a glance through eucalyptus, so perhaps not
<cjwatson> Oh yeah, there it is
<cjwatson> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/eucalyptus/lucid/view/head:/debian/eucalyptus-udeb.postinst
<cjwatson> set_question is essentially "preseed" - set a question's value in the database even if it was not yet registered
<cjwatson> but only if it is not marked as already being seen
<roaksoax> yeah that's it
<slangasek> cjwatson: hmm, what does it set it to? debconf-devel(7) implies that the only return from fget is the return value
<cjwatson> "This command returns the value of a flag"
<cjwatson> where the value is not a numeric result code and hence goes in the extended return value in $RET
<slangasek> ah
<cjwatson> (admittedly it is true or false so you *could* cram it into a numeric result code, but debconf doesn't)
<cjwatson> command_fget is implemented ending with
<cjwatson>         return $codes{success}, $question->flag($flag);
<xnox> infinity: BenC: i wonder what I have to do to get a P-cubed from servergy =))))
 * hyperair wonders if https://wiki.ubuntu.com/Wayland is still relevant.
<hyperair> it says that compiz is going to be ported to wayland.
<RAOF> hyperair: Yeah, much of that is obsolete.
<hyperair> RAOF: hmm, do you have a /hilight on wayland or something? ;-)
<sarnold> cjwatson: the symlink vs directory thing feels complicated; it feels to me that making 'current' a directory of symlinks (one per arch / flavor) would be less confusing all around...
<pitti> Good morning
<AdolfosWeb> Hi
<AdolfosWeb> Someone in there?
<pitti> xnox: I'm curious, what's the current state of usb-creator port to udisks2?
<pitti> AdolfosWeb: just ask your question, don't ask to ask
<AdolfosWeb> ok... I have problems with the suspend option at my ubuntu 12.10 in my new lenovo i3
<AdolfosWeb> someone have this problem?
<pitti> what kind of problem? suspend generally works, so I think you need to give more details
<AdolfosWeb> ok, well i had look for a solution by days... but nothing, some people have the same problem. When y press suspend boton or the option in de user menu the screen goes black, but then never enters suspend mode, my desktop appears again
<AdolfosWeb> hecking the /var/log/pm-suspend.log I find that every time I close or suspend my laptop the log reports:'Running hook /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: Having NetworkManager put all interaces to sleep...Failed '
<BenC> infinity: pokeâ¦about to do a linux-ppc uploadâ¦man the buildd's?
<infinity> BenC: Mmkay.
<infinity> BenC: Upload away.
<BenC> infinity: 15 minutes for the test build to finish...
<infinity> BenC: Too lazy to babysit, adare and ross are on manual, you'll get sagari when you upload, and I'll fix later. :)
<BenC> Heh, ok, thanks
<gema_> cjwatson: I got your email, this work was going to be done by plars from our side, so he'll be contacting you later today about it
<gema_> cjwatson: we've been waiting for someone in the release time to have some time to spend with us on that
<dholbach> good morning
<BenC> infinity: uploaded and build started
 * BenC => Memory Foam Mattresszzzzz
<infinity> BenC: And failed.
<infinity> BenC: /build/buildd/linux-ppc-3.8.0/drivers/tty/serial/8250/8250_dw.c:154:1: error: unknown type name 'acpi_status'
<infinity> BenC: So much for your test build?
<tumbleweed> xnox: (re 2 days ago) trailing commas in debian control files aren't a good idea
<tumbleweed> they aren't part of the specification, and some tools are known to break on them
<xnox> tumbleweed: i'd like to know what is broken, and I will fix it.
<xnox> tumbleweed: there are many packages that have a trailing comma. and I'm sure it's comma separated fields anyway, so one should support trailing comma.
<xnox> tumbleweed: that option is not enabled by default.
<tumbleweed> I last investigated this ages ago, let me see if I can find the discussion I had with other people about it
<xnox> pitti: pushed it here lp:~xnox/usb-creator/udisks2 , It segfaults on tear-down and introduces a dep on the udisks2 gir. And that would be a first one on the cd. I'm thinking to just do it over dbus, without gir. Not sure how to solve segfault.
<pitti> the gir is like 20 kB?
<pitti> xnox: from Python it's probably not that much difference to use dbus directly, but if you got it workign using the gir, I don't think it's a problem to pull that in
<pitti> the segfault sounds weird, though, like a bad ref count somewhere
<xnox> pitti: fair enough, but segfault on cleanup at the very end is indeed "interesting.
<xnox> pitti: ref count, sounds plausible.
<pitti> pygobject (just as python itself) unrefs all objects at the end or during gc
<pitti> xnox: merely starting and quitting it doesn't segfault; what are the steps to reproduce?
<pitti> neither does it crash with having an usb stick or mounting one
<pitti> xnox: so I guess you have to do a full write actually?
<pitti> xnox: oh, trying to erase my stick fails with "org.freedesktop.UDisks.Error.Failed: No such device"
<xnox> if one goes to create it, at 100% progress (end of talking to udisks2/helper) it crashes without giving a popup "it's all ready". Oh yeah, and erasing stopped working properly.
<xnox> pitti: note that there are changes in the common helper as well to port that to udisks2 as well.
<pitti> oh, maybe it's using the installed helper, not from the checkout path?
<pitti> I ran "PYTHONPATH=. bin/usb-creator-gtk"
 * pitti purges udisks and usb-creator
<pitti> yeah, it's using the dbus activated helpers
<pitti> xnox: hah, I built and installed your branch, and deletion now complains about missing udisks (not 2)
 * pitti runs a write, to see whether he can reproduce the segfault
<xnox> pitti: make sure the old helper is killed on dbus, as it can stick around after upgrade.
<pitti> oh, indeed
<pitti> xnox: http://paste.ubuntu.com/5630671/
<xnox> hmmmm.....
<pitti> but it actually did remove all the files, so I can restart and write now
<xnox> this should fix that UnboundLocalError http://paste.ubuntu.com/5630681/
 * xnox should ponder at refactoring all the if's in that function.
<pitti> hm, the stack trace is not very useful; deep inside a libdbus callback, and tons of unintelligible PyEval_* stuff on top
<pitti> as if the client side has torn down some dbus proxy which still got a reply from the server or so
<xnox> pitti: interesting. So new udisks2 supports objectmanager interface, so by default when it's initialised we lookup and get proxies for everything udisks2 exports. I wonder if I should be cleaning up the manager myself.
<xnox> this is the other part of the reason why I'd like to move away from the gir and do it just with dbus, such that all proxies are a little bit more explicitly created & deleted.
<cjwatson> sarnold: It will often end up being a directory of symlinks.  Any complexity in sometimes collapsing this to a single symlink if all the images are current (which should be the case most of the time, I'd hope) is entirely internal to cdimage, though ...
<pitti> xnox: but the objectmanager object should also be unreffed automatically
<pitti> but yeah, that one is quite magic
<xnox> cjwatson: current-proposed, latest-crack, incomming. A few other names to choose from.
<cjwatson> xnox: I don't want to get into a time-sucking bikeshed argument
<cjwatson> If there's a single better option, propose it :)
<cjwatson> Also I refuse to put "crack" in a URL
<pitti> (or any reference to killing kittens, if possible)
<cjwatson> In general I don't think such a frequently used URL has any need to be flippant
<xnox> cjwatson: it's just "latest" sounds more attractive to prospective people who download images over "current". Meh.... it doesn't really matter.
<pitti> "untested"?
<xnox> would attract manual cd testers to "untested" which is exactly what we don't want them to test yet. =)
<xnox> on the other hand manual testers is small enough pool and we can communicate the meaning to them.
<cjwatson> "current-proposed" has a sensible analogy to raring-proposed
<xnox> "e.g. use iso tracker urls"
<mgz> can some ubuntu developer approve the nomination of bug 1054722 for raring? just want to mark it as fixed in that series.
<ubottu> bug 1054722 in gnome-control-center-signon (Ubuntu) "Newly added account appears at the top of the accounts list" [Undecided,New] https://launchpad.net/bugs/1054722
<xnox> mgz: done. any other series....?
<seb128> mgz, well, just mark it fixed, by default if a bug is fixed that's in the current serie
<mgz> xnox: nope, would require an sru for quantal and it's apparently too trivial to be worth fixing there
<mgz> seb128: this is true, but I like knowing when something was fixed when I look back a series hence
<xnox> seb128: there was no bug reference in the commit / .changes. hence there is no comment fixed in version 3.2.2.3 in raring.
<seb128> xnox, well, nothing stops you to copy manually the changelog of the upload that fixed it when closing the bug
<seb128> that's what I usually do
<seb128> "the issue was fixed in that version:
<seb128> <copy of changelog entry for the version>"
<mlankhorst> how do I force udev to re-emit all events?
<cjwatson> that's called "coldplugging", if that helps
<mlankhorst> yeah I just need to confirm a theory
<cjwatson> 'udevadm trigger' does it, possibly with some options.  May break your system.
<cjwatson> It'd be wise to limit it to a subsystem if you can
<mlankhorst> oh that's fine
<cjwatson> cf. /etc/init/udevtrigger.conf
<mlankhorst> in fact I want to see if I can make it crash in a similar way as in a bug :P
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1157614 looks suspiciously like xorg-server is running before coldplug was
<ubottu> Launchpad bug 1050494 in xserver-xorg-video-nouveau (Ubuntu) "duplicate for #1157614 Xorg crashed with SIGABRT in drmmode_from_scrn()" [High,Triaged]
<bdrung_> cjwatson: "current-proposed" is less confusing that "proposed". it tells me that current-proposed will become current after some defined rules
<cjwatson> could you follow up by mail so this is archived?
<xnox> ogra_: snap.
<ogra_> heh
<bdrung_> xnox: do you have a minute?
<xnox> bdrung_: yeah.
<xnox> what's up ? =)
<bdrung_> xnox: can you propose one or two sentences for --trailing-comma for the man page?
<bdrung_> "add trailing comma" is a little short for the man page.
<bdrung> btw, i found a bug in your patch and fixed it. :)
<xnox> bdrung: http://paste.ubuntu.com/5630896/
<xnox> bdrung: what was it?
<bdrung> xnox: thanks. "if "Uploaders" in paragraph: self._wrap_field()" misses trailing_comma and therefore the uploaders list were sorted, too
<xnox> ha, nice one.
<bdrung> xnox: typo "trailling comma" fixed :)
 * cjwatson tries not to get distracted into wondering about the rule underlying trail -> trailing but trial -> trialling
<cjwatson> (multiple syllables, I expect)
<bdrung> xnox: http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=cbd15890e3ddf7dc6c5f135d3bd4e60903797bb6
<bdrung> there will be soon an upload of devscripts
<xnox> awesome.
 * xnox case + psu collected for RMA, new case and psu expected on monday \o/
<Laney> skillz
<xnox> Laney: ebuyer even did free collection for RMA, parcelforce dude showed up to collect.
 * ogra_ would freak out if building a new machine would take so long
<BenC> infinity: my test builds only included one flavor
<BenC> infinity: and who the hell breaks 8250 in a .y update!?
<xnox> ogra_: i went with free 5 working day delivery. So 1 week for initial delivery, then 1 week of fiddling and figuring out what's broken (mostly blocked by finding people willing for me to use/test their PSU), then a quick RMA and new purchase. Should be 3 weeks in total.
<xnox> apperanttly newer i7 CPUs want more stable 12V than usual, hence a lower wattage PSUs work better, or those that claim to support intel's 12v v2.1 (or something like that)
<hallyn> infinity: hey - i'm confused.  openbios-ppc seems to build on arch, but gcc-powerpc-linux-gnu, which openbios-ppc depends on, only exists on amd64+i386 ?
<xnox> with uber-schenell nachsten tagen delivery it could have been 1.5 weeks in total.
<hallyn> (analogous packages for sparc seem to build fine on amd64/i386, but not sure what to do about arm)
<tumbleweed> bdrung: I assume the discussion about trailing commas that I had with someone, was with you (becaues initially -s added a trailing comma, and you talked me out of it) but no idea where that is in my irc logs
<cjwatson> hallyn: it's arch all - does it really matter whether it builds anywhere other than i386?
<hallyn> cjwatson: oh is that how that works?  sorry :)  now, in ppa it actually did fail on i386, but it seemed to complain abou tthe arm pkg missing
<cjwatson> that is how it works, yes - can I see the ppa build log/
<cjwatson> ?
<hallyn> cjwatson: https://launchpad.net/~serge-hallyn/+archive/crossc/+build/4382596
<hallyn> (confused why it's building on arm ppa builder)
<OdyX> tkamppeter_: 'CUPS 1.6.2 got released on Monday and I have packaged it for Raring.' => I'd appreciate slightly more recognition...
<xnox> hallyn: it's an odd name. it's not actually arm.
<hallyn> oh ok
<cjwatson> hallyn: oh, that's irrelevant :)  the "arm ppa builder" can build for any of i386/amd64/armhf depending on config
<hallyn> gotcha
<xnox> https://launchpad.net/builders/wani02 "Architecture: Intel 386 (virtual)"
<cjwatson> hallyn: the arch in the build log url tells you what it was actually doing
<cjwatson> (you can't rely on the current builder configuration; they're often rebalanced)
<hallyn> ok so the problem isn't at all what i thoguth it was then
<xnox> cjwatson: can we rename builders to be less confusing and not include arch name, when the builder is not actually arch-specific.
<cjwatson> hallyn: so that just means that gcc-sparc-linux-gnu was uninstallable in your PPA at the time when that build happened
<cjwatson> xnox: -> infinity
<xnox> infinity: s/arm// on all virtualised builders, as it's confusing to see an "arm ppa builder" picking up i386/amd64 builders.
<xnox> please =)
<cjwatson> xnox: definitely not as simple as that because we do need to know which of them are arm-capable.
<cjwatson> hallyn: I'm not sure where gcc-4.7-multilib-sparc-linux-gnu is meant to come from; it's not in the archive and I don't immediately see it in your PPA
<hallyn> cjwatson: it should in ppa, built from gcc-defaults-sparc-cross, lemme recheck
<cjwatson> gcc-defaults-sparc-cross only builds the top-level metapackages, not the compiler itself
 * xnox universal... flexible...
<cjwatson> you need a gcc-4.7-sparc-cross
<hallyn> well huh.  i thought i'd pushed that too.  but never started that one.
<hallyn> sorry.  thanks :)
<cjwatson> np
<bdrung> tumbleweed: i don't like trailing commas, but having an option to add it is a compromise
<xnox> stgraber: I added comments / questions to the https://wiki.ubuntu.com/ImageBasedUpgrades/Mobile
<timrc> cjwatson, Throwing my suggestion into the hat for maybe 'tip' or 'current-untested' rather than 'latest'
 * ogra_ likes "current-untested"
<ogra_> tip is to technical imho
<timrc> ogra_, I think 'current-untested' is the stronger of the two as well
<tumbleweed> bdrung: yeah
<cjwatson> timrc: how about current-proposed?
<cjwatson> I think "current-untested" encourages human testers to have a go, a little more strongly than I'd like
<cjwatson> (and at some point I have to actually paint this bikeshed)
<janimo> FWIW kernel team uses 'next' in their WIP master branch
<rbasak> pre-qa? pre-auto-qa? pending? Focusing on putting off human testers here, so that they can focus on current.
<ogra_> "current-untested-not-really-for-human-testers.-but-proposed"
 * didrocks likes current-proposed
<ogra_> we could then promote http://llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogo.ch/ for link shortening :)
<cjwatson> I was thinking of pending too
<cjwatson> or even pending-autotests or something
<ogra_> "current-untested-not-really-for-human-testers-but-peding-autotestes-to-become-proposed"
<cjwatson> but seriously ...
<ogra_> (go with current-propsed)
<rbasak> "proposed" implies that users should test it. Like they do the proposed pockets for SRUs
<cjwatson> like they don't raring-proposed :)
<cjwatson> (or shouldn't, anyway)
<rbasak> :)
<cjwatson> pending-autotests is fairly descriptive
<rbasak> +1
<cjwatson> although it's confusing for the cases that *don't* have autotesting
<rbasak> Just "pending" then?
<ogra_> pending-testing ?
<pitti> well, britney also does some installability testing, after all?
<rbasak> "pending" implies that users should wait for something
<cjwatson> pending-testing> no, that invites human testing
<cjwatson> pitti: sure, but no images are built from rarnig-proposed
<ogra_> geez english is such a complicated language
<rbasak> Nobody wants to hit something that says "pending" on its own if they don't know why it's pending, since it's implied that it will change under their feet
<cjwatson> so that distinction isn't really helpful to draw
<cjwatson> yeah, rbasak may have nailed it here
<rbasak> ogra_: steal bits of language from a load of other languages and you end up with a twisted, confusing, unmaintainable mess :)
<ogra_> haha yeah
<ogra_> i generally find english easier than german though
<ogra_> (my fingers often dont ... )
<rbasak> German is confusing for entirely different reasons :)
<ogra_> not if you grew up with it :)
<rbasak> True
<rbasak> (I presume!)
<rbasak> How about "broken"? Nobody would bother testing that :-)
<xnox> "maybe-broken" is more descriptive.
<rbasak> presumed-broken?
<xnox> "hostly-harmless"
<xnox> "mostly-harmless"
<timrc> cjwatson, sorry, I had toddler-duty... While I feel that maybe it will invite human testing, 'untested' is more explicit... if the only difference between 'current' and 'latest' is smoke testing, what about 'current-not-smoke-tested'... it's sort of long, but I like the explicit nature of it
<timrc> or maybe 'current-pending-autotests' *shrug*
<timrc> not terribly succinct :(
<pitti> +1 for "pending-autotests"
<tkamppeter_> OdyX, sorry, I wanted to say that I have synced it into Raring, for the reporter of the bug to test whether his problem is solved. Probably confused it with Ghostscript.
<tkamppeter> pitti, hi
<OdyX> tkamppeter: no problem I'm not offended or anything, just surprised. FYI, I'm working on splitting the documentation and common files to cups-server-common to reduce the arch-specific packages' sizes; it'll go through NEW.
<seiflotfy> tedg: ping
<tedg> Howdy seiflotfy
<seiflotfy> tedg: in you new work can you make sure you use libzeitgeist2
<seiflotfy> no more dbus roundtrips :D
<seiflotfy> direct access when reading
<seiflotfy> only writing goes over dbus
<seiflotfy> saves a lot ofserializing and time
<tedg> seiflotfy, Yup, definitely going to do that :-)  Only reason I'd consider ZG .
<tedg> seiflotfy, It's why we didn't use it before.
<seiflotfy> tedg: sweeeeeeeeeet
<seiflotfy> tedg: we are discussing something new
<tedg> Uh, oh.  ;-)
<hyperair> hmm, would porting unity to that fix the horrible unity dash lags?
<seiflotfy> we might allow applications to host thier own instance of zeitgeist in their process and expose via dbus
<seiflotfy> distributed logs
<seiflotfy> basically the idea is to have private logs per application
<seiflotfy> and if the application wants it can expose itself over dbus :D
<seiflotfy> hyperair: oh yes
<seiflotfy> you can count on 100% speed increase
<hyperair> yay.
<seiflotfy> hyperair: i could actually do this on the weekend
<seiflotfy> :D
<seiflotfy> its just the lenses right?
<seiflotfy> then i will do it on the weekend guys :D
<seiflotfy> tedg: r u using a thinkpad
<seiflotfy> anybody using thinkpad and dealing with wireless issues
<tedg> seiflotfy, I think that might not work well with sandboxing.
<tedg> seiflotfy, In general we don't want applications exporting services by default.
<seiflotfy> tedg: its just an "option"
<tedg> seiflotfy, Sure, but trying to warn you :-)
<seiflotfy> :D
<seiflotfy> ok warning reveived
<seiflotfy> it was kamstrups idea :D
<tedg> seiflotfy, Oh, then I know to be *really* scared of it!
<seiflotfy> LOL
<seiflotfy> anybody having wireless issues under raring
<seiflotfy> ?
<tkamppeter> OdyX, when you are once on CUPS, can you remove the duplicate logrotate (bug 1157758), only cups-daemon should logrotate, not cups.
<ubottu> bug 1157758 in cups (Ubuntu) ""cups" and "cups-daemon" both logrotate /var/log/cups/*log" [Undecided,New] https://launchpad.net/bugs/1157758
<tedg> seiflotfy, It seems the ZG in raring is 0.3.18?  Is that right?
<seiflotfy> that is libzeitgeist
<seiflotfy> that is the old one
<seiflotfy> we packaged the new stuff
<tedg> seiflotfy, Ah, okay.  Where's the new stuff?
<seiflotfy> getting you the ricotzppa
<seiflotfy> https://launchpad.net/~ricotz/+archive/experimental
<seiflotfy> tedg:
<tkamppeter> pitti, around?
<pitti> tkamppeter: meeting
<tedg> seiflotfy, Cool, thanks!
<OdyX> tkamppeter: as I commented, the mv_conffile is there already for migrations in Debian, so I guess it needs a manual hashsum check and rm_conffile again.
<tseliot> infinity: have you investigated the whole "alias $module off" thing?
<infinity> tseliot: I haven't put any time into it so far this week, no.
<infinity> tseliot: Just keep things business as usual for now until we come up with some solid answers, I suppose.
<tseliot> infinity: ok
<davlefou> hi, i look for to create an systrait dev under gnome, 2.6 and 3.x
<tkamppeter> OdyX, in Ubuntu the split-out of cups-daemon was done with 1.6.1-0ubuntu14 and the debian/cups.maintscript with mv_conffile for cups-daemon was introduced in -0ubuntu15. What needs to get changed to get a correct transition here?
<cjohnston> rsalveti: can the milestones be fixed on https://launchpad.net/ubuntu/+spec/client-1303-sound-support-pulse-audioflinger please
<lool> cjwatson: hey, I'd like to introduce SDK seed(s) to generate meta-packages; there's an ubuntu-sdk package already though; I would naturally use the regular ubuntu.raring seeds for this and corresponding meta; is that ok?  I guess I can leave stuff in universe for now despite that
<cjohnston> rsalveti: since it is 's' it needs to be 13.05 or later
<rsalveti> cjohnston: fixed how exactly? remove the milestone from the workitems?
<rsalveti> cjohnston: hm, that's now what was recommended for us
<rsalveti> lool: ^
<lool> rsalveti: it seems this uses a raring milestone while being targeted at s
<cjohnston> rsalveti: if it series was 'raring' the milestones would be correct
<cjwatson> lool: is everything involved in main, or intended to reach main by raring?
<lool> I'm surprized launchpad is ok with tihs actually
<lool> cjwatson: I am not sure we're ready to put a supported tag on it, so I thought it would stay in universe, but in reality I don't know
<rsalveti> lool: cjohnston: right, but I want it target for s-series but a milestone as "13.04"
<cjwatson> lool: then please don't put it in ubuntu.raring; I suggest you use ubuntu-touch.raring for now
<lool> cjwatson: I'm mostly trying to arrange things so that we use proper seeds and meta-packages in place of manually maintained meta-packages
<cjwatson> sure
<rsalveti> and it seems s-series would be 13.05 or later
<lool> cjwatson: ok
<cjwatson> you can extend ubuntu-touch-meta to take over the ubuntu-sdk metapackage, I guess
<rsalveti> so that's why people recommended to use the old raring-based milestone
<lool> cjwatson: incidentally, this might make it easier to generate a meta from the current source
<cjohnston> correct... 's' starts with 13.05 rsalveti
<cjohnston> rsalveti: then target it to raring..
<cjohnston> who recommended it?
<rsalveti> well, I'm doing some work which will land at s, not raring
<rsalveti> but I'm planning to do that at 13.04
<lool> cjwatson: Ah so it'd be ugly to kludge the meta in the same source as current; ok, will do an ubuntu-touch-meta then
<cjwatson> lool: you miss my point, there's already an ubuntu-touch-meta
<rsalveti> I know it's confusing, because people are dealing with monthly planning x release/snapshots milestones
<cjwatson> you can extend it for ubuntu-sdk
<cjwatson> you can't use ubuntu-meta because (as ogra and I discovered the other day) there are corner cases that make it infeasible to use that for stuff not in main
<rsalveti> so I'm planning my s-series based work for april
<OdyX> tkamppeter: rm_conffile in cups.maintscript should be enough I think.
<rsalveti> :-)
<lool> cjohnston: Would it make sense to have milestones for march and april in s too?
<cjwatson> it can always be merged into ubuntu-meta later
<lool> hmm would be confusing as the milestones wouldn't follow the same pattern
<cjohnston> lool: outside of my ability to answer
<rsalveti> cjohnston: who == people planning the work for touch, bfiller and a few others
<cjwatson> I don't think it's worth changing around r/s milestones for the sake of the next month or two
<cjohnston> I tend to agree with cjwatson.
<lool> rsalveti: problem is that milestones have a series attached, so if we were to add new ones with s for march and april they would clash with the march and april one of raring
<lool> rsalveti: and that would be hugely confusing -- 3 sets of overlaping milestones
<cjwatson> if you think the current situation is confusing then ... yes, what lool said
<rsalveti> right, I can change, it's just that with this scheme you cannot plan work before the series is open
<cjwatson> rsalveti: sure you can, you  artificially
<cjwatson> *you just have to lie and artificially target it at raring
<rsalveti> right, not using blueprints :-)
<cjwatson> you can do it with blueprints fine
<lool> cjwatson: ubuntu-touch-meta >> ah, hadn't noticed, thanks
<cjohnston> xnox: has a BP for the 's' series targeted to 12.10-beta-1
<rsalveti> cjohnston: right, that lie is the tricky part regarding planning
<cjwatson> it really doesn't desperately matter if a blueprint is targeted at raring but doesn't actually land code until s :)  you can always note it in the whiteboard
<cjwatson> it's not tricky, you just have to not care
<cjwatson> easy :)
<cjohnston> :-)
<lool> then it wont show up in the s tracker
<cjwatson> just accept that the raring tracker is where work up to April goes ...
<cjwatson> it would be bad for work in a given month to be spread across two trackers anyway
<cjwatson> because that would confuse capacity tracking
<lool> +upcoming-work kind of does away with this whole problem as it ends up piling all work for a specific date rather than splitting by series
<rsalveti> well, we're using blueprint to track work now based on series x months (instead of kanban or anything related)
<lool> cjwatson: good point
<lool> rsalveti: So I guess I need to reword my recommendation
<lool> I need to note that one needs to split blueprints so that they don't overlap series boundaries and that work done during a series shoudl be targeted at this series
<rsalveti> lool: yup :-)
<rsalveti> lool: not the proper planning tool (based on project planning)
<rsalveti> at least with these constraints
<cjohnston> I say we create series 'z' and just make a milestone every month from now until eternity and work off that
<lool> cjwatson: (I wish I had found an overlapping freenode channel with sergiusens and you to discuss this  :-) sergiusens just told me the jenkins job doing smoke testing is currently borken and that he will soon fix it, I've asked him to please ping me when it's back up as to figure the best SSH trigger mechanism from jenkins to cdimage to update /pending
<lool> cjwatson: (BTW while reading the thread I thought of "pending" as a possible name for it too, +1 on it)
 * ogra_ returns
 * lool exits
<ogra_> lool, anything wrong with the meta/seeds ?
<tkamppeter> OdyX, so cups.maintscript should contain BOTH "mv_conffile /etc/logrotate.d/cups /etc/logrotate.d/cups-daemon 1.6.1~" and "rm_conffile /etc/logrotate.d/cups 1.6.1~"?
<lool> ogra_: this is about using seeds for SDK; I don't think you were involved there so far, but happy to update you
<lool> I intend to send a summary RSN
<ogra_> ah, k
<cjwatson> lool: trigger> I think that work item of yours has been overtaken by events; I've been discussing that with the QA team and we have an agreed interface
<cjwatson> lool: it just needs me to finish the code and then plars can hook it up
<ogra_> i just saw my name and ubuntu-touch-meta mentioned above
<OdyX> tkamppeter: no, rm_conffile â¦ 1.6.2-2~ (so that it first gets moved away, then rm'ed if it's still there)
<OdyX> tkamppeter: the latter version must be the one (+ "~") in which the rm_conffile addition gets added.
<cjwatson> lool: (since it's easier to set this all up for the smoke testing jobs that correspond to images already fully handled by cdimage, rather than near-future jobs)
<lool> cjwatson: Good; I didn't want to block this work any further  :-)
<OdyX> tkamppeter: I think it would work, but I'm not sure, worth testing.
<cjwatson> it's just tedious filesystem-mangling code at this point
<lool> cjwatson: so are there triggers from cdimage to QA already then?  it seems we have two sets of smoketests now
<cjwatson> other way round, QA will ssh to cdimage to notify
<lool> cjwatson: but how does QA discover there's a new image to test?
<cjwatson> cdimage doesn't trigger QA for smoketesting; QA polls for that
<lool> right
<cjwatson> it seems to work responsively enough so I haven't worried about it
<lool> cjwatson: While I think the jenkins smoke tests were triggered by the jenkins image build job
<cjwatson> seems like the sort of thing jenkins loves doing
<lool> fair enough
<lool> the only thing is that I'm not sure the smoke tests match in any way
<lool> we ought to run all the ones we have
<cjwatson> how do you mean?
<lool> cjwatson: I am not sure the smoke tests run by QA by polling cdimage are the same as the ones that were run by jenkins so far
<cjwatson> uh - I'm not aware of smoke tests run by QA that aren't in jenkins
<cjwatson> so I'm not sure what you mean there
<lool> hmm it might be too jenkinses
<lool> but perhaps I'm just confused and they are the same one
<cjwatson> there are various jenkins instances doing different things
<cjwatson> which reminds me, I only got a firewall hole opened for the PS jenkins (which will do touch images), not for the UE one
<cjwatson> plars: what's the internal IP address of the jenkins instance that things like the ubuntu desktop smoke tests run on?
<lool> right, so I think the PS jenkins also does smoke testing
<plars> lool, cjwatson: there's no reason we couldn't have cdimage trigger the job, but the way it's working now is by watching a url for a change, and I see no reason why we couldn't just move that to look at /pending
<cjwatson> plars: agreed
<cjwatson> lool: right, for a different set of images - that's not a problem
<plars> cjwatson: 10.98.0.1 for most of them, there's another lab that handles some other things but all the iso testing on VMs runs out of that one
<cjwatson> plars: I did think of one other wart - it's not one single smoke-test job per image on your end, it's several.  is there an easy way to say "poke nusakan to update the current symlink once all smoke tests for this image have passed"?
<lool> cjwatson: so would we have the PS jenkins poll cdimage for touch smoke tests just like the UE one is polling for desktop smoke tests, or would we want to move the touch smoke testing jobs to the UE jenkins?
<cjwatson> lool: I see no reason to move it
<plars> cjwatson: I think all we care about for publishing it is the default smoke test, which just looks to see if it's installable and basically sane before kicking the rest off
<plars> cjwatson: at that point, it's "testable" for both manual and the rest of the automated tests
<cjwatson> plars: hm, you think?  ok, I guess we can cross that bridge when we come to it
<lool> cjwatson: ok, so we'd have triggers from two locations then
<cjwatson> lool: that's fine, covered in the design
<cjwatson> or rather just totally not an issue for the design
<plars> cjwatson: if we want more testing in that basic smoke run, then we should add the tests there, but I don't think the goal was to do exhaustive testing or anything close to it before publishing the image right?
<lool> plars: Would you handle the PS jenkins triggers too?
<cjwatson> plars: the goal is amorphous :)  some testing is clearly better than now
<plars> cjwatson: in my understanding, we just wanted a basic sanity check that the image is in a usable state before putting it out as the current
<plars> cjwatson: yes
<plars> lool: not sure what you mean
<cjwatson> plars: though, if the full set of smoke tests doesn't take too long, I can see the argument that we should just run them all before offering it to human testers
<lool> plars: smoke testing of the touch images, do you handle that too or just of desktop images?
<roaksoax> slangasek: howdy!! So I just merged your branches. I'll backport that to precise/quantal and re-upload! Thanks for the review!!
<cjwatson> plars: ticket reopened for 10.98.0.1
<slangasek> roaksoax: great, thanks :)
<plars> lool: I do some basic testing of the touch images, primarily things like eventstat and smem for now. They do their own testing with autopilot and things like that which I chose not to replicate.
<plars> lool: there's no reason we can't detect the new images from them the same way on cdimage, that's how I see when there's something new to test now
<plars> lool: although I'm not sure if we ever expect to run into a situation where the device specific portion and the rootfs get built in different intervals and need to be tracked separately... oh hell it's hwpacks/rootfs all over again :)
<lool> right, so I came to this conversation assuming we were mainly hooking smoke testing of the touch images as these were the latest images being put on cdimage, but I think cjwatson and plars were mainly thinking of existing desktop smoke test and touch smoke testing living its own life
<tkamppeter> OdyX, so I will make a package cups 1.6.2-1ubuntu1 with debian/cups.maintscript containing "mv_conffile /etc/logrotate.d/cups /etc/logrotate.d/cups-daemon 1.6.1~" and "rm_conffile /etc/logrotate.d/cups 1.6.2-1ubuntu1~" and upload that to see whether this solves the problem for the reporter of the bug.
<lool> now it's clear to me with have two parallel systems, with two jenkins and two definitions of "smoke testing" for touch vs. desktop images
<lool> which isn't hard to handle technically, but I want to make sure we list touch and desktop actions for the /latest plan
<OdyX> tkamppeter: yeah that'd be great, then I could integrate that in 1.6.2-3, including some testing...
<lool> and don't just hook up smoke testing for one and not the other
<plars> lool: so I don't currently have a "smoke test" of the ubuntu touch images other than install, and I use that as a blocker to running things like smem. Also note that this runs out of a separate lab and seems to break frequently at the moment because of changes to phablet-tools
<lool> plars: but sergiusens has smoke tests for touch images
<cjwatson> lool: it's the same code either way
<cjwatson> lool: I really don't think we need to worry about the "duplication" here - it's a non-issue from my perspective
<lool> plars: see #ubuntu-touch backlog
<plars> lool: very likely, yes.  If we want to do something similar for ubuntu-touch images, I see no reason why we couldn't
<rsalveti> plars: guess we'd also need a way to hook up the battery, and force a device reboot if needed
<tkamppeter> OdyX, I have /etc/logrotate.d/cups-daemon and /etc/logrotate.d/cups.dpkg-new. Is /etc/logrotate.d/cups.dpkg-new automatically ignored by logrotate?
<cjwatson> lool: I'm entirely aware that touch smoke testing is the driving goal for this; using it for desktop smoke testing is merely a convenient ride-along, and means that I can get this work done *now* rather than later
<lool> cjwatson: I dont worry about duplication, just that both get smoke tested; e.g. poking two holes in the fw instead of one, and not using two different SSH triggers from jenkins if possible
<plars> rsalveti: that's another sticking point, yes.  At the moment, I rely on things not breaking in a terrible way, or the devices could need some manual intervention.  Also, ADB flakes out occasionally and has to be restarted
<cjwatson> lool: two holes in the firewall is a completely trivial issue, and the backend of the ssh trigger will be identical
<rsalveti> plars: indeed
<lool> cjwatson: there is no technical challenge here, just would like the right folks to be involved  :-)
<rsalveti> plars: are we driving all the tests via ssh?
<cjwatson> lool: (the ssh trigger will have a set of parameters for the project/series/image-type/build-id/architecture, or sufficient of those to get the job done)
<rsalveti> we were discussing about having some sort of adb for ubuntu
<cjwatson> lool: I e-mailed relevant QA folks last night and have been having a conversation about the details for a good part of today; sorry I forgot to CC you ...
<plars> cjwatson, rsalveti: so what I like here is that smoke testing is a nice add-on, but if something ever goes crazy with it, we don't actually prevent anyone from seeing/using the images - it's always possible to get at the new/pending images
<plars> rsalveti: adb/ssh yes
<cjwatson> I don't think there's anything especially touch-specific about any of it
<plars> rsalveti: some initial setup needs to be done over adb
<cjwatson> plars: right, that was always a requirement from my POV
<plars> rsalveti: I was asking for adb support for ubuntu images in linaro too, from a test automation perspective, it gives us some interesting possibilities
<rsalveti> plars: yeah
<rsalveti> plars: it might help deploying apps via sdk as well
<lool> cjwatson: I probably didn't need to be Cc:ed; is there a blueprint tracking the QA side / smoke test integration efforts outside if https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds?
<cjwatson> just that
<lool> ok, will update to list sergiusens somewhere to add a hook for the PS jenkins smoketests
<lool> plars: cjwatson: have updated WIs in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds to match my understanding
<lool> will ask sergiusens whether he can join here
<lool> plars: mind syncing with sergiusens to keep the PS and UE jenkins smoketests vaguely aligned?
<plars> lool: +1
<tvoss> slangasek, ping
<slangasek> tvoss: hey there
<stgraber> xnox: I think I answered all your questions
<xnox> stgraber: thanks. everything is sound. thanks a lot for clarifying.
 * seb128 grrr at powerpc, 2 builders and one is stucked on "cleaning build tree" for over 25 minutes now
<seb128> ok, it's qt, but what sort of disk is that :p
<sarnold> qt4-x11 took me 1:05 to build on an i7 with ssd and 16 gigs ram... give those poor ppcs a break :)
<cjwatson> seb128: chasing on #webops
<seb128> sarnold, build took 7 hours, that's ok, I'm just wondering if the builder is stucked
<seb128> cjwatson, thanks
<sarnold> seb128: owwww :)
<cjwatson> seb128: last qt4-x11 build on adare took 9h25m, so I'm not worried yet
<ogra_> seb128, you didnt get the memo ? all fast disks are now assigned to ubuntu-touch work, buildds were switched to SD cards
<cjwatson> (but you can always ask ops if you're concerned)
<seb128> cjwatson, no, that's ok, I will just be patient and wait a bit longer, it will eventually be done and pick another build :p
<cjwatson> should be fine once sagari's back
<seb128> cjwatson, thanks
<cjwatson> ... which it is now
<seb128> \o/
<bdrung> Laney: bug #1156692
<ubottu> bug 1156692 in unknown-horizons (Ubuntu) "FFe: Sync unknown-horizons 2013.1b+ds1-2 (universe) from Debian experimental (main)" [Undecided,Fix released] https://launchpad.net/bugs/1156692
<Laney> I don't see how.
<Laney> A release team member saying "OK" and moving the bug to the next stage of the process is unclear?
<tumbleweed> Laney: better to be explicit
<Laney> The only reason would be to avoid this pointless conversation
<tumbleweed> exactly :)
<roaksoax> slangasek: btw.. the update for the licenses (BSD to BSD-3-Clause) in the case of yui3, the package that came from debian uses BSD instead of BSD-3-Clause
<roaksoax> slangasek: should I change it even if the actual package in newer releases use BSD instead of BSD-3-Clause?
<roaksoax> same as for  raphael with MIT
<xnox> Laney: to me it's not clear if you were wearing release team hat or not. =))))))
 * xnox is just being pedantic here, I actually did understand what you meant.
<slangasek> roaksoax: I don't want to cause you a maintenance headache here, and as I said it's not an SRU blocker at all - they just technically aren't the right values to be used in copyright-format 1.0
 * Laney goes to the climbing centre instead :-)
<roaksoax> slangasek: ok :)
<roaksoax> slangasek: ok uploaded to btoh -precise, -quantal
<roaksoax> err {precise,quantal}-proposed
<slangasek> roaksoax: great, thanks
<roaksoax> slangasek: thank to you for the review :)
<OdyX> tkamppeter: the libp11-kit-gnome-keyring isn't in Debian yet, I can't add it to Debian's cups.
<tkamppeter> OdyX, but why does Ubuntu's CUPS need it? The source package is the same for both Debian and Ubuntu.
<OdyX> tkamppeter: missing depends in Ubuntu's build-depends ?
<tkamppeter> OdyX, I have already uploaded -1ubuntu2, see bug 1157904.
<ubottu> bug 1157904 in cups (Ubuntu) "p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory" [Undecided,Fix committed] https://launchpad.net/bugs/1157904
<seb128> hum
<seb128> does "Replaces" has any impact on the apt resolver?
<seb128> or said different "can using Replaces have an impact on the upgrade solution between "uninstall stuff" and "upgrade the source""?
<slangasek> seb128: not on its own, only if combined with Conflicts/Breaks
<seb128> slangasek, contexts is bug #1157747
<ubottu> bug 1157747 in unity-asset-pool (Ubuntu) "package unity-asset-pool 0.8.24daily12.12.05-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/icons/hicolor/32x32/apps/facebook.png', which is also in package account-plugin-facebook 0.10bzr13.02.27-0ubuntu1" [Undecided,Fix released] https://launchpad.net/bugs/1157747
<seb128> slangasek, new unity-asset-pool replaces files from the old account-* packages
<seb128> kenvandine used a breaks/replaces combo first
<seb128> which leads apt to want to remove the account-* rather than install the new unity-asset-pool apparently
<seb128> he said that dropping the "Replaces:" and keeping only "Breaks:" seems to work better
<seb128> is that right?
<seb128> I though "Replaces" was meant as "it's ok to overwrite file from"
<slangasek> seb128: where did he say that?  I don't see it on the bug
<slangasek> that is what Replaces: means, and we shouldn't be leaving it out
<seb128> slangasek, we just discussed it on #ubuntu-desktop and
<seb128> https://code.launchpad.net/~ken-vandine/unity-asset-pool/0.8.24daily13.03.20.1-0ubuntu2/+merge/154495
<seb128> the changelog on that mr is wrong
<seb128> ups
<seb128> ignore the changelog note
<seb128> he fixed it :p
<seb128> kenvandine, ^
<kenvandine> humm
<kenvandine> si with replaces and breaks dist-upgrade was trying to remove all the account-plugins-* packages
<kenvandine> s/si/so
<kenvandine> but
<kenvandine> not apt-get install unity-asset-pool
<kenvandine> that did the right thing
<kenvandine> but dist-upgrade didn't
<slangasek> kenvandine: would like to see the full dist-upgrade output, and possibly with apt debugging
<seb128> kenvandine, dist-upgrade here:
<seb128> The following NEW packages will be installed:
<seb128>   account-plugin-generic-oauth
<seb128> The following packages will be upgraded:
<seb128>   account-plugin-facebook account-plugin-flickr account-plugin-google
<seb128>   account-plugin-icons account-plugin-identica account-plugin-twitter
<seb128>   account-plugin-windows-live unity-asset-pool unity-webapps-common
<seb128> 9 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
<seb128> seems to do the right thing
<seb128> with the current version
<kenvandine> seb128, odd!
<kenvandine> ChrisTownsend saw the removal
<seb128> what slangasek said otherwise
<kenvandine> and i tried too and got the same result
<seb128> we need a log from something who has the issue
<seb128> can you downgrade and try again?
<slangasek> (apt-get dist-upgrade -oDebug::pkgProblemResolver=1)
<kenvandine> lets see if christownsend can try still
<ChrisTownsend> seb128: Ok, here
<seb128> ChrisTownsend, thanks
<seb128> can you copy the log on pastebin?
<ChrisTownsend> seb128: I ran the command, should I go ahead and do the upgrade or grab the log as is?
<slangasek> ChrisTownsend: we just want the log for what apt is showing, no need for the actual upgrade
<ChrisTownsend> slangasek: Hmm, where is this particular log stashed?  /var/log/apt/??  or something else
<slangasek> ChrisTownsend: ah, the output of the command
<slangasek> ChrisTownsend: best to do 'apt-get dist-upgrade -oDebug::pkgProblemResolver=1'
<ChrisTownsend> slangasek: Ah, ok.  I did that.  I'll get a pastebin soon.
<seb128> ChrisTownsend, running with -oDebug... should give you a lot of infos on stdout
<ChrisTownsend> It really didn't output much more than usual.
<ChrisTownsend> slangasek: seb128: http://pastebin.ubuntu.com/5632282/
<seb128> ChrisTownsend, that doesn't want to remove anything
<seb128> kenvandine, ^
<ChrisTownsend> Hmm, my other machine is the one that complained.
<seb128> can you get a lot from this one?
<seb128> log
<kenvandine> maybe my new package was published?
<seb128> it's in proposed only
<kenvandine> oh right
<seb128> ChrisTownsend, do you have raring-proposed enabled?
<ChrisTownsend> seb128: Not that I'm aware of, but let me look.
<ChrisTownsend> I just confirmed my other machine does still complain.  I'll get that in a bit.
<kenvandine> apt-cache policy unity-asset-pool
<directhex> so... i've been tracking a horrible evolution crash bug today, which is fixed in 3.6.4. there's a 22 line patch to fix said bug. is it too late to get that into raring? or as a fix for quantal, for that matter?
<ChrisTownsend> Candidate: 0.8.24daily13.03.20.1-0ubuntu1
<seb128> directhex, cyphermox is working on updating evo to 3.6.4 for raring
<directhex> oh. well, that'd help.
<seb128> ChrisTownsend, please get the log from the box which has the issue, using -oDebug::pkgProblemResolver=1
<ChrisTownsend> seb128: Yep, working on it.
<seb128> thanks
<ChrisTownsend> http://pastebin.ubuntu.com/5632300/
<directhex> cyphermox, is there anything i can do to assist with that? i can commit a debian evolution maintainer's time to making it happen, who already has some 3.6.4 packages for 12.04 going.
<ChrisTownsend> seb128:  slangasek: ^^^
<slangasek> ChrisTownsend: so the problem is that there's no newer version of account-plugin-facebook available that satisfies the breaks/replaces
<slangasek> kenvandine: are account-plugin-* not updated yet?
<slangasek> these need to be updated as a group
<kenvandine> they are
<kenvandine> for me when i tried apt-get install unity-asset-pool
<slangasek> ChrisTownsend: 'apt-cache policy account-plugin-facebook' please?
<kenvandine> it said it would install those
<seb128> outdated mirror?
<kenvandine> or upgrade those rather
<kenvandine> i am not using a mirror
<seb128> can you get us a debug log? :p
<kenvandine> not really... since doing this i have kind of hosed myself...
<kenvandine> with the scopes testing PPA :)
<seb128> :-(
<seb128> let's wait for ChrisTownsend
<kenvandine> but luckily ChrisTownsend still has a reproducer :)
<ChrisTownsend> Working on it
<kenvandine> i have since discovered that unity-asset-pool now conflicts with files in some of the new scopes in that prevalidation ppa
<ChrisTownsend> http://pastebin.ubuntu.com/5632329/
<kenvandine> and purging that has done really bad things :)
<slangasek> kenvandine: er, so isn't the issue that you've published unity-asset-pool using Breaks: to raring, but the account-plugins* are *not* published to raring?
<kenvandine> oh, you don't have the new one
<slangasek> kenvandine: you have Breaks/Replaces: account-plugin-facebook (<= 0.10bzr13.02.27-0ubuntu1), and that's the current version of a-p-f in raring
 * mlankhorst amusedly wonders what makes people think it's a good idea to accept a proposed dist-upgrade that removes the entire i386 arch
<seb128> slangasek, how can that happen?
<slangasek> this Breaks/Replaces is published in the version of unity-asset-pool /in raring/
<seb128> slangasek, how can u-a-p move to raring with a breaks not fullfiled?
<ChrisTownsend> I did an update not very long ago.
<ChrisTownsend> I can try again though
<kenvandine> i see...it's because of proposed vs raring
<kenvandine> i can revert that last update and put the replaces back in
<seb128> launchpad says the plugin have been moved to raring an hour ago
<slangasek> seb128: because the requirement for proposed migration is that packages be installable, not that they be co-installable with arbitrary other sets of packages
<slangasek> seb128: nothing in the archive depends on both u-a-p and a-p-f, so britney doesn't care that they can't be installed at the same time!
<seb128> hum, ok, I see
<seb128> second bug that goes through today, the first one was a lack of Replaces:
<seb128> kenvandine, in any case please put the Replaces: back for the next upload
<ChrisTownsend> Ok, strange, I did another update just now and now it's good.
<seb128> ChrisTownsend, good, and not strange
<seb128> it means account-plugins just moved from raring-proposed to raring I guess
 * kenvandine uploads again :)
<slangasek> right
<ChrisTownsend> seb128: Ok
<ChrisTownsend> I had wondered what would happen when/if these packages arrived at different times in the archive and I guess I found out:)
<ChrisTownsend> Thanks seb128, slangasek, kenvandine!
<seb128> ChrisTownsend, thanks for helping figuring out the issue!
<ChrisTownsend> seb128: No problem at all!
<slangasek> seb128, kenvandine: permanent fix: make something depend on all of these packages so that coinstallability is enforced; currently, a-p-f is a dep of ubuntu-touch and u-a-p is a dep of unity, so nothing tells britney that they need to be coinstallable
<seb128> slangasek, well, it's hard to make those *depends*, that's the recommended list of plugins but it's fair enough to uninstall protocols you don't need
<seb128> recommends don't enforce things the same way though...
<slangasek> hmm
<slangasek> we could conceivably make britney consider Recommends as well
<slangasek> cjwatson: ^^ should britney be paying attention to Recommends for installability?
<Laney> directhex: if you want to toss me the patch (ideally a debdiff) in a bug then I can look at sponsoring that to $your_favourite_release tomorrow when I patch pilot
<Laney> assuming the backported commit fixes it, that is
<ambroff> Howdy folks. We have an internal apt repository for lucid that we're maintaining with reprepro. We only had packages for lucid in there, and now I'm rebuilding a bunch of packages for precise and naively thought that I could just add a second block to conf/distributions with "precise" as the codename and use the same component.
<ambroff> but that obviously doesn't work, since the package versions are the same and they will conflict in the pool tree
<ambroff> so, obviously I'm missunderstanding how this is supposed to work.
<ambroff> How is this generally done?
<slangasek> ambroff: by not reusing package versions for distinct builds
<ambroff> Hrm, OK, I didn't think it would be such a manual process.
<ambroff> so when the same upstream release is packaged for the next upcoming Ubuntu release, the package version is just bumped?
<sarnold> ambroff: here's one suggested versioning scheme for building the 'same version' for multiple releases: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<ambroff> awesome thanks sarnold and slangasek
<ambroff> I'll go over that
<slangasek> ambroff: we don't as a rule "repackage" software for each Ubuntu release; the binaries are carried forward from one release to the next, and only rebuilt when a) changes are needed to the package, or b) there's a transition to a library it uses
 * calc got his old nick back :)
<ambroff> Yeah I assumed that was true, but I was worried about some unkown changes in debhelpers or sonames so I thought it seemed like the safest thing to do.
<ambroff> also, how would you even add it to multiple "codenames" in the repo so you could have (in my case)
<ambroff> deb .... lucid production
<ambroff> deb ... precise production
<ambroff> well, I guess you're saying I wouldn't
<ambroff> because that's stupid
<ambroff> :)
<slangasek> ambroff: oh, you can certainly have a .deb referenced by multiple Packages files
<slangasek> but the tools I know that do this are, er, the big ones used by the Debian and Ubuntu archives
<slangasek> I don't know if / how reprepro does this
<ambroff> ah, that makes sense
<ambroff> because reprepro just panics and bails
<ambroff> it probably doesn't support that
<ambroff> OK, thanks guys
<ambroff> I made the mistake of asking this question in #debian and got pages and pages of hate just because I mentioned that it was for Ubuntu.
<cjwatson> slangasek: not wild about having it considering Recommends - I have a strong suspicion that they aren't in a sufficiently good state for that, and a weaker suspicion that people have perpetrated hacks involving deliberately unsatisfiable Recommends
<slangasek> cjwatson: ok
<cjwatson> I'm pretty amazed reprepro wouldn't support that
<cjwatson> Not that I use reprepro, but it has a "copy" command documented in its man page ...
<cjwatson> Or indeed copysrc
<cjwatson> You should generally (because this is how most modern Debian-based archives actually work) regard a Debian-based archive as a pool of uniquely-versioned packages, with each "suite" (lucid, precise, etc.) being essentially just a set of references into the pool
<cjwatson> (it's slightly more complex than that in reality but this is a pretty decent first approximation)
<ambroff> hrm, OK, I need to do some research. I've only built simple little repositories, never anything like this.
<ambroff> OH! I didn't see the copy command. I was using includedeb
<ambroff> damn, sorry for not RTFM
<cjwatson> right, I think includedeb injects a whole new build
<cjwatson> (in general I think you should use just 'include' with a .changes file - it's safer to work in units of entire .changes files, which are the usual master control files for an upload)
<cjwatson> I'll probably try reprepro for something at some point - speaking as an Ubuntu archive admin, it certainly looks featureful enough for moderate-sized projects
<ambroff> awesome reprepro is totally working for me now
<ambroff> thanks again for the help
<cyphermox> directhex: admittedly it would be faster if the bzr branch for evolution was working
<cyphermox> directhex: evolution-data-server is ready
<pedahzur> So, we have hit what we think is a bug in the mellanox driver for our 10GigE card on our 10.04 system. This is probably confirmed by this: http://code.metager.de/source/history/linux/stable/drivers/net/ethernet/mellanox/ Search for the second and third occurrences of "page allocation" which reflects the errors we were getting.  Seeing that 10.04 is LTS, how might I go about requesting a back-port of this driver's fixes to 10.04?
<pedahzur> Or am I better off justing pulling a kernel source deb from 12.04 and compiling it for my system?
<sarnold> pedahzur: I suggest filing a bug against the kernel, include bits of your dmesg output if you still have them, include those git hashes, and the link to that page. Might as well get it fixed for everyone for the next two-odd years of support...
<directhex> Laney, https://git.gnome.org/browse/evolution/commit/?h=gnome-3-6&id=881533927325432a0bab7eabea3a1d4008b5bcff - causes evo to recuse itself to death and crash when trying to preview/open a message whose content makes it sad, e.g. http://paste.debian.net/hidden/011db506/
<Laney> please to bug and subscribe me
<chilicui1> Hi there, I've requested a bzr merge for bug #699861, it appears that the ubuntu-branches team has been suscribed automatically, should I suscribe ubuntu-sponsors as well?
<ubottu> bug 699861 in slim (Ubuntu) "Slim starts too early" [Undecided,Confirmed] https://launchpad.net/bugs/699861
<maxb> My guess would be yes, I'm not sure ~ubuntu-branches exists as anything other than a placeholder owner for autocreated package branches
<chilicui1> maxb: I've just reassign it, thanks for replying
<pedahzur> sarnold: OK. Thanks.  Yeah, the stack dumps we're seeing look like the one you see at that above URL at the third occurrence of 'page allocation.'  Even the 'order:2, mode:0x4020' is the same.
<directhex> Laney, er, done, i think. it's a while since i've driven launchpad
<sarnold> pedahzur: that's definitely encouraging :)
<pedahzur> sarnold: Submitted: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1158031  I hope I included all relevant information.
<ubottu> Launchpad bug 1158031 in linux (Ubuntu) "Mellanox ethernet driver causing page allocation failures" [Undecided,New]
<sarnold> pedahzur: nice :)
#ubuntu-devel 2013-03-21
<pitti> Good morning
<pitti> ScottK: thanks :) at least I can now say that only half of my raring FFEs were controversial :)
<dholbach> good morning
<kris-away> mornin pardner
<aquarius> erm. Doing a dist-upgrade today, and basically all the packages that it wants to install can't be authenticated. Did the archive key change or something and I didn't update?
<aquarius> (am on raring. these are not coming from a ppa: apt-cache policy shows the new version of packages (such as compiz-plugins-main) are from raring/universe)
<kris-away> You've been hekked boy.
<cjwatson> aquarius: any errors from apt-get update?
<cjwatson> aquarius: (if not, try the dist-upgrade again)
<aquarius> ha!
<aquarius> there were, and I didn't notice. I got the "something wicked" error when resolving security.ubuntu. Re-updated and now all is fine.
<aquarius> On the other hand...that's a bit weird.
<cjwatson> Some kind of temporary resolver failure, perhaps
<cjwatson> Did it give any specifics?
<cjwatson>             return _error->Error(_("Something wicked happened resolving '%s:%s' (%i - %s)"),
<cjwatson>                                  Host.c_str(),ServStr,Res,gai_strerror(Res));
<cjwatson> kris-away: FWIW: that can be the case but it isn't necessarily helpful to leap to it first
<aquarius> cjwatson,   Something wicked happened resolving 'security.ubuntu.com:http' (-11 - System error), unhelpfully. :)
<aquarius> I assume my string-and-chewing-gum LAN decided to throw some sort of a benny.
<cjwatson> Hm.  I should make apt print strerror(errno) in that case.
<aquarius> anyway, we're good now, I think
<aquarius> mildly weird that it caused a key verify error, though. I mean, key verify errors are "colour the screen in red and print 'something is very wrong'" level :)
<cjwatson> I suspect that the error was in retrieving an intermediate step in the chain from the host
<aquarius> k, restarting to enjoy the new loveliness :)
<jamespage> anyone got any ideas on where this build is stalled?
<jamespage> https://launchpad.net/ubuntu/+source/glance/1:2013.1~rc1-0ubuntu1/+build/4384118
<jamespage> that appears to be right at the end of the package build process; but I can repro locally...
<jamespage> can't rather
<ogra_> lool, hmm
<ckpringle> ps
<ogra_> lool, are you sure its a clever idea to make the sdk packages recommends (optional) instead of hooking them in with a hard dep ? i fear we will end up with ton of bugs where the sdk misbehaves
<cjwatson> jamespage: there was chatter on #launchpad-ops overnight about buildd-manager taking mysteriously long to download build results
<cjwatson> mind you, I'm not sure that's what's up here
 * cjwatson peers
<jamespage> cjwatson, hmm - well I can repro locally but that package is also doing something similar in the openstack CI lab
<jamespage> dpkg-buildpackage: binary only upload (no source included)
<jamespage> Build killed with signal TERM after 150 minutes of inactivity
<cjwatson> nothing relevant in buildd-manager logs
<cjwatson> so I think it's before it starts trying to reap the build
<jamespage> cjwatson, would a process hanging around from test suite execution cause this sort of thing?
<cjwatson> let me check
<cjwatson> that's the last thing dpkg-buildpackage does
 * dholbach relocates to Laney's
<Laney> party time
<cjwatson> Right, so yes, it's quite possible - in particular, a process that didn't disconnect from dpkg-buildpackage's stdout
<cjwatson> It's just the usual pipe semantics
<jamespage> cjwatson, OK _ lemme dig again - I actually skipped the tests when trying to repro locally
<jamespage> but the lab runs them in full
<cjwatson> Reading from a pipe will block as long as there's a process with the other end of the pipe open for writing
<jamespage> it started happening in the lab with https://github.com/openstack/glance/commit/9a01d5389ac3235279f75256815e23e49ebc0c6a
<cjwatson> And sbuild reads from dpkg-buildpackage's output until it gets EOF
<cjwatson> This is launchpad-buildd's sbuild, but the relevant part of modern sbuild is structurally similar enough that it should do the same thing
<jamespage> cjwatson, "python setup.py test" was hanging around
<cjwatson> Right
 * jamespage pokes that a bit more
<lool> ogra_: No, I don't like the recommends either; note that they are only for optional plugins apparently, but I intended to bring that up indeed
<lool> ogra_: these were introduced between .136 and .137 and I hadn't noticed this in -proposed, so I copied them wholesale (like the rest), but would rather we convert them to depends
<ogra_> ah, i didnt know they were optional ... i just see that even today people moan about missing plugins
<ogra_> (or qt-creator does and they report it)
<ogra_> yeah ... depends++
<vibhav> britney is responsible for handling debian->ubuntu package copying, right?
<cjwatson> No
<vibhav> ah wait, britney is for the autopkgtest things
<cjwatson> Still no
<cjwatson> britney is the name of the tool that drives the proposed-migration process, so copies from raring-proposed to raring when conditions are sufficient
<cjwatson> It will be hooked up to autopkgtest as well but isn't yet
<vibhav> cjwatson: conditions as in?
 * vibhav always thought certain tests included autopkgtests
<cjwatson> vibhav: https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html
<cjwatson> As for Debian->Ubuntu copies, if you mean the mass sync process that happens between archive opening and Debian import freeze, that's https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/auto-sync
<vibhav> cjwatson: So britney is reposible for unstable->testing, while a modified version of britney in ubuntu is used for raring-proposed->raring?
<cjwatson> Correct
<cjwatson> On the whole I prefer not to call it britney, because I don't particularly like the "famous women's names for archive tools" naming scheme
<cjwatson> But that's fairly unambiguously the name for it in Debian testing, at least
<vibhav> heh
<vibhav> I never realized that anyway
<vibhav> cjwatson: thanks
<cjwatson> np
<cjwatson> aquarius: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703603
<ubottu> Debian bug 703603 in apt "apt: gai_strerror is not always specific enough for "Something wicked happened" errors" [Normal,Open]
<jamespage> cjwatson: will that build ever time out? if not who do I request to kill it...
<cjwatson> jamespage: It's meant to time out after IIRC 150 minutes of inactivity.  Failing that, #webops on internal IRC
<jamespage> cjwatson, ack
<aquarius> cjwatson, cool, thank you
<cousteau> texlive-latex-extra installed.  Tried to make a pdf using the moderncv class; I got this error: http://tex.stackexchange.com/questions/4264/latex-error-file-marvosym-sty-not-found
<cousteau> installing texlive-fonts-recommended fixed the problem.  Shouldn't this have been installed by default when installing texlive-latex-extra since it's needed for the moderncv class?
<zyga> roadmr: 5162
<roadmr> zyga: wow that's a lot
<zyga> roadmr: wrong place :)
<roadmr> zyga: haha
<tvoss> mpt, ping
<tvoss> mpt, do you want to sync up? I have nothing urgent
<mpt> tvoss, nothing from me.
<tvoss> mpt, ack
<mitya57> jamespage: hi, any chance you can look at bug 1157421?
<ubottu> bug 1157421 in blktap-dkms (Ubuntu) "blktap-dkms version in 12.04.2 is not compatible with the 12.04.2 kernel" [High,Triaged] https://launchpad.net/bugs/1157421
<mitya57> looks like we only need to backport https://github.com/mcclurmc/blktap-dkms/commit/d33302b91d
<jamespage> hey mitya57
<jamespage> gah - more kernel 3.5 fallout
<mitya57> yeah, it breaks a lot
<jamespage> mitya57, is that commit backwards compat with 3.2 as well?
<mitya57> I'm not sure, that's why I asked you :)
<mitya57> jamespage: looks like no :(
<mitya57> I can find vm_mmap definition in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blob;f=include/linux/mm.h
<mitya57> but can't in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=blob;f=include/linux/mm.h
<jamespage> mitya57, OK _ so can you make a patch that is conditional on kernel version?
<jamespage> that would make life easier
<jamespage> (doing it with dkms compat patches is a real headache imho)
<mitya57> jamespage: maybe later today (but I really didn't want to do that myself :P)
<caribou> seb128: ping
<seb128> caribou, howdy
<caribou> seb128: hope you're doing fine.
<seb128> caribou, I am, thanks! you?
<caribou> seb128: Fine, thanks. I got some issue with the rsyslog corruption bug SRU
<seb128> oh?
<caribou> https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1059592
<ubottu> Launchpad bug 1059592 in rsyslog (Ubuntu Quantal) "Message and memory corruption in rsyslog" [High,Fix committed]
<caribou> seb128: the bug is hard to reproduce, so the SRU fix is difficult to confirm
<caribou> seb128: I've been running the unfixed one in loops all morning and didn't see any corruption
<caribou> seb128: even with proposed templates in the upstream bug report
<seb128> caribou, in those cases it's usually fine to stress test the new version and confirm it stills work without regression
<seb128> caribou, if the bug is not really fixed that's still ok, as long as we are sure we don't break anything
<seb128> caribou, so just stress test the new version and if it's fine add a comment saying so in the bug
<caribou> seb128: ok, I can do that. I looked at arges's merge and it only replaces Unlock by Locks in a few places
<caribou> seb128: fine, I'll do that & report in the bug. I'd hate to see arges's work lost
<caribou> seb128: thanks
<arges> caribou: thanks again for the help.
<seb128> caribou, thanks for the efforts! yeah, me too, it's annoying when we go through all the process, have people working on a fix, sponsors review/uploading, SRU team getting it in ... to then fail to verify and loose all the work
<caribou> arges: np. I got another rsyslog bug on my plate anyway
<jibel> dobey, hey, could you have a look at bug 1158290 ?
<ubottu> bug 1158290 in software-center (Ubuntu) "enums.py imports non-existent module 'version' - breaks testsuite" [Undecided,New] https://launchpad.net/bugs/1158290
<dobey> jibel: failing where? version.py is a generated file (generated by setup.py build)
<jibel> dobey, autopkgtest https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-software-center/117/ARCH=amd64,label=adt/artifact/results/dsc0t-run-tests-stdout
<esing> Hi
<esing> Why does Ubuntu change the volume control not automatically when setting a new default audio device?
<Laney> @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: Laney
<Laney> zoom zoom
<seb128> Laney, happy piloting!
<Laney> :-)
<Laney> directhex: so you're hoping I'll SRU this patch to Q, yes?
<directhex> Laney, sorta!
<directhex> Laney, would be nice if my mail client didn't keep crashing whilst i'm testing our groupware install
<Laney> aye aye
<Laney> cyphermox: how goes the 3.6.4 update?
<cyphermox> I couldn't get back to it yet
<cyphermox> like i said before, evo-data-server is done
<cyphermox> evolution not so much
<seb128> just upload the one that's ready to start ;-)
<cyphermox> but it's really just because I had to put it aside, and the importer couldn't make it a bzr branch either :/
<cyphermox> sure ;)
<Laney> I'll backport the patch but it might also be an option to upload .4 to Q under the MRE
<cyphermox> bad habit... I usually try to upload both evo and eds together
<cyphermox> Laney: MRE is probably simpler... there's quite a few bug fixes
<seb128> Laney, I wouldn't spend too much time on Q at this point
<seb128> so depends how easy is the update to do/test
<Laney> indeed
<Laney> the backport should be easy enough
<stgraber> jodh: thanks for updating gnome-session! I was just done testing my own implementation when I applied some updates here and saw you did it already ;)
 * dholbach hugs Laney
<cyphermox> Laney: as soon as it comes out of sbuild I'm uploading
<Laney> you beast
<Laney> you mean the SRU or Raring or both?
<cyphermox> for raring
<Laney> nod
<cyphermox> I can fix that up for quantal too
<Laney> ok, it's bug #1158018
<ubottu> bug 1158018 in evolution (Ubuntu Raring) "Malformed content-type header causes infinite recursion -> crash" [Undecided,New] https://launchpad.net/bugs/1158018
<Laney> slow bot is slow
<cyphermox> my system is kind of slow too
<cyphermox> I guess copying the entire aosp tree + our android tree takes a bit of juice from my disk :/
<cyphermox> I'm going to need to add another entry to changelog, I didn't catch this bug since it was filed 15 hours ago
<Laney> argh
<Laney> evolution broke my maildirs
<cyphermox> huh
 * Laney glares at directhex
<cyphermox> oh, this is fixed in evolution, not eds
<cyphermox> Laney broke how?
<Laney> seems to have deleted all the mail in them
<cyphermox> bad evolution, bad!
 * Laney resyncs
<cyphermox> Laney: uploaded eds to raring
<cyphermox> should I be holding off for quantal?
<Laney> feel free if you think all the changes between .3 and .4 are ok
<cyphermox> it's all bugfix
<Laney> go for it
<cyphermox> hmm
<Laney> you'll want to file some SRU bug and say that it goes in under the GNOME MRE so testing each specific bug isn't required
<cyphermox> yeah
<Laney> GunnarHj: what's left to do on https://bugs.launchpad.net/lightdm/+bug/952185 openssh?
<ubottu> Launchpad bug 952185 in gdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [Medium,In progress]
<GunnarHj> Laney: Uploading the patch.
<gema_> awe_: can you give me the link to all the BPs that cover the wifi/networking work?
<Laney> cjwatson: ^ maybe you could look at the openssh patch there
<gema_> lool: or maybe yourself, wifi/networking ongoing BPs?
<cjwatson> Laney: yes, it's already on my to-do list
<Laney> ok
<Laney> I'll remove from the queue then
<cjwatson> I'll get it done before raring
 * Laney nod
<jodh> stgraber: thanks - I didn't upload though :)
<stgraber> jodh: someone did :)
<Laney> le RAOF
<jodh> following on from a discussion on #upstart-desktop, I'd like to understand the expected semantics of apport hooks that have to handle potentially sensitive files. For ProblemType 'Bug', we should ask the user (if there is a ui), and for 'Crash' we could auto-attach any files as (a) we can't ask the user and (b) all 'Crash' bugs are private. But how best to handle sensitive files for other ProblemTypes?
<Laney> zul: are you uploading for https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1119248 ?
<ubottu> Launchpad bug 1119248 in nova (Ubuntu) "[SRU] nova does not set container_format when snapshotting instance with ref image deleted" [Undecided,In progress]
<zul> laney: its been delayed
<Laney> yeah?
<Laney> is it part of a regular SRU cycle or something?
<Laney> IOW does ubuntu-sponsors need to be involved?
<lool> gema_: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-converged-network-stack
<awe_> gema_, that only really cover the fact that we're going to use ofono for mobile data support
<awe_> there's no real change to how wifi works
<gema_> awe_, lool ack
<gema_> awe_: is there any past BP that defines how wifi works that is worth mentioning/taking into account?
<awe_> that said, what you'll really need to work with are probably the design specs for indicators/settings
<awe_> https://wiki.ubuntu.com/Networking
<awe_> ^^ is a good overview of how networking is supposed to work on desktop
<gema_> awe_: ack, do we have something similar for mobile?
<awe_> there was a design spec published internally for touch, but AFAIK it's no longer available ( even internally w/in Canonical )
<awe_> you probably should ask mpt or ivanka
<lool> gema_: I was hoping aruiz would have an indicator spec to complement this -- pinged him just before his holidays last week about the WI there, but he's on leave this week, will ping again this week -- and also that we'd have a wifi testing subblueprint or at least some more detailed workitems
<gema_> awe_: ack
<mpt> gema_, I will be adding phone stuff to it soon.
<awe_> one other doc which is super preliminary is: https://wiki.ubuntu.com/SystemSettings
<gema_> lool: yep, I am also waiting for aruiz to be back
<awe_> there's a meeting on monday to discuss
<gema_> mpt: ok, sounds good
<awe_> mpt, that would be super helpful...  the sooner the better, as there some holes in the spec that touch was originally based on
<gema_> awe_, mpt +1000
<awe_> ( i.e. no connection info, no way to forget a network/change a password, ... )
<mpt> I see
<gema_> mpt: that'll pretty much drive our testing use cases
<awe_> gema_, bingo
<mpt> awe_, gema_: To be fair, the PC spec is riven with holes too. :-) It dates from the days when we were flirting with ConnMan, and when we returned to the arms of NM, I stopped work on it
<gema_> mpt: then we'll have to complete it
<mpt> yes indeed
<mpt> awe_, gema_: aruiz is working on the PC UI
<awe_> mpt, re: aruiz, yes... I know.  I exchanged an email with larsu about indicators and specifically networking/telephony next week.  Looks like plans are starting to shape up a bit.  I think we'll have a chance to re-sync at the settings mtg on monday
 * Laney prods xnox to look at / upload https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/831768
<ubottu> Launchpad bug 831768 in aptitude (Ubuntu Precise) "aptitude cannot handle conflicts with multiarch enabled" [High,Confirmed]
<Laney> (from #122 I gather that you reviewed the patch)
<xnox> Laney: only briefly... be my guest to upload it =)
<Laney> /quit
<bdmurray> jodh: I think there are only 2 other problem types "Package" and "KernelOops".  For Package I think we should ask and for KernelOops may be a type of crash so private?  However, when we have server-side hooks setup for errors I think it'll be moot.
<jamespage> do the launchpad builders set HOME to something sensible?
<tkamppeter> OdyX, I have release cups-filters 1.0.31 to fix a bug and quickly uploaded it to Ubuntu (due to the FF, to get as much testing time as possible). Please merge it also back into Debian.
<vibhav> Laney: /j #launchpad
<vibhav> oops
<vibhav> sorry Laney
<Laney> I DON'T WANNA
<vibhav> Laney: Now since I (accidently) pinged you, is it considered nice to delete a merge proposal and start afresh with a new one?
<Laney> it loses the history
<vibhav> https://code.launchpad.net/~vibhavp/ubuntu/raring/thoggen/fix-format-string-warning/+merge/150969
<Laney> I'd just fix it and push some new commits
<Laney> then set back from WIP to Pending or whatever it is in the global status
<jodh> bdmurray: the source also mentions KernelCrash, and Hang so a non-kernel hook seems to have to handle Bug, Crash, Hang and Package.
<mlankhorst> \
<mlankhorst> oops
<jodh> jamespage: see https://launchpadlibrarian.net/126054368/buildlog_ubuntu-raring-amd64.procenv_0.19-1_BUILDING.txt.gz (search for HOME=)
<bdmurray> jodh: ah, I'd forgotten about hang - that is rather new
<OdyX> tkamppeter: I have too much pain with bzr to be able to push it fast to Debian, but I'll do it soon, yes.
<jamespage> jodh, interesting - that is different to a stock sbuild environment locally
<jamespage> jodh, I can simulate that tho
<jodh> bdmurray: have we got some doc on this or a skeleton hook maybe to handle all the scenarios?
<bdmurray> jodh: I don't think so
<jono> hey didrocks - testing the scopes PPA - should the server be sending correct results back now?
<jodh> jamespage: I've put links to all the environments I can get to non-locally at the top of https://launchpad.net/procenv/.
<jono> I am finding the filtering is buggy
<jono> wasnt sure if I should file a bug
<didrocks> jono: not correct results
<didrocks> jono: all scopes should start
<didrocks> they don't have real recommendations yet
<jamespage> jodh, weird - anyway - I updated my sbuildrc to set a HOME
<didrocks> jono: re filters: yeah, there are not all ready yet
<cjwatson> jamespage: it's a bug to ever rely on HOME during a build
<cjwatson> (and yes, I think launchpad-buildd currently differs from packaged sbuild)
<jamespage> cjwatson, I don't disagree - I was just observing different behaviour between sbuild and launchpad buildd
<cjwatson> jamespage: the intent is to upgrade launchpad-buildd to modern packaged sbuild, but lack of time
<jamespage> cjwatson, ack - I'll push a fix into the offending package so it does not break in future
<cjwatson> Soyuz folks do know that there are plenty of differences :)
<cjwatson> At least some Debian buildds will be running with something much more recent
<cjwatson> plars: https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1162 - with any luck this will turn out not to be total doom
<seb128> jodh, stgraber: hey, do you have any spec you are using for the upstart work scheduled for post raring? is the gsettings bridge on there?
<seb128> jodh, stgraber: I was pondering opening a client spec of "make use of session jobs" ... does that make sense or is there an existing spec that matches that?
<seb128> Laney, ^ fyi
<stgraber> seb128: I don't think we have a spec specifically for using the features we implemented, so I guess that'd be good to have
<stgraber> seb128: the gsettings/dconf bridge currently isn't upstream but jodh asked me to poke at it again and it may make the next release still
<seb128> stgraber, ok, good, do you need help from our side to figure where to plug/listen for dconf/gsettings changes?
<stgraber> seb128: it was difficult to test before as we didn't have the user sessions but now that we do, it should be fairly easy to get my code into good enough shape that it can get in upstart and people can start using it
<stgraber> seb128: the current implementation simply sends even for any change happening in the dconf database, I think it's a good first step. In the future we'll want to add extra syntax so we can depend on existing keys and not only keys changing value
<seb128> stgraber, how do you "watch for changes"? look at dbus calls?
<stgraber> seb128: yep, my bridge connects to dbus and listens for the dconf signals
<seb128> stgraber, ok, great, thanks
<seb128> stgraber, I got some new ideas of things that could make use of session jobs today once we have that bridge
<seb128> I will register the a client spec to list those ;-)
<stgraber> so you can easily start/stop a job when a value changes. The thing you can't do at this point and will need a fair bit of work in the bridge is have a start condition that checks for a specific key to be set to a specific value
 * cjwatson fixes up test failures from that last cdimage change, whoops
<bdmurray> there are 2 uploads of gvs in quantal-proposed
<bdmurray> one looks like a point release and the other is a bug fix https://errors.ubuntu.com/bucket/?id=%2Fusr%2Flib%2Fgvfs%2Fgvfsd-gphoto2%3A***%20glibc%20detected%20***%20%2Fusr%2Flib%2Fgvfs%2Fgvfsd-gphoto2%3A%20double%20free%20or%20corruption%20%28fasttop%29%3A%20ADDR%20***
<bdmurray> with 55k reports
<Laney> @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:
<Laney> will do some more tomorrow - got distracted debugging something
<jodh> pitti/mpt/bdmurray: Could you review my changes to https://wiki.ubuntu.com/Apport/DeveloperHowTo ? Maybe we could also add advice on how to handle interactive questions post-release?
<mpt> jodh, as above, I don't mind interactive questions for Crash, if they're useful, just so long as Apport suppresses them post-release. Relying on individual package developers to remember those rules won't work so well.
<dholbach> haha... https://twitter.com/politbuntu
<mpt> jodh, pro tip for the future: for less than one line of monospace you can use backticks, e.g. `Crash`
<mitya57> dholbach: :)
<bdmurray> seb128: do you have an opinion on the 2 gvfs uploads in quantal-proposed?
<seb128> bdmurray, let me have a look
<bdmurray> thanks
<seb128> bdmurray, reject 1.14.0-0ubuntu6.1 from Laney
<seb128> bdmurray, the new version includes that patch (as well as other fixes)
<bdmurray> seb128: will do thanks
<seb128> bdmurray, thank you!
<roadmr> hello folks, we found a bug when accessing (udevadm --walk) /sys/devices/tegradc.0 on a nexus 7 running the phablet image, what'd be a good place/package to report this against?
<hallyn> cjwatson: hm, when i try to install from 12.04.2 desktop livedvd with ovmf bios, i get plugininstaller.p becoming defunct
<cjwatson> hallyn: um, dunno, would need logs I guess ...
<hallyn> cjwatson: oh hey, 30 mins later it finished.  dunno waht it was doing...  oh, though i did kill -9 the defunct task, lessee if it reboots
<hallyn> http://paste.ubuntu.com/5635411
<cjwatson> err - yeah, that's not so informative
<cjwatson> anything in syslog?
<hallyn> hm, no
<hallyn> well i can do a fresh install tonight and note what time the defunct process was hanging and look through /var/log
 * hallyn back later 
<cjwatson> plars: so, I think I'm pretty much there now - I just need to bug IS a bit more re firewall holes, but the SSH trigger is in place aside from that.  Do you think we can get together tomorrow and deploy this?
#ubuntu-devel 2013-03-22
<selite_> Alright, since I care deeply about Ubuntu and know how to code. Can you please tell me how can I contribute?
<RAOF> selite_: Any number of ways; what would you like to do?
<selite_> RAOF: Write code.
<robru> selite_, so, write some code then.
<RAOF> Any particular type of code? You can usefully write code anywhere from the kernel to trivial apps.
<plars> cjwatson: sounds good, I have a dr. appointment and a few other things, but if you can send me the details, we should be able to get it tested out early on
<selite_> RAOF: my answer seems to be general but that is because I am lost, I am currently checking it Bazaar and I just don't understand how this thing works.
<RAOF> selite_: So, Ubuntu is, in part, the aggregation of tens of thousands of individual projects, from the kernel to apps like Gwibber.
<RAOF> selite_: Contributing to any one of those projects helps Ubuntu.
<robru> selite_, so think of a program that you want to like, but has problems that bother you, and then go fix those.
<selite_> robru: I download the source code from github, I fix a bug and then what do I with it?
<selite_> robru: What if someone decides to put bugs intentionally how do you keep track of that?
<RAOF> selite_: That depends on the project. If it's a project on github, generally what you'll do is fork, make your changes, and then submit a merge request.
<RAOF> selite_: For Launchpad projects it's similar.
<RAOF> selite_: For other projects (like the kernel, X, or mesa) the process is to create your patches and submit them to a mailing list.
<RAOF> selite_: It depends on the project :)
<selite_> RAOF: I understand. Do they keep a list of bugs that need to be fixed?
<selite_> RAOF: For example for Gwibber.
<RAOF> selite_: Generally, yes. You can check out the Ubuntu bugs on launchpad - https://launchpad.net/ubuntu/+source/gwibber/+bugs ; projects generally also have their own bug tracking. For example, github issues.
<robru> RAOF, maybe not the greatest example because all those bugs are obsolete ;-)
<robru> but yeah
<robru> oh, he left. d'oh
<pitti> mpt: I think I'll change apport to just not pass an UI object for crashes post-release
<vibhav> cjwatson: What is the pkg-config "name" for libpipeline?
<pitti> $ dpkg -L libpipeline-dev|grep pkgconfig
<pitti> /usr/lib/x86_64-linux-gnu/pkgconfig/libpipeline.pc
<pitti> vibhav: ^
<vibhav> thanks
<vibhav> pitti: but, shouldn't this be in PKG_CONFIG_PATH ?
<pitti> it is
<pitti> pkg-config knows about multiarch
<vibhav> pitti: http://paste.ubuntu.com/5636218/
<pitti> $ pkg-config --cflags --libs libpipeline
<pitti>  -lpipeline
<pitti> missing libpipeline-dev ?
<vibhav> This is crazy, software center doesn't find libpipeline-dev
<vibhav> while apt does
<pitti> it's not an application
<vibhav> yes, but SS does find -dev packages
<vibhav> (at least here, it used to do that)
<infinity> vibhav: I wouldn't generally recommend using SS for searching for libraries and dev things.  Most of the time, if it displays one, that's a bug, not a feature.
<infinity> (IMO)
<infinity> It's meant to be a top-level view of applications, with some semblance of user-friendliness which is, almost by design, developer-hostile.
<vibhav> infinity: ah ok
<infinity> vibhav: apt-cache search is probably a developer's best friend in this case.
<sarnold> <3
<zyga> good morning
<leagris> Hello there,
<leagris> I am testing 13.04 for some time and use google chrome from unstable chanel.
<leagris> I know it is unstable and unsupported software. So I don't asks for any help here:)
<leagris> Meaningwhile, I experience some huge bd2 (Ext4 journal update) with GoogleChrome
<jamesh> mvo: ping?  Would you have time to answer a few questions about the software center?
<leagris> So badly I came back to Firefox, because my spinning rust disk is so busy while Chrome is running, it become unresponsiv if it needs to fetch user profile datas for form filling and so on :)
<leagris> I just like to reade your own experience with these unstable builds of Google Chrome here. Did you also notice an excess of IO with the bd2 process?
<leagris> Google Chrome 27.0.1430.0 (Build officiel 186115) dev
<leagris> WebKit	537.33 (@144673)
<leagris> Mozilla/5.0 (X11; Linux x86_64)
<mvo> jamesh: hi, sure
<jamesh> We have a bunch of packages containing Unity scopes, and were wondering on the best way to make them show up together in a category on the software center
<jamesh> Looking at the code, there seemed to be some stuff to scrape XB-Category fields from the package metadata, but this doesn't seem to be what is used for the majority of packages in the archive
<mvo> jamesh: I'm talking with mhr3 about this right now
<mvo> jamesh: in #ubuntu-desktop
 * jamesh joins
<leagris> Though, I am reluctant on updating an old bug about unexpected bd2 activity preventing laptop disk spin down and draining batteries. I use a desktop computer, and I identified Google Chrome as the source of this excessive bd2 activity.
<leagris> oups, I meant jbd2
<leagris> It could match this still opened old bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560
<ubottu> Launchpad bug 607560 in linux (Ubuntu) "jbd2 writing block every 5 - 10 seconds, preventing disk spin-down and making noise" [Undecided,Confirmed]
<leagris> Launchpad is a so big load of bugs filled by clueless users like me. I praise you dev and maintainers unbelivable ability to pick any relevant information from it :P
<dholbach> good morning
<leagris> hello good morining dholbach
<dholbach> hi leagris
<pitti> vibhav: https://code.launchpad.net/~vibhavp/ubuntu/raring/libpipeline/add-atuopkgtest/+merge/154883 verified; bouncing to cjwatson as I guess he wants to keep this in sync and upload to Debian instead
<vibhav> sure, thanks
<mitya57> jamespage: re bug 1157421: I now have a working branch attached, but I don't yet know what to do with the linux-headers-generic dependency (which makes it build with 3.2 headers)
<ubottu> bug 1157421 in blktap-dkms (Ubuntu Precise) "blktap-dkms version in 12.04.2 is not compatible with the 12.04.2 kernel" [High,Triaged] https://launchpad.net/bugs/1157421
<mitya57> (asked on #ubuntu-kernel now)
<jamespage> mitya57, I'd be tempted to drop the dependency on headers; thats what openvswitch and iscsitarget do
<mitya57> and also I wonder if I should add fix-vm-reserved.patch from raring to fix compilation with 3.7+
<jamespage> mitya57, no - we just need the minimal fix for 3.5 support right now
<tkamppeter> xnox, jodh, I have reported a bug on avahi, to apply a workaround for making CUPS to reconnect to avahi-daemon after a restart of avahi-daemon, bug 1158686. Can you apply it in Raring?
<ubottu> bug 1158686 in avahi (Ubuntu) "When restarting avahi-daemon cups does not reconnect to it - workaround" [High,New] https://launchpad.net/bugs/1158686
<mitya57> jamespage: it doesn't depend on openvswitch or iscsitarget â or what do you mean?
<jamespage> mitya57, both of those packages ship dkms packages; the dkms package don't depend on linux-headers
<mitya57> ok, but dkms itself now also doesn't depend on headers...
<jamespage> mitya57, yeah - but the ubuntu install process should install the correct headers for the right kernel by default
<mitya57> fair enough :)
 * mitya57 drops the dependency and files a MP
<jamespage> mitya57, nice one!
<mitya57> jamespage: should I leave "linux-headers-generic [i386 amd64] | linux-headers" in Suggests?
<jamespage> mitya57, personally I would just drop them
<seb128> cjwatson, hey, do you think you could add https://launchpadlibrarian.net/131228119/openssh_lp-952185_raring.patch to your review list? it's in the sponsoring queue but reflected as SRU for lightdm, but in fact has a patch for openssh
<cjwatson> seb128: it *is* on my review list already
<mitya57> jamespage: done, https://code.launchpad.net/~mitya57/ubuntu/precise/blktap-dkms/lp1157421/+merge/154892
<cjwatson> but I need to think hard about it - even though it's a small patch I need to go and make sure that moving the env handling doesn't affect anything undesired within sshd
<ogra_> hmm, seems like the rm for /current misses a -r in the new cdimage code :)
<ogra_> (unlink() fails)
<ogra_> oops, i thought i was in -release
<seb128> cjwatson, ok, good, I will unsubscribe sponsors from the bug if that's fine with you (so we avoid having other people doing the review, or somebody just sponsoring without giving it too much thinking)
<cjwatson> seb128: sure, somebody already said they'd done that yesterday ...
<seb128> ok, done
<cjwatson> ogra_: where are you seeing that?
<cjwatson> oh, yeah, ok, build logs
<ogra_> in the failed buildlogs
<cjwatson> I'll sort that out, thanks
<ogra_>  File "/srv/cdimage.ubuntu.com/bin/../lib/cdimage/osextras.py", line 53, in unlink_force
<ogra_>     os.unlink(path)
<ogra_> OSError: [Errno 21] Is a directory: '/srv/cdimage.ubuntu.com/www/full/ubuntu-server/precise/daily/current'
<cjwatson> I only just got in, give me a minute to go through it all
<ogra_> i didnt mean to be pushy .... just reported it as i found it when reading morning mail :)
<cjwatson> aside from anything else there's the question of why that's a directory, since the new code isn't supposed to be active yet
<ogra_> yeah
<cjwatson> so need to do some background checking
<vibhav> ogra_: For a moment, I thought the C unlink() wasnt working :D
<ogra_> vibhav, well, not sure if cjwatson ported cdimage to C secretly over night :)
<ogra_> looks like a python error though ;)
<vibhav> ogra_: I mean unlink() in the daily builds :P
<vibhav> I read it incorrectly
<cjwatson> os.unlink is a very thin wrapper around libc unlink anyway
<jamespage> mitya57, looking now
<mitya57> jamespage: one more question for you: "the ubuntu install process should install the correct headers for the right kernel by default" â does that apply to Debian?
<jamespage> mitya57, hmm - not sure
<mitya57> (otherwise we should apply this in raring as a delta)
<mitya57> zigo: maybe you know (^)? we are talking about dropping linux-headers dependency from blktap-dkms package you're maintaining :)
<xnox> tkamppeter: updated the bug with more "upstart like" post-start. But you are correct that post-start does not run on restart avahi-daemon. I can't remember how to execute stuff on restart, let me check the cookbook again.
<mitya57> zigo: btw you may also be interested in my support_kernel_3.4.patch
<jamespage> mitya57, uploaded and subscribed ubuntu-sru to the bug report
<jamespage> mitya57, thanks for fixing that up
<mitya57> jamespage: thanks! maybe it'll make sense to do a raring upload dropping the dependency (otherwise it can be rejected)
<jamespage> mitya57, I think that would make sense
<mitya57> jamespage: should I do another MP?
<jamespage> mitya57, that would be lovely!
<xnox> tkamppeter: posted a task job which should reload cups whenever avahi-daemon is started or restarted.
<mitya57> jamespage: https://code.launchpad.net/~mitya57/ubuntu/raring/blktap-dkms/no-headers-dependency/+merge/154897
<cjwatson> ogra_: fixed
<ogra_> cjwatson, great, thx
<tkamppeter> xnox, looks great, I am testing now.
<tkamppeter> xnox, on cold boot avahi-daemon starts before cups, so when the task gets triggered "reload cups" is executed with cups not yet running and so it exits with 1. Does this cause any problem? Should we surround the "reload cups" by "if status cups | grep start/running; then ...; fi"?
<xnox> tkamppeter: it's fine, the task starts & fails, and live goes on.
<xnox> s/live/life/
<xnox> tkamppeter: the task stanza is special as each time this job is triggered a new unique (throwaway) instance is created and expected to exit soon.
<zigo> mitya57: Why dropping the kernel header thing?
<zigo> mitya57: If you drop that dependency, can the DKMS module build?
<mitya57> zigo: in Ubuntu the right headers are always installed
<zigo> mitya57: You mean, by default, you *always* have the headers?
<zigo> Even with a raw system installed by debootstrap?
<mitya57> jamespage: ^
<zigo> mitya57: Could you please send requests to me via the Debian BTS ?
<zigo> mitya57: Including your patch if possible.
<zigo> blktap-dkms-2.0.93.patch ?
<zigo> Is it that one?
<mitya57> zigo: that was not a request, but a suggestion :)
<mitya57> patch is https://bazaar.launchpad.net/~mitya57/ubuntu/precise/blktap-dkms/lp1157421/view/head:/debian/patches/support_kernel_3.4.patch
<mitya57> (there's also another patch in raring that makes it work with 3.7/3.8)
<zigo> mitya57: I don't mind request or suggestion, I appreciate both! :)
<zigo> Well, I can apply on one of them, no?
 * xnox ponders who or what creates ~/.cache/archive-cache/ which is filled with 11GB of .debs I have on a local mirror anyway....
<mitya57> zigo: as experimental has 3.8, you may want to apply both
<mitya57> (obviously, that's for jessie, not for wheezy)
<tkamppeter> xnox, I have tested it and it works on stop/start, restart, crash/respawn (simulated by "killall -9 avahi-daemon"), reboot.
<xnox> tkamppeter: cool thanks. uploading then.
<mpt> ev, what revision is errors.ubuntu.com running?
<ev> mpt: 300, by the looks of it.
<cjwatson> ogra_: OK, I worked out why those were directories as well - it was due to stale builds for architectures that we no longer build for by default.  I've removed those images and "current" should automatically collapse itself back to a symlink at the next build.
<ogra_> ok
<ogra_> which arches ? armel and so on ?
<cjwatson> powerpc, and amd64+mac for server
<ogra_> ah
<cjwatson> now, metalinks still aren't working right
 * cjwatson looks at that next
<tkamppeter> xnox, so the new file will be in avahi?
<ogra_> do we still need them ?
<mitya57> zigo: looks like in Debian dkms takes care about headers itself, so the explicit dependency is not needed (take a look at openvswitch-datapath-dkms for example)
<ev> mpt: I'd like to get tip deployed, but I'm trying to fix a few things that are going to drive people mad, like how changing the "users of" box doesn't update the table.
 * ogra_ would think we might put wubi down at some point soon
<ev> mpt: ideally I'd like to fix the pinstripe and the transition of the milestones when you select a different release, but there are far more important things to deal with. Might be one for the weekend.
<zigo> mitya57: Let me try to build it in a cowbuilder then.
<cjwatson> metalink> oh, this is because I'm an idiot
<cjwatson> ogra_: not a justification for obvious code bugs :)
<cjwatson> like a missing call to main()
<ogra_> oops :)
<mitya57> to be precise, dkms *recommends* headers
<zigo> mitya57: I mean piuparts ...
<zigo> I'll try piuparts test in SID.
 * mitya57 will have to go in 10 minutes
<ev> mpt: for what it's worth, https://rt.admin.canonical.com//Ticket/Display.html?id=60205 is blocked by the pile of stuff in front of it on the webops queue: https://portal.admin.canonical.com/ruins?team=losa
<mpt> ev, I'm not chomping at any bit, I was just wondering how to evaluate a bug comment of the form "This bug might be solved in r360"
<seb128> xnox, do you have an opinion on https://code.launchpad.net/~fehwalker/ubuntu/raring/ureadahead/fix-969926/+merge/153429? I think you wrote on the list recently you were happy to sponsor ureadhead fixes, want to look at this one? ;-)
<ev> mpt: there's always http://poppy-dev.local
<mpt> Oh. Right.
<ev> :)
<cjwatson> OK, any broken metalinks should sort themselves out over the next day or two now; I regenerated the most important ones
<zigo> mitya57: The kernel header stuff are pulled by dkms Recommends:
<xnox> zigo: not on ubuntu.
<zigo> mitya57: So as much as I understand it, the linux-header dependency is really needed.
<zigo> xnox: So, in Ubuntu, you have a Depends:?
<xnox> zigo: no. externally managed/installed. kernel itself depends on headers.
<mitya57> in Ubuntu we don't even have Recommends
<xnox> zigo: you should depend on the headers in Debian, though.
<zigo> Ok, then I believe I have to do a conditional Depends: then.
<xnox> but in ubuntu we do not want it.
<zigo> (using the substvar trick and dpkg-vendor...)
<mitya57> xnox: so will that "external management" work in "a raw system installed by debootstrap"?
<zigo> I'm doing that now then.
<xnox> zigo: basically we do not have a single top-level headers package and it gets renamed, hence the dependency is in the kernel flavour. Not sure what you mean by a raw system installed by debootstrap - if kernel is installed on ubuntu (even via debootstrap), headers package will be pulled in.
<mitya57> xnox: thanks for clarifying that!
<xnox> if there is no kernel installed, headers will not be pulled in. And well I am not sure there is a use-case for dkms, if kernel is not installed.
<zigo> xnox: Well, you do not really have to install a kernel to have a working system!
<vibhav> win 6
<vibhav> soory
<vibhav> sorry, even
<zigo> xnox: I run hundreds of virtual machines at GPLHost without the kernel package installed.
<xnox> zigo: sure, but dkms will not work without a kernel package, now will it? =) Oh.... hmm... I see....
<zigo> But well, anyway, I'm doing what I wrote above to make you guys happy! :)
<tkamppeter> xnox, thank you very much for your help.
<xnox> tkamppeter: no problem.
<ev> mpt: I decided to make the milestone labels noninteractive last night. Being able to select which lines are shown on the graph independent of the "Showing error reports from" box state, which also determines what lines are shown, seemed confusing (plus the code was getting complex).
<mpt> ev, they were interactive before??
<ev> briefly
<ev> like so: http://nvd3.org/
<mitya57> zigo: if you are going to add a conditional depends, that will be very good (and probably will allow us to drop our delta at some point)
<ev> (click on stream2)
<zigo> mitya57: Yes, I'm doing that right now.
<mitya57> thanks!
<cjwatson> eh, packages generally can't ever sensibly depend on kernel headers
<cjwatson> because they don't know which kernel flavour is installed
<mpt> ev, love the stereotypical open-source whimpering on that page: "This project is an attempt to build..."
<cjwatson> this is why we have to have something like dkms to do it at run-time instead ...
<ev> mpt: lol
 * mitya57 will be back in 1.5 hours
<ev> d3 at least breaks from some of the other stereotypical open source stuff, like giving you lots of nobs and switches to write bad code. (https://groups.google.com/forum/?fromgroups=#!topic/d3-js/mEjem7IPshY)
<zigo> http://anonscm.debian.org/gitweb/?p=pkg-xen/blktap-dkms.git;a=commitdiff;h=ab9a0d189cc196a2a09e35127a8570950d2c419c <--- As requested.
<zigo> (or suggested ... :) )
<zigo> So which patch should I apply then?
<leagris> Something wierd just happened. I had apport crash popup soon after login in 13.04, then it said the problem wals already reported here https://bugs.launchpad.net/bugs/1121896
<ubottu> Error: launchpad bug 1121896 not found
<cjwatson> zigo: well, surely that dependency is wrong in Debian too.  What if somebody has, say, linux-image-amd64 installed rather than linux-image-generic?
<cjwatson> s/installed/running/
<leagris> Unfortunately, well as you can see, this page/bug does not exist at Launchpad ;D
<leagris> So, It failed to tell what crashed and pointed to an invalid bug
<cjwatson> It exists but it's private
<cjwatson> However I don't know enough about indicator-sync to know whether I can safely mark it public (i.e. whether it contains user data)
<cjwatson> Perhaps somebody else does
<leagris> Ah yes, funny situation :) got it mentioned in here https://bugs.launchpad.net/ubuntu/+source/indicator-sync/+bug/1130062
<ubottu> Error: Bug #1130062 is a duplicate of bug #1121896, but it is private (https://launchpad.net/bugs/1121896)
<seb128> cjwatson, leagris: I market it public, the indicator can "leak" filenames, nothing else
<seb128> but that's not even the case in that report
<pitti> darkxst: I have a proposed general hook for you in bug 1158119
<leagris> thank you seb128 and no worries, I know someone will look at it before release :)
<ubottu> bug 1158119 in apport (Ubuntu) "support for reporting bugs against gnome3-team ppa" [Undecided,In progress] https://launchpad.net/bugs/1158119
<darkxst> pitti, thanks, let me test
<leagris> Are there some maintainers of compiz and or accessibility team here?
<leagris> I'd like to share my concern on the maybe endangered future of compiz within Ubuntu. I am visually impaiared and the eZoom plugin is my most efficient beloved screen magnifier for everydays since years. Gnome Orca and other tools are pale and inappropriate replacementss I would not want to fallback to.
<didrocks> leagris: TheMuso is the accessibility specialist, but he lives in australia, so you maybe want to chat with him
<tkamppeter> xnox, I have assigned bug 1158686 to you, as you told that you are uploading avahi with the new file.
<ubottu> bug 1158686 in avahi (Ubuntu) "When restarting avahi-daemon cups does not reconnect to it - workaround" [High,Triaged] https://launchpad.net/bugs/1158686
<leagris> I already avoided Unity for its poor experience with compiz eZoom (launch bar not magnified and not following zoomed area). I really feel left behind more and more. Not funny and no trolling here.
<xnox> tkamppeter: sure. just fighting with my new desktop to make it build packages (homedir rsync still in progress)
<darkxst> pitti, will that still run the normal package hooks as well?
<pitti> darkxst: yes
<darkxst> ok, looks good then
<leagris> I'd pay for having compiz eZom maintained. Not that much in regard to the work and responsabilities, but at least I sure would drop $600 as it is the price of a ZoomText licence for the Microsoft OS :)
<leagris> And I am reluctant to drop money to a broad organisation, be it non-profit as it may be significantly diluted before it reach the compiz eZoom package maintener for Ubuntu.
<zigo> cjwatson: linux-headers-amd64 has a Provides: linux-headers
<zigo> So the dependency is satisfied.
<didrocks> leagris: again, as told previously, you should talk with TheMuso when he's online
<leagris> didrocks: took a note to poke TheMuso wile in the proper timezone thanks
<didrocks> yw
<cjwatson> zigo: It's satisfied, but there's no reason apt will pick the right one; as a result the user will often have to intervene anyway
<cjwatson> zigo: A dependency on plain linux-headers would make sense, perhaps - but there's no reason, either in Debian or Ubuntu, why the package has any justification for claiming it knows what the preferred alternative is
<cjwatson> So I don't think it is right to specify a preferred alternative
<cjwatson> (I don't know the history of this bug/patch/whatever so I don't know if this started out with the dependency being actively inconvenient in Ubuntu)
<zigo> cjwatson: With the patch from upstream it fails to build the kernel module for 3.8
<zigo> http://paste.debian.net/243647/
<zigo> It did work for 3.2.0-* though.
<cjwatson> That has nothing to do with dependencies though
<zigo> Ah no.
<zigo> Sorry, forgot to push / pull it seems.
<zigo> cjwatson: Right, that's another problem! :)
<zigo> Uploaded.
<mitya57> zigo: hi again :)
<mitya57> you need either *both* patches or none of them
<zigo> mitya57: Both being which ones?
<zigo> I applied only the one from upstream, for linux 3.7+, and it worked, always ...
<zigo> For me, it seems fine.
<mitya57> what you applied doesn't make sense without https://bazaar.launchpad.net/~mitya57/ubuntu/precise/blktap-dkms/lp1157421/view/head:/debian/patches/support_kernel_3.4.patch
<mitya57> worked? let me recheck...
<hallyn> wait - does uefi not work with virtio?
<zigo> Yup, it seems it built with 3.2 and 3.8 kernels.
<zigo> I didn't try with 3.4 though (as this isn't in Debian).
<mitya57_> zigo: I have no clue why it works for you without the "first" patch, but if it works, let's leave it as is
<mitya57_> fwiw, my patch was based on https://github.com/mcclurmc/blktap-dkms/commit/d33302b91d
<hallyn> cjwatson: trying 12.0.4.2 desktop install again.  last syslog line is "purging configuration files for user-setup", then I see defunct plugininstall.p
<hallyn> well, but no, i guess dpkg is still running.  it's not really hung.
<hallyn> wonder why it's sooooo sloooooooooow
<GridCube> hi, its allow-guest removed from the default lightdm.conf?
<ogra_> distro packages shouldnt use" !#/usr/bin/env python", right ? or do i misremember
<ogra_> ah, there was some confusion of autopilot setting it to env ... seems thats not ture
<mitya57> ogra_: they can, but /usr/bin/python[3] is better, see http://lists.debian.org/debian-python/2012/04/msg00104.html
<ogra_> yeah
<ogra_> thats what i remembered
<ogra_> just wanted to make sure i didnt miss another policy change :)
<mitya57> You shouldn't care if you use dh_python2 (3)
<ogra_> yup
<hallyn> stgraber: all right, so 12.04.2 in qemu using ovmf and ide drives seems to be installed in secure mode.  Now - this appears to be (in contrast to TPM) completely useless to me.  So what exactly was it that you wanted to have be configurable?
<hallyn> pstore?
<stgraber> hallyn: so what we should have configurable is the various secureboot bits. Basically having the option to preseed the VM with the standard Windows CA or have it boot in setup mode (without any key)
<hallyn> ruh roh - fails to boot on second boot
<hallyn> stgraber: ok, i think i understand - thx
<bdrung> bryce: i like to help fixing bug #1094499. i can reproduce the crash and could help collecting the needed information. i just need to know what to do.
<ubottu> bug 1094499 in libdvdnav (Ubuntu) "vlc crashed with SIGSEGV in dvdnav_describe_title_chapters()" [Medium,Confirmed] https://launchpad.net/bugs/1094499
<ev> mpt: why require the tilde character in the package subscription field on errors.u.c? It's always going to be a team or user, so isn't the tilde superfluous?
<mpt> ev, to distinguish it from a package name
<ev> mpt: you think people will type the name of a package into a box preceded by "packages subscribed to by"?
<mpt> Oh, right. Why did I do that?
 * mpt rereads
<Sarvatt> bdrung, bryce: looks like http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2013-March/001896.html is the fix to that
<mpt> ev, ah, it's because I specified a combo box, where the currently selected menu item wouldn't be visible
<mpt> whereas now it's a menu followed in that case by a text field
<Sarvatt> (possibly)
<ev> ahh, in that context it makes sense to me
<mpt> ev, in that case, yeah, drop the tilde
<ev> woo
<ev> bdmurray: ^
<mpt> ev, <http://www.quickmeme.com/meme/3thdxg/>, but in the meantime, I'll edit to describe the text field
<ev> lol
<bdrung> Sarvatt: let me try that patch
<bdrung> Sarvatt: nope, it does not help
<stokachu> barry: im using this http://paste.ubuntu.com/5637189/ for python dict with named attributes on 2.7 and was curious if this was a decent approach or if you know a better way
<cjwatson> stokachu: Have you tried collections.namedtuple?
<stokachu> cjwatson: i looked at that but was turned off since they were immutable
<cjwatson> true
<stokachu> i also saw recordtype on pypi which is a mutable named tuple of sorts
<cjwatson> having lots of explicit setattrs seems dangerous; not sure why you wouldn't just implement __getattr__ instead
<mpt> ev, https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=152&rev1=151
<cjwatson> I mean it seems kind of like an invitation for things to get out of sync
<stokachu> cjwatson: hmm good point
<ev> thanks
<cjwatson> the point of that sort of seems to be to constrain the set of field names at __init__ time
<cjwatson> I think if I wanted to do that I might have just stored the set of keys somewhere and consulted it in __getattr__ instead
<cjwatson> but whatever :)
<stokachu> lol, i also found this routine that does a mutable named tuple as well http://paste.ubuntu.com/5637204/
<stokachu> but it won't handle nested dicts
<stokachu> which i guess really isn't a problem
<barry> stokachu: hey.  yeah, it's kind of a shame you have to roll your own mutable named tuples
<stokachu> barry: i saw python 3.3 has something like a simplenamedtuple or something
<barry> stokachu: afaict, not in the collections module
<barry> doesn't ring a bell
<stokachu> ok
<smartboyhw> slangasek, ping
<ev> jodh: \o/ well done
<jodh> ev: ta :)
<slangasek> smartboyhw: hello
<smartboyhw> slangasek, private message?
<slangasek> smartboyhw: sure
<chiluk> mvo in regards to pad.lv/1087543  Can we get that SRU'd into precise as well?
<chiluk> I can create the debdiff if you'd like, but I wanted to find out what you'd want first *(if anything).
<infinity> Well, and if what he committed upstream matches the patch.
<chiluk> deb-diff bzr branch?...
<chiluk> right.
<roadmr> Hey folks! question. We're past feature freeze, I have upload rights for a package, and I need to upload a new version that contains only bugfixes. Do I upload it as usual or is additional process needed to e.g. get it reviewed/approved by someone? (e.g. release team)
<slangasek> roadmr: upload as usual
<slangasek> roadmr: the feature freeze exception process is for things that are exceptions to the freeze on *features*, bugfixes require no extra paperwork :)
<roadmr> slangasek: awesome, thanks!
<xnox> roadmr: also we are in UI freeze as well, so if your package/app is visible in screenshots / documentations / translations please get a UIFe for it.
<slangasek> ... if you're changing the UI
<roadmr> xnox: thanks for the reminder :) Just checked, no UI or string changes
<mvo> chiluk: I think we can SRU it if it got serious testing from you guys
<mvo> chiluk: iirc this is already in debian experimental, I'm not 100% certain about the freeze status in raring, but I think we could merge some of the recent fixes in apt should all be pretty safe for raring
<chiluk> mvo, testing does become the issue.
<chiluk> and that is my concern as well.
<mvo> chiluk: I see, what can we do? provide a testing PPA for you to make the testing eas{y,ier} ?
<chiluk> Yeah I guess a precise PPA wouldn't be a bad idea.
<chiluk> let me ask this how do you feel about the risk of this change.
<mvo> chiluk: I think the risk is low but non-zero
<chiluk> mvo at first glance it looks like a quick change
<mvo> chiluk:  I can create a testing PPA on monday - would you remind reminding me again then?
<chiluk> yeah sure.. I can do it as well.
<mvo> chiluk: sure, either way is fine
<chiluk> also where is the development branch for apt.
<chiluk> is it lp:ubuntu/apt ?
<mvo> chiluk: the ubuntu branch is lp:~ubuntu-core-dev/apt/ubuntu
<chiluk> mvo glad I asked I wouldn't have guessed that.
<mvo> chiluk: the upstream one is on bzr.debian.net/bzr/apt/debian-{wheezy,sid,experimental2}
<mvo> chiluk: :) its in the apt-cache showsrc apt header in Vcs-bzr
<chiluk> thanks mvo, I'm still new to source control in this debiany world..
<mvo> chiluk: np
<mvo> chiluk: and thanks for working on this! just keep me updated on the PPA thing, I will go and have dinner now :)
 * mvo waves
<chiluk> thanks mvo
<mvo> yw
<bdmurray> slangasek: so the other day was a bug day for ubuntu-release-upgrader and some bug triage was done and I'm reviewing most of it.  There is one bug 1044144 re: 'mixed non-coninstallable and coinstallable package instances present' which sounds familiar.
<ubottu> bug 1044144 in ubuntu-release-upgrader (Ubuntu) "Upgrade from kubuntu 12.04 to 12.10 failed using "sudo do-release-upgrade -d "" [Undecided,Confirmed] https://launchpad.net/bugs/1044144
<infinity> bdmurray: I think we have a hackish workaround in dpkg for that now.
<infinity> bdmurray: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1015567
<ubottu> Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [Critical,Fix released]
<infinity> bdmurray: Your bug is probably a dupe of that, and long ago fixed.
<infinity> Well, "fixed".
<bdmurray> infinity: thanks I knew it sounded familiar
<infinity> We still don't have a strategy to upgrade the database sanely, IIRC, but the symptom should be gone.
<bdmurray> right the upgrade looks like bug 1057367
<ubottu> bug 1057367 in dpkg (Ubuntu) "please upgrade status database to remove mixed non-coinstallable and coinstallable packages" [Low,Triaged] https://launchpad.net/bugs/1057367
<bdmurray> which probably should be targetted to some future release
<infinity> Oh look, there's a new dpkg in unstable for me to merge.
<ScottK> What could go wrong?
<infinity> It's all just bugfixed and translations, it was aimed at a freeze unblock.
<infinity> bugfixes, even.
<infinity> In fact, MOM did a clean merge.  I wonder if I should be suspicious of that. :P
<bdmurray> slangasek, infinity: I've also seen a couple of bugs where packages eem to unpacked and then later when trying to set them up there is an error regarding them not being installed
<bdmurray> bug 1068996 is an example
<ubottu> bug 1068996 in ubuntu-release-upgrader (Ubuntu) "Kubuntu upgrade to 12.10 failed" [Undecided,Incomplete] https://launchpad.net/bugs/1068996
<cjwatson> I think you've mis-explained that
 * cjwatson follows up
<cjwatson> (done)
<cjwatson> heh, that terminology is particularly confusing in that example.  In the first case "installed" really means "configured", and in the second case it really means "unpacked", I think.
<bdmurray> cjwatson: could you elaborate a bit?
<cjwatson> I followed up in the bug - do you mean elaborate further on that?
<bdmurray> "In the first case 'installed' really means 'configured'".  Which first case?
<cjwatson> You quote a fragment of apt-term.log with two occurrences of "installed"
<cjwatson> wait.  sigh.  I'm obviously confused and should finish for the week.
<ironhalik> Hello, I'm a newbie and I wanted to submit a patch. I'm just not sure wether I should submit it to the gnome project or Ubuntu (it regards gnome-system-monitor) to get the best chance of seeing it in 13.04
<cjwatson> bdmurray: followed up again in a slightly less confusing way, sorry
<bdmurray> cjwatson: ah, thanks
<bdmurray> ironhalik: given where we are in the development of 13.04 I would say both
<bdmurray> infinity: is that previous bug really bug 1062503?
<ubottu> bug 1062503 in apt (Ubuntu) "apt fails to install libglapi-mesa-lts-quantal correctly on switching x stacks" [High,Fix released] https://launchpad.net/bugs/1062503
<bdmurray> 'do not do lock-step configuration for a M-A:same package if it isn't unpacked yet in SmartConfigure and do not unpack a M-A:same package again in SmartUnPack if we have already configured it
<infinity> bdmurray: It *might* relate.  It's hard to say from just the log why the :i386 one hadn't been unpacked.
<infinity> bdmurray: It might not have been on the install list at all, which would be a resolver failure, or it might have been on the list, but not unpacked at the right time.
<geomyidae> Can I get help with these bugs: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1080701 https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1120938
<ubottu> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed]
<ubottu> Launchpad bug 1120938 in ubiquity (Ubuntu) "Ubiquity hangs after the initial summary screen" [Undecided,Confirmed]
<geomyidae> I think they're the same bug, kind of a bigish deal imo
#ubuntu-devel 2013-03-23
<cjwatson> I wonder if that's also bug 1085991, for which there appears to be a patch awaiting my review
<ubottu> bug 1085991 in ubiquity (Ubuntu) "Partitioning options do not come up in ubiquity & d-i" [High,Confirmed] https://launchpad.net/bugs/1085991
<cjwatson> except looks like that's been uploaded
 * cjwatson merges anyway
<cjwatson> geomyidae: if you're ~colemickens, please attach /var/log/partman as well
<cjwatson> and /var/log/syslog
<cjwatson> geomyidae: in fact, the best thing that could be done to gather more data on this is to boot to a live session (e.g. exit the installer immediately it starts), then edit /lib/partman/automatically_partition/15reuse/choices to change 'set -e' near the top to 'set -ex', run 'ubiquity --debug', reproduce the bug, extract /var/log/syslog /var/log/partman /var/log/installer/debug, attach to bug report
<cjwatson> but I need sleep now ...
<geomyidae> cjwatson: fantastic! thank you, I will absolutely try this ASAP, this is exactly what I was looking for. thanks so much!
<ginggs> hi, is there a way to search through ubuntu build logs for a string?
<ginggs> in particular "jh_installeclipse: Cannot determine the package providing", relating to LP: #1158182
<ubottu> Launchpad bug 1158182 in eclipse-rse (Ubuntu Precise) "ships broken symlink to java/commons-net2.jar" [Undecided,New] https://launchpad.net/bugs/1158182
<sarnold> ginggs: I might try starting with google, "site:launchpadlibrarian.net ...."
<ginggs> thanks sarnold, but no luck :(
<sarnold> ginggs: maybe launchpad.net? perhaps launchpadlibrarian has asked google to not index...
<ginggs> nothing there either, the build logs I'm after are on launchpadlibrarian.net, like this one: https://launchpadlibrarian.net/51128829/buildlog_ubuntu-maverick-i386.eclipse-rse_3.1.2-1_FULLYBUILT.txt.gz
<sarnold> darn, I was wishing..
<fishor> hallo devs. One question. the gnome-sound-recorder is completely dead on 13.04. I ported it to gstreamer-1.0 and extracted it from gnome-media. So my version use less dependencies...
<fishor> are there any chance to include it in 13.04
<mitya57> fishor: Will that be included in gnome 3.8? I don't see any (standalone) tarballs of sound-recorder...
<fishor> it is not included in gnome 3.8. there is confising situation. Gnome peaple do not wont accept any more patches - they say it should die.  Reason for it is that other dev have tried to create sound-recorder from scratch on vala.  But this project is dead for year now, becous he has no time...
<mitya57> fishor: so where can I find your code?
<fishor> mitya57,  https://gitorious.org/gsr/gnome-recorder
<fishor> it is based on gnome-media package... i remove all other programs from it and did some rebase. Now i started to do some code refactoring ... separating  gui from gstreamer code
<mitya57> fishor: but *where* is it? in gnome git / github / launchpad / ...?
<fishor> gitorious.org
<fishor> mitya57, you mean some thing different?
<mitya57> fishor: this one: https://gitorious.org/gnome-sound-recorder/gnome-sound-recorder/commits/master ?
<fishor> mitya57, this is alternative dead project, i send you a link before,
<fishor> https://gitorious.org/gsr/gnome-recorder
<mitya57> fishor: I think the diff is too large for raring. Maybe you can provide a *minimal* set of patches that'll make it working? Otherwise it's probably for 13.10...
<fishor> you mean reanimate comlete gnome-media package?
<fishor> and keep it using gstreamer-0.10
<mitya57> fishor: is it impossible to get it working with 0.10?
<mitya57> or maybe make it using 1.0 but the reset of gnome-media using 0.10>
<mitya57> s/>/?/
<fishor> mitya57, by porting to gst-1.0 we need to remove gst-mixer
<fishor> and gstreamer-properties
<fishor> then there will be nothing to keep
<mitya57> no, I don't think it's a change we want in raring :(
<fishor> mitya57, are there any thing what depend on gnome-media in raring?
<mitya57> fishor: not on raring now, but I believe only gnome metapackage depends on it
<fishor> mitya57, so, probably better solution to remove gnome-media package completely. cleaned recorder works better than this ;)
<mitya57> fishor: can you ask about that on Monday so that we have more developers to discuss that?
<fishor> mitya57, Ð¾Ðº
<mitya57> fishor: fwiw, it looks like ubuntu-gnome-desktop also depends on gnome-media Â­â so it's in default Ubuntu GNOME install
<fishor> mitya57, other question. i wont to make record to store file directly to some directory... so far o know there is no XDG defined folder for Sound/Records, only Music
<fishor> are there any suggestions for it?
<mitya57> use Music or a subfolder there?
<fishor> mitya57, normally sound-recorder used as voice-recorder. It makes no real sense to store is Music folder
<fishor> We have luck that Video folder is not called Movies and Pictures are not Paints :)
<ogra_> agh, what a waste of time, who uploaded ubuntu-mobile-default settings ?  that should have better been removed from the archive ...
 * ogra_ cant find a "signed by" entry anywhere ...
<mitya57> ogra_: "ubuntu-mobile-default-settings" source is present since lucid
<mitya57> the last version was uploaded by LoganCloud who is MOTU now :)
<ogra_> mitya57, yes, and not been used since lucid either
<mitya57> s/lucid/intrepid/
<ogra_> would have helped if he had contacted the last uploader before putting time into it (i was the last uploader and had simply forgotten that package exists)
<mitya57> :)
<mitya57> maybe it'll be used again at some point?
<ogra_> it was for the ubuntu-mobile images that havent existed in years  ... so its just wasted time that another package could have benefitted from
<ogra_> i doubt it would be used again ... and even if there would be a new package under that name that would have been created from scratch for the new purpose (its unlikely that it would have been used as is ever again)
<ogra_> anyay ... shit happens ...
<ogra_> :)
<mlankhorst> can someone accept mesa-lts-quantal?
<Guest43282> hello folks, is there any tutorial how to integrate my c++/qt app into unity/gnome? (Desktop application)
<Guest43282> (Make use of QuickList..)
#ubuntu-devel 2013-03-24
<HerbertWest> Hello,in ubuntu development: I would like to understand some things. I'd already read some documentation (Packaging, PGP, develop software, Launchpad,etc) I Need to know how to start lessons (still working, subscription is avaliable only sending an email?),and finally... start a contribution, a software development.. how? TY
<vibhav> HerbertWest: If you want to start with development in Ubuntu, have a look at the packaging guide developer.ubuntu.com/packaging/html/
<vibhav> HerbertWest: You can also get involved with the ubuntu documentation team at https://wiki.ubuntu.com/DocumentationTeam
<abderraouf> hi
<abderraouf> Hello
<abderraouf> There are two proposals to improve Xubuntu
<abderraouf> One:
<abderraouf> Director files property add make each executable files. And not only a particular file type.
<abderraouf> Two:
<abderraouf> Add graphical interface to insert the proxy.
<abderraouf> Greetings from the Linux community Arab.
<abderraouf> Hello
<abderraouf> There are two proposals to improve Xubuntu
<abderraouf> One:
<abderraouf> Director files property add make each executable files. And not only a particular file type.
<abderraouf> Two:
<abderraouf> Add graphical interface to insert the proxy.
<abderraouf> Greetings from the Linux community Arab.
<philwyett> Could someone clear the awaiting approvals on the ubuntu-devel list?
<philwyett> Is there an issue with the precise upload and build queue? It seems stuck.
<swrh> i'd like to get involved in the ubuntu development community. i have c/c++, shell and python skills. is fixing bugs the best way to get started?
<JanC> it's certainly a good way to get familiar with the procedures & infrastructure
<sgtnasty> @find eclipse phase
<udevbot_> Error: "find" is not a valid command.
<greg_25> Hello, is there any way to integrate my qt application into gnome/unity (gtk)?
<mitya57> greg_25: please go to #ubuntu-app-devel
<mitya57> (and be more verbose_
<mitya57> )
<greg_25> mitya: I asked in three channels, includinge app-dev and you are the first who responds
<mitya57> greg_25: ok, what you mean by "integrate"?
<greg_25> Using the Quicklist, get an application icon (only way .desktop?), menubar top
<mitya57> greg_25: (a) you can use static quicklist items (b) https://qt-project.org/doc/qt-4.8/qapplication.html#windowIcon-prop (c) your menu will become global automatically
<mitya57> well, (c) only works for Qt 4 now, but Qt 5 will be fixed soon
<greg_25> mitya57: thank you very much, i will take a look
<greg_25> mitya57: at the ubuntu developer guidlines there is only a refernce to an article isnt existing anymore (C++ section)
<mitya57> greg_25: where is that reference?
<greg_25> http://developer.ubuntu.com/resources/programming-languages/c-and-c-plus-plus/
<greg_25> >Writing Qt desktop apps in C++ â if you want to write a Qt/KDE app, this is a great start.<
<greg_25> pointing to 4.3
<mitya57> greg_25: I've reported bug 861455 about that long time ago
<ubottu> bug 861455 in Ubuntu App Developer site "Fix Qt documentation links" [Low,Triaged] https://launchpad.net/bugs/861455
<mitya57> the correct link is http://qt-project.org/doc/qt-4.8/tutorials.html
<greg_25> but there isnt anything like quickly...a template for ubuntu projects, right?
<mitya57> greg_25: https://launchpad.net/quickly-community-templates has templates for qt and qtquick
<greg_25> aww, very nice, exactly what Iam looking for
<greg_25> thank you very much
<highvoltage> stgraber: you probably know about most of this, but I found it interesting: http://womble.decadent.org.uk/blog/the-terrible-state-of-efi-variable-storage.html
<oscailt> Hi. Just wondering if anyone knows whether or not 13.04; is currently supporting the Realtek "RTL8723AE-BT" wireless driver?
<oscailt> Hi. Lost connection so sorry for asking the same question twice in a row.
<oscailt> Just wondering if anyone knows anything about the Realtek RTL8723AE-BT in regards to 13.04
#ubuntu-devel 2014-03-17
<slangasek> xnox: so I definitely have current bash-completion installed, and bash is definitely not completing filenames for me... I'm ready to start pulling my hair out :)
<Unit193> slangasek: Yes, I have bash-completion problems as well, in Trusty and Debian.
<pitti> Good morning
<RAOF> pitti: Good morning.
<pitti> hey RAOF
<pitti> RAOF: thanks for the _add() error fix, just reviewed
<RAOF> pitti: Are you likely to get around to implementing evemu-format playback support anytime soon?
<pitti> RAOF: not in a matter of days, but if you guys need it for Mir I can add some priority to that
<pitti> RAOF: so far nobody really needed it, so I didn't pay much attention to it
<RAOF> Well, it looks like it's required for any acceptance tests with input recordings, thanks to the magic of time_t.
<pitti> RAOF: yeah, or doing per-arch recordings
<pitti> RAOF: record&replay generally is rather arch specific, at least with endianess
<pitti> RAOF: most ioctls work (on the same endianess) as most of them are rather carefully constructed to work on multi-arch
<pitti> RAOF: i. e. with explicit int lengths etc.
<pitti> but pure user-space stuff often doesn't
<RAOF> So are *almost* all of the evdev bits. Just the little time_t in struct timespec.
<pitti> still weird why time_t wouldn't be 64 bit on 32 bit archs
<RAOF> Because it wasn't in the past?
<pitti> it'll change by 2038 :)
<RAOF> Indeed :)
<RAOF> Ok. Time to EOD anyway.
<dholbach> good morning
<mardy> Riddell: hopeful Monday pong :-)
<dkessel> Good morning dholbach
<dholbach> hi dkessel
<xnox> slangasek: =( there are more bash-completion patches floating around, but i'm not sure about applying them.
<xnox> slangasek: i'd rather see it fixed rather than reverting bash upload.
<xnox> =/
<StevenK> xnox: Or you could just tell people to use zsh? WCPGW, right?
<xnox> StevenK: i'm sure i'll get more support to switch to eshell by default, than to switch to zsh.
<StevenK> xnox: No, clearly we need to wait for Lennart to write a shell, then have multiple flamewars about switching to it as the default.
<hyperair> and this shell shall have native pulseaudio and systemd integration!
<hyperair> whatever that means
<hyperair> (while also reimplementing all the functionalities of a DE)
<darkxst> I *want* a shell with GNOME integration ;) who cares about auto-completion...
<hyperair> lawl
<darkxst> ^ it is sorely broken right now though ;(
<hyperair> oh and it's going to be modular, so it'll have multiple daemons!
<darkxst> hyperair, hang on, shouldnt it be monilithic so it takes however as much as possible?
<hyperair> non non
<hyperair> it should be modular, but everything needs to be in the same git repository because a lot of code will be shared between each module!
<darkxst> "monolithic so it takes over as much as possible" apparently I can't type too well in the dark ;)
<hyperair> well, systemd isn't monolithic
<hyperair> it's just very "tightly integrated" with the rest of its other daemons
<hyperair> like networkd or udev or the other stuff
<zequence> Hi. Got a package that would need to be uploaded soonish. It's a FFe, and doesn't show in the sponsors queue. It was uploaded to the archives once already, but was rejected due to some lintian warnings, which are gone now Bug: 946591
<ubottu> bug 946591 in Ubuntu "[FFe] Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<hyperair> oh yes, here's the idea. the entire gnome should enter lennart-shell.git
<hyperair> zequence: FFe approved or not?
<zequence> hyperair: I need to ask in the mail list?
<hyperair> zequence: try poking some ubuntu-release folk
<zequence> This was not a FFe originally, but became one
<zequence> hyperair: Ok. Thanks
<hyperair> ^ that should trigger any hilight rules for ubuntu-release people lurking in the channel, so sit tight and wait, i think
<hyperair> or you could ask in #ubuntu-release
<hyperair> once the FFe's approved, you can get it uploaded
<hyperair> is that for main or universe?
<zequence> universe
<zequence> ubuntustudio stuff
<hyperair>  isee
<hyperair> is the ubuntustudio stuff not in main?
<zequence> no. I think only Canonical maintained is in there?
<zequence> All of our packages are in universe
<hyperair> i see
<hyperair> okay, i can help you upload it once you get your FFe acked
<zequence> ..except one, I think (ubiquity-slideshow-ubuntustudio)
<zequence> hyperair: Thanks
<zequence> (no, that one was in universe as well)
<MacSlow> tsdgeos, hey Albert...
<MacSlow> tsdgeos, can you re-check https://code.launchpad.net/~macslow/unity-notifications/dont-ignore-placeholder/+merge/206950
<tsdgeos> MacSlow: sure
<MacSlow> tsdgeos, I've updated the info and related MP-descriptions (explaining dependencies)
<MacSlow> tsdgeos, thx
<MacSlow> tsdgeos, yes... it the "PlaceHolder" for the synchronous notification (e.g. volume up/down) once we'll get a Design and UX for it.
<jamespage> infinity, the libgcrypt11-dev preference change you made in percona-xtrabackup - is that something I should pick into my next upload in Debian?
<Riddell> mardy: I uploaded signon-qt with a change to stop qt4 and qt5 cmake files overlapping
<mardy> Riddell: thanks!
<Mirv> there's a new hud release pending and tested, but I'd need a core dev ack for the packaging changes: http://162.213.34.102/job/landing-002-2-publish/55/artifact/packaging_changes_hud_13.10.1+14.04.20140314-0ubuntu1.diff
<cjwatson> Mirv: ack assuming that somebody is also landing libdbusmenu-qt5-dev 0.9.3
<mlankhorst> what exact date is quantal EOL?
<didrocks> Mirv: does it build on arm64?
<didrocks> not sure it was in the silo having it
<Mirv> thanks colin, yes libdbusmenu-qt5-dev 0.9.3 is part of the same landing
<Mirv> didrocks: yes it did
<Mirv> (but not on powerpc/ppc64el)
<didrocks> Mirv: excellent, one issue to remove from the list :)
<didrocks> Mirv: yeah, expected
<didrocks> thanks!
<Mirv> mlankhorst: I'd expect Apr 18th, since it was release October 18th 2012
<mlankhorst> ah k, it wasn't clear from the wiki
<slangasek> xnox: so as noted, the tab completion is not the only regression I've seen; the change in reverse-search behavior and ^C handling are also rather disruptive.  Do you think we're going to get all of these fixed in time for 14.04?  If not, I think a revert is in order
<slangasek> xnox: (and how did this even land, post-FF?)
<xnox> slangasek: "how did this even land, post-FF", without FFe -> talk to the AA who upload it ;-)
<slangasek> xnox: yes, I certainly will when he's back, just wondering if you knew some mitigating circumstances that I did not :)
<xnox> slangasek: nah, just seb128 complaining a lot that "it should not have landed without FFe"
<xnox> =)
<seb128> it should not indeed
<xnox> slangasek: there is a patch for bash posted that should fix unquoting/completion bugs. I don't see patches about reverse-search behaviour / ^C handling.
<barry> xnox, slangasek what's the bug about revsearch and ^C?
<slangasek> barry: revsearch> a failed revsearch, instead of giving you a visual bell, now just changes the prompt to 'failed reverse-i-search' and lets you continue typing
<barry> slangasek: ew, yeah i see that too :(
<slangasek> barry: ^C> if you're in the middle of a wrapped line and ^C, the prompt is placed at the next line below the current prompt, without clearing the text
<cjwatson> infinity: https://launchpadlibrarian.net/168801577/buildlog_ubuntu-trusty-i386.installation-locale_1.5_FAILEDTOBUILD.txt.gz looks like an eglibc bug to me.  It's using 'copy "i18n"' in its LC_MONETARY declaration; eglibc's localedata/locales/i18n sets int_curr_symbol to "<U0058><U0044><U0052><U0020>" i.e. "XDR ", which http://www.iso.org/iso/currency_codes has registered to the IMF; but locale/iso-4217.def doesn't contain "XDR"
<cjwatson> infinity: do you agree?  it looks as though a locale/iso-4217.def resync would fix this ...
<bdmurray> tseliot: given that hybrid-detect is no longer in ubuntu-drivers common shouldn't /etc/init/hybrid-gfx.conf be changed?
<tseliot> bdmurray: I forgot to make the package remove the file from /etc but I'll fix it soon
<bdmurray> tseliot: okay, sounds good
<cjwatson> pitti: Can you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5717053 (pkgbinarymangler)?  That's a lot of test failures
<pitti> cjwatson: ouch, indeed; I'll look at that
<cjwatson> thanks
<pitti> cjwatson: I figure this is just a test issue, otherwise trusty would have exploded already; so not an "OMG drop everything immediately" emergency
<cjwatson> Yeah, presumably
<pitti> right, I get the very same in a local run now
<pitti> finishing the phonesim PIN investigation, then looking at that
<pitti> xnox: ok to upload your ofono fix for the python3-dbus dependency?
<pitti> that breaks stuff ATM
<pitti> (already asked last week, but I guess it got drowned)
<cjwatson> seb128: do you think we can disentangle the various arch-restrictions we put in for the friends/signon/account-plugins cluster?
<cjwatson> seb128: they should be unnecessary now that we have Qt 5.2
<cjwatson> (I think)
<xnox> pitti: oh, yes please.
<xnox> pitti: do you want me to upload, or will you?
<seb128> cjwatson, that should be fine I think yes
<pitti> xnox: I don't mind; I mostly wondered why you didn't alreayd, as it's an obvious fix
<pitti> xnox: or is that in CI these days?
<xnox> pitti: oh, i thought it needs "landers landings et al". If it's just dput, i can do it.
<pitti> awe: can we just dput the python3-dbus dependency fix for ofono-scripts, or is ofono in CI now?
<xnox> cjwatson: hm, infinity  and i did disentangle some of those already. account-plugins -> done, signon -> done. dee-qt ftbfs is the blocker to get ubuntu-ui-toolkit which should get us more things building.
<awe> pitti, we have a bzr branch for the ofono packaging...
<pitti> awe: yes, I know, and xnox fixed it there already
<cjwatson> xnox: dee-qt's done as of this morning
<xnox> cjwatson: \o/
<cjwatson> and hud
<pitti> awe: can we just dput that, or does it need the CI landing exercise now?
<xnox> excellent!
<awe> what's the diff???  I'm working with it now, and it looks like ofono-script specifies all the right packages
<pitti> awe: just python-dbus â python3-dbus dep
<cjwatson> so yeah, in fact libfriends can build again, in theory; let me try that
<pitti> awe: that got missed from converting ofono-scripts to py3
<awe> pitti, hmmm that's present in the branch I'm working with.  Lemme check the master
<pitti> awe: yes, it is already committed, just not uploaded yet
<xnox> cjwatson: src:qml-friends is arch-restricted.
<awe> ah..ok
<pitti> . o O { core-dev isn't what it used to be }
<cjwatson> xnox: yeah, I expect there's more to disentangle.  thanks.  perilously close to the touch stack being arch-sane again though ...
<Laney> pitti: Pretty sure you could upload, especially if it's in trunk
<awe> pitti, we have a blocker that needs to get resolved first ( a ftb on ppc64le ); I'll work with seriusens or rsalveti to get an upload to happen
<awe> pitti are you blocked by this?
<pitti> awe: not me personally, but I figure it could cause some test failures in CI
<xnox> awe: ppc64el ftbfs is not a blocker, it never built on it, thus it would migrate just fine.
<pitti> awe: ppc64el is not a blocker, .... yes
<Laney> it's easy for CI uploads to say "yes I really do want to upload"
<xnox> awe: please just upload.
<Laney> so dputs shouldn't really be a problem
<cjwatson> xnox: unity-action-api needs lttng made optional - I'm working on that
<cjwatson> (for ubuntu-ui-toolkit)
<pitti> Laney: ah, right; it was teh committing which is the CI controlled thing these days
<cjwatson> actually maybe not, I see it's built
<cjwatson> I was thinking of unity-scopes-api
<xnox> cjwatson: i did unwind portions of lttng packages.... maybe more can be fixed, we have a few things of that already. Let me look.
<awe> xnox, I can't, as I don't have the rights...  as I said, I'll work with rsalveti or sergiusens to get it uploaded
<pitti> xnox: right, so dput should be fine
<cjwatson> xnox: yeah, so did I
<cjwatson> xnox: I know how to do it, thanks
<xnox> cjwatson: ok.
<pitti> awe: no worries, xnox or I will; I just wondered about landing through CI
<cjwatson> xnox: (https://code.launchpad.net/~cjwatson/upstart-app-launch/porting/+merge/210385 in my case)
<rsalveti> we were planning to land this via CI
<rsalveti> which should happen today still
<Laney> Yeah, CI train makes you explicitly do something about archive uploads
<xnox> cjwatson: not needed anymore, liblttng-ust-dev is available on ppc64el.
<xnox> cjwatson: or am i missing something?
<cjwatson> xnox: oh.  lttng-tools isn't though
<cjwatson> xnox: ok, I didn't realise you'd ported that ...
<cjwatson> xnox: fancy doing ltt-control as well then? :)
<xnox> cjwatson: i was bored on the weekend unwinding things.
<cjwatson> You sure were :)
<xnox> cjwatson: i have a new thing stuck however - db5.3 "gained" test-suite errors on arm64 (as seen in -proposed and the test-archive rebuild), which blocks openldap.
<xnox> cjwatson: openldap has test-suite failure further down in the test-suite upon using mdb, which i have prepared to disable for now (it's already disabled on !linux) i guess test-suite never got that far to notice that.
<Laney> xnox: please forward the ust changes ;-)
<xnox> Laney: yeah.
<xnox> Laney: i'm on lttng-dev mailing list feeding upstream patches.
<Laney> cool
<xnox> cjwatson: ltt-control built.
<cjwatson> thanks
<infinity> jamespage: I don't think Debian needs that, no.  Debian (whether they know it or not) is in the process of a slow organic gcrypt transition.
<infinity> jamespage: I just didn't want that transition in Ubuntu for trusty.
<jamespage> infinity, ack
<infinity> cjwatson: eglibc, or locales?  I still haven't re-integrated that (running out of time for that to be a sane option, but maybe if I land it in the next couple of days)
<cjwatson> infinity: eglibc itself
<cjwatson> (I think)
<cjwatson> xnox: ltt-control> you didn't do arm64
<infinity> cjwatson: Whoa, more backscroll, you sorted dee-qt?
<cjwatson> infinity: Yeah, tsdgeos and I figured out a workaround between us anyway; but it seems to be a linker bug
<cjwatson> It's basically https://bugreports.qt-project.org/browse/QTBUG-36129 and http://lists.linaro.org/pipermail/linaro-toolchain/2014-January/003942.html
<cjwatson> infinity: But building with PIE works around it for now (wibble wibble linker horror)
<infinity> s/PIE/pie/
<infinity> Also, wheeeee.
<cjwatson> So we have ubuntu-ui-toolkit everywhere now, once powerpc catches up anyway
<infinity> That sounds a whole lot like something I wish I hadn't asked about.
<cjwatson> Yup
<xnox> cjwatson: =( sorry.
<cjwatson> infinity: If you fancy teaching mir how to do big-endian GLPixelBuffers or whatever it is, we might even be able to get that part of the stack ;-)
<cjwatson> https://code.launchpad.net/~cjwatson/mir/stdint-include/+merge/211340 should sort mir/arm64, and http://paste.ubuntu.com/7109133/ on top of that makes most of the tests pass on ppc64el; I haven't sorted out whether the rest is just my build environment being wonky, which it might be
<infinity> cjwatson: Making mir endian-clean should be something they should have done from the get-go.  If I find "free time", I can look into it, though.
<cjwatson> I don't disagree, but at least there's a clear TODO for it
<xnox> cjwatson: infinity: cause clearly ubuntu-touch on ppc64el with a 7 foot watcom screen is a must for our tradeshow large audience demos =)
<cjwatson> xnox: Looks like ubuntu-sdk-libs-dev is still not multiarch-installable, but I filed https://code.launchpad.net/~cjwatson/webbrowser-app/multiarch/+merge/211350 to disentangle the next bit
<cjwatson> xnox: Well, yeah, but multiway-entangled archive and all that; and we probably *will* want it on arm64 at some point
<xnox> cool.
<tarpman> xnox: speaking of openldap. did you test the db5.1->db5.3 change on a system with slapd installed? I just tried that upgrade and it looks like it needs the database dumped and reloaded (but maybe I missed something)
<xnox> tarpman: no i did not, but it does stop slapd, does dump_database and reapplies them in postinst, thus it should just work.
<ogra_> xnox, will you make sure there is an android rebuild for your initramfs touch change ?
<xnox> ogra_: not needed.
<ogra_> ?
<xnox> ogra_: but i can make one.
<ogra_> it wont be picked up
<xnox> ogra_: i know.
<ogra_> and it would be good to set it break asap to fix it ;)
 * ogra_ grins
<tarpman> xnox: the db is always dumped, yes, but reloaded (by default) only when upgrading past the slapd version mentioned in database_format_changed; anyway, I'll spin up a new VM and double-check I'm telling the truth
<xnox> tarpman: right, that makes sense, I didn't bump those.
<xnox> tarpman: that would be great! thansk!
<didrocks> xnox: you are merging back your changes in upstream trunk, right?
<xnox> didrocks: which ones?
<didrocks> xnox: libhud-qt and so on
<xnox> didrocks: oh is libhud-qt under ci-train? it looked as if it was untouched since forever and last uploads were from daily-release bot which is not operating anymore?
<xnox> didrocks: i'll walk through my uploads and sync things up.
<didrocks> xnox: well, everything which was under daily-release will go over ci-train
<didrocks> xnox: thanks a lot :)
<didrocks> and thanks for the fixes
<didrocks> now that we have the toolkit finally built on all arch, I feel more confident
<didrocks> I'm afraid about libusermetrics though
<xnox> didrocks: meh, it's boring rebuilds work, we totally should have dropped arch restrictions in the "no change rebuilds against qt 5.2"
<didrocks> build-dep on valgrind
<didrocks> xnox: +1 I thought this was done :/
<xnox> didrocks: we don't have valgrind, but that's an easy build-dep to be make arch-dependant, we did it in a lot of other packages, so no worries.
<didrocks> xnox: ah? ok, trusting you then :)
<cjwatson> https://launchpadlibrarian.net/168403467/libusermetrics_1.1.1%2B14.04.20140120-0ubuntu1_1.1.1%2B14.04.20140305-0ubuntu1.diff.gz already has the clue
<cjwatson> it's just that it was incorrectly done in a negative way rather than a positive way
<cjwatson> should've been "enable valgrind only where valgrind is available", not "avoid valgrind on armhf"
<didrocks> ok, something for my tomorrow if nobody beats me to it
<cjwatson> well, also should be Build-Depends: valgrind [amd64 armhf i386 powerpc], but that's easy
<didrocks> then unity8 should be available on all archs from my quick look
<cjwatson> no, still mir
<didrocks> cjwatson: argh, yeah, you're right
<cjwatson> for which see a few dozen lines up here
<cjwatson> 16:51 <cjwatson> https://code.launchpad.net/~cjwatson/mir/stdint-include/+merge/211340 should sort mir/arm64, and http://paste.ubuntu.com/7109133/ on top of that makes most of the tests pass on ppc64el; I haven't sorted out whether the rest is just my build
<cjwatson>                  environment being wonky, which it might be
<cjwatson> and the endianness porting for powerpc
<didrocks> kgunn: as you are going to land a Mir, can you get that one in, please? ^
<didrocks> kgunn: we are trying to have you building on all archs to enables top of the stack
<didrocks> enable*
<cjwatson> if we'd be willing to maybe have some failures visible in build logs which don't block migration, I'd be happy to file an MP with the arch-any bits too
<kgunn> didrocks: so you want it in now ? if so i guess i can rebuild....
<cjwatson> I think it might take a while to get mir ported to the last two arches though
<didrocks> ok so maybe let's get kgunn doing his landing and just after it, dealing with your branch
<kgunn> ok...
<xnox> didrocks: kgunn: did 1.6 land already?! i'd rather have inprogress landing go in already.
<xnox> didrocks: kgunn: we want more velocity, not less =) so no need to constantly reconfigure/delay prepared&tested fixes.
<didrocks> xnox: well, it wasn't tested yet
<xnox> didrocks: well, your/landing/mir folks call  then=)
<xnox> cjwatson: looks like unity-scopes-shell needs more pie
<xnox> cjwatson: https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.4.0+14.04.20140312.3-0ubuntu1 similar to dee-qt
<cjwatson> Right, I'm not sure whether tsdgeos was planning to just turn off symbolic-functions in qtbase
<cjwatson> it's definitely not ideal to have to whack-a-mole this
<tarpman> xnox: installed a new saucy vm, installed slapd, upgraded to trusty: slapd fails to start because the db is still in db5.3 format. want a bug?
<tarpman> s/still in 5.3/still in 5.1
<sarnold> pitti: hello :) 1293156 hasn't yet been handled by the trusty retracers yet, they look unhappy again
<infinity> tarpman: Looks like it needs a database_format_changed tweak, I'll get that.
<infinity> xnox: Sorting tarpman's issue.
<tarpman> infinity: cheers! in case it matters, bugs.debian.org/738641 is the debian side
<debfx> infinity: do you mind if I sync libgcrypt20 1.6.1-2? it doesn't provide libgcrypt-dev anymore.
<infinity> debfx: Why bother?
<infinity> debfx: If it will have no rdeps (and it won't), makes more sense to just let it autosync in for trusty+1
<debfx> not all software is packaged
<infinity> If you think there's a legitimate third-party need for a newer gcrypt, sure.  Sync away.
<debfx> I might be biased as it's my software, but it certainly benefits from the new gcrypt version.
<smb> infinity, Would you have time to look into bug 1290743. Not sure comment #4 was the ok or what exactly would be the ok. The sources would be either in my ppa or on chinstrap
<ubottu> bug 1290743 in xen (Ubuntu) "[FFE] Pull Xen-4.4 into Trusty" [High,New] https://launchpad.net/bugs/1290743
<infinity> smb: On my TODO for today.
<smb> infinity, \o/ Thanks
<bdmurray> roaksoax: is the syslinux task on bug 1092265 valid?
<ubottu> bug 1092265 in syslinux (Ubuntu) "Nodes fail to boot from local disk on raring" [Critical,Triaged] https://launchpad.net/bugs/1092265
<infinity> xnox: Any idea what went wrong with your db5.3 upload on arm64?
<bdmurray> xnox: do you know how to update app-install-data-ubuntu?
<slangasek> xnox, infinity: speaking of things wrong with db5.3 uploads, I noticed that openldap was uploaded to trusty to rebuild against db5.3; but there's an on-disk logfile change, which means this requires a database dump/restore in the maintainer scripts (Debian bug #738641)
<ubottu> Debian bug 738641 in openldap "FTBFS: Transition from libdb5.1-dev to libdb5.3-dev" [Serious,Open] http://bugs.debian.org/738641
<xnox> slangasek: infinity: there is nothing wrong with my db5.3 same/similar failure is present in the archive rebuild without my patch. I didn't investigate it.
<xnox> bdmurray: i have done it once before using mvo's branches. Let me kick off a tarball generation.
<infinity> slangasek: Already fixed in ubuntu8
<infinity> slangasek: http://launchpadlibrarian.net/169846224/openldap_2.4.31-1%2Bnmu2ubuntu7_2.4.31-1%2Bnmu2ubuntu8.diff.gz
<xnox> infinity: i read that at first "already fixed in unity8" and was utterly confused =)))))
<infinity> Hrm, though maybe I should have made that ubuntu8 for the 2 people who upgraded to 5, 6, and 7, and didn't get their DB migrated. :/
<xnox> infinity: those 2 people can die another day ;-)
<infinity> xnox: Right, I didn't assume that Andy's patch broke DB on arm64, just that it's now broken for $some_reason.
<slangasek> infinity: oh. why is ubuntu5 still the latest in trusty?
<infinity> xnox: Also, are you applying that patch to DB 5.1 and DB 6.0 too?
<infinity> slangasek: Because 6 and 7 were FTBFS on ppc64el due to the kernel pagesize change.
<infinity> slangasek: 8 built fine, now that db5.3 is fixed.
<xnox> infinity: i wanted to drop db5.1 from the archive for trusty. But not sure about the last 3 packages that only migrated to db5.3 in trusty.
<slangasek> infinity: oh hah, right
<xnox> infinity: e.g. how it interracts with openldap upgrade.
<xnox> infinity: i didn't debug arm64 build-failure yet. looks as cryptic as dee-qt one.
<infinity> xnox: Dropping it doesn't affect upgrade paths.
<slangasek> xnox: openldap does its db export in the preinst because it doesn't trust db versions to be around
<infinity> The trick is that the preinst runs against the old binaries to dump the DB, then  you upgrade, and reload.
<infinity> The old library doesn't need to be in the archive for that.
<xnox> infinity: right, in that case i'll drop 5.1 from "db-utils-all" (or whatever that one was) and file db5.1 removal request.
<infinity> And it's obviously on your disk, or your old slapd no workie.
<xnox> infinity: re:db6.0 nothing is using it in the archive, and in debian it was suggested to be removed completely due to change of license.
<infinity> xnox: Hrm, cyrus-common might do this differently, though.
<infinity> xnox: No idea how this db-upgrade-util thing works.
<infinity> xnox: If db6.0 is to be removed, remove it, if it's not, fix it. :P
<slangasek> there are some that have preinsts that do evil local copies of the binaries into a private dir :P
<infinity> Okay, so cyrus depends on libdb5.1 in precise, and this db-upgrade-util thing in trusty.
<infinity> Probably worth sorting out WTF that does before dropping it. :P
<xnox> upgrader package - it just provides/depends such that db5.1_dump db5.1_load db5.1_upgrade etc are available on the path... nothing else.
<infinity> Man, I am so done with Monday.
<infinity> slangasek: If you want to upload (or approve an NMU) openldap to Debian to move to 5.3 and bump the upgrade magic number, I'll just megre that back to Ubuntu over my change.
<slangasek> infinity: I don't want to approve an NMU, because I have a new upstream version staged in git which I've been waiting to upload until I knew the answer to this thing; in turn that's probably not mergeable for trusty
<slangasek> (though tjaalton would probably appreciate it if it were)
<infinity> slangasek: Ahh, kay.  That works too.
<infinity> slangasek: So, yes, the answer is that the DB format changes, I just had someone complain this morning, hence my Ubuntu upload to bump the dump/reload magic version. :P
<slangasek> infinity: right ;)
<tarpman> infinity: fwiw, I looked at trusty this morning exactly because I'd posted about it on the debian bug last night ;)
 * tarpman will be *so* embarrassed if it turns out to have been unnecessary
<infinity> tarpman: Well, IRC backscroll claims that you tested an upgrade and it broke.
<tarpman> I did! twice.
<infinity> tarpman: So, I'm assuming you were right. :)
<infinity> tarpman: And my fixed upload should fix it.
<tarpman> three, if you count sid last night
<tarpman> yeah, I'll confirm that as soon as the builds finish (still running tests last I looked...)
<infinity> (Though, I'll note that my upload didn't fix it for people who upgraded to a ubuntu5 already and didn't fix their own breakage...)
<infinity> tarpman: Yeah, the builds all finished and then LP exploded, so they're working on it again.  Whee.
<tarpman> people running slapd on trusty? I feel like your "2" is a high estimate for that...
<tarpman> me and tjaalton I suppose :)
<slangasek> tarpman: if you're wrong, I'll have no choice but to mark you as the openldap maintainer and run away
<tarpman> :D
<infinity> slangasek: That maintainer list is long enough already.
<infinity> slangasek: Especially given the last two uploads being NMUs...
<slangasek> infinity: there you go, stigmatizing NMUs
<infinity> slangasek: I have nothing against NMUs.  The more, the merrier.
<slangasek> infinity: note the changelog, where the second NMU was to fix the fact that the first was broken ;)
<infinity> slangasek: I just find it particularly fun in that case, given the impressive length of the maintainer list.
<tjaalton> tarpman: i don't run it, but need a libkdap built against nss, not done that part yet though :)
<tjaalton> meh, libldap
<juliank> I fixed bug 1288718 today hours before I could access it.
<ubottu> bug 1288718 in apt (Ubuntu) "apt-extracttemplates crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Confirmed] https://launchpad.net/bugs/1288718
<juliank> Independent bug discovery!
<xnox> bdmurray: i'm fighting with archive-index here and I think i'll just package it up and upload it into ppa. After-all it needs/wants fast unsplit mirror access... which a distro/ppa builder will give me =)
#ubuntu-devel 2014-03-18
<barry> cyphermox: ping, re: dbusmenu (maybe)
<cyphermox> barry: pong
<barry> cyphermox: after the last update, two of my applications lost their global menu.  iirc there was a new dbusmenu uploaded recently, and i was wondering if that could be the culprit.  the apps are emacs and claws-mail
<cyphermox> it's not impossible but it's the second time I hear about this today
<cyphermox> not that I do much on dbusmenu ;)
<barry> cyphermox: yeah, i was going to ping tedg, but he's offline and you're next on my "hey, i recognize that guy on the dbus menu team" :)
<barry> cyphermox: i'm just wondering where i should report the bugs.  reporting them on emacs and claws-mail probably won't get much attention ;)
<cyphermox> barry: check if UBUNTU_MENUPROXY is set in your environment
<cyphermox> barry: I'd say either unity or libdbusmenu?
<cyphermox> barry: I wonder if the correct place for the bug isn't indicator-appmenu
<barry> % echo $UBUNTU_MENUPROXY
<barry> 1
<barry> ;)
<barry> (although that's definitely not a new setting)
<cyphermox> nah, it's not
<barry> cyphermox: i guess it should be set, right?
<cyphermox> robru: did you fix that on your system ^ ?
<cyphermox> barry: yes, it should be
<cyphermox> that just means to use them
<cyphermox> (global menus)
<barry> i vaguely remember that ;
<cjwatson> oh hey, you could fix up the libdbusmenu ftbfs :)
<cyphermox> barry: robru asked about this earlier too, but I'm not sure if he fixed it
<cyphermox> cjwatson: I could try, but I'd do that only in a few hours
<cjwatson> I think it's http://paste.ubuntu.com/7111413/ (following https://bugzilla.gnome.org/show_bug.cgi?id=701638, you might want a different approach, not sure) plus documenting the symbols that it complains about now)
<ubottu> Gnome bug 701638 in general "Support automake parallel test harness (fix error with GTKDOC_CHECK)" [Normal,Resolved: fixed]
<robru> cyphermox, barry no never got it fixed
<robru> barry what symptoms are you seeing?
<cjwatson> easier with my mp to make the test suite verbose
<cyphermox> I'm trying to go to bed very soon, I will need to be up in very few hours
<cjwatson> sure
<cjwatson> just hoping to hand off one of the zillion things I've been working on today to somebody with more clue about it :)
<cyphermox> should be simple enough to fix yeah
<barry> robru: both emacs and claws have lost their global menu.  go to the global menubar and the app name never fades into the menu
<barry> robru: this definitely worked a few days ago.  those are the only two apps that i've identified so far as busted
<cyphermox> cjwatson: ftbfs where? I don't see it in LP or on ubuntuwire?
<robru> barry, ok, i'm having the same symptoms on *every* window. I have zero menubar integration right now. luckily the traditional menubars are showing up so apps are usable, just ugly
<cjwatson> cyphermox: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
<cyphermox> oops
<cjwatson> cyphermox: also https://jenkins.qa.ubuntu.com/job/libdbusmenu-trusty-amd64-ci/8/console
<barry> robru: interesting.  chromium seems okay
<barry> ff seems okay
<barry> gtimelog seems okay
<robru> barry, lol, chromium is particularly bad, I get a unity titlebar around the chromium window. no menus either. nor ff
<barry> robru: have you filed a bug?
<robru> barry, not yet, haven't had time to troubleshoot and I wasn't sure if it was something I broke myself (i was tinkering a bit around the time it broke)
<barry> robru: naw, it's at least also partially broken for me too.  i'll ping tedg in the morning (if he's around)
<robru> barry, ok. please email me the bug and I'll mark it as affecting me
<robru> when you do eventually file it ;-)
<barry> robru: +1
<cyphermox> barry: does gedit not show menus either?
<barry> cyphermox: it does
<cyphermox> ah
<cyphermox> but not firefox and others
<cyphermox> I'm mixing things up, sorry, I see, only claws and emacs
<barry> cyphermox: well, ff and chrome work for me.  just claws and emacs broken (so far)
<TheMuso`> barry: Is emacs using GTK2?
<TheMuso`> Firefox works because it has a special plugin to work with the menus... But if emacs is GTK2, there is a chance that other GTK2 apps are broken as well, I assume claws is GTK2 also...
<barry> TheMuso`: i bet you're right that both claws and emacs are using tgk2
<barry> *gtk2
<barry> TheMuso`: hmm, maybe not: libgtk-3-0 (>= 3.2.1)
<barry> that's emacs24
<TheMuso`> Hrm ok.
<barry> claws-mail is though: libgtk2.0-0 (>= 2.24.0)
<TheMuso`> barry: Well I have just confirmed its not all GTK2 apps, I just tried one now and menus behave as normal.
<barry> TheMuso`: hmm.  okay
<infinity> barry: Asking the obvious question, have you logged out or rebooted since your last upgrade?  I've noticed that upgrades to the menu stuff seem to do weird things to active sessions sometimes.
<pitti> Good morning
<pitti> sarnold: bah, 'connecting to Launchpad failed: unclosed token: line 16399, column 6'; yay
<pitti> sarnold: I wonder why that started happening so often; it has worked for years without such cache problems..
<pitti> sarnold: thanks for pointing out, restarting
<pitti> RAOF: I think you actually want to use umockdev for the recording
<RAOF> pitti: Yeah, ish.
<pitti> RAOF: otherwise I'd have to add the whole ioctl decoding and evemu .desc parsing/ioctl synthesis
<RAOF> Right.
<pitti> RAOF: so with umockdev being able to record and read .events files it should be fine, right?
<RAOF> Yeah, mostly.
<pitti> RAOF: ah, what's missing?
<pitti> RAOF: ioctls should  be fine
<pitti> (on same endianess, anyway)
<RAOF> It just kinda irks me that if I change the order, or set of ioctls that I use, I need to re-record.
<RAOF> (Not that I've had to do that, just reading the code that's what I think happens)
<pitti> RAOF: no, umockdev's recorded ioctls don't need to be replayed in order
<RAOF> Ah, sweet. I guess I mis-skimmed the code.
<pitti> RAOF: in fact, evdev ioctls are all independent from each other, so you can call them in any order and any number you like
<RAOF> pitti: In which case I could probably just umockdev evemu-record, right?
<pitti> RAOF: .record must exactly match the original; .ioctl is a tree
<pitti> RAOF: well, yes; it's a bit redundant, though :)
<RAOF> pitti: Only if you've already implemented the ability to record .events as well as replay them :)
<pitti> RAOF: so, I'll clean up .events reading this morning and then look into .events writing; that should be fairly easy
<RAOF> Bitchn'
<pitti> reading is more work (that's why I started with that)
<RAOF> Ah, cool. Thanks muchly!
<pitti> RAOF: does that description make sense to you, or is it confusing somehow? http://paste.ubuntu.com/7112693/
<pitti> RAOF: refined: http://paste.ubuntu.com/7112707/
<pitti> zul: apparently the new python-taskflow is missing some new dependencies? (autopkgtest failure)
<pitti> cjwatson: pkgbinarymangler fixed; it was an actual regression, but a corner case (handling of files containing '%'); bash 4.3 apparently got a stricter escaping behaviour
<Noskcaj> mlankhorst, Would you mind fixing the libgphoto b-dep of wine1.6?
<dholbach> good morning
<mlankhorst>  morning
<RAOF> pitti: Description looks good. Is there any way we can shoe-horn a default-device into the evemu format? :)
<cjwatson> pitti: thanks
<pitti> RAOF: the documentation doesn't document it; but I'd expect "# comment" lines to work
<pitti> RAOF: (i. e. they work with umockdev, not sure if they work with evemu itself)
<RAOF> Yeah, they won't work with evemu, because it doesn't make sense - evemu creates a new uinput device to replay through.
<pitti> RAOF: I mean if evemu will ignore comment lines
<RAOF> Oh, right.
<RAOF> Eh.
 * RAOF is not particularly interested in that.
<pitti> RAOF: I just don't want to claim "it writes an evemu .events file" when that file can't be used with evemu
<pitti> RAOF: ah, seems it does
<pitti> i. e. '#' comments are fine
<RAOF> Sweet.
<Saviq> diwic, hey, question about the "what did you plug in" dialog: I have a combo jack (Dell Latitude E6420), but I never get the dialog, nor do I ever actually get mic input from the headset, is there something I could provide you with that needs to be added to some hw quirks or something to fix that?
<diwic> Saviq, sure, start with alsa-info: https://wiki.ubuntu.com/Audio/AlsaInfo
<Saviq> diwic, http://www.alsa-project.org/db/?f=449823acea2249ba25ab19e793c91858f4965769
<Saviq> diwic, want me to file a bug (against ?) with that?
<diwic> Saviq,
<diwic> Kernel release:    3.11.0-12-generic <- any reason you're not running a 3.13 kernel?
<Saviq> diwic, good question, no
<Saviq> hmm update-grub doesn't find the kernel...
<Saviq> ah, 'cause it's not there, must've dropped linux-generic at some point
<diwic> Saviq, and second, your machine is not one of the affected ones, at least not at this point...is it Certified/Enabled by Canonical?
<Saviq> diwic, yeah http://www.ubuntu.com/certification/desktop/models/?query=6420&category=Desktop&category=Laptop&level=Any&release=
<Saviq> diwic, they're not *exactly* like mine is - I've nVidia with Optimus
<mardy> cjwatson: hi! About https://code.launchpad.net/~cjwatson/libaccounts-glib/multiarch/+merge/211468, it's the first time I see Multi-Arch so my question might not make much sense:
<mardy> cjwatson: don't we need a similar line for the -dev package?
<diwic> Saviq, so it's a computer from 2010? Has the Mic worked in previous releases?
<Saviq> diwic, yeah, it's an old one, and I can't say that it ever worked
<Saviq> diwic, it's definitely only using the internal mic now
<Saviq> diwic, I can try  a live saucy if you'd like
<diwic> Saviq, when you submitted the alsa info, was a headset plugged into the jack?
<Saviq> diwic, no, let me
<Saviq> diwic, does it matter what do I plug in? i.e. headset vs. headphones?
<diwic> Saviq, yes
<diwic> Saviq, if I understand you correctly, plugging in headphones works as it should, whereas plugging in a headset you can't use the headset's mic?
<Saviq> diwic, yes
<Saviq> diwic, this is with a headset http://www.alsa-project.org/db/?f=b661fa1c8d2824b76db10b5cc4e20ebfab6b93aa
<diwic> Saviq, ok, so in your case it does not detect the headset mic, although the hardware claims it should be able to.
<cjwatson> mardy: it would be nice to get that far, but it isn't required.  I haven't worked out whether the files in the -dev package are multiarch-safe (any files in paths that are common between architectures must be bitwise-identical on all architectures)
<cjwatson> mardy: let me have a quick look at that if you want
<diwic> Saviq, at this point I think your best workaround is to use hdajackretask (in the alsa-tools-gui package) and remove jack detection for the headset mic pin
<diwic> Saviq, that probably won't give you a dialog (I think...), but should enable you to manually select mic in sound settings
<cjwatson> mardy: so, I *could*, but it would be futile; it depends on gir1.2-accounts-1.0, and /usr/lib/girepository-1.0/Accounts-1.0.typelib in that package has different contents on different architectures
<cjwatson> mardy: since this isn't required to make "click chroot" work, I'd rather leave that problem for another day
<cjwatson> (well, strictly, to make "apt-get install ubuntu-sdk-libs-dev:armhf" work)
<cjwatson> mardy: by the way, I see there's a new upstream in trunk - is that planned to land for trusty, or should I be looking at doing a direct upload of this to the archive based on what's in trusty now?
<Saviq> diwic, hmm indeed, got it to show up, but still no input (tried with an android/iOS â nokia adapter, too, just to check)
<mardy> cjwatson: thanks, I see there's little point in doing that
<cjwatson> mardy: https://wiki.debian.org/Multiarch if you want background on multiarch, maybe https://wiki.debian.org/Multiarch/Implementation in particular
<diwic> Saviq, ok, assuming you have increased the gain (it's quite low in your latest alsainfo) then maybe a hardware failure
<Saviq> diwic, yeah, I up'ed it to 100%, no go
<Saviq> diwic, so, I'll have to check if windoze let's me work with it, then, will do, thanks!
<Saviq> lets
<diwic> Saviq, ok!
<mardy> cjwatson: I'd like to land the new version in trusty, yes. So I think we'll take care of landing it.
<cjwatson> ok, great, thanks
<cjwatson> Laney: are you likely to be able to land https://code.launchpad.net/~cjwatson/ubuntu-system-settings/arch-any/+merge/211426 today?  it's blocking several things in -proposed
<Laney> cjwatson: Sure, I can do
<mardy> dbarth: hi! Can you make https://code.launchpad.net/~cjwatson/libaccounts-glib/multiarch/+merge/211468 land?
<Laney> seb128: ^ doing that on its own to unblock stuff, okay?
<seb128> Laney, no, please wait
<Laney> why?
<seb128> Laney, I've some trivial changes for the wizard I want to include
<Laney> could do another one ...
<Laney> but okay, you do it
<seb128> those can't bug anything, the wizard is not used
<seb128> ok, sure
<seb128> it just feels like we could batch them
<seb128> but go ahead if you want, I can do another one later
<seb128> cjwatson, just curious, how is u-s-s blocking things? it shouldn't have much rdepends
<seb128> oh, I guess it's the online account panel needed it, and that one has rdepends
<dbarth> mardy: hi
<cjwatson> seb128: {clickmanager-plugin, ubuntu-purchase-service} -> ubuntuone-credentials -> ubuntu-system-settings-online-accounts -> ubuntu-system-settings
<seb128> cjwatson, right, online-accounts, thanks ;-)
<cjwatson> I mean it's all stuff nothing needs yet but I still want to keep the list short
<seb128> right
<seb128> Laney, well, your call, feel free to land it now if needed, I can put another landing in a few hours for the one things on the backlog
<dbarth> mardy: will add to the silo
<mardy> dbarth: thanks!
<Laney> seb128: thanks, I will do so that proposed can clear out
<seb128> Laney, thanks
<dbarth> mardy: added line 13, along with the rest of the online accounts MPs
<Laney> well, they are in firefighting mode again so you never know ...
<dbarth> mardy: it's a no-op on desktop, but we will need to re-test on the phone with all of the recent changes
<cjwatson> Laney: they're being fairly good about letting through obvious packaging adjustments, so far anyway
<Laney> Yeah, but there's a new problem today in that the images don't boot, apparently. :P
 * Laney goes to ask anyway
<Laney> bah, I can't cross-build system-settings any more
<Laney> http://paste.ubuntu.com/7113317/
<seb128> qt5.2 regression?
<Laney> sec
<xnox> slangasek: bdmurray: updated app-install-data-ubuntu uploaded. But we also need updated "command-not-found" data, which is separate?! I'm not sure how that is generated.
<zul> pitti: ack
<Laney> ah I think it's the M-A: foreign on qt5-qmake
<Laney> it now installs stuff in triplet-namespaced locations
<Laney> http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtbase.git;a=commitdiff;h=dd85a4c4d6eb19a01e75959d4725f7298b63b852;hp=c5a1ab594b27738adec10d346def2bc71b23f58f
<cjwatson> Laney: yeah, I noticed the M-A: foreign seemed wonky given the paths
<Laney> It looks like it could be made M-A: same
<Laney> assuming the manpage compresses the same way, I guess
<Laney> Mirv: ^ wdyt?
<Mirv> Laney: looks like :same to me now that the mkspecs were moved
<Mirv> MR:s welcome, there's one new qtbase upload being prepared in CI Train already
<Laney> ok, if we check coinstallability explicitly
<Laney> Mirv: how does it work with the source package?
<Laney> do I add a changelog entry?
<Laney> I'd expected to see stuff merged into the packaging branch but there is nothing there
<Mirv> Laney: full changelog entry at all, propose against https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src and CI will run tests and merge after top-approving
<Mirv> s/at/and/
<Mirv> at the same time, it can be uploaded to a landing PPA via CI Train, but it's not possible right now since qtbase is already being released via CI Train (ETA 1-2 hours)
<Laney> ok
<Mirv> Laney: so, umm, maybe merge in lp:~timo-jyrinki/kubuntu-packaging/qtbase_sync_from_archives_and_add_harfbuzz_patches first since it's likely to go in, and prepare ubuntu10 upload
<Mirv> there was yet another upload by ricardo in the morning without CI involved
<Laney> Mirv: ok, there it is & requested your review
<Laney> let me know when it's up & built so that I can test it out
<Mirv> Laney: thanks, I will
<apachelogger> tseliot: bug 1291526  ... what I don't get, why would it run into an xioerror when prime selecting nvidia, but not when using intel?
<ubottu> bug 1291526 in kdebase-workspace (Ubuntu) "could not start ksmserver with nvidia-prime at next login" [Undecided,New] https://launchpad.net/bugs/1291526
<Mirv> Laney: bzr is choking on your changelog entry, the time stamp is mangled (missing '0')
<Laney> oops
<Laney> it probably got damaged in the merge
<Laney> there was a conflict of course
<Laney> Mirv: try that
<Mirv> works
<Laney> Riddell: I'm getting reject emails from this merge proposal I just made
<Laney> Can you maybe make them be discarded instead? Or better have a code review list where they are accepted
<Riddell> Laney: from kubuntu-devel?
<Laney> yes
<Laney> I guess because kubuntu-packagers had a requested review
<Riddell> Laney: unfortunately merge request have an implicit destination so I don't think there's a way to have mailman accept them automatically
<Laney> Riddell: AFAICS the best you could do would be to add a spam filter for it
<Laney> those can match any header
<Laney> For example you could match on X-Launchpad-Message-Rationale: Reviewer @kubuntu-packagers
<jamespage> I can't quite believe I've not had todo this before but what's the right way to move upstart configs between files at the same time as renaming them?
<barry> cyphermox: an update and reboot seemed to bring back the global menu for claws at least.  not for emacs (but a menu bar is kind of an anathema for that anyway :)
<cyphermox> barry: good :)
<Mirv> release team acked bug #1207812 so if anyone ready for an upload please sponsor the branch I prepared during my patch pilot turn
<ubottu> bug 1207812 in libimobiledevice (Ubuntu) "[FFe] Update libimobiledevice to support iOS 7, fix Trust Prompt Looping" [Medium,Confirmed] https://launchpad.net/bugs/1207812
<seb128> Mirv, I can do that
<Mirv> seb128: thanks.
<seb128> Mirv, yw, thanks for working on the update ;-)
<cjwatson> tjaalton: do you think you could sort out the libxmlrpc-c3-dev reverse-build-deps on http://people.canonical.com/~ubuntu-archive/nbs.html ?  I assume they need to be libxmlrpc-core-c3-dev now, but I don't really now
<cjwatson> *know
<cjwatson> tjaalton: (you can probably ignore tcos; it seems to have Build-Depends: libxmlrpc-c3-dev | libxmlrpc-core-c3-dev already)
<tjaalton> cjwatson: okay
<cjwatson> thanks
<tjaalton> seems I missed the old names
<tjaalton> although.. *cough* it failed to build on arm64/ppc64el
<cjwatson> what did?
<tjaalton> no wait
<cjwatson> https://launchpad.net/ubuntu/+source/xmlrpc-c/1.33.06-0ubuntu1 looks fine
<tjaalton> that got fixed by itself?
<tjaalton> oh good
<cjwatson> maybe it was transient
<tjaalton> yeah it was weird
<tjaalton> some test failed
<tedg> slangasek, url-dispatcher didn't officially get added to the touch FFE, do you think we can add it?  bug 1208989
<ubottu> bug 1208989 in Ubuntu "[FFe] standing freeze exception for Ubuntu Touch-specific packages" [Undecided,Confirmed] https://launchpad.net/bugs/1208989
<cjwatson> GunnarHj: mythes-sv is stuck in trusty-proposed because it builds uninstallable binaries on arm64 and ppc64el.  You'll probably end up with something similar in Debian.  Would it perhaps be worth an artificial build-dependency on libreoffice-dev (or something like that) so that you only build on the architectures that have libreoffice?
<cjwatson> GunnarHj: Or maybe the binary package should be Architecture: all (which would avoid this problem)?  It doesn't seem to do anything in its build phase
<Laney> cjwatson: Already fixed, see -2
<cjwatson> Laney: oh right
<pitti> cjwatson: right, I uploaded -2 to Debian, will sync once it gets imported
<cjwatson> ta
<Saviq> Mirv, xnox, bug #1294186, otherwise we'll never get it done...
<ubottu> bug 1294186 in qtbase-opensource-src (Ubuntu) "Cross-building broken in qt 5.2" [Undecided,New] https://launchpad.net/bugs/1294186
<Laney> Saviq: I have that fix building in a silo now
<Laney> well, potential fix
<Saviq> Laney, oh, great
<Laney> we'll see, it might need extra fixes for looking up too
<ritz> wtf, my precise boot up shows a debian logo on vm
<ritz> when did this happen
<heath> I'm wanting to write an app which utilizes the play/pause, prev, next, and volume buttons on my macbook. Tips on where to get started?
<ritz> heath,  configure the shortcuts keys
<ritz> why write an app ?
<ritz> assuming linux understands the keys
<Saviq> heath, they should be delivered to your app as XF86Audio* keys, see http://wiki.linuxquestions.org/wiki/XF86_keyboard_symbols
<heath> ritz: If there are multiple running apps which utilize the media keys, which one has preference?
<GunnarHj> cjwatson: Thanks for your head up re mythes-sv!
<Saviq> heath, so yeah, for Ubuntu it's rather different, you need to connect to the sound indicator which takes the keys
<cjwatson> Sorry it was a duplicate one
<Saviq> heath, http://askubuntu.com/questions/7342/how-do-i-integrate-an-application-in-the-sound-menu-using-python should get you started
<ritz> heath,  whichever you configure the shortcuts for
<ritz> or write a script to be called upon multimedia keys
<ritz> heath, http://askubuntu.com/questions/48393/how-to-make-the-keyboard-media-keys-to-work-with-vlc-globally
<heath> That's a neat link ritz
<heath> Saviq: I'll definitely be utilizing your link
<heath> Thanks
 * heath wonders if it's possible for a web app to connect to the sound indicator
<heath> Hrm, if youtube can be integrated, then yes
<hallyn> xnox: jodh: I went ahead and filed bug 1294200
<ubottu> bug 1294200 in lxc (Ubuntu) "test linked against nih-dbus-tool-generated libraryis not thread-safe" [Critical,New] https://launchpad.net/bugs/1294200
<Laney> Mirv: this is no good
<Laney> It wans to reference an armhf uic
<bdmurray> juliank: I've made uploaded another change to python-apt it seems slangasek and I missed a bit
<juliank> bdmurray: Thanks for letting me know. I also have some patches in upstream git, I'll do a 0.9.3.4 release soon.
<xnox> Laney: qmake doesn't know how to reference "built_arch" tools, cmake does.
<xnox> Laney: that's a known bug I haven't fixed yet.
<juliank> Bug fixes only of course (yes, I'm counting uncompressed data.tar support as a bug fix)
<Laney> xnox: It is using cmake
<juliank> bdmurray: It's a bit unfortunate to only have non-public errors.ubuntu.com resources in the changelog. I cannot seem them at all
<juliank> The bug fix seems strange
<xnox> Laney: oh.
<bdmurray> juliank: here is the traceback http://pastebin.ubuntu.com/7115343/
<Laney> xnox: Qt5WidgetsConfigExtras.cmake looks for host arch tools
<Laney> Dunno how to fix that
<juliank> bdmurray: I believe a better fix would be to change parse() to not generate bytes strings.
<juliank> in self.comment
<juliank> It looks like parse() was called with a bytes string (that is, not read using the SourcesList class). In such a case, we need to decode the line if it is not unicode already (once in __init__ and once in __parse__, to make sure)
<xnox> Laney: in cmake itself, i added a whole bunch of overrides for all the tools to look for correct arch tools, when building under environment like the one exported by dpkg-architecture -aarmhf-c
<xnox> Laney: maybe i need to fix/tweak those. Do you have an easy/simple reproducer for me to iterate with?
<bdmurray> juliank: okay
<Laney> xnox: landing-001 ppa, cross-build ubuntu-system-settings
<Laney> xnox: I'm guessing you want a similar override to those cmake ones in this file then
<juliank> bdmurray: This is still Python 2 code? It also crashes for me in another location in Python 3 with a simple test line in bytes.
<xnox> Laney: i'll look into it.
<xnox> Laney: probably not tonight though, need to finish on time today.
<Laney> nm
<juliank> bdmurray: Have you checked whether your fix actually work. I believe the problem is more that we now return a unicode object in __str__, causing it too fail afterwards because builtin str() tries to convert the unicode to str.
<juliank> There's not much we can do about that, except for adding __unicode__ and changing the other code to use __unicode__ instead.
<juliank> or using python 3 instead of 2.
<Laney> xnox: oh, I added some rules which make it work
<bdmurray> juliank: not that specific change no, I've had a hard time recreating this specific dist upgrade errors with sources list
<xnox> Laney: cool, i'll probably will snitch them to keep cmake just working for all packages.
<Laney> xnox: I added them to that MultiArchCross.cmake file
<Laney> lemme get a diff
<Laney> it just copies ones that are already there for some new tools
<Laney> or newly-moved, what evs
<juliank> bdmurray: I'm probably going to commit http://paste.debian.net/88436/ for this. It decodes byte strings to utf-8 and encodes the internal unicode to utf-8 if you call str() in Python 2 or bytes() in Python 3
<juliank> It even has a test case for both bytes and unicode.
<juliank> Not only that, it even contains a German word.
<bdmurray> juliank: okay, great.
<infinity> jodh: Any hope of my chroot-sessions bug being fixed pre-beta?
<infinity> jodh: It's amazingly noisy on machines that set up and tear down chroots constantly (*cough*buildds*cough*)
<Laney> xnox: bug #1294186 - please review the debdiff when you have time
<ubottu> bug 1294186 in qtbase-opensource-src (Ubuntu) "Cross-building broken in qt 5.2" [High,Triaged] https://launchpad.net/bugs/1294186
<juliank> bdmurray: Actually, instead of using unicode everywhere, even if not needed in python 2, how about simply opening the files in utf-8 in Python 3, and keeping the Python 2 code in bytes strings? I think this would work better, as that's the way we handle it everywhere else in the code.
<juliank> bdmurray: I now (locally) reverted the unicode patch and added http://paste.debian.net/88438/ instead; which only forces utf-8 in Python 3.
<juliank> It seems to work just fine in both Python 2 and 3 with the test case and has minimum impact.
<juliank> We would not have those problems if people did not write files in an UTF-8 environment and then run reading code in a non-UTF-8 environment like C instead of C.UTF-8
<juliank> apt_pkg.size_to_str() is broken in a non-unicode environment as well, BTW.
 * juliank is waiting for his CI to start & complete
<juliank> bdmurray: I have reverted the unicode change in upstream git for now. I'm not sure what I really want to do. Just hardcoding UTF-8 seems wrong. People might run in a non-UTF-8 locale, and things would break then. I have looked at the other code and we do not assume seem to assume UTF-8 for TagFile, but rather use the default encoding there as well (right, cjwatson?). I'd much prefer if code that sets a wrong locale like aptdaemon just gets f
<juliank> ixed instead.
<juliank> This way everyone can use the encoding they prefer.
<juliank> Python 3 uses the LANG environment variable to determine file encoding.
<bdmurray> juliank: it looks like the release upgrader sets the following - locale.setlocale(locale.LC_ALL, "")
<juliank> Which just is the default encoding. But someone must set it to a non-unicode encoding before running it, otherwise things would not break.
<juliank> locale.setlocale() seems to not influence the default encoding, BTW
<juliank> It will determine that during startup AFAICT
<juliank> It=Python 3
<lamont> why is it that after I unlock my screen, it generally re-locks the first time?
<UserError> lustre adds 10~ MB to kernel size
<infinity> lamont: Because reasons.
<infinity> lamont: There's already a bug (or three) filed about it.
<lamont> infinity: cool
<UserError> Why are there so many ARM platforms in the libsound2 package? It keeps growing with bloat.
<UserError> ALSA-know is that ain't right
<infinity> UserError: It's 204k of text files.
<UserError> the /usr/share/alsa/ucm/ dir is complete trash
<infinity> "complete trash".  Thanks for your input.
<UserError> for x86 platforms
<infinity> It's 204k of text files.
<UserError> it doesn't belong
<infinity> Also, it's 204k of text files.
<UserError> it has existed for years
<infinity> Your crusade, and the language used to fight it, aren't going to win you any friends.
<UserError> I know, it really bytes
<UserError> in 12.04 it was 120K. That is almost a +100% growth from LTS to LTS.
<infinity> It's tiny either way.
<UserError> also that means that writes are being used against NAND, SSD, and eMMC storage for 4k blocks
<UserError> Now, multiply that by the number of devices and SSD servers that exist
<infinity> You're making and argument for removing every package from the archive.
<infinity> Wouldn't want to write to those precious disks and harm them.
<UserError> and EC2 instances, Azure (copied from EC2) and OpenVZ appliance (proxmox too)
<UserError> I understand why certain things are there for supporting hardware. I do not understand files there for impossible reasons.
<infinity> None of those should have libasound2 installed in the first place.
<infinity> The simple answer to your question is because it's an arch:all package, and includes support for *drum roll* all arches.
<infinity> And, curiously, ARM seems to be the only arch that leverages UCM sanely, so it's the only one that ships a bunch of (tiny) UCM profiles.
<UserError> and yet the container profile for ubuntu minimal VM still has plenty of modules that shouldn't be there
<UserError> I agree there.
#ubuntu-devel 2014-03-19
<jrwren> UserError: libsound2 isn't part of cloudimg, so its not an issue for ec2, azure, openvz, openstack.
<sarnold> is there an easy way to download "newest" build logs for a source package for all supported releases?
<UserError> jrwren, i'm sorry I ruined your worldview then :(. It does indeed exist in many of those locations for sound processing support by default.
<UserError> as do many unneeded modules even in the minimal VM kernel versions
<UserError> https://coderwall.com/p/a56j3w -> https://gist.github.com/steakknife/6086608
<psusi> so I'm trying to debug using valgrind and I am being hit with what I can only call an idiocy of Xwindows... while displaying a pop up window, input is locked and you can't alt tab so I can't switch to the terminal running valgrind to tell it yes, I do want to attach gdb now that you noticed the error.. is there a workaround for that?
<psusi> ( other than switching to a tty and kill -9ing valgrind )
<RAOF> psusi: Welcome to the joy of X11 grabs. Run valgrind from a TTY.
<psusi> RAOF, can't you disable or break that stupid lock?  also I just noticed that menus in thunderbird don't seem to do this... I wonder why?
<psusi> constantly switching back to a tty to tell valgrind to continue a dozen times before it gets to the real problem does not seem appealing
<RAOF> Oh, yes. You can break the lock by enabling the XKB option which allows you to break locks.
<psusi> xkb?
<RAOF> http://who-t.blogspot.com.au/2012/01/xkb-breaking-grabs-cve-2012-0064.html
<ubottu> xkeyboard-config before 2.5 in X.Org before 7.6 enables certain XKB debugging functions by default, which allows physically proximate attackers to bypass an X screen lock via keyboard combinations that break the input grab. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0064)
<sarnold> how have I never heard of control+alt+numpad /*  ??
<RAOF> Because we disable it, because it kills your screen lock?
<sarnold> exactly, that would have been a pile of fun back at school
<psusi> lol
<psusi> I remember using that to insert ascii 255 characters into file names in high school
<psusi> in DOS it looked like a blank, so you could add it to the end of a file and not be able to tell it was there
<psusi> but then you couldn't touch the file or directory if you didn't add the character
<psusi> confused the hell out of the teacher when he couldn't see in the directory or delete the file
<psusi> then Windows 95 came out and things got even funnier... it would show an _ in place of the 255... and yet still puke when you tried to actually touch the file
<sarnold> haha
<psusi> I'm sure at one point we had no less than 25 copies of doom on the netware server protected using that little trick
<sarnold> awesome :)
<psusi> though that wasn't nearly as cool as when a class mate figured out how to use the dos debugger to disassemble login.exe and modify it to connect as a print server object instead of a user... print servers were supervisor equivalent and had no password ;)
<sarnold> heh, I never heard of that, either, that also would have been handy to know..
<psusi> RAOF, I don't suppose there's a way to make menus NOT grab in the first bloody place? ;)
<psusi> RAOF, bah... breaking the lock seems to kill the application
<hyperair> odd, why does indicator-application-service refuse to start up after i restart compiz?
<RAOF> psusi: No, you can't make menus not grab input; otherwise, they couldn't close when you clicked somewhere else.
<psusi> RAOF, why not?  they lose focus when you click elsewhere, and close.. the menus in thunderbird don't grab
<RAOF> psusi: Then I suspect the menus in thunderbird are hilariously broken under focus-follows-mouse?
<hyperair> oh wait they're back O_O
<psusi> wait... so this grab idiocy is all to avoid focus-follows-mouse closing the menu when you move the cursor outside the menu?
<RAOF> No, this grab idiocy is the only way guaranteed by the X11 protocol to work.
<psusi> for *what* to work?
<RAOF> For menus to be able to determine when someone has clicked outside them.
<RAOF> Yes, this sucks.
<psusi> I don't understand why you would care....
<RAOF> Because you want to close the menu when someone clicks outside it?
<psusi> so close it when you loose focus?
<RAOF> That's standard menu behaviour.
<RAOF> There is no guarantee that clicking somewhere else robs you of focus
<hyperair> does it not?
<psusi> how doesn't it?
<RAOF> It's entirely up to the window manager.
<hyperair> hmm i suppose it's not directly, yeah
<hyperair> psusi: kill compiz repeatedly until it doesn't come back, then try switching focus by clicking =p
<psusi> oy ve
<psusi> more X11 nicompoopedness
<RAOF> Which is why X11 toolkits use the only mechanism guaranteed by the X11 protocol to work :)
 * hyperair lols
<RAOF> Yeah, this sucks.
<psusi> so... what would be so wrong about not closing the menu if your wm is dead and you can't switch to another window?
<hyperair> RAOF: is there any window manager around that allows you to click on another window without switching focus?
<RAOF> hyperair: Almost certainly.
<hyperair> =\
<hyperair> so how does it switch focus then?
<hyperair> hotkey?
<RAOF> Oh, it'd probably switch focus in *some* situation; maybe you need to click on the titlebar or something.
<psusi> and X doesn't have a soft grab where you can capture clicks outside your window, but not bloody prevent switching windows?
<RAOF> psusi: Correct. âSoft grabsâ are âgive me a full-blooded grab when $CONDITIONâ.
<RAOF> For $CONDITION that doesn't include âan input event happens outside my window âºâ
<psusi> so.. what would be so bad about the menu not closing when you click outside the window and don't loose focus?
<RAOF> That's not how a menu is supposed to act?
<psusi> so?
<psusi> it's also not supposed ot disable alt-tab ;)
<RAOF> So toolkits want to provide a menu that provides certain behaviours.
<RAOF> Also note that your âlose focus => close menuâ breaks under raw X11, because the default behaviour is focus-follows-mouse.
<hyperair> derp
<psusi> I don't see a problem with the menu closing if you move the mouse to another window
<psusi> and have focus-follows-mouse on
<hyperair> psusi: what about those times you accidentally move your mouse out of the menu window?
<RAOF> Then you're perfectly welcome to write your own toolkit.
<RAOF> That doesn't have this behaviour.
<RAOF> GTK and Qt both want their menus to behave like menus :P
<psusi> how about I just patch gtk to not be stupid? ;)
<psusi> I'd like them to behave like menus too... which means not disabling alt-tab
<hyperair> eh well at least esc works
<psusi> hyperair, yea... unless the app is hung, for instance, by the debugger ;)
<hyperair> though you're kinda screwed if the application hangs while a menu is open
<hyperair> :)
<jrwren> UserError: lol. I promise, you did nothing to my world view.
 * psusi wonders when he will be able to swtich to wayland
<UserError> The day you install E19
<psusi> RAOF, there should at the very least be a setting to disable that behavior in the toolkit... if I wanted to add a patch to do that, what should I search for?  what is the api to grab?
<psusi> if only just for debugging ;)
<hyperair> psusi: just go look inside the GtkMenu widget code?
<psusi> hrm... good idea
<RAOF> psusi: You're looking for XGrabCursor, likely.
<psusi> export GTK_MENU_NO_GRAB=1
<hyperair> nah doesn't look like it
<hyperair> grepping shows no XGrabCursor
<hyperair> but i see a bunch of XGrabKeys
<hyperair> oh i see gdk_device_grab in gtkmenu.c
<TJ-> psusi: Would this act as the basis of a workaround, so you can start valgrind/gdb at the correct point? "while ! xprop -name 'New Tab - Mozilla Firefox' | grep -q _NET_WM_STATE_MODAL; do sleep 1; done; xdotool -window id-of-valgrind-window <key-strokes> "
<psusi> TJ-, I don't follow... I'm actually running gparted under valgrind and noticed some invalid memory references that sometimes are followed by an actual crash... I can kind of sort of reproduce it by right clicking up a menu at the right time
<psusi> funny though... I can't get it to crash when not running under valgrind
<TJ-> I was thinking if gparted has a 'modal' window keeping focus, and you need to send input when that appears to the valgrind window to fire up gdb, then a shell fragment like I showed in another terminal can watch for the modal window and when it sees it, can send the key-strokes needed directly to the valgrind/gdb terminal window (thus avoiding the modal focus lock)
<TJ-> Obviously, you can tweak the basic idea to trigger on your specific circumstances and windows
<infinity> Riddell: Looks like eigen2 was completely removed from Debian in favour of eigen3, but a few things in Ubuntu (almost entirely KDE) still {build-,}depend on it.  Any chance that'll be fixed?
<infinity> shadeslayer_: ^
<infinity> shadeslayer_: Looks like merging our kdeplasma-addons packaging with Debian (or, at least, pulling eigen3.patch) would sort that package, and probably get it building on ppc64el again (obviously also dropping the arch-restricted build-dep)
 * hyperair thinks a gdb session in byobu/screen/tmux would be much more helpful
<hyperair> that way you could just connect to it via ssh or from a tty
<tarpman> hyperair: ++, also gdbserver
<hyperair> oh okay, i didn't know about gdbserver
<lifeless> whats the best way to capture a full kernel oops when it happens during cloud-config ?
<hyperair> serial connection?
<hyperair> netconsole?
<lifeless> hyperair: good idea, I'll add a serial connection to the vm
<hyperair> :)
<lifeless> we were having lockups on that though
<lifeless> hopefully I can have cake and eat it
<sarnold> lockups on serial? o_O
<lifeless> yeah
<lifeless> 'fun' and didn't have time to debug...
<infinity> ScottK: Any comments on my eigen2/eigen3 observations above to Riddell and shadeslayer_?
<ScottK> infinity: About to go to bed and haven't read them yet.  I'll weigh in tomorrow.
<infinity> ScottK: Mmkay.
<Mirv> Laney: I may not understand the cross-compiling magickry you're trying, but it's possible you need to give qtchooser a specific configuration that understands where to get binaries + libraries
<Mirv> or binaries only if libraries are already fine
<pitti> Good morning
<sarnold> morning pitti, thanks for kicking the retracers yesterday :)
<pitti> hey sarnold; thanks for the poke
<pitti> sarnold: I adjusted apport to use a per-run temporary launchpadlib cache now, so this shouldn't happen again
<sarnold> pitti: oh, cool! :) thanks
<dholbach> good morning
<taihsiang> hi, I proposed the code merge for fix bug LP: #1284447,  may someone approve the merge and make the update available for users on precise?    https://code.launchpad.net/~taihsiangho/ubuntu/precise/pcmanx-gtk2/fix-for-1284447/+merge/211676
<ubottu> Launchpad bug 1284447 in pcmanx-gtk2 (Ubuntu Trusty) "middle click could not close the tab you selected by middle click" [Low,In progress] https://launchpad.net/bugs/1284447
<tjaalton> huh, trying to dist-upgrade a machine and I get
<tjaalton> The following packages have unmet dependencies: indicator-network : Depends: unity8 (>= 7.82) but it is not going to be installed
<tjaalton> claims some pkgs are held..
<pitti> tjaalton: you don't happen to have -proposed enabled?
<tjaalton> nope..
<tjaalton> hrm, jenkins output files don't have a proper mimetype so ffox offers to just save them
<tjaalton> shows them as BIN
<jamespage> xnox, around? we seem to be hitting issues with MongoDB on ppc64el due to the change in PAGESIZE
<jamespage> xnox, wondered if you could help me understand/fixup
<Riddell> infinity: will look into eigen today
<Laney> Mirv: likewise I don't understand qtchooser, but extending an existing section in cmake fixes it for me - https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1294186
<ubottu> Launchpad bug 1294186 in qtbase-opensource-src (Ubuntu) "Cross-building broken in qt 5.2" [High,Triaged]
<Laney> ;-)
<xnox> jamespage: i'd redirect you to apw =) ppc64el has large pagesizes than any other platform.
<xnox> jamespage: db5.3 now does it right, but it is a bit vodoo to me.
<xnox> *sigh* https://bugs.launchpad.net/launchpad/+bug/336439
<ubottu> Launchpad bug 336439 in Launchpad itself "No notification on conflicts in merge proposals" [Low,Triaged]
<mitya57> Mirv: Sorry, looks like I forgot to bzr add some patches when updating that branch.
<mitya57> I will now push a commit that adds them.
<Mirv> mitya57: you could just re-merge with the _510 branch too where I added those
<Mirv> either way, it's already uploaded to the https://launchpad.net/~ci-train-ppa-service/+archive/landing-017/+packages
<mitya57> Ah, I see, you already pushed that
<juliank> I just setup a bzr mirror of the python-apt git repository (debian/sid) branch at lp:~juliank/python-apt/debian-sid, maybe that's useful for someone. Note that it does not contain up-to-date mirror lists, those are created by running pre-build.sh
<dholbach> hey tkamppeter_ - how are you doing?
<dholbach> tkamppeter_, a friend in the office where I go asked me about https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/537970?comments=all - it seems like his company has a customer who would benefit from the bug being fixed - do you know what the state of things is there?
<ubottu> Launchpad bug 537970 in poppler (Ubuntu) "Evince does not print images in some pdf files." [High,Confirmed]
<miraiE> hi everyone, how can I make plasma widget Deb package? it's cmake based, and I don't know how to add cmake parameter in debian/rules file
<tkamppeter> dholbach, hi
<tkamppeter> dholbach, you go to an office? Do you have a second job?
<tkamppeter> dholbach, is Rouven Sacha (rouvensacha) your contact concerning this bug?
<mpt> Did the behavior of grep change between 13.10 and Trusty? I used to use âps aux | grep thunderâ to tell if Thunderbird is still running, but now that command just hangs
<mpt> And itâs not the ps part thatâs hanging
<jrwren> mpt: that is so crazy that it makes me think you got rooted and the kit replaced grep.
<mpt> âtouch ~/test && grep ~/test fooâ also hangs
<cjwatson> no changes at that level in grep
<sladen> strace grep?
<cjwatson> mpt: that second example is backwards.  you mean  grep foo ~/test
<mpt> Aha!
<cjwatson> but it shouldn't hang anyway, you should've got an error
<mpt> Yeah, âgrep foo ~/testâ exits immediately
<cjwatson> and that doesn't pertain to your first example
<cjwatson> what does 'type grep' say?
<mpt> grep is hashed (/bin/grep)
<cjwatson> ok, so no funny business with aliases
<cjwatson> I agree with sladen, the next thing I'd reach for would be ps aux | strace grep thunder
<mpt> open("/usr/share/locale-langpack/en/LC_MESSAGES/grep.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
<mpt> fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
<mpt> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0xbfdb2a28) = -1 ENOTTY (Inappropriate ioctl for device)
<mpt> read(0,
<xnox> mpt: what's 'type ps' as well?
<mpt> ps is hashed (/bin/ps)
<seb128> "(Inappropriate ioctl for device)"?
<seb128> mpt, do you use lxc? I wonder if you have an issue similar to the one Laney had recently
<seb128> random guessing
<xnox> seb128: mpt does use lxc a lot.
<mpt> Where âa lotâ = â1 hour per weekâ
<cjwatson> seb128: no, successful runs have that same thing
<cjwatson> that's just grep checking for the terminal size and finding it's not a terminal
<seb128> cjwatson, ok
<cjwatson> "read(0," means it's trying to read from stdin and getting no input
<cjwatson> so I think I dispute the assertion that ps is not hanging
<cjwatson> or at least would like to see further evidence there :)
<mpt> âps auxâ by itself completes in real 0m0.028s
<cjwatson> no input> more precisely, read on its standard input blocks, which means that the other end hasn't written anything (or not enough to fill a PIPE_BUF) and also hasn't closed its end
<cjwatson> maybe pastebin   strace -s1024 -f sh -c "ps aux | grep thunder"
<mpt> âps aux > ~/test && grep thunder ~/testâ also works fine
<cjwatson> so we can see the whole pipe setup
<cjwatson> possibly better bash -c there
<cjwatson> assuming you use bash as your interactive shell
<mpt> cjwatson, sorry, where would the âbash -câ go?
<mpt> at the start?
<cjwatson> strace -s1024 -f bash -c "ps aux | grep thunder"
<mpt> Thatâs more than my Terminal buffer
<mpt> ok, got it now
<mpt> cjwatson, http://paste.ubuntu.com/7119748/
 * cjwatson looks
<cjwatson> pipe([3, 4])                            = 0
<cjwatson> ...
<cjwatson> [pid 26509] close(4 <unfinished ...>
<cjwatson> [pid 26509] <... close resumed> )       = -1 EBADF (Bad file descriptor)
<cjwatson> wtf
<cjwatson> oh, no, it had already closed that one
<cjwatson> mpt: so that seems to work under strace ...
<cjwatson> and nothing seems out of order
<mpt> Meanwhile, it has been running in another terminal for 7 minutes now and hasnât exited
<dholbach> tkamppeter, yes, he is - it's a coworking space - I just call it "the office" :)
<shadeslayer_> infinity: at the very least I'd like KDE upstream to weigh in on eigen3 migration
<sladen> mpt: gdb -p pid_of_running_process    and then ctrl-c inside GDB (if needed)
<cjwatson> maybe find the pid of that running grep, ls -l /proc/THAT-PID/fd/0, and try to find that in other /proc/*/fd/
<soren> mpt: You could attach strace to the running grep. "strace -p <the pid of grep>"
<cjwatson> see what other process is holding the same pipe open
<tkamppeter> dholbach, so you do not work at home but rented a place in an office (the "coworking space")?
<dholbach> tkamppeter, sometimes like this and sometimes like that
<dholbach> :)
<ScottK> shadeslayer_: I'd suggest just checking to see if Debian's patch is merged upstream and if it, we go for it.
<mpt> soren, forgive me, the only way I know how to find the pid of a process is by running grep on ps in the first place
<shadeslayer_> ofcourse, if it's merged then it's alright
<mpt> Wait, thatâs not true, I can use Find in a text editor
<shadeslayer_> ScottK: infinity I also recall seeing some projects switching to eigen3 in 4.12.80, though I can't recall the name
<soren> mpt: LOL. Right, of course. My bad :)
<ScottK> shadeslayer_: If it's not merged, then ask the Debian people why they haven't upstreamed it.  We ought to get it in 4.13.
<tkamppeter> dholbach, the bug seems to be fixed in the current version of Ubuntu. Is your co-worker sticking to an older LTS?
<shadeslayer_> *nod*
<shadeslayer_> ScottK: I'll have a look at it
<dholbach> tkamppeter, precise is the current LTS
<ScottK> infinity: ^^^ my opinion
<mpt> Process 26532 attached
<mpt> read(0,
<mpt> soren, ^ well, that was unexciting
<tkamppeter> dholbach, the problem seems to be Poppler when I look at the bug report but it is not very clear herewhich change on Poppler fixed it.
<soren> mpt: Does this happen only with ps as the input?
<mpt> cjwatson, âlr-x------ 1 mpt mpt 64 Mar 19 13:29 /proc/26532/fd/0 -> pipe:[9579047]â â¦ And I donât understand the second part of your suggestion, sorry
<soren> mpt: ls -l /proc/*/fd/* | grep 9579047
<dholbach> tkamppeter, ok - so it still needs further investigation, I guess?
<mpt> soren, <mpt> âps aux > ~/test && grep thunder ~/testâ also works fine
<soren> mpt: Hm... There I go, using grep again.
<cjwatson> I would redirect it to a file anyway, because you're going to want to track down the owning process
<cjwatson> so  ls -l /proc/*/fd/* >all-fds 2>/dev/null; less all-fds  and then look for 9579047
<soren> cjwatson: ls -l /proc/*fd/* will show the full path names, so the owning process hsould be readily available.
<mpt> soren, âls -l /proc/*/fd/* | grep 9579047â has not exited after a minute (I assume itâs quicker than that)
<soren> It should be nearly instantaneuos.
<miraiE> I've found this https://wiki.ubuntu.com/Packaging/Training/Logs/2009-06-18 and it's what I want to do, but I can't find the debian/* example files
<soren> (It's all memory operations)
<cjwatson> mpt: redirect to a file to avoid running into whatever the same issue is
<soren> mpt: So yeah, what cjwatson said. Pipe it to a file, and use lss.
<cjwatson> this is sounding like a broken shell to me, but it's hard to tell ...
<mpt> cjwatson, ok, there are three lines with that
<cjwatson> you'd get this if the shell failed to close its ends of the pipe it's constructed
<mpt> cjwatson, http://paste.ubuntu.com/7119825/
<cjwatson> mpt: ps -p 26530 -o pid,args
<mpt>   PID COMMAND
<mpt> 26530 bash
<cjwatson> ok, so as I thought
<cjwatson> not that this gets us to a solution, since I'm running current bash in trusty and am not seeing this
<soren> mpt: Do you have another user on this system?
<mpt> soren, no
<soren> mpt: How about the guest account?
<mpt> soren, it exists but nobody is logged in to it
<soren> mpt: Can you see if it happens if you log in to it?
<mpt> (according to indicator-session, at least, and indicator-session never ever lies)
<mpt> ok
<mlankhorst> can someone remove mesa from proposed? didn't mean to get uploaded to archive
<Laney> seb128: ^?
<seb128> Laney, mlankhorst: is that a "need more testing but might be ok" thing, e.g proposed block would be enough?
<mlankhorst> no
<seb128> ok, deleting it then
<mlankhorst> it's something that should have gone to a ppa so I could run some piglit tests
<mpt> soren, it works fine in the guest session.
<mlankhorst> does ubuntu auto reject versions with ~ppa in the name?
<mpt> Meanwhile, I can no longer move my mouse pointer in *this* session.
<seb128> Laney, mlankhorst: done
<mlankhorst> ty
<soren> mpt: Interesting.
<miraiE> I've done:   dpkg-depcheck cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4
<miraiE> and it printed several depend package
 * mpt tries to log out and crashes unity-panel-service
<mpt> Stop this operating system I want to get off
<miraiE> please, how to convert those command in debian/rules ?
<mitya57> miraiE: List those packages in Build-Depends field of debian/control
<miraiE> mitya57: okay, I'll try
<mpt> cjwatson, so should I report a bug on bash?
<cjwatson> mpt: that's my best guess
<tkamppeter> dholbach, I have asked the person for more info on the bug.
<mpt> cjwatson, ok, reported bug 1294678, thanks for all the instructions
<ubottu> bug 1294678 in bash (Ubuntu) "grep waits forever for piped input" [Undecided,New] https://launchpad.net/bugs/1294678
<Riddell> infinity: looks like debian has a load of patches to port kde bits to eigen 3 only some of which have been sent upstream and they're still under discussion for issues in the patches.  is there a reason you want to switch or just don't like having two versions of same library?
<mpt> (and thanks soren and sladen too)
<apw> jamespage, oh goody
<ogra_> pitti, would there be a chance to get rid of the xvfb dep in ofono-phonesim-autostart ? it cause quite some havoc in the touch tests (since the initial test setup installs it, so there is always an xserver running)
<ogra_> (we are just discussiong it in #ubuntu-ci-eng)
<pitti> ogra_: ofono-phonesim is a graphical program, so it needs some X server
<pitti> ogra_: it's Qt, so presumably at some day it could also use some "framebuffer Mir", but we don't have that yet AFAIK?
<ogra_> on touch ?
<ogra_> afaik we only use the sim emulation of it
<pitti> and it uses Qt 4 still :/
<pitti> ogra_: yes, it's just one program
<ogra_> and use the dialer and messaging apps as frontends
<pitti> ogra_: how does it interfere, OOI? It's running as a separate user on a private D-BUS with a private Xvfb, I thought it was shielded quite well
<ogra_> pitti, well, the constantly running xvfb kind of causes issues ... i would like that ofono-phonesim-autostart only gets installed for the two tests that actually use it, but apparently the current setup doesnt offer this ... so xvfb is contantly running
<ogra_> *constantly
<pitti> ogra_: right; the whole -autostart packaging trick is because tests run as user and don't have root, so they can't set up phonesim by themselves
<ogra_> there are apps and tests that are running on desktop too ... so the running xserver can confuse them
<doko> tvoss, https://launchpad.net/ubuntu/+source/dbus-cpp/1.0.0+14.04.20140123.1-0ubuntu1  if this has to be GCC specific, please make it conditional on ppc64el, not having 4.7
<pitti> so back then, when we discussed that between fginther, awe, and me, we found that having the test depend on such an o-f-a package would be the best solution
<ogra_> (which then results in false negatives for failures)
<doko> tvoss, and what was the reason to fall back to 4.7?
<tvoss> doko, the platform-api is stuck with gcc 4.7 for the moment
<ogra_> pitti, right, but currently it isnt the app test that depends on it but the whole test run
<pitti> ogra_: confuse how? it's a separate $DISPLAY, dbus, and everything; phonesim is only feeding ofonod, the "real" UI doesn't even know of its existance
<pitti> ogra_: ah, we install all tests and their dependencies at the same time, and then run all tests?
<pitti> ogra_: (for image testing, not for MPs)
<doko> tvoss, which ppc64el doesn't have
<ogra_> pitti, well, today we had the security test fall over because there is an active socket in /tmp/.X11-unix/ for example ... we had other issues before
<tvoss> doko, yup. So what do you want me to do exactly?
<pitti> ogra_: so how does it confuse other tests? just because of the socket, or does it eat inordinate amounts of CPU/RAM/etc?
<ogra_> pitti, we run phablet-click-setup ... which installs all needed extra bits for click tests
<ogra_> phonesim is among them
<ogra_> while the fix is indeed to only have it for the tests that need it
<doko> tvoss: build depends: g++-4.7 [!ppc64el], and change the rules file to use gcc/g++ on ppc64el
<ogra_> i was wondering if there isnt a way to also decouple it from X completely
<pitti> ogra_: I know how to make the socket invisible (we could run phonesim in an unshared namespace), if it's only that
<ogra_> (which is why i pinged you)
<tvoss> doko, ack, on my list
<pitti> ogra_: right, so we'd need to re-set the device for each test, which sounds expensive
<doko> tvoss, thanks
<pitti> ogra_: do you think if we hide it "more" that would be ok? then we coudl still install and run all tests at once
<ogra_> yeah, the tests already take 5h ... adding more reboots will only add to that
<xnox> bfiller: hello, are you around?
<ogra_> well, it doesnt feel right to have an xseerver run on the phone at all ... but yeah, hiding might already be an improvemment
<bfiller> xnox: yes
<dholbach> thanks tkamppeter
<xnox> bfiller: can we make a gallery-app branch merge / release into the archive and click?
<xnox> bfiller: i'm more interested in the click into the click store with this merge proposal https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877
<bfiller> xnox: we're working on that, see line 15 of CI Train sheet
<bfiller> xnox: I can include that MR in the silo so it gets released with the rest
<xnox> bfiller: is that for click, or in the archive upload, or both?
<pitti> ogra_: well, yes, but that's an intrinsic requirement of ofono-phonesim ATM
<ogra_> right, i understand
<bfiller> xnox: would be for both, sergiusens or someone I think has to manually do the click release after the deb gets released
<pitti> ogra_: of course that could in theory be changed to not show an UI and only be a D-BUS service, but it's not doing that ATM
 * jdstrand notes that this is not needed for the security tests to pass
<jdstrand> I'm making them less brittle
<ogra_> pitti, would be nice if you could put that on your TODO for later :)
<sergiusens> bfiller, yeah; is that done?
<bfiller> sergiusens: no
<sergiusens> bfiller, as in, did it get to trunk?
<xnox> bfiller: i see. Yes, please include that merge proposal in the landing (  https://code.launchpad.net/~barry/gallery-app/xnox-pkgresources/+merge/210877  )
<bfiller> sergiusens: we found issues
<bfiller> xnox: I'll include that in the silo then
<barry> xnox, bfiller \o/
<xnox> bfiller: it's no-code change, only autopilot testing code fix-up.
<ogra_> pitti, i'll nag CI to only have it installed for phone related tests anyway, so on low prio for you :)
<bfiller> xnox: ack
<pitti> ogra_: hiding the socket, yes; rewriting phonesim, not that much :) (in fact, much of its functionality actually depends on Qt, like sending SMS messages)
<bfiller> should be fine
<ogra_> ok
<pitti> ogra_: bug report appreciated for hiding the socket, with some details
<barry> xnox: although i'm not fond of the auto-pruning of empty files (e.g. __init__.py)
<xnox> bfiller: sergiusens, barry and myself pretty-much give you 24/7 coverage to respond to any queries as we all can't wait for it to land =)))))
<bfiller> xnox, barry : just make sure that merges cleanly with https://code.launchpad.net/~artmello/gallery-app/gallery-app-multiple-bug-fixes/+merge/211154
<xnox> bfiller: let me confirm / check that.
<xnox> bfiller: "All changes applied successfully."
<bfiller> xnox: cool, I'll add it to the silo
<dobey> xnox: hi
<dobey> xnox: for "dpkg-architecture -aarmhf cmake ../ && make" to work, i need to enable armhf as an arch on my machine, and then install the :armhf versions of all the build-deps?
<xnox> dobey: almost, but that will most likely break a few things on your desktop. It's best to use a schroot. E.g. click chroot create / click chroot run, or mk-sbuild --target
<xnox> dobey: for simply things (which don't use gl*/qt*) doing it on your desktop is safe as well.
<xnox> dobey: are you already using mk-sbuild / sbuild, and what are the projects that you want to cross-compile?
<dobey> xnox: i want to compile lp:unity-scope-click. i'm not using sbuild already, no (though i do have it insatlled)
<xnox> dobey: test-building here, will let you know in a moment.
<dobey> xnox: ok, thanks!
<xnox> dobey: unfortunately automatic installation of cross-dependencies fails, as a few *accounts* *oauth* etc things are not Multi-Arch:same.
<xnox> dobey: let me see if we can fix this.
<dobey> ah, ok
<xnox> cjwatson: have you already been "multiarchifying" accounts/oauth/signon things?!
<dobey> i'll try sbuild i guess
<cjwatson> xnox: some
<cjwatson> xnox: I'm specifically working on making ubuntu-sdk-libs-dev:armhf installable on !armhf
<xnox> dobey: well, yeah native compilation should work $ mk-sbuild --arch armhf; sbuild --arch *.dsc; will use qemu-user-static and will slowly natively compile. But i'll see if i can fix cross-compilation for that.
<cjwatson> xnox: probably overlaps slightly with you but not much.  The things I have in other people's landing queue are dee and libaccounts-glib
<xnox> cjwatson: ack. thanks. I'll see which bits i can propose for landing.
<dobey> xnox: eh, seems like sbuild will be the fastest option, and i need to do the building /now/, so i'll go with that
<dobey> hopefully it doesn't break for some silly reason due to config differences between local sbuild, and what the launchpad builders are doing
<infinity> Riddell: It's not even a shared library, it's a static (in 2) headers-only (in 3) set of stubs, so I'm not super concerned, I just ran into the "it's not even in Debian" thing when I was hunting why it was broken on ppc64el.
<infinity> Riddell: Fixing it on ppc64el should be trivial, I didn't bother going that route while waiting on KDE/eigen options.
<Riddell> infinity: yep, I'll try and send that patch upstream today
<dobey> xnox: ugh. "mk-sbuild --target armhf trusty" failed pretty horribly :(
<dobey> xnox: http://pastebin.ubuntu.com/7120328/
<xnox> dobey: --skip-proposed should help cross-chroots. "--target" creates a "cross-compilation chroot". For qemu-user-static, you want "mk-sbuild --arch=armhf trusty"
<xnox> dobey: not sure why it's using "archive.ubuntu.com" for you, as armhf is on "ports.ubuntu.com (us.ports.ubuntu.com).
<xnox> dobey: did you customize it somehow?
<dobey> xnox: no, i just copied the command from your e-mail, which is mk-sbuild --target armhf trusty
<xnox> dobey: oh, maybe it does do ports, just earlier / no included in the pastebin.
<xnox> dobey: but, cross-compilation chroot will not work against unity-scope-click at the moment =)
<dobey> xnox: no, i don't see ports in the output
<dobey> oh
<xnox> dobey: right, let me strip my chroots and try from scratch locally here.
<dobey> i'll try --arch then
<ScottK> Nice thing about doing a lucid backport is at least there's not wait for sparc and ia64 builders ....
<dobey> xnox: hrmm, with --arch it is trying to use archive instead of ports, too :(
<dobey> xnox: so i'm getting pretty much the exact same failure
<xnox> dobey: $ mk-sbuild --arch armhf --name foobar trusty
<xnox> /usr/sbin/qemu-debootstrap
<xnox> [sudo] password for xnox:
<xnox> ion: Running command: debootstrap --arch armhf --foreign --variant=buildd --components=main,restricted,universe,multiverse --include=eatmydata trusty /var/lib/schroot/chroots/foobar-armhf http://ports.ubuntu.com/ubuntu-ports
<xnox> ion: Retrieving Release
<xnox> dobey: note how it calls ports like on of the first things...
<xnox> dobey: what's your host-OS?
<infinity> ScottK: Hah, yeah.  You, the kernel team, and the security team.  Pretty much everyone else has given up on lucid SRUs.
 * xnox is not sure if for-example qemu-debootstrap / debootstrap / sbuild / mk-sbuild can be affected by user/system configuration files.
<xnox> dobey: do you have ~/.mk-sbuild* files?
<dobey> i do
<pitti> ~/.mk-sbuild.rc exists and is useful, so that can impact mk-sbuild indeed
<ogra_> qemu-desbootstrap is just a wrapper around debootstrap ... doesnt know any configs
<ScottK> infinity: Keeping the clamav backports going isn't very hard.  Only minor package mods needed.  Nothing compared to what I had to do to keep dapper and hardy in the mix by this point.
<xnox> dobey: well, check their content. and probably remove any archive definitions, as correct archies are picked by default anyway.
<dobey> ok
<infinity> ScottK: Yeah.  When lucid goes away, it should be even more pleasant, thanks to trusty and precise being quite similar on the packaging toolchain front.
<infinity> xnox: Erk, did we not fix mk-sbuild to name those chroots properly?
<infinity> xnox: We should.
<infinity> xnox: (That example above should be /var/lib/schroot/chroots/foobar-amd64-armhf, if it's a cross-chroot)
<doko> Mirv, I see that qtjsbackend-opensource-src is removed in Debian. should that be removed for trusty as well?
<xnox> infinity: above is correct. "--arch" is "qemu-powered-native", not "amd64-armhf" cross.
<xnox> doko: removal request was filed, and infinity removed it from "release pocket" but there is another on in -proposed pocket.
<infinity> xnox: Oh, that's a native chroot?
<xnox> infinity: can you zap qtjsbackend from -proposed? unless you already have.
<xnox> infinity: --arch armhf is native, yes.
<cjwatson> I think we fixed the naming ...
<infinity> xnox: I didn't catch the whole backscroll, I thought it was a cross chroot.  Nevermind. :P
<xnox> infinity: (well it's qemu-debootstrapped, so there is qemu-user-static binary in the chroot, updated on each entry into it, I think.....)
<cjwatson>     CHROOT_NAME="${name}-${CHROOT_ARCH}-${TARGET_ARCH}"
<cjwatson> yeah
<infinity> xnox: Nuked.  Didn't notice the spare copy in proposed.
<happyaron> bdmurray: hi, I know that, and as explained it's something required by a cooperation project. so I'd appreciate it can be accepted.
<jamespage> apw, care to educate me?
<xnox> infinity: cool =)
<apw> jamespae, coul dyou point me at the issue you are having, so i can see if it is similar
<rbasak> stgraber: have you seen bug 1072518?
<ubottu> bug 1072518 in dbus (Ubuntu) "Restart networking crashes dbus and the desktop manager" [High,Confirmed] https://launchpad.net/bugs/1072518
<rbasak> stgraber: 120 users are complaining that "sudo restart networking" kills dbus
<mlankhorst> oh
<mlankhorst> hm that could explain things
<mlankhorst> I had a bug in xorg-server about something like that with 'no screens found'
<xnox> rbasak: my cunning plan is to turn networking into a task job, thus during normal operation it's stopped and thus "stop networking" and "restart networking" does nothing =)
<rbasak> xnox: where were you at the UDS session we had on this last week? :)
<xnox> rbasak: oh, i was in another session. Maybe i should rewatch it.
<stgraber> rbasak: yeah, that boils down to dbus shutting down after networking which is entirely reasonable, except that our whole system depends on dbus
<stgraber> xnox: except that we actually need networking to be brought down on shutdown
<rbasak> stgraber: do we need to explain in the bug and mark it Won't Fix?
<stgraber> xnox: I think we already discussed this :)
<infinity> I wish I knew where people got the idea that "restart networking" (and /etc/init.d/networking resart before that) was a good idea.
<stgraber> rbasak: yes, I think we should. I believe I "won't fixed" a similar bug against ifupdown a while back
<infinity> But we really shouldn't give people such a massive shotgun to apply to their feet either.
<xnox> stgraber: i thought splitting it into two tasks should be reasonable: networking -> start on (current start on) and do setup; networking-shutdown -> start on (current stop on condition, do the tear down, emit deconfiguring networking et.al.)
<rbasak> stgraber: do you mind doing it with an appropriate comment, please?
<stgraber> xnox: that'd probably work, though I'm reasonably sure people will then try and call networking-shutdown + networking...
<rbasak> Or maybe duplicate to the other bug?
<infinity> stgraber: Why does networking need to be shutdown at all?
<xnox> rbasak: stgraber: won't fixed bugs disappear from search results. The current bug is edit by me to shout and tell to "DO NOT DO THAT"
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1235516
<ubottu> Launchpad bug 1235516 in xorg-server (Ubuntu) "service networking restart causes Xorg crash" [Undecided,Confirmed]
<infinity> stgraber: Are we trying to be polite and release DHCP leases, or is there some more useful reason?
<xnox> rbasak: stgraber: and it "affects" all the right packages people search about this issue.
<rbasak> xnox: fair enough, but keeping it open also tells people to expect it to be fixed, including "why isn't it fixed yet?" type comments both on the bug and elsewhere.
<rbasak> xnox: "Won't Fix" is the point of a status that tells them otherwise.
<rbasak> IMHO, if that means that it doesn't appear in search results and so people don't mark Won't Fix when they should, then that's a symptom that the default search result is wrong.
<xnox> stgraber: rbasak: in networking.conf we can do "wall System shutdown initiating in 30s; sleep 30" that should be enough time for people to hit ctrl-c on "restart networking" prompt.
<rbasak> xnox: won't that delay system shutdown?
<stgraber> infinity: right, we need dhclient to shut down properly, we then want to get dbus to die and after that all network partitions are unmounted so that hopefully we can remount the world r/o at the end and not suffer dataloss
<xnox> rbasak: stgraber: or actually, we can bail restarting networking, in pre-stop. Check for events -> if we are going for shutdown, continue. Otherwise bail stopping networking job, and send a Wall explaining what's going on.
<infinity> stgraber: umounting network fielsystems shouldn't have anything to do with "networking shutdown".
<xnox> rbasak: stgraber: thus it should be interractive-friendly, not delay shutdown, nor change any job/event semantics.
<infinity> Having it only run if you're in a shutdown sequence seems sane, if that's reliably doable.
<stgraber> xnox: how would you check for the shutdown event?
 * infinity misses runlevels. :P
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1277553 fun fun
<ubottu> Launchpad bug 1277985 in xorg-server (Ubuntu) "duplicate for #1277553 Xorg crashed with SIGABRT in OsAbort(no screens found)" [Medium,Incomplete]
<xnox> stgraber: check the UPSTART_EVENT variable set by upstart with reason why "stop on" got triggered. If it's unmounted-remote-filesystems -> we are shutting down.
<xnox> stgraber: if it's empty, then we got interractively triggered.
<xnox> stgraber: and i can send wall message about it.
<infinity> Why message at all if it's interactive?
<infinity> Just do nothing.
<xnox> (e.g. DO NOT STOP or RESTART NETWORKING) using webdings pictograms to be language neutral =)
<xnox> infinity: hm, true.
<infinity> "Your system will self destruct in 30 seconds" isn't a helpful upstart job.
<stgraber> xnox: so add a pre-stop which does [ -z "$UPSTART_EVENT" ] && echo "Someone tried restarting the networking job, this isn't supported." && exit 1
<stgraber> then when they file a bug I can look at the attached networking.log and automatically mark the bug won't fix if I see that string? :)
<xnox> stgraber: right, and that string will only end up in /var/log/upstart/networking.log which is fine.
<xnox> stgraber: haha about checking the string =)
<rbasak> I think you can have Launchpad do that automatically for you :)
<rbasak> (eg. suggest it as a dupe of this bug)
<jodh> stgraber: make that $UPSTART_STOP_EVENTS
<stgraber> jodh: thanks
<xnox> jodh: hmmmm..... is pre-stop at all executed for jobs without main process?
<stgraber> ok, so added the pre-stop to my todo, will look into this soonish. I'm sure people will still complain even with this but at least they won't trash their systems.
<cjwatson> infinity: On the contrary, if my system *is* going to self-destruct in 30 seconds, I totally want an upstart job to tell me :-)
<xnox> stgraber: jodh: pre-stop doesn't seem to be executed for a job without a main process =(
<xnox> stgraber: jodh: when stopping the job interractively with "stop myjob"
<stgraber> and I don't suppose there's a way to prevent the job from switching to stopped state from post-stop (that'd be quite wrong I think...)
<xnox> stgraber: well, we could start the job again and bail / not-do ifdown.
<xnox> jodh: stgraber: i think it's a bug that pre-stop is not executed if there is no main process.
<jodh> xnox: yes, it does appear to be.
<xnox> jodh: i guess the logic is /before/ the main process is killed/terminated. But when one doesn't have exec/script stanza, there will _not_ be a main process. It's a virtual job.
<jodh> xnox: right, init(5) doesn't make the behaviour clear but maybe not a bug after all. Certainly needs better doc though.
<rbasak> Is there any reason for the behaviour to be different, though?
<rbasak> It seems that it would be more useful if pre-stop did work in this case. Would that cause any issues anywhere else?
<jamespage> apw, https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1294747
<ubottu> Launchpad bug 1294747 in mongodb (Ubuntu) "mongodb on ppc64el with 64k pagesize" [Undecided,New]
<stgraber> yeah, if we could get pre-stop to work, that'd be quite useful here, I don't like the whole calling start from post-stop thing, that's a massive hack :)
<xnox> rbasak: actually you are right, there is no combination where there would be side-effects.
<stgraber> pre-start and post-start get executed fine, so it'd make sense to me to also have pre-stop and post-stop, not just post-stop
<xnox> stgraber: yeah, plus calling start from post-stop does quite work one gets:
<xnox> $ sudo stop foo333
<xnox> stop: Job failed while stopping
<xnox> stgraber: and in the log it says job is already running.
<jodh> xnox/stgraber: can one of you raise a bug on this please?
<xnox> jodh: yeah, i will.
<xnox> jodh: hm, i can't seem to make pre-stop to bail stopping. With or without main process. I get "stopped/failed" event emitted, yet main process is killed and end result is "stop/waiting"
<xnox> jodh: filing full bug report.
<xnox> jodh: https://bugs.launchpad.net/upstart/+bug/1294753
<ubottu> Launchpad bug 1294753 in upstart "pre-stop exec false => should prevent the job getting stopped" [Undecided,New]
<xnox> stgraber: with current upstart, splitting networking.conf into two "task jobs" with shutdown one bailing out in "pre-start" is the only way that actually works. It seems that /everything/ can be stopped.
<xnox> stgraber: ah, I have something that does work =)
<stgraber> xnox: if it's not too much work, I think we should just get the pre-stop stuff in upstart and use it. networking.conf is a major pain to change because of migration code (checksums and other similar fun) so splitting it would make things even worse...
<xnox> stgraber: so i have something simple, which works, but has a stray / bogus event>
<xnox> start on stopped/failed networking
<xnox> pre-stop exec false
<xnox> that results in: stop networking => to print networking start/running
<xnox> stgraber: "stopped networking" event is emitted. but at the moment nothing is sensitive to "stopped networking" i think.
<xnox> stgraber: since "deconfiguring-networking" event is actually used. I'm not sure what happens on the other side of the startpar bridge (sysv-init)
<xnox> stgraber: but imho, this would be improvement over "my machine got destructed"
<xnox> sorry "post-stop exec false"
<rbasak> barry: any plans to fix python3-genshi in Trusty? Looks like there's a fix in Debian now?
<rbasak> jodh: well, we want to make "networking" unstoppable, right? And any real service could have respawn disabled and then killed.
<xnox> $ sudo stop test2
<xnox> stop: Job failed while stopping
<xnox> excellent!
<xnox> $ sudo cat /var/log/upstart/test2.log
<xnox> Stopping or Restarting networking job is not supported. Use ifdown & ifup to reconfigure desired interface.
<barry> rbasak: yes, i uploaded the new genshi to debian.  i just need to sync it over
<rbasak> barry: thanks! I'll leave you to it I guess.
<rbasak> Do you want a bug?
<barry> rbasak: nope, jfdi'd it :)
<rbasak> barry: thanks!
<barry> rbasak: np!
<xnox> stgraber: https://launchpadlibrarian.net/170043449/lp1072518.patch i've attached it to the bug report. No idea if i need to adjust anything else when touching that conffile.
<apw> jamespage, ok that assertion implies it is a different issue but related.  essentially that assertion is catching the case that the db5.3 was performing and getting broken by
<apw> jamespage, if i am reading it right basically it is asaying am i rounding to the OS page size at least, and the answer is no, so it blows up
<stgraber> xnox: hmm, so the problem with that is that if I define a new interface in /etc/network/interfaces and then do "stop networking", it'll be brought up :)
<stgraber> I think the real fix there is to first make upstart allow the pre-stop and then use that
<UserError> The amount of purely ARM cruft has been calculated /  EST
<UserError> it is now officially greater than VDPAU would take as a diff
<xnox> stgraber: really? which job/event will configure it?
<xnox> stgraber: all existing things would be in the state running already, and i don't see how any new ones would be started.
<stgraber> xnox: networking
<xnox> stgraber: oh, i see!
<xnox> stgraber: i should then guard pre-start script agains the same event.
<stgraber> yeah, not hackish at all ;)
<xnox> stgraber: so if we are started by "stopped networking RESULT=failed PROCESS=post-stop EXIT_STATUS=100" we'd not do "ifup -a" =))))
<xnox> stgraber: it is standalone, minimal, and SRUable =)
<xnox> stgraber: and doesn't depend on which upstart one is running ;-)
<jamespage> apw, thanks for looking
<xnox> stgraber: i don't want to introduce unstoppable jobs though. Cause i do think that "stop foo" should be resulting in stopping the main process, regardless of anything, eventually.
<apw> jamespage, i would assume what has occured is it has rounded to the filesystem block size, 4K or something and checked it is rounded to the memory one
<apw> which in the normal case is the same
<xnox> stgraber: actually i'm not sure it's a bad thing for ifup -a to be called, cause this loop is executed on $ restart networking as well.
<xnox> stgraber: then you would expect the new interface to be configured.
<xnox> stgraber: added a patch to do nothing in pre-start https://launchpadlibrarian.net/170045337/lp1072518-no-start.patch
<xnox> stgraber: i'd rather have hacks in one job, then upstart itself =)
<stgraber> xnox: ok, thanks for the patch, I'll think about it...
<charles> Sarvatt: ping
<charles> Sarvatt: I noticed you updated https://bugs.launchpad.net/indicator-datetime/+bug/1244285 earlier today
<ubottu> Launchpad bug 1244285 in indicator-datetime (Ubuntu) "Date/time sometimes doesnât appear in menu bar, settings greyed out (Ubuntu 13.10, 14.04)" [Medium,Triaged]
<charles> Sarvatt: were you doing that for bookkeeping (New -> Confirmed) because there was more than one reporter, or are you seeing this yourself?
<Sarvatt> charles: I'm not seeing it myself, a friend is and is following that bug. I just added the other project and set it to the same status as the other ones in hopes it would get looked at, sorry if I screwed anything up!
<Sarvatt> he could fix it by disabling auto login and make it broken again by turning it back on, thought the new info might help
<charles> Sarvatt: no, nothing like that, you didn't screw anything up
<charles> Sarvatt: I just wanted to pick your brains first since it would be faster than asking an open question in the ticket :)
<charles> thank you though :)
<ThiagoCMC> Guys, I just did an "apt-get update / dist-upgrade" on my Ubuntu 14.04 (Unity 7) and there is no more Window Manager... How can I debug it?
<ThiagoCMC> I'm running GNOME right now...   :-\
<UserError> That's something you Mutter under your breath around here.
<infinity> ThiagoCMC: Do you have the terminal log from the dist-upgrade?  Did it remove packages?  Did you let it remove packages without reading which ones?
<infinity> jamespage: Hah, the "solution" in the IBM mongo branch to your woes is to disable that test. ;)
<infinity> jamespage: Anyhow, there are lots of other changes in the branch, so I'll pull that all in and hopefully unblock you.
<ScottK> It would be nice if someone with access would throw http://kitterman.com/ubuntu/libopendbx_1.4.6-5.dsc at a ppc64el PPA and see if it builds.
<ScottK> If not, build log please.
<Logan_> ScottK: I don't think there are any ppc64el PPA builders atm
<ScottK> Logan_: No public ones.
<Logan_> :O
<ScottK> Or maybe it's just porter boxes.
<ScottK> You could be right.
<Sarvatt> ScottK: keep your eye on https://launchpad.net/~canonical-x/+archive/x-staging/+builds?build_text=&build_state=all
<ScottK> Sarvatt: Thanks.
<Sarvatt> ScottK: built fine, https://launchpad.net/~canonical-x/+archive/x-staging/+build/5829072
<ScottK> Sarvatt: Yep.  Thanks.  I didn't want to do the upload to Debian, wait, upload to Ubuntu round trip without a test.
<jamespage> infinity, well that's a great fix!
<jamespage> lol
<infinity> jamespage: I think the implication might be that the test is just wrong, but I'm going to talk to the branch maintainer and get his take on it.
<ThiagoCMC> guys, is there any problem with Unity and its Window Manager right now? I just upgraded my Ubuntu 14.04 (apt-get dist-upgrade) and the Window Manager doesn't appear (when with Unity 7)... But Gnome session works...
<ThiagoCMC> any tips to debug it?!
<ThiagoCMC> nothing appear on /var/log/Xorg.0.log either
<infinity> ThiagoCMC: Do you have the terminal log from the dist-upgrade?  Did it remove packages?  Did you let it remove packages without reading which ones?
<ThiagoCMC> I don't have the terminal logs anymore, sorry, but, I saw no errors there (yes, I always pay attention to the apt-get output)... No package was removed. Also, "apt-get -f install" doesn't point any problems...
<sarnold> check /var/log/ there may be some install/remove logs there too
<ThiagoCMC> Also, I didn't tried Unity8...    =P
<ThiagoCMC> sarnold, no logs about the Unity session startup?
<sarnold> ThiagoCMC: I was thikning of /var/log/dpkg.log
<ThiagoCMC> Well, never mind... I'll wait a few more weeks for the stable release, so I can go back to Unity again... Tks!!
<ThiagoCMC> =)
<sarnold> have fun! :)
<ThiagoCMC> ^_^
#ubuntu-devel 2014-03-20
<bluesabre> greeting sponsors!
<bluesabre> Is anybody interested in uploading...
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1294932
<ubottu> Launchpad bug 1294932 in xubuntu-docs (Ubuntu) "[needs-packaging] xubuntu-docs 14.04.1" [Undecided,Confirmed]
<bluesabre> and...
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1294459
<ubottu> Launchpad bug 1294459 in shimmer-themes (Ubuntu) "[needs-packaging] shimmer-themes-1.7.2" [Undecided,Confirmed]
<bluesabre> Please let me know if there are any questions or concerns
<pitti> Good morning
<doko> pitti, could you have a look at https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.91/+build/5827268
<pitti> doko: yes, will do; thanks
<doko> thanks
<dholbach> good morning
<ion> that
<YokoZar> Laney: Can I kindly trouble you to remerge p11-kit to fix https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1027299  :)   Alternatively, lmk if I should do it and seek sponsorship.
<ubottu> Launchpad bug 1027299 in p11-kit (Ubuntu) "Seperate out p11-kit-trust.so into a multiarch package to prevent errors in Wine" [Undecided,Confirmed]
<pitti> RAOF: ah, I got umockdev-record --evemu working :)
<pitti> RAOF: (mostly, need to fiddle with the "record device path" still)
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 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 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: dholbach
 * pitti hugs dholbach
 * dholbach hugs pitti back :)
<dholbach> hey happyaron - how are you doing? did you see https://bugs.launchpad.net/indicator-keyboard/+bug/1290881? (just checking because I'm doing some sponsoring right now)
<ubottu> Launchpad bug 1290881 in indicator-keyboard (Ubuntu) "indicator-keyboard suppresses IBus candidate window" [High,In progress]
<happyaron> dholbach: haven't looked at the patch yet, will do it this night
<dholbach> happyaron, thanks a lot!
<happyaron> np, :)
<seb128> dholbach, hey, happy piloting ;-)
<doko> mdeslaur, can you have a look at https://bugs.launchpad.net/ubuntu/trusty/+source/ca-certificates-java/+bug/1258286 ?
<ubottu> Launchpad bug 1258286 in ca-certificates-java (Ubuntu Trusty) "CAcert should not be trusted by default" [High,Confirmed]
 * dholbach hugs seb128
 * seb128 hugs dholbach back
<dholbach> bluesabre, for bug 1294459 do you have a .orig.tar.gz file somewhere?
<ubottu> bug 1294459 in shimmer-themes (Ubuntu) "[needs-packaging] shimmer-themes-1.7.2" [Undecided,Confirmed] https://launchpad.net/bugs/1294459
<tvoss> doko, good morning
<tvoss> doko, could you have a look here: https://code.launchpad.net/~robru/dbus-cpp/fix-ppc64el/+merge/211820
<tvoss> ?
<doko> tvoss, you don't need the b-d on gcc-4-x, g++-4.x depends on it. please don't add an explicit b-d on g++-4.8, but use g++ instead
<tvoss> doko, ack
<doko> tvoss, maybe just define something like v_ext=4.7, and then use g++$(v_ext)
<doko> tvoss, ahh, and g++ is a dependency of build-essential, so you don't need it at all
<tvoss> doko, okay, so I should be good with just g++-4.7 for non ppc64el, correct?
<doko> yes
<damianatorrpm> Hi all :-)
<damianatorrpm> How are you doing?
<tvoss> doko, https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-ppc64-el/+merge/211894
<doko> tvoss, 4.8 still hardcoded
<doko> ifneq (,$(filter $(DEB_HOST_ARCH),ppc64el))
<doko>   v_ext = -4.7
<doko> endif
<doko> export CC=$(DEB_HOST_GNU_TYPE)-gcc$(v_ext)
<doko> export CXX=$(DEB_HOST_GNU_TYPE)-g++$(v_ext)
<damianatorrpm> tiny question: libdubsmenu & libdbusmenu-qt, in ubuntu 13.10 I can see only in the repos libdbusmenu-qt, before there was libdbusmenu-gtk2 and libdusmenud-gtk3 which required patched gtk2/gtk3
<damianatorrpm> are they now dropped and only libdubsmenu-qt is still there?
<damianatorrpm> larsu: maybe you know ? :) :)
<Laney> Mirv: hm, qtbase didn't get pushed back?
<tvoss> doko, updated: https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-ppc64-el/+merge/211894
<doko> tvoss, ok. still b-d's on gcc-4.7, but doesn't hurt
<tvoss> doko, has to bd on gcc-4.7 until we update the papi to use > 4.7
<doko> tvoss, g++-4.7 depends on gcc-4.7, so it is not needed ...
<tvoss> doko, sorry, got it now
<cjwatson> damianatorrpm: "apt-cache search -n dbusmenu-gtk" still returns results on 14.04 for me
<tseliot> directhex: in case the email didn't make it, thanks! :)
<Mirv> Laney: it's not formally part of CI Train, so "the other CI" needs to merge it. trying that now.
<bluesabre> dholbach: yeah, its in the branch: https://bazaar.launchpad.net/~smd-seandavis/xubuntu-artwork/shimmer-themes-1.7.2/files
<dholbach> ah ok, thanks
<bluesabre> occasionally, there is some confusion with this package since its a multiple upstream tarball package, previous note with previous upload https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402/comments/7
<ubottu> Launchpad bug 1227402 in shimmer-themes (Ubuntu) "Please update shimmer-themes to 1.6.2" [Undecided,Fix released]
<bluesabre> thanks for taking a look :)
<mdeslaur> doko: sure, I'll take a look....it ftbfs?
<mdeslaur> doko: oh, nm, I see the test
<doko> mdeslaur, ok, thanks
<zequence> Laney: I see you are marked as janitor for ubuntustudio-live in the sponsors queue. Any more hinders in getting it through to universe?
<Laney> zequence: I don't know what that means
<zequence> Laney: From what I understand, it's uploaded, but needs approval from archive admins
<Laney> All that means is that I made the last comment on the bug
<zequence> Ah
<Laney> It's been uploaded, yes, just waiting for approval
<zequence> I have a habit of misreading things :P
<bigon> doko: hi
<bigon> I was wondering, about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720545
<ubottu> Debian bug 720545 in src:bash "bash: Please consider removing privmode.diff" [Important,Open]
<maxiaojun> why usb-creator is so buggy these days?
<miraiE> in Kubuntu, what app is similar with Password and Encryption Keys for uploading GPG key?
<sladen> Riddell: ^^
<pitti> Laney, stgraber: this should be a formality, but I filed it nevertheless: bug 1295133
<ubottu> bug 1295133 in umockdev (Ubuntu) "FFE: record/replay of input devices using the evemu format" [Wishlist,New] https://launchpad.net/bugs/1295133
<Laney> already replying
<pitti> Laney: wow, you're too fast :)
<Laney> just happened to open the list :-)
<pitti> Laney: yes, of course I'm reading incoming bugs, I watch the autopkgtest failures, and the Mir etc. guys know where I live :)
<Laney> Got to say these things for completionism :P
<barry> pitti: ping, re LP: #1272359
<ubottu> Launchpad bug 1272359 in aptdaemon (Ubuntu Trusty) "needs porting to Python 3.4" [High,In progress] https://launchpad.net/bugs/1272359
<pitti> barry: hey
<barry> pitti: hi
<pitti> barry: I see similar failures like you, also with current 3.3
<barry> pitti: there is no branch of aptdaemon that i can find that actually passes all its tests
<pitti> barry: i. e. the "FAILED (failures=1, errors=2, skipped=4)" bits
<pitti> barry: yes, that also happens in trunk
<barry> pitti: while d/rules runs the test suite at build time, it doesn't ftbfs because the test failures are ignored ;)
<pitti> barry: I guess trusty around it changed enough to now make it fail
<barry> pitti: upstream test suite doesn't pass in any of 2.7, 3.3, or 3.4
<pitti> *nod*
<barry> pitti: i am very much inclined to simply disable the dep8 tests for now and file an upstream bug about the test suite
<pitti> barry: back then when I filed it it still did (and only failed with 3.4), but apparently it now fails with current 3.3, too
<barry> pitti: 2.7 even ;)
<pitti> barry: we can just retitle that bug
<barry> pitti: yep, i'll take care of that.  do you have any objections to disabling dep8 for now?
<pitti> barry: there's no aptdaemon stuck in -proposed due to it, so no need to disable this
<pitti> barry: yes; that causes more technical liabilities, and the next upstream update might just silently get in with actual regressions
<barry> pitti: okay, i'm going to just fiddle with the bugs then and let upstream take it from here
<pitti> barry: thanks
<barry> pitti: cheers
<arges> stgraber: hey looking at bug 1254120. trying to isolate problems with ifup/ifdown on bonds. do you know which part of ifupdown would be setting static ips (ip addr ...) ?
<ubottu> bug 1254120 in ifenslave (Ubuntu) "Bonded interfaces don't come down with a ifdown -a" [High,In progress] https://launchpad.net/bugs/1254120
<stgraber> arges: looking
<stgraber> there isn't really "parts" in ifupdown, it's a gigantic source file :)
<arges> stgraber: yea, i noticed :)
<stgraber> but the commands comme from the .defn files which are parsed and expanded at build time
<stgraber> arges: so FWIW, I never expected my new package to fix bug 1254120
<ubottu> bug 1254120 in ifenslave (Ubuntu) "Bonded interfaces don't come down with a ifdown -a" [High,In progress] https://launchpad.net/bugs/1254120
<arges> stgraber: yea i've been trying to use strace and 'ifup -v' to figure out where the issues are
<arges> stgraber: figured as much, I looked at the change and didn't think it woudl either but tested it to make sure
<arges> i'll look through the .defn files.
<stgraber> arges: let me update my network testing box to see if I can reproduce that issue easily here
<arges> stgraber: yea, i'm doing this all in VMs and its pretty trivial to reproduce
<stgraber> my test box is physical hardware with LACP but that shouldn't matter in this case
<arges> yup
<Riddell> sladen: you still into fonts?
<stgraber> arges: I suspect something may be wrong somewhere in ifenslave which would explain why it's not obvious when running with -v but hopefully I can figure out what exactly once that box is done upgrading (I really should switch to something better than a single core 32bit Atom for that box :))
<Riddell> sladen: fancy seeing if this tar is sane and can be built and works? starsky.19inch.net/~jr/tmp/oxygen-fonts-0.4.tar.xz
<darkxst> dholbach, I have to run, but re Bug 1294891
<ubottu> bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [Undecided,Incomplete] https://launchpad.net/bugs/1294891
<darkxst> we got permission from image authors to release work under cc-by-sa 3.0, so copyright file should be ok?
<xnox> balloons: sergiusens: what can I help with to release calendar-app revision 205 or better? It's been blocking python2 removal for a while now.
<arges> stgraber: yea something intiially is causing it to not create the proper files in /run/network and the ifstate file isn't updated correctly, so I think ifup needs to work. The other question is, do we expect 'ifup bond0' to bring up slave interfaces or that needs to be done before bringing up the bond?
<sergiusens> xnox, just push balloons around
<xnox> balloons: i'm prepared to be a slave for you =) calendar-app, please please please =)))))
<stgraber> arges: ifup bond0 won't bring up slaves, it'll just sit and wait until slaves join. But slaves will bring up bond0, so "ifup eth0" should bring up eth0, bring up bond0 and then add eth0 to bond0
<arges> stgraber: gotcha.
<arges> stgraber: so if i do 'ifup <slave if>' and the bond comes up, do we expect the ifstate file to have bond0=bond0 in it?
<xnox> balloons: honestly changes from v201 to v205 are trivial, and are trivial to verify. We shouldn't need to wait on all the cool things to be developed and be ready.
<stgraber> arges: we do, though I suspect that may be the problem
<balloons> lol xnox
<arges> stgraber i think so too
<balloons> xnox, see my perhaps confusing mail on the list. We need to release calendar too. But trunk is broken. So I have a merge reverting the bad changes in trunk that we can land
<balloons> alternatively, we could fix the trunk version of the app, then land the fixes for the test
<xnox> balloons: do you want me to prepare v205 click, with diff of what changed is no code change. http://paste.ubuntu.com/7125444/
<xnox> balloons: you don't have to release trunk.
<xnox> balloons: i'm asking to release revision 205.
<xnox> balloons: which has _no code changes_ to the app.
<xnox> balloons: merging back reverts is silly. It's a distributed version control system, checkout the revision you want to release, build the click for that revision # and upload to the store.
<xnox> balloons: my changes were ready eon ages ago, why should i be blocked by broken trunk? i can trivially push current trunk to a staging branch and do push --override back to revision 205 if you wish.
<xnox> balloons: then "release trunk" and push back the current trunk back in place. But it's silly if we need to do that.
<xnox> balloons: am I missing something?
<xnox> bzr branch lp:ubuntu-calendar-app -r205 is not broken, and is trunk.
<balloons> https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1294181
<ubottu> Launchpad bug 1294181 in Ubuntu Calendar App "Autopilot tests crashing in switch_to_tab helper" [Critical,Confirmed]
<balloons> https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1294995
<ubottu> Launchpad bug 1294995 in qtdeclarative-opensource-src (Ubuntu) "qmlscene crashed with SIGSEGV in value() when running calendar-app" [Undecided,Confirmed]
<balloons> xnox, it sounds like we're going to go ahead with landing my mp which reverts the offending changes: https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/revert-212/+merge/211813
<xnox> balloons: and?
<xnox> balloons: dude, we need to fix packaging and metadata of the app. The app itself would be identical but the manifest revision number of where to fetch the tests from.
<stgraber> arges: hmm, nope, that's not it. In my setup here with eth0+eth1 in bond0 and bond0 in br1000, I get the expect behavior, proper bring down and consistent ifstate
<stgraber> arges: now trying with IP config directly on bond0 as you have
<xnox> balloons: with normal packages, i would have done direct to the archive upload weeks ago.
<maxiaojun> http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Block.html#gdbus-method-org-freedesktop-UDisks2-Block.Format
<maxiaojun> seems like erase: '' no longer works on trusty
<balloons> xnox, I'm blocked on releasing anything unless tests pass
<balloons> and tests fail in trunk because the app has some critical bugs
<balloons> regardless, it sounds like we are going to be able to land something today that should solve your issue
<balloons> so details aren't important
<stgraber> arges: nope, things still get brought up correctly with "ifup eth0 && ifup eth1" and brought down correctly with "ifdown -a"...
<stgraber> now trying with an exact copy of your config :)
<xnox> balloons:  "I'm blocked on releasing anything unless tests pass" that sounds really odd, can you ellaborate where this requirement is comming from? because that should be blocking merging and landing new features, this should be blocking any other no-change rebuilds. E.g. just like we did for qt5.2 landing and etc?!
<arges> hmm
<xnox> balloons: the details are important, as I have been blocked for about 4 weeks due to inability to do click uploads.
<xnox> balloons: those that _do_ not match trunk.
<arges> stgraber: it works if the bond is using dhcp, but not with a static ip
<arges> stgraber: in fact it seems to affect any static interfaces... I just set eth1 to static and tried to ifdown it with no luck
<roadmr> Hey folks, I see (https://launchpad.net/builders) that ppc64el builders are available for official distro but not for PPAs. How can I provide ppc64el packages on a PPA?
<cjwatson> roadmr: that's only possible with devirtualised PPAs, which are only provided for special purposes
<stgraber> arges: I don't use any dhcp here
<stgraber> arges: here are the config I tried so far: http://paste.ubuntu.com/7125505/
<stgraber> arges: both come up fine with either "ifup eth0 && ifup eth1" or "ifup -a" and they get brought down cleanly with "ifdown -a"
<arges> stgraber: let me adjust my config here
<roadmr> cjwatson: devirtualized meaning native hardware? oh those must be scarce... who can help me decide if my purpose is special enough and maybe give us access to this?
<mdeslaur> Laney: do we have a codesearch set up on the ubuntu somewhere?
<maxiaojun> ask again, who takes care of usb-creator?
<arges> stgraber: i also found another issue where if I have a bond my vm takes much longer to boot up because i get 'bonding: bond0: unable to update mode because interface is up'
<arges> so i should file a separate bug for that
<Laney> mdeslaur: ya: http://ubuntu-codesearch.surgut.co.uk/
<cjwatson> roadmr: #webops internal
<Laney> be patient with it and refresh a couple of times if you get timeouts
<maxiaojun> xnox: ping
<mdeslaur> Laney: sweet, thanks!
<roadmr> cjwatson: great, thanks so much for the info. I'll ask there
<xnox> maxiaojun: hey!
<arges> stgraber: i can still easily reproduce with http://paste.ubuntu.com/7125534/
<stgraber> arges: so even if your config (dropping the eth0 and replacing eth1 by eth0 and eth2 by eth1), I still get things to work here...
<arges> if I change bond0 from static to dhcp it works
<maxiaojun> xnox: usb-creator's "Erase Disk" seems totally broken in trusty
<xnox> maxiaojun: yeah. I have seen patches posted to the bugs on usb-creator. But I didn't review / upload them yet. I was planning to do it today or tomorrow.
<arges> stgraber: I'll try this on hardware. Mind reproducing this in a VM? (just to prove i'm not crazy)
<stgraber> arges: if I can find a machine where I have some kind of VM technology installed :)
<stgraber> (sorry, LXC maintainer here)
<maxiaojun> xnox: i cannot fix it even if i traced to usb-creator-helper
<arges> stgraber: ah. ok i'm testing on hw now
<jdstrand> Laney: curious, is that just for the dev release?
<Laney> jdstrand: ya
<Laney> YokoZar: I uploaded that, thanks for pointing it out
<Cimi> mterry, how do I test on the phone? branch and compile?
<mterry> Cimi, the wizard?
<Cimi> yup
<mterry> Cimi, yeah you could do that, and run it manually...
<Cimi> ok
<mterry> Cimi, alternatively, you could use the upstart job that we don't actually ship in the deb, but is in the source tree
<mterry> Cimi, place that in /usr/share/upstart/sessions
<arges> stgraber: just to confirm you've been testing trusty right?
<maxiaojun> xnox: call to UDisks2's format either error or timeout (cannot find a way to do 'quick format' and do not where the time limit is set)
<stgraber> arges: yep, up to date trusty + ifupdown from my PPA
<arges> stgraber: ok i'm using the same in my vm with your ppa, and still reproducing it
<balloons> xnox, so we are landing a fix to the store right now. As far as what happened, well when qt 5.2 landed the trunk and supposed stable version of calendar stopped working due to the bugs I linked. I understand you are upset because you made only manifest changes, however I cannot release an old revision, it has to be current trunk
<stgraber> arges: testing in a clean vm here now
<arges> stgraber: ok... on hardware. ifdown -a; ifconfig (bond0 is gone!), ifup -a && ifdown -a (bond0 is still there)
<stgraber> good, so I'm not insane :)
<stgraber> oh no
<stgraber> misread
<xnox> balloons: that sounds very wrong that " we cannot release an old revision,"
<xnox> balloons: we do this all the time for all components in the archive, in main and the ubuntu-touch seeds, both click apps and .debs
<xnox> balloons: we should fix that.
<balloons> xnox, afaict releasing an old version would still have broken tests. So yes it would have fixed your issue, but not the issues with the landing team and wouldn't pass the store review
<xnox> balloons: ?! dude didrocks himself uploads things to revert, or do no-change uploads without regressing beyond what was on the image already.
<xnox> balloons: e.g. we go up and down broken versions all the time.
<xnox> balloons: i'd love to hear comments from the landing team about this.
<didrocks> xnox: can you stop trolling and start helping in the bazillion of regressions we have please?
<balloons> xnox, I have things rejected all the time for the store..
<balloons> anyways, your pain is not just your own.. the calendar devs, landing team, everyone has felt the impact of calendar regressing. But it's fixed now
<didrocks> xnox: and we do test the revert before uploading and ensuring we don't introduce regressions compared to latest promoted image FWIW
<arges> stgraber: on hw: reboot interfaces are correct, ifdown -a - everything is down, ifup -a - I get a kernel message 'bonding: bond0: unable to update mode because interface is up' and I noticed in ifenslave it tries to set the bonding mode but that command fails...
<balloons> well, fixed in the sense you'll get a new build
<xnox> didrocks: correct. and ballons seems to think that this is not the case here.
<arges> and on my vm, I get that kernel message right on boot every time (in fact it delays boot up by a minute or so)
<xnox> didrocks: sure, what do you want me to fix in the fork of calendar-app form revison 201?
<didrocks> xnox: I'm not sure about anything right now, calendar-app has no issue with balloons's fixes from what I know of
<xnox> didrocks: it appears to have been accepted to have a certain baseline from way before qt5.2 uploads et.al.
<xnox> didrocks: gallery-app?
<didrocks> xnox: read #ubuntu-touch for the regressions
<xnox> didrocks: dude calendar_app is 100% green with no crashes http://ci.ubuntu.com/smokeng/trusty/touch/mako/248:20140320:20140304/7277/calendar_app/
<didrocks> xnox: I know that link
<xnox> didrocks: please explain how calendar-app is not in a releasible state up to revision 205.
<didrocks> in case you wonder
<didrocks> I don't know
<didrocks> did I say that?
<didrocks> did I write that?
<xnox> didrocks: no. But balloons above claims landing team is blocking releasing calendar-app.
<didrocks> xnox: so how do you want me to explain something I didn't write?
<didrocks> balloons: what's about this? ^
<xnox> didrocks: balloons: so what do I need to do to release 205? do you want to execute full manual testing plan?
<xnox> didrocks: well, I'm trying to find out what needs doing to release calendar app to revision 205 =)))) but i don't know who would know =))))
<balloons> xnox, ?? What do you need. We are releasing a build from today that contains everything up through rev211, which has your changes
<pitti> barry: big +1 on dropping 3.3
<balloons> just wait for it to land and you should be set?
<didrocks> xnox: yeah but please don't assume and start telling things that aren't written
<didrocks> xnox: there is enough pressure and confusion on the real regression
<didrocks> no need for noise on top of that
<didrocks> that would be appreciated
<barry> pitti: \o/
<xnox> balloons: what's special about today vs all the past 4 weeks. I mean fine, but what can I do to prevent 4week delays like this?!
<pitti> barry: that's essentially "drop it from py3versions; rebuild $world; remove package", right?
<xnox> didrocks: well i have spare cycles and time to test and release things, yet people who can release are over-worked with "the real regressions"
<didrocks> xnox: yeah, and not sure why you are telling that I wrote we are blocking you
<barry> pitti: yes, although $world only needs to include packages with extension modules (to be identified)
<xnox> didrocks: i'm asking how to help. Can i have access to e.g. click packages releases? and be one more lander for that?
<didrocks> xnox: I don't know, I can't release click package either
<xnox> didrocks: cause i've checked all the ci-train stuff, but the click/core-apps are not listed. Who owns those?
<xnox> balloons: is it only you who can release core-app clicks?
<barry> pitti: doko is going to upload 3.4 final tomorrow or this weekend, so let's wait for that
<pitti> barry: ack
<didrocks> xnox: and sergiusens
<didrocks> but you just started a mail on the ML
<stgraber> arges: just for fun, can you comment out eth0 in both your setups and try again?
<didrocks> if you want to discuss that on IRC, use IRC
<didrocks> don't double the discussion
<stgraber> arges: if that magically makes the issue disappear for you, that'd at least explain why I can't reproduce your problem
<xnox> didrocks: well there is no resolution. i basically got told off, to sit and wait and do nothing it will be done "today".
<arges> stgraber: sure i'll try it
<didrocks> xnox: on the ML? You wrote the email 20 minutes ago and you already get one answer
<arges> stgraber: wierd... without the extra eth0 interface ifdown -a && ifup -a works fine
<arges> stgraber: i looped it about 10 times with no problems
<arges> stgraber: i'm going to have to write some additoinal tests for ifupdown : )
<stgraber> arges: good, so that confirms what I'm seeing here.
<stgraber> arges: now the question is wth is eth0 triggering the bond somehow...
<stgraber> I guess diffing "ifup -a" with "ifup --exclude=eth0 -a" may point us in the righ direction
<stgraber> well, both of those with -v obviously
<arges> good idea. i'll give that a try
<stgraber> just ifup/ifdown of eth0 doesn't seem to do anything wrong, so it's pretty confusing
<xnox> didrocks: no, i've emailed to the ML based on the conversations with balloons. After that, you, ballons and I continued talking about this topic.
<didrocks> xnox: ack then, seems it's resolved now though, right? balloons is going to release it?
<arges> stgraber: confirmed that ifdown -a && ifup -a --exclude=eth0 do the correct thing for 5 iterations
<stgraber> arges: hmm, I'm getting an error from lockfile when doing ifup -a, I wonder if that could be the problem
<xnox> didrocks: this landing is resolved, yes. the backlog in .click releases of core-apps is subpar and needs more people helping out.
<dholbach> darkxst, if the content is all cc-by-sa - all the files should say so
<xnox> sergiusens: balloons: can you train me up to prepare and help with releasing .click core-apps?
<sergiusens> xnox, sure
<didrocks> xnox: yeah, that was on the schedule to discuss this week to have one release process for debs and clicks, but regressions blocked to take the time for it
<sergiusens> not much training needed; I'll ping back later today
<sergiusens> ah, right
<sergiusens> we can do it then as well
<xnox> sergiusens: balloons: that would be appreciated and hopefully would free you up your development time on more urgent things.
<didrocks> sergiusens: no time due to regression and not around tomorrow
<arges> stgraber: are you only seeing this with -v?
<sergiusens> didrocks, I'm not around tomorrow either
<balloons> xnox, do you have a device?
<stgraber> arges: that can be ignored, it was just the ntpdate hook being unhappy, I moved it away for now
<Cimi> mterry, it's not optimal, takes ages
<xnox> balloons: i have grouper and mako.
<stgraber> arges: "ifup eth0 eth1 eth2" => missing bond0 in ifstate, "ifup eth1 eth2 eth0" => it's in there and everything works
<xnox> didrocks: "that was on the schedule to discuss this week" where would this discussion be?
<xnox> or did you mean last week / vUDS?
<didrocks> xnox: this week
<didrocks> didn't get room last wekk
<didrocks> week
<arges> stgraber: that's really wierd
<didrocks> just a hangout
<didrocks> xnox: you're welcome to organize it
<didrocks> and promote it
<xnox> didrocks: i wouldn't know full current release process of either debs or clicks, and even less on how to apply common policies/current practice to both.
<xnox> didrocks: so i'm not at all the right person to drive that session.
<didrocks> ok, so let's us driving it
<didrocks> when we'll get time for that
<Cimi> seb128, how you test on the phone?
<Cimi> seb128, it takes light years to compile
<xnox> didrocks: i wish to be an ad-hoc lander and help releasing things, but so far that was not possible.
<seb128> Cimi, light years is an unit of distance :p
<seb128> Cimi, you can cross compile on your desktop
<Cimi> seb128, I know it is, but in my mind imples very far away with current speeds :)
<seb128> if you have a build tree it's not that slow to run make
<seb128> also often we work on qml
<Cimi> seb128, I ran debuild
<Cimi> on the phone
<Cimi> after fifteen years I run wizard/test.sh
<Cimi> and it aborts
<Cimi> fantastic :D
<Cimi> could not connect to display
<seb128> yeah, you don't get to run things by hand on the phone
<seb128> you need to --desktop_hint= if you do
<seb128> but I never tried the wizard on the phone, maybe mterry did
<mterry> seb128, Cimi: I  did, using the upstart job
<mterry> seb128, Cimi: but really, integration with phone setup is a TODO (ideally, it will be launched by greeter if needed)
<Cimi> mterry, how can I test sim card?
<Cimi> mterry, I did make install
<mterry> Cimi, try using the upstart job
<mterry> Cimi, install your built deb
<Cimi> how do I play with the upstart job?
<mterry> then copy the upstart job from the source to /usr/share/upstart/sessions
<mterry> then reboot
<seb128> you copy it in the init dir (system or user)
<seb128> reboot or just "start <job>"
<seb128> well, you might need to ack it for that
<seb128> tweak the start conditions
<Cimi> mterry, job name?
<mterry> Cimi, wizard/ubuntu-system-settings-wizard.conf
<xnox> mterry: ~/.config/upstart is read by session upstart as well.
<Cimi> mterry, start ubuntu-system-settings-wizard doesn't work
<mterry> Cimi, did you manually copy the job to the upstart directory?
<Cimi> mterry, /usr/share/upstart/sessions
<xnox> Cimi: $ init-checkconf ubuntu-system-settings-wizard.conf
<Cimi> mterry, but I cannot run others in anyway
<xnox> Cimi: and $ initctl list | grep settings-wizard
<mterry> Cimi, try rebooting?
<Cimi> xnox, maybe rebooting
<xnox> Cimi: sudo -u phablet -i, should setup the right environment and join the existing upstart user session of the currently running phablet user.
<mterry> (just because then the job will launch itself)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 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 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:
<stgraber> arges: so I have an idea for at least part of the problem, looking into ifupdown's code to confirm that one now.
<stgraber> arges: I suspect that ifup only writes ifstate in one shot at the end of the bring up which will then race with anything happening from upstart...
<arges> stgraber: this is update_state in main.c?
<stgraber> arges: yeah, though reading it now, it looks safe...
<Cimi> mterry, xnox thanks works, and sim detection too
<Cimi> mterry, seb128 simple one https://code.launchpad.net/~cimi/ubuntu-system-settings/wizard.sim-detection/+merge/211976
<seb128> Cimi, looks good, thanks
<stgraber> arges: so the reason why bond0 isn't in ifstate is because upstart fails to bring up bond0, I'm trying to figure out exactly why that is though
<stgraber> arges: oh, hold on, I think I know
<arges> stgraber: network-interface.conf or networking.conf?
<arges> stgraber: : ) ok
<stgraber> arges: yep, figured it out, your config has been wrong all along :)
<stgraber> arges: you can't have multiple default gateways
<stgraber> well, you can, but not with the same priority
<YokoZar> Laney: Thanks!
<stgraber> dhcp gives you a default gateway, you also have one in bond0, so bond0 fails to come up because ifupdown can't set the gateway
<stgraber> however bond0 is also created at that point so the rest continues and blows up because bond0 was never initialized due to the failure
<arges> stgraber: so two things : 1) how come this works on reboot? 2) do you think ifupdown should show a better error message?
<stgraber> arges: it's a race. If for some reason bond0 comes up before eth0, then things appear to work because dhclient will just silently fail to set its gateway
<stgraber> arges: ifupdown actually did log an error, just not anywhere where we were looking (it was in /var/log/upstart/network-interface-bond0.log)
<arges> stgraber: well I just get things like 'Failed to bring up bond'
<stgraber> arges: to confirm, can you try adding "metric 10" to your bond0 on both test machines and then confirm everything works as expected?
<stgraber> arges: aren't you getting the netlink error for IP collisions?
<stgraber> RTNETLINK answers: File exists
<arges> stgraber: yes I get that error as well
<arges> ah
<arges> that's where ip addr sets that gateway and it fails
<arges> ok
<stgraber> yep, it fails saying there's already an entry for the default gateway
<arges> stgraber: ok metric 10 added to the bond0 entry works on the VM
<stgraber> ok, good, so ifupdown and ifenslave work great, it's just my brain that doesn't, I should have noticed the conflict immediately...
<arges> stgraber: so why can't we have different default gateways for two different interfaces?
<arges> stgraber: and if we errored, why does bond0 still come up? and then we can't ifdown it again?
<arges> so this clearly seems like a configuration error, but i'm wondering if there is something that can be done to make ifupdown more robust with this type of failure
<stgraber> arges: the actual bond bringup is a bit special. Basically the first interface that's related to a bond (in our case, eth1) will do "echo bond0 > /sys/class/net/bonding_masters" which will create bond0. It'll then enter a loop waiting for ifenslave.bond0
<stgraber> the device creation emits a udev event which is picked up by upstart which then starts network-interface with INTERFACE=bond0
<stgraber> that in turns calls "ifup --allow=auto bond0" which is responsible for actually setting up all the parameters
<stgraber> now the problem we had here is that this ifup failed right at the end in the ifupdown code, so not something we can do anything about from the ifenslave code
<stgraber> and since the device isn't created by ifupdown, it doesn't know how to delete it
<stgraber> and as everything is done in parallel, the initial ifenslave hook can't get a return code from upstart so can't know that bond0 actually failed to be brought up
<stgraber> hmm, actually I suppose we could grep for bond0=bond0 in ifstate and try to abort if it's not in there
<arges> stgraber: ok i think that woudl help rather than getting into this error state
<arges> stgraber: the other question is why can I do something like "route add default gw 192.168.122.1 netmask 255.255.255.0 dev bond0" even if I have a default gw for eth0? But for some reason I need to change the metric to 10 to get it working with ifupdown/ifenslave/upstart
<stgraber> arges: http://paste.ubuntu.com/7125986/
<stgraber> arges: you only get file exists if the entries are identical, any difference and it'll let you add it
<arges> stgraber: so 'ip route add ' behaves differently than 'route add'
<stgraber> arges: route add doesn't appear to set "proto static"
<arges> stgraber: but isn't there a different in the dev used?
<arges> what i'm saying is this feels like a workaround and not a fix. because if we're defining a gateway for bond0, it should be for that device and shouldn't conflict with eth0's default gw right?
<stgraber> arges: there's no such thing as per-device gateway, the default gateway applies to all the trafic
<arges> stgraber: ah. ok
<stgraber> arges: so I guess you are only allowed one default gateway per metric and per scope/type
<stgraber> the device isn't considered at all, so if you try to add the same route for two difference devices, you'll still get File exists (as was the case with your config)
<arges> stgraber: so the 'real fix would be don't have multiple gateways defined for your network configuration
<arges> this may explain another issue i'm looking at...
<stgraber> arges: correct
<arges> stgraber++ cool thank you so much for your help with this.
<stgraber> multiple gateways is a nightmare to get right. You can do it with different metric and source based routing but that's a major pain
<arges> stgraber: so looking at the configuration if I wanted eth0 to get an IP from dhcp but my routing table not create a default gw for eth0 how would I specify that?
<stgraber> arges: I suspect you'd have to change your dhclient.conf
<arges> stgraber: ok. so i have a couple of suggestions then. Thanks
<stgraber> arges: hmm, so bad news, there isn't a good way to have bond0 commit suicide if ifupdown fails to set the gateway, that's because there isn't a good way to have ifup call a script on failure for something it does internally
<stgraber> so I think the best we can do for 14.04 is make sure that we have a paragraph reminding people that this specific config isn't possible
<arges> stgraber: that sounds good. Where would be the best place for this? ubuntu wiki?
<arges> man pages?
<stgraber> arges: probably in the serverguide or wherever caribou was planning on documenting that kind of stuff
<arges> stgraber: ok i'll work with him on this
<juliank> bdmurray: WRT the encoding stuff. Instead of hardcoding the encoding in python-apt, how about putting something like http://paste.debian.net/88736/ in front of all dbus daemons using it?
<juliank> This tells daemons like aptdaemon or software-properties-dbus to use the system's default locale, rather than the C locale, and thus ensures correct encoding, even in non-UTF-8 environments.
<juliank> Apparently Cyrillic and CJK use non-UTF-8  environments
<bdmurray> juliank: I don't think I know enough to say one way or the other.
<bdmurray> barry: are you about?
<barry> bdmurray: yes
<bdmurray> juliank: wanted a second opinion about some encoding issues...
 * barry backscrolls
<barry> gosh, i don't know about that pastebin
<mitya57> ScottK: can I go ahead with sip/pyqt* update in Trusty? It doesn't add new features (except some new methods in sip) (so probably no FFe is needed), but it will require rebuilding some stuff.
<tvoss> robru, ping
<juliank> barry: One of the problems is that dbus starts daemons without a locale, so Python chooses the ANSI_X3.4-1968 encoding. Which fails if the files we open contain non-ANSI stuff like UTF-8 or some other encodings (CJK, etc)
<juliank> So we need some way to override the preferred encoding of Python.
<juliank> But that does not seem possible without re-exec()ing
<juliank> I do not want to force everyone to have their /etc/apt/sources.list in UTF-8.
<sladen> juliank: python -S   then  sys.setdefaultencoding("utf-8")  ?
<barry> juliank: i generally prefer to open text files with an explicit encoding, which of course you have to know ahead of time.  in py3, built-in open() has an encoding argument, which i almost always set to utf-8.  but if the file contains non-utf8, you still have to be explicit (so how would you know what it contains if you don't already know, if you know what i mean ;)
<juliank> sladen: setdefaultencoding() does not change the preferred encoding.
<rsalveti> xnox: are you uploading a new android today still?
<juliank> barry: The user edits the files with a text editor, which chooses whatever the locale tells him. So clients using python-apt should just use the same encoding, as the normal admin does. Which is probably what /etc/defaults/locale
<juliank> says.
<juliank> Python 3 automatically chooses the default file encoding from LANG, and I think that's a good idea, because things work in almost all cases. It only breaks for dbus services, because dbus starts services in a hyper-clean environment
<sladen> is this not what is loaded via the 'site' module;  which is disabled by python -S ?
<doko> Laney, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5680438
<juliank> sladen: The defaultencoding in sys is different from the preferred encoding according to my tests.
<doko> cjwatson, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5675877
<doko> zyga, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5673667
<cjwatson> doko: tomorrow
<doko> infinity, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5673667
<doko> seb128, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5700287 ?
<seb128> doko, sure, I meant to do that last week and got sidetracked with other issues, adding to my todo for tomorrow
<doko> Sweetshark, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5703951 ?
<doko> cjwatson, seb128: thanks!
<xnox> rsalveti: i'm still working on it. Let me check how far the build got to.
<xnox> rsalveti: there were a couple of bugs when building in the chroot, vs just on my local machine.
<xnox> rsalveti: ideally, yes i'd like it to be uploaded today.
<seb128> doko, yw!
<Laney> doko: tomorrow too
<rsalveti> xnox: ok, let me know if there's anything I can help you with that
<Laney> doko: in return I'd appreciate it if you could see if you have any bright ideas about https://buildd.debian.org/status/fetch.php?pkg=webkitgtk&arch=armhf&ver=2.3.92-1&stamp=1395146394
<xnox> rsalveti: well, i'd want you to review the debdiff and test x86 emulator image shortly.
<rsalveti> sure
<doko> Laney, do you have the preprocessed source somewhere?
<Laney> nope
<doko> mlankhorst, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5735335 ?
<Laney> I guess you could reproduce it locally ;-)
<Laney> or I can, but again tomorrow
 * Laney leaves for a bit, see you
<sladen> juliank: I'm don't dispute this:  http://paste.ubuntu.com/7126580/
<arges> stgraber: fyi, bug 1295304 has the new ifdown -a / vlan/bonding issue we discussed earlier
<ubottu> bug 1295304 in ifupdown (Ubuntu) "ifdown -a fails with vlans on bonded interface" [High,In progress] https://launchpad.net/bugs/1295304
<juliank> sladen: Right, if I run this with LC_CTYPE=C it shows that me "<module 'sys' (built-in)> None UTF-8" and then "UTF-8 ANSI_X3.4-1968"
<juliank> And it does not even work in python3 which does not have reload. And we only care about Python 3, because Python 2 does not care about encoding at all
<barry> juliank: sorry, multiple conversations going on.  s/reload/imp.reload/ in py3
<juliank> barry: Thanks.
<juliank> But this still won't work because we are missing some kind of setpreferredencoding() AFAICT
<juliank> OK, seems I figured something out
<juliank> barry: So, I got rid of that nasty exec() by calling locale.setlocale(locale.LC_CTYPE, "") after setting the environment variables from /etc/default/locale. http://paste.debian.net/88751/
<juliank> This changes the value returned by locale.getpreferredencoding()
<juliank> and should thus change the default encoding of open()
<barry> getdefaultencoding is pretty much hardcoded to utf-8 in py3
<barry> s/pretty much// even ;)
<juliank> barry: Yes, but not getpreferredencoding() which is what open() uses. That uses the locale.
<barry> juliank: yeah.  it just makes me uncomfortable not give an explicit encoding to open()
<barry> juliank: where do you propose that pastebin code would go?
<juliank> barry: In aptd and software-properties-dbus (both D-Bus daemons)
<juliank> Are the other d-bus daemons using python-apt?
<barry> not sure.  check reverse-depends python3-apt?
<barry> juliank: so let me see if can summarize the problem (is there a bug?).  user writes some non-utf8 text to a file in their possibly non-utf8 locale.  some dbus daemon reads that file.  dbus does not set a locale so there's no way to know what encoding is used in the file.  boom.  if so, would seem to affect any such dbus daemon.  reading /etc/default/locale may get you closer, but could still not be perfect if user sets a different
<barry> locale.
<juliank> barry: Yes. But consider that the files are only writable by root and root configures the default locale. This is the closest we can get I think.
<juliank> It does not affect most d-bus daemons, I think; because most are written in C, and they simply read things in bytes.
<barry> i guess that would be another option, though probably not much fun (e.g. open in binary mode, read bytes and then decode according to best guess)
<barry> i'm rather surprised dbus doesn't specify a locale
<stgraber> arges: found the issue with the vlans, it's actually ifupdown being a bit too clever
<arges> stgraber: wow
<arges> that was fast
<stgraber> arges: it notices that the device is a vlan and tries to destroy it, except the vlan hook did it already so you get the error
<barry> anyway, it seems like a hack, but possibly one that will usually work, and "practicality beats purity"
<stgraber> arges: I'm trying to disable the chunk of code in ifupdown that does that, that should fix some broken behaviours with bridges and vlans
<arges> stgraber: cool let me know and i'll test it on this end
<juliank> barry: I just noticed that aptdaemon has something similar already in its script, but it simply hardcodes C.UTF-8
<barry> juliank: i wonder if that's the cause of all the aptdaemon test failures ;)
<barry> kidding, but still
<juliank> barry: It seems that my approach without the exec()ing does not change the file system encoding of Python.
<juliank> aptd re()execs itself if sys.getfilesystemencoding() == "ascii" and not "LANG" in os.environ
<juliank> If we add the default locale loading in there, all things should just work in almost all cases.
<juliank> The combined approach would be http://paste.debian.net/88755/
<juliank> It first sets LANG to C.UTF-8 and then reads /etc/defaults/locale to try to find something besser.
<juliank> It would probably be easier to ship a wrapper script instead of re-exec()ing the script itself.
<juliank> Although this should work.
<arges> bdmurray: hi. i'm getting a few things done, then i'll have some time to help with sru queue
<bdmurray> arges: sounds good
<jtaylor> infinity: when are we getting a fixed libm?
<stgraber> arges: fixed ifupdown uploaded to my ppa
<stgraber> arges: this also contains xnox's change to prevent "restart networking" and "stop networking"
<arges> stgraber: i'll give it a try. this is the experimental ppa?
<stgraber> yep, just uploaded now so it'll be a few minutes before it's done building
<arges> ok
<stgraber> arges: done building, feel free to just grab the binary from LP
<arges> stgraber: ok will do
<zyga> doko: looking
<zyga> doko: how can I reproduce that rebuild? was there anything special about it?
<juliank> bdmurray: I reassigned the original bug to software-properties, could you reset it from fix released to new or triaged?
<juliank> We should then sync python-apt 0.9.3.4 from sid tomorrow and close regression bug 1294531
<ubottu> bug 1294531 in python-apt (Ubuntu) "Unicode traceback saving empty SourcesList regression" [Undecided,Confirmed] https://launchpad.net/bugs/1294531
<arges> stgraber: it works! ifdown -a only leaves lo interfaces, and ifup -a brings back everything as expected . I did 5 iterations of it
<bdmurray> juliank: yes, will do
<juliank> Thanks.
<stgraber> arges: good :)
<bdmurray> juliank: Thanks for working on this.
<bdmurray> barry: any ideas about the update-manager tests?
<barry> bdmurray: no, sorry, i've yet to get a block of time to dig into it
<juliank> bdmurray: I'm happy that I do not have to think about update-manager... Enough other packages too maintain for me over in Debian.
<juliank> Which reminds me that I (or hopefully someone else) still need to write a PackageKit-based update-notifier replacement for Debian.
<stgraber> xnox: what's the status on changing lsb so that init scripts which have a matching upstart job exit immediately when called?
<stgraber> xnox: I believe slangasek told me in London that it was on your todo for 14.04
<slangasek> not sure I said 14.04
<slangasek> I did say xnox did have a plan for fixing this
<stgraber> ok, maybe you didn't say 14.04, though I'd argue we probably ought to fix this for 14.04, it's starting to be a bit rdiculous for half our init scripts to manually check for upstart and for the other half to just confuse you or break your system/service
<stgraber> and it's going to be quite a surprise for people upgrading from 12.04 as they'll move from the upstart-job symlink to a potentially harmful init script
<stgraber> (sure, they shouldn't be calling those scripts directly to begin with, but well, they do...)
<xnox> stgraber: right, i do have an example patch, but i didn't submit it to the debian maintainer.
<xnox> stgraber: i'll add it to my todo for tomorrow.
<stgraber> xnox: awesome! thanks
<xnox> stgraber: indeed it outght to be fixed, cause e.g. /etc/init.d/ssh start should start ssh server..... not exit zero without any output.
<xnox> cause that would make everyone think it did start up.
<xnox> stgraber: might get it done tonight after kids are asleep.
<xnox> rsalveti: hm, shell scripts for the emulator got dropped?! http://paste.ubuntu.com/7127213/
<rsalveti> xnox: yes
<xnox> rsalveti: cool.
<rsalveti> xnox: but they were already removed from the android package
<rsalveti> not sure why it tried to install them again
<xnox> rsalveti: hm, weird. I'll check my debdiff carefully, maybe i'm working against something old =/
<rsalveti> the ubuntu-emulator package is doing the logic to download and setup the image
<rsalveti> yeah
<xnox> yet with a new tarball lol.
<xnox> well it does build all flavours including x86 emulator so it's okish.
<rsalveti> xnox: maybe the pkging bzr repo is not in sync with the src package
<xnox> rsalveti: we have a pkging bzr repo? i'm working agains the archive .src packag.e
<xnox> rsalveti: it really ought to be a git repo on phablet with the rest off the code to be honest
<rsalveti> we have but yeah, not in sync
<slangasek> stgraber: which "other half" are breaking the system/service?
<rsalveti> just work against the src package
<rsalveti> xnox: indeed
<rsalveti> xnox: we might want to create another branch/repo in there for the packaging stuff
<slangasek> stgraber: I thought the announcement I sent to u-d/u-d-a last summer was very clear about the migration requirements; have people been uploading packages with upstart jobs without properly transitioning the init scripts?
<xnox> rsalveti: well i kicked off another build, and let me inspect the debdiffs so far.
<xnox> slangasek: duh.
<xnox> slangasek: not me, but i deffo seen just upstart jobs added with nothing done on sysvinit side at all.
<slangasek> sigh
<stgraber> slangasek: the usual breakage is a package having both an upstart and sysvinit job but not having both do the same thing, database servers and anything storing some kind of data in /var/lib may fall into that case
<slangasek> stgraber: there aren't supposed to have been any such packages in Ubuntu; whoever uploaded those packages without fixing the init scripts was negligent
<slangasek> and there's no guarantee that fixing this centrally in the lsb hooks will fix all of those packages, either
<slangasek> because use of the lsb functions interface is optional
<xnox> slangasek: sure but some of these came via syncs, not uploads direct into ubuntu
<slangasek> xnox: so the Debian maintainer was the one violating Debian policy on use of upstart jobs?
<stgraber> slangasek: sorry I don't remember what you sent last summer, but what were you advocating? for people to make sure the logic in the upstart job and the sysvinit script stays in sync so that if the service is started directly from init.d things don't blow up?
<slangasek> stgraber: no; you should never be starting the service directly from init.d
<xnox> stgraber: the policy says that initscript should check if there is upstart running as pid1, and in that case do nothing.
<slangasek> and it was the responsibility of the maintainer to make sure the init script became a no-op
<stgraber> slangasek: sure, I agree and indeed, I don't believe we have anything in the distro doing that
<stgraber> slangasek: my problem is our users
<xnox> slangasek: but that would also break, when systemd is pid1 and upstart is pid2, as the policy checks will succeed on upstart, yet it's not pid1
<xnox> slangasek: and systemd units should be used.
<stgraber> all the bug reports I've seen with /etc/init.d/* breaking stuff isn't because of maintainer scripts or other distro tools but because of users directly poking those
<stgraber> because, well, it used to work back in 12.04
<slangasek> xnox: that's a new problem, and not the problem in 14.04
<xnox> slangasek: ok.
<stgraber> and yes, that's wrong, they shouldn't do that and our documentation tells them not to, but well, they still do and if we can catch a good chunk of those, we should
<xnox> stgraber: "you fight for the user!" =)))))
<slangasek> stgraber: yes, but the only places where this has regressed are maintainers uploading broken packages
<stgraber> xnox: no, I fight for less bug reports :)
<slangasek> stgraber: this is NOT about what the users are doing
<xnox> stgraber: =)))))) _selfish_ ;-)
<slangasek> this is about the *uploader* having done something broken
<slangasek> "I ran /etc/init.d/foo start and it didn't start" -- "so don't do that then"; "I ran /etc/init.d/foo start and it trashed my database" -- "the maintainer did something very wrong"
<stgraber> slangasek: not sure I understand you. If I have a package in 12.04 that ships an upstart job, I can do "/etc/init.d/service restart" and it'll restart the service. Now rebuilding the exact same thing on trusty will call theactual init.d job, not the upstart-job symlink, so now I'm going through an entirely different code path and potentially causing data corruption
<slangasek> stgraber: who's "rebuilding the exact same thing on trusty"?
<slangasek> I don't like talking about this in generalities
<slangasek> what packages are broken?
<slangasek> I think it's fine that xnox will try to fix it for the lsb case by having a common hook, which can either do a pass-through or make the init script a no-op (I don't have a strong preference between the two)
<slangasek> but we need to sort out what packages are now shipping both initscript and upstart job without having been properly transitioned
<stgraber> last example I heard was from rbasak with mysql
<xnox> stgraber: slangasek: i have a branch / thing scanning all upstart jobs, i can add init.d scripts scanning to it and give you a quick way to check.
<slangasek> (and make sure that we catch the non-LSB case)
<stgraber> apparently both the upstart job and the sysvinit script in 14.04 do stuff, they just don't quite do the same thing and there is documentation out there pointing to /etc/init.d/mysql which used to work with 12.04 and now on 14.04 starts a second daemon or something
<slangasek> stgraber: which is clearly neither a sync nor a no-change rebuild; the maintainer is at fault for uploading this package
<xnox> slangasek: stgraber: we had a period of time with broken dh_installinit in debhelper. Can it be at fault here?
<xnox> slangasek: especially if before on ubuntu it would override initd script with a symlink to upstart job, and we stopped doing that?!
<slangasek> xnox: no, the expected new behavior of debhelper is to install both the init script and the upstart job from the package, so that the package works on either an upstart system or a sysvinit system.  The expected behavior of the *maintainer* was to fix the init script before uploading to Ubuntu
<stgraber> slangasek: what is the maintainer supposed to fix? both scripts are fine on their own, it's just if you start mixing both that things go wrong.
<xnox> slangasek: how would maintainer find out about it? surely that's a debhelper compatibility level break.
<slangasek> stgraber: it is *not* fine on its own, the init script is in violation of Debian Policy!
<xnox> slangasek: one simply does not start generating broken packages, based on changed debhelper version =)))))
<xnox> slangasek: and especially when one didn't bump the package to declare compliance with the new debian policy version number.
<slangasek> stgraber: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html
<xnox> let me check default installs here.
<cjwatson> eh, standards-version is purely informational, please don't start getting the idea that things should be keying off it for build behaviour
<slangasek> xnox: all packages must comply with the current version of the policy; the Standards-Version field is advisory
<slangasek> xnox: the way forward here is to land your change in the upstart package to add the lsb hook; but I don't think there's any excuse for uploaders not following ubuntu-devel.
<slangasek> this problem only happened as a result of maintainers uploading new versions of their packages without making the necessary changes to the init scripts
<Noskcaj> mdeslaur, Are you going to update libyaml to the new bugfix release soon? If not, i can. Debian has an NMU fixing a regression too
<stgraber> slangasek: I'd be interested to see an archive wide search for packages shipping both an /etc/init job and an /etc/init.d job of the same name looking for init_is_upstart or "initctl version | grep -q upstart". It's also unfortunate that the policy just says to exit 1 as that tends to confuse the users...
<stgraber> slangasek: the example in the policy also only covers the "start" argument, so if people just started copy/pasting, "/etc/init.d/service restart" has a good chance to cause chaos...
<stgraber> (your e-mail on the other hand properly covers all those cases, it's just unfortunate that this didn't make it to the policy)
<slangasek> stgraber: policy covers that 'restart' must be the equivalent of stop && start
<stgraber> ok, my bad, make that force-reload then
<xnox> ok.
<mdeslaur> Noskcaj: which version are you referring to? AFAIK, I already have the regression fix in trusty...
<xnox> rsalveti: the package builds and the debdiff is reasonable, i'll throught it into virtualised ppa to build as it's too late for me to upload.
<rsalveti> sure
<xnox> rsalveti: uploaded as https://launchpad.net/~ubuntu-toolchain/+archive/android/+build/5832660
<rsalveti> cool, thanks
<xnox> rsalveti: debdiff is smallish - http://paste.ubuntu.com/7127592/
<rsalveti> xnox: yeah, looks fine
<barry> bdmurray: so, the test error seems like a clear bug in the test suite.  i can fix that.  the others seem like a change in semantics somehow about package upgradability.  it's difficult for me to tell why the test assumptions there are incorrect now, so i think i will file a bug (and assign to mvo to give him fun stuff to work on :) and attach my branch that fixes the one problem so far
<bdmurray> barry: I've been digging at it and pkg.is_upgradable seems to be returning different results now
<bdmurray> barry: so then updates_list is a different size
<barry> bdmurray: yep, that's what i've seen too
<bdmurray> barry: well, let me know the bug number
<barry> bdmurray: LP: #1295392
<ubottu> Launchpad bug 1295392 in update-manager (Ubuntu) "test suite failures" [Undecided,New] https://launchpad.net/bugs/1295392
<bdmurray> barry: thanks
<juliank> python-apt 0.9.3.4 is imported in launchpad now. It does fix three other bugs apart from the unicode-revert-stuff (most importantly: pre-build.sh now fails if the mirror lists cannot be downloaded  [e.g. if launchpad is overloaded which happens a lot] instead of simply writing empty files)
<juliank> I'm still a bit unsure about how to request per-package upload permissions as a DD. If someone could enlighten me and tell me what the first step is, that would be helpful?
<juliank> The dynamic-ppu-procedure.txt in Laney's is not well-worded.The first "step" seems to be 10 - aka send an email with list of packages; but 11 says you must have attended a meeting before this, so is there a step before this?
<barry> juliank: probably best to start with an email to devel-permissions@lists.ubuntu.com.  explain that you're a dd maintaining the packages you want upload rights to.  it can *probably* be done over email, but then i'm no longer on the dmb :)
 * barry thinks https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage should really be updated to include laney's text
<infinity> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess has a section for DDs.
<barry> yep, which eventually links to laney's text
<Laney> that is not a guide to be followed
<Laney> I think I mith delete it
<Laney> it was a proposal to the DMB
<infinity> "To exercise this process, the DD should first be an existing Ubuntu developer ..."
<infinity> So, it sounds like one needs to at least do PPU/MOTU/etc once first before getting additional PPU for freee.
<Laney> yes
<infinity> juliank: Anyhow, synced for you for now.
<juliank> Laney: OK, thanks. The first paragraph in https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess linked to your text, and this confused me enough to not read the second one carefully
<Laney> Let me see what it says there
<infinity> juliank: Thanks for paying attention to bugs/patches in both distros.  I know it's a pain sometimes.
<Laney> Hrm
<Laney> Yeah, I added that, lemme clarify
<juliank> infinity: Thanks.
<Laney> I just removed the link, it works without it
<juliank> Laney: OK, yes, much better..
<juliank> !
<juliank> (sorry, the "..." were wrong)
<juliank> When I tried to become a MOTU in 2008 (IIRC), it was rejected, maybe a PPU now works. I did not do that much, as I do most of my stuff on Debian side and have them sync automatically, I mostly appear active on the Ubuntu side during import freeze, to request syncs.
<juliank> I'm trying to copy DeveloperApplication to a place below my user page, but all I get is "Please use the interactive user interface to use action CopyPage!"
<juliank> Well, now it tells me that JulianAndresKlode/DeveloperApplication-PPU already exists. Stupid wiki
<barry> bdmurray: that is very interesting
<bdmurray> barry: yeah, there are lot of changes there though
<barry> bdmurray: so apt 0.9.14.1ubuntu2 works.  does 0.9.14.2 fail?  probably can at least bisect the ubuntu uploads to see which one it starts to fail with
<barry> bdmurray: or maybe even ping juliank :)
<bdmurray> barry: it jumps from 0.9.14 to 0.9.15
<bdmurray> well with some .1s in there
<bdmurray> https://launchpad.net/ubuntu/+source/apt/+changelog
<juliank> There were some changes, APT now switches candidates if the normal one is not satisfiable.
<juliank> I don't know when that was introduced, though.
<juliank> In 0.9.15.1
<barry> bdmurray: i was looking at `bzr branch ubuntu:apt`
<juliank> apt 0.9.15.1 has "discard impossible candidates in MarkInstall", was it in 0.9.15 itself or were you testing with 0.9.15.1 or newer
<juliank> I don't know precisely which versions were synced.
<bdmurray> 0.9.15.1
 * barry was looking at: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apt/trusty/view/head:/debian/changelog
<juliank> Now, if you're trying to upgrade to something impossible, it will not produce an error, but rather switch back to the installed version
<barry> juliank: so it would report pkg.is_upgradable == False?
<juliank> barry: It depends on whether someone called mark_install() or mark_upgrade() on that package in the meantime. Assume: Before, it was true. Now you try to mark an impossible candidate as an upgrade. APT will switch to the installed version. So is_upgradable would be false.
<barry> juliank: okay thanks.  this is all in upgrade-manager's test suite.  we narrowed the failures down to packages which were upgradable but now are not.  it's all test data, so i suspect something there didn't keep up with these changes
<barry> but anyway... it's dinner time for me!
<juliank> OK, and it's time for me to sleep now. It's 50 minutes past midnight.
<juliank> I'll be gone in about 15 minutes and back in about 11 to 12 hours.
#ubuntu-devel 2014-03-21
<stokachu> is there a way to just manually change the version string in a debian/changelog file with dch? basically i can do "dch -v 0.1+git-aaabbb-0ubuntu1" but without loading up the editor and appending a extra * at the end of the entry
<ScottK> mitya57: For the new sip API version it's a transition.  You'll need to rebuild all the packages that depend on the API.  It definitely needs an FFe and please test rebuild everything before you ask because that'll be my first question.
<mitya57> ScottK: Ok, will do
<RAOF> Man I wish our python pretty-printers for STL containers weren't all busted to hell.
<pitti> Good morning
<RAOF> Aloha, pitti!
<pitti> hey RAOF
<RAOF> How does that umockdev sync interact with the STOP THE WORLD!! from phone CI?
<pitti> RAOF: umockdev isn't (I hope) on any image
<infinity> libumockdev0 (from umockdev) is seeded in:
<infinity>   ubuntu-touch: daily-preinstalled
<pitti> RAOF: also, I only read that afterwards
<RAOF> But is in all the CI stuff.
<infinity> That said, you can see my opinion of the stop the line thing in my followup post...
<pitti> RAOF: yes, sure; as I said, the three syncs (postgresql and umockdev) were the first things I did this morning before attacking my mailboxes
<pitti> as yesterday evening they still weren't imported into LP
<pitti> but I fully agree with infinity here
<RAOF> Yeah, I've certainly done similar things in the past.
<pitti> I think we dialed the "no regressions" slider way too far into the other direction now, it's incredibly hard to land anything these days
<infinity> pitti: Yes, ScottK brought that point up nicely.
<RAOF> Oh, *that's* what he meant!
<Mirv> I'd need a packaging ack from a core-dev, ubuntu-download-manager adding a QML plugin http://162.213.34.102/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-download-manager_0.3+14.04.20140321-0ubuntu1.diff
<RAOF> Mirv: = ${binary:Version}?
<RAOF> Ah, we've already decided that ABI is for chumps? :)
<Mirv> good point, that may be too strict
<Mirv> I don't think we've that in others
<RAOF> No, you do have that in others.
<Mirv> thank you, I'll note that on the branch. darn.
<RAOF> The package description isn't consistent with the other ones, either.
<RAOF> But I wouldn't block on that.
<Mirv> it might be of course that the '0' in lib means they aren't really committing themselves to an ABI yet
<pitti> RAOF: umockdev 0.8 just made it into trusty, so happy evemu events recording/replaying :)
<dholbach> good morning
<zyga> doko_: good morning
<zyga> doko_: regarding your question yesterday, how can I reproduce that build failure of bzr?
<pitti> zyga: I get the same failure with
<pitti> $ bzr selftest -v bzrlib.tests.test_email_message.TestEmailMessage.test_multipart_message
<pitti> zyga: in current trusty
<pitti> (with apt-get install bzr python-bzrlib.tests)
<zyga> pitti: thanks
<zyga> pitti: I recall that bzrlib was failing on tests in trunk a while ago (when I looked at bzr3)
<zyga> pitti: but I don't assume that it was packaged without running tests
<pitti> zyga: the package skips a few tests
<zyga> pitti: ok, I reproduce the failure the same way
<zyga> pitti: python 2.7 gets very few changes
<zyga> pitti: so if this worked before (and bzr was updated and ran the test suite) then it must be something python related
 * zyga looks
<diwic> Hmm, after today's updates "unity-control-center sound" crashes with "Settings schema 'com.canonical.indicator.sound' is not installed" and then a SIGTRAP.
<zbenjamin> cjwatson: ping
<pitti> diwic: works here; do you have "indicator-sound" installed?
<pitti> indicator-sound: /usr/share/glib-2.0/schemas/com.canonical.indicator.sound.gschema.xml
<diwic> pitti, thanks. It's not installed here, how can indicator-sound be not installed if ubuntu-desktop is installed?
 * diwic installs indicator-sound manually unless you want to troubleshoot further first
<pitti> it's just a recommends
<pitti> diwic: so I suppose u-c-c now needs a hard depends on it
<diwic> pitti, ah, ok. thanks for the troubleshooting
<pitti> diwic: or the schema needs to go someplace else; I'm not sure which is right (I'm not involved in this), so I think reporting a bug about that and prodding seb128 is a good approach
<diwic> pitti, will do
<tjaalton> is cmocka something that could be more useful and moved to main, or should I drop it from sssd build-depends?
<tjaalton> used for some tests
<pitti> oh, surprising that samba isn't using that too
<tjaalton> probably because of that
<tjaalton> it's in universe
<pitti> should be fairly harmless in main IMHO
<tjaalton> yeah
<tjaalton> I'll add a MIR bug
<tjaalton> sssd isn't there yet either, should fix that before release
<tjaalton> is anyone else having issues with ecryptfs taking ~5min to stop on shutdown?
<pitti> not 5 min here, but can easily take 20 s; not sure if I'm seeing the same
<tjaalton> yeah that sounds normal
<cjwatson> Mirv,RAOF: ABI or not, I tend to think that it's reasonable and appropriate for dependencies within a source package to be (= ${binary:Version}) ...
<cjwatson> zbenjamin: hi
<cjwatson> zbenjamin: (please include content with your pings, it's quicker)
<zbenjamin> cjwatson: ok , just a quick question , can a click package have more than one desktop file?
<cjwatson> zbenjamin: yes, you can have multiple apps in a single click package and each would have its own .desktop file
<Mirv> cjwatson: RAOF: not having it would allow upgrading the library from the source package without upgrading the QML plugin, but I'm not sure if that's useful of course
<cjwatson> zbenjamin: (now, whether stuff in the stack above click all handles multi-app packages gracefully, I can't be certain as I'm not sure I know of any real examples - but we made sure support for this was in the design)
<cjwatson> Mirv: yeah, in general I don't think this is a useful thing to support for different binaries from the same source, though of course there are exceptions
<zbenjamin> cjwatson: ok thank you
<Sweetshark> doko: So about libreoffice-voikko: Cant reproduce that with the libreoffice 4.2.3 prelease I current have from a PPA. It guess it was already fixed by https://gerrit.libreoffice.org/#/c/8368/ for 4.2.2.
<Sweetshark> doko: so should be fine with the next LibreOffice upload.
<Mirv> cjwatson: ok, thanks for your input. not blockin on that then.
<cjwatson> cf.
<cjwatson> $ apt-cache show gir1.2-click-0.4 | grep -m1 Depends
<cjwatson> Depends: gir1.2-gee-0.8, gir1.2-glib-2.0, gir1.2-json-1.0, libclick-0.4-0 (= 0.4.19)
<cjwatson> which I think is spiritually similar
<doko> Sweetshark, ok, let me know when I can retry
<Sweetshark> doko: will do.
<maxiaojun> anyone to look at usb-creator?
<seb128> xnox did some work on it this cycle, why?
<maxiaojun> Erase Disk still broken
<zbenjamin> cjwatson: any idea when we will be able to build in the chroots again?
<xnox> seb128: yeah. I am planning to look into usb-creator today.
<dakira> hi. can you please change the status of LP:729979. It says "Fix Released" but that fix never worked for anyone.
<dakira> This bug affects all users of nvidia binary drivers. It should either be fixed or worked around for 14.04.
<darkxst> dakira, it would be more useful, if you put a comment on the bug, rather than here!
<ScottK> cjwatson: Thanks for taking care of mplayer/arm64.  I just noticed the lack of it was blocking a -proposed -> -release migration and there it was, fixed (I hope) already.
<cjwatson> yeah, turned out to be easier than I'd thought.  I hadn't done it before because gigantic dependency chain and a lot of that wasn't ported until recently.
<rbasak> slangasek, stgraber, xnox: so for mysql-5.5, AIUI it automatically broke when debhelper behaviour changed. No upload was required for that.
<rbasak> When it was brought to my attention I asked about it (at our sprint in London) and understood that it would be fixed by changing the lsb function, so I left it.
<rbasak> So that's one example.
<dakira> darkxst: this bug is being ignored. it was marked "fix released" in february 2013. Since then there have been 40 comments stating that the bug is not fixed.
<cjwatson> doko,xnox: looks like gcc-arm-linux-androideabi needs to be switched from libppl0.12 to libppl-dev; will one of you take care of that?
<dakira> darkxst: I came here as a last resort. My first comment on the bug was in early 2011. This bug makes Unity look broken on all machines that use nvidia binary drivers.
<xnox> cjwatson: i'll do it.
<doko> cjwatson, yes, and remove the isl b-d
<doko> compilers up to 4.7 use ppl, newer ones isl
<xnox> cjwatson: so looking at the command-not-found data which mvo's account is still generating..... It not generating things for trusty, and it's only generating against main-archive, as the account got disabled on the ports machine (or the machine is gone)
<xnox> cjwatson: can we move command-not-found generator to someplace owned by ~ubuntu-archive which happens to have access to the unsplit mirror?
<cjwatson> xnox: it would be simplest to wait for mvo to restart and do it then
<cjwatson> we have time :)
<xnox> cjwatson: true. Ok then. I'll upload a small bugfix, and that's it.
<xnox> (without data update)
<cjwatson> cool, porting mplayer to arm64 cleared 15 uninstallables
<cjwatson> ten more of those ...
<seb128> bdmurray, pitti: can we do anything to get https://code.launchpad.net/~brian-murray/aptdaemon/bug-1266844/+merge/207276 moving forward? it's the most report trusty issue on e.u.c
<pitti> seb128: I'm afraid I don't understand enough what that patch is doing
<pitti> it looks like a bandaid, but doesn't explain the reason *why* the model isn't available
<seb128> pitti, we need mvo back ;-)
<pitti> +1
<pitti> and it's not clear that the program/UI would then behave sensibly after just returning
<ogra_> seb128, one more week, isnt it ?
<ogra_> :)
<seb128> ogra_, yeah, can't wait!
<ogra_> same here :)
<xnox> ogra_: seb128: do we need a blueprint with work-items we'd want mvo to finish by 14.04 release ;-)))))
<xnox> ?
<seb128> ;-)
<pitti> xnox: I'm not sure whether a single BP can hold that many WIs
<xnox> pitti: he can fix launchpad and work-items tracker in one go as well to resolve that bug =)
<pitti> oh, of course!
<pitti> xnox: I keep thinking too small :)
<ogra_> there are only two WIs , arent there ?
<ogra_> fix all click issues
<ogra_> fix all apt issues
<tseliot> pitti: hi, any ideas as to why we haven't updated util-linux? LP: #1012081
<ubottu> Launchpad bug 1012081 in util-linux (Ubuntu Raring) "util-linux needs updating to 2.24.1" [High,Triaged] https://launchpad.net/bugs/1012081
<pitti> tseliot: I poked lamont about it several times
<pitti> tseliot: I think the biggest problem is that the package is incredibly hard to update as there aren't broken-out patches, but there is just a single huge patch in debian.diff.gz
<tseliot> oh...
<pitti> tseliot: I think lamont has some git magic to tell them apart, but I wouldn't know it
<tseliot> pitti: I see
<mdeslaur> cjwatson: are you planning an openssh update to 6.6, or shall I upload the fix for CVE-2014-2532?
<cjwatson> mdeslaur: I have it staged in git already
<mdeslaur> cjwatson: great, thanks
<cjwatson> though thanks for the CVE ref :)
<cjwatson> I'll insert that into my changelog
<mdeslaur> great
<cjwatson> mdeslaur: I'm waiting for translations of the debconf template in https://lists.debian.org/debian-ssh/2014/03/msg00024.html before uploading, at this point
<cjwatson> utlemming,smoser: Do you have any thoughts on the matter raised in https://lists.debian.org/debian-ssh/2014/03/msg00029.html ?
<cjwatson> mdeslaur: (http://anonscm.debian.org/gitweb/?p=pkg-ssh/openssh.git, for future reference)
<mdeslaur> cjwatson: thanks
<utlemming> cjwatson: interesting....from a cloud-image perspecitve, cloud-init would disable that by default for our cloud images, unless the user wants it. Generally, the cloud market is split between allowing and disallowing root logins.
<smoser> cjwatson, will have no affect on us. either way.
<cjwatson> utlemming: Would you do just just by sedding sshd_config, or equivalent?
<smoser> on cloud-iamge boots, cloud-init stuffs the provided ssh key into root's authorized keys, but disables login to it by a ssh key options (gives a message that says 'login as ubuntu')
<cjwatson> utlemming: Or do you mean you're already disallowing root logins anyway?
<cjwatson> Or disallowing password auth to root anyway
<smoser> already disallowing root login. as that.
<smoser> we don't change the root password login
<smoser> so this would then allow the user to get in as root, but there is no root password in the images unless the user has set one.
<cjwatson> OK, so no effect in default configuration.  Thanks
<cjwatson> mdeslaur: If you think this is urgent, I guess I could do 6.6 first and then the root login change in a separate upload
<mdeslaur> cjwatson: not urgent at all, not a big issue
<cjwatson> Right, I didn't think it was too terrible.  Thanks
<cjwatson> (Can't think of any especially horrible env vars that contain "LC_")
<mdeslaur> yeah, me neither
<doko> jamespage, should we sync tomcat8 from unstable?
<doko> cking, could I have some feedback about lp: #1294669 ?
<ubottu> Error: Launchpad bug 1294669 could not be found
<cking> nope, it does not exist :-(
<cjwatson> it does, it's just private so the bot can't see it
<cjwatson> but you filed it so you should be able to :)
<cking> ah, sorry, it does, heh doko, will do, sorry
<doko> cking, ohh, and 4.3-4ubuntu1 is currently building
<cking> doko, unfortunately my history is probably way out of date, I'll try and reproduce it
<Laney> doko: http://people.canonical.com/~laney/weird-things/webkit-preprocessed.xz
<Laney> I just built wk on harris.debian.org & got that for you re: the ftbfs I pointed out yesterday
<doko> ahh, nice
<Laney> you should be able to grab it from my homedir there too if you want
<Laney> to save building it again
<cking> doko, I'm finding it hard to reproduce this issue, where as the day I filed it i could trigger it randomly quite frequently
<jamespage> doko, hmmm
<jamespage> doko, I'd be hesitant; its just going to sit in universe
<doko> ok
<doko> Laney, looks you can avoid that by not passing -fno-tree-dce
<Laney> doko: turning off dead code elimination? what kind of an impact will that have?
<Laney> do you think it's a gcc bug?
<doko> no, turning on
<doko> every ICE is a gcc bug
<Laney> oh, I missed the double negation
<doko> but I miss the background why you turned it off
<Laney> I thought it could have been webkit generating some invalid asm
<doko> just to confirm. you did see this in unstable too?
<Laney> It was built in experimental but I don't think it actually installed any build-deps from there, only unstable
<Laney> and I don't know why it's disabled, let me see if upstream knows
<doko> can't see this with 4.7 and trunk
<Laney> mmm, https://github.com/WebKit/webkit/commit/7678ecfd0590c406e43f1b7b8ab8c923d9bd26ab
<Laney> so compiler bugs, let me see if they filed them upstream
<Laney> bugs without, bugs with, what fun
<doko> -fno-omit-frame-pointer doesn't help for the register pressure
<slangasek> rbasak: no, it broke when 1) debhelper behavior changed, and then 2) somebody reuploaded mysql-5.5 without making the necessary source changes as described in that mail to ubuntu-devel.  In retrospect it seems we were not proactive enough in making sure that job-containing packages did get the necessary init script source changes, and given where we are now the way forward is to fix it centrally as an lsb functions hook
<Laney> the comment there says 'incorrectly compiled operationCallEval'
<doko> Laney, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1295738
<ubottu> Launchpad bug 1295738 in gcc-4.8 (Ubuntu) "[4.8 Regression] unable to find a register to spill in class 'LO_REGS'" [Undecided,New]
<Laney> doko: thank you, will look out for a fix
<cornfeedhobo> hello. I am trying to nail down an issue I am having so I can decide if I should patch this and manually compile, or what.  I am trying to find out if the NetworkManager openvpn plugin has any ipv6 support, and i just dont know how to enable it, or if that is slated for patching soon?
<maxiaojun> xnox: any news for usb-creator?
<cornfeedhobo> there are some chats about a patch available on the mailing list
<jamespage> rbasak
<jamespage> oh - nm
<hallyn> cking: forkstat looks awesome.  relatedly, comment system on your blog site sucks :)  i cannot get the capchas right.
<hallyn> (or, my eyes suck <shrug>)
<cking> oh, yeah, sorry about the capchas, but it gets load of spam otherwise
<cking> the proc connector interface is poorly documented, hopefully the source of forkstat is some help :-)
<hallyn> yes, i think it'll make a big difference in # people looking into it, a good thing
<hallyn> cking: anyway to get it to tell who the fork parent was?
<hallyn> oh heh there it is
<cking> it's all there :-)
<hallyn> just used it to look at that virtmanager bogosity.  I say, WTF!
<ogra_> xnox, i think i asked you already, but forgot the answer, are you working on getting python-apt from the image (we have python3-apt)
<cking> hallyn, that will keep you busy
<xnox> ogra_: yes, but e.g. blocked by blockages. See my latest email in response to asac.
<ogra_> xnox, yes, that remineded me that i wanted to ask you again :)
<xnox> ogra_: yeah, _all_ of it is going, as soon as things land.....
<ogra_> xnox, yeah, as soon as davmor2 is done testing i'll promote an image
<xnox> ogra_: 250?
<ogra_> he is just doing an additional verification test run
<ogra_> yeah
<xnox> ogra_: i don't see new gallery-app on image 250. So no good for me.
<ogra_> i guess 251 will then have it
<cjwatson> ogra_: click uses it to parse framework dependencies, that probably won't go away soon
<cjwatson> ogra_: oh, sorry, that's only python3-apt
<ogra_> :)
<davmor2> ogra_, popey, sil2100: can you have a quick scan over the list other than the scopes that I'm about to start can you see anything else missing?  https://docs.google.com/a/canonical.com/document/d/1VkoSTUStDDPN84rwLztHIgSEK2HlbvXghZDBkBYVxTU/edit#
<davmor2> sorry wrong channel
<ogra_> davmor2, looks good
<cyphermox> cornfeedhobo: it's already in the archive, in trusty
<cornfeedhobo> cyphermox: orly?
<cornfeedhobo> I was just starting to look into how to make a debian style package... i have a patch ready
<cornfeedhobo> cyphermox: huzzah!
<cornfeedhobo> thanks!
<cornfeedhobo> now how should i install just that one package from trusty? can i just dpkg the deb?
<seb128> bdmurray, ev: hey, do you know how e.g https://errors.ubuntu.com/problem/dae59d0805bf3202f10977ead46c964a07bb53be can have 0 report in its trusty column but trusty report in the examples list?
<bdmurray> seb128: looking
<seb128> bdmurray, thanks
<bdmurray> seb128: well at least the first couple are missing Package: info in the report
<seb128> bdmurray, do you know how that can happen?
<bdmurray> seb128: not immediately
<seb128> k
<seb128> thanks anyway ;-)
<seb128> that's probably not on the e.u.c side
<bdmurray> it could be apport, I'd try manually causing a crash in hplip-data
<bdmurray> actually a lot of 13.10 ones are missing them also
<bdmurray> seb128: I setup a crash in hplip-data and my .crash files have the information so I don't really now
<seb128> bdmurray, ok, thanks for looking
<seb128> it's weird, but it seems only that package so no a big deal either
<bdmurray> I know aptdaemon and the release upgrader have their own crash handlers but I don't see anything like that in hplip
<arges> bdmurray: hey. i can start taking a look at the sru queue
<bdmurray> arges: sounds good, no pending stuff today since its friday
<cornfeedhobo> cyphermox: so, that patch seems to deal with not messing up ipv6 routes, which is good, but does not add a tab to the gui to control it
<cornfeedhobo> and it does seem to expose ipv6 capability to all plugins, which is also good
<cornfeedhobo> the gui layout file /usr/share/gnome-vpn-properties/openvpn/nm-openvpn-dialog.ui doesnt even mention ipv6
<cyphermox> no, it doesn't have to
<cornfeedhobo> okay
<cyphermox> it's detected by NM from the capabilities of the VPN plugin
<cornfeedhobo> hmm... let me update the core NM
<cornfeedhobo> is trusy going to be systemd based?
<ScottK> No
<cornfeedhobo> any words on when that transition may start?
<ScottK> Later
<cornfeedhobo> cyphermox: my apologies. the problem appears to be with plasma-nm
<cornfeedhobo> thanks
<cornfeedhobo> i have been trying to narrow this down
<juliank> bdmurray: Did you already find out why the tests with the pkg.is_upgradable are failing?
<bdmurray> juliank: no, not yet
<paulb> Is this the correct channel to get help with creating a ppa?
<stgraber> paulb: nope
<stgraber> paulb: #launchpad maybe
<paulb> K, thanks stgraber
<bdmurray> jamespage: this upload of juju-core looks a bit like a micro release and I don't see a MRE for juju.
<bdmurray> jamespage: this being the one in the saucy proposed queue
<jamespage> bdmurray, I agree that it is bordering on needing a MRE (which I have on my list to apply for)
<jamespage> bdmurray, park it for the moment; I'll work through the linked bugs and do test-cases
<YokoZar> Are archive admins the one to talk to if I want to add a package to the debian import blacklist?
<infinity> YokoZar: Yep.
<infinity> YokoZar: Also helps if you specify what it is, though.
<infinity> YokoZar: (guessing something wine-related?)
<YokoZar> infinity: Please add winetricks there, yeah
<infinity> YokoZar: Seems we've had that all the way back to precise.  Why is it suddenly a problem?
<infinity> (Or was it always, and we just didn't notice...?)
<YokoZar> infinity: I'm readapting the debian package but it needs to fork at this point
<YokoZar> infinity: basically it's going to keep recommending the debian wine package names (eg wine-unstable)
<infinity> YokoZar: Okay, but if you fork it, there's no need to blacklist it.
<infinity> blacklisting only makes sense if we're removing it.
<YokoZar> infinity: err you're right
<YokoZar> infinity: mom won't auto import it
<YokoZar> infinity: which will be good enough
<infinity> Right, go forth and fork.
<YokoZar> actually
<YokoZar> I'm wondering how the debian one got synced on top of ours to begin with
<YokoZar> in precise
<YokoZar> maybe someone did it manually (maybe even me) and I forgot
<infinity> I don't see any ubuntu revisions in precise history.
<infinity> There was one in quantal.
<infinity> And it was indeed you who synced over the quantal delta.
<infinity> https://lists.ubuntu.com/archives/quantal-changes/2012-August/007325.html
<YokoZar> Well it did work at some level.  But now it needs to be in merge mode dropping the debian patches and making changes to the control file (and we may be upstream ahead of debian too)
<YokoZar> Thanks infinity
<infinity> YokoZar: If I were you, I'd just make the package clever enough to DTRT on both distros.
<YokoZar> DTRT?
<YokoZar> do the right thin
<infinity> Do The Right Thing.
<infinity> YokoZar: Since the build-dep is just debhelper, it's obviously only binary and runtime things you care about, and that can all be handled sanely by substituting things in debian/rules based on dpkg-vendor
<YokoZar> I have plans to bring my wine packages to debian/steamos as well (via external apt repo) so it's not a bad idea
<YokoZar> infinity: that's actually a clever idea, I forgot about variable substitutions like that
<debfx> cyphermox: some patches in network-manager rely on TARGET_DEBIAN being defined, however that has been removed upstream: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=012c5f4b271b935852267ed865933ea3bb6983ba
<marrusl> anyone happen to know if there's a PPA with a pre-release version of the HWE trusty x-stack for 12.04?
<tarpman> marrusl: looks like canonical-x/x-staging has something like it
<marrusl> thanks tarpman, I will take a look
<marrusl> tarpman, why I do believe that is exactly it.  sweet!
<ekarlso> can someone tell me why my interfaces in 14.04 are named "rename<some number>" vs em3 and em4 as they should be ?!
<jpds> ekarlso: New scheme.
<ekarlso> jpds: but why the crap does it make it "renameX" instead of em?
<ekarlso> i have a em3 which is the 3rd port on the port which _should_ be em3
<ekarlso> ibstead it's em2 as a kernel name...
<ekarlso> it even ignores my persistent udev rules
<infinity> ekarlso: dmesg should have a bit of enlightenment as to which renames were attempted and why.
<infinity> ekarlso: A persistent scheme that results in loops can sometimes lead to renames getting "stuck".
<ekarlso> nope infinity
<ekarlso> http://paste.openstack.org/show/74048/
<ekarlso> it's freakin' frustrating
<infinity> And what's in /etc/udev/rules.d/70-persistent-net.rules ?
<ekarlso> nothing on the mentioned host
<ekarlso> it doesn't write rules even
<infinity> ekarlso: Is biosdevname in play here?
<ekarlso> I have biosdevname installed ye
<ekarlso> comes with 14.04 as stock it seems
<infinity> Right, so that's where the bug lies, at least.  I'd file one, if I were you.
<infinity> It does look like a logical fail with the rename hitting a loop, but that shouldn't happen in your case, I'd think.
<infinity> Sadly, I don't know much about biosdevname, so a bug would be better to make sure the right person/people see it.
<ekarlso> which udev rule calls it ?
<infinity> ekarlso: It'll be something in /lib/udev/rules.d
<infinity> I don't have it installed here, so don't recall for sure.
<infinity> 71-biosdevname or something.
<ekarlso> well I can't see it there..
<ekarlso> oh, nvm there it is .
<ekarlso> where to report that infinity ?
<infinity> ekarlso: ubuntu-bug biosdevname
<infinity> jtaylor: Man, that python-cffi testsuite takes an impressively long time to run when it doesn't fail. :P
<jtaylor> yes but you only need to run two of them to see the failure
<jtaylor> of the files
<infinity> jtaylor: Well, I just did a full package build to make sure it worked with my local glibc build.
<infinity> jtaylor: The two things you were waiting on were the backport of Siddesh's sin() fixes, and this no-regmove hack, right?  I have both of those staged, just pondering one or two unrelated fixes, but will upload in the next ~24h, so you'll be unblocked before beta freeze.
<jtaylor> I wanted to try and bisect gcc-4.7..4.8 but for some reason every checkout failed to build so I gave up
<jtaylor> yes I only have those two issues on my want-fixed list :)
<infinity> Kay, then I have you covered.
<ekarlso> stupid ass bisodevname
<ekarlso> sucks balls
<jtaylor> thx
<jtaylor> does glibc do bugfix releases?
<infinity> jtaylor: They do point releases, yeah, though we've been amazingly bad about maintaining the stable branches upstream.
<infinity> jtaylor: There's been ongoing discussion over the last month or two about us doing better on that score.
<jtaylor> I think this one would be a good reason to do one
<jtaylor> the sin issue
<jtaylor> wrong math is very bad
<infinity> jtaylor: It's in the stable branch already, it'll make it in .1, if/when Allan decides to cut a release.
<jtaylor> now that I know how to test glibc dev releases I'm going to run the stuff I care about against git head :)
<jtaylor> the ./testrun.sh is quite convinient
<infinity> jtaylor: Yeah, now that we're pretty much caught up with upstream, my plan next cycle is to be doing snapshot builds in a PPA.
<infinity> jtaylor: And if I can get 2.19 to unstable soon, snapshot builds in experimental too.
<infinity> (Should make rebasing patches a bit less painful if we're doing it incrementally instead of in a panic with each new release)
<Noskcaj> Is anyone able to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU
#ubuntu-devel 2014-03-22
<Noskcaj> Ampelbein, cjwatson, xnox, Laney, Riddell, Logan_, mdeslaur, micahg: Are any of you willing to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU
<Noskcaj> You've all sponsored a number of packages for me
<Noskcaj> And i've got over 330 packages that have been sponsored
<alexbligh1> Is there a way of determining what versions of packages WERE in an ubuntu release? I'm looking at a problem with Precise openjdk6 which I think is https://java.net/jira/browse/OPENJDK6-29 and is fixed in upstream b31, and introduced (I think) in b28. We started seeing problems about a month ago with a Precise update so I want to know what the package version in Precise was a month or two ago.
<ogra_> alexbligh1, yes, next to the isos on cdimage.ubuntu.com or releases.ubuntu.com there is always a .manifest file that lists all binary packages included
<alexbligh1> ogra_, thanks. I used the "ssh to every machine that has Precise on but has not been upgraded" method, which is less, um, Precise :-)
<alexbligh1> ogra_, releases.ubuntu.com only seems to have 12.04.4 and cdimages only seems to have the last couple of days. Am I missing something?
<ogra_> what are you looking for ?
<alexbligh1> https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1295987 - I am trying to work out what the shipped version of openjdk would have been on a Precise box which was regularly updated back in Jan. Something in Feb (which I think I have identified) broken openjdk6 quite severely - I think it was the upgrade from b27 to b30, but I need to know the shipping version in around Jan was b27 (and not, say, b28).
<ubottu> Launchpad bug 1295987 in openjdk-6 (Ubuntu) "openjdk6 regression causes finalizers never to be called" [Undecided,New]
<alexbligh1> ogra_, I'm 90% sure of the above, but just want to check my facts
<ogra_> you can look on the precise-changes ML when a specific package was uploaded ...
<ogra_> (or on launchpad)
<alexbligh1> ogra_, ok will do
<alexbligh1> ogra_, LP is perfect, thanks - confirmed the issue
<MrCasper> HI everyone. I recently got my degree in IT and I'm working full time now, but I would like to0.
<MrCasper> contribute by doing some programming for an open source project. And suggestions where would be a good place to start?
<ersi> MrCasper: That's a tough one. Is there anything in specific that interest you extra much? A type of problem or a set of programs or such? :)
<MrCasper> I like solving problems like you see in Google Code Jam. Writing algorithms, that sort of thing
<ersi> Alright. In any specific direction of interest? (Like do you fancy visualization, mapping/geography, data storage or some specific domain?)
<MrCasper> Not particularly
 * ersi puts on thinking cap
<MrCasper> I don't work in IT at the moment so my exposure has been limited to what we did in varsity
<ersi> Any language/tool preferences?
<ersi> (I guess not too strong of a preference there, since you expressed that you particularily liked algorithmic work)
<MrCasper> Nope. I'm keen to learn. Although I have some experience in C++ and a handful in Java
<MrCasper> The problem I've had is before is the difficulty of getting into it. I spent a whole day reading documentation, guides, coding guides etc. that I didn't do any coding
<MrCasper> I want to do this as a hobby so I can't exactly spend a week on it just to get setup
<ersi> Yeah, there can be a lot of that for better or worse
<ersi> I understand that sentiment. It's hard to know how much setup cost there is to contribute to a project though, so you might want to timebox your setup time and perhaps look for another project if it isn't interesting enough until the time comes up.
<MrCasper> Is there a project you can think of that really needs an extra hand?
<ersi> I'm at loss of a really bright idea about where to take a stab at contributing at the moment. But seeing C++ and algorithmic preferences - maybe it's worthwhile pointing you to the Mozilla community as a somewhat good starting point. I frequent #introduction on irc.mozilla.org and see that come up from time to time.
<MrCasper> Thanks , I will check it out!
<ersi> They even got a http://www.whatcanidoformozilla.org/ site :-)
<ersi> Great :)
<kaliko> hi
<pitti> bdmurray: thanks for accepting postgresql-9.1! can I talk you into looking at -8.4 as well?
<kaliko> I'm maintaining a package in debian. Unfortunately the latest version sync in ubuntu contains a critical bug. I know trusty is currently frozen, but how can I eventually have the bug fixed in trusty repository.
<jtaylor> kaliko: depends on if its mixed with other changes
<jtaylor> if debian only contains bugfix on top of ubuntu we can just sync it
<kaliko> It is not the case, a new upstream version is packaged in debian.
<kaliko> But I could fix the version in ubuntu
<jtaylor> you can also go for a feature freeze exception if the new version is not too invasive
<jtaylor> are failing autopkgtests a migration blocker even if they never succeeded?
<jtaylor> unlike for failing builds
<cjwatson> jtaylor: they are right now, though I think we're largely agreed they shouldn't be
<cjwatson> need to fix that
<cjwatson> release team can override
<cjwatson> I can't right now, need to fix a washing machine :-/
<jtaylor> is mixing tk 8.5 and 8.6 a bad idea?
<jtaylor> python-tk is 8.6 while e.g. vtk is still 8.5, so its python bindings might be screwed
<jtaylor> bug 1294927
<ubottu> bug 1294927 in python-numpy (Ubuntu) "python2.7 crashed with SIGSEGV in Tk_CreateWindowFromPath()" [Medium,New] https://launchpad.net/bugs/1294927
<doko> jtaylor, can we build vtk with 8.6?
<jtaylor> don't know
<jtaylor> I don't really want to touch vtk its kind of complicated
<jtaylor> I'm just trying a build to see if it fixes that issue
<jtaylor> nope fails to build
<doko> direct access to the interp struct?
<jtaylor> how much tcl 8,5 do we still have left?
<jtaylor> hm not much
<doko> the worst thing seems to be ruby, which claims that it doesn't work with 8.6. otoh antonio terceiro did mention that nobody uses this ... so could be dropped
<jtaylor> ok got vtk to build with 8.6 and the issue is solved
<jtaylor> but no idea of the thing actually works
<ScottK> jtaylor: Details.
<jtaylor> ?
<jtaylor> oh that it works are details :)
<jtaylor> right building is all that matters ;)
<jtaylor> fwiw it doesn'T work, but neither does what we have in the archive right now
<jtaylor> so probably not so bad
<jtaylor> http://paste.ubuntu.com/7136756/
<jtaylor> also broken in debian,good enough for me to ignore it
<infinity> jtaylor: Looks like it's probably just underlinked?
<jtaylor> yes but not as-needed related
<jtaylor> as debian ahs it too
<jtaylor> looks like the buildsystem is broken (and hasn't worked since at least precise)
<bernardo_> hello!! i have a ask please can anyone help me? its about bash programming
<bernardo_> please can anyone tellme if i can ask here? please!
<Noskcaj> Ampelbein, cjwatson, xnox, Laney, Riddell, Logan_, mdeslaur, micahg: Are any of you willing to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU
 * Noskcaj should probably stop spamming people for testimonials
<bernardo_> i have a problem with fstab!! please help me
<bernardo_> i have this line //servername/sharename  /media/mountname  smbfs  username=guest,password=,uid=1000,iocharset=utf8,codepage=unicode,unicode  0  0 and dont works, when i do a mount /media/mountname i have a line, only root can do that
<infinity> bernardo_: Add 'user' to your options.
<infinity> bernardo_: Assuming you want it to be mountable by users.
<infinity> bernardo_: Otherwise, mount it as root. :P
<bernardo_> but i do that infinity, but i have next line: password: <--- i put the password, but i like what dont do that, and mount error(22):invalid argument
<Noskcaj> Is there anyone who's actively maintaining MATE in ubuntu?
<mdeslaur> Noskcaj: I'll take a look on monday
<Noskcaj> ty
<jtaylor> doko: grr said I didn't want to look at vtk, but did so anyway ..., don't look at the patch its ugly as hell, but works ;)
<Noskcaj> mdeslaur, The meeting is 19UTC on the 24th, just so you know
<doko> jtaylor, nice!
<mdeslaur> Noskcaj: ok
<jtaylor> we also should move plplot to 8.6 that also as python bindings
<Logan_> Noskcaj: MATE is being done in Debian
<Noskcaj> Logan_, I know. I mean keeping the ubuntu packages of it up to date, since some are missing bugfix releases
<Noskcaj> I just put up two minor merges
<Logan_> the actual session support hasn't even been packaged yet, so I'd call that a nonissue, tbh :P
<Noskcaj> ok
<Noskcaj> Any chance of a testimonial Logan_ ?
<Logan_> it's not like you haven't pinged me three times about that already ;P
<Noskcaj> just making sure you heard ;)
<Logan_> how many of your packages have I sponsored?
<Logan_> okay, I've sponsored 30 of yours
<Logan_> okay question
<Logan_> Noskcaj: why did you ask for https://launchpad.net/ubuntu/trusty/+source/mysql-utilities/1.3.5-2 to be synced?
<Logan_> when it explicitly states in the changelog that it added a versioned dependency on python-mysql.connector
<Logan_> did you check which version of python-mysql.connector we had? it's lower than the versioned dependency, and thus the RC change doesn't even affect us
<Logan_> and it clogs up the -proposed for this package
<Logan_> I've seen a lot of problems like this because you've been going too quickly
<jtaylor> doko: you already seem to ahve looked at plplot, can itcl3 be moved to 8.6 so plplot can too?
<Noskcaj> Logan_, that sync was a mistake, sorry
<Logan_> that's why I'm still only comfortable with you being sponsored
<Noskcaj> And that's pretty much the only bad sync i've had this year
<Logan_> there have still been a good number of "mistakes" recently
<Noskcaj> i have to get breakfast, will be back soon
<brainwash> Noskcaj is doing an amazing job, really glad that he helps with the Xubuntu packaging
<doko> jtaylor, no, this was just to get a supported version into the release. didn't look at tcl/tk specifically
<Noskcaj> Logan_, Would you at least give me a testimonial for the xubuntu packageset? All my uploads there have been good, and the two packageset uploads currently have very little time for ubuntu
<infinity> Noskcaj: In my experience, I'm not sure you're ready (yet) to have upload permissions without someone reviewing your work.
<Noskcaj> :(
<infinity> Noskcaj: This isn't a personal insult or anything, just pointing out that you're a bit too quick and not quite careful enough at times.
<Noskcaj> infinity, yep, i agree. I have improved though, and have fixed anything i can. Plus it's either this meeting or the very end of the year
<Logan_> that's more of a reflection on the broken apply-by-email process than on anything else, and you shouldn't use that as an excuse for rushing this
<infinity> Noskcaj: There's no rush here.  If you talk to people I've forced into core-dev in the past (like apw and rsalveti), they were very much keen on having as many reviews of their work as possible before being allowed to go without the training wheels.
<infinity> Noskcaj: Until all your sponsors are of the opinion that you're basically wasting their time because they don't find bugs in your uploads, it's better to have the reviews.
<Noskcaj> ok
<Noskcaj> Although i've had no declined review recently, just things that have been sponsored and are broken
<Logan_> which reflects badly on some of the sponsors who haven't been checking your uploads carefully enough, unfortunately
<Noskcaj> Maybe i'll go back to looking for a debian developer who accepts bribes, since i'm not able to meet one and get a keysigning for something like 5 years
<infinity> Noskcaj: Where do you live?
<Noskcaj> infinity, Australia, 500km from the nearest DD, who lives in an area known for crime. And i'm 15
<infinity> Noskcaj: Where in .au?  There are a ton of DDs there, maybe they're just not advertising. :P
<Noskcaj> infinity, I looked into this. Armidale, new south wales. 500km from any major city
<infinity> Fair enough.
<infinity> (Weird coincidence, I used to live in Armadale, VIC)
<Noskcaj> Why'd you leave?
<infinity> Not enough maple syrup.
<Noskcaj> :)
<doko> ohh, you didn't like the autralian substitute?
<infinity> doko: The Australian substitute is imported Canadian syrup at 15 times the price. :P
<infinity> doko: Also, the Australian substitute for tolerance of sexual preference is constitutional ammendments to ban gay marriage.
<doko> no, there is some spread, forgot the name ... somebody did bring it to UDS'es
<infinity> (It's safe to say that the current political climate in .au doesn't agree with me)
<infinity> doko: Oh, ugh, Vegemite?
<infinity> doko: That stuff is vile.
<infinity> I do miss Anzac cookies, though.
<infinity> Should find a good recipe and get my bake on.
<Noskcaj> doanac, vegemite is easily the worst national food a country has
<Noskcaj> oops, doko
<PabloRDinella> Some1 knows where can I find the official Trusty Tahr mascot emblem?
<Logan_> I didn't realize there was one
<infinity> PabloRDinella: I'm not sure if anyone actually did one.
<Noskcaj> PabloRDinella, http://ubuntuportal.com/wp-content/uploads/2014/03/ubuntu-14.04-mascot.png
 * infinity notes a complete lack of 14.04-related t-shirts in the store.
<PabloRDinella> Exactly that one Noskcaj
<PabloRDinella> But I'm wondering from where did this site and omgubuntu found the image..
<Logan_> PabloRDinella: it doesn't seem awfully official to me, tbh
<Noskcaj> PabloRDinella, I think omgubuntu may have made it.
<PabloRDinella> Hmm, I figured out that this is at the installation screen of trusty..
<PabloRDinella> maybe they remade it over the installation screen image
<PabloRDinella> http://i.imgur.com/qsfIzc6.png I think that the canonical design team make these mascot emblems at closed doors.. btw thks for helping me ;)
<infinity> PabloRDinella: Ahh, okay, so it does exist.  I'm sure we can hunt down the source of that somewhere. :P
<infinity> xnox: ^-- Any idea where the original for the Tahr logo in the installer live?
<PabloRDinella> infinity, this is what I'm was thinking right now :P I'm browsing through the live cd looking for it
<infinity> PabloRDinella: apt-get source ubiquity-slideshow-ubuntu && eog ubiquity-slideshow-ubuntu-79/images-source/ubuntu/tahr_rgb_AW.png
<infinity> PabloRDinella: I suspect that's what you're after.
<infinity> (Sadly, a PNG instead of a vector, but maybe there's a vector version somewhere that xnox knows of)
<PabloRDinella> Haha, I forgot that I was talking to developers, thks man
<PabloRDinella> if we can get the vector I'll be thankful too
<Noskcaj> Ampelbein, bug 1278106 is fixed in debian if you want to try and sync it
<ubottu> bug 1278106 in haskell-llvm-base (Ubuntu) "haskell-llvm-base: FTBFS: configure: error: could not find LLVM C bindings" [High,New] https://launchpad.net/bugs/1278106
<Noskcaj> doko, Since you uploaded to it last, is it worth packaging the new upstream release of jocaml? It allows the package to work with our ocaml version
#ubuntu-devel 2014-03-23
<doko> siretart, there are some packages in -proposed waiting on a newer x264. do you think it's safe to merge, and if yes, the version from unstable or experimental?
<highvoltage> 1/win 12
<kdeuser56> pitti: apport-retrace does not work here on 14.04 if there is no signature for it ...
<kdeuser56> pitti: for the package that crashed i mean
<siretart> doko: I believe x264 should be quite safe. I have no idea why jcristau doesn't approve #738978
<brainwash> there was a request to upgrade the version of xscreensaver, but is has not been approved yet
<brainwash> bug 1283459
<ubottu> bug 1283459 in xscreensaver (Ubuntu) "FFE: Please merge xscreensaver (5.23-1) from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/1283459
<brainwash> can we get it still in or will trusty ship with the same old version (5.15.)?
<brainwash> the new version fixes this (securiy-related) issue -> bug 1229486
<ubottu> bug 1229486 in xscreensaver (Ubuntu) "xscreensaver-command is slow at locking" [Low,Confirmed] https://launchpad.net/bugs/1229486
<j_f-f> Hi..
<j_f-f> which version of libwfmath is planed for trusty? 0.3-6 or  >1.0.0?
<philwyett> http://packages.ubuntu.com/search?suite=trusty&searchon=names&keywords=libwfmath
<infinity> j_f-f: That depends on if https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736315 ever gets sorted out, and if anyone in the Ubuntu community cares enough to validate all the rdeps and get it in.
<ubottu> Debian bug 736315 in src:wfmath "wfmath: Please upload version 1.0 to to satisfy other packages B-D (and fix their RC bugs)" [Serious,Open]
<infinity> Well, I guess the only rdeps are eris and mercator.  So, yeah, if the Debian maintainer sorts it all out, I'm sure we could upgrade.
<j_f-f> infinity: ok and thanks
<j_f-f> I am looking on mercator
<infinity> j_f-f: Your best path forward is to prod that Debian bug and see why there hasn't been any action, I'd say.  If the maintainer just hasn't gotten to it yet, such is life.  If he's been sitting on an upload and awaiting a sponsor or something, I suspect we know a few DDs who could help out.
<infinity> j_f-f: (And I say the best path forward is in Debian, because the Ubuntu upload history for those 3 packages doesn't seem to show a whole lot of interest from anyone in forking and maintaining it in Ubuntu specifically, so better to sort it at the source)
#ubuntu-devel 2015-03-16
<dholbach> good morning
<dholbach> @pilot in
* udevbot 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: dholbach
<seb128> hey dholbach ;-)
<dholbach> hey seb128
<dholbach> can somebody from the release team please take a look at https://bugs.launchpad.net/ubuntu/+source/intltool/+bug/953342?
<ubottu> Launchpad bug 953342 in intltool (Ubuntu) "[ffe] Add support for Qt Designer UI files" [Medium,New]
<dholbach> stgraber, slangasek, tumbleweed, ScottK, Riddell, Laney, Daviey, infinity: ^
<dholbach> thanks
<infinity> dholbach: I'm a bit confused by the bug log there.  Is the qtdesigner stuff a local Ubuntu patch that requires the new upstream or is the support included upstream in the new release?
<dholbach> infinity, the latter
 * infinity notes that MPs for merges are entirely useless, so can't really tell.
<infinity> Oh, wait, dobey is upstream for intltool?  That clears this up a bit.
<infinity> dholbach: Can you grab me a debdiff from current to new, so I can have a quick look at it?
<seb128> isn't that the mp diff?
<infinity> Oh, I suppose so.
<dholbach> infinity, http://paste.ubuntu.com/10608668/ - http://people.canonical.com/~dholbach/tmp/diff
<LocutusOfBorg1> hi all
<infinity> dholbach: Alright, the "new feature" parts of that look reasonably isolated, go for it.
<dholbach> thanks
<Laney> dholbach: Looks like we're in sync
<dholbach> Laney, mh?
<Laney> shall I exp-ise the new upstream release?
<Laney> then carry on syncin'
<dholbach> as you like it
<Laney> I surely do
<dholbach> https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1430893 needs a review from the release team too.
<ubottu> Launchpad bug 1430893 in ubuntu-meta (Ubuntu) "[FFe] Install Fcitx for Chinese users" [Undecided,Confirmed]
<dholbach> I guess with the MIR (https://bugs.launchpad.net/ubuntu/+source/fcitx/+bug/1356222) approved, that should be fine?
<ubottu> Launchpad bug 1356222 in libgooglepinyin (Ubuntu) "[MIR] fcitx and related packages" [Undecided,Fix committed]
<mlankhorst> infinity: hm with xorg-server 1.17 the xserver-xorg pkg has a depends on xserver-xorg-video-all | xorg-server >= 1.17 | xorg-driver-video, but it also has a depends on xorg-server, can that be changed to Recommends: xserver-xorg-video-all | xorg-driver-video?
<dholbach> Riddell: could it be that Aaron's change to ubiquity-slideshow-ubuntu did not make it into lp:ubiquity-slideshow-ubuntu?
<mlankhorst> change is because the xorg-server no longer needs a driver to function since modesetting was moved to the core
<Odd_Bloke> A CVE (and fix) for requests has been released which affects the versions in trusty onwards; is there value in my preparing debdiffs which address it?
<infinity> mlankhorst: I guess that depends on what the intent is.
<Riddell> dholbach: let me check
<infinity> mlankhorst: If you want people to be able to have no driver installed other than modesetting, removing "xorg-server-core (>=1.17)" and making xorg-server-core Provides: xorg-driver-video is probably correct.
<Odd_Bloke> (Or do the security team generally handle such things themselves?)
<Riddell> dholbach: pushed
<dholbach> thanks Riddell
<mlankhorst> infinity: yeah perhaps, but that kills the point of xorg-driver-video..
<infinity> mlankhorst: It does indeed.
<infinity> mlankhorst: Alternately, reintroduce xserver-xorg-video-modesetting as an empty package that just Provides xorg-driver-video and Depends on xorg-server-core (>=1.17)
<infinity> mlankhorst: Makes it more obvious for people to then register their intent.
<mlankhorst> hm probably
<infinity> mlankhorst: And drop the xserver-xorg alternate dep on xorg-server-core as a driver.
<mlankhorst> I think it would be best to depend on = ${binary:Version} then..
<infinity> mlankhorst: Why exact version?  On the off chance that it's removed again? :P
<infinity> Or broken out, rather.
<mlankhorst> dno
<infinity> mlankhorst: But yeah, do what works best, but that general idea seems sane.  You get the "driver" package that way.
<mlankhorst> oke
<infinity> mlankhorst: Also transitions a bit more smoothly for people who were using that package exclusively before, I suspect.
<infinity> Or, certainly more obviously.
<mlankhorst> more obviously, nothing explicitly depends on modesetting in the archive
<infinity> mlankhorst: That does mean that you need to take those Conflicts/Replaces I made you do and change them back to versioned Breaks/Replaces. :P
<mlankhorst> ironic, eh?
<infinity> Quite.
<infinity> No good deed goes unpunished.
<mlankhorst> or maybe just move it back to xserver-xorg-video-modesetting altogether, because why not..
<mlankhorst> we're bumping 2 epochs anyway :p
<mlankhorst> but if I move it back then I do need binary:Version since I can't depend on the normal xsf scripts to take care of it.
<infinity> mlankhorst: If bundled is the "right" way, the empty driver package as a hint seems to work okayish.
<infinity> mlankhorst: But I don't know why it moved in the first place, so can't make an educated guess there.
<mlankhorst> no idea, probably to always have a generic accelerated driver
<mlankhorst> when it moved over support for dri2, glamor, and dri3 was added
<doko> Riddell, any news about the libqinfinity update?
<Riddell> doko: nothing yet, feel free to remove kte-collaborative and libqinfinity if you need to
<doko> Riddell, well, I would demote it to -proposed
<Riddell> doko: demote libqinfinity ? what would that do?
<doko> Riddell, if it's not in the release pocket, then it doesn't block migration
<Riddell> doko: won't it try to migrate together with libinfinity and still fail?
<doko> no
<doko> block-proposed is your friend
<Riddell> ah hah
<Riddell> doko: sure go ahead
<dholbach> @pilot out
* udevbot 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:
 * Laney hugs dholbach 
<Laney> good work
<dholbach> thanks
<brendand_> anyone know if it's possible to write to a file in /run/ from a python script not running as root?
<brendand_> sudo doesn't work of course
<brendand_> attempting sudo -s seems to confuse the interpreter
<infinity> brendand_: What's the use-case?
<infinity> brendand_: If you're running as a logged in user, you probably want /run/user/$UID
<ogra_> yeah
<ogra_> use $XDG_RUNTIME_DIR/<myfile>
<brendand_> infinity, that won't work i don't think - it's autopkgtest, i need to write to /run/adt_reboot_target then run /tmp/autopkgtest-reboot, which i think expects the file to be there
<brendand_> the problem is the rest of the script can't be run as root
<didrocks> brendand_: why do you let autopkgtest-reboot setting the flag itself?
<didrocks> ah
<didrocks> brendand_: well, I doubt /tmp/autopkgtest-reboot will work?
<didrocks> ensure you have autopktest 3.11.1 as well, there is a fix to run autopkgtest-reboot with sudo
<flexiondotorg_> dholbach, Just seen your comment on #1432439
<flexiondotorg_> dholbach, I've checked the new tarball and the relevant file now has the executable bit set.
<dholbach> hum
<flexiondotorg_> dholbach, When I prepared the debdiff it produced what you see. Is it possible to have debdiff include the file attribute changes?
<flexiondotorg_> dholbach, Should I attached ubuntu-mate-settings_0.4.4-1.tar.gz to #1432439?
<dholbach> we already have ubuntu-mate-settings_0.4.4.tar.xz
<dholbach> maybe call it ubuntu-mate-settings_0.4.4.1.tar.xz or ubuntu-mate-settings_0.4.5.tar.xz?
<flexiondotorg_> dholbach, I can change the version. No problem.
<flexiondotorg_> dholbach, Should I attached the revised debdiff and tarball to the bug?
<dholbach> yeah, it's because ubuntu-mate-settings_0.4.4.tar.xz is alrady known to the archive and we can't just change it
<dholbach> maybe the tarball, yes
<flexiondotorg_> dholbach, I've attached a new debdiff for 0.4.4.1 and the corresponding tarball.
<didrocks> smoser: mvo_: hey, I'm using the alpha2 core image with snappy, each snappy commands ask for "Reboot to use the new ubuntu-core.". Note that I didn't upgrade anything, and that, even after rebooting
<didrocks> I then tried to upgrade ubuntu-core (to 145), reboot, snappy versions shows the new version is the current one, but I still have the reboot message
<mvo_> didrocks: its a known bug :/ if you have a3, please try snappy-go, it should be much better. or use a daily
<mvo_> didrocks: yeah, the reboot message is a known bug, its fixed in snappy-go
<mvo_> didrocks: are you using that on a arm system?
<didrocks> mvo_: is there a link to alpha3 ubuntu core image (only got alpha2)?
<didrocks> mvo_: no, I'm running amd64 for now
<didrocks> but I'm happy to switch to whatever is latest and available
<didrocks> ah, I guess http://cdimage.ubuntu.com/ubuntu-core/releases/alpha-3/ (doesn't follow the other naming schemes)
<mvo_> didrocks: best is probably to just use a daily via ubuntu-device-flash
<mvo_> didrocks: but a3 is a step forward, the pace is very very fast, daily is really the best to see where we are
<didrocks> mvo_: do you have an handy recipe to go from ubuntu-device-flash daily tar.gz to a .img?
<didrocks> seems to be "ubuntu-device-flash core", giving it a try
<dholbach> flexiondotorg_, uploaded
<flexiondotorg_> dholbach, Many thanks!
<didrocks> mvo_: seems to work, thanks! Looking a little bit more in the command difference with snappy go now
<mvo_> didrocks: https://lists.ubuntu.com/archives/snappy-devel/2015-March/000334.html <- that might be helpful for that
<didrocks> mvo_: excellent, thanks!
<mvo_> yw
<doko> jamespage, MIR for django-nose needed (horizon)
<jamespage> doko, hrm thats odd
 * jamespage looks
<jamespage> doko, looks like the django bump to 1.7 makes the message compilation for horizon need all dependencies, irrespective of whether they are used or now
<jamespage> raising MIR now
<jamespage> doko, its been in main in the past - https://bugs.launchpad.net/ubuntu/+source/django-nose/+bug/981100
<ubottu> Launchpad bug 981100 in django-nose (Ubuntu) "[MIR] python-django-nose" [Undecided,Fix released]
<jamespage> doko, I can re-do the mir but the package lgtm - still executes test etc... - it was pretty light touch from memory
<doko> jamespage, no, that's fine then
<doko> mvo_, apt boottest regression
<mvo_> doko: the adt test?
<doko> yes
<doko> jibel: some autopkg test failures seen due to qemu issues. is this known? already asked sbeattie who did the last upload
<mvo_> doko: thanks, I noticed the mail I need to dig into what went wrong
<jibel> doko, do you have an example?
<doko> jibel, kstars and marble
<jibel> doko, latest run of kstars failed because debian/tests/testsuite.xsession: 5: debian/tests/testsuite.xsession: dh_auto_test: not found
<jibel> missing dependency maybe
<jibel> doko, and last successful run of marble was Oct. 29th. Same test is failing and same failure mode.
<jibel> doko, you're talking about autopkgtest in vivid, right?
<doko> jibel, yes
<jibel> doko, so yeah, nothing in these 2 examples is related to a recent upload of qemu
<doko> jibel, I'll try to fix that.
<doko> ScottK, Riddell: are you aware of the marble autopkg test failure?
<hallyn_> stgraber: bleh, bug 1432683 presumably requires some systemd-fu
<ubottu> bug 1432683 in lxc (Ubuntu) "apt-get install lxc doesn't load required apparmor profiles" [Undecided,New] https://launchpad.net/bugs/1432683
<doko> kenvandine, ping on the libdbusmenu and signon-ui ftbfs ...
<seb128> hallyn_, hey, just checking if you saw that you got subscribed on bug #1427264 for feedback (no hurry to reply, it was to verify that the email reached you rather than going in some launchpad spam box)
<ubottu> bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] https://launchpad.net/bugs/1427264
<tyhicks> thanks seb128 - pinging serge was on my todo list today :)
<seb128> tyhicks, hey, yw :-)
 * hallyn_ cringes - why am i being subscribed?
<hallyn_> hm.  i probably was subscribed but i hadn't noticed.  will look in a bit, thanks
<hallyn_> tyhicks: i'll ping you after i digest it, thx
<seb128> hallyn_, thanks :-)
<tyhicks> hallyn_: I subscribed you, rather than pinging you directly on IRC, since it wasn't urgent
<kenvandine> doko, sorry, we should get tedg to look at libdbusmenu and mardy for signon-ui
<tedg> I think that bregma was looking at the dbusmenu one, not sure how far he got.
<bregma> yeah, I did the other ones but still need to look into why the libdbusmenu tests are hanging during the build
<bregma> bug #1429291
<ubottu> bug 1429291 in libdbusmenu (Ubuntu) "FTBFS on Ubuntu Vivid due to hang in test-json-instruction" [Critical,Triaged] https://launchpad.net/bugs/1429291
<bregma> nothing to do with GCC 5
<bdmurray> stgraber: could you verify bug 1422345?
<ubottu> bug 1422345 in unattended-upgrades (Debian) "stop being nice does not work" [Unknown,New] https://launchpad.net/bugs/1422345
<stgraber> bdmurray: doing now
<doko> mardy, ping on signon-ui
<flexiondotorg_> seb128, Regarding daily-images.
<flexiondotorg_> seb128, Confirmation from Xubuntu that they have the same issue.
<stgraber> bdmurray: tested and tags updated, feel free to release
<kenvandine> doko, is there a bug filed for signon-ui?
<kenvandine> mardy is probably eod, so if there's a bug just assign it to him
<bdmurray> stgraber: great, thanks!
<seb128> flexiondotorg_, k, good to know, and that started on the 15?
<doko> kenvandine, I have now, yes. lp #1432711
<ubottu> Launchpad bug 1432711 in signon-ui (Ubuntu Vivid) "signon-ui fails to build in vivd" [High,Confirmed] https://launchpad.net/bugs/1432711
<flexiondotorg_> I can only go back to 15.
<flexiondotorg_> seb128, So I don't know it is was broken prior to the 15th.
<kenvandine> doko, thanks, i assigned it to mardy
<flexiondotorg_> seb128, In case you missed my comment in #ubuntu-desktop
<flexiondotorg_> seb128, There is an error about pwconv not being able to set the permission of /etc/passwd- to 0600
<seb128> flexiondotorg_, I saw it
<seb128> but good to repeat here
<seb128> it's a more suitable channel for installer issuers
<seb128> issues
<flexiondotorg_> seb128, elfy just posted this in #ubuntu-release
<flexiondotorg_> seb128, elfy> good day - really not sure if this is even the right channel to bring these things, but xubuntu daily today, lubuntu and flexiondotorg_ says mate all failing to get far in to a boot, complaining of pwconv not being able to set the permission of /etc/passwd- to 0600 http://i.imgur.com/KaKMeIa.png
<flexiondotorg_> When did the new Xorg land in 15.04?
<flexiondotorg_> Because Xorg is reporting no screens found on the current daily image.
<doko> jamespage, ping on https://bugs.launchpad.net/ubuntu/+source/python-sysv-ipc/+bug/1399581 what is the status? asking because the version in the release pocket ftbfs
<ubottu> Launchpad bug 1399581 in python-sysv-ipc (Ubuntu) "[MIR] python-sysv-ipc" [High,New]
<flexiondotorg_> infinity, I'm looking into the daily image bug.
<jamespage> doko, looking now
<flexiondotorg_> See above for my questions about Xorg.
<infinity> flexiondotorg_: Ta.  Let me know if you find a scapegoat.
<jamespage> doko, I'd better get onto that
<infinity> flexiondotorg_: xorg migrated on the 12th.
<flexiondotorg_> infinity, Xorg logs show many drivers failing to load.
<elfy> re the issue that flexiondotorg_ is seeing with Mate daily, seeing same here on Xubuntu and I grabbed Lubuntu to check, same issue, pastebin of xorg.0.log which is throwing a bunch of errors it seems - http://pastebin.ubuntu.com/10610592/
<doko> didrocks, can the two remaining packages in https://bugs.launchpad.net/ubuntu/+source/fcitx/+bug/1356222 be promoted?
<ubottu> Launchpad bug 1356222 in libgooglepinyin (Ubuntu) "[MIR] fcitx and related packages" [Undecided,Fix committed]
<flexiondotorg_> Changelog is interesting too.
<flexiondotorg_> http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg/xorg_7.7+7ubuntu3/changelog
<flexiondotorg_> * Modesetting has been removed, remove from vars.
<Laney> Looks like a load of drivers dropped out of the image
<didrocks> doko: yeah, doing it now
<infinity> Laney: If drivers dropped out of the image, I think what mlankhorst and I were discussing earlier might fix that.
<Laney> Righto
<infinity> But, indeed, it looks like xserver-xorg-video-all has fallen out of all the desktop seed because of the whacky xserver-xorg-core alternate dep that shouldn't be there.
<infinity> mlankhorst: Were you going to fix that today, or should I implement the thing we discussed?  Seems more urgent than we thought.
<Laney> Well, you guys have been looking at this already, so take this here baton from me
<Laney> virt-manager continues to work. :)
<doko> ScottK, Riddell: kstars autopkg test fixed ... marble remains ...
<Riddell> doko: when I asked marble upstream they said it was flakey and to be ignored
<Laney> So delete the test?
<Riddell> upstream likes to keep it I guess
<Laney> The autopkgtest
<mlankhorst> infinity: thought it could have happened, bleh I'll look at it later this evening..
<doko> Riddell, well, they can keep it, but then please carry a patch to disable it
<mlankhorst> I'm probably going to move modesetting to being separately again..
<infinity> mlankhorst: Kay.  Whatever you're going to do, it should happen soon, cause all the images are broken right now. :P
<lefteris> hello, i am encounter a problem. i have two packages in ours repository and i want to merge these packages into one
<cjwatson> Riddell: You could always have it report the output but ignore failures from that test, if the output is useful to upstream.
<Riddell> doko, cjwatson: ack
<Riddell> will investigate
<lefteris> i try with conflict, replace, provide but update-manager in ubutnu 12.04 proposes a partial upgrade?how can do this without proposing partial upgrade?
<infinity> lefteris: For package A taking over package B, you just want A to conflict/replace B, unversioned.  The rest should happen via magic, usually.
<lefteris> infinity: to be more specific, already in ours repository exists, package A that depends on package B
<lefteris> i want to redistrubute a new one with tha name of package A (merge the two packages)
<doko> tumbleweed, can we have python-cffi 0.9.2 please?
<infinity> lefteris: Right, so the new A can't depend on B anymore, and should conflict/replace B.
<infinity> lefteris: Assuming nothing else depends on B.
<infinity> lefteris: If other things depend on B, you need to also provide B.
<infinity> lefteris: If other things have *versioned* deps on B, you're out of luck, cause 12.04's dpkg doesn't support versioned provides.
<lefteris> infinity: nothing else depends on B, but then package B still remaining to the system. right?
<lefteris> but is orphaned so with apt-get purge --auto-remove, the package B should removed
<lefteris> can i  send a package A update that upgrades already installed package A and removes package B?
<infinity> lefteris: Yes, if the new A doesn't depend on B anymore, and declares a Conflicts/Replaces against B.  Like I said.
<doko> didrocks, is there a new gnome coming soonish?
<didrocks> doko: we don't really track latest version of gnome for a long time already. So, apart if the ubuntu gnome flavor has some particular applications/components they want latest, if it doesn't break unity and there is a FFe, I would say no
<mlankhorst> Eigen berichten
<doko> thanks
<lefteris> infinity: thanks, conflicts/replaces works with dist-upgrade, but why update-manager still popup partial upgrade?
<infinity> lefteris: A bug, if it does.  It's supposed to have code to special-case that the same way apt does.
<infinity> lefteris: Or your packages aren't exactly as you described them.  Hard to say without seeing all the control files.
<cjwatson> I only added that C+R logic in 13.04's update-manager.  If it's an upgrade within 12.04, rather than an upgrade from 12.04 to 14.04, it probably won't honour that.
<infinity> cjwatson: Oh, was it that recently?
<infinity> cjwatson: Seemed longer ago.
<infinity> lefteris: There's your answer, then.  12.04's update-manager just plain doesn't support package takeovers of that sort.
<cjwatson> Yup.
<infinity> lefteris: The other option is to make an empty package B that depends on package A, and make A have a versioned Breaks/Replaces on B (<< version_where_you_did_that)
<mlankhorst> infinity: I think I'll just degrade xserver-xorg-video-all | xorg-driver to recommends, saves me from reviving modeset :P
<infinity> mlankhorst: Err, how does that help?
<infinity> mlankhorst: The problem right now is -core being in the alternate list.
<mlankhorst> infinity: yeah and lowering it to recommends means I can remove xserver-xorg-core from the alternate list
<infinity> mlankhorst: Because core is installed anyway, that means germinate ignores xserver-xorg-video-all, and it goes byebye.
<lefteris> infinity, cjwatson: thank you very much for the help
<infinity> mlankhorst: I'm not sure I follow, but okay.  I thought the whole point was to guarantee people had at least opted to have one driver installed.
<mlankhorst> infinity: yes and modesetting is a driver
<infinity> mlankhorst: I guess with core providing a driver, you can pretend they made that choice always now, but...
<hallyn_> slangasek: hi, jessie needs another cgmanager update - do you have time to take a look at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u2.dsc ?
<slangasek> hallyn_: not for the next couple of days at least
<hallyn_> slangasek: ok, thanks
<hallyn_> jamespage: are you dd?
<hallyn_> jamespage: would you be able to sponsor http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u2.dsc ?
<lefteris> infinity: I also try the above solution with the dummy package B but then, package B never become orphaned (i also try the oldlibs section but with no success)
<infinity> lefteris: No, it won't become orphaned, but it's also wasting little space, so who cares really.
<infinity> hallyn_: I was about to offer, and then I started auditing.  That's a hefty set of patches.
<infinity> hallyn_: How long has this been in sid/vivid, how well tested, what level of confidence do you have in the backports, can I hit you if it's all wrong and I get yelled at for sponsoring? :P
<lefteris> infinity: yeah you are right (just 24kb)... ok... again, thank you very much
<hallyn_> infinity: they've been in sid and vivid for about a month
<jamespage> hallyn_, I'll leave you in infinity's capable hands...
<doko> mlankhorst, ping on #1428083
<infinity> hallyn_: Well, it all looks vomitously insane, which I think I expressed the first time we talked about it, but it looks like it does what it says, and a month of battering in vivid gives me some confidence.
<hallyn_> infinity: it is somewhat insane, insane enough that i thin kit's worth some time to brainstorm better kernel support fo rthis sort of thing
<smoser> systemd kknowledgeable person able to advise ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1432758
<ubottu> Launchpad bug 1432758 in cloud-init (Ubuntu) "cloud-config.service, cloud-final.service do not run if previous cloud-init service failed" [Undecided,New]
<infinity> hallyn_: Just build testing and I'll toss it up.
<mlankhorst> infinity: uploaded a fix for xorg
<mlankhorst> bug 1428083
<ubottu> bug 1428083 in python-ttystatus (Ubuntu) "MIR: cmdtest, python-cliapp, python-ttystatus, python-coverage-test-runner" [Undecided,Incomplete] https://launchpad.net/bugs/1428083
<hallyn_> infinity: if problems do crop up then i guess it'll be time to just not use a separate mount ns, and try to reuse mouns at startup - but that has its own problems ,sadly
<infinity> mlankhorst: Ta.
<mlankhorst> oh oops :P
<mlankhorst> I guess that was the bug attached
<hallyn_> echo "$(date -d "$*" +%Y-%m-%d) infinty" >> ~/gtd/owe_a_beer
<infinity> hallyn_: Your debian/libcgmanager0.symbols is out of date, BTW.
<infinity> hallyn_: Feel like fixing that to actually be accurate before I upload this?
<hallyn_> feh
<hallyn_> will do.  always akes me awhile, will ping you when done
<infinity> hallyn_: (I find it's best to hard fail on additions too, so you actually get proper shlibdeps)
<infinity> hallyn_: It's easy by hand, if you know when the cgmanager_list_keys* symbols appeared upstream.
<hallyn_> can that be done in debian/rules?  (hard failing on additions)
<infinity> hallyn_: Yeah, see check levels (-c) in dpkg-gensymbols(1)
<cjwatson> dh_makeshlibs -- -c4
<cjwatson> (is the strictest form)
<infinity> hallyn_: Or crib from Colin.
<hallyn_> weird that i had added the other two symbols which were added in the same version
<hallyn_> cjwatson: thx
<hallyn_> k i should do the analogous change for sid then
<hallyn_> infinity: new version uploaded to mentors, though it usually takes a minute or two to actually show up there
<hallyn_> (show up there updated)
<infinity> hallyn_: Sure, just toss me the .dsc URL for both sid and jessie when they're ready.
<hallyn_> infinity: d'oh, i'd already done that in sid
<hallyn_> jessie's sslow release is just messing with me
<hallyn_> infinity: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u2.dsc is updated
<doko> jamespage, ceph regression, resulting in a broken ARM qemu: lp #1432786
<ubottu> Launchpad bug 1432786 in libguestfs (Ubuntu Vivid) "upgrade of ceph in vivid breaks qemu-system-arm" [High,Confirmed] https://launchpad.net/bugs/1432786
<gQuigs> do I need to request something else for https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1408478,  or will it be demoted from main by some automatic mechanism?
<ubottu> Launchpad bug 1408478 in libpam-ldap (Ubuntu) "Removal Request: Move to universe from main" [Medium,Fix committed]
<gQuigs> (other items at fix committed in the same repo, are already affecting the distro..)
<infinity> gQuigs: libpam-ldap and libnss-ldap are both awaiting demotion.
<gQuigs> infinity: thanks for checking!
<infinity> and ldap-auth-client too.
<infinity> I'll do all three now.
<gQuigs> infinity: awesome, thanks!
<seb128> cyphermox, do you know why "sudo start bluetooth" doesn't return on upstart/vivid? (doing a stop before)
<seb128> is the upstart script buggy?
<smoser> anyone able to confirm or refute this for me ..
<smoser> it seems that initramfs in vivid is not copying /run from initramfs into the root's /run
<smoser> where it previously did
<melodie> hello
<infinity> smoser: It hasn't changed, but it's possible that systemd is taking it upon itself to wipe /run or remount a fresh one or something.
<cyphermox> seb128: buggy I guess; but do you mean vivid on desktop or vivid on the phone?
<smoser> i think it must be.
<seb128> cyphermox, either
<cyphermox> seb128: I think I say that sudo start bluetooth on the phone would break because the bluetooth init jobs need to improve a lot
<cyphermox> I don't know why it would hang on desktop
<seb128> cyphermox, ok, I was trying to add a script that "start on started bluetooth" and call hciconfig but that doesn't work ...
<cyphermox> oh, but on desktop-next you would have some of the jobs from the phone
<seb128> cyphermox, it's not desktop next, it's standard vivid desktop
<cyphermox> I wouldn't know
<cyphermox> it's definitely supposed to return
<seb128> cyphermox, no worry, I was asking in case, thanks
<arges> smoser: howdy
<cyphermox> check any other scripts that start on starting bluetooth
<seb128> cyphermox, on starting doesn't sequence though right? they could start before the bluetooth service is working?
<arges> smoser: looking at bug 1431473, can't seem to reproduce on this end. Why are you guys using some frankenstein core2duo + vmx machine type?
<ubottu> bug 1431473 in linux (Ubuntu Vivid) "kvm_intel (nested) module will not load [Input/output error]" [High,Confirmed] https://launchpad.net/bugs/1431473
<smoser> arges, well, thats openstack in both cases doing the host.
<arges> smoser: : ) fun. Ok, yea i think joe's comments about getting the XML might help us to isolate this. if we can repro here it will be easy enough to bisect and figure out what changed.
<smoser> and oddly, rbasak said it reproduced for him on canonistack. where i had been unable to see it beofre, but i had a system that had a xeon there. (as seen in my report's cpuinf)
<smoser> yeah, and we can get host spuc and kernel information too.
<arges> smoser: cool. thanks for bringing that up.
<arges> *filing the bug that is
<Unit193> darkxst: Pingaling.
<smoser> infinity, https://bugs.launchpad.net/ubuntu/+bug/1432821 if you were wanting to take a guess :)
<ubottu> Launchpad bug 1432821 in Ubuntu "something deleting /run/network after during boot" [Undecided,New]
<smoser> xnox, maybe ?  anyone have ideas on what might be removing that directory ?
<darkxst> Å­
<smoser> stgraber, you're my resident resolvconf expert for bug 1432829
<ubottu> bug 1432829 in resolvconf (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [Undecided,New] https://launchpad.net/bugs/1432829
<daniel_> file:///home/daniel/textedit.py
<darkxst> Unit193, hi
<daniel_> Whut is in 15.04
<stgraber> smoser: haven't touched resolvconf in a long time and I'm not sure how to debug the systemd side of this
<stgraber> smoser: what seems odd is that you're using both ipconfig and dhclient, typically dhclient and ifupdown get pretty unhappy when the interface is already configured, so maybe ifupdown is actually failing to bring the interface up (or never triggered by systemd somehow). In the past it could be that timing meant that our resolvconf upstart job would fix things up for you, but doesn't anymore with systemd.
<doko> does an architecture option work in a binary all package?  Depends: not-available-here [armhf] ?
<doko> Riddell, ScottK (and maybe cjwatson): can't figure out why libkdeedu doesn't migrate
<cjwatson> doko: arch option / binary all> no, arch options like that work by dpkg-gencontrol processing them at build time, which can't work for arch all
<cjwatson> doko: that seems clear enough, it depends: kdelibs5 (>= 4:14.12.3) and vivid has 4:4.14.6-blah
<cjwatson> doko: 14 > 4
<Riddell> hmm that'll be a hardcoding mistake
<doko> oops, to blind .. time to call it a day today. Riddell, can you fix?
<Riddell> doko: si, manaÃ±a
<tumbleweed> doko: yes. Been travelling, but I'll look at it
<melodie> good night
<basic`> hi there, I'm one of the maintainers of http://ftp.drupal.org and we've noticed loganberry.canonical.com and breadfruit.canonical.com appear to be crawling the entire tree of Drupal projects.
<basic`> does anyone know what this would be?
<ScottK> basic`: You probably want #canonical-is (I think it is).  No one here is likely to know.
<basic`> ScottK: thanks!
<basic`> ScottK: nobody in there, another network ?
<Unit193> -sysadmin
<basic`> thanks!
<ScottK> That was it.
<ScottK> Thanks Unit193
<Unit193> Sure.
#ubuntu-devel 2015-03-17
<murphyslawbbs> Hi there.. I'm hitting this bug "https://bugs.launchpad.net/uvtool/+bug/1408833" which comes with a proposed fix to install a kernel "linux-image-3.18.0-14-generic_3.18.0-14.15+lp1408833_amd64.deb", but on installing that kernel on my utopic (kernel 3.16.0-31-generic) it fails to boot. should I update my system to unstable or testing first? Also, what are the unstable or testin trees on ubuntu? More used to debian...
<ubottu> Launchpad bug 1408833 in AppArmor "broken postinst test for uvtool-libvirt on utopic" [Undecided,Confirmed]
<sarnold> murphyslawbbs: there's the -proposed pocket, but it shouldn't be needed..
<murphyslawbbs> sarnold: hmm so why does the contributor propose a 3.18 kernel while uptoic is at 3.16?
<murphyslawbbs> *utopic
<murphyslawbbs> i was gussing that he was using a different "kind" of utopic
<sarnold> murphyslawbbs: probably because serge reported that he could reproduce the issue with the 3.18 kernels
<murphyslawbbs> sarnold: that makes sense, thanks
<sarnold> murphyslawbbs: the kernel team has a huge pile of upstream kernels ...
<sarnold> murphyslawbbs: it might be worth testing the 3.18.xxx kernel that that was based on, without the fix, to see if that also fails for you
<murphyslawbbs> sarnold: i just built a new 14.10 on different hardware and that one didnt crash
<murphyslawbbs> sarnold: good idea ill try that
<sarnold> murphyslawbbs: aha, see this for details https://wiki.ubuntu.com/Bugs/Upstream/kernel
<dholbach> good morning
<mvo> didrocks: \o/
<didrocks> mvo: ;)
<didrocks> pretty basics things, but hope this helps
<mvo> didrocks: still nice
<jamespage> doko_, do you have an arm enabled PPA that I can test a fix for that ceph issue in?
<mauricfo> cyphermox, hey :) u around?
<mauricfo> cyphermox, I see you uploaded the d-i multipath handling changes.. thanks a bunch.
<rbasak> arges: I still have the machine on canonistack that has the issue. I can give you access to it if it'll help? You can destroy the machine testing it as much as you l ike.
<mauricfo> I don't know what's the d-i / daily image build process/frequency there.. the 'pending' daily image doesn't yet contain the changes.   I'll soon be asked of when there will be one w/ the changes.. Do you happen to know?
<cjwatson> mauricfo: It's daily; that change just missed the last one.
<mauricfo> cjwatson, ah ok :) i wasn't sure about that.  thanks for confirming, colin
<cjwatson> mauricfo: The crontab is at http://bazaar.launchpad.net/+branch/ubuntu-cdimage/view/head:/etc/crontab
<cjwatson> mauricfo: "29 6 * * * for-project ubuntu-server cron.daily --live" is probably the line you mean
<mauricfo> cjwatson, great to know. details :)
<ogra_> slangasek, looks like your seed change was badly timed or something still depends on ttf-punjabi-fonts in the image ... the desktop builds failed this morning
<flexiondotorg> infinity, seb128 I was discussing the daily images being a bit broken with your both yesterday.
<flexiondotorg> infinity, seb128 Still have the same issue with todays daily images :(
<seb128> flexiondotorg, no wonder, if bugs are not fixed they don't automagically go away...
<flexiondotorg> infinity, seb128 Despite the xorg revision - http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg/xorg_7.7+7ubuntu4/changelog
<infinity> flexiondotorg: Well, depends on which problem you're talking about.
<infinity> flexiondotorg: The newer xorg should have gotten drivers back.
<infinity> Except that some/many flavours aren't building because some font mess happened...
<infinity> How did that happen?
<Laney> mate got the drivers
<infinity> Laney: Anyone desktoppish looking at the fonts-guru/ttf-indic-fonts versioned Breaks mess?
<flexiondotorg> infinity, http://paste.ubuntu.com/10615071/
<Laney> robert_ancell was guiding the fonts-* situation
<doko_> infinity, Laney: mterry asked for providing transitional packages
<infinity> flexiondotorg: I'm not much of an X guy.
<flexiondotorg> infinity, I do not think the issue with Ubuntu MATE is font related. The image doesn't include the troublesome fonts.
<infinity> flexiondotorg: What driver would you normally expect it to load?
<flexiondotorg> infinity, OK. I'm happy to help resolve this.
<flexiondotorg> infinity, Well, this is booting in a VBox. So vesa probably.
<flexiondotorg> infinity, Can you point me at the right people to discuss this with?
<flexiondotorg> I'm happy to help with providing logs etc.
<infinity> flexiondotorg: mlankhorst or tjaalton, probably.
<Laney> https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1432899 ?
<ubottu> Launchpad bug 1432899 in xserver-xorg-driver-vesa (Ubuntu) "VESA error: Cannot read int vect" [Undecided,New]
 * flexiondotorg goes to read #1432899
<mlankhorst> Laney: does reverting that commit help?
<Laney> Dunno
<Laney> Ask that guy â
<mlankhorst> meh, I'll try in a vm..
<flexiondotorg> Laney, mlankhorst #1432899 correctly describes the issue I am seeing in VirtualBox. I've added my feedback/logs to the issue.
<flexiondotorg> mlankhorst, If you need any additional logs/testing just let me know.
<mlankhorst> flexiondotorg: are you comfortable rebuilding xorg-server?
<flexiondotorg> mlankhorst, I imagine I can ask a PPA to do that right?
<mlankhorst> yeah else just a sec..
<xnox> pitti is not here
<xnox> =(
 * xnox throws a tantrum
<Odd_Bloke> xnox: On holiday this week, IIRC.
 * smoser throws same tantrum as xnox
<smoser> and in pitti's absense, bothers xnox.
<smoser> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1432821 <-- any ideas ?
<ubottu> Launchpad bug 1432821 in systemd (Ubuntu) "something deleting /run/network after during boot" [High,Confirmed]
<cyphermox> mauricfo: the mini iso image can be used for now, but it's a bit more complicated to use
<smoser> or https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1432758 even.
<ubottu> Launchpad bug 1432758 in cloud-init (Ubuntu) "cloud-config.service, cloud-final.service do not run if previous cloud-init service failed" [High,Confirmed]
<mauricfo> cyphermox, ok :)
<ogra_> smoser, xnox  ... not sure if they have bug tracking enabled, but you could try ... https://launchpad.net/~we-love-pitti
<smoser> ogra_, are you suggesting i should join the pitti fan club ?
 * smoser wonders why there is no ~we-love-smoser group.
<cyphermox> mauricfo: I have a preseed ready that automates everything but the partitioning, for testing the changes: http://people.ubuntu.com/~mathieu-tl/preseed/multipath.cfg
<ogra_> smoser, no, file a bug about him not being cloned yet fo example :)
<mauricfo> cyphermox, cool, checking.
<smoser> ah. /me goes to create a second launchpad account and then create a smoser fan group using it.
<ogra_> lol
<ogra_> smoser, please enable bug tracking though :)
<infinity> smoser: To have a fan club, you need to have fans.
<Odd_Bloke> * smoser orders fans from Amazon.
 * smoser goes to create *more* pseudonym accounts on launchpad as the only way to get fans.
<Odd_Bloke> Try and convince a "buy Twitter followers" company to pivot in to LP accounts.
<mauricfo> cyphermox, nice. i had something similar, but yours is more complete. thanks.    I noticed you uploaded the changes as-is, except for changelog entries/new maintainer fields for partman-multipath (now ubuntu-pathced), right?  So I expect most testing to have already been done, but we'll sure kick off some more. :)
<cyphermox> mauricfo: yup
<xnox> smoser: can you grep through contents of tmpfiles.d to check if there are stanzas to clear out /run/network?
<mlankhorst> flexiondotorg: I've uploaded a new xorg-server with the readbios reverted.. if it's really that give it a shot..
<xnox> smoser: looking at ifup@.service it specifies RuntimeDirectory=network which clears it out through the lifetime of ifup@.service
<xnox> smoser: see RuntimeDirectory= in http://www.freedesktop.org/software/systemd/man/systemd.exec.html
<xnox> smoser: enjoy! =)
<smoser> xnox, thnak you.
<smoser> xnox, was 'tmpfiles.d' /run/tmpfiles.d ?
<xnox> smoser: no /usr/lib/tmpfiles.d or i guess on debian/ubuntu /lib/tmpfiles.d?
<xnox> smoser: but in this case it was the unit itself.
<xnox> smoser: in general when in daubt there is answer in http://www.freedesktop.org/software/systemd/man/systemd.directives.html for every letter of the alphabet.
<xnox> This index contains 1829 entries in 14 sections, referring to 197 individual manual pages.
<smoser> i'm so happy, *so happy* to get to do things twice.
<smoser> after 5 years or so we had a nice reliable boot in upstart.
 * sunweaver also wonders why Ubuntu people pull-in systemd just before the release...
<smoser> s/ just before the release..//
<smoser> xnox, sorry to pester. but given /lib/systemd/system/ifup@.service has 'RuntimeDirectory=network'...
<xnox> ..... one may not write things into /run/network outside of the job.
<smoser> a.) that job may be run multiple times at the same time (ie, eth0 and eth1 come up at same time)
<xnox> they should be sharing things.
<xnox> as instances share things with ifup@.service rathern than have individual per ifup@etho0.service direcotry
<xnox> smoser: i think you want to generate things into /run/network.d and then ship /lib/systemd/system/ifup@.service.d/mass.conf
<xnox> in that mass.conf specify [Service]PreStartExec=/bin/cp -a /run/network.d/* /run/network
<slangasek> ogra_: yes there are a series of changes needed to fully get rid of ttf-punjabi-fonts; I'll keep digging if nobody else has fixed this yet
<xnox> smoser: or some such. such that mass files are copied into /run/network when part of the ifup@.service scope
<ogra_> slangasek, doesnt look like anyone has to me
<smoser> xnox, well its not maas specificlaly here, its needing to keep an interface up from initramfs configuration. but sure.
<xnox> smoser: because systemd is that beautiful =)
<smoser> but then how would i make it such that 'cp' was not run before systemd decides to rm -Rf /run/network ?
<xnox> smoser: right, if we pivot from initramfs.... we probably ought to drop RuntimeDirectory=network
<smoser> or after
<smoser> or during
<xnox> smoser: and instead have "d /run/network" in tmfiles.d
<xnox> smoser: e.g. create empty /run/network, if doesn't exist. If exists, don't clean it.
<xnox> smoser: note that the rest of the world probably is running systemd in the initramfs and doesn't have such problem.
<smoser> that seems to make sense.
<smoser> i have less excitement about initramfs having systemd than i do about /sbin/init being systemd.
<ogra_> why would the initrd be systemd
<ogra_> it isnt upstart today either
<smoser> so it could be faster!
<ogra_> lol, right
<smoser> and because we have reliable initramfs at this point. so re-engineering that is useful work.
<ogra_> and breaking it ... indeed ... so we wont be out of work
<ogra_> iirc the "might be faster" argument already didnt fly with upstart ...
<ogra_> which was why this was given up
<infinity> Pivoting a single init is faster given a frictionless bootloader in a vacuum.
<infinity> Turns out that most boot scenarios don't match that, and larger initrds are bad, even if they are slower after loading.
<infinity> s/slower/faster/
<flexiondotorg> mlankhorst, Will give it a go.
<infinity> Brain not braining yet.  Need iced tea.
<slangasek> ogra_: looks like someone retried the desktop build after fonts-guru was uploaded
<ogra_> ah, cool
<flexiondotorg> mlankhorst, Not seeing a new xorg-server here - https://launchpad.net/ubuntu/+source/xorg-server
<flexiondotorg> mlankhorst, Where should greb it from?
<smoser> anyone want to give opinion on where this code should go in systemd:
<smoser>  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/open-iscsi/vivid/view/head:/debian/open-iscsi.iscsi-network-interface.upstart
<smoser> it seems like we should have a more general mechanism for this than in open-scsi.
<doko> barry, IOError: [Errno 13] Permission denied: '/usr/bin/pip'
<doko> argh, seen in testing with tox
<barry> doko: can you give me some context?
<doko> barry, https://bugs.launchpad.net/bugs/1427852 trying to enable the tests, without tox (preferred)
<ubottu> Launchpad bug 1427852 in pyjwt (Ubuntu) "[MIR] pyjwt (b-d of python-oauthlib)" [Undecided,Incomplete]
<mlankhorst> flexiondotorg: ppa:canonical-x/x-staging
<flexiondotorg> mlankhorst, Thanks.
<flexiondotorg> mlankhorst, That has fixed my VirtualBox machine.
<flexiondotorg> mlankhorst, From Ubuntu MATE 15.04 (todays daily) I added the PPA, upgraded, restarted LightDM. Now I have the live desktop.
<mlankhorst> flexiondotorg: oke can you file a bug report upstream?
<mlankhorst> flexiondotorg: and can you run apport-collect with the failing xserver?
<flexiondotorg> mlankhorst, Will run apport collect.
<mlankhorst> ty
<flexiondotorg> mlankhorst, I didn't create the original bug. So, I'll have to use apport-bug
<mlankhorst> flexiondotorg: ok just make a dupe then
<flexiondotorg> mlankhorst, No I can't.
<flexiondotorg> Text based browser are being rejected by LP as bots.
<tjaalton> file a bug, use apport-collect
<mlankhorst> just make sure its against xorg-server
<flexiondotorg> mlankhorst, I have no display server. Therefore I have to use console browsers. LP is rejecting my authentication attempts via text based browsers claiming I am a spam bot.
<flexiondotorg> mlankhorst, Therefore, I can't provide what you've requested.
<tjaalton> just use another machine to file the bug
<tjaalton> then apport-collect on the actual machine
<flexiondotorg> tjaalton, I see. File a bug, then apport collect. Goit it.
<flexiondotorg> mlankhorst, File the bug here? https://bugs.launchpad.net/ubuntu/+source/xorg-server
<tjaalton> yes
<flexiondotorg> apport-collect claim xorg-server is not installed.
<tjaalton> install xdiagnose
<tjaalton> apport-collect #bug
<tjaalton> without #..
<flexiondotorg> tjaalton, Thanks.
<flexiondotorg> mlankhorst, tjaalton https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1433198
<ubottu> Launchpad bug 1433198 in xorg-server (Ubuntu) "15.04 daily images don't reach X using VirtualBox - VESA error: Cannot read int vect" [Undecided,New]
<flexiondotorg> tjaalton, Thanks for your help in gathering those logs.
<tjaalton> yw
<mlankhorst> weird bug
<mlankhorst> meh LOW_PAGE_SIZE is set to 0x600 :(
<mlankhorst> shouldn't that be PAGE_SIZE?
<mlankhorst> looks like it should be a getpagesize() there
<rbasak> slangasek: would you want a lintian override for dir-or-file-in-opt for a package going into partner?
<slangasek> rbasak: desirable (with comment explaining why it's allowed) but not required
<rbasak> OK, thanks.
<infinity> slangasek, mdeslaur, stgraber: Is my calendar lying to me, or do we have a TB meeting?
<infinity> kees: You too.
<mdeslaur> infinity: we do indeed have a meeting
<stgraber> infinity: my phone agrees
<kees> infinity: mine says that too. I'm in #ubuntu-meeting-2
<doko> I love it when python-defaults triggers the autopkg test world :-/
<bdmurray> jodh: bug 1300235 updated
<ubottu> bug 1300235 in chromium-browser (Ubuntu) "init (chromium-browser) crashed with SIGSEGV" [High,Triaged] https://launchpad.net/bugs/1300235
<smoser> xnox, hey. so bug http://pad.lv/1432758 . i could do 'ExecStart=-/usr/bin/cloud-init'
<ubottu> Launchpad bug 1432758 in cloud-init (Ubuntu) "cloud-config.service, cloud-final.service do not run if previous cloud-init service failed" [High,Confirmed]
<smoser> something like http://paste.ubuntu.com/10616600/
<smoser> but that seems that it would make systemd think the job succeeded.
<xnox> smoser: what do you want to do?
<smoser> rather than masking the failure, what i *want* is for the subsequent jobs to start even in that failure.
<xnox> smoser: where can i look at the actual units?
<xnox> smoser: most likely you simply want to use "After" rather than "Requires"
<smoser> lp:cloud-init
<xnox> ok.
<xnox> smoser: your target should use "Wants=" rather than "Requires"
<xnox> (unless cloud-init-local.service cloud-init.service must not fail)
<xnox> smoser: ditto e.g. cloud-final should say After=cloud-config.target Wants=cloud-config.target
<smoser> xnox, i think you're right.
<smoser> both 'After=' and 'Wants=' ?
<xnox> smoser: yes.
<xnox> smoser: after is ordering, all wants are executed together in parallel.
<smoser> ok
<xnox> e.g. A wants B, and B wants A. Are valid together, as there is no circular ordering loop. Simply both are started simultaniously together.
<xnox> A after B, B after A -> is a loop that systemd breaks.
<johanvdw> Hi all, I just filed a bug against saga: the version in vivid can not be used, it needs a rebuild to be usable. What would be the proper way to tag this bug so it gets picked up?
<infinity> johanvdw: Why does it need a rebuild?
<johanvdw> infinity: https://bugs.launchpad.net/ubuntu/+source/saga/+bug/1433255
<ubottu> Error: malone bug 1433255 not found
<infinity> johanvdw: Did you mark it private? :P
<smoser> xnox, http://paste.ubuntu.com/10616751/
<smoser> does that make sense ?
<johanvdw> infinity: fixed - contained a full report
<johanvdw> it is in fact a bug in gdal which does not do proper version of its libs
<infinity> Uhm, yes.  I was about to say...
<johanvdw> most packages use the C api which is stable, but saga uses the C++ api
<xnox> smoser: looks good.
<johanvdw> I'll check other reverse dependencies as well
<infinity> johanvdw: Yeah, I'm rather concerned that we're shipping a library with this many rdeps that doesn't do sane ABI versioning.
<johanvdw> infinity: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756867
<ubottu> Debian bug 756867 in release.debian.org "transition: gdal" [Normal,Open]
<infinity> johanvdw: Ugh.  That looks like an amazing mess.
<infinity> johanvdw: I'll note that you're the person who originally requested this be synced from experimental.  Was there a good reason for that?
<infinity> johanvdw: Anyhow, I think the best way forward is going to be to sync from experimental again to get us on the current point release, and then rebuild *all* the rdeps, so we get the shiny new per-abi dependencies tracked properly.
<infinity> johanvdw: Which is still crack, but at least crack that might sort of work in the future.
<doko>   * debian/patches/set_user_default.patch:
<doko>     - ensure better backward compatilibity for scripts executing pip install
<doko>       by not changing default to user if the script is executed with root
<doko>       perms.
<johanvdw> infinity: I do plead guilty :-) In fact we have tested gdal and its reverse dependencies a lot for building the osgeo live dvd (live.osgeo.org). Gdal is a data abstraction layer - it adds support for new file formats. People tend to want the latest version
<doko> barry: ^^^ do you know about this python-pip check?
<johanvdw> infinity: I just was not aware of this issue as we were rebuilding anyway when using the repository
<infinity> johanvdw: Right.  Well, onward we go to fixing it.  I'll start with a fresh sync, and when that's built everywhere, we can rebuild $world.
<johanvdw> ok, thanks a lot and sorry for the mess. I can call for testers after the rebuild.
<johanvdw> infinity: I can also check with the current gdal maintainer if he has any more advice
<infinity> johanvdw: Well, assuming this Provides:foo-abi madness actually works, it should be a solved problem going forward once we've rebuilt the world once.
<infinity> johanvdw: Cause britney will hold future transitions until they're completed, instead of letting things break.
<johanvdw> infinity: I'm pretty confident the current package is in a good shape - it is just that the old versions didn't track abi changes
<infinity> johanvdw: Yeahp, hence resetting the state of things by just giving up and rebuilding all the rdeps, seems the only safe way to do this so it's future proof.
<infinity> johanvdw: Beats guessing, anyway.
<infinity> johanvdw: Oh, and I just realized gdal is a 2h build on armhf, so I guess I'll revisit this a bit later.
<johanvdw> infinity: rdeps grass and qgis will also take long to build
<infinity> johanvdw: Yeah, I know.  Machine time is cheap, it's just the me waiting around time that isn't. ;)
<infinity> I might solve that problem with lunch.
<johanvdw> infinity: should you bump into any problem contact me or perhaps better debian-gis mailing list.
<infinity> johanvdw: I'll annoy you directly if it goes wrong, you can bug others. :P
<infinity> johanvdw: I'm all for doing the easy-but-tedious part and blaming you when it all goes wrong.  *nod*
<johanvdw> Well, I should have cought this earlier on - anyway we wll have a shiny gdal for vivid, this means a lot to our users :-)
<smoser> what is the normal process for proposing merge to a git repo like git://anonscm.debian.org/pkg-systemd/systemd.git ?
<smoser> can someone please take a sanity checkon my patch at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1432821 ?
<ubottu> Launchpad bug 1432821 in systemd (Ubuntu) "something deleting /run/network after initramfs" [High,Confirmed]
<mlankhorst> flexiondotorg: http://lists.freedesktop.org/archives/xorg-devel/2015-February/045546.html
<flexiondotorg> mlankhorst, Nice!
<smoser> slangasek, around ?
<slangasek> smoser: hey there
<smoser> your thoughts on http://pad.lv/1432829 would be appreciated
<ubottu> Launchpad bug 1432829 in resolvconf (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [Undecided,New]
<smoser> seems reasonable fix to me
<smoser> (still need another portion of it to get my ephemeral maas boot with working DNS, but much closer with that)
<slangasek> smoser: which part shows the fix?
<smoser> bah
<smoser> wrong bug.
<smoser> http://pad.lv/1432821
<ubottu> Launchpad bug 1432821 in systemd (Ubuntu) "something deleting /run/network after initramfs" [High,Confirmed]
<smoser> that one.
<smoser> the resolvconf one is the dns issue that i will still need fixe.d
<smoser> i can upload, but just wanted someone other than me to say that looks sane, and then also... the git upstream , do i still just upload and then expect someone to import the upload into git://anonscm.debian.org/pkg-systemd/systemd.git or does a bot do that ?
<slangasek> smoser: yes looks ok to me; as for it going into git, no, for that you want to nudge pitti
<smoser> so i upload and then he juts does the equivalent of 'bzr import-dsc'  ?
<smoser> or are you saying to let him do the upload
<slangasek> smoser: updating the VCS is his problem ;)
<smoser> k
<slangasek> smoser: Vcs-* fields for Ubuntu packages should always point to a VCS that's writable by the set of people who have upload rights to the package, and if they don't it's a bug in the VCS setup and you should go ahead and do what you need to do
<CheeseBurga> [reed] _Groo_ _salem _zerick_ achernya achiang adam_g Adri2000 ahasenack ajmitch alai alesage alexbligh1 alexlist Ampelbein and` andyrock apw arges ari-tczew asac attente_ awe_ balkamos balloons barry bdmurray bdrung bdrung_work begal-sop_ beisner bekks BenC benonsoftware beuno bfiller bigon bladernr_ Bluefoxicy bluesabre
<CheeseBurga> blueyed bregma broder bschaefer buMPnet_ buxy camako caribou catbus1 charles CheeseBurga ChickenCutlass_ chiluk Chipaca chrisccoulson Cimi cjwatson cody-somerville coreycb Cydrobolt cyphermox czchen d1b DalekSec danjared dannf danwest darkbasic darkxst Daviey davmor2 dcmorton debfx dendrobates dgadomski dgm816 directhex dkessel DktrKranz dobey
<CheeseBurga> doko dosaboy dupondje DzAirmaX eam ejat elfy elijah Elimin8er elky elmo elopio enrico ev fabbione fabo fginther fionnan FJKong Flannel flexiondotorg FliesLik1ABrick FourDollars freeflying freyes funkyHat FunnyLookinHat G gavinguo geser ginggs glebihan glebihan_ gnuoy grimble_ Guest85523 gusnan hallyn_ happyaron henrix
<CheeseBurga> herb hggdh highvoltage hloeung i_ron ikepanhc ikonia imcleod infinity iulian ivoks j_f-f james_w jamesh jamespage JanC jcastro jdstrand jhenke jjohansen johnlage jonmasters jono josepht jpds jrib jrwren jsalisbury jtaylor jvw kalzz kees kenws kickinz1|afk kirkland knocte Kow lamont Laney lathiat
<CheeseBurga> LBo lenios lfaraone lifeless lilstevie lionel LocutusOfBorg1 Logan lool lpotter lucas Lutin lutostag lynxman Madkiss mahmoh mako manjo mapreri marcoceppi mardy marga markelite maswan maxb mbarnett mbiebl_ mchro mdeslaur medicalwei mfisch mgedmin mhall119 micahg milli ming` Mirv mitya57 mitz mlankhorst
<CheeseBurga> mneptok morphis mpt mr_pouit mthaddon murphyslawbbs mwhudson mwhudson_ mzanetti NCommand` NCommander negronjl neunon niedbalski nisstyre nobuto Noskcaj ochosi Odd_Bloke ogasawara ogra_ Orphis panda|z PaulW2U PeterSchwaller_ pfsmorigo pgraner phunyguy Pici pjdc plars popey psivaa_ Pwnna Quintasan ralsina rbanffy_ rbasak rbelem_ rcj
<CheeseBurga> retoaded Riddell rmk roaksoax robert_ancell robru rpadovani rsalveti rww ryanakca sarnold Sarvatt saurik Saviq sbeattie scateu` schmidtm ScottK semiosis sergiusens seyeongkim sforshee shadeslayer shuduo simosx siretart slacker_nl sladen slangasek smb smoser Snow-Man soren` Spads SpamapS Spr0cket ssweeny StevenK stgraber stokachu
<CheeseBurga> Streamstormer stub subscope sunweaver swem tarpman tedg teward thedac TheMuso timchen119 timrc tinoco tjaalton tkamppeter tlyu Tm_T Tm_Tr tmpRAOF torkel Trevinho Tribaal tsimpson ttx tumbleweed txspud|ORS tych0 tyhicks ubottu ubuntulog udevbot ulkesh Unit193 Ursinha utlemming ValicekB vrodic vrr warp10 wendar
<directhex> sigh
<CheeseBurga> wgrant wneit wolsen wookey_ xnox yofel yosafbridge ypks ypwong yuning zbenjamin zequence Zic zigo zigo_ zsombi zumbi zyga
<Cydrobolt> ;p
<Cydrobolt> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<Unit193> CheeseBurga: Heya, how *you* doing!
<slangasek> !ops ^^
<slangasek> mmk
<Cydrobolt> Hmm, he left
<jcastro> bad paste perhaps
<Unit193> No.
<bekks> In multiple channels? :P
<bluesabre> here and accounted for
<ari-tczew> flooding
<bluesabre> hey everyone :)
<neunon> normally that kind of thing only happens to me in #freenode
<smoser> thanks slangasek . uploaded.
<Cydrobolt> im getting pinged in a lot of other chans too
<slangasek> smoser: cheers :)
<ari-tczew> from the other hand, such a cases wake the people up :P
<smoser> if you're bored and you want to think about bug 1432829 ... that'd be appreciated too.
<ubottu> bug 1432829 in resolvconf (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [Undecided,New] https://launchpad.net/bugs/1432829
<smoser> it seems sane imo to have systemd do what open-iscsi did with resolvconf
<slangasek> smoser: I saw your comment there and didn't understand why you thought this should be in systemd instead of in open-iscsi
<slangasek> but also didn't look closely
<smoser> why should it be in openiscsi ?
<smoser> its nothing to do with iscsi
<slangasek> ah
<smoser> and generally to do with ifup and intefaces being configured in initramfs
<slangasek> ok then :)
 * rww looks up
<rww> Unit193: any mode change recommendations, or shall we just wait it out :\
<sarnold> he's likely klined by now, he hit a lot of channels
<Unit193> rww: None.
<rww> ubottu: ops-#ubuntu-devel =~ s/, or/, rww, or/
<ubottu> I'll remember that rww
<rww> Unit193: figured. yay proxies and such
<rww> sarnold: I know, if it's the same twit as elsewhere, he keeps coming back on other hosts
<rww> anyways
<Unit193> rww: And too many unauth'd users. :P
<rww> mhm, i thought that too
#ubuntu-devel 2015-03-18
<tmpRAOF> Bah. Why can't you annotate your versioned symbols purely alongside their code? Why must you have a symbols.map file that is invariably wrong in some way?
<slangasek> tmpRAOF: you can?  but there are no good examples of this because the only library that makes use of the pragma approach is glibc, and it's buried under three layers of preprocessing :)
<tmpRAOF> slangasek: You can? How?
<tmpRAOF> As far as I can tell you can get _quite_ close with the relevant __asm__, if you try and add a symbol to a version node that doesn't appear in symbols.map the linker barfs.
<tmpRAOF> Assume there was a âbutâ in the relevant place there :)
<slangasek> oh?  hmm maybe I'm mistaken then
<tmpRAOF> I could try again.
<tmpRAOF> Also, I don't think there's any sane preprocessor I could do to make C++ versioning less painful, but just the C would be nice.
<cyphermox> tmpRAOF: hey
<cyphermox> tmpRAOF: may I ask why you are temporary?
<tmpRAOF> cyphermox: Because I lost my freenode password, and signed up before having a backup email address was mandatory.
<tmpRAOF> I'm temporary until the registration on RAOF expires (in another 10 months or so)
<cyphermox> ouch
 * tmpRAOF ponders writing patches for __attribute__(version)
<rww> tmpRAOF: 18 weeks, so 4 months :P
<rww> and it looks like enforcement isn't enabled on RAOF, so you could nick to it anyway and use /msg nickserv identify tmpRAOF passwordhere
<rww> actually, it's normally 15 weeks, though could be up to 18 at staffer discretion
<sarnold> I've gotten used to tmpRAOF, having a regular RAOF around is going to be confusing :)
<RAOF> rww: Ah, I thought that might have been problematic on channels like #dri-devel which require you to be registered in order to post, but apparently just being registered at all qualifies.
<rww> indeed
<Unit193> You'll just make a few of us think you aren't. ;)
<sergiusens> cyphermox: cjwatson this is a long shot question, but is there a way to get out of the need for grub-install and do something similar to dd'ing u-boot?
<ScottK> slangasek: re the TB discussion on the DMB candidate pool, we're also not processing a lot of applications, so we aren't growing the base either.
<infinity> sergiusens: Context, re: grub-install?
<infinity> sergiusens: grub-install *is* doing "something like dding u-boot", except for the (good) part where it's also keeping it up to date.
<sergiusens> infinity: my use case is not having to do a bind mount dance and setting up an armhf image without hassle but I can defer for after st patrick's
<sergiusens> oh wait, I don't use grub on armhf
<sergiusens> but still, I want to avoid doing grub-install from a chroot with a bind mounted root
<Laibsch> how can I apply to become a member of ubuntu-sru?  This doesn't seem to be documented anywhere.  SRU are a focus of my work since I run LTS, exclusively.
<Laibsch> What I'd like to do is more bug-related work, especially to be able to accept or reject SRU nominations.
<Laibsch> Currently, I can already nominate for a release (as part of being a member in bug-squad, I believe), but somebody else has to accept the nomination.
<infinity> Laibsch: If bug triaging is your aim, ubuntu-sru isn't for you.
<infinity> Laibsch: We do extensive code review and accept/reject uploads.
<Laibsch> OK. What do you suggest, infinity, to do the accepts/rejects for nominations?  I feel that is a neglected area.
<infinity> Laibsch: The permissions on that are a bit messy.  To be fair, I tend to just accept/reject the nominations when processing uploads, they don't need to be accepted before an upload happens.
<infinity> Laibsch: There is a group for nominating, but it has a few too many other permissions, due to that bit not being as fine-grained as it should be, so I'm wary of adding too many people to it.
<Laibsch> That is my impression, too.  My aim is to improve visibility.  I'd like to visit https://bugs.launchpad.net/ubuntu/trusty/ and see the open tickets still affecting the LTS.
<Laibsch> That is currently not really possible
<infinity> Laibsch: Yeah, it's not perfect, I agree.
<Laibsch> I see, understand and respect you are wary to add too many people.  Well, here I am requesting to be let in ;-)
<Laibsch> do you know my LP nick?
<infinity> wgrant: How much work would it be to fix bug nominations to not require the hackish ~ubuntu-release-nominators team (as a member of drivers, which I assume still has too many permissions to make this hack comfortable)?
<infinity> Laibsch: I'm assuming you're ~r0lf
<Laibsch> yup
<Laibsch> good memory ;-)
<wgrant> infinity: "fix" how?
<infinity> wgrant: Well, I'm not sure.  To make series nomination something that doesn't rely on drivers?
<wgrant> Sure, but nobody has been able to define what it should rely on.
<infinity> wgrant: I'm fuzzy on how that's all laid out right now.
<wgrant> Currently bug supervisors can nominate, and drivers or uploaders can approve
<infinity> Oh, uploaders can approve?
<wgrant> Yes.
<infinity> Laibsch: There's your solution.  Either only triage universe SRUs, or become a core-dev some day. :)
<Laibsch> I'm actually neither ;-)
<Laibsch> Only recently was I granted PPU uploads
<Laibsch> long, ugly story
<Mirv> I think this https://launchpad.net/ubuntu/+source/gdal/1.11.2+dfsg-1~exp2 is causing vtk6 adt failure and also blocking the whole Qt 5.4.1 landing.
<infinity> Mirv: Yeah, I'm working on it.
<Mirv> infinity: oh, thanks!
<infinity> wgrant: Okay, well, that's less broken than I originally thought, at least.
<infinity> Laibsch: So, honestly, I'm going to have to just politely decline.  But given that any core-dev can approve a nomination, if you see pending ones that you think should be approved, it's not too onerous to ask in here.
<Laibsch> OK.  I'll just bug you guys until you get tired of doing it this way ;-)  I'd think that rejecting a nomination is equally important to make sure there is a well-defined flow to it and https://bugs.launchpad.net/ubuntu/trusty/+nominations as well as https://bugs.launchpad.net/ubuntu/trusty/ show the true state of affairs.
<Laibsch> for example, I'd suggest to autoreject all 500+ nominations for lucid https://bugs.launchpad.net/ubuntu/lucid/+nominations
<infinity> wgrant: I've not been convinced since day one that the nominate->accpet/reject flow made more sense than just "here's a task, let someone wontfix/invalid it if it's crap", but I guess for what it's meant to do, the perms seem alrightish.
<Laibsch> Personally, I think the same is OK for precise https://bugs.launchpad.net/ubuntu/precise/+nominations
<infinity> Laibsch: precise is still supported for 2 more years.
<wgrant> infinity: Well, nominations don't have much value nowadays.
<wgrant> infinity: Until a few years ago anyone could nominate, so the separate phase made sense.
<infinity> wgrant: So maybe just letting bug supervisors have the full privs would make everyone happy?
<Laibsch> infinity: Well, maybe an auto-reject for precise unlike lucid is still not warranted.  Combing through the tickets would probably yield 90+% reject rate
<wgrant> infinity: I don't think that there would be serious issues with letting bug supervisors add series tasks without going through nominations, now that task deletion exists.
<wgrant> And then nominations can conveniently cease to exist.
<Laibsch> Wow, there are still open bug nominations for hardy!  170 of them
<infinity> Laibsch: See, I fundamentally disagree with you (but I think that means I disagree with the nomination model).  If a bug exists in precise, it should have a precise task.  If the people responsible for fixing it decide they don't want to, they can mention that and WontFix it, but "I don't want to" doesn't make a bug not a bug.
<infinity> wgrant: Yeah, I think I'd like that better.
<Laibsch> https://bugs.launchpad.net/ubuntu/+source/kbd-chooser/+bug/27284 that one's nominated all the way back through to dapper!
<ubottu> Launchpad bug 27284 in kbd-chooser (Ubuntu) "Wrong configuration of keyboard" [High,Confirmed]
<infinity> wgrant: And then I could delete that hackish group wholesale, which would make me happy.
<infinity> wgrant: It's never sat well with me.
<wgrant> infinity: Doesn't it also exist for blueprint targeting?
<Laibsch> infinity: I agree with the a bug that is present is a bug.  Oftentimes, I do argue that case.  But I guess most bugs like that if they have been sitting around are ignored.  Certainly any nomination before hardy should be auto-rejected as a part of clean-up.
<wgrant> Which is why UDS organisers etc. used to be in there.
<infinity> wgrant: In theory, not sure anyone uses it for that anymore.
<infinity> Laibsch: Sure, nominations on EOL releases should be cleaned up, no argument there.
 * Laibsch has done some of those in the past
<Laibsch> I was only able to do that if the nomination had been accepted
<infinity> Laibsch: But "old open bugs" on non-EOL releases are not a problem.  Driving bug counts to 0 by FIXING bugs is a noble goal.  Artificially driving bug counts to 0 by closing valid bugs is not.
<Laibsch> if a bug is nominated but not accepted yet, I'm stuck
<Laibsch> like bug 27284 which could be cleaned up on the dapper to jaunty part
<ubottu> bug 27284 in kbd-chooser (Ubuntu) "Wrong configuration of keyboard" [High,Confirmed] https://launchpad.net/bugs/27284
<infinity> wgrant: Anyhow, at the very least, we could prune the team, which would make me happy.
<Laibsch> infinity: no disagreement.  I believe in fixing bugs, not reducing ticket count.  The latter comes from the former.
<Laibsch> But I also like a good dashboard which LP mostly is.  But as I mentioned I am currently stuck on certain things.
<infinity> Laibsch: Yeah, I agree (obviously) that the nomination thing isn't ideal.
<Laibsch> Well, I kind of like it.  But I see the problem you with it from a managerial POV.
<Laibsch> "have with it"
<infinity> Laibsch: Well, if only bugcontrol can nominate, and bugcontrol are the people I'd prefer to be approving or rejecting nominations, then may as well just do away with the process. :P
<Laibsch> Sure.  I'd be happy with that too, being a member of bugcontrol.
<Laibsch> is that where you will be heading, then?
<infinity> I think that was the rough concensus between wgrant and I, though we might want to think about it a bit more before changing how something's been for years.
<wgrant> Right, the nomination process doesn't provide much value now that nominations themselves are restricted.
<infinity> Laibsch: But, for now, asking works.  Sucks, but works.
<Mirv> hmm, looks like that gdal transition might be a bit bigger one. things like rebuilding qgis would take hours.
<infinity> Mirv: Yeah, I didn't say it would be instant.
<wgrant> We should check with others, and think about it, but it's a lot of complexity for not much gain.
<Mirv> no problem
<infinity> wgrant: Well, we could fudge it for now by giving bugcontrol nomination approval perms, which effectively removes the step without removing the code.
<infinity> wgrant: And then further discuss if the code itself is even useful.
<wgrant> infinity: The code is broken anyway, so I want to delete it :P
<infinity> Heh.
<Laibsch> infinity: just to be sure I understand the outcome of this discussion. Are you (or somebody else) going to allow bugcontrol to ACK/reject nominations some time soonish? I'm not sure I understand what the consensus is where the train will be heading.
<wgrant> Good old bug #110195
<ubottu> bug 110195 in Launchpad itself "Nominating a bug for a distro series affects all package tasks for that distro" [Critical,Triaged] https://launchpad.net/bugs/110195
<wgrant> I reported it nearly eight years ago...
<infinity> wgrant: Maybe when Colin wakes up?  I don't think this needs management buy-in (in fact, I imagine that would just invite bikeshedding), between the three of us, we should be able to decide the fate of the feature reasonably.
<infinity> wgrant: Is the two-step nominate/approve process used for non-distro products too?
<infinity> wgrant: Or is it a case of "well, the code would allow that, but no permission split exists to expose the UI to other projects".
<wgrant> infinity: It is.
<wgrant> Products have the driver/bugsupervisor split just like Ubuntu.
<infinity> Kay.
<infinity> So, I think that's the discussion to have.
<infinity> Cause for Ubuntu, I can confidently say this has sucked for ages, and giving bugcontrol actual control over bugs would be fine by me.
<infinity> If they abuse it, they can be removed from the team, splitting perms doesn't make idiots stop being idiots.
<wgrant> Exactly.
<wgrant> For something that can at worst cause annoyance, we just need a barrier to stop any user at all from doing it.
<wgrant> As soon as you have that barrier, you can easily slap anyone who abuses it.
<Laibsch> kindly requesting to set the vivid task of bug 1273203 to fix released. Bonus points for actually processing the trusty task ;-)
<ubottu> bug 1273203 in ubuntu-restricted-extras (Ubuntu Trusty) "ubuntu-restricted-extras Recommends unavailable package: libavcodec-extra-53" [Medium,Triaged] https://launchpad.net/bugs/1273203
<infinity> Laibsch: That's a case of "you shouldn't have nominated it".
<infinity> Laibsch: A nomination to the development release is redundant.
<Laibsch> why is it available, then? ;-)
<Laibsch> I nominated in case it wasn't going to get fixed before the release cycle
<Laibsch> but I agree it creates unnecessary work now
<Laibsch> I'd clean up after myself if I was able to
<infinity> Laibsch: As for the debdiff there for trusty, 60ubuntu0.1 is the correct version.
<Laibsch> well, I'm aware of that.  I find my version more informative.  See my comment.  I checked all releases to make sure this one would work.
<infinity> Laibsch: Oh, wait.  No.  It's ubuntu-native.  The correct version would just be 60.1
<Laibsch> IMVHO 60ubuntu0.1 suggests this was a version not part of ubuntu which isn't the case.
<Laibsch> it's a branch-off, not a backport
<infinity> Laibsch: Right, it should just be 60.1
<infinity> I'll sponsor it as such.
<Laibsch> OK, I won't fight over that. I still prefer seeing the release name in these sometimes quite long package version numbers.
<Laibsch> when possible
<Laibsch> infinity: thanks, btw
<infinity> Laibsch: Which is entirely against our versioning policy. :P
<infinity> Laibsch: (And release names are always wrong in versions, if you really need to ref a release, say for a backport, it should be the number, so they sort correctly)
<Laibsch> I understood the version policy to be "we suggest this, but we only require you not to break anything"
<Laibsch> well, and again, I don't like only numbers
<infinity> Laibsch: And after the Z release, when the next one sorts earlier? :)
<Laibsch> 1.4.11-1 is hard to spot from 1.4.11.1-1 etc
<Laibsch> still some time for the Z release
<infinity> Laibsch: It's not about what you like, people have actually thought about this.
<Laibsch> I'm sure that will create all sorts of problems of its own and I am sure someone will figure those out
<Laibsch> well, trust me, I have thought about this, too.  And I find it important to be able to actually "read" the version number, especially when they get long.  And I know my version won't break anything and will do what I am trying to do which is readability in this case.
<Laibsch> SRU numbers tend to get longer and longer
<Laibsch> so, again, IMVHO I think the release is better than just numbers
<Laibsch> release name
<infinity> Laibsch: SRU versions don't get longer and longer...  The next one after 60.1 is 60.2
<Laibsch> What i meant is they get longer than what was initially released
<Laibsch> which can be quite long on its own already
<infinity> Laibsch: Anyhow, let me put it differently.  You can have whatever opinion you like, I'd reject the upload if it had that version.
<Laibsch> fair enough ;-)
<infinity> Laibsch: And side note, you also missed the "#" in your bug closure syntax.
 * Laibsch hangs head low in shame
<Laibsch> BTW, the wording on https://wiki.ubuntu.com/StableReleaseUpdates is as I remembered and permissive: "The version number does not conflict with any later and future version in other Ubuntu releases (the security policy document has a well-working scheme which can be used for SRUs.) "
 * Laibsch hopes the text won't get changed now
<Laibsch> "can be used for SRUs" not "has to be followed"
<Laibsch> infinity: And I agree with your suggestion of 60.1 being better than 60ubuntu0.1 but that is not what https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging suggests
<infinity> Laibsch: Yes, I know it's quite permissive (maybe we should make it less so), but we also reserve the right to reject something for whatever silly reason we like, so most "bad" version numbers don't make it through.
<Laibsch> like I said, I HAVE thought about this
<infinity> Laibsch: The security doc misses the case where a native version is ubuntu-native, not debian-native.
<Laibsch> infinity: hehe, your version number is bad as per wiki (although IMVHO it is better than the one suggested there)
<infinity> Laibsch: If this was a debian-native package, 60ubuntu0.1 would have been correct.
<infinity> Laibsch: Anyhow, sponsored for both vivid and utopic, and since it was trivial enough that I really didn't feel it needed to be reviewed twice, accepted too.
<Laibsch> awesome, thanks
<Laibsch> I thought it was already in vivid?
 * Laibsch checks
<infinity> Laibsch: Err, trusty and utopic.
<infinity> Laibsch: I don't brain so good.
<Laibsch> Ah, utopic
<mpt> â<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!â â cjwatson, perhaps time to find some new ops? :-)
<Mirv> infinity: did you note libgdal-grass failed? it seems to expect same version number as gdal itself in the build scripts
<dholbach> good morning
<infinity> Mirv: I did, yes.  I'll sort it out after the rebuilding stuff.
<infinity> Mirv: Either way, looks like Qt migrated now, with the vtk autopkgtest fixed.
<caribou> Can someone explain why we are running a version of rsyslog which is so old ? (7.4.4 .vs. jessie's 8.4.2) ?
<Mirv> infinity: ok. and yes, excellent!
<infinity> caribou: Because no one's merged it since trusty.
<caribou> infinity: any reason for that other than no one wanted to ?
<infinity> caribou: That said, rsyslog releases don't tend to be action-packed, is there an issue with the current version?
<infinity> caribou: I assume it just slipped off the radar, it happens.
<caribou> I have people complaining about memory leak on Trusty
<caribou> I've tracked a few but apparently more remains
<infinity> caribou: Okay, well, then I guess you get to backport some fixes to trusty.  It's not like an LTS keeps shiny new versions for 5 years.
<caribou> infinity: yeah, that's what I'm looking at; was just curious to know why it hadn't moved. 7.4.4 is no longer maintained upstream as fas as I know
<caribou> no, that last statement is false
<flexiondotorg> mlankhorst, Is there anything you need me to test on xorg today?
<flexiondotorg> mlankhorst, My time is a little limited however.
<infinity> caribou: Many things we ship aren't supported upstream, that's how stable releases work.
<infinity> caribou: We take on that burden.  Sucks to be us.
<flexiondotorg> mlankhorst, Also Xorg on PowerPC is completely broken right now too.
<caribou> infinity: I did fix something in precise, that's when upstream told me it was no longer supported, but asked me for a patch for the 7 release
<flexiondotorg> mlankhorst, Saw it reported by the PowerPC guys and upgrade my iBook G4 running Ubuntu MATE 15.04. Lots of screen flashing/flipping and no way to interrupt it.
<zyga> tjaalton: hey
<zyga> tjaalton: I'd like to talk about bug 1381625
<ubottu> bug 1381625 in linux (Ubuntu) "Adjust brightness to lowest value caused screen whole black" [High,Confirmed] https://launchpad.net/bugs/1381625
 * tjaalton runs
<tjaalton> zyga: what about it
<zyga> tjaalton: hey
<zyga> tjaalton: I'm doing a small research project about this issue
<zyga> tjaalton: I've updated the bug report with that
<zyga> tjaalton: I wanted to ask you about your opinion on this
<zyga> tjaalton: and to know if that kind of data could be of use
<zyga> tjaalton: and if not, what else could help
 * sladen just *wishes* it was possible to turn the backlight down that far on other laptops
<tjaalton> well, I can ask the intel devs..
<tjaalton> I can't fix that myself
<tjaalton> the VBT spec isn't open either
<zyga> tjaalton: can we patch it in userspace though? patch apps to go to 0 on firmware and on max_brigthness * 0.1 on raw?
<zyga> sladen: down to off?
<zyga> tjaalton: if you ask intel please share anything they tell us
<zyga> tjaalton: does it require an NDA?
<tjaalton> no
<zyga> tjaalton: I don't know if we can do it quickly but for preinstalled laptops we could even ship a backligth profile with behavior data
<tjaalton> I'll check my hw what they're like
<zyga> tjaalton: can you use lantern please?
<zyga> tjaalton: the more data we have the better we understand how this behaves
<zyga> tjaalton: specifically follow that please http://www.zygoon.pl/2015/03/lantern-update.html
<zyga> tjaalton: you can send the results by email or just send a pull request with the new json file
<tjaalton> ok
<zyga> tjaalton: thanks!
<zyga> tjaalton: if you want to do the analysis part: http://www.zygoon.pl/2015/03/analyzing-lantern-submissions.html
<mlankhorst> flexiondotorg: I'll create a ppa3 in a bit
<cjwatson> sergiusens: You can decompose grub-install into its pieces (grub-mkimage and grub-bios-setup, basically, on PC BIOS systems; grub-mkimage and what amounts to cp on UEFI) and run them manually if you really want and are comfortable with owning both pieces if it breaks.  The reason it normally requires a chroot is that that's by far the easiest way to deal with automatically computing which module names must be passed to grub-mkimage for ...
<cjwatson> ... being built into the core image.  And there's a bunch of files such as modules that you need to copy into place under /boot/grub/ if you aren't using grub-install.
<cjwatson> sergiusens: I can't say I recommend this; it's usually more effort than dealing with bind-mounting stuff to run grub-install.
<cjwatson> sergiusens: (There are some workflows where it's reasonable to build a single giant monolithic core image and not expect it to do module loading at run-time, in which case it's simpler.)
<sergiusens> cjwatson: ok, I'll take the recommendation into account, my other goal which I did't mention was to not need root to create these images (but that's a further away problem)
<sergiusens> smoser: fyi ^
<cjwatson> sergiusens: Well, for an image that isn't actually installed to a computer's boot sector, grub-install is conceptually inappropriate anyway.
<cjwatson> grub-install is a thing you do on a computer that will be booted using GRUB.
<cjwatson> It's more like a deployment step.
<cjwatson> You can do the grub-mkimage parts in advance if for some reason it's unreasonable to do those on the deployed system.
<sergiusens> I need to give this some thought, these are mostly VMs, cloud images or dd'able image files
<flexiondotorg> mlankhorst, Ping me when ppa3 is ready and I will test. I'll also re-test my PowerPC using it later tonight too.
<doko> didrocks, hi, what is your python-pip change about?  reading the changelog, it allows a sudo pip install to overwrite distro packaged stuff, which we want to avoid
<didrocks> doko: it's just fallbacking to the upstream /usr/local behavior if it's run as root
<didrocks> doko: that way, we don't break potential existing scripts
<doko> didrocks, and you make sure that it doesn't work with /usr and root ?
<didrocks> doko: I just fallback to upstream behavior (not sure if you follow the upstream discussion that happened with my previous patch to set user mode by default)
<doko> no, that's why I was confused ...
<didrocks> doko: look at my previous patch first I guess, basically for root, this is a non change compared to utopic
<doko> ok
<doko> jamespage, the python-defaults upload triggered a lot of autopkg tests, neutron and swift now failing. I suppose that's something else than the dependency package triggering these
<jamespage> doko, working on neutron atm - will look at swift next
<jamespage> doko, neutron broke during the systemd switch - but its not directly attributable
<doko> jibel: can we ignore the taskcoach autopkg test failure? seems unrelated to the python-defaults change, and failing since Oct
<barry> doko, didrocks was just chatting w/dstufft.  watch the tracker issue for some progress on --user
<doko> jibel, wait, I'll merge the Debian version first
<didrocks> barry: ah nice, there was still nothing yesterday AFAIK, hence this fix to at least not break scripts!
<didrocks> barry: keep us posted :)
 * Laibsch pings infinity now that cjwatson seems to be awake
<Laibsch> good morning, cjwatson!
<cjwatson> I saw the discussion; I don't know if I have strong feelings.  Task deletion indeed makes many things better, although it's not perfect (IIRC you can't re-add a task that's once been deleted), but that probably doesn't matter for this case.  But we would have to look at how other projects are using it in LP, if at all.
<infinity> cjwatson: The task delete/recreate bug should probably not define if we need a feature to work around it. :)
<infinity> Though, in my world, I work around it by wontfixing/invaliding instead of deleting.  I've learned my lesson.
<Laibsch> infinity, cjwatson: So, what is the next step now?
<infinity> Laibsch: We go talk about it a bit and maybe things change at some point.  If you were expecting a resolution today, you might be disappointed.
<infinity> Laibsch: It's been like this for years, this is hardly a critically urgent bug or feature change.
<Laibsch> it's an honest question, no expectation beyond "OK, we talked about it and then it's going to drop off the radar"
<Laibsch> beyond the quote not happening
<infinity> Laibsch: I think we've covered most of the "talking about it" step. :)
<Laibsch> it sounded reassuring that you were confident to get a decision between the three of you.  the more people involved the more difficult to progress.  so, my honest question is where this stands.
<infinity> Laibsch: William clearly has a preference for dropping the feature altogether, I'd like to see bugcontrol's permissions elevated, Colin wants to make sure others aren't in dire nead of the feature before agreeing with William, and there we are for now.
<cjwatson> infinity: perhaps you should put it onto the foundations->lp stakeholder backlog?
<Laibsch> infinity: sounds like your choice won't conflict with the other two
<Laibsch> so maybe that is a good interim solution
<Laibsch> it would make me happy, too ;-)
<infinity> cjwatson: Perhaps I should.  Or we could just do the permissions elevation bit as a bite-sized deal, and revisit the "drop the whole feature" thing another time.
 * Laibsch applauds infinity's proposal from the side-line
<wgrant> cjwatson: The task deletion reversal bug is half the reason I want to delete nominations.
<wgrant> The underlying problem is that nominations are for a DistroSeries, not a SourcePackage. So if you remove a subset of them, the nomination is half-removed.
<wgrant> If nominations go away, one could presumably add a single SourcePackage task directly.
<geser> does somebody know if having a \ in systemd unit name (run-vmblock\x2dfuse.mount) is supported by all the systemd packaging helpers?
<Laibsch> kindly accept the trusty nomination for bug 1395061
<ubottu> bug 1395061 in pinta (Ubuntu) "Pinta throws unhandled exception when invoking CUT (^X) or COPY (^C)" [Medium,Fix released] https://launchpad.net/bugs/1395061
<rbasak> Laibsch: done
<doko> jibel, taskcoach is failing. can you overwrite this permanently?
<jibel> doko, I am not allowed to do that, infinity can you help^
<doko> jibel, well, debian disabled the test, but it would need an overwrite too then, if we disable it?
<hallyn_> would anyone here ( infinity, pitti ? ) object to moving /lib/init/apparmor-profile-load from upstart-bin into init-system-helpers?
<hallyn_> jodh: ^ bringing it up here
 * hallyn_ biab
<rbasak> ^^ maybe one for jjohansen or jdstrand?
<rbasak> Does it even really belong in init-related stuff? Or should it be in apparmor packaging?
<rbasak> (now that both upstart and systemd have built-in apparmor profile loading support)?
<tyhicks> hallyn_: I agree with rbasak that it makes sense to provide it as part of the apparmor package
<hallyn_> tyhicks: but upstart jobs may use it
<hallyn_> *it* properly checks for whether scripts it uses are available, so that things calling it don't have to
<hallyn_> of course on ubuntu we'd rarely see a case where apparmor wasn't installed, so it would hide the problem, but i don't think it would be the best solution
<rbasak> hallyn_: in >= Vivid, we wouldn't ever have a case when an upstart job runs any more though right?
<rbasak> hallyn_: and apparmor jobs should move to using "apparmor load" instead now. So it's just support during a transition period that we need, and moving it to the apparmor package won't break that since no upstart jobs will run in Vivid.
<rbasak> Oh, I suppose phone.
<rbasak> Maybe we just need to search the archive, find upstart jobs that use it and fix it.
<hallyn_> rbasak: there may be ppl wanting to run upstart
<hallyn_> oh, right, phone too
<hallyn_> rbasak: but what is the reason to not put it into init-system-helpers?
<hallyn_> it's exactly what it is :)
<rbasak> hallyn_: apparmor isn't just for init.
<rbasak> (AIUI, anyway)
<rbasak> So why does it belong there?
<hallyn_> bc every system has an init
<rbasak> By that logic all files in the system should be moved to init-system-helpers :)
<hallyn_> simplifies my life
<hallyn_> so +1
<hallyn_> jodh: ^ ok, so if we move it into apparmor, will it break a lot of upstart jobs?
<hallyn_> putting it into apparmor is fine by me, suffices for lxc
<tyhicks> rbasak: apparmor support in systemd is still pretty basic
<hallyn> tyhicks: meaning what exactly?  that shouldn't affect whether that script can go into apparmor right?  (and you suggested it, so i assume not :)
<rbasak> tyhicks, hallyn: I get the case that it's convenient to wrap the test for apparmor into something in init-system-helpers so that init scripts don't have to each explicitly test themselves.
<hallyn> if noone (jodh, rbasak, tyhicks, infinity, stgraber) objects I can move the script
<rbasak> The functionlity itself though I think belongs to apparmor.
<rbasak> I didn't consider this split before, and I'm not sure what's where right now in terms of it.
<hallyn> rbasak: the functionality is in apparmor :)  the script is a pretty basic wrapper
<hallyn> 30 line script
<tyhicks> hallyn: no, that shouldn't affect where the script lives
<hallyn> otoh it does do some fugly checking of /sys etc, so...
<hallyn> tyhicks: so my suggestion would actually be,
<rbasak> hallyn: yeah. Looking at it I think that intelligence should be in apparmor
<hallyn> apparmor pkg gains a script with most of the intelligence, called /lib/init/apparmor-profile-load.real or soemething,
<rbasak> How about moving it to apparmor under a different name?
<hallyn> and the init-script-helpers has a wrapper script just returning nothing if apparmor is not installed
<jodh> hallyn: well we'd need to trawl all the packages, but on my vivid system only the now-unused /etc/init/ jobs are using /lib/init/apparmor-profile-load directly whilst session jobs are using the apparmor stanza (which calls /sbin/apparmor_parser directly).
<rbasak> Leave the path /lib/init/apparmor-profile-load managed by init-system-helpers
<rbasak> Make /lib/init/apparmor-profile-load a simple run-if-exists to the new name provided by apparmor
<rbasak> Then no backward compatibilty issues
<hallyn> rbasak: right
<infinity> hallyn: I don't know what I'm objecting to, but I like objecting.
<hallyn> it's usuallythe safe route
<hallyn> rbasak: do you have time to come up with proposed packages? :)
 * hallyn biab
<tyhicks> you both came up with the same proposal and it seems like a good approach :)
<rbasak> What's the appropriate path for apparmor?
<rbasak> /usr/share/apparmor/profile-load or something?
<tyhicks> I assume that the script is in /lib because it needs to be available very early in boot
<tyhicks> I don't think /usr/share will do in that case
<rbasak> Good point
<rbasak> I see /lib/apparmor is already used
<rbasak> /lib/apparmor/profile-load?
<tyhicks> that works for me
<hallyn> Laney: hey, i have a webkit-based browser that i use;  switching from utopic to vivid, when i pull up a new browser i always have to log back in (to github, lp, whatever).  it does seem to be reading my cookies file fine according to strace
<hallyn> just wondering, any idea where i woudl track that down?
<hallyn> (asking you since you see mto have merged it from debian, maybe you owrk iwth it sometimes)
<hallyn> if not i'll just start bisecting (or whatever i can do with their upstream :)
<Laney> hallyn: afraid not - try #webkitgtk+
<hallyn> ok, thx
<lefteris> Hello, i have pushed a new package to repository, that contains less files by the previous package
<infinity> lefteris: It usually helps if you tell us what package you're talking about, so we don't have to guess, and then perhaps tell us what problem you think you've caused.
<lefteris> why the extra files does't removing from the system when I install the new package?
<infinity> lefteris: If those files are in /etc, they're conffiles, and dpkg treats them specially.
<geser> in which directory are those extra files?
<lefteris> infinity: wow, ok
<infinity> lefteris: See "man dpkg-maintscript-helper", specifically the "rm_conffile" bits.
<lefteris> that's the problem
<lefteris> infinity: thx u for the help
<LocutusOfBorg1> dholbach, hi, how do you feel about sponsoring virtualbox from debian/experimental? just a bugfix release, but really important because of the conflicts fixes
<LocutusOfBorg1> should I open a bug?
<dholbach> no, sorry
<dholbach> in a call now
<dholbach> and have to figure out a few things
<dholbach> better file a bug, yes
<LocutusOfBorg1> didn't ask to sync :)
<LocutusOfBorg1> it has been just uploaded :)
<LocutusOfBorg1> well thanks!
<dholbach> rock on! :)
<LocutusOfBorg1> the question was "are we just too late in the release cycle?"
<LocutusOfBorg1> :)
<LocutusOfBorg1> syncing it (aka  bug 1433678) will be the first step to get bug 1429614 fixed I guess :)
<ubottu> bug 1433678 in virtualbox-guest-additions-iso (Ubuntu) "please merge virtualbox/virtualbox-guest-additions-iso from debian experimental" [Undecided,New] https://launchpad.net/bugs/1433678
<ubottu> bug 1429614 in virtualbox-guest-additions-iso (Ubuntu) "[SRU] virtualbox and virtualbox-guest-additions-iso doesn't conflict anymore with the official packages." [Undecided,New] https://launchpad.net/bugs/1429614
<LocutusOfBorg1> and recursively also (LP: #1371287, LP: #1375018, LP: #1385931, LP: #1386328, LP: #1421926)
<ubottu> Launchpad bug 1371287 in virtualbox (Ubuntu) "package virtualbox 4.3.14-dfsg-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1371287
<ubottu> Launchpad bug 1375018 in virtualbox (Ubuntu) "package virtualbox 4.3.14-dfsg-1build1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Confirmed] https://launchpad.net/bugs/1375018
<ubottu> Launchpad bug 1385931 in virtualbox (Ubuntu) "package virtualbox (not installed) failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1385931
<ubottu> Launchpad bug 1386328 in virtualbox (Ubuntu) "package virtualbox 4.3.18-dfsg-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1386328
<ubottu> Launchpad bug 1421926 in virtualbox (Ubuntu) "package virtualbox 4.3.18-dfsg-2ubuntu1 [modified: usr/lib/virtualbox/VBoxDDU.so usr/lib/virtualbox/VBoxHeadless usr/lib/virtualbox/VBoxNetAdpCtl usr/lib/virtualbox/VBoxNetDHCP usr/lib/virtualbox/VBoxOGLhostcrutil.so usr/lib/virtualbox/VBoxRT.so usr/lib/virtualbox/VBoxSDL usr/lib/virtualbox/VBoxXPCOM.so usr/lib/virtualbox/webtest] failed to install/upgrade: subprocess installed post-installation script re
<LocutusOfBorg1> and many many other bugs
<LocutusOfBorg1> (sorry for the noise, ubottu seems to pick up also LP: #)
<mitya57> LocutusOfBorg1: syncing is fine, but LP hasn't yet picked it up so I can't do it now
<infinity> tseliot: Any ideas on the ubuntu-drivers-common autopkgtests being completely broken?
<tseliot> infinity: I added a couple of tests but they ran fine here. I'll look into that soon
<infinity> tseliot: All looks very explodey in production. :P
<infinity> https://jenkins.qa.ubuntu.com/job/vivid-adt-ubuntu-drivers-common/lastBuild/
<tseliot> infinity:  from what I can see, even tests that I didn't touch now fail
<tseliot> I'm wondering if it has anything to do with this error:
<tseliot> ERROR: ld.so: object 'libumockdev-preload.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
<infinity> tseliot: I see that occasionally in the last successful run too.
<Odd_Bloke> smoser: How are new versions of cloud-init packaged; is it (in the general case) just `cp -r` and a changelog entry?
<tseliot> hmm... ok
<infinity> Though, certainly not as often.
<LocutusOfBorg1> thanks mitya57
<smoser> Odd_Bloke, packaged as in for ubuntu or as in for "upstream tarball"
<tseliot> infinity: I'm rebuilding using sbuild (again) to see if I can reproduce the issue
<infinity> tseliot: Might be a case of tests that pass when run in the build tree, but not when run against the installed packages?
<Odd_Bloke> smoser: Packaged for Ubuntu.
<smoser> see debian/README.source .
<smoser> for vivid, i just follow the '== New snapshot =='
<smoser> and then for releases, i do the quilt / single patch stuff
<Odd_Bloke> smoser: Ack, thanks.
<tseliot> infinity: yes, it's probably that, as the build completed successfully here
<tseliot> infinity: also, the actual exceptions show that the file that the tests execute (somehow) is not there: FileNotFoundError: [Errno 2] No such file or directory: 'ubuntu-drivers'
<tseliot> whereas that file is part of ubuntu-drivers-common
<infinity> Yay, fragile tests. :/
<infinity> AssertionError: Headers not installed for running kernel (3.19.0-7-generic)
<infinity> Why is that even tested?
<infinity> It's not like you can insmod the modules, cause you're not root.
<infinity> Oh, you are root.
<Laibsch> rbasak: thanks.
<tseliot> infinity: you need the headers to build the DKMS modules
<infinity> tseliot: They don't need to match the running kernel, though, unless you're also testing insmod.
<tseliot> infinity: well, they have to match the kernel in the chroot, as the DKMS build scripts will check that
<seb128> do we have a moderator of the ubuntu-doc list around?
<Laney> seb128: https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc lists 3 people
<seb128> oh ok
<seb128> Laney, thanks
<Laney> the last guy I pinged
<ginggs> @LocutusOfBorg: I see your LP: #1433678, do you mean sync, not merge?
<udevbot> Error: "LocutusOfBorg:" is not a valid command.
<ubottu> Launchpad bug 1433678 in virtualbox-guest-additions-iso (Ubuntu) "please merge virtualbox/virtualbox-guest-additions-iso from debian experimental" [Undecided,New] https://launchpad.net/bugs/1433678
<rbasak> infinity: ready for the removals in bug 1417328 please. percona-galera-3 is now built on all arches.
<ubottu> bug 1417328 in percona-xtradb-cluster-galera-2.x (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New] https://launchpad.net/bugs/1417328
<roaksoax> slangasek: ping
<roaksoax> slangasek: on bug #1415164
<ubottu> bug 1415164 in slimit (Ubuntu) "[MIR] slimit" [Undecided,New] https://launchpad.net/bugs/1415164
<roaksoax> err
<roaksoax> slangasek: bug #1433697
<ubottu> bug 1433697 in maas (Ubuntu) "maas depends on syslinux-dev, removed upstream" [Undecided,New] https://launchpad.net/bugs/1433697
<roaksoax> slangasek: so, syslinux-dev will continue to ship pxelinux.0 on previous uuntu releases, but pxelinux will ship it in vivid+
<slangasek> roaksoax: syslinux-dev shouldn't be the dep at all; all versions of syslinux that provided a syslinux-dev package also have a pxelinux package
<roaksoax> slangasek: right, but last cycle, utopic broke something that required us to add systelinux-dev because changes came in too late in the cycle to get them fixed, IIRC
<roaksoax> slangasek: which is why we had: syslinux-dev | syslinux-common (<< 3:6.00~pre4+dfsg-5),
<slangasek> roaksoax: it should have been a dependency on pxelinux, not syslinux-dev
<slangasek> I have the patch in progress here and will upload shortly
<roaksoax> slangasek: right, so I'm just thinking of backwards compatibility. Because the packaging for Vivid, applies for utopic and trusty
<cjwatson> The pxelinux package already ships pxelinux.0 in utopic, just under the different path that slangasek mentions
<cjwatson> As long as it checks both paths as suggested in the bug, there's no reason that wouldn't work for all of trusty, utopic, and vivid
<cjwatson> syslinux-dev is only useful as a dependency as a means to avoid having to check both paths, but if you check both paths it is not needed.
<roaksoax> cjwatson: right, i'm just concerned about dependencies in debian/control
<cjwatson> I'm not, pxelinux | syslinux-common (<< blah) is fine
<roaksoax> cjwatson: this should address the bug from the code point of view: http://paste.ubuntu.com/10622502/
<cjwatson> which is AFAICS what slangasek is suggesting
<cjwatson> right, so that patch plus Depends: pxelinux | syslinux-common (<< 3:6.00~pre4+dfsg-5).  I think you two are in violent agreement
<roaksoax> cjwatson: awesome!
<roaksoax> slangasek: so I'm just looking at extlinux package in utopic, and it does not contain pxelinux.0, the systelinux-dev package does. So in Utopic, we still need the dependency for syslinux-dev, where as for vivid we need it against extlinux. What we want to do here, is keep the same packaging for Vivid, Utopic and Trusty
<roaksoax> so s/syslinux-dev/extlinux won't just fix it
<roaksoax> if we want to maintain the mpackaging backwards compatible
<slangasek> roaksoax: I never said 'extlinux', you're looking at the wrong package
<roaksoax> slangasek: sorry my bad, yes, I see what you mean now
<roaksoax> :)
<slangasek> cjwatson: so the reason I happened to be looking at syslinux and maas was the report of bug #1429323 on ubuntu-devel.  Any thoughts on that patch? :)
<ubottu> bug 1429323 in syslinux (Ubuntu) "Hard reset during chromebook installation (with patch)" [Undecided,New] https://launchpad.net/bugs/1429323
<Unit193> robert_ancell: Not for Vivid, but since you seem to have a history with the package: LP 1295207.
<ubottu> Launchpad bug 1295207 in pidgin (Ubuntu) "Migrate to farsight 0.2* / gstreamer 1.0" [Undecided,Confirmed] https://launchpad.net/bugs/1295207
<robert_ancell> Unit193, I think I was looking at updating farsight but not specifically with pidgin
<Unit193> I put a comment on there, the last one.
<johanvdw> infinity: I noticed you pushed grass 7 to proposed - I think it is better to stick to 6.4 for now.
<infinity> johanvdw: libgdal-grass 1.11.2 seems to require grass 7, it was all interconnected.
<johanvdw> infinity: ok, will check it out
<infinity> johanvdw: Life would have been easier if we'd just stuck with the jessie versions of everything, but I think once we're getting into experimental most of the dep chain needs to come together.
<elfy> infinity: you got a handle at all on what's happening with the xorg-server issues with dailies - finding it hard to track the conversation ...
<johanvdw> infinity: The qgis grass plugin will not work with grass 7 (there is no upstream support either)
<infinity> elfy: Depends on which issue(s) you're refering to.
<infinity> elfy: The one where drivers weren't being installed should be resolved.
<infinity> johanvdw: Well, we could revert grass, and twiddle libgdal-grass to remove the 7.0 patch and lower the min required version, perhaps.
<elfy> infinity: mmm - something else then, unless it was after daily built - today's daily for us still complains http://i.imgur.com/NN3Z6wX.png
<johanvdw> infinity: seems a better approach to me, but I'll see if I can grab sebastic to get his opinion
<infinity> elfy: Oh, that's the vesa driver bug, perhaps.
<infinity> elfy: https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1432899
<ubottu> Launchpad bug 1432899 in xserver-xorg-driver-vesa (Ubuntu) "VESA error: Cannot read int vect" [Undecided,Confirmed]
<infinity> elfy: Your Xorg.log match that error?
<infinity> johanvdw: Well, libgdal-grass failed building against 7 anyway, despite claiming it shoud, so yeah.  Some rolling back might work fine.
<elfy> infinity: close yea
<johanvdw> infinity: sebastic will be joining
<infinity> elfy: Well, the "int vect" bit.  Not the exact log. :)
<elfy> infinity: yep
<infinity> elfy: Okay, mlankhorst is working on that.
<sebastic> to build gdal-grass 1.11.2 with grass64 you need to disable the grass7* patches for starters
<elfy> infinity: okey doke - thanks :)
<infinity> sebastic: Yeah, I assumed.
<sebastic> --with-postgres-includes= was added to configure for grass7, I think grass6 supported it
 * infinity removes grass 7 from proposed, and experiments.
<sebastic> if you don't generate debian/control from control.in, you need to change the Depends from grass700 to grass644
<sebastic> what are the issues with grass 7?
<sebastic> more than the qgis-plugin-grass breakage?
<mlankhorst> infinity: it's a check being inverted, so it claimed to fail but actually succeeded, I'll upload tomorrow
<infinity> sebastic: Just that, according to johanvdw.
<johanvdw> sebastic: libgdal-grass also didn't build
<johanvdw> https://launchpad.net/ubuntu/+source/libgdal-grass/1.11.1-1~exp1build1
<infinity> johanvdw: Wrong version
<infinity> https://launchpad.net/ubuntu/+source/libgdal-grass/1.11.2-1~exp1
<infinity> To be fair, that one didn't build either. ;)
<sebastic> I don't see it pulling in any grass packages
<infinity> Setting up grass-dev (7.0.0-1~exp1) ...
<infinity> Setting up grass-gui (7.0.0-1~exp1) ...
<infinity> Setting up grass (7.0.0-1~exp1) ...
<sebastic> I'm looking at https://launchpadlibrarian.net/200583936/buildlog_ubuntu-vivid-amd64.libgdal-grass_1.11.2-1~exp1_BUILDING.txt.gz
<infinity> You're not looking very hard then. ;)
<elfy> mlankhorst: just so I get this right in my mind .. if you're talking about upload for the vesa issue, will make it to Friday's dailies? Don't want to unnecessarily ask questions tomorrow is all
<infinity> Cause I just pasted from it.
<sebastic> I see now
<sebastic> checking for G_asprintf in -lgrass_gis... no
<sebastic> checking for G_putenv in -lgrass_gis.7.0.svn... no
<sebastic> checking for G_putenv in -lgrass_gis.7.0.0RC2... no
<mlankhorst> probably if it's friday
<infinity> Anyhow, if the qgis plugin issue is a problem, there's no point worrying about grass7.0, we can just revert a bit.
<sebastic> that's not the way configure acts with the grass7 patches
<sebastic> it's missing the recent changes:
<sebastic> dpkg-source: info: applying environment-typo
<sebastic> dpkg-source: info: applying grass7
<sebastic> dpkg-source: info: applying libpq
<sebastic> the grass7-configure, grass7-configure-postgres & grass7-makefile are now used
<infinity> sebastic: Well, this was a straight sync from experimental...
<infinity> sebastic: Maybe you didn't upload the version with the new patches.
<sebastic> quite possible
<sebastic> since I was waiting for exp1 to pass NEW
<sebastic> those changes are in exp2
<sebastic> I'll build & upload it now
<infinity> Either way, unless the qgis plugin issue johanvdw mentions is addressed, there's no point talking about grass7.0
<sebastic> if you can't live with that regression, sadly no
<infinity> So, I might revert to make this version build against 6.4, get the transition through, and then if we want to try 7.0 again, I can copy it back into proposed and we can play.
<sebastic> I'm leaning to disabling the plugin when I move grass7 to unstable after jessie
<infinity> sebastic: I can live with any regression, I don't use any of this software.  But johanvdw seemed to imply it mattered.
<sebastic> I hope the plugin gets fixed before then :)
<johanvdw> for me it is ok to ship without it, I just don't know if it is the right moment in the release cycle to do such changes
<sebastic> grass is an import package in GIS world, so it hurts a significant number of people
<sebastic> I don't use it personally either, but the needs of the users prevail mostly
<infinity> johanvdw: Right, I'll do the revert to 6.4, and we can re-examine 7.0 for next cycle.
<johanvdw> People will be able to install grass7 from the ubuntugis-ppa
<infinity> sebastic: I assume making libgdal-grass happy with 6.4 is just a matter of dropping the grass7 patch(es) and lowering the build-dep?
<infinity> I guess I'll find out shortly.
<sebastic> infinity: yes
<sebastic> you may also need to drop the postgres-include in d/rules
 * infinity nods.
<sebastic> it was added for grass7 too
<johanvdw> infinity and sebastic, you rock!
<johanvdw> anyway, any more issues with this migration - I'm ready to help
<johanvdw> s/migration/transition/
<johanvdw> saga in proposed is stuck because it fails to build - I did provide a debdiff with a workaround
<arges> hallyn: hey https://sysdigcloud.com/openstack-crime-story/  shows that our default settings might be able to be improved. Is there a reason we have VHOST_NET_ENABLED=0 vs 1?
<hallyn> arges: we've asked that q inthe past...  i think basically there were cases where there was corruption with it.  but i'm not opposed to turning it on
<arges> hallyn: ah, yea someboyd just brought this up to me, so I figured I'd ask. Ill look into it more deeply when I have some time
<sebastic> libgdal-grass_1.11.2-1~exp2 is in incoming now
<sebastic> thanks for getting it through the NEW queue
<cjwatson> slangasek: it looks right; it would presumably make sense to apply http://www.syslinux.org/archives/2015-February/023179.html as well, as hinted there
<cjwatson> slangasek: does indeed look like a refactoring mistake
<infinity> johanvdw: Alright, once the current batch of uploads is done building, it should all transition smoothly, and your original complaint (broken saga) should also be fixed.
<infinity> johanvdw: Remind me never to touch this set of packages again. :P
<johanvdw> infinity: Thanks a lot - and yes I will definitely think twice before issueing another sync request
<jbisch> Hi. What am I doing wrong in bug #1388396 that my package isn't being removed from Ubuntu?
<ubottu> bug 1388396 in armory (Ubuntu) "Delete armory package from ubuntu" [Undecided,New] https://launchpad.net/bugs/1388396
<infinity> jbisch: I'll take care of that now.
<jbisch> infinity: Thank you.
<infinity> jbisch: Done, and blacklisted.  And litecoin blacklisted too, for good measure.
<infinity> (saw reference to that from your Debian bug)
<jbisch> infinity: Thanks for catching litecoin too. I didn't realize it wasn't blacklisted already.
<infinity> jbisch: I would suggest that if there's a Debian bitcoin group, or just an interested sort of person, the best place for these might be in an ~ubuntu-bitcoin PPA that you guys can rev willy-nilly and just copy the sources in from Debian at will.
<infinity> jbisch: Probably makes more sense than pursuing a bunch of stable update exceptions, and gives users a more obvious view that it's constantly-changing and unstable software.
<infinity> (unstable in the "always different" sense, not a comment on quality or lack thereof)
<jbisch> Yeah, there's a small group over at Debian. I'll check with them and see what kind of interest there is in a PPA.
#ubuntu-devel 2015-03-19
<smoser> slangasek, so tonight i ask for review of the bug 1432829 fix (that i incorrectly asked about last night)
<ubottu> bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed] https://launchpad.net/bugs/1432829
<smoser> attached to bug .
<smoser> xnox, your thoguhts woudl be appreciated there too
<dholbach> good morning
<LocutusOfBorg1> ginggs, hi, can I release your "conflicts" virtualbox patch under MIT license?
<ginggs> LocutusOfBorg: hi, it's not much of a patch, it was merely a suggestion. :)  I haven't checked that those are the only conflicts required.
<flexiondotorg> mlankhorst, Did you create a new xorg-server build? Just testing the isos again and added the x-staging PPA. But I have ~ppa2. Thought a ~ppa3 was in the works?
<seb128> flexiondotorg, he just uploaded the fix to vivid
<flexiondotorg> seb128, Thanks. mlankhorst Excellent :D
<flexiondotorg> seb128, mlankhorst I'll wait for that to propagate and test later.
<rbasak> hallyn: I'm thinking something like this: http://paste.ubuntu.com/10626570/
<rbasak> Does everything that needs /lib/init/apparmor-profile-load correctly depend on init-system-helpers already?
<rbasak> (I've not tested these patches)
<rbasak> jodh, tyhicks: ^^
<rbasak> The [ -x /sbin/apparmor_parser ] is now redundant, but I've left it there so the move is simpler to follow (rather than change the file while it's being moved)
<zyga> hmm, how do I get a .source.changes file with sbuild? I've tried all weird combinations of -s --debuilt-opt=...
<rbasak> zyga: I use -S and just get one.
<zyga> I want to backport a package from vivid to trusty and I want to upload .source.chanegs to a ppa
<zyga> rbasak: sbuild -S ?
<rbasak> Yep
<zyga> rbasak: er, no
<zyga> rbasak: no such option
<zyga> rbasak: *sbuild*
<rbasak> Oh, I'm sorry.
<zyga> rbasak: not dpkg-buildpackage
<rbasak> I just sbuild on the .dsc with no special parameters, after -S to buildpackage.
<zyga> rbasak: I'm on vivid and I suspect that the source package should be built with the trusty chroot
<rbasak> Oh
<rbasak> Hold on.
<zyga> (maybe I'm wrong)
<rbasak> I get the source changes with dpkg-buildpackage -S
<rbasak> No need to run sbuild at all.
<zyga> but that still runs debian/clean, right?
<rbasak> It's a source-only upload after all.
<zyga> on the host
<rbasak> It does, yes. Which is annoying because I don't usually have build deps installed.
<zyga> and that may need build-deps
<rbasak> So I use -nc
<zyga> rbasak: you are right but I want to understand how to do it correctly
<rbasak> (and make sure the tree is clean, and check with debdiff afterwards to be sure)
 * zyga tries
<rbasak> I'd love to know if there's a better way.
<rbasak> (I don't want to see -nc deprecated for this reason)
<rbasak> I never have build deps installed on the machines I develop on. I do all builds inside schroot at a minimum.
<zyga> hmm, I didn't see .orig.tar.gz uploaded, I should have added -sa, right?
<rbasak> Yes, if needed.
<zyga> when is it needed?
<rbasak> If the archive or PPA already has it, no need.
<zyga> the tarball is in vivid
<zyga> ah, ok
 * zyga waits to see 
<rbasak> I'm not sure about vivid -> trusty ppa backport.
<rbasak> Though I think you still won't need it.
<cjwatson> Who's talking about deprecating -nc?  It's a perfectly reasonable and useful option, especially in scripted contexts.
<rbasak> There's a warning about it when I run it sometimes.
<cjwatson> Eh, it's warned forever
<rbasak> A deprecation warning.
<rbasak> Oh, it's not about -nc directly.
<cjwatson> Do you mean "building a source package without cleaning up as you asked; it might contain undesired files"?
<rbasak> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
<rbasak> dpkg-buildpackage: warning: (Use -d flag to override.)
<rbasak> dpkg-buildpackage: warning: this is currently a non-fatal warning with -S, but will probably become fatal in the future
<cjwatson> Oh right, that's entirely different
<rbasak> Yeah sorry, I recalled it wrong.
<cjwatson> Anyway, if you've just edited a package, not done anything special in its tree, and aren't relying on any clever autogeneration stuff, then "debuild -d -S -nc" is perfectly reasonable
<rbasak> Thanks. I had just never used -d.
<rbasak> Any thoughts on making scripts supplied in debian/ executable in the tarball vs. marking it executable via debian/rules?
<rbasak> upstart's apparmor-profile-load did the latter.
<rbasak> I think I prefer the former.
<zyga> rbasak: it worked, package built fine
 * zyga puts piglit trusty + vivid packages into a test ppa
<rbasak> zyga: \o/ sorry for my confusion
<zyga> rbasak: thanks for the help!
<rbasak> It "just happens" so I never really thought about the details!
<didrocks> flexiondotorg: FYI, xorg fixed some kvm issues making autopkgtests failing FYI, so I guess you should be good with the version in the archive (still only in -proposed now)
<infinity> rbasak: Executable bits in debian/ are dependant on source package format.  For v3 packages or native packages, because it's a tarball member, you can rely on it just working, for v1 non-native, you need to do it in rules, since debian/* is a diff, not a tarball, and you can't express file metadata in diffs.
<rbasak> Aha. That makes sense. Thanks!
<infinity> rbasak: People who flip-flop between source formats a bit tend to just always do it in rules to prevent being bitten.
<rbasak> upstart is 1.0 non-native, so it would make sense why it was being done there.
<zyga> hmm, how can I teach my sbuild the key needed to access a ppa (I'm using --extra-repository)? ideally I'd like to do that on a per-build basis as I don't want to have many chroots
<zyga> there's the --chroot-setup-commands option
<zyga> but I'm not sure what apt-key magic to use to add a ppa-specific key
<rbasak> apt-key add /path/to/key.pub
<zyga> rbasak: oh that's just too easy, thanks
<rbasak> There might be a better way with these new-fangled sbuild options though.
<zyga> I always use add-apt-repository but it has way too many dependencies to use here, I think
<zyga> rbasak: yeah, I looked but nothing popped up
<zyga> the --extra-repository option is awesome enough though
<infinity> zyga: Either use apt-key, or just configure the PPA with something like add-apt-repository on another system/chroot, let it do the hard work, and then copy the /etc/apt/trusted.gpg.d/ppa-name.gpg in.
<infinity> It does seem like extra-repository could use an extra-repository-keyring option to go with it, though.
<zyga> yeah, I totally agree
<zyga> so looking at this key (reached from the ppa, page) I just copy that somewhere and use apt-key add
<zyga> http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x3DF628E6E62E6AAB
 * zyga tries
 * zyga needs a bind mount for the key perhaps
<zyga> or a better command to get the key
<zyga> inside the chroot
<zyga> heh
<zyga> ironically this image is the best way I found so far https://launchpad.net/+help-soyuz/images/add-apt-repo2.png
<zyga> and there's no text version
<zyga> and that's ... warty?
<zyga> wow time flies
<rbasak> warty? Did gwibber exist then?
<zyga> the theme looks from that age though
<zyga> sbuild -d trusty  --extra-repository='deb http://ppa.launchpad.net/zkrynicki/piglit/ubuntu trusty main' --chroot-setup-command='gpg --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv EECD2FED2EB41383F931DEF63DF628E6E62E6AAB'
<zyga> that's the magic that works without anything extra added
 * zyga wants someone to make a new sbuild from scratch, that's EASY and has great defaults
<zyga> that's not just for debian core developers but also for people like me that have different workflows
<rbasak> It would be nice to just have a --ppa option
<zyga> yep
 * zyga builds piglit :-)
<infinity> zyga: I don't think a new sbuild is needed, but a simple wrapper for people with more limited usecases wouldn't be too hard.
<infinity> zyga: One just needs to define what those limited usecases *are*.
<infinity> zyga: I still think what we need for occasional Ubuntu/Debian devs (people doing one-off test builds, whatever) is a simple "build-it-like-a-buildd-would package.dsc"
<infinity> zyga: Which would be a wrapper around grabbing a chroot tarball and calling sbuild in a buildd-compatible sort of way.
<zyga> infinity: I think that was tried a number of times. I think the problem with wrappers is that they don't fix design problems have ways around things like ~/.sbuilrc breaking whatever the wrapper may want to do. There are ways around that but I think wrappers are never as good as a great solution.
<zyga> infinity: the amount of tinkering from defaults to get a working trusty sbuild is an example
<zyga> infinity: add sbuild profile
<zyga> infinity: add eatmydata
<zyga> infinity: do the bind mount to avoid downloads
<infinity> Lots of that isn't required...
<zyga> infinity: (and it's still not going to work offline really)
<zyga> infinity: well, it's an opinion
<zyga> infinity: (do more more more things for a feeder achive)
<zyga> infinity: I think they are because without them packaging is a pain to do
<infinity> Sure, there are lots of options.  But lots of options are orthogonal to wanting a thing that's easy to use.
<zyga> infinity: all of that should be default
<zyga> infinity: then lintian, piuparts (which never worked for me no matter what I tried, adt)
<zyga> infinity: I agree it depends on what you want to do
<zyga> infinity: but the case that sbuild has lousy defaults for 2015 is a good one, I think
<zyga> infinity: it's like motif was cool and there were themes to make it look nice
<zyga> infinity: but no amount of themeing will make it like modern OS
<zyga> infinity: I tried to do a wrapper for myself a number of times but it always failed on something (and I learned a new thing at the same time)
<zyga> infinity: there's just a lot of complexity there
<zyga> infinity: but also old designs and stuff people cannot reuse now (shell, perl) for writing a better tool
<infinity> zyga: I question the assertion that people can't use shell and perl. :P
<zyga> infinity: for new quality tools?
<infinity> Yes.
<zyga> meh
<zyga> I disagree
<zyga> perl is an ecosystem going under and shell is just useless for programming
<infinity> Disagree all you want, but language doesn't determine the quality of the output, the programmer does.
<zyga> unless it's running options with --sbuild
<zyga> infinity: sure
<zyga> infinity: but ecosystems matter
<infinity> And each tool in its place.  shell isn't for highly complex tasks, but it works for smaller things.
<zyga> infinity: doing a new tool in perl today indicates that someone is out of touch with reality
<zyga> infinity: I agree on shell
<zyga> infinity: but sbuild is big
<zyga> infinity: and the task is not suitable for a shell program
<zyga> infinity: especially if you want the program to be better and smarter than what we have now
<zyga> infinity: e.g. non-executable configuration perhaps
<infinity> I also disagree that the perl ecosystem is "dying", it's alive and well.  But to people always chasing the new hotness, I can understand how "a module it good enough that it doesn't need to be changed every two weeks" looks like "stagnation".
<zyga> infinity: it may be lively but it is a niche and one that is shrinking compared to the overal ecosystem using arguably better tools
<zyga> infinity: perl is a horrid language
<infinity> Anyhow, the important bits of sbuild and schroot have been C++ for ages.
<zyga> infinity: like the bits around dpkg and apt?
<infinity> zyga: "horrid" is a matter of opinion, not fact.  Surely, you see that?  I think python is "horrid", but that doesn't stop (many) others from seeing the beauty in it.
<zyga> infinity: yeah, that's good, those tools are complex but I wouldn't go on replacing them :)
<zyga> infinity: no, horrid is a matter of opinion but perl is just bad as a language, it's got a big bag of mistakes that people know not to do, that's not an opinion, that's a fact
<zyga> infinity: I'd love to see an argument for beauty there but I have yet to find one
<zyga> infinity: then implementation quality matters too
<zyga> infinity: but let's not make it a perl topic
<zyga> I was surprised by one thing, reading dpkg changelog
<cjwatson> You say that after filling my screen with a language war.
<zyga> that some patches for osx were added
<zyga> cjwatson: sorry, that was not my intention, I wanted to focus on highlighting opinions vs facts that are relatively undisputed
<zyga> I wonder what's the motivation for dpkg on osx
<infinity> fink.
<zyga> hmm, osx is a curious mixture of environments
<infinity> OSX devs come in two flavours: People who desperately wish it was more like a Linux distro, and... All the people who are wrong.
<infinity> (No bias here)
<zyga> infinity: heh :)
<rbasak> infinity: poke to do bug 1417328 for me please
<ubottu> bug 1417328 in percona-xtradb-cluster-galera-2.x (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New] https://launchpad.net/bugs/1417328
<rbasak> I don't forsee any issues, but I'd like to see the whole thing cleared up and 5.6 landed in case things appear that I need to fix up.
<infinity> rbasak: I'll look in a bit.  In somewhat of a glibc groove here, and don't want to get any more distracted than I already am.
<infinity> I should probably close this window. :P
<rbasak> OK thanks
<brendand> if i don't specify -B to adt-run then it tries to build the binaries, which is what i want, but it complains:
<brendand> dpkg-buildpackage: error: fakeroot not found, either install the fakeroot
<brendand> package, specify a command with the -r option, or run this as root
<brendand> i have this installed though, is this maybe because it's trying to do the build on the testbed (ubuntu touch device in this case)
<rbasak> Yeah you'll want fakeroot on your testbed
<rbasak> Or some other way to get root on your testbed
<rbasak> I would build the package locally, and then test on the testbed without build dependencies or fakeroot there.
<rbasak> (ie. separate the build environment from the test environment, rather than having them combined)
<rbasak> You can use -B to separate them, by building packages first eg. with sbuild
<Laney> Riddell: howdy, do you know if anyone's looking at kde-baseapps autopkgtest failure?
<Riddell> Laney: yeah I'm on it now, I'll just patch it out I guess
<Laney> up to you - it's weird that the check thinks it has internet access but the test goes on to fail
<Laney> but thanks
<Riddell> mm
<hallyn> rbasak: looks perfect - xcept the breaks/replaces should be against upstart-bin, not upstart, iiuc.
<rbasak> hallyn: oh, good point - thanks.
<rbasak> hallyn: do you know that jobs will correctly pull in init-system-helpers?
<hallyn> what do you mean?
<rbasak> Currently things that expect /lib/init/apparmor-update-profile to exist just call it, but presumably they depend on upstart-bin, so it's definitely present.
<rbasak> Now these things need to depend (maybe indirectly) on init-system-helpers instead, in order to not break.
<rbasak> So do we know this is the case?
<hallyn> rdepends list is pretty long, but seems random
<hallyn> cgmanager and lxc both depend on it
<hallyn> cloud-init
 * rbasak wonders what else uses it
<rbasak> Is there any easy way to grep the entire archive?
<hallyn> i'm looking at apt-cache rdepends init-system-helpers | sort | less
<hallyn> msut be something common in there i'm just not seeing it :)
<rbasak> Perhaps you're expected to depend on it explicitly.
<rbasak> In which case what matters are the recursive reverse depends on upstart-bin, which shipped /lib/init/apparmor-update-profile previously
<rbasak> Perhaps the init scripts that depended on it existing (eg. didn't test -x) just assumed it would be there, and it was on all Ubuntu because of upstart-bin.
<hallyn> man ..  i'm sure it's obvoius, but i'm not finding it
<infinity> hallyn: All those init-system-helpers deps (or most) are coming from dh_systemd.
<infinity> rbasak: The "pleasant" automated way to fix this would be to make dh_installinit grep init scripts for apparmor-profile-load and add init-system-helpers to misc:Depends, but you'd still need to identify the right packages to rebuild to make that work.
<smoser> xnox, in systemd, what all runs 'ifup NIC' ? is it more than the ifup@ service ?
<flexiondotorg> didrocks, mlankhorst seb128 Just tested the new xorg-server. Looks good. Thanks for your help!
<seb128> flexiondotorg, yw!
<flexiondotorg> seb128, Looks like another bug got fixed too.
<seb128> which one?
<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]
<seb128> great
<flexiondotorg> seb128, Just confirming.
<flexiondotorg> seb128, Nuts.
<flexiondotorg> Sadly not.
<flexiondotorg> The pp2 version that yanked redBIOS did fix the bug above however ð
<flexiondotorg> *ppa2 version from x-staging
<xnox> smoser: not so sure, i believe there is networking job that parses /etc/network/interfaces and then does magic
<xnox> should be udev triggered as well.... on nic bring ups....
<xnox> dunno, talk to debian people.
 * xnox uses systemd-networkd / network manager
<bdmurray> seb128: is there a bug reference for your unity-settings-upload to trusty -proposed?
<seb128> bdmurray, did I forget to include that in the changelog?
<bdmurray> seb128: yes
<seb128> bdmurray, sorry, let me fix that and reupload
<seb128> bdmurray, thanks for spotting it
<bdmurray> seb128: no problem
<seb128> bdmurray, k, rejected the old one, new one in the queue
<bdmurray> robert_ancell: your upload of lightdm in the precise-proposed queue should supercede the existing upload correct?
<robert_ancell> bdmurray, yes
<robert_ancell> bdmurray, I probably should have marked the patch as fixing bug 1431654
<ubottu> bug 1431654 in lightdm (Ubuntu) "lightdm (1.2.3-0ubuntu2.6) 100%/high cpu usage" [Critical,Fix committed] https://launchpad.net/bugs/1431654
<bdmurray> that would make things clearer and allow it to be verified
<robert_ancell> bdmurray, do you want me to re-upload?
<bdmurray> robert_ancell: I think that'd be best, yes please
<robert_ancell> ok
<robert_ancell> bdmurray, new version should be there now
<bdmurray> robert_ancell: okay, accepted
<robert_ancell> bdmurray, thanks
<Peaker> Hi, is there a channel dedicated to network-manager specifically?
<Unit193> Heh, was about to say their wiki claims #nm.
<cyphermox> Unit193: indeed, it's #nm
<Unit193> Heh, it's a secret (+s) channel.  And dang, was supposed to file a bug for you...
#ubuntu-devel 2015-03-20
<StevenK> RAOF: O Hai
<RAOF> StevenK: Yo!
<StevenK> RAOF: So, I bought a GeForce GTX970 yesterday ... and Trusty does not love it at all
<StevenK> RAOF: I thought LTS releases were supposed to get updates to support new hardware?
<StevenK> From what I can see, only Vivid has a new enough version of the binary driver to support the card.
<RAOF> It should get ported back, yes.
<StevenK> RAOF: Do you keep tabs on where stuff is up to, or that more someone else?
<RAOF> You'd be looking for tseliot
<StevenK> I thought so
<StevenK> RAOF: In the mean time, I need fresh crack?
<StevenK> The description for that PPA is not very encourging :-P
<RAOF> StevenK: rmadison nvidia-current tells me that trusty-updates has the same version as vivid.
<StevenK> RAOF: nvidia-346 exists in Vivid
<RAOF> Ah. nvidia-current is a lie.
<RAOF> Good, good.
<StevenK> Yes -current is not current at all
<RAOF> Hm.
 * RAOF heads out to lunch.
<StevenK> RAOF: Huh. So installing nvidia-346 from the edgers PPA ends up gnome-terminal only showing as a black box
<StevenK> If I click in the right area, it does close, at least
<tjaalton> nvidia-current-updatest
<tjaalton> -t
<tjaalton> latest in -proposed i guess
<StevenK> tjaalton: rmadison doesn't show -proposed, but current-updates in trusty-updates is still only 304.125
<tjaalton> oh right, not -current* anyway :)
<tjaalton> 346.47 was uploaded to vivid last week
<tjaalton> so looks like it's not uploaded to trusty yet then
<StevenK> It looks like my three choices are, 1) Have no X at all, 2) Have a broken X, due to -edgers or 3) Install 346 myself and hopefully everything works
<StevenK> Frankly, all of those options suck.
<tjaalton> don't pull all of edgers
<tjaalton> just the driver and then disable it, or use apt pinning
<tjaalton> it=the ppa
<StevenK> tjaalton: Which the descriptions for -edgers said do not do
<tjaalton> wonder why
<tjaalton> since the blobs aren't tied to any specific driver abi
<infinity> StevenK: Just install the blob from vivid, they're blobs+dkms, the release they're uploaded to is irrelevant.
<StevenK> infinity: Just rebooted, to make sure X libraries didn't contaminate RAM or loaded libraries, and I have lightdm up, so that's promising
<StevenK> Haha. But gnome-terminal is still just a black box
<infinity> StevenK: I'd say you get to take up that bug with the people whose binary driver you're using. :P
<StevenK> Blah
<happyaron> cyphermox: hey, wonders what's the status of the SRU for bug 1325801?
<ubottu> bug 1325801 in Ubuntu CD Images "failed to boot from USB disk with error: gfxboot.c32: not a COM32R Image boot:" [Undecided,In progress] https://launchpad.net/bugs/1325801
<tjaalton> what's the story with gpg-agent/ssh-agent, I still don't have them on a vivid session
<tjaalton> there was a bugreport at some point
<tjaalton> huh, works on my laptop though
<tjaalton> gnome-keyring-gpg that is
<tjaalton> ah, it's just run so late that my terminator shells didn't get that..
<donniezazen> The design tab of Qt-Creator is grayed out on my Kubuntu 14.04 box. Anyone would know why?
<didrocks> smoser: assigned you bug #1434020, don't know yet if your -4ubuntu7 fixes it but worth a look still
<ubottu> bug 1434020 in systemd (Ubuntu) "With systemd 219-4ubuntu6, ifup fails on startup" [Undecided,New] https://launchpad.net/bugs/1434020
<tjaalton> hmm no. why does a single terminator shell have all the GPG stuff exported, but not one with my own layout
<tjaalton> if a terminal is started from alt-f2 it doesn't have them
<zyga> hey, vivid boot today was bad, nothing came up normally, systemd seems to have dbus issues
<zyga> I brought eth0 up maually and I'm trying to update
<tjaalton> 1434020?
<zyga> not sure, I'm in text mode
<tjaalton> "With systemd 219-4ubuntu6, ifup fails on startup" [Undecided,New]
<tjaalton> 7 available
<zyga> how do I copy / paste in screen
<zyga> ^A [ but then what?
<tjaalton> set the first mark with space
<zyga> anyway, pastebin.ubuntu.com/10632989
<zyga> that's 10K of journald logs
<tjaalton> do you have -4u7?
<zyga> looking
<tjaalton> apt-cache policy systemd
<zyga> 4u7
<tjaalton> k
<zyga> yes
<zyga> update now borked on something, looking at that :/
<zyga> policykit + dbus seem borked, this prevents configuration of udev
<zyga> tjaalton: is there a workaround for that bug?
<tjaalton> not that I know of
<zyga> tjaalton: thanks, I'll lurk around in my 90's linux console and see what happens
<zyga> ;)
<dholbach> good morning
<zyga> o/
<dholbach> hi zyga
<tjaalton> meh, something is actively cleaning up /run/shm?
<alf_> Hi all! This morning, after booting, I found my .bash_history to be 0 bytes, any ideas what could have happened? I am on (almost) latest vivid, have lots of disk space free, no signs of disk problems.
<zyga> alf_: hey, at least you got to boot :)
<alf_> zyga: :)
<mpt> Ah, bdmurray, thanks for fixing bug 1084979!
<ubottu> bug 1084979 in apport (Ubuntu Utopic) "Submitting error report asks confounding questions" [Medium,Fix released] https://launchpad.net/bugs/1084979
<Chipaca> we're past translatable texts freeze for v, yes?
<adam_magic_pack> slangasek: hi, could you please take a look at https://bugs.launchpad.net/hwe-next/+bug/1396429 ? there is a v2 patch. cert qa found this issue on more and more new machines. cc ypwong
<ubottu> Launchpad bug 1396429 in HWE Next "[Lenovo ThinkPad ?40 series] Wireless key cannot turn BT off" [High,Triaged]
<adam_magic_pack> slangasek: root cause is in patch commit message, you could give another fix if mine is ugly =,=
<adam_magic_pack> is described in commit message, I mean
 * zyga wonders if pitti is working today
<tjaalton> zyga: nope, on vacation still
<zyga> tjaalton: oh, that's not good :/
 * zyga has no working machine with ubuntu now
<rbasak> In uvtool, the uvtool package owns /var/lib/uvtool/, and the uvtool-libvirt package owns /var/lib/uvtool/libvirt/
<rbasak> I want to remove all of /var/lib/uvtool/ when the user purges both packages.
<rbasak> But the uvtool postrm runs before the uvtool-libvirt postrm.
<rbasak> So the rmdir of /var/lib/uvtool fails.
<rbasak> I'm doing rmdir /var/lib/uvtool || true, but that means that it remains after the inside is cleaned up.
<rbasak> And I have a bug report because someone thought the rmdir failing was an error (since it still printed the error even if the exit status was ignored).
<rbasak> What am I doing wrong. How should I arrange things instead?
<smoser> didrocks, :-(
<smoser> i dont think my uploda would have fixd that.
<didrocks> smoser: so, regression from ubuntu6? mind having a look?
<smoser> i'd suspect its still racey.
<smoser> regressoin from 5
<smoser> still present in 7 i suspect.
<didrocks> smoser: maybe ask the user to try 5 and reboot multiple times?
<didrocks> maybe just got unlucky and first time the races showed up for him was after latest upgrade
<smoser> well, his explanation is good.
<smoser> he diagnosed the problem well.
<smoser> and i did change the creation of that directory.
<smoser> its easy enough to fix, by just creating the dir, but do you know how /run gets mounted ? other than in the initramfs .
<didrocks> smoser: let me look quickly, I think it's at early stage of systemd, one sec
<smoser> so the short of it is , that if /run is guaranteed to be mounted when ifup@.service is run, then 'mkdir -p /run/network' there is fine.
<smoser> but we dont want those to create and use /run/network before /run is mounted
<didrocks> smoser: oh, if it's the question, it's guaranteed to be mounted even before any unit start
<didrocks> smoser: the generators are running as the first systemd setps, and they are using /run
<didrocks> steps*
<didrocks> (even before the transactional service path computation)
<smoser> didrocks, so i think then its fine to just have ifup@ do a mkdir /run/network
<didrocks> smoser: why not setting it After=systemd-tmpfiles-setup.service?
<didrocks> as you have the mkdir there
<smoser> i dont have a strong feeling on it.
<smoser> your solution forces ifup@ to run afer that, meaning guaranteed to start later (or at best same time). i dont know.
<didrocks> smoser: let's preferably do that. I think we'll have some boot speed task before LTS when we will revisit
<smoser> i suspect this all happens REALLY FAST and REALLY EARLY
<smoser> :)
<didrocks> heh :)
<didrocks> we just need to ensure to document the patch to not just drop this After=
<smoser> but after is fine with me.
<didrocks> without further thoughts
<didrocks> smoser: want to do it or should I?
<smoser> i'm happy to let you do it, but i'm also happy to do it myself as its my regression.
<smoser> but i will ask you for a review... this is my first real experience with systemd.
<didrocks> smoser: sure, please do then and poke me :)
<didrocks> smoser: if you base on the git branch, we are using gbp-pq
<smoser> juts as a bit of info, the upstart jobs did 'mkdir -p /run/network' (or equivalent)
<didrocks> (see debian/README.source)
<didrocks> yeah, but there was not this "create dir" facilities
<didrocks> let's centralize it there
<smoser> right. thats fine.
<smoser> is there a git-import-dsc ?
<didrocks> smoser: I'm mostly old-school and apply debdiff manuallyâ¦
<smoser> k
<smoser> didrocks, http://paste.ubuntu.com/10634625/
<didrocks> smoser: you need the .service suffix
<smoser> i was just checking that.
<smoser> :)
<didrocks> :)
<smoser> http://paste.ubuntu.com/10634632/
<smoser> didrocks, do you want me to create a git branch for you and push it somewhere ?
<didrocks> smoser: yeah, looks good to me. I trust more your testing with manual network setup that I would on mine
<didrocks> smoser: on git branch -> just give some patch-format files, and I'll get them applied
<smoser> didrocks, well, my testing is suspect for sure. although yesterday i did painfully walk through 6 reboots of my laptop.
<didrocks> smoser: well, we get some racing issues blocking the whole boot appearing every ~30 boots, pitti had fun bisecting!
<smoser> didrocks, aren't those just:
<smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/systemd_219-4ubuntu5_219-4ubuntu6.diff.gz
<smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/systemd_219-4ubuntu6_219-4ubuntu7.diff.gz
<didrocks> smoser: yeah, but would be nice to get some git-format patch for them (so that the commit is credited with a nice commit message). No hurry, we can deal with that next week
<smoser> k
<Riddell> is anyone able to say what's up with https://jenkins.qa.ubuntu.com/job/vivid-adt-konsole/ARCH=i386,label=adt/75/console ? "test dependencies are unsatisfiable" but it's fine on amd64
<cjwatson> Riddell: is it possible it's just skew in when builds for different architectures were available?  I can mash retry
<Riddell> cjwatson: mash retry? sounds fun
<ogra_> infinity, seems oyu made fakechroot rather unhappy with the new libc ... https://launchpadlibrarian.net/200713317/buildlog_ubuntu-vivid-amd64.initramfs-tools-ubuntu-touch_0.88_BUILDING.txt.gz
<ogra_> /usr/sbin/chroot: Â°Â§^6Ã: SHâ°Ã»HÃÃÃ¾Ã¿Ã¿Ã¿HÆÃ¬Hâ¹Â²Â(: Error 18446744073178213872
<ogra_> (but at least there is a smiley in the error)
<davmor2> ogra_: there might be several you don't know what the uncoded elements are ;)
<cjwatson> Riddell: done
<Riddell> thanks
<xnox> hallyn: https://github.com/shadow-maint/shadow/pull/4
<xnox> hallyn: also emailed the alioth mailing list
<xnox> hallyn: who are the shadow maintainers? do i need to ping anyone else?
<flexiondotorg> Is some piloting today?
<flexiondotorg> I have a few package updates I'd really like actioning so I can get some QA done this weekend.
<flexiondotorg> Nice debdiffs, super simple ð
<Laibsch> Is the mirror: protocol for apt still actively developed?
<Laibsch> or is it more likely that http.debian.net will be adopted?
<Laibsch> I'm sure many mobile users would love to have a better solution for getting their downloads
<Laibsch> I'm frequently transiting between three different countries that are 6-12 hours away by plane and have vastly different networks.
<ogra_> Laibsch, what mobile users do you mean ?
<Laibsch> people who are not always connected to the same network
<ogra_> ah, not mobile phone users then.. i see
<Laibsch> unless you are (always connected to the same network) having a fixed mirror in sources.list isn't going to be ideal
<ogra_> yeah, i thougth you referred to ubuntu on phones :)
<Laibsch> well, could be mobile phone users, too (in one of the countries, I'm frequently connected over mobile phone, sometimes as slow as 2G without edge, ouch!)
<ogra_> (we dont use apt/dpkg there(
<ogra_> )
<Laibsch> no, this is not about Ubuntu on phones, my apologies if that was confusing
<Laibsch> opkg?
<Laibsch> that's the one being used last time I was involved in embedded
<ogra_> no, its my conditional brain beeping if i read "mobile" anywhere, not your fault :)
<ogra_> no, we use click packages on the phones
<ogra_> (and "soon" will use snap packages)
<flexiondotorg> Anyone available for a little sponsoring?
<roaksoax> doko_: thanks for working on dj1.6
<roaksoax> doko_: we will do a little testg, and upload to vivid, that ok with you?
<doko_> roaksoax, sure
<roaksoax> doko_: do we need to file a FFe/MIR or anything along those lines?
<doko_> I don't think so. no new code, was already there
<roaksoax> doko_: ok, great!
<doko_> infinity, looking at the glibc cross builds, multilib-stage1.diff still not applied :-/
<doko_> roaksoax, please see mdeslaur's python-django upload and apply these to the python-django16 packages too
<mdeslaur> python-django16?
<LocutusOfBorg1> hi, can anybody please sync poedit from debian/experimental (I'm the maintainer)
<Laibsch> doko: May I ask if the code behind http://mirrors.ubuntu.com/mirrors.txt is still being actively developed?
<doko> Laibsch, sorry, I'm the wrong person to ask
<Laibsch> doko: I see. Sorry for the noise. I thought you were the one who developped the code in 2011.
<hallyn> stgraber: https://jenkins.qa.ubuntu.com/job/vivid-nova-adt-cgmanager/1/   is this a temporary failure in the infrastructure?  (I don't see any actual cgmanager tests being run there)
<stgraber> hallyn: I think the -nova ones are some test new infrastructure
<stgraber> hallyn: the one you want to look at is https://jenkins.qa.ubuntu.com/job/vivid-adt-cgmanager/
<hallyn> stgraber: ok - i got an email about the othe rone
<hallyn> thanks
<hallyn> will ignore then :)
<infinity> ogra_: Fun.
<ogra_> infinity, i guess we'll have to wait til it migrated
<infinity> ogra_: Hrm?
<ogra_> to test again ... seems to be rather unhappy if there are diferent libc versions inside and outsiode the fakechroot
<infinity> Oh, really?  That's... Poor design.
<ogra_> i tried adding -s (--use-system-libs) to the fakechroot call to force usage of the new libc ... but i get a segfault instead of the cryptic error then
<ogra_> well, fakechroot is all LD_PRELOAD stuff afaik ... so not unreasonable that it gets confused between the two libc's
<stgraber> hallyn: fginther just sent an e-mail saying to disregard any e-mail regarding -nova-
<infinity> mvo: You around?
<mvo> infinity: about to leave for dinner, sup?
<infinity> mvo: The apt autopkgtest regression doesn't look like it would be glibc's fault, but can you have a poke at it?
<infinity> mvo: When you're not busy eating. :)
<hallyn> stgraber: yeah saw it - thx
<mvo> infinity: I meant to look at it, I suspect its a race in some way, but I'm not seeing it on the debian autopkgtest and on travis and not locally, this is a bit annoying,
<infinity> mvo: Oh, you don't locally see it with glibc_2.21?
<infinity> mvo: In that case, I'll retry it a few times, and you can worry about fixing it later.
<infinity> Although, I doubt a retry will help, it seems pretty consistent in our infra.
<mvo> infinity: let me double check
<infinity> But, not related to glibc, it failed before too.  So, yay.
<mvo> aha, ok
<dholbach> LocutusOfBorg1, the casablanca update is probably not a bug fix release, right?
<dholbach> might be worth subscribing the release team there
<mvo> infinity: I might found the issue, lets see if this upload helps
<infinity> mvo: \o/
<infinity> mvo: I thought you were eating.
<Laney> mvo subsists on a diet of bugs
<dholbach> yummy
<Noskcaj> Can someone please sync gnumeric? The latest debian release has a crashfix and drops a unneeded recommend
<jamespage> coreycb, doko: as part of the python update for 14.04 we must co-ordinate with openstack upstream to get fixes landed into stable branches first
<jamespage> otherwise when we push the SRU, we'll break alot of the upstream gating process and make ourselves very unpopular
<doko> jamespage, if we update, then not before June/July
<jamespage> doko, that gives us plently of time to get fixes proposed and landed - I'll work with coreycb before then to communicate plans etc...
<coreycb> jamespage, alright.  cinder and neutron are submitted for icehouse and juno.  I didn't submit the keystone patch since it hasn't landed in kilo yet.
<jamespage> coreycb, urgh
<jamespage> coreycb, ok lemme nudge that along
<coreycb> jamespage, thx
<doko> infinity, fyi, the guile-2.0 ftbfs seems to be triggered by the new glibc, just verified
<doko> on powerpc
<infinity> doko: Where did you verify?
<micahg> Noskcaj: that release of gnumeric looks like it comes with some new features, i'd suggest filing an FFe
<smoser> i need an archive admin help
<smoser> i need to NACK 2 uploads for sru.
<smoser> curtin upload to -proposed in utopic and trusty
<smoser> actually, please ignore that statement.
<infinity> smoser: So, you don't want me to reject them?  Cause I was really looking forward to it.
<smoser> go ahead and reject if you want.
<infinity> smoser: Well, make up your mind. :)
<smoser> i have one small change
<infinity> Right.  If you need to change, I'll reject.
<smoser> please do. thank you
<smoser> infinity, thank you. now, since you're feeling nice, you could ack the entry of my replacement uploads into -proposed .
<infinity> smoser: Not just now.
<infinity> doko: Okay, guile-2.0 failure reproduced, chasing it up.
<infinity> doko: And I think I found the bug, testing a fix.
<ericsnow> how can I tell which vivid daily build I have installed?
<elfy> have you updated today?
<infinity> ericsnow: Context?  Talking read-only builds like ubuntu-core/snappy, or just regular old Ubuntu?
<infinity> ericsnow: For the latter, you can tell which media you installed *from*, with /var/log/installer/media-info, mine says "Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20121209)"
<infinity> ericsnow: But as elfy implies, what you're running depends on the day you last updated/upgraded.
<infinity> For me, that was yesterday.
<elfy> oh sorry - thought I was elsewhere tbh ...
<ericsnow> infinity: just trying to identify which vivid daily build we are running on some test infrastructure
<ericsnow> infinity: the folks who run it all are EOW
<ericsnow> (and I'm too impatient to wait until Monday to ask them)
<infinity> ericsnow: Right, well, like I said, you can see what it was installed from.  But as soon as someone runs apt-get update/upgrade, that value is meaningless.
<ericsnow> infinity: right, I expect we run update/upgrade every night
#ubuntu-devel 2015-03-21
<infinity> doko: guile failure fixed in my next upload.
<mlankhorst> can I run a script against the running xserver when it comes up with lightdm?
<mlankhorst> I'm testing with a system that has a separate device for rendering and displaying, so unless I run xrandr --auto the system won't have any outputs for the greeter
<lfrlucas> Hi. What is missing to get policykit1 updated on ubuntu? It is on proposed 16 days ago: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<mitya57> lfrlucas: according to that page the trusty sru breaks a couple of automated tests, don't know if it's a real regression or false positive
<mitya57> maybe try asking that on a weekday
<lfrlucas> mitya57: ok. Weird. This was a simple fix on policykit-1.
<lfrlucas> I wouldn't expect any kind of problem
<Unit193> Dang, no pitti.
<mitya57> lfrlucas: It may be a false positive
<lfrlucas> So what can I do to fix that?
<mitya57> lfrlucas: ask again when there is someone from the SRU team here, i.e. on Monday
<lfrlucas> ok, thanks
<mitya57> Unit193: he is on vacations...
<Unit193> Indeed, was hoping for a client to ping still. :P
<Unit193> Forgot about a fun manifestation of Bug 1431200, on the netbook, while in a GUI session plymouth half pops up broken all over the screen. :D
<ubottu> bug 1431200 in systemd (Ubuntu) "daemon-reload runs alsa-restore.service and others" [High,In progress] https://launchpad.net/bugs/1431200
<teward> stupid question but if a redirect on the ubuntu.com site is broken for a given country who do we poke
<teward> (sorry if wrong channel to ask :/_
<sladen> teward: which one?
<sladen> it's easier to help you file a bug if we know where!
<teward> sladen: well, last time i had a mirrors problem i made a ticket up on rt.
<teward> sladen: basically, it's the "Download" button for 14.10 on the main site when country=BG - redirects to a broken mirror
<teward> so by 'bug' it needs to go up to canonical sysadmin or mirror admins to remove the mirror from the list, etc.
<teward> i already filed a ticket on rt for it though :/
<sladen> yes, rt@admin is the place... so you've already done this now?
<sladen> (note it's the weekend, so things might be a bit slower)
<teward> sladen: well, i went right to rt.ubuntu.com - my email's on the fritz because my firewall is slowly exploding
 * teward is downloading the parts to reset it
<teward> apparently my firewall likes eating all outbound mail right now
<teward> so i just went to rt.ubuntu.com and filed a ticket
<teward> sladen: so basically if an issue requires canonical sysadmins or mirrors admins to act on it, put it on rt?
<teward> unless it's LP related, then complain to #launchpad xD
<sladen> correct
<teward> awesome, i'll remember that for the future :)
<infinity> rbasak: Remind me of the MySQL transition bug again?  I have some time this afternoon to poke that.
<doko> infinity, https://bugs.launchpad.net/bugs/1417328
<ubottu> Launchpad bug 1417328 in percona-xtradb-cluster-galera-2.x (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New]
#ubuntu-devel 2015-03-22
<ari-tczew> is there any ppa for arm64 / ppc64el? I found probably a patch to fix FTBFS on such archs, but I wouldn't  do mess up in -proposed...
<ari-tczew> or another way, can someone take a look on following buildlog and give a feedback, whether enabling dh-autoreconf should fix that FTBFS? https://launchpadlibrarian.net/200243699/buildlog_ubuntu-vivid-ppc64el.blktap_2.0.90-3ubuntu1_BUILDING.txt.gz
<mitya57> ari-tczew: enabling autoreconf won't fix it
<ari-tczew> mitya57: ok thanks, also upstream problem
<ari-tczew> mitya57: what do you think, is now better way to disable compiling blktap on arm64 and ppc64el? our delta is: Architecture: i386 amd64 -> Architecture: linux-any
<mitya57> Actually that error (uninitialized variable) does not look architecture-specific at all
 * ogra_ hugs infinity ... (initramfs-tools-ubuntu-touch builds again )
<mitya57> hm, maybe it's a false positive
<mitya57> ari-tczew: looks like it is a false positive: vhd_footer_offset_at_eof(ctx, &end) will either initialize end or return an exit code, which will be handled
<mitya57> a simple "end = 0;" before "err  = vhd_footer_offset_at_eof(ctx, &end);" will make it compile without that warning
<ari-tczew> mitya57: wow, nice. however, in such cases ppa for arm64 / ppc64el would be useful... anyway I have to test your fix through -proposed
<mitya57> there are landing ppas with all 6 architectures, but a very limited set of people can upload to it
<ari-tczew> mitya57: ok, so if it's very limited for VIPs, then I'll push a patch to vivid-proposed without any doubts
<mitya57> yes
<ari-tczew> mitya57: Well, I was trying to build your fix, but now it fails with the same error on i386, as well :)
 * mitya57 looks
<mitya57> oh, not i386, but arm64
<mitya57> ari-tczew: or do you mean that it fails locally?
<ari-tczew> mitya57: locally
<ari-tczew> @pbuilder
<udevbot> Error: "pbuilder" is not a valid command.
<mitya57> do you have the build log?
<mitya57> and paste the patch that you applied, please
<ari-tczew> mitya57: build log: http://paste.ubuntu.com/10650875/
<mitya57> well, you didn't include the ';'
<mitya57> actually even if you (or I) fix it, it won't migrate because of a different error
<mitya57> "blktap-utils/powerpc unsatisfiable Depends: blktap-dkms"
<mitya57> let me fix it
<ari-tczew> mitya57: odd, lame bug
 * ari-tczew is hiding himself underground
<ari-tczew> mitya57: how are you going to fix unsatisfiable depends if there is no arch provided by blktap-dkms?
<mitya57> I'm going to check if blktap-dkms builds on powerpc
<ari-tczew> mitya57: have you got a powerpc or do you have an access to VIP's ppa? :)
<mitya57> Both :)
<mitya57> well, not my powerpc, but I can test on Debian's porter boxes
<ari-tczew> mitya57: is it possible to build fine that package on Debian, but on Ubuntu's builder will FTBFS?
<mitya57> I don't think there will be any difference between Debian and Ubuntu here
<ari-tczew> ok
<infinity> ogra_: Yeah, that fakechroot behaviour is irritating.
<infinity> ogra_: But I guess I don't update glibc to new upstream versions more than once every six months, so not world-ending.
<ogra_> infinity, well, the prob is that you cant tell debootstrap to use proposed :)
<infinity> ogra_: Yeah, I've been considering fixing that.  Well, not proposed specifically, but extra sources, so that preseed netinst installs can debootstrap from updates instead of doing release-pocket-then-upgrade.
<ogra_> oh, that would be cool ... i can imagine that restriction bites in other places too
<infinity> ogra_: But debootstrap used to be pretty sensitive to Packages ordering (there's a bit of dumb luck involved), so just concatenating Packages files, which would be the naive way to fix it, might break things.
<infinity> ogra_: I think the "right" way to do it would be to pull all the source you asked for and then interlace them, or maybe even supersede old entries with new, but that's a lot more work, given debootstrap's generally simple architecture.
<ogra_> yeah
<jhenke> hi are there any known problems with the dns resolution after boot? Here it just works after cycling all connections once
<jhenke> bug #1434986
<ubottu> bug 1434986 in network-manager (Ubuntu) "Not working network connection after boot" [Undecided,New] https://launchpad.net/bugs/1434986
<infinity> Riddell: Your new upstream version of libgit2 is incompatible with one of its only 2 rdeps (libgit2-glib).
<Riddell> infinity: libgit2-glib needs to fix its abi https://lists.ubuntu.com/archives/ubuntu-devel/2015-February/038683.html
<infinity> Riddell: Whee.  Has anyone told upstream that they broke ABI?
<Riddell> infinity: not that I know of
<infinity> Riddell: Oh, wait, that's a .0 SOVER, I imagine ABI breaking is something they feel within their rights to do.
<infinity> Riddell: So, the right thing to do would just be to declare a versioned Breaks on gitg (<< 3.15) and carry on, I imagine.
<Riddell> infinity: gotcha, I'll add it to my todo
<infinity> Riddell: Ta.  It's the only thing in NBS right now, so it was sticking out like a sore thumb, hence my poking at it.
<Noskcaj> infinity, Riddell: Should libgit2-glib 0.22.0 be packaged?
<Noskcaj> and the required gitg patches
<Riddell> Noskcaj: yes please :)
<Noskcaj> Riddell, both are in ppa:noskcaj/staging
<Noskcaj> Do i need to file a new FFe, or is there an existing one i should add this to?
#ubuntu-devel 2016-03-21
<nacc> slangasek: Pharaoh_Atem: fyi: https://3v4l.org/uMrcs
<nacc> shows that the issue with zeta-console-tools test is an upstream thing, and probably something that is "expected", but shoudl be adjusted in their output
<Pharaoh_Atem> nacc: cool
<cherylj> hey cjwatson, I'm seeing a failure when doing an apt-get update for ppa:juju/devel on xenial (weak digest error).  I found bug #1556666  and wondered if we had to push a new package to get InRelease resigned in that ppa?
<ubottu> bug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [High,Fix committed] https://launchpad.net/bugs/1556666
<cherylj> infinity ^^?
<infinity> cherylj: It needs fixing on the LP end, nothing you can do about it.
<cherylj> thanks, infinity
<cpaelzer> good morning
<kickinz1> Morning!
<pitti> Good morning
<pitti> Mirv: landing-036 does not exist any more, I suppose this was taken care of already?
<pitti> slangasek: there have been no testbed config changes on my side; in theory it could be that the QEMU config on the nova-compute side got changed somehow
<pitti> slangasek: but if you can reproduce it locally, that error doesn't seem to be too specific to the qemu params in scalingstack
<Mirv> pitti: yes, we just forced QA:ing and publishing of it. no problem!
<pitti> cjwatson: will look into it, this is tracked in bug 1558823
<ubottu> bug 1558823 in Ubuntu "ddebs.ubuntu.com gpg signatures use sha-1" [Undecided,New] https://launchpad.net/bugs/1558823
<pitti> xnox: seems Stephane already approved your FFE
<pitti> slangasek: ah, I get the same thing in apport now apparently
<pitti> Failed to connect to Mir: Failed to connect to server socket: No such file or directory
<pitti> ^ that?
<dholbach> good morning
<jamespage> morning all
<cjwatson> cherylj: there may be a period (which is not the case yet) in which pushing a new package is enough to get the PPA re-signed; but we're planning to do it in bulk
<cjwatson> pitti: thanks
<cjwatson> cherylj: Note that it's technically a warning, not an error
<dasjoe> cking: #1527727 - I think Ned will release 0.6.5.6 early this week, the LLNL guys don't seem to work on weekends
<cking> dasjoe, yep, I emailed Ned for some clarification, but I will try and sync with 0.6.5.6 if it comes out this week for sure
<dasjoe> cking: behlendorf asked me whether I was aware of any ZFS issues from Ubuntu which concerned the upstream ZFS on Linux project, neither rlaager nor me could name anything relevant
<cking> dasjoe, cool, thanks for that
<dasjoe> cking: one thing I've noticed, which may not be ZFS related, is grub-pc's installation fails when given multiple disks. I had to work around this for my installation: http://paste.debian.net/hidden/24d104e9/ - see line 173
<dasjoe> I didn't copy the error message, if I remember correctly grub-pc's normal installation process works for the first disk, then fails with "can't find /dev/disk/by-id/ata-xyz,", I assume the , breaks it
<Sharcho> FYI: There doesn't seem to be any patches for GIT for CVE-2016-2324, CVE-2016â2315 on Ubuntu 14.04 LTS
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2324)
<mdeslaur> Sharcho: It's being worked on
<Sharcho> mdeslaur: thanks
<doko> Laney: any idea about https://launchpadlibrarian.net/249221907/buildlog_ubuntu-xenial-amd64.gnubg_1.05.000-6_BUILDING.txt.gz ? seems to be introduced with the recent glib
<Laney> doko: It's probably that de-duplicating thing
<Laney> doko: Copy glib-gettext.m4 from glib or remove the local copy
<flexiondotorg> Which team should I direct towards this bug? https://bugs.launchpad.net/ubuntu-mate/+bug/1559243
<ubottu> Launchpad bug 1559243 in ubuntu-mate "Missing string translations for Ubuntu MATE flavour." [High,Triaged]
<cjwatson> flexiondotorg: installer team.  I'll have a look, I think I still remember how to do that
<flexiondotorg> cjwatson, Thank you :-)
<Mirv> this signatures problem probably affects interaction with Debian too? meaning LP doesn't get updated information from Debian, so syncing of latest packages and such isn't possible.
<Mirv> "has not been picked up by LP yet"
<smoser> pitti, http://paste.ubuntu.com/15401586/ <-- were you going to upload that ?
<pitti> smoser: no, as I said it's the wrong way around; the Wants= should be added to units that want to run before the network is up
<pitti> i. e. cloud-init in that case (according to systemd.special(7))
<smoser> oh.
<smoser> hm.. that was the second part of my question.
<smoser> i dont necessarily think its the wrong way around though.
<pitti> I didn't read that properly when we talked about this
<smoser> networking.service should want the network-pre.target to have been reached.
<smoser> i'm sorry, i must have just misunderstood then. i can add Wants network-pre.target to cloud-init-local.service
<pitti> no worries, it wasn't clear last week when we talked about it
<smoser> one other question.
<smoser> you can have multple 'Wants=' in a service
<smoser> i think.
<smoser> Wants=other-thing1
<smoser> Wants=other-thing2
<smoser> that multiline syntax does work, rigth?
<smoser> is 'Wants=other-thing1 other-thing2' preferred for any reason ?
<pitti> smoser: they are exactly identical
<pitti> so just a matter of stylistic preference I guess
<pitti> multi-line is nicer for patching or adding comments, but a bit more verbose
<smoser> thats what i thought.
<smoser> thanks.
<caribou> xnox: FYI - LP: #1560024
<ubottu> Launchpad bug 1560024 in s390-tools (Ubuntu) "/etc/kernel/postrm.d/zz-zipl fails when removing an old kernel" [Undecided,New] https://launchpad.net/bugs/1560024
<cjwatson> Mirv: I explained that on ubuntu-devel recently.
 * Mirv reads
<cjwatson> flexiondotorg: Done; will require another upload to actually include localisations, so please remind us in a couple of weeks.
<flexiondotorg> cjwatson, Thanks. But I can point translators at it now?
<cjwatson> flexiondotorg: It'll probably take a little while before it's available for translation on LP.  Check first
<cjwatson> flexiondotorg: (https://translations.launchpad.net/ubuntu/xenial/+source/gfxboot-theme-ubuntu/+pots/bootloader, pick random language, search for mate)
<slangasek> pitti: yeah, wasn't a testbed change, turns out it was a genuine regression between glibc and mesa due to use of swrast on single-CPU VM guests (LP: #1559842) - thanks for looking though
<ubottu> Launchpad bug 1559842 in glibc (Ubuntu Xenial) "SIGFPE in pthread_barrier_destroy in glibc 2.23" [Critical,Triaged] https://launchpad.net/bugs/1559842
<pitti> slangasek: ah, thanks for the pointer! that means now that mesa is in it's worth retrying the failures?
<pitti> slangasek: although the glibc task of the above bug is still open, does this need a glibc fix too?
<pitti> slangasek: I tried to locally run apport against all of -proposed, and it seemed to work
<pitti> (some 3 hours ago maybe)
<pitti> cjwatson: I suppose it's ok to use syncpackage --no-lp for the time being?
<slangasek> pitti: yes, any of the autopkgtests that have regressed with glibc on amd64+i386 should be retried
<pitti> slangasek: ack, doing
<slangasek> pitti: and the glibc task can be closed, I didn't clean that up before I went to bed
<pitti> in fact, I retried a few already, and so did infinity
<slangasek> yep
<slangasek> pitti: hopefully not with --all-proposed though ;)
<pitti> I might have done apport
<pitti> but *shrug*, whatever makes them pass :)
<cjwatson> pitti: Yes, though I just requested a deployment with the gina fix so if I can twist a webops' arm then it should hopefully be sorted out today
<cjwatson> pitti: i.e. if it's not urgent it would be preferable to wait
<pitti> cjwatson: no, it's not; thanks
<infinity> pitti: So, the apport test still fails, for slightly different reasons.  The rest seem to have been fixed by Steve's mesa.
<pitti> infinity: indeed, a lot less red on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc now; I'll look at apport, but this indeed looks unrelated now
<infinity> pitti: Well, it's unrelated to the thing Steve fixed, but if you previously expected xvfb to exit and now it doesn't, either your assumption was silly or something is still a bit goofy.
<pitti> AssertionError: 'no debug symbol package found for coreutils\n' != ''
<pitti> infinity: no, the only two failures are in backend_apt_dpkg
<pitti> search for ======
<pitti> the xvfb message at the end is normal (just for debugging)
<pitti> not sure what's up with coreutils' ddebs
<infinity> pitti: Oh.
<infinity> pitti: Tests with ddebs are busted because you need to re-sign ddebs.u.c with a less crap key, IIRC.
<pitti> infinity: I did this morning
<infinity> pitti: Oh, so we should retry crash and see how it likes it?
<pitti> see bug 1558823
<ubottu> bug 1558823 in ddeb-retriever "ddebs.ubuntu.com gpg signatures use sha-1" [Medium,Fix released] https://launchpad.net/bugs/1558823
<pitti> infinity: I didn't look at crash's regression yet, but if that was it it's worth retrying indeed
<infinity> pitti: crash was much whining from apt, followed by "E: some indexes not updated", so yeah.  Pretty sure your new key will fix that, if apt now loves i.
<infinity> s/i./it./
<pitti> infinity: hmm, http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0xC8CAB6595FDFF622 exists now, but I can't say for how long already
<flexiondotorg> I will be filling a needs packaging FFe in a bit. Can some just confirm I've got the version numbering correct?
<flexiondotorg> http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/topmenu-qt/view/head:/debian/changelog
<flexiondotorg> I realise the ~xenial1.0 suffix needs to be dropped.
<flexiondotorg> This package is not going into Debian, so I want the confirm I've got the -0ubuntu1 bit right.
<infinity> flexiondotorg: -0ubuntu1 is correct for something where our upstream is ahead of Debian, yes.
<flexiondotorg> infinity, Thanks. This package will be entirely absent from Debian.
<infinity> pitti: crash's tests might be statically configured to pull the old key or something.
 * infinity looks.
<infinity> pitti: Yeah, it is.
<pitti> infinity: hm, perhaps this should pull http://ddebs.ubuntu.com/dbgsym-release-key.asc instead?
<infinity> pitti: Maybe.  What's the recommended way for people to get the key on live systems?
<infinity> pitti: Should it perhaps be packaged instead, so there's a trusty path?
<infinity> s/trusty/trust/
<pitti> I updated the key ID on https://wiki.ubuntu.com/DebuggingProgramCrash this morning
<pitti> but that won't magically fix people's scripts indeed
<pitti> infinity: hmm, we could put it into ubuntu-keyring
<infinity> pitti: Yeah, in a split file, perhaps, the way debian-archive-keyring is now laid out.
<pitti> does merely adding it to /usr/share/keyrings/ actually helps? I thought apt would expect them in /etc/apt/trusted.gpg.d
<nacc> slangasek: i'm going to file a bug upstream for that php-zeta-console-tools failure, I think. Let me see if I can patch the testrunner to skip that error
<infinity> pitti: apt wants them either added to the master keyring or in a trusted.d keyring, yes.
<infinity> pitti: ubuntu-keyring adds its own keys to the master keyring.  But shipping a snippet in trusted.d (like debian-archive-keyring does) might be better for ddebs.
<infinity> pitti: Anyhow, I'm going to "fix" crash the naive and simple way for now, but I think shipping a proper keyring would be smart.  And we'll need to look at fixing stables too. :/
<infinity> pitti: Or you could double-sign ddebs with old and new key, so the old one still works on stables.
<infinity> pitti: Which might not be awful.
<infinity> pitti: double-signing seems less evil than telling everyone to fix their stable machines that they manually configured.
<infinity> pitti: And no risk of regression (ie: falling back to the old key) on >= xenial, since apt will outright reject the old key anyway.
<infinity> pitti: Then we can work on doing it "right" in xenial, by shipping a key in the archive.
<pitti> ok, that needs some reenginering (going from "just call gpg" to "call it with multiple configurable keys")
<flexiondotorg> Wht has replaced libqt4-private-dev in Xenial?
<flexiondotorg> I need some headers that package typically provides.
<bdmurray> mpt: Do you have a moment to discuss that user page in the error tracker?
<nacc> flexiondotorg: per the changelog, debian 4:4.8.7+dfsg-1
<nacc> flexiondotorg: "  * Remove libqt4-private-dev. The only package using it is gammaray (#763852)
<nacc>     which at the moment of this writing has it fixed in it's repo."
<flexiondotorg> nacc, Thanks. Well, that's dissapointing :-(
<bdmurray> mpt: Well, I'm happy to change labels of columns and reorder them - just let me know.
<mpt> bdmurray, sure
<mpt> bdmurray, what did you mean by âRecordedâ?
<bdmurray> " I took "Recorded" to mean the time that the server received them and "Occurred" to mean when the crash actually happened on the client."
<bdmurray> mpt: so recorded in the database
<mpt> Ah, I see
<mpt> So you were thinking in terms of the database, I was thinking in terms of the client
<cking> pitti, i've got another update of stress-ng i'd like to sync to Xenial under a FFe,  bug 1560065,  I was wondering if you could eyeball it
<ubottu> bug 1560065 in stress-ng (Ubuntu) "[FFE]: stress-ng: sync to 0.05.21 form 0.05.19" [Medium,In progress] https://launchpad.net/bugs/1560065
<cjwatson> pitti: It's hopefully easily reinventable, but just in case, lp:ubuntu-archive-publishing's code for doing this isn't too impenetrable
<pitti> cking: I have zero concern about getting new stress-ng versions
<cjwatson> (Since it doesn't bother with the "configurable" bit)
<pitti> cking: responded for the records
<mpt> bdmurray, so how about âOccurredâ and âSentâ? Would that be less ambiguous?
<cking> ppisati, ok, shall I just sync it in then? ;-)
<cking> done
<bdmurray> mpt: my issue with sent was the report could be sent multiple times and if something was wrong with the database it wouldn't get recorded / received.
<mpt> bdmurray, ok, âOccurredâ and âReceivedâ? :-)
<bdmurray> mpt: also thinking about it the not occurred time is in UTC which really wouldn't be the sent time.
<mpt> understood
<mpt> I noticed the different time zones
<bdmurray> mpt: sure, Occurred and Received, in which order and with which as a link?
<mpt> bdmurray, chronological order of occurrence I think â that way, the one at the top will nearly always correspond to the last time the user clicked âSendâ (unless the DB is read-only or something weird like that)
<mpt> (the last time they clicked âContinueâ with sending agreed to, I mean)
<bdmurray> mpt: okay, thanks!
<mpt> youâre welcome, thanks for indulging me :-)
<mpt> bdmurray, â¦I just noticed that I had previously written âError reports should be listed in the order they were receivedâ, but I canât remember why I did
<mpt> bdmurray, what would happen if your system clock was accidentally set to the year 2028 when you submitted an error report? Would it sit at the top of the list for 12 years?
<nacc> slangasek: LP: #1560092 filed, with debdiff that passes the testsuite here
<ubottu> Launchpad bug 1560092 in php-zeta-console-tools (Ubuntu) "Workaround PHP bug #71870" [Low,In progress] https://launchpad.net/bugs/1560092
<bdmurray> mpt: I have it sorting by received in the database so the system clock being wrong wouldn't matter.
<mpt> Ok, so I was wrong about âchronological order of occurrenceâ above. Iâll leave that sentence untouched. :-)
<nacc> Pharaoh_Atem: https://bugs.php.net/bug.php?id=71870, just got fixed yesterday :)
<infinity> Odd_Bloke: Have you tried a powerpc cloud image with the -14 kernel yet?
<Odd_Bloke> infinity: Not yet, no.
<infinity> Odd_Bloke: Were those manual builds, or automated?
<infinity> Odd_Bloke: If the latter, can I get a pointer to one that might work, if the former, want to spin a fresh one?
<Odd_Bloke> infinity: Manual; I'll (probably) have to rebase my livecd-rootfs changes on top of what's in place now (which has had a bit of a refactor); I'll try to have something for (your) tomorrow morning.
<infinity> Odd_Bloke: Sure.  No huge rush.  Would just love to have this resolved by xenial release, so we can drop the P7 machines off a cliff.
<infinity> (or mail them back to IBM)
<pitti> meh, it seems I somehow broke ddebs.u.c. :(
 * pitti files an RT, perhaps we happen to have a backup
<infinity> pitti: ...?
<infinity> pitti: Did you wipe out your archive?
<pitti> it seems trusty's indexes only have those packages which have the same version in xenial
<infinity> Ouch.
<pitti> Laney | pitti: laney@nightingale> for r in trusty xenial; do echo -n "${r}: "; GET http://ddebs.ubuntu.com/dists/${r}/main/binary-amd64/Packages | grep-dctrl -c .; done
<pitti> Laney | trusty: 121
<pitti> Laney | xenial: 3021
<infinity> That seems ungood.
<pitti> doubleplusso
<infinity> Is the pool also empty, or just the indexes?
<pitti> the pool (otehrwise it would not be a big problem)
<infinity> Ugh.
<infinity> Not sure if IS backs that up.  I guess you'll find out. :(
<Laney> :(
<infinity> We can reconstruct anything post-ddebs-in-librarian, but you may be SOL for history.
<infinity> I hope I'm wrong.
<infinity> But it was only a matter of time before the bubblegum slipped off that shoestring.
<cjwatson> Unfortunately ddebs in librarian postdates trusty release.
<infinity> cjwatson: Indeed.
<infinity> But, hey, new LTS is upon us, if there's no backup, we can just fling our hands in the air, scream a collective "meh" and carry on knowing that xenial is debuggable. :P
<infinity> It also presents an elegant solution to the "what do we do about all these loose ddebs with no strong relation to build records?" problem.
<infinity> Which is, well.  Nothing.  Cause they're gone.
<infinity> (silver lining anyone?)
<dobey> hmm, what happened to gccgo on ppc archs in xenial?
<cjwatson> "elegant"
<infinity> cjwatson: :)
<cjwatson> http://paste.ubuntu.com/15465001/ <- that looks promising to me though.
<cjwatson> suggests that that whole tree is backed up.
<infinity> Ah-ha.  It does indeed.
<pitti> wow
<cjwatson> so a full recovery should be possible
<infinity> pitti: Hit #is-outage and get them to freeze the backups in time ASAFP.
<infinity> pitti: Cause if that's backing up with --delete, it's only a matter of time before the backup also goes poof.
<infinity> (note "snapshot_mode: none")
<nacc> dobey: i believe it's just go now?
<infinity> pitti: This is too urgent for a ticket.
<nacc> mwhudson: --^ do you have the answer to dobey's question?
<dobey> nacc: https://launchpadlibrarian.net/249463768/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321-0ubuntu1_BUILDING.txt.gz
<cjwatson> turku defaults to retaining five days, I believe
<dobey> nacc: "go: not found" doesn't sound like "it's just go now" :)
<nacc> dobey: i meant based upon my reading of the logs of the channel from last week :)
<cjwatson> ah, yes, but maybe not with snapshot_mode none
<nacc> dobey: it's "supposed" to be ? :)
<pitti> apparently I triggered a but when I told it to regenerate all indexes for the new gpg key
<nacc> dobey: looking at my logs, either stgraber or mwhudson might have the context ...
<pitti> s/but/bug/
<infinity> cjwatson: I'm not sure how that key is interpreted, to be fair, but the naive interpretation would be "oh shit".
<infinity> cjwatson: (And a perfectly reasonable default for a backup of a deb archive...)
<cjwatson> Quite.
<nacc> slangasek: i believe we talked about this previously, but if Debian has/will be releasing a new 7.0.4-X, are you ok with merging to that (as it includes the backports of a few bugfixes), or would you rather i backport those directly to our current -X in ubuntu?
<zequence> We're having some problems with our seeds (Ubuntu Studio). We've blacklisted a few unity packages, such as unity-control-center, as you can see here http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.xenial/view/head:/blacklist.
<zequence> ..but, we are still getting them on our ISO
<cjwatson> Blacklisting isn't generally what you want.
<zequence> Ok
<cjwatson> Stop trying to use it. :-)
<cjwatson> You need to arrange for apt to resolve alternative dependencies the way you want.
<cjwatson> This normally involves ensuring that suitable alternatives are in the innermost possible seed whose expansion contains any of the packages with the alternative dependencies.
<cjwatson> This can be a bit subtle and usually requires poring over germinate output in some detail.
<zequence> cjwatson: Does it have to do with the order of seeds in the STRUCTURE file?
<cjwatson> Yes.
<cjwatson> Well, sort of.
<cjwatson> It has more to do with their inheritance structure.
<zequence> Right
<cjwatson> The reason seed-level blacklisting isn't what you want is that apt doesn't know anything about it.  At best it might cause an image build to fail or something as a circuit-breaker.
<zequence> cjwatson: Thanks. Seems I have a lead. lighdm pulls in unity-greeter, which we have an alternative for
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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: barry
<infinity> pitti: Do you backport postgresql-common to old releases ever, or if I change it for xenial, can I just not worry about <= xenial legacy codepaths?
<pitti> infinity: yes, it regularly gets auto-backported on apt.postgresql.org
<infinity> pitti: Right, lecagy codepath it is, then.  That's easy enough anyway.
<pitti> infinity: and we keep it in sync, so if you change it for xenial we'll have to make that compatible with other D/U releases somehow
<showaz> bug in mlmmj deb (package) "/usr/bin/mlmmj-recieve" and "/usr/bin/mlmmj-recieve" (no manual entry for mlmmj-receive)
<showaz> bin dublicate filename bug.
<infinity> pitti: Already in hand.  Don't worry about it.
<infinity> pitti: If it supports precise trusty vivid wily xenial, is that good enough, or do you backport for EOL releases too?
<pitti> infinity: nope, p/t/w/x is fine
<pitti> (and jessie/stretch/unstable of course)
 * pitti waves good night
<nacc> caribou: would you be able to review LP: #1552983 ? fairly trivial merge for logwatch
<ubottu> Launchpad bug 1552983 in logwatch (Ubuntu) "Please merge logwatch 7.4.2-1 from Debian" [Low,New] https://launchpad.net/bugs/1552983
<infinity> pitti: Sec, don't run away yet.
<infinity> pitti: Still there? :P
 * infinity guesses he ran fast.
 * flexiondotorg sees dust.
<ogra_> he didnt run .. he waved away :)
<cjwatson> showaz: as far as I can see mlmmj-recieve is the one without a manual entry, not mlmmj-receive, and since "recieve" is a misspelling that seems OK
<cjwatson> showaz: though this is version-dependent.  anyway, reporting bugs on IRC is not useful, bug reports go to Launchpad
<showaz> cjwatson:  docs only "mlmmj-receive" http://mlmmj.org/documentation/
<cjwatson> showaz: good!  ignore mlmmj-recieve, looks like it's just there for backward compat
<cjwatson> no doubt a historical mistake
<momken> nickserv identify digitsm
<Snow-Man> â¦
<Snow-Man> try again
<sarnold> momken: oops :)
<Snow-Man> and change your pw
<sarnold> preferably something a bit stronger, too
<dobey> like 12345
<momken> it's not my password
<Snow-Man> maybe Vu~W-f]zvOzY|57GGSMLe<c;0
<Snow-Man> :D
<dobey> your password must be between 8-24 characters, and match the regex [A-Za-z0-9]+
<Snow-Man> it's the websites where the 'change password' page will accept nearly anything, but the 'login' page doesn't work with certain characters that kills me
<flexiondotorg> cjwatson, Just interested in how your wrangling is going with apt changes is going?
<rcj> arges, Do you have time to review a pending upload for SRU in bug #1559307
<ubottu> bug 1559307 in walinuxagent (Ubuntu) "[SRU] update walinuxagent to 2.1.3 in Wily" [Critical,In progress] https://launchpad.net/bugs/1559307
<arges> rcj: in a bit
<rcj> arges, thank you
<slangasek> pitti: gdnsd's i386 autopkgtest failure is curious; it's failing to install the package because it wants to start a systemd unit, which will fail if e.g. there's already a dns server installed and running on the system.  Why do we not mask systemd services as part of autopkgtests (policy-rc.d)?
<arges> rcj: is the xenial task for walinuxagent is fixed?
<arges> removing the second is
<rcj> arges, it's in xenial already
<rcj> been there for a bit
<rcj> sorry
<pitti> infinity: back for a bit
<infinity> pitti: Too late, I uploaded. :)
<doko> infinity, fyi, https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-glibc@lists.debian.org
<infinity> pitti: But do check the postgresql-common diff and grab it for Debian.
<pitti> slangasek: err no, that would be entirely wrong -- the point of autopkgtests is to check that a package works, so not starting their services would certainly (for some packages)/hopefully (for many) break their tests
<slangasek> pitti: hmm, well, ok.  what do you think we should do with gdnsd, then?  Should the package conflict with e.g. dnsmasq?
<infinity> doko: Pretty much all of those seem to be fallout from https://sourceware.org/bugzilla/show_bug.cgi?id=19439
<ubottu> sourceware.org bug 19439 in math "Unix98 isinf and isnan functions conflict with C++11" [Normal,Resolved: fixed]
<infinity> doko: And I think they probably all point to their upstreams being wrong, not glibc.  But will have to go through and fix them all.
<pitti> slangasek: if that's what it's conflicting with, yes; but I suppose that should rather be some C/R/P: dhcp-server virtual package or so?
<slangasek> pitti: dns server, not dhcp server
<pitti> right, a simple apt-get install gdnsd fails in that manner
<pitti> so, this spotted a packaging bug
<pitti> gdnsd[1745]: Failed to bind() TCP DNS socket to 0.0.
<pitti> question is why -- dnsmasq isn't even installed
<pitti> (and we don't install it by default, only -base)
<infinity> pitti: The follow-up question is why anything's bound to that on your adt VM.
<slangasek> we don't, as a rule, require packages to conflict with one another due to trying to provide services on the same port
<slangasek> oh, you see that failure even without dnsmasq?
<pitti> tcp        0      0 10.0.3.1:53             0.0.0.0:*               LISTEN      901/dnsmasq
<pitti> hm, what's that
<infinity> lsof -i TCP
<pitti> ah, dnsmasq is running, owned by lxc-dns
<pitti> ah, of course! we install lxc by default now
<pitti> lxc-common in particualr
<infinity> "we" do?
<pitti> cloud images do
<infinity> Only in cloud-image/server.
<pitti> they ship all sorts of ... unnecessary stuff these days
<infinity> Yeah, don't you already remove a bunch of cloud-image stuff we don't want in adt images? :)
<pitti> yeah, I do
<pitti> except on lcy01
<pitti> as building images is broken there
<pitti> and it recently started failing on lgw01 as well (which is in some sort of semi-broken state)
<infinity> I find "apt-get purge server^ && apt-get --purge autoremove" works well.
<pitti> so before, depending on whether you ran on a minimal adt image or a standard cloud iamge it would pass or fail
<slangasek> infinity: pro tip, 'apt autoremove --purge server^'
<infinity> Or that.
<pitti> so I guess I'll add the purging of lxc/lxd to the setup commands again
<pitti> it'll slow down every test, but avoid this
<pitti> however, this just papers over the fact that the package still fails to install on a default server/cloud install
<infinity> Any dns server will.
<slangasek> pitti: again, policy doesn't expect packages to conflict with other implementors of a network service just because they might want to share the same port
<slangasek> this definitely isn't gdnsd-specific
<infinity> I'm inclined to think it's a bit of a bug that our default cloud/server install now binds to that port.
<infinity> I hear people like to run DNS servers on servers.
<pitti> well, it can be fixed either way (not make postinst fail if the port is taken, or conflict to other dns servers)
<nacc> infinity: pitti: i can take it as an action to talk to the server team about it :)
<infinity> nacc: Please do.
<nacc> yep
<infinity> pitti: I don't think packaging needs to be sorted for force conflicts all over, but I think cloud/server images binding to TCP:53 out of the box is a massive bug.
<pitti> well, if you want lxc-net to work out of the box, you have to install a DHCP server
<infinity> DNS, you mean.
<pitti> but indeed it sucks a bit that you have to choose between "run a DNS server" and "use LXC"
<pitti> infinity: henceforth I'll just call it D* :)
<infinity> Surely, the solution is to only bind to TCP:53 on the lxc bridge.
<infinity> Which shouldn't conflict with running a real DNS server on the host.
<pitti> NMICT
<pitti> infinity: unless that tries to bind on all interfaces?
<pitti> hmm, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/g/gdnsd/20160320_184317@/log.gz actually *did* run on an adt image
<pitti> ah, so apparently apt-get purge --auto-remove lxc does not remove lxc-common any more?!
<slangasek> yes, if lxc-net's dnsmasq was bound to the lxc bridge, another server coming along and binding to 0.0.0.0 should DTRT
<pitti> ah, lxc1 now also depends on that, I guess I need to add  to my ever-increasing purge list :)
<pitti> slangasek: that sounds good
<slangasek> though I'm not sure if the lxc dnsmasq running only on the bridge IP is what's expected?  questions of resolvconf integration
<slangasek> infinity: fwiw building valgrind from svn trunk doesn't get me anything that works any better
<smoser> slangasek, so http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/cloud-image
<infinity> slangasek: Fun.
<smoser> has ubuntu-snappy
<pitti> slangasek: oh, how does that integrate with resolvconf?
<slangasek> now going to double-check whether this is a toolchain problem (rebuild current glibc with xenial)
<smoser> why is that not installed in image ?
<dobey> mwhudson: around?
<infinity> smoser: Because ubuntu-snappy is in universe.
<pitti> ok, purging lxc-common does the trick
<infinity> smoser: So germinate will cull it out of the results as an unknown package.
<smoser> i figured it would go in and create a component mismatch
<smoser> ok.
<smoser> :-(
<slangasek> smoser: it's listed in component-mismatches
<slangasek> but until it's in main it doesn't go on the image
<slangasek> I've been picking away at the MIR from the archive side over the past couple of days; ubuntu-snappy itself might be ready to go in now, I can look at that today
<smoser> i expected the component mismatch, but thought it let it in and warn rather than ignore it.
<pitti> smoser: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has a nice graph of it, FYI
<smoser> ok. thank you all. so the other question related then, pitti hinted at
<smoser> should we put 'ubuntu-server' into each of those seeds (cloud-image and server)
<infinity> No.
<infinity> Well, I put it in server already.
<infinity> Didn't I?
<infinity> Yeah, I did.
<hallyn> pitti: havne't read the whole backlog, but fwiw this week or next lxc-net should be removed from the seed again i think;
<hallyn> lxd will stop depending on it, and so it should get dropped automatically
<hallyn> at least that's my understanding
<pitti> hallyn: lxc-common you mean?
<smoser> infinity, yeah, you did.
<smoser> i will add it now to cloud-image as it is desired ther also
<hallyn> pitti: that i'm not sure
<hallyn> pitti: but lxc1
<hallyn> which has the lxc-net init job
<pitti> hallyn: but I figure lxc and lxd actually do need lxc-net (i. e. a bridge with DHCP server) to work reasonably
<hallyn> lxd will stop using lxcbr0 so it won't be needed any more
<hallyn> no, lxd will not.
<pitti> hallyn: oh, will the lxd-daemon have some builtin DHCP/DNS server then?
<hallyn> i think ipv6 only by default
<slangasek> nacc: rather than passing lots of flags to apt-cache rdepends, I bet you want to learn about grep-dctrl which has much more powerful filtering capabilities
<pitti> slangasek, hallyn: hmm, lxc-net already uses --interface=lxcbr0 and listens on 10.0.3.1:53 only
<pitti> so this doesn't help for things that bind on 0.0.0.0
<slangasek> pitti: ah, you're right - I was looking at the wrong column in netstat before
<nacc> slangasek: yep, sorry, what i meant wsa that `reverse-depends` does a (albeit slower) more accurate job of what i need
<nacc> slangasek: but yeah, grep-dctrl is also going to be handy as i trim this down
<slangasek> pitti: and if I compare with bind9, bind9 binds to each available IP individually, so that tells us nothing ;)
<pitti> so, tomorrow's auto-built adt images should not have lxc1 any more
<pitti> which should make that test work again (but it's still kinda papering over)
<hallyn> and why does lxc1 make the test fail?
<infinity> hallyn: It's a test for a dns server that fails to start because lxc depends on dnsmasq, which binds to a port the dns server kinda wants.
<TJ-> shouldn't dnsmasq be using "--bind-interfaces" to 'drop' those interfaces it isn't interested in?
<doko> xnox, pitti: ping on cmake
<doko> see email
<stgraber> note that the plan is to transition to lxdbr0 over the next week or so, that bridge will be ipv6 link-local only and will not have a dnsmasq server running against it
<infinity> stgraber: Okay, that's promising.
<stgraber> TJ-: the LXC dnsmasq absolutely does that, it only binds port 53 on the lxcbr0 interface, the problem is that all the other DNS servers in the archive assume they can bind port 53 on all interfaces which doesn't quite work when you have something bind one of the others
<pitti> hallyn: it's an actual problem with the package -- apt-get install gdnsd on a cloud image fails; it's less clear whose fault that is
<infinity> stgraber: How do guests get IPv4 connectivity?
<stgraber> infinity: the guest won't have any connectivity by default except http through a minimal proxy
<stgraber> infinity: it will then be up to the local admin to run "dpkg-reconfigure lxd" to configure lxdbr0 with some proper connectivity
<infinity> Fair enough.
<TJ-> stgraber: Ahhh, the inverse issue. Although I thought binds to 0.0.0.0 would only bind the 'free' interfaces for the port
<stgraber> TJ-: sure doesn't, bind to 0.0.0.0 requires that the port is free on all interfaces :)
<infinity> TJ-: slangasek and I thought the same thing.  Apparently we're wrong. :P
<slangasek> I'm guessing that's a kernel configurable thing
<slangasek> and/or a socket configurable thing
<TJ-> I'm sure I did just that earlier today with multiple ncat instances on the same port on different interfaces.... goes off to check
<infinity> Maybe.  Though, the current behaviour is certainly more deterministic.
<infinity> "maybe-bind()" isn't exactly debuggable.
<nacc> slangasek: i'm going through the deps for the pkgs mentioned in 1547183, looking to rebuild them as best i can. I'm trying to figure out if maybe for some that we don't run tests for, we could now (at least as autopkgtests, mabye during build too)
<hallyn> pitti: ...  i thought we had it so that installing lxc did not require full dnsmasq.
<pitti> stgraber: hm, that sounds like a step backwards for "just works"?
<pitti> hallyn: it only installs/uses dnsmasq-base, so dnsmasq's own service doesn't start indeed; but lxc-net still launches lxc-net
<hallyn> which only listens on lxcbr0's port 53.
<hallyn> so if anyone wants to listen on that, it's the bad actor
<pitti> and this is correct from LXC's perspective, just as listening on all interface is reasonably plausible from gdnsd's perspective -- these just don't work togethe r:/
<hallyn> why is htat reasonable for gdnsd?
<pitti> hallyn: yeah, I tend to agree and blame gdnsd too
<TJ-> yes; i have multiple processes on the same port on different interfaces.
<pitti> it shoudl be content to bind on "some" interfaces in the default install
<hallyn> i agree i'm worried about lxdbr0 becoming more work for ppl,
<doko> TJ-, are you still working on the openjdk backports?
<pitti> or not fail package install even if it can't bind on any, cf. slangasek's "not required by policy to have packages conflicting on port resources"
<hallyn> maybe we'll push more ppl to setting up ipv6 :)
<TJ-> ahhh, no, the script is pulling out specific IP address to bind on, not 0.0.0.0
<pitti> hallyn: well, ipv4, ipv6, you still need a DNS server, no?
<TJ-> doko: I've not touched it since we last talked as in, I didn't find any regression for my use cases with Eclipse, Tomcat
<pitti> and dropping ipv4 in containers still seems a bit premature
<pitti> as much as I like/use IPv6, it doesn't fully replace ipv4 yet
<TJ-> makes routing a lot easier though :)
<stgraber> pitti: it is a step backward in usability, yes
<stgraber> pitti: unfortunately it's the only way we can fix the installation of other DNS servers and prevent accidental subnet masking issues when LXD is installed by default everywhere
<TJ-> doko: but I've been on 16.04/15.10 for a while now so not used that build recently
<pitti> stgraber: hm, a shame -- I'd rather make the .services conflict..
<stgraber> pitti: I really wish we'd made that change early in the cycle but unfortunately it took quite a while to get all images to work when on a link-local only kind of network... anyway, it's the last thing on my todo for this cycle but it's something we do need to sort out before the LTS
<stgraber> pitti: yeah, for the DNS part we could have done something like that, though even then there are a whole bunch of packages using dnsmasq-base that will screw us over as they don't use systemd units. But ulitmately the main reason behind the change we're working on now is the subnet masking issue
<pitti> doko: cmake> well, aren't you the first one to complain if new stuff causes massive FTBFS? :-)
<mwhudson> dobey: am no
<mwhudson> w
<stgraber> pitti: that is, we do have logic to use a subnet which your machine itself isn't using, but that's not to say that the subnet we're picking isn't the one that your DNS server or some other network service is using
<pitti> doko: I have no idea how prone it is to cause problems, but I guess if someone wants to update it they should at least do a rebuildl test
<stgraber> pitti: and since we can only inspect what's directly attached to your system (routing table) and not what's behind your default gateway, we're kinda stuck
<pitti> stgraber: hard to believe that after all this years of virtualization one can't use some "private routing namespace" or something such :)
<stgraber> pitti: so that's why sabdfl asked us to not have any IP configuration by default, just use IPv6 link-local and get as good an experience as we can with that until the user provides chooses something sane
<dobey> mwhudson: hi! i'm having some trouble with go on xenial powerpc/ppc64el now
<pitti> stgraber: well, I guess as long as there's some simple way to enable it (call /usr/share/lxc/enable-bridge or whatever), it's still not too bad
<mwhudson> dobey: oh right, you are being hit by the move to coinstallable go versions being half done i think
<mwhudson> dobey: ppc64el?
<pitti> stgraber: or installing a package like lxc1 indeed
<dobey> mwhudson: yeah
<dobey> mwhudson: https://launchpadlibrarian.net/249488485/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321.1-0ubuntu1_BUILDING.txt.gz
<dobey> "go: not found"
<mwhudson> blargh
<stgraber> pitti: lxc1 will ship lxcbr0 as it always had, we won't be changing it. lxd will no longer use lxcbr0 but instead lxdbr0 which will be configured through debconf
<mwhudson> dobey: does this build-depend on gccgo [ppc64el] or something?
<stgraber> pitti: by default it'll come up as a link-local only bridge with a proxy running against it, but you can run dpkg-reconfigure to set its ipv4 and ipv6 config
<dobey> mwhudson: but all the other archs where we use gccgo are still fine
<pitti> stgraber: ah, which means that you can also enable dnsmasq in a config file
<dobey> mwhudson: yes
<mwhudson> dobey: er, we only use gccgo by default on powerpc now
<mwhudson> dobey: change the package to b-d on all arches
<mwhudson> errr
<mwhudson> dobey: change the package to b-d on golang-go all arches
<mwhudson> it'll ftbfs on powerpc for a while
<dobey> mwhudson: won't that break on vivid though?
<stgraber> pitti: yeah, our default will be to start dnsmasq only if an ipv4 or ipv6 subnet is set on the bridge, so that's why this whole thing won't be an issue once my change lands since default lxdbr0 will not have a running dnsmasq
<mwhudson> dobey: are you telling me you actually care about the status of this package on ppc64el on vivid?
<mwhudson> i mean, yes it will
<infinity> dobey: The goal in debian/control shouldn't be to make a package build on every release ever.
<mwhudson> but progress has to be possible
<infinity> dobey: Surely, you have a mechanism to fork the packaging.
<dobey> mwhudson: i'm telling you this is a package that we ship on the phone and yes the ubuntu "has to build on archs where it previously built successfully" policy
<dobey> infinity: yes but i don't hate myseful enough to want to do that
<infinity> dobey: As mwhudson says, progress must be possible.  We've made go stuff much less crap in xenial, but the result is you might have to fork packaging for backports.
<mwhudson> dobey: maybe golang-go on vivid should depend on gccgo on ppc64el
<mwhudson> which would be a change, of course
<dobey> infinity: well it's not like this works on ppc even if it did build successfully; i can happily just make it not build there any more
<mwhudson> dobey: that sounds like a pretty good solution tbh
<infinity> dobey: You might be able to fudge it with something like "golang-go (>> xenial-version) [ppc64el] | gccgo [ppc64el]"
<infinity> dobey: Er, drop it in xenial or vivid?
<dobey> infinity: but that requires me to convince someone like you that we should remove the existing binaries from xenial and the phone overlay, for the archs where this doesn't work anyway
<infinity> dobey: Really don't care about ppc64el in the vivid PPA.
<dobey> infinity: well in the phone overlay, we don't care about actual vivid obviously
<infinity> dobey: But "go is improved in xenial, let's drop the arch in xenial" would be silly.
<dobey> infinity: well, people who can block my stuff landing there will complain
<dobey> infinity: well, trying to support complining stuff on archs that it doesn't really work at runtime on anyway is probably more silly
<infinity> dobey: Try "golang-go (>= 1.6) [ppc64el] | gccgo [ppc64el]" to keep the current state of affairs and make it backportable.
<infinity> dobey: How do you know it doesn't work at runtime?
<dobey> infinity: because a whole boatload of runtime dependencies aren't built on these archs
<infinity> If that were true, it would never migrate.
<dobey> it would only fail to migrate if something were trying to actually use it on those archs
<infinity> ...?
<infinity> No, if the package deps are unsatisfiable, britney will tell you to eff off.
<dobey> there are no autopkgtests in anything that tries to perform the runtime work that fails
<dobey> yeah, that's why the package deps are tweaked to not depend on the thing that isn't available, on those archs
<dobey> ok, well i have to go now. i guess i'll try to hack around the golang-go/gccgo thing then too
<dobey> so this will build again
<dobey> later
<slangasek> smoser: so the deal with ubuntu-snappy is that it has a direct build-dependency on golang-websocket, which has an incomplete MIR (LP: #1520689).  If I promote ubuntu-snappy now to get it on the images, the tradeoff is that the snappy team can no longer upload it
<ubottu> Launchpad bug 1520689 in golang-websocket (Ubuntu) "[MIR] golang-websocket-dev" [High,Incomplete] https://launchpad.net/bugs/1520689
<slangasek> I can pre-promote golang-websocket to main, but then it becomes a problem of tracking the outstanding MIR when it isn't on component-mismatches anymore
<slangasek> or I can wait until the archive reorg changes land, which may be this week or it might be next week; then ubuntu-snappy will still be buildable without golang-websocket getting promoted
<slangasek> or I can wait until the build-dep is sorted before promoting
<slangasek> or I can promote it now and leave it unbuildable
<slangasek> smoser: ^^ those are the options; option 1 is least-preferred from my POV, maybe you can discuss with the snappy team and decide which of the others is acceptable
<cjwatson> flexiondotorg: for Debian imports, changes awaiting deployment and my expectation is that that'll be done within a day; for PPA signing, the change to make it work for newly-published archives is likewise pending deployment, and part of the change to let us bulk-re-sign existing PPAs is pending code review
<cyphermox> nacc: I'm looking at bug 1544352 but it doesn't look like some of these packages can just get no-change rebuilds and php5->php
<ubottu> bug 1544352 in Ubuntu "[PHP7] After bootstrapping, these PHP packages can automatically be rebuilt" [Wishlist,Incomplete] https://launchpad.net/bugs/1544352
<juliank> cjwatson: That sounds great :)
<infinity> slangasek: Of course, regarding the snappy versus golang-foo thing above, it occurs to me that in static linking cases, germinate really should follow Built-Using and force us to support the thing we statically linked in.
<infinity> slangasek: (ie: "wait for archive reorg" is a bit of a cop-out there)
<infinity> slangasek: In that if we refuse to support golang-foo, I can't see how we can claim we support a package that statically links it.
<slangasek> infinity: the germinate patch does implement support for Built-Using
<infinity> slangasek: Kay.  In that case, archive reorg wouldn't fix the issue (assuming Built-Using is supported as I think it should be)
<slangasek> which means the package would be buildable but there would still be a record in component-mismatches, which is what I care about
<infinity> Ahh, fair.
<flexiondotorg> cjwatson, Thanks for the update. Interesting stuff.
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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:
<nacc> cyphermox: you're probably right, some will need installation checking and such; although if they have tests, that list passed their tetss
<nacc> tests, rather
<nacc> cyphermox: oh, you didn't see the description
<nacc> cyphermox: several seds need to be run
<nacc> it's *almost* automatic :)
<cyphermox> yes, several sed commands, and ideally it would probbly be best if the command was provided
<cyphermox> tbh to me it looks very not automatic
<nacc> cyphermox: it was provided, well, the regex i used were. I can provide a complete `find` line
<nacc> cyphermox: i mean, i scripted it here :)
<cyphermox> where?
<nacc> on my machine, running an adt run against each
<nacc> that's about all i can do w/o upload rights
<cyphermox> well, almost all; you could file bugs and ask for sponsoring if the work is already done
<cyphermox> but I'm looking at adminer, it needs changes in a couple places, and in some others it should *not* be a sed because then you'll have redundancies in debian/control Depends fields, for example
<nacc> cyphermox: slangasek and i agreed filing many (~400) bugs was not necessary for the ones that are roughly automateable; but i can do that for this list if you think it's preferable
<nacc> cyphermox: what redundancies?
<slangasek> nacc: fwiw cyphermox and I were discussing this - I don't mind not filing separate bugs for each of them, but if you want automated conversion of these packages, please provide us the automation code you want run + details of any testing of the results
<cyphermox> php | php, for instance
<nacc> slangasek: yep, I can do that
<cyphermox> because some packages mention php5 | php
<nacc> cyphermox: i don't see how that will ahppen to adminer
<slangasek> nacc: otherwise, if the "automation" is incomplete and should be captured as a debdiff, then there should be separate bugs for each
<nacc> the result of the sed is
<nacc> lite | php-pgsql
<nacc> gah
<cyphermox> nacc: this isn't adminer but I did see one instance
<slangasek> cyphermox: well, dpkg-buildpackage is awfully smart these days, so php | php will be reduced :)
<nacc> cyphermox: i'm happy to clean those up as i encounter them ... they didn't lead to an error, per se
<cyphermox> slangasek: but it won't change the actual debian/control file uploaded
<nacc> cyphermox: i am taking what you say to heart
<nacc> slangasek: i can provide debdiffs for these that needed the sed
<slangasek> cyphermox: true, it won't, but at runtime it'll be fine
<nacc> it will be a better review anyways, as a result
<cyphermox> I mean, the list looks otherwise pretty good, and the work isn't complicated; it just takes a bit to go through it and upload each
<nacc> cyphermox: admittedly, it's just a matter of time
<cyphermox> (I already download all the source)
<cyphermox> *downloaded
<nacc> and there's still about ~100 or so packages after that that did build w/ some tweaking to the sed and then another ~100 that need manual remediation
<nacc> we package a lot of *old* php stuff :)
<nacc> it's unfortunate, what with composer being the upstream-prescribed (and only approved) way to install things, often
<cyphermox> a couple things also ship apache config, we'll need to make sure those get changed too
<slangasek> reminder, old and crufty stuff can also be removed if we don't think it's worth fixing
<nacc> cyphermox: yep, that's one thing i needed to manually go back and fix in some packages
<nacc> slangasek: agreed, and several of them have been superseded int eh archive already, we just carry two versions
<nacc> one of whcih might be EOL at this point :)
<nacc> cyphermox: slangasek: thanks for the feedback. I'll try to be clearer in the bugs (that one in particular, I filed when I first started looking at PHP7, so I should have amended it since then).
<cyphermox> I fixed up a simple tracker config for this, I'll push my code
<nacc> cyphermox: is a tracker like what debian has for following the php7 migration? there's a page that reports any package that right now depends on a src:php5 package?
<cyphermox> yes
<nacc> awesome, thanks! i was going to ask if we had something similar, but had forgotten :)
<cyphermox> it's kind of naive; just checking if it Depends or Build-Depends on something called php5.*
<nacc> cyphermox: i mean, that's basically what my scripting is doing :) i'm ok with naive for now
<nacc> slangasek: sigh, i don't know why php-zeta-console-tools failed. It didn't emit any output that indicates what actually failed?
<nacc> slangasek: and it passed all tests during the build and in my systems' autopkgtests (running it again now to be sure)
<nacc> slangasek: confirmed, in my adt-virt-lxc run, all 744 tests passed
<nacc> slangasek: something seems off with the log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php-zeta-console-tools/20160321_202400@/log.gz
<nacc> i think you should see "test phpunit: [----
<nacc> followed by a patching line
<nacc> then PHPUnit output
<nacc> then another patching line (as the patch is reverted)
<nacc> then "test phpunit -----]
<slangasek> nacc: I can reproduce the php-zeta-console-tools autopkgtest failure here
<slangasek> nacc: in fact, phpunit does nothing but exit 255 for me here
<nacc> slangasek: so confused. i literally just ran it here; and it clearly ran succesfully during the build
<nacc> slangasek: from which directory location are you running it?
<slangasek> nacc: what is supposed to provide ezc/ConsoleTools/autoload.php?  Because I don't see that file under /usr/share/php/ on my system.  Is this from a newer version of some package which is currently only in xenial-proposed?
<slangasek> oh, maybe it comes from php-zeta-console-tools itself, and I should actually install the xenial-proposed version of the package I'm trying to test?
<nacc> yeah, i htink that's the case
<nacc> slangasek: and that's probably the issue, the d/t/control doesn't depend on itself?
<slangasek> nacc: no, that's not the problem
<slangasek> that's just the first error I hit locally, not necessarily the real problem on the autopkgtest infra
<cyphermox> you could get a console in the autopkgtest environment to check exactly what fails in the infra
<nacc> slangasek: ok, so if i don't build during my autopkgtest run, i see the same error now; but if i build, i don't.
<nacc> let me see if i can see why
<slangasek> nacc: ok, it's looking for /usr/share/php/ezc/Base/autoload.php, but there's no versioned dep on php-zeta-base
<slangasek> well... there is a versioned dep, but the versioned dep doesn't ensure that file's existence
<Umeaboy> In Xenial I see no menus when moving the cursor to the top bar.
<Umeaboy> Is that expected?
<Umeaboy> I know that it's a testing version of Ubuntu so no need to tell me that again.
<Umeaboy> Just wondering how I can get it back without having to downgrade Ubuntu.
<slangasek> nacc: upgrading php-zeta-base fixes it; so php-zeta-console-tools *should* have a versioned dep on php-zeta-base, I think?
<nacc> slangasek: it does, though? on php-zeta-base >= 1.9-2~
<cyphermox> Umeaboy: I know some apps didn't show me menus in unity; best is probably that you file a bug.
<nacc> slangasek: or do you mean only certain version of php-zeta-base have the file?
<slangasek> nacc: depends, not build-depends. the depends is on php-zeta-base (>= 1.8), php-zeta-base (<< 2~~) which is insufficiently strict
<Umeaboy> And also...... when you translate "Add to Dash", do you also translate the name Dash?
<Umeaboy> Just making sure.
<cyphermox> I don't know
<nacc> slangasek: ah! sorry
<slangasek> nacc: 1.9-1 doesn't have it, maybe it only shows up when rebuilt with the php7 package toolchain?
<Umeaboy> Anyone else that knows?
<Umeaboy>  ../launcher/ApplicationLauncherIcon.cpp:717
<cyphermox> Umeaboy: it might be better to ask about this on #ubuntu-unity
<Umeaboy> is the location of it.
<Umeaboy> OK.
<cyphermox> Umeaboy: and/or compare with other languages
<nacc> slangasek: so there should be a versioned dep on php-zeta-base, maybe on >= 1.9 ?
<slangasek> nacc: no, >= 1.9 is *not* sufficiently strict.  The php-zeta-base in xenial is 1.9-1, and that package doesn't have the file we're after
<slangasek> nacc: so if ezc/Base/autoload.php needs to be there for the package to work, it needs to be >= 1.9-2build1
<slangasek> nacc: or possibly just 1.9-2 - it's not clear to me if this was a packaging change or a tooling change
<slangasek> nacc: of course, 1.9-2 never built in Ubuntu, so either of those works the same for us - but it definitely needs to be >> 1.9-1
<doko> nacc, slangasek: the last test rebuild showed up a lot of php related build failures. are these now resolved with the recent 7 changes?
<slangasek> doko: they still need worked through; we're basically mid rebuild transition
<slangasek> doko: things that build-depend on the standard php tooling, but depend on other extensions that are currently built for php5, probably FTBFS
<doko> slangasek, ok, would like to start one more test rebuild once glibc migrates + outstanding debian syncs
<slangasek> nacc: does my explanation for php-zeta-console-tools make sense? would you like me to plunk it in here, or do you want to send me a debdiff?
<nacc> slangasek: yes, it makes sense, thank you for clarifying
<nacc> slangasek: feel free to plunk :)
<slangasek> nacc: done
<nacc> slangasek: thanks! fwiw, i just got icinga to run (mostly) its own tests. The errors it's tripping now are because i don't have mysql setup in my container, but no syntax errors
<slangasek> nacc: ok.  and I think I left questions for you on php-opencloud
<nacc> slangasek: fyi, also, it's a packing chagne, i just tried building php-zeta-base 1.9-1 and 1.9-2 and only the latter has the file where expected
<nacc> slangasek: yep, getting to that one too
#ubuntu-devel 2016-03-22
<slangasek> pitti: I see you demoted xchat-indicator to -proposed when removing xchat from the archive; rather than removing it?  and no bug filed?
<nacc> slangasek: just to confirm, does that error from lintian occur for the -doc package? i think the old pacakge has a lintian-overrides file that refers to some of the sphinx files
<slangasek> nacc: it shows up on the source package
<slangasek> nacc: so lintian foo.dsc
<nacc> slangasek: yeah, i think the old pacakge built using dh_sphinxdoc? and symlinked the _static/ dirs to the ones provided by sphinx-rtd-theme
<slangasek> nacc: however, this pertains to the contents of the source package; somehow the same version of lintian thinks source is present in the previous package version, but not in the new one
<nacc> slangasek: ah, i think i see what changed
<nacc> slangasek: i don't belieeve the old source actually contained, e.g., modernizr.min.js, and i see no reference to it in the old source. The new source now has the generated .js file (presumably generated by sphinx) in the tarball
<nacc> "* Modernizr 2.6.2 (Custom Build) | MIT & BSD
<nacc> with the build in a URL, it seems
<nacc> i'm not sure why that was done, though, let me see if i can find out
<nacc> slangasek: so upstream (gh) has embedded the templates in the src
<nacc> not sure why, other than maybe knowing with js is going to be used for the web UI ... I'd think we'd want to use the symlink provided by the other package as the old source did?
<slangasek> nacc: that is certainly an option; I have no strong opinion on it, but would ask whether we want to be on the hook for packaging changes on this universe package
<nacc> slangasek: yeah, that's not great. I'm not sure who, if anyone, cares about it, but i do see that it's maintained by rackpsace and is the "official" API to connect to openstack with PHP, which seems sort of improtant
<nacc> slangasek: i see what you mean, though, it might be easiest to just drop it, as not being compatible with php5? i'm not sure
<nacc> slangasek: and no one has demanded that we keep it around, afaict
<slangasek> nacc: yes; no reverse-dependencies, in universe, could be dropped instead of spending a lot of time on it
<nacc> no bugs against it ever, afaict, either
<nacc> slangasek: so let's say someone does come runnign and say they want it, is there a process to re-add it after release? or would we simply say they're out of luck? I just would lke to understand that policy
<slangasek> nacc: if nobody got around to asking for it until after release, they'd be out of luck
<nacc> slangasek: ok
<Umeaboy> cyphermox: Nobody is answering in #ubuntu-unity.
<nacc> slangasek: let's hold off on this one, i'll check with my team and get back to you, but probably we'll just plan on deleting it
<nacc> slangasek: presumably it'll come back in via sync in 16.10, if debian picks it up
<nacc> slangasek: ok, i'm doing some digging and only kohana 3.3 (not pacakged in debian either) supports php7, i think we should drop all of them, but i'll need toresolve the dep you found with pnp4nagios-web
<nacc> slangasek: and i think the resolution to that dep is we can't build the -web package with php7 :/
<nacc> as it depends on kohana we won't have, unless we package 3.3
<cjwatson> doko: https://bugs.launchpad.net/ubuntu/+source/libuniversal-require-perl/+bug/1560288 for devscripts, and I've uploaded a merge that fixes the test failures once that's processed.  Could you subscribe ~foundations-bugs to libuniversal-require-perl, which I think would be appropriate?
<ubottu> Launchpad bug 1560288 in libuniversal-require-perl (Ubuntu) "[MIR] libuniversal-require-perl" [Undecided,New]
<cpaelzer> good morning
<doko> cjwatson, foundations already is subscribed
<doko> jtaylor, xenial now has locales-all, no need to keep this diff (seen for matplotlib)
<pitti> Good morning
<pitti> infinity: when would be a good time to upload langpacks for the final beta?
<infinity> pitti: Right now.
<infinity> pitti: Or a week ago.
<pitti> wgrant: can you please start a xenial langpack export manually? I just requested a full export
<infinity> pitti: (if they all get through before my morning, that works for me, I can respin the world when I wake up)
<wgrant> pitti: Looking
<pitti> infinity: well, it's not utterly important, just makes the images slightly smaller
<infinity> pitti: Yeah.  But if you're doing it anyway, happy to take them.  I'm sure today's builds won't be the last.
<pitti> infinity: congrats to landing glibc, this was a mouthful
<pitti> infinity: ah, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd got stuck on some flakiness; I re-tried the test, but ok to still land this? there's two or three  urgent fixes people asked me about
<pitti> (and only bug and test fixes)
<pitti> Trevinho: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gtk+3.0 is stuck on software-properties regression; simple to fix, will upload now
<dholbach> good morning
<flexiondotorg> When the option to ignore future crash reports is selected by a user in apport, where is that "configuration" stored?
<pitti> flexiondotorg: in ~/.apport-ignore.xml
<flexiondotorg> pitti, Thanks. can system wide exclusions be made?
<pitti> flexiondotorg: not at the moment, no
<flexiondotorg> pitti, OK, thanks.
<pitti> flexiondotorg: well, you can blacklist *all* crashes from a binary, independent of the version
<flexiondotorg> How?
<flexiondotorg> Found it.
<pitti> flexiondotorg: /etc/apport/blacklist.d/README.blacklist
<flexiondotorg> Yep, reading it now :)
<flexiondotorg> Thanks.
<Trevinho> pitti: hey, thanks for letting me know.
<flexiondotorg> pitti, If you're able can I request you take a peek at bug please?
<pitti> flexiondotorg: which bug?
<flexiondotorg> pitti, I've contacted upstream, they are implicationg systemd to some extent.
<flexiondotorg> pitti, https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/1533206
<ubottu> Launchpad bug 1533206 in blueman (Ubuntu) "Blueman-applet crash on login: DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out" [High,Confirmed]
<flexiondotorg> pitti, Upstream issue - https://github.com/blueman-project/blueman/issues/488
<pitti> flexiondotorg: so something tries to dbus-activate blueman, but that either crashes or immediately terminates itself
<pitti> would certainly be useful to get the output from that
<flexiondotorg> pitti, blueman-applet is autostarted on Ubuntu MATE and Xubuntu upon login. I think possibly Lubuntu too.
<pitti> well, this isn't about the applet, it's about the service it tries to activate
<flexiondotorg> blueman-applet will crash is bluetooth is not present or disabled.
<flexiondotorg> pitti, I think so too. But upstream and feel systemd is at fault to some extent.
<pitti> uh, how's that?
<pitti> is blueman-applet talking to bluez? or is that a different dbus serivce?
<flexiondotorg> Well, see their comment in the upstream issue.
<flexiondotorg> Yes, it talks to org.bluez
<flexiondotorg> My feeling is blueman-applet should catch the exception.
<pitti> well, if you disable bluetooth.service you won't be able to talk to bluez, yes
<flexiondotorg> But, other than exitting silently, I've found now way to do that without generate a traceback elsewhere.
<pitti> so if bluez is meant to run all the time (I think it's not, as it activates on demand only *if* you have BT hw), then the client needs to be able to cope with it not being there
<flexiondotorg> So, my ideas were. Blacklist blueman-applet in apport or fail silently.
<flexiondotorg> pitti, Agreed. And so do upstream. But the 2.0.3 version appears quite brittle. There current development branch is more robust but in flux and not release ready.
<flexiondotorg> I'm not keen on failing silently. At least with blacklist via apport we backtraces are still captured in xsession-errors.
<pitti> you wouldn't get any crash of that any more, though
<pitti> I don't know what indicator-bluetooth does if it can't talk to bluez, but I figure it'd just hide itself?
<flexiondotorg> Yes, no crash reports for the blueman-applet, but the rest of blueman and BlueZ would still generate reports.
<flexiondotorg> We have plenty of blueman-applet crash reports ;-)
<flexiondotorg> indicator-bluetooth is not an option for Ubuntu MATE :-(
<flexiondotorg> Don't know if it is suitable for Xubuntu or Lubuntu.
<pitti> no, but I thought it might be worth to compare what that does
<pitti> FWIW, bluetooth.service is running here despite having no BT devices
<davmor2> pitti: yes I think it runs because you can have dongle for keyboards and stuff
<pitti> ah, "sudo rfkill list" shows that I don't have soft-blocked tpacpi_bluetooth_sw
<flexiondotorg> pitti, And org.bluez is avaiable via dbus?
<pitti> after soft-blocking tpacpi_bluetooth_sw it doesn't start any more, ok; so all as intended
<pitti> but it gets auto-activated again once I try to talk to it via dbus
<cjwatson> doko: Thanks.
<cjwatson> Maybe I was looking in the wrong place; I see it now.
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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: sil2100
<juliank> Oh, Debian import is working again? :)
<cjwatson> juliank: Yeah, it's finished with sid.  Of course dinstall being broken is clouding the issue a little.
<ricotz> cjwatson, hi, what is the plan to deal with the "broken" ppa keys with new apt
<cjwatson> ricotz: The keys aren't broken; we only need to re-sign things with the rough equivalent of --digest-algo SHA512.  This now happens for anything newly-published, but for the long tail of PPAs that haven't been touched in a while we will be re-signing them in bulk once we get the code finished to do so efficiently.
<cjwatson> (There are so many PPAs that this isn't entirely trivial ...)
<ricotz> cjwatson, yeah, that is what I meant with broken, thanks for clarifying
<ricotz> is there a bug report which I can follow?
<cjwatson> ricotz: No
<cjwatson> ricotz: Well, actually bug 1556666 will do I guess
<ubottu> bug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [High,Fix committed] https://launchpad.net/bugs/1556666
<ricotz> cjwatson, thanks
 * cjwatson posts a brief update there
<Laney> infinity: Any idea what's up with locales on the pending desktop image? There's none and no /usr/lib/locale/locale-archive...
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | 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 hugs sil2100 
* Laney 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:
 * sil2100 hugs dholbach back
<Mirv> tkamppeter: can you check hplip sync from Debian at bug #1559419 ? looks like mostly packaging fixes
<ubottu> bug 1559419 in hplip (Ubuntu) "Sync hplip 3.16.2+repack0-7 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1559419
<Mirv> I've syncpackage'd three packages for flexiondotorg without a seeming error, let's see if they appear after a delay or what's up
<flexiondotorg> Mirv, Thanks :-)
<flexiondotorg> Was one of them Pluma?
<Mirv> flexiondotorg: no, the three mate packages. don't thank me yet since they're currently still in /dev/null from what I can see :)
<flexiondotorg> Hah!
<flexiondotorg> OK, let's see.
<flexiondotorg> I've currently got an uninstallable image. Fixing a package to correct that now.
<flexiondotorg> So hopefully I can rebuild with those package you've synced as well :-)
<Mirv> flexiondotorg: oh, a correction. they're right there in the queue, so no problem. it's the final freeze that just started in action.
<flexiondotorg> Mirv, Which packages? mate-tweak, mate-settings-daemon, and mate-dock-applet?
<Mirv> flexiondotorg: yes, and I saw they were actually synced before already as promised by barry. but they'll stay in the unapproved queue for some time now.
<flexiondotorg> Mirv, OK. I requested an unblock.
<Mirv> flexiondotorg: what about pluma or eom? sil2100 commented on the bugs probably mistaking the current archive rework for them not being in debian unstable. anyway, would you need them before final beta?
<barry> yeah, it was a bit unfortunate that the debian import bug overlapped with final beta freeze.  i guess it will all work out tho
<flexiondotorg> Pluma would be good because is fixes a shell code injection.
<sil2100> Mirv: well, I checked the tracker in the morning and didn't see those, syncpackage didn't find the new versions as well
<flexiondotorg> eom just correct man page formatting.
<cjwatson> Which morning?
<sil2100> syncpackage: Error: Version in Debian 1.12.2-1 (unstable) isn't newer than Ubuntu 1.12.2-1 (xenial-proposed)
<sil2100> This is what I got around 2-3 hours ago
<sil2100> Ah, someone synced that already, sorry
<sil2100> Miss-read it ;)
<cjwatson> sil2100: The Debian archive publisher has also been broken for a couple of days.
<sil2100> k
<cjwatson> So anything uploaded to Debian for the last couple of days won't be visible, but not due to any fault on our side.
<Mirv> sil2100: yes so that's the reworks, syncpackage now started working two hours ago
<sil2100> Ok, all clear, since I didn't see it in https://tracker.debian.org/pkg/eom , syncpackage wasn't helping in the morning, so well
<cjwatson> superm1: if you want removals to happen, please subscribe ubuntu-archive to the bug - commenting on a bug I filed and hoping that I'll see the bug mail only works by luck
<cjwatson> (bug 1339073)
<ubottu> bug 1339073 in mythnettv (Ubuntu) "depends on mplayer/mencoder, which don't work with libav 10" [Undecided,New] https://launchpad.net/bugs/1339073
<cjwatson> superm1: can't deal with it at the moment but I've subscribed ubuntu-archive so that it's in the queue
<nacc> slangasek: we can drop pnp4nagios :) (https://github.com/lingej/pnp4nagios/issues/125#issuecomment-199683297)
<Son_Goku> nacc: do we have a list somewhere of php things that have worked/failed so far with php7?
<Son_Goku> because you havenât been updating the etherpad and apparently magic happened and every single thing has been a success in the ppa...
<nacc> Son_Goku: not really, I provided in a bug a list of packages that rebuilt successfully here with some sed commands
<Son_Goku> ah
<Son_Goku> nacc: it seems like this has goneâ¦ really smoothly
<nacc> Son_Goku: well, we still have 400+ pacakges that depend on php5 in the archive
<Son_Goku> right
<Son_Goku> nacc: are we keeping drupal 7 in xenial? afaik, only drupal8 is fully supported with php7
<nacc> Son_Goku: well, drupal8 isn't packaged in a debian either
<Son_Goku> erk
<nacc> Son_Goku: will have to see once i get to it on the list
<Son_Goku> nacc: since I think weâve got most of the core things out of the way, I think Iâll focus more of my efforts on testing applications with php7 to see if they pass a basic sanity check
<nacc> Son_Goku: sounds good
<nacc> Son_Goku: it would be good to verify the various extensions work too, php-memcached, etc.
<Son_Goku> yeah
<Son_Goku> I expect that Iâll hit the extensions as I do this
<nacc> Son_Goku: great, thanks
<Son_Goku> np
<Mirv> doko: can you think of something during the last two weeks (since 2016-03-07) that could cause this behavior change on i386/armhf bug #1560528 ? I'm trying to figure out if it's something to worry about or not, that out-of-range mappings don't fail.
<ubottu> bug 1560528 in qtbase-opensource-src (Ubuntu) "tst_LargeFile::mapOffsetOverflow started failing on 32-bit xenial" [Undecided,New] https://launchpad.net/bugs/1560528
<nacc> Son_Goku: it would also be good to periodically scan new bugs against php5 and php7.0 packages
<nacc> cyphermox: debian maintainer might have already contacted you about it, but he said your sg3-utils changes failed to build?
<cyphermox> yes
<nacc> cyphermox: ok, thanks; sounds like he's willing to cut a 1.41-2 once that's resolved
<cyphermox> nacc: sg3-utils is built in Ubuntu; so it's just a matter of figuring out what small bit is missing
<nacc> cyphermox: ah i see
<cyphermox> nacc: it's not currently my top priority, do you want to look into it? I'm guessing you ask because you need sg3-utils for something?
<cyphermox> otherwise I'll get to it tonight after work.
<nacc> cyphermox: i can add it to my list, but no guarantees :) it was on my list of debian differences to look at, but honestly, while we can sync to get the versions to match, it seems like it would be almost exactly our delta being applied, as debian has been taking your patches :)
<cyphermox> yes
<pitti> cjwatson: oh, so many lgw buildds down? that cloud seems to work reasonably well for me
<nacc> jgrimm: --^ can you take it off the list for now?
<cjwatson> pitti: those went down about a day or so, I'll try kicking them.
<cjwatson> *day or so ago
<jgrimm> nacc, ack. got it.
<pitti> infinity: spoon-feeding langpack upload now (uploading is achingly slow since this moved to snakefruit, argh)
<pitti> about 2.5 packages per minute, so this will take ~ 2 hours
<cjwatson> which bit is slow?
<pitti> cjwatson: dput to upload.ubuntu.com
<cjwatson> that's peculiar, should be much faster
<pitti> cjwatson: macquarie got decommissioned as it ran on lucid, so langpack builds got moved to snakefruit
<pitti> I already verified that it's not going through the proxy
<cjwatson> I mean, OK, snakefruit tends to be loaded, but dput is hardly CPU-intensive
<pitti> it's loaded in the mornings due to that git --repack thingy, but it's not particularly loaded right now
<pitti> 3.8, that's laughable
 * pitti has seen 80 in the mornings with that git job
<pitti> it apparently doesn't seem to be a bandwidth problem, as even uploading the empty ~ 1 kB update packages takes ages
<doko> also seen here
<infinity> pitti: Landing systemd seems reasonable to me.
<pitti> doko: where do you try it from?
<doko> pitti, dput from home
<cjwatson> ftp or sftp?
<infinity> Laney: *raise brow*
<infinity> Laney: Lemme look.  That seems not sane.
<pitti> ftp
<Laney> infinity: greetings
<doko> dput's default
<cjwatson> pepo isn't loaded either
<Laney> infinity: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1560459 is you-ish too (sorry)
<ubottu> Launchpad bug 1560459 in ubiquity (Ubuntu) "ubiquity crashed with GLib.GError in customize_installer(): vte-pty-error: grantpt failed: Operation not permitted (1)" [Critical,Confirmed]
<infinity> Laney: I see all sorts of locales being generated in the build log.
<Laney> Quite
<infinity> The grantpt one is more interesting.
<jgrimm> cyphermox, xnox were one of you going to be able to sponsor/upload multipath-tools for rharper?
<cjwatson> an strace -f -s1024 -tt of the client side of dput might perhaps enlighten slightly
<infinity> Laney: Grabbing an ISO now to see WTF is up.
<infinity> Laney: I'm running 2.23 locally with all sorts of vte terminals and no such problem, so I'm guessing it's something to do with the live system itself.
<Laney> infinity: It's probably some pkexec/sudo madness with ubiquity
<doko> locale issue with perl? but only on ppc64el so far: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/r/redmine/20160322_153214@/log.gz
<doko> infinity, ^^^
<infinity> doko: That's just what perl does when your environment references a locale you don't have built.  I blame the ppc64el adt image.
<infinity> Given those images shouldn't even have locales installed, they sure shouldn't have an environment referencing anything other than C or C.UTF-8
<infinity> pitti: ^
<pitti> "unable to connect to postgresql server"
<pitti> I'm quite sure they do have locales installed, it's in minimal
<pitti> ah yes, invalid locale when configuring postgresql, hmm
<pitti> the default locale in autopkgtest is C.UTF-8
<pitti> why would that not be available
<dobey> is there a trivial way to evaluate a "foo | bar" build dependency to see what the result would be, without building a source package and trying to build it?
<pitti> dpkg-checkbuilddeps checks for missing ones at least
 * pitti waves good night, not feeling well
<dobey> night pitti
<Laney> infinity: https://paste.ubuntu.com/15473053/ <- that totally fixes it
<Laney> but is it sane?
<infinity> Laney: Oh, hrm.  The usage there might not be sane in the first place.  Lemme look at the context.
<Laney> infinity: /usr/share/locales/install-language-pack grew this parameter too with 2.23
<infinity> Laney: Right, it's the other part I'm questioning.
<infinity> Laney: Since I dropped the ability to call "locale-gen $random-lang"
<infinity> Ahh, but it also writes to /etc/locale.gen which will work.
<infinity> Laney: So, you can probably drop the second argument.
<infinity> Laney: Then the only difference between keep-existing and not will be performance.
<Laney> I guess it's because install-language-pack does *not* write to locale.gen
<infinity> Laney: No, it's because we're calling locale-gen with that extra arg.
<infinity> Which changes where it looks for generation.
<infinity> Laney: If you call locale-gen bare, it uses /etc/locale.gen and /var/lib/supported.d/*
<infinity> Laney: if you call it with the second arg, it only uses /var/lib/supported.d/$arg
<infinity> Laney: Which doesn't exist when calling it with random strings.
<Laney> 'kay, so just /usr/sbin/locale-gen will work
<Laney> lemme try that
<infinity> Laney: So, drop the second arg to fix the bug, and add --keep-missing for performance reasons.
<infinity> keep-existing, even.
<Laney> nod
<slangasek> --just-keep-swimming
<infinity> --dont-stop-believing
<Laney> 'Just' #1560459 then
<infinity> Laney: Yeah, I'm looking at that one right now.
<matsubara> Hi there, not sure who to ask about the debian-installer, but we got a bug report for the server iso https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1559507 where the keyboard selection fails. I commented in the bug report with what I found about the issue and would like to ask someone that knows better about the installer. Who would be that person?
<ubottu> Launchpad bug 1559507 in debian-installer (Ubuntu) "Keyboard selection is missed" [High,Confirmed]
<dobey> dpkg-checkbuilddeps: Unmet build dependencies: golang-go (>= 2:1.6) | gccgo
<dobey> :(
<infinity> dobey: build log?
<infinity> Laney: Huh.  Surprisingly, fixing the locale also lets gnome-terminal start again.
<Laney> infinity: Yeah. It was failing because it was sad about the locale.
<Laney> the bug was initially reported by davmor2 as "gnome-terminal doesn't start" :)
<davmor2> infinity, Laney: it might also fix ubiquity as cyphermox said that the session calls terminal
<Laney> nein
<davmor2> :(
<davmor2> shame would of been nice
<dobey> infinity: https://launchpadlibrarian.net/249586552/buildlog_ubuntu-vivid-ppc64el.pay-service_15.10+15.04.20160322-0ubuntu1_BUILDING.txt.gz
<dobey> infinity: but the unmet i pasted was from me playing around with a local control file to see if i could come up with something that works on vivid, without having to generate control from control.in
<infinity> dobey: Oh.  If you're doing it locally, you want to feed --resolve-alternatives to sbuild
<superm1> cjwatson: ah okay thanks will do in future
<infinity> dobey: That's the LP default, but not the sbuild default.
<Laney> casper uploaded
<cyphermox> davmor2: to be precise, I expected that fixing glibc would fix ubiquity
<dobey> infinity: i'm just doing dpkg-checkbuilddeps locally
<infinity> dobey: dpkg-checkbuilddeps should be happy with that if one of those package is installed.
<infinity> cyphermox: Not sure yet if anything needs to be "fixed" in glibc, per se.
<infinity> cyphermox: But I'm tracing back where that error comes from in the first place.
<dobey> infinity: it's only happy if it's installed though?
<cyphermox> infinity: ok
<infinity> dobey: Well, yes.  That's the point of dpkg-checkbuilddeps.
<dobey> oh
<dobey> so i have to do an actual build to do an actual test i guess
<dobey> ok
<infinity> Hrm. I wonder if a vte rebuild would just fix it.
<infinity> Laney: I'm deep in vte hell.  Having a hard time believing this isn't already fixed, since we're pretty much the last distro to drop pt_chown.  Still digging.
<mitya57> cjwatson, were syncs really fixed? syncpackage python-markdown says that version 2.6.6-1 has not been picked up by LP yet, however it was uploaded ~35 hrs ago.
<mitya57> (should I just wait?)
<cjwatson> mitya57: Syncs were really fixed, but independently, the Debian archive publisher is broken ...
<cjwatson> mitya57: And has been for a couple of days
<cjwatson> mitya57: It's all fine at our end, but we can only pick up things that Debian has actually published for real
<cjwatson> mitya57: You'll be able to see when Debian's stuff is fixed by watching the timestamp on http://ftp.debian.org/debian/dists/unstable/InRelease
<mitya57> cjwatson, ah, thanks, that explains it
<mitya57> I now see that in #debian-devel topic :)
<cjwatson> Breaking multiple things in the same area is an excellent way to confuse everyone about which bits are fixed.
<slangasek> nacc: hum, please /don't/ open tasks for packages that can be rebuilt without modification... those should really just be a list of packages
<slangasek> if you open tasks for them, we have to close the tasks again, and then it's not an automated process ;)
<nacc> slangasek: ah ok, it's only the one soo far
<nacc> slangasek: feel free to delete the one for assetic, i'll provide a list for the remainder as i encounter them now
<nacc> Pharaoh_Atem: can you look into php-memcached? I think it's installing the .ini file in the wrong place, /etc/php/mods-available ... similar to waht you saw with imagick, slangasek
<Pharaoh_Atem> nacc: sure
<Pharaoh_Atem> one moment
<nacc> Pharaoh_Atem: slangasek: i think we just need another rebuild of php-memcached, i just built the version in release and it poitned to thee right location in /etc/php/7.0/; do you want a bug for that request?
<mapreri> JOOI, does somebody have any idea how/what it would take to move from ubuntu's system of building -dbgsym to the debian's implementation?
<slangasek> nacc: I'll kick off a no-change rebuild, no bug neede
<slangasek> d
<nacc> slangasek: thanks! I think i will do a search at some point if any pcakges refer to /etc/php/mods-available, as they need a rebuild if so
<pitti> infinity: all langpacks, and systemd, waiting in xenial-proposed; I take it you want to steer the landing yourself, to coordinate with rebuilds?
 * pitti crawls back to bed, cu tomorrow
<sarnold> gnight pitti :)
<infinity> pitti: I'd be more than happy with you letting them all in.
<Pharaoh_Atem> nacc: looks like php-memcached is installing to the wrong location
<Pharaoh_Atem> it threw warnings at me
<nacc> Pharaoh_Atem: might still be pending a rebuild
<nacc> Pharaoh_Atem: build2 is in proposed, i think
<nacc> https://launchpad.net/ubuntu/+source/php-memcached
<mwhudson> good morning distro
<nacc> slangasek: so cakephp (universe) only supports php7 with 2.8 (which is now in experimental)
<nacc> slangasek: https://github.com/cakephp/cakephp/issues/8087
<nacc> slangasek: we don't run the tests (although they do exist) so the 2.7 version will appear to build and work; but realistically we should either ship 2.8 or nothing if we are moving to php7
<slangasek> nacc: cakephp has a revdep (zoneminder), so if 2.8 will be compatible with zoneminder, syncing from experimental seems preferable
<nacc> slangasek: yep, i saw that just now, will look at it now
<nacc> slangasek: so i think zoneminder is 2.8 compat, but i'll need to test it in my lxc (https://github.com/ZoneMinder/ZoneMinder/pull/1306)
<nacc> slangasek: LP: #1560709
<ubottu> Launchpad bug 1560709 in zoneminder (Ubuntu) "Please sync cakephp 2.8.0-1 from Debian experimental" [Undecided,New] https://launchpad.net/bugs/1560709
<nacc> slangasek: on rebuild of zoneminder, it changes the dep to need cakephp >= 2.8.0, as well
<nacc> slangasek: thanks for the quick turnaround on php-memached, i can confirm the new version is correct in the archive now
<nacc> Pharaoh_Atem: --^
<Pharaoh_Atem> nacc: double checking now
<nacc> Pharaoh_Atem: thanks
<Pharaoh_Atem> nacc: looks peachy ð
<nacc> Pharaoh_Atem: cool, thanks for confirming
<nacc> Pharaoh_Atem: do you konw what, normally, would provid phpdoc?
<nacc> as a command
<Pharaoh_Atem> php-pear(PhpDocumenter)
<nacc> Pharaoh_Atem: is that pacakged in either debian or ubuntu?
<nacc> i don't thnk it is
<Pharaoh_Atem> let me quickly check
<nacc> Pharaoh_Atem: davical calls it unconditionally in its makefile, which is fine, but means we're not generating docs for it
<Pharaoh_Atem> O.o
<Pharaoh_Atem> holy crap, it's missing
<nacc> not a new issue, but i wonder if it should be something that is pacakged
<Pharaoh_Atem> how is something like that... missing?!
<nacc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=206536
<ubottu> Debian bug 206536 in wnpp "RFP: php-phpdocumentor -- phpDocumentor provides automatic documenting of php api" [Wishlist,Open]
<Pharaoh_Atem> Fedora has had it since at least Fedora Core 6
<nacc> on 10/2013, it seems like php-apigen was considered a replacement
<Pharaoh_Atem> but it doesn't provide /usr/bin/phpdoc
<nacc> agreed :)
<nacc> i meant, functionally
<Pharaoh_Atem> and doesn't use the same format as phpdoc either
<nacc> or that ml post claims as much
<nacc> i'll e-mail ondrej
<Pharaoh_Atem> afaik, apigen is also only useful for web based documentation
<nacc> clearly no one has been pushing for it in debian or ubuntu :/
<Pharaoh_Atem> that's... unfortunate
<nacc> slangasek: is it worth me trying to fixup dh-make-php to be php7 compatible, or should we just drop it? it only support php5, afaict, and i believe pkg-php-tools supersedes the functionality
<nacc> Pharaoh_Atem: would appreciate your input too
<nacc> there is a reverse build-dep on it, but i'm looking into that now
<Pharaoh_Atem> if the functionality is fully superseded, I don't see a reason why dh-make-php is needed
<Pharaoh_Atem> do the pkg-php-tools provide a debhelper thing?
<slangasek> nacc: it's not for me to say what's worth fixing or not; anything that's not worth fixing, we should definitely remove.  and dh-make-php only has two revdeps (php-letodms-lucene->letodms), so I don't think it'd be at the top of the priority list
<nacc> slangasek: agreed, i'm just looking at so much stuff, appreciate other eyes periodically :)
<slangasek> dh-make-php is a helper tool for source package templating. I'm not sure why something would build-depend on it at all
<nacc> slangasek: i don't think it actually should
<nacc> it was used to build the package originally
<nacc> afaict
<nacc> ah ha... per `man dh_pecl`:
<nacc> "If you use this program, your package should build-depend on php4-dev and
<nacc> php5-dev, as well as dh-make-php (the package containing this script)."
<nacc> i wonder why
<Pharaoh_Atem> helpful as always, I guess
<nacc> trying a build w/o it
<nacc> ah ah, it relies on a cdbs pear.mk provided by the same package
<nacc> slangasek: so it's a hlper & runtime tool :/
<nacc> err, build-time
<slangasek> nacc: oh, cdbs; yeah, nuke it all from orbit ;)
#ubuntu-devel 2016-03-23
<mwhudson> doko (or anyone else): any chance of uploading the co-installable go stuff today?
<mwhudson> ibm are suggesting i update the s390x patch
<doko> mwhudson, it's there for a few hours ...
<mwhudson> oh!
<mwhudson> i wonder why i didn't get bugmail
<mwhudson> doko: thanks
<doko> not yet migrated
<mwhudson> oh because the bug wasn't reported against the right source packages, because they didn't exist yet
<mwhudson> doko: migrated 18 mins ago apparently...
<nacc> slangasek: ah, debian has already dropped it as a dep for php-letodms-lucene
<mwhudson> ah -defaults hasn't migrated yet
<mwhudson> should in the next run though
<nacc> slangasek: LP: #1560737
<ubottu> Launchpad bug 1560737 in php-letodms-lucene (Ubuntu) "[FFe] Please sync php-letodms-lucene 1.1.1-1" [Undecided,New] https://launchpad.net/bugs/1560737
<slangasek> jdstrand: so, bug #1020598 is interesting; we've been carrying a delta to iptables to drop ipq support since quantal because "the kernel no longer supports ip_queue", yet the Debian package builds libipq just fine against xenial (and unblocks the perlipq package hanging around in -proposed). Do you remember this?
<ubottu> bug 1020598 in iptables (Ubuntu Quantal) "iptables ftbfs due to ip_queue obsolete on 3.5 kernels" [High,Fix released] https://launchpad.net/bugs/1020598
<slangasek> nacc: php-letodms-lucene has an Ubuntu delta which seems to still be relevant.  Maybe needs to be a merge instead?
<nacc> slangasek: ack, sorry! was looking at the wrong output
<mwhudson> how often does britney run for xenial-proposed -> xenial-release?
<nacc> slangasek: ah nm, no longer depends on zend-framework
<slangasek> nacc: ok
<doko> pitti, more locale issues: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python3.5/20160322_210741@/log.gz
<slangasek> doko: probably fixed by infinity's upcoming glibc upload
<slangasek> doko: or at least, worked around - but the actual test failure in there doesn't look locale related?
<slangasek> Now running lintian...
<slangasek> Complex regular subexpression recursion limit (32766) exceeded at /usr/share/lintian/checks/cruft.pm line 939.
<slangasek> nacc: ^^ ugh, what is this package
<slangasek> (icinga-web)
<doko> slangasek, yes, test_cmath failing, but only in debug mode... will have to wait until tomorrow
<nacc> slangasek: a fairly old framework for monitoring systems and networks
<nacc> slangasek: that's the web interface part
<nacc> i think there is a 2.x at this point, but not packaged anywhere
<nacc> afaict
<nacc> slangasek: err, the web interface isn't
<nacc> there is a icinga2 package
<slangasek> yeah; and the icinga2 package has a wrong dep and is blocked in -proposed
<nacc> slangasek: oh i see it now
<slangasek> mwhudson: britney runs every minute, sees that a lock is taken, and goes back into its hole for 4 more weeks of winter
<mwhudson> slangasek: i see, this is a "how long is a piece of string" question then
<nacc> slangasek: so on consideration, if we can fix up icingaweb2, we can just remove icinga-web, i think?
<nacc> no rev-deps?
<slangasek> nacc: probably, if icinga2 is something you care about
<nacc> slangasek: ok, patch for icingaweb2 posted in LP: #1544352
<ubottu> Launchpad bug 1544352 in adminer (Ubuntu) "[PHP7] After bootstrapping, these PHP packages can be rebuilt" [Wishlist,New] https://launchpad.net/bugs/1544352
<mwhudson> stgraber: the lxd test on i386 on http://autopkgtest.ubuntu.com/running.shtml looks unhappy?
<slangasek> nacc: ok. is there a bug requesting removal of dh-make-php?
<mwhudson> oh no, nm, it's going again
<mwhudson> (thought it was stuck)
<nacc> slangasek: i'll add it to LP : #1547183 if that's ok?
<slangasek> nacc: sure
<slangasek> nacc: re: icingaweb2, I will note that it seems suboptimal that Debian and Ubuntu have different spellings of 'zendframework'.  it looks like there are half a dozen packages in Debian that depend on it.  rather than needing to carry a delta for each of these, should we (eventually) sync up the zendframework package names?
<nacc> slangasek: yeah it's quite annoying
<nacc> we definitely should, i wonder why it happened
<nacc> slangasek: i think they might be idfferent packages :/
<slangasek> hmm, well, then this package that just got uploaded maybe won't dtrt ;)
<nacc> well, i mean, different sources
<nacc> they are the "same" but ubuntu has its own
<nacc> i don't know why
<slangasek> sure, I think because someone in Ubuntu was interested in packaging it before it was available in Debian
<nacc> yeah, could be, and now we're out of date :)
<slangasek> we don't have to get the packages in sync, but synchronizing on the package name would save us from having to carry delta on /other/ packages
<nacc> we're older than oldstable at this point :)
<nacc> agreed on the naming issue, though, i'll try to figure that out
<mwhudson> golang-defaults has migrated too w00t
<infinity> mwhudson: So, guessing we can remove golang, then?
<mwhudson> infinity: yes
<mwhudson> infinity: and golang-race-detector-runtime
<mwhudson> infinity: want a bug or will you JFDI?
<infinity> mwhudson: What produces golang-race-detector-runtime now?
<mwhudson> infinity: golang-defaults
<mwhudson> and it depends on the new golang-1.6-race-detector-runtime
<infinity> Ta.  Both removed.
<mwhudson> cool
<mwhudson> infinity: golang-go.tools while you're there? :)
<mwhudson> that was replaced by golang-golang-x-tools aaages ago
<mwhudson> (the latter packages makes transitional dep packages)
<infinity> golang-golang-x-tools ... What a lovely redundant name.
<infinity> (And removed)
<infinity> mwhudson: Thanks for doing this.  I really hope it makes future golang maintenance slightly less painful.
<infinity> mwhudson: And we need to revisit trusty really soon, I guess. :/
<mwhudson> infinity: so do i!
<mwhudson> infinity: slangasek put himself on the hook for that, the fool :-p
<infinity> Hah.
<infinity> Excellent.
<infinity> One more thing off my plate.
<infinity> To be fair, now that you have the versioned golang-1.6 in xenial, it should be pretty much a straight backport.  Almost.
<infinity> I'm guessing.
<infinity> And then making $stuff in trusty build with the versioned paths.
<mwhudson> oh yes that's a good point, we should backport the xenial golang-1.6, not the hacked up one i made
<mwhudson> um
<mwhudson> infinity: how do we do this and end up with a golang-1.6 package in trusty that has a lower version than the one in xenial? :)
<slangasek> I should clearly buy galangal.com, so I can have a package called golang-galangal-root-dev
<slangasek> mwhudson: add new changelog entry, copy previous version number, append ~14.04
<mwhudson> slangasek: but this process starts by copying-with-binaries from xenial to trusty
<slangasek> mwhudson: Russian nesting ppas
<slangasek> you can build-depend on packages in a ppa not your own
<mwhudson> ah right
<mwhudson> and then you can upload a version that has a lower version than the ppa you b-d on
<slangasek> yep
<infinity> Yeah, should be nice and simple now.
<infinity> Extra bonus to the defaults thing I forced on you. :P
<slangasek> jdstrand: ignore my previous inquiry; I've confirmed that the ipq support Debian added back to iptables by copying a kernel header is useless on modern kernels
<mwhudson> infinity: heh the only forced thing was getting it done in time for x, i think it's a good idea :-)
<infinity> mwhudson: s/forced/encouraged/ :)
<nacc> slangasek: ok, i think i'm stopping with updates for the day ... only 19 done out of 400 or so, but ... something!
<nacc> slangasek: Pharaoh_Atem: we need to figure out a plan for drupal
<nacc> drupal7 is in the archive & in debian, but doesn't support php7
<nacc> drupal8 does, but isn't pacakged
 * sarnold *shudders*
<infinity> drupal should never have been packaged in the first place.
 * nacc tends to agree
<sarnold> http://people.canonical.com/~ubuntu-security/cve/pkg/drupal7.html
 * mwhudson checks that golang-1.6 doesn't need to breaks the golang in trusty
<nacc> and was going to ask if we could just drop it
 * Pharaoh_Atem agrees violently
<infinity> mwhudson: I'd assume all the new versioned paths won't have any conflicts.  But nice to be sure.
<Pharaoh_Atem> can we drop *all* the web apps?
<mwhudson> infinity: yeah, i'd certainly hope not
<mwhudson> but assume make a etc etc
<infinity> mwhudson: I, too, spell assume "etcetc".
<nacc> infinity: sarnold: ok, drupal7 is close to a leaf package, so in terms of that, should be easy to drop (along with drupal7-mod-libraries). Just one update to civicrm to not build a drupal7 module.
<Pharaoh_Atem> nacc: what about phpbb3 and wordpress?
<Pharaoh_Atem> the former doesn't even HAVE a version that supports php7, and wp is just a nightmare
<infinity> My personal opinion is that no webapps should ever be packaged, but I'm not sure I should be making that call alone. :P
<infinity> I've certainly been losing that war for years.
<nacc> Pharaoh_Atem: on my list to look at
<Pharaoh_Atem> at least owncloud isn't in the archive anymore
<slangasek> nacc: heh, the auto-sed of cacti results in debian/README.Debian making some interesting claims about suhosin support
<slangasek> well. not actually auto in this case
<nacc> slangasek: argh, sorry! i had dropped that bit in my local tree
<nacc> i think that whole paragraph is wrong
<slangasek> yep ;)
<nacc> http://askubuntu.com/questions/298689/i-cant-get-apt-get-install-php5-suhosin-to-work
<nacc> :)
<nacc> slangasek: i am trying to review the pacakges at that level, which is making the process pretty slow
<nacc> slangasek: i can send an updated debdiff for cacti tmrw with that removed
<slangasek> nacc: I'm not sure that level of review is required, tbh. I just noticed it in passing
<mwhudson> ah now the game of "waiting for publisher runs" begins
<nacc> slangasek: yeah, it may not be, but i wanted to minimize my own mistakes
<Pharaoh_Atem> suhosin is unnecessary these days
<Pharaoh_Atem> just use fpm and protect it with SELinux or AppArmor
<tsimonq2> what's the deal with all my PPAs using SHA-1, which is showing a warning as being weak when I update my computer..
<tsimonq2> *computer...
<Pharaoh_Atem> tsimonq2: the switch was flipped to enforce SHA-2 hashes for signatures
<sarnold> tsimonq2: the fix is apparently in progress
<tsimonq2> well I've seen the blog post from the apt team, but the fix is in progress for PPAs?
<sarnold> yeah
<sarnold> if you add e.g. a new xenial release to your ppa the signatures ought to be fixed quickly
<sarnold> but they'll bulk-resign all ppas soon
<tsimonq2> soon being hours, days, weeks, months, years, what?
<sarnold> probably "days"
<sarnold> https://lists.ubuntu.com/archives/ubuntu-devel/2016-March/039287.html
<tsimonq2> okay, thank you sarnold :)
<Unit193> sarnold: It already hit, if you'd upload a new source package (Eg, make it re-publish the PPA.)
<Unit193> Source: The bug report I don't remember the number. :3
<sarnold> hehe
<Unit193> Just looking now to re-publish all of 'em.
<tsimonq2> you guys got an API function to republish a PPA or do you have to do it all by hand?
<tsimonq2> the latter would be painful
<tsimonq2> *very* painful
<rbasak> Do we have a Haskell guy? libghc-gnutls-dev 0.2-2 in Xenial ships /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.10.3/gnutls-0.2-BYccZTzDgCw38R5GwM0fsE/libHSgnutls-0.2-BYccZTzDgCw38R5GwM0fsE-ghc7.10.3.so which needs libgnutls-deb0.so.28 which doesn't exist in the archive.
<rbasak> Rebuilding src:haskell-gnutls gives me a libghc-gnutls-dev that uses libgnutls.so.30 instead.
<rbasak> I could just upload a no-change rebuild, but I wonder if this indicates that some wider check is needed.
<sarnold> rbasak: i've got a vague feeling infinity handled the last pile of haskell changes
<rbasak> Thanks. I've just found another with the same issue: libghc-network-protocol-xmpp-dev
<rbasak> So I think we need a bunch of rebuilds.
<rbasak> Where a bunch appears to equal two.
<cpaelzer> good morning
<pitti> Good morning
<mwhudson> good evening
<pitti> infinity, doko: after the two latest responses in bug 1534263 I'm inclined to approve this; WDYT?
<ubottu> bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.4 series to Ubuntu Xenial 16.04LTS" [High,Incomplete] https://launchpad.net/bugs/1534263
<infinity> pitti:
<infinity> Setting up udev (229-3ubuntu1) ...
<infinity> addgroup: The group `input' already exists as a system group. Exiting.
<infinity> /var/lib/dpkg/info/udev.postinst: 109: [: Illegal number: *
<pitti> infinity: yep, fixed in git already, bug 1560112
<ubottu> bug 1560112 in systemd (Ubuntu) " /var/lib/dpkg/info/udev.postinst: 109: [: Illegal number: *" [Medium,Fix committed] https://launchpad.net/bugs/1560112
<infinity> pitti: Does that break anything?
<pitti> but it's just cosmetical, thus no reason to panic-upload
<infinity> pitti: Kay.
<dholbach> good morning
<asac> beta coming today?
<asac> :)
 * asac considers to do the LTS->LTS upgrade test and wonders when is best time to be most useful :)
<asac> ah its tomorrow... nevermind
<cjwatson> tsimonq2: We will not have to do it by hand.  The thing I'm working on is some adjustments to the publishing scripts so that we can do a bulk run over everything without it taking all week.
<Unit193> Still, thanks for the fix so far.
<doko> infinity, seen on amd64: https://launchpadlibrarian.net/249606658/buildlog_ubuntu-xenial-amd64.python3.5_3.5.1-8_BUILDING.txt.gz
<doko> (search for: final link failed)
<doko> ok, this complaint seems to be valid, _math.o is built without -fPIC
<darkxst> slangasek, upstream plymouth has proper hidpi support in git now (but no release as yet) do we want to cherry-pick the patches for 16.04? ricotz has test packages at https://launchpad.net/~ricotz/+archive/ubuntu/staging/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<LocutusOfBorg> hi folks, can anybody please explain this? https://launchpad.net/ubuntu/+source/fpc/3.0.0+dfsg-4/+build/9390047
<LocutusOfBorg> Setting up fp-compiler-3.0.0 (3.0.0+dfsg-2) ...
<LocutusOfBorg> An unhandled exception occurred at $0FE502D0:
<LocutusOfBorg> EAccessViolation:
<LocutusOfBorg>   $0FE502D0
<LocutusOfBorg>   $0FE5E684
<LocutusOfBorg>   $0FE152A8
<LocutusOfBorg>   $0FE1537C
<LocutusOfBorg> the build doesn't even start
<darkxst> LocutusOfBorg, its failing before that though,
<darkxst> dpkg: dependency problems prevent configuration of sbuild-build-depends-fpc-dummy:
<darkxst>  sbuild-build-depends-fpc-dummy depends on fp-compiler; however:
<darkxst>   Package fp-compiler is not configured yet.
<darkxst>   Package fp-compiler-3.0.0 which provides fp-compiler is not configured yet.
<mdeslaur> pitti: hi! can you take a look at the comment I've added in https://bugs.freedesktop.org/show_bug.cgi?id=85477 please?
<ubottu> Freedesktop bug 85477 in operations "Creating new partition and filesystem sometimes only creates the partition" [Normal,New]
<LocutusOfBorg> darkxst, that part "Setting up fp-compiler-3.0.0" is before what your wrote :)
<LocutusOfBorg> something really bad is happening on boost / ppc64el
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/clblas/2.10-2/+build/9384486
<darkxst> LocutusOfBorg, oh yes seems I skipped to the second error
<LocutusOfBorg> :)
<LocutusOfBorg> seems some sort of apt/dpkg/chroot/sbuild issue?
<cjwatson> how would that be an sbuild issue?  /usr/include/boost/math/policies/policy.hpp:818:18: error: â__float128â was not declared in this scope
<darkxst> LocutusOfBorg, seems like an arch issue to me
<mpt> Huh. I wasnât expecting âsudo usermod -l ð testaccountâ to work, but it does
<LocutusOfBorg> cjwatson, sbuild issue is fpc
<LocutusOfBorg> boost issue clblas
<LocutusOfBorg> :)
<cjwatson> sure, but you weren't desperately specific in the one I was replying to
<LocutusOfBorg> yes, sorry
<cjwatson> anyway, the fpc thing is also not an apt/dpkg/chroot/sbuild issue; the build-depended-on fpc itself is apparently blowing up
<LocutusOfBorg> I don't understand sorry :)
<cjwatson> LocutusOfBorg: dpkg tries to install fp-compiler-3.0.0; its postinst fails with the output you quoted.  this is not the fault of dpkg or any layer above it, but the fault of whatever the postinst is calling that's exploding, which is probably some bit of fp-compiler-3.0.0 itself.
<LocutusOfBorg> and only on ppc64el :(
<LocutusOfBorg> I have no porterstuff on ubuntu, and Debian is fine
<ginggs> LocutusOfBorg: is that update-alternatives?
<LocutusOfBorg> nice and trivial to debug :(
<ginggs> LocutusOfBorg: i have a VM at OpenPower, lemme try...
<LocutusOfBorg> that would be *awesome*
<LocutusOfBorg> https://sources.debian.net/src/fpc/3.0.0%2Bdfsg-4/debian/fp-compiler.postinst.in/
<LocutusOfBorg> this seems to the failing script?
<cjwatson> the failing build you quoted is powerpc, not ppc64el
<cjwatson> my guess would be that the failing thing is something itself implemented in Pascal, so probably fpcmkcfg
<cjwatson> but that's a guess
<LocutusOfBorg> the boost stuff is failing on ppc64el
<LocutusOfBorg> the fpc on powerpc :)
<cjwatson> see "not desperately specific" above
<ginggs> aargh, i'm installing fpc on ppc64el :(
<LocutusOfBorg> probably my bad connection is messing up the messages
<ginggs> LocutusOfBorg: try to break one thing at a time
<LocutusOfBorg> ginggs, I'm leaving because of bad connection, please upload/fix/send me a mail or whatever if you have updates <3
<ginggs> hmm rebuilding clblas 2.10-1 also fails with â__float128â was not declared in this scope on ppc64el
<doko> ginggs, can you check if this is triggered by glibc 2.23?
<ginggs> doko: sure, i'll have a look
<ginggs> doko: i don't think so, clblas FTBFS on 2016-03-11 already http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160226-xenial.html
<rbasak> update_excuses.html says "libmysqlclient-dev/amd64 unsatisfiable Depends: libmysqlclient20 (= 5.7.11-0ubuntu2)"
<rbasak> But libmysqlclient20 5.7.11-0ubuntu2 is in xenial-proposed for amd64.
<rbasak> Some help please?
<slangasek> rbasak: check components
<rbasak> Ah
<rbasak> That'll be it, thanks.
<rbasak> slangasek: mind moving libmysqlclient20 and mysql-{client,server}-5.7 to main, please?
<rbasak> They will replace libmysqlclient18 and 5.6 when we're done.
<slangasek> rbasak: done
<rbasak> Thank you!
<ginggs> LocutusOfBorg, cjwatson: same access violation when installing fp-compiler on real powerpc hardware
<ginggs> and just running 'fpcmkcfg-3.0.0' also
<doko> mvo, https://launchpad.net/ubuntu/+source/golang-github-mvo5-goconfigparser/0.2-0ubuntu5/+build/9322535
<mvo> doko: thanks, I have a look
<slangasek> mvo: morning! so I see that ubuntu-snappy FTBFS on powerpc with a test timeout; do you know if it's likely to build on a retry?
<mvo> slangasek: good morning! I doubt it, it seems to be a bug in the gccgo, I will probably hvae to disable the test
<slangasek> mvo: is it the test that's broken or the code under test?  should I just delete the old powerpc binaries instead?
<mvo> slangasek: its hard to say, but if we could remove powerpc for now, that would be fine with me as well, its the only problematic arch
<rbasak> slangasek: sorry, I missed mysql-client-core-5.7. Did you notice mysql-server-core-5.7 since that seems to be OK?
<slangasek> rbasak: I noticed mysql-server-core, yeah, and missed the other. fixing now
<rbasak> Thanks
<rbasak> Skuggen: FYI ^^
<slangasek> mvo: oops, ubuntu-snappy did build successfully on powerpc after a give-back; sorry ;)
<superm1> rbasak: is 5.7 intended to replace 5.6 for beta?
<TJ-> pitti: 2 users reporting udev 229-3ubuntu1 failing postinst with  "/var/lib/dpkg/info/udev.postinst: 109: [: Illegal number: * "  "
<Son_Goku> slangasek: does Ubuntu not support UsrMerge?
<Son_Goku> I distinctly remember that it was something Ubuntu looked into in the quantal days, but I donât see any indications of it being supported
<pitti> TJ-: already fixed in git, it's just cosmetical
<pitti> TJ-: the postinst doesn't fail, it just spits out this warning
<TJ-> pitti: ahhh, OK :) couldn't find a bug report for it
<pitti> TJ-: bug 1560112
<ubottu> bug 1560112 in systemd (Ubuntu) " /var/lib/dpkg/info/udev.postinst: 109: [: Illegal number: *" [Medium,Fix committed] https://launchpad.net/bugs/1560112
<TJ-> pitti: strange; the launchpad search on the udev package didn't show that
<pitti> TJ-: the source package is systemd
<pitti> udev has been built from that since, hmm, looong ago
<TJ-> pitti: oh, of course! I was caught out because there are some very recent 16.04 reports on the udev package
<mvo> slangasek: heh, nice
<rbasak> superm1: replace yes, not sure about beta.
<rbasak> Which is a point. I wasn't expecting it to hit the archive this late. Am I OK to proceed with the transition during the beta freeze?
<superm1> rbasak: ok i'm hoping not by beta because mythbuntu has some hardcoded stuff in the ubiquity plugin to configure 5.6 mysql
<superm1> it's not a problem to change it to 5.7 other than it's a timing thing to make sure they both land in the right ISO image
<rbasak> superm1: noted. I tagged block-proposed in bug 1528583 to ensure we hold off until I understand what we should do.
<ubottu> bug 1528583 in mysql-5.7 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
<superm1> rbasak: ok thanks.  after beta no problem for me to adjust our code
<rbasak> Skuggen: FYI ^^
<rbasak> infinity: ^^ thoughts? Should we hold off?
<slangasek> I guess at this point the only way to hold it off is by blocking it in britney
<slangasek> if not already too late
<slangasek> rbasak: can you open a proposed-migration blocking bug?
<rbasak> slangasek: already done
<slangasek> ok
<rbasak> I think it's in time because the dep8 tests take quite a while.
<slangasek> oh, also freeze, which means it needs hinting anyway, so good
<slangasek> errr except it wasn't previously seeded so it's not in the freeze hint, oops ;)
<slangasek> so blocking bug is it
<rbasak> I used the "update to 5.7" bug but moved it to the new src:mysql-5.7 first. So I presume it'll work.
<slangasek> should do, yes
<Skuggen> rbasak: Ok
<Son_Goku> nacc: soâ¦ I sorta/kinda cajoled Remi into porting libvirt-php to work on php7: https://gitlab.com/Conan_Kudo/libvirt-php7/commits/php7
<Son_Goku> Iâm going to try to see if I can get it upstreamed
<Son_Goku> I really, really, really want to get it upstreamed
<Son_Goku> Iâm not a huge fan of maintaining a fork like this
<nacc> Son_Goku: cool, also on my list to look at
<ginggs> cjwatson: so fpc 3.0.0+dfsg-2 has become uninstallable on powerpc. I installed 2.6.4+dfsg-8 from wily and tried building 3.0.0+dfsg-4. It got to 99% and then hit an access violation
<ginggs> [ 99%] Compiled package zorba
<ginggs> An unhandled exception occurred at $0FE502D0:
<ginggs> EAccessViolation:
<ginggs>   $0FE502D0
<ginggs>   $0FE5E684
<ginggs>   $0FE152A8
<ginggs>   $0FE1537C
<slangasek> Son_Goku: no. UsrMerge is upside-down from the way a merged /usr should be done
<Son_Goku> slangasek: how so?
<slangasek> things should be merged into /, not into /usr
<Son_Goku> why
<pitti> err, no
<Son_Goku> slangasek: merging things into / sounds like itâd make things harder, not easier
<cjwatson> ginggs: I'm not going to be able to help further with this, I was just pointing in the right general direction to start with
<ginggs> cjwatson: ok, i pinged you because i recall you have bootstrapped fpc in the past
<cjwatson> ginggs: I can help with rebootstrapping given specific directions if that's what it needs, but not with the investigation along the way
<cjwatson> I probably just did something mechanical based on Debian's binaries, if it was me
<coreycb> bdmurray, can you reject the wily nova upload that is in the queue?  I am going to combine it with another sru.
<bdmurray> coreycb: done
<coreycb> bdmurray, thanks
<pitti> slangasek: do you happen to know about watershed?
<coreycb> bdmurray, can you also reject the python-oslo.messaging upload to wily dated 2016-03-18?
<slangasek> pitti: sure
<pitti> slangasek: if I run "/lib/udev/watershed sleep 5" n times, are the other n-1 instances actually supposed to hang until the first one finishes?
<slangasek> pitti: yes
<pitti> I wonder if that's a regression, or I just misunderstand how watershed works
<slangasek> watershed serializes, but doesn't skip the calls
<pitti> ah, then it's rather pointless to use watershed in an udev rule
<slangasek> well
<slangasek> the purpose is to avoid multiple calls to a thing running in parallel that shouldn't
<pitti> slangasek: thanks, so I guess we'll either need to change watershed (it's only being used by that lvm rule and apport-noui) or find something else that's non-blocking
<slangasek> but we can't just /drop/ the extra calls, because of races
<slangasek> why non-blocking? because of udev rule timeouts?
<pitti> that too, but blocking an udev rule blocks the worker, and there's only finitely many of them
<pitti> so in that bug 1560710 with 50 LVs this leads to a deadock
<ubottu> bug 1560710 in udev (Ubuntu) "ISST-SAN:KVM:R3-0:Unable to get the login prompt after reinstallation of Ubuntu16.04" [Undecided,New] https://launchpad.net/bugs/1560710
<slangasek> right
<pitti> ok, I'll think about that, thanks for confirming that it's not a regression in watershed itself
<slangasek> but are there expectations elsewhere in the system that the rule be synchronous?
<infinity> How did I know that was going to be an IBM bug as soon as you said "50 LVs"
<slangasek> yeah, it's not a regression, it's just IBM testing at scale
<slangasek> ;)
<pitti> slangasek: not really -- the only point is to run vgchange after the last pending LVM event got processed
<slangasek> ok
<tsimonq2> cjwatson: good :)
<pitti> that can happen asynchronously (and it might cause more uevents due to the new block devices)
<pitti> slangasek: at scale> yeah, not even smb managed to hit that limit :)
<slangasek> pitti: so if the actual calls to vgscan/vgchange need to be serialized, maybe watershed itself should just be backgrounded in the rule?
<infinity> pitti: In IBM's world, this isn't "at scale", this is "normal".
<pitti> no, you can't background stuff from an udev rule
<pitti> :)
<smb> pitti, I would not be sure :-P
<pitti> it'll get killed right after the main process exits (to avoid zombies)
<infinity> Even our teeny tiny POWER8 machines from them are insanely overspecced.
<slangasek> pitti: wellll that what would it matter if watershed "hung"?  or did you just not understand the purpose of watershed?
<slangasek> s/that/then/
<pitti> slangasek: obviously; I thought it woudl detect if the same command was already running, just re-inc the "refcount" of the first instance, and quit itself immediately
<pitti> but apparently it's not doing that
<slangasek> pitti: ah.  can't do that, because not guaranteed that the running command picked up the latest events
<slangasek> that's the race I meant
<pitti> slangasek: right, every further call would need to update some stamp file/thingy somewhere which resets the first instance's idea of "after"
<slangasek> pitti: now, maybe what watershed should actually do is detect when there are *two* other watersheds running, and quietly exit any others
<pitti> slangasek: hm, but how is that guaranteeing that the first or second one defers the re-run enough for the n-th invocation?
<slangasek> because if you have 1 running, and 5 queued, when the first one exits you only need 1 of the other 5 to run to catch up
<slangasek> not all 5 of them back-to-back
<pitti> right, but the second one is just going to wait for #1, not for #17, no?
<slangasek> and actually this would also address the boot-time load bugs we saw with apport-noui
<pitti> well, I don't know how watershed detects duplicates of itself, maybe that already works
<slangasek> it doesn't work
<slangasek> I know for sure ;)
<pitti> so, somewhere in teh system we need some kind of lock/stamp file with the command
<pitti> and duplicate invocations need to touch that
<slangasek> but if we made it do so, it would improve the scaling of watershed with AFAIK no downsides
<infinity> No need for lock files.
<pitti> and some running instance needs to defer the second run until after the current timestamp
<sarnold> having N-2 of them exit may only work when the command that's called is idempotent
<pitti> sarnold: it is
<pitti> it's always exactly the same "/sbin/lvm vgscan; /sbin/lvm vgchange -a y"
<pitti> the point is just to run it *after* the last pending LVM uevent
<pitti> and avoid running multiple copies while a whole bunch of them is coming in in parallle
<pitti> well, this is an ugly hack which we've been carrying for a decade, maybe this is all moot with modern versions, not sure
<pitti> infinity: well, not necessarily lock files, but the watersheds must communicate with each other somehow if we don't want all of them to stick around indefinitely?
<infinity> pitti: Instead of lockfiles, I'd think all it needs is a SIGUSR* handler.  New invocation of watershed sends signal to all running watersheds.  If running watershed is in "wait" state and /proc/<pid-of-process-that-signalled-us>/cmdline matches our own, exit immediately.
<infinity> Once we transition from wait to running, just ignore SIGUSR and carry on to a normal exit.
<coreycb> bdmurray, thanks.  if you or someone else on the sru team has some time we could use reviews of nova, python-oslo.messaging, and keystone in the wily queue.
<chiluk> slangasek who should I talk to about auto package test SRU failures http://people.canonical.com/~ubuntu-archive/pending-sru.html ??  The failures for coreutils and initramfs-tools all look to be infrastructure issues.
<pitti> infinity: nice idea; it currently communicates via /run/watershed/ files, but comparing /proc/pid/cmdline sounds easier indeed
<sarnold> does ibm have any systems where 64k pids aren't enough? :) it might not be fun to find all watershed processes if there's a few hundred thousand or million processes running
<pitti> well, hopefully with a change like this they would die much quicker
<pitti> and thus there should only be at most one long-running one around
<sarnold> sorry, I meant if the system has a few hundred thousand -other- processes running
<pitti> oh, that's right
<sarnold> say if someone goes nuts and runs a few hundred thousand ubuntu lxds
<pitti> you mean that pidof takes too long
<sarnold> yeah, that's a lot of getdents / open / read / close .. calls
<pitti> so maybe we'll keep the /run/watershed/ files for now
<slangasek> chiluk: pitti is a good resource for that :)
<sarnold> a shared memory segment may be quicker
<infinity> pitti: Yeah, I didn't realise it already uses the filesystem.  It just seems Wrong(tm) for a utility like this to touch files at all, given that one might not know exactly what system context it's being run in (pre-boot, mid-pivot, post-boot...)
<sarnold> files for watershed specifically probably also fine
<slangasek> infinity: we mount --move /run, though
<infinity> slangasek: Fair.
<chiluk> thanks slangasek.  Hey pitti.  it looks like the failures for initramfs-tools and coreutils on   http://people.canonical.com/~ubuntu-archive/pending-sru.html appear very bogus..
<pitti> ok, but I guess we mostly agree to changing watershed instead of trying to invent a new tool which does that?
<infinity> pitti: Fixing watershed to not have 200 copies of itself blocking on the same cmdline seems like the right thing to do regardless.
<infinity> pitti: Time, of course (or lack thereof) may lead to other hacks that aren't the Right Thing. :P
<pitti> chiluk: ah indeed; the kernel has lots of special cases, we can't currently test those for other triggers; can you please file a bug for it against auto-package-testing? For the time being, please ignore those
<chiluk> sure thing will do.
<pitti> well, we could increase the number of workers so that it hits the wall on 80 instead of 40 LVMs, at the expense of slowing down everything else
<pitti> but that doesn't feel like a real solution
<slangasek> infinity, pitti: I guess this seems straightforward to me; maybe I'll have a look at the watershed code
<infinity> pitti: No, not a real solution at all and, while big iron can handle it, slangasek's note about this being a real problem on small devices for apport-noui as well leads to a "maybe it's time to just fix it right".
<pitti> I'll update the bug then, thanks for the discussion
<slangasek> sarnold: btw, regarding idempotency, cf. the watershed.c header - "for optimizing away unnecessary runs of idempotent commands".
<sarnold> slangasek: yay :) my trusty system didn't have a manpage so it wasn't clear that it's only for idempotent calls..
<infinity> sarnold: xenial also lacks a manpage for it. :)
<infinity> Evidently, one is meant to read the source to determine if they want to use it.
<sarnold> ah :) hehe
<slangasek> infinity: or the package description; or just read Scott's mind
<infinity> slangasek: I don't recommend the latter.
<slangasek> and the package description says it is supposed to only result in one further attempt, instead of one for each call to watershed
<slangasek> but I think we found that didn't work for apport-noui
<slangasek> and regardless, the udev workers need to not block, rather than just not running extra copies of vgscan
<pitti> FTR, it's still bearable to block one of them, so that the other's don't get deadlocked
<slangasek> pitti: ok, just checked, and yes watershed *does* only run 2 copies of the command (the first one, and one at the end).  So the only issue is whether watershed itself blocks until the command has run
<slangasek> if backgrounding the command doesn't work, then a --nowait option to watershed may be the thing
<slangasek> (new option, to avoid breaking the existing contract, just in case)
<pitti> AFAIUI, right now it's the last called instance of watershed which executes the second command, right?
<pitti> and that'd need to become the first one, with some time stamp bumping/signal receiving/whatever
 * pitti still reading watershed.c
<pitti> hm, from the "Theory:" it's not clear how the second (last) time the command is actually ran
<pitti> if all other invocations happen while the first one is stil running, none but the first can grab the lock, and it only runs the command if it can grab the lock
<slangasek> pitti: so, all the processes in the "cohort", which are waiting for the currently-running process to finish, try to acquire the lock in parallel; whichever one succeeds first is the "lockholder" and runs the process; the others sit waiting for the lock held by the current process, and once it clears they read back the data from the cohort_fd (the file is unlinked, but the processes all have an open
<slangasek>  fd to it, which defines the cohort)
<slangasek> this makes it somewhat difficult to define a --no-wait option, since the process doesn't know if it's supposed to be the runner or not until it's succeeded in acquiring the lock
<TJ-> who would be responsible for mariadb on the ubuntu side? some recent Debian changes incorporating passwordless auth via unix_socket has broken log-in over TCP for the same user
<sarnold> TJ-: otto kek.... otto something :)
<TJ-> sarnold: do you know if Otto KekÃ¤lÃ¤inen sits on the Ubuntu side as well Debian?
<Skuggen> I think he does
<TJ-> sarnold: I've just spent an interesting few hours debugging this with another user who reported it
<Skuggen> rbasak: Right?
<TJ-> Skuggen: thanks. I'll email him first and ask about this
<sarnold> TJ-: I opened the bug so otto couldsee it 1561062
<Skuggen> mysql-5.7 does something similar with a passwordless root user, but it only touches root@localhost, so not entirely sure how MariaDB does it
<TJ-> Skuggen: that's the issue; root@localhost cannot log-in over TCP protocol when the GRANT .. identified via unix_socket is in place
<Skuggen> Ah, right. Then we'll probably have the same issue in mysql-5.7
<TJ-> Yes
<TJ-> is unix_socket built-in on mysql too?
<Skuggen> It's a plugin
<Skuggen> The maintainer script checks if the root user has passwordless login. If it does, it enables the unix socket auth
<TJ-> right, so it isn't affected out-of-the-box
<Skuggen> You can change it back easily enough (though you'd need to be able to log in)
<TJ-> the mariadb has built the module in and sets unix_socket for root by default
<Skuggen> TJ-: You could try manually changing the plugin field in the user table and running flush privileges after
<TJ-> Skuggen: tried that and many other things. The main problem is the other 2 user entries for root@[127.0.0.1|::1] are never reached because they're reversed to be 'localhost' despite any changes to /etc/hosts
<Skuggen> TJ-: Even if you override --host when starting the client?
<TJ-> Skuggen: that has no effect on what the server does. I just found a sneaky way to avoid the unix_socket rule - configuring te server with skip-name-resolve but that's hardly a solution, but it proves the other 2 rules added by these passwordless auth patches are useless when name-resolving is enabled
<rbasak> TJ-, Skuggen: yeah, otto should be able to help. Whichever way we probably want to support the same use cases in the same way between MySQL and MariaDB - there's no reason to differ and we should come up with the same conclusion for both variants. And that's for Debian and Ubuntu as well. So would you mind raising your use case on the Debian MySQL mailing list please?
<rbasak> In general Ubuntu is in sync with Debian with both MySQL and MariaDB now, apart from release-time differences, so we'll want to fix this in Debian.
<doko> pitti, a quick reminder how I run autopkg tests against a version in -proposed? (mpdecimal)
<doko> rbasak, squid3 is still blocked by some manual testing. did that happen?
<mwhudson> is/was lxc broken on xenial? http://paste.ubuntu.com/15480646/
<doko> barry, you accepted the last mksh, please could you have a look at the pdksh removal: http://people.canonical.com/~ubuntu-archive/nbs.html
<barry> doko: ack
<doko> ta
<barry> doko: pdksh revdeps are all safe since they conditionally dep on pdksh, e.g.: Depends: ${misc:Depends}, ${shlibs:Depends}, ksh | mksh | pdksh | zsh,
<barry>  
<barry> i can file bugs in debian (haven't checked yet) to get rid of them, but i don't think we need to update them in ubuntu to remove pdksh
<LocutusOfBorg> ginggs, thanks
<doko> barry, no, that's good enough. thanks for checking. removing the binary
<balloons> barry, I added a new one for your python3 quest :-) , just fyi: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1561210
<ubottu> Launchpad bug 1561210 in juju-core (Ubuntu) "juju-core should depend on python3" [Undecided,New]
<barry> balloons: \o/  - let me know if i can help
<balloons> barry, sounds like it's trivial, but just wanted to make sure you knew about it, since it's definitely going to be on the image
<barry> balloons: which image?
<balloons> well presumably your crusade thus far is only against the desktop images right?
<balloons> in which case you are safe
<barry> balloons: server too
<barry> which i think has been py2 free for a while
<balloons> yea, here I thought juju was on the server image
<balloons> I guess if you care about all packages in main it applies :-)
<nacc> Pharaoh_Atem: fyi: rebuilt wordpress seems to work fine with php7
<nacc> jgrimm: --^
<jgrimm> nice!
<mwhudson> sigh, i thought i'd started on ubuntu dev when it was safe to pretend cdbs didn't exist
<nacc> mwhudson: :) i've hit it a few times too
#ubuntu-devel 2016-03-24
<Pharaoh_Atem> mwhudson: no one is safe to pretend about cdbs :P
<mwhudson> luckily i'm just adding a patch
<nacc> Pharaoh_Atem: up to the j* packages with dropping php5 references :)
<Pharaoh_Atem> nacc: *\o/*
<mapreri> what would be the use of a delta like this?  https://patches.ubuntu.com/m/mairix/mairix_0.23+git20131125-0.4ubuntu1.patch
<mapreri> language-pack-en-base seems to be something totally different than locales-all ?  (granted, I've no clue why locales-all is needed in this package for)
<nacc> Logan: --^ ? :)
<nacc> mapreri: iiuc, it's so that locales get generated (and the langpacks do that too)
<nacc> mapreri: and older ubuntu didn't package locales-all
<nacc> mapreri: it is in xenial, though, so maybe that delta can be dropped now, not sure
<nacc> slangasek: done for the day again with debdiffs, will hopefully get more done tomorrow
<nacc> slangasek: three of the packages can be just rebuilt, i figured i'll just update the file in that bug at the end, if that's ok with you?
<slangasek> nacc: yep, that's fine, thanks!
<nacc> slangasek: also, i'm going to confer with kirkland about drupal7 tmrw to make sure he's ok with its removal
<nacc> slangasek: thank you for your help!
<slangasek> doko: do you understand the build failure for comet-ms? it gives errors about undefined references in /usr/lib/libmstoolkitlite.so to gzip functions, but 'ldd -d -r' shows it's properly linked to libz
<mapreri> nacc: it's weird as that change was done for xenial explicitly.
<mapreri> (sorry missed the highlight before...)
<nacc> mapreri: i'm really not sure, oddly, loooking at the glibc changelog (http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.23-0ubuntu2/changelog), 2.21-0ubuntu1 explicitly disables locales-all
<mwhudson> anyone want to make ibm happy and sponsor https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1561271 ? :)
<ubottu> Launchpad bug 1561271 in golang-1.6 (Ubuntu) "updated s390x port" [Undecided,New]
<nacc> mapreri: there's no mention of it being dropped from the delta, though
<mapreri> booh
<nacc> mapreri: oh actually it's there
<nacc> sorry it's a hard chagnelog to read
<nacc> Merge locales back into glibc and provide locales-all (LP: #1394929)
<ubottu> Launchpad bug 1394929 in langpack-locales (Ubuntu) "[FFe]Please provide 'locales-all' as in Debian" [Undecided,Confirmed] https://launchpad.net/bugs/1394929
<nacc> mapreri: that only got commited on 3/16
<nacc> mapreri: so i'm guessing Logan's change predates it
<nacc> and can be dropped
<mapreri> ok, I see
<mapreri> though I've never noticed locales-all was missing from ubuntu
<mapreri> anyway, that package is basically unmaintained in the debian, so the next force sync will have to wait
<mapreri> i hope whoever will do it will notice that this can be dropped.
<nacc> mapreri: rmadison indicates it doesn't exist anywhere else than xenial, and that's because we generate them all with langpacks, afaict
<nacc> slangasek: i did hit a weird issue with freedombox-setup; i can't run autopkgtests against it (nor against the version in the archive) if I build the pkg due to avahi failures ... might be a known problem?
<slangasek> nacc: nothing I know about
<nacc> slangasek: ok, i'll be interested to see if the same failure is seen by autopkgtest then, and i'll try and debug it a bit tmrw otherwise
<lathiat_> nacc: got a log?
<Logan> mapreri: nacc is correct
<Logan> locales-all didn't exist at the time
<Logan> I'll drop the delta when Debian releases a new version
<Logan> no real use of switching it back to locales-all right now
<cpaelzer> good morning
<Laibsch> Somebody around that is willing to sponsor SRU for bug 1547431?
<ubottu> bug 1547431 in apt-cacher-ng (Ubuntu Trusty) "Does not allow appstream files" [Medium,Confirmed] https://launchpad.net/bugs/1547431
<pitti> Good morning
<pitti> doko: add a second --trigger src/ver for the additional source that should come from -proposed, or use --all-proposed to completely disable the apt pinning
<zyga> good morning :)
<cpaelzer> that might sound silly, but I'm missing an upload, yesterday at 14:51 CET jamespages uploaded dpdk 2.2.0-0ubuntu6 for me
<cpaelzer> it doesn't show up in update_excuses, nor is it gone through
<cpaelzer> are there other places to watch where/if it might have failed - or are there other things currently stalled due to e.g. archive changes and such?
<dholbach> good morning
<smb> cpaelzer, Morning. I think there is a beta freeze around
<cpaelzer> smb: thanks, that makes sense and would explain the situation
<cpaelzer> maybe I should just call it easter weekend earlier today and check for them early next week
<caribou> anyone seeing dnsmasq process running like crazy this morning ?
<caribou> nevermind, own network mixup
<cpaelzer> caribou: not more than usually when it messes with my vpn
<caribou> cpaelzer: :)
<Saviq> pitti, morning, can I please ask you to recycle the two regressions seen in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scope-click - and about that - the failure seems to be locale related, is there a guideline on what wrt locale can be expected in the adt runners?
<pitti> Saviq: I retreid them
<pitti> Saviq: normally C.UTF-8
<pitti> Saviq: the recent switch to glibc 2.23 might have broken something there, though
<pitti> sorry, /me is sick, will crawl back to bed
<Saviq> pitti, oh sorry, of course, get well
<alexlist> infinity: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/798414 -> any chance we get >250MB /boot on systems with large enough disks?
<ubottu> Launchpad bug 798414 in initramfs-tools (Ubuntu) "update-initramfs should produce a more helpful error when there isn't enough free space" [Medium,Confirmed]
<pkern> Hi. Was the ddebs.ubuntu.com signing key change reverted? I see a file from 2008 again when I access that host.
<pkern> Since around yesterday 4:15 Pacific TIme.
<rbasak> doko: not yet, sorry. My priority is some Juju stuff right now. I'll get to squid after this.
<cjwatson> pkern: There was a data loss incident and ddebs had to be restored from backups, I believe
<cjwatson> pkern: I have write access but don't want to touch it without talking to pitti, who's currently unwell
<cjwatson> (Not least because the data loss incident was apparently somehow triggered by the attempted re-signing - don't know the details)
<pkern> cjwatson: I see, thanks. Will the new signing key come back?
<cjwatson> pkern: I'll have to defer that to pitti.
<pitti> pkern: yes, and I can't re-apply the new signatures until I figured out what wiped out ddebs.u.c.
<pitti> but I'm afraid I'm currently not really in a condition to do in-depth debugging
 * Laney hugs pitti 
<Laney> get better!
<pitti> thanks
<Laney> just in time for the long weekend eh
 * dholbach hugs pitti too
<Saviq> xnox, will you have some time to tackle bug #1552914 ?
<ubottu> bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,Confirmed] https://launchpad.net/bugs/1552914
<flexiondotorg> cyphermox, Potentially some good news.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689
<ubottu> Launchpad bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged]
<flexiondotorg> See my last comment.
<cyphermox> mmkay
<cyphermox> I'll look later...
<cyphermox> I think I just finally saw what was wrong with keyboards
<flexiondotorg> Just tested on three machines, all with different GPUs.
<flexiondotorg> And had no problems.
<cyphermox> took me long 'nough
<flexiondotorg> The computers used had previously exhibited the issue.
<flexiondotorg> cyphermox, Keyboards?
<cyphermox> language selection is messed up
<flexiondotorg> I saw Lubuntu has an issue.
<flexiondotorg> I'll double check Ubuntu MATE.
<cyphermox> flexiondotorg: a good test is SV
<flexiondotorg> OK
<flexiondotorg> cyphermox, Will this result in a respin?
<cyphermox> I don't know, ask on #ubuntu-release
<superm1> cjwatson: i noticed that secureboot-db isn't ending up in the pool for mythbuntu ISO's even though grub-efi-amd64-signed and grub-efi-amd64 are.  consequently EFI installation fails.  any pointers for checking why this is happening?
<flexiondotorg> cyphermox, Ubuntu MATE is not affected. Swedish keyboard layout persists after install in the settings and is mapped correctly as best as I can tell.
<cyphermox> oh, it is affected; you need to use english at the boot splash and then choose swedish
<cyphermox> that is, unless of course someone fixed things in between yesterday's image and today's, if you're using a new image
<doko> nacc, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html, and removing the references for the obsolete binary packages?
<cjwatson> superm1: I imagine recommends are disabled somewhere relevant
<superm1> cjwatson: okay thanks i'll poke around looking for something related to recommends
<cjwatson> superm1: ah, no
<nacc> doko: yes, will get that done today
<cjwatson> superm1: it's already in the livefs isn't it?
<cjwatson> hmm, maybe not
<nacc> lathiat_: i'll try and rerun this morning and paste it here
<cjwatson> germinate thinks it should be, the manifest says it isn't
<superm1> there were a few other odd ones i noticed dropped off the manifest running germinate last time (acpi-support and two or three others)
<superm1> so maybe related
<flexiondotorg> English was the default language, I changed the keyboard only to Swedish during the install.
<cjwatson> superm1: ah I see
<cjwatson> superm1: http://bazaar.launchpad.net/~mythbuntu-dev/ubuntu-seeds/mythbuntu.xenial/revision/1267 should fix it
<superm1> cjwatson: ah great thanks
<superm1> i'll regenerate and try
<cjwatson> the lack of that meant that germinate considered the stuff in live-common to be installed when expanding stuff in live and above, but it wasn't actually in the task so livecd-rootfs didn't install it
<cjwatson> superm1: don't do it immediately, it'll take a couple of xenial publisher runs to take effect
<superm1> OK
<mterry> stgraber: got a sec?  We've got a few touch packages that want to land in xenial but are in UNAPPROVED
<cyphermox> flexiondotorg: I'll pick the mate image to do any further testing on this
<chiluk> infinity: http://apple.stackexchange.com/questions/135967/can-i-use-non-apple-headphones-with-an-iphone/135972
<chiluk> those bastards.
<mterry> doko: ^ above: we've got a few touch packages that want to land in xenial but are in UNAPPROVED, do you have a moment to go through them
<ginggs> doko, infinity, LocutusOfBorg: I've confirmed the problem with installing fpc 3 on powerpc is related to glibc 2.23. After downgrading  libc6*, gcc* and locales, fp-compiler installs just fine. Any ideas?
<chiluk> arges I'll verify lp 1315755 now
<ubottu> Launchpad bug 1315755 in initramfs-tools (Ubuntu Trusty) "/init: line 327: egrep: not found" [High,Fix committed] https://launchpad.net/bugs/1315755
<chiluk> or at least look into it
<arges> k
<nacc> slangasek: so after talking to kirkland, there is interest in keeping drupal7 in the arhcive; but based upon upstream feedback, not yet present upstream even. Do you hve any guidance on the best way to proceed? I can backport the upstream fixes (once present) to our version, probably?
<slangasek> nacc: "interest in keeping it in the archive" doesn't make it releasable
<nacc> slangasek: or, i should say, he vetoed my suggestion of dropping it :)
<slangasek> kirkland: so what are you expecting here?  There was agreement with the server team that anything that php5 would be dropped from the archive for 16.04, in exchange for php7.0; drupal doesn't support php7.  Are you asking to keep php5 in the archive now?
<nacc> slangasek: i'm going to see what our drupal7 version looks like, test-wise, with php7 right now
<mterry> cjwatson, slangasek: continuing my pokes of archive members  :)  If anyone has time to go through xenial UNAPPROVED, there are some touch packages we landed in a big u8 silo that we'd like to shepherd through
<cjwatson> not me sorry
<GunnarHj> slangasek: Saw your im-config bug. Has whiptail replace dialog in Debian too? (im-config is a Debian package, i.e. would it need to be an Ubuntu delta?
<chiluk> arges verified.. no errors in kern.log or syslog. so I think that's sufficient to call it verified. lp 1315755
<ubottu> Launchpad bug 1315755 in initramfs-tools (Ubuntu Trusty) "/init: line 327: egrep: not found" [High,Fix committed] https://launchpad.net/bugs/1315755
<arges> chiluk: mark it down dude
<chiluk> huh?
<chiluk> arges what do you mean by that.
<arges> chiluk: you did, I meant put 'verification-done' in the bug
<chiluk> it is.
<arges> ok
<infinity> mterry: Stuff will be let out en masse later today when I'm happy with thawing the beta freeze.
<infinity> mterry: Unless one can make a valid argument for "IT MUST LAND IN THE NEXT TWO HOURS OR WE'LL ALL BE SET ON FIRE".
<mterry> infinity: no.  I was just being a bit antzy because it's annoying for our u8 devs on xenial.  But not that annoying  :)
<mterry> infinity: thanks
<Saviq> infinity, one thing to note: not sure how much we messed up by deleting packages from a PPA when they were in UNAPPROVED - if you find that stuff is missing in ppa:ci-train-ppa-service/landing-013, it's now in ppa:ci-train-ppa-service/landing-057 - not sure if the new copies overwrote the previous ones
<Saviq> and thanks :)
<nacc> slangasek: hrm, interesting -- not necessarily an authoritative test, but i was able to configure a blog using my rebuilt drupal7, now i'm going to see if i can run the tests manually
<bdmurray> chiluk: For which SRU are you awaiting a release?
<infinity> Saviq: As in, there are two copies in the queue, and I want the -057 ones?
<chiluk> bdmurray: https://bugs.launchpad.net/ubuntu/trusty/+source/coreutils/+bug/1535349
<ubottu> Launchpad bug 1535349 in initramfs-tools (Ubuntu Trusty) "`df /dev/sda1` no longer reports information for /dev/sda1" [Medium,Fix released]
<chiluk> bdmurray initramfs-tools just needs to be promoted to -updates
<bdmurray> chiluk: and you and pitti talked about the test failures being false positives yesterday?
<bdmurray> chiluk: oh, somebody beat me to it
<chiluk> bdmurray yeah.. I opened bugs against autotest yesterday about them.
<xnox> Saviq, that boost bug, yes, will fix next week. Away on holiday now and dealing only with urgent things. let me assign it tomyself unless it is really urgetn
<xnox> it is assigned
<Saviq> infinity, afaict, yes, because the -013 ones were deleted from the PPA
<infinity> Saviq: Kay.
<kirkland> slangasek: I understand from nacc that upstream drupal and upstream php are jointly working right now to get drupal7 working with php7
<kirkland> slangasek: I advised nacc that we could proceed with dropping php5, AS LONG AS we're working hard to getting drupal7 to work with php7, meaning we'll probably need a drupal7 upload(s) and/or SRUs
<kirkland> slangasek: I'm not okay with purging drupal entirely from the archive;  that would be a real disappointment to downstream Ubuntu server users
<dholbach> can somebody review snapcraft in the queue (important bug fix), it's not seeded anywhere
<dholbach> oh maybe it was just accepted
<cjwatson> unseeded stuff is usually auto-accepted
<cjwatson> (and this was AFAICS)
<nacc> kirkland: well, it's just upstream drupal, to be clear
<nacc> kirkland: php doesn't care about the sites that haven't migrated yet :)
<nacc> s/sites/projects/
<kirkland> nacc: hrm, really?  okay, well you have contact with php, too, right?  can you ask them to help?
<nacc> kirkland: i seriously doubt they will
<nacc> kirkland: php (language) developers don't seem to interact much with their downstream, afaict
<slangasek> kirkland: ok - I am also comfortable with pulling php5 out from under drupal7 and SRUing drupal7 fixes in if necessary
<kirkland> nacc: okay
<kirkland> slangasek: +1
<slangasek> kirkland: and I like that answer much better than keeping php5 in universe, thanks ;)
<nacc> slangasek: it does seem to run, i'm checking all the tests now; it's unclear if it's a regression relative to our php5 status (i'm going to check in a wily lxc) ... as we don't run the tests during build/etc
<hikiko> hello
<hikiko> infinity
<hikiko> are you around?
<infinity> hikiko: I am.
<hikiko> hi :)
<hikiko> I need your help on something
<hikiko> there was a bug report that compiz crashes during the upgrade from lts 14 to 16
<hikiko> and after some workaround I did with andyrock
<hikiko> we found out that any desktop crashes
<hikiko> and the last message we get at compiz is that libc.so is missing
<hikiko> so, I wanted to test two ideas I had but I don't know much about packaging
<hikiko> the 1st one:
<infinity> hikiko: I'd perhaps like to see the real error message, not a paraphrasing.
<hikiko> sure infinity, let me find the log, it's andyrock that produced it
<hikiko> sec
<GunnarHj> infinity: Should I make a real patch with the remaining suggestions I have wrt bug #1560577?
<ubottu> bug 1560577 in glibc (Ubuntu) "Confusing new locale-gen behavior" [High,Confirmed] https://launchpad.net/bugs/1560577
<infinity> GunnarHj: We should talk about it a day that isn't today, probably.
<infinity> GunnarHj: I had some mental notes about your last patch, but too busy with Beta to get to the nitty-gritty of it all.
<GunnarHj> infinity: Ok, then I'll try to be patient. (I think that last grep() is incorrect, but not sure what it's supposed to do.)
<infinity> GunnarHj: It's neither forgotten nor ignored, though, I agree with the spirit of the bug report and patch.
<GunnarHj> infinity: Great! :)
<infinity> GunnarHj: Most of that code was cargo-culted from our old locale-gen, right or wrong, so also happy to clean up bits that are obviously wrong or pointless.
<hikiko> https://www.irccloud.com/pastebin/kxQlPlKR
<hikiko> infinity, ^
<infinity> GunnarHj: I'd like to end up shipping something that has decent backward compat but is also a sane enough delta to push to Debian, so we can stop this forked madness.
<hikiko> and there was a most recent one from metacity:
<hikiko> https://www.irccloud.com/pastebin/Wl0AcISq
<GunnarHj> infinity: Sounds as a reasonable goal.
 * infinity notes he missed an opportunity to say "stop this forking madness".
<hikiko> I was wondering if it's possible that since libc went multiarch at the time of the crash the new libc is installed on the system but the dynamic loader looks at the wrong path because it's not updated (searches the old libc paths)
<cjwatson> multiarch was well before 14.04 LTS
<hikiko> then it can't be that...
<cjwatson> <cjwatson@tuna ~>$ lsb_release -rs
<cjwatson> 14.04
<cjwatson> <cjwatson@tuna ~>$ ldd /bin/ls | fgrep libc.so
<cjwatson>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a0ca70000)
<hikiko> the other thing I was wondering is if there's any ldconfig missing
<hikiko> and I found a post inst script that had one commented out
<hikiko> but I am not familiar with all these might not be libc at all
<infinity> Doesn't look like libc's fault in the unity case.  The red herring there is that it's trying to debug itself post-crash, using the debug libraries matching what it was linked to in memory.
<hikiko> but since the gui programs are not responsible for the crash it might be some package
<infinity> But it crashed well before it failed to backtrace.
<hikiko> infinity, I saw some messages about cron
<hikiko> I couldn't get relevant logs after the crash
<hikiko> so I recorded the gui upgrade
<hikiko> do you want me to send you the last frame?
<hikiko> to see the messages?
<infinity> And the metacity one gives me exactly zero info.  It's exiting on a SIGPIPE, which implies perhaps that X died.
<hikiko> yep
<hikiko> every log i checked gives 0 info :/
<hikiko> dmesg, apt logs
<hikiko> syslog
<infinity> X logs?
<hikiko> no errors
<hikiko> :/
<hikiko> I ll send you the last frame
<infinity> Well, the metacity one certainly implies to me that it's X dying, not the window managers.
<infinity> And the WMs tend not to do well without a root window to paint.
<hikiko> yes that's what I believe tooo
<infinity> Stupid picky window managers.
<hikiko> X is dead for sure after the crash
<hikiko> but there's nothing in the logs
<hikiko> if I ssh I can see that xserver died
<hikiko> you can't connect to any display
<hikiko> but the log is ok
<hikiko> no errors
<hikiko> infinity, http://i.imgur.com/A35uMti.jpg
<hikiko> that isserv warning was in everyone's crash
<infinity> It could be that something in the upstart->systemd transition is killing the X server, which would lead to the whole session dying and, potentially, nothing interesting in the X logs.
<hikiko> btw the udev.postinst:109 needs a fix: double [[]] in the line that takes the basename
<infinity> hikiko: The insserv cron warning is also a red herring here (though possibly another bug).
<hikiko> I have no idea how to make a patch for that...
<hikiko> yep
<infinity> hikiko: And the udev postinst bug is fixed in git, pitti claims it's only cosmetic.
<hikiko> yes
<hikiko> that line is never called basically
<hikiko> I just told you to narrow the warnings
<hikiko> because I was lost and was checking every single line :/
<hikiko> oh! infinity
<hikiko> andyrock, said that he always sees the crash after udev restarts
<hikiko> could this be relevant?
<hikiko> in my screenshot it seems that udev restarts, plus after the crash if i reboot the kernel panic gives the message: "cannot mount root fs"
<slangasek> hikiko: if unity is trying to trace itself after crash, it's probably doing a poor job of it.  Is that what's happened here, like infinity suggests? or is this the output of trying to run compiz under gdb?
<hikiko> is it possible that the kernel doesnt create an initrd?
<hikiko> slangasek, I am not sure andyrock did this debugging
<slangasek> hikiko: no one has reported bugs about missing initrd.  The initrd should always be created before the grub config is updated.
<slangasek> hikiko: so it's possible that compiz is trying to attach gdb to itself automatically, but that it only does this after the crash happens, which is insufficient
<andyrock> It x crashing
<andyrock> Not unity
<hikiko> yes
<hikiko> x crashes
<slangasek> ok
<andyrock> You can reproduce the crash with metaciyy
<slangasek> so, to debug this, you want to attach gdb to the X server remotely, and capture a backtrace
<andyrock> I suppose with g-s too
<infinity> Now, the real question is if X is *crashing* or being killed externally.
<andyrock> I tried
<infinity> My bet is on the latter.
<andyrock> But gdb crashes too
<slangasek> andyrock: how did you run gdb?
<andyrock> I guess because xorg got updated in the mean time
<slangasek> and this is where "remotely" probably means "ssh from another machine", since if the X server crashes and blocks the VT you're going to have a hard time switching VTs to see the debug output
<andyrock> infinity:  I guess the latter too
<hikiko> what looks weird to me is how a gui program like compiz could cause such a big crash that leads to kernel panic, I think that either the updater crashes at the time a critical package is updating and destroys everything (but it wouldn't be the same crash when i add and remove repositories) or a package post upgrade scripts do something that xserver doesn't like
<andyrock> X crashes or is killed
<infinity> There's a kernel panic?  No one told me that little tidbit.
<andyrock> This causes the upgrade crash
<andyrock> infinity:  just on reboot
<hikiko> infinity, that's afterwards
<hikiko> on the reboot
<infinity> Oh.  Kay.
<slangasek> hikiko: that's secondary
<andyrock> So it s not relevant
<slangasek> or possibly unrelated
<hikiko> alright
<hikiko> infinity, one other info that made me suspect that multi arch thing is that in i386 there's no crash
<hikiko> I upgraded successfully
<hikiko> that's why I thought that it might be some outdated path or sth
<hikiko> maybe not in libc but somewhere else
<infinity> hikiko: Paths to libraries changing under a binary should have zero effect on upgrades, as the current running libraries are locked in RAM (and on disk, just unlinked) until the refcount hits zero.
<andyrock> There is also a thing about libkbd that had some problems with amd64
<andyrock> I at the phone right now
<infinity> hikiko: The only exception to that rule being things dlopen()ing libraries at runtime, but if X is doing that to any of its underlying libs after init, it should be taken out and shot.
<slangasek> hikiko: what we need here is a useful backtrace of the actual crash - whether that's in X or in compiz.  If you're reproducing this, can you please ssh into your system remotely and attach gdb to both compiz and X, then upgrade?
<infinity> My bet's still on it not being a crash at all but an external signal.
<infinity> But that would be nice to confirm, and trace back to the offender.
<hikiko> I agree with infinity
<hikiko> because there's no error in the logs
<hikiko> but I am going to attach the x process to gdb
<hikiko> from ssh
<slangasek> hikiko: it will save time if you attach to both compiz and X at the same time, in case we're wrong about it being an X crash
<slangasek> hikiko: also, please be sure to install libc6-dbg before running gdb
<hikiko> mmm ok but it will take time
<hikiko> (the upgrade etc)
<slangasek> yes, this is why you want to debug both processes in parallel so you don't have to upgrade twice
<hikiko> I have to reinstall the vm
<hikiko> because I saved a snapshot
<hikiko> in the middle of the upgrade to save time
<hikiko> and I didn't install libc-dbg :/
<jderose> tjaalton: a strange bug I'm experiencing with xorg-server 1.18.2-2ubuntu0.1 from the x-staging PPA - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1561685
<ubottu> Launchpad bug 1561685 in xorg-server (Ubuntu) "x-staging: 1.18.2-2ubuntu0.1 host breaks arrow keys on qemu guest" [Undecided,New]
<tjaalton> jderose: ok, thanks for filing it
<jderose> tjaalton: np. please let me know if there are any other scenarios you'd like me to test to help you narrow your search
<smoser> Get:7 http://us.archive.ubuntu.com/ubuntu xenial/universe DEP-11 64x64 Icons [7,491 kB]
<smoser> after release, am i going to be graced with the benefit of downloading 8M of icons quite often ?
<infinity> smoser: Well, the ones in the release pocket would never change, one would expect.
<smoser> i really know nothing about DEP-11 other than my 'apt-get update' just now downloaded 18M of data, only 10 of which was package data.
<infinity> smoser: And apt has gotten quite good about not even hitting things that haven't changed.
<ogra_> s/me guesses thats somehow related to gnome-software replacing the sw-center
<smoser> and this new data is not goign to be changing any more frequently than apt package data ?
<hikiko> slangasek I'll leave the upgrade finishing and I'll email it to you tomorrow because it's almost 21:00 here and the installation + upgrade with 2 processes attached to gdb will take ages
<smoser> i was very happy to find apt not downloading as much stuff as it used to, and then it started ownloading 10s of Meg of icon data that i'll never look at.
<hikiko> I guess more than 2hrs
<sarnold> smoser: so far I have the impression that you can simply delete or truncate /etc/apt/apt.conf.d/50appstream to avoid the giant tarball of icons
<sarnold> smoser: there may be a clever dpkg redirect option too that would prevent the config file from being installed in the first place, but that kind of 'old dpkg magic' feels shrouded in mists.. :)
<tjaalton> jderose: well, if you could bisect the point-release commits that would be great
<jderose> tjaalton: sure. what's the best way to do this?
<jderose> tjaalton: i can figure it out, but if you have any tips, i'd appreciate them. where is the packaging repository for the x-staging PPA hosted?
<slangasek> hikiko: understood, thanks
<tjaalton> jderose: i've used a patch which partly reverts the update, and then change the point to "bisect"
<tjaalton> jderose: same place as debian
<tjaalton> control file has the url
<jderose> okay, thanks
<yofel> where on the live image do I find the ubiquity-dm startup sequence?
<yofel> I'm trying to launch it by hand, but I don't see how to make it start the language selector
<nacc> slangasek: so we're already two updates behind current drupal7 ... (debian unstable has 7.43-1). Based upon https://api.drupal.org/api/drupal/CHANGELOG.txt/7, I'm not 100% on needing a FFe for it (mix of bugfixes and feature improvements, i think), but would you prefer we wait for 7.44, presuming i can figure out if that will be soon? i'm guessing that version will have the php7 changes, but not sure
<nacc> on that yet. In the meanwhile, i've got the simple debdiff that modifies the control file as it is now, and does work in my basic testing (although it's unclear if a bunch of stuff is broken in the various modules).
<nacc> Pharaoh_Atem: on reading: https://github.com/kohana/core/issues/642#issuecomment-151244760, can we drop all of libkohana?
<nacc> Pharaoh_Atem: no reverse deps in the archive, that i can see
<nacc> minimially it seems like the versions we have in the archive are unsupported
<doko> mterry, are they still stuck? archive is currently frozen for the beta
<slangasek> nacc: should have an FFe; can be fairly pro forma, of the style "if we don't update to the new upstream version, we don't get php7 compatibility (or security support, or installability)"
<nacc> slangasek: ok, i'll try and get in touch with the upstream developers to see if 7.44 will have the requried fixes or not ... and i've asked a few that have commented in antoher bug to see if they can test what we have
<Pharaoh_Atem> nacc: so Kohana is dead then
<nacc> Pharaoh_Atem: well, that' the thing
<nacc> i think it's *not* dead :)
<nacc> but no one updated the issue
<nacc> 3.1 and 3.2 are dead, or at least, from the old kohana structure
<nacc> they reorged and are doing releases again
<nacc> but i think only unpacakged version support php7 :/
<Pharaoh_Atem> oh dear
<nacc> 3.3 and 4.0-dev
<nacc> but no packages in the archive depend on them
<nacc> so not sure it matters too much, and no one has requested or tried to pakcage 3.3, it seems
<Pharaoh_Atem> hmm
<doko> nacc, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  see php-json on the right side
<nacc> doko: yep, it's on my list to figure out ... dh-php5 is going to be gone, but it's part of php5
<nacc> doko: also, i think it's a false positive, possibly, as php-json itself is now part of php7, but there was a php-json that was its own package with php5
<doko> nacc, tell me if a nag too much ;p
<nacc> doko: no it's good! it's just a lot going on at the same time :)
<nacc> doko: it will clear out once we can push src:php-json to universe, which will happen once i rebuild the revdeps on php5-json :)
<nacc> and then it will get removed from the archive anyways
<nacc> doko: i've been going alphabeticall through the revdeps of src:php5, but will switch tack once i finish the l's, to cleanup that and the NBS
<nacc> Pharaoh_Atem: just contacted upstream kohana developer, even the offical 3.3.5 doesn't support php7, only his private fork does
<nacc> Pharaoh_Atem: 4.0.0 will, but doesn't exist
<Pharaoh_Atem> well, that's problematic, then
<Pharaoh_Atem> if it doesn't exist, it'll probably need to be yanked
<nacc> Pharaoh_Atem: yep, already requested
<Pharaoh_Atem> nacc: as for dh-php5 and php-json, they can just die :)
<nacc> Pharaoh_Atem: yes, they will
<nacc> Pharaoh_Atem: there are many revdeps to resolve first
<nacc> can't just break the archive
<Pharaoh_Atem> php-json is php-pecl(json) (aka, Remi's php-pecl-jsonc), which is no longer required and php7.0-json is a fully equivalent provider
<nacc> Pharaoh_Atem: yes, i know
<nacc> Pharaoh_Atem: that's not good enough
<nacc> Pharaoh_Atem: we have to ifx the packages
<Pharaoh_Atem> ah, right
<nacc> php5-cli is still in the archive and depends on php5-json
<nacc> as does php5-cgi
<Pharaoh_Atem> and of course, all the extensions and apps
<nacc> kirkland: have you already tested that pictor is php7 compliant? if it uses the php-imagic in 16.04?
<nacc> imagick, rather
<nacc> doko: ok, NBS-related debdiffs have been posted
<kirkland> nacc: indeed, pictor and php7 is working great!
<nacc> kirkland: ok, cool -- the latest build will officially only use the php7 deps (in particular php-imagick rather than php5-imagick)
<nacc> kirkland: thanks!
<sarnold> cyphermox, infinity, looks like ubiquity didn't like the recent apt changes 1561472
<nacc> hey, below 400 packages revdep'ing on src:php5! :)
 * cyphermox weeps
<sarnold> nacc: nice, how many did you start with? :)
<cyphermox> sarnold: thanks
<sarnold> cyphermox: sorry :) heh
<nacc> sarnold: 413, iirc
<sarnold> cyphermox: it seems like it might not actually be one for you but i'm not sure who else to direct it to
<sarnold> nacc: hehe gonna be a long slow road I guess..
<nacc> we're down to 380, but that's based upon what's current in the revdep tool, might be farther than that now
<nacc> sarnold: yeah ... :/
<nacc> sarnold: getting through horde will be a big chunk of it
<infinity> sarnold: That warning is just a warning.  And already fixed in debian-cd.
<sarnold> infinity: ah! hooray times two :)
<stefanct> anybody willing to review a FFe and sponsor an upload? :) https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/1558822
<ubottu> Launchpad bug 1558822 in flashrom (Ubuntu) "[FFe] sync flashrom 0.9.9+r1954-1 from Debian" [Undecided,Confirmed]
<slangasek> nacc: "unlikely to be PHP7.0-compliant" - so, what's the case for uploading this patch, as opposed to leaving drupal7 as-is in the archive (and uninstallable once php5 is removed), and upload it only once there's something that actually works?
<nacc> slangasek: I didn't realize having it uninstallable was a viable option, sorry. And like I tried to mention earlier, it does seem to start ok, but I don't know how to test it all (I asked for some help from teh community on that)
<nacc> slangasek: i'm fine with leaving it uninstallable if you prefer while we get clarity there
<slangasek> nacc: ok; let's drop this from the list for now, then
<nacc> slangasek: want me to delete the task and debdiff?
<slangasek> nacc: works for me
<nacc> slangasek: done
<infinity> nacc: There is scripts/run-tests.sh, though I have no idea how extensive that is.
<nacc> infinity: yeah, i started using that
<nacc> and it indicates some errors
<nacc> but i need to setup a wily env with php5 and see if any are regressions
<nacc> it also is quite slow :)
<nacc> but that's ok
<nacc> it's on my roadmap to try and figure out tmrw
#ubuntu-devel 2016-03-25
<nacc> Pharaoh_Atem: sigh, http://trac.roundcube.net/ticket/1490544
<nacc> not packaged yet either, will need to figure that out tmrw
<slangasek> nacc: pictor, your patch is against a stale version; there's a 2.35-0ubuntu1 package that you're in the changelog of
<nacc> slangasek: ha! ok ... let me check that, sorry
<slangasek> nacc: likewise, simplesamlphp is against a stale version
<slangasek> nacc: and I would dearly love for further debdiffs to be in a bug per package instead of in one bug report with 800 tasks... at some point LP is going to flip the table on us
<nacc> slangasek: ok, i can do that from now on ... sorry
<nacc> slangasek: so looks like roundcube 1.2 (current at beta) is teh only version that supports php7 ... similar issue as drupal7, afaict
<nacc> kirkland: for the pictor upload (2.35-0ubuntu1) why did you keep php5 compat in the control file? there is no php5-imagick, e.g., in xenial
<nacc> kirkland: are you ok if we drop that compat?
<slangasek> nacc: my view is that if it's in universe and it doesn't support php7, it's expendable and can be cut from release.  I am not, however, the product manager for Ubuntu Server.  From an archive/release POV, I'm perfectly willing to take a roundcube beta into the release instead, if a) someone is willing to do the work to prepare that package and make it work, b) upstream isn't going to yell at us for
<slangasek>  including their beta, c) any requests for an update ...
<slangasek> ... from the beta to the final release post-16.04 follow the SRU process
<nacc> slangasek: yep, understood. I think there are a class of applications that simply aren't going to be updated; but roundcube is making progress it seems like. I'll take a look at the packaging requirements tmrw
<nacc> slangasek: updated simplesamlphp debdiff
<nacc> slangasek: pictor may be fine as-is, depends on what kirkland wants to do
<slangasek> nacc: the | php5 stuff shouldn't break the package, if there were no changes to the actual contents
<nacc> slangasek: it shows up in http://people.canonical.com/~ubuntu-archive/nbs.html
<nacc> and i was aksed to fix that
<slangasek> nacc: well, when we remove php5 from the archive, it will not show up there anymore ;)
<nacc> won't it? the pictor package will still depend on php | php5, php-imagick | php5-imagick ?
<slangasek> nacc: this is a limitation of nbs, it doesn't know how to unpick alternative dependencies
<nacc> slangasek: ah ok, i wasn't sure, yeah, it's purely an alternative for that one
<nacc> the others are real and fixed in today's set of patches
<slangasek> if that's the only remaining revdep of php5-imagick, and pictor depends php-imagick | php5-imagick, we can pull it already
<nacc> yep, afaict that's it and how it is
<slangasek> nacc: php5-imagick removed from xenial
<slangasek> doko: python3.5 - why bump libmpdec_version instead of removing this check from the testsuite? why is python hard-coding a requirement of a matching minor version of libmpdec?
<nacc> slangasek: thanks!
<slangasek> nacc: should simplesamlphp's bin/memcacheSync.php have been updated?
<karstensrage> hi
<karstensrage> how does something from debian packaging get into ubuntu
<karstensrage> for example if a debian package is new
<karstensrage> how would it get into 14.04?
<infinity> karstensrage: You wouldn't, 14.04 is a stable release.
<infinity> karstensrage: But we can get it into 16.04
<infinity> (And then you could perhaps request a backport)
<karstensrage> how do i do that
<karstensrage> has 16.04 synced to debian yet?
<infinity> karstensrage: I don't know what package you're asking about...
<karstensrage> can i pm?
<infinity> Public conversations work fine.
<Unit193> Because of your asking, I requested a sync. :3
 * Unit193 waits for the day infinity kills him. :D
<karstensrage> infinity, https://packages.debian.org/testing/libs/libufpidentity1
<karstensrage> there is another one coming too, but its stuck in mentors
<karstensrage> hi Unit193
<infinity> karstensrage: Synced to 16.04
<karstensrage> it is?
<infinity> karstensrage: When the mentors one clears Debian NEW, let me know and I'll grab that too.
<karstensrage> alright? can i see that?
<karstensrage> and how do i ask for a backport for 14.04?
<karstensrage> thank you so much
<infinity> https://launchpad.net/ubuntu/+source/identity4c/1.0-1
<infinity> karstensrage: To request backports, you need to talk to the backports folks.
<infinity> karstensrage: https://wiki.ubuntu.com/UbuntuBackports
<karstensrage> ok thank you
<karstensrage> infinity, how long do i have for clearing Debian New
<infinity> karstensrage: Well, we release 16.04 in under a month.  So, that long.
<karstensrage> hmmm
<karstensrage> ill do my best
<karstensrage> oh infinity did that pull in the devel package too?
<karstensrage> dev package?
<karstensrage> oh yes
<karstensrage> i see thank you
<karstensrage> whats a good candidate for the reasoning part?
<karstensrage> just want new functionality on 14.04?
<karstensrage> and possibly 12.04 since there are still machines out there that havent updated?
<ilhami> hey
<ilhami> Has OTA 10 been released yet by Canonical?
<slangasek> nacc: so, the simplesamlphp diff switches a dep to php-mhash, which doesn't exist?
<slangasek> nacc: but neither does php5-mhash
<infinity> slangasek: mhash is builtin to all SAPIs (for both 5 and 7.0)
<infinity> So that's a useless dep.
<slangasek> ok, so it was probably a legacy provides
<LocutusOfBorg> hi folks, do you have any news about glibc/binutils/powerpc breakage?
<LocutusOfBorg> ginggs, I found your chat, but I didn't see any answer :(
<infinity> LocutusOfBorg: What glibc/binutils/powerpc breakage?
<LocutusOfBorg> infinity, nobody can install fpc on powerpc
<LocutusOfBorg> simple as that
<infinity> And this is glibc's fault somehow?
<LocutusOfBorg> ginggs, did some debugging
<LocutusOfBorg> the postinst script has a command that triggers a SEGFAULT
<LocutusOfBorg> and downgrading glibc fixes the issue
<LocutusOfBorg> let me find the bits, just a second
<LocutusOfBorg> [17:20:25] <ginggs> doko, infinity, LocutusOfBorg: I've confirmed the
<LocutusOfBorg> problem with installing fpc 3 on powerpc is related to glibc 2.23.
<LocutusOfBorg> After downgrading  libc6*, gcc* and locales, fp-compiler installs just
<LocutusOfBorg> fine. Any ideas?
<LocutusOfBorg> "I get the same access violation just running 'fpcmkcfg-3.0.0'.
<LocutusOfBorg> And even just asking for help segfaults."
<infinity> Hrm.  No ideas, but I can look into it later.
<LocutusOfBorg> you can just call that "fpcmkcfg-3.0.0 -h" command
<infinity> Right.  I'll give it a stab later.  It's almost certainly fpc's fault, not glibc's, but I'll need to dig and sort out why to prove that theory. :P
<LocutusOfBorg> the problem is: fpc doesn't build on powerpc anymore because it depends on itself
<Unit193> zigo: python-googleapi has a few incompatibilities with the python-oauth2client now in xenial.
<infinity> (And it needs fixing either way)
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/fpc
<zigo> Unit193: Oh... :/
<infinity> LocutusOfBorg: Yeah, I know, I have the build log open.
<LocutusOfBorg> thanks!
<infinity> LocutusOfBorg: Like I said, I'll look later.
<Unit193> zigo: New upstream fixes it at least..
<infinity> LocutusOfBorg: I'd like to understand why it broke before I just go and rebootstrap it.
<LocutusOfBorg> I'm happy to fix fpc sure, but I think I won't be able to do it alone, right?
<infinity> Cause if it's using internal symbols or something, it should stop.
<LocutusOfBorg> thanks a lot, funny enough it was working with the older glibc :)
<LocutusOfBorg> thanks for giving a shot!
<ginggs> infinity: thanks. FWIW with the new glibc, I was able to install fpc 2.6.4 from wily but building 3.0.0 failed with the same access violation at 99% :(
<zigo> Unit193: I'm not the maintainer of it, so maybe you could ping Laszlo Boszormenyi, he's usually very responsive.
<zigo> (and maintains a lot of stuff there...)
<LocutusOfBorg> that fpc has important fPIC fixes on arm* I need them, because they are a big regression compared with 2.6.4, and fixes hedgewars
<Unit193> Unfortunately and more importantly to me, broke gcalcli too. ;/
<infinity> LocutusOfBorg: Ahh, well, wouldn't want hedgewars to be broken. ;)
<LocutusOfBorg> yeah, nothing is more imporant in life than games :)
<infinity> LocutusOfBorg: I'm about to take a long weekend, but I might poke fpc when bored.
<infinity> I vaguely recall the last time I rummaged around in fpc's guts.
<LocutusOfBorg> thanks! and happy Easter, I'll be taking a rest too :)
<LocutusOfBorg> s/rest/helpwifeincookingalotofstuffforeaster/
<mterry> doko: no they aren't stuck anymore, thanks
<Laney> Anyone know where I can find langpack generation logs?
<Laney> or another way that I can get a list of packages that have their translations put in there
<Laney> aha I found mapping.txt
<superm1> infinity: since beta2 is out no concerns from me in unblocking that mysql-5.7 out of proposed
<superm1> i can sort out fallout in the myth* stuff now
<Skuggen> superm1: Nice. We also need to fix some test failures with dbconfig-common for it (and redmine, but I'm guessing those can also be traced to dbconfig)
<ginggs> doko: julia has been FTBFS on armhf for several weeks, I've just tried downgrading to gcc-5 5.3.1-3ubuntu1 (where I know I definitely built before) and it builds fine. What can I do further?
<hikiko> infinity, slangasek ping
<hikiko> Program received signal SIGPIPE, Broken pipe.
<hikiko> 0x00007f82e0535417 in __libc_writev (fd=50, vector=
<hikiko>     at ../sysdeps/unix/sysv/linux/writev.c:49
<hikiko> the x crash
<hikiko> compiz didn't crash it crashes later because of x
<superm1> Skuggen: http://paste.ubuntu.com/15496370/
<superm1> Skuggen: that's with the stuff in proposed, not sure where that header is supposed to be coming from
<Skuggen> Hm. Could you check what's in include/mysql/mysql? There's some mess with the header layout the devs haven't gotten around to clean up yet (though I don't think it should have been moved)
<hikiko> sorry :)
<hikiko> wrong signal
<hikiko> that's earlier :p
<superm1> Skuggen: looks to be in that directory
<superm1> http://paste.ubuntu.com/15496401/
<Skuggen> superm1: But it used to work in 5.6? From what I can see in the source the file is in the same place for 5.6.28
<superm1> Skuggen: never caused build failures previously
<superm1> so maybe the path declared in /usr/include/mysql/mysql/client_plugin.h changed?
<superm1> Skuggen: from what i see in 5.5 (on 14.04 box) client_plugin.h wasn't included in /usr/include/mysql/mysql.h, so that's the part that's newer
<superm1> don't have a 5.6 handy ATM
<Skuggen> Ah, no it's not included in 5.6
<Skuggen> https://github.com/ltangvald/mysql-5.6/blob/master/include/mysql.h
<Skuggen> If you add include/mysql on the include path, does it work?
<superm1> yes that works
<superm1> the part that broke for me was this is how a configure script was testing things
<Skuggen> Yeah, it's kind of a mess the way the includes are structured right now :|
<nacc> slangasek: ah sorry, thanks for catching that!
<nacc> slangasek: we can probably do a best effort here, if you're ok with an addition fix for simplesamlphp to suggest `phpenmod -s cli memcache`, iiuc
<nacc> Pharaoh_Atem: --^ is that rigth?
<nacc> Pharaoh_Atem: and independently, how well do you know horde? :)
<nacc> Pharaoh_Atem: nm on the latter
<barry> slangasek: i think we should ignore pbgenomicconsensus amd64.  retries don't help but local adt-runs in xenial-proposed chroots always pass for me
<barry> slangasek: then there's python-pbh5tools; pretty much same deal
<nacc> slangasek: re: LP: 1562060, i tested that the roundcube 1.2~beta installs and seems to run (I don't have an IMAP server setup so can't test it further)
<ubottu> Launchpad bug 1562060 in roundcube (Ubuntu) "Please update to roundcube 1.2" [Undecided,New] https://launchpad.net/bugs/1562060
<karstensrage> infinity, how come it looks everything has been published but when i search for the package here https://launchpad.net/ubuntu/xenial it doesnt show up?
<karstensrage> infinity, also do i have to woo some sponsor for a backport bug or are they just picked up eventually?
<nacc> karstensrage: hrm? https://launchpad.net/ubuntu/xenial/+search?text=libufpidentity1
<nacc> slangasek: fyi, I think with LP: #1562090 just filed, the horde stuff stuck in proposed should pass its tests
<ubottu> Launchpad bug 1562090 in php-horde-passwd (Ubuntu) "Update to PHP7.0 dependencies" [Undecided,New] https://launchpad.net/bugs/1562090
<nacc> i'll keep working through the rest of horde
<Pharaoh_Atem> nacc: on the former, that looks right to me
<nacc> Pharaoh_Atem: ok, will send a patch, thanks
<Pharaoh_Atem> on the latter, I have little clue about Horde :/
<jdstrand> cjwatson: fyi (I don't need anything right now), bug #1562118
<ubottu> bug 1562118 in debmirror (Ubuntu) ".temp/dists/.../Packages goes out of date" [Undecided,New] https://launchpad.net/bugs/1562118
<slangasek> hikiko: did you get a full backtrace under gdb of the crash? 'bt full'.  also are you sure it was the SIGPIPE that killed the process, and that X didn't handle that SIGPIPE later?
<slangasek> barry: pbgenomicconsensus, you probably can't reproduce the failure because you're testing with different versions of packages than what the autopkgtest infrastructure does.  I'm guessing you're doing a run with -proposed versions of packages, rather than using python-pysam 0.7.7-1ubuntu1 like the log shows?  So, it's possible to skip this test failure for python-setuptools since we know python-set
<slangasek> uptools isn't the cause, but please follow up on ...
<slangasek> ... python-pysam because this indicates real bugginess currently in xenial
<nacc> slangasek: looks like moodle is similar to drupal and others ... working on it now, had to fix the watch file too :/
<slangasek> barry: there, pbgenomicconsensus no longer a failed test ;)
<slangasek> nacc: hehe, enjoy...
<slangasek> nacc: LP: #1562090 uploaded, which horde tests do we want retried once that's published?
<ubottu> Launchpad bug 1562090 in php-horde-passwd (Ubuntu) "Update to PHP7.0 dependencies" [Undecided,Fix committed] https://launchpad.net/bugs/1562090
<nacc> slangasek: sorry, we'll need that one and the others i submitted today, wnat me to give you the list? I think i subscribed you to all of htem?
<nacc> turba is the big one, it seems like (affecting a bunch of other packages that is)
<slangasek> nacc: if you subscribed me then the list is in my inbox.  ok, from your earlier comment I understood that 1562090 was the only one needed for unblocking, but yes I had seen the turba failures and wondered how -passwd was going to unblock that.  I'll have a look, though I'm actually off today so no promises that I'll get through the stack before Monday
<nacc> slangasek: it's ok, i just  wanted to let you know they were taken care of :)
<nacc> slangasek: i'd rather you didn't work today and relaxed!
<slangasek> nacc: I relax better with fewer incoming tasks in my inbox ;-)
<nacc> slangasek: uhh, unlikely! although on my last check, we were down to 350 packages! these bigger frameworks slow me down, obviously, as pulling in a new version is not the easiest thing
<barry> slangasek: magic!
<slangasek> barry: python-pbh5tools still broken though, also points to pysam, so retrying with -proposed pysam there as well.  So maybe this unblocks it without hinting, but then python-pysam still needs attention to get it migrated
<barry> slangasek: ack
<Umeaboy> Hi!
<Umeaboy> I made a bugreport about E173 not being able to connect in Xenial.
<Umeaboy> Sorry.
<Umeaboy> In Wily.
<Umeaboy> It works on Xenial.
<Umeaboy> Can someone please push an update of NetworkManager and Policykit from Xenial to Wily?
<Umeaboy> The problem is at the window to enter the pin code.
<Umeaboy> It just won't accept it even thou it's entirely correct.
<cjwatson> jdstrand: yeah, hoping to have time to sort that out pretty soon
#ubuntu-devel 2016-03-26
<karstensrage> whats involved in getting backport bugs addressed
<lamont> I don't like it when apt-get dist-upgrade says this:
<lamont> Fetched 7,012 kB in 25s (275 kB/s)
<lamont> Segmentation fault
<karstensrage> is that 16.04?
<GunnarHj> karstensrage: Ping someone in https://launchpad.net/~ubuntu-backporters
<karstensrage> anyone? there are only 10?
<karstensrage> the pending members have been pending for quite some time O.O
<karstensrage> broder, maybe you might be interested?
<karstensrage> whats the criteria for backporting new
<karstensrage> stuff
<fastercat> Is there any additonal debug output I can turn on for a video driver?
<fastercat> It is crashing with cryptic messages like NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
<fastercat> and a lot of NVRM: Xid (PCI:0000:07:00): 3, C 00000002 SC 00000003 M 00000104 Data 00000000
<fastercat> It is:07:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
<Unit193> zigo: LP 1562358 finally filed, along with LP 1562356.  Just FYI.
<ubottu> Launchpad bug 1562358 in python-googleapi (Ubuntu) "python-googleapi is incompatible with oauth2client >= 2.x" [Undecided,New] https://launchpad.net/bugs/1562358
<ubottu> Launchpad bug 1562356 in gcalcli (Ubuntu) "gcalcli incompatible with oauth2client >= 2.x" [Undecided,New] https://launchpad.net/bugs/1562356
<juliank> lamont: If the crash was in xenial, apt 1.2.8 fixes a known segfault. It just needs to be synced. It would still make sense to have a full backtrace, if possible.
<juliank> Oh wait, no, 1.2.8 fixes an update segfault.
<juliank> So a full bt would be *really* useful
<juliank> If it's APT that's crashing, otherwise I don't care :)
<infinity> Skuggen: usr/include/mysql/mysql/client_plugin.h:103:38: fatal error: mysql/plugin_auth_common.h: No such file or directory
<infinity> compilation terminated.
<infinity> Skuggen: MySQL's fault, or mythtv's?
<infinity> superm1: mythtv seems to hate you.
<Skuggen> infinity: mysql.h includes mysql/client_plugin.h in 5.7, and didn't in 5.6
<Skuggen> It needs include/mysql on the include path to work
<infinity> Skuggen: Is that not provided by pkg-config or similar (or is mythtv not using it?)
<Skuggen> The header structure is a bit of a mess. Devs are working on cleaning it up, but wasn't ready for the 5.7 release :|
<Skuggen> Yeah, I haven't seen that issue outside mythtv so far
<Skuggen> So it's part that the directory structure is weird and part that mythtv does something a bit differently, I think
<infinity> Yeah.  Looking now.
<superm1> I explicitly patched to fix that
 * superm1 shrugs
<infinity> superm1: You may have patched the wrong bit.  The g++ command sure doesn't have the include.
 * infinity grabs the source.
<superm1> I patched the header check and the .pro to add the includes. It did all work correctly in my local test build
<superm1> I'm afk atm I'll look when I get to computer
<lamont> juliank: gdb apt-get; r dist-upgrade.... and it's working :(
<lamont> oh, right .. let's do this on the correct machine
<infinity> Hah.
<lamont> apt-get dist-upgrade ==> segv.  apt-get install gdb ==>runs to completion fine.
<lamont> bug inbound against apt with the trqace
<infinity> You're lucky the latter didn't fix the former.
<lamont> I KNOW
 * lamont was quite concerned actually
<infinity> I'd have unpacked a dpkg deb without dpkg or apt's databases being involved, probably. :P
<lamont> I see that 1.2.8 is there, I'll try that after I file the bug.
<infinity> s/dpkg deb/gdb deb/
<lamont> heh
<lamont> you know it's a red letter day, when you get to type Yes, do as I say!, twice.
<infinity> I don't think I've had to type that in years.
<infinity> I get the prompt all the time, but that's my own stupid fault, and it's saving me from myself.
<lamont> oh yes, that prompt is the machine going, no seriously, think about this one before you say yes, multiple times.
<lamont> if you ever determine that you should really type it, it's time to file a bug.
<infinity> It's triggered by removing an Essential package, IIRC.  Not a whole lot of logic behind it.
<infinity> And yes, absolutely a distro bug if it happens without you explicitly removing something you shouldn't.
<lamont> yep.  removing essential is the whole and sole cause of that
 * infinity upgrades his IBM PowerStation from 14.04 to 16.04 for the lolz.
 * lamont attaches the trace from 1.2.8
<lamont> juliank: over to you sir, lp #1562402
<ubottu> Launchpad bug 1562402 in apt (Ubuntu) "segv in apt 1.2.7 with dist-upgrade" [Undecided,New] https://launchpad.net/bugs/1562402
<infinity> Man, this disk (and the SAS controller it's attached to) were wildly overspecced for this machine.
<juliank> Oh no
<juliank> Two different backtraces :/
<infinity> I do believe this is the only 15k RPM disk in my house.
<lamont> infinity: is it time for me to start shifting the home infra to xenial?
<infinity> But I guess this is what happens when you ask IBM to make an "affordable workstation".
<juliank> lamont: Can you generate a bt with dbgsyms?
<lamont> maybe
<infinity> lamont: That's what I'm doing right now.  I think we still have one or two upgrade bugs you might want to wait on, though.
 * lamont hasn't bothered with dbgsyms in ages... process?
<infinity> lamont: Definitely have one that fubars upgrades in GUIs.
<infinity> lamont: I'm seeing now how serverish upgrades go.
<lamont> infinity: I see
 * lamont will let infinity embrace the suck on his behalf
<infinity> Right now, all I can report is that server upgrades are fast.  If you have a disk that can actually keep up with your CPU.
<infinity> Or, in this case, a disk that might be faster than my CPU. :P
<juliank> lamont: and/or run it in valgrind
<juliank> (preferably and)
<infinity> lamont: dbgsyms == install libc6-dbg and install the matching lib and apt ddebs from http://ddebs.ubuntu.com/pool/main/a/apt/
<lamont> sigh.  installed valgrind (and the most recent maas, because of huh), and then ran apt-get dist-upgrade... and it's running
<infinity> lamont: Yes, you can add ddebs.u.c to sources.list and 'apt-get install apt-dbgsym' too, if apt is working.
<infinity> Oh.  Or valgrind broke you.  \o/
<juliank> :(
<lamont> yeah  it could have been that the maas ppa install tickled it into happiness, too
<infinity> Yay for perturbing databases until it works. :(
<lamont> but valgrind and I are about to have some fun
<lamont> infinity: no yay
 * lamont loves hard failurs
<infinity> Saving /var/lib/dpkg, /var/cache/apt, and /var/lib/apt might have been nice.
<infinity> If you have a time machine.
<infinity> DO YOU HAVE A TIME MACHINE?!
<lamont> "dammit, I wish I'd created that lvmsnapshot that I didn;t think to do this time"
<lamont> ah, but I do have a backup of yesterday that includes /var/lib/dpkg
<infinity> Indeed you would.
<infinity> If you know what you've installed since, it's pretty safe to restore the old dpkg bits.  Well, safe-ish.
<infinity> And just reinstall overtop again.
<infinity> After debugging. :P
<lamont> sigh
<lamont> backup excludes for /var: lib/dpkg/
<infinity> lamont: /var/backups
<lamont> I'll rewind the maas bits, maybe
<lamont> oh!
<juliank> lamont: Do you perhaps have /var/backups/dpkg.status.0{,1.gz,2.gz}
<infinity> It's not the entirety of /var/lib/dpkg, IIRC, but it's the databases apt cares about.
 * juliank has that on Debian
<juliank> but not sure why
<lamont> yeah
<lamont> do I care about more than dpkg.status?
<infinity> Possibly apt.extended_states.0 too, depending on where the crash was.
<juliank> That should be it. You can just pass -o Dir::State::Status=/var/backups/dpkg.status.0  to APT I'd think
<lamont> Segmentation fault
<lamont> \o/
<juliank> Yay! Let's go valgrinding that bastard.
 * lamont installs dbg syms
<lamont> W: Failed to fetch http://ddebs.ubuntu.com/ubuntu/dists/xenial-proposed/main/binary-amd64/Packages  404  Not Found
<lamont> W: Failed to fetch http://ddebs.ubuntu.com/ubuntu/dists/xenial-proposed/main/binary-amd64/Packages  404  Not Found
<lamont> infinity: sigh.. what does that ddebs line look like?
<infinity> lamont: No ubuntu.
<lamont> ta
<infinity> Just ddebs.u.c/ $series $comp $comp
<infinity> We really should put an ubuntu symlink in there to /
<juliank> infinity: oh, thanks for the 1.2.8 sync.
<infinity> Maybe I'll do that right now.
<infinity> juliank: I caught you talking about it in backscroll, changelog looked sane, so you're welcome.
<lamont> http://paste.ubuntu.com/15514548/ <-- with dbgsyms
<stgraber> infinity: yes we should! it's been bugging me SO many times
<infinity> stgraber: Done.
 * infinity tests.
<juliank> I don't think it's mentioned in the changelog, but I made the flaky tests retry, so I hope it passes CI on all architectures now, even the always-failed armhf
<lamont> http://paste.ubuntu.com/15514567/ <-- juliank
<lamont> looking forward to 1.2.9 :D
<stgraber> yay
<infinity> Looks like that did the trick.
<infinity> lamont: Works with ubuntu now too. :P
 * lamont hugs infinity
<infinity> Err.
<juliank> hmm, seems like those dbgsym do not match your installed version :(
<infinity> Except for apt yelling at me about it.
<lamont> oh, yeha
<infinity> Oh, but that's true regardless of the path.
<infinity> It just needs fixing still.
<juliank> Anyway, that's fairly weird stuff
<infinity> Or I need to ship the key in the distro.  Derp.
<Unit193> ddebs could likely be useful to add commented out in the default sources.list these days.
<lamont> juliank: that's 1.2.7 syms with 1.2.8 apt. :(
 * juliank thought so
<infinity> So get 1.2.8 syms?
<juliank> seems the new ones are not available yet
<infinity> They're available in LP.
<infinity> https://launchpad.net/ubuntu/+source/apt/1.2.8/+build/9403755
<lamont> http://paste.ubuntu.com/15514599/ <-- full valgrind
<lamont> infinity: reinstalled 1.2.7
<infinity> That works too.  But I suspect he wants both if they're different.
<lamont> http://paste.ubuntu.com/15514613/
<lamont> juliank: ^^ 1.2.7 bt
<juliank> lamont: reinstall libapt-pkg5.0=1.2.7
<infinity> lamont: Also, dude, learn to autoremove.
<lamont> meh
<juliank> You only pulled in the apt binaries, not the library
<lamont> infinity: I do.. this is me not perturbing the db
<juliank> infinity: Now both are the same...
<juliank> Oh well, sorry, library is not downgraded yet.
<lamont> ii  libapt-pkg5.0:amd64                 1.2.7                               amd64        package management runtime library
<juliank> weird
<lamont> dpkg -l | grep 1.2.8 yields only zlib1g
<lamont> infinity: lp #1543683 has me being generous in my keeping of kernels
<ubottu> Launchpad bug 1543683 in linux (Ubuntu Xenial) "Fails to detect (second) display" [Medium,Fix released] https://launchpad.net/bugs/1543683
<juliank> To be fair, I have no idea what's going on. It seems that we are iterating to a broken dependency
<juliank> (in both cases)
<lamont> and sometime between now and mondya, I need to boot a kernel so that I can definitively say that the "fix released" there is an outright lie
<lamont> juliank: there is one small lie in the status file, that I don't think should matter... Package: perl5 Depends: perl, because I haven't rebuilt a binary yet to depend on perl instead of perl5
<lamont> mentioned in the interests of full disclosure
 * lamont tries one other thing
<lamont> interesting... if I drop the maas ppas, then all is happy and right in the world again
 * lamont bisects
 * infinity still resents that he needs to do this after do-release-upgrade:
<infinity> dpkg -l | awk '/^rc/ {print $2}' | xargs dpkg -P
<lamont> amusingly, /var/backups is in my backup
<infinity> lamont: Could the maas PPA have a broken control file somewhere that dpkg somehow missed?
<lamont> I have been doing rm /var/lib/apt/lists/*; apt-get update each pass
<juliank> infinity: Would you rather do apt purge ?config-files
<infinity> juliank: I didn't know that was a thing.
<lamont> File descriptor 3 (pipe:[5854305]) leaked on vgs invocation. Parent PID 3149: /usr/sbin/grub-probe
<juliank> infinity: It isn't
<lamont> stupid grub-probe
<infinity> juliank: But it's not the shell pipe that I resent, it's that I can't upgrade-with-purge via the release-upgrader.  ie: it's our bug. :P
<juliank> infinity: It's an aptitude thing right now...
<juliank> But I definitely want patterns in APT soon-ish
<infinity> lamont: As to the parallel topic, a serverish do-release-upgrade -d seemed to DTRT.  Packages all installed, postinsts all succeeded, the only unexpected removal was aptitude (which I almost consider a feature, but I suppose I should look into).
<lamont> heh
<infinity> Rebooting now to be sure it actually worked...
<lamont> yeah, they'll squawk about that
<infinity> And it boots!
<infinity> All systemdish and kernel 4.4ish.
<juliank> lamont: YOu might want to run with Debug::pkgPackageManager=yes and see which package causes that (it should be the last printed in a line starting with SmartUnPack)
<juliank> then you can see if there's anything odd about that
<juliank> We need to retry the APT test on armhf
<lamont> \o/
<lamont> dist-upgrade with everything but http://ppa.launchpad.net/maas-maintainers/experimental3/ubuntu enabled, ran fine.  uncommented that one, and *splat*
<infinity> Erm.  Reboot worked okay except that my / is read-only now.  WTF, systemd.
<lamont>     SmartUnPack maas-region-controller-min:amd64 (replace version 2.0.0~alpha3+bzr4810-0ubuntu1 with Segmentation fault
<lamont> how appropriate
<infinity> Replace it with a SEGV indeed.
<infinity> juliank: Retried.
<juliank> infinity: thx
<lamont> http://paste.ubuntu.com/15514818/
<juliank> lamont: What's the apt-cache policy output for that?
<lamont> http://paste.ubuntu.com/15514824/ <-- almost pasted before you asked
<juliank> lamont: apt-cache showpkg would be good to have too
<lamont> http://paste.ubuntu.com/15514844/ <-- showpkg juliank
<infinity> That's show, not showpkg.
<lamont> -kohlrabi(root) 381 : apt-cache showpkg maas-region-controller-min > zz
<lamont> might be, but iz showpkg.
<juliank> infinity: BTW: The failed test tries to detect that progress reporting works (start at 0, pulses somewhere in the middle, and stops at 100). It tests a 800k file download, at speed 1600/i where i is in [1..10]
<juliank> So it actually loads the 800 KB file at 160 KB/s
<infinity> lamont: showpkg looks more like http://paste.ubuntu.com/15514856/
<lamont> oh haha
<lamont> http://paste.ubuntu.com/15514869/ <-- actually different and correct this time
<juliank> But if it crashes after the "replaces ... with" part, it's actually worse than I though
<juliank> Well, it makes sense, though
<juliank> maybe it's a regression from bug #1550741
<ubottu> bug 1550741 in kmod (Ubuntu) "Upgrade failed - unauthenticated package (module-init-tools)" [Critical,Fix released] https://launchpad.net/bugs/1550741
<juliank> hmm, typo
<juliank> That is: The problem now appears to be that the cache has an invalid version selected for installation.
<juliank> Which might be a regression from http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=0390edd5452b081f8efcf412f96d535a1d959457
<lamont> \o/
<lamont> juliank: and reproduced on another machine!
<lamont> juliank: point me at an ssh key for you?
<juliank> Second or third one of https://launchpad.net/~juliank/+sshkeys
<lamont> http://paste.ubuntu.com/15514948/
<lamont> | fa1b75a1-152b-4479-a80e-9b8edaea6caa | ubuntu-released/ubuntu-xenial-16.04-beta1-amd64-server-20160223.1-disk1.img  | ACTIVE |                                      |
<juliank> hmm, where do I get that nova tool?
<lamont> juliank: see also /query
<lamont> that
<lamont> s python-novaclient
<infinity> Oh, you can't be serious.
<infinity> lamont: Okay, one glaring effin' regression from upstart/mountall->systemd that I can't believe I'm the first to run into.
<lamont> oh?
<lamont> do I even want to know?
<infinity> lamont: It fails to remount / rw if there's no (OTHERWISE COMPLETELY POINTLESS) entry for / in fstab.
<lamont> lol
<lamont> how's that readnoly thing going?
<infinity> Well, fine now that I added an fstab entry. :P
<infinity> Stupid bug is stupid.
<infinity> And completely counter to the "empty /etc" goal, so I have no idea WTF.
<lamont> infinity: you know what's hilarious?  "Myspace for dummies", published 2008
<karstensrage> infinity, do you pull from unstable or just testing? for xenial?
<lamont> juliank: amuslingly? apt-get install maas fix0rs everything
<infinity> karstensrage: Unstable.
<karstensrage> sweet
<karstensrage> its up there
<infinity> karstensrage: Does "it" have a name?
<lamont> note also that the automatic pulling from unstable stopped for xenial a while ago
<karstensrage> one sec
<infinity> lamont: Yeah, he's trying to get something NEW in.
<infinity> lamont: Which would be easier with a package name.
<infinity> *hint, hint*
<lamont> heh
<lamont> infinity: what, can't you just do a for loop checking for new packages? :p
 * lamont has lost faith
<infinity> lamont: We effectively do just that when autosyncing, but not past DIF.
<karstensrage> https://packages.debian.org/unstable/libpam-ufpidentity
<infinity> karstensrage: FWIW, source packages are the real interest, so https://packages.qa.debian.org/libpam-ufpidentity would be the more relevant URL for such requests (happens that binary and source match this time, though).
<infinity> karstensrage: And synced.
<karstensrage> thank you so much
<infinity> karstensrage: And https://launchpad.net/ubuntu/+source/libpam-ufpidentity to follow along at home.
 * lamont wanders off for a bit
<infinity> "Bash script for wrapping cron jobs to prevent excess email sendin" ... Because that extra 'g' would have been too much.
<Unit193> Hah. :D
<Unit193> Thanks for reviewing cronic!
<infinity> Unit193: "Review" is a strong word for what I do with direct Debian syncs.
<Unit193> Still, thanks.
<infinity> But now all I can think of is some redneck worryin' about too much email sendin' on his dialup.
<Unit193> Ahaha. :D
 * Unit193 is from Ohio, but city parts!
<juliank> lamont: infinity: Issue caused by the commit I linked.
<juliank> So: Yay, it's mvo's fault!
<infinity> juliank: Man, that mvo guy sure is a jerk.
<infinity> Oh, wait, no.  The other thing.
<lamont> ohio has  city parts?
<infinity> lamont: Cleveland?
<lamont> I guess so
<infinity> lamont: Population of 400k.  Doesn't qualify as a "city" to me, but it does to most people. :P
<lamont> infinity: for you, it's not a city until it's big enough to have an underbelly?
<Unit193> Welp, I don't know what I live in then, it certainly isn't a 'city' though if CLE isn't. >_>
<infinity> On, and Columbus is 800k.
<infinity> That's approaching a real city.
<lamont> Unit193: tbf, the post office serving my house is for a town that might be 4500 now, and the next closest town has about a 150k population
<juliank> maas-region-controller-min:amd64 Depends on maas-common [ amd64 ] < 2.0.0~alpha3+bzr4810-0ubuntu1 -> 2.0.0~alpha4+bzr4843-0ubuntu1~xenial2 > ( net ) (= 2.0.0~alpha4+bzr4837-0ubuntu1~xenial1) can't be satisfied!
<infinity> lamont: But you no longer get your Internet via Pringles can, so you're moving up in the world.
<Unit193> lamont: ...The metro area has 124,475. >_>
<lamont> infinity: but I hate paying for my T1
<lamont> which, tbf, is about 1/7 the bandwidth of the radio that's still on the tower, just not used by me
<infinity> lamont: I thought you finally got cheap residential cable out there?
<lamont> hahaha
<lamont> cable comes to about 2 miles away
<infinity> Oh. :P
<infinity> 2 miles is pretty close!
<lamont> the DSLAM is 17000 feet -- tariff is 15000... and "T1" is a total misnomer for a pair of bonded hdsl lines
<lamont> and that is why I have an office in town
<infinity> Oh, it's not actual ISDN/T1 old skool tech?  Just DSL sold at T1 speeds?
<lamont> I could have DSL if the firestation were 1/2 mile closer
<lamont> not entirely sure... "4-wire T1"
<lamont> but I'm given to understand that it's hdsl pretending to be a T1... 2-pair to the house, and then magically 1-pair to get to the terminus in the computer room
<lamont> http://goo.gl/BTcjCE <-- infinity
<lamont> that's the box in the comp room
<lamont> the next step down was 128kbps ISDN for about 2/3 the price of the T1
<lamont> amusingly, it's not uncommon for me to see 180KB/s from the T1
<infinity> That sounds like real old skool analog tdm T1.
<lamont> yeah - it's more the 2-pair from the ped to the demark that leads me to believe it's playing games
<infinity> But maybe their magic ... Yeah.
<juliank> Almost fixed
<infinity> lamont: It must be weird living in the past.
<lamont> totally
<infinity> lamont: Did you have to brush up on WTF Frame Relay is? :P
<lamont> also, screw you. :p
<lamont> I don't think they're actually using frame relay, either.
<infinity> Well, Frame or ATM would seem like the protocols of choice.
<infinity> Perhaps with a PPPo in front of it if they hate their customers.
<lamont> the funniest part?  they deliver me 3 voice circuits from that adtran, which then go into a telephony card
<lamont> BECAUSE THE ISP DOESN'T DO VOIP
<lamont> oh, the actual service for me:  their adtran is configured on a 1918 network talking to my router and passing me a /29 (and sometimes, even their tier 2 is most confused how that even works)
<lamont> so from my perspective, it's just "ip route default via 192.168...."
<lamont> and, of course, they advertise my /24 from the swamp for me, at no additional charge
<lamont> anyrate, afk
<infinity> juliank: Are you going to tag a 1.2.9 with this fix "soonish", or should I just yoink the commit for an ubuntu1?
<juliank> infinity: I'll do some more testing and upload this tomorrow I think
<infinity> juliank: WFM.
<infinity> juliank: I'm in no rush, lamont got unstuck, and I'm guessing it's a bit of a corner case.  Just want it in xenial sometime soonish.
<juliank> https://github.com/julian-klode/apt/commit/71f2ab088f8e077ba8375e87ee9bb595655f954a
<juliank> That should fix it
<juliank> I should also come up with a test case, though
<juliank> infinity: I'm not sure if removing maas-region-controller-min and installing maas-region-controller is the right choice, though, but it's what APT < 1.2.7 did and does not crash
<juliank> I see, maas-region-controller-min is not up to date enough
<juliank> (4837 and the rest 4843)
<juliank> Now I need to build a test case where one package needs to be removed to allow another package to be installed.
<juliank> Let's see if I can do that
<lamont> juliank: maas-region-controller-min got renamed to maas-region-api
<lamont> juliank: ^^
<juliank> Yeah, saw that.
<lamont> so before was maas-region-controller{,-min} and now is maas-region-{api,controller}
<juliank> It unfortunately works in a minimized example test case
<lamont> of course it does. :(
<lamont> SCIENCE!
<infinity> â nosferatu
<infinity>     State: running
<infinity>      Jobs: 0 queued
<infinity>    Failed: 0 units
<infinity> â leviathan
<infinity>     State: running
<infinity>      Jobs: 1783695312 queued
<infinity>    Failed: 1783695312 units
<infinity> I WONDER IF THAT MIGHT BE AN ENDIAN BUG.
<infinity> Ooo, even better on s390x.
<infinity> â z13-028
<infinity>     State: running
<infinity>      Jobs: 3804834690 queued
<infinity>    Failed: 3804834690 units
<infinity> SO MANY JOBS!
<infinity> xnox: ^-- Some lolz for you.  nosferatu = amd64, leviathan = powerpc, z13-028 = s390x.
<infinity> systemd, you never cease to amaze.
#ubuntu-devel 2016-03-27
<juliank> test works now (and fails in 1.2.8!)
<infinity> juliank: Always a good sign for a test.
 * infinity decides it's pizza and TV time.
<juliank> lamont: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=6df5632
<juliank> infinity: It was TV time for me, and then lamont returned with bug details. So it became bugfixing time :D
<juliank> Off to bed now, it's 1am...
 * juliank should write a tool to create minimal apt test cases ...
<juliank> lamont: infinity: Uploaded 1.2.9 to Debian, should be part of the next dinstall run in an hour.
<juliank> => can be synced in a few hours
<infinity> juliank: Is "aptget" in the testcase a typo, or a wrapper?
<juliank> infinity: A wrapper
<infinity> Check.
<juliank> infinity: apt-get still runs the host apt-get, and aptget the one in the build tree
<juliank> Oh really, the armhf test suite for 1.2.8 now failed in another test... :/
<juliank> We run those flaky tests 10 times, and they still fail :/
<juliank> Maybe we should run them in qemu to slow things down ...
<infinity> juliank: Meh, they'll magically all work in 1.2.9 for no good reason anyway.
<juliank> Let's hope so.
<juliank> It's almost always armhf and i386 failing
<infinity> Coincidentally, the only 32-bit arches in adt?
<juliank> Yeah. I suppose those are the slowest ones
<infinity> I didn't say slowest, just 32-bit.
<juliank> Yes, but I said
<infinity> The amd64 and i386 tests run on exactly the same hardware.
<juliank> hmm
<juliank> Somewhat surprising
<infinity> These same tests are run at build-time, right?
<juliank> No
<infinity> Ahh.  Kay.
<infinity> Cause I'd be even more confused if they did.
<juliank> At build-time we only run small unit tests
<juliank> CI systems (autopkgtest, travis) also run full integration test suite
<juliank> or actually, they only run the integration tests...
<juliank> Well, travis runs both
<juliank> I think the problem with the download progress testing is that curl does not really respect speed limits you tell it
<juliank> It starts fetching at full speed and then adjusts down to reach the requested speed
<juliank> which fails on localhost for 800KB files
<infinity> So you need bigger files?
<infinity> Or less curl.
<juliank> That might make sense
<juliank> Well, the https method uses curl
<infinity> Oh, right.
<infinity> Bigger files, then.
<juliank> Yes
<juliank> And the other failing test, I have no idea yet.
<juliank> It's supposed to test that fetching A, and B (which redirects to A) only cause one download of A
<juliank> It actually does, but the 103 Redirect message from the method to the main process is never shown
<juliank> It says " @ Queue: Action combined for http://localhost:35267/foo and http://localhost:35267/foo"
<infinity> Weren't you supposed to be sleeping? :)
<juliank> Yes, unfortunately, yes.
 * juliank should just grep for "@ Queue: Action combined for" instead of "103 Redirect", that would be more reliable
<juliank> I see what's going on
<juliank> GET /foo with "Range: bytes=64350-" cannot work on a 64350 byte fil
<juliank> Going to feed that bug to DonKult
<juliank> So this one might actually be a real bug
<juliank> I feel like I just lost one hour :/
<juliank> Hello summertime, I suppose :/
<lamont> juliank: thanks!
<karstensrage> infinity, cant thank you enough, works flawlessly on 16.04
<karstensrage> freaking brilliant
<karstensrage> very happy
<karstensrage> can someone help me with backports?
<fo0bar> to request a (universe) package be synced from debian after the import freeze, should I request an SRU?  I've only had to do this once before years ago, and seem to remember the process was SRU-like, but can't remember if it was an SRU specifically
<fo0bar> (package update, not new package)
<fo0bar> ah, found my previous request (from 2012).  looks like it's just a matter of "please sync" against the package, with an explanation of the rationale
<karstensrage> fo0bar, are you familiar with the rationale's for backports?
<karstensrage> for new stuff
<fo0bar> karstensrage: in general, or for my specific request?
<karstensrage> fo0bar, in general
<karstensrage> i have two new packages that got into xenial and id like them backported to trusty and precise
<fo0bar> karstensrage: ahh yes, I do happen to.  that is a Stable Release Update (SRU), and is explained at https://wiki.ubuntu.com/StableReleaseUpdates
<karstensrage> that doesnt seem like its for new packages?
<fo0bar> karstensrage: I believe the process is the same.  I'm not an Ubuntu developer, but I do know that once releases are finalized (and especially LTSes), SRU requests get more scrutiny than normal sync requests, so you'll need to read over and closely follow that doc
<karstensrage> hmm ok
<infinity> fo0bar: That's not an SRU he's asking for, it's a backport.
<infinity> https://wiki.ubuntu.com/UbuntuBackports
<infinity> Very different (goes to a different pocket, managed by different people, etc)
<infinity> karstensrage: The process is as laid out on the wiki page.  Expecting immediate response to backports bugs is probably your failing.  Be patient, once you've followed the right steps.
<infinity> fo0bar: What are you looking to get synced?
<fo0bar> infinity: ah sorry, my mistake
<fo0bar> infinity: https://bugs.launchpad.net/ubuntu/+source/2ping/+bug/1562455
<ubottu> Error: launchpad bug 2 not found
<infinity> ubottu: Your parser sucks.
<ubottu> infinity: I am only a bot, please don't think I'm intelligent :)
<fo0bar> haha
<fo0bar> 2ping used to be the first sorted package in the archive, before that damned 0ad came around
<infinity> fo0bar: Done.
<fo0bar> infinity: ta!
<infinity> fo0bar: Oh, if I'd seen who the upstream was, I might have not synced it.
<infinity> fo0bar: Can we trust that guy?
<fo0bar> that jerk
<fo0bar> 2ping protocol is about 99.5% binary data and lives happily (and safely) in bytearray() land, but that other .5% is optional text notice data, and of course that's the part I screwed up
<fo0bar> luckily when not in debug mode, all untrusted parsing is handled in a failsafe exception handler
<infinity> I should write a second implementation of the protocol called bigping.
<infinity> Full name, of course, Notorious P.I.N.G.
<fo0bar> haha
<karstensrage> infinity, i just want to make sure i have a properly worded rationale for the backport, i am anxious but not expecting an immediate response
<karstensrage> ive been looking over other rationales that i can find but i dont see any patterns
<karstensrage> i mean for golang backports the rationale i guess i obvious
<karstensrage> ... is obvious
<infinity> karstensrage: The only real rationale for a NEW package needs to be "this package doesn't exist in trusty, but I'd like to use it there".
<infinity> karstensrage: The backports pocket isn't particularly strict in what it accepts.
<karstensrage> ok that makes sense
<infinity> (Which is why we don't install it by default)
<karstensrage> oh sure, these packages dont even make sense as defaults
<karstensrage> for anything
<infinity> I meant we don't install anything from backports by default.  ie: if there's an upgraded version of something in backports, apt won't offer it to you unless you explicitly request it.
<infinity> With, say "apt-get install package/trusty-backports"
<karstensrage> hmm so like even if you already have the package installed it doesnt say an update is available?
<infinity> Exactly.
<infinity> Because we don't support backports.
<infinity> So auto-upgrading people to it would be irresponsible.
<karstensrage> oh but security updates are handled differently right?
<infinity> It's a use-at-your-own-risk service to people who prefer new shiny over well-supported.
<infinity> -security and -updates pockets are automatic.  -backports isn't.
<karstensrage> oh i see
<karstensrage> ah now i see
<karstensrage> ok that really is different than what i thought, let me re-read backports with this new context to see if i get something different
<infinity> karstensrage: Backports is almost certainly where your "I want my new package on old releases" request belongs.  It's not even remotely acceptable as an SRU.
<infinity> karstensrage: Alternately, you could just tell your users to use xenial if they want your package.  Your call.
<karstensrage> yeah i get that, but what happens if a security issue or bug is found, and then you want that backported as well?
<infinity> You just submit another backport request.
<karstensrage> but it wont show to be updated?
<infinity> So, the security fix lands in xenial-security, then you ask the backporty people to re-backport the xenial-security version to trusty-backports.
<karstensrage> since its -backport?
<infinity> Oh, once something is installed from -backports, you get updates from -backports.
<karstensrage> ah ok
<karstensrage> ok gotcha
<infinity> It's the initial install/upgrade to/from backports that has to be explicit.
<karstensrage> yes of course
<karstensrage> yes that makes sense
<karstensrage> alright thank you, ill re-read again in the morning, kind of bleary eyed, must get some sleep, good night
<infinity> 'Night.
<ginggs> infinity: was that you rebuilding fpc just now?
<juliank> infinity: I guess we're not that lucky with apt 1.2.9, the i386 autopkgtest failed the flaky progress detection twice :(  - either retry a third time (or how much more is needed) or ignore the issue (if possible). I'm currently testing a way to make the test less flaky, by using 16MB test files instead of 800KB ones
<juliank> cjwatson: Does openssh-server really need a strictly versioned dep on openssh-client? This can cause APT to switch architectures if the native arch is not available in the wanted version, but the other arch is (https://unix.stackexchange.com/questions/272416/why-installing-openssh-server-would-remove-openssh-client)
 * juliank has a fix for that on the APT side too, but not sure if he will roll it out
<juliank> APT fix: https://github.com/julian-klode/apt/compare/master...julian-klode:bugfix/cross-arch-candidate?expand=1
<mapreri> can somebody mark lp #1562114 as triaged/minor (or whatever severity launchpad offers for this)
<ubottu> Launchpad bug 1562114 in scribus (Ubuntu) "text box editor return always on the top when changing window" [Undecided,Confirmed] https://launchpad.net/bugs/1562114
<mitya57> mapreri, done
<mapreri> mitya57: ta :)
<infinity> ginggs: It was not me.
<infinity> juliank: Retried yet again.  The odds aren't playing out for us right now, though. :P
<juliank> infinity: Yeah, I have not seen that fail that often (3 runs until now, and all 3 failed the same flaky test) - hopefully this gets better when the test uses 16 MB files instead of 800 KB ones...
<juliank> I could also start at 1MB, and then double the size with every failure
<infinity> Heh.
<infinity> That's assuming upping the size really helps.
<infinity> If the problem is that you need a (vaguely) consistent throttled speed, could you throttle it from the server side instead?
<infinity> (not sure what you're using as your https server in the tests)
<juliank> It's a custom built server, so the answer is yes, we can throttle there.
<juliank> s/built/written/
<juliank> I tried adding usleep(100) between each 500  byte block, that made things less bad
<juliank> but larger file size produced less retries on my test system, so I suspect it's the same on i386
<juliank> It tries 16 MB files, starting with a limit of 16 MB/s and then throttling down, dividing by the number of the retry
<juliank> This actually seems to throttle, as a run at half speed takes 5 seconds instead of 3
<ginggs> infinity: no worries, i guess it was Logan wondering why his lazarus sync wouldn't build on powerpc. I've filed bug 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
<juliank> infinity: no luck :(
<juliank> infinity: Is it possible to just force accept it?
<infinity> juliank: It is, yeah.
<infinity> juliank: But I'm bored enough to retry a few dozen more times too.
<juliank> Such a waste of resources ...
<juliank> With the larger size coming in 1.2.10 I have not yet seen a single failure or even a retry
<infinity> juliank: That's promising.
<juliank> in my i386 chroot
<juliank> which failed quite easily before (1 of 5 tries I think)
<juliank> s/tries/runs/
<juliank> Now I have done 15 runs already
<juliank> every check passed
<infinity> juliank: Hey look, 5th time's the charm. :P
<juliank> <insert random exclamation here>!
 * juliank should really implement rate limiting on the server
<infinity> juliank: That's probably the only way tests like this won't be an arms race.
<infinity> juliank: I note that the 800k file was "testfile.big", which is hilarious.
<infinity> If 800k is "big", I think we found a time machine.
<juliank> I think with 800k, the bytes were already buffered in the kernel sometimes
<juliank> causing the whole issue of directly going from 0 to 100
<juliank> Actually, I'm not sure how much the method(s) request at once.
<juliank> But it's definitely less than 16 MB :D
<juliank> Our time out is 500ms
<juliank> That is, we print progress every 500 ms
<juliank> If two tests take 1.3 seconds or something like that as they used to do, that can't work
<juliank> Is it possible to lock down launchpad bugs?
<juliank> bug #1558331 is getting a bit out of control
<ubottu> bug 1558331 in apt (Ubuntu) "message "The repository is insufficiently signed by key (weak digest)" is poorly worded" [High,Fix released] https://launchpad.net/bugs/1558331
<cjwatson> juliank: There's some common functionality in both packages and I'd rather not have confusion due to "apt-get install openssh-server" not upgrading both.  Surely this isn't the only package with this pattern of dependencies?
<juliank> OK
 * juliank does not understand why users are so whiny about a very small minority of neglected repositories not working with a not-yet-released Ubuntu release...
<juliank> Especially Nvidia is terrifying: They only have MD5 checksums.
<ari-tczew> cjwatson: is there still actual problem with syncpackage?
<juliank> ari-tczew: (not cj, but: ) It at least imported apt fine, so it seems OK to me ...
<ari-tczew> juliank: I've already synced one package for me and it works as well. however, I did a sponsor sync and I guess there is something missed..
<Logan> ginggs: good deductive skills! :P
<Logan> that's exactly why I retried
<duobix> Hi there, is there a plan to support devices with 32bit uefi and 64bit cpus? (bay trail/cheap x86 tablets)
#ubuntu-devel 2017-03-20
<Phanes> hello
<Phanes> can i get an explanation of why we have /lib32 and /lib instead of, say, /lib -> /lib64 for 64bit systems and /lib -> /lib32 for 32bit systems and just use that symlink location
<sarnold> Phanes: hopefully useful https://wiki.debian.org/Multiarch
<Phanes> do you also have the build options and steps used in your initial cross-compiler environment for building ubuntu or did you literally just take debian and change stuff around
<sarnold> heh, good question. I wonder if launchpad has history from the early days or not
<pitti> xnox: sorry for the delay in reviewing https://github.com/systemd/systemd/pull/5545, last week was a bit crazy
<pitti> xnox: I promise to do a timely review/landing in the next (probably final) round :)
<cpaelzer> xnox: would you mind taking a look at sponsoring bug 1673491
<ubottu> bug 1673491 in libnl3 (Ubuntu) "[Zesty] libnl3 Segmentation fault in sriov environments" [Critical,New] https://launchpad.net/bugs/1673491
<cpaelzer> xnox: you were uploading the base version, and I prepped a fix in a bileto ppa (now already verified by reporter)
<happyaron> Saviq: would you mind to test the new zfs packages? it works for me locally
<Laney> bdmurray: SRU> because it's expected for things to be in proposed for SRUs for a long time
<Laney> bdmurray: I suppose you could make the delay configurable per release, but even then > 10 days is reasonably common
<freedwhayt> Why ubuntu-16.04.2-desktop-amd64.iso has /usr/share/initramfs-tools/hooks/klibc^i-t instead of "-"klibc? initramfs-tools-core_0.122ubuntu8.8_all.deb when extracted with "dpkg-deb -x" shows klibc file but when installed it becomes klibc^i-t.
<infinity> freedwhayt: See the klibc-utils preinst.
<infinity> freedwhayt: Or "dpkg -S /usr/share/initramfs-tools/hooks/klibc"
<freedwhayt> infinity: I did reinstall, I did rebuild package myself. Nothing helps.
<freedwhayt> I dont want to complain but initramfs-tools-core and klibc-utils both contain /usr/share/initramfs-tools/hooks/klibc.
<freedwhayt> diversion by klibc-utils from: /usr/share/initramfs-tools/hooks/klibc \n diversion by klibc-utils to: /usr/share/initramfs-tools/hooks/klibc^i-t should mean something I dont understand.
<cjwatson> Phanes: We don't have the full bootstrap history available, but in general we start new Ubuntu ports using the corresponding Debian port as a baseline since it's a whole lot less effort.  There have been a couple of exceptions when we've done a port in advance of Debian.  But in any case the bootstrapping process involves repeated rebuilds until we're confident that the path we took to get ...
<cjwatson> ... there doesn't matter.
<cjwatson> sarnold: The early days of the amd64 and i386 architectures (and powerpc for that matter) were before Launchpad existed in any case ...
<pitti> cjwatson: hey Colin, how are you?
<pitti> cjwatson: was it ever proposed to not enable ssh.service by default, but instead use ssh.socket and socket activation? This would avoid the need for that nasty /etc/network/if-up.d/openssh-server (which is a race condition and thus sometimes causes connection errors right after bringing up an interface)
<pitti> it also avoids a running openssh master as long as nobody uses it
<cjwatson> pitti: Hi.  There's a section in README.Debian about why I'm not doing that.
<pitti> cjwatson: ah, thanks!
<pitti> cjwatson: I suppose using IP_FREEBIND would be an even better solution to get rid of /etc/network/if-up.d/openssh-server
<cjwatson> Perhaps; I haven't tried.
<cjwatson> It would certainly be nice to ditch that hack.
<pitti> cjwatson: I can't actually reproduce the necessity of that hack
<pitti> I removed /etc/network/if-up.d/openssh-server, ifdown ens3, restart ssh.service, ifup ens3, and I can connect just fine
<cjwatson> https://bugzilla.mindrot.org/show_bug.cgi?id=2512
<ubottu> bugzilla.mindrot.org bug 2512 in sshd "Use IP_FREEBIND if available for sshd listening socket" [Enhancement,New]
<pitti> cjwatson: thanks for the heads-up!
<cjwatson> I would have to trawl back through bug history to work out what exactly prompted the hack
<pitti> I was mostly wondering as Fedora doesn't have such a hack, but doesn't enable sshd.socket by default either (probably for similar reasons); I'll do some git archaeology
<pitti> bug 103436
<ubottu> bug 103436 in openssh (Ubuntu) "sshd not reconfigured by /etc/network" [Wishlist,Fix released] https://launchpad.net/bugs/103436
<cjwatson> Our README.Debian links to a related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=963268
<ubottu> bugzilla.redhat.com bug 963268 in openssh "add socket activated sshd units to the package" [Unspecified,Closed: rawhide]
<pitti> hm, there is no reproducer or much justification in #103436, and it obviously works with most real-life use cases; I wonder if that only applies to some restricted ListenAddresses or AddressFamily or so
<tjaalton> systemd-resolve seems to be broken when using shortnames, at least of hosts on my local net with 192.168.1.1 as the dns server
<tjaalton> with fqdn it's fine
<tjaalton> but with a shortname it just says "no servers could be reached
<tjaalton> "
<sarnold> cjwatson: yeah, I figured that the early ubuntu days would predate launchpad, but I also figured the pioneers might have stuffed all the history into launchpad just to be thorough :)
<nacc> slangasek: is there a reason this would not be acceptable to you (for dep3changelog): http://paste.ubuntu.com/24216487/ ? it actually fails for the example on the dep3 page too (doesn't extract the bug info). It's not particularly clear on which 'header' is which in that example, admittedly, so i'm also happy to ask for clarification from the dep3 owner :)
<rbasak> slashd: so I've updated/announced to ubuntu-devel@ and ubuntu-news-team@, created and added you to ~ubuntu-sru-developers, adjusted various pages in the wiki and asked the TB to add the new ACL entry. I think that's everything I need to do. Hopefully it'll all work once the TB have made the change for us.
<slashd> rbasak, tks
<slashd> much appreciated
<slashd> rbasak, does this include nomination ? or it has to be done by the TB ? I don't seem to have the right to do it
<slashd> at the moment
<rbasak> Nomination might work once the TB have made the ACL change. I'm not sure though. Let's see.
<slashd> rbasak, sound good, tks again
<slangasek> nacc: only that I wouldn't be the one accepting it, I originally wrote the script but the devscripts maintainers own it now :)
<nacc> slangasek: right it just hasn't been changed since your original, and i'm not sure if the code is incorrect or the spec is :)
<nacc> slangasek: so just wanted to run it past you before i send to them
<slangasek> nacc: I was probably excessively strict because I didn't want to write a more complete parser, just one that did what I needed
<nacc> slangasek: ack
<nacc> cyphermox: i think my systemd-resolved (17.04) is quite unahppy, but i have no idea how to debug -- `nslookup ...` returns SERVFAIL, but if I do `nslookup ... 8.8.8.8` (or 192.168.1.1) it works. Seems to only be true for some domains, too
<cyphermox> nacc: are you connected to a VPN?
<sarnold> nacc: among my DNS pals dig is considered the One True Way to debug dns
<nacc> cyphermox: not currently
<nacc> sarnold: fair enough, `dig` reports the same :)
<sarnold> there we go :)
<cyphermox> right, dig would report the same thing
<nacc> http://paste.ubuntu.com/24216827/
<nacc> e.g. (my banking subpage refuses to load currently :)
<cyphermox> nacc: what you would want to do, I guess, is start /lib/systemd/systemd-resolved in a separate terminal, from the command-line, after stopping the service using systemctl, and then do systemd-resolve (whatever) again to get the logs
<nacc> cyphermox: thanks!
<cyphermox> also, it's possibly "just" that resolved isn't running
<jbicha> nacc: I had to reopen https://bugs.debian.org/773426
<ubottu> Debian bug 773426 in imagemagick "imagemagick: Imagemagick not run from menu in Mate" [Important,Open]
<cyphermox> file a bug, or pastebin the logs from systemd-resolved and I'll look
<nacc> cyphermox: thanks again!
<nacc> jbicha: :(
<nacc> cyphermox: looks to be a dnssec issue? http://paste.ubuntu.com/24216847/
<cyphermox> err
<cyphermox> is that the whole thing?
<nacc> cyphermox: yeah
<cyphermox> this is ridiculous
<cyphermox> ok, I was missing setting SYSTEMD_LOG_LEVEL=debug
<cyphermox> can you do this again just so I make sure I'm getting the same behavior here?
<nacc> cyphermox: run systemd-resolve again?
<cyphermox> systemd-resolved
<cyphermox> but start it as so:
<cyphermox> sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved
<nacc> cyphermox: ah ok
<cyphermox> then do systemd-resolve www.perdu.com for instance.
<cyphermox> and if you do it again it should probably get it right the second time
<cyphermox> ie. dig banking.firsttechfed.com twice, the first would SERVFAIL, but the second should succeed, immediately after restarting systemd-resolved
<nacc> cyphermox: http://paste.ubuntu.com/24216896/ that is a dig on www.perdu.com then banking.firsttechfed.com
<nacc> cyphermox: let me try it with twice in a row
<nacc> cyphermox: i consistently get SERVFAIL
<cyphermox> ok
<cyphermox> for now, to unblock you let's modify /etc/systemd/resolved.conf to set DNSSEC=no and restart systemd-resolved
<nacc> cyphermox: i should say the above log was `systemd-resolve www.perdu.com` not `dig`
<cyphermox> it shouldn't matter
<cyphermox> systemd-resolve just always asks resolved
<nacc> cyphermox: yep, understood
<nacc> cyphermox: and DNSSEC=no does work
<nacc> cyphermox: i'm happy to just chalk this up to some configuration issue on my end (or with my ISP even) -- but if there's anything i can do to help debug (now or later), let me know!
<cyphermox> I don't think it's an issue with your configuration, probably more a problem that is caused by your router supporting DNSSEC, but something else on the path not supporting it
<nacc> cyphermox: ah is ee
<cyphermox> or you know, the other way around, possibly your router can't do DNSSEC, and the logic to downgrade to not care is broken
<cyphermox> nacc: I suppose that only started breaking today?
<nacc> cyphermox: i'm not 100% sure. I think I saw the same last week and just ignored it (as sometimes my bank has periodic website outages and it wasn't urgent)
<nacc> cyphermox: i only noticed more clearly today because they didn't state there was an outage :)
<cyphermox> I'm wondering if it's not that say, they screwed up their DNSSEC?
<nacc> cyphermox: i wonder too -- i guess i need to try and find another address that has the problem ;)
<cyphermox> looks like your provider is missing a DS record
<cyphermox> maybe try cloudflare.com?
<nacc> cyphermox: which provider do you mean? is it an ISP issue?
<cyphermox> nacc: no, I think this is a site owner issue.
<nacc> cyphermox: oh i see -- i can probably ping their ownership, they are pretty responsive
<nacc> gaughen: --^ you have the same bank, right?
<cyphermox> compare with cloudflare.com, I'd venture that works correctly if you re-enable DNSSEC.
<nacc> gaughen: first tech, that is :)
<nacc> cyphermox: alright, i will look into it, thanks!
<cyphermox> moar coffee.
 * gaughen looks up
<infinity> jdstrand: FWIW, "rm_conffile won't remove the conffile if it's modified" is only sort of true.  It will rename it to $name.dpkg-bak in that case.
<infinity> jdstrand: And if apparmor is loading *.dpkg-* namespaced files, the bug is in apparmor (please tell me it doesn't).
<jdstrand> infinity: it doesn't, and I forgot about the -bak bit. it's been a while since I rm_conffiled
<infinity> jdstrand: Ditto for typical editor backup extensions, etc.  This is why most people eventually settle on a whitelist of acceptable filenames instead of blacklisting.
<infinity> jdstrand: Anyhow, I stand by my comment in the other PR that an upgrade strategy that assumes we don't know how to use our tools is probably not reasonable. :P
<jdstrand> no, that isn't reasonable
<jdstrand> I just checked the apparmor sources and we won't ever load .dpkg-bak (or -new, -old or -dist), as well as various other extensions
<infinity> jdstrand: All that aside, thanks for the enlightening interjection that profile path and the file it's referencing don't need to match.  If someone had pointed that out last week, this SRU would probably be released by now. :/
<jdstrand> np. I only just saw it today cause I was on holiday last week
<nacc> teward: fyi, LP: #1673056
<ubottu> Launchpad bug 1673056 in nginx (Ubuntu) "Upgraded nginx-upload-progress module has showstopper" [Undecided,New] https://launchpad.net/bugs/1673056
<nacc> jgrimm: should LP: #1634989 be fix-released?
<ubottu> Launchpad bug 1634989 in rabbitmq-server (Ubuntu) "Segfault on rabbitmq-server start" [Medium,Triaged] https://launchpad.net/bugs/1634989
<jgrimm> nacc, yep i just commented as much
<nacc> jgrimm: ok, could be i hadn't refreshed yet -- do you have perms to change it or want me to?
<jgrimm> nacc, worked! thanks sir
<nacc> jgrimm: awesome, np -- was just checking up :)
<nacc> dannf`: i wonder, have you tried rebuilding emacs25 25.1+1-2ubuntu2 in a arm64 env?
<dannf`> nacc: i don't know if i ever did
<nacc> dannf`: just wondering if that one still builds in arm64 with current zesty, or if it was a fluke
<dannf`> nacc: well, i've had trouble reproducing the failure even w/ the -proposed version
<nacc> dannf`: right, i recalled that, would just be another datapoint (but admittedly not necessarily that helpful)
<tyhicks> bah, my security updates for nvidia-graphics-drivers-375 landed in universe instead of restricted
<tyhicks> infinity: can you move those to the correct place?
<infinity> tyhicks: Did that literally just happen? rmadison hasn't caught up to reality yet.
<infinity> Ahh, indeed.
<tyhicks> infinity: yes - it just happened
<infinity> tyhicks: Fixed.  Err.  Crap.  I should have fixed it after the updates copies.
 * infinity fixes harder.
<tyhicks> thank you!
<infinity> tyhicks: Maybe fixed.  I'll check again when the archive settles.
<tyhicks> infinity: sounds good
<nacc> rbasak: for `usd clone`'s usage of fetch_remote, shouldn't lpusip not existing be fatal?
<nacc> rbasak: lpmep not existing is whatever, but i'm not sure we have a reasonable usecase for using usd without having an imported tree?
#ubuntu-devel 2017-03-21
* infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.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 precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<rbasak> nacc: agreed. Did I screw that up when refactoring?
<tjaalton> hrm, resolving local hostnames worked yesterday but today after a reboot I get SERVFAIL
<tjaalton> resolv.conf doesn't have "search foo" anymore
<sbeattie> tjaalton: what release?
<tjaalton> zesty
<sbeattie> ah okay
<tjaalton> restarting systemd-resolved makes it timeout instead
<tjaalton> "no servers could be reached"
<tjaalton> filed a bug
<jbicha> didrocks: thanks for helping review the UKUI packages, UKUI added a COPYING.LGPL to the control-center source
<jbicha> it's LGPL-3 but the code is LGPL-2+ or LGPL-2.1+ (or other licenses); is that fine or do they need to explicitly add a copy of the LGPL-2.1 instead?
<jbicha> https://github.com/ukui/ukui-control-center
<jbicha> https://github.com/ukui/debian-packages/blob/master/ukui-control-center/debian/copyright
<handsome_feng> hi, jbicha, sorry, i will update it now
<jbicha> handsome_feng: just a moment, I'm trying to find out what exactly needs to be done :)
<didrocks> jbicha: I would prefer LGPL2
<jbicha> didrocks: just LGPL2? not LGPL2.1?
<didrocks> yeah, 2.1
<didrocks> (just read it quickly ;))
<jbicha> handsome_feng: ok, yeah, just replace the LGPL3 with the LGPL2.1 then
<jbicha> handsome_feng: is switching to the org.mate.control-center schema intentional at https://github.com/ukui/ukui-control-center/commit/6e7769e9 ?
<jbicha> if so, you'll need to depend on mate-control-center-common
<jbicha> also, in the future could you not reuse your release tags? once you release a 1.0.1, you'll need to use a different version number if you want to change something
<handsome_feng> sorry, i got it and the I will check the schema right now
<handsome_feng> hi, jbicha, mate-settings-daemon depends the scheme, so we need to depends this, so we have added the dependence in control file. And we have updated the ukui-control-center and ukui-indicators.
<jbicha> ok, I see, thanks!
<hallyn> apw: so seriously, i thought that since a year or two ago, for sru's targeting $release-updates instead of $release-proposed was now ok, in fact perhaps preferred?
<Laney> hallyn: You're probably thinking of $release instead of $release-proposed
<Laney> The former is rewritten to the latter internally
<rbasak> hallyn: yeah I'd been meaning to reply to your mail but was out last week.
<rbasak> hallyn: usually people upload to just "$release". I'm not sure what would happen if I accepted something targetted to $release-updates directly and fear that it'll somehow go in without going through -proposed. To my knowledge, the only redirect that exists is $release -> $release-proposed, and that happens before the upload appears in the unapproved queue.
<hallyn> Ok.  and nothing wrong with $release-proposed still?
<rbasak> Whereas your uploads to $release-updates appears in the unapproved queue as the updates pocket.
<rbasak> Nothing wrong with $release-proposed mechanically, though I always felt it was ugly as it looks odd when it lands. I'd still accept it though.
<rbasak> Though I prefer consistency for ease of mentoring sponsors.
<rbasak> Uh, mentoring sponsorees.
<hallyn> ok, thx.  i'll stick with the old then, like the old man i am
<hallyn> now maybe yakkety isn't worth uploading anyway
<hallyn> meh, did it anyway.  now i'm still not sure what to do about t.
<hallyn> is it the case that trusty-backports is basically enabled everywhere?
<didrocks> jbicha: once you sponsored the new packages, mind poking me?
<jbicha> didrocks: I uploaded ukui-control-center now; peony is also part of UKUI; I assume Laney is sponsoring ukui-indicators unless he says otherwise
<didrocks> ok :)
<Laney> jbicha: I say otherwise
<jbicha> Laney: what was the reject message?
<didrocks> two things IIRC, same issue with COPYING.LGPL missing and as well some erronous file listing in debian/copyright
<jbicha> ok
<jbicha> didrocks: ukui-indicators uploadedâthat should be the last one for UKUI
<gQuigs> do I pretty much always want to run the update-maintainer script when I'm doing an SRU?  (It's one of those things I usually forget to do, and AFAICT even if it's not changed in the source file we still change it somehow - example: http://packages.ubuntu.com/xenial-updates/pcs )
<gQuigs> ^for a package from Debian... with a maintainer from Debian
<rbasak> gQuigs: yes
<rbasak> gQuigs: I think there is an exception in the case of Kubuntu maintained packages and perhaps some others.
<gQuigs> rbasak: good to know, thanks
<rbasak> Though it would be nice if update-maintainer and the other tooling were taught that.
<mardy> morphis: hi! Is bug 1658617 getting near the top of your todo list, or is it still far? If you don't have time to work on it, I could try to give it a shot
<ubottu> bug 1658617 in Ubuntu App Platform "webapps crashing - oxide being compiled with wrong libs?" [Undecided,New] https://launchpad.net/bugs/1658617
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.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 precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
<nacc> rbasak: looks like it is explicitly set to ignore_nonexistent=True in both cases (lpusip/lpmep)
<nacc> rbasak: i wonder if we can also rather than simply raise the CalledProcessError in the case of ignore_nonexistent=False, logging.exception('a useful message') and sys.exit(1)?
<rbasak> nacc: maybe create a custom exception?
<rbasak> I've created CLIError in the past.
<nacc> rbasak: yeah taht would be fine with me -- just thinking that the exception backtrace is not going to be that useful to end-users or us, as it's a potentially clear issue (probably a mis-typed srcpkg)
<rbasak> nacc: we can catch CLIError at the top level, print the string and exit the exit code only.
<rbasak> I don't know what others think of that method. I've used it in the past as it feels the cleanest (eg. with testing).
<nacc> rbasak: i think i'd be happy with that
<rbasak> assertRaises(CliError...) instead of having to mock out sys.exit, etc.
<nacc> rbasak: if you don't have time for it right now, i'd also be happy with ignore_nonexistent=True for lpusip and a bug filed for refactoring :)
<rbasak> nacc: created bug 1674740 for now. Sorry for the formatting. I need to figure out a better way to do that :-/
<ubottu> bug 1674740 in usd-importer ""usd clone" is not fatal when lpusip is empty" [Undecided,New] https://launchpad.net/bugs/1674740
<nacc> rbasak: totally fine, thanks
<nacc> cpaelzer: thanks for the effort on that vsftpd/pam-mysql bug. I am wondering if we should just SRU back 0.8 to 16.04 and 16.10? Given the lack of maintenance of the old version -- having 16.04 be on '0.7~RC1' that won't ever exist as 0.7?
<nacc> cpaelzer: iiuc, you did not see the issue with 0.8 on 16.04?
<cpaelzer> nacc: ack I did not see the issue on my 0.8 test
<cpaelzer> nacc: but the code was too different to identify a fix
<nacc> cpaelzer: ok, i'm tempted to suggest that is the right fix then -- it's at least maintained now at that version
<nacc> cpaelzer: and for an LTS taht seems at least somewhat important
<cpaelzer> nacc: backporting the real 0.8 over the non exitstin RC might be a good idea
<cpaelzer> nacc: We might make it an MRE then and get an ack of the release Team
<cpaelzer> not-so-minor, but still process wise like an MRE a bit
<nacc> cpaelzer: yeah
<nacc> smb: re: that bug, i got (just now) BUILD_EXCLUSIVE_KERNEL to work, but that means iscistarget-dkms (I think) will return an error for all newer hwe kernels if installed with them.
<nacc> smb: i couldn't get OBSOLETE_BY to do anything
<smb> nacc, ok. For quick summary the iscsitarget-dkms was an iscsitarget implementation from before the kernel had its own implementation (that existed at least since xenial)
<nacc> smb: agreed
<smb> nacc, but as you said it does not seem to be maintained any longer and broke around yakkety
<nacc> smb: and removed from teh archive in yakkety
<nacc> (and in debian)
<smb> ah ok
<nacc> smb: that's where i think the disconnect is (to me) removing it from yakkety should imply it doesn't dkms build on the hwe stacks that come from yakkety+
<nacc> smb: as there's no testing possible of it working at this point
<caribou> any archive admin in the room ? I've uploaded nfs-utils to Zesty on friday and I see no trace of it; should I just re-upload ?
<smb> nacc, right we have been ignoring the adt failures there
<nacc> smb: which i suppose is fine, but we should really fix the package (and have at least that one user having filed a bug on it now)
<smb> nacc, Yeah, not sure there is a good way to basically point them to "tgt" (which is the admin tools part that works against the in-kernel iscsi target=
<cjwatson> rbasak: sys.exit is implemented by raising an exception anyway ...
<nacc> smb: yep, that's what i've documented elsewhere (iirc)
<nacc> cjwatson: ah good to know :)
<cjwatson> (though for testability I would probably also prefer raising a dedicated exception)
<nacc> smb: i mean, in theory, we could put in a dummy package that replaces what we have now, if we're saying don't use it. But it does build (and seems to be used) on 16.04.0/1
<smb> nacc, true, so the complete move is only something that would be possible on an upgrade path to yakkety or next lts. For hwe kernels not sure
<nacc> smb: and well, for 16.10+, the move was deletion :) so probalby should be in the release notes (esp. in 18.04, i suppose)
<nacc> smb: not sure if that has been encountered before, was hoping kernel folks would know :)
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.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 precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<smb> nacc, Oh we basically told you (server) and asked whether you would have any idea of how commonly iscsitarget is still used. :-)
<smb> nacc, apparently at least "someone"
<caribou> cjwatson: sil2100: apw: is there a specific archive admin IRC room ?
<sil2100> caribou: not that I know of, usually pinging on #ubuntu-release is what we do
<apw> caribou: indeed ubuntu-release is best
<caribou> apw: yep, got my answer there, thanks!
<rbasak> cjwatson: good point, thanks.
<nacc> smb: heh
<nacc> smb: thanks for the update in the bug -- not sure how best to proceed from here? is there any precedent for this kind of issue in the past that you know of?
<nacc> slangasek: --^ maybe you have input, as well, as your RM'd the package in 16.10
<nacc> slangasek: iscsitarget-dkms and what to do with it on the 16.04.2 hwe kernel
<slangasek> nacc: what was my removal comment? :)
<nacc> slangasek: LP: #1613758 "iscsitarget no longer appears to be maintained."
<ubottu> Launchpad bug 1613758 in iscsitarget (Ubuntu Yakkety) "[RM] iscsitarget should be removed from Yakkety" [Undecided,Fix released] https://launchpad.net/bugs/1613758
<nacc> slangasek: fully agreed with
<nacc> slangasek: but the package wasn't fixed in 16.04, so it still builds there against the same kernel it didn't build against in 16.10
<nacc> slangasek: the only thing i could get to work was a 'BUILD_EXCLUSIVE' entry in dkms.conf -- but not sure that is a great solution, because it does lead to an 'Error' message from dkms (but is better than failing the build)
<slangasek> nacc: right, no opinion on any of this, really; everything I know about this package is just what's in the bug log
<nacc> slangasek: sure, but from a pseudo-policy perspective, what would you consider the right thing to do for hwe compatibility? I think clearly we shouldn't be building the dkms modules against newer kernels, but i'm not sure if it should be flagged as an error if a user tries (as it does build against the 16.04.0/1 kernel). But even in 16.04.0/1, I think we'd want to recommend not using it and using hte
<nacc> upstream module and tgt.
<rbasak> slangasek: would you mind taking a glance at bug 1672099 please? I'm not sure if this could be related or made moot by the systemd-resolved/dnsmasq stuff I think you're driving?
<ubottu> bug 1672099 in dnsmasq (Ubuntu) "DNS loop, >5,000 queries per second for minutes at a time" [Undecided,New] https://launchpad.net/bugs/1672099
<slangasek> nacc: I thought dkms had a facility for filtering by kernel version, which if straightforward would be non-controversial.  If Linux 4.4 also has a better upstream driver already and we think we should neuter the dkms package entirely in favor of this, that seems ok but requires more regression testing.  Or is there any reason we couldn't just leave the iscsitarget package as-is in 16.04, and users
<slangasek> use it if they want to and don't if they don't? it's in universe anyway
<nacc> slangasek: yeah, that's what (I think) BUILD_EXCLUSIVE_KERNEL would do. Agreed on the need for testing to ensure (and it's not a no-op migration, as src:iscsitarget itself has some tooling in iscsitarget (ietd, etc) which only works with the dkms module. We can leave the package as-is in 16.04, mark the bug as won't fix. But then there will be (are?) users who were on 16.04.0, installed
<nacc> iscistarget-dkms there and it worked fine, and have opted-in to 16.04.2 hwe and the dkms fails to build (and apport will ask to file a bug every time afaict)
<slangasek> rbasak: AFAIK dnsmasq is dropped out of the default DNS stack again in 17.04, so that shouldn't be happening?
<slangasek> certainly, resolved+networkd+resolvconf+dnsmasq might have bugs like this
<slangasek> but that's not the config we're supposed to be shipping
<slangasek> nacc: if it fails to build every time, maybe they eventually decide to remove the package? :)
<nacc> slangasek: right, I just wasn't sure if that was a desirable user experience in an LTS :)
<rbasak> slangasek: I'll note that in the bug. Thanks!
<slangasek> nacc: when all available options involve some risk of going badly, I tend to prefer this happening as a result of an explicit action the user has taken, rather than of us trying to be overly clever and compounding the problem
<slangasek> explicit action - installing iscsitarget-dkms (which they didn't need to) and then installing the hwe stack
<nacc> slangasek: i think (if i had to guess) end users are installing iscitarget-dkms because of the upgrade from 14.04 to 16.04 (but not usre)
<nacc> i could also update the release notes for 16.04 (I think) to indicate we don't recommend using the package on 16.04 and see if i can find a good guide on using tgt with the upstream driver
<slangasek> cyphermox: ^^ could you easily confirm what I said above about dnsmasq no longer being used by default in 17.04?  I think barry finished the re-revert on n-m
<cyphermox> do you mean the re-re-re-revert or just the re-re-revert?
<cyphermox> ;)
<cyphermox> I check, hold on :)
<nacc> slangasek: i think i agree in principle with your stance, just trying to translate it in my head to actionable items for the bug and for end-users to consume
<cyphermox> slangasek: nacc: yes right now we're using resolved AFAICT
<cyphermox> nacc: sorry, that was meant for rbasak
<rbasak> cyphermox: thanks
<cyphermox> in any case, it's potentially a real upgrade bug rather than an unsupported mix of features
<rbasak> Yeah could be
<slangasek> indeed
<cyphermox> I haven't checked, but I suppose it could be that either the extra file for dns=resolved isn't installed, or /etc/NetworkManager/NetworkManager.conf didn't get overridden correctly
<rbasak> cyphermox: feel free to take over the bug!
<rbasak> I was just triaging
<cyphermox> should be pretty easy to reproduce if it's the case, I'll try to run that on my X230 once I'm done with shim
<slangasek> cyphermox: AFAIK even in 16.10 we already have resolved running by default, but nothing hooks it into /etc/resolv.conf or resolvconf because NM+dnsmasq takes precedence.  So I don't see any practical way for dnsmasq and resolved to see each other
<cyphermox> this is 17.04 though
<cyphermox> I'm thinking this is a continually upgraded system that has kept some old config
<slangasek> I'm thinking it's a user who has manually installed the dnsmasq package in error
<cyphermox> oh, you have a point, this one is showing up as 127.0.0.1.
<nacc> slangasek: fwiw, http://paste.ubuntu.com/24223425/ seems to work, and emits a 'this kernel is marked as not supporting this driver' style message
<slangasek> cool
<hallyn>  /var/lib/AccountsService?  wtf ppl
<cyphermox> hallyn: ?
<hallyn> qemu but complaining that qemu user isn't made a system user - in that file
<hallyn> s/but/bug
<cyphermox> that's... interesting
<hallyn> lucky for me cpaelzer will handle it :)  where handle it probably means set it to wontfix
<cpaelzer> hallyn: yeah that is an ugly, but not evil bug
<cpaelzer> hallyn: I haven't read the history, but this is the one I dup all that to (and analyzed whats going on)
<cpaelzer> hallyn: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1667113
<ubottu> Launchpad bug 1667113 in netqmail (Ubuntu) "System users appears in Ligthdm and user switcher (Accountsservice has no filter for shell types)" [Undecided,Confirmed]
<hallyn> cpaelzer: yeah, right, thanks.  So yeah accountssservice (or anything using it) simply needs to recognize shadow's hints.  libvirt does 'adduser --system', so libvirt is good.
<hallyn> also the accountsservice web page says "may be replaced/subsumed by sssd at some point".  well that makes me want to spend time porting to accountsservice api doesn't it :)
<slangasek> rharper: do you think you could put together an SRU test case for LP: #1673860?
<ubottu> Launchpad bug 1673860 in systemd (Ubuntu Yakkety) "systemd-resolved unit should run Before=network-online.target" [Undecided,New] https://launchpad.net/bugs/1673860
<slangasek> rharper: (the yakkety upload is in the queue)
<rharper> slangasek: yes
<robru> Laney: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/320270 ok I think I addressed all your concerns, please rereview
<nacc> smb: does this look ok to you? http://paste.ubuntu.com/24224511/ (with a corrected version and a bug ref of course)
<nacc> smb: i just tested on 16.04.2 and manually installing linux-{image,headers}-generic led to a successful build for the 4.4 kernel and the 4.8 kernel gets skipped.
#ubuntu-devel 2017-03-22
<Caelum> Hi, does ubuntu have any support for building 32 bit binaries on 64 bit hosts via -m32 and such, or do you have to use chroot tools? It doesn't seem like it, I just tried e.g. apt install wxgtk3.0-dev:amd64 wxgtk3.0-dev:i386 # and got a bunch of conflicts
<sarnold> Caelum: if you want repeatable builds it's usually best to create a schroot for the i386 environment and set up sbuild to use that
<sarnold> Caelum: it ought to be possible to compile 32 bit withuot that step but it might not be as straightforward
<sarnold> Caelum: I'd expect you to be able to install both -dev packages for i386 and amd64 side-by-side but sometimes mistakes happen. If the version numbers are identical but you can't do it, file a bug; maybe it'll be addressed
<cjwatson> Caelum: as well as what sarnold said, basically using -m32 rather than a chroot is supported for a fairly minimal set of libraries but not for everything
<cjwatson> it's doable if you just need libc/libstdc++ and maybe a few other small and simple libraries; not so much for wxgtk, say
<Caelum> ok thanks, that's what I wanted to know
<Caelum> fwiw things are not that much better on other dists
<Caelum> on fedora the -devel libs do install side by side, but you have to figure out the 32 bit deps yourself, while on arch you can install the lib32 libs, but some you have to get from AUR
<smb> nacc, Sounds like the best approach that can be done. The diff looks good to my (not yet caffinated eye). With the bug reference people might look an find tgt mentioned.
<wgrant> seb128: We finally have zesty langpacks, after some silly postgres issues. They should be running regularly on Tuesdays now.
<wgrant> (and I did a manual run this morning, so a fresh full export exists)
<sil2100> seb128: hey! I poked Trevinho already about this and he pointed me to you - I'm looking for someone that's maintaining unity-settings-daemon
<sil2100> seb128: there's a merge on the sponsoring queue for a long long time that I'd like someone review/release - https://code.launchpad.net/~chrisccoulson/unity-settings-daemon/lp1542699/+merge/288952
<seb128> wgrant, thanks, I was going to ping about that again today since I didn't know if you saw my previous ones ;-)
<seb128> sil2100, we don't really have a maintainer for it, Trevinho should feel like he can approve changes ... anyway that one looks fine and I trust chrisc_coulson to know what he's doing
<seb128> so feel free to merge it
<sil2100> seb128: could you approve the merge? I might try to silo it up later on and drive it through Bileto finally
<seb128> sil2100, done
<sil2100> seb128: thanks!
<seb128> thank you for the ping
<freedwhayt> Where are kernel packages on Ubuntu Hybrid CD?
<sil2100> jbicha: hey! I wanted to release https://bileto.ubuntu.com/#/ticket/2447 (as I want to follow up with another u-s-d landing) but I see the merge is not approved yet
<sil2100> jbicha: I think Robert had some concerns with the MP
<sil2100> jbicha: could you take care of that so we could release this silo?
<philroche> Hi, would someone on the Ubuntu Sponsors team be able to help with a critical GCE bugfix please? LP:1668327 needs to be marked as critical and target Trusty, Xenial, Yakkety and Zesty. I have uploaded patches for Xenial, Yakkety and Zesty and was hoping I could land them all in -proposed today. Thanks https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1668327
<ubottu> Launchpad bug 1668327 in gce-compute-image-packages (Ubuntu) "Startup scripts get run when guest packages are updated" [Medium,Confirmed]
<philroche> Apologies I meant to post my request in #ubuntu-release
<mardy> morphis: hi! Should I clone libhybris from github of lp?
<morphis> mardy: take https://code.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/+ref/master
<morphis> but would be great if you can submit changes to both
<morphis> mardy: doesn't the fix I proposed work?
<mardy> morphis: actually, I just started working on it :-)
<morphis> ok
<mardy> morphis: or was the fix to be meant for the client code?
<morphis> it was meant for the client, yes
<Nitesh> Hello All, Anyway to figure out why I see the following inside a Ubuntu17.04 VM?  filesystem is turning into readonly due to some input output errors, why is it happening? https://paste.fedoraproject.org/paste/Gxod8BLm7Ewzyj1tP0pQr15M1UNdIGYhyRLivL9gydE=
<mardy> morphis: I'm still studying the situation, and yes, I believe that the issue is in oxide
<nacc> smb: true. I can even put that in the changelog
<nacc> bdmurray, juliank : fyi, c.u.c has been reconfigured
<nacc> bdmurray: so i'm going to close the bug and mark my MR as invalid
<jbicha> sil2100: I think you mostly just care about https://code.launchpad.net/~jbicha/unity-settings-daemon/fix-ftbfs/+merge/320665
<sil2100> jbicha: is this in some silo?
<sil2100> Ah, new merge
<sil2100> jbicha: can I use that one along with another merge I wanted to release?
<jbicha> yes, go ahead! :)
<sil2100> Since there was a very very very old u-s-d merge on the sponsoring queue that I'd like to get rid of by finally releasing it
<sil2100> Excellent :)
<sil2100> Thanks!
<jbicha> the other MP isn't that important, so we can let robert_ancell finish reviewing it
<jbicha> (let him finish reviewing my drop-updates-plugin MP)
<sil2100> Ok
<nacc> rbasak: iirc, you had pinged chrisccoulson on the firefox in z-p a few days ago? Is someone working on getting that working? or was that only for the SRU that you had pinged?
<nacc> ah intersteing, the failure to build on armhf and s390x also exists on yakkety and xenial
<nacc> so ... we have different version per architecture now? :)
<jbicha> s390x was broken for yakkety release too
<nacc> jbicha: ah ok :)
<nacc> jbicha: i guess maybe they are declared as being don't care; just makes the rmadison output rather confusing
<nacc> jbicha: and it's not great that 17.04 is behind 16.04 and 16.10...
<jbicha> yes, chris is well aware of the zesty issue
<nacc> jbicha: ok
<bdmurray> nacc: cool, thanks for doing that
<nacc> bdmurray: np, thanks for the patience
<chrisccoulson> nacc,  firefox/s390x is something that (AFAIK) nobody cares about
<nacc> chrisccoulson: ack, makes sense, was just reading through excuses. Seems like it should not be built there at all, maybe?
<chrisccoulson> firefox/armhf should be fixed but I don't block security updates for x86/x86-64 due to an armhf failure, given that nobody tests the updates there anyway
<rbasak> nacc: no it was just the regression-update bug I think.
<nacc> chrisccoulson: ah i see -- ok, i wasn't aware of that nuance, thanks!
<nacc> rbasak: ok
<chrisccoulson> And I have pretty much no time to debug what is probably going to be a wrong-code bug in the compiler anyway (the armhf build failure is actually a start crash which I reproduced in a local build and makes absolutely no sense)
<chrisccoulson> s/start/startup/
<nacc> chrisccoulson: right, so should armhf also just not be built if it's not really supported?
<nacc> chrisccoulson: i guess i don't fully understand what the long-term plan here is :)
<chrisccoulson> nacc, no, somebody needs to fix the armhf build failure
<chrisccoulson> Ideally the firefox maintainer that we don't have
<nacc> ah i see :)
<chrisccoulson> I'm just responsible for doing the security updates for firefox, and anything else is basically ricotz in his spare time
<wxl> chrisccoulson: while you're around, who do i speak to about the thunderbird ppas?
<wxl> (if anyone)
<nacc> chrisccoulson: ah ok, i see -- i didn't realize that (was just going off the upload changelog)
<ricotz> wxl, depends on which thunderbird ppa
<wxl> ricotz: well, i guess which one's the right one? XD
<wxl> ricotz: but i do mean https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+packages
<ricotz> wxl, either https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages for stable or https://launchpad.net/~mozillateam/+archive/ubuntu/thunderbird-next/+packages for beta/next-stable
<wxl> ricotz: so no luck on trunk, eh?
<ricotz> wxl, imo there is no point to tackle that ;)
<wxl> ricotz: well, i mean it hasn't build for trusty i386 since 38 or so.. :/
<ricotz> wxl, the last is 45.8.0, but you can look into thunderbird-next ppa
<ricotz> which has 52.0
<bdmurray> nacc: Did you look for any bugs about the issue? e.g. how it'd manifest in clients / tools
<wxl> ah good
<wxl> that wouldn't have fixed anything yesterday
<wxl> but it looks like we just had a successful build
<nacc> bdmurray: i hadn't yet -- i didn't find any obvious ones when i filed my own, but I will go look now
<bdmurray> nacc: What was the original issue again?
<nacc> bdmurray: `apt-get changelog qemu` would fail because qemu is in universe, but src:qemu is in main
<bdmurray> nacc: maybe bug 139791?
<ubottu> bug 139791 in aptitude (Ubuntu) "aptitude changelogs 404 when the source is in a different component to the binary package" [Medium,Triaged] https://launchpad.net/bugs/139791
<nacc> bdmurray: ah i had also only trawled src:apt so far
<nacc> bdmurray: although that bug is probably fixed by the change, the testcase given is also no longer valid (src:kdepim is in universe since at least trusty)
<nacc> bdmurray: ok, so on precise, that bug is still present, but i *think* for a different reason
<bdmurray> nacc: Ah, okay.
<nacc> bdmurray: debugging it still -- i think that one is an issue with kdepim having moved from main to universe (so there's no pool/main/k/kdepim at all)
<nacc> bdmurray: actaully, i'm rather confused, i don't see any kdepim 4:4.8.5-0ubuntu0.1 changelogs on c.u.c ? and so the redirects still 404 since there is nothing to redirect to
<nacc> bdmurray: maybe we don't care about precise, but i do wonder if extract-changelogs is missing some historical changelogs?
<bdmurray> nacc: its possible there was a hardware failure a couple of years ago, I thought everything should have been regenerated though
<bdmurray> nacc: its possible.
<nacc> bdmurray: if i had to guess, those are the kind of bugs that are now fixed, i agree (component differences between src and binary pacakges)
<slangasek> pitti: hey, so it appears systemd upstream test has regressed on the autopkgtest infrastructure sometime after the 10th, we now consistently get timeouts... does this issue look familiar to you?
<slangasek> Laney: and do you know of any changes to autopkgtest infrastructure around the 10th that could be contributing? ^^
<sinzui> rbasak: who do I talk to about bug 1669507
<ubottu> bug 1669507 in juju-core (Ubuntu) "Remove juju-core from zesty" [Undecided,New] https://launchpad.net/bugs/1669507
<Laney> slangasek: nope
<slangasek> ok
<Laney> Did someone try locally?
<slangasek> I have not
<Laney> the last message before the timeout looks kind of bad :)
<rbasak> sinzui: release team to approve an FFe, and someone from ~ubuntu-archive to do the removal.
<rbasak> sinzui: I'm not aware of any deb to snap transition mechanism.
<rbasak> Perhaps a question for ubuntu-devel@
<sinzui> rbasak: me neither, but If we can create a transitional deb for the snap, that would be grant
<sinzui> grand
<sarnold> nacc: heya, a user reported that the 'ubuntu changelog' links from e.g. http://packages.ubuntu.com/precise/abiword give 404s now -- is this the changelogs cleanup?
<infinity> sinzui: There isn't a formal deb->snap upgrade mechanism that I'm aware of, which would make, IMO, dropping the deb somewhat premature and irresponsible.
<sinzui> infinity: :/ Is it wrong for a deb's install hook to "snap install juju --classic"? What more would teh deb need to do?
<infinity> sinzui: We don't really have a defined right or wrong there, as I don't think we've ever discussed it from an OS architecture perspective.  Calling a package manager from a package manager is certainly unexpected, but it would "work".  Is there user data that would need migration, or would it Just Work?
<sinzui> infinity: indeed the JUJU_DATA dir remains a conern for me.
<infinity> There also seems to no longer be a manpage.
<sinzui> infinity: thats tragic since the most common reason for test build to fail is the man page didn't generate. We treat the man page as a first-class requirement in testing
<infinity> Can't tell if sarcasm. :P
<infinity> But yeah, not sure if that's your fault or snappy's or snapcraft, I'm not sure how manpages are (or aren't) handled in the snap world.
<sinzui> infinity: it is not sarcasm :) I really do scream when the man page breaks in tests
<sinzui> infinity: I suppose it will be my fault soon. I am taking over juju packaging again for a while
<sarnold> infinity: comment #4 is good https://bugs.launchpad.net/snapd/+bug/1575593
<ubottu> Launchpad bug 1575593 in snapd "Snappy installed manpages aren't accessible through man" [Low,Triaged]
<infinity> Given there's no snappyish paths on the default manpath, I'd suspect that even if you did ship a manpage (which I don't see in your snap), we wouldn't see it.
<infinity> sarnold: I assume that bug says what I just discovered.
<sarnold> infinity: sortof. try fixing your PATH to include the new magic snappy things.
<infinity> sarnold: There are no magic snappy man paths.  That's why the bug is still open.
<infinity> (As in, /snap/man needs to mirror the layout of /snap/bin)
<infinity> Anyhow, the juju snap ALSO doesn't ship a manpage, so even if the snapd bug were fixed, there'd be no manpage. :)
<sarnold> heh :)
<infinity> sinzui: Anyhow, I think from your POV, you want to try to minimize behavioural regressions and have a plan for data migration.  (Mark did some deb->snap migration of something a while back, etcd maybe?  You could look and see if that was crazy overengineered, or perhaps suitable)
<sinzui> thank you infinity
<infinity> sinzui: And then we need the large discussion of "is it sane for a deb to 'depend' on a snap, should there be a formal hooks process for this to happen, or ad-hoc postinst scripts, blah blah".
<infinity> s/large/larger/
<sarnold> if there's room for discussion here I think I'd rather see something common that indicates which debs ceased to exist and snap replacement names, to avoid having every postinst from trying to do this. I could imagine a lot of folks wanting to concentrate snaps on perhaps different machines than the ones that used to host things on debs, and not enjoying "hey we installed snapd and this snap" in the postinst of half-dozen packages..
<sarnold> juju especially feels like a thing that someone would Care About doing themselves. I'd expect less magic there the better.
<infinity> sarnold: I'm not wasting too much brain on it today, but there are several different scenarios and potential solutions to consider.
<infinity> sarnold: While the one that's critical to get right (lossless migration when a deb "goes away") is applicable to the above, there's also the question of what to do about the system inevitably becoming more hybrid, and would it be sane to allow deb->snap dependencies, and what would that look like.
<infinity> sarnold: Until now, I'd assumed (and hoped) we'd keep the deb world 100% self-contained, and snaps would be an opt-in, but it's pretty clear that some people would like to drop their deb offering entirely, and if one of those people happens to be a dep of someone else...
<infinity> Web browsers are a perfect example here.  Dozens of things will suggest or recommend a browser for good reasons, and users shouldn't be forced to have two installed when one would suffice.
<pitti> slangasek: hm, no, doesn't look familiar; upstream CI runs on xenial (doesn't happen there); a few weeks ago we had a qemu crash in that test because qemu didn't get along with something in the new kernel; but I don't see a qemu crash in the log this time
<sarnold> hey pitti :)
<sarnold> infinity: hrm. all good points. :/
<infinity> sarnold: And then that just digs deeper into another rabbit hole where, if one were to upstream the concept of extra-system deps to dpkg and rpm, would we have a syntax of system:package for each extra-system system (snap, flatpak, etc, gross), or some generic app:firefox or role:webbrowser type syntax that could be satisfied with a backend priority-based switch that would divine what you probably want based on preferring snaps over flatpaks and ...
<infinity> ... mozilla products over google and red over blue?
<infinity> sarnold: So, yeah.  It quickly becomes a bit "whee".  But the migration thing is obviously the more urgent to examine.
<infinity> Maybe we can borrow some Netflix code here for the preference guessing.  "We suspect you want a small indy web browser, published by a German distributor, featuring a strong female mascot, only allowing plugins on Tuesdays."
<sarnold> genau das! bitte bitte :D
<jbicha> yes but will it let me print on Tuesdays?
<sarnold> lol
<infinity> jbicha: Arguably our best bug ever.
<infinity> jbicha: Crashing X with 11 fingers on the touchpad was also solid.
<infinity> Oh, and the Microsoft keyboard being detected as a Joystick with 37 axes and 57 buttons.
<sarnold> hehehe
<nacc> sarnold: sorry, i don't *think* so
<sarnold> there's of course the chance that the link from there' salways been busted :) it's not like packages.ubuntu.com is a core service.. but it's awesome when you're reading things on you rphone..
<nacc> sarnold: yeah -- i will need to talk to IS to figure out
<sarnold> nacc: thanks
<nacc> http://changelogs.ubuntu.com/changelogs/pool/universe/a/abiword/
<nacc> sarnold: i don't see any 2.9.2
<nacc> bdmurray: --^ this makes me think precise changelogs are just broken somehow
<nacc> sarnold: it's the second precise package i have failed to find chagnelogs for
<sarnold> iiiinteresting
<bdmurray> I commented on the bug about how the trusty release pocket version of abiword is missing too
<bdmurray> so I don't think its exclusive to precise
<nacc> bdmurray: thanks -- i hadn't seen that yet
<nacc> bdmurray: interesting, so something else is going on (it feels like). I can ask IS to disable the changes and see if they come back, but we aren't changing anything on the fs itself, so it seems unlikely
<bdmurray> If I had to guess I'd say it was populated with a date argument that didn't go far enough back in time
<nacc> bdmurray: yeah, i could see that
<bdmurray> I'll look for the server fail RT
<nacc> powersj: i think i see what is happening
<nacc> powersj: if i had to guess, 2.16.12* was in yakkety-proposed
<nacc> powersj: but never made it into release and so got copied forward to zesty-proposed
<nacc> powersj: but we only know what actually happens
<nacc> *what actually publishes
<nacc> and the order in which they publish
<nacc> https://launchpad.net/ubuntu/+source/mongodb/+publishinghistory
<nacc> powersj: --^ yep
<nacc> ah *this* is why deleted matters over superseded :)
<nacc> rbasak: --^
<nacc> powersj: in any case, it's not technically wrong, that did occur in yakkety development before yakkety closed
<nacc> powersj: just never migrated -- so you would manually need to find the release pocket branch
<nacc> powersj: well 'manually' lpusip/ubuntu/yakkety should do
<bdmurray> nacc: Its RT 89921 but its not clear to me how the back population was done.
<bdmurray> nacc: the first log entries are from 2016-04-26 which seems like after the backfill would have been done.
<nacc> bdmurray: thanks, looking it up
<nacc> "  - Tried pushing that start date back in time but that just caused
<nacc> timeouts/OOPS from LP"
<nacc> bdmurray: yeah, for instance, the missing precise changelog was from a package published on 2012-05-01 :)
<nacc> so I'm guessing we're missing a lot of precise changelogs
<nacc> we could relatively easily ensure a changelog exists for every publish in the active series
<nacc> or some subset of them
<nacc> e.g., trusty, xenial, yakkety, zesty
<nacc> iterating over every source package, checking if it exists and extracting it if not?
<nacc> powersj: approving your tasks
<rbasak> nacc: I guess we need to pick up deletions to move the devel pointers back in that case?
<rbasak> (I'd use an additional merge -s ours commit)
<nacc> rbasak: yeah, but i'm not sure how we'd know
<nacc> rbasak: that would require going back in time on each new series creation?
<nacc> rbasak: which is fine, just an algorithmic change of some significance
<nacc> rbasak: right now, we assume we only ever need to visit a publish once
<rbasak> Order publishes and deletes together in time
<rbasak> Then when you see a delete, recalculate what was visible at that time, and if it's different from the tip, add a commit.
<rbasak> Though "recalclate what was visible" might need looking back perhaps?
<rbasak> Though I imagined one could determine that by looking at the "pocket" branch pointers.
 * rbasak will think about it
<nacc> well, i think we could do this (maybe) -- deletes only are relevant here when they were deleted for copy-forwards
<rbasak> I'm not sure that's true, but it's late here so I'll leave thinking about it for another time :)
<nacc> rbasak: for this particular issue, i mean (where -devel is past where it should be)
<nacc> rbasak: there migth be other cases where deletes are relevant, but we've not really hit them yet :)
<nacc> rbasak: ack, didn't think you'd respond in any case :)
<nacc> bdmurray: if you want me to code something up, let me know (or i can put something in that other ticket)
<bdmurray> nacc: If you're interested feel free. I think a new RT would be appropriate though.
<nacc> bdmurray: ok, i may see if i can spin something up -- and will file a RT tmrw
<piem> howdy. i'm trying to find out why aubio is not being updated to the latest version from debian. it's been there in 'proposed' for a few weeks now
<slangasek> pitti: right, in this case there's no qemu crash logged and we see the console output up to a getty
<sarnold> piem: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#aubio reports "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"  -- i'm a bit surprised, 114 days feels surprising here..
<piem> sarnold: i guess i should head to that channel then. thanks
<slangasek> that says why it's /currently/ not migrating
<slangasek> previously, it could have been not migrating because its reverse-deps are not in a consistent and migratable state
<sarnold> ahh
#ubuntu-devel 2017-03-23
<seb128> mardy, hey, did you see https://errors.ubuntu.com/problem/c3cf712b54fe02d52c758702cb8176ea0cbcc916 ? seems a new signon-ui error in zesty and quite high on the e.u.c reports
<seb128> mardy, https://errors.ubuntu.com/problem/0fdd752751a7b257fd4c7adaa057bd536ff767ce as well
<mardy> seb128: hi! Yes, it's https://bileto.ubuntu.com/#/ticket/2608
<seb128> mardy, great, thanks!
<fossfreedom_> jbicha: re UG Try/Installl decorations missing - we had a similar issue http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6517
<fossfreedom_> I think the key part was the addition of the X11 environment variable on line 508
<LocutusOfBorg> camako, can you please make boost1.62 available for mir?
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html
<LocutusOfBorg> it has some hard-coded runtime deps I guess, I think you just need to bump them :)
<mapreri> /cc alan_g â
<mapreri> (mostly solved between #ubuntu-mir and #ubuntu-release anyway)
<jbicha> fossfreedom_: thanks, do you happen to know how I could test whether that fixes my bug?
<fossfreedom_> jbicha: not easily - I had to build an ISO using our ISO builder - had to hack the Try/Install screen to launch a terminal session to then allow me to experiment.  There must be an easier way to debug changes to ubiquity - I'm not aware of how though :(
<jbicha> I'll ask on #ubuntu-installer
<jbicha> maybe I'd have to make a persistent live USB?
<fossfreedom_> possibly - that is an area I had not tried. we'll worth having a go
<jbicha> fossfreedom_: your fix worked, see my update on LP: #1675210
<ubottu> Launchpad bug 1675210 in ubiquity (Ubuntu) "Ubuntu GNOME 17.04 Try or Install screen missing decorations" [Undecided,New] https://launchpad.net/bugs/1675210
<fossfreedom_> jbicha: \o/      :-)
<exp-innit> a question i originally asked in #ubuntu, is anyone aware of the procedures used to prepare the netinstall iso? i need to customise its kernel somewhat and the default one is missing some modules and potentially firmware. I could not find any documentation on the release preparation process or anything like that
<mdeslaur> exp-innit: the scripts are here https://code.launchpad.net/~ubuntu-cdimage
<mdeslaur> exp-innit: that's all I know
<exp-innit> mdeslaur: hmm, this does look pretty close, but i don't see an explicit mention of netinst, i'll keep looking :)
<exp-innit> mdeslaur: i'm not even sure which script to be using here, but they seem to depend on livefs-builders for which i can find no authoritative source
<exp-innit> and these seem to be focused on live, not net images, although that may be a different issue
<exp-innit> any suggestions?
<mdeslaur> exp-innit: no, sorry, that repo is all I know about
<exp-innit> mdeslaur: i see, well thanks for the link, it gets me closer :)
<brendand> is it no longer possible to test against multiple packages built from source using autopkgtest?
<brendand> "autopkgtest: error: You must specify only one source package to test"
<exp-innit> so from what i can tell, this livefs-builders seems to be a configuration file present somewhere on launchpad, there's a group of users allowed to use it, but i have no idea where it actually resides or how to utilise it locally
<exp-innit> advice very welcome!
<nacc> brendand: not sure i understand? the tests live in some specific source package?
<brendand> nacc, there used to be an --unbuilt-tree option to build from source
<brendand> nacc, that seems to have been replaced by just specifying the path as an argument, but you could define multiple --unbuilt-tree's
<brendand> not so now it seems
<nacc> brendand: right, you are testing one source package -- i'm not sure i follow the use case?
<nacc> brendand: you can specify dependencies on the command-line, but as binary packages
<nacc> brendand: you can pass a singe unbuilt source package as the argument, as well
<brendand> nacc, yeah it's to use a dependency built from source
<nacc> brendand: ah, yeah, either build that locally first or use a PPA
<nacc> slangasek: did the process-components-mismatch emailer get broken recently?
<nacc> slangasek: it now says the following packges.... MIR: #1667003 (Confirmed)
<nacc> slangasek: and doesn't list the package :)
<jgrimm> nacc, able to take a sponsorship -> https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1634989
<ubottu> Launchpad bug 1634989 in rabbitmq-server (Ubuntu Yakkety) "Segfault on rabbitmq-server start" [Undecided,In progress]
<nacc> jgrimm: ack
<jgrimm> cool, thanks sir
<slangasek> nacc: it's always been broken, it does weird diffing
<nacc> slangasek: ah ok, i thought i saw a bug # before, i'll assume i was wrong :)
<slangasek> nacc: when there is no change to the list of packages that are component-mismatched, but there's a change in the MIR bug state, it sends the weird contextless mail
<nacc> slangasek: ah got it
<exp-innit> don't suppose either of you know the answer to my question above? :)
<nacc> exp-innit: sorry, missed the question on reboot, possibly?
<exp-innit> nacc: i'm looking for how the netinst isos for ubuntu are produced so i can customise them
<exp-innit> i was linked to https://code.launchpad.net/~ubuntu-cdimage but these seem to be backed by configuration settings i don't have access to, such as a 'livefs-builders' file
<infinity> exp-innit: By "netinst ISOs", do you mean the mini.iso?
<infinity> exp-innit: Because that's just "apt-get source debian-installer", it has nothing to do with cdimage.
<exp-innit> infinity: i see
<infinity> exp-innit: As for the other question, unless you're locally running launchpad, livefs-builders will be useless to you.  You need to look at the spirit of the code, not the literal implementation (ie: that cdimage asks some remote machine/process to build a livefs, which you might have to do by hand instead using live-build, then it downloads the result and does things to it)
<infinity> exp-innit: But yes, if all you're interested in is the tiny netinst mini.iso, none of the cdimage infra is interesting, that's produced by the debian-installer package build.
<exp-innit> infinity: i see, the 'spirit of the code' is rather a waste of time though isn't it? i mean even if that's what was intended
<infinity> exp-innit: What's a waste of time?
<exp-innit> infinity: if there's a bunch of repositories available where their dependencies are not
<exp-innit> ie the livefs-builders stuff
<exp-innit> or are they actually available somewhere that i missed?
<exp-innit> because the entries on google are minimal to say the least
<infinity> exp-innit: The dependency totally exists.  It's called "run your own launchpad".  If you mean we should include a sample version of the file that effectively says that, sure, maybe.
<exp-innit> infinity: if it's intrinsically tied to launchpad i can't quite understand why, but it would at least be nice to mention it
<infinity> exp-innit: Well, it's tied to either LP or a remote builder running our old buildd setup.  livefs-builders defines one, lives-launchpad defines the other.  It could certainly be modified to call a live-build/livecd-rootfs wrapper locally, but that's not a use-case we've needed.
<infinity> exp-innit: The point of releasing the code is to let people grab bits they want, see how we do things and, sure, run it if they feel the urge, but I'd hardly call it a product we support.
<exp-innit> infinity: being able to rebuild the installer is a fairly important thing imho, the mini iso aside as you've given me all the information i require there
<exp-innit> would you not say the installer is a product you support?
<exp-innit> or, do the cdimage repositories count as a slightly different category?
<exp-innit> (needless to say, i have not been able to find documentation to elucidate on these topics)
<davmor2> exp-innit: if all you are trying to do is modify your own cd use the dell product it is designed to do exactly that
<infinity> exp-innit: We support the ISOs we product.  We certainly don't support people altering them.  In fact, we go out of our way to NOT support that. :)
<infinity> s/product/produce/
<exp-innit> davmor2: the dell product?
<exp-innit> infinity: i don't know what to say to that, that's a rather bizarre approach
<exp-innit> ubuntu may only be installed the official way?
<exp-innit> i require a custom kernel module, so i should not use ubuntu?
<davmor2> exp-innit: just looking for the app name
<infinity> exp-innit: How does a custom kernel module require a new ISO?  But no, I'm not saying you shouldn't use Ubuntu.  I'm saying we don't *support* building custom ISOs.  We support Ubuntu, and the media we produce to install it.  A subtle difference, maybe.
<davmor2> exp-innit: but there is a nice guide here https://help.ubuntu.com/community/LiveCDCustomization
<infinity> We release the tools.  They're out there.  But the goal of them isn't to make them flexible and usable in environments other than ours.
<exp-innit> infinity: how does it not require a new ISO if the ISOs produced are one-size-fits-all-do-not-modify?
<exp-innit> and davmor2 i believe one of the steps there is "download an official iso, then hack on it!"
<exp-innit> which is not really the sort of solution we were hoping to aim for
<exp-innit> anyhow, the mini.iso approach should be fine
<exp-innit> but i must say i find the approach confusing
<davmor2> exp-innit: the ubuntu iso is a fixed thing it should only be release by Ubuntu and be checkable how can that be the case if it is modifiable
<davmor2> exp-innit: it would be like buying a music cd then complaining that you can't add your track too it
<exp-innit> davmor2: no it would be like downloading a deb then complaining that i can't get the corresponding src package
<infinity> exp-innit: The source is all there.  So no, it's not like that.
<exp-innit> infinity: other than the required parts to do the buildpackage step, which is what i started asking about really
<exp-innit> anyhow, this is going nowhere, and i have no intention on arguing the point
<exp-innit> the answer you gave re: mini.iso should be more than sufficient
<infinity> exp-innit: However, we do have a trademark policy that says you can't build your own Ubuntu distribution and call it Ubuntu.
<infinity> For reasons that should be self-evident.
<exp-innit> infinity: that is completely irrelevant?
<infinity> exp-innit: Depends.  Are you distributing these modified ISOs?  If so, then it's really not irrelevant.
<exp-innit> infinity: if i was, that would be a matter for your legal department
<infinity> (Unless you're also calling them expLinux (based on Ubuntu))
<infinity> exp-innit: Anyhow, your complaint originally of a missing config file is hardly "the source code is missing".  And the content of the config file could be determined by a quick glance at the source.  The larger blocker there, as I pointed out, is what the config file actually defines the other end to be.
<exp-innit> i don't see how this has any bearing whatsoever, unless you're saying Ubuntu doesn't support customising the install ISOs because they wish to enforce their copyright on the word "Ubuntu"
<bdmurray> What does blacklisted mean? http://autopkgtest.ubuntu.com/packages/a/akonadi/xenial/s390x
<infinity> exp-innit: And saying "I don't want to run launchpad" isn't the same as "you don't release the source".
<exp-innit> infinity: the contents are not as divinable as you believe, and i didn't refuse to run launchpad, it is undocumented (or poorly documented) that that is the case
<davmor2> exp-innit: Ubuntu Customization Kit is the dell tool.
<infinity> exp-innit: http://paste.ubuntu.com/24235823/
<exp-innit> davmor2: thank you, i'm not sure it really fits our needs but i appreciate you looking it up and letting me know, i'll certainly look through it
<infinity> exp-innit: There's no secret sauce in those files, they're just literally useless outside our production environment.  But that's what they look like.
<Laney> bdmurray: That the infrastructure won't run it
<Laney> no I don't know who put akonadi there, or why
<exp-innit> infinity: i see, well can i suggest that some documentation be added at least somewhere that explicitly warns people off this approach?
<exp-innit> as it certainly violates the principle of least surprise that the ISOs are only customisable after their construction
<exp-innit> that is somewhat the opposite of every linux system i can think of, and i don't mean that as an insult
<infinity> exp-innit: Is it?  It's never been easy to reproduce the Debian ISO infrastructure either.
<infinity> We may have accidentally made it more complicated when we forked it 13 years ago, but...
<exp-innit> infinity: i can't think of any other example where the policy is that you should modify the built 'binary' package, rather than modify the source of it
<exp-innit> the difficulty of the infrastructure wasn't really my point
<infinity> exp-innit: Err, no.  We have no policy that implies that either.
<exp-innit> i'm just saying, the policy is surprising, and should be noted somewhere, at least somewhere more prominent as i was not able to find it
<infinity> exp-innit: The policy is that you can't modify it *and* redistribute it under the name Ubuntu.
<exp-innit> infinity: isn't that literally a wiki page linked before?
<exp-innit> https://help.ubuntu.com/community/LiveCDCustomization ?
<infinity> exp-innit: Whether you modify at build time or post-build, there's no "policy" around that, just common sense that reproducing our build infra is harder than mangling an ISO.
<exp-innit> ok, well semantic arguments about "policy" aside
<exp-innit> it would be nice if there was some explicit warning
<exp-innit> as a related question, but wholly from the opposite perspective, we've noticed there are modules available in the -generic kernel packages that are not available in the installer by default, is there documentation as to the extent of what's included or not?
<infinity> exp-innit: By "in the installer", you mean in d-i installs?  Cause it should all be available in desktop installs.
<infinity> exp-innit: For d-i installs, it's self-documenting via the debian-installer source (which defines which udebs are built into which targets) and the linux source (which defines which modules are in which udebs).
<exp-innit> infinity: unfortunately i did not author the install environment here, but i believe it's based off netboot or the mini iso
<exp-innit> but, that answer is perfectly sufficient, thanks
<davmor2> exp-innit: there is only one generic kernel, during the install you have the option to enable 3rd party drivers which will either pull from the iso or from the web if you are connected, but those modules can not be shipped by default because it is not allowed by the companies owning the rights to those packages
<exp-innit> davmor2: i don't think these are license restricted packages, but they may be firmware associated or so, i will need to investigate a little further
<exp-innit> thanks for the answer though, much appreciated
<infinity> slangasek, bdmurray: You both have a bunch of commits on livecd-rootfs trunk.  Are those good to be pushed to the archive?
<slangasek> infinity: yes
<slangasek> (didn't I already? sorry)
<infinity> slangasek: Nope.  And my RPi fix on trunk that I assumed someone would release by now never made it in. ;)
<infinity> (Obviously my fault, not yours, but...)
<slangasek> yeah, mine are all good to release but also not urgent
<infinity> The RPi fix is only urgent if I recide to respin that image before I release the beta.
<infinity> Which I suppose I could do quickly.
<infinity> If we upload livecd-rootfs and push it through.
<infinity> Objections?
<slangasek> no objection here
<bdmurray> none
<infinity> xnox: *poke*
<infinity> xnox: Around?
<infinity> slangasek: Or, wait, is xnox here this week?
<slangasek> infinity: he is not
<infinity> Bah.
<infinity> Is there anyone else who has a clue how to "test" the s390x server ISO?
<slangasek> infinity: something I can xnox for you?
<slangasek> ah
<slangasek> powersj: ^^ ?
<infinity> dannf: You around?
<dannf> infinity: yup
<infinity> dannf: Can I get a (very) quick boot/install/reboot smoketest of zesty beta2 arm64?
<infinity> dannf: http://cdimage.ubuntu.com/ubuntu-server/daily/20170321/zesty-server-arm64.iso
<dannf> infinity: sure
<infinity> dannf: http://iso.qa.ubuntu.com/qatracker/milestones/374/builds/144350/testcases (please register a result of some sort)
<javier4> Hi. I want to apply some modifications to an ubuntu package for armhf. Is this the right way: download orig.tar.gz, apply the related diff.gz,  apply my changes, and pass the source dir to sbuild (that I have already configured)?
<rbasak> Roughly, yes. The dget and dpkg-source tools do these steps for you though.
<javier4> rbasak: dpkg-source download automatically the debianized source tarball, or apply the diff.gz after I manually downloaded it?
<rbasak> javier4: see the dget manpage
<slangasek> rharper: bug #1673860 still has no SRU bug template, can you get that today?
<ubottu> bug 1673860 in systemd (Ubuntu Yakkety) "systemd-resolved unit should run Before=network-online.target" [Undecided,New] https://launchpad.net/bugs/1673860
<dannf> infinity: done. LP: #1675522
<ubottu> Launchpad bug 1675522 in grub2 (Ubuntu) "arm64: Synchronous Exception at 0x00000000BBC129BC" [Undecided,New] https://launchpad.net/bugs/1675522
<infinity> dannf: How... Fun.
<infinity> dannf: So, I guess we shouldn't release that. :/
<infinity> dannf: And priotize hunting down WTF ASAP.
<dannf> yeah, reverting to yakkety grub to see if that's it
<infinity> dannf: Curious that it's only on REboot.  Could be a qemu bug not clearing some registers or something on machine reset?
<dannf> infinity: yeah, could be
<dannf> infinity: reproducible w/ yakkety grub. what's weird is that the host is pristine xenial - would've thought we'd seen this problem before
<infinity> dannf: Is it reproducible with a xenial ISO?  If so, I'm inclined to say zesty isn't the problem here, and your boot/install test is a success.
<dannf> infinity: checking
<dannf> also testing w/ the yakkety kernel. maybe some hw isn't getting quiesced like it once was
<dannf> infinity: yep, boot w/ 4.8, reboot to 4.8 works
<infinity> dannf: kernel shouldn't be involved, in theory.  I mean, unless qemu was incorrectly relying on the kernel doing somehting it doesn't have to.
<dannf> right, not saying it's a kernel *bug*
<infinity> dannf: If downgrading the kernel works, it still smells like a qemu bug.  Since "ask the machine to reboot" should be all that's required for a clean reboot.
<infinity> dannf: But that also returns us to "the image isn't releasable in that state", so whee.  I guess I'll keep it disabled.
<infinity> dannf: Please make sure this gets escalated/fixed by whomever should be doing the investigation and fixing ASAP.
<bdmurray> nacc: Is there any migration documention for bug 1668808?
<ubottu> bug 1668808 in iscsitarget (Ubuntu Xenial) "iscsitarget-dkms 1.4.20.3+svn502-2ubuntu4: iscsitarget kernel module failed to build [error: field ârx_hashâ has incomplete type]" [Undecided,In progress] https://launchpad.net/bugs/1668808
<nacc> bdmurray: i'm working on it now -- do you think that's appropriate to put in the release notes? or i could also, i guess have put it in the changelog itself!
<nacc> bdmurray: unfortunately, it's a non-trivial migration (i don't think tgt and ietd are configured similarly)
<bdmurray> nacc: I think somewhere in the bug is good. Maybe the 16.04 release notes if its not already there.
<nacc> bdmurray: ack, will provide in both (the latter is not, because the package still exists in 16.04, just doesn't do anything for HWE)
<nacc> bdmurray: but yeah, i agree, we should document the recommended approach
<nacc> mabye i'll just point at the server guide which has a tgt/iscsi section i think
<nacc> bdmurray: and thanks for following up, excellent SRU work :)
<bdmurray> mwhudson: Does the docker-compose upload in the yakkety queue reference the right bug number? bug 1675288
<ubottu> bug 1675288 in runc (Ubuntu) "security fix to runc in docker-1.12.3 wasn't picked" [Undecided,New] https://launchpad.net/bugs/1675288
<mitya57> Can someone please reject metacity from Xenial queue? After uploading I noticed that it FTBFS.
<infinity> mitya57: Done.
<mitya57> thanks
<infinity> mitya57: (You generally want #ubuntu-release for queue admin requests)
<mitya57> OK, will bear that in mind.
<infinity> dannf: A qemu problem on all releases, or specific to one?
<dannf> infinity: upgrading the host's qemu from xenial's ver to zesty's seems to fix it
<infinity> dannf: Hrm.  Kay.  So should I release that image?
<dannf> infinity: +1
<infinity> Doing.
<infinity> dannf: That said, anyone running an arm64 cloud is probably doing so on xenial, so please figure out WTF? :)
<dannf> infinity: yep, we'll figure it out
<juliank> Things with the two apt srus are a bit strange now. Some bugs got verification-done-xenial verification-needed-yakkety (and a verification-needed), others only got reset from verification-done to verification-needed.
<juliank> For example: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657567 has -needed, https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657440 has -needed, -done-xenial, -needed-yakkety
<ubottu> Launchpad bug 1657567 in apt (Ubuntu Yakkety) ""Content-Range: */<file size>" on non-416 responses considered invalid" [Low,Fix committed]
<ubottu> Launchpad bug 1657440 in apt (Ubuntu Yakkety) "apt won't redownload Release.gpg after inconsistent cache updates made while UCA is being updated" [Medium,Fix committed]
<nacc> bdmurray: re: LP: #1574900 and LP: #1574911, it seems like we're in a bad place beause we're shipping an unmaintained/broken pam-mysql RC that never released (it was subsequently forked and the version in 17.04 is the new repository and working). I spent some time yesterday and could not find a specific change that woudl fix the stack smashing. I could ask upstream to help, but honestly, from an
<ubottu> Launchpad bug 1574900 in pam-mysql (Ubuntu Yakkety) "libpam-mysql undefined symbol: make_scrambled_password" [Undecided,Fix committed] https://launchpad.net/bugs/1574900
<ubottu> Launchpad bug 1574911 in vsftpd (Ubuntu) "vsftpd 500 oops stack smashing detected - Ubuntu 16.04" [Undecided,Confirmed] https://launchpad.net/bugs/1574911
<nacc> SRU/LTS perspective, I think we would be better off shipping the actual release (same upstream as in 17.04). An MRE but not a permanent MRE -- thoughts?
<juliank> How best to clean this up and tag the bugs once verified on yakkety as well?
<nacc> juliank: i don't think there is any reason not use per-release v-n and v-d tags if they should be there
<nacc> juliank: but i suppose you should wait for an SRU repsonse :)
<infinity> juliank: If you're looking to triage it all and make it look sane, drop all the non-release ones and replace with release-specific tags that represent reality.
<infinity> Our tools kinda suck at doing this consistently, and our users suck even worse at it.
<juliank> OK, great.
<juliank> I'll have a look at it in the next days
<mwhudson> bdmurray: argh what
<mwhudson> bdmurray: no :)
<mwhudson> bdmurray: reject pls
<mwhudson> bdmurray: also xenial
<mwhudson> bdmurray: i owe you beer sometime in june somewhere in the pacific north west
<tsimonq2> mwhudson: Are you going to LFNW?
<mwhudson> tsimonq2: nah, work sprint
<tsimonq2> mwhudson: Aww :P
<mwhudson> tsimonq2: have two kids under 5, don't get to travel for fun :)
<tsimonq2> mwhudson: ;)
* infinity 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:
#ubuntu-devel 2017-03-24
<monsieur_h> Hello. So I made an app with JS/GTk3 and I'd like to host a PPA, but I have no clue where to begin.
<monsieur_h> The documentation I found always relates to building .deb files, but I don't know how to do it
<monsieur_h> Would you guys point me in the right direction ?
<ginggs> monsieur_h: this looks like a good place to start http://packaging.ubuntu.com/html/
<monsieur_h> thanks
<javier4> trying to cross-compile for buntu-touch, I keep getting
<javier4> https://www.irccloud.com/pastebin/dCZHqpBY/
<javier4> I already installed dh-system inside my chroot
<javier4> schroot -c source:vivid-amd64-armhf
<javier4> https://www.irccloud.com/pastebin/qGbOlZZe/
<sil2100> bdmurray: hey! I wanted to review cinder from the unapproved queue, but to handle it I'd have to approve the previous upload to -updates - and since I didn't get a formal green light from you on approval of packages for -updates, I'd like to get a double-confirmation from if it's ok
<sil2100> bdmurray: I checked the bugs and the testing validation comments seem sane, aging period is good
<alkisg> xnox: hi, friendly-recovery.service has 2 syntax errors, could you please have a look at https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1675805 whenever you have some time? Patch included.
<ubottu> Launchpad bug 1675805 in friendly-recovery (Ubuntu) "Friendly recovery uses invalid font" [Undecided,New]
<sil2100> bdmurray: can I approve the -proposed cinder?
<bdmurray> sil2100: No, because its Friday.
<tinoco> I think https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1317491 has passed enough time in -proposed an has been verified as good. Could someone move it to -updates, please ?
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed]
<bdmurray> tinoco: Not today because it's Friday.
<sil2100> bdmurray: ah! You are right!
<bdmurray> I always know when its Friday.
<sil2100> Time files
<sil2100> *flies
 * alkisg feels happy when it's summer holidays and doesn't know what day it is :D
<tinoco> bdmurray: ok. I'll ping you back on Monday. tks.
<jbicha> bdmurray: why should this file be so private? LP: #1386752
<ubottu> Launchpad bug 1386752 in whoopsie (Ubuntu RTM) "whoopsie-id is world readable" [High,Triaged] https://launchpad.net/bugs/1386752
<infinity> jbicha: A curious question (that I also don't know the answer to).
<jbicha> cyphermox: you don't happen to have a fingerprint reader on your computer, do you?
<cyphermox> jbicha: I do, why?
<dobey> anyone know how /var/run related stuff works in sbuild? am trying to figure out how to solve a problem with starting services during tests in sbuild in jenkins. it works fine on lp builders, but not so much in jenkins sbuild
<Unit193> ginggs: You seem pretty interested in getting last minute universe bugfixes in, interested in sponsoring xfdashboard bugfix release?
<jbicha> cyphermox: because gdm is still broken for you, probably? I saw this g-shell commit post 3.24.0: https://git.gnome.org/browse/gnome-shell/commit/?id=c0861b1
<ginggs> Unit193: I could be
<Unit193> https://git.launchpad.net/~xubuntu-dev/+git/xfdashboard or I could get you a dsc.
<cyphermox> jbicha: it fails as much on my system with as the one without
<ginggs> Unit193: please file a LP bug and include the upstream changelog (and close the bug in d/changelog)
<jbicha> cyphermox: it's broken on 2 computers and you haven't filed a bug yet?! :)
<ginggs> Unit193: are you interested in doing a xscreensaver merge? :)
<cyphermox> jbicha: I'm pretty sure I *did* me-too one of the crash bugs before we figured that it's really something different, and since reverted back to lightdm
<cyphermox> having no session-manager is pretty crippling
<jbicha> well if you want to try again sometime; you're the only one I've heard from that still has problems loading gdm on zesty
<cyphermox> ok, I'll have a look
<Unit193> ginggs: Oh, I just checked permissions.  Turns out it was added to our packageset (https://lists.ubuntu.com/archives/devel-permissions/2017-February/001033.html)  I might be, lets check it out.
<jbicha> (today started out bad for me, I managed to break lightdm :( )
<nacc> jbicha: you broke lightdm? I wondered who did
<cyphermox> jbicha: to answer your question gdm3 still doesn't work on my laptop with the fingerprint reader, but it's not completing bootup -- I don't have ssh started or any getty, so I can't go dig right now
<cyphermox> yuck, and recovering from that is no fun
<Unit193> ginggs: Actually,  xscreensaver-data 5.26-1ubuntu1  is even in Xenial, looks like the breaks/replaces can be dropped.
<Unit193> ginggs: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/7629643/+listing-archive-extra
<bdmurray> sarnold: Could you maybe have a look at bug 1582992 again?
<ubottu> bug 1582992 in apport (Ubuntu) "broken apport hook: TypeError: Can't convert 'bytes' object to str implicitly" [Undecided,Incomplete] https://launchpad.net/bugs/1582992
<sarnold> bdmurray: either it's been fixed or whatever was in my logs that tripped python's OCD is no longer in my logs -- now I only get the "Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged." message. I didn't actually file the bug reports though.
<sarnold> (I don't think I _could_ file the bug reports in may)
<sarnold> bdmurray: is there anything else you'd suggest checking? or shoudl I add this info to the bug and mark it invalid?
<sarnold> sigh looks like I missed arges's question in comment #4 :( .. heh, and your #5
<bdmurray> Well I just added #5
<bdmurray> presumably it was the Kern.log file in the bug report which was a problem right?
<sarnold> I can't find download-crash; is this the right place to look? https://code.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns
<bdmurray> Oh, apparently that's just on my local filesystem. :-|
#ubuntu-devel 2017-03-25
<Fajeey> #index user
<Fajeey> #index join
<erle-> Who is defining Ubuntu's certificate trust store?
<erle-> (The one that is shown by Seahorse.)
<erle-> (Firefox has its own obviously.)
<tjaalton> would it be possible to get debhelper 10 in xenial? I know it's in -backports, but it's not enough for all the backports that I'm dealing with
<javier4> I'm setting up an lxc container to build for ubuntu touch armhf. I also added ppa:ci-train-ppa-service/stable-phone-overlay through apt-add-repository, which should include source repo too, but apt-get build-dep complains about the lack of a src repo. Actually I can't see that repo inside my source.list, but I'm not familiar with apt tools.
<dylan> Hi guys, is the Ubuntu Packaging Guide still a reliable source for learning how to package? Its version is 0.3.8~bzr600~ubuntu14.04.1 (note the 14.04); bug 1569561 mentions that the UDD, featured heavily into the guide, is dead and that half of the guide is outdated.
<ubottu> bug 1569561 in Ubuntu Packaging Guide "4.2.2 is out of date, no longer works correctly" [Undecided,New] https://launchpad.net/bugs/1569561
<dylan> What would you recommend I read instead to learn packaging?
#ubuntu-devel 2017-03-26
<adu> hi, where is the ubuntu-vagrant room?
<adu> is there anyone looking at this? https://bugs.launchpad.net/cloud-images/+bug/1569237
<ubottu> Launchpad bug 1569237 in cloud-images "vagrant xenial box is not provided with vagrant/vagrant username and password" [Undecided,New]
<jtaylor> did perf break for anyone on 4.8 kernels? whatever I profile it always reports all cpu usage in the kernel scheduler
#ubuntu-devel 2018-03-19
<rbasak> enyc: I don't see any reason why SRU or backports processes to Xenial and Trusty can't start now.
<tsimonq2> Can I please get some clarification on what it means for Foundations to triage bugs?
<tsimonq2> So when e.g. rls-bb-incoming is added, it goes in a queue, I believe.
<tsimonq2> At what point is it assumed that Foundations has an eye on it?
<tsimonq2> Like, I see e.g. bug 1742147 where the tag "id-5a578f7753948dd556e87182" was added and rls-bb-incoming was removed.
<ubottu> bug 1742147 in ubuntu-release-upgrader (Ubuntu Bionic) "upgrade from 17.10 to 18.04 fails with triggers looping" [Critical,Confirmed] https://launchpad.net/bugs/1742147
<tsimonq2> From there, I am a bit confused. It doesn't explicitly show on the bug report that any progress was made, yet that tag was removed, so it seems that *something* was done.
<jdonald> Looks like we have the flags now to fix Firefox on Bionic (and Trusty) armhf: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337
<ubottu> Launchpad bug 1711337 in firefox (Ubuntu) "Firefox crashes at start on armv7L after 55.0.1 update" [Undecided,Confirmed]
<jdonald> Is there someone here with access to change build flags used by Launchpad?
<tsimonq2> jdonald: It depends.
<tsimonq2> If the build flags can be done in the packaging, chrisccoulson is the person to talk to.
<tsimonq2> If you need Special Magic done on the builders themselves, talk to a Launchpad administrator such as cjwatson.
<tsimonq2> I Have Not Looked Yet but let me see.
<tsimonq2> This is probably a packaging change that needs to be done.
 * Son_Goku waves at sabdfl 
<doko> tsimonq2: are you working on the node-js migration to the release pocket?
<tsimonq2> doko: Yes.
<cjwatson> tsimonq2: To a good first approximation Launchpad is never involved in setting build flags. :-)  (There are a tiny number of exceptions, but the fewer the better)
<tsimonq2> cjwatson: That's why I thought it should be done in the packaging.
<cjwatson> Indeed.
<xnox> tsimonq2, "remove tag + assign to series" => means it's committed to be fixed that cycle.
<xnox> tsimonq2, "id-<foo>" is foundations-internal project management of tasks, and is no significance (could be assigned, could be in the backlog...)
<tsimonq2> xnox: So then how do I know if someone in Foundations is working on it?
<tsimonq2> Like, are there notes on the foundations-internal side?
<tsimonq2> I guess my point is, if I want to fix a bug tagged like that, I don't want to disrupt anything or duplicate work if there's something I can't see.
<xnox> tsimonq2, there are no notes on the foundations-internal side, as that is private foundations trello boards
<xnox> tsimonq2, it's a public bug, you will see public merge proposal if its done. and we would really love to review merge proposals =)
<xnox> tsimonq2, note that than one might need multiple fixes -> e.g. fix those specific packages to use no-await triggers and upload that; develop something in release-upgrader to be smart and self resolve trigger loops.
<tsimonq2> xnox: Right.
<tsimonq2> xnox: My ultimate goal in digging into these types of bugs is to learn and apply that to fixing future bugs faster. So I'm not entirely sure how the triggers really work quite yet, but it shouldn't be too hard to learn. ;)
<juliank> Laney: I'm noticing that ubuntu-release-upgrader and update-manager autopkgtests fail to connect to changelogs.ubuntu.com via HTTPS, same test via HTTP works fine. I was wondering if you could check manually in an autopkgtest environment, in case that's simply firewall blocking access and needing unblock
<juliank> Like run nc changelogs.ubuntu.com 443 and write GET / HTTP/1.0 to it.
<juliank> It then answers with bad request
<juliank> because I'm talking plain to a TLS server :D
<cjwatson> juliank: Yes, this is a clear firewall bug
<cjwatson> juliank: Grab lp:~canonical-is-firewall-configs/canonical-is-firewalls/+git/firewall-configs and look at rules/is/changelogs.yaml
<juliank> cjwatson: thanks
<cjwatson> juliank: See https://docs.admin.canonical.com/is-firewalls/mojo-is-firewalls/user/ for how to propose a fix
<Laney> cheers
<cjwatson> (These are all Canonical-only links - sorry to the rest of the channel)
<xnox> tsimonq2, https://lintian.debian.org/tags/uses-implicit-await-trigger.html
<xnox> tsimonq2, and links from there to the debian bug report
<acheronuk> can anyone suggest who is best to approach to get the debdiff in comment #21 of LP: #1572244 actioned/uploaded?
<ubottu> Launchpad bug 1572244 in casper (Ubuntu Bionic) "Kubuntu requires that the WiFi password be entered twice before WiFi can be used" [Medium,Confirmed] https://launchpad.net/bugs/1572244
<rbasak> Maybe cyphermox: ^
<rbasak> acheronuk: also subscribe ~ubuntu-sponsors to the bug, though I'd want to check with someone appropriate on the foundations team before sponsoring it.
<acheronuk> rbasak: yeah, as it's in main I held off
<acheronuk> sponsors subbed
<ahasenack> Laney: hey, good morning, did you see my ping from a few days ago about gvfs? Are you preparing a new upload by any chance?
<Laney> ahasenack: I saw it. I'm going to upload at some point, and I'll look at the test then.
<ahasenack> Laney: is there a way to tell how frequently people hit the retry button for gvfs?
<Laney> The first request for a trigger/version/package triple will be the one from proposed-migration, and the subsequent ones manual retries.
<Laney> If you want to gather data to lobby our team though, you don't need to.
<ahasenack> just wanted some confirmation it's flaky for others as well :)
<ahasenack> could you then perhaps please click the retry button for my samba upload then?
<Laney> Okay.
<ahasenack> Laney: https://pastebin.ubuntu.com/p/yhBhSJjdhG/ 5-10s
<ahasenack> the one really failing is unmount_api(), but I changed it in the other too for consistency
<Laney> ahasenack: if you could, it'd be nice to test that
<ahasenack> I can test that, but since I can't reproduce the failure, it would just tell me the code works
<ahasenack> it's only happening in excuses
<Laney> You can upload to a PPA and then we can run the test there
<ahasenack> ok
<Laney> 5 seconds already feels like it should be long enough, so maybe this is something else
<Laney> we'll see I guess
<ahasenack> Laney: it could definitely be something else
<Laney> cheers!
<ahasenack> Laney: since the failure to unmount is about "filesystem is in use"
<Laney> ahasenack: I bumped the existing hints to apply to this version instead of retrying btw
<Laney> it's skipped on ppc64el already
<ahasenack> on s390, you mean
<ahasenack> the error in s390x is different, though
<Laney> no
<Laney> I mean ppc64el
<tsimonq2> xnox: ack, thanks
<ahasenack> Laney: https://launchpad.net/~ahasenack/+archive/ubuntu/gvfs-test-fixes-1713098/+packages has that timeout bump. We would need that ppa enabled for ppc, though, right?
<Laney> ahasenack: you should be able to do it in the settings
<Laney> "change details"
<ahasenack> oh, indeed
<ahasenack> I thought it would need a trip to rt/webops
<Laney> I think if you copy the package back on top of itself using copy-package it'll generate the missing build records?
<ahasenack> I'll try
<ahasenack> no, it doesn't like it. I'll bump the ~ppaN suffix and reupload
<Laney> what did it do?
<ahasenack> said version already existed
<enyc> rbasak: ok, can you point me at the SRU and backports process so I do it -- or you start? --   Xenial-case is much simpler (but STRONGLY advise keep byte-for-byte original xenial mke2fs.conf).  Does it START as a Backport or START as an SRU?.    Trusty, is more complicated, as documented.
<rbasak> enyc: https://wiki.ubuntu.com/UbuntuBackports and https://wiki.ubuntu.com/StableReleaseUpdates. An SRU is more likely to be refused under the SRU policy.
<rbasak> For an SRU it might be worth getting a +1 from the SRU team first.
<rbasak> I'm on the SRU team, but I should probably defer to one of the others.
<enyc> rbasak: right, but what ''practically helps'' in this case?  does it HELP to get a PPA out?  does it HELP to get a backport done first, intending it to later become an SRU ?
<rbasak> enyc: yes I'm assuming that SRUs wouldn't change default behaviour at all.
<enyc> rbasak: in pparticular, this (somehow) needs considerable ''regression analysis testing'' however we can get that ?
<Laney> ahasenack: I triggered 5 runs each on amd64 & i386
<rbasak> enyc: good question
<enyc> rbasak: can you ask that (initial) question of your colleagues and come back with suggestions?
<ahasenack> Laney: ok
<rbasak> enyc: both for a backport and an SRU the reviewing teams will expect that the person driving has at least done some informal testing and verification. Doing that in a PPA allows easier sharing, so sure that'll help without any increased effort really.
<enyc> rbasak: does PPA / build system  provide mechanism to 'build for all architectures' [and more the point, run the PPA build through ubuntu build-system], not just "upload my own binaries on limited arches" ?
<cjwatson> you can enable architectures of your choice on a PPA's "change details" page
<cjwatson> I don't know what "ubuntu build-system" you are referring to
<enyc> as in, ubuntu/launchpad/build-system/PPA-system/conincal somewhere "builds" your PPA from source, it doesn't just  distribute source/binaries you give-it only...
<cjwatson> backports in general do not become SRUs; they're a different path
<enyc> nods
<cjwatson> that's how PPAs work.  you don't have to do anything to invoke that behaviour
<enyc> ok, all new to me =)
<cjwatson> in particular it is not possible to upload your own binaries to a PPA
<rbasak> enyc: I posted this: https://lists.ubuntu.com/archives/ubuntu-devel/2018-March/040250.html
<enyc> right. I recall that sort of thing changing in  debian maintainers system at some point...  they CHANGED to a sysetm where all binaries have to be built in controlled-environment.
<cjwatson> no
<cjwatson> that is not true
<cjwatson> Debian has source-only uploads now, yes, and that's a big improvement as they become normalised; but it's still possible for developers to upload their own binaries
<enyc> okies
<enyc> maybe the 'have to be built' part applies to release versions, at least
<enyc> nm, would have to check facts and all that
<cjwatson> no, you just have a slightly exaggerated view :)
<cjwatson> the way source packages in PPAs are built is very close to identical to how source packages in Ubuntu are built.  there are a few differences, and PPAs have to be configured in a particular way if the intent is to actually copy the binaries from them into Ubuntu verbatim; but that isn't usually necessary, and for testing they're nearly always good enough
<Laney> ahasenack: https://paste.ubuntu.com/p/tXS2dnzYVy/
<cyphermox> acheronuk: rbasak: ack, I will sponsor that if it's not done yet...
<acheronuk> cyphermox: thanks. much appreciated
<ahasenack> Laney: ppc builds are done
<ahasenack> Laney: I also have https://launchpad.net/~ahasenack/+archive/ubuntu/unchanged-gvfs/+packages to compare with, if you want
<ahasenack> grr, or so I thought
 * ahasenack hates ppas sometimes
<ahasenack> "already uploaded, blabla"
<TJ-> Anyone here responsible for checking the ubuntu-devel mailing list moderation queue? I sent to the list on the 17th for the ext4 metadata_csum thread but it's not appeared as yet
<cjwatson> I can do that, one moment
<cjwatson> done
<TJ-> cjwatson: many thanks :)
<rbasak> TJ-: thank you for posting those use cases. That's helpful.
<TJ-> rbasak: I just noticed a rather vital typo! "If the exported block devices have been formatted by a //18.04// clent then operations on the 16.04 SAN host may fail"
<rbasak> I didn't notice. I understood the use cases from the general idea :)
<TJ-> yeah... weird how our brains can do that... probably proof we're not A.I. in a holgraphic universe, or something. Or maybe, it just shows how bad my typing is!
<rbasak> TJ-: thanks. Now I just noticed that the subject says "backwards" when it should say "forwards".
<TJ-> I know of a few installations where the SAN hosts will remain on 16.04 but virtualisation clients may be on 18.04 where this could become an issue. I've got one-such here although it's not 'mission critical'
<TJ-> I wonder if we can get some love for this before 18.04? It's quite an issue now UEFI-SB is more popular and breaks a key part of FDE Bug #1565950
<ubottu> bug 1565950 in grub2 (Ubuntu) "Grub 2 fails to boot a kernel on a luks encrypted volume with Secure Boot enabled" [Medium,Confirmed] https://launchpad.net/bugs/1565950
<TJ-> This is an issue where /boot/ is encrypted and the modules need to be built-in to GRUB's core image, which for the -signed packages, aren't currently included
<Saviq> hey, what's the best way to get the Ubuntu release code in debian/rules? lsb_release isn't installed on the builders
<rbasak> Build-Depend on lsb-release?
<rbasak> That's the common way I've seen in the past.
<Saviq> ohkay :)
<LocutusOfBorg> distrelease	:= $(shell lsb_release -cs)
<LocutusOfBorg> this is what gcc does...
<LocutusOfBorg> also, https://codesearch.debian.net/search?q=lsb-release+path%3Arules
<juliank> Saviq: the best way is dpkg-vendor --derives-from ubuntu
<rbasak> LocutusOfBorg: yeah but the build-dep is needed, which I think was the question :)
<juliank> ah sorry, misread
 * juliank read it as ubuntu-specific code
<juliank> but you meant the codename
<juliank> *facepalm*
<Saviq> yeah, I need to switch features on different Ubuntu releases
<jdonald> Thanks tsimonq2
<jdonald> I actually emailed Chris Coulson some weeks ago about merely changing the status of that ticket he had touched last year. I never heard back so I figured he was no longer active at Canonical.
<jdonald> But I see chrisccoulson here on IRC, and he's the one who added flags to this build last year, so fingers crossed that he can do so again.
<apw> Saviq, can you use the series name from changelog ?
<LocutusOfBorg> rbasak, yes I got it, but the "additional dependency needed" was already solved, I wanted to point out the actual code :)
<LocutusOfBorg> btw Saviq can you enlight me about "what" differs between ubuntu releases?
<LocutusOfBorg> differing wrt codenames is usually wrong
<LocutusOfBorg> you know for sure better than me, but sometimes better use "features" to discriminate stuff, e.g. packages versions or similar
<LocutusOfBorg> stuff gets backported, upgraded and so on (think wrt hwe packages)
<LocutusOfBorg> so, basing an assumption on "xenial will keep kernel 4.4 forever" is wrong
<rbasak> LocutusOfBorg: https://lists.ubuntu.com/archives/ubuntu-devel/2017-December/040093.html is one example though I don't know what Saviq's specific case is here.
<LocutusOfBorg> rbasak, yes, something similar to what I was thinking
<xnox> Saviq, if in debian/rules: include /usr/share/dpkg/default.mk and then you will have access to $(DEB_DISTRIBUTION)
<LocutusOfBorg> xnox, won't help I would say...
<xnox> Saviq, do note you should be using patter matching / starts-with type of matching on it, to catch things like "xenial xenial-proposed xenial-updates xenial-security xenial-backports"
<Saviq> xnox: lsb-release would never return something like that, would it?
<xnox> Saviq, this is not based on lsb-release, but based on debian/changelog -> specifically based on who you are building for; not where you are building it on.
<xnox> Saviq, it uses dpkg-parsechangelog -SDistribution
<rbasak> Saviq: please make sure that building on the Ubuntu dev release always works including for unknown names. Otherwise rebuilding might break when a new series is opened.
<xnox> Saviq, i would advise against lsb-release.
<LocutusOfBorg> and remember, people uses "devel" as codename too
<xnox> Saviq, can you ellaborate as to what you are actually after to detect, in more detail?
<xnox> Saviq, and is it at build-time, configure time, runtime, test time, during end-user usage..... ?
 * xnox recommends using $(DEB_DISTRIBUTION) in debian/rules and search for known things, e.g. trusty,xenial,artful,bionic, assume everything else is newer/better.
<Saviq> xnox: well, that's waht I'm trying to do, bud DEB_DISTRIBUTION isn't set by default?
<xnox> Saviq, did you miss this:
<xnox> Saviq, if in debian/rules: include /usr/share/dpkg/default.mk and then you will have access to $(DEB_DISTRIBUTION)
<Saviq> I have that included :\
<xnox> Saviq, it's a MAKE variable, not environment variable....
<Saviq> aha, that may explain things
<xnox> Saviq, maybe you need to export it again....
<Saviq> I only need it in a $(filter), so I suppose curly brackets..
<cjwatson> $(...) nests
<xnox> Saviq, round =) not curly
 * xnox calls () round, and {} curly =)
<xnox> $(DEB_DISTRIBUTION)
<cjwatson> both ${variable_name} and $(variable_name) work in make FWIW
<xnox> oh
<xnox> ok
<xnox> today i learned.....
<cjwatson> or for functions, for that matter
<cjwatson> though I'm not sure I've ever seen functions used with ${..}
<xnox> https://stackoverflow.com/questions/25185607/whats-the-difference-between-parenthesis-and-curly-bracket-syntax-in-ma says no difference
<Saviq> ok then I'm doing something wrong, back to it
<xnox> Saviq, paste a diff to pastebin, for me/us to see and check?
<persia> Most make implementations should support ${func arg,arg,arg}
<cjwatson> right, I just don't think I've ever actually seen anyone trying to use it :)
<cjwatson> for whatever reason
<benpicco> Why is mono in Ubuntu stuck at such an old version? Is the package orphaned?
<nacc> benpicco: 4.6.2.7 in bionic
<benpicco> nacc: the latest upstream release is 5.10.0.160
<ogra_> ubuntus mono comes from debian ...
<ogra_> (IIRC)
<ogra_> so whatever is in debian at the time of the import freeze of an ubuntu release will be in the ubuntu archive
<xnox> benpicco, mono is available; but not widely used at all. E.g. none of the packages in main use mono.
<xnox> hence not much cared about either
<xnox> benpicco, what do you want to use it for?
<benpicco> xnox: renode, which is a firmware simulation tool
<nacc> benpicco: what ogra said, as well
<xnox> benpicco, ask upstream to provide a snap for it?
<xnox> benpicco, (possibly with whichever mono they recommend)
<ogra_> +1
<benpicco> xnox: upstream already provides a repository for Ubuntu 16.04 which works fine, I was just wondering why it's not included in ubuntu
<xnox> out of "big" mono things we have tomboy, banshee, smuxi apps.
<xnox> benpicco, probably because nobody packaged it for distribution, and went through sponsorship process to provide it.
<xnox> benpicco, if there is an archive for it already, building a snap should be fairly straightforward, then it will be available on all ubuntu systems; always latest stable; via $ snap install renode
<Saviq> xnox: http://paste.ubuntu.com/p/TxqxDvqkXm/
<persia> From a quick look, it looks like the folk that used to care for Mono in Debian and Ubuntu have moved on to other things.  At least one of them is still active upstream, and may appreciate an offer of help.
<xnox> Saviq, so, when debian/changelog top entry is "bionic", you are comparing ifneq(bionic,) -> which false -> meaning -DMIR_EGL_SUPPORTED=OFF is not added.
<xnox> sorry, got this wrong
<xnox> rewind
<Saviq> yeah, filter-out
<xnox> Saviq, hmmm
<xnox> Saviq, that looks invalid syntax, there no?
 * xnox counts brackets
<Saviq> xnox: I'm actually down to http://paste.ubuntu.com/p/8GFDsdmkxq/
<Saviq> since the binary won't be there when DMIR_EGL_SUPPORTED=OFF
<xnox> Saviq, it works here for me, your patch, just fine....
<xnox> Saviq, you are updating debian/changelog top line right? to say mir (0.30.0.1-0ubuntu3) bionic; urgency=medium -> then build?
<Saviq> xnox: yeah I think that's good now across xenial, artful, bionic, which we care about
<xnox> Saviq, you are updating debian/changelog top line right? to say mir (0.30.0.1-0ubuntu3) xenial; urgency=medium -> then build?
<Saviq> xnox: yeah, changelog gets "real" when building for real
<xnox> so you are all good =) cool.
<Saviq> xnox: I think so, will report back if not - btw, any pointers on debugging this, other than rebuilding from scratch over and over again?
<xnox> Saviq, well, to test here locally, I added
<xnox> snos:
<xnox>    echo done
<xnox> Saviq, just _after_ your lines that configure variables and print the info thing.
<xnox> and called ./debian/rules snos
<Saviq> ack
<xnox> Saviq, you can make dh_install fail with "exit 1" just before doing the real dh_install -> then backup the dir; and change changelog/do reruns without exit 1, using $ debuild -- binary -> which should pick up where dh_install left off.
<Saviq> nifty, will try that, thanks :)
<jbicha> btw, tomboy and banshee are scheduled for removal from Debian Testing next month ð¢
<Saviq> NOOOOoooooo.....
<jbicha> shutter too
<izznogooood> jbicha, flameshot
<sarnold> bdmurray: 1756640 has a HookError_source_ubiquity.txt that shows some python2 -> python3 errors still exist. Can you recall if this has already been "fixed" .. but is still on the distributed isos?
<bdmurray> sarnold: Should have been fixed in 2.20.8-0ubuntu7 of apport which is Bionic only.
<sarnold> bdmurray: great! thanks :)
<bdmurray> sarnold: Did you see the discussion regarding journalerrors?
<sarnold> bdmurray: hrm. I know I once complained about systemd's tools ellipsizing away all the useful content, but that's it; was there something else?
<bdmurray> sarnold: systemd journal errors and security concerns like bug 1738581
<ubottu> bug 1738581 in apport (Ubuntu) "apport is leaking environment variables (including passwords!) to public bug reports" [High,Fix released] https://launchpad.net/bugs/1738581
<sarnold> bdmurray: oh, I missed seb's comment here
<bdmurray> sarnold: A discussion was also started on ubuntu-devel
<sarnold> bdmurray: heh, looks like some folks had a busy weekend...
<tyhicks> mwhudson: hello! do you have any insight into why the docker.io build tests are failing?
<tyhicks> https://launchpad.net/ubuntu/+source/docker.io/17.03.2-0ubuntu4
<tyhicks> mwhudson: the docker-in-lxd autopkgtest was broken on bionic so I updated it so that I could unwedge my apparmor upload
<tyhicks> mwhudson: however, there's an unrelated build test failure that fails even when rebuilding 17.03.2-0ubuntu3 (without my changes)
<tyhicks> mwhudson: I spent some time poking around and it looks like a docker and golang 1.10 incompatibility: https://github.com/moby/moby/pull/35739#issuecomment-350385654
<tyhicks> mwhudson: I'm in over my head and I'm hoping you know what to do here
#ubuntu-devel 2018-03-20
<flexiondotorg> tjaalton: Will you be syncing libinput 1.10.3-2 from Debian to Ubuntu?
<flexiondotorg> Looking at upstream changes, it appears it resolves fixes pointer jitter detection, something I'm seeing people bumping into in the Ubuntu MATE community on some models of trackpad.
 * tsimonq2 files bug 1757024
<ubottu> bug 1757024 in libinput (Ubuntu) "Sync libinput 1.10.3-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1757024
<jdonald> For https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337
<ubottu> Launchpad bug 1711337 in firefox (Ubuntu) "Firefox crashes at start on armv7L after 55.0.1 update" [Undecided,Confirmed]
<jdonald> Now that we have a diagnosis and a proposed fix to go from Firefox not-running to running, can we get the Importance set to Medium or High?
<tjaalton> flexiondotorg: yes
<tjaalton> flexiondotorg: why not?
<Mirv> tjaalton: bug #1756380 might be interesting to target for fixing for release. if Firefox finally gets VA-API enabled during 18.04 LTS lifetime, this would affect quite a lot of Youtube playback
<ubottu> bug 1756380 in intel-vaapi-driver (Ubuntu) "vaapi VP9 hardware decoding not working anymore in bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1756380
<tjaalton> Mirv: yes, I'm trying to find the debian maintainers..
<tjaalton> to update it to 2.1
<tjaalton> which is needed for cannonlake anyway
<Mirv> I wish it'd be lowNMU
<tjaalton> it's team maintained
<dja> doko: quick question re: python packaging - the microsoft folk who do walinuxagent want to add a dependency on python3-distro. walinuxagent is in main and python3-distro is in universe - do you think a MIR for python3-distro would be likely to be acceptable?
<doko> dja: it's a simple module, why not. but then, why would you add that in a package? sic ...
<dja> doko: walinuxgent gets info about the distro to configure itself properly. The python standard library is dropping the functions that walinuxagent uses, and python3-distro is the what they want to use to replace it.
<dja> they raised a support case with us - the proposed pull request is https://github.com/Azure/WALinuxAgent/pull/1036 and they wanted to know if that approach would work for us
<doko> dja: yes, it took me a long time to get it out of the standard library ;p
<themill> slangasek: we talked about ktikz in the context of poppler-qt4 a while back. The new qt5-only version has been released and migrated to buster now. Can you (or someone else) update bionic to that version?
<phoenix_firebrd> Hi, can a one line patch on intel vaapi driver be backported to 16.04?
<phoenix_firebrd> this is the official intel patch on the vaapi driver https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
<phoenix_firebrd> this is the bug report on the issue on the official git page https://github.com/intel/intel-vaapi-driver/issues/297
<apw> has anyone mentioned issues with encrypted disks and needing to installl libblkdev-crypto2 ?
<jbicha> apw: see LP: #1754422
<ubottu> Launchpad bug 1754422 in volume-key (Ubuntu) "[MIR] volume-key" [Undecided,Incomplete] https://launchpad.net/bugs/1754422
<apw> jbicha, should we not start recommending it too as functionality is broken without it, even if that makes it ping on the components missmatch?
<jbicha> what do you mean "broken"? is is broken compared to 17.10?
<apw> jbicha, seth just upgraded and lost the ability to mount encrypted sticks, which he had before the upgrade
<apw> jbicha, i am assuming from the upgrade list on my box, i will fall into the same hole if i hit return on the upgrade too
<apw> jbicha, i am going assume it was the libblockdev which dropped into -release on the 13-mar which was the issue
<jbicha> well it's blocked on Security review so if Seth is affected by the issue â¦ ;)
<phoenix_firebrd> Hi, can a one line patch on intel vaapi driver be backported to 16.04?
<phoenix_firebrd> this is the official intel patch on the vaapi driver https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
<phoenix_firebrd> â this is the bug report on the issue on the official git page https://github.com/intel/intel-vaapi-driver/issues/297
<juliank> I think there was some discussion about that yesterday
<juliank> tjaalton: ^
<juliank> phoenix_firebrd: generally though, asking twice in thirty minutes does not improve your chances of getting an answer.
<tjaalton> needs an sru bug too
<phoenix_firebrd> juliank: I do not intend to , but I was trying to talk to the active persons here
<apw> jbicha, that seems backwards, but hey
<phoenix_firebrd> juliank: were you tell me that there discussions regarding the bug I addressed?
<juliank> phoenix_firebrd: just because some people talk about different things does not mean they want to talk about your thing. IRC is a slow medium
<juliank> phoenix_firebrd: I think so, there was a lot of chatter about i965-va-driver yesterday
<phoenix_firebrd> juliank: wow, thats great
<tjaalton> but not about this
<tjaalton> bionic
<juliank> I did see a link to it somewhere :D
<tjaalton> which I just uploaded
<juliank> was it in #debian-devel?
<tjaalton> that too :)
<tjaalton> and #ubuntu-release
<phoenix_firebrd> tjaalton: ya, I updated the bug report and I had been pushing for that for a long time
<tjaalton> it's all over the place
<juliank> that's https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756459 I think?
<ubottu> Launchpad bug 1756459 in intel-vaapi-driver (Ubuntu) "VP9 hardware decoding broken in 17.10, displaying corrupted images in frames while playing videos" [Undecided,New]
<phoenix_firebrd> juliank: ya that one's mine
<phoenix_firebrd> juliank: also I updated another one pointing to 18.04
<phoenix_firebrd> juliank: https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756380
<ubottu> Launchpad bug 1756380 in intel-vaapi-driver (Ubuntu) "vaapi VP9 hardware decoding not working anymore in bionic" [Undecided,Confirmed]
<phoenix_firebrd> tjaalton: thanks for the channel names, I missed those
<tjaalton> my upload to bionic fixes 1756380
<phoenix_firebrd> tjaalton: uploaded?
<tjaalton> https://launchpad.net/ubuntu/+source/intel-vaapi-driver/2.1.0-0ubuntu1
 * juliank marked the bug as fix committed to keep track of things
<phoenix_firebrd> tjaalton: what about backporting a one line patch to 16.04 so that the vlc devs can rebuilt their vlc snap and the bug is gone?
<tjaalton> phoenix_firebrd: your bug only mentions 17.10
<juliank> xenial runs 1.7, and that's what snaps use
<juliank> (xenial)
<juliank> So if the VLC developers ship 1.8 in their snap they have to fix it themselves
<phoenix_firebrd> tjaalton: aweosme work about fixing bug on 18.04, thank you so much
<juliank> unless 1.7 is affected too
<jbicha> apw: adding the recommends without the approved mir isn't a very good workaround because my understanding is that it will fix the problem for upgraders but not for new installs from now on
<juliank> and they use that
<tjaalton> I need to run now, but the bug needs to be properly targeted
<tjaalton> and with a SRU header etc so that it won't get rejected from the queue once sponsored etc
<juliank> phoenix_firebrd: Please figure out which versions are affected, and provide test cases and stuff according to https://wiki.ubuntu.com/StableReleaseUpdates
<eoli3n> Hi
<eoli3n> i'm searching for the path of "ubuntu 16.04 LTS" logo printed on 16.04 unity greeter please -> https://ptpb.pw/Qu0L.png
<phoenix_firebrd> juliank: tjaalton can you people come to #videolan for a min, we will talk to a dev there? I said I will come back to him/her after talking to you people? You people together talk to and come to a solution
<manuelschneid3r> is this the correct channel for 1804 dicussions?
<Faux> No, #ubuntu+1.
 * thresh waves
<phoenix_firebrd> tjaalton: juliank, thresh is a videolan developer. I would like you guys to discuss about backporting a driver patch to 16.04
<phoenix_firebrd> tjaalton: juliank thresh â this is the bug report on the issue on the official git page https://github.com/intel/intel-vaapi-driver/issues/297
<phoenix_firebrd> tjaalton: juliank thresh â this is the official intel patch on the vaapi driver https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
 * juliank preparing lunch. will be back in ~5min
<phoenix_firebrd> thresh would like to have you guys backport the above one line patch so that he can rebuild the vlc snap with the fixed driver
<juliank> phoenix_firebrd: thresh: As explained before, we need to know which versions are affected. The bug only talks about artful (1.8), but snaps are built from xenial (1.7).
<juliank> And apart from figuring out which releases are affected, we need test cases to verify that the uploads fix the bug
<juliank> which is all documented in https://wiki.ubuntu.com/StableReleaseUpdates
<phoenix_firebrd> do any of you guys have an intel kabylake processor or newer?
<thresh> I don't
<juliank> I have the lasted and greatest i5-8250u
<juliank> :D
<phoenix_firebrd> juliank: does it have VP9 decoding profile?
<thresh> (still waiting for Lenovo to start selling T480 here)
<juliank> phoenix_firebrd: I have no idea
<phoenix_firebrd> juliank: vainfo?
<phoenix_firebrd> juliank: If it supports, can you try playing a downloaded youtube video(or any video encoded in VP9 codec) using vlc snap?
<juliank> does not say anything about vp9 right now, but might need the just uploaded fix (I'm on bionic) - but then it works anyway
<phoenix_firebrd> juliank:  can you try playing a downloaded youtube video(or any video encoded in VP9 codec) using vlc snap?
<juliank> But its HD620 should support it
<Laney> eoli3n: it's generated in unity-greeter itself
<Laney> ends up as /usr/share/unity-greeter/logo.png but look at debian/rules
<Laney> if you're talking about updating it for 18.04, I think Trevinho has a merge proposal for that
<phoenix_firebrd> juliank: I checked the intel page and also the wikipedia page, yours is a kabylake processor and it supports VP9 profile
<eoli3n> thx Laney i migrated to slick-greeter on 18.04 daylibuild
<Trevinho> Laney: it should be landed no?
<Laney> nope
<Laney> one of the mps wasn't approved
<Laney> going now
<eoli3n> is there anyway to generate it outside of unity-greeter, which will probably disapear ?
<eoli3n> by the way, slick-greeter is far away better
<eoli3n> i can configure with a single conf file
<juliank> phoenix_firebrd: probably have to switch from wayland to xorg, because it fails with libva error: va_getDriverName() failed with operation failed,driver_name=i965
<Laney> you can get the program that unity-greeter uses from its source probably
<jbicha> eoli3n: Unity requires unity-greeter for its lockscreen I believe
<Trevinho> Laney: ah ok.. I thought you already published it :-P
<Laney> I did but it failed and I didn't notice
<eoli3n> jbicha: unity is dead
<juliank> In any case a snap is not a valid reproducer for an SRU, we need to validate it some other way anyway
<eoli3n> that was my ansible role to configure unity-greeter.... -> https://ptpb.pw/2Vep
<eoli3n> what a mess
<phoenix_firebrd> juliank: you get that error in vlc or on your host?
<jbicha> eoli3n: in that case, why don't you use gdm3?
<juliank> phoenix_firebrd: that's the snap
<juliank> phoenix_firebrd: host fails with [00007fac7002f150] vaapi generic error: profile(19) is not supported
<phoenix_firebrd> juliank: ok, I will test the patch on the 1.7 version of the driver in 16.04
<juliank> because broken vaapi driver :D
<eoli3n> jbicha: because i don't want to reconfigure entire display manager before 18.04 official release
<eoli3n> i will probably
<eoli3n> but not for now
<jbicha> Trevinho: you might need something like https://github.com/ArcticaProject/arctica-greeter/pull/9 (if you didn't already fix that issue)
<phoenix_firebrd> juliank: thats the current bug
<juliank> yeah
<phoenix_firebrd> juliank: when will the daily iso reflect the fix?
<Trevinho> jbicha: that's already fixed
<juliank> phoenix_firebrd: first it needs to migrate out of proposed to release, not sure if there are tests to run
<juliank> if not, it should be pretty fast.
<juliank> not sure when the images are built, but within the next 2 days?
<phoenix_firebrd> juliank: ok. If i test the said patch with the 16.04 and update it in a bug report, is there a possibility that it will be backported to 16.04?
<phoenix_firebrd> juliank: ok
<phoenix_firebrd> thresh: a question was raised that why not the vlc team instead use a patched driver, who do you say?
<phoenix_firebrd> *what do you say?
<cpaelzer> bdrung: any updates on bug 1753938 - there was a reply yesterday which looked more like a nack still
<ubottu> bug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/1753938
<jbicha> didrocks: I'd like to flip the order of the installer screen https://thishosting.rocks/wp-content/uploads/2017/12/ubuntu-18-04-minimal-installation.jpg
<jbicha> to put Download updates at the top (since it's pre-checked), then Install third-party software, then Minimal installation, what do you think?
<didrocks> jbicha: something to discuss with mpt, but I think it makes sense
<didrocks> jbicha: I would rather be personnaly go with that order: download updates/minimal/3rd party
<didrocks> jbicha: also, ask the kubuntu teams to potentially have the same order there
<thresh> phoenix_firebrd, I'm not going to build a patch just for that, it's up to Ubuntu to fix it upstream
<thresh> s/build a patch/build a driver/
<jbicha> I'm fine with that order too
<juliank> phoenix_firebrd: please read the wiki page I linked twice and try to follow the layout. I can
<juliank> phoenix_firebrd: We can do that too, worst case, but at least figure out that both 16.04 and 17.10 are affected
<juliank> [00007fac7002f150] vaapi generic error: profile(19) is not supported
<juliank> mpv https://upload.wikimedia.org/wikipedia/commons/8/88/Big_Buck_Bunny_alt.webm
<juliank> is a simple test case for me
<phoenix_firebrd> juliank: I am very sure it affects 17.10 and I tested the patch too
<juliank> same with vlc, but that gets other issues
<phoenix_firebrd> juliank: that bug report on bug affecting 17.10 was created by me
<juliank> that's not the point
<juliank> the point is to figure out whether 16.04 is affected
<juliank> the bug only talks about 17.10 and 1.8
<juliank> again, xenial ships 1.7
<phoenix_firebrd> juliank: ok I will check that out, I will be back with the result later
<juliank> Most importantly, we need a test file/link to check against
<phoenix_firebrd> juliank: tjaalton thresh thanks a lot you people
<mpt> jbicha, making minimal install a checkbox introduces the problem âAs opposed to what?â What happens when someone leaves it unchecked? Moving the checkbox doesnât solve that problem. Thatâs why I designed it as a pair of ratio buttons instead. <https://goo.gl/DqtvZL>
<mpt> *radio buttons
<juliank> thresh: don't you want to upgrade the vaapi driver to 2.1 or something anyway to get support for cannonlake? Or just wait for the 18.04 core and rebase on that?
<juliank> I guess there's still time :D
<jbicha> mpt: ok, that would be a bit better. The current implementation feels to me like it strongly suggests the Minimal installation which I didn't think was our intent
<mpt> jbicha, agreed
<didrocks> jbicha: are you going to change it to this?
<jbicha> it's on my to-do list to take a look at it, yes
<thresh> juliank, I cant upgrade to anything newer than 16.04, or my snaps won't be accepted to snap store.
<thresh> juliank, I can wait for 18.04, but that's going to take at least half a year, and very likely more than that, for snap core to get 18.04 there.
<juliank> I was just curious about cannonlake :D
<juliank> but it's still basically a year to go, so by then that should be ready and we focus on fixing VP9 now :-)
<ogra_> thresh, you are completely neglecting the advantage of snaps with that ... the good thing about snbaps is that you definitely can do such stuff (and should)
<rbasak> thresh: I build snaps in a container, so the release installed on my host doesn't matter.
<juliank> thresh: Basically my question is how you want to deal with new hardware that requires newer vaapi drivers in the snap than there exist in the archive. cannonlake end of this year is one example, can probably base snaps on 18.04 by then; but icelake in 2019 might need another driver update. It's something to think about now-ish rather than when it happens
<ogra_> thresh, (talking about the "i wont build my own driver" )
<Mirv> my guess was that since vlc snap already includes self-compiled whole Qt 5.10, compiling newer libva + i965-va-driver as well would not be a bad idea for the snap
<juliank> I don't have any problem with them not building their own driver, but then someone likely needs to do hwe updates for vaapi drivers
<thresh> ogra_, with what?
<juliank> it might be worthwhile anyway :)
<thresh> rbasak, me too, I don't even run Ubuntu on a host that build snaps.
<Mirv> hwe updates for vaapi drivers otoh is not a bad idea either, although it's probably not happening for 18.04 either as it's soon finished
<thresh> juliank, I rely on Ubuntu to ship fixed stuff for that.
<ogra_> thresh, with the "i wont build my own driver" ... this is exactly what snaps offer you ... add another part to your snapcraft.yaml and you can have a better driver than the distro
<Mirv> since many apps will use the non-snap base distro drivers
<thresh> ogra_, I didnt say I *cant*, I just *wont*, because it's not my bug.
<thresh> it's for Ubuntu to fix their packages.
<thresh> Seriosly.
<thresh> +u
<juliank> thresh: currently there are no updates for new hardware, so e.g. no coffee lake for 16.04.
<juliank> that's all I am saying.
<juliank> It's likely that someone needs to step up and come up with a plan for that and take care of it :)
<ogra_> thresh, and they will be fixed, but until then you will have whining users that you could perhaps quieten with 5 lines of yaml ...
<thresh> I understand that, and I think someone on HWE team needs to think about that.
<thresh> ogra_, it's OK.  I cant fix all bugs instantly, but I cant ship something I can not test.
<ogra_> i.e. take a look at https://github.com/3v1n0/telegram-snap/blob/master/snapcraft.yaml ... that doesnt use a single deb for building its binary
<ogra_> well, phoenix_firebrd_ can test for you :)
<juliank> Well, intel-vaapi-driver is in universe and not supported :)
<juliank> I guess
<ogra_> and there is forum.snapcraft.io with 100s of users that will happily help testing if you file a request
<juliank> ogra_: they do
<ogra_> yeah
<juliank> ogra_: there are some build-packages in there
<juliank> for example,       - libappindicator3-dev
<ogra_> yeah, indeed ...
<ogra_> they wouldnt need to though :)
<ogra_> my point is that snaps allow you an actual archlinux approach (build everything from upstream) without being bound to any distro release ... isf you actually want
<ogra_> *if
<Mirv> thresh: it's just likely that Ubuntu won't have timely va api driver updates until 2020 at least, since 18.04 LTS is about to be wrapped and its HWE enablement does not include the drivers, and the drivers are only community maintained at the moment. so the choice is of course free, but vlc snap users would be happier with hw acceleration naturally in the coming years.
<thresh> So maybe they should be maintained by a company, then.
<Mirv> with 18.04 as the basis for snap build in half a year would bump of course hw acceleration support momentarily, but then it would start to lag soon until 20.04 LTS
<thresh> It's a basic hardware feature these days, it's not 2005 anymore where we could get away with CPU.
<juliank> of course you can get away with CPU :D
<juliank> That's what the browsers do
<Mirv> thresh: yes, it would be ideal, but as said it's not happening until 2020 at the current rate, so pragmatically speaking users will get a bit subpar experience - although as noted, it will get better when 18.04 LTS can be used as a base until again new CPUs come out
<thresh> I understand that.
<ogra_> well, i'm running 16.04 on a kabylake here ... i cant get vaapi at all on the normal distro ... the vlc 3.0 snap helps a lot here
<juliank> ogra_: how?
<ogra_> (i cant enable vaapi witrh the deb but it works well with the 3.0 snap)
<juliank> that's odd
<Mirv> I've manually upgraded to 1.8.2 on my 16.04 LTS to get a bit fresher experience
<ogra_> juliank, by switching to it in the vlc settings
<juliank> ogra_: I meant, why can't you get that in the deb? The vaapi driver in the snap is the same
<ogra_> juliank, "basic" vaapi works fine, i think it is just vp9 thats not working
<Mirv> ogra_: weird though, since the vlc 3.0 snap has the original 16.04 1.7 va-api drivers
<Mirv> I don't think that can have kaby lake support for about anything
<ogra_> Mirv, that i could never get to work right on any of my machines from the archive
<juliank> Mirv: I don't think anybody is preventing anyone from doing the work in 18.04 (or 16.04) and doing a intel-vaapi-driver-hwe package.
<juliank> right?
<juliank> or intel-vaapi-driver-community-hwe, whatever
<Mirv> ogra_: juliank: ah, funny, the 1.7.0 from 15 Mar 2016 did actually add the very first kaby lake support - quite early!
<thresh> juliank, browsers are exactly the opposite of what I could ever call a sane thing :)
<Mirv> so aside from being buggy and lacking codec support, it's actually supported there, only coffeelake isn't
<juliank> All I want is vaapi support in chrome
<juliank> and proper mpv windows
<ogra_> juliank, Mirv https://paste.ubuntu.com/p/M8gyv4jDrc/
<Mirv> juliank: well, feature freeze for one prevents such a landing in 18.04, and adding such after a release is done is maybe unlikely with any process
<Mirv> so hence my "probably 2020"
<ogra_> (just streaming Tv frm my kodi box though ... no fancy codecs or anything)
<Mirv> ogra_: nice! I upgraded to get some VP9 10-bit decoding functional
<ogra_> probably the log lies ... but the CPU utilization is definitely less than with the vlc deb
<juliank> I switched from vlc to mpv some time ago
<juliank> That was the only player I got working in wayland usably I think
<juliank> ugh, word order
<Mirv> ogra_: right, the original VLC xenial version compiled with only VDPAU, not VAAPI support, even if the va-api drivers would have been recent enough
<ogra_> yeah
<thresh> ugh, wayland.
<thresh> there is a remote chance that VLC from edge snap channel might work under wayland.
<ogra_> well, xorg is around for another 5 years at least :)
<ogra_> (thanks to 18.04 defaulting to it)
<juliank> thresh: Well it works completely fine, but via Xwayland, so some perofrmance loss I guess.
<juliank> ogra_: pff, I'll be on 18.10 sooon
<ogra_> crazy
 * ogra_ will stay on 16.04 until a proper unity replacement comes around :P
<juliank> ogra_: Gotta run devel so I notice if stuff breaks
<ogra_> yeah
<juliank> :D
<ogra_> i know ... i used to be in foundations :)
<juliank> :D
<ogra_> snaps kind of changed my habit ... and dropping unity too
<juliank> Basically the same on my Debian machine - it runs testing.
<ogra_> (i tried gnome for nearly a year but eventually going back to unity felt like coming home=
<slangasek> themill: kitkz synced
<juliank> (it used to be unstable, but um it's secondary now, so it's running testing)
<juliank> ogra_: I have not used unity a lot.
<ogra_> i did since day one
<juliank> I think my laptops all ran Debian with GNOME during the unity time
<juliank> *Debian unstable
<ogra_> to have gnome close to it regarding my use cases i have to install a gazillion of extensions that eat so much ram that it isnt worth it anymore
<juliank> I used GNOME 3 from before it was stable IIRC
<ogra_> yeah, if you like the usability of it i guess you are fine
<juliank> I think I started around 2.31 or so
<ogra_> i cant really get along with a lot there
<ginggs> ogra_: this is probably the wrong channel, but i herd you like unity :) I have 2 machines running still unity on 18.04, they suspend after 20 minutes if nobody is logged in, they didn't do this on 17.10.  any ideas?
<juliank> ginggs: sounds like a bug was fixed? ;)
<ogra_> ginggs, heh, no idea ... i'm actually sticking to 16.04 here
<ogra_> but yeah perhaps -desktop would be the better channel
<ogra_> (unless there is actually a unity dedicated channel somewhere)
<juliank> ginggs: 20 mins is the default suspend time out for gnome-power-$thingy
<juliank> Is that running?
<juliank> for the greeter
<ginggs> juliank: i can change that for a logged in user, but don't know how to change it for the greeter
<juliank> oh, ok
<juliank> you can
<juliank> like sudo to the greeter user and change it there with gsettings tool
<juliank> Although I think there are drop-in keyfiles too?
 * juliank not sure
<juliank> ginggs: are you using gdm?
<ginggs> juliank: looks like lightdm
<juliank> ok
<juliank> but I guess the idea is the same
<ginggs> juliank: thanks, i will try sudo to the greeter user
<juliank> sudo to its user and run gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
<juliank> though you might need to figure out its dbus socket
<tjaalton> Mirv: intel-vaapi-driver could probably just be backported like mesa is, unrenamed
<tjaalton> now that it's actually used almost by default
<nacc> juliank: tjaalton: shouldn't LP: #1756549 just be duped to LP: #1756380 ?
<ubottu> Error: Launchpad bug 1756549 could not be found
<ubottu> Launchpad bug 1756380 in intel-vaapi-driver (Ubuntu) "vaapi VP9 hardware decoding not working anymore in bionic" [Undecided,Fix released] https://launchpad.net/bugs/1756380
<nacc> and maybe LP: #1751492
<ubottu> Launchpad bug 1751492 in intel-vaapi-driver (Ubuntu) "VAAPI encoding is broken in Skylake" [Undecided,New] https://launchpad.net/bugs/1751492
<tjaalton> 1751492 is probably a bug in mesa
<juliank> nacc: one is about shader stuff, the other about a tiny bugfix
<juliank> nacc: ah no
<nacc> juliank: i think they are the same
<nacc> this was the annoying user :)
<juliank> nacc: tghe other is GPU hang
<tjaalton> 1756549 not found
<juliank> 1751492 => it works, but hangs the GPU
<nacc> one sec
<juliank> bug 1751492 => it works, but hangs the GPU
<ubottu> bug 1751492 in intel-vaapi-driver (Ubuntu) "VAAPI encoding is broken in Skylake" [Undecided,New] https://launchpad.net/bugs/1751492
<juliank> bug 1756380 => does not work, missing shaders
<ubottu> bug 1756380 in intel-vaapi-driver (Ubuntu) "vaapi VP9 hardware decoding not working anymore in bionic" [Undecided,Fix released] https://launchpad.net/bugs/1756380
<tjaalton> well, encoding needs the shaders, doubt he had those installed
<nacc> tjaalton: also, supposedly this affects the core snap
<nacc> sdupposedly
<nacc> i'll ping the snap folks
<juliank> nacc: it does not
<juliank> that's just silly
<nacc> juliank: ok, supposedly the vlc snap says it does
<nacc> juliank: as in, it doesn't work ... but i don't know why the user said that
<nacc> it's in a few of the bugs and that's what they've said on IRC a few times
<juliank> nacc: it does not work, sure, but it's not in there core snap, they ship the driver from the deb
<juliank> they install the driver deb into their snap
<nacc> juliank: not sure how that would be broken, given it works on xenial?
<nacc> juliank: unless they took a different deb?
<nacc> again, just my understanding
<juliank> who said it works on xenial?
<nacc> juliank: that user, again
<nacc> juliank: it was broken in 1.8.x
<tjaalton> which bug# was that?
<nacc> LP: #1756380 comment 1
<ubottu> Launchpad bug 1756380 in intel-vaapi-driver (Ubuntu) "vaapi VP9 hardware decoding not working anymore in bionic" [Undecided,Fix released] https://launchpad.net/bugs/1756380
<juliank> it was broken in a kernel update >= 4.13
<tjaalton> ah, so just trying to hijack a bug
<juliank> nacc: he's also talking about a completely different bug :)
<juliank> https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756459
<ubottu> Launchpad bug 1756459 in intel-vaapi-driver (Ubuntu Artful) "VP9 hardware decoding broken in 17.10, displaying corrupted images in frames while playing videos" [Undecided,New]
<juliank> nacc: if you read the backlog you'll see that I asked him to clarify that
<nacc> juliank: ok, well, he duped the text, so i'm not sure how i'd know that :)
<nacc> juliank: tjaalton: but as long as you two have a handle on it, i'll drop it
<tjaalton> yeah I think it'll calm down now, at least for bionic..
<nacc> tjaalton: thanks
<tsimonq2> bdmurray: Could I please get a review on this so kdesudo can be removed? https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/34155
<tsimonq2> ugh
<tsimonq2> https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/341555
<tsimonq2> that
<bdmurray> tsimonq2: commented
<tsimonq2> Thanks bdmurray.
<Mirv> tjaalton: oh, right..
<sunweaver> flexiondotorg: <others>: can you tell me what the status of notify-osd in Ubuntu is?
<sunweaver> tsimonq2: ^
<sunweaver> is it actively used in Ubuntu Desktop 18.04?
<tsimonq2> sunweaver: seeded-in-ubuntu :)
<sunweaver> ...means what?
<tsimonq2> sunweaver: Otherwise, try #ubuntu-desktop
<tsimonq2> sunweaver: It's a script
 * sunweaver starts browsing the code...
<sunweaver> tsimonq2: urgh, no... https://bazaar.launchpad.net/~indicator-applet-developers/notify-osd/trunk/files/head:/src/
<Odd_Bloke> sunweaver: I believe seeded-in-ubuntu is the script, which will tell you what notify-osd's status is.
<sunweaver> ah.
 * sunweaver changes to his bionic chroot.
<Odd_Bloke> (It's in ubuntu-dev-tools.)
 * sunweaver was wondering exactly that...
<tsimonq2> Right.
<sunweaver> it is not seeded...
<sunweaver> means, it is not used in the official set of packages, right?
 * sunweaver is more wondering about... is it still maintained as an upstream project?
<sunweaver> is it part of a Unity7 installation?
<jbicha> sunweaver: yes (I find reverse-depends to be a more useful tool here)
<jbicha> yes, it's installed by the Unity metapackage
<sunweaver> jbicha: and XDG_CURRENT_DESKTOP is Unity7 right now, not Unity anymore?
<jbicha> it's probably as well maintained as the rest of the Unity stack
<sunweaver> ok.
<sunweaver> I will update it in Debian then from bzr.
<sunweaver> is there a #unity(7) channel here on Freenode?
<jbicha> I don't have a recent Unity install to check XDG_CURRENT_DESKTOP for you
<nacc> !alis | sunweaver
<ubottu> sunweaver: Alis is an IRC service to help you find channels. For help on using it, see "/msg Alis help list" or ask in #freenode. Example usage: "/msg Alis list http"
<jbicha> sunweaver: I don't think so, you might just need to email the Unity 7 people
<sunweaver> nacc: thanks.
<sunweaver> which is this? unity7maintainers@lists.launchpad.net
<TJ-> Do we have any policykit hackers? On 16.04 at least it looks like the /etc/polkit-1/localauthority.conf.d/ is being parsed in the wrong order, resulting in Ubuntu-shipped policy being replaced by package policy
<xnox> TJ-, sigh, maybe try #ubuntu-hardened?
<ahasenack> hi, is there any trick to build an autopkgtest image for ppc64el? I have shell on such a host, autopkgtest-buildvm-ubuntu-cloud finishes but I think it falied to run the setup scripts
<ahasenack> https://pastebin.ubuntu.com/p/DVry2CPkjr/ bits of the --verbose output
<ahasenack> where cloud-init starts to run the stuff sent via user-data
<ahasenack> [   33.414880] cloud-init[1247]: sh: 0: Can't open /mnt/setup-testbed
<ahasenack> that's the key error I think, that's supposed to be a script
<nacc> ahasenack: you might even ask in #cloud-init, possibly
<TJ-> xnox: will do... just writing up a bug report :)
<nacc> ahasenack: i'm pretty sure i've done that on a ppc64el in the past, but it was a while ago
<ahasenack> ok
<ahasenack> at this stage I think the problem is bad assumptions made by the autopkgtest-buildvm-ubuntu-cloud script
<ahasenack> not strictly a cloud-init problem
 * ahasenack adds some debugging to that user-data
<ahasenack> cpaelzer probably knows, I'll ask him tomorrow
<ahasenack> nacc: hah, got it
<ahasenack> nacc: for some reason, vda and vdb are swapped
<ahasenack> vdb is the boot disk not vda
<nacc> ahasenack: weird
<ahasenack> the autopkgtest script assumed the non-boot disk would be vdb
<ahasenack> runcmd:
<ahasenack>  - sed -i 's/deb-systemd-invoke/true/' /var/lib/dpkg/info/cloud-init.prerm
<ahasenack>  - mount -r /dev/vda /mnt
<ahasenack> I changed that mount to vda (as displayed) and it's working now
<ahasenack> it was vdb
<ahasenack> now, other things failed :/
<ahasenack> [   55.637935] cloud-init[1285]: E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic/main/binary-ppc64el/Packages  404  Not Found [IP: 10.245.71.3 8000]
<ahasenack> but baby steps
<nacc> ahasenack: that seems like maybe it's trying to use an apt proxy?
<ahasenack> yeah, but that url is indeed a 404
<ahasenack> I tried from home just now
<ahasenack> are ppc packages elsewhere? ports.u.c perhaps?
<ahasenack> yep
<ahasenack> :/
<ahasenack> ahasenack@diamond:~â« cat /etc/apt/sources.list
<ahasenack> deb http://ports.ubuntu.com//ubuntu-ports/ xenial main restricted universe multiverse
<ahasenack> let's see
<ahasenack> should be able to set a mirror
<nacc> http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/binary-ppc64el/
<nacc> ahasenack: yeah, but that's weird that it wasn't done correclty to start
<nacc> ahasenack: -m option to buildvm-ubuntu-cloud
<ahasenack> yep
<ahasenack> am trying that now with your url
<ahasenack> i.e., http://ports.ubuntu.com/ubuntu-ports
<nacc> yeah
<nacc> it's weird, i woudl think if it's arch specific like that, autopkgtest would know about it
<nacc> that feels like a bug (to me)
<ahasenack> why are some arches in ports.u.c?
<ahasenack> i386/amd64 are on the same url
<nacc> ahasenack: i don't know; perhaps slangasek can tell us?
<slangasek> because the volume of downloads for !x86 arches does not justify distributing them from the primary mirror network
<nacc> slangasek: good answer
<ahasenack> [   48.513705] cloud-init[1290]: Fetched 3640 kB in 1s (3325 kB/s)
<ahasenack> nacc: worked now
<nacc> ahasenack: nice
<ahasenack> nacc: still getting this though, when starting the actual test run
<ahasenack> <VirtSubproc>: failure: The VM does not start a root shell on ttyS1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0
<ahasenack> I'll ping cpaelzer tomorrow
<nacc> ahasenack: yeah, i don't know what that means, or what is detecting that
<ahasenack> I believe it's failing to find a way to login
<ahasenack> setup-testbed might set that up somehow
<ahasenack> anyway
<ahasenack> that's a big shell script
<nacc> ahasenack: yeah is that still not running?
<ahasenack> no, it fails somewhat quickly
<ahasenack> I can try to bring a vm up on that image myself
<ahasenack> hah
<ahasenack> from the setup script
<ahasenack> # set up init script for root shell on ttyS1; necessary for autopkgtest-virt-qemu local
<ahasenack> # images
<ahasenack> and then it sets up a sysv initscript
<ahasenack> looks like I can't resist it
 * ahasenack debugs some more
<nacc> ahasenack: :)
<tsimonq2> bdmurray: Am I missing something or has DistUpgrade/DistUpgradeFetcherKDE.py already been fixed? https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/341555
<bdmurray> tsimonq2: I believe you are missing something - https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeFetcherKDE.py#L134
<tsimonq2> bdmurray: Are you sure we're looking at the same thing? That says pkexec.
<tsimonq2> On my branch it does, at least.
<bdmurray> Hmm well okay great. I must have missed that.
<tsimonq2> Cool. :)
<tsimonq2> Otherwise it looks good?
<bdmurray> Yes
<tsimonq2> Excellent.
<tsimonq2> bdmurray: Sorry if I'm just being impatient but I need a merge + upload. :)
#ubuntu-devel 2018-03-21
<cpaelzer> ahasenack: only saw this now, already answered on #server
<cpaelzer> slangasek: the bump to bridge-utils 1.5.9ubuntu2 to 1.5.15ubuntu1 https://launchpad.net/ubuntu/+source/bridge-utils
<cpaelzer> slangasek: made it having Conflicts: ifupdown (<< 0.8.17)
<cpaelzer> but that is https://launchpad.net/ubuntu/+source/ifupdown not available in Ubuntu
<cpaelzer> just relaized that this on a dist-upgrade made me having
<cpaelzer> The following packages will be REMOVED:
<cpaelzer>    ifenslave ifupdown
<cpaelzer> so it effectively became mutually exclusive until ifupdown is updated as well
<cpaelzer> slangasek: Intentional (I don't think so) or is a new ifupdown already being made?
<cpaelzer> xnox: ^^ as your TZ is much closer, if you know some team-plans on this let me know
<rbasak> bdmurray: could you glance at bug 1623125 please/ What are your SRU verification expectations there for Artful?
<ubottu> bug 1623125 in initramfs-tools-ubuntu-core (Ubuntu Artful) "fixrtc script does not catch "Last mount time: n/a" string" [Undecided,New] https://launchpad.net/bugs/1623125
<ahasenack> Laney: hi, do you have the secret sauce somewhere that preps ppc64 images for autopkgtest? I'm hitting https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1630909
<ubottu> Launchpad bug 1630909 in autopkgtest (Ubuntu) "failing console access on s390x, ppc64el" [Undecided,Confirmed]
<ahasenack> or it "just works" with the ppc cloud images we have?
<Laney> ahasenack: I don't know that anyone has ever tried it with qemu like that
<Laney> We boot a cloud image and then do things to it over SSH
<ahasenack> Laney: how does it get console access in the cloud case? ssh?
<ahasenack> ah
<xnox> ahasenack, to be honest, i believe locally we should stop using -- qemu provider too; and instead use ssh setup as well.
<xnox> ahasenack, and like use $ multipass launch bionic; and use multipass shell into it.
<Laney> that'd be good, SSH setup scripts all over
<xnox> or lxd, but again with ssh.
<xnox> or uvt-launch thing, again with ssh.
<ahasenack> Laney: xnox: I'll try ssh
<ahasenack> that might be better also because it's how migrations use it, and the bug I'm trying to reproduce is happening only there so far
 * rbasak looks forward to xnox writing an openssh dep8 test :-)
<cjwatson> there is one already?
<xnox> http://autopkgtest.ubuntu.com/packages/openssh ?
<rbasak> I mean in terms of using ssh to get to autopkgtest hosts as above.
<rbasak> Will that not interfere?
<xnox> you know you can start a second server....
<xnox> plus we have cloud image testing framework which tests that "ssh comes up" and "is available on default ports" with the "right keys" every day, on all releases =)
<cjwatson> openssh's regression tests start a server on a high port
<rbasak> My point is that you have to special case handling for that in the test because of the test environment, which is ugly, and probably the reason pitti did it via qemu where possible in the first place.
<xnox> that was not the reason at all.
<cjwatson> they won't care about sshd running on the host
<rbasak> cjwatson: a openssh dep8 test might reasonably want to check that installing openssh-server results in a listening daemon on the default port.
<xnox> at first tests were in schroot; then in lxd/lxc containers; then qemu - to break testbed, which became inflexible and unreliable; then started to use the cloud - because that gives one a "machine" more reliably.
<cjwatson> rbasak: I think you need a better example, because as the openssh maintainer I'm not going to do that precisely because it would be bloody awkward :)
<rbasak> Sorry. I didn't mean to suggest that xnox's suggestion was necessarily bad. Just that it results in some reasonable-to-write tests being awkward to write!
<xnox> rbasak, it doesn't, and at the end of the day the cloud test bed is a lot better than the qemu provider one.
<rbasak> It really depends on what you're trying to test.
<cjwatson> that sort of thing would be awkward for other reasons - it's often useful to be able to debug autopkgtests in ad-hoc environments, where in practice sshd is very often running
<xnox> rbasak, and specifically, src:systemd tests used to pass in qemu runner; but not over ssh; due to logind killing and closing ssh connections prematurely due to to systemd regression =/
<cjwatson> so this is already a thing that in practice one wants to avoid
<xnox> that was not at all fun to chase down.
<rbasak> That's the sort of thing I mean.
<rbasak> In those cases, the qemu running is clearly better.
<rbasak> runner
<xnox> that's not what we can use in production
<cjwatson> if I were writing a "does installing openssh-server start the server usefully" test then I'd nobble the port.
<cjwatson> it's just not pragmatic otherwise.
<rbasak> The more infrastructure there is in the guest for the sake of the test execution environment, the less we can effectively test the low level stuff.
<rbasak> I'm just saying there's a downside to using cloud images for autopkgtest.
<rbasak> Not that we shouldn't do it that way in general.
<cjwatson> I think in practice this is already a downside that tests have to assume is a possibility.
<rbasak> I'm not sure if it's worth the effort, but a dep8 Restriction to say "really I need qemu" might be reasonable.
<rbasak> (well, not "no qemu" specifically, but "as pure an environment as possible")
<rbasak> (well, not "qemu" specifically, but "as pure an environment as possible")
<xnox> we used to run tests on phones and tablets, bare metal, with provisioning over ADT
<xnox> i beleive there is a MAAS runner too (or maybe I am imagining things)
<xnox> in practice, we do not have infrastructure to run tests on smaller guest assist than we currently do.
<xnox> it's not just the console access; we also need ability to transfer files in and out of an instance, to collect artefacts and push files onto it.
<xnox> using serial tty + an assistance VM to mount the disk on, could be a cloud solution, but that would increase our quota usage per test.
<xnox> rbasak, there have been suggestions to use lxd containers runner for !isolation-machine tests, because it's faster and most things do not need full thing (e.g. most of ruby/php/perl/python tests)
<xnox> with lxd runner, you can have a lot less things running inside the guest, as one has direct filesystem access & out of bound shell
<rbasak> Makes sense
<rbasak> Assuming it works.
<rbasak> The s390x environment change had quite a bit of fallout :-/
<rbasak> Do we have any policy / extra thoughts on conffile changes in SRUs?
<rbasak> bug 1661869 seems reasonable to me. The point of the SRU would be to change conffiles though.
<ubottu> bug 1661869 in avahi (Ubuntu Artful) "maas install fails inside of a 16.04 lxd container due to avahi problems" [Medium,In progress] https://launchpad.net/bugs/1661869
<xnox> rbasak, well, only in status. It used to be "SKIP" which britney interpreted as "PASS", and britney got all confused when "SKIP" -> "FAIL"
<xnox> an oversight in britney to not account for "SKIP" state
<mdeslaur> slangasek: mind if I merge python-django?
<rbasak> sil2100: I'm looking at bug 1466926. I had some concerns and then read your comment that confirmed my thoughts. I'd appreciate your opinion given the responses to your comment.
<ubottu> bug 1466926 in apache2 (Ubuntu Xenial) "reload apache2 with mpm_event cause scoreboard is full" [Undecided,In progress] https://launchpad.net/bugs/1466926
<rbasak> It seems to me that we should accept the SRU, but we need to take extra care. Do you agree, and any thoughts on what we could do to mitigate please?
<rbasak> cpaelzer: FYI ^
<rbasak> Any opinion on a wholesale update to 2.4.29 for example, if everything in http://www.apache.org/dist/httpd/CHANGES_2.4 sounds acceptable to SRU?
<rbasak> Would that reduce or increase the risk do you think?
 * rbasak goes to get lunch
<cpaelzer> rbasak: the feedback I read ont he bug so far seemed to answer the question sil2100 had - => yes it is important
<cpaelzer> I haven't looked at all at doing a while minor release update
<cpaelzer> I thought SRU-wise unless under MRE we prefer backporting the actual fix
<cpaelzer> 2.4.18->2.4.29 sounds a lot (too much IMHO)
<rbasak> cpaelzer: we don't have strictly have MREs any more, though we do use the same quality criteria as before. If the changes are all acceptable for an SRU and we are confident about the quality then we can do it.
<rbasak> cpaelzer: I ask because for a more complex change, if there are interactions with the rest of the codebase we don't understand well, then we might be taking less risk taking all upstream changes, IYSWIM.
<rbasak> cpaelzer: depends on how deeply we understand this diff.
<rbasak> But yeah it's a trade-off against regressions caused by other changes.
<rbasak> I wondered where how you ad sil2100 judge this.
<rbasak> I wondered how you and sil2100 judge this.
<rbasak> juliank: based on https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1750465/comments/10, are you suggesting I should hold on processing slangasek's SRU upload?
<ubottu> Launchpad bug 1750465 in plymouth (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,In progress]
<juliank> rbasak: I'm not sure what he did precisely, I only saw the bug messages.
<rbasak> juliank: http://launchpadlibrarian.net/361447927/plymouth_0.9.2-3ubuntu17_0.9.2-3ubuntu18.diff.gz is his artful SRU upload.
<juliank> That should be correct anyway.
<juliank> And it probably fixes the bug even if we don't know the exact reason yet...
<rbasak> OK. If you and slangasek both agree on what we should land, I'm happy :)
<rbasak> I'll accept assuming all the other SRU bits look OK.
<rbasak> Thank you for looking
<sil2100> rbasak: well, I didn't judge anything, I mean this SRU just felt a bit risky considering the merits
<sil2100> rbasak: to me this SRU was still undecided
<sil2100> rbasak: but when I looked at it back then I was leaning more into the reject territory - although I didn't see the later comments yet
<rbasak> sil2100: sure, I got that part. By "judge" I'm asking for your opinion now :)
<mdeslaur> slangasek: too late
<ahasenack> Laney: hi, I pushed another gvfs build to https://launchpad.net/~ahasenack/+archive/ubuntu/gvfs-test-fixes-1713098/+packages with the FORCE flag set, as suggested in the upstream bug
<Laney> ahasenack: ok, is it published?
<ahasenack> Laney: yes
<Laney> cool
<ahasenack> Laney: gvfs - 1.36.0-1ubuntu2~ppa1
<Laney> you want 10 test runs on ppc64el or something?
<ahasenack> that would be fine
<Laney> going
<slangasek> cpaelzer: sorry, I didn't notice the added conflicts.  I had not planned to merge newer ifupdown, but if there's a conflicts then we should probably look at doing so
<slangasek> mdeslaur: no objections to merging python-django, did you find one that builds better than the one already in -proposed?
<mdeslaur> slangasek: It did build, I think it was a python change that got reverted
<rbasak> xnox: why is it worth making all dovecot users download new binaries just to fix the dep8 test?
<Laney> ahasenack: https://paste.ubuntu.com/p/kNcRc4Dd3c/ looks like that worked, just one trash failure
<ahasenack> Laney: we can't be sure, we never saw the failure from ppa tests, did we?
<ahasenack> at least it didn't introduce a new error
<Laney> there's no reason it would be any different
<Laney> to the archive
<ahasenack> it's the same build farm?
<Laney> yes, it is an almost identical codepath except there's some extra stuff to set up the PPA
<ahasenack> Laney: how about this control ppa then, it's gvfs unchanged: https://launchpad.net/~ahasenack/+archive/ubuntu/unchanged-gvfs
<cpaelzer> ahasenack: that is probably the easiest one line way to get what you asked for slowing down the guest
<cpaelzer> ahasenack: sudo cpulimit -l 50 -p $(ps aux | grep $(virsh dominfo b-test | awk '/^UUID:/ {print $2}') | grep -v grep | cut -f2 -d" ")
<cpaelzer> b-test being the guest name
<cpaelzer> ahasenack: I don't expect you want to slow I/O do you?
<Laney> that PPA has a superseded version
<Laney> we have enough results for gvfs anyway no?
<cpaelzer> there is also libvirty way - but you run qemu directly right?
<cpaelzer> you can take out the inner bulk with the pid of any qemu you run
<ahasenack> Laney: yeah, it's the one from before your version bump. I can bump it to match the archive (minus ~ppaN)
<ahasenack> cpaelzer: I'm using libvirt now (uvt-kvm)
<cpaelzer> ah I see
<cpaelzer> then just a sec
<ahasenack> cpaelzer: didn't see anything about limits in virt-manager, my gui :)
<ahasenack> Laney: as we are still experimenting, it would be super if we could see the failure from a ppa build, and then the lack of failures from a ppa build (which we do already)
<sil2100> rbasak: ah! Then I misunderstood ;) I'll read up the rest and comment
<Laney> ok, if you want
<Laney> just trying to save some CO2 from the atmosphere
<cpaelzer> ahasenack: read "blkiotune" for disk and "CPU Tuning" for cpu in https://libvirt.org/formatdomain.html
<ahasenack> can you trigger it from that ppa, or the fact that it's older prevents that?
<ahasenack> cpaelzer: ok, thx
<ahasenack> the dep8 error was happening with that version as well
<cpaelzer> ahasenack: or just use my cmdline above
<cpaelzer> this is one of the cases (debuging and qucik and dirty) where it beats the complex lbivirt config
<Laney> ahasenack: it needs to be newer
<ahasenack> Laney: ok, I'll fix that
<Laney> we could just run against the archive's gvfs
<Laney> this is a bit of a waste of compute imo
<slangasek> juliank: thanks for the follow-up comment on the apt+plymouth trigger mess... why do you say that base-files must be fully configured before bash is unpacked?  I don't see that in the dependencies (bash Depends: base-files, it doesn't Pre-Depends:), and I didn't see any logs that showed this
<ahasenack> Laney: ok, would you be ok with uploading with that force patch then?
<Laney> ahasenack: to the archive?
<ahasenack> yeah
<Laney> I think you should comment upstream
<Laney> I thought it was only meant to be an experiment
<Laney> but if he decides to commit that change then we can
<juliank> slangasek: I don't say that, I say that apt configured base-files as can be seen in the log. But it probably put it into triggers-awaited state instead of installed, and plymouth-... into triggers-pending, since we configure with --no-triggers
<slangasek> juliank: ok, I didn't see that in the logs I skimmed, sorry for overlooking
<ahasenack> Laney: ok
<slangasek> juliank: but yeah, triggers-awaited or something makes sense
<ximion> doko: thank you for uploading LDC 1.8 to -proposed! I didn't dare to file a FFe for it, but having it is very beneficial
<ximion> Please tell me if there is anything I can help with (the transition in Debian so far is flawless, only libundead needed a minor change)
<jbicha> ximion: maybe you need to file a binnmu bug since ldc migrated to Testing without the rebuilds happening https://release.debian.org/transitions/html/auto-ldc.html
<nacc> slangasek: for seeding ruby, if i seed ruby-full (which depends on ruby and ruby-dev), will it be sufficient? That seems to be the upstream ruby recommendation on Ubuntu, and then we'd "simply" need to promote ruby-defaults again?
<ximion> jbicha: some packages got binNMUs... I am still not sure when I should ping the release team explicitly for a transition, sometimes they just do it automatically, and sometimes I need to file a bug
<ximion> and explicit bug is nicer in this case, I guess (only 4 more packages need to be rebuilt though)
<slangasek> nacc: you could also just seed ruby, which seems more correct semantically; and ruby-dev will be pulled in automatically by virtue of our rule that promotes associated -dev packages
<slangasek> nacc: it depends on whether ruby-full is something you want to recommend users install
<nacc> slangasek: i'm being asked specifically that ruby-full (which upstream docs) be in main (by rbasak, dpb)
<nacc> slangasek: right
<nacc> slangasek: i would prefer 'ruby' as well, as it makes more sense to me
<jbicha> ximion: the only rebuilds that happened were because new uploads were done in Debian
<jbicha> ximion: in this case a bug would help since it appears that the new "shared" naming allowed ldc to migrate to Testing when it normally wouldn't
<ximion> jbicha: agreed, I'll file one later today
<nacc> dpb1: do you want it under "Other" or should I make a new "Ruby" section? We have no other interpeters in supported-misc-servers or supported*server (which is a metaseed currently)
<dpb1> nacc: +1 on ruby
<ximion> although I guess what allowed LDC to migrate was britney's ignore-cruft setting - the LDC upload didn't make anything uninstallable with the old cruft still in the archive, so it migrated
<dpb1> nacc: I don't think it matters on what section
<nacc> dpb1: given they are all from the same source package, i don't think anyone is really going to notice which binary is actually in main, tbh
<dpb1> ok
<dpb1> the binary will "pull in" the source as supported, I take it
<nacc> dpb1: the source will need to be in main for any of its binaries to be in main
<dpb1> k
<slangasek> the source is always pulled in via the binary.  so it's a question of which binary packages you want to represent as supported
<nacc> slangasek: right
<dpb1> I think ruby makes the most sense, no argument
<nacc> dpb1: given that we might add more to this list, I'll add a section for Language Interpeters, ack?
<dpb1> nacc: sounds good
<nacc> dpb1: seed pushed
<xnox> rbasak, because it is a regression versus release pocket, that a security upload introduced; which trips up all other pending-srus which are reverse-deps of dovecot; there is no better way then SRUing this, to insure that next upload (security or updates) will fix this issue
<xnox> rbasak, it's not like there is a VCS for next-artful upload of dovecot, which ever that might be.
<nacc> slangasek: urgh, LP: #1757344, segfault in 'frontend' -- that's debconf?
<ubottu> Launchpad bug 1757344 in php7.1 (Ubuntu) "package php7.1-sqlite3 7.1.15-0ubuntu0.17.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 139" [Undecided,New] https://launchpad.net/bugs/1757344
<slangasek> nacc: it's debconf-ish.  the segfaulting frontend may not be debconf code itself
<slangasek> (since debconf is pretty vanilla perl)
<nacc> slangasek: yeah, that's what i thought
<nacc> slangasek: i guess it could be the normal update-manager frontend?
<nacc> slangasek: but, in this case, it's (presuambly) not a bug in php, but in that frontend?
<slangasek> nacc: update-manager's frontend is the debconf gnome frontend.  But yeah, a frontend crash is unlikely to be php's fault
<nacc> slangasek: alright, i'll add a task once i figure out what they were using
<rbasak> xnox: VCS for next-artful upload> as an aside, I think we should have that kind of thing
<rbasak> xnox: but I'm not happy impacting users for what is fundamentally a developer issue that doesn't impact users.
<xnox> rbasak, e.g. even if we commit this to "-proposed" next time there is a CVE -security will not take it, they take -updates only, no?
<xnox> rbasak, i think the right thing to do, is to upload this sru.
<xnox> on the grand scheme of things it is miniscual to the kernel every three weeks.
<xnox> rbasak, and it's been less than two weeks
<xnox> rbasak, and it does show security team did not run autopkgtest of dovecot itself, before uploading security upload.
<rbasak> I believe the security team generally look at -proposed and make a decision
<rbasak> Sometimes I've seen them incorporate a verification-done upload to -proposed that hasn't finished aging, for example
<bdmurray> andyrock: Are you still about?
<andyrock> bdmurray: hey hey
<andyrock> what's up?
<bdmurray> andyrock: hey, I was you software-properties change got uploaded. One idea I might not have explained clearly was using distro-info so we don't need this line.
<bdmurray> channel='edge', # Remove this once bionic is officialy supported.
<bdmurray> Although what does "officially supported" mean? 18.04.1 or 18.04 or some other date?
<andyrock> officially supported by "livepatch"
<bdmurray> Okay so the last one!
<andyrock> yeah livepatch devs told me that before release bionic should be supported in stable canonical-livepatch snap
<andyrock> we can upload a small fix later
<andyrock> should be a small one
<andyrock> at least we can test it right now
<bdmurray> Right, my hope was to avoid that as an SRU but it sounds like it may not be possible.
<andyrock> yeah the problem is that it's not possible to query canonical-livepatch and ask "is this release supported?"
<andyrock> we need to address this in the future
<bdmurray> Okay, that's fine - just wanted to make sure it was considered.
<mwhudson> xnox, cjwatson, cyphermox: are any of you awake and willing to talk to me about partition alignment requirements?
<mwhudson> (for subiquity reasons)
#ubuntu-devel 2018-03-22
<Unit193> jbicha: Pinging with 1757574 as you did the aforementioned upload.
<Unit193> LP 1757574
<ubottu> Launchpad bug 1757574 in libappindicator (Ubuntu) "development libraries missing depends listed in *.pc files" [Undecided,New] https://launchpad.net/bugs/1757574
<jbicha> Unit193: could you be more specific?
<Unit193> jbicha: Eg libappindicator-dev should depend on libgtk2.0-dev, same for the gtk varient.
<jbicha> do you want to submit a merge proposal? https://code.launchpad.net/~indicator-applet-developers/libappindicator/trunk.16.10
<jbicha> lp:libappindicator
<Unit193> Sure, I could do that if it gets it in.
<Unit193> https://code.launchpad.net/~unit193/libappindicator/build-depends/+merge/341865
<Unit193> (If you're wondering how one could have a build-depend on that but not libgtk2.0-dev, wxwidgets.)
<Unit193> Thanks!
<tseliot> doko: hi, any chance of getting the fix for gcc in 16.04 and 14.04? https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937
<ubottu> Launchpad bug 1750937 in gcc-4.8 (Ubuntu) "4.4.0-116 Kernel update on 2/21 breaks Nvidia drivers (on 14.04 and 16.04) due to outdated gcc-4.8" [Undecided,Fix released]
<doko> tseliot: I'm not sure what you're asking
<doko> if it's about the retpoline patches, then you should ask the security team
<anon^_^> hello
<anon^_^> doko?
<anon^_^> i was the user that reported an issue with reptoline missing in gcc-4.8
<anon^_^> in ubuntu-kernel yesterday
<tseliot> doko: this ^
<anon^_^> i had a functional system with nvidia 384, updated to 3.13.0-143-lowlatency
<doko> looks good to me: https://launchpad.net/ubuntu/+source/gcc-4.8
<anon^_^> then kern.log began throwing errors
<anon^_^> Mar 21 02:11:55 ****** kernel: [   60.800613] nvidia: version magic '3.13.0-143-lowlatency SMP preempt mod_unload modversions ' should be '3.13.0-143-lowlatency SMP preempt mod_unload modversions retpoline '
<anon^_^> the nvidia driver was unloaded
<anon^_^> actually it was 4:4.8.2-1ubuntu6
<anon^_^> gcc version
<anon^_^> removed both the kernel and nvidia 384, re-installed and it was still broken
<anon^_^> modinfo nvidia-384 -k 3.13.0-143-lowlatency
<anon^_^> vermagic:       3.13.0-143-lowlatency SMP preempt mod_unload modversions
<anon^_^> ^ no retpoline flag
<anon^_^> to get the nvidia driver to load i have to manually edit
<anon^_^> # /usr/src/linux-headers-3.13.0-143/include/linux/vermagic.h
<anon^_^> following sven's workaround
<anon^_^> https://devtalk.nvidia.com/default/topic/1030325/nvidia-driver-installation-v387-26-on-ubuntu-16-04/
<anon^_^> then i removed the nvidia module from dkms, re-installed, rebooted
<anon^_^> there probably aren't very many people using 14.04 with it being close to EOL
<anon^_^> but i doubt that most ubuntu users are going to be able to figure out what broke nvidia drivers or go through all that to fix it
<anon^_^> if i remove that workaround from vermagic.h the nvidia module will not load
<anon^_^> the issue is persistent across reboots and re-install
<anon^_^> doko?
<doko> sbeattie: ^^^  I have no idea about that ...
<coreycb> sil2100: it seems like the accepted into proposed script needs updating if only per-release verification-done tags are accepted
<sil2100> coreycb: it is updated, not sure why Brian's response had the old comment - for instance right now it's like this: https://bugs.launchpad.net/ubuntu/+source/httmock/+bug/1735160/comments/21
<ubottu> Launchpad bug 1735160 in py-macaroon-bakery (Ubuntu Artful) "[SRU] Please backport python3-macaroonbakery 0.0.6-1 [universe] from bionic" [Undecided,In progress]
<coreycb> sil2100: ok cool
<coreycb> sil2100: thanks :)
<sil2100> I'll poke Brian later, maybe he's missing a bzr pull or something ;)
<sil2100> (but that's a very old change)
<sil2100> bdmurray: hey! As per coreycb's pointer, it seems like you have a greatly outdated sru-review script? Looks like you're leaving outdated verification comments, like for instance in https://bugs.launchpad.net/horizon/+bug/1582725/comments/19
<ubottu> Launchpad bug 1582725 in horizon (Ubuntu Xenial) "cinder_policy.json action does not match the Cinder policy.json file" [Medium,Fix released]
<sil2100> bdmurray: I changed that string ages ago when we switched to the verification-done-SERIES enforcement
<bdmurray> sil2100: I might have been in an old branch... I'll clean that up.
<sil2100> bdmurray: thanks ;)
<rbasak> sil2100: reminder to review bug 1466926 please
<ubottu> bug 1466926 in apache2 (Ubuntu Xenial) "reload apache2 with mpm_event cause scoreboard is full" [Undecided,In progress] https://launchpad.net/bugs/1466926
<sil2100> rbasak: ACK
<rbasak> sil2100: thank you for the review
<powersj> slangasek: LP: #1758113 is currently causing troubles with server ISO
<ubottu> Launchpad bug 1758113 in python-cryptography (Ubuntu) "bionic: depends on package that does not exist" [Undecided,New] https://launchpad.net/bugs/1758113
<powersj> ^ coreycb is this known?
<slangasek> powersj: also reported as LP: #1758004; but I'm not sure what the actual bug is, python3-cffi-backend provides both virtual package names
<ubottu> Launchpad bug 1758004 in Ubuntu on IBM z Systems "[Ubuntu 18.04] Error installing the "Basic Ubuntu Server"" [High,New] https://launchpad.net/bugs/1758004
<coreycb> powersj: i don't know. my changes to that were no-ops.
<slangasek> powersj: is python3-cffi-backend present on the ISO?
<coreycb> powersj: Tristan might be a better contact
<powersj> slangasek: it is not
<slangasek> powersj: ok. does the error occur when trying to do an install of this task without a network apt source?
<slangasek> powersj: my guess is that apt within the target is fine to do this installation, but our code to assemble the pool on the image fails to handle versioned provides
<slangasek> in this case, we would've sidestepped the bug if the squashfs on the server ISO was the full server task
<slangasek> xnox: ^^
<xnox> slangasek, which server team rejected
<xnox> slangasek, saying "oh no, people use server.iso, as a mini d-i.iso, and only install minimal by default"
<xnox> slangasek, unless we ship multiple squashfs on the server.iso
<slangasek> xnox: where/when was this reject?
<xnox> slangasek, in an informal conversation.
<xnox> slangasek, however that was in the context of disable tasksel /as well/. maybe they will be happy with a fatter squashfs. (and tasksel kept in tact)
<xnox> i can re-raise that.
<slangasek> xnox: yeah, I don't think that's a good rationale for this behavior anymore
<slangasek> xnox: please re-raise it where I can participate in the discussion :)
<xnox> slangasek, meet us in the pub, in cambridge, at 17:00 tomorrow
<xnox> =)
 * xnox giggles
<slangasek> xnox: anyway, these days we are producing a "good" squashfs for the subiquity image, and it's a shame that we're not using it for the d-i image
<slangasek> ? Unknown dependency python3-cffi-backend-api-min (<= 9729) by python3-cryptography
<slangasek> ? Unknown dependency python3-cffi-backend-api-max (>= 9729) by python3-cryptography
<slangasek> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/bionic/daily-20180322.log
<slangasek> actually, this seems to be in germinate
<slangasek> cjwatson: does germinate support versioned provides, in some version later than what we currently have on nusakan?
<cjwatson> I don't think so.  Could I have a bug?
<cjwatson> It shouldn't be too horribly difficult
<slangasek> cjwatson: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1758004
<ubottu> Launchpad bug 1758004 in germinate (Ubuntu) "[Ubuntu 18.04] Error installing the "Basic Ubuntu Server"" [Undecided,Triaged]
<cjwatson> Thanks.  I'd be happy to take a look, though probably not today
<cjwatson> I do at least have a failing test case in place
<sergiusens> slangasek: since I see you are on it, just wanted to say that the new dh-python broken our snapcraft pkg builds https://launchpadlibrarian.net/361662873/buildlog_ubuntu-bionic-amd64.snapcraft_2.40+18.04.2_BUILDING.txt.gz
<sergiusens> *broke
<sergiusens> there seems to be new copy logic in there
<slangasek> sergiusens: please refer this to doko who made this post-FF change
<sergiusens> ack, I'll log a bug
<sergiusens> doko: LP: #1758142
<ubottu> Launchpad bug 1758142 in dh-python (Ubuntu) "Recursive follow of symlinks" [Undecided,New] https://launchpad.net/bugs/1758142
<slangasek> powersj, cjwatson: as a short-term hack to unbreak server, I think I'm going to try to have germinate on nusakan ignore versions entirely for provides calculation; AFAIK we don't have any versioned dependencies currently that will be incorrectly resolved to non-version-matching virtual packages as a result of this, and even if we do, the outcome is no worse than currently
<powersj> slangasek: ok I would need to wait for tomorrow's ISO to re-test?
<slangasek> powersj: I would retrigger a build immediately for testing
<powersj> even better
<slangasek> powersj: (and running now)
<mwhudson> morning
 * slangasek waves
<slangasek> powersj: we should diff the .list files for each architecture, to make sure it's done what we expect
 * powersj downloads the 20180322.list
<slangasek> powersj: 20180322.1 done
 * powersj waits on http://cdimage.ubuntu.com/ubuntu-server/daily/20180322.1/
<slangasek> unfortunately the dh-python dpkg-dev fix landed at the same time so the diff is large
<powersj> diff http://paste.ubuntu.com/p/xXpyH96ntG/
<powersj> yeah
<slangasek> -/pool/main/p/perl/libperl5.26_5.26.1-5_amd64.deb
<slangasek> that part doesn't look good though
<slangasek> +/pool/main/p/python-cffi/python3-cffi-backend_1.11.5-1_amd64.deb
<slangasek> whereas that part does
<slangasek> actually, even the perl stuff is consistent with the priority-mismatches fixup
<powersj> diff with only changes: http://paste.ubuntu.com/p/8VHTTf57ds/
<powersj> all the gcc and gnupg2 changes are expected?
<slangasek> yes
<slangasek> python3 -> dh_python was incorrectly pulling in dpkg-dev -> build-essential
<powersj> ok I'll launch tests
<slangasek> so actually 20180321 might be a better basis for comparison
<slangasek> hmmm no, gcc was already in the mix in 20180321
<slangasek> so nevermind
<slangasek> I could revert this change and do another build for comparison
<slangasek> powersj: ^^?
<powersj> that might be good to make sure we don't let something slip through
<powersj> I'll still launch on 22.1
<slangasek> k, running
<slangasek> the libperl5.26 change *looks* super-odd, but when I dig I am surprised to find that perl-base (/usr/bin/perl) does not depend on libperl.  Sooooo even this is plausible
<slangasek> cjwatson: you mentioned a failing test case, perhaps you also arrived at something like https://code.launchpad.net/~vorlon/germinate/+git/germinate/+ref/lp.1758004
<powersj> slangasek: smoke test install just completed successfully
<cjwatson> slangasek: Similar kind of thing; thanks
<jbicha> cking: why did you reintroduce xchat-gnome to Ubuntu? LP: #1758163
<ubottu> Launchpad bug 1758163 in xchat-gnome (Ubuntu) "Please remove xchat-gnome from Ubuntu (again)" [Undecided,New] https://launchpad.net/bugs/1758163
<cking> jbicha, it can be killed, it's too much hassle to maintain IMHO
<jbicha> could you comment on the bug please then :)
<cking> done
<jbicha> apw: since you sponsored xchat-gnome back into Ubuntu, could you look into removing it now? ^
<slangasek> jbicha, cking, apw: done
<jbicha> cool, that was really fast :)
<cking> thank
<cking> s
<slangasek> oh no, we removed his irc client from the archive and he fell offline
<acheronuk> lol
<slangasek> powersj: 22.2 is up, with a shorter (and still interesting) delta
<powersj> slangasek: is this what you show? 22.1 diffed against 22.2 http://paste.ubuntu.com/p/2cTHwh7W3W/
<powersj> so e2fslibs
<slangasek> powersj: yes.  so, what does ef2slibs mean
<powersj> ef2slibs was on the cd, but since changing germinate to ignore versions it is now not on there
<anon^_^> doko, sbeattie, any update re: reptoline, gcc-4.8 issue with 14.04 that lead to persistent unloading of Nvidia driver?
<slangasek> powersj: turns out libext2fs2 Provides: e2fslibs (= 1.44.0-1); so it's a bit strange that e2fslibs and libext2fs2 exist like this, but it's not wrong for the image build to drop e2fslibs from the image based on my germinate change
<powersj> ok
<sbeattie> anon^_^: I don't know what you're referencing. gcc-4.8 4.8.4-2ubuntu1~14.04.4 (available in both trusty-security and trusty-updates) is needed for the dkms build. I'm not sure why any of that would cause a module to unload, though.
<jbicha> slangasek: can you explain the bash 4.4.18-1.1ubuntu1 removal?
<jbicha> because I used sbuild-launchpad-chroot to create an armhf chroot but it is stuck trying to update bash with an error that looks like Debian bug 889869
<ubottu> Debian bug 889869 in bash "bash: crash in qemu-user: bash: xmalloc: ... cannot allocate XX bytes (0 bytes allocated)" [Important,Fixed] http://bugs.debian.org/889869
<slangasek> jbicha: PIE is a security feature, and shouldn't be disabled to work around a bug in qemu-user-static
<jbicha> is there a LP bug for the issue I experienced then?
<slangasek> jbicha: LP: #1751011
<ubottu> Launchpad bug 1751011 in bash (Ubuntu) "bash crashes in qemu-user environments (bionic)" [Undecided,Triaged] https://launchpad.net/bugs/1751011
<jbicha> bash being stuck half-installed is a bit of a problemâ¦
<jbicha> slangasek: I request that you reconsider. The PIE change was only in Debian one week before it was reverted
<jbicha> meanwhile, I added it to the Release Notesâ¦
<slangasek> jbicha: considering.  I think at minimum, I would want it signed off by the Security Team that they're ok with non-PIE bash in 18.04
<slangasek> jbicha: barring that signoff, although I understand it's inconvenient to have qemu-user completely unusable for cross-chroots as a result of this, there are also still large swaths of the archive that qemu-user can't cope with (last I checked: anything Qt-based, for armhf), so I think having it completely-broken vs 25% broken is not a persuasive reason to disable the hardening feature
<slangasek> mdeslaur, sbeattie: ^^ would one of you want to weigh in on this?
<sbeattie> slangasek: we previously had bash as no-pie because it hit a similar failure on older kernels. It's not ideal, but I can live with it.
<jbicha> slangasek: comment 15 at Debian bug 865599 has another proposalâ¦
<ubottu> Debian bug 865599 in src:bash "bash can stop disabling PIE" [Normal,Open] http://bugs.debian.org/865599
<jbicha> I don't know enough about bash to know what the proposal means
<slangasek> sbeattie: you're not required to live with it, though... if you think this is important to our hardening story in 18.04, I think that takes precedence
<slangasek> also it's one thing to have had PIE disabled for a package for 16.10-17.10, and another to have it disabled in 18.04 LTS
<slangasek> jbicha: yes, that suggestion makes sense given what I saw of the description of the problem (internal use of sbrk instead of glibc malloc)
<slangasek> jbicha: I think it's worth investigating as a path forward (but I'm probably not going to pursue this myself)
<jbicha> ok
<anon^_^> sbeattie, pm
<tjaalton> could a member of the security team please review https://bugs.launchpad.net/ubuntu/+source/pysmi/+bug/1748572
<ubottu> Launchpad bug 1748572 in pysmi (Ubuntu) "[MIR] pysmi, pycryptodome" [High,New]
<tjaalton> I need to get 389-ds-base unblocked, finally
<sarnold> tjaalton: it'll be next week before we can get to that
<tjaalton> sarnold: as long as it's on the radar, thanks
<sarnold> tjaalton: yup, not forgotten, it just got knocked back a bit on the list when encrypted devices stopped working the other day :/
<tjaalton> fun times
<sarnold> there's always a bit of a rush around FF time .. this one more than most, probably because it's an LTS..
<tjaalton> I'm just as guilty :)
<sarnold> it's probably just the way things are going to go when it's run on a cycle ;)
<tjaalton> yup
<slangasek> tjaalton: <cough> I accidentally got 389-ds-base in already without the MIR being handled
<sarnold> heh
<slangasek> MIR still needs doing of course
<tjaalton> slangasek: oh, hehe.. thanks
#ubuntu-devel 2018-03-23
<rbasak> xnox: you know I've been working on the mongodb FTBFS right?
<rbasak> xnox: my fix is ready. I've put up an MP for peer review.
<xnox> rbasak, url?
<xnox> rbasak, you mean https://jira.mongodb.org/browse/SERVER-33395 right?
<rbasak> Yes.
<rbasak> xnox: 1758116
<rbasak> xnox: bug 1758116
<ubottu> bug 1758116 in mongodb (Ubuntu) "mongodb ppc64el FTBFS on 1:3.4.7-1ubuntu3" [Undecided,In progress] https://launchpad.net/bugs/1758116
<rbasak> xnox: bug 1758118
<ubottu> bug 1758118 in mongodb (Ubuntu) "src/mongo/db/fts/unicode is not optimised on ppc64el" [Medium,Triaged] https://launchpad.net/bugs/1758118
<xnox> "I've put up an MP for peer review" -> url?
<rbasak> xnox: https://code.launchpad.net/~racb/ubuntu/+source/mongodb/+git/mongodb/+merge/341934
<mdeslaur> slangasek: fyi, I am against the xchat-gnome removal
<xnox> mdeslaur, have you used hexchat at all?
<rbasak> xnox: frankly I'm pretty pissed off at the level that you're interfering with this, given that you washed your hands of it already.
<mdeslaur> xnox: yes, but it's gtk2.0, which we are trying to deprecate
<rbasak> xnox: I have it under control.
<xnox> mdeslaur, true
<rbasak> xnox: please stop.
<mdeslaur> in fact, AFAIK, jbicha is the one trying hard to deprecate gtk2.0, so I'm a bit puzzled by his bug
<mdeslaur> It would be nice to have at least _one_ irc client that works natively in wayland
<rbasak> xnox: and if you have comments to make, please discuss them with me first. It's frustrating to find that you're doing things without talking to me about it given that you know I'm on it.
<xnox> rbasak, you have been following the discussions on #juju, right?
<xnox> rbasak, you are the one told me to talk with balloons and figure things out, which is what i have been doing.... like you said....
<xnox> rbasak, you are the one who told me to talk with balloons and figure things out, which is what i have been doing.... like you said....
<xnox> also re:altivec, we do have a channel to talk about power issues direct with IBM.
<xnox> so instead of regressing performance, or applying an unknown fix, it would be better to escalate it to IBM via our PMs.
<rbasak> xnox: I said that *if* you want to do things differently, then you can take responsibility for the whole thing. I'm not aware that you did that.
<rbasak> xnox: and if you want to do that, please speak to dpb first.
<rbasak> xnox: connecting to IBM about it is part of the plan. That's why I have filed a separate bug.
<xnox> cool
<rbasak> xnox: but in the meantime I want to land the FTBFS fix to unblock Juju.
<rbasak> If/when a fix arrives upstream (quite possibly with IBM's help), then we can upload that - in an SRU if needed.
<xnox> rbasak, i still stand by the fact that your facilitation of enabling juju team to use src:mongodb with js engine enabled, is irresponsible from security stand point of view.
<xnox> rbasak, and no, that's not what they ultimately want. but they don't have time nor headcount to have what they really want.
<rbasak> And I stand by the fact that it is outside of your remit and my remit to speak for the security of Juju upstream, as Juju is not packaged in Bionic.
<xnox> i'm just being a responsive community member
<rbasak> You're being a community member demanding that others do work.
<rbasak> You're not in a position to do that.
<xnox> i made no such demands.
<rbasak> Sure, we can improve tons of things.
<rbasak> This is not an improvement that we've commited to make and support. We've chosen a middle ground instead.
<xnox> i did file requests for certain things to be looked at. and they haven't because of ENOTIME, but there are a lot of bugs, which we are valid, and we do acknoweldge by either fixing them or, wont-fixing them.
<rbasak> No, you're filing bugs that actively block my work, eg. with block-proposed, without even telling me about it, let alone consulting me.
<rbasak> That is out of order.
<mdeslaur> xnox, slangasek: I've filed bug 1758210 to remove hexchat from Ubuntu
<ubottu> bug 1758210 in hexchat (Ubuntu) "Please remove hexchat from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1758210
<xnox> mdeslaur, nice =)
<jbicha> lol
<Unit193> What? :P
<xnox> rbasak, filing a public bug is trivial; so is marking it wontfix with the a comment; or leaving the bug open, but removing the tag.
<xnox> rbasak, i'm using the collaboration tools as they were meant to.
<rbasak> And pinging me about it is trivial too, but you didn't seem to find the time to do that.
<Unit193> Perhaps 'demote' is a better word?
<rbasak> Instead you're demanding that we do this differently while also blocking me from making progress while also not committing any time to actually do it.
<rbasak> Anyway, I've said my piece. Now: will you leave me alone please, so I can get on and land this without further interference?
<xnox> rbasak, you are missjudging me a lot.
<jbicha> mdeslaur: of course we're not actually removing gtk2 from universe for 18.04 LTS ð
<Unit193> Yeah, that'd be insane.
<xnox> rbasak, if I were not working, in my free time, for the past few days, on making a minimal supportable juju-mongodb3.4 build with js engines off, i would not have hit the same FTBFS on the test-suite stage of the build to discover and comment on the upstream jira.
<xnox> rbasak, i would not have been uploading wiredtiger to enable it to be build on arm64, s390x, ppc64le
<xnox> rbasak, i would not have uploaded it to support verbose messaging
<jbicha> mdeslaur: Firefox and Chromium aren't native Wayland yet eitherâ¦
<xnox> (and check that we have both newer wiredtiger in the distro, still compatible with mongodb)
<rbasak> xnox: why have you not been coordinating this work with me, dpb, or ~ubuntu-server in genreal?
<mdeslaur> jbicha: perhaps we should leave gtk2 in main
<xnox> rbasak, i would not be making a build that uses system wiredtigered.
<mdeslaur> would be nice to get gtk2 compatible with wayland
<xnox> rbasak, dude - you said you have no time, to make the standalone minimal build; and that you are doing core packages split (because it makes sense anyway) and that is it. And you said take it with juju, and discuss if minimal build is something they would ahve liked..... as i did..... in #juju chanel.... with talking to balloons.
<xnox> rbasak, i'm confused, why you are backtracking on what we disussed now.
<rbasak> xnox: no, I'm not.
<rbasak> xnox: I didn't think it needed to be said that I expect you to coordinate with everyone involved, including me.
<rbasak> You *knew* that I was continuing down this path.
<xnox> rbasak, correct, which is the core split. but you did say you want to do this, irrespective of what juju does.
<xnox> or uses.
<rbasak> No, I said it was _for_ Juju, but acceptable generally for the package.
<rbasak> I intended to maintain the core split delta only for Juju.
<xnox> i thought you said you chatted with debian about it, and they are ok to take it too, etc... and they ~ubuntu-server did that for all other dbs
<xnox> that's what i understood
<xnox> sorry. and that juju would be one of the users of core bins - just like they noticed that core split was done everywhere else already
<rbasak> Who is going to maintain this juju-mongodb3.4 that you intend to upload in your spare time?
<xnox> rbasak, anyway, irrespective of this, i think even 3.4 series are crap, due to lack of openssl1.1 support. thus i'm planning to tackle v3.6, if i find enough time for that.
<xnox> rbasak, support on the stable series is easy.
<xnox> rbasak, it's supporting it across multiple LTS is hard.
<rbasak> Who is going to maintain this juju-mongodb3.4 that you intend to upload in your spare time?
<xnox> rbasak, i did talk to them - so what is the support story, beyond bionic and non-out-of-the-archive mongo? and turns out, they have none (or at least baloons was not aware of any). And they do have lack of manpower to be able to maintain juju-mongodbX.Y either in the distro, or outside of distro.
<xnox> one option
<xnox> is for them to move to upstream builds
<rbasak> I am aware. Please answer my question.
<xnox> because upstream does provide mongodb builds fro arm64 s390x amd64 ppc64el
<xnox> but htat upstream build is "enterprise"
<xnox> rbasak, supporting source package of 3.4 in bionic, for lifetime of bionic, is easy, even if by me. It is no harder than support boost.
<xnox> rbasak, supporting source package of 3.4 in bionic, for lifetime of bionic, is easy, even if by me. It is no harder than supporting boost.
<xnox> rbasak, but not supporting 3.4 build in e.g. 18.10, or beyond.
<rbasak> Just you? And you don't consider that irresponsible?
<xnox> ideally i want juju-mongodb3.6 in bionic with openssl1.1
<xnox> because i think 3.4 series may die soon.
<rbasak> What if you're not around? Hit by a bus? You think it's OK to leave your baggage behind in the archive without having consulted any appropriate other Ubuntu developers about it?
<rbasak> ...while also having Juju rely on it?
<xnox> rbasak, dude. you do know that mwhudson was the one-man person doing juju-mongodb & mongodb all this time.
<rbasak> You are missing my point.
<rbasak> It's not about how difficult it is.
<jbicha> mdeslaur: have you tried Polari?
<rbasak> It's about imposing your will on others without consulting with them first.
<rbasak> That is irresponsible and antisocial.
<xnox> rbasak, and e.g. me getting hit by the bus, will get boost unmaintained in debian & ubuntu, as far as i can tell. already =)
<rbasak> You don't get to make that decision alone.
<xnox> rbasak, and boost has a bit more users.
<xnox> rbasak, i can say the same about you.
<jbicha> xnox: rbasak: please don't get hit by a bus
<xnox> rbasak, this is a waste of my time, let me go back to coding and building things.
<rbasak> No, you can't.
<xnox> jbicha, hahahhaha. thanks.
<rbasak> I am doing what I'm doing after extensive consultation with a whole load of people.
<rbasak> And my actions are backed by ~canonical-server which includes a bunch of Ubuntu core devs.
<xnox> good
<rbasak> xnox: no, you don't get to ignore the conversation.
<rbasak> xnox: you chose to get involved, now you get to take responsibility and work with me to find an agreement on how to continue from here.
<xnox> my code is not ready for code review yet
<rbasak> What are your intentions now?
<xnox> unchanged since yesterday; work on providing a test ppa with juju-mongodb3.4 & juju-mongo-tools3.4; latest upstream point release; js-engine off; no /bin/mongo client shipped; and asking upstream (juju) to review if that is suitable/desirable/better for them. mentioning the build changes, and caveats.
<xnox> also i have two patches to send to upstream mongo, to fix their build infra.
<xnox> there are mistakes in scons linking scripts for smaller builds
<rbasak> Thank you for stating that.
<rbasak> From my POV, if you do that and upstream uses that instead of the Bionic mongodb package, then I'd like to back as much of the delta out of Ubuntu universe as I can, as we would have no motivation to maintain it.
<rbasak> The FTBFS fixes would have to remain of course, but that can be synced in time I guess.
<rbasak> The core split change I'd want to back out unless Debian upload that before we release Bionic. Because otherwise, if Debian decides not to take it, then we'd have to hold a transitional delta until the next LTS.
<xnox> rbasak, that would be reasonable. to me the biggest driving factor is to avoid legitimising use of src:mongodb and given any impression that Canonical supports it. Given the nack from security team in keeping it support due to js engine. Having mongodb in main has come up before (with juju and wihtout juju as context) and foundations/security did a lot of analysis on making mongodb supportable for generic users - and it really isn't.
<xnox> "and give any"
<rbasak> I think I'm justified in being pissed off about this - not because you're doing work in your spare time, but because you've done this without coordination and this is causing me to waste my time.
<xnox> FTBFS fixes only -> yeah, we need that regardless
<rbasak> "avoid legitimising use of src:mongodb and given any impression that Canonical supports it" -> you should be talking to your manager about this.
<xnox> rbasak, i'm pissed off that instead of continuing conversation with me about fixing up juju-mongodb3.2, since the issue was raised early in bionic cycle, the upstream pivoted to stop talking to foundations/mwhudson and instead pivoted to talking to you/ubuntu-server.
<rbasak> If that's your rationale, then I still think your inteference is out of order.
<rbasak> It's outside the remit of your Ubuntu hat, and not within the remit of your Canonical hat.
<xnox> rbasak, because have they said "well then, will have to switch to using src:mongodb instead" things would have been escalated much earlier, and juju-mongodb3.[46] could have been done much earlier.
<xnox> rbasak, but, i get pissed off, and let things go. clearly the code they need, in the form they need, does not exist, and needs work. Because mongo has a lot of deps, and is quite fragile/sensitive - any time one touches it, something new pops up to fix. If mongo was easy to build, none of this would have been an issue; and it would have been vendorized by juju a long time ago, like the rest of their godeps.
<xnox> "out of order" -> as soon as I discovered it.
<xnox> rbasak, also note the https://bugs.launchpad.net/ubuntu/+source/juju-mongodb3.2/+bug/1730706 and the comment from 1st of December
<ubottu> Launchpad bug 1730706 in juju-mongodb3.2 (Ubuntu Bionic) "RM FTBFS with new scons, new g++, new C++ standards" [Critical,Confirmed]
<xnox> rbasak, that is my context for my involvement. so chronologically, i think the core-split comes after that bug was filed, no?
<xnox> clearly there were multiple conversations, in parallel, with certain people involved, but not all.
<rbasak> I don't see how that contradicts anything I've said.
<rbasak> Yes, the core split proposal came after. I wasn't aware of that bug specifically, but was aware of the general gist.
<xnox> "We will seek to ship juju-mongo3.6"
<rbasak> That's exactly why, in my understanding, we ended up doing the core split in src:mongodb
<xnox> hence, i wrote FTBFS juju-mongo3.2 issues; knowning that 3.6 will land sometime.
<xnox> it's quite a change in plan of record; to pivot to a mongo-core split, don't you think?
<rbasak> It follows from the conversation on that bug. I only see people declaring that effort was not being committed there.
<xnox> rather than saying "please halp, we are late, we have no juju-mongo3.6, can anybody help, please" -> ok then, says xnox.
<xnox> rbasak, well, i'm sorry that i trust people when they say they gonna do something or what the plan is.
<rbasak> All of that is fine. Taking it upon yourself without coordinating with anyone else is what I have a problem with.
 * xnox "hence, i wrote _off_ FTBFS ..." (i suck at grammar, and i better correct myself, before rbasak goes quoting irc logs in emails to the widely followed mailing lists by all the job recruitors ;-) )
<rbasak> ?
<xnox> rbasak, btw, i think it is not nice quoting irc logs in public mailing lists ;-) the style and tone of irc conversations, is different to emails, mailing lists, and email requests/petitions for policy clarifications.
<xnox> rbasak, you could have paraphrased, and summarise irc conversation re:autopkgtest-only-sru
<xnox> at least my writting style is different on irc vs mailing lists
<rbasak> The IRC logs are public.
<xnox> sure, but the audience is different. and when people open and read irc logs, they do it differently, then when they are reading an email.
<rbasak> Would you prefer I linked to the IRC logs instead?
<xnox> yes
<rbasak> I don't see how that would be different.
<xnox> because it would force you to summarise what you are linking to.
<rbasak> I'm just saving the trouble of someone clicking. I did state that it is an IRC discussion!
<rbasak> I did summarise.
<rbasak> "Dimitri uploaded a dep8 fix for dovecot in bug 1757265"
<ubottu> bug 1757265 in dovecot (Ubuntu Artful) "Ubuntu in the welcome string confuses autopkgtest" [Undecided,Fix committed] https://launchpad.net/bugs/1757265
<rbasak> That was (genuinely) my summary.
<rbasak> I didn't feel that anything further was needed, because the details aren't relevant to the general question.
<xnox> i just think it was rude, to quote irc conversation, even if it was on the public irc channel, in a mailing list email / policy discussion email thread.
<xnox> that is all.
<rbasak> OK. Sorry. Data point accepted. I'm quite surprised you think that though. If consensus is that it's rude, I'll stop doing it.
<xnox> rbasak, i've asked opinions, a few people agreed that i'm not weird, and that it is a bit rude to "quote irc in an email, without consent / asking"
<xnox> as a general rule of thumb.
<rbasak> I'm in the habit of doing it.
<rbasak> For example, if I ping someone asking about a bug, I'll paste the conversation into the bug.
<xnox> we typically go very explitic, like "startmeeting" bot command when we are logged, and published minutes to e.g. websites / wikis / mailinglists
<rbasak> How else should I record the conversation in a way that's useful to the bug?
<rbasak> Are you saying I need to summarise and link every time?
<xnox> i'd say copy&paste irc responses form somebody, that purely contain technical details, description of behaviour, code explanations are fine.
<rbasak> I genuinely don't see how that's different. I understand that IRC has a different conversational context, but I have always assumed that context switch is obvious to any reader who sees that it's obviously an IRC paste.
<xnox> as the person at the time, are in "code comment like writing mode"
<xnox> rbasak, for example, our conversation today, i expect not, to be send to juju-devel; or ubuntu-release; or canonical-tech; etc.
<rbasak> I didn't think that quoting you from a public, logged channel is something you'd find rude in the slightest. Sorry.
<xnox> appologies accepted.
<rbasak> I think to be consistent I can only really follow accepted norms on this though, rather than remember to do something special for different people as that would be unrealistic.
<rbasak> I'll ask around to try to match my understanding to what people expect.
<xnox> cool
<sarnold> xnox: fwiw I'd rather see raw IRC in an email than a summary. Summaries can be misleading, even when made carefully and with no ill intentions.
<xnox> rbasak, if you want a bit of british humor google for "Tea Consent" youtube video
<rbasak> I'm aware of that video :)
<xnox> sarnold, sure, i would email security@ubuntu.com full logs of everything i can. because that's a more private venue, who I expect to sanitize things.
<xnox> sarnold, we do sanitize bugs before changing them form private -> public.
<sarnold> aye
 * rbasak is pretty sure that sarnold is a real person rather than just security@ubuntu.com :)
 * xnox TIL
<slangasek> mdeslaur: xchat-gnome> I have no dog in this, if you want to maintain it you can reupload it and I'll let it back in same as it was removed
<slangasek> I just don't know why anyone wants any of these gui irc clients ;p
<slangasek> mdeslaur: as for hexchat, given that this is a package synced from Debian rather than an Ubuntu-only package, my threshold for removal is slightly higher
<tsimonq2> irssi ftw :P
<dupondje> xnox: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2d1fad641b950520bec1a87c450d0e3b1439e262 => by chance this can be cherry-picked into nm?
<_hc> good morning!  hope the bionic freeze is going smoothly.  I'm part of the Debian Android Tools team.  The past two LTS releases, we've synced up right about now, so I'm checking in to see what's needed
<_hc> we've being doing testing on bionic and things are looking good
<_hc> there are three sync requests for the final bug fixes
<_hc> we were not able to get a update of the full SDK complete in time for bionic, so it'll still be on 7.0.0.  but I believe that still has ~3 years of security support from GOogle
<_hc> at the very least, that version of adb works with all current Android releases
<rbasak> _hc: bug fix sync requests should be fine. Do you have a link to the requests please?
<_hc> https://bugs.launchpad.net/bugs/1758192
<rbasak> Has anyone in particular dealt with these for you before?
<ubottu> Launchpad bug 1758192 in android-sdk-meta (Ubuntu) "Sync android-sdk-meta 25.0.0+8 (universe) from Debian unstable (main)" [Undecided,New]
<_hc> https://bugs.launchpad.net/bugs/1758196
<ubottu> Launchpad bug 1758196 in fdroidserver (Ubuntu) " Sync fdroidserver 1.0.3-1 (universe) from Debian unstable (main) " [Undecided,New]
<_hc> https://bugs.launchpad.net/bugs/1758199
<ubottu> Launchpad bug 1758199 in androguard (Ubuntu) " Sync androguard 3.1.0rc2-1 (universe) from Debian testing (main) " [Undecided,New]
<_hc> yes, I'm looking it up in the log, one sec
<_hc> cjwatson is one person
<rbasak> _hc: https://tracker.debian.org/pkg/android%2Dsdk%2Dmeta took me to https://salsa.debian.org/android-tools-team/android-sdk-meta which 404s. Is the link incorrect?
<_hc> no, its mid-migration, I can do that now if its needed
<rbasak> _hc: no need to fix the link. Just tell me where I can find the VCS to browse pleaes :)
<rbasak> (well do fix the link of course, but no need to block on that right now)
<_hc> still on alioth https://anonscm.debian.org/git/android-tools/android-sdk-meta.git
<rbasak> These all look fine to sync in principle. I'd just like to browse the actual changes to make sure they aren't doing anything unexpected/inappropriate for freeze
<_hc> FYI, Debian will be shutting down alioth soon, and all repos should be migrated to salsa.debian.org
<_hc> so if you haven't seen that already, expect to see it a lot from here on out :)
<cjwatson> I was just doing it because I was around and paying attention, rather than because I have a special interest, so no need to block on me.
<rbasak> cjwatson: OK thanks
<rbasak> _hc: yeah I'm aware thanks :)
<cjwatson> (I think possibly at one point there was a complicated bootstrap to do.)
<_hc> correct, not this time
<rbasak> _hc: alioth is missing the push of +8 that you're asking for a sync for I think?
<_hc> arg, sorry
<_hc> rbasak: pushed
<rbasak> Thanks, looking
<_hc> and https://salsa.debian.org/android-tools-team/android-sdk-meta is up now
<rbasak> Syncing android-sdk-meta. Looking at fdroidserver next.
<_hc> fdroidserver requires the third sync request: androguard
<rbasak> OK, thanks
<rbasak> _hc: doesn't https://salsa.debian.org/debian/fdroidserver/commit/c20834080e5b82b8d7a5ea5eef8aaa71e8416d33 _add_ dependencies?
<rbasak> For example, doesn't it cause android-sdk-common to be installed when it wasn't before?
<_hc> it removes android-platform-tools-base, which has a lot of deps, while adding more specific ones
<_hc> that android-platform-tools-base would install
<_hc> oops, android-platform-tools-base might not install those two
<_hc> android-sdk-common and android-sdk-platform-tools-common have no other deps
<_hc> android-platform-tools-base installs libandroid-ddms-java, which installs a few more things
<rbasak> It feels like a bigger change to me, and https://tracker.debian.org/pkg/fdroidserver has warnings about installability problems in testing.
<rbasak> (androguard I know about, but not the others)
<rbasak> Separately, I've just noticed that androguard has a major version bump. Are all changes there suitable for feature freeze?
<_hc> yeah, we got it into unstable in time for the bionic freeze, but not testing
<_hc> we specifically were working on androguard, fdroidserver, and all the android packages to get them into Debian in time for the bionic freeze
<_hc> but I guess I overlooked that LTS imports from testing not unstable
<rbasak> It may still be reasonable to update Ubuntu with this, but if the changes are over the feature freeze line, I'm not allowed without consultation with the release team.
<_hc> sorry
<rbasak> brb
<_hc> are ppc64el, mips, s390x even supported arches on Ubuntu? sorry for the mess there, I was just focused on Ubuntu, so thinking arm*/amd64/i386
<rbasak> ppc64el and s390x are supported on Ubuntu.
<_hc> ok, fixing now
<rbasak> We sync from Debian unstable but pretty much the same installability checks Debian does to migrate to testing.
<rbasak> Except we don't have minimum aging periods.
<rbasak> So in general, if Debian can't migrate to testing, we might well not be able to do so either.
<_hc> good to know
<rbasak> So a testing migration blocking issue in Debian is something to look at before sync to consider whether it will also block proposed migration in Ubuntu.
<_hc> ironically aapt/zipalign aren't hard deps, I just assumed they would always be there
<_hc> I've been doing most of my Ubuntu testing with a PPA, never seen other arches there.
<rbasak> You should be able to enable ppc64el and s390x on your PPA settings page
<rbasak> _hc: where can I find the upstream changelog/commits for androguard please? I don't see a link on the tracker.
<_hc> ah, interesting,, I'll try that now
<_hc> it'll be a large change:  https://github.com/androguard/androguard
<_hc> is that what you mean?
<_hc> or a specific file?
<rbasak> THat's fine, thanks.
<rbasak> I'm interested in "git log old_tag..new_tag" basically
<rbasak> Since that's the change you want to land in Ubuntu.
<_hc> it'll be large.
<_hc> we worked with upstream on androguard 3.1.0 to get it in bionic...
<_hc> sorry I didn't catch that sooner
<rbasak> OK. Based on https://github.com/androguard/androguard/releases/tag/v3.1.0 the set of changes is too large, IMHO, to be suitable for upload to Bionic after feature freeze without an exception from the release team.
<rbasak> I guess that blocks the sync of fdroidserver too then?
<rbasak> If you think it's still appropriate to land in Bionic, please follow https://wiki.ubuntu.com/FreezeExceptionProcess and get a +1 from a release team member.
<_hc> yeah, but if androguard won't make it into bionic, I can change the fdroidserver deps accordingly
<_hc> it'll work without androguard, but works better with
<rbasak> Basically edit the bug, explain what you're doing, why you want it, why it's appropriate to break the freeze, etc, and subscribe ~ubuntu-release.
<rbasak> Then we can ask a release team member to look at it.
<_hc> thanks!
<rbasak> _hc: you're welcome. Thank you for looking after this in Bionic. I hope it's clear what you can do to make progress. If not, feel free to ping me.
<_hc> I think so
<jbicha> rbasak: did you see https://tracker.debian.org/news/942400/accepted-mongodb-13414-1-source-amd64-all-into-unstable-unstable/ just landed in Debian?
<rbasak> jbicha: yes, thanks.
<rbasak> It's in NEW because of my core split patch that Debian accepted.
<jbicha> it's out of new now so maybe we can just sync it later today?
<rbasak> I'm concerned that it will FTBFS.
<rbasak> It doesn't have https://code.launchpad.net/~racb/ubuntu/+source/mongodb/+git/mongodb/+merge/341934 AFAICT for example.
<rbasak> So please don't just sync it without checking it builds and works first.
<jbicha> I guess it does: https://buildd.debian.org/status/package.php?p=mongodb
<rbasak> (and to be clear, please check with me again before actually pushing the button to sync)
<rbasak> On Debian, sure.
<rbasak> The current ppc64el FTBFS in Ubuntu appears to be toolchain dependent.
<rbasak> I'm not saying it won't work.
<rbasak> I just don't want to add to the mess by syncing without checking.
<jbicha> no, I mean, it fails to build on ppc64el in Debian too
<rbasak> Oh
<jbicha> so if y'all could forward that to Debianâ¦ :)
<rbasak> I'm currently blocked on my manager figuring out what he wants me to do next, so I'm holding uploading the MP on that.
<rbasak> But yeah, I'll forward my MP to Debian as part of resolving all of this.
<dupondje> https://bugs.launchpad.net/network-manager/+bug/1758331 => would be a nice-to-backport :)
<ubottu> Launchpad bug 1758331 in network-manager (Ubuntu) "IPv6 Route to OpenVPN Server is not created" [Undecided,New]
<ahasenack> Laney: hi, 'morning. I got another gvfs build with two patches from upstream to add extra logging. I think these are committed even (https://bugzilla.gnome.org/show_bug.cgi?id=794487)
<ubottu> Gnome bug 794487 in general "gvfs-test: Increase timeout to 10s" [Normal,New]
<ahasenack> hi, archive admin question: https://pastebin.ubuntu.com/p/vnKrkqNczH/
<ahasenack> would you reject this NEW package on the basis of the nvml_dbg directory under /usr/lib/$arch?
<ahasenack> upstream says:
<ahasenack> "Files under nvml_dbg are builds with debugging symbols, logging, asserts and expensive checks that we normally don't want users to run with.
<ahasenack> "
<ahasenack> the files there also trigger "W: libpmempool-dev: package-has-unnecessary-activation-of-ldconfig-trigger"
<ahasenack> dupondje: oh, do you think that's related to https://launchpad.net/bugs/1756032 ?
<ubottu> Launchpad bug 1756032 in openvpn (Ubuntu) "No VPN connectivity when accessing tunnel endpoint over IPv6" [Medium,Triaged]
<dupondje> ahasenack: i'm quite sure :)
<dupondje> I did have the same issue, build nm with the patch, and it works fine now
<ahasenack> dupondje: I might be able to get someone to test it, besides myself. I was also hit by that
<dupondje> I can send you the .deb's :)
<dupondje> or just build it yourself ofc
<ahasenack> you could attach a branch to that bug report
<dupondje> didn't create a branch :) just build a deb on my own syste,
<ahasenack> I'll create a branch and a ppa
<jbicha> ahasenack: I ignore https://lintian.debian.org/tags/package-has-unnecessary-activation-of-ldconfig-trigger.html
<jbicha> ahasenack: that lintian warning shows up too often and it's not clear that there's anything that should be done for it
<ahasenack> jbicha: I think ldconfig being activated could be a bug even, since that subdirectory is not in the ld search path
<rbasak> jbicha: I'm more bothered about the shipping of weird extra binary libraries in a -dev package. The lintian warning is just a symptom.
<ahasenack> yeah, it pointed me at that, let's consider these two issues
<jbicha> dupondje: looks like we just need to update NM from 1.10.4 to 1.10.6 for that issue
<dupondje> jbicha: could be an option indeed, its included in 1.10.6
<dupondje> somebody got to do it :)
<dupondje> its in debian already at least
<dupondje> I just want to have it on somebody's radar :) hehe
<ahasenack> I know a few people hit by that bug
<ahasenack> I can prep/tst packages with the patch, but not a new upstream, that I will leave to somebody else to justify
<ahasenack> I'm not that familiar with n-m
<jbicha> ahasenack: oh if you want to test, I can put it in a temp PPA for you then :)
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/nm-ipv6-openvpn-1758331/+packages is building with the patch
<jbicha> I think we should update to 1.10.6 for bionic anyway so that was my plan eventually
<ahasenack> I'm fine with that, I just don't know n-m enough to file a FFe
<jbicha> I don't consider this as needing a FFe (new bugfix release in the stable series)
<ahasenack> I admittedly didn't go over the changelog
<mapreri> mdeslaur: btw, I'm quite annoyed by your wording in lp #1758210 that I read as "the UX is suboptimal in gnome shell, so it's trash let's remove it".
<ubottu> Launchpad bug 1758210 in hexchat (Ubuntu) "Please remove hexchat from Ubuntu" [Undecided,Won't fix] https://launchpad.net/bugs/1758210
<Laney> ahasenack: sorry, I missed your message, do you still need those tests queueing?
<mdeslaur> mapreri: huh? I didn't write that
<mapreri> oh, that was xnox
<mapreri> mdeslaur: sorry, I meshed the messages from you and xnox.
<mdeslaur> my intention by filing that bug was to push for someone to port it to gtk3, so that it can be properly confined, etc.
<jbicha> mdeslaur: could you reword the bug description and title then?
<mapreri> mdeslaur: with "Please remove hexchat from Ubuntu" as a title and subscribing the release team?
<mapreri> and then slangasek already subscribed the archive adminsâ¦
<mdeslaur> yes, at some point in the future I suspect it will be inevitable
<mapreri> right, but that's not nowâ¦ and starting with a title like that and already subscribing AA it's *very* rushed.
<slangasek> mapreri, mdeslaur: he had subscribed the release team but it's an AA call, so I changed the subscription
<mapreri> slangasek: could you please drop the AA subscription for now?
<ahasenack> Laney: yes please, I can't to it myself. No upload privs
<Laney> ahasenack: ok, running
<ahasenack> thx
<slangasek> mapreri: I don't think that's the appropriate action here.  There is a discussion in the bug log, which shows there's not a consensus for this action; I don't think unsubscribing ubuntu-archive is relevant
<slangasek> if you were counting on unsubscribing ubuntu-archive to keep an AA from acting on the bug, well, someone could just re-subscribe ubuntu-archive later
<mapreri> slangasek: ok (as long as no action is taken)
<mapreri> probably I'm a bit concerned due to how RM bugs tend to be acted upon in Debian :)
<rbasak> mapreri: IMHO, it should just be made clear that there's an objection using a bug comment. Whether or not the AAs are subscribed, it's their decision on any action they want to take, so all that anyone else can do is to make sure they're informed and leave them to decide.
<rbasak> (and the only path if you object is the tech board)
<rbasak> (and the only path if you object _to their decision_ is the tech board)
<ahasenack> Laney: hi, do you have the results of those gvfs test runs somewhere?
<xnox> mdeslaur, mapreri - yes, i like hexchat, it worked awesome with unity / messenging menu; it doesn't with shell.
<xnox> mapreri, polari does things better; so something is broken w.r.t. how hexchat sends notifications to gnome-shell.
<xnox> mapreri, i've tried polari, maybe it is just the themeing, but it really is not usable.
<xnox> eplisized topic, with full topic only in an tooltip, is not good, given that one cannot click the URLs in a tooltip
<xnox> and lack of the server buffer is also quite constricting.
<coreycb> bdmurray: we have a regression in neutron in a recent fix. i'm working through the packages atm to revert the change. would you be free in a bit to review? https://bugs.launchpad.net/cloud-archive/mitaka/+bug/1758411
<ubottu> Launchpad bug 1758411 in neutron (Ubuntu Bionic) "[SRU] Revert fix for bug 1752838 regression" [Critical,Triaged]
<bdmurray> coreycb: I'm going to take a break soon but will be back in about an hour
<coreycb> bdmurray: that's fine, thanks
<coreycb> bdmurray: ok they are ready for review in the xenial and artful unapproved queues
<smoser> wonder if someone could review my package
<smoser>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1758420
<ubottu> Launchpad bug 1758420 in cloud-init (Ubuntu) "separate grub-legacy-ec2 from cloud-init" [Undecided,New]
<Laney> ahasenack: same place, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ahasenack-gvfs-test-fixes-1713098/?format=plain
<Laney> ahasenack: e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ahasenack-gvfs-test-fixes-1713098/bionic/ppc64el/g/gvfs/20180323_165317_e7060@/log.gz "ftp: blocking job: 0x1a21e512210" is the output of the new g_debug
#ubuntu-devel 2018-03-24
<jbicha> rbasak: only testing I've done is that Debian's updated mongodb builds on all (supported) arches: https://launchpad.net/~jbicha/+archive/ubuntu/arch/+packages
<rbasak> jbicha: thanks. I'm not happy about that fix though. Without further understanding or investigation I don't want it in Bionic. I'd prefer to disable ppc64el until someone who actually understands the code confirms that it's a correct fix.
<rbasak> By disable I mean the optimisation, so the build works but the generic code path is used on ppc64el instead.
<jbicha> rbasak: is the proposed Ubuntu fix better?
<rbasak> jbicha: it's subjective. IMHO, it's certainly safer, at the cost of performance.
<jbicha> anyway, I'll let you handle all of it since you've already been working on getting mongodb updated :)
<rbasak> Thanks :)
<rbasak> I'm hoping that although I'll upload my proposed fix for now, we'll be able to get a proper confirmed fix in before Bionic's release.
<slangasek> mdeslaur: good news, autopkgtests work; unixodbc is blocked in bionic-proposed because psqlodbc's test shows that iusql is now completely broken and unable to load ODBC drivers
<mdeslaur> slangasek: crud, I'll take a look, thanks
<michagogo> slangasek: regarding the openjdk 10/11 package, canât a package be marked as replacing a different one, causing the other one to be uninstalled? Why not, when 11 is SRUâd, have it be called 11, tagged as replacing 10, and just make the meta package (default-jdk?) depend on 11 rather than 10?
<slangasek> michagogo: that's not what 'Replaces' means, no; the package manager will not automatically swap out 10 for 11 just because 11 exists and says that it Replaces 10.
<slangasek> mdeslaur: fwiw I've dug into unixodbc a bit, it seems some caller of unicode_to_ansi_copy() is relying on buffer overflowing dest by one byte and fixing the overflow means the string is wrongly truncated ;P
<Unit193> LocutusOfBorg: https://packages.qa.debian.org/r/remmina/news/20180324T213520Z.html looks a bit important.
<LocutusOfBorg> I already know Unit193 :)
<Unit193> \o/
<LocutusOfBorg> today I was with remmina main developer to a conference
<LocutusOfBorg> he asked me to wait for debian to upload :)
<Unit193> Oooooh, I never looked to see if you were a dev.  Also, do you know why they were so quick to pick up Ayatana support?  (Not that I'm complaining one bit!)
<LocutusOfBorg> no, we were together to an ubuntu-it conference
<LocutusOfBorg> yes, I know the answer
<LocutusOfBorg> "someone in debian was forcing to do the switch, and we don't care enough for one or the other solution"
<Unit193> \o/
#ubuntu-devel 2018-03-25
<soshiant> i want link download repository for ubuntu trusty
<s1aden> soshiant: ubuntu.com
<sladen> soshiant: http://releases.ubuntu.com/14.04/
<soshiant> sladen: this the ubuntu operating system and isn't repository
<sladen> soshiant: what precisely do you want to do
<soshiant> i don't internet connection
<soshiant> and want to download ubuntu repository for 14.04
<sladen> soshiant: http://ftp.ubuntu.com/ubuntu/dists/trusty/  is the APT repository
<soshiant> for local use
<soshiant> sladen: this is ubuntu repository but not downloadable
<tsimonq2> soshiant: Like I explained in a different channel, are you looking to do a full archive mirror?
<tsimonq2> You're probably looking for https://wiki.ubuntu.com/Mirrors
<tsimonq2> Specifically: https://wiki.ubuntu.com/Mirrors/Scripts
<soshiant> tsimonq2:
<soshiant> tsimonq2:i want to download from windows. i want repository link
<tsimonq2> soshiant: If you want an ISO, you're looking for releases.ubuntu.com
<soshiant> tsimonq2:this is the os and isn't repository
<flocculant> https://help.ubuntu.com/community/AptGet/Offline/Repository
<soshiant> flocculant: only link download
<soshiant> one link for all repository
<flocculant> that's how to do what you appear to want - if you don't really understand - then I suggest you go to an actual support channel like #ubuntu
<sladen> soshiant: the repo is a metadata file, that points to a subset of .deb files, out of all versions available.  This 'subset' (pointed to by the metadata) is what is
<sladen> "the release"
<sladen> soshiant: the CD image, takes an even smaller subset and stores those together as one file (an '.iso')
<soshiant> 14.04
<soshiant> trusty
<sladen> soshiant: it's a bit like walking to the local (book) library, and asking to "take all the books in the library", but all joined together as one book
<soshiant> sladen:my packages does not in inline repository of ubuntu server
<sladen> soshiant: it would require a really really big truck.
<sladen> soshiant: you want to upload a package to Ubuntu?  https://developer.ubuntu.com/
 * sladen getting more and more confused
<soshiant> so i want dowload quite repository and use localy in addition i don't internet connection
<tsimonq2> (Except that developer.ubuntu.com has been snappified and contains no useful information about actual packages.)
<soshiant> inline repository is in cd ubuntu server
<soshiant> installation cd
<sladen> use  apt-get install --print-uris foobar
<sladen> and it will print a list of URLs to .deb files to download
<alkisg> ogra_ (or anyone else that knows :D): Good morning! Using linux-image-raspi2, I get no sound devices from my raspberry pi, while it works with ubuntu-mate's "raspberrypi-kernel", which isn't an official Ubuntu package. What am I missing, some module, or it requires kernel support not found in -raspi2?
<soshiant> sladen: thank's. must to test
<Mirv> Trevinho: FYI bug #1689356 seems indeed valid with its latest comments that it started happening on 16.04 with unity 7.4.5. my living room computer is resetting the scale factor now all the time.
<ubottu> bug 1689356 in unity-settings-daemon (Ubuntu) "UI scale being reset to 1 everytime when display sleeps for a while" [Undecided,Confirmed] https://launchpad.net/bugs/1689356
<Mirv> I'm disabling screen blanking now totally (enabled it to preserve OLED TV just in case, but I think the TV can take care of itself with its automatic procedures)
<fidjifrezz> hello, sorry for my english i m french. I have a web project. It's a website to introduce open source projects with Internet poster and ease contact. Anyone is interested ?
<Mirv> lol, I'm so glad someone had this problem earlier too so I managed to fix this https://askubuntu.com/questions/723902/lightdm-doesnt-show-wallpaper-background-and-colors-are-wrong?answertab=votes#tab-top
<Mirv> I wonder if I'll need to google my own answer again still in the future
<Unit193> And the part that bugged me was 'how to fix this' rather than 'how do I fix this' >_<
<Unit193> Mirv: I have Documents/scribble for a few quick things that I may need later. :P
<Unit193> That file also has some of the strangest notes, contextless. :P
<Mirv> I have some hundred of "helpers" scripts that contain valuable tips and tricks to problems, other than that I've a long emacs org-mode notes that may or may not have something valuable
<pjotr> Hello, I've found a bug in ubiquity:
<pjotr> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1758647
<ubottu> Launchpad bug 1758647 in ubiquity (Ubuntu) "ubiquity doesn't preselect the right default keymap for Dutch" [Undecided,New]
<pjotr> cjwatson: is it possible to get this fixed in time for bionic?
<pjotr> In case there are other ubiuity devs around besides cjwatson, then their comments are just as welcome, of course.... :P
<pjotr> ubiuity = ubiquity
<cjwatson> pjotr: Sorry, I mostly don't work on ubiquity any more.
<pjotr> cjwatson: OK... Do you know whom to contact best about this?
<jbicha> pjotr: Lubuntu. It works fine in regular Ubuntu bionic (I just tested it)
<tsimonq2> Hmm.
 * tsimonq2 looks into it
<pjotr> tsimonq2: thanks!  :-)
<tsimonq2> np :)
<pjotr> tsimonq2: I should add that Dutch shows up as "Nederlands" in the language selection window of Ubiquity. Which is correct, but something you need to know if you wish to test it...
<tsimonq2> OK
<sacarde> do you know why in package ntp, not include sntp do you know why in package ntp, not include sntp binary (only for xenial) ?binary (only for xenial) ?
<mdeslaur> slangasek: I looked a bit too, there are so many commits that seem to add a byte, remove a byte, or simply do *4 to "handle unicode" that I'm now afraid to touch it ;)
<mdeslaur> I may poke at it again when I get a minute
<alkisg> ogra_: nevermind, I figured it out, I was missing a line in config.txt
<rbasak> jbicha: I'm planning on attempting another round of certbot SRUs soon.
<rbasak> (in the next week or three)
<jbicha> have fun! :)
#ubuntu-devel 2019-03-18
<cpaelzer> hi fellow packagers, I'm asking for best practise on the following case
<cpaelzer> old version: /a/b/c/FILE
<cpaelzer> now that was wrong and instead the content of FILE should be in a file at /a/b/c
<cpaelzer> conffile btw
<cpaelzer> that means not only does the path change, but also /a/b/c changes from being a directory to being a file
<cpaelzer> is for this case anything more than setting the right paths in .install and mv_conffile in .maintscript needed?
<cpaelzer> because since it is a conffile it will not be removed in the RM, but mv_conffile will rename it (on the old path) so the dir can't be removed and thereby the new path can not be used then
<cpaelzer> This almost seems I need a custom snippet in the maintainer scripts, but if someone has a good best practise I'm happy to learn
<handsome_feng> Hi, could someone who in update-manager maintenance team have a look at this: LP: #1817980, Thanks!
<ubottu> Launchpad bug 1817980 in update-manager (Ubuntu) "update-manager pull in gnome-shell in ubuntukylin" [Undecided,Confirmed] https://launchpad.net/bugs/1817980
<doko> Laney: the mutter transition still needs a gpaste upload (see nbs)
<seb128> doko, what transition, that package is not blocked in proposed (also L_aney is at a hackfest this week so might not been around much)
<doko> seb128: "see NBS"
<seb128> doko, ah, your use of 'transition' confused me
<doko> well, left-overs from the transition
<seb128> yeah, right
<seb128> sil2100, hey, do you know if we are supposed to get weekly langpack updates in disco at this point? seems like we didn't get one since the initial export?
<sil2100> seb128: oh, we should, I was sure I added it into the crontab
<sil2100> seb128: let me investigate, thanks for poking!
<sil2100> eeek
<sil2100> I commented it out
<sil2100> eh, sorry about that... let me make sure an update gets uploaded
<seb128> sil2100, thx
<sil2100> seb128: let's wait for tomorrow, 10:30, the scheduled auto-update
<sil2100> I'll make sure it goes smoothly
<seb128> wfm
<seb128> thx!
<seb128> sil2100, unsure if you know who to ping for that but it would also be good to have https://dev.launchpad.net/Translations/LanguagePackSchedule updated with the current schedule/serie
<sil2100> cjwatson: hey, could you help out and update the langpack schedule page with the current export standings?
<cjwatson> sil2100,seb128: done
<cjwatson> oh and zesty -> cosmic, one sec
<cjwatson> done too
<seb128> cjwatson, thx!
<dnegreira> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1091645 - maybe someone want to clean up that "bug"
<ubottu> Launchpad bug 1091645 in avahi (Ubuntu) "Order Xanax Online to Control Post-Traumatic Stress Disorder:" [Critical,Confirmed]
<lathiat> Curious the text got edited
<lathiat> Could edit it back
<bdmurray> seb128: towards the end of my Friday I discovered and fixed an issue with how apport calls gdb which I believe only affects disco retracing. I've pushed it to the LP retracers and things seem better there. I'll be doing some more testing today then pushing to the Error Tracker.
<seb128> bdmurray, hey, ah good to know. I pinged you last week about the nautilus/disco retraces failing, I guess that was the issue
<bdmurray> seb128: Yeah, I believe so. I went back and retraced some failures in LP from the past couple of weeks too.
<seb128> great, thx!
<alkisg> teward: hi, re: LP #1820090, is it progressing normally or is it stuck? Can I do something to help?
<ubottu> Launchpad bug 1820090 in parted (Ubuntu Bionic) "SRU: fix FAT recognition after resizing" [Undecided,New] https://launchpad.net/bugs/1820090
<teward> alkisg: well simon only just uploaded it
<teward> and I only just subbed SRU
<teward> it takes time for SRU to get to things
<teward> patience is the virtue at this point
<teward> if you WANT you can prod #ubuntu-release to move the SRU forward... but I'd advise you don't do that for a few days and let the normal gears turn
<teward> alkisg: for *my part* it's now out of my hands and in the hands of the SRU process
<teward> which means a release team member / sru member needs to look at it in Bionic Unapproved and accept it before it'll go anywhere
<alkisg> teward: oh no problem about waiting, I already have it in my PPA so there's no hurry. Thanks a lot!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<tinoco> No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id!
<coreycb> hello, we have some openstack point releases in the bionic unapproved queue if an SRU team member has a chance to review. thanks!
<coreycb> bug 1818069
<ubottu> bug 1818069 in swift (Ubuntu Bionic) "[SRU] queens stable releases" [High,Triaged] https://launchpad.net/bugs/1818069
<teward> and if an SRU team member is around, can you review https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1820090 for Bionic as well?  Since the upload for it is in unapproved and this is a pretty nasty bug that probably should be fixed sooner than later :P  (alkisg is also asking for this to land heh)
<ubottu> Launchpad bug 1820090 in parted (Ubuntu Bionic) "SRU: fix FAT recognition after resizing" [Undecided,New]
<teward> (thanks to tsimonq2 for helping get that sponsored into unapproved)
<tinoco> rafaeldtinoco was removed by: rafaeldtinoco
<ahasenack> does anybody know what happened to libnfsidmap's upstream?
<ahasenack> the "canonical" url looks abandoned and stuck at 0.25, yet I have found higher versions in other linux distributions
<ahasenack> I have a feeling people are just hacking on top of it
<ahasenack> looks like steved from redhat took over? https://fedorapeople.org/~steved/libnfsidmap/
<ahasenack> http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/ stopped at 0.25
<ahasenack> ubuntu/debian has 0.25
<doko> tseliot: are you aware that nvidia-graphics-drivers-418 has unsatisfiable dependencies?
<ginggs> doko: have all the new binaries been accepted?
<ginggs> hmm, or maybe because the transitional packages aren't built for i386...
<tjaalton> right, or they could be arch:all..
<tjaalton> or maybe not
<tseliot> doko: I'll have a look at them tomorrow
#ubuntu-devel 2019-03-19
<CarlFK> https://www.independent.co.uk/news/world/europe/brexit-france-theresa-may-deal-nathalie-loiseau-cat-a8828026.html
<CarlFK> Franceâs EU minister names her cat âBrexitâ because âhe meows loudly to be let out but wonât go through the doorâ
<tinoco> .
<CarlFK> whoops, this is not https://wiki.pumpingstationone.org/IRC :p
<lag> Does anyone know how this images is created?
<lag>   http://cdimage.ubuntu.com/releases/18.04.2/release/ubuntu-18.04.2-server-arm64.iso
<lag> There is lots of documentation regarding how to build a customised Ubuntu ISO for x86_64 (using ISOLINUX), but none for ARM64
<lag> Does anyone know of a working `mkisofs` command that works for the ISO image above?
<lag> .. or where the scripts that create this image reside?
<mwhudson> lag: the code is all in debian-cd somewhere
<lag> mwhudson: Is that a package?
<mwhudson> no, it's a branch
<mwhudson> this one https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
<alkisg> arm boxes have cds?! :)
<lag> alkisg: Sure, why wouldn't they?
<lag> alkisg: Also flashing these images onto USB flash drives and SD cards work
<alkisg> I've only seen raspberries and the like, so no idea, I didn't imagine they'd have
<mwhudson> fair warning, this code is not really designed for third party use
<mwhudson> sadly
<mwhudson> alkisg: x86_64 boxes have cds !? :)
<mwhudson> none of mine do...
<alkisg> For usb/sd cards, I thought the images were .img
<alkisg> I.e. no need for hybrid .isos with workarounds etc
<alkisg> BIOS/UEFI do have code to boot from El-torito cds, I didn't know arm firmware has that code too
<lag> alkisg: You have led a sheltered life :D
<alkisg> :D
<lag> alkisg: There is more to (ARM) life than RPi
 * alkisg would like to get sheltered from rpi as well, but has to support it in a couple of projects...
<lag> alkisg: I'm not saying it a bad platform - just that there are so many more (better) platforms out there
<alkisg> +1. Or maybe +1000. :D
<lag> Does anyone know a bit about ISO files?
<lag> alkisg: You seemed pretty knowledgable in that area (/me has lived a sheltered (ISO) life)
<lag> I have 2 files - 1 made by Canonical, 1 by me:
<lag>   https://paste.ubuntu.com/p/btdkvtnJDs/
<lag> They look the same (should be ISO9660), but when they're flashed, the partition tables look totally different
<lag> Canonical: https://paste.ubuntu.com/p/btdkvtnJDs/
<lag> Whoops - ignore that
<lag> Canonical: https://i.imgur.com/MldCw7i.png
<lag> Mine: https://i.imgur.com/uIbyFAJ.png
<lag> What gives?
<lag> CMD: xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V "Bionic: AArch64 Laptops" -o laptops-ubuntu-bionic.iso -J -l -c boot/boot.cat -partition_offset 16 -append_partition 2 0xef CDDIR/boot/grub/efi.img -e boot/grub/efi.img -no-emul-boot CDDIR
<rbasak> Is there a good answer to https://lists.ubuntu.com/archives/ubuntu-server/2019-March/007820.html ?
<rbasak> (Ctrl-C during release upgrade)
<rbasak> I would apt -f install and fix anything up manually, or better redeploy to a new release and not do a release upgrade in the first place.
<rbasak> I'm not sure if there's anything better that could be recommended.
<alkisg> lag: sorry, I haven't studied the hybrid .iso internals recently, I don't know that much. I did find some related pages on the internet about it in the past, explaining both ubuntu's and fedora's methods, but it was so long ago that I don't remember anything to help you.
<mwhudson> rbasak: yeah if dpkg --configure -a and apt install -f and friends don't fix it, either you're in for a lot of fiddling or should just start again i think
<rbasak> mwhudson: I'm wondering: is that acceptable, or a bug that we don't have a better option?
<mwhudson> rbasak: we should probably block C-c i guess...
<mwhudson> i don't know, i guess apt install -f should really fix things and any way it doesn't would pedantically be a packaging bug?
<alkisg> Maybe there's also "power loss recovery" involved, not just ctrl+c...
<rbasak> In theory all maintainer scripts are idempotent and so apt install -f should always be able to fix things.
<rbasak> But in practice do-release-upgrade exists instead of apt; doesn't that fix things up after apt is finished?
<rbasak> So perhaps do-release-upgrade needs a "resume" entry point.
<mvo> cjwatson: thanks for merging support for the new "Commands-*" indexfiles to LP. I did a quick test on disco and command-not-found there seems to be working fine and using the data from the archive.ubuntu.com indexfiles now instead of the old command-not-found-data package. so yay!
<cjwatson> Excellent
<xnox> whoop whoop
<juliank> awesome!
<rbalint> juliank, found the bug why u-u autopkgtest fails in disco when upgrading cosmic
<juliank> :)
<rbalint> i'm rather :-\, will push the fix after lunch
<tseliot> doko: things should be fine now that nvidia is finally in restricted (rather than in multiverse)
<ricotz> tseliot, without transitionals for i386 I don't see this properly working
<ricotz> and libnvidia-common-410 should be arch all
<tseliot> ricotz: let me check
<tseliot> ricotz: this should do it: http://paste.ubuntu.com/p/mbyPR5djWn/
<ricotz> tseliot, this looks good
<tseliot> good
<bdmurray> Is command-not-found information now on Ubuntu mirrors?
<bdmurray> seb128: does gnome-initial-setup still ask about automatic crash reporting?
<seb128> bdmurray, it never did on Ubuntu I think
<seb128> bdmurray, I don't think it knows how to talk to apport?
<bdmurray> seb128: I thought didier did something about that a while ago
<seb128> gnome-control-center yes
<seb128> initial setup no
<bdmurray> Ah, okay
<rbalint> seb128, juliank: I pushed the converted repo, it matches usd imports (ignoring .bzr-builddeb) https://code.launchpad.net/~ubuntu-core-dev/software-properties/+git/software-properties
<rbalint> tomorrow we can switch the default repo on lp and i push a pointer on top of the bzr repos
<rbalint> and import the few dscs missing from trusty/precise
<juliank> rbalint: Awesome!
<seb128> rbalint, great, thx
<juliank> then I'll rebase the PackageKit patch queue from Debian on top of the matching Ubuntu tag
<juliank> and then I'll rebase again on top of ubuntu/master
<juliank> It
<juliank> It will be fun
<rbalint> juliank, cool!
<rbalint> juliank, i see there used to be a git repository on alioth but it is not migrated
<rbalint> (to salsa)
<rbalint> was there anything useful or i should not care about it?
<rbalint> juliank, also are you ok with the git repo scheme? Debian uses quilt
<juliank> rbalint: I have a git repo on salsa at https://salsa.debian.org/pkgutopia-team/software-properties, but it imports the ubuntu tarballs
<juliank> rbalint: Yeah, it's fine. What I do in Debian is import the ubuntu .tar.xz and as an .orig.tar.xz, and then use 3.0 (quilt), so I can ship the same tarball
<juliank> I'll probably merge in the Ubuntu git branches into the Debian branches soon, though
<rbalint> juliank, ok, ack
<juliank> instead of continuing to import tarballs :)
<rbalint> juliank, i'm transitioning to this upstream/latest scheme, too, with my packages
<coreycb> bdmurray: hello, would you be able to take a look at keystone in the cosmic unapproved queue? this version would replace the current version that is in cosmic-proposed (2:14.0.1-0ubuntu2).
<tjaalton> LocutusOfBorg: hi, I have three patches for llvm/clang, needed by intel's "NEO" opencl compute runtime. I'll test the build tomorrow and would like to get them in disco
<tjaalton> LocutusOfBorg: all are in llvm master, but not on llvm-8
<coreycb> bdmurray: i added the additional test details to bug 1815126
<ubottu> bug 1815126 in python-networkx (Ubuntu Bionic) "[SRU] Bionic missing dependency for pydotplus" [Medium,Incomplete] https://launchpad.net/bugs/1815126
<bdmurray> coreycb: cool, thanks
<coreycb> bdmurray: np thank you
<teward> bdmurray: thanks for accepting parted to proposed for 1820090 :)
#ubuntu-devel 2019-03-20
<LocutusOfBorg> tjaalton, https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/tree/8 merge request here please?
<LocutusOfBorg> if they are in llvm-toolchain-snapshot, nice, so we don't have to keep them around on more branches
<tjaalton> LocutusOfBorg: ok, will do
<LocutusOfBorg> tjaalton, if you have them, please double check if they aren't in the one that is going uploaded probably today
<LocutusOfBorg> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/42b7383d1a6f8b5df0a7e960a17bb5230ffec61f
<LocutusOfBorg> 8.0 stable is out...
<LocutusOfBorg> https://github.com/llvm/llvm-project/releases/tag/llvmorg-8.0.0 maybe your patches are already there
<LocutusOfBorg> so we can just sync
<tjaalton> LocutusOfBorg: they are these https://github.com/intel/opencl-clang/tree/ocl-open-80/patches/clang
<tjaalton> I was told they were not queued for 8
<tjaalton> LocutusOfBorg: where do I get the tarball?
<LocutusOfBorg> tjaalton, I guess when sylvestre uploads it
<LocutusOfBorg> let me ask
<doko> oSoMoN: could you have a look at the libreoffice/s390x autopkg test failure? triggered by openjdk-8 (which isn't even installed in the test)
<oSoMoN> doko, looking
<seb128> jdstrand, iptables still looks like it's unhapy, firewalld tests with 1.8.2-4ubuntu1
<seb128> autopkgtest firewalld[1362]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables):
<seb128>                                              line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT
<seb128>                                              line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUT
<oSoMoN> doko, that looks like a flaky test, it previously failed with the same error on 2019-03-12 02:37:15 UTC, and was then retried by j_bicha and passed, I will need to look into that more closely but for now I just retried it
<doko> oSoMoN: I already did, but maybe you have better luck ;p
<oSoMoN> doko, yeah, I saw you had retried already, fingers crossed this time it passes
<tjaalton> LocutusOfBorg: they applied on top of rc5, so I sent the merge request already
<LocutusOfBorg> merged thanks
<tjaalton> cool, thanks!
<rbalint> juliank, seb128: i finalized the switch of lp:software-properties to git
<rbalint> i'm in the process of updating the precise and trusty git branches with synthetic commits
<LocutusOfBorg> tjaalton, uploading right now
<tjaalton> LocutusOfBorg: sweet
<LocutusOfBorg> let me know if it works, next upload in debian will be syncable thanks to you :)
<LocutusOfBorg> I think you should join the team, llvm and graphic people have a lot in common!
<LocutusOfBorg> (I mean, you need patches mostly each llvm release)
<LocutusOfBorg> btw next time please also update changelog in the merge request
<tjaalton> well actually I rarely need patches, this was an exception :)
<tjaalton> llvm upstream is a mystery, would be nice to have relnotes for point-releases for starters
<seb128> rbalint, great, thx
<juliank> thanks rbalint
<ahasenack> rbasak: does debian's ci also trigger dep8 tests on reverse dependencies, like we do? Do you know?
<rbasak> I think so, but am not sure.
<ahasenack> https://ci.debian.net/status/ is nice
<rbasak> rharper: have you ever seen anything like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925126 on Ubuntu?
<ubottu> Debian bug 925126 in bcache-tools "bcache-tools: Load bcache kernel module *before* registering device" [Important,Open]
<rbasak> Apparently RUN{builtin} and RUN are separate lists in udev and ordering isn't guaranteed; the reporter is hitting the wrong ordering.
<rharper> rbasak: I've not seen that before
<rharper> I suspect that the normal path is that the initramfs will load the bcache module (even if the race still exists)
<rharper> rbasak: I would be interested in confirmation of the run order
<rharper> that does seem like lots of things could break (not just bcache)
<coreycb> rbasak: hello, if you have a chance today we'd like to see if we can get nova and swift into bionic-proposed for bug 1818069
<ubottu> bug 1818069 in swift (Ubuntu Bionic) "[SRU] queens stable releases" [High,Triaged] https://launchpad.net/bugs/1818069
<ahasenack> doko: hi, does this ring a bell?
<ahasenack> doko: Can't exec "gcc": No such file or directory at /usr/share/perl5/Dpkg/Arch.pm line 126.
<ahasenack> doko: -: warning: cannot determine CC system type, falling back to default (native compilation)
<ahasenack> started happening in a test
<ahasenack> https://pastebin.ubuntu.com/p/H55y8JcMVw/
<ahasenack> it's not what failed the test, though
<doko> ahasenack: probably gcc is not installed
<Wimpress> Snapcraft Live! starts in about 5 minutes - https://www.youtube.com/watch?v=X_U-pcvBFrU
<RAOF> tjaalton: intel-mediasdk appears to use the embedded googletest/googlemock source.
<RAOF> tjaalton: debian/copyright is incorrect; a bunch of files under samples/ are 3-clause BSD (copyright claims them as MIT), a handful of files (eg: wayland-drm-client-protocol.h) are neither BSD nor MIT and don't have their licence recorded in debian/copyright.
<RAOF> tjaalton: Possibly we should split contrib/ipp out and have an actual intel-performance-primitives library, but we don't currently have one.
<RAOF> tjaalton: A quick codesearch shows that there are at least 6 packages in Debian that would use an ipp library if it existed, so maybe it's time to bite that particular bullet?
<teward> if a package is 3.0 native format do you still use quilt patches to patch it, or is there a different mechanism for making changes?
<teward> (package in question is in universe but still a valid question)
#ubuntu-devel 2019-03-21
<mwhudson> teward: no a native package means patches are not applied
<mwhudson> (not that i've attempted to SRU a native package with a debian/patches directory or anything embarassing like that)
<mwhudson> and the mechanism for making changes is ... making changes
<mwhudson> if that's not appropriate it probably shouldn't be a native package i guess
<tjaalton> RAOF: thanks, I'll clean it up
<tjaalton> meh, I'll just let intel split ipp in a public repo first
<tjaalton> there's no way to download ipp anywhere without filling a form
<RAOF> Oh, really? WTF?
<RAOF> Oh, wow. Yeah.
<tjaalton> I'll try stripping it off, only used for some sw fallback
<RAOF> Good hustle, Intel.
<tjaalton> and let them know about it
<JZA> hi got a question about how to mantain a package on launchpad
<JZA> currently there is a team account with a package, but I want to get a testing branch from my user
<JZA> how do I go about that
<tjaalton> RAOF: oh well, can't build it without embedded ipp or gtest. I'll just wait for them to fix it
<lag> Hmm ... not sure my messages went through - apologies for the churn if they did:
<lag> Does anyone know how to tell the Ubuntu Installer to install additional modules into the rootfs?
<lag> s/modules/kernel modules/
<lag> I guess we could hack initramfs-tools.deb to include them in the '/etc/initramfs-tools/modules' template, but is there a better/proper way to do this?
<RAOF> tjaalton: ipp is not a (strong) blocker, but it should really use the perfectly sensible copy of googletest we have.
<tjaalton> or disable tests
<tjaalton> anyway, filed tickets upstream
<lag> xnox: mwhudson: FYI --^
<dupondje> Its to late in the release schedule for merges? Or are some still accepted?
<dupondje> mwhudson: https://merges.ubuntu.com/g/golang-1.12/REPORT
<Mirv> Trevinho: thank you so much for continous maintenance of the AppIndicator/KStatusNotifierItem extension!
<Trevinho> Mirv: :) well actually I should spend much more time on it as there are various issues I had no time to address yet, but thank you :)
<tjaalton> ahasenack: hey, do you have plans to push the samba/talloc etc py3 work to debian?
<ahasenack> tjaalton: yep
<ahasenack> tjaalton: as soon as I'm done with the disco work, which should be tomorrow
<tjaalton> ahasenack: ok cool, for experimental I assume?
<ahasenack> that will be up to them
<ahasenack> I'm planning on salsa mps
<tjaalton> right
<ahasenack> (I can't upload to debian myself)
<ahasenack> experimental sounds right
<coreycb> sil2100: hello, if you have a moment we have swift and nova SRUs in the bionic unapproved queue that we'd like to get going on with testing.
<sil2100> coreycb: let me try getting to those after the kernels
<sil2100> o/
<coreycb> sil2100: thanks!
<juliank> What's the status of Kubuntu package management?
<juliank> Does it use PackageKit or that QApt thing?
<juliank> I'm porting software-properties to PackageKit, but only the GTK+ one so far
<juliank> Currently the Qt one is a weird mix of aptdaemon and qapt-batch
<teward> mwhudson: just saw your message.  It probably doesn't matter much either way, but iptables-persistent has a liiitle bit of a bug in it - https://bugs.launchpad.net/ubuntu/+source/iptables-persistent/+bug/1820144 - so i was wondering how best to prep changes for the SRU.  So just changing it directly, then, would be the proper course since its a native package and not a quilt one?
<ubottu> Launchpad bug 1820144 in iptables-persistent (Ubuntu Cosmic) "iptables-persistent fails in containers due to modprobe being unavailable even though module could've been loaded outside of the container" [Undecided,Confirmed]
<Kiranos> Hi I have an issue, I'm trying to automate the ubuntu 18.04 installation with preseed, this is how partitioning look like: https://pastebin.com/xm6dQiuV
<Kiranos> however I get a prompt like this: https://imgur.com/a/W2sj7yu
<Kiranos> I'm not sure which option I miss
<Kiranos> I look at https://help.ubuntu.com/lts/installation-guide/i386/apbs04.html and seem to follow it
<Kiranos> if I just hit enter on that screen all is just continuing and finalizing
<sil2100> coreycb: sorry for it to take so long, let me take a look at your SRUs now
<cyphermox> Kiranos: your config is not selecting the recipe; or you are not specifying guided_size, up to you ;)
<cyphermox> you would need either "d-i partman-auto/choose_recipe select root"
<cyphermox> that's if you want preseed to follow exactly your recipe there
<cyphermox> Kiranos: or if you want to use the guided partitioning, you'll want to preseed:
<cyphermox> d-i partman-auto-lvm/guided_size string "max"
<cyphermox> for example
<CarlFK> d-i partman-auto-lvm/guided_size string max
<CarlFK> before d-i partman-auto/expert_recipe string Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  \
<sil2100> coreycb: ugh, why is there an UNRELEASED changelog entry in the changelog for swift?
<coreycb> sil2100: checking
<sil2100> coreycb: if 2.17.0-0ubuntu1.1 was unreleased, I guess it should be included in 2.17.1-0ubuntu1
<sil2100> coreycb: could you re-upload with that fixed? Other than that it's good to go
<coreycb> sil2100: yeah let me fix that. thanks for catching it.
<sil2100> coreycb: give me a sign once you upload, I accepted nova in the meantime
<sil2100> I'll reject the old swift
<coreycb> sil2100: should be there soon, just uploaded it. thank you.
<sil2100> yw! Thanks for reuploading, approved
<jdstrand> cjwatson: hey, does debmirror need any special support for cnf? (command-not-found)
<jdstrand> cjwatson: I noticed apt-get update errors on disco and it doesn't seem to pull it. I'm going to use --include and see if that helps
<cjwatson> jdstrand: it probably will do, yes
<jdstrand> cjwatson: I couldn't get that to work. looked at the dep11 handling and can steal code from there. if I get it to work I'll file a bug with patch
<mwhudson> dupondje: i should merge golang-1.12 yeah
<mwhudson> teward: yes
<teward> mwhudson: ack.  I'll take that approach then.
<CarlFK> when bionic runs my systemd script, HOME is not set.  disco and stretch it is set.  I can work around this in my script.  Should I file a bug?
<rbasak> rharper: FYI, that bcache bug I asked about was apparently a udev bug
<rharper> rbasak: thanks; i really looked like a udev issue; I suspected that many other rules could break as wekk
<rharper> well
<jdstrand> cjwatson: fyi, bug #1821251
<ubottu> bug 1821251 in debmirror (Ubuntu) "please add cnf support to debmirror" [Undecided,New] https://launchpad.net/bugs/1821251
<jdstrand> cjwatson: patch is attached
<xnox> CarlFK, yes, and also describing the sample script, systemd unit, and whether it is installed as user or system wide.
<xnox> CarlFK, potentially you might be able to reproduce it with like systemd-run
<CarlFK> xnox: is there a package I should file against ?
<xnox> CarlFK, $ ubuntu-bug systemd
<CarlFK> thanks
<CarlFK> is there a "hello systemd" I can use to demo my HOME issue?
#ubuntu-devel 2019-03-22
<mwhudson> ExecStart=/bin/echo $HOME would probably be enough here?
<CarlFK> just that one line?
<xnox> mwhudson, well, systemd will substitute that in the unit. I'd rather see something like
<xnox> ExecStart=/bin/sh -c 'echo $HOME'
<mwhudson> oh right
<xnox> or maybe it needs like \$HOME
<xnox> ah
<xnox> ExecStart=/bin/sh -c 'env | grep HOME'
<xnox> muahahahhaha
<sarnold> lol
<CarlFK> yeah - ans sh is linked to dash, which is different from bash  and $HOME and ~ are surprising me a little too
<xnox> CarlFK, that's why i want specifics of how/what works for you in one release, but not the other, and wheather it is sensible or not.
<xnox> sarnold, bah
<ahasenack> doko: hi, do you remember what happened to your mongodb "No-change rebuild for boost soname change" in cosmic, 1:3.6.3-0ubuntu2? I don't see it in rmadison, nor publishe in https://launchpad.net/ubuntu/+source/mongodb
<ahasenack> ah, it failed to build
<teward> ah, small question, I should probably know this but, if a package I'm working on ends in a +nmuX version string, would the Ubuntu one be +nmuXubuntuY for an Ubuntu modified version of the package?
<teward> there's no documentation of such examples on the security team's documentation for the 'version string' guide so sorry for the stupid question
<rbasak> teward: I'm not aware of any convention. I think +nmuXubuntuY would be fine.
<teward> rbasak: that's what I thought, and what sarnold thought, interesting though there's no examples in the documentation :p
<xnox> teward, i recall hainv a ubuntuX+nmuYubuntuZ
<rbasak> My long term plan is to have "git ubuntu lint" expect one (and only one) answer for every input case.
<xnox> teward, because somebody uploaded ubuntuX string to debian, then it got nmued, and then we had to patch that again in ubuntu....
<rbasak> The code is already there; it's just not integrated yet.
<rbasak> https://git.launchpad.net/usd-importer/tree/gitubuntu/versioning.py#n342
<rbasak> Please feel free to add additional cases :)
<teward> xnox: indeed, that makes sense, though I"m surprised it was never added into the documentation as an example, guess I"ll ask the sec team to update their documentation :p
<teward> rbasak: not every package is in git ubuntu last i checked though?
<rbasak> And then eventually I'd like to split that code out into some kind of library, and for Ubuntu's official answer to be "what the library does; file a bug against the library where it's wrong"
<teward> or has that changed?
<rbasak> teward: you're correct
<teward> yeah the package in question isn't ;)
<rbasak> But the code that works out the next version is fairly independent - just not split out as an API, but it could be.
<teward> (iptables-persistent is not there, nor is it a quilt package which made me headscratch for a moment xD)
<ahasenack> doko: did you investigate more that mongodb ftbfs in cosmic?
<doko> ahasenack: sorry, no
<ahasenack> it looks like gcc issues
<ahasenack> new warnings, that kind of stuff
<doko> cosmic?
<ahasenack> yeah
<ahasenack> cc1plus: all warnings being treated as errors
<ahasenack> https://launchpadlibrarian.net/416133571/buildlog_ubuntu-cosmic-amd64.mongodb_1%3A3.6.3-0ubuntu1.18.10.1_BUILDING.txt.gz
<ahasenack> Werror=class-memaccess pops up a lot
<doko> ahasenack: and works in disco?
<doko> die, -Werror, die
<ahasenack> doko: haven't checked, but it's another version in disco
<ahasenack> seems to build fine in bionic, same version as cosmic
<ahasenack> (ppa still buildinf)
<doko> bionic is GCC 7
<ahasenack> I remember having to deal with this with squid
<ahasenack> which is c++ too
#ubuntu-devel 2019-03-23
<CarlFK> xnox: fun fact: my ansible  home ~ problem was not different OS/systemd things but different ansible versions.
<CarlFK>  # This is a hack and should be solved by more intelligent handling of remote_tmp in 2.7  https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/__init__.py#L335
<CarlFK> there may still be some undesirable behavior in ansible, but I don't care.
#ubuntu-devel 2019-03-24
<cjwatson> wgrant: Do you fancy merging debmirror for disco?  You TIL, and jdstrand wanted the fix for bug 1821251 which is in unstable now.
<ubottu> bug 1821251 in debmirror (Ubuntu) "please add cnf support to debmirror" [Medium,Fix committed] https://launchpad.net/bugs/1821251
<cjwatson> Several other fairly important fixes in the interim too.
<Unit193> Unfortunate, apt-ftparchive doesn't seem to have grown support for them.
<wgrant> cjwatson: Ah, will do
#ubuntu-devel 2020-03-16
<alkisg> Hi, I want to upload a new ltsp in debian, which will contain only bug fixes, and then sync to focal; that still doesn't require an FFE, right?
<ginggs> alkisg: correct
<alkisg> Thank you ginggs
<ailion> Hi
<ailion> How can I get the exact kernel source code running on a server?
<ailion> e.g. # uname -a
<ailion>          Linux mirrors 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
<doko> cpaelzer: do you plan to remove mailman2 in focal?
<Odd_Bloke> ai_lion: That sounds like a question that would be more appropriate in #ubuntu-server. :)
<ai_lion> Odd_Bloke: maybe...
<ai_lion> I'm following this wiki page: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<Odd_Bloke> ai_lion: Aha, then perhaps #ubuntu-kernel?
<ai_lion> "apt-get source linux-image-$(uname -r)" results in something not kernel source code
<ai_lion> emmmm
<ai_lion> ok
<cpaelzer> doko: we had no further plans on mailman
<cpaelzer> which translates to keep things as they are synced from debian
<cpaelzer> doko: did you want to remove it for the py2 deps or what makes you ask?
<GunnarHj> Hi vorlon, wondering about bug #1171844 (comment #18). You uploaded gfxboot-theme-ubuntu on March 8 and debian-installer was last built on March 10. Is there more into it?
<ubottu> bug 1171844 in debian-installer (Ubuntu) "Ubiquity: Tajik Language Support" [Undecided,New] https://launchpad.net/bugs/1171844
<ahasenack> teward: nginx ffe approved
<teward> ahasenack: ack.  upload in progress.
<ahasenack> thanks
<ahasenack> I'll take care of the rest
<teward> fek i think i forgot to mark the bug in the changelog
<teward> how good i can cancel :p
<teward> ahasenack: do you want me to mark it as closing LP #1867150
<ubottu> Launchpad bug 1867150 in nginx (Ubuntu) "FFe: nginx: demote bin:libnginx-mod-http-geoip" [Undecided,Triaged] https://launchpad.net/bugs/1867150
<teward> in the changelog
<ahasenack> teward: yes please
<teward> uploaded.  system accepted it from the upload queue into proposed
<ahasenack> I'll monitor migration
<teward> yep.  needs to build first heh.  https://launchpad.net/ubuntu/+source/nginx/1.17.9-0ubuntu2
<ahasenack> details
<vorlon> GunnarHj: AFAIU the debian-installer rebuild should have picked up the changes from gfxboot-theme-ubuntu, so at this point I don't know why it didn't take effect
<GunnarHj> vorlon: :( I looked at the d-i build depends, and didn't find gfxboot-theme-ubuntu.
<vorlon> GunnarHj: d-i is sketch and pulls most of its stuff directly from the archive rather than as build-dependencies
<GunnarHj> vorlon: Ack.
<GunnarHj> vorlon: Will you investigate when you have a minute? The installer stuff is way over my head.
<vorlon> GunnarHj: I'm having a look right now but I'm actually off today
<vorlon> GunnarHj: ok, found a spot I missed in gfxboot-theme-ubuntu, reuploading now; won't land in the images until there's another d-i upload for another reason
<GunnarHj> vorlon: Thanks! Crossing my fingers, then.
#ubuntu-devel 2020-03-17
<xnox> vorlon:  d-i uploaded for another reason!
<vorlon> xnox: cheers
<seb128> vorlon, hey, so, libgphoto2 has a bit of a weird autopkgtest, it does autoreconf/configure/make check its source, which fails on i386 on configur not fiding ltdl
<seb128> do you think it makes sense to try to cross compile or is it fine to just badtest that one on i386?
<vorlon> seb128: I think a cross-compile would be better
<seb128> vorlon, k, adding to the backlog of things we need to look at then (webkitgtk is high on that list, I will try to make progress today)
<seb128> hum, autopkgtest, so http://autopkgtest.ubuntu.com/packages/s/sbd/focal/amd64 is often failing with
<seb128> 'sudo: /tmp/autopkgtest-run-wrapper: command not found'
<seb128> but sometime it success ... is that command supposed to be always available? or is it by luck on some images?
<seb128> juliank, hey, do you know maybe about ^ ?
<OxThiebaut> Hi! Any plans to port https://ubuntu.pkgs.org/18.04/ubuntu-universe-amd64/nfqueue-bindings-perl_0.6-1build2_amd64.deb.html to ubuntu 19? (Appologies if wrong channel)
<ginggs> OxThiebaut: it's not recent Ubuntu because of release critical debian bug #906495
<ubottu> Debian bug 906495 in src:nfqueue-bindings "nfqueue-bindings: FTBFS in buster/sid (add_custom_target cannot create target "nfqueue_swig_compilation")" [Serious,Open] http://bugs.debian.org/906495
<OxThiebaut> Thanks for the quick and precise response. Have a good day!
<seb128> Laney, do yo maybe know about my question from earlier and 'autopkgtest-run-wrapper: command not found' errors and if they are sign on an image issue usually?
<Laney> seb128: no, probably the real error is further up
<Laney> that is just something which gets printed as part of dumping some logs on failure
<seb128> that's what I was wondering, thanks
<Bun> Is there any information available on how Ubuntu Base images are created?
<Eickmeyer[m]> Do we have any progress on bug 1851346?
<ubottu> bug 1851346 in ubiquity (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<oSoMoN> vorlon, lp:ubuntu-themes isn't up-to-date with the contents of the archive, it's missing https://launchpadlibrarian.net/451540523/ubuntu-themes_19.04-0ubuntu1_19.04-0ubuntu2.diff.gz , would you mind pushing that change to the branch?
 * ogra hugs sil2100 
<seb128> hum, does anyone know what's the easiest way to 'simulate' an i386/focal autopkgtest environment?
<Laney> seb128: Use amd64 and pass a --setup-command "dpkg --add-architecture i386; apt update" or something like that
<Laney> Would be useful to add that to https://wiki.ubuntu.com/ProposedMigration/#autopkgtests if it works for you
<seb128> Laney, I will try and update if it works, thanks
<Laney> thanks to you!
<Laney> I think I gave Steve a review comment on his MR upstream to make this automatic
<ahasenack> kanashiro: so you want 1.3.0-5 in focal
<ahasenack> plain 1.3.0-5? no ubuntu changes needed?
<rafaeldtinoco> node-uglifyjs-webpack-plugin | 1.3.0-5         | unstable         | source, all
<rafaeldtinoco> kanashiro: needs that package in focal
<kanashiro> ahasenack, exactly
<rafaeldtinoco> but im thinking about upgrade path
<rafaeldtinoco> you cant sync to the same version in focal
<ahasenack> ok, and that failed because this existed in focal before, and was removed
<ahasenack> "Depends on node-webpack, removed in favor of node-acorn transition" <-- do you know what this means?
<kanashiro> ahasenack, during node-acorn transition node-webpack FTBFS I think
<kanashiro> but the current version of it in Debian unstable is fixed
<ahasenack> node-webpack we have in focal-proposed
<ahasenack> from you, actually
<kanashiro> yes, with a delta
<kanashiro> I want to drop the delta
<kanashiro> and make it a sync
<kanashiro> to do that I need node-uglifyjs-webpack-plugin
<rafaeldtinoco> ahasenack: and im proposing to upload node-uglifyjs-webpack-plugin with versioning
<rafaeldtinoco> so its not the same as eoan
<ahasenack> you will need to make node-uglifyjs-webpack-plugin something like 1.3.0-5build1
<rafaeldtinoco> and it allows eoan to upgrade (not that will upgrade)
<rafaeldtinoco> 1.3.0-5build1 would be in eoans upgrade path
<rafaeldtinoco> if it gets rebuilt
<rafaeldtinoco> for whatever reasons
<ahasenack> a "buildN" suffix also doesn't block future automatic syncs
<rafaeldtinoco> hum I do a build1
<ahasenack> use dch -R (iric) for the changelog
<rafaeldtinoco> and then after its good
<rafaeldtinoco> a sync again ?
<ahasenack> no
<ahasenack> you will have to grab the source
<rafaeldtinoco> do a -R and upload
<rafaeldtinoco> with build1 versioned
<ahasenack> add a new d/changelog entry, call it 1.3.0-5build1
<ahasenack> and upload
<ahasenack> and that's it
<rafaeldtinoco> yep.. my doubt
<rafaeldtinoco> eoan has the same version
<rafaeldtinoco> lets suppose SRU is done and a rebuild is needed in eoan
<ahasenack> if debian releases 1.3.0-6, and the archive is open again (no FF), ubuntu will sync it automatically
<rafaeldtinoco> build1 would be a version that eoan would also use
<rafaeldtinoco> thats the main concern
<ahasenack> then whoever is doing the sru to eoan has to come up with a version number that fits between 1.3.0-5 and 1.3.0-5build1
<rafaeldtinoco> of everything we are saying
<rafaeldtinoco> ahasenack: gotcha. works for me
<rafaeldtinoco> thanks for checking this
<ahasenack> according to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation, that would be 1.3.0-5ubuntu0.1
<rafaeldtinoco> yep
<ahasenack> 2.0-2build1                   2.0-2ubuntu0.1
<ahasenack> from their example
<ahasenack> no, wait
<ahasenack> that's for focal
<rafaeldtinoco> yep i was almost putting 1.3.0-5ubuntu1 for focal
<rafaeldtinoco> and letting eoan to have 1.3.0-5ubuntu0
<ahasenack> some ~ might be involved
<rafaeldtinoco> if ever needed
<ahasenack> for an eoan sru
<rafaeldtinoco> they could do 1.3.0-5~ubuntu1
<rafaeldtinoco> etc.. if needed
<ahasenack> 2.0-2 in two releases         2.0-2ubuntu0.11.10.1 and 2.0-2ubuntu0.12.04.1 <-- that case I think, if the sru affects focal as well
<ahasenack> but it has a solution
<rafaeldtinoco> ok.. i'll go with a build1
<rafaeldtinoco> to keep things simple for now
<ahasenack> it's correct for focal
<rafaeldtinoco> cool thx!
<rafaeldtinoco> kanashiro: ^
<cjwatson> rafaeldtinoco: It would be up to a future hypothetical SRUer not to collide.  Just suffixing build1 is correct for the development series, indeed.
<rafaeldtinoco> cjwatson: cool! thanks for clarifying
<vorlon> oSoMoN: sorry, I'm out of office today, probably best if you can push the changes there yourself?
#ubuntu-devel 2020-03-18
<alkisg> Hi, I got ltsp uploaded into debian and I tried to sync it with focal: syncpackage -d sid ltsp
<alkisg> But I got: syncpackage: Error: The signer of this package is lacking the upload rights for the source package, component or package set in question.
<alkisg> Would this be because I'm DM and not a DD? Or is it because the ltsp binary packages have been renamed and I somehow lost upload rights?
<alkisg> I'm properly listed in "Original Maintainers (usually from Debian)" in https://packages.ubuntu.com/source/focal/ltsp ...
<Unit193> alkisg: You could try running: `ubuntu-upload-permission ltsp`
<alkisg> Unit193, it only allows:  * MOTU (motu) [team]
<Unit193> Just in case you weren't aware, upload rights in Debian don't imply upload rights in Ubuntu.
<alkisg> I did upload ltsp/ldm etc in the past
<alkisg> *sync
<Unit193> OK. :)
<alkisg> I do not remember how I asked for permission for that though; maybe now that ltsp binaries changed name, it needs some updating?
 * alkisg re-reads https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage ...
<alkisg> Hmmm it's possible that I had only synced epoptes, and not ltsp; for epoptes, I do have rights due to edubuntu-dev...
<alkisg> How can I ask someone to sync ltsp for me, until I get upload rights myself? It's a bug-fix only release, it doesn't need FFE
<ginggs> alkisg: i'll do it
<alkisg> Thank you very much ginggs :)
<Unit193> Heh, that's one I could even help with.
<ginggs> alkisg: there you go
<alkisg> Thanks guys!
<Unit193> I was in looking through https://people.canonical.com/~ubuntu-archive/packagesets/focal/
<alkisg> I guess if ltsp was added in https://people.canonical.com/~ubuntu-archive/packagesets/focal/edubuntu, I'd then have enough rights... /me checks how to request that...
<mwhudson> Package openssh-server is not available, but is referred to by another package.
<mwhudson> This may mean that the package is missing, has been obsoleted, or
<mwhudson> is only available from another source
<mwhudson> you what
<mwhudson> from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntu-server-live/+build/207898
<mwhudson> oh   Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8001::23). - connect (101: Network is unreachable) Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8001::24). - connect (101: Network is unreachable) Could not connect to archive.ubuntu.com:80 (91.189.88.142), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.88.152), connection timed out
<mwhudson>  
<LocutusOfBorg> seb128, I think libgusb sync is better than the current version
<LocutusOfBorg> debian reverted the abi changes
<doko> mitya57: https://launchpad.net/ubuntu/+source/gnumeric/1.12.46-1ubuntu2  not sure what the way forwarded is ... drop python2 support for the plugins?
<doko> cpaelzer, ahasenack: python-maxminddb needs a team subscriber
<ahasenack> doko: will get it once powersj starts his day
<cpaelzer> doko: I already asked for it
<mitya57> doko: gnumeric's maintainer is another Dmitry
<doko> damn ;p
 * xnox shakes fist too
<seb128> locutus_, @libgusb, thanks for the notice
<doko> xnox: https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1867935 fyi.  not sure if that's still needed in the distro
<ubottu> Launchpad bug 1867935 in wsmancli (Ubuntu) "remove openwsman and rdep wsmancli" [Undecided,New]
<xnox> doko:  pinged certification & maas teams to see if they might know it. Simply based on past people who uploaded this.
<powersj> ahasenack, doko ubuntu-server is now subscribed to python-maxminddb
<ahasenack> thanks
<ahasenack> cjwatson: hi, just checking in if you saw the last comment on https://bugs.launchpad.net/ubuntu/+source/libfido2/+bug/1864439 and if you are planning on updating libcbor?
<ubottu> Launchpad bug 1864439 in libfido2 (Ubuntu) "[MIR] libfido2, libcbor (dependencies of openssh)" [Undecided,New]
<cjwatson> ahasenack: I am not; perhaps somebody else can?
<rbasak> src:what-is-python
<rbasak> I like the name :)
<ahasenack> cjwatson: ok, I'll take a look
<cjwatson> Thanks
 * cjwatson doesn't need more distractions from making Built-Using work :)
<xnox> rbasak:  me too =) but steve doesn't
<xnox> vorlon:  rbasak likes the package name i made, so we should totes keep it now
<xnox> =))))))))))))))))))))
<vorlon> xnox, rbasak: "baby don't hurt me" missing from the binary package descriptions
<xnox> vorlon:  ok I will add XS-Theme-Tune: baby don't hurt me
<ahasenack> hi, do we have any sphinx experts here?
<ahasenack> i'm trying to change a package to rebuild the docs. The tarball is shipping the built documentation,
<ahasenack> but I noticed a _sources/ directory which has the .rst file
<ahasenack> looks like all I'm missing is conf.py (which sphinx-quickstart generates?)
<ahasenack> bryce: rafaeldtinoco: rbasak: wdyt, ok to sync? https://paste.ubuntu.com/p/Qgr5ZcnqQV/
<ahasenack> I need that bugfix (I'm trying right no to see if it's enough for my problem, will know in a few)
<ahasenack> oh, sorry, that's sphinx
<ahasenack> diff between 1.8.5-5 and 1.8.5-6
<bryce> andersk_, what you pastebinned LGTM
<ahasenack> so, this lintian tag: https://lintian.debian.org/tags/source-is-missing.html
<ahasenack> :)
<sarnold> the 404 is a nice touch :)
<mwhudson> uh does the dead-snakes ppa not support focal? :(
<Unit193> Poor snakes. :(
<rafaeldtinoco> rbasak: https://bugs.launchpad.net/ubuntu/+source/drbd-utils/+bug/1866458 -> sorry, I failed to see you were expecting a 4.15 test here. just did it. thanks for reviewing!
<ubottu> Launchpad bug 1866458 in drbd-utils (Ubuntu Bionic) "drbd not working after kernel upgrade 5.0.x -> 5.3.x" [Medium,In progress]
#ubuntu-devel 2020-03-19
<mruffell> does anyone know why the default kvm eumlator on focal is /usr/bin/qemu-system-x86_64 directly, and not /usr/bin/kvm-spice?
<mruffell> I filed a bug for the above ^^ https://bugs.launchpad.net/bugs/1868029
<ubottu> Launchpad bug 1868029 in libvirt (Ubuntu Focal) "focal not using /usr/bin/kvm-spice as default emulator" [Undecided,New]
<cpaelzer> mruffell: answered on the bug, TL;DR the change is intentional
<cpaelzer> doko: is there a place with e.g. upstream builds of all gcc minor releases or something like it?
<cpaelzer> doko: I might want to "bisect" through those a bit, and having soem pre-built would help
<doko> cpaelzer: no, ubuntu-toolchain-r ppa/test has some
<doko> what are you looking for?
<cpaelzer> I'm hunting down a qemu issue that turned out to be a seabios issue that turned out to -maybe- be a compiler issue
<cpaelzer> TL;DR something after Disco changed and in build environments since then the resulting binary breaks on older Penryn chips
<doko> ugh
<doko> not the clash-protection stuff that s m b reported?
<cpaelzer> a new case for sure, but mabye eventually the same reason
<cpaelzer> doko: it is indeed again fcf-protection
<cpaelzer> doko: I'll submit a fix to disable it to the seabios project, I'll CC you in case there are any "why is fcf on" questions
<tsimonq2> On 2019-10-18 19:40z (152 days 16 hours 32 minutes ago), you uploaded a
<tsimonq2> file with French (fr) translations for templates in Ubuntu Focal package
<tsimonq2> "lintian" to Launchpad.
<tsimonq2> We were unable to import the file because of errors in its format
<tsimonq2> Why would I get an email like this?
<tsimonq2> I don't have TIL last time I checked.
<tsimonq2> Also, hello. I've been fairly absent as of lately.
<cjwatson> tsimonq2: Note the rather old date; https://launchpad.net/ubuntu/+source/lintian/+publishinghistory says you synced 2.28.0 then.  I'm guessing somebody just unstuck a translation approval queue.
<tsimonq2> Nice.
<tsimonq2> Thanks.
<coreycb> hello release team, I'd like to bump python-decorator from 4.3.0 to 4.4.2. new versions of openstacksdk won't work with decorator < 4.4.0. the delta is mostly bug fixes and most of the non-openstack reverse depends are in universe.
<ddstreet> cjwatson quick q, i have a build recipe in LP, but the resulting source package in the ppa is not signed...is there a way to get LP to sign recipe-built source packages?
<cjwatson> No
<ddstreet> ok, thnx :)
<cjwatson> Almost nothing relies on signatures on source packages anyway
<cjwatson> The containing archive is signed
<ddstreet> well pull-lp-source does at least try to check them
<ddstreet> but yeah, it's not really useful since lots of src pkgs are signed by keys that aren't in the debian keyring
<seb128> sil2100, hey, could we have langpacks rolled for focal? looks we have none since the start of the cycle?
<cjwatson> It's possible we never got the crontab set up.  I think I was waiting for some kind of confirmation before doing that
<cjwatson> Indeed, looks like it
<cjwatson> In the short term this is our (LP's) problem not sil2100's
<seb128> cjwatson, thanks, I'm going to ask on #launchpad
<cjwatson> seb128: Well I just made progress on it so ...
<seb128> cjwatson, k, thanks
<sil2100> Yeah, sorry about that, GunnarHj pinged me about it a while ago but I was deep in other stuff
<sil2100> cjwatson, seb128: so is the first translation export running right now? Or is there something else we still need to do before that can happen?
<cjwatson> sil2100: Could you apply https://code.launchpad.net/~cjwatson/langpack-o-matic/focal/+merge/380897 ?
<cjwatson> And then it should be sorted out automatically next week
<cjwatson> It isn't running right now - I was going to leave it to cron
<cjwatson> Can run it if it's more urgent than that though, I guess
<sil2100> cjwatson: when is the focal export planned? I usually do the first full base packs manually, so I can do those whenever we get the export
 * sil2100 checks the Full language pack export checkbox
<sil2100> It's not urgent or anything
<seb128> urgent it's not, but it would be useful to be able to test whether strings are translatable/translated
<seb128> if it's not too expensive to kick an export now it would be nice still
<seb128> we are not that far from beta
<GunnarHj> Agree with seb128 here. There av dozens of translators out there who would like to check the result of their work.
<cjwatson> If I do nothing it'd be Tuesday
<cjwatson> I'll go and request one
<sil2100> cjwatson: thank you! In that case I'll create the first base packs tomorrow
<sil2100> GunnarHj: ^
<seb128> cjwatson, thanks
<seb128> hey GunnarHj :)
<sil2100> GunnarHj: (sorry it took so long, it's a bit crazy again)
<GunnarHj> sil2100: Np. I understand about priorities.
<cjwatson> Dropped ball here I think.  I think I missed https://lists.launchpad.net/ubuntu-translations-coordinators/msg11353.html
<cjwatson> Ah, because it wasn't CCed to me
<cjwatson> So the state machine I was running hung
<cjwatson> Export is running now on the LP side; should take a few hours.
<GunnarHj> sil2100: Btw, good if you keep bug #1864680 in mind.
<ubottu> bug 1864680 in localechooser (Ubuntu) "Revival of language packs for Kurdish (Sorani)" [Medium,Triaged] https://launchpad.net/bugs/1864680
<seb128> sil2100, btw I updated the proposed migration mp with the import a new line
<sil2100> GunnarHj: will do!
<sil2100> cjwatson: thank you!
<sil2100> seb128: thanks, looking o/
<xevious> bryce: Do you have a link that shows the build status for the PHP 7.4 packages? I only see php-text-captcha (its status says it's waiting on php-numbers-words) on the build failures link in the topic.
<ahasenack> kanashiro: this is the only red remaining for gem2deb, I found the right combination of triggers for the ruby-commander reds and those will clear next round
<ahasenack> http://autopkgtest.ubuntu.com/packages/r/ruby-activeldap/focal/armhf
<ahasenack> kanashiro: any idea? ^
<ahasenack> it passed with gem2deb/1.0.5, but failed with gem2deb/1.0.5ubuntu1
<ahasenack> 1second diff
<ahasenack> <"2020-03-12T14:39:59Z"> expected but was
<ahasenack> <"2020-03-12T14:39:58Z">
<kanashiro> ahasenack, it might be an issue just in armhf because of timing
<kanashiro> yes, just checked this failure log
<ahasenack> let me retry it
<ahasenack> thanks
<ahasenack> doko: hi, if you are still around, about one paragraph in the bind9.16.1 release notes here: https://downloads.isc.org/isc/bind9/9.16.1/RELEASE-NOTES-bind-9.16.1.html
<ahasenack> " Feature Changes"
<ahasenack> about pthread-rwlock
<ahasenack> bind is switching from their own implementation (?) to the glibc one
<ahasenack> "The system-provided POSIX Threads read-write lock implementation is now used by default instead of the native BIND 9 implementation"
<ahasenack> any comment about that? Should we follow this upstream change, or disable it? Note the bug they mention affects only bionic
<bryce> hi xevious, sorry was in a meeting, yes I have a link one sec
<bryce> xevious, what I've been looking at is this page - https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server
<bryce> under ubuntu-server, the php-defaults bullet lists the php-horde regressions, with links to logs
<bryce> I'm going to send an email to the ubuntu-server@lists.ubuntu.com mailing list with a longer list of packages and what I noticed in a cursory look
<GunnarHj> Hi vorlon, sorry to bother you again about this, but d-i has been built after your latest upload of gfxboot-theme-ubuntu, and still no tg language in the isolinux menu (checked today's daily build).
<ahasenack> kanashiro: passed on a simple retry: http://autopkgtest.ubuntu.com/packages/r/ruby-activeldap/focal/armhf
<ahasenack> good
<ahasenack> gem2deb will migrate in the next run then, or the one after
<kanashiro> ahasenack, good :)
<xevious> bryce: Have you already sent that? If not, let me subscribe first.
<bryce> xevious, sorry not yet, got caught up in some followup meeting notes
<xevious> No worries. I'm not going to be able to really look into this until tomorrow, anyway. I subscribed to the mailing list, so I'll keep an eye out for your post.
<bryce> xevious, great!
<doko> ahasenack: hmm, where should that be added?
<pgnd> juliank: to your comment in convo with hggdh re: grub update 'vs' continuation lines, specifically:
<pgnd> <juliank> So they made a change in their files between those and that blew up after the upgrade
<ahasenack> doko: it's a new default in bind9.16.1's ./configure, i.e., without doing anything, we get the changed behavior
<pgnd> nope.  no changes for a loong time.
<ahasenack> if we want to revert to how 9.16.0 is, we have to now pass --disable-pthread-rwlock to ./configure
<ahasenack> focal has 9.16.0
<ahasenack> my intention is to update to 9.16.1
<doko> why do you tell me that?
<ahasenack> doko: because you know glibc
<ahasenack> and I wanted your opinion on this feature
<doko> ahh, looking at Fedora ...
<ahasenack> doko: we also have a bug in bionic's glibc when using pthread-rwlock, https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864
<ubottu> Launchpad bug 1864864 in glibc (Ubuntu Bionic) "[SRU] pthread_rwlock_trywrlock results in hang" [Undecided,Triaged]
<doko> ahasenack: https://src.fedoraproject.org/rpms/bind/blob/master/f/bind.spec  I don't see it disabled there
<ahasenack> doko: checking. Is that for 9.16.1?
<ahasenack> that was released today
<ahasenack> doko: that's 9.11?
<doko> yes
<ahasenack> irrelevant for 9.11
<rafaeldtinoco> ivoks: ping. I see you are an admin for ubunt-ha community but it appears to be inactive since ~2010 or so. I'm doing the maintenance of all HA related packages and going through bugs and all, would u mind closing that group and/or pointing to "ubuntu-server-ha" group ? <- we're using that group to track ubuntu-ha related stuff
<coreycb> vorlon: hi, if you're avail, I would like to get release team permission to bump python-decorator from 4.3.0 to 4.4.2 in focal
<tjaalton> LocutusOfBorg: hi, do you have an idea why building mesa with llvm-10 fails with "undefined reference to `getPollyPluginInfo()"? Wondering if it's a packaging bug, before I go complain upstream..
<LocutusOfBorg> tjaalton, let me sync llvm-toolchain-10-rc5 with the fix hopefully
<LocutusOfBorg> otherwise I'll fix it
<LocutusOfBorg> can you please check debian/sid in the meanwhile?
<LocutusOfBorg> I'm speaking about https://reviews.llvm.org/D74464
<tjaalton> is rc5 in sid?
<LocutusOfBorg> tjaalton, not yet built
<LocutusOfBorg> but I checked, no patch there, so I'm uploading it to focal
<tjaalton> ok, cool
<LocutusOfBorg> tjaalton, here you go https://launchpad.net/ubuntu/+source/llvm-toolchain-10/1:10.0.0~+rc5-1ubuntu1
<LocutusOfBorg> please report back when you can, so I upload in debian too
<tjaalton> LocutusOfBorg: it probably takes some hours to build?-)
<LocutusOfBorg> yep
<LocutusOfBorg> ~5h
<tjaalton> I didn't realize they use github now for issues
<LocutusOfBorg> fortunately yes!
<ahasenack> if a debian package has no d/gbp.conf, nor d/README.source, how can I tell what rules were applied to prepare its dfsg orig tarball?
<ahasenack> d/watch has just the +dfsg mangling
<ginggs> ahasenack: maybe Files-Excluded in d/copyright?
<ahasenack> ginggs: oh, there is a hint
<ahasenack> Files-Excluded: docs/doxygen
<ahasenack> thanks, I'll try that
<ahasenack> kanashiro: gem2deb is a valid candidate!
<ahasenack> kanashiro: and has in fact migrated already: https://launchpad.net/ubuntu/+source/gem2deb
<kanashiro> ahasenack, \o/
#ubuntu-devel 2020-03-20
<Eighth_Doctor> would someone be able to process this? https://bugs.launchpad.net/ubuntu/+source/pagure/+bug/1867775
<ubottu> Launchpad bug 1867775 in pagure (Ubuntu) "Sync pagure 5.8.1+dfsg-3 (universe) from Debian sid (main)" [Undecided,New]
<Eighth_Doctor> it's a sync request for a package in focal from debian sid that only contains packaging fixes
<Eighth_Doctor> there's basically zero risk to the ubuntu archive
<RAOF> Conan Kudo: Hm. What is that actually fixing? You say âbasically no riskâ, but the second changelog entry suggests that the first one broke the package ð
<ivoks> rafaeldtinoco why not just take over ubuntu-ha? it has more members, ppas, history...?
<alkisg> Hi, what's the last date when we can sync bug-fixing-releases from debian without FFEs? FinalFreeze on April 16th? (there's a security issue I'm trying to find the best way to resolve)
<LocutusOfBorg> hello tjaalton, did you have chance to test it?
<Laney> ddstreet: Just noticed that all(?) systemd-upstream CIs are borked ...
<Laney> they seem to randomly terminate with no useful output
<tjaalton> LocutusOfBorg: yes, didn't help :/
<tjaalton> LocutusOfBorg: filed it upstream as https://github.com/llvm/llvm-project/issues/191
<tjaalton> fedora doesn't seem to enable polly, which is why they haven't hit this
<LocutusOfBorg> tjaalton, do you have a log?
<tjaalton> LocutusOfBorg: looks the same
<LocutusOfBorg> mmm strange, the bug and patches looked good to me
<tjaalton> something broke the url handler in terminator..
<ginggs> hasta la vista url handler
<sil2100> Aw crap, the langpack gpg key expired
<sil2100> seb128: hey! Do you remember the procedure of getting new gpg keys for Ubuntu Langpack Uploader ?
<sil2100> The current key expired 2020-02-10
<Eighth_Doctor> RAOF: well, I mean, the package is kind of broken right now, when I meant no risk, nothing important in ubuntu would break :P
<Eighth_Doctor> as of right now, the missing dependency and the broken maint scripts means this thing doesn't work at all
<sil2100> Oh, and I need to wait for the translation stats to publish, the first focal ones should appear soonish
<sil2100> So I'll kick the updates then
<ddstreet> Laney it seems like some are currently running ok, did you fix it?
<Laney> nope
<Laney> they will probably fail out
<Laney> or you mean you can see successful results?
<ddstreet> no i was jjust looking at currently running ones - i'm pulling the last 40 finished runs now to look at
<seb128> sil2100, no idea, I don't think the key ever expired since pitti left
<xnox> doko:  have you been working on removal of unversioned python build-deps? or not at the moment? I think I see a few more, but not too sure if they are in progress or not.
<doko> xnox: I had the hope I catched them all. what are you seeing?
<xnox> doko:  things like https://bugs.launchpad.net/ubuntu/+source/cinfony/+bug/1868259
<ubottu> Launchpad bug 1868259 in cinfony (Ubuntu) "RM: build-dep python; cannot be built anymore; removed from testing" [Undecided,Confirmed]
<xnox> doko:  https://paste.ubuntu.com/p/WbcnxrPn8v/
<xnox> doko:  lots of Build-Depends-Indep: python (>= 2.*)
<ddstreet> Laney yeah it seems like the testbed is hanging while installing the newly built systemd pkgs to test :-/
<xnox> and Build-Depends: python (>= 2.*) too
<ddstreet> i'll run some tests manually to see if it hangs for me also
<doko> hmm, wondering why I didn't catch those
<Laney> ddstreet: :(
<Laney> cool
<Laney> hopefully it does and then you get get into the instance to debug
<xnox> doko:  https://paste.ubuntu.com/p/JnbqWMD9xh/ is the pkg list imho
<xnox> doko:  but some might be like fixed in -proposed =( i don't have a good way to catch that
<doko> crap, some more work :-(
<xnox> doko:  do you want to do them? or me?
<xnox> doko:  i don't have powers to like RM packages like cinfony above
<xnox> (cannot be built anymore, removed from testing)
<doko> I'll walk through that list
<xnox> thank you, hopefully most of it, is just RM removed from debian
<xnox> some we still need for sure, like libaccounts-glib
<xnox> but not sure
<doko> xnox: edgy-community-wallpapers, naked people?
<xnox> doko:  let's see
<xnox> doko:  naked people were calendar wallpapers, no?!
<xnox> doko:  that one is just a plant
<xnox> doko:  which for a static file has setup.py and setup.cfg
<xnox> ah to translate <_name>Dawn Of Ubuntu</_name>
<xnox> doko:  i'll make that one python3
<xnox> doko:  continue with something else
<cjwatson> the dubious wallpapers were edgy in nature but not in timing :)
<doko> heh
<xnox> uploaded port to python3
<Eickmeyer> Hi all! I've got some very pressing issues in ubiquity that need to be taken care of. At first I had bug 1851346 back in December, but now bug 1868191 has popped up and they're both related to the manual package selection for Ubuntu Studio.
<ubottu> bug 1851346 in ubiquity (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<ubottu> bug 1868191 in ubiquity (Ubuntu) "Unchecking all optional media apps, install fails" [Undecided,New] https://launchpad.net/bugs/1868191
<Eickmeyer> I see two solutions for this: 1) we fix the problem (preferable) or 2) we disable the package selection altogether.
<Eickmeyer> Either way, I don't want these bugs landing in an LTS, and I don't have the know-how to fix them
<Eickmeyer> bdmurray: ^
<bdmurray> Eickmeyer: bug 1851346 is on our list of things to fix
<ubottu> bug 1851346 in ubiquity (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<Eickmeyer> bdmurray: I hope so. Looks like 1868191 might be a duplicate? I'm not sure, but it seems to be the same problem.
<bdmurray> Eickmeyer: I'll add it to our list to look at as a team
<Eickmeyer> bdmurray: I'd appreciate it. :)
<bdmurray> vorlon: Is there any duplicate searching to be done for bug 1867431 or did you do that already?
<ubottu> bug 1867431 in glibc (Ubuntu) "ERROR got an error from dpkg for pkg: 'libc6'" [Critical,Fix released] https://launchpad.net/bugs/1867431
<vorlon> bdmurray: I had not looked for duplicates of LP: #1867431
<ubottu> Launchpad bug 1867431 in glibc (Ubuntu) "ERROR got an error from dpkg for pkg: 'libc6'" [Critical,Fix released] https://launchpad.net/bugs/1867431
<vorlon> coreycb: I was on PTO yesterday; did you get what you needed wrt python-decorator? (did you talk to #ubuntu-release?)
<rbasak> bryce: I filed a fairly minor MP with definitely-needed commits that are finished from my branch, to reduce the size of the upcoming one. No rush to review, though it should be trivial.
#ubuntu-devel 2020-03-21
<mbnunes> hi
<mbnunes> i need a custom Ubuntu Server's Installer, is possible?
<mbnunes> I can't find ubuntu's source =/
<mbnunes> hi
<mbnunes> sorry i'm lost connect
<mbnunes> is possible custom installer ( setup ) ubuntu server?
<genii> Much of the method found here is still applicable https://help.ubuntu.com/community/InstallCDCustomization
<mbnunes> i'm see thanks for help
<genii> This not so much a question for this channel, however, which is for developers working on Ubuntu to communicate with each other, the more approriate channel would be either the server specif one #ubuntu-server  or the main support channel of #ubuntu
<mbnunes> thanks
<genii> Glad to be of assistance
<TJ-> Any fixes in the pipeline for "ssh: symbol lookup error: /snap/core18/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_vfork, version GLIBC_PRIVATE']" (conjure-up kubernetes). There's a related microstack bug #1860660
<ubottu> bug 1860660 in MicroStack "Strict confinement (was: microstack.init is broken on eoan)" [Critical,Fix released] https://launchpad.net/bugs/1860660
<Unit193> So I updated from bionic and wondered why there was such a regression in dput's bash-completion, I was going to copy over bionic's version (or diff them rather) when I noticed that the new one wasn't even being installed.  http://paste.openstack.org/show/pERsfUDKOL336O3poBbm would fix it.
<Unit193> (It would also work to drop the override entirely, fwiw.)
#ubuntu-devel 2020-03-22
<tarzeau> i know the archive sync is over, but i'd highly recommend to sync meshlab from debian sid
<tarzeau> to fix the current proposed pkg to work, it's just another line in the debian/*install file, i can also provide that if big changes are not accepted anymore
<RikMills> tarzeau: I was already planning to. just completed a test build in a ppa to make sure nothing in our toolchain differences caused something unexpected
<RikMills> syncing now
<RikMills> thank you :)
<tarzeau> RikMills: sound great :) thank you
<tarzeau> unfortunately due to holidays abroad+corona stay home i wasn't able to check/fix icon+desktop file associtaion (two bugs on launchpad)
