Sponsor wanted for new newspost package
I have made changes to source package newspost_2.1.1-4, so that a bigger
-l (lines) parameter can be given, and and indroduced a new parameter -2
with which it calls another program - such as par2create - to make the
desired par2 files. I renamed the dir into newspost-2.1.2.beta.
*Open question*: Is another person presently working on a new version of
newspost, if yes, how can I contact him/her?
A test uploading a binary file to the usenet, making the par2 files, and
uploading them too, has been *successful*!
I also have successfully checked it with the UseNeXT client, the UseNeXT
client could successfully download the files and put them together again.
Upload was done news.t-online.de, Download from news.usenext.de. The
call was:
./newspost -v -i news.t-online.de -u -p -f
[EMAIL PROTECTED] -n de.alt.dateien.misc -s Test8 -y -T 3 -2
'par2create -s12288000' *.mpg
To build the source package with dpkg-buildpackage was not successful, but
dpkg-source -b newspost-2.1.2.beta
has been successful.
Now I need more help to prepare the package for uploading with dput, for
uploading it;
and I am looking for a sponsor.
When trying to upload the package with dput, then come following error
messages:
[EMAIL PROTECTED]:~/newspost-2.1.2.beta$ dput -P ftp-master
debian/newspost.changes
Traceback (most recent call last):
File "/usr/bin/dput", line 919, in ?
main()
File "/usr/bin/dput", line 767, in main
unsigned_upload, debug)
File "/usr/bin/dput", line 281, in verify_files
changes = parse_changes(chg_fd)
File "/usr/bin/dput", line 80, in parse_changes
for a in changes.dict['files'].split('\n'):
KeyError: 'files'
My dir shows:
...
drwxr-xr-x 9 david david 4096 29. Apr 08:01 newspost-2.1.2.beta
-rw-r--r-- 1 david david 483 29. Apr 05:49 newspost_2.1.2.beta.dsc
-rw-r--r-- 1 david david 435 29. Apr 06:52 newspost_2.1.2.beta.dsc.gpg
-rw--- 1 david david68954 29. Apr 05:49 newspost_2.1.2.beta.tar.gz
...
I don't know anything about the file debian/files, so I need help.
At present time I want to build a source package only, the binary
package I want to make later.
David
It follows newpost.changes with signature:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Newspost
List of Changes
2.1.2.beta
- Option -l changed to default 5, maximally 5 millions.
- Made new option -2 to call an external program to make the
desired par2 files, after this the newspost program calls
itself recursively one time to upload the par2 files too;
precautions to avoid infinite recursion have been made.
2.1.1
- The extra header option (-X) works again
- Subject line creation is fixed when ALLOW_NO_SUBJECT is defined
- The text prefix is no longer counted in the "UUencoding xx bytes" line
- Updated the contact e-mail address
2.1
- Removed all string length limitations
- Fixed zero-padding with -q option ("File 01 of 10" not "File 1 of 10")
- Referencing message IDs (-r option) now works
- Ability to "fake post" files: newspost can add specific files to
generated .SFV and .PAR files, and preserve ' \- File x of y: ' numbering,
but not actually post those files
- Compilation fixes for a variety of platforms
2.0 - Major rewrite
- Yencoding support
- Support for automatic PAR file generation
- Support for posting parts of files
- Optionally edit text prefixes and text posts in external editor
- User-configurable delay before posting
- New header options, including user-specified extra header lines
- New file format for defaults, now in .newspostrc
- Man page :-)
- SFV posted first instead of last
- SFV now specified with "-c" instead of "-v"; now "-v" is "verbose"
1.20 - changes by William McBrine
- .newspost values were sometimes not zero-terminated on rereading,
resulting in garbled settings; fixed
- messages that had a '.' in the first position on a line could be
posted incorrectly; fixed
- changed status display to show "Posting n of n" instead of hash
marks
- lines in the body of the article now end correctly in CRLF,
instead of just LF
- temporary files are no longer created, except in the case of SFVs
generated by newspost
- CRLF vs. LF is now handled correctly in reading and writing files
(and should now work under Windows as well as Unix)
- "Organization" line is now optional; "Subject" parameter is
optionally optional (see source)
- corrected format of "User-Agent" line
- special makefiles for AIX and OSF no longer needed
- much internal reorganization; faster, smaller, and probably easier
to compile
1.13
- fixed endless loop that occurs with -v option when one of the
files is deleted before posting is complete
- no longer prints out your password when displaying help
- added a makefile and made changes to support D
[Fwd: Sponsor wanted for new newspost package]
I also have changed the manpage and want to show it: .TH "NEWSPOST" "1" "2.1.1" "Jim Faulkner" "" .SH "NAME" .LP newspost \- a usenet binary autoposter .SH "SYNTAX" .LP ... no changes before here ... \fB\-2\fR This causes par2 files to be made, by calling an external program, usually par2create. The call must be given in quotes and WITHOUT the file list, example: -2 'par2create -s12288000'. .br Newspost will create a par2 directory,chdir there, call par2 to create the par2 files, and chdir() .. Then it will do the normal job. At the end, it will again chdir to par2, ignore options -2 -a -A -B -d -D -e -E -t, and with system() call itself, so that the contents of the par2 directory is posted too. .br This option does not work if the par2 directory - or a normal file with this name - exists. Before use, you must delete or move the par2 file or directory. .TP \fB\-l\fR <\fInumber\fP> Sets the number of lines per message to <\fInumber\fP>. In the old days most people used to post messages which are between 5000 and 1 lines long. By default, this is now set to 5. Note: For uuencoded messages, this is the actual number of lines in the body of the message; but for yencoded messages, it's used to determine the size of each segment before encoding, by multiplying the specified number of lines by 45 (which is the size of a uuencoded line before encoding). Thus, the size of each segment before encoding is the same for either method, but the actual line count for yencoded segments will vary. .TP ... no changes after here ... Original-Nachricht Betreff:Sponsor wanted for new newspost package Weitersenden-Datum: Tue, 29 Apr 2008 06:32:35 + (UTC) Weitersenden-Von: [EMAIL PROTECTED] Datum: Tue, 29 Apr 2008 08:31:36 +0200 Von:David <[EMAIL PROTECTED]> An: [EMAIL PROTECTED], debian-devel@lists.debian.org I have made changes to source package newspost_2.1.1-4 ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
newspost - neues Paket bauen - Fragen -- newspost - build new source package - questions
Bitte um Hilfe bei einigen Fragen betr. des Bauens von Quellpaketen: Habe einige Erweiterungen / Änderungen gemacht zum Programm (Source Paket) newspost. Folgendes ist mir inzwischen gelungen: Vorhanden Datei: newspost_2.1.1.orig.tar.gz Datei: newspost_2.1.2.beta.tar.gz ( erzeugt mit dpkg-source -b newspost-2.1.2.beta) - dieses Verzeichnis enthält alle Dateien, darunter die von mir geänderten und die zwei neuen. cd newspost-2.1.2.beta dpkg-distaddfile newspost_2.1.1.orig.tar.gz news optional und: dpkg-distaddfile newspost_2.1.2.beta.tar.gz news optional hat ebenfalls funktioniert (Erzeugen der Datei debian/files). Jetzt - bin immer noch im Verzeichnis newspost-2.1.2.beta - dpkg-genchanges -sa ergibt einige Warnungen: parsechangelog/debian: Warnung: debian/changelog(l5): ungültig formatierte Zeile im Nachspann LINE: -- David Moerike <[EMAIL PROTECTED]> Sat, 26 Apr 08:01:02 +0200 parsechangelog/debian: Warnung: debian/changelog(l7): found start of entry where expected more change data or trailer LINE: newspost (2.1.1-4) unstable; urgency=low +0200 parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo more change data or trailer erwartet wurde Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Dpkg/Fields.pm line 202, line 7. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Dpkg/Fields.pm line 202, line 7. parsechangelog/debian: Warnung: debian/changelog(l5): ungültig formatierte Zeile im Nachspann LINE: -- David Moerike <[EMAIL PROTECTED]> Sat, 26 Apr 08:01:02 +0200 parsechangelog/debian: Warnung: debian/changelog(l7): found start of entry where expected more change data or trailer LINE: newspost (2.1.1-4) unstable; urgency=low +0200 dpkg-genchanges: Warnung: Paket newspost in Steuerdatei aber nicht in Dateiliste dpkg-genchanges: Warnung: unbekanntes Informationsfeld »Error« in den Eingabedateien in ausgewertete Version des changelogs dpkg-genchanges: füge kompletten Quellcode beim Hochladen hinzu Format: 1.8 Date: Tue, 29 Apr 2008 19:29:55 +0200 Source: newspost Binary: newspost Architecture: source Version: 2.1.2.beta Distribution: unstable Urgency: low Maintainer: Debian QA Group <[EMAIL PROTECTED]> Description: newspost - Usenet binary autoposter Changes: newspost (2.1.2.beta) unstable; urgency=low . * Functions for external calls added. Checksums-Sha1: 7d7a2e71a04dd3fc5999e1c0a931d0e4dffaad7b 483 newspost_2.1.2.beta.dsc 147d6b0d932acb7564b7f77eac4642e672fa01ce 67286 newspost_2.1.2.beta.tar.gz 244f31c6e5aa8e41224310295e477ab4a8a17071 61412 newspost_2.1.1.orig.tar.gz Checksums-Sha256: 867137bea86c78680ca95070fc78fc35662af893f4c2cb5f9973b978e24efab1 483 newspost_2.1.2.beta.dsc 13f952b7cd0de96de65a74fb197d74585ba451ad43016f41f4a393cf210b5a86 67286 newspost_2.1.2.beta.tar.gz bdd1ae83d7459d2cdd726115c028405fce33f9b60e71b88969f82fbc02672be7 61412 newspost_2.1.1.orig.tar.gz Files: 0c4718a9952e30cf7d33ec9980ffaf51 483 news optional newspost_2.1.2.beta.dsc e4e28deecf535fe28435a206fb8ab74f 67286 news optional newspost_2.1.2.beta.tar.gz 099a69ce511f746aec88a57d03575d5f 61412 news optional newspost_2.1.1.orig.tar.gz Jetzt - dpkg-buildpackage -k66256351 -sa ergibt folgendes: dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2 dpkg-buildpackage: setze CPPFLAGS auf Standardwert: dpkg-buildpackage: setze LDFLAGS auf Standardwert: dpkg-buildpackage: setze FFLAGS auf Standardwert: -g -O2 dpkg-buildpackage: setze CXXFLAGS auf Standardwert: -g -O2 parsechangelog/debian: Warnung: debian/changelog(l5): ungültig formatierte Zeile im Nachspann LINE: -- David Moerike <[EMAIL PROTECTED]> Sat, 26 Apr 08:01:02 +0200 parsechangelog/debian: Warnung: debian/changelog(l7): found start of entry where expected more change data or trailer LINE: newspost (2.1.1-4) unstable; urgency=low +0200 parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo more change data or trailer erwartet wurde Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Dpkg/Fields.pm line 202, line 7. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Dpkg/Fields.pm line 202, line 7. dpkg-buildpackage: Quellpaket newspost dpkg-buildpackage: Quellversion 2.1.2.beta dpkg-buildpackage: Fehler: kann Quellen geändert durch nicht bestimmen Die beiden Warnungen sind wohl nicht tödlich, aber die Zeile zum Schluss: was bedeutet sie genau, und wie kann man den Fehler beheben? Beim Versuch, das Paket mit dput zu mentors.debian hochzuladen, kommt: [EMAIL PROTECTED]:~/newspost-2.1.2.beta$ dput -P ftp-master newspost.changes Traceback (most recent call last): File "/usr/bin/dput", line 919, in ? main() File "/usr/bin/dput", line 767, in main unsigned_upload, debug) File "/usr/bin/dput", line 281, in verify_files changes = parse_changes(chg_fd) File "/usr/bin/dput", line 80, in parse_changes for a in cha
build new source package - questions
Please help, I have some questions regarding building Source Packages.
Made some changes to source package newspost.
Successful with following:
There exists file: newspost_2.1.1.orig.tar.gz
File: newspost_2.1.2.beta.tar.gz ( erzeugt mit dpkg-source -b
newspost-2.1.2.beta)
- all files, also those i have changed and the new ones.
cd newspost-2.1.2.beta
dpkg-distaddfile newspost_2.1.1.orig.tar.gz news optional and:
dpkg-distaddfile newspost_2.1.2.beta.tar.gz news optional
successful too (create file debian/files).
Jetzt - still in newspost-2.1.2.beta - dpkg-genchanges -sa - some warnings:
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike <[EMAIL PROTECTED]> Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo
more change data or trailer erwartet wurde
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, line 7.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, line 7.
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike <[EMAIL PROTECTED]> Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
dpkg-genchanges: Warnung: Paket newspost in Steuerdatei aber nicht in
Dateiliste
dpkg-genchanges: Warnung: unbekanntes Informationsfeld »Error« in den
Eingabedateien in ausgewertete Version des changelogs
dpkg-genchanges: füge kompletten Quellcode beim Hochladen hinzu
Format: 1.8
Date: Tue, 29 Apr 2008 19:29:55 +0200
Source: newspost
Binary: newspost
Architecture: source
Version: 2.1.2.beta
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group <[EMAIL PROTECTED]>
Description:
newspost - Usenet binary autoposter
Changes:
newspost (2.1.2.beta) unstable; urgency=low
.
* Functions for external calls added.
Checksums-Sha1:
7d7a2e71a04dd3fc5999e1c0a931d0e4dffaad7b 483 newspost_2.1.2.beta.dsc
147d6b0d932acb7564b7f77eac4642e672fa01ce 67286 newspost_2.1.2.beta.tar.gz
244f31c6e5aa8e41224310295e477ab4a8a17071 61412 newspost_2.1.1.orig.tar.gz
Checksums-Sha256:
867137bea86c78680ca95070fc78fc35662af893f4c2cb5f9973b978e24efab1 483
newspost_2.1.2.beta.dsc
13f952b7cd0de96de65a74fb197d74585ba451ad43016f41f4a393cf210b5a86 67286
newspost_2.1.2.beta.tar.gz
bdd1ae83d7459d2cdd726115c028405fce33f9b60e71b88969f82fbc02672be7 61412
newspost_2.1.1.orig.tar.gz
Files:
0c4718a9952e30cf7d33ec9980ffaf51 483 news optional newspost_2.1.2.beta.dsc
e4e28deecf535fe28435a206fb8ab74f 67286 news optional
newspost_2.1.2.beta.tar.gz
099a69ce511f746aec88a57d03575d5f 61412 news optional
newspost_2.1.1.orig.tar.gz
Now - dpkg-buildpackage -k66256351 -sa
gives following:
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
dpkg-buildpackage: setze FFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CXXFLAGS auf Standardwert: -g -O2
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike <[EMAIL PROTECTED]> Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo
more change data or trailer erwartet wurde
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, line 7.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, line 7.
dpkg-buildpackage: Quellpaket newspost
dpkg-buildpackage: Quellversion 2.1.2.beta
dpkg-buildpackage: Fehler: kann Quellen geändert durch nicht bestimmen
(- cannot determine sources changed by)
Warnings seem not lethal but the last line:
what does it exactly mean and how can I successfully do it?
When trying to upload to mentors.debian.net with dput comes following:
[EMAIL PROTECTED]:~/newspost-2.1.2.beta$ dput -P ftp-master newspost.changes
Traceback (most recent call last):
File "/usr/bin/dput", line 919, in ?
main()
File "/usr/bin/dput", line 767, in main
unsigned_upload, debug)
File "/usr/bin/dput", line 281, in verify_files
changes = parse_changes(chg_fd)
File "/usr/bin/dput", line 80, in parse_changes
for a in changes.dict['files'].split('\n'):
KeyError: 'files'
No change when omitting Option -P (passive ftp).
Next quest
Has recibido una postal de David
Hola debian-devel@lists.debian.org, Has recibido una postal de David <[EMAIL PROTECTED]> ! Para ver tu postal por favor clickea este link : http://postales.sonico.com/view.php?cid=11622329&[EMAIL PROTECTED]&db=2&t=ecards_sonico&ss=1 Muchas Gracias, http://Postales.Sonico.com Sitios recomendados http://www.TarjetasTelefonicas.com - Ahorra hasta 95% en tus llamadas telefónicas http://www.Sexymetro.com - ¿Crees que eres sexy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
download de video aulas curso video aula
video aula net cursos online: Visite: http://www.cursoemvideoaulas.com download de video aulas curso video aula, video aula net cursos online, aula violino video aulas canto, como fazer sites video aulas violão, video aula em dvd video cursos, aula musica video aula matematica, aula violão video aulas guitarra, como fazer magica como fazer sites, video aula canto aprenda inglês, video aulas de violão video aula concursos. download de video aulas curso video aula. Mais detalhes em: http://www.cursoemvideoaulas.com video aula net sites de video aulas, cursos video aulas video aprenda, video aulas violão curso canto, violao em video video aulas inglês, video dança do ventre video aulas baixo, aprenda inglês como fazer video, aulas guitarra video aula concursos, como fazer trabalho aulas em video, video aula guitarra video aulas direito, video bateria como fazer maquiagem. video aulas sites de video aulas, downloads video aula vídeo aula, aprenda ingles videos aula guitarra, aulas guitarra online video aula em dvd, violao em video video aulas violão, aula guitarra on line como fazer montagens, como fazer amor palestra em video, como fazer video aula video direito, video aula matematica video aula informatica, video cursos como fazer bijuteria. aula violino video aulas cantodvd video aulas cursos à distância, video curso cursos em video aulas, aulas guitarra online video aula em dvd, video aulas flash videos aulas guitarra, video aulas canto video aulas violão, sites de video aulas como fazer bijuterias, aulas canto aulas em videos, como fazer montagem video aulas guitarra, video aula concursos como fazer sabonete, video aulas guitarra aprenda espanhol. -- 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/1267453068c4b71992bd71327e8969323a50583...@gmail.com
Make money at home with your PC
I'll make you a promise. READ THIS E-MAIL TO THE END! - follow what it says to the letter - and you will not worry whether a RECESSION is coming or not, who is President, or whether you keep your current job or not. Yes, I know what you are thinking. I never responded to one of these before either. One day though, something just said "you throw away $25.00 going to a movie for 2 hours". "What the heck." Believe me, no matter where you believe "those feelings" come from, I thank goodness every day that I had that feeling. I cannot imagine where I would be or what I would be doing had I not. AS SEEN ON NATIONAL TV: Making MONEY every month from your home. THANK'S TO THE COMPUTER AGE AND THE INTERNET ! JOIN THE RANKS OF THOSE MAKING SERIOUS MONEY AT HOME Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can "follow the simple instruction" they are bound to make money with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. Read on. It's true. Every word of it. It is legal simply because you are buying and selling something of value. This is what one had to say: '' Thanks to this profitable opportunity". I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received a total $610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. == Another said: "this program has been around for a long time but I neverbelieved in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and waited. 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, === PRINT THIS NOW FOR YOUR FUTURE REFERENCE If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following... THEN READ IT AGAIN and AGAIN!!! FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE! INSTRUCTIONS: You will be buying 5 reports for $5 each, a total of $25. =Order all 5 reports shown on the list below = For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. ===WHEN YOU PLACE YOUR ORDER, MAKE SURE === ===YOU ORDER EACH OF THE 5 REPORTS! === You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happens to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on the majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter it, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, some have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! This IS a legitimate BUSINESS. You are offering a product for sale and getting paid for it. Treat i
Re: XFS Kernel image packaging
At this time being, there's no official XFS kernel images nor patches in Debian, however there is xfsprogs as far as I know in Woody & Sid. I am willing to work on an XFS kernel floppy boot disk, but it would be pointless cine a kernel image with XFS is bloated by about 300K if I'm not mistaken, at least the ones on some of the machines I put XFS into. There are Reiserfs images avaiable however. I certainly would like to get a hold of some XFS based install disks if anyone ever has done any with success. David On Tue, Sep 25, 2001 at 01:12:52PM -0600, Russel Ingram wrote: > Pardon me if I sound like a newbie here. I am fairly new to the Debian > way, but I am a Linux veteran. I have noticed that there are patches > available in the debian package tree for the XFS filesystem but there are > no available kernel-image packages with XFS already built in. Is there a > specific reason for this or is it just because no one has stepped forward > to offer such a package? > > If the latter is true I would be willing to be a maintainer for a > kernel-*-xfs package set if no one else is working on it. I haven't been > able to find any references specific to making kernel packages in the > packaging manual or the policies so I'm also curious about whether or not > official debian kernel packages are created with the make-kpkg command or > if it has to be done with dpkg-deb tool. I've used the make-kpkg command > to create kernel packages, but they always come out with a custom-1.00 > label on them and I haven't figured out how to get around that. > > Thanx, > Russ > > -- > Russel H. Ingram > Unix Systems Administrator > Institute for Scientific Computation > University of Wyoming/Math Dept. > Phone: (307)766-6546 > E-Mail: [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Application Icons Design
Hello Sir/Madam, We are developing software runs at iPhone, iPad and Android. Basically, this software is an auto follow tool built for twitter users. The draft design for this app is here: http://twittergrow.com/info.php?img=draft_ZGViaWFuRGRldmVsJWxpc3RzS2RlYmlhblxvcmc.png The page is not ready, we need in web designer to build it. I would like to have a custom design icon made - I need a desktop icon for Windows 7, app icon for iPhone, app icon for Android, app icon for iPad, favicon for our site and 10 toolbar icons with 32x32 icon size: follow, unfollow, start, stop, check status, tweet, retweet, reply, help, black list. How long does it take before you send a sample design? And please calculate the project cost. Thanks This is a forwarded message From: Tim To: dahm...@twittergrow.com Date: Saturday, September 3, 2011, 4:18:56 AM Subject: Draft for apps for twitter ===8<==Original message text=== Hello David, >Timeframe is 3 weeks. It's possible to discuss a budget next week with skype, >Please try to ask the following icon designer: debian-devel@lists.debian.org ===8<===End of original message text=== -- Best regards, D. Ahmed dahm...@twittergrow.com -- 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/6916028642.20110912164...@graphics4design.com
Re: Removing more packages from unstable
Hi, On 20/08/2024 07:28, Helmut Grohne wrote: […] What does a package cost? [ a lot ] What does package removal cost? […] Sometimes, packages are reintroduced. Doing so incurs a pass through NEW (and review by the ftp team). […] That’s the main reason why I usually keep packages around for a few months after getting them removed from unstable. php-fig-link-util […] php-sabre-event php-sabre-http php-sabre-uri php-sabre-xml php-sparkline php-webimpress-safe-writer ( and more ) … And months become years… I’ll try and take care of the removal from unstable of those package, but don’t know when, so no objection if you’re quicker. I welcome your initiative: I didn’t feel like putting too much cost on people on top of hardware when keeping packages around. The little “economy” I was hoping for (no NEW handling if the package gets reintroduced) is not really worth it IMHO. Thanks for raising the issue publicly. Regards David
Re: mtkbabel mayby unmaintained long time new version available Perl? advice?
benatt...@gezapig.nl writes: > Hello, > I think mtkbabel is unmaintained. > Listed maintainer Uwe Hermann > (https://qa.debian.org/developer.php?email=uwe%40debian.org) > There is a new version since oct-2019 with some improvements. > I am no maintainer no coder etc. Probably I will never sent paches etc. > What is the best I could do in such cases. > Is there some kind of template that I could use when contacting > the maintainer directly. > And would it be appreciated when cc ing teams in this case maybe Debian Perl > Group? > Thanks. It's great that you want to help Debian, but I'm sorry to say your current bug filing strategy is not (in my opinion as an individual maintainer) very helpful. It seems like the bugs you are filing mostly duplicate the information already in tracker.debian.org. If you are a user of the software in question, then it's reasonable to file a wishlist bug asking for an update, or higher severity bugs for specific issues fixed in the new version. Otherwise you are just adding noise, and probably increasing the stress level of overworked volunteers. As a non-developer, there is still plenty you can do in terms of triaging existing bugs (seeing if they can be duplicated on your system), and reporting actual (major or minor) problems with the software you are using. I hope you will consider this as constructive feedback. David
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
On Sun, Oct 24, 2004 at 13:07:34 +0100, Matthew Garrett wrote: > > * Package name: ibm-acpi > > This has been integrated into the acpi.sf.net patch, so is fairly likely > to end up in the mainstream kernel before too long. Even if it gets integrated in the kernel (which I am not 100% sure about), having a package would make it work on older kernels. Also, an init script is needed to configure what events you are interested in and the package can provide example configuration files in /etc/acpi. Cheers David -- David Schweikert| phone: +41 44 632 7019 System manager ISG.EE | walk: ETH Zentrum, ETL F24.1 ETH Zurich, Switzerland | web: http://people.ee.ethz.ch/dws
Linux: Status Update On Open Source Friendly Graphics Card
Hello, Noticed this a couple of days back, and it's one of those things that stay on your mind and nag away at you until you become functional. I'm not up to taking on anything as advanced as this, but I thought perhaps others may be interested. http://kerneltrap.org/node/view/4057 Regards, David.
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
On Thu, Oct 28, 2004 at 09:44:18 +0200, Jerome Warnier wrote: > > Even if it gets integrated in the kernel (which I am not 100% sure about), > > having a package would make it work on older kernels. Also, an init script > > is needed to configure what events you are interested in and the package > > can provide example configuration files in /etc/acpi. > Shouldn't it be integrated to package "acpid" then? Yes, if the patch gets integrated, that would be the best solution. I am not saying that the package can't be obsoleted in the future. It can be however of use right now. I don't know, but maybe it could even make it to sarge... Cheers David -- David Schweikert| phone: +41 44 632 7019 System manager ISG.EE | walk: ETH Zentrum, ETL F24.1 ETH Zurich, Switzerland | web: http://people.ee.ethz.ch/dws
Re: Bug#292831: udev: udev prevents X from beeing started
On Jan 31, 2005 at 15:44, Wouter Verhelst praised the llamas by saying: > Op ma, 31-01-2005 te 09:40 -0600, schreef Ron Johnson: > > On Mon, 2005-01-31 at 15:58 +0100, Christoph Hellwig wrote: > > > On Mon, Jan 31, 2005 at 12:45:42PM -0200, Henrique de Moraes Holschuh > > > wrote: > > > > On Mon, 31 Jan 2005, Ron Johnson wrote: > > > > > Unfortunately, GNOME depends on hal, and hal depends on udev. > > > > > > > > If it does indeed depend on udev, how does it work under kernel 2.4 at > > > > all? > > > > > > Because that statement is utter bullshit. There's a single and optional > > > gnome component that wants to use hal. > > > > A single and optional gnome component that is very, very useful. > > apt-cache show magicdev > > No, that does not just work on Linux 2.4. > Except, I believe magicdev polls the kernel, rather than responding to kernel event. Plus HAL provides more features than just noticing if a CD has been inserted into a drive. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#280324: ITP: freemind -- A Java Program for creating and viewing Mindmaps
On Wednesday 10 November 2004 18:22, Eric Lavarde wrote: > Hi, > > hope this is OK to reply-to-all in such cases... > > Hilko Bengen wrote: > > Eric Lavarde <[EMAIL PROTECTED]> writes: > >>the package does already exist actually (see > >>http://freemind.sourceforge.net/wiki/index.php/FreeMind_on_Linux for > >>details), I'm the maintainer of the package for the FreeMind project > >>and I'd like to have it in the official Debian repository (contrib > >>Section). > > > > Have you tried to compile/run freemind with any of the available > > DFSG-free JREs so far? > > Not personally, but some users have unintentionally and unsuccessfully > tried to start FreeMind with kaffe and gcj. Would I get a different > result if I would try to _compile_ first FreeMind with whatever free JDK? I tried to run it under gij-3.4 and it died. I have yet to investigate why. David > > >>I'm not yet a Debian developer, going through the documentation and > >>the process of becoming one. > > > > Recently I spent a few hours on creating a freemind package myself, > > since I hadn't seen the links to your package so far. If you want, > > I'll be happy to sponsor your package. > > It would be a pleasure, I just need to find a key signer nearby. Anybody > living around BÃblingen (or Stuttgart)? > So, what would be the next steps? Remember: I'm still going through the > documentation (and I didn't think it would be so quick to get a sponsor > > :-) ). > > Thanks, Eric > > > Cheers, > > -Hilko
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 12:38:03AM +0100, Michelle Konzack wrote: > Am 2004-12-01 18:23:47, schrieb sean finney: > > > then don't give your daughter sudo privileges on your debian machines, > > and she can't install it! :) > > Too late... She is 13 and Administrator already... > Had learned very fast how to 'rm -rf /' and reinstall it alone. Really, she's 13, and you think it'd do any difference whatsoever to expose her to a pixelled image of a nude woman?! Sheesh. Either you've been shielding her completely (no TV, no advertisments, no magazines, no Internet), or you need a reality update. Worried parents should realise, that if their kids are old enough to administrate a Debian-machine to the level of installing their own packages, they've already been exposed to nudity. Lots of times. And they should probably worry more about the cases of non-nudity that are far more hurting, like all commercials with near-anorectic plastic-wonders on billboards, etc, from companies constantly trying to push for the image of the ideal woman as someone who is malnourished, probably will have backproblems before the age of 30 because of frontal overweight, and generally likes drinking alcohol in her underwear... Whether the package hotbabe is something that should be in Debian or not I leave up to others to decide, but personally I feel it to be on the same utility level as xeyes (that is, none, but probably amusing to some persons for a day or two). I can agree that putting the work erotic in the package description might not be ideal though; a.) I had a look at the pictures and I have a *very* hard time finding them even mildly erotic... b.) it'll definitely annoy people. But please wake me up when bible-kjv-text has been removed. Descriptions of rape, incest, murder, and about everything else, cannot possibly be good for children to read about, now can it?! As for hotbabe being pornographic? Nah. It does it's fair share to objectify women though, something that I find more worrying. Indeed, in a society where people were more equal (and more relaxed about sexuality), the porn industry would very likely both be sanitised and less prosperous. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Wed, Dec 01, 2004 at 11:32:18PM +, Will Newton wrote: > On Wednesday 01 Dec 2004 21:35, Manoj Srivastava wrote: > > > Right. We should not have games like quake, doom, or > > nethack,. since they promoite murder and mayhem and eating of > > corpses. > > So far so sarcastic. IMO if it can be demonstrated that distributing > something is illegal we should think about not distributing it. And, as demonstrated elsewhere in the thread, whoops goes bible-kjv-text. > We are not the EFF. If they or anyone else wants to fight for the No, we're not. We're also not the PTA or the moral police. > right to look at cartoon tits then that's fine by me. We are trying to > build an operating system. I think. Indeed. From that point of view, hotbabe is pretty meaningless. Then again, so is quake, doom, nethack, etc. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 08:03:42AM +, Helen Faulkner wrote: > Yes, you are being absurd. Since you are presumably not understanding the > point, let me explain more clearly: > > Pornography is widely regarded as being demeaning and insulting to women. Is this among people who are associated with pornography, either by being producers or consumers, or would this be among people who have some other motive for disliking porn? I happen to have the pleasure of knowing dozens of sex industry workers, including prostitutes (male, female, and TS), camerawomen, models, actors and actresses, store owners, dildo designers, authors, sex club bouncers, webmasters, toy reviewers and professional doms. I'm sure every one of them would agree with me that the expression of sex and pornography is about _freedom_, especially freedom from the oppressive ideas of outsiders, and that anyone who thinks it is demeaning or insulting to anyone just really is missing the boat. At least one of them (the store owner) feels that people that say they dislike porn just have never been exposed to "the right kind". It's a pretty common feeling to dislike something you don't understand. Especially when repeatedly told to dislike it. Perhaps the porn by itself is neutral, and the oppresive cluture around it is what causes it to be demeaning. (btw, is gay porn demeaning to women?) dave...
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 08:15:16AM +1100, Matthew Palmer wrote: > On Wed, Dec 01, 2004 at 08:50:08PM +0200, Kalle Kivimaa wrote: > > Yes, hotbabe is sexist (at least in it's current incarnation - if it > > included a male theme then it would only be sexually offensive to > > some) > > Anyone who feels that hot-babe would become less sexually offensive because > it included naked male images as well as naked female images really does > need to rethink their ideas about offensiveness. Somehow putting more > offensive images into a package doesn't strike me as being the way to make > something less offensive. Not less sexually offensive. But adding naked male images would probably take the edge of the argument of the package being sexist. > Personally, I don't have a problem with the package as-is -- the pictures > aren't exactly the most graphic thing that's likely to pop up unannounced in > a web-browser window, but the authorities frown on distributing anything > tittilating to minors in a lot of places, so I'd "vote" for making it a > series of pictures of a tree shedding it's leaves or something in the > default incarnation. While being all for that series of pictures (nature is beautiful), I find the package pretty meaningless anyway, so I don't see the point of including it in Debian in the first place. I do, however, see some relevance to the discussions. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
People have been complaining about not having child-safe images, so I've made some (attached). The images fade from solid green to solid red, pretty harmless. The images attached to this email are public domain and are provided as-is. -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GAT/CM$/CS>$/CC/IT$/M/S/O/U dpu s+:++ !a C++$>C+++$ UB+++>$L$*-- P+>++$ L+++()$ E-(---) W+++>$ N(+) o? K- w--(---) O? M V? PS++@ PE-@ Y+@ PGP++(+++)>$ t? 5? X? R tv--(-) b++(+++)@ DI? D? G e-> h* r? z* --END GEEK CODE BLOCK-- David Mandelberg [EMAIL PROTECTED] hb01.tar.bz2 Description: Binary data signature.asc Description: OpenPGP digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 04:07:14PM +0100, Michelle Konzack wrote: > Am 2004-12-02 08:44:34, schrieb David Weinehall: > > > Really, she's 13, and you think it'd do any difference whatsoever to > > expose her to a pixelled image of a nude woman?! Sheesh. Either > > you've been shielding her completely (no TV, no advertisments, > > no magazines, no Internet), or you need a reality update. > > And if she does not like violence and naked people ? Well, the first shows she's quite tasteful, the second might be a problem during physical education, no? (But I realise you didn't mean it that way). The question is, who would install the package on her computer? She surely wouldn't. She'd probably dodge the pr0n-sites on the Internet too. Why worry? > And publicity using half naked people is offensive !!! Sure, I didn't say otherwise. Of course, it depends on what you're doing commercials for. If it's underwear, I can see the point. Then again, the market for underwear is probably not big enough to warrant billboard ads with supermodels; they are rather an excuse for using semi naked surgically modified anorectics to sell everything else the stores have to offer. That's sad, but as long as people keep buying their products, the ads will continue. > > Worried parents should realise, that if their kids are old enough to > > administrate a Debian-machine to the level of installing their own > > She has an IQ enorm and will make her Lycee examen next year. > 4 years before the others... I didn't question that, and I'm glad to hear you have such an intelligent daughter. > She do not like to see everywhere naked People... > > It is TOO much ! > > Exhibiting of naked women is offensiv and disriminating. > Even it is a cartoon. I hate mens using women as sexobjects... Objectifying women is indeed degrading, both to women and men. Naked people as such isn't, it's natural and beatiful. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 01:55:28PM -0500, Stephen Frost wrote: > 2) Where do we point out to our users that the laws which govern what > we'll distribute are those of the US and finland (or wherever) and that > the laws in their country may forbid distribution? > > Especially if they're downloading from a mirror that's in their country, > they may not be aware of this. I'd hope that someone who installs bible-kjv would think about the consequences when such texts were forbidden in her country. Regards, David -- * Customer: "My palmtop won't turn on." * Tech Support: "Did the battery run out, maybe?" * Customer: "No, it doesn't use batteries. It's Windows powered." -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian
On Fri, Dec 03, 2004 at 02:12:19PM -0800, Martin Olsson wrote: > > I have not seen this image thus I do not if I would find it offensive or > not. Could someone please upload a .png of it somewhere and post the URL? The ITP contains a link to the source for the package. You *really* need to have a look at the pictures. All of your argumentation below about pron neatly goes *wooosh*. [snipped totally irrelevant though eloquent reasoning] > I'm not advocating a limitation on the freedom of speech though, neither > am I saying that nudity is an unmoral thing per se. I believe that it's > necessary to depict/discuss/describe even 'bad' things such as brutal > violence, exploitation, rape and war in a non-sugarcoated form. The > problem is typically the context, when an image depicting rape is > presented as entertainment I strongly oppose it. Again, have a look at the pictures *before* making comments. I don't doubt that you have have these opinions; in fact, I suspect most people here agree with you (I do). It's not really relevant wrt these pictures, however. [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Questionable image process. Was: Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian
Bruce Perens wrote: David Weinehall wrote: The ITP contains a link to the source for the package. You *really* need to have a look at the pictures. All of your argumentation below about pron neatly goes *wooosh*. I'll take your word. However, we seem to be lacking some process here. I don't have a guideline at hand regarding what can and can not be distributed to minors, with impunity, in various places. Lacking that, we should probably have a procedure in place to run any questionable images and dialogue by our volunteer counsel simply to get a call regarding how much trouble they could make for the project and its members. The goal is to be able to say that we distributed the image on advice of counsel, which can help us if the image gets us in court later on. How counsel reports back may be complicated due to issues of attorney-client privilege. We probably want to be able to maintain privilege so that we don't have to report to a court what we discussed with our attorney. It's not yet clear to me that stuff we post to debian-private is still under privilege. I'd have to ask our lawyer. This process is complex as it is multi-facetted. It's not just open source, it deals specifically with open access as well. To further complicate things, it deals with introducing a common factor within an international, multicultural environment. The OpenNetInitiative recently completed a study dealing with some of these aspects which might help. http://opennetinitiative.net/docs/Legal_Implications.pdf Regards, David.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Fri, Dec 03, 2004 at 12:12:53PM +0900, Mike Hommey wrote: > You're being offensive, you should not be included in Debian. Reading this one comment made this whole craptacular thread worth reading. - David Nusinow
Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian
On Mon, Dec 06, 2004 at 04:35:41PM +1100, Brian May wrote: > >>>>> "Tollef" == Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > Tollef> | Finally, I would like to commend Michelle Konzack for > Tollef> standing up on | this issue. Debian should never promote | > Tollef> degradation/abuse/exploitation, in any form, of females > Tollef> (or males or | blacks or whites or whatever). Be careful with your attributions, that was written by Martin Olsson, not Tollef Fog Heen. > Tollef> Please take a look at the images and I'd be surprised if > Tollef> you feel them degrade, abuse or exploit females. I think > Tollef> they are silly and nothing to be upset about. Not porn, > Tollef> not erotic, just silly. This part, was written by Tollef though =) [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Status of this ITP?
On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by saying: > > > Its been more than a year now. What's the status of this ITP? This is > ridiculous. If you can't package it, then say so so others can come in > and do the job. We deserve a freedesktop.org package by now in debian. > > Get off your ass. > This is an ITP for KDrive, the experimental xserver. It is not the X.org xserver. I'm not sure this is what you think it is. I appriciate that english may not be your first language, but the tone of the email was not exactly friendly. People work on Debian because they want to. Having people shout at them isn't the best incentive to get them to do voluntary work. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: Where is your freedom of speech ? (Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor)
On Wed, Dec 08, 2004 at 09:29:55AM +0100, Emmanuel Charpentier wrote: > Debian might fare much > better if its members who happen to be citizens of the U f*ck*ng S of A > rememeber sometimes that they are *not* center and moral arbiter of the > world... The same can be told of (semi-) legal concerns, which have no > relevance outside the US : insisting that Debian should cater to any > possible foolish demands of an US attorney|sycophant is at best > provincialism, at worst parochialism. Rampant USA bashing is not likely to help your cause, and is in fact far more likely to piss off a large number of people who might otherwise be inclined to listen to what you have to say. As it is, you just come off sounding like a total jerk. Please read the RTFThread and come back when you realize that a good chunk of the debate is centered around the legality of distributing content to places like Iran. - David Nusinow ObRC: #280901
Re: dselect survey
On Thu, Dec 09, 2004 at 11:08:53PM +0100, Florent Rougon wrote: > I've always thought that people who say they hate dselect (or, worse, > that dselect is crap) fall into one of the following cases: > > (a) allergic to text-mode interfaces > (b) type or click without thinking > (c) haven't used it for more than 5 years (I don't know how dselect was > before slink) > (d) didn't bother to read the "dselect for beginners" tutorial or any > similar introductory document > (e) have had problems with packages that didn't install, upgrade or > configure correctly and wrongly blamed dselect for these problems. > > [ Quizz of the day: which cases do you think are the most common? ] > > Once you understand the basics, I find dselect to be a very useful and > efficient program. Amen! Well said. Regards, David -- * Customer: "My palmtop won't turn on." * Tech Support: "Did the battery run out, maybe?" * Customer: "No, it doesn't use batteries. It's Windows powered." -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote: > As a practical matter, what if the Debian gcc team decide to release > etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is > not stable enough on all the platforms ? Will LCC follow ? If not, how > are we going to share binary package if we do not use the same compiler? Another question that bothered me, is whether "special" binaries which cannot be bit-equal be rebuilt by the build-process (i.e. everything containing timestamps, random offsets (consider prelink -R) or machine dependant strings (like the hostname)) are really free. Obviously there are rights attached to the binary which cannot be reproduced solely from the delivered source. A similar argument was brought up in the DRM/Palladium discussion with signed binaries. But that was worse, because this kind of binaries was unusable without the signature while non-LCC binaries would just be that: non-LCC binaries. Regards, David -- * Customer: "My palmtop won't turn on." * Tech Support: "Did the battery run out, maybe?" * Customer: "No, it doesn't use batteries. It's Windows powered." -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: dselect survey
On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote: > [1] I still use both versions and happen to often hit instead of > when I use sid's one, which doesn't have any bad > consequences (simply scrolls help). And the problem will disappear > automatically when I don't have to use woody's dselect anymore. echo expert >> /etc/dpkg/dselect.cfg Regards, David -- * Customer: "My palmtop won't turn on." * Tech Support: "Did the battery run out, maybe?" * Customer: "No, it doesn't use batteries. It's Windows powered." -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: > I have looked at it. And I don't think it is an acceptable thing to ship as > part of an operating system. I am an atheist and a liberal but the majority > of people in the world are not. I don't think it is an acceptable thing to ship as it has no use. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: Debian package selection depending on user location/belief/society(was bug #283578 hot-babe (AGAIN :-)))
On Tue, Dec 07, 2004 at 09:49:57AM +, Will Newton wrote: [snip] > Not to point out the obvious, but "foul language" is dependant on the > language you speak, so most countries are unlikely to be offended by > the Linux kernel. Not to point out the obvious, but what is pornographic is dependant on the viewer, so most people are unlikely to be offended by the artwork in hotbabe... Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Ron Johnson wrote: > On Sun, 2004-12-12 at 22:24 +1300, Philip Charles wrote: > >>On Sun, 12 Dec 2004, Ron Johnson wrote: >> >> >>>On Sun, 2004-12-12 at 02:18 +0100, Robert Millan wrote: >>> >>>>On Tue, Dec 07, 2004 at 01:06:11PM +0900, Clemens Schwaighofer wrote: >>>> >>>>>>True, the Koran just invites to kill your ennemy bloodily, that's very >>>>>>different... >>>>> >>>>>Thats wrong, thats just an interpretion. >>>> >>>>I wonder how could text be written such that the question wether it invites >>>>to kill someone bloodily is open to interpretation. >>> >>>Are there other places in the Koran that say different things? >>> >>>An example from the Bible: the Old Testament says that homosexuals >>>must be stoned to death, >> >>Nonsence, people were to be stoned for many things, but homosexuality was >>not one of them. > > > You're right. It doesn't say "stoned". However, "they shall > surely be put to death", is, how shall we say, a superset of > "stoned to death". Therefore, I was close enough. > > Leviticus 20 > > 13 If a man also lie with mankind, as he lieth with a woman, > both of them have committed an abomination: they shall surely > be put to death; their blood shall be upon them. > That's not anti-homosexual, that's anti-bisexual. "as he lieth with a woman" implies that he has to lie with women the same way as with men for it to be applicable. -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GAT/CM$/CS>$/CC/IT$/M/S/O/U dpu s+:++ !a C++$>C+++$ UB+++>$L$*-- P+>++$ L+++()$ E-(---) W+++>$ N(+) o? K- w--(---) O? M V? PS++@ PE-@ Y+@ PGP++(+++)>$ t? 5? X? R tv--(-) b++(+++)@ DI? D? G e-> h* r? z* --END GEEK CODE BLOCK-- David Mandelberg [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
Hi, On Tuesday 14 December 2004 23:35, Josselin Mouette wrote: > First, please don't send mails to the BTS with a local address. > > Le mardi 14 décembre 2004 à 20:06 +, [EMAIL PROTECTED] a Yes, how I cursed that one, once I realised it had got out. I sent three ITPs, and one made it out wrong. I knew some one would spot it, nonetheless ;) > > * Package name: libxbox-dev > > Version : 0.1.0 > > Upstream Author : David Pye <[EMAIL PROTECTED]> > > * URL : http://www.xbox-linux.org > > * License : GPL > > Description : Libxbox-dev provides the headers for libxbox0 and the > > libxbox.so symlink > Why do you need to make it a separate source package? Ah. So that's what I did wrong, maybe. The two packages build from the same source. Does that mean a single ITP is necessary? I have not raised ITPs before, so was not sure exactly. One question this raises in my mind: suppose I have a single source tar.gz, that I want to build into four debian binary packages, with different names (obviously). If this should require only one ITP, which package name should the ITP be made for? David -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s-: a-- C++ UL P L+++ E--- W++ N+ o+ K- w--- O M V- PS+ PE+ Y+ PGP t 5- X+ R- tv+ b+ DI++ D+ G+ e++ h--- r++ y++ --END GEEK CODE BLOCK--
Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink
On Tuesday 14 December 2004 23:35, Josselin Mouette wrote: > Why do you need to make it a separate source package? No, no, ignore my last email. I 'get it' now. It for some reason escaped my notice that the ITP needed only to be raised against the source package, and not the multiple binary packages it would spawn. D'oh. Sorry, I'll close this spurious ITP. David -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s-: a-- C++ UL P L+++ E--- W++ N+ o+ K- w--- O M V- PS+ PE+ Y+ PGP t 5- X+ R- tv+ b+ DI++ D+ G+ e++ h--- r++ y++ --END GEEK CODE BLOCK--
software raid question/confusion
I installed the mdadm package recently. version 1.3.0-2 I do not want the md devices to be started when I reboot the server. I cannot find the config file which specifies this. The only way I was able to stop this was to edit /etc/init.d/mdadm-raid. I can't even find what process is calling mdadm-raid. Please advise. --David Dougall
Re: software raid question/confusion
That file does not appear to exist. I did find the links in /etc/rc0.d, rcS.d and rc6.d after the fact Why is it "starting" the raids in runlevel 0 and 6 anyway? That seems a little weird. Also, I have AUTOSTART=false in /etc/mdadm/debian.conf. But, the script jumps to the next else statement if it is not set to true and therefore will automatically start the raids anyway. I have no problem editing the scripts, but I don't want them to be overwritten when I upgrade the package later on. I was hoping that a config option somewhere would do the trick. If I delete the debian.conf file, it will not start the raids. Will this file get replaced during an upgrade? If I symlink it to /dev/null or something ugly like that, will it work? Thanks --David Dougall On Wed, 15 Dec 2004, Jose Luis Painceira wrote: > David Dougall wrote: > > > I installed the mdadm package recently. version 1.3.0-2 > > I do not want the md devices to be started when I reboot the server. I > > cannot find the config file which specifies this. The only way I was able > > to stop this was to edit /etc/init.d/mdadm-raid. > > I can't even find what process is calling mdadm-raid. > > Take a look at /etc/default/mdadm > > Regards, > Jose Luis Painceira > > >
Re: OSPF and distance vector routing source code
On Dec 17, 2004 at 09:44, j.s.dhilip praised the llamas by saying: >hello, > Would you please told me how can I get source code for OSPF? > Makes a nice change from dualling banjos. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: MPEG in general Was: Is anyone packaging `lame' ?
Florian Weimer wrote: Is only MPEG Layer III patent encumbered ? How about the other MPEG stuff ? I find it hard to believe that it is all patent-free. It's all encumbered with patents. Encoders *and* decoders. Yes, but how is then there a ton of MPEG code in debian (Sarge), but LAME is "banned" ? What is the difference between LAME MPEG code and other MPEG code ? Regards, David Balažic
Re: Bug#293055: ITP: rails -- MCV ruby based framework geared for web application development
On Mon, Jan 31, 2005 at 03:52:01PM -0600, Adam Majer wrote: > Package: wnpp > Severity: wishlist > Owner: Adam Majer <[EMAIL PROTECTED]> > > * Package name: rails > Version : 0.9.5 > Upstream Author : David Heinemeier Hansson > * URL : http://www.rubyonrails.com > * License : MIT > Description : MVC ruby based framework geared for web application > development > > Rails is a full-stack, open-source web framework in Ruby for writing > real-world applications. > > Being a full-stack framework means that all layers are built to work > seamlessly together. That way you don't repeat yourself and you can > use a single language from top to bottom. Everything from templates to > control flow to business logic is written in Ruby. I worked on a package for this throughout the weekend, and while it's not done I've made some considerable progress on it. If you'd like help or a comaintainer, let me know. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293055: ITP: rails -- MCV ruby based framework geared for web application development
On Tue, Feb 01, 2005 at 12:32:31PM -0600, Adam Majer wrote: > David Nusinow wrote: > > >I worked on a package for this throughout the weekend, and while it's not > >done > >I've made some considerable progress on it. If you'd like help or a > >comaintainer, let me know. > > > > > > For the package, I essentially want to take rails and stuff it (minus > the non-software stuff in upstream tarball) in /usr/share/rails/ with a > deployment script in /usr/bin. Then you'll be able to type `rails > my_app` and empty rails framework would deploy to `pwd`/my_app. > > The /usr/bin/rails script will also have a -P,--production switch that > will deploy the framework for production environment (ie. no docs or > unneeded parts of the framework). > > I will be using rails next week so the package will be ready by end of > the weekend. > > What does your package look like? Do you have a place where I can > download it? Just like you envision, but it's not functional yet, mainly due to the activerecord/actionmailer stuff not being done yet. The rails script works partially, but chokes when it reaches these items, because I haven't put them in to /usr/share/rails yet and patched the rakefile to look there for them. I like the -P switch, although there is already a rakefile target that pretty much does what you suggest. I made a modified version of the target for my own needs, also minus docs and such. I'll try and upload my package to people.debian.org/~dnusinow tonight so you can have a look. I think I've managed to detach it from depending on rubygems, but it still requires rake, which is contingent on you :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bad Sig (was: Re: Diversion of APT tools by dpkg-cross (apt-get,apt-cache,apt-config))
On Wednesday 02 February 2005 10:21, Adrian von Bidder wrote: > On Tuesday 01 February 2005 21.49, Raphael Bossek wrote: > > Message was signed by [EMAIL PROTECTED] (Key ID: 0x376941AB835EB2FF). > > Warning: The signature is bad. > > Something's broken somewhere... > > Can anybody confirm so I can stop worrying about my set up? Me too, but I noticed an escaped >From in the message and didn't investigate further. Regards, David # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293561: ITP: player -- music player and organizer for GNOME
On Feb 04, 2005 at 13:39, Steve McIntyre praised the llamas by saying: > Dan Korostelev wrote: > >Package: wnpp > >Severity: wishlist > >Owner: Dan Korostelev <[EMAIL PROTECTED]> > > > >* Package name: player > > Version : 0.1pr1 > > Upstream Author : Milosz Derezynski <[EMAIL PROTECTED]> > >* URL : http://linux-media.net/player/ > >* License : GPL > > Description : music player and organizer for GNOME > > > > Player is a graphical music player and organizer for GNOME 2 > > desktop environment. > > > > It uses GTK+ for its user interface, GStreamer for playback and > > SQLite for working with music database. > > > >(expect packages soon on http://mentors.debian.net/, we still need > >libvisual to be packaged and uploaded.) > > Please use a less generic name. "player" alone means very little and > is likely to cause confusion. > Also, what advantages does player have over muine or rhythmbox? The UI looks identical to rhythmbox, but without some useful features, like being able to output to more than just alsasink. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
On Monday 07 February 2005 16:17, Lars Wirzenius wrote: > ma, 2005-02-07 kello 16:50 +0100, Mike Hommey kirjoitti: > > Debian is a distribution which tries to provide good software, implying > > changes if necessary. > > I completely agree with this. If changing a program makes it better, > Debian should do it even if upstream doesn't. Such changes should be > justified, of course; preferably explicitly. > > > Wireless interfaces should be called wlan%d, not eth%d > > Why is this important? Why does the name of a network interface matter? > All the tools in Debian that can deal with network interfaces are > neutral about the name and the name isn't particularly significant to > users either. If one is worried about which interface name corresponds > to which physical device, guessing from the name is not a good way. > Using ifconfig or iwconfig or other tools to do it is a better way. ifrename can of course be used to rename an interface, and it is also worth noting that MadWifi uses ath%d, and the RealTech driver uses ra%d. Obviously neither of these are bland as eth0 (which maybe implies wired), but wlan%d is by no means a standard. David > > (I'm not saying that using wlan%d is bad or wrong, I am asking for > justifications for that name over eth%d.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294209: ITP: reminiscence -- REminiscence is a rewrite of the engine used in the game Flashback from Delphine Software
On Feb 08, 2005 at 14:08, Niv Altivanik praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Niv Altivanik <[EMAIL PROTECTED]> > > > * Package name: reminiscence > Version : 0.1.2 > Upstream Author : Gregory Montoir <[EMAIL PROTECTED]> > * URL : http://membres.lycos.fr/cyxdown/reminiscence/ > * License : GPL > Description : REminiscence is a rewrite of the engine used in the game > Flashback from Delphine Software > > Description: free implementation of Delphine Software's FlashBack engine > REminiscence is an engine capable of runing any game based on the > FlashBackengine. > . > To actually make use of ScummVM, you currently need to get the orginal > FlashBack game data-files > Did you mean ScummVM there? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is /.udev for ?
GOMBAS Gabor wrote:
> ... which would mean that it would become unaccessible (and thus
> meaningless) as the real /var gets mounted later in the boot process.
> You cannot reliably put it under a directory that is not guaranteed to
> be on the root file system; that leaves roughly /, /etc, /bin, /lib and
> /sbin. Pick your favourite :-)
What about this:
TMPDEV="`mktemp -d /tmp/devXX || { mkdir /.dev; echo -n /.dev; }`"
mount -o bind /dev $TMPDEV
mount -t tmpfs none /dev
mkdir /dev/orig
mount -o bind $TMPDEV /dev/orig
umount $TMPDEV
rm -rf $TMPDEV
This way there's no clutter in / and the original dev is mounted in a valid
place that won't get overmounted later. It's also fhs compliant I think.
signature.asc
Description: OpenPGP digital signature
Re: what is /.udev for ?
Adam Heath wrote:
> On Wed, 9 Feb 2005, David Mandelberg wrote:
>>TMPDEV="`mktemp -d /tmp/devXX || { mkdir /.dev; echo -n /.dev; }`"
>>mount -o bind /dev $TMPDEV
>>mount -t tmpfs none /dev
>>mkdir /dev/orig
>>mount -o bind $TMPDEV /dev/orig
>>umount $TMPDEV
>>rm -rf $TMPDEV
>
>
> Unless of course /tmp is mounted /tmpfs later.
That's why nothing is used in /tmp for very long, the $TMPDEV dir is unmounted.
signature.asc
Description: OpenPGP digital signature
Re: /etc under svk
On Friday 11 February 2005 18:50, Ricardo Mones wrote: > On Fri, 11 Feb 2005 18:36:04 +0100 > > Enrico Zini <[EMAIL PROTECTED]> wrote: > > And a question: where do we collect this kind of tips? > > Create a debian-tips package :) Like fortunes-debian-hints? Description: Debian Hints for fortune This package provides a set of hints and tips on using Debian, in a fortune database format. New Debian users (or administrators) may find its advice particularly sage or helpful, and even veteren Debianites might find some new tidbits. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: runlevel and sequence point for gfs cluster infrastructure
On Sunday 13 February 2005 18:47, Bastian Blank wrote: > I currently try to get gfs and the cluster infrastructure into a usable > state. One of the problems are the runlevel and sequence point settings > for each step. Take a look at the NFS packages, while I'd venture that PCMCIA NICs are irrelevant for GFS Clusters, the main question is whether you need GFS for mounting /usr. If you do, the node will be unusable anyways, if you don't GFS can be started late. Other services depending on CMS and GFS have to be brought online later anyways. Regards, David PS: have you received my private inquiry regarding the status of your packages I sent you two weeks ago? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295171: ITP: libformatr-ruby -- perl-like formats for ruby
Package: wnpp Severity: wishlist Owner: David Nusinow <[EMAIL PROTECTED]> * Package name: libformatr-ruby Version : 1.09 Upstream Author : Paul Rubel <[EMAIL PROTECTED]> * URL : http://formatr.sourceforge.net/ * License : GPL or Ruby's other licensing terms (see ruby package) Description : perl-like formats for ruby This library provides an easy way to create output with similar formatting but changing values. It is styled after perl's built-in format capablities. This package is basically done as far as I can tell. It's located at http://people.debian.org/~dnusinow/libformatr-ruby/ for those who want to try it out. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: all new Debian diagram - now with less chaos!
Hi Kev, list! On Tuesday 15 February 2005 08:27, Kevin Mark wrote: > after my initial work on a diagram, and the comments and the work of > madduck, ÂI had some time to redo my diagram to produce a totally new > concept. any comment appreciated. Really nice and clean. Great to see such fundamental processes documented properly! Some things though, perhaps someone can help me out here: * buildd: there is more than one of them and I always thought the results are checked (and signed) manually by the buildd admins? * propagation from experimental to unstable: I always thought that required a re-upload? * "testing packages propagate to stable" is perhaps better called "release: testing becomes new-stable"? Regards, David
Re: Automatic building of (parts of) the archive
On Friday 25 February 2005 18:43, Frank Küster wrote: > in order to test whether packages that build-depend on tetex can still > be built with the upcoming version 3.0, I would like to automatically > build as many of these packages. Take a look at pbuilder. There are people recompiling the whole of debian regularily with pbuilder. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: splitting a source package into 2 source packages
On Saturday 26 February 2005 08:45, sean finney wrote: > so i'm thinking these two packages should be generated from their own > respective tarballs (and i'm not sure why they weren't in the first > place). however, one thing that's not clear to me is whether or not the > new second source package will have to make it through the NEW queue. > if it does, this is a problem given that NEW seems to be stalled and the > previous version of the package will be totally broken when the other > is updated. Upload it to experimental. When the packages reach it after NEW-processing, you can re-upload them to unstable without any delay. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: [OT] maildir (was Re: procmail and Large File Support)
On Monday 28 February 2005 01:51, Ron Johnson wrote: > On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote: [snip] > > figuring the average email is about 13-15k, i believe an ext2/ext3 > > That seems awfully huge. In my (Maildir) archive of d-u, the > average size is 4,959 bytes. Of course, there are no html mails. > Though, even in my Evolution list archive, where there are many > more html-mails, the average size is only 6,097. I ran statistics on maildirs of the university (of arts) mailserver I administer: ~90k per mail. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
PROMPT RESPONSE NEEDED.
ATTN: READ CAREFULLY, Compliments of the season.I have to start by introducing myself to you.I am Dr.Mark David,the Head of Delegation to the WorldBank in West Africa.I am the linkman between the Organization For Petroleum Exporting Countries -OPEC and the petroleum sector in a West African country. I also attend OPEC meetings constantly in Geneva on the auspicies of World Bank.I am 54 years of age and with 26 years experience. I got your contact on the internet and wants to contact you for your assistance in transaction which invovle the transfer of money to an account.Sincerely, i want us to discuss about this transaction as partners.Through the sale of our allocated oil quota in OPEC, I was able to make US$25.5million, which is currently deposited in a Security company in Europe. I want you to assist me to claim this money as I cannot claim It directly because I am still a civil servant, and the code of conduct Bureau forbids me to acquire such amount of money. It is on this basis that I am contacting you for assistance, if you will be interested, Claim documents have been processed and will be sent to you. The Documents with which the fund is deposited will be changed to reflect You as the new beneficiary so that you will be eligible to collect the fund on my behalf.I will give you 30% of the fund for this assistance while 60%will be For me and 10% will be for expenses that may be incurred on both sides. I am aware of the international monitoring of all large-scale financial Movements after the September 11th 2001 terrorist attack on United States of America and to avoid any state of financial investigation I will provide a classified clearance paper from the relevant body which will exonerate the money from either drug, money laundered or terrorist related proceeds. Kindly respond to this mail indicating interest. I want to assure you that there is no risk attached in this transaction. You should also provide me with your private telephone and fax numbers for easier communication. I await your propmt response. Best regards, Dr. Mark David.
Key management using a USB key
Hi all, first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. Things which I've considered so far: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? o Password entry, it's a hassle to enter 10 different passwords, what would be the best way to reduce the number of password entries? dm-crypt to mount an encrypted file on the USB key and then have the gpg and ssh keys unencrypted within? The login to X/console etc could then maybe be performed using libpam-usb [1] so that only the password for the dm-crypt filesystem is needed? o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? o Automagic setup. Hopefully, some scripts in conjunction with udev/hotplug/pmount/whatever could make everything "just work" (tm) when the key is inserted. o USB key removal, how should it be handled if the key is physically removed during a session? Maybe kill the agents and run xscreensaver until the key is reinserted... o Permissions, how are these handled when the key moves between systems where my userid might differ? o Other issues? It would be very interesting to hear how others manage this... Kind regards, David [1] http://bugs.debian.org/234134 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UK Meetings
On Mar 08, 2005 at 14:40, Ben Hill praised the llamas by saying: > On Mon, 2005-03-07 at 23:52 +, Will Newton wrote: > > Try the debian-uk list: > > > > http://www.chiark.greenend.org.uk/mailman/listinfo/debian-uk > > Perfect, thanks! > You may also want to join #debian-uk on OFTC too, which is where most of us hang out. > -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Mar 08, 2005 at 14:58, Ben Hill praised the llamas by saying: > On Tue, 2005-03-08 at 00:46 +0100, David Härdeman wrote: > > first of all, this might be slightly off-topic for the debian-devel > > list, but I've got the impression that it's already been solved by some > > DD's and might prove interesting to others (including non-DD's such as > > me). > > I use a very small USB key for my gnupg and ssh keys. I had created > the .gnupg and .ssh directories in my home a long time ago, so I > formatted the USB device as ext2, and copied the two directories to the > USB device as ssh and gnupg. > Ideally I want to keep the disk formatted as vfat so it is usable on other operating systems and use an ext2 loopback filesystem. Getting the system to mount that is the hard part. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 02:30:06AM -0500, sean finney wrote: well, me wanting to do things the "right way" it ended up being a pretty long script and i didn't think the list would appreciate random shell scripts flying around. but, i'll go ahead and put it online: http://www.seanius.net/linux/keyloader/usb-storage Thanks Sean and everyone else for contributing. Based on the above script and the suggestions from everyone else, I've got a basic idea of how I'd want this to work: o usb key contains a vfat filesystem with two special files, one names the user for the "keychain", while the other is a storage file to be used as a loopback drive. o use the keychain script sean mentioned to keep one ssh-agent running per user no matter how many sessions (which has other advantages than those relating to usb key management). o when the usb key is inserted, the user is prompted for a password to the encrypted loopback file which is then mounted, the ssh keys within are fed to ssh agent, and the file is unmounted again. Pros: o the ssh key only exists in the memory of the ssh agent (except for a short time period when the loopback file is mounted) o hopefully, in combination with libpam-usb and/or libpam-mount, it would be possible to reduce the number of password prompts to one. o vfat filesystem means that the key is usable on most OS:es (as a normal data carrier) and that it can be easilly backed up and recreated. Meanwhile the loopback file allows for the features one expect in a unixy system such as proper permissions etc. Cons: o Only I've come up with so far is that there will be some dependencies which might not be available on any host computer. And that the keys wont be usable at all should one need to use them on a windows computer (if they are locked into a ext2-loopback file that is). Bonus stuff: o It would be a neat trick to have the keys which were once loaded from the usb key into the ssh agent automatically removed from the agent when the key is removed from the computer (meaning you could quickly yank the key, go for lunch, return, reinsert it and continue working). o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. o check both at insertion time and at "first login" time for the usb key (so that the key can be either inserted from boot or inserted during an existing session). I'll probably keep the main vfat partition mounted for access to general data stored on the key while it is inserted, a neat trick would then be to automatically remove the keys from the ssh agent which were once upon a time loaded I have started working on some scripts to do the above. Currently, they consist of three parts: o a udev rule file which gives a special device node to the usb key o a /dev/udev.d file which is run after the node is created that does the necessary root-level setup and then calls o a user-specific script which loads the keys (and prompts for necessary passwords) etc. I think this setup should allow all the bonus stuff to be implemented as well. The only real problem I've found so far is bug 290324 (http://bugs.debian.org/290324) which makes it hard to have "user-mounted-dm-crypt-over-loopback-device" goodness, and the patch attached to that bug seems to have bitrotted a bit. I'll get back to you when I have something real to show. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 07:29:20AM -0600, Steve Greenland wrote: On 07-Mar-05, 17:46 (CST), David H?rdeman <[EMAIL PROTECTED]> wrote: o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? While you might store the revocation certificate (RC) on *a* key, I certainly wouldn't store it on *the* key. If you lose the usb key with the gpg keys, you do want to be able to revoke them, right? Since the RCs are not something I need regularly, I put mine on a couple of CDs, and printed a copy (worst case). Sorry, I was being vague. I did of course intend to have the revocation certificates on the key in *addition* to alternative forms of storage. My concern was rather if there was any problems with this. As far as I can understand, all that a malicous persom who found the key could do with the revocation cert would be to revoke my gpg key right?...which would not be a problem as I would have to assume the worst and perform the revocation anyway should the usb key be lost. So the revocation could even be stored in cleartext on the usb key, unless I'm mistaken? Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Wednesday 09 March 2005 01:42, David Härdeman wrote: > So the revocation could even be stored in cleartext on the usb key, > unless I'm mistaken? Depending on the strength of the crypto/passphrase protecting your key, this could lead at least to a DOS if the revocation is publicised without compromising your keys. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Cron-standard package to replace current tasks in 'cron'
On Wednesday 09 March 2005 15:20, Javier FernÃndez-Sanguino PeÃa wrote:
> - Basic system accounting (implement in sysstat)
> - Basic logfile reporting (implemented through logcheck)
> - Basic security checks (implemented through checksecurity and Tiger)
> - Integrity file monitoring (through tripwire, aide, integrit or samhain)
> - Check if the system is up-to-date (using cron-apt or apt-watch,
> this requires an Internet connection)
> - Basic database backups (for both MySQL and PostgreSQL if they are
> installed)
> Following mechanisms similar to those described at
> http://www.redhat.com/docs/manuals/database/RHDB-2.1-Manual/admin_user/back
>up.ht ml
> - Basic filesystem analysis (checksecurity implements this but it should
> probably be moved here)
> Like in: http://shelldorado.com/scripts/cmds/checkfs.txt
> - System's user accounting (maybe using sac?)
Why {c,sh}ouldn't they be implemented as cron.daily scripts in the respective
packages?
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Cron-standard package to replace current tasks in 'cron'
[Please don't confuse my procmail with Cc's]
[http://www.debian.org/MailingLists/#codeofconduct]
On Wednesday 09 March 2005 16:16, sean finney wrote:
> On Wed, Mar 09, 2005 at 04:00:49PM +0100, David Schmitt wrote:
> > Why {c,sh}ouldn't they be implemented as cron.daily scripts in the
> > respective packages?
>
> i'd like to ack that. however, if the non-arch specific stuff (generic
> cron jobs, init scripts, etc) for cron is still sufficiently complicated
> it might make sense to have an Arch: all cron-common type package.
I am not against a cron-common-jobs package. Quite to the contrary.
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. [...] It would be very interesting to hear how others manage this... Ok, based on the script from Sean Finney and the feedback from the others (thanks all!). I've written a rough draft of how *I* would like things to work. It's divided into three parts, and also requires the keychain tool[1]. The first file, is a simple udev rule which creates a /dev/cryptdisk node when the appropriate usb key is inserted (proper as decided by the various conditions which one can list in a udev rule). It can be placed in /etc/udev/rules.d/cryptkey.rules. Then, a script which is run after the appropriate device node is created or removed. This script is plopped into /etc/dev.d/block/cryptdisk.dev. This script mounts the drive, checks who it belongs to (by reading the "keyowner" file in the root dir of the USB key), mounts it again with the proper permissions for that user and then calls the third piece. The third script, which is run as the user who "owns" the key, loads the ssh keys from the usb key and into ssh-agent. The advantage is that this script can also be called from eg. .xsession to load keys from usb devices which were already present during boot. It also allows one to load keys even if X isn't running. The scripts are a bit rough at the moment, I wrote them in a hurry, but I'll clean them up a bit more later, I wanted to get something through the door. They "work-for-me" right now (loading keys, with ssh-askpass dialogue, and removing them when the usb key is removed). I'll work more on the scripts during the weekend (adding some of the TODO's, documentation). Regards, David [1] http://www.gentoo.org/proj/en/keychain/index.xml [2] http://www.hardeman.nu/~david/keyload/ PS Right now, the scripts are licensed under a "david-owes-sean-a-pizza" license =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 11:28, Thomas Bushnell BSG wrote: > In this case, it was a bug that required human intervention, a package > upload that accidentally would hose a chroot, which required the > chroot to be repaired for each affected buildd. Even that can be mitigated by debootstrapping the chroot once a day automatically. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 11:10, Rene Engelhard wrote:
> pcc is barely at 98%. I don't think that barrier should be that high. We
> *should* at last release with the tree most important archs: i386, amd64,
> powerpc.
Please, 98% is not high. It is just a call to porters to get their act
together.
I don't believe that any (sane) maintainer would refuse FTBFS fixing patches
(see hurd-i386 and k{net,free}-bsd stuff). These criterions are just a IMHO
necessary step to put the load on those people who want to use the arch
instead of those who maintain central infrastructure.
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 12:21, Ingo Juergensmann wrote: [...] > but in fact this is already a decission being > made by just a handful of people without asking those who will be affected > by that decision. I always thought those who do the work, also get to make the decisions. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 11:00, Sven Luther wrote: > On Mon, Mar 14, 2005 at 01:14:47AM -0800, Steve Langasek wrote: > > There are a few problems with trying to run testing for architectures > > that aren't being kept in sync. First, if they're not being kept in > > sync, it increases the number of matching source packages that we need > > to keep around (which, as has been discussed, is already a problem); > > second, if you want to update using the testing scripts, you either have > > to run a separate copy of britney for each arch (time consuming, > > resource-intensive) or continue processing it as part of the main > > britney run (we already tread the line in terms of how many archs > > britney can handle, and using a single britney check for archs that > > aren't keeping up doesn't give very good results); and third, if > > failures on non-release archs are not release-critical bugs (which > > they're not), you don't have any sane measure of bugginess for britney > > to use in deciding which packages to keep out. > > What about building the scc (or tier 2 as i would say) arches from testing > and not unstable ? this way you would have the main benefit of testing (no > RC bugs, no breakage of the day kind of problems). I'm only guessing: because keeping those archs in testing didn't work out and is (broadly) the cause dropping them in the first place? > > For these reasons, I think the snapshotting approach is a better option, > > because it puts the package selection choices directly in the hands of > > the porters rather than trying to munge the existing testing scripts > > into something that will make reasonable package selections for you. > > So, why don't you do snapshoting for testing ? Do you not think handling > all those thousands of packages manually without the automated testing > thinhy would be not an over-burden for those guys ? Obviously britney/dak is available from cvs.d.o and meanwhile also as debian package. So the question for me (administrating two sparc boxes) is why _we_ don't setup our own testing when obviously the ftp-masters and core release masters are not willing to do the work for us? My answer is that I don't care enough for tow out of 15 boxes for the hassle, I will update them to sarge, be grateful for the gracetime given and - iff nobody steps up to do the necessary porting and security work - donate them to Debian when etchs release leaves my current nameserver without security updates. What would you say, if I asked you to provide security support for sparc because _I_ need it for my nameservers? > You are really just saying that the testing scipts don't scale well, and > instead of finding a solution to this, you say let's drop a bunch of > architecture, and make it another-one's problem. I think you have hit the point of this reorganisation head on: the people who did the work until now, feel that they cannot do the work with the expected quality _and_ the current number of arches. Thus they make the hard decision to put down hard, objective and verifyable rules where everyone can decide whether an arch deserves use of central Debian resources like mirrorspace on the central network. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 11:05, Sven Luther wrote: > > > > Andreas Schuldei (DPL candidate) > > > > Angus Lees (DPL candidate) > > > > Branden Robinson (DPL candidate) > > > > Jonathan Walther (DPL candidate) [...] > And how do you reconcile the fact that most of those told us recently on > debian-vote that they believed that dropping an architecture will not help > with the delay of the release ? And giving the times of the posts, they > probably knew about this plan previously to replying that, especially those > of the scud team. Pure demagogy then ? I cannot remember[0] a question to the candidates regarding architecture-dropping. The only question pertaining the release[1], was only answered by Matthew Garret, saying that "it would be helpful if (in future) the release team would communicate their list of release criteria well in advance of their estimated time of release." Which obviously happened now. Please point me to the posts, so I can add it to my page[2] Regards, David [0] And I should know, I maintain [2] [1] http://debian.edv-bus.at/vote-2005/release-strategy.html [2] http://debian.edv-bus.at/vote-2005/ -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 10:56, Aurélien Jarno wrote: > I think that supporting a lot of architectures is an important > difference between Debian and other distributions. Changing that could > have a dramatically influence of what users think of Debian. IMHO, such > an important decision should not be taken by a few developers. Maybe a > vote is need... Since this is already the second time, I see someone calling for a vote, I just want to note, that no vote in the world could force someone to do work he is not willing to do. Forcing RMs to resign via vote would leave Debian in a much worse state. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 03:24:06PM +0100, Aurélien Jarno wrote: > What about partial mirroring to address space problems? What about a > team for wanna-build so that help and machines are not refused anymore? > What about a team for buildd so that there is always an admin available > at a given time? > > Maybe it doesn't work, but at least we have to try, before dropping > arches. Because it's clear that SCC arches will be dropped sooner or > later, if they are considered by debian-developers as "secondary arches". What about the *massive* issues with releasing d-i due to syncing on all arch's? What about the various arch-specific kernel issues that have popped up and the problems in getting people to make all the necessary fixes? What about the huge problems in getting a decently new release of X in to Debian because of constant porting problems? What about the heavy burden on the security team? The problems extend beyond the mirrors and the buildds. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 12:05, Robert Lemmen wrote: > - there must be a way for a scc arch to get a stable release. why don't > we either keep testing for scc archs but not do releases, so the > porters can do their own stable releases of their arch or have > per-arch testing? (the latter might lead to a source package explosion > i think) AFAI can tell, anybody can host an archive of packages built from stable sources for a scc or unofficial port. And - if I read the conditions on becoming a fully supported Debian arch right - then having security support for an external pool of this arch is a good indicator that it should be a fully supported stable release (amongst other things). If on the other hand nobody can be found to recompile packages after DSAs are released for this arch, I believe the arch shouldn't be released for Debian as stable. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Do not make gratuitous source uploads just to provoke the buildds!
On Monday 14 March 2005 15:31, Goswin von Brederlow wrote: > Andreas Barth <[EMAIL PROTECTED]> writes: > > * Hamish Moffatt ([EMAIL PROTECTED]) [050314 01:45]: > >> On Sun, Mar 13, 2005 at 11:16:56PM +0100, Andreas Barth wrote: > >> > Our goal is that the queue gets empty from time to time, and so, > >> > priority shouldn't prevent a package from being built. > >> > >> How often should the queue be emptied, or when will an architecture be > >> declarared not-keeping-up? > > > > In light of > > http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html > > the release architecture must have N+1 buildds where N is the number > > required to keep up with the volume of uploaded packages > > at least once per day for etch. > > That means no more m68k. Given that some packages compile up to 12 > days there will be plenty of times the queue doesn't empty once per > day. Perhaps that was a slight misunderstanding: the Nybbles only require "the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages" with N <= 2. The part about emptying once per day was only added by Andreas. Considering the effects of a twelve-day build of something big like KDE, GNOME or X: delays in security updates, shlib-deps, build-depends and testing migration, I can see the roots of the requirements on buildds. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 09:23:54AM -0600, John Goerzen wrote: > On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote: > > Basically, you're just leaving a number of Debian users out in the > > cold. Users who choose Debian because we were the only distribution > > out of there to provide serious support for the architectures they > > care for, for various reasons. > > Indeed. I am one such user. I have always felt fortunate that I don't > have to really care what architecture a machine is, because "of course > it runs Debian". I have run Debian on Alpha, x86, amd64, powerpc, and > sarc systems, both as a desktop and a server environment on most of > these. > > Here's a key point: the utility of Debian on x86 is greatly diminished, > for me, if I can't run Debian on alpha (or arch x) also. > > Why? Because having an environment that works exactly the same across > multiple architectures is a Good Thing. If I will no longer be able to > achieve that, then Debian on x86 becomes seriously less useful, because > now I'll have to maintain some Debian machines and some Gentoo machines > or something. It would be easier for me to just maintain all Gentoo > machines. I'm pretty amazed that people are saying that without being an FCC that their arch will simply die. I don't understand why the porters, who've been so quick to point out that they'll host and maintain buildd's, aren't willing to simply track unstable and set up their own buildd network for their port. The m68k guys did it. So did amd64. dak is now in the archive, and sbuild has been there for ages. Quite frankly, I'll be shocked if m68k or anyone else doesn't make their own etch release within days of the official one. > > I feel sad today, I feel it is a sad day for the Project. > > I agree, and I too am quite sad that a number of DPL candidates signed > off on this without asking hard questions about it or even putting it > out for discussion and feedback first. I disagree. I dislike the cabalistic feel of this whole thing, but it's a step forward that needs to be taken, and I don't think anything would have moved otherwise. I trust this group of people to know what they're doing, since they've demonstrated their abilities and value time and again. I'm very happy about this proposal. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 14:29, Sven Luther wrote: > Obviously the aim is to have the tier 2 > arches dropped from the main ftp-servers of debian (do we still run some of > those on sun-donated sparc machines though ?), and going into alternate > solutions like the amd64 move on alioth or whatever, which i think is a > broken concept. In my reading of the proposal, not-tier-1 arches will receive appropriate space and resources off the main mirror network if they can demonstrate viability (working buildd, basic unix functionality, compiled 50%, 5 developers, 50 users) and DFSG-ness (freely usable, unmodified Debian source). As far as I can see all current official Debian arches fulfill these criteria. For the in-development arches like k*bsd with a handful of developers and a extremly small userbase other solutions are already used. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 04:37:36PM +0100, Matthias Urlichs wrote: > Hi, David Nusinow wrote: > > > What about the *massive* issues with releasing d-i due to syncing on all > > arch's? > > Yeah, and *after* these were solved, it was "oops, we still can't release > because of $different_problem". > > Such things are somewhat more parallelizeable than has happened during > this release cycle. Manpower is limited, and I'd rather have manpower be the limiting factor than machine power. Currently, the d-i issues are incredible. Have you read what joeyh has to do with his automated testing lab just to keep d-i development running at a decent pace? It's simply amazing. And to get an actual d-i release out is very difficult in practice. Passing the buck on to the other issues doesn't resolve this issue itself: a large number of arch's places a major burden on a limited number of developers of a core piece of our release infrastructure. > > What about the various arch-specific kernel issues that have > > popped up and the problems in getting people to make all the necessary > > fixes? > > If it's an arch-specific kernel, ideally it should only affect that arch. Ideally... in practice it slows down everyone, including d-i. > Recently, $ARCH was taken off testing consideration because it was behind. > If that's done somewhat more aggressively in the future, those problems > are parallelizeable too, because they don't block the whole project. In practice, this doesn't happen though. > > What about the huge problems in getting a decently new release > > of X in to Debian because of constant porting problems? > > See above. See my response as well. Where's X.org in Debian? > > What about the heavy burden on the security team? > > With a decent toolset, doing a security package for 10 architectures > should be a nearly-constant amount of work, no matter which base the > number 10 is written in. In practice, this isn't true. And it's pretty well known that the security team carries a very heavy burden as is. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
COUNT(buildd) IN (2,3) (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 14:24, Aurélien Jarno wrote: > Hamish Moffatt a écrit : > > I see it as more a practical consideration. If you can't buy the > > hardware new then you will have trouble keeping up with a growing > > unstable, especially given the requirement that you need <= 2 buildds. > > So the requirement that you need <= 2 buildds is not well choosen. Why > such a requirement? m68k prooved that having a lot of buildd is not a > problem, *if they are correctly managed* (which is the case for m68k). IANARM, but I outline the possible reasons in http://lists.debian.org/debian-devel/2005/03/msg00866.html | Considering the effects of a twelve-day build of something big like KDE, | GNOME or X: delays in security updates, shlib-deps, build-depends and | testing migration, I can see the roots of the requirements on buildds. Thus the problem is less in the development and more in the support of testing requirements (all arches in sync) and stable support (security response time). Therefore the N<=2 requirement is only needed for tier-1 arches but not for the tier-2 which will not officially release a stable. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
COUNT(buildd) IN (2,3) (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 16:27, Matthias Urlichs wrote: > If I had to think of a rationale for it, the only one I could think of > would be "the architecture needs to be fast enough not to block security > updates". This is not the only one. Taking days to build some packages also leads to shlibs-skew and problems with testing migration. Both which only affect tier-1 arches but not those in tier-2. > However, I consider an update whose $ARCH binaries are released a week > later not to be a problem. There is a fundamental problem: There are people (me included) who believe that a week delay for a security update is not acceptable. > Not when the alternate choice is to not have Debian support $ARCH at all. Please cite where this was proposed. I read the original Nybbles mail (and a part of the current thread) but couldn't find the "at all" bit. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 09:54:49AM -0600, John Goerzen wrote: > It is not unstable that I am (most) worried about. > > It is the lack of any possibility of a stable release that concerns me. > Even if the people for a given arch were to build a stable etch, it > would have no home in Debian, would suffer from being out of the loop on > security updates, etc. Well, we do know the security team needs help. What I'd love to see is each port have someone on the security team to handle their specific bugs, binary builds and testing. That might scale better and decrease the overall load on the team. This is all in line with what seems to be the central thesis of the proposal: shift more of the core burden to the porters. Of course, this does demand a lot, but the burden has to go somewhere, and the people currently carrying large portions of it are saying they can't do this any more. > > for ages. Quite frankly, I'll be shocked if m68k or anyone else doesn't make > > their own etch release within days of the official one. > > That still doesn't solve the problem of security updates, for one, and > archive space, for another. Agreed on the archive space, but I don't know what to do about that. One thing that we've seen lots of is people happy and willing to donate buildd's for their pet arch. I'd imagine those could be converted to package pool space and such. The bandwidth issue I have no answer for though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 14:50, Steve McIntyre wrote: > Lots of people on arm, for a start. Debian is (to my knowledge) the > only common distro that supports arm, so there are _lots_ of people > out there running embedded machines using bits from Debian. Look at > the emdebian project. Of course, most of those machines don't have a > net connection for popcon or downloading from mirrors so they don't > show up in the figures. AFAICS was popcon usage never stated as a requirement and if a arch isn't downloaded from a mirror, it doesn't need this part of the infrastructure. Also any arch worth it salt should be able to easily collect 50 supporting users who send mail to $survey-address. No need for popcon either. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
(Please don't cc me. I'm on-list. Thanks.) On Mon, Mar 14, 2005 at 04:06:39PM +, Alastair McKinstry wrote: > The question is: how do you release a SCC arch, if at all? > > Its unlikely that producing an s390 (for example) release for etch is simply > a matter of building the released etch on > s390. It will probably take patches to the released packages > for s390 to work. Is the s390 release etch+patches ? > There would be version skew; There would be version skew, but porters should continue to submit mainline patches as they always have. I don't see any reason at all why they shouldn't. It might be harder to actually get them in to packages in a timely manner, but we'll have to see how that all falls out. I feel like it's an unfortunate tradeoff, but in all honesty I'd rather release etch than support a lot of arch's (most of which I've personally never seen in real life) and never release. > will Security releases be available? Explicitly no, unless the porters themselves handle them. I'd imagine that getting a member of the port team on the security team would help a great deal there. Of course, that would require people coming out from their little corner of Debian and helping with core pieces, which would help the project in a huge way. > Immediately post a release, there is likely to be a flood of > RC-creating changes, as transitions that were postponed for the release are > committed; indeed this is the recommended time to do them, in order to get as > much time for stabilisation as possible, However under the proposal, any SCC > architecture build comes from unstable; Not necessarily. I imagine it such that the porters set up their own pull from unstable, the same way amd64 does now. They can set up testing themselves (remember, dak is in the archive now) so they can run their own testing in parallel to the mainline one. > so, if s390 doesn't build a working release > when FCC releases, then back to the bottom of the hill as ahuge pile of new > RC bugs arrives; it sounds highly unlikely that > the porters could get s390 unstable into a fit shape to release. I don't see why not. If the testing approach doesn't work, then there's the snapshot approach, which has worked well for every single Debian-derived distro out there. > I think the coupling between FCC and SCC architecture releases needs to be > thought > through, or at least explained, better. I'll agree there. Particularly with respect to bugs submitted by porters. > As it is, if I was an SCC arch maintainer, trying to remain in sync with FCC > changes sounds impossible under this scheme; I disagree. I think the tools are all there to do it. There's no magic to running Debian, it's just a lot of manpower and lot of scripts. > it will drive the SCC archs away from debian so that they > have some time to themselves to stabilise. Possibly, but I hope not. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 05:13:59PM +0100, Sven Luther wrote: > So you mean that all the tier-2 arches should go and take over alioth as > distribution media ? You read the answer of wiggy about this almost bringing > alioth to his knees ? Aren't scc.debian.org (or perhaps various different hosts for each SCC) part of the plan in the email? I don't think anyone wants to break alioth further. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package flow scenarios (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
[Sven, pPlease teach you and your mutt the use of reply-to-list] On Monday 14 March 2005 14:06, Sven Luther wrote: > On Mon, Mar 14, 2005 at 01:02:34PM +0100, David Schmitt wrote: [...] > No, you didn't understand. You are right. > let's tell the plan again : > > 1) people upload to unstable always. Only source are considered, and > people not having tested them and upload unbuildable sources are utherly > flamed for their lack of discern :). > > 2) the autobuilder build those packages for unstable for the tier 1 > arches. > > 3) after some time, the packages are moved to testig, as done by the > testing script for the tier 1 arches. > > 4) the tier 2 arches build their stuff from testing. there are two > results of this : > > 4.1) the package builds without problem, it is added to the tier 2 > archive. > > 4.2) the package fails to build. This used to be a RC critical FTBFS, > but is not so anymore. The porter are responsible for fixing the bug and > uploading a fixed package to unstable, as they do now. Wouldn't it be better: "The porter are responsible for fixing the bug and supplying a patch?" Of course, in the case of unresponsive maintainers, there is always the possibility of an NMU, but this shouldn't be the norm - not even with tier-2 arches. > 4.2.1) the unstable built package passes testing rather quickly, and > is then rebuild for the tier 2 arches, back to 4). > > 4.2.2) the unstable built package is held out of testing for whatever > not tier2 arch relevant issue. They can then be built in an > arch-specific way, and uploaded directly to the arch in question, or > maybe through a arch-specific-mini-testing-script. Careful: this would touch on "binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance)" from the Nybbles proposal. [benefits moved downwards for discussion] > Now, given this full description, does my proposal seem more reasonable ? Wow. I envy your ability to churn out such masses of mostly sane emails. Let me contrast this to my mind model of how Debian-flex will work in the case of a FTBFS on a tier-2 arch: 1) upload to unstable 2) autobuild for all tier-1 and 2 arches 2.1) packages builds without problem: goto 4) 2.2) FTBFS on tier-2 arch -> FTBFS bug+patch 2.2.1) maintainer applies patch with high priority: goto 3) 2.2.2) maintainer applies patch with low priority: goto 4) 2.2.3) maintainer doesn't apply the patch: goto 6) 3) package is reuploaded with porters-fix: goto 1) 4) package propagates to testing without regard to tier-2 FTBFS 5) maintainer uploads next version with porters-fix: goto 1) 6) package probably needs a porter-NMU > This would have the benefit of : > > - Not having slower arches hold up testing. Check. > - not overloading the testing scripts. Check. > - allow the tier 2 arches to have the benefit of testing, that is an > archive with packages suffering from RC bugs and breakage-of-the-day, as if > they build from unstable. All packages passing 2.1 and 4 would be eligible for a tier-2 testing. I have faith that the current discussion of the Nybbles proposal will lead to a structure allowing this. > - diminish the workload for the tier 2 autobuilders, since they only have > to build proven good packages, and not random stuff going in unstable. - > still allow the tier 2 arches to be part of debian, and hope for a sarge > release, which yields to : The Nybbles proposal explicitly says: " They will be released with sarge, with all that implies (including security support until sarge is archived)" > 5) Once a stable release is done, the above can be repeated by the tier 2 > arches, until they obtain the release quality and maybe be part of a > future stable point release. If this can be archived properly (with fast security and stuff), then the arch could also reach tier-1 status (probably without ftp.d.o distribution) > > Obviously britney/dak is available from cvs.d.o and meanwhile also as > > debian package. So the question for me (administrating two sparc boxes) > > is why _we_ don't setup our own testing when obviously the ftp-masters > > and core release masters are not willing to do the work for us? > > I guess this is also the message i get from them. The same happens for NEW > processing, and the solution is to setup our own unofficial archive, thus > leading to the split and maybe future fork of debian. "This is a dangerous time for you, when you will be tempted by the Dark Side of the Force." Let's structure that again in a list. That helps me thinking. 1) tier-2 will have its own resources[1] and support/developmen
Security Support and other reasoning (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 14:06, Sven Luther wrote: > > My answer is that I don't care enough for tow out of 15 boxes for the > > hassle, I will update them to sarge, be grateful for the gracetime given > > and - iff nobody steps up to do the necessary porting and security work - > > donate them to Debian when etchs release leaves my current nameserver > > without security updates. > > > > What would you say, if I asked you to provide security support for sparc > > because _I_ need it for my nameservers? > > There was no comment from the security team about this new plan, we don't > know for sure that this is the problem, we don't even know in detail what > the problems are and how do they relate to the drastic solutions (in france > we would say horse-remedies) proposed here. The problem I - as a system administrator - see is that waiting a week for a security update might be not acceptable. Of course there are many scenarios where there is no need for such tight security, but it seems only honest to make the difference obvious? > > to put down hard, objective and verifyable rules where everyone can > > decide whether an arch deserves use of central Debian resources like > > mirrorspace on the central network. > > But why, and is it the good/best solution ? Why did they not consult with > the arch porters before hand ? Why did they not put the announcement in a > more diplomatic and inviting way ? We are all only humans? We are all emotionally laden? I think putting down rules under which circumstances a arch is eligible for tier-1 is a good thing. This reminds me to the oft-cited "We hide no problems": for some, a week waiting until a security update is built _is_ a serious problem, for others shlib-skew and testing propagation are, others again need a working installer. Taken together these seem to make the difference between tier-1 and 2. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Mirror Network (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 18:11, Goswin von Brederlow wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > Speaking of the mirror network is a red-herring. Mirrors are not > > forced to distribute every arch; they can and should eliminate archs > > they aren't interested in distributing. > > They are. That is mirror policy for primary mirrors. That is the > reason why amd64 is not in sid and consequently not in sarge. > > Instead of dropping archs from debian mirrors should be allowed to do > partial mirrors. That would solve the space and bandwith problems for > mirrors without adverse effects to the project as such. And would break d-i, which currently provides a list of mirrors to choose from. Also notably, distribution on the main-mirror network is neither a requirement for nor a part of being in tier-1 Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 18:37, Goswin von Brederlow wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > This point is *not* about supported architectures, only about > > architectures carried by the primary mirror network. We did consider > > having a single set of requirements for both "release architectures" and > > "primary mirror architectures", and the structure of the announcement > > might still reflect that, but I couldn't justify using "percent market > > share" as a straight criterion for release architectures. > > Release should be governed by the amount of developers, if the can > keep up, if the buildd works and so on. *Quality* > > Mirroring should be governed by the amount of users (as in downloads), > the amount of traffic for an arch. No point having more mirrors than > users. *Quantity* > > There might be 100 firms downloading to their proxy and maintaining 1 > million s390 systems (VMs) with 10 million users. Does s390 then get > kicked out of the release because they download efficiently, only 100 > downloads instead of 10 million? To highlight Steves most important sentence: | This point is *not* about supported architectures, only about | architectures carried by the primary mirror network. And if s390 only needs 100 downloads per year, the don't need to be distributed on the mirrors, but can easily download from a central site. What a long ways to "Yes, you are right." Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Supporting tier-2 (was Re: COUNT(buildd) IN (2,3))
On Monday 14 March 2005 17:39, Frank Küster wrote: > David Schmitt <[EMAIL PROTECTED]> schrieb: > > On Monday 14 March 2005 16:27, Matthias Urlichs wrote: > >> Not when the alternate choice is to not have Debian support $ARCH at > >> all. > > > > Please cite where this was proposed. I read the original Nybbles mail > > (and a part of the current thread) but couldn't find the "at all" bit. > > No testing, no release, no security support. For me, that is so close > to "not support at all" that I hardly see the difference. No testing and release support by the current RMs and no security support by the current security team. Any interested developer should be able to pick up where the current powers that be have given up. > I would see things different if it was "Not part of the main testing > procedure" (using a different scheme), "Not necessarily released when > the tier 1 arches are released", "No support for tier 2 arches by the > tier 1 release managers and security teams, but we offer Debian > infrastructure for yet-to-form RM and Security teams for each tier 2 > arch". Those points either require coding (which cannot be forced upon anyone) or are not forbidden by the authors of the Nybbles proposal. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Call for help / release criteria (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 17:31, Aurélien Jarno wrote: > Frank Küster a écrit : > > - First of all, we should take the details as a starting point for > > discussion, not as a decision that has made. Nevertheless, we must > > take into account that there are reasons for it: The people doing the > > release, ftpmaster, etc. work noticed that they cannot go on like > > before. > > Why they don't ask for help? They do so now. Are you (all) prepared to take up the call? While the slower arches are not able to fulfil quality requirements for a top notch stable release with security support and everything, they surely should be able to provide their binaries as available in tier-2. I also have faith, that the security team will run security updates through tier-2 buildds but without delaying the DSAs for tier-1 arches and without having to do overnighters or something if a build fails on a tier-2 arch. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Vision for the future (was: Re: COUNT(buildd) IN (2,3))
On Monday 14 March 2005 17:16, John Goerzen wrote: > On Mon, Mar 14, 2005 at 05:03:30PM +0100, David Schmitt wrote: > > Thus the problem is less in the development and more in the support of > > testing requirements (all arches in sync) and stable support (security > > response time). Therefore the N<=2 requirement is only needed for tier-1 > > arches but not for the tier-2 which will not officially release a stable. > > Why can we just not relax these requirements, and m68k people get their > kde security updates 12 days after everyone else does, because that is a > fact of life on m68k? > > Moreover, perhaps we ought to rethink the "all arches in sync" rules for > testing a bit; maybe it's OK if some archs aren't in sync. Both are currently "happening." The current release and security teams say that they cannot support the tier-2 arches for etch. The porters jump up and prove them wrong by creating stable-with-security-updates-after-two-weeks and eventually we will have timely Debian stable releases people can trust their jobs on and Debian stable-with-security-updates-after-two-weeks releases for tier-1.5 arches I can safely install behind a firewall or in my network-free basement. Or perhaps they pickup the idea floating around somewhere else in this thread, building two or three 10-ways distcc-powered buildds suddenly fulfilling tier-1 requirements. But the latter will not be done by the current release/security/d-i/kernel/x teams. In my opinion these rules are an important step in the right direction: setting down checkable borders. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Supporting tier-2 (was Re: COUNT(buildd) IN (2,3))
On Mon, Mar 14, 2005 at 05:57:05PM +, Matthew Garrett wrote: > Reasonable security support requires some degree of cooperation with the > current security team. Without that, vulnerabilities notifications won't > be available. Why can't porters join the security team? Then everyone benefits. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 12:45, Wouter Verhelst wrote: > Op ma, 14-03-2005 te 12:38 +0100, schreef David Schmitt: > > On Monday 14 March 2005 11:28, Thomas Bushnell BSG wrote: > > > In this case, it was a bug that required human intervention, a package > > > upload that accidentally would hose a chroot, which required the > > > chroot to be repaired for each affected buildd. > > > > Even that can be mitigated by debootstrapping the chroot once a day > > automatically. > > Not really. You are severely underestimating the time it takes to do > that on the slower architectures. A current pbuilder chroot takes 121 MB (containing build-essential already). How long does a '(mv $chroot foo; rm -Rf foo & cp $stash $chroot)' take for 121 MB on $small-arch? Please enlighten me, I am really interested since I (obviously) have no clue about the orders of magnitude of performance Debian runs on. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir Ãber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 07:03:52PM +0100, Marc Haber wrote: > Will early-release information be available to the porters? Or do > porters only start building their security updates once the official > advisory has gone out? Why can't porters join the security team? > >Not necessarily. I imagine it such that the porters set up their own pull > >from > >unstable, the same way amd64 does now. They can set up testing themselves > >(remember, dak is in the archive now) so they can run their own testing in > >parallel to the mainline one. > What a huge waste of manpower, done seven times in a row. Hopefully not that huge, as the tools have already been written. Perhaps there can be a single package pool for all SCC/Tier-2 arches so it only has to be done once. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Supporting tier-2 (was Re: COUNT(buildd) IN (2,3))
On Monday 14 March 2005 19:18, David Nusinow wrote: > On Mon, Mar 14, 2005 at 05:57:05PM +, Matthew Garrett wrote: > > Reasonable security support requires some degree of cooperation with the > > current security team. Without that, vulnerabilities notifications won't > > be available. > > Why can't porters join the security team? Then everyone benefits. You are completely right. Sadly this isn't as easy as it might seem: As far as I know from the local CERT, security teams need to sign NDAs to receive notifications before they are made public. Please also see my musings about security support in my 'Vision for the future' only a few mails further up this thread. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 09:25:02PM +0100, Julien BLACHE wrote: > Sure that's good. It stops to be that good when they're obviously > trying hard to impose their employer's agenda on the Project. Sarge was already very late before Ubuntu existed. Our mirror network was already strained before Ubuntu existed. Our release team was struggling to get sarge out before Ubuntu existed. Our security team was already undermanned before Ubuntu existed. d-i was short on contributers and had a hard time releasing before Ubuntu existed. We have only ourselves to blame for where we're at now. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 11:38:29PM +0100, Julien BLACHE wrote: > >> Sure that's good. It stops to be that good when they're obviously > >> trying hard to impose their employer's agenda on the Project. > > > > Sarge was already very late before Ubuntu existed. Our mirror network was > > already strained before Ubuntu existed. Our release team was struggling to > > get > > sarge out before Ubuntu existed. Our security team was already undermanned > > before Ubuntu existed. d-i was short on contributers and had a hard time > > releasing before Ubuntu existed. > > That's very Ubuntu-centric. What about the others ? I'm not > specifically speaking of Ubuntu here. You can add Project Scud to the > list, if you'd like. Got a more specific example or are you just going to keep throwing conspiracy theories around? > > We have only ourselves to blame for where we're at now. > > At least back then we weren't trying to reduce the set of > architectures we support to match theirs. This isn't about matching with Debian-derivatives. This is about the load placed on the people doing the actual work. Are you paying attention to what the Release Managers, D-I Lead, and FTP Masters are saying? Or are you just assuming that they're out to get you? > And keeping IA64 in the loop is just another joke from the release > team. It'd be interesting to find out, but I bet more m68ks were sold > than IA64 last year. Oh no! Objective criteria! Whatever shall we do? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Requireing 98% built sources (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 22:30, Bdale Garbee wrote: > [EMAIL PROTECTED] (David Schmitt) writes: > > On Monday 14 March 2005 11:10, Rene Engelhard wrote: > >> pcc is barely at 98%. I don't think that barrier should be that high. We > >> *should* at last release with the tree most important archs: i386, > >> amd64, powerpc. > > > > Please, 98% is not high. It is just a call to porters to get their act > > together. [much agreeable stuff] > The real question on the day of release is what the build percentage of > 'testing' is for each architecture, and that's a pretty easy place to drive > the numbers near or to 100% if we think it's important enough! The 98% are a requirement to reach tier-1 with testing-major and FTBFS==RC status. As with policy changes DDs have to "show the code" first before they get the "official" stamp. As you correctly say, once an arch enters tier-1, testing should stay at >98% built. Which still forces the archto stay ahead of the 98% in unstable, I would guess that to prevent a drooping arch from delaying the whole project too much. On a tangent, some sentences I wrote before understanding your paragraph: If an arch that would be tier-1 otherwise is dropped two days before etch releases because there are only 97.999% built sources after demonstrating the ability to reach 99+% for months, I would call the decisionmaker nuts. If on the other hand the arch in question was never able to prove consistent buildd performance they probably also are not able to consistently and instantly react on security issues and have a much higher probability to cause shlib-skew and testing-propagation hold-ups. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Dropping from mirror network vs dropping from tier-1 (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Monday 14 March 2005 19:36, Sven Luther wrote: > Well, as long as the discussion is on dropping from the mirror network, > yes, you may be right, but the proposal is to drop from stable/testing > altogether, isn't it ? Quoting from the Nybbles proposal: "[...] the list of release candidate architectures will be further split, with only the most popular ones distributed via ftp.debian.org itself. The criterion for being distributed from ftp.debian.org (and its mirrors) is roughly: - there must be a sufficient user base to justify inclusion on all mirrors, defined as 10% of downloads over a sampled set of mirrors " Elsewhere I believe Steve mentioned, that earlier versions had tier-1 == ftp.d.o, but that this was dropped (exactly because of arches like s390 who should be able to reach tier-1 easily, but really have no reason to be on the mirror network). Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Security support on tier-2 (was: Re: COUNT(buildd) IN (2,3))
On Monday 14 March 2005 20:07, Julien BLACHE wrote: > Stephen Gran <[EMAIL PROTECTED]> wrote: > >> > Thus the problem is less in the development and more in the support > >> > of testing requirements (all arches in sync) and stable support > >> > (security response time). Therefore the N<=2 requirement is only > >> > needed for tier-1 arches but not for the tier-2 which will not > >> > officially release a stable. > >> > >> What is the detailed reasoning for this requirement anyway ? > > > > I thought that was fairly clear - a 12 day build of a security fix is > > unacceptable, especially since it hampers getting that fix out the door > > for everyone else. > > Then we have to adjust our security support policy. Define Tier-1 > archs for security support, release updates for them first. Then for > the others. I fail to see how this could be a problem. The problem for me is on machines (like my old sparc nameserver, providing service for 1500 users, being attacked multiple times a day) where receiving a security update days later[1] is no option. Having sparc in tier-1 without zero-day security updates would be no use to me, because I couldn't honestly say that "all tier-1 architectures are fit for production use and properly supported by Debian." I don't know what to do with tier-1.5 arch fulfilling everything except prompt security updates. Regards, David [1] Time to Exploitation after announcement is going down to hours. Attack rates are in the some-per-hour range. Prototype flashworm simulations reach 99% infection in seconds. And I don't see how it is getting any better. -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
