Re: Should the weboob package stay in Debian?
On Thursday, 19 July 2018 10:50:20 AM AEST Ian Jackson wrote: > I think this naming, and the iconography, is all very unfortunate. > IMO it is not compatible with Debian's Diversity Statement (which as > ou know was ratified by an overwhelming majority of DDs). You are overreacting. Name of the package may be tasteless but still not bad enough to justify exclusion. I fear of misuse of diversity statement to justify morally distorted decisions against something mild like this particular case. Here is an example: I'm aware of legal human name that is offensive and inappropriate in another language. Nobody in the right mind would use diversity statement against people with such names. Even bringing such matter to attention of a person is awkward to say the least and may be even insulting on its own. Asking person to change his name because it is unpleasant to us would be beyond rude. Let's just leave the matter alone please. If contributors find it sufficiently repulsive to maintain the package then you will be able to remove (unmaintained) package soon enough. Otherwise we can say that usefulness of the package outweighs its bad naming. Another argument is that many things in older literature, fairy tales and religious texts may be considered offensive these days. Yet banning those things would be wrong and would cause far greater damage to freedoms. If we were operating a restaurant, would you suggest to remove all non- vegetarian meals from the menu because some of our customers are vegetarians? Surely they may consider meat to be offensive but normally it is enough to be respectful to people's rights not to use whatever they consider inappropriate to them. I'd much rather not waste any time to facilitate or justify useless renaming like "fsckeditor" to "ckeditor", etc. -- Regards, Dmitry Smirnov. --- The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Re: Should the weboob package stay in Debian?
Hello, On Thu, Jul 19, 2018 at 05:40:46PM +1000, Dmitry Smirnov wrote: > Here is an example: I'm aware of legal human name that is offensive and > inappropriate in another language. Nobody in the right mind would use that might be possible, but it is not a appropriate comparison in this case: -The developer of the program is aware of the meaning of the words, it is not a random coincidence -Changing a program's name is much more easy than to change a first name of a person -The package is not a person and cannot be offended > Let's just leave the matter alone please. If contributors find it > sufficiently repulsive to maintain the package then you will be able to > remove (unmaintained) package soon enough. Otherwise we can say that > usefulness of the package outweighs its bad naming. In fact its bad naming reduces its usefulness: Although there are some useful programs contained, I know there are people which wouldn't recommend it because of its naming (not only the package's name but also because of the programs contained in the package). So if the package stays in the archive, but would be renamed, its usefulness would probably be increased. > Another argument is that many things in older literature, fairy tales and > religious texts may be considered offensive these days. Yet banning those > things would be wrong and would cause far greater damage to freedoms. It is not about an ancient work, those programs are fairly recent. > If we were operating a restaurant, would you suggest to remove all non- > vegetarian meals from the menu because some of our customers are vegetarians? > Surely they may consider meat to be offensive but normally it is enough to be > respectful to people's rights not to use whatever they consider inappropriate > to them. Probably not, but it would be bad, if we killed an animal for every vegetarian entering the restaurant. As it is is bad to have every one creating a Debian mirror distributing this insulting content, which itself already creates an environment encouraging objectification of people having boobs (note that one of the programs contained the term "cook" and wasn't changed for an extra joke). > I'd much rather not waste any time to facilitate or justify useless > renaming like "fsckeditor" to "ckeditor", etc. Did anybody ask you to do so? You didn't have to continue reading this thread if it only wastes your time. Kind regards, Benedikt
Re: Should the weboob package stay in Debian?
Hi Dmitry, On Thu, Jul 19, 2018 at 05:40:46PM +1000, Dmitry Smirnov wrote: > On Thursday, 19 July 2018 10:50:20 AM AEST Ian Jackson wrote: > > I think this naming, and the iconography, is all very unfortunate. > > IMO it is not compatible with Debian's Diversity Statement (which as > > ou know was ratified by an overwhelming majority of DDs). > > You are overreacting. Name of the package may be tasteless but still not bad > enough to justify exclusion. I fear of misuse of diversity statement to > justify morally distorted decisions against something mild like this > particular case. I disagree that this is "mild". weboob itself is fine, maybe. But there are various other binaries inside the weboob packages that aren't, at least not so much: wetboobs handjoob boobsize boobtracker like, seriously. > Here is an example: I'm aware of legal human name that is offensive and > inappropriate in another language. Nobody in the right mind would use > diversity statement against people with such names. Even bringing such matter > to attention of a person is awkward to say the least and may be even > insulting on its own. > Asking person to change his name because it is unpleasant to us would be > beyond rude. This is true, but not relevant to the issue at hand (which is about weboob). [...] -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Can aolserver4 be considered superseded and removed?
Hi Sebastian, El mié, 18-07-2018 a las 21:41 +0200, Sebastian Andrzej Siewior escribió: > On 2018-02-27 18:34:13 [+0100], Héctor Romojaro Gómez wrote: > > El mar, 27-02-2018 a las 17:36 +0100, Francesco P. Lovergine > > escribió: > > > [...] > > > > > > I would suggest to provide a migration package for AOLserver > > > users > > > with a NEWS document about possible issues due to known problems. > > > > Agree. I will make openacs dependant on naviserver in the next > > version, > > once naviserver + its modules are in the archive. > > We have naviserver in NEW [0] (for four months but okay). I don't see > any reference to the aolserver4 package. I was expecting something > like > Provides:/Replaces:/Package: for a transitional package to move all > users from aolserver4 over to naviserver. I will add a "Replaces" to the naviserver package once it hits sid and i am able to upload a newer version. > I am currious now if I am allowed to reassing [2] over to > ftp.debian.org > for the removal. Fine for me, let's wait for Frankie's opinion. > There is also ITP for naviserver-modules [1] so I could then file a > RM > for aolserver4-nsopenssl which I what I planned in the beginning. > Any objections? nsopenssl is replaced by naviserver itself, as it includes now the nsssl module, so there is no need to wait for the modules package :) > [0] https://ftp-master.debian.org/new/naviserver_4.99.16-1.html > [1] https://bugs.debian.org/891650 > [2] https://bugs.debian.org/891633 Kind regards, Héctor
Bug#904084: ITP: mimepull -- Pull API for parsing MIME messages
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: mimepull Version : 1.9.7 Upstream Author : Oracle Corporation * URL : https://javaee.github.io/metro-mimepull/ * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : Pull API for parsing MIME messages Mimepull provides a streaming API to access attachments parts in a MIME message. This package will be maintained by the Java Team. It's required to build the JAX-WS reference implementation. This API was previously embedded in the JDK and will be removed in Java 11.
Re: Can aolserver4 be considered superseded and removed?
Quoting Héctor Romojaro Gómez (2018-07-19 13:07:24) > I will add a "Replaces" to the naviserver package once it hits sid and > i am able to upload a newer version. You can upload a newer version now, while package is stillin NEW queue. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Can aolserver4 be considered superseded and removed?
On Thu, Jul 19, 2018 at 01:07:24PM +0200, Héctor Romojaro Gómez wrote: We have naviserver in NEW [0] (for four months but okay). I don't see any reference to the aolserver4 package. I was expecting something like Provides:/Replaces:/Package: for a transitional package to move all users from aolserver4 over to naviserver. I will add a "Replaces" to the naviserver package once it hits sid and i am able to upload a newer version. I am currious now if I am allowed to reassing [2] over to ftp.debian.org for the removal. Fine for me, let's wait for Frankie's opinion. There is also ITP for naviserver-modules [1] so I could then file a RM for aolserver4-nsopenssl which I what I planned in the beginning. Any objections? nsopenssl is replaced by naviserver itself, as it includes now the nsssl module, so there is no need to wait for the modules package :) I would propose a replace roadmap for people using aolserver4 (in both testing and stable) with usual replaces/provides/conflicts items, and add a *big* warn in NEWS about known changes and incompatibilities. -- Francesco P. Lovergine
Re: Should the weboob package stay in Debian?
On Thursday, 19 July 2018 7:43:39 PM AEST Wouter Verhelst wrote: > weboob itself is fine, maybe. But there are various other binaries > inside the weboob packages that aren't, at least not so much: > > wetboobs > handjoob > boobsize > boobtracker > > like, seriously. Yuck... :( Incredibly tasteless and probably intentionally controversial... I see your point and I agree with you yet renaming might still be inappropriate and/or ineffective. I'd like to see stronger justification for replacing uncomfortable reference to part of human body because why should it be uncomfortable? If double "O" is a problem then how are we not offended by Google? If we swap body part reference to another body part like "leg" or "arm", it becomes just ridiculous. I have no intention to defend this particular package but more interested in principle of justifying such actions. > > Asking person to change his name because it is unpleasant to us would be > > beyond rude. > > This is true, but not relevant to the issue at hand (which is about > weboob). That was about misuse of diversity statement. My point is about how inappropriate renaming might be, if pushed too far. -- Regards, Dmitry Smirnov. --- Continuous effort - not strength or intelligence - is the key to unlocking our potential. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#904088: ITP: golang-github-araddon-gou -- logging and json helpers for Go
Package: wnpp Severity: wishlist Owner: Aggelos Avgerinos * Package name: golang-github-araddon-gou Version : 0.0~git20180509.7db4be5-1 Upstream Author : Aaron Raddon * URL : https://github.com/araddon/gou * License : MIT Programming Lang: Go Description : logging and json helpers for Go logging and json helpers for Go gou is both a JSON helper focused on Type coercion, and json path query and another configurable logger for Go. I intent to package and maintain it under the Debian Go Packaging Team.
Re: Can aolserver4 be considered superseded and removed?
El jue, 19-07-2018 a las 13:18 +0200, Jonas Smedegaard escribió: > Quoting Héctor Romojaro Gómez (2018-07-19 13:07:24) > > I will add a "Replaces" to the naviserver package once it hits sid > > and > > i am able to upload a newer version. > > You can upload a newer version now, while package is stillin NEW > queue. Thanks, was not aware of that. Héctor
Re: Can aolserver4 be considered superseded and removed?
El jue, 19-07-2018 a las 13:52 +0200, Francesco P. Lovergine escribió: > On Thu, Jul 19, 2018 at 01:07:24PM +0200, Héctor Romojaro Gómez > wrote: > > > We have naviserver in NEW [0] (for four months but okay). I don't > > > see > > > any reference to the aolserver4 package. I was expecting > > > something > > > like > > > Provides:/Replaces:/Package: for a transitional package to move > > > all > > > users from aolserver4 over to naviserver. > > > > I will add a "Replaces" to the naviserver package once it hits sid > > and > > i am able to upload a newer version. > > > > > I am currious now if I am allowed to reassing [2] over to > > > ftp.debian.org > > > for the removal. > > > > Fine for me, let's wait for Frankie's opinion. > > > > > There is also ITP for naviserver-modules [1] so I could then file > > > a > > > RM > > > for aolserver4-nsopenssl which I what I planned in the beginning. > > > Any objections? > > > > nsopenssl is replaced by naviserver itself, as it includes now the > > nsssl module, so there is no need to wait for the modules package > > :) > > > > I would propose a replace roadmap for people using aolserver4 (in > both testing > and stable) with usual replaces/provides/conflicts items, and add a > *big* warn > in NEWS about known changes and incompatibilities. There is a full upstream NEWS file including those: https://salsa.debian.org/tcltk-team/naviserver/blob/master/NEWS Not so easy to digest (~900 lines), but it is exhaustive. We could include it in /usr/share/doc/naviserver/ and point the user to it in the NEWS.Debian file. Kind regards, Héctor
Re: Bug#903815: ITP: pw -- A simple command-line password manager
On Thu, 2018-07-19 at 06:16 +0200, Tollef Fog Heen wrote: > ]] Michael Stone > > > On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: > > > It writes to `/dev/shm` which is not disk. > > > > All else that's been said aside, this idea is also dangerously > > incorrect in a typical configuration: the tmpfs backend will write to > > swap under memory pressure. (This is also true of the memory used by > > the process; if it's actually important to keep data from being > > written to persistent storage, it should be set unswappable using > > mlock. I have no idea how one would do this effectively in a shell > > script.) > > Assuming it's small enough, using a pipe (or possibly a FIFO) could > work. That's kernel memory and iirc it won't be swapped out. (I'm > happy to be corrected on this, I'm basing it on what I've heard before > and my recollection of it.) This is true on Linux. Kernel memory is not swappable. But data in the pipe must be written from and read out to swappable process memory, so using a pipe doesn't solve the problem completely. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: This is a digitally signed message part
Re: Should the weboob package stay in Debian?
On Thu, Jul 19, 2018 at 10:02:23PM +1000, Dmitry Smirnov wrote: I see your point and I agree with you yet renaming might still be inappropriate and/or ineffective. I'd like to see stronger justification for replacing uncomfortable reference to part of human body because why should it be uncomfortable? Have you read Matthew Vernon's reply to OP in this thread? Does that not explain it? If double "O" is a problem then how are we not offended by Google? Because double "O" is not the problem. If we swap body part reference to another body part like "leg" or "arm", it becomes just ridiculous. Do you mean: it would be ridiculous to perform s/boobs/arm/ in the package? Indeed it would be. Or do you mean it would be ridiculous to object to *arm* in packages or binary names? Nobody is doing that. Or do you mean something else? -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Should the weboob package stay in Debian?
Thanks Marc for raising this on -devel. I am the person who originally brought attention to the package on -private. I did so there, because I did not feel confident in doing so in a public space initially. It wasn't my intention to irritate upstream by talking behind their back, so I'm sorry for that. On Wed, Jul 18, 2018 at 02:35:18PM +0100, Matthew Vernon wrote: I think the names contribute to a "laddish" environment where sexual objectification of women can be seen to be OK, and that this is something we should try and avoid in Debian. I say this without implying any malign intent on the authors part - they've been named thus for some time now, and what was once considered OK is not necessarily still considered OK (that's progress!). I'm quoting this part because I think it's an excellent summary of the problem. I think it would be good if the names were changed. I think we ought to more concretely determine what changes we wish to take place. To do this properly I need to spend more time looking at the package in more detail, so what follows is just my initial feelings. I welcome feedback. For now I suggest we hash it out in mail, let's see how well this works. We may have to consider something more structured such as debating over a concrete PR, or a DEP proposal. As a pre-amble side-note, some issues of offending users with homophobic language have been addressed upstream, and I think we should aim to carry these patches in stable/testing/unstable. (I don't think we have processes for patching oldstable or o-o-stable, please correct me if I'm wrong. I also haven't yet verified that these patches are necessary in all of our suites.)[1] My ideal outcome is that we come to an agreement on a series of steps that results in the software *upstream* no longer objectifying women, and we continue to carry the software in Debian, and that in doing so both upstream and Debian benefit (it *is* useful software). A less ideal outcome, but still acceptable from my POV, would be that upstream make no changes, but we carry patches in Debian to address the issue. This is, of course, so long as we have maintainers willing to do that. Since I raised the objection, I am prepared to volunteer towards that effort, should it be necessary, and for what little that's worth. So some of the changes then: The software has a long established name "weboob" which is an acronym of sorts for "web outside of browsers". Whether or not the acronym was ever chosen to allude to breasts in the first place, I don't know. The software has a domain name weboob.org which is their established home on the Internet and WWW. Changing the entire project name I think would be impractical and impose real costs on upstream (e.g. new domain registration(s)). If it was crystal clear that this name was deliberately offensive then I would argue that this should happen non-the-less, but IMHO at least, it's not, and I think the issues with weboob itself, in isolation, can be addressed simply by adding a hyphen. I propose, that the package name in Debian grows a hyphen: web-oob. The placement is consistent with the acronym (web is not an acronym, it's a full word, the rest is an acronym), the coincidence (or not) with "boob" is at least disguised. It's close enough to the old name to preserve word-of-mouth, awareness of the tool, search engines finding it, etc. I would be very encouraged if upstream were to consider this, too. The binary names within are far more problematic. A full enumeration of the ones that IMHO must change will have to wait for a follow-up email. But it would certainly include "wetboobs", "boobsize", "boobtracker" and "flatboob". If the names are to change, I don't think there's any reason they should not change significantly; merely adding a hyphen would not be sufficient. I will attempt to suggest some names in a follow-up. A technical drawback of changing names may be that scripts reference the older names break. More work to be done on this proposal is to determine to which programs this is likely to be an issue. Should it be an issue, then I do not object to the offensive names being provided as compatibility symlinks, so long as they are shipped in a separate binary package, using the already-established practice of suffixing "-offensive" to the binary package name. I'll stop here for now, plenty to discuss already. [1] https://git.weboob.org/weboob/devel/merge_requests/228 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Building Debian packages in CI (ick)
I've recently made the first release of ick, my CI engine (https://ick.liw.fi/), which was built by ick itself. It went OK, but the process needs improvement. This mail has some pondering on how the process of building Debian packages should happen in the best possible taste. I'd appreciate feedback on these thoughts. (This email is a big long, but I've published the same thing on my blog, if that's easier to read: https://blog.liw.fi/posts/2018/07/19/building_debian_packages_in_ci_ick/) # Context I develop a number of (fairly small) programs, as a hobby. Some of them I also maintain as packages in Debian. All of them I publish as Debian packages in my own APT repository. I want to make the process for making a release of any of my programs as easy and automated as possible, and that includes building Debian packages and uploading them to my personal APT repository, and to Debian itself. My personal APT repository contains builds of my programs against several Debian releases, because I want people to have the latest version of my stuff regardless of what version of Debian they run. (This is somewhat similar to what OEMs that provide packages of their own software as Debian packages need to do. I think. I'm not an OEM and I'm extrapolating wildly here.) I currently don't provide packages for anything but Debian. That's mostly because Debian is the only Linux distribution I know well, or use, or know how to make packages for. I could do Ubuntu builds fairly easily, but supporting Fedora, RHEL, Suse, Arch, Gentoo, etc, is not something I have the energy for at this time. I would appreciate help in doing that, however. I currently don't provide Debian packages for anything other than the AMD64 (x86-64, "Intel 64-bit") architecture. I've previously provided packages for i386 (x86-32), and may in the future want to provide packages for other architectures (RISC-V, various Arm variants, and possibly more). I want to keep this in mind for this discussion. # Overview For the context of this email, let's assume I have a project Foo. Its source code is stored in `foo.git`. When I make a release, I tag it using a signed git tag. From this tag, I want to build several things: * A **release tarball**. I will publish and archive this. I don't trust git, and related tools (tar, compression programs, etc) to be able to reproducibly produce the same bit-by-bit compressed tarball in perpetuity. There's too many things that can go wrong. For security reasons it's important to be able to have the exact same tarball in the future as today. The simplest way to achive this is to not try to reproduce, but to archive. * A **Debian source package**. * A **Debian binary package** built for each target version of Debian, and each target hardware architecture (CPU, ABI, possibly toolchain version). The binary package should be built from the source package, because otherwise we don't know the source package can be built. The release tarball should be put in a (public) archive. A digital signature using my personal PGP key should also be provided. The Debian source and binary packages should be uploaded to one or more APT repositories: my personal one, and selected packages also the Debian one. For uploading to Debian, the packages will need to be signed with my personal PGP key. (I am not going to give my CI access to my PGP key. Anything that needs to be signed with my own PGP key needs to be a manual step.) ## Package versioning In Debian, packages are uploaded to the "unstable" section of the package archive, and then automatically copied into the "testing" section, and from there to the "stable" section, unless there are problems in a specific version of a package. Thus all binary packages are built against unstable, using versions of build dependencies in unstable. The process of copying via testing to stable can take years, and is a core part of how Debian achieves quality in its releases. (This is simplified and skips consideration like security updates and other updates directly to stable, which bypass unstable. These details are not relevant to this discussion, I think.) In my personal APT repository, no such copying takes place. A package built for unstable does not get copied into section with packages built for a released version of Debian, when Debian makes a release. Thus, for my personal APT repository, there may be several builds of the any one version of Foo available. * foo 1.2, built for unstable * foo 1.2, built for Debian 9 * foo 1.2, built for Debian 8 In the future, that list may be expanded by having builds for several architectures: * foo 1.2, built for unstable, on amd64 * foo 1.2, built for Debian 9, on amd64 * foo 1.2, built for Debian 8, on amd64 * foo 1.2, built for unstable, on riscv * foo 1.2, built for Debian 9, on riscv * foo 1.2, built for Debian 8, on riscv When I or my users upgrade our Debian hosts, say from Debian 8 to Debian 9, any packges from my pers
Re: Building Debian packages in CI (ick)
Hello, one short remark Am 19.07.2018 um 18:06 schrieb Lars Wirzenius: > I've recently made the first release of ick, my CI engine > (https://ick.liw.fi/), which was built by ick itself. It went OK, but > the process needs improvement. This mail has some pondering on how > the process of building Debian packages should happen in the best > possible taste. > * `foo_1.2-1~debian8.dsc` — source package for Debian 8 > * `foo_1.2-1~debian8.debian.tar.xz` — Debian packaging and changes > * `foo_1.2-1~debian8_amd64.deb` — binary package for Debian 8, amd64 > * `foo_1.2-1~debian8_riscv.deb` — binary package for Debian 8, riscv > > * `foo_1.2-1~debian9.dsc` — source package for Debian 9 > * `foo_1.2-1~debian9.debian.tar.xz` — Debian packaging and changes > * `foo_1.2-1~debian9_amd64.deb` — binary package for Debian 9, amd64 > * `foo_1.2-1~debian9_riscv.deb` — binary package for Debian 9, riscv Please regard that foo_1.2-1~debian9 is greater than foo_1.2-1~debian10, which stand for Debian Buster -- Mechtilde Stehmann ## Debian Developer ## Loook, calender-exchange-provider, libreoffice-canzeley-client ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Re: Building Debian packages in CI (ick)
On Thu, Jul 19, 2018 at 06:49:11PM +0200, Mechtilde wrote: > Please regard that foo_1.2-1~debian9 is greater than foo_1.2-1~debian10, > which stand for Debian Buster Nope: dpkg --compare-versions 1.2-1~debian9 lt 1.2-1~debian10 In Debian versions, like in all modern version comparison schemes, a string of digits sorts by its numerical value rather than strictly asciibetically. Meow. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Firefox 60esr on Stretch ?
Hideki Yamane schrieb: > Hi, > > On Fri, 18 May 2018 10:29:03 +0200 > Moritz Mühlenhoff wrote: >> > Does it fail like in bug #858153 (which has a patch) or in a different way? >> >> That bug is a year old and for 0.19, not sure if it's still any relevant >> for current releases, when trying to run a bootstrap build with 0.25 it's >> still trying to execute cargo, but I haven't dug deeper so far: > > Let me clarify current status, cargo package backport for stretch > is the blocker to bring firefox-esr 60 to stable, right? Correct, backports of rustc 1.24 and LLVM 4.0 have landed in Stretch 9.5 and cargo is the last missing bit. It's also worth pointing out that rustc is currently only available on amd64, so if anyone is interested in having i386 or some arm supported one needs to sort out a cross-compiled build. Cheers, Moritz
Re: Can aolserver4 be considered superseded and removed?
On 2018-07-19 13:52:04 [+0200], Francesco P. Lovergine wrote: > > > I am currious now if I am allowed to reassing [2] over to > > > ftp.debian.org > > > for the removal. > > > > Fine for me, let's wait for Frankie's opinion. > > I would propose a replace roadmap for people using aolserver4 (in both > testing and stable) with usual replaces/provides/conflicts items, and add a > *big* warn in NEWS about known changes and incompatibilities. it would be only for stable because it is already gone from testing. Regarding my question of the removal of aolserver from unstable: Héctor was okay with it but wanted to your (Frankie's) opinion. Are you okay, too? > -- > Francesco P. Lovergine Sebastian
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Jul 18, Marco d'Itri wrote: > Some day it may replace crypt(3), currently provided by glibc: > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt I tried creating a package which would divert libc's libcrypt, but it appears to be much harder than I thought. Installing it would looke like: 1) libcrypt1.preinst diverts glibc's libcrypt.so.1 2) dpkg does things 3) dpkg installs libxcrypt's libcrypt.so.1 4) dpkg does more things 5) libcrypt1.postinst runs/triggers ldconfig And this means that perl (a libcrypt dependency) would be broken between 1 and 5 (or maybe 1 and 3): is this ever going to work? But even if this worked correctly, glibc installs a libcrypt-N.NN.so, whose exact name I expect changes among different releases. Is there any way to implement all this safely? -- ciao, Marco signature.asc Description: PGP signature
Work-needing packages report for Jul 20, 2018
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1268 (new: 1) Total number of packages offered up for adoption: 164 (new: 1) Total number of packages requested help for: 54 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: sheepdog (#903990), orphaned 2 days ago Description: distributed storage system for QEMU Installations reported by Popcon: 36 Bug Report URL: http://bugs.debian.org/903990 1267 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: mueller (#903832), offered 4 days ago Description: Mueller English/Russian dictionary in dict format Installations reported by Popcon: 8517 Bug Report URL: http://bugs.debian.org/903832 163 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 596 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker openstack-pkg-tools Installations reported by Popcon: 1142 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2489 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 625 Bug Report URL: http://bugs.debian.org/642906 broadcom-sta (#886599), requested 192 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1930 Bug Report URL: http://bugs.debian.org/886599 cargo (#860116), requested 464 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 619 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3330 days ago Description: Common UNIX Printing System Reverse Depends: ayatana-indicator-printers bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd (67 more omitted) Installations reported by Popcon: 170089 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 1030 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (118 more omitted) Installations reported by Popcon: 193583 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 734 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 59310 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1419 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 11891 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 1024 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero autodeb-worker brz-debian bzr-builddeb customdeb debci debian-builder (29 more omitted) Installations reported by Popcon: 12865 Bug Report URL: http://bugs.debian.org/800413 ed (#886643), requested 192 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn Installations reported by Popcon: 20808 Bug Report URL: http://bugs.debian.org/886643 ejabberd (#767874), requested 1354 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 565 Bug Report URL: http://bugs.debian.org/767874 fbcat (#565156), requested 3109 days ago Description: framebuffer grabber Installations reported by Popcon: 192 Bug Report URL: http://bugs.debian.org/565156 fgetty (#823061)
Re: Should the weboob package stay in Debian?
On Friday, 20 July 2018 12:50:12 AM AEST Jonathan Dowland wrote: > Have you read Matthew Vernon's reply to OP in this thread? Does that not > explain it? Matthew did not convince me. IMHO his explanation is weak as it boils down to "there are many problems like this and we should fix this problem because there are other similar ones"... I refuse to judge the matter with my feelings. To decide rationally we need to identify inappropriate component. Because trying to aggressively eliminate what makes us feel uncomfortable is against diversity, against multi-culturalism, against tolerance. Can you explain what makes you feel uncomfortable about it? Is it (semantics of) the word itself or context? If we recognise word "boobs" as inappropriate in Debian community, doesn't it also condemns (good) things like breast feeding in public by association? Isn't that too far? We might be doing more harm than good. I think what stigmatising the word is cultural bias implying negative context by interpreting and extrapolating meaning that word itself may not carry. Like assuming bad intentions. Why not assume the opposite like some degree of admiration? When we hear word "hair" do we automatically imply dirty/messy hair or a beautiful one? If to you word "boobs" is more inappropriate than it is to me, that's probably because you are attaching more negativity to the word. What seems to be the problem is application of cultural bias to assign negative meaning and by doing that we perpetrate the very problem that I'd rather destroy. Maybe if we all try to stop negative interpretations then we might have a chance to eliminate the problem instead of supporting it. I see the whole thing as the other side of multi-culturalism. If we were from the same culture then it would be easy to agree what's (in)appropriate. (Example: showing hair or skin in public). In multi-cultural society there will be always something you'll probably never accept and something that others will never understand about you. And that's OK as we can still be friends and respect each other as long as we don't try too hard to adjust everyone to our standards. > Do you mean: it would be ridiculous to perform s/boobs/arm/ in the > package? Indeed it would be. It is more interesting to explore why would it be ridiculous. Probably not because it instantly weakens inappropriate-ness but because it changes _nothing_. Other parts of human body can be just as attractive or objectified just as much. The same arguments can be made about legs, arms, hair. If problem is not the (particular) part of human body then what it is? Not a context - purpose of the software is not offensive. Debian context implies no problem either - we are a friendly community. It appears to me that the root of the problem is culturally shaped perception. Truly multi-cultural society have more to gain from diversity than from attempts to adjust each other to certain language standards. > Or do you mean it would be ridiculous to > object to *arm* in packages or binary names? Nobody is doing that. Not today, not yet anyway... But why not? The same mechanism of distortion can be applied to any word for any part of human body. Another absurd example: "claws" - clearly an offensive reference to ugly or malformed human hands. Inappropriate. Let's ban/remove from Debian or rename... IMHO that kind of interpretations are toxic and inappropriate. Why not try to think more positive? -- Best wishes, Dmitry Smirnov. --- I am easily satisfied with the very best. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Re: Should the weboob package stay in Debian?
On Fri, Jul 20, 2018 at 01:34:19PM +1000, Dmitry Smirnov wrote: On Friday, 20 July 2018 12:50:12 AM AEST Jonathan Dowland wrote: Have you read Matthew Vernon's reply to OP in this thread? Does that not explain it? Matthew did not convince me. IMHO his explanation is weak as it boils down to "there are many problems like this and we should fix this problem because there are other similar ones"... This suggests that you did understand Matthew's reply, but the rest of your message implies that you didn't. Honestly I'm not sure I've got the skill to explain it to you, I'm not sure I could do a better job than Matthew at summarizing the issue. I'm afraid I must bow out, focus on fixing the problem, and leave it to others or to self-study for you to understand it, if you wish to. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
