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
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
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 dgit
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 secure
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
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
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
> mentors.debian.net that could chec
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 popula
* 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
> mentors.debian.net that could
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 th
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.. does anyone on t
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 partially uploaded packag
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.
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)
Ye
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 upload
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
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
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
80c5a87b087f56b90cbd10be3bc14dd066b9
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
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, even.
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 u
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 destructive mode, and it
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 that
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 b
* 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 Mai
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 hylafax-client-dbg_6.0.6-7_amd6
Joachim Wiedorn wrote:
> Is that o.k. that until now the new package is not visible
> on the qa.debian.org site ?
Huh, odd.. Not sure what's going on there, sorry.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
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 maybe
>
>>you'd want to take a
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 t
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
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 cont
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 genera
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
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.
>
> m
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
35 matches
Mail list logo
