Bug#889636: ITP: rt4-extension-resetpassword -- Reset Password extension (Request Tracker)
Package: wnpp Severity: wishlist Owner: Andrew Ruthven * Package name: rt4-extension-resetpassword Version : 1.04 Upstream Author : Best Practical Solutions * URL : https://metacpan.org/release/RT-Extension-ResetPassword * License : GPLv2 Programming Lang: Perl Description : Reset Password extension (Request Tracker) This extension allows users to get a reset password link in Request Tracker. RT doesn't come out of the box with an ability for users to reset their passwords if they forget them, or if they aren't set. This extension adds that ability. The intial packaging work has been carried but by myself for my employer. Ongoing maintenance will be by the Debian Request Tracker Group (of which I'm a member).
Re: Re: RFS: materia-gtk-theme
On रविवार 04 फेब्रु 2018 10:49 म.नं., Adam Borowski wrote: > On Sun, Feb 04, 2018 at 09:59:56PM +0530, I Sagar wrote: >> I prepared the packaging of materia-gtk-theme. It is lintian clean >> and tested with pbuilder.Further information about this package can >> be accessed from the URL : >> https://salsa.debian.org/isaagar-guest/materia-gtk-theme > > Please don't sent RFS requests to debian-devel; the proper list is > debian-mentors. Also, a mere mail tends to be forgotten unless acted upon > immediately, please file a bug instead. Just: > [~]$ reportbug sponsorship-requests > which will DTRT. ok, next time I'll follow the procedure without fail. > > (Not needed this time -- your package looks good; in NEW.) > >> It would be nice if it is maintained under Debian desktop group. > > There's a separate team set up for themes: > https://salsa.debian.org/groups/desktop-themes-team > which you even have already joined. > > You may consider moving the VCS for this package to this team. I'll get this done upon getting access . > >> Consider to review and upload it. > > Done! Thank you very much :) > > > Meow.
Re: ITP: lsmount -- a simple formatter for /proc/mounts
On Sun, Feb 04, 2018 at 04:06:05PM +0100, Adam Borowski wrote: I even wrote a series of patches for dfc fixing this and other issues (https://github.com/kilobyte/dfc/commits/master) but they haven't been accepted by upstream. I found the pull request itself to be interesting reading. It seems the author was keen to merge many of your changes, but not all, and since you piled them all into one PR the onus was on them to try and unpick the result. I guess they lost interest or forgot about the PR after a while. https://github.com/Rolinh/dfc/pull/9 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Package review: ddupdate.
Hi Alec, On Sun, Feb 04, 2018 at 02:20:55PM +0100, Alec Leamas wrote: Following the checklist for new packages on debian mentors FAQ [2] I'm approaching the review point: "Ask on the debian-mentors mailing list for people to check your packaging..." You've sent this to debian-devel@ rather than debian-mentors@. Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#889660: ITP: golang-github-gobuffalo-envy -- simplify working with ENV variables
Package: wnpp Severity: wishlist Owner: Dr. Tobias Quathamer * Package name: golang-github-gobuffalo-envy Version : 1.3.0+git20180205.bac51f7-1 Upstream Author : Mark Bates * URL : https://github.com/gobuffalo/envy * License : Expat Programming Lang: Go Description : simplify working with ENV variables Envy makes working with ENV variables in Go trivial: * Get ENV variables with default values * Set ENV variables safely without affecting the underlying system * Temporarily change ENV vars; useful for testing * Map all of the key/values in the ENV * Loads .env files (by using godotenv This package is a dependency for hugo 0.35. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#889661: ITP: apertium-ukr -- Apertium single language data for Ukrainian
Package: wnpp
Severity: wishlist
Owner: Kartik Mistry
* Package name: apertium-ukr
Version : 0.1.0
Upstream Author : John Lyell and others
* URL : https://www.apertium.org/
* License : GPL-3+
Programming Lang:
Description : Apertium single language data for Ukrainian
Data package providing Apertium language resources for Ukrainian.
- why is this package useful/relevant?
A. Dependency for apertium-urk-rus package.
- 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?
A. Under science-team umbrealla.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
signature.asc
Description: PGP signature
Re: Mass bug filing for the removal of freetype-config and freetype.m4
Hi Simon, On Friday, 2 February 2018 11:14 PM, Simon McVittie wrote: > On Thu, 01 Feb 2018 at 11:07:42 +, Hugh McMaster wrote: >> Freetype-config has been considered deprecated for several years [1]. > > By us, or by upstream? Both. We considered freetype-config a deprecated legacy interface back in 2011 [1]. Upstream also recommend using pkg-config over freetype-config in freetype-config(1). In fact, freetype-config has used pkg-config as a wrapper since February 2017 [2]. > Is there a reason to prefer removing AC_CHECK_FT2, rather than patching > it to provide enough of its historical functionality for (I'd guess) 90% > of packages? Something like this should work (untested): > > AC_DEFUN([AC_CHECK_FT2], > [ >PKG_CHECK_MODULES([FT2], [freetype2 >= $1], [$2], m4_if([$3], [], [:], > [$3])) > ]) > > (This doesn't do the sanity-checks that current AC_CHECK_FT2 does, > and it respects PKG_CONFIG_PATH instead of --with-ft-prefix, > --with-ft-exec-prefix and FT_CONFIG, but this shouldn't matter most of > the time; and it seems better if simple packages still compile than if > they don't.) codesearch.debian.net shows 26 packages referencing AC_CHECK_FT2. > Does Freetype's upstream developer consider AC_CHECK_FT2 to be deprecated > too? Not as far as I can tell. That said, I'm not against patching the m4 macro to use PKG_CHECK_MODULES if you believe it will be useful. > If we ask the upstream developers of various packages to make a change > because otherwise their package won't compile on Debian, some of them > will say "well, that's Debian's fault for removing APIs provided by > Freetype's upstream developer" and do nothing. If we ask them to make a > change because Freetype upstream has officially deprecated the macro/tool > they're using, or because otherwise their package (eventually) won't > compile against newer upstream Freetype releases, it seems more likely > to happen. > > Not carrying long-term patches to the build systems of a large number of > packages seems a good goal. Good point. I'll file a bug upstream to ask them to drop freetype-config. In the meantime, I'll do the mass bug filing for Debian. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642354#10 [2] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/builds/unix/freetype-config.in?id=1c513fbb8872bfac5631964963b6a751169a1ce6
Debian part of a version number when epoch is bumped
Hi, moon-buggy recently had its epoch bumped. The old version is 1.0.51-11, the new version is 1:1.0.51-1. I opened https://bugs.debian.org/887740 to request that the version number be bumped to 1:1.0.51-12. The problem with the 1:1.0.51-1 version number is that the Debian source filenames like the .dsc do not include the epoch in the filename. This means that is impossible to include the completely history of files in the same directory (because there would be files with the same file name but different file contents). This also means that it is impossible to auto-sync the package to Ubuntu. The maintainer thinks the 1:1.0.51-12 version number would be "ugly" and the version number issue is only an Ubuntu-specific problem (given that the original 1.0.51-1 was superseded in 2006). I could not find anywhere in Debian Policy that directly addressed this issue. Therefore, I'm bring up this issue here to get input from other developers. Thanks, Jeremy Bicha
Re: Debian part of a version number when epoch is bumped
On Mon, Feb 5, 2018 at 9:43 AM, Jeremy Bicha wrote: > > The maintainer thinks the 1:1.0.51-12 version number would be "ugly" The maintainer would not be wrong. -m
Re: Debian part of a version number when epoch is bumped
On Mon, Feb 05, 2018 at 10:43:17AM -0500, Jeremy Bicha wrote: > moon-buggy recently had its epoch bumped. The old version is > 1.0.51-11, the new version is 1:1.0.51-1. I opened > https://bugs.debian.org/887740 Sigh. Indeed he had no reason to bump the epoch. He couldn't see solutions, but the truth is that all he had to do was to switch to 3.0 (quilt) with the -12 upload and clean up its sources. moon-buggy_1.0.51.orig.tar.gz had never been uploaded, and even if it was the epoch would have not allowed him to replace it as the upstream version doesn't change with epoch changes. This is one of the many situations where I'd like developers to *ask* when unsure or uncertain of something. So, in fact, the epoch bump was totally useless, and as it often happens in those cases, it's causing headaches for somebody. > The maintainer thinks the 1:1.0.51-12 version number would be "ugly" Well, for sure bumping -1 → -12 is ugly... > and the version number issue is only an Ubuntu-specific problem (given > that the original 1.0.51-1 was superseded in 2006). I agree this is an Ubuntu issue with their infrastructure. Have you tried asking the ubuntu archive admins, maybe they could get it through manually? > I could not find anywhere in Debian Policy that directly addressed > this issue. Please don't consider the Debian Policy like a stick. Or a all-kwowing never-wrong oracle. > Therefore, I'm bring up this issue here to get input from other > developers. If I were the maintainer, I'd just bump the version to get it through LP, but I'm biased as I'm also a Ubuntu developer. Otherwise, just manually merge it, doing the 1.0 native → 3.0 quilt move properly? Just that then the version are not going to match anymore for a long while, and MoM is surely going to be confused… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Frustration over Debian naming
rhkramer: Intentionally cross posted. Aside: For those on the debian-user lists, the thread came from the debian-backports list, but my frustration should probably be expressed more to the debian-user list (or debian-developer list, assuming there is such a list (to which I am not subscribed). [...] But the various names and use of those names gets very frustrating for me, and I suspect I am not the only one. The numbered versions, the Toy Story names, and then the testing, stable, old stable, old old stable is just frustrating. Tangentially to that, it seems that someone needs to pick up the dropped baton and update the pictures. * http://wiki.lib.sun.ac.za/images/thumb/a/aa/Timelinededebian.png/800px-Timelinededebian.png * http://blog.admin-linux.org/wp-content/uploads/2012/01/infographic_debian_history-en-v081.png * http://doc.callmematthi.eu/pictures/Understanding_Debian.png * https://i.stack.imgur.com/nLXu9.jpg * https://bsdmag.org/wp-content/uploads/2016/08/infographic_debian-v2.1.en_.png
Bug#889694: ITP: editorconfig-core-py -- Python library for working with EditorConfig
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: editorconfig-core-py Version : 0.12.1 Upstream Author : EditorConfig Team * URL : https://pypi.org/project/EditorConfig/ * License : PSF-2 Programming Lang: Python Description : Python library for working with EditorConfig EditorConfig makes it easy to maintain the correct coding style when switching between different text editors and between different projects. . When developing an editor plugin for reading EditorConfig files, the EditorConfig core code can be used to locate and parse these files. . This package is the Python library of EditorConfig Core. This is a dependency for the ‘editorconfig-gedit’ package. -- \ 德不孤、必有鄰。 (The virtuous are not abandoned, | `\ they shall surely have neighbours.) | _o__)—孔夫子 Confucius (551 BCE – 479 BCE) | Ben Finney signature.asc Description: PGP signature
Re: Frustration over Debian naming
On Tue, Feb 6, 2018 at 6:17 AM, Jonathan de Boyne Pollard wrote: > Tangentially to that, it seems that someone needs to pick up the dropped > baton and update the pictures. Those are all copies of a diagram by Claudio Filho, if anyone updates it, please send him a pull request to update the official repository: http://cfnarede.com.br/en/infographic-of-debian https://github.com/filhocf/infographics -- bye, pabs https://wiki.debian.org/PaulWise
Bug#889696: ITP: editorconfig-gedit -- EditorConfig support for GEdit
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: editorconfig-gedit Version : 0.5.3 Upstream Author : EditorConfig Team * URL : https://github.com/editorconfig/editorconfig-gedit/ * License : BSD-2-clause Programming Lang: Python Description : EditorConfig support for GEdit EditorConfig makes it easy to maintain the correct coding style when switching between different text editors and between different projects. . This package installs the plug-in for GEdit to support EditorConfig settings. -- \ “I'm a born-again atheist.” —Gore Vidal | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
