On Saturday, 19 April 2025 18:23:06 Central European Summer Time Mattia
Rizzolo wrote:
> But I recommend you just leverage control commands while filing, since
> ftp-master tools just parse the subject:
Good idea !
Thanks both for the help
On Fri, Apr 18, 2025 at 03:46:03PM +0200, Dominique Dumont wrote:
> But I forgot that all raku-modules are Architecture: any, which means that
> all
> these module must also be removed from unstable/arm*.
>
> There are 19 packages to be removed from arm*.
>
> Should I log one bug for all 19 pac
Hi
On 18-04-2025 15:46, Dominique Dumont wrote:
Should I log one bug for all 19 packages, or one bug per package ?
I'm pretty sure ftp-master has workflows that desire one bug per package
as I've seen that request often enough.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital sig
Hi
Currently rakudo cannot be shipped on arm architectures because of build
issues. Upstream is working in this, but in the meantime, raku is not suitable
for ARM.
I've required the removal of moarm, nqp and rakudo from unstable/arm*, which
was done a few days ago.
But I forgot that all raku-
On 16 April 2025 at 19:24, Paul Gevers wrote:
| Hi Dirk,
|
| On 16-04-2025 18:55, Dirk Eddelbuettel wrote:
| > | [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
| >
| > That appears to be a different set of packages.
|
|
| The packages spotted in the original list, I assume you're ta
Hi Dirk,
On 16-04-2025 18:55, Dirk Eddelbuettel wrote:
| [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
That appears to be a different set of packages.
The packages spotted in the original list, I assume you're talking about
all of them except maybe cantor and vtk9?
boot: r-recom
w that you can't remove them at this stage of the release.
|
| [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
That appears to be a different set of packages. It is comprised entirely of
packages that the meta package "r-recommended" depends upon. [ The R 'engine'
d on those architectures. I think it's best to
assume for now that you can't remove them at this stage of the release.
Paul
[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
OpenPGP_signature.asc
Description: OpenPGP digital signature
On Wed, 16 Apr 2025 at 23:04:47 +0900, Charles Plessy wrote:
If you need one of the team-maintained r-cran-* packages on a 32-bit or
on a big endian architectures, which are not supported upstream, please
contact me on the debian-r list and let's see how we can share the
workload.
It might be b
jects
architecture-is-64-bit in the build depends and I will add a
--little-endian one that will inject architecture-is-little-endian.
After uploading the changes, I will then ask the FTP team to remove the
team-maintained r-cran-* packages and all their reverse-dependencies
from the excluded architecture
* Holger Levsen [250102 13:03]:
> On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> > I'm wondering how we can clean up suites like experimental and
> > unstable. They tend to slowly accumulate cruft that nobody cleans up,
> > including no longer installable packages.
>
> for experiment
e: what Helmut said & does.
> As a very simple start, I would like to remove packages from
> experimental that haven't seen an upload for a long time (arbitrarily
> chosen as before 2020-01-01 for the list below).
I'd propose to be more "aggressive" and use 2021-0
* Andreas Metzler [241231 06:59]:
> On 2024-12-29 Helmut Grohne wrote:
> > On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> [...]
> >> I would also like to do something similar to unstable; maybe start with
> >> packages uploaded before some arbitrary date that are also not included
>
On 2024-12-29 Helmut Grohne wrote:
> On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
[...]
>> I would also like to do something similar to unstable; maybe start with
>> packages uploaded before some arbitrary date that are also not included
>> in any of oldstable/stable/testing. These ca
ple start, I would like to remove packages from
> experimental that haven't seen an upload for a long time (arbitrarily
> chosen as before 2020-01-01 for the list below).
>
> What do people think about this?
Only if that does not lead to a subsequent upload of the package to be
art, I would like to remove packages from
> experimental that haven't seen an upload for a long time (arbitrarily
> chosen as before 2020-01-01 for the list below).
>
> What do people think about this?
Thanks for cleaning up the archive. The proposed criteria vaguely makes
sense to
Ansgar dixit:
> musescore-snapshot| 2019-07-05 00:19:11.735843+00
I do have plans to pick that up once I find the tuits for it
and have finished the preceding musescore{2,3} uploads. (Lots
to do there.) So please keep that for now.
Thanks,
//mirabilos
--
[16:04:33] bkix: "veni
Hi,
On 29/12/2024 13:08, Ansgar 🐱 wrote:
[…]
As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).
Yes please.
> David Prévot
>php-sabre-event (
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I
Date: Sun, 29 Dec 2024 13:37:50 +0100
From: Matthias Geiger
To: ,
Cc:
Bcc:
Subject: Re: Remove ancient uploads from experimental (and later
unstable)
In-Reply-To: <87ikr2zo6m@43-1.org>
Hi,
As a very simple start, I would like to remove packages from
experimental that haven
Hi,
I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up,
including no longer installable packages.
As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a
On Fri, Jul 05, 2024 at 09:24:18AM +0200, Simon Josefsson wrote:
> First, I think we need to understand the rationale for doing anything
> about 'netkit-rwho': do we want to do something because 1) it is not
> maintained upstream? or 2) because it is an insecure design?, or 3)
> something else?
At
t; Please have a look at https://github.com/alexmyczko/rutpime (there's
> an ITP for it, and it has
> been in new queue several times:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013361
>
> After a while I intend to clone this bug to ftp.debian.org for
> removal f
Quoting Otto Kekäläinen (2024-03-30 22:09:46)
> Is it so that the debian/copyright file is reviewed by ftp-masters
> only for packages in NEW queue, and there is probably no automation in
> place to flag subsequent copyright changes for re-review?
It is my understanding that it is, and always has
sible-island.net/personal/copywrongs.html
If someone has rewritten an author's contribution such that none of the
author's "original expression" (a manifestation of human creativity)
remains in the file/work, then it is okay to remove their attribution
and/or copyright noti
Hi!
While reviewing xz-utils commits I noticed that a bunch of old
copyright holder names were removed in
https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78.
Is this OK to do so? Having source code in the public domain means
that there is no copyright, so n
-Undiacritic
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : remove diacritics from a string
Text::Undiacritic provides a module that changes characters with diacritics
into their base characters.
Also changes into base character in cases where UNICODE does not
Hi,
Am 11.01.23 um 15:20 schrieb John Paul Adrian Glaubitz:
Hi Helge!
On 1/11/23 15:03, Helge Deller wrote:
Yes, sadly we don't have a working java right now on hppa, and it will
probably take some more time to get one. At least I won't have time
for it during the next few months.
But it would
Hi Helge!
On 1/11/23 15:03, Helge Deller wrote:
Yes, sadly we don't have a working java right now on hppa, and it will
probably take some more time to get one. At least I won't have time
for it during the next few months.
But it would be sad to loose those bindings...
There are some efforts to
On 1/10/23 19:54, Rene Engelhard wrote:
Hi,
Am 10.01.23 um 19:44 schrieb John Paul Adrian Glaubitz:
On 1/10/23 19:25, Rene Engelhard wrote:
(which are for many BD-Uninstallable since ages because it does not have Java
(anymore), didn't do a long-ago transition, ...)
They all have Java suppo
Hi,
Am 10.01.23 um 19:44 schrieb John Paul Adrian Glaubitz:
On 1/10/23 19:25, Rene Engelhard wrote:
(which are for many BD-Uninstallable since ages because it does not
have Java (anymore), didn't do a long-ago transition, ...)
They all have Java support except for hppa, see:
I was indeed ai
(posting this to debian-devel@ since debian-ports@ cross-posts to too many
lists)
Hello Rene!
On 1/10/23 19:25, Rene Engelhard wrote:
(which are for many BD-Uninstallable since ages because it does not have Java
(anymore), didn't do a long-ago transition, ...)
They all have Java support exc
On 2022-09-14 Paul Wise wrote:
> On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote:
>> Is there a way to find all packages built against broken dh-fortran-
>> mod so all affected packages can be rebuilt?
> I am not sure of the correct regex, but the binary package control
> search should
On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote:
> Is there a way to find all packages built against broken dh-fortran-
> mod so all affected packages can be rebuilt?
I am not sure of the correct regex, but the binary package control
search should work, if it doesn't then you need a loca
: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such
file or directory
dpkg: error processing package libopenmpi-dev:amd64 (--purge):
[...]
Looking at the postrm script we find:
(sid)root@argenau:/# grep ^rmdir
/var/lib/dpkg/info/libopenmpi-dev\:amd64.postrm
rmdir --igno
ian-devel@lists.debian.org
> Cc: debian-...@lists.debian.org
> Subject: Re: debian-faq in NEW - or: remove documentation from the archive at
> all
> Date: Tue, 05 Apr 2022 07:54:47 +0800
>
> On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote:
>
> > Maybe in a next uploa
Hi,
On Sun, 2022-04-03 at 13:18 +0200, Holger Wansing wrote:
> debian-faq is waiting in NEW queue for more than 4 months now (upload
> is from 23.11.2021), with no visible activity from ftp-masters (and
> even with no message at all!).
> I pinged ftp-masters at the end of January, but got no react
Hi,
Am 6. April 2022 06:40:54 MESZ schrieb "Joost van Baal-Ilić"
:
>
>Luckily ftp-masters in the mean time did accept the faq upload. Thanks!
Yes, That's great. Many thanks
Now I can look into activating the new Portuguese translation
on the website (which is one major point in this upload, an
Hi,
On Tue, Apr 05, 2022 at 07:54:47AM +0800, Paul Wise wrote:
> On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote:
>
> > Maybe in a next upload of debian-faq, we could get rid of this by-hand
> > stuff.
> > Afaik it's only used to get the FAQ content published at
> > https://ftp.debi
On Mon, 2022-04-04 at 20:52 +0200, Joost van Baal-Ilić wrote:
> Maybe in a next upload of debian-faq, we could get rid of this by-hand stuff.
> Afaik it's only used to get the FAQ content published at
> https://ftp.debian.org/debian/doc/
I think it would be better to send a dak patch turning the
Hi,
Samuel Thibault schreef op maandag 4 april 2022:
> the byhand queue is quite different from the new
> queue, possibly there are very few ftpmaster who actually know how to
> process it.
Maybe in a next upload of debian-faq, we could get rid of this by-hand stuff.
Afaik it's only used to get t
Hello,
Bo YU, le lun. 04 avril 2022 09:09:53 +0800, a ecrit:
> On Sun, Apr 03, 2022 at 01:18:37PM +0200, Holger Wansing wrote:
> > debian-faq is waiting in NEW queue for more than 4 months now (upload is
> > from 23.11.2021), with no visible activity from ftp-masters (and even with
> > no
> > mes
documentation-only package is still waiting.
Any comments on this?
If documentation is that unimportant, we could save a long of work and time,
if we remove all documentation packages from the archive and the website!!!
Holger
(being extremly sad about all this)
Holger Wansing wrote (Sat, 29
wrong with this upload or this
package???
There have been countless NEW processings since then, but this (in my opinion)
uncritical documentation-only package is still waiting.
Any comments on this?
If documentation is that unimportant, we could save a long of work and time,
if we remove all
-deprecation-shim
* License : Apache 2.0
Programming Lang: Python
Description : Shims to help you safely remove pytz
pytz has served the Python community well for many years, but it is no
longer the best option for providing time zones. pytz has a non-standard
interface that is very easy
Quoting Scott Kitterman (2021-12-06 16:03:31)
> Speaking only for myself here, not the team as a whole:
>
> The tools we use default to age order, so if one just starts working
> through packages in the order given, it's oldest first. Personally, I
> rather rarely do that. I don't have a lot o
On Monday, December 6, 2021 8:58:15 AM EST Andreas Tille wrote:
> Hi Jonas,
>
> I've thought that it is probably not my turn to answer your questions
> but since there was no answer yet I'd like to report from my experience.
>
> Am Thu, Nov 18, 2021 at 05:21:45PM +0100 schrieb Jonas Smedegaard:
>
Hi Jonas,
I've thought that it is probably not my turn to answer your questions
but since there was no answer yet I'd like to report from my experience.
Am Thu, Nov 18, 2021 at 05:21:45PM +0100 schrieb Jonas Smedegaard:
>
> Is "Age" used to rank processing of NEW requests?
I have some evidence
Andrey Rahmatullin writes:
> On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote:
>> > > I don't know if that has been proposed before, but how about waiving
>> > > the NEW queue requirement for experimental packages as a start?
>> > > [...] Since packages in experimental will never
Simon Richter writes:
> Hi,
>
> On 11/18/21 4:08 PM, Stephan Lachnit wrote:
>
>> I guess this raises the (maybe already answered) question if the
>> additional license QA from NEW is for the end-product (i.e. Debian
>> stable) or for the servers that run the Debian infrastructure, which
>> of co
On Thu, 2021-11-18 at 19:32 +0100, Philip Hands wrote:
> There is also the issue of cryptographic software, and the laws
> regarding its export from the USA, which Debian deals with by treating
> every package as though it _might_ at some point incorporate some
> crypto, and therefore registering
Stephan Lachnit writes:
> On Thu, Nov 18, 2021 at 4:16 PM Simon Richter wrote:
>>
>> On 11/18/21 4:08 PM, Stephan Lachnit wrote:
>>
>> > I guess this raises the (maybe already answered) question if the
>> > additional license QA from NEW is for the end-product (i.e. Debian
>> > stable) or for th
On Thu, 18 Nov 2021 at 19:28:28 +0500, Andrey Rahmatullin wrote:
> On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote:
> > I don't know if that has been proposed before, but how about waiving
> > the NEW queue requirement for experimental packages as a start?
> > [...] Since packages i
On Thu, Nov 18, 2021 at 4:16 PM Simon Richter wrote:
>
> On 11/18/21 4:08 PM, Stephan Lachnit wrote:
>
> > I guess this raises the (maybe already answered) question if the
> > additional license QA from NEW is for the end-product (i.e. Debian
> > stable) or for the servers that run the Debian infr
On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote:
> > > I don't know if that has been proposed before, but how about waiving
> > > the NEW queue requirement for experimental packages as a start?
> > > [...] Since packages in experimental will never land in any
> > > official release,
Hi,
On 11/18/21 4:08 PM, Stephan Lachnit wrote:
I guess this raises the (maybe already answered) question if the
additional license QA from NEW is for the end-product (i.e. Debian
stable) or for the servers that run the Debian infrastructure, which
of course includes experimental.
The latter.
On Thu, 2021-11-18 at 19:28 +0500, Andrey Rahmatullin wrote:
> On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote:
> > I don't know if that has been proposed before, but how about waiving
> > the NEW queue requirement for experimental packages as a start?
> > [...] Since packages in ex
On Thu, Nov 18, 2021 at 3:28 PM Andrey Rahmatullin wrote:
>
> On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote:
> > I don't know if that has been proposed before, but how about waiving
> > the NEW queue requirement for experimental packages as a start?
> > [...] Since packages in ex
On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote:
> I don't know if that has been proposed before, but how about waiving
> the NEW queue requirement for experimental packages as a start?
> [...] Since packages in experimental will never land in any
> official release, I think droppin
On Thu, Nov 18, 2021 at 11:52 AM Gard Spreemann wrote:
>
> Every time I see stories like this, I wonder what the consequences of
> the NEW queue's current workings are. This is *not* criticism of the
> heroic work of the FTP Masters, nor is it criticism of the objectives
> they have in processing
Hi list,
On 18/11/2021 11:51, Gard Spreemann wrote:
Apologies in advance if this is something that has been discussed a lot
in the past. I'd be very interested in being pointed in the right
direction in that case!
No need to apologize... searching the the devel archives on "NEW queue"
reveal
Hi all.
Johannes Schauer Marin Rodrigues writes:
> slightly related question: if I upload a new version to NEW, will the Age of
> the package be reset? I'm asking because my package has been in NEW for four
> months already and I'd like to avoid loosing that place by an upload of a new
> upstrea
Quoting Johannes Schauer Marin Rodrigues (2021-11-18 11:26:44)
> Quoting Tobias Frost (2021-11-18 10:38:40)
> > (speculatinng on the why you want it rejected: if you want to replace it
> > with e.g. a newer version, you can just upload the new version)
>
> slightly related question: if I upload a
Quoting Tobias Frost (2021-11-18 10:38:40)
> (speculatinng on the why you want it rejected: if you want to replace it with
> e.g. a newer version, you can just upload the new version)
slightly related question: if I upload a new version to NEW, will the Age of
the package be reset? I'm asking bec
Am 18. November 2021 10:30:37 MEZ schrieb Stephan Lachnit
:
>I tried to remove a package from NEW with `dcut rm package.deb`, `dcut
>rm package.changes` and `dcut cancel package.changes`, but nothing
>worked.
>Is there even a way to remove a package from NEW?
>
>Regards,
&
I tried to remove a package from NEW with `dcut rm package.deb`, `dcut
rm package.changes` and `dcut cancel package.changes`, but nothing
worked.
Is there even a way to remove a package from NEW?
Regards,
Stephan
: Apache 2.0
Programming Lang: Python 3
Description : Remove TrueType and OpenType bytecodes and tables from font
files
Taken from project readme:
dehinter is a Python command line application that removes TrueType
instruction sets, global hinting tables, and other associated
/packages/strip#readme
* License : Expat
Programming Lang: Javascript
Description : Rollup plugin to remove debugger statements and functions
This is a plugin for rollup module bundler to remove debugger statements
and functions like assert.equal and console.log from your code. This
m an "how do I use this feature" perspective, I would recommend that
> you/people wait until relevant wiring has been added to debhelper.
>
> ~Niels
>
Hi,
I just uploaded debhelper/13.5 that adds support for the new feature via
the following methods:
* Use of "rm_conff
Ludovic Rousseau:
> Hello Niels,
>
> Le 08/08/2021 à 09:09, Niels Thykier a écrit :
>> Ludovic Rousseau:
>>> [...]
>>
>> Hi Ludovic,
>>
>> You cannot use that feature yet as it would break during upgrade. The
>> dpkg version in stable does not support the feature. Which is also why
>> there is no
Hello Niels,
Le 08/08/2021 à 09:09, Niels Thykier a écrit :
Ludovic Rousseau:
Hello,
I am fixing Debian bug #990154.
After some work I am able to remove the obsolete conf file using:
rm_conffile /etc/reader.conf.d/0comments 1.9.3-2~ pcscd
in debian/pcscd.maintscript
Nice.
Now I would like
Ludovic Rousseau:
> Hello,
>
> I am fixing Debian bug #990154.
>
> After some work I am able to remove the obsolete conf file using:
> rm_conffile /etc/reader.conf.d/0comments 1.9.3-2~ pcscd
> in debian/pcscd.maintscript
>
> Nice.
> Now I would like to use the meth
Hello,
I am fixing Debian bug #990154.
After some work I am able to remove the obsolete conf file using:
rm_conffile /etc/reader.conf.d/0comments 1.9.3-2~ pcscd
in debian/pcscd.maintscript
Nice.
Now I would like to use the method documented in deb-conffiles
https://manpages.debian.org/unstable
On 2021-03-07 Hideki Yamane wrote:
> X-debbugs-CC: debian-devel@lists.debian.org
> I've tried to remove files that was accidentally containts empty " ",
> comma "," and wildcard "*" via rm_conffile from dpkg-maintscript-helper.
> However, it
X-debbugs-CC: debian-devel@lists.debian.org
Hi,
I've tried to remove files that was accidentally containts empty " ",
comma "," and wildcard "*" via rm_conffile from dpkg-maintscript-helper.
However, it returns an error like below.
> dh_installdeb
: GPL3+
Programming Lang: Emacs-Lisp
Description : remove visual distractions and focus on writing
darkroom-mode makes visual distractions disappear: the mode-line
is temporarily elided, text is enlarged and margins are adjusted
so that it's centered on the window.
On Sat, 11 Jul 2020, Henrique de Moraes Holschuh wrote:
> On Sat, 11 Jul 2020, Niels Thykier wrote:
> > This is a heads up about my intention to remove debhelper compat levels
> > 5 and 6. This is also an intention to do a MFB for this removal now at
>
> ...
>
> >
On Sat, 11 Jul 2020, Niels Thykier wrote:
> This is a heads up about my intention to remove debhelper compat levels
> 5 and 6. This is also an intention to do a MFB for this removal now at
...
> Henrique de Moraes Holschuh
>freepats
Oh wow, I haven't looked at this pack
Hi,
This is a heads up about my intention to remove debhelper compat levels
5 and 6. This is also an intention to do a MFB for this removal now at
severity important, which will be bumped to RC later.
With the current rate of migration as well as the current number of RC
bugs in testing, I
Hi Ted,
On Sun, Jan 26, 2020 at 4:54 AM Theodore Y. Ts'o wrote:
> So it's stupid stuff like the choice of compilers and CFLAGS
At this point, wireguard-tools package is reproducible actually. At
some point it wasn't, due to some older versions (but not all older
versions!) of make(1) passing GLO
On Tue, Jan 21, 2020 at 05:15:16PM +0100, Jason A. Donenfeld wrote:
> The comment itself doesn't indicate to me (upstream) much at all, and
> a pretty ordinary attempt to figure out what it means didn't yield
> much
Hi Jason,
At least in my experience, most of the time when there are
reproduc
On Wed, Jan 22, 2020 at 10:01:35AM +0500, Alexander E. Patrakov wrote:
> Unfortunately, this message is still non-ideal, because it contains a dead
> link.
I left the dead link as as such it still contained useful information,
while removing the link would have removed that info.
(And now the is
(got a "550 5.6.0 improper use of 8-bit data in message header",
resending without S-MIME signature, sorry for the duplicate)
Holger Levsen wrote:
I've improve it like this now:
$ git log -p -1
commit 172f203eab628bd5df0106b33153dc428d12dd5c
Author: Holger Levsen
Date: Tue Jan 21 18:07:14
Hi Jason,
thanks for reaching out to us!
On Tue, Jan 21, 2020 at 05:15:16PM +0100, Jason A. Donenfeld wrote:
> I received a reply about not providing "private support"
I believe this is some unfortunate wording from someone to busy. I
believe it was meant to say "please send this request to a
On Tue, Jan 21, 2020 at 5:25 PM Sam Hartman wrote:
>
> > "Jonathan" == Jonathan Carter writes:
>
> Jonathan> On 2020/01/21 16:43, Jason A. Donenfeld wrote:
> >> This note doesn't make sense. It's either entirely invalid or so poorly
> >> written that it's useless. As the author of
On Tue, Jan 21, 2020 at 5:10 PM Jonathan Carter wrote:
>
> On 2020/01/21 16:43, Jason A. Donenfeld wrote:
> > This note doesn't make sense. It's either entirely invalid or so poorly
> > written that it's useless. As the author of the code in question, I've
> > been unable to ascertain what the not
> "Jonathan" == Jonathan Carter writes:
Jonathan> On 2020/01/21 16:43, Jason A. Donenfeld wrote:
>> This note doesn't make sense. It's either entirely invalid or so poorly
>> written that it's useless. As the author of the code in question, I've
>> been unable to ascertain wha
On 2020/01/21 16:43, Jason A. Donenfeld wrote:
> This note doesn't make sense. It's either entirely invalid or so poorly
> written that it's useless. As the author of the code in question, I've
> been unable to ascertain what the note is about, and an email to the note
> author hasn't yielded any u
This note doesn't make sense. It's either entirely invalid or so poorly
written that it's useless. As the author of the code in question, I've
been unable to ascertain what the note is about, and an email to the note
author hasn't yielded any understanding.
Signed-off-by: Jason A. Donenfeld
---
--
Best Regards,
Brian Samson
Please excuse any typos as this was sent from my mobile phone.
/cargo-edit
* License : Apache-2.0/MIT
Programming Lang: Rust
Description : add, remove and upgrade Cargo dependencies from the command
line
cargo-edit is an extension for Cargo, the Rust package manager, that
allows users to add, remove and upgrade dependencies by modifying the
: Python
Description : tool to remove comments from Python scripts
Nudatus is a tool to remove comments from Python scripts.
It was created to help squeeze longer programs onto the micro:bit
but it should be suitable for various environments with restricted
storage.
Nudatus was designed to be
On Tue, 12 Jun 2018, Wouter Verhelst wrote:
Hi Wouter,
> On Wed, May 30, 2018 at 10:24:33AM +0200, Alexander Wirt wrote:
> > Hi,
> >
> > we still have 175GiB git repos left on alioth. Please remove them asap.
>
> Life has been busy recently, and I didn't se
Hi,
On Wed, May 30, 2018 at 10:24:33AM +0200, Alexander Wirt wrote:
> Hi,
>
> we still have 175GiB git repos left on alioth. Please remove them asap.
Life has been busy recently, and I didn't see this message until now.
I guess that alioth has been shut down by now.
Is it stil
I'm sorry but I don't remember that I have created a repo on alioth.
How can I do for deleting it?
Thanks in advance for any reply.
Pietro Prandini
On mer, 30 mag, 2018 at 10:24 , Alexander Wirt
wrote:
Hi,
we still have 175GiB git repos left on alioth. Please remove them
asap.
Em 31-05-2018 14:50, Alexander Wirt escreveu:
On Thu, 31 May 2018, Herbert Fortes wrote:
Hi,
On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote:
On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:
There it doesn't make sense to keep anything on alioth which is also on
On Thu, 31 May 2018, Herbert Fortes wrote:
> Hi,
>
> > On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote:
> > > On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:
> > > > There it doesn't make sense to keep anything on alioth which is also on
> > > > salsa. Everything els
Hi,
On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote:
On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:
There it doesn't make sense to keep anything on alioth which is also on
salsa. Everything else gets archived for historical purposes.
Every repo that is on salsa a
please tell.
However I do think a better way is to check it Alioth "writes" are been
disabled.
And if so, remove the repo.
[ partitial output of `ls -ltr hooks ]
-rwxrwxr-x+ 1 mjj29Debian 452 sep 17 2011 applypatch-msg.sample
-rwxrwxr-x+ 1 mattia Debian 48 feb 20 2016 post
On Wed, 30 May 2018, Adam Borowski wrote:
> On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:
> > There it doesn't make sense to keep anything on alioth which is also on
> > salsa. Everything else gets archived for historical purposes.
> > Every repo that is on salsa and alioth will
1 - 100 of 1131 matches
Mail list logo
