Re: Summary of the 2038 BoF at DC17
On Mon, 2017-09-18 at 18:33:12 +0100, Steve McIntyre wrote:
> On Mon, Sep 18, 2017 at 05:46:34PM +0100, Ian Jackson wrote:
> >Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"):
> >> It depends on how/where/why you're embedding 64-bit time,
> >> basically. If you're embedding a time_t (or a struct including a
> >> time_t) in your ABI and want to keep to something similar, it's worth
> >> waiting to see what's going to be standardised then using that.
> >
> >Are you saying that if I am designing an API/ABI now I should write:
> >
> > typedef struct {
> >blah blah;
> >time_t whenever;
> >blah blah;
> > } MyAPIThing;
> >
> >rather than
> >
> > typedef struct {
> >blah blah;
> >uint64_t whenever;
> >blah blah;
> > } MyAPIThing;
> >
> >? Really ?
> >
> >I think that's bad advice.
I have to agree here. I was also suprised by that recommendation in the
initial report.
> Yes, really. You've now hidden that you're storing time data by using
> another data type, which makes things much harder to find if anybody
> else is scanning for time-handling code. And you've made assumptions
> about how new time-handling APIs are likely to look in the near-ish
> future when people have worked everything out and agreed new
> standards. If the new stuff ends up using a different representation
> with 96 or even 128 bits in total, I'd argue that it's cleaner to wait
> for that and not gamble.
While using more semantic types would be nicer, and more searchable,
the reality is that we've got already systems out there with 64-bit
time_t/clock_t (OpenBSD for example). If POSIX (say) standardized on a
new time96_t or similar, code using 64-bit time would still be no worse
off, it would actually still be in a better position compared to 32-bit
time.
In addition, for the same reason that exposing off_t directly as part
of an API is a very bad idea, because you are then requiring the users
to match your build LFS state, or they will break horribly. Doing the
equivalent with time_t, assuming there cannot be a scorched-earth
just-rebuild-the-world approach to transitioning to non 32-bit time,
will be also a bad idea. (We still do not have 100% LFS coverage!)
The alternative is to provide interfaces similar to glibc, for example
one for off_t (32-bit) another for off64_t, etc, which is also horrible.
> >I would do the latter. Even though that means writing library code
> >internally that checks whether the supplied value of `whenever' fits
> >in whatever the system calls a time_t.
>
> Your code, your choice...
Well for public APIs, it's not just "your code", it's code that
affects all its users.
Thanks,
Guillem
Alioth: Concerns about git URLs and groups/teams
Hi! First off, and just to be clear, I think decomissioning Alioth is a good thing given its current state! Thanks for that. One concern is whether we'll be needing to mass switch yet again git repo URLs for the nth time? The nice thing about the current setup is that it's decoupled from Alioth, at least URL-wise. I think it would be nice to preserve that. And the other related concern is that the current candidate (gitlab) seems to suffer from the same flat-namespace disease as github, where all users and orgs/groups/teams are conflated, and the site is user-centric instead of project or team-centered. For something like gitlab.com or github.com that's from ok to passable (even if sometimes very annoying), but for something like Debian, where our user registration is independent of our "forge" this is a problem with collisions waiting to happen, or where we cannot consider using groups/teams freely. :( When it seems like most of our packages are maintained as part of some team even if the team is composed of very few members, because that's a nice way to group related packages. I'd like to note that while gitlab, as well as gitea get this wrong, pagure for example seems to have gotten this right! Thanks, Guillem
Bug#876347: ITP: go-dep -- Go dependency management tool
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: go-dep Version : 0.3.1 Upstream Author : The Go Authors * URL or Web page : https://github.com/golang/dep * License : Go (BSD-3-clause + Patents rights grant) Description : Go dependency management tool dep is a dependency management tool that at this point looks like the most likely candidate to eventually become part of the Golang source distribution. Cheers, -Hilko
Re: Alioth: Concerns about git URLs and groups/teams
On Thu, 21 Sep 2017, Guillem Jover wrote: > Hi! > > First off, and just to be clear, I think decomissioning Alioth is a > good thing given its current state! Thanks for that. > > One concern is whether we'll be needing to mass switch yet again git > repo URLs for the nth time? The nice thing about the current setup is > that it's decoupled from Alioth, at least URL-wise. I think it would > be nice to preserve that. > > And the other related concern is that the current candidate (gitlab) > seems to suffer from the same flat-namespace disease as github, where > all users and orgs/groups/teams are conflated, and the site is > user-centric instead of project or team-centered. For something like > gitlab.com or github.com that's from ok to passable (even if sometimes > very annoying), but for something like Debian, where our user > registration is independent of our "forge" this is a problem with > collisions waiting to happen, or where we cannot consider using > groups/teams freely. :( When it seems like most of our packages are > maintained as part of some team even if the team is composed of > very few members, because that's a nice way to group related packages. > > I'd like to note that while gitlab, as well as gitea get this wrong, > pagure for example seems to have gotten this right! We do plan to provide some solution for the namespace thing with providing an own interface for creating group in defined namespaces. Alex >
Bug#876356: ITP: clonalframeml -- Efficient Inference of Recombination in Whole Bacterial Genomes
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: clonalframeml Version : 1.11 Upstream Author : Xavier Didelot * URL : https://github.com/xavierdidelot/ClonalFrameML * License : GPL, LGPL Programming Lang: C++ Description : Efficient Inference of Recombination in Whole Bacterial Genomes ClonalFrameML is a software package that performs efficient inference of recombination in bacterial genomes. ClonalFrameML was created by Xavier Didelot and Daniel Wilson. ClonalFrameML can be applied to any type of aligned sequence data, but is especially aimed at analysis of whole genome sequences. It is able to compare hundreds of whole genomes in a matter of hours on a standard Desktop computer. There are three main outputs from a run of ClonalFrameML: a phylogeny with branch lengths corrected to account for recombination, an estimation of the key parameters of the recombination process, and a genomic map of where recombination took place for each branch of the phylogeny. . ClonalFrameML is a maximum likelihood implementation of the Bayesian software ClonalFrame which was previously described by Didelot and Falush (2007). The recombination model underpinning ClonalFrameML is exactly the same as for ClonalFrame, but this new implementation is a lot faster, is able to deal with much larger genomic dataset, and does not suffer from MCMC convergence issues Remark: This program is packaged since it is to some extend a successor of clonalframe which might be lost due to the removal of Qt4. It will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/clonalframeml.git
references to software catalogs
Hello, Because of ever-more complicated workflows in computational biology, researchers combine more and more tools within a project and people start getting confused over what (flavour of) tool has been involved in an analysis when exchanging worklows or when skimming through notes of an analysis done a few years back. To help this situation, the old concept of software catalogs and assigning IDs to software has gained some new attention. We have come up with an extension to the debian/upstream/metadata file like Registry: - Name: NameOfCatalog Entry: SoftwareIdentifier and at the moment support SciCrunch RRIDs, OMICtools and bio.tools. These IDs are earmarked to eventually appear on the Debian Med task pages and point to the external source, which in part already point to Debian (like OMICtools) and add additional information helping our users like informing on similar tools or about tools co-cited in scientific publications. This is meant to help our users to craft better workflows more quickly. And it helps our visibility, too. Also for less scientific software it may be of interest, e.g. for our package trackers, to point to catalogs. I just now found https://en.wikipedia.org/wiki/Open_Hub and find to like it. There may be others. What does our community think? There is https://www.openhub.net/p/inkscape and one could add Registry: - Name: Open Hub Entry: inkscape to debian/upstream/metadata to give whoever is interested the opportunity to add a pointer to or from that catalog when talking about that software. I would not place the full URL since those paths are not unlikely to change over time. The immediate concern is obviously yet another overhead that we impose on our developers. But once we have everything in the successor of alioth, I see this to be a very inviting first contribution by our next generation of developers or just some motivated users of ours. So, the overhead should not be too bad for us. Please discuss. Many thanks Steffen
Re: New httpd-fastcgi virtual package
Michael Lustfield writes ("Re: New httpd-fastcgi virtual package"):
> Personally, I always recommend uwsgi over any of the avaialable cgi/fastcgi
> servers, such as php-fpm, ruby-fcgi, python-fcgi, etc. When you have uwsgi
> available, and it's capable of handling all those languages, including legacy
> raw-cgi apps, it seems kinda silly to use anything else. ;)
fcgi has a wide variety of glue code, compared to uwsgi, AFAICT.
For example, there is fcgi<->cgi glue in both directions, which works
moderately well. Also it looks like to use uwsgi you pretty much have
to use their code and buy into their whole application management
framework.
Sometimes that's not what's wanted.
Mind you, I agree that fgci is an unpleasant protocol.
Ian.
Re: pasting license text into debian/copyright
Hi Dominique, On Wed, Sep 20, 2017 at 05:44:03PM +0200, Dominique Dumont wrote: > > I forgot to mention the main side effect: the copyright file is re-organized, > and the dependency list are re-indented. This is not a problem if you already > use cme, but may lead to a big diff if you don't. > > What do you think ? *I* think its fine but I have heard from at least one team member who asked me not to use cme on the packages he is Uploader for since the identation does not fit his aesthetics. > Would such script be useful ? Yes, despite some people might not like some details. Thanks a lot for your work on cme Andreas. -- http://fam-tille.de
Bug#876374: ITP: libdist-zilla-plugin-modulebuildtiny-fallback-perl -- Dist::Zilla plugin that generates a Build.PL with fallback on Module::Build
Package: wnpp Severity: wishlist Owner: Carnë Draug * Package name: libdist-zilla-plugin-modulebuildtiny-fallback-perl Version : 0.025 Upstream Author : Karen Etheridge * URL : https://metacpan.org/release/Dist-Zilla-Plugin-ModuleBuildTiny-Fallback * License : perl 5 Programming Lang: Perl Description : Dist::Zilla plugin that generates a Build.PL with fallback on Module::Build Dist::Zilla::Plugin::ModuleBuildTiny::Fallback is a Dist::Zilla plugin that provides a Build.PL in your distribution that attempts to use Module::Build::Tiny when available, falling back to Module::Build when it is missing and printing a warning about it. . This is useful when your distribution is installing on an older perl (before approximately 5.10.1) with a toolchain that has not been updated, where configure_requires metadata is not understood and respected -- or where Build.PL is being run manually without the user having read and understood the contents of META.yml or META.json.
Re: pasting license text into debian/copyright
On Thursday, 21 September 2017 15:17:06 CEST Andreas Tille wrote: > I* think its fine but I have heard from at least one team member who > asked me not to use cme on the packages he is Uploader for since the > identation does not fit his aesthetics. Note that I wouldn't mind changing the format details of the file generated by cme to follow an agreed upon standard (or recommendation) that would apply to all tools that reformat files (like cme wrap-and-sort dh-make-perl) or create files from scratch (like some dh-make tools) . > > Would such script be useful ? > > Yes, despite some people might not like some details. Great :-) Thanks for the feedback -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Re: Alioth: Concerns about git URLs and groups/teams
FWIW gitlab now supports groups, subgroups and projects + granular permissions per those. Ondřej On Thu 21 Sep 2017, 11:10 Alexander Wirt wrote: > On Thu, 21 Sep 2017, Guillem Jover wrote: > > > Hi! > > > > First off, and just to be clear, I think decomissioning Alioth is a > > good thing given its current state! Thanks for that. > > > > One concern is whether we'll be needing to mass switch yet again git > > repo URLs for the nth time? The nice thing about the current setup is > > that it's decoupled from Alioth, at least URL-wise. I think it would > > be nice to preserve that. > > > > And the other related concern is that the current candidate (gitlab) > > seems to suffer from the same flat-namespace disease as github, where > > all users and orgs/groups/teams are conflated, and the site is > > user-centric instead of project or team-centered. For something like > > gitlab.com or github.com that's from ok to passable (even if sometimes > > very annoying), but for something like Debian, where our user > > registration is independent of our "forge" this is a problem with > > collisions waiting to happen, or where we cannot consider using > > groups/teams freely. :( When it seems like most of our packages are > > maintained as part of some team even if the team is composed of > > very few members, because that's a nice way to group related packages. > > > > I'd like to note that while gitlab, as well as gitea get this wrong, > > pagure for example seems to have gotten this right! > We do plan to provide some solution for the namespace thing with providing > an > own interface for creating group in defined namespaces. > > Alex > > > > > -- Ondřej Surý
Re: pasting license text into debian/copyright
On Wed, 20 Sep 2017 11:31:39 +0200, Dominique Dumont wrote: > On Wednesday, 20 September 2017 11:24:50 CEST gregor herrmann wrote: > > gregor, who also hates reformatting license texts or copying them from > > random places > I can also whip up a script based on cme that would copy the license text > from > a file (or from STDIN), format it and store it in debian/copyright as a > License: paragragh > > The command could look like: > > cme run copy-license Sounds nice. Maybe we could even have "cme run copy-license " which takes the text from a well-know location? On Wed, 20 Sep 2017 17:44:03 +0200, Dominique Dumont wrote: > I forgot to mention the main side effect: the copyright file is re-organized, > and the dependency list are re-indented. This is not a problem if you already > use cme, but may lead to a big diff if you don't. I'm used to cme reformatting files, so personally I don't care about the diff :) [0] Cheers, gregor [0] In one of my wrapper scripts I have cme modify dpkg-control -save git commit -a -m 'Reformat debian/control with cme' -m 'Gbp-Dch: ignore' || true before any commands which actually change the contents of files -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #362: Plasma conduit breach
Re: pasting license text into debian/copyright
Hi Dominique, On Thu, Sep 21, 2017 at 03:38:52PM +0200, Dominique Dumont wrote: > On Thursday, 21 September 2017 15:17:06 CEST Andreas Tille wrote: > > I* think its fine but I have heard from at least one team member who > > asked me not to use cme on the packages he is Uploader for since the > > identation does not fit his aesthetics. > > Note that I wouldn't mind changing the format details of the file generated > by > cme to follow an agreed upon standard (or recommendation) that would apply to > all tools that reformat files (like cme wrap-and-sort dh-make-perl) or create > files from scratch (like some dh-make tools) . I would consider a common agreed upon standard an additional advantage. May be if cme would have the same effect as wrap-and-sort there is at least no disagreement between the users of both tools any more (leaving those who are not happy with either of them :-P ). I do not mind very much about the format as long as it is consistent between all packages I need to touch. > > Yes, despite some people might not like some details. > > Great :-) > > Thanks for the feedback You are welcome Andreas. -- http://fam-tille.de
Bug#876383: ITP: safeeyes -- Protect your eyes from eye strain using this simple and beautiful, yet extensible break reminder
Package: wnpp Severity: wishlist Owner: Antoine Beaupre * Package name: safeeyes Version : 1.2.2 Upstream Author : slgobin...@gmail.com * URL : http://slgobinath.github.io/SafeEyes/ * License : GPL-3 Programming Lang: Python Description : Protect your eyes from asthenopia Protect your eyes from eye strain using this simple and beautiful, yet extensible break reminder. -- This program is similar to Workrave, but written in Python and without the questionable 3D art. It is also simpler: it doesn't track keystrokes and is more easily extensible. I've been a happy user for a few weeks now - it's really nice that the popup is a fullscreen black thing instead of a small popup: it means you are not distracted by whatever you're doing. I'm open to co-maintainership on this or would gladly let someone else take it if people are interested.
Re: [Alioth-staff-replacement] Alioth: Concerns about git URLs and groups/teams
On Thu, 21 Sep 2017, Ondřej Surý wrote: > FWIW gitlab now supports groups, subgroups and projects + granular > permissions per those. Jupp, we will do teams as subgroups in a defined namespace with admin permissions to the team admin. Alex
Bug#876405: ITP: node-rollup-plugin-buble -- rollup plugin
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-rollup-plugin-buble Version : 0.15.0 Upstream Author : Rich Harris * URL : https://gitlab.com/Rich-Harris/rollup-plugin-node-buble * License : Expat Programming Lang: JavaScript Description : Rollup plugin to convert ES2015 to more common javascript using buble This plugin for rollup will convert javascript using the too-recent ES2015 standard to older and more common javascript variants, using the buble transpiler. I need this package because I want rollup in Debian ; and I want rollup in Debian because I already have a few node-* packages which I can barely maintain properly without it. The plan is to maintain it within the Debian Javascript Maintainers team. Cheers, Snark on #debian-js
Bug#876406: ITP: python-stestr -- test runner runner similar to testrepository
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-stestr Version : 1.0.0 Upstream Author : Matthew Treinish * URL : https://github.com/mtreinish/stestr * License : Apache-2.0 Programming Lang: Python Description : test runner runner similar to testrepository Stestr stands for Slim/Super Test Repository. It is a fork of the testrepository that concentrates on being a dedicated test runner for python projects. The generic abstraction layers which enabled testr to work with any subunit emitting runner are gone. Stestr hard codes python-subunit-isms into how it works. The code base is also designed to try and be explicit, and to provide a python api that is documented and has examples. . While stestr was originally forked from testrepository it is not 100% backwards compatible with testrepository. At a high level the basic concepts of operation are shared between the 2 projects but the actual usage between the 2 is not exactly the same. This package is needed by OpenStack Pike.
Bug#876412: ITP: python-subunit2sql -- subunit file/stream to DB
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-subunit2sql Version : 1.8.0 Upstream Author : Matthew Treinish * URL : https://github.com/openstack-infra/subunit2sql * License : Apache-2.0 Programming Lang: Python Description : subunit file/stream to DB subunit2SQL is a tool for storing test results data in a SQL database. Like it's name implies it was originally designed around converting subunit streams to data in a SQL database and the packaged utilities assume a subunit stream as the input format. However, the data model used for the DB does not preclude using any test result format. Additionally the analysis tooling built on top of a database is data format agnostic. However if you choose to use a different result format as an input for the database additional tooling using the DB api would need to be created to parse a different test result output format. It's also worth pointing out that subunit has several language library bindings available. So as a user you could create a small filter to convert a different format to subunit. Creating a filter should be fairly easy and then you don't have to worry about writing a tool like :ref:`subunit2sql` to use a different format. . For multiple distributed test runs that are generating subunit output it is useful to store the results in a unified repository. This is the motivation for the testrepository project which does a good job for centralizing the results from multiple test runs. . However, imagine something like the OpenStack CI system where the same basic test suite is normally run several hundreds of times a day. To provide useful introspection on the data from those runs and to build trends over time the test results need to be stored in a format that allows for easy querying. Using a SQL database makes a lot of sense for doing this, which was the original motivation for the project. . At a high level subunit2SQL uses alembic migrations to setup a DB schema that can then be used by the subunit2sql tool to parse subunit streams and populate the DB. Then there are tools for interacting with the stored data in the subunit2sql-graph command as well as the sql2subunit command to create a subunit stream from data in the database. Additionally, subunit2sql provides a Python DB API that can be used to query information from the stored data to build other tooling. This is needed for OpenStack Pike.
Work-needing packages report for Sep 22, 2017
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: 1121 (new: 8) Total number of packages offered up for adoption: 153 (new: 1) Total number of packages requested help for: 44 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bandwidthd (#876073), orphaned 3 days ago Description: Tracks usage of TCP/IP and builds html files with graphs Installations reported by Popcon: 218 Bug Report URL: http://bugs.debian.org/876073 bash-completion (#876095), orphaned 3 days ago Description: programmable completion for the bash shell Reverse Depends: parl-desktop Installations reported by Popcon: 184003 Bug Report URL: http://bugs.debian.org/876095 dnsproxy (#876201), orphaned 2 days ago Description: proxy for DNS queries Installations reported by Popcon: 10 Bug Report URL: http://bugs.debian.org/876201 pirl (#876371), orphaned today Description: PIRL Java Packages Reverse Depends: pirl-image-tools Installations reported by Popcon: 10 Bug Report URL: http://bugs.debian.org/876371 vimoutliner (#876202), orphaned 2 days ago Description: script for building an outline editor on top of Vim Installations reported by Popcon: 341 Bug Report URL: http://bugs.debian.org/876202 xdg-utils (#876401), orphaned today Description: desktop integration utilities from freedesktop.org Reverse Depends: 0install-core amtterm anarchism arb asymptote bauble calibre chromium-common cinnamon-common cinnamon-control-center (44 more omitted) Installations reported by Popcon: 114460 Bug Report URL: http://bugs.debian.org/876401 xml2 (#876203), orphaned 2 days ago Description: Convert between XML, HTML, CSV and a line-oriented format Reverse Depends: ceph-test dh-php Installations reported by Popcon: 1472 Bug Report URL: http://bugs.debian.org/876203 xsddiagram (#876304), orphaned yesterday Description: XML Schema Definition (XSD) diagram viewer Installations reported by Popcon: 86 Bug Report URL: http://bugs.debian.org/876304 1113 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: imlib2 (#876256), offered yesterday Description: image loading, rendering, saving library Reverse Depends: amora-applet amora-cli caca-utils conky-all eterm feh fluxbox gambas3-gb-image-imlib giblib-dev giblib1 (31 more omitted) Installations reported by Popcon: 29378 Bug Report URL: http://bugs.debian.org/876256 152 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 295 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 980 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2188 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 682 Bug Report URL: http://bugs.debian.org/642906 cargo (#860116), requested 163 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 479 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3029 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (68 more omitted) Installations reported by Popcon: 179227 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 729 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (120 more omitted) Installations reported by Popcon: 199249 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 433 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 647
