Re: Quilt and patches directory
On Sun, Sep 14, 2008 at 04:00:18PM +0200, Andreas Schildbach wrote: > Is there any way to tell quilt about the debian package structure? The > way it works, it always looks in the current directory for the patches > and .pc directories. > > What I'd like it to do is find the debian directory in the parent > hierarchy and put/search for its patches directories there. I've found http://chistera.yi.org/~adeodato/blog/104_quilt_options useful. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploads to experimental instead of unstable
Am Donnerstag, den 11.12.2008, 13:09 + schrieb Neil Williams: > On Thu, 11 Dec 2008 12:43:03 +0100 > "Sandro Tosi" <[EMAIL PROTECTED]> wrote: > It would make things easier to release Lenny if all (or very > nearly all) activities in unstable that were unrelated to the release > *were* actually stopped. Then the release process is buggy. If we need to freeze both testing and unstable, what's the virtue of testing in the first place? > Lenny is my priority and it saddens me that > other maintainers and DD's don't seem to feel the same way. No, the current release process means: don't do anything for > 6 months and then rush to just catch up with upstream. It means keeping bugs around that are fixed upstream. It means users asking on upstream's list about bugs we ship in unstable that upstream fixed months ago. > experimental - why is that such a bad thing? "Warning: This package is from the experimental distribution. That means it is likely unstable or buggy, and it may even cause data loss." > Why do people react so badly to a recommendation to upload to experimental? > It's just a name, > a label. No, it isn't. At a minimum, I will need to build and upload that package again into unstable later. Experimental packages are autobuilt on a best-effort basis, which may or may not cover all architectures. And experimental has far less users, due to its (well) experimental nature. > It doesn't have to mean that the package is experimental, it > simply means that it isn't suitable for what is currently happening in > unstable (which, in case anyone is still in doubt, is the final > preparations for the Lenny release). That's the part where opinions differ. Testing was created for what currently unstable is used for. We should freeze testing and freeze unstable instead. > Everyone has to take account of > transitions and blocks in unstable between releases, the release freeze > itself is just another issue to consider with regard to unstable. > Unstable isn't 100% available every single day between freezes, there > are constant issues that mean that uploads need to be delayed or put > into experimental. That's why we have experimental. http://www.debian.org/doc/developers-reference/resources "The experimental distribution is a special distribution. It is not a full distribution in the same sense as stable, testing and unstable are. Instead, it is meant to be a temporary staging area for highly experimental software where there's a good chance that the software could break your system, or software that's just too unstable even for the unstable distribution (but there is a reason to package it nevertheless). Users who download and install packages from experimental are expected to have been duly warned. In short, all bets are off for the experimental distribution." Sorry, but your description doesn't match at all with both devref and the warning about experimental packages. Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
two different packages with the same source tarball/name
Hi, is it possible to have two different binary packages with the same source package name (but different upstream versions of the source)? Reason: I'm about to package octave-forge for both Octave 2.1 and 2.9 (you can consider octave-forge as plugin, that needs to be compiled for the respective version). Now, upstream provides only one tarball for *one* version; that is, the latest upstream tarball is meant for Octave 2.9, while previous versions were meant for Octave 2.1. I would therefore like to keep the old version for Octave 2.1 (with a source name of octave-forge), while packaging the latest version for Octave 2.9 (as well with a source name of octave-forge, but a different upstream version). Thanks Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder outside & inside chroot hook scripts
Hi, > Workaround: use a simple D hook script [1] to access via http method of apt > needed build depends which are stored in manually prepared apt repo (well, on > the same machine). Have a look at pbuilder's OTHERMIRROR option (for http and ftp repositories). > Improvement?: I think the wishlist described in #316547 has its merits, since > one should be able to feed self-healing pbuilder image with needed > build-depends at least. The external (outside chroot hook script will be used > to re-index[2] the apt repo which in fact could be pbuilder's result/ > directory with previuosly built packages stored in there and copy that > directory inside the chroot image one could access via file: method of apt. > Or other way round, copy packages inside chroot and re-index that apt repo. > > What do you think and am I missing something pretyty obvious here ? I think what you want is described in pbuilder's manual: http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#id267346 Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with really long argument list to dpkg-shlibdeps
Hi, [no need to CC me, I'm subscribed]. I'm trying to package Octaviz and I'm running into problems with dpkg-shlibdeps. The package generates around 1000 binary modules/plugins. Running dpkg-shlibdeps over these files makes for really weird errors[1], due to the length of the command line passed to dpkg-shlibdeps (at least that's what I believe). Shortening the line or passing all files in a for-loop works alright. Is there some best practice solution for this? [1] http://www.num.uni-sb.de/~weber/debian/temp/octaviz_0.4.5-1_i386.build.gz (124kb) Beware, the extracted file has 5 MB. Look for line 17394, which is about 90k lines long. Thanks Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prompt to install missing software?
Hi, Am Sonntag, 27. Mai 2007 06:17 schrieb John Pye: > Is there any way under Debian (and hopefully also Ubuntu) that I can > trigger gtk-debi or something like that when the user requests to use > the part of my program that depends on stuff they haven't installed yet? > What would be the best way of doing that from python, if such a thing > exists? Frankly, the very first thing that comes to my mind about such a software: "Stupid program, shut up and don't get in my way". If this feature is useful, use Recommends, period. You should also consider that a user may not have sysadmin rights and must go ask someone for this additional installation. If you are that person, how much would you like being pestered several times a day about such things? Additionally, what if I don't have a network connection at that moment? Then this turns from "how nice, it asks me about additional stuff" to "great, I installed the package with all recommeded packages and still can't do what I want to do". Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: QtOctave -- A Qt front-end to Octave
Hi Jordi, Am Montag, 18. Juni 2007 04:38 schrieb Jordi Gutierrez Hermoso: > The Debianised source tarball is found here: > > http://www.cimat.mx/~jordi/debian/qtoctave_0.5.1-1.debian.tar.gz There's something wrong with the tarball. According to the .dsc file: 04dd905a3bb001516045fc06eff46085 2855 qtoctave_0.5.1-1.diff.gz here: $ md5sum *diff* a855b539cf5cee5a0dfe42e55c9bddcc qtoctave_0.5.1-1.diff.gz Indeed, the diff file is a gzipped tarball, containing the .dsc and the original tarball. You might want to join the Debian Octave Group. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 maintainer's view). I know about the "Debian Library Packaging Guide", but #493951 indicates that there should be something 'better' (for whatever definition of better). In case it matters, upstream uses C++ and Fortran. Thanks Thomsa -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
How to maintain a large symbols file of a C++ library
Hi, I'm in the process of converting Debian's Octave packages into a structure with proper library packaging. The symbols file of these three C++ libraries has about 30k lines. I'm pretty new to symbols handling, so I'm looking for advice on how to handle this. Is there a simple way to reduce the pure size of this file? Or is this size normal? Further, looking at dpkg-gensymbols(1), it seems I should take special care about some C++-features - can you point me to an example of how to do this? Thanks Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007231800.GA27343@t61
Re: How to maintain a large symbols file of a C++ library
On Tue, Nov 08, 2011 at 12:21:16PM +0100, roucaries bastien wrote: > On Tue, Nov 8, 2011 at 12:18 AM, Thomas Weber wrote: > > Hi, > > > > I'm in the process of converting Debian's Octave packages into a > > structure with proper library packaging. The symbols file of these three > > C++ libraries has about 30k lines. > > > > I'm pretty new to symbols handling, so I'm looking for advice on > > how to handle this. Is there a simple way to reduce the pure size of > > this file? Or is this size normal? > > > > Further, looking at dpkg-gensymbols(1), it seems I should take > > special care about some C++-features - can you point me to an example of > > how to do this? > > > > Thanks > > Thomas > > Try to use hidden linking before doing this. Ask upstream hel, if needed. Do you mean GCC's -fvisibility=hidden? If yes, I'm at a loss at how to do this in a sensible way - if the symbols were exported before, changing this in Debian might break other software that actually uses these symbols. > BTW do you need help on arpack ? Opps, thanks for pointing me at this. I had totally forgotten about arpack being bundled. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008224756.GA1123@t61
Re: How to maintain a large symbols file of a C++ library
On Wed, Nov 16, 2011 at 10:32:22AM +0100, bastien ROUCARIES wrote: > Le Tuesday 8 November 2011 23:47:56, Thomas Weber a écrit : > > On Tue, Nov 08, 2011 at 12:21:16PM +0100, roucaries bastien wrote: > > > On Tue, Nov 8, 2011 at 12:18 AM, Thomas Weber wrote: > > > > Hi, > > > > > > > > I'm in the process of converting Debian's Octave packages into a > > > > structure with proper library packaging. The symbols file of these > > > > three C++ libraries has about 30k lines. > > > > > > > > I'm pretty new to symbols handling, so I'm looking for advice on > > > > how to handle this. Is there a simple way to reduce the pure size of > > > > this file? Or is this size normal? > > > > > > > > Further, looking at dpkg-gensymbols(1), it seems I should take > > > > special care about some C++-features - can you point me to an example > > > > of how to do this? > > > > > > > > Thanks > > > >Thomas > > > > > > Try to use hidden linking before doing this. Ask upstream hel, if needed. > > > > Do you mean GCC's -fvisibility=hidden? If yes, I'm at a loss at how to > > do this in a sensible way - if the symbols were exported before, > > changing this in Debian might break other software that actually uses > > these symbols. > > Yes but because you will upload a new major version you will break. So try to > convince upstream to do this. Hmm, okay. I'm not going to do this in the 3.4 series, though. We are already far behind with the 3.4 packaging as is. > > > BTW do you need help on arpack ? > > > > Opps, thanks for pointing me at this. I had totally forgotten about > > arpack being bundled. > > Do you need help ? Do you need a new upstream ? If you can get a patch for the 3.4.3 tarball, that uses the packaged arpack instead of the included one, that would obviously be helpful. Bonus points if it's in such a way that the Fedora guys can use it as well :) https://bugzilla.redhat.com/show_bug.cgi?id=676858 Thanks Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021222748.GA3559@t61
Overwriting binary files when building a package
Hi, my upstream ships documentation in PDF format in the normal sources. Upon build, I re-create those files[1]. The newly generated PDF files differ from the originally shipped ones. So, I have a problem asserting that "debian/rules clean" gives me the same source tree as "dpkg-source -x" which seems to ask for trouble, see http://www.mail-archive.com/debian-ocaml-maint@lists.debian.org/msg22803.html In fact, we already see some issues when using git-buildpackage right now (currently, I remove the PDF files via dh_clean). Is there a way around the "make a backup copy of the original PDF files and copy it back upon executing 'debian/rules clean'"? And if not, is there some generic code floating around for doing this (I envision something like dh_backup ;))? [1] Part of the documenation for building the PDF is copied from the source files, so a normal patch to the source code triggers a rebuild of the documentation - so it's not like I can easily avoid the rebuild of the PDF files. Thanks Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111211205024.GA22098@t61
Re: Overwriting binary files when building a package
On Mon, Dec 12, 2011 at 12:25:08PM +0100, Bernhard R. Link wrote: > * Thomas Weber [111211 22:08]: > > my upstream ships documentation in PDF format in the normal sources. > > Upon build, I re-create those files[1]. The newly generated PDF files > > differ from the originally shipped ones. So, I have a problem asserting > > that "debian/rules clean" gives me the same source tree as "dpkg-source > > -x" which seems to ask for trouble > > To get dpkg-source happy is easy: Just remove the files in > "debian/rules clean". dpkg-source will then assert those files do not > need representation in the .diff (or in a patch). It will print a little > notice which files were treated that way and otherwise just behave the > way you want it. > > > In fact, we already see some issues when using git-buildpackage right > > now. > > git-buildpackage might be some other issue. As this seems to be the only > think to give you troubles here, Well, git-buildpackage is one thing. The problem is really that "debian/rules clean" doesn't give the same as "dpkg-source -x". As far as I understand Stefano in http://www.mail-archive.com/debian-ocaml-maint@lists.debian.org/msg22803.html, I have no guarantee that a buildd will actually run the "clean" target before building the package. Thanks Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212211224.GA23924@t61
Symbols and C++ inline constructor
Hi,
I have a question about an inline constructor and debian/symbols.
The code looks like this:
class X {
public:
X() { some code };
}
According to http://gcc.gnu.org/onlinedocs/gcc/Inline.html, this means
that the constructor is inlined.
So, can I mark such a constructor as optional in debian/symbols?
Thanks
Thomas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120105224626.GA6628@atlan
Re: Symbols and C++ inline constructor
On Fri, Jan 06, 2012 at 12:14:11AM +, Roger Leigh wrote:
> On Thu, Jan 05, 2012 at 11:46:26PM +0100, Thomas Weber wrote:
> > Hi,
> > I have a question about an inline constructor and debian/symbols.
> > The code looks like this:
> >
> > class X {
> >
> > public:
> > X() { some code };
> > }
> >
> > According to http://gcc.gnu.org/onlinedocs/gcc/Inline.html, this means
> > that the constructor is inlined.
>
> Good question.
Thanks :)
> IIRC inline is only a hint--it's not guaranteed to
> be inlined if the compiler thinks it's more efficient not to.
That is exactly my problem. A newer compiler version might change the
decision of the former version due to better optimization; but then I
see no way to guarantee stable symbols in the library.
> From the symbols POV, what really matters is the content of the ELF
> symbol table. If it's present then include it, otherwise don't.
It's present on some architectures, but not on others. I would like to
keep the symbols files for the different architectures as much as
possible in sync, that's why I'm asking.
Thanks
Thomas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120106223349.GA8251@atlan
Re: Symbols and C++ inline constructor
On Fri, Jan 06, 2012 at 05:14:32PM -0800, Russ Allbery wrote: > Thomas Weber writes: > > On Fri, Jan 06, 2012 at 12:14:11AM +, Roger Leigh wrote: > > >> IIRC inline is only a hint--it's not guaranteed to > >> be inlined if the compiler thinks it's more efficient not to. > > > That is exactly my problem. A newer compiler version might change the > > decision of the former version due to better optimization; but then I > > see no way to guarantee stable symbols in the library. > > If it's a private symbol not intended to be used by clients and that > wouldn't naturally be used by clients, you can mark it optional in the > symbols file (symbol tag optional), and then the symbols generation won't > care if it appears and disappears. This doesn't answer my question, does it? I mean, your statement is true for whatever symbol that appears in the symbol file. My question is about inlined class methods specifically and the fact that the compiler might change its opinion about them with even minor version bumps. > You have to do that for some things with C++, since there are places where > C++ just doesn't give you control over what symbols are exported. One of the things that I find frustrating is the total lack of reliable and complete documentation about symbols; yet library maintainers are expected to keep the symbols file sane. Example from dpkg-gensymbols (5): "For example, most of C++ template instantiations fall into this category" (it's talking about optional symbols here). So, which template instantiations are *not* safe to be tagged as optional? This is a different question, but I have quite some template instantiations in the symbol file as well. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120107184649.GA8333@atlan
Finding the correct alignment for all architectures
Hi, I am maintaining lcms2. In #749975, I received a patch to ensure correct alignment for doubles von MIPS. I have forwarded the patch upstream[1], but in the latest release, upstream has chosen a different way. It is now possible to configure the alignment via a preprocessor variable CMS_PTR_ALIGNMENT[2]: // Alignment to memory pointer // (Ultra)SPARC with gcc requires ptr alignment of 8 bytes // even though sizeof(void *) is only four: for greatest flexibility // allow the build to specify ptr alignment. #ifndef CMS_PTR_ALIGNMENT # define CMS_PTR_ALIGNMENT sizeof(void *) #endif #define _cmsALIGNMEM(x) (((x)+(CMS_PTR_ALIGNMENT - 1)) & ~(CMS_PTR_ALIGNMENT - 1)) I would like to drop the Debian-specific patch. But what value for CMS_PTR_ALIGNMENT would be good/sufficient on all arches? [1] https://github.com/mm2/Little-CMS/issues/32 [2] https://github.com/mm2/Little-CMS/blob/master/src/lcms2_internal.h Thanks Thomas
Re: Re: Finding the correct alignment for all architectures
Thanks guys, I went with _Alignof(double), which interestingly aligns to 8 bytes on amd64. Thomas
