Bug#385756: ITP: libwww-indexparser-perl -- Fetch and parse the directory index from a web server
Package: wnpp Severity: wishlist Owner: James Bromberger <[EMAIL PROTECTED]> * Package name: libwww-indexparser-perl Version : 0.4 Upstream Author : James Bromberger <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/WWW-IndexParser/ * License : Artistic Programming Lang: Perl Description : Fetch and parse the directory index from a web server WWW::IndexParser is a module that uses LWP to fetch a URL from a web server. It then atempts to parse this page as if it were an auto generated index page. It returns an array of WWW::IndexParser::Entry objects, one per entry in the directory index that it has found. Each Entry has a set of methods: filename(), time(), size(), and others if supported by the autoindex generated: type() and size_units(). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.32 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#65611: Press Release: Re: Hoodialife Inc.
Sorry for taking so long to reply. We are sorry to inform you that our products are still not in stores. Currently we are only offering them on our product website and plan on having them in stores come October 2006. Our company Nutritionist still recommends a 4 month supply of Hoodialife for best results. If you have anymore health concerns then feel free to send me an email. Below I have posted our site for further info. Hoodialife: http://097.linewitkhatoneobject.com Shawn Lange Nutritionist Hoodialife Inc. (re)mo(val) (sy)stem (on) the (s)ite -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Code of Conduct on the Debian mailinglists
Joe Smith wrote: > > OE does support threading for Email, it is simply disabled by > default. However overall the threading is more accuracte an reliable > for newsgroups. Until this MUA is released under a free license and ported to the GNU system so it can be packaged, this crucial detail is out of interest for the most of the list subscribers, I guess. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Code of Conduct on the Debian mailinglists
"Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Mon, Aug 07, 2006 at 11:39:51AM +0900, Miles Bader wrote: "Joe Smith" <[EMAIL PROTECTED]> writes: > So I really wonder why mailing lists are so common. It sort of depends on what you're looking for. Some advantages of mailing lists: * E-mail generally has a "wider reach" -- it gets past corporate firewalls, (my company has never allowed external nntp connections), works even on strange systems, etc. Point. Then again, if your corporate sysadmins don't want you reading news, they probably don't want you reading mailinglists, either. * With email, you can use the same MUA you always use, with the features you're used to. People are _used_ to email, know how to configure it. OTOH, many MUA's (including Thunderbird, mutt with some patches, pine, Mozilla Mail, MS Outlook Express, and of course gnus (which is more of a news client than a mail client)) can read news just fine[1], with an interface that is almost the same as the mail interface. Outlook Express, which does not support threading in the mail interface, will suddenly support threading for NNTP, too. Sorry for the very late reply, but wanted to clarify this: OE does support threading for Email, it is simply disabled by default. However overall the threading is more accuracte an reliable for newsgroups. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: lsjk -- development files for arbitrary-precision numeric evaluation
Hi, On Fri, 2006-09-01 at 09:43:03 +0200, Gürkan Sengün wrote: > Package: wnpp > Severity: wishlist > > * Package name: lsjk (source package name) Could you please use the X-Debbugs-CC header when sending the ITPs instead of CCing directly debian-devel? Otherwise we don't get to see the bug number and the replies do not get recorded there, if people do not make the effort (which they would not need to do) to search the bug number in the BTS or the wnpp pages. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITPs for packages lsb-* currently in NEW
On Sat, 2 Sep 2006, Aníbal Monsalve Salazar wrote: Hello Stuart, Where are the ITPs of the following packages currently in NEW: lsb-appchk2 lsb-appchk3 lsb-build-base2 lsb-build-base3 lsb-build-cc2 lsb-build-cc3 lsb-pkgchk3 Bug #35165. (Yes, I just realized the Closes is missing in the changelog.) Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
Bashing rude users does not fix bugs they report.
Le Fri, Sep 01, 2006 at 11:36:15AM +0100, Jon Dowland a écrit : > At 1156986534 past the epoch, Michelle Konzack wrote: > > > to be fair with Mgr Tuharsky, I think that it is > > > important to remind that the bug he is talking about in > > > not affecting OpenOffice only, that it was introduced by > > > a security update, and that for various reasons the fix > > > takes months to be released, leaving users with a broken > > > Sarge. > > ^ > > Do you mean Testing? > > A security update in sarge for a different package breaks > OOo2 in some circumstances on Sarge. That is, if someone > installs OOo2, which means fetching it from elsewhere > (backports perhaps?) an unrelated security update will stop > it working. > > Personally I think the DS team have enough work making sure > security updates are a smooth process for packages *in the > OS*: being expected to test random-external-package-x on top > of that is asking too much. Hi all, here is a summary of what happened: - A security update of Sarge broke programs, some being shipped in Sarge, some being installed by the users from other sources. - The problem was quickly reported, and a fix was made. - Unfortunately, it was not released during aproximately two months. - A user complained on -devel. - It was realised by the appropriate persons that the fix was forgetten for two months. - The fixed was released in the last Sarge update. People who tried to report through the bts that the bug was not fixed were replied that it was, as they sent bugs to the package, not on the security.debian.org pseudopackage. Did the user who complained on -devel stay silent, it is possible that the fix would still wait to be released. I think that it is unfair to criticize him for having reported the problem as it appears that this is what solved the problem for real at the user level. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
claiming bugs, BTS delay, planning BSPs
Hi all, we're in the middle of the BSPMarathon[0]. Among the things new this year (as opposed to the sarge BSPs) are usertags for claiming bugs [1]. Unfortunately, the BTS is known to lag a bit these days, and it won't get better during a BSP, so I wonder how to best handle this. 0. http://wiki.debian.org/BSPMarathon 1. http://lists.debian.org/debian-project/2005/09/msg00138.html Independently, I was considering that it would make a lot of sense for each attendant to prepare for the BSP, possibly by pre-selecting bugs to work on and ideally getting in touch with the maintainer of upstream as needed well in advance. One would thus claim a number of bugs to work on a week before and prepare everything so that the time at the BSP can be used for squashing, not waiting for maintainers to get back to you. After the BSP, bugs would be automatically unclaimed. This could be done in a way like the devscripts's pts-subscribe -- via an at job. Is this a good idea? Are people already doing this? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems NP: No-Man / Together We're Stranger signature.asc Description: Digital signature (GPG/PGP)
ITPs for packages lsb-* currently in NEW
Hello Stuart, Where are the ITPs of the following packages currently in NEW: lsb-appchk2 lsb-appchk3 lsb-build-base2 lsb-build-base3 lsb-build-cc2 lsb-build-cc3 lsb-pkgchk3 Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Aug 31, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > >> Marco trolled again. FYI, no serious person disagrees with this >> interpretation. > Except every other distribution, which usually retain real lawyers > to advise them about potential problems like this instead of relying > on mailing lists posts. > It's pathetic that you dismiss dissenting opinions as "trolling". > > -- > ciao, > Marco Every other distribution does not concern itself with the question wether it is legal to distribute this. They are only concerned with "Will anybody sue us?" and "Do we loose more profit by risking a lawsuite or by dropping support?". MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Joe Smith wrote: > >> "Sven Luther" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> 1. Module and firmware in free. (The firmware can be compiled into the >> module, or can be loaded from a file.) >> >> 2. Module in free, firmware in nonfree, loaded from file by driver. [One >> could argue that the modules belong ion contrib, unless the firmware is >> optional (perhaps allowing access to non-essential features)]. >> >> 3. Module in non-free. [Firmware compiled into module, has not yet be >> seperated into seperate file. This is acceptable, but many of these could >> be converted to type 2 if somebody puts in the work]. >> >> >> I know we have some modules of type 1. I'm pretty sure we have some >> modules of type 3. It has not been clear to me if we currently have any >> modules of type 2. > > Yes, we do. bluez-firmware and atmel-firmware. > >> Obviously if the infrastucture is not there, that should be fixed. > > It's there except for d-i. Actualy D-I has the support it needs for this, at least net-retriever I checked myself. But if the cd-retriever lacks it then it is trivial to add the same code there. What isn't there is the md5sum / sha1 sum in the release file for non-free/debian-installer/* on the debian archive. A minor config problem. The only real problem left arises when you need firmware to access the udebs containing the firmware. That means if you use netboot and need firmware for the network card or netinst and a cdrom that needs firmware to be accessible. That can only be solved by building non-free D-I images that already include non-free firmware. I don't think that needs anything but config file changes for the build process. Besides D-I there is also the problem of debian-cd. Someone has to build non-free CD images that include the firmware udebs. That is mainly a infrastructure matter and not a software problem though. >> Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 >> modules. This can definately be fixed, but doing it for etch could delay >> release. > > Right. Wrong, see above. Surprisingly enough the support for this was addes _5_ years ago to support having udebs in main and local sections. A non-free section is just a variation of that. >> So the question I have is how long would etch need to be delayed to add >> support for non-free firmware to D-I? > > Joey Hess estimated 6 months work, but that was to implement a whole bunch > of uncommon special cases. I think it is totally unnecessary to implement > all, or even any, of those. > > http://lists.debian.org/debian-vote/2006/08/msg00122.html (1) was nearly done. The Release file are missing the checksums. Minor problem. > For (2) from that post, which is the key sticking point for d-i, it needs to > be done anyway, and honestly should not take more than a month if someone > bothers. > > So -- point me to the correct parts of the installer. I don't know where to > find this "anna". libdebian-installer I'm looking at -- it would be a great > help if someone could direct me to the part of the code which loads udebs > from disk/network, because I can't find it. Is that all in 'anna', which I > can't find? :-/ If I can't find the source code for 'anna', I can't fix > it. (2) was done 5 years ago (for the non-free case) by having the retriver concatenate the downloaded Packages files into one before passing it off to anna/libd-i. That way the problem is circumvented. I also have a patch for libd-i to parse multiple packages files but Bastian told me that the internal data structures of the parser will break if packages with the same name appear and dependency resolving might be off. Something I haven't yet seen happening since all my tests had disjunct Packages files. This feature would only be needed to support 3rd party repositories inside the installer though. Not for Debians non-free. One could also extend the trick of concatenating the packages file even for 3rd party repositories. The retriever just need an extra option to no delete the old file. > (3) is trivial and simply requires the will to fix RC bugs. (3) is wrong since there is a frimware-nonfree package with 2 firmware udebs in experimental for example. > > (4) is frankly not nearly as important as Joey makes it out to be. It is > very unlikely that someone will have a machine where *both* the CD *and* > the NIC *and* the floppy drive if present *and* the USB driver (USB key) > need non-free firmware. > > As long as there is one piece of hardware with fully free drivers which can > be used to load the additional non-free material on the machine, it is > perfectly tolerable that an alternate piece of hardware is not so > supported. (I've seen systems where the NIC needed non-free firmware > downloaded and ones where the CD did, but never ones where both did.) I > know it's theoretically possible that someone will buy a "hell machine" > where every single
