[00:00] * nhandler only reviewed a few packages [00:00] Now, if all MOTUs would just take 1 every day... [00:01] We'd be back on track over the weekend... [00:01] "Back on track" meaning that people would get their upload reviewed within a week [00:01] mok0: how many active MOTUs are on revu? [00:02] * slytherin is still waiting for REVU hackers to implement tagging system [00:02] handschuh: Based on the stats page, not many (http://revu.ubuntuwire.com/stats.py) [00:02] handschuh: Hard to say... maybe around 10 [00:03] The Top Advocators list hasn't even been filled yet [00:03] Some of the people in top 15 aren't MOTUs [00:03] mok0: ok ... do MOTUs loose their MOTU status sometimes? [00:03] handschuh: I believe it expires every few months [00:03] handschuh: If they don't renew it [00:04] mok0: good to know, thanks [00:05] handschuh: If you look at https://edge.launchpad.net/~motu/+members you can see that quite a few have their membership expire [00:05] handschuh: perhaps some of them have moved on the main developers [00:07] heya [01:08] thanks freeflying [01:09] lfaraone: hi, still around? [01:27] james_w: hi [01:28] james_w: u r welcome [01:29] freeflying: I knew I had seen your name somewhere related to this, but I forgot it was you that wrote the file originally :-) [01:31] james_w: btw, I will upload a svn sanpshot of new fcitx to ubuntu later [01:31] freeflying: shall I refrain from syncing that fixed Debian version then? [01:33] james_w: I will based on the version in Debian :) [01:33] cool, less work for me :-) [01:40] james_w: yes [01:40] hi lfaraone [01:40] how are you? [01:41] james_w: fine, thanks. [01:41] james_w: I was working on a new package, and was wondering if bzr-builddeb is safe enough for a packaging newbie. [01:42] should be [01:43] james_w: kk. === Pici` is now known as Pici [02:15] MOTU sponsors ack for sync. <-- What does this mean in a bug report? [02:22] Leon_Nardella: if someone who does not yet have upload rights request that we pull an updated package from Debian a developer must first confirm the request before it is processed, so that we make sure that it won't cause problems [02:23] the act of confirming it is known as "sponsoring", and so that comment means that a developer is happy for the sync to take place [02:24] Thanks, james_w === protonchris_ is now known as protonchris [02:51] james_w: I've looked at the bzr-builddeb docs, and I'm wondering how I'd import from an upstream bzr tree. [02:52] why would you import? [02:52] if upstream is in bzr then branch to add the packaging [02:52] Or merge if you've already history [02:53] Same thing ought work for git, hg, svn, etc. [02:53] james_w: well, ideally I'd like to not have my repo version the upstream code, since I won't be touching that. [02:54] REVU is no longer being used for new upstream releases, correct? [02:54] this was something expressed in the Kubuntu meeting the other day as well [02:54] hey persia [02:54] if you are going to use a distributed VCS, which is great at merging by definition, why would you then layer a patch system on top, which is not going to be as good at merging? [02:55] james_w: Because we're a Debian derivative and they use patch systems mostly. [02:55] if you are not going to patch the upstream source at all then that's obviously not a very convincing argument [02:55] ScottK-laptop: true, and that argument I appreciate. [02:55] In the case of KDE, not using a patch system would make coordination with Debian substiantially harder. [02:56] ScottK-laptop: mentioning Kubuntu probably wasn't wise, this is a new package. [02:56] Also there are performance reasons. [02:56] james_w: this is a new package that I am targeting for ubuntu, but am going to submit to debian. [02:56] lfaraone: yeah, but you'll be the maintainer in Debian I assume, so there's no problem with that part. [02:56] wget the tarball then then play with the debian dir in the VCS is a lot faster. [02:57] ScottK-laptop: see... that's the problem, there is no real "tarball"... as this is a "BZR release" [02:57] ScottK-laptop: if the upstream is in bzr then performance is going to be ok for this package. I accept your point in general. [02:57] Ah. [02:58] So what's a bzr release? [02:58] presumably not really a release at all [02:58] ScottK-laptop: it's a "here's the code we've written, we havn't really 'released' it yet, but it's OK to use" [02:59] As james_w says then. [02:59] pre-release snapshot. [02:59] eesh nothing more painful than fixing Debian over the phone with the fols :) [02:59] folks* [03:00] REVU is no longer being used for new upstream releases, correct? [03:00] jdong: You could be fixing Vista. That's probably more painful. [03:00] I did find a good use for Skype as a remote desktop type program :) [03:00] nhandler: Generally, yes. [03:00] "Alright now point the webcam at the monitor..." [03:00] nhandler, Wasn't ever intentionally [03:00] persia: Wiki pages used to tell people to use REVU for new upstream releases [03:00] and it turned out to be the 180-day e2fsck on the main storage drive with is 1.5TB [03:01] any guesses how many decades that'll take? [03:01] james_w, ScottK: Note that this argument isn't about bzr vs. others, it applies generally to VCS packaging. There are two ways to do it: either include upstream source or don't. Both have drawbacks of various sorts, and both have advantages. [03:01] persia: Agreed. [03:02] nhandler, Please fix that. They aren't correct. People should add the .diff.gz to a bug. [03:02] persia: Most of them have already been patched. I just wanted to confirm this before I commented on a certain package on REVU which is for a new upstream release [03:03] james_w: Is someone working on making bzr work with python 2.6? [03:04] ScottK-laptop: yes [03:04] ScottK-laptop: I believe it is compatible [03:04] james_w: OK. It has some from __future__ import stuff in it. [03:04] That means it needs checking. As long as someone is doing it. [03:05] or rather I should say, "it is compatible". However, we have had a couple of bugs since that point due to things being missed [03:05] it seems python2.6 removed a couple of things without deprecation, though they may of course be considered internal [03:05] We're going to have 2.6 in Jaunty (not as default I'd expect), so ... [03:05] Lovely. [03:05] I haven't seen the __future__ stuff though, I'll take a look, thanks. [03:06] persia: Upon closer examination of the package, they are actually renaming it from 'foo' to 'foo-x.y' to allow multiple versions to be installed at the same time. [03:06] wgrant just grepped the entire archive's python packages for me and that's one that came up. [03:06] nhandler: Doesn't need to go on REVU. [03:06] from __future__ import generators [03:06] There you go. [03:06] it's in the embedded configobj [03:06] Thanks ScottK-laptop. [03:07] ScottK-laptop: happen to know off hand what will happen with that one? [03:07] james_w: No. I've been avoiding the topic (2.6) up to now. [03:08] ScottK-laptop: ok, thanks. I'll file a bug. [03:10] Hmm. [03:11] I doubt that needs a change... [03:11] Because generators have been available by default since at least 2.5, and probably 2.4 too. [03:12] Hey, in my python debian package the setup.py is located in $BASEOFPACKAGE/gasp/setup.py, rather than where it would normally. How do I tell CDBS that? [03:12] lfaraone: If you grab pymilter there's a setup.py in a non-standard location in that package. [03:14] ScottK-laptop: thanks [03:21] ScottK-laptop: yeah... I looked at it, and am still stumped... [03:22] ScottK-laptop: despite the rules I adopted, it still tries to use the default. [03:22] lfaraone: Pastebin your debian/rules [03:24] DEB_PYTHON_SETUP_CMD = gasp/setup.py ? [03:24] james_w: er... I _just_ figured that out. heh... [03:25] "Package liblame-dev is not available,... following packages replace it: libmp3lame-dev" "I've changed the liblame0 library name to libmp3lame0, and some packages are not yet in Lenny, so some others packages aren't installable" - http://www.debian-multimedia.org/ [03:25] how can I work around that? [03:26] output from apt-get build-dep transcode http://dpaste.com/92833 [03:28] james_w: I just did it with a build rule that said python ./debian/spf-setup.py build - Your way is more CDBS like. [03:28] my way may not even work though :-) [03:30] james_w: oh, it works perfectly! [03:30] score! [03:30] james_w: (just installed the resulting package, "import gasp" worked properly) [04:21] has anyone encountered d-shlibs before? [04:21] or the d-devlibdeps command provided by it? [04:29] I have a stupid (read simple) question. On the merge-o-matic status pages there are two different colors of green, what do the different colors mean? [04:31] I believe it is the priority of the package [04:32] It's to do with how recently it's been merged. The greener the more recent. [04:32] I don't understand the exact algorithm though. [04:40] on main: apt-setup -> installer -> red [04:40] apt -> important -> orange-yellow [04:40] at -> standard -> green-yellow [04:40] acpid -> optional -> light green [04:41] ipsec-tools -> extra -> dark green [04:44] OK. That makes sense. === asac_ is now known as asac [05:22] ScottK: the fix future import for spambayes. I've been through them all, i think there were problem ones that we moved up in the debian version (above __author__ and ___credits___) - there are some that havent moved. Did you just patch to move them higher as a matter of course? [05:29] Hi! May I ask what is the proper way of packaging software with debian/ included? [05:30] !packaging [05:30] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [05:31] Well, I want to maintain debian/ directory in my program myself and when I try to build the package from source I get warnings about "native" package [05:32] The debian mentors FAQ suggests not using native packages for general purposes, so I need an advice on those [05:33] artfwo: Someone may be able to advise better, but i believe its generally discouraged for upstream to maintain /debian [05:34] artfwo: Often something changes on the debian side, and we need to update /debian stuff for multiple packages. If bugs are filed, we cant fix them, etc [05:34] so, is it better for me to exclude debian/ from the tarball and provide .diff.gz instead? [05:34] artfwo: yes, better [05:35] ok, thanks for clarifying this :) [05:35] artfwo: http://www.mail-archive.com/debian-mentors@lists.debian.org/msg17466.html also has a thread about it [05:37] hmm, I see [06:49] If I am dropping any previous Ubuntu changes when doing a merge, do I have to mention them in changelog? Or is it sufficient to mention in the bug. [06:50] the latter [06:50] you keep the remaining ubuntu changes in the changelog [06:51] Hobbsee: thanks [06:51] slytherin: you're welcome [07:13] geser: persia: Debian's latest lucene2 version uses libdb4.5-java as build dependency. Is it ok to switch to libdb4.7-java? === doko_ is now known as doko === thinkgnu_ is now known as thinkgnu === gouki_ is now known as gouki [09:35] slytherin: I'm a big fan of dropping older versions of db. What's the user data migration strategy? [09:36] slytherin: The issue is that often different versions of db don't have binary-compatible storage, so depending on how or why it's used, transition can be tricky. [09:39] persia: I was under the impression that the db formats were compatible, and the problems only arose when transactions were involved. [09:39] Is that not so? [09:39] soren, I'm a little hazy on the details. I thought that some version changes caused larger effects than others. More than anything, I think it's worth investigation rather than blindly changing the version. [09:40] Oh, certainly. [09:40] I do know that for some packages, you can change the version without worry, and for others you need to take care. I have no idea where lucene2 falls on that scale. [09:41] https://wiki.ubuntu.com/HardyReducingDuplication agrees that only transactions are a problem. [09:43] soren, Thanks for tracking down a resource for that. [09:43] * soren tips his hat [09:44] slytherin: In the hopes you scan backscroll from irclogs.ubuntu.com: that's the doc you want to check against lucene2 to take your decision. [09:45] soren, Do you know if anyone is working to drop those completely, rather than just pushing stuff to universe? [09:45] * persia still sees *lots* of libdb* packages in jaunty [09:46] persia: Dunno. I think Debian intends to drop them, so we'd better follow suit. [09:47] Well, there's a couple archive-admins who scan sync-packages-only-in-Ubuntu and drop them every few weeks. I just like to move in advance for clearly useless stuff like that. [09:47] Personally, I doubt Debian will drop them during Lenny. === thinkgnu1 is now known as thinkgnu [11:30] Hi there, I need advice about packaging. [11:31] I'm working (first of all) on a binary package for an app I wrote, to get the feeling about how things are done [11:32] and I got a hard time having a menu entry right [11:33] here is my menu file => http://pastebin.com/m511004c3 [11:33] I'm working with dh-make tools, and got sure my 'rules' file do call dh_installmenu [11:35] usr/share/menu/qrest file _is_ part of the generated binary package, but after installing the package on my 8.04 system, I still miss the menu entry [11:35] any advice ? [11:37] deufrai: is this a GNOME or KDE app? [11:38] this is a Qt app, but I don't intend to tighten it to either wm [11:38] it should probably have a .desktop file then, rather [11:39] could be that menu files are not displayed in the Ubuntu menu by default [11:39] azeem: oh, right. I'll dig in the .desktop direction [11:39] iirc the menu package isn't installed by default, Ubuntu prefers to use .desktop files [11:40] where should this file be installed ? [11:40] see the freedesktop.org spec [11:40] azeem: ok, thanx [12:01] azeem: great ! Still need to find the right category. Thanx for your help [12:01] geser: you too === RainCT changed the topic of #ubuntu-motu to: Masters of the Universe https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Jaunty: OPEN. | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs [12:58] hello everyone [12:59] I want to package fonts. I have never made a package before. [12:59] Besides the editing a debian control file. What do I do? [13:00] et3: have you read all the packaging documentation? [13:00] slytherin: I've browsed through it last night. [13:01] I have pbuilder ready [13:01] I don't have a key yet [13:02] et3: so that documentation should tell you all the files you need to create. And since this is the first time you are creating package I suggest take a look at some existing packages. [13:02] slytherin: like hello-world? [13:03] et3: yup [13:04] alright. [14:01] stefanlsd: Yes. I just moved them all and I don't think it was needed. [14:04] Is there a way to figure out if a package in Debian has been renamed? [14:33] nhandler: check the changelog, but that only works if you knew the new name [14:36] You could also use grep-dctrl to look for Replaces: headers, which are a good indicator. [14:42] persia: do you plan to vote before you leave? (May missunderstood your mail) [14:42] If I want to provide three packages in different sections (devel, libs and libdevel), does anyone know what section do I use for the source? [14:43] the most appropriate one I think [14:43] probably devel [14:43] um.. devel? [14:43] oki dokie [14:45] sebner, For anyone who applied previously to the 20th, yes. I'm nearly done with those reviews. [14:45] persia: I see, thx [14:45] For people who applied after the 20th, I doubt I'll be able to do so. [14:46] savvas, libs usually. [14:46] savvas, Just remember to be more specific in the binary sections. [14:46] hm.. [14:46] hm.. ? [14:46] hold a sec [14:46] it's for ccod: http://ccod.sourceforge.net/ [14:47] And which packages are you planning? [14:47] from what I see, it provides/builds ccod (binary) libcsp.so (library) and a header for include/ folder [14:47] ccod, libcsp and libcsp-dev [14:48] it's not anything official, just playing arond with my PPA :) [14:48] *around [14:48] savvas, I'd probably use "devel" as the section for the package, and provide ccod (devel), csp (web), libccodX (libs), and libccod-dev (libdevel). [14:49] Also, why not for the archive, if it's not packaged? [14:49] I'm afraid I'm not that good with cdbs and making packages yet [14:49] as it is, I'm patching the ./configure and the Makefile.in to get the job done [14:50] I'd recommend working on it towards the primary archive. Once you have it in fairly good shape, get some MOTU review. [14:50] savvas: hmmm [14:50] savvas, Mostly just a social thing: if it's good for you, and you did the work, may as well share so nobody else has to do it. [14:50] mok0: I know, not a good solution, but I think ccod is not using standard makefile and configure, correct me if I'm wrong [14:51] persia: now that you mention it, I have a fairly good package of libbusiness-issn-perl: https://launchpad.net/~medigeek/+archive [14:51] savvas: oh, I don't know what it's using. It's just that patching configure and Makefile.in is not a good way to go [14:52] should a daemon really be trying to open /dev/null with O_CREAT? [14:52] savvas: If you must go that way, it's better to patch configure.ac [14:52] savvas: and Makefile.am [14:52] james_w: no [14:53] savvas, Well, if you've a good package, get some reviews :) I'm sure someone will find a couple issues (always happens when I package things), and then it can be part of Ubuntu. [14:53] james_w, Only O_CREAT, or is that one of several flags? [14:54] mok0: well I see that the debuild sequence of commands actually instructs the make install with DESTDIR= variable that points to the correct debian/tmp/ directory, but it doesn't use that. Also there is no --prefix argument for ./configure [14:54] O_CREAT | O_APPEND | O_RDWR [14:54] persia: you said yesterday that you were looking at supercollider-gedit... apparently you didn't finish your review? [14:54] mok0: any handy links I could read about? :) [14:54] james_w, A defensive programmer will often add O_CREAT when opening things for output to avoid a crash. This is especially useful for /dev/null because you don't care about the output anyway. Mind you, without some other flags, it's kinda useless. [14:54] savvas: ... you mean about ... configure.ac? [14:55] mok0: yes, and Makefile.am [14:55] savvas: I'll go look [14:55] mok0, I haven't, but will definitely do so before I leave. [14:55] persia: great, thanks for the info, but.. where do I apply for review? [14:55] mok0, Also, thanks for clearing some of the old ones. It's looking less bad. [14:55] persia: great. AFAICS supercollider itself is in the "update" section [14:55] !revu | savvas [14:55] savvas: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [14:56] I see, thanks! [14:56] mok0, Yep. That's a bug in REVU that I've reported to the REVU hackers, but I want to leave it alone so they can try to fix it. [14:56] let me bookmark that link :) [14:56] savvas, There are also other ways to get reviews, but that's the most common method. [14:56] persia: ... because that's the last upload from May still hanging around... [14:56] savvas, General rule of thumb is that two Ubuntu devs should have looked at a package before it gets approved. [14:57] mok0, Wow! Thanks for chasing the others. [14:57] now the other question: is it better to aim for a debian package or an ubuntu package? [14:58] savvas: here's a nice little short one: http://www.developingprogrammers.com/index.php/2006/01/05/autotools-tutorial/ [14:58] savvas, Hard to say, but Debian is generally preferred. [14:58] I'm not sure either is "better", but it's always more polite to share. [14:58] savvas: otherwise look at the GNU documentation for automake and autoconf, it's really good [14:59] mok0: if you come across any java packages on revu, let me know. [14:59] slytherin: will do :-) [14:59] or do they cross-exchange packages? [14:59] ok, we'll start from ubuntu going upstream :) [14:59] *we'll = I will heh [14:59] thanks mok0, noted [15:00] let's see if I can tame this puppy [15:00] savvas: go go go [15:00] ah one last thing! should the maintainer use gpl for packaging or follow the license of the included code? [15:00] * mok0 is hungry but fridge is empty :-( [15:01] savvas: just follow the license of whatever you're packaging [15:01] savvas, Well, if you do your packaging completely from scratch, I'd recommend using the same license as upstream (unles it's particularly onerous). [15:01] hm.. ccod is licensed with MIT license [15:02] savvas, Alternately, if you're copying packaging from another package, you might have to use the licensing for that packaging code. [15:02] and the package with dh_make suggested gpl in debian/copyright for the packaging [15:02] savvas: you can use the 3-clause BSD with that I think [15:02] savvas, That gives you a *lot* of flexibility, but it means you'd do better to avoid GPL packaging, as it might lead to questions about the license of patches, and could conceivably cause issues sending stuff upstream. [15:02] the what? :P [15:02] savvas: it does that every time :-) [15:03] ok thank you both [15:03] so for the ccod packaging I put everything under MIT/X consortium whatever license [15:03] mok0, "BSD" license can only be used by the Regents of the University of California (see /usr/share/common-licenses/BSD). Please recommend "MIT" or "ISC" as portable licenses with similar intent. [15:04] (there are *many* "BSD-like" licenses, but they aren't properly BSD, and so "BSD" is at best confusing) [15:06] so.. I'm right? MIT-licensed packaging for MIT-licensed code? [15:09] bah anyway, that's minor details, let me see if I can actually package it properly :) [15:09] persia: ok [15:10] weird, there's no MIT in common-licenses, it's not that common I presume? :) [15:10] savvas, There is no "right". The recommendation would be to use the same license where you can. Just check your sources carefully to make sure that you can use that license. [15:12] I'm really not good with legal documents - I can just promise that I'll try heh.. [15:12] savvas: nobody is, not even those who make the law. :-P [15:15] :) [15:17] Trying is the important part. Licenses are important, but for the most part as long as you check the license for any code you copy, and license any code you write in a way that is compatible with that with which it will integrate, you're fine. There's lots of sites that list various charts of license compatibility. [15:17] I am looking for someone who can take a look at the package uiflite (http://revu.ubuntuwire.com/details.py?package=uiflite) and maybe be the second advocate [15:20] mok0: hey, in your collectd merge left it with an unsatisfiable build dependency on libupsclient1-dev, was that intentional? [15:21] james_w: yes [15:21] persia: arn't you meant to be in the mountains? [15:21] james_w: because there's a bug in the current package that makes the build fail [15:21] ah, ok [15:22] might be good to note that in the changelog in future :-) [15:22] james_w: you are right..,. finding the bug link... [15:24] bug 299489 [15:24] Launchpad bug 299489 in nut "[jaunty] /usr/lib/libupsclient1.so is a dangling link" [Medium,Fix released] https://launchpad.net/bugs/299489 [15:24] stefanlsd, Not yet. I like to give a few days notice so I can complete the list of things I've compiled to do before I leave. [15:25] Ah, fix released [15:25] ah, that one [15:26] james_w: I am hoping the build will resume once the depends are satisfied [15:26] it's not really fix released [15:26] james_w: "a sync has to be requested" [15:26] yeah [15:26] don't know where [15:26] james_w: or a merge? [15:28] mok0: it looks like it needs a merge [15:28] Saturday afternoon... everyone is downloading movies for tonight... my network conn has slowed to a crawl [15:30] james_w: You have a special interest in nut? [15:30] nope, no idea what it is [15:30] james_w: it's a UPS client [15:31] at least part of it is... that is why it is used by collectd I guess [15:31] james_w: ok, I will merge it and upload [15:32] persia: where are you leaving? [15:33] thanks mok0 [15:34] slytherin, That's an interestingly phrased question. I'll answer "Japan". [15:34] persia: going on vacation? [15:34] UDS? [15:34] slytherin, That is the intent. [15:35] mok0, I'll end up there as part of it. [15:35] persia: ok [15:35] mok0: I would check that something that uses the pkgconfig file from nut will build correctly. The change in -9 doesn't look sufficient to fix all the problems to me. [15:36] james_w: thanks for the warning [15:36] mok0: the pkg-config file will tell whatever is building against libupsclient that it should use -L/usr/lib but the libraries will be in /lib [15:36] james_w: oh? I though he fixed that [15:37] persia: so how long will you not be available for sponsoring bugfixes/syncs/merges? :-D [15:37] mok0: the symlinks will now be correct, but the pkg-config file may now be wrong. [15:37] james_w: Hmm. The pending package assumes it's going to find the library in /usr/lib. [15:38] james_w: I am not sure that collectd uses pkgconfig, but I will check. [15:38] slytherin, 2-4 weeks, depending on a wide variety of factors. I'll have network access by the 3rd or 4th, but don't know how busy I'll be with UDS, and then getting back. [15:38] it does [15:38] james_w: I don't see that those libraries belong in /lib [15:39] They _really_ ougth to go in /usr/lib [15:39] mok0: that was the Debian maintainers decision, and what led to these issues in the first place [15:39] persia: no issues, I will bug geser. :-) [15:39] Hello all. [15:39] It may even be policy? Where universe components are supposed to put things? [15:39] mok0: the binary is in /bin, so the libs should be there as well, no? [15:39] azeem: hmm [15:39] we had this discussion before with LaserJock [15:40] I think he filed the Debian bug [15:40] azeem: ... and why is the binary in /bin?? It's not an essential system component [15:40] apparently they think it is [15:40] jpds: hi [15:40] mok0: well, /bin is also for stuff which is needed before /usr is mounted, not sure this is the case here [15:40] Yeah. Unless it's needed before /usr is mounted, it ought be in /usr. main/universe doesn't matter for this: it's related to how the package works. [15:41] azeem, james_w, in my opinion the whole nut package belongs in /usr [15:41] slytherin: bug me? for what? /me checks scrollback [15:41] It's not about being "essential", it's about being part of the early startup cycle. [15:41] mok0, Check the rdepends properly. Maybe something needs it in /bin & /lib [15:41] persia: a UPS client is essential before mounting /usr?? Naahh [15:42] mok0, Well, when does it startup? [15:42] persia: OK, I will take a good look [15:42] If it's started by a udev hook, quite possibly. [15:42] or maybe if it's fscking /usr and losing power.. *shrug* [15:43] laga, Well, that's a use-case for why, but unless it actually could get started before /usr mount, the package doesn't support that use case (which is a different sort of bug). [15:45] * mok0 is hampered by the slow internet... there's a delay on every character typed on my remote system terminal connection :-( [15:45] mok0: yeah, I know this :P [15:48] Hm, well I'll need to make a link from /usr/lib/libupsclient1.so to /lib/libupsclient1.so.0.0.0 otherwise the pending build will not make it. [15:51] Ah, this slow internet is killing me. I have to move close my laptop, leave my comfy position in the couch and fire up my linux box. *Sigh* [16:17] hey folks... can I keep certain open source libraries that are third party in my project if I keep the licenses and credits available? [16:18] JonReagan: in source form? [16:18] yeah.. well, they are .jars [16:18] and I think I may be able to remove some [16:18] JonReagan: then the asnwer is no [16:19] but some have been modified from the original source, and others are no longer available [16:19] s/asnwer/answer [16:19] dangit. [16:19] well, thanks for letting me know [16:19] JonReagan: you should consider making them separate packages [16:20] ah, k [16:20] JonReagan: or, if the external libraries are really trivial, include the sourcecode [16:20] JonReagan: can you name me the external jars? [16:21] eh... yeah... it will take me just a sec [16:25] most of the jars have to do with ant and other apache services (batik, jakarta, etc.) [16:25] but one in particular [16:25] will be hard to separate [16:25] because apparently the host project for it is dead [16:27] whats the name of the project? [16:27] (that you want to package) [16:27] openproj [16:27] it's in REVU [16:28] http://revu.ubuntuwire.com/details.py?package=openproj [16:28] ok I will check the orig.tar.gz [16:29] thanks! [16:29] slytherin posted a comment for some to-do stuff [16:29] some of the things I have already fixed, but I haven't created a new build yet. [16:30] where are the jars in the orig.tar.gz? [16:31] they are under... *checks own package* [16:31] found them [16:31] contrib/lib it was [16:32] yup, that's it [16:32] ok the common-* jars are in the repos [16:32] ah, k [16:32] junit also [16:32] the jasper-folder looks also very good [16:33] groovy is the same [16:33] JonReagan: have you checked if some of the jars are already packaged? [16:33] I looked for the JasperReports [16:33] but couldn't find it [16:33] geser: we are checking this right now :-) [16:34]