[00:00] blueyed: I've to go for a dogwalk now, but I'll try that when I'm back. Thanks! [00:01] welcome, have fun :) === lifeless_ is now known as lifeless [00:23] hi [00:24] there is a little problem with REVU :) http://revu.tauware.de/details.py?package=awn-extras-applets [01:02] Dear everyone: Please stop and think about if your change is appropriate to Debian before sending them a patch and a bug. [01:08] sorry [01:09] is it still valid to propose software ? [01:09] You can always propose. It may well not be accepted though :) [01:09] oh, I'd get very angry then :-D [01:10] tacone: we are near Feature Freeze so it's likely a bit late... [01:10] tacone: but is that new software or changing a default application? [01:10] new software [01:10] may sound stupid. a little game, which work like a charm with ubuntu [01:10] there's already a .deb on getdeb.net [01:11] You have 10 days until Feature Freeze. After it your chances are low. [01:11] tacone: is it Debian? How is it called? [01:11] where should I propose ? [01:11] teewars [01:11] File a needs-packaging bug in Launchpad, (and a RFP in Debian) [01:11] it's got nice reviews. and it's very simple and addicting. http://www.getdeb.net/app/TeeWars [01:12] should I propose that in debian too ? [01:12] tacone: If it gets into Debian first, its a lot easier to get into Ubuntu. [01:13] The game looks nice indeed [01:13] themuso: it's already packaged [01:13] there's a .deb on getdeb.net. [01:13] * pochu looks for bddebian to get it packaged in pkg-games :) [01:14] But he isn't around... [01:14] tacone: Yes, but that may need extra work before its accepted into Debian/Ubuntu. [01:14] I understand that. [01:15] I don't know how to file a need packaging bug. where do I specify 'need packaging' ? in the bug title ? [01:16] is a rules error or dependency error? [01:16] http://paste.ubuntu-nl.org/54796/ [01:16] :) [01:18] tacone: yes, and add a "needs-packaging" tag [01:20] just submitted. looking for the change of attaching a tag [01:21] done, nice ! [01:21] https://bugs.launchpad.net/ubuntu/+bug/189118 [01:21] Launchpad bug 189118 in ubuntu "Teewars would be a nice inclusion for hardy" [Undecided,New] [01:21] :-) [01:21] vorian, looks like a file missing [01:21] I am no expert though [01:21] :D [01:21] you are doing awesome effie_jayx :) [01:22] vorian, I am going the distance... :D [01:22] Heya gang [01:22] i'm converting my package to be compliant with the debian/python policy [01:35] the updated souce seems to have several files changed. there is a whole bunch of files that are in .install file that are not in the soucer package... do this get created or I have to find the list somewhere? [01:40] hrm does gparted safely resize a ext3 part ? [01:40] imbrandon: sure, i just did one a few weeks back [01:40] cool [01:41] it needs to lead though [01:41] yea thats no biggie [01:47] ah, there is no setup.py [01:54] slangasek: Excellent responsiveness on sync requests today (sync done less than an hour after I request it). Thanks. [01:57] ScottK2: nah, I think I need to get a start on those earlier in the day, so I can be /off/ that page by the time your sync requests come through ;) [01:58] (looks like I won't get any new processing done today, for instance...) [02:01] heh [02:06] jdong: bug #175344: are you sure it was the intention of the original bug submitter to request a backport, as opposed to an SRU? The bug title here comes from Kmos, who I think may have misapprehended the submitter's concerns [02:06] Launchpad bug 175344 in gutsy-backports "Please backport ntfs-3g 1.1120 from Hardy" [Undecided,In progress] https://launchpad.net/bugs/175344 [02:08] slangasek: for the specific issue the submitter cited, yeah, it's SRU material .However, there's also new features (faster perforamcne, relatime support and default) that make the release worthwhile in any case [02:08] * twitch * [02:08] jdong: Then shouldn't the SRU be done first. [02:09] ScottK2: I think they are independent matters that can be approached in any order [02:09] icky [02:09] yes, the order shouldn't matter [02:09] ScottK2: if we SRU it, I'd also like to look at the 5+ other issues addressed in the versions between gutsy and hardy :) [02:09] jdong: OK. My experience has been that once you do the backport the interest in working out the SRU goes WAY down. [02:09] ScottK2: and before long, that's gonna be the same thing as just a backport :D [02:09] but I'm not sure if pushing a backport with this poor user's name in the changelog is the right thing either, since I don't think that's what he was requesting [02:10] Slap jdong's name on it then. [02:10] slangasek: Only my name gets put in the changelog, right? [02:10] ScottK2: only if Canonical sends me an official Ubuntu scapegoat t-shirt :) [02:10] jdong: You've been wearing that one for years. [02:10] jdong: uh, I've been following the same convention as for syncs, which is that the original bug submitter gets their LP id used in the backport [02:11] slangasek: interesting :) [02:11] slangasek: Normally for a backport I'd suggest you put whoever ack'ed it for backporters. [02:11] if I should use you for all of them instead, that would certainly save on typing ;) [02:11] slangasek: the other archive admins previously have been following the convention that it goes to the approving backporter [02:11] ok, that's fair [02:11] slangasek: yeah I think that's a better way of doing it [02:11] slangasek: Your odds of having someone mind after problems go way up that way. [02:12] slangasek: often times backport requesters aren't of the technical skill level of a sync requester and would be less able to deal with the responsibility of the changed-by blame trail ;-) [02:12] slangasek: not to mention FTBFS mail should be directed at a backporter :) [02:12] not that I'm all that interested wine didn't build on sparc256 or whatever :) [02:12] right, let me go through and redo these... :) [02:13] hehe :) [02:13] who's the ntfs-3g dude around here? [02:13] I like the stick the tag on jdong no matter who did it plan. [02:14] That'd be you, now. [02:14] :) [02:14] I was wondering if we should update to the latest upstream release before review [02:14] release* [02:14] http://ntfs-3g.org/releases.html their release notes always sound intriguing [02:14] though that 2121 release sounds scarily intrusive [02:14] Well I'd be really careful about an ntfs-3g backport no matter which version it was. [02:15] ScottK2: the main mode of failure for one would be some sort of FUSE API incompatibility blowup [02:15] causing ntfs-3g to be inoperable [02:15] historically the QA from ntfs-3g upstream is quite superb [02:15] everytime i see ntfs it makes my skin crawl [02:15] I believe they have a test suite too :) (gasp!) [02:17] How can I search for packages which build-depend on a given package? [02:18] blueyed: grep-dctrl [02:21] slangasek: so you're the poor unfortunate soul stuck with processing all those backports I triaged this weekend? :D [02:22] yes [02:22] * jdong gives slangasek half of this yummy cardboard^Wprotein bar he's snacking on :) [02:22] next time, take a Wednesday off to do those ;) [02:22] haha :) [02:22] Night MOTUland! [02:22] ask backports requestors. I don't do this often :D [02:23] how does the debian/python policy apply to a package which is built with a configre/makefile? [02:23] this is killing me :P [02:24] StevenK: thanks, but I can't get it to do what I want.. would I have to grab some Contents file for this? [02:24] I've tried e.g. "grep-available -F Build-Depends sun" [02:25] Contents lists what packages provide what file, that is hardly revelant [02:25] blueyed: grep-dctrl -FBuild-Depends -sPackage sun < /var/lib/apt/lists/*Sources [02:28] jdong: do you think 175344 should also have an SRU, then? If so, would you mind nominating it for gutsy? (TTBOMK I still can't nominate bugs without them immediately being accepted) [02:28] bug 175344 [02:28] Launchpad bug 175344 in gutsy-backports "Please backport ntfs-3g 1.1120 from Hardy" [Undecided,Fix released] https://launchpad.net/bugs/175344 [02:28] slangasek: :-/ I'm hesitant to do so because I'm not sure what the scope of that SRU would be [02:29] I'm not familiar with upstream's codebase or release habits [02:29] ok [02:29] but I will add a comment [02:29] and also flip (presumably Kmos's) invalid marking on Ubuntu [02:30] jdong: You can check the activity log for that. [02:30] 10 Dec 07 18:49 Marco Rodrigues ntfs-3g: status New Invalid [02:30] surprise! [02:31] StevenK: thanks, works (in zsh). I'd expected more packages then 25 though (B-d on sun's java) [02:34] * Hobbsee refuses to comment, but wonders about how many *other* good bugs have been mangled, due to him, and if anyone plans on reverting the changes [02:34] i guess people will rereport, particularly in hardy+1 [02:40] Can somebody plz help. I am in the debian NM queue and am maintaining a couple of packages which are also in Ubuntu, xball and vobcopy. My sponsors have uploaded new versions of both programs recently. How can I get them uploaded to Ubuntu as well. They are both in sid. [02:41] vorian: The build system doesn't affect policy. [02:42] sgbirch: they are both in Ubuntu already. To get the latest release synced, you should file a sync request. [02:42] sgbirch: I could file the sync request, if you want. [02:42] vorian: Either convince the upstream makefile to shove stuff into policy compliant locations or make your own setup.py, add it to the debian/dir and then use that. [02:43] blueyed: Better he files it and you ack it. [02:43] ok === wolfger_ is now known as wolfger [02:45] blueyed: This is actually my first ever contact with Ubuntu folks. I normally hang out in the debian areas. So I dont know how to file a sync request. Can you point me to the docs so I can RTFM plz? [02:45] sgbirch: Do you use pbuilder for test bulding? [02:46] sgbirch: docs are at https://wiki.ubuntu.com/SyncRequestProcess [02:46] blueyed: Oh ... I just noticed your offer to file the sync req. Would you please, that would be great. Two packages .... xball and vobcopy. [02:46] I'm testing currently if they build and will do so then. Seems more straightforward, doesn't it, ScottK? [02:47] blueyed: Yes, but if you do it, he doesn't learn and can't do it himself the next time this comes up. We want to help everyone learn that comes here. [02:47] ScottK2: No, I use a clean VM loaded with sid [02:48] hi all [02:49] sgbirch: OK. You might want to consider setting up an Ubuntu Hardy VM so you can test build on our toolchain. It'd make it more credible/less work for us if you've already done the test build when you come ask. [02:50] I'm preparing a new version for mnemosyne but upstream packages it as -.tgz. Should I repackage it ? [02:51] mruiz: Just rename it. That's not repackaging. [02:51] mruiz: You have to rename .tar.gz to .orig.tar.gz in any case. [02:52] ScottK2: OK .. I am happy to do that. Although I am working towards DD I run Ubuntu on all my machines :-) I really want the two packages I currently maintain and future packages to always go into debian and ubuntu. So the Ubuntu learning curve is important to me. [02:52] Excellent. [02:52] sgbirch: I'm the same. I run Ubuntu, but am in NM. [02:53] ScottK2: Very cool. [02:53] ScottK2, thanks... I'm asking as tgz is different to tar.gz ;-) . I read that tar.bz2 should be processed in a different way [02:53] sgbirch: Welcome. You might also want to consider doing packaging work in Ubuntu and maybe becomine a MOTU. [02:53] mruiz: I missed the bz2 part. Yes. You need to reroll that. [02:53] :-) [02:54] ScottK2: Yes ... that is very much on my mind, Id like to do that. I actually do packaging professionally in my day job ... but that doesn't mean I am an expert by any means :-) [02:54] A tar.bz2 only needs to be recompressed, not repackaged entirely. [02:54] sgbirch: Well we're always looking for help. [02:55] ScottK2: How long have you been in the NM queue? [02:58] belated thanks ScottK :) [03:35] Oh well. I guess he left [03:35] vorian: You're welcome. [03:35] :) [03:43] bye all [03:43] good night [03:43] ScottK2: Did you scare another one away? :) [03:43] Night mruiz [04:02] w00t! GO BLUE! [04:02] sorry, seen the umich :) [04:03] yay, from my state :) [04:04] hey, I need some opengl love here...I have a file that includes , that is apparently a part of mesa-common-dev, I shouldn't have to dep on that should I [04:04] go umich people :) [04:04] jdong: my state too! :) [04:04] booo [04:04] ahh, one of them hairy nut fans [04:04] :D [04:04] nixternal: I always thought you were in chicago for some reason? [04:04] shouldn't it be libglu1-mesa-dev [04:04] you know, I need to stop saying that, because people who do not know about a buckeye may wonder [04:04] vorian: and your highway patrol owes me money! [04:05] jdong: I am, but I was born in Benton Harbor, MI [04:05] lol [04:05] all of my family is there [04:05] hahahaha [04:05] jdong: yah yah yah :) [04:05] nixternal: ah, ok, cool :) [04:05] vorian: seriously, blinker lights too bright? [04:05] Penguicon in DTown in a couple of months, who's going? [04:05] * vorian raises his hand [04:05] jdong: let me guess, clear tail lights? [04:05] nixternal: depends on whether or not This Wonderful Educational Institution will give me time off ;-) [04:06] nixternal: and actually, no, stock lights on a grand cherokee [04:06] I will be broke, so everyone is buying me food and drink [04:06] nixternal: but admittedly they are stunningly bright in the night [04:06] wow [04:06] with Michigan plates I bet :P [04:06] vorian: yup [04:06] :) [04:06] I got pulled over because they said my blinker lights were to bright here in Chicago...but my truck has custom carbon fiber tail lights [04:06] vorian: no front plate so no laser tickets :) [04:06] that would be your first problem [04:06] oh, and they are damn bright [04:06] nixternal: ah, interesting :) [04:06] it is a xeon bulb that you can find in some fog lights :p [04:07] err [04:07] zenon I think is what they are [04:07] nixternal: I was let off with a warning, though my sarcasm nearly cost me the $120 :D [04:07] xenon [04:07] hahaha [04:07] xenon, that, that's it [04:07] I've been considering adding HID front and LED rear lights [04:07] oh bother [04:07] I am ordering some LED from ebay for the rear myself [04:07] I even have a nice strip of Luxeon Star and Nichia CS reds that I stripped off an ambulance light bar [04:07] (legally!!) [04:08] nixternal: anywhere but ebay! [04:08] haha [04:08] vorian: best price for them [04:08] I'm guessing I should NOT use those lights in Ohio :) [04:08] well the place I might order from has an ebay store [04:08] I am starting to hate opengl [04:09] slangasek: you still awake? [04:09] nvm I answered my own question [04:10] nixternal: are you looking for `The OpenGL utility library development environment'? [04:11] jdong: because you saw me still doing archive processing? :-P [04:11] slangasek: well I had no idea whether that was activity or LP lag :) [04:12] slangasek: but it was regarding the bzr-svn tangle, I noticed jpatrick also had requested/approved a bzr-svn backport [04:12] slangasek: at any rate, hold off on both for now and let me look at this 0.4.7 that jelmer wants :) [04:13] and with that, I disappear off into the night :) [04:13] aaahhh the LP mail has started! [04:14] slangasek: oh btw I bet at least 2 of the backports you processed today will instnatly end up in source NEW so if you could push those through after you're done too... *hugs* [04:15] vorian: I figured it out I think [04:15] might help to update patches/series [04:15] schweet [04:16] bddebian: No. He heard you were coming. [04:17] * jdong wonders if there will be nuclear fallout from firefox-3.0 entering gutsy-backports :) [04:17] lol [04:17] jdong: For someone who has disappeared, you talk a lot [04:17] StevenK: I'm a bad magician... I can never disappear completely on the first try [04:19] jdong: ah, I think I'm running away for the night after the backports themselves are done, sorry [04:20] slangasek: sure thing :) [04:21] * StevenK kicks libosso [04:22] I change the dbus security policy for its dbus service, and now hildon-desktop SEGVs inside libosso [04:22] s/its/libosso's/ [04:30] ScottK2: Heh, zing :-) === asac_ is now known as asac [04:57] Hi, I have two lintian warnings I would like explained to me - "W: kompozer source: desktop-file-but-no-dh_desktop-call" and "W: kompozer source: out-of-date-standards-version 3.7.2 (current is 3.7.3)". Are these things I need to worry about? [04:59] hello, i would like to get involved and help with bugs or packaging, but i am not sure where to start. I have been reading all the getting started and faq pages, but I need help finding something small and easy to start with. Can anyone help me out? [04:59] tonyyarusso: The first means you are installing a .desktop file and don't call dh_desktop in your rules file [04:59] tonyyarusso: The second you can update if you're worried about the warning [04:59] StevenK: What changes are there in the standards version that I would need to update? [05:00] tonyyarusso: There is a checklist installed by the debian-policy package [05:00] StevenK: Okay, I'll look for that. [05:00] desktop thing first.. [05:03] StevenK: Would that go in install: build or binary-indep: build install? [05:05] tonyyarusso: In binary-indep [05:06] tonyyarusso: The first word there is the target name itself, the others are what that target depends on. [05:06] StevenK: I still don't quite understand that. [05:07] tonyyarusso: binary-indep is a Makefile target, which requires that the targets build and install are up to date before it runs [05:07] ok [05:15] Okay, the only warning I have now from lintian is "W: kompozer source: not-binnmuable-all-depends-any kompozer-dev -> kompozer" [05:17] What's binnmuable mean? [05:17] Able to be binary-only NMU'd, a Debian-ism [05:18] Means you don't use (>= ${binary:Depends}) in kompozer-dev's Depends line. [05:18] Yeah, I was using Depends: kompozer (= ${binary:Version}) [05:19] Oh, that should be okay [05:19] Actually, >= [05:19] binary:Depends is my brain going funny [05:20] the lintian notes suggest Depends: kompozer (>= ${source:Version}) [05:21] perhaps I should try that? [05:22] tonyyarusso: Sure. My memory might be faulty [05:22] k [05:26] all right, looks good now [05:29] Would anyone like to sponsor bug #187576? I'd like to get the new upstream version to Ubuntu first before packaging it for Debian [05:29] Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576 [05:31] ugh this channel does not help my insomnia [05:32] LucidFox: I'm gonna have to try my best to ignore you till tomorrow morning.... Need my sleep for classes ;-) [05:32] heh [05:34] I wonder what percentage of Ubuntu contributors are students [05:39] a non-trivial portion. [05:46] Please review: http://revu.tauware.de/details.py?package=kompozer [05:55] jdong: Sleep IS what the classes are for. [06:08] Well, I guess now it's just time to go to bed and wait. If someone's considering looking at that kompozer upload, it should be all pretty straightforward changes, so hopefully nothing too complicated to worry about. 'night [06:17] tonyyarusso: Why is an upgrade on REVU? [06:17] * ScottK2 just looked at two packages and found copyright problems in both. Urgh. [06:18] ScottK2: Perhaps we should have something about people getting copyright checked out before submitting a package... [06:19] TheMuso: I think running grep -ir copyright * over the package should definitely be mentioned. These packages had all been reviewed several time before too, so MOTUs aren't looking hard enough either. [06:20] I think there is an assumtion that other MOTUs will look at the copyright. [06:20] That or the archive admins will do it. [06:25] Good night all. [06:43] good morning [06:46] ScottK2: Because I thought it was supposed to be? Please enlighten me. [06:51] dholbach> Not yet, but I'll talk to the original maintainer, thanks for the tip. You can unsubscribe u-u-s for now. [06:51] LucidFox: will do - thanks for taking care of it! [06:54] Since ScottK2 went to bed, anyone care to tell me what the proper process for getting upgrades approved and uploaded is? [06:55] tonyyarusso, generally attaching to a bug and subscribing u-u-s [06:56] tonyyarusso, but after FF, new versions will need to go through motu-release [06:56] bug fixes can still be attached to a bug though [06:57] superm1: Ah, all right. And if I do it that way, it should probably be a debdiff rather than the full thing, right? [06:57] tonyyarusso, well all depends on the situation [06:57] and the patching scheme used for the package [06:57] previously interdiffs were the way to go [06:57] if all of the patching is constrained to the debian/ directory [06:57] superm1: It was just packaging info updates - debian/control, debian/rules, and debian/changelog I think are all that changed. [06:57] the more ideal route is to link to the new archive, and then attach a diff of the two debian/ directories [06:58] or even better, use a get-orig-source rule to build the archive needed for the .orig.tar.gz [06:58] but if you debdiff two new versions alltogether, it will be a very large diff usually [06:59] understand? [06:59] Sorry, no... [06:59] okay so lets say you've got hello-world-v1 and hello-world-v2 [06:59] okay, good so far :) [06:59] between the two versions, there are tons of upstream changes [06:59] they decided that they wanted to add this wacky GUI and stuff [07:00] hehe [07:00] so you go and package up the new version based on the old one's packaging [07:00] and you're all said and done [07:00] so you debdiff the two dsc's, and its a 10 meg debdiff [07:00] well that would be silly to upload [07:00] your changes were just in the debian directory [07:01] and the diff for your changes is only like 15k [07:01] Okay, still following. [07:01] so instead, in that case you can just do a diff between the old debian directory and new debian directory [07:01] and upload that diff instead [07:01] just in your comments on the bug explain that its a diff of the debian directories, and provide a link where someone grab hello-world-v2 [07:02] I wasn't aware diff operated on directories - or do you do it file by file? [07:02] you can do it recursively [07:02] ah [07:02] the switches are something like -urN [07:02] unified recursive something something [07:02] now, as far as this link, which file precisely is it going to? Which portion is "interesting" to a reviewer? [07:02] well it wouldnt be for review [07:03] it would be for a new version [07:03] so if its say a merge from debian [07:03] and they have that new version, just say to grab the .orig.tar.gz from there [07:03] if on a website say to grab it from there [07:03] the most ideal case though, you can write a rule in debian/rules that will grab the right file for the person [07:03] if its not already present [07:04] Now, in my particular case today, the .orig.tar.gz is completely unchanged. Do I even need a link then? [07:04] now in that case you can just use a debdiff [07:04] I wish I had that kind of debian/rules fu, but sadly, I simply don't (yet) [07:04] because you're not including any new .orig.tar.gz [07:04] so no new upstream changes [07:04] (-N treats non-existant files as empty in the 'old' directory) [07:04] So debdiff makes sense now, but I should know all this other stuff for later. [07:05] well that's just one type of case, but yeah its a good idea to understand it [07:05] there are more complex cases depending upon how the package adopted a patching system which you might come across some day [07:06] like mplayer for example [07:06] * tonyyarusso installs a 1TB drive in his brain for this... [07:06] be careful with that one, its fun [07:06] I'm told I should start using quilt for my package, if I'm brave someday [07:06] (it's a mozilla thing) [07:07] everyone has their preferences on patching systems, you'll eventually learn which ones are easier for you to work with [07:07] after seeing how they operate [07:09] dholbach, ah. i've wondered about that [07:09] but never looked at the man page :) [07:09] tonyyarusso> I prefer simple-patchsys for CDBS packages and dpatch for plain debhelper packages. [07:09] So, if I'm going to create a bug whose sole purpose is the be the carrier of this diff, should I bother trying to cite it in changelog or does it not matter? [07:09] tonyyarusso> yes, mention it in the changelog [07:10] okay [07:11] tonyyarusso> as for recursive diffs, superm1 is right - run it with -urn [07:11] -urN [07:11] (u)nified format, (r)ecursive, include (N)ew files [07:11] LucidFox: wrt the changelog, I have 3 things that I did (all quite minor). How would you suggest I write that, with the bug #? [07:12] * Fixed such-and-such issue (LP: #xxx) [07:12] I meant as in should I list the same LP bug three times? [07:12] no, once is sufficient [07:12] okay [07:13] its sole purpose is to let the upload automatically close the bug [07:13] Oh, that's nifty. [07:14] As for patches, does the package use CDBS? [07:15] No. (not yet at least) [07:17] Ah, that's a shame. The CDBS simple-patchsys is not that in name only, it's really the simplest patch system out there. [07:18] the only thing i don't like about the simple-patchsys is that all patches in that directory are "automatically" applied. [07:18] so if you want to turn off one [07:18] Ah, indeed. [07:19] even temporarily you gotta move it out of the directory [07:19] whew, well there went a few hours of testing. [07:19] * crimsun uploads and drags off to sleep [07:19] superm1> but doesn't it only apply files with the .diff and .patch extensions? [07:20] LucidFox, i think so, but again, you gotta rename it then [07:20] which makes the diff's huge [07:20] (granted, that won't help if you want to just minimize the delta, which is achieved by removing just one line with dpatch) [07:20] exactly [07:21] but be it as it may, easy to use otherwise [07:22] Any preferences for what I should name a debdiff? [07:23] I name it the same as the dsc/diff.gz, but with the .debdiff extension [07:24] package_version-XubuntuY.debdiff [07:24] makes sense [07:26] In LP, there's the checkbox for "this attachment is a patch" - does that include debdiffs, in the sense more like "this attachment has code to fix it"? [07:28] * tonyyarusso guesses yes [07:29] tonyyarusso: yes [07:29] sweet [07:30] All right, I think it's all ready to go - https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/189174 if you want to see if there's anything wrong with that. [07:30] Launchpad bug 189174 in kompozer "kompozer needs minor packaging fixes" [Undecided,New] [07:31] Please review http://revu.tauware.de/details.py?package=sadms [07:34] hello [07:35] need help please [07:45] gah! [07:45] well... he will learn patience [07:48] Can anyone help me investigate this issue. There is a source package aspectwerkz2 which is supposed to provide binary libaspectwerkz2-java (arch all). Launchpad says build was successful but I can not find the binary anywhere. [07:48] slytherin, did you check the hardy NEW queue? [07:48] superm1: where to check it? [07:48] https://edge.launchpad.net/ubuntu/hardy/+queue [07:49] the first time a binary is introduced to the archive, it sits there [07:49] until an archive admin acks it [07:49] if this was already in the archive, then just give it some time to propagate the mirrors [07:50] Packages that are already in the archive that introduce new binaries also sit in binary new. [07:50]