Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Sun, Jun 16, 2019 at 04:28:37PM +0200, Nicola Di Lieto wrote: > New version with suggestions from Adam > > dget -x https://mentors.debian.net/debian/pool/main/u/uacme/uacme_1.0.15-3.dsc I'm afraid it doesn't build again: http://ix.io/1Ma0 In file included from crypto.c:31: crypto.h:58:2: error: #error either USE_GNUTLS or USE_MBEDTLS or USE_OPENSSL must be defined #error either USE_GNUTLS or USE_MBEDTLS or USE_OPENSSL must be defined Also, sorry if I haven't been clear -- asciidoc is long unmaintained and on its way out, the replacement is asciidoctor; it'd be nice if you could migrate to that (it's supposed to be fully compatible). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Tue, Jun 18, 2019 at 02:01:08PM +0200, Andre Noll wrote: > On Fri, Jun 07, 10:39, Andre Noll wrote > > > > What about tfortune-data that ships as many good epigrams as you have, > > > that's Recommended: by tfortune? > > > > Sounds good. I've merged and pushed out the t/debian branch so > > that current master corresponds to what you have uploaded. I'll come > > back to you when the tfortune-data package is ready. > > Here we go. The public repo now contains the t/tfortunes branch with > the following four commits on top of master: Looks good. However, version 1.0.0-1 is already in NEW, thus unless it's REJECTed, the version number cannot be reused. There's also a typo: "considerd". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.
Bug#930595: RFS: uacme/1.0.15-2 [ITP]
On Sun, Jun 16, 2019 at 10:52:00AM +0200, Nicola Di Lieto wrote: > * Package name: uacme > Version : 1.0.15-2 > Upstream Author : Nicola Di Lieto > * URL : https://github.com/ndilieto/uacme > uacme - Lightweight client for the RFC8555 ACMEv2 protocol There's already a team in Debian dedicated to packaging of stuff made by that anvil-making company. Have you contacted them? The package doesn't build for me: http://ix.io/1LVo ./configure: line 5401: syntax error near unexpected token `$CFLAGS' ./configure: line 5401: `AX_CHECK_COMPILE_FLAG($CFLAGS -Wall, CFLAGS="$CFLAGS -Wall")' Not building something (like the man page) from source is usually a serious error. In this particular case, groff is nearly as sourcey format as asciidoc -- but it'd still be a problem with upstreaming. Someone wanting to improve the man page can't easily test asciidoc (as the patched build system doesn't use that) yet improvements done as groffage wouldn't be liked by upstream (in this case you). But, what about using asciidoctor instead? That's supposed to be a drop-in replacement for asciidoc. Your upstream project seems to use straightforward sane github-based release workflow, that makes watch files easy to write (just copy one of existing recipes). Watch files are not mandatory, but are nice to have. A new package can be uploaded only to unstable (or experimental) -- your version is targetted at stretch. For a backport, it needs to first be in testing, thus please retarget at unstable even if you eventually do want to include a backport later. And, we care about future releases more than past. But generally, the above problems aside, the package seems to be well made. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Secret tech: have up-to-date backups. Rules of this world say ⢿⡄⠘⠷⠚⠋⠀ a failure can ever happen if you don't have them, which saves a ⠈⠳⣄ lot of downtime spent restoring.
Bug#927996: RFS: diskfit/2.0.2.3 [ITP] -- Simple disk fit calculator
Hi! On Wed, May 29, 2019 at 08:30:50AM +0200, Heiko Schäfer wrote: > an updated package is available at > > https://launchpad.net/~velnias/+archive/ubuntu/sandbox/+sourcefiles/diskfit/2.0.2.6-1~eoan~ppa1/diskfit_2.0.2.6-1~eoan~ppa1.dsc > > Please ignore the '~eoan~ppa1' for the moment, because I build my packages > currently via Ubuntu's Launchpad. 'Eoan' comes closest to 'sid'. You'll need to update that for the final upload, but during the review that's ok. debian/copyright needs an entry for install-sh which is under the MIT/X11 license. debians/source/options forces xz level 9 compression, which for this size of files is harmful (doesn't improve disk space, and requires a lot of memory on tiny machines). Please just drop these settings -- they should be used only in special cases. debian/control: could you please fill in Homepage/Vcs-*, or at least drop the commented out fields? The long desc really needs to be extended. Even with trying to use the program, I had some trouble finding out what it is for. Also, a man page is vital for a command-line tool. Upstreamish side: I played with the GUI a bit, and it seems to handle selecting a dir badly (which, in my naive understanding, is what most people will try to do). It does nothing until you click "Cancel", in which case it'll add one of previously (not currently) show directories. And then the program doesn't seem to do anything useful. So, if dirs are not supported, the programs shouldn't at least try them. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal).
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Thu, Jun 06, 2019 at 12:42:48PM +0200, Andre Noll wrote: > On Wed, Jun 05, 15:49, Adam Borowski wrote > > On Wed, Jun 05, 2019 at 02:31:09PM +0200, Andre Noll wrote: > > > That's the old hen and egg problem: One needs to provide a bug number > > > in debian/changelog for the initial RFS, i.e. before the bug has been > > > opened. So I put a dummy number there and forgot to update it after > > > the bug number had been assigned. Fixed now. > > > > The RFS and ITP are unrelated. > > IDGI. For an RFS email one needs to provide the source package with > a debian/ directory, correct? If so, the debian/changelog file must > contain a line of the form > > * Initial Release. Closes: #929467 > > But the number will only be assigned after the mail has been sent. > What am I missing here? You file ITP stating you intend to work on package X. Once you're done, you file a RFS. > > > > On the other hand, the package neither ships any data files, nor can't > > > > handle their lack gracefully: it crashes with: > OK. Do you think it makes sense to provide another package which > installs a few tagged epigrams in, say, /usr/share/games/tfortunes > and make tfortune fall back to this directory if ~/.tfortune does > not exist? That'd be nice. What about tfortune-data that ships as many good epigrams as you have, that's Recommended: by tfortune? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Sometimes you benefit from delegating stuff. For example, ⢿⡄⠘⠷⠚⠋⠀ this way I get to be a vegetarian. ⠈⠳⣄
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Tue, Jun 04, 2019 at 05:06:00PM +0200, Andre Noll wrote: > v3 is pushed out now and contains > a simple debian/rules file which fully relies on dh. Besides > dh_auto_configure I also had to override dh_autoreconf for reasons > explained in the commit message. The package looks almost good now. You do close a completely unrelated ITP bug though: "ITP: eazel-engine". On the other hand, the package neither ships any data files, nor can't handle their lack gracefully: it crashes with: regfile_iter_new: opendir /home/kilobyte/.tfortune/epigrams: No such file or directory Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Sometimes you benefit from delegating stuff. For example, ⢿⡄⠘⠷⠚⠋⠀ this way I get to be a vegetarian. ⠈⠳⣄
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Sat, Jun 01, 2019 at 11:17:53PM +0200, Andre Noll wrote: > Adam, do you want me to provide v3 with debian/rules changed to > something like the above? v2 still suffers from the non-standard perms on usr/ and so on, thus I guess it'd be simpler to move to the dh workflow rather than to fix what you currently have. It's by no means mandatory, but our newly elected Dear Leader is waging a campaign to make it strongly recommended, especially for new packages. I quite see why. And I for one prefer packages where a reviewer doesn't have to fire up the brain to comprehend what's being done. :) (But again, it's no cdbs nor waf -- I'd gladly review either approach.) > Note, however, that building with the simple debian/rules file prints a > warning because dh_auto_configure seems to add --disable-silent-rules, > --disable-maintainer-mode and --disable-dependency-tracking to the > configure command line, which tfortune's configure doesn't know. Yeah, it assumes autotools' quirks. If that's a concern, you do: override_dh_auto_configure: dh_auto_configure --some --params or: override_dh_auto_configure: ./configure --foo --bar The man page says: # This is intended to work for about 90% of packages. If it doesn't work, # you're encouraged to skip using dh_auto_configure at all, and just run # ./configure or its equivalent manually. > This seems to be a common problem. One solution is to call configure > directly, as recommended in the dh_auto_configure man page. Another way > to avoid the warning is to provide noop-stubs for the three options > in configure.ac. I'd prefer to call configure directly because this > is a bit simpler and touches only debian/rules. Opinions anybody? Either way would work. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#929816: RFS: simhash/0.0.20161225-1 [ITA] -- generate similarity hashes to find nearly duplicate files
On Sat, Jun 01, 2019 at 01:27:53AM +0800, laokz wrote:
> I am looking for a sponsor for my first package "simhash".
>
> * Package name: simhash
> Version : 0.0.20161225-1
> Changes since the last upload:
>
> * New maintainer. Closes: #652727
> * Upgraded d/* according to Debian Policy 4.3.0.3.
>Priority -> optional, Standards-Version -> 4.3.0, debhelper >= 12,
>update Vcs-* fields, add simple testsuite and watch file,
>remove redundant d/{clean,dirs,lintian-overrides}.
> * Upstream cleaned up buffer signedness warned by gcc. (Git commit fa34436)
Hi!
It's nice to see you taking up this package -- however, this is an upload to
unstable during the freeze. It's generally a bad idea; it would be better
to either use experimental or to wait until Buster is released.
> After packaging, I checked lintian, debdiff .dsc|.deb results, tried
> install/remove/run, and https://tracker.debian.org/pkg/simhash. More
> explanations:
>
> * d/dirs removed: Its content is 'usr/bin' which belongs to FHS.
> * d/simhash.linlian-overrides removed: It contained "no-upstream-
> changelog", which is nonexisted in current lintian version.
> * d/{clean,rules,test/*}: Based on source 'test.sh', the testsuite can
> confirm the build procedure. d/clean is no needed also.
> * d/{watch,source/lintian-overrides}: New version adds a watch file. It is
> not very well but can do work.
It finds some old version for me:
uscan info: Newest version of simhash on remote site is 0.0.20110213, local
version is 0.0.20161225
uscan info:=> Only older package available from
https://github.com/BartMassey/simhash master
> Another request. I updated Vcs-* fields, but need you help to upload to
> salsa.debian.org/debian/.
(didn't do this yet)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes
⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Fri, May 24, 2019 at 08:57:49AM +0200, Andre Noll wrote: > * Package name: tfortune >Version : 1.0.0 > git clone git://git.tuebingen.mpg.de/tfortune/ Hi! I'm afraid your packaging unnecessarily reinvents a good part of usual tools, and does this wrong. For example: * directories have non-standard permissions, and this affects common dirs as well * gzip is invoked without -n, which renders the package non-reproducible * standard build flags don't get passed to the compiler * no md5sum files are generated I'd recommend using dh instead. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#929241: RFS: xmltoman/0.6-1 - simple XML to man converter
On Tue, May 21, 2019 at 05:59:45AM +0200, Adam Bilbrough wrote: > Hi Adam, I have re-uploaded it to mentors. Tested on multiple > systems, should be no problems now. > On Mon, 20 May 2019 at 06:29, Adam Bilbrough wrote: > > > Fails to build for me: Hi! I'm afraid I only now noticed that this is an upload to unstable for a package that has a version in Buster. It's generally a pretty bad idea to do so during the freeze, other than to fix important bugs. Thus, it'd be good to either: * wait until Buster is out, or * put the new version into experimental instead Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Re: Create repository under Debian workspace on Salsa
On Sat, May 25, 2019 at 01:42:09PM -0300, Gabriel F. T. Gomes wrote: > I'm working on a new package and I would like it to be under the Debian > workspace on Salsa, but I don't have the rights to do it. Could someone > do it for me? > > The project currently resides in: > https://salsa.debian.org/gabrielftg-guest/pveclib > > I suppose cloning it to Debian/ with the same name would be allright. Done. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#929350: RFS: libt3highlight/0.4.8-1
On Thu, May 23, 2019 at 08:35:55AM +0200, Gertjan Halkes wrote: > Hi Adam, > > Thanks for pointing out the feature freeze, and sorry for forgetting about > it :-( I think I will go for option 3, as the bad-free bug can cause program > crashes. Not just a feature freeze -- a hard freeze, with rules approximating those of stable updates (ie, important bug fixes only). On the other hand, while rules as to what changes are acceptable are the same, it's drastically less hassle to get the fix through now than it'll be after the release. > Once the feature freeze is over, I'll revist the release of 0.4.8. > Do we keep this bug open, or shall I simply file a new bug once the time has > come? It'd be good to mark it as not actionable for now, yeah. Closing and reopening would work, so would closing and re-filing. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Bug#929350: RFS: libt3highlight/0.4.8-1
On Wed, May 22, 2019 at 09:14:11AM +0200, Gertjan Halkes wrote: > * Package name: libt3highlight > Version : 0.4.8-1 > Changes since the last upload: > > * New upstream release. Hi! This upload is targetted at unstable, yet doesn't look like something fit for a late-freeze update. It is somewhat controversial whether this matters much for a near-leaf package, but it makes the life of the Release Team busier, and some people have strong opinions about the issue. Thus, I'd propose either: 1. pausing until Buster is released, or 2. uploading to experimental instead, or 3. if you consider it important, isolating just the bad free fix, and applying it as a patch to 0.4.6 (I don't know how severe the bug is) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#929241: RFS: xmltoman/0.6-1 - simple XML to man converter
On Sun, May 19, 2019 at 09:54:49PM +0200, Adam Bilbrough wrote: > Package name: xmltoman > Version: 0.6-1 > Changes since the last upload: > > * New upstream release. > * Updated debian/watch to point to new upstream location. > * Updated debian/control with maintainer information. > * Updated debian/copyright with new maintainer and date. Fails to build for me: [...] dh build dh_update_autotools_config dh_autoreconf dh_auto_configure dh_auto_build make -j64 make[1]: Entering directory '/<>' ./xmltoman xml/xmltoman.1.xml > xmltoman.1 ./xmltoman xml/xmlmantohtml.1.xml > xmlmantohtml.1 /bin/sh: 1: ./xmltoman: Permission denied make[1]: *** [Makefile:10: xmltoman.1] Error 126 make[1]: *** Waiting for unfinished jobs /bin/sh: 1: ./xmltoman: Permission denied make[1]: *** [Makefile:13: xmlmantohtml.1] Error 126 make[1]: Leaving directory '/<>' dh_auto_build: make -j64 returned exit code 2 make: *** [debian/rules:5: build] Error 2 Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Re: Removing incorrect upload from NEW
On Thu, May 16, 2019 at 08:23:59AM +0300, Andrius Merkys wrote: > Dear Mentors, > > I have recently uploaded incorrect package to the NEW > (gversion-plugin_1.5.0-1_amd64.changes, should have been a repacked > DFSG-compliant version). I would like to remove the incorrect upload > from NEW and dput the right package. Neither of the following works for me: > > dcut cancel > dcut rm Both of these work only for packages uploaded but not yet picked up for processing (the first of two mails you get after an upload). That is: * a small time window for usual uploads * DELAYED Once the package has been taken for NEW, it's out of your reach, and you need to ask for a REJECT. Best way is hopping on IRC to #debian-ftp -- this is where ftpfolks hang out. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#928450: RFS: megadown/0~20190502+git734e46f-1 [RC]
On Sat, May 04, 2019 at 04:08:32PM -0700, Lev Lazinskiy wrote: > I am looking for a sponsor for my package "megadown" > > * Package name: megadown >Version : 0~20190502+git734e46f-1 > Changes since the last upload: > > * New upstream release (Closes: #927462) which is an RC bug. > * Remove patch series. Upstream swapped out python for jq. Python is no > longer > required > * Add jq as dependency Hi! This is a non-maintainer upload, and you don't seem to have followed the usual rules. Also, during a freeze, only small targetted fixes are appropriate -- this is a bulk new upstream version. There are cases when there's no better way than such a large upload (like Firefox and Chromium these days), but as the patch fixing #927462 is tiny and obvious (although I don't know if it's enough), it strongly seems the large upload is not needed. Thus, could you please extract (and test) just the fix? Only if that doesn't work we could debate uploading the whole new upstream version. Also, although a RC bug that hasn't seen maintainer response within two weeks is eligible for a 0-day NMU, you'd still need to follow at least parts of the procedure. Especially, the upload needs to be marked appropriately: the first line of the changelog should say "Non-maintainer upload.", the version needs to be .1, etc. NMUs are supposed to be small which is similar to during-freeze updates. (Even if such a procedure might seem like an unnecessary hurdle, it doubles as a way to ensure you are aware what you're doing.) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Re: GPG Key errors
On Thu, May 02, 2019 at 06:56:53AM +0200, Mechtilde wrote: > Am 01.05.19 um 23:53 schrieb Tong Sun: > > On Wed, May 1, 2019 at 3:50 PM Shreyas Bapat wrote: > >> I made a stop for good, and departed from the train station in a very > >> little time towards the destination. :) > > > > , I view such departure as the result of poking fun at the > > new-comers, instead of giving them direct answers -- direct answers > > like "start gpg beforehand" have much less typing, and are more > > helpful instead. Any unnecessary writing might be viewed as "you don't > > have time to answer my question, but you are willing to waste time on > > laughing at me", to the people that badly need help. > > Give a fish to a hungry person and (s)he has something to eat for one day. > Teach the person to fish and (s)he will have food for every day. Maxim 21: "Give a man a fish, feed him for a day. Take his fish away and tell him he's lucky just to be alive, and he'll figure out how to catch another one for you to take tomorrow." We want new contributors to find ways to teach others. :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#927293:
On Sun, Apr 28, 2019 at 10:55:03AM +0200, Miroslav Kratochvil wrote: > > The package seems in good shape, except for the "inih" one-file library. > > [...] Also, as it's already packaged in Debian, it might > > be better to use that copy rather than what's in tree. > > Unfortunately, it seems that the upstream `inih` is not compatible > with the editor anymore -- the internal copy is either historical or > modified, and relies on slightly different library API. > > Fixing the incompatibility requires larger path than what would be > maintainable. And in this case, a larger patch that the library itself. :p No reason to bother then, I'd say. Meow! -- < darkling> When all you have is a hammock, every problem looks like a nap.
Bug#927293:
On Sat, Apr 27, 2019 at 12:40:13PM +0200, Miroslav Kratochvil wrote: > retitle 927293 RFS: dte/1.8.2-1 [ITP] > > I just uploaded the newest packaged upstream release (1.8.2) to > mentors, should appear under the same link in no time. The package seems in good shape, except for the "inih" one-file library. It's under a different license, thus it needs a separate entry in debian/copyright. Also, as it's already packaged in Debian, it might be better to use that copy rather than what's in tree. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Sun, Apr 21, 2019 at 05:11:05PM +0200, Andre Noll wrote: > That's just because I misread section 8.1 of the Debian Policy Manual. > I've renamed the -dev package to liblopsub-dev. Not sure if you'd want the _source_ package to have a simple soname-less name as well; I would but that's up to you -- that'd be nicer and make having only-one-version transitions easier; on the other hand a soname-encoded source name is better when there's a need for multiple coinstallable versions. Your choice; current state is ok. > If there are further issues, just let me know. Just cosmetic stuff: * installation instructions don't really belong in the man page -- if you can read it, you've already managed to install the package. * please copy the description for liblopsub1 to liblopsub-dev; it currently says just "This package contains the development environment for the lopsub library." It's pointless to require the user to check the other package -- other libraries alter merely the last part. Also, it's -dev what users pull by hand. * is there a reason for shipping the static library? Static linking is frowned upon in a distribution -- whenever the library gets updated, every reverse dependency has to be recompiled; this is especially nasty for security updates. * (bonus) The nicely documented process for building the example looks like something that could be turned into an autopkgtest. Unlike build-time tests, autopkgtests are run against installed packages, the way an user would. That's of course extra effort, by no means required -- but, extra testing is always good. But in general, the package already seems to be in a releasable state. Could you please change "UNRELEASED" to "unstable" so it can be uploaded? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#925505: closed by Adam Borowski (Re: Bug#925505: RFS: dhcpoptinj/0.4.4-1 [ITP])
On Tue, Apr 16, 2019 at 11:38:40AM +, Andreas Misje wrote: > Out of curiosity, why did you upload one of the older revisions > uploaded to https://mentors.debian.net/package/dhcpoptinj and not the > newest, in which I have fixed a few issues, like outdated standards > version and debian-compat, and updated the VCS URIs? I had grabbed the package earlier, and did not suspect there might be updates since the last post. > If you are considering uploading another version, would you mind if I > package 0.5.0 first? While I'm obviously willing to upload new versions in the future, it's usually harmful to have multiple versions in NEW -- the ftpmasters would have to review them all, and failure in just one means rejection of everything. Thus, I'd recommend waiting for 0.4.4-1 to get ACCEPTed or REJECTed, and only then updating it. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool
On Mon, Apr 15, 2019 at 11:45:31AM +0500, Andrey Rahmatullin wrote: > On Mon, Apr 15, 2019 at 06:40:41AM +, Mishra, Gaurav wrote: > > FOSSology currently supports Debian Jessie and Stretch both. And Jessie > > still have a year left to meet its end of life that is the reason we still > > support it. And that is the reason php5-cli is still there. > Please keep in the official packages only stuff needed by the official > packages. > You will need to maintain a separate changelog anyway. On the other hand, if the official package has a priority, I don't see a problem with having support for unofficial/other distro/etc stuff. > > And for Stretch, we have added the regex `php5-cli|php7.0-cli|php7.2-cli` > > in the control file. > It's not a regex. And only the first alternative is considered by the > official buildds. For the ease of backports, you can have other alternatives later -- but official buildds indeed use only the first listed one. This is done to ensure consistent packages during a transition. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#925911: RFS: lopsub-1.0.2 [ITP]
(Sorry for slow response time.)
On Sat, Apr 06, 2019 at 09:52:53PM +0200, Andre Noll wrote:
> > > I see a static library installed by the package. Those shouldn't
> > > generally
> > > be used unless you're doing something special -- static linking makes
> > > security and bugfix updates extremely tedious. Libraries should also be
> > > split into separate binary packages, with lib${name}dev providing
> > > development files while lib${name}${so} the runtime lib.
I'm afraid that the shared library doesn't work: liblopsub1 in /usr/lib
has nothing but an infinite symlink loop from liblopsub.so.unnamed_version
back to itself.
Besides a proper soname, the file should also go to a multiarch dir (ie,
/usr/lib/x86_64-linux-gnu on amd64, /usr/lib/aarch64-linux-gnu on arm64,
etc -- most build systems get it right without your action).
Also, I wonder why you include the soname in the -dev package's name.
That's allowed but usually not what you want -- an ABI break will also
require changing every depending package instead of a simple recompile.
Unless you change the API every time there's a soname bump, it'd be
better to have the -dev package be unversioned. But this is up to you.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄
Bug#927052: RFS: errbot/6.0+ds-1 ITP
On Sun, Apr 14, 2019 at 10:25:55AM +0200, Birger Schacht wrote:
>
> * Package name : errbot
> Version : 6.0+ds-1
> It builds those binary packages:
>
> * errbot
Hi!
In the .service file, you use LC_ALL=en_US.UTF-8 unconditionally. That
won't work for anyone who's doesn't have that locale generated. Besides
USians, many people whose native language is not English use that as
fallback (it's d-i's default in such cases), but Brits, Aussies and the like
will have en_{UK,AU}.UTF-8 instead. The only guaranteed locale is C.UTF-8.
Very likely that'd be enough for you -- but if not, you'd need to organize
a way to run the daemon with a privately generated locale.
Also, why .service instead of an init script? This makes the daemon work
only with systemd -- not with sysv-rc, openrc, runit, etc. In particular,
this means that _I_ can't (without extra effort) test this package.
Of the following combinations:
* .service, no init
* both .service and init
* init, no .service
the latter two work everywhere; the last one being least work.
Everything else about the package seems to be ok.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!".
⠈⠳⣄
Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool
On Fri, Apr 12, 2019 at 06:59:12AM +, Mishra, Gaurav wrote: > Package name: fossology > Version : 3.5.0-1 Alas, it fails to build: it build-depends on php5-cli which is gone for two releases already (was in jessie, your package can get to bullseye at the soonest). [I won't likely be reviewing this package any further, though -- web stuff is not my strength.] Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Re: A question about stack alignment in C language
On Sat, Apr 06, 2019 at 02:08:17AM +, Mo Zhou wrote:
> Hi mentors,
Unlike Matthew, I don't consider code questions to be completely off topic.
And I hate Stack Overflow. So let's continue to the fun. :)
> float sasum64(size_t N, const float *X, size_t incX)
> float sasum32(int N, const float *X, int incX)
> compiled as libfoo.so: gcc -shared -fPIC libfoo.c -o libfoo.so
> float sasum64(int N, const float *X, int incX);
> float sasum32(size_t N, const float *X, size_t incX);
> printf("%f, %f\n", sasum32(3, a, 1), sasum64(3, a, 1));
> My questions are:
>
> 1. Why doesn't the application segfault, since it has already
> misused the index (N and incX) type?
On 32-bit archs, all these types have same widths.
On 64-bit, you have undefined behaviour portability-wise as registers that
are being used to pass these values might or might not have their upper bits
cleared.
On arm64, this is explicitly the case for a store to lower half (w0 of x0):
# w0 through w30 - for 32-bit-wide access (same registers - upper 32 bits
# are either cleared on load or sign-extended (set to the value of the most
# significant bit of the loaded value)).
On amd64, this is also the case for stores to lower 32-bits of a 64-bit
register (eax of rax). That's very surprising for those of us who did most
of their asm programming in 16-bit days: a store to al does _not_ clear the
upper half of ax.
I have no idea about other archs -- they very well could behave like 8086.
But the problem is, everyone among us has an amd64 box and a bunch of
arm64/armhf boards, but a trip to a porterbox for fringe archs tends to be
something you do only upon suspecting a bug.
Someone more knowledgeable may fill us in.
> 2. Did we avoid SIGSEGV because the arguments used to call
> sasum32 or sasum64 are aligned in 64-bits? But that's still
> strange due to little-endianess...
Registers don't care about endianness nor alignment. Any modern ABI passes
such arguments in the registers rather than stack, at most spilling once you
have too many.
On the stack, all 64-bit archs I'm aware of require 64-bit values to be
aligned; whether passing two 32-bit values side-to-side requires one or two
words depends on the ABI (stack is different from structs). In no case you
mention there's two 32-bit args.
> 3. How can I make the app.c segfault?
Possibly use a musty old arch (not sure about that)? Have more args that
include two 32-bit ones? Use negative values (size_t vs int, sign
extension)?
(And thanks for the question: TIL that eax -> rax zero/sign extends while
al -> ax did not.)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ It's all millenials' fault. I've discussed this with a cow
⣾⠁⢠⠒⠀⣿⡁ orker, we just couldn't agree on a definition -- I say
⢿⡄⠘⠷⠚⠋⠀ millenials start at 1979, he claims it's 1985+. But it's
⠈⠳⣄ certain: smelly millenials are the cause of all problems.
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 01:30:30PM +0200, Mathieu Mirmont wrote: > On Thu, Apr 04, 2019 at 10:20:47AM +, Dmitry Bogatov wrote: > > * I know, it is pain, but there should be init.d script. You may want to > > take a look at bcron=0.11-8. > > Sure, no worries. How about systemd service files? It makes little sense > to run socklog along with systemd I think, but for the principle it may > be required to profile service files. What do you think? No point in adding .service if you already have an init script; that'd be useful only if you want to do something _different_ when running under systemd, or when you hit a systemd bug that makes it unable to handle a regular init script. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 01:40:16PM +0200, Mathieu Mirmont wrote: > I did reach out to Gerrit Pape (previous maintainer & upstream) of > course before doing anything. I offered to help and he was happy to hand > over the package to me. Cool, that answers my question. It'll be enough to write "New maintainer" in the changelog then. > I'll file an ITS if you guys think I should. No point, you already have Gerrit's consent. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#926306: RFS: socklog/2.1.0-9
On Wed, Apr 03, 2019 at 10:45:56AM +0200, Mathieu Mirmont wrote: > * Package name: socklog > Version : 2.1.0-9 > Upstream Author : Gerrit Pape > Changes since the last upload: > > * Convert the package to debhelper (Closes: #857208) > * patches: Import previous patches > * patch: remove the chkshsgr test > * watch: add the uscan watch file > * socklog-run: migrate to dh-runit (Closes: #668718, #834089) > * gitlab-ci.yml: add GitLab CI file > * control: update the Vcs fields > * doc-base: register the html documentation > * lintian: add overrides This is a package hijack. In this case, the package is so neglected (no maintainer upload in 11 years, long-standing RC bugs) that insisting on the proper procedure would be a waste of time -- but it still should be done consciously. No mention in the changelog suggests that it's not. A nice new process is described here: https://wiki.debian.org/PackageSalvaging but it's probably an overkill for a clear case like here. But, the old maintainer being the upstream means you need to at least communicate with him beforehand. Adding Mattia Rizzolo to CC -- he's not only handling MIA, but also happened to NMU this package a couple of years ago. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Mon, Apr 01, 2019 at 12:57:51AM +0200, Andre Noll wrote:
> On Sat, Mar 30, 23:58, Adam Borowski wrote
> > On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> > > * Package name: lopsub
> > >Version : 1.0.2
> > This library is certainly not something for Debian only, thus please append
> > "-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
> > despite the name, doesn't require actually using quilt).
>
> Sure, I just wasn't aware of this convention, and that "3.0 (quilt)"
> is the right choice for a package like lopsub. One question: With this
> change applied, dpkg-buildpackage wants the upstream tarball in the
> parent directory. I guess I'm supposed to run git archive here to
> create it as part of the before-build hook, but I couldn't figure
> out where this hook is defined.
There are many workflows for this, but my personal favourite is to skip any
such wrappers and rely on uscan (ie, debian/watch) only. As most project
will want a watch file anyway, this reduces the amount of work.
Alas, the vast majority of projects use a git host that does provide tarballs
for a tag, thus I have never used uscan with mode=git (as downloading a
tarball is still more likely to produce a reproducible result), and thus
can't give you ready copypasta to use.
> > I see a static library installed by the package. Those shouldn't generally
> > be used unless you're doing something special -- static linking makes
> > security and bugfix updates extremely tedious. Libraries should also be
> > split into separate binary packages, with lib${name}dev providing
> > development files while lib${name}${so} the runtime lib.
>
> Yes, I had this concern as well. I'll change the build system to
> create a shared library instead and split the binary package as you
> suggest. I'll follow up with another reply when it's ready.
Sounds good.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> * Package name: lopsub
>Version : 1.0.2
Such a version means a native package; only software written specifically
for Debian which makes no sense outside it should use the native format.
Even if you're both upstream and the packager, a non-native format is
helpful in case someone other than you would upload a fix.
This library is certainly not something for Debian only, thus please append
"-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
despite the name, doesn't require actually using quilt).
>Upstream Author : Andre Noll
> * URL : http://people.tuebingen.mpg.de/maan/lopsub/
> * License : (L)GPLv3
It would be nice to mention more prominently what parts are GPLv3-ed and
which are LGPLv3-ed.
>Section : libdevel
>
> lopsup - The Long Option Parser for Subcommands
> However, there are still some warnings from lintian
> I don't know how to deal with.
I'd recommend running "lintian -i" which gives a long descriptive message
for every warning, including hints how to fix.
I see a static library installed by the package. Those shouldn't generally
be used unless you're doing something special -- static linking makes
security and bugfix updates extremely tedious. Libraries should also be
split into separate binary packages, with lib${name}dev providing
development files while lib${name}${so} the runtime lib.
I'll stop this round of review here; I haven't took a look at the actual
functionality yet.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄
Re: Backwards-incompatible ABI change due to function rename
On Mon, Mar 04, 2019 at 01:37:51PM +0200, Andrius Merkys wrote: > On 2019-03-04 13:32, Andrey Rahmatullin wrote: > > What does the upstream say about this? > > The upstream says that the renamed functions are not documented, > therefore they are private-ish. However, strictly speaking these > functions are public, as they are accessible in the ABI. But, are they actually available from the published API? And do reverse dependencies use those functions? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#923570: RFS: zipios/2.1.7.11-1 [ITA] -- small C++ library for reading zip files
On Sat, Mar 02, 2019 at 09:43:57AM +0100, François Mazen wrote: > Package name: zipios > Version : 2.1.7.11-1 > Changes since the last upload: > > * Rename to Zipios from Zipios++ > * New maintainer (Closes: #834214) > * Import new upstream release (Closes: #834171) > * Add watch file > * Fix reproducible issue with doxygen documentation > * Rename to libzipios2 from libzipios0v5 and create a transition > package. > * Add autopkgtest > * Add upstream metadata Alas, the transition freeze is in for quite a while already, and we're entering hard freeze. There's no way to get such a rename in. Even if we uploaded your new version today, it'd stay in NEW then in unstable until Buster's release -- for no benefit but blocking any fixes to the frozen package. Thus, I'm afraid such changes should wait. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
On Wed, Feb 27, 2019 at 09:33:43AM +0100, Domenico Andreoli wrote: > On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote: > > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote: > > > * Package name: dwarves-dfsg > > > Version : 1.12-2 > > > * Update copyright to copyright-format/1.0. Closes: #919356. > > The new copyright file contains references to GPL-2.0-only and > > GPL-2.0-or-later without defining them. > > According to https://spdx.org/licenses/ they are defined and supersede > GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm > reading that as long as copyright-format is not updated, new ones should > not be used. SPDX has nothing to the copyright-format. The latter doesn't care about short names at all, merely that 1. every file has a license, and 2. every license is defined. Thus, "GPL-2", "GPL-2+", "GPL-2.0-only", "GPL-2.0-or-later", "Meow-meow" and "Cthulhu-fhtagn" have exactly the same meaning: they're merely identifiers that need to be defined elsewhere in the file. Obviously, for human readers we still want GPL to mean GPL -- but it's a syntax vs content distinction. > Anyway, this is what I get if I switch to GPL-2 and GPL-2+ everywhere: > > W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2+ > (paragraph at line 102) > N: > N:The files paragraph in the machine readable copyright file references a > N:license, for which no standalone license paragraph exists. > N: > N:Refer to > N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for > N:details. > N: > N:Severity: normal, Certainty: possible > N: > N:Check: source-copyright, Type: source > N: > W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2 > (paragraph at line 94) So it does if you say "GPL-2.0-only" or "GPL-2.0-or-later"... > I spent quite some time in trying to understand what lintian tries > to tell me here. I verified that reshuffling the file does not help > either, these errors stay in a similar location, as if lintian had some > bug somewhere. "references a license, for which no standalone license paragraph exists" > I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly. I don't see it on mentors yet... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote: > * Package name: dwarves-dfsg > Version : 1.12-2 > Changes since the last upload: > > dwarves-dfsg (1.12-2) unstable; urgency=medium > > * Convert to dh. > * Fix Homepage and Vcs-Git. > * Fix depends on debhelper >= 10. > * Remove trailing spaces from the Debian changelog. > * Update copyright to copyright-format/1.0. Closes: #919356. Hi! The new copyright file contains references to GPL-2.0-only and GPL-2.0-or-later without defining them. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#923102: RFS: xsoldier/1:1.8-6 [ITA] -- shoot 'em up game with the "not shooting" bonus
On Sun, Feb 24, 2019 at 08:37:53AM +0100, Sebastien CHAVAUX wrote: > I would like to adopt the xsoldier package, considering that it does not > change much or little and requires little in consequence. > I am looking for a sponsor for my package "xsoldier" > * Package name: xsoldier > Version : 1:1.8-6 > Changes since the last upload: > > xsoldier (1:1.8-6) unstable; urgency=medium > > * New maintainer. (Closes: #738879) > > -- Sebastien CHAVAUX Sun, 24 Feb 2019 07:41:00 +0100 Would you have any changes other than to stake a claim? It's pretty pointless to make an upload only to change the Maintainer field. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#923039: RFS: dayon/1.7.1 ITP -- a cross platform remote assistance tool
On Sat, Feb 23, 2019 at 02:05:37PM +0100, Fensterkitt Computer Support wrote: > Package name : dayon > Version : 1.7.1 > Upstream Author : Reto Glante, i...@fensterkitt.ch > It builds those binary packages: > dayon_1.7.1_all.deb (which includes both, the assistant and the assisted > app, written in Java) > > https://github.com/RetGal/Dayon/releases/download/v1.7.1/dayon_1.7.1_all.deb Hi! You'd need to submit the source package; .deb is only the product of building. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Bug#921373: RFS: codelite [QA] -- Powerful and lightweight IDE
On Mon, Feb 04, 2019 at 05:11:40PM +, David Hart wrote: > * Package name: codelite > Version : 12.0+dfsg-1 > Changes since the last upload: > > codelite (12.0+dfsg-1) unstable; urgency=medium > > * QA upload. > > * New upstream release. > > * debian/codelite-plugins.install: > - Install new plugins. > * debian/copyright: > - Add copyright for new plugin. > - Update copyright dates. > * debian/patches: > - Refresh patches. > - Backport a fix for LLDB terminal crashes. > - Fix 3 more spelling mistakes. > * debian/control: > - Bump standards to 4.3.0. > * debian/compat: > - Use debhelper 11. > * debian/watch: > - Add oversionmangle for +dfsg Your upload would remove the last changelog entry, could you please fix that? Otherwise, I see no problems so far. The issue with VCS would be nice to solve but is not a showstopper. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#921226: RFS: austin/0.6.1~beta-1 [ITP]
On Sun, Feb 03, 2019 at 11:43:43AM +, Gabriele wrote: > * Package name: austin > Version : 0.6.1~beta-1 > dget -x > https://mentors.debian.net/debian/pool/main/a/austin/austin_0.6.1~beta-1.dsc > austin (0.6.1~beta-1) unstable; urgency=medium > > * Initial release (Closes: #918518) Hi! First, could you please upload your GPG public key to a keyserver (most will then distribute it further)? That's not strictly needed, but will allow verifying that subsequent uploads come from the same person. The command to do so is: gpg --send-keys 28685C7301633F89212E14876036934E1BA07EFA (not sure if there's a need to name a keyserver explicitly) The package requires some tool named "snapcraft" to even repack the source; I see no program by that name anywhere in Debian. It also doesn't declare any build-dependencies beyond debhelper; I haven't looked any further but it's pretty clear it'll need something pythonesque. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#917876: RFS: ethereal-chess/11.25+ds1-1 [ITP]
On Tue, Jan 29, 2019 at 06:33:01AM +0100, Jose G. López wrote: > Now, as fathom is building correctly [0], this package is looking for a > sponsor ;-) Hi! I'm afraid it fails to build for me: gcc -flto -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro src/*.c -lpthread -lm -lfathom -o ethereal-chess src/search.c:34:10: fatal error: tbprobe.h: No such file or directory #include "tbprobe.h" ^~~ Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 07:54:45PM +0530, Archisman Panigrahi wrote: > On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski wrote: > > > On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: > > > I am not sure about the native package issue. Has it got something to > > > do with /debian/source/format? I did not exactly understand what is > > > the difference between native and quilt, so went for native. Any > > > suggestion is welcome. > > > > The "native" format is adequate only when there's no separate upstream (and > > often not even then); in this case you are packaging Amit's software that > > has proper releases, tarballs, and all proper trappings. > > > > The packaging is supposed to be composed of two pieces: > > * the upstream (.orig) tarball > > * a packaging tarball, that includes the debian/ dir and a (possibly empty) > > patch series > > > > This was somewhat different with the 1.0 format, but you don't want it -- > > even if you (like me) despite quilt, the "3.0 (quilt)" format with a single > > patch is strictly better than 1.0. > > I am now using 3.0 (quilt). I have uploaded a new release (under the same > version number), please check. > There is some lintian error > "debian-changelog-version-requires-debian-revision". Is it due to the fact > that the debian/changelog in .orig.tar.gz Lintian has a nice set of explanations for its error messages, they get enables by "-I". These tend to be better than one-paragraph responses reviewers like me reply with (even though an automated tool is not as good at understanding the context). In this case, the version number should end in "-1". > init.py calls other python files in usr/share/brightness-controller/ui and > usr/share/brightness-controller/util, so I want init.py > to be in usr/share/brightness-controller/ as well. Otherwise I will need to > import them across directories which I want to avoid. That's a Python specific question, I can't answer those. I'm afraid that I need to pass you to other people on this mailing list. If you happen to have any Perl questions, though... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: > I am not sure about the native package issue. Has it got something to > do with /debian/source/format? I did not exactly understand what is > the difference between native and quilt, so went for native. Any > suggestion is welcome. The "native" format is adequate only when there's no separate upstream (and often not even then); in this case you are packaging Amit's software that has proper releases, tarballs, and all proper trappings. The packaging is supposed to be composed of two pieces: * the upstream (.orig) tarball * a packaging tarball, that includes the debian/ dir and a (possibly empty) patch series This was somewhat different with the 1.0 format, but you don't want it -- even if you (like me) despite quilt, the "3.0 (quilt)" format with a single patch is strictly better than 1.0. > No such executable file is needed to run this software. The > /usr/bin/brightness/controller calls the file > /usr/share/brightness-controller/init.py (which has been marked > executible with chmod +x), which can calls python to run itself. Yeah, but you're supposed to install the executable into /usr/bin. What your current package does is a text file without the +x bit, that's not going to work. In some complex cases it might be reasonable to have a wrapper but here I don't see a reason to not install to /usr/bin directly. In any case, a script needs to declare a hashbang with an explicit interpreter -- even though shells can execute a script without such a hashbang, relying on this is not allowed in Debian as it'd be unreliable if the user's shell is something weird. > I am not the main developer of the software (Amit Seal Ami > is), but am one of the major contributors. My > name is included in the list of contributors under > /usr/share/brightness-controller/about.py. All copyright holders (ie, contributors with non-trivial parts) need to be listed or at least referred to. > Can I edit the package description (to remove license information, > etc.) and release the next version? Would that work, or do I have to > make another RFS for it? Yeah, please do. You're not supposed to bump the version number while doing so (unless there's a really good reason), and neither you need another RFS. You can update this one until an upload to the archive has actually happened. > And, this is not compatible with Python 3 yet. That's good for Buster but it'll need to be updated after. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 11:16:09AM +0100, Adam Borowski wrote: > The package installs no useful executables, > /usr/share/brightness-controller/init.py has no x bit and its only contents /usr/bin/brightness-controller that is. > is "/usr/share/brightness-controller/init.py\n". -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
On Tue, Jan 22, 2019 at 01:41:49AM +0530, Archisman Panigrahi wrote: > * Package name: brightness-controller >Version : 2.2.3 > brightness-controller - Easily adjust your display brightness Hi! Why is this a native package if it's in no way specific to Debian only? The package installs no useful executables, /usr/share/brightness-controller/init.py has no x bit and its only contents is "/usr/share/brightness-controller/init.py\n". I wonder why the source package has a FHS-ish layout. This might be acceptable (but certainly atypical), but suggests something wrong is going on. At least some Python files have been generated but don't get regenerated during the build. The copyright file lacks at least yourself. That's ok only if you're doing the packaging as a part of your work duties, but I have doubts that "Amit Seal Ami " is your employer. The package's description is not supposed to talk about license, the upstream's github nor how to report bugs. Likewise, it's not a place to ask for review. It's probably a bad idea to use Python [2] in the packaging of a new program. While Python 2 is still supported for Buster, it'll be dropped early in the next release cycle. There's no man page. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]
On Mon, Jan 21, 2019 at 03:26:18PM +0100, أحمد المحمودي wrote: > Re-uploaded elinks, with libmozjs60-dev | libmozjs-dev (removed obsolete > libmozjs185-dev) Alas, it still FTBFSes: Working on: /<>/doc/manual.xml xmlto: /<>/doc/manual.xml does not validate (status 3) xmlto: Fix document syntax or use --skip-validation option /<>/doc/manual.xml:3993: element link: validity error : IDREF attribute linkend references an unknown ID "CONFIG-SCRIPTING-SPIDERMONKEY" Document /<>/doc/manual.xml does not validate make[2]: *** [Makefile:201: manual.html-chunked] Error 13 Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919743: RFS: rumur/2019.01.12-1 [ITP]
On Sun, Jan 20, 2019 at 12:15:54PM -0800, Matthew Fernandez wrote: > > On Jan 19, 2019, at 17:29, Adam Borowski wrote: > > > > On Fri, Jan 18, 2019 at 06:43:13PM -0800, Matthew Fernandez wrote: > >> * Package name: rumur > >> Version : 2019.01.12-1 > > The package fails to build: > > . > > In file included from /<>/librumur/src/parse.cc:10: > > /<>/librumur/include/rumur/scanner.h:6:12: fatal error: > > FlexLexer.h: No such file or directory > > #include > > ` > > This looks like missing build-dependency on libfl-dev. > > I guess I didn’t notice this as I had something else installed that pulled > in libfl-dev. Is there a page where I can see results from an attempted > build of my uploaded package? Or maybe you built it yourself locally to > discover this? flex has Recommends: libfl-dev, which _usually_ pulls that package in on user systems. That's specifically disabled in build environments -- only strict dependencies are guaranteed to be installed. The best way to test whether a package will build is to compile it in a minimal chroot. The automated way to do so is to use a tool like sbuild or pbuilder -- the former is used on official buildds and more fit for heavy-duty use, while pbuilder is much easier to use. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919819: RFS: knowthelist/2.3.1
Hi Adam, thanks for your fast feedback. To be honest, this was the easiest way for me to get rid of some confusing warnings / errors of the build tools. But your arguments sounds reasonable and I tried to re-build the package as quilt. New upload is done. I look forward to further feedback from you. Regards Mario On So, Jan 20, 2019 at 2:12 AM, Adam Borowski wrote: On Sat, Jan 19, 2019 at 10:21:42PM +0100, Mario Stephan wrote: * Package name: knowthelist Version : 2.3.1 dget -x https://mentors.debian.net/debian/pool/main/k/knowthelist/knowthelist_2.3.1.dsc May I ask why did you convert the package to native? * the upstream package is useful outside Debian * the upstream package _exists_ (ie, doesn't come from Debian) * the packaging hasn't been fully adapted to native Generally, only stuff like debhelper makes sense as native, even if you're upstream -- clear separation between upstream and packaging parts allows other people to make non-maintainer uploads that can be reasonably incorporated into your master repository. (I haven't looked at other changes yet.) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919819: RFS: knowthelist/2.3.1
On Sat, Jan 19, 2019 at 10:21:42PM +0100, Mario Stephan wrote: > * Package name: knowthelist > Version : 2.3.1 >dget -x > https://mentors.debian.net/debian/pool/main/k/knowthelist/knowthelist_2.3.1.dsc May I ask why did you convert the package to native? * the upstream package is useful outside Debian * the upstream package _exists_ (ie, doesn't come from Debian) * the packaging hasn't been fully adapted to native Generally, only stuff like debhelper makes sense as native, even if you're upstream -- clear separation between upstream and packaging parts allows other people to make non-maintainer uploads that can be reasonably incorporated into your master repository. (I haven't looked at other changes yet.) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919743: RFS: rumur/2019.01.12-1 [ITP]
On Fri, Jan 18, 2019 at 06:43:13PM -0800, Matthew Fernandez wrote: > * Package name: rumur > Version : 2019.01.12-1 > dget -x > https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2019.01.12-1.dsc > Changes since the last upload: > > Initial release. Closes #919220. The package is marked as "UNRELEASED" -- ie, marked as not meant for uploading. Generally, RFS bugs are requests for actual uploads, there's no need to file a bug if all you want is review of a WIP state. I guess the marking was left accidentally... The package fails to build: . In file included from /<>/librumur/src/parse.cc:10: /<>/librumur/include/rumur/scanner.h:6:12: fatal error: FlexLexer.h: No such file or directory #include ` This looks like missing build-dependency on libfl-dev. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]
On Sat, Jan 19, 2019 at 07:47:51AM +0800, Paul Wise wrote: > On Fri, Jan 18, 2019 at 11:51 PM Adam Borowski wrote: > > > I'm not entirely sure if enabling javascript is such a hot idea in a > > codebase that hardly sees maintenance these days. But it's up to you... > > Personally I think the users of terminal-based web browsers would be > very surprised and possibly upset that their browser suddenly supports > JavaScript. At minimum, I would suggest a NEWS.Debian entry about > this. The most ideal situation would be to leave it off by default but > have a command-line option to turn it on. I wouldn't be _this_ negative, but only if the defaults are reasonable (ie, javascript only from the first-party site, akin to Firefox with uMatrix in its default configuration). I don't know how good this implementation of Javascript is in practice -- previous attempt sucked -- but quite a large part of sites rely on that abomination to display meaningful contents. Thus, it might work adequately, only testing can show. It's up to Ahmed to decide -- this kind of decisions are what we have maintainers for (before users start spamming complaints :p). My remark was mostly about a project dormant for years -- or, with the fork, not established enough to be trusted for security matters -- not being able to provide reasonable support for something that's a notorious attack surface. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]
On Fri, Jan 18, 2019 at 07:42:08AM +0100, أحمد المحمودي wrote: > I am adopting elinks. Awesome! > Anyways, this upload is targetting experimental, as I have enabled > several features like Bittorrent and Javascript. I'm not entirely sure if enabling javascript is such a hot idea in a codebase that hardly sees maintenance these days. But it's up to you... > elinks (0.13~20190114-1) experimental; urgency=medium > dget -x > https://mentors.debian.net/debian/pool/main/e/elinks/elinks_0.13~20190114-1.dsc Alas, the package build-depends on libmozjs185-dev which has been removed in March... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#918497: RFS: arptables/0.0.4+snapshot20181021-1 - ARP table administration
On Sun, Jan 06, 2019 at 06:31:01PM +0100, Alberto Molina Coballes wrote: > * Package name: arptables >Version : 0.0.4+snapshot20181021-1 > * [2c7c7c6] New upstream version 0.0.4+snapshot20181021 > * [c6b2324] d/patches: Adapt the default patch to the latest upstream > version > * [3076713] arptables: introduce /sbin compatibility symlinks > * [4108b0d] arptables: introduce alternatives for /usr/sbin/arptables > (Closes: #916106) > * [f7b48be] d/control: bump std-version to 4.3.0 Hi! I'm afraid the package fails to remove: Removing arptables (0.0.4+snapshot20181021-1) ... dpkg-query: no packages found matching iptables dpkg: error processing package arptables (--remove): installed arptables package pre-removal script subprocess returned error exit status 1 Errors were encountered while processing: arptables E: Sub-process /usr/bin/dpkg returned an error code (1) It's run with "set -e", thus dies on "variable=$(false)". You may want to try various piuparts scenarios, and/or abuse chroots a bit, as such transitions are quite tricky to get right. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Hans 1 was born and raised in Johannesburg, then moved to Boston, ⣾⠁⢠⠒⠀⣿⡁ and has just became a naturalized citizen. Hans 2's grandparents ⢿⡄⠘⠷⠚⠋⠀ came from Melanesia to Düsseldorf, and he hasn't ever been outside ⠈⠳⣄ Germany until yesterday. Which one is an African-American?
Bug#917629: RFS: xhk/1.0-1
On Sat, Dec 29, 2018 at 10:59:35PM +0900, Kentaro Hayashi wrote:
> * Package name: xhk
> Version : 1.0-1
> Upstream Author : Kieran Bingham
> * URL : http://kieranbingham.co.uk/xhk
> * License : GPL-2.0+
> Section : x11
> It builds those binary packages:
>
> xhk - XLib halfkey implementation
> * Initial upload to Debian. (Closes: #917091)
The packaging seems all fine.
The man page is corrupted -- I see a few ANSI codes among the troffage,
the text seems doubled and misformatted. Also, the part about a Texinfo
manual seems weird as there are no info docs.
I couldn't manage to get the utility do anything. The debug output is:
[~]$ xhk -d
-- HalfKey Xorg Driver Utility 1.0 --
SetPriority call failed : -1
Process Priority set at 0
XOpenDisplay(":0.0")
XI Version 2.0
Device Virtual core XTEST keyboard (id: 5) is a slave keyboard
Device is attached to/paired with 3
Device Power Button (id: 6) is a slave keyboard
Device is attached to/paired with 3
Device SEMICO USB Keyboard System Control (id: 8) is a slave keyboard
Device is attached to/paired with 3
Device SEMICO USB Keyboard (id: 9) is a slave keyboard
Device is attached to/paired with 3
Device SEMICO USB Keyboard (id: 10) is a slave keyboard
Device is attached to/paired with 3
Device Yubico Yubikey 4 OTP+U2F+CCID (id: 20) is a slave keyboard
Device is attached to/paired with 3
Device C-Media Electronics Inc. USB PnP Sound Device (id: 7) is a slave
keyboard
Device is attached to/paired with 3
Device USB OPTICAL MOUSE Consumer Control (id: 15) is a slave keyboard
Device is attached to/paired with 3
Floating device ID 10
after which no further messages are given -- other than reactions to signals
which also produce nothing but a message (although obviously SIGKILL wins).
Am I holding it wrong?
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Hans 1 was born and raised in Johannesburg, then moved to Boston,
⣾⠁⢠⠒⠀⣿⡁ and has just became a naturalized citizen. Hans 2's grandparents
⢿⡄⠘⠷⠚⠋⠀ came from Melanesia to Düsseldorf, and he hasn't ever been outside
⠈⠳⣄ Germany until yesterday. Which one is an African-American?
Bug#917250: RFS: dwarves/1.12-1
On Mon, Dec 24, 2018 at 06:49:34PM +0100, Domenico Andreoli wrote: > I'm looking for a sponsor for this package: Hi! I assume you have a problem with your gpg key. > * Package name: dwarves-dfsg > Version : 1.12-1 > dwarves-dfsg (1.12-1) unstable; urgency=medium > > [ Domenico Andreoli ] > * New upstram release. Closes: #908563, #779809, #693096, > * Migrate to salsa.d.o and enable CI. Closes: #908564. > * Migrate to DEP-14. > * Drop patch DW_TAG_mutable_type (merged upstream). > * Refresh patch no_shared_no_ebl. > * Improve package description. Closes: #914527. > * Add test executing pahole on itself. > * Set debhelper compatibility level to 10. > * Start using dh_strip_nondeterminism. > > [ Helmut Grohne ] > * Let dh_auto_configure pass cross flags to cmake. Closes: #903506. I have no complaints other than what lintian says (yet?), but with so many warnings that are trivially fixable it'd be better to give it at least some heed. Improper debhelper versioning hurts backports, using a ssh URL for VCS- breaks QA pages, etc. On the other hand, if you insist because of wanting the new release in while you're not capable of caring for less important matters, please say so -- these are only warnings rather than show-stoppers. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916905: RFS: Jerry (Chess GUI) /3.1-0 -- looking for sponsor
On Fri, Dec 21, 2018 at 08:45:40PM +, Dominik Klein wrote: > thanks very much for your feedback. > > I've filed an ITP under #917027. > > Moreover I've > - changed the icon to a png, since the problem is likely that not all > window manager are able to display .ico > - changed changelog to mark for unstable > - added regexp to track new releases via the watch-file > - modified the copyright file to clarify for all files who owns the > copyright and which license > - The .bin is polyglot opening book. It's format is openly documented, > e.g. here http://hardy.uhasselt.be/Toga/book_format.html > > I also changed the changelog > https://github.com/asdfjkl/jerry/releases/tag/v3.1.0 to automatically > close #917027, i.e. if feedback for the ITP is positive and a sponsor > would come forward, the current package might be suitable for inclusion... Awesome. There's one laughably small nit: the control file says: Maintainer: Dominik Klein while the changelog: -- Dominik Klein Fri, 21 Dec 2018 10:15:05 +0100 with different capitalization of the email address. For many mail servers, the user field is case-sentisive, thus tools in general have to understand it this way. Yet while it's just a detail, it would spook at least some of the archive tools into thinking you're not the maintainer. It'd be best to get this right before the first upload. Other stuff that would be nice to improve but are not blockers: Tthe icon still doesn't work for me (xfce). The copyright file would be a lot more readable if you placed you and Karl into a "Files: *" stanza. If two stanzas match the same file, only the later one applies, allowing overriding a more global match. Also, while missing a copyright holder is an error (not for a reasonable person, but lawyers are not reasonable, thus the ftpmasters need to be strict), being too generous is benign. Thus, having both you and Karl for the majority of files would allow coalescing all those entries into a single one, leaving nothing but icons, pieces and books. Likewise, the .install file could be made more readable using wildcards. Of course, this is not mandatory, but would be nice to have. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916933: RFS: libgsm/1.0.18-1 [ITA]
On Fri, Dec 21, 2018 at 05:23:19AM +0100, Adam Borowski wrote: > On Thu, Dec 20, 2018 at 01:14:01PM -0800, Felix Lechner wrote: > > On Thu, Dec 20, 2018 at 12:10 PM Adam Borowski wrote: > > > audio_gsm.c:29:11: fatal error: GSM610/gsm.h: No such file or directory > > > # include "GSM610/gsm.h" > > > > Thank you for taking a look. The errors you found are due to confusion > > about the include path. > > Full results of the rebuilds: > > freerdp2_amd64.build:Status: attempted > gmerlin-avdecoder_amd64.build:Status: attempted > mediastreamer2_amd64.build:Status: attempted > twinkle_amd64.build:Status: attempted > > The previous version shipped gsm.h in two locations: It was in > > /usr/include, and again in /usr/include/gsm---together with a bunch of > > probably private headers that gave rise to #882176. > > Either way, I uploaded a new version to Mentors that again ships the > > same file in both locations. Would you please try again? Hi; the package has been for some reason removed from mentors, despite no one uploading anything. Could you tell me if there's a version you'd want in? I'd be happy with either a hard break or a compat link -- it's up to you and your upstream wrt what is preferred. I believe we know enough; thanks for your work so far. So please give me something to re-test and upload. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916933: RFS: libgsm/1.0.18-1 [ITA]
On Thu, Dec 20, 2018 at 01:14:01PM -0800, Felix Lechner wrote: > On Thu, Dec 20, 2018 at 12:10 PM Adam Borowski wrote: > > > > audio_gsm.c:29:11: fatal error: GSM610/gsm.h: No such file or directory > > # include "GSM610/gsm.h" > > Thank you for taking a look. The errors you found are due to confusion > about the include path. Full results of the rebuilds: asterisk_amd64.build:Status: given-back baresip_amd64.build:Status: successful blender_amd64.build:Status: successful ffmpeg_amd64.build:Status: successful flightgear_amd64.build:Status: successful freerdp2_amd64.build:Status: attempted gmerlin-avdecoder_amd64.build:Status: attempted gnuradio_amd64.build:Status: successful gst-plugins-bad1.0_amd64.build:Status: successful kino_amd64.build:Status: successful linphone_amd64.build:Status: successful mangler_amd64.build:Status: given-back mediastreamer2_amd64.build:Status: attempted mplayer_amd64.build:Status: successful pjproject_amd64.build:Status: successful ring_amd64.build:Status: successful rplay_amd64.build:Status: successful sipxtapi_amd64.build:Status: successful sox_amd64.build:Status: successful svxlink_amd64.build:Status: successful swh-lv2_amd64.build:Status: successful swh-plugins_amd64.build:Status: successful twinkle_amd64.build:Status: attempted vlc_amd64.build:Status: successful wine-development_amd64.build:Status: given-back wine_amd64.build:Status: given-back http://ix.io/1wu4 http://ix.io/1wu3 Breakage looks same. > The previous version shipped gsm.h in two locations: It was in > /usr/include, and again in /usr/include/gsm---together with a bunch of > probably private headers that gave rise to #882176. When trying to fix > the latter, I settled for /usr/include/gsm.h since the file appeared > to be the sole header (although the reporting party's patch kept it in > /usr/include/gsm). As a side note, I had seen #include in > a package of mine but thought it was conditional on autoconf; some of > the packages you tested may also look for the header in both places. > Either way, I uploaded a new version to Mentors that again ships the > same file in both locations. Would you please try again? > > If you feel strongly about it, we can also file bugs against packages > that use the library but do not look for the header in your favorite > location. I have no preference. I'm slightly biased towards making a hard break rather than a compat hack that'd linger -- the former is more immediate work but is far cleaner. On the other hand, packages might silently _succeed_ to build while skipping gsm support, and there's little time to find such bugs before Buster's freeze. Do you happen to know what upstream does? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916933: RFS: libgsm/1.0.18-1 [ITA]
On Thu, Dec 20, 2018 at 08:36:07AM -0800, Felix Lechner wrote: > * Package name: libgsm >Version : 1.0.18-1 > dget -x > https://mentors.debian.net/debian/pool/main/libg/libgsm/libgsm_1.0.18-1.dsc > Changes since the last upload: > > * New upstream version > * New maintainer (Closes: #891760) > * Only ship gsm.h (Closes: #882176) > * Migrated rules to dh(1) > * Updated patches (most of 05 was accepted upstream) > * Bumped shared object version in 01 patch > * Made copyright file dep5 machine readable > * Added README.Debian about (non-)patent status > * Updated upstream URL in watch file > * Turned on migration to automatic debug packages > * Removed old debug package from control > * Removed libgsm1-dbg.install > * Added homepage field to control > * Removed trailing whitespace from changelog > * Removed trailing whitespace from control > * Removed ancient Conflicts: from control > * Corrected two misspellings in man via 06 patch > * Removed duplicate binary control field for section > * Set Build-Depends: debhelper (>= 11) > * Set compat to 11 > * Updated Standards-Version: 4.2.1 Alas, while your changes to the package itself look good, at least some of reverse-depends don't build anymore. So far, I tried the following: asterisk_amd64.build:Status: given-back baresip_amd64.build:Status: successful blender_amd64.build:Status: successful ffmpeg_amd64.build:Status: successful flightgear_amd64.build:Status: successful freerdp2_amd64.build:Status: attempted gmerlin-avdecoder_amd64.build:Status: attempted gnuradio_amd64.build:Status: successful gst-plugins-bad1.0_amd64.build:Status: successful kino_amd64.build:Status: successful freerdp2: http://ix.io/1wsw gmerlin-avdecoder: http://ix.io/1wsx CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find GSM (missing: GSM_INCLUDE_DIR) audio_gsm.c:29:11: fatal error: GSM610/gsm.h: No such file or directory # include "GSM610/gsm.h" Thus, you need to investigate and decide what to do. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916905: RFS: Jerry (Chess GUI) /3.1-0 -- looking for sponsor
On Thu, Dec 20, 2018 at 08:33:16AM +, Dominik Klein wrote: > * Package name: jerry >Version : 3.1-0 >Upstream Author : Dominik Klein / dominik.kl...@outlook.com > * URL : https://github.com/asdfjkl/jerry > It builds those binary packages: > >Jerry - a chess program / GUI > https://github.com/asdfjkl/jerry/releases/tag/v31 Hi! Functionally, the program works nearly fine: only nit I noticed is runtime icon missing. You'd need to file an ITP bug, wait a bit for potential responses, and close it via the changelog, Also, changelog for packages you request an upload for should be marked for unstable rather than UNRELEASED -- that's a marking meant to block packages in a state not yet meant to be uploaded. The watch file should point at a wildcard that will match future releases; you have a static URL for the current tarball. The copyright file needs work: * the vast majority of program sources include Karl Josef Klein * images have external authors * the "book" The latter also appears to lack any sources. How does one build/edit it? It's in some ".bin" format that appears to be a binary blob -- that would be bad except that the code refers to it as "Polyglot". How does one deal with such Polyglot files? You don't need to list binary files in debian/source/include-binaries; that's only for stuff that's changed during the packaging. Anything within the upstream tarball is fine -- .jpg images are also binary, for example. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916854: RFS: duperemove/0.11.1-1
On Wed, Dec 19, 2018 at 02:03:23PM +, Peter Zahradnik wrote: > * Package name: duperemove >Version : 0.11.1-1 > dget -x > https://mentors.debian.net/debian/pool/main/d/duperemove/duperemove_0.11.1-1.dsc > Changes since the last upload: > > * Update Standards-Version > * Bump debian/compat to 11 > * Update debian/watch > * Fix insecure-copyright-format-uri > * Move Vcs from github.com to salsa.debian.org > * Add Enhances: btrfs-progs (Closes: #854361) > * Bump to upstream v0.11.1 > * Fix FTBFS for mips/mipsel arch (Closes: #851261) > * Fix missing include in dbfile.c / FTBFS (Closes: #916104) Build-Depends: ..., libatomic1 [mipsel] _Build_ depending on a runtime library, rather than its -dev, sounds odd. Also, why is this dependency limited to mipsel only, when the FTBFS applies to at least six architectures? shlibdeps will do this for you. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#916285: RFS: extsmail/2.2-1 -- enables the robust sending of e-mail to external commands
On Wed, Dec 12, 2018 at 05:38:01PM +0100, Olivier Girondel wrote: > * Package name: extsmail >Version : 2.2-1 > https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.2-1.dsc > > Changes since the last upload: > > * New upstream release 2.2. (Closes: #748739) > * debian/compat: Upgrade to 11. > * debian/control: Priority: optional. > * debian/control: Vcs-Browser: https://github.com/ltratt/extsmail. > * debian/control: Vcs-Git: https://github.com/ltratt/extsmail.git. > * debian/control: Build-Depends: Remove dh-autoreconf. > * debian/control: Build-Depends: Update debhelper (>= 11). > * debian/control: Update Homepage. > * debian/control: Standards-Version: 4.2.1. > * debian/copyright: Update copyright years. > * debian/copyright: Update Source URL. > * debian/copyright: Use secure copyright format URI. > * debian/rules: Remove --with autoreconf. > * debian/tests/control: Added. > * debian/watch: version=4. > * debian/watch: Use secure URI. Alas, it doesn't build: http://ix.io/1vVp common.c:37:10: fatal error: conf_parser.tab.h: No such file or directory #include "conf_parser.tab.h" ^~~ (I didn't review further.) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Re: Question about a file inside debian directory
On Fri, Dec 07, 2018 at 11:35:52AM +0100, Jose G. López wrote: > Dear mentors, > > Is it permitted by the Debian Policy to have a personalized makefile inside > debian > directory and call it from rules file? Or I should patch the upstream's > makefile completly? There's also a third way: as debian/rules is a makefile, it can do whatever you want. Patching the upstream Makefile is good when you want to amend or change some issue, not when you replace it completely. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Bug#915718: RFS: arno-iptables-firewall/2.0.3-1 [ITA]
On Thu, Dec 06, 2018 at 12:41:55PM +0100, Sven Geuer wrote: > * Package name: arno-iptables-firewall >Version : 2.0.3-1 > Changes since the last upload: > > * New upstream release. > (Closes: #824684, #862856, #886991, #898770, #913089) > * New maintainer. > (Closes: #886951) > * Update Standards-Version to 4.2.1; no changes necessary. > * Update debhelper compatibility level to 11. > * Clean up Depends. > * Update debian/copyright. > * Update debian/watch. > * Make use of dh_installlogrotate and simulate non-existing > dh_installrsyslog > - Move logrotate.d.conf to arno-iptables-firewall.logrotate > - Move rsyslog.d.conf to arno-iptables-firewall.rsyslog > - Update debian/rules > * Switch from System-V style init scripts to systemd No, this is no good. You can _add_ integration for a specific additional rc system if you have a good reason (this is usually merely doubling the effort) but the Policy is clear: # However, any package integrating with other init systems must also be # backwards-compatible with sysvinit by providing a SysV-style init script # with the same name as and equivalent functionality to any init-specific # job, as this is the only start-up configuration method guaranteed to be # supported by all init implementations. An init script works with systemd, sysvinit, openrc, runit, etc. > - Suppress installation of /etc/init.d/arno-iptables-firewall > - Introduce debian/prerm > - Update debian/postrm to not use invoke-rc.d or update-rc.d. > - Update debian/preinst to remove System-V style init script links. > - Update debian/postinst to use deb-systemd-invoke instead > of invoke-rc.d or update-rc.d. > - Update debian/arno-iptables-firewall.logrotate to use systemctl > instead of invoke-rc.d. > - Update debian/template and debian/po/* to propose a call to > systemctl instead of invoke-rc.d. > - Update debian/rules > * Bugfix: Convert debian/po/fr.po and sv.po from latin1 to utf8 Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Re: Request for peer review of clamav-unofficial-sigs
On Thu, Nov 22, 2018 at 03:07:36PM +0800, Paul Wise wrote: > I'm not sure how you want to use git for packaging. I used gbp and > pristine-tar. These days I would personally remove all upstream code > from git and store only the debian/ directory. A more popular option > is to use the DEP14 standard for this. I'm not sure how the clamav > team do things these days. To the contrary, I would heartily recommend keeping upstream code in git, and burying gbp far away from any of your machines. Being able to use git's power to merge/cherry-pick patches with upstream both ways is awesome. Quilt makes a really poor VCS, and is really fit only for old-style tarballs. These days, most upstreams don't use autotool-like workflows and the tarball is merely a snapshot of a tree pointed by a git tag. This applies to clamav-unofficial-sigs as well. But then, the set of workflows in Debian is anything but not diverse. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Bug#914174: RFS: easy-rsa [ITA]
On Wed, Nov 21, 2018 at 02:27:17PM +0100, Michele Orru wrote:
> On 11/21/18 6:45 AM, Adam Borowski wrote:
> > On Tue, Nov 20, 2018 at 08:45:09AM +0100, Michele Orrù wrote:
> > > * Package name: easy-rsa
> > >Version : 3.0.5-1
> >
> > > https://salsa.debian.org/maker-guest/easy-rsa/
>
> thanks a lot for your prompt response!
>
> I really apologise for the silly mistake on dh_installdocs: it should be
> fixed now, together with the other issues you reported.
>
> I pushed the modifications on salsa, and uploaded the package on
> mentors.debian.net
Awesome.
There's one more issue that's better to fix before uploading:
Maintainer: Debian QA Group
-- you'd want to update this.
> I also took the liberty of removing: ${shlibs:Depends} from the list of
> dependencies. They were empty, plus easy-rsa is just a shell script that
> relies solely on openssl, which is explicit in the package. Hope that's
> fine.
It's generally better to keep this even if unused as an empty var that's
referenced is ok but a non-empty var that's missing would cause problems.
This might happen if you one day need to include a bit of compiled code
in the package. But then, for now there's no difference either way.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
Bug#914174: RFS: easy-rsa [ITA]
On Tue, Nov 20, 2018 at 08:45:09AM +0100, Michele Orrù wrote: > * Package name: easy-rsa > Version : 3.0.5-1 >https://salsa.debian.org/maker-guest/easy-rsa/ > > Changes since the last upload: > > * New upstream version 3.0.5 > * Updated d/README.Debian Hi! The package's changelog is set as UNRELEASED, which marks the current state as not meant for upload. The changelog doesn't also list your takeover. The package fails to build: dh_installdocs: Cannot find (any matches for) "debian/README-Debian-much-features-such-wow" (tried in ., debian/tmp) (the file is deleted in the packaging now) Rules-Require-Root should be "Requires". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Re: Build dependency
On Mon, Oct 29, 2018 at 01:09:54AM +0100, gregor herrmann wrote: > On Mon, 29 Oct 2018 00:25:35 +0100, Leopold Palomo-Avellaneda wrote: > > > I know that > > apt-cache rdepends packageX > > show me the list of the packages that depends of packageX. But, how can > > I obtain the list of packages that build-depends of packageX? > > reverse-depends -b packageX > > (reverse-depends is in ubuntu-dev-tools) build-rdeps packageX (needs just regular devscripts, although you want dose-extra to handle B-Dep on Dep chains) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄ together with silk (judging by today's amber stalls).
Bug#912313: RFS: tlf/1.3.1-1
On Tue, Oct 30, 2018 at 09:09:27AM +0100, Ervin Hegedüs wrote: > * Package name: tlf >Version : 1.3.1-1 > Changes since the last upload: > > * Team upload. > * New upstream release > * Bump compat to 11 > * Bump Standards-Version to 4.2.1 > * Added DH_VERBOSE=1 in d/rules > * Modified spelling-fixes.patch, some modifications had been > merged to upstream > * Added libcmocka-dev to dependency list in d/control > * Removed trailing whitespaces from d/control > * Removed dh-autoreconf and autotools-dev packages > (not required since compat lev 10) > * Replaced Priority from extra to optional diff -Nru tlf-1.3.0/debian/source/include-binaries tlf-1.3.1/debian/source/include-binaries --- tlf-1.3.0/debian/source/include-binaries1970-01-01 01:00:00.0 +0100 +++ tlf-1.3.1/debian/source/include-binaries2018-10-29 22:38:06.0 +0100 @@ -0,0 +1,145 @@ +src/addarea.o +src/addcall.o +src/addmult.o +src/addpfx.o +src/addspot.o +src/audio.o +src/autocq.o +src/background_process.o +src/bandmap.o +src/bands.o +src/cabrillo_utils.o +src/calledit.o +src/callinput.o +src/changefreq.o +src/changepars.o +src/checklogfile.o +src/checkparameters.o +src/checkqtclogfile.o +src/cleanup.o +src/clear_display.o +src/clusterinfo.o +src/cw_utils.o +src/deleteqso.o +src/displayit.o +src/dxcc.o +src/edit_last.o +src/editlog.o +src/fldigixmlrpc.o +src/focm.o +src/freq_display.o +src/genqtclist.o +src/get_time.o +src/getctydata.o +src/getexchange.o +src/getmessages.o +src/getpx.o +src/getsummary.o +src/gettxinfo.o +src/getwwv.o +src/grabspot.o +src/initial_exchange.o +src/keyer.o +src/lancode.o +src/last10.o +src/listmessages.o +src/locator2longlat.o +src/log_to_disk.o +src/logit.o +src/logview.o +src/main.o +src/makelogline.o +src/messagechange.o +src/muf.o +src/netkeyer.o +src/nicebox.o +src/note.o +src/paccdx.o +src/parse_logcfg.o +src/prevqso.o +src/printcall.o +src/qrb.o +src/qsonr_to_str.o +src/qtc_log.o +src/qtcutil.o +src/qtcwin.o +src/readcabrillo.o +src/readcalls.o +src/readctydata.o +src/readqtccalls.o +src/recall_exchange.o +src/rtty.o +src/rules.o +src/score.o +src/scroll_log.o +src/searchcallarray.o +src/searchlog.o +src/sendbuf.o +src/sendqrg.o +src/sendspcall.o +src/set_tone.o +src/setcontest.o +src/setparameters.o +src/show_help.o +src/showinfo.o +src/showpxmap.o +src/showscore.o +src/showzones.o +src/sockserv.o +src/speedupndown.o +src/splitscreen.o +src/startmsg.o +src/stoptx.o +src/store_qso.o +src/sunup.o +src/time_update.o +src/tlf +src/ui_utils.o +src/write_keyer.o +src/writecabrillo.o +src/writeparas.o +src/zone_nr.o +test/data.o +test/functions.o +test/run_addcall +test/run_addcall.o +test/run_addmult +test/run_addmult.o +test/run_bands +test/run_bands.o +test/run_cabrillo +test/run_cabrillo.o +test/run_cw_utils +test/run_cw_utils.o +test/run_dxcc +test/run_dxcc.o +test/run_getctydata +test/run_getctydata.o +test/run_initial_exchange +test/run_initial_exchange.o +test/run_locator2longlat +test/run_locator2longlat.o +test/run_prefix +test/run_prefix.o +test/run_score +test/run_score.o +test/run_searchlog +test/run_searchlog.o +test/run_sendbuf +test/run_sendbuf.o +test/run_zone_nr +test/run_zone_nr.o +test/test_addcall.o +test/test_addmult.o +test/test_bands.o +test/test_cabrillo.o +test/test_cw_utils.o +test/test_dxcc.o +test/test_getctydata.o +test/test_initial_exchange.o +test/test_locator2longlat.o +test/test_prefix.o +test/test_score.o +test/test_searchlog.o +test/test_sendbuf.o +test/test_zone_nr.o I have a feeling you did not quite intend this... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄ together with silk (judging by today's amber stalls).
Bug#910018: RFS: hoteldruid/2.2.4-1
On Mon, Oct 01, 2018 at 02:24:52PM +0200, Marco M. F. De Santis wrote: > * Package name: hoteldruid > Version : 2.2.4-1 > Changes since the last upload: > > * New upstream release. > * debian/control: updated Standards-Version > * debian/control: added suggest on sensible-utils for > hoteldruid-launcher previously included in debianutils I'm pretty sure "hoteldruid-launcher" has never been included in either sensible-utils nor debianutils. Care to clarify? Besides, both packages are >= priority:important, thus a stronger dependency has no downsides (as hoteldruid is not something that cares about cutting every little bit of bloat from a container it runs in). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Bug#909701: RFS: wxmaxima/18.10.1-1
On Thu, Sep 27, 2018 at 03:43:19AM +0200, Gunter Königsmann wrote: > * Package name: wxmaxima > Version : 18.10.1-1 > Changes since the last upload: > > * A new upstream version that comes with many bugfixes, features and > performance improvements. > * Updated the Homepage and the main upstream contact of the program. > * Dropped all the patches as they are incorporated in the new upstream > release. I'm afraid that the desktop file got converted to Windows line endings, which breaks some consumers. A lot of other files also suffered the same, this is harmless in the source but might harm other functionality as well. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Bug#909117: RFS: libmd5-rfc/0.0+20020413-1 [ITP]
On Wed, Sep 19, 2018 at 12:37:19AM +0800, Yangfl wrote: > * Package name: libmd5-rfc >Version : 0.0+20020413 >Upstream Author : Aladdin Enterprises > * URL : https://sourceforge.net/projects/libmd5-rfc/ > libmd5-rfc-dev - RFC1321-based (RSA-free) MD5 library - development headers > libmd5-rfc0 - RFC1321-based (RSA-free) MD5 library > * Initial release (Closes: #909116) The package technically looks good (one nitpick: rm debian/clean, but this is too minor to really bother). I'm ready to upload at any time. But, with md5 thoroughly broken, do you have any reason to include this library? It's unfit for cryptographic purposes, and there exist much faster hashes for non-crypto uses. Thus, I'd recommend introducing this package only if you have some actual use -- such as another package wanting to depend on it. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Bug#900579: RFS: libminini/1.2.a-1 [ITP]
On Mon, Sep 17, 2018 at 12:01:56PM +0800, Yangfl wrote: > Hmm seems like a new symbol in gcc8... anyway fixed and reuploaded. > Lintian clean and sbuild amd54/i386 passed. Thanks, the packaging seems to work well now. Alas, this can't be said about copyright stuff. I see that "NOTICE" includes Steven Van Ingelgem and Luca Bassanello as contributors, and at least the former is above the threshold of copyrightability (a rule of thumb says ~10 lines are a reasonable boundary between a trivial vs non-trivial contribution). The documentation bears a copyright marking of CompuPhase -- I get the impression that CompuPhase is the author's company (no idea if employer or owned), but legally that's distinct. (Yeah, all this legal crap is annoying, and a waste of time that could be spent coding -- but we don't get to choose the law. :( ) I also don't see any source for the PDF documentation. This makes it impossible for anyone to edit it. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
On Mon, Sep 17, 2018 at 09:30:27AM +0300, Andrius Merkys wrote:
> On 09/16/2018 12:31 AM, Adam Borowski wrote:
> > 2. The package fails to build:
> >
> > ! LaTeX Error: File `ulem.sty' not found.
>
> I have missed one of texlive-* packages. Added now.
>
> Would you mind to pull and build it again?
Alas, it fails again, this time with:
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty))
! LaTeX Error: File `subfigure.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
l.26 \usepackage
{dcolumn}^^M
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on w90pov.log.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
On Mon, Jul 16, 2018 at 03:44:21PM +0300, Andrius Merkys wrote:
> * Package name: wannier90
> Version : 2.1.0
> Upstream Author : Mostofi et al.
> * URL : http://www.wannier.org
> * License : GPL-2+
> Programming Lang: Fortran
> Description : maximally localized Wannier functions
>
> It builds these binary packages:
> wannier90- Maximally Localized Wannier Functions - executables
> libwannier90-dev - Maximally Localized Wannier Functions - development files
While I cannot adequately review this package, and thus won't sponsor it,
here's a couple of problems:
1. The copyright file claims GPL-2+ with no authors outside "2017 Wannier
Developers' Group", yet I see at least test-suite/testcode being:
"Copyright (c) 2012 by James Spencer", license: BSD.
2. The package fails to build:
! LaTeX Error: File `ulem.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
l.19 \newcommand
\tent[1]{\textcolor{red}{#1}} % for tentative changes^^M
! ==> Fatal error occurred, no output PDF file produced!
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Bug#903845: RFS: lv2bm/1.0-1 [ITP] -- LV2 audio plugin tester with uses in autopktest
On Sun, Jul 15, 2018 at 08:18:32PM +0200, Víctor Cuadrado Juan wrote: > * Package name: lv2bm >Version : 1.0-1 > * URL : https://github.com/moddevices/lv2bm > Description: Benchmark CLI tool for LV2 plugins > Features: > - Allows one to select which LV2 URIs to test > - Uses minimum, maximum and default control values to run the plugins > - Has a full test mode which check all combinations for discrete > controls > - Can be used along with valgrind to detect plugin memory issues > > In addition to shipping /usr/bin/lv2bm, the package also ships > /usr/bin/lv2-plugin_autopkgtest, a script that uses lv2bm to smoke-test > installed LV2 plugins. > https://salsa.debian.org/multimedia-team/lv2bm I don't have a clue what this is about, but as it's at least not node.js or a python library, I took a look... But alas, any use seems to fail: [~/tmp/pkg]$ lv2bm http://portalmod.com/plugins/caps/CabinetIV Segmentation fault (core dumped) [~/tmp/pkg]SEGV$ lv2bm http://lv2plug.in/plugins/eg-amp Segmentation fault (core dumped) [~/tmp/pkg]SEGV$ lv2bm --full-test http://lv2plug.in/plugins/eg-amp+ Segmentation fault (core dumped) [~/tmp/pkg]SEGV$ lv2bm --full-test http://lv2plug.in/plugins/eg-amp Segmentation fault (core dumped) [~/tmp/pkg]SEGV$ lv2bm fdlkfsdfdg error: attempt to map invalid URI `fdlkfsdfdg' Segmentation fault (core dumped) [~/tmp/pkg]SEGV$ lv2bm http://example.org Segmentation fault (core dumped) [~/tmp/pkg]SEGV$ Meow! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Bug#900579: RFS: libminini/1.2.a-1 [ITP]
On Fri, Jun 01, 2018 at 11:24:39PM +0800, Yangfl wrote: > * Package name: libminini >Version : 1.2.a-1 >Upstream Author : Thiadmer Riemersma > * URL : https://www.compuphase.com/minini.htm > > It builds those binary packages: > > libminini-dev - minimal INI file parser - development headers > libminini1 - minimal INI file parser > dget -x > https://mentors.debian.net/debian/pool/main/libm/libminini/libminini_1.2.a-1.dsc Sorry for taking so long; there's too many RFSes left rotting... symbols file produces: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Ba se 1.2.a-1 which has a Debian revision. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#908163: RFS: wfrench/1.2.4
On Thu, Sep 06, 2018 at 10:10:21PM +0200, guillaume pernot wrote: > * Package name: wfrench >Version : 1.2.4 > Changes since the last upload: > > * New maintainer (Closes: #858663) > * Added verbs from verbiste (Closes: #329474) > * debian/control: > - Bumped Standards-Version to 4.2.1. Hi! Not mentioned in the changelog is turning the package into format: native. That's pretty certainly not the right thing to do: "native" packages are those which make no sense outside Debian, which doesn't apply to a word list. Even if there's no other upstream, you can take over and generate such a tarball yourself -- but that's still something some other distro may want. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Bug#907803: closed by Adam Borowski (Re: Bug#907803: RFS: udfclient/0.8.9-1)
On Sun, Sep 02, 2018 at 11:37:43PM +0200, Pali Rohár wrote: > On Sunday 02 September 2018 21:33:03 Debian Bug Tracking System wrote: > > Nitpick: these warnings are trivial to fix: > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause > > (paragraph at line 37) > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-2-clause > > (paragraph at line 62) > > W: udfclient source: dep5-copyright-license-name-not-unique bsd-4-clause > > (paragraph at line 149) > > so it'd be nice if you could get rid of them in the future. Not an > > important thing, but less noise is good. > > How to fix this problem? There are basically 3 different texts of BSD > licenses in source files. You need to give them unique names. If the body of a license is different, so must be its short name. Yeah, that's somewhat unpleasant, but the reason is obvious. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Re: testcase requires fuse to be loaded
On Mon, Aug 27, 2018 at 03:50:05PM +0800, Yanhao Mo wrote: > Dear mentors, > > I am packaging a fuse file system. It called securfs [1][2]. It has some > test cases under test directory, and these test cases require fuse kernel > module to be loaded. My system has this module loaded. But when I > packaging securfs by gpb && cowbuilder, I still get the following error. > > > fuse: device not found, try 'modprobe fuse' first > > I guess the build environment cannot access /dev/fuse device is the > reason for this. But I cannot find a way to work around. So I have to > disable all test cases to let the build process continue. I don't think you can reliably run such tests during build -- builds nearly exclusively run under fakeroot, which is not enough to create missing device nodes. Installing build-deps uses real root, but I don't think there's a good way to ensure the device nodes are properly setup in the chroot. On the other hand, it's a good match for autopkgtest -- you can then specify demands such as needs-root, and if that's not enough, isolation-container or isolation-machine. 喵! -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
Bug#907275: RFS: debian-timeline/39+nmu1
On Sat, Aug 25, 2018 at 09:11:51PM +0200, Birger Schacht wrote: > There was a short discussion about the status of the `debian-timeline` > package on the debian-publicity list [0], so i figured i could take a > look and upload a current version of the package. I'm not sure if it > really should be a NMU, but i'm happy to fix that if thats not adequate. I don't believe this package should be NMUed (other than for a technical RC bug or such). On the other hand, marking it as a "Team upload" would be very appropriate. I'm not aware whether the Debian-Publicity team keeps a formal list of members, but if there's one, you may consider getting onto it. Many teams use Salsa permissions as a technical implementation of such a list. (Responding with a -mentors hat on, I'm not involved in any way with the Publicity team. Heck, I'm the kind of guy whose workmates don't let talk to any customers. :p) > [0] https://lists.debian.org/debian-publicity/2018/08/msg00019.html Larjona: IIRC because of a prior issue when someone was both a DM and a DN, and some tool not being able to handle a person being in two keyrings, DAK got hacked to make DN imply DM rights. Thus, if I'm correct, there's no need to implement any special handling. So you have no excuse for not updating the package as often as you'd like. :) > I am looking for a sponsor for my package "debian-timeline" > > * Package name: debian-timeline >Version : 39+nmu1 > Changes since the last upload: > * Non-maintainer upload. > > [Cédric Boutillier] > * Publication of Debian 8.10 and 9.3 > > [Jean-Pierre Giraud] > * Git repo is now in salsa > > [Chris Lamb] > * Move under the care of the Publicity Team > > [Donald Norwood] > * Publication of Debian 8.11 > > [Ana Guerrero López] > * Add DebConf 18 > * Add `make mpublish` command > > [Laura Arjona Reina] > * Remove Chris Lamb from uploaders > > [Birger Schacht] > * Bump standards version > * add Mini-DebConf Hamburg With so many contributors to the package, it's definitely not something for a random sponsor to review/upload. Thus, a RFS for it should go through some other channels. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Re: RFS: hepmc -- [RC] on behalf of multiarch-support removal
On Wed, Aug 15, 2018 at 02:51:45AM +, Lumin wrote: > Can anybody sponsor my team upload for "hepmc"? Thanks. > > https://salsa.debian.org/science-team/hepmc > - commit: cb8aa811bb7e8b5be46107ca9992a5ad58df73cb > - upload: unstable > hepmc (2.06.09-2) unstable; urgency=medium > > * Team Upload. > * Replace B-D-I:texlive-math-extra with texlive,texlive-science. > The original one no longer exists in archive. (Closes: #867090) > * Upgrade from Debhelper compat level 7 to level 11. > * Overhaul debian/rules in debhelper 11 style. > * Patch src/IO_AsciiParticles.cc to amend floating point format. > The FTBFS is due to floatpoint printing format mismatch during test, > triggered by GCC-5's change. (+ gcc-5plus.patch) (Closes: #777901) > * Deprecate DM-Upload-Allowed field. > * Strip useless build-dependencies. > * Annotate Upstream-Git URI in control. > * Point Vcs-* fields to Salsa due to Alioth deprecation. 'ere you go. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job, ⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato ⢿⡄⠘⠷⠚⠋⠀ pancakes. Then the Polish couldn't decide which of his ⠈⠳⣄ adjectives to use for the dish's name.
Bug#905791: RFS: swapspace/1.14-1 [ITA]
On Thu, Aug 09, 2018 at 12:43:22PM -0400, Jacob Adams wrote: > * Package name: swapspace >Version : 1.14-1 > swapspace (1.14-1) unstable; urgency=medium > > * New maintainer. (Closes: #725821) > * Redo packaging with debhelper 11 (Closes: #866272) > * Account for memory allocated to /dev/shm (Closes: #691128) > * Removed swapd conflict as swapd was removed from Debian in 2010 > * Fix minor manual page typo Hi! This is bad: Files in second .deb but not in first - -rw-r--r-- root/root /lib/systemd/system/swapspace.service [...] Files in first .deb but not in second - [...] -rwxr-xr-x root/root /etc/init.d/swapspace And this is not even an upstream change, but a regression in the packaging: --- swapspace-1.10/debian/swapspace.init2018-08-09 20:58:32.0 +0200 +++ swapspace-1.14/debian/swapspace.init1970-01-01 01:00:00.0 +0100 While some people may decide to use systemd, your change breaks the package for everyone else. That shouldn't be done without a very good reason. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job, ⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato ⢿⡄⠘⠷⠚⠋⠀ pancakes. Then the Polish couldn't decide which of his ⠈⠳⣄ adjectives to use for the dish's name.
Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)
On Thu, Aug 09, 2018 at 10:16:17AM +, Lumin wrote: > * Package name: mkl-dnn >Version : 0.15+git20180803.3f58c16-1 >Upstream Author : intel Alas, the build flags use -march=native -mtune=native which is a big no-no. The first makes the package crash on any processor lacking an extension that was present on the build machine and was used by the compiler; unless some kind of runtime detection is used, packages are allowed only the baseline ISA for the architecture. As for -mtune=native, it makes the package build unreproducibly, differing based on where it was compiled. The second problem is that in the testsuite, test_convolution_format_any fails (0/5 sub-tests). This might be related to my machine being: vendor_id : AuthenticAMD model name : AMD Phenom(tm) II X6 1055T Processor Log of the FTBFS attached. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job, ⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato ⢿⡄⠘⠷⠚⠋⠀ pancakes. Then the Polish couldn't decide which of his ⠈⠳⣄ adjectives to use for the dish's name. mkl-dnn_0.15+git20180803.3f58c16-1_amd64.build.xz Description: application/xz
Bug#904408: RFS: pidgin-gmchess/0.02-2 [QA]
On Tue, Jul 24, 2018 at 01:35:37AM -0300, Paulo Henrique de Lima Santana wrote: > Please **don't sponsor and upload** this package because my AM (Mike Gabriel) > will review it. I guess the reason you posted it here is that you still want some external review, right? > * Package name: pidgin-gmchess >Version : 0.02-2 > https://mentors.debian.net/debian/pool/main/p/pidgin-gmchess/pidgin-gmchess_0.02-2.dsc Why would you introduce a bogus watch file instead of simply providing none? If the package doesn't have an upstream anymore, there's nothing to watch. Adding requests to some fake URL that reports no news sounds counterproductive to me. I see no other problems. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#904543: RFS: deepin-screen-recorder/2.7.5-1
On Wed, Jul 25, 2018 at 11:10:55AM +0800, Yanhao Mo wrote: > > * Package name: deepin-screen-recorder >Version : 2.7.5-1 > dget -x > https://mentors.debian.net/debian/pool/main/d/deepin-screen-recorder/deepin-screen-recorder_2.7.5-1.dsc > deepin-screen-recorder (2.7.5-1) unstable; urgency=medium > > * New upstream version 2.7.5 > * d/rules: Don't install directory usr/share/dman . The recent QT transition made the build-depends uninstallable for a while. That's over now, however the package fails to build: src/utils.h:24:10: fatal error: dwindowmanager.h: No such file or directory #include ^~ compilation terminated. src/main.cpp:26:10: fatal error: DApplication: No such file or directory #include ^~ compilation terminated. make[1]: *** [Makefile:576: main.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: *** [Makefile:607: record_button.o] Error 1 In file included from src/record_process.cpp:27: src/utils.h:24:10: fatal error: dwindowmanager.h: No such file or directory #include ^~ compilation terminated. In file included from src/main_window.cpp:30: src/main_window.h:29:10: fatal error: dwindowmanager.h: No such file or directory #include ^~ compilation terminated. make[1]: *** [Makefile:595: record_process.o] Error 1 make[1]: *** [Makefile:589: main_window.o] Error 1 In file included from src/utils.cpp:33: src/utils.h:24:10: fatal error: dwindowmanager.h: No such file or directory #include ^~ Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#904793: RFS: libskk/1.0.4-2
On Sat, Jul 28, 2018 at 01:43:58PM +0800, 073p...@gmail.com wrote: > * Package name: libskk >Version : 1.0.4-2 [~/tmp/pkg]$ dget https://mentors.debian.net/debian/pool/main/libs/libskk/libskk_1.0.4-2.dsc dget: retrieving https://mentors.debian.net/debian/pool/main/libs/libskk/libskk_1.0.4-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 2237 100 22370 0 5049 0 --:--:-- --:--:-- --:--:-- 5038 dget: retrieving https://mentors.debian.net/debian/pool/main/libs/libskk/libskk_1.0.4.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 184k 100 184k0 0 564k 0 --:--:-- --:--:-- --:--:-- 564k dget: retrieving https://mentors.debian.net/debian/pool/main/libs/libskk/libskk_1.0.4-2.debian.tar.xz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 4568 100 45680 0 23070 0 --:--:-- --:--:-- --:--:-- 23070 libskk_1.0.4-2.dsc: Good signature found validating libskk_1.0.4.orig.tar.gz dscverify: invalid file length for libskk_1.0.4.orig.tar.gz (wanted 188524 got 188529) validating libskk_1.0.4-2.debian.tar.xz Validation FAILED!! As it's not the typical problem of a tarball on mentors.d.n differing from what's in the archive but the .dsc not matching the rest, I can't reliably recover: the new state might be not what you want. Thus, could you please re-upload? Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#904745: RFS: mint-y-icons/1.3.0-1 [ITP]
On Fri, Jul 27, 2018 at 03:04:04PM +0200, pavel-re...@email.cz wrote: > * Package name: mint-y-icons > Version : 1.3.0-1 > * URL : https://github.com/linuxmint/mint-y-icons > * License : GPL-3+, CC-BY-SA-4.0 > * Package name: mint-y-theme > Version : 1.2.3-1 > Upstream Author : Clement Lefebvre r...@linuxmint.com > * URL : https://github.com/linuxmint/mint-y-theme > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/mint-y-icons Hi! I've done only a very cursory review so far, and I see: * menu bar in GTK3 programs is squashed, here's a screenshot: https://angband.pl/tmp/mint-y-menu.png GTK2 programs are ok, so are QT (QT uses GTK2 theme, I think it can be configured for GTK3 these days though) * both in -theme and -icons, you ship pre-built files, and don't even delete them during build. That makes it hard to ensure that what you install is indeed built from provided source. It would be best to repack the .orig tarballs to remove usr/ dirs inside -- besides making things unclear, they also waste space, and might possibly include parts that don't have source. * the copyright files in both -theme and -icons need to include all authors (you can often get away with naming a group, though). They don't even list files in debian/ (the packaging). In -theme, the README.md says it is based on Arc. In -icons, there's a long list of themes some categories of icons have been copied from. Those authors need to be mentioned. There's a disagreement on how detailed the list should be: some people want everything to be accurate down every file, others say something like: Files: *Copyright: 1991-2012 Linus Torvalds and many others You need to do it detailed enough to pass ftpmasters' review, and their minimal requirements tend to be somehwere in the middle. And here, you didn't list most authors at all, even as part of a group. Meow! (.sig related -- but no matter how _I_ feel about copyright, with a DD hat on I still need to respect it, as it's not up to me to decide) -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#904529: RFS: dtkcore/2.0.8-1
On Wed, Jul 25, 2018 at 10:31:24AM +0800, Yanhao Mo wrote: > I am looking for a sponsor for my package "dtkcore" These three (dtkcore dtkwidget deepin-screen-recorder) currently fail to build because of a QT transition -- not your fault. I (or some other sponsor) will try again soon. Keep up the good work! Meow. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#904089: RFS: ibus-table-extraphrase/1.3.9.20110826-1 [RC]
On Fri, Jul 20, 2018 at 08:28:14AM +0800, Boyuan Yang wrote: > Adam Borowski 于2018年7月20日周五 上午4:47写道： > > > > On Thu, Jul 19, 2018 at 08:05:57PM +0800, Boyuan Yang wrote: > > > * Package name: ibus-table-extraphrase > > >Version : 1.3.9.20110826-1 > > > > > + Use Google Code Archive as homepage. > > > > The new homepage is also 404-compliant. > > I was using "Homepage: https://code.google.com/archive/p/ibus/";. I know that > Google Code is dead but this URL is still valid and won't return 404: > > curl -v https://code.google.com/archive/p/ibus/ > [...] > > GET /archive/p/ibus/ HTTP/2 > > Host: code.google.com > > User-Agent: curl/7.60.0 > > Accept: */* It doesn't return a proper 404, yeah. It puts a "successful" page that says (beside search header, etc): The Google Code Archive requires JavaScript to be enabled in your browser. and upon loading in Firefox: 404. That's an error. The project ibus was not found. Tested from a bunch of different IPs and profiles. On the other hand, using Google-Spyware^WChrome, the page loads. > Is there any problem with the homepage field? If it's about Google Code > decommissioning, this project don't really have better choice, I believe. Not sure how to deal with turning a working web page into a Javascript program that works only on a single browser. It's not your duty but upstream's though, and with upstream being defunct, there's not much to do... Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#904015: RFS: libhinawa/1.0.0-1
On Wed, Jul 18, 2018 at 10:44:46PM +0900, Kentaro Hayashi wrote: > On Wed, 18 Jul 2018 14:16:32 +0200 > Adam Borowski wrote: > > > On Wed, Jul 18, 2018 at 06:32:57PM +0900, Kentaro Hayashi wrote: > > > * Package name: libhinawa > > >Version : 1.0.0-1 > > > > > > It builds those binary packages: > > > > > > gir1.2-hinawa-1.0 - GObjet introspection data for libhinawa1 > >gir1.2-hinawa-2.0 actually > > Oh, I've missed it. > As you pointed out, it should be -2.0. What really counts is the actual state, not a bit of documentation. I raised this issue only because (a bit too late) noticed this transition might possibly be not what you intended. It's good to hear it was. > > One notable change in the upstream tarball is that usual licensing files > > have just been removed. The meson build file describes the license as > > LGPL-2.1+ and sources have SPDX identifiers, though. > > > > As for change to gir1.2-hinawa-2.0 -- I noticed it when debdiffing binaries, > > but dismissed it as a part of the package bump (there's a trip through NEW > > anyway). Only after uploading, when responding to this bug, I noticed that > > this mismatches what you wrote in the RFS. Thus, if the gir bump was not > > intentional, please request a REJECT on #debian-ftp (or via mail). > > > > The package has been uploaded as-is and is in NEW. > > gir bump was intentional, but I had missed to describe it into d/changelog. No pressing need to amend the changelog, I'd say. > I'll fix also license issue as 1.0.0-2 after 1.0.0-1 is accepted. The license is fine, it's just that the removal of centralized license info upstream might raise the ftpmasters' eyebrows. Meow. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Bug#883702: RFS: lina/5.3.0-1 ( #859130 ITP: lina -- iso-compliant Forth interpreter and compiler )
On Mon, Jul 02, 2018 at 05:32:40PM +0200, Albert van der Horst wrote: > (An earlier non-personal call for reviews yielded no reactions.) > I eagerly await your review of > https://mentors.debian.net/package/lina > especially whether it complies with the "preferred form of modification" > guidelines. The current version of the package fails to build: makeinfo lina.texinfo --no-split -o lina.info make[1]: makeinfo: Command not found make[1]: *** [Makefile:52: lina.info] Error 127 which is trivially fixable by adding texinfo to Build-Depends. Besides that, in a cursory review, I don't see any other issues. I can't claim I understand your build system, though. And unlike not understanding merely the packaged program's functionality, I don't think I can sign this myself. Thus, it'd be nice if someone else took a look as well. I don't quite see what's the new relation between ciforth and lina, too. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Bug#902967: RFS: ddnet/11.2.1-1
On Wed, Jul 04, 2018 at 12:23:25PM +0800, Yangfl wrote: > * Package name: ddnet >Version : 11.2.1-1 ^ > dget -x > https://mentors.debian.net/debian/pool/main/d/ddnet/ddnet_11.2.1-2.dsc ^ > > Changes since the last upload: > > * New upstream release Hi! The version you're requesting sponsorship for, and the one you pointed to, are different. The changelog in the latter is: +ddnet (11.2.1-2) unstable; urgency=medium + + * New upstream release + + -- Yangfl Wed, 04 Jul 2018 00:17:11 +0800 + ddnet (11.1.8-1) unstable; urgency=medium with no trace of 11.2.1-1 anywhere. Is something amiss? 喵! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Looking for help: A weird FTBFS triggered by d/control pkg description?
On Mon, Jun 25, 2018 at 11:19:20AM +0800, Boyuan Yang wrote: > On Sun, Jun 24, 2018 at 11:16:59PM +0500, Andrey Rahmatullin wrote: > > On Mon, Jun 25, 2018 at 12:25:36AM +0800, Boyuan Yang wrote: > > > However, after applying the following change, the package would > > > immediately FTBFS: > > I cannot reproduce this, so it's most likely not because of this change. > > > Neither can I, thus it must be something on Boyuan's system -- or there's > > some additional change not included in either the WIP .dsc. > > Thanks for your tests -- I suspect that it is caused by some race condition > that takes place during tests. > > I have prepared another upload forcing non-parallel build to circumvent this > problem for now. Still builds ok for me. Is it meant for upload? This is not a RFS bug, but because of a trip through NEW you can't upload it yourself yet. I see you dropped version 1.0.2-3, at least from the changelog, and thus it's likely you miss changes from it as well. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Re: Looking for help: A weird FTBFS triggered by d/control pkg description?
On Sun, Jun 24, 2018 at 11:16:59PM +0500, Andrey Rahmatullin wrote: > On Mon, Jun 25, 2018 at 12:25:36AM +0800, Boyuan Yang wrote: > > However, after applying the following change, the package would immediately > > FTBFS: > I cannot reproduce this, so it's most likely not because of this change. Neither can I, thus it must be something on Boyuan's system -- or there's some additional change not included in either the WIP .dsc. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Bug#902047: RFS: nautilus-hide/0.2.3-4
On Fri, Jun 22, 2018 at 06:55:49AM +1000, Carlos Maddela wrote: > * Package name: nautilus-hide >Version : 0.2.3-4 > dget -x > https://mentors.debian.net/debian/pool/main/n/nautilus-hide/nautilus-hide_0.2.3-4.dsc dget also fails, same as in the other package. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Bug#902046: RFS: nautilus-admin/1.1.6-2
On Fri, Jun 22, 2018 at 06:49:40AM +1000, Carlos Maddela wrote: > * Package name: nautilus-admin >Version : 1.1.6-2 > https://mentors.debian.net/package/nautilus-admin > Alternatively, one can download the package with dget using this command: > dget -x > https://mentors.debian.net/debian/pool/main/n/nautilus-admin/nautilus-admin_1.1.6-2.dsc Alas, the signature is missing: [~/tmp/pkg]$ dget https://mentors.debian.net/debian/pool/main/n/nautilus-admin/nautilus-admin_1.1.6-2.dsc dget: retrieving https://mentors.debian.net/debian/pool/main/n/nautilus-admin/nautilus-admin_1.1.6-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 2227 100 22270 0 11135 0 --:--:-- --:--:-- --:--:-- 11135 dget: using existing nautilus-admin_1.1.6.orig.tar.xz dget: retrieving https://mentors.debian.net/debian/pool/main/n/nautilus-admin/nautilus-admin_1.1.6.orig.tar.xz.asc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found dget: curl nautilus-admin_1.1.6.orig.tar.xz.asc https://mentors.debian.net/debian/pool/main/n/nautilus-admin/nautilus-admin_1.1.6.orig.tar.xz.asc failed nautilus-admin_1.1.6-2.dsc: Good signature found validating nautilus-admin_1.1.6.orig.tar.xz skipping nautilus-admin_1.1.6.orig.tar.xz.asc (not present) skipping nautilus-admin_1.1.6-2.debian.tar.xz (not present) All files validated successfully. gpgv: Signature made Thu Jun 21 22:27:05 2018 CEST gpgv:using RSA key 75EF6669E1BA6F557F17B0EFE1A3EAB44C24B2DD gpgv:issuer "e7ap...@gmail.com" gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on ./nautilus-admin_1.1.6-2.dsc dpkg-source: error: cannot fstat file ./nautilus-admin_1.1.6.orig.tar.xz.asc: No such file or directory It's not available either on the in-archive package nor in what you just uploaded to mentors. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Bug#901988: RFS: granite/5.0+ds-1
On Thu, Jun 21, 2018 at 12:43:13PM +0800, Yangfl wrote: > * Package name: granite >Version : 5.0+ds-1 > Changes since the last upload: > > * so bump But, the changelog of this and past versions is: granite (5.0+ds-1) experimental; urgency=medium * New upstream release. -- Yangfl Wed, 20 Jun 2018 23:14:19 +0800 granite (0.5+ds-3) unstable; urgency=medium * Bump Standards-Version to 4.1.4 (no changes needed). * Use team+pkg-dee...@tracker.debian.org in maintainer field. * d/rules: Use "dh-missing --fail-missing". -- Boyuan Yang <073p...@gmail.com> Fri, 20 Apr 2018 17:46:08 +0800 granite (0.5+ds-2) unstable; urgency=medium * Upload to unstable. * Apply "wrap-and-sort -abst". -- Boyuan Yang <073p...@gmail.com> Sat, 31 Mar 2018 18:27:53 +0800 granite (0.5+ds-1) experimental; urgency=medium * New upstream release. * Reintroduce package (Closes: #872919). * Bump Standards-Version to 4.1.3. * Move Vcs to Salsa platform. * Bump debhelper compat to v11. * Update debian/copyright. * Remove cmake/ParseArguments.cmake. -- Yangfl Tue, 23 Jan 2018 17:42:51 +0800 Note 0.5+ds-1 having already been uploaded, also to experimental, on Jan 23. Have you somehow forgot to actually update to the new upstream release? 喵! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Re: Salsa repository request
On Sun, Jun 24, 2018 at 04:59:03PM +0300, Alexander Inyukhin wrote: > I have to move old task-spooler repository from collab-maint on alioth > to debian project at salsa. > > I would like to ask someone to create an empty repository task-spooler > on salsa and grant access to it for user shurick-guest. Done. -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]
On Fri, Jun 22, 2018 at 06:04:14PM +0100, Ben Hutchings wrote: > I needed to make some small changes to build them as modules. The next > upload using Linux 4.17 should include ashmem_linux and binder_linux > modules for amd64, arm64 and armhf. I looked at it, and it seemed like making the mainline version of ashmem build as a module would indeed take only small changes. I did not have the time to actually do it, and it sounds like Ben just has done so. The driver is in staging/ thus perhaps you could push the patch gregkh's way? This would help people who use vanilla kernels. Binder is already module-capable. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
Re: sql-ledger on salsa?
On Thu, Jun 14, 2018 at 08:42:01AM -0400, Robert J. Clay wrote: > Is the normal procedure now, to ask here or in debian-devel to have a > DD add the project for the package to salsa? My salsa ID is > rjclay-guest. It's the normal procedure. debian/sql-ledger is up, rights granted. As you say you have the repository on your disk, I skipped finding out how to read archived Alioth projects, thus the repo is empty -- please push. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target.
