Re: Package EOL checklist

On Tue, Feb 27, 2018 at 2:34 PM, Joseph Herlant wrote: > Did I miss a step? The first step when asking questions should always be to include details so that we know what we are talking about. > I have a package that is not maintained by upstream anymore and I was trying > to find some sort of

Bug#891429: RFS: urlwatch/2.8-1

On Sun, Feb 25, 2018 at 10:34 PM, Maxime Werlen wrote: > Cc: Paul Wise <p...@debian.org> Please use X-Debbugs-CC to CC people when filing new bugs. This allows the recipient to also find out about the bug number: https://www.debian.org/Bugs/Reporting#xcc > I am looking for a sp

Bug#890203: RFS: gigalomania/1.0-1 [ITP]

On Fri, Feb 16, 2018 at 3:34 AM, Jose G. López wrote: > The package got rejected because I forgot to reference a copy of TinyXML. Please ask upstream to remove the copy from their VCS and tarballs and depend on it instead. If that does not work, please either repack the tarball or ensure that

Re: GPLv3 source code with license check for some build configuration, DFSG ok?

On Thu, Feb 15, 2018 at 8:29 AM, Thomas Preud'homme wrote: > ultracopier's source code has a license check when built in ultimate mode. What is the difference between ultimate mode and normal modes? -- bye, pabs https://wiki.debian.org/PaulWise

Bug#887659: RFS: urlwatch/2.7-1 [ITA]

On Fri, 2018-02-09 at 07:29 +0100, Maxime Werlen wrote: > Thanks for your time reviewing my packages. Thanks for adopting urlwatch! > I've tried to fix as much issues as I'm capable. There is only the blocker of ftp-masters accepting minidb now. It would be nice to fix these extra issues at

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

On Fri, 2018-02-09 at 07:31 +0100, Maxime Werlen wrote: > Thanks for your time reviewing this package. Thanks for adopting urlwatch :) > I've tried to fix as much issues as I'm capable. Excellent. Since you fixed the two blockers, I've uploaded it to NEW. A few more things that might be nice

Re: compiled binary file in source package

On Fri, Feb 9, 2018 at 4:14 PM, Miroslav Kravec wrote: > Could you please provide the name of the policy? I've just read it, > and I haven't found one. Debian Free Software Guidelines item 2: https://www.debian.org/social_contract#guidelines 2. Source Code The program must include source

Re: question about lintian overrides

On Thu, Feb 1, 2018 at 7:47 AM, Elías Alejandro wrote: > "Exec=env GDK_BACKEND=x11 uget-gtk %u" I'm guessing this will break for users running apps under Wayland instead of X11. I think it would be best to remove "env GDK_BACKEND=x11" so that Wayland works and the lintian warning goes away. --

Bug#888312: RFS: streamlink/0.10.0+dfsg-1

On Thu, 2018-01-25 at 22:35 +0100, Alexis Murzeau wrote: > Without this override, dh_installchangelogs uses "docs/changelog.rst" > instead, which contains only an include statement and not the actual > content (see diffoscope in attachment) > > According to its sources, dh_installchangelogs

Bug#888312: RFS: streamlink/0.10.0+dfsg-1

On Thu, Jan 25, 2018 at 5:26 AM, Alexis Murzeau wrote: > I am looking for a sponsor for my package "streamlink" for a new > upstream version 0.10.0. Uploaded. Some things that would be nice to fix at some point: I'm surprised override_dh_installchangelogs is needed, the code seems like it

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

Control: owner -1 ! Control: tags -1 + moreinfo I intend to sponsor this because the urlwatch RFS needs it. On Fri, Jan 19, 2018 at 4:42 AM, Maxime Werlen wrote: > I am looking for a sponsor for my package "minidb" In future, I'd recommend using the BTS block command when filing an RFS that

Bug#887659: RFS: urlwatch/2.7-1 [ITA]

Control: owner -1 ! Control: tags -1 + moreinfo I intend to sponsor this. On Thu, 18 Jan 2018 21:42:33 +0100 Maxime Werlen wrote: > I am looking for a sponsor for my package "urlwatch" These issues block the upload of this package: The package FTBFS in a clean chroot, you need to package

Re: ITA: pygithub/1.35-1

On Sat, 2018-01-13 at 21:37 -0300, eamanu15 . wrote: > I will send again the mail with the correct data. No need to do that. > this is the only change that I have to make?? No idea, I didn't review the package. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This

Re: ITA: pygithub/1.35-1

On Sat, Jan 13, 2018 at 11:48 PM, Emmanuel Arias wrote: > Source: https://pypi.python.org/pypi/PyGithub > Upstream Author : Emmanuel Arias This is incorrect, please do not claim authorship of code you did not write. https://github.com/orgs/PyGithub/people

Re: Splitting source package into two

On Thu, Jan 11, 2018 at 3:45 PM, Ole Streicher wrote: > Recently, upstream announced a new version 3.0 of astropy, which > supports Python 3 only, and I want to have a smooth migration path. I > thought of a temporary package split: create a new source package > "astropy" that inherits of the

Re: Dependencies across architectures

On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote: > Unfortunately, this is impossible: the assembler code creates a kind of > sigsetjmp() (with its own calling interface) for Fortran 77. This cannot > be simply remodelled in C. In principle, one could re-implement this > with the libunwind

Re: Dependencies across architectures

On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote: > "iraf" exists only on selected architectures due to some required > assembler code for each arch and problems with big endian. There could be a fallback in C for arches with no assembler yet and any non-baseline instructions should be

Re: Built-Using usage question

On Sat, Dec 30, 2017 at 10:49 PM, Lukas Schwaighofer wrote: > I read the update in policy 4.1.3 and I'm not sure how to handle the > change / clarification of the Built-Using control field for the > syslinux package (which I maintain in the debian-cd team). I suggest you ask this question on the

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

On Sun, 2017-12-31 at 02:28 +0100, Alexis Murzeau wrote: > The upload failed because the orig tarball was not included maybe > because its -3 ? Right, I forgot to include the orig tarball manually. Done now. > The changes since version 0.8.1-2 should be included too I guess as this > one has

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

On Sat, 2017-12-30 at 22:04 +0100, Alexis Murzeau wrote: > https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0+dfsg.2-3.dsc Uploaded to NEW, thanks a lot for your contribution, it saved me from having yet another package removed from Debian on my system :) -- bye, pabs

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

On Fri, Dec 29, 2017 at 7:54 PM, Alexis Murzeau wrote: > Yes I will do that and consider check-all-the-things to be run at each > version. Ok, great. I'm also interested in any feedback you have on the tool. > Indeed my bad. Also, the package got rejected because of a higher > version in stable

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

On Fri, Dec 29, 2017 at 9:43 AM, Alexis Murzeau wrote: > https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0+dfsg.2-1.dsc Uploaded to NEW. https://ftp-master.debian.org/new.html For future uploads, please file an RFS bug as usual. Please consider working through the

Bug#861011: RFS: qt5ct/0.31-2 [ITP]

On Wed, Dec 27, 2017 at 5:25 AM, Tobias Frost wrote: > - do not install AUTHORS. This information should be visible in > d/copyright already. The authors of a piece of software are not always the same as the copyright holders of that software. There are various things that can cause this,

Bug#884816: RFS: frontaccounting/2.4.3-1 [ITA]

On Thu, 2017-12-21 at 23:51 +0100, Janusz Dobrowolski wrote: > Taking into account the package is not part of any debian repo, can I > just update the version published on my mentors.debian.net account > without version change, or should I update package version to 2.4.3-2 > before upload? You

Bug#884816: RFS: frontaccounting/2.4.3-1 [ITA]

On Wed, Dec 20, 2017 at 6:57 AM, Janusz Dobrowolski wrote: > This package was recently included in wheezy, but seems later was > orphaned sometime back in 2013, and currently is absent from debian > repositories. Now it is refreshed, and as one of upstream developers I'm > ready to maintain it

Bug#878268: RFS: streamlink/0.9.0-1 [ITP]

On Thu, Nov 23, 2017 at 5:41 AM, Alexis Murzeau wrote: > https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0-1.dsc Here is a review: These issues need to be resolved before upload: I think docs/_static/flattr-badge.png is probably non-free. Upstream stopped using a while

Bug#883611:

On Wed, Dec 6, 2017 at 6:12 PM, Paolo Gigante wrote: > As per the ITP (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880600) > there is a lot of additional functionality that auter provides which goes > way beyond what is offered by cron-apt and unattended-upgrades: A comment on the ITP

Bug#883611: RFS: auter/0.11 (ITP: Bug#880600)

On Wed, Dec 6, 2017 at 1:54 AM, Paolo Gigante wrote: > auter - Automatic updates for Redhat and Debian based Linux servers Please compare and contrast auter with the other packages in Debian for this task: unattended-upgrades cron-apt packagekit -- bye, pabs https://wiki.debian.org/PaulWise

Re: Re-Uploading to mentors.debian.net

On Fri, Dec 1, 2017 at 7:46 PM, Sascha Manns wrote: > Now i have fixed these things, and built a new package version. Should > i delete the old package before uploading the new package version? IIRC, reuploading will replace the older version. -- bye, pabs https://wiki.debian.org/PaulWise

Re: orphaned open-cobol package should be replaced with new gnucobol package

On Sun, Nov 26, 2017 at 11:24 PM, Simon Sobisch wrote: > I'd like to know if there's something the GnuCOBOL project can do to > allow the orphaned open-cobol package to be replaced with a new gnucobol > package and provide updates for it. I would suggest starting with the existing open-cobol

Re: How to package support libraries for Tilde

On Wed, Nov 15, 2017 at 5:03 PM, Gertjan Halkes wrote: > My question is: how do I go about packaging them? Do I package each library > separately, and if so, do I file ITP bugs for each of them? If, on the other > hand, I am to package everything into a single 'tilde' package, how would I > do

Bug#862114: Bug#862115: RFS: xe/0.8-1 (ITP, #862114) & lr/0.4-1 (ITP, #862115)

On Mon, 2017-10-30 at 15:01 +0100, Nicolas Braud-Santoni wrote: > Oh, I didn't realise this wasn't a person :O Yeah, it probably should migrate to mentors and a more obvious sender address. > I guess the obvious solution is for me to become a DD and sponsor uploads :P That would definitely

Bug#862114: Bug#862115: RFS: xe/0.8-1 (ITP, #862114) & lr/0.4-1 (ITP, #862115)

On Mon, Oct 30, 2017 at 9:45 PM, Nicolas Braud-Santoni wrote: > This RFS is a pretty good example: there was no new upstream version, and > no review (or any sort of activity on the RFS) since June, while the timeout > on mentors.debian.net is only 20 days. The best you can do in that situation

Bug#862115: RFS: xe/0.8-1 (ITP, #862114) & lr/0.4-1 (ITP, #862115)

On Sat, Oct 28, 2017 at 5:38 PM, Nicolas Braud-Santoni wrote: > As an aside, I find it very weird to close a RFS due to > the inactivity of would-be sponsors: from the packager's > side, it feels like a double punishment (getting ignored, > then getting your RFS closed because you got ignored)...

Bug#869692: RFS: cyclograph/1.9.1-1

On Sat, Oct 14, 2017 at 4:46 AM, Federico Brega wrote: > Is my proposal of adding a lintian override Ok? lintian is only for the situation where it the lintian complaint is not true. In this case, the problem is present so you should not override it. If you intend to ignore this problem, just

Re: Help with watchfile to Gitlab clone needed (Was: Source code of altree vanished)

On Fri, Oct 6, 2017 at 6:50 PM, Andreas Tille wrote: > Any hint how to fix this? If you run uscan with --debug (or look at the HTML) you can see that the URLs are domain absolute rather than relative, so you need to either add /NGS/ALTree/ or .*/ to the repository regex: version=4

Bug#877296: Subject: RFS: dokuwiki-sync/0.1 ITP

On Sat, Sep 30, 2017 at 6:30 PM, Andrew Worsley wrote: > This is just a small shell script I have used from time to time - I am > not sure how usable it is for others and it is mostly to get practise > of packaging and getting feedback. So please feel free to comment on > what might be a better

Re: Debian Mentor

On Mon, Aug 14, 2017 at 6:13 AM, Francois Gez wrote: > I am honored to be in this list for so many years! Does it mean that I am a > mentor and I did not know? I was be delighted to be of any help here. This is the first mail from you on the debian-mentors list, I think to be considered a

Re: pypi.debian.net sending a 502 bad gateway

On Sat, Aug 12, 2017 at 7:45 PM, Joseph Herlant wrote: > https://pypi.debian.net/* sends back a "502 Bad Gateway I'd suggest contacting the maintainer of that service: $ host -t txt pypi.debian.net | head -n1 pypi.debian.net descriptive text "Piotr O\197\188arowski " $ finger

Re: Replace cron with systemd timer unit?

On Thu, Aug 3, 2017 at 9:19 PM, Ben Finney wrote: > If the cron job is removed – necessarily entailed by “replace it”, > surely? – then how can they continue to use it after it is replaced by > something else? I would discourage removal of the cron job, but it could still be replaced by a

Re: Replace cron with systemd timer unit?

On Thu, Aug 3, 2017 at 1:53 PM, Ben Hildred wrote: > You do realise that there are people who do not run systemd? They can use the cron job as usual. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Replace cron with systemd timer unit?

On Thu, Aug 3, 2017 at 1:20 PM, Ricardo Fraile wrote: > I like some aspects of the .timer, but I don't know if the change is a good > idea or not at this moment? There are any other package that has changed > from cron to .timer? What is the official recomendation? One significant difference

Re: Linitian orig-tarball-missing-upstream-signature

On Mon, Jul 31, 2017 at 5:41 AM, Christian Seiler wrote: > On 07/31/2017 11:34 AM, Andrey Rahmatullin wrote: >> uscan isn't used, or needed, in the git-only workflow at all. > > In purely git workflows (that pull remote git tags), sure, but > then you'd not have debian/watch That isn't

Re: Linitian orig-tarball-missing-upstream-signature

On Mon, Jul 31, 2017 at 5:19 AM, Christian Seiler wrote: > How does this interact with git-based workflows? I don't use such workflows so I'm not sure, but at a guess; uscan and upstream tarballs aren't involved in your workflow, so you won't have upstream tarball signatures either and should

Re: Linitian orig-tarball-missing-upstream-signature

On Mon, Jul 31, 2017 at 4:24 AM, Ole Streicher wrote: > is not really helpful to me; at least I did not find a mention in the > Debian policy that the signature should be included in the .changes > file. Also, it seems that the standard (pdebuild) toolchain does not > include it by default.

Bug#870215: RFS: stendhal/0.1-1 [ITP] -- Multiplayer online adventure game with an old school feel

On Sun, Jul 30, 2017 at 8:58 PM, Carlos Donizete Froes wrote: > Sorry, I have a question, even though it is a project of my own. > > Do I have to add the Stendhal link? In my first mail I was confused, since you previously had an ITP/RFS for stendhal-installer and I assumed this package was the

Bug#870215: RFS: stendhal/0.1-1 [ITP] -- Multiplayer online adventure game with an old school feel

On Sun, Jul 30, 2017 at 8:22 PM, Carlos Donizete Froes wrote: > * Package name: stendhal > dget -x > https://mentors.debian.net/debian/pool/contrib/s/stendhal/stendhal_0.1-1.dsc Since this does not include stendhal, just a script to download the upstream JAR, I think you should call

Bug#870215: RFS: stendhal/0.1-1 [ITP] -- Multiplayer online adventure game with an old school feel

On Sun, Jul 30, 2017 at 8:22 PM, Carlos Donizete Froes wrote: > * URL : https://github.com/coringao/stendhal This is the wrong link, it should be: https://stendhalgame.org/ > * License : GPL-2+ >Section : contrib/games This is the wrong section for a package

Re: Bug#869198: RFS: golang-github-shibukawa-configdir/0.0~git20170330.0.e180dbd-1 [ITP]

On Sat, Jul 29, 2017 at 3:46 AM, Andreas Moog wrote: > To: debian-mentors@lists.debian.org I suggest mailing the bug instead, since debian-mentors is subscribed to all RFS bugs but RFS bug submitters might be only subscribed to their RFS bugs. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Request for sponsor for Stendhall Installer

On Mon, Jul 24, 2017 at 10:59 AM, Carlos Donizete Froes wrote: > Sorry, but I do not know about the "game-data-packager" and what has to do > with > my installers. It is a tool to convert upstream data packages into .deb files: https://tracker.debian.org/pkg/game-data-packager > Is there a

Bug#868378: RFS: nlohmann-json/2.1.1-1

On Mon, Jul 17, 2017 at 8:09 AM, Christian Seiler wrote: > [1] This takes a _long_ time with this package as you have huge > test data in JSON form within the package, and if you do > run it, redirect its output into a file, otherwise your > terminal will be swamped with messages. >

Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

On Mon, Jul 3, 2017 at 7:34 PM, Albert van der Horst wrote: > This is of course in the spirit of open source, and it is the > "preferred source of modification" for the *target* audience. "Preferred" in "preferred form of the work for making modifications to it" does not refer to downstream

Bug#865515: RFS: pcc/1.2.0~20170614-1 [ITP]

On Fri, Jun 23, 2017 at 5:52 AM, Adam Borowski wrote: > It was briefly in the archive: https://packages.qa.debian.org/p/pcc.html > Removed due to no upstream activity. I see the upstream is somewhat alive > nowadays, although I wouldn't call the development brisk. Please read this advice about

Re: experimental => unstable?

On Sun, Jun 18, 2017 at 2:41 PM, Roger Shimizu wrote: > So it should be fine to release various packages currently being held > in experimental to unstable. Unstable is back in business, but testing is still frozen. Please note you still need to co-ordinate with the release team for

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

On Tue, 2017-06-06 at 18:17 +0700, Arnaud wrote: > Is it a correct way of doing things ? If the tarball you upload to Debian is bit-for-bit identical to the tarball you upload to or get from github, then yes, otherwise no. I used diffoscope to compare the tarball uploaded to github with the

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

On Mon, Jun 5, 2017 at 11:35 PM, Arnaud wrote: > mentors.debian.net says there's a problem. I'm not sure what's wrong. Probably due to the old version of uscan it uses. > The package is now built with `gbp` from a git tag. I guess it fixes the > problem. Please verify that is the case. > I

Re: Packaging PythonQt for Qt 5

On Tue, May 23, 2017 at 4:56 AM, Erik Lundin wrote: > We're using PythonQt built for Qt 5 at work, and I have been looking at the > possibility to package it for Debian. Here is what I have found so far: I note that PythonQt is orphaned, so you may want to adopt it:

Re: artifacts in upstream, re: pristine source

On Tue, May 16, 2017 at 12:42 PM, Brian Smith wrote: > Regarding the "pristine source" requirement (i.e. no build artifacts) in the > source archive: should the upstream tarball be imported to the upstream > branch "as is", and the tar command for orig.tar.gz should be configured to > omit build

Re: how best to package when using hardware vectorization with vector-unit specific code?

On Thu, May 11, 2017 at 12:01 AM, Kay F. Jahnke wrote: > While this is tempting, I'd like to keep my code as general as possible. > Also, I prefer compiling with clang++, which, for my use case, produces > faster code, and clang++ does not support constructs like Apparently clang supports

Re: how best to package when using hardware vectorization with vector-unit specific code?

On Wed, May 10, 2017 at 3:17 PM, Kay F. Jahnke wrote: > I have code which optionally makes use of hardware vectorization. ... > When compiling with Vc, the resultant machine code is for a specific vector > unit only, like AVX or SSE. ... > I'd like some advice on how to proceed to get my code to

Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]

On Thu, 4 May 2017 00:38:24 +0200 Adam Borowski wrote: > I'm not entirely sure .otf are the real sources, despite the upstream > providing only otf.  For now, let's assume they are, unless there's evidence > to the contrary (not sure what the README means). The README is pretty clear that the

Bug#847608: RFS: zodbpickle/0.6.0-1 [ITP]

On Fri, 9 Dec 2016 21:24:48 +0100 Julien Muchembled wrote: >python-zodbpickle - Fork of pickle module, for ZODB If this enters Debian, please make sure that you notify the security team to update their embedded-code-copies file, which tracks both embedded copies and forks of projects.

Bug#861011: RFS: qt5ct/0.31-2 [ITP]

On Mon, Apr 24, 2017 at 12:41 AM, Mateusz Łukasik wrote: > qt5ct - Qt5 Configuration Utility Since Lisandro is a Debian member and a co-maintainer of the package, will he be uploading this? I don't intend to sponsor this package, but here is a quick review: There do not appear to be any

Re: someone knows about https://archive.debian.net/

On Fri, Apr 21, 2017 at 10:02 PM, PICCORO McKAY Lenz wrote: > some one noted or using any time the https://archive.debian.net/ service.. ... > today this service are changed and now only put a static page in > frontend.. anybocy knows about related? The service will not be available until the

Bug#860123: RFS: gsignond/1.0.6 [ITP] -- gSSO daemon and default plugins

On Wed, Apr 12, 2017 at 1:05 AM, Corentin Noël wrote: > https://mentors.debian.net/debian/pool/main/g/gsignond/gsignond_1.0.6.dsc I don't intend to sponsor this, but here is a quick review: debian/source/format should be 3.0 (quilt) instead of 3.0 (native) and the version number should be

Bug#860145: RFS: openscap-daemon/0.1.6-1 [ITP] -- SCAP security policy compliance daemon for a complete infrastructure

On Wed, Apr 12, 2017 at 3:10 PM, Philippe Thierry wrote: > https://mentors.debian.net/debian/pool/main/o/openscap-daemon/openscap-daemon_0.1.6-1.dsc I don't intend to sponsor this, but here is a quick review: Please encourage upstream to port the project to Python 3, we are getting closer to

Re: rejection

On Wed, Apr 12, 2017 at 2:42 PM, Dominique Dumont wrote: > On Tue, 11 Apr 2017 17:53:41 +0200 Paride Legovini wrote: > Coalescing entries can be done by 'scan-copyrights' or 'cme update dpkg- > copyright' (provided by cme and libconfig-model-dpkg-perl packages) For reference, there are some more

Re: Trigger to activate bash-completion

On Mon, Apr 10, 2017 at 10:09 AM, Eriberto Mota wrote: > My current problem is I need to execute 'exec bash' to completion > work. Is there a trigger to activate completion after the package > install? Any postinst action? Packages don't get to interfere with user processes, so no you cannot do

Re: How to build scala source

On Fri, Feb 24, 2017 at 5:19 AM, Stuart Prescott wrote: > I don't know what sbt is (I know little about scala). I get the impression > there are quite a few commonly used bits of the scala tool chain that aren't > in Debian. ... > (or alternatively, package sbt?! ;) See this thread/bug about

Bug#855355: RFS: nasm/2.12.02-1 [ITA]

On Fri, 17 Feb 2017 07:50:21 + (UTC) Gianfranco Costamagna wrote: > side note: the reproducible patch might be changed in something little > different > -const char nasm_date[] = __DATE__; > +const char nasm_date[] = __DATE_DEBIAN__; It is far better to just remove build dates, they are

Re: Adding a new package to Debian

On Fri, Feb 17, 2017 at 4:23 AM, Iban Eguia wrote: > already was a package named `super` in the Debian repositories. > > We first thought of changing our package name to something other than > `super`, but we then noticed that the package had not been updated in more > than 9 years, and we

Re: [RFC] How to review RFS package

On Wed, Feb 8, 2017 at 10:15 PM, Roger Shimizu wrote: > Yes, but those docs didn't provide info detailed enough for me to start. > Probably I too much rely on the high level tools, and lack of ability > to use plumbing level tools such as dpkg-*. I think most people encounter all these tools

Re: [RFC] How to review RFS package

On Wed, Feb 8, 2017 at 9:50 PM, Roger Shimizu wrote: > During my attempt to review RFS package in mentors list, I find actually > there's no good manual for this activity. Did you see the existing documentation? http://mentors.debian.net/intro-reviewers https://wiki.debian.org/SponsorChecklist

Re: Popcon statistics over time for set of packages

On Tue, Feb 7, 2017 at 3:56 PM, Andreas Tille wrote: > I wonder if there is some way to get popcon statistics for a set of > packages to compare their usage over time. The background is that > I consider to compare the dependencies of Blends metapackages in one > graph. The popcon graph script

Re: Forth compiler has been gitted, request for sponsoring lina32

On Fri, 2017-01-13 at 03:00 +0100, Albert van der Horst wrote: > [Sorry for the long quote] Sorry for the delay :) > The generic system for ciforth is now present in github. > https://github.com/albertvanderhorst/ciforth Great :) > This is a complete copy of the rcs/cvs system with all

Re: mpgrafic - mpirun test program as root in automatic build

On Thu, Jan 19, 2017 at 7:44 AM, Sean Whitton wrote: > This is temporarily false: #852071 Is there a typo in that bug? I get a 404 -- bye, pabs https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote: > Also when using cowbuilder? At least I see the whole build done by root > when running in my cowbuilder chroot. That was the point that lead to > the trouble here... Yep. I tested this with id and override_dh_auto_* in cowbuilder:

Re: mpgrafic - mpirun test program as root in automatic build

On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote: > I guess by "both of these" you mean "most of the build steps (apart from > the 'debian/rules install' step)"? What I wrote wasn't clear and wasn't strictly true, sorry! When manually building from source: You always build/test as a normal

Re: mpgrafic - mpirun test program as root in automatic build

On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote: > I've looked a bit at buildd.debian.org, but it's not completely > trivial to decide which is correct - do the buildd builds on the > debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged > user running fakeroot, or as

Re: watch file with multiple download url

On Tue, Jan 17, 2017 at 2:47 PM, PICCA Frederic-Emmanuel wrote: > so it seems that I have a problem with the upstream versioning ... > the final release is tango-9.2.5a which is considered lower than > tango-9.2.5-rcx > > how should I change my watch file to take this into account. This has

Re: watch file with multiple download url

On Mon, Jan 16, 2017 at 11:01 PM, PICCA Frederic-Emmanuel wrote: > No issues, I just wanted to know if I could have something with uscan which > work out of the box with both URL's. > So I would like something without the comment / uncomment trick. uscan works out of the box with both URLs as

Re: watch file with multiple download url

On Mon, Jan 16, 2017 at 5:34 PM, PICCA Frederic-Emmanuel wrote: > Here my current watch content where I comment and uncomment the URL. Just uncommenting both seems to work for me, what issue do you get? -- bye, pabs https://wiki.debian.org/PaulWise

Re: What GPU can be assumed for autopkgtests

On Mon, Jan 16, 2017 at 12:12 AM, Andreas Tille wrote: > I remember these messages in connection with some (other?) package on > autobuilders but I can't make up my mind which one and I'm obviously > doing the wrong web search queries. I don't know enough about OpenMPI and the logs you posted

Re: What GPU can be assumed for autopkgtests

On Sun, Jan 15, 2017 at 9:07 PM, Andreas Tille wrote: > Is there any hint how this test can be run on the autopkgtest > hardware? It is unlikely any buildd, puiparts host or debci host has a GPU. Often they are virtual machines with only serial console for input if any. So the safe bet for

Re: debian/watch: FTP with version encoded (only) in directory

On Sun, Jan 8, 2017 at 3:55 AM, Ole Streicher wrote: > Thank you. I am however a bit afraid since this depends that upstream > keeps both really consistent. You could use the github tarball but I'm not sure how it differs from the stilts zipballs. > I will have a look; however it may be faster

Re: Mixed kloak anti keystroke / mice deanonymization tool package or better two separate packages?

On Sat, 2017-01-07 at 01:35 +, Patrick Schleizer wrote: > Would 'sudo systemctl mask kloak' be a good enough an option to > selectively disable that component etc.? That sounds reasonable to me, as long as it is documented. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: Mixed kloak anti keystroke / mice deanonymization tool package or better two separate packages?

On Sat, Jan 7, 2017 at 2:50 AM, Patrick Schleizer wrote: > kloak is an anti keystroke deanonymization tool. [1] A major enhancement > for the privacy software ecosystem. It's new and currently called a > prototype. We're currently discussing it [2] with upstream, Debian > packaging it [3] [4].

Re: debian/watch: FTP with version encoded (only) in directory

On Thu, Jan 5, 2017 at 10:40 PM, Ole Streicher wrote: > How can I get this right? With just the ftp site alone it can't work (see below), luckily for you there is a github page: http://www.star.bristol.ac.uk/~mbt/stilts/#install https://github.com/Starlink/starjava/releases So this monstrosity

Re: Build-Depends vs Depends

On Wed, Jan 4, 2017 at 1:52 AM, Taylor Kline wrote: > Thanks, that does help a lot, and it helped me to realize that the packages > are built on the Debian machines and sent to users already built, so there's > no need for the users to install the Build-Depends, right? Right, except users might

Re: Build-Depends vs Depends

On Fri, Dec 30, 2016 at 12:31 PM, Taylor Kline wrote: > What is the difference? How are they treated differently during the > apt installation process? Thanks :) You might be interested in looking at some of these diagrams to discover more about how Debian works:

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

On Fri, Dec 30, 2016 at 12:10 PM, Nicholas D Steeves wrote: > I'm collecting a list of mistakes I'm likely to make when I'm not 100% > focused on the work I'm doing; in the future, I plan to use it as a > personal checklist. If any of these mistakes fall into the "useful > for other new

Bug#832941: RFS: 4pane (debian: to exclusive)

On Sun, Dec 25, 2016 at 3:53 AM, David Hart wrote: > However will it be accepted into debian? The project is moribund: apart from a > single commit 3 years ago, it's been unmaintained for 6 years. That was > supposed to give time for a rewrite which hasn't happened. I might be a good idea for

Re: tool to rebuild all build-deps of a package

On Mon, Dec 19, 2016 at 1:54 PM, gustavo panizzo (gfa) wrote: > Is there any tool I can use to rebuild all packages which B-D/D on my > package? i want to do a local test before bumping it on the archive apt install ratt > Extra points for running the autopkgtests (if any) You should use

Re: Help: r-cran-treescape does not build on i386, armel and armhf any more

On Tue, Dec 13, 2016 at 3:47 PM, Andreas Tille wrote: > Well, adding xvfb was the usual trick to cope with "unable to open X11 > display" messages and thus I added it ... To me it looks like you didn't add it yet, at least not to the version in Debian. -- bye, pabs

Re: Help: r-cran-treescape does not build on i386, armel and armhf any more

On Mon, Dec 12, 2016 at 5:46 PM, Andreas Tille wrote: > I admit I do not only lack the hardware I'm also lacking experience to > track down this kind of problems. I discussed the issue with upstream > and they also do not have any clue. > > Any help would be really appreciated. Looking at the

reminder: Uploaders and RFS bug closing

Hi all, A reminder for those who aren't aware: The Uploaders field is for co-maintainers, not sponsors: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Uploaders RFS bugs should be closed with -done not debian/changelog: https://www.debian.org/Bugs/Developer#closing --

Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU]

On Wed, Nov 30, 2016 at 10:32 PM, Pranith Kumar wrote: > Bug#846348: RFS: capstone/4.0.0-next-0.1 [NMU] This should not be an NMU because the package is orphaned and you intend to adopt it. So you should change the version to 4.0.0-next-1, add yourself to the maintainer field and remove any

Re: when salvage a package?

On Wed, Nov 30, 2016 at 4:27 PM, Adam Borowski wrote: > Thus, popcon is useless here. The vote data should give some useful info about how many people used it recently. > If you think this software is important, it > is, and fixes would be welcome. Indeed. -- bye, pabs

Re: Copyright for Autoconf stuff

On Sat, Nov 26, 2016 at 3:51 AM, Russ Allbery wrote: > For those who think it's important to document the licenses of these > files, I would encourage you to work on writing a well-tested and reliable > tool to automatically generate those stanzas (the notices are fairly > consistent and open for

Re: upload to mentors

On Wed, Nov 23, 2016 at 11:04 PM, Werner Detter wrote: > both packages are now showing up. Thanks for your help, what was the > reason / the problem? One of the files in the upload queue was already in the incoming area so it was deleting it from the upload queue, but then that made the upload

<    1   2   3   4   5   6   7   8   9   10   >