[00:12] Uploading to upload.ubuntu.com fails: "Connection failed, aborting. Check your network (111, 'Connection refused')" - temp. problems? [00:13] blueyed: Scheduled Hardy upgrades. [00:13] For another 4 hours. [00:14] wgrant: ah.. forgot about that one. Thanks. [00:48] How can I make my installed program via a .deb I made appear in Add/Remove, not only in synaptic? [00:50] vadi2: Create a desktop file for your application. If it is a GUI application, this ought be a regular .desktop file. If it is not a GUI application, you will want to have a special .desktop file. You may want to look at the app-install-data package for information about the required construction. [00:51] persia: I did make a .desktop file, yes. It appears in applications menu properly [00:51] look at the app-install-data package [00:52] I see. So I should stuff the .desktop into '/usr/share/app-install/desktop/' too? [00:52] (that's what that package does with a bunch of .desktops) [00:54] vadi2: You already have a .desktop, and it doesn't show? You may need some extra keys then, but /usr/share/applications/ is the right place for it. [00:55] I think I got it, it needs a 'X-AppInstall-Package [00:55] ' key. I'll test in a sec. [00:57] persia, vadi2: /usr/share/applications is for installed applications, I don't believe that gnome-app-install looks there. [00:58] Oh, you mean for picking up by mvo later? Right. [01:01] wgrant: Right. Pushing things directly into app-install-data is not ideal, with the exception of server packages with insufficient internationalisation to support multilinugal installation through the .desktop files (where putting it in app-install-data helps get that right). [01:01] (and these exceptions are only really meaningful for main) [01:02] vadi2: wgrant does raise a good point: once your ,desktop file has all the right keys, you'll have to wait for an update to app-install-data before it appears, although the change oughtn't be made in the app-install-data source directly. [01:03] persia: so what is the proper way to have it appear right away in there? [01:04] vadi2: There isn't one. [01:05] hrm. but then the user can't uninstall a .deb I made without using the synaptic or terminal, which is bad. [01:06] I suppose, long term, someone might write a script that regenerated app-install-data daily (or more often), but in practice such freqency is rarely relevant. Usually it gets prepared prior to each milestone release (Alpha, Beta, RC, Final) [01:06] vadi2: How are they installing it? [01:06] via a .deb I made [01:06] With gdebi or some such? [01:07] yeah. [01:07] I think it would make sense to be able to trigger app-install-data to regenerate it's index via a package [01:07] Ah. That's not really supported, and users who choose to do that are expected to be able to deal with the consequences. [01:07] Why? my program is a commercial one, and I can't afford to use canonical's partner repository. [01:08] Review the source, create a patch. For that package, branches from trunk on LP are the preferred mechanism to present code changes. [01:08] eh? [01:09] vadi2: How were you planning on getting the .desktop into the user's system in the first place? [01:09] wgrant: I made a .deb which installs it [01:10] But you can't get a file installed by a .deb to give instructions to the user on how to install said .deb. [01:10] ? [01:11] Not sure what do you mean. The .deb installs the program, the .desktop, and the icon. [01:11] The program appears in the Applications category properly. [01:11] There's no point adding it to gnome-app-install if it's only going to appear there when it's already installed... [01:11] The lil problem is that the user has no way of removing it unless they're comfortable with the terminal/synaptic. I'd like to appear it in add/remove. [01:12] Ah. [01:12] Well, that's not going to be supported here, I don't think. [01:12] It's an interesting use case, but it really needs someone to drive the code, as mvo is unlikely to write such functionality. [01:13] Rather unlikely indeed. [01:13] I think it's a pretty important one, not everyone would like to use the partner repository and still be able to make ubuntu installation of the program easy. [01:14] If the work was done well, and in a style matching that of the application, it may be merged though, as support for easy uninstallation of third-party packages may be interesting to many. [01:14] But I cannot imagine a Canonical employee would be paid to do that - that would be very silly on their part. [01:15] To write the code? Unlikely. To merge the code, maybe. [01:16] Okay, I guess I'll hold off on that and just use an archive for distribution. Thanks for the explanation. [01:16] /win 54 [01:16] Gah. [03:34] kirkland: Just saw your wiki question. Is there an example pacakge that illustrates the issue? [03:35] persia: i'm working on pam at the moment [03:35] persia: http://merges.ubuntu.com/p/pam/REPORT [03:35] persia: i think i'm doing the right thing... i just thought the algorithm in the wiki document might be updated for such cases [03:36] kirkland: Right, I'm just trying to understand the situation, so as to document it. [03:36] There are a number of different things that could happen to cause a "no conflict" merge report. [03:37] persia: ah, gotcha [03:37] heya kirkland persia [03:37] kirkland: Just for verification, by "no conflicts" do you mean the report says "No problems were encountered during the merge, so a source package has been produced along with a patch containing the differences from the Debian version to the new version."? [03:38] persia: see: http://merges.ubuntu.com/p/pam/REPORT [03:38] persia: yes, to your question [03:38] emgent: hiya sir [03:38] kirkland: That's exactly the source from which I copied the phrase :) [03:39] persia: right, this is the first merge i've ever worked on where there *are no conflicts* :-) [03:39] persia: so I think the appropriate thing to do is just skip the conflict resolution step [03:39] persia: and proceed on with the documentation of dropped/remaining changes [03:41] kirkland: Well, I think it's worth reviewing all the changes anyway. Imagine the case where Ubuntu adds 54_remove_wonkiness.patch and Debian adds 67_dewonkify.patch, and they patch the same file differently. This will show as no conflict in MoM, but will cause a FTBFS. In a more subtle case, it might just break something at runtime. [03:44] kirkland: In this specific case, I think I'd recommend chatting with the person who uploaded the updated Debian version, as the same person later added patches to the Ubuntu version without including the Debian bugfix patch. [03:45] persia: yessir, i'm hanging around here looking for slangasek, in case he comes back online later [03:46] kirkland: More generally, it looks like all the things I would recommend doing in this case also apply in the general case, and aren't documented in this guide. I'll likely not update it today, but I would be adding these checks to the general process, rather than adding separate workflow for the no-conflict case. [03:47] persia: awesome, thanks for the advice [03:51] kirkland: Getting back to specifics, these patches don't clash: it's probably worth reviewing Debian bug #446327 to understand it, and maybe speaking with the uploader as to why we didn7t want it before. [03:51] Debian bug 446327 in libpam-modules "pam_tally audit option locks out root" [Important,Closed] http://bugs.debian.org/446327 === LucidFox is now known as LucidFox_KOTOR30 [03:52] Actually, reading that, it makes sense. Root is locked out anyway, so we don't care. [04:02] slangasek: hey, thought i'd get some late-evening packaging practice in. i merged pam from 0.99.7.1-5ubuntu7 to 0.99.7.1-6 for intrepid. no conflicts, so it was mainly constructing the changelog of dropped/remaining differences. i also threw in the fix for 64064. uploaded to chinstrap:~kirkland/pam.intrepid. === LucidFox_KOTOR30 is now known as LucidFox [04:05] has anyone heard from RAOF lately, hes here but MIA lately... [04:05] (sorry to just barge in and ask, i figure if hes been active anywhere, here would be the place) [04:05] kirkland: As much as specific people are helpful to contact, I'd also encourage you to attach the debdiff to a bug, and subscribe ubuntu-main-sponsors. This both raises visibility to the sponsoring developers and serves as a public indicator that the merge has been done, so nobody else is tempted to attempt it. [04:06] DBO: He's been active most days this week. [04:06] persia, thank you, do you remember what times? I have been trying to catch him [04:06] DBO: I'm not that good with time. [04:07] okay [04:07] thank you === freeflyi1g is now known as freeflying [04:12] freeflying: Did you get anywhere with the fbreader merge? I've been passed some additional patches, so wanted to either share, or take back the merge. [04:18] persia: I've noticed the maintainer will have new upload in sid, so waiting for his upload [04:21] freeflying: OK. Maybe I'll push the extra patches into Ubuntu, and the merge can happen when the maintainer uploads? Would that work for you? [04:22] persia: maybe you can mail the maintainer your patch, he has filed RFS recently [04:22] persia: its up to you :) [04:22] freeflying: OK. Last I looked the patch was lpia-specific, so I'm not sure it's Debian-interesting :) [04:23] persia: hehe :) [04:24] persia: then it should be ok for me [04:25] freeflying: Just checked. Other than the lpia stuff, there's a 'r' -> 'R' in a .desktop file (which is being patched anyway). I'll just get it up today then. [04:25] persia: thats great! [06:14] good morning [06:15] Morning dholbach [06:16] hi Iulian === dholbach_ is now known as dholbach [06:46] good morning [06:47] hi geser [06:50] Hi dholbach [07:13] c [07:14] * ScottK waits for the ugh. [07:17] * StevenK chuckles [07:23] Thats long gone. :) [07:25] Hi TheMuso [07:25] Hey geser. [07:39] Does debian use tmpfs vor /var/run aswell? [07:42] afaik no [07:45] Not by default, but any Debian user is free to configure their system that way. [07:51] Anyone: is there a written policy that executables must be lower case? I searched for it but did not find it. [07:52] no, there are executables who have uppercase letters in their names because that's the upstream convention [07:52] <\sh> moins [07:53] slangasek: the fast majority has lower case in /usr/bin. So I'd like to rename CamelCase to lower case. Can I do that? [07:54] uh - you mean you have a program whose name is CamelCase? [07:54] because that would be an incredibly ironic renaming :) [07:54] :) [07:54] TouchFreeze [07:55] there's no policy against renaming it, either [07:55] there are times when upstream executable names can't be used due to namespace conflicts, so [07:57] i think i just rename it, mention that in changelog without reason [07:58] Why do you want to rename it? [08:17] ScottK: To break compatibility with anybody who wants to use it, of course. [08:17] That was my guess. [08:18] Uh. [08:19] Are incomplete bugs now meant to be assigned to the person who is meant to give the information, or is somebody breaking the rules? [08:21] I [08:21] I'll go with breaking the rules. [08:32] wgrant: that was old procedure before you could search for bugs you were subscribed to apparently. [08:36] james_w: You have been able to search for bugs to which you are subscribed since before 2006. [08:37] james_w: And that doesn't explain this situation - a triager assigned it to the person who needed to provide the information (ie. the reporter), not themselves. [08:37] oh, sorry, I misunderstood, that's just odd then. === freeflying is now known as GNU === GNU is now known as Guest71839 === Guest71839 is now known as freeflying [09:21] tseliot, lucky you, nvidia 177.13 is now officially out. and i hear work of ati's new cards shipping with a new driver which i can only assume is 8.7 [09:27] directhex: Catalyst 8.6, I believe. [09:27] wgrant, 8.6 claims no 4000-series support [09:27] not to say it's not there, but going by the readme, i assume it ain't [09:31] directhex: I have packaged the 4 flavours of the NVIDIA driver for Intrepid, however Intrepid's kernel is Xen-enabled and doesn't work with the patches for Xen for the NVIDIA driver. BenC will work on a new patch. [09:31] 4 flavours!? [09:32] wgrant, fun, isn't it [09:32] directhex: as regards ATI, I will package 8.6 for EnvyNG while Mario will package it for Intrepid [09:32] wgrant: yes, and I'm the new maintainer [09:33] wgrant: I'm having a lot of fun... [09:33] tseliot: So I heard. [09:46] does anyone can give me some details on the role of the lintian directory in debian/ in a package ? === asac_ is now known as asac [10:01] huats: I think that usually stores lintian overrides [10:02] they tell lintian to not complain about a specific problem. [10:02] they should be reviewed to ensure they are not masking a real issue. [10:03] ok [10:03] james_w: thanks [10:03] no problem [10:03] james_w: in fact I am facing that in a merge (it is present in the debian package) [10:04] so I will have a closer look at it [10:04] :) [10:08] james_w: the lintian warning that it is handling is binary-or-shlib-defines-rpath [10:46] hi \sh and everyone! [10:46] \sh: this should please you: https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/241587 :) [10:46] Launchpad bug 241587 in claws-mail "bugfix batch for Hardy's Claws Mail" [Undecided,New] [10:49] <\sh> colinl: ah sru :) [10:50] <\sh> colinl: thx :) [10:51] <\sh> colinl: would you like to update your debdiff and follow https://wiki.ubuntu.com/StableReleaseUpdates?highlight=(StableReleaseUpdates) ? :) === devfil_ is now known as devfil === pgquiles__ is now known as pgquiles === elkbuntu is now known as elky [11:28] Is the backports team really busy with 8.04.1 stuff? I'd like to poke them about Wine 1.0 :) [11:28] \sh: sure [11:33] \sh: I mainly have to document how to reproduce the differents bugs the patches fix? [11:41] <\sh> colinl: that would be a plus, yes :) [11:41] ok [11:41] how can I subscribe to motu-sru? I can't find an "Apply" link [11:43] colinl: Why would you want to do that? [11:44] wgrant: to propose an SRU [11:44] colinl: motu-sru reviews SRUs - you don't join the team. [11:44] ok [11:44] You subscribe it to the bug. [11:53] \sh: I don't really have to update the debdiff itself, in fact, do I? [11:56] <\sh> colinl: the version string is not correct according to SRU policies [12:10] ah sorry [12:12] \sh: claws-mail (3.3.1-1ubuntu3build1) hardy-proposed; urgency=low ? [12:13] !info claws-mail hardy [12:13] claws-mail (source: claws-mail): Fast, lightweight and user-friendly GTK2 based email client. In component universe, is optional. Version 3.3.1-1ubuntu3 (hardy), package size 1231 kB, installed size 2976 kB [12:13] 3.3.1-1ubuntu3.1 [12:13] thanks wgrant [12:14] <\sh> 3.3.1-1ubuntu3 [12:14] good your-time-of-the-day [12:15] updated :) [12:16] \sh: That's the version in hardy-release.. [12:28] emgent: any news on eggdrop? [12:28] hello there, need help with packaging [12:29] when I do apt-get source dbus, this happens: unlink("dbus-1.1.20/debian/patches/03_fix_inotify.patch.dpkg-orig") = -1 ENOENT (No such file or directory) <- this is the second-last line before the write+exit(1) [12:29] my goal is to compile an ubuntu package of the SVN version of dbus [12:29] any quick tutorial that gets me there? [12:29] hello everybody7 [12:32] Rudd-O: do you have intrepid enabled as a src repository? [12:32] no [12:32] why? [12:32] I have hardy [12:32] I need a fix that went a few days ago into dbus svn [12:32] because otherwise it fails with ZFS [12:32] I am running ZFS in /var and /usr and /home [12:32] this fix also benefits ntfs3g users [12:32] and I need it like now [12:33] no dbus, no modern desktop environment [12:33] Rudd-O: You better use the latest src package [12:33] I doubt that the latest intrepid package has the fix [12:33] so I want to build the latest package but using the dpkg data [12:34] anyway [12:34] why is apt-get source failing on me, with the official hardy package? [12:35] i know it's the dpkg-source routine that is failing [12:35] but WHY? [12:35] Rudd-O: no idea. I tried the intrepid one and there is no problem [12:36] Rudd-O: you can also use -t intrepid if you don't want to change your sources.list [12:36] ook [12:36] let's try that [12:36] apt-get -t intrepid source dbus? [12:37] Rudd-O: yes [12:37] Des:2 http://mirrors.kernel.org hardy-updates/main dbus 1.1.20-1ubuntu2 (tar) [1402kB] [12:37] that didn't work [12:37] still gets from hardy [12:37] idea? [12:37] same problem [12:38] Do other sources work? [12:38] no [12:38] same problem with fuse source [12:38] * wgrant would blame your strange FS setup. [12:39] hardly [12:39] Rudd-O: than you just miss some build-essential [12:39] Rudd-O: is it just complaining about signatures? [12:39] there is a complaint about signatures, publc key not found [12:39] but that has nothing to do with dpkg-source's attempt to delete a nonexistent file! [12:40] dpkg-source: fallo: eliminar copia de seguridad de parche dbus-1.1.20/debian/patches/03_fix_inotify.patch.dpkg-orig: No existe el fichero ó directorio [12:40] again, the filesystem is orthogonal to the issue [12:41] Rudd-O: it might be perpendicular too but the problem is in your machine [12:41] so? any ideas on how to track this issue down? [12:42] let me strace it all [12:42] Rudd-O: run dpkg-source under the perl debugger [12:43] <\sh> wgrant: grmpf...3.3.1-1ubuntu3.1 is the new one for SRU [12:43] * \sh was in between four tasks [12:45] here was it sais [12:45] apt-get source downloads the stuff and places it into the directory [12:45] then apt-source successfully untars the file and runs patch [12:45] and the patch *succeeds* [12:46] then dpkg-source attempts to delete a file ending in .dpkg-orig which doesn't exist there [12:46] *boom* goes the terrorist [12:46] I don't need the perl debugger to figure that out [12:47] let's read the source, see what the hell it's trying to do [12:47] there is someting else I would like to know [12:47] how come there is a debian/patches in the source dir, and there is ALSO a .diff.gz in the pwd? [12:49] Rudd-O: lsdiff -z foo.diff.gz to answer the last question [12:49] lemme install that tool [12:49] no such package lsdiff [12:49] > aptitude search lsdiff [12:50] 0 bytes reply [12:50] Rudd-O: patchutils [12:50] ok [12:50] installing... [12:50] hey, anyone here work at google? [12:51] ok so the .diff.gz gets uncompressed in the source tree? neato. [12:54] Rudd-O: Right. That's how Debian-format packaging works. The orig.tar.gz matches upstream, the diff.gz is all the patches and packaging, and the .dsc contains some meta information and checksum hashes for the two content files. [12:55] okay [12:55] interesting,v ery interesting, I'm learning a lot now [12:55] well, I have surpassed the dpkg-source problem by manually untarring and patching [12:55] what's next? [12:56] I assume plugging in the original source? [12:56] how do I get from the original source plus debian-specific patches to a deb? [12:56] debian/patches/* I assume are applied when the package is actually built, right? [12:57] The common method is to construct a new orig.tar.gz from the new source. Adjust the variance in diff.gz to be compatible with the new source, update debian/copyright, and build a new source package. [12:57] Adjust the variance in diff.gz <- what does this mean? [12:57] If you just want to apply a patch (which is also good), you probably want to try the which-patch program from the ubuntu-dev-tools package to determine how to apply the patch in a compatible manner. [12:58] persia, uupdate! [12:58] ok [12:58] Rudd-O: Let's say that we have a patch that fixes a bug, and it's been sent upstream and accepted. That patch then needs to be removed from the package. Simiarly, if a patch applies against code that changed, the patch may need to change. [12:58] I want ot just apply the patch [12:58] ok, this is a patch that has NOT made it into upstream [12:59] directhex: In those cases where it works, maybe, but it's very rare that uupdate lets one construct a new SVN snapshot. [12:59] https://bugs.freedesktop.org/attachment.cgi?id=16746 [12:59] I just plop it into debian/patches? [12:59] Rudd-O: What did which-patch tell you? [13:00] Sorry. "what-patch" [13:01] what? what do you mean? is there a what-patch command? [13:01] I just plopped the patch and adjusted for build system into debian/patches [13:01] what next? [13:03] the patch was applied correctly, when I do it manually [13:03] what's next after plopping the patch in there? [13:03] I mean, changelog and how do I build it? [13:05] Usually dropping the patch in debian/patches isn't sufficient, which is why I recommended the what-patch program from the ubuntu-dev-tools package. [13:05] 00list! [13:05] I have updated the changelog [13:05] To alter the changelog, use `dch -i` from the package top-level directory. Add in a note about what you fixed, and make sure your name is correct. [13:05] oh okay thanks for the 00list headsup [13:06] the changelog I altered manually following earlier changelog entry conventions [13:06] At this point, you can build an updated source package with `debuild -S -us -uc` [13:06] ok so what does what-patch do? [13:06] directhex: Again, 00list only works for a subset of packages :) [13:06] Rudd-O: what-patch tries to determine which patch system is being used, to give you guidance on the best means by which to apply a patch. [13:06] persia, the right-minded ones! [13:06] wait, where is the 00list file? [13:07] i find no 00 file anywhere [13:07] just the patches numbered from 00 to above [13:07] and I can confirm no file lists the patches anywhere [13:08] apparently it is using simple-patchsys [13:08] which has no 00list [13:08] directhex: Err. I disagree with that, but don't want to argue dpatch vs. quilt vs. simple-patchsys vs. Format: 3.0 (foo) right now. [13:09] okay, I'm not sure about these different patch system technologies you seem to be discussiong, but the sensible thing from what I've learnt from debian structure is: plop the patch there, see if it applies, revert it (obviously!) and add to changelog. [13:09] in an ideal world for me, everything would be distributed as git clones [13:09] Rudd-O: If it is using simple-patchsys, you want to use the following procedure to apply the patch: [13:09] 1) determine a name for the patch [13:09] 1) done: 90_dbus_zfs_fix.patch [13:09] 2) From the package top-level directory, call `cdbs-edit-patch name-of-patch` [13:10] 3) In the temporary build tree, apply the patch [13:10] simple-patchsis is remarcably similar to RPM patches [13:10] 4) exit the shell (Ctrl-D or `exit 0` is good). [13:10] cdbs for the changelog? [13:10] That constructs a simple-patchsys compatible patch in debian/patches. [13:10] wait a second [13:11] the patch applies just fine just like the rest of the patches there, why do I need to use cdbs? [13:11] this simple-patchsys seems to me like it complicates stuff [13:11] Rudd-O: cdbs-edit-patch ensures that all the patches are applied in the sequence used at build time, which reduces the chances of conflict from layered patches. [13:12] You may well get lucky, and have a patch just work. [13:12] then I guess I'm feeling lucky [13:12] hey, any of you work at google? [13:12] ok [13:12] now let's try debuilt [13:12] I mean debuild [13:12] cross fingers here! [13:12] debuild :) [13:13] just before debuild [13:13] onemorequestion [13:13] dpkg-source doesn't apply the patches, right? [13:13] It depends on the package construction, but generally not. [13:13] awesome [13:13] running debuild [13:13] WAIT [13:14] Note that some sources have the patches pre-applied from diff.gz, and also in debian/patches, in which case the above would not be correct. (simple-patchsys packages are not of this type) [13:14] oh shit, how do I bump the ver numbe rin the package? [13:14] You edit the version number when you update the changelog. [13:14] Did you not use dch -i? [13:15] If you haven't, you wish to. If you have, you can continue work on your last change with just dch [13:15] (including changing the version string) [13:15] so the version number is taken from the first line of the changelog? that's ingenious! [13:15] It tends to reduce mistakes :) [13:15] ok, no files were created by debuild [13:15] debuild -S -us -uc [13:15] failed I guess? [13:15] Maybe in the parent directory? You ought have at least a .changes file. [13:16] Err. Rather at least a .build file, and likely a .changes file. [13:16] oh, it worked in the parent directory! [13:16] yes, a .source and .build [13:16] what now? [13:17] Now you have a new candidate source package. You want to make a binary package. We usually recommend sbuild or pbuilder for that. [13:17] awesome the .changes contains the changes from the last .diff.gz [13:17] There are convenience scripts in ubuntu-dev-tools to simplify setting these up. [13:17] .build is just a log right? [13:17] !sbuild [13:17] sbuild is a system to easily build packages in a clean schroot environment. To get started with SBuild, see https://help.ubuntu.com/community/SbuildLVMHowto [13:17] !pbuilder [13:17] pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto [13:17] installing that package now [13:18] what is the difference among those two? [13:18] Yes. .build is a log of the source package build, to help debug any issues that may have occurred. [13:18] it's installing bzrrrrrrrr and a bunch of other stuff [13:18] sbuild and pbuilder are different implementations of an automated build process. The main difference is that pbuilder stores the template build chroots in tarballs, and sbuild expects you to have them available for use by schroot. [13:18] what are the main differences between sbuild and pbuilder [13:19] so I would need pbuilder, right? [13:19] why can't it be as easy as rpm -ba ? [13:19] it can, if you want it to be [13:19] Depends on how often you build packages. sbuild is slightly faster for most hardware, although a little more annoying to get set up. [13:20] dpkg-buildpackage -rfakeroot, in the package root directory, is the VERY hairy way to build packages [13:20] directhex: That's also bad because it can damage your precious source package. [13:20] If you want to go the messy way, debuild -b -us -uc is preferred. [13:20] my prEcious!!! [13:20] one reason it's ill-advised because it compiles "in situ", so if you have something installed but not declared in the build dependencies (say, gcc) then it'll WORK for you, but fail to compile on a 'pristine' system [13:21] okay, what's the quick and dirty way? It's just a patch [13:21] what is ddebs.ubuntu.com? [13:21] Rudd-O: Quick and dirty is debuild -b -us -uc, but a package so constructed is often unsuitable for sharing with others, so doing it that way may be considered antisocial. [13:21] but why? [13:21] what do the built packages have of antisocial in them? [13:22] highvoltage: It contains dbgsym packages for everything in the repositoes, for apport retracing and debugging. [13:22] Rudd-O, as stated, they can be wrong, but you won't notice the wrongness due to local environment peculiarities [13:22] Rudd-O: One issue is that directhex mentioned, that the source package may be missing build-dependencies. Another is that some programs will autoconfigure to use libraries locally installed, which may not match the intended build, and create subtle unexpected dependencies. [13:23] but those wrongnesses stem from dependencies and other crap that has already been declared to be good in the original package, right? [13:23] ok [13:23] I will use pbuilder then [13:23] directhex: They may be wrong, if you have lots of -dev packages installed :) [13:23] damn I love RPM. the autodep stuff just doesn't let you get deps wrong! [13:23] Rudd-O: Well, not quite, as building in a different environment may cause the declared dependencies to no longer be correct. [13:24] ok in which directory do I run pbuilder? [13:24] persia: the deps for the binary packages are always correct with RPM [13:24] * persia looks for someone who uses pbuilder to answer that [13:24] just read the manpage [13:24] don't worry [13:24] what? do I have to run that as ROOT? [13:25] Rudd-O: True, but they are also dependent on the packages installed on the local system, which may not match. RPM has different issues with local compiles, but also shares benefit from being built in a clean chroot. [13:25] * persia likes sbuild more: no sudo involved :) [13:25] persia: if the binary packages are dependent on the packages installed in the local system, then they are declared as well in the build products. [13:25] ok doing sudo pbuilder now [13:25] Rudd-O: Right, but those local binary packages may not be available to others, depending on the local system construction, hence possibly being antisocial. [13:26] wait [13:26] pbuilder downloads an ENTIRE DISTRO in the dir? [13:26] Rudd-O: Only the subset required to build the package. [13:26] persia: you got that right, that is true [13:26] persia: but that is HALF A GIGABYTE!!!!!!!! [13:26] I suppose. I don't really count bits much. [13:27] I guess you don't have an 800 kbps connection at home... but much more! [13:27] and wait for it... /var/cache is in ZFS, so the slowdown WILL BE unbearable [13:27] okay [13:27] let's leave it churning for a couple of HOURS and focus on the next step in the agenda [13:27] Some people who do this often have local mirrors. Others may bind-mount apt-sources, like the alternate install CD. [13:28] this is a package that I want to share as a fix for ubuntu hardy [13:28] what should I do? [13:28] Is there a bug open about the issue? [13:28] not sure [13:28] the bug is in freedesktop bts [13:28] That's your first step then: you'll want to have a bug in launchpad to track the task of applying the fix in hardy and getting it tested widely, etc. [13:29] ok [13:29] I will open the bug NOW [13:29] Review the existing bugs, as the testing process goes faster if you can find a bug others are already experiencing. [13:29] (assuming it is truly the same bug) [13:29] lemme add a cookie exception for launchpad [13:30] loggedon [13:30]