Re: Removal of upstart integration
2017-08-30 15:54 GMT+02:00 Dimitri John Ledkov : > I hope that this email alone is enough for at least some maintainers > to integrate/schedule this change without the bug overhead I think this could be a good candidates for a lintian tag to inform maintainers about the change and to keep track of the progress. -- Cheers, Luca
Re: Bits from the Wanna Build team
2015-08-21 19:54 GMT+02:00 Jakub Wilk : > Hmm, how do you build only arch:all packages in sbuild? See commit below, not uploaded to sid yet: https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=fec82ed70d7efdfe17f676c60e1114bd8bb4a888 -- Cheers, Luca
Re: oldoldstable on DDPO
Hi, 2015-06-13 19:36 GMT+02:00 Christoph Berg : > The display logic is now generalized so it can also exclude the > "older" dists, e.g. &version=testing will just show testing and > later. The default is to show oldstable and up. Thanks for this new feature! Would it be also possible to exclude from the view packages no longer maintained in the selected suites (see #736715) ? -- Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0Nc+pD_zBAhJ=vw8qfnetjgwhkyl+obciopg-dugg8...@mail.gmail.com
Re: MBF for python-support removal
2015-05-07 13:59 GMT+02:00 Luca Falavigna :
> =
> Dear Maintainer,
>
> your package either build-depends or depends on the python-support
> package, or uses dh_pysupport in debian/rules file.
>
> python-support has been deprecated for some time, and any package
> still using it should be migrated to dh_python2 and dh_python3.
> Instructions on how to migrate packages to dh_python2/dh_python3 can
> be found on the Debian wiki [0]. An overview of the anatomy of a
> package using the pybuild and dh_python{2,3} helpers can be found in
> the Python Module Style Guide [1].
>
> Please test your package thoroughly to make sure the transition to
> dh_python2/dh_python3 is done correctly and does not cause a negative
> impact on your package. In particular, please test upgrades from the
> current jessie and stretch/sid versions of the package.
>
> If your package does not yet use Python 3, please consider adding
> Python 3 support to your package at the same time as updating the
> build system; the py3k porters can offer assistance with that [2].
>
> [0] https://wiki.debian.org/Python/TransitionToDHPython2
> [1] https://wiki.debian.org/Python/LibraryStyleGuide
> [2] https://wiki.debian.org/Python/Python3Port
>
> Thanks!
> =
Does anybody else have comments / adjustments on the text above?
I'd like to send out the bugs within the end of this week.
--
Cheers,
Luca
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CADk7b0NQQ4G9-f4pQRA4Zd9OQLf7mi9a5J1RRYodp=eues7...@mail.gmail.com
Re: Upcoming mass-bug filing: GStreamer 0.10 removal
Hi, 2015-05-13 10:42 GMT+02:00 Sebastian Dröge : > GStreamer 0.10 is no longer maintained and supported by the upstream > project since almost 3 years now, and contains many known bugs that are > fixed in the new 1.x release series of GStreamer. Next to many bug > fixes, the new release series also contains many other improvements, new > features and a more streamlined API. Is a porting guide / reference available? That would be helpful to spot issues while dealing with the new API's. -- Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadk7b0p-k0zov1hfne1mr7bx7ey10lp6astntff+vi62zmq...@mail.gmail.com
Re: MBF for python-support removal
2015-05-03 10:54 GMT+02:00 Ben Finney :
>
> Better to have it in a message in this forum for context. The document
> at the above URL has this text::
Indeed, I should have done it myself in the first place, but I was too quick :-)
By the way, I saw a nice addition to the template, therefore
re-submitting it to the list:
=
Dear Maintainer,
your package either build-depends or depends on the python-support
package, or uses dh_pysupport in debian/rules file.
python-support has been deprecated for some time, and any package
still using it should be migrated to dh_python2 and dh_python3.
Instructions on how to migrate packages to dh_python2/dh_python3 can
be found on the Debian wiki [0]. An overview of the anatomy of a
package using the pybuild and dh_python{2,3} helpers can be found in
the Python Module Style Guide [1].
Please test your package thoroughly to make sure the transition to
dh_python2/dh_python3 is done correctly and does not cause a negative
impact on your package. In particular, please test upgrades from the
current jessie and stretch/sid versions of the package.
If your package does not yet use Python 3, please consider adding
Python 3 support to your package at the same time as updating the
build system; the py3k porters can offer assistance with that [2].
[0] https://wiki.debian.org/Python/TransitionToDHPython2
[1] https://wiki.debian.org/Python/LibraryStyleGuide
[2] https://wiki.debian.org/Python/Python3Port
Thanks!
=
--
Cheers,
Luca
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CADk7b0PBL0h3k4sdiPL=yU-PzJ2i7tyJ=plj47-gg2x4kza...@mail.gmail.com
Re: MBF for python-support removal
Hi Julien, 2015-05-01 19:47 GMT+02:00 Julien Cristau : > It would be nice to see a template of your proposed mass filing. https://titanpad.com/hL2sxANh1Y -- Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0NHe=m7jRDVxohJA7-95N4kd6ZEUHsTW7eYxnOs=+y...@mail.gmail.com
MBF for python-support removal
Hi, as discussed on a thread on debian-python mailing list [0], I'd like to start a MBF against about 420 packages [1] to propose the removal of the deprecated python-support. A couple of lintian tags have been around for about one year and a half, allowing us to reduce the total number of affected packages, but from the graphs it seems the curve is no longer decreasing, therefore this request to speed up the migration to dh_python[23]. I'd like to work on this in the coming days if rough consensus is reached, feel free to raise your objections/suggestions! [0] https://lists.debian.org/debian-python/2015/04/msg00152.html [1] https://udd.debian.org/cgi-bin/python_helpers.cgi Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0P1ARVvAmPPVsZXdbZpzGGR9T=egm5vu0pdo-xahwb...@mail.gmail.com
Re: Bug#771687: debootstrap: Please add support for the Tanglu derivative
2014-12-02 15:19 GMT+01:00 Thorsten Glaser : > On Mon, 1 Dec 2014, Cyril Brulebois wrote: > >> > Could you please add support for the Tanglu[1] Debian derivative? > >> Without having looked at it yet: thanks. > >> Yes, please. One bug report per feature is the best way. > > I thought d-i was frozen and debootstrap was to absolutely > not be touched any more? Unless I'm wrong, these quotes refers to the fact a patch was submitted, and not about the intention to actually merge it in time for Jessie. Perhaps, having quoted the full thread instead of these two lines only would have led to a clearer interpretation.. > Disappointed and even more so disillusioned, > //mirabilos (not even a .sig this time) Sorry to hear that, but... for what reason? Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadk7b0oqs7o-549n1wektb2ffyd6vwmmu3o+2lyzlr90mhl...@mail.gmail.com
Re: r-base-core upload to unstable does not respect freeze policy
Hi Andreas, 2014-11-11 19:12 GMT+01:00 Andreas Tille : >> Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2) > > Hmmm, this is what I missed. :-( I guess the only chance is to upload > to t-p-u, right? That could be an option. You have to coordinate with Release Team, though, as I can't speak for it. Obviously, fixes to any R package should go through t-p-u, which could be a pain to handle. I wonder whether the version in unstable can be reverted to 3.1.1... Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0NKQS_VmtXreSY+e4etB6KwMc2e=Dw1FJ_=77uumpg...@mail.gmail.com
Re: r-base-core upload to unstable does not respect freeze policy
Hi Andreas, 2014-11-11 16:33 GMT+01:00 Andreas Tille : > I was close to trap into the pitfall to uploaded an RC bug fix built in > an unstable chroot which would not be able to migrate to testing since > the R cdbs helper injects a > > Depends: r-base-core (>= ) > > So I used a testing chroot I think this is not enough, as packages being built by the buildd network will pick up the R in unstable anyway :/ >From >https://buildd.debian.org/status/fetch.php?pkg=r-cran-epi&arch=i386&ver=1.1.67-3&stamp=1415721806 r-cran-epi_1.1.67-3_i386.deb [...] Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2) Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadk7b0opwvqeeaw9kmpoz2f8ys5mj0nd6ugqt0w_v7rte5r...@mail.gmail.com
Re: Override disparity checks (Was: Re: Transition plan for changing the default init system)
2014-07-17 16:31 GMT+02:00 Thorsten Glaser :
>> * https://ftp-master.debian.org/override-disparity.gz
>
> This is not shown in the PTS, though. If we could get it to show
> up there, and maybe DDPO, that could help.
Indeed, it's in yaml format, so I guess it should be easy to integrate
it in PTS/Tracker. Any takers?
> MBF would probably not be... appreciated.
Yes, despite Policy §2.5 uses a "must", I don't think we should
mass-change overrides.
IMO, these should be handled on a case-by-case basis.
Looking more at it, it seems there are a lot of packages requiring
dependencies which are extra:
$ grep -E "^\s{4}" override-disparity | cut -d" " -f6 | sort | uniq -c
4789 extra
8 important
131 optional
17 standard
$
Looking at the policy again, I think extra is (mis)used quite too often.
Cheers,
Luca
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cadk7b0o1z3me35b6j0tl-i_6ccwrrxvse-phwoe940pvyxt...@mail.gmail.com
Override disparity checks (Was: Re: Transition plan for changing the default init system)
Hi! 2014-07-17 15:27 GMT+02:00 Thorsten Glaser : >>A Priority: required package (init) isn't allowed to depend on something >>with Priority: standard per policy. > > Among even minbase, there are a *lot* of violations of this > particular rule of Policy. There is also nothing in place > checking them. Actually, there are two tools to check this: * https://ftp-master.debian.org/override-disparity.gz * https://qa.debian.org/debcheck.php (check for "Priority") Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0M3y=psnfR-m9LObVboCmf8RD8rdpLSdNvu=an4vrw...@mail.gmail.com
Bug#741021: RFA: keybinder -- registers global key bindings for applications
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I request an adopter for keybinder source package. It should be in a decent state, upstream is not very active lately, but he's always been very responsive. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadk7b0m5ghmjoo7djpb9a9n9fdk-h5tnno7pabyiba-xhfg...@mail.gmail.com
Bug#741022: RFA: kupfer -- fast and lightweight desktop summoner/launcher
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I request an adopter for kupfer source package. It should be in a decent state, upstream is not very active lately, but he's always been very responsive. Package is maintained under Python Application Team umbrella, bonus points if perspective adopters are willing to maintain it there. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADk7b0Prei-wM2gSJ=xbfeyx2eb1trbqjdc_cl8h6pex8g4...@mail.gmail.com
Re: Nitpicking in the NEW queue.
2013/9/3 Paul Wise : > Reading Charles' mail I had a thought; how about accepting buggy > packages (unless the issues make them non-distributable) and file RC > and other bugs if there are DFSG or other issues? Although this could be possible, a second upload would be needed anyway (hopefully in a very short timeframe), so reuploading a fixed package to NEW would avoid wasting bandwith and disk space on mirrors and snapshot.d.o. Usually, rejected packages are fast-tracked when reuploaded to avoid letting them slip at the bottom of the queue. Simply reply to rejection mail (or ping us in IRC) informing us a fixed package has been reuploaded to the NEW queue. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0p3tqwt6_ssqq3ygpen7aonsrgqkscwkv8tf7bvr-r...@mail.gmail.com
Re: Less dinstall FTW?
2013/8/29 Dominique Dumont : > Are the package signatures verified at this point ? Yes. Packages are listed in incoming.d.o after they have been accepted by dak. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0m+owooouo4h-yz4c1euacu0w2qqbyp1wchm9ky0cw...@mail.gmail.com
Re: Less dinstall FTW?
2013/8/29 Dmitrijs Ledkovs : > Can dinstall be run every hour please? For me, if anything dinstall is > not frequent enough. No, dinstall takes more than an hour to finish... > If it takes longer than hour to execute, can it be optimised and sped up? ... and even if it can be reduced, there are more problems this would introduce (mirror pushes, snapshot pushes, ...) Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADk7b0Md4jUmjxwWtkc86hT=eqksLK61htR6=Np8qOw7u3=_...@mail.gmail.com
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
2013/4/9 Thomas Goirand : > If I upload new packages A and B, that A depends and B, and > that A gets approved, but B doesn't, then we end up with > package A being in Debian, but never installable. That is unlikely to happen: dak has a colour scheme to identify missing packages. It's also nice to identify packages who belong in main, contrib, and non-free, just to avoid component mismatches. > Now, if what you are suggesting that I should wait for B > to be approved before uploading A, I think you aren't > being realistic when the NEW queue has a 3 months > waiting time. This might work with small projects, but > if you have to maintain a complex set of packages, with > lots of dependencies, it just doesn't work. Been there, > tried that ... Uploading packages in NEW which depend on other packages in NEW is fine, as explained above. Dependencies will be reviewed first, and when accepted, the other packages will be processed as well. The major difficulty happens when the dependency chain is very complex (e.g. A -> B -> C -> D -> E -> A), in that case it would help if maintainers suggested the order in which to review packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0of088feo66cypo-8crkrrsyd5bma49oe-twf8tx71...@mail.gmail.com
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
2013/4/1 Rene Engelhard : > True for unstable, not for experimental, Because stuff uploading to > experimental > can cause a transition if uploaded to unstable, yes - for *jessie*. Most of the packages introducing new transitions were accepted, if targeted experimental. A lot are still in the queue, though. The "rationale" will follow shortly. > Of course if mallicous or careless maintainers uploaded to unstable.. *shrugs* True, and currently it's not possible to block those. But TTBOMK, only a very few cases happened, and fortunately it was not to crack the game. > I understand that, *if* comments were needed. But that's not the case always. > > Some were stuck there and gor rejedted after 2 months. That specific > exmple was needed to make a transition which *will* happen in jessie > _less painless_. Comments and rejects are issued during package review. Most of the packages are accepted without remarks, some of them have a longer path. I know the frustration of waiting for two months or more, and then having your package rejected for just a few comments, but that is why the NEW queue is in place, and maintainers sometimes have to face a "try again". > And this isn't a explanation for *completely new*, (and thus no r-deps, > thus no transition) packages. > > (And no, I didn't get a comment.) As I outlined in my previous message, we're in a phase in which we receive more packages than we're able to process, due to internal factors (our team is made of five members, while active developers are about five hundred), or external (some of us have been busy elsewhere, rationales are better explained in other mailinglists). binary-NEW packages are usually processed first due to dak sorting, and the NEW queue is not generally processed as FIFO, so it can happen a package is processed way later even if it has been uploaded earlier. >>On the other hand, FTP Team is willing to fast-track NEW packages anytime, > > I know, and afaicr I went this way (or /query ansgar), too and I am very > grateful for that. > > It's more cumbersome than it needs to be, though. In a perfect world there wouldn't be any need for a NEW queue at all. But we have to face with the reality. We try to do our best to improve things where we can. From the FTP Team side, we always try to be quick and helpful with our fellow developers, and are happy to hear about suggestions how to improve further. On the other hand, please bear with us a little more when packages are not processed so quickly. FTP Team is not just pressing a button. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0pspid5gdpbkikuha4skidaa8zy5esbme7wny5iflu...@mail.gmail.com
NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
[ This is just my personal point of view, not necessarily the one of the FTP Team ] 2013/4/1 Rene Engelhard >> Even if you think there are a few days between the time taken to process >> NEW for experimental vs NEW for unstable, I've seen no evidence of that >> and it's not as if a few days are really going to matter. (If it's that >> critical, find a webhost running Debian and install reprepro.) > > A few days? There's stuff there *for months*? True. But most of the packages that currently are on top of the NEW queue would have introduced transitions if FTP Team blindly had accepted them, and we agreed with Release Team to keep them in the queue to avoid potential breakages, given that at the time we just entered the Wheezy freeze. We sent emails to maintainers to inform them about the reasons behind the delay, and we offered to accept packages targeted to experimental instead. I think this is a good approach. Some other packages are stuck in the queue pending an answer from their maintainers about some concerns FTP Team raised. There's little FTP Team can do other than wait for actions from maintainers. Since July 1st (first day of Wheezy freeze), we have the following figures: * 2085 NEW packages received (7.694 per day) * 1379 were accepted (5.089 per day) * 213 were rejected (0.786 per day) * 130 generated comments from FTP Team (0.480 per day) During the freeze, the number of NEW packages received dropped by a half if compared to the average during active development (about 14,85 packages each day), so the number of actions by the FTP Team (about 13.5 accepts, 1.2 rejects, 0.5 comments each day). The above figures are normal during freezes, both maintainers and FTP Team members are focused on other tasks (releasing Wheezy is, of course, one of them!). Maintainers upload packages more often than FTP Team is willing to process them (about 1,8 packages every day), that explains the recent NEW queue growth. Just for the record, FTP Team managed to keep the NEW queue around ten packages for more than one year and a half, average processing time was less than two days. Also, FTP Team processed almost two hundred packages just before the freeze to give maintainers a chance to make their packages into Wheezy (and most of them did!). On the other hand, FTP Team is willing to fast-track NEW packages anytime, if needed. Asking for a pacakge acceptance in #debian-ftp is always worth it, and rarely these requests are not taken into consideration (as it happened for some gcc/clang packages, or GNOME ones). If you need actions from FTP Team, feel free to talk to us and we will be happy to help you. Cheers, Luca
Bug#695629: ITP: xtree -- gather files scattered across several subdirectories
Package: wnpp Severity: wishlist Owner: Luca Falavigna * Package name: xtree Version : 0.1-1 Upstream Author : Luca Falavigna * URL : https://github.com/dktrkranz/xtree * License : GPL-3 Programming Lang: Python Description : gather files scattered across several subdirectories xtree can easily convert an archive or a directory populated by a lot of nested subdirectories into a flat tree structure, or the other way round. . This is particularly useful to move files scattered across a lot of subdirectories into a single directory, or to move files grouped by a common pattern into corresponding subdirectories. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121210223324.10624.69966.reportbug@utumno
Re: Minified javascript files
2012/8/17 Andreas Tille : >http://lists.debian.org/debian-devel/2012/08/msg00397.html > and do you agree that a (enhanced) uscan could be this tool? Sounds good for the majority of the cases, I don't think there are too many repacked sources in the archive for which it's impossible to provide a watch file [0]. [0] maintainers' laziness is not a justification -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0p1s++rcirmn9fp7gr3yqo8mddo5w7gawz8uomf4w7...@mail.gmail.com
Re: Minified javascript files
2012/8/17 Bernd Zeimetz : > But it usually does and also results in a source tarball which is > missing essential pieces of the software, so people who download it for > non-Debian usage will fail to run the shipped source just because we > removed an otherwise free piece of software. This does not make sense if the removed pieces are useless, as the core of this discussion is about. I also don't see the point of providing dozens of convenience copies of the very same third-party software bundled with every single pet package. If a software really needs a third-party software, just warn in $buildsystem_of_choice and in INSTALL file. Upstream should be really taugth not to reinventing the wheel again and again and again... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0mxazk+ejmoe1u9fdbevimmkqx98r5gydywsma1bzx...@mail.gmail.com
Re: Minified javascript files
2012/8/17 Jakub Wilk : > Part of the problem is that we lack good tools to do this extra work for us. > Really, repacking shouldn't be a tedious operation, it shouldn't take more > than 5 seconds, it shouldn't require writing two dozens lines of code and > documentation. :( ACK. Should we write a tool that, once and for all, allows to automate the process? I think workflow should something similar to: * tool should receive an URI of the orig tarball * tool should download and unpack the orig tarball * tool should compare orig tarball with already clean sources * tool should not consider file differences, just file removals * tool should generate a policy-compliant get-orig-source target based on the diff Also, where to put this tool? Devscripts? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADk7b0OpYe8HzYYFSxRZ7wbxhugj=k9o8sbkw5yuvcwfbo1...@mail.gmail.com
Packages up for adoption
Hi, due to lack of time, I intend to give a couple of packages up for adoption: * remmina (#676894) * libvncserver (#676895) The latter is a (build-)dependency of the first, so you may want to have a look at both if you are interested in maintaining them. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0pxajselgeh1fgjqvest5k7pnswo4xpy_w+ur2ngtb...@mail.gmail.com
Packages still in experimental but removed in unstable
Hi, I generated a list of source packages which have been removed from unstable, but are still kept into experimental for some reason. I excluded those which seem maintained, and generated a dd-list of the remaining ones. I will file removal bugs for them within the end of June if nobody claims they should be kept around. Albin Tonnerre python-ecore (U) python-evas (U) Charles Fry libjgrapht-java (U) Cyril Brulebois xserver-xorg-video-v4l (U) David Nusinow xserver-xorg-video-v4l (U) Debian freesmartphone.org Team zhone Debian Java Maintainers libjgrapht-java Debian Pkg-e Team python-ecore python-evas Debian X Strike Force xserver-xorg-video-v4l Guido Günther iceowl Jakub Wilk re2 (U) Jan Lübbe python-ecore (U) python-evas (U) Joachim Breitner zhone (U) Luca Capello zhone (U) Marc Haber rageircd Michael Koch libjgrapht-java (U) Nikita V. Youshchenko zhone (U) Simon Richter misdn-kernel misdn-user Stefano Rivera re2 Steffen Moeller libjgrapht-java (U) Thierry Randrianiriana qpopper Timo Jyrinki zhone (U) Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADk7b0PW3cmRQPA5kX6K-7P6wBYoSycJ-gCbm6D+y4bir=y...@mail.gmail.com
source-contains-waf-binary tag added to nonfatal lintian autoreject list
Hi, lintian 2.5.5, recently uploaded in unstable, introduced a new tag called "source-contains-waf-binary", which checks whether waf "binary" is available in source packages. Please see [0] for further information. We just added the tag to the dak nonfatal autoreject list, that means packages triggering that error will be automatically rejected by dak, unless the tag is overridden for a good reason. At the time of writing this email, several packages still need to be processed [1], please consider fixing them before Wheezy freeze. [0] http://wiki.debian.org/UnpackWaf [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ftpmas...@debian.org;tag=waf-unpack -- Luca Falavigna on behalf of the FTP Team signature.asc Description: OpenPGP digital signature
Bug#658287: ITP: pbs -- Python subprocess wrapper
Package: wnpp Severity: wishlist Owner: Luca Falavigna * Package name: pbs Version : 0.7 Upstream Author : Andrew Moffat * URL : https://github.com/amoffat/pbs * License : MIT Programming Lang: Python Description : Python subprocess wrapper PBS is a unique subprocess wrapper that maps your system programs to Python functions dynamically. PBS helps you write shell scripts in Python by giving you the good features of Bash (easy command calling, easy piping) with all the power and flexibility of Python. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201201702.3950.9756.reportbug@utumno
[RFC] License text parser and converter
DEP-5 is a good step forward to standardize copyright information. While it's indeed useful to determine a license type, there's no guarantee stand-alone license paragraphs or license headers are accurate (i.e. typos, GPL-2 license header while declaring GPL-2+), or canonically formatted (i.e. 72-char lines vs. 80-char lines, different spacing or indentation). Plus, some license text are not expressed in RFC822 syntax, and maintainers must adapt it to fit into DEP-5. As a reference, take MPL license, which is very long and fullfilled with spacing, converting it by hand is definitely time-consuming and error prone. I'd like to ask the following questions: * Is there a tool which, given a license text in raw format, converts it to match RFC822 syntax? * In case it exists, is it able to perform sanity checks on the licenses (i.e. license text matches intended one)? * In case it doesn't exist yet, would it be worth implementing it? * Which language would you use to implement it? I guess the answer to the last question would be Perl, as several related tools use Perl already (think of lintian, or libconfig-model-perl), but I suspect other scripting languages could fit as well. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0mdnkkq1qnib6ybc7l+ae51wkwvyu-h0rjtq5nsemg...@mail.gmail.com
python2.5 removal: dd-list of affected packages
python2.5 source package is planned to be removed from sid soon [0], there are several packages still depending on one of the binaries provided by it, though. Bugs have been already filed, you can see them at [1]. I also provide a dd-list of the affected packages. Adam C. Powell salome (U) Luciano Bello libmimic Jeff Breidenbach pylucene Sargis Dallakyan mgltools-bhtree (U) mgltools-gle (U) mgltools-opengltk (U) mgltools-pyglf (U) mgltools-sff (U) Debian Games Team libtuxcap Debian Med Packaging Team mgltools-bhtree mgltools-gle mgltools-opengltk mgltools-pyglf mgltools-sff Debian Science Maintainers salome Debian/Ubuntu Zope Team bobo zconfig zope.testing Freevo Debian Dream Team freevo IV salome (U) Matthias Klose zope.testing (U) Georg W. Leonhardt freevo (U) Jeremy Malcolm gozerbot A Mennucc1 freevo (U) Steffen Moeller mgltools-bhtree (U) mgltools-gle (U) mgltools-opengltk (U) mgltools-pyglf (U) mgltools-sff (U) Python Applications Packaging Team pytagsfs (U) Miriam Ruiz libtuxcap (U) Ritesh Raj Sarraf pytagsfs Brian Sutherland bobo (U) zconfig (U) zope.testing (U) Jason Thomas nagios-statd Andreas Tille mgltools-bhtree (U) mgltools-opengltk (U) mgltools-pyglf (U) mgltools-sff (U) Fabio Tranchitella bobo (U) zconfig (U) zope.testing (U) Davide Truffa obmenu [0] http://bugs.debian.org/623820 [1] http://deb.li/py25 -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Bug#613870: RFA: libraw -- raw image decoder library
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I request an adopter for libraw source package. It is one of the build-dependencies of shotwell package. Package: libraw-dev Description: raw image decoder library (development files) LibRaw is a library for reading RAW files obtained from digital photo cameras (CRW/CR2, NEF, RAF, DNG, and others). This package contains a static library and header files. Package: libraw-doc Description: raw image decoder library (documentation) LibRaw is a library for reading RAW files obtained from digital photo cameras (CRW/CR2, NEF, RAF, DNG, and others). This package contains documentation files. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Re: GNOME 3 and panel applets
Il 14/02/2011 18.17, Josselin Mouette ha scritto: > Debian GNOME Maintainers >tsclient Removed from unstable. > Luca Falavigna >remmina-gnome Will be removed as soon as remmina 0.9.3 hits wheezy. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
List of override disparities
Policy § 2.5 [0] states packages must not depend on other packages with lower priority values. In order to better adhere to it, FTP Team recently implemented a new tool that generates a list of override disparities[1] daily. We export a yaml-formatted list, limited to the affected packages only, with this group of attributes: * package name * maintainer * priority * dependencies with their overrides Feel free to look at the list and eventually report a bug against ftp.debian.org pseudo-package to ask for override adjustments or adjust your package. Please adjust this template as your subject string to ease the FTP Team's job: override: packagename:section/priority Please keep in mind that override disparities are neither RC bugs to flood squeeze with nor do they need a mass bug filing for all the packages (or flooding ftp.debian.org with). Instead, simply adjust your package when you agree that your package is wrong, or file a bug on ftp.debian.org having us change the overrides for your package, when you think our overrides are wrong. [0] http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities [1] http://ftp-master.debian.org/override-disparity.gz -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Re: [MBF proposal] Empty packages in the archive
I've just submitted relevant bugs, list can be found here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=empty-package -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
[MBF proposal] Empty packages in the archive
Hi, I've conducted an analysis looking for empty binary packages. Here is a dd-list of binary packages packages which would get a bug with severity serious: Jesus Climent libdspam7-drv-db4 (U) Julien Danjou libpthread-stubs0 (U) Debian DSPAM Maintainers libdspam7-drv-db4 Debian Mono Group libmono-windowsbase-cil-dev mono-winforms-a11y Debian Pkg-e Team efl-dev Debian Science Team fenics XCB Developers libpthread-stubs0 Christoph Haas libdspam7-drv-db4 (U) Kurt B. Kaiser libdspam7-drv-db4 (U) Aurelien Labrosse libdspam7-drv-db4 (U) Jan Lübbe efl-dev (U) Matthijs Mohlmann libdspam7-drv-db4 (U) Christophe Prud'homme fenics (U) Johannes Ring fenics (U) Jamey Sharp libpthread-stubs0 (U) Albin Tonnerre efl-dev (U) Josh Triplett libpthread-stubs0 (U) Ray Wang libmono-windowsbase-cil-dev (U) mono-winforms-a11y (U) Rudolf Weber libdspam7-drv-db4 (U) These packages would receive severity important: Wolfgang Baer libjmock-java-doc (U) Debian Java Maintainers libjmock-java-doc liblayout-java-doc librepository-java-doc Debian Octave Group octave3.2-dbg [mips, mipsel] Debian Ruby Extras Maintainers libimage-science-ruby-doc (U) libkrb5-ruby-doc (U) Rene Engelhard liblayout-java-doc (U) librepository-java-doc (U) Michael Koch librepository-java-doc (U) Trygve Laugstøl libjmock-java-doc (U) Ryan Niebur libkrb5-ruby-doc Ryan Niebur midori-dbg [hppa] Thomas Weber octave3.2-dbg (U) [mips, mipsel] Torsten Werner librepository-java-doc (U) Gunnar Wolf libimage-science-ruby-doc Other bugs have been already filed: libatlas-test_3.8.3-27 588418 libqthreads-12_1.6.8-10 397238 libslepc3.0.0_3.0.0-p7.dfsg-7 595396 google-perftools-dbg_1.5-1 595184 inventor-doc_2.1.5-10-14595405 mono-uia-dbg_1.0-2 595399 Please note test results have been gathered using a semi-automated process, so there could be some false positives. Feel free to correct me in case a package is empty on purpose. Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Bug#585602: ITP: gexiv2 -- GObject-based wrapper around the Exiv2 library
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: gexiv2 Version : 0.0.91 Upstream Authors: Mike Gemuende Jim Nelson * URL : http://trac.yorba.org/wiki/gexiv2 * License : GPLv2+ Programming Lang: C++ Description : GObject-based wrapper around the Exiv2 library gexiv2 is a GObject-based wrapper around the Exiv2 library. It makes the basic features of Exiv2 available to GNOME applications. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: Waiting for SCons 2.0: rebuild test
Il giorno Fri, 04 Jun 2010 19:37:26 +0100 "Adam D. Barratt" ha scritto: > > * 1 package has temporary dependency screwup > What specifically does "temporary dependency screwup" mean? http://people.debian.org/~dktrkranz/scons-2.0/depwait/gtkrsync_1.0.4-sid-i386-20100604-075618.22.log gtkrsync requires some build-dependencies conflicting each other. I didn't spend a lot of time on this specific issue, so I'm not able to say where the problem is right now. > > I have already informed upstream of my rebuild tests, and I hopefully > > will be given instructions on how to properly fix FTBFSes, which I will > > report as important bugs against affected packages. SCons 2.0 release > > should happen in June, if RT does not mind, I intend to upload 2.0 to > > unstable shortafter. > > I'm assuming that this is "just" a new upstream version? i.e. once the > FTBFS packages are fixed and assuming no RC issues in scons itself > appear, there'd be no need for any explicit action from the Release Team > and SCons 2.0 would simply transition to testing once its 10 days were > up? Exactly, given that several packages build-depend on SCons, and there could be some hidden aspects I'm not aware of, informing RT in advance could avoid additional headache to team members :) -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: Waiting for SCons 2.0: rebuild test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il giorno Fri, 04 Jun 2010 13:12:52 -0400 Felipe Sateler ha scritto: > Does SCons finally support SONAMES or do we still have to manually do > that? I don't see any reference to that in the release text. I don't think so. I remember I've seen a request on Tigris tracker, but I can't remember its # right now. - -- .''`. : :' : Luca Falavigna `. `' `- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwJO4YACgkQnXjXEYa8KlC4eACfY57+uBGmmhkOGIaDBn3zUSuh Ws4An3SaDenP8C14mgwhlEL+RWgS4Qq4 =NPqn -END PGP SIGNATURE-
Waiting for SCons 2.0: rebuild test
Hello, SCons developers are close to release new major release of SCons, which started to deprecate some obsolete function and dropped support for Python code older than 2.4. Full release notes can be found here: http://sourceforge.net/projects/scons/files/scons/2.0.0.beta.20100531/RELEASE.txt/view SCons unittest is very well designed, and there should not be any major breakages, but risk of backward incompatible changes could affect some Debian packages which does not see updates from upstreams so often. So, I rebuilt reverse dependencies of SCons to spot some problems, and I published my results online. Here is a brief summary: * 58 packages build-depending on SCons * 53 packages built successfully (2 of them needed sourceful changes, such as build-dependency mangling or so, but not related to SCons). * 4 packages FTBFS: * 1 package has temporary dependency screwup This is a dd-list of FTBFSing packages: Tim Abbott sagemath Michael Ablassmeier kstreamripper William J Beksi skim (U) Zhengpeng Hou skim (U) Steffen Joeris abakus skim maintainers skim Jaldhar H. Vyas skim (U) Build logs and other details can be found here: http://people.debian.org/~dktrkranz/scons-2.0 I have already informed upstream of my rebuild tests, and I hopefully will be given instructions on how to properly fix FTBFSes, which I will report as important bugs against affected packages. SCons 2.0 release should happen in June, if RT does not mind, I intend to upload 2.0 to unstable shortafter. Thoughts? -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Packages up for adoption
I'm asking for adopters for the following packages: * boa-constructor http://bugs.debian.org/575844 * drpython http://bugs.debian.org/575845 * foff http://bugs.debian.org/575842 * jokosher http://bugs.debian.org/575843 * lfm http://bugs.debian.org/575840 * pythoncadhttp://bugs.debian.org/575839 * qa-assistant http://bugs.debian.org/575841 Details are in the corresponding bug reports, if you're interested please follow-up here or in the bugs. Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Intent to remove waf from Debian
Hello, after some time spent to reflect and discuss, I think we reached a point of no return regarding waf package in Debian. I try to summarize what happened in the past months. Devid and I originally decided to include waf as a regular package in Debian because several projects use it as their preferred build system, including a waf "binary" in upstream tarballs. Such "binary" is basically a Python script with an embedded bzip2 tarball unpacked at runtime. Debian package provides waf script, together with wafadmin directory, which is basically the tarball mentioned above, unpacked. Upstream discourages using a system-wide installation of waf [1], and tried in some ways to complicate things for distributors ([2], search "Debian" word), and refused to provide any feedback with related build failures, which were handled with workarounds [3][4]. Things went worse when a user complained with upstream about a build failure while using waf provided by Debian package and an older wscript, waf upstream contacted us asking to remove waf package from Debian under threat to remove system-wide installation, giving us no chance to provide a working waf package anymore. We tried to reach a compromise [5], but it was not enough for upstream, and he renewed his intentions. We do not believe we can solve this situation anytime soon, so we would like to remove waf from Debian for good. I already filed bugs on those packages currently build-depending on waf [6], hopefully they will be fixed before Squeeze, or I will prepare NMUs if release approaches. As a personal note, I discourage using waf as build system of choice: during these months I realized waf introduces backward incompatible changes every releases, this can lead to build failures very frequently. Sticking with older releases is the suggested solution by upstream, but may expose to bugs fixed in newer releases only. [1]http://freehackers.org/~tnagy/wafbook/single.html#installing [2]http://groups.google.com/group/waf-users/browse_thread/thread/88ad357bf2bf59f4/7261615b56c07eea [3]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/patches/intltool.patch [4]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/patches/fun_check.patch [5]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/README.Debian [6]http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=...@packages.qa.debian.org;tag=waf-removal Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Bug#571041: ITP: dreampie -- advanced Python shell
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: dreampie Version : 1.0 Upstream Author : Noam Yorav-Raphael * URL : http://dreampie.sourceforge.net * License : GPLv3 and others Programming Lang: Python Description : advanced Python shell This Python shell permits to work in a more productive way with Python interpreter providing features not yet implemented in standard IDLE. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100223004811.4a7e2...@utumno
Re: List of possible empty binary packages
Reinhard Tartler ha scritto: >> http://packages.debian.org/sid/all/byobu-extras/filelist > > thanks, that's indeed correct. This is a transitional convenience > package for supporting partial upgrades for squeeze systems only. It was > never in lenny. Thanks for the clarification! It wasn't excluded because it didn't match conditions and I've overlooked it during manual processing. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Re: List of possible empty binary packages
Stefano Zacchiroli ha scritto: > Is the code you used to detect this available somewhere? I wonder mainly > how did you check if the packages are metapackages/transitional. If it > is something you consider reliable, it would be worth to turn your code > into a lintian check, so that we avoid in the future re-introducing this > kind of bugs. Well, "code" is located on lintian.debian.org/~dktrkranz/empty.sh, it's a very simple shell script which declares a package being empty if all of the following conditions are met: * package does not ship files outside of /usr/share/doc/$pkg * package does not have subdirectories in its /usr/share/doc dir * package does not have a "blacklist" word in its description: - meta - transition - dummy - dependency package - empty package - virtual package After that, I manually sorted resulting packages to remove notable false positives, so it's definitely not reliable enough to provide full automated reports yet, but I can work to define improved conditions. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Re: List of possible empty binary packages
Il giorno Sun, 7 Feb 2010 20:20:08 +0100 Luca Falavigna ha scritto: > I conducted an analysis to see if there are empty packages in the > archive which are not metapackages or transitional ones, and > then prepared a dd-list to show affected packages. To match source packages with affected binaries, you can look at the list I prepared at http://people.debian.org/~dktrkranz/empty_packages Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
List of possible empty binary packages
Hello, I conducted an analysis to see if there are empty packages in the archive which are not metapackages or transitional ones, and then prepared a dd-list to show affected packages. Some packages have been removed from the original list as it was clearly stated in package descriptions they are empty by purpose, others have been manually removed being false positives. There could be more false positives, feel free to report inaccuracies to have a more precise picture for a potential MBF. Adam C. Powell scotch (U) Michael Ablassmeier libapache-mod-chroot Ivanko B mseide-msegui Christian Bac phpgroupware (U) Sebastien Bacher totem Mirco Bauer mono (U) Olivier Berger phpgroupware Armin Berres kdeartwork (U) kdeedu (U) kdepim (U) Laurent Bigonville libchamplain (U) Fathi Boudra kdeartwork (U) kdeedu (U) kdepim (U) mlt Emmanuel Bouthenot weechat Michael Casadevall kdeartwork (U) Michael Casadevall libxfcegui4 (U) Jesus Climent dspam (U) Julien Cristau libxmu (U) LI Daobing liblunar Debian Citadel Team citadel Debian DSPAM Maintainers dspam Debian GCC Maintainers gcc-4.1 Debian GNOME Maintainers libchamplain (U) totem (U) Debian Haskell Group haskell-hsql-mysql Debian Mono Group mono mono-uia Debian Pkg-e Team e17 Debian Qt/KDE Maintainers kdeartwork kdebindings kdeedu kdepim Debian Request Tracker Group request-tracker3.8 Debian Science Team code-saturne Debian Scientific Computing Team fenics scotch suitesparse-metis Debian X Strike Force libxmu Debian Xfce Maintainers libxfcegui4 Debian Xiph.org Maintainers libfishsound Eric Dorland libp11 Sebastian Dröge mono (U) totem (U) vala (U) John Francesco Ferlito libfishsound (U) Freevo Debian Dream Team freevo Wilfried Goesgens citadel (U) Stephen Gran hdparm Debian QA Group avifile GRUB Maintainers grub2 Christoph Haas dspam (U) Dominic Hargreaves request-tracker3.8 (U) Jacob Helwig request-tracker3.8 (U) Simon Huggins libxfcegui4 (U) Mario Iseli libconfig-inetd-perl IV" scotch (U) Kurt B. Kaiser dspam (U) Dustin Kirkland byobu Matthias Klose gcc-4.1 (U) Ivan Kohler request-tracker3.8 (U) Aurelien Labrosse dspam (U) Sylvestre Ledru code-saturne (U) Georg W. Leonhardt freevo (U) Martin Loschwitz libxfcegui4 (U) Ola Lundqvist dpsyco harden Marc-Andre Lureau vala (U) Jan Lübbe e17 (U) Maintainers of Vala packages vala Jordi Mallach grub2 (U) Torsten Marek kdebindings (U) TSUCHIYA Masatoshi mecab-ipadic mecab-jumandic Patrick Matthäi mlt (U) Alastair McKinstry emoslib A Mennucc1 freevo (U) Michael Meskes citadel (U) kdepim (U) Robert Millan grub2 (U) Loic Minier vala (U) Matthijs Mohlmann dspam (U) Emilio Pozuelo Monfort totem (U) Daniel Rus Morales suitesparse-metis (U) Daigo Moriwaki google-perftools ruby1.9 (U) Josselin Mouette totem (U) Toni Mueller request-tracker3.8 (U) David Nusinow libxmu (U) Lucas Nussbaum ruby1.9 (U) Xavier Oswald e17 (U) David Palacio kdebindings (U) Víctor Pérez Pereira haskell-hsql-mysql (U) Yves-Alexis Perez libxfcegui4 (U) Christophe Prud'homme fenics (U) scotch (U) suitesparse-metis (U) Johannes Ring fenics (U) Emanuele Rocca libxfcegui4 (U) Felipe Sateler csound Daniel Schepler kdeedu (U) Jo Shields mono (U) Sjoerd Simons libchamplain totem (U) Jonas Smedegaard csound (U) Lincoln de Sousa freecraft TANIGUCHI Takaki libmoe Reinhard Tartler byobu (U) Enrico Tassi lua-soap lua-xmlrpc Albin Tonnerre e17 (U) Niko Tyni request-tracker3.8 (U) Modestas Vainius kdepim (U) Modestas Vainius kdeartwork (U) kdebindings (U) kdeedu (U) Sune Vuorela kdeartwork (U) kdebindings (U) kdeedu (U) kdepim (U) Ray Wang mono-uia (U) Rudolf Weber dspam (U) Torsten Werner mseide-msegui (U) Alexander Wirt citadel (U) akira yamada ruby1.9 Felix Zielcke grub2 (U) Regards, -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
[RFC] Collecting changelog entries in projectb
Hi, FTP team and I are currently writing a new feature in dak which will collect changelog entries and store them in projectb, to be later used for other purposes (e.g. to write point release changelogs, see [1]). Collecting every changelog entry takes lots of space (the whole past adds up to 7GB), so we thought to limit that to policy queues only (right now stable-proposed-uploads and oldstable-proposed-uploads), unless there is a valid reason to do for every upload in the archive. Can you imagine a useful thing that is worth having every entry in projectb? If so, here's your chance :) [1] http://ftp.debian.org/debian/dists/lenny/ChangeLog -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Bug#563994: ITP: python-geoclue -- Python module to access Geoclue data
Package: wnpp Severity: wishlist Owner: Luca Falavigna X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-geoclue Version : 0.1.0 Upstream Authors: Paulo Cabido * URL : http://live.gnome.org/gtg/soc/python_geoclue * License : GPLv3+ Programming Lang: Python Description : Python module to access Geoclue data This module uses the Geoclue D-Bus API to implement a nice API for Python developers to ease access to and manipulate Geographic information framework data. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Bug#562861: ITP: remmina-xfce -- XFCE applet for Remmina
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: remmina-xfce Version : 0.7.0 Upstream Authors: Vic Lee * URL : http://remmina.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : XFCE applet for Remmina Remmina-XFCE is a XFCE applet for the Remmina application. This XFCE desktop applet allows for easy-access of the Remmina main features. Remmina-XFCE is also able to list all remote desktop files and makes the connection easy. -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: PGP signature
Re: [MBF] Handling python2.4 removal
Il giorno Tue, 15 Dec 2009 23:11:18 +0100 Luca Falavigna ha scritto: > Squeze will release with Python 2.5 and Python 2.6, while Python 2.4 > is scheduled for removal when no packages will depend on it. When > Python 2.6 will enter unstable, Python 2.4 will be no longer > supported version for module and extension building. > > We're proposing a MBF for the following packages to ease transition, > a brief explanation for every class of package involved follows. Here's a follow-up to include some more packages, and to remove those which were already fixed in the meantime. --- NEED CODE/PACKAGING CHANGES --- These packages build-depend or depend on one of the package built on top of python2.4 source, and will be uninstallable when those packages will be removed from Sid and Squeeze. Jeff Breidenbach jcc Debian Games Team adonthell Debian/Ubuntu Zope Team zope-common zope2.10 zope2.11 Barry deFreese adonthell (U) Debian QA Group graphviz Bjørn Hansen balder2d Ian Jackson autopkgtest Matthias Klose python-extclass zope-common (U) martin f. krafft zope-common (U) Rafael Laboissiere plplot (U) Jeremy Lainé kdevelop Iain Lane adonthell (U) Andrea Mennucci zope-common (U) Jonas Meurer zope-common (U) zope2.10 (U) zope2.11 (U) Andrew Ross plplot Fabio Tranchitella zope-common (U) zope2.10 (U) zope2.11 (U) Bernd Zeimetz zope-common (U) zope2.10 (U) zope2.11 (U) -- NEED A SOURCEFUL UPLOAD WITH NO CODE/PACKAGING CHANGES -- In order to get rid of dependencies on python2.4 package, a no-change sourceful upload should be enough in most cases for those packages. Sebastien Bacher pyorbit Daniel Baumann pywebdav (U) Mathias Behrle pywebdav (U) Vincent Bernat simpleparse (U) sshproxy Vincent Danjean commit-tool Debian GNOME Maintainers pyorbit (U) Debian Python Modules Team simpleparse Debian/Ubuntu Zope Team zc.buildout zodb zope.testing Dirk Eddelbuettel nwsclient Luca Falavigna pyorbit (U) Alexandre Fayolle pyqonsole Matthias Klose zope.testing (U) Jan Lübbe bitbake Debian Tryton Maintainers pywebdav Loic Minier pyorbit (U) Josselin Mouette pyorbit (U) Brian Sutherland zodb (U) zope.testing (U) Fabio Tranchitella zc.buildout (U) zodb (U) zope.testing (U) - NEED A BINNMU - These packages should be fixed with a binNMU. Loic Dachary (OuoU) pypoker-eval Sebastien Bacher gnome-python-extras Michael Banck opensync Luciano Bello libmimic Calendarserver Maintainers twisted-calendarserver Carl Chenet rdiff-backup Pierre Chifflier libcap-ng Debian GNOME Maintainers gnome-python-extras (U) Debian Python Modules Team pykcs11 (U) pyscard (U) Sebastian Dröge gstreamer0.10-rtsp (U) Guido Guenther twisted-calendarserver (U) Anders Hammarquist python-meld3 Thomas Jollans chatplus Jonny Lamb librra Arthur Loiret medit Maintainers of GStreamer packages gstreamer0.10-rtsp (U) A Mennucc1 xdelta3 Loic Minier gnome-python-extras (U) rpm (U) Josselin Mouette gnome-python-extras (U) Sam Hocevar (Debian packages) papaya Kari Pahula crossfire Lucas Di Pentima gwp Python Applications Packaging Team rdiff-backup (U) Sebastian Reichel gstreamer0.10-rtsp Ludovic Rousseau pykcs11 pyscard David Smith pykcs11 (U) Davide Truffa obmenu Jelmer Vernooij subvertpy Michal Čihař rpm -- PACKAGES TO BE REMOVED -- These packages ship modules or extensions already provided by python2.5 or newer Python versions, so they should be not needed anymore, a RM request will be filed. Maintainers of packages that build-depend or depend on these should update their packages. This will be the subject for a future MBF. SZALAY Attila zorp Debian Python Modules Team celementtree ctypes (U) elementtree Raphael Hertzog celementtree (U) Scott Kitterman celementtree (U) Matthias Klose python2.4-doc Torsten Marek celementtree (U) elementtree (U) Python Modules Packaging Team python-wsgiref (U) Ganesan Rajagopal ctypes Noah Slater python-wsgiref Bernd Zeimetz elementtree (U) Regards, -- Matthias Klose, Scott Kitterman & Luca Falavigna signature.asc Description: PGP signature
[MBF] Handling python2.4 removal
Squeze will release with Python 2.5 and Python 2.6, while Python 2.4 is scheduled for removal when no packages will depend on it. When Python 2.6 will enter unstable, Python 2.4 will be no longer supported version for module and extension building. We're proposing a MBF for the following packages to ease transition, a brief explanation for every class of package involved follows. --- NEED CODE/PACKAGING CHANGES --- These packages build-depend or depend on one of the package built on top of python2.4 source, and will be uninstallable when those packages will be removed from Sid and Squeeze. SZALAY Attila zorp Debian/Ubuntu Zope Team zope-common zope2.10 zope2.11 Bjørn Hansen balder2d Ian Jackson autopkgtest Matthias Klose python-extclass zope-common (U) martin f. krafft zope-common (U) Rafael Laboissiere plplot (U) Andrea Mennucci zope-common (U) Jonas Meurer zope-common (U) zope2.10 (U) zope2.11 (U) Andrew Ross plplot Filippo Rusconi mmass (U) The Debichem Group mmass Fabio Tranchitella zope-common (U) zope2.10 (U) zope2.11 (U) Bernd Zeimetz zope-common (U) zope2.10 (U) zope2.11 (U) -- NEED A SOURCEFUL UPLOAD WITH NO CODE/PACKAGING CHANGES -- In order to get rid of dependencies on python2.4 package, a no-change sourceful upload should be enough in most cases for those packages. Daniel Baumann pywebdav (U) Mathias Behrle pywebdav (U) Vincent Danjean commit-tool Debian/Ubuntu Zope Team zc.buildout zconfig zodb zope.testing Dirk Eddelbuettel nwsclient Matthias Klose zope.testing (U) Debian Tryton Maintainers pywebdav Brian Sutherland zconfig (U) zodb (U) zope.testing (U) Fabio Tranchitella zc.buildout (U) zconfig (U) zodb (U) zope.testing (U) - NEED A BINNMU - These packages should be fixed with a binNMU. Loic Dachary (OuoU) pypoker-eval Sebastien Bacher gnome-python-extras Michael Banck opensync Luciano Bello libmimic Pierre Chifflier libcap-ng Debian GNOME Maintainers gnome-python-extras (U) Debian Python Modules Team pykcs11 (U) pyscard (U) Sebastian Dröge gstreamer0.10-rtsp (U) Thomas Jollans chatplus Jonny Lamb librra Maintainers of GStreamer packages gstreamer0.10-rtsp (U) A Mennucc1 xdelta3 Loic Minier gnome-python-extras (U) rpm (U) Josselin Mouette gnome-python-extras (U) Kari Pahula crossfire Sebastian Reichel gstreamer0.10-rtsp Ludovic Rousseau pykcs11 pyscard David Smith pykcs11 (U) Jelmer Vernooij subvertpy Michal Čihař rpm -- PACKAGES TO BE REMOVED -- These packages ship modules or extensions already provided by python2.5 or newer Python versions, so they should be not needed anymore, a RM request will be filed. Maintainers of packages that build-depend or depend on these should update their packages. This will be the subject for a future MBF. Debian Python Modules Team celementtree ctypes (U) elementtree Raphael Hertzog celementtree (U) Scott Kitterman celementtree (U) Torsten Marek celementtree (U) elementtree (U) Python Modules Packaging Team python-wsgiref (U) Ganesan Rajagopal ctypes Noah Slater python-wsgiref Bernd Zeimetz elementtree (U) Regards, -- Scott Kitterman & Luca Falavigna signature.asc Description: PGP signature
Bug#551274: ITP: python-wadllib -- Python library for navigating WADL files
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-wadllib Version : 1.1.4 Upstream Author : Canonical Ltd. * URL : https://launchpad.net/wadllib * License : LGPLv3 Programming Lang: Python Description : Python library for navigating WADL files The Web Application Description Language (WADL) is an XML vocabulary for describing the capabilities of HTTP resources. wadllib can be used in conjunction with an HTTP library to navigate and manipulate those resources. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551275: ITP: lazr.restfulclient -- client for lazr.restful-based web services
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: lazr.restfulclient Version : 0.9.9 Upstream Author : Canonical Ltd. * URL : https://launchpad.net/lazr.restfulclient * License : LGPLv3 Programming Lang: Python Description : client for lazr.restful-based web services A programmable client library that takes advantage of the commonalities among lazr.rest web services to provide added functionality on top of wadllib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551273: ITP: python-launchpadlib -- Launchpad web services client library
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-launchpadlib Version : 1.5.2 Upstream Author : Canonical Ltd. * URL : https://launchpad.net/launchpadlib * License : LGPLv3 Programming Lang: Python Description : Launchpad web services client library Python library for scripting Launchpad through its web services interface. It provides access to the following parts of Launchpad: * People and Teams * Team memberships * Bugs and bugtasks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551005: ITP: blogtk -- client for weblog systems
Package: wnpp Severity: wishlist Owner: Luca Falavigna * Package name: blogtk Version : 2.0 Upstream Author : Jay Reding * URL : https://launchpad.net/blogtk * License : Apache 2.0 Programming Lang: Python Description : client for weblog systems BloGTK is a client for weblog systems like Blogger, WordPress, and Movable Type. BloGTK makes managing blog posts easy, especially for people who have multiple blogs. BloGTK works with any blogging system that supports XML-RPC publishing. BloGTK will run on any system that supports the GNOME desktop environment. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python 2.6? A Python transition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery ha scritto: >> First, the installation path changed from site-packages to >> dist-packages. This means that most Python packages will need two >> changes: > >> * passing --install-layout=deb to setup.py > > Okay, that's easy enough. I assume that doesn't break builds for Python > 2.5 (or 2.4, to the extent it's still supported)? - --install-layout option has been implemented (as a no-op) both in python2.5 (>= 2.5.3-1~exp1) and python2.4 (>= 2.4.6-2~exp1). - -- .''`. : :' : Luca Falavigna `. `' `- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqXgKcACgkQnXjXEYa8KlDUfwCePZ3WG+wLRDUM2Te1L7CAkja6 io0An15fxktJObjGFZdwLtzkT3gsWTUf =wVCq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Python 2.6? A Python transition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery ha scritto: > Is there a best practice guide somewhere, and if we are doing a > transition, a guide for those of us who only have ancillary involvement in > Python packaging telling us what to do? Some references can be found here (and in follow-ups): http://lists.debian.org/debian-devel/2009/02/msg00431.html http://lists.debian.org/debian-python/2009/03/msg00091.html https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028266.html Regards, - -- .''`. : :' : Luca Falavigna `. `' `- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqU94cACgkQnXjXEYa8KlD/mgCgnyVOIUQbbQs5X66Bj5p94Ium xGwAn1OIoZnanQJW59owXVhaLGUrX2zb =Unfy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: waf into NEW, please test it with your packages
Il giorno Fri, 31 Jul 2009 22:14:14 -0700 Ryan Niebur ha scritto: > On Sat, Aug 01, 2009 at 02:48:37AM +0200, Cyril Brulebois wrote: > > Ryan Niebur (30/07/2009): > > > would you mind providing a .deb of that so that I can test and > > > update my dh build system patch to use it? > > > > waf deb? Check first mail in the thread. > > > > ok, I misunderstood what Luca was saying. I thought Luca meant a new > version of waf, not a new version of midori :/. Yes, I meant new midori upstream version. I haven't specified it, sorry. We prepared waf_1.5.8+dfsg-2, which implements compatibility with intltool and older versions of wscript. I uploaded preview packages: http://alioth.debian.org/~dktrkranz-guest/waf_1.5.8+dfsg-2/ -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature
Re: waf into NEW, please test it with your packages
Ryan Niebur ha scritto: > It doesn't work with midori apparently... Right, I prepared a patch to build with 0.1.7, but I noticed new upstream version (0.1.8) builds correctly. If you plan to upgrade to the new version, you should not have any issue with waf Debian package. Thanks for testing! Regards, -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: OpenPGP digital signature
waf into NEW, please test it with your packages
Hello, waf has been recently sponsored and it's currently in NEW (until it lasts, you can see its details at [1]). waf preferred design is to provide a self-unpacking Python script to be installed into projects' root directories and then executed from there, we adjusted it to be available system-wide, so everyone can use it, no matter if waf script is available in upstream tarballs or not. As you can see from [2], we decided to remove some files with potential license issues (mainly files under QPL and GFDL), so we are sure to distribute a full DFSG-compliant waf package to our users. several Debian source packages ship an internal copy of such a script, which distributes non-free files and creates code duplication. Here's a dd-list output of interested packages, this has been obtained using Debian source search service [3], so some packages could be missing, please notify me in such a case. Sebastien Bacher gnome-python Thomas Bläsing hotssh Debian GNOME Maintainers gnome-python (U) gnome-python-desktop (U) Debian Xfce Maintainers gigolo Sebastian Dröge gnome-python-desktop (U) Peter Eisentraut kdissert Simon Huggins gigolo (U) Thomas Jollans abraca xmms2 (U) Jonne Lehtinen xmms2 (U) Loic Minier gnome-python (U) gnome-python-desktop Emilio Pozuelo Monfort gnome-python (U) Josselin Mouette gnome-python (U) gnome-python-desktop (U) Ryan Niebur midori Stefan Ott gigolo (U) Yves-Alexis Perez gigolo (U) Python Applications Packaging Team hotssh (U) Florian Ragwitz xmms2 Emanuele Rocca gigolo (U) Gustavo Noronha Silva gnome-python-desktop (U) Jens Taprogge xmms2 (U) Damián Viano geany Anders Waldenborg xmms2 (U) I published preview waf packages at [4], so you can test if your packages can be built with our package instead of custom scripts. Please report any bug or issue you find, so we can fix them when waf comes out NEW and reaches mirror network. When waf is published, I will file bugs to start the transition. Thank you! [1]http://ftp-master.debian.org/new/waf_1.5.8+dfsg-1.html [2]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/README.source?r1=3307&r2=3325 [3]http://walrus.rave.org/source/ [4]http://alioth.debian.org/~dktrkranz-guest/waf_1.5.8+dfsg-1/ -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature
Bug#537292: ITP: grdc -- remote desktop client based on GTK+ and GNOME
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: grdc Version : 0.6.0 Upstream Authors: Vic Lee * URL : http://grdc.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : remote desktop client based on GTK+ and GNOME Grdc is a remote desktop connection client that can view and control a desktop session running on another system. It can connect to a VNC platform as well windows terminal servers. Grdc is an application based on GNOME and GTK+. Features include a scrollable window, floating toolbar, keyboard grabbing, and so on. -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature
Bug#537293: ITP: grdc-gnome -- GNOME applet for grdc
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: grdc-gnome Version : 0.6.0 Upstream Authors: Vic Lee * URL : http://grdc.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : GNOME applet for grdc Grdc-gnome is a GNOME applet for the grdc application. This GNOME desktop applet allows for easy-access of the grdc main features. Grdc-gnome is also able to list all remote desktop files and makes the connection easy. -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature
Bug#535619: ITP: python-keybinder -- register global key bindings for gtk-based apps
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: python-keybinder Version : 0.0.2 Upstream Authors: Ulrik Sverdrup Nigel Tao Raphaël Slinckx Sebastian Pölsterl Alex Graveley * URL : http://kaizer.se/wiki/python-keybinder/ * License : GPLv2 Programming Lang: C Description : register global key bindings for gtk-based apps Python extension to allow applications to register a key binding to be later executed when a combination of keys is pressed. signature.asc Description: PGP signature
Bug#535617: ITP: kupfer -- fast and lightweigh desktop summoner/launcher
Package: wnpp Owner: Luca Falavigna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kupfer Version : c1 Upstream Author : Ulrik Sverdrup * URL : http://kaizer.se/wiki/kupfer/ * License : GPLv3 Programming Lang: Python Description : fast and lightweigh desktop summoner/launcher Kupfer is a summoner/launcher in the style of Quıcĸsılvεʀ or Gnome Do. It can search and browse your files, launch desired applications and objects you need. Kupfer is written in Python and has a flexible architecture based on plugins to extend its features. signature.asc Description: PGP signature
Re: debian and lilypond 2.12
Il giorno Sun, 07 Jun 2009 15:59:55 +0200 Gilles Filippini ha scritto: > It appears that lilypond is actively maintained in ubuntu[1]. > I'd like to take over this package in Debian but I don't know about > the practices when a package is already maintained in Ubuntu: > * should I start from the Ubuntu source package? You could do it if you plan to include Ubuntu changes in Debian. If you decide to package it from scratch, Ubuntu will merge your package applying Ubuntu adjustments on top of it until there is need to. > * the Ubuntu lilypond release is now 2.12.1-0ubuntu1; what should be > the debian release then? 2.12.1-1? Yes. > * or simply persuade the ubuntu maintainer to package it for Debian ;) > (cc-ing him)? Ubuntu usually haven't designed maintainers, think of it as a global QA effort to have package in shape. If you want, you can contact the last person who touched it to see if he has interest in maintaining it, but it is usually not the case. -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature
Re: Possible mass bug filing: non-doc packages recommending doc packages
Y Giridhar Appaji Nag ha scritto: > Would there be any objections to filing minor/wishlist bugs against these > packages? I am including a tentative dd-list corresponding to the packages > [1] that I found after manually removing some packages [2]. I will modify it > based on suggestions. > > Luca Falavigna >drpython Fixed in SVN, will appear in the next upload. Thank you! :) -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: OpenPGP digital signature
