Accepted libsyntax-keyword-try-perl 0.29-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 08 Mar 2024 20:04:16 +0100 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.29-2 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Closes: 1048889 Changes

Re: build profile proposal: nogir (second try)

On Wed, Jan 24, 2024 at 06:30:02PM +, Alberto Garcia wrote: > - Are packages that ship gobject-introspection files supposed to have >in the relevant build dependencies (gir1.2-*-dev, > gobject-introspection ?), or is the build profile handling this > automatically? This is not

Re: build profile proposal: nogir (second try)

As Johannes mentioned earlier in this thread, the first piece of practical advice on nogir should be: if you don't know that you need to use it, then perhaps you shouldn't. It's primarily aimed at breaking cycles, and enabling buildability in lower-level packages during bootstrapping. (Having

Re: build profile proposal: nogir (second try)

On Wed, Jan 17, 2024 at 10:00:35PM +, Simon McVittie wrote: > Here is the draft text that I added to the GObject-Introspection > mini-policy in 1.78.1-11: Hi, thanks for the explanation. A couple of questions about this: - Are packages that ship gobject-introspection files supposed to have

Re: build profile proposal: nogir (second try)

profiles and that was a bad idea. What stages are needed can (and does) change. For instance, we no longer need glibc's stage1 profile and go to stage2 directly. Hence, we try to more and more use profiles that change a particular aspect of a package in an obvious and isolated way and ext

Re: build profile proposal: nogir (second try)

On Thu, 18 Jan 2024 at 11:08:30 +0100, Helmut Grohne wrote: > On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote: > > The only package where I'm sure that I intend to separate out the GIR > > XML in the short term is src:glib2.0 > > How annoying would it actually be to split this to a

Re: build profile proposal: nogir (second try)

On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote: > On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: > > Does this mean we should should split out the .gir XML files from existing > > source packages into a separate gir1.2-foo-dev (in the long run) ? > > That's a good

Re: build profile proposal: nogir (second try)

Hi, On 2024-01-18 00:38, Simon McVittie wrote: On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: Am 17.01.24 um 23:00 schrieb Simon McVittie: > Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the > C headers, but recent versions of gobject-introspection define

Re: build profile proposal: nogir (second try)

On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote: > Am 17.01.24 um 23:00 schrieb Simon McVittie: > > Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the > > C headers, but recent versions of gobject-introspection define a canonical > > virtual package name

Re: build profile proposal: nogir (second try)

Am 17.01.24 um 23:00 schrieb Simon McVittie: Last year, Helmut Grohne proposed a nogir build profile to help with cross-compiling the GLib ecosystem: . After some discussion on #1030223, I have a revised proposal, with the same name

build profile proposal: nogir (second try)

Last year, Helmut Grohne proposed a nogir build profile to help with cross-compiling the GLib ecosystem: . After some discussion on #1030223, I have a revised proposal, with the same name but slightly different rules: profile name:

Accepted libsyntax-keyword-try-perl 0.29-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 17 Jul 2023 19:11:22 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.29-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.28-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 03 Jul 2023 19:08:51 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.28-2 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.28-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 16 Dec 2022 19:42:39 +0100 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.28-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted golang-github-matryer-try 1+git20161228.6.9ac251b-4 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 06 Apr 2022 06:16:26 -0600 Source: golang-github-matryer-try Architecture: source Version: 1+git20161228.6.9ac251b-4 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Anthony Fok Changes

Accepted golang-github-matryer-try 1+git20161228.6.9ac251b-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 05 Apr 2022 12:07:01 +0200 Source: golang-github-matryer-try Architecture: source Version: 1+git20161228.6.9ac251b-3 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Thomas Goirand

Accepted libfeature-compat-try-perl 0.05-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 25 Feb 2022 22:51:38 +0100 Source: libfeature-compat-try-perl Architecture: source Version: 0.05-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libfeature-compat

Accepted libsyntax-keyword-try-perl 0.27-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 25 Feb 2022 17:52:30 +0100 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.27-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.26-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 15 Oct 2021 17:42:31 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.26-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.25-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 29 Sep 2021 15:58:02 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.25-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libfeature-compat-try-perl 0.04-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 29 Sep 2021 01:28:55 -0400 Source: libfeature-compat-try-perl Architecture: source Version: 0.04-2 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: Andrius Merkys Changes: libfeature-compat

Accepted libfeature-compat-try-perl 0.04-1 (source all) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 2 Sep 2021 01:21:16 -0400 Source: libfeature-compat-try-perl Binary: libfeature-compat-try-perl Architecture: source all Version: 0.04-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group Changed-By: Andrius

Accepted libsyntax-keyword-try-perl 0.24-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 02 Sep 2021 01:47:53 -0400 Source: libsyntax-keyword-try-perl Binary: libsyntax-keyword-try-perl libsyntax-keyword-try-perl-dbgsym Architecture: source amd64 Version: 0.24-1 Distribution: unstable Urgency: medium Maintainer

Accepted libsyntax-keyword-try-perl 0.21-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 25 Jan 2021 19:13:22 +0100 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.21-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted golang-github-matryer-try 1+git20161228.6.9ac251b-2.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 08 Jan 2021 14:59:35 +0100 Source: golang-github-matryer-try Architecture: source Version: 1+git20161228.6.9ac251b-2.1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Holger Levsen

Accepted libsyntax-keyword-try-perl 0.20-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 26 Nov 2020 19:04:33 +0100 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.20-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.18-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 02 Aug 2020 15:12:29 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.18-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.16-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 25 Jul 2020 17:09:54 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.16-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.15-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 23 Jul 2020 18:41:16 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.15-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted rust-try-or 0.2.0-1 (amd64 source) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 6 Apr 2020 18:44:42 CEST Source: rust-try-or Binary: librust-try-or-dev Architecture: amd64 source Version: 0.2.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Andrej Shadura

Accepted libsyntax-keyword-try-perl 0.14-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 11 Jul 2020 16:22:46 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.14-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.13-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 03 Jul 2020 19:44:59 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.13-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file

Description : Try to find a password of a encrypted wallet file The program tries to decrypt one of the encrypted addresses in the wallet by trying all the possible passwords. It is especially useful if you know something about the password (i.e. you forgot a part of your password but still

Accepted rust-try-from 0.3.2-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 24 Jan 2020 07:58:20 +0100 Source: rust-try-from Architecture: source Version: 0.3.2-2 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Wolfgang Silbermayr Changes: rust-try-from

Accepted rust-try-from 0.3.2-1 (source amd64) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 23 Oct 2019 23:43:56 +0200 Source: rust-try-from Binary: librust-try-from-dev Architecture: source amd64 Version: 0.3.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Wolfgang

Accepted libsyntax-keyword-try-perl 0.11-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 07 Sep 2019 14:14:17 +0200 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.11-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Accepted libsyntax-keyword-try-perl 0.10-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 19 Jul 2019 16:23:29 -0300 Source: libsyntax-keyword-try-perl Architecture: source Version: 0.10-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: gregor herrmann Changes: libsyntax-keyword

Re: The Difference between debcheckout and dgit and what they try to accomplish

Hello, On Wed 19 Jun 2019 at 11:51pm +0200, Wouter Verhelst wrote: > On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote: >> We could try to write a tool which tries to guess and convert (e.g.) the >> dgit view with your changes into a maintainer workflow, but the

Re: The Difference between debcheckout and dgit and what they try to accomplish

Ansgar Burchardt writes: > On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote: >> This reminds me of something that popped up in a dinner discussion a few >> days ago: mandate documenting workflow in debian/README.source no matter >> what, and allow to symlink that file to a repository in >>

Re: The Difference between debcheckout and dgit and what they try to accomplish

Hi Enrico, > This reminds me of something that popped up in a dinner discussion a few > days ago: mandate documenting workflow in debian/README.source no matter > what, and allow to symlink that file to a repository in > /usr/share/doc/somewhere/ as we do for common licenses. I do like the

Re: The Difference between debcheckout and dgit and what they try to accomplish

On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote: > This reminds me of something that popped up in a dinner discussion a few > days ago: mandate documenting workflow in debian/README.source no matter > what, and allow to symlink that file to a repository in > /usr/share/doc/somewhere/ as we do

Re: The Difference between debcheckout and dgit and what they try to accomplish

On Wed, Jun 19, 2019 at 11:51:14PM +0200, Wouter Verhelst wrote: > What if you took away the necessary guesswork? > > Have dgit support a field in debian/control that, if it exists, explains > to dgit (and any other tool that might care) what the workflow type is. > This would require a

Re: The Difference between debcheckout and dgit and what they try to accomplish

Russ Allbery writes: > Colin Watson writes: >> Is it at all likely that the ftpmaster api service might migrate away >> from Let's Encrypt at this point? I would assume probably not. In that >> case, you could at least make the situation substantially better with no >> further DSA work required

Re: The Difference between debcheckout and dgit and what they try to accomplish

On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote: > We could try to write a tool which tries to guess and convert (e.g.) the > dgit view with your changes into a maintainer workflow, but there are > large obstacles to this working reliably. For example, there exist edg

Re: The Difference between debcheckout and dgit and what they try to accomplish

Sam Hartman writes: >> "Russ" == Russ Allbery writes: > Russ> debian.org already publishes a CAA record, which conveys that > Russ> information (although has its own verification concerns, but I > Russ> think debian.org is using DNSSEC so you can verify the record > Russ>

Re: The Difference between debcheckout and dgit and what they try to accomplish

> "Russ" == Russ Allbery writes: Russ> Colin Watson writes: >> Is it at all likely that the ftpmaster api service might migrate >> away from Let's Encrypt at this point? I would assume probably >> not. In that case, you could at least make the situation >>

Re: The Difference between debcheckout and dgit and what they try to accomplish

Colin Watson writes: > Is it at all likely that the ftpmaster api service might migrate away > from Let's Encrypt at this point? I would assume probably not. In that > case, you could at least make the situation substantially better with no > further DSA work required by pinning the

Re: The Difference between debcheckout and dgit and what they try to accomplish

On Wed, Jun 19, 2019 at 01:57:39PM +0100, Ian Jackson wrote: > FTAOD: I have a memory that in response to Hector Oron's message #20 > in that bug, I did try to have a conversation on debian-admin, but > that I found that conversation very frustrating. I did not feel that > the D

Re: The Difference between debcheckout and dgit and what they try to accomplish

Ian Jackson writes ("Re: The Difference between debcheckout and dgit and what they try to accomplish"): > Hector: If it would be useful to you, I could tell you a set of dgit > configuration settings to have it use the apt repository fetching > method. That would rely, therefo

Re: The Difference between debcheckout and dgit and what they try to accomplish

0093). FTAOD: I have a memory that in response to Hector Oron's message #20 in that bug, I did try to have a conversation on debian-admin, but that I found that conversation very frustrating. I did not feel that the DSA members I was talking to were listening very well. Probably, they fe

Re: The Difference between debcheckout and dgit and what they try to accomplish

Hello Helmut, On Mon 17 Jun 2019 at 06:21pm +0200, Helmut Grohne wrote: > Presently, no. I attempted using it, but I feel that the extra > complexity did not help my use case. dgit solves a difficult problem and > that comes at a cost. Verification of source integrity is much more > difficult to

Re: The Difference between debcheckout and dgit and what they try to accomplish

Hi, Let me try to answer multiple mails as one: On Mon, Jun 17, 2019 at 07:44:39AM +0200, Andreas Tille wrote: > In other words: If vcs-git would be uniform would this be more > attractive to you? Maybe. Uniformity certainly is an important property to me. Having to figure out dif

Re: The Difference between debcheckout and dgit and what they try to accomplish

Sean Whitton writes ("Re: The Difference between debcheckout and dgit and what they try to accomplish"): > It would seem, then, that what we want is merge requests against our > interchange format: the source packages that actually get uploaded. Or, > in other words, we

Re: The Difference between debcheckout and dgit and what they try to accomplish

Sam Hartman writes ("Re: The Difference between debcheckout and dgit and what they try to accomplish"): > But my reading of the discussion so far is that people see getting > patches actually integrated as a pain point. ... > In the debian-vote discussion people were talking ab

Re: The Difference between debcheckout and dgit and what they try to accomplish

It's a dgit design goal not to require standardising the workflows of maintainer views, for roughly these reasons.) With that assumption made, however, submitting merge requests against maintainer views on salsa now faces the problem that doing so requires knowledge of the workflow the maint

Re: The Difference between debcheckout and dgit and what they try to accomplish

On 17.06.19 06:53, Helmut Grohne wrote: > Whether I use apt-get source and debdiff or dgit > and git format-patch is a detail on my side. out of curiosity (and because i usually quite enjoy your patches): do you do use dgit in *your* workflow? fgmadsr IOhannes

Re: The Difference between debcheckout and dgit and what they try to accomplish

On Mon, Jun 17, 2019 at 06:53:05AM +0200, Helmut Grohne wrote: > > Still, vcs-git is not my preferred interface to the archive, because its > lack of uniformity makes using it unproductive for me. In other words: If vcs-git would be uniform would this be more attractive to you? Kind regards

Re: The Difference between debcheckout and dgit and what they try to accomplish

Hi Sam, On Sun, Jun 16, 2019 at 08:08:51PM -0400, Sam Hartman wrote: > Ian> That depends, I think, on whether you are trying to (a) join a > Ian> maintainer team, or do "maintainer-like" work; or, (b) do > Ian> cross-archive work with small changes to many packages, or > Ian>

Re: The Difference between debcheckout and dgit and what they try to accomplish

at discussion on other things needs to be inscope. If we're solving one problem at a time, we need to include discussion of future related work as it impacts our current discussion. >> What I do know is that I think I'm already worried about whether >> the discussion is to

Re: The Difference between debcheckout and dgit and what they try to accomplish

I haven't really organised my thoughts and have been travelling a lot and am very tired, so this is a bit bitty. I may respond more usefully in a day or two: Sam Hartman writes ("The Difference between debcheckout and dgit and what they try to accomplish"): > Debcheckout allo

The Difference between debcheckout and dgit and what they try to accomplish

valuable: I don't think all the people involved in the debian-vote discussion earlier this year understood the difference adequately. What I do know is that I think I'm already worried about whether the discussion is too big. I'm going to try and focus on what I said I'd focus on because that's

Accepted rust-try-lock 0.2.2-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 29 Jul 2018 08:33:15 -0700 Source: rust-try-lock Binary: librust-try-lock-dev Architecture: source Version: 0.2.2-2 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Ximin Luo

Accepted rust-try-lock 0.2.2-1 (amd64 source) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 15 Jul 2018 22:26:13 PDT Source: rust-try-lock Binary: librust-try-lock-dev Architecture: amd64 source Version: 0.2.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Rust Maintainers Changed-By: Wolfgang

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

Alexander Wirt writes ("Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all"."): > You are completly right. Thats why I said I will stop answering questions > here. This will help me to come down. For my part

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On Wed, 30 May 2018, Chris Lamb wrote: Hi, > > I am not a kindergarten teacher. I will just stop answering mails here. > > You must know I have the greatest of respect for the tireless work you > have done and continue to do so as part of the migration from Alioth > to salsa. > > You are

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

Dear Alexander (et al.), > I am not a kindergarten teacher. I will just stop answering mails here. You must know I have the greatest of respect for the tireless work you have done and continue to do so as part of the migration from Alioth to salsa. You are actually not privy to the number of

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

Hi Alexander, On Wed, May 30, 2018 at 02:12:38PM +0200, Alexander Wirt wrote: > > > In this particular case, that environment is Salsa. If course there > > will always be mistakes and people will overlook things. But if you > > find that you are having to explain similar things over and over

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On Wed, 30 May 2018, Ian Jackson wrote: > Alexander Wirt writes ("Re: remote: GitLab: LFS objects are missing. Ensure > LFS is properly set up or try a manual "git lfs push --all"."): > > Alex - fed up with explaining the same things again and again an

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On Wed, 30 May 2018, Ian Jackson wrote: > Alexander Wirt writes ("Re: remote: GitLab: LFS objects are missing. Ensure > LFS is properly set up or try a manual "git lfs push --all"."): > > Alex - fed up with explaining the same things again and again an

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

Alexander Wirt writes ("Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all"."): > Alex - fed up with explaining the same things again and again and again Debian contributors are not, by and large, stupid or lazy.

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

ing objects: 100% (4453/4453), done. > Writing objects: 100% (4599/4599), 64.56 MiB | 462.00 KiB/s, done. > Total 4599 (delta 811), reused 1 (delta 0) > remote: Resolving deltas: 100% (811/811), completed with 1 local object. > remote: GitLab: LFS objects are missing. Ensure LFS is properly se

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On Wed, 30 May 2018, Geert Stappers wrote: > On Wed, May 30, 2018 at 11:19:14AM +0200, Alexander Wirt wrote: > > On Wed, 30 May 2018, Andreas Tille wrote: > > > Hi again, > > :-) > > > > > On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote: > > > > > > Your repo has lfs

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On 30/05/18 11:40, Geert Stappers wrote: > On Wed, May 30, 2018 at 11:19:14AM +0200, Alexander Wirt wrote: >> On Wed, 30 May 2018, Andreas Tille wrote: >>> Hi again, > > :-) > > >>> On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote: >> Your repo has lfs disabled. You should

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On Wed, May 30, 2018 at 11:19:14AM +0200, Alexander Wirt wrote: > On Wed, 30 May 2018, Andreas Tille wrote: > > Hi again, :-) > > On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote: > > > > > Your repo has lfs disabled. You should enable it. > > > > > > > > How can I do this? >

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

On Wed, 30 May 2018, Andreas Tille wrote: > Hi again, > > On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote: > > > > Your repo has lfs disabled. You should enable it. > > > > > > How can I do this? > > > I've just found[1]: "Your administrator only need to enable the LFS > > >

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

eltas: 100% (811/811), completed with 1 local object. remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all". To salsa.debian.org:med-team/gatk.git ! [remote rejected] master -> master (pre-receive hook declined) ! [remote rejec

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

(4599/4599), 64.56 MiB | 1.09 MiB/s, done. > > > Total 4599 (delta 811), reused 1 (delta 0) > > > remote: Resolving deltas: 100% (811/811), completed with 1 local object. > > > remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or > > > try a manual &

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

e: Resolving deltas: 100% (811/811), completed with 1 local object. > > remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or > > try a manual "git lfs push --all". > > To salsa.debian.org:med-team/gatk.git > > ! [remote rejected] master -> mas

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

l object. > remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try > a manual "git lfs push --all". > To salsa.debian.org:med-team/gatk.git > ! [remote rejected] master -> master (pre-receive hook declined) > ! [remote rejected] pristine-tar -> pr

remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

/4453), done. Writing objects: 100% (4599/4599), 64.56 MiB | 1.09 MiB/s, done. Total 4599 (delta 811), reused 1 (delta 0) remote: Resolving deltas: 100% (811/811), completed with 1 local object. remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push

Accepted golang-github-matryer-try 1+git20161228.6.9ac251b-2 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 10 Apr 2018 09:13:03 -0600 Source: golang-github-matryer-try Binary: golang-github-matryer-try-dev Architecture: source all Version: 1+git20161228.6.9ac251b-2 Distribution: unstable Urgency: medium Maintainer: Debian Go

Accepted libsyntax-keyword-try-perl 0.09-1 (source amd64) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 20 Jan 2018 02:41:43 +0100 Source: libsyntax-keyword-try-perl Binary: libsyntax-keyword-try-perl Architecture: source amd64 Version: 0.09-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group <pkg-p

Bug#887801: ITP: libsyntax-keyword-try-perl -- try/catch/finally syntax for perl

Package: wnpp Owner: gregor herrmann <gre...@debian.org> Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-keyword-try-perl Version : 0.09 Upstream Author : Paul Evans <leon...@leonerd.org.

Accepted golang-github-matryer-try 1+git20161228.6.9ac251b-1 (source all) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 02 Aug 2017 23:56:38 -0600 Source: golang-github-matryer-try Binary: golang-github-matryer-try-dev Architecture: source all Version: 1+git20161228.6.9ac251b-1 Distribution: unstable Urgency: medium Maintainer: Debian Go

Bug#870589: ITP: golang-github-matryer-try -- Simple idiomatic retry package for Go

Package: wnpp Severity: wishlist Owner: Anthony Fok <f...@debian.org> * Package name: golang-github-matryer-try Version : 1+git20161228.6.9ac251b-1 Upstream Author : Mat Ryer * URL : https://github.com/matryer/try * License : Expat (MIT) Programming La

Bug#850123: ITP: node-has-unicode -- Try to guess if your terminal supports unicode

om/iarna/has-unicode * License : ISC Programming Lang: JavaScript Description : Try to guess if your terminal supports unicode

FTP Master move, second try | Upload queue

Hi first a short announce: Saturday (that is, 29th of October) we give it another shot of moving the ftp-master host, so expect another bit of downtime there. More importantly: With the changes to the upload queues I announced just yesterday, we turned off ftpd on the ftp-master host. Anyone who

Bug#838848: ITP: bruteforce-salted-openssl -- try to find the passphrase for files encrypted with OpenSSL

GPL-3 with OpenSSL exception Programming Lang: C Description : try to find the passphrase for files encrypted with OpenSSL bruteforce-salted-openssl try to find the passphrase or password of a file that was encrypted with the openssl command. It can be used in two ways: . - T

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Le dimanche 06 mars 2016 à 08:54:31+0100, Vincent Bernat a écrit : > ❦ 6 mars 2016 04:22 +0100, Pierre-Elliott Bécue  : > > >> > Mmh, take a look at other debian packages. It is quiet common that > >> > python > >> > packages uses sphinx as documentation framework. So it

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

❦ 6 mars 2016 04:22 +0100, Pierre-Elliott Bécue  : >> > Mmh, take a look at other debian packages. It is quiet common that python >> > packages uses sphinx as documentation framework. So it should be a already >> > solved issue - maybe ask python-debian. >> >> The easiest

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Le mardi 23 février 2016 à 08:29:37-0800, Nikolaus Rath a écrit : > On Feb 22 2016, Malte Swart wrote: > >> > - The documentation's raw rst files are currently installed; please run > >> > sphinx> > >> > during the build and ship the compiled files instead. > >> > >>

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

On Feb 22 2016, Malte Swart wrote: >> > - The documentation's raw rst files are currently installed; please run >> > sphinx> >> > during the build and ship the compiled files instead. >> >> Lintian complains about external js library that is used in html doc. >> (jquery

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Hey, On Monday 22 February 2016 04:48:51 Pierre-Elliott Bécue wrote: > > > - it does not install on Jessie (even with jessie-backports because of > > > > > > missing dependencies) (just a note because of not working on stretch > > > either) > > > > I tries Ubuntu Wily afterwards. But I good

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

On Feb 22, 2016, at 02:50 AM, Malte Swart wrote: >- Mailman does not use /etc/mailman3/mailman.cfg as default config. So to each > > mailman call a extra parameter or the environment variable > MAILMAN_CONFIG_FILE as to be added. If you forget this, mailman creates a > new instance one

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

On Feb 20, 2016, at 07:52 PM, Bernhard Schmidt wrote: >- it does not work on stretch/sid because it is not compatible with > Python 3.5, see https://gitlab.com/mailman/mailman/issues/181 Since both the latest Debian and Ubuntu releases have dropped Python 3.4 and only have Python 3.5, I'm

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

At Mon, 22 Feb 2016 02:50:44 +0100, Malte Swart wrote: > - The default configuration uses postfix, needing postmap to run mailman > aliases (which is called automatically on mailman create). So the package > should recommend/suggests postfix. If mailman 3 works with any MTA in the same way

Re: Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Le lundi 22 février 2016 à 02:50:44+0100, Malte Swart a écrit : > Hey, > > > > Before requesting for sponsorship, and packaging officially the other > > > components of mailman3, I'd like some "testers" for the core package I > > > built, in order to be sure that it works, and that I will not

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Le samedi 20 février 2016 à 19:52:49+, Bernhard Schmidt a écrit : > Pierre-Elliott Bécue wrote: > > Hi Pierre, > > > Before requesting for sponsorship, and packaging officially the other > > components of mailman3, I'd like some "testers" for the core package I > > built,

Re: Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Hey, > > Before requesting for sponsorship, and packaging officially the other > > components of mailman3, I'd like some "testers" for the core package I > > built, in order to be sure that it works, and that I will not introduce some > > stupid caveats on the packaging of the other components.

Re: [Mailman-Developers] Let's try to package mailman3 in Debian!

Pierre-Elliott Bécue wrote: Hi Pierre, > Before requesting for sponsorship, and packaging officially the other > components of mailman3, I'd like some "testers" for the core package I > built, in order to be sure that it works, and that I will not introduce some > stupid

  1   2   >