[00:23] <merbit> can someone check out bug #568707 ? It looks like debian/rules is missing a sed command to replace "@java_launcher@" in file debian/JB-java.desktop.in
[00:24] <persia> Does it work with OpenJDK?
[00:24] <merbit> persia: yes :)
[00:24] <persia> Ah, it does!
[00:29] <nessita> hello everyone. I build a .deb for a project of mine (https://lp:launchpad/pycasa), and I uploaded the package to revu, but it complains "This package could not be extracted; there's no browsable directory for it on REVU." Would you know what steps I should take in this case? (the tar.gz can be opened with no problem, and the .deb installs just fine)
[00:30] <persia> nessita: Your next step is to relax.  REVU doesn't have a new enough dpkg to unpack your package.
[00:30] <nessita> persia: wow
[00:30] <lool> Would someone be able to help me sync over libhildonhelp from sid?
[00:31] <lool> to fix a FTBFS in Ubuntu
[00:31] <persia> lool: A straight sync?
[00:31] <lool> I didn't manage to fill in the sycn request
[00:31] <lool> persia: yeah
[00:31] <lool> 2.0.5-4
[00:31] <nessita> persia: ok then, thanks!
[00:32] <persia> lool: Just file a sync request, no?
[00:32] <persia> Or do you need a test-build/etc. ?
[00:32] <merbit> james_w: Are you in charge to update the ubuntu package branches? Could you update sun-java6? https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/sun-java6/lucid shows it's going to be updated, but never is! https://code.edge.launchpad.net/ubuntu/lucid/+source/sun-java6 says it's 20 weeks old
[00:33] <james_w> merbit: I'm one of the people that can do that, yes
[00:33] <james_w> however, it's not a 2 minute job, sorry
[00:33] <james_w> I've just realised that we don't import partner, and I'm not sure that we should
[00:34] <james_w> and the branch is never updated with the state from when it wasn't in partner due to MemoryError apparently
[00:34]  * james_w files some bugs
[00:34] <merbit> that was my next message, i kind of realized that :)
[00:34] <lool> persia: I didn't manage to
[00:34] <merbit> thanks :)
[00:34] <lool> persia: requestsync doesn't want to take it
[00:34] <lool> neither with --lp nor without
[00:35] <persia> Then just file a bug with the right title, the expanation why the ubuntu diff can be dropped, the explanation why it needs to happen pre-release, and a changelog diff.
[00:35] <ajmitch> lool: LP is a little slow on picking up that there's a new version in debian
[00:36] <persia> Subscribe the archive-admins.
[00:37] <james_w> merbit: bugs 568740 and 568741
[00:38] <merbit> james_w: thanks!
[00:39]  * lool filed https://bugs.launchpad.net/ubuntu/+source/libhildonhelp/+bug/568742
[00:46]  * ajmitch should have filed a bug about the lp records of debian packages not updating properly
[00:51]  * ajmitch will let the LP people deal with that now
[00:58] <persia> Interesting.  sun-java6 isn't in Ubuntu anymore.
[00:58]  * persia gives up on bug #568707
[00:59] <ajmitch> oh it's finally been removed?
[00:59] <persia> merbit: My recommendation would be to switch JVMs :)
[00:59] <persia> Apparently so.  I've been ignoring it for a good while now, but it's gone so I can be explicit about ignoring it :)
[01:00]  * ajmitch hates getting nearly unintelligible telemarketing calls at work
[01:00] <StevenK> persia: It moved from multiverse to partner
[01:01] <persia> StevenK: But rmadison doesn't show partner :)
[01:01] <StevenK> That can be fixed
[01:01] <StevenK> I'd rather not, but don't tempt me :-)
[01:01] <persia> Personally, I consider it a feature.
[01:01] <ajmitch> but he wants to be able to ignore it :)
[01:02] <persia> StevenK: That said, I'd be delighted if you knew how to make rmadison show ports.
[01:02]  * persia currently has to fiddle with running madison-lite twice
[01:03] <ajmitch> StevenK: you're 'familiar' with gina & soyuz, right? :)
[01:04] <persia> What does gina do?
[01:04] <ajmitch> from what I was told, keeps track of source packages in debian
[01:04] <ajmitch> though that's probably a rather wrong description
[01:05] <ajmitch> A script that generates Launchpad database entries for tables related to
[01:05] <ajmitch> packages; bases itself on Katie data and Debian package/release tag files.
[01:05] <ajmitch> from the README file in the LP source
[01:07] <StevenK> ajmitch: What about it?
[01:07] <ajmitch> StevenK: reocrds of uploads to sid aren't showing up on LP, I can't tell if it's intentional (probably not)
[01:08] <ajmitch> it makes requestsync unhappy, I filed bug 568745
[01:09] <StevenK> persia: Right, to make the madison-lite mirror on people.c.c support ports requires crimes against humanity that I'm not willing to commit
[01:09] <persia> StevenK: OK.  Thanks for looking into it.
[01:09]  * persia may have to set up a local madison.cgi
[01:10] <ajmitch> crimes against humanity sounds like a good description of some of this soyuz stuff
[01:10] <StevenK> madison.cgi is trivial, if you have a cache seeded with ports stuff
[01:10] <persia> ajmitch: The key part of the phrase is "I'm not willing to commit"
[01:11] <persia> I'd have to fake it, by setting up something to merge the ./dists/ trees
[01:11] <StevenK> ajmitch: But looking at https://edge.launchpad.net/debian/+source/gpt doesn't show unstable at all?
[01:12] <persia> Might it be a side effect of the "let's sync from testing" adjustment?
[01:12] <ajmitch> StevenK: correct
[01:12] <StevenK> persia: I was thinking that
[01:13] <ajmitch> I'd have thought it'd have been more of a problem before now
[01:13] <ajmitch> thought I haven't exactly been doing a lot of syncs
[01:13] <persia> Since that gets readjusted in a couple weeks, I'm not sure how critical fixing it now might be.
[01:14] <StevenK> I can't see unstable on https://edge.launchpad.net/debian/+source/glibc either
[01:15] <ajmitch> I'm doing it wrong - there are records for sid on there
[01:15] <ajmitch> but they're not updated for gpt
[01:16] <ajmitch> https://edge.launchpad.net/debian/+source/gpt/1.0.4-1 says it's uploaded to sid, but 1.0.4-3 was uploaded a week ago
[01:19] <ajmitch> I think I'll go & get lunch instead :)
[01:20] <imbrandon> StevenK / persia is it something that could be setup on ubuntuwire ?
[01:21] <StevenK> No, it has LP internals all through it
[01:21] <imbrandon> ah
[01:22] <persia> imbrandon: We could do something entirely different that pulled every upload from Debian and extracted the changelogs, and made a DB, etc., but that's just a lot of effort when it's working around a simple bugfix.
[01:22] <imbrandon> yea
[01:41] <ajmitch> persia: you may as well use UDD for that, if it were needed
[01:41] <persia> ajmitch: Indeed.
[01:53] <ScottK> YokoZar: wine accepted.
[01:53] <YokoZar> ScottK: Great.  now onto the next one...
[02:27] <YokoZar> ScottK: https://launchpad.net/ubuntu/lucid/+source/wine/1.0.1-0ubuntu11
[02:27] <YokoZar> ScottK: failed to upload?
[02:27] <YokoZar> do I need to bump the version?
[02:30] <ajmitch> YokoZar: it's not liking the version
[02:31] <ajmitch> http://launchpadlibrarian.net/45057644/upload_1703023_log.txt
[02:31] <YokoZar> ajmitch: it probably got confused by the rejected upload having the same version then
[02:51] <ScottK> YokoZar: No.  Not that.
[02:51] <ScottK> YokoZar: What was the wine version when it was provided by the wine1.2 package and what is it now?
[02:52] <YokoZar> ScottK: ugh, yeah that was 1.1.42-something
[02:52] <ScottK> So you need a higher version.
[02:53] <ajmitch> thiss was the WARNING in that upload log
[02:53] <ScottK> Since your package doesn't derive from Debian at all, I don't think an epoch would be a problem.
[02:54] <YokoZar> ScottK: If I make this Wine > 1.1.42, users of wine1.2 will be downgraded to it and that's not supposed to happen
[02:54] <ajmitch> but it neeeds to be higher than what's in the archive currently for it to exist
[02:55] <ScottK> YokoZar: Did wine1.2 provide wine or was it an actual package?
[02:55] <YokoZar> ScottK: it was a dummy package
[02:55] <YokoZar> So new wine needs to be > original Wine and < current wine1.2 package
[02:56] <ScottK> Are the actual wine and wine1.2 packcages co-installable?
[03:40] <YokoZar> ScottK: no they're not, I'm worried about making dpkg spew out one of those refusal to upgrade things
[03:43] <ScottK> YokoZar: Yeah, I agree.
[03:44] <ScottK> I'm not sure what the right answer is.
[03:44] <persia> YokoZar: Whilst you're fiddling with wine, would you be up for adding an entry to P-a-s?
[03:46] <YokoZar> persia: No, as I explained earlier the package has parts that are usable on all arches (the font), and there is an ARM port underway
[03:46] <YokoZar> persia: In its current state it doesn't try to build on the other arches anyway as it lists them specifically in the control file
[03:46] <persia> An ARM port!  For WinCE?
[03:46] <persia> Yeah, it's because it doesn't build, but wastes build scheduler time and buildd time not building that I wanted to see the P-a-s entries.
[03:46] <YokoZar> persia: For winelib apps at first, but in the future Windows Mobile compatibility is reasonable as it's very similar to win32
[03:47] <YokoZar> persia: why would the builder try to build on an arch that has no binary targets?
[03:48] <persia> YokoZar: Because the semantics of .dsc files aren't rich enough to properly identify which architectures should be used for building, which is why we have P-a-s.
[03:49] <YokoZar> persia: do the architecture=all packages become available on P-A-S prohibited targets?
[03:49] <persia> Absolutely.  Those are arch:all, so only get build on i386, and may be installed anywhere.
[03:49] <persia> P-a-s is only how we tell the buildds not to bother even trying a source on an arch.
[03:50] <persia> So if a source has a combination of Architecture fields in debian/control that means it should never be tried on some architecture (e.g. wine on sparc), it makes sense to P-a-s it.
[03:53] <YokoZar> persia: Will P-A-S affect ppas?
[03:53] <persia> No idea, but since PPAs don't build any interesting architectures anyway, I doubt it matters.
[04:34] <YokoZar> persia: My thinking was if ARM port gets somewhere and I put Wine ARM port on a PPA I don't want to deal with worrying about P-A-S issues for a stable release
[04:34] <persia> PPAs don't support ARM anyway.
[05:19] <ScottK> If someone could investigate a sync request for zabbix, that looks likely to be fruituf.
[05:20] <persia> 1:1.8.2-1?
[05:20] <ScottK> Yes
[05:20] <ScottK> Sync or merge, whichever.
[05:21] <ScottK> In the meantime, I think I will sleep
[05:21] <persia> Good night.
[05:22] <persia> http://www.zabbix.com/documentation/1.8/manual/about/what_s_new_1.8.2 looks like a massive volume of feature additions to me.
[05:22] <persia> Anyone actually use zabbix?
[05:24] <persia> Reading the docs, I don't think I can test a new version effectively.
[05:24] <ajmitch> ScottK: your opinion on bug 568670? I just got warned of it by a DD
[05:24] <ScottK> Is it better to risk a possble broken new version or release with a known security issue?
[05:24] <ScottK> Good night.
[05:26] <persia> ajmitch: Can't that be cherrypicked trivially and safely?
[05:26] <ajmitch> it'd just be adding the conflicts, I think
[05:27] <ajmitch> rather than grabbing that revision of perl
[05:27] <persia> That's what it looks like to me.  Pulling newer software seems risky, but not upgrading seems bad.
[05:27] <persia> cherrypicking can probably skip both options.
[05:27] <ajmitch> at least ubuntu-release is subscribed now, hopefully slangasek will see it soon :)
[05:28] <persia> I'd suggest attaching a cherrypick debdiff for consideration.  I believe the release team operates best when there's something to review.
[05:29] <persia> I'm certain they respond more effectively when something is milestone-targeted.
[05:29] <ajmitch> true
[05:29] <ajmitch> I'll create a quick debdiff & nominate it then
[05:30] <ajmitch> whatever is needed to avoid messy upgrades
[05:30] <persia> Can't you just milestone it?  I thought you were core-dev
[05:30] <ajmitch> I can, UI still says nominate for release
[05:31]  * ajmitch looks for the right milestone button
[05:33] <ScottK> ajmitch: I'm just trying to get that bug to load in my browser
[05:35] <ScottK> ajmitch: I'd just milestone it and upload the proposed package.  It's a lot easier for the release team to review in the queue and accept/reject than it is to do the additional round trip if it's decided an upload is wanted.
[05:35] <ajmitch> alright
[05:36] <ScottK> I've got the LP foo covered
[05:37] <ajmitch> I'll make up a package now then
[05:39] <ScottK> Great.
[05:39] <ajmitch> may take awhile to test-build, so don't stay up waiting for it :)
[05:39] <ScottK> I am enjoying the irony of safe-rm breaking upgrade.
[05:39] <ScottK> I won't.
[05:39] <ScottK> Good night again.
[05:40] <ajmitch> night
[08:11] <dholbach> good morning
[08:11] <ajmitch> morning dholbach
[08:11] <dholbach> hola ajmitch
[08:12] <ajmitch> how are you?
[08:13] <dholbach> ajmitch: very slowly waking up, but alright :)
[08:13] <ajmitch> heh
[08:14]  * ajmitch is forever doomed if this upload gets accepted - I'll have the TIL curse for perl for maverick
[08:14] <dholbach> hahaha
[08:15]  * dholbach hugs ajmitch
[08:15] <persia> ajmitch: You always wanted to be a perl hacker, right?
[08:15] <ajmitch> persia: yeah, and cyanide is tasty & wholesome, right?
[08:15] <persia> Of course.  The only cure for oxygen addiction.
[08:16] <ajmitch> at least I wasn't the last person to touch php
[08:17] <ajmitch> so how's universe looking for release this time round?
[08:22] <persia> Depending on architecture, I get 310/107/100/163 from `apt-cache unmet -i | grep ^Package | wc -l`
[08:22] <ajmitch> it could be worse
[08:22] <ajmitch> though it'd be nice to see them at 0
[08:22] <persia> ubuntuwire ftbfs has 28 packages FTBFS on i386 (never mind other arches), and there's more at the UDD link.
[08:23] <persia> RCBugs is depressingly full.
[08:23] <Rhonda> persia, ScottK: I finally got around to upload wesnoth-1.8 1:1.8-3 to unstable, including a change to have installing the wesnoth-1.8-server package make it _not_ start automatically, closing a LP bug. :)
[08:23] <ajmitch> it'll be SRU season soon
[08:23] <persia> Rhonda: File a sync request.
[08:23] <persia> (and share the bug number of the sync)
[08:24] <persia> ajmitch: My worry is that everyone will be focused enough on maverick, that these will never be fixed.
[08:24] <ajmitch> persia: that's usually the case
[08:24] <ajmitch> I should probably sit down with the rc bugs list & try & get a few more fixes in, or scrub the bug as unimportant
[08:25]  * persia has done a few hit&miss scans, and expects to spend some real time with it over the weekend.
[08:25] <ajmitch> it's not entirely accurate either
[08:25] <ajmitch> yeah, I went & added a few comments, I need to follow up on getting the fix in
[08:26] <ajmitch> not sure when we'll be told to stop uploading to let the buildds be free
[08:26] <Rhonda> persia: I will, just give me a moment to settle. ;)
[08:26] <Rhonda> Thought I'd drop a notice prior to that.
[08:27] <persia> I think we're good up until the usual deadlines: Xubuntu and UbuntuStudio stuff can always rescore, all the architectues are mostly caught up, and main gets 1000 extra points anyway.
[08:27] <persia> Rhonda: No huge rush :)
[08:30] <fabrice_sp> I asked that on ubuntu-release, but not sure it was the right channel: Hi. Is this sync acceptable? (https://bugs.launchpad.net/ubuntu/+source/gorm.app/+bug/568619) It fixes a FTBFS and make 2 packages installables
[08:31]  * ajmitch finds 2 to knock off the rcbugs list
[08:32] <persia> fabrice_sp: Am I reading that right that the only "feature additions" are the button style popups and the support for standalone views?
[08:32]  * persia would imagine it to be OK, but suspects it needs release-team ACK
[08:35] <ajmitch> ugh, xemacs21 needs a merge
[08:37] <fabrice_sp> persia, that's also my point (mainly bug fixing, but some 'new' features)
[09:27] <slytherin> Are bug fixes still allowed for packages in universe?
[09:28] <slytherin> ahh, forgot to check topic.
[09:28] <persia> Absolutely!
[09:28] <persia> We have about 50,000 bugs to fix in the next week.
[09:32] <_ruben> ;)
[09:56] <slytherin> ha ha ha
[09:57] <Rhonda> persia, ScottK: LP bug #568871 is the sync request. Thanks in advance. :)
[10:02] <slytherin> Wow, I just checked yesterday and wesnoth 1.8 was not in unstable. :-)
[10:07] <slytherin> Rhonda: Any idea why is this a new package 'wesnoth1.8'?
[10:07] <the-dude> fabrice_sp: ping
[10:08] <fabrice_sp> the-dude, pong
[10:08] <Rhonda> slytherin: wesnoth 1.8 was in unstable yesterday and for a bit longer, too. It was just build-broken. And of course I have an idea about that because I did the change. ;)
[10:09] <slytherin> Rhonda: Ok. Then tell me. Why the source/binary package rename.
[10:09] <Rhonda> slytherin: The reason is to be able to install 1.6 and 1.8 side-by-side and not have to remove the one on upgrade and with that lose the posibility to finish a started campaign.
[10:10] <Rhonda> There were some people complain about that with last releases.
[10:10] <slytherin> Rhonda: Funny, I never faced such a problem.
[10:10] <Rhonda> On upgrade from 1.2 to 1.4, and then again from 1.4 to 1.6.  I wanted to avoid that for 1.8
[10:11] <slytherin> May it was specific to some campaigns. As I said, in my case the partial campaign always got converted properly.
[10:13] <persia> Rhonda: testbuild (powerpc) started
[10:13] <persia> Rhonda: Do you know if anyone ran it in Ubuntu yet?
[10:13] <Rhonda> Actually don't know that, sorry no.
[10:14] <Rhonda> slytherin: No, it was for all campaign. And 1.6 even started to use its own dotdir so it wasn't even technicly possible anymore to load a savegame from 1.4
[10:14] <Rhonda> Maybe you didn't had any unfinished campaigns from the old releases when you did the upgrades.
[10:15] <persia> slytherin: Since this needs runtime testing, and you're obviously a player, do you want to gram bug #568871?
[10:18] <slytherin> persia: I have not updated to lucid. If the dependencies are not very tight I can try.
[10:20] <the-dude> fabrice_sp: what can I do to get a new version of grsync in to ubuntu? I see you uploaded the last version
[10:21] <persia> slytherin: OK.  If you fail, let me know, and I'll play it tomorrow (I'll likely fall asleep first tonight).
[10:21] <slytherin> persia: Where do I find packages?
[10:22] <slytherin> the-dude: At this point new version is very much out of question (unless in very exceptional cases).
[10:22] <persia> slytherin: unstable
[10:22] <persia> slytherin: You'll have to build them
[10:22] <the-dude> fabrice_sp: it would solve a lot of open bugs, isn't that a good reason :)
[10:23] <the-dude> I could prepare a NMU if needed
[10:23] <slytherin> persia: That is problematic then. My machine freezes almost every time I try to build anything. :-( I thought I could pick packages from your test build.
[10:24] <fabrice_sp> the-dude, the actual version in ubuntu is the debian one, so you can fill a sync request, explaining why a FFe should be granted
[10:24] <persia> the-dude: We have no maintainers in Ubuntu.  THere's no such thing as NMU.  debdiffs may be sponsored.
[10:24] <persia> slytherin: I'm building powerpc/lucid.  I can pass you those.
[10:24] <persia> (or build something else)
[10:24] <slytherin> persia: powerpc is fine. I can test parallel install with 1.6 on karmic.
[10:24] <the-dude> fabrice_sp: its there https://bugs.launchpad.net/ubuntu/+source/grsync/+bug/556280
[10:26] <fabrice_sp> the-dude, you should follow the FFe process
[10:26] <the-dude> I can create a debdiff as well if someone wants to sponsor it
[10:26] <fabrice_sp> no need of debdiff, if the debian package works
[10:28] <the-dude> the debian package works, but it doesn't close LP bugs
[10:29] <fabrice_sp> that's why you hae to explain why it is so important to have it in lucid ;-)
[10:29] <the-dude> fabrice_sp: I already added comments to the open bugs
[10:30] <slytherin> fabrice_sp: I think he meant the debian changelog does not have (LP: #xxxxxx) comments.
[10:30] <the-dude> slytherin: yes thanks :)
[10:31] <the-dude> Im maintainer of the Debian grsync package
[10:31] <fabrice_sp> the-dude, subscribe ubuntu-release to get their ack
[10:32] <the-dude> fabrice_sp: ask them if it is ok to sync ?
[10:32] <fabrice_sp> yes
[10:32] <fabrice_sp> and you can add the bugs that this release would fix
[10:33] <fabrice_sp> !ffe|the-dude
[10:34] <fabrice_sp> that explain the kind of info you need to add to your sync request before subscribing ubutnu-release
[10:36] <AnAnt> Hello, is there a way to only download a delta instead of the whole .deb files on upgrades ?
[10:36] <geser> no
[10:37] <AnAnt> ok
[10:37] <slytherin> AnAnt: Have you ever heard of debdelta?
[10:37] <AnAnt> slytherin: maybe
[10:38] <AnAnt> slytherin: ok, I just read about it, but seems that it needs to be supported on server side too
[10:39] <slytherin> AnAnt: Yes. But there isn't much trouble in setting the server side.
[10:39] <AnAnt> slytherin: except that I am not the server side :)
[10:40] <slytherin> AnAnt: You may try requesting the server/repo admin.
[10:41] <slytherin> persia: Are you currently approving universe packages from queue?
[10:42] <persia> slytherin: I'm not a member of the release team.
[10:42]  * persia is in fact not a member of *any* special teams that appove anything *except* regarding membership in teams.
[10:43] <soren> It's funny really. You can go and make other people core-dev, but you'r not one yourself.
[10:45] <slytherin> hmm. ScottK, can you please approve pidgin-sipe whenever you get time.
[10:50] <persia> soren: I believe it to be that my wisdom is respected, but that I don't have frequent enough desire to upload to anything for which I'd need core-dev to be in the group.
[10:52] <soren> persia: Probably something like that. It's just a bit odd.
[10:53] <persia> I guess.  I end up with 3-4 uploads to main a cycle, and have since Breezy (excepting edgy and karmic, when I wasn't active).  I don't really anticipate this will change.
[10:54] <persia> Plus, I expect components to go away soon enough, so that the entire "main"/"universe" thing will go away.
[11:05] <imbrandon> i've been expecting them to go away for a while, dont see it happening though for 3 or 4 more cycles
[11:06] <slytherin> Does anyone know why such an error would be seen only on sparc buildd - gnome-icon-theme: Depends: libgtk2.0-bin but it is not going to be installed
[11:06] <imbrandon> is libgtk2.0-bin built ?
[11:06] <imbrandon> ( for sparc )
[11:07] <persia> slytherin: there's a script on the buildd that kills any attempt to build libgtk on sparc because it was killing the buildds.
[11:08] <persia> slytherin: In other news, the lucid sparc kernel isn't known to boot for anyone.
[11:08] <imbrandon> fun
[11:08] <slytherin> Oh. I will then stop worrying about why evolution isn't building on sparc. :-)
[11:08] <imbrandon> i dont have any sparc hardware anymore sadly
[11:08] <persia> Really needs a couple people with sparcs to pay attention, and it can work again.  There's only about 6-7 core bugs that make it mostly useless.
[11:09] <imbrandon> persia: what happened to fabionone or w/e his irc nick was
[11:10] <slytherin> persia: By the way, there are sparc packages here - https://edge.launchpad.net/ubuntu/+source/gtk+2.0 So I am really not sure why this error is seen during evolution build.
[11:10] <persia> imbrandon: He's around here and there.  Last I heard, he didn't have a fix.
[11:10] <imbrandon> ahh
[11:11] <persia> slytherin: Quite possibly due to archive skew (different versions)
[11:11] <persia> slytherin: Or maybe I'm out of date.  Would have to test on a sparc, and our virtual sparcs are currently broken for another reason.
[11:17] <slytherin> persia: 'different versions' does not seem to be a problem. Anyway, it's not like I care too much for sparc.
[11:17] <persia> heh.
[11:18] <persia> If we get a couple people to fix the core issues, the rest of us will happily chase the miscellaneous stuff.
[11:53] <ScottK> slytherin: I didn't see  pidgin-sipe in the queue.
[11:54] <slytherin> ScottK: Someone else approved it already.
[11:54] <ScottK> OK
[11:54] <slytherin> ScottK: I thought it was you. :-)
[11:55] <ScottK> Nope.  I was sleeping.
[11:59] <fabrice_sp> ScottK, would you mind having a look at bug 568619 and see if it requires a FFe?
[12:01] <ScottK> fabrice_sp: Perhaps later today.  Currently I need to sleep.
[12:02] <imbrandon> ScottK: wakeup just for an IRC fix ;)
[12:02] <ScottK> No, woke up to get the first wave of kids off to school.
[12:04] <imbrandon> ahh
[12:28] <persia> slytherin: Rhonda: This is going to take a whle: it *finally* started ./configure
[12:28] <slytherin> ok
[12:29] <Rhonda> persia: Well, build with -b wouldn't build the source (again) and spare you a lot of time. :)
[12:29] <persia> Rhonda: I didn't rebuild the source: I just fed it to sbuild for binary-only build.
[12:30]  * persia doesn't have a very super-powerful powerpc
[12:37] <imbrandon> consumer powerfull powerpc hardware is becomming increasingly harder to find
[12:37]  * imbrandon wouldent mind picking up something arround 2ghz at somepoint
[12:38] <persia> Doesn't help that I have a new rule that all my servers must be smaller than 200mmx200mmx100mm
[12:38] <imbrandon> ;)
[12:40] <slytherin> persia: Is your machine slower than G4 1.3 GHz with 1.2 GB RAM?
[12:40] <persia> More CPU, less RAM.
[12:40] <persia> But < 10% more CPU
[12:41] <persia> But it's nearly done, and I'm doing arch-all on a different machine (2x2.5GHz/4G)
[12:42] <imbrandon> hrm
[12:44] <imbrandon> i have a video file, i know its a video file because my portable media player will play the file as video, it became a video file by a piece of windows software that converted my mpg-2 file to this format, so i'm lookin at it trying to figure out what it is so i can use something like ffmpeg to create more of them, but linux "file" only knows it as :data :(
[12:44] <imbrandon> ideas ?
[12:44] <persia> Rhonda: I'm getting lots of dpkg-gencontrol: warning: unused substitution variable ${wesnoth:Max-Version} messages.  Dunno if that's intended, or matters.
[12:47] <slytherin> imbrandon: Try something like this - gst-launch-0.10 -t playbin uri=file:///path/to/file
[12:47] <slytherin> imbrandon: that -t should print out metadata.
[12:47] <slytherin> if it can actually identify it.
[12:50] <imbrandon> k
[12:52] <imbrandon> hum i get exactly 2 lines of output, and nothing else seems to be happening ( but it hasent given me a prompt back either )
[12:52] <imbrandon> Setting pipeline to PAUSED ...
[12:52] <imbrandon> Pipeline is PREROLLING ...
[12:53] <slytherin> imbrandon: Is the video playing in a window?
[12:53] <imbrandon> nope, no windows opened up
[12:54] <slytherin> hmm, looks like it is not able to identify the type. Do you have all the gstreamer plugins packages installed?
[12:54] <imbrandon> yea as far as i know, and ubuntu-restricted-extras plus w32codecs and vlc
[12:54] <imbrandon> and a slew of other "media" stuffr
[12:54] <imbrandon> s/stuffr/stuff
[12:55] <slytherin> hmm, any chance you can post the video anywhere.
[12:55] <imbrandon> sure, give me just a sec
[12:56] <Rhonda> persia: http://bugs.debian.org/557133 :)
[12:56] <persia> Rhonda: Aha!
[12:56] <Laibsch> Can somebody please sync pastebinit from Debian unstable and fix bug 566933?
[12:56] <Rhonda> persia: I take it that you are building it on karmic, not on lucid then? ;)
[12:57] <persia> I'm building on lucid.
[12:57] <Rhonda> Hmm. Maybe the bug needs to get reopened. I really have to check my own build logs.
[12:57] <imbrandon> slytherin: http://storage.brandonholtsclaw.com/misc/Hilary_Duff_-_Beat_of_My_Heart.mtv
[12:58] <persia> Laibsch: Why?  I didn't see any additional changes in Debian that were worth changing.
[12:58] <Rhonda> persia: Anyway, that's the bug you found and it is well known to me. :)
[12:58] <persia> If it's known, and didn't compromise my build, I'm happy.
[12:58] <slytherin> imbrandon: It will take a while to download. Will let you know when I am done with analysis.
[12:58] <Rhonda> So expected behavior and no influence, yes.
[12:58] <slytherin> imbrandon: At least half hour
[12:58] <imbrandon> slytherin: great , and thanks
[12:59] <imbrandon> slytherin: no worries, i'm just starting my day, i'll be arround for the next ~8 hours minimum
[13:02] <Laibsch> persia: that's exactly the point.  To have no Ubuntu delta going into the lucid release.
[13:03] <persia> Laibsch: Not worth making a fuss about: there are more critical uses of archive-admin time right now, and the bug in LP that keeps the rest of us from processing syncs is getting closer to closed, but isn't there yet.
[13:03] <Laibsch> if nothing else it makes things easier for me.  And me being the maintainer of the package, that means, I'd be much more inclined and responsive to backport fixes once lucid is released.
[13:04] <persia> Laibsch: So, I ACK'd it, and put it in the right place to get synced, but I don't consider it release-critical.
[13:04] <carstenh> imbrandon: i did not read this link, but googling for the first string in the video ... http://mympxplayer.org/solved-mtv-aliavi-converter-on-linux-vt12615.html
[13:04] <Laibsch> persia: I never said it was RC
[13:04] <Laibsch> but then again, I don't think we now fix only RC bugs
[13:04] <Laibsch> now
[13:04] <persia> Laibsch: We're in final-freeze.  If it's not RC, it's not likely to happen.
[13:04] <Laibsch> ?
[13:05] <Laibsch> if that rule existed, that would be stupid IMNSHO
[13:05] <Laibsch> a fix is a fix
[13:05] <imbrandon> carstenh: i think i looked at that , but it said to use wine, but let me try make sure
[13:05] <persia> Laibsch: There are 7 people who can process syncs.  They are all focused on RC issues.  Is this bug important enough to distract them?  It's in the queue, so if they have a spare moment, they'll do it.
[13:06] <carstenh> imbrandon: maybe the strings ALIAVI RIFF and WAVEfmt could help slytherin to find a solution faster
[13:06] <imbrandon> carstenh: yea i seen that, it says use wine ( i would rather not if i can help it )
[13:06] <persia> That there are so few people who can do it is a bug, but that's a different issue.
[13:06] <imbrandon> true
[13:09] <imbrandon> carstenh: btw, thanks :)
[13:25] <slytherin> imbrandon: Just FYI ... 'file -i filename' is better use of the command.
[13:27] <imbrandon> :)
[13:44] <slytherin> imbrandon: Sorry, can't help much. Here is the output from gst-launch - http://paste.ubuntu.com/421019/
[13:45] <persia> File copy is the worst part: data+music >> 200MB
[13:45] <imbrandon> slytherin: ok thanks a ton for looking, i'll keep poking, i'm gonna beat this thing if it kills me
[13:45] <imbrandon> :)
[13:45] <slytherin> persia: Don't copy music. It is not hard dependency.
[13:46]  * slytherin will be back in half hour.
[13:46]  * persia may have published binaries by then
[13:50] <nigelbabu> .ws 26
[14:13] <ScottK> fabrice_sp: For libmetadata-extractor-java, would you please just cherrypick the changes needed to fix the FTBFS and upload rather than sync all the changes.
[14:14] <ScottK> (sync is good for Maverick)
[14:20] <persia> slytherin: http://people.ubuntu.com/~persia/wesnoth-1.8/
[14:35] <slytherin> persia: Thanks. I am updating some CD images. After that I will download the packages.
[14:35] <persia> Heh, OK.  Dunno if you want the debug packages or the music, but just in case :)
[14:38] <slytherin> persia: Nope. Just core + data + campaigns.
[14:39] <persia> slytherin: If it works, please ACK the sync rather than telling me, to save time :)
[14:39] <slytherin> persia: But I am not part of release team. :-)
[14:39] <slytherin> I will add comment on bug.
[14:39] <persia> slytherin: and subscribe the archive-admins.
[14:40] <persia> It's just two cherrypicks from upstream.
[14:41] <persia> (upstream bugs 15716 15865)
[14:41] <persia> So since it's bugfix-only, no release-team ACK required (although the archive-admins may not prioritse it)
[14:42] <slytherin> My bad. Actually I was assuming it to be a new upstream version (with appropriate FFE data available).
[14:43] <persia> No, just fixes.  Otherwise I wouldn't waste time on it this close to release :)
[14:43] <slytherin> :-)
[14:47] <fabrice_sp> ScottK, ok (about cherrypicking the fix for libmetadata-extractor-java)
[14:47] <ScottK> fabrice_sp: Thanks.
[15:56] <mok0> ls -Fart
[15:56] <hyperair> mok0++
[15:56] <mok0> hyperair!
[15:56] <hyperair> mok0!
[15:57] <mok0> My mouse is focus confused
[15:57] <hyperair> focus confused?
[15:58] <mok0> Uhm yes it was focused Pidgin and not terminator
[15:59] <hyperair> =O
[15:59] <hyperair> mok0: i thought that was intentional
[15:59] <hyperair> i mean -Fart sounds like an awesome flag combination ;-)
[15:59] <mok0> hyperair: Indeed :-)
[16:00] <persia> It'S both memorable and useful
[16:00] <mok0> hyperair: it could be the start of a great meme
[16:00] <hyperair> mok0: submit it to the xkcd author, maybe he'll think of something =p
[16:00] <mok0> hyperair: heh, can you do that?
[16:01] <hyperair> mok0: i don't know =\
[16:01] <mok0> hyperair: but... but.. but... he so KNOWN!
[16:01] <mok0> :-)
[16:02] <hyperair> mok0: to me, you're a celebrity too =p
[16:02] <mok0> hyperair: what are you trying to achieve :-)
[16:02]  * hyperair whistles and walks away
[16:02] <mok0> hehe
[16:06]  * hyperair makes a tomboy note: flattery does not work on mok0 ;-)
[16:06] <ScottK> Stuff like this is why I always minimize my IRC window before typing passwords now.
[16:06] <mok0> Tomboy eh? I'm a Zim man myself
[16:07] <mok0> ScottK, I did that once
[16:07] <mok0> My best password, too
[16:08] <ScottK> Fortunately mine wasn't.  It was just my Skype password.
[16:08] <ScottK> (emphasis on was)
[16:08] <mok0> ScottK, ah yes, low grade ones
[16:09] <mok0> Well, people should run john the ripper on their /etc/password files once in a while. It's an enlightening experience
[16:10] <hyperair> mok0: me too. i dumped it out on #ck on oftc >_>
[16:10] <mok0> :-/
[16:11] <hyperair> thankfully, since firefox keeps track ofm y passwords, i just had to do a search and change passwords on all the sites that used it.
[16:11] <hyperair> (it would be awesome if chromium could do the same)
[16:11] <mok0> hyperair: keep track of passwords? It can
[16:11] <hyperair> mok0: searching, no.
[16:12] <mok0> ah
[16:12] <hyperair> mok0: anyway isn't john the ripper supposed to operate on /etc/shadow?
[16:13] <mok0> hyperair: can't remember
[16:13] <mok0> hyperair: I think it operates on whatever you give it
[16:13] <hyperair> heh i see
[16:13]  * hyperair tries
[16:13] <mok0> But tbh I can't remember given it's been more that a few days since I ran it last
[16:14] <mok0> About the length of my memory span
[16:14] <mok0> :)
[16:51] <micahg> bdrung: how did you upload vlc-1ubuntu1 without it hitting Debian first?
[16:52] <bdrung> micahg: vlc -1 is just waiting for a sponsor
[16:52] <bdrung> micahg: git makes it possible ;)
[16:53] <micahg> bdrung: k, thanks, one less package for me to worry about this weekend :)
[16:53] <bdrung> :)
[17:14] <ScottK> FYI, keep uploading stuff, but we need to hold off accepting Universe packages until after the current language pack export gets built down.
[18:47] <mdeslaur> ScottK: can I upload xchat to fix a FTBFS?
[18:48] <ScottK> mdeslaur: Definitely.
[18:48] <mdeslaur> ScottK: cool
[18:51] <micahg> ScottK: is Sunday ok for Seamonkey upload?
[18:52] <ScottK> micahg: Assuming it meets the criteria for an update this late in the cycle and it's not on any ISO, yes.
[18:52] <micahg> ScottK: you approved teh FFe
[18:52] <ScottK> micahg: Sooner the better.
[18:53] <micahg> ScottK: will try for early Sunday then
[19:28] <didrocks> ScottK: can you accept the new quickly version, please? (not sure I have to bother you each time ;))
[19:29] <ScottK> didrocks: We're waiting for the language pack export to finish before accepting more Universe packages.  That's another ~7 hours.
[19:29] <ScottK> No need to ping every time
[19:30] <didrocks> ScottK: ok, make sense. And thanks for the info, I'll avoid to ping you everytime so ;)
[19:31] <didrocks> I'm never sure in freeze period about what's the process, everything uploaded to universe is still accepted until final?
[19:33] <ScottK> It'll be reviewed.
[19:58] <ajmitch> morning
[19:59] <sistpoty> hey ajmitch
[19:59]  * ajmitch needs to compile stuff, it's cold this morning
[20:02] <geser> :)
[20:09] <ScottK> Excellent.  We need more fixed.
[20:09] <ScottK> ed/es
[20:10]  * sistpoty bangs his head against abiword
[20:16] <ivoks> ScottK: thanks ;)
[20:31] <imbrandon> moins ajmitch
[22:17] <mcas> hi
[22:17] <mcas> can someone give me a hint how i can make a selection like in the postfix package and depending on this selection change the pre-depends of the package?
[22:18] <sistpoty> mcas: what do you want to achieve?
[22:19] <sistpoty> (ooo upgrade path is fixed, should hit mirrors in several hours, if that's what you're trying to achieve)
[22:20] <mcas> there is a bug in bacula-server... this package needs mysql-server but the mysql-server gets started after bacula wants to create the db...
[22:21] <mcas> but it is possible that you want to use another mysql-server so i would like to build a selection like "localhost, remote server" and if the user selects localhost the mysql-server has to be started before bacula wants to connect
[22:23] <sistpoty> mcas: that should be best fixed within dbconfig-common, I guess
[22:24] <sistpoty> (I think there's also a bug report mentioning this)
[22:29] <sistpoty> bug #563039 fwiw
[22:40] <psusi> isn't there a bzr command to export a tarball?
[22:44]  * psusi facepalms... I swear bzr exort was the first thing I tried.... must have mistyped it
[23:01] <persia> sistpoty: I don't have any of the leftover files from openal-soft currently.  The ABI change was just new symbols added: no drops: it *ought* work with existing clients (and worked with torcs).  The test case failed.  I can regenerate, but with other things, this will probably be 12-18 hours at least.
[23:01] <persia> Err, the test case failed with the in-archive stuff, and succeeded with the update, rather.
[23:02] <sistpoty> persia: I'd like to take a glimpse at it to see the amount of changed symbols (and I'd still like to see the full debdiff, we need a package ready to go out *now*)...
[23:02] <sistpoty> persia: however my gut feeling is that we'll need to defer it to sru past release
[23:04] <sistpoty> persia: oh, and thanks for your input, any good input for FFe's is always appreciated :)
[23:04] <persia> sistpoty: Isn't it tricky to do in SRU?
[23:05]  * persia is not yet awake enough to remember why, but remembers YokoZar mentioning some issues in the comments.
[23:05] <sistpoty> persia: cherry-picked fixes shouldn't be tricky to SRU? and I guess updating ia32-libs from the fixes should also be trivial
[23:06] <persia> OK, if you're comfortable.  ia32-libs is ugly enough I don't really like the idea of SRUing it, but that's a release/sru team decision :)
[23:07] <sistpoty> persia: well, I'm not -sru, but I think if fixes are cherry-picked (instead of a huge diff), -sru won't object much ;)
[23:08] <persia> I think cherrypicking would be painful: there's heaps of changes.
[23:09] <sistpoty> persia: a heap of changes also makes it imho a bad idea to bring in now for lucid :(
[23:10] <sistpoty> apt-cache rdepends libopenal1 | wc -l => 45
[23:11] <persia> Yeah :/
[23:11] <persia> It's bad either way.
[23:12] <persia> My reasoning for pre-release is mostly: 1) upstream seems to care, and it makes them happy and 2) saves users downloading ia32-libs twice.
[23:12]  * ScottK thinks if cherry picking were going to happen we'd have an SRU for Karmic already
[23:12]  * persia suspects that's the case
[23:13] <ScottK> sistpoty: I'd suggest we need to make a decision about leaving it like it is or updating.  I don't think a hypothetical cherrypick is a realistic expectation.
[23:15] <sistpoty> ScottK: I'm not comfortable to give an ack for any library with rdepends where I didn't see a symbol diff, a proposed debdiff, and a diff of headers (which I usually take from rebuilding the package myself) at this point
[23:15] <ScottK> OK.  That sounds like a lot less work that a cherrypick later.
[23:17] <crimsun> sistpoty: if you're still following abiword, there are at least two commits that need to be applied; the xmlparsercleanup and gobject init ones
[23:17] <persia> sistpoty: Fair.  I'll try to produce those later.
[23:17]  * persia wishes YokoZar was about
[23:17] <sistpoty> crimsun: yes, still looking at it
[23:18] <sistpoty> crimsun: thanks for the info
[23:18] <crimsun> the former is known to cause Bad Things (pulseaudio is almost always blamed, but it ain't PA's fault but the app that abuses xmlParserCleanup() )
[23:18] <crimsun> I started looking at abiword last night, but I ran out of disk space
[23:19]  * sistpoty only managed to do two rebuilds so far :/
[23:20] <sistpoty> oh, abisource is back online, finally :)
[23:45] <sistpoty> crimsun: any pointers about the xmlpasercleanup patch? can't find xmlParserCleanup in the source or the debdiff