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 p
ge: 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 patche
> 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 wil
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 cre
> > * 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
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
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. Ho
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'
> > 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
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 dis
> 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
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 jib
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 UMLe
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
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
> >
> &g
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
> > optio
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 #
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 pack
> 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 B
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-plug
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 go
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
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.
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
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...
> 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
> 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 del
> 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
> 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
--
> 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,
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
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: Nat
32 matches
Mail list logo
