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
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
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
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
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
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
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/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/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
I'll take care of packaging this.
Cheers,
--Seb
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 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
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
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 723017 ITP: xrayutilities -- Python x-ray data reduction and analysis
owner 723017 s...@debian.org
tag 723017 + pending
thanks
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.
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
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 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 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 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
retitle -1 ITP: pyhst2 -- Python High Speed Tomographic reconstruction
tag -1 + pending
owner -1 s...@debian.org
thanks
Upstream uses hdf5plugin, but it can be patched out in 2 lines once
https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/1 is
merged.
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):
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
28 matches
Mail list logo