[00:00] james_w, ok good, we're on the same page, and I'm just insane. [00:00] We could pull them in if you like. [00:00] * ajmitch hasn't touched these for a long time, so doesn't exactly have intimate knowledge of the packages in question [00:01] NCommander: and if it's not to be fixed in lenny then an upload to unstable blocks the easy route for a possible RC bug fix later. Uploading to experimental for something non-experimental is a bit silly. [00:02] NCommander: if you want the fix in Intrepid, and Cody agrees then just upload it direct, it's no problem if it's in SVN. [00:03] james_w, ok, I understand now ;-) [00:04] ajmitch: The -3 changes look safe; we can pull them in if you'd like. I'd also be happy to just fix this bug, given release nearness. I'm about as happy either way. [00:05] for safety reasons, probably just fixing this for now [00:06] 'twas my thinking. Would you like the gnomedesktop dllmap rolled into the other dllmap patch, then? [00:07] nah [00:07] just waiting for pbuilder now [00:08] hm, I'll have to check it after lunch, must run out for a bit [00:09] Ok. You've unsubscribed u-m-s from that bug, right? [00:44] RAOF: of course not :) [00:45] RAOF: I'm not currently a member of u-m-s [00:46] hehe [00:47] ajmitch: That can be fixed. [00:47] it could [00:48] but none of the administrators are speaking up at the moment, so sad [00:53] Depends: libglib2.0-cil (>= 2.12.1), libgnome-desktop-2-7 (>= 1:2.23.90), libgtk2.0-cil (>= 2.12.1), libmono-corlib1.0-cil (>= 1.2.2.1) [00:53] am hoping that is proper & correct now [00:56] ajmitch: Yes, that's right. The last upload lacked the libgnome-desktop-2-7 dep. [00:56] * StevenK uploaded a rebuild of libgnomedesktop2.20-cil last night for that reason [00:56] StevenK: Yeah. That rebuild broke the package :) [00:57] :-( [00:57] Well, broke the Depends, which allowed apt to remove libgnome-desktop-2, which broke the package :) [00:57] poor StevenK, we love you really [00:58] RAOF: Well, better now, since libgnome-desktop-2 is NBS [00:58] And I'm plotting to remove it from the archive [00:58] * ajmitch dputs [00:58] Go for it, I don't see any rdepends (and ajmitch is presumably uploading a fixed gnome-desktop-sharp2 soon) :) [00:59] Hmmm. That's what I uploaded [00:59] Yeah, but you needed to add a patch. [00:59] StevenK: -2ubuntu3 wasn't enough to fix it [00:59] What did I screw up? [00:59] mono packages are spethial [00:59] Mono stuff generally doesn't actually try to resolve the .so symlink. [00:59] ok, uploaded [00:59] It hardcodes the SONAME in the .config files. [00:59] evil, isn't it? [01:00] Someone should add something to cli-common-dev to fix it. dh_i_hate_config or something. [01:00] dh_dtrt [01:00] Heh [01:01] Argh. That reminds me of some package I touched for NBS. It built but always got marked Failed to upload [01:01] * ajmitch forgot he left debmirror running over lunch [01:01] only at 33% [01:01] The version number was hard-coded in debian/rules, too ... [01:02] oh that's great to do, too [01:03] hopefully it won't take long to grab the other 6.6GB of hardy & intrepid packages [01:03] * ajmitch hugs the uncapped connection at work [01:03] * StevenK misses the 2Mbit upload/download connection at $OLD_WORK [01:04] it's somewhere north of that here [01:04] I've seen it get close to 10Mbps [01:04] I'm guessing that :-) [01:04] 802.11something [01:05] 802.11n ? [01:05] no idea, the isp installed the hardware [01:06] Hmmmm. New d-i [01:07] RAOF: upload accepted, at leastt [01:08] so my gpg key hasn't been forgotten from the keyring :) [01:09] ajmitch: Just got the mail. Thanks! [01:11] * StevenK will have to keep in mind Mono is spethial ... [01:15] YOu just need to more carefully check the build logs; there would have been a warning about failing to resolve dependencies for libgnome-desktop-2.so.2 [01:15] and you would have scratched your head, gone "whuh?" & beaten the package some [01:15] Ah yes. dh_clideps: Warning: Missing shlibs entry: libgnome-desktop-2.so.2 or gnome-desktop-2 for: gnomedesktop-sharp.dll! [01:16] you have to wonder if some of these warnings should cause it to fail instead [01:17] Yup [01:18] Sometimes; GNOME-do _also_ has that warning, because it doesn't ship a shlibs file for the internal libdo.so [01:18] something that'd have to be smarter, like checking if the library is in the package itself [01:19] Right. [01:26] file wishlists against cli-common rather than moaning, imho === cr3_ is now known as cr3 [01:55] StevenK: did you try the myodbc stuff/ [01:55] zul: I saw it built, that was really my only concern [02:01] built where? [02:01] my ppa [02:01] ah [02:01] is the ABI skew fixed? [02:01] slangasek: we should probably get a ffe because its kind of useless with the newer version of mysql [02:02] that sounds like the ABI skew isn't fixed [02:03] how do I ask for the removal of an outdated package? [02:03] perhaps [02:03] just file a bug report? [02:04] yes, and subscribe teh corresponding sponsorship team [02:08] Hobbsee: how do I find the sponsorship team? [02:09] is that the same as the maintainer? [02:09] danbh_intrepid: /topic [02:09] see the Contributing link [02:09] it mentions them there [02:09] you know the Mono 1.9.1 in Intrepid is actually basically a early beta version of Mono 2.0 [02:10] mk [02:10] so it's quite unstable and buggy [02:10] * Hobbsee notes the guy who did the mono packages has already said "no, we're not updating" [02:12] not smart, that's all I have to say [02:13] you should say it to the people working on the package, rather than using this whole channel as a go-between [02:14] emet: Also, you'd need mono 2.0 packages to actually exist before you could advocate their use. The Debian mono team has spent some time on it, and still hasn't finished packaging 2.0. [02:16] okay I am just saying I personally submitted many bug reports against 1.9.1 that were fixed in later versions, 1.9.x series of Mono was basically the beta series of 2.0, so it's equivalent to shipping Mono 2.0 Beta 1 [02:17] But do they affect packages that we care about is the more important question. :) [02:20] launchpad will be getting a large amount of bug reports that will be duplicates of bugs marked fixed in Novell's tracker, that's for sure [02:20] Hasn't seemed to so far. If you run into specific bugs with our packages, feel free to file a bug against the relevant package; there's still time to pull in bugfixes. [02:21] But there's certainly not time to pull in mono 2.0 [02:25] mono 2.0 doesn't have DirectX, does it? [02:26] coppro: In roughly the same way that mysql doesn't have opengl, yes. [02:30] yeah well the situation looks bad either way with Mono, I understand that we are too close to release to include Mono 2.0 even if Debian/Ubuntu MOTU team can package it in time [02:31] RAOF: :( [02:32] but at the same time there was a lot of bugs I've had with Mono 1.9.1 that were fixed in 2.0, but I don't know how many people will effected by them, but really it wasn't the most tested or bug free release [02:32] emet: Right. Which is why _we've_ tested 1.9.1 :) [02:33] probably not as well as Novell did as they released the updated versions heading towards Mono 2.0 [02:34] Almost certainly much better, at least for our purposes. [02:34] I am not saying Mono 2.0 is the most stable and bug free thing ever, I am sure it's full of bugs too, but it really fixed a mess of bugs between 1.9.1 and 2.0, without adding many features that could introduce more bugs [06:40] Morning. [07:06] morning [07:55] Does launchpad seem slow to anyone else? [07:56] orly_owl, Not more than usual. [07:56] I'm just looking to see if a bug for project-x has been filed. [07:57] Prompts users to agree to a free software license: http://notzzap.zzzzz.ws/project-x.png [08:43] james_w: about bug 275608, that panel is more broken than I thought, also inverts password fields, see duplicate bug 280265 -- can you please unsubscribe universe-sponsors, this is not ready yet for uploading. [08:43] Launchpad bug 275608 in network-manager-openvpn "nm-openvpn swaps ca-cert and user-cert labels when using "Passwords with Certificate (TLS)" mode" [Medium,Confirmed] https://launchpad.net/bugs/275608 [08:43] Launchpad bug 280265 in network-manager-openvpn "Wrong handle of passwords (dup-of: 275608)" [Undecided,New] https://launchpad.net/bugs/280265 [08:54] morning ! [09:48] james_w: thanks [09:49] hey morgs [09:49] morgs: does the web activity work nicely with the package pulled from Debian? [09:50] james_w: hi [09:51] james_w: it works better, although I still had some minor issue which I'm checking out now [09:53] morgs: cool, minor sounds ok to fix up afterwards. [09:54] yes [10:21] morgs: sync requests sponsored, sugar-hulahop uploaded. Would you like me to hold back on uploading sugar until the sync requests are processed? [10:21] james_w: how long do you think it will take? [10:21] morgs: not sure, few hours to a few days [10:23] james_w: OK, yes please - sugar would be broken without the others (not that it *really* matters right now since nobody's using it yet that I know of) [10:25] morgs: cool, ping me if I forget [10:25] james_w: OK, will do [10:31] james_w: you could go ahead with Bug 280424 any time, since that package is already in intrepid and didn't build yet [10:31] Launchpad bug 280424 in sugar-hulahop "Build deps wrong, doesn't build" [Undecided,Fix released] https://launchpad.net/bugs/280424 [10:31] sync requests will probably take a while [10:31] (oh, you did :) [10:31] but there's nothing stopping you from using sync-source.py [10:31] I'll add in the LP: # next time, thanks [10:31] yeah, I don't think there's a need yet, but thanks Hobbsee [10:31] y/w [10:32] Hobbsee, Is there a specific reason for that? sync-source.py tends to waste some resources, or so I was advised. [10:32] Hobbsee, Can't you just get annoyed, and sync everything anyway? [10:32] persia: specific reason for what, sorry? [10:33] For "sync requests will probably take a while" [10:36] persia: they seem to have so far. Release team seems to have been focussing on other stuff, apart from the -archive queue [10:39] and they're (mostly) the same people [10:39] persia: feel free to ask slang*asek for a ETA, though, because that may have changed. [10:40] persia: the reason sync-source.py was discouraged was that sometimes it wasn't putting the launchpad bugs headers in correctly, iirc. [10:40] the bugs fixed ones, iirc. [10:40] Oh. I thought I saw seb128 say that he would be processing some fairly soon a couple days ago. [10:41] Not syncing is frustrating, as we don't get testing of stuff where we are coordinating with upstream : only stuff where we're not. [10:41] ah, good. i hadn't seen that. [10:42] seb128 did a whole bunch yesterday === asac_ is now known as asac [12:23] if I want to post a feature-request for an Ubuntu-package, where should I post it? (small feature, writing a blueprint feels like overkill) is posting a bug appropriate? [12:24] rawler: which package? [12:24] rawler: file bug on launchpad. the request will probably get forwarded to upstream. [12:24] wireshark.. it's missing a mimetype for pcap, meaning that it can't register itself as default-program for pcap-files.. [12:25] That's a bug. [12:25] oki.. thanks. :) === mterry_ is now known as mterry [13:53] emgent: is there any particular reason https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/fetchmail/+bug/240549 hasn't been actioned yet? [13:53] Launchpad bug 240549 in fetchmail "fetchmail denial of service CVE-2008-2711" [Unknown,Fix released] [13:59] anyone know where viruskiller went? [13:59] I can't find a removal bug, and it's not in removals.txt [14:00] but it has "Deleted in intrepid-release" [14:01] james_w, Was it removed from Debian? There's a script that just culls stuff that runs sometimes. [14:01] persia: nope [14:01] it's non free in Intrepid, I just went to sync a free version and was told that it's not in Intrepid [14:02] Err, if you've a free version, that would be a regression. Complain vociferously at whoever rejected the sync. [14:05] james_w: removals.txt is long obsolete. [14:05] See https://edge.launchpad.net/ubuntu/+source/viruskiller/+publishinghistory [14:06] Which is buggy. [14:06] Huh. [14:06] It's missing a date, but it gives the comment. [14:06] persia: no-one rejected it. [14:06] thanks wgrant [14:06] james_w, How were you told it wasn't in intrepid? [14:06] persia: requestsync [14:06] requestsync will do that. [14:06] Deleted on 2008-09-30 by Jonathan Riddell [14:06] Oh. Yeah. [14:07] No reason not to put it back. [14:07] Riddell: hi, you removed viruskiller as it is non-free, I assume you have no objection to me requesting a sync of a free version from Debian? [14:07] james_w: not at all, want me to just do that? [14:08] Riddell: if that's no trouble, version in unstable please. [14:08] james_w: what's your launchpad id? [14:08] Riddell: james-w [14:09] Riddell: if you are already there would it be possible to do the requested syncs of the sugar related packages? the sugar team has been working hard on that, and would like to get on with the next part. [14:09] Riddell: no worry if not, it's not urgent. [14:09] james_w: bug numbers? I'm in a meeting just now but probably after [14:10] Riddell: thanks, I'll pull them together. [14:13] Riddell: 277798 280144 277790 277789 277788 277787 277782 277779 277778 277777 277776 [14:13] thanks [14:13] Hobbsee: yep, it`s a very minor bug. [14:17] Hi [14:17] Hi RainCT [14:51] Heya gang [14:51] bddebian, Did you get the gpib build sorted? [14:52] Heya persia [14:52] No not yet :( [14:53] OK. I saw the missing Kbuild comment, but didn't hear anything else, and didn't know if you wanted me to look deeper. [14:53] persia: I can't even find a Kbuild :( [14:53] Even in the old package? [14:55] Nope [14:55] Hrm. Odd. That should have broken the old one. [14:56] someone give me a good reason not to get incredibly pissed off at someone posting on a debian ITP i'm working on [14:56] persia: mga-vid doesn't have one either and it builds. [14:57] directhex: bug number please [14:57] directhex, All contributions are welcome, even the most minor, or those that appear to be obnoxious. Invite closer discussion, and collaboration. I'm sure you'd appreciate a tester. [14:57] slytherin, 501190 [14:57] persia, i'd appreciate both. i don't appreciate dripping hypocrisy though [14:58] directhex, Sometimes you have to ignore part of a message to get to the good bit. Sometimes the good bit is the headers. [14:59] persia, the good bit is having the *gnash* maintainer say a plugin shouldn't be allowed into debian if it isnt' a 100% compatible equivalent [14:59] visit bbc.co.uk/iplayer and get 600 meg of ram eaten, but he's acting high & mighty? [14:59] directhex, That doesn't look like the good bit. That looks like the annoying bit. [15:00] persia, i can't tell the difference these days [15:01] directhex, In that case, spend an hour in a park on a sunlit day. [15:02] persia, it's about 6 degrees outside [15:02] directhex, bundle up then :) [15:03] * persia remembers days when the thermometer read the same in F and C. [15:03] i'm being advised by my sponsor to ignore it [15:05] Right. This is one of those cases where the headers are the good bit. [15:08] persia: Do you know if I should have the .ko files before I get to that part? [15:08] I think you shouldn't, but my kernel-fu is very weak. [15:08] Join the club :) [15:41] superm1: ping [15:41] slytherin, pong [15:42] superm1: a problem with nautilus-sendto. It doesn't have dependency on libbtctl4 and hence produces an error when the library I snot installed. [15:44] superm1: I think problem is present even when library is installed. Looks like some other error. [15:44] slytherin, okay so no root cuase yet then? [15:45] superm1: Do I need to restart nautilus? [15:46] slytherin, i would think so. [15:46] slytherin, between you and crevette, didn't one of you test it? [15:46] that's what i thought the comment was on the bug [15:46] superm1: I didn't test it. [15:47] Hi all, I'm maintaining a package which creates /var/log// and /var/lib// - is it okay, in purge, to just delete everything inside those directories, or should I be more specific about what I delete? I couldn't find anything about this in debian-policy [15:49] superm1: It was nhandler who worked on it. not crevette [15:51] I am confused. :-( [15:51] this is the reason i uploaded it: [15:51] https://bugs.edge.launchpad.net/ubuntu/+source/bluez-utils/+bug/274950/comments/66 [15:51] Launchpad bug 274950 in gvfs "Look into switching to bluez 4.x" [Wishlist,Fix released] [15:52] superm1: let me try restarting machine. === persia_ is now known as persia [16:07] superm1: didn't work even after restart. Can you please check once? [16:10] Hrm. nhandler and crevette are away : they'd be the best people to pester about n-s-t not working. === bddebian2 is now known as bddebian === ember_ is now known as ember [16:45] kees: so stefanlsd, wgrant and I were thinking of changing the changelog format for -security updates [16:46] jdstrand: I'm for it. my goals would be documentation and obvious linkages between CVE#s and changed items [16:46] kees: the current format in SecurityUpdateProcedures has a couple of issues [16:46] * kees agrees [16:46] kees: cool, here is an example we came up with... [16:47] I'd like to tie CVE# to change more closely -- like how we already use (LP: #...) [16:47] kees: http://paste.ubuntu.com/55688/ [16:47] and references should probably be subitems for the fixed areas (but only when there isn't an appropriate place for them in an existing patch system) [16:47] kees: I think the example does that [16:48] jdstrand: yeah, that looks good to me, though the long series of yelling 'SECURITY UPDATE' is a bit funny. Not sure the best way to address that, though [16:48] kees: basically '*' corresponds to a patchset/CVEset [16:48] right, I like it. [16:49] kees: well, that is a holdover from the previous way [16:49] I'd like to keep "credit" in the changelog, but put patch references in the patches. when it's a native-patch, the ref should go in the changelog. what do you think of that? [16:50] e.g.: - debian/patches/blah.patch: [what it fixes], thanks to so-and-so. [16:50] and in debian/patches/blah.patch at the top: http://upstream/patch/url [16:50] kees: I'm all for the patch URL being in the patch, if the patch system supports that [16:51] kees: and credit goes in changelog of course [16:51] kees: however, I feel pretty strongly that CVE-YYYY-NNNN is in the changelog [16:51] oh yeah, for sure. [16:51] ok, wasn't totally clear on that point [16:52] kees: but in the case of a patchless system, then the patch url can go in the changelog, as a '-' item, correct? [16:52] I'm pondering that it should go maybe at the end of an update paragraph instead of as a separate item? e.g. "... check argument length (CVE-2010-1234)." [16:52] jdstrand: yeah, that's what I was thinking [16:52] Having the separate subitem format may make it easier to machine-parse them (or may not). [16:54] kees: it does make it more compact, but I think a seaparate subitem really makes it standout, which when the patch file doesn't have the CVE in the name (eg, many from Debian do not) is important [16:54] persia: ah, for the CVEs? Generally just looking at the changelog and looking for "CVE-" works, especially since debian doesn't have a standard format for it. [16:54] In that case, making it easy doesn't help. [16:54] kees: plus if we always do it, it is consistent no matter what patch system or patch name [16:55] jdstrand: always do it as a "-" item or as a "()" item? [16:56] kees: I thin always as a separate '-' is better [16:56] think [16:56] kees: at the expense of compactness [16:56] jdstrand: okay, I was on the fence, I'm happy to make it a "-" item. [16:56] it's kind of a like a mini-References section, plus the eye will always know to look there [16:57] Any chance of having a common format with Debian Security so dch -s can get into Debian and we both just use it? [16:58] ScottK: that is for versioning, no? we were talking only about the changelog text [16:58] But dch -s gives you the template. [16:58] ah. I haven't looked at dch -s in awhile [16:58] (since it didn't ever work right for me :) [16:59] ScottK: I can say that dch -s has been on my todo list for quite some time, but unfortunately, it is rather low... [17:00] jdstrand: http://pastebin.osuosl.org/22275 ? [17:00] Just a thought ... [17:01] kees: yes, with the addendum that we are putting the patch url in the patch file when there is a patch system that supports it [17:01] ScottK: honestly, these formats are more or less a guideline. I don't want to force a machine-parsable format on anyone, so I'm not sure it's needed to coordinate the format with Debian. [17:01] jdstrand: right [17:02] OK. [17:02] kees: I think that is much more clear. I'll update the wiki [17:02] * RainCT decides that he hates apt for not supporting redirects :P [17:02] s/that/this new format/ [17:03] kees: and I am going to steal your template :) [17:03] jdstrand: http://pastebin.osuosl.org/22276 ? [17:03] jdstrand: okay, sweet [17:03] kees: looks great [17:19] Heya [17:20] jdstrand: we should linked to https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines in the SUP for how to mark up the patches [17:21] * jdstrand nods [17:31] apachelogger: hey, do you have an icon of a person suitable for revu? [17:34] https://wiki.ubuntu.com/SecurityUpdateProcedures?action=info [17:34] kees: ^ please review/edit as needed [17:38] kees: heh, I of course had to make one more change :) [17:39] (in the patch tagging part) [17:41] RainCT: what size? [17:42] apachelogger: like the nuke/archive/unarchive buttons [17:42] jdstrand: yeah, looks really good. I think I'll add a note about "priority" and how it's not used in Ubuntu. (I have Debian folks ask about that from time to time) [17:42] apachelogger: it's to show it on front of the usernames, linking to their revu profile [17:43] kees: cool, I was thinking about that when I saw it, and then said: "oh, that is documented, people know about that" :) please do document it here since it isn't getting across in whatever other places it is :) [17:43] RainCT: http://aplg.kollide.net/tmp/user-identity.png [17:43] jdstrand: one sentence in parens added. ;) [17:44] \o/ [17:48] apachelogger: that one doesn't look very good.. [17:48] RainCT: please make a screenshot [17:48] apachelogger: http://localhost/Ubuntu/revu/?updated=true [17:49] apachelogger: ^ [17:49] RainCT: localhost? ;-) [17:49] apachelogger: err http://rainct.homelinux.net/revu/?updated=true [17:50] * RainCT didn't remember that links are hardcoded to localhost (in the config file) [17:51] RainCT: doesn't load images [17:51] * apachelogger assumes a misconfigured apache [17:51] RainCT, Whilst you're doing that much of a rewrite, would it be possible you could add a feature to subscribe to packages you didn't upload? [17:52] Or the hardcoding of everything to "localhost" :) [17:54] persia: that's already possible :) [17:55] persia: you've a "Subscribe" link on the details page of any upload (at the top-right) [17:57] persia: and the hardcoding (which is not really hardcoding, but a tag) was actually a feature :P. I guess I could change it to some dynamic host detection, though [17:58] apachelogger: right, that would be because of the tag too.. well, I've just decided that it doesn't look that bad after all :P [17:58] ok :P [17:58] RainCT: I also have a blackish one [17:58] that might be better for this size [17:58] sec [17:59] RainCT: http://aplg.kollide.net/images/osiris/snapshot153.png [18:01] RainCT: http://aplg.kollide.net/tmp/user.png if you want to try it [18:12] Hi everybody. I would like to contribute to Linux, but I am not sure where to start or who to talk to. This seems to be the place. Can anybody spare a few minutes to point me in the right direction? [18:14] <__iron> hi Guinnesss [18:14] <__iron> https://wiki.ubuntu.com/MOTU/GettingStarted [18:14] Hi __iron, I will go to that link now. === dholbach_ is now known as dholbach [18:24] Guinnesss, there are a lot of different ways to contribute to free software. what's your level of expertise - are you a programmer, or a user, or what? do you speak any foreign languages? === bddebian2 is now known as bdddebian === bdddebian is now known as bddebian [18:41] Hi. I got the 2 acks for FFe from motu-release for Bug #261693, and now, I've subscribed u-s-u. Is it correct? [18:41] Launchpad bug 261693 in tor "[FFe] tor version bump to 0.2.X" [Undecided,Confirmed] https://launchpad.net/bugs/261693 [18:46] apachelogger: the changes (including the icon) are up now [18:47] hm [18:47] RainCT: I think we need a placeholder for uploaders without account [18:47] looks weird if some people have an icon and some don't [18:48] RainCT: btw, does the profile page have hardcoded coloring? [18:48] certainly doesn't follow the CSS :P [18:50] apachelogger: No, only CSS, and that's a "known bug" :). The problem is only with the brown lines in the Uploads section though, or? (I askfor the case that you have the page cached - I've changed the comments section to use blue) [18:50] RainCT: or maybe just indent/stuff the icon in a seperate column [18:50] directhex: I've been reading the ubuntu wiki about contributing, so I did not see your post earlier. Anyway, I would like to contribute through programming if possible. I have a Computer Engineering Degree from the University of Pretoria, and I have reasonable experience as a programmer. I have compiled small programs in linux and have used gcc, makefiles etc. elsewhere I am currently finishing off a project where I had to generate co [18:51] RainCT: ah, now the profile works :) [18:51] * apachelogger didn't notice the brown lines until now though [18:51] fabrice_sp: yes. Is this a sync? I've scanned the bug, but wasn't sure if it's a sync or not. [18:52] Guinnesss, i think, given what you say your skills are, you should consider helping to improve (or bugfix) your favourite apps [18:52] geser: yes, it's a sync from Lenny version [18:52] Guinnesss, if you see yourself as a C coder, then your time is wasted mangling debian/watch files down here at the land of packaging [18:52] geser: and an easy one (no Ubuntu modification needed :-) ) [18:53] fabrice_sp: if ubuntu modification was needed then it wouldn't be a sync. :-) [18:54] slytherin, well..... there are filthy workarounds for that..... [18:54] RainCT: revu looks nice now. :-) [18:54] slytherin, those filthy workarounds often start with "ifeq ($(DISTRO),"Ubuntu")" [18:54] slytherin: thanks :) [18:55] Ok, where do I go about finding a bug? I've set up a launchpad account, but what should I do from there? Basically, Do I simply download the source fix the described bug and upload it? [18:56] Guinnesss, well, the best format for fixes is a patch, prefereably a patch you send to the upstream developer - to avoid ubuntu deviating from the original [18:57] slytherin: so sync are always easy, then! :-) Only MOTU can perform that task? [18:57] And creating a patch? (Sorry I realize these are basic things, but I haven't found a tutorial about this yet) [18:58] fabrice_sp: yes, for universe/multiverse packages of course. And subscribing u-u-s was the only thing you needed to do. [18:58] Guinnesss: search for patching system on wiki [18:58] Thanks will do. [18:59] slytherin: ok. Thanks! [19:13] slomo: do you have time to sponsor a fix to resindvd backported from upstream? [19:43] Cheers...thanks for the help [19:46] Anyone could help me using dpkg-builpackage? I'd like to build a library package and it completes without a glitch but the resulting .deb file is empty [19:48] everything builds automatically an dinstalls in /debian/tmp/usr/... but the library files are not included in the generated .deb package [19:49] jmichel: can you paste your logfile in paste.ubuntu.com and post the link here? [19:51] which log file ? [19:51] the build log file [19:54] I believe it does create one or do you mean the output of the console ? [19:55] jmichel: have you taken look at any existing library packages? [19:55] Sorry I mean it doesn't seem to create one [19:57] slytherin: well it doesn't tell me much other than the files that are inside it [19:57] jmichel: paste your debian/rules file on pastebin [19:59] pastebin.ca/1223920 [19:59] But it is the default one created by dh_make [20:00] Because to install the lib I only need to ./configure, make, make install [20:02] jmichel: do you have any debian/install file? [20:02] no [20:03] jmichel: You will need it. It should contain a line debain/tmp/* I guess. [20:05] So I need to create /debian/install with only "debain/tmp/*" in it ? [20:05] that's a bit extreme and likely wrong [20:05] normally you only want the actual lib and symlink [20:06] e.g.: [20:06] debian/tmp/usr/lib/libfoo.so.2.0.5 [20:06] debian/tmp/usr/lib/libfoo.so.2 [20:06] crimsun: flashupdate is somehow slightly b0rken :\ [20:06] sebner: if you're referring to wmode, that's an nspluginwrapper issue that is being addressed already [20:07] so the file I write in debian/install will go into my deb package ? right ? [20:07] crimsun: I'm not sure. what's up with the windowed mode? [20:07] jmichel: yes [20:07] but which one will go in the -dev ? [20:07] sebner: windowless applets [20:07] crimsun: that is why I said 'I guess' :-) [20:07] crimsun: ah no [20:08] crimsun: sometimes (not reproducable yet) I just see just a gray windows (youtube) but sounds working [20:08] jmichel: instead of a single debian/install file, you can create two files, debian/libfoo.install and debian/libfoo-dev.install [20:08] slytherin: ok I will try this [20:08] jmichel: libfoo-dev.install should have debian/tmp/usr/lib/libfoo.a and debian/tmp/usr/lib/libfoo.so as appropriate [20:09] crimsun: -deb package containing .so? [20:09] s/dev/dev [20:09] s/deb/dev [20:09] slytherin: yes [20:10] in most circumstances, the libfoo2.install won't ship the .so symlink [20:10] oh, I didn't realise you were talking about symlink [20:15] * DktrKranz looks at http://qa.ubuntuwire.com/bugs/rcbugs/, no bugs, everything is fixed!!! (at least until next reschedule) [20:15] sebner: does reconfiguring flashplugin-nonfree help? If not, does purging flashplugin-nonfree and then reinstalling it help? [20:15] sebner: also, what arch? [20:15]