Bug#839915: ITP: crac -- integrated RNA-Seq read analysis
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: crac Version : 2.5.0 Upstream Author : Nicolas PHILIPPE, Mikaël SALSON, a.o. * URL : http://crac.gforge.inria.fr * License : CeCILL Programming Lang: C++ Description : integrated RNA-Seq read analysis CRAC is a tool to analyze High Throughput Sequencing (HTS) data in comparison to a reference genome. It is intended for transcriptomic and genomic sequencing reads. More precisely, with transcriptomic reads as input, it predicts point mutations, indels, splice junction, and chimeric RNAs (ie, non colinear splice junctions). CRAC can also output positions and nature of sequence error that it detects in the reads. CRAC uses a genome index. This index must be computed before running the read analysis. For this sake, use the command "crac-index" on your genome files. You can then process the reads using the command crac. See the man page of CRAC (help file) by typing "man crac". CRAC requires large amount of main memory on your computer. For processing against the Human genome, say 50 million reads of 100 nucleotide each, CRAC requires about 40 gigabytes of main memory. Check whether the system of your computing server is equipped with sufficient amount of memory before launching an analysis. Remark: This package is maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/crac.git
Re: Interface of `shutdown', 'halt', ... programs
> > #838480 > > [...] > > Any suggestions? > > Is it possible to use a pointyclicky desktoppy widgety thing to reboot > a system with runit ? I guess from your mails you use the command > line. > [...] > I think if I were you I would try installing a system with runit and > GNOME, make enough of an emulation that the GNOME shutdown and reboot > functions work, and call that "done". Thank you for your advice, Ian. You guessed correctly -- 'sudo init 0' is good enough for me and I have little knowledge about "pointy-clicky" things. While I can install GNOME on virtual machine (sigh) there are also other desktop enviroments (KDE, XFCE, ...). Is there some common way to get "pointy-clicky widget"? I assume (correct me, if I am wrong) all desktop enviroments share some mechanism how to invoke root-only command (shutdown) as regular user, so there may be way to invoke just shutdown menu, without need other parts of desktop enviroments. More suggestions are welcome. -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff| is urgent, you have my phone number.
Re: Interface of `shutdown', 'halt', ... programs
Hi, On 06/10/16 11:51, Dmitry Bogatov wrote: >>> #838480 >>> [...] >>> Any suggestions? >> >> Is it possible to use a pointyclicky desktoppy widgety thing to reboot >> a system with runit ? I guess from your mails you use the command >> line. >> [...] >> I think if I were you I would try installing a system with runit and >> GNOME, make enough of an emulation that the GNOME shutdown and reboot >> functions work, and call that "done". > > Thank you for your advice, Ian. You guessed correctly -- 'sudo init 0' is > good enough for me and I have little knowledge about "pointy-clicky" > things. While I can install GNOME on virtual machine (sigh) there are > also other desktop enviroments (KDE, XFCE, ...). > > Is there some common way to get "pointy-clicky widget"? I assume > (correct me, if I am wrong) all desktop enviroments share some > mechanism how to invoke root-only command (shutdown) as regular user, > so there may be way to invoke just shutdown menu, without need other > parts of desktop enviroments. GNOME does this using logind which is probably the closest you'd get to a common interface for this. If using systemd-shim to implement logind for runit, you would need to provide the shutdown and reboot commands used here: https://sources.debian.net/src/systemd-shim/10-2/src/power-unit.c/ James signature.asc Description: OpenPGP digital signature
Re: Interface of `shutdown', 'halt', ... programs
Dmitry Bogatov writes ("Re: Interface of `shutdown', 'halt', ... programs"):
> Thank you for your advice, Ian. You guessed correctly -- 'sudo init 0' is
> good enough for me and I have little knowledge about "pointy-clicky"
> things. While I can install GNOME on virtual machine (sigh) there are
> also other desktop enviroments (KDE, XFCE, ...).
>
> Is there some common way to get "pointy-clicky widget"? I assume
> (correct me, if I am wrong) all desktop enviroments share some
> mechanism how to invoke root-only command (shutdown) as regular user,
> so there may be way to invoke just shutdown menu, without need other
> parts of desktop enviroments.
Do you have the ability to install on a second system, or maybe dual
boot, or something ? I would suggest doing a default install but with
runit (not sure how one would even do that) and just letting it
install gnome.
Failing that: I use `trayer' on my laptop as a thing to allow the
handful of desktoppy pointyclicky icony things I like, to have their
icon. Eg the network manager applet.
You could try that, plus installing some desktop's power manager.
Maybe desktoppy kind of people will be able to advise.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
Hi, 2016-10-06 8:46 GMT+02:00 Scott Kitterman : > > > On October 6, 2016 2:04:36 AM EDT, Samuel Thibault > wrote: >>Paul Wise, on Thu 06 Oct 2016 11:40:12 +0800, wrote: >>> On Thu, Oct 6, 2016 at 12:53 AM, Samuel Thibault wrote: >>> > So if some of these packages is falling down, the >>debian-accessibility >>> > team *has* to be notified so we can find a solution. Maybe we >>should >>> > put in the ftp-master process that an RM request for any kind of >>> > accessibility-related package shouldn't be processed without an ACK >>from >>> > the debian-accessibility team? >>> >>> These kind of issues aren't specific to removal of accessibility >>> packages; >> >>The kind of issue isn't specific indeed. But the consequence is >>specific: the result is that some people can not use Debian any more at >>all. That's very different from just missing a program you really want >>to have. >> >>Scott Kitterman, on Thu 06 Oct 2016 00:08:19 -0400, wrote: >>> It's extremely rare that a removal is problematic. It does happen >>and in >>> cases where it does, the FTP team is generally happy to expedite a >>package >>> back through New. >>> >>> Speaking only for myself, I think the level of work implied in your >>request >>> translates into removals don't happen. If you think this work should >>be done, >>> I encourage you to comment on the removal bugs requesting that the >>removal be >>> held in abeyance while you do it (also adding a moreinfo tag is >>helpful). >> >>I'm not sure to understand what you meant exactly here. >>debian-accessibility wasn't aware of the RM request before it was >>processed. Realizing that and having to go through NEW again is not >>technically hard, sure, but it takes a lot of energy to go pass the >>frustration that it happened at all. > > Agreed it's frustrating, but I don't think it's the FTP Team's job to second > guess a maintainer request for removal of a buggy package. I doubt most > people appreciate the volume of rm bugs. FTP Team spending significant time > figuring out if maybe someone else might care just doesn't scale. > > As frustrating as occasional removal/reintroduction cycles are, they are rare > enough that despite the frustration when they occur it's really not worth the > effort it would take to avoid them completely. I agree that we should not ask the FTP Team to take extra steps before performing removals. They already take care of many things and nowadays nowadays they act on uploads to NEW amazingly fast! Dear FTP Team, thank you, accepting packages with so little delay is a huge help! If there is something that we can do related to removals then it would be waiting with the removals one or two weeks after the removal request is filed. This time would most probably be enough for interested parties to fix the package or at least signal their intentions. Regarding dasher I did the last upload around the last freeze to keep it in stable and my plan was packaging new upstream for Stretch, but I was busy with other packages which require a transition thus should be ready this month. I'm sorry for not stating that in dasher's bugs, but I would have shared my plans if I knew about the removal. Thibaut Paumard already filed an ITP and thank you for that. Requesting the removal was a mistake IMO, but it can be fixed. We will ship dasher in Stretch and we still care about people who need it for using their computers. Cheers, Balint
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
06.10.2016, 07:54, "Paul Wise" : > On Wed, Oct 5, 2016 at 11:00 PM, Ponomarenko Andrey wrote: > >> I'd like to present a new free tool for maintainers of software libraries — >> Package ABI Diff Tool (Pkg-ABIdiff). It's a tool for backward compatibility >> analysis of API/ABI interfaces in Deb packages. The tool is based on ABI >> Compliance Checker and ABI Dumper tools. > > Does this have any advantages over abipkgdiff from the abigail-tools > Debian package already in Debian? > > BTW, I think it would be really interesting to run > pkg-abidiff/abipkgdiff over the whole Debian archive and possibly use > that to inform the release team of uncaught ABI changes. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise I guess, checks for more compatibility rules, less false positives, visual reports, problem severity levels and separated analysis of both backward binary compatibility and backward source compatibility are main advantages of the pkg-abidiff. The disadvantage is that pkg-abidiff may not be as fast as abipkgdiff, because pkg-abidiff is written in Python, but abipkgdiff is written in C++. The tools are based on different software stacks. The pkg-abidiff is based on ABI Compliance Checker and ABI Dumper tools (https://github.com/lvc) developed since 2009. The abipkgdiff is based on libabigail developed since 2013. So, implementations and reports are completely different. Anyway, it's better to run both tools on all packages at the same time and verify reports of each other. Thank you.
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote: >... > As frustrating as occasional removal/reintroduction cycles are, they are rare > enough that despite the frustration when they occur it's really not worth the > effort it would take to avoid them completely. This assumes that all users are developers who are following unstable. The vast majority of Debian users won't use stretch until after it became stable. And even if a user does use unstable or testing, there is no clear way for a non-developer do get a removed package back into unstable. It is a problem for users when Debian is a revolving door for packages that get ITP'ed into one stable and then disappear without a good reason for removal in a later stable. Example maintainer opinion: [1,2] If we orphan 2.x someone might fix the RC bug and get it back into testing. At this point I think releasing stretch with 2.x would be worse than releasing stretch without freeradius. When a user who uses FreeRADIUS 2.2.5 in jessie upgrades to stretch after it became stable, is it worse for the user he gets FreeRADIUS 2.2.9 in stretch with 3 years (or 5 years with LTS) of security support,[3] or if he gets no FreeRADIUS in stretch? FreeRADIUS is high-profile enough that many Debian developers do care and new maintainers were quickly found. Many other packages are not. > Scott K cu Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806617#42 [2] this is *not* meant against this soecific maintainer, but it is impossible to quote a maintainer opinion from a public BTS without revealing who it is [3] the security team stating that it cannot support something would be a good reason for not shipping in stretch, but that seems unlikely for FreeRADIUS 2.2 and would be orthogonal to my point regarding users -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
Le 06/10/2016 à 13:30, Bálint Réczey a écrit : > Regarding dasher I did the last upload around the last freeze to keep > it in stable > and my plan was packaging new upstream for Stretch, but I was busy > with other packages which require a transition thus should be ready > this month. > > I'm sorry for not stating that in dasher's bugs, but I would have > shared my plans > if I knew about the removal. > > Thibaut Paumard already filed an ITP and thank you for that. Dear Bálint, I'm working on reintroducing dasher with minimal changes to fix the RC bugs first because I don't know anything about the package yet (compiled it on stable today without issue). If you can beat me on that, please let me know and just do it :-) Regards, Thibaut.
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
Hi Andrey, how are they related to the dpkg-gensymbols? Would it make sense to use the symbol files with it or have it as an alternative to dpkg-gensymbols? * Ponomarenko Andrey [2016-10-06 15:23]: > Anyway, it's better to run both tools on all packages at the same time and > verify reports of each other. Would it be possible to do that automatically using debhelper? Or if not, maybe download the current deb from the archive and compare it? Cheers Jochen signature.asc Description: PGP signature
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
El Dijous, 6 d'octubre de 2016, a les 15:23:10, Ponomarenko Andrey va escriure: > 06.10.2016, 07:54, "Paul Wise" : > > On Wed, Oct 5, 2016 at 11:00 PM, Ponomarenko Andrey wrote: > >> I'd like to present a new free tool for maintainers of software > >> libraries — Package ABI Diff Tool (Pkg-ABIdiff). It's a tool for > >> backward compatibility analysis of API/ABI interfaces in Deb packages. > >> The tool is based on ABI Compliance Checker and ABI Dumper tools.> > > Does this have any advantages over abipkgdiff from the abigail-tools > > Debian package already in Debian? > > > > BTW, I think it would be really interesting to run > > pkg-abidiff/abipkgdiff over the whole Debian archive and possibly use > > that to inform the release team of uncaught ABI changes. > > > > -- > > bye, > > pabs > > > > https://wiki.debian.org/PaulWise > > I guess, checks for more compatibility rules, less false positives, visual > reports, problem severity levels and separated analysis of both backward > binary compatibility and backward source compatibility are main advantages > of the pkg-abidiff. The disadvantage is that pkg-abidiff may not be as fast > as abipkgdiff, because pkg-abidiff is written in Python, but abipkgdiff is > written in C++. > > The tools are based on different software stacks. The pkg-abidiff is based > on ABI Compliance Checker and ABI Dumper tools (https://github.com/lvc) > developed since 2009. The abipkgdiff is based on libabigail developed since > 2013. So, implementations and reports are completely different. > > Anyway, it's better to run both tools on all packages at the same time and > verify reports of each other. > Then I would like to ask when we must think that we need a transition for a the package. If these test shows a binary compatibility of 99%, do we need to create a need soname bump and initiate a transition? Best regards, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: This is a digitally signed message part.
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
06.10.2016, 15:32, "Ponomarenko Andrey": > 06.10.2016, 07:54, "Paul Wise": >> On Wed, Oct 5, 2016 at 11:00 PM, Ponomarenko Andrey wrote: >> >>> I'd like to present a new free tool for maintainers of software libraries >>> — Package ABI Diff Tool (Pkg-ABIdiff). It's a tool for backward >>> compatibility analysis of API/ABI interfaces in Deb packages. The tool is >>> based on ABI Compliance Checker and ABI Dumper tools. >> >> Does this have any advantages over abipkgdiff from the abigail-tools >> Debian package already in Debian? >> >> BTW, I think it would be really interesting to run >> pkg-abidiff/abipkgdiff over the whole Debian archive and possibly use >> that to inform the release team of uncaught ABI changes. >> >> -- >> bye, >> pabs >> >> https://wiki.debian.org/PaulWise > > I guess, checks for more compatibility rules, less false positives, visual > reports, problem severity levels and separated analysis of both backward > binary compatibility and backward source compatibility are main advantages of > the pkg-abidiff. The disadvantage is that pkg-abidiff may not be as fast as > abipkgdiff, because pkg-abidiff is written in Python, but abipkgdiff is > written in C++. > > The tools are based on different software stacks. The pkg-abidiff is based on > ABI Compliance Checker and ABI Dumper tools (https://github.com/lvc) > developed since 2009. The abipkgdiff is based on libabigail developed since > 2013. So, implementations and reports are completely different. > > Anyway, it's better to run both tools on all packages at the same time and > verify reports of each other. > > Thank you. After a closer look at the source code, reports and docs of abipkgdiff / libabigail tools I can list more pros and cons of https://github.com/lvc/pkg-abidiff / abi-compliance-checker: PROS - separated analysis of both backward binary compatibility and backward source compatibility - assigning severity levels to ABI changes - explaining effects of ABI changes - checks for more compatibility rules - less false positives - visual reports - grouping of affected ABI interfaces by root cause (usually a change in the structure of data type), so the output report is more compact and easy to review - estimating total compatibility rate of an object CONS - may be slower and consume more RAM memory than libabigail tools due to implementation language (C++ vs Python/Perl/C) - the generation of output report is not configurable (can't pass any additional options to abi-compliance-checker via cli interface of pkg-abidiff) - no option to generate detailed plain-text report (only console output and summary report in JSON format are present) Thank you.
Re: Network access during build
2016-09-07 12:32 GMT+02:00 Paul Wise : > On Wed, Sep 7, 2016 at 6:06 PM, Guillem Jover wrote: > > I think what we actually want is for the build to be self-contained. > > So nothing inside the build environment (defined as dpkg-buildpackage > or debian/rules and all sub-processes) should contact any processes, > network resources nor use any files outside the build environment > (modulo /dev/null and the like). > > Is there some simple way to check, when using sbuild, that the build does not access network ? Jérémy.
Bug#839943: ITP: lxqt-build-tools -- Set of scripts required to build LXQt desktop environment
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-build-tools Version : 0.1.0 Upstream Author : Luís Pereira * URL : https://github.com/lxde/lxqt-build-tools * License : LGPL-2.1+ and BSD-3-clause Programming Lang: cmake Description : Set of scripts required to build LXQt desktop environment Right now the package contain the needed cmake scripts for building the LXQT desktop environment. More scripts will follow over time. Maintainer of the package will be the LXQt Packaging Team
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
On October 6, 2016 8:51:59 AM EDT, Adrian Bunk wrote: >On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote: >>... >> As frustrating as occasional removal/reintroduction cycles are, they >are rare enough that despite the frustration when they occur it's >really not worth the effort it would take to avoid them completely. > >This assumes that all users are developers who are following unstable. > >The vast majority of Debian users won't use stretch until after it >became stable. > >And even if a user does use unstable or testing, there is no clear way >for a non-developer do get a removed package back into unstable. > >It is a problem for users when Debian is a revolving door >for packages that get ITP'ed into one stable and then disappear >without a good reason for removal in a later stable. > >Example maintainer opinion: [1,2] > If we orphan 2.x someone might fix the RC bug and get it back into > testing. > At this point I think releasing stretch with 2.x would be worse than > releasing stretch without freeradius. > >When a user who uses FreeRADIUS 2.2.5 in jessie upgrades to stretch >after it became stable, is it worse for the user he gets FreeRADIUS >2.2.9 >in stretch with 3 years (or 5 years with LTS) of security support,[3] >or if he gets no FreeRADIUS in stretch? > >FreeRADIUS is high-profile enough that many Debian developers do care >and new maintainers were quickly found. Many other packages are not. ... This is all true, but in the end, Debian is a do-acracy. While we should try to do the best for our users, there's no way we can do everything for everyone. Users who want to increase the chances our next release scratches whatever their personal itch is need to get involved with development. Scott K
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
On 2016-10-06, Ponomarenko Andrey wrote:
> The tools are based on different software stacks.
> The pkg-abidiff is based on ABI Compliance Checker and ABI Dumper tools
> (https://github.com/lvc)
> developed since 2009.
The ABI compliance checker is the only tool that I have tried that
actually works and doesn't provide any false OK's or false Not-ok's of
what I have noticed so far.
(The only "false not-ok" I've seen, which is also questionable, and only
tagged at medium level is of enums of the construction
enum Modes {
firstmode = 0,
secondmode = 1,
thirdmode,
fourthmode,
NumberOfModes
}
where the last one gets renumbered when a fifthmode is added, and only
to be used in loops as end point. But in general it is a style I don't
recommend, and it is also one incredibly hard to autodetect)
/Sune
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
On Thu, Oct 06, 2016 at 02:46:46PM -0400, Scott Kitterman wrote: > > > On October 6, 2016 8:51:59 AM EDT, Adrian Bunk wrote: > >On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote: > >>... > >> As frustrating as occasional removal/reintroduction cycles are, they > >are rare enough that despite the frustration when they occur it's > >really not worth the effort it would take to avoid them completely. > > > >This assumes that all users are developers who are following unstable. > > > >The vast majority of Debian users won't use stretch until after it > >became stable. > > > >And even if a user does use unstable or testing, there is no clear way > >for a non-developer do get a removed package back into unstable. > > > >It is a problem for users when Debian is a revolving door > >for packages that get ITP'ed into one stable and then disappear > >without a good reason for removal in a later stable. > > > >Example maintainer opinion: [1,2] > > If we orphan 2.x someone might fix the RC bug and get it back into > > testing. > > At this point I think releasing stretch with 2.x would be worse than > > releasing stretch without freeradius. > > > >When a user who uses FreeRADIUS 2.2.5 in jessie upgrades to stretch > >after it became stable, is it worse for the user he gets FreeRADIUS > >2.2.9 > >in stretch with 3 years (or 5 years with LTS) of security support,[3] > >or if he gets no FreeRADIUS in stretch? > > > >FreeRADIUS is high-profile enough that many Debian developers do care > >and new maintainers were quickly found. Many other packages are not. > ... > > This is all true, but in the end, Debian is a do-acracy. While we should try > to do the best for our users, there's no way we can do everything for > everyone. Users who want to increase the chances our next release scratches > whatever their personal itch is need to get involved with development. I am not disputing that. What I am saying is that "try to do the best for our users" includes "do not remove a package that is in stable without a good reason from the next stable". I am not saying that anyone has an obligation to fix RC issues in packages he does not maintain. If there is an RC issue that doesn't get fixed, that is a good reason. If Debian is not able to provide security support for a package, that is a good reason. "maintainer doesn't want his package in the next stable" or "package is orphaned" alone are not good reasons, especially when the package is in testing or only kept out of testing by a maintainer not applying a fix. "upstream is dead" is also less obvious that it looks at first sight. For some packages it does not even matter that much (e.g. packages supporting specific older hardware). Code that works for 10 years is also not necessarily in a worse state than some random code a highschool student pushed to GitHub that gets ITP'ed. I do see the problem that Debian accumulates more and more packages, but instead of being a revolving door for packages Debian would need a policy for ITPs if that should change. > Scott K cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#839964: ITP: ace-window -- selecting a window to switch to
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: ace-window Version : 0.9.0 Upstream Author : Oleh Krehel * URL : https://github.com/abo-abo/ace-window * License : GPL-3+ Programming Lang: Emacs Lisp Description : selecting a window to switch to The main function, `ace-window' is meant to replace `other-window'. In fact, when there are only two windows present, `other-window' is called. If there are more, each window will have its first character highlighted. Pressing that character will switch to that window.
Work-needing packages report for Oct 7, 2016
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 953 (new: 23) Total number of packages offered up for adoption: 148 (new: 0) Total number of packages requested help for: 49 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: atanks (#839966), orphaned today Description: tank-battling game Reverse Depends: atanks atanks-dbg Installations reported by Popcon: 383 bing (#839967), orphaned today Description: Empirical stochastic bandwidth tester Installations reported by Popcon: 436 bookview (#839673), orphaned 3 days ago Description: Tcl/Tk based NDTP(Network Dictionary Transfer Protocol) client Installations reported by Popcon: 11 dvbstream (#839968), orphaned today Description: Broadcast a DVB Transport stream over a LAN Installations reported by Popcon: 231 dvbtune (#839969), orphaned today Description: Simple tuning application for DVB cards Installations reported by Popcon: 439 enscribe (#839652), orphaned 3 days ago Description: convert images into sounds Installations reported by Popcon: 54 hupnp (#839976), orphaned today Reverse Depends: libhupnp-dev libhupnp1 Installations reported by Popcon: 115 iog (#839970), orphaned today Description: network I/O grapher Installations reported by Popcon: 35 ipcheck (#839971), orphaned today Description: Dyndns.org client to register your dynamic IP address Installations reported by Popcon: 122 ivtv-utils (#839975), orphaned today Description: utilities for use with the ivtv kernel driver Installations reported by Popcon: 109 mp3rename (#839972), orphaned today Description: Rename mp3 files based on id3tags Installations reported by Popcon: 745 ncap (#839610), orphaned 4 days ago Description: network capture tool, library and Python bindings Reverse Depends: libncap-dev ncaptool python-ncap Installations reported by Popcon: 81 plum (#839675), orphaned 3 days ago Description: IRC proxy, stationing, logging, and bot program (pirc) Installations reported by Popcon: 19 python-pcs (#839611), orphaned 4 days ago Description: Packet Construction Set for Python Installations reported by Popcon: 8 python-pefile (#839613), orphaned 4 days ago Description: Portable Executable (PE) parsing module for Python Reverse Depends: plaso Installations reported by Popcon: 161 python-pypcap (#839612), orphaned 4 days ago Description: object-oriented Python interface for libpcap Reverse Depends: python-pcs Installations reported by Popcon: 98 smstools (#839973), orphaned today Description: SMS server tools for GSM modems Installations reported by Popcon: 243 tamil-gtk2im (#839663), orphaned 3 days ago Description: Tamil input method for GTK-2 Installations reported by Popcon: 61 twolame (#839974), orphaned today Description: MPEG Audio Layer 2 encoder (command line frontend) Reverse Depends: audacity audiotools darkice gstreamer1.0-plugins-ugly libavcodec-extra57 libavcodec57 libsox-fmt-mp3 libtwolame-dev mencoder twolame (1 more omitted) Installations reported by Popcon: 102525 wayv (#839651), orphaned 3 days ago Description: Experimental hand writing/gesture recognition program Installations reported by Popcon: 17 webkit2pdf (#839741), orphaned 2 days ago Description: export web pages to PDF files or printer Installations reported by Popcon: 149 xipmsg (#839676), orphaned 3 days ago Description: A pop up style message communication software Installations reported by Popcon: 11 yahoo2mbox (#839664), orphaned 3 days ago Description: Retrieve and store Yahoo! Groups messages Installations reported by Popcon: 9 930 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 148 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: athcool (#278442), requested 4363 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 21 awstats (#755797), requested 806 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4091 balsa (#642906), requested 1838 days
Re: Network access during build
On Thu, Oct 6, 2016 at 11:48 PM, Jérémy Lal wrote: > Is there some simple way to check, when using sbuild, that the build does > not access network ? nsntrace could probably be used for this. I think lamby has another method too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
On Thu, Oct 6, 2016 at 9:59 PM, Jochen Sprickerhof wrote: > how are they related to the dpkg-gensymbols? The exported symbols of a library are part of the ABI but the purpose of the two tools is completely different. > Would it make sense to use the symbol files with it or have it as an > alternative to dpkg-gensymbols? I don't think so. > Would it be possible to do that automatically using debhelper? debhelper does not have the old binary packages available and isn't a QA tool anyway. lintian is a QA tool but does not have the old binary packages available. If we are to do this automatically, we are going to need a service especially designed for it, possibly based on snapshot.d.o. > Or if not, maybe download the current deb from the archive and compare > it? You can definitely do that manually and I hope any library maintainers reading this thread will do so. It might be nice to have a wrapper script in devscripts to download the relevant binary package versions, run both tools, generate reports and print any discrepancies. If we had such a tool, it could be added to check-all-the-things. -- bye, pabs https://wiki.debian.org/PaulWise
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
On Thu, Oct 6, 2016 at 10:29 PM, Leopold Palomo-Avellaneda wrote: > Then I would like to ask when we must think that we need a transition for a > the package. If these test shows a binary compatibility of 99%, do we need to > create a need soname bump and initiate a transition? SONAMEs are generally a property of upstream and should generally not be set by Debian, except for setting a Debian-specific SONAME where our patches introduce an ABI change or where upstream does not yet set a SONAME. While we could probably develop a mechanism to check which packages in Debian rely on parts of the ABI with incompatible changes, we can never know which software outside Debian relies on those parts of the ABI so I think we should almost always initiate a transition when we detect incompatible changes. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#839980: ITP: golang-github-hlandau-buildinfo -- Go build information utilities
Package: wnpp Severity: wishlist Owner: Peter Colberg * Package name: golang-github-hlandau-buildinfo Version : 0.0~git20160722.0.b25d4b0 Upstream Author : Hugo Landau * URL : https://github.com/hlandau/buildinfo * License : Expat Programming Lang: Go Description : Go build information utilities This package provides small build information utilities for tracking Go binary version information. Rather than trying to assign a linear version number to a binary, the tag names and version control commit hashes of all dependencies are tracked. This information is embedded into the binary at build time. This package is a prerequisite for acmetool (>= 0.0.58-1).
Bug#839981: ITP: golang-github-hlandau-dexlogconfig -- logging configuration package for Go
Package: wnpp Severity: wishlist Owner: Peter Colberg * Package name: golang-github-hlandau-dexlogconfig Version : 0.0~git20160722.0.055e2e3 Upstream Author : Hugo Landau * URL : https://github.com/hlandau/dexlogconfig * License : Expat Programming Lang: Go Description : logging configuration package for Go This is a policy package to configure the xlog package by the same author. This package is a prerequisite for acmetool (>= 0.0.58-1).
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
On 2016-10-06, Leopold Palomo-Avellaneda wrote: > Then I would like to ask when we must think that we need a transition f= > or a=20 > the package. If these test shows a binary compatibility of 99%, do we n= > eed to=20 > create a need soname bump and initiate a transition?=20 Always use common sense. Always investigate. But if there is a 'red' item in the abi report, likely. /Sune
