Re: SML/NJ Packaging Difficulties
On Tue, Jul 15, 2003 at 08:04:07PM -0700, Aaron Matthew Read wrote: > The smlnj package (the compiler) is implemented in sml and needs a > working implementation to build. Upstream, a set of pre-compiled > binary files (~4 MB each) are supplied for each platform. > > When I initially supplied the smlnj package, I shortsightedly only > included the binary images required to build the i386 and powerpc > platforms, since those were the only platforms for which I had a > working runtime package. > > Since then, I have received a patch to get the runtime working on > hppa, and am now confronted by my lack of forethought. Since the > boot files are binary, I cannot simply patch them on. Since the boot > files upstream only represent a subset of Debian supported > architectures (with the possibility of cross-compiling more in the > future), I cannot provide a definitive set of boot files. > > I think this problem is a manifestation of bad design of this > package. I'm curious if anyone has dealt with similar problems > (platform-specific binaries required to build their package) or has > any ideas about a better design for such problems. > > Here are some of my ideas: > 1. Eliminate the need for the boot images, somehow creating them from >scratch. A working sml implementation is needed since the compiler >is written in sml. I don't see any reasonable way to implement this >solution. > 2. Download the appropriate boot image while building the package. I >doubt this would be in the spirit of Debian Policy, if not a direct >violation. > 3. For each platform, create a source package, for example: smlnj-x86 >which would contain the appropriate boot image. These packages >would provide smlnj as a virtual package. Seems the best solution. > > I am not confident enough with the third idea to begin without seeing > if anyone has any other ideas, or an elaboration on one of mine. Notice that the ocaml packages also include some initial images, but i believe they are not used really. I just copy them somewhere else and back when cleaning so i don't get problem with the generation of the patch. How it actually works is that a minimal ocaml compiler is generated from C code, and this one is used to bootstrap the initial compiler suite, which is then used to rebuild everything. I believe that maybe smlnj has some similar mechanism, maybe you should ask upstream about this. Friendly, Sven Luther
xemacs specific .el
Hello, I have a package that installs a xemacs specific .el file, which naturally don't build with the emacs20 package i have installed. Is there a way of specifying that only xemacs installs should build a given .el or something such ? Friendly, Sven Luther
Re: xemacs specific .el
On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: > On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: > > I have a package that installs a xemacs specific .el file, which > > naturally don't build with the emacs20 package i have installed. > > > > Is there a way of specifying that only xemacs installs should build a > > given .el or something such ? > > Yes, check the Emacs policy doc. The install scripts get passed the flavor > (emacs20, emacs21, xemacs21) as the first argument, so the script can check it > and skip it unless the flavor is xemacs21. You can download my aplus-fsf-el > package source if you want an example. It only works with xemacs21, and I > have both xemacs21 and emacs21 installed on my machines, so I know it's > working properly :-) > Ok, nice. Will the install script be called for every .el file, or only for the whole directory. I have a bunch of .el files, and only one has this problem. I will go read the emacs policy now, i guess it has the answer ... Now, there don't seem to be made any mention of this. Friendly, Sven Luther
Re: xemacs specific .el
On Sat, Aug 30, 2003 at 08:57:36AM -0400, Neil Roeth wrote: > On Aug 30, Sven Luther ([EMAIL PROTECTED]) wrote: > > On Fri, Aug 29, 2003 at 08:30:38PM -0400, Neil Roeth wrote: > > > On Aug 29, Sven Luther ([EMAIL PROTECTED]) wrote: > > > > I have a package that installs a xemacs specific .el file, which > > > > naturally don't build with the emacs20 package i have installed. > > > > > > > > Is there a way of specifying that only xemacs installs should build a > > > > given .el or something such ? > > > > > > Yes, check the Emacs policy doc. The install scripts get passed the > flavor > > > (emacs20, emacs21, xemacs21) as the first argument, so the script can > check it > > > and skip it unless the flavor is xemacs21. You can download my > aplus-fsf-el > > > package source if you want an example. It only works with xemacs21, and > I > > > have both xemacs21 and emacs21 installed on my machines, so I know it's > > > working properly :-) > > > > > > > Ok, nice. Will the install script be called for every .el file, or only > > for the whole directory. I have a bunch of .el files, and only one has > > this problem. > > > > I will go read the emacs policy now, i guess it has the answer ... Now, > > there don't seem to be made any mention of this. > > The install script gets called once for each flavor, and since you write that, > you have total control over what it does. If foo.el is your xemacs specific > script, then some test like > > for f in *.el; do > if [ "$f" != "foo.el" ] || [ "$FLAVOR" != "xemacs" ] > ... > done > > should do it. Ok, thanks, i will do it then. > [ No need to CC me, I'm on the list. ] Then set your mail-followup-to or somethign such header correctly ? Friendly, Sven Luther
Re: randomplay: command-line shuffle music player
On Mon, Sep 08, 2003 at 05:37:40AM +0200, Adam Borowski wrote: > On Sun, 7 Sep 2003, Adam Kessel wrote: > > I've written a fairly simple command-line shuffle music file player. > > Despite its simplicity, I find it quite handy, and I don't think there's > > any other package out there (in Debian or not) that does quite what it > > does. The main feature is that it keeps track of which files have been > > played across sessions; but it also has some nice ways to play your files > > quickly from the command line. It's definitely a "scratch an itch" type > > program. > Been there... my version is -shuffle +recursion. > > > I'm wondering if something relatively simple (the script is about 340 > > lines of code) would be worth including in Debian. > There is already something similar (music123), but that one is devoid of > the features I want, and consists of 1e38 source files and a 300KB binary > written in some completely inappropiate language (you can do that in a few > screenfulls of perl, you know). There is quark also, which is a client/server design with both command line and gnome system tray (err notification area that is now, maybe it even works with any freedesktop notification areas) clients. It does random and loop playing, but nothing much more, and is maybe a bit feable/immature on handling playlists. Well, you can provide a simple textual playlist file, or hand append files, but that's it. It also doesn't die when you relaunch the X server, which is rather nice when doing X driver work :))) It also is a true C application, and not a bunches of script. It uses libxine for playing sounds. Friendly, Sven Luther
Re: randomplay: command-line shuffle music player
On Mon, Sep 08, 2003 at 11:49:57AM -0500, John Buttery wrote: > * Brian Nelson <[EMAIL PROTECTED]> [2003-09-08 07:19:08 -0700]: > > That is certainly not all that matters. If every script anyone tried > > to write was included in Debian, Debian would collapse under its own > > weight. > > How? I mean, as long as the package was maintained. Although, if > you're talking about bandwidth and disk space expenses to the mirror > sponsors, then you do have a point there. The phrase "collapse under > its own weight" suggests to me, though, that you're talking about > something else, ie something about coordinating things regardless of > data storage logistics. I guess I'm not really an expert on how the > "Debian machine" ticks internally, but it seems like whatever system has > already scaled to 8-9000 packages should scale the same way up to 30K or > 40K packages? You are aware that some mirror are already on the very limit of not having enough place on their 100Go partition for the debian archives and were asking for near term solutions. That said, a small (arch: all probably) script should probably not even be visible in the archive. Friendly, Sven Luther
Re: randomplay: command-line shuffle music player
On Mon, Sep 08, 2003 at 09:45:37PM +0200, Adam Borowski wrote: > On Mon, 8 Sep 2003, Sven Luther wrote: > > On Mon, Sep 08, 2003 at 05:37:40AM +0200, Adam Borowski wrote: > > > On Sun, 7 Sep 2003, Adam Kessel wrote: > > > > I've written a fairly simple command-line shuffle music file player. > > > > Despite its simplicity, I find it quite handy, and I don't think there's > > > > any other package out there (in Debian or not) that does quite what it > > > > does. The main feature is that it keeps track of which files have been > > > > played across sessions; but it also has some nice ways to play your > > > > files > > > > quickly from the command line. It's definitely a "scratch an itch" type > > > > program. > > > Been there... my version is -shuffle +recursion. > > There is quark also, which is a client/server design with both command > > line and gnome system tray (err notification area that is now, maybe it > > even works with any freedesktop notification areas) clients. It does > > random and loop playing, but nothing much more, and is maybe a bit > > feable/immature on handling playlists. Well, you can provide a simple > > textual playlist file, or hand append files, but that's it. > In other words, it's one of these bulky graphical things you click on and > you can't do anything that it's author didn't think of... however the > ability to "hand append files" gives us at least some hope. You didn't read what i wrote, did you ? It is a client/server design, with a server named quark which plays the music, and has nothing whatsoever to do with any graphical thing. There are two client, one being the command line charm-quark, which allow you to communicate with this server with a propper communication protocol, and allow you to play songs, set some flags, play a playlist and so on. There is also a graphical client which does the same. > What I want, is something that can take a list of files and passes all > "mp3"s to "mpg123", all "ogg"s to "ogg123", all "mid"s to "timidity" and > all "wav"s to "play", ignoring the rest, all while preserving the order. Ok, this is something else, i agree, altough i question the utility of such a design, especially in the face of the fact that mostly the sound device can be opened only once. Also it is contrary to the idea of having a library which can play lot of different song types, instead of many programs, but i guess it is only a different way of handling this. > How do I produce the list, it's my business. It usually comes from "find" > or from the shell, like: > find|bogosort|xargs 123 # shuffle > 123 ~/mp3/Dimmu\ Borgir\For\ All\ Tid\* # a LP in order > 123 ~/mp3/some_single_file.mp3 > My version defaults to `find` starting from the current directory when > it's run without any arguments, but it would be equally good to make it so > when a filename received is a directory as opposed to a regular file the > script does a recursive search. Ok, same as the playlist quark can handle then. > > It also doesn't die when you relaunch the X server, which is rather nice > > when doing X driver work :))) > Why won't you use one of the real text consoles then? Why should i ? > You see, I don't use X unless I have to, but if you're already in X, it's > faster to just use xmms and its playlist. Your situation is so rare that Because xmms is too complicated for my use. I just want something to play songs and don't have to bother about it. Which is easily accesible from the gnome panel, without being too intrusive. Quark is especifically designed be the contrary of what xmms and his heavy interface is, its author using the 'Anti-GUI' term for it. > you can do what I and other X-haters do and use a text-based program on > another console. Sure sure, you can do that too, it is more inconvenient, and as my X driver is not yet accelerated, and uses the shadowfb, it takes ages to switch to console, which is not nice. Friendly, Sven Luther
Re: [OT] Virus W32/Swen@MM spreading...
On Fri, Sep 19, 2003 at 05:01:25PM +0200, Thomas -Balu- Walter wrote: > Okay guys, this is fairly offtopic, but I keep getting _massive_ amounts > of email to my debian-lists address [EMAIL PROTECTED] which makes me > believe, that many subscribers here are infected with W32/[EMAIL PROTECTED]: > > http://securityresponse.symantec.com/avcenter/venc/data/[EMAIL PROTECTED] > http://vil.nai.com/vil/content/v_100662.htm > > Please get your machines offline and scan them with a recent > Virus-Scanner. I'd suggest to boot to Linux and remove all Windows > partitions anyway, but some of you still seem to need/use it ;) BTW, the attachement is of md5sum b09e26c292759d654633d3c8ed00d18d. Anyone know of an easy way to filter out emails where a given attachement has a particular md5sum ? My tries with uudeview, grep, sed and med5sum where not that much of a success. Friendly, Sven Luther
gcc 3.3 and __func__ ...
Hello,
I have some code that was using :
printf (__func__ "Message", ...);
This doesn't build anymore with gcc 3.x, since __func__ is treated as a
variable, not a string literal.
What would be the best way of working around this ? Replacing all these
constructs with :
printf ("%sMessage", __func__, ...);
Works, but seems a bit ugly, and there are _lots_ of those lines.
Is there a compiler switch to consider __func__ as string literal or
something such ?
Naturally, using 2.95 kinda works, but i don't think this is a good
idea.
Thanks for your help.
Friendly,
Sven Luther
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 12:26:42PM -0400, Matt Zimmerman wrote:
> On Thu, Oct 16, 2003 at 05:59:43PM +0200, Sven Luther wrote:
>
> > I have some code that was using :
> >
> > printf (__func__ "Message", ...);
> >
> > This doesn't build anymore with gcc 3.x, since __func__ is treated as a
> > variable, not a string literal.
> >
> > What would be the best way of working around this ? Replacing all these
> > constructs with :
> >
> > printf ("%sMessage", __func__, ...);
> >
> > Works, but seems a bit ugly, and there are _lots_ of those lines.
> >
> > Is there a compiler switch to consider __func__ as string literal or
> > something such ?
>
> That behaviour is mandated by ISO C99, so even if it were possible to
> override it, the code needs to be fixed.
Yes, seemed so to me.
> The gcc-specific __FUNCTION__ and __PRETTY_FUNCTION__ are string literals,
Well, apparently no more in gcc 3.4.
> like what is expected here, except in C++, where they act like __func__.
> See "(gcc)Function Names". It'd really be best to adapt it to use __func__
> properly, since this is a standard which will be honored by other compilers.
What would be the best way to adapt it ? Use the
printf ("%sMessage", __func__, ...);
form ?
Thanks for your reply,
Friendly,
Sven Luther
Re: Debian Installer sends acknoledgements to uploader, doesn't it?
On Wed, Oct 22, 2003 at 01:23:19AM +0100, Colin Watson wrote: > On Wed, Oct 22, 2003 at 09:53:45AM +1000, Martin Michlmayr wrote: > > * Colin Watson <[EMAIL PROTECTED]> [2003-10-21 19:15]: > > > Boggle. Your sponsor just signed something you'd built? Sponsors are > > > supposed to build packages themselves, not accept binaries from > > > elsewhere. > > > > He runs a m68k buildd, so building his packages again kind of defeats > > the whole purpose... > > I'm not sure I'd ever considered the possibility of a non-developer > running a buildd properly. Perhaps somebody else could be the buildd > operator who does all the signing and uploading and Goswin could host > and maintain it? > > (Or maybe this is already the case and I've just misunderstood.) Or he could be made a DD, and all this discussion will be void. I have really came to know him only since the oldenburg meeting a bit less than a month ago, but i guess he would be no worse than our average DD, and he has sure done more work in this last month that our average DD does, especially on the debian-installer work. Friendly, Sven Luther
Re: Put a program in the gnome menu
On Thu, Nov 06, 2003 at 09:51:36AM +0100, Ottavio Campana wrote: > I'm developing some programs for my university. They're ready for being > packaged in debs and I have created an entry for them in the debian > menu. > > For we use gnome 2 I'd like to add the programs to the gnome menu, > without having to go through Debian menus -> Apps -> .. but I'd like to > create a new folder in the gnome menu and to put the programs there. Do > you know how to do it? In the same vein, i package two gnome panel applets (hardware-monitor & gnome-randr-applet). When gnome is launching, there are little icons in the splash screen, and one of the applets (hardware-monitor) doesn't show a little icon, only the small gnome foot used for icon-less applets. Any idea on how to add such a gnome splash screen icon ? Friendly, Sven Luther
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 03:07:59AM +0100, David Weinehall wrote: > [snip] > > Of course, UTF-8 whereever possible is a nice goal to strive after, > and I think that the debian-specific files are a good place to start. Would the place to start not be to make sure that every piece of debian supports it, and make it a release goal ? I doubt it is still time for sarge, but maybe for sarge+1 ? Friendly, Sven Luther
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 02:48:01PM +, Colin Watson wrote: > On Tue, Dec 16, 2003 at 01:40:35PM +0100, Sven Luther wrote: > > On Tue, Dec 16, 2003 at 03:07:59AM +0100, David Weinehall wrote: > > > Of course, UTF-8 whereever possible is a nice goal to strive after, > > > and I think that the debian-specific files are a good place to start. > > > > Would the place to start not be to make sure that every piece of debian > > supports it, and make it a release goal ? I doubt it is still time for > > sarge, but maybe for sarge+1 ? > > Depends how practical that is, I guess. For example, it's still unknown > when groff will support it properly (as in UTF-8 input; UTF-8 output is > more or less OK now), since nobody's yet done the work and it's Hard. I Yep, noticed that also, man simply removes the - from manpages, which is a pain, as they get used pretty much in manpages. > don't think we'd want either to delay sarge+1 by an arbitrary amount of > time until that happens or to drop man pages from the distribution ... Then, do not say that we should allow UTF-8 usage in files, if it is clearly not going to be supported. Come one, sarge+1 is probably more than 2 years away, if we cannot support UTF-8 by then, something is seriously wrong. Friendly, Sven Luther
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 05:22:36PM +, Colin Watson wrote:
> On Tue, Dec 16, 2003 at 04:38:23PM +0100, Sven Luther wrote:
> > On Tue, Dec 16, 2003 at 02:48:01PM +, Colin Watson wrote:
> > > Depends how practical that is, I guess. For example, it's still unknown
> > > when groff will support it properly (as in UTF-8 input; UTF-8 output is
> > > more or less OK now), since nobody's yet done the work and it's Hard. I
> >
> > Yep, noticed that also, man simply removes the - from manpages, which is
> > a pain, as they get used pretty much in manpages.
>
> See /etc/groff/{man,mdoc}.local. (And no, groff doesn't remove "-", it
Ok, will look.
> renders it as the Unicode HYPHEN character.)
Well, i most definitively cannot see it, and i am using a UTF-8 aware
xterm (uxterm if i am not wrong).
> > > don't think we'd want either to delay sarge+1 by an arbitrary amount of
> > > time until that happens or to drop man pages from the distribution ...
> >
> > Then, do not say that we should allow UTF-8 usage in files, if it is
> > clearly not going to be supported. Come one, sarge+1 is probably more
> > than 2 years away, if we cannot support UTF-8 by then, something is
> > seriously wrong.
>
> What I'm saying is that we depend on upstreams to make significant
> design changes, and that's something we have little control over, so it
> shouldn't be a release goal as such. Some changes can be made in Debian,
> but I'm not sure radical design shifts with compatibility implications
> qualify.
It would assuredly not be the first time that we fork upstream to fit
our goals and needs.
Friendly,
Sven Luther
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 07:44:35PM +, Colin Watson wrote:
> On Tue, Dec 16, 2003 at 07:00:26PM +0100, Sven Luther wrote:
> > On Tue, Dec 16, 2003 at 05:22:36PM +, Colin Watson wrote:
> > > On Tue, Dec 16, 2003 at 04:38:23PM +0100, Sven Luther wrote:
> > > > Yep, noticed that also, man simply removes the - from manpages,
> > > > which is a pain, as they get used pretty much in manpages.
> > >
> > > See /etc/groff/{man,mdoc}.local. (And no, groff doesn't remove "-", it
> >
> > Ok, will look.
> >
> > > renders it as the Unicode HYPHEN character.)
> >
> > Well, i most definitively cannot see it, and i am using a UTF-8 aware
> > xterm (uxterm if i am not wrong).
>
> Try:
>
> printf - | groff -Tutf8 | grep .
>
> then:
>
> printf - | groff -Tutf8 | grep . | od -tx1
>
> I've seen a similar report before, but IIRC it turned out to be a
> terminal/font problem.
I get an invisible - for the first one, and then :
e2 80 90 0a
0004
for the second one.
I choose fr_FR.UTF8 or something such in gnome GDM.
Friendly,
Sven Luther
Re: UTF-8 in copyright files?
On Wed, Dec 17, 2003 at 12:45:41AM -0200, Henrique de Moraes Holschuh wrote: > On Tue, 16 Dec 2003, Sven Luther wrote: > > I choose fr_FR.UTF8 or something such in gnome GDM. > > And it IS just like that in your /etc/locale.gen as well? fr_FR only won't > do. I have many locales there, en_IN UTF8 en_US ISO-8859-1 en_US.ISO-8859-15 ISO-8859-15 en_US.UTF8 UTF8 fr_FR ISO-8859-1 fr_FR.UTF8 UTF8 [EMAIL PROTECTED] UTF8 [EMAIL PROTECTED] ISO-8859-15 Should be ok, no ? Friendly, Sven Luther
Re: UTF-8 in copyright files?
On Wed, Dec 17, 2003 at 01:48:41AM +, Colin Watson wrote: > On Tue, Dec 16, 2003 at 09:23:01PM +0100, Sven Luther wrote: > > On Tue, Dec 16, 2003 at 07:44:35PM +, Colin Watson wrote: > > > On Tue, Dec 16, 2003 at 07:00:26PM +0100, Sven Luther wrote: > > > > Well, i most definitively cannot see it, and i am using a UTF-8 aware > > > > xterm (uxterm if i am not wrong). > > > > > > Try: > > > > > > printf - | groff -Tutf8 | grep . > > > > > > then: > > > > > > printf - | groff -Tutf8 | grep . | od -tx1 > > > > > > I've seen a similar report before, but IIRC it turned out to be a > > > terminal/font problem. > > > > I get an invisible - for the first one, and then : > > > > e2 80 90 0a > > 0004 > > > > for the second one. > > groff is behaving correctly, then, which means that you must be using a > font which doesn't have the U+2010 HYPHEN glyph. Fix that ... > > I use 'pterm -fn > -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1' as a > Unicode terminal. Yep, i guess this would work, but i think that this kind of things should be the default, if we are counseling people to write stuff in UTF8 in debian related things. Other problems is sshing from a non UTF terminal, but then luit helps, but there is not really much we can do there, no ? Friendly, Sven Luther
how to test for architecture in perl base pre/postinst scripts ?
Hello, I am searching to test for architecture in perl written pre/post inst scripts. I am not perl fluetn though, and i don't know what is the correct way of querying for architecture in those scripts. Sure i could parse the uname output or something such, but maybe there is already a prefered way of doing this ? Thanks for your help. Friendly, Sven Luther
Re: how to test for architecture in perl base pre/postinst scripts ?
On Mon, Feb 23, 2004 at 06:42:08PM +0100, Jochen Friedrich wrote: > Hi Sven, > > > I am searching to test for architecture in perl written pre/post inst > > scripts. I am not perl fluetn though, and i don't know what is the > > correct way of querying for architecture in those scripts. Sure i could > > parse the uname output or something such, but maybe there is already a > > prefered way of doing this ? > > You could use dpkg-architecture for this. Yeah, seems reasonable, now i only need to find out how to call it from perl. I hope that this is available when using debootstrap, since it is needed in base-install on debian-installer. Friendly, Sven Luther
Re: how to test for architecture in perl base pre/postinst scripts ?
On Mon, Feb 23, 2004 at 11:20:10AM -0800, Don Armstrong wrote: > On Mon, 23 Feb 2004, Sven Luther wrote: > > Yeah, seems reasonable, now i only need to find out how to call it > > from perl. > > %arch = split /[=\n]/, qx(dpkg-architecture) or die q(dpkg-architecture > failed); > > should do nicely. [dpkg-architecture should exist once dpkg has been > unpacked...] Mmm, the following was recomended to me : # Get the architecture we are running on, to set silent_modules on powerpc. open(FILE, "dpkg-architecture -qDEB_HOST_ARCH |"); undef $/; $arch = ; close(FILE); As said, i am no perl expert, is this better or worse than your solution ? Friendly, Sven Luther
Re: dependencies issue
On Thu, Feb 26, 2004 at 10:50:44PM +0100, Arvind Autar wrote: > Hi, > > I'm to package something that doesn't have a ./configure . > What ways are there to find out the dependencies ? > > I tried to use " dpkg-depcheck -b debian/rules build ", but that didn't > work well. Build it in a pbuilder, and add everything it is missing. Or alternatively in a clean chroot, is actually faster. look at the debootstrap manpage for info on how to build one. Friendly, Sven Luther
Re: RFS: mpd - Music Player Daemon, and clients
On Sat, Mar 27, 2004 at 02:54:36PM -0800, Eric Wong wrote: > Hello, > > I've been maintaining Debian packages for the Music Player Daemon > project for the past month or so, and have finally decided that they're > ready for sponsorship and upload into Debian proper. I have the full > support of the upstream authors, and have myself contributed to the > upstream development of mpc and mpd. BTW, how does it compare to quark, which also has the same client/server design, and which i package. Friendly, Sven Luther
Re: Unicode conversion goals for Sarge (was Re: debian-changelog-file-uses-obsolete-national-charset)
On Wed, Mar 31, 2004 at 03:06:37PM +0100, Colin Watson wrote: > I think UTF-8 is the future, use it fairly extensively myself, and will > continue to work towards having it everywhere, but let's not make the > mistake Red Hat made of pushing UTF-8 beyond the current capabilities of > our software. The main problem being that gnome insist of everything being UTF-8 by default. So will the broken_filename variable be set per default for sarge, and we will forgo UTF-8 support ? And we could then make an official announcement that sarge+1 should be officially full UTF-8, and that this be a release criteria for sarge+1 ? Friendly, Sven Luther
Re: motion - please do a sponsored upload for me (new revision with debconf fix)
On Sat, Aug 14, 2004 at 09:18:12AM +0200, Frederik Dannemare wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Saturday 14 August 2004 03:16, Wesley J Landaker wrote: > > On Friday 13 August 2004 19:06, Adam Majer wrote: > > > Frederik Dannemare wrote: > > > > Hi, > > > > > > > > I was hoping that my previous sponsor of motion would have the > > > > time this week to do a new upload which has a couple of very > > > > small fixes, but unfortunately I haven't heard from him yet, so > > > > I'm really, really > > > > > > I'll look at it and upload within an hour or so (unless there are > > > problems). > > > > I saw a copy of Frederik's same e-mail in debian-mentors earlier > > today and already checked it over and uploaded. My only concern was > > that it's not quite up-to-date with the latest upstream (3.1.14 vs > > 3.1.16), but since it's a bugfix, I went ahead and sponsored. > > When I adopted the package, I chose to update from 3.0.6 to 3.1.14, and > not 3.1.15/3.1.16, because I personally feel 3.1.14 is the most stable > of them. .15 had a lot of problems, and although .16 fixed much of > this, I still feel 3.1.14 is the better choice for the sarge release. > > Many thanks for the upload, Wesley. I really appreciate it. And thank > you, Adam, for once again offering to help me with an upload. BTW, what is the deal with motion and 2.6 kernels ? I am under the understanding that it requires the videoloop or whatever module, which is not only abandoned upstream, but also not yet ported to 2.6 kernels. Friendly, Sven Luther
Re: motion, 2.6, and v4l loopback device [WAS Re: motion - please do a sponsored upload for me (new revision with debconf fix)]
On Wed, Aug 25, 2004 at 01:48:26AM +0200, Frederik Dannemare wrote: > > BTW, what is the deal with motion and 2.6 kernels ? I am under the > > understanding that it requires the videoloop or whatever module, > > which is not only abandoned upstream, but also not yet ported to 2.6 > > kernels. > > I have been using motion and 2.6 without the v4l loopback device. I Ok. > don't know much about it, but I think it was initially developed for > debugging motion in real-time or something like that. I have been helping someone, who has a customer who is using linux with a set of surveillance cameras. I think they use the vloopback device to have more than one app access the video device, namely motion and then vlc for video streaming server. Friendly, Sven Luther
Re: Problem regarding copyright of Moscow ML...
On Mon, Nov 30, 1998 at 11:55:15PM +0100, Torsten Landschoff wrote: > Hi :-) > > I have a little problem with "my" package Moscow ML - the following comes from > copyrght.cl, which really is from CAML Light (which Moscow ML is based > upon...): > > -- > b- Reproduction of the software: > > INRIA grants any user of the software the right to reproduce it so as > to circulate it in accordance with the same purposes and conditions as > those defined at point a- above. Any copy of the software and/or relevant > documentation must comprise reference to the ownership of INRIA and > the present file. > > >The user undertakes not to carry out any paying distribution of the > >software. However, he is authorized to bill any person or body for the > >cost of reproduction of said software. As regards any other type of > distribution, the user undertakes to apply to obtain the express > approval of INRIA. > -- > > What should I do next? I think I'd try to contact the upstream maintainers to > change this part of the copyright. But this file is from Moscow ML - do I have > to contact the maintainer of Moscow ML to if INRIA removes this section from > the copyright file? It shoudl go into non-free, at least i think so. i don't think you will have any luck in convincing the INRIA people to change their licence, altough you could try. Myself i have been speaking with them about the ocaml package, who has a almost dfsg compliant license, patch only, but no binaries of modificated work permited. So we can not even distribut debian package of it. the author (or at least one of them) said that he didn't considered debianizing as modification of the package, and i was told that with a notice from them in debian/copyright it should be ok to distribute it, but it should still go into non free. Or did i misunderstood something. I think they don't want someone using part of their virtual machine into a JVM without some money going back to them, and since Java is quite hot right now, i understand them quite well. Friendly, Sven LUTHER
pgp signing ...
Hello, ... i became debian developper recently, and am using a pgp id in the form of my name, followed by my private email address. now i actually began to build packages, and i figured it would be best to put my debian email address in the maintainer field instead of my private one. so i did [EMAIL PROTECTED] cd package-version dh_make and promptly i had a source package that i modified as needed. but then, when i tried to build the package with dpkg-buildpackage, pgp complained about not finding Sven LUTHER <[EMAIL PROTECTED]> which is normal since i used my private address when building my pgp secret key ... so now i have a few questions : * is there a dpkg-buildpackage option to give the pgp id to use ? * is it possible to change the pgp id in the keyring ? * or should i ask the pgp-stuff maintainer of debian to use a new pgp-id that i will generate in the form of Sven LUTHER <[EMAIL PROTECTED]>, to avaoid problems in the future ? Also is there somewhere a debian&pgp manual, howto or faq ? actually i think all this would easier if we had a program that did authentification that was special for debian, and that integrates with dpkg and friends better than that pgp does. also this would protect me from my governement who is considering me a dangerous terrorist because i used pgp to sign a debian package ... Friendly, Sven LUTHER
non-free, contrib or main ?
Hello, ... i am currently packaging mlgtk, the Ocaml bindings for Gtk+. the mlgtk sources are under the LGPL, so they should go into main, same as all the gtk stuff. but ocaml is in non-free (well actually it is just on my harddrive, because i am still asking autorisation from the autors to make distribute binary modifications, since the licence allow only distribution of modified works as patches to the source, but no binaries ...). so does the mlgtk package now go into contrib (if it depends on ocaml) or main (if you consider that it is only bindings to glib/gdk/gtk) actually the mlgtk only contains a C library, and a few ocaml libraries, that you have to link with your ocaml programs. You can install them without ocaml being present, but not use them (after all they are only bindings). And after all, they are binding to gtk, which definitively is in main. Friendly, Sven LUTHER
Re: OCAML Debian package
On Mon, Dec 14, 1998 at 08:45:10PM +0100, Fernando Sanchez wrote: > On Mon, 14 Dec 1998, Kristoffer Rose wrote: > > > This is a good idea but you should of course contact the maintainer of the > > existing OCAML package, version 1.05-2, before going further! It is > > Christophe Le Bars <[EMAIL PROTECTED]>. Allow some weeks for the reply. > > I've already contacted him and got his blessing. I wouldn't have posted this > comment about ocaml package if I had not. Hello, ... i have been wanting to package ocaml for some time now, i contacted the author about the license, and let's say we have to discuss more about it, what is the best place for discution about the ocaml license ? debian-license, debian-devel ? > > He said he didn't release more versions of ocaml after 1.05-2 because of > licensing problems and that I should contact Objective Caml developer for > permission. I contacted ocaml development team and they said there was no > problem at all, it's fine to make a Debian package for ocaml 2.01. > > > documented, etc. Maybe the system is so different that it should have a > > new name so the two can coexist? There may be many issues to discuss! > > No, no. Ocaml new versions only imply bugfixes and new functions etc. > Binaries compiled are the same and code that runs on 1.05 will run on 2.01. > I think there are enough improvements in version 2.01 to have to release a > debian package for it. > I think there was some serious new functionalities between ocaml1.07 and ocaml 2.00, but i don't remember exactly. ocaml1.05 is quite old, june-july 96 i think, almost two years now, and it was at that time that the license changed, i think it was supposed to become more non-free, don't know the old license, but the new one is almost DFSG free, the only problem is that they don't allow binaries of modified works, but i don't know if they will want to change that, but i think we could come with a proposal on this topic to them. > > Also you should be ready to prepare your package with whatever is necessary > > to compile it on non-i386 systems if this is at all possible. > > I think I can prepare sparc and maybe m68k package too, but there is no > difference from compiling in i386 at all. I will only release packages for ppc myself, not i386. The packages should compile without problems, but i had difficulties with the ocaml debugger on debian/ppc it is configured ok, but don't compile. I still don't solved that. And remember for there is no native code compiler for linux/m68k, so don't put the line make opt and friends in the debian/rules for m68k. I think a n inclusion of the config file and some conditional rules will do the job just fine. > > > pressure up on INRIA to change over to the GPL since there is a strong > > movement inside INRIA to do this with Bernard Lang among its chief > > advocates.) > > I do agree. I will ask Xavier Leroy about it, maybe they're chaging their > mind (?) The problem i see is that they don't want it to become non-free, and i think this is ok for this package, altough i think that ocaml could be more used if it would become really non-free. lets start a discution with them about it, but keep in mind that the opinion on releasing programs non-free is ok as long as the package is not a big inovation, at least i read that, be it from the FSF or RMS, i don't remember. And ocaml plays in the same area as most JVM stuff, and they are smaller as most player there, so they need some protection. > Regards, > > Fernando Sanchez Ok, Fernando, which one of us package it then ? I am already debian developper, so the package could go in nextly. i will also package mlgtk, an ocaml binding to gtk+, but it is still a bit alpha software. Right now i am not maintaining any other packages, and i am writhing my phd thesis on camlous stuff, so i will need quite recent packages of it ... if you do it, you could also add the mli2html patch, it is quite nice for doing some documentation ... Friendly, Sven LUTHER
Re: Chaning a new package still in incoming?
On Wed, May 05, 1999 at 09:26:14AM -0400, Peter S Galbraith wrote: > > Roderick Schertler wrote: > > > On Mon, 26 Apr 1999 16:20:02 -0400, Peter S Galbraith <[EMAIL PROTECTED] > > ca> said: > > > > > > I _just_ found a little bug and would like to replace with -1 package > > > with a new one with the same name (but new changes file with new > > > checksum). Can I do that? Or Must I upload a version -2 ? > > > > You should use a new version number if it was in incoming for more than > > a minute or two, because people download packages from incoming and its > > mirrors. > > > > -- > > Roderick Schertler > > [EMAIL PROTECTED] > > Good point. It's too late now, unless I upload a new -2 version > identical to the changed -1 version. a -1.1 will do also, altough dotted debian versions are ususally reserved for NMUs. or you could do a -1.updated or or something like that ... Friendly, Sven LUTHER
gmp2 ????
Hello, ... i plan to package a program called mozart, that uses gmp version 2 and searches his includes under /usr/include/gmp.h and his libs under /usr/lib/libgmp.so but since both gmp1 and gmp2 are supported under debian, gmp2 stuff are in /usr/include/gmp2/gmp.h, and the libraries are/usr/lib/libgmp2.so How do i tell the autostuff how to search for the library in the right place ? Friendly, Sven LUTHER
Re: Building from a source package
On Fri, May 14, 1999 at 09:21:46PM +1200, Alex King wrote: > I have a feeling this may be a silly question, but here goes... > > How do I build a binary package from a debian source package? > > I have downloaded the source package, and unpacked it with dpkg-source, but > how do I make the .deb from it? > > I need to recompile the package (samba) with a compile time setting changed > (MAX_OPEN_CONNECTIONS). This is really urgent, any tips greatly appreciated. Two ways of doing it : 1. dpkg-source -x package.dsc 2. cd to package-version 3. dpkg-buildoackage -rsudo (or -rfakeroot, or whatever you use to gain root privilege, you could even do it as root, but it is not recomended). add the flags -us -uc to not sign the package if you are not developper (which i guess you are not). second way : use the package dbuild, very nice, install it and then run : dbuild package.dsc and it will build the package for you. There are certain option you have to set so the package don't get signed, but i don't remember them so check the man page. you can also p[ut them in a .rc file, so you don't have to rewrite them each time. Friendly, Sven LUTHER
Re: arch-specific binary-only rebuild
On Thu, Oct 21, 1999 at 10:31:06AM -0400, Peter S Galbraith wrote: > > Hamish Moffatt wrote: > > > On Tue, Oct 19, 1999 at 12:17:53PM -0400, Peter S Galbraith wrote: > > > The changelog will not appear in all the binary packages produced > > > since I won't be uploading a new diff.gz to propagate a new > > > changelog. > > > > If it's a new binary version, it should have source to go with it. > > And you can't reupload the binary package without a new version number. > > No, it's a recompile-only of the source package. > > For instance, ``foo_1.3-1'' would be numbered ``foo_1.3-1.0.1''. > No new .diff.gz is uploaded. No, i don't think so, ... What if the person uploading the binary package did have to make some change to the diff.gz in order of the package to be uploaded, and later is no more joingable for whatever reason, There is no way of rebuilding the package without having to make those changes again. One solution would be to have the 1.0 to 1.0.1 diffs send to the BTS against the package, instead of making it available as source package. This way the sources of everything will be available, but we don't force rebuilding of packages for the other arches, ... Friendly, Sven LUTHER
dh_installinfo ?
Hello, ... i received a bug against one of my packages saying that the .info documentation is not available by info directly, and that i should add a prerm and postinst calling install-info. Now, in debian/rules i do a : dh_installinfo ocaml.info/* Which should take all appropriate steps to install the stuff contained in ocaml.info as correct info files, including generating the correct prerm/postinst instruction. Am i correct in thinking that these is a dh_installinfo bug or not ? Please respond to me directly, as i am not subscribed to debian-mentors Friendly, Sven LUTHER
Re: dh_installinfo ?
On Tue, Jan 25, 2000 at 12:19:36PM -0800, Sean 'Shaleh' Perry wrote: > > On 25-Jan-2000 Sven LUTHER wrote: > > Hello, ... > > > > i received a bug against one of my packages saying that the .info > > documentation is not available by info directly, and that i should add a > > prerm and postinst calling install-info. > > > > Now, in debian/rules i do a : > > > > dh_installinfo ocaml.info/* > > > > only if you place #DEBHELPER# in your scripts. otherwise debhelper assumes > you > are doing it yourself. Take a look in /var/lib/dpkg/info/.postinst > and see if the calls are there. Ok, thanks will do it. Friendlym Sven LUTHER
Re: dh_installinfo ?
On Tue, Jan 25, 2000 at 12:19:36PM -0800, Sean 'Shaleh' Perry wrote: > > On 25-Jan-2000 Sven LUTHER wrote: > > Hello, ... > > > > i received a bug against one of my packages saying that the .info > > documentation is not available by info directly, and that i should add a > > prerm and postinst calling install-info. > > > > Now, in debian/rules i do a : > > > > dh_installinfo ocaml.info/* > > > > only if you place #DEBHELPER# in your scripts. otherwise debhelper assumes > you > are doing it yourself. Take a look in /var/lib/dpkg/info/.postinst > and see if the calls are there. Err, ... no when i add #DEBHELPER#, it adds the following stuff only : # Automatically added by dh_installdocs if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/ocaml-doc ]; then rm -f /usr/doc/ocaml-doc fi # End automatically added section Nothing gets installed by installinfo. Guess i will have to do it by hand. By the way, why does this package says : Selecting previously deselected package ocaml-doc. (Reading database ... 61386 files and directories currently installed.) Preparing to replace ocaml-doc 2.04-1 (using ocaml-doc_2.04-1_all.deb) ... dpkg (subprocess): unable to execute old pre-removal script: Exec format error dpkg: warning - old pre-removal script returned error exit status 2 dpkg - trying script from the new package instead ... dpkg (subprocess): unable to execute new pre-removal script: No such file or directory dpkg: error processing ocaml-doc_2.04-1_all.deb (--install): subprocess new pre-removal script returned error exit status 2 dpkg (subprocess): unable to execute post-installation script: Exec format error dpkg: error while cleaning up: subprocess post-installation script returned error exit status 2 Errors were encountered while processing: ocaml-doc_2.04-1_all.deb What is the meaning of exec format error ? And how do i fix it ? Friendly, Sven LUTHER
multi binaries packages.
Hello, ... while working on apus boot floppies, i had a problem with the amiga-fdisk packages, who uses libreadline, but i need a version of it without readline and ncurses for the boot floppies. So i modified the source, and added a define that enables readline support or not. Now, i want ot build two packages from it, the first amiga-fdisk should stay as before, and the seconf, amiga-fdisk-boot-floppies, should contain a second version of the executable, but recompiled without libreadline. I managed to produce both binaries, amiga-fdisk and amiga-fdisk-boot-floppies and added a package description in the control file. But both of the binaries absolutely want to go into the first packages, letting the second one empty. How do i tell the dpkg-build stuff to put the second file in the second package. Where can i find info on building multi binaries packages ? The packaging manual seems mute about it. Also if i want both executables to have the same name, how can i do this ? Friendly, Sven LUTHER
Sponsoring ...
Hello, ... I am sponsoring someone who wants to become a new maintainer, and well, i have checked the packages and there are ok. Now, what is the correct way for his packages to be uploaded into debian. I thought that buildiing and signing the package myself, and then uploading would be ok, but it is not working, dpkg-buildpackage is not happy with me providing a pgp key with -k. What is the best way of doing this, or alternatively, is there some doc somewhere explaining the finer aspects on sponsoring ? Friendly, Svne Luther
Re: Sponsoring ...
On Thu, Feb 15, 2001 at 06:03:10PM +0100, Adrian Bunk wrote: > On Thu, 15 Feb 2001, Sven LUTHER wrote: > > > Hello, ... > > Hi Sven, > > > I am sponsoring someone who wants to become a new maintainer, and well, i > > have > > checked the packages and there are ok. > > > > Now, what is the correct way for his packages to be uploaded into debian. > > > > I thought that buildiing and signing the package myself, and then uploading > > would be ok, but it is not working, dpkg-buildpackage is not happy with me > > providing a pgp key with -k. > > > > What is the best way of doing this, or alternatively, is there some doc > > somewhere explaining the finer aspects on sponsoring ? > > I do usually a: > > dpkg-buildpackage -us -uc -rfakeroot > cd .. > debsign -m'Adrian Bunk' fspanel_0.5-1_i386.changes > > and it works without any problems. thanks, will try it, ... i tried dpkg-buildpackage -rfakeroot -k"Sven LUTHER <[EMAIL PROTECTED]>" didn't work. Friendly, Sven Luther
Re: Sponsoring ...
On Thu, Feb 15, 2001 at 06:03:10PM +0100, Adrian Bunk wrote: > On Thu, 15 Feb 2001, Sven LUTHER wrote: > > > Hello, ... > > Hi Sven, > > > I am sponsoring someone who wants to become a new maintainer, and well, i > > have > > checked the packages and there are ok. > > > > Now, what is the correct way for his packages to be uploaded into debian. > > > > I thought that buildiing and signing the package myself, and then uploading > > would be ok, but it is not working, dpkg-buildpackage is not happy with me > > providing a pgp key with -k. > > > > What is the best way of doing this, or alternatively, is there some doc > > somewhere explaining the finer aspects on sponsoring ? > > I do usually a: > > dpkg-buildpackage -us -uc -rfakeroot > cd .. > debsign -m'Adrian Bunk' fspanel_0.5-1_i386.changes > > and it works without any problems. ... Args, ... it was because i am using a pgp key, and dpkg-buildpackage now uses a gpg key by default ... Friendly, Sven Luther
Question about testing and multi binaries ...
Hello, ... Say i have a multi-binary package, where one of the binaries does not get build for one of the arches (namely arm in this case). In this case, does the binaries that get build for all arches go into testing, and not the one which only gets build for some of them, or does all the binaries from the source package need to get build. Also, ... Is there any documentation on making multi binary packages ? I did search a lot around, and the only thing i found is the /usr/share/doc/debhelper/examples/rules.multi and multi2 files, which don't explain that much, and don't seem very readable ... Friendly, Sven Luther
Re: upstream new version
On Thu, Mar 29, 2001 at 10:48:49AM +0200, Stefano Zacchiroli wrote: > I've to build a new package against a new upstream version released by > the upstream author of one of my packages. > What I have to do to merge the new upstream version in the old one > debianized source tree ? > > Have I to unpack the new orig file and copy in it the old debian/ dir ? What i use to do is either : 1) just apply the diff file to the new package, chmod +x debian/rules, and check that nothing broke. and once in a while i also do : 2) do a dh_make on the new upstream source, and one by one migrate the stuff done for the previous version to the new version. this needs : -> applying all patches to the upstream source that are still needed. -> modifying debian/rules os that it does the same things as the previous version -> copy the debian/changelog file and add a new entry there. (is there a tool for doing this, or do i need to do it by hand like i currently do ?) -> copy the rest of the stuff, checking it is still needed/don't need to be modified. Friendly, Sven Luther
Re: Do I need 'unstable' for development?
On Wed, Mar 28, 2001 at 06:21:38PM +0200, T.Pospisek's MailLists wrote: > Nazdar, > > On Wed, 28 Mar 2001, Karel Gardas wrote: > > > I have one question regarding creating debian package. Do I need > > unstable debian for this task? I'm asking because I run potato now and (if > > possible) wouldn't like to switch to unstable. > > No, you definitively don't need to run unstable. It's better if you run > and develop on potato since then your package will also run there and > potato users will also be able to use your package. On the other side it's > always better for testing/unstable if people run them so, bugs get sorted > out... I think it is better to run unstable for building new packages, since : 1) no new package will get into potato anyway. 2) in running unstable, you help debugging it, which is required of developper in the later stages before a new release at least. 3) you will build your package against newer versions of the library. What does policy say about this exactly ? I think it is to use unstable, but i am not sure. Ideally, you would also have a chrooted stable environment, to build potato bug fixes or other such things. Or vice-versa ... Friendly, Sven Luther
Re: Question about testing and multi binaries ...
On Thu, Mar 29, 2001 at 11:23:23AM +0100, Colin Watson wrote: > Sven LUTHER <[EMAIL PROTECTED]> wrote: > >Say i have a multi-binary package, where one of the binaries does not get > >build for one of the arches (namely arm in this case). > > > >In this case, does the binaries that get build for all arches go into > >testing, > >and not the one which only gets build for some of them, or does all the > >binaries from the source package need to get build. > > All binaries need to be in sync on all architectures if they are > present, but they're allowed to be absent. The whole source package and > all binaries built from it are treated as a single unit for the purposes > of testing. : > If you've stopped building a binary package for one architecture, you > need to make sure the ftpmasters remove it from that architecture > (they'll probably notice themselves eventually, but filing a bug against > ftp.debian.org doesn't hurt) before it can get into testing. If it was > never built for that architecture, it doesn't matter. The problem is that i have a package, ocaml, which builds fine on every arch, save the native code version of 1 library that don't build on arm, because of a arm assembly code generation bug in upstream. I don't speak arm assembly language, and asm code generation is a rather difficult problem anyway. What i would like to do, is to split the package, and move the problematic library in its own package, that will not be build for arm until the problem is solved. Thus enabling the most part of ocaml to go into testing, as it is pretty stable anyway, and well, no other package uyse said library that i know of. Now, the other solution would be to disable arm native code generation, but i think this is most uncool, since it works for everything less this binary. I can also wait for upstream or the arm porters to fix this, but i would like best that ocaml goes into testing as soon as possible. > >Is there any documentation on making multi binary packages ? I did search a > >lot around, and the only thing i found is the > >/usr/share/doc/debhelper/examples/rules.multi and multi2 files, which don't > >explain that much, and don't seem very readable ... > > Looking at multi-binary packages by competent maintainers? There are so many multi-binaries package out there, and no documentation provided on how to do this. This is not a good thing. Friendly, Sven Luther
Re: upstream new version
On Thu, Mar 29, 2001 at 11:18:26AM +0100, Colin Watson wrote: > Sven LUTHER <[EMAIL PROTECTED]> wrote: > >What i use to do is either : > > > > 1) just apply the diff file to the new package, chmod +x debian/rules, and > > check that nothing broke. > > > >and once in a while i also do : > > > > 2) do a dh_make on the new upstream source, and one by one migrate the > > stuff > > done for the previous version to the new version. this needs : > > > >-> applying all patches to the upstream source that are still needed. > > > >-> modifying debian/rules os that it does the same things as the previous > >version > > > >-> copy the debian/changelog file and add a new entry there. (is there a > >tool for doing this, or do i need to do it by hand like i currently do ?) > > debchange (in the devscripts package). Thanks, didn't know about this. > >-> copy the rest of the stuff, checking it is still needed/don't need to > >be modified. > > Sounds like a large amount of extra error-prone work to me, although I > suppose running dh_make every so often is one way of keeping some bits Thought so also :))) Also will look at what dh_make will propose to me about about multi-binaries. > of policy vaguely up to date. I just use uscan/uupdate to unpack the new > source and try to apply the old diffs for me. Yes, but, ... Often the diffs are no more valid, or may apply, but will not work as expected. Also, since i send my patches also upstream, often the patches i have need no more to be applied, but will also not be detected to be already applied, since upstream may have changed them a bit. But then i guess it depends on the package, and as for me upstream provides good quality releases, and also accepts my patches, this is the easiest way for me. Friendly, Sven Luther
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 09:04:41AM -0400, Gopal Narayanan wrote: > On Tue, Apr 03, 2001 at 10:40:11AM +0200, Stefano Zacchiroli wrote: > > I've done the ocaml-findlib package with 'export DH_COMPAT=3' in the > > debian/rules. > > Some user report me the impossibility of build the same package from the > > sources on a debian potato. > > The compilation fail on dh_clean that right report an error. > > > > If I turn DH_COMPAT to 2 all compile correctly even on a potato. > > > > So, why (and when) I have to use DH_COMPAT=3 ? > > The version of debhelper on potato does not recognize > DH_COMPAT=3. That is a feature in the debhelper ver >3.0. That may > explain the problem of building on a potato machine. Is there any way of telling if we are building on a potato system or in a woody or unstable system in the rules file ? This could be handy for other kind of stuff also. Friendly, Sven Luther
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 03:16:57PM +0200, Ivo Timmermans wrote: > Sven LUTHER wrote: > > On Tue, Apr 03, 2001 at 09:04:41AM -0400, Gopal Narayanan wrote: > > > On Tue, Apr 03, 2001 at 10:40:11AM +0200, Stefano Zacchiroli wrote: > > > > I've done the ocaml-findlib package with 'export DH_COMPAT=3' in the > > > > debian/rules. > > > > > > The version of debhelper on potato does not recognize > > > DH_COMPAT=3. That is a feature in the debhelper ver >3.0. That may > > > explain the problem of building on a potato machine. > > > > Is there any way of telling if we are building on a potato system or in a > > woody or unstable system in the rules file ? This could be handy for other > > kind of stuff also. > > cat /etc/debian_version yes, this one could do ... > dh_testversion erm, ... this is told to be depredated (or whatever is the correct writting of this word) by the build dependency stuff. It also don't seems to do anything on a unstable system. > or build dependencies on debhelper (>>3.0) Yes, but since i want ot build the package on both potato and unstable, this will not help. Maybe there could be two Build-depends line, one for potato and one for unstable also, or something such, but then potato apt don't support build depends yet, so this may be moot. Anyway, the first solution would be the best one in this case. Friendly, Sven Luther > > > -- > Ivo Timmermans > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 04:25:01PM +0200, Stefano Zacchiroli wrote: > On Tue, Apr 03, 2001 at 09:04:41AM -0400, Gopal Narayanan wrote: > > The version of debhelper on potato does not recognize > > DH_COMPAT=3. That is a feature in the debhelper ver >3.0. That may > > explain the problem of building on a potato machine. > > If i want to do a package that can be compiled even on a potato machine, > what I have to do ? What about testing the content of /etc/debian_version, and if it is potato, then set DH_COMPAT to 2 ? (the propper sh stuff is left as an excercice :))) Friendly, Sven Luther
Re: Undocumented binary
On Tue, Apr 03, 2001 at 04:28:37PM +0200, Dennis Schoen wrote: > On Tue, Apr 03, 2001 at 09:49:41AM -0400, Steve M. Robbins wrote: > > On Tue, Apr 03, 2001 at 03:23:59PM +0200, Karel Gardas wrote: > > > > > > Hi, > > > > > > I have many binaries compiled from my source package and I would like to > > > attach 'undocumented' man page to these files. How can I do it? > > > > Aigh, no, please don't do that! > > Those drive me crazy!! > > > > The undocumented page provides no more information than > > "No manual entry for foo" (but the former is much longer to > > read). What is the point? > policy :) Does the policy not say that all binaries should have a manpage. having a manpage saying that there is no manpage is the same as having non, and i think it is not in the spirit of the policy. Maybe all manpage needing binaries could be listed somewhere, and we could have a manpage writing task ? Friendly, Sven Luther
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 09:40:43PM +0200, Ivo Timmermans wrote: > Sven LUTHER wrote: > > > or build dependencies on debhelper (>>3.0) > > > > Yes, but since i want ot build the package on both potato and unstable, this > > will not help. > > Why exactly? It's not a crime to create two separate packages; one > for stable and one for unstable. You can change the build > dependencies to match the distribution. Well, the idea is to have only one package for both, this make things simpler, create less work for me, and should be more error proof in general. Anyway, forking a package for 2 lines difference in the debian/rules file, and different build-depends don't seem worth it for me. Friendly, Sven Luther
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 01:17:06PM +0100, Julian Gilbey wrote: > On Wed, Apr 04, 2001 at 07:44:34AM +0200, Sven LUTHER wrote: > > > Why exactly? It's not a crime to create two separate packages; one > > > for stable and one for unstable. You can change the build > > > dependencies to match the distribution. > > > > Well, the idea is to have only one package for both, this make things > > simpler, > > create less work for me, and should be more error proof in general. > > > > Anyway, forking a package for 2 lines difference in the debian/rules file, > > and > > different build-depends don't seem worth it for me. > > So it'll potentially create different binaries with the same version > number on the different platforms. Hmm. Why not just go with the > potato version? It should work fine on unstable. I don't package for potato, only for unstable. The version in potato is very old, and upstream did 2 releases since then (1 major and 1 minor). The reason for this question, was that someone wanted to build unofficial potato packages out of my source package for unstable. It caused some problems because i was depending on tcl/tk 8.3, while potato only has tcl/tk 8.2. Also, the package configure script did check for tcl.h to determine the version of tcl/tk installed on the system, and this file got moved from the potato version of tcl/tk (both all 8.0 forks and 8.2) (/usr/include/tcl.h) and the newer versions of tcl/tk for unstable (well 8.2 and 8.3, not 8.0, which conserve the old location). (/usr/include/tcl8.[23]/tcl.h). Now i solved this by fixing the upstream configure script and providing upstream with my patch, but it could have been nice also to provide a way to tell the package that you are under a potato system, or unstable/woody system, for this, and to build-depend on the correct tcl/tk. Notice that this is not so much a problem for potato, since apt in potato don't support build depends, but in the forthcoming woody release, apt will be able to support build depends, so this could cause problems. Friendly, Sven Luther
Re: Python script
On Wed, Apr 04, 2001 at 01:02:56PM -0700, Sean 'Shaleh' Perry wrote: > > On 04-Apr-2001 Michael Wiedmann wrote: > > Questions which arise for me in creating an unofficial Debian > > package for a Python based script: > > > > - the upstream Python script is called 'script.py'. Should I keep > > the .py extension or drop it? > > > > Either is fine. > > > - should this script be installed in /usr/bin like any other > > regular program? > > > > as a package, yes. > > > - the upstream tarball has no man-page, so I'd created one > > and am not sure how to name it: 'script.py.1', 'script.1'? > > > > if it is foo.py, you get foo.py.1, if it is foo you get foo.1. BTW there is a > program which takes --help output and makes a manpage. I think it is called > help2man. Also note, (altough script may only be an example for you, in this case just ignore me) but script is already an existing binary of the bsdutils package (required and in base). Friendly, Sven Luther
Re: m68k compilation, account needed ?
On Wed, Apr 11, 2001 at 07:23:50PM +1000, Hamish Moffatt wrote: > On Tue, Apr 10, 2001 at 04:37:30PM +0200, Stefano Zacchiroli wrote: > > I've fixed a porting bug on one of my package (ocaml-findlib). > > The bug caused a compilation failure on m68k architectures. > > Before uploading the new version and closing the bug I want to be sure > > that the bug is fixed, but I don't have a m68k machine on which try the > > compilation. > > > > May I request an account on kullervo for compilation test ? > > I don't think m68k accounts are generally available. I could attempt > to compile your package if you post a URL for the source. I have > an m68k running unstable here. Stefano, i am sure your fix (if it is the one i suggested) will work. Just let the autobuilder build it, and then close the bug. You may look at ftp.debian.org/debian/pool/o/ocaml-findlib to check it. Friendly, Sven Luther
Re: Advice needed on changing upstream source.
On Tue, Apr 10, 2001 at 03:48:25PM -0400, [EMAIL PROTECTED] wrote: > > I have a problem. The Webmin distribution consists of various modules. > > It has periodic numbered releases. It also has unnumbered updates of > > individual modules between releases for bug fixes etc. What do I do? > > 0. Complain to upstream and ask them to make an official patch-level >number for these updates. 1.2.3 with the third update patch should >be called 1.2.3pl3. > > > 5. Invent my own versioning scheme > > If they don't want to officialize the patch-level numbers, go ahead and > do it yourself. The meaning is clear enough. If I see 1.2.3pl3, I know > that it's the official 1.2.3 with extra stuff added. Also if they have a anonymous cvs access or somethign such, you could just get the new version out of it, and number it : 1.2.3.cvs.2001.04.11 or somethign such (i know there is a policy on date-like versions, please read it). Friendly, Sven Luther
Re: Advice needed on changing upstream source.
On Wed, Apr 11, 2001 at 10:12:13AM -0400, Peter S Galbraith wrote: > > Matt Zimmerman wrote: > > > On Tue, Apr 10, 2001 at 02:46:30PM -0500, Jaldhar H. Vyas wrote: > > > > > I have a problem. The Webmin distribution consists of various modules. > > > It has periodic numbered releases. It also has unnumbered updates of > > > individual modules between releases for bug fixes etc. What do I do? > > > > > > 2. add updates to both the debianized source and orig.tar.gz. reupload > > > the orig.tar.gz with -sa > > With pools, you should no longer do this. Just change the upstream version number, adding a 'a' to the end or something such will make pools happy (especially good if you did upload a bad .orig.tar.gz to the pool). Friendly, Sven Luther
Re: corel install
On Tue, Apr 10, 2001 at 04:22:10PM -0500, Day wrote: > just tried the corel linux second edition ... went pretty > well. > but it dont run the lexmark printer even though it does find > it. > is it spozed to be normal, EPP, or ECP? > I tried all three cmos settings without result. > it dont say there's an error, just sorta blinks when I tell it > to print. no reset of the printer during a cold boot. > > another oddity. when I tell it to shutdown, it goes down, then > immediately tries to reboot rather than going off on an atx > athelon socket A. shutdown -r now will reboot, shutdown -h now will halt the box. You need acpi/or whatever that stuff is named working with your motherboard to have it switch off your box. Friendly, Sven Luther
Re: [users] Re: Where's lame
On Thu, May 10, 2001 at 12:33:19AM +0200, Robert Bihlmeyer wrote: > Paul Martin <[EMAIL PROTECTED]> writes: > > > The RSA patent was only valid in the USA, an oversight on RSA's part. > > That's the difference. > > But surely a sizable chunk the Debian usersbase lives in the US, there > were official CDs sold in the US containing the software, etc. So the > difference is only gradual: more potentail users, and more mirrors > (if mere distribution is really illegal) would be affected. What about setting up a non-patent debian archive somewhere were the patent don't apply. India could be a likely candidate, i think, but then maybe they only don't like patent on medicine or such ? Friendly, Sven Luther
Re: porting problem and how to request help
On Tue, Jun 05, 2001 at 07:51:08PM +0200, Stefano Zacchiroli wrote: > Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr, > the problem is a build failure on a m68k machine. The reason is that a > package needed in ocaml-xstr compilation named ocaml-findlib, does not > work well on a m68k architecture. > I forwarded the problem to the upstream author and I told me that he > does not like to solve architecture specific problem, OTOH I do not have > time and knowledge to debug problems on m68k arch. > > How can I solve the problem? May I ask for help on debian-devel or on > debian-m68k ML? > > Cause the problem is related to another package, may I close the bug on > ocaml-xstr and fill a new one against ocaml-findlib? I would say the best idea would be to write to debian-m68k, or maybe to some of the proters directly. Who did make the bugreport to you ? what does he have to say about this ? Friendl,y, Sven Luther
Re: motion - please do a sponsored upload for me (new revision with debconf fix)
On Sat, Aug 14, 2004 at 09:18:12AM +0200, Frederik Dannemare wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Saturday 14 August 2004 03:16, Wesley J Landaker wrote: > > On Friday 13 August 2004 19:06, Adam Majer wrote: > > > Frederik Dannemare wrote: > > > > Hi, > > > > > > > > I was hoping that my previous sponsor of motion would have the > > > > time this week to do a new upload which has a couple of very > > > > small fixes, but unfortunately I haven't heard from him yet, so > > > > I'm really, really > > > > > > I'll look at it and upload within an hour or so (unless there are > > > problems). > > > > I saw a copy of Frederik's same e-mail in debian-mentors earlier > > today and already checked it over and uploaded. My only concern was > > that it's not quite up-to-date with the latest upstream (3.1.14 vs > > 3.1.16), but since it's a bugfix, I went ahead and sponsored. > > When I adopted the package, I chose to update from 3.0.6 to 3.1.14, and > not 3.1.15/3.1.16, because I personally feel 3.1.14 is the most stable > of them. .15 had a lot of problems, and although .16 fixed much of > this, I still feel 3.1.14 is the better choice for the sarge release. > > Many thanks for the upload, Wesley. I really appreciate it. And thank > you, Adam, for once again offering to help me with an upload. BTW, what is the deal with motion and 2.6 kernels ? I am under the understanding that it requires the videoloop or whatever module, which is not only abandoned upstream, but also not yet ported to 2.6 kernels. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: motion, 2.6, and v4l loopback device [WAS Re: motion - please do a sponsored upload for me (new revision with debconf fix)]
On Wed, Aug 25, 2004 at 01:48:26AM +0200, Frederik Dannemare wrote: > > BTW, what is the deal with motion and 2.6 kernels ? I am under the > > understanding that it requires the videoloop or whatever module, > > which is not only abandoned upstream, but also not yet ported to 2.6 > > kernels. > > I have been using motion and 2.6 without the v4l loopback device. I Ok. > don't know much about it, but I think it was initially developed for > debugging motion in real-time or something like that. I have been helping someone, who has a customer who is using linux with a set of surveillance cameras. I think they use the vloopback device to have more than one app access the video device, namely motion and then vlc for video streaming server. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote: > [People from debian-ocaml-mail, please keep -mentors CC'ed.] > > * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: > > I could use a 'build-recommends' dependency, > > but I understand 'recommends' > > is only available for the binary package, not the source. > > Is this correct? > > > The situation: the packaging machine requires 'ocaml' > > to make binaries from my source package, but if > > 'ocaml-native-compilers' is also installed it will > > do so faster, however that package is not available > > on all architectures. > > > This isn't an essential feature, but here is a case, > > possibly isolated, where it could be useful. > > Normally, one resolves this and similar situations like this: > > Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], >ocaml [m68k mips mipsel s390] Bah, you just need to build-depends on : ocaml-best-compilers, and it does the necessary magic for you. ocaml-best-compilers is provided by ocaml-nox on m68k, mipses and s390, and by ocaml-native-compilers in the other cases. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
On Mon, Jun 13, 2005 at 09:57:25AM +0200, Goswin von Brederlow wrote: > Ralf Treinen <[EMAIL PROTECTED]> writes: > > > If you want to say in your package control file to depend > > on the fastest available compiler on any architecture then > > your should depend on "ocaml-best-compilers" which is a virtual > > package provided by "ocaml-best-compilers" on architectures > > You can't Build-Depend on virtual packages. Sure you can. You can't just not have a versioned dependency on them. Also, now is the time to fix any brokeness in dpkg and co to make this move more smoothly, if needed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depend on virtual packages
On Mon, Jun 13, 2005 at 01:51:23AM -0700, Steve Langasek wrote: > On Mon, Jun 13, 2005 at 10:15:30AM +0200, Stefano Zacchiroli wrote: > > [ Mail-Followup-To: set to debian-mentors only ] > > > On Mon, Jun 13, 2005 at 09:57:25AM +0200, Goswin von Brederlow wrote: > > > You can't Build-Depend on virtual packages. > > > Ok, time to settle down this issue. > > > We do, all ocaml packages build depends on ocaml-3.08.3 a virtual > > package provided by ocaml. What's the problem with that? It has worked > > properly for two years or so. > > Then you've been lucky. I don't think I've ever seen a clear statement that > virtual build dependencies *should* work, but they usually *do* work -- > *except* when there are bugs, which has happened from time to time. It > seems that sbuild particularly likes to object to build-dependencies on > virtual packages that were once real packages (e.g., libmysqlclient-dev -> > libmysqlclient12-dev). As a result, it seems to generally be more robust to > build-dep on a real package when possible. Let's make them working a etch release goal, ok ? Notice though that this is something a bit different than other usages of the virtual packages, since the virtual package is not used as an alternative thingy, but provided by one and one only real packages, and thus there should be no theoretical difficulty in making it happen. Notice that i mentioned this to elmo and aj in oslo already, during debconf'03. elmo was not so interested, but aj mentioned it was a reasonable use of virtual packages. And to stefano, the problem was mostly with the autobuilders logic being too broken to handle virtual packages correctly and needing hand intervention. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depend on virtual packages
On Mon, Jun 13, 2005 at 12:40:51PM +0200, Goswin von Brederlow wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > On Mon, Jun 13, 2005 at 10:15:30AM +0200, Stefano Zacchiroli wrote: > >> [ Mail-Followup-To: set to debian-mentors only ] > > > >> On Mon, Jun 13, 2005 at 09:57:25AM +0200, Goswin von Brederlow wrote: > >> > You can't Build-Depend on virtual packages. > > > >> Ok, time to settle down this issue. > > > >> We do, all ocaml packages build depends on ocaml-3.08.3 a virtual > >> package provided by ocaml. What's the problem with that? It has worked > >> properly for two years or so. > > > > Then you've been lucky. I don't think I've ever seen a clear statement that > > virtual build dependencies *should* work, but they usually *do* work -- > > *except* when there are bugs, which has happened from time to time. It > > seems that sbuild particularly likes to object to build-dependencies on > > virtual packages that were once real packages (e.g., libmysqlclient-dev -> > > libmysqlclient12-dev). As a result, it seems to generally be more robust to > > build-dep on a real package when possible. > > apt-get complains if there is more than one source of the provides > (even two sources with the same name/version). sbuild then picks the > first choice apt lists for the provides which is non deterministic and > strongly discouraged. > > As I said in the past this needs a real metapackage that then depends > on the actual ocaml package. We don have this problem, as for both ocaml- and ocaml-best-pacackages, there is only one real pasckage providing those. The same happens for things like spamoracle which is provided by spamoracle-byte on non-native arches. BTW, stefano, what happened to your presentation in helsinki ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote: > [People from debian-ocaml-mail, please keep -mentors CC'ed.] > > * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: > > I could use a 'build-recommends' dependency, > > but I understand 'recommends' > > is only available for the binary package, not the source. > > Is this correct? > > > The situation: the packaging machine requires 'ocaml' > > to make binaries from my source package, but if > > 'ocaml-native-compilers' is also installed it will > > do so faster, however that package is not available > > on all architectures. > > > This isn't an essential feature, but here is a case, > > possibly isolated, where it could be useful. > > Normally, one resolves this and similar situations like this: > > Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], > ocaml [m68k mips mipsel s390] Notice that this kind of things is mentioned in the ocaml-packaging-policy, did you read it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with bad package
On Tue, Jun 14, 2005 at 05:56:06AM +1000, John Skaller wrote: > On Sun, 2005-06-12 at 16:18 +0200, Goswin von Brederlow wrote: > > > > > 'Build-Conflict: ocaml (== version) [amd64]' I believe. You just have > > to hope the next upload fixes the problem. > > Here's is a reason to switch to Ocaml as a programming language: > copied from the ocaml mailing list: > > - > Yes, PR#3640 is an AMD64-specific code generation bug. It occurs in > the uncommon case where a leaf function (a function that doesn't call > other functions except as a tail-call) accesses a parameter passed on > the stack (not in registers). As a rule of thumb, if your tail > functions have fewer than 9 arguments, you're safe. > > The bug is fixed in the CVS repository, 3.08 bug-fix branch. > > - Xavier Leroy > --- So, can someone grab the patch from the bugfix branch and apply it to the debian package ? I would do it but i am far from my ssh/gpg keys for another two weeks. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Depend on virtual packages
On Tue, Jun 14, 2005 at 02:01:42PM +0200, Stefano Zacchiroli wrote: > On Tue, Jun 14, 2005 at 11:09:14AM +0200, Goswin von Brederlow wrote: > > No you don't. You have one per entry in the sources.list. As I said > > even the same version can make apt-get build-dep fail. Two versions, > > like when you just uploaded a new one that a local mirror doesn't have > > yet or users with stable/testing/unstable entries, makes apt always fail. > > I made some test with current unstable apt and "apt-get build-dep". I > set up a local repository of packages. First I tried to store there a > version of ocaml (providing the virtual package on which several other > packages build depend on) greater than that in unstable. In that case > apt-get build-dep indeed fails. > > Then I tried to store in the repository the same version of ocaml than > that in unstable. In this case apt-get build-dep work properly. > > Summarizing: > > I see no problem with autobuilders and virtual build-dependencies since > they're supposed to be configured with just unstable repositories. > However, to be kind to users it would be better to do as you suggest (a > real metapackage) so that they can happily live with an additional local > apt repository. No, i refuse to do hacky workaround and drop our current elegant solution just because others are too lazy or uninterested or whatever ot fix this. I think we should never again let others dictate how we should handle this or not, and if they get annoyed by imperfections or bugs in apt, dpkg or whatever, they can just fix it. /me still a bit angry about elmo's email about that a couple of years ago. > Do you know if there are plans to fix this behaviour in future versions > of apt? The expected behaviour for it should be to choose the greater > version if several version of a single package provide a virtual > package. No, but now is the time to fix this, at the start of the release cycle, so maybe we should fill an important bug report about this ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Felix package
On Wed, Jun 15, 2005 at 05:28:34AM +1000, John Skaller wrote: > I am seeking some input on the state of the following package: > > Package Name: felix > Version: 1.1.0 > Upstream author: John Skaller <[EMAIL PROTECTED]> > Licence: BSD > Description: high performance programming language translator and tools > > Source and amd64 binaries can be found at: > > http://felix.sf.net/debian > > There are certainly some known problems so I'm not yet seeking > a sponsor: one is the Build-depends and Depends. > > Additional info for anyone checking: > > (1) lintian complains about installing a shared library > in a non-dev package. This is deliberate. > > (2) On amd64, you must use the very latest bleeding edge > debian ocaml package: probably 3.08.3-4 (not sure if it is up yet) We have backported (well julien did) the fix in svn, and only an upload is needed. I will do so in two weeks once i come back to my gpg key if nobody does this before. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sponsoring ...
Hello, ... I am sponsoring someone who wants to become a new maintainer, and well, i have checked the packages and there are ok. Now, what is the correct way for his packages to be uploaded into debian. I thought that buildiing and signing the package myself, and then uploading would be ok, but it is not working, dpkg-buildpackage is not happy with me providing a pgp key with -k. What is the best way of doing this, or alternatively, is there some doc somewhere explaining the finer aspects on sponsoring ? Friendly, Svne Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsoring ...
On Thu, Feb 15, 2001 at 06:03:10PM +0100, Adrian Bunk wrote: > On Thu, 15 Feb 2001, Sven LUTHER wrote: > > > Hello, ... > > Hi Sven, > > > I am sponsoring someone who wants to become a new maintainer, and well, i have > > checked the packages and there are ok. > > > > Now, what is the correct way for his packages to be uploaded into debian. > > > > I thought that buildiing and signing the package myself, and then uploading > > would be ok, but it is not working, dpkg-buildpackage is not happy with me > > providing a pgp key with -k. > > > > What is the best way of doing this, or alternatively, is there some doc > > somewhere explaining the finer aspects on sponsoring ? > > I do usually a: > > dpkg-buildpackage -us -uc -rfakeroot > cd .. > debsign -m'Adrian Bunk' fspanel_0.5-1_i386.changes > > and it works without any problems. thanks, will try it, ... i tried dpkg-buildpackage -rfakeroot -k"Sven LUTHER <[EMAIL PROTECTED]>" didn't work. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsoring ...
On Thu, Feb 15, 2001 at 06:03:10PM +0100, Adrian Bunk wrote: > On Thu, 15 Feb 2001, Sven LUTHER wrote: > > > Hello, ... > > Hi Sven, > > > I am sponsoring someone who wants to become a new maintainer, and well, i have > > checked the packages and there are ok. > > > > Now, what is the correct way for his packages to be uploaded into debian. > > > > I thought that buildiing and signing the package myself, and then uploading > > would be ok, but it is not working, dpkg-buildpackage is not happy with me > > providing a pgp key with -k. > > > > What is the best way of doing this, or alternatively, is there some doc > > somewhere explaining the finer aspects on sponsoring ? > > I do usually a: > > dpkg-buildpackage -us -uc -rfakeroot > cd .. > debsign -m'Adrian Bunk' fspanel_0.5-1_i386.changes > > and it works without any problems. ... Args, ... it was because i am using a pgp key, and dpkg-buildpackage now uses a gpg key by default ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question about testing and multi binaries ...
Hello, ... Say i have a multi-binary package, where one of the binaries does not get build for one of the arches (namely arm in this case). In this case, does the binaries that get build for all arches go into testing, and not the one which only gets build for some of them, or does all the binaries from the source package need to get build. Also, ... Is there any documentation on making multi binary packages ? I did search a lot around, and the only thing i found is the /usr/share/doc/debhelper/examples/rules.multi and multi2 files, which don't explain that much, and don't seem very readable ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: upstream new version
On Thu, Mar 29, 2001 at 10:48:49AM +0200, Stefano Zacchiroli wrote: > I've to build a new package against a new upstream version released by > the upstream author of one of my packages. > What I have to do to merge the new upstream version in the old one > debianized source tree ? > > Have I to unpack the new orig file and copy in it the old debian/ dir ? What i use to do is either : 1) just apply the diff file to the new package, chmod +x debian/rules, and check that nothing broke. and once in a while i also do : 2) do a dh_make on the new upstream source, and one by one migrate the stuff done for the previous version to the new version. this needs : -> applying all patches to the upstream source that are still needed. -> modifying debian/rules os that it does the same things as the previous version -> copy the debian/changelog file and add a new entry there. (is there a tool for doing this, or do i need to do it by hand like i currently do ?) -> copy the rest of the stuff, checking it is still needed/don't need to be modified. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do I need 'unstable' for development?
On Wed, Mar 28, 2001 at 06:21:38PM +0200, T.Pospisek's MailLists wrote: > Nazdar, > > On Wed, 28 Mar 2001, Karel Gardas wrote: > > > I have one question regarding creating debian package. Do I need > > unstable debian for this task? I'm asking because I run potato now and (if > > possible) wouldn't like to switch to unstable. > > No, you definitively don't need to run unstable. It's better if you run > and develop on potato since then your package will also run there and > potato users will also be able to use your package. On the other side it's > always better for testing/unstable if people run them so, bugs get sorted > out... I think it is better to run unstable for building new packages, since : 1) no new package will get into potato anyway. 2) in running unstable, you help debugging it, which is required of developper in the later stages before a new release at least. 3) you will build your package against newer versions of the library. What does policy say about this exactly ? I think it is to use unstable, but i am not sure. Ideally, you would also have a chrooted stable environment, to build potato bug fixes or other such things. Or vice-versa ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about testing and multi binaries ...
On Thu, Mar 29, 2001 at 11:23:23AM +0100, Colin Watson wrote: > Sven LUTHER <[EMAIL PROTECTED]> wrote: > >Say i have a multi-binary package, where one of the binaries does not get > >build for one of the arches (namely arm in this case). > > > >In this case, does the binaries that get build for all arches go into testing, > >and not the one which only gets build for some of them, or does all the > >binaries from the source package need to get build. > > All binaries need to be in sync on all architectures if they are > present, but they're allowed to be absent. The whole source package and > all binaries built from it are treated as a single unit for the purposes > of testing. : > If you've stopped building a binary package for one architecture, you > need to make sure the ftpmasters remove it from that architecture > (they'll probably notice themselves eventually, but filing a bug against > ftp.debian.org doesn't hurt) before it can get into testing. If it was > never built for that architecture, it doesn't matter. The problem is that i have a package, ocaml, which builds fine on every arch, save the native code version of 1 library that don't build on arm, because of a arm assembly code generation bug in upstream. I don't speak arm assembly language, and asm code generation is a rather difficult problem anyway. What i would like to do, is to split the package, and move the problematic library in its own package, that will not be build for arm until the problem is solved. Thus enabling the most part of ocaml to go into testing, as it is pretty stable anyway, and well, no other package uyse said library that i know of. Now, the other solution would be to disable arm native code generation, but i think this is most uncool, since it works for everything less this binary. I can also wait for upstream or the arm porters to fix this, but i would like best that ocaml goes into testing as soon as possible. > >Is there any documentation on making multi binary packages ? I did search a > >lot around, and the only thing i found is the > >/usr/share/doc/debhelper/examples/rules.multi and multi2 files, which don't > >explain that much, and don't seem very readable ... > > Looking at multi-binary packages by competent maintainers? There are so many multi-binaries package out there, and no documentation provided on how to do this. This is not a good thing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: upstream new version
On Thu, Mar 29, 2001 at 11:18:26AM +0100, Colin Watson wrote: > Sven LUTHER <[EMAIL PROTECTED]> wrote: > >What i use to do is either : > > > > 1) just apply the diff file to the new package, chmod +x debian/rules, and > > check that nothing broke. > > > >and once in a while i also do : > > > > 2) do a dh_make on the new upstream source, and one by one migrate the stuff > > done for the previous version to the new version. this needs : > > > >-> applying all patches to the upstream source that are still needed. > > > >-> modifying debian/rules os that it does the same things as the previous > >version > > > >-> copy the debian/changelog file and add a new entry there. (is there a > >tool for doing this, or do i need to do it by hand like i currently do ?) > > debchange (in the devscripts package). Thanks, didn't know about this. > >-> copy the rest of the stuff, checking it is still needed/don't need to > >be modified. > > Sounds like a large amount of extra error-prone work to me, although I > suppose running dh_make every so often is one way of keeping some bits Thought so also :))) Also will look at what dh_make will propose to me about about multi-binaries. > of policy vaguely up to date. I just use uscan/uupdate to unpack the new > source and try to apply the old diffs for me. Yes, but, ... Often the diffs are no more valid, or may apply, but will not work as expected. Also, since i send my patches also upstream, often the patches i have need no more to be applied, but will also not be detected to be already applied, since upstream may have changed them a bit. But then i guess it depends on the package, and as for me upstream provides good quality releases, and also accepts my patches, this is the easiest way for me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 09:04:41AM -0400, Gopal Narayanan wrote: > On Tue, Apr 03, 2001 at 10:40:11AM +0200, Stefano Zacchiroli wrote: > > I've done the ocaml-findlib package with 'export DH_COMPAT=3' in the > > debian/rules. > > Some user report me the impossibility of build the same package from the > > sources on a debian potato. > > The compilation fail on dh_clean that right report an error. > > > > If I turn DH_COMPAT to 2 all compile correctly even on a potato. > > > > So, why (and when) I have to use DH_COMPAT=3 ? > > The version of debhelper on potato does not recognize > DH_COMPAT=3. That is a feature in the debhelper ver >3.0. That may > explain the problem of building on a potato machine. Is there any way of telling if we are building on a potato system or in a woody or unstable system in the rules file ? This could be handy for other kind of stuff also. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 03:16:57PM +0200, Ivo Timmermans wrote: > Sven LUTHER wrote: > > On Tue, Apr 03, 2001 at 09:04:41AM -0400, Gopal Narayanan wrote: > > > On Tue, Apr 03, 2001 at 10:40:11AM +0200, Stefano Zacchiroli wrote: > > > > I've done the ocaml-findlib package with 'export DH_COMPAT=3' in the > > > > debian/rules. > > > > > > The version of debhelper on potato does not recognize > > > DH_COMPAT=3. That is a feature in the debhelper ver >3.0. That may > > > explain the problem of building on a potato machine. > > > > Is there any way of telling if we are building on a potato system or in a > > woody or unstable system in the rules file ? This could be handy for other > > kind of stuff also. > > cat /etc/debian_version yes, this one could do ... > dh_testversion erm, ... this is told to be depredated (or whatever is the correct writting of this word) by the build dependency stuff. It also don't seems to do anything on a unstable system. > or build dependencies on debhelper (>>3.0) Yes, but since i want ot build the package on both potato and unstable, this will not help. Maybe there could be two Build-depends line, one for potato and one for unstable also, or something such, but then potato apt don't support build depends yet, so this may be moot. Anyway, the first solution would be the best one in this case. Friendly, Sven Luther > > > -- > Ivo Timmermans > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 04:25:01PM +0200, Stefano Zacchiroli wrote: > On Tue, Apr 03, 2001 at 09:04:41AM -0400, Gopal Narayanan wrote: > > The version of debhelper on potato does not recognize > > DH_COMPAT=3. That is a feature in the debhelper ver >3.0. That may > > explain the problem of building on a potato machine. > > If i want to do a package that can be compiled even on a potato machine, > what I have to do ? What about testing the content of /etc/debian_version, and if it is potato, then set DH_COMPAT to 2 ? (the propper sh stuff is left as an excercice :))) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Undocumented binary
On Tue, Apr 03, 2001 at 04:28:37PM +0200, Dennis Schoen wrote: > On Tue, Apr 03, 2001 at 09:49:41AM -0400, Steve M. Robbins wrote: > > On Tue, Apr 03, 2001 at 03:23:59PM +0200, Karel Gardas wrote: > > > > > > Hi, > > > > > > I have many binaries compiled from my source package and I would like to > > > attach 'undocumented' man page to these files. How can I do it? > > > > Aigh, no, please don't do that! > > Those drive me crazy!! > > > > The undocumented page provides no more information than > > "No manual entry for foo" (but the former is much longer to > > read). What is the point? > policy :) Does the policy not say that all binaries should have a manpage. having a manpage saying that there is no manpage is the same as having non, and i think it is not in the spirit of the policy. Maybe all manpage needing binaries could be listed somewhere, and we could have a manpage writing task ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Tue, Apr 03, 2001 at 09:40:43PM +0200, Ivo Timmermans wrote: > Sven LUTHER wrote: > > > or build dependencies on debhelper (>>3.0) > > > > Yes, but since i want ot build the package on both potato and unstable, this > > will not help. > > Why exactly? It's not a crime to create two separate packages; one > for stable and one for unstable. You can change the build > dependencies to match the distribution. Well, the idea is to have only one package for both, this make things simpler, create less work for me, and should be more error proof in general. Anyway, forking a package for 2 lines difference in the debian/rules file, and different build-depends don't seem worth it for me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DH_COMPAT 2 or 3 ?
On Wed, Apr 04, 2001 at 01:17:06PM +0100, Julian Gilbey wrote: > On Wed, Apr 04, 2001 at 07:44:34AM +0200, Sven LUTHER wrote: > > > Why exactly? It's not a crime to create two separate packages; one > > > for stable and one for unstable. You can change the build > > > dependencies to match the distribution. > > > > Well, the idea is to have only one package for both, this make things simpler, > > create less work for me, and should be more error proof in general. > > > > Anyway, forking a package for 2 lines difference in the debian/rules file, and > > different build-depends don't seem worth it for me. > > So it'll potentially create different binaries with the same version > number on the different platforms. Hmm. Why not just go with the > potato version? It should work fine on unstable. I don't package for potato, only for unstable. The version in potato is very old, and upstream did 2 releases since then (1 major and 1 minor). The reason for this question, was that someone wanted to build unofficial potato packages out of my source package for unstable. It caused some problems because i was depending on tcl/tk 8.3, while potato only has tcl/tk 8.2. Also, the package configure script did check for tcl.h to determine the version of tcl/tk installed on the system, and this file got moved from the potato version of tcl/tk (both all 8.0 forks and 8.2) (/usr/include/tcl.h) and the newer versions of tcl/tk for unstable (well 8.2 and 8.3, not 8.0, which conserve the old location). (/usr/include/tcl8.[23]/tcl.h). Now i solved this by fixing the upstream configure script and providing upstream with my patch, but it could have been nice also to provide a way to tell the package that you are under a potato system, or unstable/woody system, for this, and to build-depend on the correct tcl/tk. Notice that this is not so much a problem for potato, since apt in potato don't support build depends, but in the forthcoming woody release, apt will be able to support build depends, so this could cause problems. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python script
On Wed, Apr 04, 2001 at 01:02:56PM -0700, Sean 'Shaleh' Perry wrote: > > On 04-Apr-2001 Michael Wiedmann wrote: > > Questions which arise for me in creating an unofficial Debian > > package for a Python based script: > > > > - the upstream Python script is called 'script.py'. Should I keep > > the .py extension or drop it? > > > > Either is fine. > > > - should this script be installed in /usr/bin like any other > > regular program? > > > > as a package, yes. > > > - the upstream tarball has no man-page, so I'd created one > > and am not sure how to name it: 'script.py.1', 'script.1'? > > > > if it is foo.py, you get foo.py.1, if it is foo you get foo.1. BTW there is a > program which takes --help output and makes a manpage. I think it is called > help2man. Also note, (altough script may only be an example for you, in this case just ignore me) but script is already an existing binary of the bsdutils package (required and in base). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k compilation, account needed ?
On Wed, Apr 11, 2001 at 07:23:50PM +1000, Hamish Moffatt wrote: > On Tue, Apr 10, 2001 at 04:37:30PM +0200, Stefano Zacchiroli wrote: > > I've fixed a porting bug on one of my package (ocaml-findlib). > > The bug caused a compilation failure on m68k architectures. > > Before uploading the new version and closing the bug I want to be sure > > that the bug is fixed, but I don't have a m68k machine on which try the > > compilation. > > > > May I request an account on kullervo for compilation test ? > > I don't think m68k accounts are generally available. I could attempt > to compile your package if you post a URL for the source. I have > an m68k running unstable here. Stefano, i am sure your fix (if it is the one i suggested) will work. Just let the autobuilder build it, and then close the bug. You may look at ftp.debian.org/debian/pool/o/ocaml-findlib to check it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice needed on changing upstream source.
On Tue, Apr 10, 2001 at 03:48:25PM -0400, [EMAIL PROTECTED] wrote: > > I have a problem. The Webmin distribution consists of various modules. > > It has periodic numbered releases. It also has unnumbered updates of > > individual modules between releases for bug fixes etc. What do I do? > > 0. Complain to upstream and ask them to make an official patch-level >number for these updates. 1.2.3 with the third update patch should >be called 1.2.3pl3. > > > 5. Invent my own versioning scheme > > If they don't want to officialize the patch-level numbers, go ahead and > do it yourself. The meaning is clear enough. If I see 1.2.3pl3, I know > that it's the official 1.2.3 with extra stuff added. Also if they have a anonymous cvs access or somethign such, you could just get the new version out of it, and number it : 1.2.3.cvs.2001.04.11 or somethign such (i know there is a policy on date-like versions, please read it). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice needed on changing upstream source.
On Wed, Apr 11, 2001 at 10:12:13AM -0400, Peter S Galbraith wrote: > > Matt Zimmerman wrote: > > > On Tue, Apr 10, 2001 at 02:46:30PM -0500, Jaldhar H. Vyas wrote: > > > > > I have a problem. The Webmin distribution consists of various modules. > > > It has periodic numbered releases. It also has unnumbered updates of > > > individual modules between releases for bug fixes etc. What do I do? > > > > > > 2. add updates to both the debianized source and orig.tar.gz. reupload > > > the orig.tar.gz with -sa > > With pools, you should no longer do this. Just change the upstream version number, adding a 'a' to the end or something such will make pools happy (especially good if you did upload a bad .orig.tar.gz to the pool). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: corel install
On Tue, Apr 10, 2001 at 04:22:10PM -0500, Day wrote: > just tried the corel linux second edition ... went pretty > well. > but it dont run the lexmark printer even though it does find > it. > is it spozed to be normal, EPP, or ECP? > I tried all three cmos settings without result. > it dont say there's an error, just sorta blinks when I tell it > to print. no reset of the printer during a cold boot. > > another oddity. when I tell it to shutdown, it goes down, then > immediately tries to reboot rather than going off on an atx > athelon socket A. shutdown -r now will reboot, shutdown -h now will halt the box. You need acpi/or whatever that stuff is named working with your motherboard to have it switch off your box. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [users] Re: Where's lame
On Thu, May 10, 2001 at 12:33:19AM +0200, Robert Bihlmeyer wrote: > Paul Martin <[EMAIL PROTECTED]> writes: > > > The RSA patent was only valid in the USA, an oversight on RSA's part. > > That's the difference. > > But surely a sizable chunk the Debian usersbase lives in the US, there > were official CDs sold in the US containing the software, etc. So the > difference is only gradual: more potentail users, and more mirrors > (if mere distribution is really illegal) would be affected. What about setting up a non-patent debian archive somewhere were the patent don't apply. India could be a likely candidate, i think, but then maybe they only don't like patent on medicine or such ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: porting problem and how to request help
On Tue, Jun 05, 2001 at 07:51:08PM +0200, Stefano Zacchiroli wrote: > Some weeks ago I received Bug#96254 on one of my package: ocaml-xstr, > the problem is a build failure on a m68k machine. The reason is that a > package needed in ocaml-xstr compilation named ocaml-findlib, does not > work well on a m68k architecture. > I forwarded the problem to the upstream author and I told me that he > does not like to solve architecture specific problem, OTOH I do not have > time and knowledge to debug problems on m68k arch. > > How can I solve the problem? May I ask for help on debian-devel or on > debian-m68k ML? > > Cause the problem is related to another package, may I close the bug on > ocaml-xstr and fill a new one against ocaml-findlib? I would say the best idea would be to write to debian-m68k, or maybe to some of the proters directly. Who did make the bugreport to you ? what does he have to say about this ? Friendl,y, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a sponsor for Ppower4
On Wed, May 15, 2002 at 12:48:46PM +0200, Jens Schmalzing wrote: > Hi, > > Matthias Papesch writes: > > > Now I am looking for somebody to have a look at the package and help > > me get it into proper shape for uploading. > > I'd be happy to take a look at the package and sponsor the upload. BTW, on a somewhat related topic, i am planning to maintain a java written program also, but am asking myself how this can be done in debian, especially since there don't seem to be a complete java suite available in main, and even the ones in non-free seem to be quite outdated (last time i looked, which is already some time ago). Is it ok to upload such a package to contrib, and use the jdk available elsewhere, or should i try to build it with java tools available in main (it uses swing and threads among other stuff). Friendly Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Binary depends
On Thu, May 23, 2002 at 06:45:47PM -0500, Steve Langasek wrote: > On Thu, May 23, 2002 at 06:39:16PM -0400, Bob Hilliard wrote: > > I have just discovered (via a bug report) that dict and dictd > > depend on netbase. (dict and dictd communicate with each other using > > the TCP/IP protocol.) Since dictd has been in debian for over four > > years without declaring the dependency, this indicates that netbase is > > almost universally installed! :-) > > > Is there any tool, comparable to dpkg-shlibs, to determine > > non-library dependencies? > > How would you propose to detect such a dependency? Library dependencies > are easily detected; they're listed in a definitive location in every > ELF binary, and all libraries listed there are definitely dependencies > because the binary won't run without them. Dependencies on other > programs, OTOH, can only be identified using heuristics, or by simply > knowing your package very well: any tool that (e.g.) tries to grep > through the package sources to find out what other programs it > references will turn up lots of false positives on packages that *can* > use particular binaries if present, but don't really depend on those > external binaries. Well, you could try running the program through strace, and then look at all the opened files (with the proper strace flag) and then run dpkg -S on them. Same as for autodetecting build depends. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changing teTeX default config
On Sat, May 25, 2002 at 01:44:24PM +0100, Stephen Stafford wrote: > Sorry, I appear to have lost the message to which I am replying. It is: > > http://lists.debian.org/debian-mentors/2002/debian-mentors-200205/msg00212.html > > You can't change the systems texmf.cnf, but you *can* replace it in a > specific environment. > > If you set the environment variable TEXMFCNF=/path/to/dir/with/new/cnf/ then > it will read the texmf.cnf in there rather than the systemwise one in /etc. Will this work without further action, or do you need to run texconfig init, like you have to do when you change the one in /etc ? BTW, i too found that the default are too small for the tex files i am doing, but then i use mfpic ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question on build process
On Tue, May 28, 2002 at 07:31:51PM -0400, [EMAIL PROTECTED] wrote: > Hi > > I grabbed the source to an abondened package. I checked the bug reports > and no bugs were filed. > > I made all the changes to the files in the debian directory and run > debuild on them. All the files were built but the .diff ? > > Not sure why this did not appear but my quess is that since I did not > make any changes in the source but only the files in the debian directory? Because you don't have the pristine upstream source tarball, so dpkg-buildapckage considers that you are doing a native debian package, which does not have .diff file. A reason for this hapening, even when the upstream tarball is there, is that the name is wrong (often happens when the _ after the package name an d before the version is a - as upstream source often use, and is difficult to spot) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: looking for a TeX guy to (help to) package PassiveTeX
On Tue, Jun 18, 2002 at 11:16:46PM -0400, Jaldhar H. Vyas wrote: > On Wed, 19 Jun 2002, Atsuhito Kohda wrote: > > > Well, I would like to know what is the problem before > > trying to help you... > > > > Does build fail or doesn't passivetex work well with > > xmlto? > > > > How can one encounter the problem? > > > > xmltex convers XML Formatting Objects (FO) into PDF via TeX. This problem > seems to occur with any file used as input. I don't believe this is a > packaging problem though I would not rule that out. What happens is some > internal resource limit of TeX is getting exhausted. The last lines of > the log usually say something like: > > TeX capacity exceeded, sorry [pool size=67470]. > If you really absolutely need more capacity, > you can ask a wizard to enlarge me. you can enhance the different size of tex by modifying /etc/texmf/texmf.cnf and running texconfig init as root afterward. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reqest for review: ArgoUML java packages
On Fri, Jul 05, 2002 at 12:41:27PM +0200, Grzegorz Prokopski wrote: > Hello! > > With madness in the eyes and fury in the fingers after many hours > of extreme effort, with some help from doogie at #d-d and developers > of the software being packaged I finally created > > The packages of ArgoUML! The best free UML modelling tool. > > They're at: http://debian.sente.pl/debian/ > Sources line: deb http://debian.sente.pl ./ > Install by: apt-get install argouml Hello, ... I will be giving it a try, i was just searching a free UML modelling tool for some teaching job i will do next semester to replace the windows emulated objecteering we were using last year. I will keep you informed on my impressions and anything else i notice. BTW, did you also package the documentation ? I have seen there is some on the web page, but the /usr/share/doc/argouml is desesperately empty, and learning directly from the interface is not the best of solutions. Also some examples would be welcome in such a argouml-doc package. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream's debian/ directory
On Sun, Jul 28, 2002 at 09:36:24PM +0200, Marcin Owsiany wrote: > On Sun, Jul 28, 2002 at 08:15:12PM +0200, Amaya wrote: > > I am taking a look at renameutils > > (http://freshmeat.net/projects/renameutils) in oprder to file an ITP. > > > > Upstream already has a debian/ directory and I am not sure what to do... > > > > ?Should I just remove it form the .tar.gz and use that as my > > .orig.tar.gz or just let diff do its thing and reflect my changes? > > I guess the best way is to ask upstream to remove the debian directory. > Otherwise you have to repack the source tarball (removing it yourself). Or you could ask them to upgrade the debian directory to your new work, so other people can easily rebuild out of CVS and other such things. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: renaming a package
On Mon, Jul 29, 2002 at 12:04:51AM +0100, Colin Watson wrote: > On Sun, Jul 28, 2002 at 11:24:16AM -0400, christophe barb? wrote: > > On Sun, Jul 28, 2002 at 01:04:07PM +1000, Jamie Wilkinson wrote: > > > So in the control file, I've specified that libglut3 Conflicts and Replaces > > > glutg3 for versions <= 3.7-15, and created a glutg3 package with no content, > > > > I am not sure but isn't it better to use 'Provides: glutg3' instead of > > providing a package glutg3 with no content. > > Most dependencies on glutg3 are versioned, and a Provides: can't satisfy > versioned dependencies. Are there any plans to fix dpkg so it finally supports versioned provides ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what to do with binary conffiles ?
On Tue, Jul 30, 2002 at 06:14:55PM +0200, Eric Van Buggenhaut wrote: > On Tue, Jul 30, 2002 at 03:33 +0100, Mark Brown wrote: > > On Tue, Jul 30, 2002 at 04:15:11PM +0200, Eric Van Buggenhaut wrote: > > > > > When you install crafty for the first time, it installed compiled > > > opening books in /var/lib/crafty. Then, as it plays against you, it > > > 'learns' from the games and add the new moves to the opening books > > > that live in /var/lib/crafty. > > > > > Because You don't want your 'updated' opening books to be replaced by > > > crafty's default ones when you install a new version of the package, > > > these opening books are marked as conffiles. > > > > The bugs aren't just about the binary bit, they're also about the fact > > that you shouldn't have conffiles in /var. > > > > I don't agree with you here. When you have games that use high scores > files, these are placed in /var as per FHS 5.4 > (http://www.debian.org/doc/packaging-manuals/fhs/fhs-5.4.html) and > obvioulsy tagged as conffiles (you don't want to lose your > high scores files when upgrading the game). > > > > So, is it a problem to have conffiles being binary ? Do you have any > > > idea about how I could fix this (if it actually has to be fixed)? > > > > You definately need to remove the conffiles from /var. > > > > Why not just ship the files in /usr/lib or something and then in the > > postinst copy them to the place the package access them from if they > > aren't already there? > > > > I like this idea. Thanks for the tip. > > One drawback I see is that crafty-books-medium install a 30MB opening > book file, if we go copying it from /usr/lib to /var/lib, we're > wasting 30MB user's disk space, he might not like it. What about a symlink ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
staging area ?
Hello, ... I am packaging the ocaml language and some related libraries. There was a new release lately, which i packaged, but was somewhat buggy, and now i wish i had released it first into experimental (like gnome2 does) or a staging area (like perl does), since i cannot easily take it out of unstable (unless using epoch or 3.05_is_in_truth_3.04 versions) and its presence in unstable hinders upload of 3.04 related libraries. (Well, it is not all that problematic, since by end of the month, upstream will fix all problems, and make a new release). So i would like to know, which of the gnome approach (uploading to experimental) or the perl approach (using a staging area) is better or more recomended, and also if there is some documentation available on building a staging area. I suppose the advantage of experimental is that it is mirrored, while the staging area is not and that to build a staging area, i need some kind of copy of the dinstall scripts or something such and run them on a private subdirectory somewhere ? Any help or hint to information would be welcome. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
