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 them outside the main storage, ideally to a dedicated device (OpenPGP smart card or usb implementation of it), or at the very least an usb stick. I would feel safe sending my main disk out for repairs, since it has no crypto secrets (they are on a smartcard) nor confidential data (stored on different storage), but by the time it came back I would consider it compromised and requiring a full format + reinstall, so you might as well start by doing a wipe + basic reinstallation now before you send it away, to be sure that any interesting datai, including your deleted .gnupg, is very hard to retrieve. -- Elena ``of Valhalla''
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 source was not compiled - I just got an empty deb binary :/ I also had to keep the extra dh_auto_install because the compilation creates a .la file and this causes a lintian error. I was a little surprised - the only real difference I saw between debhelper 9 and 10 was that I didnt need to specify dh-autoreconf in the control build-depends BTW - is there a bug in mentors.debian.net because when I look at the package it says I'm using debhelper 9 and it gives me a lintian error that I'm missing dh-autoreconf? I've changed to a text based pgp signature and thus removed the include/binaries as requested. Copyright 2+ --> 3 has been corrected. I'm not sure what you meant by src:ido is RC buggy - libido3-0.1-dev is an essential package for both mate-indicator-applet and this applet compilation - same version exists in sid/stretch and ubuntu zesty. David On 11 November 2016 at 10:11, Gianfranco Costamagna wrote: > control: owner -1 ! > control: tags -1 moreinfo > > > > >> I am looking for a sponsor for my package "budgie-indicator-applet" > > > here we are: > > license seems wrong: > License: GPL-2+ > > but every file seems under GPL-3 (this seems to be probably not an issue, > just misleading) > > question: why can't you use compat level 10? > > this will avoid: autoreconf, dh-autoreconf, dh_install (not sure if needed) > and simplify the whole packaging > (with compat level 10 autoreconf is automatic, as well as parallel building) > > debian/source/include-binaries, please drop, and use a text public key > > build fails: > > checking for BUDGIE_PLUGIN... yes > checking for INDICATOR... no > configure: error: Package requirements (indicator3-0.4 >= 12.10.2 > libido3-0.1 >= 13.10) were not met: > > Requested 'indicator3-0.4 >= 12.10.2' but version of libindicator3 is 0.5.0 > > and src:ido is currently RC buggy, so you have to fix it if you want this one > to migrate. > > cheers, > > G.
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 dgit and at least understanding
it more, so I'm doing this.
First, a small review:
* be aware that I'm morally opposed to --link-doc, so good thing you
reverted that..
* 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?
* question: why don't you also sort the (build-)deps?
> % dgit sbuild || dgit gbp-build --git-pbuilder
> # ^ no source-only uploads to binNEW!
I use pbuilder, so I can't use `dgit sbuild`.
I also don't use gbp to build my package, but I usually `debuild -S`
them, then `cd ..` and `pbuilder b foo_123.dsc`, and depending on
whether I'm doing a source-only upload or a source+binary upload I
either upload that one foo_123_source.changes that debuild generated,
or the ~/pbuilder/results/sid/amd64/foo_123_amd64.changes that pbuilder
built (note how it's in a completely different directory).
Now, I understand I shouldn't run debuild directly on this but:
% dgit build-source
wants all the build-dependencies installed => no going to happen
digging through the manpage I ended up with
% dgit -wg build-source
cool, I have a .dsc now.
I can build it!
but:
tests/test_main.py
FFssFF.FFF.FFF..FF.F...
They are all like
tests/test_main.py:131:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
input_basename = 'ccitt.pdf', output_basename = 'test_quick.pdf'
env = {'CCACHEDIR': '/home/mattia/pbuilder/cache/ccache', 'CCACHE_DIR':
'/home/mattia/pbuilder/cache/ccache', 'CCACHE_PATH': '/usr/bin',
'CCACHE_UMASK': '000', ...}
args = (), input_file = '/build/ocrmypdf-4.3/tests/resources/ccitt.pdf'
output_file = '/build/ocrmypdf-4.3/tests/output/main/test_quick.pdf'
def check_ocrmypdf(input_basename, output_basename, *args, env=None):
"Run ocrmypdf and confirmed that a valid file was created"
input_file = _infile(input_basename)
output_file = _outfile(output_basename)
p, out, err = run_ocrmypdf(input_basename, output_basename, *args,
env=env)
if p.returncode != 0:
print('stdout\n==')
print(out)
print('stderr\n==')
print(err)
> assert p.returncode == 0
E assert 15 == 0
E+ where 15 = .returncode
tests/test_main.py:68: AssertionError
- Captured stdout call -
stdout
==
stderr
==
ERROR - [Errno 13] Permission denied
Is there some caveat I don't know?
Then, once I build this, should I e.g. place the built files (I suppose
I have to do a -b build, right, not -F?) in .. realtative to the
unpacked source tree and just dgit push?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
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 secure-delete' wil provide sdmem command, that will wipe the RAM. I suggest to use a live-CD or flash drive with Debian to boot in shell only mode and run sdmem. You can install Debian in a flash drive and use it. It is easy to do. Regards, Eriberto
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 mess. The creator didn't care about that process and so it contains a lot of cruft like a populated .git/, backup files, autotools debris, patches applied, you name it. Therefore I'd like to provide a clean and much smaller one, ideally one provided by upstream that was ignored in the past. However, there might be no newer upstream version so I'd have to replace foo_1.0.orig.tar.xz with new content, something I consider unfriendly[1] and that hopefully[2] gets blocked by technical means. Ideas so far: * 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. * Switch upstream tarball compression. This works, I found an upload[3] where -2 switched from .gz to .xz. Still rather a hack[4], and if this means going away from xz to something older, it feels wrong. Anything else I could do? It's all a bit first-world-problem-ish and, as I said, it's a theoretical question. In the actual cases (outside Debian) I could get out of this situation easily since either there was a new upstream version, or the source name was a misnomer and needed a change anyway. I don't expect to have that luck all the time. Christoph [1] In my opinion, every file in the Debian repositories that carries a version number should have unique content over all the time. I found some history .dsc files on snapshot.d.o that violate this idea, but I think I should not extend that list. [2] As this breaks the pool/ layout. [3] Compare http://snapshot.debian.org/archive/debian/20120317T153349Z/pool/main/f/file/file_5.11-1.dsc http://snapshot.debian.org/archive/debian/20120630T221249Z/pool/main/f/file/file_5.11-2.dsc [4] Mostly since the tarballs differ after decompression. signature.asc Description: Digital signature
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 way to get the package reviewed? The package is "quagga". [0] https://alioth.debian.org/tracker/index.php?func=detail&aid=315172 -- Regards, Scott. signature.asc Description: Digital signature
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 > mentors.debian.net that could check this for me? > > Failing that, is there an alternative way to get the package reviewed? > > The package is "quagga". > > [0] https://alioth.debian.org/tracker/index.php?func=detail&aid=315172 Hi, Confirmed. Two people whom I sponsor are having dificulties with some packages. There are packages that can be uploaded; other no. Thanks in advance. Regards, Eriberto
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 populated .git/, backup files, autotools > debris, patches applied, you name it. Therefore I'd like to provide a > clean and much smaller one, ideally one provided by upstream that was > ignored in the past. > > However, there might be no newer upstream version so I'd have to > replace foo_1.0.orig.tar.xz with new content, something I consider > unfriendly[1] and that hopefully[2] gets blocked by technical means. It is blocked indeed. > Ideas so far: > > * 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. +ds is what's usually used. > * Switch upstream tarball compression. This works, I found an upload[3] > where -2 switched from .gz to .xz. Still rather a hack[4], and if this > means going away from xz to something older, it feels wrong. Though it works and indeed it has been used. > Anything else I could do? It's all a bit first-world-problem-ish and, as > I said, it's a theoretical question. In the actual cases (outside > Debian) I could get out of this situation easily since either there was > a new upstream version, or the source name was a misnomer and needed a > change anyway. I don't expect to have that luck all the time. 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 information to be clearly visible, in this case in the form of a modified version. > [1] In my opinion, every file in the Debian repositories that carries a > version number should have unique content over all the time. I found > some history .dsc files on snapshot.d.o that violate this idea, but > I think I should not extend that list. you really found such things? 'cause really a file once stored in the archive really can't change. At least, as long as that file is known to dak, it can't change, once a distribution is archived you theoretically could upload the same filename with different content. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
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 > mentors.debian.net that could check this for me? > > Failing that, is there an alternative way to get the package reviewed? > > The package is "quagga". The package has been moved out of the way. Cheers, -- Nicolas Dandrimont signature.asc Description: Digital signature
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 that process and so it > contains a lot of cruft like a populated .git/, backup files, autotools > debris, patches applied, you name it. Therefore I'd like to provide a > clean and much smaller one, ideally one provided by upstream that was > ignored in the past. Get all those issues fixed upstream and release a new upstream version. -- bye, pabs https://wiki.debian.org/PaulWise
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.. does anyone on this list have admin access to > > mentors.debian.net that could check this for me? > > > > Failing that, is there an alternative way to get the package reviewed? > > > > The package is "quagga". > > The package has been moved out of the way. Great, thanks for your help! -- Regards, Scott. signature.asc Description: Digital signature
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 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 way to get the package reviewed? > > > > > > The package is "quagga". > > > > The package has been moved out of the way. > > Great, thanks for your help! Unfortunately, I spoke too soon.. the .buildinfo upload failed with 403 Forbidden again :( Would you be able to remove that file too? :) -- Regards, Scott. signature.asc Description: Digital signature
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-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) Yes - I'm adopting it! However I need to upload it somewhere first before I can file a RFS. -- Regards, Scott. signature.asc Description: Digital signature
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 uploader is something... strange) G.
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 reminding me of that. Done. > * question: why don't you also sort the (build-)deps? No particular reason. Done now. I've also updated to a new upstream bugfix release. Please pull both the dgit/sid and pristine-tar branches from my repo. New hashes: % git rev-parse dgit/sid 74fe61dff168a760edaf08cc5f8e497e8c0181d1 % sha256sum ../ocrmypdf_4.3.2.orig.tar.xz a935fd4c4e808ab41018e0c0b74d1f91047f3165aab96b692831247e9a25 ../ocrmypdf_4.3.2.orig.tar.xz > I use pbuilder, so I can't use `dgit sbuild`. > I also don't use gbp to build my package, but I usually `debuild -S` > them, then `cd ..` and `pbuilder b foo_123.dsc`, and depending on > whether I'm doing a source-only upload or a source+binary upload I > either upload that one foo_123_source.changes that debuild generated, > or the ~/pbuilder/results/sid/amd64/foo_123_amd64.changes that pbuilder > built (note how it's in a completely different directory). > > Now, I understand I shouldn't run debuild directly on this but: > % dgit build-source > wants all the build-dependencies installed => no going to happen > > digging through the manpage I ended up with > % dgit -wg build-source > > cool, I have a .dsc now. > I can build it! > > [...] > > Then, once I build this, should I e.g. place the built files (I suppose > I have to do a -b build, right, not -F?) in .. realtative to the > unpacked source tree and just dgit push? That's a perfectly reasonable way to use dgit. Don't use -b/-F. Instead: % dgit -wg build-source || ( git clean -xdf ; debuild -S -nc ) % pdebuild % dgit --build-products-dir=~/pbuilder/resuilts/sid/amd64 push since you have to do a binary upload to binNEW. 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)? > but: tests/test_main.py > FFssFF.FFF.FFF..FF.F... > > They are all like > > [...] > > stderr > == > ERROR - [Errno 13] Permission denied > > > Is there some caveat I don't know? Please try turning off your pbuilder tmpfs. That worked last time, when you originally sponsored ocrmypdf. Or you could just use deb-o-matic. Thank you again for your time! -- Sean Whitton signature.asc Description: PGP signature
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 be able to remove that file too? :) AFAIK, there is a cronjob that removes the incomplete uploads after some time -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
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 80c5a87b087f56b90cbd10be3bc14dd066b9fae1 -- Sean Whitton signature.asc Description: PGP signature
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 pretty much impossible, short of using the secure erase features of an SSD and trusting it to implement that correctly -- or using undocumented SSD firmware bypass commands, which might not even exist in the first place, etc -- to get an SSD to really erase data from the RAW flash. > Even overwriting the block device does not necessarily remove them from an > SSD: In any SSD worth something, overwriting a sector will *never* remove the old data, as it will always be directed to some other flash block. It just schedules the old block for eventual garbage collection and erasure. Even trimming a sector won't erase the flash. The only thing that is supposed to work is to command the SSD to secure-erase itself, and that depends on the manufacturer doing its job right in the first place. Alternatively, using dmcrypt-based FDE, and trashing the encryption key will give you an erase level that is at least as strong as the strength of your passphrase. > I strongly suggest removing the SSD before sending the device. Indeed. -- Henrique Holschuh
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, even... -- Henrique Holschuh
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 upstream tarball compression. This works, I found an upload[3] > where -2 switched from .gz to .xz. Still rather a hack[4], and if this > means going away from xz to something older, it feels wrong. This is going to get people wondering what you were up to. Don't do it. -- Henrique Holschuh
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 destructive mode, and it does > use a lot of very nasty bit-walking patterns to do it, even... Hum, a good catch. I never tested this procedure. But it is a interesting thing to try. You can test it and use lime-forensics (already packaged) + strings/grep commands to do a quick analysis. I will test it soon. But it seems a good idea too. Thanks! Eriberto
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 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.)
--
843430: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843430
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for a new release of ocrmypdf.
I have DM upload rights for this package, but this revision introduces a
new binary package, ocrmypdf-doc.
* Package name: ocrmypdf
Version : 4.3-1
Upstream Author : James R. Barlow
* URL : https://github.com/jbarlow83/OCRmyPDF
* License : Expat
Section : graphics
Changes since the last upload:
* New upstream release.
- Remove dropped tasks.py from d/copyright.
* New ocrmypdf-doc binary package: upstream's new HTML documentation.
- Set PYBUILD_DESTDIR in d/rules.
- Add override_dh_{auto_build,installdocs,sphinxdoc} targets to d/rules.
- ocrmypdf suggests python-watchdog.
See "Cookbook" documentation entry.
- New build dependencies:
- python3-sphinx
- python3-sphinx-rtd-theme
* Add doc-base registration.
* Add patch-docs-for-Debian.patch
* Add path-to-docs-for-Debian.patch
* Add disable-mathjax.patch
* Add pip-to-apt-get.patch
* Bump debhelper compat & build-dep to 10.
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.
% git clone https://git.spwhitton.name/ocrmypdf
% cd ocrmypdf
% git rev-parse HEAD
14ee9e157b2347d13c0dc90316514db8c36cb9c5
% origtargz # invokes pristine-tar to extract orig.tar
% sha256sum ../ocrmypdf_4.3.orig.tar.xz
dc79c4078e1fd0cb8fa5c010f418fc00a7683da3f27add7477289e38daf07b02
../ocrmypdf_4.3.orig.tar.xz
% dgit fetch
% git diff dgit/dgit/sid..HEAD # review my changes
% git diff dgit/dgit/sid..HEAD -- debian # review just debian/ changes
% dgit sbuild || dgit gbp-build --git-pbuilder
# ^ no source-only uploads to binNEW!
% dgit push
If you have any trouble with this, I'd appreciate if you'd ask me about
it rather than doing an upload that bypasses dgit, as that would break
the history on dgit-repos. I'm interested in making sponsorship with
dgit a smooth and well-documented process.
Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Sat, Nov 12, 2016 at 08:26:48AM -0700, Sean Whitton wrote:
> That's a perfectly reasonable way to use dgit. Don't use -b/-F.
-F is the deafault if you don't specify anything, so well, I've used -F
:P
> 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 or two.
> Please try turning off your pbuilder tmpfs. That worked last time, when
> you originally sponsored ocrmypdf. Or you could just use deb-o-matic.
oh...
I forgot about this!
you know, a lot of stuff happened since that time :)
| dgit ok: pushed and uploaded 4.3.2-2
\o/
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
--- End Message ---
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 or two. I've filed #844125, #844128, #844129 and #844131 based on our discussion on IRC. > | dgit ok: pushed and uploaded 4.3.2-2 > > \o/ Thanks again, especially for finding several potential improvements to dgit in the process. -- Sean Whitton signature.asc Description: PGP signature
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 Maintainer QA Team and a real uploader is something... strange) Ah, this is about quagga. I'm only taking care of emergencies (which lately includes minor security bugs) in unstable. You can drop me as an uploader. (I do not use quagga anymore.)
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 hylafax-client-dbg_6.0.6-7_amd64.deb: done. > Uploading hylafax-client_6.0.6-7_amd64.deb: done. > Uploading hylafax-server-dbg_6.0.6-7_amd64.deb: done. > Uploading hylafax-server_6.0.6-7_amd64.deb: done. > Uploading hylafax_6.0.6-7_20161112T094537z-0e26557c.buildinfo: done. > Uploading hylafax_6.0.6-7_amd64.changes: done. > Successfully uploaded packages. Thank you for sponsoring. Is that o.k. that until now the new package is not visible on the qa.debian.org site ? --- Have a nice day. Joachim (Germany) pgp7KibyUv6nN.pgp Description: Digitale Signatur von OpenPGP
Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software
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 `-
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 maybe > >>you'd want to take a look at those packages how they do their build. > > I'm far from being a java expert, but IIRC maven tries to download from > internet or create such directories when a dependency is not available. > > Solution: package it, and add it to control file, and try again. 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 contain all of the bits required to build the desired binary package(s), either as dependencies on other Debian packages or (and only for a non-free package) as JAR files included with the source package. As Christian points out, Maven will happily attempt to download dependencies. For a non-free Java package, those Maven Central dependencies need to be available on the local file system and all references to them updated to use scope and the path where they can be found. (There might be an easier way to accomplish this, but this is the one I'm familiar with.) Cheers, tony
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 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 populated .git/, backup files, autotools > > debris, patches applied, you name it. Therefore I'd like to provide a > > clean and much smaller one, ideally one provided by upstream that was > > ignored in the past. > > Get all those issues fixed upstream and release a new upstream version. If such a messed up tarball was created by upstream, I wouldn't ask in Debian how to resolve that. Also, I'd probably not start maintaining such a package since I'd rather not trust upstream is doing good development if the provided result is in such a bad state. However, I have seen a lot of poorly organized .orig.tar.* balls, appearently created by careless Debian maintainers. Some even just a few weeks ago; and I was wondering how I could hypothetically deal with them. Again, no names in the public as I'm not interested in blaming. Christoph signature.asc Description: Digital signature
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 information > to be clearly visible, in this case in the form of a modified version. Thanks, this seems a sound concept. > > [1] In my opinion, every file in the Debian repositories that carries a > > version number should have unique content over all the time. I found > > some histor[ic] .dsc files on snapshot.d.o that violate this idea, but > > I think I should not extend that list. > > you really found such things? > 'cause really a file once stored in the archive really can't change. > At least, as long as that file is known to dak, it can't change, once a > distribution is archived you theoretically could upload the same > filename with different content. See http://snapshot.debian.org/package/file/4.17-5etch2/ :) I guess this could happen since one upload was for debian (presumably stable-proposed-updates), the other one for debian-security. Still I'd recommend not to try this again. Christoph signature.asc Description: Digital signature
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 contain all of the bits required to build the desired > binary package(s), either as dependencies on other Debian packages or > (and only for a non-free package) as JAR files included with the > source package. > > As Christian points out, Maven will happily attempt to download > dependencies. For a non-free Java package, those Maven Central > dependencies need to be available on the local file system and all > references to them updated to use scope and the path where > they can be found. (There might be an easier way to accomplish this, > but this is the one I'm familiar with.) Thanks to everyone for replying. All your comments make sense. My observation was mostly in the direction of a package version that was accepted to Debian and that required pulling Maven dependencies from online and/or not rellying on those provided by the system (namely, in a source package for Scala 2.10.5). I'm just trying to revive that package in the current context (i.e. with the current Debian OS releases) so I found it surprising to see something like this made it into Debian at some point. I'll look at later package versions (i.e., after 2.10.5-1) and try to see if and when something like this was fixed. -- Regards, Marko Dimjašević https://dimjasevic.net/marko PGP key ID: 1503F0AA Learn email self-defense! https://emailselfdefense.fsf.org signature.asc Description: This is a digitally signed message part
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 generated packages in the correct sections for an elpafied package? Is removing hrefs to favicon.ico (Bug: #775885) sufficient? Distributing a favicon.ico seems unnecessary and honestly, I'm against it. In Canada, because the author retains all distribution rights in the absence of a license or declared copyright, even something as trivial as a favicon.ico can be unredistributable. I couldn't find the license on Michael Olson's website , so I decided it was best not to copy it. Do my patches look ok? Should elpafied packages continue to be arch-independent? Is debian/changelog too verbose and could it be condensed? Package name: muse-el Version : 3.20+dfsg-1 Section : editors It builds those binary packages: elpa-muse - Author and publish projects using Wiki-like markup muse-el- transitional dummy package for elpa-muse. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/muse-el Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+dfsg-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: muse-el (3.20+dfsg-1) unstable; urgency=medium * New Maintainer. * debian/control: - Bump required debhelper to >=9. - Update emacs dependency. - Add emacs-goodies-el dependency, which provides htmlize.el. * Switch to debcompat 9; Switch to 3.0 (quilt) non-native packaging. * Add patch to fix privacy breaches; removes hrefs. (Closes: #775885) * Elpafy! (depends on dh-elpa). * Add patch to disable non-DFSG compliant texi stuff. * Install docs and examples the new dh_way. * debian/rules: - add override to build examples and autoloads. - add override to install upstream changelog series. * debian/copyright: - Fix misattributed source (found by comparing timestamps in comments between gna.org tarballs and git sources). - Update format. - Add debian/* section. * Include images used by the QuickStart.muse example. (Closes: #720121) * Add patch to use Debian's "see" command instead of "open". Thank you Kevin Ryde, I didn't know about the existence of "see" before reading this bug report. (Closes: #720126) * Patch README to explain how installed files relate to src:muse-el. -- Nicholas D Steeves Tue, 18 Oct 2016 20:58:45 -0400 Regards, Nicholas D Steeves
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 release of fvwm in Debian. I have created a source package for review along with have had a short correspondence with the current maintainer, sharing my work with him. The current maintainer said he no longer uses fvwm and if I'm willing to take responsibility I am welcomed to. I have shared my work with the maintainer but besides that one short email, he has not gotten back to me. Once this bug is submitted, I will send the bug ID to the maintainer and ask for him to respond publicly for verification. This will be the first package I have maintained, yet I am an active member of the #debian irc community where I go by "somiaj". A copy of the source (and other files generated) can be found at: http://fvwmforums.org/fvwm-2.6.7/ My changelog to update the package to 2.6.7: fvwm (1:2.6.7-1) unstable; urgency=low * Complies with Policy v3.9.8. * New upstream version. (Closes: #820425) - Fvwm now has a default config. See /usr/share/doc/fvwm/NEWS.Debian.gz - Removed the following modules: FvwmDragWell, FvwmGTK, FvwmSave, FvwmSaveDesk, FvwmScroll, FvwmTabs, FvwmTaskBar, FvwmTheme, FvwmWharf, FvwmWinList, FvwmWindowMenu, FvwmIconBox. - fvwm-menu-desktop updated (now a python script). (Closes: #808292) - New features and bug fixes. For a full list between 2.6.5 and 2.6.7 see /usr/share/doc/fvwm/NEWS.gz * Removed the old system.fvwm2rc config examples. * Upstream moved from cvs to git. Updated watch file. * Removed old Debian menu methods. Use XDG menus with fvwm-menu-desktop. * html documentation no longer built (outdated/broken links). * Package build is reproducible. (Closes: #831646) * Fixed conflicting array sizes of TabCom. (Closes: #801612) * Upstream no longer includes a debian/ directory, so Debian no longer has to repackage the upstream source without debian/. Removed .ds from version. Thanks for your consideration, 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. > > mentors.d.n does not accept .buildinfo files yet > > > > > Would you be able to remove that file too? :) > > AFAIK, there is a cronjob that removes the incomplete uploads after some time Okay, I'll give this a shot. Thanks for your help. -- Regards, Scott. signature.asc Description: Digital signature
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
