=== nxvl_work is now known as nxvl [01:24] \o_ [01:26] heya === asac_ is now known as asac === philwyett_ is now known as philwyett === saivann_ is now known as saivann [06:08] good morning [06:27] hi [06:51] hi folks [06:53] hi! [06:58] hi nxvl [07:16] Hello [07:17] packages.ubuntu.com is down again ? [07:17] not here [07:19] ?' [07:19] i can open it normaly [07:22] AnAnt: For what do you use packages.ubuntu.com? It may be there is also another way. [07:22] persia: I want to know what version of swt-gtk is in intrepid ? [07:22] AnAnt: `rmadison swt-gtk` [07:22] persia: swt-gtk 3.4 is released [07:23] persia: no return [07:24] persia: that means that there's no swt-gtk ? [07:24] persia: btw, I am using hardy now [07:25] At least there is no package by that name. [07:25] persia: ok, how do I request a sync ? [07:25] AnAnt: You mean the Java GUI toolkit? [07:25] persia: swt-gtk 3.4~rc3 is in Debian [07:26] https://wiki.ubuntu.com/SyncRequestProcess [07:26] RAOF: I think so [07:26] Heh. That package description lies so much: " - Fast and rich GUI toolkit for Java" :) [07:27] RAOF: Do you know a faster or richer GUI toolkit for Java? [07:27] The gtk bindings? [07:27] can someone review webstrict on REVU ? [07:27] Actually, maybe I'm thinking of the other Java GUI toolkit. [07:28] awt? [07:28] That might be it. [07:28] RAOF : how is JavaFX? [07:28] Yeah. AWT is the reason SWT exists. [07:29] bliZZardz: Dunno. [07:30] RAOF : you are looking at web based ones or for clients? [07:30] Well, for clients. Web based ones don't count. === AnAnt is now known as Guest72197 [07:34] can someone review webstrict on REVU ? [07:34] sorry I was disconnected [07:43] <\sh> moins [07:52] persia: ok, I found a new package on intrepid, how can I fetch its changelog ? [07:53] <\sh> http://changelogs.ubuntu.com [07:54] And this is why it's best to ask questions generally :) [07:55] persia: I done a general request regarding webstrict, and I got no answer :) [07:55] AnAnt: Right, but asking for something quick & specific (like "Where do I find changelogs" is more likely to get a response than "Please REVU this package", whether specific or general. [07:56] ok [07:56] <\sh> AnAnt: webstrict already reviewed by rainct... [07:56] <\sh> AnAnt: you didn't respond to the review at all [07:57] \sh: how's that, there is a new upload [07:57] <\sh> AnAnt: so tell the people that [07:57] <\sh> AnAnt: webstrict_1.0-0ubuntu3_source.changes that's the version on revu [07:58] <\sh> AnAnt: if there is no "oh, i fixed this and that as you remarked" nobody knows [07:58] \sh: aha, ok [08:04] ok, how do I know wether swt-gtk & xulrunner will be sync'ed (before I submit a request) ? [08:05] xulrunner certainly won't be sync'd. [08:05] why's that ? [08:06] Because our xulrunner packaging is different to Debian's, and will likely remain so. [08:07] You notice the big bold on the top of the SyncRequest page? "you must ensure the Ubuntu changes have been merged or are no longer relevant" [08:10] RAOF: ok, here's my issue, in the latest changelog entry of swt-gtk package, the maintainer depends on xulrunner-dev instead xul-dev [08:11] Right. So, this won't be a sync. It'll be a merge. [08:12] RAOF: oh, what's the difference ? [08:12] A sync is where we take the Debian source package and copy it into Ubuntu's repositories. [08:12] RAOF: so, is there a merge request ? [08:12] A merge is where a human looks at the existing Ubuntu packge and the new Debian package, and figures out how to make a new Ubuntu package. [08:15] Hm. Where are you getting swt-gtk from? [08:15] In Ubuntu it seems to be built from the eclipse source package. [08:15] RAOF: in Debian [08:16] There's a swt-gtk source package in Debian? [08:16] RAOF: yup [08:16] swt-gtk (3.4~rc3) [08:16] There used to be one in Ubuntu as well. It was removed back in 2006 because the implementation in eclipse was preferred. Fashion is again swinging the other way. [08:17] Oh, what fun. [08:17] persia: Debian seems to have both ! [08:18] AnAnt: Both the old and the new swt-gtk? I don't think so. swt-gtk in both eclipse and a separate source, yes, as does Ubuntu. Note that eclipse is swt-gtk-3.2 and the standalone is swt-gtk-3.4. I expect that the version in eclipse may be dropped once all dependencies are migrated. === doko__ is now known as doko [08:23] HI all! I was wondering if a package in universe can depend on or recommend a package in multiverse. Where can I find information on this topic? [08:24] Recommend: probably. Depend, no. [08:24] rutil: A package in universe may only depend, recommend, build-depend, or build-depend-indep on packages in universe or main. If it wants to do anything with a package in multiverse, it may break, or suggest it. [08:25] RAOF: Surely not, now that we have recommends-by-default and germinate processing recommends. [08:25] persia: I may have misremembered the outcome of "can main recommend universe". I thought the answer there was "yes", and by extension universe should be able to recommend multiverse. [08:26] Ah. I thought the outcome was "No". [08:26] * persia hunts for a reference [08:26] persia: probably suggests: is the right field then. I didn't understand "it may break", can you elaborate, please? [08:26] rutil: There's a Breaks: field. A universe package can decleare that it Breaks: a package in multiverse. [08:27] rutil: A package in universe may include a package in multiverse in the Breaks: field. [08:27] Did Enhances: ever get implemented anywhere? [08:27] Yeah. [08:27] Where? [08:27] I'm pretty sure it's implemented somewhere; at least one package uses it. [08:28] I suspect a package in universe might be able to enhance a package in multiverse, although I don't know what tool uses this field. [08:28] Which suggests that dpkg, at least, doesn't barf on it :) [08:28] Well, it's permitted, but I'm not sure it's used. [08:28] RAOF, persia: interesting... is there any particular problem I risk to face using Breaks: ? [08:29] rutil: As far as I know, Breaks: works fine, although it's a rare case where you need it. [08:29] I'm not sure what the question is. Breaks: is used as an aid to apt/dpkg when figuring out dependencies/conflicts/etc. [08:30] Debian isn't using Breaks yet; not until Lenny's released. [08:30] But apart from that... [08:30] persia, RAOF: I understand. BTW, Suggests should work fine for me. Thank you, you have been of great help [08:31] ok, how do I file a merge request for xulrunner ? [08:31] and can a sync request be filed for a package that doesn't exist in Ubuntu ? [08:32] Absolutely. [08:32] RAOF: I can't official statement. Colin wrote https://lists.ubuntu.com/archives/ubuntu-devel/2008-June/025684.html, and later processed that as https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025697.html. Matt later indicated this was probably correct in https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025715.html [08:32] s/'t off/'t find a off/ [08:33] AnAnt: When filing a sync request for a package not in Ubuntu, file it against the ubuntu project, with no package. For xulrunner, you'll want to ask in #ubuntu-mozillateam [08:34] Ok. There doesn't seem to be an official answer there, but I now agree that "no" is the general trend. [09:15] I want to create meta-packages to ease bundle installations of preferred packages.Can anyone recommend a beginner's tutorial? [09:16] philsf: It's extremely simple. Basically you only need to worry about debian/control. [09:17] philsf: Maybe starting with 'apt-get source ubuntu-desktop', which is a typical metapackage, will give you some idea. [09:17] Well, except that ubuntu-desktop is one of those seeded germinate-based packages. [09:18] Oh, really? I though I'd apt-get source'd ubuntu-desktop at one point and got something sane. [09:18] Maybe I was making that bit up. [09:18] RAOF: Certainly possible, but there's another example that's preferred for local stuff: I'm hunting it now... [09:19] Right. The equivs package contains documentation and hints to create local metapackages for preferred applications. [09:19] The *-meta packages are likely better examples if one wants to construct a flavour. [09:20] um, flavour? [09:20] %) [09:20] philsf: e.g. Ubuntu, Kubuntu, Server, Mobile, Studio, etc. [09:20] is that a custom distro? [09:20] ok [09:20] I'll take a look in equivs, thanks [09:21] If I just put in package's names, and never versions, I should be able to install it both in ubuntu and debian, right? [09:21] or meta-gnome2 [09:21] or meta-telepathy [09:22] philsf: Precisely. [09:22] dholbach: Do you think something based on meta-gnome2 is better than something based on equivs for local use? [09:23] I never looked at equivs, sorry [09:28] Does anyone know anything about the library libmozembed-linux-gtk2? [09:28] I have not been able to find its source [09:29] [09:29] Many Java applications distributed its source code with this library precompiled [09:29] it's needed for acroread, right? I was looking for it too, last week [09:29] philsf, you talk with me? [09:29] Festor: yup [09:30] Not only for acroread [09:30] frostwire [09:30] and others apps [09:30] For mozembed, I'd encourage asking in #ubuntu-mozillateam, as there resides the expertise in *moz* [09:30] Despite these applications are GPL [09:30] ok, thanks [09:31] Festor: Java upstream is far too often frustrating. You might also ask in #ubuntu-java for guidance on others experience in convincing upstream to actually ship source. [09:31] OK, thanks again [09:32] persia: didn't sun gpl'ed java recently? [09:32] or is it the gerund type of action [09:32] philsf: Well, huge chunks of something called Java. OpenJDK is working it's way to being both complete and clean in Ubuntu. [09:33] oh [09:33] But I can upload a precompiled lib to universe? [09:34] These libraries are mozilla so it will probably be free (libres) [09:34] I don't think so, no. Universe has to build from source. [09:34] or at least that's what I think [09:34] Festor: Nope. Everything in universe must be compiled from source. [09:34] Festor: you could try with multiverse, but universe isn't worth trying, I'd say [09:34] Sometimes there are exceptions for come things (e.g. images), but even PDF files often get rejected. [09:35] hey [09:35] dushara: hey [09:36] hi persia: got that issue sorted out. Now I'm packaging separately for Ubuntu :-) [09:37] dushara: Excellent. Glad to hear it. [09:37] One question, a [needs-packaging] bug could be assigned to MOTU team? [09:37] No. [09:37] I say for this https://bugs.launchpad.net/ubuntu/+bug/95666 [09:37] Launchpad bug 95666 in ubuntu "[needs-packaging] OrbisCAD" [Wishlist,Confirmed] [09:38] and this [09:38] https://bugs.launchpad.net/ubuntu/+bug/94722 [09:38] Launchpad bug 94722 in ubuntu "[needs-packaging] ANts P2P" [Wishlist,Confirmed] [09:38] I think there are many more [09:38] Needs-packaging bugs are waiting for someone interested to come and package the software. They shouldn't be assigned until someone actually wants to do the work. [09:38] Laney: re the ffmpeg rebuilds: I'd prefer to see debdiffs for the rebuilds as it makes the sponsoring for me easier (just apply the debdiff and debuild -S) [09:38] Question: Started a new project scim-wijesekera in launchpad (I'm also the developer). What do I do about the " Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" warning? [09:39] thanks RAOF , so I can unassigned these bugs? [09:39] morning dear MOTUs [09:40] dushara: If you're packaging for inclusion in Ubuntu, you want to set an Ubuntu maintainer. We typically use team maintainers: if you don't have any other team, MOTU is often a good candidate. [09:40] Festor: never assign a bug to a team. that's pretty pointless [09:40] huats: morning (though I'm not a motu) ^^ [09:40] hey sebner :) [09:40] Festor: You can unassign those bugs, but I wouldn't bother. It doesn't hurt much. [09:40] persia: What's the address? [09:42] Maintainer: Ubuntu MOTU Developers [09:42] But I wanted to try to pack a bug assigned to MOTU [09:42] https://bugs.launchpad.net/ubuntu/+bug/94722 [09:42] Launchpad bug 94722 in ubuntu "[needs-packaging] ANts P2P" [Wishlist,Confirmed] [09:42] Festor: Feel free to reassign it to yourself then. [09:43] ok, thanks [09:45] persia: Thanks. === dholbach_ is now known as dholbach [09:52] I found libmozembed [09:52] but in Debian [09:52] ... [09:53] [09:53] Should I use the same procedure as to create a new package for the Ubuntu import a Debian package? [09:54] this is the package: [09:54] http://packages.debian.org/sid/libjdic-bin [09:55] Festor: Did you not get any information about it from the mozilla team? [09:55] nop [09:56] they only found rpm package with precompiled lib [09:58] Well, if you want to import a package from Debian, the SyncRequestProcess is your best process. [10:28] hello, can someone review my swt-gtk package upload on REVU ? [10:52] AnAnt: I thought you were syncing from Debian. Why is it on REVU? [10:53] ScottK: isnt ~8.04~jjv lower than ~hardy1? [10:54] im going on the ~jjv at the end made it lower [10:57] persia: Debian has rc3, I made package for the stable release [10:59] persia: besides, there had to be a change for Ubuntu, build-depend on xulrunner-1.9-dev instead of xulrunner-dev [10:59] AnAnt_: Ah. I'd have recommended you coordinate with the Debian Maintainer to do that, who would likely have been able to push it to Debian within a few hours, but I've missed you. [11:00] Oh! I didn't see the tail. Excellent. Please check with the Debian Maintainer: I'm sure there will be support to get the stable release uploaded directly, so we can sync. [11:00] Hmm. I'm unsure of policy for that. [11:00] Any other opinions? Should NEW packages in Debian processed for an Ubuntu variation go through REVU, or as bugs? [11:02] Or we could make our Mozilla people comply with Debian, which is probably an all-round better idea. [11:02] persia: btw, according to mozillateam, there will be a xulrunner-dev in Ubuntu too, but it doesn't exist now [11:02] but I dunno if that will be in Intrepid or what [11:04] wgrant: That makes more sense. [11:05] AnAnt_: Could you please coordinate with the Debian Maintainer to get the newer version in Debian, and the mozillateam to ensure that we don't have to carry this silly variation for every single package (in many cases, Provides: works just fine). [11:07] gnomefreak: [11:07] directhex@mortos:~$ dpkg --compare-versions 1.0-1~8.04~jjv gt 1.0-1~hardy1 || echo "the jjv one is higher" [11:07] the jjv one is higher [11:08] 'dpkg returns success (zero result) if the specified condition is satisfied,' [11:08] You want && [11:08] close enough ;) [11:08] i blame lack of sleep [11:10] ok guess im rebuilding everything [12:06] n/c [12:11] Hi TheMuso [12:20] persia: sorry I was away [12:21] persia: how will Provides work ? [12:23] AnAnt: If two packages are functionally identical, one may indicate that it Provides: the other. When the package management tools cannot find a specific package, but can find a package that Provides: that package, they will select the providing package for installation. [12:24] morning [12:26] emgent: \o/ === Syntux_ is now known as Syntux [12:32] hi [12:32] goshawk: hi [12:35] i'm trying to make a deb package for ubuntu (i'm packaging dsss a tool to compile and install D programs), what should i do to be accepted in ubuntu universe repository? [12:35] !revu [12:35] 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 [12:35] sebner: heh ubotu is sleeping... [12:35] tahnks sebner [12:35] mok0: really laggy [12:35] mok0: ? [12:36] persia: eerrh he woke up I guess [12:36] ubotu, are you asleep? [12:36] ubottu: speed up! [12:36] Sorry, I don't know anything about speed up! [12:37] LOL [12:38] !lag [12:38] You have lag, I don't have lag [12:38] ubottu: everybody except you have lag [12:39] mok0: Error: I am only a bot, please don't think I'm intelligent :) [12:39] rofl [12:39] Erm. Let's not abuse the bot. Too much attention, and it tends to sulk for a couple days :( [12:40] I guess he is busy serving all those losers over at #ubuntu ;-) [12:41] Erm. Many of those people are very important in ensuring that Ubuntu works properly. Without #ubuntu, Ubuntu would not be what it is today. [12:41] mok0: I don't think losers is appropriate term. [12:42] mok0: uh uh uh. bad words [12:42] slytherin: you are right I apoligize [12:42] Bad attempt at being funny [12:43] persia: mozillateam says that they done that in the bzr already [12:43] persia: but they doubt it'll work, so they are planning to make an empty xulrunner-dev package that will depend on xulrunner-1.9-dev [12:43] I have to reboot [12:47] anyone knows when is next intrepid upload ? [12:49] wb mok0 [12:52] AnAnt__: next upload of what? xulrunner? [12:53] uhm... [12:53] geser: yeah [12:53] i'm packaging a tool that needs itself to be compiled... how to solve this problem? [12:54] AnAnt__: it's up to the mozillateam when they do a new upload [12:56] AnAnt__: That works too. Thanks for checking with them: with that new dummy package, will we be able to sync with Debian once they update to the now released upstream? [12:58] anything interesting happening? [12:58] persia: well, got to talk with the maintainer [12:58] AnAnt__: Almost there then :) [12:58] Hobbsee: Always. Would you like a task? [12:59] persia: so no need for package on REVU [12:59] persia: probably not :P [12:59] AnAnt__: That's what I think. Let's wait until you hear back from Debian before we nuke it. [12:59] Hobbsee: Well then, you don't get to play :p [12:59] aww [12:59] well, depends what's on offer [13:01] Let's see: rcbugs, unmetdeps, mutliverse demotions, ubuntu-local package updates, watch files, NBS. [13:01] <\sh> siretart: ping are you going to the FAI developer workshop (august @linuxhotel, essen) ? [13:01] There's a heap of Kubuntu NBS, if that interests you. [13:01] has someone an idea how to best sponsor the ffmpeg rebuild requests in the u-u-s queue as they don't have debdiffs? wait for debdiffs or simply do the rebuilds myself? [13:01] \sh: puh, TBH, I currently don't plan to do so. [13:02] geser: Are you talking about Laney's bug? [13:02] persia: yes [13:02] <\sh> siretart: k [13:02] \sh: do you plan to attend? [13:02] geser: I'd just process it and close the bug, rather than pushing debdiffs. He's had a few days, and reported several times that they all build correctly. [13:03] <\sh> siretart: I don't have the time...:( too much to do @office and for leonov...and I [13:04] <\sh> 'm attending froscon which is also in august :( [13:04] <\sh> siretart: I just asked you, because it would be good to have at least a "biased" fai lover there to make fai work properly for hardy/intrepid [13:05] hm. I'll think about it [13:06] persia: do I put him into the changelog or myself? I don't want to "steal" the rebuilds from him but I don't want to invest to much time on the changelog either. [13:07] geser: I'd "steal" them. When I find good bugs in the queue, and the person doesn't have a good debdiff, and doesn't get one soon, I tend to just adjust, update the changelog, and upload. [13:08] From my experience when receiving sponsoring, I tended to prefer that the bugs I worked on got fixed, rather than that I got changelog credit, and tended to learn when you or crim*sun would "steal" them with additional corrections. [13:08] On the other hand, my first NBS work was very confusing, as my sponsor fixed a bunch of things and uploaded with my name in the changelog, so the packages in the repo didn't match my local patches. [13:11] persia: thanks [13:12] has someone an idea how to prevent "Building database of manual pages" in a pbuilder? I don't need the manpages during a build and it only takes time. [13:12] geser: dpkg triggers? [13:15] persia: I guess [13:16] More seriously, I don't think there is a way, any more than the building font DB issue, or the scrollkeeper update issue. [13:16] Getting triggers widely implemented likely won't happen until post-lenny (intrepid+1), so we're likely stuck for now. [13:17] allRIGHTY then. i finally have a package in sid. so, where do i request a sync? [13:21] directhex: w.u.c/SyncRequestProcess [13:22] Probably worth a wishlist against pbuilder - dancer may well want to handle it like start-stop-daemon or similar. [13:25] broonie: Does it make sense to have many of those? I'd personally prefer to have the build environment be close to the target environment, even if this makes it take a little longer. [13:26] (That said, I use sbuild+schroot, and actually do start the daemons at build time, when required) [13:33] persia: Well, it'd be nice if pbuilder ran faster :) [13:34] broonie: I guess. I value correct over fast, but that's likely me. [13:35] good morning everyone! [13:35] persia: It should be a whitelist of triggers for things like the man-db update that are guaranteed not required rather than suppressing all triggers. [13:36] broonie: I guess. On the other hand, for me the issue is that it does this sometimes several times in a single installation run, whereas doing it once would be less painful. [13:38] That's nothing to do with pbuilder - it's a generic "issue" with triggers (it was brought up on d-d recently, not sure what the conclusion of the thread was) [13:39] My understanding was that the goal was to only do these things once, but that the mechanism for doing so wasn't implemented in all packages, and not considered release-important for lenny. [13:39] Then again, I've not been a d-d reader for a few years now, so I'm quite likely mistaken, [13:40] There's two orthogonal issues. [13:40] One is that more packages could use triggers than currently do so. [13:40] The other (the one with multiple invocations of triggers) is that triggers get run more frequently than might perhaps be desirable. [13:41] Ah, I see. I'd consider the second a bug, as part of the slowly improving implementation. [13:42] Indeed. Everything actually works fine so it's not critical. IIRC half of it is better integration with apt. === effie is now known as keffie_jayx [14:33] morning [14:37] wow boost is messed up with the gcc change [14:41] morning null_vector :) [14:47] How are you today RainCT? [15:01] Heya gang [15:02] hi bddebian =) [15:02] Hello sebner [15:11] Hi bddebian [15:11] hello there [15:11] emgent: \o/ [15:11] hi bddebian [15:12] and hi emgent [15:12] geser: you are like a working-animal (arbeitstier) [15:12] hihi sistpoty|work =) [15:12] sistpoty|work: geser sebner heya :) [15:12] hi sebner [15:12] hot day.. [15:13] is anybody here familiar with using xdg-desktop-meny? [15:13] xdg-desktop-menu? [15:14] slayton: Yes, and I very much discourage you from using it. [15:14] You'll do best to encode things in interesting categories in your .desktop files, and then have the menu system or launcher use this informaiton to control display in a manner well integrated with the rest of the environment. [15:15] sebner: yes :) I didn't do many uploads in the last weeks so I need to catch up to be back on track for my regular amount of uploads/sync for a release (around 300) :) [15:15] Trying to adjust the menus directly tends to lead to confusion, and possible significant differences in behaviour in different environments. [15:15] geser: WOW (no vista) xD [15:16] so I've pretty much been getting that same response for the last week or so... everybody is telling me that creating my own menu entries is bad... but why? [15:16] If the software I'm deploying is going to be used in a highly controlled environment is it really that big of an issue? [15:17] stdlib.h or string.h doesn't pull in limits.h anymore? [15:17] slayton: If the software you're deploying is going to be used in a highly controlled environment, this is the wrong forum in which to seek advice. [15:17] null_vector: gcc-4.3 doesn't recursively track things anymore anyway. [15:18] yay =/ [15:18] ok thanks.... [15:18] Heya geser, emgent, sistpoty|work :) [15:19] o/ [15:20] persia: hmm I have currently 2 packages on revu and enough reviewers (currently looking at it) but I promise you the third is yours ;) [15:20] emgent: bah! still not a motu :P [15:21] does anyone know off hand if hamster is already packaged? [15:22] sebner: yeah i know, waiting Motu Council votes. [15:22] slytherin: No, it's not IIRC. [15:22] emgent: speed it up (with free beer) xD [15:23] Iulian: Not present in debian too. [15:23] sebner: lol [15:24] emgent: though it may look like corruption :P [15:24] sebner: it`s impossible, i will wait. [15:24] * sebner ist just making fun =) [15:25] slytherin: You should talk to Tim Retout (he reported the ITP bug to Debian) if you'd like to start packaging it. [15:25] sebner: hehe i know. [15:25] Iulian: nooo, I stay away from python packaging. :-D [15:28] Heh [15:30] slytherin: why, python packaging is great :P [15:30] slytherin : what is tough in py pkging? [15:30] * RainCT stays away from C/C++ stuff packaging :) [15:31] RainCT: bliZZardz: Never said it was tough. But I am more interested in java packaging. :-) [15:31] bliZZardz: it has it's own policy (you've to use pycentral/pysupport to byte-compile the files, etc) [15:31] c/c++ is PIA [15:35] bliZZardz: Why? [15:35] bliZZardz: may be, but you have to take into consideration that most of the Free software is written in C/C++ :-D [15:35] Bah. C is easy to package. With python, one has to do all sorts of contortions to ensure that one only uses libraries available for some specific python version and avoid using ezsetup. [15:35] * Iulian agrees with persia. [15:36] If I add dpatch to a package should that be noted in the changelog? [15:36] null_vector: Yes [15:37] Iulian: thanks [15:37] vorian: congratulations! [15:38] slytherin: lulian : i would like to rephrase what i said... i meant packaging on multi-bit platforms.. [15:39] Laney: are you around? could you check if the still open ffmpeg rebuild requests are still valid? looking at the dependencies on intrepid/AMD64 they look to my like a rebuild isn't needed anymore [15:39] vorian: congratulations [15:39] slytherin: lulian: persia : and if you are not talking abt just ubuntu specific packaging(but even Solaris, Win etc) - then it becomes little tricky [15:40] bliZZardz: Indeed: packaging vs. preparing an upstream release. [15:42] i still remember the first time when i compiled a C prog in win 98 and took the exe and tried running the exe on win 2k.... i got jacked. (these were teh days when i just knew to print 'foobar' [15:46] Is there an easy way to edit a dpatch? I need to add an include to an existing patch. [15:48] null_vector: dpatch-edit-patch === thekorn_ is now known as thekorn [15:49] damn I love dpatch [15:52] * raphink_ prefers cdbs' simple-patchsys or even quilt to dpatch, but since most packages use dpatch... [15:54] Would somebody mind doing a second review on my packaging of stjerm (a light weight terminal emulator)? Bug 216603, http://revu.ubuntuwire.com/details.py?package=stjerm. Thanks :) [15:54] Launchpad bug 216603 in ubuntu "[needs-packaging] stjerm" [Wishlist,In progress] https://launchpad.net/bugs/216603 [15:56] vorian: congrats [15:58] vorian: congrats! [16:00] null_vector: always document *every* change ;) [16:00] vorian: congratulations! :D [16:00] dholbach: bah that's unfair -.- [16:00] null_vector: i think quilt is alot more easier to use [16:00] hm? [16:04] sebner: Know of any good intro quilt? Might check it out. [16:07] null_vector: I usually use the one on the wiki when I need to deal with quilt [16:07] https://wiki.ubuntu.com/PackagingGuide/PatchSystems#head-144f4addc9168b6fba691616e44f75d34fb5af77 [16:08] vorian: congrats! [16:13] sebner: are you kidding quilt is pain. [16:13] slytherin: O_o for me quilt is easier than dpatch [16:16] grats vorian [16:31] ScottK, ping === devfil_ is now known as devfil [16:48] * hefe_bia likes quilt, too :) [16:48] I need some clarification on the get-orig-source target [16:49] Is it supposed to get the source matching the package version or the newest version? [16:51] syspoty|work: the packages are ready for testing, in case you're interested. [16:53] Anyone have any experience with the "__stack_chk_fail_local" issues? [16:58] null_vector: build failure? [16:58] geser: dlopen [17:00] null_vector: it is related to the gcc stack protector [17:01] geser: yes, the library being build and dlopened seems to be using the stack protection bits [17:05] tseliot: ah, not too sure if I manage to come around it once I'm home, as I'm now > 11 hours at work already [17:05] sistpoty|work: no problem. This was just FYI ;) [17:06] tseliot: thanks :) [17:08] Is it necessary to request a review of REVU packages in this channel? [17:08] I say this for it seems that there are many packages unreviewed === Nafallo_ is now known as Nafallo [17:09] Festor: well if you want somebody to lookt at them ;) [17:10] Festor: it's not necessary but it often helps (but don't repeat your requests too often else you might get ignored) [17:10] I do not say that review my packages. I mean that there are many with no comment [17:12]