Bug#612909: python-mpd

[Sébastien Delafond]

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 listmas...@lists.debian.org
Archive: http://lists.debian.org/20110326143921.gw20...@frisco.mine.nu

Bug#612909: RFA: python-mpd

[Sébastien Delafond]

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 package mpd-sima depends on it.
 I noticed a new project @ alioth focused on MPD and related application:
   http://alioth.debian.org/projects/pkg-mpd/
 
 This is probably what Michal was talking about. It would be nice to move
 python-mpd on that project as well.
 
 Cheers,
 Geoff
 



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110721113114.gd29...@frisco.mine.nu

Bug#755838: ITP: perf-tools -- DTrace-like tools for linux

[Sébastien Delafond]

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 functionality is
  possible on existing Linux kernels. Because of this, many tools have
  caveats (see man pages), and their implementation should be
  considered a placeholder until future kernel features, or new
  tracing subsystems, are added.
 
 Based on the description, it doesn't appear that this would be
 suitable for a stable release.  So after uploading it, please open an
 RC bug to ensure that it does not transition to testing.

As long as the caveats/missing features are properly documented in the
manpages (which, as far as I can tell, they are), why wouldn't this
package be suitable for testing ?

Cheers,

--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/20140723212848.gv24...@frisco.mine.nu

Bug#755072: perf-tools instead of iosnoop

[Sébastien Delafond]

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 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/20140724103400.gz24...@frisco.mine.nu

Bug#755838: ITP: perf-tools -- DTrace-like tools for linux

[Sébastien Delafond]

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 version, I plan on asking upstream to tag his source
tree at a commit he considers stable-ish, so the resulting packaged
version doesn't look like a plain arbitrary snapshot.

Cheers,

--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/20140724103325.gy24...@frisco.mine.nu

Bug#746343: Now in sid

[Sébastien Delafond]

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

Bug#784317: Bug#787319: ITP: configargparse -- replacement for argparse with config files and environment variables support

[Sébastien Delafond]

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 package) that's totally
 fine by me. I don't need to maintain this, I just need to have it in
 Debian because it's a dependency of the letsencrypt client.

Nah, it's perfectly fine for you to maintain it: I only needed it as a
dependency as well. And since my package wasn't ready yet, let's go with
yours as it's already in NEW.

Cheers,

--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/20150601073605.gz23...@frisco.mine.nu

Bug#801837: ITP: yank -- interactively select and yank terminal output to stdout or xsel

[Sébastien Delafond]

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

Bug#801837: ITP: yank -- interactively select and yank terminal output to stdout or xsel

[Sébastien Delafond]

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 that renaming, and also a recommendation
to alias it to something short : users of this package will be
command-line afficionados, and as such should probably not be
handicapped by this.

Cheers,

--Seb

Bug#800760: ITP: python-certifi -- collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts

[Sébastien Delafond]

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 this behavior in README.Debian, but you make a good point:
I'll also include it directly in the package description.

Cheers,

--Seb

Bug#774055: tmuxp

[Sébastien Delafond]

I'll take care of packaging this.

Cheers,

--Seb

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Sébastien Delafond]

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 for perf-tools-unstable at all ?

If you do, would you be willing to take over its maintainership ? I'm
trying to save more time to contribute to security work in Debian, so
you'd be welcome to do that :)

Anyway, let me know what you think and we'll take it from there.

Cheers,

--Seb

On Nov/30, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello Sebastien,
> 
> First of all, thanks for maintaining perf-tools-unstable. I use it many a 
> times.
> 
> I just completed the major chunk of bcc packaging. I intend to maintain it 
> under
> collab-maint/ too.
> 
> 
> The binary file names are conflicting for bcc and perf-tools-unstable. I don't
> see a reason why one cannot co-install both the packages and use. But in its
> current form, it'll fail complaining file overwrites.
> 
> Personally, I don't think the alternatives route may be of much use because
> apart from this 2 packages, I don't see any other package using these names.
> Also, IMO, the alternatives feature is usually useful for common tools like
> editor, pager etc.
> 
> One option could be that we append the names of the binaries explicitly.
> Example, for bcc => execsnoop-bcc, perf-tools => execsnoop-perf
> 
> What do you say ? Or if you have any suggestions, please do mention.
> 
> Thanks,
> Ritesh
> 
> On Wed, 2016-11-30 at 22:50 +0530, Ritesh Raj Sarraf wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ritesh Raj Sarraf 
> > 
> > * Package name: bcc
> >   Version : 0.2.0
> >   Upstream Author : IO Visor Project (https://github.com/iovisor)
> > * URL : https://github.com/iovisor/bcc
> > * License : Apache 2.0
> >   Programming Lang: C, Python
> >   Description : Tools for BPF Compiler Collection (BCC)
> > 
> >  BPF Compiler Collection (BCC) is a toolkit for creating efficient
> >  kernel tracing and manipulation programs
> >  .
> >  It makes use of extended BPF (Berkeley Package Filter) and provides tools
> >  for BPF based Linux IO analysis, networking, monitoring and more
> > 
> > This is a great tool to debug and instrument your kernel and
> > applications. It also is a a performance characterization and analysis
> > tool
> > 
> > I have an interest in Debugging and Analysis and I intend to use and
> > maintain it under Debian.
> > 
> > As with most of my packages, I intend to maintain it under collab-maint
> - -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlg/EPQACgkQpjpYo/Lh
> dWle6xAAsRRfIO3oUvk6wN4NXanqQark//nvE5ezt2RPlx4SUYWA3WWJas1bbGA8
> AdnJMKvqYD1wkBmuSRU5S+Ne6kXjat8GQCPiYBi1IS1mcUQXRT/MoKce3YmxJGvt
> p6jxGBP8d9CeUZe7eOHujKmsBj4OYghX1e6VmYtwdGeaCEw4x5vnxO7GuX8ZkgxZ
> XE/zSyuKB7GLAJUbg11VGUKoLVEP0kOprflj17DsNofXFNDrETL2OykDTNNIsJTP
> c+RuTQE2xlD4EGCbnrYQ5A4tVl6ZtFao8LZXzcOmmAu9yR+6aYVMdEJnFe6iXTSY
> M74pIBLZs3gq5gkhfm0x+sVadkXx/xuG3fslFxHYJIUWXS2aaB1pryrvDKdP1SF7
> F1RzJe6JtflzkkRu0DNBvZdkOztoX+jhldeoWXjZ7qcwKNFC7COvT4piEi+ivIXb
> q3gvuadoGN4SL8M4sJJD2nbmKiDo74UuQ+HisY1xrAM6+ksf+/DxwVHOOX1Akpii
> b77uguwPf6kxmScfI0VrL7LJr9y3vOI4GeQsAqq1ttUghi59u/dZ6qGjbA3xEnTz
> a2w9kHGtwVUTIZaMT3v2nXveI87P+vHNhVDA9GyTmDvdqdVpTQp3nfCMzeCj1/L6
> 5fK78HJnQkdhMcITGVYmgcUAuegws2X1f0pw2/9jzpGWE39Sjjc=
> =YYEe
> -END PGP SIGNATURE-
> 
> 

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Sébastien Delafond]

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 me.

> PS: If you want to, please review and upload. Otherwise, if you want
> me to do it, please let me know.

I've pushed a change removing myself from the Uploaders field: it's
basically your package now :) Feel free to upload whenever you like !

Cheers,

--Seb

Bug#846366: ITP: bcc -- Command line tools for BPF Compiler Collection (BCC)

[Sébastien Delafond]

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 command.
> 
> 2. This approach is explicit, visible and allows for co-existence for
> both.
> 
> So, unless there is a concern, I'd want to target this change for the
> next upload of both the tools. The bpfcc follow-up upload is pending
> because of a FTBFS bug. And on the perf-tools side, there haven't been
> any substantial changes lately, warranting an upload.
> 
> But whatever triggers the upload, we'll make this change included ?

Sounds good to me. Maybe worth documenting in README.Debian as well ?

Cheers,

--Seb

Bug#947017: [ATT seb] Re: Bug#947017: RFP: org-drill -- emacs self-learning mode with spaced repetition

[Sébastien Delafond]

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

Bug#947017: [ATT seb] Re: Bug#947017: RFP: org-drill -- emacs self-learning mode with spaced repetition

[Sébastien Delafond]

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 it, but I don't want to be the only person responsible
> for something that I don't use ;-)

Hi Nicholas,

I'm OK to be listed as an uploader, but let me state right now that I
don't use org-drill either :)

Cheers,

-- 
Seb

Bug#950198: 950198

[Sébastien Delafond]

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

Bug#723017: xrayutilities: changing from RFP to ITP

[Sébastien Delafond]

retitle 723017 ITP: xrayutilities -- Python x-ray data reduction and analysis
owner 723017 s...@debian.org
tag 723017 + pending
thanks

Bug#950198: restinio

[Sébastien Delafond]

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.

Before you go ahead on any of this, please let's wait for Alexandre's
input.

> Something else that might need work.
> 
> The freshly imported tarball (0.6.6) contains an embedded dev/asio
> directory, which does not exist in the upstream repository, nor was it
> in the 0.6.4 tarball. I understand that this copy is unnecessary. But
> some test is compiled with -I${top_srcdir}/dev/asio/include.
> 
> The embedded asio does not coincide with libasio-dev in sid,
> 1:1.12.2-1.  Imo (and I am certainly clueless here) this may lead to
> questionable test results. Technically, We may need to depend on a
> specific libasio-dev.

Definitely not; instead we'd patch the corresponding CMakeLists to
compile against the system-wide asio. As for the 2 above points, let's
wait on Alexandre to see if he thinks this should delay the upload to
NEW.

> The source of this is, upstream is offering multiple tarballs, one
> with third party packages included. This also explains some of
> Sébastiens additions to the copyright file.

Some of them, yes. But there wasn't really any effort put into coming up
with a proper d/copyright with 0.6.4, as my initial "git grep -i
copyright upstream/0.6.4" led me to conclude.

> As of version 0.6.4, none of the additional headers were required for
> either for building opendht or jami.

But the whole point is, they are required to run the unit tests.

> I have imported the smaller tarball and rebased Sébastiens
> commits. It's in my master branch now [1]. I'm afraid the package does
> no longer build, and I am unsure how to proceed.

I'm not sure what to tell you here, except that this operation was
indeed bound to fail.

> My gut feeling is that the small tarball is the correct one, (although
> I can see the other one listed in d/watch), and that the tests should
> be compiled against installed packages, if at all.

I am unsure where your gut feeling comes from: the smaller package is OK
to simply use as an include in a development project. OTOH when building
the Debian package, we're definitely interested in running the
upstream-provided unit tests during a regular build.

Cheers,

-- 
Seb

Bug#950198: restinio

[Sébastien Delafond]

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 what's
in my salsa repository right now achieves the three of them:

 - copyright-clean
 - runs the upstream tests
 - should pass NEW

As I don't intend to maintain restinio in the long run, I don't feel the
need to argue this any further, and will happily defer to Alexandre's
opinion.

Cheers,

-- 
Seb

Bug#950198: restinio

[Sébastien Delafond]

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 in a clean chroot

  - reworked/removed patches to cmake: initial patch had a "CMakeLists
hacks; no idea what they are trying to do" comment associated to
various changes in upstream CMakeLists. I changed that hack, which
was aimed at "just building the package", so that we now run the
full suite of unit tests provided by upstream (needed to upgrade to
upstream version to 0.6.6 to fully implement that)

Let me know if you want me to upload what I've got now to NEW.

So we don't forget, here are a couple of items we'll want to fix later
on:

  - 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"

Cheers,

-- 
Seb

Bug#950198: restinio

[Sébastien Delafond]

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 as I definitely did
not upload the package. I just changed that.

> Action item before we can upload:
>  - Agree where the package will be maintained (hopefully thats over -
> debian/restinio)

Agreed.

>  - If we run the tests, they should pass (or was it my machine?)

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.

I add a basic d/salsa-ci.yml, that should tell us what's going on.

Cheers,

-- 
Seb

Bug#950198: restinio

[Sébastien Delafond]

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.
> 
> 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

Cheers,

-- 
Seb

Bug#950198: restinio

[Sébastien Delafond]

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 think I should upload restinio to NEW?

Cheers,

-- 
Seb

Bug#711554: pyhst2

[Sébastien Delafond]

retitle -1 ITP: pyhst2 -- Python High Speed Tomographic reconstruction
tag -1 + pending
owner -1 s...@debian.org
thanks

Bug#969371: hdf5plugin

[Sébastien Delafond]

Upstream uses hdf5plugin, but it can be patched out in 2 lines once
https://salsa.debian.org/alteholz/bitshuffle/-/merge_requests/1 is
merged.

Bug#947187: Unmaintained

[Sébastien Delafond]

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):

  https://github.com/sdelafond/cistern/tree/debian/master

Cheers,

-- 
Seb

Bug#950198: ring

[Sébastien Delafond]

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