Требуется подтверждение для доставки вашего письма "Системная Работа с Клиентом." до sh...@mail.ua.
(see english version below) (дивіться українську версію нижче) Ваше письмо не прошло спам-фильтр и было временно помещено в папку "Спам". Для доставки письма, пожалуйста, перейдите по этой ссылке: http://www.shade.mail.ua/confirm/1QJIgJ-0006Ro-R7_mail.ua_shade Детали письма: Тема: "Системная Работа с Клиентом." Отправитель: "Josef Edwards" Получатель: sh...@mail.ua Дата: 09.05.2011 Подробнее про анти-спам на Mail.UA --- Наш почтовый сервис использует анти-спам систему, основанную на принципе «белого списка». Это значит, что письмо от отправителя, адрес которого отсутствует в адресной книге получателя, помещается в папку «Спам» После того как вы перейдете по ссылке, указанной выше, ваш e-mail адрес будет добавлен в адресную книгу sh...@mail.ua и все ваши следующие письма будут приниматься без дополнительных проверок. Спасибо за понимание, Команда Mail.UA. = українська == Потрібне підтвердження доставки вашого листа "Системная Работа с Клиентом." до sh...@mail.ua. Ваш лист не пройшов спам-фільтр і його було тимчасово поміщено до папки "Спам". Для доставки листа, будь ласка, перейдіть за наступним посиланням: http://www.shade.mail.ua/confirm/1QJIgJ-0006Ro-R7_mail.ua_shade Деталі листа: Тема: "Системная Работа с Клиентом." Відправник: "Josef Edwards" Одержувач: sh...@mail.ua Дата: 09.05.2011 Детальніше про анти-спам на Mail.UA --- Наш поштовий сервіс використовує анти-спам систему, засновану на принципі "білого списку". Це означає, що лист від відправника, адреса якого відсутня в адресній книзі одержувача, переміщується до папки "Спам". Після того як ви перейдете за посиланням, зазначеним вище, вашу e-mail адресу буде додано до адресної книги sh...@mail.ua і всі ваші наступні листи будуть прийматися без додаткових перевірок. Дякуємо за розуміння, Команда Mail.UA = english = Confirmation is required to deliver your message "Системная Работа с Клиентом." to sh...@mail.ua. Your letter did not pass the spam filter, and it was temporarily placed in the Spam folder. To deliver the letter to sh...@mail.ua Inbox, please follow this link: http://www.shade.mail.ua/confirm/1QJIgJ-0006Ro-R7_mail.ua_shade Details: Subject: "Системная Работа с Клиентом." Sender: "Josef Edwards" Recipient: sh...@mail.ua Date: 05/09/2011 More information about our spam filter - Our mail service uses anti-spam system based on the "whitelist" principle . This means that the message from an unknown sender (whose address is not listed in the recipient's address book) is automatically placed in the Spam folder Once you navigate to the link above and follow the instructions, your e-mail address will be added to sh...@mail.ua Contacts, and all your following letters will be accepted without any further checks. Thank you for understanding, Mail.UA team.
Потрібне підтвердження для доставки вашого листа "Системная Работа с Клиентом." до yars...@mail.ua.
(see english version below) (смотрите русскую версию ниже) Потрібне підтвердження відправки вашого листа "Системная Работа с Клиентом." для yars...@mail.ua. Ваш лист не пройшов спам-фільтр і його було тимчасово поміщено до папки "Спам". Для доставки листа, будь ласка, перейдіть за наступним посиланням: http://www.yarstar.mail.ua/confirm/1QJIhL-00064l-EU_mail.ua_yarstar Деталі листа: Тема: "Системная Работа с Клиентом." Відправник: "Randell Moseley" Одержувач: yars...@mail.ua Дата: 09.05.2011 Детальніше про анти-спам на Mail.UA --- Наш поштовий сервіс використовує анти-спам систему, засновану на принципі "білого списку". Це означає, що лист від відправника, адреса якого відсутня в адресній книзі одержувача, переміщується до папки "Спам". Після того як ви перейдете за посиланням, зазначеним вище, вашу e-mail адресу буде додано до адресної книги yars...@mail.ua і всі ваші наступні листи будуть прийматися без додаткових перевірок. Дякуємо за розуміння, Команда Mail.UA = русский = Требуется подтверждение для доставки вашего письма "Системная Работа с Клиентом." до yars...@mail.ua. Ваше письмо не прошло спам-фильтр и было временно помещено в папку "Спам". Для доставки письма, пожалуйста, перейдите по этой ссылке: http://www.yarstar.mail.ua/confirm/1QJIhL-00064l-EU_mail.ua_yarstar Детали письма: Тема: "Системная Работа с Клиентом." Отправитель: "Randell Moseley" Получатель: yars...@mail.ua Дата: 09.05.2011 Подробнее про анти-спам на Mail.UA --- Наш почтовый сервис использует анти-спам систему, основанную на принципе «белого списка». Это значит, что письмо от отправителя, адрес которого отсутствует в адресной книге получателя, помещается в папку «Спам» После того как вы перейдете по ссылке, указанной выше, ваш e-mail адрес будет добавлен в адресную книгу yars...@mail.ua и все ваши следующие письма будут приниматься без дополнительных проверок. Спасибо за понимание, Команда Mail.UA. = english = Confirmation is required to deliver your message "Системная Работа с Клиентом." to yars...@mail.ua. Your letter did not pass the spam filter, and it was temporarily placed in the Spam folder. To deliver the letter to yars...@mail.ua Inbox, please follow this link: http://www.yarstar.mail.ua/confirm/1QJIhL-00064l-EU_mail.ua_yarstar Details: Subject: "Системная Работа с Клиентом." Sender: "Randell Moseley" Recipient: yars...@mail.ua Date: 05/09/2011 More information about our spam filter - Our mail service uses anti-spam system based on the "whitelist" principle . This means that the message from an unknown sender (whose address is not listed in the recipient's address book) is automatically placed in the Spam folder Once you navigate to the link above and follow the instructions, your e-mail address will be added to yars...@mail.ua Contacts, and all your following letters will be accepted without any further checks. Thank you for understanding, Mail.UA team.
Требуется подтверждение для доставки вашего письма "Системная Работа с Клиентом." до yi...@mail.ua.
(see english version below) (дивіться українську версію нижче) Ваше письмо не прошло спам-фильтр и было временно помещено в папку "Спам". Для доставки письма, пожалуйста, перейдите по этой ссылке: http://www.yield.mail.ua/confirm/1QJIqp-0008MI-Ek_mail.ua_yield Детали письма: Тема: "Системная Работа с Клиентом." Отправитель: "Lindsey Graves" Получатель: yi...@mail.ua Дата: 09.05.2011 Подробнее про анти-спам на Mail.UA --- Наш почтовый сервис использует анти-спам систему, основанную на принципе «белого списка». Это значит, что письмо от отправителя, адрес которого отсутствует в адресной книге получателя, помещается в папку «Спам» После того как вы перейдете по ссылке, указанной выше, ваш e-mail адрес будет добавлен в адресную книгу yi...@mail.ua и все ваши следующие письма будут приниматься без дополнительных проверок. Спасибо за понимание, Команда Mail.UA. = українська == Потрібне підтвердження доставки вашого листа "Системная Работа с Клиентом." до yi...@mail.ua. Ваш лист не пройшов спам-фільтр і його було тимчасово поміщено до папки "Спам". Для доставки листа, будь ласка, перейдіть за наступним посиланням: http://www.yield.mail.ua/confirm/1QJIqp-0008MI-Ek_mail.ua_yield Деталі листа: Тема: "Системная Работа с Клиентом." Відправник: "Lindsey Graves" Одержувач: yi...@mail.ua Дата: 09.05.2011 Детальніше про анти-спам на Mail.UA --- Наш поштовий сервіс використовує анти-спам систему, засновану на принципі "білого списку". Це означає, що лист від відправника, адреса якого відсутня в адресній книзі одержувача, переміщується до папки "Спам". Після того як ви перейдете за посиланням, зазначеним вище, вашу e-mail адресу буде додано до адресної книги yi...@mail.ua і всі ваші наступні листи будуть прийматися без додаткових перевірок. Дякуємо за розуміння, Команда Mail.UA = english = Confirmation is required to deliver your message "Системная Работа с Клиентом." to yi...@mail.ua. Your letter did not pass the spam filter, and it was temporarily placed in the Spam folder. To deliver the letter to yi...@mail.ua Inbox, please follow this link: http://www.yield.mail.ua/confirm/1QJIqp-0008MI-Ek_mail.ua_yield Details: Subject: "Системная Работа с Клиентом." Sender: "Lindsey Graves" Recipient: yi...@mail.ua Date: 05/09/2011 More information about our spam filter - Our mail service uses anti-spam system based on the "whitelist" principle . This means that the message from an unknown sender (whose address is not listed in the recipient's address book) is automatically placed in the Spam folder Once you navigate to the link above and follow the instructions, your e-mail address will be added to yi...@mail.ua Contacts, and all your following letters will be accepted without any further checks. Thank you for understanding, Mail.UA team.
Re: Best practice for cleaning autotools-generated files?
On Sun, 8 May 2011 22:36:20 +0200 Enrico Weigelt wrote: > > The options are just passed on unchanged. No problem with that. Can > > still call ./configure directly. Maybe it wastes a little bit of time > > but if you're cross-building, you're using a really fast machine so > > this is hardly of concern. > > Requires that you can really pass all required options *and* > environment variables reliably. I've seen packages where this > wasn't the case. Just as there are packages which cannot be automatically built just from the VCS checkout and ./autogen.sh, hence the need for tarballs where that work has already been done. I think you've argued yourself into a corner there. > > and all the other build systems out there are suddenly compatible > > across all packages?? Dream on. > > At least, for autoconf packages, which follow the rules I've written > down here: > > > http://www.metux.de/index.php/de/component/content/article/1-software-entwicklung/57-rules-for-distro-friendly-packages.html > > that would be the case. Those aren't rules, those are your preferences which you wrote yourself. I reviewed them when you first posted about them and I discounted the majority as a combination of over-elevated preference and complete dreamland. I'm not going to have time to continue feeding your trolling. I've said my bit, nothing you've said has been a new argument for the elevation of your pet system to be deemed "best practice" by anyone except you. Try that with any of my upstream packages and I'll laugh at you, then ignore you and then I'll add you to the killfile. Please stop this one-man campaign. It's already sounding tired and repetitive. > Actually, once I fixed packages to this, the individual distro > builder pkg configuration is reduced to nothing more than the > package name, list of available features and their enable/disable > flags, and the individual target config for the package just > tells the version and selected features. That's it. > > (see attached files) Gentoo have been trying that for quite some time but it still needs a wide range of specialist tools to keep it working. > > That's not technical and there is no one organisation which bridges > > all of the various upstream teams. If you want to change things, you > > must persuade each team to adopt your preferences and you have > > That's not necessary. Having a project, where people like distro > package maintainers come together (at least for a bunch of packages > and growing it later) and maintain stabelized and distro-friendly > downstream branches. (oh, that's what OSS-QM is meant for ;-o) Then I'm glad I've got nothing to do with OSS-QM and I have no intention of modifying any of my upstream packages to meet your personal preferences, even if you continue to dress them up as requirements. > > > Exactly the same reason why things like AC plugs, voltages and > > > frequencies are standardized. > > > > Not true. Those things MUST work together in every permutation within a > > specific jurisdiction or people can die. Debian and autotools are > > nowhere near that level of importance. > > Probably not. But why not learning from the other areas of engineering ? The benefit has to be transferable across fields - blatantly the analogy you drew has no relevance to autotools. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpCPLF0vNJQD.pgp Description: PGP signature
Re: Best practice for cleaning autotools-generated files?
* Bernhard R. Link schrieb: > Given that aclocal is part of automake that is not very surprising. > If you want to use it without automake, you could just add a single-line > Makefile.am with the needed data (without AM_INIT_AUTOMAKE in configure.ac > autoreconf will not call automake), but best simply use automake. So, essentially, autoconf-only packages should be converted to automake packages that way ? > Promoting everything to add some script (which people will always have > to look at first because you can never be sure what it does), just > because some projects prefer to have their own kind of build-system > really seems kind of far-fetched. Well, I'm doing such things in the OSS-QM project (where packages also undergo lots of other tests, massbuilds on various cross targets, etc), so consumers of OSS-QM can be sure that these scripts do exactly what I described there. Of course, we cannot ever enforce that on upstreams, and we dont need to. That's why I've founded the OSS-QM project: it acts as an intermediate between upstream and consumers (distros, etc), and does those things (also including hotfixes, etc) which upstreams tend not to do. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- 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/20110508204400.GL25423@nibiru.local
Re: Best practice for cleaning autotools-generated files?
* Neil Williams schrieb: (forgot attachments) ... -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- @package: expat @version: 2.0.1.999 feature-enable=namespaces: on feature-enable=tools: on feature:namespaces on: --enable-namespaces off:--disable-namespaces -- feature:tools on: --enable-tools off:--disable-tools -- @style: class/autotools-2-features @style: source/oss-qm-git-2 builder-supports-install-strip: off !!postinstall-remove-la:on
Re: Best practice for cleaning autotools-generated files?
* Neil Williams schrieb: > ./autogen.sh does not clean anything. Clarification: with "clean state" I meant a state of the tree where all the generated files (from autotools+friends) have been reliably regenerated afresh (no leftovers from previous runs). Removing temporary files from different stages (eg. configure or make run) is a completely different issue. > > It *is*, as soon as this cannot run through without special > > flags (eg. if some features have to be switched off, etc). > > The options are just passed on unchanged. No problem with that. Can > still call ./configure directly. Maybe it wastes a little bit of time > but if you're cross-building, you're using a really fast machine so > this is hardly of concern. Requires that you can really pass all required options *and* environment variables reliably. I've seen packages where this wasn't the case. And requires the distro packaging system to pass the configure flags twice (to autogen.sh and configure), yet another piece of additional complexity. > > Adds additional complexity to add proper parameters here, for each > > individual package. (and, of course, find out all this first). > > > > This way, you add unnecessary burden to all the maintainers of all > > the distros out there (that might be interested in your package). > > and all the other build systems out there are suddenly compatible > across all packages?? Dream on. At least, for autoconf packages, which follow the rules I've written down here: http://www.metux.de/index.php/de/component/content/article/1-software-entwicklung/57-rules-for-distro-friendly-packages.html that would be the case. Actually, once I fixed packages to this, the individual distro builder pkg configuration is reduced to nothing more than the package name, list of available features and their enable/disable flags, and the individual target config for the package just tells the version and selected features. That's it. (see attached files) > That's not technical and there is no one organisation which bridges > all of the various upstream teams. If you want to change things, you > must persuade each team to adopt your preferences and you have That's not necessary. Having a project, where people like distro package maintainers come together (at least for a bunch of packages and growing it later) and maintain stabelized and distro-friendly downstream branches. (oh, that's what OSS-QM is meant for ;-o) > > Exactly the same reason why things like AC plugs, voltages and > > frequencies are standardized. > > Not true. Those things MUST work together in every permutation within a > specific jurisdiction or people can die. Debian and autotools are > nowhere near that level of importance. Probably not. But why not learning from the other areas of engineering ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- 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/20110508203620.GJ25423@nibiru.local
Re: Crypto consolidation in debian ?
On Sun, 2011-05-08 at 21:25 +0200, Arthur de Jong wrote: > On Sun, 2011-05-01 at 12:55 +0200, Bastien ROUCARIES wrote: > > It seems fedora is moving to nss for openldap > > I don't think it's completely free from the same kind of issues as > GNUTLS. For example, I recently came across this: > https://bugzilla.redhat.com/show_bug.cgi?id=701587 > NSS (Network Security Service, not Name Service Switch) seems to change > the scheduling parameters of a process. [...] Scheduling parameters generally apply to a *thread*, not a process. There is nothing wrong with a library changing those parameters for its own thread. (However, creating new threads that the application doesn't know about it can bring its own problems. It is common practice on Windows and has led to some nasty bugs and workarounds there.) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Best practice for cleaning autotools-generated files?
* Enrico Weigelt [110508 21:45]: > Autoconf (w/o automake) offers no means to tell additional m4 > include pathes (eg. in configure.ac), so that just calling > autoreconf (w/o any additional parameters!) can do a full > regeneration all on its own. Given that aclocal is part of automake that is not very surprising. If you want to use it without automake, you could just add a single-line Makefile.am with the needed data (without AM_INIT_AUTOMAKE in configure.ac autoreconf will not call automake), but best simply use automake. Promoting everything to add some script (which people will always have to look at first because you can never be sure what it does), just because some projects prefer to have their own kind of build-system really seems kind of far-fetched. Bernhard R. Link -- 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/20110508200815.ga21...@pcpool00.mathematik.uni-freiburg.de
Re: Best practice for cleaning autotools-generated files?
* Simon Josefsson schrieb: > >> The problem is that autoreconf offers NO command line options for you to > >> pass the required -I parameters for aclocal, nor is there a way to encode > >> that information in the one place where it could conveniently live > >> (configure.ac) AFAIK. > > > > So, more precisely: autoreconf lacks an important feature would like > > to see. > > I don't think this is the case -- others have already explained how to > achieve the goals above. If you still believe something is missing in > autoreconf, please report it to upstream so it can be fixed. I was just summing up what I learned from this thread for now. Let's repeat this: (correnct me if I'm wrong) Autoconf (w/o automake) offers no means to tell additional m4 include pathes (eg. in configure.ac), so that just calling autoreconf (w/o any additional parameters!) can do a full regeneration all on its own. Right ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- 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/20110508194331.GI25423@nibiru.local
Re: Best practice for cleaning autotools-generated files?
* Neil Williams schrieb: > > Which ones exactly (besides the usual autotools) ? > > bison, flex and a few others. Standard tools available on virtually any system that likes to build anything ... To make sure they're installed, use build-time dependencies. Done. > Also that certain stages of the transition from VCS checkout to > tarball are not actually scripted anywhere, just described in a file. Bad practise, unnecessarily burns manpower and leaves more chances for errors. Actually, not quite that unsual out there, but I'm fixing this for packages I need in OSS-QM. > > I don't want to repeat the last decades if SCM theory and common > > practies here, but one of the major goals of an SCM infrastructure > > is that you always get can grab the source of some product in some > > specific version and run a fully rebuild, anytime. _Reliable_ > > reproducability. Tarballs that are not fully-automatically produced > > from the appropriate SCM tag (and can be reproduced anytime) simply > > dont meet that requirement. > > Disagree. A tarball is easier to get hold of than some weird tag in an > unfamiliar VCS. But tarballs dont exactly scale well when you need to maintain many versions and downstream branches. > Common format, common methods to download and obtain it, simple URL's Yes, simple as an doSomething() function ;-o Practical for the end-user, but lacks a lot of useful information (eg. history). > > Maybe that all worked for you over many years. Fine. > > It has indeed - about 10yrs at last count. Well, for me, in the last 10yrs that way exactly did not work. My current models and workflows are product of an 10yrs evolutions, lots of trials and errors. > Personally, I dislike sysroot because it doesn't actually make my > cross-building work any easier. Actually, I've switched to sysroot several years ago, because it made it a lot easier and more reliable. Of course, many packages dont work with it yet (mostly due stupid buildfiles). So I fix it, and I fix it once and for all. Takes some bit more time in the first place, but gets you rid of a whole lot of trouble later. > > Guess what, I wouldn't work with upstreams that don't provide > > reliable release tags in the VCS (an VCS that I can import to git). > > Actually, I sometimes do, but it adds a lot of extra burden. > > Fine. That means that any difference on that issue is personal > preference and has no place in any "best practice" guide or > specification. Heavily depends on the scope of that guide. If, for example, Debian would add that point to its packaging guidelines, somebody would have to fill the gap. hmm. oss-qm ? ;-) > > My buildsystem (called Briegel), doesn't even bother with things > > like tarballs or patches (still supported, but unused for years now). > > It simply grabs the source tree from git by a normalized ref (eg. tag). > > Normalized means: there's a simple rule to transform a vector of > > package name and (also normalized) version number into a ref name. > > Period. > > Then your build system cannot cope with any of my packages. It doesn't need to. If I ever needed one of your packages, I'd cleanup and maintain it the OSS-QM project. Briegel then would just pull from there. A clear separation of roles. > > Any changes needed in the source tree are done through SCM. > > (the processes behind may vary between individual packages). > > No, those should be done via patches, managed by dpkg-source format 3 > or directly incorporated into the upstream tarball (which is how I > prefer to do it). Maybe this approach works for Debian, but for my projects it doesn't scale well. It essentially means manually maintaining text-based patches (especially when it comes to rebasing, moving to other branches, etc, etc). I dont wanna do such manual things anymore since the SCM can do that automatically. > Depending on the purpose of the patches, the patch can go upstream or > into the Debian package. It's trivial to export patches from git automatically. I also thought about adding additional changeset headers, so an robot could export and mail the patches automatically. > > True. It's a distro-agnostic issue. It's about how to be a good > > upstream to make distro's lifes easier and extends into the whole > > QM topics. > > And that includes the ability to compare the checksums of tarballs > included in the distributed sources of an embedded cross-built > distribution to check that you really do have the same version as other > distributions. Why care about tarball checksums if you have cryptographically secured tags and histories ? > I never have seen any point in that. When preparing patches for an > embedded distribution, it is pointless to modify the sources > themselves. Provide patches in your own build system (i.e. debian/) and > let people have the assurance that your sources match everyone else's > by keeping the original tarball unchanged and putting your changes into > either a .diff.gz or a .de
Re: Best practice for cleaning autotools-generated files?
* Simon McVittie schrieb: > As much as I wish this had been the convention, it isn't - the convention is > that autogen.sh *does* call ./configure (often with options suitable for > developers of the project, whereas the ./configure defaults are more suitable > for packagers). Actually, I dont see that there's any convention on that. Some packages do call configure, some don't, other even have different script names. It's quite unlinkely that we'll some day really have an standard, so I've decided to set my own policies which I think are best for distros in general (not just an specific one) and fixing packages within the OSS-QM project. I've written down a few lines on my policies, JFYI: http://www.metux.de/index.php/de/component/content/article/1-software-entwicklung/57-rules-for-distro-friendly-packages.html > For many (most? all?) autoconf/automake projects, running "autoreconf" > is enough; that's essentially what dh_autoreconf does. Yes, but just most of them, not all. That still leaves a lot of extra logic for those which dont. I prefer to keep those things out of the distro's packaging system, handle them in the individual package itself and provide a common interface, which (for autoconf'ed packages) looks like this: #1: ./autogen.sh #2: CC=.. LD=.. ... ./configure #3: make #4: make DESTDIR=... install cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- 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/20110508192518.GB25222@nibiru.local
Re: Crypto consolidation in debian ?
On Sun, 2011-05-01 at 12:55 +0200, Bastien ROUCARIES wrote: > It seems fedora is moving to nss for openldap I don't think it's completely free from the same kind of issues as GNUTLS. For example, I recently came across this: https://bugzilla.redhat.com/show_bug.cgi?id=701587 NSS (Network Security Service, not Name Service Switch) seems to change the scheduling parameters of a process. Also OpenLDAP itself isn't that good a candidate to load into every process. Just look at all the hacks nss_ldap needs to do keep it in a sane state. Also environment variables and files in user's home directory influence libldap's workings. Although switching SSL/TLS library to something different may be a good idea, I don't think it will fix the problem for NSS (Name Service Switch here) modules. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Crypto consolidation in debian ?
On Sun, 2011-05-01 at 14:08 +0100, Roger Leigh wrote: > If we could move to having a central service, rather than having every > process load in a pile of extra libraries, I would probably be in > favour of it. If would make some things, such as NSS queries inside > chroots, much more efficient and robust. This is what nss-pam-ldapd does to replace nss_ldap (NSS part in libnss-ldapd). It uses a central daemon running as a dedicated user (for LDAP NSS requests only). The original reason for the creation of nss-ldapd was that the OpenLDAP libraries are not meant to be in processes that do not expect them. I guess there are more. Another solution (that Joss already pointer out) is libnss-sss which has a slightly broader scope. I'm not sure that having a central process to read stuff from simple flat files is a good idea though as it adds extra complexity and a single point of failure. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: 0-day NMUs for RC bugs without activity for 7 days?
On Sat, 07 May 2011 15:08:37 +0200, Stefano Zacchiroli wrote: > But I agree that this policy should not force maintainers of several > packages to ping their bug logs every 7 days, although at the very > minimum I do expect a maintainer to post to an RC bug log at least once > an "I'm on it" message. Ack, I've also read the "no reaction within 7 days" as "no short mail to the BTS withing the first seven days". > I've proposed before, for this change, to stress > that the NMUer should do a best effort attempt to verify whether the > maintainer is working on the fix, for instance by looking at VCS head of > the package, asking on IRC, or the like. I'd prefer to narrow this down to visible activity in the bug report; if we have to hunt down maintainers on all possible and impossible channgles, that doesn't scale ... > Finally, considering this policy has been in effect for 5 years or so, > and considering that devref states guidelines rather than hard rules, I > believe the _practical_ impact of this change would be very low. /me nods. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: Die Tontauben: Father of Night signature.asc Description: Digital signature
Bug#626097: ITP: ruby-pgplot -- A Ruby interface to the PGPLOT graphics library
Package: wnpp Owner: Youhei SASAKI Severity: wishlist * Package name: ruby-pgplot Version : 0.1.3-1 Upstream Author : Masahiro TANAKA * URL or Web page : http://pgplot.rubyforge.org/ * License : Ruby's Description : A Ruby interface to the PGPLOT graphics library Ruby/PGPLOT is the Ruby interface to the PGPLOT graphics library. PGPLOT is a FORTRAN library to draw line/scatter/histogram plot, error bar, contour/image/vector map, etc. Supports various output devices including Postscript, PNG, X-Window, etc. --- Youhei SASAKI GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- 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/87pqntdnbc.wl%uwab...@gfd-dennou.org
Re: wheel group
Quoting Steve Langasek (vor...@debian.org): > But I hope the login maintainers 'wontfix' any such bug report. This is a I suspect they would, yesbased on the advice of people they trust for such things..:-) (imho, such case is indeed something where the Technical Comittee has added value if I refer to some recent interviews I read..:-)) signature.asc Description: Digital signature
Bug#626087: ITP: tinarng -- Tina's (pseudo-) Random Number Generator Library
Package: wnpp Severity: wishlist Owner: "Torquil Macdonald Sørensen" * Package name: tinarng Version : 4.12 Upstream Author : Heiko Bauke * URL : http://trng.berlios.de * License : BSD Programming Lang: C++ Description : Tina's (pseudo-) Random Number Generator Library Tina's Random Number Generator Library (TRNG) is a state of the art C++ pseudo-random number generator library for sequential and parallel Monte Carlo simulations. Its design principles are based on a proposal for an extensible random number generator facility, that will be part of the random number generator facility of the forthcoming revision of the C++ standard. -- 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/20110508173135.19512.42072.report...@asus.home.org
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On Sun, 2011-05-08 at 17:56 +0200, Sven Hoexter wrote: > On Sun, May 08, 2011 at 05:33:42PM +0200, Martin Zobel-Helas wrote: > > Hi, > > > i currently wonder if Debian should implement RFC 4941 as default for > > wheezy. > > I thought about this a few month ago and my proposal would've been to > add an example in /etc/sysctl.conf. I'm not sure if we can or should > distinguish between desktop and server systems because I don't think > you'll like to have it as a default for a server system. [...] I don't see why. Any static records in DNS should not use SLAAC addresses, since swapping the NIC will change those addresses. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On dim., 2011-05-08 at 17:56 +0200, Sven Hoexter wrote: > Beside that the default timeout setting for the dynamic address is something > to be discussed, I believe the default is about a week which is rather > long if you want to have a benefit over static assignment. After all the gain > of > anonymity highly depends on the IP assignment rules your ISP will have. > If you always end up with the same /64 you gain nearly nothing and there are > better properties to track you anyway. Privacy extension addresses are more intended for the mobile people (prevent you beeing tracked when you change provider, like connecting from some hotspot, the hotel, a conference, work, home etc.). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On Sun, May 08, 2011 at 05:33:42PM +0200, Martin Zobel-Helas wrote: Hi, > i currently wonder if Debian should implement RFC 4941 as default for > wheezy. I thought about this a few month ago and my proposal would've been to add an example in /etc/sysctl.conf. I'm not sure if we can or should distinguish between desktop and server systems because I don't think you'll like to have it as a default for a server system. Beside that the default timeout setting for the dynamic address is something to be discussed, I believe the default is about a week which is rather long if you want to have a benefit over static assignment. After all the gain of anonymity highly depends on the IP assignment rules your ISP will have. If you always end up with the same /64 you gain nearly nothing and there are better properties to track you anyway. Sven -- I don't know much, but I do know this: With a golden heart, comes a rebel fist [ Streetlight Manifesto - Here's To Life ] -- 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/20110508155651.GE1795@colin
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
Hi, i currently wonder if Debian should implement RFC 4941 as default for wheezy. Background: IPv6 configured via router advertisement will use the hardware address of the ethernet card to encode the IPv6 address. This raises privacy issues, such as being able to track each single device. I therefor wonder, if Debian should be shipped with the privacy extensions for stateless address autoconfiguration on IPv6 per default starting with wheezy. I would like to hear other developers meanings to this issue, before proposing this as release goal for wheezy. Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- 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/20110508153342.ge9...@ftbfs.de
Re: Bits from the Release Team - Kicking off Wheezy
Le Sun, May 08, 2011 at 10:07:53AM +0200, Stefano Zacchiroli a écrit : > > I would be happy if we could stop discussing what today is just spilled milk, > given that one way or another this matter has been settled. To clarify, Enrico wrote that “the hands of FD were rather tied” by the 2008 GR, and this is about what I react, and only this. Whether this GR made it more difficult to have non-packaging DDs or not is indeed another question that I agree to not discuss. As the proposer of this GR I feel responsible for its consequences, and I wanted to clarify that it is not formally tying any hands. By no way I am suggesting that your efforts were not difficult. Cheers, -- Charles -- 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/20110508112133.ga14...@merveille.plessy.net
Processed: Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
Processing commands for cont...@bugs.debian.org: > reassign 616317 general Bug #616317 [base] base: commit= ext3 mount option in fstab has no effect. Bug reassigned from package 'base' to 'general'. > thanks Stopping processing here. Please contact me if you need assistance. -- 616317: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616317 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13048513041699.transcr...@bugs.debian.org
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
reassign 616317 general thanks In http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;bug=616317 you said: > So I'm going to do the cowardly thing, and choose the third option, > which is to reassign this back to base, cc'ing debian-devel. I'm not > sure what the right thing is to do here, since honoring this feature > request would require making changes to multiple different packages: > initramfs-tools, all of the bootloaders, etc. Well, "base" is for users that do not know where to report complex bugs like this. This is a perfect case for package "general", for the reasons you described, so I am reassigning. Thanks for the useful input on this bug, very clarifying!. -- .''`. Hate's no fun if you keep it to yourself : :' : -- The life of David Gale `. `' `-Proudly running Debian GNU/Linux -- 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/20110508104135.GU3098@aenima
Re: New Packages generator
Hi again,
Cyril Brulebois (08/05/2011):
> is that a related breakage?
>
> [Can't debootstrap]
>
> Same happens with ftp{.fr,.uk,.de,}.debian.org; with i386 and amd64.
Also, ftp.ch.d.o exhibited the infamous Hash Sum mismatches for the
kfreebsd-i386 sid chroot on io.debian.net; switching to ftp.debian.org
doesn't help:
[sid chroot] io:~# apt-get update
Get:1 http://ftp.debian.org unstable InRelease [167 kB]
Get:2 http://ftp.debian.org unstable/main Sources [5632 kB]
Get:3 http://ftp.debian.org unstable/main kfreebsd-i386 Packages [6649 kB]
Get:4 http://ftp.debian.org unstable/main TranslationIndex [2264 B]
Get:5 http://ftp.debian.org unstable/main Translation-fr [596 kB]
Fetched 13.0 MB in 27s (475 kB/s)
W: Failed to fetch
bzip2:/var/lib/apt/lists/partial/ftp.debian.org_debian_dists_unstable_main_source_Sources
Hash Sum mismatch
W: Failed to fetch
bzip2:/var/lib/apt/lists/partial/ftp.debian.org_debian_dists_unstable_main_binary-kfreebsd-i386_Packages
Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones
used instead.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: New Packages generator
Hi,
Joerg Jaspert (07/05/2011):
> As we have received no notice of errors and as we also do not see
> anything bad ourself, I just activated the new generator for the
> archive. Starting with the next dinstall run in a few minutes all
> Packages and Sources files[2] will be generated using the new tool.
is that a related breakage?
$ sudo debootstrap --arch=i386 sid sid-32 http://ftp.debian.org/debian
I: Retrieving Release
I: Retrieving Release.gpg
I: Checking Release signature
I: Valid Release signature (key id 9FED2BCBDCD29CDF762678CBAED4B06F473041FA)
I: Retrieving Packages
I: Validating Packages
W: http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.bz2 was
corrupt
I: Retrieving Packages
I: Validating Packages
W: http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.gz was
corrupt
I: Retrieving Packages
E: Couldn't download dists/sid/main/binary-i386/Packages
Same happens with ftp{.fr,.uk,.de,}.debian.org; with i386 and amd64.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Software quality metrics in Debian?
Sounds like an extension of DACA: http://qa.debian.org/daca/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/BANLkTi==k+e2+ho-otm4apj06oggamp...@mail.gmail.com
Software quality metrics in Debian?
Hi,
I'd like to hear your opinions about an idea and propose a discussion about it
on Debconf:
a) Dream: Debian could publish quality metrics about the packaged software in
a machine readable format.
b) Software quality obviously is not strictly defined. There are metrics that
could automatically be measured, but the interpretation of the metrics is
still dependend on personal judgement.
c) Not only can the source code be measured but only the development process:
Does the project use a (distributed) VCS, Bugtracker, Continuous integration,
Test coverage, ...? The judgement of these facts is once again a matter of
personal assessment.
d) Many metrics are language specific. Every language team (Perl, Java, PHP,
Python, ...) could measure additional metrics or measure the adherence to best
practices or common coding styles. (See e.g. the book "effective java")
e) All these things should of course be voluntary. But with time people may
tend to prefer packages that have there software quality measurements
published.
f) It happens, that DDs argue against an ITP, because they don't like some
crappy software (personal judgement) to enter Debian. I for example would
prefer to purge all PHP and Ruby based software from history and destroy all
evidence that it ever existed.
However only with {agreed|objective|established} software quality metrics can
people argue about ITPs without reference to personal taste.
I already filled a BoF event about this topic for Debconf.
Thomas Koch, http://www.koch.ro
--
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/201105081009.16716.tho...@koch.ro
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, May 08, 2011 at 10:46:35AM +0900, Charles Plessy wrote:
> the 2008 GR invites to seek consensus, and in my opinion, what prove
> to be anti-consensual is to divide developers into formal categories.
> I have not seen such a vigourous opposition in the recent years to the
> idea of accepting non-packaging developers in Debian.
I'm happy to see that today the problem seems easy to solve to several
commenters and I'm sorry I haven't seen how easy it was to solve one
year ago or so: me, Enrico, DAM, DDs, we all have limits. Were it
possible, I'll be happy to offer a time machine so that we can go back
in time 3 years to solve it way more quickly than we did so that today
we would have had not 5 people in the pipe of non-packaging developers,
but 50 or 500. But given that is not possible, I would be happy if we
could stop discussing what today is just spilled milk, given that one
way or another this matter has been settled.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Best practice for cleaning autotools-generated files?
Enrico Weigelt writes: > * Henrique de Moraes Holschuh schrieb: > >> > I'm (as upstream) using serval macros in their own .m4 files (eg. >> > in ./m4/, maybe even sorted into subdirs). Can autoreconf figure >> > out the required search pathes all on its own ? >> >> The problem is that autoreconf offers NO command line options for you to >> pass the required -I parameters for aclocal, nor is there a way to encode >> that information in the one place where it could conveniently live >> (configure.ac) AFAIK. > > So, more precisely: autoreconf lacks an important feature would like > to see. I don't think this is the case -- others have already explained how to achieve the goals above. If you still believe something is missing in autoreconf, please report it to upstream so it can be fixed. /Simon -- 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/87sjsp643z@latte.josefsson.org
