Re: DEP17 /usr-move: debootstrap set uploaded
Helmut Grohne dijo [Thu, Jun 06, 2024 at 09:28:52AM +0200]: > Hello, > > I have just uploaded > * base-files > * bash > * dash > * glibc > * util-linux > to unstable. These were the last remaining packages shipping aliased > files inside the package set relevant to debootstrap. > (...) > Thanks for bearing with me and also thanks to all the people (release > team and affected package maintainers in particular) who support this > work. > > Helmut Let me chime in with all of the people that have been amazed at your depth of analysis and your commitment to implementing the *properly right* situation. It cannot be overstressed that, for this release cycle, one of the main reasons Debian will probably keep its honor badge of being easy and reliable to upgrade without breakage is the work you have taken as yours. signature.asc Description: PGP signature
Re: About i386 support
rhys dijo [Fri, Jun 14, 2024 at 01:09:18PM -0500]: > My response remains the same. If it only affects a small slice of > systems that already represent a small slice of systems, it becomes > untenably difficult to chase that one bug that affects that one > case. > > But that does not translate into an excuse to drop all of the many > working legacy systems. > > This argument gets used both ways by people who just want to abandon > "old stuff," regardless of the circumstances. > > As someone who uses things until they fail, I find myself unmoved by > these excuses. > > There is always a corner case that doesn't work. But my 32-bit > machines have been able to run Linux for as long as Linux has > existed. Even under the bookworm "Intel 686-only" rules, it still > works, so I still use it. It's built, it runs, it serves a purpose, > and it costs very little. > > Dropping support for something that works based on some other much > less common thing that doesn't work sounds to me like an excuse, not > a logically valid reason. I'm very happy that Debian has provided you with a tool for your aging hardware for 30 years already. However, the Debian project (a group of around a thousand individuals, each of them working independently in their own time, and according to their own motivations) has decided to drop support for that architecture. I am sorry this becomes a pain point for you. As a project, we try to always put our users first. But there is a tension --- the amount of energy (person-hours) needed to keep i386 alive is higher than what we are willing to put up with (and there are many documented documents leading to that, mostly the most prominent of which is the architecture qualification rules). Maybe you didn't read Russ' excellent explanation as an answer to your previous message. Supporting an architecture (that, yes, still has many millions of computers that can use it, and that was the original development target both of Linux and of Debian) is not as easy as setting up some computers to compile and accept some bugs as corner cases. There are, and there will be, each time more technically-hard bugs to overcome. And there's just not the needed interest to keep it alive. In case you, and a group of devoted people, are willing to put up with the effort to keep i386 a viable architecture, please step up and do it (either as a port or as an official architecture). It is too late for you to become a DD and join the developer for architecture qualification for the Trixie cycle (but having a full-hosted i386 install as a port would not be impossible!), but you might still achieve it for our next release. In the meantime, please don't abuse volunteer time. Every minute somebody spends time answering to rants blindly saying that "this old stuff is not so broken" is a minute we don't spend making Debian better for more use cases. - Gunnar. signature.asc Description: PGP signature
Re: Mini-DebConf in Cambridge, UK - October 10-13 2024
Roberto C. Sánchez dijo [Tue, Jun 25, 2024 at 06:14:54AM -0400]: > On Tue, Jun 25, 2024 at 08:39:51AM +0530, Nilesh Patra wrote: > > On Mon, Jun 24, 2024 at 12:32:59PM +0100, Steve McIntyre wrote: > > > On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be Luna > > > Jernberg wrote: > > > > > > > > > > > > Just to be 100% clear, that mail didn't come from Luna's normal gmail > > > account but was instead spoofed and sent via emkei.cz, a "free online > > > fake mailer". It's now blocked from Debian lists. > > > > If what you're saying is correct (based on headers that make sense), it's a > > bit > > concerning since someone is launching targeted spoofing attacks with the > > name > > of actual Debian contributors. > > > > The style of writing mail - everything in one line, CCing several lists is > > similar to how Luna writes it too. Freaky. Sadly, we do have our resident, established, well-known favorite troll. And the project has quite recently made an announcement involving him: https://lists.debian.org/debian-news/2024/msg0.html So, given no evidence otherwise, I point my finger to said troll's general direction. > AI can already generate audio and video that convincingly imitate real > people. Why not the same with email? Though, the implications are rather > serious. > > Perhaps our policies need to evolve to expect (or require?) > cryptographic signatures from DDs in mailing list discussion. We may > eventually reach a point where AI can fabricate those as well, but that > seems to not be possible yet. This time around we don't need to overcomplicate things given we know it is his establihed pattern to come up with false identities trying to smear sh*t on DD's noses.
Re: Q: Ubuntu PPA induced version ordering mess.
Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]: > So, at least three possible paths: > > 1. Persuade users to uninstall PPA packages before installing official > packages and also generation 2 PPA packages with sane versions like 5.10.x > > 2. Use versions like 9000.5.10, 9000.5.12. etc. > > 3. Use an epoch. You can also consider a third possible path: Pick a different package name. I am unfamiliar with opencpn to be able to suggest an alternative. But given opencpn has never been part of Debian, you could just name your package "opencpn-deb". Just to be sure users don't get surprised by having two different versions of the same package, it can "Conflict: opencpn". Then, you get a blank slate from which you can work your versioning as you deem adequate. It does, yes, introduce some confusion, but I think is the least evil option.
Re: Finding an improved release process.
Cesar Martinez Izquierdo dijo [Sun, Nov 28, 2004 at 01:25:49PM +0100]: > Yes, we have more packages now, but we also have more developers to deal with > them. And we always have a big pool of people that wish to become DD, so man > power is not the problem, in my opinion. Remember that more people is not always better. Take a look, for example, at "The Mythical Man-Month" [1]. There is a main idea in the book: Adding manpower to a late software project makes it later. Coordination between a thousand people is _way_ more difficult than coordination between a hundred. > After Sarge is realeased, we really need to think in what are we doing wrong, > and arrange a more effective way (after a serius analysis). We can't continue > with the current trend, I think is not acceptable. IMHO, we need to think and argue about it now - We wanted Sarge to be out in less time than Woody since Woody was testing. We failed miserably. This discussion should not only take place at the end/beginning of a release cycle, but it should remain an ongoing concern. I have been quite disconnected from my mail for the last couple of weeks... But I'd like some input on an idea I posted at the Wiki [2]. Greetings, [1] http://www.aw-bc.com/catalog/academic/product/0,,0201835959,00%2ben-USS_01DBC.html [2] http://wiki.debian.net/index.cgi?PartialReleasesFullRelease -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: dselect survey
Miles Bader dijo [Fri, Dec 10, 2004 at 11:52:05AM +0900]: > Completely and utterly wrong in my case. I'm exactly the sort of person > that you apparently think should like dselect, but I think aptitude is > _far_ superior, for both experts and newbies. The competition isn't even > close. ME TOO! I liked dselect very much, and would have no problems using it... Only that I found aptitude was standard the first time I installed using d-i, decided to give it a spin, didn't really love it the first time... But by the third use, it really stuck, and now I am an aptitude convert. Far more usable, friendly, navigable has more colors, lets me play minesweeper. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]: > > I think that tying core Debian packages to the Red Hat boat anchor is a > > horrible, horrible idea. > > I tend to agree with sentiments like this, but didn't Bruce mention > that we could participate in this organization even if we didn't take > their packages? That is, perhaps we could influence the direction to > a more useful one? > > If that is the case, it seems zero risk to me. Then we would be non-participants, we would be just bitchers, telling everybody how fucked-up their process and QA are. We would gain nothing, and we would lose as everybody would say that Debian refuses to play together with the guys after giving an initial 'yes'. And no, no ISV would certify Debian just because Debian sits and bitches. I don't have a real position on whether we should join LCC or not - But if we do, we should _really_ join LCC, not just sit at the LCC table and watch them play. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
Ian Murdock dijo [Thu, Dec 09, 2004 at 04:42:29PM -0500]: > > We would never have a common kernel with these vendors anyway - they > > don't even have a common kernel with each other. My experience tells > > me that would be a big barrier to certification of any kind. > > The LCC core will include a common kernel. Ummm... Wait a second on this one. Do you think that Mandrake (I wanted to make the example with RedHat or SuSE, but it seems they also have not commited, and without them mostly any attempt to do something this big will probably fail) would want to have a kernel with less, slower or less complete hardware support? Because I know Debian does not want a kernel with propietary firmware in it. > > If there is merit to the common binaries, I think we would get more > > mileage from it by supporting them as we do the LSB: with separate > > packages on top of the Debian base system. > > That's certainly an option I've thought a lot about--the main > question is, is this good enough to get the ISV support? It probably > isn't to get the tier 1 ISVs (Oracle etc.), but it might be to > get some of the smaller ISVs, and that's better than nothing at all. Ok, so here is where exactly companies like yours come into play. I don't think the LCC (as a commercial entity, with commercial interest as you said) would be benefitted at all by supporting m68k or mips (they would be more hindered than pushed by it - It does not surprise me at all most Linux distributions pulled the plug on older or less common architectures one by one). Progeny provides a Debian-based distribution meant to be closer to the commercial world than Debian. Why shouldn't Progeny provide for this set of needs? Of course, if you are in the right mood, you can push your packages into Debian as well, although they would not be base packages. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
Adrian von Bidder dijo [Fri, Dec 10, 2004 at 04:38:10PM +0100]: > > we don't exactly have a strong history of being able to pull off > > timely releases > > Did Debian even try? > > I didn't follow the woody release too closely, being a Debian newbie at the > time, so I don't know. But - this was my impression - from the start, > sarge was prepared with the 'we release when we're ready' idea, which makes > everybody feel that they have more than enough time. Yes, it did. Debian has long tried to shorten the release cycles, without any success. That's the reason why Testing was introduced (after Slink, IIRC). I got involved in Debian close to the Woody release. We were quite optimist that Sarge would release in ~1 year - We failed. The failure has some justifications, and they all fall down to the fact that Sarge has not been ready, and we will not release before it is ready... Which is getting closer every day :) There are many proposals to make Etch and future releases come out sooner, please check them at http://wiki.debian.net/index.cgi?ReleaseProposals Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
Ian Murdock dijo [Tue, Dec 14, 2004 at 11:53:54AM -0500]: (snip) > The ISVs have spoken. They want to support as few ports as possible, > because those ports cost money. They also want to support as much > of the market as possible, and the current reality is that many of > those markets are out of reach today. Beyond that, they don't care. If > there's an open standard they can certify to and reach a broader > market, they'll be very happy with that. If commercial Linux > ends up being owned by Red Hat, they'll be fine with that too. I > for one am hoping it doesn't come to that. The current reality seems > like a pretty big opportunity to me to define a different future. Ok, so with this you are stating that the only way to get the ISVs to certify Debian is to gain market share. If by adhering to the LSB we got no results then, how would you think that by adhering to the LCC we would? Yes, it will be a bit simpler for them to have their applications run natively on all LCC-certified distributions... But they want to be sure to be able to guarantee to each of their users the application will work just as they tested it. And LCC is just one step, there is still a lot of components outside it. I really doubt that the LCC will be enough to lure them in. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: updated debian development diagram -- comments?
Kevin Mark dijo [Mon, Jan 03, 2005 at 01:08:49AM -0500]: > Hi Folks, > I have updated my diagram on the debian developement model. Any comments > appreciated! Very nice! I expect to use it at some conferences (BTW: Looks like a nice addition to Debian Eyecatcher[1], I'll add it :) ) I'd suggest you (although I don't know .fig, so...) to try to make the labels on the arrows be horizontal - Specially the ones on the left, going from "Security team .deb" to testing and stable "security updates", as it's easy to mis-read "upload" as "paoidn". Greetings! -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: updated debian development diagram -- comments?
Stephen Cormier dijo [Wed, Jan 05, 2005 at 05:28:27PM -0400]: > > Debian Eyecatcher [1] > > [1] http://alioth.debian.org/projects/eyecatcher/ > > At least I presume this is what you meant to include. Oops... Sorry, you got me right. My brain has been on vacation lately :( Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Switchconf: Orphaning or removing?
Hi, Some time ago, I adopted switchconf, a very simple bash script used to simply switch between configurations, planned for use on mobile systems, but perfectly usable on the desktop as well. Now, switchconf is too simple. It does very little, but does not do it very well. I originally intended to work with it to make it much more robust... But in the end, I didn't get around to do it. The original upstream author was also a DD (Sebastien Gross), but he orphaned the package and stopped its development. I am not working on it anymore, so I thought on orphaning it... But, as the package has never been in a stable release and it is pretty obvious, I think it should be removed. ...So this message is just to ask: Does anybody care about it, or should I just file the removal bug? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Ignoring the truth or Hiding problems? (was: Are mails sent toxxxx buildd.debian.org sent to /dev/null ?)
Marc Haber dijo [Thu, Jan 06, 2005 at 09:01:07AM +0100]: > >When Joerg Jaspert is already doing the dirty daily work, why does James > >still needs in place then? (Except he just stays in that position for a > >transitional period until Joerg is taking over that task and job completely. > >I would recommend that transitional period for other positions as well.) > > If James doesn't hinder Jörg in doing his work, I don't see a problem > with him staying in place. Frankly, the only problem I could see would > be James denying applicants faster than Jörg could approve them, but > that is (a) unlikely to happen and (b) likely to be solved swiftly. Dont worry, Jörg is perfectly capable not only of approving, but also of denying applicants. He does not need James' help for that ;-) Jörg was my AM. Most NMs pass through the set of questions that he prepared, even if they have a different AM. I know he can get quite tough... And I completely trust his ability for this. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: [Pre-RFA] Intending to drop twenty-some packages
Martin Michlmayr dijo [Tue, Feb 01, 2005 at 02:46:04PM +]: > * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2005-01-15 11:51]: > > Please CC me on follow-ups to debian-devel, or email me directly if > > you have any interest. I should follow up with RFA and O bug reports > > over the next few weeks, but doing this informally first may be > > simpler. Or maybe not. > > Did you keep track which packages have been spoken for and for which > you still need to file RFA or O reports? > > It seems at least tob is still outstanding. Gunnar Wolf seemed > interested in some of the Perl packages but it's not quite clear to me > which he'll actually adopt. I have already adopted spreadsheet-writeexcel, spreadsheet-parseexcel, ole-storage-lite and dbd-excel (renamed them to be consistent with regular use as lib*-perl). I have not adopted dbd-odbc, finance-streamer, inline-octave, math-numbercruncher, statistics-descriptive - I cannot assure you I will, but I might end up taking some of them if nobody else does. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: graph of Debian package cycle
martin f krafft dijo [Sat, Feb 12, 2005 at 04:47:27PM +0100]: > Based on the work of Kevin Mark (URL not available, sorry), I have > made a graph of the life cycle of a Debian package for inclusion in > my forthcoming book (http://debianbook.info). You can find the > sources and generated files at > > http://people.debian.org/~madduck/graphs/package-cycle/en/ Good! I do hope to be soon near a graphics-capable display ;-) I have always liked this stuff. > PS: right now it's really big in size. Sorry about that. If someone > tells me how to reliably scale a dia diagram down, I will do so, > gladly. I do it this way: dia -nt png -s800 diagram.dia This will output a 800 pixel wide diagram. Of course, this will be only as reliable as the selected resolution allows. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Info and statistics about the project
Maykel Moya dijo [Wed, Mar 02, 2005 at 02:54:09PM -0400]: > Don't know whether the appropiate list for this post should be > debian-users or this. > > March 25, a Congress of Free Software will take place at UCI, here in > Cuba. I'd been preparing myself to give a talk about the Debian Project. > > Have found tons of info disgregated across the net. But, particularily, > I'm looking for some place where I can grab objetive statistics about > the project. > > If you know about such a site, please let me know. > > Thanks in advance and forgive me If I should begin asking for this in > debian-users. ¿En Cuba? ¡Hombre! Tiene varios años que no tengo contacto con mis amigos cubanos del Software Libre... ¡Me da mucho gusto leer esto! La última vez que supe de ellos, el movimiento estaba un tanto de capa caída, un tanto tristeando... ¿Qué tipo de estadísticas buscas? ¿Qué tipo de números? No puedo asegurarte tener o saber ubicar todo (hay una cantidad increíble de datos respecto a Debian regados por la red), pero con gusto te ayudo a buscar. ¿Dónde es la UCI? Conocí a algunas personas principalmente en Santiago, algo menos en Habana, un par de Pinar. ¡Saludos! -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Info and statistics about the project
Gah... Sorry for this Spanish last mail, it was supposed to be sent only to Maykel Mora. /me ducks. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switchconf: Orphaning or removing?
Sorry... I got your mail the first time, I am sorry I could not reply to it sooner. Jose Manuel dos Santos Calhariz dijo [Wed, Mar 02, 2005 at 07:15:39PM +]: > Yes, I care about it. I use it on my laptop to have personalized > configurations for the places I connect to the Internet. For example > besides interfaces, I have a sources.list optimized for the places I > connect to the Internet, home and school. > > Now I have to install 60 PCs with Debian and there exist 3 different > configurations of monitor, graphical display and mouse. I was > planning to use it to switch XF86Config-4 and gpm.conf between the > optimized configurations. > > There exist any alternative? Most of the use I had seen for switchconf was regarding network detection - that can be perfectly handled through divine, laptop-net, laptop-netconf or netapplet... Now, I know switchconf could do some extra stuff (i.e., not be in any way tied to the network, work to switch between arbitrary files in a desktop system)... However, the script is too simplistic, can lead to strange problems, seems to have been thought for laptop-specific use, and was never popular. > What can I do to get it back into the Debian? > PS: I am not a Debian Developer. Well... It could get back into Debian for sure, but there must be somebody responsable for it. You can take the package, even not being a DD, uploading it through a sponsor. You are, besides, the second person who asked me about this, the first one was Martin Krafft <[EMAIL PROTECTED]>, who _is_ a DD... He might want to resurrect it and take it over or sponsor your uploads. I am sorry... When I decided to let it go, I gave some time expecting nobody would complain about it - and you complained just a little bit too late :-( In the worst case, you can keep Switchconf as a locally generated package, or set up your own internal apt repository for it and whatever other packages you need. I really don't like it, it is too dirty. I wanted to do a complete rewrite, but I never had time to do so. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#298354: ITP: gtk2-engines-clearlooks -- An attractive gtkengine with a focus on usability.
David Moreno Garza dijo [Mon, Mar 07, 2005 at 09:57:27PM -0600]: > > Please look at http://ftp-master.debian.org/new.html, it's already in > > the NEW queue. And hey, Ross, what about an ITP of your own? > > What should Marco do then? He is learning how to make official Debian > packages, he is following the procedure[1] suggested to people starting > like him, and I've seen him over IRC working with the package for a > couple of days. Wasn't the meaning of ITP reports to avoid > double-efforts? > > And the ITP was sent more than 18 hours ago (as NEW states right now). > > I truly consider this a little bit rude and not respectful. ITPs are meant to avoid duplicating efforts, yes... But you should not consider this action as hostile - Ross didn't file an ITP, ok, but Marc is advising Marco not to waste _his_ time duplicating Ross' (unadvertised) work. Marco is trying to start working on Debian, I don't think he _needs_ to package this specific gtk2 stuff. Marco: Just forget it, grab another package. If possible, adopt an orphan package. Damog: This is not CONSOL, people are not out to get you ;-) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299650: ITP: libhtml-fillinform-perl -- populates HTML Forms with data
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libhtml-fillinform-perl Version : 1.05 Upstream Author : TJ Mather, Maxmind LLC, [EMAIL PROTECTED] * URL : http://www.cpan.org/modules/by-module/HTML/ * License : GPL + Artistic Description : populates HTML Forms with data This module automatically inserts data from a previous HTML form into the HTML input, textarea, radio buttons, checkboxes and select tags. It is a subclass of HTML::Parser and uses it to parse the HTML and insert the values into the form tags. One useful application is after a user submits an HTML form without filling out a required field. HTML::FillInForm can be used to redisplay the HTML form with all the form elements containing the submitted info. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10-lafa Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Restrictive SMTP server
Daniel Ruoso dijo [Sat, Mar 12, 2005 at 04:18:06PM -0300]:
> I'm with a problem about sending emails @debian.org. My ESP (email
> service provider) has a restrictive rule about sending emails with a
> >From header different of the account you actually have.
>
> This wouldn't be a problem, as I could set up a mail server in my
> machine, but I am in a DSL network which is completely blacklisted due
> to spammers.
>
> The fact is that I am unable to send emails with my debian.org address.
> Does someone has some idea of how can I fix that?
Hi,
Many suggestions have already been posted - I have your same
situation, but have been working correctly with it for over one
year. What I do is:
- I deliver SMTP to the smarthost 127.0.0.1:10025
- At 127.0.0.1:10025, I have a ProtoWrap agent invoked with the script
shown below
- ProtoWrap changes the envelope and hands it over to my ISP's MTA
What is ProtoWrap [1]? A simple daemon I wrote a long time ago made to be
a generic proxy for line-oriented protocols. It works fine, but I
don't know if it is usable/useful enough for packaging it.
Ok, and here is the invoking script:
-
#!/usr/bin/perl -w
use strict;
use ProtoWrap;
my $wrap;
$wrap = ProtoWrap->new(standalone => 0,
destAddr => 'smtp.prodigy.net.mx',
destPort => 25,
destType => 'ip',
logLevel => 2,
testLine => \&rewriteEnvelope);
$wrap->startServer or warn "Can't start server: ",$_->getProp;
sub rewriteEnvelope {
my ($self,$line,$socket,$who);
$self = shift;
$line = shift;
$socket = shift;
$who = shift;
unless (ref $line) {
warn "No es una referencia: $line";
return 1;
}
if ($$line =~ /^mail from:/i) {
$$line = 'MAIL FROM: [EMAIL PROTECTED]';
}
return 1;
}
-
You will find that it might be too simplistic. In fact, it can
(seldom) lead to errors - Lets say I want to say I got a mail from
your address... You will get it differently:
MAIL FROM: [EMAIL PROTECTED]
...But anyway, it works quite nicely.
Greetings,
[1] http://www.gwolf.org/seguridad/wrap/
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
Matthias Urlichs dijo [Tue, Mar 15, 2005 at 11:14:50PM +0100]: > It won't work that well for slower architectures, for the very simple > reason that compiling everything would take a long time. > > m68k (as the admittedly extreme example) doesn't have ten buildd boxes > just because we feel like it. :-) Being m68k among the prime candidates for SCC, why shouldn't we ponder using emulated autobuilders? We have some quite decent and reliable emulators in our archive for some architectures (i.e., basilisk2 for m68k [in contrib because of the needed Mac ROMs], hercules for s390), and they do work reliably. (BTW: I have had for a couple of months a Mac Quadra 950 sitting in my house... It seems to work, but I have had no time to set it up :-/ ) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Emulated buildds (for SCC architectures)?
Hi, I haven't followed as thoroughly as I would have liked the recent verborrhea in the list regarding the Vancouver proposal. Anyway, I'd like to raise a point that I brought up during Debconf3, in the light of the changes that we are now facing. Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A completely different problem with the same results arises when using s390 machines: As someone noted recently, most of us cannot afford having a s390 running in the basement. But AFAICT, Hercules is a quite usable s390 emulator. And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that "the release architecture must be publicly available to buy new" in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? Greetings, [1] http://lists.debian.org/debian-devel/2005/03/msg01387.html -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Peter 'p2' De Schrijver dijo [Sat, Mar 19, 2005 at 03:41:46AM +0100]: > > Nowadays, an i386 system emulating a m68k (using either UAE or > > Basilisk2) is at least comparable to the fastest m68k system ever > > produced. I have worked with both emulators, and both seem completely > > safe - Yes, I know we cannot run Debian on a regular UAE because of > > the lack of a MMU in the official package, but we _can_ run it inside > > Basilisk2. > > A much faster solution would be to use distcc or scratchbox for > crosscompiling. Yes, but the argument against cross-compiling has always been stronger - If you are compiling under an emulator, you can at least test the produced binaries under that same emulator, and you have a high degree of confidence that they work reliably (this is, if an emulator bug leads to gcc miscompiling, it'd be surprising if it allowed for running under the emulator). Using cross-compilers you can't really test it. And, also an important point, you can potentially come up with a resulting package you could not generate in the target architecture. But, yes, I'd accept a cross-compiler as a solution as well in case we could not run an emulator for a given slow platform. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn dijo [Wed, Mar 16, 2005 at 08:39:48PM -0700]: > Consider: > > * SCC systems have buildds. > > * Buildds must be network accessible. > > * The first rule of securing a machine exposed to the wilds is "Deny by > default, allow by need". > > Therefore, a box which does not provide basic firewalling capabilities > (whether that's achieved by configurable ACLs, mind-reading the human > traffic trigger, or pixies inspecting every packet) is thus not suitable > for running a buildd on, and thus can never achieve SCC status. > > Sorry, but being able to cope with a hostile environment *is* a requirement > in today's network, and there isn't any real way around that fact. I have > no clue where Hurd network filtering stands at the moment, so I can't > comment on how far it is from having this feature. I wouldn't be willing to > admin any such box that was plugged into a network using a ten foot pole, > and I don't see why the DSA folks should be expected to either. I would admin such a machine precisely by using a ten foot pole - That ten foot pole can be materialized into a firewall-able machine sitting between it and the network. I agree that any Debian architecture needs to provide basic networking facilities, but I don't think firewalling is a real requirement. Yes, of course, we expect users to actually _run_ this architecture, and they will probably be connected to the network, and thus they can be at risk - But right now Debian installs are done with no firewalling rules on anyway. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)
Frank Küster dijo [Tue, Mar 15, 2005 at 02:15:15PM +0100]: > This whole argument is bogus. Up to before Vancouver, we always said: > "A package should be Architecture: any if it can in principle be > compiled on every arch; the fact that it might not be useful there does > not justify excluding it from that arch." And AFAIK the rationale for > this was overall quality of the distribution. > > Now with the requirement for 98% compiled (and N<=2 buildd's being able > to take the workload) the focus has shifted: From overall quality to > timely release and quality of individual architectures. > (...) Ummm... What do you think about this: There are packages we recognize will be of little use in certain architectures - say, KDE on m68k, qemu on a !i386, etc. They should be built anyway on all architectures where expected to run be buildable, anyway, as a QA measure - many subtle bugs appear as the result of architecture-specific quirks. "Architecture: any" means "build anywhere". We could introduce a second header, say, Not-deploy-for: or Not-required-for:. This would mean that KDE _would_ be built for m68k if the buildds are not too busy doing other stuff, and probably would not enter our archive (or would enter a different section - just as we now have contrib and non-free, we could introduce not-useful ;-) ) Would such a measure be enough for you? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release sarge now, or discuss etch issues? (was: Bits (Nybbles?)from the Vancouver release team meeting)
Ola Lundqvist dijo [Tue, Mar 15, 2005 at 09:19:45PM +0100]: > > And would a larger discussion at debconf'05 not have been more appropriate > > than handing done a couple of taken decision disguised as proposal ? > > > > It is not too late for this yet, but there needs to be a real discussion > > with > > real facts, and not just a list of resolution letting 8/11th of the project > > in > > the cold. > > Please take this kind of discussions on debian-devel as it is possible > for people not attending on debconf be a part of the discussion. I do believe that Debconf is an ideal place for this - Having 150 of us together might mean having 40 of us interested in joining this discussion, brainstorming (and shouting at each other) for ~2hr instead of over 600 messages, and coming up with something similar to the Vancouver stuff - a summary of the points reached, not a firm decision... But a summary with more adherents. And more people convinced by the release and ftp teams on what and why (or people in those teams convinced back, or... whatever :) ) Of course, if you cannot make it to Debconf, you will know about the discussion results. In fact, Debconf plans to capture audio/video of the sessions at the auditoriums, so you might even participate via IRC. I intended to propose this topic for a round table, but was asked to wait on this by one of the release members, as they were close to announcing the Vancouver stuff... Anyway, I am not formally proposing it, but I do expect it to happen - After all, we will be in HEL ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
Ola Lundqvist dijo [Wed, Mar 16, 2005 at 09:18:33PM +0100]: > Hello > > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > > Hello. > > > > > > I have several reports saying procmail does not support mbox folders > > > larger than 2GB. Questions: > > > > OT here, but WTF are people smoking, to have 2GB mbox files? > > Some people tend to have really large inboxes. I have had a number of > customers that have several GB inbox. They tend to get quite a lot > of attachments (reports etc) and do not have the time to delete mail. > It will grow quite fast. Ummm... And wouldn't it make more sense for them to switch to maildir instead of mbox? I wouldn't like to search for new mails in there. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experimental or unstable.
Simon Huggins dijo [Thu, Jan 05, 2006 at 02:03:37PM +]: > > http://www.perrier.eu.org/weblog/2005/09/30#experimental-useless > > See this worries me a bit. > > I'd love for Debian users to test some more cutting edge versions of > packages (partly so upstream gets more testers, partly so I can see the > bits I hate about the new versions and try to get them fixed) but I > don't want them in testing now until they are properly released as a > stable series. In fact, I don't really want them in unstable if it > means that in order to fix bugs which appear in testing I have to revert > to the stable set of packages in order to get them in. > > I guess the compromise is just to realise that they just won't be > thoroughly tested when they hit unstable if they've only been in > experimental before. Well... I see experimental more as an area where _you_ (be it a person or a team ;-) ) can test the work you are producing as something integrated with Debian, not as an isolated piece of work. Of course, you could set up a private apt repo for that, but it just does not make sense if we can have it all in the same place. Sometimes, work in experimental has been more widely used (by a large group of maintainers), as when having a large transition (thinking about Gnome) or work useful for many people that simply hasn't been ironed out (IIRC, OpenOffice1.9 was for some time in experimental, and it made 2.0 much easier to incorporate into unstable). Experimental _should not_ be aimed to become a complete distribution or widely tested. That's what unstable is for. And if unstable breaks on you... Well, tough luck - you knew what you were facing when you decided to install it, right? I prefer to keep unstable free of betas or snapshots - they eventually migrate into testing, and that's not good (even if your package is called foo-cvs, foo-snapshot or whatever). If a new major release of a package will change the way you do your packaging, just _prepare_ the whole show in experimental. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Stephan Hermann dijo [Sun, Jan 08, 2006 at 11:25:28AM +0100]: > > Which nobody except the Blessed Few (being those who have signed the NDA > > allowing them access to the Launchpad code) can modify or enhance. > > Everything what is on https://wiki.launchpad.canonical.com/ is free to use. > Read and think again. Or use another example: Amazons code is not free to > see, but you can use the interfaces described in their developers documents, > same applies to google api. > So where is the difference? Everybody is playing with public interfaces, > where > the sourcecode is non-free. But nobody complains. Without google e.g., as a > free, but sourcecode-non-free service, most of the people here, even the cli > guys are lost. The difference? I might use Google or Amazon for searching, might even give them my money - But my work is more important. I am a Google/Amazon _user_, but if we were to move to Launchpad, my role would be quite different - I would become a producer. And not being able to fully control what happens with the stuff I produce sucks - even more after having such control and knowing the history of the Free Software movement. > Oh, I never signed an NDA, so I've never seen the code, actually I'm not > interested in the code, because if I have a problem with the result, I can > file bugs against this products, or bug the maintainers of the code in their > present irc channel :) But you cannot directly fix a thing. > Working alone in a dark, cold cellar, translating e.g. only 30 strings and > not > knowing if someone else was translating this already, or using a webbrowser > and translating 30 strings, and see that other people are also translating? Too many projects have offered what Launchpad is offering now. People want more control than access to an interface and a decent API. People want to be independent of the whims of whoever runs it. As it has been stated before - Give us a launchpad we can install in .debian.org and include in main (even if it defeats the centralized repository idea), and it can become an option. > Well, if I see the difference between 20 people working on one application > and > translating them in less then 2 hours, or I'm sitting in a dark, cold cellar, > alone, only with vi, and translating 30 strings in 2 hours, what is more > worth for OSS or free software? Free Software as a product or as a social movement? -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Thomas Bushnell BSG dijo [Wed, Feb 15, 2006 at 06:36:11PM -0800]: > > This is not to day that Python is bad - It has better OO, which Perl > > unfortunately negletted fromt he very starts. Now, talk about Perl OO > > and that's hairy!. > > Actually, Python *also* ignored OO at the beginning. > > It has grafted it on, but since real OO is either Smalltalk or the > Metaobject Protocol, I'll have to beg off on whether C++ or Perl or > Python has "better" OO. Umh... We can talk about "more intuitive". As a Perl fan, I must say Perl's OO is far from being intuitive. Python's and Ruby's are excellent. Java's is awkward (as anything in Java is). But this only adds noice and practically no signal to the discussion :-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Xavier Roche dijo [Mon, Feb 13, 2006 at 10:55:57AM +0100]: > > > Fonts or documentations are not softwares, for god's sake! > > everything that is not hardware is software > > So a cat is a software, or a hardware ? Do I have to provide the sources > (the DNA full sequence) if I want to give a kitten to someone, following > the "free" spirit ? :p A cat is not licensed under a viral license ;-) And, more important, is not covered by copyright law (at least, I have not heard of a breeder copyrighting the colors and/or design in the back of his carefully-bred kittens) > > all the rest is excuses and play with words. > > My opinion is that my holiday pictures aren't neither hardware nor > software. Mine are mostly software nowadays, but my father still prefers the hardware version. Oh, and very important: It should be no surprise to you that I am not constant with my choice of license - Some of my pictures are _not_ redistributable nor modifiable. Some, of course, are. > > Indeed, but they should know (and we should tell them), that the hardware > > they > > are buying is not free-software friendly > > Err, I think the problem is that most users *do not care*. They just want > their card to *work*. Remember Debian is not after the market share. I'd like more people to use Debian, as long as Debian is what it has always been - And by incorporating ndiswrapper-requiring modules, it would change its essence. > I think this more productive to make their card work, AND then tell them > "this card is working with a non-free piece of thing, meaning that you may > have problems in the future in case of bugs or after upgrading your > system. please ask the manufacturer to do something about it" And break the stability promise we make? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Michael Banck dijo [Mon, Feb 13, 2006 at 03:22:39PM +0100]: > > > > > Fonts or documentations are not softwares, for god's sake! > > > > everything that is not hardware is software > > > > > > So a cat is a software, or a hardware ? Do I have to provide the sources > > > (the DNA full sequence) if I want to give a kitten to someone, following > > > the "free" spirit ? :p > > > > A cat is hardware, obviously (it's a physical entity), it runs a > > proprietary operating system, but can be taught. This is very much > > unrelated to the rest of the thread *grin*. > > I don't see how this is either relevant to Debian development per se, > nor rehashing past discussions. So please take this to another (i.e. a > non-technical) list or private. Just pray that nobody manages to compile a kernel to work on cats... -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {SPAM} Question about GFDL licensed works
Daniel Ruoso dijo [Mon, Feb 13, 2006 at 05:17:27PM -0300]: > Hmmm... I still didn't buy this argument... But it has been argued that > it is not the intent of this license clause and that, because of that, > it would not be enforceable, as, even the text not saying that, some > other references around are sufficient to disable this type of > enforcement of the license. > > I don't know where are these references (probably RMS comments), but, as > we agree it is a bug in the license, it's quite possible that such text > exists (there is a message from RMS saying he never thought this could > be applied with GFDL terms). But then again, if I chose to license something under the GFDL as it is now, being aware of this bug/feature, I have created a work that is clearly non-free, and which is licensed under the GFDL and has no invariant sections. I don't care what RMS wanted to say, but I liked the license as a good way to find you not respecting it - I can sue people! So, at least until a new revision is published, GFDL cannot be seen as free. And works licensed under the current revision with no "or later" provisions cannot be seen as free. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
Petter Reinholdtsen dijo [Mon, Mar 13, 2006 at 11:00:47AM +0100]: > > The mirror split is a complicated endeavour. From what I understood, > > the NEW queue was put on hold on purpose until the split is > > complete. > > Ouch. If that is true, I hope ftpmasters will announce it to the > developers, as a blocked NEW hinders development of Debian and should > not we a surprise. An announcement would at least give us some idea > on when the NEW holding will end, and let us plan ahead. > > It blocks my development at least, as I normally want to make sure one > level of dependencies are in the archive and doing well before I move > on and upload the next level of dependencies. Blocked NEW stops all > progress in this case, and I spend time on other things while I wait. Of course, I don't know your exact case or situation... But I think you are overreacting. It blocks your development? While the FTPmasters have their systems ready, why don't you set up a local apt repository with all of your new stuff, so it doesn't block you anymore? Yes, waiting and pinging them is annoying and robs some precious time... But not much more than that. Specially once you know they are not out there just to make you more miserable ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apply to NM? ha!
SR, ESC dijo [Mon, Jan 24, 2005 at 07:59:59PM -0500]: > while i don't appeciate gunnar's comments - seems to me he's just > trying to lessening the issue i brought up. and i do have a thick > skin, i just don't see the need to have one if people are going to > work together in a cooperative fashion. attacking people isn't the way > to do things, we have enough of it going on in the world, we don't > need to bring any more of it in here. Yes, I am trying to lessen it, not because I love flamewars, but because that's part of what we are - Certainly, it could be better if we didn't flame each other, but that is the kind of interaction that has come out of this community (as well as many others in the online world), and while words are certainly often harsh, it does not usually mean one flame's side thinks the other side is incompetent - just the opposite. What I _did_ criticize is that the NM process is meant to officialize the status of a person _already_ involved in Debian - And, if you are involved in Debian, you should know how we treat each other. For the precise example you are involved in: I hold Vorlon as one of the most respectful-easy going members of Debian, let alone one of the most technically competent. Yes, he might have said you are an asshole. I might have said the same to him. Many people have said exactly that to me. So what? If you were _that_ angry about that, you just proved you are currently not enough involved in Debian. You should get more into Debian -the social phenomenon- before committing yourself to it. > to answer some of the people attacking my character - as it seems to > me they're doing - i work well with people, you have a problem with > it? tough. judging a person based on a reaction and having had > enough of crap from people is no way to judge someone. i barely post > here, how dare you exclude me based on a raving rant like i did? i see > many people rant, if you were to exclude people based on that, you > would've excluded them already. reading some of the replies it just > gets me pissed off all over again, and wanting to rant. get a clue. If this is the only reaction we know from you, sorry, we will extrapolate. Were you a regular member of this forum, were you more involved in Debian activities, you would be better known, and you would know people better. People have criticised exactly the same aggressive behavior without being seen as soft or weak - But once we got to know them! I am by far not among the most active DDs, although I try not to drown into the back side of it. However, I do try to follow what is going on, and try to participate every time I have the ability and the time to do so. Debian is a technical proyect, yes, but it is highly social as well... If you are really interested in joining the project, you cannot miss the social part. And I really would advise you not to try to miss it - Might seem too harsh, but it is hell of fun! :) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
Ron Johnson dijo [Tue, Jan 25, 2005 at 08:24:57AM -0600]: > > > Ron Johnson <[EMAIL PROTECTED]> writes: > [snip] > > Up until a certain age the parents should be responsible for keeping control > > on the machine itself, the software it has installed and the programs they > > can > > use/install, including the ports and domains they have access to. > [snip] > > At no time Debian should be censoring any content for innapropiate. Every > > single bit of information has an audience which might feel offended by it. > > So help us parents keep control by splitting possibly inappropriate > material into separate packages. Like fortune does. Then all the > bits are there, and parents have a modicum of control. ...Ok, so we should put mozilla into this category? Hell, it's much easier to type "www.sex.com" into the address bar or to google for "naked babes" than it is to install this package. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers toVancouver critique)
martin f krafft dijo [Fri, Mar 18, 2005 at 12:57:54PM +0100]: > > The security team is under-staffed *now*, AFAICT; and you want to increase > > their workload for etch on the assumption that nothing bad will come of it? > > No, I said we should stock the security team, which I meant to read > as: add more man-power. Why has this not happened yet? This has been a known problem for quite a long time... The answer is simple: Not everybody can become a security team member, the required technical skills are quite high. There is a VERY high commitment requirement as well, so even some of the skilled people do not become part of the security team. Besides _that_, most people agree that creating new code is more fun than patching existing code, so even less people step into that position. Remember this is a volunteer project. I know of no extra volunteers willing to take up such a task as Security. You repeatedly talk about adding man-power to it. So... Are you in? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)
Steve Langasek dijo [Fri, Mar 18, 2005 at 11:32:08PM -0800]: > > There are packages we recognize will be of little use in certain > > architectures - say, KDE on m68k, qemu on a !i386, etc. They should be > > built anyway on all architectures where expected to run be buildable, > > anyway, as a QA measure - many subtle bugs appear as the result of > > architecture-specific quirks. > > > "Architecture: any" means "build anywhere". We could introduce a > > second header, say, Not-deploy-for: or Not-required-for:. This would > > mean that KDE _would_ be built for m68k if the buildds are not too > > busy doing other stuff, and probably would not enter our archive (or > > would enter a different section - just as we now have contrib and > > non-free, we could introduce not-useful ;-) ) > > As pointed out in a recent thread, most of the core hardware portability > issues are picked up just by building on "the big three" -- i386, powerpc, > amd64. If we know the software isn't going to be used, is it actually > useful to build it as a "QA measure"? What value is there, in fact, in > checking for bugs that will only be tripped while building software that > isn't going to be used? As you say, _most_ of the issues are triggered by one of those three chips, not all. And, by not making a hard requirement to compile the packages which will not be used, you are not holding the project back waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I doubt their buildds are ever idle - But what do you prefer, say, for our ia64 buildd, to just sit there waiting for a new package to arrive, or to start compiling something that will be useful only for QA, and only probably? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standard description file about maintainer groups
Ola Lundqvist dijo [Mon, Mar 28, 2005 at 10:37:33AM +0200]: > > * Sean Perry [Sun, 27 Mar 2005 18:36:49 -0800]: > > > > > Source: mysource > > > Maintainer: Bob <[EMAIL PROTECTED]> > > > Maintainers: Bob <[EMAIL PROTECTED]>, George <[EMAIL PROTECTED]> > > > > > I left the Maintainer in place to allow for some backwards > > > compatibility. This could be the 'captain' of the project. > > > > Or a list. See the Maintainer field of e.g. lintian, exim4, kde. > > And wrt 'Maintainers', there is 'Uploaders' already. > > A common way is to list the contact address for the group > as maintainer and each person responsible for uploads in Uploaders. > You miss non official Debian developers this way though. In the pkg-perl group, I often list a non-DD as an uploader, even if he cannot formally upload - He is a comaintainer anyway. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anonymous dupload stopped working
Adam C Powell IV dijo [Tue, Apr 05, 2005 at 09:55:53AM -0400]: > Greetings, > > About two weeks ago (or perhaps earlier, I don't know), > anonymous-ftp-master stopped functioning as an upload host. I think > this corresponded to a dupload upgrade (2.6.3 in testing), since the > $default_host line was commented reflecting a new dupload.conf. > > Has anyone else had this problem? I can't find anything about it using > google. And I'd like to get some bug fixes uploaded before the freeze. Hi, I have had this same problem - I will try with dput, as some people pointed out it does work. Strange thing is, looking into this specific package: http://packages.qa.debian.org/libp/libpdf-api2-perl.html It reports that it was successfully uploaded yesterday to unstable. It showed the same information some time ago (I did this same upload about a week ago). -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why do we still have this on the distribution?
Don Armstrong dijo [Tue, Apr 05, 2005 at 12:17:26PM -0700]: > If php3 has specific security problems, then file bugs against > it. Currently Adam Conrad <[EMAIL PROTECTED]> is maintaining php3, and > as I sit here, there are no bugs with severity > Normal open against > it. > > Until Adam Conrad decides that it shouldn't be in the archive, or the > bugginess of the package precludes it from being included in a release > (IE, unresolved RC bugs) the package will continue being released on > the assumption that the maintainer actually knows better than any one > else if people are really using the package. Debian does not aim at packaging _more_ software, it aims at packaging _better_ software, at offering everything a given user might need. Adam: Is there a reason for keeping PHP3 in the archive? The following packages currently are listed as its rdepends: php3-xml, php3-snmp, php3-pgsql, php3-mysql, php3-mhash, php3-magick, php3-ldap, php3-imap, php3-gd, php3-cgi, dcl, twig, spip-eva, spip, php4-cli, php4-cgi, php3-xml, php3-snmp, php3-pgsql, php3-mysql, php3-mhash, php3-magick, php3-ldap, php3-imap, php3-gd, php3-cgi, php-elisp, nagat, libphp-phplot, libapache-mod-php4, htcheck-php, dcl, dacode, checkservice, acidlab Out of those, they are all either available for php4 as well (php3-*) or depend on either php3 or php4. Is there a real reason to keep carrying this cruft? I understand the packages are not (or don't appear to be) buggy... However, their bits are rotting. They are not widely used anymore, and they might have all sorts of problems that do not get detected. I don't know if patches for the php4 modules are backported (if the problem exists, of course) for older php3 modules. Adam: Please reply :) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
Patrick A. Ouellette dijo [Wed, Apr 13, 2005 at 10:12:31AM -0400]:
> (...)
> The progression I see is:
>
> unstable -> testing -> candidate -> stable
>
> The existing rules for promotion from unstable to testing continue to be
> used.
>
> Promotion from testing to candidate requires meeting the same rules as
> promotion from unstable to testing with the following exceptions:
> packages must be in testing for at least 3 months, and have no release
> critical bugs.
>
> Promotion from candidate to stable would follow a similar pattern, with
> a time in candidate requirement of 3 additional months.
Umh... There is a simple problem with your proposal: Most of my
packages are quite stable, yes, but some would never reach candidate
status. Try uploading a package every five days (with priority=low) -
it will never reach testing, as the old version disappears under the
new one.
Yes, this could be sorted out, so that old versions no longer
disappear until ${fateful_event}. This would create more problems: If
a RC bug report is closed, you will have to keep track of which upload
did the trick, not considering any of the ones below it for testing or
candidate.
Finally, this would make any library migration a real nightmare :-/
You'd have to somehow keep the archive synchronized, doing something
similar to what is currently done re:testing, but on a _much_ broader
scale. Tracking dependencies and FTBFS bugs could become basically
impossible.
...But if you come up with an implementation, I'll just shut up :)
Greetings,
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
Patrick Ouellette dijo [Sat, Apr 16, 2005 at 01:04:59AM -0400]: > (...) > Another difference is that testing will get new versions of packages and > those versions might (but should not) cause breakage. Testing has had > breakage issues in the past. Ten days is not enough time to catch all > the possible interactions (or even the majority of them). I'm also not > naive enough to think that my proposed "candidate" step will never cause > breakage. The purpose of the additional step is to have a place where > things change slower than testing to catch more of the obscure bugs that > only become apparent with more time. By requiring there be 0 RC bugs to > progress from "testing" to "candidate" and "candidate" to "stable" we > cause stable to change when the software really stabalizes, not at an > arbitrary time selected by the release team. Umh... And... Well, if a RC bug is found in candidate, will it take (a very minimum of) one month for the fix to get there? Don't you think that, during the release cycle (and specially during its first phase after a release) we will always have one RC bug keeping a second one from getting fixed? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302278: ITP: libuser-identity-perl -- manages different identities/roles used for email
Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf <[EMAIL PROTECTED]>
* Package name: libuser-identity-perl
Version : 0.90
Upstream Author : Mark Overmeer <[EMAIL PROTECTED]>
* URL : http://perlovermeer.net/userid/
* License : GPL + artistic
Description : manages different identities/roles used for email
The "Mail::Identity" object contains the description of role played by
a human when sending e-mail. Most people have more than one role these
days: for instance, a private and a company role with different e-mail
addresses.
An "Mail::Identity" object combines an e-mail address, user description
("phrase"), a signature, pgp-key, and so on. All fields are optional,
and some fields are smart. One such set of data represents one role.
"Mail::Identity" is therefore the smart cousine of the Mail::Address
object.
This module is required by the new upstream version of libmail-box-perl,
already in the archive.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-lafa
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Orphaning recover and makeztxt
Hi, I have just orphaned two of my packages, I hope somebody among you wants to pick them up. They are recover (#307558) and makeztxt (#307557). Recover lets you recover (duh) deleted files in ext2 filesystems. Note that it is in ext2 and _not_ in ext3 - I once talked with some people about removing it, but I was persuaded to keep it, as there are many ext2 users still in some platforms that don't run kernel 2.4/2.6 - I don't know if now that we are moving to Sarge they will still be counted in... Possibly it'd be time to remove recover. About makeztxt, it is a nice program to convert text files into ztxt files, apt for reading in a Palm with the (GPLed) Weasel reader. It has a simple regex engine used to create the TOCs, and works just fine. The problem is, I no longer own a Palm, so I cannot do much with it. Both packages move very slowly (IIRC, two years since their last release). The bugs against WNPP have been filed. Do you want to pick them up? Do you want recover out of Sarge? Speak up! Greetings! -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
Thomas Hood dijo [Wed, May 04, 2005 at 12:05:19AM +0200]: > I have been looking at the lsb init functions and am beginning to feel > that they are a bad idea. It will be a hard time converting to them, but in the end I think it will be a net gain. > * Converting to lsb init function requires modifying every initscript in > Debian. > > * Every initscript has to read in a file containing a set of function > definitions, some/most of which the initscript does not use. Yes. Inertia is hard to break - But it is often necessary. > * The lsb functions don't handle all the kinds of output currently > produced by initscripts. Ummm... But we currently only print the message. We can print the informative messages _and_ return a meaningful success/failure value. Further more, the base LSB functions can be extended if there is need for it. > I think it would be better if we simply made rc capture initscripts' > standard output (and exit status) and formatted it in such a way that > bootup messages were prettier. It is not just about prettyness, but about giving more concise and useful information at a first glance - about usability. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning recover and makeztxt
John H. Robinson, IV dijo [Wed, May 04, 2005 at 10:21:37AM -0700]: > John H. Robinson, IV wrote: > > Gunnar Wolf wrote: > > > Hi, > > > > > > About makeztxt, it is a nice program to convert text files into ztxt > > > files, apt for reading in a Palm with the (GPLed) Weasel reader. It > > > has a simple regex engine used to create the TOCs, and works just > > > fine. The problem is, I no longer own a Palm, so I cannot do much with > > > it. > > > > I will happily pick this up for you. > > Looks like there were a few takers for this: > > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > I am happy to let Rolandas Juodzbalis have it. Yup, he was the first taker. I will sponsor his upload. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about apt-get upgrade/install semantic
Daniel J. Axtens dijo [Fri, May 06, 2005 at 01:36:06PM +0800]: > > and not > > "apt-get upgrade " > > Possibly because apt-get upgrade is used to upgrade the whole system, > not just one package. My guess is that the developers didn't want to > overload the upgrade command. It is not only that - It is because apt-get is an infrastructure manager, not an individual package manager. dpkg does work on single packages, but apt-get works on the whole collection - and it could lead to inconsistencies if you let apt-get do a half-assed job and upgrade just one out of many packages - There might be dependencies down there, and this kind of command would not follow them (or would be inconsistent with the user's wishes of upgrading _only_ that). Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG dijo [Mon, May 09, 2005 at 03:08:57PM -0700]: > >> If there is a reason to separate /usr from / (which so many people > >> think there is, though I don't understand why, since it has no > >> semantic significance at all), why separate /lib from /etc? > > > > I don't see a semantic difference between /bin and /usr/bin (or /lib and > > /usr/lib). IMHO, the only reason for /bin and /lib is that some programs > > and libraries need to be available before is /usr is mounted. > > That doesn't make sense. If you get rid of the /usr vs / distinction, > then there is no "before /usr is mounted". As far as I have always understood this, there is an important distinction: / should have everything needed for booting the system into a mode that can be used to solve problems. This means, if you are performing an installation on very reduced media, you only put / in it, and /usr is network-mounted. This was quite a common setup some years ago, and is still somewhat common. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mrtg package problems
Adam Majer dijo [Tue, May 10, 2005 at 12:23:10PM -0500]: > Currently there are two packages that he maintains, > > http://qa.debian.org/[EMAIL PROTECTED] > > *libnet**-easytcp-perl > **mrtg > > I would like to maintain mrtg since I do use it. As to the other > package, it probably should be orphaned. I am not currently using it, but seems easy to maintain - I'll take it over. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian as living system
Raphaël Pinson dijo [Wed, May 18, 2005 at 09:45:03PM +0200]: > >(...) > > Quelle verve :) A en faire pâlir Cyrano de Bergerac ma foi ! > La liste est cependant anglophone je pense, et nos pauvres collègues non > francophones ne peuvent malheureusement pas profiter pleinement de la qualité > votre pamphlet ;) I have to agree here, even with my pathetic understanding of French through Spanish similarity :) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regarding unresponsive Debian maintainers
Tollef Fog Heen dijo [Tue, May 24, 2005 at 10:27:36AM +0200]: > * Cesar Martinez Izquierdo > > | I don't think co-maintenance needs to be a "must", but I totally > | agree that is always possitive and it should be encouraged someway. > > No, it is not always positive. Co-maintainence means you have a way, > way higher overhead at maintaining the package. I don't have to > coordinate uploads, checkins and so on with myself, for packages with > comaintainers, I do. Depends a lot on the nature of your packages. The majority of my packages are comaintained with the Pkg-perl group - Yes, they are usually quite simple packages. However, what we have usually done is that whoever has time to fix an issue just goes ahead and does it - Up to now, we have not trampled over each other. It could happen, yes, and the probability grows if the packages are larger or the bugs are more intrincate, but anyway, most of Debian's packages are quite straightforward. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unloyal competition
Joey Hess dijo [Sat, May 28, 2005 at 07:10:35PM -0400]: > I will not be online between June 2nd and 5th. Don't release without me! ;-) Hey, this might give some people extra information for getting a free beer[1]! Anyway, have a good time [1] http://www.grep.be/blog/2005/05/28/#release_pool -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
Ron Johnson dijo [Wed, Jun 01, 2005 at 05:48:46AM -0500]: > > A while ago, in an IRC discussion, it was revealed that a notary in the > > US doesn't mean as much as it does in Europe. > > > > AIUI, in the US, a notary is just some extra title a lot of secretaries > > have, so that they can make some documents more official. > > That's wrong. You take a non-trivial test, and be background checked. > > The secretaries you are referring to are 99.9% of the time in law > offices and title-transfer companies. Well, the main point behind this still stands: In the US, notaries are quite common and cheap. In Mexico, they serve +- the same role as there (gathered from your other replies in this thread and from what I know), but I don't think a single notary in this city would certify that I am the guy that appears in my government-issued ID without charging me some US$200 first, at the very least. Most people in this country don't make more than US$400 a month, so notaries are an unaffordable luxury. ...And that for simple transactions. My father bought his house a couple of years ago. IIRC, the notary's fee for the transaction was closer to US$1500. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Goswin von Brederlow dijo [Sun, Jun 12, 2005 at 08:46:47AM +0200]: > Intermittendly we had a multi floppy setup. > > The first floppy contains the kernel and a minimal initrd. That > prompts for the second floppy and the user to press return and then > adds the contents of the 2nd floppy to tmpfs. > > There was just one problem with it: > The floppy was to small to include usb keyboard support. Ummm... And if instead of asking the user for a disk change, this mini-initrd just keeps polling the floppy for a non-erroneous read (this means, the drive is not empty) with the correct magic at the correct place? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Joey Hess dijo [Wed, Jun 15, 2005 at 09:40:59PM -0400]: > Gunnar Wolf wrote: > > Ummm... And if instead of asking the user for a disk change, this > > mini-initrd just keeps polling the floppy for a non-erroneous read > > (this means, the drive is not empty) with the correct magic at the > > correct place? > > This assumes that the kernel works better than it really does. You'll > get oopes on some machines, I can tell you from experience. What can I do but long at the Amiga? ;-) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: And now for something completely different... etch!
Andrew Suffield dijo [Tue, Jun 07, 2005 at 02:32:53PM +0100]: > > - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5 > > No way. Debian has always avoided mindlessly dictating what runlevels > must be used for. There's no reason to destroy this feature now. And > there's no advantage to consuming an entire runlevel just to say > "/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is > all that you are proposing. We could provide default settings that lead to the LSB-specified functionality that Javier suggests, but without falling in RedHat's IMHO fucked up habit of starting [xwkg]dm not from an explicit script (/etc/rc?.d/Sxx?dm), but directly from /etc/inittab, hiding it from the user. If our display manager packages are set up to start only from runlevel 4 or higher, but you and me can set them up to start on any lower ones, we'll all be happy, won't we? Same thing for networking. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: And now for something completely different... etch!
Enrico Zini dijo [Thu, Jun 09, 2005 at 12:49:39PM +0200]: > I've been it_IT.UTF-8 for quite a while with no problems. And I also > get to be able to write the name of my girlfriend, which Latin1 cannot > encode, together with accented Italian words, which BIG5 cannot encode. H... Silly me thought that Italian was the only Latin language which used no diacritics. Which kind of accents does it have? (yes, OT and couple-of-days-late, I know) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: automated updates of debian/changelog considered harmful
Christian Perrier dijo [Wed, Jun 08, 2005 at 06:13:21PM +0200]:
> > Nowadays, the recommended way to update config.sub/guess is transparent,
> > Debian-specific (but friendly to any sort of upstream config.sub/guess
> > usage pattern), version-control friendly, and also non-.diff-bloating.
>
> Could you develop on that topic (or point me to some good reference,
> of course)?
>
> At this moment, I'm afraid my way to update config.{guess|sub} in
> lifelines and poedit *is* actually diff-bloating (I have removed the
> automated change to debian/changelog).
Don't copy the files over - Remove them during 'clean' and create a
symlink to them as the first step in 'configure'. (Why remove them?
Because otherwise diff will fail, as you cannot represent the symlink,
and your package build will fail)
Greetings,
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Richard Kettlewell dijo [Fri, Jun 10, 2005 at 03:42:01PM +0100]: > I think it doesn't go far enough. > > mv sbin/* bin > rmdir sbin > ln -s bin sbin > > ...and the problem goes away forever. You type too fast. Are you _sure_ no two Debian packages provide overlapping /bin/$that and /sbin/$that ? Or /usr/bin/$foo and /usr/sbin/$foo ? Or (going back some flamewars^Wweeks) /bin/$bleh and /usr/bin/$bleh ? ...Or, mix-and-match, /sbin/$this and /usr/bin/$this? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
Adam Majer dijo [Wed, Jun 15, 2005 at 01:15:00PM -0500]: > > - Change boot system, to one capable of handling dependencies and > > parallell invocation, to speed up the boot process. > > > > > Err.. Why? The current "slow" bootup is caused mostly by hardware > detection from my experience. Speeding up hardware detection or remove > it in favour of manual /etc/modules entries would speed up the boot > process a lot more than changing the boot process. If it ain't broke, do > not fix it. My systems have no hardware detection at all - But they start many daemons at boot time. Probably, say, Apache and Postgres could be started concurrently, saving some extra time. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315903: ITP: evilfinder -- proves that any given subject isevil
Miles Bader dijo [Wed, Jun 29, 2005 at 03:14:02PM +0900]: > Marc Singer <[EMAIL PROTECTED]> writes: > > Whew. That was close. I thought we were gonna lose evilfinder. > > ... if we did, that would show that Debian really _is_ evil -- and if > that's true, evilfinder must be capable of true prophecy! It would seem > almost criminal to reject a program capable of true prophecy. > > So either Debian includes evilfinder or it _must_, by law, include > evilfinder. Evilfinder is apparently irresistible -- and surely we want > to include irresistible programs? > > QED. or something. Oh, come on... Weren't we discussing how to get rid of circular dependencies? Now paracircular metadependencies? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling dijo [Mon, Aug 07, 2006 at 12:24:57PM +0200]: > As long as people from Debian are on calumiation campaigns aginst > OSS authors, Debian needs to be called non-free. It's not like publishing software under an allegedly free license makes you a saint, you know? > > GR stated that invariant sections aren't acceptable for the specific > > GFDL case, and there is no reason why they would be acceptable for > > If Linux Distributions would not distribute bastardized versions of cdrecord, > there was no need to add the statements you might be talking about. Any free license allows for forking, allows for us modifying and redistributing your work. If we consider some parts of your code unfit, and you say you write Free Software, you should not have a problem accepting us to distribute those changes to your sources. Why are you so bitter about it to call "bastardizing" what should be called "distributing modified versions of"? > You should better inform yourself on the Debian project and about the > GPL. The phrases that are inside cdrecord, have been clearly accepted by > Debian > more than 4 years ago and they have been 100% GPL compatible as long as > cdrecord was published under GPL. Note that there are no invariant sections > in my sofware. As long as you do not create problems with my reputation > (which > meand that you may need to call cdrecord e.g. "kindergarten", you may apply > any changes you like). Thing is that different programmers will look differently at the same problem - And if most people looking at your approach feel it should not be done that way, what's your big problem with them modifying your logic? They are not "creating problems with your reputation". They label the software as originally written by you, but maintained for Debian by another Joerg, an Eduard and a Steve. > There are definitely NO issues with the CDDL. The CDDL gives at least > as much freedom as the GPL does and the CDDL is a first class OSS license. > It has been accepted by the OSI and this is sufficient for anybody. ...By OSI. That's an important part, but not all of, the Free Software camp. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling dijo [Thu, Aug 10, 2006 at 02:49:36PM +0200]: > As I _did_ already receive coplaints against cdrecord that have been e.g. > based > on the fact that Linux distributoions change the name for the file > /etc/default/cdrercord and the fact that the basterdized behavior is > incompatible with the (officially) documented behavior, these Linux > distributions cause harm > > Free software gives you the right to change software but free software > definitely does _not_ give you the right to use the originam _name_ of the > software in case you apply incompatible changes or in case that you introduce > bugs. The license is related to "urheberrecht", using the original name > of the software is related to trade mark right > > If people at Denbian are missing this kind of basic knowledge, how > would it be possible to discuss license issues in a serious way? I am currently maintainer (co-maintainer for most of them) for 70 packages, most of them quite easy and low-maintenance. However, some of them have patches, maybe adding a specific functionality the author didn't want to include in his official version, maybe fixing some idiosyncratic differencies (i.e. PDF::API2 comes to mind - It defines sections in its documentation which don't cleanly map to what's used in regular manpages, so I did the changes, but I must keep patching the author's official module). You say that I don't have the right to distribute this under the name PDF::API2 in Debian, do I understand correctly? Please tell me: This module is a Perl library. If I modify it to become PDF::API2::Debian, how will our users' code be portable? How can other pieces of code link against this one and not be Debian-specific? A compromise we have reached in some cases is to change the _version_ number (i.e. in Mail::IMAPClient, where I had to remove some non-free files from the distributed tarball) appending '+deb' to it (so for us it's now 2.2.9+deb-4). It clearly shows it's not the original author's code, but that the code _is_ contained. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of typo3
Hi, Grave bug #364351 was filed in December, and it has seen basically no activity since April. The new upstream version, 4.0, seems to have fixed the reported problems. I am Cc:ing this mail to debian-devel to ping the public for their opinions... Last upload by the maintainer Christian Leutloff is from May 2005. Christian, are you still working on it? Should somebody else take over? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Bug#384407: ITP: libtest-harness-perl -- Run Perl standard test scripts with statistics
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libtest-harness-perl Version : 2.62 Upstream Author : Andy Lester <[EMAIL PROTECTED]> * URL : http://www.cpan.org/modules/by-module/Test * License : Same terms as Perl itself (GPL+Artistic) Description : Run Perl standard test scripts with statistics Test::Harness is an utility script invoked by Test::Simple, Test::More and several based on Test::Builder. It is also part of the perl-modules installation. This module is packaged to satisfy the build-dependency of several other Perl modules over a newer version than the one perl-modules provides - Please refer to bug #383517 for the rationale on separately packaging it. -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.14-cajita Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITPs for packages lsb-* currently in NEW
Stuart Anderson dijo [Sat, Sep 02, 2006 at 09:41:27AM -0400]: > >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.) Ummm... I think you mean #356165 - the low number surely got my attention ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386146: ITP: libconfig-file-perl -- Parses simple configuration files
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libconfig-file-perl Version : 1.4 Upstream Author : Gunnar Wolf <[EMAIL PROTECTED]> * URL : http://www.cpan.org/modules/by-module/Config * License : GPL+Artistic Description : Parses simple configuration files ConfigFile parses simple configuration files and store its values in an anonymous hash reference. The syntax of the configuration file is quite simple: # This is a comment VALUE_ONE = foo VALUE_TWO = $VALUE_ONE/bar VALUE_THREE = The value contains a \# (hash). # This is a comment. COMPOSED_VALUE[one] = The first component of a clustered value COMPOSED_VALUE[two] = The second component of a clustered value This module is already packaged in Debian as libconfigfile-perl (dpkg-sig and apt-file depend on it) - It is a native package, and I am renaming it in order to make it available in CPAN for wider distribution and to turn it into a non-native package. -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.14-cajita Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387179: ITP: libnet-arp-perl -- Create ARP packets and lookup for ARP information
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libnet-arp-perl Version : 0.8 Upstream Author : Bastian Ballmann <[EMAIL PROTECTED]> * URL : http://www.cpan.org/modules/by-module/Net * License : GPL + Artistic Description : Create ARP packets and lookup for ARP information This module allows for creating arbitrary ARP packages from within your Perl code, as well as for looking up the ARP information for machines in your local network -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.14-cajita Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning my packages
Martín Ferrari dijo [Wed, Sep 13, 2006 at 03:26:43PM -0300]: > On 9/12/06, David Moreno Garza <[EMAIL PROTECTED]> wrote: > > >If you think you could adopt some of the packages, feel free to do it > >(filling an ITA would be nice). Just talk to the Debian Perl Group > >first, if thinking on adopting some of the Perl modules; talk first > >to the pkg-ruby-extras groups if thinking on adopting some of the > >ruby modules, also. > > I'd like to adopt some of the -perl packages, but I don't know what > has to be coordinated with the perl group. Can somebody comment? Hi, I was planning on starting the wide adopting process to the group, but if you can help, much better. In my experience, the pkg-perl group has helped me not appear like an irresponsable maintainer (which I am! :-P ) during my stress periods. So, Mart�n, if you are not currently part of the group, I can add you - just give me your Alioth user name and promise to do no intentional harm. So, taking from Damog's developer page - We need to adopt: libcontextual-return-perl libcurses-widgets-perl libend-perl libio-prompt-perl liblingua-es-numeros-perl liblist-compare-perl libmath-fibonacci-perl libmath-nocarry-perl libmath-randomorg-perl libmath-vec-perl libnumber-compare-perl libopengl-perl libterm-size-perl libwww-freshmeat-perl libwww-google-calculator-perl libwww-myspace-perl They look quite simple, the only three open bugs on them look trivial to fix. We should check for updatedness, add watch files, and... Well, simple stuff in the end. Perl group: Should we? Who starts? David: Best luck. Hope to see you back here soon! -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Manpages in language-specific packages
Hi, I'm adopting liblingua-es-numeros-perl, a Perl module for translating numbers into their Spanish string representation. One of the first things I noticed is that the manpage is completely (and only) written in Spanish. So, besides sending any changes I do to the upstream author (although the module looks unmaintained, with only version 0.01 existing since 2001), what would be wisest? - Leaving it as it is - Translating only the manpage description, perhaps first section - Don't think it would be the best, as it might have non-ES users (although the whole module API is in Spanish) - Translating the whole manpage, and providing the Spanish translation as a separate file in /usr/share/doc (pointing at it from the manpage) - Going the inverse way, leaving the package as close as possible to its current status, and pointing to an English translation from /usr/share/doc - I18N in manpages? Sorry, haven't been there, haven't done that Personally, I don't feel it natural having a Spanish-only manpage. But then again, I'm among the nasty minority who does not like his computer to use his mother tongue ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Manpages in language-specific packages
Felipe Augusto van de Wiel (faw) dijo [Thu, Sep 14, 2006 at 12:31:35AM -0300]: > >>- I18N in manpages? Sorry, haven't been there, haven't done that > > > > It's not that difficult, just put the (english) manpage in /usr/share/man/ > > and the i18n manpage in /usr/share/man/XX. Man takes care of the rest. > > You could use po4a, it is an amazing tool to work with different > formats and convert them into PO files, than you could easily request > for translator on -i18n. ;) > > http://po4a.alioth.debian.org/ Hmh... Looks noble, but in the case of a very simple and quite unmaintained Perl module, I don't really think it's worth it to go so far away from the original author's way - I will follow Javier's advice... Of course, once I have time and finish adopting the modules I told I would :) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free flash player for your browser (Was: Running x86-64 debian inside i386 pbuilder on AMD64)
Petter Reinholdtsen dijo [Tue, Sep 26, 2006 at 01:10:55PM +0200]: > > [Tollef Fog Heen] > > Not having flash is a good, not a bad thing to me at least. :-) > > Now you can have flash support for your browser in unstable, at least, > by installing the mozilla-plugin-gnash or konqueror-plugin-gnash > package. The gnash package is already capable of running quite a few > flash pages, and upstream is improving it every day. :) > > And it even work with amd64 CPUs. :) In my experience, it will even _require_ AMD64 or similar CPUs to display even trivial pages. Gnash is still a long way for being useful on most machines - it's just too heavy. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Desktop task(sel) in Etch? (Bug #389092)
Yves-Alexis Perez dijo [Tue, Sep 26, 2006 at 05:45:14PM +0200]: > Xfce is quite popular now, and I guess people would be happy if they > could have a Xfce Debian CD if KDE & Gnome people have one. I don't know > how hard it is to add a specific CD from a task, but if it's not too > hard, why not ? > > (and by the way it's Xfce, not XFCE (nor XFce)) AFAICT, Xfce is mostly popular in audiences that are technical enough to manage to select the packages by themselves ;-) ...But still, I think we should have a Ion3 CD. It could even probably fit on smaller media (i.e. mini-CDs), so it's more important! ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free flash player for your browser
Petter Reinholdtsen dijo [Tue, Sep 26, 2006 at 06:21:24PM +0200]: > > [Gunnar Wolf] > > In my experience, it will even _require_ AMD64 or similar CPUs to > > display even trivial pages. Gnash is still a long way for being > > useful on most machines - it's just too heavy. > > OK. Do you have URLs to test pages showing this behaviour? I use the > test ages listed in > http://wiki.debian.org/DebianEdu/FlashInDebianEdu>, and would > welcome more test pages. :) > > I have not seen this problem myself, but I guess that might be because > I have powerful machines. :) Ugh, I _knew_ I should not have replied ;-) No, I don't have it... I came to that conclusion only because after installing Gnash my (850MHz PIII) laptop suddenly became irresponsive and loud-fanned. I noticed Firefox was the responsable process, then uninstalled Gnash and continued with my business. All in all, I hate animations coming along where I don't explicitly call them, and most web pages have at least one bothering Flash element... I have a habit of opening tens of pages and reading them according to my free time, so tracking which .swf is the culprit is more work than what I'm willing to. I'm sorry... I don't expect to be able to pinpoint the offending pages soon. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Desktop task(sel) in Etch? (Bug #389092)
gregor herrmann dijo [Thu, Sep 28, 2006 at 06:00:06PM +0200]: > > as I would hope that numbers are not moved to random places on keyboards > > Except on french keyboards where they are accessed with Shift- > :-) > > I guess all these ideas are not that really fool-proof ... Sacre bleu... My fingers are bleeding! -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Reasons for keeping Coin3D (libcoin20) at version 1.0.4?
Hi, A project that requested for my help towards packaging their software for Debian has libcoin20 as one of its dependencies. One of the first steps I must take is, of course, make sure the project's dependencies are met in Debian. Coin3D (packaged in Debian as libcoin20) is currently at version 2.4.5 [1], released in April 2006, while in Sid and Etch we still have 1.0.4-5 [2]. The last upload, sent in January [3], basically deals with the xlibs transition. The last upstream version was uploaded in February 2003 [4]. Is there a reason we are still carrying this version? Steve, are you still actively maintaining it (or interested in doing so)? If not, would you oppose handing it over? Greetings, [1] http://www.coin3d.org/news/coin-2.4.5-release [2] http://packages.debian.org/unstable/libs/libcoin20 [3] http://packages.qa.debian.org/c/coin/news/20060113T080214Z.html [4] http://packages.qa.debian.org/c/coin/news/20030215T031724Z.html -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Reasons for keeping Coin3D (libcoin20) at version 1.0.4?
Gunnar Wolf dijo [Thu, Oct 05, 2006 at 03:29:30PM -0500]: > Hi, > (...) GAH! Sorry... Please ignore this mail. I felt I researched thoroughly on coin's status, didn't it? Well, yes, but I didn't pay attention that there are two different source packages: coin (providing Coin3D 1.0 series) and coin2 (providing 2.4.5, the newest upstream release). Bad Gunnar. Bad Gunnar. /me hides. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Bug#397361: ITP: libscgi-rails-ruby -- SimpleCGI protocol implementation for Ruby on Rails
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libscgi-rails-ruby Version : 0.4.3 Upstream Author : Zed Shaw <[EMAIL PROTECTED]> * URL : http://www.zedshaw.com/projects/scgi_rails/ * License : BSD-like Programming Lang: Ruby Description : SimpleCGI protocol implementation for Ruby on Rails SCGI Rails Runner is a complete implementation of the *Simple CGI* protocol for Ruby on Rails as specified by the http://python.ca/nas/scgi/protocol.txt specification. SCGI is similar to FastCGI except that it is much simpler to implement and is actively maintained by the original author. The primary advantages of SCGI over the current FastCGI are: . * Completely pure Ruby yet still quite fast when compared with FastCGI. * The core implementation (SCGI::Processor) is extensible for other frameworks. * Systems other than Rails can use the library to implement their own versions. * An extensive control mechanism to let you start, stop, restart, and reload even remotely. * Cluster management using the scgi_cluster tool. * Configuration file based so you can set options and start from command line easily. * Runs on nearly everything with initial support for Windows. * Restarts and stops are graceful, with redirects to a /busy.html page for clients during the shutdown phase. * You can set a throttle and max connections setting to reduce the load an application puts on your system. . This package is part of the Ruby library extras, a supplement to Ruby's standard library. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399145: ITP: mongrel -- A small fast HTTP library and server that runs Rails, Camping, and Nitro apps
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: mongrel Version : 0.3.13.4 Upstream Author : Zed Shaw <[EMAIL PROTECTED]> * URL : http://mongrel.rubyforge.org/ * License : Same as Ruby (GPL + Artistic-like) Programming Lang: Ruby, C Description : A small fast HTTP library and server that runs Rails, Camping, and Nitro apps Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI. It is framework agnostic and already supports Ruby On Rails, Og+Nitro, and Camping frameworks. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about "Depends: bash"
Dwayne C. Litzenberger dijo [Sat, Nov 25, 2006 at 11:30:40PM -0600]: > On Wed, Nov 22, 2006 at 07:42:14PM +, Oleg Verych wrote: > >Guys. Once more. Spaces is your problem, not my. > > In Unix, every byte except NUL and / (including CR, LF, quotes, and UTF-8 > characters) can be used in a filename, and every string of those bytes > except "." and ".." is a perfectly valid, legal filename. > > Treating some legal filenames differently than others is a bug. Period. Actually, '.' and '..' are completely valid and legal filenames, and quite popular, in fact. Of course, they have a very special meaning, you should not just touch them... But they are as valid as any other. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bonsai: Candidate for removal from the archive?
(If you didn't catch it in the To: line: Check on #391772 for further background) Of the modules you mention: > use Crypt; Provided by the Bonsai package (in /usr/lib/bonsai/Crypt.pm) > use File::Find; Provided by perl-modules, which is build-essential. However, this module is used at installation time (in postinst), so yes, this should be listed as a pre-depends (as it's not a required/essential package) > use Debconf::Client::ConfModule ':all'; Provided by debconf, which is Priority: required > use DBI; Is depended upon by libdbd-mysql-perl, which is both in build-depends-indep and in depends. > Furthermore, it can't be installed without mysql-server, which is in > recommends, and not depends Uhmm... Without looking too deep into Bonsai, I'd not put it as a depends - Bonsai uses DBI + DBD::Mysql to connect to MySQL - The server could be in any machine, not necessarily in the same server. Yes, I hold this even with the reference to #390325 you provide - The Debconf prompt quoted by Steve is right: The (guided?) configuration will fail, but the package will be configurable/usable. > I think all this postinst script is wrong and should be removed and > even the package itself should be removed at least from etch (I > don't know if there are many users, but the popcon says it has been > installed 6 times) > > The maintainer seems not to be very active (other bugs are 5 years old > and tagged "help"), so I think someone else would have to take the > decision to remove it or not. ...I do agree on this, though... I'll close this bug (as all the depended modules _are_ there) and send a copy of this message to debian-devel. Of course, I'm also Cc:ing the maintainer - While he seems to be away (this particular RC bug is almost two months old hand has seen no activity from him), I'm sure his opinion is very much worth it. If Rémi agrees with your opinion, or if he is unreachable and nobody else steps forward to take this package over, I do feel Bonsai is a candidate for removal. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bonsai: Candidate for removal from the archive?
Marc 'HE' Brockschmidt dijo [Sun, Dec 03, 2006 at 11:47:45AM +0100]: > >> use File::Find; > > Provided by perl-modules, which is build-essential. However, this > > module is used at installation time (in postinst), so yes, this should > > be listed as a pre-depends (as it's not a required/essential package) > > Why exactly do you need a pre-depends to use a perl module in postinst? Because: [EMAIL PROTECTED]:/tmp/bonsai-1.3+cvs20060111/debian$ grep use.*File bonsai.postinst use File::Find; The postinst is a Perl file. > >> use Debconf::Client::ConfModule ':all'; > > Provided by debconf, which is Priority: required > > Which doesn't help. You need to depend on all packages you use and can > only leave essential: yes packages out. You are right on this one, it should be added to the depends. Still, I am not familiar with this package - If it provides functionality not provided by other packages, yes, it should at least be marked as belonging to QA and set as Orphaned. We have, however: $ apt-cache search web cvs bonsai - The Mozilla CVS query tool by web interface chora2 - code repository viewing component for horde framework config-manager - manage directories with Arch, CVS, HTTP, FTP and/or Subversion cvstrac - Low-ceremony bug tracker for medium-sized projects under CVS cvsweb - CGI interface to your CVS repository darcs-server - a cgi script for browsing darcs repositories on the web gforge-theme-starterpack - Collaborative development tool - theme package libwww-mediawiki-client-perl - simple CVS-like interface for editing MediaWiki websites python-biopython - Python library for bioinformatics texlive-latex-extra - TeX Live: LaTeX supplementary packages vcsweb - HTTP interface to VCS-controlled repositories viewcvs - view CVS Repositories via HTTP viewcvs-query - view CVS (viewcvs-query.cgi) At least, Chora2, Cvsweb, Vcsweb and Viewcvs look quite similar in purpose. Why should we keep Bonsai? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Bug#401578: ITP: libfilter-template-perl -- Source filter for inline code templates (macros)
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libfilter-template-perl Version : 1.02 Upstream Author : Rocco Caputo <[EMAIL PROTECTED]>, Matt Cashner * URL : http://www.cpan.org/modules/by-module/Filter/ * License : GPL + Artistic Programming Lang: Perl Description : Source filter for inline code templates (macros) Source filter for Perl, allowing to specify inline source code templates. Templates can be much faster than subroutines, but they can mean a much harder debugging, maintenance and use - Read the documentation and choose wisely. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ondemand governor by default in etch
Anthony DeRobertis dijo [Fri, Dec 08, 2006 at 06:31:55PM -0500]: > > * Will cause negligible impact on system performance. ondemand seems > >to have the philosophy of "max system speed unless I can be shown > >that the system is pretty much idle" > > This isn't true on this machine here. Enabling it has the following > effects: > 1) it slows the CPU down to the point where I can watch the title > bars of windows redraw step-by-step when I move the mouse over them > 2) according to the power meter in my UPS, saves approximately 0W > (yes, zero) of electricity. > 3) lets the chip run approximately 0°C cooler. > (...) I must just repeat what you say. Of course, I cannot say how cooler or how much lower on electricity does this run, but my 3GHz P4 also dropped to 375MHz. And it was painful. I hand-adjusted the minimum to 1GHz, but still... I'm unsure whether to leave the ondemand governor active, as it might just never go back to 3GHz on its own. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ondemand governor by default in etch
John Goerzen dijo [Fri, Dec 08, 2006 at 07:20:25PM -0600]:
> > I must just repeat what you say. Of course, I cannot say how cooler or
> > how much lower on electricity does this run, but my 3GHz P4 also
> > dropped to 375MHz. And it was painful.
> >
> > I hand-adjusted the minimum to 1GHz, but still... I'm unsure whether
>
> We can trivially fix that by fixing a minimum to, say, 50% or 30%.
Well, yes, that's what I did after the machine was basically
unbearably slow.
> > to leave the ondemand governor active, as it might just never go back
> > to 3GHz on its own.
>
> Are you seriously having trouble with that? I've seen it spike up
> virtually instantaneously. What kernel version do you have
Yes. In fact, I left it running in 375MHz for almost an hour, just to
be sure it was not my bias. It _was_ slow as hell.
Strange. Now that you mentioned it, I tried to more objectively (sort
of) measure it - I configured the system for the full range. Yes,
375MHz is slow as crap. Redrawing Firefox takes about half a second
(with a very simple page), which is not too much by itself (unless you
work, as I do, under ion3 and every app is full-screened). Switching
~8 times between xterm and Firefox makes it go up to 3GHz. Of course,
a perl -e 'while (1) {}' immediately drives it up to 3GHz. Going down
to 375 is almost instantaneous as well.
...Maybe the problem is that I need a short burst of high speed
operation, and that's where it falls down. But I would not recommend
thinking on using this at 375MHz.
I tried this earlier today under 2.6.16, and am now under 2.6.18.
Greetings,
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is Ryuichi Arafune MIA?
Hi, I just prepared a NMU for toolbar-fancy [1], a package maintained by Ryuichi Arafune. Now, I usually check the QA page for maintainers for which I do NMUs. Now, Ryuichi's QA page [2] shows he has been quite inactive in the project - His latest upload AFAICT was in 2006-03-30 for imagemagick [3]. This package is quite popular (popcon 9174), and has seen 13 NMUs since. It seems Ryuichi is MIA. Possibly this is not the best way to check for activity or to ask QA to take over his packages (QA, is it?). Anyway, Ryuichi: Are you reading this? What's your status regarding Debian? Do you plan to go back to activity, or should your packages be taken over by someone else? Thank you very much, [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=403935 [2] http://qa.debian.org/[EMAIL PROTECTED] [3] http://packages.qa.debian.org/l/lookup-el.html [4] http://packages.qa.debian.org/i/imagemagick.html -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Two questions on package quality
Nikita V. Youshchenko dijo [Sun, Dec 17, 2006 at 09:48:02AM +0300]: > Hello people. > > I was asked to sponsor a package upload. > I am in doubt on tho following issues, so I/m asking debian-devel for > comments. > > > 1. Upstream does not provide a manual page for the binary. Packager decided > to add binary-without-manpage to lintian override file, and Tag: > no-manual-for-binary to linda override file. > > My questions are: > > - Is having a manual page for each binary inside package a mandatory > requirement these days? It's not mandatory, but strongly prefered. Think about this: How complex is this binary's user interface? Is it easy enough so that a user can understand its working without a manpage? Great, then writing a manpage should prove trivial. Is it so complicated that writing a manpage is too much work? Well, then how do you expect your users to understand and use it? :) > 2. Upstream tarball contains ttf-dejavu font. Linda found that and > complained. I've asked packager to remove font both from binary package > and upstream tarball, and to make binary package to depend on ttf-dejavu > instead. > > So .orig.tar.gz got repackaged, and now it differs from upstream. > > Should then 'upstream' version string be changed from x.y.z to > x.y.z.debian? Or not? Or it does not matter? Yes, it should be changed. Not because of the policy, but for clearness. Of course, document prominently that you are not building from upstream sources. And, if possible, add a check in debian/rules so you (or someone else) don't forget to repackage the orig.tar.gz for the next upstream version. Make the build fail if it has ttf-dejavu. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Two questions on package quality
Russ Allbery dijo [Sun, Dec 17, 2006 at 11:20:37AM -0800]: > > 2. Upstream tarball contains ttf-dejavu font. Linda found that and > > complained. > > Why? > > Sure, duplication of code is a bit annoying, but ttf-dejavu appears to be > a free font, so it doesn't hurt anything that the upstream tarball > contains it. The installed *package* shouldn't duplicate the font and > should instead just depend on the font package it needs (or possibly not > even depend -- if it's only accessing the font via X, it should only > recommend and allow for the possibility that there's an X font server > providing the font). But there's no harm that I can see in leaving the > font in the upstream tarball unless it's under some other non-DFSG-free > license, and you want to avoid repackaging the upstream tarball when you > can help it. Oh! I have to agree with Russ: If the font is free, then just delete it from the target directory after building. Ship pristine sources. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
Steve McIntyre dijo [Fri, Dec 22, 2006 at 03:04:54PM +]: > Bad news I'm afraid. I've worked through the mkisofs boot code again, > and I get: > (...) > I'm looking further to see if it's at all possible to get (e.g.) hppa > and alpha to live in the same boot sector, but it's really not likely. I might be stating the obvious, but the OpenBSD team (and I understand it's Theo specifically who was responsable for this) spent a nontrivial amount of time working how to make their CDs bootable in every possible platform, with usually 3-4 architectures per CD. Maybe (knowing their community is (even) more hostile than ours) it's not an option to ask them for information on how they managed to do this, but you could study a bit their ISO's layout. Their ISOs are not freely redistributable, but if you are interested, I can snail-mail you some older releases (~4 year old, IIRC) I have around here. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: ITP: nspeed -- Prints the currently incoming and outgoing traffic in kb/s of a NIC on the console, no more, no less
André Appel dijo [Sat, Dec 23, 2006 at 07:16:54PM +0100]: > Package: wnpp > Severity: wishlist > Owner: Andre Appel <[EMAIL PROTECTED]> > > > * Package name: nspeed > Version : 1.0.0 > Upstream Author : Andre Appel <[EMAIL PROTECTED]> > * URL : http://nforcer.de/debian/nspeed/ > * License : (GPL) > Programming Lang: (bash) > Description : Prints the currently incoming and outgoing traffic in > kb/s of a NIC to the console > > > nseepd is a shell script which prints the kb/s which are currently > beeing received and transmitted by a NIC in a direct way only using > simple shell commands. No superuser rights required. All other tools I > found displayed continuous the incoming / outgoing rate or many other > thins. All I needed was a short information of how much is going in and > out at the moment, displayed once. What does "current" mean? How long does taking a "sample" take? Can you adjust it? Maybe this is not as important for the description, but should be mentioned in the package :) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Request for removal of libconfhelper-perl
Subject: ftp.debian.org: Request for removal of libconfhelper-perl Package: ftp.debian.org Severity: normal Hi, I'm looking at orphaned Perl packages, adopting some or trying to find which should be dropped instead. I found libconfhelper-perl to be surprisingly popular (1548 on popcon), but it's a package on which no other package depends, has been orphaned since February 2004 (#233666), and has not seen an upload since then. Yes, I know that "if it's not broken, don't fix it" - But it looks like begging for trouble (it provides a way of "chunking" a configuration file, reserving some areas of it to be modified by the user, and some of them to be modified by programs). I even think its incorrect use could mean a policy violation here and there. And I guess it has a high number of installations because of people that had it long time ago (from the Woody or earlier days). So, please comment if this package is worth keeping... Or remove it otherwise :) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Request for removal of libconfhelper-perl
Gunnar Wolf dijo [Thu, Dec 28, 2006 at 12:20:13PM -0600]: > (...) > So, please comment if this package is worth keeping... Or remove it > otherwise :) Ok, so adn pointed out on IRC to me that this package is depended on by mplayer - I didn't find it, as I forgot I'm tracking Marillat's multimedia repository on this machine. Still, I do think we should drop this package. If the mplayer agree, I'd be more inclined to help them stop depending on this code and be able to get rid of it - I think it's prone to creating troubles, it's quite fragile. At the very least, I'd like somebody to step up and adopt it :) I'm (not) Cc:ing the bug, as it has not yet been assigned a number. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
More orphaned Perl packages to be removed from the archive
Hi, I just filed bug #404896 - I'm copying it here as I hope you have some comments regarding it: The following Perl modules have been orphaned (or have not been updated) for a long time, have no reverse dependencies, and have quite low installation count according to popcon: libbusiness-ups-perl (O: #279777 nov 2004; last non-QA upload Mar 2002) Popcon: 18 Rdepends: 0 libnewt-perl (O: #279798 nov 2004; last non-QA upload Jul 2003) Popcon: 37 Rdepends:0 libcorba-orbit-perl (O:#279781 Nov 2004; last non-QA upload Aug 2002) Popcon: 50 Rdepends: 0 libtangram-perl (O: #279804 Nov 2004; last non-QA upload Sep 2002) Popcon: 27 Rdepends: 0 libapache-authznetldap-perl (O: #312835 jun 2005, last non-QA upload Mar 2004) Popcon: 38 Rdepends: 0 libclass-prototyped-perl (O: #317262 Jul 2005; last non-QA upload Mar 2005) Popcon: 24 Rdepends: 0 libapache-miniwiki-perl (O: #400362; last non-QA upload Dec 2003) Popcon: 25 Rdepends: 0 libextutils-f77-perl (O: #317400 Jul 2005; last non-QA upload Jun 2004) Popcon: 39 Rdepends: 0 libnet-ftpserver-perl (O: #357085 Mar 2006; last non-QA upload Feb 2004) Popcon: 38 Rdepends: 0 libdb-file-lock-perl (O: #357344 Mar 2006; last non-QA (and only) upload Sep 2004) Popcon: 57 Rdepends: 1 libpod-pom-perl (O: #379983 Jul 2006; last non-QA upload Jul 2005) Popcon: 45 Rdepends: 0 libclass-contract-perl (O: #399254 Nov 2006; last non-QA upload Mar 2003) Popcon: 26 Rdepends: 0 -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Etch Software RAID Upgrade Trouble & Suggested Installer Improvements
Russell Coker dijo [Mon, Jan 08, 2007 at 10:07:12AM +1100]: > > Other than the partition type, there's no way to do this, and > > setting the partition type is not always desirable. > > It's not always possible on other architectures. What do you do on a > platform > that supports the BSD disk label and has no type number? > > Are there any platforms other than i386, AMD64, and IA64 that support the > partition type number? Well, remember the disk with a strange partition does not need to be the boot disk. Even more if using the installer disk as rescue media, I really appreciate the ability of plugging some spare disks in a well supported system and being able to recover a dead system. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Best scheme for teams and Maintainer/Uploaders fields ?
Pierre Habouzit dijo [Mon, Jan 08, 2007 at 11:58:49AM +0100]: > > Uh? Why? Your maintainer field seems to address this issue. In our > > scheme that's would be more a problem, but if the mailing list is > > responsive it's enough. Think for example at the debian-release mailing > > list: it's a list, but it's really responsive for all packages in the > > archive. So IMO not being able to identify a single person is not > > necessarily an indicator of unresponsiveness for a given package. > > What he means is that when people are listed automatically as > Maitnainer/Uploader, the fact that the package is well maintained may > hide that a particular DD do nothing at all, and is in fact MIA. > > Last-action of a DD is computed using many ways, uploads of package > where he is in Maintainer/Uploader beeing among them, and it hides real > MIAs from the mia tracking scripts, and that's bad, because it prevent > good QA work, and generate more and more bitrot. Umh... Then, I think the MIA-calculation ways are the broken ones, not the team maintainership options. Developer activity should be done checking either who signed the package, or at the very least, who's name is reported on each of the changelog's entries - But basing it on the Uploaders field is just asking for trouble. Team maintainership is just a way to make MIA people hurt Debian _less_, not more! :) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Release Date Update
Tollef Fog Heen dijo [Fri, Mar 24, 2006 at 01:47:57PM +0100]: > | The premise is also weak. Man, in the summer, I want to be > | out. Day trips. Picnics. Sports. County fairs. Winter is when one > | hunkers down in the warmth of the house and codes. > > But in the winter you can go skiing! In the summer, there's no snow, > but nice and cool in the basement without having to worry about the > heat or the icky yellow thing on the sky. Man, on which world do you live? In the winter there is no snow either - But in the Summer we have rain, which makes you stay indoors in the evenings. Lets better hurry, freeze now, release by June, and go looney during Summertime! Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Wrong comparisons [was: etch before vista]
A Mennucc dijo [Fri, Mar 24, 2006 at 07:41:39PM +0100]: > hi everybody > > According to the latest [1] Microsoft announcement, Vista will be released > in Jan 2007; according to our schedule [2], Etch may be released in Dec 2006. > > If we accomplish it, it will be a great feat: Debian will (possibly) > show it is able to relase two versions of its distribution since Jul > 2002 (= woody release); whereas Microsoft seems unable to release its > own O.S. (even though XP has been out since Dec 2001, if I recall > correctly). > > Yes guys, it means > (...pseudo-stats...) > Amazing. Hi, Free and propietary software development are two beasts so far apart and so different in means, in scope and almost in every conceivable sense that I have to answer to your mail ;-) Don't try to compare "us" and "them". Don't try to turn it into a race. What if we win? What if we lose? Is OpenBSD better because it releases more often and they write all of the code (to their base system)? Are we worse because we take so damn long to release a new stable version, even if we just fix the bugs and package the software but don't always write it ourselves? Then Apple should die quite soon, as MacOS X has not seen a major update since it was born, over six years ago (it was 2000, right?) Different software development projects, different developer communities and different operating systems as a whole cater to different needs. Sometimes we can -carefully- measure certain aspects against each other, but if we want to be fair, if we don't want to be judged as FUD-machines, we should avoid hollow comparisons as this one. Some time ago, I defended Debian's long release cycle by pointing out the average user does not like to change - After all, Windows 98 is still too common everywhere (and I could still say so today, as about half of my Institute's PCs run Win98)... But I would not claim the same today. Once again, Windows and Debian are both operating systems, have both their advantages and disadvantages, but have clearly different intentions. How can we then measure up against Evil Propietary Software? Well, start by believing we are morally superior (which I do believe). Look at the sheer amount of code, and the average quality of two similar pieces of software. Yes, sometimes we will win, sometimes we will lose, but Free Software is maturing and becoming attractive every day for more people. Oh! And the best thing: If you want Debian(/Linux/*BSD/whatever) to beat Windows(/MacOS/HPUX/whatever), there is something very easy you can do: Code, document, report, fix, translate, meet, facilitate. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
