Conflict with kernel versions?
I'm interested in doing a package for spey, my greylisting SMTP proxy (http://spey.sf.net). This isn't going to happen immediately, but I'm due to make another upstream release soon, and if that goes well I want to start work on the package. Unfortunately, the application has its own coroutine library that turns out to have a nasty conflict with linuxthreads (due to allocating its own stacks, which causes linuxthreads to crash). linuxthreads is used as part of glibc on 2.4 kernels. 2.6 kernels, such as the one I did the development on, are fine. Is it possible to specify this as part of the package dependencies, and if so how, or am I just going to have to document the fact that it'll crash on startup on a 2.4 system? Is this, in fact, not appropriate for inclusion in Debian because of this? (And if anyone wants to suggest a real fix, please get in touch. The *only* reason I'm asking about this is because I can't find any way of working around the problem.) -- +- David Given --McQ-+ "I never really understood how there could be | [EMAIL PROTECTED]| things that would drive you insane just because you | ([EMAIL PROTECTED]) | knew them until I ran into Windows." --- Peter da +- www.cowlark.com --+ Silva pgpOREA8UGZ53.pgp Description: PGP signature
Re: Conflict with kernel versions?
On Thursday 10 November 2005 14:16, Kevin B. McCarty wrote: [...] > To answer your first question: you cannot conflict against (or depend > upon) specific kernel versions because there is no guarantee that an > installed kernel package is the kernel that's running at the moment. Yes, of course. Actually, thinking about this a little more clearly, the *real* problem is that the coroutine library doesn't work with pthreads. Given that I'm not using pthreads, that ought not to matter; unfortunately, spey links with libsqlite3, which *is* built to use pthreads. The 2.4 vs 2.6 thing is a bit of a red herring --- the problem still exists on 2.6, but just happens to work. So if a non-threadsafe version of libsqlite3 could be built, there's a good chance that it would Just Work on all kernel versions. Given that there is no such thing in Debian, what's the appropriate solution? Include my own copy of the library (which I don't want to do)? Petition the sqlite maintainers to build a non-threaded version as part of the stock libsqlite3 package? -- +- David Given --McQ-+ | [EMAIL PROTECTED]| Become immortal or die! | ([EMAIL PROTECTED]) | +- www.cowlark.com --+ pgpKk5h9K6hAv.pgp Description: PGP signature
Replacing aclocal.m4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm current packaging ufiformat, a USB floppy disk formatter (#436134). It's nearly at the stage of looking for a sponsor, but before that happens I'd like to sound people out about something. I needed to change Makefile.am to tell it to install the binary in the right place. When rebuilding, autotools whinged about aclocal.m4 being too old and that I should regenerate it, which I did. Now the (compressed) patch file is 80+kB, only slightly smaller than the source code itself, and is almost entirely comprised of the new aclocal.m4. Is this acceptable, or does it need addressing? If so, how? - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtwNGf9E0noFvlzgRAu99AKCRHqkVYtfguTxFA/cA7M6YSc5POwCg1j1U ojQL6IEKWjPEZcOrB5IC5CM= =6wuJ -END PGP SIGNATURE-
Re: Replacing aclocal.m4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] > Otherwise you can depend on autotools-dev and run them at build time, > and remove the generated files at clean time to get a small diff. This approach works fine; I'm now running aclocal, automake and autoconf at build time (adding automake to the build-deps list). The diff is now 3kB, a sizeable improvement over 80kB. Ta. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtz2Of9E0noFvlzgRAnzQAJ9U+n7tiHMlgvVmd+cIlHkr/ZjGAQCfcmdI PCM6i1NNDcY9SpvybG4RraI= =wlqU -END PGP SIGNATURE-
Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The package I'm putting together has no man page and the author is Japanese, which means I have to write one; as a courtesy, I'd like to put the kanji-form of his name in the AUTHORS section as well as the romanji. Unfortunately, it would appear that using kanji characters in a man page is non-trivial as the encoding for English man pages seems to default to ISO-8859-1. I've scoured the documentation but can't find anything on how to set a specific encoding for a man page --- can anyone point me at instructions on how to do this? Note that this is *not* a ja localised man page. It's a plain English man page with some Japanese characters in it. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGvDXTf9E0noFvlzgRAtX9AKDMoj2OAhlFTgVnqVm+FKtv1ENREQCfWR5L Qtb9gXUPvQGebnY9JzQqpI0= =BKRc -END PGP SIGNATURE-
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery wrote: [...] > The last time I checked, this didn't work for man pages. If it does now > and we can just install man pages in UTF-8, that's great, but a quick test > seems to indicate it still doesn't work even if you run groff -T utf8 in a > UTF-8 locale. What, then, should I be doing? Is it legitimate to include UTF-8 in my man page and assume that it'll be fixed (some day)? This seems... un-Debian-like. Is there an alternative way of representing Unicode in troff that might work better? Of course, a perfectly viable solution is to simply not put non-ASCII characters in my man page, but this seems kinda cheating. Particularly since I went out of my way to ask the author how to spell his name in kanji... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGvJ+Kf9E0noFvlzgRAlBjAKCD6S4/96p4hzGfnDyT2Qffvi8gKwCg3oiF +RAcxvC+ipkXMBMNJU+vjPE= =SuFC -END PGP SIGNATURE-
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Finney wrote: [...] > That sounds like a bug. I was under the impression that the default > encoding of everything in lenny was supposed to be UTF-8. > > What tool is it that has this different default encoding? Well, I tried UTF-8 with the assumption that it would work, and it threw up a lintian warning and produced gibberish when viewing the man page (with default 'man'). After searching the 'net I found this list in the LFS: http://www.linuxfromscratch.org/lfs/view/6.2/chapter06/man-db.html (See 6.45.2.) - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGvDzIf9E0noFvlzgRAqOcAKCG+ZBr4vYwkgfyFLVQunScVMSw2ACgmvOQ Wd0jdHFubCI7sXdnkkiR7ZQ= =KNki -END PGP SIGNATURE-
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Plessy wrote: >[...] > You can refer to the following post of Noridata Kobayashi on this list: > http://lists.debian.org/debian-mentors/2007/03/msg00378.html > > Apparently, the encoding of the manpages is hardcoded, so you have no > other choice than using the default encoding for english... Not really what I wanted to hear, but at least the definitive answer makes my life easier... oh, well. Given that that was the last issue that needed addressing, expect a RFS RSN. Ta. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGveDEf9E0noFvlzgRAnM3AKDTiBzMCA1zPsxoQLghRFVHhu+EQQCfWmQX yBNJ694Wg5I3riegvxi+fGU= =Y1fM -END PGP SIGNATURE-
RFS: ufiformat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package "ufiformat". * Package name: ufiformat Version : 0.9.3-1 Upstream Author : Kazuhiro Hayashi / 林和宏 * URL : http://www.geocities.jp/tedi_world/format_usbfdd_e.html * License : GPL v2 Section : base It builds these binary packages: ufiformat - disk formatter for USB floppy drives The package appears to be lintian clean. (And linda and pbuilder clean.) The upload would fix these bugs: 436134 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/u/ufiformat - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/u/ufiformat/ufiformat_0.9.3-1.dsc I would be glad if someone uploaded this package for me. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGvetqf9E0noFvlzgRAl2KAJ9aCQo5nD86Q2bJuZLIkoUku0u1NgCgyt8O a6RYAdypFboMwGotzcySf38= =WfqQ -END PGP SIGNATURE-
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery wrote: [...] > What I was trying to get at earlier is that I believe groff can't handle > UTF-8 input. So fixing B, if I'm correct, is certainly not local to > man-db. I believe that fixing groff to handle multibyte character sets > property is a substantial amount of work. I've heard rumors from time to > time that upstream intended to do this for 2.0, but the work is mostly > stalled. The standard encoding for Japanese man pages is EUC-JP, which is multibyte; and poking around in my man directories, there are some man pages there which are correctly declared as UTF-8. (Take a look at /usr/share/man/it.UTF-8, for example.) So it's obviously possible. Whether there aren't any other horrible gotchas I couldn't say. Incidentally, all I originally wanted to do was just be able to spell upstream's name correctly, so I can live without it for the time being; but it would be nice to get this fixed. (BTW, I don't suppose anyone would be interested in sponsoring the package in question? ufiformat, a USB external drive floppy formatter, something which Debian doesn't appear able to do otherwise...) - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwD+vf9E0noFvlzgRAmMMAJ9hE6/p37rEXMqQc2XedFnyQkwoewCfZkZE AWQiNIjjfGVfOocrEPRR+5w= =4+29 -END PGP SIGNATURE-
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Finney wrote: [...] >> The standard encoding for Japanese man pages is EUC-JP > > That's no more true than "the standard encoding for English text is > ASCII". The world is moving to Unicode encodings, though legacy > encodings will remain for some time. > > They're also both equally irrelevant. The standard encoding for Debian > GNU/Linux is UTF-8. man-db says otherwise --- if you're in a Japanese locale it looks up man pages in /usr/share/man/ja and assumes they're in EUC-JP format. > A previous message in this thread asserted that groff is capable of > generating UTF-8 output; but has trouble consuming UTF-8 input. Again, man-db says otherwise. In fact, man-db says that while there's a default table of hard-coded encodings, this may be overridden by an explicit encoding in the directory name. e.g.: /usr/share/man/ru.KOI8-R /usr/share/man/ru.UTF-8 (I missed that comment last time.) Does this mean that if I install my UTF-8 encoded man page into /usr/share/en.UTF-8, it'll all work? What happens if someone tries to read the man page on a non-English locale? I know that if a locale-specific man page isn't found it'll fall back to the C locale (i.e. /usr/share/man/manX), but can it be set to also fall back explicitly to English? - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwHDvf9E0noFvlzgRAjjuAJ0WWBwgg/1BJFHEcOkeUiLmWdQ2lgCfVSaa Mf37sGztIml9GsBr4tc66rY= =Ot16 -END PGP SIGNATURE-
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Russ Allbery wrote:
[...]
> Okay, your analysis matches what I thought was going on. However, David
> Given seems to be seeing something else where some man pages are already
> encoded in UTF-8. So I guess I'm confused as to what's going on and what
> the current status is.
I've only got a handful of them. Here's one:
vim-common: /usr/share/man/it.UTF-8/man1/rvim.1.gz
That's vim-common 1:7.0-122+1etch2.
Here's the relevant comment from the source of man-db:
/* Due to historical limitations in groff (which may be removed in the
* future), there is no mechanism for a man page to specify its own
* encoding. This means that each national language directory needs to carry
* with it information about its encoding, and each groff device needs to
* have a default encoding associated with it. Out of the box, groff
* formally allows only ISO-8859-1 on input; however, patches originating
* with Debian and imported by many other GNU/Linux distributions change
* this somewhat.
*
* Eventually, groff will support proper Unicode input, and much of this
* horror can go away.
*
* Do *not* confuse source encoding with groff encoding. The encoding
* specified in this table is the encoding in which the source man pages in
* each language directory are expected to be written. The groff encoding is
* determined by the selected groff device and sometimes also by the user's
* locale.
*
* The standard output encoding is the encoding assumed for cat pages for
* each language directory. It must *not* be used to discover the actual
* output encoding displayed to the user; that is determined by the locale.
* TODO: it would be useful to be able to change the standard output
* encoding in the configuration file.
*
* This table is expected to change over time, particularly as man pages
* begin to move towards UTF-8. Feel free to patch this for your
* distribution; send me updates for languages I've missed.
*
* Explicit encodings in the directory name (e.g. de_DE.UTF-8) override this
* table.
*/
(man-db-2.4.3/src/encodings.c)
> If our groff really can handle UTF-8 input and is doing so for some
> locales, I'd love to declare all regular man pages are in UTF-8 and be
> done with it; that's a change that we can probably make without backward
> compatibility issues right now, since currently those code points are
> disallowed.
Wll... unfortunately man-db uses ISO-8859-1 for C and POSIX locales, so
transcoding would be required.
Further investigation reveals that man-db seems to transcode UTF-8 to
ISO-8859-1 before passing it to groff. man-db has three tables. This one tells
it what encoding to use for each locale:
{ "C", "ISO-8859-1", "ANSI_X3.4-1968"}, /* English */
{ "POSIX", "ISO-8859-1", "ANSI_X3.4-1968"}, /* English */
#ifdef MULTIBYTE_GROFF
/* These languages require a patched version of groff with the
* ascii8 and nippon devices.
*/
{ "ja", "EUC-JP", "EUC-JP"}, /* Japanese */
{ "ko", "EUC-KR", "EUC-KR"}, /* Korean */
...
The two columns seem to be: encoding man page is written in, encoding to use
when saving in cat page. This one tells it what output device to use:
{ "ANSI_X3.4-1968", "ascii" },
{ "ISO-8859-1", "latin1"},
{ "ISO-8859-15","latin1"},
{ "UTF-8", "utf8" },
#ifdef MULTIBYTE_GROFF
{ "EUC-JP", "nippon"},
#endif /* MULTIBYTE_GROFF */
And this one tells it what encoding to pass in to each groff device:
{ "ascii", "ISO-8859-1", "ANSI_X3.4-1968"},
{ "latin1", "ISO-8859-1", "ISO-8859-1"},
{ "utf8", "ISO-8859-1", "UTF-8" },
#ifdef MULTIBYTE_GROFF
{ "ascii8", NULL, NULL},
{ "nippon", "EUC-JP", "EUC-JP"},
(Columns are: encoding to pass into groff, encoding passed out of groff.)
Note that if utf8 is selected as the output device, which appears to happen if
the source encoding is UTF-8, the groff source encoding is specified as
ISO-8859-1 and a transcode happens.
It's all a bit of a maze, unfortunately, and I could have misunderstood
things. But that MULTIBYTE_GROFF #define looks interesting. It *might* be
possible to crudely hack it to work by using the nippon device and the EUC-JP
encoding for man pages writ
Re: Man pages and UTF-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Borowski wrote: [...] > Due to Red Hat and probably other dists using UTF-8 already, plenty of man > pages are in UTF-8 when our groff still can't parse them. Having gone > through 2/3 of the archive, I got 807 such pages so far. And every single > one displays lovely "ä" or similar instead. That's 9% of all mans with > non-ASCII characters in the corpus. You mean by that that they're encoded as UTF-8 where man-db expects them in whatever encoding is in its hard-coded table, correct? How are you detecting them? [...] >> UTF-8 is supported on output, so it is really transparent for users. > > If you consider having all unsupported characters silently dropped as being > transparent. This may not be as bad as all that, actually. Currently man-db will cope fine with UTF-8 man pages (if it's expecting them) and will output UTF-8. Of course, it'll lose all characters not in ISO-8859-1, but that's a man-db bug. This means that, assuming they all actually *are* in ISO-8859-1, we should be able to transcode all such man pages to UTF-8, update man-db's table so it expects them, and not lose any functionality. This means that without having to wait for the technology, we can do this: - transcode all man pages currently in ISO-8859-1 into UTF-8 - move all non-ISO-8859-1 man pages into directories with explicit encodings et voila (which will soon be able to be reliably spelt voilá), we have now achieved total UTF-8 dominance. Admittedly, because we're not handling non-ISO-8859-1 characters, it's mere buzzword compliance, but that is now a perfectly manageable bug in man-db and groff. It means that by making one small change to man-db we can start the policy change and the technology change *in parallel*, which ought to save loads of time. ...also, because man pages are now either in UTF-8 or in a directory with an explicit encoding in the name, it ought to be easy to change linda and lintian to check for invalid UTF-8 in the man pages, which should help with the cat-herding aspects of the problem. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwkG7f9E0noFvlzgRAuefAKDaMn2noIGKL88qav+aaIb+4tEPGwCgi4kk 9wqG7+J19tOflGdaQIs/LqI= =ZivR -END PGP SIGNATURE-
Re: RFS: ufiformat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Given wrote: [...] > I am looking for a sponsor for my package "ufiformat". [...] > ufiformat - disk formatter for USB floppy drives I don't suppose there's anyone interested in sponsoring this, is there? AFAICT, there is currently no way of formatting floppy disks on USB external drives when using Debian, which does mean that this fills a rather crucial hole, particularly for laptop users. In case my earlier formal message went astray, it's on mentors, package name ufiformat; ITP #436134... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxHOgf9E0noFvlzgRAiqgAKCYcFv8vaFXAmkKRcpePTmWPbsluwCcDg0D Gwl6Y8wcbfXtuE9MCKAKPAI= =pJ2D -END PGP SIGNATURE-
Package requiring a customised version of another package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Note: it doesn't need the customised version to be *installed* --- all it needs is the .so somewhere private where it can find it. I suppose the worst-case scenario is where I have to ship a copy of the glibc source along with the plasticfs source and build it there... which is pretty horrible. Not the least of which is trying to keep the various version in sync. Of course, my build process *could* just do 'apt-get source glibc' and patch the result... Is there a smarter way of doing things? - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzeaCf9E0noFvlzgRAq4/AKCZ7Vl1HXSN2pPXvGNzY1qzLPm/OgCfXaI0 z7KEvCzTsEakF9Z3QKrXp1A= =aw6V -END PGP SIGNATURE-
Re: Package requiring a customised version of another package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] >> I have an application I'd like to package --- plasticfs. Unfortunately, due >> to >> glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) >> options. Is this doable, or is it likely to be a lost cause? > Please can you give the details of why this is necessary? It's an LD_PRELOAD hack. When glibc calls itself --- for example when fopen() calls open() --- it does so using a hidden private interface, which means the preloader library doesn't get a chance to override it. plasticfs wants a glibc compiled with --disable-hidden-plt to expose this interface. Or so the plasticfs docs say --- I'm sure this can be worked around, since fakeroot and fakechroot manage it, but I wouldn't know how to do that. Also, I'm working on the assumption that upstream at least know something about what they're talking about... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzfuLf9E0noFvlzgRAiq/AJ0XJAopwbtk0Kmw+0FKfht8NL1YZgCgkT2b 9PsElxgRWVm+0ccZbf+WpEg= =O/mh -END PGP SIGNATURE-
Re: Package requiring a customised version of another package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] >> which means the >> preloader library doesn't get a chance to override it. plasticfs wants a >> glibc >> compiled with --disable-hidden-plt to expose this interface. > I still don't understand why? I *presume* so that plasticfs can just override open() and not have to worry about overriding fopen() and getpwent() and tmpfile() and all the other glibc functions that call open() internally. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzgTkf9E0noFvlzgRAiWFAKCdDIRZ5Ck9rzyUz0R41OcSCrFZHgCdFA3U /Ep0TftHwqqas2W08YyuFXQ= =Bszw -END PGP SIGNATURE-
Re: Package requiring a customised version of libc6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Williams wrote: [...] > Do the work and come back to the list with > a detailed reasoning for what is a MAJOR packaging decision. This isn't > "yet another customised version of a package" it is a COPY of GLIBC! Don't shout at me, please. Yes, I am entirely aware of all the issues you raise. However, at this point I am still collecting information. I have no intention of doing *anything* until I know exactly what's going on. Currently I am merely trying to figure out whether upstream's idea of using a customised glibc is possible on Debian; I suspect it's not, but as I haven't actually received an answer to my question yet, it's still rather up in the air... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzht7f9E0noFvlzgRAgufAJ45Bb0AsCfnWnkAsLEmozlEZrPsRgCfZO3z k6pVrsqtl3pSWbObn5drGWY= =4jv2 -END PGP SIGNATURE-
Re: Package requiring a customised version of libc6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don Armstrong wrote: [...] > The people who have responded to you so far strongly suspect that it's > not worth the effort, but without knowing why the glibc we already > distribute can't be used, it's hard for us to give you a definitive > answer. *nods* As far as I can tell --- I've contacted upstream to confirm this --- what plasticfs wants to do is to override the underlying system calls (or at least, the functions that call them) that access the file system. Unfortunately, those system calls are not exposed by default, so plasticfs wants a tweaked glibc in which they are exposed. By overriding the system calls rather than the higher-level functions, it means that plasticfs doesn't have to override the higher-level functions --- they work automatically. fakeroot and fakechroot appear to operate by overriding *all* glibc functions that might access the file system. I've had a look at the code... it's unpleasant. There are a lot of functions that might do this, and not all of them are easily overridable, and quite a lot of them are rather obscure. (I'd never even heard of ftw() and nftw() before now.). This makes it much harder to catch coverage issues. A function that isn't wrapped will work on the real file system, rather than the virtual one. I notice that fakechroot doesn't wrap getpwent(), for example --- which means it'll always use the *real* /etc/passwd, rather than the emulated one. This could be intentional, but as it's not mentioned in the docs I suspect it's a bug. I've given up on the replacing-glibc idea; it was pretty horrible anyway. Unfortunately, the alternatives seem just as horrible, in different ways... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGziWjf9E0noFvlzgRAmPdAJkBBRbIetG6x/T23fKqDZtetrir+wCeP7fY t5NJukVanIgk7i8iZSW2W9E= =pOkz -END PGP SIGNATURE-
Re: Package requiring a customised version of libc6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lucas Nussbaum wrote: [...] > Then what about using ptrace and overriding syscalls in the way > usermodelinux used to do it? Yes, indeed; that is currently looking like the best approach. Not only does it provide the low-level interface that upstream wants, but it also works on statically bound binaries and on anything else that makes syscalls directly. I'm a little worried about performance, but it can't be that bad or UML wouldn't use it. I'll suggest it to upstream. Thanks for the link. (Incidentally, the more I look at fakechroot the more I'm coming to believe that it's no use for anything whatsoever. The security aspects of it are... erm... nil; it's trivial for the client app to break out of its jail. Is this a potential problem?) - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzr+7f9E0noFvlzgRAnMFAKCp0NxkOWgEW4XMNFeHg0CaViWlqwCg0S45 unlRqCTamPtiz0Q8tjZ2spU= =X2Ph -END PGP SIGNATURE-
Re: RFS: steam-powered
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Finney wrote: [...] > There's nothing in the social contract that compels anyone to include > any specific software in Debian if they are disinclined to do so. The > package in question has as its sole purpose the promotion of non-free > software. Many people are disinclined to spend effort on promoting > non-free software, and your cries will not gain their support. Hmm. Given that I've just seen pretty much exactly the same conversation on -devel about a week ago, and that this keeps popping up, it's obvious that there *is* demand for working non-free software on Debian. (I use it myself.) Also given that given that there are a number of DDs who *do* want to sponsor non-free (because otherwise there wouldn't be such a thing...), might I suggest that it might be worthwhile setting up a -nonfree mailing list? This ought to allow the relatively small number of nonfree developers to meet each other more easily, while also keeping such things out of -mentors and -devel, an improvement to everybody. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3R5wf9E0noFvlzgRAgFgAKDd+f2/0vN600Zatk49hEIA3Y/CDwCfYFqZ Oc4NDyB0uajOKYwUOtFkzXs= =bLPA -END PGP SIGNATURE-
Re: How to start porting to a new ARCHITECTURE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michelle Konzack wrote: [...] > since 2007-08-01 I am now jobless (yeah, the new French GOV do not like > that I stay in the army as PMC) and today (Saturday) I was asked by an > owner of a german Enterprise whether it is possibel to port GNU/Linux, > specialy Debian to this new ARCHITECTURE. > > Now I need to ask you, how one should start this? You've got two major tasks ahead of you: - - port gcc - - port the kernel - - cross-compile a basic userland For the former, you'll need to write a new gcc backend targeting your architecture, and then add support to binutils to allow programs to be linked. This is not easy. gcc's innards tend to drive people mad. Once you have a compiler, you can then port the kernel --- this will require development hardware with a good debugger (or, preferably, a reliable emulator with built-in debugger support). You'll be wading neck-deep in the inside of the kernel, although I gather it's not as bad as it used to be these days. Now you have both a compiler and a kernel, you can use your compiler to generate a userland --- as set of basic binaries to get your system up and running --- and then boot your new system. This isn't too difficult, although cross-compiling on gcc has its own horrors. Once you've got it reliably self-hosted, you're most of the way there --- setting up a basic Debian port is relatively straightforward. I'd suggest looking up a gcc and linux-kernel mailing list and asking there for more detailed info. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7st7f9E0noFvlzgRAuz6AKC4JnIKL5SXJq+Np6qNEJcgMEJ6AACglhF6 aVbLIkgBmbaIhFyQSga55xw= =nuuc -END PGP SIGNATURE-
Re: RFS: nted (3rd try)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Schanze wrote: [...] > Is it possible to get any sound output without MIDI hardware > (kernel module is loaded)? > Just to test the program. Install timidity and freepats, do: timidity -iAv -B2,8 -Os ...and some new MIDI ports will show up. You can then tell nted to use these and timidity will emulate a GM synth and play to your ALSA sound device. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ "There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs." --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKRLkf9E0noFvlzgRArd8AJ9d3d2TF+ALEKOPZE4A+Oi6/BlVngCcC9VH Lp+OR3LbMmrPMKu19oszcA4= =v8hI -END PGP SIGNATURE-
RFS: wordgrinder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package "wordgrinder". * Package name: wordgrinder Version : 0.2-1 Upstream Author : David Given <[EMAIL PROTECTED]> * URL : http://wordgrinder.sourceforge.net * License : New Form BSD Section : editors It builds these binary packages: wordgrinder - a simple word processor that runs in a terminal The package appears to be lintian clean. The upload would fix these bugs: 461515 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/w/wordgrinder - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/w/wordgrinder/wordgrinder_0.2-1.dsc I would be glad if someone uploaded this package for me. It's very nearly linda and lintian clean (linda complains about me using Standards-Version 3.7.3, but if I use 3.7.2 then lintian complains that I'm not using 3.7.3...), and it builds cleanly under pbuilder. (Note --- when I wear my other hat, I am upstream.) Kind regards David Given -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkhfRf9E0noFvlzgRAsaIAKC7fP7u9JQk0KD7t7meTHio7dIGTwCZAa7Q vLHXTAug+I9GsfJYXfXHFog= =g2E7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: wordgrinder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Tuckley wrote: [...] > I'll take a closer look tomorrow and if I don't find anything wrong I'll > sponsor it for you. Ta muchly. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "Wizards get cranky, / Dark days dawn, / Riders smell manky, / The │ road goes on. / Omens are lowering, / Elves go West; / The Shire needs │ scouring, / You may as well quest." - John M. Ford -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkxfIf9E0noFvlzgRArp6AJ9Tc1f9IetjE9K8pFI9W8LJq5jJOwCeNq8k ujLkbjUBk6Az2oyy0a3tBSk= =msQZ -END PGP SIGNATURE-
Re: RFS: wordgrinder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Tuckley wrote: [...] > Uploaded! Gosh, that was quick! Thanks very much. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "Wizards get cranky, / Dark days dawn, / Riders smell manky, / The │ road goes on. / Omens are lowering, / Elves go West; / The Shire needs │ scouring, / You may as well quest." - John M. Ford -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkyGuf9E0noFvlzgRAhxCAJ0SWoa3g+FM/os5a4O8kfX2RGgtzwCgluVk ccHMGWxhlBlsWZ2rY2fLTq0= =IAV0 -END PGP SIGNATURE-
DD lite
I've had it suggested to me that there's a new streamlined Debian Maintainer role, that gives DD-like privileges over a limited number of packages. Some quick web searching doesn't reveal anything. Does anyone know anything about this? While currently I have no desire to become a full DD --- I *like* having a sponsor check my new packages, thanks very much --- this would be a big benefit for doing bugfixes and incremental upgrades of my existing packages: I would be able to do minor changes and upload them without having to hassle my sponsor. And since they'd only be minor changes, they might even work, too. Does such a thing exist? -- David Given [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging without Makefile
Dominik George wrote: [...] > Sounds easy - but how do I get it to copy my one single file? What Dmitry > suggested does not quite work ... The debian/rules file *is* a Makefile --- so at the very worst you can just change the bit that invokes upstream's Makefile to a cp. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup signature.asc Description: OpenPGP digital signature
Uploader wanted: new version of ufiformat
I've been maintaining the ufiformat floppy disk formatter package; recently I did a new version to fix a FTBFS bug (plus a whole bunch of other improvements). Unfortunately my usual sponsor is unavailable due to being in hospital, so I can't get it uploaded --- I'm not a DM. Would it be possible for someone to have a look to make sure I haven't done anything really stupid and, if it looks good, upload it for me? https://mentors.debian.net/package/ufiformat It's lintian clean and the mentors automated system thinks it's okay too. Package description follows: Description: disk formatter for USB floppy drives ufiformat is a command-line utility for formatting floppy disks in UFI-compatible USB floppy drives. It allows disks to be formatted in any format supported by the drive, and can also be used to determine what format a disk is currently using. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "Home is where, when you have to go there, they have to take you in." │ --- Cordelia Naismith (via Robert Frost) signature.asc Description: OpenPGP digital signature
Re: Uploader wanted: new version of ufiformat
On 19/10/13 18:12, David Given wrote: [...] > Would it be possible for someone to have a look to make sure I haven't > done anything really stupid and, if it looks good, upload it for me? > > https://mentors.debian.net/package/ufiformat Can anyone assist me with this? I want to get the FTBFS bug fixed, but can't upload it myself... (Once this is done I really need to get started on the DM process to avoid this happening again.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "Home is where, when you have to go there, they have to take you in." │ --- Cordelia Naismith (via Robert Frost) signature.asc Description: OpenPGP digital signature
Re: Uploader wanted: new version of ufiformat
On 21/10/13 15:32, David Given wrote: [...] > Can anyone assist me with this? I want to get the FTBFS bug fixed, but > can't upload it myself... I've just received notification that it's been uploaded by someone. Thanks! -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "Home is where, when you have to go there, they have to take you in." │ --- Cordelia Naismith (via Robert Frost) signature.asc Description: OpenPGP digital signature
Creating a user/group for a package
Hello, I'm packaging a daemon that wants to run in its own user and group. I'm having trouble finding any information on how to handle creating/deleting these cleanly. I've looked it the New Maintainer's Guide and the Policy Manual but don't see any reference to doing this. I've looked at some existing packages (ssh, timidity) and am a little confused; not only do they both do the user and group management all manually in their postinst/prerm scripts (isn't there any debhelper mechanism for handling this?), but in general the support seems a bit shifty: at uninstall time neither delete their group, timidity never deletes its user at uninstall time at all, and while ssh does delete its user, won't this cause problems if orphaned files are left with that uid? This must be a solved problem by now; what am I missing? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "I have a mind like a steel trap. It's rusty and full of dead mice." │ --- Anonymous, on rasfc signature.asc Description: OpenPGP digital signature
RFS: spey
Dear mentors, I am looking for a sponsor for my package "spey". * Package name: spey Version : 1.0.pre1-1 Upstream Author : David Given ; myself * URL : http://spey.sf.net * License : GPL v2 Section : mail It builds these binary packages: spey - SMTP proxy with greylisting, RBL, and authentication The upload would fix these bugs: 611409 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/spey - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/spey/spey_1.0.pre1-1.dsc spey is an SMTP proxy that sits between a real MTA and the outside world and filters the connection; it's intended to provide a very lightweight first-line-of-defense against spam, but has other uses (one of my users uses it solely to provide an easy way of doing authenticated SMTP). I've had a couple of requests for a Debian package so I feel this would be of interest to the community. Note that I'm not asking for this to be uploaded as yet --- I'm preparing a new upstream release (SourceForge's CVS servers allowing), and I don't want any Debian package to go out until that's done. However, while I have some Debian packages in the archive already, this is my first try at a non-trivial one, so I think I'll need a run up. It's lintian clean (with one override). -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "I have a mind like a steel trap. It's rusty and full of dead mice." │ --- Anonymous, on rasfc signature.asc Description: OpenPGP digital signature
Re: Creating a user/group for a package
On 30/01/11 03:02, The Fungi wrote: [...] > This has been discussed to death in years past, but it's generally > considered more dangerous to delete accounts in package management > than to leave them behind. That's fine by me; less work! I've done this; thanks. Although I might suggest that the next edition of the NMG could usually have a discussion of the issue and recommended best practices. (I have since found some useful code snippets in the Securing Debian Manual, but it's not an obvious place to look.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "I have a mind like a steel trap. It's rusty and full of dead mice." │ --- Anonymous, on rasfc signature.asc Description: OpenPGP digital signature
Re: Output of dpkg-scanpackages as XML
William Ballard wrote: [...] Of course you're right. But building XML with shell commands was always a lot easier when I could count on all shell output being 2-byte Unicode. It was a neat bit of magic, ascii and utf-8 text files would get turned into Unicode and I'd pipe them to cscript.exe and my XML would never break. iconv is your friend: zcat Packages.gz | iconv -f utf8 -t ucs2-le | cscript (Packages.gz is in UTF8, right? In fact, if you were using grep you'd want to use UTF8 so that the non-ASCII characters would simply fall through, rather than UCS2.) Unicode and XML are like chocolate and peanut butter. Um, yeah. Personally, I've never eaten peanut butter and chocolate together, and have no desire to. I think XML is overrated, too, but that's neither here nor there... -- [insert interesting .sig here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Output of dpkg-scanpackages as XML
William Ballard wrote: [...] But back to Linux. $echo hi | iconv -f utf8 -t unicode | grep hi (no output) Not surprised; grep understands ASCII, AFAIK, so what you've just sent to it is: $ echo hi | iconv -f utf8 -t unicode | od -t x1 000 ff fe 68 00 69 00 0a 00 It can't find an 'h' and an 'i' next to each other. That's why I mentioned UTF8; UTF8 has the nice property that anything that can be represented in plain ASCII *is*, and all other characters are high-bit, which grep and friends will pass straight through. It's still an ad-hoc solution, though; does anyone know of versions of the standard textutils that know about Unicode? -- [insert interesting .sig here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cant build a simple package.
On Thursday 06 January 2005 09:17, Rakotomandimby (R12y) Mihamina wrote: [...] > I'm learning making debian packages. > I choosed to learn on a very simple software: minimalist. Are you aware that minimalist has already been packaged? Package: minimalist Priority: optional Section: mail Installed-Size: 256 Maintainer: Fernando Sanchez <[EMAIL PROTECTED]> Architecture: all Version: 2.5.2-1 Depends: perl5 Filename: pool/main/m/minimalist/minimalist_2.5.2-1_all.deb Size: 50454 MD5sum: 86021d345d293fadc417e12abefe022c Description: a MINImalist MAiling LIST manager Minimalist is a fast and extremely easy to setup and support list manager. . Minimalist has these features: . - subscribing/unsubscribing users by request - several levels of security - additional services such as information about list, archiving lists, information about users of list and so on - support for read-only/closed/mandatory lists - support for Blacklist - logging activity . Minimalist has also a notion of 'trusted users'. They have full rights to subscribe/unsubscribe other users; get any information related to lists and users. -- +- David Given --McQ-+ "If God spammed rasfw with the answer to Life, the | [EMAIL PROTECTED]| Universe, and Everything, I'd report him to | ([EMAIL PROTECTED]) | [EMAIL PROTECTED]" --- David Bilek +- www.cowlark.com --+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages that *can* provide essential services (but not always)
I'm currently thinking about packaging Citadel, a next-gen BBS and groupware system (http://www.citadel.org/). The problem with Citadel is that it supplies a whole bunch of different services. You can access it via its own protocol on port 504; it can be used as an SMTP mail server; it can act as a POP3 or IMAP4 server; etc, etc. It can, in general, act as a complete mail hub --- but can be configured not to. The problem I'm looking at is that if my package says that, say, it provides mail-transport-agent, then that means that it'll conflict with any other MTAs. But the user might not want to use Citadel as an MTA, and might want to keep exim instead. What's the best way round this? One thought I had was to provide a basic citadel-server package, and then have some dummy packages called citadel-server-mta, citadel-server-pop, etc that depend on it to keep the dependencies happy. But that seems rather ugly to me. Is there a correct way of tackling this kind of thing? -- [insert interesting .sig here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages that *can* provide essential services (but not always)
On Sunday 09 January 2005 18:53, Florian Weimer wrote: > * David Given: > > Is there a correct way of tackling this kind of thing? > > Does citadel provide the /usr/lib/sendmail interface? It does, yes, although it needs a bit of setting up; which makes it a good candidate for the citadel-server-smtp package, right? Is there anything similar I should be aware of for the pop3 and imap4 servers? -- +- David Given --McQ-+ "Why should we put ourselves out of our way to | [EMAIL PROTECTED]| serve posterity? For what has posterity ever done | ([EMAIL PROTECTED]) | for us?" --- Sir Boyle Roche +- www.cowlark.com --+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages which need themselves to compile?
This isn't directly a Debian packaging question, but it's related, and it may at some point in the future become a packaging question. I'm taking on maintainership of a very large and gnarly project, a compiler toolchain. Parts of the toolchain need other parts to build. Some parts require *themselves* to build. For example, there's a Bison-like parser generator called llgen whose input scripts are parsed using an llgen-generated parser. How does Debian deal with packages like this? I need to replace the build mechanism (the current one is being problematic), and as one day I'd like to make a Debian package of all of this, I want something that's Debian-friendly. Is there any better way of going about it than to just check a pre-built version of the parser into CVS? -- +- David Given --McQ-+ "I smell a rat; I see him forming in the air & | [EMAIL PROTECTED]| darkening the sky; but I'll nip him in the bud." | ([EMAIL PROTECTED]) | --- Sir Boyle Roche +- www.cowlark.com --+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages which need themselves to compile?
On Thursday 23 June 2005 20:04, John Skaller wrote: [...] > That cannot be allowed, the build must proceed without > ever installing anything: if you really need something > installed you will need to provide a separate package, > and then the build interaction cannot be cyclic. Ung. The build scripts do assume that as they build things, those things become available to use. For example, in order to build the libraries for each target architecture, they use the code generator and librarian tool that they've just built... I suspect that the only way to cleanly package this for Debian (and for most other architectures) would be to split it up into (a) tools, (b) code generators, (c) compilers, (d) libraries. Each one would be a different Debian package and build and install seperately (but possibly from the same source package). This does mean that building it all in one pass would be tricky, though. > Otherwise, if you have a cyclic process in the build, > then there is no alternative than to provide an initial > value for it, hopefully one such that the recursion > fixes fairly quickly .. How about this: supply a prebuilt parser; llgen builds using this parser, and then uses itself to generate a new parser. The build will then *fail* if this new parser does not match the prebuilt one. While this doesn't get around the bootstrap problem, it will eliminate gotchas due to the pregenerated file being out of sync. > BTW: is this vbccz you're talking about? No, this is the ACK, the toolchain that was written for Minix. It's been open sourced and, despite having timestamps over twenty years old, still works rather well --- if you can get it to build. http://tack.sourceforge.net -- "Curses! Foiled by the chilled dairy treats of righteousness!" --- Earthworm Jim (evil) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Detecting stray writes in cowbuilder
I've just had a FTBFS bug on a new upload caused by a debian/rules bug where I was running upstream's make install twice, once without setting PREFIX. This was causing the package to be installed to $HOME as will as to ./debian/tmp. This worked while doing the packaging, because it was silently getting installed in my home directory; and it worked in cowbuilder, because it was silently getting installed in the build's home directory and then discarded; but it was failing on the build servers because the build server's $HOME is read-only. Is there a way to make cowbuilder detect writes to places that shouldn't be written to so this doesn't happen again in the future? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#880414: RFS: wordgrinder 0.7-1 -- word processor which runs in a terminal
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wordgrinder": * Package name: wordgrinder Version: 0.7-1 Upstream Author: David Given * URL: http://cowlark.com/wordgrinder * License: MIT Section: editors It builds those binary packages: wordgrinder wordgrinder-x11 wordgrinder-ncurses wordgrinder-doc ...and it's uploaded on Mentors: https://mentors.debian.net/package/wordgrinder (Both 0.7-1 and a now obsolete 0.6-3~bpo8+1 version are uploaded there. Please ignore the 0.6 version; I haven't figured out how to delete it yet.) WordGrinder's not a new package --- it's been in Debian since wheezy. Unfortunately my existing sponsor has retired and is unable to upload the new version, so for the this version I'm looking for a new sponsor. The package should be in pretty good shape as the old sponsor waa pretty conscientous; it's lintian clean, has hardening enabled, and uses dquilt for patching. Disclaimer: when I'm wearing my other hat, I am the upstream author. Changes since the last upload: - New upstream release PTAL, and LMKWYT.
Bug#880414: RFS: wordgrinder 0.7-1 -- word processor which runs in a terminal
Aargh, yes --- the extras are documented upstream, but I completely forgot to update the debian/copyright file... I'm usually better than that. Sorry. (That's why there are reviews!) I have: - produced a new upstream version, 0.7.1, with the code rearranged to make it easier to strip out the unneeded dependencies, and much better documentation of third-party code. - produced a special minimal distribution just for Debian with the unused dependencies removed. (Most of them weren't being used anyway; now they're not present.) - updated the packaging. The only thing the package actually uses now is a patched copy of xpattern, which can't be externalised. It's documented in the copyright file. The new package is 0.7.1-1, here: https://mentors.debian.net/package/wordgrinder PTAL and let me know what else is wrong... On Thu, 2 Nov 2017 at 04:15 Adam Borowski wrote: > On Tue, Oct 31, 2017 at 11:33:13AM +0100, David Given wrote: > > * Package name: wordgrinder > > Version: 0.7-1 > > > WordGrinder's not a new package --- it's been in Debian since wheezy. > > Unfortunately my existing sponsor has retired and is unable to upload > > the new version, so for the this version I'm looking for a new > > sponsor. The package should be in pretty good shape as the old sponsor > > waa pretty conscientous; it's lintian clean, has hardening enabled, > > and uses dquilt for patching. > > > > Disclaimer: when I'm wearing my other hat, I am the upstream author. > > > > Changes since the last upload: > > > > - New upstream release > > I'm afraid the new version ships a bunch of big external projects such as > lua-5.1, minizip, uthash (aka "convenience copies"). It'd be better to > remove them from the tarball to ensure only the system version is used -- > this greatly helps the Security Team. This is not strictly needed, but > there should be a good reason to do otherwise. > > You also don't even mention them (other than uthash) in the copyright file, > despite them not having been written by you. > > There's also a bunch of smaller files from external source (lfs, wcwidth, > lua-bitop) -- you also falsely claim that you own copyright for them. > > (Yeah, copyright issues are an unfun thing, but these days lawyers rule the > world.) > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. > ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift > ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters > ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. > -- ┌─── http://cowlark.com ─── │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_
Re: RFS: flex-sdk-4.5
On 13/10/11 16:13, Joey Parrish wrote: [...] > Does the Debian community standardize on git, or is an svn repo also > acceptable? I don't have any experience with git yet, but I'm a > frequent user of svn. If you like SVN you may be interested in checking out Mercurial; it speaks git, so you can hg clone a git repo and it Just Works, and its commands are SVN-like. I've never been able to get my head around some of git's peculiarities and hg has saved my bacon several times. You want the mercurial-git package, and then you'll need to add: [extensions] hgext.git = ...to your .hgrc. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ "Under communism, man exploits man. Under capitalism, it's just the │ opposite." --- John Kenneth Galbrith signature.asc Description: OpenPGP digital signature
Re: debianization with files that change
I'd add that the recommended thing to do if you're trying to create a package for software you own is to blatantly wear two hats: with one hat you're the upstream author, and with the other hat you're the packager. Have two different repositories, don't add the debian/ directory to the upstream distribution, when you find an upstream bug fix it there and make a release and *then* import the new release into the Debian repository and make a new package, etc. The workflow works much better like that. In your specific case, this will avoid the git weirdness because you'd be only using the public dist files on import. On Sat, 11 Jan 2020 at 13:17, David Griffith wrote: > > My reply is at the bottom. Please put your reply there too. > On Sat, 11 Jan 2020, Thomas Dettbarn wrote: > >> David Griffith hat am 11. Januar 2020 um 05:57 > geschrieben: > >> > >> I'm trying to debianize Frotz 2.50 and put the debian/ directory into > the > >> git repository. A complication is that the contents of a dist file > >> differs from what you get from a git clone. This is what I get from > >> dpkg-source -b ./ > >> > >> dpkg-source: info: using options from frotz-git/debian/source/options: > --tar-ignore=public > >> dpkg-source: info: using source format '3.0 (quilt)' > >> dpkg-source: info: building frotz using existing > ./frotz_2.50.orig.tar.gz > >> dpkg-source: info: using patch list from debian/patches/series > >> dpkg-source: info: local changes detected, the modified files are: > >> frotz-git/.gitlab-ci.yml > >> frotz-git/Makefile > >> frotz-git/public/index.html > >> frotz-git/src/dos/bchash.h > >> dpkg-source: info: you can integrate the local changes with dpkg-source > --commit > >> dpkg-source: error: aborting due to unexpected upstream changes, see > >> /tmp/frotz_2.50-1.1.diff.B02OBO > >> > >> My problems: > >> 1) .gitlab-ci.yml handles the Frotz webpage > >> https://davidgriffith.gitlab.io/frotz/, which lives in public/. By > way of > >> .gitattributes, that's automatically stripped out of the tarball when > >> making a distribution source tarball. It should be ignored by > >> dpkg-source too. > >> > >> 2) I can't seem to make dpkg-source ignore public/. I put 'tar-ignore > = > >> "public"' into debian/source/options and it doesn't seem to work because > >> dpkg-source is still complaining about public/index.html. > >> > >> 3) When a dist tarball is made, hash and date information is put into > >> Makefile and dos/bchash.h by way of export substitutions in > >> .gitattributes. The object of this is to embed commit hashes and build > >> times into the executable. How do I tell the debianization process that > >> these changes are okay? I'd rather not have to do "made dist", open up > >> the resulting tarball, and debianize there. > >> > >> 4) I would also like the debianization process to ignore src/dos/ as > well > >> because that contains MS-DOS specific code. > >> > >> My working code for this is in the debian branch at > >> https://gitlab.com/DavidGriffith/frotz > > > The way into debian is a complicated one. There are a LOT of > > helper scripts out there, which have grown. Some of them are > > still useful, some are not. > > On top of that, the contents of the debian/ directory are > > plentiful, and not very well documented, if I may say so. > > > > My solution was to create a new repository (ports and packages) > > outside of my project, and put the debian/ directory in > > it. And edited the contents by hand. > > > > I also added a shell script mkpackage.sh, and only used three > > tools: debuild, debsign and dput. Within this script, I am > > also creating the orig.tar.gz, to make sure that it only > > contains files that I want it to contain. > > > > If you would like to have a look, you can clone it from here: > > github.com/dettus/ports_and_packages > > maybe it helps. > > I think I understand most of the debianization process as far as it > applies to packing up Frotz. My main concerns are why I continue to have > trouble with the public/ directory, how I'm supposed to make it ignore > src/dos, and what I'm supposed to do to make it not complain about > .gitlab-ci.ylm and Makefile. > > > -- > David Griffith > d...@661.org > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > -- ┌─── http://www.cowlark.com ─── │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup
Automated uploading of packages?
I have a compiler suite --- the Amsterdam Compiler Kit --- which I'm thinking of packaging. Trouble is, it's a bit of a moving target as it doesn't have releases and there's a slow trickle of activity making changes. I could do a packaging for it and get it reviewed and uploaded, but then I'd have to do it again basically every month. This seems like a lot of work. What I'd much rather do is to get it packaged and reviewed *once*, and then set up automation which periodically compiles and uploads new versions from the git repository. At first glance this seems a bit problematic, as it would require uploading packages which haven't been reviewed by a human. I'd be relying on the automation to spot any potential problems. But, if the packaging's not changing --- which should be detectable --- I'm not sure that a human review adds much value. The codebase is huge and it'd be just as easy to slip something nefarious through a human review as it would with automated reviews. So, is there any way in which this could be done? Has anyone worked on tooling for it that they can point me at? Realistically it'd make the difference between getting this into Debian and having the .deb files distributed via PPA or as manual sideloads...
Re: Questions about packaging the 'googleapis' project
On Wed, 14 Jun 2023 at 09:35, Paul Wise wrote: [...] > The upstream repo seems to use bazel as its build system, at least > according to the README. Is that not usable here? The bazel tool > appears to be packaged in bazel-bootstrap in Debian. > bazel-bootstrap is very old, unfortunately --- it's bazel 4.2.3, while the current version is 6.something and has moved on a lot since then. bazel's really hard to package. The sad thing is that bazel, which is the least bad build system I've ever used, works in a way that's completely antithetical to how Debian wants to build things: it doesn't want to use host software for *anything* and will, e.g., download and recompile libraries you refer to at build time. So you end up with mostly static binaries containing embedded copies of any libraries you refer to. It even likes to download its own compiler rather than using the host one. This is all for perfectly good reasons, but those reasons don't work for Debian. It ought to be possible to write bazel files which *do* produce Debian-compliant binaries, but it'll be tough (you'd basically need to replicate the ability to install Debian packages into the bazel build tree in order to use them as dependencies), and of course any third party software won't be doing that anyway so the package maintainer would need to rewrite large chunks of the build system.
Re: looking for a sponsor
On Thursday 21 October 2004 14:25, martin f krafft wrote: [...] > Chill. First, it is trivial to create Debian packages even on > Windows, and second... it's a mail client. To change the subject slightly, does anyone know what happened to debian-win32? The mailing list seems to be dead, it's not on the ports page, and I can't seem to find any resources on the 'net that date past about 1997. I could really use such a thing. -- +- David Given --McQ-+ | [EMAIL PROTECTED]| "I have a mind like a steel trap. It's rusty and | ([EMAIL PROTECTED]) | full of dead mice." --- Anonymous, on rasfc +- www.cowlark.com --+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating relocatable packages with dpkg
No Spam wrote: [...] I'm not sure that that's what's happening, but it makes sense. You can easily install a filesystem with "debootstrap - Bootstrap a basic Debian system". That seems like such overkill. I'm trying to do something similar; I'm putting together an embedded system, and want to populate it from Debian packages. I need to create a minimal chrooted Debian system in a subdirectory and then copy it to my target. debootstrap is, indeed, overkill. It insists on not only creating a local admin database but also on downloading all the packages it needs *into* that admin database, which takes forever. It also insists on installing all sorts of stuff that I'm never going to want to use --- my embedded system doesn't *need* exim, for example. What I eventually did is the incredibly simple and naive: for package in debs/*; do echo "Unpacking $package..." dpkg --extract "debs/$package" target done rm -rf target/usr/share/doc target/usr/share/man target/var/lib/dpkg This just extracts the files. It doesn't attempt to do any setup or maintain any admin database, and I have to do download the debs and do all the dependencies manually, but it does work (and it's fast). -- [insert interesting .sig here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: looking for a sponsor
On Thursday 21 October 2004 14:25, martin f krafft wrote: [...] > Chill. First, it is trivial to create Debian packages even on > Windows, and second... it's a mail client. To change the subject slightly, does anyone know what happened to debian-win32? The mailing list seems to be dead, it's not on the ports page, and I can't seem to find any resources on the 'net that date past about 1997. I could really use such a thing. -- +- David Given --McQ-+ | [EMAIL PROTECTED]| "I have a mind like a steel trap. It's rusty and | ([EMAIL PROTECTED]) | full of dead mice." --- Anonymous, on rasfc +- www.cowlark.com --+
Re: Playing with dpkg's mind
[...] > I actually rather like having IF games controlled by dpkg -- just like I > like having all the other sofwtware and even documentation I use under > it. The only issues I see are: > > 1. There are a *lot* of IF games! > 2. They are small individually. > > Both can be aided by having groups of games when possible -- e.g., one > pack for each IF competition. Also, both would be alleviated if the > "games" category had a subcategory for IF. I'd just like to point out that I'm working on packages for a bunch of IF interpreters using the glk I/O library; I've done Nitfol (Z-machine) and Glulxe (Glulx), and someone's just pointed me to a Tads glk interpreter. There's also a few other things in there that use glk. deb http://plover.net/~hjalfi/debian ./ deb-src http://plover.net/~hjalfi/debian ./ Just in case anyone's doing anything similar. -- +- David Given McQ-+ | Work: [EMAIL PROTECTED] | "Space is the final frontier, and so is the sewage | Play: [EMAIL PROTECTED]| farm." --- Diana Wynne Jones, _Archer's Goon_ +- http://www.cowlark.com -+
Re: glk packages
On Friday 09 November 2001 14:42, Robert Bihlmeyer wrote: > David Given <[EMAIL PROTECTED]> writes: > > I'd just like to point out that I'm working on packages for a bunch of > > IF interpreters using the glk I/O library; [...] > Are you interested in maintaining the packages for Debian? I could > sponsor you. I am; and I will be looking for a sponsor at some point, but I want to make sure the packages actually work properly first (no point in embarassing myself *too* much). I need to rearrange some of the configuration code. ...which reminds me; I have a question I've been wanting to ask. Am I allowed non conffiles in /etc? Each of my glk implementations wants to install a file in /etc/glkloader.d so that glkloader can find them. But I want the file to be removed again when the implementation is removed, and I don't think conffiles are ever removed. Any suggestions? -- +- David Given McQ-+ "Est brilgum: toui slimici | Work: [EMAIL PROTECTED] | In uabo tererotitant | Play: [EMAIL PROTECTED]| Brogoui sunt macresculi +- http://www.cowlark.com -+ Momi rasti strugitant." --- Anonymous
Looking for a sponsor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a Debian package that I'm looking for a sponsor for. Package: vbcc Version: 0.7-2 Section: devel Priority: optional Architecture: i386 Depends: libc6 (>= 2.2.4-2) Installed-Size: 1562 Maintainer: David Given <[EMAIL PROTECTED]> Description: Lightweight retargetable optimising C compiler vbcc is a free portable and retargetable ANSI C compiler which can generate code for a wide variety of processors. It can perform any of a large range of optimisations on the emitted code; in some areas it can produce better code than gcc. . This version contains code generators for: alpha, c16x, i386, m68k, PowerPC, and Infocom's Z-machine. vbcc is *non-free*. (The upstream author wants to keep a license that disallows the distribution of modified versions; I got special permission to distribute a tar.gz version of the source to go with the Debian patch.) It's almost, but not quite, lintian clean; it produces one error --- E: vbcc: FSSTND-dir-in-usr usr/man/ - --- what's this? You can find it here: http://plover.net/~hjalfi/debian/vbcc/ There's an apt repository based on http://plover.net/~hjalfi/debian, if you prefer. (There are some other packages in there that I'm packaging, but they need work before announcing to non beta people. If you're interested in glk or IF, you may want a look.) Any comments, suggestions, or flames because I haven't packaged it properly welcome. - -- +- David Given McQ-+ Did you hear about the Buddhist who refused his | Work: [EMAIL PROTECTED] | dentist's Novocain during root canal work? He | Play: [EMAIL PROTECTED]| wanted to transcend dental medication. +- http://www.cowlark.com -+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8QsJcf9E0noFvlzgRAkAnAKCQiSAp2HwnCeQB4I6UINu3JuPBagCgx1aQ qRBMH8ureEb2m0XZc6TgKkc= =4S4Y -END PGP SIGNATURE-
Re: Looking for a sponsor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 14 January 2002 11:51, peter karlsson wrote: > David Given: > > E: vbcc: FSSTND-dir-in-usr usr/man/ > > - --- what's this? [...] > man lintian > >-i, --info > Print explanatory information about discovered pol > icy violations in addition to the lintian error > tags. Ah. Oh. Okay, vbcc_0.7-3 is now available, and it's lintian clean. Thanks. - -- +- David Given McQ-+ "I told you to make one longer than another, and | Work: [EMAIL PROTECTED] | instead you have made one shorter than the other | Play: [EMAIL PROTECTED]| -- the opposite." --- Sir Boyle Roche +- http://www.cowlark.com -+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Qs6Hf9E0noFvlzgRAkA1AJ9vVBMs8vKU8AWYAan4eBaLoqnbcQCfWJLP fkae7lWHZ3ou0zO6u2+GV3U= =5ULK -END PGP SIGNATURE-
Re: Looking for a sponsor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 17:38, you wrote: > David Given <[EMAIL PROTECTED]> cum veritate scripsit: > > vbcc is *non-free*. (The upstream author wants to keep a license that > > disallows the distribution of modified versions; I got special permission > > to distribute a tar.gz version of the source to go with the Debian > > patch.) It's almost, but not quite, lintian clean; it produces one error > > --- > > Have you considered asking the upstream to > change the license ? I did my best to persuade him, but he doesn't want to. Besides, there are chunks of other licensed code in there; I did a code generator for it, which is BSDd; the preprocessor comes from lcc; etc. Non-free is the only possibility, I'm afraid. - -- +- David Given McQ-+ "We must go out and utterly crush every other | Work: [EMAIL PROTECTED] | worldview that does not believe in tolerance and | Play: [EMAIL PROTECTED]| free speech!" --- David Brin, paraphrased +- http://www.cowlark.com -+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RG+Kf9E0noFvlzgRAhuzAJ9r8nCFAL1Vx+axea4TDxwmnetrWwCg1m6w M+4XixbVT63TyYua3IzMTrw= =QXMa -END PGP SIGNATURE-
Looking for sponsor: nitfol/glulxe/floo/glk
I have built a number of packages for the glk generic user interface library, plus some applications that use them. The applications are: * nitfol: a Z-machine interpreter * glulxe: a Glulx interpreter (the successor to the Z-machine) * floo: a simple Postscript-based language interpreter Three glk backends are available: * cheapglk: uses only stdin/stdout * glkterm: uses Curses * xglk: uses Xlib (There's also a GtkGlk, but it's still under development so I haven't packaged it.) The main libglk0 package is a wrapper called glkloader that dynamically loads whichever backend the user wants, so the same binary will work with any backend. There's a libglk-dev for development. All the packages are available here: deb http://www.cowlark.com/debian.dat/ ./ deb-src http://www.cowlark.com/debian.dat/ ./ (Plus a bunch of other stuff, but that's not relevant here.) The full list of packages is: floo_0.5-4_i386.deb glulxe_0.3.5-2_i386.deb libglk-dev_0.3.2-4_i386.deb libglk0-cheap_0.8.7-3_i386.deb libglk0-term_0.7.8-3_i386.deb libglk0-xglk_0.4.11-3_i386.deb libglk0_0.3.2-4_i386.deb nitfol_0.5-3_i386.deb ...plus source. All of them are lintian clean. I have a number of users who haven't complained of any bugs yet. Anyone interested in sponsoring them? I've managed to tick off everything else on the checklist... -- David Given [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Multiple compile of source (ie, different configure lines for each package)
On Wed, 2002-09-18 at 07:33, Turbo Fredriksson wrote: [...] > The key point was that there was no second point 1 (Touching file1-stamp). > Since the 'file1-stamp' file where removed, I had expected 'make' to > re-create it! It doesn't... > > Any one have any idea? make only looks at the file system *once*. So it sees that file1-stamp doesn't exist, and runs the rule to create it. It will then assume that file1-stamp will *continue* to exist. This has bitten me several times. Personally, I'd be inclined to go for the easy solution: duplicate the source tree three times, once for each configuration. Using symlink trees this won't use much more disk space (apart from the object files), and dependencies will keep working (although they're not used much in Debian). -- +- David Given --McQ-+ Did you hear about the hard-working but ill sage | [EMAIL PROTECTED]| who got cursed with garlic breath? He was a | ([EMAIL PROTECTED]) | super-calloused fragile mystic hexed with +- www.cowlark.com --+ halitosis. signature.asc Description: This is a digitally signed message part
Re: Control File
On Thu, 2002-10-03 at 16:56, Zeno Davatz wrote: [...] > Why do the dependency-manager not know that I already got apache-ssl > installed. I wrote in my control file that apache-ssl-ywesee replaces > apache, apache-common, apache-ssl All Replaces: does is ensure that if you install apache-ssl-ywesee, then apache, apache-common and apache-ssl are removed. What you want is to add: Provides: apache, apache-common, apache-ssl This will tell the package manager that apache-ssl-ywesee has the same functionality as the named packages, so that any dependency that relies on one can depend on apache-ssl-ywesee instead. -- +- David Given --McQ-+ Did you hear about the hard-working but ill sage | [EMAIL PROTECTED]| who got cursed with garlic breath? He was a | ([EMAIL PROTECTED]) | super-calloused fragile mystic hexed with +- www.cowlark.com --+ halitosis. signature.asc Description: This is a digitally signed message part
Re: glk packages
On Friday 09 November 2001 14:42, Robert Bihlmeyer wrote: > David Given <[EMAIL PROTECTED]> writes: > > I'd just like to point out that I'm working on packages for a bunch of > > IF interpreters using the glk I/O library; [...] > Are you interested in maintaining the packages for Debian? I could > sponsor you. I am; and I will be looking for a sponsor at some point, but I want to make sure the packages actually work properly first (no point in embarassing myself *too* much). I need to rearrange some of the configuration code. ...which reminds me; I have a question I've been wanting to ask. Am I allowed non conffiles in /etc? Each of my glk implementations wants to install a file in /etc/glkloader.d so that glkloader can find them. But I want the file to be removed again when the implementation is removed, and I don't think conffiles are ever removed. Any suggestions? -- +- David Given McQ-+ "Est brilgum: toui slimici | Work: [EMAIL PROTECTED] | In uabo tererotitant | Play: [EMAIL PROTECTED]| Brogoui sunt macresculi +- http://www.cowlark.com -+ Momi rasti strugitant." --- Anonymous -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for a sponsor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a Debian package that I'm looking for a sponsor for. Package: vbcc Version: 0.7-2 Section: devel Priority: optional Architecture: i386 Depends: libc6 (>= 2.2.4-2) Installed-Size: 1562 Maintainer: David Given <[EMAIL PROTECTED]> Description: Lightweight retargetable optimising C compiler vbcc is a free portable and retargetable ANSI C compiler which can generate code for a wide variety of processors. It can perform any of a large range of optimisations on the emitted code; in some areas it can produce better code than gcc. . This version contains code generators for: alpha, c16x, i386, m68k, PowerPC, and Infocom's Z-machine. vbcc is *non-free*. (The upstream author wants to keep a license that disallows the distribution of modified versions; I got special permission to distribute a tar.gz version of the source to go with the Debian patch.) It's almost, but not quite, lintian clean; it produces one error --- E: vbcc: FSSTND-dir-in-usr usr/man/ - --- what's this? You can find it here: http://plover.net/~hjalfi/debian/vbcc/ There's an apt repository based on http://plover.net/~hjalfi/debian, if you prefer. (There are some other packages in there that I'm packaging, but they need work before announcing to non beta people. If you're interested in glk or IF, you may want a look.) Any comments, suggestions, or flames because I haven't packaged it properly welcome. - -- +- David Given McQ-+ Did you hear about the Buddhist who refused his | Work: [EMAIL PROTECTED] | dentist's Novocain during root canal work? He | Play: [EMAIL PROTECTED]| wanted to transcend dental medication. +- http://www.cowlark.com -+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8QsJcf9E0noFvlzgRAkAnAKCQiSAp2HwnCeQB4I6UINu3JuPBagCgx1aQ qRBMH8ureEb2m0XZc6TgKkc= =4S4Y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a sponsor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 14 January 2002 11:51, peter karlsson wrote: > David Given: > > E: vbcc: FSSTND-dir-in-usr usr/man/ > > - --- what's this? [...] > man lintian > >-i, --info > Print explanatory information about discovered pol > icy violations in addition to the lintian error > tags. Ah. Oh. Okay, vbcc_0.7-3 is now available, and it's lintian clean. Thanks. - -- +- David Given McQ-+ "I told you to make one longer than another, and | Work: [EMAIL PROTECTED] | instead you have made one shorter than the other | Play: [EMAIL PROTECTED]| -- the opposite." --- Sir Boyle Roche +- http://www.cowlark.com -+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Qs6Hf9E0noFvlzgRAkA1AJ9vVBMs8vKU8AWYAan4eBaLoqnbcQCfWJLP fkae7lWHZ3ou0zO6u2+GV3U= =5ULK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a sponsor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 17:38, you wrote: > David Given <[EMAIL PROTECTED]> cum veritate scripsit: > > vbcc is *non-free*. (The upstream author wants to keep a license that > > disallows the distribution of modified versions; I got special permission > > to distribute a tar.gz version of the source to go with the Debian > > patch.) It's almost, but not quite, lintian clean; it produces one error > > --- > > Have you considered asking the upstream to > change the license ? I did my best to persuade him, but he doesn't want to. Besides, there are chunks of other licensed code in there; I did a code generator for it, which is BSDd; the preprocessor comes from lcc; etc. Non-free is the only possibility, I'm afraid. - -- +- David Given McQ-+ "We must go out and utterly crush every other | Work: [EMAIL PROTECTED] | worldview that does not believe in tolerance and | Play: [EMAIL PROTECTED]| free speech!" --- David Brin, paraphrased +- http://www.cowlark.com -+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RG+Kf9E0noFvlzgRAhuzAJ9r8nCFAL1Vx+axea4TDxwmnetrWwCg1m6w M+4XixbVT63TyYua3IzMTrw= =QXMa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for sponsor: nitfol/glulxe/floo/glk
I have built a number of packages for the glk generic user interface library, plus some applications that use them. The applications are: * nitfol: a Z-machine interpreter * glulxe: a Glulx interpreter (the successor to the Z-machine) * floo: a simple Postscript-based language interpreter Three glk backends are available: * cheapglk: uses only stdin/stdout * glkterm: uses Curses * xglk: uses Xlib (There's also a GtkGlk, but it's still under development so I haven't packaged it.) The main libglk0 package is a wrapper called glkloader that dynamically loads whichever backend the user wants, so the same binary will work with any backend. There's a libglk-dev for development. All the packages are available here: deb http://www.cowlark.com/debian.dat/ ./ deb-src http://www.cowlark.com/debian.dat/ ./ (Plus a bunch of other stuff, but that's not relevant here.) The full list of packages is: floo_0.5-4_i386.deb glulxe_0.3.5-2_i386.deb libglk-dev_0.3.2-4_i386.deb libglk0-cheap_0.8.7-3_i386.deb libglk0-term_0.7.8-3_i386.deb libglk0-xglk_0.4.11-3_i386.deb libglk0_0.3.2-4_i386.deb nitfol_0.5-3_i386.deb ...plus source. All of them are lintian clean. I have a number of users who haven't complained of any bugs yet. Anyone interested in sponsoring them? I've managed to tick off everything else on the checklist... -- David Given [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Multiple compile of source (ie, different configure lines foreach package)
On Wed, 2002-09-18 at 07:33, Turbo Fredriksson wrote: [...] > The key point was that there was no second point 1 (Touching file1-stamp). > Since the 'file1-stamp' file where removed, I had expected 'make' to > re-create it! It doesn't... > > Any one have any idea? make only looks at the file system *once*. So it sees that file1-stamp doesn't exist, and runs the rule to create it. It will then assume that file1-stamp will *continue* to exist. This has bitten me several times. Personally, I'd be inclined to go for the easy solution: duplicate the source tree three times, once for each configuration. Using symlink trees this won't use much more disk space (apart from the object files), and dependencies will keep working (although they're not used much in Debian). -- +- David Given --McQ-+ Did you hear about the hard-working but ill sage | [EMAIL PROTECTED]| who got cursed with garlic breath? He was a | ([EMAIL PROTECTED]) | super-calloused fragile mystic hexed with +- www.cowlark.com --+ halitosis. signature.asc Description: This is a digitally signed message part
Re: Control File
On Thu, 2002-10-03 at 16:56, Zeno Davatz wrote: [...] > Why do the dependency-manager not know that I already got apache-ssl > installed. I wrote in my control file that apache-ssl-ywesee replaces > apache, apache-common, apache-ssl All Replaces: does is ensure that if you install apache-ssl-ywesee, then apache, apache-common and apache-ssl are removed. What you want is to add: Provides: apache, apache-common, apache-ssl This will tell the package manager that apache-ssl-ywesee has the same functionality as the named packages, so that any dependency that relies on one can depend on apache-ssl-ywesee instead. -- +- David Given --McQ-+ Did you hear about the hard-working but ill sage | [EMAIL PROTECTED]| who got cursed with garlic breath? He was a | ([EMAIL PROTECTED]) | super-calloused fragile mystic hexed with +- www.cowlark.com --+ halitosis. signature.asc Description: This is a digitally signed message part
Packaging an application with unpackaged dependencies
I'm try to put together a package for a big, complex application. One of its dependencies isn't in Debian yet. What do I do? - package up the dependency and somehow get both packages sponsored at the same time (how?); - package up the dependency and get it sponsored first... meaning that I'll be trying to get a library added which has no users. Neither option seems great, TBH. What's the recommended thing to do here? Both the application and the library are written in Java, FWIW. Thanks!
Re: Packaging an application with unpackaged dependencies
Unfortunately they're all external libraries. Right now I'm just trying to make it build (it uses a new version of gradle...) and am making a list of the libraries one at a time as I find them. Nothing's particularly complex; examples are Phidias (https://github.com/rotty3000/phidias) and jungrapht ( https://github.com/tomnelson/jungrapht-visualization), but there's more. AFAICT packaging a Maven Java-only library is, or at least should be, almost trivial... On Fri, 24 May 2024 at 18:08, Jérémy Lal wrote: > Hi David, > > Le ven. 24 mai 2024 à 17:06, David Given a écrit : > >> I'm try to put together a package for a big, complex application. One of >> its dependencies isn't in Debian yet. What do I do? >> >> - package up the dependency and somehow get both packages sponsored at >> the same time (how?); >> - package up the dependency and get it sponsored first... meaning that >> I'll be trying to get a library added which has no users. >> >> Neither option seems great, TBH. What's the recommended thing to do here? >> > > There is a third option: you can bundle the dependency. > It is especially appropriate when it is from the same upstream authors, > when they chose to split their software into parts that fit together, > but that are not actually used elsewhere. > Also, it makes sense when the dependency is a non-released obscure library > that won't ever be used by some other package. > It is not appropriate if that dependency is a mainstream java library that > just happens to be missing from debian. > In that case, options 1/2 are better. > Check Java Team policy, they might have some doc on that matter. > The tools to do that are uscan (check its man page), debian/copyright, > multiple upstream tarballs, components, and you can find plenty of examples > from sources.debian.net. > > >
Re: Packaging an application with unpackaged dependencies
On Sun, 26 May 2024 at 04:58, Wookey wrote: > On 2024-05-24 16:39 +0200, David Given wrote: > [...] > > - package up the dependency and get it sponsored first... meaning that > I'll > > be trying to get a library added which has no users. > > This is what I do. All packages have no users before they enter the > archive so that's not really a problem. Cool. I'll continue trying to make it build and come up with a full list of unpackaged dependencies, and report back.
