tag 947187 + wontfix
close 947187
thanks
This is now unmaintained upstream:
Note: As of June 2020 I do not have time to maintain this repository
anymore and I've thus made it read-only.
FTR, here's where I was with the packaging (the package itself could be
built, but dh_test failed):
Upstream uses hdf5plugin, but it can be patched out in 2 lines once
https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/1 is
merged.
Hi Alexandre,
I noticed opendht 2.1 is now in sid. Is there anything I can do to help
with the next steps, however you see fit?
Cheers,
--
Seb
On 04/05 10:31, Sébastien Delafond wrote:
> > I add a basic d/salsa-ci.yml, that should tell us what's going on.
>
> All the unit tests are passing in salsa:
>
> https://salsa.debian.org/debian/restinio/-/jobs/717236#L1500
Hi Alexandre,
in the current state, do you thi
On 04/05 09:18, Sébastien Delafond wrote:
> I re-ran the build this morning from the repository you created, and it
> passes here in sbuild; TTBOMK it's only binding its test router to
> 127.0.0.1, and not trying to reach anything outside, but I may be
> missing something.
>
&g
On 03/05 19:40, Alexandre Viau wrote:
> Also, I notice that the package's Changelog already has two entries,
> but was it even uploaded once? Should it say UNRELEASED instead, until
> it is uploaded, or should I understand that it was uploaded?
This was my mistake, it should have said UNRELEASED
On 27/04 13:13, Felix Salfelder wrote:
> I hope it is more clear now, how I prefer to use the small tarball
> over running the tests, as a matter of principle
It was perfectly clear the first time, and this is where we can agree to
disagree. Starting on this project I had a couple of goals, and
On 27/04 11:02, Felix Salfelder wrote:
> > - salsa-ci
> >
> > - open an issue upstream to integrate my two cmake patches for the
> > scenario "build a release without shipping binaries, yet
> > insist on running the tests during our build"
>
> I will see what I can do about these.
I've pushed my version of restinio's packaging to
https://salsa.debian.org/seb/restinio's master branch. I started from
Felix's initial effort, but a lot of things were missing:
- d/copyright severely lacking
- missing build-deps (most notably on cmake) initially prevented
building as-is
On 07/04 14:06, Alexandre Viau wrote:
> - https://bugs.debian.org/950198
Hi Alexandre,
I will look into Felix's packaging of restinio soon.
Cheers,
--
Seb
retitle -1 ITP: pyhst2 -- Python High Speed Tomographic reconstruction
tag -1 + pending
owner -1 s...@debian.org
thanks
retitle 723017 ITP: xrayutilities -- Python x-ray data reduction and analysis
owner 723017 s...@debian.org
tag 723017 + pending
thanks
On 08/01 09:56, tho...@koch.ro wrote:
> I intend to start using org-drill again once it is in Debian.
> I've never sponsored yet, but I'm a DD now and should learn how to do it.
> So I can upload.
Perfect: it's a much better solution than me uploading it.
Cheers,
--
Seb
On 07/01 15:07, Nicholas D Steeves wrote:
> Since you're the elpa-org-mode maintainer Would you like to package
> org-drill, which was broken out into its own project for org-mode 9.3
> (possibly earlier)?
>
> Failing that, could I add you as an uploader? I'm happy to do the
> work to package
I'll take care of packaging this.
Cheers,
--Seb
On Dec/29, Ritesh Raj Sarraf wrote:
> I've just pushed my changes to the git repo. Could you please review
> it once ? I'd like you to have your comments/feedback before we
> decide on uploading it.
>
> Apart from the main file name change, there are other minor changes.
It all looks good to
On Dec/29, Ritesh Raj Sarraf wrote:
> I think we should stick with this proposal of appending the type along
> with the name.
>
> 1. On autocompletions, it'd autocomplete to "execsnoop-", which is an
> invalid name either way. This will expect the user to pay attention
> and fire the correct
Hi Ritesh,
I agree with you, there is no reason we can't coexist :)
However, perf-tools-unstable doesn't seem to be much more updated these
days, and it sorta worries me, especially since Brendan Gregg mentions
on his blog that bcc seems to be the future: in that light, do you still
see a need
On Oct/15, Jakub Wilk wrote:
> Please talk to upstream (or maybe to both upstreams) before renaming
> anything.
> [...]
> Eeek... https://lists.debian.org/20070428095345.ga9...@kunpuu.plessy.org
The package is already in NEW, and contains /usr/bin/yank-cli. I'll add
a note to README.Debian about
On Oct/15, Jakub Wilk wrote:
> Sounds very cool, but apt-file tells me this name is already taken:
>
> emboss: /usr/bin/yank
I think I'll keep the package name, but I'll install the binary itself
under some other name, maybe something like /usr/bin/yank-cli ?
Cheers,
--Seb
On Oct/03, peter green wrote:
> If you do that please be sure to make it clear in the package
> description what the Debian version of the package returns (the
> proposed description in the ITP suggests that the package will return
> the list of certs from python-certifi upstream).
I described
On Jun/01, Francois Marier wrote:
I've already submitted my package [1] to NEW and so given the amount
of time it takes these days to go through that, I would suggest
keeping it there.
However, if Sebastien wants to take it over from me after it's
accepted (and even replace it with his own
aptly has passed new, and is now in unstable.
--Seb
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140924064306.gj22...@frisco.mine.nu
I figured I'd package the whole perf-tools suite instead of just
iosnoop.
The corresponding ITP for perf-tools (renamed to perf-tools-unstable in
the mantime) is #755838, and the first version has been uploaded to
NEW. Once it enters sid, I'll simply close ##755072.
Cheers,
--Seb
--
To
On Jul/24, Ben Hutchings wrote:
If it stays in testing, it will go into the next stable and you then
need to support some arbitrary version for ~3 years.
OK, I initially thought it was the mention about the caveats in the
package's description that led to your request.
About the arbitrary
On Jul/23, Ben Hutchings wrote:
Package name: perf-tools
Please choose a different name so that it won't be mistaken for
linux-tools. Perhaps 'perf-tools-unstable'.
Sure, I can do that: I'll re-upload it to NEW with another name.
Many of these tools employ workarounds so that
Hi Geoff,
you can go ahead and take it over, if one of your other packages
depend on it it makes more sense.
Cheers,
--Seb
On Jul/21, Geoffroy Youri Berret wrote:
Hi Michal, Sébastien,
Sébastien are you still planning to take over python-mpd?
I'm also interested in this package as my
Hi Michal,
I'd be interested in taking over the maintainership of python-mpd, if
that's fine with you; please let me know how to proceed.
Cheers,
--Seb
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
28 matches
Mail list logo
