Re: Epoch version for google-authenticator
On Sunday, March 1, 2020 12:06:13 AM EST SZ Lin (林上智) wrote: > Hi all, > > I'm working on fixing bugs (including RC) on google-authenticator[1] which > name should be "google-authenticator-libpam" instead. > > [1] https://packages.debian.org/source/sid/google-authenticator > [2] https://github.com/google/google-authenticator-libpam > > I intend to import the new upstream release, but the current upstream > version changed the versioning scheme and thus epoch is needed to avoid the > latest version lower than the previous one, as shown below. > > = > Previous version: 20170702-2 > Proposed version: 1:1.08-1 > = > > I've contacted the package maintainer in January but got no response so far. > So I plan to upload the package via the NMU process. > > Any feedback is welcome. I'm only commenting about the epoch, since I don't know enough about the situation to have an opinion on if doing this via NMU is appropriate. Since you say the package is incorrectly named, would it make more sense to rename the package now? Then you wouldn't need an epoch at all. Scott K signature.asc Description: This is a digitally signed message part.
Epoch version for google-authenticator
Hi all, I'm working on fixing bugs (including RC) on google-authenticator[1] which name should be "google-authenticator-libpam" instead. [1] https://packages.debian.org/source/sid/google-authenticator [2] https://github.com/google/google-authenticator-libpam I intend to import the new upstream release, but the current upstream version changed the versioning scheme and thus epoch is needed to avoid the latest version lower than the previous one, as shown below. = Previous version: 20170702-2 Proposed version: 1:1.08-1 = I've contacted the package maintainer in January but got no response so far. So I plan to upload the package via the NMU process. Any feedback is welcome. SZ signature.asc Description: PGP signature
Re: debian/*.symbols files for C++ libraries
On Sat, Feb 29, 2020 at 4:02 PM Alf Gaida wrote: > it's easy to see that it's a simple wrapper around c++filt. Simple wrappers around c++filt should not be needed, because dpkg-gensymbols(1) supports converting plain C++ symbols in the source package symbols files into the C++ mangled form when generating the symbols files stored in binary packages. https://manpages.debian.org/buster/dpkg-dev/dpkg-gensymbols.1.en.html#Using_symbol_patterns -- bye, pabs https://wiki.debian.org/PaulWise
Bug#952823: ITP: jgrep -- Compare a list of json documents to a simple logical language and returns matches as output
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: jgrep Version : 1.5.2 Upstream Author : Pieter Loubser , Dominic Cleal , R.I. Pienaar * URL : https://github.com/ploubser/JSON-Grep * License : Apache-2.0 Programming Lang: Ruby Description : Compare a list of json documents to a simple logical language and returns matches as output JGrep is a command line tool and API for parsing JSON documents based on logical expressions. It returns a JSON datastructure that contains all of the matches from the original JSON document. Used as a library, you can filter results in a similar fashion from within your Ruby code. This tool is very similar in functionality to jq, but uses a matching syntax that is a lot simpler. This tool/library can be very useful on its own either directly on the command line or as a tool for building complex programs that need to filter JSON. It's also used as a dependency by facterdb, which itself is required for puppet-development-kit. I plan to maintain this package from within the ruby team. I will ask for sponsorship from the team.
Bug#952819: ITP: facterdb -- Database of facts from many Facter versions on many Operating Systems
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: facterdb Version : 1.2.0 Upstream Author : Mickaël Canévet * URL : https://github.com/camptocamp/facterdb * License : Apache-2.0 Programming Lang: Ruby Description : Database of facts from many Facter versions on many Operating Systems The facterdb command can lookup its database with a set of versions of Facter and a set of Operating System distributions and versions and output the list of facts corresponding to those to the terminal. The output is formatted in JSON so it can be parsed by other scripts and programs. When used as a library, the same lookups can be done in a programmatic way. This means that you can use the facts in any Ruby program. Having access to lists of facts that mimic different setups is useful for running tests and making sure that features for those different setups are doing what's expected. This command and library is generally useful for Puppet module development and creating CI environments for running module unit tests. It's also used by the puppet-development-kit, so it is a dependency for this tool. I plan on maintaining this package from within the ruby team. I will ask for sponsorship from the team.
Bug#952816: ITP: metadata-json-lint -- Utility to verify Puppet metadata.json files
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: metadata-json-lint Version : 2.2.0 Upstream Author : Vox Pupuli * URL : https://github.com/voxpupuli/metadata-json-lint * License : Apache-2.0 Programming Lang: Ruby Description : Utility to verify Puppet metadata.json files The metadata-json-lint tool validates and lints metadata.json files in Puppet modules against style guidelines from the Puppet Forge module metadata recommendations. metadata.json files are, as implied by the extension in the name, using a JSON syntax but a specific schema is expected to be used to format information in the data structure. They are helpful for specifying dependencies to Puppet modules and for making license and other such metadata parseable by a machine. This file is expected to be present when a module is published to the Puppet forge. This package is generally useful for Puppet module developers. It is also a dependency of puppet-development-kit, since it uses it directly to run verifications on modules. I plan to maintain this package within the ruby team and will ask for sponsorship from the team.
Re: janitor.debian.net & Standards-Version
Hello Jelmer,
I'm sorry for not replying sooner.
On Wed 04 Dec 2019 at 04:26PM +00, Jelmer Vernooij wrote:
> Thanks for the considerate e-mail; I share your concern that simply
> updating Standards-Version renders it meaningless, and should be
> avoided. I took measures to try to prevent that, and I'm interested to
> hear whether you think those are sufficient.
>
> The bot will only attempt to update the Standards-Version in a select
> set of situations where it can verify that there are no
> changes necessary to comply with the new standards version.
Great, I think we're on the same page.
> The bot currently only supports upgrades between the
> following standards versions:
>
> * 4.1.0 => 4.1.1, if debian/changelog exists
> * 4.2.0 => 4.2.1, no checks (just loosens a requirement for perl
>files)
> * 4.3.0 => 4.4.0, if the package uses debhelper
> * 4.4.0 => 4.4.1, if there is only one Vcs field and none of the file
> patterns
>in machine-readable debian/copyright refers to a directory[*]
>
> In all other situations, it leaves the Standards-Version field alone -
> requiring a human to deal with updating it.
Cool. That seems like the correct approach.
> These checks were implemented based on my reading of the policy
> upgrading check list [1]. I'm hoping that it can upgrade between more
> versions in the future, but of course in most situations a human will
> need to be involved.
Right.
> So while it verifies that the package is compliant with the
> newer standards version ("violations"), it does not currently check
> that there are no liberties provided by the newer version that the
> package could use ("opportunities"). E.g. it doesn't refuse to
> upgrade to 4.4.0 if there is a Vcs-Hg field without a branch specified
> in the package, where the package maintainer may have wanted to set a
> branch.
>
> I do indeed also manually review all diffs before they end up in merge
> proposals; at the time of writing I have no plans to stop doing this,
> but this is more of a QA step and consists of a fairly casual review -
> I don't expect to be spotting policy violations/opportunities
> consistently at this step.
>
> Please let me know what you think. I'm open to extending the
> number of checks (e.g. to cover for possible "opportunities" like
> setting -b on the Vcs-Hg field) or indeed to stop touching the
> Standards-Version altogether, if policy team would still prefer that.
What you are doing right now looks safe. If you extend Janitor's work
with std-ver to do more than the sort of completely verifiable updates
described above, I would be grateful if you'd share your plans with
debian-policy@lists before implementing them; we may have something
useful to say.
Thank you for thinking carefully about std-ver, and once again for your
work on the Janitor project!
--
Sean Whitton
signature.asc
Description: PGP signature
Re: debian/*.symbols files for C++ libraries
Am 29.02.20 um 16:33 schrieb Mike Gabriel: > Until now, I mostly avoided writing .symbols files for C++ shared libs. Solve the problem, but let some maybe important informations pass through. > But I am now. Thanks to all pkg-kde-tools hackers for the symbols > helper. Much appreciated. A maybe a wrong explanation - changes in the symbols mean that a library will not work at some points - may it be because of a changed compiler or changed sources - the result is that the former lib will behave different - and that's exactly my motivation to take care about. And yes, pure c behave better regarding symbols. - I for myself prefer readable symbols, so i made this very small script "symmangle": > if [ -d ./debian ]; then > for i in `find . -name symbols`; do > k=`echo $i | sed "s#/DEBIAN/symbols##" | sed "s#./debian/##"` > cat "$i" | sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' | c++filt | > LC_ALL=C sort -u | tee "debian/$k.mangled"; > done > fi > it's easy to see that it's a simple wrapper around c++filt. > > light+love > Mike > Cheers Alf signature.asc Description: OpenPGP digital signature
Bug#952810: RFH: ebib -- BibTeX database manager for Emacs
Package: wnpp Severity: normal I request assistance with maintaining the ebib package. Upstream makes a lot of releases and I haven't been able to keep up for a while. A current blocker for updating to a more recent release is that upstream changed how their documentation is built. Fixing this might be an interesting project for one of our newer Emacsen Team members; I can sponsor uploads. I still rely on ebib for work and so would like to stay involved in maintainance. The package description is: Ebib is a BibTeX database manager that runs in Emacs. With Ebib, you can create and manage .bib-files, all within Emacs. It supports @string and @preamble definitions, multi-line field values, searching, and integration with Emacs' (La)TeX mode. -- Sean Whitton signature.asc Description: PGP signature
Bug#952809: ITP: minilla -- CPAN module authoring tool
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: minilla Version : 3.1.9 Upstream Author : Tokuhiro Matsuno * URL : https://metacpan.org/release/Minilla * License : Artistic or GPL-1+ Programming Lang: Perl Description : CPAN module authoring tool Minilla is a CPAN module authoring tool. Minilla provides the minil command for creating, testing, releasing, installing, and uploading CPAN distributions. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Re: debian/*.symbols files for C++ libraries
Hi Scott, hi KDE team On Mo 17 Feb 2020 22:32:18 CET, Scott Kitterman wrote: On February 17, 2020 9:23:39 PM UTC, Mike Gabriel wrote: Hi all, (please Cc: me when replying. Thanks.) I'd like to warm up an old topic regarding creation of *.symbols files for shared libraries implemented in C++. I have followed all links in [1] and esp. read Russ Alberries experiment results [2,3]. All writing are quite old and I wonder if something new has come up meanwhile (improved tool chains, etc). Until now, I mostly avoided writing .symbols files for C++ shared libs. However, here comes the question: How do people handle .symbols files these days if they originate from C++ code? How do people make sure the .symbols files are correct for all supported architectures? What tool chains are used? Are there other good reads about the topic? My current context: I want to fix various build failures of lib-cpp related packages relevant for upcoming Unity8. Thanks + Greets, Mike [1] https://wiki.debian.org/UsingSymbolsFiles [2] https://www.eyrie.org/~eagle/journal/2012-01/008.html [3] https://www.eyrie.org/~eagle/journal/2012-02/001.html Here's what the QT/KDE team use: https://qt-kde-team.pages.debian.net/symbolfiles.html https://manpages.debian.org/testing/pkg-kde-tools/pkgkde-symbolshelper.1.en.html I've used it for other C++ packages with pretty good success. I have updated some of my C++ pkgs with .symbols files and it works like charme. I tried the pkg-kde-tools at an earlier point (several years ago) and wasn't happy with it. But I am now. Thanks to all pkg-kde-tools hackers for the symbols helper. Much appreciated. light+love Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpJtQwBjOLYm.pgp Description: Digitale PGP-Signatur
Re: Re: Security. Allow to run only executables with certain hash
I think If somebody would need python or perl language he would have to rewrite the library to allow only certain files to execute. And still he have to rewrite /bin/mv, /bin/cp source code to restrict actions with that library if they (mv, cp) are allowed by the app to execute. --- This is doable as an LSM for executables. Pretty sure there's a working version of this on Android that uses hashes stored with the file and signed. (I recall seeing something in LWN about it.) However, a major challenge is interpreted languages. Do you allow people to run /usr/bin/perl or not? Both answers imply a lot of difficult problems. Java, Python, Node, and anything else in that family have the same issue. You can otherwise set this up with a Linux distribution with existing tools and maybe a few additions, but in practice you would have to bless Perl and Python (at least), and then it's not clear if you're getting enough security benefit. -- Russ Allbery (r...@debian.org)
