Bug#1015926: ITP: persalys -- GUI for uncertainty treatment and variabilities management
Package: wnpp Severity: wishlist Owner: Pierre Gruet User: debian-scie...@lists.debian.org Usertags: field..science X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: persalys Version : 12.0.1 Upstream Author : Airbus-EDF-Phimeca * URL : https://persalys.fr/ * License : LGPL-3+ Programming Lang: C++ Description : GUI for uncertainty treatment and variabilities management Persalys is a graphical user interface for OpenTURNS, dedicated to the treatment of uncertainty and the management of variabilities. The software is a tool between the computer simulation, probabilistic analyses and the data sciences. The interface is available in French or in English. Persalys allows one to: - create mathematical models: analytical, coupling with an external model (finite elements, ...), FMU; - analyse the variability of one's parameters thanks to many methods and visualisation tools; - statistically analyse one's measuring data, infer probability distributions or create metamodels. I am an user of Persalys. I plan to maintain in in the Debian-science team.
Server rental (OT)
Hi ! I'm in the process of renting some servers. Would you suggest I configure my 3 x 2 TV HDD as a RAID group ? Or would this be somewhat useless because the service provider (who rents the rack) already does some maintenance and preventive work ? Thanks -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
Re: Server rental (OT)
On Sun, 2022-07-24 at 04:14 -0400, Polyna-Maude Racicot-Summerside wrote: > I'm in the process of renting some servers. > Would you suggest I configure my 3 x 2 TV HDD as a RAID group ? Please contact debian-user@l.d.o for user support. Also describe your use case as there are no "yes" or "no" answers independent of the use case. Ansgar
Re: adduser default for sgid home directories
Marc Haber writes: > ... Here is what the adduser team considers possible > documentation for this, and we itend to include this in NEWS.Debian as a > rationale for the change. As a user who reads NEWS.Debian (via apt-listchanges) i found the text didnt give me the answers i was looking for. I wanted to know: - what had changed (and when) - why has a change been made - how the change might affects my existing/new systems - eg do i need to manually do something to adopt it? - how/if i can customise/revert/use the new changes? I also found the end of the draft was written almost combatively - as a user i dont really care about bug reports or whether developers argued on a mailing list: i just want to know the facts and whether i need to do anything different as a result. A more neutral phrasing would be better and would also go out-of-date slower. Most NEWS files suffer from this to some extent but i was hoping for something with less about bug reports and more like: "adduser version 3.122 has changed pp (DIR_MODE setting in /etc/ ) from aaa to bbb (one of these is 0700 i think, but i couldnt tell which?). This change has been made to (prevent files being created with the wrong permissions? and also for compatibility with other distributions?) This means ccc (something about the root user's home directory and the user account made by the installer?). Administrators of existing systems may want to (manually chmod /root and other home directories under /home to 0700 for consistency with the new default? ) Administrators who want to have different behavior may (edit /etc/??? and set DIR_MODE back to ? and then restart some service? or do something else? )" Happy to help, but i really couldnt follow the draft below very clearly. I hope you see this as helpful and not annoying - i would be happy to help edit/send a patch etc when i understand the change. If you point me to some better documentation i will be happy to help further
Transition proposal: pkg-config to pkgconf
Hi, Following a discussion at DebConf, I’d like to officially propose a transition from pkg-config to pkgconf in Debian. pkgconf is a newer, actively maintained implementation of pkg-config that supports more aspects of the pkg-config file specification and provides a library interface that applications can use to incorporate intelligent handling of pkg-config files into themselves (such as build file generators, IDEs, and compilers). pkgconf is compatible with pkg-config when it is run as "pkg-config", so it can completely replace the original implementation. Debian would benefit from switching to pkgconf by utilising a more complete implementation of pkg-config that handles aspects of .pc files that pkg-config does not. For example, Provides rules and Cflags.private rules are supported, and pkgconf has a better (and less costly) dependency resolver for .pc files. Having a more complete implementation of the pkg-config implementation can also help convince upstreams like Postgres and LLVM to switch to using pkg-config instead of their custom scripts like llvm-config. pkgconf also supports a feature called personalities [1], that can be used to implement cross-build support without a wrapper script (as currently implemented in both pkgconf and pkg-config packages). pkgconf is already used by other major distributions like Fedora, Gentoo and Arch, so by doing the switch we’ll be aligning ourselves with other distributions ([2], [3], [4]) Migration plan == I believe that it would in the best interests of Debian to only ship one pkg-config implementation, so I propose to make pkgconf provide the binary package pkg-config without a possibility to fall back to the original implementation. This means that after pkgconf takes over the pkg-config binary package, all packages depending on pkg-config will be using the pkgconf implementation without being able to opt out and use the one from freedesktop.org. While this may seem limiting, it reduces the probability of some packages staying with the freedesktop.org implementation indefinitely and missing out on bug fixes or suffering from other differences in implementation details in future when pkgconf becomes even more widespread. In preparation for this migration, I ran a rebuild of all packages depending on pkg-config and found only very few failures [5], which may or may not be related to the difference in behaviour between pkg-config and pkgconf. I will perform another rebuild and continue investigating them to provide patches during the transition period. [0]: http://pkgconf.org/features.html [1]: https://manpages.debian.org/unstable/pkgconf/pkgconf-personality.5.en.html [2]: https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation [3]: https://packages.gentoo.org/packages/virtual/pkgconfig/dependencies [4]: https://archlinux.org/packages/core/x86_64/pkgconf/ [5]: http://pkgconf-migration.debian.net/failed.html -- Cheers, Andrej
Bug#1015971: ITP: pamixer -- pulseaudio command line mixer
Package: wnpp Severity: wishlist Owner: Tzafrir Cohen X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pamixer Version : 1.6 Upstream Author : Clément Démoulins * URL : https://github.com/cdemoulins/pamixer * License : GPL-3+ Programming Lang: C++ Description : pulseaudio command line mixer pamixer is like amixer but for pulseaudio. It can control the volume levels of the sinks. It is used by the SXMO mobile phone interface, an ITP to follow shortly. It will be packaged in the debian namespace on Salsa: https://salsa.debian.org/debian/pamixer
Re: adduser default for sgid home directories
Hello, On Sun, 2022-07-24 at 15:09 +0100, RL wrote: > Marc Haber writes: > > > ... Here is what the adduser team considers possible > > documentation for this, and we itend to include this in NEWS.Debian > > as a > > rationale for the change. > > As a user who reads NEWS.Debian (via apt-listchanges) i found the > text > didnt give me the answers i was looking for. I wanted to know: It is a bit long, but this discussion has come up a number of times over the years, so for the people interested in the details, we felt it was better to have a well-documented rationale. > > - what had changed (and when) This was the first line of the NEWS. "The default for DIR_MODE has been set to 0700 for this release. Detailed explanation follows." So: there is the change; no need to keep reading unless you're interested in the details. > - why has a change been made I think this is explained in excruciating detail. The short version (from NEWS): "mode 0700 provides both the most secure, unsurprising default" > - how the change might affects my existing/new systems - eg do i need > to > manually do something to adopt it? > - how/if i can customise/revert/use the new changes? > For the vast majority of users, nothing needs to be changed. If you run a multi-user system, nothing about your existing users will change, but new users created with adduser will have the new permissions. If you do not want this, the method for changing it back is well documented. > I also found the end of the draft was written almost combatively - as > a > user i dont really care about bug reports or whether developers > argued > on a mailing list: i just want to know the facts and whether i need > to > do anything different as a result. A more neutral phrasing would be > better and would also go out-of-date slower. I am sorry you read it that way; as I said, we felt that an extended description of the change (and some of its history, for people wondering why this change is happening) was appropriate. Certainly no combativeness was intended. > > Most NEWS files suffer from this to some extent but i was hoping for > something with less about bug reports and more like: > > > "adduser version 3.122 has changed > pp (DIR_MODE setting in /etc/ ) from aaa to bbb (one of these > is > 0700 i think, but i couldnt tell which?). Respectfully, the NEWS is not THAT unclear. Perhaps a better opening would have been: The default mode for users created with adduser is now 0700. If you don't know what that means and/or don't know what the default was, you can ignore this change. (but that alone would leave questions unanswered, for people that have followed the issue) Anyway, its been released at this point, so the issue is moot :) -- Cheers, Matt signature.asc Description: This is a digitally signed message part
Re: adduser default for sgid home directories
Matt Barry writes: >> - why has a change been made > > I think this is explained in excruciating detail. The short version > (from NEWS): > > "mode 0700 provides both the most secure, unsurprising default" This is a self-referencing explanation. It provides no value. It's only good if you already understand (and agree) that 0700 is more secure. And the claim that this is "most unsurprising" (less surprising?) is obviously false. "No change" is always less surprising than any change, whatever the rationale is. Bjørn
Re: adduser default for sgid home directories
On 25.07.22 08:46, Bjørn Mork wrote: Matt Barry writes: - why has a change been made I think this is explained in excruciating detail. The short version (from NEWS): "mode 0700 provides both the most secure, unsurprising default" [...] And the claim that this is "most unsurprising" (less surprising?) is obviously false. "No change" is always less surprising than any change, whatever the rationale is. It can also be unsurprising from an end-user's perspective. For someone new to the system. So that line of argument does not really hold. Kind regards Philipp Kern
