[00:09] <somerville32> RAOF, I keep getting 404s when I build :(
[00:15] <wolfgang> look that- http://wolfgang-city.myminicity.com/
[00:17]  * somerville32 sighs.
[00:17] <somerville32> 0.3-0ubuntu2 IS listed on +packages for some reason (and now 0.3-0ubuntu1 is gone).
[00:18] <Fujitsu> somerville32: That's LP magic.
[00:18] <Fujitsu> It's because you're the maintainer.
[00:20] <Fujitsu> And bug #125987.
[00:20] <ubotu> Launchpad bug 125987 in soyuz "Some uploads missing from +packages" [Medium,Confirmed] https://launchpad.net/bugs/125987
[01:56] <LaserJock> is there any way to check why a package is uninstallable without actually installing it?
[01:59] <slangasek> run something like edos's software over the archive? :)
[02:13] <minghua> LaserJock: Does "ask someone else to test installing it" count? :-P
[02:20] <LaserJock> minghua: no, not really
[02:20] <LaserJock> I don't mind doing it in general
[02:20] <LaserJock> but some of my edubuntu metapackages show up
[02:23] <LaserJock> seems like qa.ubuntuwire.com/debcheck has what I want
[02:25] <somerville32> LaserJock, want to do a quick/super-fast sponsorship? :]
[02:25] <LaserJock> hmm, depends ;-)
[02:26] <LaserJock> somerville32: what's up?
[02:28] <minghua> LaserJock: I thought debcheck only checks dependency-related un-installable problems, and it can't check maintainer script related un-installable problems.
[02:28] <somerville32> LaserJock, bug #176467 but I've got a new debdiff coming up in a sec
[02:28] <ubotu> Launchpad bug 176467 in gnomescan "Sponsor gnomescan_0.4.1-0ubuntu4" [Wishlist,Confirmed] https://launchpad.net/bugs/176467
[02:29] <minghua> Am I wrong?
[02:29] <LaserJock> minghua: sounds reasonable
[02:29] <LaserJock> we'd need like piuparts for a full check I think
[02:30] <somerville32> LaserJock, uploaded.
[02:30] <minghua> LaserJock: I think so.  But wasn't there an email recently about piupart testing for the whole archive?
[02:36] <LaserJock> somerville32: hmm, that seems like stuff that should be done upstream
[02:36] <somerville32> LaserJock, How so?
[02:37] <LaserJock> somerville32: why should we be maintaining that diff?
[02:37] <somerville32> LaserJock, the diff is in debian/
[02:38] <somerville32>    * debian/watch: Created watchfile
[02:38] <somerville32>    * debian/changelog: Fixed encoding issue.
[02:38] <LaserJock> right
[02:38] <LaserJock> but Debian should have that, not us
[02:38] <somerville32> LaserJock, Look at the version of the package
[02:39] <LaserJock> heh ...
[02:39] <LaserJock> then my question's gonna be, why isn't this package in Debian? ;-)
[02:40] <somerville32> LaserJock, I dunno. Persia wants all packages unique to Ubuntu to have watchfiles
[02:40] <somerville32> so I'm just doing his bidding :P
[02:41] <LaserJock> right
[02:48] <somerville32> LaserJock, Did you unsubscribe u-u-s?
[02:48] <LaserJock> yeah
[02:48] <LaserJock> cause I'm gonna upload it
[02:49] <somerville32> ok
[02:49]  * Fujitsu thinks a per-package whiteboard would be nice.
[02:50] <LaserJock> yeah, I said that a long time ago ...
[02:56] <persia> Ubulette: I tend to be very team-focused.  Please feel free to ask any sponsor for a review after adjusting for my changes, or for any questions you may have.  If I'm around, I'll also answer, and once it turns up again as oldest in FIFO, I'll hit it again.
[02:57] <Ubulette> persia, nm, asac sponsored it
[02:57] <persia> Ubulette: Excellent.  That's efficiency: when he's busy, I review, and when I'm busy, he uploads.
[03:00] <Ubulette> efficient, depends. i've done those changes ~5 days ago. but nm, i'm probably too demanding.
[03:03] <somerville32> LaserJock, how goes it?
[03:04] <LaserJock> somerville32: done
[03:04] <persia> Ubulette: More efficient than waiting for me to look at it again :)
[03:04] <somerville32> LaserJock, How long ago?
[03:05] <somerville32> LaserJock, I don't see it
[03:05] <LaserJock> like a minute
[03:05] <somerville32> ok
[03:12] <ScottK> If there's anyone about (like maybe Ste
[03:12] <ScottK> ...
[03:12] <ScottK> StevenK) who know about Perl stuff....  I'm looking for a point to docs on how to add POD documentation to a Perl package (upstream, not Debian packaging)
[03:12] <ScottK> Help
[03:14] <persia> ScottK: Do you mean just adding the POD clauses to the source?
[03:15] <persia> Or do you mean extracting it for export to other tools?
[03:15] <ScottK> Adding POD clauses to the source.
[03:15] <persia> ScottK: man perlpod
[03:15] <ScottK> persia: Thanks.
[03:16] <persia> ScottK: There may be some magic I don't understand to make that useful :)
[03:16] <ScottK> OK.  Well it's a start.
[03:17] <ember> i've got a few packages on queue if anyone wanna check
[03:17] <ember> bug #174467
[03:17] <ubotu> Launchpad bug 174467 in gnome-schedule "Please sponsor gnome-schedule-1.2.1 into Hardy" [Wishlist,New] https://launchpad.net/bugs/174467
[03:20] <persia> ember: By my count, you're currently at spot 17 in the FIFO queue.  Shouldn't be terribly long.
[03:21] <ember> heh that one have 10 days, seb already reviewed but forgot to upload it
[03:22] <persia> ember: The way I count, a review or comment resets, which skews things for cases like that :(
[03:23] <ember> humpfh, lol.
[03:24] <LaserJock> persia: do you think it'd be reasonable to have a PTS-like interface on qa.ubuntuwire.com?
[03:24] <persia> LaserJock: Could you expand on that a little?
[03:25] <LaserJock> well, rather than having lists of packages and looking by "issue"
[03:25] <persia> (more specifically, explain how it differs from packages.ubuntu.com or launchpad.net/ubuntu/+source/foo)
[03:25] <LaserJock> I'd like to put in a package name and see all the available info
[03:25] <LaserJock> umm, we none of those have QA
[03:25] <LaserJock> *well
[03:26] <persia> LaserJock: Ah, so you want to see info about FTBFS, lintian, NBS, etc from a per-package overview page?
[03:26] <LaserJock> yes
[03:26] <Fujitsu> Like http://qa.debian.org/developer.php?
[03:26] <persia> LaserJock: That makes sense.  If you can get a POC running on people.ubuntuwire.com, I don't see any reason it can't later get included on the QA page.
[03:27] <LaserJock> Fujitsu: pretty much yeah
[03:27] <LaserJock> persia: POC?
[03:27] <crimsun> proof of concept.
[03:28] <persia> LaserJock: Proof-of-concent
[03:28] <LaserJock> oh, right
[03:28] <persia> LaserJock: Also, I'd personally prefer limiting that list in most cases to Ubuntu-unique & orphaned packages, as I don't think we yet have the resources to chase all the QA stuff in Debian (NBS & FTBFS stuff aside)
[03:29] <LaserJock> persia: all I want is the stuff we already have on qa.ubuntuwire.com
[03:29] <LaserJock> just on a per/package basis
[03:30] <persia> LaserJock: That's just a pointers page.  Half the stuff is LP or p.u.c, and the other half scripts that point to different subsets of the archive.  There's no central organisation.
[03:30] <LaserJock> that's what I'm getting at basically
[03:30] <minghua> persia: For example, http://packages.qa.debian.org/s/scim.html, if you don't know what PTS is exactly.
[03:31] <persia> minghua: Yep: it's my primary source of info about Debian packages :)
[03:31] <minghua> persia: It pretty much has all the links related to a certain package.
[03:31] <minghua> persia: Okay, just to be sure you are LaserJock are talking about the same thing...
[03:31] <persia> minghua: At issue is that it's a big effort, and in many ways duplicates Debian.  I'd prefer to see us concentrate on the non-Debian stuff and the broken-when-imported-to-Ubuntu stuff.
[03:32] <LaserJock> persia: all I'm talking about is data we *already* have on qa.ubuntuwire.com
[03:33] <guest22> Any MOTUs here who would be willing to review a newly uploaded package - "photoml" at http://revu.tauware.de/details.py?upid=998? (This upload corrects the problems pointed out by norsetto earlier today.)
[03:34] <persia> LaserJock: Right, but as I said, half of that is hosted by Canonical, and the rest is all separate scripts.  If someone were to organise it, and generate a sample (people.ubuntuwire.com might be a good place), and people found it useful, I don't see any reason not to add another link on the QA page.
[03:34] <LaserJock> persia: right
[03:35] <LaserJock> do we have a list of where the scripts are maintained?
[03:38] <persia> LaserJock: For UW-hosted stuff, Fujitsu does UEHS, debcheck, lintian, and MDT.  I think geser adopted FTBFS, and ajmitch does RCbugs.  For the rest, I'm not sure, but I think pitti does NBS, keybuk does MoM, pitti does SRUs, and mvo does conflict-checker (although I may be mistaken)
[03:39] <persia> (and LP stuff is just special searches)
[03:40] <LaserJock> thanks
[03:40] <crimsun> (I think Steven does NBS.)
[03:41] <crimsun> Steve, that is.
[03:41] <crimsun> argh
[03:41] <persia> crimsun: manages the NBS generation script?  Thanks for the correction.
[03:43] <persia> LucidFox: No need to mention that something is in incoming.d.o in a sync request: between U-U-S and U-A delays, it almost certainly won't be by the time the request gets processed.
[03:46] <imbrandon> hrm, a PTS like interface on a per package basis would be nice
[03:47] <cheguevara> imbrandon, just in case you didn't notice there are 2 patches on the novell bugzilla that need to be applied, sorry i didn't make it clear
[03:47] <imbrandon> cheguevara: i seen that, thanks
[03:47] <cheguevara> kk, just checking :P
[03:48] <LaserJock> imbrandon: it'd be really nice if Launchpad did it for us
[03:48] <imbrandon> LaserJock: you can also cat the apache config for qa.uw.c on orko to see where the scripts are housed, it should be readable
[03:48] <imbrandon> just fyi
[03:48] <persia> LaserJock: Yes, but LP would have to have all the other bits as well, or be linking outside LP.
[03:49] <imbrandon> LaserJock: it would be really nice but i dont count on LP to provide anything other than whats already there, we cant modify it when needed etc
[03:50] <imbrandon> and realy actualy against adding things to it untill it is made floss
[03:50] <imbrandon> and stablized
[03:50] <persia> imbrandon: That's not fair to the LP developers.  They do make changes, and some of those changes are helpful.  Doesn't mean we wait before writing other tools.
[03:51] <imbrandon> yea sorta heh ...
[03:52] <LaserJock> persia, imbrandon: I know I'm just saying that if they want to support distros these kinds of tools would be nice
[03:52] <imbrandon> LaserJock: definately
[03:52] <persia> LaserJock: Agreed.  File some wishlist bugs or write some specs :)
[03:53] <LaserJock> hmm, does apt-cacher handle multiple releases?
[03:54] <ScottK> imbrandon: Of course there's the things we rely on in LP that LP developers unknown to us consider bugs and take away.
[03:54] <LaserJock> or any apt caching app
[03:54] <imbrandon> LaserJock: a mirror or squid probably, i doubt others
[03:55] <minghua> LaserJock: I know apt-proxy does.
[03:55] <LaserJock> I've got 3 machines at home and with all the pbuilders and chroots I'm wasting a lot of time/bandwidth
[03:55] <persia> LaserJock: The web tools do, the local tools don't.
[03:55] <Fujitsu> I use apt-cacher, and it works fine over multiple releases.
[03:55] <minghua> LaserJock: I'm not sure it qualifies your "apt caching app" though.
[03:56] <Fujitsu> If I were to tell it to do Debian too, it would probably get mighty confused, but that particular instance doesn't do Debian stuff.
[03:56] <minghua> Is there recently any discussion about updating texlive-base in gutsy?
[03:57] <ScottK> minghua: IIRC it was mentioned on #ubuntu-devel earlier today.
[03:57]  * persia thinks that was for a sync for hardy
[03:57] <LaserJock> minghua: no why?
[03:57] <minghua> ScottK: Thanks, I'll go read the log.
[03:57] <persia> LaserJock: ML discussion on u-d-d about it being broken
[03:57] <LaserJock> :/
[03:58] <minghua> LaserJock: bug 174569
[03:58] <ubotu> Launchpad bug 174569 in texlive-bin "postinst failure during gutsy security update" [Undecided,Fix released] https://launchpad.net/bugs/174569
[04:01] <minghua> ScottK: It was a different issue on #ubuntu-devel earlier, unfortunately.
[04:01] <ScottK> minghua: Sorry for the distraction then.
[04:02] <LaserJock> minghua: what was the problem earlier?
[04:02] <minghua> ScottK: No problem, at least it gives hints who care about texlive... :-)
[04:02] <minghua> LaserJock: Hardy issues, bug 176411, for instance.
[04:02] <ubotu> Launchpad bug 176411 in texlive-bin "[Sync request] Sync texlive-bin (2007.dfsg.1-2) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/176411
[04:02] <LaserJock> I have such a love-hate relationship with TeX
[04:04] <LaserJock> I'm not sure we can SRU all of -11
[04:04] <minghua> LaserJock: I think I can cherry-pick the patch if there is interest for a SRU.
[04:05] <minghua> It will be quite a PITA to test, though...
[04:05] <LaserJock> seems like we can't go a release without breaking something in TeX
[04:05] <LaserJock> :/
[04:05]  * minghua doesn't even have texlive installed on his gutsy.
[04:05] <LaserJock> I do for my dissertation
[04:06]  * minghua writes papers on his Debian. :-)
[04:07] <imbrandon> ugh, 9 to 12 inches of snow called for tonight over the next 12 hours
[04:07] <imbrandon> fun fun fun
[04:08]  * persia misses snow
[04:08]  * imbrandon dosent
[04:08]  * Fujitsu does too. No snow here in... well, we had a tiny bit about a decade ago.
[04:09]  * imbrandon is suprised Fujitsu rembers a decade ago :)
[04:09] <DarkMageZ> imbrandon, what's this snow you speak of?
[04:13]  * minghua misses snow as well.
[04:22] <guest22> Since my previous request seems to have been made during the middle of a discussion, let me try again. Any MOTU here willing to review a recently uploaded package ("photoml")?
[04:23] <somerville32> guest22, I'm not a MOTU but I'll review for you
[04:26] <guest22> somerville32: thanks - I'd appreciate your comments.
[04:42] <tritium> hi jsgotangco
[04:43] <StevenK> ScottK: Do you still need help?
[04:44] <ScottK> StevenK: I think persia gave me enough of a hint to at least give it a shot.  Thanks.
[04:44] <persia> StevenK: Are you maintaining NBS now?
[04:50] <StevenK> persia: I'm doing NBS stuff, yes
[04:51] <persia> StevenK: I was more talking about the generation scripts, rather than the work described, but if the answer is still yes, I'd be curious if you'd find http://people.ubuntuwire.com/~dktrkranz/NBS/ (or extensions thereof) useful.
[04:53] <StevenK> I'll have a poke. I've written my own tools anyway. :-)
[04:53] <persia> StevenK: Do you have a pointer to your tools?
[04:54] <StevenK> No, they're local, and I'm not really comfortable enough with them to have other people using them.
[04:54] <persia> StevenK: Fair enough :)
[04:54] <StevenK> They work for me since they're written to deal with the way I work.
[05:16]  * persia encourages all contributors to add a Debian bug task when the bug is also submitted to debian.
[05:31] <bluefoxicy> argh
[05:31] <bluefoxicy> this crappy printer config...
[05:31]  * bluefoxicy goes to get the old one
[05:31] <bluefoxicy> gnome-cups-ui actually works ~_~
[05:32] <bluefoxicy> gnome-cups-manager rather
[05:33] <bluefoxicy> oh THAT was the problem, stupid system-config-printer PAUSED MY PRINTER and doesn't tell you that it's paused
[05:33] <bluefoxicy> remind me again WHY this worthless crap was put in Gutsy in place of something that actually works?
[05:36] <bluefoxicy> looks like it has the ability to configure a bunch of options like paper margins and such that I don't see a need for (that's openoffice's job), and also (uniquely) to configure the printer to always print classified/top secret/etc banners (my house isn't a cleared facility, if I need to print something classified here something is wrong)
[05:36] <joejaxx> who is steven langasek?
[05:36] <persia> joejaxx: One of the archive-admins
[05:36] <ScottK> joejaxx and persia: He's the Ubuntu release manager
[05:37] <ScottK> Not actually an archive admin.
[05:37] <ScottK> Also vorlon in Debian.
[05:37] <joejaxx> what is his irc nick?
[05:37] <joejaxx> :)
[05:37] <ScottK> slangasek: joejaxx is looking for you.
[05:37] <persia> ScottK: https://launchpad.net/~vorlon/+participation
[05:38] <joejaxx> oh no i was not really i was just wondering who has was
[05:38] <DoubleDave> good evening
[05:38] <joejaxx> since he was doing release engineering for ubuntu
[05:38] <persia> joejaxx: Long-time release manager for Debian, now also doing release management for Ubuntu.
[05:38] <joejaxx> oh ok
[05:39] <persia> good evening DoubleDave
[05:40] <joejaxx> i do not feel so well :\
[05:40] <DoubleDave> have a couple of questions about lintian if anyone can lend some advice
[05:40] <persia> DoubleDave: You'll do best to just ask the questions :)
[05:40] <joejaxx> persia: i think i am going to go for motu next release cycle
[05:40] <joejaxx> :)
[05:41] <joejaxx> Hobbsee: minghua hello :)
[05:41] <persia> joejaxx: Cool!
[05:41] <DoubleDave> k i'm building a deb package for  ubuntu to eventually go into the cononical repo
[05:41] <minghua> Hi joejaxx.
[05:41] <DoubleDave> running lintian on it though reports that there is a file in an unusual directory /opt
[05:41] <DoubleDave> my whole package is being installed into opt
[05:42] <joejaxx> oh
[05:42] <persia> DoubleDave: Ubuntu doesn't generally use anything in /opt.  Why are you installing there?
[05:42] <joejaxx> interesting
[05:42] <DoubleDave> seems trivial that I would get an error from lintian regarding this
[05:43] <DoubleDave> persia: just to keep the users system clean I suppose
[05:43] <persia> DoubleDave: That's why we package things.  It allows software to be installed in the default locations, and cleanly uninstalled later.
[05:43] <DoubleDave> do you know if they will reject the package because of that?
[05:43] <Hobbsee> heya joejaxx!
[05:43] <persia> DoubleDave: I would, although I can't speak for everyone.
[05:44] <DoubleDave> well its a custom package its our own software so that just where we started installing it on other systems
[05:45] <DoubleDave> im used to slackware so the whole debian policy is a little strange to me I guess
[05:45] <persia> DoubleDave: For unpackaged software, /opt can be a real benefit.  Once it gets packaged, the inconveniences of /opt outweigh the benefits.
[05:46] <DoubleDave> persia: not arguing here just curious. what would be inconvenient about it?
[05:47] <persia> With an /opt configuration, the user must reconfigure some of their basic utilities to use that configuration, which is lots easier than trying to individually deal with the random files all over the place.  Once the user can use a package manager, there is no need for the user to care where the binaries are kept, so it's best to make it so they don't need to reset their $PATH, etc.
[05:47] <minghua> persia: I'm pretty sure packages that install to /opt will be rejected, violating FHS and stuff, you know.
[05:48] <persia> minghua: I'd tend to agree.
[05:48] <LaserJock> according to FHS, "/opt is reserved for the installation of add-on application software packages."
[05:48] <DoubleDave> what would be considered ad on and what is FHS?
[05:48] <DoubleDave> sorry can you tell im a newb
[05:48] <persia> LaserJock: I guess the question is whether a given package should be considered "add-on".  I believe that once it is packaged in the default package manager, it's no longer "add-on".
[05:48] <persia> DoubleDave: Just new to Debian policies :)
[05:49] <DoubleDave> the package I'm building I would consider add on
[05:49] <LaserJock> DoubleDave: no problem, FHS is Filesystem Hierarchy Standard
[05:49] <LaserJock> DoubleDave: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
[05:49] <DoubleDave> persia: yes and I must admit I've been a bit lazy about reading
[05:50] <DoubleDave> thanks for your help everyone
[05:50] <LaserJock> I've seen /opt/ used for binary 3rd party software and for software that will conflict with existing system software
[05:50] <DoubleDave> I'll read that link Laser
[05:51] <StevenK> LaserJock: Ponies!
[05:51] <persia> LaserJock: I'd even recommend it as an alternative to /usr/local when it's not really local for source-available software being installed manually.  For conflicts, there's Priority: extra
[05:51] <LaserJock> persia: for co-existing conflicting software
[05:52] <LaserJock> i.e. KDE4 alongside KDE3
[05:52] <joejaxx> lol ponies
[05:52] <persia> LaserJock: If it can co-exist, it doesn't conflict.  Now, about the status of the Equestrian Academy....
[05:53] <joejaxx> Lol
[05:54] <LaserJock> persia: it can only exist in a different part of the filesystem
[05:54] <LaserJock> so it *would* be conflicting if it were to not be installed in /opt/
[05:54] <persia> LaserJock: So the heap of kde4 packages that just went through NEW all install to /opt?
[05:55] <LaserJock> no
[05:55]  * persia wants a different example
[05:55] <LaserJock> they've separated by /usr/lib/kde{3,4}
[05:56] <LaserJock> but I *have* seen it done that way for KDE4&3
[05:56] <persia> LaserJock: Right, which makes sense, and doesn't require /opt.  I can't think of a case where any package that would be in the archives by default should use /opt.
[05:56] <LaserJock> no, it shouldn't
[05:57] <persia> On the other hand, I can see many cases where an administrator would prefer /opt to /usr/local as an installation target.
[05:57] <LaserJock> I'm just saying that's often a case where /opt is used
[05:57] <LaserJock> LTSP uses /opt
[05:57] <LaserJock> for the client chroots
[05:58] <persia> That seems odd to me.  I'd have expected something under /var.
[05:58] <DoubleDave> k im back with another one
[05:59] <DoubleDave> verry good link by the way laser
[05:59] <LaserJock> DoubleDave: well, that is a widely accepted standard for *nix OSs
[05:59] <DoubleDave> persia: you mentioned trying to keep the user from change their path correct
[06:00] <persia> DoubleDave: By way of example.  There are many other things that may need adjustment to use /opt
[06:00] <DoubleDave> the package im makeing installs postgres, php, apache into opt so that it doesnt disturb any of that software already running on the users system
[06:00] <persia> DoubleDave: Why can't you use the system postgres, php, and apache?
[06:01] <DoubleDave> it runs post gres with its own socket file under opt along with apach listening on a different port
[06:01] <DoubleDave> would that be an exception
[06:01] <persia> LaserJock: Reading again, I'm still not sure about /opt for LTSP, but I can't figure out where it would go, so I'll stop complaining.
[06:01] <persia> DoubleDave: Why does it need to do that?
[06:01] <LaserJock> persia: I'm guessing that's how it ended up there
[06:02]  * persia notes that /var/lib/ would be right, if it weren't for the strange restriction to the local system.
[06:02] <DoubleDave> persia: guess now that you ask im not to sure that it does its just the way my partner built it
[06:03] <persia> DoubleDave: OK.  At this point, I think more context is required.  Is there a URL that provides information about the application?
[06:04] <DoubleDave> yes nullbound.com
[06:04] <DoubleDave> persia: its downloadable now in tar.gz form that is executable
[06:04] <DoubleDave> it installs to opt
[06:05] <DoubleDave> in my opinion its not the cleanest installer
[06:05] <DoubleDave> but it works well
[06:06] <persia> DoubleDave: So basically, this software is installed on a dedicated appliance, watches the network for stuff, and provides reports?
[06:06] <DoubleDave> yes for the most part
[06:06] <DoubleDave> it should be installed on a dedicated machine
[06:06] <joejaxx> probably do not need to install to /opt then ;)
[06:07] <LaserJock> so for you using /opt is a convenience
[06:07] <persia> DoubleDave: OK.  Personally, I believe that in such a case, it's best to have the promiscuous port on a secondary network, and use default services on the management network (which is presumably protected by other means).
[06:07] <LaserJock> it allows you to just drop in on many different distros without worrying about peculuarities
[06:07] <DoubleDave> sorry its moving pretty fast in here... Yes conveniance LaserJock as well as cleanlyness
[06:07] <persia> As a result, I'd strongly suggest using the system default services on the system default ports on the management interface (and nothing on the promiscuous interface).
[06:07] <DoubleDave> or so I thought
[06:08] <persia> This means your software only needs to do its thing, and you can rely on the distribution for the updates to the system software, reducing your support overhead.
[06:08] <LaserJock> DoubleDave: of course there are pros and cons
[06:09] <persia> Further, I'd recommend not using /opt.  Given that this would be the primary service installed on the target machine, there's no reason to keep it separate once it has been integrated with package management.
[06:09] <LaserJock> if you're gonna go to the trouble of making a package and you know it's gonna be for a Debian/Ubuntu system
[06:09] <LaserJock> then integration with the existing distro packages can be a bonus
[06:10] <DoubleDave> trying to keep up here. lol
[06:10] <joejaxx> anyone else here have experience with the fedoa-ds source?
[06:10] <persia> DoubleDave: Also, I'd add some documentation & support for a separate management network to your site & software: trying to manage a system over a monitored promiscuous port can be exceedingly annoying for large installations.
[06:11] <joejaxx> i am trying to figure out whether i should create one source package or multiple ones
[06:11] <joejaxx> oh nevermind
[06:11] <joejaxx> one source package does not make any sense
[06:11] <DoubleDave> persia: is there another channel perhaps that I is a little quiter im having a hard time here sorry
[06:12]  * StevenK adds to the noise.
[06:12] <persia> joejaxx: Unless there's a strong reason otherwise, best to have one source per upstream tarball, and split the binaries based on architecture (and purpose, for libraries)
[06:12] <DoubleDave> nm
[06:14] <DoubleDave> persia: thanks again and I am taking all of your opinions but for some reason I cant see a downside
[06:14] <DoubleDave> the software during the setup asks what nic you would like to use for monitoring
[06:14] <DoubleDave> so really you should have two nics anyway
[06:15] <persia> DoubleDave: The downside to /opt is that very few would consider it an "add-on" package, and so getting it into the archives would be very difficult.
[06:15] <DoubleDave> I'll head your advice and see what my buddy thinks
[06:15] <persia> Further, if you are installing specialised versions of postgres, apache, etc. you do not get the benefits of distro security support for those components, and so need to manage it separately
[06:15] <DoubleDave> I thing the reason why we would like to keep it in opt is for consistancy on for our sake instead of having multiple installs of the same version software
[06:16] <DoubleDave> but if it will be rejected then I guess me complaining wont really get me anyware will it? lol
[06:16] <joejaxx> persia: the tricky thing is all the build requirements
[06:16] <persia> DoubleDave: As the software provider, you shouldn't need to care about the installation location: that should all be abstracted by the build system.  Then, the packaging for each distribution should pass the right flags to the build system to install it in the preferred place.
[06:17] <joejaxx> persia: i am going to have to do an audit of them
[06:17] <persia> joejaxx: Just be extra careful to avoid any loops, and you should be OK.
[06:17] <joejaxx> to see if they are even necessary in ubuntu
[06:17] <joejaxx> or if they have already been applied
[06:17] <joejaxx> loops?
[06:18] <persia> joejaxx: A depends on B and B build-depends on A.  Easy to see for two packages, but not always as obvious for 10.
[06:18] <joejaxx> oh
[06:18] <joejaxx> :)
[06:18] <DoubleDave> anyway to add a little plug here for the software your more than welcome to try it out if you have a spyware problem on your network
[06:18] <DoubleDave> it works great. I'll get to makeing the package compliant
[06:18] <DoubleDave> thanks again all
[06:18]  * persia is far too paranoid to install binary software
[06:19] <joejaxx> persia: security paranoia ftw :)
[06:23] <joejaxx> StevenK: oh i forgot to tell you, upstream calls it fedora-ds
[06:24] <joejaxx> StevenK: ref: package naming
[06:26] <StevenK> Grm?
[06:26] <ScottK> joejaxx: I think you meant me.
[06:26] <joejaxx> oh whoops
[06:26] <joejaxx> sorry
[06:27] <ScottK> StevenK: He asked me about what to name his package earlier today.
[06:27] <StevenK> Ah
[06:27] <ScottK> joejaxx: That changes things.  I'd go with the upstream name.
[06:27] <joejaxx> ScottK: ok
[06:27] <ScottK> Unless the other S*K has another thought on it.
[06:27]  * persia notes that backlog says he was asking me, and thanks ScottK for answering promptly
[06:27] <ScottK> 'cause you were sleeping (like I should be right now).
[06:28] <persia> ScottK2: Right.  Go to bed :)
[06:28] <joejaxx> i might have to start with the build requirements for it
[06:28] <joejaxx> lol
[06:28] <joejaxx> as some of them might not be in ubuntu yet
[06:29] <ScottK> persia: I'm doing important stuff like making software not want to fall over quite so badly in the face of insanely broken DNS servers.
[06:29] <persia> ScottK2: Ah.  DNS has a way of keeping one up at night.  Good luck.
[06:29] <joejaxx> maybe i will just put it on ppa as it seems this is going to be a project to upload
[06:29] <joejaxx> lol
[06:30] <joejaxx> or it is not going to all get uploaded this release cycle
[06:30] <joejaxx> well maybe
[06:30] <joejaxx> depends on when the new package freeze is
[06:30] <persia> joejaxx: Just give it a shot.  There's a couple months left.
[06:31] <joejaxx> what is NPF a part of now?
[06:31] <joejaxx> i do not see it on the release schedule
[06:31] <persia> joejaxx: Feature Freeze
[06:31] <joejaxx> ah ok
[06:32] <joejaxx> ahh i thought it was a lot closer :)
[06:33] <persia> joejaxx: No, this is the right phase of the release cycle to be looking closely at integration and new features to make hardy the best Ubuntu yet.
[06:34] <joejaxx> :)
[06:36] <joejaxx> i think the fun part will be the java based parts :P
[06:45] <LaserJock> so bzr hit 1.0
[06:45] <joejaxx> yeap
[06:48]  * LaserJock idly wonders if Launchpad will hit 1.0 soon
[06:48]  * TheMuso wonders whether that will be backported.
[06:48] <LaserJock> TheMuso: they have their own repo if not
[06:48] <TheMuso> LaserJock: Ah ok. I didn't know that?
[06:48] <TheMuso> s/?/./g
[06:48] <LaserJock> yeah, they've had it forever
[06:49] <LaserJock> that was about the only way you could keep up
[06:49] <TheMuso> Right.
[06:49] <joejaxx> anyone else having problems with the libstndc++6 package on hardy?
[06:50] <LaserJock> hmm
[06:50] <joejaxx> libstdc++6 *
[06:50] <TheMuso> joejaxx: What problems exactly?
[06:50]  * LaserJock raises an eyebrow as libc6-amd64 goes by in his pbuilder update
[06:50] <joejaxx> LaserJock: say
[06:50] <joejaxx> same*
[06:51] <joejaxx> failing to configure
[06:51] <TheMuso> ah
[06:51] <joejaxx> but it seems that it goes way after dist-upgrading the rest of the system
[06:52] <joejaxx> bah that stinks there are not an 3ware RAID drivers for solaris yet
[06:53] <TheMuso> brb
[06:59]  * TheMuso is currently mirroring hardy, as well as gutsy* powerpc.
[06:59] <TheMuso> oh and hardy* powerpc
[07:00] <joejaxx> persia: http://directory.fedoraproject.org/wiki/Licensing
[07:00] <persia> joejaxx: Why me?
[07:00] <joejaxx> -persia :P
[07:01] <persia> joejaxx: Next, what about it?
[07:02] <joejaxx> would any of those license stop any of those from going into universe?
[07:02] <joejaxx> well excluding the software already in ubuntu
[07:04]  * persia is unsure about "Only Red Hat, Inc. may make changes or additions to the list of Approved Interfaces" in paragraph 4 of http://directory.fedoraproject.org/wiki/GPL_Exception_License_Text for Directory Server Core.  Is this exception required for the materials you are expecting to package?
[07:04] <TheMuso> joejaxx: What is fedora-ds?
[07:08] <joejaxx> TheMuso: directory server
[07:08] <joejaxx> ldap
[07:08] <TheMuso> ah
[07:08] <TheMuso> Whats so special about it if its ldap?
[07:09] <joejaxx> http://directory.fedoraproject.org/wiki/Features all of this :)
[07:10] <TheMuso> ok
[07:13] <TheMuso> Nice set of features.
[07:13] <slangasek> ScottK: I am an archive admin too, as persia seems to have pointed you to
[07:13] <joejaxx> TheMuso: :D
[07:14] <joejaxx> well i am going to retire for the evening
[07:14] <joejaxx> i will start on the build depends tomorrow
[07:14] <joejaxx> Goodnight All
[07:16] <TheMuso> Night joejaxx.
[07:18] <persia> slangasek: Do you expect anything special from universe for alpha 2, or is it just more of our regular "things should install, and not FTBFS" efforts.
[07:21]  * TheMuso is VERY impressed with his local mirror.
[07:21] <TheMuso> I uploaded a package, and as of approx 3 this afternoon, its there.
[07:21] <TheMuso> Much better turn-around to what it used to be.
[07:26] <Hobbsee> TheMuso: wow, nice.  internode?
[07:27] <slangasek> persia: I expect universe to be bug-free for alpha 2, of course ;)
[07:28] <TheMuso> Hobbsee: Yse.
[07:28] <TheMuso> yes even
[07:28] <TheMuso> SO I don't have to wait half a day for a broken mirror to be working again. :)
[08:00] <slytherin> Is an upstream source package contains some jar files. Is it good idea to remove them all?
[08:02] <persia> slytherin: Not necessarily: it depends what is in the jar files.  Sometimes upstreams put source in jar files, and you might need that.
[08:02] <persia> Further, if the upstream files are free, it might make sense to remove them in clean: rather then removing them in the tarball.
[08:04] <slytherin> persia: There are some demos in the documentation sub directory. These demos are bulild automatically but they don't seem to be cleaned in 'clean' target
[08:04] <persia> slytherin: In that case, either patch clean in the upstream makefile, or add it to debian/rules clean:
[08:07] <slytherin> The situation is like this. I am trying to create a .orig.tar.gz. That is why I want to remove the jar files.
[08:07] <slytherin> Even the older .orig.tar.gz has jar files removed
[08:09] <persia> slytherin: I don't see the point of removing the jar files from the orig.tar.gz if you have source for them, and would rebuild during the build process.  I suspect either the source doesn't work, the files aren't free, or someone was being extra careful, and erred in favour of removing stuff rather than maintaining checksum sync with upstream.
[08:10] <slytherin> persia: 1. Sorry for being unclear. The jar files are related to test and demos. So they won't get build in the ubuntu package because we are not using 'test' or 'demo' targets
[08:11] <persia> slytherin: That's fine.  As long as they could be built, and they may be modified and distributed, then they are free enough to be in the tarball, even if we don't use them.
[08:12] <slytherin> persia: Ok. I was under impression that we shouldn't include any jar files in orig.tar.gz them being binary.
[08:13] <persia> slytherin: My opinion is that we should ship the orig.tar.gz available upstream as often as possible, as long as we are permitted to do so.  The only reason most Jar files, PDF files, etc. need to be removed from upstream tarballs is because upstream doesn't provide source.
[08:14] <persia> Binary files are fine: many sounds and graphics have binary formats as the preferred form of modification.
[08:14] <slytherin> persia: provide source in same tarball right?
[08:14] <persia> slytherin: Right.
[09:10] <JimmyDee> quietest 177 people I've ever seen
[09:11] <Burgundavia> it is European early morning and NA night
[09:11] <JimmyDee> yeah its 0300 here, but no sleep for the wicked
[09:13] <persia> JimmyDee: Even in places where it isn't an odd time, it's the weekend.  Further, this is mostly a coordination channel: people generally only say things when there is a question.
[09:17] <TheMuso> And, people also idle in here to follow the activity, and to find out what has been going on when they are not around.
[09:21]  * persia contemplates shifting the topic from merging to FTBFS + debcheck
[09:21] <persia> ajmitch: Any chance that RCbugs could be updated to point at hardy?
[09:29] <slytherin> Where can I find minor ftbfs bugs?
[09:30] <jpatrick> sl
[09:30] <jpatrick> slytherin: http://qa.ubuntuwire.com/ftbfs/
[09:30] <persia> slytherin: Separating major from minor is tricky, but the link jpatrick provided is a nice list :)
[09:31] <slytherin> Thanks
[09:31] <slytherin> I will be mostly looking for java programs/libraries
[09:41] <Lutin> persia: does the ftbfs page makes any difference between build failures and depwait/not yet built ?
[09:42] <persia> Lutin: They should be different colors.  Take a look at the top: if you can't differentiate two of the colors, maybe one should be adjusted (I can see 5 with this set)
[09:43] <persia> Ooh!  I forgot, they have different letter codes now too :)
[09:44] <Lutin> persia: ahh right. sorry
[09:55] <slytherin> It looks like there is no java-gcj-compat-dev package for hppa. This causes FTBFS for many java based libraries. Does anyone know anything about this?
[09:55] <pochu> good morning MOTU land!
[09:59] <geser> Hi pochu
[10:01] <geser> slytherin: go up the dep chain and check why is isn't there
[10:02] <geser> slytherin: java-gcj-compat depwaits on gcj-4.2 and gcj-4.2 failed to build as ecj wasn't installable at that time
[10:03] <slytherin> geser: Ok. I thought this was something arch specific.
[10:08] <geser> it might be
[10:08] <geser> I didn't check if ecj is now installable on hppa
[11:19] <slytherin> How can I find someone to review the package I have uploaded?
[11:21] <Hobbsee> ask in here
[11:23] <persia> slytherin: Is this a new package, or a package update?
[11:23] <slytherin> persia: New version
[11:24] <persia> slytherin: In that case attach a debdiff or interdiff to a bug, and subscribe the ubuntu-universe-sponsors.
[11:25] <slytherin> persia: I had talked with last uploader. He asked me to upload to Revu and I did it and even mailed him for review. But haven't got any reply.
[11:25] <slytherin> persia: I am one of the upstream maintainers and wish to take over package maintenance in Ubuntu
[11:26] <persia> slytherin: There are lots of different methods to get your updates into the repositories.  If you work with a specific person, you may want to listen to them.  The official current procedure in the standard case is as I described.
[11:26] <slytherin> Ok
[11:26] <persia> Personally, I recommend following the standard procedures to take advantage of team review, and not wait for some person.  On the other hand, some packages do better from having that person's input.
[11:27] <persia> If you're upstream, and you want to help with Ubuntu, that's great.  I suggest you may also want to get in touch with Debian if your package is there, as the Debian maintainer may also find your advice helpful.
[11:28] <persia> For most cases of upstream support for a specific application, following the team procedures is fastest.  Once you've had a couple uploads, you'll find your changes getting only light review, as you'll be considered the expert for that package.
[11:29] <slytherin> persia: Since I have already uploaded package to revu is it ok if I mention that in bug or do I still need to attach debdiff/interdiff?
[11:30] <persia> slytherin: Some of the sponsors will demand you generate the diff.  Some will go do it for you.  If you don't attach the diff, be prepared for someone to complain (although they may not).
[11:30] <slytherin> persia: I will do it anyway
[11:32] <slytherin> persia: As to debian package, there is bug in debian for long time to update the package. It was logged by a friend for last upstream version in February. No activity there and since I don't have access to any debian system, I can not do it myself. :-(
[11:33] <persia> slytherin: Which package?
[11:34] <slytherin> gnusim8085
[11:34] <persia> 87 days old :)
[11:37] <persia> slytherin: The maintainer looks to be active.  You might set up a sid chroot, build a candidate, and ask them if they'd be willing to look at the changes at get it in.
[11:37] <slytherin> persia: Wait, let me check
[11:39] <slytherin> persia: Some confusion on my part. The version mentioned in bug is 10 months old but the bug is not so old. :-)
[11:41] <persia> slytherin: Understood.  No worries.  Still, it's been a while, and the new update may be useful.  Do you distribute a tar.gz upstream?
[11:41] <slytherin> persia: Yes I do.
[11:42] <persia> slytherin: Great.  Sometimes it's troublesome to do an update in Ubuntu when Debian will update soon, as repacking orig.tar.gz files can lead to differing checksums.  If you distribute an official orig.tar.gz, that risk goes away.
[11:43] <slytherin> :-)
[11:48] <slytherin> persia: files bug 176521
[11:48] <ubotu> Launchpad bug 176521 in gnusim8085 "New upstream version available (1.3.2)" [Undecided,New] https://launchpad.net/bugs/176521
[11:50] <persia> slytherin: That looks like a well-formatted bug.  I sponsor in FIFO mode, so there's a heap of other bugs I'll dig at first.  I'd guess it's probably a couple days before that gets uploaded (we're running a little slow right now), unless someone is concentrating on new upstreams and hits it sooner.
[11:51] <slytherin> persia: Thanks. :-)
[11:52] <Kopfgeldjaeger> could someony have look at avidemux@revu? the  version in feisty and gutsy is _very_ outdated. http://revu.tauware.de/details.py?package=avidemux
[11:53] <persia> Kopfgeldjaeger: upgraded packages on REVU tend to get ignored.  You may have better luck submitting an interdiff in a bug to the sponsors queue.
[11:53] <slytherin> Kopfgeldjaeger: Are you targetting that package for feisty/gutsy?
[11:58] <slomo> siretart: iirc you asked me to test a new ffmpeg snapshot some days ago? where was it again? :)
[11:59] <Kopfgeldjaeger> slytherin: no. hardy.
[12:06] <persia> Supremus: Thanks for all your help with the SRU testing.  It really helps to get the fixes into the repositories.
[12:06] <Supremus> persia, :D
[12:08] <Supremus> persia, could you please see my bugfix?
[12:09] <Supremus> https://bugs.launchpad.net/ubuntu/+source/twill/+bug/176435
[12:09] <ubotu> Launchpad bug 176435 in twill "python-twill missing a dependency" [Undecided,Confirmed]
[12:11] <Supremus> persia, sorry for ma bad english
[12:11] <persia> Supremus: It's currently #35 in my view of the sponsoring queue.  Looks relatively sane.
[12:12] <persia> Supremus: Don't worry about your English: while it's always valuable to study languages, as long as people understand, you've achieved the primary goal :)
[12:13] <Supremus> persia, ok
[12:16] <persia> Could anyone point me at a Debian package removal log?  I usually use the PTS, but I'm currently looking at a package that appears to only have ever been uploaded to "unstable", yet lacks a PTS entry.
[12:16] <Lutin> stdin: think you might be interested in bug #172636
[12:16] <ubotu> Launchpad bug 172636 in amarok2 "amarok2 FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/172636
[12:18]  * persia finds http://ftp-master.debian.org/removals.txt and asks others to ignore the previous request
[12:29] <geser> persia: perhaps the package never was in Debian? which one are you looking at?
[12:30] <persia> geser: Yeah.  That was it.  It's showfsck, which was apparently sync'ed back in the days of apt-get.org fun.
[12:30] <siretart> slomo: svn.debian.org, pkg-multimedia repo, the experimental branch
[12:31] <slomo> siretart: where's the tarball for which this was created? :)
[12:31] <siretart> slomo: i've disabled 2 altivec quilt patches. no idea if that was a clever move
[12:32] <slytherin> Supremus: While you are at it, you may want to add 'Homepage' field. ;-)
[12:32] <siretart> slomo: on my laptop at home. create it yourself by using the upstream svn trunk
[12:32] <siretart> slomo: and svn up -r {20071007}
[12:32] <slomo> ok :)
[12:32]  * persia encourages get-orig-source in debian/rules to make this transparent
[12:33] <slomo> siretart: i can't test on ppc though... mine is broken :/ how much did the api change?
[12:33] <siretart> slomo: mount the debian branch on it and run debian/strip.sh to disable the mpeg encoders
[12:34] <siretart> slomo: I've rebuilt all ffmpeg using packages in debian
[12:34] <bluekuja> good morning everyone
[12:34] <bluekuja> heya siretart, slomo, persia, geser
[12:34] <siretart> yesterday, and  didnt notice a single ftbfs due  to api changes
[12:34] <bluekuja> :)
[12:34] <geser> persia: https://lists.ubuntu.com/archives/ubuntu-changes-auto/2005-October/001421.html
[12:35] <geser> persia: auto-synced from dept-info.labri.fr
[12:35] <slomo> siretart: even new gstreamer0.10-ffmpeg that builds against it? great :)
[12:35] <geser> Hi bluekuja
[12:35] <slomo> siretart: why does the ffmpeg option to list all codecs still list h263 as supported for encoding btw?
[12:35] <persia> geser: Yep.  New version now hosted on http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html#showfsck, but context was lost due to the change to only pulling from Debian.
[12:37] <siretart> slomo: ive bounced you the buildlog
[12:37] <slomo> thanks
[12:37] <siretart> slomo: I think that should be fixed now in the experimental branch
[12:37] <siretart> slomo: needs more research for a  definite answer
[12:39] <geser> http://qa.ubuntuwire.com/ftbfs/ has now also some per-arch stats and is valid XHTML 1.1
[12:39] <persia> \o/
[12:40] <DktrKranz> geser, great!
[12:40] <slomo> siretart: looks good (the build log)
[12:40] <bluekuja> slangasek, around?
[12:40] <siretart> slomo: need to leave now, please mail me your findings
[12:41] <Lutin> geser: cool :)
[12:41] <siretart> slomo: I plan an upload to experimantal rsn
[12:41] <slomo> siretart: will do... and an upload to exp would be nice too so we can get some wider tseting :)
[12:41] <persia> bluekuja: It's very early in the morning there.  You might have a bit to wait.
[12:41] <Lutin> geser: was thinking too: a BTS link might be useful, to check quickly if a FTBFS fix has been uploaded to debian
[12:41] <slangasek> yes, you might have to wait a minute or two
[12:41] <persia> heh
[12:41] <bluekuja> slangasek, haha :)
[12:42] <bluekuja> slangasek, how are you? everything fine?
[12:42] <slangasek> my eyelids are drooping and you probably have about 2 minutes of my attention before I wander to bed :)
[12:43] <bluekuja> slangasek, about fische, I found out that the build system created upstream, was unable to support all the archs, so I wanted to restrict them for a while
[12:44] <slangasek> ah
[12:44] <bluekuja> I was in contact with upstream about that, so I guess I'll have to send him a reminder-mail
[12:44] <slangasek> in that case, I may end up having a look at the package to try to get it ported
[12:44] <bluekuja> slangasek, that would be simply great :)
[12:45] <slangasek> ... but not until after I sleep.  G'night. :)
[12:45] <imbrandon> gnight slangasek
[12:45] <bluekuja> good night mate, ping me again when you gonna wake up
[12:46] <geser> Lutin: I've already a quick-search for PTS in my firefox :) But I could add a BTS link for each package if it helps
[12:46] <DktrKranz> hey imbrandon, any news for the meeting?
[12:46] <geser> Lutin: where in the row should it be added? at the end?
[12:47] <imbrandon> DktrKranz: the sru meeting ?
[12:47] <Lutin> geser: aah :) . was just a thought anyway, don't know if there are other developers that would find useful
[12:47] <DktrKranz> imbrandon, that one
[12:47] <imbrandon> DktrKranz: 2100 UTC today
[12:47] <DktrKranz> ok, saturday night may wait a bit :D
[12:47] <imbrandon> :)
[12:47] <DktrKranz> on #ubuntu-meeting
[12:47] <DktrKranz> ?
[12:47] <persia> DktrKranz/imbrandon: There was an interesting request earlier that I wasn't sure how to answer: specifically someone subscribed both U-U-S and ~motu-sru to a bug.  Does the SRU team approve or approve & upload?
[12:47] <Lutin> geser: the place doesn't matter much, as long as it's there :)
[12:48] <DktrKranz> persia, related to spe?
[12:48] <imbrandon> persia: typicly only approve
[12:48] <persia> DktrKranz: You seem to get the same bugmail as I :)
[12:48] <DktrKranz> hehe
[12:49] <persia> imbrandon: OK.  I'd like to keep the U-U-S queue clean: what's the best way to coordinate to not miss things?
[12:49] <geser> Lutin: do you want a link to the BTS or PTS or both?
[12:49]  * persia would prefer PTS if there was only one link.
[12:49] <imbrandon> persia: in the past only ACK unless specicly stated in the bug when acking that they would upload it, but really u-u-s shouldnt be subscribed untill its ready, e.g in this cased acked
[12:49] <Lutin> persia , geser : right, PTS might be better
[12:49] <DktrKranz> persia, not sure if a motu-sru member should upload it as well after approving it, but it should be worth discussing it
[12:49] <imbrandon> did that make sense
[12:50] <persia> imbrandon: OK.  So if U-U-S gets an SRU request, it should be resubscribed to the SRU team, and when it gets ACK'd, the SRU team will resubscribe UUS if it needs sponsoring for upload?
[12:50] <imbrandon> right
[12:50] <persia> DktrKranz: Does that make sense to you?
[12:51] <DktrKranz> persia, it does to me
[12:52] <persia> OK.  Let's go with that as a provisional policy for the next 7 hours, and you guys can confirm at your meeting, and publish an update in your new policy report to the ML.
[12:52] <imbrandon> basicly that makes it so ~ubuntu-dev filed bugs get "one" eyebal ( as should be ) and contributor uploads get atleaste 2
[12:52] <imbrandon> eyebals
[12:52] <DktrKranz> what about writing a brief agenda on the wiki (or gobby, or whatever) to have a list of things to discuss?
[12:52] <imbrandon> DktrKranz: yup, just waking up myself but i'm actualy doing that right now
[12:52] <DktrKranz> imbrandon, thanks
[12:52] <imbrandon> persia: yup
[12:52] <DktrKranz> please, point me to it once ready
[12:53] <imbrandon> DktrKranz: ok, i'll "publish" it here in a few, lemme wake up just a tad and dig out my txt from last night
[12:53] <DktrKranz> \o/ dapper -> hardy upgrade failure!
[12:55] <imbrandon> persia: right see that gets more eyes on a contributor sru patch without having to make it explisit policy ( wich is good imho , i'm a fan of strong but minimal policy ) anyhow imho it *should* go like this ( will get confirmed in the meeting today )
[12:55] <imbrandon> ...
[12:55]  * txwikinger wonders what to work on next
[12:56] <imbrandon> motu files bug --> sru ack --> motu upload ; contributor files bug, sru ack; u-u-s review and upload
[12:56] <imbrandon> persia: see what i mean ?
[12:56] <persia> imbrandon: I'd agree.  Further, I don't think the SRU team is necessarily the people who want to spend time chasing new contributor processes, and I don't think the UUS team is necessarily the people who can make a good determination on SRU.
[12:56] <imbrandon> right
[12:56] <DktrKranz> +1
[12:57] <persia> txwikinger: unmet or incorrect dependencies.  See the debcheck page on qa.ubuntuwire.com
[12:57] <txwikinger> ok persia
[12:58] <DktrKranz> additionally, as pitti said, before going for a SRU, we must be sure development version is fine, we don't want to file a new SRU for a regression
[12:59] <imbrandon> DktrKranz: right, but thats part of what the sru team should be checking when acking a bug/request , e.g. its great of the filer does that but ultimately its our duty to check
[12:59] <persia> imbrandon: I think you guys should not only be checking, but also testing.  If you can't reproduce, you'll need to get lots of logs, etc.
[12:59] <imbrandon> persia: right, i simplified that a bit but yea
[13:00] <DktrKranz> It's hard to ACK something without testing it, IMHO
[13:00] <persia> DktrKranz: No, it's just three characters.  Very easy :)
[13:00] <persia> (note that this might mean a change of membership in the ACK'ing team :) )
[13:00] <DktrKranz> that's why TEST CASE must be accurate, and bug description update accordingly
[13:01] <imbrandon> speaking of ... the flashplugin-nonfree introduces a new regression that might not be avoidable, eg. require an aditional sru for another package
[13:01] <DktrKranz> persia, typing A, C, K with SHIFT key pressed is very hard...
[13:01] <imbrandon> lol
[13:01] <persia> DktrKranz: If you're caps lock doesn't work, try enabling sticky keys
[13:01] <DktrKranz> and I'm not a caps-lock supporter...
[13:01] <persia> s/you're/your/
[13:02] <imbrandon> heh i'm for all lowercase and all only ascii keyboards :)
[13:02]  * imbrandon ducks
[13:02]  * DktrKranz ponders to buy that wooden-made bird Homer Simpson used to manage his tasks on the nuclear plant
[13:04] <imbrandon> DktrKranz: anyhow the document i'm writeing is basicly a copy paste from the current main + universe SRU page with the universe stuff all deleted initialy and then going back and noting the 1 or 2 subtle diffrences in the two pilicys , e.g. my goal is to make it ONE policy with only team name changes basicly
[13:05] <imbrandon> wiki/SRU
[13:05] <DktrKranz> and it really should be that way
[13:05] <imbrandon> yea
[13:06] <DktrKranz> we don't want to have two different procedures, with many differences between them
[13:06] <persia> imbrandon: One key difference I see is that for universe FTBFS and cannot-install bugs seem to get handled, whereas for main, they aren't usually considered.
[13:06] <imbrandon> well at one time we did, this will be the 4th universe pilicy i have seen come to light since i have been involved with ubuntu, and the more we can keep it the same the better we are imho just from past experince
[13:07] <persia> imbrandon: Only the 4th?  Aren't you glossing over the SRU-policy-of-the-week part of the feisty cycle?
[13:07] <imbrandon> persia: yea, basicly the same as main + these key points ( only ) .... team name changes and a few additions to what qualifies for an SRU , eg. FTBFS bugs
[13:08] <imbrandon> persia: hehe yea i dont really consider that one
[13:08] <imbrandon> lol
[13:08] <DktrKranz> mh, SRU policy states only regressions or data losses are good candidates for updates
[13:09] <DktrKranz> I think FTBFS can be managed by backports
[13:09] <imbrandon> DktrKranz: right, and for universe we want to make just a few additions to that , that basicly is the only change to the main policy
[13:09] <imbrandon> DktrKranz: not really FTBFS are normaly regressions
[13:09] <imbrandon> but minor regressions that main normaly dont think applies
[13:10] <DktrKranz> ah, good point
[13:10] <persia> DktrKranz: For main, that is true, but main doesn't have FTBFS or cannot-install as there are careful rebuild tests and install tests of all the packages after feature freeze.
[13:11] <DktrKranz> so, basically we can consider good candidates bugs which have at least "medium" priority
[13:11] <persia> Isn't "Medium" the default priority?
[13:11] <imbrandon> hrm depending on the person that triaged it possibly heh
[13:11] <imbrandon> persia: no, none is afaik
[13:11] <imbrandon> or "unset" or soemthing
[13:11] <DktrKranz> I'm referring to "medium" for motu-sru
[13:11] <persia> I think you'd want a set of rules for bug class, rather than using Priority.
[13:12] <imbrandon> yea
[13:12] <persia> My thought for the set would be: data loss, regression, FTBFS, cannot-install, license violation, completely fails to work (e.g. Bug #108559)
[13:12] <ubotu> Launchpad bug 108559 in skencil "skencil core dumps when I attempt to load it (dup-of: 81567)" [Undecided,New] https://launchpad.net/bugs/108559
[13:12] <ubotu> Launchpad bug 81567 in skencil "skencil crashes on startup with a SIGSEGV in free()" [Medium,Confirmed] https://launchpad.net/bugs/81567
[13:13] <imbrandon> ok i got a serouis question here, policy dissussion aside for a moment, ok the flashplugin-nonfree update , it works perfect for geko based browsers, but totaly breaks konqueror, sooooooooooo
[13:14] <DktrKranz> Gotta leave for a while, my father manages to adjust our christmas tree, he's unhappy of the lights...
[13:14] <DktrKranz> I'll read logs later
[13:14] <DktrKranz> see you
[13:14] <imbrandon> do we knowingly break konq or there is a patch but its pretty invasive and untested
[13:14] <persia> imbrandon: I'd be opposed (even though I use gecko).  That's just very risky.
[13:14] <imbrandon> persia: well then anyone that dosent use hardy wont be able to use flash
[13:14] <imbrandon> thats a tough call too
[13:15] <persia> imbrandon: No, anyone who installs gutsy after the upstream change will have to use a free flash viewer.
[13:15] <imbrandon> e.g. its not a bug in flash, its a bug in konq that flash exposes
[13:16] <persia> Or rather, Ubuntu doesn't support them.  They can download from upstream, but that might break their browser.
[13:16] <imbrandon> sooo really we should do a konq sru too, but the code is new and untested and actualy in svn only
[13:16] <persia> imbrandon: Why a konq SRU?  Is there a chance of data loss?  Is it a regression?  (konq is main)
[13:16] <imbrandon> persia: yea ubuntu dosent support them, but ummm try telling that to the users heh
[13:17] <persia> imbrandon: I do, sometimes accompanied by hints for a workaround, and warnings that it might break things.
[13:17] <imbrandon> persia: yea i know, this was discussed in #k-devel yeaterday, i dont like any of the awnsers but one of them we will have to do, its a case of lesser of the evils here i'm afaraid
[13:17] <joejaxx> Good Morning All
[13:17] <imbrandon> ello joejaxx
[13:18] <persia> imbrandon: I'd agree with that.  I think the lesser evil is using free flash viewers in gutsy (gutsy gnash is pretty good), but I'm opinionated, which is part of why it's not my decision :)
[13:19] <imbrandon> persia: hrm but that still makes a regression from dapper onword, this is for all supported releases atm
[13:19] <imbrandon> and gnash isnt in all
[13:20] <imbrandon> e.g. feist on? maybe edgy but the edgy version likely isnt the one that can do video etc
[13:20] <persia> imbrandon: Ah.  True.  For < gutsy, gnash isn't really as good, and for dapper or edgy, nothing really is useable.
[13:20] <imbrandon> right
[13:21] <persia> imbrandon: On the other hand, konqeror is fairly popular :(
[13:21] <imbrandon> i mean i hate flash too, actualy i dont hate flash i just hate gnash is ready or arround sooner, but anyhow , the users do see it as important and there is a vast number of sites that use it, its kinda a psudo standard as much as we know it shouldnt be
[13:22] <imbrandon> persia: yea, not supporting konq is just as much of a deadly mistake as not updating flash
[13:22] <imbrandon> rock + hardplace
[13:22]  * joejaxx remembers back in 1999 when it was "cool" to have your entire site in flash
[13:22] <persia> joejaxx: Some people still think that way
[13:22]  * joejaxx does like that era :P
[13:22] <imbrandon> lol
[13:23] <joejaxx> persia: yeah
[13:23] <imbrandon> geocities homepages
[13:23] <imbrandon> :)
[13:23] <joejaxx> imbrandon: hahaha
[13:23] <StevenK> I remember when embedded MIDI was cool
[13:23]  * StevenK twitches
[13:23] <imbrandon> i had a geocities homepage ( before it was bought by yahoo ) about c64 basic programign heheh
[13:24] <persia> imbrandon: Not only.  nokia.co.jp is mostly flash, and not gnash-friendly.
[13:24] <imbrandon> StevenK: heh
[13:24] <joejaxx> StevenK: LOL yeah
[13:24] <persia> Or maybe that got fixed (oops)
[13:24] <imbrandon> hrm there IS one other alternative
[13:24] <StevenK> I think any Nokia site is mostly flash?
[13:24] <imbrandon> bear with me ... i just thought about this
[13:25] <joejaxx> you would have to sift through the webpages trying to figure out which one was playing the music
[13:25] <imbrandon> now the current flash9 releases is r115 , r48 ( last released ) works with konq
[13:25] <imbrandon> well adobe only makes avail r115 in the download url
[13:25] <imbrandon> BUT
[13:25] <persia> StevenK: I thought so as well, but apparently .jp was sorted recently.  Still flash-heavy, but now navigable.  I suspect it's to avoid breaking everyones phone.
[13:26] <imbrandon> adobe also makes r48 and others avail in a "archive" zip thats 65+ MB
[13:26] <imbrandon> sooooooo we could have the package check the release its installed to and optionaly get the r48 for konq
[13:26] <imbrandon> but thats full of holes and a large download
[13:26] <StevenK> persia: Yeah, I this feeling that the phone browser got locked in a room with the web site people, the door was locked, and they were told they were going to be let out until they reached an understanding.
[13:27] <imbrandon> e.g. for someone who has ubuntu but konqueror installed
[13:27] <imbrandon> thoughts ?
[13:28] <StevenK> imbrandon: Then the package installation should fail with "Konqueror SUCKS!"
[13:28] <persia> StevenK: Not that drastic.  About 6 months ago most phones were upgraded to 640x480, which suddenly made the normal web accessible (320x240 still used special sites), and a lot of customers now use their phones as their primary browsers (nothing else to do on the train).
[13:28]  * StevenK hides
[13:28] <joejaxx> StevenK: lol
[13:28] <imbrandon> StevenK: heh that was my initial thought, but then we have the issue of people that have konq and ff installed
[13:28] <StevenK> persia: I don't, since Telstra charge something like $0.30 per KB
[13:29] <joejaxx> StevenK: oh wow
[13:29] <imbrandon> StevenK: robery
[13:29] <StevenK> (I'm not sure of the exact number, but it's *hideous*)
[13:29] <StevenK> imbrandon: Apparently, Telstra *need* to make $200 million profit
[13:29] <persia> StevenK: Right.  That might be why nokia.jp is more standards compliant than nokia.au.  Unlimited mobile dual-ISDN goes for about 6000 yen a month, and phone data charges are around 2 yen per 10,000 packets.
[13:30] <Tilllinux> hiho. If I want to create a GUI for, let's say, CloneZilla, what do I have to know to create one?
[13:30] <persia> Tilllinux: Do you mean building a XUL app?
[13:30] <imbrandon> whats clonezilla ? a cli app ?
[13:31] <imbrandon> so what do you all think aobut the "archive" work arround ? and some of the wholes it makes
[13:31] <imbrandon> w/wholes/holes
[13:32]  * txwikinger likes Konq
[13:32] <imbrandon> basicly it would make r48 only available on dapper to gutsy ( at the cost of a 65+ mb download ) and r115 avail on hardy
[13:34] <persia> imbrandon: Actually, if you could leverage that to use the version of flash that was originally shipped for that release, you'd likely get a supportable solution.
[13:34] <persia> s/that release/each release/
[13:34] <imbrandon> yea r48 is what is currently in all supported releases via other SRU's
[13:34] <imbrandon> s/other/past
[13:34]  * persia notes that people in places with less high or more costly bandwidth may have a different opinion
[13:35] <Tilllinux> I'd like to either create a simple gui for clonezilla (http://drbl.sourceforge.net/screenshot/?in_path=/01_Clonezilla) or just a simple script that provides all information needed to start backup'ing/restoring (for our school... we've tried acronis snap deploy but... umm... it isn't reliable [like, clients stop to restore at 99,99% ;) ])
[13:35] <persia> imbrandon: Right, but in the future, you could track versions for releases properly, and not keep updating just because upstream did.
[13:35] <imbrandon> persia: exactly
[13:36] <imbrandon> the one thing i would have to do would be make it download the zip of the archive regardless and check the md5 of the file inside, not the archive as a whole, as new "archives" releases are likely to be added
[13:37] <persia> imbrandon: The problem is places like Australia that request vital organs in exchange for large downloads or places like Ghana, where it might be faster to drive somewhere to carry around that much data rather then downloading it.
[13:38] <imbrandon> yup, but the more i think about it, it might be the best tradeoff, users still wont be happy because they will have an "old version" but its better than having no version or SRUing untested svn code
[13:39] <persia> Tilllinux: Looks like you could use just about any GUI creation tools to make a GUI.  If you don't mind GTK, I'd suggest that any of the glade bindings would probably ease your workflow.  On the other hand, this isn't really the best place to ask general programming questions.
[13:39] <StevenK> persia: Yes, that's exactly the problem. Telstra ask for vital organs for large downloads and you only have so many.
[13:40] <imbrandon> let me check the exact size, irrc its right at 65 mb
[13:40] <persia> StevenK: How discriminating are they?  Could a shovel help?
[13:40] <imbrandon> persia: hahahaha
[13:41] <StevenK> persia: Oh dear.
[13:42]  * persia apologises for the poor taste, and will refrain in the future
[13:42] <imbrandon> StevenK / persia : yea between 61 and 85 MB via http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266&sliceId=2
[13:42] <imbrandon> ouch
[13:44] <imbrandon> but thats the "safest" alternative
[13:44] <imbrandon> imho
[13:44] <persia> imbrandon: You might try a ML post to ask the question: options being 1) don't update, 2) break konq, 3) patch konq, 4) huge download.
[13:45] <imbrandon> good idea
[13:48] <imbrandon> persia: btw while i wait for my mail client to start heh, that contract was "typod" hehe i'm closer to the 75 to 78 i'm accustomed to lol
[13:49] <imbrandon> just fyi :)
[13:49] <persia> imbrandon: Right.  This is why it's good to get signed paper copies before asking questions :)
[13:50] <imbrandon> heh yea
[13:51] <joejaxx> does anyone even honor ubuntu certification yet? lol
[13:51] <imbrandon> ok i always forget the diffrence between -devel and -devel-discuss, what one is approperate
[13:51] <imbrandon> joejaxx: from LPI ?
[13:52] <imbrandon> and honor in what way ? ehhe
[13:52] <joejaxx> imbrandon: as in does it hold any weight yet :P
[13:52] <joejaxx> or are people taking it seriously i should say
[13:52] <imbrandon> i would guess as serouisly as RH cert form LPI as its the same people
[13:52] <persia> joejaxx: Those (benighted) employers who attach weight to certifications likely will consider an Ubuntu certification when considering one for a position involving Ubuntu.
[13:53] <imbrandon> imho none are worth anything, but thats just me
[13:54] <imbrandon> well not worth anything is wrong, not worth what people use them as/for
[13:54] <imbrandon> is better
[13:54] <persia> imbrandon: -devel is for developer communication.  -devel-discuss is for general discussion by anyone about the traffic on -devel and a redirect for posts to -devel by non-developers.  Use -devel.
[13:54] <imbrandon> k
[13:55] <StevenK> imbrandon: A lot of employers tend to put weight on an RHCE, for example
[13:55] <persia> dfiloni: You were looking for me earlier.  I suspect about wxwidgets2.8.  I can't build it due to issues on my local system: you'll need another sponsor.  The changes I last reviewed looked good and clean.
[13:56] <imbrandon> StevenK: yea, really depends on the the place, i know the place i work for looks at all certs ( MS and LPI and RH* and CCN* etc ) as shredder material, but i konw thats not the case some places
[13:56] <dfiloni> persia: sponso? I'm a newbie, I don't understand what  you said me...
[13:56] <imbrandon> they place experince at a much much higher sot
[13:56] <imbrandon> spot*
[13:57]  * persia is aware of employers that consider certifications on a CV to be negative, and other employers who will not employ people not certified in the relevant technologies.
[13:57] <imbrandon> yea
[13:57] <persia> dfiloni: Which don't you understand?
[13:58] <dfiloni> persia: I don't understand why I will need another sponsor
[13:59] <dfiloni> persia: and who is a sponsor...
[13:59] <StevenK> imbrandon: Hah, way cool.
[13:59] <persia> dfiloni: Because I'm unable to upload without changing my local system configuration, and I don't want to change it when there are other sponsors.  A sponsor is someone who uploads contributions from people who are not members of ~ubuntu-dev.
[14:00] <dfiloni> persia: ok, no problem
[14:00] <geser> persia, Lutin: http://qa.ubuntuwire.com/ftbfs has now a PTS and BTS link
[14:01] <persia> geser: Looks nice.
[14:01] <Lutin> geser: great ! thanks a lot :)
[14:02]  * persia encourages someone else to sponsor bug #133888 for dfiloni
[14:02] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the <IP_ADDRESS> release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[14:02] <zul> morning
[14:04] <joejaxx> zul: Good Morning :)
[14:04] <zul> hi joejaxx
[14:05] <imbrandon> moins zul
[14:05] <zul> morning imbrandon
[14:06] <geser> persia: what needs to be still done for wxwidgets? just test-build and upload or also some more review?
[14:07] <jimqode> hello, I just uploaded a package to my ppa, but i don't see it in the build queue. is it normal?
[14:07] <persia> geser: just test-build and upload.  I can only build locally, but was able to test successfully with both a local build and pochu's build.
[14:07] <persia> I just don't have enough capacity in my LVM chroot for a proper test-build.
[14:08] <geser> how much space does it need?
[14:08] <imbrandon> jimqode: yes, it take some $time for it to show, where $time == 20 minutes to 24 hours
[14:08] <imbrandon> hard to tell
[14:08] <jimqode> imbrandon, thank you!
[14:08] <persia> geser: Not sure.  Somewhere around 8GB I think.
[14:09] <persia> (including base tools, build-deps, etc.)
[14:10] <jimqode> something else, which version of ubuntu are my packages going to be compiled for? I want them for gutsy but I haven't seen any options for that.
[14:11] <persia> jimqode: Which version did you list in your changelog entry?
[14:11] <jimqode> i cant see a version: wmii (3.6+debian-3~jimqode) unstable; urgency=low
[14:12] <geser> persia: then I don't have enough free space either. I've a new 500 GB disk, but I haven't moved my system to it yet.
[14:12] <persia> geser: That's the problem with wxwidgets.  It's a huge and ugly package (although dfiloni has mostly cleaned up the new one), so nobody likes to work with it.
[14:13] <jimqode> persia, am i doing something wrong?
[14:14] <geser> are we interested in gcc-4.3 patches from Debian for hardy? or is this something for hardy+1?
[14:14] <persia> jimqode: You're asking for compilation against "unstable".  I don't know how Soyuz interprets that.
[14:14] <geser> iirc uploads for unstable get rejected
[14:14] <persia> geser: We applied quite a few gcc-4.3 patches for gutsy, and I think I remember a couple from feisty.  Better to push now.
[14:15] <persia> geser: By PPAs?
[14:15] <jimqode> persia, what are the keywords i can use? version numbers or names? What should i write there to compile against gutsy?
[14:15] <persia> jimqode: "gutsy"
[14:15] <jimqode> persia, thank you
[14:16] <geser> persia: ok, I will see if it's safe to sync the package if I see gcc-4.3 fixes in debian uploads
[14:19] <dfiloni> anyone can sponsor bug  #133888?
[14:19] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the <IP_ADDRESS> release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[14:37] <imbrandon> persia / StevenK / * : email sent to -devel explainign the issue and possible outcomes , sugestions welcome
[14:38]  * persia is very much not an SRU expert, and doesn't use non-free flash, so refrains
[14:38] <imbrandon> persia: even a proofread to make sure i got the point correct might be helpfull hehe
[14:39]  * persia polls the mail queue, wondering if it was sent from the right address
[14:39] <imbrandon>  yea it was, i just checked
[14:39]  * imbrandon checks again
[14:39] <imbrandon> ahh its still in my outbox, mail is being slow
[14:39] <imbrandon> one sec
[14:44]  * imbrandon kicks evolution
[14:48]  * persia suggests imbrandon may want a different client.  mailx is known to send reliably, for instance.
[14:48] <DktrKranz> telnet is better
[14:48] <imbrandon> yea i've been contemplating using mutt
[14:48] <imbrandon> anyhow sent now, i just used the gmail webinterface
[14:49] <persia> DktrKranz: The only issue with telnet is that it doesn't auto-retry in case of network failure, but it's at least simple.
[14:56] <imbrandon> persia: https://lists.ubuntu.com/archives/ubuntu-devel/2007-December/024877.html
[14:56] <imbrandon> finaly made it
[14:59] <dfiloni> anyone can sponsor bug  #133888?
[14:59] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the <IP_ADDRESS> release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[15:01] <pochu> imbrandon: you mention dapper->gutsy updates in your post, but they aren't supported, are they?
[15:02] <imbrandon> pochu: e.g. seperate sru for all releases
[15:02] <imbrandon> no upgrades from reelease to release
[15:02] <DktrKranz> pochu, IIRC only LTS -> LTS upgrades are supported
[15:17] <persia> dfiloni: For all that I support your candidate, and would like to see an update at least as much as you, I recommend you don't ask too often.  Some sponsors avoid uploading for people who ask a lot.
[15:18] <dfiloni> persia: thanks for your hints, I really appreciate it
[15:18] <persia> imbrandon: Just to check, what does "break konqueror" really mean?  Is only flash broken, or does it have wider effects?
[15:19] <imbrandon> persia: segfaults the browser
[15:19] <persia> dfiloni: Thank you for taking so much trouble with that unloved library.  Getting the new version in should close a lot of other bugs.
[15:19] <imbrandon> if a flash page is tried to be visited
[15:19] <persia> imbrandon: Only when visiting flash sites, or always?
[15:19] <DktrKranz> persia, I'm not confortable with wxwidgets, but would like to help dfiloni somehow. Is there something I need to know to review wxwidgets?
[15:19] <persia> Ah.  Yes.  That would be bad :(
[15:19]  * persia looks at the bug again
[15:22] <persia> DktrKranz: Build it in a safe environment.  Install it.  Test a client for the python binding (which also hits GTK & base).  filezilla or amule are probably the two most popular clients.
[15:22] <persia> DktrKranz: pochu has done all of the above, and I've done items 2 & 3, so it's pretty safe.
[15:23] <pochu> persia: filezilla and amule don't use the python bindings
[15:23] <pochu> I tested with phatch for the python bindings, fwiw
[15:23] <DktrKranz> probably boa-constructor does
[15:24] <DktrKranz> it uses 2.6, but should be compatible
[15:24]  * persia has misread the output of apt-cache rdepends and apologises for both the confusion & insufficient testing
[15:24] <pochu> persia: I tested it, so don't worry ;)
[15:25] <persia> DktrKranz: 2.6 and 2.8 are parallel installs, and all the clients are built against one or the other, so unless you want to port boa-constructor, you're better off with something else.
[15:25] <persia> (they are also not compatible APIs: WX is good about reversioning for incompatible changes, but less good about having easy transition plans)
[15:25] <pochu> aMule is built against wx2.8
[15:25] <Iwanowitch> Mercury (a programming language) has a new version upstream, and I'd like to see it in Ubuntu. However, it hasn't been maintained for about 3 years now. What should I do? File a bug? Get in touch with Debian maintainers?
[15:25] <pochu> and Filezilla too
[15:26] <DktrKranz> good point
[15:26] <persia> Iwanowitch: What's the package name?
[15:26] <Iwanowitch> persia: mercury
[15:27] <pochu> It is in the repos, isnt it?
[15:27] <pochu>    mercury | 0.11.0.rotd.20040511-5ubuntu1 | http://archive.ubuntu.com hardy/universe Packages
[15:27] <Iwanowitch> In universe, yes.
[15:27] <pochu> Oh, you mean the new release
[15:27] <Iwanowitch> 2004 as you can see.
[15:27] <pochu> Iwanowitch: file a bug then.
[15:27] <persia> Iwanowitch: I'd suggest preparing an update candidate for Ubuntu.  The Debian maintainer doesn't appear to be very active (I may well be mistaken).
[15:27] <pochu> Iwanowitch: and tag it 'upgrade'
[15:28] <zul> imbrandon: how is the snow?
[15:28] <imbrandon> zul: i havent went outside yet, but looking out the window about 2 inches so far and still comming
[15:28] <Iwanowitch> I'll be taking a look at it, will probably have more questions. Thanks :)
[15:28] <zul> thats not too bad i thought you were suppose to get alot
[15:28] <persia> Iwanowitch: For the update, it would be worth trying to make sure all of http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mercury are also closed, as some of them are considered sufficient to block release.
[15:30] <persia> Iwanowitch: Also, I'd recommend using a real release, rather than a rotd version.  That appears to be one of the reasons why the package is having trouble.
[15:30] <imbrandon> zul: yea they called for upto 12 inches
[15:30] <imbrandon> seems most of it missed me
[15:32] <persia> imbrandon: Seems reasonable, aside from my uncertainty above.  Usual comments about grammar, capitalisation, and spelling apply :)
[15:33] <ScottK> imbrandon: You have mail (about the Flash thing).
[15:35] <persia> When does Edgy support stop again?  April?
[15:35] <pochu> Yes.
[15:36] <dfiloni> pochu: do you tried if the new version of wxwidgets2.8 (<IP_ADDRESS>) fix amule's bugs?
[15:36] <dfiloni> *did you try
[15:37] <imbrandon> ScottK: thanks, reading now
[15:37] <pochu> dfiloni: I tried with one of them, which is reproducible, and it doesn't fix it.
[15:37]  * persia grumbles at the introduction of a new package depending on wx2.4
[15:38] <pochu> persia: how are your plans of getting rid of wx2.4?
[15:38] <dfiloni> pochu: ok...
[15:40] <persia> pochu: I'm basically stuck.  I don't understand ctsim well enough to port it, I'm not excited about trying to fix ecos SVN, as I don't like new snapshots of something that the devs don't think is suitable for use, and I'm not going to touch gnue-*.  survex is on my todo list, but with the other issues, it's not a high priority.
[15:40] <persia> On the other hand, this new package gets hit now to see if simple brute-force can prevent the problem growing.
[15:40] <pochu> persia: should we get a CVS snapshot of amule in? 2.2.0 has been frozen for a long time, but no final release yet...
[15:40]  * ScottK cheers brute force.
[15:40] <pochu> persia: request a removal for all of them? ;)
[15:40]  * pochu hides
[15:40] <persia> pochu: Any guess from upstream as to when there might be one?
[15:41] <pochu> persia: nope. Let me see if I can get some news...
[15:41] <txwikinger> how do I handle a case when for an upgrade of a package an additional package is needed which exists in debian but not in ubuntu
[15:42] <persia> pochu: For ecos, I'm thinking about it.  For gnue-*, the Debian maintainer is often in this channel, and keeps not wanting to talk about it.  For ctsim, there's really no alternative, and it meets a need.  For survex, I think it's soluable, just needs ~30 hours of porting work.
[15:42] <persia> txwikinger: Best way is to try to pull the Debian package.  What's the dependency?
[15:43] <txwikinger> locales-all
[15:43] <txwikinger> it might also work with locales, but I am not sure
[15:44] <persia> txwikinger: That's a special case.  Try to play with adjusting the dependencies, and test a bit.
[15:45] <txwikinger> The build works (the package is libversion-perl)
[15:45]  * persia wonders why on earth a package would build-depend on both libwxgtk2.4-dev and qt3-dev-tools
[15:45] <persia> txwikinger: The build working is a good sign.  Adjust debian/control, rebuild, and test to see if the result works.
[15:46] <txwikinger> Yes I did that
[15:46] <persia> txwikinger: Does the result work?
[15:46] <txwikinger> but I am not sure if I can extensively test the packages itself
[15:46] <txwikinger> the build has some tests, and 4 are skipped
[15:47] <txwikinger> but that looks independent of the dependency and looks ok
[15:47] <txwikinger> I will try what it does if I get the debian package
[15:47] <pochu> persia: LOL http://forum.amule.org/index.php?topic=13700.0
[15:48] <persia> txwikinger: If you need wider testing, you can either put the patch somewhere and call for developers as testers, or submit to a PPA and ask for lots of testers.  Don't try with debian locales: Ubuntu varies on that on purpose.
[15:49] <txwikinger> No I would try locales-all from debian
[15:49] <txwikinger> we don't have that package
[15:49] <persia> pochu: How clean are they?  If Festor is updating that often, maybe we should grab one of those (assuming the testing is OK).
[15:49] <txwikinger> I tried with our locales instead
[15:50] <persia> txwikinger: My confusion.  Still, Ubuntu locale handling is different, and we won't be able to pull from Debian.
[15:50] <txwikinger> ok.. then I can leave that test
[15:52]  * persia grumbles that jugglemater has to be added to the porting list :(
[15:52] <pochu> persia: or maybe we could ask him to do the work in the archive ;)
[15:53] <persia> pochu: Sounds reasonable.  Given that finding a place to upload seems to have been one of the problems.  I just like soft introductions: having 100 people suddenly complaining about policy violations isn't best :)
[15:57] <pochu> persia: sorry? I can't understand that about policy violations and soft introductions. could you rephrase for me? my english isn't that good :/
[15:57] <persia> pochu: Sorry.
[15:57] <pochu> well I know what are policy violations but don't get the sense in that context ;)
[15:58] <persia> pochu: The forum thread gives me the impression that a place to upload (like the archives) would be appreciated.
[15:58] <pochu> heh, ok :)
[15:58] <pochu> thank you
[15:58] <persia> On the other hand, if you have time to gently review and discuss with upstream, I suspect that they will be happier than if they went straight to REVU.
[15:59] <persia> Some people don't react well to having all the developers telling them they should do it differently when they already have lots of happy users.
[15:59] <pochu> persia: festor isn't upstream, is just a contributor in ubuntu-es ;)
[15:59] <persia> pochu: Ah.  Easier then :)
[15:59] <pochu> I'll ask him when he connects again :)
[16:00] <persia> pochu: Thanks.  Takes an application off your list, and puts it in the hands of someone with a clear and documented interest in chasing upstream :)
[16:01] <pochu> persia: and who uses the given application ;)
[16:01] <persia> pochu: That's good too :)
[16:05] <persia> bigon: Please try to keep changelogs in version order: when pulling from UNRELEASED, it's likely good to mangle the last changelog entry, rather than adding a new one.
[17:13] <slicer> Does anyone have time to do a review update of http://revu.tauware.de/details.py?package=mumble ? I'd kind of hoped to get the package done before the holidays.
[17:20] <somerville32> slicer, I'm not a MOTU but I'll take a peak
[18:11] <guest22_> Hi norsetto, I see you're back. I've fixed all of the problems with package "photoml" that you pointed out yesterday (and it now builds in a properly updated pbuilder). Would you mind taking another look?
[18:17] <norsetto_> guest22: could you add a watch file?
[18:18] <pkern> StevenK: Why shouldn't .la files be installed?
[18:19] <norsetto_> guest22_: you should also update http://www.wohlberg.net/public/software/photo/photoml/
[18:22] <norsetto_> guest22_: lintian warning on the source W: photoml source: binary-arch-rules-but-pkg-is-arch-indep
[18:24] <guest22_> norsetto: excuse my ignorance: what's a watch file?
[18:24] <LucidFox> guest22_> debian/watch
[18:24] <LucidFox> a file that allows for automated search of new upstream versions with uscan
[18:25] <pochu> see https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[18:26] <guest22_> norsetto: That must be something new - I'll look up the details and add one. I'll update the release on the homepage soon.
[18:26] <pkern> Anyone who could give me a clue about libtool .la removals?
[18:26] <norsetto_> pkern: only clue I can give you is that I was told not to add them in new -dev packages
[18:27] <pkern> norsetto_: And the reasoning behind that?
[18:27] <norsetto_> pkern: "because libtool is evil" whatever that means
[18:28] <pkern> Heh.
[18:28] <guest22_> LucidFox: Thanks for the details.
[18:28] <norsetto_> pkern: In my case I also had a pkgconfig file, so it was not a big deal
[18:28] <pkern> norsetto_: Now of course packages *might* also depend on the old libtool behaviour?
[18:29] <pkern> I mean all I see is this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451389
[18:29] <ubotu> Debian bug 451389 in libglade "Please remove .la files from the package" [Normal,Open]
[18:29] <pkern> And a changelog entry of StevenK where he announces that he'll do bad things to the libtool maintainers.
[18:29] <pkern> Unhelpful that is.
[18:29] <guest22_> norsetto: The lintian warning you mention doesn't appear on my system (dapper) or on the lintian output on REVU. What version did you run when you obtained that error?
[18:30] <norsetto_> guest22_: 1.23.41~gutsy1 which is a backport of the hardy one
[18:31] <guest22_> norsetto: OK, thanks, I'll look into that. Did you notice any other issues?
[18:32] <somerville32> Does anyone have an i386 machine I can build on?
[18:33] <norsetto_> pkern: yes, he was pretty upset about this (amongst others I believe): https://bugs.launchpad.net/ubuntu/gutsy/+source/libgcrypt11/+bug/139635
[18:33] <ubotu> Launchpad bug 139635 in libgpg-error "[cryptsetup] library dependency in /sbin/cryptsetup" [Undecided,In progress]
[18:33] <norsetto_> guest22_: yes, I'm compiling them all together and will post it to REVU
[18:34] <guest22_> norsetto: Molte grazie
[18:38] <norsetto_> guest22_: I guess pmldoc.html is the source for pmldoc.pdf ?
[18:40] <norsetto_> guest22_: sorry, I'm having connection problems, did you see this: I guess pmldoc.html is the source for pmldoc.pdf ?
[18:42] <guest22_> norsetto: No, pmldoc.html and pmldoc.pdf are both built from DocBook source.
[18:48] <pochu> pkern: if you find some documentation about it (.la removal) I'd be interested in it :)
[18:51] <guest22_> norsetto_: (Repeating in case of connection problems) No, pmldoc.html and pmldoc.pdf are both built from DocBook source.
[18:55] <LaserJock> imbrandon: ping?
[18:55] <imbrandon> pong
[18:55] <LaserJock> I gotta run for some christmas shopping
[18:55] <LaserJock> but I should be back before the meeting
[18:55] <imbrandon> cool, pick me up a eeepc :)
[18:55] <imbrandon> hehe
[18:56] <imbrandon> kk
[18:56] <LaserJock> I'm going to Cabela's, not sure if they have eeepcs
[18:56] <LaserJock> ;-)
[18:57] <warp10> Hi all!
[18:57] <geser> somerville32: you don't have i386? which arch do you have?
[18:57] <geser> somerville32: what about using PPA?
[18:57] <somerville32> geser, I'm i386 but I have a 333mhz computer.
[18:57] <geser> ok :)
[18:58] <somerville32> geser, and I can't compile binaries on amd64 for my computer, can I?
[18:58] <imbrandon> sure
[18:58] <somerville32> geser, (I have access to amd64 computers for compiling)
[18:58] <imbrandon> just setup a i386 chroot
[18:58] <geser> sure, but you'd need an i386 pbuilder for that
[18:58] <somerville32> How do I do that with sbuild?
[18:58] <cyberix> Do Debian developers care about Ubuntu deadlines?
[18:59] <pochu> Why should they care?
[18:59] <cyberix> I'm not asking, if they should
[18:59] <pochu> No
[18:59] <pochu> Unless they are Ubuntu developers too ;)
[19:00] <cyberix> Nmap 4.5 was released and I'm wondering, if it will be packaged in time for Hardy.
[19:00] <pochu> !info nmap
[19:00] <ubotu> nmap: The Network Mapper. In component main, is extra. Version 4.20-2 (gutsy), package size 732 kB, installed size 2640 kB
[19:00] <pochu> !info nmap hardy
[19:00] <ubotu> nmap: The Network Mapper. In component main, is extra. Version 4.20-3 (hardy), package size 730 kB, installed size 2640 kB
[19:00] <Kmos> it's packaged on debian
[19:01] <Kmos> need to wait for have it in hardy =)
[19:01] <pochu> cyberix: you can request a sync - you will need a good reason in order to have it accepted.
[19:01] <imbrandon> Kmos: wait for what ?
[19:01] <geser> PTS lists 4.20-3 for nmap as the last version
[19:01] <somerville32> Kmos, DIF is enacted
[19:01] <pochu> Kmos: we are past DebianImportFreeze, so waiting won't help
[19:01] <Kmos> pochu: i mean.. wait for someone of us to sync it =) hehe
[19:02] <pochu>       nmap |     4.20-3 | http://ftp.de.debian.org sid/main Sources
[19:02] <Kmos> and i think lamont changed it to zenamp as a new package in debian
[19:02] <cyberix> Kmos: It is?
[19:02] <imbrandon> pochu: and a good reason isnt so much needed untill FF
[19:02] <Kmos> so it isn't at archive
[19:02] <pochu> imbrandon: then why stop autosyncing? :)
[19:02] <imbrandon> to begin stablizing the apps
[19:03] <DktrKranz> and avoid to include more transitions which could be overlooked
[19:03] <Kmos> nmap 	4.49~rc6-1
[19:03] <Kmos> 4.50-1 source i386
[19:03] <Kmos> http://ftp-master.debian.org/new.html
[19:04] <Kmos> debian bug 456232
[19:04] <ubotu> Debian bug 456232 in nmap "New upstream version 4.50" [Wishlist,Open] http://bugs.debian.org/456232
[19:07] <cyberix> I suppose some of the major highlights (the ones that come with a text paragraph) from http://insecure.org/stf/Nmap-4.50-Release.html might be good reasons.
[19:08] <slicer> somerville32: Did you have any comments about mumble?
[19:08] <somerville32> slicer, It looked decent
[19:08] <somerville32> slicer, I only had time to look at the  diff though
[19:08] <slicer> somerville32: Ok. Thanks :)
[19:10]  * somerville32 wonders how to set up an i386 chroot
[19:12] <geser> somerville32: with debootstrap
[19:13] <geser> and the right options
[19:15] <geser> somerville32: something like "debootstrap --arch i386 gutsy /path/where/chroot/to/store http://archive.ubuntu.com"
[19:18] <\sh> moins
[19:18] <\sh> phew...new intel p4 emt64 desktop is up and running :)
[19:21] <pkern> There are still P4s? (:
[19:22] <\sh> pkern, yepp...
[19:22] <\sh> pkern, at least our old hardware from the company ,-()
[19:22] <pkern> Heh.
[19:22] <\sh> at least I can testbuild 64bit stuff again
[19:24] <pkern> While my laptop is a bit clumsy it's fun with the repaired panel and faaaast...  :D
[19:25] <\sh> pkern, but does it has a 500G sata hd? ;)
[19:25] <pkern> \sh: Point.  Just 120G.
[19:25] <pkern> Now 500G would be overly large anyway.
[19:26] <pkern> I hardly fill the 400G disk attached to my slug.
[19:26] <pkern> But for LVM snapshots and sbuild... heh. ;o)
[19:26] <\sh> well, I just grabbed some old server hw from our company as well. 2x 19" Dual PIII 1GHz ...
[19:26] <\sh> they have ide2scsi interfaces, so you can plug into plain ide hds
[19:26] <\sh> s/into/in/
[19:26] <pkern> \sh: Now that would be nice.  To hook up
[19:26] <Chipzz> \sh: why does a *server* need a 19" screen?  :-P
[19:29] <\sh> 3 or 4 1U HP stuff, and at least 2x 5500
[19:29] <\sh> fully functional
[19:29] <Nafallo> ugh
[19:29] <Nafallo> those are huge...
[19:29] <Nafallo> ...and old :-P
[19:29] <\sh> the complete rack with all the stuff inside 400 euro ,-)
[19:29] <\sh> anyone wants to buy it?
[19:29] <imbrandon> if it dident cost so much to ship i would
[19:29] <\sh> well, you need to come to germany to pick it up, sadly ,-)
[19:30] <imbrandon> yea, cant do that heh
[19:30]  * pkern hasn't got the space.
[19:30] <\sh> well, another idea is to call the guys from linux4africa project to take them to their place
[19:30]  * Nafallo doesn't need old stuff :-)
[19:30] <Nafallo> or hmm
[19:31] <Nafallo> \sh: any Cobalts? :-)
[19:31] <pkern> \sh: What kind of machines are those, anyway?
[19:31] <\sh> pkern, I'll give you more infos on monday, with pictures and all the things someone needs
[19:31] <\sh> pkern, the guy is giving me all the informations
[19:31]  * chillywilly evals some \sh
[19:32] <\sh> Nafallo, no cobalts
[19:32] <\sh> Nafallo, or you those machines which are shown in the middle of this article http://www.sourcecode.de/content/it
[19:32] <\sh> gnarf..."buy"
[19:32] <ScottK> Heya pkern.
[19:33]  * \sh needs to adjust back from logitech to sun type 6 keyboard hacking
[19:33] <pkern> ScottK: Working on it, just hacking the changelog.  :-P
[19:33] <ScottK> pkern: Great.  Thanks.
[19:33]  * Nafallo waits for the page to load
[19:33]  * ScottK just got lucky and got about 30 minuts to work on stuff due to schedule shifts.
[19:34] <pkern> ScottK: uploaded
[19:34] <pkern> ScottK: Do you have any documentation about .la removal?
[19:34] <ScottK> pkern: I think you want StevenK
[19:34] <ScottK> pkern: Thanks.
[19:35] <\sh> Nafallo, need more netspeed? ,-)
[19:35] <ScottK> Isn't tab completion fun.
[19:35] <pkern> \sh: *cough*
[19:35] <\sh> pkern, hmm?
[19:35] <pkern> ScottK: That one sleeps. \:
[19:35] <pkern> \sh: data center fun
[19:35] <\sh> pkern, it's the past the datacenter cells are empty now...
[19:36] <\sh> but the machines are still there
[19:36] <Nafallo> \sh: yes please.
[19:36] <\sh> 2796,50 Euros
[19:36] <\sh> but you need to pick them up at the companies HQ
[19:37] <\sh> 2 years ago their price was round about 12k per server
[19:37] <pkern> \sh: If I had to start a web business... maybe.  ;o)
[19:37] <\sh> pkern, na...you don't want that
[19:38] <Nafallo> I like cobalts. they are blue :-)
[19:39] <\sh> pkern, no crap...I had the whole ubuntu package archive (including source) + the whole SLES9 archive + opensuse archive *(2 archs) on those machienes...I didn't even had 1TB..I mirrored debian (i386 only but with source) for unstable stable oldstable...and it came just around 1.5TB
[19:39] <\sh> Nafallo, I don't like cobalts, because I made them orange in the past...
[19:39] <\sh> Nafallo, no joke...
[19:39] <Nafallo> ?
[19:40] <\sh> Nafallo, we had a job from cobalt and a local telco who wanted to sell orange cobalt cubes these days in the 90ties
[19:40] <\sh> Nafallo, problem...the outside needed to be orange (which was not the problem) but the whole webstuff needed to be orange too...
[19:40] <Nafallo> ah, cubes.
[19:40] <Nafallo> I was talking about raqs :-)
[19:41] <\sh> Nafallo, cobalt raqs were evil too, raq1 + 2 were crap because of logfiles and mails in the quota of the user
[19:41] <pkern> \sh: Sure such machines are fun, just a little bit... costly. ;o)
[19:41] <Nafallo> I'll probably run Ubuntu on mine ;-)
[19:42] <Nafallo> she's named smurf btw.
[19:42] <Nafallo> just waiting for the new fans to arrive now :-)
[19:42] <\sh> and raq3 well...the fcking guy of development manager didn't include any of my packages...but he was sitting on my chair damn...that was before sun was buying cobalt
[19:42] <Nafallo> then it will go in THE.
[19:42] <Nafallo> and she's a RaQ 4 ;-)
[19:43] <\sh> pkern, yepp...that's why we had to build new datacenter cells around those machines...even the racks are not standard
[19:43] <\sh> pkern, rital racks -> you need 4U for those servers, but they are 3U high...
[19:43] <\sh> pkern, so we needed special racks....
[19:44] <Nafallo> combots...
[19:45] <Nafallo> sounds like a DDoS-cluster :-P
[19:45] <\sh> well, in the first days I rolled out 200 servers with FAI...with some seti@home client on it...top 3 in one week
[19:46] <\sh> one 100 machines more and I would have beaten HP to death these days
[19:46] <\sh> and I would have been the one who found the aliens who say always "NI!"
[19:47] <Nafallo> nih!
[19:47] <\sh> Nafallo, NI! they are aliens..they don't know the char "h" ;)
[19:48] <Nafallo> \sh: sounds like french people ;-)
[19:48] <\sh> Nafallo, yeah, aliens ,-)
[19:48]  * \sh runs
[19:49] <\sh> hmmm...what do I have to do to get flash on 64bit?
[19:49] <Nafallo> install gnash?
[19:49] <Nafallo> install flash?
[19:49] <stgraber> aptitude install flashplugin-nonfree
[19:49] <Nafallo> whichever
[19:49] <stgraber> works fine with nspluginwrapper
[19:50] <somerville32> Is it safe to delete /var/apt/archive ?
[19:50] <Nafallo> do I want to upgrade my laptop to hardy yet?
[19:50] <\sh> Download done.
[19:50] <\sh> md5sum mismatch install_flash_player_9_linux.tar.gz
[19:50] <\sh> The Flash plugin is NOT installed.
[19:50] <\sh> cool
[19:50] <Nafallo> somerville32: I wouldn't.
[19:51] <Nafallo> \sh: -proposed I think
[19:51] <Nafallo> somerville32: apt-get clean
[19:51] <stgraber> \sh: yes, you can read about that on ubuntu-devel :) (basically new flash breaks with konqueror so we don't have an updated package yet)
[19:51] <Nafallo> stgraber: I installed one just today?
[19:53] <stgraber> Nafallo: I'm running Hardy here, that's like with any devel release. Everything works well if you now how to fix it and carefully choose what to upgrade :)
[19:53] <\sh> anyways....I'll deal with it later on..now it's time for some relaxing duties...like cooking
[19:53] <stgraber> hmm, maybe the new md5 is on -proposed but breaks konqueror, I haven't personally checked. I just saw the post on ubuntu-devel
[19:54] <Nafallo> stgraber: I've done all the others except warty. I'll see if I pop by a DC tomorrow then :-). thanks.
[20:01] <zxczxc> Alex look that- http://wolfgang-city.myminicity.com/ind
[20:01] <imbrandon> \sh_away: flash in gusty is broke, i have an update in -proposed atm ( it breaks konqueror though only use it with firefox )
[20:03] <Nafallo> imbrandon: why does it break konq though? that seems just weird :-)
[20:04] <imbrandon> Nafallo: konq dosent support XEmbed
[20:04] <imbrandon> and the new flash requires it
[20:04] <Nafallo> imbrandon: how silly of it :-)
[20:56] <imbrandon> hrm boring day
[20:57] <DktrKranz> imbrandon, let's make it better with a shiny meeting, then :)
[20:57] <tritium> imbrandon: you have time for boring?
[20:57] <imbrandon> tritium: only today, its a layed back saturday :)
[20:57] <tritium> imbrandon: good :)
[20:57] <imbrandon> DktrKranz: not for 1 more hour correct ?
[20:58] <DktrKranz> imbrandon, 21:00 UTC, IIRC
[20:58] <DktrKranz> and it is :)
[20:58] <imbrandon> mmm but i did manage to get alpine setup almost the way i want
[20:58] <imbrandon> all imap folders showing, gpg signing , keymaps , etc :)
[20:59] <DktrKranz> Ok, ping us when ready
[20:59] <norsetto> what meeting was I missing?
[21:00] <DktrKranz> norsetto, motu-sru, for defining new policy
[21:00] <norsetto> DktrKranz: oh right
[21:01] <norsetto> DktrKranz: I'm joining you then (in listen only mode)
[21:01] <DktrKranz> norsetto, naaah.... propose mode is better :)
[21:02] <imbrandon> jdong / TheMuso ping re: #ubuntu-meeting
[21:02] <norsetto> DktrKranz: :-X
[21:04] <DktrKranz> hoping it won't be a two-person meeting, sound like a rendez-vous to me :)
[21:06] <norsetto> DktrKranz: if imbrandon is the bad and you are the good this doesn't leave me much choice .....
[21:06] <DktrKranz> norsetto, the... erm... ugly?
[21:06] <norsetto> DktrKranz: yeah ....
[21:08] <Hippuu> hi, it seems that tuxguitar package in ubuntu is somehow broken
[21:09] <Hippuu> there are no binaries of it in repos
[21:10] <Hippuu> https://launchpad.net/ubuntu/+source/tuxguitar/
[21:11] <Hippuu> and it should probably be in universe instead of multiverse
[21:11] <norsetto> !info tuxguitar gutsy
[21:11] <ubotu> Package tuxguitar does not exist in gutsy
[21:11] <norsetto> !info tuxguitar hardy
[21:12] <ubotu> Package tuxguitar does not exist in hardy
[21:12] <Hippuu> i can download it's sources with apt-get source
[21:12] <somerville32> !info tuxguitar dapper
[21:12] <ubotu> Package tuxguitar does not exist in dapper
[21:12] <TheMuso> imbrandon: sorry I'm late
[21:13] <geser> tuxguitar never built succesfully
[21:13] <geser> Missing dependencies: libswt-gtk-3.2
[21:15] <Hippuu> ubuntu has libswt3.2-gtk-java
[21:20] <geser> Hippuu: if it's the same package, then someone needs to fix the build-dependency e.g. by providing a debdiff
[21:31] <LaserJock> imbrandon: did I miss it?
[21:31] <imbrandon> LaserJock: its going on right now
[21:31] <imbrandon> come join us
[22:10] <cbx33> hey peeps
[22:10] <cbx33> how are network devices named/mapped in ubuntu?
[22:10] <Nafallo> cbx33: #ubuntu
[22:12] <nixternal> howdy peep!
[22:12] <nixternal> err
[22:12] <nixternal> Pete :)
[22:14] <LaserJock> cbx33: hi Pete
[22:14] <cbx33> hey duuudes
[22:14] <cbx33> long time eh
[22:14] <norsetto> network devices are named/mapped in ubuntu as pete?
[22:14] <nixternal> no doubt cbx33, where you been hiding?
[22:15] <cbx33> hehe
[22:15] <cbx33> working
[22:15] <nixternal> groovy...how ya likin' the job?
[22:15] <cbx33> yeh it's good
[22:15] <cbx33> i actually have money to buy stuff
[22:15] <cbx33> :p
[22:16] <cbx33> the old job budgets were so tight I couldn't do anything
[22:16] <nixternal> good, send me some then :)
[22:16] <nixternal> I need a new bowling ball, can you provision that? :p
[22:16] <cbx33> hehehe
[22:16] <cbx33> howz it all going here nixternal, LaserJock ?
[22:17] <nixternal> going about as good, or bad, as it always has I guess :)
[22:17] <cbx33> hehe
[22:17] <cbx33> brb
[22:17] <cbx33> switching interface
[22:17] <nixternal> working on different projects now just to stay sane
[22:17] <cbx33> heheh
[22:19] <cbx33> hey hey
[22:19] <cbx33> back
[22:19] <cbx33> sorry was resetting my gateway
[22:19] <cbx33> now to see if the bug returns
[22:21] <nixternal> heh
[22:21] <cbx33> hmmm
[22:21] <cbx33> interesting
[22:22] <cbx33> my WifiCard AP seems to be working better
[22:22] <nixternal> that's always a good thing
[22:22] <cbx33> yeh
[22:22] <cbx33> hostapd + madwifi
[22:22] <cbx33> I had a pci network card that was getting the eth1 transmit timeout error
[22:22] <cbx33> and freezing all nics
[22:23] <nixternal> wifi is just evil for me
[22:26] <cbx33> let's see how long he lasts
[22:31] <pkern> Hm, who was it who set up sbuild+LVM for package building?  persia?
[22:33]  * Fujitsu has it working.
[22:34] <geser> pkern: yes, iirc there is also wiki page
[22:34] <huats> hey dear MOTUs
[22:34] <geser> pkern: https://help.ubuntu.com/community/SbuildLVMHowto
[22:35] <cbx33> right brb
[22:36] <norsetto> dear? who's dear?
[22:37] <huats> norsetto: you :)
[22:37] <huats> norsetto: how are you ?
[22:37] <pkern> geser: Well I get an obscure "sid-26079e91-10ac-41a0-8a8a-b65b888726ba: Chroot not found".
[22:37] <huats> norsetto: pfff lately it is so hard to find some time to come here...
[22:37] <Fujitsu> Sounds like the snapshotting failed.
[22:38] <pkern> Fujitsu: The snapshotting works fine with schroot alone.
[22:38] <Fujitsu> I was about to suggest you try that.
[22:38] <Fujitsu> Hm...
[22:38] <Fujitsu> So schroot alone works fine?
[22:38] <LaserJock> jdong, TheMuso, imbrandon: if we keep the tags then they should show up on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[22:38] <Fujitsu> You get a shell and all?
[22:39] <TheMuso> LaserJock: SOunds fair.
[22:39] <cbx33> w00t
[22:39] <cbx33> i think it worked
[22:39] <cbx33> hey TheMuso
[22:39] <TheMuso> cbx33: Hey there.
[22:39] <jdong> LaserJock: well that's a nice incentive to do so
[22:39] <pkern> Fujitsu: Yep.
[22:39] <pkern> Fujitsu: Hm gotcha.
[22:39] <Fujitsu> pkern: How many times have you got that error?
[22:40] <pkern> Removing the apt-get update hook I added due to a howto got me a meaningful error message.
[22:40] <cbx33> w00t
[22:40] <cbx33> who would have though
[22:40] <Fujitsu> Aha.
[22:40] <norsetto> huats: yes, so it was for me
[22:40] <cbx33> a slightly knackered pci card
[22:41] <pkern> But sbuild wouldn't cache the debs it downloads right?  Unlike {p,cow}builder?
[22:41] <LaserJock> TheMuso: you know anything about that usplash-theme-ubuntustudio package in gutsy SRU?
[22:41] <cbx33> could throw out WPA authentication on hostapd+madwifi for non Windows Xp clients
[22:41] <TheMuso> LaserJock: Yes, it needs testing.
[22:41] <TheMuso> LaserJock: I was the one who uplodaed to proposed.
[22:41] <pkern> Fujitsu: I thought that I tried it in the sudo su - pkern shell to obtain the sbuild group, but due to root-users=pkern it did not display a failure message earlier.  OBscure that is.
[22:41] <Fujitsu> pkern: Correct, it won't cache. I use apt-cacher, but one could fairly easily create a shared /var/cache/apt/archives
[22:41] <TheMuso> LaserJock: I was planning on trying to get some wider testing, with a script to make usplash display with some text.
[22:42] <pkern> Fujitsu: Hm ok.
[22:42]  * TheMuso shared apt/cache/archives between several sbuild instances.
[22:42] <TheMuso> s/shared/shares/
[22:42] <pkern> TheMuso: through schroot?
[22:42] <TheMuso> pkern: Yes.
[22:42] <pkern> TheMuso: Aye.
[22:42] <TheMuso> I just modified /etc/setup.d/10mount to mount an NFS share I have set up.
[22:43] <LaserJock> holy cow, mldonkey has been in -proposed for 276 days!
[22:44] <pkern> By the way: Anyone on feisty who could try a gajim SRU? (:
[22:44] <TheMuso> Wow.
[22:44] <cbx33> mldonkey?
[22:44] <cbx33> oooh
[22:44] <cbx33> LaserJock,
[22:44] <cbx33> I got a question for you
[22:44] <Fujitsu> pkern: I thought Nafallo was doing the SRU.
[22:44] <cbx33> hang on 2 secs
[22:45] <pkern> Fujitsu: Probably we mean different SRUs? o_O
[22:45] <Fujitsu> pkern: Well, I know he was considering SRUing something about it a week or so ago.
[22:45] <pkern> Hm, that matches, though.
[22:46] <LaserJock> Fujitsu: do you happen to know if LP can remove packages from a pocket yet?
[22:46] <Fujitsu> LaserJock: It can.
[22:46] <Fujitsu> pitti cleaned out -proposed a while back.
[22:47] <pkern> Nafallo: LP: #174406 -- Are you in a position to confirm that fix?
[22:47] <Nafallo> Fujitsu: no. I've asked for backports.
[22:47] <Nafallo> pkern: nope. only have gutsys around.
[22:47] <cbx33> LaserJock, got a sec?
[22:47] <Nafallo> pkern: looked sane though
[22:47] <Fujitsu> Nafallo: Ah.
[22:47] <pkern> Nafallo: Considering that it worked on our pool of Etch machines...  :-P
[22:47] <Nafallo> pkern: :-)
[22:48] <LaserJock> there are 9 packages in -proposed over 120 days
[22:49] <Nafallo> gaah!
[22:49] <pkern> Nafallo: Could you comment that "looked sane" to the bug report please?
[22:49]  * Nafallo fails to install JeOS :-/
[22:51] <Nafallo> bug 174406
[22:51] <ubotu> Launchpad bug 174406 in gajim "feisty: gajim does not start up correctly " [Undecided,Fix committed] https://launchpad.net/bugs/174406
[22:53] <pkern> Nafallo: Thanks.
[22:55] <Nafallo> no worries
[22:55] <jdong> Do I need to do anything else to bug 163283 for a SRU to go thru?
[22:55] <ubotu> Launchpad bug 163283 in gtkpod-aac "[SRU/Gutsy]: Two patches for gtkpod-aac" [Medium,Fix committed] https://launchpad.net/bugs/163283
[22:55] <jdong> I've already marked it verification done and subscribed -archive
[23:12] <Flare183> Why do I keep getting this error: http://paste.ubuntu-nl.org/48389/  ?
[23:13] <Fujitsu> Flare183: Your changelog is bad. Use dch to edit it in future.
[23:14] <Flare183> Fujitsu:> ok
[23:14] <LaserJock> specifically it says line 5 of debian/changelog
[23:43] <LaserJock> these shipit envelopes are kinda fun to read
[23:43] <Fujitsu> LaserJock: Are they?
[23:43] <LaserJock> yeah, they have a whole thing about Canonical, *buntu, etc.
[23:44] <Fujitsu> Oh, right, that.
[23:57] <imbrandon> LaserJock / TheMuso : wiki updated
[23:57] <TheMuso> imbrandon: ok will have a lok shortly.
[23:59] <LaserJock> imbrandon: do we want a set of links for MOTU SRU like Ubuntu SRU has at the bottom of the page?