[04:17]  * StevenK sighs. ENOCONTENTS for Hardy
[05:40] <Hobbsee> Fujitsu: have you found a workaround for making totem work?
[05:40] <Hobbsee> for video?
[06:16] <calc> doko: do you remember how you made OOo not ICE on sparc?
[06:49] <calc> i setup photoshop cs2 on my desktop and showed it to my wife... letting her know her system will one day be running ubuntu ;-)
[06:50] <LaserJock> cool
[06:50] <Burgundavia> good luck with that
[06:50] <calc> she hates vista so she will end up converting when she gets a new machine anyway
[06:50] <LaserJock> my wife didn't mind much at all, but she mostly just needs Firefox and a word processor
[06:50] <calc> it will just be a matter of if it will be running xp in a vm or using photoshop via wine
[06:51] <calc> i had converted her, before we got married, back around 4.10 but didn't have a good solution for photoshop for her at the time so she switched back to xp
[06:52] <StevenK> Gimp doesn't count?
[06:52] <calc> gimp doesn't run photoshop filters does it?
[06:52] <calc> or is there a hack to do that?
[06:52] <StevenK> I have no idea, what are photoshop filters? :-)
[06:52] <calc> StevenK: expensive add on programs to do all sorts of things to images
[06:53] <calc> the main reason photoshop has lockin btw
[06:53] <Burgundavia> calc: there was an effort using wine awhile back
[06:53] <Mithrandir> StevenK: gimp lacks some of the neat features of PS, like adjustment layers.
[06:53] <Burgundavia> http://www.gimp.org/~tml/gimp/win32/pspi.html
[06:54] <Mithrandir> and 16 bit mode.
[06:54] <calc> Burgundavia: cool i'll have to look at that
[06:55] <calc> 16 bit mode in photoshop is a bit crap (imho) since most filters don't support it still years later
[06:55] <calc> even adobe's own filters
[06:55] <Mithrandir> calc: so?  Filters are overrated anyway.
[06:57] <Burgundavia> slangasek: I have no time to write the Alpha1 preview this time due to school and it doens;t look like anybody else is stepping up, so you are likely to have to get somebody internal to do it
[06:58] <Hobbsee> wow, kubuntu blew up
[06:59]  * calc bbl bedtime
[07:00] <Hobbsee> Riddell: broke it.
[07:01] <Hobbsee> Mithrandir: can you demote kdegames-kde4 binary, please?
[07:02] <LaserJock> Hobbsee: you know it was you, stop blaming other people ;-)
[07:02] <Hobbsee> LaserJock: ENOPOWER :)
[07:02] <Hobbsee> i didn't accept hte binary.  although, if i had, it would have gone direct to main, iirc.
[07:03] <Hobbsee> i just can't demote things ;)
[07:03] <Hobbsee> oh, awit, it's new stuff that goes direct to main
[07:03] <Mithrandir> Hobbsee: done
[07:04] <Hobbsee> Mithrandir: thanks
[07:04] <StevenK> Mithrandir: Would you mind looking at libgpod in NEW?
[07:04] <StevenK> Mithrandir: I'm happy to do the six or so rebuilds of r-depends. Or shall we leave it until after the release?
[07:05] <slangasek> Burgundavia: righto, I've gotten good at cut'n'pasting from previous pages by this point :-)
[07:05] <Mithrandir> StevenK: after the release sounds like a plan, unless slangasek wants otherwise?
[07:05] <Hobbsee> slangasek: what's your plan with kubuntu cds, and are you intending to make your release discussions at UDS public at all?
[07:05] <slangasek> StevenK: uhm, "freeze"?
[07:05] <Mithrandir> slangasek: it's still a freeze even if it's not enforced as such.
[07:06] <StevenK> slangasek: I'm happy to leave it, I just want something to do tonight.
[07:06] <slangasek> Hobbsee: sorry, I saw your question about that; I was looking for a proper reference at the time I wrote that bit, but unfortunately I can't find that anyone took notes :/
[07:06] <slangasek> StevenK: here, sponsor this :-) https://bugs.launchpad.net/ubuntu/+source/wireless-tools/+bug/172510
[07:06] <ubotu> Launchpad bug 172510 in wireless-tools "please merge wireless-tools 29-1 (main) from Debian unstable (main)" [Undecided,New]
[07:06] <slangasek> Mithrandir: yes, that's what I'm saying... :)
[07:07] <Hobbsee> slangasek: right.  so, um...
[07:07] <slangasek> Hobbsee: I can try to write a brain-dumpy summary for you at some point; and pitti might have some relevant archive pointers
[07:08] <StevenK> slangasek: Yeah, alright. And the reason I didn't upload ubuntu-meta was because there were no seed changes when I ran update
[07:08] <Hobbsee> slangasek: that would be good, thanks.  else i need to seriously consider stepping down from the team.
[07:08] <slangasek> StevenK: hrm? there definitely were seed differences relative to what was in the archive
[07:09] <StevenK> slangasek: Not according to when I ran ./update
[07:09] <Hobbsee> StevenK: stupid question...but was that gutsy's ubuntu-meta, or hardy's ubuntu-meta?
[07:09] <StevenK> Which do you think? :-)
[07:10] <slangasek> Hobbsee: well, there shouldn't be need for an "else" here; if I don't get to it by next Tuesday (allowing for lack of brain availability over the alpha), just kick me harder
[07:10] <StevenK> Obviously, it was warty's.
[07:10] <Hobbsee> slangasek: will do.  with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™ ?
[07:12] <slangasek> Hobbsee: I would note fwiw that "how should we handle milestones" was the main topic for which the session was called, so apart from the crummy way in which you learned of it and the lack of easily accessible rationale, you do at least have the main conclusion... :)
[07:12] <Hobbsee> slangasek: the "else" was only in the case of "if i don't know waht's going on, w.r.t process changes, etc, then it's impossible for me to usefully help out
[07:13] <slangasek> Hobbsee: sticks are fine, though I'm not sure kicking with sticks is very kind to the sticks
[07:13] <Hobbsee> slangasek: right - i'm aware that it's changed, but not to.
[07:13] <Hobbsee> er, but not what to.
[07:13] <Burgundavia> slangasek: that is exactly what I was going to do anyway :)
[07:13] <Hobbsee> i didn't have my psychic cereal this morning.
[07:15] <slangasek> wikipedios, part of this balanced psychic breakfast
[07:28] <dholbach> good morning
[07:28]  * slangasek moos
[07:29]  * Hobbsee squeaks
[07:29] <LaserJock> dholbach!
[07:29] <dholbach> hey guys :)
[07:50] <StevenK> slangasek: Did you see the dpkg-source warnings for wireless-tools?
[07:52] <slangasek> I believe I may have missed them.  Is this during package generation?
[07:53] <StevenK> slangasek: Yup
[07:53] <StevenK> dpkg-source: warning: newly created empty file 'debian/ifrename.docs' will not be represented in diff
[07:54] <StevenK> And ifrename.{install,postrm,init}
[07:55] <pitti> Good morning
[07:55] <Hobbsee> morning pitti!
[07:56] <StevenK> Morning pitti
[07:56] <slangasek> StevenK: oh. that would be because you're applying a diff on top of the Debian source package and diff doesn't delete empty files for you :)
[07:56] <slangasek> StevenK: so the fact that they won't be represented is just fine, 'cuz they're supposed to go away
[07:57] <StevenK> Great
[07:58] <StevenK> slangasek: Uploaded. Hopefully, just in time for the publisher.
[08:28] <doko> calc: the previous failures were segfaults in the compiler. this failure doesn't look like the previous ones.
[08:40] <slangasek> StevenK: thanks
[08:50] <needhelp> Hi! I need your help. Iam collecting points in page listed below. If you be so kind, please click url below.(sorry for the spam, thank you) http://www.3dwhite.lt/?click=56a3cdcf22ccc7ab5f0a7f4d2bc900ff
[08:58] <seb128> TheMuso: could you attach a debdiff for the merge rather than a weird interdiff to the gnome-orca bug?
[09:00] <TheMuso> seb128: Ok, the only problem with that is the changes in the upstream tarball...
[09:01] <seb128> TheMuso: what do you mean? I don't understand what your interdiff is actually, you didn't describe what version you used, etc
[09:02] <seb128> TheMuso: do you need to change the upstream tarball?
[09:02] <TheMuso> seb128: Sorry, I thought the using of interdiffs for new upstream versions was being used with packages in main as well...
[09:02] <TheMuso> seb128: There is a newer upstream for gnome 2.21 available, so I thought I should use that.
[09:02] <seb128> TheMuso: no, we use a dsc and diff.gz usually and download the upstream tarball
[09:03] <dholbach> http://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[09:04] <seb128> dholbach: I know what interdiff is, I just don't know what version he used, etc
[09:04] <seb128> dholbach: you have to apply the diff to something
[09:04] <cjwatson> sladen: no, not console-setup - look in usplash's own source, and in the kernel source for the ioctl it's calling
[09:04] <cjwatson> (it's doing ioctl(KDFONTOP) and failing for some reason)
[09:04] <dholbach> this page does not explain what interdiff is, but how it can be used in the context of sponsoring
[09:05] <somerville32> Does anyone know when the next lifefs run is?
[09:05] <cjwatson> Hobbsee: dunno if you noticed, but apparently the +queue mail-sending bug is fixed
[09:05] <Hobbsee> cjwatson: i did, thanks :)
[09:05] <seb128> dholbach: still need to get an upstream tarball and you need to know what version and from where (debian or upstream)
[09:05] <seb128> dholbach: no?
[09:05] <dholbach> seb128: right
[09:05] <seb128> dholbach: or I'm being not awake or something
[09:05] <TheMuso> seb128: Ok if you prefer, I'll attach a .diff.gz and .dsc.
[09:06] <dholbach> seb128: what does the version in the changelog say?
[09:06] <Fujitsu> Hobbsee: No idea. I don't play video.
[09:06] <Hobbsee> Fujitsu: pity.  wonder if tjaalton knows.
[09:06] <dholbach> looks like the new upstream version, no?
[09:06] <Fujitsu> Hobbsee: Hm, wait a sec, I'll find the option.
[09:07] <seb128> dholbach: 2.20.1, Ubuntu has 2.20.0 though and new upstream version is 2.21.2
[09:07] <dholbach> seb128: hm, it says 2.21.2-0ubuntu1 in the bug report
[09:07] <seb128> dholbach: so I'm not sure from where the 2.20.1 is coming, it's neither what is in Ubuntu nor the new version
[09:08] <dholbach> what happens if you apply it to the new upstream source?
[09:08] <Fujitsu> Hobbsee: I can't find the video output options, but they're around somewhere
[09:08] <seb128> dholbach: right that's the new version, I'm trying to figure what it interdiffing
[09:08] <Hobbsee> Fujitsu: right
[09:09] <TheMuso> seb128: The latest gnome-orca package in debian, 2.20.1-2
[09:09] <seb128> TheMuso: so you interdiffed the Debian version and your update?
[09:10] <TheMuso> seb128: Yes, sorry I should have made that clearer in the report.
[09:10] <Fujitsu> It looks like a new upstream version combined with a merge, so that makes sense.
[09:10] <seb128> interdiffs are the suck to read, I'm wondering why you guys don't just attach a dsc and a diff.gz
[09:10] <Fujitsu> How is an interdiff worse to read than anything else?
[09:11] <somerville32> seb128, with a -p1, it is very nice to read :)
[09:11] <seb128> Fujitsu: a merge with Debian should list the changes between debian and ubuntu, not a zillion weird changes
[09:11] <MacSlow> Greetings everybody!
[09:12] <seb128> somerville32: I'm using emacs to read it, what do you mean?
[09:12] <seb128> hey MacSlow
[09:12] <somerville32> seb128, With new upstream releases, you only see the delta of the delta
[09:12] <somerville32> seb128, For package updates, an interdiff of the two package diffs is the same as a debdiff
[09:13] <seb128> somerville32: I don't want to see the delta of the delta, I want to read the changes to the debian directory over the Debian version
[09:13] <cjwatson> seb128: that's what interdiff gives you, unless you encounter a case that interdiff finds hard to handle
[09:13] <cjwatson> (which does crop up from time to time, and may be what you've run into)
[09:13] <cjwatson> interdiff is used internally by debdiff
[09:14] <seb128> cjwatson: this interdiff has debian/compat removed and added again later with the same 5 value
[09:14] <seb128> which is weird
[09:14] <cjwatson> that would be a bug; that's not normal
[09:14] <somerville32> cjwatson, The person who made the patch didn't use -p1
[09:14] <Fujitsu> TheMuso: Did you build the diff with -p1?
[09:14] <cjwatson> somerville32: perhaps a bug in the person who invoked interdiff, yes :)

[09:15] <TheMuso> Fujitsu: I followed the procedure on the wiki
[09:15] <somerville32> Well, you can't use the -p1 patch to reconstruct it
[09:15] <somerville32> The -p1 is for viewing only
[09:15] <dholbach> sebhttps://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002767.html
[09:15] <seb128> bug #172515
[09:15] <ubotu> Launchpad bug 172515 in gnome-orca "Please merge gnome-orca 2.21.2-0ubuntu1 from Debian unstable." [Undecided,New] https://launchpad.net/bugs/172515
[09:15] <dholbach> oops... https://lists.ubuntu.com/archives/ubuntu-motu/2007-November/002767.html
[09:15] <seb128> the interdiff is attached there
[09:15] <MacSlow> Salut seb128, dholbach, cjwatson, mvo, keescook
[09:15] <dholbach> salut MacSlow, mon ami
[09:15] <mvo> hey MacSlow
[09:15] <cjwatson> seb128: if you forget to pass the -p1 option to interdiff, then it considers changes in the base directory name to be significant, which means it's removing foo-1.0/debian/compat and adding foo-1.1/debian/compat
[09:15] <Fujitsu> somerville32: Oh, woops, you're right.
[09:15] <cjwatson> s/you/somebody/
[09:16] <seb128> cjwatson: ok, that's what it looks like there
[09:17] <cjwatson> somerville32: why can't you use -p1 to reconstruct it?
[09:17] <cjwatson> sure, you might have to rename a directory at the end
[09:18] <somerville32> mm
[09:18] <cjwatson> if some bug means that you can't use -p1 to reconstruct, I agree with seb128, instead of advising people to attach an interdiff without -p1, you should advise them to attach the interdiff -p1 for easy viewing plus the new .diff.gz
[09:19] <somerville32> I thought you could do it with the -p1 but Persia asked me earlier to reattach one without it to reconstruct
[09:19] <cjwatson> perhaps it was some special case
[09:20] <somerville32> So, Does anyone know when the next lifefs run is?
[09:21] <cjwatson> somerville32: for which flavour?
[09:21] <somerville32> Xubuntu
[09:21] <cjwatson> 9:55 London time
[09:22] <cjwatson> well, no, it'll start a bit after that
[09:22] <cjwatson> but that's when the cron job fires that includes a livefs build in the middle
[09:23] <somerville32> ok, thanks
[09:23] <somerville32> Is there some sort of method of notification for failures?
[09:23] <seb128> TheMuso: ok, I managed to use your interdiff, reviewing it now
[09:25] <cjwatson> somerville32: no, sorry
[09:25] <cjwatson> we may get something like that as part of developer-weather-report, I hope
[09:25]  * somerville32 thinks of whipping something up.
[09:25] <somerville32> ok
[09:25] <somerville32> Sounds hot.
[09:25]  * somerville32 chuckles.
[09:26] <seb128> TheMuso: are those debian/copyright formatting changes required?
[09:27] <TheMuso> seb128: I wasn't really aware of formatting changes, due to the way I reviewed the diff, i.e I didn't review it visually. But no they wouldn't be.
[09:28] <seb128> TheMuso: could you change that? diff the debian directories for the versions maybe
[09:28] <TheMuso> seb128: Ok.
[09:28] <seb128> thanks
[09:37] <TheMuso> seb128: Shall a .diff.gz attached to the bug be sufficient?
[09:38] <persia> cjwatson: coming late to the party, but the reason that one can't always apply an interdiff -p1 to construct the new .diff.gz is that combinediff gets confused if hunks overlap, so the change in the directory name forces correct behaviour.  I agree that interdiff without -p1 is not human readable.
[09:42] <cjwatson> persia: why wouldn't you just use unpack, patch, repack to reconstruct, rather than combinediff?
[09:43] <cjwatson> makes it simpler to use dpkg-buildpackage that way
[09:44] <seb128_> TheMuso: at-spi, any reason for reverting the debian description changes there?
[09:44] <seb128_> TheMuso: looks like you copied the ubuntu control rather than using the required changes on the debian one
[09:45] <persia> cjwatson: The idea was to prepare a simple command line that would produce a file that a sponsor could use to get everything necessary, and support the case where diff -nuR debian/ wasn't sufficient (raw patches in diff.gz) for new upstream versions.  I'm not sure how to easily generate a patch to be applied to old source that does the same without mixing upstream changes.
[09:45] <seb128_> TheMuso: otherwise looks correct
[09:46] <persia> cjwatson: The other bit is that one actually wants to unpack twice: once to get the watch file / get-orig-source rule to grab upstream, and a second time to create a candidate from the constructed orig.tar.gz
[09:47] <TheMuso> seb128/c
[09:47] <TheMuso> ugh
[09:48] <cjwatson> persia: it doesn't look like the result is something simple for a sponsor though
[09:48] <TheMuso> seb128_: Ok, I'll revert the descriptions. Is attaching updated .diff.gz and .dsc files to both the orca and at-spi bugs sufficient?
[09:49] <cjwatson> persia: I think it would be a lot better just to ask people to attach .dsc and .diff.gz (and .orig.tar.gz if necessary) plus a human-readable interdiff
[09:49] <seb128_> TheMuso: either the interdiff or those
[09:49] <persia> cjwatson: Agreed.  I have a script that mostly works, but I'm still adding error checking & stuff, which will end up in ubuntu-dev-scripts.  An early draft is at http://people.ubuntuwire.com/~persia/process-interdiff (and I'm expecting to have something sufficiently robust this coming weeked).
[09:49] <TheMuso> seb128_: Ok.
[09:50] <persia> Hmm.  I don't like people attaching orig.tar.gz, as LP doesn't check who people are very well, but maybe just diff.gz & a human-readable interdiff makes sense.
[09:50] <cjwatson> persia: I'm mostly worried about running into unnoticed round-trip errors between interdiff and combinediff
[09:51] <cjwatson> persia: well, instructions to fetch .orig.tar.gz anyway
[09:51] <cjwatson> in most cases it should just be something from a website
[09:51] <seb128_> persia: easy enough to ask the upstream or debian tarball url
[09:52] <persia> cjwatson: Right.  Thinking more about it, diff.gz contains all the interesting bits, and is more familiar.  For orig.tar.gz, I think the instructions belong in a watch file or get-orig-source: rule.
[09:53] <cjwatson> do we caution people that if get-orig-source is used then this *must* be coordinated with any other distros that ship the package?
[09:53] <persia> cjwatson: *must*?  Why?  If we're repacking without it, we get a different orig.tar.gz without explanation.  If we repack with it, we may differ, but at least we can explain why.
[09:54] <cjwatson> persia: *must* because if you don't coordinate and another distro ships the same version but a different .orig.tar.gz then we can't sync
[09:55] <cjwatson> if at all possible all .orig.tar.gz files floating around for the same version should be bit-for-bit identical
[09:55] <cjwatson> if they aren't identical for some known reason, then the versions should also differ
[09:55] <persia> cjwatson: Ah.  Just to be extra-clear: I strongly recommend that if Debian has the upstream version, we use a debdiff against Debian when sponsoring, and I didn't think we had sync working for any other distros.
[09:56] <cjwatson> persia: it sometimes happens that we package the new upstream version before Debian, and in that case it is important that we let the Debian maintainer know that we have an .orig.tar.gz
[09:56] <persia> Should we be naming repacks with x.y.z+ubuntu-0ubuntu1 rather than x.y.z+dfsg-0ubuntu1 to support that?
[09:56] <cjwatson> persia: depends on the reason for the repacking
[09:56] <seb128_> persia: ubuntu > debian
[09:56] <cjwatson> and no, I don't think so; we should instead be sharing the .orig.tar.gz with Debian
[09:56] <seb128_> persia: for the versionning
[09:57] <cjwatson> it is better to actually have the same version
[09:57] <cjwatson> cases where we need different contents are vanishingly rare
[09:57] <seb128_> well, the issue is often when we are faster to do the update than debian
[09:57] <persia> Ah.  So if we repack a new version, we should be notifying Debian that we have a new orig.tar.gz for consideration?  I'd be happy to add that to the various docs on package updating this weekend (if someone else doesn't first).
[09:58] <cjwatson> yeah
[09:58] <cjwatson> or indeed, talking to the Debian maintainer to find out if they're about to do the same
[09:58] <cjwatson> (might be a better attitude than "notify" which can be a bit abrupt)
[09:58] <persia> seb128_: Not always.  At the beginning of a cycle, frequently debian > ubuntu.  At DIF, ubuntu > debian.
[09:59] <seb128_> persia: I was speaking about versions, if you use n-ubuntu you are not able to sync a n-dfsg later because you can't downgrade
[09:59] <TheMuso> seb128_: At-spi bug updated.
[09:59] <seb128_> TheMuso: looking
[10:00] <persia> seb128_: Ah.  Right.  I thought we didn't tend to sync Ubuntu updates anyway, but I suppose if we can institutionalize the practice of feeding orig.tar.gz's back, we will be able to do so.
[10:01] <seb128_> persia: well, in the case when you package the new version before debian and want to use a different naming to be able to sync when they do the update you should use something which has a lower version
[10:01] <TheMuso> seb128_: gnome-orca bug updated.
[10:02] <persia> seb128_: Right.  I'll think about it some more before I update anything, and publish to u-d@ when I'm done.  Thanks for reminding me.
[10:03] <seb128_> persia: you're welcome
[10:04] <pitti> geser: hah, I already wondered why my hevea upload was rejected; you beat me to it by a few minutes :)
[10:08] <pitti> yay apparmor -- it disallows access to creating bluetooth sockets without providing a profile option  to enable it
[10:09] <geser> pitti: builds in MANUALDEPWAIT should get automatically retried if the waiting package is there, shouldn't they?
[10:10] <pitti> geser: right
[10:10] <TheMuso> c
[10:10] <TheMuso> wrong tab..
[10:10] <geser> pitti: have you an idea why https://edge.launchpad.net/ubuntu/hardy/+source/cdebconf-entropy/+builds is in depwait? rmadison lists libdebconfclient0-dev |      0.125 |         hardy | amd64, i386, powerpc
[10:11] <pitti> geser: hm, maybe "MANUAL"depwait is something special
[10:11] <Fujitsu> pitti: There is no non-manualdepwair.
[10:12] <Fujitsu> Er, s/r/t/
[10:12] <pitti> geser: no idea then; I'll try a give-back
[10:17] <seb128_> TheMuso: you didn't revert the at-spi description changes
[10:18] <seb128_> - services, products and information.
[10:18] <seb128_> + services, products, and information.
[10:18] <TheMuso> oh hrm. ok.
[10:19] <seb128_> TheMuso: you also changed the dbg description
[10:19] <seb128_> the new debian one is the correct one to use
[10:19] <TheMuso> ok looking.
[10:19] <geser> is there a date when dpkg gets merged in hardy? As packages using dpkg-shlibdeps --ignore-missing-info FTBFS as dpkg-shlibdeps doesn't know this option yet (introduced in dpkg 1.14.8)
[10:20] <Mithrandir> doko: the ssed build-dependency for norwegian wasn't there for speed, it was there so the package built correctly.
[10:22]  * TheMuso hits himself on the head. I removed the wrong diff hunks. :S *sigh*
[10:23] <doko> Mithrandir: hrm, then mention it?
[10:23] <doko>   * Use ssed instead of sed, since sed has turned into the slowest piece
[10:23] <doko>     of software on earth.
[10:23] <doko>  -- Tollef Fog Heen <tfheen@debian.org>  Fri,  4 Apr 2003 14:15:14 +0200
[10:24] <Mithrandir> doko: hm, I was fairly sure it didn't build correctly, but it seems I was mistaken.
[10:24] <Mithrandir> I suspect you'll get buildd timeouts now, though.
[10:24] <Mithrandir> unless libc has been fixed.
[10:24] <doko> Mithrandir: lets wait. I'll look at the failures, it did build on amd64
[10:24] <seb128_> TheMuso: gnome-orca still has unrequired copyright changes
[10:24] <seb128_> -It was downloaded from: <http://ftp.gnome.org/pub/GNOME/sources/orca/>.
[10:24] <seb128_> +It was downloaded from <http://ftp.gnome.org/pub/GNOME/sources/orca/>
[10:24] <cjwatson> I thought we fixed that libc/sed UTF-8 thing ages ago
[10:25] <geser> doko: I'm looking at gmetadom which you last touched. I don't understand your changelog entry "Fix build failure with g++-4.3." as I only see changed to debian/ files in http://patches.ubuntu.com/g/gmetadom/gmetadom_0.2.5-1ubuntu1.patch
[10:25] <seb128_> TheMuso: copyright list, license text, etc
[10:25] <geser> doko: it is ok to sync it?
[10:25] <Mithrandir> cjwatson: it being slow as molasses?  Maybe.  See the date of the changelog above. :-)
[10:25] <seb128_> TheMuso: you should take the debian version and add the credit line and that's about it, no other change
[10:25] <TheMuso> seb128_: Third times the charm I hope. at-spi bug updated.
[10:25] <doko> geser: If you can build it with gcc-snapshot without modifications, yes
[10:26] <cjwatson> Mithrandir: I remember some kind of quadratic-time UTF-8 regex behaviour bug being RC for a previous Ubuntu release. I think it was sed.
[10:26] <Mithrandir> cjwatson: sounds like something the norwegian build system would run into.
[10:26] <Mithrandir> it's the most massive use of sed, awk and friends I've ever run into.
[10:26] <TheMuso> seb128_: Ok.
[10:27] <geser> doko: simply install gcc-snapshot in a pbuilder and build it there? or are some additional steps necessary to test it?
[10:31] <seb128_> TheMuso: looks correct now, thanks for the work there
[10:31] <TheMuso> seb128_: gnome-orca bug updated.
[10:32] <seb128_> TheMuso: could you send the fix-server-i18n change to upstream and debian?
[10:32] <TheMuso> seb128_: Thanks a lot for being so patient. I'll visually review diffs in the future, and more thorougly. Speech doesn't always give all formatting problems away.
[10:32] <doko> geser: make sure that the binaries in /usr/lib/gcc-snapshot/bin are used
[10:32] <TheMuso> seb128_: Sure, will do.
[10:32] <seb128_> TheMuso: thanks
[10:33] <TheMuso> seb128_: The only thing I'm not entirely sure of, is what that patch for at-spi fixes.
[10:34] <luisbg_> hey TheMuso =)
[10:34] <TheMuso> Hey luisbg_ .
[10:34] <seb128_> TheMuso:
[10:34] <seb128_> "  * Add debian/patches/fix-server-i18n.patch: Mark translatable strings in
[10:34] <seb128_>     registryd/Accessibility_Registry.server.in.in as such, so that intltool
[10:34] <seb128_>     picks them up."
[10:34] <seb128_> that's the corresponding changelog entry
[10:35] <TheMuso> Right, saw that, but didn't make the connection at the time.
[10:45] <seb128_> TheMuso: do you need those gnome-orca credit change? If the debian maintainer didn't use your package there is no real point to add this to the copyright
[10:46] <geser> doko: it FTBFS with gcc-snapshot. So I need to merge your changes, but I can't find the fix in the Ubuntu delta (which changes only some files in debian/)
[10:46] <seb128_> TheMuso: the README.Debian change also doesn't look like something required
[10:47] <seb128_> geser: what package are you looking?
[10:47] <geser> gmetadom
[10:47] <seb128_> geser: looks like there no change there
[10:48] <geser> seb128_: the ubuntu delta should be http://patches.ubuntu.com/g/gmetadom/gmetadom_0.2.5-1ubuntu1.patch
[10:48] <geser> I see there a comment from doko "* Fix build failure with g++-4.3." but not the fix itself
[10:48] <seb128_> right, looks like he forgot to apply the change
[10:48] <doko> geser: then please fix it =)
[10:49] <TheMuso> seb128_: Way back in 2006 the Ubuntu package was used as a base, but I am enclined to agree the credit is no longer needed. Updating again.
[10:49] <seb128_> doko: do you plan to mail the debian lists or something about the python  dbg changes? it's creating a lot of merge work on Ubuntu
[10:49] <seb128_> TheMuso: thanks
[10:50] <doko> seb128_: on my todo ...
[10:50] <seb128_> doko: would be nice to have some sort of debian summary mail that we could note when sending the patch to the bts
[10:50] <doko> seb128_: there's the wiki page
[10:50] <seb128_> doko: could you bump it? so we don't have to merge those again and again, the earlier we send those to debug the better for everybody
[10:51] <seb128_> doko: right, I'm not sure the debian guys will all welcome an ubuntu wiki page to justify changes though
[10:52] <TheMuso> seb128_: Updated orca bug
[10:54] <ogra> sigh ... dhcp3 is such a monster ... we could write our own dhcpd from the patches we have
[11:22] <pitti> cjwatson: if you have a minute, can you please ack my gutsy-proposed debdiff for bug 147800? it's pretty obvious and simple, but peer review and all that..
[11:22] <ubotu> Launchpad bug 147800 in cupsys "[Gutsy] : bluetooth printing was working but is not (at the beginning of september)." [Undecided,Confirmed] https://launchpad.net/bugs/147800
[11:33] <geser> doko: can you look at bug #172546 and tell me if that's the right fix?
[11:33] <ubotu> Launchpad bug 172546 in gmetadom "[Merge] gmetadom 0.2.5-3ubuntu1" [Undecided,New] https://launchpad.net/bugs/172546
[11:33] <geser> doko: http://launchpadlibrarian.net/10620953/3-3ubuntu1.debdiff
[11:33] <doko> geser: looks ok
[11:35] <geser> doko: then I'll forward the patch to Debian
[11:35] <geser> doko: can you sponsor the merge?
[11:41] <pitti> ogra: tuxmath is uninstallable because its dependency ttf-sil-andika is in universe
[11:41] <doko> geser: yes
[11:41] <pitti> ogra: (which in turn caues edubuntu-addon-meta uninstallability)
[11:42] <geser> doko: thanks
[11:42] <ogra> pitti, hrm
[11:44] <ogra> intresting that i didnt have it i the mailed report ...
[11:44] <ogra> (from cdimage)
[11:44] <ogra> but probably it doesnt chek addon
[11:44] <ogra> *check
[11:45] <pitti> Hobbsee, Riddell: kaddressbook uninstallability (from kdeaddons) is caused by the kdepim shlibs wreckage and thus needs a rebuild; is this on your schedule? (maybe upload it now with a proper versioned build dep)
[11:45] <somerville32> btw, is there any updates on getting Xubuntu's images onto the r.u.c?
[11:45] <pitti> Hobbsee, Riddell: kipi-plugins should sort itself out, AFAICS; that should cover Kubuntu uninstallability
[11:51] <Hobbsee> pitti: ?
[11:51] <Hobbsee> sarah@LongPointyStick:~% show kaddressbook | grep Source                10:51PM
[11:51] <Hobbsee> Source: kdepim
[11:51] <pitti> Hobbsee: the kdeaddons packages picked up the >= 3.5.8 shlibs
[11:52] <pitti> Hobbsee: I mean kaddressbook-plugins, sorry
[11:52] <Hobbsee> oh, the plugins
[11:52] <Hobbsee> right, fixing
[11:55] <Riddell> pitti: yes it is, along with kdesdk and kdebluetooth
[11:55] <pitti> kdesdk just fell out of http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html, so that should be good now
[11:56] <pitti> in fact it is starting to look quite manageable now :)
[11:56] <StevenK> pitti: I will probably becoming your friend after alpha 1 about NBS :-)
[11:56]  * pitti hugs StevenK
[11:57]  * StevenK grins and hugs pitti back
[11:57] <Riddell> pitti: it still needs to be built, seems like kdepim is in the archive now so please give back kdesdk and kdebluetooth
[11:58] <pitti> Riddell: done
[12:01] <Hobbsee> tjaalton: ping
[12:05] <geser> pitti: what's the best way to resolve the hplip FTBFS? fix temporarily the package or wait for a newer dpkg? http://launchpadlibrarian.net/10582485/buildlog_ubuntu-hardy-i386.hplip_2.7.10-3_FAILEDTOBUILD.txt.gz
[12:07] <pitti> geser: I saw it, but for now I think it is ok to wait for new package
[12:07] <pitti> Debian should fix the build dependency for dpkg, though
[12:07] <pitti> to avoid broken backports, etc.
[12:08] <geser> Hobbsee: is it safe to request a give-back of kdesdk?
[12:09] <pitti> geser: I just did it
[12:09] <geser> pitti: kdebluetooth too?
[12:09] <pitti> yes
[12:18] <tjaalton> Hobbsee: boing
[12:19] <geser> pitti: Please give-back xemacs21. Thanks
[12:20] <pitti> geser: done
[12:25] <Hobbsee> tjaalton: any idea on how to go about getting totem to work on hardy?
[12:25]  * Hobbsee hopes you know, else she can't watch any video on hardy
[12:25] <tjaalton> Hobbsee: starts but doesn't display anything?
[12:26] <Hobbsee> tjaalton: starts, works for audio, but when i play video, it vanishes, and i get this:
[12:26] <tjaalton> here the playback doesn't seem to start
[12:26] <Hobbsee> The program 'totem' received an X Window System error.
[12:26] <Hobbsee> This probably reflects a bug in the program.
[12:26] <Hobbsee> The error was 'BadAlloc (insufficient resources for operation)'.
[12:26] <Hobbsee>   (Details: serial 71 error_code 11 request_code 140 minor_code 19)
[12:26] <Hobbsee> tjaalton: yeah, exactly
[12:29] <geser> pitti: are NEW packages in Debian contrib auto-synced?
[12:32] <Hobbsee> grrr.
[12:32] <Hobbsee> sorry, i missed everything after what i last said.
[12:32] <cjwatson> 12:26 <Hobbsee> tjaalton: yeah, exactly
[12:32] <cjwatson> 12:29 <geser> pitti: are NEW packages in Debian contrib auto-synced?
[12:32] <cjwatson> 12:30 -!- Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has quit [Read error: 104 (Connection reset by peer)]
[12:32] <cjwatson> 12:30 -!- Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-devel
[12:32] <tjaalton> Hobbsee: it seems to work on i965 at least
[12:32] <tjaalton> but not on my savage
[12:32] <tjaalton> maybe the problem is somewhere else
[12:33] <Hobbsee> cjwatson: thanks
[12:33] <Hobbsee> tjaalton: this is a 945GM.  *shrug*
[12:33] <Hobbsee> tjaalton: it used to work, too
[12:33] <Hobbsee> as in, it'd crash X after a few minutes, but it would actually start playing
[12:34] <Hobbsee> and i suspect it was with the most recent -intel upload
[12:34] <ogra> can some archive admin let through the split out ldm package ?
[12:34] <ogra> pitti, ? ^^
[12:35] <ogra> sits in NEW
[12:35]  * ogra also wonders where his reciept for the ltsp upload is
[12:39] <tjaalton> Hobbsee: I'm afraid I don't have any ideas :/ You can try building the previous driver and test it, if you have the time
[12:41] <Hobbsee> tjaalton: hm.
[12:41] <Hobbsee> tjaalton: wrong answer :)
[12:41] <tjaalton> Hobbsee: obviously :)
[12:43] <Hobbsee> tjaalton: bugger.  cant seem to strace it / use gdb / antyhing debug-related on it, getting any useful output.
[12:44] <tjaalton> Hobbsee: does gstreamer-properties tests work for you?
[12:45] <Hobbsee> tjaalton: ah ha!
[12:46] <Hobbsee> tjaalton: the no XV version of the first video test does, the X11/Xshm/Xv gives the usual error like i was getting from totem
[12:47] <tjaalton> Hobbsee: right, and since you use XAA with compiz, Xv probably shouldn't even work :)
[12:48] <tjaalton> I'm not sure though
[12:48] <Hobbsee> tjaalton: heh.
[12:48] <Hobbsee> ookay, now i'ts stopped crashing on the x/x/x mode, it just produces the "OK" box, and no output apart from that
[12:50] <Hobbsee> tjaalton: erm.  i wonder what hte last changes in totem were.
[12:50] <Hobbsee> tjaalton: iz compiz bug.
[12:50] <tjaalton> Hobbsee: a new version? (2.21.2)
[12:50] <tjaalton> duh
[12:53] <seb128> what?
[12:53] <tjaalton> she quit :)
[12:53] <seb128> totem changes are not likely to break video playing, I would rather look to the gstreamer updates
[12:53] <tjaalton> yep, that was updated recently
[12:54] <geser> pitti: Please give-back futilities. Thanks
[12:54] <seb128> does it work using gst-launch-0.10 playbin uri=file///video
[12:55] <tjaalton> seb128: on my laptop it doesn't
[12:55] <tjaalton> Hobbsee: 14:54 < seb128> does it work using gst-launch-0.10 playbin uri=file///video
[12:55] <Hobbsee> well now, that's interesting.
[12:56] <tjaalton> (add ":" to the uri)
[12:56] <Hobbsee> it appears that randomly fiddling between the options will make it work, rather than letting it use autodetect - which is making it do no XV, i think
[12:57] <Hobbsee> ah, there we go.  now it's crashing again
[12:57] <seb128> crashing = SIGSEGV or rather x11 error?
[12:57] <Hobbsee> seb128: x11 error
[12:58] <Hobbsee> tjaalton: sorry, but where does the colon go?
[12:58] <seb128> pedro_ had issue yesterday using the autosinks
[12:58] <tjaalton> Hobbsee: uri=file:///
[12:58] <seb128> slomo might know about it
[12:58] <slomo> ok, what's broken? :)
[12:58] <Hobbsee> tjaalton: seb128 no, the same, the above error
[12:59] <tjaalton> slomo: video playback :)
[12:59] <slomo> Hobbsee: what kind of video (large resolution maybe?) is this? what's the X error? does switching to x11imagesink in gstreamer-properties fix playback with totem at least?
[12:59] <Hobbsee> slomo: ah, didn't realise you weren't reading above
[12:59] <mvo> Hobbsee: this is not compiz, right?
[12:59] <tjaalton> on my laptop it doesn't even start (the Mandela clip)
[13:00] <tjaalton> and no compiz on the savage
[13:01] <slomo> and this is since latest gstreamer updates in hardy?
[13:01] <Hobbsee> sigh.
[13:01] <Hobbsee> was X bug.  iz now compiz bug.  sorry for the hassle.
[13:01] <slomo> :)
[13:01] <tjaalton> slomo: tbh I haven't tried playback in a while
[13:02] <tjaalton> slomo: but the test video on gstreamer-properties works
[13:02] <Hobbsee> when i last checked it a week or so ago, it happened on metacity too
[13:02] <Mithrandir> Hobbsee: you should find and talk to the crazy american tourist
[13:02] <slomo> ok, so probably no bug anymore except the one pedro_ found
[13:02] <Hobbsee> Mithrandir: yeah.  that'd be fun
[13:02] <Hobbsee> Mithrandir: FIX IT!  NOW!
[13:03] <Mithrandir> Hobbsee: and get him to implement multiplayer while he's at it?
[13:05] <Hobbsee> Mithrandir: :)
[13:07] <Rospo_Zoppo> Hobbsee: hi, can you please give-back vertex ?
[13:07] <Rospo_Zoppo> on hardy
[13:11] <Hobbsee> Mithrandir: when you get bored, please write another greasemonkey script for retrying builds, and fix your rescore script please.
[13:11] <Mithrandir> Hobbsee: I just need to fix the retry one.  Or you could use pitti's buildd.py script.
[13:11] <Hobbsee> "do you want to retry this build?"  "why, yes launchpad, i do.  i'ts the only menu option on that section of the page, so it's fairly hard to hit by accident.  i'm *very* likely to actually want you to do what i tell you to"
[13:12] <Hobbsee> Mithrandir: i've not heard of that one
[13:12] <Mithrandir> I'll bounce you a copy
[13:12] <Hobbsee> woot :)
[13:13] <Mithrandir> http://people.ubuntu.com/~pitti/scripts/buildd.py is the script; I forwarded the instructions on how to use it
[13:15]  * StevenK remembers pitti writing that script
[13:15] <Mithrandir> I think the problem with my greasemonkey script is it does GET rather than POST
[13:15] <StevenK> pitti sitting on his bed at UDS. Every so often, "Rrrr.. why does that not work? Launchpad!"
[13:16] <Hobbsee> Mithrandir: iz borken :)
[13:16] <Hobbsee>     result = func(*args)
[13:16] <Hobbsee>   File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default
[13:16] <Hobbsee>     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
[13:16] <Hobbsee> urllib2.HTTPError: HTTP Error 500: Internal Server Error
[13:16] <Hobbsee> trust LP to break
[13:16] <Mithrandir> just retry and it ought to work
[13:16] <StevenK> That isn't the scripts problem :-)
[13:16] <Mithrandir> LP doesn't like being DoS-ed
[13:17] <Hobbsee> Mithrandir: same error
[13:17] <Mithrandir> Hobbsee: which FTBFS is this?  I'd like to fix my script.
[13:17] <Hobbsee> Mithrandir: pitti's, sorry
[13:18]  * Mithrandir goes to find a random FTBFS
[13:18] <Hobbsee> Mithrandir: http://rafb.net/p/jHeLcz71.html
[13:18] <StevenK> Mithrandir: If sparc is fixed, I have one
[13:19] <Hobbsee> Mithrandir: erm.  and i cant seem to specify a build prio yet
[13:20] <StevenK> Mithrandir: libgpod on sparc
[13:20] <persia> Mithrandir: http://qa.ubuntuwire.com/ftbfs/ tries to track them all
[13:21] <Mithrandir> StevenK: cheers, I'll play with that, then
[13:22] <Hobbsee> Mithrandir: oh, you were asking which *package* FTBFS.  sorry, didn't undersatnd what you meant
[13:23] <geser> persia: I'm trying to get my script running on people.ubuntuwire.com, the last output is at http://members.ping.de/~mb/build_status/
[13:25] <persia> geser: Does `rmadison -u ubuntu` not do the trick?
[13:26] <geser> persia: the rmadison there doesn't understand it
[13:27] <cjwatson1> rmadison -u http://people.ubuntu.com/~ubuntu-archive/madison.cgi
[13:27] <geser> cjwatson: does it also work on feisty?
[13:28] <cjwatson> geser: should work from devscripts 2.10.0 on
[13:28] <cjwatson> hmm, possibly not feisty
[13:28] <cjwatson> it's a trivial script though, just grab a copy
[13:39] <Mithrandir> StevenK: given-back
[13:39] <StevenK> Mithrandir: Thanks
[13:40] <StevenK> libgpod and friends is on my list post-Alpha1
[13:40] <geser> Mithrandir: as pitti is away, please give-back futilities. Thanks.
[13:40] <Mithrandir> geser: given-back
[13:40] <StevenK> Hah!
[13:40] <StevenK> futilities
[13:40] <geser> Mithrandir: are NEW packages from Debian contrib auto-synced or is a sync request needed?
[13:41] <Mithrandir> geser: they're generally synced without any bug report needed
[13:41] <pitti> re
[13:42] <seb128> wb pitti
[13:42] <geser> ok, then I'll wait
[13:43] <persia> Does that also apply for non-free?
[13:43] <seb128> persia: yes
[13:43] <persia> Thanks.
[13:43] <seb128> persia: you are welcome
[13:43] <pitti> geser: contrib new autosync> not at the moment; if you need something particular, please file a sync request (we need to check which component it shuold go to)
[13:44]  * persia is now confused: does seb128 secretly run a sync when pitti isn't looking?
[13:44] <pitti> Hobbsee: urllib2 HTTP error: are you in launchpad-buildd-admins?
[13:44] <seb128> persia: non-free and contrib are handled the same way
[13:45] <seb128> persia: I never did a new-debian-source run for those though
[13:45] <persia> OK.  So NEW packages should get sync requests.
[13:45] <Hobbsee> pitti: yes
[13:45] <seb128> maybe Mithrandir has some magic for it dunno
[13:46] <pitti> Hobbsee: next possibility is that your firefox cookie.txt doesn't have your Launchpad login cookie
[13:46] <pitti> Hobbsee: if you use epiphany or konqueror, you need to fix it (patches appreciated)
[13:46] <Hobbsee> pitti: status, etc, works.
[13:46]  * Hobbsee uses firefox.
[13:46] <pitti> Hobbsee: right, but status doesn't require privileges
[13:46] <Hobbsee> oh, hang on
[13:49] <pitti> Hobbsee: check if "~/.mozilla/*/*/cookies.txt" expands to the cookie file with LP
[13:49] <Hobbsee> pitti: yeah, found it.  i haave 2 folders under .mozilla, and in firefox-3.0, i have my normal profile, and a clean one, as i was testing a firefox bug a couple of days ago.
[13:50] <pitti> Hobbsee: the current code to find it could do with some cleanup (like iterating over all found ones and check which ones have a LP cookie), but I never bothered to do that
[13:50] <Hobbsee> pitti: sorry, i deleted the profile, but obviously it didn't delete the data.  *blush*
[13:50] <Hobbsee> yeah, having multiple firefox profiles is kinda rare
[13:51] <Hobbsee> pitti: thanks, works a chram.
[13:52] <ogra> pitti, can you let ldm out of NEW?
[13:52] <ogra> its just a split of the ltsp source
[13:53] <pitti> ogra: at it already
[13:53] <ogra> gracias :)
[13:54] <pitti> te nada
[13:54] <ogra> no hurry though, i seem to have added some ftbfs stuff to ltsp (just testbuilding the fix) :)
[13:55]  * ogra hugs his new line ... uploading ltsp is faster than the terminal can scroll :)
[13:56] <somerville32> ogra, How fast is it?
[13:56] <ogra> 2Mbit symmetrical
[13:56]  * ogra had 128k upstream before ;)
[13:57] <somerville32> I have a 7mb down and 512kb up
[13:58] <pitti> ogra: can you maybe drop autom4te.cache/ from the orig.tar.gz?
[13:58] <ogra> pitti, ldm ?
[13:58]  * ogra looks
[13:58] <pitti> yes
[13:58] <ogra> hmm, the mkdist script should probably delete it whn creating the tarball
[13:58] <pitti> yep
[13:58]  * ogra fixes
[13:59] <pitti> looks fine otherwise
[13:59] <ogra> well, its what we used since dapper :) just split out
[13:59] <pitti> ogra: depending on your sense of beauty, shall I accept it, or reject and you upload a clean orig.tar.gz?
[14:00] <ogra> reject
[14:01] <pitti> ogra: done; let me know when you upload, then I'll wave it through
[14:02] <pitti> Riddell: hm, how come that gnupg2 wants to go back to universe? you don't use it any more in kubuntu?
[14:04] <Riddell> pitti: I don't think anything has changed since gutsy, kleopatra is in universe
[14:04] <Hobbsee> gnupg2 should be there for pinentry, i would think
[14:05] <pitti> kdepim> yay gcc ICE
[14:07]  * pitti gives it back, the previous version worked
[14:08] <Riddell> ScottK knows about gpg and kdepim, I get lost in a twisty maze of passages all alike
[14:09] <Hobbsee> uh, why is gpgsm not part of kdepim anymore?
[14:09] <Hobbsee> sarah@LongPointyStick:~% show libgpgme11 | grep gpgsm                    1:09AM
[14:09] <Hobbsee> Suggests: gpgsm
[14:09] <Hobbsee> that'll do it
[14:09] <Hobbsee> wonder why that got dropped
[14:10] <Hobbsee> what?  that can't be right...
[14:11] <Riddell> kmail should also depend on it
[14:11] <Hobbsee> debian bug #281261
[14:11] <ubotu> Debian bug 281261 in libgpgme11 "please, add gpgsm to Recommends when available" [Wishlist,Fixed] http://bugs.debian.org/281261
[14:11] <Hobbsee> Riddell: it was doing so, thru libgpgme11.
[14:12] <Hobbsee> Riddell: sigh.  Lure wants to work on it on the weekend anyway.  either we explicitly seed it nwo, or ignore it.
[14:13] <Hobbsee> Lure: can you make sure you add gpgsm as a dep for kmail please?
[14:13] <Lure> Hobbsee: will do
[14:13] <Hobbsee> Lure: thanks
[14:18] <Hobbsee> pitti: i guess it goes without saying to not force it back
[14:35] <ogra> pitti, new ldm :) same version ... no autom4te.cache :)
[14:36] <pitti> ogra: thanks, accepted
[14:36] <ogra> thanks :)
[15:26] <knowmad> sladen: my custom usplash is working!
[15:41]  * LaserJock shoots a glance at jcastro 
[15:58] <sladen> knowmad: excellent, congratulations!
[15:58] <sladen> knowmad: pop over to #ubuntu-motu and get it directly into the archive next!
[16:21] <knowmad> sladen: hi; heading over
[16:22] <knowmad> sladen: oh, that's to get it loaded; well this is probably not something anyone else will want; it's a custom bootsplash for a client with their own log
[16:23] <knowmad> s/log/logo
[16:23] <knowmad> sladen: btw, i'm posting that bug report for you on launchpad; my analysis is that it only happens when using '-c' option to open on vt8
[16:25] <knowmad> i tried to trace the calls in usplash.c but my c knowledge is rudimentary and my linux pgmming knowledge is nil; it does appear to be using switch_console function in libusplash.c which makes ioctl calls
[16:42] <lamont> mvo: you around?
[16:42] <lamont> Getting upgrade prerequisites failed
[16:42] <lamont> The system was unable to get the prerequisites for the upgrade. The upgrade will abort now and restore the original system state.
[16:42] <lamont> what's that mean?
[16:42]  * lamont discovers log files..
[16:43] <lamont> maybe if the mirror had feisty-backports on it... :(
[16:46] <lamont> mvo: btw, what it means is that update-manager doesn't know to use ubuntu-ports for ports upgrades...
[16:49] <mvo> lamont: urgh, ok. ports ...
[16:49] <mvo> lamont: that is entirely possible, could you file a bug please? and make it "high" priority?
[16:49] <lamont> what thing where generates /etc/apt/sources.list.d/prerequists-sources.list?
[16:49] <Hobbsee> mvo: on another subject you don't wnat ot think about - what's your plan w.r.t ppa and dist-upgrades?
[16:50] <lamont> will file a bug... but I want to upgrade this poor box first...
[16:50] <lamont> I suppose I could just dist-upgrade, but I'm trying to play right...
[16:50] <lamont> Hobbsee: what plan would be needed?
[16:51] <Hobbsee> lamont: it has the potential to turn into an automatix-like situation?
[16:51] <Hobbsee> like, new versions of dpkg, etc, goodness knows waht
[16:51] <lamont> ppa's are a loaded handgun...
[16:51] <Hobbsee> as is automatix, and we get screamed at about it each release.
[16:51] <lamont> as in, I don't think we support them on upgrade. :-)
[16:52] <lamont> update-manager strips everything but ubuntu.com sites from the list before the upgrade, if you have any of those in sources.list
[16:52] <Hobbsee> yes, but is that enough?  the damage would presumably already be done
[16:53] <lamont> "use a harmonica...."
[16:53] <lamont> hrm.. maybe that was obscure
[16:53] <LaserJock> Hobbsee: I don't see how you can just not let people upgrade because they have a PPA enabled
[16:54] <ogra> LaserJock, broken version numbers ....
[16:54] <lamont> if you've forked upgrade-requisite packages in your ppa, then you have an issue.
[16:54] <Hobbsee> LaserJock: agreed, but i suspect it deserves some thinking about what happens if someone's used a ppa to grab a new version of dpkg, whcih explodes.
[16:54] <Hobbsee> lamont: ++
[16:54] <ogra> i.e. you have a development version of an app that uses the odd/even scheme for its releases and there was no new release yet
[16:54] <mvo> lamont: it only strip non-ubuntu (or mirrors) if your sources.list contains both. if you have a "internal mirror" only configuation it should do the right thing
[16:54] <Hobbsee> lamont: in those cases, then what happens?  This is my question
[16:54] <LaserJock> Hobbsee: well yes, that is an issue
[16:55] <LaserJock> but I don't see what update-manager is supposed to do with it
[16:55] <Hobbsee> badly phrased, i'll agree, but that's probably because it's 4M.
[16:55] <lamont> mvo: I didn't have feisty-backports mirrored here, so it created prerequisits-sources.list
[16:55] <Hobbsee> not let you upgrade, or reinstall the proper packages of required upgrade stuff before upgrading?
[16:55] <lamont> and editing that file doesn't do me any good.
[16:55] <lamont> since it overwrites it
[16:56] <LaserJock> Hobbsee: I don't see "not let you upgrade" as an option, reinstall may work but then you've probably already got a hosed system
[16:56] <mvo> LaserJock: how do you mean? why they get commented out?
[16:56] <Hobbsee> LaserJock: that was planned in sevilla for automatix-based stuff.
[16:56] <lamont> Hobbsee: who says that hardy's dpkg will even work with what you've done to /var/lib/dpkg/status in your ppa version of dpkg?
[16:57] <Hobbsee> lamont: granted.  this is why it requires some discussion
[16:57] <LaserJock> Hobbsee: right, and I don't think I'd agree with that, that's all
[16:57] <lamont> Hobbsee: it requires some knowledge on the part of the user if he's using a ppa with upgrade-scary stuff...
[16:57] <lamont> regardless of how much discussion happens here...
[16:57] <Hobbsee> lamont: i think it's going to have to, yes.
[16:57] <Hobbsee> lamont: it's just a question of whether the upgrader tries, and bails, or doesn't try at all
[16:58] <LaserJock> complaints from every Automatix/PPA users of "Ubuntu won't let me upgrade unless I use their software" will occur more often than "OMG, I upgraded and my system is hosed"
[16:58] <LaserJock> and it much more MS sounding
[16:58] <mvo> lamont: hm, so all your sources.list point to a internal mirror and your use something that is normally only on ports.u.c ?
[16:58] <lamont> deb http://archive.mmjgroup.com/ubuntu-ports feisty main universe
[16:58] <lamont> for example
[16:58] <Hobbsee> anyway, /me --> bed.
[16:58] <lamont> and exclusively
[16:58] <LaserJock> A warning claiming we're not responsible if your upgrades doesn't work if you have 3rd party repos makes sense
[16:59] <lamont> feisty-backports does not exist on archive.m.c
[16:59] <lamont> (not mirrored)
[16:59] <LaserJock> but blocking users from using the upgrade tool seems a bit much
[16:59] <LaserJock> Hobbsee: night
[16:59] <alex-weej> asac: can i talk to you for a minute about n-m or is now a good time?
[16:59] <alex-weej> *now not
[16:59] <mvo> lamont: and currently its doing the wrong thing and comments those out?
[16:59] <Hobbsee> LaserJock: i guess if you make it big enough, then the user will have to read it, and so then the people can still whinge, but then be proved that they didn't read
[17:00] <LaserJock> Hobbsee: yep
[17:00] <Hobbsee> "i ignored teh big warnings, and ubuntu hosed my system"
[17:00] <lamont> mvo: no.
[17:00] <LaserJock> Hobbsee: exactly ;-)
[17:00] <lamont> it generates sources.list.d/prerequists-sources.list  with the wrong target, overwriting that file if it previously existed
[17:01] <lamont> mvo: and I want to hack where it creates that file so that it does the right thing for now, and i can upgrade..
[17:01] <mvo> lamont: and your machine can not access archive.ubuntu.com (or us.archive.ubuntu.com) where this sources.list file points to?
[17:01] <lamont> without doing the upgrade fro a.u.c
[17:02] <lamont> deb http://us.archive.ubuntu.com/ubuntu feisty-backports main/debian-installer
[17:02] <lamont> show me a binary-ia64/Packages.gz file there....
[17:02] <mvo> lamont: ok, I get the problem now. its tricky, give me a sec to think about it
[17:03] <lamont> do-release-upgrade is a twisty maze of files that are doing a very good job of hiding where it creates that file...
[17:03] <mvo> lamont: the biggest problem is that the bulk of the stuff comes directly from the net and is not local where you can edit it :/
[17:03] <alex-weej> mvo: been waiting on you for a response on https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/19053 :)
[17:03] <ubotu> Launchpad bug 19053 in synaptic "Synaptic doesn't respect gnome preferences" [Wishlist,Confirmed]
[17:03] <lamont> we could get IS to put redirects on archive.u.c. :-)
[17:04] <lamont> mvo: oh. how, uh, nausiating
[17:04] <mvo> lamont: I can fix the actual bug in a SRU pretty easily, but it will take until tomorrow I think
[17:05] <mvo> lamont: would it be ok for you to wait until then?
[17:05] <lamont> yes
[17:07] <mvo> lamont: ok, I will do it first thing in the morning, if you want a workaround I can give you one, but it would be cool if you could test the fix with that machine
[17:11] <lamont> mvo: I'll stall my upgrade until tomorrow
[17:18] <mvo> lamont: sorry for the trouble, it seems to affect only ia64 and hppa, I think I know how to fix it
[17:18] <lamont> mvo: if the internal mirror has feisty-backports, and no net access, will things do the right things?
[17:18] <lamont> mvo: I'll go ahead and smack a bug through to you momemntarily
[17:20] <mvo> lamont: I think it won't :( it will do the right thing if you give it a CD to upgrade from (a ia64 alternative)
[17:20] <lamont> :-(
[17:20] <lamont> my other machine has that situation, sort of...
[17:21] <lamont> DNAT rule on the firewall that redirects all port 80 traffic to archive.m.c :)
[17:21] <lamont> where there is a {feisty,gutsy}{,-security,-updates} mirror pile.
[17:22] <lamont> I just haven't taught it about backports at all - I can add at least a subsection of that if you need me to...
[17:29] <mvo> lamont: :(
[17:32] <lamont> mvo: 172609, assigned to yo
[17:32] <lamont> u
[17:33] <lamont> mvo: I guess the real question is: "what all do I need to mirror onto that machine to make the rest of the computers work?"
[17:33]  * lamont really doesn't want to iterate through reading access.log for apache :-)
[17:33] <lamont> bug 172609
[17:33] <ubotu> Launchpad bug 172609 in update-manager "mishandles prerequists-sources.list on ports architectures" [High,Confirmed] https://launchpad.net/bugs/172609
[17:35] <cjwatson> (any chance that "prerequisites" could be consistently spelled correctly?)
[17:36] <lamont> cjwatson: that'd be a different bug. :-)
[17:36] <lamont> I think maybe the e-free version is german? :-)
[17:37] <cjwatson> I suspect that would be Voraussetzung ;-)
[17:37] <ogra> i dont think we use that word here
[17:37] <ogra> yeah
[17:37]  * lamont considers the trick of dpkg-diverting apt-get to a script that checks/fixes that file... 
[17:37] <lamont> ogra: waz joke
[17:37] <mvo> *cough* cjwatson *cough* yes
[17:37] <ogra> lamont, well, there are some words :)
[17:38] <lamont> ogra: that's why the joke works :-D
[17:38] <ogra> :)
[17:39] <lamont> "dpkg-divert":  the alternate spelling for "I win."
[17:39]  * ogra wonders why he cant get ip forwardig to work on his router :/
[17:39] <cjwatson> lamont: though, as we found out, a little bit non-trivial to apply to dpkg-deb
[17:39] <lamont> ogra: echo 1 > /proc/sys/net/ipv4/ip_forward ?
[17:39] <lamont> cjwatson: ew.  who did that?
[17:40] <ogra> lamont, thast fine i want to have port forwarding (sorry, wrong term)
[17:40] <lamont> s/did/tried/
[17:40] <cjwatson> lamont: pkgbinarymangler
[17:40] <cjwatson> $ dpkg -c /mirror/ubuntu/pool/main/p/pkgbinarymangler/pkgbinarymangler_45_all.deb | grep dpkg-deb
[17:40] <cjwatson> -rwxr-xr-x root/root      1078 2007-09-13 21:55 ./usr/bin/dpkg-deb
[17:40] <ogra> i use ipmasq for NAT and want outside port to be forwarded ...
[17:40] <lamont> ipmasq?
[17:40] <ogra> i know i just did something like: iptables -D PREROUTING -t nat -p tcp -i ppp0 --dport 80 -j DNAT --to 192.168.2.XX in the past
[17:41] <ogra> but that somehow doesnt get through
[17:41] <cjwatson> and note the preinst evil required
[17:42] <lamont> cjwatson: at least it knows that the correct spelling is "mangler" not "manager"
[17:42] <ogra> err -A indeed :)
[17:43] <cjwatson> lamont: I think it's the most lamontish thing I've seen that wasn't written by you ;-)
[17:43] <lamont>                 # on initial install, we have no dpkg-deb, cause we just diverted it
[17:43] <lamont> cjwatson: "lamontish", eh?
[17:43] <cjwatson> preinst diverts dpkg-deb. dpkg tries to unpack pkgbinarymangler/data.tar.gz. boom.
[17:44] <cjwatson> lamont: ;-)
[17:44] <lamont> I just find that sometimes fixing a bug with the minimal change and time involved requires some (er, significant) creativity
[17:45] <lamont> if you permit me a larger footprint, then it looks less, um, creative.
[17:45] <lamont> sometimes happens faster, too.
[17:45] <cjwatson> "build openoffice.org. you have 230 cycles"
[17:45] <lamont> easy.  uuencode the binary in the source upload.
[17:46] <cjwatson> touché :-)
[17:46] <lamont> 2) die.
[17:46] <MacSlow> redirected widget-drawing fun (almost correct) -> http://people.ubuntu.com/~mmueller/reflected-widgets-1.ogg
[17:46] <lamont> (since that _WOULD_ result in a death-squad)
[17:46] <lamont> hell, I'd lead it.
[17:46] <lamont> or did you mean cycles from the Taltos series?
[17:47] <MacSlow> for some reason the lower part doesn't get refreshed correctly although all drawing is happening in the same expose-handler
[17:47] <lamont> in that case, it might just finish in significantly less than one cycle.
[17:48] <lamont> cjwatson: the absolute worst thing I can remember ever doing was writing code in a kernel driver that returned to user space while holding a spinlock.  on purpose.
[17:48] <lamont> I felt _very_ dirty.
[17:49] <lamont> OTOH, implementing simulated non-cache-coherent DMA in user-space requires lots of dirt.
[17:50] <cjwatson> lamont: "here, userspace, pray hard"?
[17:50] <lamont> cjwatson: I abused an already-existant hook in exit() to make things pretty before the exit() path grabbed the spinlock.
[17:51] <lamont> and then there was the other bit where I told the one other kernel process that might try to grab the spinlock to stay the hell away from there
[17:52] <lamont> and _that_ (very big) rock also protected me from little things like being paged out of memory.
[17:53] <lamont> getent shadow| grep lamont | cut -d: -f1,3-
[17:53] <lamont> lamont:13179:0:99999:7:::
[17:53] <lamont> lamont:13845::99999:7:::0
[17:53] <lamont> interesting the small differences one sees between the local passwd file and ldap...
[18:03] <tkamppeter> pitti, hi
[18:04] <pitti> hi tkamppeter
[18:04] <tkamppeter> pitti, I have seen you have fixed the AA rules for reported AA issues with CUPS.
[18:04] <pitti> tkamppeter: right; I got a reply from the AA upstream guys how to fix the Bluetooth bug in a better way, though
[18:04] <pitti> I'll handle that tomorrow
[18:05] <pitti> tkamppeter: I just need someone to review my SRU (I pinged cjwatson so far, but he's incredibly busy with d-i, so I don't expect an answer soon)
[18:06] <tkamppeter> pitti, there is one problem. You have fixed the problems of each driver by an individual solution for the particular driver. Problem is then if for example a printer manufacturer supplies a new driver it will not work with Ubuntu-
[18:07] <pitti> only if it does some low-level crack; usual operations should already be covered by the profile
[18:08] <pitti> but yes, that's a general problem
[18:08] <pitti> tkamppeter: I have to try, but it could be possible to say 'restrict the backends we ship ourselves and run the unknown ones unrestricted'
[18:10] <tkamppeter> pitti, probably this is the best solution. expand it to also filters (/usr/lib/cups/filter/*) and PPD generators (/usr/lib/cups/driver/*) and all third-party drivers and backends should work.
[18:11] <ScottK> Lure: Just reading the scrollback from the Kmail/gpgsm discussion.  What I see we had in Gutsy (and should be unchanged) for Kmail depends is: ... gpgsm, gnupg-agent, pinentry-qt | pinentry-x11
[18:12] <tkamppeter> pitti, and add this to the SRU, so that Gutsy users will also have access to all third-party drivers and software for CUPS.
[18:12] <Lure> ScottK: not sure when was this lost - I recall this was ok early in gutsy
[18:12] <Lure> ScottK: and hardy kdepim was the same as gutsy until recently (not merged with debian)
[18:13] <Riddell> Lure: it would have been lost when I merged with debian
[18:13] <Lure> Riddell: oh, so we have merged even though that we have different branch (enterprise)?
[18:14] <ScottK> Riddell: This is in Hardy, right?  We didn't lose this for Gutsy (where it's mentioned in the release notes), I really hope???
[18:14] <Riddell> ScottK: correct
[18:14] <Riddell> Lure: only the packaging was merged
[18:15]  * ScottK relaxes a bit.
[18:53] <RicardoPerez> seb128: ping
[19:24] <LaserJock> Riddell: ping
[19:26] <Riddell> hi LaserJock
[19:35] <LaserJock> Riddell: do you mind people working on KDE-Edu
[19:35] <LaserJock> I was just looking at Bug #164563 and wondered the best way to get it fixed
[19:35] <Riddell> LaserJock: I'd positively encourage it
[19:35] <ubotu> Launchpad bug 164563 in kdeedu "kstars can connect but not control lx90 using kubuntu gutsy" [Undecided,New] https://launchpad.net/bugs/164563
[19:36] <LaserJock> Riddell: is it better to give your or a Kubuntu person a debdiff or is just uploading ok?
[19:36] <LaserJock> I didn't know if you had any grand plans
[19:36] <Riddell> LaserJock: just uploading is fine with me
[19:37] <LaserJock> Riddell: k, thanks
[19:37] <Riddell> although generally a ping is a good idea so we don't clash on something and so I can update the bzr archive
[19:37] <LaserJock> Riddell: is kde-edu in bzr?
[19:38]  * LaserJock realizes that's somewhat of a rhetorical question :-)
[19:40] <alex-weej> does anyone know at what stage the networking service starts? seems in both hardy and gutsy it is failing to associate wlan devices
[19:57] <nenolod> haha cool, bdmurray is taking on all of the stagnent ALSA bugs
[20:08] <ryu> welcher kopp kommentiert denn schon wieder fußball hier :(
[20:08] <geser> ryu: -EWRONGCHANNEL?
[20:09] <ryu> geser, jeah, sorry :(
[20:09]  * LaserJock looks at KDE Edu's debian/ and cries
[20:26] <Riddell> LaserJock: what's wrong with kdeedu's debian/ ?
[20:26] <Riddell> LaserJock: kdeedu is a 279K upload, not 30MB
[20:32] <LaserJock> Riddell: right, had merging on the brain
[20:32] <LaserJock> Riddell: nothing wrong, just a lot going on
[20:33] <LaserJock> Riddell: KDE packages are so big and have a lot of binary package built out of them
[20:36] <DB42> hi, i'm trying to do "apt-get source ntp" and afterwards when i ./configure it fails on
[20:36] <DB42> config.status: error: cannot find input file: ElectricFence/Makefile.in
[20:38] <Fujitsu> DB42: This is not a support channel.
[20:38] <Fujitsu> However, you probably want to use dpkg-buildpackage.
[20:38] <DB42> it's a devel issue
[20:39] <Riddell> LaserJock: that has advantages and disadvantages.  you get used to it
[20:39] <cjwatson> DB42: it's not an Ubuntu development issue, because it built fine for us. :-)
[20:40] <cjwatson> (our source packages all build using dpkg-buildpackage or similar, as Fujitsu pointed out)
[20:42] <LaserJock> Riddell: yes, I can imagine. I just need to dig into KDE packaging. It's good to get familiar with in any case
[20:54] <lamont> DB42: and I expect that if you look at debian/rules, you'll find that configure is run with a number of arguments...
[20:54] <Fujitsu> lamont: Do you know if there are any mass givebacks planned?
[20:54] <DB42> tnx
[20:55] <lamont> Fujitsu: always. :-)
[20:55]  * lamont can't do mass givebacks
[20:55] <Fujitsu> lamont: Any kind of timeline?
[20:55] <lamont> since "mass giveback" currently == "SQL magic on the database"
[20:55] <Fujitsu> So I guessed.
[20:55] <ScottK> or lamont doing a lot of typing.
[20:55] <Fujitsu> Hah.
[20:56] <Fujitsu> DktrKranz, geser ^^
[20:56] <lamont> I may walk through the tree looking at not-yet-built packages (http://bld-4.mmjgroup.com/~wb/buildLogs/Lists for each arch...), and handle some of them.
[20:56] <lamont> Fujitsu: infinity is who you need...
[20:56]  * lamont can't give ETAs for things he can't do.
[20:56] <Fujitsu> lamont: I thought it might be him, but he's never around...
[20:57] <jdong> lamont: whom.
[20:57]  * lamont discovers from his firewall log that apparently update-manager tries to fetch some stuff from people.u.c???  wth?
[20:57] <Fujitsu> lamont: We now have http://qa.ubuntuwire.com/ftbfs, too.
[20:57] <lamont> jdong: no.
[20:57] <lamont> 'who'
[20:58] <lamont> jdong: one would not say 'him is who you need'
[20:58] <jdong> lamont: err, oops you're right
[20:58]  * lamont lets that poor ia64 machine talk to p.u.c as well.
[20:58] <cjwatson> or, in more formal grammatical terms, "to be" takes the nominative
[20:58] <geser> Fujitsu: can't you drive by him?
[20:59] <Fujitsu> geser: Heh. I know the suburb, but not any more.
[20:59] <jdong> cjwatson: because to be is a copulative verb :)
[20:59]  * jdong pulls hair out
[20:59] <cjwatson> the way I remember this is from a brief bout of learning Hungarian, where you have a thing called "equational sentences"; if you want to say "X is Y", you just say "X Y", both in the nominative
[20:59] <cjwatson> IIRC, anyway
[21:00] <lamont> cjwatson: I finally understood it with 'substitute "he" or "him"'
[21:00] <lamont> I've also come to understand that latin has more parts of speech than rational minds should be asked to grasp.
[21:00] <ScottK> Perfect.
[21:01]  * ScottK has one daughter in Latin.
[21:01] <cjwatson> colloquial English is sort of broken though; it's quite common to use the accusative after "to be" (e.g. "it was him" rather than "it was he"), hence jdong's confusion
[21:01] <somerville32> cjwatson, Has there been any progress on making provisions to allow Xubuntu to be hosted on r.u.c?
[21:01]  * Fujitsu has always wanted to learn Latin at some point.
[21:01] <cjwatson> somerville32: no, sort of intentionally
[21:01] <jdong> cjwatson: it's not helpful that the commonly understood expression C'est moi looks like an analog of using the accusative after to be.
[21:01] <norsetto> ave fujitsu, morituri te lasutant
[21:01] <cjwatson> somerville32: the smaller releases.u.c can be, the better
[21:01] <norsetto> ops, make it salutant
[21:02]  * Fujitsu curses norsetto.
[21:02] <cjwatson> somerville32: many of the constraints on that are outside Canonical and not within our control
[21:02] <somerville32> cjwatson, The last time we all chatted, I thought we were going to try and get Xubuntu on there.
[21:02] <cjwatson> basically, every extra thing you add to releases.u.c is giving up some more mirrors
[21:03] <cjwatson> I'm sorry if I gave that impression; I don't remember doing so
[21:03] <cjwatson> I might have said that I would make it better-linked *from* releases.u.c
[21:03] <cjwatson> (still happy to do that, but a bug to remind us would be good)
[21:03] <somerville32> cjwatson, Well, IIRC, mdz said that he saw no reason why Xubuntu shouldn't be on there and so we had a little conversation about it on here (I think elmo was involved too)
[21:04] <somerville32> cjwatson, Xubuntu is an official derivative so I don't see why it should be the odd one out.
[21:04] <somerville32> cjwatson, At the time, the reasoning was space constraints but you had said you were going something about it
[21:04] <somerville32> Thought you must not have meant for Xubuntu
[21:04] <Mithrandir> somerville32: so is ume, so is gobuntu and I believe ubuntustudio too.
[21:05] <Mithrandir> not to mention jeos
[21:05] <somerville32> Mithrandir, It was my understanding they were "supported" but not Official like Ubuntu, Kubuntu, Xubuntu ...
[21:06] <cjwatson> Ubuntu Studio is at the same level as Xubuntu
[21:06] <Mithrandir> somerville32: what do you mean by "Official" in this context?
[21:06] <Fujitsu> At least UME would be more official.
[21:06] <cjwatson> it's a community-supported derivative
[21:06] <cjwatson> somerville32: we have improved some of the space constraints within the datacentre, but we can't do anything about those outside the datacentre
[21:06] <Mithrandir> Fujitsu: yeah, though currently it pulls stuff from universe.  That'll go sometime during the hardy cycle.
[21:07] <cjwatson> I may have been talking about a couple of things at once, and I'm sorry if I was confusing
[21:07] <somerville32> Xubuntu isn't community supported
[21:07] <Fujitsu> Mithrandir: Right, but the intention is for it to be more official than Xubuntu etc.
[21:07] <Fujitsu> somerville32: Yes it is...
[21:07] <somerville32> All of it's components are in main
[21:07] <cjwatson> I don't think that being on releases.ubuntu.com should be regarded as a barometer of officialness
[21:07] <somerville32> Main isn't "community supported"
[21:07] <cjwatson> somerville32: it's not Canonical-supported. Ergo, it's community-supported.
[21:07] <somerville32> cjwatson, I thought Canonical supported all packages in main?
[21:07] <cjwatson> admittedly, at present, that smaller part of the community with the ability to upload to main
[21:07] <Mithrandir> Fujitsu: yes.
[21:07] <cjwatson> somerville32: Xubuntu is an awkward exception to that
[21:08] <cjwatson> we don't have the resources to provide commercial support for Xubuntu
[21:08] <Mithrandir> somerville32: there's support and there's support.  I believe Xubuntu gets full security support, but it does not get the user support that Canonical provides for Ubuntu and Kubuntu.  (Colin, please correct me if I'm wrong here)
[21:08] <cjwatson> I'm not absolutely certain of the security position, but that's pretty close
[21:09] <Fujitsu> Mithrandir: For as much security support as main actually gets....
[21:09] <cjwatson> so, in a number of ways, it would actually be clearer if Xubuntu were in universe
[21:09] <keescook> ?
[21:09] <somerville32> Are you saying that it is possible for one to void their support contract by installing certain packages from main?
[21:09] <Mithrandir> so you can't buy a support contract for an Xubuntu desktop, while you can for an Ubuntu desktop.
[21:09] <somerville32> A ubuntu desktop is simply support for packages in main, is it not?
[21:09] <Mithrandir> somerville32: it's possible to install packages where we would tell you "sorry, that configuration is not supported" or "we don't support that package on that level, sorry".
[21:10] <somerville32> Then maybe we should update the website?
[21:10] <cjwatson> somerville32: I'm not aware of the exact details, but at present Canonical support describe things in terms of "the Ubuntu desktop" or "an Ubuntu server" which is very different from main
[21:10] <Mithrandir> somerville32: if you're asking about the commercial support and exactly which packages that cover, it's better if you ask the support department.   I don't have a list here.
[21:10] <cjwatson> I believe the situation is made quite clear to commercial support customers
[21:11] <cjwatson> but you're right that it's confusing, and actually, we'd like to get back to the point where main is the stuff that's commercially supported
[21:11] <somerville32> The website states that Canonical guarantees a level of quality for main packages, are "xubuntu packages" an exception?
[21:11] <cjwatson> the reason that Xubuntu was promoted to main was so that we could build CDs for it, in essence
[21:12] <cjwatson> however, when Ubuntu Studio came on the scene, what we did instead was to instigate a system where we could build CDs from universe, without compromising the safeguards that ensure that Ubuntu CDs don't contain universe packages
[21:12] <cjwatson> I think that for hardy we should move Xubuntu across to this system, and move packages that are only seeded for Xubuntu back to universe
[21:13] <cjwatson> this would allow more developers to be involved in Xubuntu without having to jump through the hoops that are required for main, and simplify the description of what's supported considerably
[21:13] <cjwatson> what do you think?
[21:13]  * _MMA_ lurks.
[21:13]  * Fujitsu locks _MMA_ out.
[21:14] <somerville32> cjwatson, I'd have to think about it before I could give an opinion.
[21:14] <somerville32> But the hoops are the same for Universe and Main pretty much if you're not a developer in the first place.
[21:15] <cjwatson> I think that the Xubuntu community will be more able to effectively support it that way, and that there will be fewer constraints imposed by the way we do things for Ubuntu that are partly due to the requirement for commercial support
[21:15] <somerville32> cjwatson, It could definitely be a positive thing
[21:15] <cjwatson> somerville32: sure, but quite a lot more people can upload to universe than to main, and universe doesn't require main inclusion reports and special review of every single package
[21:15] <somerville32> cjwatson, qa isn't a bad thing :P
[21:16] <Mithrandir> somerville32: nobody prevents people from doing more QA on universe, though.
[21:16] <cjwatson> no, but one half of the purpose of main inclusion reports is to ensure that we can provide effective commercial support
[21:16] <cjwatson> so half of the work there is wasted
[21:16] <cjwatson> and, what Mithrandir said of course
[21:17] <somerville32> Well, it is something to bring up
[21:17] <Fujitsu> Mithrandir: Indeed, we're trying to improve QA significantly for Hardy.
[21:17] <cjwatson> the community around universe is a lot bigger than it was a couple of years ago, and I think it's time to treat it as such :)
[21:17] <somerville32> But I don't think most people (mostly users) will perceive this in the same light
[21:17] <Mithrandir> I'd love to see more MOTUs and more people help out with ensuring universe is of good quality.  It's hard work and loads of work; I'm not trying to make it sound like it's an easy task.
[21:17] <Mithrandir> Fujitsu: great. :-)
[21:17] <cjwatson> our systems are geared around promoting everything at a certain level of quality and usefulness to main, at which point suddenly only a restricted number of people can work on it
[21:18] <Fujitsu> (and we're trying to get security support in order too, but we just don't have enough people at the moment)
[21:18] <cjwatson> I think this scheme is pretty dated and should probably be phased out
[21:19] <cjwatson> it creates confusion such as what was mentioned above, since Canonical's support department can't hope to grow at the same rate as our development community, even ubuntu-core-dev
[21:20] <somerville32> I think it is sad that we can't move forward with providing more support for Xubuntu.
[21:20] <somerville32> It is gaining a lot of traction :]
[21:20] <cjwatson> support != commercial support
[21:20] <cjwatson> I think very effective support for it can be provided without it having to be on a commercial basis
[21:21] <somerville32> I know that Canonical supports Ubuntu but is Ubuntu and Canonical truly separate entities?
[21:21] <cjwatson> we don't mind-control the core developers who don't work for Canonical ;-)
[21:22] <cjwatson> (hmm. spec for hardy+1? ;-))
[21:22] <Fujitsu> cjwatson: That's what you want us to think.
[21:22] <somerville32> Well, main is clearly controlled by Canonical.
[21:23] <joejaxx> cjwatson: the north pole mind control ray ;)
[21:23] <cjwatson> I would dearly love Canonical staff to be in a minority among core developers
[21:23] <Fujitsu> cjwatson: That's a little way off yet.
[21:23] <lifeless> aren't they? I thought they were < 50%
[21:24] <_MMA_> somerville32: Im wondering a couple of things. Why do you want "Commercial support" from Canonical? Is it just about perception? Im not sure there's anything (maybe some trademake agreement) stopping you or anyone from starting a support company.
[21:24] <somerville32> _MMA_, I'm not looking for them to sell Commercial support.
[21:24] <somerville32> I just want Xubuntu to be completely equal to say Kubuntu
[21:24] <somerville32> (Besides Canonical, the third party here, selling support for it)
[21:25] <cjwatson> lifeless: you're right
[21:25] <lifeless> cjwatson: your dear desire is granted
[21:25]  * Fujitsu notes quite a few are ex-Canonical, at least.
[21:25] <_MMA_> somerville32: It, we, are in my eyes. Other then selling support and pressing disks. Which we're gonna do. (press disks that is)
[21:25] <cjwatson> right, the numbers are different if you count that
[21:26] <cjwatson> somerville32: I don't think it's ever going to be possible to resolve the confusion between main and commercial-supportedness without making them equal
[21:26] <lifeless> well, they went through the application process, and - amusingly - at least one works for red hat
[21:26] <Fujitsu> lifeless: Heh, I was rather amused when I discovered that 24 hours ago.
[21:26] <Lure> somerville32: I am sure Canonical has limited resources and has to decide what to use the limited resources on
[21:26] <somerville32> cjwatson, And I dunno about demoting Xubuntu. With it being in mean, Canonical provides security updates for it.
[21:26] <somerville32> Lure, I would never of imagined that :P
[21:26] <Lure> somerville32: but as _MMA_ said, there is space for other comapnies to take leading role in Xubuntu
[21:26] <Fujitsu> somerville32: Universe may well have sane security updates for Hardy.
[21:27] <cjwatson> somerville32: as far as I can see, there's been exactly one security update for Xubuntu ever
[21:27] <keescook> xfce4-terminal!
[21:27] <cjwatson> does this really correspond to what the security update situation would be if they were being handled by a group with more of a vested interest in Xubuntu?
[21:28] <cjwatson> I'll let Kees speak for himself, but I suspect that XFCE updates come relatively low on his list, behind things with commercial support; and from what I hear Kees' list never reaches empty
[21:29] <keescook> well, as you say, the only thing that I'm aware of that was xfce-specific was the xfce4-terminal update I did a while back
[21:29] <cjwatson> I expect that spreading that out to a wider group would improve the situation for everyone
[21:29] <keescook> the bulk of a xubuntu system is the same as an ubuntu system, really.
[21:30] <Fujitsu> cjwatson: I don't see a wider security group.
[21:30]  * somerville32 is worried people will treat Xubuntu differently with it not being in main.
[21:30] <cjwatson> Fujitsu: the potential for one, at least
[21:31] <cjwatson> somerville32: I don't deny there's a messaging issue, but I'd like to hear specific concerns that can be addressed, rather than general ones
[21:32] <somerville32> cjwatson, I'd like to see Xubuntu full ratified as a full derivative similar to Kubuntu
[21:32] <somerville32> *fully
[21:32] <cjwatson> because I do not believe that the current situation is an effective use of Xubuntu developers' time
[21:32] <cjwatson> somerville32: that is, Canonical offering support for that? I'm afraid that's not on the table
[21:33] <cjwatson> I do not think that "official derivative" should have to mean "in main"
[21:33] <_MMA_> somerville32: Im sorry. I just fail to see why this is important. It just looks to be about perception. :)
[21:33] <somerville32> _MMA_, It is about perception.
[21:33] <cjwatson> surely fully hosted in the main Ubuntu archive and having Canonical build and host CD images makes it pretty official
[21:33] <Mithrandir> somerville32: it's not like the people in core-dev who don't run Kubuntu spend much time fixing kubuntu-specific bugs; do you think that would be different for Xubuntu?
[21:33] <_MMA_> And like Colin said this system is dated.
[21:34] <_MMA_> Main vs. Universe and all.
[21:34] <cjwatson> because there are lots of derivatives out there that aren't in our archive and where we don't do the CD builds
[21:34] <somerville32> Mithrandir, No but I'm tired of people saying Xubuntu isn't an official Ubuntu derivative because Canonical doesn't sell support for it.
[21:34] <somerville32> Xubuntu should be an official derivative because "Ubuntu" say so.
[21:34] <somerville32> *says
[21:34] <lifeless> Mithrandir: I think thats really the biggest point; our devs that are not using packs don't even notice issues with packs.
[21:34] <_MMA_> lol You to? ;)
[21:34] <cjwatson> somerville32: I agree.
[21:35] <lifeless> Mithrandir: now that I'm finally kicking enough devs into dogfooding, voila, bugs appear and are getting fixed.
[21:35] <cjwatson> but I do not think that that has to equate to it being in main
[21:35] <Mithrandir> lifeless: the same goes for more or less anything.  It's not like many people in core-dev do anything about our emacs bugs.
[21:35] <Mithrandir> (since quite a lot of them use vi/vim)
[21:35] <lifeless> Mithrandir: sounds like core-dev have good taste :)
[21:35] <_MMA_> somerville32: Why does it matter if they say that? :)
[21:35] <somerville32> _MMA_, Because then Xubuntu doesn't get listed in news releases, documents, help files, etc.
[21:36] <Mithrandir> lifeless: :-P
[21:36] <_MMA_> somerville32: You know what Ubuntu Studio says when asked? "Ubuntu Studio is as official as Xubuntu." :D
[21:36] <somerville32> Xubuntu is as official as Kubuntu
[21:36] <cjwatson> news releases are typically from Canonical, so I'm not 100% sure about those, but all the others could easily be addressed
[21:36] <somerville32> P
[21:37] <_MMA_> somerville32: Not so. Or else we wouldnt be having this chat.
[21:37] <somerville32> The only difference between Kubuntu and Xubuntu at this point is that Canonical does not sell support and it is not hosted on r.u.c
[21:37] <cjwatson> this began because Xubuntu isn't on releases.u.c; but nor are Ubuntu DVDs, and Canonical even sells those!
[21:37] <_MMA_> Or press disks.
[21:37] <cjwatson> (at cost)
[21:38] <somerville32> And r.u.c, IIUC, is Ubuntu ran and not Canonical (although financed by it).
[21:38] <cjwatson> so being on releases.ubuntu.com or not is not an indicator of *anything*
[21:39] <somerville32> cjwatson, Well, it would be awfully helpful for Xubuntu to be on there so we can use the launchpad mirror tool thinger.
[21:39] <cjwatson> it could be taught to run over the cdimage mirrors
[21:40] <somerville32> So, what is the problem exactly with putting Xubuntu on there? We already get lots of mirrors from cdimage
[21:40] <cjwatson> I'm sorry, but it is not going to be possible to add every derivative to releases.ubuntu.com
[21:40] <slangasek> the criteria for r.u.c are roughly, "it's frequently downloaded and the mirrors have room for it"
[21:40] <cjwatson> and "supported by Canonical" is a good line
[21:40] <somerville32> cjwatson, I think it makes sense that the official derivatives are the mainstream desktop environments
[21:40] <slangasek> (at least currenty)
[21:40] <joejaxx> somerville32: ?
[21:41] <cjwatson> somerville32: Mythbuntu and Ubuntu Studio probably won't like that definition so much
[21:41] <cjwatson> and what about Gobuntu? Fluxbuntu?
[21:41]  * _MMA_ doesnt care. ;)
[21:41] <cjwatson> we just can't host everything on releases
[21:41] <somerville32> One could argue that Mythbuntu is Xubuntu or Ubuntu depending on the DE used
[21:41] <somerville32> I like where Edubuntu is going
[21:42] <somerville32> Becoming a "module" and not an official derivative
[21:42] <joejaxx> somerville32: most ubuntu derivatives are actually about a purpose and not necessarily the desktop environment
[21:42] <joejaxx> :P
[21:42] <jdong> Is anyone currently here able to do a give-back/retry-build/whatever-its-called?
[21:42] <joejaxx> even though the naming scheme is what it is traditionally
[21:42] <Mithrandir> jdong: yes, quick before I go to bed.
[21:42] <jdong> Mithrandir: faad2 on all bug i386,ppc
[21:42] <jdong> but*
[21:43] <jdong> FTBFS was due to broken xmms2 which was fixed a week and a half ago
[21:43] <Mithrandir> jdong: given-back
[21:43] <jdong> Mithrandir: thanks!
[21:43]  * Mithrandir goes to bed
[21:43] <jdong> night! :)
[21:44] <cjwatson> somerville32: "official" does not equate to "on releases.ubuntu.com". I'm happy to add language to the releases.ubuntu.com front page to clarify this, and am open to suggestions on that front
[21:44] <_MMA_> somerville32: Ubuntu Studio is also watching how Edubuntu is going. But in the end, all the derivatives, "official" or not could also go that way.
[21:44] <somerville32> cjwatson, Why not remove kubuntu and edubuntu and just have Ubuntu there then?
[21:44] <cjwatson> somerville32: Kubuntu and Edubuntu are heavily enough downloaded to make it worthwhile, AIUI
[21:45] <cjwatson> releases.ubuntu.com is the high-bandwidth site
[21:45] <somerville32> cjwatson, I was told by canonical sys-admins we had to start using mirrors because we were too much of a resource drain on cdimages.
[21:45] <somerville32> cjwatson, Xubuntu is heavily downloaded.
[21:46] <joejaxx> somerville32: maybe it is not as high as {ed,k,ubuntu} ;)
[21:46] <cjwatson> Canonical sysadmins need to talk to me directly about this sort of thing rather than via a proxy if it's their instruction that Xubuntu move
[21:46] <cjwatson> and they know how to do so :)
[21:46] <somerville32> cjwatson, We're using mirrors of cdimage
[21:46] <cjwatson> (well, me or another cdimage admin)
[21:46] <cjwatson> it's a good idea for *everyone* to use releases, even Ubuntu
[21:47] <cjwatson> err
[21:47] <somerville32> cjwatson, So I don't know why being on r.u.c and using the mirrors of release is a big difference
[21:47] <cjwatson> that wasn't what I meant to say
[21:47] <cjwatson> it's a good idea for *everyone* to use mirrors, even Ubuntu
[21:47] <cjwatson> Ubuntu release announcements cite mirrors
[21:47] <cjwatson> adding Xubuntu to releases.ubuntu.com would directly reduce the number of releases.ubuntu.com mirrors.
[21:47] <cjwatson> we already moved edgy off to old-releases (even though that's not strictly accurate) to try to save space there
[21:48] <cjwatson> even though edgy is still supported
[21:49] <somerville32> My question is what is so special about Kubuntu compared to Xubuntu from the "Ubuntu" perspective and not Canonical's.
[21:49] <somerville32> And I'm sorry to be sticking such tough questions :]
[21:50] <somerville32> It Is just that I help develop Xubuntu and I want to see it in the same light (from the community perspective) as Kubuntu is for obvious reasons
[21:50] <Lure> somerville32: afaik, Canonical is providing commercial support for kubuntu (at least mark said so on several occasions)
[21:50] <cjwatson> it is still the case that Kubuntu is very substantially more popular than Xubuntu
[21:51] <cjwatson> I think Xubuntu is an excellent valuable project and I want to see it succeed
[21:51] <_MMA_> somerville32: I would totally say "from the community perspective" Xubuntu is viewed in the same light. I do.
[21:51] <cjwatson> I just don't think that being in main and being on releases.ubuntu.com are necessary conditions for that, and in the former case, I think it's actively harmful to Xubuntu to have the extra constraints on it that are imposed by being in main
[21:51] <cjwatson> (at present)
[21:52] <cjwatson> I have put a non-trivial amount of time into helping Xubuntu out, and Canonical has contributed quite a bit in the way of resources to it
[21:52] <somerville32> I've just worked really hard to improve the "official status" of Xubuntu since dapper and I'd hate to see things take a step back by demoting to main. I've already seen other developers in other channels discussing our discussion with the same attitude I fear - that not being in Main means it isn't supported.
[21:53] <cjwatson> that attitude needs to be fixed
[21:53] <cjwatson> I think that moving Xubuntu will help it be fixed
[21:53] <Lure> somerville32: maybe it would be good if Ubuntu (foundation) would give "official" status from community (and not commerical, Canonical) perspective - is this what you are asking for?
[21:53] <cjwatson> because it will allow us to make the main == Canonical-support thing really clear
[21:53] <cjwatson> Lure: the Ubuntu Foundation would better be called the Ubuntu Trust
[21:54] <cjwatson> it does not play an active role, and will not unless Mark is hit by a bus and Canonical's funding dries up
[21:54] <cjwatson> it's an insurance policy
[21:54] <Lure> cjwatson: I understand that that is what it is currently, but it may be that we need some offical body
[21:54] <somerville32> It is called the Community Council, Lure
[21:54] <somerville32> I do plan to write a spec outlining some of these issues though
[21:54] <Lure> cjwatson: maybe community council/TB would approve distros similar to LoCo's...
[21:55] <somerville32> I've already spoken with Jono and some of the CC members about it
[21:55] <cjwatson> Lure: Xubuntu is already an official team, AFAIK
[21:55] <cjwatson> but sure, maybe some such body could ratify derivatives as official
[21:55] <cjwatson> meaning that they meet some minimum level of quality control and engagement with the development community
[21:55] <cjwatson> I'd be all for that
[21:55] <Lure> cjwatson: that would help with "official", which is point of confusion here
[21:56] <_MMA_> cjwatson: Does it really matter though. I havent done it with Ubuntu Studio?
[21:56] <joejaxx> somerville32: what would the result be though? other than what Xubuntu is already? :)
[21:56] <somerville32> joejaxx, Clear up confusion.
[21:56] <somerville32> Trust me. There is a _lot_ of confusion.
[21:56] <_MMA_> From who?
[21:56] <somerville32> Developers and users
[21:57] <_MMA_> But what does it get you? Tell them and move on. :)
[21:57] <jcastro> we talked a bit about this at uds, how to better communicate common derivative issues with canonical.
[21:57] <cjwatson> _MMA_: it seems to matter to somerville32, and it seems like it could help
[21:57] <jcastro> so that developers know that "derivatives want foo", not "this derivative wants, foo, this one wants bar, this one wants baz."
[21:58] <_MMA_> somerville32: If anyone stops working on/using Xubuntu because of a "unofficial" perception Id say let it go.
[21:58] <cjwatson> of course there'd have to be some kind of process where we ratified a bunch of the existing projects at once, otherwise those not included in the initial pass would be disadvantaged
[21:58]  * somerville32 nods.
[21:58] <somerville32> I think setting up clear community policies and processes for derivatives is an excellent idea.
[21:58] <_MMA_> cjwatson: I know it matters to Cody but I just fail to see how it matters. :)
[21:59] <_MMA_> somerville32: _1
[21:59] <_MMA_> gah
[21:59] <_MMA_> +1
[21:59] <Kmos> cjwatson: edgy is at top "The following releases of Ubuntu are available:
[21:59] <Kmos> but not at directorys in bottom
[21:59] <Lure> kubuntu positioning is also discussed quite some recently and clear statement from both commercial (Canonical) as well as community (CC/TB) would be good
[21:59] <cjwatson> I think perhaps if you're coming from outside the Ubuntu project it's unclear what is a project done by the Ubuntu developer community and what is an external project with unclear support and status
[21:59] <cjwatson> Kmos: yep, I'm fine with that
[22:00] <cjwatson> follow the link and note the different URL
[22:00] <cjwatson> "Although they are not directly supported by Canonical, releases of Xubuntu are available from the cdimage server."
[22:00] <cjwatson> could somebody suggest better text for that?
[22:00] <cjwatson> it probably isn't helping
[22:01] <_MMA_> cjwatson: Sure. We've had our fair share of that. We say Canonical doesnt sell support nor press disks. Usually settles things.
[22:01] <ScottK> cjwatson: How about directly/commercially?
[22:01] <slangasek> cjwatson: "we are happy to also provide hosting for the following community projects via the cdimage server:" ?
[22:02] <slangasek> s/community/community-supported/
[22:02] <cjwatson> I had done something else, but Steve is a good wordsmith as always
[22:02] <slangasek> heh
[22:02] <somerville32> I hate the "community projects"
[22:02] <_MMA_> somerville32: Why?
[22:02] <somerville32> Ubuntu is a community project
[22:02] <somerville32> Kubuntu is a community project
[22:03] <cjwatson> "for the following projects via the cdimage server; they are not commercially supported by Canonical but receive full support from their communities"
[22:03] <cjwatson> or some such
[22:03] <slangasek> somerville32: "community-supported" was what I'd originally intended, is that better?
[22:03] <mpt> This discussion needs a Venn diagram
[22:04] <somerville32> For me, I feel alienated when there is a distinction made.
[22:04] <somerville32> The ubuntu community its self should not be divided up because of where Canonical decides to place its money.
[22:04] <cjwatson> I'm afraid we have to make the distinction clear
[22:05] <cjwatson> how's the wording on http://releases.ubuntu.com/ now?
[22:05] <elmo> somerville32: it's not about Canonical's money
[22:05] <cjwatson> formatting perhaps isn't ideal
[22:05] <ScottK> And there's the other end of the spectrum to be clear about too.  Projects like Getdeb are NOT part of Ubuntu even though they happen to use LP.
[22:05] <elmo> somerville32: Ubuntu relies on a worldwide network of mirrors, 99.9% of which are outside of Canonical's control
[22:06] <somerville32> elmo, I fully understand why it is a problem to put more data on r.u.c
[22:06] <slangasek> somerville32: my feeling was that it's an improvement to emphasize "these projects are community supported" instead of "these projects are not supported by Canonical".  The distinction still exists whether it's stated or not, and like cjwatson I think it's something that needs to be made clear to users up front
[22:07] <Lure> cjwatson: funny, http://www.canonical.com/projects claims that xubuntu is also commercially supported by Canonical
[22:07] <Lure> cjwatson: "These derivatives are developed and supported by Canonical and the Ubuntu community."
[22:07] <cjwatson> anyway, this discussion has gone on longer than I thought it had and I've spent none of the time with my family this evening that I wanted to, so ...
[22:07] <cjwatson> Lure: thanks, that's a bug, I'll pass it on
[22:07] <somerville32> cjwatson, Sorry. Thanks for listening :]
[22:07] <mdz_> (that's probably "provides resources for" rather than "provides commercial tech support for")
[22:07] <Lure> cjwatson: thanks for spending time on this - I think it is important to have this as clear as possible
[22:07] <cjwatson> somerville32: not your fault :)
[22:08] <Lure> mdz_: you are probably right - you can also understand it like that
[22:09]  * _MMA_ did.
[22:09] <_MMA_> But Im part of the community.
[22:10] <cjwatson> bug 172672 filed
[22:10] <ubotu> Launchpad bug 172672 in canonical-website "http://www.canonical.com/projects claims that Xubuntu is supported by Canonical" [Undecided,New] https://launchpad.net/bugs/172672
[22:13] <somerville32> cjwatson, Would you be able to put some weight on lp to adapt mirror probing for cdimages? :]
[22:14] <cjwatson> somerville32: elmo would know more about the issues there than I
[22:14] <cjwatson> I'm happy to support it where I can but I don't know what's involved
[22:15]  * somerville32 nods.
[22:25] <lamont> dear release team... can I please have git-core 1.5.$something in {dapper,edgy} backports, too?
[22:25] <lamont> 1.4 is "teh suck"
[22:25] <ScottK> lamont: Did you bug jdong?
[22:26] <lamont> oh, is jdong the right guy to pester?
[22:26] <ScottK> I'm sure he'd much rather do that then eigen vectors or however you spell it.
[22:26] <ScottK> For backports, yes.
[22:26] <lamont> kewl.  target acquired.
[22:26] <lamont> oh... jdong?????
[22:27] <ScottK> He did claim earlier that he really had to study,  It's at least slightly possible he was serious.
[22:29] <jdong> *cry* lamont: Hi. I am going to grab dinner and eat while handling some Ubuntu stuff, then go back to differential equations. Please leave a message after the beep: ^G
[22:31] <somerville32> Isn't it ^A for beep?
[22:31] <lamont> jdong: if I upload current git-core to dapper-gutsy backports, will you let it in?  1.4 has an absolutely sucky interface.  And, yes, 1.5 is a UI change of some significance.  OTOH, I haven't met anyone who prefers it...
[22:31] <lamont> somerville32: yes
[22:34] <slangasek> ^[beep]
[22:34]  * Fujitsu looks for the beep button.
[22:36] <lamont> slangasek: I wonder... with the LP-controls-sources.list changes, do we still have the 'can't do security with a version between release and -backports'?
[22:36]  * lamont waits for slangasek to say --> launchpad 
[22:36] <torkel> Fujitsu: it is just right to (the) any key
[22:37] <Fujitsu> lamont: I've uploaded a lot of security updates meeting that criterion.
[22:37] <Fujitsu> Wait, LP-controls-sources.list? That sounds evil.
[22:37] <lamont> Fujitsu: it beats the hell out of 'all of gutsy's pockets share one sources.list'
[22:38] <lamont> iz _GROSS_ oversimplification of the situation, but close enough
[22:39]  * Fujitsu is confused.
[22:39] <slangasek> lamont: ok, I'll say that then
[22:39] <slangasek> lamont: since I have no knowledge of the thing you're talking about :)
[22:39] <lamont> slangasek: too slow.  was already asking
[22:39] <Fujitsu> lamont: Ohhhh, on the buildds. I see.
[22:40] <lamont> Fujitsu: where else could launchpad control?
[22:40] <lamont> :-)
[22:40] <Fujitsu> lamont: LP seems to be rather far-reaching these days.
[22:40]  * lamont checks the world-domination meter.
[22:40]  * lamont -> kids.  back in a while
[22:41] <lifeless> lamont: you don't have enough already?
[22:46] <LaserJock> darn, I missed my chance to throw my $0.02USD in, stupid laser saftey inspections :/
[22:47] <Fujitsu> LaserJock: Into what? The supported discussion?
[22:47] <LaserJock> yeah
[22:48] <LaserJock> I've always wondered why all the "Canonical supported" stuff isn't on canonical.com rather than *ubuntu.com
[22:48] <LaserJock> in terms of wordage
[22:48] <LaserJock> Canonical support should be on top of what we do as a distro rather than determining it no?
[22:49] <LaserJock> so Main would be a subset of packages that Ubuntu wants to specifically support
[22:50] <jdong> lamont: yeah, sure, I go on record approving your upload of git-core :)
[22:50] <Fujitsu> LaserJock: If Canonical weren't so integrated, there would be no need for the main/universe distinction within Ubuntu.
[22:50] <LaserJock> Fujitsu: why not?
[22:51] <slangasek> the distinction would still exist, whether or not it was represented in the archive structure or upload rights
[22:51] <Fujitsu> Because it exists to delineate a support boundary.
[22:51] <LaserJock> Fujitsu: it does? and should it?
[22:51] <LaserJock> it doesn't have to
[22:51] <LaserJock> I would say that is a Canonical creation, not an Ubuntu one
[22:52] <Fujitsu> What is a Canonical creation? The support division?
[22:53] <LaserJock> the "Supported by Canonical" division
[22:53] <LaserJock> according to ubuntu.com: "The main distribution component contains applications that are free software, can freely be redistributed and are fully supported by the Ubuntu team."
[22:53] <elmo> Fujitsu: that's not true
[22:53] <elmo> Fujitsu: there are a number of reasons for the main/universe split and several of them have nothing to do with Canonical
[22:53] <LaserJock> that says to me that the *Ubuntu* team fully supports Main
[22:54] <ScottK> So who's on that team?
[22:54] <LaserJock> Core Devs
[22:54] <LaserJock> going by upload rights
[22:54] <LaserJock> and the CC/TB
[22:55] <Fujitsu> elmo: What are there, other than the levels of expertise and trust possessed by the developers
[22:55] <Fujitsu> +?
[22:57] <LaserJock> this is why I've not liked the Main == Canonical supported, Universe == community supported
[22:57] <LaserJock> Canonical should define what it's going to support, and Main makes sense for that
[22:57] <elmo> Fujitsu: off the top of my head, it allows for multiple levels of developers, as you say (nothing to do with Canonical); it allows for a sane release process (nothing to do with Canonical); it gives users clear hints when they have option between otherwise equal choices of software (nothing to do with canonical)
[22:58] <LaserJock> but I don't see how that should determine what a component is
[23:00] <elmo> oh, it adds additional sanity checks (for software being promoted to main) beyond the (by comparison) cursory checks applied to NEW stuff
[23:00] <elmo> (nothing to do with Canonical)
[23:03] <LaserJock> that's why I kinda wonder if all the "supported" wordage kinda makes things confusing
[23:04] <LaserJock> whether Canonical provides commercial support for a component shouldn't really concern anybody unless they are looking for a support contract
[23:04] <LaserJock> so it would make sense to move that stuff to canonical.com
[23:05] <LaserJock> and not talk about that kind of thing in Ubuntu itself
[23:05] <LaserJock> or maybe I'm in lala-land and need to go back to lasers ;-)
[23:05] <Fujitsu> Or ponies :P
[23:05] <LaserJock> doh!
[23:06] <RAOF> *Laser ponies!*
[23:06] <ScottK> *Rocking Laser Ponies*
[23:06] <LaserJock> man, wouldn't that be killer, a pony with a laser on it's head!
[23:06] <ScottK> And speakers
[23:06] <LaserJock> Unicorn 2.0 ;-)
[23:07] <RAOF> Maybe you could get it to breathe fire while you're at it :)
[23:07] <LaserJock> "horns are so 1.0, lasers are the way of the future"
[23:08] <soren> Am I the only one with gstreamer issues today?
[23:08] <slangasek> can anyone explain to me why packages should want to use log_success_msg in init scripts for usage messages, instead of plain old echo?
[23:08] <ScottK> soren: IIRC Hobbsee was complaining about it ~10 hours ago or so.
[23:08] <Fujitsu> ScottK: AFAIK that was just because we moved back to XAA, which doesn't do Xv.
[23:09] <Fujitsu> slangasek: LSB compliance, no?
[23:09] <ScottK> slangasek: I'm thinking "Because the package they copies the init from did it that way".  How about that for a reason?
[23:09] <ScottK> copies/copied
[23:09] <soren> Erm. no.
[23:09] <slangasek> given that the usage info should never be triggered under init or upstart, and therefore not have to interact with usplash, I can't see why you would want to use anything but "echo"
[23:10] <slangasek> ScottK: this is in an Ubuntu delta
[23:10] <soren> It's to apply a consistent type of formatting to messages from init scripts.
[23:10] <Fujitsu> slangasek: True.
[23:10] <slangasek> Fujitsu: can you please offer a citation for the claim that this is relevant to LSB compliance?
[23:10] <ScottK> There's always perceived LSB compliance.
[23:10] <Fujitsu> Aren't those functions there for that sort of thing? I thought they were, but I'm probably wrong.
[23:11]  * ScottK needs to go make dinner for the children before they riot.  See you all later.
[23:11] <slangasek> Fujitsu: log_success_msg is for logging information about a success.  A usage message doesn't look like success to me? :)
[23:11] <Fujitsu> slangasek: Right.
[23:12] <slangasek> "The log_success_msg function shall cause the system to write a success message to an unspecified log file. The format of the message is unspecified. The log_success_msg function may also write a message to the standard output."
[23:12] <slangasek> so by my reading, this is the wrong thing to use for usage output
[23:12] <slangasek> I mean, at least it should be log_warning_ or log_failure_
[23:12] <soren> slangasek: Ah... I don't know how I missed the "for usage messages" in your original question. :)
[23:12] <Fujitsu> Right, that looks very wrong, then.
[23:12] <slangasek> ok
[23:13] <slangasek> fwiw, a minority of init scripts on my system use this for usage, a majority just use echo
[23:13] <slangasek> so I'll just drop this part of the delta for the next round
[23:13] <soren> slangasek: Which packages?
[23:13] <slangasek> soren: samba :)
[23:13] <slangasek> soren: or do you mean, what are all the packages that use it?
[23:13] <soren> slangasek: No, the last 's' was indeed a typo :)
[23:37] <Amaranth> Ng: Does the window menu work when a window isn't decorated in metacity?
[23:38] <Amaranth> Need to decide if the fix is to make the window menu work or make the segfault go away
[23:39] <lifeless> Amaranth: quotes page!
[23:39] <Amaranth> lifeless: ?
[23:40] <lifeless> you can rephrase your comment as 'decide if the fix is to fix it or fix it'
[23:40] <Fujitsu> How big is the quotes page these days?
[23:41] <lifeless> its <------------------------------>
[23:42] <Fujitsu> I see.
[23:42] <soren> (not to scale)
[23:43] <Fujitsu> I would never have guessed.
[23:43]  * jdong stifles a few grins and goes back to exam review
[23:47]  * LaserJock wonders what happens when the quotes page gets to be bigger than 80 characters wide
[23:48] <Fujitsu> LaserJock: Then you change the scale, of course.
[23:48] <LaserJock> ah
[23:48] <LaserJock> I was thinking maybe word-wrap, but changing the scale makes sense