Re: WolfSSL and Netatalk
Hi, > A few days ago, we released Netatalk 3.2.0 which comes bundled with a > customized subset of WolfSSL as SSL provider. > However, when I spoke to a Debian developer last year about this very > topic, they told me that using WolfSSL for packaged software in > Debian required some kind of special exemption and approval. > wolfssl is packaged in Debian, did you try to build netatalk with the packaged version? Debian doesn't like code copies in sources, so if it builds fine with the packaged version, removing it from the source that ends up in Debian will fix all issues. (I didn't check for licence compabilites and such things, guess you've done that already). Hope that helps, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: default network management tools (was: ifupdown maintenance)
On Tue, 2024-07-09 at 11:45 +0100, Simon McVittie wrote: > On Tue, 09 Jul 2024 at 10:57:39 +0200, Matthias Urlichs wrote: > > Agreed: either it's drop-in compatible or we may as well switch > > the > > default to NM and/or systemd-networkd. > > > > Well, here's a heretical thought: why don't we do that anyway, at > > least for new > > installations? > > To some extent, we are already there: for new laptop/desktop > installations, NM is already the default (certainly true for GNOME, > and hopefully for most/all of the other tasksel-supported desktops). > > For new server/embedded installations, I think networkd would be a > better default than ifupdown [] yes please, I would love to see Debian switch from ifupdown to NM/networkd. ifupdown was the perfect tool for the time it was created in, but things have advanced, and imho now is a good time to switch. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Look for keysign
Hi, > OK, don't beat me up too bad, even though I deserve it. I've been > away > a LONG time and did not retire properly nor update my key and my old > key has been removed from the keyring (as it should have been). I'm > hoping to get back involved so I'm wondering if any of you old timers > that I used to work with might be willing to sign my new key and/or > would be looking for possible keysigning in Philadelphia, PA area or > maybe even New Haven, CT area. > > Thanks for any guidance/help! https://wiki.debian.org/Keysigning/Offers#US might help. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Look for keysign
Hi Barry, On Thu, 2024-07-18 at 21:53 -0400, Barry deFreese wrote: > > I do and I have signed my new key with the old [] anything wrong with the old key? You could just use it again until you have signatures on the new one. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
#379113: python-soappy: fpconst failure on 64 Bit
Hello, since the last bugfixes/upload for the python-soappy package have been NMUs, I'm posting to debian-devel, too. * #379113 renders the package more or less useless on all 64bit platforms, at least its WSDL part. This should be fixed before etch comes out. * the fpconst URL mentioned in the report does not work, it's avaiable here: http://cheeseshop.python.org/pypi/fpconst/0.7.2 I'm also wondering why fpconst is not included in any default py package or available in it's own package - although packaging a single file sounds like overkill - fpconst provides some useful functions. * I've packaged a version of python-soappy which includes the fix for #379113 - would be good if somebody could look trough it and get it into Debian as I'm no DD. The files are here: http://debian.recluse.de/python-soappy/ Thanks a lot, best regards Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [q] maintainance of xfsprogs and util-linux
Hi, > Where stability is relative to the filesystem. :) > > I actually would like to see the latest xfsprogs in etch simply > because they contain fixes for the recent XFS kernel bugs, so if > you've been bitten, you can at least get your data back. > I've also run into problems with xfs due to hardware-failures which were not possible to fix with the xfs_repair included in etch (after I managed to get a disk dump from the buggy hardware..). WOuld be really nice to hve an uptodate version of the xfs tools in etch. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462879: ITP: python-cssutils -- CSS Cascading Style Sheets parser and builder
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: python-cssutils Version : 0.9.5a2 Upstream Author : Christof Hoeke * URL : http://cthedot.de/cssutils/ * License : LGPL Programming Lang: Python Description : CSS Cascading Style Sheets parser and builder Based upon and partly implements the following specifications (DOM only, not any rendering facilities): . * DOM Level 2 Style CSS * DOM Level 2 Style Stylesheets * CSSOM * CSS 2.1 * CSS 2.1 Errata * MediaQueries * Namespaces * Selectors -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
> I just completed an archive wide check on amd64/all packages by searching > for shell scripts in /bin:/usr/bin:/sbin:/usr/sbin:/etc/init.d:/usr/share > and checking them with checkbashisms from devscripts 2.10.13. script ./usr/bin/foo does not appear to be a /bin/sh script; skipping you should not list this as a problem. If a script is not a sh script, there's no reason to check for bashisms imho, especially if you have scripts for psh, ksh, csh or other weird shells. Best regards, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intend to hijack rrdtool
[CCing [EMAIL PROTECTED] as he is listed as Uploader] Hi, as rrdtool is a vital part of a lot of system monitoring solutions and should not go into Lenny in its current unmaintained state, I intend to hijack it. Unfortunately the current rrdtool package - is outdated. Currently we have 1.2.19 in testing, while 1.2.26 is out now, which does not only include a lot of bugfixes (not only for bugs in Debian's BTS) but also has a significantly improved performance. [EMAIL PROTECTED] was pinged several times about updating the package, in #431060 (4 times), on irc (#debian-devel/oftc, Dec 02 2007 03:45 CET) and also by a mail from me to him one week ago, which was also forwarded to the MIA team. - has a high bugcount: All bugs 25 RC bugs 2 I&N bugs 14 M&W bugs 8 F&P bugs 1 (while the only F&P bug the mentioned #431060, which is tagged pending for 33 days now, while being open for 220 days). Looking at the archived bugs there were only a few bugs closed by the current maintainer, all open bugs are several months old now. - Still ignores the new Python policy completely. If there are no objections I want to upload a new and heavily overworked package in about two weeks as the very soft freeze for Lenny will be in the early march, so there's at least some time left for intensive testing. Best regards, -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changing the default syslog daemon for lenny?
> rsyslog could of > course read configs from syslog.d and rsyslog.d, and admins could > install those under /etc/rsyslog.d/ or edit /etc/rsyslog.conf to make > use of those additional features. This would also be a way to solve #311812. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to hijack rrdtool
Bernd Zeimetz wrote: > [CCing [EMAIL PROTECTED] as he is listed as Uploader] > > Hi, > > as rrdtool is a vital part of a lot of system monitoring solutions and > should not go into Lenny in its current unmaintained state, I intend to > hijack it. After a lot of positiv reactions on my intention to hijack rrdtool, and several offers to co-maintain the package in a team, the package would be maintained by (at least) Sebastian Harl ([EMAIL PROTECTED]), Alexander Wirt (formorer) and me. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to hijack rrdtool
Heya, after so many positive responses we've decided to upload rrdtool today, also not to loose time as it has to go trough NEW. It is team-maintained and living in a git repository now. Maintainer: Debian RRDtool Team <[EMAIL PROTECTED]> Vcs-Browser: http://git.snow-crash.org/?p=pkg-rrdtool.git;a=summary Vcs-Git: git://git.snow-crash.org/pkg-rrdtool.git/ Best regards, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to hijack rrdtool
> There *is* a pkg-rrdtool team in alioth, and a public SVN (that you see > was > having commits as of two days ago). I had problems to access my @debian.org > address and just saw your mails today. I've offered to help you with the package several times during the last months, I don't understand why you did not point me to the team. As rrdtool is not just 'some' package, but one of the most important pieces in most monitoring tools, it needs much more time and work than it had during the last years. Proper maintenance of a package also means to update to new upstream versions in time, and not short before a freeze of a new Debian release. While we don't want to fight about a package, we insist on a good maintenance of rrdtool, therefore I'd suggest to merge our work and the two teams (even if I have the impression that you're the only active person in your team). Best regards, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to hijack rrdtool
> Do you prefer your git, or the Debian SVN or maybe git.debian.org? I think using alioth's services would be the best way to go. We'd prefer git, but svn is fine, too. What's your favourite? I'd offer to spend the time to merge your and our work. As the old packaging never had a copyright information form the packager I'd suggest to use as much of the new package as possible, and merge your changes in, so the Debian packaging has a proper license. Are you around on irc these days? Probably the fastest way to discuss things. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467038: RFP: pytrainer -- Free Sport Training Center
> Unfortunately, I'm dumb when it comes at Python stuff, so, while I'd > happily give some help, imagining to package this myself would be too > ambitious... I'll help out if there're Python problems. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host
Joel Franco wrote: > Package: wnpp > Severity: wishlist > Owner: Joel Franco <[EMAIL PROTECTED]> > > > * Package name: winhardware > Version : 0.0.14 > Upstream Author : Joel Franco <[EMAIL PROTECTED]> > * URL : Not yet > * License : GPL > Programming Lang: shell script > Description : hardware summary report from a Win32 host > > Gets the basic hardware report from a Win32 computer including > processor, last user, memory, disk, motherboard, network interface card > and others. Uses the WMI interface. are you going to use wmic and/or winexe for that? Then I'd suggest to add teh script to the wmi-client package instead of wasting a full package for a single shellscript. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host
Hi, > I have no relationship with the wmi-client package nor knows the > mainteiner. To agree with your opinion, i should work close to that > mantainer and this could make the work a lot harder in the mean that i > have to commnuicate with him. uh, ntot really. You've just sent him an email ;) The package is maintained by me in the Zenoss team... If you want to provide such a script, as examples or for /usr/bin (with manpage then please), I could give you access to the svn, so you can maintain it in the debian directory of the package, not a big problem. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: nagiosql -- Web based administration tool for Nagios
Hi, > NagiosQL is a web based administration tool for Nagios 2.x. It helps you Is it compatible with Nagios 3? Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help required regarding bug - #436681
hi, > >"Debian Bug report logs - > #436681 > backuppc: Web interface password > publicly visible " >link > http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=436681 If you give the page a close look you can see, that the bug was closed last year, so you should probably choose another bug to fix. To fix a current bug, you should install Debian testing (called Lenny, as it is the upcoming Dbeian release) instead of the stable version (Etch). Then the best (for Debian) would be if you have a look at the release critical bugs, and bugs which are marked as a release goal, as they're most important to be fixed. So have a look at http://bts.turmzimmer.net/details.php?bydist=any&sortby=packages&ignhinted=on&ignclaimed=on&ignpending=on&ignpatch=on&ignmerged=on&igncontrib=on&ignnonfree=on&ignbritney=on&ignotherfixed=on&ipv6=on&new=7&refresh=1800 which should give you a nice list of bugs to work on. Interesting to read for you is probably http://www.debian.org/doc/maint-guide/ which gives a nice overview about the packaging and files in the debian directory. Chances are good that you'll have to work on them. If you've prepared a patch/fix for a bug, just let me know and I'll review and upload it. Best regards, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-sphinx or sphinx?
Hi, > If it's just a tool, that name is fine. But if it also contains modules, then > I > think you should go for python-*. Perhaps you could make two binary packages, > one for the module(s) and one for the tool, although that could be > overkilling... looks more like a module in my eyes, so python-sphinx Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Hi Christoph,
> So I'm wondering what other developers do. Are you using NFS at all? Are
> you putting all your work under repository control and check the files out
> to a local disk and back in to the server? I consider keeping $HOME on NFS
> but symlink $HOME/debian to /mnt/localdisk/debian or something like that.
All the stuff I'm working on is on a server somewhere in the net (either
on alioth, sf.net, berlios,. or my own server), and whereever I want
to work on something I get a checkout and commit before switching
computers. To checkout things like the DPMT/PAPT repositories I have
small scripts, as I have a checkout of all trunks on my disk usually.
Here is an example snippet:
=schnipp==
URL=svn+ssh://svn.debian.org/svn/python-modules/packages
svn ls ${URL} | sed 's,/$,,' | while read dir; do
if [ -d ${dir} ]; then
svn up ${dir}
else
svn co ${URL}/${dir}/trunk ${dir}
fi
done
=schnapp==
NFS is something I avoid if possible.
Hope that helps,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
> Why did I guess the name of binutils' maintainer correctly _before_ > looking into the PTS? You're not alone. > I bet that multiarch gets included into Ubuntu about two weeks after > we released lenny without multiarch. That's indeed the way the maintainer seems to work, and he keeps sitting on way too many packages, stopping progress in Debian. Thanks for the fish. Multiarch should indeed go into Lenny, please consider an exception for it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#475971: This is caused by LDFLAGS being set in the environment (by dpkg-buildpacakge)
Adeodato Simó wrote: > After a bit of inspection, the root of this FTBFS seems to be > dpkg-buildpackage having set LDFLAGS in the environment (even to an > empty value, mind you). Two of my packages were affected by this uglyness, too. If you use LDFLAGS as _make_ variable to build up the linker flags you need, for some reason this _make_ variable is now exported into the environment, resulting in this weirdness. I'm not sure where the sense behind all this is - I prety much know when I want to have such flags in the environment or not, there's no need that dpkg helps me with that. For one package I used unset on all this environment nonsense in the build target, for one LDFLAGS was renamed to LINKER_FLAGS. I'm pretty much annoyed that those hacks are necesary at all. Just another, untested change in dpkg which resulted in a lot of unnecessary FTBFSs. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intend to hijack GnuPG
Hi, >> Various people can't reach him[2]. On the other hand, he seems to be >> active on Ubuntu[3], he joined to Launchpad security this january at >> least. Moritz Muehlenhoff noted[4] that it should be hijacked and get in >> shape for Lenny. Thus I have created a preliminary package[5] which >> fixes some important bugs and get v1.4.9 to the archive. >> Does the Release Team allow this hijack, should I upload it as an NMU >> instead or just leave it alone? > > > I think this is a very good initiative. However, I encourage you to > setup a collaborative project for this (on Alioth, with repository, > mailing-list, etc.). Several people have expressed > interest in helping to maintain Gnupg and this is certainly something > that should, from the start, be maintained by more than one person. What's the status here? Is there a team being setup, or anybody else working on gnupg? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building with -msse
> And check if there is any sse3 support. That one needs cpu suport on > amd64 too. Are there amd64 machines which do *not* support sse3? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building with -msse
> Does any Athlon64 support sse3? yes, since Venice Stepping E3 and San Diego Stepping E4. But thanks for the reminder, there were indeed CPUs before that. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#478167: ITP: cowpoke -- Builds a single Debian source package with a remote cowbuilder
> Programming Lang: bash > Description : Builds a single Debian source package with a remote > cowbuilder > > The cowpoke script automates the task of sending a package to a remote do we really need a package for a single script?! I think such stuff could go into the pbuilder package, too. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VLC 0.8.6a - Why hasn't the package been upgraded?
Hi, > If you want to use very latest softwares (even with some trouble), use > * testing (now lenny) or > * unstable (sid) or create a backport, or look at backports.org if there's one already. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486909: ITP: python-creoleparser -- Parser for the Creole common wiki markup language
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: python-creoleparser Version : 0.5.0 Upstream Author : Stephen Day <[EMAIL PROTECTED]> * URL : http://creoleparser.googlepages.com * License : MIT Programming Lang: Python Description : Parser for the Creole common wiki markup language Creoleparser is a Python library for converting Creole wiki markup for output on the web. It is a full implementation of the Creole 1.0 specification and aims to follow the spec exactly. Creole is a common wiki markup language to be used across different wikis. It's not replacing existing markup but instead enabling wiki users to transfer content seamlessly across wikis, and for novice users to contribute more easily. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487020: ITP: libtext-wikicreole-perl -- Convert Wiki Creole 1.0 markup to XHTML
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: libtext-wikicreole-perl Version : 0.05 Upstream Author : Jason Burnett <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Text-WikiCreole/ * License : same as Perl Programming Lang: Perl Description : Convert Wiki Creole 1.0 markup to XHTML Text::WikiCreole implements the Wiki Creole markup language, version 1.0. It reads Creole 1.0 markup and returns XHTML. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector)
Hi,
I'm forwarding this orphaning bug to debian-devel as I hope this rises
the chances to find somebody who is willing to take care of ispell.
According to http://ficus-www.cs.ucla.edu/geoff/ispell.html the version
in Debian is pretty outdated, also there's a number of bugs to triage...
Best regards,
Bernd
Original Message
Subject: Bug#487732: O: ispell -- International Ispell (an interactive
spelling corrector)
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Package: wnpp
Severity: normal
The current maintainer of ispell, David Coe <[EMAIL PROTECTED]>,
is apparently not active anymore. Therefore, I orphan this package
now. If you want to be the new maintainer, please take it -- see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.
Some information about this package:
Package: ispell
Binary: iamerican, ispell, ibritish
Version: 3.1.20.0-4.4
Priority: standard
Section: text
Maintainer: David Coe <[EMAIL PROTECTED]>
Build-Depends: bison, texinfo, texi2html, debhelper (>= 4), wamerican
(>= 5-2), wbritish (>= 5-2), libncurses5-dev, textutils,
dictionaries-common-dev (>= 0.20)
Architecture: any
Standards-Version: 3.6.1
Format: 1.0
Directory: pool/main/i/ispell
Files: 1f1959139ac18c82eed5472481fcab27 713 ispell_3.1.20.0-4.4.dsc
8376d8c63c6066fc2e4af6cb49629f60 675385 ispell_3.1.20.0.orig.tar.gz
ade3758731178717bbe2cfa687712b9c 54441 ispell_3.1.20.0-4.4.diff.gz
Package: iamerican
Priority: standard
Section: text
Installed-Size: 1189
Maintainer: David Coe <[EMAIL PROTECTED]>
Architecture: i386
Source: ispell
Version: 3.1.20.0-4.4
Provides: ispell-dictionary
Depends: ispell, debconf | debconf-2.0, dictionaries-common (>= 0.20),
debconf (>= 0.5) | debconf-2.0
Recommends: wamerican
Conflicts: ispell (<< 3.1.18-2)
Filename: pool/main/i/ispell/iamerican_3.1.20.0-4.4_i386.deb
Size: 425774
MD5sum: d344414aadadca581c0f1503f2214e6e
SHA1: 925e2a8e159d2325054fbb7a0b446a999d567970
SHA256: f809fc3b952cd7f8703d69b988ed8e847ac7112b8e4024d9d6171a4b65d7ca9c
Description: An American English dictionary for ispell
This is the americanmed+ dictionary, as supplied with
the source for ispell, with additional words added from
the more comprehensive wamerican wordlist package.
.
This package also recommends wamerican because ispell's
(L)ookup command needs a wordlist.
Tag: made-of::data:dictionary, role::app-data, use::checking
Package: ibritish
Priority: standard
Section: text
Installed-Size: 1189
Maintainer: David Coe <[EMAIL PROTECTED]>
Architecture: i386
Source: ispell
Version: 3.1.20.0-4.4
Provides: ispell-dictionary
Depends: ispell, debconf | debconf-2.0, dictionaries-common (>= 0.20),
debconf (>= 0.5) | debconf-2.0
Recommends: wbritish
Conflicts: ispell (<< 3.1.18-2)
Filename: pool/main/i/ispell/ibritish_3.1.20.0-4.4_i386.deb
Size: 425386
MD5sum: c3e9f83488e71e18e3aadd2ced66d942
SHA1: 3ec5ffc995a47b32f8b5ae53c637bc417fb5b211
SHA256: c372d6345cd6cdfe264e4088683fcb4bd5085784469480abb5c3210b42f59c60
Description: A British English dictionary for ispell
This is the britishmed+ dictionary, as supplied with
the source for ispell, with additional words added from
the more comprehensive wbritish wordlist package.
.
This package also recommends wbritish because ispell's
(L)ookup command needs a wordlist.
Tag: made-of::data:dictionary, role::app-data, use::checking
Task: british
Package: ispell
Priority: standard
Section: text
Installed-Size: 322
Maintainer: David Coe <[EMAIL PROTECTED]>
Architecture: i386
Version: 3.1.20.0-4.4
Depends: dictionaries-common (>= 0.20), iamerican | ispell-dictionary,
libc6 (>= 2.5-5), libncurses5 (>= 5.4-5)
Recommends: wordlist
Suggests: spell
Filename: pool/main/i/ispell/ispell_3.1.20.0-4.4_i386.deb
Size: 159754
MD5sum: 25406835d42abe85fa00b3324f89d4a8
SHA1: 1ba72a618b6aa2b6b5efc227490ff99b9f1d4d17
SHA256: 815cb1d82c00524daf2d2226041627dbab8c77317deae38933c4fbfad977faf9
Description: International Ispell (an interactive spelling corrector)
Ispell corrects spelling in plain text, LaTeX, sgml/html/xml,
and nroff files. [x]Emacs and jed have nice interfaces to
ispell, and ispell works from many other tools and from the
command line as well.
.
No ispell dictionaries are included in this package; you must install
at least one of them ("iamerican" is the default dependency for no
good reason); install the "ispell-dictionary" package(s) for the
language(s) you and your users will want to spell-check.
.
It's a good idea to install "wordlist" package(s) for the same
language(s), because they'll be used by ispell's (L)ookup command.
Tag: interface::text-mode, role::program, scope::utility,
uitoolkit::ncurses, works-with::dictionary
--
Bernd Zeimetz Debi
Re: ia32-libs transition
Josselin Mouette wrote: > Le mardi 30 juin 2009 à 01:55 +0100, Aneurin Price a écrit : >> Is there any way of preventing this kind of major breakage in the future? >> I don't think many people expect that upgrading one package will FUBAR >> the packaging system. > > Report a critical bug against the package. Arrange so that it can never > migrate to testing. > >> Is there any chance of Wine becoming functional on amd64 in the forseeable >> future? > > Yes: hijack the ia32-libs package. > please do so. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
Re: [DebianGIS-dev] maps / coastline files within Debian
Francesco P. Lovergine wrote: > On Tue, Jun 16, 2009 at 10:12:02PM +0100, Alastair McKinstry wrote: >> Does anyone know this code? It appears as though the gmt-coast-low is >> not sufficient for zyGrib and magics++, >> and I'm not familiar with the history of "gmt" beyond the README. Any >> ideas or recommendations as to how to proceed? >> > > Just for note, the downloading script can be used in non interactive > way so a debconf based postinst step to download at installation > (or any later) time the required files could be considered. I'm too > lazy to provide that myself, but a patch for that could be considered for > the gmt data package could be useful. > > That said, the whole arch-indep > data set is probably much less a concerning for storage of some years > ago, but that could be confirmed only by ftp-masters and mirror > maintainers. There were some discussions in the past about a data > providing infrastructure, but I missed the whole thread conclusion > (if any). > We're still waiting for the necessary hardware (mainly: storage) to be sponsored... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: > Please do files bugs about issues you consider blockers for > ia32-libs-tools and squeeze and please include if that applies even if > there is the old ia32-libs in parallel to it (i.e. when it doesn't get > pulled in on upgrades). The package is a mess, the idea is broken by the design and it has numerous RC bugs. Do you *really* want to have more reasons? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: >> and it has numerous RC bugs. > > Lets see: > http://packages.qa.debian.org/i/ia32-libs-tools.html > > RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt completely while removing the ia32 packages is not nice. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: > Bernd Zeimetz writes: > >> Goswin von Brederlow wrote: >>>> and it has numerous RC bugs. >>> Lets see: >>> http://packages.qa.debian.org/i/ia32-libs-tools.html >>> >>> RC bugs: 1 >> There were 6 bugs when I looked at the page before writing my mail, guess >> you've >> merged/downgraded/... the others.I should have added another one - breaking >> apt > > Most importantly fixed in an upload or assigned to the package that > did the actual breaking. I got a number of non-bugs caused by > libc6-i386 changing lib32 from link to directory too: Like > lib32nss-mdns being uninstallable because libc6-i386 conflicts with > it. > >> completely while removing the ia32 packages is not nice. Remember, I asked you on irc? It leaves empty files somewhere in /var/lib/apt which breaks apt pretty much... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537499: RFP: weaveserver -- Secure data sharing server for firefox/iceweasel
Package: wnpp Severity: wishlist * Package name: weaveserver Upstream Author : Mozilla Labs. * URL : https://wiki.mozilla.org/Labs/Weave * License : MPL 1.1/GPL 2.0/LGPL 2.1 Programming Lang: php, perl Description : Secure data sharing server for firefox/iceweasel (this is not a proper description, just the usual babbling from the web page) Weave is a Mozilla Labs project to integrate web services into Firefox by allowing users to securely share their data with other users and 3rd parties. As such, Weave encompasses a Firefox add-on, a server component, data sharing APIs, etc. The Weave Server allows the firefox client addon to store and retrieve data and passwords from the browser. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Intend to create an -fPIC library package...
Peter Samuelson wrote: > 2) Runtime linking. This is overhead at application startup time. >Something that embeds an SQL engine should not, I think, start up too >frequently. Am I wrong? We're talking about amarok here. As a medi aplayer I could imagine it will be starte several times per day... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Siggy Brentrup wrote: >> Folks, there was a longish discussion on IRC starting about an hour >> ago about dash and bash. > > These discussions are extremely long standing :) The move away from > bash has been aimed at long before I vanished from the project in 2004. > I'm really upset that 5 years are not enough to accomplish the move. So how many of the bashism bugs did you fix? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash without dash essential
Steve Langasek wrote: > On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote: >> Steve, let's take a step back and calm down. > >> Are you saying that your objection to engineering a solution where >> dash doesn't need to be essential is that it's not worth the effort? >> I *think* that was the point of your message but am not entirely sure. > > Yes, that's definitely my position. From what I can see, engineering a > solution where dash doesn't need to be essential isn't worth *any* effort, > because IMHO, so far the arguments for being able to remove dash from the > system appear entirely contrived. > +1 from me. Making things more complicated when there is no need to do so is a waste of time. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The insserv mess - or how not to change important parts of systems
Dear Petter, this is an excerpt from your last sysvinit upload's changelog: sysvinit (2.87dsf-2) unstable; urgency=low * Let sysv-rc depend on insserv (>= 1.12.0-10) to activate dependency based boot sequencing by default. Do you *REALLY* think that changing such important pieces of systems should be done without discussing it first on an appropriate list like debian-devel? Also I'm wondering when and how you've tested the insserv package. Looking at bugs like #475478 and #538959 I start to wonder if you did an appropriate testing at all (Hint: there is experimental to test things). And looking at replies like " Insserv will become essential together with sysv-rc, and is not supposed to be simple to remove any more. Dependency based boot sequencing is going to become the default and suppoted boot sequencing method. I'll remove the option to disable it. " to bug reports I'm not sure any more if you should maintain such an essential package. Yes, this mail has a bit more harsh tone than it should probably have, but it pretty much reflects the result of having fun with broken systems in the morning. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
Re: eiskaltdc extra licence
Andrey Tataranovich wrote: > Hi all, > > I working on packaging eiskaltdc - direct connect client (see #540458). > This program have extra licence information (you can see it on > http://rootshell.be/~ice/tmp/COPYING) wich installed by default in > /usr/share/eiskaltdc/COPYING. This produced lintian warning > (W: eiskaltdc: extra-license-file usr/share/eiskaltdc/COPYING). > > This file is used in About/Licence dialog. > > What should I do to satisfy DEBIAN policy? > > a) rename/move this file another place and patch code > b) add lintian override c) patch it to display /usr/share/doc/$package/copyright ? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: eiskaltdc extra licence
Rene Engelhard wrote: > Hi, > > On Mon, Aug 10, 2009 at 09:50:07PM +0200, Bernd Zeimetz wrote: >> c) patch it to display /usr/share/doc/$package/copyright ? > > That would be against policy. > No package is supposed to rely on /usr/share/doc/$package for doing stuff. if [ -f $file ]; then cat $file; else echo 'admin was stupid'; fi -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: can i use 'piuparts' within 'pbuilder'
Leinier Cruz Salfran wrote: > hello dd. > > 1- can i use 'piuparts' within 'pbuilder'? You should be able to, but I guess it takes *way* tooo much time to be useful. Have a look at the pbuilder hook examples in /usr/share/doc/pbuilder/examples - they do some minimal testing and are what I definitely recommend. > 2- is required use 'piuparts' in order to upload a package? No, but recommended. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python 2.6? A Python transition?
Josselin Mouette wrote: > There are two problems with adding Python 2.6 to the supported versions. > > First, the installation path changed from site-packages to > dist-packages. This means that most Python packages will need two > changes: > * passing --install-layout=deb to setup.py > * fixing paths from site-packages to *-packages (since the path > now depends on the Python version, yay) Also see /usr/share/python/python.mk for some good ideas on how to handle this. If you need some examples - look into the python-modules team svn, some of the packages have been changed for Python 2.6 already. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python 2.6? A Python transition?
Michal Čihař wrote: > Hi > > Dne Wed, 26 Aug 2009 11:00:40 +0200 > Josselin Mouette napsal(a): > >> To put it simply: >> * Most packages using cdbs should be safe. >> * Some packages using dh (most of those building only one binary >> package) should be safe. >> * All the rest needs updating, at least for the new setup.py >> option. > > Well for most packages it just means merging back Ubuntu changes ... > just if maintainer would be notified about them, it would make it much > easier. Unfortunately the transition was messed up in Ubuntu at too many places. Including disabling unit tests to make the package "build" with Python 2.6. You need to make sure that the Ubuntu patches really do what you expect them to do. In a lot of cases it may be easier to migrate to dh :) -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543783: ITP: douf00 -- fat free presentations
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz * Package name: douf00 Upstream Author : natano (Martin Ptacek) * URL : http://github.com/natano/presentation/ * License : MIT Programming Lang: Python Description : fat free presentations There is no real description yet, it will be added as soon as upstream finished to write the documentation :) DouF00 is a really awesome tool to do presentations, it was written to make all these things right which are annoying with software like OOo. It is fast, easy to use and is just what you need at the next conference. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: how to upload a debian binary for lyx
belahcene wrote: > Hi, > > I generate a debian package for the more recent lyx (1.6.4), I want to > share it, how and where to upload it. You should talk to the Debian lyx maintainers, which is as far as I remember a team, so you could probably join it. Working on packages somewhere else is a waste of time, as it needs to be done in Debian properly. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: responsibility for iptables bug
Marco d'Itri wrote: > On Sep 14, jida...@jidanni.org wrote: > >> LB> You could file this a a wishlist bug report against the iptables >> LB> package, and see if the maintainer wish to add this file (or a larger >> LB> /etc/sysctl.d/iptables.conf with some sane defaults). > What makes you believe that the kernel defaults are not sane? > This is an extra feature which is not required by most people, has a > computational and memory cost and should not be enabled unless needed. > This bug should just be closed, or at least only commented by people who > actually know what they are talking about. This bug should *NOT* be closed. Getting a deprecation warning for a simple and common use of iptables is a bug somewhere, either in iptables or the kernel. And I really fail to understand why the iptables maintainer thinks it is useful in any way to tag this bug wontfix without any comment at all. Are people supposed to live with that deprecation warning forever? I'd expect that Debian provides useful defaults, running in such a warning is not useful. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#546831: ITP: perdition-pbs -- POP / IMAP Before SMTP Tool
Horms wrote: > Package: wnpp > Severity: wishlist > Owner: Horms > > > * Package name: perdition-pbs > Version : 1.0.0 > Upstream Author : Simon Horman > * URL : http://www.vergenet.net/linux/perdition/pbs.shtml > * License : GPL > Programming Lang: C > Description : POP / IMAP Before SMTP Tool People are still using pop/imap before smtp? OMG. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#546831: ITP: perdition-pbs -- POP / IMAP Before SMTP Tool
Marco d'Itri wrote: > On Sep 16, Bernd Zeimetz wrote: > >> People are still using pop/imap before smtp? OMG. > People are also still using 10 years old systems in production, so > anything that helps integrating them in modern infrastructure is > useful. If I remember right I've disabled pop/imap before smtp on the last server about 10 years ago... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Changes in the maintenance of the Developers Reference
Bill Allombert wrote: > debian-de...@l.d.o could be a better channel for the developers-reference > discussions, though with the downside of yet more outside traffic than > debian-policy. Not really - d-devel is a way too messy list for a useful discussion. Not sure if there is a better list to use for that. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python2.6 in unstable?
Luk Claes wrote: > Bastian Venthur wrote: >> Stefano Zacchiroli schrieb: >>> On Thu, Sep 03, 2009 at 04:32:10PM +0800, Paul Wise wrote: >>>> See the recent threads on debian-python, debian-devel and debian-release. >>> Given that Bastian's post is the first time I've seen the question >>> posed straight away for the -devel public, can you please summarize an >>> answer for us? >> Since I didn't receive an answer on my question I summarize what I >> found. Python 2.6 will definitely not become the standard Python for >> Squeeze. It is also very unlikely that it will enter unstable soon as >> far as I understood due the way 2.6 handles site packages and the >> resulting packaging issues. > > Python 2.6 should become the standard Python for Squeeze. Ack. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: get-orig-source: possible MBF
Jakub Wilk wrote: > I performed an experiment, in which I tried to check if source packages > are providing get-orig-source targets that comply with the Debian > Policy. Let me quote: > > | `get-orig-source' (optional) As long as the policy says optional I can't see a reason for a MBF. Not to forget that I think that the get-orig-source target is more and more superseded by using debcheckout and providing vcs informations in debian/control. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/rules "make -f" restriction
Tobi wrote: > Or should we just add a Linitan override? Or do we really need to use > "#!/usr/bin/make -f" as the shebang line in debian/rules? Use make. it is able to do all the things you're doing right now, including to do different stuff based on an environment setting. > Personally I would vote for dropping the make requirement from the > policy all together. I might be mistaken, but I think none of the > build tools calls make explicitly with debian/rules. A debian/rules > might even be a Python or Rake script. Oh god, no. And I'm not even going to explain why.Think about it. > > Tobias > > [1]: > http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh > > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553359: ITP: darktable -- virtual lighttable and darkroom for photographers
Package: wnpp Severity: wishlist Owner: Debian PhotoTools Maintainers * Package name: darktable Version : 0.3 Upstream Author : Johannes Hanika * URL : http://darktable.sourceforge.net/ * License : GPL3 or later Programming Lang: Description : virtual lighttable and darkroom for photographers darktable manages your digital negatives in a database and lets you view them through a zoomable lighttable. it also enables you to develop raw images and enhance them. It tries to fill the gap between the many excellent existing free raw converters and image management tools (such as ufraw or f-spot). The user interface is built around efficient caching of image metadata and mipmaps, all stored in a database. the user will always be able to interact, even if the full resolution image is not yet loaded. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Cross compiler ITP (armel)
Ben Hutchings wrote: > You can disagree all you like, but I believe that the FTP team will > currently reject any new packages that use source code from their build- > dependencies. It would likely be a waste of Hector's time to continue > with this approach. So if that is a problem - why not enhance the gcc packaging to build the cross-compiler packages? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: please test with tiff 4.0.0~beta4 from experimental
Goswin von Brederlow wrote: > Bernd Zeimetz writes: > >> Jay Berkenbilt wrote: >>> If you maintain a debian package that directly uses libtiff or if you >>> maintain software that uses libtiff, it would be a great help if you >>> could test your packages against the version of libtiff in experimental, >>> 4.0.0~beta4. If you find any problems, please report them as bugs >>> against the tiff package in the debian BTS. If you test and everything >>> works fine, I'd like to know that as well as I can communicate back to >>> upstream. >> I gave radiance a try and everything seems to work as expected. Just >> uploaded it >> to unstable in case somebody wants to play with the latest cvs head and the >> new >> libtiff. > > Unstable or experimental? If you build against experimental libtiff > then you should have uploaded to experimental. Err yes. s/unstable/experimental/ -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build logs from local builds
Adam Majer wrote: > People are lazy and like myself don't want to sync pbuilder and > related stuff every time I want to upload something. Since my box is > rarely up to date, this can result in dependencies lagging > somewhat compared to official buildd. I generally don't check for any > build-depends problems anyway with pbuilder unless buildd chokes. And so you put the problem on the shoulders of the buildd admins. Sorry, but that behaviour makes me choke. I've CCed DAM as this behaviour is absolutely not acceptable for DDs. > And for the Arch:all packages? I guess no check for this with lazy > maintainer. > > So how do I compare with the other maintainers? Or do all maintainers > run pbuilder religiously for each upload? Thats what they're required to do and what we tell new developers. > The requirement not allowing source only uploads is childish at best - > it treats DD as children that can't check their packages compile on > their own box. No. Even DDs make mistakes and requiring to build packages in a clean chroot before uploading them is a *very* good way to avoid a lot of annoying bugs. > I'm all in favour of removing uploaded binaries. But also allow source > only uploads. No way. At least to stop people like you who prefer to let the buildd admins do *your* work. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F signature.asc Description: OpenPGP digital signature
Re: nexuiz-data does not fit on a single CD
Gustavo Noronha Silva wrote: > On Fri, 2009-11-20 at 14:00 +0100, Stefano Zacchiroli wrote: >> the Debian CD team (in the person of Steve McIntyre) has noted the >> enormous size of nexuiz-data, which means the package won't fit on a >> single CD. I'm setting severity serious because this de facto means the >> package cannot be distributed to our CD users. I agree that the severity >> can be controversial since we have other ways of distributing packages; >> feel free to downgrade, better if after discussion with the release team >> (even better by reducing the size ;-)) > > This is silly. I haven't seen bug reports about packages not fitting in > diskettes, and it would not make any sense if they were filed! =). > > The world moved on, CDs are getting too small. It's a technical > limitation which can be overcome by using the network, or bigger media, > such as DVDs. While I think blacklisting the package for CDs is a > pragmatical decision, making the package smaller should be just > desirable, not a (specially RC!) bug. Ack. People which use computers which did not came with a DVD reader built in are probably not able to play nexuiz anyway as it needs a pretty fastCPU and graphics card to be fun :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#557515: ITP: rail -- Replace Agent-string Internal Library
Youhei SASAKI wrote: > Package: wnpp > Owner: Youhei SASAKI > Severity: wishlist > > * Package name: rail > Version : 1.2.6 > Upstream Author : Mitsunobu Shimada > * URL or Web page : http://ring.riken.jp/archives/elisp/rail/ > * License : GPL > Description : Replace Agent-string Internal Library > > 1. compatibility for tm's enjis.el (japanize 'mule-version) > 2. Japanize ( FLIM / SEMI / XEmacs / UTF-2000 Mule / Meadow )'s code name. > And apply it for User-Agent: field. > 3. On irchat-pj, Japanize ( Mule / XEmacs / Meadow )'s code name > for "CTCP VERSION" return string. I think you should really use a proper and better description here. The lines above don't tell what the package is for, at least not for the common user. Maybe if you know what the package is for you will understand the description - so there is no chance that a normal user is able to figure it out. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the NM people
Ralf Treinen wrote: > GPG keysigning coordination is since a long time done by a small > group of people independendent from FrontDesk. Currently this is > basically me, with an offer from Patrick Schoenfeld to help. In > the past tbm and Luk have been part of that team. > > I agree that the infrastructure could (and should) be independent > of the rest of nm. Which doesn't mean that I volunteer to implement > it ... In my opinion the easiest way would be to use a page in the Debian wiki, probably with some links to biglumber and/or other useful resources. And it would be really easy to maintain it - in the best case it maintains itself. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the NM people
Ralf Treinen wrote: > the main resource is a psql database with offers and requests, and the > gpg coordination web pages are mainly interfacing to these web pages. > > Did you actually look at how gpg coordination works? I know the code *puke* and the database very well, thanks. And I still can't see a problem to migrate it to a wiki page or two. At least thats what I'll do as soon as the NM page is rewritten and nobody took care of the gpg stuff - drop the data nicely formatted into the wiki and link to that. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Lucas Nussbaum wrote: > It's a bit too easy to behave like an ass and insult him, and then > complain that he is not talking to you or willing to work with you. There were several nice and friendly attempts to get this problem fixed behind the scenes - but Matthias didn't even bother to reply to a single mail. I'm done with him and Python definitely needs a new maintainer team, without him. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Josselin Mouette wrote: > Le jeudi 03 décembre 2009 à 22:46 +0100, Luk Claes a écrit : >>> Many still seem to think that Ubuntu is sufficiently close to Debian >>> that work done in it should be easily transferrable. If this is not the >>> case, maybe we need to start treating Ubuntu more like we do Fedora. >> Because it is sufficiently close, mistakes learnt in one should probably >> not be repeated in the other... > > Yeah, sure. I guess this is why the dist-packages changes, which were so > painful for Ubuntu, were applied to Debian as well without any kind of > discussion. Also the Python2.6 transition was an utter mess as it was started WAY too late. We're going to face that mess in Debian again. Some people learn nothing by their own mistakes just because they think they're better then all the others. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Michael Banck wrote: > When it came to evaluating the same for Debian, his technical opinion > won (e.g. the problem with setup.py changes mentioned some time ago) for > the time being, and now that python2.6 would be ready to upload, > Matthias turned ill (or was distracted by other real life stuff for a > while before). he should either learn to work in teams or to communicate. Even better - learn both. There is absolutely no excuse for the current situation. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Josselin Mouette wrote: > Le jeudi 03 décembre 2009 à 19:28 +0100, Luk Claes a écrit : >> There is currently discussion ongoing about how to move forward, though >> due to the complex nature of the current situation (where also lots of >> FUD etc is on the lists), it is being dealt in private. > > This is absolute bullshit. The situation is not complex. > >> Before there is a real break through where everyone involved has got the >> chance to react on proposals and hopefully agree on a way forward, there >> won't be much disclosed. > > Everyone already agreed on the way forward, including representatives of > the release team. Everyone started to work on this months ago. Everyone, > except the Python maintainer himself, of course. Ack. He didn't even bother to write a single mail. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem
Robert Millan wrote: > On Mon, Dec 07, 2009 at 02:14:52AM +, Ben Hutchings wrote: >> On Mon, 2009-12-07 at 01:43 +0100, Robert Millan wrote: >>> Package: wnpp >>> Severity: wishlist >>> Owner: Robert Millan >>> >>> * Package name: modem-cmd >>> Version : 0.0.1 >>> Upstream Author : me >>> * URL : none yet, debian-native >> Why should this be Debian-specific? > > I don't know. Should it? No, it should not. I assume other distributions support modems, too - so its clearly not Debian specific. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560863: ITP: lamson -- The Python SMTP Server
Heiko Schlittermann wrote: > FYI, from the FAQ of lamson: > http://lamsonproject.org/docs/faq.html > --- > Debian and CentOS are notorious for being dinosaurs. Both distributions of > Linux suffer from the false rationale that older software is more stable > and > secure. The reality is that the stability or security of a piece of > software is > not a function of its age, and in many cases the newer versions of > software > will typically fix many stability and performance problems. Despite this > fact, > these two variants of Linux are notorious for back-porting patches from > later > versions to older versions rather than just using the newer version. Sounds like one wants to check with the upstream what their plan to handle security issues is. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The GIMP plugins for refocussing blurred images
Hello, since I'm not only a geek but also a photographer and GIMP user I've decided to have a look at wnpp bug #398765 [1] and package the plugin [2]. While packaging gimp-refocus I came across the refocus-it plugin, which uses a different algorithm and also supports to refocus motion blur, so I've decided to package it, too [3]. It seems to be much slower, though - but it provides a command-line version which works totally independent of The GIMP, it only depends on libc6. I've commented and described the issues of both plugins at the given urls, testing and comments would be very appreciated. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398765 [2] http://bzed.de/debian/packages/gimp-refocus [3] http://bzed.de/debian/packages/gimp-refocus-it Thanks a lot, Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The GIMP plugins for refocussing blurred images
Heya, actually I'm looking more for somebody who has an actual use-case for those plugins and is willing to test them with a recent version of gimp, I didn't even think about finishing the packages yet. The code is unmaintained for years, and the refocus under gimp 2 is more or less a hack... I don't want to spend time on finishing the package if it doesn't make a sense, especially since upstream seems to be dead. The math used in the plugins is nothing I could fix, otherwise I would just finish the packages, find a sponsor and just wait for bug-reports. Cheers, Bernd Matthias Julius wrote: > This question is better placed on [EMAIL PROTECTED] > > So, I am crossposting it there > > Bernd Zeimetz <[EMAIL PROTECTED]> writes: > > >> Hello, >> >> since I'm not only a geek but also a photographer and GIMP user I've >> decided to have a look at wnpp bug #398765 [1] and package the plugin >> [2]. While packaging gimp-refocus I came across the refocus-it plugin, >> which uses a different algorithm and also supports to refocus motion >> blur, so I've decided to package it, too [3]. It seems to be much >> slower, though - but it provides a command-line version which works >> totally independent of The GIMP, it only depends on libc6. >> I've commented and described the issues of both plugins at the given >> urls, testing and comments would be very appreciated. >> >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398765 >> [2] http://bzed.de/debian/packages/gimp-refocus >> [3] http://bzed.de/debian/packages/gimp-refocus-it >> >> Thanks a lot, >> >> Bernd Zeimetz >> > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414028: ITP: python-html5lib -- Library for working with HTML5 documents
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: python-html5lib Version : 0.2 * URL : http://code.google.com/p/html5lib/ * License : MIT Programming Lang: Python Description : Library for working with HTML5 documents html5lib is a pure-python library for parsing HTML. It is designed to conform to the Web Applications 1.0 specification, which has formalized the error handling algorithms of popular web browsers. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The GIMP plugins for refocussing blurred images
Hi, > times, with a home-compiled version. BTW, I have a patch to make it compile > cleanly with gimp 2.2 (last time I tested was 6 months ago, but it should work > also with newer versions). I'll take a look at your packages when I have some > time. > thank you very much! Could you please mail me your patch so I can compare it with the one I found? As you know the plugin - do you have any other suggestions, or do you probably have any documentation of the refocus-it plugin? Luckily refocus brings at least a little bit of documentation. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414420: ITP: refocus-it -- refocus images using Hopfield neural networks
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: refocus-it Version : 2.0.0 Upstream Author : Lukas Kunc <[EMAIL PROTECTED]> * URL : http://refocus-it.sourceforge.net/ * License : GPL2 Programming Lang: C Description : refocus images using Hopfield neural networks Package: gimp-refocus-it Description: Plugin for The GIMP to refocus images using Hopfield neural networks The Refocus-it plugin for The GIMP can be used to refocus images acquired by a defocused camera, blurred by gaussian or motion blur or any combination of these. There are a few nice features of this plug-in, especially adaptive / static area smoothing used to remove the so called "ringing" effect, introduced by edges in the image, and effects introduced by noise. Mirror and periodical boundary conditions are available. Preview helps you select the best parameters. . There are a few NOT nice features of this plug-in as well, namely its memory and CPU requirements. . The algorithm is based on finding the minimum of the error function using Hopfield neural network. Package: refocus-it-bin Description: Command line version of The GIMP's refocus-it plugin This is the command line version of the refocus-it plugin for The GIMP. It can be used to refocus images acquired by a defocused camera, blurred by gaussian or motion blur or any combination of these. There are a few nice features, especially adaptive/static area smoothing used to remove the so called "ringing" effect, introduced by edges in the image, and effects introduced by noise. Mirror and periodical boundary conditions are available. . There are a few NOT nice features as well, namely memory and CPU requirements. . The algorithm is based on finding the minimum of the error function using Hopfield neural network -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#414966: ITP: svnmerge -- A merge helper tool for Subversion
Heya, > Seconded, and even more: the "subversion-tools" package is a binary > package from the "subversion" source package. At first glance, stuff in > subversion-tools is contributed stuff to the subversion upstream. Can't > these 3 scripts be contributed upstream as well and hence distributed > directly in subversion-tools? > and even more: where's the difference between svnmerge from this package, and svnmerge from "subversion-tools" ? Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling Debs on AMD vs. Intel and 32bit vs. 64bit
Heya, > And for clarity, IA32 cover 32-bit Intel and works for AMD 32-bit > processors. > but ia32 will just work fine on amd64 architectures. You can decide if you want to run a 32 or 64bit Linux on amd64/emt64. Both ways have their advantages and drawbacks. Choose whatever you need. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compiling Debs on AMD vs. Intel and 32bit vs. 64bit
Hi, > A machine that generates *.deb files that are only good on *that* one > machine is useless to me. as I said before, you can run 32bit and 64bit OSs on amd64 machines, so you could just stay with ia32 on all machines and not worry about 64bit. But neither that nor trying to cross-compile from 32bit to 64bit is the way to go in my eyes. I'd just install a 32bit debian and a 64bit debian within a kvm and use them to build the packages. I'll setup such a build environment in April, which will work like pbuilder, but it'll be based on kvm and build packages for ia32 and amd64, as we're starting to use amd64 at work these days. If there're better ideas how to solve this problem, please let me know. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415844: ITP: python-fpconst -- Utilities for handling IEEE 754 floating point special values
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: python-fpconst Version : 0.7.2 Upstream Author : Gregory R. Warnes <[EMAIL PROTECTED]> * URL : http://research.warnes.net/projects/rzope/fpconst/ http://www.python.org/dev/peps/pep-0754/ * License : Apache License, Version 2.0 Programming Lang: Python Description : Utilities for handling IEEE 754 floating point special values This python module implements constants and functions for working with IEEE754 double-precision special values. It provides constants for Not-a-Number (NaN), Positive Infinity (PosInf), and Negative Infinity (NegInf), as well as functions to test for these values. -- The fpconst module is packaged within the python-soappy package at the moment, which I have adopted with Ed Boraas' agreement. There're a few reasons to package the small module as an extra package: * It is useful on it's own * there's no upstream development on python-soappy anymore, you're supposed to use python-zsi instead - one less reason to install SOAPpy to have fpconst * fpconst is PEP 754 and will be included in a coming python release, hopefully. It wouldn't make sense to ship python-soappy with a module which is included in the standard modules * I think Debian is the only distrib which does not ship a python-fpconst package yet. -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ethernet interface numbering in etch
Heya, > As a corollary to this, I have machines where the disks swap device files on > each boot. It's pretty annoying when my nfs volumes switch which device name > is used to mount them. > you could mount them by UUID instead of the device name. Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ethernet interface numbering in etch
> Btw. do Debian initrds already support specifying the root fs with > LABEL= like Fedora/RedHat? > Didn't try it, but according to [1] they do. Cheers, Bernd [1] http://wiki.debian.org/InitrdReplacementOptions -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
was (long time ago) ITP: zenoss
Heya, yesterday I've contacted the original bug submitter of #361253 via personal mail and he told me that he doesn't have the time to take care of packaging zenoss at all and that I should just do it, so I'll hijack this wnpp bug and package zenoss within the next days. If anybody else is working on this, or if there are any wishes or additional plugins to package, please let me know. I don't want to waste any efforts. Cheers, Bernd Zeimetz -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anyone
Heya, > > Which library? > According to the mail headers this mail was a reply to <[EMAIL PROTECTED]> google found it in the archive: http://lists.debian.org/debian-devel/1999/02/msg00565.html So we're talking about pdflib. And I think the package php-fpdf should be a way to create pdf files from php without the need for pdflib. As far as I know does http://www.debian-unofficial.org/ ship pdflib packages, but I think they're not necessary here. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417365: ITP: zope-advancedquery -- Zope product providing enhanced search functions
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: zope-advancedquery Version : 2.2 Upstream Author : Dr. Dieter Maurer <[EMAIL PROTECTED]> * URL : http://www.dieter.handshake.de/pyprojects/zope/#AdvancedQuery * License : BSD-style Programming Lang: Python Description : Zope product providing enhanced search functions AdvancedQuery is a Zope product aimed to overcome several limitations of ZCatalog's native search function. .. Like ZCatalog's search, it supports elementary index searches. While ZCatalog can combine such elementary searches only by "and", AdvancedQuery allows them to be combined arbitrary with & (and), | (or) and ~ (not). .. While ZCatalog supports an efficient sorting via an index on one level, AdvancedQuery supports sorting via any level of (field) indexes. Moreover, it sorts the result incrementally -- only as far as you access your result. This can drastically speed up the time required for sorting. It uses Python's generators for this (and thus requires Python 2.2 or better). * I'm packaging this product as dependency of Zenoss (#361253). Cheers, Bernd Zeimetz -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417500: ITP: zope-managableindex -- Zope product providing indexes managable via the ZMI
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: zope-managableindex Version : 1.6.1 Upstream Author : Dr. Dieter Maurer <[EMAIL PROTECTED]> * URL : http://www.dieter.handshake.de/pyprojects/zope/#ManagableIndex * License : BSD-style Programming Lang: Python Description : Zope product providing indexes managable via the ZMI ManagableIndex can mean different things for different people. For a content manager, it brings flexible field, keyword and efficient range indexes managable via the ZMI to * combine values from different sources, ignoring irrelevant value and transforming values in an inadequate form, * control acquisition and prevent acquired values to be indexed * ignore stop-terms, normalize terms and check types .. For a developer, ManagableIndex provides a framework for index definition, improving on PluginIndexes. It provides for managability, automatically and intelligently handles unindexing when an object is reindexed and implements and, or and range queries (for not too complex indexes). * I'm packaging this product as dependency of Zenoss (#361253). Cheers, Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417514: ITP: zope-ofolder -- A tiny layer above Folder providing ordering control
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: zope-ofolder Version : 1.0 Upstream Author : Dr. Dieter Maurer <[EMAIL PROTECTED]> * URL : http://www.dieter.handshake.de/pyprojects/zope/#bct_sec_3.6 * License : completely free Programming Lang: Python Description : A tiny layer above Folder providing ordering control An OFolder contains an ordered sequence of objects. Besides the ordering, it behaves identical to a Folder. You can reorder the objects by assigning new order numbers (these are float values) and then press 'reorder'. * I'm packaging this product as dependency of Zenoss (#361253), and zope-managableindex (#417500) * Although it's a very small product it is useful on it's own imho, so I think it should not be packaged with zope-managableindex into one package. Cheers Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#416490: acpi-support: IBM Ultrabase X4 DVD/CDOM Undetected On Dock
Heya, >> I fear that the IDE bus is not really hotplug friendly and that we >> simply have no way to discover this automatically (hence the need of >> a tool to ask for a rescan of the IDE bus by the kernel). But I'm >> neither an hardware expert nor a kernel specialist, so I may be wrong. >> > > I think hdparm has some flags to do this. > > The hdparm way resulted in some bad bad bugs some time ago due to the more or less broken ide stack. This is supposed to be fixed, though. I think hdparm -R is the option, which is still marked as dangerous in the readme. In the hdparm package you'll find /usr/share/doc/hdparm/contrib/, which contains a README and two scriptst ultrabayd and idectl. They were supposed to do those things before the ibm_acpi module was created. Not sure how far the ibm_acpi module takes care of those things - at least it works well for the integrated ultrabay, you want to make sure that it is loaded. Have a look into /proc/acpi/ibm then. IBM-Acpi's homepage is here: http://ibm-acpi.sourceforge.net/ Hope that helps, cheers Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Alpha for developers?
Heya, Sam Hocevar mentioned on his platform that there is no Alpha machine available for developers. As we have a few standing around in a cellar at work I'd be willing to setup one or two of them to be used as machines for developers, if there's anybody interested in that (and the machines still work). Cheers Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418552: ITP: umit -- nmap frontend, developed in Python and GTK
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: umit Version : 0.9.3-rc2 Upstream Author : Adriano Monteiro <[EMAIL PROTECTED]> * URL : http://umit.sourceforge.net/ * License : GPL2, and LGPL for the higwidgets library Programming Lang: Python Description : nmap frontend, developed in Python and GTK UMIT's goal is to provide a nmap frontend that is really useful for advanced users and easy to be used by newbies. With UMIT, a network admin could create scan profiles for faster and easier network scanning or even compare scan results to easily see any changes. A regular user will also be able to construct powerful scans with UMIT command creator wizards. * The python-higwidgets package will be created from the umit source, too -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#418552: ITP: umit -- nmap frontend, developed in Python and GTK
Stefano Zacchiroli wrote: > On Tue, Apr 10, 2007 at 03:31:02PM +0200, Bernd Zeimetz wrote: > >> Description : nmap frontend, developed in Python and GTK >> > > Is it interesting for the user/sysadm that the frontend is developed in > Python? I would remote that (while I will keep the reference to GTK) and > perhaps adding something about the intended targets: both advanced users > and newbies. > Good idea, how does Description: nmap frontend for advanced users and newbies sound? cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error with fakeroot
Heya, > > Maybe the original poster may have typed in "fakeroot" by itself > without realizing it changed the environment. I doubt that. You can easily run into this problem by using make-kpkg --rootcmd fakeroot modules-image and the nvidia module will fail with fakeroot: FAKEROOTKEY set to 1625239046 fakeroot: nested operation not yet supported make[2]: *** [build-stamp] Error 1 make[2]: Leaving directory `/usr/src/modules/nvidia-kernel' make[1]: *** [kdist_image] Error 2 make[1]: Leaving directory `/usr/src/modules/nvidia-kernel' Module /usr/src/modules/nvidia-kernel failed. Perhaps /usr/src/modules/nvidia-kernel does not understand --rootcmd? If you see messages that indicate that it is not in fact being built as root, please file a bug against /usr/src/modules/nvidia-kernel. This behavior changed within the last weeks, not sure when exactly. I'm sure it worked well when I built the first kernel on my new desktop, which was in October. I think I ran into the same problem while using dpkg-buildpackage, but I'm not sure. running fakeroot make-kpkg instead of using --rootcmd works. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error with fakeroot
Heya,
>> You can easily run into this problem by using
>> make-kpkg --rootcmd fakeroot modules-image
>> and the nvidia module will fail with
>
> Does this happen every time?
with the nvidia module - yes [1].
I'm pretty sure I've seen this happen with {svn,dpkg}-buildpackage
before, too - but I just don't know where. As soon as I see it again
I'll make sure to look into the problem.
Cheers,
Bernd
[1]: http://bzed.de/debian/bugs/fakeroot
--
Bernd Zeimetz
<[EMAIL PROTECTED]> <http://bzed.de/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LDAP breaks kcheckpass when not setuid root (#298148)
Christoph, > Thanks in advance for the hints. I'm taking notes already to document > this better. please post a link as soon as you have some documentation online. I'd think that a wiki would be a good place for it. pam-ldap/libnss-ldap is missing a good documentation definitely. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422392: ITP: gimp-plugin-registry -- A repository of optional extensions for The GIMP
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: gimp-plugin-registry Version : 0.0 * URL : http://registry.gimp.org/ * License : several, mainly GPL Programming Lang: c, c++, python, perl, Description : A repository of optional extensions for The GIMP This package will contain several plugins/extensions to GIMP, which are imho useful for many people. The description will contain a list of all contained plugins (and is far from beeing complete yet). Most extensions are too small to be packaged into a package on their own, that's why I want to package several of them into one package. If you know an extension you'd like to see in this package, please let me know by replying to this bug report. See http://registry.gimp.org/ for a list of existing extensions. All extensions should fulfil the following requirements: * no special dependencies to libraries (except libgimp & co). I will not include any extensions which need 30M of libraries as dependencies. * must work with Gimp 2.3 from experimental * must be under a DFSG and GPL compatible licence, of course. Several plugins either don't have a licence at all or a not compatible one, unfortunately. * must be useful and create something that is not easily reproducible with 2 mouse clicks. * should be capable of handling images of at least 5000x5000 pixel without running into memory issues or taking the whole night to finish. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wordpress packages
Russell Coker wrote: > I am currently running Wordpress on Debian/etch. I would like to run only > Debian packages but it seems that themes and plugins are not packaged and > Wordpress is not fully functional without them. imho the wordpress packaging should be changed in a way to allow the user to drop their plugins/themes into /var/lib/wordpress/../ instead of trying to package plugins and themes. Due to the nature of php and wordpress, the code is hard to maintain in general, and many plugins are a mess of code and often they open security related holes in your WP installation. Maintaining a collection of plugins for WP sounds like a nightmare for me. only my 2c. Cheers, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422137: ITP: 09F911029D74E35BD84156C5635688C0 -- l33t h4x0r numb3r
> Humh... No, I don't have, have had, own, have owned, claim to own, > claim to have owned, claim to have nor claim to have ever had the > needed private key that corresponds 09F911029D74E35BD84156C5635688C0.. I hope so - or somebody could think you had chosen your GPG fingerprint as master key while writing the "encryption" stuff for that company :P -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wordpress packages
Bernd Zeimetz wrote: > Maintaining a collection of plugins for WP sounds like a > nightmare for me. http://seclists.org/bugtraq/2007/May/0011.html while we're speaking from the devil -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424406: ITP: python-snpp -- SNPP library for Python
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: python-snpp Version : 1.1.1 Upstream Author : Monty Taylor <[EMAIL PROTECTED]> * URL : http://www.sf.net/projects/pysnpp * License : GPL2 Programming Lang: Python Description : SNPP library for Python Pure Python library implementing RFC 1861, the Simple Network Paging Protocol -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424727: ITP: wmi -- DCOM/WMI client implementation for Linux
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz <[EMAIL PROTECTED]> * Package name: wmi Version : 20070516 Upstream Author : Zenoss / Andrzej Hajda / The Samba Team * URL : http://dev.zenoss.org/svn/trunk/wmi/ * License : GPL/LGPL and others Programming Lang: C, Python Description : DCOM/WMI client implementation for Linux This DCOM/WMI client implementation is based on Samba4 sources. It uses RPC/DCOM mechanism to interact with WMI services on Windows 2000/XP/2003 machines. . This package is a Zenoss dependency mainly, but it can be used on its own. It also includes a Python module providing access to the DCOM/WMI functions. The implementation uses a small, patched part of the samba sources. It does not really make sense to integrate it into a Samba4 package yet, probably this will change in the future, when there's a stable samba4 version. Then this source should provide the python bindings only, or build the whole wmi client using the Samba libraries. Of course, this is only possible if the patches would be integrated into Samba4. In the meantime we jsut ship a patched Samba source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Frank Küster wrote: > Personally, I don't like branches very much. Nobody ever explained to > me a good receipe to handle them in the case where development proceeds > in both, and important fixes are copied from one to the other. http://youtube.com/watch?v=4XpnKHJAok8 is good to view if you're interested in how the branching can work, using git. Best regards, Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#424875: ITP: libical0 -- libical offers parsing of ical text data.
>> * URL : http://freeasociation.sf.net just a typo, there's a s missing: http://freeassociation.sf.net -- Bernd Zeimetz <[EMAIL PROTECTED]> <http://bzed.de/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
