[00:12] <blueyed> Uploading to upload.ubuntu.com fails: "Connection failed, aborting. Check your network (111, 'Connection refused')" - temp. problems?
[00:13] <wgrant> blueyed: Scheduled Hardy upgrades.
[00:13] <wgrant> For another 4 hours.
[00:14] <blueyed> wgrant: ah.. forgot about that one. Thanks.
[00:48] <vadi2> How can I make my installed program via a .deb I made appear in Add/Remove, not only in synaptic?
[00:50] <persia> 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] <vadi2> ﻿persia: I did make a .desktop file, yes. It appears in applications menu properly
[00:51] <directhex> look at the app-install-data package
[00:52] <vadi2> I see. So I should stuff the .desktop into '/usr/share/app-install/desktop/' too?
[00:52] <vadi2> (that's what that package does with a bunch of .desktops)
[00:54] <persia> 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] <vadi2> I think I got it, it needs a 'X-AppInstall-Package
[00:55] <vadi2> ' key. I'll test in a sec.
[00:57] <wgrant> persia, vadi2: /usr/share/applications is for installed applications, I don't believe that gnome-app-install looks there.
[00:58] <wgrant> Oh, you mean for picking up by mvo later? Right.
[01:01] <persia> 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] <persia> (and these exceptions are only really meaningful for main)
[01:02] <persia> 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] <vadi2> persia: so what is the proper way to have it appear right away in there?
[01:04] <persia> vadi2: There isn't one.
[01:05] <vadi2> hrm. but then the user can't uninstall a .deb I made without using the synaptic or terminal, which is bad.
[01:06] <persia> 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] <persia> vadi2: How are they installing it?
[01:06] <vadi2> via a .deb I made
[01:06] <persia> With gdebi or some such?
[01:07] <vadi2> yeah.
[01:07] <vadi2> I think it would make sense to be able to trigger app-install-data to regenerate it's index via a package
[01:07] <persia> 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] <vadi2> Why? my program is a commercial one, and I can't afford to use canonical's partner repository.
[01:08] <persia> Review the source, create a patch.  For that package, branches from trunk on LP are the preferred mechanism to present code changes.
[01:08] <vadi2> eh?
[01:09] <wgrant> vadi2: How were you planning on getting the .desktop into the user's system in the first place?
[01:09] <vadi2> ﻿wgrant: I made a .deb which installs it
[01:10] <wgrant> 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] <vadi2> ?
[01:11] <vadi2> Not sure what do you mean. The .deb installs the program, the .desktop, and the icon.
[01:11] <vadi2> The program appears in the Applications category properly.
[01:11] <wgrant> 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] <vadi2> 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] <wgrant> Ah.
[01:12] <wgrant> Well, that's not going to be supported here, I don't think.
[01:12] <persia> 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] <wgrant> Rather unlikely indeed.
[01:13] <vadi2> 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] <persia> 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] <wgrant> But I cannot imagine a Canonical employee would be paid to do that - that would be very silly on their part.
[01:15] <persia> To write the code?  Unlikely.  To merge the code, maybe.
[01:16] <vadi2> Okay, I guess I'll hold off on that and just use an archive for distribution. Thanks for the explanation.
[01:16] <wgrant>  /win 54
[01:16] <wgrant> Gah.
[03:34] <persia> kirkland: Just saw your wiki question.  Is there an example pacakge that illustrates the issue?
[03:35] <kirkland> persia: i'm working on pam at the moment
[03:35] <kirkland> persia: http://merges.ubuntu.com/p/pam/REPORT
[03:35] <kirkland> 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] <persia> kirkland: Right, I'm just trying to understand the situation, so as to document it.
[03:36] <persia> There are a number of different things that could happen to cause a "no conflict" merge report.
[03:37] <kirkland> persia: ah, gotcha
[03:37] <emgent> heya kirkland persia
[03:37] <persia> 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] <kirkland> persia: see: http://merges.ubuntu.com/p/pam/REPORT
[03:38] <kirkland> persia: yes, to your question
[03:38] <kirkland> emgent: hiya sir
[03:38] <persia> kirkland: That's exactly the source from which I copied the phrase :)
[03:39] <kirkland> persia: right, this is the first merge i've ever worked on where there *are no conflicts* :-)
[03:39] <kirkland> persia: so I think the appropriate thing to do is just skip the conflict resolution step
[03:39] <kirkland> persia: and proceed on with the documentation of dropped/remaining changes
[03:41] <persia> 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] <persia> 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] <kirkland> persia: yessir, i'm hanging around here looking for slangasek, in case he comes back online later
[03:46] <persia> 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] <kirkland> persia: awesome, thanks for the advice
[03:51] <persia> 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:52] <persia> Actually, reading that, it makes sense.  Root is locked out anyway, so we don't care.
[04:02] <kirkland> 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.
[04:05] <DBO> has anyone heard from RAOF lately, hes here but MIA lately...
[04:05] <DBO> (sorry to just barge in and ask, i figure if hes been active anywhere, here would be the place)
[04:05] <persia> 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] <persia> DBO: He's been active most days this week.
[04:06] <DBO> persia, thank you, do you remember what times?  I have been trying to catch him
[04:06] <persia> DBO: I'm not that good with time.
[04:07] <DBO> okay
[04:07] <DBO> thank you
[04:12] <persia> 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] <freeflying> persia: I've noticed the maintainer will have new upload in sid, so waiting for his upload
[04:21] <persia> 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] <freeflying> persia: maybe you can mail the maintainer your patch, he has filed RFS recently
[04:22] <freeflying> persia: its up to you :)
[04:22] <persia> freeflying: OK.  Last I looked the patch was lpia-specific, so I'm not sure it's Debian-interesting :)
[04:23] <freeflying> persia: hehe :)
[04:24] <freeflying> persia: then it should be ok for me
[04:25] <persia> 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] <freeflying> persia: thats great!
[06:14] <dholbach> good morning
[06:15] <Iulian> Morning dholbach
[06:16] <dholbach> hi Iulian
[06:46] <geser> good morning
[06:47] <dholbach> hi geser
[06:50] <geser> Hi dholbach
[07:13] <TheMuso> c
[07:14]  * ScottK waits for the ugh.
[07:17]  * StevenK chuckles
[07:23] <TheMuso> Thats long gone. :)
[07:25] <geser> Hi TheMuso
[07:25] <TheMuso> Hey geser.
[07:39] <elmargol> Does debian use tmpfs vor /var/run aswell?
[07:42] <geser> afaik no
[07:45] <ScottK> Not by default, but any Debian user is free to configure their system that way.
[07:51] <mouz> Anyone: is there a written policy that executables must be lower case? I searched for it but did not find it.
[07:52] <slangasek> no, there are executables who have uppercase letters in their names because that's the upstream convention
[07:52] <\sh> moins
[07:53] <mouz> 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] <slangasek> uh - you mean you have a program whose name is CamelCase?
[07:54] <slangasek> because that would be an incredibly ironic renaming :)
[07:54] <mouz> :)
[07:54] <mouz> TouchFreeze
[07:55] <slangasek> there's no policy against renaming it, either
[07:55] <slangasek> there are times when upstream executable names can't be used due to namespace conflicts, so
[07:57] <mouz> i think i just rename it, mention that in changelog without reason
[07:58] <ScottK> Why do you want to rename it?
[08:17] <wgrant> ScottK: To break compatibility with anybody who wants to use it, of course.
[08:17] <ScottK> That was my guess.
[08:18] <wgrant> Uh.
[08:19] <wgrant> 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] <ScottK> I
[08:21] <ScottK> I'll go with breaking the rules.
[08:32] <james_w> wgrant: that was old procedure before you could search for bugs you were subscribed to apparently.
[08:36] <wgrant> james_w: You have been able to search for bugs to which you are subscribed since before 2006.
[08:37] <wgrant> 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] <james_w> oh, sorry, I misunderstood, that's just odd then.
[09:21] <directhex> 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] <wgrant> directhex: Catalyst 8.6, I believe.
[09:27] <directhex> wgrant, 8.6 claims no 4000-series support
[09:27] <directhex> not to say it's not there, but going by the readme, i assume it ain't
[09:31] <tseliot> ﻿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] <wgrant> 4 flavours!?
[09:32] <directhex> wgrant, fun, isn't it
[09:32] <tseliot> ﻿directhex: as regards ATI, I will package 8.6 for EnvyNG while Mario will package it for Intrepid
[09:32] <tseliot> wgrant: yes, and I'm the new maintainer
[09:33] <tseliot> ﻿wgrant: I'm having a lot of fun...
[09:33] <wgrant> tseliot: So I heard.
[09:46] <huats> does anyone can give me some details on the role of the lintian directory in debian/ in a package ?
[10:01] <james_w> huats: I think that usually stores lintian overrides
[10:02] <james_w> they tell lintian to not complain about a specific problem.
[10:02] <james_w> they should be reviewed to ensure they are not masking a real issue.
[10:03] <huats> ok
[10:03] <huats> james_w: thanks
[10:03] <james_w> no problem
[10:03] <huats> james_w: in fact I am facing that in a merge (it is present in the debian package)
[10:04] <huats> so I will have a closer look at it
[10:04] <huats> :)
[10:08] <huats> james_w: the lintian warning that it is handling is binary-or-shlib-defines-rpath
[10:46] <colinl> hi \sh and everyone!
[10:46] <colinl> \sh: this should please you: https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/241587 :)
[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) ? :)
[11:28] <YokoZar> Is the backports team really busy with 8.04.1 stuff?  I'd like to poke them about Wine 1.0 :)
[11:28] <colinl> \sh: sure
[11:33] <colinl> \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] <colinl> ok
[11:41] <colinl> how can I subscribe to motu-sru? I can't find an "Apply" link
[11:43] <wgrant> colinl: Why would you want to do that?
[11:44] <colinl> wgrant: to propose an SRU
[11:44] <wgrant> colinl: motu-sru reviews SRUs - you don't join the team.
[11:44] <colinl> ok
[11:44] <wgrant> You subscribe it to the bug.
[11:53] <colinl> \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] <colinl> ah sorry
[12:12] <colinl> \sh: claws-mail (3.3.1-1ubuntu3build1) hardy-proposed; urgency=low ?
[12:13] <wgrant> !info claws-mail hardy
[12:13] <wgrant> 3.3.1-1ubuntu3.1
[12:13] <colinl> thanks wgrant
[12:14] <\sh> 3.3.1-1ubuntu3
[12:14] <norsetto> good your-time-of-the-day
[12:15] <colinl> updated :)
[12:16] <wgrant> \sh: That's the version in hardy-release..
[12:28] <norsetto> emgent: any news on eggdrop?
[12:28] <Rudd-O> hello there, need help with packaging
[12:29] <Rudd-O> 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] <Rudd-O> my goal is to compile an ubuntu package of the SVN version of dbus
[12:29] <Rudd-O> any quick tutorial that gets me there?
[12:29] <polo> hello everybody7
[12:32] <norsetto> Rudd-O: do you have intrepid enabled as a src repository?
[12:32] <Rudd-O> no
[12:32] <Rudd-O> why?
[12:32] <Rudd-O> I have hardy
[12:32] <Rudd-O> I need a fix that went a few days ago into dbus svn
[12:32] <Rudd-O> because otherwise it fails with ZFS
[12:32] <Rudd-O> I am running ZFS in /var and /usr and /home
[12:32] <Rudd-O> this fix also benefits ntfs3g users
[12:32] <Rudd-O> and I need it like now
[12:33] <Rudd-O> no dbus, no modern desktop environment
[12:33] <norsetto> Rudd-O: You better use the latest src package
[12:33] <Rudd-O> I doubt that the latest intrepid package has the fix
[12:33] <Rudd-O> so I want to build the latest package but using the dpkg data
[12:34] <Rudd-O> anyway
[12:34] <Rudd-O> why is apt-get source failing on me, with the official hardy package?
[12:35] <Rudd-O> i know it's the dpkg-source routine that is failing
[12:35] <Rudd-O> but WHY?
[12:35] <norsetto> Rudd-O: no idea. I tried the intrepid one and there is no problem
[12:36] <norsetto> Rudd-O: you can also use -t intrepid if you don't want to change your sources.list
[12:36] <Rudd-O> ook
[12:36] <Rudd-O> let's try that
[12:36] <Rudd-O> apt-get -t intrepid source dbus?
[12:37] <norsetto> Rudd-O: yes
[12:37] <Rudd-O> Des:2 http://mirrors.kernel.org hardy-updates/main dbus 1.1.20-1ubuntu2 (tar) [1402kB]
[12:37] <Rudd-O> that didn't work
[12:37] <Rudd-O> still gets from hardy
[12:37] <Rudd-O> idea?
[12:37] <Rudd-O> same problem
[12:38] <wgrant> Do other sources work?
[12:38] <Rudd-O> no
[12:38] <Rudd-O> same problem with fuse source
[12:38]  * wgrant would blame your strange FS setup.
[12:39] <Rudd-O> hardly
[12:39] <norsetto> Rudd-O: than you just miss some build-essential
[12:39] <james_w> Rudd-O: is it just complaining about signatures?
[12:39] <Rudd-O> there is a complaint about signatures, publc key not found
[12:39] <Rudd-O> but that has nothing to do with dpkg-source's attempt to delete a nonexistent file!
[12:40] <Rudd-O> 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] <Rudd-O> again, the filesystem is orthogonal to the issue
[12:41] <norsetto> Rudd-O: it might be perpendicular too but the problem is in your machine
[12:41] <Rudd-O> so?  any ideas on how to track this issue down?
[12:42] <Rudd-O> let me strace it all
[12:42] <persia> 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] <Rudd-O> here was it sais
[12:45] <Rudd-O> apt-get source downloads the stuff and places it into the directory
[12:45] <Rudd-O> then apt-source successfully untars the file and runs patch
[12:45] <Rudd-O> and the patch *succeeds*
[12:46] <Rudd-O> then dpkg-source attempts to delete a file ending in .dpkg-orig which doesn't exist there
[12:46] <Rudd-O> *boom* goes the terrorist
[12:46] <Rudd-O> I don't need the perl debugger to figure that out
[12:47] <Rudd-O> let's read the source, see what the hell it's trying to do
[12:47] <Rudd-O> there is someting else I would like to know
[12:47] <Rudd-O> how come there is a debian/patches in the source dir, and there is ALSO a .diff.gz in the pwd?
[12:49] <persia> Rudd-O: lsdiff -z foo.diff.gz to answer the last question
[12:49] <Rudd-O> lemme install that tool
[12:49] <Rudd-O> no such package lsdiff
[12:49] <Rudd-O> > aptitude search lsdiff
[12:50] <Rudd-O> 0 bytes reply
[12:50] <persia> Rudd-O: patchutils
[12:50] <Rudd-O> ok
[12:50] <Rudd-O> installing...
[12:50] <Rudd-O> hey, anyone here work at google?
[12:51] <Rudd-O> ok so the .diff.gz gets uncompressed in the source tree?  neato.
[12:54] <persia> 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] <Rudd-O> okay
[12:55] <Rudd-O> interesting,v ery interesting, I'm learning a lot now
[12:55] <Rudd-O> well, I have surpassed the dpkg-source problem by manually untarring and patching
[12:55] <Rudd-O> what's next?
[12:56] <Rudd-O> I assume plugging in the original source?
[12:56] <Rudd-O> how do I get from the original source plus debian-specific patches to a deb?
[12:56] <Rudd-O> debian/patches/* I assume are applied when the package is actually built, right?
[12:57] <persia> 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] <Rudd-O> Adjust the variance in diff.gz <- what does this mean?
[12:57] <persia> 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] <directhex> persia, uupdate!
[12:58] <Rudd-O> ok
[12:58] <persia> 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] <Rudd-O> I want ot just apply the patch
[12:58] <Rudd-O> ok, this is a patch that has NOT made it into upstream
[12:59] <persia> directhex: In those cases where it works, maybe, but it's very rare that uupdate lets one construct a new SVN snapshot.
[12:59] <Rudd-O> https://bugs.freedesktop.org/attachment.cgi?id=16746
[12:59] <Rudd-O> I just plop it into debian/patches?
[12:59] <persia> Rudd-O: What did which-patch tell you?
[13:00] <persia> Sorry.  "what-patch"
[13:01] <Rudd-O> what?  what do you mean?  is there a what-patch command?
[13:01] <Rudd-O> I just plopped the patch and adjusted for build system into debian/patches
[13:01] <Rudd-O> what next?
[13:03] <Rudd-O> the patch was applied correctly, when I do it manually
[13:03] <Rudd-O> what's next after plopping the patch in there?
[13:03] <Rudd-O> I mean, changelog and how do I build it?
[13:05] <persia> 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] <directhex> 00list!
[13:05] <Rudd-O> I have updated the changelog
[13:05] <persia> 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] <Rudd-O> oh okay thanks for the 00list headsup
[13:06] <Rudd-O> the changelog I altered manually following earlier changelog entry conventions
[13:06] <persia> At this point, you can build an updated source package with `debuild -S -us -uc`
[13:06] <Rudd-O> ok so what does what-patch do?
[13:06] <persia> directhex: Again, 00list only works for a subset of packages :)
[13:06] <persia> 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] <directhex> persia, the right-minded ones!
[13:06] <Rudd-O> wait, where is the 00list file?
[13:07] <Rudd-O> i find no 00 file anywhere
[13:07] <Rudd-O> just the patches numbered from 00 to above
[13:07] <Rudd-O> and I can confirm no file lists the patches anywhere
[13:08] <Rudd-O> apparently it is using simple-patchsys
[13:08] <directhex> which has no 00list
[13:08] <persia> 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] <Rudd-O> 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] <Rudd-O> in an ideal world for me, everything would be distributed as git clones
[13:09] <persia> Rudd-O: If it is using simple-patchsys, you want to use the following procedure to apply the patch:
[13:09] <persia> 1) determine a name for the patch
[13:09] <Rudd-O> 1) done: 90_dbus_zfs_fix.patch
[13:09] <persia> 2) From the package top-level directory, call `cdbs-edit-patch name-of-patch`
[13:10] <persia> 3) In the temporary build tree, apply the patch
[13:10] <Rudd-O> simple-patchsis is remarcably similar to RPM patches
[13:10] <persia> 4) exit the shell (Ctrl-D or `exit 0` is good).
[13:10] <Rudd-O> cdbs for the changelog?
[13:10] <persia> That constructs a simple-patchsys compatible patch in debian/patches.
[13:10] <Rudd-O> wait a second
[13:11] <Rudd-O> the patch applies just fine just like the rest of the patches there, why do I need to use cdbs?
[13:11] <Rudd-O> this simple-patchsys seems to me like it complicates stuff
[13:11] <persia> 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] <persia> You may well get lucky, and have a patch just work.
[13:12] <Rudd-O> then I guess I'm feeling lucky
[13:12] <Rudd-O> hey, any of you work at google?
[13:12] <Rudd-O> ok
[13:12] <Rudd-O> now let's try debuilt
[13:12] <Rudd-O> I mean debuild
[13:12] <Rudd-O> cross fingers here!
[13:12] <persia> debuild :)
[13:13] <Rudd-O> just before debuild
[13:13] <Rudd-O> onemorequestion
[13:13] <Rudd-O> dpkg-source doesn't apply the patches, right?
[13:13] <persia> It depends on the package construction, but generally not.
[13:13] <Rudd-O> awesome
[13:13] <Rudd-O> running debuild
[13:13] <Rudd-O> WAIT
[13:14] <persia> 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] <Rudd-O> oh shit, how do I bump the ver numbe rin the package?
[13:14] <persia> You edit the version number when you update the changelog.
[13:14] <persia> Did you not use dch -i?
[13:15] <persia> If you haven't, you wish to.  If you have, you can continue work on your last change with just dch
[13:15] <persia> (including changing the version string)
[13:15] <Rudd-O> so the version number is taken from the first line of the changelog?  that's ingenious!
[13:15] <persia> It tends to reduce mistakes :)
[13:15] <Rudd-O> ok, no files were created by debuild
[13:15] <Rudd-O> debuild -S -us -uc
[13:15] <Rudd-O> failed I guess?
[13:15] <persia> Maybe in the parent directory?  You ought have at least a .changes file.
[13:16] <persia> Err.  Rather at least a .build file, and likely a .changes file.
[13:16] <Rudd-O> oh, it worked in the parent directory!
[13:16] <Rudd-O> yes, a .source and .build
[13:16] <Rudd-O> what now?
[13:17] <persia> 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] <Rudd-O> awesome the .changes contains the changes from the last .diff.gz
[13:17] <persia> There are convenience scripts in ubuntu-dev-tools to simplify setting these up.
[13:17] <Rudd-O> .build is just a log right?
[13:17] <persia> !sbuild
[13:17] <persia> !pbuilder
[13:17] <Rudd-O> installing that package now
[13:18] <Rudd-O> what is the difference among those two?
[13:18] <persia> Yes.  .build is a log of the source package build, to help debug any issues that may have occurred.
[13:18] <Rudd-O> it's installing bzrrrrrrrr and a bunch of other stuff
[13:18] <persia> 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] <Rudd-O> what are the main differences between sbuild and pbuilder
[13:19] <Rudd-O> so I would need pbuilder, right?
[13:19] <Rudd-O> why can't it be as easy as rpm -ba ?
[13:19] <directhex> it can, if you want it to be
[13:19] <persia> 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] <directhex> dpkg-buildpackage -rfakeroot, in the package root directory, is the VERY hairy way to build packages
[13:20] <persia> directhex: That's also bad because it can damage your precious source package.
[13:20] <persia> If you want to go the messy way, debuild -b -us -uc is preferred.
[13:20] <Rudd-O> my prEcious!!!
[13:20] <directhex> 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] <Rudd-O> okay, what's the quick and dirty way?  It's just a patch
[13:21] <highvoltage> what is ddebs.ubuntu.com?
[13:21] <persia> 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] <Rudd-O> but why?
[13:21] <Rudd-O> what do the built packages have of antisocial in them?
[13:22] <persia> highvoltage: It contains dbgsym packages for everything in the repositoes, for apport retracing and debugging.
[13:22] <directhex> Rudd-O, as stated, they can be wrong, but you won't notice the wrongness due to local environment peculiarities
[13:22] <persia> 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] <Rudd-O> but those wrongnesses stem from dependencies and other crap that has already been declared to be good in the original package, right?
[13:23] <Rudd-O> ok
[13:23] <Rudd-O> I will use pbuilder then
[13:23] <persia> directhex: They may be wrong, if you have lots of -dev packages installed :)
[13:23] <Rudd-O> damn I love RPM.  the autodep stuff just doesn't let you get deps wrong!
[13:23] <persia> Rudd-O: Well, not quite, as building in a different environment may cause the declared dependencies to no longer be correct.
[13:24] <Rudd-O> ok in which directory do I run pbuilder?
[13:24] <Rudd-O> 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] <Rudd-O> just read the manpage
[13:24] <Rudd-O> don't worry
[13:24] <Rudd-O> what? do I have to run that as ROOT?
[13:25] <persia> 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] <Rudd-O> 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] <Rudd-O> ok doing sudo pbuilder now
[13:25] <persia> 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] <Rudd-O> wait
[13:26] <Rudd-O> pbuilder downloads an ENTIRE DISTRO in the dir?
[13:26] <persia> Rudd-O: Only the subset required to build the package.
[13:26] <Rudd-O> persia: you got that right, that is true
[13:26] <Rudd-O> persia: but that is HALF A GIGABYTE!!!!!!!!
[13:26] <persia> I suppose.  I don't really count bits much.
[13:27] <Rudd-O> I guess you don't have an 800 kbps connection at home... but much more!
[13:27] <Rudd-O> and wait for it... /var/cache is in ZFS, so the slowdown WILL BE unbearable
[13:27] <Rudd-O> okay
[13:27] <Rudd-O> let's leave it churning for a couple of HOURS and focus on the next step in the agenda
[13:27] <persia> Some people who do this often have local mirrors.  Others may bind-mount apt-sources, like the alternate install CD.
[13:28] <Rudd-O> this is a package that I want to share as a fix for ubuntu hardy
[13:28] <Rudd-O> what should I do?
[13:28] <persia> Is there a bug open about the issue?
[13:28] <Rudd-O> not sure
[13:28] <Rudd-O> the bug is in freedesktop bts
[13:28] <persia> 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] <Rudd-O> ok
[13:29] <Rudd-O> I will open the bug NOW
[13:29] <persia> Review the existing bugs, as the testing process goes faster if you can find a bug others are already experiencing.
[13:29] <persia> (assuming it is truly the same bug)
[13:29] <Rudd-O> lemme add a cookie exception for launchpad
[13:30] <Rudd-O> loggedon
[13:30] <highvoltage> persia: ah, thanks, I think I may need to do some more reading there :)
[13:31] <persia> highvoltage: Are you just seeking to understand, or were you pursuing a particular goal?
[13:31] <persia> If the former, looking at the apport and pkg-create-dbgsym packages may be more informative than arbitrary Google queries.
[13:32] <Rudd-O> alright
[13:32] <Rudd-O> I have reported the bug
[13:33] <Rudd-O> what files do I need to uplaod to have them incorporated and looked at by the hardy-proposed repo managers?
[13:33] <persia> !sru
[13:33] <Rudd-O> guys?
[13:33] <persia> The next step is to review the Stable Release Updates policy that ubottu just referenced, and proceed with that to get the update into the repositories.
[13:33] <Rudd-O> ok
[13:34] <persia> Part of that will involve testing your package, and attaching a debdiff with the fix to the bug.
[13:35] <persia> You can generate the debdiff by running debdiff old-version.dsc new-version.dsc.  You may want to do this while you are waiting for pbuilder to examine your changes, and ensure nothing unexpected occured.
[13:35] <Rudd-O> ok
[13:35] <Rudd-O> debdiff?
[13:35] <Rudd-O> awesome
[13:35] <Rudd-O> that was my question
[13:38] <directhex> and diffstat is nice for seeing which files have changed. IMHO anyway
[13:38] <persia> directhex: Really?  I always use lsdiff and view to inspect patches, and find diffstat of limited value.
[13:39] <persia> What about diffstat do you like?
[13:39] <directhex> persia, i just like the simple representation
[13:39] <directhex> persia, it's visual enough for my feeble mind
[13:40] <persia> directhex: Ah.  That makes sense.  I don't find a close correlation between number of lines changed and possible impact of change, but that might just be me.
[13:40] <Rudd-O> oh, I need to talk to scott
[13:41] <Rudd-O> diffstat is info-dense
[13:41] <directhex> persia, it helps me quickly see which files have changed, and by how much. anything beyond that is pretty much a leap of faith anyway, unless i'm doing a full patch audit. and honestly, reading enormous autoreconf patch updates is dull.
[13:41] <Rudd-O> ok apparently pbuilder is pdownloading a pseries of packages that will be pfinished in a couple of pminutes
[13:48] <persia> directhex: Makes sense.  I tend to find that patches that change lots are often of the autoreconf variety, but that a one-liner that changes something (e.g. "#DEFINE FOO 100" -> "#DEFINE FOO 0100") can have enourmous impact.
[13:48] <directhex> well, yes
[13:50] <highvoltage> persia: no particular goal, just wanting to understand
[13:51] <persia> highvoltage: OK.  I hope those two packages explain it sufficiently.  Feel free to ask if you have specific questions.
[14:05] <ember> nixternal thanks! and congrats.
[14:06] <highvoltage> persia: thanks :)
[14:07] <Rudd-O> hey there nixternal
[14:13] <Rudd-O> this sucks sticky balls
[14:13] <Rudd-O> this sucks sticky balls
[14:14] <Rudd-O> pbuilder gave me the exact same frigging error
[14:14] <Rudd-O> dpkg-source: failure: remove patch backup file dbus-1.1.20/debian/patches/03_fix_inotify.patch.dpkg-orig: No such file or directory
[14:14] <Rudd-O> WHY DOES IT WANT TO DELETE AN ORIG FILE THAT DOES NOT EXIST??????
[14:15] <Rudd-O> goddamnit
[14:17] <Rudd-O> monkeypatched that shit, to see how it goes
[14:20] <laga> Rudd-O: language please
[14:25] <Rudd-O> a-ok, laga
[14:31] <Rudd-O> okay I officially GIVE UP
[14:31] <Rudd-O> pbuilder insists on removing nonexistent files even after the monkey patch
[14:32] <Rudd-O> which is probably because it's using its own chroot
[14:33] <Rudd-O> see you guys, thanks for the brave help
[14:33] <persia> Rudd-O: You might want to try with a different package, as you may have exposed an issue with the package with which you are working.
[14:33] <persia> Bah.
[15:12] <huats> what is the benefit of adding dpkg-dev in the build-depends of a package (it is the case in the debian package that I am merging)
[15:12] <huats> ?
[15:16] <james_w> it might be doing something like using dpkg-parsechangelog to get the current version number of the package.
[15:16] <james_w> I'd ./debian/rules to see what they may be up to.
[15:19] <persia> huats: Is it a versioned dependency on dpkg-dev?  dpkg-dev is already build-essential, so if it doesn't need a newer version, it's a fairly useless dependency.
[15:20] <huats> persia: dpkg-dev (>= 1.14.16)
[15:21] <persia> huats: Ah, that might be important: you could check the dpkg-dev changelog to get an understanding why.
[15:21] <huats> I am having a look right now
[15:21] <persia> Once build-essential has a versioned depends on a sufficient version of dpkg-dev, and all supported releases also have a sufficiently new dpkg-dev, it may be dropped.
[15:21] <cody-somerville> james_w, https://bugzilla.novell.com/show_bug.cgi?id=361180
[15:22] <james_w> cody-somerville: yeah, I saw.
[15:28] <huats> persia: currently build-essential depends on dpkg-dev >= 1.13.5
[15:28] <huats> so it might be the reason
[15:29] <huats> thus I might need to let the dependency
[15:30] <huats> I have found the reason in the package that I am merging
[15:30] <huats> thanks persia
[15:31] <persia> huats: No, thank you for tracking it down.  What was the cause for the newer dpkg-dev requirement?
[15:31] <huats> yep
[15:32] <huats> Update DM-Upload-Allowed according to change in dpkg 1.14.16
[15:32] <huats> (from the debian changelog)
[15:33] <huats> so there has been a change in dpkg in 1.14.16 and since they use that syntax they need to explicit the version number
[15:35] <huats> persia: what is exactly DM-Upload-Allowed ?
[15:35] <persia> Aha!  That would do it.  Not very meaningful for Ubuntu, but won't cause any harm.
[15:36] <huats> I am looking what it is and I don't find
[15:36] <persia> DM-Upload-Allowed means that those in the Uploaders field can upload if they are in the Debian-Maintainers keyring, even if they are not Debian Developers.
[15:36] <persia> It is a means by which non-DD maintainers of packages can reduce sponsoring delays for updates.
[15:36] <huats> ok
[15:36] <huats> thanks
[15:37] <huats> since I am heading for a sync
[15:37] <huats> it is harmless right ?
[15:37] <huats> I don't need to ask a merge because of that right ?
[15:39] <james_w> huats: there will be no problem in using making it a sync if the only difference is the addition of dpkg-dev.
[15:39] <james_w> s/using //
[15:39] <persia> huats: It's harmless: makes no difference in Ubuntu, and oughtn't cause FTBFS.
[15:40] <persia> If the Debian change was the removal of this, I'd not advocate keeping it as Ubuntu variation, as there's no Ubuntu benefit.
[15:40] <huats> james_w thanks
[15:41] <huats> persia: there has been a few other addition
[15:41] <huats> some needed ones...
[15:41] <huats> and that  one which is useless for Ubuntu.
[15:41] <huats> so I am finishing
[15:41] <huats> it
[15:41] <huats> :)
[15:41] <huats> but I think I will ask a sync
[15:42] <huats> thanks
[15:52] <norsetto> huats: how is your calf?
[15:56] <dholbach> your what? :)
[16:02] <norsetto> dholbach: not the animal :-)
[16:31] <Lutin> james_w: why did you list the CVE fix as ubuntu change in the cecilia debdiff ?
[16:31] <james_w> Lutin: to make sure it was picked up in the CVE tracking.
[16:33] <Lutin> james_w: ah, ok
[16:34] <james_w> It's maybe not necessary, but I took the belt and braces approach
[16:36] <Lutin> james_w: btw, how does the CVE tracking picks up such things ? regexp matching on the changelog ?
[16:36] <james_w> Lutin: I don't think it is automatic.
[16:36] <james_w> I can always remove the entry, I'm going to spend some more time on it tonight.
[16:37] <Lutin> ok
[16:41] <Laney> Lutin: Can you ack the clearsilver sync request? Sorry for confusion.
[16:45] <Laney> or dholbach: ^
[17:04] <persia> james_w: As long as the merge upload is done with the correct -v call so that the .changes includes the Debian variation, you don't need to repeat yourself.  Note that if you aren't making the final .changes, it doesn't hurt to be careful.
[17:06] <Lutin> TheMuso: if csound builds correctly, can the copyright change be dropped ?
[18:11] <Traktor1> pls come in new IRC server balkanchat.no-ip.org just type /s -m balkanchat.no-ip.org .We will give you IRC OP
[18:11] <Traktor1> pls come in new IRC server balkanchat.no-ip.org just type /s -m balkanchat.no-ip.org .We will give you IRC OP
[18:11] <Traktor1> pls come in new IRC server balkanchat.no-ip.org just type /s -m balkanchat.no-ip.org .We will give you IRC OP
[18:11] <Traktor1> pls come in new IRC server balkanchat.no-ip.org just type /s -m balkanchat.no-ip.org .We will give you IRC OP
[18:11] <Traktor1> pls come in new IRC server balkanchat.no-ip.org just type /s -m balkanchat.no-ip.org .We will give you IRC OP
[18:24] <calc> i got an email that my motu membership is about to expire, should i let it expire and have it moved over to ubuntu-dev instead?
[18:25] <calc> or is "motu" still considered a live group?
[18:25] <jpds> calc: you can renew on Launchpad.
[18:26] <calc> jpds: yea i see that, but should it get renewed under the new(?) ubuntu-dev group instead of motu?
[18:27] <calc> or is motu the new group, i am a bit confused on which is the new group
[18:27] <jpds> calc: all MOTU memberships should be done via the ~motu group.
[18:27] <calc> ah ok
[18:33] <TomJaeger> how do I tell pbuilder to give me a shell when there's an error?
[18:34] <laga> there's a hook for that
[18:36] <james_w> TomJaeger: http://blog.madism.org/index.php/2006/06/27/93-pbuilder-custom-configurations
[18:36] <james_w> http://madism.org/~madcoder/pbuilder/C10_launch_shell
[18:37] <james_w> it needs to be executable in --hookdir
[18:37] <TomJaeger> thanks
[20:21] <TomJaeger> grrr, gtk-builder-convert produces garbage in a pbuilder environment and i have no clue why.  But after installing ubuntu-desktop, everything works fine.
[20:25] <TomJaeger> Is there a way to get a list of all the files a program reads during execution?
[20:25] <laga> strace?
[20:27] <TomJaeger> thanks, that looks like it might work
[20:45] <TomJaeger> sweet, that actually worked, the culprit is one of these packages: libc6-i686 libgtk2.0-dev libxml2-utils locales python2.5 python2.5-minimal python-apport python-gst0.10 python-imaging python-minimal python-numeric python-support time util-linux
[21:03] <TomJaeger> okay, it's libxml2-utils, filing a bug report
[21:04]  * sebner is taking a break from learning for giving ScottK a bear hug =)
[21:05] <ScottK> sebner: I did a bit of editing on your debian/changelog entry.  Since it's been so long, I just edited and uploaded, but please have a look at what I changed.
[21:06] <ScottK> sebner: Thanks for taking that one on.  Courier is a pretty 'fun' experience.
[21:06] <sebner> ScottK: Yeah I already discovered that you edited the changelog. will look at it later :) So, the fun is over. what's now you impression ^^
[21:07] <ScottK> Pretty good.
[21:09] <sebner> ha! With this comment of ScottK no one can stop me to conquer the world ... or become MOTU, hmm or something like that .. xD
[21:14] <sebner> ScottK: but also thanks to you for reviewing it. I know I was a bit annoying and reviewing courier is also not that fun. so thanks =)
[21:14]  * sebner hugs ScottK 
[21:15] <ScottK> No problem.
[21:15] <ScottK> mok0 is the one that should be happy.  He'd touched it last before.  Now courier is YOURs.
[21:15] <ScottK> ;-)
[21:17] <sebner> ScottK: Well, if I become MOTU in the next few months I can delegate it for intrepid +1 ;) Or you are looking for a new victim aka potential motu :P
[21:40] <sebner> ScottK: whitespaces?
[21:40] <ScottK> No
[21:41] <sebner> ScottK: kompare shows me that you added 2 bug numers and changed a "+" to a "-"
[21:42] <ScottK> Right.
[21:43] <ScottK> So what does that tell you?
[21:44] <sebner> ScottK: I should look if I can close other bugs too. the other is a minor cosmetic change
[21:44] <ScottK> Yes.  Also look and see if there are also bugs you can fix when you are merging.
[21:45] <ScottK> Also, don't forget that debian/changelog is designed to be machine parsable, so keep to standard formatting as much as you can.
[21:45] <sebner> ScottK: Will try, thanks for the hints
[21:47] <sebner> ScottK: about merging. I followed the mail discussion. What sense does it make to request a Exeption for a merge? We now that since import freeze we want "important" merges but exeptions ...
[21:47] <sebner> *know
[21:48] <ScottK> sebner: I think the entire concept is silly.  If a developer thinks a merge is worth doing, they should do it/sponsor it.
[21:48] <sebner> ScottK: right but we does this came up?
[21:48] <sebner> *did come
[21:49] <ScottK> It was a reaction to the ubuntu-devel-announce message about upcomig DIF that referred to getting exceptions.
[21:50] <cody-somerville> wait...
[21:50] <cody-somerville> who approves that?
[21:50] <sebner> cody-somerville: for ...
[21:51] <norsetto> sebner: we better get flightgear ready
[21:51] <sebner> norsetto: no reaction by debian yet ... I'll be off until tuesday, wednesday but will look at it if you want
[21:52] <ScottK> cody-somerville: There was a long IRC thread on this yesterday in ubuntu-devel.  grep the logs for persia and I talking for the highlights.
[21:52] <norsetto> sebner: yes, we have to get rid of it, there is an NBS that I would like to clear that depends on it
[21:53] <norsetto> sebner: also, you may want to coordinate with emgent about eggdrop?
[21:53] <cody-somerville> ScottK, Maybe the people involved that discussion and yourself could write something to the ML to help keep everyone on the same page?
[21:54] <sebner> norsetto: Yes but not today. will  be off soon. I offered him that he can do it but I'm  not sure if he is working on it or not
[21:54] <norsetto> sebner: well, the deadline is the 26th, so we can wait until tuesday/wednesday, but not later
[21:55] <sebner> norsetto: deadline?
[21:55] <norsetto> sebner: dif
[21:55] <sebner> norsetto: I know that every package should be merged one but why? what's so bad doing it later?
[21:56] <norsetto> sebner: lots of discussions going on at the moment, but if there is a rule, lets try to stick to it
[21:56] <sebner> norsetto: bad rule
[21:57] <norsetto> sebner: whats the problem? We have plenty of time
[21:57] <sebner> norsetto: 6 days ^^ and I'm off for 4-5 days xD
[21:58] <norsetto> sebner: it takes half an hour max to fixe those two, these leave us 1 day to enjoy our well-deserved rest
[21:58] <sebner> norsetto: will see, maybe I do flightgear and he eggdrop?
[21:59] <norsetto> sebner: as you wish, I don't mind either way
[21:59] <sebner> norsetto: kk, may you want to tell him then
[21:59] <norsetto> sebner: sure
[21:59] <norsetto> sebner: enjoy your mini-holiday
[22:00] <sebner> norsetto: well, my mini-holiday starts on tuesday ;) montag is the big day
[22:00] <sebner> lol
[22:00] <sebner> monday
[22:00] <sebner> sry. german word ^^
[22:01] <norsetto> sebner: good luck with your exams, you will pass with full marks ;-)
[22:01] <sebner> norsetto: ^^, thanks
[22:01] <sebner> norsetto: btw, but I love the idea. merge as many as you can =)
[22:04] <sebner> \sh: though you can get troubles because you don't file bugs :P
[22:05] <\sh> sebner: ?
[22:06] <sebner> \sh: everybody can do any merge without asking the previous uploader. And you are normally your work without filing bugs you said. so a lot of double work =)
[22:13] <sebner> ember: hey, you are doing a lot of gnome stuff. *cool* :)
[22:21] <RoAkSoAx> hey guys, have a question... how to apply a patch using cdbs (i downloaded the patch from a website and i want to apply it to the package)
[22:26] <ScottK> RoAkSoAx: Add simple patchsys to your debian/rules and then use cdbs-edit-patch
[22:27] <RoAkSoAx> ScottK, by just doing cdbs-edit-patch patch-name.patch  (where patch-name.patch is the name of the patch i downloaded?)
[22:27] <ScottK> No.  If you know the patch applies to your source without adujstment, you can just copy it into debian/patchs.
[22:28] <ScottK> Or cdbs-edit-patch patch-name.patch where patch-name.patch is what you want the final patch name to be.
[22:29] <ScottK> Then apply the patch manually using patch in the tmp dir
[22:29] <ScottK> The latter approach you can be sure that the patch will apply during build.
[22:31] <RoAkSoAx> ScottK, ok so for example: cbds-edit-patch name.patch , then patch -p1 < downloaded-patch.patch, and finally ctrl+d, right?
[22:31] <sebner> gn8 folks, see you next week.
[22:31] <ScottK> Right except exit at the end instead of ctrl d.
[22:32] <RoAkSoAx> ScottK, ok thanks :D
[22:47] <\sh> sebner: if I have a merge finished, I'm uploading directly...if I don't upload, there is no merge from me
[22:47] <\sh> s/from/by/
[22:48] <\sh> anyways..