Bug#844185: RFS: fvwm/2.6.7 (Update)

Hello, I was running a test in a clean build environment and found an error with lintian. This has been fixed. I also updated the maintainers name to mine in the control file. The files for review have been updated. http://fvwmforums.org/fvwm-2.6.7/ jaimos

Re: debexpo bug on upload

On 2016-11-12.23:59, gustavo panizzo (gfa) wrote: > On Sun, Nov 13, 2016 at 01:20:46AM +1100, Scott Leggett wrote: > > > Unfortunately, I spoke too soon.. the .buildinfo upload failed with 403 > > Forbidden again :( > Remove the .buildinfo line from the .changes file, then sign and upload. > >

Bug#844185: RFS: fvwm/2.6.7 [ITA] -- f? virtual window manager

Package: sponsorship-requests Severity: normal Hello mentors, I am looking for a sponsor for me to maintain the package fvwm: Package name: fvwm Version: 2.6.7 Upstream Author: fvwm-work...@fvwm.org URL: http://fvwm.org License: GPL-2 Section: x11 I am looking to update and maintain the latest

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

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for review and a sponsor for my package "src:muse-el". I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and any emacs-on-Debian integration issues. Here are a few things I'm wondering about: Are the

Re: Scala 2.10

Hi all, On Sat, 2016-11-12 at 15:22 -0800, tony mancill wrote: > For Marko's purposes, which IIRC, are to create a non-free package to > avoid the circular dependency scala has upon itself, packaging all of > the build dependencies isn't strictly necessary. However, the source > package must

Re: Modernizing the upstream tarball without version number change

Mattia Rizzolo wrote... > Personally, I'd just repack, appending +ds to the upstream version. > I find switching compression scheme just for the sake of repacking, an > ugly hack; I really really prefer to be shipping whatever upstream > provided me, and if I can't/don't want to do so I want that

Re: Modernizing the upstream tarball without version number change

Paul Wise wrote... > On Sat, Nov 12, 2016 at 9:12 PM, Christoph Biedl wrote: > > > disclaimer: This is a theoretical situation > > Ahem. Yes? My intention was to signalize a "I'm not in a hurry". > > Assuming I took over maintainership for a package with upstream. So > > there is an upstream

Re: Scala 2.10

On Thu, Nov 10, 2016 at 11:39 PM, Gianfranco Costamagna wrote: >>I'm not in the Java packaging community, but from a little searching >>.m2 appears to be created by the Maven build system, and I know for >>sure there is software packaged in Debian that uses Maven, so

Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software

Hello Chris, Chris Lamb wrote on 2016-11-12 09:48: > Uploading to ftp-master (via ftp to ftp.upload.debian.org): > Uploading hylafax_6.0.6-7.dsc: done. > Uploading hylafax_6.0.6.orig.tar.gz: done. > Uploading hylafax_6.0.6-7.debian.tar.xz: done. > Uploading

Re: debexpo bug on upload

* Gianfranco Costamagna: >>Yes - I'm adopting it! >> >>However I need to upload it somewhere first before I can file a RFS. > > > this is true, I'm ccing Florian, because the package has an active > uploader, so I think you should get in touch with him before asking > for a sponsor :) > > (BTW

Bug#843430: RFS: ocrmypdf/4.3-1

Hello, On Sat, Nov 12, 2016 at 05:51:50PM +, Mattia Rizzolo wrote: > > Do you think this could be better documented? I guess there is no > > manpage corresponding to your workflow. Maybe it could be added to > > dgit-maint-merge(7)? > > I think I'm going to think about it and maybe open a

Bug#843430: marked as done (RFS: ocrmypdf/4.3.2-1)

Your message dated Sat, 12 Nov 2016 17:51:50 + with message-id <20161112175148.okhdlw2rqg5us...@chase.mapreri.org> and subject line Re: Bug#843430: RFS: ocrmypdf/4.3-1 has caused the Debian Bug report #843430, regarding RFS: ocrmypdf/4.3.2-1 to be marked as done. This means that you claim

Re: Best GPG practices before sending computer to maintenance.

2016-11-12 15:03 GMT-02:00 Henrique de Moraes Holschuh : > On Sat, 12 Nov 2016, Eriberto Mota wrote: >> There is another point to be considered: the RAM memory. The data, > > Eriberto, would a full pass of memtest86 work as well? > > It is supposed to test the entire RAM in

Re: Modernizing the upstream tarball without version number change

On Sat, 12 Nov 2016, Christoph Biedl wrote: > * Fake a new upstream version number, like foo_1.0a.orig.tar.xz. > Yes, it's faking. Using "+repack" is more obvious but still means > this gets carried into the Debian version number. This is the recommended way of doing things, yes. > * Switch

Re: Best GPG practices before sending computer to maintenance.

On Sat, 12 Nov 2016, Eriberto Mota wrote: > There is another point to be considered: the RAM memory. The data, Eriberto, would a full pass of memtest86 work as well? It is supposed to test the entire RAM in destructive mode, and it does use a lot of very nasty bit-walking patterns to do it,

Re: Best GPG practices before sending computer to maintenance.

On Sat, 12 Nov 2016, Paul Wise wrote: > On Sat, Nov 12, 2016 at 1:26 PM, Johannes Schauer wrote: > > If you are just worried about GPG, then removing .gnupg should be all you > > need > > to do. > > Deleting files does not remove the data from the block device, it only > removes metadata. It is

Bug#843430: RFS: ocrmypdf/4.3-1

On Sat, Nov 12, 2016 at 08:26:48AM -0700, Sean Whitton wrote: > I've also updated to a new upstream bugfix release. Please pull both > the dgit/sid and pristine-tar branches from my repo. Sorry, forgot to update the manpage. % git rev-parse dgit/sid

Re: debexpo bug on upload

On Sun, Nov 13, 2016 at 01:20:46AM +1100, Scott Leggett wrote: > Unfortunately, I spoke too soon.. the .buildinfo upload failed with 403 > Forbidden again :( Remove the .buildinfo line from the .changes file, then sign and upload. mentors.d.n does not accept .buildinfo files yet > > Would you

Bug#843430: RFS: ocrmypdf/4.3-1

control: tag -1 -moreinfo control: retitle -1 RFS: ocrmypdf/4.3.2-1 Hello Mattia, On Sat, Nov 12, 2016 at 01:00:14PM +, Mattia Rizzolo wrote: > * policy 3.9.7 recommend to install the docs in /usr/share/doc/$mainpkg > instead of /usr/share/doc/$mainpkg-doc/ care to move them? Thanks for

Re: debexpo bug on upload

Hi, >Yes - I'm adopting it! > >However I need to upload it somewhere first before I can file a RFS. this is true, I'm ccing Florian, because the package has an active uploader, so I think you should get in touch with him before asking for a sponsor :) (BTW Maintainer QA Team and a real

Re: debexpo bug on upload

On 2016-11-12.14:25, Gianfranco Costamagna wrote: > Hi, > > >The package is "quagga". > > please wait for mentors to be fixed and open an RFS bug. > or upload somewhere else, but really open a bug. > > otherwise probably nobody will look at it > (and there is already a quagga in the archive)

Re: debexpo bug on upload

Hi, >The package is "quagga". please wait for mentors to be fixed and open an RFS bug. or upload somewhere else, but really open a bug. otherwise probably nobody will look at it (and there is already a quagga in the archive) G.

Re: debexpo bug on upload

On 2016-11-13.01:11, Scott Leggett wrote: > On 2016-11-12.15:02, Nicolas Dandrimont wrote: > > * Scott Leggett [2016-11-13 00:06:39 +1100]: > > > > > Hi, > > > > > > I've run into a bug[0] with debexpo making it impossible to upload my > > > package. I suspect there's a

Re: debexpo bug on upload

On 2016-11-12.15:02, Nicolas Dandrimont wrote: > * Scott Leggett [2016-11-13 00:06:39 +1100]: > > > Hi, > > > > I've run into a bug[0] with debexpo making it impossible to upload my > > package. I suspect there's a partially uploaded package sitting in the > > system somewhere..

Re: Modernizing the upstream tarball without version number change

On Sat, Nov 12, 2016 at 9:12 PM, Christoph Biedl wrote: > disclaimer: This is a theoretical situation Ahem. > Assuming I took over maintainership for a package with upstream. So > there is an upstream tarball foo_1.0.orig.tar.xz but, quite frankly, > it's a mess. The creator didn't care about

Re: debexpo bug on upload

* Scott Leggett [2016-11-13 00:06:39 +1100]: > Hi, > > I've run into a bug[0] with debexpo making it impossible to upload my > package. I suspect there's a partially uploaded package sitting in the > system somewhere.. does anyone on this list have admin access to >

Re: Modernizing the upstream tarball without version number change

On Sat, Nov 12, 2016 at 02:12:23PM +0100, Christoph Biedl wrote: > disclaimer: This is a theoretical situation pfff :) > there is an upstream tarball foo_1.0.orig.tar.xz but, quite frankly, > it's a mess. The creator didn't care about that process and so it > contains a lot of cruft like a

Re: debexpo bug on upload

2016-11-12 11:06 GMT-02:00 Scott Leggett : > Hi, > > I've run into a bug[0] with debexpo making it impossible to upload my > package. I suspect there's a partially uploaded package sitting in the > system somewhere.. does anyone on this list have admin access to >

debexpo bug on upload

Hi, I've run into a bug[0] with debexpo making it impossible to upload my package. I suspect there's a partially uploaded package sitting in the system somewhere.. does anyone on this list have admin access to mentors.debian.net that could check this for me? Failing that, is there an alternative

Modernizing the upstream tarball without version number change

disclaimer: This is a theoretical situation Hello, there is a problem where I could use some advice about a sane way or best practise to get out of it: Assuming I took over maintainership for a package with upstream. So there is an upstream tarball foo_1.0.orig.tar.xz but, quite frankly, it's a

Re: Best GPG practices before sending computer to maintenance.

Hi Charles, I am a forensics teacher. There is another point to be considered: the RAM memory. The data, commonly, pass across RAM and is easy get the key from a memory dump (even if the computer was turned off). So, after take care of the SDD, you need to wipe the RAM. An 'apt-get install

Bug#843430: RFS: ocrmypdf/4.3-1

control: owner -1 ! control: tag -1 moreinfo On Sun, Nov 06, 2016 at 09:59:01AM -0700, Sean Whitton wrote: > I normally upload ocrmypdf with dgit, so I'd like to request sponsorship > using dgit so that the git history on dgit-repos is not interrupted. As I said, I'm interested in trying out

Bug#843378: RFS: budgie-indicator-applet/0.1-1 ITP

Hi Gianfranco, I've submitted a revised package - since this required source changes the version has changed to 0.2 I've changed to debhelper 10 as recommended. Note however - when testing on sid and ubuntu zesty I still had to use in the rules dh $@ --with autoreconf without the clause, the

Re: Best GPG practices before sending computer to maintenance.

On 2016-11-12 at 17:15:49 +1100, Ben Finney wrote: > The best practice is: Use full-disk encryption. The only cost to this is > setting it up before you start using the storage device, and entering > the passphrase every time you start it. or, if you're only worried about gpg (and ssk keys), move