RE : Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
Thank you for your feedback. First of all let me recall the actual URL for upstream bash_unit since I misspelled it in the bug report: https://github.com/pgrange/bash_unit Regarding the differences with shunit2, there are many differences. First, it is not that easy to find shunit2 reference documentation (you will have to type "shunit2 documentation" in some search engine, "shunit2" will not give you that) and when you find that, it is not clear how up-to-date and alive it is. Second, shunit2 does not work as a tool you run to launch your tests. You have to write your own script that will have to source shunit2. Third, shunit2 will not help you find your code under test. If you are writing tests for some script in a separate file, how do you find that script under test from your tests, wherever the tests are run from? These where some of the reasons why a new tool has been been started instead of using an existing one, like shunit2. bash_unit provides an extensive reference documentation with detailed examples for every assertion function and getting started sample code. You do not have to source anything in your test, you run your test with a command like: bash_unit tests/test_* You might even filter the tests you want to run with a pattern. For instance to run only tests which name contains "access": bash_unit -p access tests/test_* bash_unit ensures you that the current working directory in your running test is the directory containing your test file. That allows you to easily reference your script under test with relative path. bash_unit assertion functions try to be more "shell" than the ones proposed by shunit2 but I let people compare for themselves. In case of failure, bash_unit will display the stack trace with source file and line number indications to locate the problem. On another side, bash_unit provides you the fake function that will help you define a context of execution for your code under test. You can find more details in bash_unit documentation here: https://github.com/pgrange/bash_unit Regarding the fact that bash_unit only supports bash, this was a design decision. I personally stumbled upon too many shell scripts that started with: #!/bin/sh When they where actually using bash specific instructions or constructs in the code. That was a motivation to be really clear and specific about the contexts where this testing tool where supposed to work. This testing tool supports bash and tries to support it well. Concerning my motivations to package it for Debian, as stated in the bug report:I use this software in a daily basis on debian systems. A small community is emerging, also using it and asking for easier ways to install it on Debian systems. Regards, Pascal. Message d'origine De : Jonathan Dowland Date : 04/10/2016 12:02 (GMT+01:00) À : Pascal Grange , 839...@bugs.debian.org Cc : debian-devel@lists.debian.org Objet : Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals On Fri, Sep 30, 2016 at 08:53:05AM +0200, Pascal Grange wrote: > Package: wnpp > Severity: wishlist > Owner: Pascal Grange > > * Package name : bash-unit > Version : 1.0.2 > Upstream Author : Pascal Grange > * URL : https://github.com/pgrange/bash-unit > * License : GPL > Programming Lang: Bash > Description : bash unit testing enterprise edition framework for >professionals > > bash-unit is a unit testing software for bash. My immediate thought was "how does this differ to shunit2", which is already packaged. You mention this later: > I am aware of one alternative Debian package providing similar > functionaltities: shunit2. bash_unit and shunit2 propose > different testing methods and workflow. It would be nice to expand on this a little, to help make the case that we need another shell unit testing framework (especially since shunit2 works for other shells too!) > It has been reported that people using bash_unit won't use shunit2 to write > their tests but I may not be objective about that ;) bash_unit officially > supports only bash where shunit2 tries to support more shells. This package > would improve bash unit testing support for Debian. > > I am the main developer of bash-unit. Objectivity is very important here IMHO. What are your motivations for packaging it in Debian? Is it a build-dependency for something else, or are you looking for a "signal boost" to raise the profile of bash-unit? -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Bug#839826: ITP: neutron-dynamic-routing -- OpenStack Neutron Dynamic Routing
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: neutron-dynamic-routing Version : 9.0.0~rc2 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/neutron-dynamic-routing * License : Apache-2.0 Programming Lang: Python Description : OpenStack Neutron Dynamic Routing Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . Neutron dynamic routing enables advertisement of self-service (private) network prefixes to physical network devices that support dynamic routing protocols such as routers, thus removing the conventional dependency on static routes. . It advertises three classes of routes: * Host routes for floating IP addresses hosted on non-DVR routers, the nexthop is the centralized router. * Host routes for floating IP addresses hosted on DVR routers, the nexthop is the appropriate compute node. * Prefix routes for directly routable tenant networks with address scopes, the nexthop is the centralized router, the same for DVR and CVR. . Neutron dynamic routing consists of service plug-in and agent. The service plug-in implements the Networking service extension and the agent manages dynamic routing protocol peering sessions. The plug-in communicates with the agent through RPC.
Bug#839744: ITP: PyMOC -- Python Multi-Order Coverage map library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 package: wnpp Owner: Paul Sladen Severity: Wishlist * Package Name: pymoc * Version: 0.4.1 * Upstream Author: Graham Bell * URL: https://github.com/grahambell/pymoc * Programming Language: Python * License: GPLv3+ * Description: Python Multi-Order Coverage map library PyMOC manipulates a stack of Multi-Order Coverage maps for exchanging images within the Virtual Observatory (VO). These MOCs can be encoded as FITS, JSON or ASCII formats. Multiple MOCs can be stacked using union, intersection and subtraction the result converted and saved in alternative formats. A 'pymoctool' command-line tool that accesses the library is included. MOCs can be viewed and rendered by other tools, including Aladin. Debian Packaging can be found at: https://anonscm.debian.org/git/debian-astro/packages/pymoc.git -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFX87Cbc444tukM+iQRAvRYAKCCUIT2UVMZ44YXLj/O26jdVjoXLwCfbEHQ 3aOOXCusDJO7JQStnkxj17g= =B4mj -END PGP SIGNATURE-
Stretch freeze and the possible future upload of MATE 1.18
Hi all, I'm one of the upstream developers of MATE desktop environment. Current version, 1.16, just reached Unstable and should make it into Testing soon. However, 1.16 has some outstanding issues (mostly GTK+3 related ones, but there are also dependencies on deprecated packages) which we'll only be able to handle during 1.18 development phase, due to amount of new code needed for that and time needed for testing. So we're interested in getting the future 1.18 release into Stretch before it's released as the next Stable. Now we're only preparing to start 1.18 development, and we don't know which date would be the deadline for 1.18 release in order for it to make it into Testing. I've looked at three freezes listed at https://wiki.debian.org/DebianStretch#Before_the_release and I have to admit I don't understand them fully. Which freeze would be the one after which the new upstream MATE release won't be accepted into Testing? Here's the tentative list of possible changes in 1.18 in regards to package dependencies: - src:caja - drop B-D:libunique-3.0-dev - src:eom - add B-D:libpeas-dev - src:libmateweather - drop this package completely - src:mate-applets - drop B-D:libmateweather-dev, add B-D:libgweather-3-dev - src:mate-control-center - drop B-D:libunique-3.0-dev - src:mate-media - drop B-D:libunique-3.0-dev - src:mate-panel - drop B-D:libmateweather-dev, add B-D:libgweather-3-dev - src:mate-system-monitor - add D:policykit-1 - src:pluma - add B-D:libpeas-dev Would something of that count as a transition that should be completed before the transition freeze on 5th Nov? Or would it be allowed to upload these new packages until soft freeze or even full freeze? (Not sure if I should've posted this in debian-release list instead, I wasn't sure where to discuss this topic.)
A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
Hello, 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. The tool does the following: 1. Extracts input packages 2. Searches for *.debug, *.so and header files 3. Creates ABI dumps of all found shared objects 4. Filters out private part of the ABI using info from header files 5. Matches shared objects in old and new packages 6. Compares ABI dumps of corresponding objects 7. Creates backward binary compatibility (BC) report 8. Creates backward source compatibility (SC) report The tool is intended for Linux maintainers who are interested in ensuring backward compatibility, i.e. allow old applications to run (BC) or to be recompiled (SC) with newer versions of Deb packages. Home page: https://github.com/lvc/pkg-abidiff Usage: pkg-abidiff -old P1 P1-DEBUG P1-DEV -new P2 P2-DEBUG P2-DEV P1 — Deb package to analyze (with *.so object files) P1-DEBUG — corresponding debug-info package (*.debug files with DWARF info) P1-DEV — corresponding development package (with header files) Report example for libssh 0.5.4 vs 0.6.3: https://abi-laboratory.pro/examples/compat_report/amd64/libssh-4/0.5.4-1+deb7u3/0.6.3-4+deb8u2/ Enjoy!
IBM MQ users lists
Hi, A Quick Follow up to you that if you are interested in IBM MQ users list which can help you to grow up your business campaigns? We have other organization users like: SQL Server Integration Services, webMethods, Talend Data Integration, Informatica PowerCenter, MuleSoft ESB, IBM InfoSphere, Inaport, Informatica Integration, Microsoft SQL Server Management, SAP Data Services, Atlas, TIBCO ActiveMatrix BusinessWorks, Oracle GoldenGate, Adeptia Integration, COZYROC, Neuron ESB, MetaDex and many more. Specialties: Cloud,Cognitive,Security,Research,Watson,Analytics,Consulting,Commerce,Exper ience Design, Technology support, Industry solutions, Systems services, IT iinfrastructure,Resiliency services, Financing and so on. Data Fields - Name, Title, Email, Company Name, and Company Details like, Physical Address, Web Address, Revenue Size, Employee Size and industry. Please let me know your thoughts and your criteria we will provide you with more information. And if you aren't the right person to discuss this mail you can freely forward this mail to right person in your organization. Thanks, Cheryl Walker Marketing Analytics
Re: RE : Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
Pascal Grange schreef op 05-10-2016 9:32: I use this software in a daily basis on debian systems. A small community is emerging, also using it and asking for easier ways to install it on Debian systems. Sounds like good reasons, Regarding the fact that bash_unit only supports bash, this was a design decision. I personally stumbled upon too many shell scripts that started with: #!/bin/sh When they where actually using bash specific instructions or constructs in the code. That was a motivation to be really clear and specific about the contexts where this testing tool where supposed to work. This testing tool supports bash and tries to support it well. But do take note that on Debian systems there is also an interest to be Dash compatible. At least with me it is. Particularly scripts that need speed can see great improvements sometimes under Dash. Which was also the reason for it (hence "dash" a fitting name ;-)). Bash will run differently when invoked as Sh, by the way. I applaud your efforts. You say the main difference is that shunit2 requires you to source the file and then run the test as a regular shell script, but that your tool depends on the calling tool to source those things? To compare: jUnit requires you to source stuff AND it is run by the tool. But it seems to me that for Bash and other shell scripts the infrastructure to know where to find source scripts is rather missing and sourcing stuff from the right location is always a bit of a pain so I can only see that as a great benefit currently to me at least. However I do not know about shunit2 and I know very little about Debian policy and should not be saying too much here, but I would personally be inclined to ask foremost if you would have any interest in extending the tool to Dash. Bash scripting is a lot easier but for production systems sometimes there is a reason to change that "fast" code to compatible code. We have the "checkbashisms" script from devscripts and it would not be unkind if the best featured unit testing framework, supposedly, would be a bit in line with that -- I suppose people are also coming from that. Debian does not support any other tool apart from Bash, Dash and Posh, I guess, as shellscripting languages for the system, so it would not be about support C-shells or even Zsh, it would probably, however 'selfishly' be most important for "us here" if the thing supported Dash. Just saying that that is something I would personally ask and I could wonder if you could comment on that. (Also for me personally, of course). Of course the name has "bash" in it but that is something the people at #bash would like ;-). If Bash came to be a bit more of an accepted thing. Regards.
Bug#839836: ITP: dasher -- A graphical predictive text input system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: wnpp Severity: wishlist Owner: Thibaut Paumard * Package name: dasher Version : 5.0 Upstream Author : The Dasher Project * URL : http://www.inference.phy.cam.ac.uk/dasher/ * License : GPL Programming Lang: C++ Description : A graphical predictive text input system Dasher is an information-efficient text-entry interface, driven by natural continuous pointing gestures. Dasher is a competitive text-entry system wherever a full-size keyboard cannot be used - for example, * on a palmtop computer * on a wearable computer * when operating a computer one-handed, by joystick, touchscreen, trackball, or mouse * when operating a computer with zero hands (i.e., by head-mouse or by eyetracker). The eyetracking version of Dasher allows an experienced user to write text as fast as normal handwriting - 25 words per minute; using a mouse, experienced users can write at 39 words per minute. Dasher uses a more advanced prediction algorithm than the T9(tm) system often used in mobile phones, making it sensitive to surrounding context. This package has recently been removed from Debian for the previous maintainer did not have enough time to foster it. However this package is a necessity for certain users with disabilities. I intend on maintaining it presumably within the debian-accessibility team. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJX9SeSAAoJEJOUU0jg3ChApYYP/iPeaiFe3GCG/WrrE9kI2L+E EG2uLv2HorwV+Bet23jt4kYAaa4eX6JFTJv3g0D67hVZyN4c8ol+JwNMpCjk6uP8 Aer/hrVCYCLWpRYwqAOVAOxC2796syBl2/JgjGMwWdUYUR/8Ylk3dPa+aJKui2cN ItxaY1rE3hEePT4CRkTI4EaFNvItYS4O4A7zG8ssA0iO42aBnWsKruWLksdnXmH0 9E3VJvc7EMh6uIQoq5N2u3tpOet7qqMR+XdpLpZYIJxHUqqavbQqfTcSyosvxoB3 8lK91PEZNEjsVtt9pP95D3dWKgSnXRhzjLG04RWzLyaa5ABLtV5oiFIAjrHuJ3Xb I2fvrMHweVgoqlwQrZ48sQ7V2tvP7NcbC0Q55U4boZOm0cjNwuOTUYuZo/9CXTp+ TnIhKLOgdVzBMwX/3r5VkmXZh6HPQjjvuQc/hH2xdJjflLbn3Mr5kCbfNnvE+KjW 31rCXcPZQ4BQad0ByfBZbXFL5gVv0ZPSwf6VB6aMzxAVYi30zmb//XbK1kv4Hlhf Eg6M/dLwxdyTZ/xWh9UPYY//WqQckXA/u9U1v1ob6UG/olNAU0jqmqVHbnB3FVs5 uTEfbC2g6bhb9koKXLWO64Ggsem/9avLKnJ8RoPMkRYIUnlOHddu+968TG8n2OrR NxR0YczKoBIiMppZ+Gwb =sngp -END PGP SIGNATURE-
Re: RE : Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals
On Wed, Oct 05, 2016 at 05:35:21PM +0200, Bart Schouten wrote:
> Pascal Grange schreef op 05-10-2016 9:32:
> >Regarding the fact that bash_unit only supports bash, this was a
> >design decision. I personally stumbled upon too many shell scripts
> >that started with:
> >
> >#!/bin/sh
> >
> >When they where actually using bash specific instructions or
> >constructs in the code.
Which doesn't work on Debian other than in non-standard configurations.
> >This testing tool supports bash and tries to support it well.
>
> But do take note that on Debian systems there is also an interest to be Dash
> compatible. At least with me it is.
>
> Particularly scripts that need speed can see great improvements sometimes
> under Dash.
Which is a reason to do so by default:
[~]$ grep '^#! */bin/bash' {/usr,}/{s,}bin/*|wc -l
72
[~]$ grep '^#! */bin/sh' {/usr,}/{s,}bin/*|wc -l
317
[~]$ grep '^#! */bin/dash' {/usr,}/{s,}bin/*|wc -l
0
(Lintian considers #!/bin/dash an error.)
While bash does have a lot of extensions, I for one never felt like learning
them and thus still write portable shell scripts (even if by laziness rather
than a conscious decision). And really, the only times I feel angry enough
to change to #!/bin/bash is dash's lack of support of \e in printf[1].
Thus, by the above statistics, shunit2 is a lot more useful.
Meow!
[1]. All scripting languages I've checked support \e, so do all free C
compilers, and all shells other than dash -- even "Posixly correct" posh.
--
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
Hello, Michael Biebl, on Wed 05 Oct 2016 14:54:19 +0200, wrote: > I'm not sure why you think there was fighing going on. > Mario was/is part of the pkg-gnome team and had SVN commit rights for a > very long time. > > It's not like he couldn't have just uploaded the package instead. So I > think it's a bit disingenious to say that he had no control over the > package. Why he chose not to get involved is his decision ultimately. > But implying that he was somehow hindered and there was fighting going > on is misleading and unfair. > > The pkg-gnome team actually tried in the past and still tries to get > people involved who care about a11y and welcome any contributions in > that regard. Well, Adrian Bunk, on Tue 04 Oct 2016 23:55:17 +0300, wrote: > Andreas claiming "there's noone willing to commit to actually taking > care of the package" in the removal request is also quite at odds with > him being completely silent on my suggestion to file a WNPP bug. I do read the "work-needing" mails, so I would have seen it. There was no single mail on the debian-accessibility list about dasher. I didn't know it got removed from testing or even that help was requested. Had I known it, I would have moved for sure, or at least post a request for help on debian-accessibility. So it's not active fighting indeed, but from the point of view of a11y people it *is* definitely fighting to have to realize that something again has fallen down, and have to spend energy into putting it up again. The case of a11y packages is very particular: their popularity is irrelevant, since some people simply *need* them to be able to do any kind of work with Debian. Just dropping the package from Debian, saying that people who need it will install it by themselves, actually means just killing the package: how will the user know about it? How will he manage to install it not through the package manager while he is already struggling with using the computer? 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? Anyway, thanks a lot Thibaut for proposing to take maintenance of the package. You're welcome in the debian-accessibility team ;) Samuel
Re: Stretch freeze and the possible future upload of MATE 1.18
Vlad Orlov: > Hi all, > Hi :), I am moving this to debian-release with the MATE packaging team as CC. (Also BCC'ed to debian-devel@lists.debian.org) > I'm one of the upstream developers of MATE desktop environment. Current > version, 1.16, just reached Unstable and should make it into Testing soon. > However, 1.16 has some outstanding issues (mostly GTK+3 related ones, but > there are also dependencies on deprecated packages) which we'll only be able > to handle during 1.18 development phase, due to amount of new code needed for > that and time needed for testing. > Ok. :) > So we're interested in getting the future 1.18 release into Stretch before > it's released as the next Stable. Now we're only preparing to start 1.18 > development, and we don't know which date would be the deadline for 1.18 > release in order for it to make it into Testing. I've looked at three freezes > listed at https://wiki.debian.org/DebianStretch#Before_the_release and I have > to admit I don't understand them fully. Which freeze would be the one after > which the new upstream MATE release won't be accepted into Testing? > It depends on what the MATE release includes. If it involves a transition (e.g. ABI / API bumps), then you are looking at 5th of November as deadline. Otherwise, I strongly recommend using early/mid-December as the latest deadline upstream. That way the MATE packaging has 2-3 weeks to get it uploaded plus another 2-3 to fix any bugs without any extra hassle. I assume here that there is no need for new packages (based on your input below). *Deadlines are for having things in Debian testing* Please remember to coordinate with the MATE packaging team so they have time to upload it to unstable and let it migrate. > Here's the tentative list of possible changes in 1.18 in regards to package > dependencies: > > [...] > > - src:libmateweather > - drop this package completely > Removals can occur after the 5th of Feb. But please have all reverse dependencies (if any) fixed before then. > [...] > > Would something of that count as a transition that should be completed before > the transition freeze on 5th Nov? Or would it be allowed to upload these new > packages until soft freeze or even full freeze? > > [...] That depends if these changes affect the API/ABI of the MATE packages (in an incompatible way). I cannot tell that from just looking at changed dependency lists as I don't know if those changes will be exposed to reverse dependencies. Thanks, ~Niels
Bug#839877: ITP: uftrace -- Traces and analyzes execution of programs written in C/C++
Package: wnpp Severity: wishlist Owner: paul cannon * Package name: uftrace Version : 0.6.0.20161004-1 Upstream Author : Namhyung Kim * URL : https://github.com/namhyung/uftrace/ * License : GPL Programming Lang: C Description : Traces and analyzes execution of programs written in C/C++ The uftrace tool is intended for tracing and analyzing the execution of programs written in C or C++. It was heavily inspired by the ftrace framework of the Linux kernel (especially the function graph tracer) and supports userspace programs. It supports various kinds of commands and filters to help analysis of the program's execution and performance. It traces each function in the executable and shows time durations. It can also trace external library calls - but only entry and exit are supported, and internal function calls within the library cannot be traced unless the library itself was built with profiling enabled. It can show detailed execution flow at function level, and report which function has the highest overhead. It also shows various information related to the execution environment. You can setup filters to exclude or include specific functions when tracing. In addition, function arguments and return values can be saved and shown later. The uftrace tool supports multi-process and/or multi-threaded applications. It can also trace kernel functions as well, with root privileges and if the system enables the function graph tracer in the kernel (CONFIG_FUNCTION_GRAPH_TRACER=y). - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? Cachegrind provides similar functionality, but only provides information in aggregate, whereas uftrace will collect the entire stack and provide pretty output for visualization. It is more of a "tracer" than a sample-and-aggregate tool. Intel has a profiler called VTune(tm) Amplifier which also fills a related niche, but it is not free software. - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? Should be simple enough to self-maintain. No sponsor needed. I'm on LowThresholdNmu.
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
On Thu, Oct 6, 2016 at 12:53 AM, Samuel Thibault wrote: > I do read the "work-needing" mails, so I would have seen it. There was > no single mail on the debian-accessibility list about dasher. I didn't > know it got removed from testing or even that help was requested. Had I > known it, I would have moved for sure, or at least post a request for > help on debian-accessibility. > > So it's not active fighting indeed, but from the point of view of a11y > people it *is* definitely fighting to have to realize that something > again has fallen down, and have to spend energy into putting it up > again. > > The case of a11y packages is very particular: their popularity is > irrelevant, since some people simply *need* them to be able to do any > kind of work with Debian. Just dropping the package from Debian, saying > that people who need it will install it by themselves, actually means > just killing the package: how will the user know about it? How will he > manage to install it not through the package manager while he is already > struggling with using the computer? > > 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; people doing Debian package removal rarely do any due diligence work before filing removal bugs. Personally, at minimum I would like to see removalists contacting PTS/tracker/DDPO subscribers, upstream, any related Debian teams and any related Debian derivatives. -- bye, pabs https://wiki.debian.org/PaulWise
ITP: gogs -- self hosted git service
retitle 792101 ITP: gogs -- A painless self-hosted Git service. owner 792101 ! thanks Updated Details: * Package name: gogs Version : 0.9.97 Upstream Author : The Gogs Authors * URL : https://github.com/gogits/gogs * License : MIT Homepage: https://gogs.io/ Programming Lang: Golang Description : A painless self-hosted Git service. . Gogs is a self-hosted service aiming to provide a similar set of features to gitlab and github while remaining lightweight and easy. I intend to package gogs. I have reached out to the gogs developers to make them aware of this intention and have offered to discuss what that may mean for them. Although upstream makes frequent releases, these seem to rarely have security fixes so I don't anticipate any significant concerns backporting security issues. (feel free to double check me!) -- Michael Lustfield pgpQ5tJiDtmWa.pgp Description: OpenPGP digital signature
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
On Thursday, October 06, 2016 11:40:12 AM Paul Wise wrote: > On Thu, Oct 6, 2016 at 12:53 AM, Samuel Thibault wrote: > > I do read the "work-needing" mails, so I would have seen it. There was > > no single mail on the debian-accessibility list about dasher. I didn't > > know it got removed from testing or even that help was requested. Had I > > known it, I would have moved for sure, or at least post a request for > > help on debian-accessibility. > > > > So it's not active fighting indeed, but from the point of view of a11y > > people it *is* definitely fighting to have to realize that something > > again has fallen down, and have to spend energy into putting it up > > again. > > > > The case of a11y packages is very particular: their popularity is > > irrelevant, since some people simply *need* them to be able to do any > > kind of work with Debian. Just dropping the package from Debian, saying > > that people who need it will install it by themselves, actually means > > just killing the package: how will the user know about it? How will he > > manage to install it not through the package manager while he is already > > struggling with using the computer? > > > > 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; people doing Debian package removal rarely do any due > diligence work before filing removal bugs. Personally, at minimum I > would like to see removalists contacting PTS/tracker/DDPO subscribers, > upstream, any related Debian teams and any related Debian derivatives. 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). Scott K
Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages
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
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
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. Samuel
Re: Bug#835533: dasher: Please package Dasher 5.0 beta
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. Scott K
