=== MenZa is now known as kii === kii is now known as Kii === Kii is now known as MenZa [00:09] RAOF, I keep getting 404s when I build :( === MenZa is now known as Kii === Kii is now known as MenZa [00:15] look that- http://wolfgang-city.myminicity.com/ [00:17] * somerville32 sighs. [00:17] 0.3-0ubuntu2 IS listed on +packages for some reason (and now 0.3-0ubuntu1 is gone). [00:18] somerville32: That's LP magic. [00:18] It's because you're the maintainer. [00:20] And bug #125987. [00:20] Launchpad bug 125987 in soyuz "Some uploads missing from +packages" [Medium,Confirmed] https://launchpad.net/bugs/125987 [01:56] is there any way to check why a package is uninstallable without actually installing it? [01:59] run something like edos's software over the archive? :) [02:13] LaserJock: Does "ask someone else to test installing it" count? :-P [02:20] minghua: no, not really [02:20] I don't mind doing it in general [02:20] but some of my edubuntu metapackages show up [02:23] seems like qa.ubuntuwire.com/debcheck has what I want [02:25] LaserJock, want to do a quick/super-fast sponsorship? :] [02:25] hmm, depends ;-) [02:26] somerville32: what's up? [02:28] LaserJock: I thought debcheck only checks dependency-related un-installable problems, and it can't check maintainer script related un-installable problems. [02:28] LaserJock, bug #176467 but I've got a new debdiff coming up in a sec [02:28] Launchpad bug 176467 in gnomescan "Sponsor gnomescan_0.4.1-0ubuntu4" [Wishlist,Confirmed] https://launchpad.net/bugs/176467 [02:29] Am I wrong? [02:29] minghua: sounds reasonable [02:29] we'd need like piuparts for a full check I think [02:30] LaserJock, uploaded. [02:30] LaserJock: I think so. But wasn't there an email recently about piupart testing for the whole archive? [02:36] somerville32: hmm, that seems like stuff that should be done upstream [02:36] LaserJock, How so? [02:37] somerville32: why should we be maintaining that diff? [02:37] LaserJock, the diff is in debian/ [02:38] * debian/watch: Created watchfile [02:38] * debian/changelog: Fixed encoding issue. [02:38] right [02:38] but Debian should have that, not us [02:38] LaserJock, Look at the version of the package [02:39] heh ... [02:39] then my question's gonna be, why isn't this package in Debian? ;-) [02:40] LaserJock, I dunno. Persia wants all packages unique to Ubuntu to have watchfiles [02:40] so I'm just doing his bidding :P [02:41] right === ScottK2 is now known as ScottK [02:48] LaserJock, Did you unsubscribe u-u-s? [02:48] yeah [02:48] cause I'm gonna upload it [02:49] ok [02:49] * Fujitsu thinks a per-package whiteboard would be nice. [02:50] yeah, I said that a long time ago ... [02:56] 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] persia, nm, asac sponsored it [02:57] Ubulette: Excellent. That's efficiency: when he's busy, I review, and when I'm busy, he uploads. [03:00] efficient, depends. i've done those changes ~5 days ago. but nm, i'm probably too demanding. [03:03] LaserJock, how goes it? [03:04] somerville32: done [03:04] Ubulette: More efficient than waiting for me to look at it again :) [03:04] LaserJock, How long ago? [03:05] LaserJock, I don't see it [03:05] like a minute [03:05] ok [03:12] If there's anyone about (like maybe Ste [03:12] ... [03:12] 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] Help [03:14] ScottK: Do you mean just adding the POD clauses to the source? [03:15] Or do you mean extracting it for export to other tools? [03:15] Adding POD clauses to the source. [03:15] ScottK: man perlpod [03:15] persia: Thanks. [03:16] ScottK: There may be some magic I don't understand to make that useful :) [03:16] OK. Well it's a start. [03:17] i've got a few packages on queue if anyone wanna check [03:17] bug #174467 [03:17] Launchpad bug 174467 in gnome-schedule "Please sponsor gnome-schedule-1.2.1 into Hardy" [Wishlist,New] https://launchpad.net/bugs/174467 [03:20] ember: By my count, you're currently at spot 17 in the FIFO queue. Shouldn't be terribly long. [03:21] heh that one have 10 days, seb already reviewed but forgot to upload it [03:22] ember: The way I count, a review or comment resets, which skews things for cases like that :( [03:23] humpfh, lol. [03:24] persia: do you think it'd be reasonable to have a PTS-like interface on qa.ubuntuwire.com? [03:24] LaserJock: Could you expand on that a little? [03:25] well, rather than having lists of packages and looking by "issue" [03:25] (more specifically, explain how it differs from packages.ubuntu.com or launchpad.net/ubuntu/+source/foo) [03:25] I'd like to put in a package name and see all the available info [03:25] umm, we none of those have QA [03:25] *well [03:26] LaserJock: Ah, so you want to see info about FTBFS, lintian, NBS, etc from a per-package overview page? [03:26] yes [03:26] Like http://qa.debian.org/developer.php? [03:26] 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] Fujitsu: pretty much yeah [03:27] persia: POC? [03:27] proof of concept. [03:28] LaserJock: Proof-of-concent [03:28] oh, right [03:28] 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] persia: all I want is the stuff we already have on qa.ubuntuwire.com [03:29] just on a per/package basis [03:30] 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] that's what I'm getting at basically [03:30] persia: For example, http://packages.qa.debian.org/s/scim.html, if you don't know what PTS is exactly. [03:31] minghua: Yep: it's my primary source of info about Debian packages :) [03:31] persia: It pretty much has all the links related to a certain package. [03:31] persia: Okay, just to be sure you are LaserJock are talking about the same thing... [03:31] 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] persia: all I'm talking about is data we *already* have on qa.ubuntuwire.com [03:33] 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] 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] persia: right [03:35] do we have a list of where the scripts are maintained? [03:38] 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] (and LP stuff is just special searches) [03:40] thanks [03:40] (I think Steven does NBS.) [03:41] Steve, that is. [03:41] argh [03:41] crimsun: manages the NBS generation script? Thanks for the correction. [03:43] 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] hrm, a PTS like interface on a per package basis would be nice [03:47] 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] cheguevara: i seen that, thanks [03:47] kk, just checking :P [03:48] imbrandon: it'd be really nice if Launchpad did it for us [03:48] 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] just fyi [03:48] LaserJock: Yes, but LP would have to have all the other bits as well, or be linking outside LP. [03:49] 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] and realy actualy against adding things to it untill it is made floss [03:50] and stablized [03:50] 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] yea sorta heh ... [03:52] persia, imbrandon: I know I'm just saying that if they want to support distros these kinds of tools would be nice [03:52] LaserJock: definately [03:52] LaserJock: Agreed. File some wishlist bugs or write some specs :) [03:53] hmm, does apt-cacher handle multiple releases? [03:54] 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] or any apt caching app [03:54] LaserJock: a mirror or squid probably, i doubt others [03:55] LaserJock: I know apt-proxy does. [03:55] I've got 3 machines at home and with all the pbuilders and chroots I'm wasting a lot of time/bandwidth [03:55] LaserJock: The web tools do, the local tools don't. [03:55] I use apt-cacher, and it works fine over multiple releases. [03:55] LaserJock: I'm not sure it qualifies your "apt caching app" though. [03:56] 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] Is there recently any discussion about updating texlive-base in gutsy? [03:57] minghua: IIRC it was mentioned on #ubuntu-devel earlier today. [03:57] * persia thinks that was for a sync for hardy [03:57] minghua: no why? [03:57] ScottK: Thanks, I'll go read the log. [03:57] LaserJock: ML discussion on u-d-d about it being broken [03:57] :/ [03:58] LaserJock: bug 174569 [03:58] Launchpad bug 174569 in texlive-bin "postinst failure during gutsy security update" [Undecided,Fix released] https://launchpad.net/bugs/174569 [04:01] ScottK: It was a different issue on #ubuntu-devel earlier, unfortunately. [04:01] minghua: Sorry for the distraction then. [04:02] minghua: what was the problem earlier? [04:02] ScottK: No problem, at least it gives hints who care about texlive... :-) [04:02] LaserJock: Hardy issues, bug 176411, for instance. [04:02] 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] I have such a love-hate relationship with TeX [04:04] I'm not sure we can SRU all of -11 [04:04] LaserJock: I think I can cherry-pick the patch if there is interest for a SRU. [04:05] It will be quite a PITA to test, though... [04:05] seems like we can't go a release without breaking something in TeX [04:05] :/ [04:05] * minghua doesn't even have texlive installed on his gutsy. [04:05] I do for my dissertation [04:06] * minghua writes papers on his Debian. :-) [04:07] ugh, 9 to 12 inches of snow called for tonight over the next 12 hours [04:07] 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] imbrandon, what's this snow you speak of? [04:13] * minghua misses snow as well. [04:22] 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] guest22, I'm not a MOTU but I'll review for you [04:26] somerville32: thanks - I'd appreciate your comments. === asac_ is now known as asac [04:42] hi jsgotangco [04:43] ScottK: Do you still need help? [04:44] StevenK: I think persia gave me enough of a hint to at least give it a shot. Thanks. [04:44] StevenK: Are you maintaining NBS now? [04:50] persia: I'm doing NBS stuff, yes [04:51] 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] I'll have a poke. I've written my own tools anyway. :-) [04:53] StevenK: Do you have a pointer to your tools? [04:54] No, they're local, and I'm not really comfortable enough with them to have other people using them. [04:54] StevenK: Fair enough :) [04:54] 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. === gouki_ is now known as gouki [05:31] argh [05:31] this crappy printer config... [05:31] * bluefoxicy goes to get the old one [05:31] gnome-cups-ui actually works ~_~ [05:32] gnome-cups-manager rather [05:33] oh THAT was the problem, stupid system-config-printer PAUSED MY PRINTER and doesn't tell you that it's paused [05:33] remind me again WHY this worthless crap was put in Gutsy in place of something that actually works? [05:36] 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] who is steven langasek? [05:36] joejaxx: One of the archive-admins [05:36] joejaxx and persia: He's the Ubuntu release manager [05:37] Not actually an archive admin. [05:37] Also vorlon in Debian. [05:37] what is his irc nick? [05:37] :) [05:37] slangasek: joejaxx is looking for you. [05:37] ScottK: https://launchpad.net/~vorlon/+participation [05:38] oh no i was not really i was just wondering who has was [05:38] good evening [05:38] since he was doing release engineering for ubuntu [05:38] joejaxx: Long-time release manager for Debian, now also doing release management for Ubuntu. [05:38] oh ok [05:39] good evening DoubleDave [05:40] i do not feel so well :\ [05:40] have a couple of questions about lintian if anyone can lend some advice [05:40] DoubleDave: You'll do best to just ask the questions :) [05:40] persia: i think i am going to go for motu next release cycle [05:40] :) [05:41] Hobbsee: minghua hello :) [05:41] joejaxx: Cool! [05:41] k i'm building a deb package for ubuntu to eventually go into the cononical repo [05:41] Hi joejaxx. [05:41] running lintian on it though reports that there is a file in an unusual directory /opt [05:41] my whole package is being installed into opt [05:42] oh [05:42] DoubleDave: Ubuntu doesn't generally use anything in /opt. Why are you installing there? [05:42] interesting [05:42] seems trivial that I would get an error from lintian regarding this [05:43] persia: just to keep the users system clean I suppose [05:43] DoubleDave: That's why we package things. It allows software to be installed in the default locations, and cleanly uninstalled later. [05:43] do you know if they will reject the package because of that? [05:43] heya joejaxx! [05:43] DoubleDave: I would, although I can't speak for everyone. [05:44] well its a custom package its our own software so that just where we started installing it on other systems [05:45] im used to slackware so the whole debian policy is a little strange to me I guess [05:45] DoubleDave: For unpackaged software, /opt can be a real benefit. Once it gets packaged, the inconveniences of /opt outweigh the benefits. [05:46] persia: not arguing here just curious. what would be inconvenient about it? [05:47] 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] persia: I'm pretty sure packages that install to /opt will be rejected, violating FHS and stuff, you know. [05:48] minghua: I'd tend to agree. [05:48] according to FHS, "/opt is reserved for the installation of add-on application software packages." [05:48] what would be considered ad on and what is FHS? [05:48] sorry can you tell im a newb [05:48] 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] DoubleDave: Just new to Debian policies :) [05:49] the package I'm building I would consider add on [05:49] DoubleDave: no problem, FHS is Filesystem Hierarchy Standard [05:49] DoubleDave: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES [05:49] persia: yes and I must admit I've been a bit lazy about reading [05:50] thanks for your help everyone [05:50] I've seen /opt/ used for binary 3rd party software and for software that will conflict with existing system software [05:50] I'll read that link Laser [05:51] LaserJock: Ponies! [05:51] 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] persia: for co-existing conflicting software [05:52] i.e. KDE4 alongside KDE3 [05:52] lol ponies [05:52] LaserJock: If it can co-exist, it doesn't conflict. Now, about the status of the Equestrian Academy.... [05:53] Lol === CyberMatt is now known as Matt|sleep [05:54] persia: it can only exist in a different part of the filesystem [05:54] so it *would* be conflicting if it were to not be installed in /opt/ [05:54] LaserJock: So the heap of kde4 packages that just went through NEW all install to /opt? [05:55] no [05:55] * persia wants a different example [05:55] they've separated by /usr/lib/kde{3,4} [05:56] but I *have* seen it done that way for KDE4&3 [05:56] 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] no, it shouldn't [05:57] On the other hand, I can see many cases where an administrator would prefer /opt to /usr/local as an installation target. [05:57] I'm just saying that's often a case where /opt is used [05:57] LTSP uses /opt [05:57] for the client chroots [05:58] That seems odd to me. I'd have expected something under /var. [05:58] k im back with another one [05:59] verry good link by the way laser [05:59] DoubleDave: well, that is a widely accepted standard for *nix OSs [05:59] persia: you mentioned trying to keep the user from change their path correct [06:00] DoubleDave: By way of example. There are many other things that may need adjustment to use /opt [06:00] 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] DoubleDave: Why can't you use the system postgres, php, and apache? [06:01] it runs post gres with its own socket file under opt along with apach listening on a different port [06:01] would that be an exception [06:01] 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] DoubleDave: Why does it need to do that? [06:01] 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] persia: guess now that you ask im not to sure that it does its just the way my partner built it [06:03] DoubleDave: OK. At this point, I think more context is required. Is there a URL that provides information about the application? [06:04] yes nullbound.com [06:04] persia: its downloadable now in tar.gz form that is executable [06:04] it installs to opt [06:05] in my opinion its not the cleanest installer [06:05] but it works well [06:06] DoubleDave: So basically, this software is installed on a dedicated appliance, watches the network for stuff, and provides reports? [06:06] yes for the most part [06:06] it should be installed on a dedicated machine [06:06] probably do not need to install to /opt then ;) [06:07] so for you using /opt is a convenience [06:07] 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] it allows you to just drop in on many different distros without worrying about peculuarities [06:07] sorry its moving pretty fast in here... Yes conveniance LaserJock as well as cleanlyness [06:07] 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] or so I thought [06:08] 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] DoubleDave: of course there are pros and cons [06:09] 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] 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] then integration with the existing distro packages can be a bonus [06:10] trying to keep up here. lol [06:10] anyone else here have experience with the fedoa-ds source? [06:10] 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] i am trying to figure out whether i should create one source package or multiple ones [06:11] oh nevermind [06:11] one source package does not make any sense [06:11] 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] 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] nm [06:14] persia: thanks again and I am taking all of your opinions but for some reason I cant see a downside [06:14] the software during the setup asks what nic you would like to use for monitoring [06:14] so really you should have two nics anyway [06:15] 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] I'll head your advice and see what my buddy thinks [06:15] 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] 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] but if it will be rejected then I guess me complaining wont really get me anyware will it? lol [06:16] persia: the tricky thing is all the build requirements [06:16] 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] persia: i am going to have to do an audit of them [06:17] joejaxx: Just be extra careful to avoid any loops, and you should be OK. [06:17] to see if they are even necessary in ubuntu [06:17] or if they have already been applied [06:17] loops? [06:18] 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] oh [06:18] :) [06:18] 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] it works great. I'll get to makeing the package compliant [06:18] thanks again all [06:18] * persia is far too paranoid to install binary software [06:19] persia: security paranoia ftw :) [06:23] StevenK: oh i forgot to tell you, upstream calls it fedora-ds [06:24] StevenK: ref: package naming [06:26] Grm? [06:26] joejaxx: I think you meant me. [06:26] oh whoops [06:26] sorry [06:27] StevenK: He asked me about what to name his package earlier today. [06:27] Ah [06:27] joejaxx: That changes things. I'd go with the upstream name. [06:27] ScottK: ok [06:27] 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] 'cause you were sleeping (like I should be right now). [06:28] ScottK2: Right. Go to bed :) [06:28] i might have to start with the build requirements for it [06:28] lol [06:28] as some of them might not be in ubuntu yet [06:29] 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] ScottK2: Ah. DNS has a way of keeping one up at night. Good luck. [06:29] maybe i will just put it on ppa as it seems this is going to be a project to upload [06:29] lol [06:30] or it is not going to all get uploaded this release cycle [06:30] well maybe [06:30] depends on when the new package freeze is [06:30] joejaxx: Just give it a shot. There's a couple months left. [06:31] what is NPF a part of now? [06:31] i do not see it on the release schedule [06:31] joejaxx: Feature Freeze [06:31] ah ok [06:32] ahh i thought it was a lot closer :) [06:33] 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] :) [06:36] i think the fun part will be the java based parts :P [06:45] so bzr hit 1.0 [06:45] yeap [06:48] * LaserJock idly wonders if Launchpad will hit 1.0 soon [06:48] * TheMuso wonders whether that will be backported. [06:48] TheMuso: they have their own repo if not [06:48] LaserJock: Ah ok. I didn't know that? [06:48] s/?/./g [06:48] yeah, they've had it forever [06:49] that was about the only way you could keep up [06:49] Right. [06:49] anyone else having problems with the libstndc++6 package on hardy? [06:50] hmm [06:50] libstdc++6 * [06:50] joejaxx: What problems exactly? [06:50] * LaserJock raises an eyebrow as libc6-amd64 goes by in his pbuilder update [06:50] LaserJock: say [06:50] same* [06:51] failing to configure [06:51] ah [06:51] but it seems that it goes way after dist-upgrading the rest of the system [06:52] bah that stinks there are not an 3ware RAID drivers for solaris yet [06:53] brb [06:59] * TheMuso is currently mirroring hardy, as well as gutsy* powerpc. [06:59] oh and hardy* powerpc [07:00] persia: http://directory.fedoraproject.org/wiki/Licensing [07:00] joejaxx: Why me? [07:00] -persia :P [07:01] joejaxx: Next, what about it? [07:02] would any of those license stop any of those from going into universe? [07:02] 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] joejaxx: What is fedora-ds? [07:08] TheMuso: directory server [07:08] ldap [07:08] ah [07:08] Whats so special about it if its ldap? [07:09] http://directory.fedoraproject.org/wiki/Features all of this :) [07:10] ok [07:13] Nice set of features. [07:13] ScottK: I am an archive admin too, as persia seems to have pointed you to [07:13] TheMuso: :D [07:14] well i am going to retire for the evening [07:14] i will start on the build depends tomorrow [07:14] Goodnight All [07:16] Night joejaxx. [07:18] 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] I uploaded a package, and as of approx 3 this afternoon, its there. [07:21] Much better turn-around to what it used to be. [07:26] TheMuso: wow, nice. internode? [07:27] persia: I expect universe to be bug-free for alpha 2, of course ;) [07:28] Hobbsee: Yse. [07:28]