Re: installing a source tree?
Chasecreek Systemhouse wrote: > Its a Accounting/Ledger system from http://www.sql-ledger.org/ -- apt-get install sql-ledger
Re: possible freetype transition; improved library handling needed for all C/C++ packages
Steve Langasek wrote: > * Use Debian's libtool. I took one affected package (kmldonkey) from your list, relibtoolized it as described, and rebuilt it, which failed spectacularly. Then, I took another one (rekall), relibtoolized it, rebuilt it, and that failed with a strikingly similar pattern. kmldonkey links with the following libraries: -lkdeui -lkio. As shipped, libtool expands that to every library under the sun. The new libtool indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few system libraries/objects, which is then greeted by ld with hundreds of error messages of the kind: /usr/share/qt3/include/qstring.h:847: undefined reference to `QString::shared_null' /usr/share/qt3/include/qstring.h:848: undefined reference to `QStringData::deleteSelf()' Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which I suppose is where these symbols should be). The error messages in the rekall build are of the sort .../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to `i18n(char const*)' In this case -lqt-mt is actually on the libtool command line. So what is wrong here? Have other maintainers of Qt/KDE-related packages perhaps experienced this? -- Please send copies of list mail to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
md5sum output format
Has the tech-ctte decision regarding the output format of md5sum [0] been withdrawn in some form? It seems to be back to the old format: $ md5sum http://lists.debian.org/debian-ctte/2004/06/msg00032.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Bug#344758: init.d script should create /var/run/dirmngr
What do you think about this request? It seems reasonable, but I think if this should be supported, there ought to be a general policy (formal or informal) on it because I think many other init scripts will suffer from similar problems. -- Forwarded message -- Subject: Bug#344758: init.d script should create /var/run/dirmngr Date: Sonntag, 25. Dezember 2005 18:22 From: System Administrator <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Package: dirmngr Version: 0.9.3-1 Severity: normal The script should create /var/run/dirmngr to allow users to map their /var/run to a temporary filesystem like tmpfs. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301061: ITP: apt-rpm -- tools to create APT RPM repository
Package: wnpp Severity: wishlist Owner: Peter Eisentraut <[EMAIL PROTECTED]> * Package name: apt-rpm Version : 0.5.15cnc6 Upstream Author : Gustavo Niemeyer <[EMAIL PROTECTED]> Alfredo K. Kojima <[EMAIL PROTECTED]> based on work by the Debian APT team * URL : https://moin.conectiva.com.br/AptRpm * License : GPL Description : tools to create APT RPM repository apt-rpm is Connectiva's port of Debian's APT to RPM. This Debian package contains the tools to create an APT RPM repository, so RPM-based systems can be maintained via APT while the APT repository resides on a Debian system. The client-side part of apt-rpm will obviously not be included in the Debian package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unixODBC vs. iODBC
Debian currently ships two ODBC driver managers, unixODBC (source package "unixodbc") and iODBC (source package "libiodbc2"). These basically do the same thing. Every package that wants to provide database access through ODBC has to pick at build time which driver manager to use. That in turn forces the user to set up each ODBC drivers twice, once for each driver manager. This process must seem pretty arbitary from the user's point of view. Well, the above is mostly true because you can build the program one way and the driver the other way and it might still work, but who really knows? Should we somehow declare one or the other as the preferred driver manager, thus making it easier for users and perhaps developers? I'm not attached to either camp, but here are some data points: - Currently 18 packages use unixODBC, 11 use iODBC. - Both myodbc (MySQL ODBC driver) and psqlodbc (PostgreSQL ODBC driver) build against unixODBC. - unixODBC comes with a buch of GUI tools, iODBC does not. - Both are still developed upstream. - libiodbc2 has been RFA'd by the current maintainer for over a year. - The lastest PostgreSQL ODBC driver fails to build with iODBC. Well, you can guess what my pick is. Other comments? -- Please copy me on replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please remove rules.old
There are a few dozen source packages in the archive that contain a file called debian/rules.old. In many cases, this was apparently the backup copy during a cdbs conversion or something similar that should have been removed. If you appear below, please consider fixing this. Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]> denemo puredata wavesurfer Marc Dequènes (Duck) <[EMAIL PROTECTED]> arkhart Moray Allan <[EMAIL PROTECTED]> gpe-julia gpe-todo libdisplaymigration teleport Hakan Ardo <[EMAIL PROTECTED]> binutils-avr gcc-avr Michael Banck <[EMAIL PROTECTED]> gnoise mpqc python-cddb Bastian Blank <[EMAIL PROTECTED]> ibm-3270 Yann Dirson <[EMAIL PROTECTED]> skribe Dirk Eddelbuettel <[EMAIL PROTECTED]> gtkdevice rggobi rgtk rodbc tkrplot tseries Florian Ernst <[EMAIL PROTECTED]> xmms-crossfade Daniel Glassey <[EMAIL PROTECTED]> bibletime-i18n Debian QA Group <[EMAIL PROTECTED]> gtk-mist-engine Marek Habersack <[EMAIL PROTECTED]> pike7.2 Pierre Habouzit <[EMAIL PROTECTED]> php-json-ext Fredrik Hallenberg <[EMAIL PROTECTED]> asmail Uwe Hermann <[EMAIL PROTECTED]> aview Mark Howard <[EMAIL PROTECTED]> gtkballs Sam Johnston <[EMAIL PROTECTED]> pound Anand Kumria <[EMAIL PROTECTED]> tspc Adam Majer <[EMAIL PROTECTED]> mrtg Steve McIntyre <[EMAIL PROTECTED]> seyon Jim Mintha <[EMAIL PROTECTED]> slang Joe Nahmias <[EMAIL PROTECTED]> pacman Gopal Narayanan <[EMAIL PROTECTED]> pgplot5 Kari Pahula <[EMAIL PROTECTED]> crossfire crossfire-maps crossfire-maps-small Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]> clips-doc Florian Ragwitz <[EMAIL PROTECTED]> libxml-libxslt-perl Craig Small <[EMAIL PROTECTED]> procps Christian Sánchez <[EMAIL PROTECTED]> libhtml-table-perl Masato Taruishi <[EMAIL PROTECTED]> vflib2 James A. Treacy <[EMAIL PROTECTED]> fftw sean finney <[EMAIL PROTECTED]> cacti Debian ACE+TAO maintainers <[EMAIL PROTECTED]> ace -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373824: RFH: ntp -- Network Time Protocol: network utilities
Package: wnpp Severity: normal We could use a few more people to help with the ntp package. We have a new mailing list and a subversion repository hosted under the pkg-ntp project on alioth. There is a boatload of bugs to deal with, most of which are not that hard but need someone with a little time and dedication to evaluate them. The package description is: NTP, the Network Time Protocol, is used to keep computer clocks accurate over the Internet, or by following an accurate hardware receiver which interprets GPS, DCF-77, NIST or similar time signals. . This package contains control programs which can access a remote NTP server. Thus you will need either ntp-simple or ntp-refclock; ntp-refclock includes drivers for radio clocks. . For more information about the NTP protocol / NTP server configuration and operation, load the optional Debian package 'ntp-doc'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
egroupware upgrade drops several applications -- suggestions?
The upgrade to the new egroupware upstream drops several applications such as the trouble-ticket system and the forum (because they were unmaintained or the functionality was picked up by something else). I'm not sure how to arrange an upgrade to this new version. On the one hand, no one wants to maintain the old stuff anymore, so it should disappear from the Debian distribution. On the other hand, if a sarge->etch upgrade potentially throws away a bunch of functionality and data, users won't be happy. What to do? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clarification of NMU policy
I have been in a discussion with a fellow developer about the exact meaning of the "0-day NMU policy" that is currently in effect. Questions: 1. Does the 0-day policy only apply to RC bugs or to all bugs? 2. Does the "0 day" apply to the delay after the upload or to the delay between the submission of the bug and the upload? 3. Does any rule, policy, or BSP excuse people from following the NMU protocol in the developer's reference, for example, the requirement to submit a bug before the upload? Thank you for clarifying. (Please Cc me.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337401: ITP: ggz -- libraries, games, and programs for network and online games
Package: wnpp Severity: wishlist Owner: Peter Eisentraut <[EMAIL PROTECTED]> * Package name: ggz Version : 0.0.12 Upstream Author : Josef Spillner <[EMAIL PROTECTED]> * URL : http://www.ggzgamingzone.org/ * License : GPL Description : libraries, games, and programs for network and online games GGZ (which is a recursive acronym for GGZ Gaming Zone) develops libraries, games and game-related applications for client-server online gaming. Player rankings, game spectators, AI players and a chat bot are part of this effort. The previous ggz packages were removed from Debian because of RC bugs and a missing maintainer. A new packaging team with upstream involvement is going to attempt to revive this effort. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474299: ITP: semantik -- mindmapping tool
Package: wnpp Severity: wishlist Owner: Peter Eisentraut <[EMAIL PROTECTED]> * Package name: semantik Version : 0.6.4 Upstream Author : Thomas Nagy <[EMAIL PROTECTED]> * URL : http://freehackers.org/~tnagy/semantik.html * License : QPL Programming Lang: C++, Qt Description : mindmapping tool This is the successor of kdissert. The packaging is already available at <http://svn.debian.org/viewsvn/pkg-kde/kde-extras/semantik/>. The ftpmaster rejected the first upload because the QPL was incompatible with the GPL, but in fact the package does not link against anything under the GPL, so that objection appears to be irrelevant. While that is being sorted out, I just want to document that the package is being worked on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475361: ITP: chkconfig -- system tool to enable or disable system services
Package: wnpp Severity: wishlist Owner: Peter Eisentraut <[EMAIL PROTECTED]> * Package name: chkconfig Version : 10.3-90 Upstream Author : Michael Schroeder <[EMAIL PROTECTED]> * License : GPL Programming Lang: Perl Description : system tool to enable or disable system services Chkconfig is a utility to update and query runlevel information for system services. Chkconfig manipulates the numerous symbolic links in /etc/rc.d, to relieve system administrators of some of the drudgery of manually editing the symbolic links. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479953: uniform header for automated package maintenance emails
Package: general Severity: wishlist With all the (helpful) email that a package maintainer gets nowadays, BTS, PTS, Dak, DDPOMail robot, BTS link, etc., it becomes ever weirder to just filter them into appropriate mail folders. To illustrate that, here are procmail rules that I have assembled over time: * ^X-Debian-PR-Message: * ^X-Katie: * ^X-PTS- * ^From:.*(installer|katie|dak)@((ftp-master|spohr)\.debian\.org|backports\.org) * ^From: DDPOMail robot <[EMAIL PROTECTED]> * ^X-BTS-Link: I think it would be very nice to press these into some common form, such as X-Debian: BTS X-Debian: DAK X-Debian: PTS X-Debian: BTS-link or alternatively X-Debian-BTS: $moreinfo X-Debian-DAK: $moreinfo Maybe there is a quasi-standard for constructing these X- headers. Comments? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of new source formats project
On Wednesday 05 August 2009 14:21:54 Cyril Brulebois wrote: > Michael Banck (05/08/2009): > > On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote: > > > And for the format of the patch, I do not know what to tell them > > > apart that unified diff is the preferred format of some Debian > > > developers, > > > > It's the preferred format for 99% of all Free Software work/projects > > AFAICT. > > I was wondering who could be in the last 1%. At least OpenSceneGraph > people[1] prefer being sent the whole files. :) For everyone's further entertainment: The PostgreSQL project heavily prefers context diff patch submissions. This is also part of the reason why PostgreSQL is still stuck on CVS, because Git does not produce context diffs. There you go. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: renamings to remove extensions
On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote: > "Steve M. Robbins" writes: > > > I agree with Charles: this is unncessary, unproductive busy-work. > > The same characterisation could be given to other changes that raise the > quality of software in Debian (e.g. ensuring that commands are > accompanied by man pages, or that the package synopsis should not be > repeated in the extended description). This is not a useful analogy. Software will continue to work with or without documentation or description. Renaming programs breaks interfaces. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).
On Tue, 2009-09-29 at 13:36 +0900, Charles Plessy wrote: > I know that there has already been much of talk about this, but I am am > getting > more and more uncomfortable removing .pl or .sh extensions from programs when > upstream does not. At least in cases where the programs/scripts could be considered part of a programming interface, this requirement is approximately equivalent to requiring the exported symbols of libraries to conform to some spelling scheme. While Debian has occasionally altered or broken the exported interfaces of libraries in cases of severe trouble, this is not routinely done, and usually not merely in the name of prettiness. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
hardening-wrapper and debug symbols
I found out the hard way that when a package is built with hardening-wrapper, then debugging it with gdb results in seriously suboptimal backtraces like this: #0 0xb7d01424 in __kernel_vsyscall () #1 0xb7816d11 in ?? () #2 0xb7e973a2 in ?? () #3 0xb7e9784b in ?? () #4 0xb7f1c8fd in ?? () #5 0xb7eeae1b in ?? () #6 0xb7eebee7 in ?? () #7 0xb7e998d9 in ?? () #8 0xb774a7a5 in ?? () #9 0xb7d73011 in ?? () whether or not I have the -dbg package installed. If I rebuild the package without hardening-wrapper, I get a normal backtrace (with more or less information, depending on whether the -dbg package is installed). First of all, is this normal? Is there anything that can be done about it? The http://wiki.debian.org/Hardening page doesn't appear to cover it. Since debug packages and hardening-wrapper are both spreading in an ad-hoc way across packages, it appears that we'll end up with a rather nonuniform collection of packages that sometimes can be debugged, sometimes can be debugged a little bit, and sometimes cannot be debugged at all. Also, hardening-wrapper describes itself as "experimental" and "for build testing". Is it appropriate for large-scale use in mainstream packages intended for release? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Updating NEWS.Debian
I have seen some packages lately, most prominently apache2, that replace the entire NEWS.Debian file when they have some news to report. That way, older news are lost, and users who don't upgrade to every intermediate version (say, those who upgrade only between stable releases) are left in the dark. So if you have been doing that, please don't, and put the old news entries back at the bottom of the file. Bugs should probably be submitted about that kind of misuse. The Developer's Reference doesn't make this point entirely clear. Maybe that ought to be improved as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian/rules and environment variables
It has been suggested in bug #411520 that cdbs should be set up so that it preserves CFLAGS set in the environment. But I haven't found any clear specification about how debian/rules, being a makefile, should deal with environment variables. The best I could find is Policy 10.1 which states that "the following compilation parameters should be used: CC = gcc CFLAGS = -O2 -g -Wall" (It doesn't say, "these variables should be set this way".) It appears, however, that hardly any package (containing C language code) explicitly sets CC, and I think it is certainly useful to be able to set a different CC in the environment. Yet at the same time most packages set CFLAGS explicitly, overriding anything that's there before. The language in the policy and various rules templates appear to encourage that. But as the submitter of #411520 stated, it could also be useful to be able to build a package with different compiler flags. What this might come down to is that most variable assignments in rules files should be changed from = to ?=. Since debuild and pbuilder and other tools exist that give pretty good control over the environment for "final" package builds, I don't think there is much of a risk in allowing that, but I think some consistent approach ought to be worked out. Comments? -- please CC me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460504: dh_desktop/dh_icons madness
Package: general Severity: normal For a while now some folks have been going around asking various package maintainers to inject dh_icons and/or dh_desktop calls into the package build rules. The basic argument appears to be that your package needs to do this so that my desktop environment will work correctly. I don't think this approach has correct and sustainable principles. And what is more, if some random third packages or user environments dictate what other, unrelated packages have to do to function with them, we will in practice never reach a state where everything works. Furthermore, if other desktop environments come up with their own variants of icon caching of MIME file registration (since these are supposedly Free Desktop standards) or perhaps completely new file registration requirements, we will have an unmaintainable mess of competing implementations of registration scripts, and thousands of packages stuck in a transition somewhere between all of them. It seems to me that, in principle, if some third package or user environment wants something to be done for its own functional benefit, it should be its own responsibility to arrange that, instead of bothering thousands of other packages with it. This appears to be the only robust and maintainable approach. On a technical level, the best approach would appear to be implementing some sort of global dpkg postinst and postrm hooks. Perhaps there are other ideas, but the current approach needs to stop; it won't work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460504: dh_desktop/dh_icons madness
Josselin Mouette wrote: > Debian has always been about integration. Don’t you register your > documentation with doc-base so that your application integrates with > centralized documentation systems? I'm glad you bring up this comparison, but this is different. If someone neglects to do doc-base registration, his package's documentation won't be usable in a nice way. That directly affects the functionality of that package. If someone doesn't do dh_icons or dh_desktop registration, nothing changes for that package. It affects only users of whatever environment it is that appears to require this. > It is not a random user environment. It is the accepted standard for the > three main desktops we are shipping. I assume you are talking about GNOME, Xfce, and KDE here. KDE doesn't do any of this, so have doubts about the "accepted standard". It seems silly to request all KDE-related packages to jump through hoops so they work with GNOME. > Is it the desktop environment’s or the package’s own functional benefit > to have the application launched when you click on a file of the related > type, or to have a visible icon? This is merely a philosophical > question. It is to the desktop environment's benefit. The package will work fine in other environments. To pick a concrete example (bug #460449), if a GNOME user clicks on a kdissert file and things don't work, while they work just fine in KDE, then that is GNOME's problem, not kdissert's. > I thought dpkg triggers had been sufficiently advertised, but it seems > the mails haven’t reached the (deep ?) place you are living in. They indeed haven't, but since they appear to have reached the (shallow ?) place you are living in, why not use them? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460504: dh_desktop/dh_icons madness
Josselin Mouette wrote: > You are completely wrong on this topic. If you don’t use dh_icons, the > icons shipped in your package won’t be available even to the application > itself. I don't claim to know the technical details of this, but I don't have update-icon-caches installed and I have never had a missing icon. So again I suspect that this is an issue particular to some other environment. Which was my point. > > > I thought dpkg triggers had been sufficiently advertised, but it seems > > > the mails haven’t reached the (deep ?) place you are living in. > > > > They indeed haven't, but since they appear to have reached the (shallow > > ?) place you are living in, why not use them? > > If you had read them, you would also know this feature isn’t available > yet. So the transitive closure of this discussion is that you are just idly rambling. Thank you for your time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#602441: ITP: check-postgres -- script for monitoring PostgreSQL databases
Package: wnpp Severity: wishlist Owner: Peter Eisentraut * Package name: check-postgres Version : 2.14.3 Upstream Author : Greg Sabino Mullane * URL : http://bucardo.org/wiki/Check_postgres * License : BSD Programming Lang: Perl Description : script for monitoring PostgreSQL databases check_postgres is a Perl script that runs many different tests against one or more PostgreSQL databases. It uses the psql program to gather the information, and outputs the results in one of three formats: Nagios, MRTG, or simple. -- 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/20101104211234.9264.26611.report...@vanquo.pezone.net
Re: [GENERAL] Debian packages of 7.4
Oliver Elphick writes: > Please note that the python packages have been dropped from this build, > since the PyGreSQL source tree is now independent. Another maintainer > will take those on. Then why are plr, odbc, pgeasy and pgperl still in there? Those have been removed a longer time ago, or were never even in there in the first place. -- Peter Eisentraut [EMAIL PROTECTED]
Re: RFC: best practice creating database
Philipp Matthias Hahn wrote: > What is consideres best practice when a package uses a SQL database > (mysql, postgresql) and needs to create its own catalog and/or > tables? I say, create the tables when the package starts for the first time. As an analogy, programs using Berkeley-type databases normally set up their databases automatically when they run and don't require postinst processing.
Re: Common set of debconf templates
Marc Haber wrote: > Do we have infrastructure to handle different answers for the same > question? Maybe I'd like to have a different dbadmin password on my > postgresql database than on mysql? This discussion is about having a common set of chunks of text available somewhere for use in the debconf templates of individual packages, not about having a common set of debconf database entries.
Re: proposal: 'xterm' alternatives entry
martin f krafft wrote: > What do you think of this proposal. Are there any string points > *against* it? I have written scripts that explicitly call xterm because other terminal emulator programs under X (which I had preferred otherwise) couldn't handle certain programs. So in those situations it was not a generic name, but a specific program with specific capabilities.
Re: Automake & dependency tracking
Wouter Verhelst wrote: > Is there any other reason why we would still need to use automake's > dependency tracking anyway? I don't think so. You may want to use it while working on the package, but it seems like a fine idea to turn it off when finalizing the package.
Re: forwarding bugs to other packages
Bernd Eckenfels wrote: > Perhaps we need a "read this before submitting bugs against my > package" function in reportbugs :) That already exists: /usr/share/bug/. "reportbug galeon" provides a reasonable example run.
Considering the removal of ntpdate
As described in bug #514318 and elsewhere, the upstream NTP Project has deprecated the ntpdate program a long time ago, and it may be time to drop it from the Debian distribution. Most of the functionality of ntpdate is now provided by ntpd (stepping the clock without threshold, stepping the clock and exiting without running the server). The only exception that I'm aware of is that ntpd doesn't support the use of an outgoing unprivileged port (ntpdate -u). On the other hand, ntpdate is not developed anymore and has lots of bugs and inconveniences, and more lightweight alternatives such as rdate are available now as well. Nevertheless, since ntpdate used to be quite popular, I figured I'd better ask here for objections. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Outdated config.{sub,guess} package list
On Saturday 25 April 2009 02:51:40 Bradley Smith wrote:
> In light of the recent outdated config.{sub,guess} discussion I have
> decided to generate a list[0] of packages that have these files from before
> June 2006, which is when the AVR32 architecture was added.
> The list was generated using lintian 2.2.9 with this[1] patch. It is
> obviously possible that there are false positives in this list since the
> files might be not be actually used in the build, or they are copied from
> the host on clean etc. Please let me know if this is the case for one of
> your packages so I can avoid filing pointless bugs later on, although it
> is probably better to either remove/replace these files or override the
> lintian error.
Like lintian, your list falsely includes packages that use cdbs to build,
which automatically updates config.{sub,guess}.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
On Tuesday 28 April 2009 05:11:26 Russ Allbery wrote: > Noah Slater writes: > > As far as I see it: > > > > * Debian has dropped the Reply-To header because it is "harmful" in > > some way. > > > > * Debian has mandated that all replies must behave as if Reply-To > > existed. > > If this were the case, this would be an easy solution. However, it's > not. Debian has mandated that all *public* replies must behave as if > Reply-To existed, but all *private* replies behave as if it did not, and > repliers must distinguish between the two. One very practical problem I personally have with all of this is that on certain/some/many other mailing lists it is expected that you reply to the poster *and* the mailing list, to be sure that the poster gets your reply in case he is not subscribed (and also, because some people can then find replies to their personal problems more easily among the load of other messages). And with the multitudes of communities I deal with, I do not have the time or concentration or infallibility to scan the emails for "please cc me" or "please don't cc me" notes or even reverse-engineer the mailing list's posting or subscription policy to make sure the message gets to who needs to read it. Considering that most mailing list software has an elimnatecc feature, this is never really a problem for people who don't want that sort of behavior. Another problem on the flip side is that many people don't observe the "please cc me" requests on Debian mailing lists, and that way communication gets annoying. So in practical terms, it is safer to add more recipients to the message to make sure it is received and noticed, and let computer software do the filtering if necessary. That is just my practical experience in trying to communicate with people. The policy is what it is, but I don't like it, because it *hinders* rather than *helps* me communicate effectively. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Monday 04 May 2009 08:35:18 Guillem Jover wrote: I like this proposal. A small nit: > ,-- /usr/share/dpkg/build-options.mk > # distro defaults > FOO := distro Please be sure to use FOO = bar instead of ":=", unless you have determined that you really wanted ":=". In most cases it won't make a difference, but in some it does, and then it would behave contrary to how make usually treats variables. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Monday 04 May 2009 23:53:15 Manoj Srivastava wrote: > On Mon, May 04 2009, Peter Eisentraut wrote: > > Please be sure to use > > > > FOO = bar > > > > instead of ":=", unless you have determined that you really wanted ":=". > > In most cases it won't make a difference, but in some it does, and then > > it would behave contrary to how make usually treats variables. > > Why, in your opinion, would we want _not_ to use :=? What does > delayed evaluation buy us? That is up for debate, to some degree, I guess. I just want to make sure that a conscious decision is made either way. (In my experience, many uses of := are made without knowledge about what it does.) I think delayed evaluation is sort of the default way in which make treats variables, and so to avoid surprises and confusion, we should go with that one unless there is a specific reason otherwise. In practical terms, using delayed evaluation makes the outcome mostly independent of the order of the assignments. Which might become quite relevant when you design an include-a-bit-here, override-a-bit-there scheme that is supposed to be robust against all the nonsense that 1 source packages might do with it afterwards. Also note that someone who wants to be careful not to overwrite values supplied elsewhere might use ?=, which creates a delayed expansion type variable. In any case, we should be careful to define and document it one way or the other. Otherwise stuff like CPPFLAGS += -DFOO=$(BAR) has unclear behavior, depending on how or whether CPPFLAGS was previously set up. (And note that it will change if initially you don't define CPPFLAGS at all and in a later version make a := definition for it -- delayed variables being the default.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Saturday 09 May 2009 02:35:18 Micah Anderson wrote: > Some people clearly want postfix as the default MTA in Debian (I do), > and some people dont want the default to change from Exim. There are > some people who want something else, but so far that something else has > not be technically satisfactory. > > I think our problem is, how do we go about making this decision? There are really two orthogonal things being discussed here: One question is whether the default MTA should be a full or proper implementation versus a tiny and limited implementation (or -- the latest idea -- none at all). The other is whether, if the full implementation is chosen, it should be Exim or Postfix. It might lead this argument to a clearer conclusion if those two issues are treated separately. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
On Saturday 09 May 2009 00:58:56 Russ Allbery wrote: > Wouldn't our users expect to get the documentation > with many of these packages by default? Normally you do get some > documentation with things, and I've always been surprised by, say, ntp > not including any documentation without installing a separate package. We currently have that ntp suggests ntp-doc. Should that be changed to recommends? Perhaps a better policy or developer reference type guideline can come out of this thread about what kind of package should or should not depend on documentation in what way. It is kind of idiosyncratic that we insist on man pages being provided in a very specific way but are completely lax about other kinds of documentation, even if the latter might be the primary way to learn about a particular package's functionality. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Sunday 10 May 2009 13:56:04 Steve Langasek wrote: > I thought it was generally recognized that it's a Bad Idea to implement > config files using your interpreter's 'include' functionality, but that's > basically what we have here. Guillem pointed out one problem: Either you do it via a make include (which you have issues with), or you stop supporting calling debian/rules directly (inconvenient, probably prone to break things), or you require every package to handle it itself (unreliable, stupid) -- or you have the current situation, which is somewhere in the middle. For example, you possibly get something different depending on whether you call debian/rules, dpkg-buildpackage, debuild, or pbuilder. And the difference is hard to explain or analyze. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Monday 11 May 2009 00:06:09 Steve Langasek wrote: > Or maybe I've misunderstood, and there are > Debian developers who are building official packages for *upload* by > calling debian/rules by hand, and that's what people are concerned about > preserving while still getting the benefits of these distro build flags? > > I hadn't considered that possibility, because I can't imagine anyone > wanting to build packages that way instead of using dpkg-buildpackage, > which does it all in a single command. So I really don't consider that an > important use case, weighed against the concerns I outlined. I don't either, but it would probably be better to spell that out explicitly somewhere. > > For example, you possibly get something different depending on whether > > you call debian/rules, dpkg-buildpackage, debuild, or pbuilder. And the > > difference is hard to explain or analyze. > > Er, both debuild and pbuilder invoke dpkg-buildpackage. So it seems clear > to me that the only difference would be when calling debian/rules directly, > and at that point you're opting out of lots of other conveniences, not just > distro build policy. Well, debuild calls dpkg-buildpackage most of the time, unless you give a specific target (which would again possibly be of interest to those who are interested in calling debian/rules by hand for some reason). And that is also something newish. Plus, you can set separate environment variables for debuild. And probably also for pbuilder. And you can set environment variables or possibly site files within the pbuilder chroot. And there is also the option of pbuilder calling debuild -- who knows what that really does. So again some of this would become clearer if the actually supported build methods are more clearly spelled out. And then if someone could fold all of the functionality of debuild into dpkg-buildpackage, there would be even less distraction and variation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Monday 11 May 2009 07:45:02 Manoj Srivastava wrote: > Changing defaults with a large installed base begs the > question: Why? Random churn for churns sake is not the answer. But upgrades would (should?) keep exim installed. A new default would only affect new installations. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
On Monday 11 May 2009 09:49:31 Raphael Hertzog wrote: > On Mon, 11 May 2009, Peter Eisentraut wrote: > > Well, debuild calls dpkg-buildpackage most of the time, unless you give a > > specific target (which would again possibly be of interest to those who > > are interested in calling debian/rules by hand for some reason). And that > > is also something newish. > > Any pointer to this feature? Um, didn't you yourself orginally report this? (bug #476100) Anyway, the current man pages of debuild says this: """ An alternative way of using debuild is to use one or more of the parameters binary, binary-arch, binary-indep and clean, in which case debuild will attempt to gain root privileges and then run debian/rules with the given parameters. """ > > So again some of this would become clearer if the actually supported > > build methods are more clearly spelled out. And then if someone could > > fold all of the functionality of debuild into dpkg-buildpackage, there > > would be even less distraction and variation. > > It's planned, see #476221. That sounds like the ticket. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
architecture wildcards, type-handling, etc.
Since etch, dpkg has supported architecture wildcards such as "linux-any" and "any-powerpc", which can, among other things, be used to express Linux-only build dependencies like this: Build-Depends: libcap2-dev [linux-any] instead of one of the previous approaches: Build-Depends: libcap2-dev | not+linux-gnu # works, but not documented(?) or using type-handling to expand the wildcard manually: Build-Depends: libcap2-dev [alpha amd64 arm armeb armel hppa i386 ia64 lpia m32r m68k mips mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb sparc] The latter two approaches have obvious flaws, but it seems that no one is using the built-in dpkg approach. Is there anything wrong with it? Are people just not aware of it? Partial answer: pbuilder doesn't support that style yet, so you can't build packages that way (bug #363193). Comments? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: architecture wildcards, type-handling, etc.
On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote: > So, there's missing support in sbuild (#501230), which arguably is > a pretty recent bug report, but AFAIR I sent a mail to Ryan long time > ago when drafting the wildcard support and never heard back, but then > I never insisted again, so that's on me. > > Then the buildd network will need to be upgraded to use an sbuild > supporting that. I'm not sure if wanna-build might also need changes. > Lintian will need to be fixed as well once the buildd network supports > this. And then minor stuff like the vim debcontrol syntax highlighter > and similar. Would it be reasonable/acceptable to establish this issue as a squeeze release goal? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: architecture wildcards, type-handling, etc.
On Friday 15 May 2009 12:28:07 Riku Voipio wrote: > a release goal is IMHO something that needs fixes in a sweep of > packages in archive before release. This change OTOH just needs fixes > to sbuild and then some infrastructure work (deploying new sbuild/buildd > everywhere). Per upstream, this would still need fixes in pbuilder, lintian, possibly other build tools, and then sweep across all packages to replace type-handling or not+gnu-linux. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
cc vs gcc
There is a bit of discussion in bug #487546 about whether using cc or gcc as the compiler is appropriate. Particular questions: * Are Debian packages supposed to be built by default using /usr/bin/gcc (or whatever gcc is first in the path)? Or is it valid to use cc? * What interface is the "cc" alternative offering? Is it a GCC-compatible compiler, or a POSIX/SUS-compatible compiler? Currently, packages using cdbs will usually end up using CC=cc as their compiler, which is typically gcc, but doesn't have to. The submitter of the bug isn't really telling what exactly he is doing, but I guess it's conceivable to have another compiler than gcc in use, at least unless there is a ruling to the contrary on the above questions. Comments? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: CDBS - how to source a shell fragement before running ./configure?
On Tuesday 23 June 2009 08:22:17 Carsten Aulbert wrote: > Hi, > > as suggested on debian-user I repost my question here (sorry for the > cross post, but I think it's better than send to individual emails to > both lists, feel free to remove the other list) > > I'm currently packaging some "internal" software named gds with the > great CDBS package. However, I have a problem. One of the build > dependencies installs things into a non-standard system location (read > /opt) and I need to source one file to let the configure script know > where to look for certain software. > > Right now my debian/rules file looks like: > #!/usr/bin/make -f > > MAJOR_VER := 2.13 > DEB_TAR_SRCDIR:=gds-2.13.1 > INSTALL_PREFIX:=/opt/lscsoft/gds > > include /usr/share/cdbs/1/rules/tarball.mk > include /usr/share/cdbs/1/rules/debhelper.mk > include /usr/share/cdbs/1/class/autotools.mk > > DEB_CONFIGURE_NORMAL_ARGS := --prefix=$(INSTALL_PREFIX) > --libdir=$(INSTALL_PREFIX)/lib --enable-online --enable-dtt > CFLAGS += -D_POSIX_C_SOURCE=199309 -fPIC > > --8><8>< > > This one works provided I source /opt/foo/bar.sh before running > dpkg-buildpackage. Obviously, I would like to get this included into the > rules file, however, my current attempts failed since it seems that the > "source" only happens in a subshell and the remaining (inlcuded makefile > snippets odn't know about this) > > I'm adding this to the debian/rules file: > > makebuilddir/gds:: > source /opt/foo/bar.sh > > which subsequently leads the configure script to fail when detecting > software available under /opt It's a bit daring, but the following might work: DEB_CONFIGURE_INVOKE := . opt/foo/bar.sh ; $(DEB_CONFIGURE_INVOKE) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices
On Wednesday 24 June 2009 16:58:52 Gunnar Wolf wrote: > Driving licenses are expressly not accepted as official ID documents > in Mexico, even if they are government-issued. That just begs the question: official to whom, and why? Ultimately, the office clerk, the bar tender, or the key signer will have to use best judgement whether the evidence produced establishes a link between a person and an identity. Of course the bar tender for example might have a legal framework about what to accept and not to accept. But I don't think it is going to be successful to enforce a law like that for key signing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Clarification on the Origin: field in the Patch Tagging Guidelines?
On fre, 2012-06-15 at 09:39 -0400, Theodore Ts'o wrote: > I'm trying to understand a better way of using the Origin: field as > specified by DEP-3. > > I'm currently using something like this: > > Origin: > http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commitdiff;h=8f00911a21 > f4e95de84c60e09cc4df173e5b6701 > > since DEP-3 seems to strongly encourage a URL. But this seems really > ugly and painful to me. Looks fine to me. URLs are a uniform way to locate resources. Of course, it would be nicer if the git URL scheme had a way to specify what to check out. > >From reading the DEP-3, it mentions the use of the Commit: identifier, > but doesn't give any examples of how this would be done. Would > something like this be acceptable instead? > > Origin: upstream, Commit:8f00911a21 > > I assume as long as there is clear documentation in where to find the > canonical upstream repository (perhaps in debian/README.source or > debian/copyright) this would be considered acceptable? Or maybe it > would be better to include a new repository designator in the Patch > Tags, i.e.: > > Upstream-VCS: git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git > VCS-Branch: debian That doesn't excite me. Everyone would create their own non-*uniform* way to describe what they meant, and someone who wants to follow along will have to figure out loads of details, depending on what vcs is used, how it's hosted, etc. -- 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/1340318810.26286.93.ca...@vanquo.pezone.net
many packages fail to build twice in a row again
With recent dpkg(-source) changes, many packages are again failing to build twice in a row, because of uncommitted upstream changes. Fixing this was a lenny release goal, maybe it should be one again?!? Most importantly, maybe someone who has access to one of those build grids can run the old tests again, because I feel by accidentally stumbling upon these problems we will not be able to find and fix many of them any time soon. -- 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/1324411304.8520.3.ca...@vanquo.pezone.net
Bug#833682: ITP: cmark -- CommonMark parsing and rendering library and program in C
Package: wnpp Severity: wishlist Owner: Peter Eisentraut * Package name: cmark Version : 0.26.1 Upstream Author : John MacFarlane * URL : https://github.com/jgm/cmark * License : BSD, MIT Programming Lang: C Description : CommonMark parsing and rendering library and program in C cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec.
