Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 10:04:00AM -0800, Russ Allbery wrote: In a sense, of course, this is true. However, what I'm trying to point out is that we have a fundamental governance question facing us here. What are we, as a project, going to do when we face a decision where the project is strongly divided and all sides consider the opposing decision to be a disaster? What ever happened to letting the system evolve naturally? Rather than force change on the users, let the quality and utility of the software the user *wants* to run manage the timetable to change the foundational elements of the system. Change from the status quo should be done when there is a compelling reason to do so - and then with great care and consideration of the consequences. Yes, this approach leads to painfully slow transitions sometimes. If you are really concerned about the speed of change implementation, you probably shouldn't be working on an open-source collaborative project founded on the bazaar model. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113185852.gc16...@flying-gecko.net
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 11:24:31AM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: On Thu, Nov 13, 2014 at 10:04:00AM -0800, Russ Allbery wrote: In a sense, of course, this is true. However, what I'm trying to point out is that we have a fundamental governance question facing us here. What are we, as a project, going to do when we face a decision where the project is strongly divided and all sides consider the opposing decision to be a disaster? What ever happened to letting the system evolve naturally? Rather than force change on the users, let the quality and utility of the software the user *wants* to run manage the timetable to change the foundational elements of the system. This sounds great on the surface, but the general principle is hard to apply to the current situation for a couple of reasons. First, several of our upstreams have, from their perspective, already gone through this natural evolution process and have landed on a new set of software, which they are now requiring as a prerequisite. This is, in one sense, a normal thing for upstreams to do. It happens all the time with new shared libraries or new ABIs of existing shared libraries. However, this time, it's rather unusual, since it's unusually hard (although not completely impossible) to provide both the old and new mechanisms at the same time. It's not unheard of, though; we have retired old stacks before even though some users wanted to use them because they weren't supported upstream. I'm remembering the last GNOME and KDE major release transitions, for instance. (And, in the GNOME case, a team stepped up to maintain a fork, and as a result the previous version is being reintroduced in the archive under a different name.) Again, you can have many different opinions about these decisions, and I know people do, but the fact remains that the people who are making those decisions are independent citizens of the free software community with the right to make their own decisions. We don't get to tell them what to do; it would be extremely rude of us to do so, not to mention completely ineffective as we are not their bosses or owners. The alternative is what it always is in free software: if you don't like a project direction and can't convince the current maintainers that you're right, you either have to put up enough resources to maintain a fork or live with it. We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. The current systemd / GR issue would not be happening if the project had not said the default init system shall be init system. Had the project said we have the following init systems available: list of init systems and let the other package dependencies drive the user's selection then users would fell there was a little more choice in the matter. Right now, GNOME seems to be the primary driver for requiring systemd. If you don't use a graphical environment, you don't need systemd but you are forced to at least install it on a new build. Second, our users are just as split as the developers are. Some users have already gone through the process you describe and are eager for the new software. Others are pretty leery or even actively opposed. If we can maintain both in parallel, this is not a problem, but it seems like everyone is dubious about the project's ability to maintain both, so one side is arguing for investing our time into supporting sysvinit rather than systemd, and the other side is arguing for investing our time into supporting systemd instead of sysvinit, both making essentially zero-sum tradeoff assumptions. If there are two opposing sides, then there are two maintainers willing to maintain the packages. If there are not, the package without a maintainer looses by default. I don't recall Debian every saying we will support package package forever and ever. So, again, we return to the governance question. We're at loggerheads no matter how you cut it, including the way that you're trying to cut it. Do we wait for unanimity? Is that the right default decision? Waiting implies lack of movement - this is not what I was saying. I say allow the natural evolution to play out. GNOME wants to require systemd and someone packages systemd - great - allow it AS AN OPTION, NOT A REQUIREMENT for all. Similarly with sysvinit - it has maintainers, allow it as an option. The issue we should be tackling is not which init system to force on the users, but the higher level what is the minimum functionality and API a Debian init system MUST provide to allow it to declare Provides: init-system in its control file. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 01:39:52PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: We do tell users of Debian what to do - that's part of the problem right now. We told the users they will switch init systems, and a large portion (or at least a vocal portion) don't want to. Well, no, we didn't. We said that there would be a different default, which is not the same thing. The project hasn't made a decision about switching, and also, at present, sysvinit is still fully supported (modulo the normal pre-release bugs). By making it the new default, and causing apt-get dist-upgrade to install systemd (which is what happened to one of my systems) in place of sysvinit we most certainly are. Did the system implode in a fiery pool - no, but I was forced to deal with the unexpected aftermath. There was some breakage, and some things did not work as expected. (Sure, people would say I shouldn't be following unstable or SID but then I wouldn't have development environments.) By not having a meta-package init-system provided by an actual package, we are forcing anyone who upgrades to also change init systems unless they take special precautions to not do so. For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113215610.gg16...@flying-gecko.net
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote: For the record, I really don't care about the init system per-say. I am more annoyed with the systemd insistence on logging to binary files than anything. Log files should be plain text. Rsyslog is srill installed by default (and I guess that won't change soon), so you now have even better textlogs. The binary logs are great for quick searching (just run systemctl status on a service) and provide some extra benefits for working with logs (I, for example, love the ability to group entries by priority), but that's not something someone is forced to work with. Matthias, I did not ask for evangelization about how wonderful binary logs are, nor for a lesson on how to get the info out of systemd with the systemctl command. I am glad you like them and they work for you. For me they add another level of obfuscation, a speed bump and a potential point of failure. All of which are unnecessary. Cat logfile, more logfile less logfile, grep term logfile -- all worked well and continue to do so for my text file logs. Awk, emacs, vi, all work on them too. My log management tools all expect my old plain text formatted logs. If we can agree to disagree on this all is well. If you feel it necessary to convert me or help me see the light then, well, we're going to have a problem ;-) Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113222533.gi16...@flying-gecko.net
Re: Being part of a community and behaving
On Fri, Nov 14, 2014 at 12:05:17AM +, Sam Hartman wrote: I'm confused. Are you saying that cat logfile isn't working for you with systemd on jessie? I'm honestly asking for information here. As best I can tell on my system everything that gets logged gets logged to text log files. Some of it also gets logged to the journal. Sam, I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. (Obvoiusly if a program manages its own logging, those are not affected by the change.) If the journal file is not supposed to be in a binary format, then my system didn't get that configuration update Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114013921.ga10...@flying-gecko.net
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 06:07:33PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: I'm saying those things that logged to syslog now log to the journal, so cat /var/log/syslog doesn't work because the output that used to go there is redirected to the binary format journal file. If that's happening on your system, that's a bug. It's definitely not happening on mine. Could you provide more information, such as an example that's not in /var/log/syslog where you expect it but ended up in the journal, and what program is involved? Since /var/log/syslog is empty, clearly there was an issue when my system upgraded. I'll have to look into this to see what is going on. (Kind of illustrates my point about another point of failure... No, I did not plan or do this intentionally) Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114021510.ga12...@flying-gecko.net
systemd / syslog issue (was Re: Being part of a community and behaving)
On Thu, Nov 13, 2014 at 06:53:09PM -0800, Russ Allbery wrote: Maybe some failure to sync status correctly? syslog-ng does ship with a service file. What does: systemctl status syslog-ng say? Particularly the Loaded and Active fields should have some hint as to what's going on that's preventing the service from starting automatically. ● syslog-ng.service - System Logger Daemon Loaded: loaded (/etc/systemd/system/syslog-ng.service; disabled) Active: active (running) since Thu 2014-11-13 21:36:20 EST; 18min ago Docs: man:syslog-ng(8) Main PID: 13370 (syslog-ng) CGroup: /system.slice/syslog-ng.service └─13370 /usr/sbin/syslog-ng -F So it claims the syslog-ng service is disabled. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114030316.gc12...@flying-gecko.net
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote: Patrick Ouellette poue...@debian.org writes: Since /var/log/syslog is empty, clearly there was an issue when my system upgraded. I'll have to look into this to see what is going on. (Kind of illustrates my point about another point of failure... No, I did not plan or do this intentionally) Ow. No, that's definitely a bug. I'd love to understand what happened there, as that sounds like a pretty serious one. That is not expected behavior. OK, so the system has syslog-ng installed. For what ever reason syslog-ng is not starting automatically, but starts manually by systemctl. syslog-ng version 3.5.6-2 systemd version 215-5+b1 Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141114024043.gb12...@flying-gecko.net
Accepted ax25-apps 0.0.8-rc2+cvs20130510-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 11 May 2013 11:53:32 -0400 Source: ax25-apps Binary: ax25-apps Architecture: source i386 Version: 0.0.8-rc2+cvs20130510-2 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-apps - AX.25 ham radio applications Changes: ax25-apps (0.0.8-rc2+cvs20130510-2) unstable; urgency=low . * Fix build failure on buildd (autoreconf call) Checksums-Sha1: 59fdeb60d4ae51cf1f45e16a981e0ee0a4afbf7d 1380 ax25-apps_0.0.8-rc2+cvs20130510-2.dsc cf4944b6afa0406766cc88ea76714da2b6f2844c 340610 ax25-apps_0.0.8-rc2+cvs20130510-2.diff.gz e8b68e2ad0a34feae3593f33e116c6e00d8bd9d6 125872 ax25-apps_0.0.8-rc2+cvs20130510-2_i386.deb Checksums-Sha256: b95d9eeb34f5a6515ee28f17b7c30eb49f90f1ad767b6a719461313239256ecd 1380 ax25-apps_0.0.8-rc2+cvs20130510-2.dsc 019eed852aa140baf61d052571b6a0ad4da731c62266c55d3bebd37c31e2e8b3 340610 ax25-apps_0.0.8-rc2+cvs20130510-2.diff.gz 14794e737e67f18ffee1a1bce07f736dfe827b82ec54b42a0690a956c8ca816e 125872 ax25-apps_0.0.8-rc2+cvs20130510-2_i386.deb Files: 14b8005770cf09f44ec834307dcd31f7 1380 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-2.dsc ec851e3266b93a40f3eac035032b30b6 340610 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-2.diff.gz 02565ffe02cca203ed7d9fd2b94de5a1 125872 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGOafkACgkQz9qdgganN26jTQCgvmmNwpBVfL5sbrOrWSRUod6f eTAAoJLorquMKwIIynGwzKKpGSC9QEKD =EbQz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ubcux-0001rd...@franck.debian.org
Accepted ax25-apps 0.0.8-rc2+cvs20130510-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 11 May 2013 12:26:12 -0400 Source: ax25-apps Binary: ax25-apps Architecture: source i386 Version: 0.0.8-rc2+cvs20130510-3 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-apps - AX.25 ham radio applications Changes: ax25-apps (0.0.8-rc2+cvs20130510-3) unstable; urgency=low . * Move to dh_autoreconf * Add build depends for autotools Checksums-Sha1: d59f195acec3207af7e1a9e01b8de4015fb55432 1432 ax25-apps_0.0.8-rc2+cvs20130510-3.dsc 9197416013ba02547e420e897ca732f9877dfad9 12756 ax25-apps_0.0.8-rc2+cvs20130510-3.diff.gz 56cda89e26d3f859a17ea181d8f64727b286e5c7 125902 ax25-apps_0.0.8-rc2+cvs20130510-3_i386.deb Checksums-Sha256: dafe5cfe831456e87ae11ecd33bc3c3ec5a9daa3f4a42a152c5aa72152d9865e 1432 ax25-apps_0.0.8-rc2+cvs20130510-3.dsc 6a15966b070abb132b0b05d596ee911d989b00bbc558ef2edda8aa1b0452e51a 12756 ax25-apps_0.0.8-rc2+cvs20130510-3.diff.gz 62121599ac53791dd87d86334d0b0f57a95bdfbc55d17b9378e2dcd0383030ca 125902 ax25-apps_0.0.8-rc2+cvs20130510-3_i386.deb Files: 9429e7b8ff78f0d20701e5a93ab3b489 1432 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-3.dsc 3bc0a7c388bea5ef612993df6d094770 12756 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-3.diff.gz 78a9d4a4be459d55de73ff02dd22f837 125902 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGOeB8ACgkQz9qdgganN27hqwCffG1TeLmueMhWBojM7MSTxM4d KfIAoLEI0ixU1Snt0aqcyxR/acw2tiKP =Tjeh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ubdqz-0007aw...@franck.debian.org
Accepted ax25-apps 0.0.8-rc2+cvs20130510-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: FrI, 10 May 2013 11:13:29 -0400 Source: ax25-apps Binary: ax25-apps Architecture: source i386 Version: 0.0.8-rc2+cvs20130510-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-apps - AX.25 ham radio applications Closes: 630893 Changes: ax25-apps (0.0.8-rc2+cvs20130510-1) unstable; urgency=low . * License changed to BSD license for listen/ripdump.c (Closes: #630893) * Updated standards version to 3.9.4 * Added use of hardening flags to debian/rules for compilation Checksums-Sha1: 6138747d43a803e24cc89b9f9a28c0319980af49 1380 ax25-apps_0.0.8-rc2+cvs20130510-1.dsc 14dc88feef157c896bb997f9338a1fa23df1faea 140072 ax25-apps_0.0.8-rc2+cvs20130510.orig.tar.gz 08edf73be8f830b5e3f8f1f0dd9e402cfc7e7ff5 340578 ax25-apps_0.0.8-rc2+cvs20130510-1.diff.gz 1da7ca7d00ee75e2a0a3a5c67ee093bf7bddb97c 125836 ax25-apps_0.0.8-rc2+cvs20130510-1_i386.deb Checksums-Sha256: 702f2915c755be51fd8139a71cc7739dd251172cace35b0210719af0c17dd9c6 1380 ax25-apps_0.0.8-rc2+cvs20130510-1.dsc a65808a132c6b499d9c37817aaab8b979442dde4950b74a41186ac8d02e13738 140072 ax25-apps_0.0.8-rc2+cvs20130510.orig.tar.gz 2335a2b3e2765400ec6e73535164d4de252d34d1d544b238e9672c2f3b8fdef6 340578 ax25-apps_0.0.8-rc2+cvs20130510-1.diff.gz 786357eb68cff14e39bfa497135b32019ff5095ab711b71a0554b94128bff213 125836 ax25-apps_0.0.8-rc2+cvs20130510-1_i386.deb Files: 02efd225cb5b85985f62f671731dbd77 1380 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-1.dsc 03be77c56a35d70bbfbd25ab4f6b04c7 140072 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510.orig.tar.gz b33a6fae72bae1cfdcef9212251ed4b6 340578 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-1.diff.gz 9f1443a0fbca59299c6294c1f84c80af 125836 hamradio extra ax25-apps_0.0.8-rc2+cvs20130510-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGNKd8ACgkQz9qdgganN24GQQCgvA9O0NgI5+M3LlSUYsyWYi7r 1l4AoMs/01upWwX7aicKgdWC2P9eu5+j =4NvL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uarbo-0007f4...@franck.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thu, Oct 25, 2012 at 09:51:16AM +0200, Thibaut Paumard wrote: So yes, I say long silence from the entire community *including the package maintainer(s)* probably means it's safer to orphan the package than not. I would probably send a few pings during the one month period though. I would also be careful during vacation periods, especially if the maintainer is not a DD and therefore can not easily announce VAC. Can you define in absolute terms what are the vacation periods that apply to anyone/everyone of all cultures and religious backgrounds in the world in a way that is acceptable to everyone? A long silence is defined as how many hours/days/weeks/months/years? All the pings in the world won't help if you are sending them via a path that discards them. I know several large US ISPs that automatically reject what they consider SPAM without the customer's knowledge. If the sender of the ping is on a SPAM list for one of them, the ping will never get to the maintainer, and *no one* will know. (From personal experience I can tell you mail from the Debian list addresses does get caught in these SPAM filters and no, the ISPs won't change the policy.) Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121025174752.gb19...@flying-gecko.net
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Tue, May 08, 2012 at 12:41:40PM +1000, Ben Finney wrote: David Weinehall t...@debian.org writes: Wasn't the main reason (apart from the seniority argument) for preserving the node name for ax25 to prevent remote unmonitored highly important systems from failing? If such systems are highly important, should we accomodate them remaining unmonitored? Surely if they are unmonitored, then they are not considered sufficiently important to monitor. So “highly important” ceases to carry any weight in such cases. No? The systems are not unmonitored they are physically difficult to access. One of the tools used to monitor them is connecting to them with the node application. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120508160953.gb28...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 09:08:23AM -0700, Russ Allbery wrote: Thomas Goirand z...@debian.org writes: On 05/02/2012 06:00 AM, Russ Allbery wrote: and the binary isn't invoked directly by users If the binary isn't invoked directly by the users, why do we have a problem? Why can't a patch be introduced so that the binary doesn't live in a user accessible path (eg: not in /usr/bin)? That's also an option, but the amount of work required to do the transition is basically the same either way, and in Debian usually programs meant to be invoked by inetd are kept in /usr/sbin. The ham radio node command IS already in /usr/sbin This does not stop people from writing scripts that invoke it, nor stop them from invoking it on the command line. Node.js' node IS already in /usr/bin Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503171543.gf19...@flying-gecko.net
Re: Node.js and it's future in debian
On Tue, May 01, 2012 at 03:00:46PM -0700, Russ Allbery wrote: That community is much smaller, and the binary isn't invoked directly by users, which makes the impact fairly minimal in practice. Can you support that assertion with data? I'm not talking installed instances in Debian, but in the overall world community? How many people use Node.js? I had never heard of it until this came up, and I work in IT with web development teams. I can find numbers of potential node users by examining the number of active amateur radio licenses and make educated guesses as to how many may be using the ham radio node software as either a user of the system or a system provider/administrator. FWIW, the bug log from Node.js when they examined the Debian installations of each found them to be a similar number as reported by popcorn. (N.B. I don't put much stock in popcorn's numbers because it can be opted out of) Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503172254.gg19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 01:10:24PM +0200, Vincent Bernat wrote: As said many times, node is an interpreter used in shebang. Using a different name would just upset its user base. Debian will be seen, again, as the one harming a community, like this may happen in the Ruby community because of lack of understanding on how we work. Outside of Debian, nobody will understand why a package related to HAM radio hinders the use of one of the trendiest package (in the top 5 of most watched and forked repository in GitHub). So every time something is the hot new trend it has the right to usurp an established package's binary namespace? I'm not asking this to be argumentative, I really want to know if this is your intention. I'm not saying there is a perpetual right to a name either, but when a package has active users, has been in the distribution a long time, and still does what it is designed to do there should be some significant consideration given to protecting that package's name space. We are building a distribution for users. There are far more users of node.js than there is for node. Plus the fact that the proposed change will be absolutely invisible to most users of the node package. The ham radio community is also our users. In fact, one of Debian's early focus areas was amateur radio software (see Bruce Perens' history in Debian - he wanted to have a distribution that included the ham radio software and tools). Are you a ham radio user of node? You can not make assertions that the change will be absolutely invisible to most users if you have zero experience with the community that uses the package. The fact is it will break machines that have been in service for possibly as long as 13 years. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503173516.gh19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 02:35:06PM -0300, Fernando Lemos wrote: So while I don't think decisions shouldn't be taken based solely on popcon stats, I think it would be silly to think that ham radio would be more popular than node.js. I understand you're reluctant to undergo this transition and I empathize, but this argument is really a long shot. There are several issues, apparently none of which apply including but not limited to : length of time a package has been in Debian the fact the package is still viable and in use by a not insignificant number of people the fact that the Node.js maintainers previously asked the node maintainer to change the package name and he refused the fact the Node.js maintainers knowing policy violations would happen willfully released their package to Debian with the policy violations apparently to force just this situation and usurp the namespace (or at the very least in an attempt to circumvent policy) Please understand, it is not a reluctance to undergo this transition. I am being asked to make Debian incompatible with the previous 13 years of functionality, and cause a significant impact on a user community. This is not something that should be done lightly or without considerable thought and preparation. The first part of that process is convincing me and the ham community (e.g. upstream) that the necessity of the change is real, and the benefits outweigh the costs. One of the considerable costs involves the number of systems in place in the ham community that are not easily physically accessible should the upgrade/change break the system. These systems may be on mountain tops, high buildings, or other high structures with significant challenges to accessing the locations. These systems may be (usually are) part of emergency communications plans and are relied on to help in the event of a disaster. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503182633.gi19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 08:48:07PM +0200, Vincent Bernat wrote: OoO Pendant le repas du jeudi 03 mai 2012, vers 19:35, Patrick Ouellette poue...@debian.org disait : As said many times, node is an interpreter used in shebang. Using a different name would just upset its user base. Debian will be seen, again, as the one harming a community, like this may happen in the Ruby community because of lack of understanding on how we work. Outside of Debian, nobody will understand why a package related to HAM radio hinders the use of one of the trendiest package (in the top 5 of most watched and forked repository in GitHub). So every time something is the hot new trend it has the right to usurp an established package's binary namespace? I'm not asking this to be argumentative, I really want to know if this is your intention. Not the right but this is a strong criteria to hijack a binary name. The second strong criteria is the absolute necessity for node.js executable to be named node since it is used as a shebang. OK, so in your mind the hot new item (that maybe unused in a couple of years when the next new thing comes along) has a strong argument to hijack a binary name simply because it is hot at the time. Certainly you are entitled to your opinion. We'll have to agree to disagree on this particular criteria. I still don't get the importance of the shebang argument. Scripts are text files, like conf files and can be modified. While definitely not an ideal situation, replacing the shebang line can be pretty easily scripted. It is the very first line of the script. (yes, constantly having to run the script for *every* new script downloaded from the prolific websphere can be a burden) Changing conf files always requires manual intervention to preserve any local changes. We are building a distribution for users. There are far more users of node.js than there is for node. Plus the fact that the proposed change will be absolutely invisible to most users of the node package. The ham radio community is also our users. In fact, one of Debian's early focus areas was amateur radio software (see Bruce Perens' history in Debian - he wanted to have a distribution that included the ham radio software and tools). Yes, they are. But we need to find a solution that will work for almost every one and this solution seems to exist. Can you please elaborate on the solution that seems to exist? All I have seen is a demand from Node.js to give up the name ASAP. Are you a ham radio user of node? You can not make assertions that the change will be absolutely invisible to most users if you have zero experience with the community that uses the package. The fact is it will break machines that have been in service for possibly as long as 13 years. I am not a ham radio user at all. I base my writings on what has been said by others (who may not be ham radio users either): node is meant to be called through inetd which is configured by a conffile that can be updated. This is a pity to do the change but it seems to be invisible to most users and easy for the almost the rest of them (they will be prompted for the configuration change if they have modified the configuration file of inetd in the past). This is from the linux-hams list where I asked about changing the name of node: From my experience, many MANY Linux hams have customized scripts that startup some very elaborate HAM systems. For many, these scripts weren't written by them and the changing of the node command could be very difficult for some. The other aspect is if this change came into a package update that could impact production systems in VERY remote sites. This could cause all kinds ugliness that can be easily avoided. Thanks, Pat -- ,-. Patrick Ouellette | While you are proclaiming peace with your lips, pat(at)flying-gecko.net | be careful to have it even more fully in your Amateur Radio: NE4PO| heart. -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503191159.gk19...@flying-gecko.net
Re: Node.js and it's future in debian
Can someone please explain to be why it is so unpalatable to have the Node.js package in the README and in an installation/ configuration message include the following (or similar) message: Node.js in Debian has the executable name /usr/bin/nodejs This is to solve a conflict with a package that still exists in Debian from a time before Node.js. If you are not going to use the other package, and wish to maintain compatibility with the upstream Node.js documentation, tutorials, scripts, etc. please run the following command as an administrator: ln -s /usr/bin/nodejs /usr/bin/node Thanks, Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503183849.gj19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 09:24:00PM +0200, Raphael Hertzog wrote: So to avoid disruptions, you rename the binary in the package and in the postinst configure old-version which is run during upgrade, you add a symlink from /usr/sbin/node to ax25-node and you display a prominent warning explaining that the binary name has changed but that you left a (non-packaged) symlink in the mean time. For new installs, as opposed to upgrades, you obviously don't install the compatibility symlink. I really don't understand what's so complicated about all this. With a clear note in README.Debian and NEWS.Debian, ham radio users will not suffer. With all due respect, you can make the same argument for the Node.js package to do this. Node.js is not currently in the stable distribution while node is (apparently this does not have any bearing on the discussion). Until a solution is implemented and tested in a variety of cases I would not claim the user will not suffer. You also don't address the issue of a user who installs both packages and now gets varying behavior depending on their $PATH - a result not of a local administrator's action, but of the Debian package's actions. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503194414.gm19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 10:11:41PM +0200, Raphael Hertzog wrote: You also don't address the issue of a user who installs both packages and now gets varying behavior depending on their $PATH - a result not of a local administrator's action, but of the Debian package's actions. If node gets renamed to ax25-node, the conflict will disappear, no? Not if your backwards compatibility symlink is there. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503202046.gn19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 09:21:16PM +0100, Colin Tuckley wrote: Date: Thu, 03 May 2012 21:21:16 +0100 From: Colin Tuckley col...@debian.org Subject: Re: Node.js and it's future in debian To: debian-devel@lists.debian.org On 03/05/12 20:44, Patrick Ouellette wrote: With all due respect, you can make the same argument for the Node.js package to do this. Node.js is not currently in the stable distribution while node is (apparently this does not have any bearing on the discussion). node might be in stable but it has less than 100 installs of which about *20* are currently shown as vote meaning they are active. Popcorn requires a connection to the internet to get statistics. If the machine is not normally connected to the internet, the stats are not reported. What you are also ignoring here is that AX25 packet is pretty much dead in Ham radio. No, I am not ignoring the ax25 packet status in ham radio. When I posted to linux-hams I received a rapid response. There has been a consistent trickle of kernel source patches for ax25 also. Like all things ham radio, there is a significant difference in the number of people who participate in ax25 / packet depending on the area you are in. APRS is fairly common in the metropolitan areas of the USA. APRS uses UI ax25 frames. It is not infrequent to find the same location running a APRS digipeater and a PBBS. There is a coordinated effort in the state of Virginia to use ax25 as a part of the disaster communications plan (http://www.vden.org/). Pat NE4PO -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503203208.go19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 03:09:42PM -0400, Andrew Starr-Bochicchio wrote: It has been said many times that the impact on users will be limited as node is not meant to be called directly but by inetd. You and other members of the ham radio community seem to feel that there would be an impact on its users. Perhaps pointing to some specific use cases that will be impacted would help the rest of us understand the issues your user would face? Apologies if you've covered this elsewhere (I've read this thread but not all of the past ones). From the linux-hams list: From my experience, many MANY Linux hams have customized scripts that startup some very elaborate HAM systems. For many, these scripts weren't written by them and the changing of the node command could be very difficult for some. The other aspect is if this change came into a package update that could impact production systems in VERY remote sites. This could cause all kinds ugliness that can be easily avoided. From the ax25-HOWTO (http://tldp.org/HOWTO/AX25-HOWTO/x1688.html): The node would normally be invoked from the ax25d program although it is also capable of being invoked from the TCP/IP inetd program to allow users to telnet to your machine and obtain access to it, or by running it from the command line. In practice, node is called from inetd, ax25d, scripts, and from the command line directly depending on the need and circumstance. I have stated elsewhere in the threads, there can be significant challenges to physically access the ham radio machines if the transition breaks the system. If the ham radio node has to change, the change must be bulletproof to the greatest extent possible. A failed upgrade may deprive a region of emergency communications capability until the problem is resolved. editorial Ironically one of the reasons many hams looked to Debian was the stability of the system and the ability to upgrade in place. Changing a core ham radio component throws those reasons out the window. /editorial Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503193459.gl19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 05:13:09PM -0400, Chris Knadle wrote: Drat. I forgot about APRS. APRS has become fairly popular among hams, so much so that it now comes built-in to several radios, and even HTs (Handy-Talkies). APRS is a system for location reporting. It's also very commonly used to track experimental weather balloons at high altitudes, because apparently GPS stops working at around 30,000 feet. [The original high-altitude MIT balloon launch that many others have duplicated uses APRS, and I know of other groups using it for this purpose also.] APRS is also commonly used by hams to track themselves and/or their cars and loved ones as they drive around. The rigs used in cars likely aren't running a Linux OS, but the base station nodes that receive and report the APRS traffic probably are, and as Debian has been friendly to hams it's one of the more likely to be used there. Continue to say DRAT! The handwriting is on the wall. Very few have come out even marginally supporting the ham radio claim other than myself. Frankly, given the lack of response from the Debian ham community I'm inclined to no longer maintain the ax25 packages and let them drop from Debian. Three other people are listed as uploaders on ax25-apps: Jaime Robles, Hamish Moffatt, and Ramakrishnan Muthukrishnan. I haven't heard from any of them. Haven't heard from our QSSTV supporter either (Steve Kostecke). 73, Pat NE4PO -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503212829.gp19...@flying-gecko.net
Re: Node.js and it's future in debian
On Thu, May 03, 2012 at 04:46:09PM -0500, Peter Samuelson wrote: Date: Thu, 3 May 2012 16:46:09 -0500 From: Peter Samuelson pe...@p12n.org Subject: Re: Node.js and it's future in debian To: debian-devel@lists.debian.org, Patrick Ouellette poue...@debian.org, Andrew Starr-Bochicchio a.star...@gmail.com [David Weinehall] So... A (admittedly expensive) pre-inst script that checks the system for calls to /usr/sbin/node outside of Debian packages would likely do the trick? That seems like a pretty big violation of the spirit, and possibly the letter, of Debian Policy. I suspect he was suggesting a pre-inst script that scanned and identified the files with /usr/sbin/node references so the sysadmin could update them. That would not be any different in spirit than the script the checks your system for the ability to move to dependency based init. Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120503220348.gr19...@flying-gecko.net
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Tue, May 01, 2012 at 08:22:05PM -0700, Russ Allbery wrote: Maybe we should short-circuit this part of the conversation, since it doesn't sound like you're horribly interested in agreeing to change the name of node in the existing package. :) Actually, despite my vigorous defense of the ham radio use of node as a binary name, I am not adverse to renaming it provided it can be done in a manner that minimally disrupts the users. I believe the Node.js people need to help since they are the late comers and their upstream seems to be the issue, and they ignored policy at their peril to force the issue. I'm more than a bit disappointed that this will be the second time a ham radio tool in Debian is forced to use a name the wider Linux ham community does not use. No one seems to be considering the issues or complications caused to the ham users. I've heard the assertion that the ham users are a smaller community, but I have not seen the numbers. It seems the issue has come down to a popularity contest, and since the Node.js folks don't understand ham radio the ham radio people will be made to bear the burden of the change. I think it would make sense to take this to the Technical Committee at this point and just make a decision, unless anyone thinks something substantially new is likely to turn up. (We should probably give it a few more days to see if anything does, but it's feeling increasingly unlikely to me, as is the idea that we're all going to reach a consensus.) I forwarded the message proposing the Node.js people step up with a migration plan and code to transition the ham radio package to the linux-hams list. It usually takes a few days to get any substantive comments on that list. Pat -- ,-. Patrick Ouellette| It is no use walking anywhere to preach unless pat(at)flying-gecko.net | our walking is our preaching. Amateur Radio: NE4PO | -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502211033.gk7...@flying-gecko.net
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Wed, May 02, 2012 at 06:43:04PM +0100, Neil Williams wrote: There's also http://packages.debian.org/#search_contents which can search for files listed within packages. That's where I check. Pat -- ,-. Patrick Ouellette| No one is to be called an enemy, all are your pat(at)flying-gecko.net | benefactors, and no one does you harm. Amateur Radio: NE4PO | You have no enemy except yourselves. | -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502211226.gl7...@flying-gecko.net
Re: Node.js and it's future in debian
On Sat, Apr 28, 2012 at 03:31:02AM +0200, Carl Fürstenberg wrote: There has been an log struggle between the nodejs package and the node package, which is still unresolved (bug #611698 for example) And I wonder now what the future should look like. To summarize the problem: * the nodejs upstream binary is called node, and the upstream developers have refused to change it's binary name to nodejs for debian; * The the hamradio package node shipping a binary called node, and as it's so old, the developers argue that the package must ship a binary called node or breakage will occur. * The reason the nodejs developers want to ship the binary as node is because all programs written for nodejs all has /usr/bin/node in it's shebang * the nodejs package are not allowed to conflict on the node package just because the binary name is the same As I'm not a hamradio user, I'm off course biased towards letting nodejs having the node binary and let it pass to testing. But we must find a solution to this, as nodejs is getting more and more used, and developers are forced to install nodejs from source to be able to use it instead of install it via the package manager. I was under the impression that neither package was going to move forward with a binary named node The proposal was made for a transition plan to be made then the nodejs person quit talking/posting. Pat -- ,-. Patrick Ouellette| Start by doing what's necessary; then do pat(at)flying-gecko.net | what's possible; and suddenly you are doing Amateur Radio: NE4PO | the impossible. -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501205524.gi30...@flying-gecko.net
Re: Node.js and it's future in debian
On Fri, Apr 27, 2012 at 08:26:47PM -0700, Russ Allbery wrote: Contrast that with the positive actitude of the NFS developers of CITI at UMichi when heimdal-dev and libgssapi-dev both contained /usr/lib/libgssapi.a [1]. They went to the trouble of renaming libgssapi to libgssglue. Indeed, and I'm very grateful for that. But realistically that was also a lot easier than renaming Node.js's interpreter, and I think the CITI folks did actually know that was coming. The conflict had already been pointed out in the Kerberos community and had been discussed prior to it coming up here. But more significantly that library was essentially used only by NFS, so only a few clients had to change and the renaming was fairly straightforward. The Node.js developer KNEW there were other binaries named node, and just went on as if it did not matter. Check the development history/blog. Node.js is at this point another matter; it's the topic of books, widespread use independent of the upstream developers, and lots of articles and Internet documentation with a life of its own. A quick Google search comes up with tons of indepedent sites telling people to run programs with node script-name. That makes renaming a much more difficult prospect. And the ham radio binary is the subject of sections of how-to's and books on amateur radio. It also has a life of it's own in the ham radio community. If a binary's name is simply a matter of a popularity contest in Debian, at some point every name may be made to change. -- ,-. Patrick Ouellette |It is in pardoning that we are pardoned. pat(at)flying-gecko.net |-- Francis of Assisi Amateur Radio: NE4PO | `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501211011.gj30...@flying-gecko.net
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote: Node.js is becoming quite popular and is known generally to use node in its hash-bang. Seriously? People are writing scripts that start #!node That is truely messed up! Pat -- ,-. Patrick Ouellette | Lord, grant that I might not so much seek pat(at)flying-gecko.net | to be loved as to love. Amateur Radio: NE4PO | -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501211803.gk30...@flying-gecko.net
Re: Node.js and it's future in debian
On Tue, May 01, 2012 at 01:07:11AM +0200, Carsten Hey wrote: Date: Tue, 1 May 2012 01:07:11 +0200 From: Carsten Hey cars...@debian.org Subject: Re: Node.js and it's future in debian To: debian-devel@lists.debian.org Mail-Followup-To: Carsten Hey cars...@debian.org, debian-devel@lists.debian.org * Carl Fürstenberg [2012-04-28 03:31 +0200]: There has been an log struggle between the nodejs package and the node package, which is still unresolved (bug #611698 for example) And I wonder now what the future should look like. In short I think that there is only one sane solution to this and that the way to reach this solution is to ask the tech-ctte for a decision. This is the second thread about this topic on -devel, the first one was in November 2011. In both threads and in some smaller ones, people basically claimed things like (incomplete list): It is at least the third discussion that I can remember. Given that node is a rarely used daemon and that nodejs is a widely used language, I think that nodejs should get the binary name node; but due to the non-responsiveness of node's maintainers I think this might be a case where involving the tech-ctte would help. node's maintainers don't participate in such discussions in a reasonable and timely manner, for example the RC bug had no action for months despite the patch and nobody ever explained what exactly the problem of a changed binary name for a daemon would be (node can be used interactively, but it is not supposed to be used that way and those users that do would be able to set up an alias anyway). The first answer from one of the uploaders was sent nearly a year after nodesjs' maintainer asked about this issue on the maintainer's list (back then he didn't seem to notice that those who answered were unrelated to the node package). The subject of the -devel thread last year Is anyone maintaining (the ham radio tool) node? speaks for itself. So expel all the maintainers for having a real life and not living and breathing only the Debian project and it's fire hose like mailing lists. If timeliness is an issue, email the maintainer(s) directly. No other package is subverted because of slowness to address a bug (the exception being NMU uploads, which I would not class as subverting the package). Packages are dropped from the release for RC bugs. A package that has been in Debian for YEARS should not expect a RC bug to be filed on the basis on a name space collision. (Otherwise look out for your favorite executable, because someone WILL name the next new thing with the same name.) As was put forth in the Is anyone maintaining thread, node is a fairly mature piece of code that has been working without major upstream changes because it does the job it was written to do. I assume all of node's uploaders did great work on many ham related packages, but all that the two uploaders that replied to this issue during the last two years did related to the node package is that they also replied to the Call for debian hamradio developers pool from node's actual but now retired maintainer who then added them as uploaders. Only Hamish, who did not respond to this issue, uploaded node once in 2005, the others did never do any upload. The responses from the other two uploaders were essentially please report a bug (although this was already done) by one; and ... then no package should get the name and in one mail this patch needs to be tested by someone who runs node and nodejs by the other. There hasn't been any upstream changes in node for a long time. The package builds fine in the auto-builders and does what it was designed to do. The number of active ham radio maintainers has varied over time, just like other packages. Right now there are only a few, and most of us are busy (just like everyone else). -- ,-. Patrick Ouellette | It is not fitting, when one is in God's service, pat(at)flying-gecko.net | to have a gloomy face or a chilling look. Amateur Radio: NE4PO| -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501213654.gl30...@flying-gecko.net
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Tue, May 01, 2012 at 03:24:58PM -0700, Russ Allbery wrote: Date: Tue, 01 May 2012 15:24:58 -0700 From: Russ Allbery r...@debian.org Subject: Re: [Pkg-javascript-devel] Node.js and it's future in debian To: debian-devel@lists.debian.org Patrick Ouellette poue...@debian.org writes: On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote: Node.js is becoming quite popular and is known generally to use node in its hash-bang. Seriously? People are writing scripts that start #!node The #! part is really not the issue, since the two packages don't conflict there (the ham radio one is in /usr/sbin). Of course the #! line is not the issue. The issue is two upstream maintainers separated by years and miles selected the same generic name for their binary file. Compounding the issue, some Debian Maintainer seeking to better the project by packaging additional software for the project failed to perform due diligence in researching if any of the binary names from the proposed new package were already in use. Having packaged the software and uploaded it, someone noticed the issue and started us down the path we are on. However, Googling for Node.js tutorials and documentation actually reveal that people usually *don't* use #!, which would avoid the conflict, and instead run node file. Which means when both packages are installed, which node they get depends on what their PATH looks like, which is the sort of conflict that we try to avoid. So Google says most people run the files interactively from the command line, almost never from scripts? Be careful using search engine results to support your position. You can usually skew the results depending on which search engine you use and how you word the search. Do you still do things (especially repetitive things) the way you learned in the tutorial/documentation? Do you automate processes with shell scripts, or type the command each time? Pat -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502031200.gb18...@flying-gecko.net
Accepted ax25-tools 0.0.10-rc2+cvs20120204-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 09 Apr 2012 12:01:16 -0400 Source: ax25-tools Binary: ax25-tools ax25-xtools Architecture: source amd64 Version: 0.0.10-rc2+cvs20120204-3 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-tools - tools for AX.25 interface configuration ax25-xtools - tools for AX.25 interface configuration -- X11-based Closes: 665236 Changes: ax25-tools (0.0.10-rc2+cvs20120204-3) unstable; urgency=low . * Fix FTBFS: dh_movefiles: debian/ax25-tools/usr/sbin/xfhdlcchpar not found (supposed to put it in ax25-xtools) explain what you changed and why (Closes: #665236) Checksums-Sha1: b5fabc91a71fb1897c7d43cce840ad7e23126009 1522 ax25-tools_0.0.10-rc2+cvs20120204-3.dsc a1c6b6c54b1f4194bf08fc38a00f9db7c0eb6864 119759 ax25-tools_0.0.10-rc2+cvs20120204-3.diff.gz afa0ceb02ce8b8709b0da2ac274e89c5b42cf1e5 230770 ax25-tools_0.0.10-rc2+cvs20120204-3_amd64.deb 80012b24c06e37d2e01642444d6fd7b75976c166 43650 ax25-xtools_0.0.10-rc2+cvs20120204-3_amd64.deb Checksums-Sha256: 68c2ce0a4db01b9bdb7f56028de724ad3fb841898e3c0ff673d93f7cbc80a615 1522 ax25-tools_0.0.10-rc2+cvs20120204-3.dsc 03a3b312b7e0f2553a7fe6da4403489485735c778c2954cf9fabddaff6b73024 119759 ax25-tools_0.0.10-rc2+cvs20120204-3.diff.gz 244ee3427a960251e11cadfa2c79b20c168f608fc1fb484571234d1115334b49 230770 ax25-tools_0.0.10-rc2+cvs20120204-3_amd64.deb 6f02666a2f6f94a04e0efef9d7b6924c3726818811901218ecd54b508a0ab8e4 43650 ax25-xtools_0.0.10-rc2+cvs20120204-3_amd64.deb Files: fc051e08eada0d2203852824dda21fb8 1522 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-3.dsc 92ca2ab1829edc8098cb26f9edfd2758 119759 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-3.diff.gz 51eb8a51dec83bed6063ec13617ed113 230770 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-3_amd64.deb a7d36d65fbd1344c78df102b3be5e3a9 43650 hamradio extra ax25-xtools_0.0.10-rc2+cvs20120204-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+DCOIACgkQz9qdgganN26zdgCfWUE6W0gS6K0jAmhpfaYE0UmP Bh0AoMviKY75VSFCDLj5tctMvpLofmez =/JiS -END PGP SIGNATURE- Accepted: ax25-tools_0.0.10-rc2+cvs20120204-3.diff.gz to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-3.diff.gz ax25-tools_0.0.10-rc2+cvs20120204-3.dsc to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-3.dsc ax25-tools_0.0.10-rc2+cvs20120204-3_amd64.deb to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-3_amd64.deb ax25-xtools_0.0.10-rc2+cvs20120204-3_amd64.deb to main/a/ax25-tools/ax25-xtools_0.0.10-rc2+cvs20120204-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s-0004tc...@franck.debian.org
Re: debian-multimedia.org considered harmful
On Fri, Mar 16, 2012 at 12:21:14AM +, Ben Hutchings wrote: On Thu, Mar 15, 2012 at 04:11:00PM -0400, Patrick Ouellette wrote: On Sun, Mar 11, 2012 at 09:48:02AM +0100, Luk Claes wrote: Why so? If I make a copy for backup and want to use it, how would I do that without use of decss or similar? Or is making a backup copy no legitimate use anymore? You don't need decss to make a backup copy of a DVD. All you have to do is a block copy of the media. That is just one of the reasons the arguments against decss are/were less than intelligent. DVD-CCA was not that stupid. Consumer writable DVD media does not allow you to write the disc keys, so you cannot make a simple copy that is readable by an authorised DVD player. That may be the theory, but the real world implementation seems to be a little different. I have not heard of anyone having a problem using a block copy to backup a commercially produced consumer DVD to consumer writable DVD media. -- ,-. Patrick Ouellette | Above all the grace and the gifts that Christ pat(at)flying-gecko.net | gives to his beloved is that of overcoming self. Amateur Radio: NE4PO| -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120316171143.ga28...@flying-gecko.net
Re: debian-multimedia.org considered harmful
On Thu, Mar 15, 2012 at 08:20:22PM -0400, Chris Knadle wrote: On Thursday, March 15, 2012 16:11:00, Patrick Ouellette wrote: On Sun, Mar 11, 2012 at 09:48:02AM +0100, Luk Claes wrote: Why so? If I make a copy for backup and want to use it, how would I do that without use of decss or similar? Or is making a backup copy no legitimate use anymore? You don't need decss to make a backup copy of a DVD. All you have to do is a block copy of the media. That is just one of the reasons the arguments against decss are/were less than intelligent. That depends on whether the DVD will fit onto the media its to be burnt to. If the DVD needs to be resampled in order to get it to fit onto the burnt media, then you need to be able to decypher it to be able to do that. Resampling could be termed a derivative work, not a backup copy since you are throwing away information contained in the original. -- ,-. Patrick Ouellette| I have been all things unholy. If God can work pat(at)flying-gecko.net | through me, he can work through anyone. Amateur Radio: NE4PO | -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120316171330.gb28...@flying-gecko.net
Re: debian-multimedia.org considered harmful
On Sun, Mar 11, 2012 at 09:48:02AM +0100, Luk Claes wrote: Why so? If I make a copy for backup and want to use it, how would I do that without use of decss or similar? Or is making a backup copy no legitimate use anymore? You don't need decss to make a backup copy of a DVD. All you have to do is a block copy of the media. That is just one of the reasons the arguments against decss are/were less than intelligent. Pat -- ,-. Patrick Ouellette| No one is to be called an enemy, all are your pat(at)flying-gecko.net | benefactors, and no one does you harm. Amateur Radio: NE4PO | You have no enemy except yourselves. | -- Francis of Assisi `-' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120315201100.ga24...@flying-gecko.net
Accepted ax25-apps 0.0.8-rc2+cvs20120204-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 26 Feb 2012 20:46:29 -0500 Source: ax25-apps Binary: ax25-apps Architecture: source amd64 Version: 0.0.8-rc2+cvs20120204-2 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-apps - AX.25 ham radio applications Closes: 510947 593666 606338 627843 659128 Changes: ax25-apps (0.0.8-rc2+cvs20120204-2) unstable; urgency=low . * Fix ax25ipd: fails to transmit packets with assemble_kiss: dumped - control byte non-zero fixed in new upstream (Closes: #606338) * Fix pending l10n issues. Debconf translations: * Italian (Vincenzo Campanella). Closes: #593666 * Danish (Joe Hansen). Closes: #627843 * Polish (Michał Kułach). Closes: #659128 * Fix Uses absolute path to call dpkg-statoverride change check for - dpkg-statoverride from test to hash (Closes: #510947) Checksums-Sha1: 64bff1c71f97f88f388a9a781b53e6ee9c2028dd 1357 ax25-apps_0.0.8-rc2+cvs20120204-2.dsc 5989bafbdb36bdc2d5046008b53f2e56841d0034 342631 ax25-apps_0.0.8-rc2+cvs20120204-2.diff.gz 066745bdb638bb790e5de2a76f83d621a56097e9 122988 ax25-apps_0.0.8-rc2+cvs20120204-2_amd64.deb Checksums-Sha256: 47f7b25f7eef98aec81c232b0a1101d13d6d8395fabc2c9a5e1505fb048ef13e 1357 ax25-apps_0.0.8-rc2+cvs20120204-2.dsc 9de31bf3473d0c92047db9f1aeb5000849f9826e8461e582652785f3aaa36cc1 342631 ax25-apps_0.0.8-rc2+cvs20120204-2.diff.gz 994a5615dde5bbc826bd30566548e40d269d76f69186814ea09b05da00e53d37 122988 ax25-apps_0.0.8-rc2+cvs20120204-2_amd64.deb Files: d3c5b3f9f6c049b3134803a616d501e8 1357 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204-2.dsc c9468923a46192cb85da460a5f85e0e5 342631 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204-2.diff.gz a7a890ed9e910502a85913b66595badc 122988 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9K8lsACgkQz9qdgganN27DPQCgp/1a5OCECg8rOZ34R2AZUwQz 4nEAoMxH0JkHDqfN3SgUJrb8qfKCt67m =eIJP -END PGP SIGNATURE- Accepted: ax25-apps_0.0.8-rc2+cvs20120204-2.diff.gz to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204-2.diff.gz ax25-apps_0.0.8-rc2+cvs20120204-2.dsc to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204-2.dsc ax25-apps_0.0.8-rc2+cvs20120204-2_amd64.deb to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s1r5n-0001c9...@franck.debian.org
Accepted ax25-tools 0.0.10-rc2+cvs20120204-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 26 Feb 2012 20:53:44 -0500 Source: ax25-tools Binary: ax25-tools ax25-xtools Architecture: source amd64 Version: 0.0.10-rc2+cvs20120204-2 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-tools - tools for AX.25 interface configuration ax25-xtools - tools for AX.25 interface configuration -- X11-based Closes: 568290 603169 Changes: ax25-tools (0.0.10-rc2+cvs20120204-2) unstable; urgency=low . * Fix kissnetd broken with PTYs fixed in the new upstream (Closes: #603169) * Fix beacon crashes if the length of the destination exceeds 20 fixed in the new upstream (Closes: #568290) * Fix FTBFS by adding chmod +x configure to debian/rules Checksums-Sha1: 58c2a13ea44232c2934ddb1636c80d1a0fc1311e 1482 ax25-tools_0.0.10-rc2+cvs20120204-2.dsc e13f4aa3790f72b013a7ff2316d52b4b9bdf115a 119519 ax25-tools_0.0.10-rc2+cvs20120204-2.diff.gz c97daed16198dc5d4075f55fc1d8c0ed3586d52c 230650 ax25-tools_0.0.10-rc2+cvs20120204-2_amd64.deb 70730b6fefc9d09be4abc219b4c23302d035edea 43530 ax25-xtools_0.0.10-rc2+cvs20120204-2_amd64.deb Checksums-Sha256: f304266883f286a870dd067121323f0c80bc5bbfa3c65e6d916ec389bbdbf470 1482 ax25-tools_0.0.10-rc2+cvs20120204-2.dsc 45cbb1e4d7ed07c00f35389d09165cc90a5ca3e06747182c10567ab1803b853b 119519 ax25-tools_0.0.10-rc2+cvs20120204-2.diff.gz fa792df0173b6b6c4401a7bab38f8e87ebfa2cb8f0c969683ed3785b8959dd43 230650 ax25-tools_0.0.10-rc2+cvs20120204-2_amd64.deb aba7e0f1f3b0500e1a73294d19e9fe7c6e0488a05e0f6d90f7a4c10b6df9ca2c 43530 ax25-xtools_0.0.10-rc2+cvs20120204-2_amd64.deb Files: bdcd16224f71aec38b161e737be52144 1482 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-2.dsc ac1a8dd36565ea3ce0e1c684348024f5 119519 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-2.diff.gz d8126e272e65845d15805084423b3f6f 230650 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-2_amd64.deb 2943a45e7543daa42d3a8d471b6eb0d8 43530 hamradio extra ax25-xtools_0.0.10-rc2+cvs20120204-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9K7dkACgkQz9qdgganN25CLACfdOa+W7EdqJk0TFEZd1S8TmWC HNkAoKUfBLOWGacy74SfvgkQt/LAEkRM =j2uc -END PGP SIGNATURE- Accepted: ax25-tools_0.0.10-rc2+cvs20120204-2.diff.gz to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-2.diff.gz ax25-tools_0.0.10-rc2+cvs20120204-2.dsc to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-2.dsc ax25-tools_0.0.10-rc2+cvs20120204-2_amd64.deb to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-2_amd64.deb ax25-xtools_0.0.10-rc2+cvs20120204-2_amd64.deb to main/a/ax25-tools/ax25-xtools_0.0.10-rc2+cvs20120204-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s1r5c-0001ni...@franck.debian.org
Accepted libax25 0.0.12-rc2+cvs20120204-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 26 Feb 2012 20:04:08 -0500 Source: libax25 Binary: libax25 libax25-dev Architecture: source amd64 Version: 0.0.12-rc2+cvs20120204-2 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: libax25- ax25 library for hamradio applications libax25-dev - ax25 library development files Closes: 658770 Changes: libax25 (0.0.12-rc2+cvs20120204-2) unstable; urgency=low . * Fix libax25 FTBFS make: execvp: ./configure: Permission denied added chmod +x configure to debian/rules (Closes: #658770) Checksums-Sha1: 958c9f0721058025ff98828440b7c4bdfcd2b120 1321 libax25_0.0.12-rc2+cvs20120204-2.dsc d881c1b21e054f9c837a095ef58430920a361872 301421 libax25_0.0.12-rc2+cvs20120204-2.diff.gz 8ebc5f44d70609d149dd4e5fef137155efd5c6e9 29660 libax25_0.0.12-rc2+cvs20120204-2_amd64.deb 659e1eb6a60feb2a9b83a151015a3c5d3a1df9b8 30834 libax25-dev_0.0.12-rc2+cvs20120204-2_amd64.deb Checksums-Sha256: b87205a0a50c95acbccf667793af25606038b75e2cac1b983ff31de514ddeea1 1321 libax25_0.0.12-rc2+cvs20120204-2.dsc 190d17d4f541baba773dd8107afac27720a1f26a972d3b9db19bf82defa3b5a0 301421 libax25_0.0.12-rc2+cvs20120204-2.diff.gz e1503e302d46596416388cd82d173e94e8b99076fb910c7bf623d744627fa33e 29660 libax25_0.0.12-rc2+cvs20120204-2_amd64.deb f27663936d84fb692559047af440ed81ce1e6d2bc45ce80e701109a3817ecff8 30834 libax25-dev_0.0.12-rc2+cvs20120204-2_amd64.deb Files: 4de36c14afd04040028a8520b7f2ccc4 1321 hamradio optional libax25_0.0.12-rc2+cvs20120204-2.dsc 4ae8584f2c76fea08c1d28536627f4ca 301421 hamradio optional libax25_0.0.12-rc2+cvs20120204-2.diff.gz 37cb544a05d92102745941ae3f2d00e6 29660 hamradio optional libax25_0.0.12-rc2+cvs20120204-2_amd64.deb 98c9cdce003a474f5031e0e5067d4749 30834 hamradio optional libax25-dev_0.0.12-rc2+cvs20120204-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9K7SAACgkQz9qdgganN27ycgCeI/Wg3gI+c5OEL3y1ErmLCrTy nGIAn18wiiHohD/3+zYsigK0V87uUiVU =SA19 -END PGP SIGNATURE- Accepted: libax25-dev_0.0.12-rc2+cvs20120204-2_amd64.deb to main/liba/libax25/libax25-dev_0.0.12-rc2+cvs20120204-2_amd64.deb libax25_0.0.12-rc2+cvs20120204-2.diff.gz to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204-2.diff.gz libax25_0.0.12-rc2+cvs20120204-2.dsc to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204-2.dsc libax25_0.0.12-rc2+cvs20120204-2_amd64.deb to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s1r68-0001sj...@franck.debian.org
Accepted ax25-apps 0.0.8-rc2+cvs20120204-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 04 Feb 2012 22:03:45 -0500 Source: ax25-apps Binary: ax25-apps Architecture: source amd64 Version: 0.0.8-rc2+cvs20120204-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-apps - AX.25 ham radio applications Changes: ax25-apps (0.0.8-rc2+cvs20120204-1) unstable; urgency=low . * new upstream Checksums-Sha1: 2d335ffea6eacde780b6fc5d1e8171ade3d17259 1357 ax25-apps_0.0.8-rc2+cvs20120204-1.dsc b1b8fb2ae9abb8c839b72bf395f1230ac4733b1e 138106 ax25-apps_0.0.8-rc2+cvs20120204.orig.tar.gz d8506c5e6936451ec13c9d6810051cac70b345a3 341246 ax25-apps_0.0.8-rc2+cvs20120204-1.diff.gz da263dc63db7b501bac3be31f98c279866dc9d5a 122286 ax25-apps_0.0.8-rc2+cvs20120204-1_amd64.deb Checksums-Sha256: 4afc74c7338129d9c7827ddd61ebb22da2f9137410e8def534f60b7e749c7546 1357 ax25-apps_0.0.8-rc2+cvs20120204-1.dsc d5a3bf1519ea1eac568d20d141bacb84db69bb2584abbcd9467accaae9bc6dd7 138106 ax25-apps_0.0.8-rc2+cvs20120204.orig.tar.gz 20c4486ea23262ceabe3608d4698033c68c3b681045b80f70da09d95a1091bb8 341246 ax25-apps_0.0.8-rc2+cvs20120204-1.diff.gz efde0594d5d5960c6f095fa1d279042d1839237037a6c3f24e6fcc302ea26190 122286 ax25-apps_0.0.8-rc2+cvs20120204-1_amd64.deb Files: f40f9e276188aec4a979ed9f4ada34cf 1357 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204-1.dsc 5611ae010c7c679e40627b29f2971cf0 138106 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204.orig.tar.gz 367e13f5d05d647ca08cadcd46b758ad 341246 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204-1.diff.gz a517adf47c74fe5ee6f3e608c0e6f1f1 122286 hamradio extra ax25-apps_0.0.8-rc2+cvs20120204-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8uAuEACgkQz9qdgganN25SVACfTYCHMHll3LYP5NIrnZ1Ekcqf ZnIAnReZWD52MWgHrlYlnp5Dy+JDL067 =PvgH -END PGP SIGNATURE- Accepted: ax25-apps_0.0.8-rc2+cvs20120204-1.diff.gz to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204-1.diff.gz ax25-apps_0.0.8-rc2+cvs20120204-1.dsc to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204-1.dsc ax25-apps_0.0.8-rc2+cvs20120204-1_amd64.deb to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204-1_amd64.deb ax25-apps_0.0.8-rc2+cvs20120204.orig.tar.gz to main/a/ax25-apps/ax25-apps_0.0.8-rc2+cvs20120204.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rtueu-0003zk...@franck.debian.org
Accepted ax25-tools 0.0.10-rc2+cvs20120204-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 04 Feb 2012 22:14:52 -0500 Source: ax25-tools Binary: ax25-tools ax25-xtools Architecture: source amd64 Version: 0.0.10-rc2+cvs20120204-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: ax25-tools - tools for AX.25 interface configuration ax25-xtools - tools for AX.25 interface configuration -- X11-based Changes: ax25-tools (0.0.10-rc2+cvs20120204-1) unstable; urgency=low . * new upstream Checksums-Sha1: 9b379da7dfca2aaf968ce07c950178bf2f2fd218 1482 ax25-tools_0.0.10-rc2+cvs20120204-1.dsc 9bd6e7620c162eb0c4f66bd34f0951656bd19e61 203480 ax25-tools_0.0.10-rc2+cvs20120204.orig.tar.gz cbabb69944b46365c5e01ba43c18d6e8a3b459af 119352 ax25-tools_0.0.10-rc2+cvs20120204-1.diff.gz 46414fe21ea68d4a2a6b0538799b53b5f26223a2 230530 ax25-tools_0.0.10-rc2+cvs20120204-1_amd64.deb 19b45e2ab35e50951272d8410d825e1f0ef8cd73 42748 ax25-xtools_0.0.10-rc2+cvs20120204-1_amd64.deb Checksums-Sha256: 6b1b28539ef6f8060efadfc1eae763fe353caeee9797828e81b2859de81caaf7 1482 ax25-tools_0.0.10-rc2+cvs20120204-1.dsc 2585a296081ccdce52e9703c7ac1634297ce39d03d69d3831e38d81b2fa74fe0 203480 ax25-tools_0.0.10-rc2+cvs20120204.orig.tar.gz 7e18b4ad29fd7d9e97dc3ca1e2784727e7ad46da8763fa853021984a96458431 119352 ax25-tools_0.0.10-rc2+cvs20120204-1.diff.gz 11c7541f8129970e4e6bf209f0dbb67a5dcd56cbf656121f00439349c45f1905 230530 ax25-tools_0.0.10-rc2+cvs20120204-1_amd64.deb 1b3ae42043d9135b1b94602db5caaaed74ff81514dc6c8426b938086fd1c2767 42748 ax25-xtools_0.0.10-rc2+cvs20120204-1_amd64.deb Files: 1b4d06cc20a521f3a39716d28d45ec25 1482 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-1.dsc a7d530ecfbc7df6503016e849a9de43e 203480 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204.orig.tar.gz 3a4dfc7fcc18dcb70b96dc6a91ff1f25 119352 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-1.diff.gz a906b34d8b9cc180ea409e07b0b26443 230530 hamradio extra ax25-tools_0.0.10-rc2+cvs20120204-1_amd64.deb 502084c2b0162cad8f60e68ad3521a46 42748 hamradio extra ax25-xtools_0.0.10-rc2+cvs20120204-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8uAccACgkQz9qdgganN24KnQCgpgFabY1BDwMnNCYLibPxiByX 3oIAn0twi2UMd4Y+yanOls5425L6Rik7 =oeRU -END PGP SIGNATURE- Accepted: ax25-tools_0.0.10-rc2+cvs20120204-1.diff.gz to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-1.diff.gz ax25-tools_0.0.10-rc2+cvs20120204-1.dsc to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-1.dsc ax25-tools_0.0.10-rc2+cvs20120204-1_amd64.deb to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204-1_amd64.deb ax25-tools_0.0.10-rc2+cvs20120204.orig.tar.gz to main/a/ax25-tools/ax25-tools_0.0.10-rc2+cvs20120204.orig.tar.gz ax25-xtools_0.0.10-rc2+cvs20120204-1_amd64.deb to main/a/ax25-tools/ax25-xtools_0.0.10-rc2+cvs20120204-1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rtufb-0003kd...@franck.debian.org
Accepted libax25 0.0.12-rc2+cvs20120204-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 04 Feb 2012 21:50:54 -0500 Source: libax25 Binary: libax25 libax25-dev Architecture: source amd64 Version: 0.0.12-rc2+cvs20120204-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: libax25- ax25 library for hamradio applications libax25-dev - ax25 library development files Changes: libax25 (0.0.12-rc2+cvs20120204-1) unstable; urgency=low . * new upstream Checksums-Sha1: e663188d8e916378dd7862e7b82317bf0b57d9fd 1321 libax25_0.0.12-rc2+cvs20120204-1.dsc 71a09ebed43a6a60f3b45a6aba4ba4d6b363997f 62766 libax25_0.0.12-rc2+cvs20120204.orig.tar.gz 673de9952936d11aabc007b38450f6cdc65c36ae 301250 libax25_0.0.12-rc2+cvs20120204-1.diff.gz 523fdec8314f23785f4db2780db86d296096000f 29562 libax25_0.0.12-rc2+cvs20120204-1_amd64.deb 4a0a0e66e6b0d7fcff282ae4804b1316c15b3678 30744 libax25-dev_0.0.12-rc2+cvs20120204-1_amd64.deb Checksums-Sha256: b8e5761923476ad27ac0a51b9f8f0bc6fcec0b309b0002b22c3afc59274893fd 1321 libax25_0.0.12-rc2+cvs20120204-1.dsc e3cf8011ef86acab4d54b122501cea596c03a90bdc35a9ebe4078719af449b38 62766 libax25_0.0.12-rc2+cvs20120204.orig.tar.gz dcfa4d7b4398a16e135819e1e76207342a3e24676fb6de6d8f1e8a1059265890 301250 libax25_0.0.12-rc2+cvs20120204-1.diff.gz e3ca103dc0950d6c2f844d752a512a1ca56d51a5f51697e59e8883eaf8289069 29562 libax25_0.0.12-rc2+cvs20120204-1_amd64.deb 3e0004bae54985053ee46a3ed955b6f17e9c30aef86a050afe623a6f70c972e3 30744 libax25-dev_0.0.12-rc2+cvs20120204-1_amd64.deb Files: 35ba0a2967bb76af49a386b4ea6ccac3 1321 hamradio optional libax25_0.0.12-rc2+cvs20120204-1.dsc 8eea13c4efec6304fbcd9b6f8a990656 62766 hamradio optional libax25_0.0.12-rc2+cvs20120204.orig.tar.gz 94ed5cf47d08a69d1fa7efd67771c063 301250 hamradio optional libax25_0.0.12-rc2+cvs20120204-1.diff.gz 0709a68ae41fd006f21bde60de620629 29562 hamradio optional libax25_0.0.12-rc2+cvs20120204-1_amd64.deb 473f7087791122bbfff2a07e28a4 30744 hamradio optional libax25-dev_0.0.12-rc2+cvs20120204-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8uAocACgkQz9qdgganN27OnQCaAubPctkj9Jf3Wo/HqOCey8jf OfQAoNC4CvA+VMOC5oIBXuWCeDKo5UBm =oaO8 -END PGP SIGNATURE- Accepted: libax25-dev_0.0.12-rc2+cvs20120204-1_amd64.deb to main/liba/libax25/libax25-dev_0.0.12-rc2+cvs20120204-1_amd64.deb libax25_0.0.12-rc2+cvs20120204-1.diff.gz to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204-1.diff.gz libax25_0.0.12-rc2+cvs20120204-1.dsc to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204-1.dsc libax25_0.0.12-rc2+cvs20120204-1_amd64.deb to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204-1_amd64.deb libax25_0.0.12-rc2+cvs20120204.orig.tar.gz to main/liba/libax25/libax25_0.0.12-rc2+cvs20120204.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rtugr-0003rl...@franck.debian.org
Re: new on list
On Thu, Jan 05, 2012 at 08:15:47PM +0200, vangelis wrote: Thank you Osamu, i ' ll read all about but please if any group needs help i'm offering. Check http://www.debian.org/devel/wnpp/ find some package(s) that you are interested in and use. Update the packages, fix bugs, find a mentor. Good Luck! -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120105190139.ge28...@flying-gecko.net
Re: Two groups of users, one distro in the middle
On Thu, Nov 17, 2011 at 01:21:17AM +0700, Jonas Smedegaard wrote: Why do noone comment on the point raised that the ham tool possibly can change the name of its binary without involving its end-users, whereas changing the name of the nodejs binary affects all end-users directly? I commented on it earlier - you can not control the user community and how they use the software on their machines. Just because the software is only installed automatically with a specific configuration does not mean that that configuration is the only configuration in use. Changing the name of *any* binary has the potential for creating unintended consequences for the end users. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016194352.ga21...@flying-gecko.net
Re: Is anyone maintaining (the ham radio tool) node?
On Wed, Nov 16, 2011 at 04:04:36PM -0400, Joey Hess wrote: One user claimed it would inconvenience users, but provided no supporting details about why a user would run it manually. http://lists.debian.org/debian-hams/2010/08/msg00032.html The package's own documentation states Node is intended to be called from ax25d or inetd. A similar case with a large userbase is the syslog daemon. Debian used to ship standard with a /usr/sbin/syslogd. Then it was replaced with a /usr/sbin/rsyslog, from a different package. Since rsyslog is Priority important, it gets installed automatically, and this removes sysklogd; you can verify this happened to most users on [1]. However, we have not lost any sleep over users who might have something that ran /usr/sbin/syslogd directly, and I've never seen this inconvenience a single user. I don't know if there's any reason users would be more likely to run node manually than syslogd manually. Even if there is, the vast difference in userbases (multiple orders of magnitude) suggests it's unlikely to inconvenience many users. Probably this case is sufficiently edge that a NEWS file would do. The syslog case does not apply since the *standard* syslog was changed at the distribution level and another package *provides* the same functionality. Users could, if the old syslog package is still in the archive, install the old syslog as an alternative. nodejs *only* exists in unstable. A name change in unstable should be less disruptive because it is, well - unstable. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016203827.ga29...@flying-gecko.net
Re: Is anyone maintaining (the ham radio tool) node?
On Wed, Nov 09, 2011 at 08:33:38AM +, Philipp Kern wrote: On 2011-11-08, Patrick Ouellette p...@flying-gecko.net wrote: I hope to avoid any issues with breaking old boxes with the eventual resolution of the issue. I don't know what's wrong with Jonathan Nieder's advise in [0] about helping users with the conversion automatically. That's how it's usually done. He even provided that patch. I don't know that his patch will or will not work. It needs to be tested by someone who uses the package(s) in question. He stated he uses neither the ham radio node nor nodejs. I note he provided a patch to the ham radio package, but not to the nodejs package. I also note the nodejs maintainers were working on a solution (last updated in February). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611698 Who would refer to the node binary as provided by the ham package node except for the inetd and the ax25d superservers? (Serious question.) I don't think the packagers are in a position to answer this for any particular installation. The end user can create any manner of linkage to any package's binaries. Certainly we can control what packages require specific binaries on a system, but we can not control the user. In this particular case, the postinst for node calls update-inetd to add an entry for node. And marks it as disabled. This is easy enough to change to a different binary name. Because as we're providing a whole distribution we could adjust the latter's configuration file and ensure that both packages are upgraded (using Breaks, for instance). The issue is one of following policy. Debian policy doesn't allow such a resolution to this issue. Consensus on which must change, or both must change are the only allowed outcomes. In this case the two packages at least don't ship the same file. With the current situation you can coinstall the packages and both parts ham and nodejs shebangs will keep working. Provided the programs are being called with complete path names this is true. If the user is just calling node then it depends on the ordering of the search path. I'm pretty sure this is something most people want to avoid But then policy talks of filenames and I don't know if that refers to files with a full path or not… If so, invoking policy as a reason wouldn't help here. Jonathan invoked policy as a reason to change the names, then claimed he wanted node.js to retain the binary name node. You can't have it both ways in the absence of consensus. It appears not enough people in the project care about either package to reach a consensus. Earlier when this particular situation was being discussed, someone mentioned the generic name node was bad for a computer binary. 10-15 years ago it was a different landscape. The node.js folks should probably have given more thought to their binary's name given the nature of the computer software landscape at the time they created their program. I can see the logic in this argument, and so can support changing *both* binaries. I recall this situation earlier for the axlisten binary. Back when I was maintaining the ax25-* packages alone, someone complained that listen conflicted with their audio player (I think) with the same binary name. I argued for the ax25-* package and prevailed. A couple of years later after I was no longer maintaining the ax25-* packages someone complained again and the maintainer for the ax25-* packages decided to change the name to axlisten. Thanks for your questions and input! Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2009151610.ga23...@flying-gecko.net
Resolve namce conflise with node and nodejs [was Re: Is anyone maintaining (the ham radio tool) node?]
Where is the voice of the nodejs maintainers in this? They are listed as: Debian Javascript Maintainers Jérémy Lal Dave Beckett Jonas Smedegaard -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? signature.asc Description: Digital signature
Re: Is anyone maintaining (the ham radio tool) node?
On Tue, Nov 08, 2011 at 07:16:35AM +1100, Damien Gardner Jnr wrote: I have to pop my head up from my lurker-hole here, and say that I'm a more than a little confused, why a 15 year old application should change its name at all? Even the Node.js wiki makes it clear that the application should be called Node.js 'to disambiguate it from other nodes' - it sounds like the developers are being proactive in notifying users that they picked a name which conflicts with other packages? You would think there would be some weight given to the length of time a binary has been in the project, but there is not. First come, first served does not apply according to Debian Policy. I don't know about others, but I'm not overly keen on the idea of reconfiguring machines which were installed last century, because a program which appeared in the last two years has the same name.. If you think about it, node.js is *much* more 'able' to change the name of its binary - it still has an actively developed community! - I don't know about other folk, but I find it pretty darned hard to find much 'current' documentation about a lot of the older x.25 bbs stuff I have running on some of my older boxen - one of my BBS packages doesn't even appear in a google search anymore (god help me if the wrapper I setup in 2001 to make it telnet-accessible as well as dial-in, ever breaks ;) ) I hope to avoid any issues with breaking old boxes with the eventual resolution of the issue. Although I'm curious why both packages can't just shove a Conflicts: in for each other, and be done with it? Or just leave it as is, since they're in different directories, provided a nice big must-click-ok dialog comes up during install/upgrade to notify the user of the change? From the AX.25 side, and probably at least partly from the Node.js side, the users are going to be fairly cluey, if not accomplished hackerers - having multiple binaries of the same name, in different directories in the path is nothing new (hell, we used to rely on it on some of our hosting servers - things like reboot, shutdown, etc were wrappered with scripts in higher-preferenced directories from the PATH, to make sure accidental reboots, shutdowns, rm's etc, couldn't happen, as explicit paths had to be used.. As for scripts etc, well, if you're not specifying the absolute path to any binary you're calling, you're just asking for trouble anyway! The issue is one of following policy. Debian policy doesn't allow such a resolution to this issue. Consensus on which must change, or both must change are the only allowed outcomes. 73, Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2008194814.gd30...@flying-gecko.net
Re: Is anyone maintaining (the ham radio tool) node?
On Sun, Nov 06, 2011 at 01:27:42AM -0600, Jonathan Nieder wrote: Hi, In February, I wrote[1]: Both LinuxNode (package node) and node.js (package nodejs) are designed to be accessed through the command name node. [...] If there is any way I can help, please feel free to ask. No response from the node package maintainers. My offer still stands, but I am worried that this is not going to be fixed before the next release. So, what next? Should the node package be orphaned? Based on popcon, it seems to have a small but respectable and growing number of users. Maybe if the current status of the package were more obvious, someone would start working on it (well, one can hope). Popcorn is not a definitive measure of a package's use or usefulness to a group of people. Not every machine runs popcorn. Debian maintainers, like all free software maintainers, work on what they choose to work on for their own reasons and in their own time frame. Please do not confuse a lack of updates with a lack of active maintainer(s). The upstream AX25 tools have not had much activity and for the most part do what they are designed to do. The binary on the ham radio side is not LinuxNode in package node it is simply node in package node Since you are still concerned with this issue, and neither side has shown a willingness to change, I would say the time has come for both packages to be renamed. Pat (one of the unresponsive ham radio maintainers) -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? signature.asc Description: Digital signature
Re: Is anyone maintaining (the ham radio tool) node?
On Sun, Nov 06, 2011 at 09:20:31PM -0600, Jonathan Nieder wrote: Hi Pat, Patrick Ouellette wrote: The binary on the ham radio side is not LinuxNode in package node it is simply node in package node Since you are still concerned with this issue, and neither side has shown a willingness to change, I would say the time has come for both packages to be renamed. Just to be clear: both package names are fine --- it's the names of the binaries that cause trouble. Being a user of neither package, I'd actually prefer for the name of the javascript interpreter to stay node (sorry!). It is the difference between needing to change the configuration of one superserver and needing to change the shebang line and content of many scripts. However, if the only way to include both node and nodejs in wheezy is for the interpreter binary to be renamed, too, that's ok with me. There's currently a release-critical bug against nodejs about that. You claim to not use either package, but yet you advocate for the node.js package to keep the executable name node - this is strange to me. Having a vested interest in the ham radio package retaining the name node and pointing out the history of the ham radio package being in Debian long before the node.js package, I want the ham radio package to retain the name. Apparently a consensus has not been reached, or at least not one that you recognize. In the event of no consensus, Debian policy calls for *both* packages to have their binaries renamed. You even say as much in the bug report you filed against the node package. Should the binary on the ham radio side be called ax25-node, or LinuxNode, or something like that? Given a proposed name, I would be happy enough to assume I have your blessing and start sending patches to the node bug. :) When you assume something. (if you don't know the rest of the quote, google it) Are you a ham radio operator, or do you have another reason to be interested in the eventual name of the ham radio package? There is currently a bug against the ham radio package for the binary name conflict. This is sufficient pending the outcome of the what package (if any) may retain the binary name node discussions. When the ham radio maintainers decide on how to implement the fix, they will. If you wish to join the ham radio maintainers group, we can discuss that. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007034509.gc16...@flying-gecko.net
Web host question
Anyone use micfo.com? Thoughts? Thanks, Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101026195601.gb11...@flying-gecko.net
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 01:48:03PM +0100, Ian Jackson wrote: Carl Fürstenberg writes (Re: Bug#597571: nodejs: non common executable name): Policy only states The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed.; I don't see any consensus in the thread you linked to, so technically both must change at the moment :) I wrote that bit of the policy and my intent was to try to punish people for picking stupid names. In this case, and many others, the only people punished are the Debian packagers and users. The packagers because they have to create patches to rename the binaries, and the users because the name is not the same for either package in Debian as it is on other distros. Yes, both binaries should be renamed. node is a ridiculous name for a specific-purpose executable. At this point in time I would agree. Twenty or so years ago when the ax25 software was first being developed, node adequately described the binary's function and was not so common a term. We had a similar issue not that long ago with the ax25 package listen. It had been in Debian for a long time and then someone wanted to upload something new that was also named listen. Initially the ax25 package name was kept, but later it was changed to axlisten and the (created much later) audio player was allowed to keep the name. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? signature.asc Description: Digital signature
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 03:54:41PM +0200, Mehdi Dogguy wrote: Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can stay as is. The rename would be necessary if both packages provide the same binary (same filename), which is not the case here. Actually, from the discussion in debian-hams, nodejs provides a binary named node - otherwise we would not need to have the discussion at all since there would be no conflict. -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100921140225.gb26...@flying-gecko.net
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 05:07:39PM +0200, Mehdi Dogguy wrote: On 21/09/2010 16:02, Patrick Ouellette wrote: On Tue, Sep 21, 2010 at 03:54:41PM +0200, Mehdi Dogguy wrote: Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can stay as is. The rename would be necessary if both packages provide the same binary (same filename), which is not the case here. Actually, from the discussion in debian-hams, nodejs provides a binary named node - otherwise we would not need to have the discussion at all since there would be no conflict. Wrong. nodejs's maintainer wants to rename bin/nodejs to bin/node… that's why there was the discussion on debian-hams. (But then, whether the rename is appropriate is another story… IMO, it's not appropriate because the name is too generic. And as Ian already pointed out, even node should be renamed). $ dpkg -L nodejs | grep bin/ /usr/bin/nodejs You are quick with the wrong button. The UPSTREAM nodejs is /usr/bin/node. The Debian package renamed it to nodejs. -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100921152247.ga14...@flying-gecko.net
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 05:26:30PM +0200, Mehdi Dogguy wrote: Did you say that before? I don't think so. Personally, I care about the Debian package only because the original bugreport (from where this discussion started) was against the Debian package and for a Debian specificity, not about the genericity of the name used for the shipped binary. Part of the historical discussion on debian-hams and Jéré mentioned it in this thread today. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100921160102.gb14...@flying-gecko.net
Accepted fldigi 3.20.28-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 Sep 2010 22:40:33 -0400 Source: fldigi Binary: fldigi Architecture: source amd64 Version: 3.20.28-1 Distribution: experimental Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Closes: 593349 Changes: fldigi (3.20.28-1) experimental; urgency=low . * New upstream (Closes: #593349) Checksums-Sha1: 9353bf73973c16f3bfb335649433dc169dda0ee2 1231 fldigi_3.20.28-1.dsc bcef314c4aa91eaa0f32c24e4c9dd29545a021c8 1377667 fldigi_3.20.28.orig.tar.gz bfbc997350fc4da138f0022fe280f1f17608392f 8422 fldigi_3.20.28-1.diff.gz a103bbc85bad26be675bf19e95d42d021adbbc35 1243954 fldigi_3.20.28-1_amd64.deb Checksums-Sha256: 69f910c9b677c88151eeead08c03b8af71b105a45d96c475bdceb35ca2c430c4 1231 fldigi_3.20.28-1.dsc 4f220049589f8cc8fafd6b2076656e86553be0a8fe79d29ea13ac2b4893a1707 1377667 fldigi_3.20.28.orig.tar.gz e12d7c2330d82e3f93f2f666777371194efec9f5d0cb3c6947f1de9287fe87cd 8422 fldigi_3.20.28-1.diff.gz 32a81344a7668adf842e2a250466ba2ce3e1b25eaae3b58f3c8df215a1a92126 1243954 fldigi_3.20.28-1_amd64.deb Files: 49529b2cbcb852975e603febf2f31a1f 1231 hamradio extra fldigi_3.20.28-1.dsc 1aafe98640ed45351271a78645bacf4e 1377667 hamradio extra fldigi_3.20.28.orig.tar.gz 6306d17e98b0adf3ff4c602a91012fd9 8422 hamradio extra fldigi_3.20.28-1.diff.gz 194f4d52c394aa342d925bded920dd6f 1243954 hamradio extra fldigi_3.20.28-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkyFp7YACgkQz9qdgganN25t/wCeJ9GS1A8EW3bx8jjuPprZZkD/ s/EAn2a8TZPcnUcT7g2VDkLDPOuq1PTd =jCOf -END PGP SIGNATURE- Accepted: fldigi_3.20.28-1.diff.gz to main/f/fldigi/fldigi_3.20.28-1.diff.gz fldigi_3.20.28-1.dsc to main/f/fldigi/fldigi_3.20.28-1.dsc fldigi_3.20.28-1_amd64.deb to main/f/fldigi/fldigi_3.20.28-1_amd64.deb fldigi_3.20.28.orig.tar.gz to main/f/fldigi/fldigi_3.20.28.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1osorl-jy...@franck.debian.org
Accepted fldigi 3.20.23-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 11 Aug 2010 17:13:30 -0400 Source: fldigi Binary: fldigi Architecture: source amd64 Version: 3.20.23-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Changes: fldigi (3.20.23-1) unstable; urgency=low . * new upstream Checksums-Sha1: 5e77885bdae4edd55ae2cac95bcb71db8ecbff41 1231 fldigi_3.20.23-1.dsc 8425562065875154202f4ac8420c3976f348ae46 1364267 fldigi_3.20.23.orig.tar.gz 1467dcc52c7f22c553dcb109471c24a024e27106 8437 fldigi_3.20.23-1.diff.gz 7be805296f4aacd92fe5911c884909e8d7dd6c0f 1224288 fldigi_3.20.23-1_amd64.deb Checksums-Sha256: f0030207b79fc23160b4b3117ba5adbd9b36a10ac419c8482e1b670a71b713cd 1231 fldigi_3.20.23-1.dsc fde828f221be55497e23fa5ca386fe29608934fdb84a20bf2907c8fe6c55aaec 1364267 fldigi_3.20.23.orig.tar.gz c160ea1a80a94590923ebbb892b5cbe47bb3edbb6fb17e7c69188ce2de88c395 8437 fldigi_3.20.23-1.diff.gz d5693444a1451f92f123bfd2325a3f2908b56f50001c61910e423f59ad22b839 1224288 fldigi_3.20.23-1_amd64.deb Files: 19896aeeea89059f38fa9653796e3880 1231 hamradio extra fldigi_3.20.23-1.dsc 9ae8ef32ad92071e4ad58523ec04d14b 1364267 hamradio extra fldigi_3.20.23.orig.tar.gz d7d8f2b473f44856dd45bdf1fad205bc 8437 hamradio extra fldigi_3.20.23-1.diff.gz f18c53d91048147a45d3fd34ae18ff29 1224288 hamradio extra fldigi_3.20.23-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxjE3oACgkQz9qdgganN26XEQCfZ/YKSDBvL4OotOV3+pEmtGEp lr8An1Lzl73GN4C0QEtKbV6cwoUtw6Mi =3hsa -END PGP SIGNATURE- Accepted: fldigi_3.20.23-1.diff.gz to main/f/fldigi/fldigi_3.20.23-1.diff.gz fldigi_3.20.23-1.dsc to main/f/fldigi/fldigi_3.20.23-1.dsc fldigi_3.20.23-1_amd64.deb to main/f/fldigi/fldigi_3.20.23-1_amd64.deb fldigi_3.20.23.orig.tar.gz to main/f/fldigi/fldigi_3.20.23.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ojiu9-00081t...@franck.debian.org
Accepted fldigi 3.20.20-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 23 Jul 2010 09:53:06 -0400 Source: fldigi Binary: fldigi Architecture: source amd64 Version: 3.20.20-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Changes: fldigi (3.20.20-1) unstable; urgency=low . * New upstream Checksums-Sha1: 6bf32a7007d2e9a21d134f026ceadde579dc9bb4 1231 fldigi_3.20.20-1.dsc d11b6e5fb5c5043632f7a10b426f830afcd96a23 1363237 fldigi_3.20.20.orig.tar.gz 2c0528c91756bf93a7d3bc714a9c7bb86b3b33a9 8416 fldigi_3.20.20-1.diff.gz 5d85b01f1b19c835172c7670ca8cb59182a0a7d4 1221372 fldigi_3.20.20-1_amd64.deb Checksums-Sha256: 2bb6a1d4b64db7ffae0cdf2453b6eeb3cf57badebcc3aee2d2d78cb62bdf13b0 1231 fldigi_3.20.20-1.dsc 9ac4d9be73f921f1cd7d7c461aff10ac85eacafa80ba455f9bae32fd22fe723e 1363237 fldigi_3.20.20.orig.tar.gz a0fffd5295c9ff2a21830bc08f1ed447bbd207bac888e2f4df52198577f71c54 8416 fldigi_3.20.20-1.diff.gz ba272604dc2dadc0170806a16e745b0227d57b6abc1fc7086c25993cc95de66e 1221372 fldigi_3.20.20-1_amd64.deb Files: 0d0e35a93105b45f73ac7549cd64a83e 1231 hamradio extra fldigi_3.20.20-1.dsc e03c5cc698fffd0ef93d822c555ce950 1363237 hamradio extra fldigi_3.20.20.orig.tar.gz ac12df7187320f89687d15e26f2e2bc2 8416 hamradio extra fldigi_3.20.20-1.diff.gz 5d1859b585ad93316b4eec9799d24d94 1221372 hamradio extra fldigi_3.20.20-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxJoW8ACgkQz9qdgganN2450QCfaYEiKTyAyXBXABA4pMLzx6Aa 11cAn09wDhfWt3lnm82Nd038p8Pc45LW =8xSW -END PGP SIGNATURE- Accepted: fldigi_3.20.20-1.diff.gz to main/f/fldigi/fldigi_3.20.20-1.diff.gz fldigi_3.20.20-1.dsc to main/f/fldigi/fldigi_3.20.20-1.dsc fldigi_3.20.20-1_amd64.deb to main/f/fldigi/fldigi_3.20.20-1_amd64.deb fldigi_3.20.20.orig.tar.gz to main/f/fldigi/fldigi_3.20.20.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ocjin-0003ah...@franck.debian.org
Accepted fldigi 3.20.19-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 11 Jul 2010 17:35:22 -0400 Source: fldigi Binary: fldigi Architecture: source amd64 Version: 3.20.19-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Changes: fldigi (3.20.19-1) unstable; urgency=low . * New upstream release Checksums-Sha1: 13b7ffab6f69faaeabfe223064e041bea662e3c1 1231 fldigi_3.20.19-1.dsc 939b1edbe738ad65d500f9965f01a4e02315a688 1362698 fldigi_3.20.19.orig.tar.gz ca19046028733ca3618e125ffab81849f3a95879 8400 fldigi_3.20.19-1.diff.gz 5f132d8e586e7d85656e8902205bc47212432e02 1220982 fldigi_3.20.19-1_amd64.deb Checksums-Sha256: 12ecf9e4fa767861d9879afba1ca521ba0df8cd644d494ac4c22e30e5cd43ab7 1231 fldigi_3.20.19-1.dsc 2f966ceb32454141c1e371159b2d91415ee5287ee0af3d839dc47f05c04bc752 1362698 fldigi_3.20.19.orig.tar.gz 25733f4a7dc6f2d2c2ec726bc90edd87e8ea39af3d8b2ef0323d01a484e0f8a9 8400 fldigi_3.20.19-1.diff.gz e3947f4d63dc20fafa4a57949ba1aa68ba118aec3c9cdc446f1a5c22cfc4e2b9 1220982 fldigi_3.20.19-1_amd64.deb Files: 5d528be7fb29f89c8507dd3323c93987 1231 hamradio extra fldigi_3.20.19-1.dsc 28ff29561eef2b716d2c427a618bd411 1362698 hamradio extra fldigi_3.20.19.orig.tar.gz 2888dd5fb32d88c317e5b294ae47b1aa 8400 hamradio extra fldigi_3.20.19-1.diff.gz fb07147d0c4de64c6e52600fccae540e 1220982 hamradio extra fldigi_3.20.19-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkw6RZkACgkQz9qdgganN24/+wCfRpQYrQzH4dxFwIA8zENKmvvI CO8An1pAGwxp0ZdVb4UOjFlxSFiXdbxP =vS1o -END PGP SIGNATURE- Accepted: fldigi_3.20.19-1.diff.gz to main/f/fldigi/fldigi_3.20.19-1.diff.gz fldigi_3.20.19-1.dsc to main/f/fldigi/fldigi_3.20.19-1.dsc fldigi_3.20.19-1_amd64.deb to main/f/fldigi/fldigi_3.20.19-1_amd64.deb fldigi_3.20.19.orig.tar.gz to main/f/fldigi/fldigi_3.20.19.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oy5in-0005x2...@franck.debian.org
Accepted fldigi 3.20.17-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 22 Jun 2010 14:37:26 -0400 Source: fldigi Binary: fldigi Architecture: source amd64 Version: 3.20.17-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Closes: 583894 Changes: fldigi (3.20.17-1) unstable; urgency=low . * New upstream release (Closes: #583894) * Bump standards to 3.8.4 * Update watch file to point to http://www.w1hkj.com/download Checksums-Sha1: a3878dd512359208508be2262f7a80c97441e7a6 1231 fldigi_3.20.17-1.dsc b95fb55a8e85c410bd04101e86981810541d630e 1357982 fldigi_3.20.17.orig.tar.gz 3bdd14c85e713fab9c890140b7cec3bce4f076c6 8378 fldigi_3.20.17-1.diff.gz d4f075b842e9423766502950bc4c9e5390b53394 1213470 fldigi_3.20.17-1_amd64.deb Checksums-Sha256: f7b9d8918067328e969c8db7d196b89b010c90252b6eed9a8c6380bd95799903 1231 fldigi_3.20.17-1.dsc 014c53246995747ddd617f5bd1ea73a3883be01fd8a7ed4f7228138bb0f41c17 1357982 fldigi_3.20.17.orig.tar.gz a13d26f0ad59b25e79ae58e89f7cb6513059ae7fee1c64d653471b7af9dc9cdb 8378 fldigi_3.20.17-1.diff.gz 7f3ac2c958d2fe8f37eb1a726fde9618fabeaf8b9e12a5004d0aee37e5cbf8d0 1213470 fldigi_3.20.17-1_amd64.deb Files: 6f3fac4a89cc2bc76430488314d819dd 1231 hamradio extra fldigi_3.20.17-1.dsc cc301844b05c6ee955209a401e601211 1357982 hamradio extra fldigi_3.20.17.orig.tar.gz d12d965711c3362439a3d6b42919faaa 8378 hamradio extra fldigi_3.20.17-1.diff.gz c57cd29ec84486c5063d19a57515e7ac 1213470 hamradio extra fldigi_3.20.17-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwhDnQACgkQz9qdgganN27zvACgjNIwo0LxGy96uZxa+/TTNlcd 33EAnjo0aLEEGNTPzga9M9sgUgRX85+w =Srgc -END PGP SIGNATURE- Accepted: fldigi_3.20.17-1.diff.gz to main/f/fldigi/fldigi_3.20.17-1.diff.gz fldigi_3.20.17-1.dsc to main/f/fldigi/fldigi_3.20.17-1.dsc fldigi_3.20.17-1_amd64.deb to main/f/fldigi/fldigi_3.20.17-1_amd64.deb fldigi_3.20.17.orig.tar.gz to main/f/fldigi/fldigi_3.20.17.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1or9hp-0007hu...@ries.debian.org
Accepted fldigi 3.11.6-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 15 Jul 2009 08:46:40 -0400 Source: fldigi Binary: fldigi Architecture: source i386 Version: 3.11.6-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Changes: fldigi (3.11.6-1) unstable; urgency=low . * new upstream Checksums-Sha1: c045b9ab9f73786dd16fdc45983ee88b87b8601b 1277 fldigi_3.11.6-1.dsc 050faaa3f655bacae0beae403be393100b807413 1052916 fldigi_3.11.6.orig.tar.gz a119d35ef4dd4e4b6dad420bda4b315239c568fd 9811 fldigi_3.11.6-1.diff.gz 0574391f8670e7ac3e5804d4fc02c958ecacda4e 786230 fldigi_3.11.6-1_i386.deb Checksums-Sha256: e1032925ddcc567f2fe3e6464d6ca353a88db793e0bc56703b3dd6afa45f9181 1277 fldigi_3.11.6-1.dsc fa08918d2cd25117c6cbcdbcb5b753f580eeb510d83adf88c0438bea3d990d53 1052916 fldigi_3.11.6.orig.tar.gz ea45dcc45ecded06acfa45d3ed0c4725a4afd025440a54f18054738f09355e4d 9811 fldigi_3.11.6-1.diff.gz 5f9ad125016ad62be2579e7fb022d9f6cd76a776ebe88d7586e4e854f98f1385 786230 fldigi_3.11.6-1_i386.deb Files: 70f6c7cd7a195267f391bd379333bf7e 1277 hamradio extra fldigi_3.11.6-1.dsc 912ddc303ca54b9e41e8c271c6160bbc 1052916 hamradio extra fldigi_3.11.6.orig.tar.gz ebc2311056ac7f42dcd03765f75eaf93 9811 hamradio extra fldigi_3.11.6-1.diff.gz baa804917acd3afdcd0d8976305f14f8 786230 hamradio extra fldigi_3.11.6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpd3OkACgkQz9qdgganN27QugCgl/UfcjcPsw0UCPcSsUDfbLXK lsMAn3+qgd7hqOespjKsIHFULQIpAStK =vJDH -END PGP SIGNATURE- Accepted: fldigi_3.11.6-1.diff.gz to pool/main/f/fldigi/fldigi_3.11.6-1.diff.gz fldigi_3.11.6-1.dsc to pool/main/f/fldigi/fldigi_3.11.6-1.dsc fldigi_3.11.6-1_i386.deb to pool/main/f/fldigi/fldigi_3.11.6-1_i386.deb fldigi_3.11.6.orig.tar.gz to pool/main/f/fldigi/fldigi_3.11.6.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted fldigi 3.11.4-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 13 Jun 2009 21:57:44 -0400 Source: fldigi Binary: fldigi Architecture: source i386 Version: 3.11.4-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Closes: 525712 530938 Changes: fldigi (3.11.4-1) unstable; urgency=low . * New upstream release (Closes: #530938) * Upstream fixed FTBFS with gcc-4.4 (Closes: #525712) Checksums-Sha1: 5510ab4b531c8c43d3d429c7ceb22c951cadcc18 1277 fldigi_3.11.4-1.dsc 3b3b273bb90f8992800ac7b1978755843579ab1d 1035414 fldigi_3.11.4.orig.tar.gz 772ff4a19d974b11333aa36dff6737569cf7418f 5448 fldigi_3.11.4-1.diff.gz d01381bc1deec4d2a056b4fd06dca67859b9a143 766724 fldigi_3.11.4-1_i386.deb Checksums-Sha256: eb5718120c5a95c43693fb36c834cacf52ba1a0152e2988c82df09df4ff0b1a4 1277 fldigi_3.11.4-1.dsc 1614d6720994a5b794d50b05d95dfd1f1cc556fcd500352f0203daeae88be0dd 1035414 fldigi_3.11.4.orig.tar.gz 40fbad4803f436a764b7380f4e71743da94d94ea0239ff689425b385a0c41a43 5448 fldigi_3.11.4-1.diff.gz 1b82451af3ad2324147893b2a8dd59a2a313361311806cedcb9fe41b7e2e20aa 766724 fldigi_3.11.4-1_i386.deb Files: d770502aadb4b8c194920885a975a8b7 1277 hamradio extra fldigi_3.11.4-1.dsc 85457a57ac97210ee23299ccf25e5c60 1035414 hamradio extra fldigi_3.11.4.orig.tar.gz cc34d0f8b93145b1523972b60dd4e30f 5448 hamradio extra fldigi_3.11.4-1.diff.gz 3f23a0ab09f7f993931a10f613d907c9 766724 hamradio extra fldigi_3.11.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko0WxsACgkQz9qdgganN24FhACgu1L1RIVih66iwStLmu19JVoT MwgAniwInMIeB0vIDQTpCFzn98T0hWo9 =8bvc -END PGP SIGNATURE- Accepted: fldigi_3.11.4-1.diff.gz to pool/main/f/fldigi/fldigi_3.11.4-1.diff.gz fldigi_3.11.4-1.dsc to pool/main/f/fldigi/fldigi_3.11.4-1.dsc fldigi_3.11.4-1_i386.deb to pool/main/f/fldigi/fldigi_3.11.4-1_i386.deb fldigi_3.11.4.orig.tar.gz to pool/main/f/fldigi/fldigi_3.11.4.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DebConf10 to take place in New York City, USA
With respect to visa issues, early application is always a good ideal. I work for a US government agency that hosts international guests for training three to four times a year. We usually don't know who is going to show up until we actually see the people arrive on the first day of training. This is usually due to trying to rush the visa process. If someone *thinks* they want to attend DebConf10, I suggest they commit to attending and apply for a visa sooner rather than later. It just makes things easier. This advice applies anytime a visa is needed to visit any country, not just the USA. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO Crank the amp to 11, this needs more cowbell - and a llama wouldn't hurt either Your arguments are an odd mix of overly optimistic on one side and overly pessimistic on the other -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted fldigi 3.10-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 20 Feb 2009 22:10:46 -0500 Source: fldigi Binary: fldigi Architecture: source i386 Version: 3.10-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org Changed-By: Patrick Ouellette poue...@debian.org Description: fldigi - digital modem program for hamradio operators Changes: fldigi (3.10-1) unstable; urgency=low . * New upstream release Checksums-Sha1: 45eddb01ab24cdd649765809efa00cea6d0d71f2 1260 fldigi_3.10-1.dsc b64ea45aad2b87b9eab750ea2b8bf0e8cb5de71f 944266 fldigi_3.10.orig.tar.gz f41f3a92cfac6f2eab78819dcb7b8889804ef81d 5381 fldigi_3.10-1.diff.gz 71e058d7e05124f84f397c9d877e6cfed2b2fa8e 707348 fldigi_3.10-1_i386.deb Checksums-Sha256: fc27e40ab91a2280b5a1fe0433bbd427848595ed4672369e54a5c6da8612e81d 1260 fldigi_3.10-1.dsc e8e6872bd93a04d90cebcf93ef62055f2d20e7a9e7a69d2f0e61d2b3dcc4b760 944266 fldigi_3.10.orig.tar.gz a2bf4adfe438895a22ad052feba292c45dec5af8922ba9cef523e6a57b14691f 5381 fldigi_3.10-1.diff.gz e3f4cfae0f9e2996339666dc579494b592d3fc06e2d6b8b9da39dadc90c9f286 707348 fldigi_3.10-1_i386.deb Files: 1a0e5973339fc1ecfd366e9537b08e29 1260 hamradio extra fldigi_3.10-1.dsc dd00a04b6134aeefa8431ce19a97dbf0 944266 hamradio extra fldigi_3.10.orig.tar.gz 87facedd378881fb7a8895d8946cd03e 5381 hamradio extra fldigi_3.10-1.diff.gz d7a56f419110d056d709723475bf5b7e 707348 hamradio extra fldigi_3.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmgmZsACgkQz9qdgganN25GJACgigtQ8NYp0aXmmWQgBSajZlvS 4LcAoJ27pzq//0EG2wUoSnBAHYi7GrMl =djww -END PGP SIGNATURE- Accepted: fldigi_3.10-1.diff.gz to pool/main/f/fldigi/fldigi_3.10-1.diff.gz fldigi_3.10-1.dsc to pool/main/f/fldigi/fldigi_3.10-1.dsc fldigi_3.10-1_i386.deb to pool/main/f/fldigi/fldigi_3.10-1_i386.deb fldigi_3.10.orig.tar.gz to pool/main/f/fldigi/fldigi_3.10.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted fldigi 2.10.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Mar 2008 13:39:21 -0400 Source: fldigi Binary: fldigi Architecture: source i386 Version: 2.10.1-1 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers [EMAIL PROTECTED] Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: fldigi - digital modem program for hamradio operators Changes: fldigi (2.10.1-1) unstable; urgency=low . * New upstream release * added support for pulseaudio Files: 66f0c85f66186a3ce26ca9e9a8620e2f 904 hamradio extra fldigi_2.10.1-1.dsc 7876fad6982bc64c0f5f88398548381b 640274 hamradio extra fldigi_2.10.1.orig.tar.gz 3511ebee14ba821b3c54d02303c47613 5124 hamradio extra fldigi_2.10.1-1.diff.gz c9f73fe01f752f29edc37cc3584a5293 428616 hamradio extra fldigi_2.10.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH5UZdz9qdgganN24RAoatAJ0ebIOOZqT5q+iS6yGeTaeFF+mDrQCeN1rG A/0xLUSzOdd2GTOLQeKPj+E= =vDy2 -END PGP SIGNATURE- Accepted: fldigi_2.10.1-1.diff.gz to pool/main/f/fldigi/fldigi_2.10.1-1.diff.gz fldigi_2.10.1-1.dsc to pool/main/f/fldigi/fldigi_2.10.1-1.dsc fldigi_2.10.1-1_i386.deb to pool/main/f/fldigi/fldigi_2.10.1-1_i386.deb fldigi_2.10.1.orig.tar.gz to pool/main/f/fldigi/fldigi_2.10.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Stable Distro
On Wed, Mar 01, 2006 at 08:19:01AM -0700, Joseph Smidt wrote: To the Debian Developers, Again I am writing to mearly throw an idea out on the floor. It has to deal with the stress of having release date to cram for, as well as being accused of being a distro that never has up-to-date software in stable. I think you could solve this with a pre-stable distro. This is how it would work: Packages are continuosly being uploaded into unstable where active development is taking place. When they reach a low enough RC count and have served their time in unstable they are uploaded into testing. Here is where things would be different: Once every three months the new Pre-Stable distro will upload only those packages from testing that have had 0 RC bugs for at least month and have been flagged by their maintainers as a good version to entet stable. These packages will be uploaded into a current copy of stable where they will be tested agiasnt the current stable for three months. At the end of each month along the way, those packages that have not been able to survive being with stable packages without having an RC bug will be dropped. Those packages who survive for three whole months will be uploaded into stable. The upload would then be like a mini new release. Advantages for those using stable: 1. They get new packages without having to wait years for them. 2. Since this process repeats itself every three months the uploads will be very predictable, unlike testing which has uploads every day. 3. These packages will have had zero RC bugs for at least four months straight with three of those months being tested against the current stable snapshot. 4. These packages will have been flagged by their maintainers showing these are good versions of the packages, ie, the maintainers know -1 and -2 may not be ready for stable despite RC count and maybe -3 is better than -4. Advantages for developers: 1.) There will not be the stress of worrying about release dates. The packages are readywhen they are ready, and will enter stable accordingly. 2.) They will be harassed less for taking so long for a major release. Disadvantages: 1.) Many may argue we don't need another Distro, we already have three, four if you include experimental. ( I can already see responses sarcastically suggesting we should have 20 or 30 distros.) 2.) Maybe it is not reliable to release pieces of a distro every three months. (However, if the upload would damage anything in stable it would surely be caught in three months.) 3.) Security issues. 4.) Tradition: (See Fiddeler on the Roof) Anyways, I again want to repeat it is only a suggestion. I would not want Debian to do anything that would hurt Debian. However if it would help, all the better. I wish you all the best. I suggested something kind of similar a while ago. Google the Debian archives for temporal release. Not much interest in it overall, and I ran into time problems setting up the infrastructure to list which packages would be in the pre-stable and stable branches (in your terms). I might return to that in the next few months once real life settles down.. -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM Living life to a Jimmy Buffett soundtrack Crank the amp to 11, this needs more cowbell - and a llama wouldn't hurt either -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Mon, Apr 18, 2005 at 07:37:40PM -0500, Gunnar Wolf wrote: 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? Yes, that is true. It will take time for the fix to work through the system, and there is also the possibility of finding additional RC bugs in the candidate version that further delay the cycle. That's how the iterative develop-test-release cycle works. 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? If that is indeed the case, no software would ever be released. The trick is to make the number of known RC bugs at the time a package moves from one stage to the next 0. If a bug truly is release critical, then that package should not be in the release while it is known to contain that bug. Pat -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote: The problem is that for many transitions, slowly means never, since the criteria you set are unlikely to be fulfilled for all parts of such a transition at any time in the future. And the more time passes, it becomes more and more complicated since additional transitions might be interdependent with a transition making the problem even more complicated. You are very good at repeating this will never work. You are essentially saying it is impossible for a package to have no RC bugs, and that those bugs are never going to be fixed fast enough to progress through the quality control system I proposed. I have a bit more faith in my fellow Debian Developers than that. I admit that the candidate phase will change more slowly than testing - it is supposed to. The stable (or whatever it is called - maybe production) section will change even more slowly. This is by design. I am proposing a system that removes some of the arbitrary nature of what we call a stable package. I'm proposing that we define QUALITY CONTROL standards that ALL packages adhere to so that when someone says they recommend Debian's testing/candidate/stable release, they can point to a testing system that allows the person to select which branch they use based upon well know published criteria for the stability of that particular branch. The user controls the amount of risk they are willing to have in their system. That's already true today. People who like the latest software can choose between unstable and testing with testing usually having a bit less known bugs. People who want stability use stable. It is not true today. What is true is people who are not running hardware less than 36 (or so) months old have the option of running stable (the kernel shipping and included with stable just does not have drivers for new hardware). This has been a perpetual problem. People who need a stable distribution should not be forced to use testing or unstable because they have hardware that is only 18 months old, especially when you consider the pace of change in computer hardware manufacturing. The reality today is people who have older hardware can choose to run Debian stable. People with newer but by no means cutting edge hardware do not have the option of installing stable. They can choose testing or unstable. People who want security updates from the Debian security team must run stable. If you want security fixes and have newer hardware, you must run unstable (and hope the maintainer uploads a fixed version quickly) or patch the testing packages yourself. People are not able to choose by their desired comfort level of stability. If anything, my proposal might allow people to choose which version they want to run based on their desired level of stability - instead of what will run on their hardware. Testing, candidate and stable should change progressively slower. That is the entire point. As I am trying to explain, the speed of changes to stable will sonn become zero. The speed of changes to stable is currently zero. Debian does not have to do anything to maintain that. My proposal would at the very least change that from zero to glacially slow, with the option to pick a version that changes slow, fast, or continuously. If you believe your approach would work, please try the following: Take stable from today, and make this your candidate. Take testing from today. Actually, I am planning on working on that this weekend. I was not going to start with the current stable, but with the current testing. I will be building a candidate list by using my proposed rules (0 RC bugs, 3 months or more in testing). I will build a new stable from the candidate list with those packages that have been in testing 6 or more months with 0 RC bugs. It will be interesting to see how many required, base, standard, and optional packages meet the standard I propose. Create a complete list of all packages that have to go from testing into your candidate _at the same time_ for getting e.g. the tiff transition into your candidate. If after this you do still believe your approach would work, please send the complete list of packages you think would be involved in this one transition (to let me check whether you missed some - they are much more than hundred), and explain at which time of the future you expect every single package in the list to fulfill your criteria at the same time. I will publish the results on my people.Debian.org page at http://people.debian.org/~pouelle/temporal_release.html Look for that URL to be updated by 13:00 25-APR-2005 UTC I will not be able to explain at which time I expect a particular package to meet the standards since I don't maintain each and every package in Debian. Debian always releases when it's ready and I don't expect that to change. Pat -- Patrick
Re: Temporal Release Strategy
On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote: The rules and goals of testing are clear. The more interesting points are the problems of testing that several years of using it have shown. If package FOO has a RC bug, then everything that depends on FOO will be stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed. If fixing FOO breaks BAR, then they all wait again until BAR is fixed. Use of experimental to work through some of these issues would help. I'm not saying it won't take manual coordination to handle complex changes to the system. I'm not saying it will make anyone's life easier. What my proposal will do is provide the ability to decide when package $PACKAGE makes it into stable, we will call that an official release and give it a number. Alternatively, you could declare every $INTERVAL Debian releases. What is in stable should have been well tested, and supportable. Stable no longer is a static concept, but a slowly evolving thing. If you cannot wrap your mind around to accepting a stable that evolves, we could snapshot stable at release data and make a separate archive (really a Packages.gz and related files as long as the version of the package in the release exists in the package pool). You completely miss my point: There are several transitions every month, and a big transition can involve several hundred packets. Your proposal requires, that _every single_ package that is part of a transition has to be both ready and in testing for over 3 months before it can enter your proposed candidate. If _one_ of the packages that is part of a transition is updated in testing during this time, the 3 months start again. For bigger transitions, it's therefore practically impossible that they will be able to enter your candidate. I don't believe I missed your point, you just don't seem to be able to grasp the fact that I intend candidate to change slowly. Yes, I am proposing that every package involved in a transition be of adequate quality to be promoted to candidate. The purpose of the entire release system is to ensure the quality of the Debian distribution. Debian releases when it's ready because Debian demands a certain minimum level of quality (currently defined as an arbitrary number of RC bugs in packages of variable importance in the distribution as seen by the release manager). I'm proposing a system that allows when it's ready to be defined and automated. Our current release system places an enormous burden on the release manager. Please try to understand the limitations of testing before proposing something even stricter. I understand the limitations of testing. In fact, I am depending on the limitations of the testing rules to ensure that candidate is of adequate quality and changes slowly enough to be used on desktop workstations and that stable is adequate for servers. I am proposing a system that removes some of the arbitrary nature of what we call a stable package. I'm proposing that we define QUALITY CONTROL standards that ALL packages adhere to so that when someone says they recommend Debian's testing/candidate/stable release, they can point to a testing system that allows the person to select which branch they use based upon well know published criteria for the stability of that particular branch. The user controls the amount of risk they are willing to have in their system. Testing, candidate and stable should change progressively slower. That is the entire point. Pat -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
arbitrarily decided to release it does not mean it is not there. If a bug requires an unlikely set of events to coincide before it is triggered, it could be YEARS after the software is released before the right set of conditions happens. kind of problems that can occur every day in sarge _are_ dangerous problems. The kind of bugs yet undiscovered in testing and stable are also dangerous, but not as dangerous as believing all the major bugs are caught in testing. How many security updates have been issued for packages in stable since it was released? Here there be dragons. It is not about presenting a bug free distribution, but about managing the risks associated with the bugs that may be undetected at the time the release is released. I believe a second stage between testing and stable would allow better management of that risk, by providing an almost frozen area where further testing of packages would be able to take place. The natural progression is then to declare those packages production quality at some point in time after they entered the candidate stage. If you really believe the package to be production quality, you should have no problem calling it stable. Pat -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
of Debian (where stability is defined as lack of bugs, not software that never changes except for security updates), as well as further enhance the reputation Debian maintains in the community. In many ways, current testing is your stable. Extending the testing period from testing to your proposed candidate and then stable would do nothing about normals bugs. RC bugs are usually found quite quickly by people using unstable. If RC bugs are found so quickly in unstable, why has there been no release in the last 3 or so years? Testing is normally quite usable. That is part of the reason I believe this type of approach to releases would work. Pat -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Thu, Apr 14, 2005 at 11:59:52PM +0200, Adrian Bunk wrote: On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote: ... 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. ... One big problem testing has are transitions. This includes library transitions, but also other transitions like e.g. an ocaml transition affecting several dozen packages currently waiting to enter testing. Many transitions require a serious amount of manual coordination since all packages have to be ready to go into testing _at the same time_. Please explain how you think any bigger transition can ever enter your candidate if you add to the testing criteria a 3 months criteria all affected packages have to fulfill at the same time? The system should always be considered a FIFO system. There are only 2 places packages can enter the system: unstable, and security-updates. The coordination of dependent packages will always require manual coordination. There is no way around it (unless you completely automate the build process so it downloads the upstream tar ball and packages it for Debian - and never breaks). The purpose of unstable is to allow those problems to be worked out. Once the group of interdependent packages is ready (managed to live in unstable for 10 days without a release critical bug) then they will all meet the criteria set to be promoted to testing. The same thing happens again. Once the entire group satisfies the conditions, the entire group migrates to candidate. The point of having the promotion conditions is to make sure the system is not broken, and can handle library or interdependent package version changes. The rules I referred to are found here: http://www.debian.org/devel/testing If package FOO has a RC bug, then everything that depends on FOO will be stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed. If fixing FOO breaks BAR, then they all wait again until BAR is fixed. Use of experimental to work through some of these issues would help. I'm not saying it won't take manual coordination to handle complex changes to the system. I'm not saying it will make anyone's life easier. What my proposal will do is provide the ability to decide when package $PACKAGE makes it into stable, we will call that an official release and give it a number. Alternatively, you could declare every $INTERVAL Debian releases. What is in stable should have been well tested, and supportable. Stable no longer is a static concept, but a slowly evolving thing. If you cannot wrap your mind around to accepting a stable that evolves, we could snapshot stable at release data and make a separate archive (really a Packages.gz and related files as long as the version of the package in the release exists in the package pool). Pat -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
On Fri, 2005-04-15 at 21:48 -0500, Adam M. wrote: Unfortunately this totally changes the purpose of stable. Stable is Yes and no. It changes the concept of stable in that stable evolves. You still have the static release as long as we decide to keep that version of all the packages in the package pools. The implementation of package pools created a virtual release environment where the release in the archives is only defined by the contents of the Packages file at the time of release. This has a few disadvantages and advantages. The main advantages include, * less time spent on maintaining your production machines - once you set them up, no need to change the configs. * ability to maintain 1000s of installations by one person - installing a new machine can be as simple as `dd` the partition. * security fixes do not break your system (3rd party applications or otherwise) You can still have this environment. As long as your system looks at the Packages file from the release (and the security updates Packages file). The main disadvantage of this is that stable becomes stale. The current testing is a remedies for this problem. Up-to-date packages are provided in testing where the packages are virtually always production quality. The main disadvantage of testing is lack of environmental stability seen in stable. Testing does not remedy this problem. If testing was virtually always production quality then there would be no need for the release manager to go through an elaborate freeze bug fix cycle to get things in shape for a release. The only difference between the support of testing vs. stable in Debian is security support. If we have volunteers for the security team for testing (for Etch), then I'm certain Debian can have two release modes, 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. We should not destroy the notion of stable to get up-to-date packages. I'm not trying to destroy the notion of stable, I have a different definition of stable. My definition of stable is software that does what it is designed to do without bugs, in the manner in which the designer and programmer intended. I'm also trying to show that the traditional concept of a release in Debian is outdated. I will even go so far as to say the reason Debian has had exponentially longer release cycles is that the traditional concept of a release is flawed for a project the size and scope of Debian. We need to adjust our thinking outside the traditional definitions. I think this proposal could actually enhance the stability of Debian (where stability is defined as lack of bugs, not software that never changes except for security updates), as well as further enhance the reputation Debian maintains in the community. Pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ax25-apps 0.0.6-9 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Apr 2005 14:06:32 -0400 Source: ax25-apps Binary: ax25-apps Architecture: source i386 Version: 0.0.6-9 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-hams@lists.debian.org Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: ax25-apps - AX25 ham radio applications Changes: ax25-apps (0.0.6-9) unstable; urgency=low . * Changed maintainer to debian-hams@lists.debian.org * Changed uploaders to Jaime Robles [EMAIL PROTECTED], Joop Stakenborg [EMAIL PROTECTED], Patrick Ouellette [EMAIL PROTECTED], Hamish Moffatt [EMAIL PROTECTED], Ramakrishnan Muthukrishnan [EMAIL PROTECTED] Files: 42c7523a59f68b5a6ddde51026b32ee0 873 hamradio extra ax25-apps_0.0.6-9.dsc d849d177418071a79427312674cf6765 12411 hamradio extra ax25-apps_0.0.6-9.diff.gz 39bacee2d160a26250f439d90d56d90d 95694 hamradio extra ax25-apps_0.0.6-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCXrLTz9qdgganN24RAl3rAKCjWMAgc07PR4R6+I/5uKBeBs1jswCgrojC qYofMfKMCTfft5prPUaZM/o= =b29b -END PGP SIGNATURE- Accepted: ax25-apps_0.0.6-9.diff.gz to pool/main/a/ax25-apps/ax25-apps_0.0.6-9.diff.gz ax25-apps_0.0.6-9.dsc to pool/main/a/ax25-apps/ax25-apps_0.0.6-9.dsc ax25-apps_0.0.6-9_i386.deb to pool/main/a/ax25-apps/ax25-apps_0.0.6-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ax25-tools 0.0.8-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Apr 2005 14:03:24 -0400 Source: ax25-tools Binary: ax25-tools ax25-xtools Architecture: source i386 Version: 0.0.8-7 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-hams@lists.debian.org Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: ax25-tools - AX-25 tools ax25-xtools - AX-25 tools (X versions) Changes: ax25-tools (0.0.8-7) unstable; urgency=low . * Changed maintainer to debian-hams@lists.debian.org * Changed uploaders to Jaime Robles [EMAIL PROTECTED], Joop Stakenborg [EMAIL PROTECTED], Patrick Ouellette [EMAIL PROTECTED], Hamish Moffatt [EMAIL PROTECTED], Ramakrishnan Muthukrishnan [EMAIL PROTECTED] * Fixed lintian warnings about copyright file reference * Added reference to original source (a25.sf.net) to copyright file Files: d024071a5a93d4b1f996af8ca053b437 950 hamradio extra ax25-tools_0.0.8-7.dsc b8676ae5694ec2366800479677402cc6 7860 hamradio extra ax25-tools_0.0.8-7.diff.gz f3a2e4d77cd40427e99df36089288fc9 219280 hamradio extra ax25-tools_0.0.8-7_i386.deb b53ebb1bd893ca8046389c68f7fe471d 38646 hamradio extra ax25-xtools_0.0.8-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCXrTsz9qdgganN24RAuWTAJ9KiVsyFx0Tw9Zo8T0ODTfDpIYpGACfXFCH OB2WH0zMtWMF0ZXWyTJRK3A= =lTBG -END PGP SIGNATURE- Accepted: ax25-tools_0.0.8-7.diff.gz to pool/main/a/ax25-tools/ax25-tools_0.0.8-7.diff.gz ax25-tools_0.0.8-7.dsc to pool/main/a/ax25-tools/ax25-tools_0.0.8-7.dsc ax25-tools_0.0.8-7_i386.deb to pool/main/a/ax25-tools/ax25-tools_0.0.8-7_i386.deb ax25-xtools_0.0.8-7_i386.deb to pool/main/a/ax25-tools/ax25-xtools_0.0.8-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libax25 0.0.11-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Apr 2005 13:37:17 -0400 Source: libax25 Binary: libax25 libax25-dev Architecture: source i386 Version: 0.0.11-3 Distribution: unstable Urgency: low Maintainer: Debian Hamradio Maintainers debian-hams@lists.debian.org Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: libax25- ax25 library for hamradio applications libax25-dev - ax25 library development files Changes: libax25 (0.0.11-3) unstable; urgency=low . * Changed maintainer to debian-hams@lists.debian.org * Changed uploaders to Jaime Robles [EMAIL PROTECTED], Joop Stakenborg [EMAIL PROTECTED], Patrick Ouellette [EMAIL PROTECTED], Hamish Moffatt [EMAIL PROTECTED], Ramakrishnan Muthukrishnan [EMAIL PROTECTED] Files: e481d3fe0159e6b04bbaa8a51c6affea 833 hamradio optional libax25_0.0.11-3.dsc 717a8fecf009af74680f5f6e0e334070 2993 hamradio optional libax25_0.0.11-3.diff.gz 58baf21224e0d9a3ca2d0f451b1d226d 23750 hamradio optional libax25_0.0.11-3_i386.deb 66d82bb9e7884d498a39faafd1f6f312 27480 hamradio optional libax25-dev_0.0.11-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCXrMAz9qdgganN24RAu/5AJ0eE5+ul2bsI5o1GhdvXL3sRAwl7gCeNyf9 lDROLTZQzDRhXDR/S2gdZzg= =DyL9 -END PGP SIGNATURE- Accepted: libax25-dev_0.0.11-3_i386.deb to pool/main/liba/libax25/libax25-dev_0.0.11-3_i386.deb libax25_0.0.11-3.diff.gz to pool/main/liba/libax25/libax25_0.0.11-3.diff.gz libax25_0.0.11-3.dsc to pool/main/liba/libax25/libax25_0.0.11-3.dsc libax25_0.0.11-3_i386.deb to pool/main/liba/libax25/libax25_0.0.11-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 2005-02-22 at 04:39 +, Dirk Eddelbuettel wrote: For your convenience, I quote the numbers here again along with a quick percentage calculation: md - read.table(/tmp/md.txt, header=TRUE, row.names=1) md - cbind(md, percent=round(100*md[,1]/md[total,1], 4)) md files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. The problem with these numbers is the architecture all. over 27% of files downloaded don't count since you don't know what systems they are running on. -- Patrick Ouellette [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted seesat5 0.90.10-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 18 Apr 2004 14:30:54 -0400 Source: seesat5 Binary: seesat5 Architecture: source i386 Version: 0.90.10-1 Distribution: unstable Urgency: low Maintainer: Patrick Ouellette [EMAIL PROTECTED] Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: seesat5- a satellite location program Closes: 216541 216543 235300 Changes: seesat5 (0.90.10-1) unstable; urgency=low . * new maintainer Closes: #235300 * fixed minor policy violation package now not Debian native Closes: #216541 * updated to standards version 3.6.1 * gzipped man pages Closes: #216543 * upstream created a separate changelog, please see the package's changelog for changes prior to this version Files: 45af3fb723491a64e28b21780f0a4d75 468 math extra seesat5_0.90.10-1.dsc dab99c23c4c3527932fbccacd41b7988 115708 math extra seesat5_0.90.10-1.tar.gz ae61a25f16657438ad0ce75f91cd484d 93658 math extra seesat5_0.90.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgtDaz9qdgganN24RAkF0AKDGT9aplFvlLE9huFPHelIzA1Q6zACgtRqx 0XuowQ9dRsm6uw5XFXMIRu8= =2niU -END PGP SIGNATURE- Accepted: seesat5_0.90.10-1.dsc to pool/main/s/seesat5/seesat5_0.90.10-1.dsc seesat5_0.90.10-1.tar.gz to pool/main/s/seesat5/seesat5_0.90.10-1.tar.gz seesat5_0.90.10-1_i386.deb to pool/main/s/seesat5/seesat5_0.90.10-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted opt 3.19-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 23 Dec 2003 13:41:48 -0500 Source: opt Binary: opt Architecture: source i386 Version: 3.19-1 Distribution: unstable Urgency: low Maintainer: Patrick Ouellette [EMAIL PROTECTED] Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: opt- Options Parsing Tool library Changes: opt (3.19-1) unstable; urgency=low . * new upstream version * updated to policy 3.6.1 * removed shared from short description * cool with NMU updates (Closes #173912) * removed dh_suidregister call * moved removal of info docs from postrm to prerm * updated debian/copyright file for http download and dual copyright notice Files: d2992204b171bc60a51fc18ed9d302da 536 devel optional opt_3.19-1.dsc 9ba0d4701b3160055e6280c60b8a6702 216621 devel optional opt_3.19.orig.tar.gz 3e4a48be38fd402fac749090a53875c4 2994 devel optional opt_3.19-1.diff.gz ca9379c02205853584b8f66db1bb3b52 75532 devel optional opt_3.19-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAH/58z9qdgganN24RAsbHAJ9rHzif2jWeBZqubqDafNYbIaSoYQCfamle mVPY7gPwufmzvtCjuZtej2o= =FNw8 -END PGP SIGNATURE- Accepted: opt_3.19-1.diff.gz to pool/main/o/opt/opt_3.19-1.diff.gz opt_3.19-1.dsc to pool/main/o/opt/opt_3.19-1.dsc opt_3.19-1_i386.deb to pool/main/o/opt/opt_3.19-1_i386.deb opt_3.19.orig.tar.gz to pool/main/o/opt/opt_3.19.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 11:55:26AM -0800, Tom wrote: instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a Instead of a smartcard/token/whatever physical device, this incident could possibly have been thwarted by requiring developers to pre-register their machine with the project (using ssh host key for example). The attacker would have the user's account information, but project machines would have refused access since the host id did not match the user's registered hosts. Then the project machine could have alerted both the project's admin team and the owner of the compromised account. The initial compromise would have been detected sooner, and project machines protected *without* any additional hardware or money being spent. -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM
Authentication enhancements (was Re: Backport of the integer overflow in the brk system call)
On Mon, Dec 08, 2003 at 01:28:20PM +1100, Russell Coker wrote: But this still leaves the issue of how to deal with dial-up machines. Even if we restrict connections to a single ISP as often dial-up machines are not used with multiple machines, this still isn't necessarily much good, some dial-up ISPs have 50,000 IP addresses. Your other very good points not withstanding, I was thinking along the lines of the user's id substituting for the ip address in the verification process. User authentication would require a matched user id host id or a warning would be triggered. I didn't claim it was a perfect solution, I don't even claim it as a *good* solution. It would be another layer of checks in the authentication process, with the benefit of not costing much in terms of money. Finally, if the attacker can compromise the machine and the machine is online (EG permanently connected machines) there's no good options. That is true for many of the suggested additions. Once a trusted machine is compromised, it's game over. My suggestion would only send up a flag if the attacker attempted to access project machines from a host the user had not registered (assuming he did not know enough to steal the host's key first). If we could tie the host key to a unique property of the physical host it would help. In any event, I think there is merit in requiring a user / host authentication pair if we can come up with a method of tying the host key to the hardware. I would be willing to work on such a task, if others also think it might have merit. -- Patrick Ouellette [EMAIL PROTECTED] [EMAIL PROTECTED] Amateur Radio: KB8PYM
Accepted libax25 0.0.10-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 19 Feb 2003 23:38:44 -0500 Source: libax25 Binary: libax25 libax25-dev Architecture: source i386 Version: 0.0.10-3 Distribution: unstable Urgency: low Maintainer: Patrick Ouellette pouelle@xx Changed-By: Patrick Ouellette pouelle@xx Description: libax25- ax25 libraries for hamradio applications libax25-dev - ax25 library development files Closes: 181880 181881 Changes: libax25 (0.0.10-3) unstable; urgency=low . * fixed separation of headers and man pages between libax25 and libax25-dev (closes: #181880, #181881) Files: f8bc1e2cd1fa978c55523a86c206018b 607 hamradio optional libax25_0.0.10-3.dsc 9fcce9c4afb8a8b77cec50cb92c25444 90333 hamradio optional libax25_0.0.10-3.diff.gz ddc9a36bba263b2e577c105fef186486 22582 hamradio optional libax25_0.0.10-3_i386.deb ac26a2a8e7ff54f22ec10e22fbb84e58 26222 hamradio optional libax25-dev_0.0.10-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Vl71z9qdgganN24RAj6MAJ9yUmKk8PTZ2Gz1LGiXtKX3E0+OPwCfTcKc Yrs9D6K/xm3EVm1JIigXClM= =xlme -END PGP SIGNATURE- Accepted: libax25-dev_0.0.10-3_i386.deb to pool/main/liba/libax25/libax25-dev_0.0.10-3_i386.deb libax25_0.0.10-3.diff.gz to pool/main/liba/libax25/libax25_0.0.10-3.diff.gz libax25_0.0.10-3.dsc to pool/main/liba/libax25/libax25_0.0.10-3.dsc libax25_0.0.10-3_i386.deb to pool/main/liba/libax25/libax25_0.0.10-3_i386.deb -- To UNSUBSCRIBE, email to debian-devel-changes-request@ with a subject of unsubscribe. Trouble? Contact listmaster@
Accepted libax25 0.0.10-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 20 Sep 2002 11:28:45 -0400 Source: libax25 Binary: libax25 libax25-dev Architecture: source i386 Version: 0.0.10-2 Distribution: unstable Urgency: low Maintainer: Patrick Ouellette [EMAIL PROTECTED] Changed-By: Patrick Ouellette [EMAIL PROTECTED] Description: libax25- ax25 libraries for hamradio applications libax25-dev - ax25 library development files Closes: 159284 Changes: libax25 (0.0.10-2) unstable; urgency=low . * added postrm script to remove /etc/ax25 directory when purging package (closes: #159284) Files: 435ea90a031c9b46c710fa30c09c91b4 607 hamradio optional libax25_0.0.10-2.dsc 4a36e99c355965b7e8e9f6e42c7f7025 90293 hamradio optional libax25_0.0.10-2.diff.gz eda0a9c4ee48f40124409bc1f973181e 31664 hamradio optional libax25_0.0.10-2_i386.deb f1a0a812e72854aff9c675a7405d1f96 28564 hamradio optional libax25-dev_0.0.10-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+VCJOz9qdgganN24RAg0RAJwNo93gvYkkH+PTWGSSfNEBTSId8gCdFyrw JkYpdL3IeKe1fEZEFZVPsNo= =94xC -END PGP SIGNATURE- Accepted: libax25-dev_0.0.10-2_i386.deb to pool/main/liba/libax25/libax25-dev_0.0.10-2_i386.deb libax25_0.0.10-2.diff.gz to pool/main/liba/libax25/libax25_0.0.10-2.diff.gz libax25_0.0.10-2.dsc to pool/main/liba/libax25/libax25_0.0.10-2.dsc libax25_0.0.10-2_i386.deb to pool/main/liba/libax25/libax25_0.0.10-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree 4.2.0 - again
And the SUM of the numbers in the version number is also an even number!!! On Thu, Apr 18, 2002 at 07:52:57PM +1000, Brian May wrote: Date: Thu, 18 Apr 2002 19:52:57 +1000 From: Brian May [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: XFree 4.2.0 - again Mail-Followup-To: Brian May [EMAIL PROTECTED], debian-devel@lists.debian.org On Wed, Apr 17, 2002 at 10:56:33AM +1000, Roger So wrote: Why do people like you insists on having the latest version of everything without making sure that it's actually _better_ than what we have? Are you implying that the latest version isn't always the best version? Yeah right! ;-) Rather than repeating what most others have said, I'll give you one more reason why not rushing 4.2.0 into woody is a good thing: the whole i18n architecture changed from 4.1 to 4.2, and many bugs _were_ introduced in the transition -- like X clients segfault on startup if Xlib can't find the input method specified in the environment, and so on. I for one am glad that Branden is not rushing things through. I need X 4.2 because it... errr... umph. hang on a moment ...because its version number is made entirely of even numbers. ;-) (knew there had to be a good reason). -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Patrick Ouellette [EMAIL PROTECTED] Amateur Radio: KB8PYM 50.200, 144.200 EN81fp ICBM: 41:38:25.476N 83:31:43.417W -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug in buildd for all except ix86 and sparc?
(Should have sent this to -devel, but had a brain cramp and sent it to -user first.) Hey all, I seem to be having a problem that is buildd specific. I uploaded my package (ax25-apps-0.0.5-5) from ix86 after fixing problems on the non ix86 archs (working on merulo). It builds fine on merulo manually (with debuild) but dies when the build daemon tries with a 'cannot run configure.sub' error. Anyone else have this problem? Is it a feature or a bug? Thanks, Pat -- Patrick Ouellette [EMAIL PROTECTED] Amateur Radio: KB8PYM 50.200, 144.200 EN81fp ICBM: 41:38:25.476N 83:31:43.417W
Re: Bug in buildd for all except ix86 and sparc?
Yes, that's the apparent problem. On Thu, Jan 10, 2002 at 03:38:35PM -0200, Henrique de Moraes Holschuh wrote: Date: Thu, 10 Jan 2002 15:38:35 -0200 From: Henrique de Moraes Holschuh [EMAIL PROTECTED] To: Patrick Ouellette [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: Re: Bug in buildd for all except ix86 and sparc? On Thu, 10 Jan 2002, Patrick Ouellette wrote: manually (with debuild) but dies when the build daemon tries with a 'cannot run configure.sub' error. Anyone else have this problem? Is it a feature or a bug? Are you sure you are not missing a build dependency? The build daemon runs inside a chroot... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- Patrick Ouellette [EMAIL PROTECTED] Amateur Radio: KB8PYM 50.200, 144.200 EN81fp ICBM: 41:38:25.476N 83:31:43.417W
RE: libc6_2.0.7 release notes...
I think a reasonable policy statement for this would be something like: All pre-release versions will have debian revision of -0.x Maintainer release revisions will start at -1 and increment in whole numbers Non maintainer releases will add a point version to the left of the maintainer release number they are closest to or based on. Additional non maintainer releases will increment the point version number until the maintainer officially releases another debian revision. Non maintainer releases will not cause the removal from the archive of the maintainer release they are based on. This seems to solve future problems with upstream beta software revision numbers that don't allow us to use the upstream release number. OK, I opened my big mouth and have put on my asbestos undergarments :-) Pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: libc6_2.0.7 release notes...
OOPS left should be right. One of these days I'll be able to tell my left and right apart! -Original Message- From: Patrick Ouellette [mailto:[EMAIL PROTECTED] Sent: Thursday, June 25, 1998 3:13 PM To: debian-policy@lists.debian.org Cc: Debian Developers Subject: RE: libc6_2.0.7 release notes... I think a reasonable policy statement for this would be something like: All pre-release versions will have debian revision of -0.x Maintainer release revisions will start at -1 and increment in whole numbers Non maintainer releases will add a point version to the left of the RIGHT maintainer release number they are closest to or based on. Additional non maintainer releases will increment the point version number until the maintainer officially releases another debian revision. Non maintainer releases will not cause the removal from the archive of the maintainer release they are based on. This seems to solve future problems with upstream beta software revision numbers that don't allow us to use the upstream release number. OK, I opened my big mouth and have put on my asbestos undergarments :-) Pat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Lilo..
I had similar problems with Windows NT and large drives on 2940UW controllers. The problem appeared to be the wide bus mode setting ( I forget the exact wording in the adaptec setup). If I changed the setting, the machine would not boot from the drive until I either low level formatted the drive or changed the setting back. I eventually took to setting all the options to default, then enabling the ultra mode, then installing the OS and not touching the card setup again. There were four of us working on those machines, so the simpler we made the setup the less we had to remember and document. Pat -Original Message- From: Paul Slootman [mailto:[EMAIL PROTECTED] Sent: Friday, May 08, 1998 3:07 AM To: debian-devel@lists.debian.org Subject: Re: Lilo.. On Wed 29 Apr 1998, Enrique Zanardi wrote: matthew.r.pavlovich.1 wrote: I am getting a quirky bug with lilo. I have a 4gig Wide SCSI drive that is set to scsi id 0. I can partition the disk, write to the disk, read, mount it as /, but I cannot boot from it (The boot flag is set on the first primary partition). I have an adaptec 2940UW controller w/ 2.0.33. Lilo runs correctly, and the light flashes on the drive, but at boot it just hangs..not even a 'Li'. I was wondering if anyone has seen a similar problem with lilo and large drives, or lilo and adaptec 2940's. Lilo works correctly with another hard drive, that is a 2gig and on the narrow bus. I had the same problem some time ago (Adaptec card, I don't remember the model). I solved it by disabling the Extended translation mode for big disks in the adaptec BIOS and adding the linear option to lilo.config. I hope that helps. I still saw problems last weekend with mbr.b not being written to /dev/sda when installing frozen with the 04-11 boot-floppies. I did that by hand dd if=/boot/mbr.b of=/dev/sda bs=444 and after that I could boot from the disk. And yes, I did answer 'y' to the question install a boot block or whatever the exact message is. Note that this only happens on a virgin disk or a disk that otherwise doesn't have any remains of a previous installation on it (e.g. dos; the dos primary bootstrap also works). Paul Slootman -- home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands Support Randal Schwartz! See http://www.lightlink.com/fors/ or send empty email to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FW: Yet another Linux distribution! :-)
I have tossed around the idea of a ham specific configuration that would fit on a zip disk. Not the fastest way to run the system, but you could set up a swap and var/temp area on a small local hard drive, use a ramdisk and have an easy way to upgrade the node. I haven't thought about what software should be in it. I can see 2 configurations, a node/bbs and an end user. I use the term configuration because that is exactly what it would be in my case. In my mind if the system uses the Debian packages and upgrade/configuration tools then it is a Debian distribution configured for the task. Pat -Original Message- SNIP I also will plug again for an Amateur Radio specific distribution. (IE: AX2.5, RTTY, SSTV, log, contest, CAD S/W etc). And yes when I come up to speed on my own debian system (I'm going to install GTK / GHOME / GIMP and see about porting my MFC knowledge to X) I'll try to write some of this stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: New Linux distribution
If you have sensitive skin you may wish to push the delete button now -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 30, 1998 8:27 AM To: [EMAIL PROTECTED]; debian-devel@lists.debian.org Subject: New Linux distribution Bruce, I just read your letter to the debian devel list and your name sounded familiar. You were mentioned in a Linux Ham-HowTo as starting a linux distribution for amateur radio. The mentioned web page however does not exist (dns entry not found anyway). I learned of Debian from this goal too. Never saw the Ham distribution, but found what I needed in Debian. I assume that your current letter is a resumption of this desire. I have had my own thoughts along these ideas. There are several Amateur radio programs currently available for dos/windows that *NEED* to be ported to linux. These include contest loggers, satalite trackers, packet radio, RTTY, and SSTV programs. There is very good SSTV program for windows 95, using the sound blaster that I would like to see ported to Linux / X. It is currently shareware. A call to ham software developers! Yep, lots of apps need to be ported - are you volunteering? I have installed debian 1.3.1 (several times!) at home and have found that it is NOT easy to install. Many of the utilities are older than versions supplied with Slackware or Redhat. Examples: Man uses More instead of Less as a pager (this can be fixed but debian's man does not support the 'rc file format that slackware uses). LS does not support color (can be added but again debian does not support the same 'rc or enviromental settings found elseware). Getting networking up was a real head scratcher as a network configuration program (such as supplied with slackware and redhat) does not exist and you must edit startup scripts by hand. Yes a true sysadmin should know this stuff, but I had to find the answeres in a book on Slackware and translate to debians script format! I like debians goals and style but it needs polish. A good book on dpkg and dselect (along the read-ability lines of maximum RPM ) would help. If you set up another list for this effort please post it's url here or e-mail me. Thanks. Most of the items listed are in FAQs or documentation on the system. As I recall from Debian 0.93 (I think that was the revision when I started using it) the configuration of a network was part of the post-inst script. PPP needed tweaking, but nothing that wasn't in the documentation. If someone has the desire to install an operating system on a computer that is created, supported, and distributed by volunteers they should expect to have to do some amount of reading to configure the system to their liking. When someone does the install and then proceeds to cry because the system doesn't do what their friend's does, without being willing to read and follow the documentation I quickly lose patience. It is a different issue if the person reads the documentation and doesn't understand it, or the solution is not in the documentation. At least the person has *tried* to help themselves. As with most free things, you get out what you put in. If you want a system that is easy for the casual user, you need to develop that and be willing to hold the hand of all the casual users when they don't understand why the system is doing what they told it to, not what they think it should be doing. I applaud Bruce for attempting to follow this goal, and wish him the best of luck in the endeavor. I hope it meets with better success than the Linux for Hams project. Pat Pat Ouellette Email: [EMAIL PROTECTED] Amateur Radio (voice): KB8PYM on KB8YVY repeater (52.650 / 146.835 / 444.650) Amateur Radio (packet): [EMAIL PROTECTED] Running down the hall: Hey you! You can ping your node, you can ping you neighbor, but you can't ping your neighbors node. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: on forming a new Linux Distribution
Thanks for taking it as intended - and not the flame bait it might have sounded like. (Rough night last night - but I did put the delete disclaimer in) I've been using hamm for some time, and as long as you check to be sure that application you can't live without exists, it has been fairly stable for the last month. The autoup.sh script was a bit rough (I have heard it is much better now) and I trashed a system with it. After I installed from scratch everything has been reasonable (except the soundmodem programs were linked against libc5). When you get around to porting those ham apps, let me know and I'd be happy to help if I can. 73 de KB8PYM Pat Email: [EMAIL PROTECTED] Amateur Radio (voice): KB8PYM on KB8YVY repeater (52.650 / 146.835 / 444.650) Amateur Radio (packet): [EMAIL PROTECTED] Running down the hall: Hey you! You can ping your node, you can ping you neighbor, but you can't ping your neighbors node. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 30, 1998 12:02 PM To: [EMAIL PROTECTED]; debian-devel@lists.debian.org Subject: Re: on forming a new Linux Distribution If someone has the desire to install an operating system on a computer that is created, supported, and distributed by volunteers they should expect to have to do some amount of reading to configure the system to their liking. When someone does the install and then proceeds to cry because the system doesn't do what their friend's does, without being willing to read and follow the documentation I quickly lose patience. It is a different issue if the person reads the documentation and doesn't understand it, or the solution is not in the documentation. At least the person has *tried* to help themselves. No problem here. As I said I *DID* find the answers and got my debian installation to talk to my ethernet card after making use of available documentation. But it was not Debian specfic documentation that was most helpfull, but rather general linux networking and slackware specific documentation that gave me my answers. Yep, lots of apps need to be ported - are you volunteering? Ok put your money where your mouth is eh? I'm not yet at the point where I could make the kind of contribution that I'd like to. First I need to get my own system in order (I'll end up starting from scratch with debin 2.0 when it is ready for prime time). Then I need to learn how to program GUI under X (which standard? Motif etc?), I currently know MFC under windows professionally. As with most free things, you get out what you put in. If you want a system that is easy for the casual user, you need to develop that and be willing to hold the hand of all the casual users when they don't understand why the system is doing what they told it to, not what they think it should be doing. Yes I'd also like to help improve system friendlyness for the begineer. I applaud Bruce for attempting to follow this goal, and wish him the best of luck in the endeavor. I hope it meets with better success than the Linux for Hams project. Maybe Debian should become linux for hams. How about a default configuration for amateur radio users? And solicit more ham radio packages. I'm willing to write / port some, in the near future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: **Ready your Flame-Throwers**
I'll bite: From: Ian Keith Setford [mailto:[EMAIL PROTECTED] Sent: Thursday, April 30, 1998 3:09 PM To: debian-devel@lists.debian.org Subject: **Ready your Flame-Throwers** Yo- I am subscribed to devel although I am not a developer and since everyone else has had comments on Bruce's message so do I. It seems to me that the problem is difference in opinion on the direction of Debian. Unlike most of you (I presume) I have chosen to study business instead of computer science of some variety. I have seen that a group of developers would like to see Debian as the most technically advanced distribution at a cost of time and user-friendliness. On the other hand, we have those developers that have a vision of Debian being more user-friendly and less technical. Gee, I studied physics and am working on an astro-physics degree. Computers just pay the bills and keep me off the streets. Remember presume is almost ass-u-me :-) I can presume that these same arguments were occurring in board rooms of the Big-3 auto-makers in the U.S. in the late 70's and early 80's. The problem is that Debian is presuming what the average or mainstream computer user wants. This is wrong. The focus should be on the customer and therein lies Debian's problem. Who are the developers working for? Are you in it to make Debian for hackers, for business or for home use? It is very hard if not impossible to achieve all of these. Why do companies segment their products? Why do they do selective marketing? WHO IS DEBIAN FOR? Does Sun make Solaris with the intent of home users running it? No. They made their product based on what their customers wanted. Microsoft tries this but their technical side is crap. No doubt every product needs a focus. The rift opened when Bruce attempted to get the developers to see the value of marketing TO an audience. The developers are *volunteers* who do it as a hobby, not because a user wants this or that. For someone to market Debian, they would need to look at what is there and find the marketable points of it. Most of the developers would not be adverse to *suggestions* from marketing, but are against marketing driving the direction of the development. Most consumer mass market things are driven by marketing once the initial idea is built. That's why many new mini-vans have connivance outlets (cigarette lighter sockets) in the cargo area. There is no technical reason to have one there, but marketing said it would sell more vans. Why not find out what computer users want? Why don't you segment Debian into two divisions? Like Microsoft does with it's products (except both Debians would retain superior technial ability). A Debain for a newbie and a Debian for power-users? I'm not sure how much work that would entail because I am not a developer. See your comment on Micro$oft, and my comments above. I can tell you right now that no Linux distribution will conquer Microsoft or anyone else if they can not market themselves and release when they say they will. Being technically supreme will get you no where unless it is matched at least equally with ease in installation, visibility, customer support, and product reliability. We are not out to conquer Micro$oft, or anyone else. We are here to share out talents with like minded individuals (and some not so like minded). The fact that other people find it useful is a bonus. Debian, in it's current state, focuses on being technically superior with *excellent* support but lacks ease in installation and marketing. (Note I said marketing, not marketability.) Ok Mr. Business - create a marketing team and propose said marketing in such a way as to not step on the sensitive toes of the developers. Debian needs to be easier to install and it needs visibility to those who would purchase Windows. Why? This is a world domination style goal. Easier to install would be nice, and is being worked on from what I can tell. If Bruce wishes to make a more user-friendly distribution I wish he would do it under the guise of Debian. Excuse the comparison but if Bruce's Easy Debian or whatever the name is could do for Debian what Window's 95 did for Microsoft,all of Debian would be *far* better off. Bruce should do what Bruce thinks is right for Bruce. He's a big boy and can make decisions for himself. RedHat already has the ease in install and visibility so all they have to do is get their technical and support side better. RedHat has the visibility because it is commercially produced for profit. If Debian had the goal to be the number one Linux distribution in the world - regardless of the competition, the first thing I would suggest is a Debian point of purchase package to be made available through computer stores and bookstores. The question is: Who is Debian for and where do you see it one year from now? ..five years from now? Sounds like Micro$oft's where do you want to go
