Re: Problems pdebuilding a quilt-based package
Hello, > > fakeroot debian/rules clean > > # do not abort if quilt pop fails (this is usually if there no > > patches applied > > quilt pop -a || true > > No patch removed > > quilt push 10_addBuildInfrastructure > > No patches in series > > You probably have a .quiltrc that sets non-default options > (e.g. QUILT_PATCHES=debian/patches). The .quiltrc is not available in > the pbuilder environment, thus the build fails. Thanks a lot, that was indeed the reason. Best regards Ben -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Problems pdebuilding a quilt-based package
Hello, I have a package which builds just fine when running debuild. It also works fine, taking the source files created by debuild run "dpkg-soruce -x" and then debuild in the resulting directory. However, I am unable to pdebuild the package from the same directory where debuild works perfectly. Pdebuild fails to apply the quilt patches(see below). I have no idea what is causing this. I am including the significant parts of the debuild output as well as the pdebuild output. Here comes the pdebuild output: [Setup of the build system using cowbuilder snipped] Setting up fakeroot (1.12.2) ... I: Copying back the cached apt archive contents I: Copying source file I: copying [/umlet/umlet_9.1-1.dsc] I: copying [/umlet/umlet_9.1.orig.tar.gz] I: copying [/umlet/umlet_9.1-1.diff.gz] I: Extracting source dpkg-source: warning: extracting unsigned source package (umlet_9.1-1.dsc) dpkg-source: extracting umlet in umlet-9.1 dpkg-source: info: unpacking umlet_9.1.orig.tar.gz dpkg-source: info: applying umlet_9.1-1.diff.gz I: Building the package dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package umlet dpkg-buildpackage: source version 9.1-1 dpkg-buildpackage: source changed by Benjamin Mesing dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean # do not abort if quilt pop fails (this is usually if there no patches applied quilt pop -a || true No patch removed quilt push 10_addBuildInfrastructure No patches in series make: *** [clean-patched] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2 E: Failed autobuilding of package I: unmounting dev/pts filesystem I: unmounting proc filesystem -> Cleaning COW directory forking: rm -rf /var/cache/pbuilder/build//cow.7782 Here comes the debuild output: dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package umlet dpkg-buildpackage: source version 9.1-1 dpkg-buildpackage: source changed by Benjamin Mesing dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean # do not abort if quilt pop fails (this is usually if there no patches applied quilt pop -a || true No patch removed quilt push 10_addBuildInfrastructure Applying patch 10_addBuildInfrastructure.diff patching file Makefile Now at patch 10_addBuildInfrastructure.diff rm -f build-stamp /usr/bin/make clean make[1]: Entering directory `/home/ben/debian/umlet/umlet-9.1' rm -f umlet.jar rm -f epsgraphics.jar rm -rf bin rm -rf epsgraphics/bin make[1]: Leaving directory `/home/ben/debian/umlet/umlet-9.1' dh_clean quilt pop -a Removing patch 10_addBuildInfrastructure.diff Removing Makefile No patches applied QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 No patch removed rm -rf .pc debian/stamp-patched dpkg-source -b umlet-9.1 dpkg-source: info: using source format `1.0' dpkg-source: info: building umlet using ex
Re: How to create quilt-based source packages using debuild
> Start with the unpatched upstream source. > Copy the debian dir in including debian/patches/. > echo "3.0 (quilt)" >debian/source/format > remove patch system from debian/rules if present > debuild Thanks for the pointer. However, since the archive does not support Format 3.0 (quilt) yet, I will stick to format 1.0 for now. Best regards Ben -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
How to create quilt-based source packages using debuild
Hi, I am having trouble understanding how to build a quilt based source-package. My packaging is based on quilt, but when running debuild, debuild creates a traditional style source package. I've tried to add "Format: 3.0 (quilt)" to the control file and a Format 3 source package is correctly created (i.e. an orig.tar.gz and a debian.tar.gz), but that resulted in a lintian warning: W: umlet source: empty-debian-diff and dpkg-genchanges complains about dpkg-genchanges: warning: unknown information field 'Format' in input data in general section of control info file Are those tools not yet quilt ready or am I doing something wrong? Best regards Ben -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package extraction process (dpkg-source, format 1.0 and 3.0 (quilt))
> > * In the same section there is a note: > > "Note: dpkg-source expects the source tree to have all patches > > applied when you generate the source package. This is not the > > case when the source tree has been obtained by unpacking a > > source package using the Format: 1.0 for instance." > > But unpacking format 1.0 packages does lead to a tree with all > > patches applied, doesn't it? > > Not always, since extracting a non-native package prepared as format 1.0 is > done by first unpacking the .orig.tar.gz and then applying the patch in > the .diff.gz. Now, you have two kinds of diff.gz - hooligan ones which > directly modify upstream files when applied as one fat, monolitic and > illogical changeset, and such that create logically separated diffs in > debian/patches/ which are then applied build time. So you will not have all patches applied only, if you are using a patch system like dpatch or quilt - which for format 1.0 had nothing to do with dpkg-source. > > Does this refer to using some > > external patch system like dpatch? > > Not mandatory. Directly citing from #482741: > "In this process, if the .diff.gz contains changes to upstream files, > dpkg-source will have created a corresponding patch in > debian/patches/debian-changes-2.1.0-3 and will have registered that > patch in a quilt series (debian/patches/series, it is created if needed). > All the patches listed in the "series" file are applied directly during > the extraction (dpkg-source -x). quilt itself is used if available (and > will thus lead to the creation of the .pc directory), otherwise > dpkg-source applies the patches by itself." This is true for the 3.0 format, but not for 1.0, or am I missing something? Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package extraction process (dpkg-source, format 1.0 and 3.0 (quilt))
Hello, I am trying to understand the new dpkg-source format 3.0 (quilt). There are two points in the documentation (man-page) I do not understand: * In the section "Building" of the description of 3.0 (quilt) it is stated: "The updated debian directory and the list of modified binaries is then used to regenerate the debian tarball." Why is it "regenerate" instead of "generate" here? I believe, it is not uncommon, that no debian tarball exists before. * In the same section there is a note: "Note: dpkg-source expects the source tree to have all patches applied when you generate the source package. This is not the case when the source tree has been obtained by unpacking a source package using the Format: 1.0 for instance." But unpacking format 1.0 packages does lead to a tree with all patches applied, doesn't it? Does this refer to using some external patch system like dpatch? I would file a bug report against dpkg-source if you believe my concerns are justified. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Suggests vs. Recommends
Hello > > 'packagesearch' is a package which uses a plugin architecture. Each > > plugin provides a way to search for packages, e.g. doing a full text > > search, searching by filenames or orphaned packages. All plugins are > > shipped together with the main application in a single > > package. However, most of the plugins require some additional packages > > to work (e.g. apt-file or deborphan). If the packages are not > > available, the plugin will detect that, inform the user how he could > > install the package and disable itself. > > I would do this on a case by case basis: recommend some of the > core plugins that do not need additional packages, so that the > framework normally ships with some plugins that work, but even those > can be removed without removing the framework; and suggesting the other > plugins, so people know about them. That sounds like a reasonable policy for plugin packages to me. It's actually what a lot of totally plugin based software does. I will use that approach for packagesearch. I believe the use of virtual packages is not exactly the most popular thing to do. I remember being advised against it once. Also I don't want the overhead of splitting up the package just yet - there is not much gain coming from that. Thanks to all for the suggestions. Best Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Suggests vs. Recommends
Hello, the latest message on debian-devel-announce made me rethink my decision for the dependencies for my package 'packagesearch'. Having read the policy again and again and also through the recent debian-devel thread [1], I am not sure whether to use *Recommends* or *Suggests*. 'packagesearch' is a package which uses a plugin architecture. Each plugin provides a way to search for packages, e.g. doing a full text search, searching by filenames or orphaned packages. All plugins are shipped together with the main application in a single package. However, most of the plugins require some additional packages to work (e.g. apt-file or deborphan). If the packages are not available, the plugin will detect that, inform the user how he could install the package and disable itself. Now the first question is quite general: * a plugin architecture package (which provides merely the framework for additional functionality) without any additional is useless by itself so it requires at least one plugin. According to the policy wording this should qualify for a depend? 'The *Depends* field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.' (for convenience I have appended the description of Depends, Recommends and Suggests at the end of the email) * Each plugin provides a certain amount of functionality (usually one or more features) I am not sure if this qualifies for Suggests or Recommends As for 'packagesearch', even if no additional package is installed, there is always the full text search available - so the package by itself is useful. Thus there is no need to *Depends:* on deborphan or apt-file. Also, I could imagine a 'usual' installation (compare [2#Recommends]) without those packages installed, so this would hint for *Suggests:*. So, is this a case for a *Suggests* (instead of *Recommends* as it is decclared now)? Regards Ben [1] http://lists.debian.org/debian-devel/2007/08/msg00043.html [2] Depends This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase. Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. Suggests This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prompt to install missing software?
> > I have a PyGTK-based program that has an optional dependency on the > > package python-matplotlib. > > > > Is there any way under Debian (and hopefully also Ubuntu) that I can > > trigger gtk-debi or something like that when the user requests to use > > the part of my program that depends on stuff they haven't installed yet? > > What would be the best way of doing that from python, if such a thing > > exists? > > > That seems like too much work. Why not just document the optional > dependencies. Additionally, if the features are that nice to have why > not make the packages which provide the functionality Recommended? According to the policy Recommends "declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations." [1] Which IMO is clearly not the case here. Many users probably won't need that particular feature. Regards Ben [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Creating a source tarball for repackaged source using dpkg-source -b
Hello, the developer reference describes how to do the repackaging of upstream source. Among others the following two points are mentioned for the repackaged .orig.tar.gz: * should use -.orig as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones. * should be gzipped with maximal compression. And it is said, that those points can be met, by using "dpkg-source -b" to construct the repackaged tarball from an unpacked directory. (http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz) How do I invoke dpkg-source to create the .orig.tar.gz file? I have tried specifying the location of the changelog and the control file (using -l and -c) dpkg-source -b -lchangelog -ccontrol unmodified-source-dir but this created a file: umlet_7.1-1.tar.gz with an unchanged top level directory. I've also tried: dpkg-source -sU -b -lchangelog -ccontrol unmodified-source-dir unmodified-source-dir which created (among others) a umlet_7.1.orig.tar.gz but still the top level directory remained unchanged. Help would be appreciated! Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why are the buildds able to find a Build-Dep on their own?
> And isn't it a good idea to declare a build-dep even in this case? > > proftpd would FTBS if libacl1-dev would drop its dependency on libattr1-dev. > > Is there a commonly accepted rule on these particular cases? There is. If the package directly depends on libattr1-dev (this usually means it includes headers from libattr1-dev or links the library) then the build dependency should be specified in proftpd. If the package depends only indirectly on libattr1-dev, i.e. only because libacl1-dev depends on libattr1-dev, the dependency should not be specified. The rule of thumb you gave is the way to go: If proftpd FTBS after libacl1-dev drops the dependency on libattr1-dev, then it should build-depend on libattr1-dev, otherwise it shouldn't. Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dependency on Package where Upstream License Changed to Non-Free
Hello, > > The source of the EPS lib is contained in the UMLet release > > Then it's not an external dependency, you have a fork. A fork that is - > and therefore will remain - GPL. What you may miss out on are updates, > that's all. It was shipped with UMLet only for convenience. But since jibble no longer releases the file under GPL, this seems to be the only place were to get it. > > 2. Ship the EPS library as part of the UMLet package. > > Keep the GPL code already within UMLet, create a new home for it - > say on SourceForge - as a fork. Future upstream releases can be > assessed when the time comes. I am reluctant to take over upstream maintenance of the EPS library. > > 3. Create a new package containing only the EPS library. > > Why? Is any other package likely to use it? What would be gained? I > can't see that is worthwhile paying for the current version to go into > non-free and moving your package to contrib. What I meant here, is taking the source of the EPS library shipped with UMLet and create a package from that one. So basically doing a fork, without providing a new upstream, instead considering the UMLet distribution as upstream. This would lead to having a source package UMLet and the two binary packages libeps and umlet. The library sounds useful for others too, but this is only a theoretical possibility. > > What would you suggest? > Personally, 2. Fork it. Thanks Neil for your input. After considering your arguments and my requirements, I've decided not to create a separate package for the EPS lib. I will consider it to be a part of UMLet. The reason for this is, that if UMLet upstream decides to replace or remove the EPS part (and drops it from their distribution) I won't have a library package without an upstream maintainer left. Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dependency on Package where Upstream License Changed to Non-Free
Hello, I am in the process of packaging UMLet [1] which depends on the external library EPS Graphics2d [2]. Apparantly that libray used to be available under GPL but is now distributed on a commercial basis. The source of the EPS lib is contained in the UMLet release, therefore I guess, that UMLet upstream will fix "their" version of the EPS lib if necessary. I can see three possibles ways to go on: 1. Rip the EPS part out of UMLet (it's used only for the EPS export and removing EPS support is a straightforward task). 2. Ship the EPS library as part of the UMLet package. 3. Create a new package containing only the EPS library. What would you suggest? Thanks Ben [1] http://lists.debian.org/debian-devel/2006/11/msg00351.html [2] http://www.unipeak.com/gethtml.php?_u_r_l_=aHR0cDovL3d3dy5qaWJibGUub3JnOjgwL2Vwc2dyYXBoaWNzLw== -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with really long argument list to dpkg-shlibdeps
Hi, > The package generates around 1000 binary > modules/plugins. Running dpkg-shlibdeps over these files makes for > really weird errors[1], due to the length of the command line passed to > dpkg-shlibdeps (at least that's what I believe). Shortening the line or > passing all files in a for-loop works alright. Have a look at xargs, it is the nice way of doing the for-loop. Regards Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reassigning Bugs
On Tue, 2006-09-26 at 15:20 +0300, George Danchev wrote: > On Monday 25 September 2006 16:19, Benjamin Mesing wrote: > > > clone 12345 -1 > > > reassign -1 apt-file > > > retitle -1 apt-file: known to break packagesearch ... > > > thanks > > > > However, the bugs live seperated from each other after cloning. So this > > seems to be more convenient way of doing option 1 (without the blocking > > thing), right? > > Right. This in fact is one and the same bug, but cloned, showing in > packagesearch and apt-file bug records. When it gets closed it does that for > both packages. If I understand you correctly, this creates only an alias for the existing bug report. Please confirm that you are sure about this, it seems to contradict with what is written in the BTS documentation: clone bugnumber NewID [ new IDs ... ] The clone control command allows you to duplicate a bug report. It is useful in the case where a single report actually indicates that multiple distinct bugs have occurred. "New IDs" are negative numbers, separated by spaces, which may be used in subsequent control commands to refer to the newly duplicated bugs. A new report is generated for each new ID. The line that a new report is created for each new ID seems to indicate that an independent report (and not just an alias is created). Additionally having only an alias, would contradict the goal of splitting multiple disitinct bugs from a single report. Thanks, Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reassigning Bugs
Hello > > Options I have thought about, but found not to be optimal: > > * File a bug report against apt-file, and block the bug against > > packagesearch by the new one - close the bug against > > packagesaerch as soon as the bug in apt-file is closed. This > > option does not reflect reality: I could not specify the version > > of packagesearch this bug is closed in. Besides it requires me > > to notice when the bug in apt-file is closed. > > * File a bug report against apt-file, (force)-merge the bug in > > packagesearch with that one. Again this is not a truthful > > reflection of reality, but might be a way to go. > > > > Any help is appreciated! > > You are probably looking for the 'clone' [1]. > > clone 12345 -1 > reassign -1 apt-file > retitle -1 apt-file: known to break packagesearch ... > thanks However, the bugs live seperated from each other after cloning. So this seems to be more convenient way of doing option 1 (without the blocking thing), right? Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reassigning Bugs
Hello > > Is there a way to leave the bug visible for my package, but reassign it > > to apt-file? > > Reassign it to "packagesearch,apt-file" ? Is this an undocumented feature? From the documentation of the BTS: reassign bugnumber package [ version ] Records that bug #bugnumber is a bug in package. This can be used to set the package if the user forgot the pseudo-header, or to change an earlier assignment. No notifications are sent to anyone (other than the usual information in the processing transcript). If you supply a version, the bug tracking system will note that the bug affects that version of the newly-assigned package. Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reassigning Bugs
Hello, I have a bug which is not a bug in my package (packagesearch). However, reassigning it to the package that causes that bug (apt-file), would leave it no longer visible for my package, and thus probably result in the bug to be posted again. Is there a way to leave the bug visible for my package, but reassign it to apt-file? Options I have thought about, but found not to be optimal: * File a bug report against apt-file, and block the bug against packagesearch by the new one - close the bug against packagesaerch as soon as the bug in apt-file is closed. This option does not reflect reality: I could not specify the version of packagesearch this bug is closed in. Besides it requires me to notice when the bug in apt-file is closed. * File a bug report against apt-file, (force)-merge the bug in packagesearch with that one. Again this is not a truthful reflection of reality, but might be a way to go. Any help is appreciated! Regards, Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Licence issues
> However, that code is unmaintained upstream > and not used in the version i'm compiling. Should I repackage > upstream's tarball to exclude it? Definitely! You could also ask upstream if there is a reason to keep distributing that code, perhaps they will exclude it in the next release. Regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question on a package split
Hello, > > Either way, I don't think that's too much splitting, but you could > > eliminate one library by mergeing the packages for libkmobiletools_at > > and libkmobiletools together. > > Ok, then I will have: > > kmobiletools > libkmobiletools > libkmobiletools-dev > and kmobiletools-plugin-kontact. According to Policy, Chapter 8.1 "the run-time shared library needs to be placed in a package whose name changes whenever the shared object version changes". You might need to do that, though I am not sure if this statement is absolute, since it is written to ensure that two different versions of the library can be installed at the same time, while if there is only one application using it, and the library is not useful for other packages, this might be not neccessary. I'd appreciate comments on this. Best regards Benjamin -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libapt-pkg/python-apt API documentation?
Hello > is there any documentation of the libapt-pkg resp. python-apt API? > AFAICS their API is very much the same. libapt-pkg-doc is, hm... an > interesting, though incomplete description of APT internals and > concepts, but not much help wrt the libapt-pkg API. I have never really found any good documentation on the libapt-pkg API. I used to revert to digging in the apt-get source code. However depending on which programming language you are planning to do something, I could recommand using libapt-front which is a frontend library build to hide the ugly details of libapt-pkg from you. It's documentation is not really good yet either, but IMO it provides a much more consise API. libapt-front is C++ but I believe there are people working on python/perl bindings. Please refer to http://libapt-front.alioth.debian.org/ and [EMAIL PROTECTED] for more information. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: quilt-el
On Sun, 2006-07-02 at 16:28 +0200, Soren Hansen wrote: > On Sun, Jul 02, 2006 at 11:18:39PM +0900, Satoru Takeuchi wrote: > > 1. package stable release version > > 2. package developing version and don't apply any extra patches > > 3. package developing version and apply bug fix patch > > 4. wait for upstream to apply bug fix patch and release stable release > > 5. something else... > > The stable version has many bugs in it, so (1) seems pointless. > > If you go with (3), you will probably get a bug report, possibly with a > patch attached, and you would then proceed to actually do (2). > > If upstream is as dead as you imply (4) will be a looong time in the > future. > > If you have too much time, you can take over or fork upstream and apply > any fixes you want and then package that. If you do not have time for > this, I would go for (2). Soren: I believe you've mixed the numbers saying (2) instead of (3) and vice versa in your whole post. If not I disagree with you. Satoru: So go with (3), and have the fix as a Debian specific patch for now. If upstream is dead and noone is willing to take over you might consider not packaging it at all. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package does not build on ia64 and sparc
Thanks you all for your explanations. To summarize, I will take no action regarding sparc and inform the apt-front developers regarding the failure on ia64. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Package does not build on ia64 and sparc
Hello, > What package is it? It's "packagesearch" > I've got a sparc64 (sun4u) machine that I can try the > build on if you like? That would be helpful, please do so. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package does not build on ia64 and sparc
Hello, my package does not build on ia64 due to what seems to be dependency problems: /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install debhelper libapt-front-dev libqt4-dev qt4-dev-tools docbook-to-man pkg-config libmysqlclient15-dev Reading Package Lists... Building Dependency Tree... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libapt-front-dev: Depends: libtagcoll-dev (< 1.6) but 1.6.3-1 is to be installed E: Broken packages apt-get failed. Package installation failed Full build log here: http://buildd.debian.org/fetch.php?&pkg=packagesearch&ver=2.1&arch=ia64&stamp=1149912912&file=log&as=raw Whom should I contact about this? The maintainer of libtagcoll/libapt-front-dev or the porter team, since it works fine on every other architecture. It also does not build on sparc, where I was unable to determine the reason from the build log: http://buildd.debian.org/fetch.php?&pkg=packagesearch&ver=2.1&arch=sparc&stamp=1149339169&file=log&as=raw Help would be appreciated. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging a release
> But using cvs export also means I'd have to check-in every change I > want to test, doesn't it? Either that, or doing the changes in the export, and manually merging the changes you've done back into your working directory. Best regards, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging a release
> find release/$(deb_dir_name) -type d -name CVS | xargs rm -rf You know about "cvs export"? This would spare you to having to delete the CVS directories. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to 'su' to root from a script using Xdialog?
> Q 2:How to avoid permission problems on $DISPLAY > (root can not start a program on $USER x-window) "sux" does this, though it is somewhat limited. E.g. if you "ssh -X" to the target and run sux there, it won't work. Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a kernel module
> Is the current kernel source available as a binary package? Why do you need a binary package? You can always do "apt-get source linux-image-" - most likely this works for Ubuntu too. Besides there seems to be a binary package for the kernel source in Debian: linux-source- Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depending on non-buggy versions?
> If you require a minimal version, you should have a versioned > (build-)depenancy. (Unless stable already has the required version, > you don't need to support installing your package on older versions > that that.) > > If there was a buggy version that was only in unstable for a short > time, you don't need to do anything special about it other than > requesting binNMUs if needed. > > If the buggy version is still in stable or testing, you should have a > dependancy or conficts to avoid it. Now I know why we call it unstable :-) I also read from your email that this allows dropping a versioned dependency (>= n) once version >= n has entered stable. That makes sense. Let me think this through: Once a buggy package has entered testing but was replaced by a version which fixed the bug, no versioned dependency against it is required in my package, because we care only for a working stable release, a working *current* testing and a working upgrade path. Right? Thanks, Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Depending on non-buggy versions?
Hello, I am wondering if my package should depend/build-depend on a special minimum version of another package, if my package fails to work with earlier buggy versions of the packages I depend on. For example the libqt4 is buggy in version 4.1 which causes my package (packagesearch) to crash. I've worked around the QT bug for now, but would like to drop this workaround at one point. The bug will be fixed in the next upstream release of QT which is 4.1.1. So basically my package depends on: libqt4(<<4.1) || libqt4(>=4.1.1). However because the reason for the crash is a bug in QT and not an incompatability by design, I am not sure if I should state dependencies at all. There are other scenarios which are similar where I have to make this decision. Thanks Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Interest in packaging GNU Shishi and GNU Generic Security Service?
Hello > W: shishi source: native-package-with-dash-version > N: > N: Native packaging should only be used if a piece of software was > N: written specifically to be turned into a Debian package. In this case, > N: the version number should not contain a debian revision part. > N: > N: Native source packages are sometimes created by accident. In most > N: cases the reason is the location of the original source tarball. > N: dpkg-source searches for this in > N: ../package_upstream-version.orig.tar.gz. > N: > > What's causing that? I think you need to put a shishi_upstream-version.orig.tar.gz file into ../ before running the build (this should contain the upstream release of shishi, from which the changes you've made can be deduced). Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
