Bug#891922: RFS: you-get/0.4.1040-1 [ITP]

[Paul Wise]

On Sat, Mar 3, 2018 at 1:46 AM, Alex Mestiashvili wrote:

> It would be interesting to see how this program is different from
> already existing tools like youtube-dl and cclive.

There are a lot of different tools in this space:

https://wiki.debian.org/MultimediaFetchingTools

They are complementary, when one breaks, another often works. Each of
them supports a different set of sites, so if one doesn't support one
site, one of the others probably will.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#891922: RFS: you-get/0.4.1040-1 [ITP]

[Lumin]

On Sat, 3 Mar 2018 at 01:46 Alex Mestiashvili 
wrote:

>
>
>
> It would be interesting to see how this program is different from
> already existing tools like youtube-dl and cclive.
>
> Thank you!


I have noticed the existence of youtube-dl. However, the user may switch
to you-get when youtube-dl fails to work at some sites, such as Bilibili
(a popular Chinese danmaku video site).

cclive supports few site,compared to youtube-dl and you-get.

Danke.

> --
Best,

Bug with sev: grave while new package waiting

[Muri Nicanor]

hi mentors,

there is a bug with severity: grave in usbguard, because of a libqt5
version incompatibility (#892045) and there is already a new version of
usbguard waiting to be sponsored. Should i fix the bug in the new
version or should i fix it in the version thats already in the archive?

cheers and thanks,
muri



signature.asc
Description: OpenPGP digital signature

Bug#890878: RFS: company-irony

[Nicholas D Steeves]

Hi Alberto,

On Wed, Mar 14, 2018 at 09:34:07AM +0100, Alberto Luaces wrote:
> >> > I: company-irony source: testsuite-autopkgtest-missing
> >> 
> >> This is N/A, I think.
> >
> > It's not required at this point in time, but someday it's possible
> > that self tests will be required.  Dh_elpa_test runs the tests as part
> > of a package build, and autopkgtest is a framework that automates
> > testing of packages in a container or virtual machine.  Because this
> > is Informational level lint it's not high priority for Lintian, but if
> > you ever want to write a test that gets an company-irony autocompleted
> > list for something, and then compares that against the expected list,
> > in the expected order.  Tests that provide assurances it won't do
> > hilarious/embarrassing autocompletion like cell phones do.  A Nice to
> > have, later, if you have time and find the challenge interesting ;-)
> >
> 
> Ok.  I don't have currently the skills for writing those tests, but
> maybe in the future I can try to learn from some other packages.

Sounds good! :-)

> > Because for now the most pressing issue is that it doesn't initialise
> > properly...
> >
> >   Company backend 'company-clang' could not be initialized:
> >   Company found no clang executable
> >
> > This was both with no configuration (and M-x company-mode), and with
> > following upstream's README in a clean sid chroot.  I opened a random
> > cpp from kdeconnect to test.  I suspect a documentation of
> > configuration issue because I would have expected company-irony to
> > load rather than company-clang...but it's possibly a bug.
> >
> > Please let me know how you made company-irony work.
> 
> Oh, yes, I think this is expected.  From the documentation at
> 
> /usr/share/doc/elpa-company-irony/README.md
> 
> --8<---cut here---start->8---
> 
> ## Configuration
> 
> Add `company-irony` to your company backends.
> 
> ~~~el
> (eval-after-load 'company
>   '(add-to-list 'company-backends 'company-irony))
> ~~~
> 
> --8<---cut here---end--->8---

This is exactly one of the two things that I tried.  To be fair,
company-irony's autocomplete seems to function properly despite this
:-)

Could you patch README.md to show how to remove company-clang from
company-backends, and also document that this warning is harmless (if
it's harmless).

Thanks!
Nicholas


signature.asc
Description: PGP signature

Bug#892924: marked as done (RFS: gdbm/1.14.1-6 )

[Debian Bug Tracking System]

Your message dated Wed, 14 Mar 2018 15:13:20 + (UTC)
with message-id <1207708420.694453.1521040400...@mail.yahoo.com>
and subject line Re: Bug#892924: RFS: gdbm/1.14.1-6
has caused the Debian Bug report #892924,
regarding RFS: gdbm/1.14.1-6 
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
892924: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892924
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gdbm"

* Package name : gdbm
  Version  : 1.14.1-6
  Upstream Author  : bug-g...@gnu.org
* Url  : https://gnu.org/software/gdbm
* Licenses : GPL-3+,GFDL-1.3+
  Programming Lang : C
  Section  : libs


 GNU dbm ('gdbm') is a library of database functions that use extendible
 hashing and works similarly to the standard UNIX 'dbm' functions.
 .
 The basic use of 'gdbm' is to store key/data pairs in a data file, thus
 providing a persistent version of the 'dictionary' Abstract Data Type
 ('hash' to perl programmers).

It builds those binary packages:

  * libgdbm5
  * gdbm-l10n
  * libgdbm-dev
  * gdbmtool
  * libgdbm-compat4
  * libgdbm-compat-dev

This package succesfully builds on debomatic machine:

  https://debomatic-i386.debian.net/distribution#unstable/gdbm/1.14.1-6

Please note, that package is maintained with dgit(1) tool
using dgit-maint-merge(7) workflow. For more information about how to
sponsor this package, see dgit-sponsorship(7).

  Git repository: https://salsa.debian.org/iu-guest/gdbm.git
  Git branch: master

With /bin/sh following commands should suffice:

  $ git clone https://salsa.debian.org/iu-guest/gdbm.git gdbm
  $ cd gdbm
  $ make -f debian/rules get-orig-source # 'gbp buildpackage' is fine
  $ dgit sbuild

Changes since last upload:

  * Fix description of libgdbm-compat4 binary package (Closes: #892846)
+ Thanks: Vincent Lefevre 

Regards,
  Dmitry Bogatov
--- End Message ---
--- Begin Message ---
Hello,

>I am looking for a sponsor for my package "gdbm"


ack done

>  https://debomatic-i386.debian.net/distribution#unstable/gdbm/1.14.1-6


please fix this link, It took me a while to understand debomatic had no https
(I was wondering about it being unreachable)

G.--- End Message ---

Bug#892924: RFS: gdbm/1.14.1-6

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gdbm"

* Package name : gdbm
  Version  : 1.14.1-6
  Upstream Author  : bug-g...@gnu.org
* Url  : https://gnu.org/software/gdbm
* Licenses : GPL-3+,GFDL-1.3+
  Programming Lang : C
  Section  : libs


 GNU dbm ('gdbm') is a library of database functions that use extendible
 hashing and works similarly to the standard UNIX 'dbm' functions.
 .
 The basic use of 'gdbm' is to store key/data pairs in a data file, thus
 providing a persistent version of the 'dictionary' Abstract Data Type
 ('hash' to perl programmers).

It builds those binary packages:

  * libgdbm5
  * gdbm-l10n
  * libgdbm-dev
  * gdbmtool
  * libgdbm-compat4
  * libgdbm-compat-dev

This package succesfully builds on debomatic machine:

  https://debomatic-i386.debian.net/distribution#unstable/gdbm/1.14.1-6

Please note, that package is maintained with dgit(1) tool
using dgit-maint-merge(7) workflow. For more information about how to
sponsor this package, see dgit-sponsorship(7).

  Git repository: https://salsa.debian.org/iu-guest/gdbm.git
  Git branch: master

With /bin/sh following commands should suffice:

  $ git clone https://salsa.debian.org/iu-guest/gdbm.git gdbm
  $ cd gdbm
  $ make -f debian/rules get-orig-source # 'gbp buildpackage' is fine
  $ dgit sbuild

Changes since last upload:

  * Fix description of libgdbm-compat4 binary package (Closes: #892846)
+ Thanks: Vincent Lefevre 

Regards,
  Dmitry Bogatov

Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

(Anton, there is a question below for you, that's why you are in To:))

On Fri, Mar 09, 2018 at 01:13:54AM -0600, Kurt Kremitzki wrote:
> Control: tags -1 - moreinfo
> 
> Alright, I've addressed all the points brought up by you two (thanks for the
> feedback so far!)
> 
> I have done a thorough check of the licenses, updated d/copyright, and found
> a few problematic Qt Commercial license files, which I reported to upstream.
> [1]
> 
> But, besides the files mentioned in [1], I think everything else is ready
> for review.
> 
> I've verified FreeCAD works well with this, and previously my WIP Netgen 6.2
> package worked well but is currently experiencing issues which I think are
> unrelated. The only other dependent package is deal.ii which I am not
> familiar with and will have to investigate later as part of the phase-out of
> liboce.
> 
> 1. https://www.opencascade.com/content/packaging-again-debian#comment-20398
> 

Hi,

here's a review...(it is not sorted by priority or like)

- d/patches
  - did you check with upstream whether they would accept the patches,
especially fix-install-dir-references.diff.   

- d/rules:
  - override_dh_auto_configure -> the comment refers to an non-existing
  file. Is the ignoring of cmake's return value still needed?
  - see below for dh_doxygen.

- d/control
  - there is a missing B-D on graphviz, otherwise doxygen will fail
  - (bonus area:) It would be great if doxygen could be put to
B-D-indep, so only installed then building the -all packages
I did not check how much effort this is, it is not required for an
upload, but as doxygen has a huge dependency chain, this is nice for
the buildds.
  - for the doxygen cleanup, prefer using dh_doxygen, and you should 
do that in a override for dh_installdocs(1)

- d/changelog
  - the line with dbgsym can go, as those are automatic and did not
require a change in the sources.
  
- d/changelog.gz / changelog.html.gz
  I'm not sure if we should ship those in the debian directory.

  But first the technical things:
  One copy should be enough, do not ship both html and text. (I would prefer
  the text version) Especially, as the html version has problems: it
  sources files from external websites (css, google-analytics) which is a
  breach of privacy and not acceptable for Debian.  Then, if you ship
  them as changelogs, they are not to be installed using *.docs, they
  should be installed using dh_installchangelogs(1), because this tool
  will "do the right thing" and install it into every package, which is
  require by the Policy*.  You should not compress the changelogs in the
  debian directory, the tool mentioned above will do that for you.

  (* I'm omitting here the other possibility to use
  symlinks between packages, which could be used to deuplicate them, IMHO
  not worth the effort)

  Said, that I'm not sure if we should the upstream changelog in the
  debian directory; It will be an easy error to make to miss updating it
  as it will always be manual. If you want to keep it, this would be
  needed to be documented in README.Source, and we have many packages
  without upstream changelogs, so don't let you get nuts by this
  linitian messages ;) It would be better to ask upstream to put the
  changelog into their releases tarballs (which then needs to be NOT
  behind a login, IIRC)

  I leave it up to you whether you want to have the changelog manually
  or if you want to ditch it completly. (if you keep it, the fixes
  described above will be needed)

- lintian overrides
  - usually overrides should only be done if there is a problem with
linitian detecting the correct things, IOW it should not be
used to "silence" things, e.g
If upstream does not support something, just keep the message...
(e.g no-upstream changelog, testsuite-autopkgtest-missing,
debian-watch-does-not-check-gpg-signature)

E.g those overrides should be removed:
- source-contains-autogenerated-visual-c++-file 
- no-upstream-changelog


- spelling-errors-in-binary overrides
  Note hat this is about binaries, not about comments in the source
  code! (as your override comment suggests)
  At least a few of them are legitimate, at least the random spot
  checks I did on. Disclaimer: I did not check context if this would 
  change code behaviour. Needs to be checked with upstream
  I egrep'ed on:
  - tranformations 
  - convertion
  - unkown
  I'd recommend to get in touch with upstream, maybe providing them a
  patch to apply. (This will not be required for the upload, but
  spelling should be fixed at least long term)

- script-not-executeable
  You writd in the override:# /usr/share/occt/bin/*.sh are reference scripts
  Can you expand what you mean? Are they examples? Are they
  needed? For what are they needed?
  One of the scripts references DRAWEXE which is listed
  in d/non-installed

- symbol files
  I think you should run the symbols through c++filt, see 
  dpkg-gensymbols(1) and 

Bug#890878: RFS: company-irony

[Alberto Luaces]

Hi Nicholas,

Nicholas D Steeves writes:

[...]

Thanks again for your advice!

>> > I: company-irony source: testsuite-autopkgtest-missing
>> 
>> This is N/A, I think.
>
> It's not required at this point in time, but someday it's possible
> that self tests will be required.  Dh_elpa_test runs the tests as part
> of a package build, and autopkgtest is a framework that automates
> testing of packages in a container or virtual machine.  Because this
> is Informational level lint it's not high priority for Lintian, but if
> you ever want to write a test that gets an company-irony autocompleted
> list for something, and then compares that against the expected list,
> in the expected order.  Tests that provide assurances it won't do
> hilarious/embarrassing autocompletion like cell phones do.  A Nice to
> have, later, if you have time and find the challenge interesting ;-)
>

Ok.  I don't have currently the skills for writing those tests, but
maybe in the future I can try to learn from some other packages.

[...]

>
> Because for now the most pressing issue is that it doesn't initialise
> properly...
>
>   Company backend 'company-clang' could not be initialized:
>   Company found no clang executable
>
> This was both with no configuration (and M-x company-mode), and with
> following upstream's README in a clean sid chroot.  I opened a random
> cpp from kdeconnect to test.  I suspect a documentation of
> configuration issue because I would have expected company-irony to
> load rather than company-clang...but it's possibly a bug.
>
> Please let me know how you made company-irony work.

Oh, yes, I think this is expected.  From the documentation at

/usr/share/doc/elpa-company-irony/README.md

--8<---cut here---start->8---

## Configuration

Add `company-irony` to your company backends.

~~~el
(eval-after-load 'company
  '(add-to-list 'company-backends 'company-irony))
~~~

--8<---cut here---end--->8---


Regards,

Alberto