Re: Packaging a header-only library with frequent breaking changes

Hello, On 2023-01-17 15:04, David Kalnischkies wrote: I would suggest talking to maintainers of similar packages, they can probably give you more practical advice in this matter. I maintain a couple of similar header-only packages. Developers unwilling to provide stable API are a challenge, b

Re: Packaging a header-only library with frequent breaking changes

Hi, On Sun, Jan 15, 2023 at 01:21:59PM +, Matthew Fennell wrote: > I'm looking into whether it is feasible to package EnTT [1], a header-only C++ > library with breaking API changes every few releases / months. As I use it in a private toy-project I can certify that it is breaking API (and AB

Packaging a header-only library with frequent breaking changes

Hi all, I'm looking into whether it is feasible to package EnTT [1], a header-only C++ library with breaking API changes every few releases / months. Would the following approach be sufficient to prevent reverse dependencies from having dependency issues when the library is updated: 1) Create a

RE: Packaging a .NET Core application & pbuilder

Ansgar wrote: > > Still, having to first install some other package from some third-party > repository as proposed here for the systemd-genie package before being > able to use or build software is not very user-friendly and also makes it > harder to find sponsors interested in reviewing and uplo

RE: Packaging a .NET Core application & pbuilder

Andrey Rahmatullin wrote on Thursday, August 20, 2020 3:08 AM: > On Thu, Aug 20, 2020 at 02:15:07AM +, Paul Wise wrote: > > > I'm currently working on packaging a .NET Core utility for contrib > > > > I note that .NET is Free Software these days, so you should be

Re: Packaging a .NET Core application & pbuilder

There's also Mono, which is already in Debian but has some limitations (e.g. C# features newer than version 6 may not be available). https://lists.debian.org/debian-cli/ has been mostly-inactive for years.

Re: Packaging a .NET Core application & pbuilder

On Thu, Aug 20, 2020 at 02:15:07AM +, Paul Wise wrote: > > I'm currently working on packaging a .NET Core utility for contrib > > I note that .NET is Free Software these days, so you should be able to > package both for main instead of using contrib. > > htt

Re: Packaging a .NET Core application & pbuilder

On Thu, 2020-08-20 at 11:40 +0500, Andrey Rahmatullin wrote: > On Thu, Aug 20, 2020 at 12:09:08AM +0200, gregor herrmann wrote: > > libdbd-oracle-perl is such an example; it's in contrib because it's > > free software itself but needs oracle software which is not even in > > Debian. Typically someo

Re: Packaging a .NET Core application & pbuilder

On Thu, Aug 20, 2020 at 12:09:08AM +0200, gregor herrmann wrote: > > > > > Are these acceptable caveats for a source package in contrib, > > > > No, the package still needs to be built without network, using only its > > > > contents and packages from Debian. > > > > You also need to produce a pack

Re: Packaging a .NET Core application & pbuilder

On Wed, Aug 19, 2020 at 11:04 AM Alistair J R Young wrote: > I'm currently working on packaging a .NET Core utility for contrib I note that .NET is Free Software these days, so you should be able to package both for main instead of using contrib. https://en.wikipedia.org/wiki/.NET_Co

Re: Packaging a .NET Core application & pbuilder

On Wed, 19 Aug 2020 22:14:36 +0500, Andrey Rahmatullin wrote: > On Wed, Aug 19, 2020 at 02:31:10PM +, Alistair J R Young wrote: > > > > Are these acceptable caveats for a source package in contrib, > > > No, the package still needs to be built without network, using only its > > > contents and

Re: Packaging a .NET Core application & pbuilder

On Wed, Aug 19, 2020 at 02:31:10PM +, Alistair J R Young wrote: > > > Are these acceptable caveats for a source package in contrib, > > No, the package still needs to be built without network, using only its > > contents and packages from Debian. > > You also need to produce a package that can

RE: Packaging a .NET Core application & pbuilder

Andrey Rahmatullin wrote: > > Are these acceptable caveats for a source package in contrib, > No, the package still needs to be built without network, using only its > contents and packages from Debian. > You also need to produce a package that can be installed with apt and usable > after that, a

Re: Packaging a .NET Core application & pbuilder

Note that you replied to my email in private and I can't reply back as your server blacklisted my IP. -- WBR, wRAR signature.asc Description: PGP signature

Re: Packaging a .NET Core application & pbuilder

On Wed, Aug 19, 2020 at 10:31:43AM +, Alistair J R Young wrote: > I'm currently working on packaging a .NET Core utility for contrib (ITP here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968331; current version of > the package here: https://mentors.debian.net/package

Packaging a .NET Core application & pbuilder

I'm currently working on packaging a .NET Core utility for contrib (ITP here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968331; current version of the package here: https://mentors.debian.net/package/systemd-genie/ for those interested), and am in the stage of dotting Is and crossi

Re: Packaging a gui app

Jones @CaffeinatedEng On 2/26/17, 11:15 AM, "Christian Seiler" wrote: On 02/26/2017 04:52 PM, The Wanderer wrote: > On 2017-02-26 at 10:47, Ghislain Vaillant wrote: > >> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote: >> >>> I am

Re: Packaging a gui app

On 02/26/2017 04:52 PM, The Wanderer wrote: > On 2017-02-26 at 10:47, Ghislain Vaillant wrote: > >> On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote: >> >>> I am packaging a gui that has dependencies for qt and such. How do >>> I go about ensuring that X is

Re: Packaging a gui app

On 2017-02-26 at 10:47, Ghislain Vaillant wrote: > On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote: > >> I am packaging a gui that has dependencies for qt and such. How do >> I go about ensuring that X is available as well? Do I list that as >> a dependency as well.

Re: Packaging a gui app

On Sun, 2017-02-26 at 10:15 -0500, matt jones wrote: > I am packaging a gui that has dependencies for qt and such. How do I go about > ensuring that X is available as well? Do I list that as a dependency as well. > The upstream maintainers don’t call it out specifically but it is u

Re: Packaging a gui app

jones wrote: > > I am packaging a gui that has dependencies for qt and such. How do I > go about ensuring that X is available as well? Do I list that as a > dependency as well. The upstream maintainers don’t call it out > specifically but it is understood. Links to doc

Re: Packaging a gui app

jones wrote: > > I am packaging a gui that has dependencies for qt and such. How do I > go about ensuring that X is available as well? Do I list that as a > dependency as well. The upstream maintainers don’t call it out > specifically but it is understood. Links to doc

Packaging a gui app

I am packaging a gui that has dependencies for qt and such. How do I go about ensuring that X is available as well? Do I list that as a dependency as well. The upstream maintainers don’t call it out specifically but it is understood. Links to docs are always welcome. Thanks! -- Matt

Re: Advices for packaging a daemon of galileo

Hi Ben, Le 6 sept. 2016 1:20 AM, "Ben Finney" a écrit : > > Could you instead have the existing ‘galileo’ package install the > SystemD service, but not activate it? > > That way, anyone who installs ‘galileo’ can choose whether to enable the > service. You could describe how to do that in the ‘R

Re: Advices for packaging a daemon of galileo

Dylan writes: > Some users request the possibility to install galileo as a daemon. I > do not want to run galileo as a daemon for my own use. So, I created a > new binary package "galileo-daemon" which configure galileo as a > daemon. Thank you for working to improve the package. Could you inst

Advices for packaging a daemon of galileo

Hi, Galileo [1] is a python utility to securely synchronize a Fitbit device with the Fitbit web service. Some users request the possibility to install galileo as a daemon. I do not want to run galileo as a daemon for my own use. So, I created a new binary package "galileo-daemon" which configure g

Re: RFC: Packaging a toolchain for CloudABI, a new architecture/runtime

On Fri, Feb 12, 2016 at 01:47:26PM +, Alex Willmer wrote: > >> 3. Are there any comments/questions you'd like to add? > > > > Please create a wiki page for the port if you haven't already. > > I'm not seeking to have a Debian port of CloudABI, but agreed. > > Thank you for the links, I'm read

Re: RFC: Packaging a toolchain for CloudABI, a new architecture/runtime

On Sat, Feb 13, 2016 at 12:47 AM, Alex Willmer wrote: > I'm not seeking to have a Debian port of CloudABI, but agreed. Oh, so you are only looking at packaging a cross-compilation toolchain, woops. Some more appropriate links: https://wiki.debian.org/CrossCompiling https://wiki.de

Re: RFC: Packaging a toolchain for CloudABI, a new architecture/runtime

(resending to the list) On 12 February 2016 at 04:54, Paul Wise wrote: > On Thu, Feb 11, 2016 at 7:57 AM, Alex Willmer wrote: >> 1. Are there specific rules/procedures regarding adding an entry to >> the ostable & tripletable files used by dpkg-architecture? Or is it >> just another patch submiss

Re: RFC: Packaging a toolchain for CloudABI, a new architecture/runtime

On Thu, Feb 11, 2016 at 7:57 AM, Alex Willmer wrote: > 1. Are there specific rules/procedures regarding adding an entry to > the ostable & tripletable files used by dpkg-architecture? Or is it > just another patch submission? Probably just a patch submission, but check the dpkg team wiki pages:

RFC: Packaging a toolchain for CloudABI, a new architecture/runtime

Hi, I'm seeking input on packaging compiler and binutils support for CloudABI in Debian. The necessary upstream versions of clang and binutils are already in Sid, and I have rough patches. However the GNU triplets ({aarch64,x86_64}-unknown-cloudabi) for CloudABI are currently unknown by dpkg-archit

Re: Packaging a Go binary

For the record: I’ll be replying on the thread to pkg-go-maintainers: http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20150601/000276.html On Tue, Jun 2, 2015 at 12:31 AM, Aaron Jacobs wrote: > [+Michael Stapelberg] > > I found this, apparently written by Michael Stapelbe

Re: Packaging a Go binary

On Tue, May 26, 2015 at 02:19:57PM +0800, Paul Wise wrote: > On Tue, May 26, 2015 at 1:01 PM, Aaron Jacobs wrote: > > > Is anybody able to point me to some documentation on packaging Go binaries, > > a > > good example, or even a person who would like to be the maintainer for this? > > I'm not a

Re: Packaging a Go binary

On Tue, May 26, 2015 at 1:01 PM, Aaron Jacobs wrote: > Is anybody able to point me to some documentation on packaging Go binaries, a > good example, or even a person who would like to be the maintainer for this? I'm not aware of any documentation on that but `build-rdeps golang` says that golang-

Packaging a Go binary

Hi debian-mentors, I am attempting to package a program written in Go, so that it can easily be installed by Debian and Ubuntu users: https://github.com/googlecloudplatform/gcsfuse Go programs are generally installed using `go get`, but since this one has an external dependency (fuse) I figu

Issue with packaging a Hunspell dictionary (hunspell-en-med)

Hi, I am packaging a Hunspell dictionary of English medical terms for Debian Med (`hunspell-en-med'). Even though the packaging is complete [0], but somehow it is not working as it should be as I am unable to use the dictionary in OpenOffice: the dictionary is labelled as "Unknown

Re: Packaging a Patched Kernel

I would suggest that you take a look at the existing Linux patch packages in Debian: pabs@chianamo ~ $ aptitude search '(kernel|linux)-patch' p kernel-patch-atopacct - save additional statistical counters for atop in the record p kernel-patch-atopcnt

Re: Packaging a Patched Kernel

I would suggest that you take a look at the existing Linux patch packages in Debian: pabs@chianamo ~ $ aptitude search '(kernel|linux)-patch' p kernel-patch-atopacct - save additional statistical counters for atop in the record p kernel-patch-atopcnt

Packaging a Patched Kernel

Hi, there. I'm not an official Debian maintainer, but I'm building a custom Debian kernel based on the bcache fork by Kent Overstreet (http://bcache.evilpiepirate.org/). I've read through the relevant-seeming part of the Debian Kernel Handbook and I think I have a build process in place. This

Re: Question: Packaging a Program from a Dir that is Not a Deb Package in the least...

On Sun, Nov 11, 2012 at 07:59:12PM -0800, AllowOverride wrote: > Got links? Suggestions? all are welcomed... This[0] PDF is pretty useful to have a general idea of how to begin your package. Debian new maintainers' guide[1] is also a good source of information. Cheers. [0] http://www.debian.org

Re: Question: Packaging a Program from a Dir that is Not a Deb Package in the least...

> Some of the programs are java installed and stem from rpm's or at least > built for redhat/centos systems. > Are you aware you can use alien to convert rpms to debs? It's not ideal, but it has worked for me in the past and it's rather easy to do.. -- To UNSUBSCRIBE, email to debian-mentors-re

Re: Question: Packaging a Program from a Dir that is Not a Deb Package in the least...

On Mon, Nov 12, 2012 at 11:59 AM, AllowOverride wrote: > a. create a .deb from a directory of 3rd party paid software. Which software do you want to package? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "u

Re: Question: Packaging a Program from a Dir that is Not a Deb Package in the least...

I remember seeing a question similar to this on a mailing list, but I can't seem to find it at the moment. However, [1] might be of interest to you. It shows how to package simple binaries without the intent of publishing them into the official Debian archives. It creates a very bare-bone package w

Question: Packaging a Program from a Dir that is Not a Deb Package in the least...

Hello, I am new here. Be gentle. What I would Like to do: a. create a .deb from a directory of 3rd party paid software. b. be able to install the .deb on debian server. I have looked at all the documentation I could stand about howto go about it, seems rather complicated, and I'm sure it is, ho

Re: Packaging a new release of released SW, not considered by the DM?

On Thu, May 31, 2012 at 10:22:21PM +0200, Svante Signell wrote: > Hi, > > A Short question. Is it possible to ITP a new release of some software > not being even considered by the DM, for whatever reason. Wishlist bugs > are submitted, etc. According to if there is no reply of bug reports, > there

Re: Advice on packaging a PHP application (ITP for Shaarli)

Thanks Gregor, Thomas, Arno and Christian for your bits of wisdom. Summary: I'll put - the application files (which do not get modified) in /usr/share/shaarli - the data/ directory in /var/lib/shaarli - the cache/ and tmp/ directories in /var/cache/shaarli I'll use the version name 0.0.32beta. T

Re: Advice on packaging a PHP application (ITP for Shaarli)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Christian, On 06.01.2012 17:47, Christian Welzel wrote: > Another approach would be to make an apache configuration package like > shaarli-apache2. That leaves the choice to the user, and can force > the installation of apache. And its very eas

Re: Advice on packaging a PHP application (ITP for Shaarli)

Am 06.01.2012 11:22, schrieb Arno Töll: >> - Should I handle more than just Apache2 (other webservers)? > > That's up to you. At least, you should not depend on Apache and make > sure it works fine without installing Apache. A dependency like: > > Depends: apache2 | httpd-cgi Another approach w

Re: Advice on packaging a PHP application (ITP for Shaarli)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Emilien, On 06.01.2012 00:13, Emilien Klein wrote: > Those files constitute the application. I am thinking about placing > those in /usr/share/shaarli That's all right. Please note, you must not write anything to this directory though after in

Re: Advice on packaging a PHP application (ITP for Shaarli)

On 01/06/2012 07:13 AM, Emilien Klein wrote: > By default, those directories are created in the same folder as where > the application files are (that would mean under /usr/share/shaarli). > Would /var/lib/shaarli be a better place to locate these folders? Remember that /usr can be a read-only file

Re: Advice on packaging a PHP application (ITP for Shaarli)

On Thu, 05 Jan 2012 21:41:43 -0500, Emilien Klein wrote: > > I'd go with 0.0.32~beta or similar (assuming that there will be a > > 0.0.32 release later) since ~ sorts before everything else. > The upstream author justifies the addition of "beta" to mean "be > aware, no guarantees, this could break

Re: Advice on packaging a PHP application (ITP for Shaarli)

Hi Gregor, 2012/1/5 gregor herrmann : > On Thu, 05 Jan 2012 18:13:44 -0500, Emilien Klein wrote: > >> - The current version number is "0.0.32 beta" (including space) as >> written on the web page and in the source code, and "0.0.32beta" in >> the zipfile. As the version number in Debian can't cont

Re: Advice on packaging a PHP application (ITP for Shaarli)

On Thu, 05 Jan 2012 18:13:44 -0500, Emilien Klein wrote: > - The current version number is "0.0.32 beta" (including space) as > written on the web page and in the source code, and "0.0.32beta" in > the zipfile. As the version number in Debian can't contain spaces, > would you use "0.0.32beta", or

Advice on packaging a PHP application (ITP for Shaarli)

Hi Mentors and Apache Maintainers, I am in the process of packaging Shaarli (a delicious clone written in PHP) for Debian (ITP bug#654814). I would need someone familiar with packaging a [PHP] web application [for Apache] to guide me in the right direction. I have looked at the gallery and

Re: RFS: mdk (adopted, updated the packaging a lot)

On Wed, 09 Mar 2011 22:35:34 +0200, Peter Pentchev wrote: > > Only one remark: I hate uupdate in d/watch, especially when I > > maintain a package in a VCS; but since this is your package and not > > mine I don't mind :) > Oh yeah, I do not quite like it, either :) I think I'll remove it in > the

Re: RFS: mdk (adopted, updated the packaging a lot)

On Wed, Mar 09, 2011 at 09:28:14PM +0100, gregor herrmann wrote: > On Tue, 08 Mar 2011 13:56:52 +0200, Peter Pentchev wrote: > > > > I am looking for a sponsor for the new version 1.2.3-2 > > > of my package "mdk". I am hereby trying to adopt the package and

Re: RFS: mdk (adopted, updated the packaging a lot)

On Tue, 08 Mar 2011 13:56:52 +0200, Peter Pentchev wrote: > > I am looking for a sponsor for the new version 1.2.3-2 > > of my package "mdk". I am hereby trying to adopt the package and > > refresh its packaging a lot; I've left the update to newer upstream

Re: RFS: mdk (adopted, updated the packaging a lot)

On Mon, Feb 21, 2011 at 01:45:17PM +0200, Peter Pentchev wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.2.3-2 > of my package "mdk". I am hereby trying to adopt the package and > refresh its packaging a lot; I've left the update to new

Re: packaging a new qt application with 2 components

On Wed, 2011-02-23 at 07:53 +0100, Lars Buitinck wrote: > 2011/2/22 Steven : [...snip...] > But I'm not sure Debian would benefit much from a -dev package that > only exists to build a single other package. I'll leave it to the > Debian Developers on this list to comment on that, though. > In th

Re: packaging a new qt application with 2 components

2011/2/22 Steven : > Hmm.. Sounds good, I'll have a look at it. So the libfoo-dev (or > foo-dev) would contain the 'kernel' and the dependency only exists when > building if I understand correctly. > > [snip] > > That is definitely not necessary at this time, the 'kernel' would only > be used in co

Re: packaging a new qt application with 2 components

On Tue, 2011-02-22 at 00:23 +0100, Lars Buitinck wrote: > 2011/2/22 Steven : > > Yes, looking in the directory, I see a single .a file, starting with > > 'lib' (also the largest file in there). I guess this means it would be > > easiest to create 2 separate packages, while changing the *.pro file

Re: packaging a new qt application with 2 components

On 2011-02-21, Steven wrote: > What would be the best approach to deal with this? > Note that I'm fairly new at creating Debian packages and developing qt > applications (I do have experience in Java, but not with Debian in > mind). two tarballs is a v3 source format? There is nothing special ab

Re: packaging a new qt application with 2 components

2011/2/22 Steven : > Yes, looking in the directory, I see a single .a file, starting with > 'lib' (also the largest file in there). I guess this means it would be > easiest to create 2 separate packages, while changing the *.pro file for > the gui? If you want to keep them separate, that would be

Re: packaging a new qt application with 2 components

On Mon, 2011-02-21 at 23:18 +0100, Lars Buitinck wrote: > 2011/2/21 Steven : > > The original sources are in a remote SVN repository, the project > > consists of 2 major components, a 'kernel' and a gui. > > These 2 projects compile separately, although the resulting binary of > > the gui componen

Re: packaging a new qt application with 2 components

2011/2/21 Steven : > The original sources are in a remote SVN repository, the project > consists of 2 major components, a 'kernel' and a gui. > These 2 projects compile separately, although the resulting binary of > the gui component is a single file which also contains the binary code > from the '

packaging a new qt application with 2 components

Hi Debian mentors, I picked up an existing qt application which was not packaged before. I do maintenance on the source code and would like to create proper Debian packages. I'm fairly new at creating Debian packages, I read some documentation about packaging and did some testing, which goes fair

RFS: mdk (adopted, updated the packaging a lot)

Dear mentors, I am looking for a sponsor for the new version 1.2.3-2 of my package "mdk". I am hereby trying to adopt the package and refresh its packaging a lot; I've left the update to newer upstream versions for the next uploads. It builds a single binary packages: m

Packaging a WM configured with "config.h" (C header)

Hi All, I'm currently working on packaging Mucsa, a lightweight tiling WM. Like dwm, it can be configured through its header file (config.h), which has to be recompiled each time, but unlike dwm, its settings can also be configured in a .musca_start file (in $HOME by default, does not need recompi

Re: Packaging a library -- looking for documentation

On Sun, Jan 31, 2010 at 6:18 PM, Thomas Weber wrote: > In order to not screw up too badly, I'm looking for documentation on > developing/packaging libraries (both from a developer's view and a > maintainer's view). libpkg-guide is the only public one I know of. dato was writing something but it

Packaging a library -- looking for documentation

Hi, I maintain Octave in Debian. My upstream will switch to using libtool in the next major release (ETA of that release is unknown, but somewhen in 2010). In order to not screw up too badly, I'm looking for documentation on developing/packaging libraries (both from a developer's view and a mai

RE: Packaging a self-hosting assemler from source

in license.txt, my fault. That seems to be fine. Still, there are problems with building it, especially as you probably *have* to build it using a binary of itself, which is not available for all architectures. Asking upstream about build-instructions might be a good idea though. > > Subj

Re: Packaging a self-hosting assemler from source

On Fri, 2009-02-20 at 12:58 +, Peter Marsh wrote: > I'm trying to package FASM (http://www.flatassembler.net/) from > source. It's a self-hosting assembler, and upstream doesn't provide a > makefile. I can't find anything in the docs about how I should > correctly specify a make file and the b

Packaging a self-hosting assemler from source

Hi, I'm trying to package FASM (http://www.flatassembler.net/) from source. It's a self-hosting assembler, and upstream doesn't provide a makefile. I can't find anything in the docs about how I should correctly specify a make file and the build-depends (the package will depend on its self,

Re: Packaging a library

A Dilluns 29 Setembre 2008, Neil Williams va escriure: [...] > > > What matters is now - educating upstream to tweak the libtool > > > versioning *separately* from the version string when the ABI next > > > changes. > > > > Uff. Who am I to try to educate to upstream? :-) I can try to send an > > e

Re: Packaging a library

On Mon, 29 Sep 2008 20:08:24 +0200 Leopold Palomo Avellaneda <[EMAIL PROTECTED]> wrote: > > > Yes, you are right. But I prefer the Debian library packaging guide, it's > > > more clear in this aspect. However I guess than the author uses the > > > version number as the SONAME number and don't know

Re: Packaging a library

A Dilluns 29 Setembre 2008, Neil Williams va escriure: > On Mon, 29 Sep 2008 18:40:47 +0200 > > Leopold Palomo Avellaneda <[EMAIL PROTECTED]> wrote: > > > > Upstream uses autotools, but not in a very correct way, I guess. The > > > > library is 3.5.6 version, but the configure + make creates > > >

Re: Packaging a library

On Mon, 29 Sep 2008 18:40:47 +0200 Leopold Palomo Avellaneda <[EMAIL PROTECTED]> wrote: > > > Upstream uses autotools, but not in a very correct way, I guess. The > > > library is 3.5.6 version, but the configure + make creates > > > libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am,

Re: Packaging a library

A Dilluns 29 Setembre 2008, Neil Williams va escriure: > On Mon, 29 Sep 2008 17:31:55 +0200 > > Leopold Palomo Avellaneda <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm packing a library (not yet an ITP, just learning) and I'm having some > > doubts about it. > > > > Upstream uses autotools, but no

Re: Packaging a library

IANADD Leopold Palomo Avellaneda wrote: > Hi, > > I'm packing a library (not yet an ITP, just learning) and I'm having some > doubts about it. [snip] > Also, my second question is about to create a dbg package. Upstream has > some --enable-debug that is a -DDEBUG. Looking on the source I have s

Re: Packaging a library

On Mon, 29 Sep 2008 17:31:55 +0200 Leopold Palomo Avellaneda <[EMAIL PROTECTED]> wrote: > Hi, > > I'm packing a library (not yet an ITP, just learning) and I'm having some > doubts about it. > > Upstream uses autotools, but not in a very correct way, I guess. The library > is 3.5.6 version, bu

Packaging a library

Hi, I'm packing a library (not yet an ITP, just learning) and I'm having some doubts about it. Upstream uses autotools, but not in a very correct way, I guess. The library is 3.5.6 version, but the configure + make creates libXXX.so.0.0.0. I have looked on the configure.ac, Makefile.am, etc, a

Re: RFC: packaging a daemon for an embedded platform

Hi, José. On Aug 23 2008, José Luis Tallón wrote: > Rogério Brito wrote: > > I intend to package a heartbeat program for an embedded computer > > (actually, a NAS) based on PowerPC, the Kurobox. > > > Yup, your thread on -devel is most detailed. I just included that preamble because I'm not su

Re: RFC: packaging a daemon for an embedded platform

Hi, Rogério Rogério Brito wrote: > Dear mentors (with CC to debian-powerpc), > > I intend to package a heartbeat program for an embedded computer > (actually, a NAS) based on PowerPC, the Kurobox. > Yup, your thread on -devel is most detailed. > The original firmware of the Kurobox is non-free,

RFC: packaging a daemon for an embedded platform

Dear mentors (with CC to debian-powerpc), I intend to package a heartbeat program for an embedded computer (actually, a NAS) based on PowerPC, the Kurobox. The original firmware of the Kurobox is non-free, but there is a free, highly configurable daemon from

Re: Help needed for packaging a library

o.so) must be architecture-dependent and therefore the .pc file needs to be in /usr/lib/ with all the other library .pc files. If this is unclear, maybe you should not be packaging a library in the first place as shared library packages are always more complex than a typical application package

Re: Help needed for packaging a library

Helmut Grohne wrote: > Hi Georgi, > >> Why is my library architecture-dependent? How can I make it >> architecture-independent, assuming the source code doesn't care about the >> architecture (I don't think a printf should be a problem)? > > Your library will be compiled to a binary blob and thi

Re: Help needed for packaging a library

Hi Georgi, > Why is my library architecture-dependent? How can I make it > architecture-independent, assuming the source code doesn't care about the > architecture (I don't think a printf should be a problem)? Your library will be compiled to a binary blob and this binary blob is architecture d

Re: Help needed for packaging a library

> > libnonsense-dev.install > > --- > > usr/include/* > > usr/lib/lib*.a > > usr/lib/lib*.so > > usr/lib/pkgconfig/* > > usr/lib/*.la > > It is IMHO a better idea to drop the libtool .la files. Please excuse my ignorance, but why is it better to drop them? > > usr/share/pkgcon

Re: Help needed for packaging a library

Am Freitag, den 28.03.2008, 00:41 +0100 schrieb Georgi Chulkov: > I'm trying to package a very simple hello world library, before I move to > more > complex things. The problem is that dpkg will not include the most important > files in the finished package. Here's what I did, step by step (on

Re: Help needed for packaging a library

All'incirca Fri, 28 Mar 2008 01:49:54 +0100, Romain Beauxis <[EMAIL PROTECTED]> sembrerebbe aver scritto: > Appart from that, I can only point you to > http://www.debian.org/doc/maint-guide/ > > There, you can find more documentation on the first steps in > packaging stuff.. More documentati

Re: Help needed for packaging a library

Hi ! (..autotools stuff is not really in this list's scope..) Le Friday 28 March 2008 00:41:20 Georgi Chulkov, vous avez écrit : > As you can see, none of the important files are included in the packages. > Why is that? Seems like you have to edit and read debian/rules to see what it actu

Help needed for packaging a library

Hello, I'm trying to package a very simple hello world library, before I move to more complex things. The problem is that dpkg will not include the most important files in the finished package. Here's what I did, step by step (on a Kubuntu 7.10 system): 1. I start with the following source fil

Re: Packaging a non-free software

Le 3 mars 08 à 19:29, Marco Bertorello a écrit : Hi Mentors, I want this software [1] avaible in debian, but is released as binary-only without any license. There are any chance to put my package [2] in debian, non-free archive? Even for non-free you need a clear license statement which

Packaging a non-free software

Hi Mentors, I want this software [1] avaible in debian, but is released as binary-only without any license. There are any chance to put my package [2] in debian, non-free archive? I'm asked upstreams about license, if the source code is avaible, etc... and I'm waiting a reply. Thanks a lot for

Packaging a difficult project

Hi all, I have a software project that I plan on creating Debian packages for which is non-standard in that it uses patched versions of GCC and Doxygen. http://edoc.sourceforge.net/ --- Project Description --- EDoc++ is a compile time C++ exception analysis/documentation tool. EDoc++ is a tool

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

Re: packaging a release

Benjamin Mesing <[EMAIL PROTECTED]> wrote: > > 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. But using cvs export also means I'd have to check-in every change I want to test,

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 del

Re: packaging a release

gregor herrmann <[EMAIL PROTECTED]> wrote: > There are helpers for other version control systems, too: > > $ apt-cache search --names-only .*-buildpackage > arch-buildpackage - tools for maintaining Debian packages using arch > cvs-buildpackage - A set of Debian package scripts for CVS source tree

Re: packaging a release

On Sat, Apr 29, 2006 at 01:27:10PM -0700, Tyler MacDonald wrote: > I'd like to build my debian packages out of my repository, so I've added the > following in my debian/rules... Is there a better, standardized way to do > this? (I've already looked at cvs-buildpackage, but I want to move away from

  1   2   3   >