Bug#702376: ITP: wfrog -- Web-based customizable weather station softwar
Package: wnpp Severity: wishlist Owner: A Mennucc mennu...@debian.org * Package name: wfrog Version : 0.8.2 + svn Upstream Author : Jordi Puigsegur jordi.puigse...@gmail.com et al * URL : http://code.google.com/p/wfrog/downloads/list * License : GPL 3 Programming Lang: Python Description : Web-based customizable weather station softwar wfrog is a software for logging weather station data and statistics, viewing them graphically on the web and sending them to a remote FTP site. The layout and behaviour is fully customizable through an advanced configuration system. It is written in python with an extensible architecture allowing new station drivers to be written very easily. wfrog supports many weather stations and is compliant with the WESTEP protocol. Supported stations: * Ambient Weather WS1080 * Davis VantagePro, VantagePro2 * Elecsa AstroTouch 6975 * Fine Offset Electronics WH1080, WH1081, WH1090, WH1091, WH2080, WH2081 * Freetec PX1117 * LaCrosse 2300 series * Oregon Scientific WMR100N, WMR200, WMRS200, WMR928X * PCE FWS20 * Scientific Sales Pro Touch Screen Weather Station * Topcom National Geographic 265NE * Watson W8681 -- 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/20130305201915.GA694@kytty
new debdelta gpg key
dear all, sorry, I had completely forgotten that the debdelta signing key was to expire on 20th August; I have issued a new one; to import it, save it from attachment and issue, as root # gpg --home /etc/debdelta/gnupg/ --import 2012_signed.key I will upload a new 'debdelta' package containing the new key soon, hopefully it will make it in wheezy (but not in squeeze) a. ps: please support my effort to integrate the debdelta service in Debian at http://bugs.debian.org/548709 2012_signed.key Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
debdelta forensic
dear all, I just uploaded 'debdelta' version 0.45, that has a better implementation of error logs , and a provision for (automatically) sending them to the main server (where I will be able to look at them) . Brief explanation. A 'forensic file' is a file listing the content of a Debian package , with sha1 hashes for regular files; currently http://debdelta.debian.net/run/forensic/ contains the forensics for all debs that the debdelta server processes. When 'debdelta-upgrade' is invoked, a delta fails , and the '--forensic' option is on, then 'debdelta-upgrade' will store the output of the internal script, and also a forensic file representing the state of the installed package in your host , and (possibly) send it to me those logs. By looking at the log, and comparing the forensic file coming from you host with the forensic of the original deb, it should be possible to understand why the delta failed. If you usually use 'debdelta-upgrade', may you please install the new version 0.45 and use the new option --forensic? Example usages: ---1 # debdelta-upgrade --forensic=http if a delta fails, then the above will send the logs using http POST - fast and clean, no questions asked ; but it is totally anonymous, I cannot reach you back in any way. ---2 # debdelta-upgrade --forensic=mutt this instead invokes 'mutt' to send the logs by email: so you can see what you are sending me, and I can also answer you if I have further questions. Note it only works if the host is configured to send email (default Debian installs on laptops are not). ---3 # debdelta-upgrade --forensic=icedove as above but launching 'icedove' (as root!) ---4 If you instead do not wish to send anything to the server, but want to understand what may have gone wrong, then # debdelta-upgrade --forensic=do will generate the logs and simply list them; you can then check the logs yourself, and compare the 'forensic file' against the similar file that is found in http://debdelta.debian.net/run/forensic/ (e.g. by using 'diff -u' ) to see if any file is altered in your install a. ps: If a delta fails, then debdelta-upgrade will download the corresponding .deb (see the option '--deb-policy' in the man page for more details). So if you issue 'debdelta-upgrade --forensic=???' after the failure , nothing will happen. There are three ways out of this: 1) always use the '--forensic=???' option 2) always use the option '--deb-policy s,b' so that debdelta-upgrade will not download the deb in case of failure; if any fails, use 'debdelta-upgrade --forensic=???' 3) as a last resort, if you did not do the above, and you wish to send a bugreport, please manually delete the downloaded deb, e.g. # rm /var/cache/apt/archives/that-deb-that-failed_0.0-0_amd64.deb and run 'debdelta-upgrade --forensic=???' : it will retry and , upon failure, generate the log files that you may send me. signature.asc Description: OpenPGP digital signature
Re: OK, Re: need a server for debdelta repository
Il 03/05/2011 18:44, Stefano Zacchiroli ha scritto: Out of curiosity, and given http://debdelta.debian.net has been around for a long while now and is used (according to my exchanges with you) regularly, do you have a plan for integration into debian.*org* proper? I would like to. But so far no effective plans. In principle, it looks like a very useful service to users than they should be able to enable triggering a switch into APT. Is there any document describing that possibility, its drawbacks, showstoppers and, more generally, the way forward? I am writing documentation, it is at http://debdelta.debian.net/html/index.html (it is still work in progress); I just added a section 3.9 that may be of interest; I sent an email debian-dak@l.d.o . There will also be a session at https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-debdelta/ it is currently scheduled Tuesday, 12:00 CEST a. signature.asc Description: OpenPGP digital signature
new experimental debdelta feature --format=unzipped
Dear all, I just uploaded into experimental a new version 0.42exp of debdelta ( you may find some binaries also in [3] ). This version adds an experimental feature : if you call 'debdelta-upgrade' with the option '--format=unzipped' , then in the recreated deb the data.tar part will not be compressed. This may speed up the 'debdelta-upgrade' + 'apt-get upgrade' process. Indeed, writing to hard disk is fast (let's say 5MB/sec, but usually much more); whereas compressing random data with 'bzip2 -9' or 'lzma -9' is much slower (let's say 2.0MB/sec and 1.5 MB/sec) ; and moreover the compressed data is then decompressed by dpkg when installing; so avoiding the compress/decompress should be a win/win (unless you run out of disk space...). Please test it and tell me what you think. (Let me mention that old deltas in the server do not support this new feature, so you may get some warnings for some days). (I also want to thank Guillem Jover for proposing this idea, in a mail in debian-dpkg@l.d.o). (In the future, we may add an even more aggressive behavior, whereby the data is directly piped from debdelta thru dpkg to the hard disk ; this would be in the spirit of [2] ; I already adapted the deltas to support this, but it needs changes in APT and in dpkg , it may be done as part of [4] ). A. [1] http://debdelta.debian.net [2] http://wiki.debian.org/SummerOfCode2010/StreamingPackageInstall [3] http://debdelta.debian.net/squeeze-backports/ [4] http://wiki.debian.org/SummerOfCode2011/AptDebdeltaIntegration signature.asc Description: OpenPGP digital signature
need a server for debdelta repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi there, the debdelta service is experiencing some problems. There are two hosts involved: the first creates the deltas, and the second is a public http server 'bononia' that serves them (under a virtual host by the CNAME debdeltas.debian.net ). Unfortunately, there is some strange problem, so that bononia is not correctly mirroring the delta repository... whole directories are missing (!); I noted this some time ago, I contacted the people who had setup the mirroring, but there was no answer. What I am asking , as an emergency (and possible even temporary) solution, is a place where there are ~15GB of free disk space and an http server, so that I can transfer the repository of deltas there, and redirect 'debdeltas.debian.net' onto a virtual server at that place; and I would need an 'rsync' access so as to push new deltas (and delete old) when they are generated. TIA a. ps: I don't know exactly how much traffic deltas generate, I never had a change at looking at the bononia logs. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2/wb8ACgkQ9B/tjjP8QKQEsgCeIBxEtFaGhUaNbFMRf8GJnxyN 7OsAn1k9vngEnCtAswj1UmckWRrq/j2+ =pzt4 -END PGP SIGNATURE- -- 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/4dbfc1c1.8020...@debian.org
OK, Re: need a server for debdelta repository
The debdelta repository 'debdeltas.debian.net' has a new home! I thank a lot 'md' for hosting it in ftp.linux.it; and also 'ansgar' , 'formorer' for offering a host. With a new server, the service should also be better: deltas should be available no more than 1 hour later than the corresponding deb. (*) So you should almost never see the message delta is not present (but you may see the message delta is too big ). A. ps: (* this is not true yet for debian-security , I need to do a bit of work on that) signature.asc Description: OpenPGP digital signature
not yet, Re: debdelta back online
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 22/09/2010 22:46, A Mennucc ha scritto: due to my PC running out of disk space, no deltas were generated in the last week It seems that there was another problem: there is broken pdiff in amd64/experimental, so that debmirror was not updating my local repository now it should be working (but it will take some time to create all deltas) a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkybY6oACgkQ9B/tjjP8QKT58QCfafIdRgSitqH4l5cNOXpdTxEb Le0An3wFK0x7XDMmyhxZP8o5dtFAPNMw =iEGe -END PGP SIGNATURE- -- 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/4c9b63aa.10...@debian.org
Re: debdelta back online
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 23/09/2010 08:59, Javier Fernandez-Sanguino ha scritto: On 22 September 2010 22:46, A Mennucc mennu...@debian.org wrote: due to my PC running out of disk space, no deltas were generated in the last week (while I was absent); I found more space, so it will be back online as soon as it generates all needed deltas. Question: How much space does debdelta take? (per architecture?) currently I am creating deltas for amd64 and i386, and for lenny squeeze sid experimental ; there are ~14000 deltas , the total size of deltas is ~ 9Gbytes . I also create deltas for lenny-security, those are ~ 5GByte . To create deltas, I need a local mirror of the above suites, and that is quite big nowadays . You might need to provide figures if you want some big Debian server to host this service... the discussion about this is in http://bugs.debian.org/548709 ; it stalled for some time, but now Joerg is helping me a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkybZh8ACgkQ9B/tjjP8QKQqtwCfQ+zeXv9JCFj8TIfT/zQKToiX D0MAn2Dvnc8kDE4GFla8MMoNrgqUR3uE =FFGo -END PGP SIGNATURE- -- 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/4c9b661f.8060...@debian.org
debdelta back online
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dear all, due to my PC running out of disk space, no deltas were generated in the last week (while I was absent); I found more space, so it will be back online as soon as it generates all needed deltas. If you do not know what debdelta is , see http://debdelta.debian.net BTW, I hope that someday the generation of deltas will be done in some big Debian server , and not on my PC... it is not easy to keep a mirror of the repository (and indeed I only mirror debs, and hence only generate deltas, for 'i386' and 'amd64') a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaaz8ACgkQ9B/tjjP8QKTE8wCeNW/PPHzyKC7qolqWVcfdPVfY 2iMAn1X5lGAMoQe2WYUtxfmmvwA8Ss/c =ORZQ -END PGP SIGNATURE- -- 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/4c9a6b3f.30...@debian.org
ombrelli in Toscana
ciao, è stato annunciata la disponibilità di ombrelli con il logo di Debian, vedere in http://blog.fortytwo.ch/archives/84-The-Debian-Swirl-Umbrella-Order-it-Now!.html qualcuno è interessato? ci vogliamo coordinare per un acquisto congiunto (per facilitare la spedizione dalla Svizzera) fra DD toscani? a. NB: ogni spedizione è di 4 ombrelli o più -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-devel-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-devel-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100528124906.ga22...@tonelli.sns.it
Bug#538728: ITP: dvbstreamer -- DVBStreamer is an console based application to stream DVB/ATSC service(s)
Package: wnpp Severity: wishlist Owner: A Mennucc deb...@mennucci.sns.it * Package name: dvbstreamer Version : 2~svn Upstream Author : Adam Charrett charrea6 at users.sourceforge.net et al * URL : https://sourceforge.net/projects/dvbstreamer/ * License : GPL 2 Programming Lang: C, Python Description : DVBStreamer is an console based application to stream DVB/ATSC service(s) DVBStreamer is an console based application to stream DVB/ATSC service(s) over UDP or to a file. It is more that just an app to stream AV though and feature a simple plugin architecture to allow more features to be added. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: trasferimento di debian.it
Marco non sara' stato un Apollo Della Simpatia, ma da qui a scadere nel turpiloquio ce ne corre. a. signature.asc Description: Digital signature
xkcd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 we had to have this http://xkcd.com/424/ a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILybU9B/tjjP8QKQRAr5xAJ4gI/2k/LQqlsVKWXtCW0Nsli0RPgCfTSMH fCHEC7M6erNUsmN0d+zUADQ= =pIM0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
hi It is all explained in /usr/share/doc/sysv-rc/README.policy-rc.d It seems that all you need to do is to create inside your chroot a simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101' for example with these two simple commands $ echo -e '#!/bin/sh\nexit 101' /usr/sbin/policy-rc.d $ chmod +x /usr/sbin/policy-rc.d then invoke-rc.d becomes a no-op, it will not start or stop anything. Unfortunately the docs are a bit incomprehensible to me .. it seems you can do much complex stuff than that, but I cant help. You may want to look into the package policyrcd-script-zg2 : they know their act. a. Sebastian Dröge ha scritto: Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer: On 25/09/2007 Sebastian Dröge wrote: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. I tought that this should be handled by invoke-rc.d itself. The manpage states that: invoke-rc.d introduces the concept of a policy layer which is used to verify if an init script should be run or not, or if something else should be done instead. This layer has various uses, the most immediate ones being avoiding that package upgrades start daemons out-of-runlevel, and that a package starts or stops daemons while inside a chroot jail. So my assumption was that invoke-rc.d detects if it's invoked inside a chroot, and doesn't start the service in that case. AFAIK this only happens if specified in some config file that daemons shouldn't be started. Whatever, although hal is invoked by invoke-rc.d it is started in the buildd chroots. :/
Re: Request for set up of kudos.debian.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi you can use $ reportbug --kudos PACKAGE a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1GB09B/tjjP8QKQRAg+9AJ9WNuYwW2QDDuZ46l9rRgwrGIZVVgCfbU0j n3inmbPPVbDTwJjTKernKZc= =eCnZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Javier Fernández-Sanguino Peña ha scritto:
On Mon, Aug 27, 2007 at 12:04:51PM +0200, A Mennucc wrote:
I think I already pointed people interested in this to #268658.
If ftpmasters where given the tools to implement this seamlessly then you
could have aside tools that downloaded that file from the FTP site, and
locally checked the md5sums.
AFAICS in bug 268658 you propose to ship a signed 'Checksums-${ARCH}.gz'
with releases.
What I had in mind was slightly broader, though.
What I have in mind is a database containing all checksums of all binary
packages passing trough unstable, with records such as
package / arch / version / file / permissions / md5 / sha1
The 'Checksums-${ARCH}.gz' that you mention in 268658 may be generated
from this database at release time; but also the database would be
useful for people using tracking testing and unstable. The database may
have web interface, and/or a LDAP interface (with cryptographic
protection), so it may be searched. When doing forensic, it would be
useful to search it using the hash as a key.
Again, following your reasoning in 268658, I would then add a link to
the web interface in packages pages such as
http://packages.debian.org/testing/base/procps
But you are definitely right on one point: records should be added by a
script inside the incoming queue.
a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1I0R9B/tjjP8QKQRAr2BAJ4/dRWnUX8W6SRF+Uy9QqTd127uQACePtGH
1gprvSqm26Z7t5zepFpEkYI=
=1IVv
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debdelta, Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi just for the record : debdelta uses md5sums (when available) as a way to speed up delta creation, to rapidly detect if there are any identical files in the archives. So , yes, I (*) would be happy if md5sums where always available. BTW, I also encountered a strange bug : sometimes the md5sums file contains MD5 of files that are not shipped. This is printed as a warning in my server. If MD5 will become a release goal, this should be corrected as well : in case, I will send bug reports. a. * that is, my server that generates the patches for 'debdelta-upgrade' would be faster, and that would make me happier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0plu9B/tjjP8QKQRAm+iAKCLbo9dUeQtA3fR9FV9rIcLp8mCkgCfcWoj g1Rw/3sW8rPgaI3/laq/yn0= =jcX9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc 'HE' Brockschmidt ha scritto: Yes, that sounds like a good idea. It might also be interesting to not put those into the control.tar.gz, but directly into the deb, so that it can easily be extracted. I do not agree, for two reasons: 1) it is quite easy, by piping 'ar' and 'tar' , to extract files such md5sums from control.tar.gz 2) if md5sums is inside control.tar.gz, then it is compressed better, since the list of files is also inside control.tar.gz, and gzip is quite good at compressing repeated stuff a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0p4a9B/tjjP8QKQRAjv3AJ4jSAZei167CemUvLu1LZ8KDjAE/QCggHm4 nsnr8dj2Abjo9mvFFgdyElE= =K2wf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Wirzenius ha scritto: It strikes me that if we want to make it policy, having dpkg generate the checksums upon creating the .deb would be the simplest and best way to do it. This way we wouldn't have to change packages to do it, and if we ever want to change the format (sha1 as well as md5?) there's only one place to change it. this would guarantee that the list will really reflect what is inside the data.tar.gz as I said in another post, my debdelta-generating-server often complains that packages ship a md5sum that does not correspond to what is in data.tar.gz a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0p6a9B/tjjP8QKQRAhP4AJ9MfotrnlskSd+TsArbYQP0kyvffgCfe2nR GMHUwKKTHNONe8V1j3o9g9s= =RRx8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefano Zacchiroli ha scritto: In an attempt to prevent drift to a well-known counter argument: DEBIAN/md5sums (used by debsums) are *not* intended as a mean to counter security attacks, since they can be easily altered. If md5sums become part of the policy, then this brings me to an old idea of mine. Idea: we set up a database containing those md5sums , for all packages/versions that pass thru the archive, and add a web interface to that. This database then may be really used in forensic. Example usage. Suppose that I find out that my PC has been hacked. I then shut it down immediatly, and grab a live CD. I boot my PC using the live CD, and have it connect to Internet. I then start a simple utility (think of 'debsums --web --root'), that, for any package that is installed in the OS in the PC, downloads the md5sum for that version from the web interface, and goes checking; eventually leaving a list of all files that did not check OK or that were found in /etc /usr /bin ... and have no md5sum. Of course this would give many false positives, (such as the aspell hashes, as is discussed in a subthread ; and a lot of stuff in /etc); but it would be useful to prune the majority of OK files out, and leave a small subset for human forensic analysis. a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0qHD9B/tjjP8QKQRAmJnAJ9oUWwME6Q8g6JrRt6bF4nk6HYIawCdG1hP GRyBERL04/5Nz2/YmM16uts= =M3m4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Samuelson ha scritto: [Lars Wirzenius] It strikes me that if we want to make it policy, having dpkg generate the checksums upon creating the .deb would be the simplest and best way to do it. I'd opt for dpkg generating the checksums upon _extracting_ the .deb file. we already have debsums to do that also, in that case, it would damage my debdelta server :-( a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0qJt9B/tjjP8QKQRAmiBAJ9vC9AVUOZMJvyK1yHnG+X6IhcN6gCgn24X rbGdgmcvfWdshScmb7UtIg4= =44br -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed release goal: DEBIAN/md5sums for all packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow ha scritto: So why waste all the mirror space and bandwith for something rather useless? I did not do statistics; but, knowing how compression works, I would estimate that the cost of shipping md5sums is ~ 20 bytes for each file that is in data.tar.gz IMHO this is not wasting a lot of bandwidth... a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0qTl9B/tjjP8QKQRAnL2AJ9JLRPRmm/nmK3U66jzbedkyq6wywCZAfGS eUXy6V36rTWN60/hSFjh8cc= =Ihrc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debdelta service back on track
hi Mark Brown ha scritto: On Tue, Jul 17, 2007 at 11:23:53AM +0200, A Mennucc wrote: The problem was due to a subtle change in zlib1g: in newer versions, the compressed output has 0x02 instead of 0x00 at the 10th byte (that is in the header). This change occurred somewhere between version 1.2.3-13 and 1.2.3.3.dfsg-5 . Byte 10 is the XFL field which contains compression method specific flags. For deflate a value of two indicates that the compressor was aiming for maximum compression and a value of zero indicates nothing in particular. The code was previously not bothering to provide any information about how hard it was trying to compress things. thanks for the explanation (I was too lazy to go look into it myself :-) Since dpkg-deb uses zlib1g, this changed the .deb files. So a file reconstructed by debpatch would be different with the original in 2 bytes. Two bytes? a .deb file is an ar archive containing both a control.tar.gz and a data.tar.gz BTW: let me remind that one goal of debdelta is to obtain perfect reconstruction. The change in zlib1g did break perfect reconstruction; but the reconstructed .deb files were OK in all other respects. I have added a workaround for that problem in 'debdelta' version 0.21 , and I have installed it in the server that prepares deltas for 'debdelta-upgrade' . Now it should work again as expected. (If it does not, mail me, or send a bug in the BTS). I'm not sure exactly what debdelta is doing here but it sounds like it ought to have specific code for handing the reconstruction of this header in order to be robust against reasonable upstream changes. that is what I did. Currently a delta file also saves the header file and then puts it back forcibly. There are several fields in there which are informational and could be varied by the compressor pretty much at will. debdelta relies on the fact that dpkg-deb uses zlib1g to compress control.tar.gz and a data.tar.gz ; so debdelta calls minigzip, that obtains the same exact result - unless zlib1g changes, of course. debdelta currently is not robust w.r.t. strong changes in zlib1g ... the only way to achieve robustness would be that I should ship a copy of the source code of zlib1g inside the debdelta package (but that is inconvenient in other respects). a. signature.asc Description: OpenPGP digital signature
Bug#433774: ITP: xdelta3 -- Xdelta3 is a set of tools and APIs for reading and writing binary deltas
Package: wnpp Severity: wishlist Owner: A Mennucc [EMAIL PROTECTED] * Package name: xdelta3 Version : 30q Upstream Author : Josh MacDonald * URL : http://xdelta.org/ * License : GPL v2 Programming Lang: C, Python Description : programs and libraries to diff binary files Xdelta3 is a set of tools designed to compute changes between binary files. These changes (delta files) are similar to the output of the diff program, in that they may be used to store and transmit only the changes between files. The delta files that Xdelta3 manages are stored in RFC3284 (VCDIFF) format. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 signature.asc Description: Digital signature
debdelta service back on track
hi all, about two weeks ago 'debdelta-upgrade' started failing. Unfortunately I was away with (almost) no Internet access. Today I could finally fix the problem. The problem was due to a subtle change in zlib1g: in newer versions, the compressed output has 0x02 instead of 0x00 at the 10th byte (that is in the header). This change occurred somewhere between version 1.2.3-13 and 1.2.3.3.dfsg-5 . (I am sending a CC to the upstream authors and to the Debian Mantainer, in case they are not aware of this change). Since dpkg-deb uses zlib1g, this changed the .deb files. So a file reconstructed by debpatch would be different with the original in 2 bytes. I have added a workaround for that problem in 'debdelta' version 0.21 , and I have installed it in the server that prepares deltas for 'debdelta-upgrade' . Now it should work again as expected. (If it does not, mail me, or send a bug in the BTS). Note that endusers that only use 'debpatch' and 'debdelta-upgrade' do not need to upgrade: the workaround is in the delta-ing code. a. --- Info debdelta is a program suite designed to compute changes between Debian packages. It contains various utilities, including 'debdelta-upgrade' that can be used by people with slow access to Internet to speed up their apt-get upgrade. The debian package is http://packages.debian.org/unstable/devel/debdelta More info are available at http://tonelli.sns.it/pub/mennucc1/debdelta/README signature.asc Description: OpenPGP digital signature
Re: compiling packages
Oliver Block ha scritto: Hello list, I am not very familiar with the debian developer tools. How to recompile a package with debuggin option (gcc -g)? usually packages are compiled with -g, but are stripped afterwards; to avoid that, see example: as root # apt-get build-dep mplayer # apt-get install devscripts as user $ apt-get source mplayer $ cd mplayer-1.0~rc1 $ DEB_BUILD_OPTIONS=nostrip debuild binary when a package uses debhelper, the dh_strip command will respect your request; but not all packages so; so in some cases you may need to edit debian/rules to change the build rules a. signature.asc Description: OpenPGP digital signature
removing 'printtool' from archives
hi I am the mantainer of 'printtool' brief history: printtool was the GUI tool that Red Hat had developed for easy printer configurations ; it was then ~2000 adopted by the GNULpr project at http://lpr.sourceforge.net/ ; but, after the doc-com crisis, the project was eventually abandoned. Currently I mantain some code that came out of lpr.sf.net , and keep it alive: in particular, I use and appreciate 'gpr' , and I have developed the code (lately I added support for CUPS). But I think that 'printtool' has outlived its usefullness: its database of printers (that is actually contained in the package 'printfilters-ppd', for some strange reason) is outdated; and Debian ships many tools to configure printing (foomatic-gui , gnome-cups-manager , just to name two) , that work well and have up-to-date printer databases. If nobody is interested in 'printtool', I will ask for its removal from archive. a. signature.asc Description: OpenPGP digital signature
removing 'printtool' from archives
hi I am the mantainer of 'printtool' brief history: printtool was the GUI tool that Red Hat had developed for easy printer configurations ; it was then ~2000 adopted by the GNULpr project at http://lpr.sourceforge.net/ ; but, after the doc-com crisis, the project was eventually abandoned. Currently I mantain some code that came out of lpr.sf.net , and keep it alive: in particular, I use and appreciate 'gpr' , and I have developed the code (lately I added support for CUPS). But I think that 'printtool' has outlived its usefullness: its database of printers (that is actually contained in the package 'printfilters-ppd', for some strange reason) is outdated; and Debian ships many tools to configure printing (foomatic-gui , gnome-cups-manager , just to name two) , that work well and have up-to-date printer databases. If nobody is interested in 'printtool', I will ask for its removal from archive. a. signature.asc Description: OpenPGP digital signature
Re: checklib
Lucas Nussbaum ha scritto: On 24/05/07 at 21:22 +0200, Pierre Habouzit wrote: On Thu, May 24, 2007 at 08:26:00PM +0200, A Mennucc wrote: maybe the source code may be uploaded in the alioth project that would be good yes. Feel free to use the collab-qa alioth project for that, if you want. there is a 'checklib' project in alioth a. signature.asc Description: OpenPGP digital signature
checklib
hi what about http://rerun.lefant.net/checklib/ ? madcoder mentioned in http://lists.debian.org/debian-devel/2007/01/msg00822.html of the intention of getting the checklib service up again: any progress? also, where do I get the source code from (since the link http://greek0.net/div/checklib.tar.gz seems broken)? maybe the source code may be uploaded in the alioth project thanks a. signature.asc Description: OpenPGP digital signature
su repubblica bis
dopo pochi gg dalla breve comparsata in http://www.repubblica.it/2007/03/sezioni/scienza_e_tecnologia/creative-commons/creative-commons/creative-commons.html ecco una altra breve apparizione del nostro O.S. preferito http://www.repubblica.it/2007/03/sezioni/scienza_e_tecnologia/dell-linux/dell-linux/dell-linux.html che sia un segno ? :-) a. -- Per REVOCARE l'iscrizione alla lista, inviare un email a [EMAIL PROTECTED] con oggetto unsubscribe. Per problemi inviare un email in INGLESE a [EMAIL PROTECTED] To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
su repubblica
ciao a tutti un piccolo trivia tanto per rallegrare il primo dopopranzo: la parola Debian � comparsa su Repubblica in http://www.repubblica.it/2007/03/sezioni/scienza_e_tecnologia/creative-commons/creative-commons/creative-commons.html Argomento: seminario di De Martin a Pisa, sulla stesura di una Creative Commons compatibile con la legislazione italiana Cito l'articolo dove De Martin � citato dire: I ragazzi di Debian (una distribuzione di Linux) proponevano di lasciare all'autore la possibilit� di inserire i drm a patto di distribuire parallelamente una versione senza protezioni (sarei curioso di sapere chi in Debian a lavorato con De Martin per questo progetto - immagino sia uno di noi italiani) a. ps: purtroppo mi sono perso il seminario di De Martin ( ero nell'aula accanto a fare lezione!!! :- ) ho chiesto se mettono in rete la registrazione
Re: daylight saving time and RTC clock
hi thanks anyone yes, in the past I had to accomodate for dual booting into that peculiar other operating system (hereby called Windows, as by Santiago suggestion) : I developed gtkmorph in the past, and it had to run on both O.S.es ; but nowadays I dont, so I think I will switch my RTC to UTC, and be done with it. The reason why I did send the first post is that I thought there may be a way to do daylight switching even when RTC!=UTC ... but thinking about it more, I decided it is almost impossible: when dual booting, the RTC is affected by both O.S.es, so it all would depend on which one of the O.S.es is booted first on daylight-switching-day : the only way is, possibly , that Debian should peek into the innards of the Windows registry, to see if daylight-switching was already done, or not, on the RTC... this seems too complex to be feasible (I for once could not do it) a. signature.asc Description: OpenPGP digital signature
daylight saving time and RTC clock
hi everybody today is the first day of daylight saving time in Italy, (and many other European countries); but something did not work as expected in my Etch box --- brief summary of what I saw happening: this morning, when I booted my PC, I looked at the date # date dom mar 25 08:34:22 CEST 2007 that is, it was 1 hour behind ; so I issued # ntpdate-debian 25 Mar 09:34:32 ntpdate[3996]: step time server 193.204.114.105 offset 3599.702392 sec and this moved my clock 1 hour ahead, and then the date was correct: # date dom mar 25 09:34:35 CEST 2007 - my RTC clock is not set to UTC , and maybe this is the cause for what I saw happening above. Is there any way so that people not keeping their RTC to UTC may still have a correct time on daylight-saving switching days? What package may I send a bug report (wishlist) to? a. signature.asc Description: OpenPGP digital signature
Re: in cerca di un mentore
On Mon, Mar 12, 2007 at 07:28:01PM +0100, redcloud wrote: Domenico Andreoli wrote: ciao, On Mon, Mar 12, 2007 at 02:16:43PM +0100, redcloud wrote: Salve, sto realizzando una piccola applicazione in GTK+ e mi piacerebbe un giorno diventare il suo maintainer. Sono alla ricerca quindi di un mentore che mi guidi e che mi indichi i primi passi per diventare un DD. questo e' il posto giusto. potresti cominciare col descrivere la tua applicazione e magari ad aggiungere un link... :) P.s. ho visto che c'è molto spam nell varie lists, è un peccato! si', troppo... :/ ciao domenico Ciao, la mia applicazione è banale. Per descriverla in due parole... data in input una lista di file, calcola la combinazione di questi file che occupi al meglio un dato spazio http://kitenet.net/~joey/blog/entry/file_set_split_utility.html a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420
Re: xdelta, grave bug 147187, time left
On Thu, Jan 18, 2007 at 09:03:16PM -0700, LaMont Jones wrote: I hadn't seen the mail that added the patch to the bug report - I'll work on xdelta this weekend. that patch should fix interoperability between 64 and 32 bit I dont know if it addresses security implications... thanks thank you if interoperability would be achived , that would really help my debdelta project a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xdelta, grave bug 147187, time left
hi xdelta is affected by bug 147187 this is Steve Langasek analysis: the problem was that the xdelta file format includes information telling xdelta how much memory it needs to allocate in order to read in the patch structure -- and when allocating space for objects that include pointers, this is obviously going to differ between 32-bit and 64-bit architectures. this bug's severity was debated a lot; in the end , it was decide to downgrade it fast forward to today: since I would need to use xdelta across 32bit and 64bit archs (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=147187;msg=53) I found a patch that should solve the problem; this patch is used in RedHat version of the package. So the question to d-release team (and to the mantainer) is: should/could I NMU a new version with this patch applied? Also, how much time is left before Etch is released? I may actually spend some time testing this patch (I now have access to a amd64). a. signature.asc Description: OpenPGP digital signature
FuzzyOcr 3.5.1 for Debian
Hello all, I have packaged fuzzyocr 3.5.1 for Debian ; the name of the package is fuzzyocr3 ; I uploaded it into debian/experimental ; it is also available at http://tonelli.sns.it/pub/mennucc1/fuzzyocr a. ps: I previously uploaded fuzzyocr 2.3b-1 as fuzzyocr signature.asc Description: OpenPGP digital signature
kudos, Re: db.debian.org (and related infrastructure) updates
hi I keep statistics of my email before I activated greylisting and sender verification callouts, my average was ~200 spam/day (with peaks of ~400) ; after that, it is ~40 spam/day (and most do not pass thru debian.org, but are delivered directly at my account) so I want to kudo all people who made this possible a. signature.asc Description: OpenPGP digital signature
Re: db.debian.org (and related infrastructure) updates
hi [ thanks Ryan for the work] Ryan Murray ha scritto: The mail gateway, web scripts, and userdir-ldap command line interface have all been updated to deal with the new fields. I connected to the web interface at https://db.debian.org/update.cgi?id=mennucc1 I found fields for birthdate and Greylisting and Callout, but no fields for RBL and RHSBL and whitelisting a. signature.asc Description: OpenPGP digital signature
Re: please let mplayer into testing
[actually, my original mail had to go to d-release, but I miss-auto-completed the To:] Bill Allombert ha scritto: On Tue, Dec 12, 2006 at 11:09:09PM +0100, A Mennucc wrote: anyway, shortly after I wrote that email, the situation reverted again (for worse); so currently there is no agreement between me and Aurelien, and I put that matter to d-ctte, in bug 402772 the d-ctte, and all other people, settled for this final agreement - the bug 395252 should stay RC , but - the bug is though 'etch-ignore' If you need an example of massive code duplication between security-sensitive packages, I offer iceweasel and icedove: LANG=C diff -sr icedove-1.5.0.8.dfsg1/build-dir/mozilla/ iceweasel-2.0+dfsg/ | grep are identical|wc -l 21131 So there are at least 21131 fully duplicated files between this two packages. thanks for the tip I agree with you... moreover, iceweasel/firefox , icedove/thunderbird , etc etc , have been a frequent source of security problems indeed this kind of argument was already presented in the discussion of the bug 395252 , but it did not work it seems that MPlayer is kind of a lighting rod for criticism and strong feelings a. signature.asc Description: OpenPGP digital signature
Re: Dropping GStreamer 0.8 for etch
Josselin Mouette ha scritto: As the situation is very similar in mplayer, mplayer is considered RC-buggy by the security team. Josselin Mouette is talking about is bug 395252 Moritz Muehlenhoff (that is in security) asserted that he thinks that that bug 395252 should be RC But then I asked to Moritz, and he answered me so On Wed, Nov 01, 2006 at 12:24:24AM +0100, A Mennucc wrote: BTW: I have been assuming that Moritz is reporting the consensus of the whole security team , and not only his personal opinion... is it so? I'm speaking for myself. However, we already have unfixed issues in libavcodec in Sarge, which are very time-consuming to fix and apparently no one has started to work on in either, so I don't suppose anyone would be keen on it. CCing the rest of Security Team for comments. Cheers, Moritz (the above comes from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252;msg=139 ) Moritz did not update me, or bug 395252, on the consensus of the security team on this matter. (That is why I am CCing him). Today, I have asked d-ctte to deliberate on 395252: see bug 402772. Moreover, Josselin has filed 402793 re: gst-ffmpeg. So now the security team should express their opinion on those two bugs. a. signature.asc Description: OpenPGP digital signature
Re: please let mplayer into testing
Moritz Muehlenhoff ha scritto: A Mennucc wrote: Brief summary of bug: MPlayer contains an embedded copy of FFmpeg (indeed, they are developed by ~the same people); Aur=E9lien G=C9R=D4ME a= nd Moritz Muehlenhoff ask that the mplayer package be dynamically linked to the libraries in the Debian package ffmpeg; they consider this a RC bug.= Unfortunately, this cannot be currently done (mplayer does not compile with current ffmpeg package; and we are too late to update ffmpeg into Etch ; more details are in the above bug report). So we agreed to ignore that problem for the sake of the etch release Where did I agree until now? sorry, I got confused in the English, that last we was meant to mean me and Aurelien (and not including you) anyway, shortly after I wrote that email, the situation reverted again (for worse); so currently there is no agreement between me and Aurelien, and I put that matter to d-ctte, in bug 402772 Please hint MPlayer into Etch. I've tried it myself and it is indeed not possible to link against libavcodec dynamically currently. Given that mplayer was only accepted into the archive 2.5 months after the current ffmpeg snapshot was made and that mplayer is an important application I do now think we can ignore this RC bug for Etch as a one-time exception. In any case further mplayer maintenance needs to be synchronised with Debian's libav[codec| format], even if it means to not being able to upload the most recent upstream version every week. happy to know this. May you please forward this statement into bug 402772? (I would really appreciate). Also, the static linking against libdv introduced in 1.0~rc1-4 should be reverted. I did not mean to introduce any static linking; I will investigate a. signature.asc Description: OpenPGP digital signature
double GPG signature in Release files
hi I use amd64 here ; recently all tools (aptitude, debmirror) started complaining that archives are not properly signed ; here is a snippet of code to show the situation: $ cd /var/lib/apt/lists $ for i in *Release ; do echo === $i ; \ gpg --verify $i.gpg $i echo OK ; done === ftp.debian.org_debian_dists_unstable_Release gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 2D230C5F gpg: Good signature from Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 6070D3A1 gpg: Can't check signature: public key not found === ftp.it.debian.org_debian_dists_etch_Release gpg: Signature made Wed Nov 22 00:18:42 2006 CET using DSA key ID 2D230C5F gpg: Good signature from Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F gpg: Signature made Wed Nov 22 00:18:42 2006 CET using DSA key ID 6070D3A1 gpg: Can't check signature: public key not found === ftp.it.debian.org_debian_dists_unstable_Release gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 2D230C5F gpg: Good signature from Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 6070D3A1 gpg: Can't check signature: public key not found === security.debian.org_dists_etch_updates_Release gpg: Signature made Tue Nov 21 19:14:24 2006 CET using DSA key ID 2D230C5F gpg: Good signature from Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F OK as you see many archives seem to be signed with two keys: 1st is key 2D230C5F Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] 2nd is a key 6070D3A1 why this ? where do I find the latter key ? a. signature.asc Description: OpenPGP digital signature
Re: Debian Archive Automatic Signing Key (4.0/etch)?
Martin Zobel-Helas ha scritto: gpg --recv-keys A70DAF536070D3A1 (gpg --export -a A70DAF536070D3A1 | apt-key add -) $ gpg --recv-keys A70DAF536070D3A1 gpg: requesting key 6070D3A1 from hkp server keyring.debian.org gpgkeys: key A70DAF536070D3A1 not found on keyserver gpg: no valid OpenPGP data found. gpg: Total number processed: 0 signature.asc Description: OpenPGP digital signature
Re: double GPG signature in Release files
uh I see that there is a thread on that a. signature.asc Description: OpenPGP digital signature
Re: Debian Archive Automatic Signing Key (4.0/etch)?
Luca Capello ha scritto: Hello! On Wed, 22 Nov 2006 12:09:58 +0100, Hendrik Sattler wrote: Noone answered, yet, why this key is not in debian-archive-keyring package. It's there since the last update: = debian-archive-keyring (2006.11.22) unstable; urgency=low * Non-maintainer upload. * Add Etch release key * Bump priority to important (Closes: Bug#397698) * Update FSF address in copyright. -- Anthony Towns aj@azure.humbug.org.au Wed, 22 Nov 2006 01:30:50 +1000 = I thought that the whole idea was to make it available before it gets used. That would be the easiest (install it at installation time) and apt-key update could be used. that package is only 2 days old and did not transition to etch yet so it is too early to start signing etch archives with it and it empties the whole idea : to restore my trust path , I will have to manually download that package and install it a. signature.asc Description: OpenPGP digital signature
just wait more next time, Re: Debian Archive Automatic Signing Key (4.0/etch)?
actually, there is no need for tons of documentation: the usage of the package debian-archive-keyring should really automate the whole thing, as long as it is done correctly: 1) release team generates new key and new package debian-archive-keyring 2) users install it : in postinst, /usr/bin/apt-key update is run 3) after some time (10 days), release team starts using new key If done that way, it really works, and we have a trust path, since the new package debian-archive-keyring is certified by the old key. The problem is that , in this particular case, the new package debian-archive-keyring was released 22 Nov, and the new key was used almost immediately : so people using testing did not have time to import it. next time, they should just wait (at least 10 days - but maybe 30days would be better) a. Andreas Tille ha scritto: On Tue, 21 Nov 2006, Kurt Roeckx wrote: On Tue, Nov 21, 2006 at 04:50:29PM -0600, Peter Samuelson wrote: [Martin Zobel-Helas] gpg --recv-keys A70DAF536070D3A1 (gpg --export -a A70DAF536070D3A1 | apt-key add -) Uh, don't forget the part about verifying that the key is actually signed by the ftpmasters. Skipping that step pretty much defeats the entire point. gpg --list-sigs A70DAF536070D3A1 Try gpg --check-sigs A70DAF536070D3A1 instead. But Hendrik Sattler is perfectly right and this knowledge has to be stored at prominant places like: a) installation manual b) apt-key.8 c) perhaps somewhere else Could maintainers of a) and b) (and perhaps c) ;-)) acknowledge, that this will be done or should we rather file bug reports (IMHO with severity important) to these packages? Kind regards Andreas. PS: debian-boot@lists.debian.org in CC because of the installation manual issue. Forgive me if this should be off-topic there. signature.asc Description: OpenPGP digital signature
Re: Debian Archive Automatic Signing Key (4.0/etch)?
Julien Cristau ha scritto: On Wed, Nov 22, 2006 at 14:53:38 +0100, A Mennucc wrote: that package is only 2 days old and did not transition to etch yet so it is too early to start signing etch archives with it and it empties the whole idea : to restore my trust path , I will have to manually download that package and install it no, because the Release file is still signed with the 2006 key, which is in apt's keyring already. you are right on that : I can check that at least one key is verifying OK but gpgv returns an error for that; so debmirror does not run : look $ cd /var/lib/apt/lists $ for i in *unstable*Release ; do echo === $i ; \ gpg --verify $i.gpg $i echo OK ; done === ftp.debian.org_debian_dists_unstable_Release gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 2D230C5F gpg: Good signature from Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F gpg: Signature made Wed Nov 22 00:19:30 2006 CET using DSA key ID 6070D3A1 gpg: Can't check signature: public key not found as you see, no OK is printed. a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397615: ITP: fuzzyocr -- spamassassin plugin to check image attachments
Package: wnpp Severity: wishlist Owner: A Mennucc [EMAIL PROTECTED] * Package name: fuzzyocr Version : 2.3b Upstream Author : Christian Holler, decoder_at_own-hero_dot_net * URL : http://wiki.apache.org/spamassassin/FuzzyOcrPlugin * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : spamassassin plugin to check image attachments This Spamassassin plugin checks for specific keywords in image/gif, image/jpeg or image/png attachments, using gocr (an optical character recognition program). This plugin can be used to detect spam that puts all the real spam content in an attached image, while the mail itself is only random text and random html, without any URL's or identifiable information. Additionally to the normal OcrPlugin, it can do approximate matches on words, so errors in recognition or attempts to obfuscate the text inside the image will not cause the detection to fail. Another improvement was to move the wordlist into the configuration file so it can be easily extended. a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FAQ, Re: new mplayer
hi everybody I just now notice the debate on mplayer going on; so here are a few answers [many people] MPlayer dev team and Debian do not work together this is not the case. I have been working with Diego Biurrun (of the mplayer team) and Joerg Jaspert (of ftp-master team) many changes that Joerg asked have been applied directly by Diego into SVN this is why this package is a SVN snapshot Please tell me what's wrong with current package and what can we do to make it better and stop saying me it's license issue. in July, Joerg reviewed the mplayer package in NEW and listed many issues; most of them regards the licenses Since MPlayer incorporates code from many sources, it needs to properly document this fact ; this was done, by adding all necessary licenses and copyrights statements both in upstream code (thanks to Diego) and in debian/copyright file . Moreover now Mplayer documents the differences between its shipped version of libraries such as FFMPEG, and the upstream version ; this is again done to comply with GPL . [Andrew Donnellan ] Since when was MPlayer acceptable in the Debian archive? mplayer is in the NEW queue (sorry for the misunderstanding) [Yavor Doganov] I was wondering, what's so important about mplayer? it works quite well for me ; e.g. , I have a digital camera that can record movies (MPEG4 in MOV) , last time I tried (~1 month ago) totem and xine reproduced my movies with skippy audio ; moreover , when I tried ~1 year ago, mplayer was capable of playing DVDs on my Pentium 450, while some other players were skipping frames . Of course, other people may prefer other players... that is fine for me; one nice point of Debian is that it offers all choices, Gnome vs KDE, Emacs vs Vi vs ... , OpenOffice vs AbiWord ; so it is just a big shame that mplayer is still missing [fEnIo] Mplayer comes with his friend mencoder. Not in Debian, and it probably never will. At the request of Joerg from ftp-master team, I even deleted mencoder.c from the tarball, to make it clear that we do not want to incur in any patent problem. Yes, I know there won't be w32codecs package in Debian, but even mplayer would be great addition. there is a script for downloading those a. ps: feel free to ask more questions; if you want a quick answer, CC me, I do not read d-devel usually -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new mplayer
hi everybody I prepared a new mplayer (with help from Diego Biurrun of the mplayer team) it has version 1.0~rc1~svn19921 (note that I have decided to use the new ~ element, so this version appears to be older than 1.0rc1 or 1.0pre8 ; you may need to manually use dpkg to install it) it was uploaded into Debian incoming, and it is available from http://tonelli.sns.it/pub/mplayer/etch/ a. -- Andrea Mennucc E' un mondo difficile. Che vita intensa! (Tonino Carotone) signature.asc Description: Digital signature
Re: debdelta
Nikita V. Youshchenko wrote: The command 'debdelta-upgrade' is meant to be run between 'apt-get update' and 'apt-get upgrade'; it downloads .debdelta files and recreate the new .deb files from them; always using the *installed* old version of the .deb, and not the old .deb file itself. Is it safe - e.g. in case of localy-modified config files? yes a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposal for a more efficient download process
to a_3.deb This would work if done by hand, just doing $ debpatch a_1_2.debdelta / /tmp/a_2.deb $ debpatch a_2_4.debdelta /tmp/a_2.deb /tmp/a_3.deb but 'debdelta-upgrade' now is uncapable to exploit this situation; so I keep only one delta for each deb How do you integrate this approach with the minimal security Release files give us today? recreated debs are identical to original in archive. Currently the best way to use my package is: $ apt-get update $ su nobody -c debdelta-upgrade $ mv /tmp/archives/*deb /var/cache/apt/archives $ apt-get upgrade (By default , debdelta-upgrade puts the resulting .deb in /tmp/archives; use --dir to your taste, though ) As you see , I propose to run debdelta-upgrade not as root, since it is still in development. What about the kind of signatures dpkg-sig provides? Those are supported. 'debdelta' reproduces everything it sees into the .deb file, considering it as an 'ar' archive (altough it is not exactly a 'ar' archive, since 'ar' adds a '/' in the header , 'dpkg' does not ); it just treats control.tar.gz and data.tar.gz in a smarter way. - other FAQ I made up for you Q: What about .debs where the data part is compressed with bzip ? A: currently, is unsupported (I never found one :-) but I did write some code to support it. Q: can 'debpatch' recreate the new .deb using the installed old .deb, even when - there are dpkg-diversions ? - conf files where modified ? A: yes, yes. Q: can 'debpatch' recreate the new .deb using the installed old .deb, when 'prelink' is used in the host? A: currently, no. a. -- Andrea Mennucc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debdelta
Dear Debian people, I have completed a reasonably working version of 'debdelta', a package suite to compute differences between Debian packages. For sake of clarity, let's call '.debdelta' a file that encodes the differences between Debian packages, and '.deb' a Debian package. The command 'debdelta' creates a .debdelta ; the command 'debpatch' applies it to the old .deb to recreate the new .deb ; or, it can use the *installed* files of the old .deb. The command 'debdelta-upgrade' is meant to be run between 'apt-get update' and 'apt-get upgrade'; it downloads .debdelta files and recreate the new .deb files from them; always using the *installed* old version of the .deb, and not the old .deb file itself. Downloading .debdeltas instead of .deb packages can be a huge benefit for people with slow Internet access, and/or to keep traffic on servers low (as when the X security upgrade did saturate the server security.debian.org , see http://www.debian.org/News/2005/20050920 ) More info and details are in http://tonelli.sns.it/pub/mennucc1/debdelta/README The 'debdelta' package is in http://tonelli.sns.it/pub/mennucc1/debdelta/etch or http://tonelli.sns.it/pub/mennucc1/debdelta/sarge Unfortunately my repository of .debdelta is currently stored in a slow-bandwidth server; I would need some space (~800Mb) in some Debian server to host it (in a server where there is a copy of the archive). Any suggestions? The best would be if ftp-masters may help me set it up in ftp.debian.org . a. -- Andrea Mennucc signature.asc Description: Digital signature
Re: exp. lightspeed disappeared
Steinar H. Gunderson wrote: Perhaps it fixed itself? :-) yes it did. The reason I posted is that, when I posted, the page http://packages.debian.org/lightspeed was showing the kfreebsd binary but not the i386 binary that I had uploaded...I was very puzzled! thanks for checking a. ps: it seems anyway that there are some weird issue with archives: see http://permalink.gmane.org/gmane.linux.debian.devel.general/100417 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
exp. lightspeed disappeared
hi I uploaded an experimental version of 'lightspeed', as you see in http://packages.qa.debian.org/l/lightspeed/news/20060507T214839Z.html on Sun 7th of May ; but strangely enough it does not appear, neither in http://packages.qa.debian.org/l/lightspeed.html nor in http://packages.debian.org/cgi-bin/search_packages.pl?searchon=namesversion=allexact=1keywords=lightspeed Actually, in this latter there is the version for kfreebsd-i386 , but not the version for i386, that I uploaded. Why? (also, who should I write to? if there is a more apt list to post this message, please tell me) a. ps: note that the above is a NMU... I am helping fixing a bug; I uploaded the new version in experimental to make it available to the bug reporter and so that I would see if autobuilders do compile it -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef signature.asc Description: Digital signature
Re: effectiveness of rsync and apt
hi I had the same idea some time ago if you ever decide to work on that, I may help Goswin von Brederlow wrote: I actualy have a little hack how one could implement patch debs now to test this out: 1. Create an archive mirror with rsync batch files (or xdelta or whatever) between the last and current version of each package. It might be simplest to replace the data.tar.gz in each deb with the rsync batch file and leave the rest of the deb as is. 2. Create Packages.gz and friends for those patch debs 3. Create an apt method http-patch to apt that will first check for the old version of the package or dpkg-repack it, then forks the http method to download the patch deb, applies the patch and returns the build deb. 4. Add deb http-patch://server/path suite dist to sources.list _before_ the normal http url. One drawback of this hack would be that you get an error from the http-patch method when you don't have the previous version available before apt-get falls back to the http url. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fonts prbl in sid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Meskes wrote:
On Mon, Apr 24, 2006 at 11:38:43AM +0300, Daniel Stone wrote:
almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
('xmms' is missing fonts for the menus but not for the main display);
Not sure if this is related but for display see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363371
Michael
yes it was the same bug
it was solved by forcing dpkg-reconfigure to properly recreate
/etc/X11/xorg.conf ; then , after reboot , it all worked fine (for some
reason, server restart was not enough...)
a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEVzcx9B/tjjP8QKQRAul7AKCN64Qd7dCkMq0A/LapNK+zndaMXgCdGjaS
5SDTcri3TQ3Jz74ZgstUNqo=
=uaiD
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fonts prbl in sid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Vega wrote: On Mon, Apr 24, 2006 at 11:22:42AM +0200, A Mennucc wrote: hi I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did not have time to) ; now I have serious problems with fonts. Have you reconfigured xserver-xorg? As part of the modular Xorg update, the directories the fonts reside in have moved. Your xorg.conf may still be pointing to the old directories. Refer to http://wiki.debian.org/Xorg69To7 for other side-effects you may experience from the upgrade. thank you, it was not very easy to tell to have dpkg-reconfigure to properly recreate /etc/X11/xorg.conf ; then I managed to put the correct MD4 in the correct directory; then, after reboot , it all worked fine (for some reason, server restart was not enough...) a. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEVzdl9B/tjjP8QKQRAmdVAJ9gyCVSM4LsV5pHRl8uoWIn3oGi7QCghWBc xa5qEN8+/cVvy2Qy9HEHb+s= =kt69 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: effectiveness of rsync and apt
hi I did a similar thing some time ago; I used 'xdelta' on two versions of kernel and of tetex; the results were impressive; I could prepare a 'debdiff' that was 10% (AFAICR) of the size, and that would recreate an exact copy of the new version of the package, given the previous version of the package. Currently my notebook is broken (power transformer fried with a white flash); when it is alive again, I will post more details. a. Brian Eaton wrote: Hello all - Regarding the ideas discussed here: http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html Has anyone ever done some log file analysis to figure out how much bandwidth would be saved by transferring package deltas instead of entire new packages? Assuming someone hasn't done the work already, I'd be interested in looking at some logs to figure it out. Regards, Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
fonts prbl in sid
hi
I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did
not have time to) ; now I have serious problems with fonts.
Symptoms: some programs fail to find and use the fonts ,and are then
almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
('xmms' is missing fonts for the menus but not for the main display);
'gpr' 'gnomecal' .
Note that, in my desktop, I set:
$ env | grep LANG
LANG=it_IT.UTF-8
GDM_LANG=it_IT.UTF-8
note also that other programs are fine, for example, all GTK2 applications.
I encounter some peculiar behaviour, here is a listing
$ gnomecal
(never starts)
$ LANG='' gnomecal
(prints this forever)
The font
-adobe-helvetica-bold-r-normal--12-*-*-*-p-*-*-*,-cronyx-helvetica-medium-r-normal-*-14-*-*-*-p-*-koi8-r,-*-*-bold-r-normal--12-*-*-*-*-*-ksc5601.1987-0,*
does not support all the required character sets for the current locale
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
(Missing character set ISO8859-1)
(Missing character set ISO8859-1)
$ gpr
(starts, no text anywhere)
$ LANG='' gpr
(starts , text is blocky but fine)
$ display
display: unable to load font
`-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1'.
display: unable to load font
`-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1'.
(fails to start)
$ xlsfonts -fn -*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
$ LANG='' display -font
-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1
display: unable to load font
`-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1'.
display: unable to load font
`-adobe-helvetica-medium-r-normal--12-87-100-100-p-0-iso8859-1'.
(fails to start as well!)
$ xcalc -font -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
Warning: Cannot convert string
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 to type
FontStruct
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable fontset
(starts, fonts look funny)
Does anyone have an helping clue ?
a.
--
Andrea Mennucc
E' un mondo difficile. Che vita intensa! (Tonino Carotone)
signature.asc
Description: Digital signature
etch before vista
hi everybody According to the latest [1] Microsoft announcement, Vista will be released in Jan 2007; according to our schedule [2], Etch may be released in Dec 2006. If we accomplish it, it will be a great feat: Debian will (possibly) show it is able to relase two versions of its distribution since Jul 2002 (= woody release); whereas Microsoft seems unable to release its own O.S. (even though XP has been out since Dec 2001, if I recall correctly). Yes guys, it means we (Debian + Open/Free SW community) manage to release ~ 9GB of binary precompiled integrated software , times ~ 10 binary architectures , (maybe) twice , and for free ... while in roughly the same time frame Microsoft is unable to release Vista, and Office [3] as well; that is AFAIK less than 1GB of binary code. Amazing. Is somebody out there doubting that Free/Open Software will eventually lead? I hope we do manage to release in Dec 2005 (and I thank people who work hard to this end). a. [1] http://arstechnica.com/news.ars/post/20060321-6433.html [2] http://lists.debian.org/debian-devel-announce/2005/12/msg00013.html http://lists.debian.org/debian-devel-announce/2005/10/msg4.html [3] http://www.eweek.com/category2/0,1874,1840947,00.asp signature.asc Description: Digital signature
Re: etch before vista
On Fri, Mar 24, 2006 at 08:07:48PM +0100, Joerg Jaspert wrote: On 10603 March 1977, A. Mennucc wrote: I hope we do manage to release in Dec 2005 (and I thank people who work hard to this end). We wont, im sure. :- gotme but in the beginning of the email I got it right :-) excuse yesterday I went thru 4 airports, ~5000miles , 7 hours jetlag, 20 hours of travelling overall ; so a misstype is somewhat to be expected. (yesterday is quoted, since, for me , intercontinental flying feels more like two days than one) /excuse btw : I am in University of Minneapolis now, mail me for keysigning / beer / Debian related events a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new mplayer 1.0pre7try2 package
hi everybody a new version of mplayer 1.0pre7try2 is available ; add either for the etch version, the line deb http://tonelli.sns.it/pub/mplayer/etch ./ or for the sarge version, the line deb http://tonelli.sns.it/pub/mplayer/sarge ./ to /etc/apt/source.list . a. signature.asc Description: Digital signature
policy on stati/dynamically linked binaries
hi does the Debian Policy mandate that binaries should be dynamically linked and not statically linked to their needed libraries ? I thought so but I could not find it; in particular, I looked in section 10.1 Binaries, where it goes at length in talking of the debugging and stripping options, but it never explicitly says that binaries should be dynamically linked. I noted this curious fact while posting bug 345506. a. -- Andrea Mennucc E' un mondo difficile. Che vita intensa! (Tonino Carotone) signature.asc Description: Digital signature
Re: etch release plan (was Re: congratulations to our ftp-master team)
sorry, I was remembering incorrectly the dates (and by no means meaning that I want the release to be 3 months later than what Steve announced) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Javier Fernández-Sanguino Peña wrote: On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: I *guess* mplayer could do likewise. MPlayer was once very picky regarding the versions of ffmpeg that it does compile with. Moreover MPlayer want to link all core libraries together (for performance reasons). So I think not. Notice, in any case, that the xvidcap packages in NEW *don't* use ffmpeg, the source code is there: $ ldd /usr/bin/xvidcap . 'ldd' does not mean anything: most versions of xvidcap ship a copy of ffmpeg in their own sources: $ wget http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3-p7.tar.gz $ tar xzf xvidcap-1.1.3-p7.tar.gz $ du -s xvidcap-1.1.3-p7/ffmpeg/ 6420xvidcap-1.1.3-p7/ffmpeg/ $ wget http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3.tar.gz $ tar xzf xvidcap-1.1.3.tar.gz $ du -s xvidcap-1.1.3/ffmpeg/ 6340xvidcap-1.1.3/ffmpeg/ a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I did ask, Re: congratulations to our ftp-master team
Dear Jeroen and everybody, here attached is an email I sent in September. Yes, I did ask to ftp-masters clarifications about your proposal in http://lists.debian.org/debian-devel/2005/04/msg00997.html and never received a reply. Jeroen van Wolffelaar wrote: While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... yes, your memory failed :-) (you are in the CC of the attached email) I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. (sorry my english fails me here) To the best of my knowledge, mpeg encoding stuff is nowhere near the core funcionality of mplayer anyway, isn't it? yes AFAIK mencoder cannot encode MPEG2 in this version (that is in NEW queue) Of course, if this way is choosen and is turning out to work out, later inclusion of the mpeg encoding stuff in mplayer must be discussed with ftp-master prior to it happening -- we (as in, Debian users in general) just get to have a chance of a slightly crippled mplayer in the archive in the meanwhile. I agree As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member Of course. This is what I have been waiting for. For 880 days, roughly. a. From debdev Mon Sep 26 11:33:39 2005 Date: Mon, 26 Sep 2005 11:33:39 +0200 To: [EMAIL PROTECTED] Cc: Diego Biurrun [EMAIL PROTECTED], MJ Ray [EMAIL PROTECTED], Dariush Pietrzak [EMAIL PROTECTED], Joerg Jaspert [EMAIL PROTECTED], Jeroen van Wolffelaar [EMAIL PROTECTED] Subject: questions on mplayer Message-ID: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=nFreZHaLTZJo0R7j Content-Disposition: inline User-Agent: Mutt/1.5.9i Status: RO Content-Length: 2300 Lines: 64 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear ftp-masters,=20 (and in particular Jeroen van Wolffelaar and Joerg Jaspert, who have discussed the problem before), in April 2005, during a thread discussing inclusion of mplayer in Debian, at http://lists.debian.org/debian-devel/2005/04/msg00997.html J. van Wolffelaar expressed the opinion that nowadays the only issue still blocking acceptance of mplayer in Debian may be=20 the (*) presence of MPEG encoding software.=20 [(*) as a matter of fact, up to some time ago AFAIK mplayer was unable to encode MPEG stream; but I heard that they are working on it] J. van Wolffelaar also said though that We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. I would be very grateful if the ftp-masters team may finally decide what are the requirements so that mplayer be accepted into Debian; in doing so, they may want to read http://people.debian.org/~mjr/legal/mplayer.html where M J Ray summarizes and links many info. To fix ideas, I would need official (at least privately to us) answers to these questions: 1) can mplayer be included into Debian, possibly with some fixes, including removal of source from the mplayer...orig.tar.gz ? 2) (if yes) do we need to remove MPEG decoding stuff? 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) The above questions are somewhat urgent, since the current version of mplayer in NEW has a security bug, so I would love to prepare a new version, and I would love to prepare it to comply to any request by the ftp-masters, so that I may upload it into NEW for their review. a. --=20 Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDN8Bz9B/tjjP8QKQRAmxfAJ9IJ686tgGjSRBIbqBqQaACm7OROwCdH94G ulHqI6eqYyiOis8K8mrKz/8= =6Wc/ -END PGP SIGNATURE- --nFreZHaLTZJo0R7j-- signature.asc Description: OpenPGP digital signature
Re: congratulations to our ftp-master team
actually, there was a response in Aug 2004, as in attachment A Mennucc wrote: The oldest upload of 'mplayer' that I still find in my harddisk was 'Wed Jul 23 10:44:54 2003' (see attachment) So 'mplayer' has been waiting in NEW queue for some response from ftp-masters for 876 days (at least) From [EMAIL PROTECTED] Mon Aug 16 00:54:00 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from sns.it (mail.sns.it [192.167.206.31]) by tonelli (Postfix) with ESMTP id 68F2517601 for debian; Mon, 16 Aug 2004 00:54:00 +0200 (CEST) Received: from newraff.debian.org ([208.185.25.31] verified) by sns.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 20014347 for [EMAIL PROTECTED]; Mon, 16 Aug 2004 01:01:46 +0200 Received: from troup by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1BwTic-00016O-00; Sun, 15 Aug 2004 18:43:14 -0400 From: James Troup [EMAIL PROTECTED] To: A Mennucc1 [EMAIL PROTECTED], Dariush Pietrzak [EMAIL PROTECTED] X-Katie: lisa $Revision: 1.30 $ Cc: Debian Installer [EMAIL PROTECTED] Precedence: bulk Subject: mplayer_1.0.cvs20030324-1_i386.changes REJECTED Message-Id: [EMAIL PROTECTED] Sender: James Troup [EMAIL PROTECTED] Date: Sun, 15 Aug 2004 18:43:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on tonelli.sns.it X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4.5 tests=AWL,BAYES_00 autolearn=ham version=2.63 Status: RO X-Status: A Content-Length: 299 Lines: 16 Hi, Sorry for the delay in processing this package. Please upload a version with a sane copyright file - the one currently in the package still just says GPL. -- James === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email.
Re: congratulations to our ftp-master team
Anand Kumria wrote: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. don't be fooled by the web page. The oldest upload of 'mplayer' that I still find in my harddisk was 'Wed Jul 23 10:44:54 2003' (see attachment) So 'mplayer' has been waiting in NEW queue for some response from ftp-masters for 876 days (at least) a. u mplayer_0.90-1_i386.deb ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90-1.diff.gz ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90.orig.tar.gz ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90-1.dsc ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90-1_i386.changes ftp-master.debian.org Wed Jul 23 10:44:54 2003 s mplayer_0.90-1_i386.changes ftp-master.debian.org Wed Jul 23 10:44:54 2003
Re: congratulations to our ftp-master team
Jeroen van Wolffelaar wrote: On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: That would have been me: http://lists.debian.org/debian-devel/2005/04/msg00997.html at that time, you wrote/ / /So, adding these two tentative conclusions together, it seems likely that if mplayer were demonstrated with reasonable certainty to be free of MPEG-encoding code, it would be acceptable for inclusion in main as far as the FTP-masters are concerned (note: We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. Don't take my words on too much value though, maybe stripping this won't be required after all, but in any case, if it isn't there, we don't need to think/discuss about it -- reinclusion of the encoding stuff can then later separately be discussed)./ I have indeed been waiting to know if /it's *required* to strip MPEG /ftp-master not responding, still waiting.. ftp-master not responding, still waitingftp-master not responding, still waiting.ftp-master not responding, still waiting.ftp-master not responding, still waitingftp-master not responding, still waiting a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
hi I think that both sides are right: 1) people who express kudos to FTP-masters for express accepting new packages due to the C++ name transitions 2) Anand Kumria and Thaddeus Black criticizing FTP-masters for never addressing 'mplayer' 'xvidcap' 'rte' and such I can understand why nobody in the ftp team addresses 'mplayer' 'xvidcap' 'rte' : suppose you are a ftp-master and have 15minutes spare: you check into the NEW queue, spot some transitional packages, run a quick script to check that they were renamed accordingly, and give green light. To address 'mplayer', it would take more than 15 minutes; and it would mean reading a lot of code and debian-legal discussion, and taking sides and expressing an important opinion. hey that is a lot of work so 'mplayer' is always delayed. So , ftp-master team is not doing a _fantastic_ job, (as Jay thinks), they are doing the _most convenient_ job. The _fantastic_ job was the job of people who discussed mplayer on d-devel and d-legal, and reached an agreement that 'mplayer' may enter into Debian, (maybe w/o MPEG2 encoding [1]). That work is currently completely disregarded by the ftp team. Running a script to check that /libblah1c2/ has been properly renamed to /libblah1c2a/ is not that _fantastic_. Solving an outstanding problem is _fantastic._ The paradox is that, if you sum up 15minutes for each package in the NEW queue, you easily total many many hours of work more than enough to address 'mplayer' 'xvidcap' 'rte'. In my opinion, considering that the release of etch is 15 months away, there is no need today to concentrate only on accepting transitional new package; it would be instead nice to use these 15months to solve the mplayer stalemate (that has been waiting more than 876 days). indeed, when [1] was written, sarge's release was near, and 'mplayer' was not top priority; now the situation is quite different; there is need to consider 'mplayer' low priority forever; if the ftp team does care a little bit, then this is a good timeframe. BTW: I know that 'mplayer' has always been fishy business in Debian but what did 'xvidcap' ever do wrong? AFAICT the only problem may be that 'xvidcap' contains FFMPEG code ; but FFMPEG has been in Debian for quite long now, so I do not really understand what is going on here. a. [1] http://lists.debian.org/debian-devel/2005/04/msg00997.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge uninstallable !?!
ops turns out that in both cases they where using a pre-release, namely, .disk/info contains Debian GNU/Linux testing Sarge - Official Snapshot i386 Binary-1 (20041121) :- turn off red alarm a. On Fri, Dec 02, 2005 at 04:09:49PM +0100, debdev wrote: hi everybody two friends of mine tried (separately) to install sarge using the netinst cdrom, and failed a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge uninstallable !?!
On Sun, Dec 04, 2005 at 12:11:13PM +0100, Olaf van der Spek wrote: On 12/4/05, A Mennucc [EMAIL PROTECTED] wrote: Apparently that wasn't obvious. Shouldn't it be made more clear what version is being used? yes, I was thinking the same... maybe it would be useful if the installer snapshots would at a certain point flash a huge warning such as hey! you are using a prerelease snapshot! things may mulfunction! maybe you should get an official release instead... a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sarge uninstallable !?!
hi everybody two friends of mine tried (separately) to install sarge using the netinst cdrom, and failed in both cases, the first part of the install was OK, but, after reboot, when APT was called to upgrade the system, it stopped claiming: E: This installation run will require temporarily removing the essential package e2fsprogs due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option. this seems the same problem as in bugs 330719 and 325834 but this is incomprehensible to me! the above bugs should never affect people doing a new install of sarge on a formatted disk! These 2 friends phoned me (one yesterday, one today) asking for help; here is what I can report to you (informations are scarce, getting technical details on the phone is not easy): 1st friend used an italian mirror (one of the 'garr' , I dont know if it was 'cdn.mirror.garr.it' ); after APT stopped, he was left with an unworkable system, that would not even reboot properly; wed. he phoned me, and tried again while I was consueling thru the phone; we used 'ftp.it.debian.org' as mirror, and installation was flawless 2nd friend used 'debian.fastweb.it' ; he googled around, found many pages reporting this kind of problem, so he reissued APT with 'apt-get -o APT::Force-LoopBreak=yes' and managed to complete the install. I can imagine only two possible explanations: - broken mirrors where stable points to etch (but I checked this, and the above mirrors seem OK) - some new package that comes from deb http://security.debian.org stable/updates main is triggering the above prbl with e2fsprogs a. -- Andrea Mennucc E' un mondo difficile. Che vita intensa! (Tonino Carotone) apt.tgz Description: GNU Unix tar archive signature.asc Description: Digital signature
Re: sarge uninstallable !?!
That day, Florian Weimer wrote I've seen this as well, but attributed it to an old sarge installer which used testing instead of sarge (or stable) in the installed sources.list file. In this case, an update from a pre-sarge testing snapshot (is installed by the base system) to a current etch version is attempted. Such cross-release updates are not supported. the friend sent me a tgz of the whole /etc/apt directory, and I attached to the first email (but I forgot to talk about it). In /etc/apt/sources.list there are deb http://debian.fastweb.it/debian/ stable main deb-src http://debian.fastweb.it/debian/ stable main deb http://security.debian.org/ stable/updates main and there is not mention of testing. This is why I am very amazed. By the way, your Mail-Followup-To: header is broken. thanks;some time ago I decided to abide by http://larve.net/people/hugo/2000/07/ml-mutt but I forgot to fix this account a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Segmentation fault on xmms startup (NVIDIA graphic driver involved)
hi try this: deinstall all xmms plugins that use GL graphics; indeed the crash is in the add_plugin () call Paolo Pantaleo wrote: Well i discovered that it is not an xmms issue, but some problems with NVIDIA non free graphic drivers, probalby it is a configuration problem (specific of my own installation). btw: NVIDIA drivers works very well on my system: I can play all GL games that are in Debian, and DVDs, on a 450MHz Pentium system (and never experience crashes) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
zope2.7 security fix (for bug 334055)
hi everybody I have (hopefully) fixed the bug 334055 of zope2.7, that is a security alert. Note that my patch is much smaller than the original hotfix, which included also some new features such as nl and ca languages - - but usually we do not add new features in Debian when releasing security upgrades. - testing This is the updated binary for testing/etch http://tonelli.sns.it/pub/mennucc1/zope/debian/etch-security/zope2.7_2.7.5-3sec1.deb I will not upload it to secure-testing-master since it violates point 1 at http://secure-testing-master.debian.net/ Only upload changes that have already been made in unstable. People in the pkg-zope-team are introducing in unstable a completely different zope framework. - sarge This is the proposed update for stable/sarge : http://tonelli.sns.it/pub/mennucc1/zope/debian/sarge-security/zope2.7_2.7.5-2sec1_source.changes unfortunately I do not have available a clean sarge environment, so you have to compile it. This is the diff w.r.t the older version http://tonelli.sns.it/pub/mennucc1/zope/debian/sarge-security/zope-hotfix_2005-10-09-sarge.diff Warning: do not apply that patch to the installed files of zope2.7, it will not work. Compile the above source, or help me use a sarge buildd. a. ps: I wrote to the security team asking info on the sarge upload, never got an answer. Question: can I upload a source-only to sarge-security? ps2: I would also appreciate if someone who understands what 334055 is about would compile and test my fix to see if it really works. -- Andrea Mennucc E' un mondo difficile. Che vita intensa! (Tonino Carotone) signature.asc Description: Digital signature
Re: snmpkit stuck in unstable ?
On Thu, Sep 08, 2005 at 09:12:15AM -0400, Nathanael Nerode wrote: Looks like its entire chain is ready, so now you need a hint. Ask debian-release to do this: the page on excuses was speaking of an hint... what is it ? choice 1) a plain english email to [EMAIL PROTECTED] choice 2) a procedure involving gpg signing and email to an obscure address using a set of keywords nobody ever documented properly 1 was my hope, 2 was my Debian-experience-induced-fear a. -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef signature.asc Description: Digital signature
snmpkit stuck in unstable ?
hi people (maybe I do not properly understand how the transition unstable - testing goes , but...) my packages from source libprinterconf, see http://bjorn.haxx.se/debian/testing.pl?package=libprinterconf are waiting for snmpkit to go into testing; at the same time, my packages from source snmpkit seem ready, are quite old, see http://bjorn.haxx.se/debian/testing.pl?package=snmpkit but still they are not going into testing. what is happening? a. ps: please CC me -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef signature.asc Description: Digital signature
email error message from d.o may be better
hi I sent an email to [EMAIL PROTECTED] instead of debian-68k@lists.debian.org ; the error message that I got was strange (in particular, the two lines procmail: Error while writing to DeadLog procmail: Error while writing to /var/mail/debian look as if there is a misconfiguration somewhere ); moreover, it would be better if the error was akin to no such user. Hope someone may find some time to look into it (altoh I ack that it is a minor minor problem) (btw, I do not know if this list is the best place to report this - any suggestions on where I should report this?) a. - Forwarded message from Mail Delivery System [EMAIL PROTECTED] - From: Mail Delivery System [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: pipe to |/usr/bin/procmail -p .procmail/rc.split generated by [EMAIL PROTECTED] Child process of address_pipe transport returned 73 (could mean can't create output file) from command: /usr/bin/procmail The following text was generated during the delivery attempt: -- pipe to |/usr/bin/procmail -p .procmail/rc.split generated by [EMAIL PROTECTED] -- procmail: Error while writing to DeadLog procmail: Error while writing to /var/mail/debian -- This is a copy of the message, including all the headers. -- Received: from cibs10.sns.it (reed.sns.it) [192.167.206.30] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1E6pjV-00024M-00; Sun, 21 Aug 2005 08:19:29 -0500 Received: from [192.167.206.31] (helo=sns.it) by reed.sns.it with esmtp (Exim 3.35 #1 (Debian)) id 1E6pkn-0006wk-00 for [EMAIL PROTECTED]; Sun, 21 Aug 2005 15:20:49 +0200 X-Virus-Scanned: by cgpav Received: from [192.84.155.215] (HELO tonelli) by sns.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 36570565 for [EMAIL PROTECTED]; Sun, 21 Aug 2005 15:21:04 +0200 Received: by tonelli (Postfix, from userid 1013) id 1EA0D176C1; Sun, 21 Aug 2005 15:19:28 +0200 (CEST) Date: Sun, 21 Aug 2005 15:19:28 +0200 To: [EMAIL PROTECTED] Subject: zope2.7 failed to build Message-ID: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i [omitted] - End forwarded message - -- Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef signature.asc Description: Digital signature
Re: snmpkit stuck in unstable ?
Andreas Barth wrote: * A Mennucc ([EMAIL PROTECTED]) [050908 13:39]: (maybe I do not properly understand how the transition unstable - testing goes , but...) my packages from source libprinterconf, see http://bjorn.haxx.se/debian/testing.pl?package=libprinterconf are waiting for snmpkit to go into testing; at the same time, my packages from source snmpkit seem ready, are quite old, see http://bjorn.haxx.se/debian/testing.pl?package=snmpkit but still they are not going into testing. what is happening? I'd say your package is part of the c++-abi-transition. sorry... since the dependency on c++ libraries is not listed in the above excuses, I forgot about it a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
I approve Drew Parsons wrote: I remember some of us belatedly suggested sarge should be Debian 4.0, though it was too late (May?) to accept that. (it was me) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
Antti-Juhani Kaijanaho wrote: On 20050708T181259-0400, Johan Kullstam wrote: What signal is meant by 3.1 versus 4.0? Does your intended audience have any concept of the distinction? The usual distinction, when it is made, is that bumping the major number indicates a disruptive upgrade (changing how things work, not just adding new things). the change of gcc 3 to gcc 3 is disruptive (to c++ binaries) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Planning a libglade to libglade2 transition
the same for me: I develop and mantain some gtk packages there is no such thing as an easy transition from gtk1 to gtk2 Andreas Tille wrote: On Tue, 14 Jun 2005, Martin Michlmayr wrote: And how hard is that? It seems that tons of stuff in the archive still requires GTK1. It would be great to move them all to GTK2. Unfortunately it's not that simple. I'm upstream for two packages using GTK1 and I spended some time for investigating how hard would be the move. Even if I would like to switch to GTK2 it would cost so much time that other projects have much higher priority. It is kind of I can perfectly use this software as it is and thus I wished somebody would lend me his time travel device to give me an additional week of live time to port these projects but at current state I see no chance to do this soon (even if I would love to). Kind regards Andreas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Luca - De Whiskey's - De Vitis MIA?
Roberto C. Sanchez wrote: I am wondering what the deal is with Luca and his packages, specifically httperf. httperf was uploaded once, 3.5 years ago. It has two important and one normal bug [0]. He has never responded to any bug on httperf. #215277: httperf: please update libssl dependency (1 year and 239 days) #308097: httperf errors out when requesting SSL sessions (30 days) #170060: Please move httperf to main archive (2 years and 198 days) Of his other packages [1], his latest upload was late 2003. He has a number of bugs open [2] as far back as 6 years ago. Many are unacknowledged, including two important bugs, one regarding a policy violation in a package description and another about a filename collision between a package he maintains and another package. Just wondering what, if anything, should be done. Personally, I would be willing to adopt httperf because I would like to see the bugs fixed. -Roberto [0] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=httperf [1] http://qa.debian.org/[EMAIL PROTECTED] [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=luca%40debian.org some people started to work on zope , on pkg-zope on alioth, and indeed we have not heard from him in a long time (that is, since June 2004) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
Jaldhar H. Vyas wrote: On Fri, 6 May 2005, Marc Haber wrote: Their fault for releasing a book about unreleased software which is bound to be outdated the day that sarge will actually release. Uh-uh and when will that day be? And don't give me any of that when it is ready nonsense. The release version number was ready a long time ago. The problem isn't a concern for quality, it is people like you and Andrea who don't follow process, me, I do my part of the work in Debian and nobody ever contacted me regarding the choice of the number a. who don't contribute when the actual decisions are being made, on the opposite, I am happy to contribute : I always vote, for example a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
Joey Hess wrote: Andrea Mennucc wrote: now that sarge is frozen, I would like to start a discussion on the number to associate to Sarge release. Now that sarge is frozen we have /etc/debian_version, the installation manual, the release notes, and the website all containing the version number 3.1. I've probably forgotten a few other things. I dont see it as a big stopper. You are saying that the number 3.1 appears /etc/debian_version (that lives in package base-files) and in 3 documents (and translations). How much work does it take to change the above? (If I add access to the above, I would offer my time to do it myself). Updating all these things to change a version number kinda misses the point of a freeze, doesn't it? yes and no I would bet 10$ that during the freeze more than 300 packages will be admitted into Sarge. And I would bet another 5$ that base-files will be one of them. And I would bet another 5$ that both the release notes and the installation manual will need to be edited at least once before we release. Moreover. For me, the point of the freeze is to release a new Debian, and be proud of it. Part of my pride would be highlighted by seeing it named 4.0. Call me sentimental. 3.1 seems just a minor upgrade, something that comes out to fix a few bugs and add a few minor features, not what summarized 3 years of work and commitment. see shy jo, who argued for 4.0 at the appropriate time to discuss the version number to use That is puzzling me. In 2003, in the thread starting at http://lists.debian.org/debian-devel/2003/01/msg00337.html most people were agreeing with calling sarge 4.0. I inderstand from your signature that you were for 4.0 as well (altough I do not find your support in above thread). So why nobody did actually change the number then? a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
hi I see that some people are opposing using 4.0, so I give up. I just write this e-mail to better understand why Bartosz Fenski aka fEnIo wrote: On Thu, May 05, 2005 at 01:17:45AM +0200, Andrea Mennucc wrote: So I would much prefer if sarge would be called Debian 4 Do you agree? I would prefer to be maintainer of the well known distribution which *doesn't* bump versions only for the fun of it. what is wrong in bumping version numbers? (and I mean, particularly in this context) so, (I am just curious) , why do people (e.g. you) oppose that? joke we all learn from arithmetic that there is an infinite number of positive integers, so we are not in risk of exhausting them /joke I know that for most people numbers have some magic meaning, but please can we try to provide stable OS by its quality and not version number? Calling sarge 4.0 won't make it better. neither calling it 3.1 and I never implied that calling it 4.0 makes it better it just sounds better (for me at least) neither choice prevents us from working in making Sarge better -- bye a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
hi I happen to mantain 'snmpkit' ; you may give it a look a. Christian Hammers wrote: Hello [regarding #306840 and with more info in #243870] One of my packages, Quagga, is licenced under the GPL but is supposed to get linked against NetSNMP. That now is problematic, as NetSNMP depends on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. Does anybody know a good and easy to replace GPL-compatible SNMP library that provides SNMP MUX capatiblities for C applications? Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package? bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian sarge is 3.2 or 4 ?
hi everybody now that sarge is frozen, I would like to start a discussion on the number to associate to Sarge release. According to http://www.nl.debian.org/releases/sarge/index.en.html Sarge may be released as Debian 3.1 In 2003, Scott James Remnant proposed in http://lists.debian.org/debian-devel/2003/01/msg00337.html that Sarge should be Debian 4; some (most?) people did agree. But some other people refer to sarge as Debian 3.1 (or 3.2) Considering that woody was released 19 Jul 2002, it took us ~3 years to release; in the meantime, all most important components changed completely; and we did a lot of work in Sarge, that I do not want to see numerically represented as sarge = woody + 0.1 So I would much prefer if sarge would be called Debian 4 Do you agree? a. (ps: I apologize if this has been discussed recently... I googled around, but did not find any recent reference) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mplayer 1.0pre7
I had forgotten mplayer_1.0pre7.orig.tar.gz now it is there A Mennucc wrote: hi mplayer 1.0pre7 is ready and packaged at http://tonelli.sns.it/pub/mplayer/sarge a. ps: still no news from ftpmasters... hope they at least will try to read http://people.debian.org/~mjr/mplayer.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mplayer 1.0pre7
hi mplayer 1.0pre7 is ready and packaged at http://tonelli.sns.it/pub/mplayer/sarge a. ps: still no news from ftpmasters... hope they at least will try to read http://people.debian.org/~mjr/mplayer.html -- Andrea Mennucc E' un mondo difficile. Che vita intensa! (Tonino Carotone) signature.asc Description: Digital signature
arm seems OK: release status?
hi reading the latest message on the status of the release http://lists.debian.org/debian-devel-announce/2005/04/msg3.html I understood that the release was near, and that, given good progress with d-i and testing-security, the main showstopper was the arm buildds trouble. (*) Yesterday I have uploaded two packages, with low priority, and the arm buildds compiled them after only 4 hours. So I am curious : what is stopping the freeze now? testing-security? a. ps: (*) OTOH, that message was issued on april 1st :- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arm seems OK: release status?
Steve Langasek wrote: So I am curious : what is stopping the freeze now? testing-security? What's stopping the freeze is all the people uploading their low-priority packages and keeping the arm autobuilders from ever catching up on the ones that are actually medium and high priority. ARM is *not* OK; we still have only two buildds on-line instead of the usual four, and the build queue is getting longer, not shorter. hi Steve your answer is puzzling. How is the queue in arm buildd managed? If I would design a queue for a buildd, I would put medium and high priority packages before low priority packages. You seem to suggest that this is not the case. So I do not fully understand your ever catching up...medium and high priority comment. Or... wait... maybe I understand... the problem is http://buildd.debian.org/stats/graph-week.png That, and still waiting for the glibc upload to roll in, and for testing-security to be 100% on-line. ok a. ps: I promise not to upload anything else :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arm seems OK: release status?
when a buildd builds a package, it first install all build-dependencies, then compiles, then remove all build-dependencies. For my package, that was a total of 113 MB of data to be moved in and out of disks; since ARM is running late, maybe it would be wise to not remove build-dependencies at the end of a run, (and check for any build conflict before starting, and just remove that) for example, to compile my package , sbuild had to install things as gettext, libtool autotools-dev debhelper xlibs-dev libxaw7-dev xutils texinfo I propose to keep them installed for some time.. moreover my package depends on libgtk2.0-dev: I guess there are many packages that has the same dependency a. Steve Langasek wrote: On Mon, Apr 11, 2005 at 09:25:56AM +0200, A Mennucc wrote: reading the latest message on the status of the release http://lists.debian.org/debian-devel-announce/2005/04/msg3.html I understood that the release was near, and that, given good progress with d-i and testing-security, the main showstopper was the arm buildds trouble. (*) Yesterday I have uploaded two packages, with low priority, and the arm buildds compiled them after only 4 hours. So I am curious : what is stopping the freeze now? testing-security? What's stopping the freeze is all the people uploading their low-priority packages and keeping the arm autobuilders from ever catching up on the ones that are actually medium and high priority. ARM is *not* OK; we still have only two buildds on-line instead of the usual four, and the build queue is getting longer, not shorter. That, and still waiting for the glibc upload to roll in, and for testing-security to be 100% on-line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please make ARM buildd more efficient, was Re: arm seems OK: release status?
Paul TBBle Hampson wrote: On Mon, Apr 11, 2005 at 02:31:15PM +0200, A Mennucc wrote: when a buildd builds a package, it first install all build-dependencies, then compiles, then remove all build-dependencies. For my package, that was a total of 113 MB of data to be moved in and out of disks; since ARM is running late, maybe it would be wise to not remove build-dependencies at the end of a run, (and check for any build conflict before starting, and just remove that) Funny. I was under the impression that the buildds _did_ leave these packages installed, and that was one of the things that pbuilder could test that the buildds don't, that build-depends are complete and sufficient. when a buildd is running ahead, it may as well waste time in installing and deinstalling; but when it is not, it should avoid that task I'm sure it's been suggested that the buildds remove the extra packages after each run, but that is considered too inefficient, and the buildds are not _expected_ to pick up all build-depends bugs. ARM builder is inefficient: http://buildd.debian.org/fetch.php?pkg=xmorphver=1%3A20050408arch=armstamp=1113139251file=logas=raw I am sending this e-mail to Ryan Murray (who is at the end of the above log), so to make him aware of this issue a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mplayer 1.0pre6a-4 for i386 and PowerPC and sparc
Laszlo Boszormenyi wrote: On Tue, 2005-03-15 at 00:56 +0100, Sven Luther wrote: Well, there are two issues here, one is why mplayer is not in debian. Supposedly it was because the legal situation was not clear and that made it dangerous and maybe illegal for us to distribute it. I wonder why ubuntu does not have this problem (even it if is in universe/multiverse), and if maybe this means the problems got solved and it could be included in debian now, or maybe because ubuntu just didn't care about the legal dubious situation. Just a note, that their homepage[1] is something like closed: Free Software Multimedia Threatened by Software Patents Closed for patent infringement This site has been shut down because of numerous patent violations in MPlayer. The other free software multimedia players are next. [...] This is a preliminary warning, but everyone should look into all possibilities. if mplayer will become illegal because of the new european patent laws, so will be xine and all other programs that are already in Debian a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
