[00:09] <ScottK> cjwatson: I've done it (accidentallly uploaded to Ubuntu).  It was a package I meant for a PPA.
[00:09] <ScottK> And yes, I did change mine after that to require me to specify ubuntu as an upload target.
[00:17] <cjwatson> ScottK: fair enough. Of course it's a bug that PPAs use the same upload target scheme as Ubuntu.
[00:24] <cody-somerville> cjwatson, no it isn't
[00:25] <cody-somerville> cjwatson, may be undesirable but I wouldn't call it a bug
[00:25] <cody-somerville> cjwatson, It is possible for other distributions to have PPAs
[00:28] <persia> cody-somerville, Traditionally, responsible third-party repositories selected different series names for releases, to better identify the appropriate place for any given upload, as reflected in the changelog.
[00:28] <persia> To me, it would make more sense, assuming the bug was fixed, to do something where dput would upload to the location identified by the target in debian/changelog except when overridden.
[00:29] <cody-somerville> I disagree
[00:29] <persia> Unfortunately, with the current state of PPAs, this means an override is required for each PPA upload, which doesn't solve your use case.
[00:29] <persia> Why?
[00:30] <cody-somerville> persia, I think you'd find it logical for different repositories that are providing additional packages to have the same corresponding name for the targetted distroseries.
[00:31] <persia> Not at all, because I would expect the builds to differ because there are different packages therein.
[00:32] <cody-somerville> persia, so you expect end users to go hunting down all the third party repositories to find out what the new codename is for the new distroseries every six months?
[00:33] <persia> Doesn't affect end-users at all, and yes, I expect developers working on multiple projects to keep track of changes to upload targets in those projects to which they contribute.
[00:33] <cody-somerville> Hobbsee, I've already filed a bug and sent Debian an e-mail
[00:33] <cody-somerville> persia, how does it not affect end-users?
[00:33] <Hobbsee> cody-somerville: cool.  just checking :)
[00:33] <persia> cody-somerville, Because end-users only need the URL of the repos they want: they don't care how it got there.
[00:34] <cody-somerville> persia, not true. You also need to know the distroseries name
[00:34] <persia> Further, differentiation by targets in the changelog is beneficial to end-users, because they can see points of differentiation in derivative repos.
[00:35] <cody-somerville> I agree with that point
[00:36] <persia> cody-somerville, Right.  You need a string, which includes a URL and a name.  And yes, I do expect users of multiple repositories to track them: otherwise we get back into the troubles we saw when there was a wealth of advertised third-party repos about 5 years ago.
[00:37] <cjwatson> cody-somerville: I'm not sure how my statement conflicts with the possibility of other distributions having PPAs
[00:37] <cody-somerville> persia, so, what would you suggest for distroseries names for PPAs?
[00:37] <cody-somerville> cody-somerville-hardy, cody-somerville-intrepid?
[00:37] <ScottK-desktop> Even if it was jaunty-ppa it'd be fine.
[00:37] <cjwatson> cody-somerville: it's a bug because you can take a signed upload that somebody had intended for a PPA, and subvert their intent by uploading to Ubuntu
[00:38] <cody-somerville> ScottK-desktop, but then all the PPAs are the same
[00:38] <persia> I'd prefer something like jaunty-ppa
[00:38] <cjwatson> cody-somerville: without having to re-sign
[00:38] <ScottK-desktop> cody-somerville: Fine with me.  They aren't the same distro as Ubuntu.
[00:38] <persia> cody-somerville, I don't care about differentiation between PPAs.  I know that's being small-minded, but it's true.
[00:38] <cjwatson> cody-somerville: the thing that goes at the top of debian/changelog has absolutely zip to do with what end users have to know about.
[00:38] <ScottK-desktop> +1
[00:39] <persia> cjwatson, There's a workaround blocker for that, but it was true for a year or so.
[00:39] <cody-somerville> If we don't care about that then I'd strongly be in favour of changing it as well to have another pocket for PPA uploads
[00:39] <cjwatson> persia: right, but people might well still publish the signed object somewhere without realising the problem
[00:39] <cjwatson> e.g. for review
[00:39] <persia> Ah.  That would indeed be dangerous.
[00:40] <cody-somerville> right... how *do* we prevent a third-party someone taking a package in a PPA of a developer and reuploading it to Ubuntu?
[00:41] <cjwatson> by making the thing at the top of debian/changelog different, as I said a page back
[00:41] <cjwatson> i.e. the upload target
[00:42] <cody-somerville> right, but its currently the same for PPA and Ubuntu, no?
[00:44] <persia> cody-somerville, Which is the bug.
[00:44] <cjwatson> as I've been saying
[00:44] <cody-somerville> Scary.
[00:51] <cody-somerville> Hobbsee, so I'll change it back to Ubuntu
[00:51]  * ScottK-desktop comes back to the conversation and turns around in a circle.
[00:52] <cody-somerville> ScottK-desktop, or would ScottK-desktop like to sponsor? :)
[00:53]  * ScottK-desktop is desparately trying to get some $WORK done before leaving town for Christmas vacation
[00:53] <ScottK-desktop> so no.
[00:53] <Hobbsee> cody-somerville: oh good :)
[00:54] <cody-somerville> Hobbsee, I don't think upstream is going to take the sftp transport patch because it introduces a dependency on bzr :P
[00:54] <cody-somerville> (or recommends, sorry)
[00:55] <Hobbsee> cody-somerville: that's a point.  Although they might for the sake of compatibility, but bump bzr to suggests ;)
[00:55] <persia> Why does sftp require bzr?
[00:58] <cody-somerville> persia, because I use the bzrlib.transport module
[00:59] <cody-somerville> Hobbsee, It is a suggests, sorry
[00:59] <Hobbsee> oh.
[00:59] <Hobbsee> on that basis, they probably would.
[01:00] <Hobbsee> bzr's in debian
[01:00] <cody-somerville> Hobbsee, maybe they just haven't gotten around to it. I know they took one of my other fixes in my last upload.
[01:00] <Hobbsee> i saw that
[01:13] <avb> bzrlib.transport
[01:13] <avb> why not usual openssl?
[01:18] <cody-somerville> avb, if you'd like to rewrite it to use openssl directly, be my guest.
[01:21]  * cody-somerville will be back later.
[03:46] <mrooney> bryce: around?
[03:52] <mrooney> bryce: I've added a workaround section to the description of bug 284408, if you could enhance or fix it in any way I would appreciate it, I'm not sure if everyone should be installing -ati or what.
[04:00] <bryce> mrooney: thanks, yes that looks good (on quick glance)
[04:01] <bryce> mrooney: and yes, people with problems using -fglrx should switch to -ati.  -ati is a pretty decent driver nowadays
[04:01] <mrooney> bryce: okay, thanks, and those purges are all good?
[04:01] <bryce> mrooney: -radeonhd is another open source option people have, although we don't give it as much attention in ubuntu as -ati
[04:02] <bryce> mrooney: well, -radeon is just an alias for -ati so I'm not sure if that's required, but it doesn't hurt
[04:02] <bryce> mrooney: also I'm not certain if they'd need to purge/reinstall mesa
[04:03] <bryce> fglrx has some glx bits that overwrite the corresponding files that -ati uses.  Not sure whether that would get automatically cleaned up or not
[04:03] <mrooney> yeah I think that's why -ati is purged and then installed, although a reinstall might suffice
[04:14] <gnomefreak> bryce: are you working on X in Jaunty?
[04:14] <mrooney> bryce: okay, well thanks for your help! I figured once people started posting comments to remove your video card someone had better post a formal workaround and stop all the confusion
[04:15] <bryce> gnomefreak: hmm?
[04:15] <bryce> mrooney: heh, very true!
[04:16] <bryce> mrooney: it's much appreciated; I'm probably going to be scaling back the amount of attention I give to -fglrx bugs going forward, with the hope that community folks like yourself can assist other users with questions and so on
[04:16] <mrooney> bryce: yeah, -ati seems to be really shaping up! I am glad for this bug actually or I never would have found out :)
[04:17] <mrooney> bryce: good night for now, it was nice meeting you at UDS
[04:18] <bryce> mrooney: :-)
[05:16] <mcasadevall> freeflying, ping
[05:20] <NCommander> Can a buildd admin please rescore kde4bindings on armel?
[05:31] <freeflying> NCommander: I'm not in charge of buildd :)
[05:42] <bluesmoke> bryce: just fyi, bug 310228 should be closed as invalid as removing that patch drastically reduces performance when using a compositor
[05:42] <bluesmoke> oh, it got duped
[05:43] <bluesmoke> anyway, same message
 so what gnome quite sensibly does is tells the compositor not to show the window contents until they're painted, using the same sync protocol that window resizing uses.
[05:44] <bluesmoke> that's the 'fix' for GNOME to make it not show garbage, KDE needs to do something similar
[05:45] <bluesmoke> oh, I guess he is in US too and won't see that for some time...
[07:33] <NCommander> Can a core developer kick the retry button on opie in main for armel?
[07:48] <fargiolas> how long does it take for a package that has been pushed into repositories to actually be available for install? I'm asking because lool said he pushed libv4l 0.5.7 (bug 308890) but I cannot see it yet in -proposed
[08:09] <NCommander> fabbione, in the case of the proposed repos, an SRU member must ACK it and an archive admin must accept it
[08:09] <NCommander> It doesn't enter the proposed archive automatically
[08:12] <fargiolas> NCommander: oh I though "pushed" there meant that it has been pushed in -proposed
[08:12] <NCommander> Nope
[08:12] <NCommander> I assume you got an email from Ubuntu Installer when your patch was sponsored?
[08:12] <fargiolas> so is there any SRU member here to ACK it?
[08:12] <fargiolas> NCommander: I'm not the author of the patch
[08:12] <NCommander> oh
[08:13] <fargiolas> NCommander: I'm a cheese developer and I already have at least 3 bugs in bugzilla caused by that
[08:13] <NCommander> Oh, I see
[08:13] <NCommander> Loic already did the right thing
[08:13] <NCommander> Its just a matter of waiting
[08:14] <fargiolas> NCommander: ok, I just wanted to sure what to say to reporters (either enable proposed or wait until it gets in proposed)
[08:14] <NCommander> Once it enters proposed, the buildds will get it, and it usually will be available within a few hours of acceptence
[08:14] <fargiolas> *to be
[08:48] <dholbach> good morning
[08:49] <NCommander> morning dholbach
[08:49] <dholbach> hi NCommander
[08:49] <dholbach> NCommander: just looking at the python-qt thing
[08:50] <NCommander> which one :-)
[08:50] <dholbach> the fixed replaces
[08:50] <NCommander> ah, that one
[08:54] <NCommander> dholbach, since we're on the topic, can you please retry opie on armel for me?
[08:54] <NCommander> (of sponsoring stuff ;-))
[08:54] <dholbach> NCommander: err?
[08:55] <NCommander> dholbach, can you retry a build for me on armel?
[08:56] <dholbach> NCommander: done
[08:56] <NCommander> thanks
[10:21] <dholbach> is there something we can do about  http://www.chipx86.com/blog/?p=276 ?
[11:12] <tseliot> Riddell: I should write a patch for the randr kcm module instead of writing a new module (since I only need to add an option to restore X restart with "ctrl-alt-backspace"), right?
[11:13] <cjwatson> dholbach: I've a feeling that the fix needs to be on the vmware side - it looks like basically the same kind of thing we had to fix in kvm to cope with the switch to evdev
[11:14] <RainCT> stgraber: congrats :)
[11:20] <dholbach> cjwatson: OK, thanks
[11:33] <Riddell> tseliot: yes, if there's space for such a tickbox
[11:33] <tseliot> Riddell: ok, thanks
[11:35]  * directhex wonders who's bored and in an archive adminning mood
[11:37] <Riddell> directhex: I'm on duty today
[11:38] <directhex> Riddell, lucky you!
[11:38] <directhex> Riddell, feel like waving your magic wand at bug 308497, bug 308500, bug 308498 ?
[11:43] <Riddell> directhex: done
[11:43] <directhex> neato. cheers
[11:50] <apw> does anyone know if you can do binary uploads to PPA's
[11:51] <Laney> you can't
[11:51] <directhex> you can't do binary uploads full stop. PPAs are no different
[11:52] <directhex> and any archive admin who corrects me on that point gets a stab ;)
[11:59] <directhex> gah. yes, i've seen it. i'll stab meebey when he wakes up
[12:00] <Laney> hm?
[12:00] <directhex>  * Source Package: monodevelop
[12:00] <directhex>  * State: Failed to build
[12:01] <directhex> the same mono-cairo.pc problem that plagued slangasek's gtk# upload
[12:01] <directhex> which begs the question "how was it uploaded to experimental
[12:01] <Laney> did it build for exp?
[12:01] <Laney> ^
[12:01] <directhex> i suspect a dirty chroot
[12:01] <Laney> silly binary uploads
[12:01] <directhex> hence stab time!
[12:03] <directhex> i can 4ubuntu1 a workaround, but i'd rather the fix go to exp & then sync
[12:03] <directhex> i think it's time to move mono-cairo.pc to libmono2.0 instead of libmono1.0, don't you?
[12:03] <Laney> directhex: Always test your syncs ;)
[12:04] <directhex> sigh, i know, i know. i thought i had. i filed the last week
[13:04] <Riddell> dholbach: do you have a magic way to mass close bugs?  e.g. bug 310888
[13:11] <NCommander> dholbach, email
[13:11] <NCommander> er, Riddell
[13:11] <NCommander> Does anyone know what could selectively cause one button to stop registering clicks to it?
[13:19] <Riddell> NCommander: nothing in my e-mail
[13:19] <NCommander> Riddell, no, use email to close all the tasks
[13:21] <Riddell> hmm, that means learning a whole new user interface
[13:22] <NCommander> pretty much
[13:22] <NCommander> There is also that LP gui that can do it
[14:04] <apw> before launchpad, did ubuntu bugs reside 'elsewhere'?  i have a reference to an ubuntu bug #nnnn which is clearly not the launchpad bug and am trying to locate it
[14:05] <cjwatson> yes, they were in a Bugzilla instance
[14:05] <cjwatson> apw: https://bugs.launchpad.net/bugs/bugtrackers/ubuntu-bugzilla/<bugnumber> will redirect you to the Launchpad import of that bug
[14:05] <apw> ooo arr cantana
[14:05] <apw> (thanks)
[15:00] <Riddell> asac: alive?  do you know why there's a new chatzilla package in New?
[15:04] <cody-somerville> Can an archive admin look at bug #310821 ?
[15:05] <cody-somerville> Before I ack with my motu-sru hat on, I'd like an archive admin to ack
[16:10] <Riddell> cody-somerville: you want an archive admin to ack so you can ack so an archive admin can do it?
[16:11] <cody-somerville> Riddell, I want to ensure that the process can be smooth and go without a hitch
[16:13] <Riddell> cody-somerville: I don't see there would be any problem
[17:02] <dholbach> NCommander: no, sorry
[17:02] <NCommander> dholbach, no to what?
[17:04] <dholbach> NCommander: ... err Riddell: ^^ :)
[17:04] <dholbach> no magic auto-closing way
[17:04] <dholbach> excusez moi
[17:26] <asac> Riddell: yes. its a ffox extension ... the other thing in the archive is seamonkey
[17:29] <asac> Riddell: (i assume you had archive day ... did you reject bugmail extension?)
[17:31] <Riddell> asac: I did reject bugmail yes
[17:32] <asac> Riddell: ok did you send an explanation somewhere ;)?
[17:32] <Riddell> asac: https://lists.ubuntu.com/archives/ubuntu-archive/2008-December/023488.html
[17:35] <asac> Riddell: ok i uploaded it because all but the trivial files have an explicit GPLv3 header in it
[17:35] <asac> anyway upstream already said they would add it
[17:35] <Riddell> it really needs the full licence text
[17:36] <Riddell> for my approval anyway, other archive admins may vary
[17:36] <asac> kk
[18:09] <msaraujo> hi, I am getting this error when trying to compile ruby (trunk version)
[18:09] <msaraujo> vsnprintf.c:1185: sorry, unimplemented: inlining failed in call to ‘snprintf’: redefined extern inline functions are not considered for inlining
[18:10] <msaraujo> is there anyone here that can help?
[18:13] <Adri2000> ok
[18:13] <Adri2000> oops
[18:24] <Q-FUNK> howdy!   is there anything missing to get xserver-xorg-video-geode 2.9.0-1ubuntu2.5 from hardy-proposed into hardy-updates?
[18:24] <slangasek> the bug status doesn't reflect that it's gotten any testing at all in -proposed
[18:25] <slangasek> so, yes, "testing" is missing. :)
[18:25] <Q-FUNK> :)
[18:26] <Q-FUNK> slangasek: ok. so where would anyone confirm that testing was conclusive and support a move to -updates?
[18:26] <Q-FUNK> ööö... express support for a move to -updates?
[18:27] <cjwatson> in the bug
[18:27] <cjwatson> linked from http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[18:27] <slangasek> https://wiki.ubuntu.com/StableReleaseUpdates#Verification
[18:31] <cjwatson> oops, I copied cairo to intrepid-updates a bit early, sorry
[18:31] <cjwatson> pitti: ^-
[18:31]  * directhex stabs cairo
[18:32] <cjwatson> only by one day though
[18:34] <Q-FUNK> that would be bug #255991
[18:48] <lool> doko: Just noticed this today, but python-central moves .py to /usr/share/pyshared but these might be arch specific (/usr/share/pyshared/PyQt4/pyqtconfig.py for instance); that'd bad, why /usr/share/pyshared and not /usr/lib/pyshared?
[19:50] <Riddell> cjwatson: doing New queue?
[19:53] <cjwatson> finished
[19:53] <cjwatson> I did a bit
[19:54] <cjwatson> lool: I acked bug 309674, in case you're still around to upload that
[20:08] <directhex> aha, it was cjwatson who pulled in banshee-extension-mirage from NEW
[20:09] <directhex> it's a neat plugin - it takes ages to scan your library, but you can pick a track & it'll generate playlists based in the "feel" of your chosen track. i think itunes has a similar feature
[20:11] <wasabi> so i guess msn telepathy is broken in intrepid in some fashion?
[20:11] <wasabi> (or is it just me?)
[20:12] <Treenaks> wasabi: empathy works great for me.. waht's broken?
[20:12] <wasabi> Won't connect. Network error.
[20:12] <wasabi> It stopped like... a week or two ago.
[20:12] <wasabi> I was thinking it was a protocol/server change that nobody kept up with.
[20:13] <Treenaks> wasabi: which protocol? because gtalk, msn, aol/icq work for me
[20:13] <wasabi> msn.
[20:13] <wasabi> actually. i'm not sure what it is now... when i enable the account it says network error, but actually I see no packets.
[20:13] <wasabi> maybe it is just me
[20:14] <Treenaks> wasabi: maybe you deinstalled the package?
[20:14] <wasabi> nope
[20:19] <Treenaks> wasabi: firewall rules?
[20:21] <wasabi> no firewall.
[21:15] <cr3> what's the wiki page describing how to request an update of a package which has been renamed in main?
[21:31] <cr3> bug #257746 has not seen much action in a while and might need review before DIF, should I do anything so that it doesn't fall through the cracks?
[22:23] <cody-somerville> jdstrand, ping
[22:24] <jdstrand> cody-somerville: pong?
[22:24] <cody-somerville> jdstrand, I got another dput upload for you to sponsor :)
[22:24] <jdstrand> cody-somerville: sure, np
[22:24] <cody-somerville> jdstrand, https://bugs.edge.launchpad.net/ubuntu/+source/dput/+bug/310754
[22:26] <jdstrand> cody-somerville: is the changelog correct in that debdiff?
[22:26] <cody-somerville> jdstrand, yup
[22:27] <cody-somerville> jdstrand, re comment #6?
[22:27] <jdstrand> cody-somerville: yes
[22:27] <cody-somerville> yup
[22:47] <jdstrand> cody-somerville: done
[22:48] <cody-somerville> jdstrand, thanks
[22:49] <jdstrand> cody-somerville: and fwiw, I think you made the right choice to keep default_main_host as is
[22:49] <jdstrand> people will likely have opinions on that one
[22:50]  * cody-somerville nods.
[23:38] <slangasek> does anyone here have experience with editmoin?
[23:39] <slangasek> I don't seem to be able to get it working against wiki.u.c, it consistently gives me a permission error even after configuring it
[23:40] <nhandler> slangasek: I got it working
[23:40] <slangasek> is there a secret I'm missing? :)
[23:41] <nhandler> Did you get your MOIN_SESSION or w/e it is called?
[23:41]  * nhandler is pulling up the namme
[23:41] <slangasek> I grabbed the value of the "MOIN_ID" cookie under the wiki.ubuntu.com domain out of firefox, and pasted the unquoted content of the cookie into .moin_ds
[23:41] <slangasek> .moin_ids, rather
[23:42] <slangasek> do I need to leave the quotes in, or am I supposed to be using MOIN_SESSION instead or something?
[23:42] <nhandler> So what does your .moin_ids file look like?
[23:42] <slangasek> https://wiki.ubuntu.com<tab>$cookie
[23:42] <slangasek> that's what I understood from the manpage, though the manpage seems to have mangled formatting
[23:43] <nhandler> And how are you going about editing the wiki page (or trying to)
[23:43] <slangasek> a variety of ways
[23:43] <slangasek> fwiw, I just found the answer: the file is called .moin_ids, but the cookie you need is MOIN_SESSION
[23:43] <slangasek> thanks :)
[23:44] <nhandler> slangasek: Sorry about that. I'm not on my ubuntu machine right now.
[23:44] <nhandler> Glad you got it working
[23:45] <slangasek> guess the manpage needs updating, then