Re: A concrete proposal for rolling implementation
Hi Teodor/Bruce, On Mon, May 09, 2011 at 05:48:25PM +0300, Teodor MICU wrote: > I've been disappointed at first to read that so many approve this > "rolling" implementation that in fact is just "c-u-t", constantly > usable testing [1]! Outside of the freeze period it doesn't really > matter and one can say rolling==cut. On Mon, May 09, 2011 at 11:36:04AM -0600, Bruce Sass wrote: > On May 9, 2011 08:48:25 am Teodor MICU wrote: > > To conclude, "unstable-next" suite (or some other name [2]) is a > > requirement for "rolling" [3]. > > ...unless the nature of experimental is changed, and its current function > replaced with PPA's? DEP-10 is focused entirely on how we can avoid and/or circumvent the freeze process (for things not concerning the next stable release), which is helpful by itself but also a key part of a working rolling release, I'd say. I'm trying to cover most of the ideas discussed in the previous mega-thread for how this could be done, including both of the "unstable-updates" and the "PPA's" approach, and maybe a couple more. I'm still putting meat onto the document but in the next couple days I'll bring it back on list for a more thorough discussion. So please keep any ideas you have about either of these approaches readily available :) sean -- 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/20110510055244.ga21...@cobija.connexer.com
Bug#626225: ITP: cmtk -- The Computational Morphometry Toolkit
Package: wnpp Severity: wishlist Owner: NeuroDebian Team * Package name: cmtk Version : 1.7.0 Upstream Author : Torsten Rohlfing * URL : http://www.nitrc.org/projects/cmtk/ * License : GPL-3+ Programming Lang: C++ Description : The Computational Morphometry Toolkit A software toolkit for computational morphometry of biomedical images, CMTK comprises a set of command line tools and a back-end general-purpose library for processing and I/O. . The command line tools primarily provide the following functionality: registration (affine and nonrigid; single and multi-channel; pairwise and groupwise), image correction (MR bias field estimation; interleaved image artifact correction), processing (filters; combination of segmentations via voting and STAPLE; shape-based averaging), statistics (t-tests; general linear regression). -- 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/20110510023932.5170.69169.report...@novo.onerussian.com
a few packages for adoption
** Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. ** I recently became a father of twins and, as such, have less time to work on packages than I used to. While I do plan on keeping some of my packages, there are others I'm interested in finding new maintainers for, if anyone is interested: * ICU: This is ICU4C. I sent another (lengthy) message about it. * xerces-c, xerces-c2: These are two versions of Xerces-C (http://xerces.apache.org). These are generally pretty low effort to maintain, and upstream is helpful and responsive. xerces-c2 is an older version that is no longer really being maintained, and backporting security fixes to it can be very hard, but so far, there hasn't been anything major. xerces-c is the 3.x series and is actively maintained upstream. Note that xerces-c2 has an orphaned reverse dependency (xalan), which you may occasionally need to NMU, though I think I only had to do that one time. * libxml-xerces-perl: This is a Xerces-p, a perl interface to Xerces-c. As far as I can tell, it is dead upstream, and there are better alternatives. At one time, it was the only perl module capable of doing XML validation with both DTD and schema support and with the capability of providing values for default attributes when doing validation, but I haven't actually tried to determine whether that's true for about six or seven years. If no one wants this, I may orphan it or request removal. * psutils: This is a collection of tools including psnup and ps2ps. They are pretty popular, but the project has been dead upstream for a while. psutils is part of all the major distributions, and we all have various patches. I put some effort into trying to synchronize with other distributions a while ago. Our psutils package includes a few other tools that are not strictly part of the upstream distribution, and every now and then, someone posts a bug report asking for some additional utility to be added. Some of the time, there's a licensing reason or some other reason why it won't work out (so you have to be careful when analyzing these requests), but every now and then it works out. I'll wait a few days to give people a chance to reply. For the xerces packages, I'd probably give preference to the debian SGML/XML group or to other groups maintaining stuff from apache. -- Jay Berkenbilt -- 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/20110509134418.322691.qww314159@motoko.argon.local
Re: A concrete proposal for rolling implementation
On May 9, 2011 08:48:25 am Teodor MICU wrote: > To conclude, "unstable-next" suite (or some other name [2]) is a > requirement for "rolling" [3]. > > Thanks > > [2] but not "experimental" ...unless the nature of experimental is changed, and its current function replaced with PPA's? - Bruce -- 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/201105091136.05627.bms...@shaw.ca
anyone interested in adopting ICU?
** Please reply to me directly (or CC me on replies) as I am not currently subscribed to debian-devel. ** I'm looking for someone who might like to take over the icu package. This is ICU4C (C/C++), not to be confused with ICU4J (Java), which is a separate package maintained by someone else. ICU is "International Components for Unicode". It is a robust, well-maintained project that is widely used and has corporate backing. In Debian, it has a few high-profile reverse dependencies including OpenOffice.org and Boost. If no one is interested in taking it over, I will continue to maintain it, but I don't have as much time right now to work on packages, and I actually don't use ICU anymore myself. I'll wait a few days before replying to messages about taking over ICU to give people time to reply. ICU is a relatively low-effort package to maintain, but there are a few things about it that are tricky. I would say you must be a C programmer (and preferably C++) to maintain these packages well. Some of the past debian ICU maintainers have actually been members of ICU's upstream development community. * ICU releases twice a year, and each release requires an soname bump, which means you have to coordinate a transition with the release team. The ICU project is very careful to preserve source compatibility, and I have the packages set up so that an automatic recompile is sufficient for pretty much all packages that depend on icu. However, I always coordinate with the openoffice team and stage new versions in experimental since sometimes new versions of ICU introduce new bugs or change behavior in a way that breaks openoffice. In fact, I skipped packaging 4.6 entirely because, with the freeze leading up to the release of squeeze, 4.8 would probably be out before the 4.6 transition could have completed. A 4.8 release candidate is expected on May 11. When it comes it out, it should be packaged for experimental. I could do this, or someone else could take over the package at that time. * It is high enough profile to have fairly regular security issues, though all in all, its security situation is pretty good as upstream stays on top of this. Because of the frequent updates, there are usually three versions of ICU that you have to worry about for security: oldstable, stable, and unstable. Sometimes you have to backport fairly complicated security fixes to an older version. I have often been able to take advantage of Red Hat's ICU packages for security fixes, though we don't always have the same patches applied or patches applied in the same order. Clever use of quilt has helped, but in at least one case, I had to spend a few hours fixing patches to backport a substantial security fix and be sure I got it right. Upstream will sometimes help with this if necessary. * On 64-bit platforms, ICU builds both 32-bit packages and 64-bit packages. There have been some problems (though none recently) that only appeared on 64-bit platforms. I would highly recommend that you have an amd64 system as your primary build platform if you maintain ICU. * ICU includes several optimizations that use assembly language or even directly generated object files containing only data. There have been instances in the past where some of debian's more obscure platforms have fooled ICU's build process and generated incorrect results. To fix this, you have to be able to understand how all the code generators used in ICU's build play together. I have originated a handful of patches that have kept ICU working on all of debian's platforms, and I have also worked with upstream to get patches created by debian porters into the main release. This hasn't been a problem for quite a while, but things like this happen every now and then. Upstream is very supportive. * Many of the bugs found in ICU only affect certain languages or language environments. Sometimes problems can be hard to reproduce, and unless you are familiar with the language that has the problem, you may not be in a position to evaluate whether a patch is correct. Sometimes the debian maintainer's job will end up being to act as an intermediary between an end user and upstream, though I guess is true of most packages. It can take a long time to get fixes in. I have had bug fixes take two years to get into an upstream stable release. This is because of how they target fixes, how they do pre-releases, etc. I have enjoyed maintaining ICU, and I think the debian ICU packages are in very good shape, so I am offering it up with some reluctance. If you think you have the skills to maintain this package in debian, please let me know if you'd like to take it over. In spite of the complexities, this is a relatively low-effort package to maintain. Sometimes I can go months without having to touch it at all, and other t
Re: Software quality metrics in Debian?
Thomas Koch dijo [Sun, May 08, 2011 at 10:09:16AM +0200]: > 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. Hi, I agree with b) - But there are some points that could be gathered and presented. As an example, in our package build process: How many packages are built running upstream's test suites? I know I have disabled them ocassionally because of hard-to-fix corner cases that were only biting me in the test suites themselves... Of course, that speaks horribly of me. Many authors, true, do not provide a test suite at all... So we could have a three(?)-state definition here: Runs-tests: (Yes|No|NotAvailable) Of course, even when available, what's the code coverage they offer? And even harder than that, what's the quality of the tests? That's much harder to guess... But having such a field (be it in d/control, be it anywhere else) could start leading us to one such metric. Yes, this can lead to a nice BoF :-) Greetings, -- 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/20110509164824.gb6...@gwolf.org
Bug#626179: ITP: letodms -- open-source document-management-system based on PHP and MySQL
Package: wnpp Severity: wishlist Owner: Francisco Manuel Garcia Claramonte * Package name: letodms Version : 3.0.0 Upstream Author : Uwe Steinmann Markus Westphal * URL : http://www.letodms.com/ * License : GPL Programming Lang: PHP Description : open-source document-management-system based on PHP and MySQL LetoDMS combines all these features with a nice-looking web-interface which makes it possible to access your documents not only via intranet in your office but worldwide via the internet. In detail LetoDMS offers you these features: * Upload files through web-interface * Create folders to group your documents * Edit document and folder properties online * Detailed information on uploaded documents * Lock and unlock documents * Update documents - old versions are saved * Individual Icons for different Mime-Types * Set expiration-date for documents * Users are notified about new/updated or expired documents via email * Download documents or view them online within your Browser * Control access via detailed ACLs (access control lists) * User- and Group-Management * Powerfule search-engine * Multi language support * Template-System * User can choose language and theme on login * Intuitive User-Interface * Should work with every Browser * Easy to install * Auto-conversion to HTML to view even MS Word-Documents online * Supports multiple databases through ADOdb -- 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/20110509163934.ga8...@debian.org
Re: Writing to /etc/ from a "privileged" UI
On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: > On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: > > > * David Paleino [110509 04:19]: > > > On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: > > > > > > > /etc may include only _static_ configuration. What you have is variable > > > > state which belongs in /var. It's no different from a database, or > > > > dpkg's > > > > status data. > > This isn't about whether the data saved in the config file is variable, > > it is about whether the config file is variable. Files in /etc should > > only be modified when the sysadmin is doing what (s)he considers to be > > "configuration", not when a user is running a program. > > So the CUPS web interface, and GNOME/KDE settings UIs, and such other things > are > all RC-buggy, because the info under /etc/ was not edited using > vim/nano/emacs/... but through a UI? CUPS: definitely. Most of its "configuration" is in reality persistent state which most certainly belongs under /var. This has been a major bug in CUPS since its inception. This includes all its queues, PPD files, and even dynamically updated parts of cupsd.conf. It definitely needs fixing, despite upstream's objection to that. Other admin tools may or may not be buggy (see below). There's a fuzzy area between "static configuration" (/etc) and "persistent state" (/var) [and there's also "ephemeral state" (/run)]. If it's generated by a program, it's most likely /not/ static. CUPS queue configuration is this type of data: on one hand one may create it by hand, but it can also be created and updated via lpadmin or via the web interface. The deciding factor for me here is that it also stores queue state in here--that makes it require /var. It could be split into static and dynamic parts split between /etc and /var, or just moved wholesale to /var. Static state is usually obvious stuff such as interfaces and port numbers to listen on. Dynamic state isn't always quite so obvious, but wireless AP info is certainly more on the "persistent state" side than static. It's still configuration, but it's not truly "static" configuration, and so it falls outside the remit of /etc. > I repeat myself: users capable of running a wicd ui are enabled by root, by > adding them to a specific system group (`netdev'). This is not relevant: /etc can not be considered to be writable by default, irrespective of the user/group making changes. > > The specific data shown in the bug report is clearly variable "state" > > information and not static configuration info, [..] > > but even adding and removing more permanent wireless access point info > > should > > not be done in /etc during the normal, continuous operation of a daemon. > d> Why not? It works. Read-only root is a goal we have had for a number of years. We'll actually be mostly there in the very near future with /run and mtab symlinking. Anything which writes to /etc during its normal operation is de facto broken and needs fixing (e.g. CUPS). Programs can not, and should not, expect to have a writable /etc under normal conditions. To clarify, programs such as editors and even custom tools to modify configuration are obviously needed to update configuration files under /etc. However, the admin may have been required to remount / read-write prior to using their tool-of-choice for making changes. Other than this usage, writing to /etc is bad practice. IMO it should be considered RC buggy for wheezy, and banned outright--it's fundamentally incompatible with a r/o rootfs. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 16:13:16 +0100, Jon Dowland wrote: > On Mon, May 09, 2011 at 11:29:07AM +0200, David Paleino wrote: > > On Mon, 9 May 2011 10:21:21 +0100, Simon McVittie wrote: > > > I seem to remember newer NM versions (in experimental) have changed the > > > default to be the other way round, on the basis that network connections > > > are system-wide, so their configuration should be system-wide too. > > > > That's what I tend to think as well. > > In the bugreport, I first thought about per-user configuration (something > > like ~/.config/wicd/...), but then I realised that it's non-sense, since > > network connections are system-wide AFAIK. > > OTOH, credentials supplied to connect to a network can be user data. Indeed, > having them as such means they can be protected (by using a keyring scheme > like gnome-keyring, for example). Also encrypted $HOME is more common than > encrypted /, I expect. Or just proper permissions to the user-config directory. :) (I'd avoid adding more dependencies to wicd) > "multi-user" and "concurrent use" are different things. If I loan my laptop > to my brother, we are not concurrently changing system-wide network state; > however, I may not want him to read my WPA passphrase and/or VPN connection > details out of a file in /etc. Ok, this makes sense. So I could change the UI so that it provides a "Save for all users" checkbox, that makes it save data to /etc/wicd/, otherwise the data would be saved to ~/.config/wicd/. I just submitted a bug to myself, so I remember to implement this :) Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: > On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: > > > * David Paleino [110509 04:19]: > > > On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: > > > > > > > /etc may include only _static_ configuration. What you have is variable > > > > state which belongs in /var. It's no different from a database, or > > > > dpkg's > > > > status data. > > > > > > Static IPs, DNS servers and WEP/WPA keys for a given wireless network are > > > "variable state"? Sorry, I disagree. > > > > > > I already said that I have a patch not to save networks for which no > > > configuration is made -- which is the "variable state" thing at the > > > moment. > > > The question was different :) > > > > This isn't about whether the data saved in the config file is variable, > > it is about whether the config file is variable. Files in /etc should > > only be modified when the sysadmin is doing what (s)he considers to be > > "configuration", not when a user is running a program. > > So the CUPS web interface, and GNOME/KDE settings UIs, and such other things > are > all RC-buggy, because the info under /etc/ was not edited using > vim/nano/emacs/... but through a UI? > > I repeat myself: users capable of running a wicd ui are enabled by root, by > adding them to a specific system group (`netdev'). You are right (I'd say). > > If I were designing the config structure, since each AP is a distinct > > entity that doesn't depend on any other AP (maybe that should be essid, > > not AP), I would have a .d directory where each essid had its own config > > file. There could be corresponding /etc/wicd/something.d and > > /var/lib/wicd/something.d directories. The admin could place files in > > /etc that he didn't want users messing with. Non-conflicting files in > > /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would > > be treated equally by wicd, with preference to ~user/.config/wicd then > > /var/lib/wicd, then /etc/wicd for any conflicting entries. > > > > Actually, one normal user should not be able to override the admin > > defaults for another user, so if there is already an entry in /etc, wicd > > should place any user change to that entry in ~user, but new, > > non-conflicting entries should go in /var/lib. Then, the order of > > preference should be ~user, /etc, /var/lib. > > I can't understand all this. Network connections are system-wide by their own > nature -- or do you know cases where there could be different concurrent > connections used by different users? No. What I like about (parts of) this solution is that /etc is kept a bit cleaner. For a few reasons (/etc being read-only, or being stored in a VCS) I like the idea of having /etc unmodified in normal circumstances. I completely agree with you that such data wicd stores has nothing to do in ~user. But the concept of two directories, one in /etc, one in /var, is something that appeals to me. The admin can still choose to copy files from /var over if he wants to keep them. If that really solves all use cases, I don't know. If it's the most practical approach, I don't know either. It's just something I'd like in wicd (if wicd then still works as well as it does now for me). > > Transient state information, like signal strength and quality should > > _not_ go in these files, but rather in /var/run/wicd/ (soon to be > > /run/wicd/). > > I probably haven't been clear enough. That's not configuration, and they > shouldn't go in any config file. And that's already fixed. > > > http://git.debian.org/?p=collab-maint/wicd.git;a=blob;f=debian/patches/34-dont_save_useless_config.patch > > There I drop 'quality', 'strength', 'bitrates' and 'has_profile' from the > configuration file. As stated before in this mail, that list could include > 'mode' and 'channel', but I prefer to be careful, since those are passed to > iwconfig. I like that anyways. Hauke -- .''`. Jan Hauke Rahmwww.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, May 09, 2011 at 11:29:07AM +0200, David Paleino wrote: > On Mon, 9 May 2011 10:21:21 +0100, Simon McVittie wrote: > > I seem to remember newer NM versions (in experimental) have changed the > > default to be the other way round, on the basis that network connections are > > system-wide, so their configuration should be system-wide too. > > That's what I tend to think as well. > In the bugreport, I first thought about per-user configuration (something like > ~/.config/wicd/...), but then I realised that it's non-sense, since network > connections are system-wide AFAIK. OTOH, credentials supplied to connect to a network can be user data. Indeed, having them as such means they can be protected (by using a keyring scheme like gnome-keyring, for example). Also encrypted $HOME is more common than encrypted /, I expect. "multi-user" and "concurrent use" are different things. If I loan my laptop to my brother, we are not concurrently changing system-wide network state; however, I may not want him to read my WPA passphrase and/or VPN connection details out of a file in /etc. -- Jon Dowland -- 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/20110509151316.ga10...@deckard.alcopop.org
Re: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: > * David Paleino [110509 04:19]: > > On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: > > > > > /etc may include only _static_ configuration. What you have is variable > > > state which belongs in /var. It's no different from a database, or dpkg's > > > status data. > > > > Static IPs, DNS servers and WEP/WPA keys for a given wireless network are > > "variable state"? Sorry, I disagree. > > > > I already said that I have a patch not to save networks for which no > > configuration is made -- which is the "variable state" thing at the moment. > > The question was different :) > > This isn't about whether the data saved in the config file is variable, > it is about whether the config file is variable. Files in /etc should > only be modified when the sysadmin is doing what (s)he considers to be > "configuration", not when a user is running a program. So the CUPS web interface, and GNOME/KDE settings UIs, and such other things are all RC-buggy, because the info under /etc/ was not edited using vim/nano/emacs/... but through a UI? I repeat myself: users capable of running a wicd ui are enabled by root, by adding them to a specific system group (`netdev'). > The specific data shown in the bug report is clearly variable "state" > information and not static configuration info, [..] Again, I disagree. BSSID, ESSID, encryption key, "automatic connection"-flag all sound like configuration to me. Granted, there are more things to purge (channel and mode, for example), but that's a bug with a different solution than "move everything to /var/". > but even adding and removing more permanent wireless access point info should > not be done in /etc during the normal, continuous operation of a daemon. Why not? It works. > If I were designing the config structure, since each AP is a distinct > entity that doesn't depend on any other AP (maybe that should be essid, > not AP), I would have a .d directory where each essid had its own config > file. There could be corresponding /etc/wicd/something.d and > /var/lib/wicd/something.d directories. The admin could place files in > /etc that he didn't want users messing with. Non-conflicting files in > /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would > be treated equally by wicd, with preference to ~user/.config/wicd then > /var/lib/wicd, then /etc/wicd for any conflicting entries. > > Actually, one normal user should not be able to override the admin > defaults for another user, so if there is already an entry in /etc, wicd > should place any user change to that entry in ~user, but new, > non-conflicting entries should go in /var/lib. Then, the order of > preference should be ~user, /etc, /var/lib. I can't understand all this. Network connections are system-wide by their own nature -- or do you know cases where there could be different concurrent connections used by different users? > Transient state information, like signal strength and quality should > _not_ go in these files, but rather in /var/run/wicd/ (soon to be > /run/wicd/). I probably haven't been clear enough. That's not configuration, and they shouldn't go in any config file. And that's already fixed. http://git.debian.org/?p=collab-maint/wicd.git;a=blob;f=debian/patches/34-dont_save_useless_config.patch There I drop 'quality', 'strength', 'bitrates' and 'has_profile' from the configuration file. As stated before in this mail, that list could include 'mode' and 'channel', but I prefer to be careful, since those are passed to iwconfig. Kindly, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6in wheezy as default?
> On 09/05/2011 12:51, Arnd Hannemann wrote: >> Hi, >> >> Am 09.05.2011 11:34, schrieb Vincent Danjean: >>> RFC 4941 is a problem if you want to use to use IPv6 and proxy NDP, >>> at least until the kernel allow to proxy a network instead of hosts. >>> This does not seem for now: >>> http://marc.info/?l=linux-kernel&m=130385156131530&w=2 >> >> But if anoyone has enough knowledge to setup proxy NDP he should >> be able to disable the privacy extension on its client hosts, too. > > It is not the problem of knowing how to do it. It is the problem of > doing it by default. And I do not have strong opinion on the > problem. For info, I setup privacy extension on my laptop but > I use a (Hurricane) IPv6 tunnel instead of using the /64 given > by my ISP. > >> Also, wouldn't using DHCPv6 solve this problem as well? > > DHCPv6 is useful when you do not want to you auto-configuration. > It can be the case if you would like several networks with > auto-configuration in a /64: DHCPv6 seems the only way to go in > this case. if you want only one subnetwork with autoconfiguration > and you have only a /64, you whould be able to create a correct > routing table on your firewall. > > It does not solve the proxy NDP (here, the problem is for the > ISP gateway that makes false assumption about the network layout, > not for the other host that can easily be instructed to have > a default route the the good host) > > I just realized that, perhaps, you want to says that privacy > extension is disabled when you are using DHCPv6 ? I did not > test it, so I do not know if this is right or not. Yes thats exactly what I wanted to say here: if the gateway requires control about the address assignment one probably should use DHCPv6 instead of relying on Stateless Autoconfiguration. >> Its really good to know that there exists such a problem with Privacy >> Extension >> and Linux gateways, but in IMO it shouldn't hinder the deployment >> of privacy extensions as default for for wheezy. > > An another problem is for firewalls that wants to do strict > controls (ie also filtering out-going connections). But here > again, there will be default rules for all client. Or, if > special rules are required for a client, the client can be > reconfigured to avoid using Privacy Extension. Yeah, or use DHCPv6 to have more control about address assignment. Best regards Arnd > PS: no need to CC me But please CC: me, I'm not (yet) on the list. -- 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/4dc7fc40.8080...@arndnet.de
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On Mon, 09 May 2011, Bjørn Mork wrote: > Henrique de Moraes Holschuh writes: > > We've been trying to avoid that kind of bad practice here in Brazil, > > through an effort to get ISPs to undertand you do NOT issue /64 to > > clients in the various NANOG-like (locally called "GTER") encounters > > throughout the year. > > > > It is an uphill battle. Time for an informational RFC, perhaps? It > > does help to point people at a RFC, where all technical arguments are > > fully written down and explained. > > Allocating /48, /56 or /64 for end users is not a technical discussion. > The arguments may be pseudo-techincal, but that's only an attempt to > obscure the the real issue: market segmentation. I assure you that is not what I heard from the big operators and not-so-big ISPs enabling experimental IPv6 access to their users. They did not want to 'waste IPv6' (IPv4-shortage-induced paranoia), and some were also worried that it would force users to have IPv6 routers if they got anything bigger than a /64, etc. Might not always be the case, obviously. But it often is IME. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110509145111.gc13...@khazad-dum.debian.net
Re: A concrete proposal for rolling implementation
2011/5/5 Raphael Hertzog : > On Thu, 05 May 2011, Stefano Zacchiroli wrote: >> Also, having the unstable-next suite you've mention would tight more the >> deployment of rolling to other project mechanisms, while the rest of the >> proposal enjoyed much more decoupling. > > There's no reason why this unstable-next would be a requirement to start > rolling. It's just a suggestion of how to handle package updates during > the freeze. I've been disappointed at first to read that so many approve this "rolling" implementation that in fact is just "c-u-t", constantly usable testing [1]! Outside of the freeze period it doesn't really matter and one can say rolling==cut. However, some key points added later with 'unstable-next' really completes the missing piece to call it "rolling"! During the freeze "unstable" is in a de facto freeze, but packages not suited for the next stable release in preparation could be uploaded to 'unstable-next'. The 'unstable-next' suite could be used for several purposes: 1) some packages could be picked from it for 'unstable' -> "testing" 2) all packages from "unstable-next" are a candidate for "rolling" 3) after the final stable release all packages could be moved directly from 'unstable-next' to 'unstable'. Although #3 might not be practical without other infrastructure changes, but was the core of this discussion in debian-devel. "rolling" has only derived from not freezing "unstable", but the initial proposal was to be able to never freeze unstable. It is my believe that by using the freeze time to upload packages as usual will help to prepare the next release by extending the pre-freeze development from 1.5 years to 2 years. To conclude, "unstable-next" suite (or some other name [2]) is a requirement for "rolling" [3]. Thanks [1] although the CUT team might have a different view for 'cut', I don't know what's the current direction [2] but not "experimental" [3] I agree with Raphael that is not a requirement to *start* "rolling" -- 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/banlktin3czqjafzsk1bsk6akd_w22yc...@mail.gmail.com
Re: Writing to /etc/ from a "privileged" UI
* David Paleino [110509 04:19]: > On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: > > > /etc may include only _static_ configuration. What you have is variable > > state which belongs in /var. It's no different from a database, or dpkg's > > status data. > > Static IPs, DNS servers and WEP/WPA keys for a given wireless network are > "variable state"? Sorry, I disagree. > > I already said that I have a patch not to save networks for which no > configuration is made -- which is the "variable state" thing at the moment. > The > question was different :) This isn't about whether the data saved in the config file is variable, it is about whether the config file is variable. Files in /etc should only be modified when the sysadmin is doing what (s)he considers to be "configuration", not when a user is running a program. The specific data shown in the bug report is clearly variable "state" information and not static configuration info, but even adding and removing more permanent wireless access point info should not be done in /etc during the normal, continuous operation of a daemon. If I were designing the config structure, since each AP is a distinct entity that doesn't depend on any other AP (maybe that should be essid, not AP), I would have a .d directory where each essid had its own config file. There could be corresponding /etc/wicd/something.d and /var/lib/wicd/something.d directories. The admin could place files in /etc that he didn't want users messing with. Non-conflicting files in /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would be treated equally by wicd, with preference to ~user/.config/wicd then /var/lib/wicd, then /etc/wicd for any conflicting entries. Actually, one normal user should not be able to override the admin defaults for another user, so if there is already an entry in /etc, wicd should place any user change to that entry in ~user, but new, non-conflicting entries should go in /var/lib. Then, the order of preference should be ~user, /etc, /var/lib. Transient state information, like signal strength and quality should _not_ go in these files, but rather in /var/run/wicd/ (soon to be /run/wicd/). ...Marvin -- 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/20110509134541.gb...@cleo.wdw
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Wed, May 04, 2011 at 12:40:47PM +0200, Goswin von Brederlow wrote: > Steve Langasek writes: > > On Mon, May 02, 2011 at 06:09:17PM +0200, Goswin von Brederlow wrote: > >> Also the libc6-msp430-dev:all and libc6-dev:msp430 packages will both be > >> using /usr/inlcude// and already trigger the problem you > >> fear. > > No, libc6-msp430-dev would use /usr//include as it does today. > mrvn@book:~% less /var/lib/dpkg/info/libc6-dev-i386.list | grep include > /usr/include > /usr/include/gnu > /usr/include/gnu/stubs-32.h > /usr/include/i486-linux-gnu > /usr/include/sys > /usr/include/sys/vm86.h > /usr/include/sys/elf.h > Aparently not. But maybe that is just the biarch packages. Yes, that only applies to biarch packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On Mon, May 09, 2011 at 12:51:30PM +0200, Arnd Hannemann wrote: > Also, wouldn't using DHCPv6 solve this problem as well? The way to go is DHCPv6-PD. Bastian -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, "The Squire of Gothos", stardate 2124.5 -- 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/20110509123436.ga4...@wavehammer.waldi.eu.org
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
Hi, Am 09.05.2011 11:34, schrieb Vincent Danjean: > On 08/05/2011 17:33, Martin Zobel-Helas wrote: >> i currently wonder if Debian should implement RFC 4941 as default for >> wheezy. > [...] >> I would like to hear other developers meanings to this issue, before >> proposing this as release goal for wheezy. > > RFC 4941 is a problem if you want to use to use IPv6 and proxy NDP, > at least until the kernel allow to proxy a network instead of hosts. > This does not seem for now: > http://marc.info/?l=linux-kernel&m=130385156131530&w=2 But if anoyone has enough knowledge to setup proxy NDP he should be able to disable the privacy extension on its client hosts, too. Also, wouldn't using DHCPv6 solve this problem as well? Its really good to know that there exists such a problem with Privacy Extension and Linux gateways, but in IMO it shouldn't hinder the deployment of privacy extensions as default for for wheezy. Best regards Arnd -- 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/4dc7c732.1020...@arndnet.de
Bug#626159: ITP: scilab-jims -- Binding the worlds of Scilab and Java
Package: wnpp Severity: wishlist Owner: Sylvestre Ledru * Package name: scilab-jims Version : 0.2 Upstream Author : Calite Denizet * URL : http://forge.scilab.org/index.php/p/JIMS/ * License : CeCILL Programming Lang: C, Java & Scilab Description : Binding the worlds of Scilab and Java From Scilab, JIMS allows the capability to load and manage Java objects from the Scilab interpreter. . Thanks to this module, Scilab can access to complex and advanced Java objects with Scilab classical data types. -- 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/20110509115021.9075.47268.report...@korcula.inria.fr
Re: 0-day NMUs for RC bugs without activity for 7 days?
Roberto C. Sánchez wrote: > So, my experience with #624819 was basically this. The bug was > reported, followed by an NMU upload about 45 minutes after the bug was > initially reported. Please don't misunderstand. I appreciate that the > submitter was proactive. However, emailing the patch first and giving > me a few days would have been nice. As the reporter+NMUer, let me apologize and try to explain my reasoning: I was in the process of uploading a new upstream release for PySide (including shiboken, which is libsparsehash-dev's only reverse build-dependency in the archive) and bumped on that issue, hence reported it (with a patch, applied by the upstream authors of shiboken; which revealed itself to be insufficient, but still). A side-reason for the speed of the NMU, was that I noted that the Maintainer of the package, "Athena Capital Research " hadn't proved to be very responsive to bug reports: http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=acr-debian%40athenacr.com But that was clearly not enough, and I shouldn't have taken that unresponsiveness for granted. > Since the NMUer made changes directly to the source files, I have to back > out the patch and convert it over to quilt (I use quilt on all my > packages). So, his helpfulness actually created more work. That criticism is unfair (although I understand it), as this package is not currently using quilt (nor is in 3.0 (quilt) format). AFAIK, adding new build-dependencies (quilt in this case) and/or adding/changing patch systems is usually considered a too big change for a NMU. But I can prepare the quilt patch for you if you want. > Another thing to note is that while the NMU was uploaded to DELAYED/2, > the upload was actually ACCEPTed about 24 hours after the upload. Yep, I was really too impatient on that case, and rescheduled it after one day. At the time, I considered it harmless, but at the light of your mail, it appears that I clearly overpassed the NMU rules; I am sorry for that (and be assured that it will not happen again). Cheers, OdyX -- 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/iq8iut$714$1...@dough.gmane.org
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On 09/05/2011 11:53, Henrique de Moraes Holschuh wrote: > On Mon, 09 May 2011, Vincent Danjean wrote: >> On 08/05/2011 17:33, Martin Zobel-Helas wrote: >> Note: proxy NDP is required when your provider gives you a flat /64 >> (ie its router is in your /64, generally prefix::1 and it tries to talk >> directly to any host of your /64 network) >> and you want to have subnetworks (one for wifi, one for your DMZ, ...) > > We've been trying to avoid that kind of bad practice here in Brazil, > through an effort to get ISPs to undertand you do NOT issue /64 to > clients in the various NANOG-like (locally called "GTER") encounters > throughout the year. > > It is an uphill battle. Time for an informational RFC, perhaps? It > does help to point people at a RFC, where all technical arguments are > fully written down and explained. Given the fact that the provider is the French ISP Free/Proxad (the one that invent the 6rd technique), I really doubt that this is not a deliberate choice on their part. But if anything can convince them to modify their practice, it would be a very good thing. Regards, Vincent PS: no need to CC me -- 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/4dc7cee8.5080...@free.fr
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On 09/05/2011 12:51, Arnd Hannemann wrote: > Hi, > > Am 09.05.2011 11:34, schrieb Vincent Danjean: >> RFC 4941 is a problem if you want to use to use IPv6 and proxy NDP, >> at least until the kernel allow to proxy a network instead of hosts. >> This does not seem for now: >> http://marc.info/?l=linux-kernel&m=130385156131530&w=2 > > But if anoyone has enough knowledge to setup proxy NDP he should > be able to disable the privacy extension on its client hosts, too. It is not the problem of knowing how to do it. It is the problem of doing it by default. And I do not have strong opinion on the problem. For info, I setup privacy extension on my laptop but I use a (Hurricane) IPv6 tunnel instead of using the /64 given by my ISP. > Also, wouldn't using DHCPv6 solve this problem as well? DHCPv6 is useful when you do not want to you auto-configuration. It can be the case if you would like several networks with auto-configuration in a /64: DHCPv6 seems the only way to go in this case. if you want only one subnetwork with autoconfiguration and you have only a /64, you whould be able to create a correct routing table on your firewall. It does not solve the proxy NDP (here, the problem is for the ISP gateway that makes false assumption about the network layout, not for the other host that can easily be instructed to have a default route the the good host) I just realized that, perhaps, you want to says that privacy extension is disabled when you are using DHCPv6 ? I did not test it, so I do not know if this is right or not. > Its really good to know that there exists such a problem with Privacy > Extension > and Linux gateways, but in IMO it shouldn't hinder the deployment > of privacy extensions as default for for wheezy. An another problem is for firewalls that wants to do strict controls (ie also filtering out-going connections). But here again, there will be default rules for all client. Or, if special rules are required for a client, the client can be reconfigured to avoid using Privacy Extension. But I repeat, I just want to talk about these issues. I'm not convinced myself they should block privacy extensions enabled by default. Regards, Vincent > Best regards > Arnd > PS: no need to CC me -- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann Email: vincent.danj...@imag.fr 38330 Montbonnot Saint Martin -- 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/4dc7cdc7.6030...@free.fr
Re: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 11:55:39 +0200, Jan Hauke Rahm wrote: > Aside from privileges wicd needs or has to write in /etc, how does it > handle read-only / (including /etc)? Does it fall back to /var? No. I haven't tried, but it should be able to connect without a writable /(etc) (it already uses /var/lib/wicd/ to store runtime config): network configuration will "just" be lost on wicd-daemon shutdown. Still, I'll need to confirm this (maybe it'll throw an exception when trying to write the config files), and eventually fix it to support at least this behaviour. Is there some document I should be reading? :) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
On Sat, May 07, 2011 at 10:43:29PM -0400, Ted Ts'o wrote: > This isn't a bug in e2fsprogs; e2fsprogs has absolutely nothing to do > with mounting the file system. > > Debian simply doesn't support the mount options for the root file > system in /etc/fstab having any effect on how the root file system is > mounted. The root file system is mounted by the kernel, and the mount > options used by the kernel are specified by the rootflags= option on > the kernel's boot command line. > > Should we try to make this work (at best badly) since a change in > mount options in /etc/fstab would only take effect at the next > mkinitramfs and/or update-grub invocation? Or should we just close > out this bug and say, "tough luck, kid; if you want to change the root > file system's mount options, you need to edit your kernel's boot > options using whatever bootloader you might happen to be using"? It is really annoying to have to edit the same thing twice and face boot failures if you forgot that. There are legitimate reasons you might want to change boot options often. Would it be possible to ask the kernel what root fs options it received? The line in fstab could then be changed to include only options that change, without having to redundantly specify device, fs type, subvolume and the like. Rationale: as you said, there are so many ways to configure kernel's command line, the source for kernel's configuration might even be not present on the system at all. Trying to update that configuration from /etc/fstab seems to be impossible, but going the other way around seems relatively easy. With /etc/fstab no longer having authoritative data for the root fs, one would have to change fsck and mount, but since there are few consumers of /etc/fstab, that's not a show stopper. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, May 09, 2011 at 09:39:07AM +0200, David Paleino wrote: > Hello everybody, > I'm writing this mail to gather comments about a serious bug I received some > time ago, for which I haven't yet had time to make a proper fix. The bug is > #612918, against wicd, "Uses /etc/wicd/wireless-settings.conf as state file". > > My opinion is that wireless networks with some kind of configuration provided > (say, a key, or a DNS server, or some static IP, [..]), should be saved there > (so the bug really is: «don't uselessly save all the networks you encounter» > -- and I already have a fix for that). > > The reporter's opinion is that no GUI should ever write to /etc/. > > However, WICD clients are run from privileged users, i.e. those in the > `netdev' > group, and are added there by root. So I think that's perfectly fine. Aside from privileges wicd needs or has to write in /etc, how does it handle read-only / (including /etc)? Does it fall back to /var? Hauke -- .''`. Jan Hauke Rahmwww.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On Mon, 09 May 2011, Vincent Danjean wrote: > On 08/05/2011 17:33, Martin Zobel-Helas wrote: > > i currently wonder if Debian should implement RFC 4941 as default for > > wheezy. > [...] > > I would like to hear other developers meanings to this issue, before > > proposing this as release goal for wheezy. > > RFC 4941 is a problem if you want to use to use IPv6 and proxy NDP, > at least until the kernel allow to proxy a network instead of hosts. > This does not seem for now: > http://marc.info/?l=linux-kernel&m=130385156131530&w=2 > > > Note: proxy NDP is required when your provider gives you a flat /64 > (ie its router is in your /64, generally prefix::1 and it tries to talk > directly to any host of your /64 network) > and you want to have subnetworks (one for wifi, one for your DMZ, ...) We've been trying to avoid that kind of bad practice here in Brazil, through an effort to get ISPs to undertand you do NOT issue /64 to clients in the various NANOG-like (locally called "GTER") encounters throughout the year. It is an uphill battle. Time for an informational RFC, perhaps? It does help to point people at a RFC, where all technical arguments are fully written down and explained. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110509095317.ga21...@khazad-dum.debian.net
Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?
On 08/05/2011 17:33, Martin Zobel-Helas wrote: > i currently wonder if Debian should implement RFC 4941 as default for > wheezy. [...] > I would like to hear other developers meanings to this issue, before > proposing this as release goal for wheezy. RFC 4941 is a problem if you want to use to use IPv6 and proxy NDP, at least until the kernel allow to proxy a network instead of hosts. This does not seem for now: http://marc.info/?l=linux-kernel&m=130385156131530&w=2 Note: proxy NDP is required when your provider gives you a flat /64 (ie its router is in your /64, generally prefix::1 and it tries to talk directly to any host of your /64 network) and you want to have subnetworks (one for wifi, one for your DMZ, ...) Regards, Vincent > > > Cheers, > Martin -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/4dc7b53c.9010...@free.fr
Re: OK, Re: need a server for debdelta repository
Il 03/05/2011 18:44, Stefano Zacchiroli ha scritto: > Out of curiosity, and given http://debdelta.debian.net has been around > for a long while now and is used (according to my exchanges with you) > regularly, do you have a plan for integration into debian.*org* proper? > I would like to. But so far no effective plans. > In principle, it looks like a very useful service to users than they > should be able to enable triggering a switch into APT. Is there any > document describing that possibility, its drawbacks, showstoppers and, > more generally, the way forward? I am writing documentation, it is at http://debdelta.debian.net/html/index.html (it is still work in progress); I just added a section 3.9 that may be of interest; I sent an email debian-dak@l.d.o . There will also be a session at https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-debdelta/ it is currently scheduled Tuesday, 12:00 CEST a. signature.asc Description: OpenPGP digital signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 10:21:21 +0100, Simon McVittie wrote: > On Mon, 09 May 2011 at 09:39:07 +0200, David Paleino wrote: > > I took a look at how NetworkManager handles that: it stores configuration > > using gconf, so it's not really comparable > > NM can go either way - it'll use the current user's gconf for connections > that are not "shared with other users", which is the default, or flat files > in /etc for connections that are shared. > > I seem to remember newer NM versions (in experimental) have changed the > default to be the other way round, on the basis that network connections are > system-wide, so their configuration should be system-wide too. That's what I tend to think as well. In the bugreport, I first thought about per-user configuration (something like ~/.config/wicd/...), but then I realised that it's non-sense, since network connections are system-wide AFAIK. David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, 09 May 2011 at 09:39:07 +0200, David Paleino wrote: > I took a look at how NetworkManager handles that: it stores configuration > using > gconf, so it's not really comparable NM can go either way - it'll use the current user's gconf for connections that are not "shared with other users", which is the default, or flat files in /etc for connections that are shared. I seem to remember newer NM versions (in experimental) have changed the default to be the other way round, on the basis that network connections are system-wide, so their configuration should be system-wide too. S -- 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/20110509092121.gb28...@reptile.pseudorandom.co.uk
Re: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: > /etc may include only _static_ configuration. What you have is variable > state which belongs in /var. It's no different from a database, or dpkg's > status data. Static IPs, DNS servers and WEP/WPA keys for a given wireless network are "variable state"? Sorry, I disagree. I already said that I have a patch not to save networks for which no configuration is made -- which is the "variable state" thing at the moment. The question was different :) David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Writing to /etc/ from a "privileged" UI
On Mon, May 09, 2011 at 09:39:07AM +0200, David Paleino wrote: > Hello everybody, > I'm writing this mail to gather comments about a serious bug I received some > time ago, for which I haven't yet had time to make a proper fix. The bug is > #612918, against wicd, "Uses /etc/wicd/wireless-settings.conf as state file". > > My opinion is that wireless networks with some kind of configuration provided > (say, a key, or a DNS server, or some static IP, [..]), should be saved there > (so the bug really is: «don't uselessly save all the networks you encounter» > -- and I already have a fix for that). > > The reporter's opinion is that no GUI should ever write to /etc/. > > However, WICD clients are run from privileged users, i.e. those in the > `netdev' > group, and are added there by root. So I think that's perfectly fine. > > I took a look at how NetworkManager handles that: it stores configuration > using > gconf, so it's not really comparable. I'd like to stick with files under > /etc/, > possibly. > > What's your opinion on this? > I haven't searched thoroughly through the archive, but I guess there are other > UIs run by privileged non-root users that write to /etc/? /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110509091253.ga7...@angband.pl
Re: 0-day NMUs for RC bugs without activity for 7 days?
On Saturday 07 May 2011 15:14:59 Raphael Hertzog wrote: > Hi, > > On Sat, 07 May 2011, Jakub Wilk wrote: > > This works both ways. If a NMUer uploaded my package without a delay > > and without a good reason[0], I want to be able to yell at him „you > > are a jerk (according to Developers Reference)!” > > No. > > First off, I never said that the rules are there to be able to badmouth > people. So calling someone a jerk is never a good idea. You better stop twisting the context and artificially "teach good manners", this is so much demotivating! You can't be serious believing Jakub will call someone a jerk, and I seriously doubt badmouthing was his main point. Let me decypher the message for you as you seem unable to -- the fear is whether more RC bugs would be introduced while being *careful* to fix one via NMU. I don't share Jakub's fears to a great extend, to be honest. -- pub 4096R/0E4BD0AB -- 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/201105091042.56086.danc...@spnet.net
Re: Best practice for cleaning autotools-generated files?
]] Enrico Weigelt | 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. What's wrong with the suggestion in http://lists.debian.org/debian-devel/2011/05/msg00442.html ? If that doesn't work, that sounds like a bug in autoconf. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87r588tj6h@qurzaw.varnish-software.com
Re: Writing to /etc/ from a "privileged" UI
On Mon, 9 May 2011 09:39:07 +0200, David Paleino wrote: > ... Gah, I clicked "Reply" instead of "Compose". Sorry everybody. -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Writing to /etc/ from a "privileged" UI
Hello everybody, I'm writing this mail to gather comments about a serious bug I received some time ago, for which I haven't yet had time to make a proper fix. The bug is #612918, against wicd, "Uses /etc/wicd/wireless-settings.conf as state file". My opinion is that wireless networks with some kind of configuration provided (say, a key, or a DNS server, or some static IP, [..]), should be saved there (so the bug really is: «don't uselessly save all the networks you encounter» -- and I already have a fix for that). The reporter's opinion is that no GUI should ever write to /etc/. However, WICD clients are run from privileged users, i.e. those in the `netdev' group, and are added there by root. So I think that's perfectly fine. I took a look at how NetworkManager handles that: it stores configuration using gconf, so it's not really comparable. I'd like to stick with files under /etc/, possibly. What's your opinion on this? I haven't searched thoroughly through the archive, but I guess there are other UIs run by privileged non-root users that write to /etc/? Didier, I hope I correctly summarised the bug you reported. If not, please reply :) Thanks for your suggestions, David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: New Packages generator
>> 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/debianI:
> 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.
It wasn't. Entire different area did this.
Well. We now have a function RIGHT before the mirrorpush goes out that
does a has sum check using the InRelease files before we send the
push. Instead of assuming that noone might ever change the files between
the "rsync into public place" and "now push the mirrors".
Should help against those errors.
--
bye, Joerg
Ganneff: NM-queue ist das schnellste zu uploadrechten für ein paket,
oder?
ach aqua^Wribnitz
--
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/87d3jspbuw@gkar.ganneff.de
