Hmm, wait a moment.
I see you are currently using a bunch of "dh_install -p"
calls in your execute_before_dh_install target.
Maybe the next logical step would be to use debian/*.install
files.
Thanks.
El 14/12/23 a las 14:31, PICCA Frederic-Emmanuel escribió:
Hi. Have you tried splitting override_dh_auto_install into
override_dh_auto_install-arch
and override_dh_auto_install-indep?
no effect at all..., it is especially difficult to deal with the
nopython, nodoc, nocheck profiles if
El 14/12/23 a las 11:07, PICCA Frederic-Emmanuel escribió:
So my question is why dh_missing does not understand that the remaining are not
installed because they are part of arch packages (bornagain and
python3-bornagain) ?
Hi. Have you tried splitting override_dh_auto_install into
Hi.
A similar bug which was fixed in a similar way:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052859#40
See what Aurelien Jarno (glibc maintainer) said:
I have seen that in the meantime you have done a new upload with the
en_US.UTF-8 locale, that's a perfectly valid workaround.
Hi. I see that the previous change was also requested by you
(and uploaded by someone else) due to its interaction with Texinfo.
If you feel attachment to an orphaned package, you can also adopt it.
Thanks.
El 6/11/23 a las 23:42, Hilmar Preuße escribió:
TeXinfo 7.1 does not migrate to testing b/c the test suite of autoproject returns
with exit code > 0. I've filed a bug report and created a patch for the issue.
The package is maintained by the Debian QA group. What else can be done from my
El 30/10/23 a las 18:42, Andrey Rakhmatullin escribió:
What's the recommended way to convert ones created earlier? Recreate?
Install usrmerge?
In this case I'd recommend recreating the chroots, if only because
after this change in debootstrap the chroot will be cleaner:
El 30/10/23 a las 17:21, Markus Blatt escribió:
W: See /var/cache/pbuilder/base.cow/debootstrap/debootstrap.log for details
(possibly the package /var/cache/apt/archives/usr-is-merged_38_all.deb is at
fault)
Try
DEBOOTSTRAPOPTS="--merged-usr"
in your ~/.pbuilderrc
In trixie and sid, all
El 27/12/22 a las 13:12, Ole Streicher escribió:
Santiago Vila writes:
If you don't have deb-src lines, they are the same as the usual deb lines
except that they begin with deb-src.
Just curious: why are the deb line not used by default here?
There is a question during install about deb
El 27/12/22 a las 12:28, Barry Scott escribió:
How do I go from a installed package and find its debian source?
On a Debian/Ubuntu system, if you have deb-src lines in your
/etc/apt/sources.list,
then
apt-get source source-package-name
will retrieve the source and unpack it automatically.
El 26/12/22 a las 16:28, Barry Scott escribió:
E: bemacs source: malformed-debian-changelog-version 8.9.3 (for non-native)
[debian/changelog:1]
It seems that the changelog issue is around lintian mandating a issue to close?
I have no issue what do I put in the changelog? Or do I have to
Hello Geert.
El 15/12/22 a las 23:12, Geert Stappers escribió:
Which paramaters to provide to sbuild
to get the .orig.tar.xz included?
I think you need both --source and --force-orig-source.
(Maybe you were trying only one at a time?)
btw: There is a bug about this problem (need to
On Mon, Nov 12, 2018 at 01:26:11PM +0100, JOSE LUIS BLANCO CLARACO wrote:
> And my question is: is it "acceptable" to run `update-alternatives`
> during debian/rules? [...]
I don't think so. Would that work at all if you are using fakeroot?
On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote:
> my package "saods9" has currently a RC release in experimental that is
> named
>
> 7.5~rc+repack-1
>
> Now, upstream released a second RC which I want to upload as well:
>
> 7.5~rc2+repack-1
>
> However, it turns out that this
On Wed, May 11, 2016 at 10:31:46AM +, Gianfranco Costamagna wrote:
> You need to make the package migrate into stretch if you want the autoremoval
> to stop
> https://buildd.debian.org/status/package.php?p=singular=unstable
> armhf is not build anymore, so you can choose from:
> 1) fixing
On Sat, Nov 28, 2015 at 03:00:47PM +0100, Werner Detter wrote:
> short question by example: quilt series contains several patches, e.g.
>
> 1.patch
> 2.patch
> 3.patch
> 4.patch
>
> let's assume 3.patch which worked for some time but will be no longer
> functional
> because the 3.patch uses a
On Tue, Oct 20, 2015 at 11:05:11PM -0200, Giovani Ferreira wrote:
> I'll update the unhide package and I need help.
> The package has a serious bug #769345, which is about statically-linked
> glibc. According to the bug and Debian policy 7.8 is required the
> Built-Using field in d/control.
> How
Hello.
I'm looking at some of the reasons packages do not build reproducibly,
and one of them is different locale settings.
Let's say that I want to ensure that some UTF-8 locale is available
during the build. It seems my options are the following:
* Add a "Build-Depends: locales-all"
The
On Sun, Oct 04, 2015 at 06:24:36PM +0200, Jakub Wilk wrote:
> just use C.UTF-8. [...]
Great! This is the kind of thing I was looking for.
Thanks a lot!
On Mon, Sep 21, 2015 at 02:06:36PM +0200, Thomas Schmitt wrote:
> "multiarch-support is inserted into Pre-Depends via ${misc:Pre-Depends}
>by dh_makeshlibs. In order to be able to remove the multiarch-supporti
>package from glibc without updating every package,
>Pre-Depends:
On Fri, May 22, 2015 at 01:25:39PM +0800, Paul Wise wrote:
On Fri, May 22, 2015 at 5:34 AM, Santiago Vila wrote:
i.e. tell apt-get to ignore recommends.
In this case a metapackage using recommends does not seem very useful,
I guess.
apt-get --install-recommends --install-suggests
On Thu, May 21, 2015 at 02:30:58PM +, lumin wrote:
I'm trying to package caffe as said [1] at debian-science@ .
However I encountered a problem when writing debian/rules.
I'd like to take over the whole build process, so I wrote:
32 override_dh_auto_build: build_cpuonly
On Wed, May 20, 2015 at 10:34:05PM +0200, Andreas Tille wrote:
On Wed, May 13, 2015 at 03:29:47PM +0200, humbert.olivie...@free.fr wrote:
I guess that they should be either Recommends, or Suggests, but not
Depends, right? (So that one can deinstall a single package without
deleting
On Sun, Nov 30, 2014 at 05:31:00PM +0100, Jerome BENOIT wrote:
On 30/11/14 16:30, Vincent Bernat wrote:
In the past, having a `debian/` directory upstream was a pain because we
didn't have a proper way to remove a file if needed. Nowadays, it is
perfectly fine if you use a 3.0 format.
On Fri, Oct 03, 2014 at 07:08:06PM +0200, Felix Natter wrote:
hi,
upstream Freeplane wants to replace the release zips/.tar.gzs because
they contain a freeplane-1.3.12_pre06/ instead of a freeplane-1.3.12/
directory. The software will be re-compiled (md5 changes), but There
will be
On Mon, 29 Jan 2007, Laurent Bigonville wrote:
Hi,
My package (pam-keyring) FTBFS on some buildd[1] because 'kill' is
missing. /bin/kill is part of the procps package which has a required
priority. I thought that packages with such priority should not be
added to build-deps...
It's not
On Fri, 19 Jan 2007, Justin Pryzby wrote:
You will have to test with both sarge and etch dpkg (until after etch
releases). Colin Watson recently wrote [0] about one of the ssh bugs
and how this was complicated for him.
You have to include the logic in the preinst, since the prerm is for
On Fri, 19 Jan 2007, Marc Haber wrote:
Hi,
I have a package with a bunch of configuration files that are managed
by my maintainer scripts and not by dpkg. I now need one of them
(a.conf) to vanish.
How do I do this in a clean way? I am thinking about the following:
(1) Let the new
On Sun, 22 May 2005, Daniel Leidert wrote:
A short question: I have a package, where I run autopoint during build
process. Now the situation is, that gettext only suggests, but not
depends on cvs. So without adding cvs to 'Build-Depends:', the build
fails in a chrooted environment (pbuilder).
On Tue, 17 May 2005, Ben Finney wrote:
I'd like to submit patches for a couple of packages that currently use
hand-rolled debian/rules files. Is the current best practise to use
debhelper, or cdbs, or something else?
The current best practise is to not assume that everybody wants to use
On Tue, 17 May 2005, Ben Finney wrote:
I'm surprised that people have consistently read submit patches as
somehow bypassing the maintainer, or telling him what to do. To whom
would I be submitting the patches, if not the maintainer?
To the maintainer, via the BTS as a wishlist bug. That's
On Sun, 1 May 2005, John Hedges wrote:
I've incorporated a patch[1] into splay and would be very grateful if
someone would check over the new package[2] and, if all is well, do the
upload thing for me.
John
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306983
Hmm, I would not use
On Fri, 29 Apr 2005, H. S. Teoh wrote:
Hi, I have a question about how to handle the upgrade of one of my
packages to a new upstream package.
I am currently the maintainer of the package 'smurf', which is now no
longer maintained upstream. For various reasons, upstream has moved to
a new
On Tue, 8 Mar 2005, Christian Hammers wrote:
I'm building a private(!) package with files in /usr/local/bin for a host
where /usr/local/ is a symlink. Whenever I remove the package the symlink
gets removed by dpkg although there are plenty of (non-Debian maintained)
files in /usr/local.
On Sat, 15 Jan 2005, Kevin B. McCarty wrote:
Santiago Vila wrote:
This way, apt-get upgrade will install libvips-doc without requiring
apt-get dist-upgrade, and this will be done automatically and
without user intervention,
Are you certain of that? My understanding is that apt-get
On Fri, 14 Jan 2005, Jay Berkenbilt wrote:
The recent thread on names of library packages on debian-devel made me
decide that I made a mistake in naming one of my packages.
Specifically, the vips7.10 source package creates four binary
packages: libvips7.10, libvips7.10-dev, libvips7.10-tools,
On Wed, 3 Nov 2004, Zach Garner wrote:
1. The sheer number of helper scripts, with layers and layers of
scripts built on top of each other is really confusing.
Try
apt-get source hello
for an example package with less layers.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
On Wed, 3 Nov 2004, Zach Garner wrote:
1. The sheer number of helper scripts, with layers and layers of
scripts built on top of each other is really confusing.
Try
apt-get source hello
for an example package with less layers.
On Fri, 29 Oct 2004 [EMAIL PROTECTED] wrote:
How to use variables in postinst scripts?
Currently, I use a variable for the upstream version with these lines in
debian/rules:
[...]
# Get the upstream version from the changelog.
upstream := $(shell head -1
On Fri, 29 Oct 2004 [EMAIL PROTECTED] wrote:
How to use variables in postinst scripts?
Currently, I use a variable for the upstream version with these lines in
debian/rules:
[...]
# Get the upstream version from the changelog.
upstream := $(shell head -1
On Thu, 28 Oct 2004, David Everly wrote:
Is there some mechanism or alternative for using uupdate so that any
upstream debian directory can be removed before patching?
Don't know about uupdate, but you are allowed to repackage the .orig.tar.gz
to exclude the upstream debian directory if it
On Thu, 28 Oct 2004, David Everly wrote:
Is there some mechanism or alternative for using uupdate so that any
upstream debian directory can be removed before patching?
Don't know about uupdate, but you are allowed to repackage the .orig.tar.gz
to exclude the upstream debian directory if it
On Sat, 16 Oct 2004, Magnus Therning wrote:
Is one deprecated in favour of the other, or is it simply another place
where Debian offers more options than any other distribution?
Yes, you can consider debmake deprecated.
I have the intention to kill debmake some day. Until then, I'll
On Sat, 16 Oct 2004, Magnus Therning wrote:
Is one deprecated in favour of the other, or is it simply another place
where Debian offers more options than any other distribution?
Yes, you can consider debmake deprecated.
I have the intention to kill debmake some day. Until then, I'll
On Wed, 21 Jul 2004, MiguelGea wrote:
Dear Mentors,
I am looking for a sponsor form the package fpdf-1.52
* Package name : fpdf-1.52
* Version : 1.52
* License : Freeware, It allows modify it and use without
restriction and without cost.
Freeware is not a license. I doubt such
On Fri, 23 Jul 2004, MiguelGea wrote:
Before packaging fpdf I talked with the author about this, and he told
me to read FAQ#1:
1. What's exactly the license of FPDF? Are there any usage restrictions?
FPDF is Freeware (it is stated at the beginning of the source file).
Freeware is not a free
On Fri, 23 Jul 2004, Laszlo 'GCS' Boszormenyi wrote:
* Santiago Vila [EMAIL PROTECTED] [2004-07-21 01:45:58 +0200]:
There is a python policy that you should probably read.
Thanks. I have checked at http://www.debian.org/devel/ , but I could
not find that there. But after searching around
On Wed, 21 Jul 2004, MiguelGea wrote:
Dear Mentors,
I am looking for a sponsor form the package fpdf-1.52
* Package name : fpdf-1.52
* Version : 1.52
* License : Freeware, It allows modify it and use without
restriction and without cost.
Freeware is not a license. I doubt such
On Fri, 23 Jul 2004, MiguelGea wrote:
Before packaging fpdf I talked with the author about this, and he told
me to read FAQ#1:
1. What's exactly the license of FPDF? Are there any usage restrictions?
FPDF is Freeware (it is stated at the beginning of the source file).
Freeware is not a free
On Fri, 23 Jul 2004, Laszlo 'GCS' Boszormenyi wrote:
* Santiago Vila [EMAIL PROTECTED] [2004-07-21 01:45:58 +0200]:
There is a python policy that you should probably read.
Thanks. I have checked at http://www.debian.org/devel/ , but I could
not find that there. But after searching around
On Tue, 20 Jul 2004, Laszlo 'GCS' Boszormenyi wrote:
I would like to ask advice with Python. I have a package, which depends
on it, and previously I depended on an exact version (2.3) thus altered
the interpreter in each file to be python2.3 instead of generic python.
It worked, but upstream
On Tue, 20 Jul 2004, Laszlo 'GCS' Boszormenyi wrote:
I would like to ask advice with Python. I have a package, which depends
on it, and previously I depended on an exact version (2.3) thus altered
the interpreter in each file to be python2.3 instead of generic python.
It worked, but upstream
On Tue, 13 Jul 2004, Milan Zamazal wrote:
My package contains binaries using a common shared library, which is not
intended to be used by other programs. This is a regular shared
library, not a plugin or other object to be explicitly loaded by the
binaries, the binaries just normally link to
On Tue, 13 Jul 2004, Milan Zamazal wrote:
My package contains binaries using a common shared library, which is not
intended to be used by other programs. This is a regular shared
library, not a plugin or other object to be explicitly loaded by the
binaries, the binaries just normally link to
On Thu, 24 Jun 2004 [EMAIL PROTECTED] wrote:
I am packaging source which builds two binary packages; however, each
package has different build dependancies. In fact, the packages' build
dependancies conflict.
I don't think the dpkg tools have the facility to build one binary but
not the
On Thu, 24 Jun 2004 [EMAIL PROTECTED] wrote:
I am packaging source which builds two binary packages; however, each
package has different build dependancies. In fact, the packages' build
dependancies conflict.
I don't think the dpkg tools have the facility to build one binary but
not the
On Fri, 30 Jan 2004, Andreas Metzler wrote:
On Fri, Jan 30, 2004 at 02:15:18PM +0100, Robert Lemmen wrote:
i am looking for a sponsor for secure-delete, it's a small package that
quite some people might find usefull. from the control file:
Description: tools to wipe files, free disk
On Tue, 30 Dec 2003, Jay Berkenbilt wrote:
As far as I can tell, a Debian package consists of a single source
tarball and a single diff. Is this right, or have I missed something?
It's right, a Debian source package is usually distributed as a single
source and a single diff (sometimes there
On Fri, 3 Oct 2003, Peter S Galbraith wrote:
Peter S Galbraith [EMAIL PROTECTED] wrote:
Santiago Vila [EMAIL PROTECTED] wrote:
There is not a standard to make a package to disappear, but there is
something you can do to ensure that apt-get upgrade works: Just make
emacs-goodies
On Fri, 3 Oct 2003, Peter S Galbraith wrote:
Peter S Galbraith [EMAIL PROTECTED] wrote:
Santiago Vila [EMAIL PROTECTED] wrote:
There is not a standard to make a package to disappear, but there is
something you can do to ensure that apt-get upgrade works: Just make
emacs-goodies
On Fri, 3 Oct 2003, Peter S Galbraith wrote:
In the upcoming version of the `emacs-goodies-el' source package, I want
the following to happen to these bianry packages:
`emacs-goodies-extra-el'
- removed and contents merged into `emacs-goodies-el'
`debbugs-el'
- replaced by
On Fri, 3 Oct 2003, Peter S Galbraith wrote:
In the upcoming version of the `emacs-goodies-el' source package, I want
the following to happen to these bianry packages:
`emacs-goodies-extra-el'
- removed and contents merged into `emacs-goodies-el'
`debbugs-el'
- replaced by
On Tue, 9 Sep 2003, Andreas Barth wrote:
* Ismael Valladolid Torres ([EMAIL PROTECTED]) [030909 12:58]:
Is it in some way mandatory using sid as the developing and
packaging environment?
I usually have stable installed, and even have built some simple
packages against stable
On Tue, 9 Sep 2003, Ismael Valladolid Torres wrote:
El martes, 9 de septiembre de 2003, a las 14:27, Andreas Barth escribe:
With a sid build environment you're always on the safe side.
What about, having the choice of building against both the stable and
the unstable version of a library,
On Tue, 9 Sep 2003, Ismael Valladolid Torres wrote:
El martes, 9 de septiembre de 2003, a las 14:27, Andreas Barth escribe:
With a sid build environment you're always on the safe side.
What about, having the choice of building against both the stable and
the unstable version of a library,
On Sun, 7 Sep 2003, Andreas Metzler wrote:
This leads to the question stated in the subject: Is it an error in
the package if it does not build correctly with umask 0007?
If it is an error, is there a straightforward way to fix it, i.e. some
magic setting in debian/rules? (/I/ did not find
On Sun, 7 Sep 2003, Andreas Metzler wrote:
This leads to the question stated in the subject: Is it an error in
the package if it does not build correctly with umask 0007?
If it is an error, is there a straightforward way to fix it, i.e. some
magic setting in debian/rules? (/I/ did not find
On Wed, 27 Aug 2003, Robert Lemmen wrote:
one of my packages (trickle) had a problem and used to create stupid
directories (/usr/share/man1 etc) (see #207258). this is due to a typo
in debian/rules (shame on me)
i fixed this in a new version, but i don't know how to handle the
existing
On Wed, 27 Aug 2003, Robert Lemmen wrote:
one of my packages (trickle) had a problem and used to create stupid
directories (/usr/share/man1 etc) (see #207258). this is due to a typo
in debian/rules (shame on me)
i fixed this in a new version, but i don't know how to handle the
existing
Joe Nahmias wrote:
quick question: Where is the proper place to report spam in the BTS (bug
#137152, to be specific)? [EMAIL PROTECTED] ? file a bug?
[EMAIL PROTECTED] They are usually very quick at removing the junk.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Joe Nahmias wrote:
quick question: Where is the proper place to report spam in the BTS (bug
#137152, to be specific)? [EMAIL PROTECTED] ? file a bug?
[EMAIL PROTECTED] They are usually very quick at removing the junk.
On Sat, 18 Jan 2003, martin f krafft wrote:
Can you please shine some light on section 2.2 of the Policy?
I understand required and important, but the phrasing of optional and
extra are a little cumbersome. I think my packages may not all have
the right priorities and before I go and fix
On Sat, 18 Jan 2003, martin f krafft wrote:
Can you please shine some light on section 2.2 of the Policy?
I understand required and important, but the phrasing of optional and
extra are a little cumbersome. I think my packages may not all have
the right priorities and before I go and fix
On Sun, 20 Oct 2002, Santiago Vila wrote:
Steve Langasek wrote:
These are both dependency lines, not build-depends. You should *never*
build-depend on libc6, as it is an essential package; [...]
Minor nitpick: libc6 is not essential, only essential-de-facto, since
most essential packages
On Fri, 20 Sep 2002, Holger Kubiak wrote:
I want to build a package on my computer for several other hosts at work.
I use unstable but on some other hosts there is stable. My problem is:
Building packages with debhelper causes a dependency (expanded from
shlibs:Depends) of the package libc6
On Fri, 20 Sep 2002, Holger Kubiak wrote:
I want to build a package on my computer for several other hosts at work.
I use unstable but on some other hosts there is stable. My problem is:
Building packages with debhelper causes a dependency (expanded from
shlibs:Depends) of the package libc6
On Sun, 28 Jul 2002, Jamie Wilkinson wrote:
I intend to rename the glut packages from
glutg3
glutg3-dev
to
libglut3
libglut-dev
to follow the convention for library package naming.
So in the control file, I've specified that libglut3 Conflicts and Replaces
glutg3 for versions =
On Sun, 28 Jul 2002, Oohara Yuuma wrote:
On Sun, 28 Jul 2002 13:04:07 +1000,
Jamie Wilkinson [EMAIL PROTECTED] wrote:
I intend to rename the glut packages from
glutg3
glutg3-dev
to
libglut3
libglut-dev
to follow the convention for library package naming.
I prefer libglut3-dev
Colin Watson wrote:
On Sun, Jul 28, 2002 at 04:34:54PM +0200, Santiago Vila wrote:
We should make versioned -dev (binary) packages the exception, not
the norm. libglut-dev is better. Think about libglut3-dev,
libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades
much easier
On Sun, 28 Jul 2002, Jamie Wilkinson wrote:
I intend to rename the glut packages from
glutg3
glutg3-dev
to
libglut3
libglut-dev
to follow the convention for library package naming.
So in the control file, I've specified that libglut3 Conflicts and Replaces
glutg3 for versions =
Colin Watson wrote:
On Sun, Jul 28, 2002 at 04:34:54PM +0200, Santiago Vila wrote:
We should make versioned -dev (binary) packages the exception, not
the norm. libglut-dev is better. Think about libglut3-dev,
libglut4-dev, libglut5-dev etc. and how libglut-dev makes upgrades
much easier
Oohara Yuuma wrote:
dpkg compresses the diff file differently every time
I build .deb . The uncompressed .diff is same.
Is this an expected behavior?
Yes. This is because gzip stores the time stamp (as well as the name)
of the original file inside the compressed one.
[ Normally, you don't
Oohara Yuuma wrote:
dpkg compresses the diff file differently every time
I build .deb . The uncompressed .diff is same.
Is this an expected behavior?
Yes. This is because gzip stores the time stamp (as well as the name)
of the original file inside the compressed one.
[ Normally, you don't
Amaya wrote:
I just translated the .po files for one of my packages (gnomekiss) and I
am having trouble getting the i18n stuff installed.
Please, bear with me, as this is my first attepmt to get in terms with
gettext, .po, gtranslator and the rest of the crew :-)
First I have seen that
Amaya wrote:
I just translated the .po files for one of my packages (gnomekiss) and I
am having trouble getting the i18n stuff installed.
Please, bear with me, as this is my first attepmt to get in terms with
gettext, .po, gtranslator and the rest of the crew :-)
First I have seen that alll
Eric Van Buggenhaut wrote:
This is what my debian/rules looks like:
binary-arch: install-stamp
dh_testdir
dh_testroot
dh_installdirs
dh_movefiles
dh_installdocs
dh_installinfo
dh_installmenu
dh_installpam
Eric Van Buggenhaut:
Depends: , libpam-modules (= 0.72-1), adduser, xutils | xbase-clients, gdm-cleaner
Are you sure you run dpkg-shlibdeps (or debhelper equivalent) on the
ELF binaries in debian/rules?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Eric Van Buggenhaut:
Depends: , libpam-modules (= 0.72-1), adduser, xutils | xbase-clients,
gdm-cleaner
Are you sure you run dpkg-shlibdeps (or debhelper equivalent) on the
ELF binaries in debian/rules?
On Mon, 26 Nov 2001, Eric Van Buggenhaut wrote:
I just adopted a package which is nothing but a Perl script. Previous
maitainer built it using
Architecture: any
when it had to be
Architecture: all
(correct me if I'm wrong)
Now that I'm uploading a new version of package
On Mon, 26 Nov 2001, Eric Van Buggenhaut wrote:
I just adopted a package which is nothing but a Perl script. Previous
maitainer built it using
Architecture: any
when it had to be
Architecture: all
(correct me if I'm wrong)
Now that I'm uploading a new version of package
Amaya wrote:
I am trying to reopen a bug, tag it and merge it with a more recent one.
This is the answer I get from the BTS:
Debian Bug Tracking System said:
Processing commands for [EMAIL PROTECTED]:
reopen 109629
Bug number 109629 not found.
tags 109629 upstream
Bug number 109629
On Mon, 8 Oct 2001, peter karlsson wrote:
While sifting through the policy upgrade checklist for one of my
packages, I came to the information about changing mail access from
/var/spool/mail to /var/mail. That's not hard. Also, the
upgrade-checklist states that I should [...] include a
On Mon, 8 Oct 2001, peter karlsson wrote:
While sifting through the policy upgrade checklist for one of my
packages, I came to the information about changing mail access from
/var/spool/mail to /var/mail. That's not hard. Also, the
upgrade-checklist states that I should [...] include a
peter karlsson wrote:
Santiago Vila:
I would first create the Debian source and binary packages for upload,
and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN
I said:
peter karlsson wrote:
so I don't want dpkg-buildpackage to overwrite it.
Why does dpkg-buildpackage overwrite it? [...]
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by
peter karlsson:
Santiago Vila:
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
peter karlsson wrote:
Santiago Vila:
I would first create the Debian source and binary packages for upload,
and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN
I said:
peter karlsson wrote:
so I don't want dpkg-buildpackage to overwrite it.
Why does dpkg-buildpackage overwrite it? [...]
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by
peter karlsson:
Santiago Vila:
Oops! I understand. My suggestion is that you arrange things so that
dpkg-buildpackage creates the one and only source tarball, instead of
creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
peter karlsson wrote:
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I distribute elsewhere.
I would first create
1 - 100 of 169 matches
Mail list logo
