[00:15] <NCommander> wgrant: I don't remember, did you ever sponsor any of my uploads?
[00:15] <wgrant> NCommander: I did not.
[00:15] <NCommander> ok
[00:17] <NCommander> StevenK: ping?
[00:22] <ion_> wgrant: Where is this ALLCAPS complaint about an ALLCAPS EULA?
[00:23] <wgrant> ion_: Only the description of my bug that has been circulating everywhere... Have you not seen it?
[00:23] <sbeattie> ion_: bug 269656
[00:23] <wgrant> That one.
[00:24] <ion_> Thanks
[00:26] <ion_> The bug report is missing ‘HEREAFTER REFERRED TO AS “THE BROWSER”’ etc. ;-)
[00:27] <wgrant> Sorry.
[01:33] <slangasek> cody-somerville: xubuntu images are up for alpha-6 and awaiting testing
[01:35] <nxvl> \o/
[01:35] <_Zeus_> this isn't gmail :P
[01:36] <nxvl> _Zeus_: ?
[01:36] <_Zeus_> that's a gmail smiley
[01:36] <slangasek> it's not a smiley
[01:36] <_Zeus_> oh?
[01:36] <slangasek> it's an army
[01:36] <nxvl> nop, that's a clasic celebration ascii emoticon
[01:36] <_Zeus_> slangasek: whoa, you're the guy who answers like all the launchpad bugs
[01:37] <_Zeus_> hmm..
[01:37] <slangasek> I am? :)
[01:37] <_Zeus_> OH wait.  i was thinking of \m/
[01:37] <_Zeus_> slangasek: yeah.  Steve Langasek.
[01:37] <nxvl> it's a guy with the arms up
[01:37] <_Zeus_> ah
[01:37] <_Zeus_> now i see him
[01:38] <nxvl> _Zeus_: yeah, slangasek can be a little grumpy sometimes, but really funny when not :D
[01:38] <slangasek> _Zeus_: oh, yes, I suppose I am him
[01:38]  * nxvl HUGS slangasek
[01:38]  * slangasek hehs
[01:39] <nxvl> \m/ is a hand with 2 fingers up, the clasic ROCK ascii emoticon
[01:39] <nxvl> :D
[01:39] <_Zeus_> ya
[01:40] <_Zeus_> anyone know how to remedy this? https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/271459
[01:42] <pochu> If a package is moved in Debian from contrib to main, what's the procedure to get it reviewed/moved from multiverse to universe? bug 269074
[01:44] <_Zeus_> no one has any idea i take it...
[01:49] <cjwatson> pochu: file bug, subscribe ubuntu-archive
[01:50] <mathiaz> cjwatson: is partman-auto-raid working ? I'd like to get it included on the server cd
[01:53] <cjwatson> mathiaz: I don't know that it isn't, but then again since we haven't been using it it's untested in an Ubuntu context
[01:53] <_Zeus_> is mark shuttleworth ever on irc?
[01:54] <ion_> Yes
[01:54] <cjwatson> mathiaz: given its structure, it's harmless if not explicitly activated, so I have no objection to somebody adding it to the platform.intrepid/installer seed after alpha 6
[01:54] <_Zeus_> ion_: what's his username?
[01:54] <mathiaz> cjwatson: ok - I'll also have to write a MIR for it
[01:55] <ion_> zeus: sabdfl. You could have found out it by grepping this channel’s WHO list. :-)
[01:55] <cjwatson> Mark's IRC username is easily found; but he's a busy man, please don't bug him :)
[02:11] <ScottK> persia: It turns out that reading debian/copyright doesn't help at all when it comes to discovering the conditions under which one is allowed to freely modify Firefox.
[02:12] <slangasek> debian/copyright doesn't cover the copyright license of the firefox logo?
[02:13] <ScottK> Well it's actually a Trademark issue, not a copyright issue.
[02:13] <ScottK> But no.
[02:14] <ScottK> I think it's perhaps a policy hole that was opened when we diverged from Debian on allowing such restrictions, but didn't describe how they are to be documented.
[02:15] <slangasek> ScottK: the whole reason Debian forked was over the inclusion of a restrictive copyright license on the logo to enforce their trademark
[02:16] <ScottK> OK.  Maybe I'm tangled up in terminology then.
[02:16] <slangasek> so either something's changed in the licensing that I'm unaware of, or there's a bug in debian/copyright for it not being documented
[02:16] <ScottK> No, it's in the upstream file called "LEGAL"
[02:18] <ScottK> Also the argument that we have 'abrowser' so one's right to modify/distribute is unhampere started to seem a bit specious to me when I noticed it's a binary built out of the firefox-3.0 source package.
[02:20] <ScottK> So I'd suggest it's more correct to characterize it as an unbranded version of Firefox, not as an unbranded alternative that is actually DFSG Free.
[02:20] <slangasek> I don't see the distinction there
[02:21] <ScottK> If I grab the Iceweasel source package, I can patch it and upload it and distribute it in any MPL/GPL/whatever the third license is manner I want.
[02:22] <slangasek> ok, so you're asserting the restrictions on naming mean it's not DFSG Free.
[02:22] <ScottK> Yes.  I don't think that's in question.
[02:22] <slangasek> I don't either; I think it's just false ;)
[02:23] <ScottK> It's just that I think "Don't worry about Firefox not being quite free, it's OK we have abrowser" is meaningless.
[02:23] <cjwatson> "The license may require derived works to carry a different name or version number from the original software." DFSG#4
[02:23] <ScottK> OK.  I'm a muppet then.
[02:23] <ScottK> So why do we have Iceweasel?
[02:24] <slangasek> ScottK: because the Debian maintainer chose to rename it to free himself from the requirement to get everything approved by MozCorp
[02:24] <slangasek> it was entirely the maintainer's choice, not something that was considered a requirement (by Debian at large) under the DFSG
[02:25] <ScottK> I see.
[02:26] <slangasek> I think it was a reasonable choice to make, because Mozilla's intertwining of copyright and trademark in the license went beyond the pale for free software projects
[02:27] <slangasek> but I don't think Ubuntu taking the other path means a choice for non-freeness, either
[02:27] <ScottK> I agree, but I think there's a limit to how far down that path it's reasonable for us to tread.
[02:29] <slangasek> fwiw, if you want precedent in Debian for software with renaming requirements on modification, try apache and metafont :)
[02:29] <ScottK> Obviously people will disagree, but it's my opinion (based on the incomplete information I have) that we went a bridge to far.
[02:29] <slangasek> (but neither of those includes an EULA, of course)
[02:29] <ScottK> Right.  I'd have preferred we renamed, but understand the choice and accept it.
[02:30] <ScottK> I don't understand how we could have accepted this (and I hope that at some point it'll be explained why this was OK).
[02:34] <cjwatson> those of us who were involved weren't exactly comfortable with it either, although we saw different trade-offs; but, reading Mitchell Baker's blog, it looks like it should turn out OK in the ned
[02:34] <cjwatson> end
[02:36] <ScottK> I'm deeply curious about Mark's comment in the bug that staying with an older version without the EULA requirement like Fedora did was not an option for us.
[02:36] <ScottK> To me that would have seemed like the easy right thing to do.
[02:37] <cjwatson> we can't do that with Firefox; they have a history of bundling security updates with other updates in such a way that they're infeasible to disentangle
[02:37] <cjwatson> same reason as Firefox has a standing exception for new upstream versions in stable releases
[02:37] <kirkland> cjwatson: i have an update-motd, removing the initscript, all of the debconf configuration, etc.
[02:37] <ScottK> I understand we couldn't have released that way, but release is a ways off yet.
[02:37] <cjwatson> kirkland: what did you put in place of the init script?
[02:38] <kirkland> cjwatson: nothing
[02:38] <cjwatson> ScottK: that would have just landed us with the same problem after release, which would have been worse. This has been brewing for a while
[02:38] <kirkland> cjwatson: pitti was pretty anti-init script for this utility
[02:38] <cjwatson> ScottK: it was better to get it out of the way
[02:39] <kirkland> cjwatson: http://people.ubuntu.com/~kirkland/update-motd/
[02:39] <kirkland> cjwatson: i have not uploaded to universe
[02:39] <kirkland> cjwatson: i understand it's middle of the night for you, probably
[02:39] <kirkland> cjwatson: so no request to review
[02:39] <ScottK> cjwatson: Thanks for taking the time to give me your perspective on it.
[02:39] <cjwatson> any reason not to upload it?
[02:39] <kirkland> cjwatson: if you'd like to, though, i'm all ears
[02:40] <kirkland> cjwatson: well, i do have one question
[02:40] <kirkland> cjwatson: etc/cron.d/update-motd is being installed into place, rather than being generated via debconf/config/postinst
[02:40] <cjwatson> I'd just like to say that the objection to the init script was pitti's; I wasn't concerned by it
[02:41] <kirkland> cjwatson: so users upgrading from 1.5 to 1.6 will get a question about what to do about a conflicting conf file
[02:41] <kirkland> cjwatson: I understand ;-)  we're all looking out for our best interest...  no complaints from me.
[02:41] <cjwatson> there are sneaky ways around that, though they may not be worthwhile
[02:41] <kirkland> cjwatson: i did put a lot of effort into the debconf code, and you recognized that, which I appreciated, but I think you're right in the end... just more room for bugs
[02:42] <kirkland> cjwatson: so what i did in place of an init script was to add --disable and --enable options to /usr/sbin/update-motd itself
[02:42] <cjwatson> yeah, I think it was doing the right thing, but ... well, I'm debconf co-maintainer and even I can't just look at that kind of code and say whether it's correct or not
[02:42] <kirkland> cjwatson: where --disable touches /var/run/update-motd.disabled, and --enable removes it
[02:42] <cjwatson> ah, ok
[02:42] <cjwatson> that sounds sane
[02:43] <kirkland> cjwatson: that gives the flexibility i wanted ...  to be able to turn it off without uninstalling the package or farting around with the cronjob
[02:43] <kirkland> pitti and i came up with that in a private IRC conversation
[02:43] <ScottK> kirkland: That doesn't mean it comes back on after every reboot does it?
[02:43] <cjwatson> much more intuitive than an init script, I expect
[02:43] <kirkland> ScottK: nope.  it's sticky
[02:44] <ScottK> OK.  Even though /var/run is tempfs?
[02:44] <kirkland> it does throw an error message, if you try and run it when disabled
[02:44] <cjwatson> tmpfs> I was about to say the same thing :)
[02:44] <kirkland> update-motd is currently disabled.
[02:44] <kirkland> You might try:
[02:44] <kirkland>   * update-motd --enable
[02:44] <kirkland>   * update-motd --force
[02:45] <cjwatson> so where is the state stored between reboots?
[02:45] <kirkland> i stand corrected, i didn't realize that /var/run was tmpfs
[02:45] <kirkland> so it's not sticky
[02:46] <kirkland> if you want to disable it over boots, remove the cronjob
[02:46] <kirkland> the enable/disable is merely meant as a simple convenience for short term disabling
[02:46] <cjwatson> can I suggest /var/lib/ somewhere instead then? it seems like it ought to be sticky
[02:46] <kirkland> cjwatson: sure, would /var/lib be the best place for it?
[02:47] <cjwatson> that would be my instinct, though the convention there seems to be to create a subdirectory
[02:47] <cjwatson> sorry for YA minor change
[02:47] <kirkland> sure, that's easy
[02:49] <cjwatson> kirkland: I think you need to exit 0 after parsing --enable as well as after parsing --disable?
[02:49] <slangasek> kirkland: /var/run is declared in the FHS to be not sticky, so it's a tmpfs ;)
[02:50] <cjwatson> kirkland: what's the point of echo 2>&1?
[02:50] <kirkland> cjwatson: well, i mentioned in the manpage that it will enable AND run it immediately
[02:50] <cjwatson> if you want it to go to stderr, use 1>&2 (or >&2)
[02:50] <kirkland> cjwatson: but i'm indifferent
[02:50] <cjwatson> ah, I didn't see that, OK
[02:50] <cjwatson> that seems reasonable enough
[02:50] <kirkland> slangasek: thanks ;-)    more knowledge > kirkland
[02:51] <cjwatson> >>, we hope ... ;-)
[02:51] <StevenK> Haha
[02:51]  * slangasek laughs
[02:51] <kirkland> :-D
[02:51] <StevenK> "Want device .... used for digging food ..." "A spoon?" "Yes"
[02:52] <cjwatson> the diff looks good to me otherwise and should mean there's no contention about main inclusion
[02:52] <kirkland> cjwatson: thanks for catching my broken stderr redirects
[02:53] <kirkland> cjwatson: i'll exit 0 after --enable, and note in the manpage that it exits immediately (not updating the motd)
[02:53] <cjwatson> I don't care about that, if you prefer the other behaviour then it sounds completely sensible
[02:54] <cjwatson> I just noticed the asymmetry, that's all, but life is not necessarily symmetric
[02:54] <kirkland> cjwatson: do one thing and do it well :-)
[02:54] <kirkland> cjwatson: enable and exit
[02:54] <cjwatson> mkay
[02:56] <kirkland> cjwatson: changes pushed to http://people.ubuntu.com/~kirkland/update-motd/update-motd-1.6/
[02:56] <kirkland> cjwatson: i'll do some testing of the /var/lib changes, for sanity
[03:01] <kirkland> cjwatson: what about purging the old /etc/init.d/update-motd script?
[03:01] <kirkland> cjwatson: on upgrades, i mean
[03:02] <cjwatson> yes, might be reasonable with a version guard
[03:04] <kirkland> cjwatson: can you point me to a package with a sample?
[03:04] <cjwatson> hmm
[03:04] <cjwatson> alsa-base.postinst
[03:05] <cjwatson> consolekit.preinst has a more paranoid version that removes it only if unmodified
[03:07] <cjwatson> dhcdbd.p* has an even more careful and (I think) correct version that removes it only if modified and deals with rollback in the event of failed unpack or configure
[03:09] <NCommander> StevenK: you floating around?
[03:09] <StevenK> NCommander: I might be
[03:10] <Hobbsee> NCommander: only if you test some cds :P
[03:11] <NCommander> Hobbsee: for what, and why?
[03:11] <Hobbsee> NCommander: alpha 6!
[03:11]  * NCommander burns
[03:11] <NCommander> Ew
[03:11] <NCommander> *er
[03:11] <Hobbsee> NCommander: https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-September/001134.html - get to it!
[03:11] <NCommander> I can
[03:11] <Hobbsee> good man :)
[03:11] <NCommander> I didn't say I would ;-)
[03:11]  * NCommander runs
[03:12] <Hobbsee> NCommander: you inferred it, and my Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ is nice and sharp, for if you don't...
[03:13] <bddebian> Wow, haven't seen the pointy stick in quite a while
[03:14] <NCommander> Hobbsee: your stick is in metric, and I'm in imperial. Its incompatable with me
[03:14]  * Hobbsee attacks bddebian with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™
[03:14] <Hobbsee> NCommander: actually, i'ts both.
[03:14] <bddebian> NCommander: Heh, nice one
[03:14] <Hobbsee> NCommander: so, fail.
[03:14] <Hobbsee> bddebian: which image are you going to test?  :P
[03:17] <kirkland> cjwatson: http://people.ubuntu.com/~kirkland/update-motd/update-motd-1.6/debian/postinst
[03:17] <kirkland> cjwatson: while I'm at it, should I go ahead and 'fix' the conf file overwrite prompt?
[03:17] <kirkland> cjwatson: would that go in postinst, or elsewhere?
[03:22] <cjwatson> kirkland: TBH I'd just leave it, it's a one-time thing and only affects alpha users
[03:22] <kirkland> cjwatson: fair enough!
[03:22] <cjwatson> postinst is fine
[03:23] <kirkland> testing looked good, i'm going to upload, and email pitti
[03:23] <bddebian> Hobbsee: None of the above? :)
[03:23] <kirkland> he said he'd check email and review
[03:23] <Hobbsee> bddebian: so you will face the Stick.  Poor Man.
[03:23] <cjwatson> kirkland: ok, cool
[03:24] <kirkland> cjwatson: as always, big thanks \o/
[04:42] <TheMuso> cd
[06:23] <persia> Is there a tool that can track when packages are no longer built for a given architecture?  I've hit this before, but have again run into some outdated arch-specific binaries for packages that will no longer supply them, and was interested in hunting for some tool to track everything out-of-date towards requesting they be removed as old, buggy, and unlikely to be fixed.
[06:27] <slangasek> you're looking to track packages that have been dropped on /an/ architecture, but not on /all/ architectures?
[06:30] <slangasek> if so, I'm afraid the only tool I know of for doing this is dak; unless pitti's NBS script happens to cover that case
[06:32] <persia> Nope, the NBS script doesn't happen to cover that case.
[06:33] <persia> And I'll admit to a little trepidation in trying to import Ubuntu into dak just to hunt for these.
[06:33]  * wgrant wonders where bug #271502 should go.
[06:36] <slangasek> persia: yes, I don't think importing the database into dak is the right way to go about it :)
[06:38] <persia> No, probably not.  And e.g. http://people.ubuntu.com/~ubuntu-archive/testing-ports/intrepid_outdate.html only covers main, which is only part of the list.
[06:39] <persia> What's the best way to request removal of these?  A bug listing all the individual binaries to be removed on a per-arch basis, or a pointer to the changed source?
[06:41] <persia> (today's annoyance being the linux-meta binaries for *all* ports)
[06:41] <slangasek> list of binaries
[06:41] <persia> OK.  I'll file a bug.  Thanks.
[06:42] <persia> Also, do you know of any way of generating the _outdated.* output for universe as well?
[06:43] <slangasek> britney
[06:43] <slangasek> it just needs to be fed the full Packages lists; this isn't done because the version of britney being used is resource-intensive
[06:44] <slangasek> switching to a newer one is on my TODO
[06:44] <persia> So if full packages lists are available somewhere, running britney ought do the right thing?
[06:44] <slangasek> yes, if britney is invoked correctly
[06:44] <persia> wgrant: Is that something that would be trivial to set up, or does it need someone to construct the code?
[06:45]  * wgrant can look into that.
[06:45] <persia> wgrant: Thank you.
[07:39] <bryce> slangasek, cjwatson: I've been picking through the changes between our acpi-support and debian's.
[07:42] <bryce> slangasek, cjwatson:  I found there's a huge amount of changes Debian made, that didn't get rolled into ours.  The package has basically forked in a major way.
[07:43] <bryce> slangasek, cjwatson:  to try and bring things back closer together, I've cherrypicked a bunch of the changes that look understandable and safe to me.  Here's what I've got so far:  http://bryceharrington.org/ubuntu/ACPI/
[07:46] <bryce> slangasek, cjwatson:  Anyway, I'd like to hear your comments/encouragement before continuing with the next set of changes.  The next set of changes get into some structural issues that significantly change how this package works, so would like to get your thoughts first.
[07:50] <bryce> hi cjwatson
[08:02] <slangasek> bryce: I'm afraid I'm not going to be able to provide much guidance there as far as the correctness of such changes; I've been aware for some time of the Debian forking of acpi-support, but haven't had the bandwidth to chase it up
[08:04] <bryce> slangasek: hmm, do you think I should continue with pulling in selected debian changes?
[08:04] <slangasek> for intrepid?  probably only ones you confirm fix bugs :)
[08:04] <bryce> are Debian bug fixes ok?
[08:05] <bryce> so far I've just been pulling in ones that look logically correct to me just by eyesight
[08:05] <bryce> well, and a few that seem appropriate for thinkpads...
[08:07] <tjaalton> I think acpi-support upstream should be debian and not us..
[08:08] <tjaalton> since we don't have anyone maintaining it ;)
[08:08] <slangasek> bryce: if they're valid bugfixes that are relevant to us, sure; there's no requirement that you file bugs in LP before fixing them
[08:09] <bryce> tjaalton: I've been wondering about that
[08:10] <bryce> slangasek: okie doke.  I plan to look through LP and see if we have bugs that these changes fix.
[08:18] <sbeattie> asac: ping
[09:13] <slangasek> persia, TheMuso: any expectations of testing UbuntuStudio alpha-6 soon?
[09:14] <persia> There was some testing going on 12-3 hours back.  I'll see if I can get the results somewhere.  Where do you need them?
[09:16] <asac> sbeattie: ?
[09:17] <sbeattie> asac: was just wondering if bug 271654 was known already
[09:18] <slangasek> persia: on http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all
[09:18] <sbeattie> and whether ubufox was the right place to file it.
[09:18] <asac> StevenK: no its not
[09:19] <asac> sbeattie: can you reproduce this outside of liveCD?
[09:19] <sbeattie> asac: this was post install
[09:19] <sbeattie> asac: should have made it clearer in the bug report, but i'm a bit tired.
[09:19] <StevenK> asac: Hm?
[09:19] <asac> sbeattie: oh ok
[09:19] <persia> slangasek: Aha!  It's the amd64 variant that didn't get *any* testing.  I'll see if I can do anything about that.
[09:19] <asac> StevenK: sorry .. not you ;)
[09:20] <slangasek> persia: ok, cheers :)
[09:21] <asac> sbeattie: does this also happen when you move .mozilla away and start firefox?
[09:21] <sbeattie> asac: i can reproduce each time I start firefox after doing rm -rf ~/.mozilla/
[09:22] <kagou> Hi
[09:24] <asac> sbeattie: ok thanks. please add that info to the summary.  (e.g. reproduce by removign .mozilla)
[09:24] <sbeattie> asac: sure thing.
[09:40] <stefan__> hey, kann jemand über die konsole eine tv-karte initialiesieren?
[09:40] <\sh> asac: with ia32-libs 2.2ubuntu13 flashplugin10 works now as expected...(well, I need to test the rtmp connections still)
[09:42] <stefan__> hallo?
[09:43] <\sh> stefan__: this is an english speaking channel
[09:43] <wgrant> !de
[09:43] <stefan__> to do that?
[09:43] <stefan__> why is nobody there?
[09:43] <wgrant> I am not here.
[09:44] <stefan__> lucky Answer
[09:44] <\sh> stefan__: your question is better suited in #ubuntu (this is a development channel only)
[09:44] <stefan__> oh, take sure, sorry
[09:44] <stefan__> uhhhh
[09:44] <persia> stefan__: The answer to your question is "Ja", but the procedure you need is best collected in one of the channels ubottu mentioned.
[09:47] <asac> \sh: rock
[09:51] <\sh> asac: uploaded
[09:51] <\sh> asac: and air works too...(at least the installation ;))
[09:57] <pythonic> can i build a package for ubuntu on debian? using debootstrap?
[09:57] <azeem> sure
[09:58] <pythonic> which release should i use? intrepid?
[09:58] <azeem> that depends which release you want to build it for
[09:59] <pythonic> i'd like to submit the package for inclusion in ubuntu
[09:59] <azeem> that has nothing todo with building, Ubuntu does source-only uploads
[09:59] <azeem> pythonic: you should contact #ubuntu-motu for that
[10:00] <pythonic> yes, but i should check that it builds on some given release
[10:00] <pythonic> k, thanks
[10:01] <\sh> asac: http://paste.ubuntu.com/47990/ <- I just installed the "Color Browser" app from the air showcase...and I ran it from its installation dir...this is the only cruft I have left.
[10:01] <asac> \sh: sigh
[10:01] <\sh> but it works :)
[10:02] <asac> maybe ia32-libs should be ia32-all-libs-in-main ;)
[10:02] <asac> \sh: yeah ... most likely just broken theme engine for KDE users
[10:02] <\sh> asac: the libqt4engine.so for sure...
[10:02] <\sh> what bugs me is gio modules ;)
[10:03] <asac> oh .. i only looked at the bottom
[10:03] <\sh> asac: air app installer... Failed to load module: /usr/lib/gio/modules/libgiogconf.so
[10:03] <\sh> and so on
[10:03] <asac> shouldnt gio be in ia32-libs too?
[10:04] <\sh> that's libgio0 right?
[10:04] <\sh> dpkg _l
[10:04] <\sh> grmpf
[10:06] <\sh> gvfs
[10:06] <\sh> ah...I think that's not important
[10:07] <\sh> air installer uses gtk file dialogs...and I think it tries to use now the gvfs stuff..the modules are in the gvfs server package...and I wonder if that is sane to include into ia32-libs
[10:13] <therealjosh> hey
[10:14] <therealjosh> i am wondering, i have made a program with is a budget program written in gtk. How would I go about getting it into ubuntu? I know intrepid is already frozen, but is j??? a likely target? where do I go to find out about the process?
[10:15] <liw> therealjosh, https://wiki.ubuntu.com/UbuntuDevelopment is a good place to start
[10:17] <therealjosh> so do i need to get involved in the MOTU team just for one package?
[10:17] <liw> no
[10:18] <liw> the easiest way to get your package into Ubuntu would be to find someone to do the actual packaging for you, or with you; a MOTU could help you with that
[10:19] <liw> on the other hand, it would also be possible to go via Debian -- find a Debian developer to help with the packaging, and then the package will get into Ubuntu as well
[10:19] <therealjosh> So I should ask on #ubuntu-motu if anyone would like to package my application?
[10:19] <therealjosh> that would be better because it gets more coverage, correct?
[10:19] <therealjosh> thanks
[10:20] <therealjosh> i have to go
[10:23] <Robot101> https://bugs.launchpad.net/ubuntu/+source/ffmpeg-debian/+bug/254201
[10:23] <Robot101> does anyone know the rationale behind requesting the removal of these?
[10:24] <Robot101> it's totally cripped several video-capable sip/jingle clients including empathy and ekiga :(
[10:24] <Robot101> *crippled
[10:24] <siretart> Robot101: well, the archive admins don't accept mpeg based encoders in the 'main' archive
[10:25] <siretart> Robot101: the package has a script that disables some mpeg 1 decoders from ffmpeg, see debian/strip.sh in the source package
[10:25] <seb128> Robot101: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433287
[10:25] <Robot101> so it was just an accident that they were there for 4 or 5 years before being removed?
[10:25] <siretart> more or less
[10:26] <Robot101> there was me thinking ubuntu were being cool and more functional than debian
[10:26] <Robot101> so can they go in multiverse?
[10:26] <seb128> Robot101: I'm not sure it has been discussed for ubuntu
[10:26] <seb128> siretart: is the discussion you had a debian or an ubuntu one?
[10:26] <Robot101> seb128: they were in everything up until intrepid
[10:26] <siretart> seb128: both
[10:26] <Robot101> now intrepid's ffmpeg is crippled similarly
[10:26] <Robot101> debian's not had the encoders for a long time
[10:27] <siretart> seb128: the end of the discussion with ubuntu was "well, if debian doesn't accept them, we won't as well" (shortened)
[10:27] <seb128> siretart: who did you discuss this with?
[10:27] <Zdra> I don't know if medibuntu is kind of "official" but at least non-free codecs should be added there
[10:27] <siretart> seb128: that was in sevilla with at least pitti and elmo in the room
[10:27] <seb128> Zdra: no it's not
[10:27] <seb128> siretart: sevilla, that was ages ago
[10:27] <Robot101> I've not found a very good justification for them being removed in Debian either, tbh
[10:28] <seb128> siretart: we had no issue with those until now, I'm not sure why that's an issue now
[10:28] <cjwatson> bryce: pretty much what Steve said - I'm not going to be able to provide specific review unfortunately, so his general guidance sounds about right
[10:28] <siretart> seb128: so we do accept mpeg encoders in the 'main' component?
[10:28] <Robot101> I can understand MPEG4 having people enforcing it, but H263 is very, very old...
[10:28] <seb128> siretart: I don't know and I'm not the one to decide, I think that deserve some thinking and discussion
[10:29] <broonie> Robot101: There's rather a lot of money to be made enforcing it.
[10:29] <siretart> seb128: sure. each time I started that discussion it was.. difficult
[10:29] <Robot101> broonie: patents on H263?
[10:29] <siretart> because nobody wants to decide on that subject
[10:29] <seb128> siretart: is h263 that problematic?
[10:29] <broonie> IIRC, yes.
[10:29] <cjwatson> bryce: looks like you're doing the right kind of thing at least from looking at the changelog, though
[10:29] <siretart> seb128: I have no idea, TBH. there are patents on that, but I have no idea if its being enforced
[10:29] <Robot101> does anyone have any /actual/ source of knowledge on this, rather than heresay? :)
[10:30] <Robot101> s/ere/ear/
[10:30] <Hobbsee`> oh, so this is what server everyone's on.  I wish freenode wouldn't curl up and die like that.
[10:30] <seb128> siretart: I think that should be taken to the technical board
[10:30]  * broonie is seeing if he can dig up some notes from when he worked on this.
[10:30] <siretart> Robot101: use google patent search for h263
[10:30] <Robot101> like does Canonical have lawyers they can ask and get an answer
[10:31] <siretart> seb128: again? - well, I welcome you to mail the TB, CC'ing me.
[10:31] <Robot101> siretart: patents merely existing isn't a problem, it's if they're actively enforced
[10:31] <cjwatson> yes, we do; technical-board would be the place to start for that
[10:31] <siretart> seb128: I'd love to see an unrestricted ffmpeg in ubuntu
[10:31] <persia> Robot101: Even a laywer can't necessarily answer the question "Is it safe to distribute foo".  There are many jurisdictions, and each is different.
[10:31] <cjwatson> (if it hasn't been through the TB already of course)
[10:32] <siretart> cjwatson: the problem is determining if a codec 'is actively enforced' or not
[10:32] <cjwatson> persia: given what patents are like, our question is usually a bit more like "can we afford to distribute foo, I think"
[10:32] <Robot101> persia: right, but presumably Canonical's lawyers are used to opining on such vague questions :)
[10:32] <cjwatson> siretart: yes, I'm familiar with the problem
[10:32] <persia> cjwatson: Well, perhaps, but I think it's a matter for the TB, rather than a lawyer hired by a sponsor.
[10:32] <siretart> cjwatson: from what I've heared from the ffmpeg people is that they are not enforced against non-commercial projects but for companies that make a profit from them
[10:33] <siretart> some ffmpeg developers are hired by companies that pay patent fee to develop and sell their products
[10:33] <cjwatson> persia: the body who would be sued, in practice, is Canonical; therefore Canonical deserves the opportunity to decide
[10:33] <Robot101> siretart: on what exactly? MPEG4 I can very much understand, the MPEG people are very active in enforcing. H263 I'm not so certain.
[10:33] <siretart> it is very unclear if ubuntu would be considered as 'non-profit' in that context
[10:33] <siretart> I'm off for lunch, brb in 45min - cu later
[10:34] <cjwatson> persia: for example, there is a history (and I'm afraid I forget the specifics) of Mark saying that he was OK with distributing certain enforced-patent audio codecs but not others
[10:34] <persia> cjwatson: Er.  Well.  Perhaps.  I don't think it *should* be that way, but I can see that point
[10:34] <cjwatson> as in "I think this is worth it"
[10:35] <cjwatson> (actually I think it may have been more like "bring it on" but as I say I forget the specifics :-) )
[10:35] <Robot101> :P
[10:35] <persia> cjwatson: I understand.  The distinction is Mark as "representative of Canonical" and Mark as "leader of Ubuntu".  Anyway, as I said, given the current environment, it may not matter, especially for the ffmpeg question.
[10:36] <cjwatson> there are certainly things that might be considered too much of a risk, though; Canonical in principle has quite deep pockets and it could get ugly
[10:37] <persia> Sure.  Canonical being sued is significantly less than ideal.  That Canonical is the default body getting sued is likely also so.  That said, this isn't the forum to address that.
[10:38] <sykopomp> http://www.kroah.com/log/linux/lpc_2008_keynote.html I'll just leave this here.
[10:38] <sykopomp> ;)
[10:38] <stdin> sykopomp: ok, now leave then
[10:38] <persia> sykopomp: I'm not sure how that's relevant.
[10:38] <sykopomp> persia: Blame stdin, he told me this is where it belonged :)
[10:38] <elky> sykopomp, did he?
[10:38] <stdin> no, I didn't
[10:39] <sykopomp> persia: and I'm not sure how something directly related to ubuntu development is irrelevant.
[10:39] <elky> sykopomp, i'm not sure how berating the developers is a help in any way, shape or form.
[10:39] <persia> sykopomp: It's claims by someone that some company doesn't contribute to some selected subset of projects based on unavailable data.
[10:39] <sykopomp> elky: berating?
[10:40] <seb128> cjwatson: hi
[10:40] <sykopomp> persia: mmhmm
[10:40] <mvo> sykopomp: there is a replay at http://mdzlog.wordpress.com/2008/09/17/greg-kh-linux-ecosystem/ that is worth reading imo
[10:40] <sykopomp> persia: because the kernel is a meaningless subset that canonical accepts as perfect, and thus unworthy of man-hours of patching.
[10:40] <persia> sykopomp: Considering that the majority of developers do not have a formal relationship with that company, it's at least confused, and not likely contributory to further development of Ubuntu.
[10:40] <seb128> cjwatson: thanks for the comments about the new GTK, it made me uneasy too since that's somewhat a compatibility change, I mailed the GNOME list about reverting it for this cycle
[10:41] <stdin> sykopomp: please stop talking about things which you have no clue about, ie: everything
[10:41] <cjwatson> seb128: great, thanks
[10:41] <sykopomp> stdin: clever retort. Did you learn that in Internet School?
[10:41] <seb128> cjwatson: I think we should revert the change for ubuntu in any case, will do that in the next upload, is that something which is required to get a working installed in alpha6?
[10:41] <stdin> sykopomp: nope, came up with it all by myself
[10:41] <sykopomp> stdin: your mum must be proud.
[10:43] <sykopomp> mvo: and thank you, that looks interesting :)
[10:43] <sykopomp> mvo: was sort of hoping for an actual reply that didn't involve made-up logic (re: stdin)
[10:44] <elky> sykopomp, carry along now, and come back when you have something constructive to contribute.
[10:44] <sykopomp> elky: 'bawww'
[10:44] <Hobbsee> sykopomp: do you have something useful to add?
[10:44] <Hobbsee> sykopomp: and personal attacks are unwelcome in this channel.
[10:44] <elky> (and yes, attacking an entire company and an entire project is a personal attack)
[10:45] <sykopomp> Hobbsee: it's good to know personal attacks are unwelcome. That's the kind of rule that builds strong, mature communities. :)
[10:45] <elky> sykopomp, feel free to read the code of conduct some time too.
[10:46] <sykopomp> elky: link?
[10:46] <Hobbsee> !coc
[10:46] <sykopomp> thanks
[10:47] <sykopomp> You're all a lovely bunch, but I need my beauty sleep.  Don't take inquiry as trolling, this wasn't ;)
[10:47] <cjwatson> stdin: code of conduct applies to you too. You're out of order
[10:47] <sykopomp> nite, all, and happy hacking.
[10:47] <stdin> cjwatson: yes, I was getting annoyed. so I stopped responding
[10:48] <broonie> Robot101: My grovelling appears to indicate a possibility of crossover between MPEG and H.263 IP; I've got a feeling that may be a mistake for H.264, though.
[10:52] <Robot101> broonie: right, H.264 ~= MPEG4
[10:53] <Robot101> I thought H.263 and MPEG4 were developed quite separately, and MPEG4 was later adopted as H.264
[10:53] <broonie> Yeah, that's why I've got a feeling it may be a mistake.
[10:54] <broonie> but it's possible that some of the lower level stuff got shared while the overall structures are very different.
[11:08] <siretart> Robot101: well, I think I kind of agree with you that we can/should reenable h263 again.
[11:08] <siretart> Robot101: what I want to avoid at any price is that after reenabling I get approached by the archive admins rejecting the package
[11:09] <siretart> Robot101: this has happend to be already in debian, where we enabled _all_ encoders and had to implement this debian/strip.sh solution
[11:09] <siretart> Robot101: so what I actually ask for is for some guidelines what encoders are okay to leave in and what are to be disabled
[11:09] <seb128> siretart: really you should take that to the technical board so we have a clear decision taken on the topic
[11:10] <siretart> seb128: yes, perhaps you're right.
[11:11] <siretart> seb128: on my todo list is also to investigate the mplayer package, which also seems to contain all encoders in source and approach debian's ftpmasters with that. I didn't get to that yet, however
[11:11] <Robot101> that's likely to just have the functionality asked to be removed from mplayer too
[11:11] <siretart> but perhaps you're right and I should contact the tb in paralell.
[11:12] <seb128> siretart: speaking about todo, do you think you will update the ffmpeg snapshot before intrepid? ;-)
[11:12] <siretart> seb128: definitly not.
[11:12] <seb128> siretart: why not?
[11:13] <siretart> seb128: ffmpeg has changed both API and ABI last week, I do not have the ressources to fix all reverse dependencies
[11:13] <siretart> seb128: the API changes aren't that bad, but we still need to touch every package because the headers get installed into an other location, so we have to adjust all CFLAGS
[11:13] <seb128> siretart: can't you take a snapshot slightly less recent which doesn't break the compatibility?
[11:14] <siretart> the header change commit was done somewhen in april or may, we could perhaps update to something around that date, though
[11:15] <siretart> however since we are in feature freeze anyway, I think working on the package in experimental and clearing the patent issue has is more important, no?
[11:15] <siretart> seb128: why do you want to have ffmpeg updated? do you have a specific bug in mind?
[11:16] <seb128> siretart: no, I didn't follow the details but some bugsquader said there is several good reasons we should update, he mailed one of the ubuntu lists too about that
[11:17] <siretart> seb128: yes, I remember that guy. ignore him
[11:17] <siretart> seb128: he wants AMR support, which he confused with the AAC decoder, that got merged in early september this year
[11:17] <seb128> siretart: he's doing quite some good work on lot of bugs for some weeks and have good points often, not sure why you want to ignore him
[11:18] <siretart> on this point, the suggestion is totally unreasonable.
[11:19] <siretart> he was pretty demanding on that bug. and started a bug status change war. I decided to ignore him from then on
[11:19] <\sh> siretart: this amr stuff was this "external zip file with the not-known-royalty-free-source inside" right?
[11:19] <siretart> \sh: kind of. you need to build it against an libamr, which has unclear licensing AFAIUI
[11:19] <seb128> siretart: I didn't read the bug, but I'm not convinced that using 6 month old snapshots is good either
[11:20] <siretart> unclear or incompatible
[11:20] <\sh> siretart: yeah...got that during combots crap
[11:20] <\sh> unclear...there was some patent üpending or so
[11:20] <seb128> siretart: I'm pondering making gst-ffmpeg uses its ffmpeg copy again and not ffmpeg-debian
[11:20] <siretart> seb128: gst-ffmpeg's copy is even older, no?
[11:22] <seb128> siretart: they rolled a new tarball on 2008-09-03, let me look at what version they used there
[11:22] <seb128> siretart:
[11:22] <seb128> "	* ffmpegrev:
[11:22] <seb128> 	Update our 'prefered' ffmpeg snapshot to rev 15004. This has the fix for a nasty
[11:22] <seb128> 	wma2 decoding regression."
[11:22] <seb128> siretart: do you know if this revision is a recent one?
[11:23] <siretart> r15004 | michael | 2008-08-28 02:46:09 +0200 (Do, 28. Aug 2008) | 2 lines
[11:24] <seb128> siretart: ok, so no it's not older
[11:24] <siretart> ah, so they updated the copy
[11:24] <seb128> yes
[11:24] <siretart> well, that date has the header already installed to a different location
[11:24] <seb128> that's one reason why this guy started to request the ffmpeg-debian version
[11:24] <seb128> the new gst-ffmpeg fixes lot of issues
[11:24] <siretart> updating the package to that version would instantly break all other packages using ffmpeg
[11:24] <seb128> but we don't benefit of those because we use ffmpeg-debian which is clearly outdated
[11:25] <seb128> siretart: how many packages are we speaking about?
[11:25] <siretart> if you can convince the security team to use the embedded copy, it might be an option to use the internal ffmpeg
[11:26] <wgrant> Why would we want to do that?
[11:26] <siretart> everything build-depending on libavcodec-dev, libavformat-dev, libavutil-dev and libpostproc-dev
[11:26] <seb128> wgrant: because siretart refuses to update ffmpeg-debian and updating it would fix lot of issues
[11:26] <siretart> not sure about about libswscale-dev, I think not but might be wrong
[11:27] <seb128> wgrant: an easy way to get those fixes for gstreamer users would be to use the upstream gst-ffmpeg
[11:27] <wgrant> I don't blame siretart for not wanting to.
[11:27] <siretart> seb128: I don't refuse to update the version. I rather say that I don't have the ressources to fix the resulting breakage
[11:27] <wgrant> A better way is to hit ffmpeg upstream harder until they become less retarded.
[11:27] <seb128> wgrant: that will not make intrepid suck less for our users
[11:27] <siretart> wgrant: a better way would be to help me with ffmpeg maintenance
[11:27] <wgrant> seb128: Perhaps not, but it would make everybody's lives easier in the long run.
[11:28] <seb128> siretart: that's probably not the first ffmpeg breakage no? you have no idea about many packages are concerned? I'll have a look to that number
[11:28] <seb128> wgrant: not discussion that but that's orthogonal to the intrepid issue
[11:28] <wgrant> siretart: My time is unfortunately limited these days.
[11:28] <seb128> discussing
[11:29] <siretart> seb128: last time I counted it was about ~40 packages
[11:29] <siretart> including universe
[11:30] <siretart> for main its not so bad, but it includes packages like xine, kino and the like
[11:31] <siretart> seb128: updating to a newer ffmpeg upstream version requires to forward port the bounch of patches we carry in the package. OTOH, all of them were merged or no longer necessary versions > early september
[11:32] <seb128> siretart: I'll discuss with the security team about using the gst-ffmpeg copy for intrepid and we should upgrade the snapshot when intrepid+1 opens
[11:33] <siretart> seb128: yes, updating the snapshot for intrepid+1 is on my todo list. actually, I'm working on having a more updated package in debian/experimental, which I'll sync to some PPA
[11:33] <siretart> so we have the package ready when jaunty opens
[11:34] <seb128> siretart: looks good, thanks
[12:55] <psyke83> \sh: thanks for the work on ia32-libs. As per bug #192888, you removed libflashsupport - but we still need libasound2-plugins added. Would you like me to open a new bug or will I change the status back to assigned?
[12:56] <\sh> psyke83: libasound2-plugins is in...
[12:56] <psyke83> \sh: awesome, thanks. I didn't see it in the changelog
[12:56] <\sh> psyke83: it was already in :)
[12:56] <\sh> libasound2-plugins
[12:56] <psyke83> ah... I thought that it wasn't
[12:57] <\sh> psyke83: but I wonder if that helps, when some apps are looking under /usr/lib/... instead of /usr/lib32/....
[12:57]  * \sh declares, that he has no clue about nspluginwrapper and his function ;) so could be that it rewrites all the cruft
[12:58] <psyke83> \sh: did you test PulseAudio & Flash 10 RC? Install "padevmon" to get access to the PulseAudio GUI utilities, run "asoundconf set-pulseaudio", restart firefox and play some flash content - see if it uses pulseaudio
[12:58] <psyke83> asac: ping re: testing the pulseaudio output with flash 10
[12:59] <psyke83> \sh: no clue either ;)
[12:59] <asac> psyke83: so whats the problem?
[13:01] <\sh> psyke83: work
[13:01] <psyke83> asac: there's no problem, I hope. Remember yesterday I suggested that you test Flash 10 output
[13:01] <\sh> psyke83: and flex is working again ;)
[13:01] <asac> psyke83: does pulse plugin 32bit lib work with flash through nspluginwrapper?
[13:01] <psyke83> asac: i.e. make sure it lists itself as a pulseaudio client
[13:01] <\sh> asac: it works via alsa-plugin of pa
[13:01] <lool> slangasek: Hey, my nice upstream filed a MIR for python-dateutil; BTW allow me to clarify: it's needed for an embedded lib (storm); in the mean time, a new storm came out with twisted integration
[13:01] <cjwatson> 10:41 <seb128> cjwatson: I think we should revert the change for ubuntu in any case, will do that in the next upload, is that something which is required to get a working installed in alpha6?
[13:01] <cjwatson> seb128: sorry, I just noticed I missed that question
[13:01] <psyke83> asac: on a 32bit system, nspluginwrapper works fine... the only problem I noticed was some intermittant times when flash would "disappear", I still need to test that more
[13:01] <lool> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/python-dateutil/+bug/271680 and https://wiki.ubuntu.com/MainInclusionReportPythonDateutil
[13:01] <cjwatson> seb128: no, we've fixed the installer for alpha-6 to use page_size=0
[13:01] <asac> psyke83: ok. i think i have to wait a bit more before the new ia32 libs is published
[13:01] <\sh> http://www.youtube.com/watch?v=R13Gu3fr6Ug <- works quite nicely
[13:01] <seb128> cjwatson: ok good, I've the new GTK version ready on my disk with that changed, I'll upload after alpha6
[13:01] <psyke83> ah yes, I forgot
[13:02] <lool> slangasek: If you like, I can look into updating storm to the latest upstream which came out; I don't think the version currently in the archive is widely in use, but I'm not sure
[13:02] <lool> slangasek: It would be nice to drop an embedded copy of it for sure
[13:02]  * lool hugs seb128
[13:02] <\sh> asac: http://launchpadlibrarian.net/17716833/ia32-libs_2.2ubuntu13_amd64.deb :)
[13:02] <seb128> hey lool
[13:03]  * seb128 hugs lool
[13:03] <seb128> lool: did you read my question about the glib update? ;-)
[13:03] <lool> seb128: I sent you an email on that glib stuff, you were disconnected when I saw your ping
[13:03] <seb128> ah ok
[13:03]  * seb128 looks
[13:03] <seb128> lool: ok thanks
[13:03] <psyke83> asac: I'll ping you again when the package is published and in the repos, though I reckon it works, as \sh confirms. As for the PulseAudio issue, we just need Luke's passthrough patch to alsa-plugins and we can fix bug #198453
[13:05] <asac> psyke83: thats nice
[13:05] <asac> psyke83: is flash 10 already updated in archive too?
[13:06] <psyke83> asac: no, but the debdiff is available. I can build the package for you if you want to test it soon
[13:07] <\sh> we need an UVF Exception right?
[13:07] <psyke83> asac: I have it in my PPA, as well (though it differs slightly from the proper version, as it deletes a configuration file that the previous version set to disable windowless mode)
[13:07] <\sh> or does flash has a standing exception, universe wise?
[13:07] <asac> \sh: for flash?
[13:07] <\sh> asac: yepp
[13:08] <psyke83> \sh: yes, though I think flash gets an exception due to vulnerability issues. And the tarball is not archived on the labs.adobe.com server, so the package will break
[13:08] <\sh> flash10 i mean
[13:08] <NCommander> ACK, SPAM
[13:08] <psyke83> \sh: there was beta 1, beta 2, rc and rc2, all on the labs.adobe.com server. The older tarballs are deleted when they are obsoleted by a newer release
[13:08] <\sh> psyke83: do you have any clue on the final release date for flash10? eventually we need to push the final through updates
[13:09] <psyke83> \sh: I would imagine very soon, as the version string is using the rXX pattern - so it's a "genuine" release candidate already
[13:09] <asac> \sh: i think we should file a bug ... just to document this
[13:10] <asac> \sh: e.g. "feature freeze exception for flash 10 updates" ... or something
[13:10] <\sh> asac: yepp...but after release we need an SRU statement anyways...
[13:10] <asac> \sh: i have exception granting power for mozilla packages. we should check sispoty if that falls in that realm
[13:11] <asac> \sh: well, nothing to bother now :) ... maybe we get final for final :)
[13:11] <psyke83> \sh & asac: can we not convert bug #257403 to an SRU or FFe request?
[13:12] <psyke83> that has the debdiff for the latest release
[13:14] <\sh> moins mr. kwwii :)
[13:19] <lool> seb128: BTW I still have this extra /ext/xdg/menus file provided by gnome-menus; should I remove it by hand?
[13:20] <seb128> lool: no, the preinst should clean those on upgrade
[13:20] <lool> Ok; wasn't sure whether I'd get it as an intrepid upgrade
[13:21] <\sh> psyke83: yes..please convert it to an FFe, subscribe motu-release to it
[13:22] <\sh> psyke83: if you need an sponsor, I'm still at office/home until sunday...after that I'm gone for at least one week to work on new hardware in our DCs
[13:23] <psyke83> \sh: forget the n00b question. Is it sufficient to edit the title & description to signify it's a FFe, then subscribe motu-release? Do I need to do anything else with the package status?
[13:23] <psyke83> or "distribution" status
[13:23] <\sh> psyke83: there is a link on the wiki with the howto file ;) give me sec
[13:24] <psyke83> \sh: I guess this: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20upstream%20versions
[13:25] <psyke83> \sh: well, not new upstream versions, since we grab the tarball in the script
[13:26] <\sh> psyke83: yes..but you change the version to something else, or is it just a revision fix.. but no. rc2 introduces some new features, right?
[13:27] <\sh> psyke83: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20upstream%20versions <- that's the one
[13:28] <psyke83> \sh: there is a changelog on the labs.adobe.com site listing improvements and bugfixes, but only listing fixes from rc1 -> rc2. The version we have currently is beta 2 (the sequence: beta 1, beta 2, rc1, rc2). I'll paste it anyway, it's better than nothing
[13:28] <\sh> but more likely it's more a bug fix only update...so the paragraph under the FFe description is more correct...the bug is ok, put the changelog in it, put in debian/changelog a (LP: #<no>) and ok...
[13:28] <\sh> psyke83: hmm...is there no changelog anymore from beta2 to rc1? it can be merged then
[13:29] <psyke83> \sh: the changelog is removed from the site, I think... it's not archived anywhere
[13:29] <psyke83> \sh: the debdiff is compliant: http://launchpadlibrarian.net/17642343/flashplugin-nonfree_<IP_ADDRESS>ubuntu1.debdiff
[13:29] <psyke83> the first line of the changelog lists the LP#
[13:30] <psyke83> *changelog for older releases
[13:31] <psyke83> it's on a static page that's updated with each release: http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#fixed
[13:31] <\sh> psyke83: yes..Just paste the complete page in ;)
[13:31] <psyke83> cool, thanks
[13:31] <\sh> known issues+fixed issues
[13:47] <psyke83> \sh & asac: I've updated bug #257403 to a FFe, if you want to give it an ack
[13:47] <\sh> psyke83: I can't :) /me not motu-release :)
[13:47] <psyke83> \sh: ah, right... heh. Well motu-release were already subscribed
[13:50] <psyke83> \sh: I thought that sponsoring and giving ack were similar
[13:50] <\sh> psyke83: nope..sponsoring means, uploading your package with my powers ,-)
[13:50] <\sh> asac can do that too :)
[14:17] <lool> seb128: Oh cool, new gtk drops the xrr call which was causing screen flickers!
[14:44] <norsetto> asac, seb128: when you have some time, can you please check bug 250290?
[14:46] <asac> norsetto: is #485644
[14:46] <asac> the debian bug for this?
[14:46] <asac> otherwise i dont see in debian changes that there is a crash fix
[14:47] <norsetto> asac: yes, thats the bug that was fixed in Debian, same as our bug 250290
[14:49] <norsetto> asac: you may be confused since they fixed the fix so that t won't ftbfs on alpha
[14:55] <norsetto> asac: I can confirm that this also fixes bug 257272 and bug 264847
[14:59] <asac> norsetto: looks ok for me then. but i think seb128 has the say about the timing of that upload
[14:59] <norsetto> asac: sure, thanks
[15:25] <tseliot> Riddell: does KDE 4 have a GUI to configure touchpads? If not, which part of KDE should I hack on to add such functionality?
[15:32] <tseliot1> Riddell: my connection died. Did you receive my message or shall I write it again?
[15:32] <stgraber> bryce: Do I understand it right that the latest fglrx still doesn't fix the new X server support issue ?
[15:32] <ion_> It came through.
[15:33] <tseliot1> stgraber: yes, that it correct
[15:33] <tseliot1> is
[15:34] <stgraber> so, no fglrx for Intrepid ?
[15:34] <Riddell> tseliot1: i don't think there is a gui for touchpads it should be under mouse in system settings
[15:34] <Riddell> there was once ksynaptics but i neverf used it
[15:37] <tseliot1> Riddell: ok, thanks I'll have a look at it
[15:55] <seb128> lool: right, I marked the bug fix commited, I've the new version ready locally
[15:55] <seb128> norsetto, asac: did anybody look at updating to the current version?
[15:55] <seb128> asac: feel free to upload whenever you want
[15:56] <norsetto> seb128: if you mean from upstream I haven't
[15:57] <seb128> norsetto: alright, there is a new version so feel free to do the update too if you want ;-)
[15:58] <norsetto> seb128: willco
[16:01] <superm1> stdin, tseliot1, so since fglrx looks like it's probably not going to be ready quick enough, i think this is my current plan: I'll upload 8-9 to intrepid, and then downgrade the x server on an intrepid machine to the hardy version.  hopefully still be able to test other integration pieces so that when it comes time for an SRU, everything else is ready/been tested.  sound sane?
[16:03] <tseliot1> superm1: are you planning to patch the driver for kernel 2.6.27 or are you simply planning to try the driver and see how it goes?
[16:04] <tseliot1> either way I don't see any problems with a new upload of the fglrx driver
[16:06] <superm1> tseliot1, oh right, i forgot it didn't build on 2.6.27
[16:06] <superm1> i'll have to see how difficult it is to patch for it
[16:07] <tseliot1> ok
[16:45] <superm1> can an archive admin comment why was gcc-3.3 demoted to universe in hardy and intrepid?
[16:46] <StevenK> Presumably, because nothing in main required it
[16:46] <superm1> well fglrx now needs it to build as of 8-9
[16:46] <ScottK> In fact there are a determined effort to make that the case.
[16:46] <ScottK> are/was
[16:48] <superm1> so this is one of those things that will need to be sorted out so that an SRU will be possible when the xorg 1.5 support is in it
[16:49] <Keybuk> superm1: why doesn't fglrx build with gcc 3.4 ?
[16:49] <Keybuk> err 4.3
[16:49] <superm1> Keybuk, it's from a binary that's already shipped with the driver
[16:49] <superm1> Keybuk, libAMDXvBA.so.1.0
[16:49] <superm1> requires libstdc++.so.5
[16:50] <superm1> so when i say build, i'm referring to dpkg-shlibdeps borks out unless you've got libstdc++5 installed
[16:50] <Keybuk> that's ... old
[16:50] <Keybuk> I mean, I like outdated C++ template libraries as much as the next person, but that's still old
[16:51] <jdong> do we have any AMD buddies we can poke to "fix" that?
[16:51] <superm1> bryce, can you bring it up in your next discussion?
[16:53] <superm1> in the event that it's not sorted out in the next driver release though, only solution for us would be to re-promote gcc-3.3 for intrepid
[17:10] <s0u][ight> hello is intrepid using the drivers from compat-wireless?
[17:43] <slangasek> lool: updating storm doesn't sound like a good thing to focus on
[17:45] <norsetto> asac, seb128: devhelp diff.gz for 0.20 attached to bug 250290 if you prefer this to a merge with debian 0.19.1-5
[17:55] <ldp> YAY ME!!
[17:56] <_Zeus_> anyone know how i can roll back from kernel 2.6.27-3 to -2?
[17:56] <_Zeus_> it's not in the repos
[17:56] <ldp> I mean, hello..
[17:56] <mathiaz> slangasek: kirkland said that update-motd has been promoted to main. This was the blocker for landscape-client to be working in the -server installer.
[17:57] <mathiaz> slangasek: do you plan to respin a server iso for alpha6 or it's too late ?
[17:57] <slangasek> I wasn't planning to respin, no
[17:57] <slangasek> working in the installer - as an install option?
[17:57] <mathiaz> slangasek: there is an install option.
[17:58] <mathiaz> slangasek: one of the choice is "Configure landscape client."
[17:58] <mathiaz> slangasek: if you choose it, it won't work because landscape-client cannot be installed.
[17:59] <slangasek> ok
[17:59] <slangasek> that seems worth respinning, for; you'd be able to test in short order?
[18:00] <mathiaz> slangasek: sure.
[18:00] <mathiaz> slangasek: once the isos are available I can test all of the test cases in a couple of hours.
[18:01] <mathiaz> slangasek: but before you start respinning make sure that update-motd is published in main and that it will land on the -server isos.
[18:02] <slangasek> tkamppeter: foomatic-db 20080918-0ubuntu1> we're in a milestone freeze right now, please don't be uploading packages in the middle of the freeze that cause out-of-dateness on the CD images
[18:02] <slangasek> mathiaz: ah, well, it's not in main yet :)
[18:02] <slangasek> cjwatson: were you going to promote update-motd?
[18:03] <mathiaz> slangasek: pitti promoted it according to kirkland
[18:03] <kirkland> https://bugs.launchpad.net/bugs/260443
[18:03] <kirkland> pitti wrote "Promoted to main." in his last comment.
[18:03] <bryce> superm1: sure I'll email them now
[18:04] <superm1> bryce, okay thanks
[18:06] <slangasek> mathiaz: ah, 26 minutes ago, ok :)
[18:06] <slangasek> mathiaz: so I'm looking at stale data
[18:07] <bryce> superm1: do you have a bug id# btw?
[18:07] <superm1> bryce, yeah bug 271794
[18:11] <bryce> thanks
[18:53] <\sh> hmmm..does the last upload of fglrx-installer mean that it ati non-oss drivers are working now on intrepid? ,-)
[18:53] <tjaalton> no
[18:54] <\sh> I guessed
[18:54] <\sh> hopefully 8.10 will have new xorg love
[18:54] <tjaalton> it already has
[18:54] <tjaalton> just not fglrx love
[18:55] <\sh> (catalyst)
[18:55] <tjaalton> or, fglrx has no love for new xorg
[19:06] <superm1> \sh, it just means that it will compile against 2.6.27, so if you pin the x server at hardy's you can try to do regression testing on the other integration pieces
[19:07] <superm1> for when we end up doing an SRU for fglrx
[19:07] <\sh> superm1: na...I'm happy right now with the ati/radeon oss driver...I'm just waiting until AMD releases their binary only driver to the public as LGPL
[19:08] <superm1> \sh, personally i'm more confident in the open driver getting more featureful that the closed driver doesn't need to be used as much
[19:09] <superm1> \sh, there are closed pieces in that driver that go into realms of IP that will keep it from opening up for a very very long time
[19:10] <\sh> superm1: well, if AMD is releasing the internal specs to the oss ati driver devs , cool...but it would really be an advantage when they just free the code
[19:11] <Treenaks> \sh: The chance that the non-free driver has bits licensed from others in it is high
[19:11] <superm1> \sh, if they ever do decide to free the code, it's only going to be portions, and i expect  those portions wouldn't be as useful
[19:11] <superm1> what Treenaks said is what i was alluding to.
[19:12] <Treenaks> that's why the opening of Java is taking/took so long
[19:12] <slangasek> superm1: mythbuntu alternates looking any good? :)
[19:13] <davmor2> slangasek: I draw the line at testing things that aren't on the tracker ;)
[19:14] <\sh> most probably...but someone can dream
[19:14] <tkamppeter> slangasek, I have uploaded foomatic-db as I thought that it fixes an important bug (near 400 manufacturer PPDs did not pass CUPS' sanity test for PPDs, making CUPS potentially not accepting them for print queues). I did not see any problem with the package in alpha 6 as it did not change in size (no PPDs for new models added).
[19:14] <calc> davidm: good evening
[19:14] <slangasek> davmor2: no objections; the community flavors really ought to be self-sustaining in this regard :/
[19:14] <davidm> calc, good evening
[19:14] <superm1> slangasek, well actually now that i've got vbox 2.0.2 uploaded, it will be a lot easier to test (i was wiping platforms away previously and couldn't afford to wipe them as often :))
[19:15] <slangasek> tkamppeter: "I did not see any problem" - the problem is that we're in a freeze, and you're not supposed to be uploading packages during the freeze that aren't fixes for milestone-critical bugs
[19:15] <calc> davidm: we're headed back to clean out the fridge and hopefully have power tomorrow morning
[19:15] <slangasek> tkamppeter: for one thing, having packages uploaded to the archive after images have already been built means we have skew between the archive and the .jigdo files, making it impossible for people to use jigdo to grab images...
[19:15] <tkamppeter> slangasek, sorry.
[19:16] <calc> davidm: they haven't made much progress since noon on tuesday though
[19:16] <slangasek> tkamppeter: no real damage done (I've had to re-roll images anyway), but please keep this in mind for future alphas
[19:16] <slangasek> (you don't get a choice in the matter for beta, we'll have a hard archive freeze ;)
[19:17] <slangasek> fta: <ahem> fontconfig uploads during a milestone freeze? :)
[19:18] <davidm> calc, good luck, I hope you have power.
[19:19] <slangasek> seb128: ah, these are your uploads... it's still Thursday, we're still in freeze...
[19:20] <calc> davidm: my parents have power now so if i don't i'll have to see if the mind us staying with them, heh
[19:20] <calc> in laws are always fun to be around
[19:21] <davidm> :-)
[19:21]  * calc pictures his mom and wife in a fight
[19:28] <calc> wow new 'powershot sx10 is' is nice :)
[19:28] <calc> 10mp 20x optical zoom
[19:49] <tedg> calc: I was really impressed by the 5D Mark II -- I need more hard drive space first though at 21 MP. :)
[19:59] <calc> tedg: the higher end powershot, apparently might not come to the US, will have a CMOS sensor also
[19:59] <calc> tedg: yep large files :)
[20:00] <calc> PowerShot SX1 IS with 1080p video recording and 20x zoom
[20:00] <calc> it appears from pricing it is probably the replacement for the PowerShot S5 IS
[20:04] <seb128> slangasek: hello, hey soft freeze though no? those are not disruptive changes
[20:09] <slangasek> seb128: "please take care that any packages that you upload to main between now and the Alpha 6 release will help us in the goal of a high quality and timely alpha" - uploading packages that don't fix milestone-critical bugs hurts this by invalidating jigdo images
[20:09] <slangasek> (--> "timely", as it interferes with ISO testing...)
[20:10] <seb128> slangasek: does that mean I should be slacking during freeze days? ;-)
[20:10] <slangasek> you could test ISOs instead, then the alpha would be out sooner and you could go back to uploading :-)
[20:10] <seb128> like I had not enough work
[20:11] <seb128> slangasek: the issue is that I don't want to upload changes on friday afternoon before everybody is away for the weekend
[20:12] <seb128> slangasek: so we have freeze between wednesday on friday every 2 weeks basically
[20:12] <seb128> a new GNOME between those
[20:12] <seb128> and I need to get feedback from users to have GNOME bugs fixed in the next version
[20:12] <slangasek> that's correct; and it's also not new
[20:12] <seb128> that's a pretty tight schedule
[20:13] <seb128> right, and I've been abusing the soft freezes this way before too
[20:13] <seb128> but that's either that
[20:13] <seb128> or I wait on monday and next tarballs to upload outdated things
[20:13] <seb128> and don't get bug fixed in the next GNOME updates
[20:14] <slangasek> would it make a difference if we were able to guarantee alphas were out of the way before Friday morning your time?
[20:14] <seb128> yes
[20:14] <slangasek> ok. I'm not sure I can guarantee this using soft freezes, but that's useful to know.
[20:14] <seb128> I uploaded this afternoon because I figured it was late to roll new CDs
[20:14] <slangasek> /this/ one is on track, though
[20:14] <seb128> and that would not disturbe anything
[20:15] <seb128> I spent yesterday doing hardy srus uploads
[20:15] <seb128> and did bug triage this morning
[20:15] <slangasek> yeah, unfortunately not; maybe it's worth pinging #ubuntu-release first in those cases?
[20:15] <seb128> I know the reply, it's always "alpha is not available yet so there is still a possibility we need to roll new images"
[20:16] <slangasek> then I think we need to consider going back to hard freezes.
[20:17] <slangasek> (of course, we will for beta anyway, but for jaunty alphas as well.)
[20:17] <seb128> what is the point exactly?
[20:17] <slangasek> the point of which?
[20:17] <seb128> did any of my uploads created a practical issue?
[20:18] <seb128> impose hard freeze when the soft ones are usually working
[20:18]  * calc hopes he will be able to get his visa for china
[20:18] <seb128> I'm doing that for years now and it has not been an issue until now
[20:18] <calc> most of houston is still listed as 70%+ without power
[20:18] <slangasek> seb128: they invalidated all the jigdo images; that affects testing for alternate ISOs, since it impacts download time for our testers
[20:18]  * calc has heard reports of power not being restored until sometime in october
[20:19] <seb128> slangasek: do we need that level or testing for alphas?
[20:19] <slangasek> maybe our current testers have stopped relying on jigdo working, though, I don't know :/
[20:19] <slangasek> seb128: we need to have a set of usable ISOs, or else why call it an alpha?
[20:19] <seb128> if you don't manage to get alpha available on time maybe we should consider having an extra week between those
[20:20] <seb128> well, 3 days freeze every 2 weeks is getting in the way of getting work done that's my issue
[20:20] <slangasek> well, my point is that ignoring the freeze is a factor in the freezes stretching out to 3 days, when they're supposed to only be 2...
[20:21] <slangasek> (not the only factor, for sure)
[20:21] <seb128> I doubt my upload from today created any issue, I've be cautious and didn't upload the new gtk for example
[20:22] <seb128> as said point me to one case where I did upload which delayed an alpha and I'll be happy to consider those and how to do better
[20:23] <seb128> it's just that if alpha are supposed to be available on thursday uploading on thursday afternoon should be alright since that's not the time to start a new image rolling and testing round
[20:23] <slangasek> well, if that's your position, then the end result may well be that we're going to have to rule out the possibility of jigdo being usable at all for testing, and adjust the testing window to compensate
[20:24] <seb128> I would like to know if jigdo is used at all, I had the impression people were rsyncing iso usually
[20:24] <cjwatson> (I use jigdo for testing, at least, and it's important to me)
[20:25] <cjwatson> for non-desktop images, jigdo is a lot faster for me since I keep a local mirror, and it also allows me to share downloaded bits around between images
[20:25] <slangasek> this cycle I haven't been, because my mirror setup needs a bigger disk; but I have before and intended to again for jaunty
[20:25] <cjwatson> as in, a large chunk of the data downloaded for alternate also applies to server, and since I don't have a very fast connection it helps me a lot to be able to share this
[20:25] <cjwatson> I know it gets used by people other than developers since I get bug reports when it breaks
[20:25] <seb128> slangasek: I really don't want to upload a ton on upload we queued for 3 days on friday afternoon, that's a receipe for weekend breakages
[20:26] <cjwatson> jigdo also recovers better from network interruptions, IME
[20:26] <seb128> and I would like to avoid blocking upload between wednesday and next monday
[20:26] <cjwatson> perhaps the answer is to move milestones to Wednesdays
[20:27] <cjwatson> or some other day of the week
[20:27] <seb128> if we do that we need to make sure they are not on same weeks that new GNOME versions
[20:27] <cjwatson> I think the beta, RC, and final work best on Thursday, but that doesn't have to match the milestones
[20:27] <cjwatson> when does new GNOME arrive, Wednesday?
[20:27] <slangasek> seb128: which we can't do if GNOME is every 2 weeks, and Ubuntu alphas are alternating 2/3 weeks
[20:27] <seb128> but having milestones and new GNOME on alternates weeks and doing those on wednesday looks good to me
[20:28] <cjwatson> we could do milestones on Fridays if you could get the new GNOME uploaded before Steve wakes up on Wednesday
[20:28] <seb128> slangasek: the GNOME schedule is available early we can probably adjust to not conflict
[20:28] <seb128> doing GNOME uploads before wednesday is fine, that's what we do usually
[20:29] <slangasek> seb128: I'm saying that I don't think it's possible to space them to guarantee there are no collisions with GNOME, without doing some really funny padding of the Ubuntu schedule compared to what we have today
[20:29] <cjwatson> the only trouble with milestones on Fridays is that if they run late then we're in trouble
[20:29] <slangasek> (i.e., either larger gaps around beta time, or starting the alphas much later)
[20:29] <cjwatson> Ubuntu alphas every two weeks have proven to be difficult
[20:30] <cjwatson> I don't think we could sustain that reliably
[20:30] <slangasek> that too
[20:30] <cjwatson> the alternative could be to start earlier (if possible) and do them every four weeks, but that's quite a big gap
[20:30] <seb128> can we setup a pocket for uploads which are done during freezes and that users who want to could use?
[20:30] <cjwatson> PPAs
[20:30] <seb128> one that everybody would use
[20:30] <cjwatson> we could have an ubuntu-dev PPA
[20:30] <seb128> would work for me
[20:31] <slangasek> moving milestones to Wednesday seems ok; the only thing I think would need to change is the release team meeting because that doesn't leave enough time to act on anything, and that was hard to schedule to begin with
[20:31] <cjwatson> it will help once they're signed; that's targeted for the next LP release at the moment
[20:31] <seb128> I just don't like to queue uploads for 3 days to unlash everything on friday afternoon
[20:31] <seb128> by time everything is built and available it's evening european time and nobody is around
[20:32] <seb128> and that also means apt-get doesn't give us current version during freeze and we have work duplications and upload conflicts (not that often but sometimes though)
[20:32] <cjwatson> I'm surprised the idea of an ubuntu-dev PPA (or maybe just ubuntu-core-dev, universe/multiverse isn't so important for freezes) hasn't come up before, actually; I don't remember it doing so
[20:33] <cjwatson> I'll mail ubuntu-devel and see what people think
[20:33] <slangasek> seb128: fwiw, I'm making every effort to get the alpha out yet today so it doesn't bleed over into Friday in this case; but I'm quite aware that I can't promise that in general, particularly for the earlier milestones
[20:33] <seb128> slangasek: right I'm aware about that too and that's why I take the liberty to upload non disruptive change because usually they are not an issue
[20:34]  * slangasek nods
[20:34] <slangasek> in this case, it's specifically /because/ I'm trying to wrap things up on time that I'm making more noise about it than in the past
[20:35] <seb128> slangasek: well, if I was sure I could upload on friday morning I would wait, so maybe you can better communicate on that ;-)
[20:35]  * slangasek nods
[20:36] <slangasek> and maybe there should be varying gradations of freeze between the earlier and later milestones... <ponder>
[20:37] <mathiaz> slangasek: have you already rebuild the -server isos ?
[20:37] <mathiaz> slangasek: bug 271854 will be an issue
[20:37] <slangasek> mathiaz: no - was just about to ping you to confirm you're still available to work on them
[20:37] <slangasek> mathiaz: update-motd is promoted now
[20:37] <slangasek> (i.e., visible in the archive)
[20:38] <slangasek> 271854> that will be an issue if we /do/ reroll?
[20:38] <mathiaz> slangasek: yes
[20:38] <mathiaz> slangasek: so either I can fix it.
[20:38] <mathiaz> slangasek: or we don't reroll.
[20:38] <cjwatson> seems like you should definitely fix it, and then either we reroll or we don't
[20:38] <mathiaz> slangasek: I'll still be around for a couple of hours.
[20:38] <slangasek> mathiaz: ok; do you want to work on resolving that bug then, and ping me again when it's done and we'll evaluate whether it's worth trying to reroll at that point?
[20:39] <mathiaz> slangasek: wfm.
[20:39] <cjwatson> fixing it in the archive shouldn't hurt anything at this point, relative to the current broken state
[20:39] <slangasek> yep
[20:40] <seb128> slangasek: alright for now I'll wait friday morning european time to upload during freezes, if that's not good enough we need to figure what to do when freeze are stretching ;-)
[20:40] <slangasek> seb128: that sounds good from my side, thanks
[20:40] <calc> if the freeze is having trouble maybe make it a hard freeze at that point?
[20:41] <calc> so people can upload and get it in the queue
[20:41] <calc> or implement day queues like debian has (or had?)
[20:41] <cjwatson> the problem about a hard freeze is that there's no notification to developers when two people upload the same version of the same package
[20:41] <cjwatson> we've had difficulty with that in the past
[20:41] <calc> cjwatson: oh yea thats true
[20:42] <cjwatson> also doesn't really help seb128's other problem, which is getting feedback on what he's uploaded, more than just getting it off his disk
[20:42] <slangasek> it's also not very satisfactory if the reason for getting the upload done is to get it tested by users so bugs can be fixed before the weekend :)
[20:42] <cjwatson> I mailed ubuntu-devel@ about the ubuntu-core-dev PPA idea, we can discuss it there
[20:42] <seb128> there is also the "don't accept tons of updates on friday afternoon when everybody is running away for the weekend" issue
[20:43] <cjwatson> right, and all the build failures landing at once ...
[20:45] <mathiaz> kirkland: re bug 271854 - the call to invoke-rc.d can just be dropped ?
[20:46]  * kirkland looks
[20:46] <mathiaz> kirkland: there is nothing else to be done to integrate landscape-client with update-motd ?
[20:46] <kirkland> mathiaz: right, that should definitely be dropped
[20:47] <kirkland> mathiaz: right, landscape just needs update-motd to be there
[20:47] <mathiaz> kirkland: so only the ln -sf are needed in the postinst.
[20:47] <kirkland> mathiaz: right
[20:48] <kirkland> mathiaz: cjwatson was advising me against debconf'ing everything yesterday
[20:48] <mathiaz> kirkland: right - I've read the bug
[20:48] <kirkland> mathiaz: cjwatson: i did add debconf support to landscape to allow an admin to change between update-motd and /etc/profile.d handling of publishing sysinfo
[20:49] <kirkland> cjwatson: that, too, was done as I was learning debconf and thought i should debconf everything
[21:22] <superm1> slangasek, i did an install with the mythbuntu alt, and there was a bug caused by an extraneous recommends
[21:23] <superm1> slangasek, i uploaded mythbuntu-default-settings-0.71-0ubuntu2 to resolve it
[21:26] <slangasek> superm1|away: shall I reroll the images?
[21:27] <slangasek> ah, needs the new package published first
[21:33] <Yoghurt^> Does anyone knows when Alpha 6 will be released? :)
[21:35] <cjwatson> Yoghurt^: typically, on the advertised day for an alpha, the people who know are too busy to be interested in giving out exact times to people. :-)
[21:35] <cjwatson> Yoghurt^: subscribe to ubuntu-devel-announce if you want to be notified as quickly as possible
[21:36] <slangasek> Yoghurt^: also, you already asked this question in #ubuntu-testing...
[21:36] <Yoghurt^> Yeah... but i thought that i could get an more precise answer :)
[21:37] <Yoghurt^> it's getting late in Denmark, but it came out within an hour i would stay up a little longer :)
[21:37] <Yoghurt^> but thanks cjwatson!
[21:38] <cjwatson> if you want to make it faster, do some (more?) ISO testing ;-)
[21:39] <Yoghurt^> i've already added a few bugs to launchpad :)
[21:40] <qah> Hello. Is anyone here?
[21:42] <Yoghurt^> I can be "anyone" :P
[22:00] <fta> slangasek, ?
[22:01] <slangasek> fta: I saw your name in the changelog of the latest fontconfig upload; seb128 and I discussed it
[22:01] <slangasek> fta: since seb128 did the uploading, I think you're off the hook regardless ;)
[22:02] <norsetto> james_w: re. bug 271881, should we rebuilt with 0.2.4 or is 0.3.2 (or 0.3.3) going to be uploaded soon?
[22:02] <fta> slangasek, oh, ok. i'm not allowed to push to main anyway so i'm still on the safe side ;)
[22:18] <mathiaz> slangasek: I've uploaded a new version of landscape-client that should fix the update-motd issue and an upgrade issue.
[22:20] <slangasek> mathiaz: ok; I'll watch for it to be published, but I think we're on the line where I lose my support for getting website updates done today if we iterate again
[22:23] <mathiaz> slangasek: ok - it's up to you. It will be in the next daily iso - so I'll be able to test it then.
[22:23] <mathiaz> slangasek: we won't put a note about landscape-client in the release note then.
[22:27] <slangasek> tedg: I think that pam-auth-update belongs in the System->Preferences menu for intrepid, possibly as "Authentication Management"; how would I accomplish that, and where do icons come from? :)
[22:27] <tedg> slangasek: Well, there's a mommy icon and a daddy icon... haven't your parents talked to you about this?
[22:28] <slangasek> how is ikkon formed
[22:28] <tedg> slangasek: I'd talk to kwwii about the icon.
[22:28] <slangasek> ok
[22:28] <slangasek> what about the "right" way to get it added to the menu?  Do I just need to peek at an existing .desktop file for one of the other entries there?
[22:29] <tedg> slangasek: Yeah, I'd steal one and change it.
[22:29]  * slangasek nods
[22:29] <tedg> I'm not sure how translations work there though.  You need to make sure to add it to your package's po files, but I doubt that PAM is using intltool, eh?
[22:30] <slangasek> heh, indeed not
[22:30] <slangasek> (oh, I guess I mean System->Administration, of course)
[22:31] <tedg> Uhm, I'm not sure the best way to pull out the strings there.  Adding in intltool would be a pain, and probably overkill.
[22:32] <persia> slangasek: When you create your .desktop file, please run desktop-file-validate against it as a check.
[22:32] <slangasek> persia: certainly will, thanks
[22:32] <persia> Translations are currently handled by brute-force inclusion of the translated strings in the .desktop files themselves.
[22:32] <slangasek> tedg: I'm sure I can figure something out on that side :-)
[22:33] <persia> Many upstreams will generate these from a foo.desktop.in file at build time, based on the contents of po/, but that's probably overkill if you're looking at inclusion from debian/
[22:33] <tedg> persia: Yeah, but I was more concerned about the pulling out into the po files.  Most GNOME packages are using intltool.
[22:34] <persia> tedg: Sure, but that's not actually a requirement.  There's only three translatable strings (Name, GenericName, and Comment).  For bunches of packages, these are just translated in the .desktop file, rather than invoking the overhead of intltool
[22:35] <slangasek> this seems to be going a bit meta? we're not going to have lots of translations make their way into the pam package itself between now and release, AFAICS
[22:36] <slangasek> mathiaz: btw: "It should also be noted that Samba 3.2 is licensed under the GPLv3." - I think I disagree? :)
[22:36] <tedg> slangasek: No, actually we expect you to translate it into all the languages Ubuntu supports.  We're just trying to help ;)
[22:36] <slangasek> tedg: my contract only requires me to provide 14% language coverage
[22:36] <mathiaz> slangasek: ?
[22:37] <tedg> persia: Yeah, probably.  If all you're used to using is a hammer...
[22:37] <slangasek> mathiaz: the samba blurb in the technical overview; I don't agree that this should be noted :)
[22:37] <persia> Not infrequently when someone generates an Ubuntu-local desktop file in universe, there will be a call for translated strings in #ubuntu-motu from a pastebin, and people will supply their local translations.  Tends to hit the top 5-10 languages.
[22:37] <mathiaz> slangasek: ah ok. I though you said that samba 3.2 was *not* under GPLv3
[22:37] <slangasek> no, not that :-)
[22:38] <tedg> persia: Really?  That's cool.
[22:38] <mathiaz> slangasek: the reason I mentionned it was because of libsmbclient that can be linked to other libraries under GPLv2 (cf kde)
[22:38] <slangasek> "Authentication Management" - pff, that better get at least 20 :-)
[22:38] <persia> tedg: Yep.  We started it about a year ago, as some people complained about Ubuntu-local desktop files because they weren't translated.
[22:39] <mathiaz> slangasek: I noted it as it could be useful to developers. I agree that it's less important for end users.
[22:39] <slangasek> mathiaz: I understand; I just don't think this is a key issue to be highlighting here
[22:39]  * mathiaz nods
[22:40] <slangasek> also, I think you meant ™ or ®, not © :)
[22:40] <Riddell> kdelibs is GLP 3 happy now incidentally
[22:41] <slangasek> Riddell: yep, we didn't push to samba 3.2 in Debian until that was resolved
[22:48] <ceekay> sorry i know this is a newbie developer question- there is a new version of a package upstream (makedumpfile) that i created a package for because i need it right away. seems like the nice thing to do would be to contribute that packaging to ubuntu for potential use... what is the best channel for doing do? contact the package maintainer?
[22:49] <Nafallo> #ubuntu-motu
[22:49] <persia> slangasek: some number of hours ago you asked about Ubuntu Studio testing.  All cases for the 32-bit disks have been covered.  There's apparently not hardware available to those testing to reach proper coverage of the 64-bit cases (unless you want to wait several more hours).  There have been a couple statements that there would be time to test 64-bit on the weekend, but I'm not sure that helps you.
[22:50] <ceekay> Nafallo: even though it's in main?
[22:51] <slangasek> persia: well, it's more about helping you than about helping me; if UbuntuStudio doesn't get tested, it doesn't get included in the alpha pulse
[22:51] <persia> ceekay: Despite the names, #ubuntu-motu has become the channel where developer support is offered (support with developing for Ubuntu), and #ubuntu-devel is discussion about development activity in Ubuntu (sometimes including Universe)
[22:51] <slangasek> persia: which is on-time for this round, so the pulse is happening shortly
[22:52] <ceekay> perfect, thanks persia ... sorry to be in the wrong channel
[22:52] <slangasek> persia: I could include the tested i386 image without including the amd64 image, if you think that reflects the real needs of the userbase?
[22:53] <persia> slangasek: The vast majority of users are 32-bit (anecdotally about a 10-to-1 ratio), and nearly all those who commit to testing.
[22:54] <davmor2> Jo no
[22:54] <persia> Having a 32-bit "Alpha" would certainly be rewarding even if the 64-bit wasn't present, and might help engage more people to hit the beta testing window.
[22:54] <davmor2> slangasek: I can run a test on it
[22:55] <slangasek> persia: so are you authorizing me, on behalf of the US developers, to do that?
[22:55] <slangasek> davmor2: yes, but I'm not going to block the alpha waiting for those tests
[22:56] <persia> slangasek: I'll go try to get an official statement of some sort, as I'm not sure I can do that.  On the other hand, given the timing, I'm not expecting 64-bit coverage.
[22:56] <davmor2> slangasek: well someone has done a couple of test on xub alt so I can do a couple on that instead :)
[23:21] <slangasek> persia: any ETA on that official statement?  I'm just about ready to pull triggers, here
[23:22] <persia> slangasek: Real Soon Now (minutes)
[23:26] <persia> slangasek: Please do include Ubuntu Studio in the pulse.  While the 64-bit is expected to work, without test coverage, it is understandable if you can't include that.
[23:27] <persia> (and yes, this is now an official authorisation)
[23:27] <slangasek> ok
[23:27] <slangasek> pushing 32-bit, and deferring 64-bit until test results are in
[23:27] <persia> Thanks.  I'll see if someone can't organise more agressive testing during the beta-freeze window.
[23:33] <davmor2> 64bit is about 60% complete on whole disk  and 50% on auto resize
[23:33] <davmor2> slangasek: persia: ^
[23:34] <slangasek> how long does the last 40% take to do? :)
[23:34] <ldp> I need a video converter
[23:34] <davmor2> not too long I hope :)
[23:35] <ldp> HELP
[23:35] <persia> davmor2: Great news indeed.  I'm personally extremely confident that the install works, as it's the same kernel, and nearly the same desktop as Ubuntu Desktop, but less so that the standard Studio applications are all working under 64-bit today.
[23:35] <slangasek> davmor2: well, can you be more specific?  I need to know whether I should wait for it before pushing, or to push in two rounds
[23:35] <slangasek> ldp: this isn't a help channel; try #ubuntu, perhaps?
[23:35] <ldp> k
[23:35] <ldp> I know
[23:36] <ldp> I did /amsg :)
[23:36] <davmor2> 83% of app install 84%
[23:36] <davmor2> so about 10 minutes maybe
[23:36] <slangasek> ok
[23:37] <persia> davmor2: That's for the full suite, or just the desktop?
[23:37] <davmor2> persia: full
[23:37]  * persia is envious of davmor2's machines: the Studio install usually takes a *long* time, and most users only select one of the application clusters in part for this reason
[23:37] <davmor2> the other is just coming up 60% app install
[23:38] <davmor2> persia: how many test on vm though ?
[23:38] <davmor2> setting system clock cd ejected
[23:39] <davmor2> booting
[23:39] <davmor2> sweet I like the usplash :)
[23:39] <persia> davmor2: about half the testers were testing in VMs for 32-bit, but nobody uses VMs for actual installs because it either introduces complexity with input devices (graphics), adds latency (audio), or has slightly slower disk throughput (video)
[23:40] <davmor2> first one is up and running
[23:42] <davmor2> second machine is at 70% now
[23:43] <davmor2> persia: why 2 cd burners?
[23:43] <persia> davmor2: Which do you mean?
[23:44] <davmor2> brasero and gnome cd master
[23:44] <persia> Oh, because gcdmaster can't handle data CDs, and brasero doesn't have the mastering wizards for audio CDs.
[23:45] <persia> (or at least that is what I was told when I suggested removing gcdmaster to try to reduce image size)
[23:47] <davmor2> persia: sorry don't you just add the audio to the cd ?  Or am I missing some major point?  Brasero has a importer not great but it is functional :-?
[23:48] <davmor2> slangasek: that 2
[23:48] <slangasek> "that 2"?
[23:49] <davmor2> that's 2
[23:49] <slangasek> ok
[23:49] <sbeattie> slangasek: were you going to release the 20080918 builds of xubuntu/
[23:50] <sbeattie> or stick with 20080917.1?
[23:50] <persia> davmor2: I'm not someone who has ever mastered a CD, but from what I understand, you first want to use something like jamin to get your multitrack into 44.1kHz stereo 16-bit WAV, and then use GCD Master to import your WAVs, set your track markers and track information, and perhaps add "bonus" tracks (less aggressively mastered) before burning.
[23:50] <slangasek> sbeattie: they were rolled in case there was enough time to cover them for testing; there wasn't, so moving on
[23:50] <sbeattie> slangasek: okay. the i386 from 18 worked fine for me for a manual install
[23:50] <davmor2> persia: right so the mastering is better then :)
[23:51] <davmor2> Right bed
[23:51] <sbeattie> davmor2: thanks much!
[23:51] <persia> davmor2: I think it's also the adding of the extra non-audio data, as brasero is designed to be simple, but I'm not really sure.
[23:51] <persia> Sleep well.
[23:51]  * slangasek waves
[23:53] <maco> where is DistUtilsExtra.command?  I'm trying to test a change to update-manager, but just realized I can't run the setup.py to test it because it can't import that python module
[23:55] <TheMuso> persia: That sounds about right. While I have never used gcdmaster myself, I am well aware of how powerful it can be.
[23:55] <cjwatson> $ dlocate DistUtilsExtra/command
[23:55] <cjwatson> python-distutils-extra: /usr/share/pyshared/DistUtilsExtra/command
[23:57] <cjwatson> maco: ^-


[23:07] <huwshimi> Morning
[23:30] <rick_h_> huwshimi: howdy
[23:30] <huwshimi> rick_h_: Great news over the weekend :)
[23:30] <rick_h_> huwshimi: oh yea?
[23:30] <rick_h_> huwshimi: how goes things?
[23:30] <huwshimi> rick_h_: About YUI
[23:30] <rick_h_> huwshimi: :P
[23:30] <rick_h_> huwshimi: yea, I emailed the thread on it this weekend
[23:31] <huwshimi> rick_h_: It'll be interesting to see what we come up with.
[23:32] <rick_h_> huwshimi: yea, will take some work and we've got some WIP that means we should peek at things. I'd like to see us lead the way here, but that'll come with some costs of velocity
[23:32] <huwshimi> yea
[23:32] <huwshimi> rick_h_: I think we've got the most invested in YUI too
[23:32] <rick_h_> yea, we're definitly not going to be rewriting upteen thousand lines of code tomorrow
[23:32] <huwshimi> :)
[23:32] <huwshimi> That's good
[23:35] <huwshimi> rick_h_: Do you have any initial thoughts about what stacks might be worth looking at?
[23:36] <rick_h_> angular will come up, everyone wants jquery
[23:37] <huwshimi> rick_h_: Do you like it?
[23:38] <rick_h_> I'd like to look at react and what it would take to build some tools around it
[23:38] <rick_h_> but we're in a nice position we can stick with modern browsers and don't need much of jquery/etc
[23:38] <rick_h_> I'm not a fan of jquery or angular
[23:39] <rick_h_> angular has too much magic, makes it hard to debug, and won't scale out well to our needs. Though angualr 2.0 is supposedly coming and will help
[23:42] <rick_h_> bah, uploading pics and streaming a movie makes for lack of bandwidth for even irc to stay working
[23:43] <huwshimi> ouch
[23:44] <huwshimi> rick_h_: I guess one of the hardest parts for us is how to migrate to a new stack without a big rewrite
[23:45] <huwshimi> JS makes it hard to isolate components
[23:45] <rick_h_> huwshimi: yea, basically we'll have to find an adaptor on either the YUI end or the new end