Re: apt-get and SOCKS
xHemi schrieb: > This might not be the correct place but here goes.. > > apt-get provides http_proxy and ftp_proxy support but why not SOCKS? > I have no experience with SOCKS other than that I use it daily in conjunction > with firefox and ssh. I think it is a feature which could be of use > to others as well since it would enable you to use apt over ssh. > > Regards > > > !DSPAM:47c6934330731369617410! > > > Hello, is there any reason to encrypt your traffic on downloading packages? I think this will only cause more traffic and cpu overhead on the mirrors instead of help anything. -- Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#454993: RFH: fglrx-driver -- non-free AMD/ATI r5xx, r6xx display driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, it is an old RFH, but I want to remind it: We are needing help with the fglrx packaging. The person who would apply for this job should require the following: - - Using a radeon card > 2000 HD, which is supported by fglrx >= 9.4 - - Using unstable for testing out new releases - - He/She hasn't got to be a DD, but minor packaging experience should be available, at least he/she should know how to build a package from svn trunk - - Interested in testing out and hopefully also hunting open bugreports. FAQ: - - Why we do not need stable users for this job? The only issues we may fix in stable releases are packaging ones, which is our code, in some *realy rare* cases also on the kernel module.. - - Why do we require ppl with a radeon card > 2000 HD? fglrx > 9.3 dropped support for all belower chipsets, the current team is unable to realy test the new uploaded releases, because of the lack of hardware. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqLGQsACgkQ2XA5inpabMcrxwCfT2XoTo+1QSwsc2PkDeirgSgq IBoAnifftV357ov6+cV5ITS/lvgPMCK5 =HmgG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Taking care of exising packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leinier Cruz Salfran schrieb: > Hello > > I want to take this opportunity to add that the bugs need to be > addressed, especially the wish list. There are people who send bugs to > request to be added or taken into consideration certain properties and > functionality in the packages and maintainers are ignoring. Another Examples? Personaly on wishlist items (new upstream functionalitys) it is the job of upstream to address them, the maintainer should forward it to them and maybe upstream does not want it? > thing is the system of new packages (debian-mentors, > mentors.debian.net) .. I think that there could be a team dedicated to > addressing this important task, same as the team dedicated to the > kernel, the core packages, translation, among other important packages. I think you do not know how much work it is to sponsor a packages, especially if it is NEW or the maintainer does not have enough experience yet and the whole sponsoring requests ends up in a 30 mails conversation.. > > I believe that this significantly affects the quality of the > distribution Debian has the biggest software repository of every distribution. I do not think that it is a *such important* part to include new software. The most important RFS reports are such which fixes bugs (especially RC ones). For some weeks I take a look on the mentors mail archive and the packages list for sponsors on mentors.debian.net - I wanted to sponsor packages which are waiting since "ages" to get uploaded. My result was, that most packages are more or less quickly uploaded, but neither the sponsor and maintainer replied to the thread on the mailing list / removed the package from mentors, which is bad. What I want to say: I think the current situation is not as dramatical as some people state it here, please correct me if I have got a wrong view of it. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqMP20ACgkQ2XA5inpabMdEIgCeLET/h/2n8CDkpgS6WTShKNBa eeEAn2pvmlsMiyhI1/u+ug1FZtUEUjsC =3XMu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#454993: RFH: fglrx-driver -- non-free AMD/ATI r5xx, r6xx display driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leinier Cruz Salfran schrieb: > hello. > > I see this post and I would ask the team that keep the old version of > theses packages in order to allow me to use my old integrated video card > 'ati radeon xpress 200' I am sorry, this is not possible.. fglrx 9-3 does not support the kernel and especially xorg in the unstable version and the support will never appear from AMD. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqMRjgACgkQ2XA5inpabMf5zgCfcgMf0x49VB24zSFv3zWKRIMJ TMkAniPYQCZYfBIBWODIf7BJOjrK4KBo =VyCL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Taking care of exising packages
Leinier Cruz Salfran schrieb: El mié, 19-08-2009 a las 20:07 +0200, Patrick Matthäi escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leinier Cruz Salfran schrieb: Hello I want to take this opportunity to add that the bugs need to be addressed, especially the wish list. There are people who send bugs to request to be added or taken into consideration certain properties and functionality in the packages and maintainers are ignoring. Another Examples? Personaly on wishlist items (new upstream functionalitys) it is the job of upstream to address them, the maintainer should forward it to them and maybe upstream does not want it? You're right in that part, it all depends from the point of view we look, now evaluate this: if the sender requests that maintainer of the package to take into consideration to add or modify any part of the package, or add something missing and that can be added? For example, if I create a program in Perl or Python, I pack and upload it and someone asks me to consider adding a file that may help, or someone requests a modification of the code? That is what I mentioned in my previous post. Modifying isn't as easy as a patch sounds in most cases, because you may also break the usage of it, like ABI/API incompatibilities. thing is the system of new packages (debian-mentors, mentors.debian.net) .. I think that there could be a team dedicated to addressing this important task, same as the team dedicated to the kernel, the core packages, translation, among other important packages. I think you do not know how much work it is to sponsor a packages, especially if it is NEW or the maintainer does not have enough experience yet and the whole sponsoring requests ends up in a 30 mails conversation.. I do not think you're right in that part. I do not deny that I lack experience, but I know that to create a package takes time and dedication and thus, to evaluate and see if the package meets the minimum requirements takes more time. For the same reason is that, as a suggestion, I explained to DD to assess the possibility of creating a team of DD that can be charged with this task that is as important as many other In my opinion it would not help to creae a special force team for it. Currently there are many DDs who are looking on mentors for potentioal sponsorings. Most people have a quick lock at the package and decide then if they are able/interested in sponsoring it, as a sponsor you also have some more or less obligations about the package. Personally I do not want to sponsor gnome apps, because I do not realy know the gnome internals, etc etc. Please also note that every DD is doing this work in his free time, this would be still the case if we have got a special sponsoring team - the current situation wouldn't get better with this. I believe that this significantly affects the quality of the distribution Debian has the biggest software repository of every distribution. I do not think that it is a *such important* part to include new software. The most important RFS reports are such which fixes bugs (especially RC ones). I agree with you in the part that is more important to address a package that updates or fixes a bug, but it is also important to address the new revenue package. Yes and no. That is just a question of priorities: 1) rc bugfixing 2) any other bugfixing 3) new packages An example of this, when I started using Debian one of the things that impressed me was the amount of programs, games, tools, and libraries that exist in the repository. Just ordered a 'apt-get' and was installed and almost ready to use. Yes this also was in the past one reason why I switched to Debian. :-) For some weeks I take a look on the mentors mail archive and the packages list for sponsors on mentors.debian.net - I wanted to sponsor packages which are waiting since "ages" to get uploaded. My result was, that most packages are more or less quickly uploaded, but neither the sponsor and maintainer replied to the thread on the mailing list / removed the package from mentors, which is bad. I have for you a scenario: Suppose you're excited about Debian, you like Debian, you want to help to make Debian better and spend part of your time to package a program, game, tool or a library. When you finished, you test it with 'lintian', install, uninstall, then uploaded to the 'mentors.debian.net' and finally sent an RFS. Spend one week, two weeks, three weeks and it's time that you ask yourself: What is happening? Until the time comes to desist from a help and good day, after a very long time, you receive a message talking about a DD package, then what are you doing? And the time comes that you no longer want to help. A good day, after a very long time, you receive a message from a DD talking about your package, what you would do in that time? I personaly know how frustrating it
Serious problem with geoip - databases could not be build from source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello lists and maxmind, (please CC me in your replys, I am not subscribed to debian-legal@ and debian-devel@, thanks). First some facts: - - geoip is installed/used by many users, popcon reports something like 20% - - Some more packages are in the reverse dependency list - - Much much much more packages are in the reverse reverse dependency list of it GeoIP is a quite usefull library for geolocation. It has got a stable ABI/API and upstream is normaly very helpfull with patches and issues. But I have got a serious problem with it: 1) upstream delivers the databases only as binary .dat files 2) csv versions of the free databases are available 3) upstream isn't cooperative to tell us how to build the binary files from the csv (source) files I tried to fix this issue together with upstream, but his decision was, that we should remove the database(s) from the tarball and let them download at install time, this would be a candidate for contrib. If Boris Zentner ACKs with it I will publish the mailing result of us. I disagree with it, because of the reverse dependencies. GeoIP is also not a candidate for main without any database, because the whole library isn't usefull in any manner then. Currently I see only three options: 1) upstream decides to open his build system 2) we move it to contrib with all consequences 3) we leave it as it is 2) would be a disaster in my and many other eyes, 3) would be an exception of the DFSG, 1) is in my opinion the only acceptable solution for this problem. I hope you could help me. :) - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqUHgAACgkQ2XA5inpabMdu4QCgrN4zZveJ7kqV7+bujaaTjFaM hxcAnRlfuZeQAy3bbB10RPYyu/3iUzDK =s36I -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Serious problem with geoip - databases could not be build from source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MJ Ray schrieb: > Patrick Matthäi wrote: >> GeoIP is a quite usefull library for geolocation. >> It has got a stable ABI/API and upstream is normaly very helpfull with >> patches and issues. > [...] >> Currently I see only three options: >> 1) upstream decides to open his build system >> 2) we move it to contrib with all consequences >> 3) we leave it as it is > > 4) we deduce the build system by looking at the CSVs and how the > library uses the binary dat files, then junk the upstream-built > dat files. I've no idea if this is feasible, but it's another > option. This is also an option, I have got one serious semi ACK for reverse engenierng it, but it is also on my list of "last choices". > > It seems a shame if an upstream wants a library removed from the > debian operating system and uses data files to achieve that, but > shouldn't we respect that for now? It is unacceptable for Debian and many other distributions. It is in my eyes also unacceptable for the business model of maxmind, because there *will* be less customers for their commercial database version if distributions/authors drop GeoIP support, because it is non-free. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqUKKcACgkQ2XA5inpabMfvmgCfTiHxsxw0sVhi+DmnBh206nts 0nAAn3f+Qz2X/IYt/9oSKS8igw9Ji476 =AnXl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE: Serious problem with geoip - databases could not be build from source
Le mercredi 26 août 2009 à 11:09 +0200, Bjørn Mork a écrit : > You are aware of the GPLv3 licensed database at > http://software77.net/geo-ip/ ? >Woohoo, nice. Combine this with Julien’s idea to implement support for a new >database format, and I think you have the correct solution. And who ports it to this database format (they are incompatible) and maintains it in the future? I think this job may be as hard as reverse eng. it, or? Cheers.
Re: Serious problem with geoip - databases could not be build from source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Matthäi schrieb: > Hello lists and maxmind, > > (please CC me in your replys, I am not subscribed to debian-legal@ and > debian-devel@, thanks). I am now, so ignore it. :) . > But I have got a serious problem with it: > 1) upstream delivers the databases only as binary .dat files > 2) csv versions of the free databases are available > 3) upstream isn't cooperative to tell us how to build the binary files > from the csv (source) files Here are the results: - - With the great help from Kalle Olavi Niemitalo it is now possible to build a good working GeoIP.dat from source, nice work! - - Upstream does not provide (anymore?) csv files for the IPv6 database, I asked them to do so, then we are possible also able to to provide this database in the Debian packages. - - I added several scripts which are useable for cron.d: geoliteasnum.sh: the ASNUM edition geolitecityupdate.sh: The city database geolitecountryv4.sh: The classic Country database (IPv4) geolitecountryv6.sh: The IPv6 country database > > I tried to fix this issue together with upstream, but his decision was, > that we should remove the database(s) from the tarball and let them > download at install time, this would be a candidate for contrib. > > If Boris Zentner ACKs with it I will publish the mailing result of us. Since I opened up this discussion, they didn't replied to any of my mails. > > I disagree with it, because of the reverse dependencies. > GeoIP is also not a candidate for main without any database, because the > whole library isn't usefull in any manner then. Now it is safe. > Currently I see only three options: > 1) upstream decides to open his build system Maybe they will decide to do so in the future, I hope it. > 2) we move it to contrib with all consequences > 3) we leave it as it is > > 2) would be a disaster in my and many other eyes, 3) would be an > exception of the DFSG, 1) is in my opinion the only acceptable solution > for this problem. > > I hope you could help me. :) Thanks for all your hints and work! - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqWv2wACgkQ2XA5inpabMf5QACfbwFrZGKVUgoQGsAfMvMngCb1 OrIAnAuLMqqq+QhEv57wlm9EKC70yL1m =bSR/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#544539: RFP: Linux Unified Kernel
Ivan Borzenkov schrieb: Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: Linux Unified Kernel Version: 0.2.4-1 Upstream Author: Insigma li...@insigma.com.cn URL: http://www.longene.org/en/ License: GPL Description: wine and windows drive model in kernel The LUK project aims to add all Windows kernel mechanisms into the Linux kernel, including Process management, Thread management, Object management, virtual memory management, Synchronization, System calls (Syscall), Windows Registry, WDM (Device driver framework), Windows DPC mechanism, etc., to form a new kernel. Thus, the new kernel allows both Linux and Windows applications and device drivers to work directly without virtualization or emulation. Weee, a registry on Linux? WTH? I was so happy that Linux operating systems do not have such a crap. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: OK to reduce priority of update-inetd to optional?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serafeim Zanikolas schrieb: > Hi, > > Is it OK to reduce update-inetd's priority to optional, to agree with the > archive admin's override? (It should be, as all its rdepends are at most > optional) > > It should be Priority: standard only if people use it interactively, and > expect it to be part of a standard installation (but I'm guessing that this > isn't common). > > update-inetd_4.32_all.deb: package says priority is important, override says > optional. > In my opinion (and I sponsored this upload) it is okay. In my opinion there is no need that this packages has a bigger importance than optional, this should fit for this package. You may report this against ftp.debian.org. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqgKFQACgkQ2XA5inpabMfhvQCeLy0RScUaQ4HxMUAwWIebeHQY nksAnR54p7JQfSwsBULyhtITNNEkXyUU =+rYd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Anton Mitterer schrieb: > Hi. > > Some time ago, I've wrote several bug reports to packages, that download > files from some non-apt-secured sources of the web, and install them. > > I got more or less positive feedback from maintainers that happily > accepted my suggestions, to those who thought they were crap and not > necessary ;) > > > Some days ago Tom Feiner opened #546945 (and CC'ed) me, which proved me > that I'm not the only one concerned about this issues. > > > So I thought it might be worth to bring them up for discussion here. Maybe we should also think about the downloaded files itself. A firmware for Linux or a plugin for firefox could do realy bad things. In the case of geoip it is just a data file (like a .svg etc) with no attacking vector. The attacker could only inject a corrupted database and geoip will throw errors/false positions. Is this realy a vector for it? - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkqyj/QACgkQ2XA5inpabMcu2QCcDPhC6W99H+VCyQNbfE5FItiE MXgAoJko/JL4r7yXSIpnmgrLZKWpMqoI =mQ9S -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leo "costela" Antunes schrieb: > Hi, > > Patrick Matthäi wrote: >> Maybe we should also think about the downloaded files itself. >> A firmware for Linux or a plugin for firefox could do realy bad things. >> >> In the case of geoip it is just a data file (like a .svg etc) with no >> attacking vector. The attacker could only inject a corrupted database >> and geoip will throw errors/false positions. >> >> Is this realy a vector for it? > > GeoIP's database is AFAICT a binary format, which means the library > could theoretically suffer from buffer-overflows and such. If this is > indeed correct, you'd just need apache's mod-geoip, for instance, to put > your server in potential trouble. Sure if the library / program itself is vulnerable for it, then it is a real problem. I should be more precise: Is it realy a problem if the user "just" gets a corrupted database? There are _currently_ no known security issues in this way. That is what I mean with "realy". > > Being strict, almost any format can be an attack vector in some way > (phishing sites are another extreme example, and obviously one we > shouldn't try to solve through the packaging system), but I somewhat > agree with Christoph that we could draw the line on packages that > perform automatic installations of binaries from external unchecked sources. > > Cheers > - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkqynHQACgkQ2XA5inpabMfiUQCdFf6gjXFwicnax/JB3W0LILlq ll0AoKCI9Nw0dOj3SPJKKZlWMAWJ1llA =L6uy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael S Gilbert schrieb: > On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote: >> Hi. >> >> Some time ago, I've wrote several bug reports to packages, that download >> files from some non-apt-secured sources of the web, and install them. > > i also started a similar discussion a while back, which was met with > mixed opinion [0]. i tried to lay out the full spectrum of issues > related to this problem, but many just focused on the non-free aspect. > no consensus was reached. > > checksums are a good start, but if the data itself is non-free (or > closed or obscured), then how can you be sure it is not malicious? > > i think it is a matter of trust, and maybe the key would be that scripts > should only accept the external data if it is signed and hashed by an > authenticated DD's gpg key. This would be a good option. But I think you do not have access to the upstream files and also you can not sign them, maybe upstream itself also do not want to do it. Hosting them on my own host is also not a good option. > > mike > > [0] http://lists.debian.org/debian-devel/2009/02/msg00461.html > > - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkqzGJEACgkQ2XA5inpabMf8LgCgiHwsWxk12w91O4ozp2vEwLsD IuoAoIErTVqIMWd9muwK0tfBWAgycf3n =r5nE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael S Gilbert schrieb: > On 9/18/09, Patrick Matthäi wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Michael S Gilbert schrieb: >>> On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote: >>>> Hi. >>>> >>>> Some time ago, I've wrote several bug reports to packages, that download >>>> files from some non-apt-secured sources of the web, and install them. >>> i also started a similar discussion a while back, which was met with >>> mixed opinion [0]. i tried to lay out the full spectrum of issues >>> related to this problem, but many just focused on the non-free aspect. >>> no consensus was reached. >>> >>> checksums are a good start, but if the data itself is non-free (or >>> closed or obscured), then how can you be sure it is not malicious? >>> >>> i think it is a matter of trust, and maybe the key would be that scripts >>> should only accept the external data if it is signed and hashed by an >>> authenticated DD's gpg key. >> This would be a good option. But I think you do not have access to the >> upstream files and also you can not sign them, maybe upstream itself >> also do not want to do it. >> >> Hosting them on my own host is also not a good option. > > you could host just the hashes for the external files (signed with > your key) on your site. then you wouldn't have to duplicate > upstream's data files nor spend (much) of your own bandwidth (since > the hash files should be fairly small in most cases). Hmm good idea :) - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkqzzKEACgkQ2XA5inpabMdsSQCgg0+9S6my1TCXUZoFn6nR3+N4 tCwAn3ukfDSdOovEl/eoZx3eTU7YUgYi =YMqo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Anton Mitterer schrieb: > By the way,.. a similar problem is also present in many other packages. > Let me just name a few concrete examples so that you get a feeling on > what I mean. > > > > 1) debootstrap/cdebootstrap > IIRC, only cdeboostrap requires a keyring per default (or did it always > use debian-archive-keyring?) > Anyway,... while deboostrap supports verifying signatures and specifying > a keyring,.. it doesn't to so per default. > Neither does it fail if just nothing is specified (it should only work > with verification, if some special parameter e.g. --dont-verify-sigs is > given). > I've filed a bug for this some time ago,... (and unfortunately a 2nd one > recently) but it does not seem that upstream is willing to change this > behaviour. > > > 2) pbuilder and piuparts (and probably the debian buildd's, too) create > chroots to build the packages, and I think they're using one of the > aboves for this. > Per default they're not configured to use them (well at least > debootstrap) with signatures. > => Building packages may lead to installation and execution of malicious > packages. > > I've filed bugs for at least pbuilder and piuparts. > > > 3) aptitude > Well I'm not sure here as I haven't had the time to read the code. > For some actions (install/upgrade/dist-upgrade) it uses secure-apt as it > simply uses apt-get (IIRC). > > But what about actions not provided by apt-get, like aptitude download > . > So far I was not able to find out whether this uses secure apt or not. > > > 4) apt-file (which I like very much) > The Contents files are not yet signed AFAIK,.. and thus it cannot do any > verification. There are so many scenarios where we are not able to verify any signatures (upstream does not provide any kind of verification) or where it is non-sens. If we are so pedantic about this topic, we should also ask ourself, if packages like wget, curl, ncftp, ftp etc fullfil the security requirements. We can not secure *everything*, but the most important parts, which Debian itself controls. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkq5JD0ACgkQ2XA5inpabMfJYQCfba6GxGaOkzct0yN9iRvU/f6j 4nIAnAtayYfmdpYWgF9EZX/zE2J+8fHf =35fe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is it time to remove sun-java6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Klose schrieb: > On 10.10.2009 13:43, Sam Morris wrote: >> On Sat, 10 Oct 2009 11:14:20 +, Sam Morris wrote: >> >>> On Thu, 08 Oct 2009 11:44:21 -0400, Barry deFreese wrote: >>>> There has also been some similar discussions in Ubuntu with some users >>>> reporting that some web sites and packages don't work with openjdk but >>>> I have not seen a lot of concrete proof. >>> >>> Last time I tried the Java Climate Model (which can be found at http:// >>> www.climate.be/jcm) it failed to work with openjdk. >> >> Ok, I tried it again and it seems to work fine! Great! >> >> The menus and tabs are a bit screwed up in the (default) GTK+ look-and- >> feel, but that's never really 100% worked even with Sun's official Java >> version. >> >> I just rememberd another thing that didn't work with openjdk... WebSDR, a >> software radio reciever<http://www.websdr.org/>. Games on www.playray.de also do not work with openjdk, e.g.: http://www.playray.de/spielen/klassische/yatzy/ With iceweasel I only get a grey window, also for every other game on this site. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrSULkACgkQ2XA5inpabMev1gCZAYUzqbsslss2SkJy0J7t7VCX 1/QAnAljuMT3kqKNcnZQlyiKAsZTHHI3 =dbm8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is it time to remove sun-java6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Allums schrieb: > Patrick Matthäi wrote: > > > >> Games on www.playray.de also do not work with openjdk, e.g.: >> http://www.playray.de/spielen/klassische/yatzy/ >> >> With iceweasel I only get a grey window, also for every other game on >> this site. > > That's a Flash issue. Uninstall some of swfdec (I forget offhand which > bits) and install flash-nonfree, the corresponding Mozilla plugin, etc. > Sorry I'm being vague on this, but I'm minus some hours on sleep and > really should be in bed. Someone can corroborate me or correct me. Yeah I can correct you: It is java, not flash. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrSaVgACgkQ2XA5inpabMcRSACgoD1nR0+GVKoHxYIOW66Z7F6p HegAn2xfwr9k+yEf6NjuxSTacU2QJQQ7 =xt12 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Weimer schrieb: > * Michal Čihař: > >>> Can gnaughty download anything other than porn? >> Not really without patching the source. > > And the content is non-free, right? Then it should go into contrib. Maybe there is some Open-Porn available, ftp-masters have to test it out. :-) - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrWEQYACgkQ2XA5inpabMd3kgCfUQpsSOI9yMFiRmEyB7b6/eJY fqEAn2w2E6jX4Qz99o3t82rX2L/Q0vZ+ =Vopn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery schrieb: > Rodrigo Gallardo writes: > >> I could just put up a site with CC porn, then. Aren't we supposed not >> to discriminate against fields of endeavour? > > The package description strongly implies that gnaughty works only with one > specific porn index or download service, which is presumably non-free. If > this is not the case, the proposed package description should be fixed. > Seems like the description has to be fixed, there is no pay-only content and it has included some more download sources, not only one "vendor". But also if the _free_ software is for downloading etc. pay-only content like music, I do not think that it has to enter contrib, because it does not has got a real dependenie on non-free stuff. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrWKoAACgkQ2XA5inpabMeZyACdFCpTQT3chGiIDe/PCW7suFZp VH0An2/RGLmmRJ1sPLj7stejUt92CVNX =UUsG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Kern schrieb: > On 2009-10-14, Russ Allbery wrote: >>> But also if the _free_ software is for downloading etc. pay-only content >>> like music, I do not think that it has to enter contrib, because it does >>> not has got a real dependenie on non-free stuff. >> Yeah, it's a bit of a marginal case. We have, for instance, Perl modules >> to talk to the Amazon APIs in main, although in most of those cases the >> API is relatively open and some other sites also implement it. > > The appearance of Eucalyptus is pretty recent, though. So you'd need to > wait until a free service of an API gets released? How feature complete > does it need to be? If I release a "compliant" porn directory with only one > pic, would that be appropriate? And I could easily make it non-porn too. > > zsnes used to be in contrib, but somebody made the case that there could > be, in fact, free roms, because the way how to program the box is not > exactly secret anymore. (If they would be buildable on Debian is another > question.) It lives in main now and my gut feeling is that it's the right > thing to do, given that the code base is free to modify, share and gives > you the usual rights of a free software license (here: GPL2). Please move this whole discussion to debian-legal now. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrWTt0ACgkQ2XA5inpabMfMkgCZAa1TyfmAqpzQN+I15vl2pohe 5lEAni039ylmJ95ylOC3RWVX/hmGnHJU =JCXs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery schrieb: >> Please move this whole discussion to debian-legal now. > > No. debian-legal is the place for license nit-picking, which isn't what > this discussion is about. The main discussion is about applications/libs where the sourcecode itself is free in the manner of the DFSG, but it is only useable with non-free services and something like that, like a software for buying music online. It is about moving such apps to contrib, because it is free, but "depends" on non-free content, which is a DFSG question and so on stuff for debian-legal, or I am wrong? - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrWVNgACgkQ2XA5inpabMcqkwCfQ09A896+d0iPMITGJU3Vch+J dx8AnA/XBH0TPRJrimxo53bPYau3GeNz =IW/o -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#551275: ITP: lazr.restfulclient -- client for lazr.restful-based web services
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan Yu schrieb:
> Yep, that's what I meant by 'version part' -- though not part of the
> actual package version, it does refer to a series (apache2.0 vs
> apache2.2 for example) of packages. This, I consider to be distinct
> from other packages like the Python ones.
>
> Is this a Python-specific phenomenon, or do other packages in Debian
> exhibit the same patterns?
All the ${programm}.app packages (56 packages) like:
adun.app
camaelon.app
cynthiune.app
easydiff.app
edenmath.app
gnumail.app-dbg
gnuwash.app
gomoku.app
gorm.app
gtamsanalyzer.app
helpviewer.app
lusernet.app
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkrY7W8ACgkQ2XA5inpabMff+gCeM4AJWCHw2yuxFixLbvnNg23u
giEAnj+jkhDIXQfin6QXBEuVGZuwYmWC
=sV2k
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554717: ITP: torsocks -- use socks-friendly applications with Tor
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: torsocks Version : 1.0-gamma Upstream Author : Robert Hogan * URL : http://code.google.com/p/torsocks/ * License : GPLv2+ Programming Lang: C Description : use socks-friendly applications with Tor Torsocks allows you to use most socks-friendly applications in a safe way with Tor. It ensures that DNS requests are handled safely and explicitly rejects UDP traffic from the application you're using. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Using a perl lib from postinst
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tollef Fog Heen schrieb: > ]] Dominique Dumont > > | Since the postinst is a shell script, you cannot call directly the > | perl lib. > > Postinsts can be written in any language, including perl, so he could > just write it in perl and use the relevant module. > Yep and what is with: #!/bin/sh # some foo to be inserted here perl -e -MMy::Module 'My::Module->do_something_nasty();' - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkr9r3cACgkQ2XA5inpabMfA3wCgjML8iAbYj5vo4fZtElLr9zYc pukAnjFCDQITemD1CkkYOiO9efllXte8 =NOTC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian means 'closer to Windows'?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marek Artur Penther schrieb: > When Debian started to mean 'closer to windows'? > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, > and not Debian. And now it's changed? > And this new minimal requirments making my computer completly obsolete? > It's madness! > Even Windows 7 don't making my computer completly obsolete, and Debian 6.0 > making it. > I can't understand. Do you want to better then Microsoft? > So why you cutting me from our community? > > P.S. I wanted to start donating Debian, but now I'll rather start donating > thing which I hate from bottom of heart - Microsoft! > Why you doing this to me and others? First at all: Why are you trying to forcing us (the mailinglist readers) to send you a reading notification? This is realy bad.. Disable it. To your post: Who said that we try to mess ourself with Windows or that we want to be closer to Windows? It is Linux, not Windows. Also I do not understand your requirements, do you have got references? And "who" is "cutting" you from the community? Sorry but your post seems to be a little trolling like.. If you are happy with Windows, use it, if not, use another system with that you are happy. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksAODAACgkQ2XA5inpabMcuagCfSSFjczcZD6OpkGhMT97fIcC7 +rMAoIIu8+/kJh+7OMvAgRVonBl34pmM =zwn6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Anjal package needs RPATH, which is considered an error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Li, Yan schrieb: > Mike: >> Why not put a lintian override ? Your explanation sounds like a good >> reason to me. > > Thank you. I'm contacting Lintian maintainers. You have to set and install your own lintian overrides in your package in the .lintian-overrides file. See e.g. man 1 dh_lintian - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksGZDoACgkQ2XA5inpabMf1IwCeI+7Hdog6QCH4THsoI6jj87r7 L6UAn0rhwplhAcHXbs7W1iA/E4gzglNz =06oT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux image packages going to depend on python
Am 28.11.2009 18:52, schrieb Bastian Blank: Hi folks The Linux image packages needs to do some modifications to core configuration files like fstab in the future to allow newer kernels to work. To do this and the planned further extension I intend to make all linux image packages depend on python. The python package is already part of the standard system via the priority, so for most people this will not make any difference. However there was concerns about the size from the embedded people, so I consider to restrict that to python-minimal. Hi, if the embedded people may have problems with it, would it be an option to rewrite the code (whatever it does) in Perl? I may help out there.. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Key signing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolas schrieb: > Hi all, > > I search for a Debian Member to sign my gpg key. > I work in Paris. I live in Seine-et-Marne (77). > > Thanks in advance. > > Nicolas Have you already looked here [0]? [0]: https://nm.debian.org/gpg_offer.php - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksevnAACgkQ2XA5inpabMfF7ACeJxhqpCpci7V4uOAmiieHFx9H wiAAn3DS4f3TYd6NCMGEejm+54I2oMrP =NrYy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Inactive maintainer (package: libguichan0)
Hello everyone, I have got a problem with the following maintainer: FERREIRA Yohann <[EMAIL PROTECTED]> He is the offical maintainer of the libguichan0 (and libguichan0-dev) package but he seems to be inactive. I asked him for a few weeks, if he could upload libguichan0 in version 0.6.1 to Debian Sid (because my tmw / tmw-music package depends on it), but he refered me to another person. Here is the original email (his answer is the part at the top): Hi, You can ask Mickael Koch for that. Michael Koch <[EMAIL PROTECTED]> Have a nice day. > > Hi Bertram, > > > > I would ask you if you would upload libguichan0 0.6.1 to Debian > > unstable, so that my tmw package can enter Debian Sid (it's now in > > experimental). > > > > Regards, > > Patrick Matthäi So I asked Michael Koch (his package sponsor) and he has written: Hello Yohann, You need to prepare a new new upload which I can sponsor. I cannot just move packages from experimental to unstable. When its done please send me the URL to the *.dsc file and I can upload it. Cheers, Michael Now I have complained an offical report at the dbd about it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421859 But without any answer. I hope someone could solve this problem and if the maintainer will still be unavailable for his package, I would be ready to be the new maintainer of the libguichan0 package. Regards, Patrick Matthäi <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FHS and /var/www
Carl Fürstenberg schrieb: > FHS 2.3 specifies in > http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM > to use /srv for "Data for services provided by this system", for > example /srv/www for web root. > In the policy, the section > 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1) > specifies that FHS 2.3 is mandatory, except for some exception, and > the use of /var/www isn't included in that list. > > Should we force all httpd:s to use /srv/www instead of /var/www, or > should an exception to the policy be added? Per > http://wiki.debian.org/Apache2LennyGoals it states that apache2 has > support for /srv/www, but it's still defaulting to /var/www. > Hello, I fully agree with you, but there are some problems. 1) lintian states that packagers should add a regular httpd config file which should work on most http-daemons - this is in my opinion garbage and not user friendly. 2) lintian also states (yes against lintian) that the packagers shouldn't point symlinks or anything like that in / from /var/www/ but they should add instructions (in README.Debian) for the administator how he could set up his web application, this is also not very user friendly.. Yes the FHS says, that such data has to be places in /srv/ so what have we to do? We should NOT go the user unfriendly way and place at every webapp-package some README.Debian files, we should migrate after lenny from /var/www to /srv/www - I think it will solve the issue with less user problems. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: [EMAIL PROTECTED] Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: can buildd logs be sorted (again)?
Steve M. Robbins schrieb: > Hi, > > The buildd log pages, e.g. [1], used to be sorted by package version > (or maybe build date). However that is no longer the case. > > Can this be fixed? The current situation is less than useful since > the latest build is buried in other output. You should report a bug against qa.debian.org / www.debian.org. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: [EMAIL PROTECTED] Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [s...@powerlinux.fr: Re: Results for General Resolution: Lenny and resolving DFSG violations]
> I think the problem is not really the social contract, what it currently > says is just fine, and we all agree with it. ACK. > We have free stuff, which is in main, and non-free stuff of diverse > variety, which is in non-free (plus the hybrid contrib). > > My own guess is that all those clamoring to have non-free firmware and > non-free documentation or images or whatever in main, would be just as > satisfied if we decided to support non-free more (and maybe put choice > non-free stuff on our CD medias). I also agree in parts with you. There was already somewhere a discussion about, my opinion is, that it would be good to have e.g. an additional non-free netinstaller medium, which includes non-free parts like bnx2 firmwares, some non-free drivers which are necessary to run this machine and to get a connectivity (so on also WLAN blobs). e.g. we have some servers with those bnx2 (aka brotcom netextreme II) cards, with the netinstaller we can not get a connectivity to the network, remote installations are so on for the a... :) > > I believe this will satisfy everyeone, there will be no loss of > freeness over what we have now (we distribute this non-free stuff from > our ftp/http servers, which is just another distribution media compared > to CDs), while it allows for transparent installation of those non-free > drivers, and thus those wanting to be able to install on > non-free-firmware needing hardware should be happy too. The point is (except from some realy crazy licenses) that the most ppl in Debian (I am counting myself to this group) do not want to support non-free stuff, which is also an enforcement for the vendor/programmer to switch to a free solution. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: patrick.matth...@web.de Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: percentage of popcon submitters
Michael Goetze schrieb: > Hi, > >> I know it is not possible to _know_ the real percentage of uses which >> submit popcon stats of all users. But I want to ask for guesses, >> because more oppinions do likely improve the result. >> >> My current guess is between 1/3 and 2/3. >> >> What do you think? > > before wild speculations ensues, you might want to specify what you > really want to know: the percentage of people installing debian systems > who use popcon (always/sometimes), or the percentage of installed > machines that submit popcon data? > > For example, I'm pretty sure any hosting company offering Debian on > dedicated servers will disable popcon by default... > Hello, for myself I deactivated popcon on every machine. Then I first installed and activated it on every server and some times later also on my desktop. For my case I do not think that it will be realy deactivated on dedicated servers in most cases. But yeah, it may differ from person to person :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi E-Mail: patrick.matth...@web.de Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Missing libstdc++5 for 3rd party software
On 12.02.2010 14:09, Goswin von Brederlow wrote: Hi, I just noticed that icc (intel C/C++ compiler) will no longer work in Squeeze because lbstdc++5 (from gcc-3.3) was removed. Same goes for Civ CTP or Heroes and probably a lot of other old games and 3rd party software in general. Is there any chance of getting libstdc++5 back in oldlibs? Same problem with packages from HP for Proliant servers (like firmware updates and hpacucli for maintaing HP SmartArrays). We everytime have to install it from etch :/ -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Missing libstdc++5 for 3rd party software
On 12.02.2010 14:33, Patrick Matthäi wrote: On 12.02.2010 14:09, Goswin von Brederlow wrote: Hi, I just noticed that icc (intel C/C++ compiler) will no longer work in Squeeze because lbstdc++5 (from gcc-3.3) was removed. Same goes for Civ CTP or Heroes and probably a lot of other old games and 3rd party software in general. Is there any chance of getting libstdc++5 back in oldlibs? Same problem with packages from HP for Proliant servers (like firmware updates and hpacucli for maintaing HP SmartArrays). We everytime have to install it from etch :/ Oh sorry, libstdc++2.10-glibc2.2 was the package I mean :/ -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570980: teasers
On 27.02.2010 11:56, Tollef Fog Heen wrote: ]] | Well just like many of the comments to 348864, I just hate the | "teasers" in section 1 that only root can run. Whether a tool is root-only or not is orthogonal to whether it's in bin or sbin. (ifconfig is useful for non-root users, but is in sbin. chown is effectively root-only, but is in bin.) Why is chown useless for users? m...@exez:~$ touch test m...@exez:~$ ls -l test -rw-r--r-- 1 me me 0 27. Feb 12:06 test m...@exez:~$ chown :audio test m...@exez:~$ ls -l test -rw-r--r-- 1 me audio 0 27. Feb 12:06 test -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4b88fcf3.7080...@debian.org
Re: including full package source code in the debian release
On 07.03.2010 04:29, Jamie Morken wrote: Hi, Debian releases have 25,000 or so packages and don't include the source to them, so to recompile the package you use apt-get to connect to the internet and download the source to one package at a time if you want the source code. I did some calculations to see how much bulk adding the package source code to the debian release would add and using high compression it appears that it would increase the overall release size by less than 1%. Most users won't care or benefit from having the source code to these 25,000 packages included in the distribution, but some will probably like the ability to be able to have this source code and be able to recompile packages without requiring internet access to download package source code. Here are my calculations, they are rough estimates: packages included in Debian 4.0 /etch/ (283 million lines of code) source: http://en.wikipedia.org/wiki/Debian assuming 32KB per 1000 lines of code, this would be about 8.6GB for 283 million lines of code. assuming a factor of 100 for the compression of this code, this would give approx 88MB of extra space required in the debian distribution for all of this source code. You completly forget, that most of the space of the sourcecode are != programming code, so they are images etc, which are much bigger and also a part of the source code. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4b9374f2.70...@debian.org
Re: Debian Package
Am 09.03.2010 18:52, schrieb Jake: Hello, I was creating a Debian package and after it install I would like it to prompt the user to reboot the computer, is there anyway to do this? The right way here is to use debconf for it. But why should it be needed to reboot the computer after this? I am feeling myself remembered to windows systems >.< -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4b968fe3.4040...@debian.org
Bug#574895: ITP: muroard -- minimalist RoarAudio sound daemon
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: muroard Version : 0.1~beta0 Upstream Author : Philipp 'ph3-der-loewe' Schafft * URL : http://roaraudio.keep-cool.org/ * License : GPL-3+ Programming Lang: C Description : minimalist RoarAudio sound daemon RoarAudio is a sound-server for audio mixing. Its main purpose is to mix audio from different clients before sending it to its outputs (for example a soundcard). -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20100321224443.17270.56494.report...@srv1.linux-dev.org
Re: Handling optimization flags in Debian packages
On 04.04.2010 22:29, Tiago Bortoletto Vaz wrote:
Hi all,
I've faced an issue (#557550) which is much probably caused by a CPU which
doesn't support SSE2 instructions. I'm not sure about the best way to address
this. Any suggestion will be very welcome. Actually I can see the following
workarounds:
1) consider that most of CPUs support this flag, so tell the reporter to
compile the package by him/herself.
Quite bad.
2) remove this specific flag during package building, ending with a
non-optimized software available for all users.
3) create a specific -sse2 (or -non-sse2) package.
Sounds like too much work.
4) ask the upstream to code runtime checks before using SSE2 specific
instructions (is that possible?).
AFAIK it is possible.
For now, my choice is #1.
This is a bad decision.
The only architecture where you can assume, that all CPUs support MMX
and SSE{2} is amd64. So you can enable the optimizing flags only on this
arch.
I am also handling it this way in my packages.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
--
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/4bb90113.2080...@debian.org
Re: Possible boot ordering issues with the packages in Sid
Am 23.05.2010 20:25, schrieb Petter Reinholdtsen: Every day, I run a archive wide consistency check of all the init.d scripts in Debian. It detect dependencies on non-existing facilities, duplicate provides and other problems. Here is the complete list from today, also available fromhttp://lintian.debian.org/~pere/>. There are quite a few false positive here. For example the missing $remote_fs check look for /usr/s?bin in the script, and will report a missing dependency also for scripts not using files in /usr/. The missing $syslog check look for a syslog symbol being mentioned in some binary in the package, and do not really know if the binary is started at boot. Anyway, sharing this with you all, in the hope that some of you might be motivated to review your packages init.d scripts to increase the quality of the init.d script dependencies. Please help me reduce the number of init.d script dependency issues. Most of these issues are not reported to BTS, as it require time to verify that the reported issue is a real problem, and I have not had time to do that for most of these packages. I know it would be better to order the list by maintainer, but have not found a simple way to do that with the format I have available. Thanks for the list, but wouldn't it be better to submit bugreports? :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4bf97797.5030...@debian.org
Re: Bindv6only once again
Am 15.06.2010 23:18, schrieb George Danchev:
Jarek Kamiński writes:
Na grupie linux.debian.devel napisałe(a)ś:
I see only two ways of fixing proprietary Java (apart from fixing it
upstream or ignoring the problem):
* wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in
Debian package)
or
* allow sun-java6-* packages to override bindv6only sysctl.
* allow bindv6only to be overridden by process instead of system-wide.
You mean modifying kernel?
Of course not, the kernel already provides everything needed for years, and
these dummy apps can still request bindv6only to 0 on the sockets they listen
on their own, which is also discussed at debian-ctte[1]:
int b = 0;
if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&b, sizeof(b))==-1)
perror("failed blah");
they would be still inferior to those opening two separate sockets (which
means more fine-grained control like listening on v4 or v6 or both, or
establish means to threat them specifically if necessary), but this is at least
easily doable for brain-damaged apps badly in need for 0.
You have forget, that most apps, which does not work with = 1, are
non-free and mostly completly closed-source.
Yeah we could follow this way and say "f*** on non-free SW", but many
companies, which are using Debian, are also hosting non-free software on
it (we also do it); and it just breaks with this value.
What would our CEO say? "It is not working with Debian, but with every
other distro? Then install distro XYZ!"
I don't think, that this is a good idea :<
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
--
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/4c17f1a0.9070...@debian.org
Re: How to warn about need to port changes to new configuration file?
Am 18.06.2010 18:10, schrieb Michael Biebl: On 18.06.2010 17:15, James Vega wrote: On Fri, Jun 18, 2010 at 10:46 AM, Michael Biebl wrote: I assume the file in question is a conffile. If you just want to move its location, read the section "Moving a conffile" at http://wiki.debian.org/DpkgConffileHandling dpkg-maintscript-helper was introduced in dpkg 1.15.7.2 to provide a standard implementation of actions like this. This means though, your package needs to add a versioned depends on dpkg, which imho is not so nice. Much better as different solutions from different maintainers which will cause different bugs :< -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4c1b9d54.9030...@debian.org
Re: "Waqf" General Public License in Debian?
Am 02.07.2010 00:21, schrieb Christoph Anton Mitterer: > > 4) The license is extremely anti-American, and I guess also > anti-European/anti-Western. IMHO I think it does not comply with the DFSG, but it is still in NEW and I trust the ftp-masters, that it will be rejected. I don't see a reason to post it to d...@l.d.o at the current time.. > > > This may sound anti-Islamic, but it is not. In my opinion, we should > just keep Debian clean of any religious stuff, or software related to > similar problematic areas, especially if they have such a questionable > "license". I don't see any problem with it (okay there are people who think it may be a problem etc etc etc..). There are also groups of people, which see porn as quite problematic at all, but we have got pornviewer e.g.. The software does not discrimate anyone, so why should we care about it? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: "Waqf" General Public License in Debian?
Am 02.07.2010 00:45, schrieb Russell Coker: > On Fri, 2 Jul 2010, Christoph Anton Mitterer wrote: >> 3) The license contains many places which can be considered >> discriminatory, racist or fundamentalist. >> Apart from that... religious stuff shouldn't go into a license. > > http://www.ojuba.org/wiki/waqf/license > > The above URL has the license. I think that the concepts in the preamble are > interesting, offering software to please Allah and denying the concept of > "ownership" of Intellectual Property. Which is not only non-free in Debian, we can not distribute it. A software license is not allowed to force other users to please any "god". I think we all agree with this point, so please don't start a religious discussion now on this list.. > Also as we don't discriminate against fields of endeavor the "good purpose" > part wouldn't be acceptable even if it could be clearly defined and agreed. > If Stormfront, Al Quaeda, or Right to Life want to use Debian then as a > matter > of principle we should let them do so - but of course the members of such > organisations think that they have a "good purpose" so it probably doesn't > matter much. > ACK. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: "Waqf" General Public License in Debian?
Am 02.07.2010 08:57, schrieb Joerg Jaspert: >>> The above URL has the license. I think that the concepts in the preamble >>> are >>> interesting, offering software to please Allah and denying the concept of >>> "ownership" of Intellectual Property. >> Which is not only non-free in Debian, we can not distribute it. >> A software license is not allowed to force other users to please any "god". > > Yes, we can very well distribute a software in non-free that requires > the user to do whatever funny thing the license author wants from him. > It is the users problem in non-free if they can follow that or > not. Debian does only require the distribution rights, and I do not see > how they are affected in such a thing. How much sense it makes and what > I personally think of license authors (hint: nothing good at all, DO NOT > WRITE ANY NEW LICENSE, DAMNIT), is something else. > Okay thanks for the correctur :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Bug#587968: ITP: roaraudio -- sound server for audio mixing
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: roaraudio Version : 0.3~beta7 Upstream Author : Philipp Schafft * URL : http://roaraudio.keep-cool.org * License : GPL, LGPL Programming Lang: C Description : sound server for audio mixing RoarAudio is a server for audio mixing. Its main purpose is to mix audio from different clients before sending it to its outputs (for example a soundcard). It is completely network transparent (UNIX sockets, TCP/IP, DECnet) and supports many common codecs like Ogg Vorbis, Speex or FLAC. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20100703113106.15483.91154.report...@srv1.linux-dev.org
Bug#588361: RFH: fglrx-driver -- non-free AMD/ATI r6xx - r7xx display driver
Package: wnpp Severity: normal I request assistance with maintaining the fglrx-driver package. The package description is: Display driver for the ATI recent Radeon and FireGL graphics cards. . This package provides 2D display drivers and hardware accelerated OpenGL for X.Org version 7.1. For 3D acceleration to work, you will need to compile the fglrx kernel module for your kernel: see the fglrx-source package. Note that the driver will work without the kernel module, but 3D acceleration will be disabled. . The driver can work with plain mesa libGL, but some applications may require the proprietary libGL. This library is shipped in the fglrx-glx package. . This driver is not free. As an alternative, you may try the newest free driver xserver-xorg-video-radeonhd. . This driver will replace parts of your X11 and Mesa system. My further TODO in the team: - Better dkms integration - Forwarding and solving of bugs (if possible) - Better documentation of well known bugs and their workarounds -- 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/20100707180438.27259.88042.report...@localhost
Bug#588363: RFH: otrs2
Package: wnpp Severity: normal Hello, I need some help with the otrs package. Currently, I am the only maintainer of it. The package itself is in a good shape, except of bug #511080 What I need: An enthusiastic maintainer, who is also using otrs, who has got basic skills in Perl in databases (the best would be to have got a postgres pro, because I am MySQL'ish). Further TODO: - Packaging the upcoming otrs3 package from scratch - Packaging of popular extensions? and so on.. I am maintaing the package in svn. Cheers. -- 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/20100707180301.27228.16646.report...@localhost
Re: The number of popcon.debian.org-submissions is falling
Am 20.07.2010 23:18, schrieb Holger Levsen: Hi, On Dienstag, 20. Juli 2010, Bernhard R. Link wrote: I think there should be a popcon mode where it only reports the installed packages. and it should be the default. Maybe the default value at d-i for popcon should be set to true (report popcon statistics). atm it is false. Yes I know, that many people (I am including myself in general) think, that we may abuse the data privacy with this default value, but.. 1) if $user read the message, he still could decide to deactivate it 2) with `installed packages only' I think no privacy data will be submitted 3) we get more popcon data, which helps Debian and his users -- 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/4c461475.8080...@debian.org
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
> This should probably then move to Debian-Project? > > On 07/21/2010 11:31 AM, Andreas Tille wrote: >> On Wed, Jul 21, 2010 at 05:34:27PM +0900, Charles Plessy wrote: >> >> >>> I think that what we need is Debian Blends that include official >>> backports. >>> This, no other distribution proposes yet. >>> >> IMHO this is worth another thread how to make Debian more attractive for >> users ... >> > The computing world have become such complex, that we are all mere users > somewhere. So yes, we should think more about our users. > > * I know a few who love lenny with backports, so yet, we should somehow > integrate that with the blends concept. Could there be a flag in > debian/control in some way for anything with a compatible debhelper > version to be auto-backported? > > * Metaphorical speaking: we should give Debian a phone number. And I > mean full-time or at least half-time employees. With so many people > unemployed these days, I even feel we have the duty to think about > creating jobs. Or a better idea: * Provide semi-official images with non-free enabled (on cdimage.debian.org) of our releases. This is one big reason, why users decide to use Ubuntu instead of Debian. -- 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/02905573d5290737d21b0f6fe761d612.squir...@www.linux-dev.org
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Am 21.07.2010 23:04, schrieb Ron Johnson: > On 07/21/2010 06:50 AM, Patrick Matthäi wrote: > [snip] >> >> Or a better idea: >> >> * Provide semi-official images with non-free enabled (on >> cdimage.debian.org) of our releases. This is one big reason, why users >> decide to use Ubuntu instead of Debian. >> > > That's why I installed Ubuntu on my wife/kids' PC: the stuff they care > about (no-fuss audio and video on an old PC) Just Work on Ubuntu but > were a struggle on Sid. > Thanks. I think with our next release, we will have got less users. Why? We stripped out all binary only firmware images from Linux and put them mostly into the non-free linux-firmware image. What is the consense? I can not install any newer Desktop PC, Notebook and now ALSO HP Proliant servers (current generations) without activating non-free manualy, which eats time. No PXE boot, automagic installed updates after netinstall etc... Don't understand me wrong, I am completly happy with our DFSG, we should follow this way, but I also think we should provide images with non-free enabled to allow a simple and fast installation of Debian for our Desktop and Business users. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: Bug#594672: ITP: dhcpcd5 -- a DHCP client
Am 28.08.2010 10:35, schrieb Roy Marples: Package: wnpp Severity: wishlist Owner: Roy Marples * Package name: dhcpcd5 Version : 5.2.7 Upstream Author : Roy Marples * URL : http://roy.marples.name/projects/dhcpcd * License : BSD-2 Programming Lang: C, Shell Description : dhcpcd5 - a DHCP client dhcpcd is a one stop IPv4 network management daemon which includes It only supports IPv6? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4c78d4b7.2000...@debian.org
Re: Bug#594672: ITP: dhcpcd5 -- a DHCP client
Am 28.08.2010 12:11, schrieb Roy Marples: dhcpcd is a one stop IPv4 network management daemon which includes It only supports IPv6? Only IPv4 at present. IPv6 support, at least for RA is planned for the next major version, possibly with support for the experimental RFC5006 (DNS in IPv6 RA). Whops, s/IPv6/IPv4/ in my message, please. :) IMHO it shouldn't uploaded to Debian, without missing IPv6 support. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4c78e5f6.6090...@debian.org
Bug#594808: ITP: xvba-video -- XvBA-based backend for VA API
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: xvba-video Version : 0.7.3 Upstream Author : Gwenole Beauchesne * URL : http://www.splitted-desktop.com/~gbeauchesne/ * License : non-free/prop. Programming Lang: something which is compileable ;) Description : XvBA-based backend for VA API Video decode driver for ATI/AMD chipsets (XvBA implementation). . This VA driver provides GPU video decoding for ATI/AMD chipsets. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20100829173047.10853.89925.report...@srv1.linux-dev.org
Re: Bug#594808: ITP: xvba-video -- XvBA-based backend for VA API
Am 29.08.2010 21:06, schrieb Julien Cristau: Video decode driver for ATI/AMD chipsets (XvBA implementation). . This VA driver provides GPU video decoding for ATI/AMD chipsets. The package name should somehow include fglrx, IMO. Already uploaded to NEW. xvba-video is the right source package name, the binary package is named xvba-va-driver (same way as the nvidia VA driver: vdpau-va-driver). The package description already mentions, that it is ATI/AMD specific. Users who want to activate this feature also know, that the AMD implementation of VA is named xvba :) I don't see any problems with that name. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- 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/4c7ab147.6040...@debian.org
Re: why experimental latest Release file hasn't NotAutomatic: yes
Am 19.09.2010 17:17, schrieb Jérémy Lal: > Suddenly apt wants to upgrade packages to experimental ! > ftp://ftp.debian.org/debian/dists/experimental/Release Hu? m...@gnu:~$ wget -q ftp://ftp.debian.org/debian/dists/experimental/Release -O /dev/stdout|grep ^NotAutomatic: NotAutomatic: yes m...@gnu:~$ Maybe you have got mis'pinned? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: Web host question
Am 26.10.2010 21:56, schrieb Patrick Ouellette: Anyone use micfo.com? Thoughts? Thanks, Pat How is this related to debian-devel? -- 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/4cc74634.1070...@debian.org
Re: debian can be better
Am 27.10.2010 23:32, schrieb Russell Coker: > On Wed, 27 Oct 2010, Pedro Paulo Argolo wrote: >> needs better support video cards from Nvidia and ATI video boards >> Intel. I had configuration problems because of that, and for a typical >> user is a very embarrassing situation. ~: ( > > The change from "nv" to "nouveau" was a good improvement for my main system > (Thinkpad T61), 2D graphics performance improved noticeably although I do > occasionally get transient corrupted bitmaps. Debian is dedicated to free > software (which precludes the non-free NVidia driver from being in main) and > I > don't want the security risk of running binary-only software on my important > systems. Most desktop users also want to have some 2D/3D performance, or special features like tv out, xvideo acceleration etc etc. nouveau is a good replacement for nv, but still far away of being useful for powerful desktop users. On the ATI/AMD side, the free radeon driver does a quite good job, but since it uses KMS you have to disable KMS to get some performance (radeon+KMS = quite slow) The security side: Sure, security issues could be "easily" fixed with open drivers, but if I remember right, the only security issue with a closed-source prop. X11 video driver was 2-3 years ago with the nvidia one. And if there are some new sec. issues, you can still switch. > > I am not aware of anything that stops a Debian user from using a binary-only > Xorg driver. Not supported by us, officialy, they are also not on our installation cds (users have to activate non-free by themselve). > > Intel video cards work really well in my experience, performance is great > including on 3D graphics with games such as Warzone 2100, Super Tux Carts, > and > Tux Racer. Given a choice I'd just buy a system with Intel graphics. It may be great with such "historic" games, but don't try to play modern games with intel HW ;) > >> In this case I think >> Debian should look a little closer to Ubuntu, referring to usability. >> You can maintain a perfectly usable OS for both beginners and advanced >> users of Linux technology, without changing the philosophy course >> Debian. > > Ubuntu aren't as much into free software. ACK. > > Speaking for myself I'm more than happy for people who want Debian with non- > free software to use Ubuntu. I think that they are doing a great job of > making a Debian-derived distribution that supports non-free software and is > easy to use. I do not agree with you at all, but mostly because of some "religion" reasons :p Anyway for squeeze there will be (if nothing have been changed again) an image with some non-free enabled (like firmware foo). -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: debian can be better
Am 28.10.2010 00:05, schrieb Vincent Bernat: > OoO La nuit ayant déjà recouvert d'encre ce jour du mercredi 27 octobre > 2010, vers 23:48, Patrick Matthäi disait : > >> Most desktop users also want to have some 2D/3D performance, or special >> features like tv out, xvideo acceleration etc etc. >> nouveau is a good replacement for nv, but still far away of being useful >> for powerful desktop users. > > nouveau supports 2D acceleration including compositing and Xvideo > acceleration. I don't see what may be missing for everyday desktop > use. It is even better than the nvidia driver because of its perfect > support of xrandr. I am not nvidia'ish, but supporting 2D/3D acceleration is a *must have* in my eyes since many years. The performance of nouveau just sucks. Yeah if you do not need it, okay.. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: Bug#603699: ITP: celt051 -- The CELT codec v0.5.1
Am 16.11.2010 16:09, schrieb Liang Guo: celt is already packaged: http://packages.debian.org/search?keywords=celt Different version CELT is not compatiable, it means, if audio is encoded with celt 0.5, it is not possible to decode it with celt 0.9, and spice[1] uses celt 0.5.1, if we want use spice in Debian, we need package celt051 for it. Marc-André Lureau had ported spice to use the latest celt , but it is not suitable for upstream, for the spice client and the server use different different bitstream format. BTW: fedora have two different version celt[3] [1] http://www.spice-space.org/ [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560721 [3] https://admin.fedoraproject.org/pkgdb/acls/list/*celt**?_csrf_token=537e3e3d62864407b17cb114113258d54f249410 Thanks, Yeah I am aware of the celt _madness_ - I am one of the mumble maintainers.. spice then has to be adjusted to support celt 0.9. -- 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/4ce29e52.50...@debian.org
Re: Bug#603699: ITP: celt051 -- The CELT codec v0.5.1
Am 16.11.2010 16:43, schrieb Marc-André Lureau: Hi Patrick, On Tue, Nov 16, 2010 at 4:08 PM, Patrick Matthäi wrote: Am 16.11.2010 16:09, schrieb Liang Guo: Marc-André Lureau had ported spice to use the latest celt , but it is not suitable for upstream, for the spice client and the server use different different bitstream format. BTW: fedora have two different version celt[3] Yeah I am aware of the celt _madness_ - I am one of the mumble maintainers.. spice then has to be adjusted to support celt 0.9. Then we will be incompatible with upstream. Upstream has decided to stick to 0.5.x. This means that all the people using SPICE today are using this version. Do we really want to be incompatible with others distros and custom builds? I think we should be reasonable, since Fedora and RHEL already decided to stick to 0.5.x, that means they are going to maintain it as well. What really prevent us from making it available in Debian? One day, perhaps if the reasons are good enough, spice upstream will decide to use a higher version of the bitstream. But right now, there is no frozen bitstream, and it would be crazy to just take arbitrarily another version, they did it once, it's enough. Please correct me if I am missing something here. I think at all (before submitting this ITP) you should talk about this with the celt package maintainer of Debian. -- 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/4ce2a767.4000...@debian.org
Re: Bug#603699: ITP: celt051 -- The CELT codec v0.5.1
Am 16.11.2010 15:15, schrieb liang: Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: celt051 Version: 0.5.1.3 Upstream Author: Christopher Montgomery, Jean-Marc Valin Timothy Terriberry, CSIRO, and other contributors URL: http://www.celt-codec.org/ License: BSD Description: The CELT codec version 0.5.1 CELT is an experimental audio codec for use in low-delay communication. Its potential uses include video-conferencing and network music performance. This is a maintained branch of the 0.5.1 prerelease of CELT, it is not compatiable with any previous or subseqent numbered release. . This package is specially used by spice, you may install celt for NORMAL USE. celt is already packaged: http://packages.debian.org/search?keywords=celt -- 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/4ce2977a.4040...@debian.org
Bug#610470: ITP: geoip-database -- IP lookup command line tools that use the GeoIP library (country database)
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: geoip-database Version : 20110118 Upstream Author : Patrick Matthäi * URL : http://www.maxmind.org/ * License : BSD like Programming Lang: CSV Description : IP lookup command line tools that use the GeoIP library (country database) Split up of the geoip package, have a look at the current geoip-database package. -- 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/20110118210332.2153.75946.reportbug@localhost
Bug#611752: ITP: mana -- mana is a 2D MMORPG
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: mana Version : 0.5 * URL : http://www.manasource.org/ * License : GPL, BSD Programming Lang: C++ Description : mana is a 2D MMORPG The Mana client is developed as part of The Mana Project, which aims to build a complete 2D MMORPG platform. This includes a client, server and web component, as well as a library of free content that you can use under the terms of the GPL. . This version of the client can connect to a specific version of the eAthena server known as tmwAthena, a version with adaptations made as part of The Mana World project. -- 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/20110201194303.24746.83858.reportbug@localhost
The future of m-a and dkms
Hello folk, since we have got a stable release with dkms now, I am asking myself, if it is still necessary to support module-assistant. dkms is IMHO the better system and maintaining two different systems for kernel modules is a bit bloated. I think there should be a decission for wheezy, how we should continue with it. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: The future of m-a and dkms
Am 13.02.2011 23:39, schrieb Cyril Brulebois: > That said, I'm no longer interested in maintaining m-a (lack of time > is one thing, lack of interest is another, “upstream first” yet > another). Putting my fglrx maintainer hat on, I am also no longer interested in supporting m-a, putting my server administrator job hat on, I am happy that we have got dkms now. dkms is more widley use (especially by commercial software products) and so on we could reach a widley user- and developer-base. I think it would be a nice release goal for wheezy, to get rid of m-a and to migrate all related packages to dkms. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: Should pam_unix log non-interactive sessions? [c...@taz.net.au: Bug#612382: pam, non-interactive-sessions, and pam_unix spamming the auth log]
Am 13.02.2011 23:45, schrieb Steve Langasek:
> Hi folks,
>
> I have a bug report objecting to pam_unix logging all PAM sessions,
> interactive and non-interactive alike, to syslog. Should pam_unix be
> dropped from /etc/pam.d/common-session-noninteractive? It's only after
> pam-auth-update started being used and common-session-noninteractive is
> split out that anyone mentioned this might be a problem; before that I
> assumed that having pam_unix log the session was the right thing to do.
>
> Any other arguments for/against this logging?
>
> On my systems, this affects atd, cron, and samba; conceptually it should
> also apply to services like imap, pop and ppp, but in practice these
> services haven't switched over to common-session-noninteractive at all yet.
> Any change to the pam_unix profile now would impact those services later, so
> if people expect syslogging of those sessions via pam_unix, we should
> determine that now.
>
*We* need those logging on our machines per default and I don't think,
that we are the only one. Non-interactive sessions should still be logged.
Personaly I would wish, that I can see in auth.log, if it is
{non-}interactive or not, but that is not the topic of this thread.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
signature.asc
Description: OpenPGP digital signature
Re: The future of m-a and dkms
Am 13.02.2011 23:52, schrieb Christoph Anton Mitterer: > On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote: >> since we have got a stable release with dkms now, I am asking myself, if >> it is still necessary to support module-assistant. >> dkms is IMHO the better system and maintaining two different systems for >> kernel modules is a bit bloated. > With dkms, can you also create packages of the modules? > > At least I found it always very useful, to create modules with m-a, or > via make-kpkg, and provide them via local archives to all my Debian > boxes. Can save quite some compilation time, and one doesn't need kernel > header + build packages etc. on all nodes. You can still publish ready compiled module on the other nodes and I don't think, that it is necessary to safe this little bit compile time and extra space for the headers, to support m-a in the next releases. Also with dkms this job could be done more automagic (especially with new kernel versions). -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ signature.asc Description: OpenPGP digital signature
Re: The future of m-a and dkms
Am 14.02.2011 00:12, schrieb Iustin Pop:
> On Sun, Feb 13, 2011 at 06:00:10PM -0500, Michael Gilbert wrote:
>> On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote:
>>
>>> On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
>>>> since we have got a stable release with dkms now, I am asking myself, if
>>>> it is still necessary to support module-assistant.
>>>> dkms is IMHO the better system and maintaining two different systems for
>>>> kernel modules is a bit bloated.
>>> With dkms, can you also create packages of the modules?
>>>
>>> At least I found it always very useful, to create modules with m-a, or
>>> via make-kpkg, and provide them via local archives to all my Debian
>>> boxes. Can save quite some compilation time, and one doesn't need kernel
>>> header + build packages etc. on all nodes.
>>
>> Yes, there is the "mkdeb" command-line option, but I suppose that
>> doesn't get as much testing as it should.
>
> With my sysadmin hat on, compilation on servers is a *very* big no-no,
> so if mkdeb doesn't work or if it doesn't provide nice modules, then m-a
> should stay in.
I find it useful, e.g. for several servers, running different kernel
versions.
>
> I know that right now, when backporting stuff at work, we have to drop
> the DKMS stuff and write our own packaging since DKMS doesn't play
> nicely with multiple kernel versions, embedding the kernel *and* package
> version in the final module version, etc. Things might have changed
> recently, but last time I looked DKMS was only good for desktops, and
> not as a reliable package-building method.
>
> Of course, I might have wrong information, so clarifications welcome.
I think the disadvantage of dkms is, that apt will fail, if the module
couldn't be built for one of the "n" installed kernel versions, because
the module is not compatible {anymore} with the kernel version.
This process could be enhanced, by dropping an notify to the user, that
module "x" failed to buit on kernel version "y" and you might found more
information at "z". But you have got the same problems with m-a, just
you don't have to execute m-a by yourself.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
signature.asc
Description: OpenPGP digital signature
Re: The future of m-a and dkms
Am 14.02.2011 17:04, schrieb Marc Haber: On Mon, 14 Feb 2011 14:43:23 +, Ben Hutchings wrote: On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote: Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi: since we have got a stable release with dkms now, I am asking myself, if it is still necessary to support module-assistant. dkms is IMHO the better system and maintaining two different systems for kernel modules is a bit bloated. Well, dkms might be a good system for workstations, but on servers where you want to have reliable systems and security first you do not want dkms ever. DKMS was developed by Dell originally to support servers (as they did not sell any other systems running Linux until recently). We all know which strange ideas hardware vendors have with regard to system administration. This is not true. You can use 'dkms mkdeb' to build module packages elsewhere. That would be an acceptable workaround. Is there any way to prevent dkms from trying to build modules for the currently running kernel when module sources are installed (which is bound to fail in my build chroot)? I don't think so, also the maintainer scripts execute the dkms build, e.g. [0]. But this would be a serious goal for dkms and its implementation in the maintainer scripts. [0]: http://svn.debian.org/wsvn/pkg-fglrx/fglrx-driver/trunk/debian/fglrx-modules-dkms.postinst -- 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/4d59562a.5060...@debian.org
Re: Fwd: paraview_3.8.1-2_amd64.changes REJECTED
Am 24.02.2011 10:26, schrieb Mathieu Malaterre: Dear DDs, A user discover the wrong source for paraview 3.8.1 were pushed to debian repository. To fix this mistake, I asked for the removal of the paraview package to be able to quickly reupload it. This was very quickly executed by ftpteam. However even if paraview has been removed from testing, I can still not push it back. See the error message below. Is there anything I would be missing ? What about uploading 3.8.1+1? -- 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/4d662835.3080...@debian.org
[Fwd: [Pkg-fglrx-devel] Bug#514061: atieventsd and SELinux support]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags #514061 + help
thanks
Hello list,
I am also an SELinux newbie and hope here is someone who knows how to
fix this. :-)
Please keep the BTS in CC, thanks.
- Original-Nachricht
Betreff: [Pkg-fglrx-devel] Bug#514061: Workaround
Weitersenden-Datum: Mon, 09 Feb 2009 17:39:02 +,Mon, 09 Feb 2009
17:39:03 +
Weitersenden-Von: Don Pellegrino
Weitersenden-An: debian-bugs-d...@lists.debian.org
Weitersenden-CC: Fglrx packaging team
Datum: Mon, 09 Feb 2009 12:37:37 -0500
Von: Don Pellegrino
Antwort an: Don Pellegrino , 514...@bugs.debian.org
Organisation: Drexel University
An: 514...@bugs.debian.org
In my original report I mentioned that I couldn't find the error message
with grep. The error is recorded in /var/log/audit/audit.log and I
didn't run grep -r so I initially missed it. The error is:
type=AVC msg=audit(1234196438.214:4): avc: denied { execmem } for
pid=3063 comm="atieventsd" scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=process
type=SYSCALL msg=audit(1234196438.214:4): arch=4003 syscall=192
success=no exit=-13 a0=b7e06000 a1=6000 a2=7 a3=812 items=0 ppid=3061
pid=3063 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="atieventsd"
exe="/usr/sbin/atieventsd" subj=system_u:system_r:initrc_t:s0 key=(null)
Experimentation with my local policy file shows that both execmem and
execstack are needed:
type=AVC msg=audit(1234199603.086:4): avc: denied { execstack } for
pid=3057 comm="atieventsd" scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=process
type=SYSCALL msg=audit(1234199603.086:4): arch=4003 syscall=125
success=no exit=-13 a0=bf81d000 a1=1000 a2=107 a3=f000 items=0
ppid=3055 pid=3057 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="atieventsd"
exe="/usr/sbin/atieventsd" subj=system_u:system_r:initrc_t:s0 key=(null)
The basic work-around is to just assume atieventsd should be given the
security it needs and to add a local policy entry:
module local-ati 1.0.0;
require {
type initrc_t;
class process { execmem execstack };
}
# Workaround for atieventsd
allow initrc_t self:process { execmem execstack };
This policy can be added with the following commands:
# checkmodule -M -m -o local-ati.mod local-ati.te
# semodule_package -o local-ati.pp -m local-ati.mod
# semodule -i ./local-ati.pp
I am a novice SELinux user and I don't believe this is the best
work-around. For one the allow statement appears to cover the entire
initrc_t type rather than the /usr/sbin/atieventsd binary specifically.
Second, I don't know enough to determine if this the proper course of
action. Should a policy update be made or should this go to ATI for a
correction to the atieventsd binary itself so that it doesn't use
execmem or execstack?
Finally, it is curious that /etc/init.d/fglrx-driver start worked to
load atieventsd after boot without any problems. So it seems that
loading the process at boot time gives different behavior.
___
Pkg-fglrx-devel mailing list
pkg-fglrx-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-fglrx-devel
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
E-Mail: patrick.matth...@web.de
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmQa6UACgkQ2XA5inpabMchRACgm/nDQ4k1P3etCkwCVFQZa1bF
eVkAnAycOqp4QKm42mOCvdfmEn4YvA/l
=K/Jc
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529814: ITP: luckybackup -- rsync-based GUI data backup utility
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: luckybackup Version : 0.3 Upstream Author : Loukas Avgeriou * URL : http://luckybackup.sourceforge.net/ * License : (GPL-3 Programming Lang: C++ Description : rsync-based GUI data backup utility luckyBackup is an application that backs-up and/or synchronizes any directories with the power of rsync. Its main features are: backup, safety, synchronization, exclude/only include options, allows custom rsync options, remote connections, restore and dry-run operations, scheduling, profiles and command line mode. . It is simple to use, fast (transfers over only changes made and not all data), safe (keeps your data safe by checking all declared directories before proceeding in any data manipulation ), reliable and fully customizable. . This package contains the arch independent data files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Seeking help with OpenVPN scripts and systemd
Von meinem iPad gesendet > Am 09.09.2014 um 22:26 schrieb Noel Torres : > > On Tuesday, 9 de September de 2014 16:51:20 Alberto Gonzalez Iniesta escribió: >> AltSubject: For those who care about OpenVPN >> >> Dear fellow developers, >> >> This is a cry for help. I've been trying to support systemd in OpenVPN for >> some time, but the results are not satisfactory. I'd like to keep the >> current (SysV) behaviour in systemd but it's becoming quite an annoying >> task. >> >> I'd love to hear recommendations, receive patches or any other help with >> this. Let me explain what the SysV init script did, so you can figure out >> what I'd like to achieve. If you aren't interested in the task you may >> skip the rest of this mail. >> >> What was working? >> - >> >> First of all, openvpn in Debian is able to run several VPN daemons. >> Depending on the value of the configuration variable AUTOSTART (in >> /etc/default/openvpn): - all -> A daemon for each of the configuration >> files found in /etc/openvpn - none -> Do not manage any VPN (they can be >> started manually or through a directive in /etc/network/interfaces >> - A list of the VPNs you want automatically managed (i.e. AUTOSTART="work >> home"). The rest can be managed manually. >> >> In order to be able to control individual VPNs the init.d script accepts a >> second argument (after start/stop/...) with the name of the VPN to manage. >> I know this was a hack, but it worked like a charm. This is no longer >> possible with systemd. >> >> stop, reload, soft-restart and cond-restart will only affect running VPNs. >> The last one is specially important in upgrades, when the currently running >> daemons have to restart. That includes those VPNs that are managed >> automatically (in AUTOSTART) *and* those started manually or through a >> network/interfaces directive. Whereas restart will only affect those >> managed automatically unless a VPN name is specified. >> >> In addition to the init.d script, there are two script in >> /etc/network/if-(up|down).d/openvpn that allow for VPNs to be managed when >> interfaces are brought up or down. So you may have AUTOSTART=none, or >> AUTOSTART="home office", and then enable "work" tunnel when only when using >> a specific network interface. >> >> Where are we now? >> - >> >> The latest version of openvpn's package (in experimental) includes two >> service files for systemd. One instantiated (openvpn@.service) allows the >> control of single VPNs, piece of cake. >> >> The main issue is with the other one, openvpn.service, that tries to >> replace the old init.d script and all its features. It is, currently, >> calling a helper script that (tries to) mimic(s) the former behaviour. >> >> First of all, the script can only be called with start, stop or reload >> arguments. So no distinction can be made between a restart and a >> stop-then-start. So there's no way (i.e. on an upgrade) to restart all >> VPNs (those in AUTOSTART *and* those manually controlled), since "start" >> and "stop" should only manage those in AUTOSTART. >> >> Another problem is the package upgrade to systemd in a running system, >> since the VPNs started with the current init.d script are not recognized >> by openvpn@NAME.service. So when upgrading the package from the >> non-systemd-enabled package (< 2.3.2-7) to the package with the service >> files, we end up with two active VPNs (the one that was running, and one >> started by systemd) for each AUTOSTARTed configuration. >> >> If you know systemd and would like to help with this please Cc: me (since >> I'm not subscribed to -devel) or mail me directly. You may find the >> current git repo for openvpn in Debian at: >> git.debian.org/git/collab-maint/openvpn.git >> >> Thanks, >> >> Alberto > > Hi Alberto > > openvpn package should Conflitcs systemd in order to avoid systemd being > installed and so messing with OpenVPN-working systems, until systemd gets > appropiately fixed or you get a workaround. Please troll elsewhere. The upcoming Debian Release will come with systemd and it is not helpful at all if trolls just trolling around on serious user questions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e2283334-3ba5-47be-9bba-3a81f14ae...@debian.org
Bug#762725: ITP: apt-dater-host -- host helper application for apt-dater
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: apt-dater-host Version : 1.0.0~ Upstream Author : Thomas Liske * URL : https://github.com/DE-IBH/apt-dater-host * License : GPL2+ Programming Lang: Perl Description : host helper application for apt-dater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140924183354.3223.33184.report...@srv1.linux-dev.org
Re: ITP? Sponsors of eudev, consolekit2, uselessd?
Am 13.11.2014 um 19:17 schrieb Svante Signell: Hi, Hi, I'm currently looking into packaging eudev, consolekit2, uselessd for Debian. If doing so, is anybody interested in sponsoring uploads of these packages? It would be great to know, before digging into the details. If you wish, please reply to me privately. the correct list for such requests is debian-ment...@lists.debian.org, much fun and luck! -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5464fa56.80...@debian.org
Re: greater popularity of Debian on AMD64?
Am 05.09.2012 18:36, schrieb W. Anderson: > It is somewhat surprising and a little disappointing that Debian, or any > other GNU/Linux distribution would be making statements that, in effect, > give great public support to AMD in regard Linux, when the company has > for many years been decidedly ambivalent and generally uncooperative > towards the Linux community, particularly in cooperation with Microsoft > in their negative attitudes and /_actions _/toward Free/Open Source > Software communities. amd64 is the name of the x64 CPU architecture and also with my fglrx hat on I think you do not know about what you are speaking (just have got a look at radeon).. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: greater popularity of Debian on AMD64?
Am 05.09.2012 20:57, schrieb martin f krafft: > also sprach Patrick Matthäi [2012.09.05.1902 +0200]: >> amd64 is the name of the x64 CPU architecture and also with my fglrx hat >> on I think you do not know about what you are speaking (just have got a >> look at radeon).. > > Radeon being owned by AMD and fglrx not having the best reputation, > I don't quite understand your point. > Forget the past where GPUs were owned by ATI, they s When AMD took over ATI they first began to work with the OSS community, seriously checked if they could open fglrx-driver, hire full time people to work on the radeon driver, released 2D/3D/board/Video specifications of their cards and so on.. AMD also supports Debian (just now with an special point release for Wheezy). I do not think that AMD (not the past ATI) is evil and such foo should stop here. And why hasn't got radeon a good reputation? It is the fastest and most supported OSS Xorg driver and also quite stable.. Yeah intel has got a good OSS driver, but they are to lame for complex 2D/3D scenarious.. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: greater popularity of Debian on AMD64?
Am 05.09.2012 23:24, schrieb martin f krafft: > I said fglrx — because its binary-only version caused regular > crashes and headaches for Linux users. > Which is ATM more useful as nvidia prop. ones. And AMD (not the ATI in the past) is in general interested (and already legaly checked) in opening fglrx, but it fails with third party foo... Anyway AMD in general is doing quite much for the OSS community, why it is IMO fud. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: greater popularity of Debian on AMD64?
Am 06.09.2012 10:10, schrieb Josselin Mouette: Le jeudi 06 septembre 2012 à 16:00 +0800, Thomas Goirand a écrit : Would you then advise for an AMD card over Nvidia? Is it better supported, and integrate with the standard desktop screen switcher(s), like xrandr and friends? Yes AMD is better supported, but for some models the performance is atrocious. You can’t even run a fullscreen video in a 3D WM if your hardware is not recent enough. A little bit offtopic. I didn't wanted to advertise to buy AMD GPUs (where the topic itself is about the CPU architecture), just wanted to argument against random old rants. Cheers -- 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/50485cdf.3030...@debian.org
Bug#719673: ITP: needrestart -- needrestart checks which daemons need to be restarted after library upgrades
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: needrestart Version : 0.2 Upstream Author : Thomas Liske * URL : https://github.com/liske/needrestart * License : GPL2+ Programming Lang: Perl Description : needrestart checks which daemons need to be restarted after library upgrades needrestart checks which daemons need to be restarted after library upgrades. It is inspired by checkrestart(1) from the debian-goodies package. It does not rely on lsof as checkrestart does. -- 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/20130814074731.30474.87288.report...@srv1.linux-dev.org
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
Am 10.11.2011 13:54, schrieb onlyjob: Dear Kai, well, then what is different and why can't that be upstreamed? And is there a known case, where the driver provided by Debian doesn't work (if so, is there a bug filed)? Perhaps you are right, given the time and the skills and the hardware and the person skilled and motivated enough it can be upstreamed. Ideally it should be. I'm afraid I don't fit for such job: I can't meet you high expectations since I might not have enough time, skills, right hardware, etc. Let's see what Patrick Matthäi is going to tell since he is apparently have a problematic hardware in his possession. r8169 "works", but I get approx every 5 minutes timeouts of one minute (where the whole NIC does not work) or I have got a package loss around 50% and it is quite slow. This is an older known problem in Debian, just search for "r8168 r8169 debian" on google. Don't get me wrong: I love alternatives, but I don't see their value when it comes to device drivers. That's probably because you can afford it due to lack of problematic hardware on your hands. For those who are not as lucky as you and me it might be more difficult. At least we already have one person who might need solution right now. ;) I just get that new NIC with my new mainboard, a Gigabyte GA-990XA-UD3-AM3. Since I just have got this hardware since 1-2 weeks, I didn't searched for other solutions, but r8168 works. btw: Linux 3.0 and 3.1 didn't worked. Apparently we have a philosophical problem here: given the fact that nether you nor me can benefit from having the alternative driver it will be over-generalization for us to say that nobody can and therefore don't give them a chance. We're not talking about mandatory driver so alternative might be good for someone. Of course it would be perfect to have one 100% working driver in kernel so all those troubles won't be necessary at all. I believe it will be like this, eventually. There was a "fix" for this problem in stable linux-2.6: 2.6.32-36: * r8169: Backport changes up to Linux 3.0.2 (Closes: #627704) - Fix support for RTL8102E and RTL8168DP - Add support for RTL8105E, RTL8168E and another variant of RTL8168DP - Add support for D-Link DGE-530T rev C1 But yeah as I told, 3.0 and 3.1 have got the same problems with my NIC. Cheers. -- 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/4ebbce43.8060...@debian.org
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
Am 10.11.2011 15:18, schrieb Ben Hutchings: On Thu, 2011-11-10 at 14:14 +0100, Patrick Matthäi wrote: Am 10.11.2011 13:54, schrieb onlyjob: [...] Don't get me wrong: I love alternatives, but I don't see their value when it comes to device drivers. That's probably because you can afford it due to lack of problematic hardware on your hands. For those who are not as lucky as you and me it might be more difficult. At least we already have one person who might need solution right now. ;) I just get that new NIC with my new mainboard, a Gigabyte GA-990XA-UD3-AM3. Since I just have got this hardware since 1-2 weeks, I didn't searched for other solutions, but r8168 works. btw: Linux 3.0 and 3.1 didn't worked. [...] Anyone who has problems with r8169 in 3.0 or 3.1 should report this: To: Realtek linux nic maintainers To: Francois Romieu Cc: net...@vger.kernel.org They may also wish to open a Debian bug report and cc that. That is right, also that it should be fixed upstream, which isn't the case since years (according to google results). So I don't see a problem to include the r8168-dkms package, until r8169 realy works. -- 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/4ebbdde9.7050...@debian.org
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
Am 10.11.2011 10:42, schrieb Dmitry Smirnov: > Package: wnpp > Severity: wishlist > Owner: Dmitry Smirnov > > * Package name: r8168-dkms > Version : 8.026.00 > Upstream Author : Realtek Semiconductor Corp. > * URL : > http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false > * License : GPL-2+ (contains binary blobs) > Programming Lang: C > Description : Realtek r8168 device driver for Linux (DKMS version) > r8168 is the Linux device driver released for RealTek RTL8168B/8111B, > RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, RTL8168DP/8111DP, and > RTL8168E/8111E Gigabit Ethernet controllers with PCI-Express interface. > . > This is to substitute built-in r8169 driver if it doesn't work well. I just searched this thread in my MUA and notified that Andreas Beckmann already filled an ITP on 20.09.2011 @ #642198 @Andreas and Dmitry: You may cooperate on packaging or decide, who wants to maintain it in the future. @Ben: I still think this driver should be added as alternative driver to the archive, until r8169 will do its job for the promoted PCIIDs correctly. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
Am 13.11.2011 15:08, schrieb Andreas Beckmann: On 2011-11-12 19:04, Patrick Matthäi wrote: @Andreas and Dmitry: You may cooperate on packaging or decide, who wants to maintain it in the future. I just revived my old ITP http://bugs.debian.org/642198 and tried to put my things in a git repository: Only git://git.debian.org/~anbe-guest/r8168.git seems to work so far. @Ben: I still think this driver should be added as alternative driver to the archive, until r8169 will do its job for the promoted PCIIDs correctly. One possible solution I see would be to upload r8168 to sid (or experimental) and add a severity=serious bug "r8168 should not enter testing - let's fix r8169 in the kernel instead" to prevent migration. Documentation should include detailed instructions how to properly report bugs for the in-kernel r8169 if it does not work (but r8168 does). I do not agree. The package description and README should state, that it is an alternate driver which should be used, if r8169 does not work. It SHOULD enter wheezy as alternative, if r8169 is still buggy. What should be handled by upstream and what should be fixed is outside of this discussion and I am still available to sponsor the upload :) But btw isn't http://code.google.com/p/r8168/ the better homepage for it? Cheers -- 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/4ebfe94d.7060...@debian.org
Re: Bug#650975: r8168: does not belong in a stable release
Am 04.12.2011 19:41, schrieb Julien Cristau: > Source: r8168 > Severity: serious > > (x-debbugs-cc to pmatthaei and debian-release) > > Hi, Hey, thanks for submitting! > > I've been blocking this package from entering testing, but as Patrick > Matthäi questions that choice I'm filing this bug for the record. > > It is my opinion, as a member of the release team, that we shouldn't > ship this package in stable. > > This driver duplicates functionality available in the r8169 module in > the standard linux kernel, which is going to create a support burden, From my point of view, there are this pros and cons for the driver: Pros: - It is free - It is a working driver (mainline r8169 also covers those NICs, but it is not working for years with specific NICs) - Our users with such a crippled NIC could install this *alternative* driver from our archive Cons: - Overlapping PCIIDs with r8169 - People simple switch to r8168 without reporting bugs (decreased bugfixing on r8169) Sure r8169 should be fixed in upstream, so that there is only one driver and everyone is happy, but when it is fixed? Tomorrow or 2015? Who knows. If someone has got a patch I would be happy to test it :) For the time where it isn't fixed we (IMHO) should ship the driver with our release(s) until r8169 is fixed or r8168 is in mainline (who knows..) > the ITP was NAKed by the kernel maintainers, and apparently you agreed > in <4ebfcf49.5070...@abeckmann.de> to not let this enter wheezy. I just want to note: It is my personal motivation that we should release it (but there is much time until the next release, so the situation could change), not the motivation of Andreas Beckmann, I am doing it on my own. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Bug#655956: O: drizzle
Package: wnpp Severity: normal Hello, I am the sponsor of the opendchub package. Since the package is RC buggy since a longer time and the maintainer is not responsible since an longer time I orphan it. I would be happy if someone could take care of the package. If you are not an Debian Developer you may ask me directly per mail for sponsoring your upload(s). Cheers. -- 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/20120115101528.12263.46725.report...@srv1.linux-dev.org
Re: Bug#655956: O: drizzle
Am 15.01.2012 11:15, schrieb Patrick Matthäi: > Package: wnpp > Severity: normal > > Hello, > > I am the sponsor of the opendchub package. > Since the package is RC buggy since a longer time and the maintainer is not > responsible since an longer time I orphan it. Just to avoid confusions, this is realy about the drizzle package, but I also orphaned the opendchub package. Just a little copy paste fault :-) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: alioth is down (again)
Am 29.01.2012 20:52, schrieb Poison Bit: > On Sun, Jan 29, 2012 at 8:40 PM, Poison Bit wrote: > [] [...] > I use to think too much as final user... I.E. I could love to use a > Debian "anonymous DNS" servers instead of be tracked on 8.8.8.8 to get > publicity. Sorry it that annoys to someone. Providing infrastructure services like DNS is not the job of a distribution, but providing software for doing this on your own, which is the case :-) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Proposed removal of yiff
Am 24.02.2012 14:12, schrieb Phil Brooke: > Hi, > > I plan to ask for the removal of the yiff sound package from Debian late > next week. > - It no longer appears to have any upstream maintainer. > - The only package that depends on yiff is roaraudio, and I think that's > only as a minor plugin. (I'm cc'ing the maintainers of roaraudio.) No problem, we can remove it with our next roaraudio upload. > Please email if you object. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Enabling hardened build flags for Wheezy
Am 29.02.2012 22:52, schrieb Moritz Muehlenhoff: > The most important reason for dpkg-buildflags is [1.] : > One of the Wheezy release goals is to build as many packages as > possible with a hardened toolchain by means of dpkg-buildflags: > http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags > > I've written conversion documentation in the Debian Wiki to provide > central step-by-step documentation: > http://wiki.debian.org/HardeningWalkthrough I fully support the hardening goal. May it be an option to add lintian errors (also non-fatal errors on ftp-master side) about missing-hardening-build in the future? It may be too late for Wheezy to force packages to build with hardened build flags, but we should start with it as soon as possible IMHO. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Enabling hardened build flags for Wheezy
Am 29.02.2012 23:57, schrieb Russ Allbery: > Patrick Matthäi writes: > >> I fully support the hardening goal. >> May it be an option to add lintian errors (also non-fatal errors on >> ftp-master side) about missing-hardening-build in the future? > >> It may be too late for Wheezy to force packages to build with hardened >> build flags, but we should start with it as soon as possible IMHO. > > It's a little tricky because hardening-check is prone to false positives > (through no fault of its own; it's just a limitation of what one can > check). > > For example: > > windlord:~> hardening-check /usr/bin/remctl > /usr/bin/remctl: > Position Independent Executable: no, normal executable! > Stack protected: no, not found! > Fortify Source functions: yes (some protected functions found) > Read-only relocations: yes > Immediate binding: yes > > but that binary is indeed stack-protected (built with the appropriate > options). It just never allocates any substantial amount of data off the > stack, so there's non need to add the stack protection. > > Fortify Source functions has a similar problem. Not every function call > can be protected, so it's possible to have all of the calls in a > particular binary be ones that happen to not be protectable, and hence get > a false positive for a binary that's built properly. > That behavious is new for me, thanks for this usefull hint! But maybe it still would be an option to add am lintian warning (regarding your above arguments throwing an error would not be the right solution) about "maybe-missing-hardening"? The maintainer would be aware about this potential problem, check his package and if it is realy a false positive he still could overwrite it. What do you think? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Do not use tabs in /etc/init.d/[script]
Am 02.03.2012 16:01, schrieb Alexey Bearded: Dear Developers and Maintainers, Please, do not use tabs for indentation in init.d scripts. It can make your scripts a bit more readable for all users. I am writing init scripts in Debian with tabs, so on: s/all/some/ Cheers. -- 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/4f50e649.9070...@debian.org
Bug#696739: ITP: pam-geoip -- PAM module checking access of source IPs with a GeoIP database
Package: wnpp Severity: wishlist Owner: "Patrick Matthäi" * Package name: pam-geoip Version : 1.0 Upstream Author : Hanno Hecker * URL : http://ankh-morp.org/code/pam_geoip/ * License : BSD Programming Lang: C Description : PAM module checking access of source IPs with a GeoIP database This PAM module provides GeoIP checking for logins. The user can be allowed or denied based on the location of the originating IP address. This is similar to pam_access, but uses a GeoIP City database instead of host name / IP matching. -- 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/20121226161651.21158.63738.report...@srv1.linux-dev.org
Re: bugs.debian.org: something's wrong...
Hi, Am 15.03.2013 20:14, schrieb Paul Gevers: Hi Is it just me or am I the only one getting bug reports from bugs that don't seem to exist on bugs.debian.org. I do not think that you are alone. The latest bug that I can find is 703078. The next one [1] fails and after that it says it can not be found. An error occurred. Error was: Bad bug log for Bug 703079. Unable to read records: state kill-init at end at /usr/local/lib/site_perl/Debbugs/Log.pm line 293. We sent a report on 16:11 o'clock (german time) and it was deffered until 19:50 with the message: status=deferred (host bugs-master.debian.org[140.211.166.26] said: 452 Space shortage, please try later (in reply to MAIL FROM command)) And now it is still not available at the bug tracker. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org */ -- 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/51436a4f.3030...@debian.org
Re: Will we see MariaDB in Jessie?
Am 06.05.2013 19:02, schrieb Thomas Goirand: > I wonder what the plans of the MySQL maintainers are concerning MySQL vs > MariaDB. Famously, Fedora made the switch. What will happen in Debian? > What kind of transition would this mean? Would it be a drop-in > replacement like Monty is pretending, or would it be harder? An ITP exists: #565308 But why should it _replace_ MySQL, why not providing it as an alternative MySQL'ish server? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Will we see MariaDB in Jessie?
Am 06.05.2013 19:33, schrieb Julien Cristau: > On Mon, May 6, 2013 at 19:17:47 +0200, Patrick Matthäi wrote: > >> But why should it _replace_ MySQL, why not providing it as an >> alternative MySQL'ish server? >> > Because Oracle. That alone does not count, since it is still OSS. As long as _MySQL_ maintainers are able (and want) to continue MySQL (or some other person) there is no reason to not keep it in Debian. I also can not get used to the thought that we only provide one alternative like some other more or less popular distributions, where you need e.g. a HTTP daemon and then you just can install Apache from their repositories. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ signature.asc Description: OpenPGP digital signature
Re: Bug#739997: ITA: mumble -- Low latency VoIP client
Am 24.02.2014 20:50, schrieb Chris Knadle: Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org This package hasn't been orphaned, but there hasn't been any activity from the maintainer or uploader for ~18 months despite some grave bugs, so I'm offering to adopt the package as the maintainer. I'm familiar with maintaining this package -- I put together the current 1.2.4-0.2 package in sid and jessie. I will support this. Please go ahead. Ron was unable to maintain the package after he has took over the maintainance of it from me. I would sponsor your uploads. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530f0fa4.1070...@debian.org
