Re: support for merged /usr in Debian
On 14173 March 1977, Ian Jackson wrote: >> Is there any use case that requires supporting unmerged systems? > Someone has already mentioned mounting /usr ro. But one generally has > to keep /etc rw. I don't think that the right way to address this is > to make /etc a mount point. No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log storage and the user homes, as well as a tmp filesystem rw, rest ro. Works nicely, I have 4 of such systems running. Yes, updates are a bit annoying (especially as those systems also disallow any further rw mounts after boot), as they include reboots or remounts, depending on if you block further remounts or not. But thats a minor thing. -- bye, Joerg But Marge, what if we chose the wrong religion? Each week we just make God madder and madder.
Bug#809664: ITP: seelablet -- software for the SEELablet experiment box
Package: wnpp Severity: wishlist Owner: Georges Khaznadar * Package name: seelablet Version : 0.1.9 Upstream Author : Jithin B.P. * URL : https://github.com/jithinbp/SEELablet * License : GPL-3+ Programming Lang: Python Description : software for the SEELablet experiment box SEELablet is a hardware & software framework for developing science experiments, demonstrations and projects and learn science and engineering by exploration. Capable of doing real time measurements and analysing the data in different ways. Analog voltages are measured with 0.025% resolution and time intervals with one microsecond. This project is based on Free and Open Source software, mostly written in Python programming language. The hardware design is also open.
Re: support for merged /usr in Debian
On Jan 02, Joerg Jaspert wrote: > No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log > storage and the user homes, as well as a tmp filesystem rw, rest ro. > Works nicely, I have 4 of such systems running. Just to be clear: on a merged /usr system nothing prevents you from having /home and /var on standalone file systems and keeping the root file system (eventually with /usr on it) read only. It is a totally orthogonal choice and it is not related to this discussion. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Jan 01, 2016 at 03:53:03PM +0100, Marco d'Itri wrote:
> On Jan 01, Ian Jackson wrote:
>
> > Someone has already mentioned mounting /usr ro. But one generally has
> > to keep /etc rw. I don't think that the right way to address this is
> > to make /etc a mount point.
> I am not aware of any plan to make /etc a mount point, which indeed
> would pointless.
> On a merged /usr system the root file system only contains /boot, /etc,
> /var and /home while the OS proper is all in /usr.
>
> > Anotheer example: I have a system which does a rather hackish NFS root
> > boot. It has its own / but uses /usr from the fileserver. This has
> > worked surprisingly well for a long time.
> With a merged /usr you would be able to serve the whole OS over NFS (and
> even share it among multiple systems without the constant threat of
> having / and /usr diverge) and only configuration + data from the local
> disk, which makes this kind of setup much more useful.
"whole OS over NFS" is the same as "whole OS on /usr"
A design with "whole OS over NFS" breaks the good pratice of having
A design with "whole OS on /usr" breaks the good pratice of having
tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable.
To me is this "TheUsrMerge" something like among
* "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
* "there was a question about /bin/kill and /usr/bin/killall being inconsequent"
* "we could not agree if p{erl,ython,hp} should in /bin or in /usr/bin"
* "when calling `foo` we rely on $PATH. To avoid $PATH we call `/bin/foo`,
to have a reason to rant it should be /usr/bin/foo"
* "reverting a historic decission is much better then accepting a historic
decission"
* "just because we can"
* "others doing also"
In other words: I don't yet see a _good_ reason for "TheUsrMerge".
And I think that it is ill-named,
it should be named "PutAllExecutablesInRootFS" :-)
And the "PutAllExecutablesInRootFS" is
in fact "put all executables in a single file system".
That makes it harder to split out executables in different file systems.
(having a mechanisme for executables in different places,
makes it easy to add another place)
I mean that executables will be in different places. ( ramdisks, netwerk disks
/usr/local /opt )
Groeten
Geert Stappers
- --
Leven en laten leven
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJWiAv1AAoJECE10SPYwZvsksgQAIbp0VeOgxTJHcy5+34v8Qk/
3gnwag2Rh6qLCIZ/ag+sO1EDdp/ja0af8XSOxln4p7EnPzgsVRUBA9QIG8ebRn7Z
gdOMk4oTEdBb3i4XcZ0oSjjwsZAYt6aGcjEsYpQlRjexdP7r8ZF+8PMqJ4sfY98C
MumzBvJjBcf3J9Pt3XlyV4AGh5AZt/Ku9sDu6BezeVYd0yo9/TLE+V/9a3MBuve7
p2LaGIQ81XlHpIMbghwrbObu8caKNnk7mBcOUOXSGJBr+7PEOlE5GU+HsmC9ZV49
9FQW+j35x0y2cRSxkOZFgPX4VneXH7VMN1Cpn57gGurZEbWwmvHHLqrfnRN+bOc8
lCRDh8szm/jsMapnQhXClcAb3RsPpOfb4lQ5n8owSqJAGfEezfNyEwcjGlMEJg6l
y/kno8S+vfilJTelQ0EsV8x/DCW7RsofC7mUjxQ5nfxzi+BsFbCRbmywCRBsz9/v
b8eYVYsx0rbgh/L0ZfXpqJBlyLjcNrtUlCiY91IGX4faxp1xcHBVD9feQeIC5lfS
LrUezPTZ3bXjPGo3nGFugkCRflWHx+exmFwDaQXaLP5FNu9+Vv3ufna+P/khHxms
Z93Pn6dDFamNNooa2DbJQxmmZeXMeEw74YLGwQ9fxJXeC5Ntt9cvBeevYs5iZfWU
csniUjI3remGk2HdtCa2
=pc0X
-END PGP SIGNATURE-
Re: support for merged /usr in Debian
On Jan 02, Geert Stappers wrote: > A design with "whole OS on /usr" breaks the good pratice of having > tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable. This is not a good practice but just an historical accident: for details see http://lists.busybox.net/pipermail/busybox/2010-December/074114.html . grml-rescueboot is way more useful for rescue purposes. > In other words: I don't yet see a _good_ reason for "TheUsrMerge". Many have been discussed. -- ciao, Marco signature.asc Description: PGP signature
Re: Renaming the Debian Project
You are either playing an artificial character or you are simply not very good at reading people and interpreting text. I hope you find more constructive things to do in the future. I hope you find happiness and love. Thank you Ian, for initiating this great community. Your legacy will not be forgotten. pgp8o8DPn3Nwt.pgp Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On Sat, 2 Jan 2016 19:00:17 +0100, m...@linux.it (Marco d'Itri) wrote: >On Jan 02, Geert Stappers wrote: >> A design with "whole OS on /usr" breaks the good pratice of having >> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable. >This is not a good practice but just an historical accident: for details >see http://lists.busybox.net/pipermail/busybox/2010-December/074114.html . >grml-rescueboot is way more useful for rescue purposes. Show me how to do that on arm. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Sat, 2 Jan 2016 18:42:14 +0100, Geert Stappers
wrote:
>To me is this "TheUsrMerge" something like among
>* "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
>* "there was a question about /bin/kill and /usr/bin/killall being
>inconsequent"
>* "we could not agree if p{erl,ython,hp} should in /bin or in /usr/bin"
>* "when calling `foo` we rely on $PATH. To avoid $PATH we call `/bin/foo`,
> to have a reason to rant it should be /usr/bin/foo"
>* "reverting a historic decission is much better then accepting a historic
>decission"
>* "just because we can"
>* "others doing also"
Amen.
>In other words: I don't yet see a _good_ reason for "TheUsrMerge".
Seconded.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Sat, 2 Jan 2016 18:25:21 +0100, m...@linux.it (Marco d'Itri) wrote: >On Jan 02, Joerg Jaspert wrote: >> No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log >> storage and the user homes, as well as a tmp filesystem rw, rest ro. >> Works nicely, I have 4 of such systems running. >Just to be clear: on a merged /usr system nothing prevents you from >having /home and /var on standalone file systems and keeping the root >file system (eventually with /usr on it) read only. What is the "upgrade path" for an older system that has /usr split off? Will it just stop being bootable after upgrading? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Jan 02, Marc Haber wrote: > What is the "upgrade path" for an older system that has /usr split > off? Will it just stop being bootable after upgrading? It just needs to use an initramfs. A standalone /usr without an initramfs IS ALREADY NOT SUPPORTED by systemd. This is not relevant for merged /usr. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
Am 02.01.2016 um 22:08 schrieb Marc Haber:
> On Sat, 2 Jan 2016 18:42:14 +0100, Geert Stappers
> wrote:
>> To me is this "TheUsrMerge" something like among
>> * "it is hard too to explain to have /sbin/fsck and not /usr/sbin/fsck"
>> * "there was a question about /bin/kill and /usr/bin/killall being
>> inconsequent"
>> * "we could not agree if p{erl,ython,hp} should in /bin or in /usr/bin"
>> * "when calling `foo` we rely on $PATH. To avoid $PATH we call `/bin/foo`,
>> to have a reason to rant it should be /usr/bin/foo"
>> * "reverting a historic decission is much better then accepting a historic
>> decission"
>> * "just because we can"
>> * "others doing also"
>
> Amen.
>
>> In other words: I don't yet see a _good_ reason for "TheUsrMerge".
>
> Seconded.
>
I see a lot of good reasons for "TheUsrMerge".
So thanks for pushing for this.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On 03/01/16 07:00, Marco d'Itri wrote: > On Jan 02, Geert Stappers wrote: > >> A design with "whole OS on /usr" breaks the good pratice of having >> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable. > This is not a good practice but just an historical accident: for details > see http://lists.busybox.net/pipermail/busybox/2010-December/074114.html . > grml-rescueboot is way more useful for rescue purposes. Perhaps you should read the rest of that thread.. > >> In other words: I don't yet see a _good_ reason for "TheUsrMerge". > Many have been discussed. And none of them stand up to scrutiny imho. Just because Lennart Poettering and Kay Seivers say so is not a valid reason. Neither does publishing an opinion piece on freedesktop.org FWIW. Because Solaris has done it is no reason to do so either Because systemd doesn't work without /usr on the root partition isn't a good reason either. That just means systemd is broken by design and needs to be fixed. Just because the separation occured way back in time, doesn't mean that it isn't still useful or beneficial for some or indeed many use cases. What I'd like to know is what are the real use cases where a merged /usr is absolutely required (- where it isn't the result of a lazy and unprofessional attitude of dis-respecting the environment that exists and ignorance of the hard learned lessons of long ago.)? -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On 3 January 2016 at 00:25, Daniel Reurich wrote: > On 03/01/16 07:00, Marco d'Itri wrote: >> On Jan 02, Geert Stappers wrote: >> >>> A design with "whole OS on /usr" breaks the good pratice of having >>> tools like /bin/mount and /sbin/ifconfig available when /usr is unavailable. >> This is not a good practice but just an historical accident: for details >> see http://lists.busybox.net/pipermail/busybox/2010-December/074114.html . >> grml-rescueboot is way more useful for rescue purposes. > > Perhaps you should read the rest of that thread.. >> >>> In other words: I don't yet see a _good_ reason for "TheUsrMerge". >> Many have been discussed. > > And none of them stand up to scrutiny imho. > > Just because Lennart Poettering and Kay Seivers say so is not a valid > reason. Neither does publishing an opinion piece on freedesktop.org FWIW. > > Because Solaris has done it is no reason to do so either > > Because systemd doesn't work without /usr on the root partition isn't a > good reason either. That just means systemd is broken by design and > needs to be fixed. > > Just because the separation occured way back in time, doesn't mean that > it isn't still useful or beneficial for some or indeed many use cases. > > What I'd like to know is what are the real use cases where a merged /usr > is absolutely required (- where it isn't the result of a lazy and > unprofessional attitude of dis-respecting the environment that exists > and ignorance of the hard learned lessons of long ago.)? > > > -- > Daniel Reurich > Centurion Computer Technology (2005) Ltd. > 021 797 722 > This "UseMerge" just brings more insanity into Debian. What is wrong with you guys?! For God's sake... --- It violates the FHS 2.3 standards. http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html --- Also, if you guys (Debian) reeeally wants to move everything to /usr, so, there is no reason for any symbolic links at the root file system. I am 100% against this insanity. Again, If Debian wants to do that, then, do NOT create any symlink on the root file system. Do not bring CentOS shit to our shiny distribution. Those symlinks: "/bin -> /usr/bin" "/sbin -> /usr/sbin" "/lib -> /usr/lib" "/lib64 -> /usr/lib64" Looks very, very unprofessional. It looks like a huge workaround, created to deal with something that you broke for no reason. One more time, if things are going to be moved to /usr, then, there is no reason for ugly symlinks at the root file system. I vote against "UsrMerge". But, if Debian wants it, do it right, without symlinks (i.e., workarounds). Otherwise, do not touch this and go away. Best, Thiago
Re: support for merged /usr in Debian
On Sun, Jan 03, 2016 at 01:23:14AM -0200, Martinx - ジェームズ wrote: > It violates the FHS 2.3 standards. > > http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html Can you cite the requirement in FHS 2.3 which is violated by usrmerge. I only found the requirements that allow us to do usrmerge via symbolic link. For example: http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#Requirements The following directories, or symbolic links to directories, are required in /. > Also, if you guys (Debian) reeeally wants to move everything to > /usr, so, there is no reason for any symbolic links at the root file > system. Symbolic links at the root file system is required by FHS 2.3. Removing them will violate it. -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: PGP signature
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
Alexander Wirt writes: >> This should be integrated in the backports.d.o repositories. > Backports is not for fixing bugs in stable. I think there is a misunderstanding here. This is not about fixing unison in stable. "unison" 2.40.102-2 in stable works fine. It is not broken. There is nothing to fix. It works fine when talking to other stable servers. The package called "unison2.40.102" version 2.40.102-3+b1 in testing and unstable is broken. This broken package is not in stable. If it can't get fixed, it probably should get removed. The most recent "unison" package, version 2.48.3-1 in testing and unstable is not broken. Unfortunately it is not compatable with the version in stable. This is about letting stable users use the latest bleeding each version so that they can have compatability with unison 2.48 in unstable which is not broken. Which I believe is inline with what backports is for. -- Brian May
Bug#809704: ITP: libhtml5parser-java -- validator.nu HTML parser implementation in Java
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: libhtml5parser-java Version : 1.4 Upstream Author : Henri Sivonen * URL : https://about.validator.nu/htmlparser/ * License : Expat, BSD-3-clause, GPL-2+, MPL-1.1, LGPL-2.1+, LGPL-3+ Programming Lang: Java Description : validator.nu HTML parser implementation in Java The Validator.nu HTML Parser is an implementation of the HTML5 parsing algorithm in Java for applications. The parser is designed to work as a drop-in replacement for the XML parser in applications that already support XHTML 1.x content with an XML parser and use SAX, DOM or XOM to interface with the parser. This package will be maintained within the Debian Java Team. It is a prerequisite to fix https://bugs.debian.org/809256
Bug#809705: general: let people use non-free software but opt-out of non-open software
Package: general Severity: wishlist Tags: security Hi. I think Debian has the following two problems (or rather its security conscious users) with respect to software that gets into the system: First, more and more packages install software which sneaks around the package manager (and thus typically around any security support from Debian) by downloading further code, plugins and so on. Examples include programms like firefox, thunderbird (both, the add-ons and bad things like silent/automatic downloaded blobs as OpenH264, even though the later has been disabled in Debian :-) ) but also many others like josm, picard or ruby gems integration. For the user it's not really visible when he crosses the line where such plugins are simply proper Debian packages and where he gets binaries or other code from 3rd parties, which are out of any security support proper, and possibly even compromised. Unfortunately, doing something about this wouldn't be very easy, because it would require patching all these packages :-( Second, there is a growing number of packages, for which no sources are available (not talking about the Debian source package, but the sources from the software). Examples include, steam, firmware packages and so on. This software is, for policy reasons, in non-free. Many non-free packages have however their sources available and are for other reasons in non-free. One may not be happy about them not being DFSG compatible, but at least one can read their code and check for any backdoors or security holes. Examples include many documentation packages in non-free or software like unrar. I can understand that for some packages (typically the firmware packages) there is no alternative to having them - but I don't quite understand why Debian needs to ship packages (e.g. like steam) which is by no means necessary and install code into the system that's not only incompatible with the ideas of FLOSS but also not auditable. Of course there are people who wand to have these packaged and maintainers who are doing some good work on them, so maybe there can be a solution that fits both sides' needs: Why not adding another section which is so to say even "worse" than non-free, e.g. call it non-open (or some better name). This would contain any packages that contain anything (i.e. software) for which there are no sources, while anything else, where software is available that's just not DFSG compatbile, would remain in non-free. A policy change should enforce that of course. The benefit of this would be that it's far easier for users to rule out any non-open software, but still continue to use "just non-free" packages, which aren't perfect from their licensing but cannot contain anything evil (or at least one could find it in the code). With e.g. apt_preferences, one could still selectively allow certain such closed-source packages, e.g. firmware packages. Thanks in advance for your consideration. Sincerely, Philippe
Bug#809705: general: let people use non-free software but opt-out of non-open software
Quoting Philippe Cerfon (philc...@gmail.com): > Package: general > Severity: wishlist > Tags: security > > Hi. > > I think Debian has the following two problems (or rather its security > conscious users) with respect to software that gets into the system: No idea whether what you're proposing is relevant or notbut there's something I'm deeply sure of : that won't be solved through a "general" bug report. Such vague bug reports are usually either quickly closedor just ignored by everybody in the project. Discussing infrastructure changes like what you're proposing (which I have no advice about) should usually be done through our mailing lists, get some kind of agreement, include some implementation in key packages, and get enough consensus among developers to draw the needed changes in the infranstructure (in this case, our software repositories, at minimum). So, zero chances that this happens through a (soon to be forgotten) bug report. No offense, but that's reality. signature.asc Description: PGP signature
