Package: wnpp
Severity: wishlist
Owner: Ralf Treinen
* Package name: ocaml-fpath
Version : 0.7.2
Upstream Author : Daniel Bünzli
* URL : https://erratique.ch/software/fpath
* License : ISC
Programming Lang: OCaml
Description : OCaml library for handlin
Package: wnpp
Severity: wishlist
Owner: Fabian Grünbichler
* Package name: cargo-deny
Version : 0.6.4
Upstream Author : Jake Shadle
* URL : https://github.com/EmbarkStudios/cargo-deny
* License : MIT or Apache-2.0
Programming Lang: Rust
Description : C
Hi folks,
I am maintainer for mg, currently on salsa. Problem is, upstream
doesn't release tar balls anymore, but moved the code to github.
No tags.
How can I tell Salsa? Should I drop the upstream and pristine-tar
branches on Salsa and integrate the repository on github? Would
you suggest to mo
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> Hi folks,
>
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
> No tags.
>
> How can I tell Salsa? Should I drop the upstream and pristine-tar
> bra
On Sat, Feb 15, 2020 at 12:05:29AM -0500, Jerome Charaoui wrote:
>
> Following the announcement of the DebConf20 location, our desire to
> participate became incompatible with our commitment toward the Boycott,
> Divestment and Sanctions (BDS) campaign launched by Palestinian civil
> society in 20
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> Hi folks,
>
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
> No tags.
>
> How can I tell Salsa?
Question seen.
However I think the question does
On Sat, Feb 15, 2020 at 08:33:25AM -0500, Roberto C. Sánchez wrote:
> On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> > Hi folks,
> >
> > I am maintainer for mg, currently on salsa. Problem is, upstream
> > doesn't release tar balls anymore, but moved the code to github.
> > No ta
fwiw, looking at the repo on github. There are tags. They're just dates,
Ideally one would get an idea of what the tags are from upstream, but you
could just git clone using a tag. Also github allows you to easily get a
tarball given a tag:
wget https://github.com/hboetes/mg/tarball/20180927
On Sat, Feb 15, 2020 at 02:41:59PM +0100, Geert Stappers wrote:
> On Sat, Feb 15, 2020 at 08:33:25AM -0500, Roberto C. Sánchez wrote:
> > On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> > > Hi folks,
> > >
> > > I am maintainer for mg, currently on salsa. Problem is, upstream
> >
On 2/15/20 2:44 PM, Peter Silva wrote:
fwiw, looking at the repo on github. There are tags. They're just dates,
Ideally one would get an idea of what the tags are from upstream, but you could
just git clone using a tag. Also github allows you to easily get a tarball
given a tag:
wget https:
On Sat, Feb 15, 2020 at 03:00:52PM +0100, Harald Dunkel wrote:
> On 2/15/20 2:44 PM, Peter Silva wrote:
> > fwiw, looking at the repo on github. There are tags. They're
> > just dates, Ideally one would get an idea of what the tags are from
> > upstream, but you could just git clone using a tag.
Quoting Harald Dunkel (2020-02-15 14:16:27)
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
> No tags.
>
> How can I tell Salsa? Should I drop the upstream and pristine-tar
> branches on Salsa and integrate the r
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
* Package name: ordered-map
Version : 0.8.1
Upstream Author : Tessil
* URL or Web page : https://github.com/Tessil/ordered-map/releases
* License : MIT
Description : C++ insertion-order-preserving hash map and hash
Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias
* Package name: scalene
Version : 0.7.5
Upstream Author : Emery Berger
* URL : https://github.com/emeryberger/scalene
* License : Apache
Programming Lang: Python
Description : high-performance, hig
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> Problem is, upstream doesn't release tar balls anymore, but moved the
> code to github. No tags.
If you can get upstream to tag releases, then the "When upstream uses
Git" section of the git-buildpackage manual will be useful:
http:
On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote:
> Hi folks,
>
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
> No tags.
>
> How can I tell Salsa? Should I drop the upstream and pristine-tar
> branches o
On Fri, 2020-02-14 at 15:46 +, Dimitri John Ledkov wrote:
> Can a Debian Package Maintainer require CLA for accepting packaging
> changes and distro patches to be uploaded into Debian itself?
>
> (case in point, debian maintainer & upstream wear the same hat, and
> maintain upstream code & pac
On Sat, 2020-02-15 at 18:26 +0100, Geert Stappers wrote:
> On Sat, Feb 15, 2020 at 05:02:03PM +, Ben Hutchings wrote:
> > On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote:
> > > Hi folks,
> > >
> > > I am maintainer for mg, currently on salsa. Problem is, upstream
> > > doesn't release t
Hi Harald
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote:
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
This is nothing uncommon.
> No tags.
So this upstream doesn't make releases but only pro
Hello,
afaict we are moving to a usrmerge setup, i.e. with /lib just a
symlink to /usr/lib. So shouldn't packages start installing stuff to
/usr/lib instead of /lib? I would like to do that for libgcrypt, since
I would be able to shorten debian/rules by stopping to split stuff
between /lib (.so) a
On Sat, Feb 15, 2020 at 05:33:51PM +, Ben Hutchings wrote:
> On Sat, 2020-02-15 at 18:26 +0100, Geert Stappers wrote:
> > On Sat, Feb 15, 2020 at 05:02:03PM +, Ben Hutchings wrote:
> > > On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote:
> > > > Hi folks,
> > > >
> > > > I am maintain
On Sat, 2020-02-15 at 18:31 +0100, Andreas Metzler wrote:
> Hello,
>
> afaict we are moving to a usrmerge setup, i.e. with /lib just a
> symlink to /usr/lib. So shouldn't packages start installing stuff to
> /usr/lib instead of /lib? I would like to do that for libgcrypt, since
> I would be able t
On 2020-02-15 18:29 +, Ben Hutchings wrote:
> On Sat, 2020-02-15 at 18:31 +0100, Andreas Metzler wrote:
>> Hello,
>>
>> afaict we are moving to a usrmerge setup, i.e. with /lib just a
>> symlink to /usr/lib. So shouldn't packages start installing stuff to
>> /usr/lib instead of /lib? I would l
On Feb 15, Sven Joachim wrote:
> True, but there seem to be a relatively high number of systems where an
> old unowned version of some library is lying around under /lib (possibly
> because the dpkg database became corrupted at some point and so dpkg
> forgot about the file; see the dpkg bug #949
On Feb 15, Harald Dunkel wrote:
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
I plan to do something like this for ppp, which now has a proper
upstream git repository but no actual releases in a long time:
Am 15.02.20 um 19:48 schrieb Sven Joachim:
> True, but there seem to be a relatively high number of systems where an
> old unowned version of some library is lying around under /lib (possibly
> because the dpkg database became corrupted at some point and so dpkg
> forgot about the file; see the dp
On 2/15/20 3:14 PM, Geert Stappers wrote:
> FWIW Consider to use email address m...@packages.debian.org for it.
>
>[...]
> The idea is that it helps you to explain that you are maintainer
> of the package in Debian. Hope this helps.
So far I did not find a single upstream that was not abl
On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote:
> On Feb 15, Sven Joachim wrote:
> > True, but there seem to be a relatively high number of systems where an
> > old unowned version of some library is lying around under /lib (possibly
> > because the dpkg database became corrupted at some
Hi!
On Sat, 2020-02-15 at 18:31:32 +0100, Andreas Metzler wrote:
> afaict we are moving to a usrmerge setup, i.e. with /lib just a
> symlink to /usr/lib. So shouldn't packages start installing stuff to
> /usr/lib instead of /lib? I would like to do that for libgcrypt, since
> I would be able to sh
Am 15.02.20 um 23:11 schrieb Guillem Jover:
> On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote:
>> On Feb 15, Sven Joachim wrote:
>>> True, but there seem to be a relatively high number of systems where an
>>> old unowned version of some library is lying around under /lib (possibly
>>> bec
On Sat, 2020-02-15 at 23:27:08 +0100, Michael Biebl wrote:
> Those issues happen on non-usr-merged systems.
The one report against dpkg sure. I'm talking about the ones with
disappearing pathnames, in case that was part of "similar". But if it
was not, then libcrypt is still just broken on usrmerg
On Feb 15, Guillem Jover wrote:
> > Somebody reported a similar problem about libcrypt.so.1, which moved
> > from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt).
> If the problem was with the new pathname disappearing, then that's just
> yet another instance of the usrmerge-via-sy
Adam Borowski wrote:
>On Wed, Feb 12, 2020 at 06:10:53PM +, Steve McIntyre wrote:
>>
>> /me ponders - this could be a fun task for a GSoC/outreachy student to
>> hack on, maybe?
>
>Prior art:
>
>* my unfinished https://github.com/kilobyte/crossgrade -- does a lot of
> error checking and conti
Hey John,
John Goarzen wrote:
>On Tue, Feb 04 2020, Steve McIntyre wrote:
>
>The thing that we have to remember is that an operating system is a
>platform for running software. This problem is rather thorny, because:
>
>1) Some software is provided in only binary form and cannot be
>recompiled
O
anth...@derobert.net wrote:
...
>Lastly, 64-bit time_t has been tested widely (e.g., on amd64). That's not
>perfect of
>course since 32-bit archs have smaller basic integer types, but likely a lot
>less work
>fixing the stray "int"s than adding epochs all over the place.
>
>PS: Debian-devel is
Hello,
On Mon 10 Feb 2020 at 04:29PM +11, Dmitry Smirnov wrote:
> No. ITPs are opportunities to team up with others, not merely for de-
> duplication.
For many small packages there is simply no need for teaming up at the
stage of uploading to NEW.
> That might be a valid situation but neverthel
Hello,
On Sat 15 Feb 2020 at 02:16PM +01, Harald Dunkel wrote:
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
> No tags.
>
> How can I tell Salsa? Should I drop the upstream and pristine-tar
> branches on Salsa
Hello,
On Sat 15 Feb 2020 at 06:45PM -07, Sean Whitton wrote:
> git remote add -f upstream https://github.com/hboetes/mg
> git tag -s upstream/0+git20200215.1.3992db3 3992db3
> git merge upstream/0+git20200215.1.3992db3
> dch -v0+git20200215.1.3992db3-1 New upstream release.
... and then `git de
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-yuin-goldmark-highlighting
Version : 0.0~git20191202.78f32c8-1
Upstream Author : Yusuke Inuzuka
* URL : https://github.com/yuin/goldmark-highlighting
* License : Expat
Programmi
39 matches
Mail list logo
