[07:43] <Rhonda> Hmm. Shall I upload my built packages for Bug #656850 somewhere? I mean, it's not like it's rocket science, there are no source changes involved at all?
[07:43] <Rhonda> Potential to a PPA? Never used PPA before, and I guess I'll have to version it differently there, too?
[07:48] <wgrant> Rhonda: I'd tend to reversion it to 1:1.8.5-1~ppa1 and upload to a PPA.
[07:48] <wgrant> Hm, but if it's for backports, ~karmic1~ppa1 and ~lucid1~ppa1 may be better.
[07:48] <wgrant> So the official backports will clobber them.
[07:49] <Rhonda> not rather... yes, that's my thought. ;)
[08:17] <dholbach> good morning! :)
[08:55] <Laney> morning
[09:03] <\sh> hey Laney
[11:09] <Rhonda> natty is already in the archive. :)
[11:10] <hyperair> whut, seriously?
[11:10] <Rhonda> hyperair: http://archive.ubuntu.com/ubuntu/dists/natty/
[11:10]  * geser has already upgraded his pbuilder to natty :)
[11:11] <persia> Just so folks don't get too excited, natty isn't really ready yet.
[11:11] <hyperair> woow
[11:11] <hyperair> aw man?
[11:11]  * hyperair checks his own mirror
[11:11] <Rhonda> persia: of course not, not before 6 month  :P
[11:11] <hyperair> lol Rhonda.
[11:12] <persia> https://launchpad.net/ubuntu/natty still says "Pre-release freeze"
[11:13] <geser> and the first FTBFS in natty exist too :)
[11:15] <Rhonda> Hmm, never have done an SRU …
[11:16] <Rhonda> Anyone got a hint how to turn bug #656238 into a SRU?
[11:17] <geser> Rhonda: extract the change for the mkdir call and apply it to the version in maverick (the translation changes probably won't qualify for SRU)
[11:18] <persia> !sru
[11:18] <Rhonda> geser: Feared something like that. ;)
[11:19] <Rhonda> persia: Am on that page right now, yes. :)
[11:19] <persia> Just wanted to make sure :)
[11:20] <Rhonda> I'll have to wait for gitolite to get synced into natty first it seems anyway.
[11:21] <Rhonda> btw., my latest blog post will apply to natty, too
[11:22]  * Rhonda . o O ( the one about sudo )
[11:22] <geser> Rhonda: usually this requirement is waived that short after release to not block until natty it fully opened
[11:24] <persia> The requirement is *always* so waived: a full copy of maverick-updates -> natty will be some of the first uploads
[11:24] <persia> (although I forget if it's actually on the release open checklist)
[11:50] <soren> Rhonda: That has been the default sudo behaviour for Ubuntu for years.
[11:51] <soren> Rhonda: so yes, it does apply, but it shouldn't be a surprise to existing Ubuntu users.
[11:55] <Rhonda> soren: Hmm, I only find it mentioned in the changelog, not within the rest of the diff?
[11:57] <soren> Rhonda: Eh?
[11:58] <Rhonda> soren: http://patches.ubuntu.com/s/sudo/sudo_1.7.2p7-1ubuntu2.patch
[11:58] <Rhonda> That mentions tty_ticket only in the changelog.
[11:58] <Rhonda> I would have expected it to be part of a different file, too
[12:00] <soren> Rhonda: I don't follow the logic here, sorry. It only mentions it in the changelog => the code changes must already be applied, right?
[12:00] <soren> Besides:
[12:00] <soren>   * Merge from debian unstable, remaining changes:
[12:00] <soren>    - debian/rules: Disable lecture, enable tty_tickets by default. (Ubuntu
[12:00] <soren>      specific)
[12:00] <soren> From 1.7.0-1ubuntu1 (sudo in karmic).
[12:01] <soren> I'm /fairly/ certain it's been this way forever.
[12:01] <Rhonda> soren: Yes, in the changelog. But nowhere else in the diff?
[12:01] <soren> *precisely*
[12:01] <Rhonda> The changelog is just a textfile. It has to be in some other place within the diff, too.
[12:02] <soren> If you only see it mentioned in the text file, it's because it didn't change in the code. If it didn't change in the code, that's because it was that way before.
[12:02] <persia> There's another option.
[12:02] <Rhonda> But it can't.
[12:02] <Rhonda> The switch was done in 1.7.4 by upstream.
[12:02] <persia> It may have changed in Debian since it was changed in Ubuntu, and the last merger may have failed to understand the code well enough to drop it from the changelog.
[12:03] <Rhonda> persia: No, it's explicitly marked in the 1.7.4 upstream changes.
[12:04] <soren> Ok, now I'm actually looking at the patch,you're linking to..
[12:04] <soren> It says, loud and clear:
[12:04] <soren> +--without-lecture --with-tty-tickets \
[12:04] <soren> Twice.
[12:05] <soren> So it most certainly does mention this outside the changelog diff.
[12:05] <Rhonda> Ah, only grepped for tty_tickets, my bad.
[12:05] <Rhonda> my bad then
[12:06] <soren> But really, if Debian applied the same change, it wouldn't show up in this diff, exactly /because/ we already had this change.
[12:07] <Rhonda> soren: a.) Debian didn't apply any diff, the default got switched upstream in 1.7.4.  b.) this diff is about 1.7.2, not 1.7.4 (which isn't in Ubuntu yet)
[14:49] <ScottK> Rhonda: For the backport, since it's a no change backport, you don't have to upload anything.  There is an archive script that does it.
[14:54] <Rhonda> ScottK: Right, but people might want to test it before they ACK, not?
[14:54] <Rhonda> Just wanted to offer my done builds somehow. :)
[14:56] <ScottK> Rhonda: From and Ubuntu backports perspective if a tester says it builds, installs, runs (which I read your report as saying), it's sufficient.
[14:56] <ScottK> I know that sounds like a very weak standard, but it seems to work.
[15:00] <Rhonda> Well, it's not like debian backports has any more testing, trust has to be there anyway for the uploaders.
[15:01] <Rhonda> And if it's a backport without source changes chances are good that this can be trusted indeed.
[15:05] <debfx> ScottK: is there anything more I need to do in bug #647361?
[15:06] <ScottK> looking
[15:06] <ScottK> debfx: Upload it.
[15:07] <ScottK> debfx: Upload target is lucid-backports.
[15:07] <ScottK> (as you have it)
[15:12] <debfx> ScottK: ok, but bug #600321 is just waiting for an archive admin to process it?
[15:12] <ScottK> debfx: Yes.
[15:34] <Rhonda> The error in Bug #659108 looks pretty strange and like a local issue on the system of the user?
[15:37] <Hobbsee> i'd say so - download issue
[16:28] <micahg> \sh: PM?
[16:28] <\sh> sure
[17:57] <maxb> Is there a reference implementation for DEB_BUILD_OPTIONS nocheck somewhere?
[17:57] <maxb> I'm sure I can make it work myself, just wondering if there's a canonical way to write it
[18:44] <smallfoot-> hey put PyOgre in repo
[18:48] <_stink_> hey folks.  i just did apt-get update in lucid 64bit and i'm seeing some unexpected stuff in the aptitude package listings.  245 new packages, all of them with blank descriptions... doing 'U' to mark all updates has aptitude wanting to remove g++ and tons of other stuff... and update many packages from one version number to an identical version number.
[18:48] <_stink_> any advice?  could the repo be messed up?
[18:53] <_stink_> wait, i'm using a mirror on this machine.
[18:53] <_stink_> i mean, not using the standard ubuntu repos.  don't know if that matters.
[18:55] <Bachstelze> probably
[18:55] <jdong> _stink_: having weird 3rd party repos can certainly do that
[18:55] <Bachstelze> any real reason to not use the standard repos ?
[18:55] <jdong> try to simulate it and pastebin the simulation output?
[18:55] <Bachstelze> hi jdong
[18:55] <jdong> hey Bachstelze
[18:55] <_stink_> Bachstelze: well, i am close to the Oakland Univ. (Michigan) mirror.
[18:56] <jdong> oh if it's an actual mirror of an Ubuntu repo, that should not be an issue
[18:56] <Bachstelze> oh, right
[18:56] <Bachstelze> I thought maybe some unofficial ISP or company mirror
[18:56] <jdong> your sources.list / sources.list.d, and an aptitude -s dist-upgrade
[18:56] <Bachstelze> that could be messed up
[18:56] <jdong> those would be helpful for troubleshooting
[18:57] <_stink_> jdong: well, it happened right after i added the virtualbox non-free repo.  after apt-get update, i get the weirdness.  but i've removed that file in sources.list.d, and re-updated, and i expected it to fix itself.  but it didn't.
[18:57] <jdong> *cringe* okay
[18:57] <jdong> now I think we're getting closer to the problem
[18:57] <_stink_> ruh roh.
[18:58] <jdong> can you run aptitude -s dist-upgrade and pastebin the results?
[18:58] <jdong> that'll at least tell us why aptitude so desperately wants to be removing g++ et al
[19:01] <_stink_> jdong: http://paste.ubuntu.com/511823/
[19:03] <jdong> hmm interesting
[19:04] <jdong> _stink_: what does safe-upgrade want to do?
[19:05] <_stink_> jdong: aptitude -s safe-upgrade show exactly the same thing as -s dist-upgrade.
[19:05] <jdong> _stink_: okay time for the big guns then. aptitude -o 'Aptitude::CmdLine::Resolver-Debug=true' dist-upgrade
[19:06] <ari-tczew> who deals with hall-of-fame?
[19:06] <jdong> the only slightly suspicious thing I see is the edgers PPA
[19:07] <_stink_> jdong: no extra output at all.  i'm at the "Do you want to continue?" prompt.
[19:07] <jdong> doubt it'd be acting up to the point of suggesting the removal of so many packages
[19:07] <_stink_> looks the same as the other outputs.
[19:07] <jdong> hmm, groan
[19:08] <_stink_> and that PPA is commented out. :/
[19:08] <jdong> I'm not much of an aptitude guy, what is {u}?
[19:09] <jdong> {a} is autoremove...
[19:09] <smallfoot-> hey put PyOgre in repo
[19:09] <smallfoot-> hey put PyOgre in repo
[19:09] <smallfoot-> hey put PyOgre in repo
[19:09] <smallfoot-> hey put PyOgre in repo
[19:09] <_stink_> not sure myself - the aptitude GUI shows these as no longer used, so marked for removal.
[19:10] <jdong> _stink_: oh, they're marked for autoremove... so that's what {u} is...
[19:10] <jdong> heh it's totally ungoogleable
[19:10] <_stink_> hehe
[19:11] <jdong> _stink_: eh then it doesn't look so bad; explicitly aptitude install things that you don't want it to autoremove?
[19:11] <jdong> _stink_: probably easier to mark that using Synaptic if it's a GUI enabled system
[19:11] <_stink_> lemme give that a shot.
[19:11] <_stink_> thanks.
[19:11] <Pici> !newpackage > smallfoot-
[19:12] <jdong> sure thing
[19:19] <smallfoot-> yeah, someone already put a request on launchpad
[19:19] <smallfoot-> nobody does shit
[19:19] <_stink_> jdong: it was the mirror, fwiw.  switched back to us.archive.ubuntu.com and all is well.  thanks for your help.
[19:21] <micahg> !ohmy | smallfoot-
[20:22] <ajmitch> morning
[20:22] <ari-tczew> hi ajmitch
[20:28] <ivoks> wow... i'm not motu anymore :)
[20:29] <ajmitch> ivoks: you let it expire?
[20:29] <ivoks> yeah :/
[20:29] <jcastro> I knew I never liked ivoks!
[20:29] <jcastro> j/k
[20:29] <ajmitch> you can get that fixed, you know :)
[20:30] <ivoks> i have to reapply again :)
[20:30] <ajmitch> I'm sure the DMB wouldn't be too mean about it
[20:31] <ivoks> heh
[20:31] <ajmitch> it's not like you've been completely away from ubuntu for the last couple of years :)
[20:31] <ivoks> :p
[20:32]  * ajmitch no longer has direct ubuntu membership, for that matter :)
[20:34] <Rhonda> Does one receive a ping before it expires?
[20:34] <ajmitch> a week before
[20:35] <ajmitch> & every day after that until it expires
[20:35] <Rhonda> ivoks doesn't read mails?
[20:36] <ajmitch> a week isn't long if you're on holiday :)
[20:36] <Rhonda> What's holiday?
[20:36] <ivoks> and something like that happened
[20:48] <geser> ivoks: add yourself to agenda for the next DMB meeting (Oct 25th, 12UTC) and be there
[20:49] <ivoks> ts...
[20:49] <ivoks> i'll be on the plane whole day that day
[20:49] <ivoks> nex time, i guess
[20:49] <ivoks> geser: but thanks
[20:51] <shadeslayer> any ideas where opensuse keeps its packaging?
[20:51] <shadeslayer> like we have bzr
[21:15] <shadeslayer> nvm
[23:52] <maxb> Does anyone know off hand what the best way to set something like PYTHONPATH=build/temp.linux-x86_64-2.6 is, to run tests during a build on what you just built?
[23:55] <RAOF> Set that in the environment before running your tests?
[23:57] <ScottK> maxb: I assume you want to add that to PYTHONPATH, not be all of PYTHONPATH?
[23:57] <ScottK> import sys
[23:57] <ScottK> sys.path.append('build/temp.linux-x86_64-2.6')
[23:58] <maxb> Well, there shouldn't be any PYTHONPATH before that, since it's inside a build on a buildd
[23:58] <maxb> And the tricky bit is calculating the platform specifier right