't even need to get the old source packages
> removed as dak will automatically remove cruft packages.
>
> https://ftp-master.debian.org/#cruft
Thanks for the explanation!
Best,
Andrius
On Tue, Apr 21, 2020 at 5:29 AM wrote:
> Instead, I would like to build libfreehep-graphicsio-*-java binary
> packages from the single source package, and remove the old source
> packages. However, I am not sure if two source packages producing binary
> packages with th
Hello,
The upstream seems to have merged sources of freehep-graphicsio-* into a
single tarball. Thus to update libfreehep-graphicsio-*-java binary
packages (currently having their separate source packages) I would have
to split the new tarball myself. Splitting is quite some hassle, and
gives
Hi,
I'm thinking to package [1]. This package is in the github and upstream
release it with two main directories: one with the C++ version (complete) and
another with a python binding against the first one.
The Python version cannot be built without the C++ version.
Can I have in alioth a
On Thu, Mar 12, 2015 at 9:48 PM, Leopold Palomo-Avellaneda wrote:
Can I have in alioth a single repo with two debian packages?
How you structure the git repository doesn't have much correlation
with what source/binary packages are produced. Feel free to do as you
want.
If you intend to
El Divendres, 13 de març de 2015, a les 00:08:07, Paul Wise va escriure:
On Thu, Mar 12, 2015 at 9:48 PM, Leopold Palomo-Avellaneda wrote:
Can I have in alioth a single repo with two debian packages?
How you structure the git repository doesn't have much correlation
with what source/binary
Hi,
Le 19/11/2014 19:23, Maxime Chatelle a écrit :
[...]
The package is cakephp. Upstream maintains 3 main branches: 1.3.x, 2.x and
3.x
I plan to use the following naming scheme for branches:
upstream/1.3.x(fast-forward only branch feeded by upstream releases)
debian/1.3.x/master
Hi,
On Tue, 18 Nov 2014, Maxime Chatelle wrote:
Is it a good practice to use the same Alioth packaging repository to
maintain two (and later, three) source packages ? Obviously the three
source package come from the same upstream git repository. The point is
to maintain 2 (or 3) development
Le 19/11/2014 11:21, Raphael Hertzog a écrit :
Hi,
On Tue, 18 Nov 2014, Maxime Chatelle wrote:
Is it a good practice to use the same Alioth packaging repository to
maintain two (and later, three) source packages ? Obviously the three
source package come from the same upstream git repository
On Wed, Nov 19, 2014 at 11:55:20AM +0100, Thibaut Paumard wrote:
Le 19/11/2014 11:21, Raphael Hertzog a écrit :
Hi,
On Tue, 18 Nov 2014, Maxime Chatelle wrote:
Is it a good practice to use the same Alioth packaging repository to
maintain two (and later, three) source packages
Hi,
Is it a good practice to use the same Alioth packaging repository to
maintain two (and later, three) source packages ? Obviously the three
source package come from the same upstream git repository. The point is
to maintain 2 (or 3) development branchs of the same software while
avoiding
Hello Forum,
in order to add some missing sample material, I add a second source to the
upstream source tarball,
then I followed the multiple upstream tarballs in Debian source packages
approach [1].
This approach is currently used for spamassassin [2].
What is the GIT part of this approach
Hi,
On Thu, Nov 13, 2014 at 6:48 PM, Jerome BENOIT g62993...@rezozer.net wrote:
Hello Forum,
in order to add some missing sample material, I add a second source to the
upstream source tarball,
then I followed the multiple upstream tarballs in Debian source packages
approach [1
Arno Töll a...@debian.org writes:
Hi,
hello Arno,
Thanks for the quick response.
On 21.03.2013 21:08, Felix Natter wrote:
Do I have to follow (some of) these steps?
http://wiki.debian.org/Keysigning
yes, the first one is enough though. This is not covered by docs,
because that's a
hi,
I would like to publish a package to d-mentors for sponsorship soon, and
am wondering how to sign the source package for upload. Do I even need
to sign packages as a package maintainer (not DM, not DD)?
intro-maintainers writes this:
How to upload packages to mentors.debian.net?
You
Hi,
On 21.03.2013 21:08, Felix Natter wrote:
Do I have to follow (some of) these steps?
http://wiki.debian.org/Keysigning
yes, the first one is enough though. This is not covered by docs,
because that's a generic OpenGPG problem not specifically related to
Debian (Mentors). You need to
On Fri, Mar 22, 2013 at 6:28 AM, Arno Töll wrote:
yes, the first one is enough though. This is not covered by docs,
because that's a generic OpenGPG problem not specifically related to
Debian (Mentors). You need to create a key satisfying the Debian keyring
maintainers [1]. See any tutorial
come from proprietary code, and others from assets, they
should only be binary packages, not source packages. When trying to
build a .changes file though, dpkg-genchanges -b always complains
about a missing Source field in my control file, even though I though
the -b option meant only binary
Thanks again for everyone's help on this!
For now I'll try generating the changes file by script as we are
building the deb packages through the OpenEmbedded build system and it
handles the actual packaging for us. In the future I'll look at
getting it to build these packages the right way so
On Sun, 05 Dec 2010, Paul Wise wrote:
On Sun, Dec 5, 2010 at 5:03 AM, Raphael Hertzog hert...@debian.org wrote:
Using dpkg -b directly is still not the right way to build a package.
If you don't want to distribute a source package, that's fine don't
distribute it. But a debian binary
, not source packages. When trying to
Using dpkg -b directly is still not the right way to build a package.
If you don't want to distribute a source package, that's fine don't
distribute it. But a debian binary package should always be built from
source package, it's the best way to create a policy
On Sun, Dec 5, 2010 at 5:03 AM, Raphael Hertzog hert...@debian.org wrote:
Using dpkg -b directly is still not the right way to build a package.
If you don't want to distribute a source package, that's fine don't
distribute it. But a debian binary package should always be built from
source
, they
should only be binary packages, not source packages. When trying to
build a .changes file though, dpkg-genchanges -b always complains
about a missing Source field in my control file, even though I though
the -b option meant only binary packages.
Does anyone know how to build a .changes file
be binary packages, not source packages. When trying to
build a .changes file though, dpkg-genchanges -b always complains
about a missing Source field in my control file, even though I though
the -b option meant only binary packages.
Does anyone know how to build a .changes file without having
come from proprietary code, and others from assets, they
should only be binary packages, not source packages. When trying to
build a .changes file though, dpkg-genchanges -b always complains
about a missing Source field in my control file, even though I though
the -b option meant only binary
Le Fri, Dec 03, 2010 at 06:08:42PM -0800, Daniel Lazzari a écrit :
/eme-assets
/eme-assets/DEBIAN
/eme-assets/DEBIAN/control
/eme-assets/DEBIAN/postinst
/eme-assets/DEBIANprerm
/eme-assets/opt
/eme-assets/opt/image.jpg
/eme-assets/opt/libmine.so
I package it up using dpkg -b
Dear Mentors,
My package uses 4 original tarballs, one of the files within these needs
to be patched, however the patch fails. I think this is because it is
not extracting the additional original tarballs in to the temporary
build directory.
This is part of the build log:
dpkg-source:
Hi,
On Wed, Sep 01, 2010 at 01:37:37PM +0100, Chris Baines wrote:
I think it should say something about the other original tarballs there
as well. Is there anything I am missing?
Look at my package foundry for an example on how to use multiple
tarballs.
Simon
--
To UNSUBSCRIBE, email
Thanks, I was using incorrect names for the additional source packages.
Thanks again,
Chris
On Wed, 2010-09-01 at 15:13 +0200, Simon Richter wrote:
Hi,
On Wed, Sep 01, 2010 at 01:37:37PM +0100, Chris Baines wrote:
I think it should say something about the other original tarballs
On 12197 March 1977, Chris Baines wrote:
Those source archives are used to build a toolchain capable of compiling
firmware for the Lego Mindstorms NXT. Its critical both for support
reasons and for practical size issues that I use the exact same method
to compile the device firmware as
the original archives
correctly. I have followed the guidelines in man dpkg-source for using
version three source packages, unpacking the additional archives to the
armtc directory in my source package. This is a list of all the archives
in question.
lejos-nxj_0.8.5.orig.tar.gz
Hi,
On Wed, Aug 04, 2010 at 12:50:28PM +0100, Chris Baines wrote:
binutils_2.18.50.orig-armtc.tar.bz2 additional original archive
gcc_4.3.2.orig-armtc.tar.bz2 additional original archive
newlib_1.16.0.orig-armtc.tar.gz additional original archive
That
Those source archives are used to build a toolchain capable of compiling
firmware for the Lego Mindstorms NXT. Its critical both for support
reasons and for practical size issues that I use the exact same method
to compile the device firmware as upstream. Upstream deliberately uses
specific
Erik Schanze schan...@gmx.de writes:
Hi mentors,
I have a question regarding repacking and hope you could give me some
suggestions.
I'd like to run a special x86 based device with Debian.
I could use most of the common Debian packages, but I have to repack some of
them
for the use on
Hi mentors,
I have a question regarding repacking and hope you could give me some
suggestions.
I'd like to run a special x86 based device with Debian.
I could use most of the common Debian packages, but I have to repack some of
them
for the use on this device. The packages will be provided and
On Tue, Jan 26, 2010 at 09:20:34PM +0100, Erik Schanze wrote:
[...]
I'm a bit lost to find a way which is compatible to Debian archive and
packages that are easy to maintain and to follow Debian versions
(mostly security fixes).
[...]
Have your custom repository use a different distribution
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
Hi.
On May 03 2009, Benjamin Mesing wrote:
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:
(...)
Does the archive accept 3.0 source packages already
2009/5/17 Rogério Brito rbr...@ime.usp.br:
Does the archive accept 3.0 source packages already? If yes, then I
think that I will migrate some of my packages.
No:
http://bugs.debian.org/457345
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ
On May 17 2009, Paul Wise wrote:
No:
http://bugs.debian.org/457345
Thanks.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Benjamin Mesing bensm...@gmx.net writes:
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
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
On Sunday 03 May 2009 08:15:42 Benjamin Mesing wrote:
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
Take a look at
http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native
and the question after that (What's wrong with upstream shipping a debian/
directory?).
Yep, all sound like good reasons to separate the source distfile and the
debian specific data.
Currently
Brendon Costa [EMAIL PROTECTED] writes:
I have those files listed below (Excepting the
package_1.0-1.diff.gz) as there are no differences that need to be
applied for debian. So a source distribution would just include
the .dsc and .tar.gz file.
Even when you are acting in both the upstream
On Sunday 29 July 2007, Ben Finney wrote:
Brendon Costa [EMAIL PROTECTED] writes:
I have those files listed below (Excepting the
package_1.0-1.diff.gz) as there are no differences that need to be
applied for debian. So a source distribution would just include
the .dsc and .tar.gz file.
Hi all,
I have been looking on the web, but have found little in the way of
tutorials on how to create a debian source package. I have created a
binary package for my project (EDoc++: http://edoc.sourceforge.net/),
but want to create a source package and then build the binary one from this.
Does
On Sun, Jul 29, 2007 at 11:13:06AM +1000, Brendon Costa wrote:
I have been looking on the web, but have found little in the way of
tutorials on how to create a debian source package. I have created a
binary package for my project (EDoc++: http://edoc.sourceforge.net/),
but want to create a
Brendon Costa [EMAIL PROTECTED] writes:
I have been looking on the web, but have found little in the way of
tutorials on how to create a debian source package. I have created a
binary package for my project (EDoc++:
http://edoc.sourceforge.net/), but want to create a source package
and then
On Sun, Jul 29, 2007 at 11:13:06AM +1000, Brendon Costa wrote:
I have been looking on the web, but have found little in the way of
tutorials on how to create a debian source package. I have created a
binary package for my project (EDoc++: http://edoc.sourceforge.net/),
but want to create a
Actually, there is no one-file source package form of a deb like there
is for rpms. When you create your binary package, a signed .dsc file is
created with which you can create the deb in conjunction with the
original upstream tarball and the diff of the debian packaging.
Ahh that would
On Sun, Jul 29, 2007 at 02:59:53PM +1000, Brendon Costa wrote:
Actually, there is no one-file source package form of a deb like there
is for rpms. When you create your binary package, a signed .dsc file is
created with which you can create the deb in conjunction with the
original upstream
I should adjust my plans to do the following:
1) produce win32 cross compiling packages of some Debian source packages
2) document this, maybe writing a litte howto.
3) publish these packages in an inofficial a Debian APT repository
Sadly, there isn't any good documentation about cross compiling
On Tue, 2006-03-14 at 00:28 +0100, Volker Grabsch wrote:
The extra work of duplicate security fixes is IMHO very small
compared to the additional infrastructural work of keeping lots
of Debian packages win32 portable, duplicating maintaining work
which is already done by the GnuWin32 project.
On Tue, Mar 14, 2006 at 07:21:56PM +1100, Jamie Jones wrote:
On Tue, 2006-03-14 at 00:28 +0100, Volker Grabsch wrote:
The extra work of duplicate security fixes is IMHO very small
compared to the additional infrastructural work of keeping lots
of Debian packages win32 portable,
Volker Grabsch [EMAIL PROTECTED] wrote:
Which of these ways is the current, modern, best practise way of
handling such exotic source archives?
I don't think that there's a general consensus about that.
The Debian New Maintainers' Guide explicitly says that it doesn't
cover this topic. The
maintainer of these libs to include an
extra binary target will be very hard, and the project as a whole
may fail if only one of them doesn't like it.
Indeed, and this would only be a stopgap solution, but it's better than
duplicating source packages.
3) It's much work for a Debian maintainer
Hi,
Volker Grabsch wrote:
I'm trying to build Debian cross compiled packages of win32 libraries.
As upstream sources I use the (already patched) sources from the
GnuWin32 project. (http://gnuwin32.sourceforge.net/)
IMO what would make more sense is to try to get the patches integrated
into
Dear Debian Mentors,
I'm trying to build Debian cross compiled packages of win32 libraries.
As upstream sources I use the (already patched) sources from the
GnuWin32 project. (http://gnuwin32.sourceforge.net/)
Their source packages are named this way:
libpng-1.2.8-src.zip
and this ZIP
: You want to cross compile. So the Debian cross compiling
should stay as close as possible to the packages one would normally
use with MinGW under Windows.
6) It add in general more work to more persons, than to simply use
the GnuWin32 source packages as upstream source. The GnuWin32
Hi Mentors!
Since I didn't get an answer as d-d, I try it here ... Hope I have more
luck!
- Forwarded message from Norbert Preining [EMAIL PROTECTED] -
From: Norbert Preining [EMAIL PROTECTED]
Subject: bug pages and source packages
To: debian-devel@lists.debian.org
Date: Wed, 8 Feb
On Thu, Feb 09, 2006 at 08:14:59PM +0100, Norbert Preining wrote:
When I go to
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=info
it tells me
... to the source package texinfo's bug page ...
But when I go to
: http://www.kde-apps.org/content/show.php?content=30223
* License : GPL
Description : KDE automatic installer for source packages
Kompile is a KDE interface for automatic execution of
configuration, compilation and installation of source tarballs.
It adds a KDE service menu so
Hi,
Is it possible to ship the same binary packages in two source packages
across two distributions?
A concrete example would be a tools package which can be built from two
major upstream releases that need to be kept in the distribution for
the shared libs:
short term:
- unstable
On Sun, Aug 07, 2005 at 03:41:31PM +0200, Lo?c Minier wrote:
Hi,
Is it possible to ship the same binary packages in two source packages
across two distributions?
This situation can occur, but should be transitional and short. The
archive will let the highest version numbered
to some base
level.
apt-get --only-source build-dep fred
apt-get --only-source -b source fred
should do what you want. This is how the pine source packages in are
built.
Giridhar
--
Y Giridhar Appaji Nag | http://www.appaji.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
and transparently. This
occurs recursively for all dependencies, at least up to some base
level.
apt-get --only-source build-dep fred
apt-get --only-source -b source fred
should do what you want. This is how the pine source packages in are
built.
Aha .. thank you! This looks just right. I'll try
On 08-Jul-2005, John Skaller wrote:
On Thu, 2005-07-07 at 21:27 +0200, Christoph Haas wrote:
You may as well use the http://mentors.debian.net service to
upload your work. It will take care of your files and make them
publicly available in a decent repository structure.
but
(a) it
On Fri, 2005-07-08 at 12:58 +1000, Ben Finney wrote:
On 08-Jul-2005, John Skaller wrote:
On Thu, 2005-07-07 at 21:27 +0200, Christoph Haas wrote:
You may as well use the http://mentors.debian.net service to
upload your work. It will take care of your files and make them
publicly
Hi,
I have 2 source packages in the archive (unstable only) that are
branches of the same tree, but generate different backages.
e.g. source packages A and B which make packages X and Y
respectively.
I has bothered me to have such duplication and finally some work that
upstream did lets me
* Brian Sutherland [EMAIL PROTECTED] [2004-11-03 01:09]:
What is the best way to go about getting rid of package B? My first
instinct is just to upload a new version of A (with new versions of
X and Y) and then file a bug against ftp.debian.org?
But my first instincts are often wrong. So
Hi,
I have 2 source packages in the archive (unstable only) that are
branches of the same tree, but generate different backages.
e.g. source packages A and B which make packages X and Y
respectively.
I has bothered me to have such duplication and finally some work that
upstream did lets me
Author : Joey Hess [EMAIL PROTECTED]
* URL : could not find any, sorry :(
* License : GPL v2
Description : manage Debian source packages
apt-src is a command line interface for downloading, installing, upgrading,
and tracking Debian source packages. It makes source package
Author : Joey Hess [EMAIL PROTECTED]
* URL : could not find any, sorry :(
* License : GPL v2
Description : manage Debian source packages
apt-src is a command line interface for downloading, installing, upgrading,
and tracking Debian source packages. It makes source package
separate source and binary packages. Do the various scripts/people
automatically handle this, or do I have to file some bugs against
ftp.debian.org to remove the old ddrmat-source package first?
You do not need to contact the ftpmasters in advance. Just upload both
source packages as normal
Hi all,
I maintain the pyddr and ddrmat-source packages, which are both
generated from the same pyddr source package. Upstream is going to split
off the ddrmat-related files into a separate tarball since they don't
change much, for the next version.
The obvious way to handle this is to package
I have found what appears to be a bug in a source package (ucd-snmp-4.0.1).
The bug being that /usr/sbin/snmpd does not exist after installing the snmpd
.deb created from the sources with dpkg-buildpackage -rfakeroot -b -us
-uc. It *does* show up when installing a package made from sources with
I'm packaging some Perl modules and a program which is a bunch of Perl
scripts. Everything in these packages is Perl code (and documentation).
Do I need to make source packages for these? How would I go about doing
that?
--
Matthew Sachs
[EMAIL PROTECTED]
-- random fortune quote --
But like
Le Sun, Jun 27, 1999 at 04:52:47PM -0400, Matthew Sachs écrivait:
I'm packaging some Perl modules and a program which is a bunch of Perl
scripts. Everything in these packages is Perl code (and documentation).
Do I need to make source packages for these? How would I go about doing
On Sun, Jun 27, 1999 at 04:52:47PM -0400, Matthew Sachs wrote:
Do I need to make source packages for these?
Of course. Even if the binaries are identical to the sources, you need some
scripting (ie. debian/rules etc) to produce the .debs, and that requires a
source package.
How would I go
Currently I build a binary package A from source package X; now I want
to build binary packages A and B from source package Y (which contains
the contents of package X), without changing the functionality in
binary package A. Is it ok to leave package X alone or do I have to
orphan it?
Thanks,
81 matches
Mail list logo
