Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 05:28:29PM -0400, Patrick Ouellette wrote: > On Thu, May 03, 2012 at 05:13:09PM -0400, Chris Knadle wrote: > > > > Drat. I forgot about APRS. APRS has become fairly popular among hams, so > > much > > so that it now comes built-in to several radios, and even HTs > > (Handy-Talkies). > > > > APRS is a system for location reporting. It's also very commonly used to > > track experimental weather balloons at high altitudes, because apparently > > GPS > > stops working at around 30,000 feet. [The original high-altitude MIT > > balloon > > launch that many others have duplicated uses APRS, and I know of other > > groups > > using it for this purpose also.] APRS is also commonly used by hams to > > track > > themselves and/or their cars and loved ones as they drive around. > > > > The rigs used in cars likely aren't running a Linux OS, but the base > > station > > nodes that receive and report the APRS traffic probably are, and as Debian > > has > > been friendly to hams it's one of the more likely to be used there. > > Continue to say DRAT! The handwriting is on the wall. Very few have come > out even marginally supporting the ham radio claim other than myself. > > Frankly, given the lack of response from the Debian ham community I'm > inclined > to no longer maintain the ax25 packages and let them drop from Debian. > > Three other people are listed as uploaders on ax25-apps: Jaime Robles, > Hamish Moffatt, and Ramakrishnan Muthukrishnan. I haven't heard from > any of them. Haven't heard from our QSSTV supporter either (Steve Kostecke). Sorry Pat, I'm pretty much MIA and wasn't aware of this renewed discussion until you Cced me. I think it's pretty poor of the node.js developers to trample on an established name, especially when "node" doesn't even seem to be particularly descriptive of their application. Secondly if node.js is usually just used via #!, I'm not sure why it's in $PATH at all - why not in /usr/lib? Nonetheless the numbers are against the ham radio case. I personally haven't used (ax)node and I'm not able to confirm that these complicated scenarios you mention exist. If we added a big preinst warning to (ax)node with a chance to abort installation, would that be sufficient warning? Ubuntu hasn't resolved this either FWIW. They probably have fewer hamradio users than we do. Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120504041105.ga19...@risingsoftware.com
Re: build self-contained repository for offline use
On Tue, Jul 05, 2011 at 10:52:02PM +0200, Paul Wise wrote: > One of apt-zip/aptoncd/apt-offline might meet your needs. Thanks all for the replies. I checked out apt-zip, apt-offline, aptoncd, CDD and apt-clone. None of them really suited my needs, as I want to generate this repository automatically, and want to do a whole class of target systems which will have a baseline set of packages installed. Anyway I've found it's pretty easy to roll my own using python-apt and configuring apt to use alternate locations for the cache, dpkg status file etc. I feed in the dpkg status file from my baseline install, a sources.list and a list of packages I want to be installable, and I can easily download the files. Then use apt-ftparchive to generate the metadata and I'm done. thanks, Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110706081123.ga19...@risingsoftware.com
build self-contained repository for offline use
I need to build a repository to allow some specified packages to be installed on computers without internet access. It needs to contain the specified packages plus any dependencies (new packages and new versions) from squeeze plus other repositories such as squeeze backports and some local ones. I want to include everything beyond a basic squeeze install. (Ideally I can feed in a list of stuff to be excluded.) Does anyone know a tool/process for doing this? thanks, Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110705075959.ga26...@risingsoftware.com
Re: Bug #302907 - maintainer doesn't reply
On Mon, May 16, 2011 at 10:25:17AM +0200, Stefano Zacchiroli wrote: > Hi Vincent, > > On Wed, May 11, 2011 at 02:17:30PM +0200, Vincent Lefevre wrote: > > Bug #302907 in libstroke0-dev has been open and had a (working) patch > > for 6 years. The maintainer has never replied or done anything else > > concerning this bug. > > > > Could this bug be eventually fixed? > > Sure it can, and it *will* be fixed as soon as someone does that :) > > The bug is 6 years old but, at the same time, the package hasn't been > uploaded to the Debian archive for the past 4 years. Chances are that > the maintainer, Cc:-ed, has lost interest in maintaining the package or > is simply in need of help. > > How about you prepare an nmudiff and post it to the bug log for review > as a concrete step forward to fix the issue? If the maintainer does not > reply, you can then ask for sponsoring (to the maintainer, to -mentors, > or the like) and eventually even step in as the maintainer of a package > you seem to care about. Hi, Indeed an NMU or a new maintainer for the libstroke package would be most welcome. Please go ahead and upload if you wish; no need to ask my permission. Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110516084801.ga15...@risingsoftware.com
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Wed, Mar 23, 2011 at 12:28:18PM +1100, Ben Finney wrote: > Christian PERRIER writes: > > That's indeed insane..:-). Hobart (Tasmania), Melbourne (Victoria), > > Sydney (NSW) and Canberra (ACT) have the *exact* same time rules > > (including DST). > > But they didn't always; and with the tendency of governments to flex > their arbitrary timezone powers, they may be different again in future. Indeed, Vic and NSW only aligned themselves with Tasmania a few years back. Tasmania had longer daylight savings periods for years before. It's feasible that it will differ again in the future. I think Vic/ACT/NSW discrepancies are unlikely but it doesn't seem worth removing them to me. Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324234114.ga32...@risingsoftware.com
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Wed, Mar 23, 2011 at 12:59:19PM +1100, Aníbal Monsalve Salazar wrote: > Commonwealth Games. In Victoria we were on a different timezone to that > of the folks in New South Wales. Not really relevant, but no we weren't. NSW changed too. Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324234259.gb32...@risingsoftware.com
Re: The "node" command in Debian
On Mon, Feb 07, 2011 at 10:54:24AM -0200, Henrique de Moraes Holschuh wrote: > On Mon, 07 Feb 2011, Jonathan Nieder wrote: > > The LinuxNode project > > - > > The other is a frontend to libax25, an AX.25 implementation for Linux. > > Hardware implementations of AX.25 are apparently called "terminal node > > controllers" or "nodes" for short; hence this Linux-based > > implementation was called LinuxNode and its binary called "node". It > > was introduced in January, 1996. It seems that its family tree also > > includes (unpackaged) implementations named AWZNode and FlexNode. > > 1996 was a long time ago, the world was much smaller back then. It was > still a very very poor choice of naming, and it should have been named > ax25node from day one. Similar AX.25 tools "call" and "listen" were renamed in 2007 to ax* (package ax25-apps), because those names were too generic (according to the changelog). I think renaming the node binary to axnode is reasonable and consistent with this, but I don't think the nodejs program should be using that name either. > If push comes to shove, nobody is going to try to force _them_ to give > up that name. You can get the package itself renamed to ax25node, and > have the required "node" transitional package in squeeze+1, so as to > have no "node" package in squeeze+2, but rename the executable itself? > not likely. We did it with call and listen, both used from the command line more frequently, so it's not out of the question. > 4. as the one with the weaker claim, node.js can move its executable out >of the generic namespace or rename its executable to something else. I think it should do that anyway. Hamish -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110208230458.ga23...@risingsoftware.com
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
On Fri, Apr 03, 2009 at 11:50:45PM +0200, Goswin von Brederlow wrote: > Cyril Brulebois writes: > > > Vincent Fourmond (01/04/2009): > >> Although I admit that schroot is a neat tool to deal with that, it is > >> overkill in the case of wine, and much too complex for users that would > >> be interested to use wine: one of the public that can be attracted to > >> the GNU/Linux side of the game is gamers - especially now that there are > >> so many *recent* games that work with it. Telling them: «well, you'll > >> have to build a ia32 chroot to play...» is likely to drive them off for > >> good. > > > > I can't really see why wine couldn't embed a script to do the needed > > work. Users would need to call a single command to prepare the > > environment. It could, I guess, even be done in the postinst. > > So wine on amd64 should be a dummy package that then creates a 32bit > chroot all on its own? > > Now what about rar? Another chroot? And the 32-bit application can't launch 64-bit applications as it could if it were just running with 32-bit libraries outside of a chroot. The chroot is too isolating. I used to run 32-bit Firefox in a chroot before 64-bit flash and nspluginwrapper etc and of course it couldn't launch external applications associated with various file types etc. PITA. Hamish -- Hamish Moffatt VK3SB -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#507451: ITP: iptux -- IP Messenger client for Linux
On Tue, Dec 02, 2008 at 08:28:22AM +0800, LI Daobing (李道兵) wrote: > On Tue, Dec 2, 2008 at 2:50 AM, Ron Johnson <[EMAIL PROTECTED]> wrote: > > But still: How does this relate to IM, or to older protocols like "talk"? > > (The Google Translation of the URL doesn't make much sense.) > > > 1. it has a friendly interface > 2. it can auto detect all clients in the intranet > 3. it does not need a center server. > 4. it can add internet client by IP > 5. the file transfer speed is very fast (MSN, gtalk only has several KB/s > here) Like Bonjour, then? (Implemented in pidgin and finch.) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#481134: libpoppler does not use cmap files from xpdf-{japanese,...}, and fails to parse Japanese PDF files.
On Sat, Aug 23, 2008 at 03:10:22PM +0800, Deng Xiyue wrote: > Ftp-masters, sorry to break the protocol, but due to the current > situation, it'll be very helpful if the poppler-data package sitting in > NEW will be reviewed soonish so that it can be decided whether the NMU > of xpdf-CJK packages should be done. Obviously poppler-data is the best > way to solve the issue. Thanks very much. You also need the release managers ([EMAIL PROTECTED]) to accept the new package into lenny, and they appear reluctant to allow new packages in general. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#481134: libpoppler does not use cmap files from xpdf-{japanese,...}, and fails to parse Japanese PDF files.
Hi, On Fri, Aug 22, 2008 at 07:51:36AM -0700, Junichi Uekawa wrote: > > > I'm a bit worried that this needs to be fixed for > > > xpdf-chinese-simplified > > > xpdf-chinese-traditional > > > xpdf-korean > > > xpdf-japanese > > > > > > packages. The fix would probably be simple. It should probably be > > > hardlinks rather than symlinks considering dpkg behavior wrt symlinked > > > dirs. > > > > You can't hardlink directories though, so we might as well symlink the > > individual files. > > > > > I'd like this fix included in lenny so that we don't see a regression > > > in Debian for Japanese users. > > > > > > > > > There was a package in the NEW queue 'poppler-data' which should > > > really have fixed this bug. > > > http://ftp-master.debian.org/new/poppler-data_0.2.0-1.html > > > > > > That going into Debian sid would fix this bug also, but not quite sure > > > if it's reasonable to expect a new package to enter Debian lenny. > > > > I kinda think it's in poppler's domain to fix this; logically > > xpdf-japanese (etc) exists only to enhance xpdf. poppler-data appears to > > be a good solution. > > 1. poppler was theoretically self-contained, poppler-data was REJECTed > once and not yet part of non-free as of today. > > 2. Japanese users upgrading from etch would have xpdf-japanese > installed because evince (poppler) needed and used xpdf-japanese, and > natural upgrade path would be xpdf-japanese supporting poppler. > > These factors make adding support in poppler somewhat reasonable. If the release managers would approve an update to xpdf-japanese I am happy to upload a new version including your patch, or for you to NMU the package. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#481134: libpoppler does not use cmap files from xpdf-{japanese,...}, and fails to parse Japanese PDF files.
On Wed, Aug 20, 2008 at 09:42:21PM -0700, Junichi Uekawa wrote: > I'm a bit worried that this needs to be fixed for > xpdf-chinese-simplified > xpdf-chinese-traditional > xpdf-korean > xpdf-japanese > > packages. The fix would probably be simple. It should probably be > hardlinks rather than symlinks considering dpkg behavior wrt symlinked > dirs. You can't hardlink directories though, so we might as well symlink the individual files. > I'd like this fix included in lenny so that we don't see a regression > in Debian for Japanese users. > > > There was a package in the NEW queue 'poppler-data' which should > really have fixed this bug. > http://ftp-master.debian.org/new/poppler-data_0.2.0-1.html > > That going into Debian sid would fix this bug also, but not quite sure > if it's reasonable to expect a new package to enter Debian lenny. I kinda think it's in poppler's domain to fix this; logically xpdf-japanese (etc) exists only to enhance xpdf. poppler-data appears to be a good solution. thanks, Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#481134: libpoppler does not use cmap files from xpdf-{japanese,...}, and fails to parse Japanese PDF files.
On Wed, Aug 20, 2008 at 04:06:40PM +0200, Loïc Minier wrote: > For the long term, I'd recommend either b), or c) if b) isn't possible; > for lenny, either the long term approach or the d) approach would work, > but d) would only solve the problem for this particular package. > > Because b, c), and d) will almost certainly require changes to > xpdf-japanese, I'm reassigning the RC counterpart of this bug to this > package. I'm keeping an important bug open against poppler because it > can be considered a regression of poppler, but I don't think it should > be considered RC for poppler because: > * xpdf-japanese is non-free while poppler is free; perhaps this is a > fallacy, but I don't think support for a non-free package should > affect the Debian release; if this is considered >= serious > severity, it shouldn't be release-blocking > * it's an upstream design decision that poppler doesn't support xpdf > config/data and poppler doesn't aim to be compatible with xpdf's > config/data: xpdf-japanese needs to grow compatibility with poppler > instead Patches for xpdf-japanese would be most welcome. I'm not familiar with the details of fontconfig, defoma etc. Maybe the relevant data in xpdf-japanese should be moved into cmap-adobe-japan1 instead. Probably xpdf-japanese's additional CMaps should move too; I thought I submitted a bug about this years ago but I don't see it now. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface
On Wed, Aug 06, 2008 at 02:38:36PM +0200, Guus Sliepen wrote: > On Wed, Aug 06, 2008 at 02:10:46PM +0200, Yves-Alexis Perez wrote: > > > > What is the added value of etherpuppet over existing tools, such as > > > openvpn, tinc, gvpe, vde2? If there is none, or if the functionality > > > that is missing from etherpuppet can be easily integrated with one of > > > the existing tools, then you should tell upstream that it would be > > > better to invest time and energy in one of the other solutions. > > > > Well, etherpuppet is not really something to use as a simple vpn. You > > use it to really clone (including low level stuff) the interface on the > > remote side. > > Ok, I see now that only one side of the etherpuppet tunnel uses a > tun/tap device, the other side copies everything to/from a real Ethernet > interface. > > Still, the other tools I mentioned can all handle Ethernet frames. In > fact, tinc can be compiled to connect to a real Ethernet interface > instead of a tun/tap device, so it might already have the capability to > do what etherpuppet does. The advantage of these tools is that they can > provide encryption, and some of them can connect more than two endpoints > together. > > The reason I urge you to consider having upstream merge his > functionality with one of the others is that otherwise there is yet > another tunnel tool out there. etherpuppet doesn't sound like a tunnel or VPN tool at all - it seems to be a mirroring tool for diagnostic purposes. I'm confused about how TUN/TAP are involved though. If I'm routing packets between two Ethernet interfaces, can I have them copied to a third? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#492922: ITP: arpon -- arp handler inspection
On Wed, Jul 30, 2008 at 10:33:39AM +1000, Ben Finney wrote: > Giuseppe Iuculano <[EMAIL PROTECTED]> writes: > > > Guus Sliepen ha scritto: > > > On Tue, Jul 29, 2008 at 11:27:55PM +0200, Giuseppe Iuculano wrote: > > > > > >> Description : arp handler inspection > > > > > > That is not a short description, that is just the expansion of the > > > acronym. > > > > Yes, this won't to be package synopsis. > > Then you've submitted the ITP report incorrectly. That field should be > the intended 'Description' field of the package. Where's that written? I don't mean to be objectionable, but no such requirement is listed in the developer's reference: http://www.debian.org/doc/developers-reference/pkgs.html#newpackage I think it's more important to submit an ITP early to avoid duplicate work than to spend more time perfecting the package description. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#492376: ITP: libwwwbrowser-perl -- Platform independent means to start a WWW browser
On Fri, Jul 25, 2008 at 12:29:48PM -0500, Carlo Segre wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Carlo Segre <[EMAIL PROTECTED]>
>
>
> * Package name: libwwwbrowser-perl
> Version : 2.23
> Upstream Author : Slaven Rezic <[EMAIL PROTECTED]>
> * URL : http://user.cs.tu-berlin.de/~eserte/src/perl/WWWBrowser/
> * License : GPL or Artistic
> Programming Lang: Perl
> Description : Platform independent means to start a WWW browser
>
> Perl module which starts a web browser, in the background for X11, with a
> specified URL. Options exist to use a user-specified browser, including
> text browsers, which are started in a terminal window.
Is this better than fork & exec("sensible-browser ")? Does it
refer to existing methods used to select a browser on Debian eg MIME,
the GNOME preferences etc?
thanks,
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote: > I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - > emdebian-tools also depends on server resources provided only by Debian > (in this case, the package repositories containing compatible packages > which I can use to generate cross-dependencies). FWIW, couldn't emdebian-tools be used to build a Debian target on a Ubuntu host? You need Debian's packages for the target architecture, but you don't have to be running Debian on your host to access those. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to build only linux-image-2.6.18-6-686
On Sat, Jun 07, 2008 at 11:31:14AM -0400, Lennart Sorensen wrote: > You should be installing the linux-source-x.x.x package instead and > using make-kpkg to build custom kernels. The source package (rather > than the linux-source-x.x.x binary package) is not meant to make custom > kernels. Ideally the .config files used to build the standard Debian kernels would be available in a light-weight package. I think the only solution currently is to install that package and get the configuration from /boot/config-. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Sun, May 18, 2008 at 07:21:29PM +0100, Mark Brown wrote: > On Sun, May 18, 2008 at 06:08:23PM +0200, Raphael Hertzog wrote: > > > public list that end up in their main INBOX. If those can't make the > > effort to setup Mail-Followup-To, they should post less and not _more_ > > just for the sake of complaining about the copies. > > Of course, MFT brings up the whole "it's not a standard, why should I > follow it, my MUA never heard of it" thing... You can't win. Our code of conduct has the same problem - ours is different to many other communities where CCs are fine or even welcome, eg the kernel communities. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Fri, May 16, 2008 at 02:10:39AM +0200, Eugeniy Meshcheryakov wrote: > 15 травня 2008 о 16:24 -0700 Steve Langasek написав(-ла): > > > What concerns me about this approach is that it could easilly end up with > > > dist-upgrades swapping out users mail systems without warning. I would > > > consider such behaviour unacceptable as it could easilly cause mail loss > > > > Er, no, that wouldn't happen. As long as packages correctly depend on > > default-mta | mail-transport-agent, this will have no impact on upgrades. > > > This can happen if user has 'default-mta' package installed, and it > changes (if it is done like with 'gcc' package now). What if default-mta itself depend on the current default (exim4) | mail-transport-agent? Then future changes to default-mta would not affect installed users. ie: Package: something-that-needs-an-mta Depends: default-mta | mail-transport-agent Package: default-mta Depends: exim4-daemon-light | mail-transport-agent Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New README.source documentation for Debian packages
On Tue, Apr 29, 2008 at 11:15:08AM -0400, Scott Kitterman wrote: > On Tuesday 29 April 2008 10:31, martin f krafft wrote: > > Not sure about just symlinking. I'd rather say it should be: > > > > To use this package, you need to install dpatch. > > > > Once installed, please see /usr/share/doc/dpatch/... > > For common patch systems like dpatch or quilt, I guess I don't see what I > learn from this that I can't already learn from a quick glance at the > build-dep line in debian/control. Using dpatch doesn't _guarantee_ the relevant debian/rules target is "patch" though. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP-master & DAM delegations
On Thu, Apr 17, 2008 at 12:32:17AM +0200, Sam Hocevar wrote: >Dear Developers, > >Now that I have your attention, I would like to make the following > delegations: > > 1. Joerg Jaspert <[EMAIL PROTECTED]> is appointed FTP-master. > > 2. Joerg Jaspert <[EMAIL PROTECTED]> is made a full Debian Account > Manager and is therefore empowered to create and remove developer > accounts according to the New Maintainer procedure. > >These delegations are effective until revoked by the DPL or by a > resolution. Terrific! Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the armel porters
On Fri, Mar 07, 2008 at 12:15:09AM +0200, Riku Voipio wrote: > Hello dear developers, > > As you may have noticed, a new architecture, armel, has been added to > Debian. Here are some highlights and a bit of information in a nutshell. > For more details, refer to the wiki pages[0]. Can someone give us an update on armeb? www.debian.org/ports refers to debonaras.org which is currently giving a 500 result. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Wed, Feb 27, 2008 at 12:23:33AM -0600, Anibal Avelar wrote: > http://fixxxer.cc/images/mascot/Mascot_Harmony_without_Strings_by_ravenmosher.jpg That looks like some sort of big eyeball? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Tue, Feb 26, 2008 at 01:41:22PM -0600, William Pitcock wrote: > (Also, it's a bloody mascot, who cares if they don't /really/ live in > the same locations. They live in the same /climate/ and that's good > enough for most people.) How about a leopard seal? They eat penguins :-| http://www.flickr.com/photos/hnmoffatt/381679738/in/set-72157594521689295/ Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Tue, Feb 26, 2008 at 12:03:06PM +, Stephen Gran wrote: > This one time, at band camp, Petter Reinholdtsen said: > > [Stephen Gran] > > > I really hope that's not true. There are many useful use cases for > > > static linking when you're building for constrained or otherwise not > > > quite sane environments that IMHO we should continue to support. > > > Since in the main it's not that hard to do the right thing, it's > > > also of limited value to discourage it. > > > > It is worth to note that glibc do not work properly with static > > linking. All functions using PAM and NSS do not work, so binaries > > using such functions will fail when presented with incompatible > > modules on disk. > > That's pretty much always been the case with at least NSS, by design. > That being said, the interface to nss hasn't particularly changed in so > long I'm not sure this is an issue, in practice. Broken glibc due to static linking is an issue at least weekly on embedded linux mailing lists (eg buildroot). ie it's still an issue. What are the constrained environments where you think static linking would be useful? I'm developing embedded systems and I prefer shared libraries - unless you have only one application using a particular library then you will save space. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466939: ITP: hex2bin -- Converts Motorola and Intel Hex files to binary
On Fri, Feb 22, 2008 at 12:04:19AM +0100, Uwe Hermann wrote: > Package: wnpp > Severity: wishlist > Owner: Uwe Hermann <[EMAIL PROTECTED]> > > * Package name: hex2bin > Version : 1.0.6 > Upstream Author : Jacques Pelletier <[EMAIL PROTECTED]> > * URL : http://sourceforge.net/projects/hex2bin/ > * License : GPL > Programming Lang: C > Description : Converts Motorola and Intel Hex files to binary > > Converts Motorola and Intel Hex (*.hex or *.ihx) files to binary. FWIW, you can do this with the srecord package. Despite the name, it reads and writes a bunch of hex formats and binary, and can convert between them and apply various other transformations (address shift, byte swapping) etc. Note that I'm not objecting to your ITP, only proposing an existing solution. hex2bin might be simpler to use, although it could probably be implemented as a simple wrapper script on-top of srecord, and packaged with it. You can do a hex to binary conversion with: srec_cat -Intel -output -Binary Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upstream API breakage question
On Tue, Feb 19, 2008 at 03:43:09AM -0600, William Pitcock wrote:
> libprojectM upstream are soon releasing libprojectM 1.1 which makes the
> following breakage:
>
> public: PCM *projectM::pcm
>
> is replaced by:
>
> public: const inline PCM *projectM::pcm() { return _pcm; }
>
> So, is this the proper solution:
>
> * libprojectm1 -> libprojectm2
Yes, though you need to convince upstream of that, rather than acting
solely for Debian.
> * libprojectm-dev -> libprojectm2-dev
> * libprojectm-dev becomes virtual package of libprojectm2-dev
>
> If not, what should I do differently?
As Michal said, you don't need to rename the -dev package, unless you
want to support compilation against old versions of the library. If not,
it continue to use an unversioned name.
If you do want to support compilation of old versions then you need to
rename the source package also, ie have parallel libprojectm1{,dev} and
libprojectm2{,dev} packages.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463973: ITP: deejayd -- A media player daemon
On Tue, Feb 05, 2008 at 12:13:29PM -0600, Steve Greenland wrote: > On 05-Feb-08, 01:10 (CST), Hamish Moffatt <[EMAIL PROTECTED]> wrote: > > mpd has a play queue. > > No it doesn't. See SVN revision 7155. (Short version: the maintainer > didn't like the implementation, and ripped it out.) Erm, that's unfortunate. > > DSP in pure Python? Hopefully not. > No, the actual playback is via xine or gstreamer, as previously noted. > > I think this is different enough from mpd to be worth including. I'll > probably switch when it's packaged. I agree, especially having read the justifications on the deejayd wiki. My apologies to Alexandre Rossi as my earlier reply was a bit harsh. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463973: ITP: deejayd -- A media player daemon
On Tue, Feb 05, 2008 at 07:34:06AM +0100, Alexandre Rossi wrote: > > > Yes. Apparently what's special about this is that it can be > > > controlled over the network. Probably not the only one but > > > noticeable enough to be mentioned in a short description. > > > > mpd also supports that (tcp/6600). > > Yep this project is very similar to mpd. As far as I know, it improves > over mpd with the following features : > - play queue mpd has a play queue. > - video support (this is also an advantage over XMMS2 but I do not > know this project well enough to do a full comparison) Isn't that a client/front-end issue? > - xine or gstreamer backend (i.e. more supported media formats, well > tested media backends) OK. > - more easily extensible protocol because of XML and easier to extend > because of Python Wow, XML. Shiny! It must be better then(?). > It has the following drawbacks compared to mpd : > - uses more memory and perhaps more CPU time (because written in > Python vs optimized C) but it keeps reasonable, you'll see if you give > it a try. DSP in pure Python? Hopefully not. cheers Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463873: ITP: pondus -- personal weight manager for GTK+2
On Sun, Feb 03, 2008 at 11:01:36PM +0100, Eike Nicklas wrote: > Description : personal weight manager for GTK+2 > > Pondus keeps track of your body weight. It aims to be simple to use, > lightweight and fast. Is that a bad pun? I am to be lightweight too. Perhaps pondus will help. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font
On Mon, Feb 04, 2008 at 06:54:20AM +0900, Hideki Yamane wrote: > On Sun, 03 Feb 2008 15:43:27 -0600 > William Pitcock <[EMAIL PROTECTED]> wrote: > > This should be ttf-ipafont. > > Yes, binary package name is ttf-ipa, but source package name > is ipafont. Please don't do that for a source package with a single binary package output. It's unnecessarily confusing. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- 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
On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote: > Hamish Moffatt <[EMAIL PROTECTED]> >ax25-tools (U) >hf (U) Thanks, fixed these two. >libguilegtk-1.2-dev False alarm: the /usr/bin/build-gtk-guile script is actually in guile, but has a quick shell wrapper at the top. checkbashisms is fooled. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rebuilding the archive in a dirty chroot: results
On Mon, Jan 28, 2008 at 07:23:09AM +0100, Lucas Nussbaum wrote: > On 27/01/08 at 12:47 +1100, Hamish Moffatt wrote: > > trustedqsl build-depends(*) on libwxgtk2.4-dev, but your bdfh had > > libwxgtk2.6-dev installed as well. The bdfh build used the newer > > version, hence the binary dependencies were different. I'm not really > > sure how to solve this. The two libwxgtk-dev packages are > > co-installable (obviously). > > Build-Conflicts: libwxgtk2.6-dev? Possibly, although you'd really need to Build-Conflicts all future libwxgtk versions, and there's no virtual package which can be used to group them. And it doesn't really build-conflict, it just isn't the default choice... Anyway the problem has gone away for now. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rebuilding the archive in a dirty chroot: results
On Fri, Jan 25, 2008 at 03:25:15PM +0100, Lucas Nussbaum wrote: > 938 packages produced different binary packages according to debdiff. Of > those, 477 produced different Depends line (caused by some features not > being explicitely enabled, but not being explicitely disabled, usually). > > All the results are available from > http://people.debian.org/~lucas/logs/2008/01/22/bdfh/ I've fixed pcb, fldigi and tucnak2 from my list already and I'm working through the others. trustedqsl build-depends(*) on libwxgtk2.4-dev, but your bdfh had libwxgtk2.6-dev installed as well. The bdfh build used the newer version, hence the binary dependencies were different. I'm not really sure how to solve this. The two libwxgtk-dev packages are co-installable (obviously). (*) It's since been changed to build-depend on libwxgtk2.6-dev anyway. Thanks Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: elinks[-lite] doesn't provide links anymore
On Wed, Jan 23, 2008 at 02:07:57PM +0530, Y Giridhar Appaji Nag wrote: > Beginning elinks 0.11.3-2, the elinks and elinks-lite binary packages > don't "Provides: links" anymore (See bug #154859 and Debian ELinks GIT > commit a885ecead29f808310e6c2908f59f59a8d69b3ac). The links alternative > isn't installed. Wouldn't have providing a links executable been a better solution? It would have solved the bug but also not broken those other packages. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
On Tue, Jan 15, 2008 at 02:22:19PM +0100, Andreas Tille wrote: > On Tue, 15 Jan 2008, Hamish Moffatt wrote: > >> Err, like you did already for games, as you said. I see in the >> standard GNOME gnome-applications.menu. >> >> It appears that the Technical menu should include at least; >> - Science >> - Engineering >> - Math >> - HamRadio >> - Electronics > > And here we have good chances for a flame because I as a user would > not expect Science and Math under a main menu "Technical". I'd rather > see "Science" as a main menu entry and find "Math" below this. I > do not say that my point of view is correct but there is no "correct" > location for the sections and it mainly depends from users view where > he might search for certain topics. That's my arguing for grouping I thought that Science fit under Technical, if the offer was for one additional main menu. However it's clearly big enough to have its own main menu (there are lots of Science sub-categories in the standard). Math is an interesting case in that it's obviously a science, yet the tools are also used in engineering and also education. Hence your point about different user views. (On the other hand, putting everything under Technical helps too :)). Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
On Tue, Jan 15, 2008 at 02:22:19PM +0100, Andreas Tille wrote: > On Tue, 15 Jan 2008, Hamish Moffatt wrote: > >> Err, like you did already for games, as you said. I see in the >> standard GNOME gnome-applications.menu. >> >> It appears that the Technical menu should include at least; >> - Science >> - Engineering >> - Math >> - HamRadio >> - Electronics > > And here we have good chances for a flame because I as a user would > not expect Science and Math under a main menu "Technical". I'd rather > see "Science" as a main menu entry and find "Math" below this. I By the way, our main aim in proposing the original electronics-menu package was simply to get these packages out of Other and into a relevant menu. I imagine that Science is suffering similarly. I would be happy to get a simple solution in place before working on the larger problems of different user views etc. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
On Tue, Jan 15, 2008 at 11:34:10PM +1100, Hamish Moffatt wrote: > Can submenus be made to appear automatically? I should study the > standards. Err, like you did already for games, as you said. I see in the standard GNOME gnome-applications.menu. It appears that the Technical menu should include at least; - Science - Engineering - Math - HamRadio - Electronics (The Freedesktop.org menu spec doesn't list Engineering as related to Electronics, which I think is an oversight.) I'm not sure if it needs to list ALL of the relevant Additional Categories; the above are the set of related categories which cover them. Should we develop a patch for gnome-menus and submit it in a bug report? thanks Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
On Tue, Jan 15, 2008 at 10:39:03AM +0100, Josselin Mouette wrote: > Le lundi 14 janvier 2008 à 21:25 +, Peter Clifton a écrit : > > Since there are no other categories in the XDG spec which fit, this is > > really why the problem occurs: > > > > "Every conforming desktop environment MUST support" (XDG menu-spec) > > At least for GNOME, I have nothing against adding new menus. We have > already done that for games, and this could be done for other categories > as well. > [...] > I think the good solution is a new "technical" menu with optional > submenus appearing when it becomes too large. If you can agree on the > structure of this menu and make it fit as much as possible to existing > XDG categories, it could be easily added. Thanks for the suggestion. I agree, with questions: How many is too many? I understand that having many top-level menus with a few entries each may be confusing, but grouping electronics, science and hamradio applications on one menu is also rather odd. Can submenus be made to appear automatically? I should study the standards. I opened #339305 requesting gnome-menus add a ham radio menu more than two years ago and unfortunately the maintainer has not responded at all. That still leaves KDE. I guess it has its own implementation of the standard XDG menus somewhere. Is it better to have a single implementation of these extra menus that could be recommended by gnome-menus and (?)kdelibs-data? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
On Mon, Jan 14, 2008 at 09:43:35AM +0900, Charles Plessy wrote: > Le Sat, Jan 12, 2008 at 07:34:21PM +, Peter Clifton a écrit : > > > > In gEDA, the .desktop files list "Electronics" and "Engineering" (both > > of which are sub-categories), and without an additional XML file > > describing a new menu, these applications will appear under "Others" > > under gnome, or lost+found under KDE. > > Dear Peter, > > Do you know how many .desktop files in Debian use the categories > Electronics or Engineering? If there are not enough to nicely populate a > menu, it may be better to patch them to relocate them somewhere else. We have quite a few hamradio applications and quite a few electronics applications. Neither of these fit well into any existing freedesktop menu. An Engineering menu might be more generic replacement for Electronics, if there are enough other packages to make it worthwhile. Unfortunately none of the top-level freedesktop categories fits either. The registered categories list http://standards.freedesktop.org/menu-spec/latest/apa.html does not list any related categories for electronics. For ham radio, it suggests Network and Audio, both of which are inappropriate for most of the packages. Nobody on the freedesktop.org xdg mailing list seemed to care when I posted about this. > If there are enough, there is a third way of having an optional menu: > the Custom Debian Distribution. In the Debian-Med CDD, we have an extra > "Med" menu, and which user gets it is configured through debconf. All the other electronics and hamradio packages are in standard Debian. thanks Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#459627: ITP: libdmtx-dev -- header files for libdmtx
On Tue, Jan 08, 2008 at 07:30:30PM -0800, Todd A. Jacobs wrote: > On Wed, Jan 09, 2008 at 03:51:25AM +0100, Michael Biebl wrote: > > What you want instead is one source package creating 3 binary packages. > Which is what I did...but I grokked that I was supposed to create an ITP > for each .deb, not for each source package. If that was in error, I can > close all three bugs and reopen one for libdmtx0 only. > > Is that what I should do, or is there some other way to handle it at > this point? You can close the -dev and -utils bugs and retitle the libdmtx0 bug to "ITP: libdmtx". See http://bugs.debian.org/ for instructions on how to use the control interface to achieve this. > Okay, so you'd like to see three packages named: > > libdmtx0 > libdmtx0-dev > libdmtx0-utils > > Is that right? If so, I'd be glad to do it that way. If I've > misunderstood again, please clarify what's needed. Typically the -dev package should be just libdmtx-dev, unless you anticipate that it will be necessary to have both libdmtx0-dev and libdmtx1-dev in the archive at the same time in the future. This may be true for -utils also. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Thu, Jan 03, 2008 at 10:51:16AM +0100, Loïc Minier wrote: > On Wed, Jan 02, 2008, Raphael Geissert wrote: > >libavahi-common-data (U) > > Ships a GDBM file which is arch-dep; shouldn't ship it in /usr/share > though. Are those really arch-specific? That's really crap design. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFA: gpsim -- Simulator for Microchip's PIC microcontrollers
On Sat, Dec 22, 2007 at 08:12:52PM +0100, Steffen Joeris wrote: > My debian time is already taken by other debian things, so I am not > finding enough time to maintain this package properly. > If you are willing to take it over, be my guest. However, I guess it is > a good idea to also adopt the documentation package (gpsim-doc), the > module packages (gpsim-lcd, gpsim-logic, gpsim-lcd-graphic and gpsim-logic) > and the ktechlab package, which needs gpsim. Therefore, please take all > of them in one round :) If you wanted to keep it but with co-maintainers or team maintenance, consider joining the pkg-electronics group at alioth. http://pkg-electronics.alioth.debian.org has some details though it's spartan. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
On Fri, Dec 21, 2007 at 04:23:52PM +0100, Guus Sliepen wrote: > On Fri, Dec 21, 2007 at 02:28:28PM +, Gerrit Pape wrote: > > > qmail is meant as a replacement for the entire sendmail-binmail system > > on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and > > BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements. > [...] > > This is not a proper ITP. You only mention where to find documentation > on system with a supposedly already installed qmail. To file a proper > ITP, make sure you've read the policy manual about what to put in the Policy doesn't dictate the format of an ITP message though, or even a requirement to submit one. This particular ITP doesn't need to explain what qmail is (the target audience already knows) and the ITP isn't intended to be a review of the final descriptions. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
On Thu, Dec 20, 2007 at 01:06:58AM +0100, Toni Mueller wrote: > Anyway, I'll put the program where I think it fits, and it will be in > accordance to packaging rules. Sorry you don't like our feedback, but this is the reason why ITPs are posted to debian-devel. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
On Wed, Dec 19, 2007 at 11:05:47PM +0100, Toni Mueller wrote: > On Thu, 20.12.2007 at 08:50:39 +1100, Hamish Moffatt <[EMAIL PROTECTED]> > wrote: > > In that case, you could call the package funkload-tcpwatch? > > Perhaps even install the binaries in /usr/lib for use by funkload only? > > it is only one "binary", and in fact, I already thought about that, but > I'm a bit undecided yet because the program still can be used the other > way, which I'm not going to change. Renaming the package is a good > idea, but whether renaming the program itself is, I have to think over. > > For such programs, there exists /usr/libexec on some systems, but not > in Linux as far as I know. /usr/lib is suitable in place of /usr/libexec. thanks, Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
On Wed, Dec 19, 2007 at 10:01:54PM +0100, Toni Mueller wrote: > On Wed, 19.12.2007 at 18:23:19 -0200, Henrique de Moraes Holschuh <[EMAIL > PROTECTED]> wrote: > > We have *real* tcp stream/flow watchers and recorders in Debian already. > > Also, ethereal/wireshark can postprocess and analyze http traffic, if you > > require a GUI. If this new tool can do better for http traffic (which I > > this is highly irrelevant for the matter at hand because this tool is > specifically well suited to be used as a tool from inside funkload (not > by humans directly these days) to record web requests and write them to > file as Python code which you can later modify to automate web-related > tasks, or run tests against web based applications. In that case, you could call the package funkload-tcpwatch? Perhaps even install the binaries in /usr/lib for use by funkload only? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unmet dependencies on Sparc when building wordnet
On Tue, Dec 18, 2007 at 08:18:13AM +0100, Andreas Tille wrote: > On Tue, 11 Dec 2007, Cyril Brulebois wrote: > >> asking for a give-back on [EMAIL PROTECTED] should do the trick. > > What is the usual response time? I sended the mail 7 days ago. In my experience, you may not get a response but action will be taken anyway. Or that may have been a coincidence. Indeed, http://www.buildd.net/cgi/package_status?unstable_pkg=wordnet&searchtype=all says wordnet is building right now on sparc. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reporting BTS spam easily from Mutt
In case it's useful to anyone, here's a quick hack I put together for
easy BTS spam reporting from mutt.
Firstly a keybinding for .muttrc:
macro index B "unset
wait_key\nbugspam\nset wait_key\n"
macro pager B "unset
wait_key\nbugspam\nset wait_key\n"
Secondly, a script called bugspam which goes somewhere in $PATH:
#!/usr/bin/perl
# Read message on stdin, get Bug#nnn from subject line then call
# "bts reportspam" to submit a spam report
$bug = 0;
while(<>) {
if (m/^Subject: (?:\[.*\])?\s*Bug#(\d+): /) {
$bug = $1;
last;
}
}
if ($bug) {
print "Reporting spam in bug $bug\n";
system "bts reportspam $bug";
} else {
print "Bug number not found from subject line\n";
}
(And install devscripts to get the "bts" program.)
Now, hit B on bug spam and be merry.
Future enhancements might include reopening of occasional [EMAIL PROTECTED]
spam incidents.
I suppose the trend these days would be to blog this rather than post,
but I don't have one.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB-ize daemon without pidfile handling
On Thu, Nov 08, 2007 at 09:36:24PM +0100, Marc Haber wrote: > ser2net, a small daemon in a package maintained by me, cannot write > its own pidfile. Since it forks and detaches by default, > start-stop-daemon's --make-pidfile option is of no use as well, since > the daemon that ends up running has a different pid than s-s-d's > child. > [..] > > How am I supposed to properly lsb-ize ser2net's init script? Is it ok > to directly call s-s-d from the init script or do I need other > workarounds? Perhaps you could patch the daemon to add pidfile writing? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit
On Wed, Nov 07, 2007 at 08:59:00PM +0100, Sylvain Garcia wrote: > Selon Russ Allbery <[EMAIL PROTECTED]>: > > Sylvain Garcia <[EMAIL PROTECTED]> writes: > > > I would like package an application for debian and use dh_installinit > > > for install init script, but I have problem. > > > > > dh_installinit has add installation script at the of postint, but when i > > > want install my .deb the postinst script take a pause when invoke-rc.d > > > start the init script. > > > > > If I want continu I must make "Ctrl + c" > > > > Sounds like a bug in the init script. In particular, it sounds like the > > init script is starting some program that's waiting for input on standard > > input. This would be bad when the init script is run during system boot > > as well. > > > How verify if the the program start by init script wait an entry on standard > input; because when use init y hand this script work perfectly. When the script has run and hung, is the process started by the script running? Then you can get its pid, check in /proc//fd and see what file descriptors are open. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaned packages with quite some users
On Thu, Nov 01, 2007 at 12:45:29AM +0100, Frank S. Thomas wrote: > Hi, > > On Wednesday 31 October 2007, Luk Claes wrote: > > Below you'll find a list of longtime orphaned packages with quite some > > users. It would be great if people could adopt packages that are still > > usefull and give alternatives and/or migration plans for packages that > > are rather obsolete or not really usefull anymore. > > People who are interested in adopting orphaned packages might want to run > something like the script below to see the list of orphaned packges that are > installed on their system sorted by the packages' popcon scores. This may > help with deciding which package to adopt. Or use wnpp-alert from devscripts. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what's up with sparc?
On Sun, Oct 28, 2007 at 01:19:04PM +0100, Michael Banck wrote: > On Sun, Oct 28, 2007 at 11:08:07PM +1100, Hamish Moffatt wrote: > > Thanks. OK so now a few of my packages have been built after a long > > wait, but 2.5 days later still not uploaded apparently. Are they just > > waiting for manual processing of some kind? > > The .changes needs to get signed manually, as for every other upload. What's the typical frequency of that? Still no action on sparc. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what's up with sparc?
On Tue, Oct 23, 2007 at 02:16:58AM +0200, Bernd Zeimetz wrote: > Hamish Moffatt wrote: > > Are we short on sparc buildd resources right now? > > > > geda-* 1:1.2.0-1 was first built nearly a month ago but never uploaded. > > For the past week they've been hovering in the build queue but never > > making it near the top. > > sounds like #433187. > > Unfortunately still not fixed, although I didn't check the kernel.org > logs during the last few weeks. Thanks. OK so now a few of my packages have been built after a long wait, but 2.5 days later still not uploaded apparently. Are they just waiting for manual processing of some kind? Wait time on an average optional package entering testing is now 28+ days it seems. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
what's up with sparc?
Are we short on sparc buildd resources right now? geda-* 1:1.2.0-1 was first built nearly a month ago but never uploaded. For the past week they've been hovering in the build queue but never making it near the top. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to find out the sponsor of an upload?
On Sat, Oct 20, 2007 at 01:17:36PM -0300, Felipe Sateler wrote: > Hamish Moffatt wrote: > > How can I find out who sponsored a particular upload? (I only need to do > > it by hand, not an automated lookup.) > > > > I expected that I could locate the upload announcement on > > debian-devel-changes, then verify the signature to get the key ID, and > > look that up. I got a key ID, but can't find out whose it is, suggesting > > it's not in the keyring... Now I'm confused. > > the debian-keyring package has not been updated in more than 2 years. You > need to rsync the actual keyring from keyring.debian.org::keyrings if you > want to know who uploaded. > > > It would be useful if this information was recorded somewhere, > > especially as dak has to verify the key on uploads anyway. > > If you have a recent keyring, then who-uploads will show you that > information. Excellent. Thanks all for the information. The DDPO method is also useful (although it only reveals the login of the uploader, so a visit to db.d.o is often required). devscripts rocks. Thanks Julian. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
how to find out the sponsor of an upload?
How can I find out who sponsored a particular upload? (I only need to do it by hand, not an automated lookup.) I expected that I could locate the upload announcement on debian-devel-changes, then verify the signature to get the key ID, and look that up. I got a key ID, but can't find out whose it is, suggesting it's not in the keyring... Now I'm confused. It would be useful if this information was recorded somewhere, especially as dak has to verify the key on uploads anyway. As an aside, db.debian.org only allows searching by whole fingerprint, not key ID. thanks Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why MIA database restricted only for DDs
On Mon, Oct 15, 2007 at 09:15:27PM -0400, Kamaraju S Kusumanchi wrote: > Is there any reason why the database containing maintainers MIA (missing > in action) is available only for DDs? The developers-reference.pdf tells to > use mia-query for this (chapter 7). But the command is on a Debian machine > which can only be accesses by DDs. Can this be changed? I think it is limited for privacy reasons. The same with vacation and echelon information on db.debian.org. As far as debian.org systems are concerned, maintainers who are non-DDs are indistinguishable from the general public at present. Sorry about that. Perhaps the new debian-maintainers system will allow access to that information to participants. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Testing Security team
On Mon, Oct 15, 2007 at 11:06:32AM +0200, Francesco P. Lovergine wrote: > On Sun, Oct 14, 2007 at 11:38:35PM +0200, Stefan Fritsch wrote: > > > > Embedded code copies > > > > > > There are a number of packages including source code from external > > libraries, for example poppler is included in xpdf, kpdf and others. To > > ensure that we don't miss any vulnerabilities in packages that do so we > > maintain a list[6] of embedded code copies in Debian. It is preferable > > that you do not embed copies of code in your packages, but instead link > > against packages that already exist in the archive. Please contact us > > about any missing items you know about. > > Unfortunately this is not always viable, because in some cases embedded > libraries are de facto forks of the original ones, or the program > depends on a specific version (and API) of the library. Or in rare cases, the shared libraries are forks of embedded code, eg the case of Xpdf which has been forked to make libpoppler. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling of poorly maintained and useless packages
On Fri, Oct 12, 2007 at 12:33:41PM -0400, Kevin Mark wrote: > If I am a user of one of these packages who may have the skill to adopt > it or may know someone who can, I may want to know about its orphaning. > At current, this is going to be noted on -devel. > > I would like a message on the user lists on _all_ orphaned packages, > maybe just a CC of the current WNPP report? wnpp-alert may be useful to you - it will tell you if any of your packages are nominated for adoption or are orphaned. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#446057: ITP: uspp -- Universal Serial Port Python library
On Wed, Oct 10, 2007 at 11:35:15AM +0300, Martin-Éric Racine wrote: > Package: wnpp > Severity: wishlist > Owner: "Martin-Éric Racine" <[EMAIL PROTECTED]> > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > * Package name: uspp > Version : 1.0 > Upstream Author : Isaac Barona Martinez <[EMAIL PROTECTED]> > * URL : http://ibarona.googlepages.com/uspp > * License : LGPL 2.1 or later > Programming Lang: Python > Description : Universal Serial Port Python library > > USPP is a multi-platform Python module to access serial ports. You might wish to investigate python-serial instead (already in Debian) which appears to do exactly the same thing. It supports Windows and POSIX platforms. IMHO universal/multi-platform isn't actually an interesting property of a Debian package. cheers Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: configure script cannot find doc/goops/Makefile.in
On Tue, Oct 02, 2007 at 11:18:48PM -0400, Kamaraju S Kusumanchi wrote: > Dont know whether debian-user or debian-devel is appropriate for this kind > of question. Trying my luck here first... > > When I run the configure script of guile 1.8.2+1 on Debian Sid, the > configure script stops with the following error. > > $ ./configure > > . > config.status: creating Makefile > config.status: creating am/Makefile > config.status: creating benchmark-suite/Makefile > config.status: creating doc/Makefile > config.status: error: cannot find input file: doc/goops/Makefile.in > > > When asked on guile-user mailing list, I was told the problem is Debian > specific. Hence I am asking here. Is this a bug in guile? > > Despite this problem, the package actually builds fine with > $fakeroot debian/rules build So, read debian/rules to see what it does differently? The answer seems to be that it applies quite a few patches, and that some documentation has removed due to licensing problems (DFSG). So the .tar.gz is missing the doc/goops/* files and the patches are needed to remove it from the Makefiles. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
On Mon, Oct 01, 2007 at 03:11:05PM +0200, Piotr Roszatycki wrote: > I think it is because the nimbus font is released on GPL license, so > the source code is required. The Olson DB is public domain so its > license does not exact the shipping of source form. The DFSG requires us to ship the source though. Clause 2. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 10:10:52PM -0400, Edward Allcutt wrote: > On Wed, 2007-09-26 at 11:26 +1000, Hamish Moffatt wrote: > > On Wed, Sep 26, 2007 at 01:03:38AM +0200, Bastian Blank wrote: > > > m-a don't need build-essential. It needs the compiler (nothing else like > > > libc headers) for the kernel. The debian linux headers already depends > > > against the correct compiler. > > > > Maybe so, but "m-a prepare" installs it. I don't know why it doesn't > > just depend on it instead. > Perhaps because the specific compiler needed depends on what the > current kernel was compiled with? I thought that was the reason > linux-headers depended on a specific compiler version. As I said, "m-a prepare" installs build-essential always. Therefore it may as well just depend on it. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, Sep 26, 2007 at 01:03:38AM +0200, Bastian Blank wrote: > On Wed, Sep 26, 2007 at 08:44:50AM +1000, Hamish Moffatt wrote: > > It would be consistent with m-a's handling of build-essential. However, > > I think m-a should depend on build-essential since it always requires > > it. Therefore we are still undecided about bzip2. > > m-a don't need build-essential. It needs the compiler (nothing else like > libc headers) for the kernel. The debian linux headers already depends > against the correct compiler. Maybe so, but "m-a prepare" installs it. I don't know why it doesn't just depend on it instead. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 04:51:10PM +0200, Patrick Schoenfeld wrote: > Hamish Moffatt schrieb: > > module-assistant installs build-essential it doesn't seem like space is > > an important consideration. > > When i read this sentence I had an idea of what would eventually be > better. module-assistant is installing build-essential, you said. Why > shouldn't it install bzip2 on demand? It would make sense, wouldn't it? It would be consistent with m-a's handling of build-essential. However, I think m-a should depend on build-essential since it always requires it. Therefore we are still undecided about bzip2. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 11:30:37AM +0200, Patrick Schoenfeld wrote: > Steve Greenland wrote: > > It seems to me that module-assistant should recommend/depend on bzip2, > > since it is presumably m-a that is calling it. > > Since it seems as if not every module package is distributed as a bzip2 > tarball I think Recommends would be suffice. Because it is a strong, but > not absolute, dependency as described by the policy. True, but what would be the harm in depending on bzip2? Given that module-assistant installs build-essential it doesn't seem like space is an important consideration. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Mon, Sep 24, 2007 at 08:43:09PM +0200, Adeodato Simó wrote: > * Hamish Moffatt [Mon, 24 Sep 2007 10:18:34 +1000]: > > > Perhaps rt2500-source should recommend bzip2? The relationship seems to > > fit the definition - a package that is usually installed along with it > > but not strictly required. > > Can you tell us in which "unusual installation" is a package that *only* > ships /usr/src/rt2500.tar.bz2 useful *at all* without bzip2 installed? There are other tools which can read bzip2 files (eg Python's bz2 module, and the tarfile wrapper module). Or Compress::Bzip2 for Perl which is also in the archive. The dependency really belongs with the consumer of the data eg module-assistant rather than the provider. Packages that purely provide PDF files don't depend on PDF tools, although some suggest it. module-assistant happens to call "tar xjf" and should therefore depend on bzip2 (bug filed), but could equally use libcompress-bzip2-perl. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Mon, Sep 24, 2007 at 12:00:25AM +0100, Ben Hutchings wrote: > On Mon, 2007-09-24 at 08:40 +1000, Hamish Moffatt wrote: > > I wouldn't expect rt2500-source to depend on bzip2 any more than I > > expect any package providing a PDF file to depend on a viewer. > > That's different because there are many PDF viewers (and other tools > that work on PDFs). There's nothing much that can be done with a bzip2 > archive without using bzip2. There are virtual packages which could be used to express the PDF -> tools relationship if it was important to do that. As an example, the r-doc-pdf package suggests pdf-viewer. Perhaps rt2500-source should recommend bzip2? The relationship seems to fit the definition - a package that is usually installed along with it but not strictly required. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: tinytinyrss -- Web-based news reader
On Mon, Sep 10, 2007 at 01:12:45PM -0300, Marcelo Jorge Vieira (metal) wrote: > retitle 440602 ITP: tinytinyrss -- Web-based news reader > owner 440602 ! Web-based RSS (or feed) reader would be more accurate. Also upstream refers to it mostly as tt-rss, which I think would therefore be a more recognisable package name. Will you need a sponsor? I have been using tt-rss for over a year so I am interested in a package. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
On Thu, Sep 06, 2007 at 10:21:14AM +0200, Edward Welbourne wrote: > > you can at least use linda and lintian (-iI) to check your packages, > > that should help a lot. > > Indeed - I've been using lintian, and linda's on my set of things to > try during my next binge of package work. How about amd64 packages? thanks, Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Mon, Aug 06, 2007 at 10:22:22PM +0200, SZALAY Attila wrote: > At first if you poll for an fd in more than one thread you can balance > the load. (When a thread handle a message another thread can read. Just > like in spamassassin :) There's a risk of reordering the messages if subsequent messages may take different routes within the application (ie a different receiving thread); even subsequent messages from the same application, if it is not using TCP. I wonder if syslog is expected to preserve message order. It could be quite confusing... > At second there may be more than one destionation or you can connect to > a database with more than one connection. So it can be parallelable too. Same potential for reordering here. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sat, Aug 04, 2007 at 02:18:29PM +1000, Hamish Moffatt wrote: > On Sat, Aug 04, 2007 at 12:12:50AM +0200, Michael Biebl wrote: > > * Package name: rsyslog > > Version : 1.18.0 > > Upstream Author : Rainer Gerhards <[EMAIL PROTECTED]> > > * URL : http://www.rsyslog.com > > * License : GPL v2 or later > > Programming Lang: C > > Description : enhanced multi-threaded syslogd > > > > Rsyslog is an enhanced multi-threaded syslogd supporting, amongst > > others: > > Why is rsyslog being multi-threaded interesting to our users? > Isn't that an internal implementation decision? Rainer has blogged about this at: http://rgerhards.blogspot.com/2007/08/why-is-rsyslog-multi-threaded-and-is-it.html If I may summarise, rsyslog is currently only actually using two threads, one to collect messages from input sources and one to write them out. This is intended to prevent slow output (eg MySQL) potentially causing messages to be lost. This seems quite reasonable. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sun, Aug 05, 2007 at 10:25:34PM +0200, SZALAY Attila wrote: > And yes, I know that the choosen method is depend on the function. But I > think that this function is better to implement with multithread than > multiprocess, because: > > 1. Reading a log message and write it to a file is highly paralellable. > > 2. There may be a lot of paralell reading. (the config) > > 3. We have to ballance the load about message, not connection because > sometimes a small number of programs (maybe one) generate a big part of > messages. Since messages arrive on a single socket (usually connection-less) ultimately the messages enter through one process/thread. And they get written to a file or database which is ultimately not parallelable either. Is there a huge amount of processing in between which justifies multithreading? Also does rsyslog guarantee that messages are logged in the order they are sent? If messages may take different paths due to multi-threading I guess this would need extra care. > And I think that the real question is that there is place in Debian for > a multithread/process system logging daemon (against the singlethread > ones) or not. And I think that this dispute is onlt theoretical. :) My original question was why you would mention multi-threaded in the short description of rsyslog? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sat, Aug 04, 2007 at 12:24:58PM +0200, Bastian Blank wrote: > On Sat, Aug 04, 2007 at 01:44:14AM -0400, Roberto C. Sánchez wrote: > > As the "target" user for this sort of package is a sysadmin type, I > > would saw it is an important enough detail that it should be in the > > short description. > > But only in the relation: multi-threaded == bad. You need much more > knowledge to handle concurrency correctly. Yes that's my reaction also. System admins might regard multi-threaded as the key to high performance. As programmers we consider it the key to increased complexity and therefore more bugs. Multi-threaded does allow you to use more than one CPU, but in the case of syslogd ultimately the log file has to end up on disk anyway. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sat, Aug 04, 2007 at 12:12:50AM +0200, Michael Biebl wrote: > * Package name: rsyslog > Version : 1.18.0 > Upstream Author : Rainer Gerhards <[EMAIL PROTECTED]> > * URL : http://www.rsyslog.com > * License : GPL v2 or later > Programming Lang: C > Description : enhanced multi-threaded syslogd > > Rsyslog is an enhanced multi-threaded syslogd supporting, amongst > others: Why is rsyslog being multi-threaded interesting to our users? Isn't that an internal implementation decision? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [updated] Mass bug filing: Dependency/file list predictability
On Fri, Jul 20, 2007 at 10:22:52AM +0200, Steinar H. Gunderson wrote: > Hamish Moffatt <[EMAIL PROTECTED]> >kptc (U) >phaseshift (U) >qsstv (U) >ucblogo >verilog The first 4 of these are all extra dependencies on libdnet, which all come from AC_PATH_XTRA in /usr/share/autoconf/autoconf/libs.m4. It doesn't seem right to patch every package individually to fix this. Is there another alternative? Perhaps that macro could be modified so that libdnet must be explicitly enabled; the only package that actually rdepends on libdnet is from the same source package :-| Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#433812: ITP: pssh -- Parallel versions of the OpenSSH tools
On Fri, Jul 20, 2007 at 07:25:21AM +0200, Christian Perrier wrote: > I just completed the translation of a few Hamradio packages and, wow, > the hamradio jargon they use is about as intelligible as Sanskrit to > me...:-). It even sometimes takes ages before one can *understand* > that the package deals with hamradio. That's an interesting point. These applications are in their own section (hamradio) so we assume a certain lingo that most of the target audience would understand. Is this reasonable? We could explain in more detail, it's probably true that if you don't understand the description, the package isn't what you're looking for (within the hamradio section). Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Targeting RPM and Debian from a Debian box?
On Fri, Jul 06, 2007 at 05:06:56PM +, Peter Makholm wrote: > "Christian Convey" <[EMAIL PROTECTED]> writes: > > > Is this something people normally do from the same Debian workstation, > > or do they typically fire up a RedHat system to do their .rpm > > creation, and use a Debian workstation to do their .deb creation? > > Never done it myself but I would at least built the rpm in a chroot or > vserver with the target distribution installed. It looks like rpmstrap could build you a suitable chroot (like debootstap for Debian), but from the description it appears to be somewhat outdated (eg Fedora Core 2). Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#417118: ntpdate: Start sequence problem for some network setups
On Thu, Jul 05, 2007 at 02:26:43AM +0200, Marco d'Itri wrote: > On Jul 05, Brian May <[EMAIL PROTECTED]> wrote: > > > Marco> Hope that some day we will switch to upstart. > > Ok, so when do we switch to upstart? > Probably at the same time when we will switch from exim to postfix. That's just religion without technical basis. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#430206: ITP: iodine -- tool for tunneling IPv4 data through a DNS server
On Sat, Jun 23, 2007 at 01:01:40PM +0200, gregor herrmann wrote: > * Package name: iodine > Version : 0.4.0 > Upstream Author : Bjorn Andersson <[EMAIL PROTECTED]>, Erik Ekman > <[EMAIL PROTECTED]> > * URL : http://code.kryo.se/iodine > * License : BSD-like > Programming Lang: C > Description : tool for tunneling IPv4 data through a DNS server > > This is a piece of software that lets you tunnel IPv4 data through a > DNS server. This can be usable in different situations where > internet access is firewalled, but DNS queries are allowed. Hi Gregor, How is iodine different from nstx? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, Jun 21, 2007 at 05:29:47PM -0400, Ivan Jager wrote: > On Thu, 21 Jun 2007, Hamish Moffatt wrote: > >On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote: > >You seem to claim that binary units (ie powers of 2) are natural > >everywhere related to computers, but I disagree. > > Not everywhere related to computers. Only when the unit is bytes. Wow, what a concession! > >It's natural for > >memory and structures like it, but not for bitstream quantities like > >network traffic. > > Yes, for network traffic both are just as natural. Except that our decimal prefixes (10^N) are part of our language and therefore win by default. > >Most NAND FLASH chips have 2062 byte > >blocks, which even throws the memory device argument out the window. > > I have no idea about this, but I would expect > http://www.google.com/search?hl=en&q=2062+flash+nand&btnG=Search > to have more results where the 2062 is a block size... Sorry, I meant 2112. > You forgot about ECC SDRAM which is 72 bits wide. So when you buy a 1GB > (72x128M) DIMM, you're actually getting 1207959552 bytes of raw storage. Actually the controllers don't memory-map the extra 8 bits per 64. The existence of the extra bits is totally hidden between the RAM and the controller. For NAND flash however the whole 2112 byte blocks are memory mapped. After every 2112 bytes there's a gap until the next 4K boundary. > But even then, the powers of two are more natural than the powers of 10. Yes for memory structures, I agree. You failed to address my point about bitstream quantities like network traffic. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Thu, Jun 21, 2007 at 09:32:09AM +0200, Adam Borowski wrote: > On Thu, Jun 21, 2007 at 01:11:52PM +1000, Hamish Moffatt wrote: > > I think Ben's point is that we don't know. > > > > You seem to claim that binary units (ie powers of 2) are natural > > everywhere related to computers, but I disagree. It's natural for > > memory and structures like it, but not for bitstream quantities like > > network traffic. > > But they don't use powers of 10 any more than they do powers of 10. While > bps speeds are an oft-quoted case that "always" use powers of 10, the > connection I got here is guaranteed min=max 1Mbps which as far as I can > measure it goes right at 1048576 bits per second, rain or sleet. > And the ISP is one of the most despicable, cheating, greedy ones you can > imagine -- for example our company pays for that 1Mbps more than in a > civilised place you would pay for 100Mbps, so if they seen a place to > overadvertise something, they would. > > And as far as I know, usually 1Mbps stands for 1024x1000 bits where network > speeds are concerned, to be wrong by both the correct and yours > interpretation :p The raw network transports (eg Ethernet and SONET) *are* quoted in powers of 10, and they mean it. Gigabit ethernet is really a billion bits (10^9) per second. OC-3 is really 155,520,000 bits per second. Powers of 10 are perfectly natural in this case (imho). They are what we humans are used to as the default. For computer memory structures where an N bit address bus means you have 2^N bits of storage, powers of 2 make some sense, but not in the general case. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, Jun 20, 2007 at 08:11:23PM -0400, Ivan Jager wrote: > On Wed, 20 Jun 2007, Ben Finney wrote: > >The problem is that *many* cases are incorrect; we can't say that > >*all* of them are. That uncertainty is not amenable to a mindless text > >substitution without judgement of each case. The solution can only be > >for humans to find those cases where the units presented do not match > >the quantities, and to file bugs against those packages asking for the > >mistake to be corrected. > > The other solution can be for humans to find those few (if any) packages > that say MB when they mean 1,000,000 and fix only those. Then we'd have a > consistent system conforming to the standards most CS people expect. > > How many packages can you name that measure bytes in powers of 10? Are > there any? People tell me I am making an argument from ignorance, and that I think Ben's point is that we don't know. You seem to claim that binary units (ie powers of 2) are natural everywhere related to computers, but I disagree. It's natural for memory and structures like it, but not for bitstream quantities like network traffic. Hard disks are different again; I don't know that there is any particular reason for them to have 2^n byte sectors (and at the hardware level perhaps they don't). CD-ROMs have 2304 byte raw sectors. Most NAND FLASH chips have 2062 byte blocks, which even throws the memory device argument out the window. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#429801: ITP: libclass-accessor-grouped-perl -- build groups of accessors
On Wed, Jun 20, 2007 at 11:55:33AM +0200, Krzysztof Krzyzaniak (eloy) wrote: > Package: wnpp > Severity: wishlist > Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> > > > * Package name: libclass-accessor-grouped-perl > Version : x.y.z > URL : http://www.cpan.org/ > * Upstream Author : Matt S. Trout <[EMAIL PROTECTED]> > Christopher H. Laco <[EMAIL PROTECTED]>. > * License : Perl: Artistic/GPL > Programming Lang: Perl > Description : build groups of accessors > > Class::Accessor::Grouped lets you build groups of accessors that will call > different getters and setters. Are all these weird and whacky new Perl module packages in aid of something, ie are they about to become reverse dependencies of some new package? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: > On 10-Jun-07, 17:47 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > > Since then, it seems like most users have switched to apt-get and > > synaptic, with hardly anyone using aptitude or dselect any more > > Really? I'd have guessed that most people used aptitude. I can't imagine > anyone preferring synaptic to aptitude. Of course, I don't really [..] > Steve the hopelessly out-of-date dselect still works, fwiw ;) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#428188: ITP: dir2ogg -- audio file converter into ogg-vorbis format
On Sat, Jun 09, 2007 at 10:36:37PM +0200, Steinar H. Gunderson wrote: > On Sat, Jun 09, 2007 at 08:13:24PM +0200, Julian Andres Klode wrote: > > dir2ogg converts MP3, M4A, WMA and WAV files to the open-source OGG > > format. > > What is the purpose of this, besides reducing audio quality? I have used it to convert M4A podcasts into something playable on my portable player (eg ogg). Being that those the podcast is just talking the quality did not matter. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting ftp-master mails as sponsor
On Mon, May 07, 2007 at 10:14:52PM +0200, Pierre Habouzit wrote: > On Mon, May 07, 2007 at 08:10:47PM +0200, Steinar H. Gunderson wrote: > > On Mon, May 07, 2007 at 08:08:09PM +0200, Nico Golde wrote: > > > This would be nice since the NM don't have to forward them > > > to the sponsor. > > > > Have them subscribe in the PTS? > > Honestly, that sucks. I don't want to subscribe the PTS for packages I > sponsor, I do go read the BTS from time to time to check they (my > sponsoring) are doing a good job, but I don't want to receive > everything. Though, I find it a real PITA not having the confirmation > mail from Katie^Wdak. Yup. Even worse is screwing up and not getting the Naks, and the maintainer you're helping is in the opposite timezone so you don't even know about it till hours later. Sorry Magnus :-] > IOW, I do second nion request. Me too. TIA. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mandatory -dbg packages for libraries?
On Mon, Apr 23, 2007 at 07:38:15AM +0200, Mike Hommey wrote: > On Sun, Apr 22, 2007 at 08:26:38PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote: > > Mark Brown wrote: > > > I'd be interested to see some numbers on the archive size impact - my > > > experience with C++ suggests that the size inflation caused by debug > > > symbols can be enormous. > > > > I don't know about C++, but for C it depends. For example, aalib is a > > 102 kb library that compresses to 44kb. Its debug symbols are 234 kb and > > compress to 65 kb. > > > > OTOH, people rarely need full debugging information for aalib, it's > > probably plenty to see its functions in the backtrace, and not have line > > number info (bear in mind that line number info includes effectively the > > entire source code of the program). So it I build it with -g1, the > > debug symbols size drops to 48 kb and compresses to 14 kb. > > Except that -g1 drops line numbers... Wasn't that Joey's point? cheers, Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#420249: ITP: thom -- A Thomson TO7-70 Emulator
On Sat, Apr 21, 2007 at 08:13:38PM +0200, Jérémie Corbier wrote: > On Sat, Apr 21, 2007 at 05:22:00PM +1000, Hamish Moffatt wrote: > > Do these two emulators come with free ROMs and other free software to > > run in the emulated environment? > > Unfortunately, both emulators require ROMs that are not free. They are > available > on the software's website but you are supposed to own the original cartridges. Ah. Then the emulator packages (thom, teo) would belong in contrib. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#420249: ITP: thom -- A Thomson TO7-70 Emulator
On Sat, Apr 21, 2007 at 06:39:33AM +0200, Jeremie Corbier wrote: > Package: wnpp > Severity: wishlist > Owner: Jeremie Corbier <[EMAIL PROTECTED]> > > * Package name: thom >Version : 1.5.5 >Upstream Authors: Eric Botcazou <[EMAIL PROTECTED]> > * URL : http://nostalgies.thomsonistes.org/ > * License : GPL >Programming Lang: C >Description : A Thomson TO7-70 Emulator > > The Thomson TO7-70 is a computer which was widely used in French schools in > the 80s. > . > This package provides an emulator capable of running most of the softwares > that > were available for the original hardware. Do these two emulators come with free ROMs and other free software to run in the emulated environment? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to bet back to a sane version number?
On Tue, Apr 17, 2007 at 09:53:58PM +0200, Frank Küster wrote: > "Margarita Manterola" <[EMAIL PROTECTED]> wrote: > > > The only thing that worries me a bit is that this prevents any 4.22.x > > future upstream version. I guess that an epoch would be need in that > > case. (4.22.3 already prevented any upstream version in 4.22.[123]). > > Yes, therefore an epoch would be needed anyway should a 4.22.x version > be released. You could use "4.22..x-1" for that version, as a workaround. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to bet back to a sane version number?
On Tue, Apr 17, 2007 at 02:22:27PM +0200, Florian Weimer wrote: > * Hamish Moffatt: > > > FWIW you can experiment quite easily using > > > > dpkg --compare-versions x lt y && echo Yes > > > Interestingly, "4.22.." is considered higher than "4.22.3". I'm not sure > > if this is good advice though :-) > > It's also a good idea to check against APT's implementation when > playing with strange version numbers (because it's not the same). The > python-apt package contains a wrapper (not yet another independent > implementation): Good idea. What about dak - does it have its own code too? And the BTS? apt's code seems to think 4.22.. > 4.22.3 , Frank. It does look weird though. What's with having to call apt_pkg.init() manually? That's uncool. It should be automatic. Simple in a pure Python package though I know nothing about building binary modules for python. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to bet back to a sane version number?
On Tue, Apr 17, 2007 at 10:11:18AM +0200, Frank Küster wrote: > I'm currently preparing an NMU for a package which, besides an RC bug, > also has a bug in its last version number. The upstream version is > 4.22, but after 4.22-2 the maintainer uploaded 4.22.3. > > What do you suggest to get back to a sane version number until there is > a new upstream version 4.23 or higher? Is there a special letter like > ~, but not "lower than anything", but "higher than anything? That would > be great, it would just be appended to the 4.22. > > Otherwise, should I use 4.23~real.4.22-3.1 or similar beasts? Or just > go for 4.22.3-0.1 and leave the decision to the maintainer? FWIW you can experiment quite easily using dpkg --compare-versions x lt y && echo Yes Interestingly, "4.22.." is considered higher than "4.22.3". I'm not sure if this is good advice though :-) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Buzz and Rex binary packages
On Wed, Apr 11, 2007 at 04:49:21PM -0400, Lennart Sorensen wrote: > Hmm, I was under the impression that before 2.0, debian wasn't released > as binaries yet, only source packages and the source code to the > utilities needed to build the packages. I didn't really think debian > had any real installer or anything before 2.0 anyhow. More of a work in > progress. I could be wrong of course since I only actually started > using debian at version 2.0 (which was hard enough to install). No, binaries were provided for all official releases (buzz/1.1 onwards). There was an installer (known as boot-floppies); its appearance was fairly similar from buzz right through to woody when it was retired. There was no apt and no source dependencies, and early on even a different source package format, but there's still a lot of similarity. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installing packages with arch i686
On Wed, Apr 04, 2007 at 05:27:35PM -0300, Rodrigo Tavares wrote: > I created one package for architeture i686, in control > file. > > # dpkg -i pacote-1.1.6.i686.deb > dpkg: error processing pacote-1.1.6.i686.deb > (--install): > package architecture (i686) does not match system > (i386) > Errors were encountered while processing: > pacote-1.1.6.i686.deb > > How to resolve it ? Don't do that? All of our x86 support is in the 'i386' architecture. We don't have an i686 architecture. Some packages provide some optimised binaries which may be detected and used at runtime, eg in /usr/lib/i686. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debhelper and variable substitution in *.install files etc.
On Thu, Mar 29, 2007 at 03:19:21PM +0100, Paul Cager wrote: > I can use debhelper's "package-name.install" and "package-name.links" > config files to set this up, but then I have to remember to amend them > for each new upstream version. > > The rules file already has "PACKAGE" and "VERSION" variables (parsed > from the changelog). It would be really nice if the config files could > use variable substitution, so the links file would look like: > > /usr/share/java/$(PACKAGE)-$(VERSION).jar /usr/share/java/$(PACKAGE).jar > > Would anyone else find it useful to be able to use variable substitution > in the debhelper config files? You could always run dh_install with parameters from your rules file for this case. It doesn't need to source everything from the .install files. Now, do you want access to all environment variables, or a set of predefined Debian variables like $(PACKAGE) and $(VERSION)? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alioth lists are too strict in checking senders
On Thu, Mar 22, 2007 at 07:23:51AM -0600, Luis Rodrigo Gallardo Cruz wrote: > In trying to send mail to an alioth ml I got: > > The following message to <[EMAIL PROTECTED]> was undeliverable. > The reason for the problem: > 5.1.0 - Unknown address error 550-"Verification failed for <[EMAIL > PROTECTED]>\nCalled: 207.44.202.99\nSent: RCPT TO:<[EMAIL > PROTECTED]>\nResponse: 550 5.1.1 <[EMAIL PROTECTED]>... User unknown\nSender > callout failed: Sender adress can't be verified trough SMTP check." > > Shouldn't such tests cause, at most, mail to be queued up for > moderation? There probably are many users who are in no position to do > anything about sender verification failures[1], and this can efectively > cut them out from communication with many Debian projects. > > [1] Me, for one. My home ISP demands I only send mail through their > SMTP relay. Why does your outbound mail configuration affect sender verification? The recipient should only check that the address is deliverable, not necessarily that it is deliverable *to the sending server*. If you are using your own domain but relaying through your ISP to send, it seems to be a problem with your incoming server still. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: May one use ~rc1 within versions although older lintians are complaining?
On Thu, Mar 15, 2007 at 06:40:43AM +0100, Adrian von Bidder wrote: > If you're building packages for Debian, you should use a Debian machine, not > an Ubuntu machine. FWIW, you can install cross-distro chroots and use them to build packages if you need to. Not necessarily recommended for official-quality packages, but I have spun versions of my packages for Ubuntu users in the past with success, using a chroot. Debian's debootstrap package even appears to have some script files for it (though nothing more recent than breezy). You'd have to pull down the Ubuntu debootstrap package to extract scripts for edgy/feisty. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
