Bug#311215: RFP: gajim -- a GTK Jabber client
Package: wnpp Severity: wishlist * Package name: gajim Version : 0.7 Upstream Author : Yann Le Boulanger <[EMAIL PROTECTED]> Vincent Hanquez <[EMAIL PROTECTED]> Nikos Kouremenos <[EMAIL PROTECTED]> Alex Podaras <[EMAIL PROTECTED]> * URL : http://gajim.org/ * License : GPL Description : a GTK Jabber client Gajim is a promising Jabber client that uses the xmpppy library. It is written in PyGTK and supports multiple accounts, service discovery, transport registration, TLS and GPG, emoticons, popup notification and many other useful features. Although not yet fully GNOME HIG compliant, upstream developers are very active and are improving the program quite rapidly. IMHO Gajim is in a better state than some other clients already packaged (such as gabber/gabber2 and cabber) and many people are using it. Upstream are maintaining Debian packages which seem to be in order. All free Jabber clients should be in Debian, this would speed up the inevitable death of all proprietary IM protocols. -- Yavor Doganov Free Software Association - Bulgariahttp://fsa-bg.org -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-386 Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312269: ITP: emile -- Early Mac Image LoadEr, a bootloader for m68k macs
On Mon, 06 Jun 2005 23:50:46 +0200, Wouter Verhelst wrote: > Owner: Wouter Verhelst <[EMAIL PROTECTED]> > > * Package name: emile > Description : Early Mac Image LoadEr, a bootloader for m68k macs Thank you very much for finally deciding to package emile. I will be expecting eagerly the moment when I'll be able to purge the proprietary OSes from my machines. Keep the good work! -- Yavor Doganov Free Software Association - Bulgaria GNUstep Bulgarian Translation Project GNOME Bulgarian Translation Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two versions of pan in etch?
David Weinehall wrote: > > Is the new version of pan able to migrate the information from the > old version yet? No, and it won't be until somebody writes the code. Charles Kerr (the upstream author) said that he's not going to do it as it's non-trivial and fairly difficult. I understand him, and I suffer as well as I'm subscribbed to a gazillion groups. > If it does support this now (or if you could at least add a postinst > script that does the migration), then I'm all for a switch to the > new version. I guess this (important, indeed) feature is irrelevant to the question. You'll hit the migration issue anyway. As a devoted Pan user, I'd like the new Pan in Etch, but since the code is changing very rapidly and is not yet mature, I think it's not a wise choice. Having the old and the new Pan together is over-projecting and not worth it, IMHO. OTOH, I really hope that upstream will release a stable version before freeze time. -- In the GNU Project, discrimination against proprietary software is not just a policy -- it's the principle and the purpose. Proprietary software is fundamentally unjust and wrong, so when we have the opportunity to place it at a disadvantage, that is a good thing. --RMS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pan in Sid
As it was pointed out by Jon Dowland, please read the discussion on this list that was started by the maintainer. Michael Rasmussen wrote: > > 1) It is VERY unstable - constant freezes and crashes Please report such issues using the "reportbug" program or `M-x debian-bug' if you use Emacs and have debian-el installed. One of the reasons that pan was uploaded to unstable is to find and fix any existing bugs in due time. It doesn't crash for me on three architectures. > 2) When installing the old settings from Pan 1.x is not merge with Pan > 2.x in which case your settings are either lost or you have to merge > all settings manually. It is a pain, yes. But for some packages there is no guarantee for an automatic upgrade path, so you'll have to live with it. Note that this is is an upstream issue so all users of all distros suffer from it. > I hope the version of Pan is removed by the end of the day! It won't, I hope. The old pan is not supported by upstream and although more stable than the new one, has plenty of annoying issues and bugs, which Søren Boll Overgaard has been fixing through the years with passion and love. It is inappropriate to insist to continue this nightmare for him throughout Etch's timeframe.
Re: Code of Conduct on the Debian mailinglists
Joe Smith wrote: > > OE does support threading for Email, it is simply disabled by > default. However overall the threading is more accuracte an reliable > for newsgroups. Until this MUA is released under a free license and ported to the GNU system so it can be packaged, this crucial detail is out of interest for the most of the list subscribers, I guess. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not only support Sid and Testing?
Joseph Smidt wrote: > > The question in my mind becomes: Is it still worth it if the bulk of > people Stable is created for are better servered somewhere else? You don't have a complete view on the situation, probably because you're a geek. Stable is not limited to servers. Almost every municipality, NGO, business coproration, etc. run Debian stable on their workstations for very good reasons. It is absolutely great, very easy to maintain, and the users don't care about the hottest stuff, they care to get their job done. I can assure you that GNOME 2.8 runs fine on stable and it is more than good for a generic business activity. So the "bulk of people Stable is created for" is tremendously large, just try to imagine it. It is not limited to the kiddies that hang on IRC. [Yavor, who actually works as a shipbroker but voluntarily supports all machines in the company; and is suffering great pain since the boss, looking at his desktop running Debian testing, ordered the migration from stable to testing for all the workstations 2 years ago.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer
Andrew Donnellan wrote: > > Since when was MPlayer acceptable in the Debian archive? I think he meant NEW, not incoming. But let's not resurrect old discussions. I was wondering, what's so important about mplayer? With totem and vlc (and I anticipate there's something similar for KDE) you have everything you need. I've never tried mplayer and I don't know how it looks or what it does, so that's just my uneducated guess. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downgrading the priority of nfs-utils
Roger Leigh wrote: > > What's the rationale for needing it as part of the default install? Because it's the standard GNU way of doing this kind of job? > The majority of the Debian (and GNU/Linux systems in general) I see > tend to not use NFS at all. I guess there is truth in this statement. But what else would you use for a network entirely consisting of GNU/Linux machines (lucky me)? Samba is a bridge to the proprietary world so I don't see a single reason to use it if there are no Windows hosts involved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is bug #399214 release critical? (Upgrade from version not in debian currently)
Daniel J. Priem wrote: > > I think such bugs can be easily closed. The bug is closed with the last upload to sid, the question is whether it should be considered as RC and if the release team will approve the fix for Etch. When upgrading from Sarge to Etch there is no issue, but for users like me (that particular machine is running testing) it is a real PITA. I intend to upgrade and remain on Etch (stable) when it is released, so I'll have a broken package. There's no way to remove/purge or upgrade it (well, there is, but it would be difficult for the average user). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] FTPmasters (again)
On Wed, 31 Aug 2005 12:29:07 +0300, Kalle Kivimaa wrote: > Thanks to you all for the best Linux distribution! In fact it is a GNU distribution, it used to be GNU/Linux distribution, now we can call it simply GNU (given the fact that both hurd and kfreebsd-gnu are rocking and under active development). "Linux distribution" is just wrong (and rather annoying). -- Yavor Doganov JID: [EMAIL PROTECTED] Free Software Association - Bulgaria http://fsa-bg.org GNOME in Bulgarian! http://gnome.cult.bg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
To Linux or not to Linux
On Wed, 31 Aug 2005 07:35:23 -0600, Wesley J. Landaker wrote: > That and--it will make most of us cringle--when other kernels are popular, > you'll hear lots of stuff like: The reason for calling it GNU (ok, GNU/Linux as the the other ports are not yet in a releasable state) is to enable people to find out how everything started and read www.gnu.org, understand the reasons, and eventually agree with them and why not, start to contribute and spread the freedom. It is really amazing how developers still continue to call it with the wrong name. Developers are not like journalists, right? By calling it simply "Linux" you mislead the people -- they will know about the genius and selfish Finnish programmer who wrote the first free kernel and doesn't object others refering to it as "operating system". They will have no clue about freedom at all. (I know, this is the wrong list). -- Yavor Doganov JID: [EMAIL PROTECTED] Free Software Association - Bulgaria http://fsa-bg.org GNOME in Bulgarian! http://gnome.cult.bg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To Linux or not to Linux
* Wouter Verhelst <[EMAIL PROTECTED]> writes: > And you're also preaching to the choir, mostly. A well known fact to me, sorry for this, but I consider it important. As you're my personal hero (I have a Mac Quadra), now I know your attitude, which makes me sad. -- With respect, Yavor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To Linux or not to Linux
On Sat, 03 Sep 2005 08:29:03 +1000, Paul TBBle Hampson wrote: > Coming directly after "wrong list" possibly helped that, although > I didn't read it as such. My mistake, Wouter has explained and I'm more than happy now ;-) > Of course, now I'm posting... I disagree with Yavor that we should use > GNU/Linux so that people will go to gnu.org [...] [...] > I believe we should use GNU/Linux because we're using GNU libc That's ok, so even from technical point of view people should call it GNU/Linux. I am more concerned about the moral issues, though. > So GNU/FreeBSD for the kfreebsd port Thanks to the people involved in development of this port one day I'll be able to install on my old Alpha not only a GNU system, but the system I am familiar with -- Debian. The Linux kernel will never boot on it as the kernel team has declared several times that people having TurboChannel Bus Alphas are not important (which is in fact, true). > The name of the distribution should reflect the contents of that > distribution, rather than the politics it may or may not endorse. I agree, it is a GNU system, hence the name -- GNU/Linux (with a piece of deserved credit to Linus). Calling it only "Debian" is fine as well. -- Yavor Doganov JID: [EMAIL PROTECTED] Free Software Association - Bulgaria http://fsa-bg.org GNOME in Bulgarian! http://gnome.cult.bg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: real-i386 (was Re: i386 requalification for etch)
At Thu, 3 Nov 2005 02:38:51 -0800 (PST), Nick Jacobs wrote: > > You mean, it's seriously been proposed that a significant amount of > work should be done to restore support for a processor that has not > been manufactured for 10 years? While slightly degrading performance > for the 99.9% of x86 users who have Pentium/Athlon/or better? Why not supporting it, if it is not so hard? This is important for the small hobbits that love to tinker old hardware. I have 2 i386 machines and I don't plan to throw them away. I am quite confident that the users of powerful and shiny new machines won't suffer much. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: real-i386 (was Re: i386 requalification for etch)
At Thu, 03 Nov 2005 18:11:56 -0300, Daniel Ruoso wrote: > > I think i386 debian arch is not suitable anymore for real-i386 machines > (self-experience), I mean, it's not suitable even for a Pentium 133 with > 32 Mb RAM. Ok, I know it works, but it's a waste of memory and CPU > cycles to run a full glibc-based distro in such restrictive > environment... That's the greatest joy of it -- to see a Free OS running on forgotten machines. This is somehow a liberation of the machines/architectures. My mail server and gateway is ST (Cyrix) at 100 MHz and it's doing fine. Basically you have to follow 3 rules - patience, patience and patience ;-) Compiling a 2.6 kernel on a i486 with 8 MB RAM takes 11-12 days. > So, I would state it as: "Want your 386/486/pentium I running Debian? > help the i386-uclibc port" :) :) :) :) :) :) :) :) :) :) :) :) :) :) I'd love to, but unfortunately I'm a translator and documentation writer, I don't have programming skills :/ But I'll follow it closely, thanks. -- Yavor Doganov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules "make -f" restriction
[ I haven't looked the vdr-* source; apologies if I miss something essential. ] Tobi wrote: > Personally I think debian/rules shouldn't be restriked to make. What happens if you do `./debian/rules -p | less'? Although seldom needed, that's a useful thing when you have to debug the build system, especially when it's intercepted with upstream's and things are not working as one would expect. (I fixed a bug in a package using this technique once, so it's not just a hypothetical argument.) IMHO, the assumption that debian/rules is a makefile (or more precisely, a GNU makefile) has its deep roots in maintainers' minds. Personally, I've never associated it with alleged policy bureaucracy, I've always thought that's simply the *right* thing to do. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Icons and instructions for the FreeDesktop menu.
Jeff Carr wrote: > On 01/17/07 00:22, Loïc Minier wrote: > > > The Debian menu system is completely useless to me, and I expect to > > most GNOME and KDE users. > > You've hit the nail on the head. That whole thing came about from > earlier times. I wish you every luck in purging it from existence. But you both forget that there are GNOME users who use apps without a .desktop entry and the only way to start them is through the Debian menu. Opening a terminal just horrifies them. All my colleagues are such users.
Re: Bits from the Debian GNU/kFreeBSD porters
Instead of arguing about the "From" header and generating traffic that might be interesting, but not important at all, why don't we express our warm gratitude and congratulate the Debian GNU/kFreeBSD team for the *great* work they have done by making yet another variant of GNU a reality? Their work indirectly helps the GNU/Hurd port as well and is a solid foundation for GNU/kNetBSD (which will eventually make using the GNU system possible on many peculiar and rare machines). Wonderful job, dear developers! I thank you wholeheartedly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts about the bug tracking system
Don Armstrong wrote: > > [It appears that debian-bug.el doesn't actually do the > /usr/share/bugs//*; thing either [...] It does but relies on reportbug for this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Samuel Thibault wrote: > Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : > > Samuel Thibault wrote: > > > Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : > > > > * Package name: pthsem > > > Mmm, could this perhaps rather be just a patch added to the > > > existing pth package? > > > > The situation with GNU pth is: > > I guessed so, but still. [...] > Were I Martin Kögler, I'd even just request GNU to become the new > maintainer of pth. ...which is usually done by writing to . It is counter-productive to start a fork just because GNU pth is unmaintained upstream (it is not an officially "orphaned" GNU package, AFAICS, but that doesn't matter much if it really is neglected). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler wrote: > I must admit, that I have not read anything about GNU maintainers, > but GNU has usually a bigger "philosophical overhead". Then I suggest you to read the appropriate documenation [1] before jumping to premature and possibly incorrect conclusions (what does the phrase "philosophical overhead" entail?). A fork is done when there is some kind of unresolvable conflict/disagreement (be it technical or not). Forking is a fundamental right, so there's nothing wrong in forking pth. But there are too many (forked) packages in Debian, and the Debian QA team would have to maintain the original pth package for some time at least, which is a burden. If there are people actively working to enhance pth, the best (for GNU, Debian, and literally everyone else) is to take over the package upstream. (OTOH, speaking generally, it is sad to see a package "reborn" under another name just because the prospective new maintainer cannot communicate successfully with the original one to negotiate the takeover. I once again urge you to write to to avoid this unpleasant scenario.) [1] The gnu-standards package in Debian (both documents available also online at http://gnu.org/prep). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Marc Leeman wrote: > > (OTOH, speaking generally, it is sad to see a package "reborn" > > under another name just because > > Don't read to much into this; Well, as a matter of fact I don't. Probably I wouldn't have replied to the thread if pth wasn't a GNU package, but my opinion would be the same. A fork should be the last resort, when all efforts to prevent the fork have been tried and failed. The introduction of a forked package in a distro is a separate issue, but it naturally is something not to be taken lightly. > pth is for sure a smaller effort in Martins' work. We just want to > get over this small hurdle in order to get his really interesting > stuff included (which depends on this). Avoiding this "small hurdle" will result in a much bigger hurdle for every distribution, especially Debian when you take into account the number of packages and supported architectures. Every new package results in extra load on the infrastructure (which is not only machines), possible user confusion, possible and very likely further effort by QA/security/release teams, etc. > OK, sent a short note to maintain...@gnu.org. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: auto-tools and debian/source/Makefile.am file
Peter S Galbraith wrote: > Anyone know how to make the auto-tools include the debian directory > in the source tar ball (with `make dist') but NOT maintain any > Makefile in those directories? You can just list all needed files in EXTRA_DIST (or the appropriate automake variable) and avoid using SUBDIRS, e.g. EXTRA_DIST = upstream-file1 upstream-file2 debian/control \ debian/changelog debian/source/format ... It's a separate question why would you need to distribute the upstream tarball with a debian dir included... (BTW, Automake is smart enough to automatically distribute ChangeLog, README, THANKS, etc. and defining VPATH/srcdir is not necessary since quite some time.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxv6edry.gnus_not_unix!%ya...@gnu.org
Re: xulrunner 1.9.2 into sid?
Michael Gilbert wrote: > No, my proposal is to move the package to a better home: backports. Have you discussed this proposal with other members of the security team? And/or the relase team? Ignoring the fact whether this is something possible or not currently, just think of the rdepends. Seriously. xulrunner is not clamav in this regard. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaqc7b41.gnus_not_unix!%ya...@gnu.org
Re: RFC: Rules for distro-friendly packages
Enrico Weigelt wrote: > * Russ Allbery schrieb: > > You're basically saying that people aren't allowed to use > > the typical Autoconf semantics of honoring --with and --without > They should use --enable-*/--disable-* flags for switching features. --with and --enable have different semantics, although they're often misused and/or confused by upstream authors. See (autoconf)External Software' and the subsequent node, `(autoconf)Package Options'. > Switching dependencies which silently enables/disables features is > a generally bad approach. Well, in my very humble experience, an optional dependency is there precisely to provide an optional feature. > > I disagree with requiring static libraries even with the exception that > > you list. In this day and age, I think static libraries are basically > > useless unless > > Building static libraries (additional to shared/dynamic ones) usally > is not a big task. I guess what Russ is trying to say is that they are completely useless if just one library package in the dependency chain doesn't provide a static lib. > And still many people need them. I seriously doubt that. Many Debian library packages have been gradually dropping static libraries in the past few years, and I don't recall complaints. I think the statement "many people need them" is an exaggeration. If someone really needs a static library, she is probably in a perfect position and has the necessary knowledge/skills to build one herself. As you say, that's easy :-). > > I strongly disagree with requiring pkg-config. > > Well, actually, I need it, eg. for clean sysroot'ed crosscompiling. But pkg-config is notoriously bad when cross-compiling... With pure Autoconf macros (used properly, and providing an extra argument for AC_RUN_IFELSE and friends), cross-compilation works out of the box. If PKG_CHECK_MODULES is used, the installer has to go through extra hoops. > > None of my libraries support this, > > Bad. You should fix this. I don't think so. It's entirely his prerogative whether to support it or not, and it's perfectly fine not to use it. > > and I don't see any point in using pkg-config if the way that one > > uses the shared library is to just add -l. > > Because that doesn't always suffice. It requires that the library > is in the toolchain's standard search path. That's the case with pkg-config too. If you install a library in /opt/foo, pkg-config will not find it if you don't instruct it to look there. > And what about cflags ? What about dependencies ? What's wrong with checking for the libraries/headers in the right dependency order? Honestly, I've always wondered what's so attractive in pkg-config that people use it so much. All it does is parsing a .pc file, which fails short in so many situations... The version check pkg-config does is simply a comparison with the version embodied in the .pc file, which does not match the reality in some cases, and more importantly, is the wrong approach -- the version check may succeed, but the library may not provide the feature needed by the package (improper installation, distro patch, sysadmin patch, forked software, anything else the package developer *has not* anticipated). And vice versa, which is equally annoying -- the library provides the symbol (or the new feature) the package needs, but the .pc file still contains the old version, because usually it's bumped at release time. Ugh. You are basically right that using pkg-config is easier for many upstreams, but "easy" != "correct". Correctness is far more important. I also fail to see what has pkg-config to do with distro-friendliness. A distro maintainer by definition should be familiar with the code, follow upstream development, examine diffs between upstream releases (in the ideal case), and add the appropriate build-dependencies when the new upstream version of the package needs them (or could benefit from them). pkg-config is not in the picture at all. > > It's a nice-to-have if upstream wants to bother, but is absolutely > > not required. > > For my setups, it *is* required. Then you probably can't build lots of packages. Many widely used libraries with a truckload of reverse dependencies do not support pkg-config, and there's nothing wrong in that. > > My packages will not be using pkg-config when pkg-config doesn't > > do anything useful or when I can reproduce its results in more > > supportable ways. > > Then you'll have to live with the fact, that other people won't > like your libraries very much, for that reason. That is an utterly wrong assumption, and I even find it slightly insulting because it presumes that the quality of Russ' software is somewhat lower than expected. > > The pkg-config Autoconf glue is ugly and does not properly > > implement Autoconf semantics (for example, it incorrectly merges > > CPPFLAGS and CFLAGS, and LIBS and LDFLAGS, and is not written > > using modern Autoconf features and style), Very true. >
Re: RFC: Rules for distro-friendly packages
Enrico Weigelt wrote:
> * Yavor Doganov schrieb:
> > > Switching dependencies which silently enables/disables features is
> > > a generally bad approach.
> >
> > Well, in my very humble experience, an optional dependency is there
> > precisely to provide an optional feature.
>
> No, opposite direction: features are functional requirements, whose
> implementations just happens to have some dependencies. For example,
> an feature could be supporting compressed files, implemented using
> zlib or libbz2.
That's exactly where --with-zlib and --with-libbz2 should be used
(according to the practice recommended by Autoconf, at least).
--enable-compression could by default check for zlib and libbz2, and
enable either or both if found. If neither is found and
--enable-compression was manually specified by the installer, the
configure script should fail with a proper error message.
That's what users generally expect, since the recommendation has been
there for ages.
> > > And still many people need them.
> >
> > I seriously doubt that.
>
> You doubt the whole embedded/smalldev development going all around
> the world ?
I admit I'm not familiar with this topic ("embedded/smalldev
development"). If static libraries are really needed there, and this
is an area Debian strives to support, I guess the stance about static
libs should be widely discussed.
> > > > I strongly disagree with requiring pkg-config.
> > >
> > > Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.
> >
> > But pkg-config is notoriously bad when cross-compiling...
>
> No, it's not. Actually, it's quite fine. Just give it the right
> environment variables, so it takes everything from sysroot.
That's what I'm talking about. You don't need to play with PKG*
variables if pkg-config macros are *not* used.
> And you suppose all the individual distro maintainers to manually
> tweak each package for each target ?
Of course not. A proper usage of the GNU Build System does not
require pkg-config, and certainly does not require manual tweaks.
> It's easier to control those things via a generic interface like
> pkg-config (note: I'm talking about the _interface_, not just the
> binary /usr/bin/pkg-config !)
This interface contradicts the Autoconf philosophy (i.e., perform
realistic feature tests, not merely version comparisons), which is why
some developers do not like and/or trust its approach. Others do,
which is also fine.
I don't see why Debian should insist on upstreams to be in the former
or the latter group. Really.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874odkdxcy.gnus_not_unix!%ya...@gnu.org
Re: Upcoming Section changes in the archive
[BTW, the only proper spelling is "GNUstep" -- not "Gnustep" or "GNUStep".] Vincent Danjean wrote: > I maintain a page.app package. You mean paje.app, I assume (innocent typo)? > It is right it is a gnustep application (ie it uses the gnustep > framwork). However, I never use the gnustep environment. Well, GNUstep is not a desktop environment (unlike GNOME, KDE, Xfce, etc.), so it is more or less correct that the proposed section title says "GNUstep environment" and not "GNUstep desktop environment". GNUstep is more than libraries (like GLib/GTK+), so it is basically right to say "environment". Whether gnumail.app (for example) belongs in the "gnustep" section instead of the "mail" section is another question. I think that programs that have already specialized sections should remain there (i.e. "science" for adun.app or "news" for lusernet.app). OTOH, having the GNUstep apps/bundles/tools in one section is a convenience for the average user (I guess). Current GNUstep upstream labels it as "development environment", and it's very unlikely that GNUstep would become a desktop anytime soon (contrary to the hopes of many GNUsteppers, unfo). There is a desktop based on it, however, Étoilé (http://etoileos.com). The Debian package is about to be updated after the current post-release dust/morass settles down. > This is just to say that some *.app application are not tied to the > gnustep environment (for example, I find correct that gnumeric is in the > 'math' section and not in the 'gnome' section). Right, you can run GNUstep apps under any window manager (well, in theory, at least -- there are lots of WM-specific bugs and limitations). The same holds (to a much greater extent) for GNOME or pure GTK+ apps or pretty much everything else. I would consider it a bug if I install (say) kmail on my GNUstep workstation and it doesn't pull all the required dependencies and doesn't work correctly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#1085099: ITP: gshisen.app -- Shizen-sho puzzle game for GNUstep
Package: wnpp Severity: wishlist Owner: Debian GNUstep maintainers * Package name: gshisen.app Version : 1.3.0 Upstream Author : Enrico Sersale (RIP) James Dessart Larry Coleman The GAP Team * URL or Web page : https://gap.nongnu.org/gshisen/ * License : GPL-2+ Programming lang: Objective-C Description : Shizen-sho puzzle game for GNUstep The object of the game is to remove all tiles from the field. Only two matching tiles can be removed at a time. Two tiles can only be removed if they can be connected with at most three connected lines. Lines can be horizontal or vertical but not diagonal. Remember that lines may cross the empty border. If you are stuck, you can use the Hint feature to find two tiles which may be removed. This is the first ever GNUstep game (well, that has been released publicly as free software) and it was available in Debian under the name "shisen.app" between 2006-2013. It was removed from the archive because the package was orphaned.
