Bug#882872: First stab at functionality for copying files

[Benj. Mako Hill]

Greetings!


> Your patch looks good to me and works as promised, thanks!  Before forwarding
> it to upstream, we need an appropriate update of vidir documentation.  Are you
> interested in preparing that?  (If not, I can do it.)

Sorry I lost track of this. Are we still waiting on documentation? If
so, I'm happy to do this so that this can land.

Regards,
Mako

-- 
Benjamin Mako Hill
https://mako.cc/


signature.asc
Description: PGP signature

Bug#1069883: most: copyright - mark the ftp:// address not available (N/A)

[Benj. Mako Hill]

Thanks for catching that. I'll update the URL with the next upload.

Regards,
Mako




> Package: most
> Version: 5.2.0-1+b1
> Severity: minor
> 
> https://metadata.ftp-master.debian.org/changelogs//main/m/most/most_5.2.0-1_copyright
> 
> Suggest to add a note[1], that the sources are no longer available
> at the location:
> 
> This package was put together by Chris Fearnley ,
> from the GNU sources, which I obtained from
>   ftp://space.mit.edu/pub/davis/most/
> 
> => 
> 
> This package was put together by Chris Fearnley ,
> from the GNU sources, which I obtained from
>   ftp://space.mit.edu/pub/davis/most/
> As of 2024-04-26 the sources are no longer avilable
> 
> [1]
> lftp ftp://space.mit.edu/pub/davis/most/
> cd: Access failed: 550 No such directory. (/pub/davis/most)
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages most depends on:
> ii  libc6  2.37-15
> ii  libslang2  2.3.3-3+b1
> 
> most recommends no packages.
> 
> most suggests no packages.
> 
> -- no debconf information
> 

-- 
Benjamin Mako Hill
https://mako.cc/


signature.asc
Description: PGP signature

Bug#568834: First stab at functionality for copying files

[Benj. Mako Hill]

Greetings!

This is just a followup to say that I've been using the patch for
about two years now and have not noticed any trouble. I use the
copying files functionality in vidir nearly every day!

If someone wants to take a more active role in maintaince and needs a
hand, let me know.

Regards,
Mako



> tags 882872 patch
> thanks
> 
> Greetings!
> 
> Thanks for maintaining moreutils! It's one of the packages I love most
> in Debian!
> 
> I'm attaching a first stab a patch to add copying file support to
> vidir (i.e., #882872) which is something I've wanted for a very long
> time and just broke down and did today.
> 
> It's been quite a while since I've written Perl and I'm not 100% sure
> that I've thought the logic through completely so as to avoid all
> possible corner cases (e.g., related to every way one would swap
> filenames and/or copy things repeatedly).
> 
> The way it works is much simpler than the model suggested in #568834,
> (which, BTW, sounds very nice): If a line number shows up twice in the
> vidir output—and if the two filenames associated with the lines
> numbers—are different, the file gets copied. That's it. :)
> 
> Regards,
> Mako
> https://mako.cc/





-- 
Benjamin Mako Hill
https://mako.cc/


signature.asc
Description: PGP signature

Bug#990797: most: upstream is now 5.2.0 (was: most: Please package new upstream release (5.1.0))

[Benj. Mako Hill]

> the upstream version of most is now at 5.2.0.

I will upload a new version. Thanks for the heads up.

Later,
Mako



-- 
Benjamin Mako Hill
https://mako.cc/

Bug#965691: Bug#998984: libtext-wikiformat-perl: diff for NMU version 0.79-1.2

[Benj. Mako Hill]

Greetings Gregor!

Thank you for doing this! I apprecaited the help! I'll take a look and
let you know if you should delay it.

Regards,
Mako



> Control: tags 965691 + patch
> Control: tags 965691 + pending
> Control: tags 998984 + patch
> Control: tags 998984 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for libtext-wikiformat-perl (versioned as 0.79-1.2) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>`-   NP: Jimi Hendrix: Hear My Train A Comin'





-- 
Benjamin Mako Hill
https://mako.cc/

Bug#472311: Merge duplicates bugs in most

[Benj. Mako Hill]

severity 472311 wishlist
forwarded 472311 j...@jedsoft.org
merge 472311 585566
thanks

Greetings!

I embarrassed for fixing this up before but I realize that these two
bugs are duplicates. I'll clean this up now before I close these with
an upload I'm preparing now.

Regards,
Mako

-- 
Benjamin Mako Hill
https://mako.cc/academic/


signature.asc
Description: PGP signature

Bug#987405: most has mailcap entries with quoted %-escapes

[Benj. Mako Hill]

Thanks for this (and for the patch)! I'll take a look at it right
away. It looks quite straightforward.

Regards,
Mako


-- 
Benjamin Mako Hill
https://mako.cc/


signature.asc
Description: PGP signature

Bug#568834: First stab at functionality for copying files

[Benj. Mako Hill]

Greetings!


> It's been quite a while since I've written Perl and I'm not 100% sure
> that I've thought the logic through completely so as to avoid all
> possible corner cases (e.g., related to every way one would swap
> filenames and/or copy things repeatedly).

I'm attaching an updated and better version of the patch. It's
stylistically more consistent and fixes at least one bug/corner case.

It's obviously still be good to have someone look at it and think
through through this a little before it's applied.

In any case, I'm using it now and will try to stress test it and
figure out what the corner cases are.

Later,
Mako


-- 
Benjamin Mako Hill
https://mako.cc/
--- /home/mako/bin/vidir	2021-04-02 17:24:01.718977602 -0700
+++ /usr/bin/vidir	2019-08-18 06:27:38.0 -0700
@@ -81,7 +81,6 @@
 use File::Path qw(make_path);
 use File::Spec;
 use File::Temp;
-use File::Copy;
 use Getopt::Long;
 
 my $error=0;
@@ -144,7 +143,6 @@
 	die "@editor exited nonzero, aborting\n";
 }
 
-my %finished_item;
 open (IN, $tmp->filename) || die "$0: cannot read ".$tmp->filename.": $!\n";
 while () {
 	chomp;
@@ -152,26 +150,7 @@
 		my $num=int($1);
 		my $name=$2;
 		if (! exists $item{$num}) {
-			# attempt to copy files if a duplicate of a number we've already seen before
-			if (exists $finished_item{$num}) {
-if ($name eq $finished_item{$num}) {
-	print STDERR "$0: cannot copy because source ($finished_item{$num}) and destination ($name) are the same\n";
-} 
-elsif (-e $name || -l $name) {
-	print STDERR "$0: cannot copy because destination ($name) already exists\n";
-}
-elsif (! (-e $finished_item{$num} || -l $finished_item{$num})) {
-	print STDERR "$0: cannot copy because source ($finished_item{$num}) does not exist\n";
-}
-elsif (! copy($finished_item{$num}, $name)) {
-	print STDERR "$0: failed to copy $finished_item{$num} to $name: $!\n";
-	$error=1;
-}
-next;
-			}
-			else {
-die "$0: unknown item number $num\n";
-			}
+			die "$0: unknown item number $num\n";
 		}
 		elsif ($name ne $item{$num}) {
 			next unless length $name;
@@ -227,7 +206,6 @@
 }
 			}
 		}
-		$finished_item{$num} = $name;
 		delete $item{$num};
 	}
 	elsif (/^\s*$/) {


signature.asc
Description: PGP signature

Bug#882872: First stab at functionality for copying files

[Benj. Mako Hill]

tags 882872 patch
thanks

Greetings!

Thanks for maintaining moreutils! It's one of the packages I love most
in Debian!

I'm attaching a first stab a patch to add copying file support to
vidir (i.e., #882872) which is something I've wanted for a very long
time and just broke down and did today.

It's been quite a while since I've written Perl and I'm not 100% sure
that I've thought the logic through completely so as to avoid all
possible corner cases (e.g., related to every way one would swap
filenames and/or copy things repeatedly).

The way it works is much simpler than the model suggested in #568834,
(which, BTW, sounds very nice): If a line number shows up twice in the
vidir output—and if the two filenames associated with the lines
numbers—are different, the file gets copied. That's it. :)

Regards,
Mako


-- 
Benjamin Mako Hill
https://mako.cc/
--- /home/mako/bin/vidir	2021-04-02 16:48:20.646390946 -0700
+++ /usr/bin/vidir	2019-08-18 06:27:38.0 -0700
@@ -81,7 +81,6 @@
 use File::Path qw(make_path);
 use File::Spec;
 use File::Temp;
-use File::Copy;
 use Getopt::Long;
 
 my $error=0;
@@ -144,7 +143,6 @@
 	die "@editor exited nonzero, aborting\n";
 }
 
-my %finished_item;
 open (IN, $tmp->filename) || die "$0: cannot read ".$tmp->filename.": $!\n";
 while () {
 	chomp;
@@ -152,24 +150,7 @@
 		my $num=int($1);
 		my $name=$2;
 		if (! exists $item{$num}) {
-			# copy files if a dupliate of a number we've already seen before
-			if (exists $finished_item{$num}) {
-if ($name eq $finished_item{$num}) {
-	print STDERR "$0: cannot copy because source ($finished_item{$num}) and destination ($name) are the same\n";
-	delete $item{$num};
-} elsif (-e $name || -l $name) {
-	print STDERR "$0: cannot copy because destination ($name) already exists\n";
-	delete $item{$num};
-} elsif (! (-e $finished_item{$num} || -l $finished_item{$num})) {
-	print STDERR "$0: cannot copy because $finished_item{$num} does not exist\n";
-	delete $item{$num};
-} elsif (! copy($finished_item{$num}, $name)) {
-	print STDERR "$0: failed to copy $finished_item{$num} to $name: $!\n";
-	$error=1;
-}
-			} else {
-die "$0: unknown item number $num\n";
-			}
+			die "$0: unknown item number $num\n";
 		}
 		elsif ($name ne $item{$num}) {
 			next unless length $name;
@@ -225,7 +206,6 @@
 }
 			}
 		}
-		$finished_item{$num} = $name;
 		delete $item{$num};
 	}
 	elsif (/^\s*$/) {


signature.asc
Description: PGP signature

Bug#930007: closed by Debian FTP Masters (reply to Andres Salomon ) (Bug#930007: fixed in dtrx 8.0.1+git20200717-2)

[Benj. Mako Hill]

Thanks for fixing this Andres and for giving the time and attention to
dtrx!

Regards,
Mako



> This is an automatic notification regarding your Bug report
> which was filed against the dtrx package:
> 
> #930007: dtrx does not support password encrypted zip files
> 
> It has been closed by Debian FTP Masters  
> (reply to Andres Salomon ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Andres Salomon 
> ) by
> replying to this email.
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Fri, 01 Jan 2021 21:49:08 +
> From: Debian FTP Masters 
> To: 930007-cl...@bugs.debian.org
> Reply-To: Andres Salomon 
> Subject: Bug#930007: fixed in dtrx 8.0.1+git20200717-2
> Message-Id: 
> 
> Source: dtrx
> Source-Version: 8.0.1+git20200717-2
> Done: Andres Salomon 
> 
> We believe that the bug you reported is fixed in the latest version of
> dtrx, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 930...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Andres Salomon  (supplier of updated dtrx package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Fri, 01 Jan 2021 21:01:31 +
> Source: dtrx
> Architecture: source
> Version: 8.0.1+git20200717-2
> Distribution: unstable
> Urgency: low
> Maintainer: Andres Salomon 
> Changed-By: Andres Salomon 
> Closes: 930007
> Changes:
>  dtrx (8.0.1+git20200717-2) unstable; urgency=low
>  .
>* Add my own patches to support password-protected zip, rar, and 7z
>  archives. Please report any bugs you find! Upstream pull request is
>  https://github.com/dtrx-py/dtrx/pull/6 (closes: #930007).
>* Fix lintian warning in debian/copyright.
> Checksums-Sha1:
>  e91dff104aef249a1ca4927ca4f3daf7e9c33d1d 2086 dtrx_8.0.1+git20200717-2.dsc
>  1d1638a2811997b725b51c94a0f367c8bc5bc1b8 9268 
> dtrx_8.0.1+git20200717-2.debian.tar.xz
>  00458feb0573fd2bd167156e303948e56a748730 6135 
> dtrx_8.0.1+git20200717-2_source.buildinfo
> Checksums-Sha256:
>  2becdce583dfd9b6d7bbff097af1e3d89e8a5682757de02c772aff095f4ed59c 2086 
> dtrx_8.0.1+git20200717-2.dsc
>  5eef494d73541f1b77740a775562fb60a2823617f6fbcfebf539a7d1ae863361 9268 
> dtrx_8.0.1+git20200717-2.debian.tar.xz
>  fee19291fdd0d194e911cfd5b83c0ad8222e4d8e938b3c94017bbd564de99fb5 6135 
> dtrx_8.0.1+git20200717-2_source.buildinfo
> Files:
>  2821dc792b1f520cd5a90219934dc312 2086 utils optional 
> dtrx_8.0.1+git20200717-2.dsc
>  93516be6709b4e9f1a51f4f2da3daf89 9268 utils optional 
> dtrx_8.0.1+git20200717-2.debian.tar.xz
>  fbf64714f9698ed669c8dd88bf20f60a 6135 utils optional 
> dtrx_8.0.1+git20200717-2_source.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJIBAEBCAAyFiEEUAUk+X1YiTIjs19qZF0CR8NudjcFAl/vlmcUHGRpbGluZ2Vy
> QGRlYmlhbi5vcmcACgkQZF0CR8NudjcuNQ//cXc0Mw1Ko0uNUI6ZaLlmWjjIi8sA
> 7As6RFKKlLyOprtV+g0WMcX0r8D/zv1ECijIRuiF5Js10CcaVygx6DrOYJUnXncR
> uOm4YNkWXiepthYwIyitpCQGlQG21vnBUHamyxA2f1wusn1z/ZA6gqA9D3VDqtYO
> /IiBKjx6GkzySo83UjZa8c1U0d1Jl0bMwydTJV+Sck+M20ATTXB/WU3jVzXM4d3+
> DmvbfCY8hSrZTwWFCG5s9ZGeLxkflxmil1gFwHJr19RQSI/icX0d4e5EehbofpTS
> xUMLs3vl+Z7DznJhUPCN0803b1AjzNSSPh/FwWTpS9ukBIxsd50Vq7Vk1Q/74Pyl
> GY7p9ZAeTOB2+t9W1QgC0NEHPgOLKn/0zNZLy62Z6yWh+kkYwJBEb7IkxnO4H+7Z
> SogCuP2xOpNFh5GLp3x0ajMzJxWBTxvD5ZF4NdlniH/RfFy5DGqudXdH0Lj+hRwf
> ADc/iK/25IcFE1jmpL4WS8iPi5ERpjkQ1AGeQHE9yQMyqxzNEJNr8LSAhZTIuqcV
> wTezEJhmBxTgtSoTM8uH6z0z+ivmVxZkFde/8JVbWPLTt0aaY/fpRd7u8ODX4bzH
> KUMqXydSab6AbvoIWWjcpu27CKiJkKLZaGkdZiemwYx/drHZ1NkktE9p+GN99vRD
> e23IVQtcDNTRiiI=
> =lBiS
> -END PGP SIGNATURE-

> Date: Tue, 04 Jun 2019 19:36:03 -0700
> From: Benjamin Mako Hill 
> To: Debian Bug Tracking System 
> Subject: dtrx does not support password encrypted zip files
> Message-ID: 
> <155970216336.513.15905693693042535931.report...@spes.spes.yukidoke.org>
> 
> Package: dtrx
> Version: 7.1-2
> Severity: wishlist
> 
> Since this package is currently orphaned... Thank you for to whoever takes on
> the maintainership of dtrx.
> 
> This is a very simple feature request. There is currently no way to extract
> password protected zip files with dtrx. I'd love it it there was. A more
> general solution might simply be a way to pass options onto the programs
> (unzip, tar, etc) that are doing the extraction.
> 
> That's it! I'm happy to provide a broken password protected zip file if that's
> helpful. :)
> 
> 

Bug#888663: libtemplate-perl: FTBFS with debhelper/11.1

[Benj. Mako Hill]

> Is there something where the Debian Perl Group can help?

Apologies for the slow response. The package needed a major
overhaul. I've done that now and fixed this issue and quite a few
others.

In general, I'm very happy with NMUs of my package if I'm not able to
get to it or unresponsive for any reason. Thanks so much for offering
to help!

Later,
Mako




-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#888663: libtemplate-perl: FTBFS with debhelper/11.1

[Benj. Mako Hill]

> In the concrete case, it is appears to be relaitively simple to
> convert libtemplate-perl to use override targets rather than the
> deprecated manual sequence control parameters.  I have attached
> a patch for this.

Thanks for the patch! I'll test this and upload it if it looks
alright.

Later,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#876191: most: configure cannot be built from source

[Benj. Mako Hill]

severity 876191 minor
retitle 876191 most: configure file cannot be regenerated automatically
thanks

Greetings!

For the reasons discussed on this bug already, I'm retitling this bug
and reducing its severity. I know Helmut doesn't agree. If we want to
have a bigger conversation about policy on -legal or -policy or
something, please keep me in the loop!

Otherwise, we both agree that the first order of business should be
closing this bug! I hope to getto that Real Soon but patches (even
NMUs to fix the issue) are always, always, always welcome.

Later,
Mako



-- 
Benjamin Mako Hill
http://mako.cc/academic/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#876191: most: configure cannot be built from source

[Benj. Mako Hill]

> On Sat, Nov 25, 2017 at 12:36:33PM -0800, Benj. Mako Hill wrote:
> > I agree that a hand-modified binary a binary would not mean that you
> > don't need to provide source for that binary. I think there's likely
> > going to be consensus on that in Debian.
> 
> That put's you in a difficult spot as to where to draw the line.

Drawing lines on these sort of issues involves judgment calls—often
difficult ones. We're not going to avoid that.

> > To say that DFSG#3 is moot (i.e., that you /can not/ make
> > modifications or derived versions) seems to me to be an
> > exaggeration. It is more difficult than it might be if the software
> > and build scripts were created in a different way. But that's not
> > necessary a DFSG issue. Writing your software in a obscure programming
> > language makes it harder to modify as well and that is obviously
> > allowed.
> 
> DFSG #3 is about enabling users. It doesn't really matter if users
> refrain from modifying due to licensing or due to being
> impractical. The end result is, that the purported freedom hasn't
> transferred into reality.

We agree on this. It should also be clear that we allow some amount
of annoyance, difficulty, and practicality in modifying software in
that we allow software in allow advertising clauses, esoteric
programming languages, single character variable names, no comments,
etc.

We also, generally speaking, have allowed software that involves
hand-modified versions of auto-generated build scripts and other code.

> > Are you willing to say that source code can never contain code
> > that was partially generated by another program that is provided?
> > Even if it is generated by computers and then modified by hand?
> > That's a much stronger position than I think is supportable by any
> > reading of the DFSG than I've ever heard and it would eliminate
> > many hundreds or even thousands of packages from Debian.
> 
> That's a tough question indeed. Half a year ago, the strict answer
> would have eliminated nothing less than perl (#762638). Even though
> the Debian perl maintainers were heavily patching the generated
> file, they are now generating it at build time.

That's still just a bug about an autoconf-generated configure
script. I was asking a much bigger question. Much of what we would
both agree is the source code of many /programs/ (like the .c files or
whatever) is at least partially generated by programs. How often to
programmers create keyboard macros to autogenerate code? How often do
they include them?

> To evade answering it, I try to work from the impact. Whenever
> fixing a bug is impeded by the inability to regenerate build
> artifacts, I file a bug, because it clearly demonstrates that the
> freedom to modify is limited here.

I agree that this is the right approach. But that bug is still to have
one severity or another and I'm still not convinced that this is a
serious DFSG issue.

> > This is distinctly different. The source code in the JS example is
> > obviously not minified the Javascript if we use the GPL's "preferred
> > form for modification" heuristic regardless of the change in
> > question. If upstream wanted to make a change to the Javascript in
> > their program, they would almost never use the minified version. If
> > most's upstream wanted to make a change to their configure file, they
> > would likely modify the pre-built version. Or they would go through
> > rebuilding it again.
> 
> Most commonly, Javascript is not copy-left, but something like MIT.
> Downstream projects commonly embed minified, embedded copies and just
> update them whenever convenient. So yes, some upstreams (e.g. a past
> Doxygen) do prefer to deal with minified Javascript.

The GPL defines source as preferred form for modification. Upstreams
may prefer to just use/update their minified Javascript with a new one
but there is no way athat the minified version is the version nearly
anybody would turn to if they wanted to make a modification. It's
nearly impossible to do so!

Again, it's a judgment call. But if it came to a copyright case
someone would have to make the argument in front of a judge that the
minified version was the preferred form for modification. It would not
be hard to find expert witnesses to convince any reasonable judge
otherwise.

> > I agree! But I think that having packages removed from testing (as
> > has now happened to most) over this interpretation is an
> > overreaction to what I think constitutes an annoyance.
> 
> The removal happened due to not responding to the bug. You can defer
> automatic removals indefinitely by continuously mailing the bug.

I'm sure that neither one of us thinks that this is an actually
solution. Either there's a serious bug, and it should

Bug#876191: most: configure cannot be built from source

[Benj. Mako Hill]

Greetings Helmut!

Thanks for engaging productively on this!


> I deliberately avoided the FTBFS language, because it is not a FTBFS.
> It's different. It's like shipping a binary that cannot be regenerated
> and using that during build. The term FTBFS is well defined and does not
> cover this case.

Got it. We agree about that.

I'm don't think we agree on what constitutes the source for this
package. Until we do, I think a more descriptive title might be
better. Something like: "configure file cannot be regenerated
automatically."

> Would you say the same if you compile a binary, use a hex editor to fix
> the binary and then ship the binary in your source package? I mean you
> preferred to edit the binary with a hex editor, so wouldn't it be
> preferred form for modification?

I agree that a hand-modified binary a binary would not mean that you
don't need to provide source for that binary. I think there's likely
going to be consensus on that in Debian.

I also think this situation is different because I think that a
configure file is more like computer-generated, hand-modified,
/source/ than like a binary.

I think one could also argue that there is an difference between the
program binary and a build script which is used to build the package
in question.

> Also consider that autoconf projects tend to ship embedded copies of
> .m4 files. A bug in those .m4 files is often fixed upstream. Fixing
> it could be a simple matter of updating the embedded copy if one
> could regenerate configure.
> 
> In both of these examples, I very much do not prefer working with
> the generated configure as it feels very much like editing a binary
> with a hex editor. Thus I argue that configure is not the preferred
> form for modification. Shipping only configure makes DFGS #3
> practically moot.

To say that DFSG#3 is moot (i.e., that you /can not/ make
modifications or derived versions) seems to me to be an
exaggeration. It is more difficult than it might be if the software
and build scripts were created in a different way. But that's not
necessary a DFSG issue. Writing your software in a obscure programming
language makes it harder to modify as well and that is obviously
allowed.

Are you willing to say that source code can never contain code that
was partially generated by another program that is provided? Even if
it is generated by computers and then modified by hand? That's a much
stronger position than I think is supportable by any reading of the
DFSG than I've ever heard and it would eliminate many hundreds or even
thousands of packages from Debian.

> > If this has been discussed elsewhere or if there is Debian policy
> > on this I don't know about, I'd appreciate being pointed to this
> > and I'm happy to defer to this. In the meantime, I'd appreciate
> > help fixing this issue. I'm not likely to have bandwidth for a few
> > more weeks.
> 
> I guess we should document this issue class centrally. It is similar
> to the javascript bundling issue (where people suppose that minified
> or concatenated javascript files could be considered source).

This is distinctly different. The source code in the JS example is
obviously not minified the Javascript if we use the GPL's "preferred
form for modification" heuristic regardless of the change in
question. If upstream wanted to make a change to the Javascript in
their program, they would almost never use the minified version. If
most's upstream wanted to make a change to their configure file, they
would likely modify the pre-built version. Or they would go through
rebuilding it again.

> This issue comes about every time Debian is bootstrapped for a new
> architecture as configure tends to have bugs (e.g. ppc64el). I'm
> seeing it now as I bootstrap Debian for something like a new
> architecture (cross building). So this is the class of bugs to watch
> out.

I agree! But I think that having packages removed from testing (as has
now happened to most) over this interpretation is an overreaction to
what I think constitutes an annoyance.

I think that the main goal should be focusing on trying to fix these
bugs. I think a secondary goal should be discussing this in a
systematic way to get some sort of consensus.

Until then, my sense is to reduce the severity of this (likely to
normal) and to retitle the bug as described above. As I said, I think
this is a real bug. I just don't agree that it's a showstopper or a
DFSG issue.

Regards,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#876191: most: configure cannot be built from source

[Benj. Mako Hill]

Greetings Helmut!


> I was trying to fix a bug in most that requires modifying configure.
> Thus I tried to regenerate it and ... failed.

I'll start by saying that this is a real bug and that I agree that it
should be fixed. And thanks so much for notice and submitting it! And
for trying to fix the other issue!

I'll also say that I'm skeptical about both the severity you've chosen
here (serious), about describing this as a FTBFS issue, and about your
suggestion that this is a DFSG issue.

After all, the package still builds from its source and I think we
have everything that upstream has.

If there is a serious DFSG issue here, it's not a FTBFS issue but
rather a question of whether or not the source package contains the
full source in the first place. I'm open to being convinced otherwise
but I think it does.

If I generate a configure file with autoconf and then modify it by
hand in order to create a working build script, I don't I've somehow
made it impossible to provide source for that package. I think I'm
still providing the preferred form of modification (as the GPL defines
source). I agree that that situation is brittle and bad and should be
avoided.  But I don't think it's a DFSG issue.

If this has been discussed elsewhere or if there is Debian policy on
this I don't know about, I'd appreciate being pointed to this and I'm
happy to defer to this. In the meantime, I'd appreciate help fixing
this issue. I'm not likely to have bandwidth for a few more weeks.

Regards,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#848942: Acknowledgement (jessie-pu: package most/5.0.0a-2.3)

[Benj. Mako Hill]

Greetings!

I forgot to mention that I've discussed this with the security team
and uploading to stable-proposed-updates was their suggestion and
recommendation.

Regards,
Mako

-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#846465: most: Add support for XZ-compressed files

[Benj. Mako Hill]

> > Fortunately it seems very easy to do, so I'm attaching the patch.
> 
> I pressed the 'send' button too fast. The previous patch was wrong,
> here's the correct one.

Thanks for this! I really appreciate the help.

I've applied this patch to a version I've just uploaded to Debian
unstable. It also fixes the other security you've mentioned and I've
emailed the security team so we can begin fixing that issue in
distributions other than testing/unstable.

Thanks for your work on this!

Later,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#848132: most is vulnerable to a shell injection attack using LZMA-compressed files

[Benj. Mako Hill]

Thanks for this. I'll upload a patch for the version in unstable right
away.

Later,
Mako



> Package: most
> Version: 5.0.0a-1
> Severity: grave
> Tags: security patch
> Justification: user security hole
> 
> Hello,
> 
> the most pager can automatically open files compressed with gzip,
> bzip2 and (in Debian) LZMA.
> 
> This is done using popen() and, in earlier releases of most, it was
> vulnerable to a shell injection attack.
> 
> most fixed this in v5.0.0 (released in 2007), but the Debian patch
> that added LZMA support (bug #466574) remains vulnerable.
> 
> It is trivial to generate a file with a certain name and content that,
> when opened with most, runs arbitrary commands in the user's computer.
> 
> most is also launched by other programs as a pager for text files
> (example: an e-mail client that needs to open an attachment). If any
> of those programs generates a temporary file name that can be set by
> an attacker, then that can be used to break into the user's machine.
> I don't have any example of such program, however.
> 
> All versions of most >= 5.0.0a-1 including 5.0.0a-2.5 in Debian
> (and derivatives that include the LZMA patch) are vulnerable (older
> versions are vulnerable in all distros as I explained earlier).
> 
>https://security-tracker.debian.org/tracker/CVE-2016-1253
> 
> I'm attaching the debdiff with the patch. It simply replaces single
> quotes with double quotes in the command passed to popen(). Double
> quotes in the filename are escaped by most in order to prevent this
> kind of attacks, but this offers no protection if the file name is
> enclosed in single quotes.
> 
> Regards,
> 
> Berto
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages most depends on:
> ii  libc6  2.24-7
> ii  libslang2  2.3.1-5
> 
> most recommends no packages.
> 
> most suggests no packages.
> 
> -- no debconf information

> diff -Nru most-5.0.0a/debian/changelog most-5.0.0a/debian/changelog
> --- most-5.0.0a/debian/changelog  2016-08-05 02:55:52.0 +0300
> +++ most-5.0.0a/debian/changelog  2016-12-14 14:31:29.0 +0200
> @@ -1,3 +1,12 @@
> +most (5.0.0a-2.6) unstable; urgency=high
> +
> +  * Non-maintainer upload.
> +  * lzma-support.patch:
> +- Fix CVE-2016-1253 (shell injection attack when opening
> +  lzma-compressed files).
> +
> + -- Alberto Garcia   Wed, 14 Dec 2016 14:31:29 +0200
> +
>  most (5.0.0a-2.5) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -Nru most-5.0.0a/debian/patches/lzma-support.patch 
> most-5.0.0a/debian/patches/lzma-support.patch
> --- most-5.0.0a/debian/patches/lzma-support.patch 2016-07-22 
> 01:50:23.0 +0300
> +++ most-5.0.0a/debian/patches/lzma-support.patch 2016-12-14 
> 14:25:03.0 +0200
> @@ -1,3 +1,5 @@
> +Index: most-5.0.0a/src/file.c
> +===
>  --- most-5.0.0a.orig/src/file.c
>  +++ most-5.0.0a/src/file.c
>  @@ -77,7 +77,7 @@ static int create_gunzip_cmd (char *cmd,
> @@ -32,13 +34,15 @@
>   
>   if (cmd != NULL)
> {
> +Index: most-5.0.0a/src/file.h
> +===
>  --- most-5.0.0a.orig/src/file.h
>  +++ most-5.0.0a/src/file.h
>  @@ -22,6 +22,7 @@
>   #define MOST_MAX_FILES 4096
>   #define MOST_GUNZIP_POPEN_FORMAT "gzip -dc \"%s\""
>   #define MOST_BZIP2_POPEN_FORMAT "bzip2 -dc \"%s\""
> -+#define MOST_LZMA_POPEN_FORMAT "lzma -dc '%s'"
> ++#define MOST_LZMA_POPEN_FORMAT "lzma -dc \"%s\""
>   
>   extern void most_reread_file (void);
>   extern void most_read_to_line (int);


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#817586: most package failed to build on arm64 + ppc64el

[Benj. Mako Hill]

> Here's the patch against the -2.4 NMU

Looks good to me.

Later,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#817586: Info received (most: diff for NMU version 5.0.0a-2.4)

[Benj. Mako Hill]

> Hopefully everyone is fine with this and no harm done. If the
> maintainer wants any changes I'm happy to re-upload.

I can take a look and make any changes in my own upload.

Later,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#817195: Same observation

[Benj. Mako Hill]

I am suffering from the same bug.


> Your best bet is probably to actually check if reverting to an older
> version of the intel driver fixes the issue, and if it does, to file
> this upstream per
> https://01.org/linuxgraphics/documentation/development/how-report-bugs

Switching back to earlier versions of the kernel did not fix this
bug. I tried this kernel packages linux-image-4.2.0-1-amd64 (4.2.6-3),
linux-image-4.3.0-1-amd64 (4.3.5-1) and linux-image-4.4.0-1-amd64
(4.4.6-1) and the bug was present in all three cases.

I switched back to the version of xserver-xorg-video-intel (plus
dependencies) in jessie and the bug went away.

The bug is present in 2:2.99.917+git20160218-1 and
2:2.99.917+git20160307-2 but switching back to an earlier version of
xserver-xorg-video-intel (I just moved all the way back to
2:2.21.15-2+b2, the version in Jessie) eliminates the bug.

This bug is a little outside of my wheelhouse but I can reliably
reproduce this and I'm happy to help debug and fix this.

Regards,
Mako


PS: I agree with the assessment that #818384 is a dupe of this bug.

-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: PGP signature

Bug#795937: NMU uploaded to DELAYED/5

[Benj. Mako Hill]

> I've sponsored Bradley's NMU to DELAYED/5 -- feel free to dcut cancel
> the upload or beat it to sid.

Sounds good! Thanks for the heads up!

Later,
Mako



-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#738327: Python3 support for iso8601 and more

[Benj. Mako Hill]

quote who=Thomas Goirand date=Mon, Mar 17, 2014 at 07:42:44PM +0800
 You still didn't reply to this message. #740311 was submited on the 28
 Feb 2014 (18 days ago), and #738327 on the Sun, 09 Feb (37 days ago),
 and you replied to none of them.

I'm sorry for the slow response Thomas. Thank you for patience and for
your help and interest in the package. 

I've looked at both the open bugs.

#740311 is bug. I haven't looked at the patch (I am catching up on my
volunteer software work now while offline) but I assume if it is a
minimal change and it fixes an important issue with the package, go
ahead and prepare an NMU fixing it.

Of course, I'd like make sure that upstream has the patch but if it's
been forwarded on (or applied), I don't object to applying the patch
here at all.

In terms of #738327, I'm not wild about gutting CDBS and essentially
redoing the package because you're not familiar with how to handle
Python3 support. I don't love the idea of NMUs that redo the entire
package because the person doing the NMU is not familiar with the
packaging software used. It seems like to a lot to change to a
relatively simple and stable package for something that is likely
unnecessary.

I should be able to get around preparing a package this week. If you
want to prepare a minimal fix for the Python 3 issue, I've got no
problems with that either.

 If you don't have time for this package, would you agree that I NMU it,
 and set the Python module team as Maintainer: ? Or maybe just add me as
 Uploaders: for the package?

I'm happy for to add you as uploader for the package.

Later,
Mako

-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#738327: Bug#740311: Bug#738327: Python3 support for iso8601 and more

[Benj. Mako Hill]

quote who=Thomas Goirand date=Tue, Mar 18, 2014 at 08:16:13AM +0800
 Best is simply to upgrade to the latest upstream release: it fixes
 it.

OK. Sounds fine.

  In terms of #738327, I'm not wild about gutting CDBS and essentially
  redoing the package because you're not familiar with how to handle
  Python3 support. I don't love the idea of NMUs that redo the entire
  package because the person doing the NMU is not familiar with the
  packaging software used. It seems like to a lot to change to a
  relatively simple and stable package for something that is likely
  unnecessary.
 
 Sure, I understand, and agree. I was merely proposing a way to do
 things. But also, please keep in mind that python-support is deprecated,
 and one way or another, you must change the package to get away from it.
 Switching to dh_python2 is what everyone recommends these days. Does
 CDBS support python3, and is there ways to do CDBS *without* using
 python-support?

I'll take a look. I'm not /opposed/ to switching to dh_python2 in
general, I just think it's overkill to fix that one bug. I'm not so
attached to CDBS that I will refuse to switch away. :)

Later,
Mako



-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#732284: Uploading fixes for OpenStack means updating python-iso8601

[Benj. Mako Hill]

quote who=Thomas Goirand date=Wed, Dec 18, 2013 at 12:06:17AM +0800
 Here's the full debdiff.

Thanks for helping me out with this. I'll look this over and upload it
this afternoon. The package is simple so I don't forsee problems.

Regards,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#732284: Uploading fixes for OpenStack means updating python-iso8601

[Benj. Mako Hill]

quote who=Benj. Mako Hill date=Tue, Dec 17, 2013 at 12:47:01PM -0800
 quote who=Thomas Goirand date=Wed, Dec 18, 2013 at 12:06:17AM +0800
  Here's the full debdiff.
 
 Thanks for helping me out with this. I'll look this over and upload it
 this afternoon. The package is simple so I don't forsee problems.

I've just uploaded a new version of the package. This bug should be
closed as soon as its processed.

Regards,
Mako


-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#710629: Bug#726164: NMU broke previously existing patches

[Benj. Mako Hill]

quote who=David Prévot date=Mon, Oct 14, 2013 at 10:31:27AM -0400
 Ping?
 
 http://patch-tracker.debian.org/patch/nondebian/view/most/5.0.0a-2.1

I can get to it in Hideki doesn't.

 The previously existing patches are big, can you please restore them
 ASAP (not changing the format to 3.0 in an NMU would be appreciated).

I agree.

I generally welcome NMUs but I do think that NMUs should fix bugs, not
overhaul packages.

Thanks to everybody who is helping with most!

Later,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#710629: Bug#726164: NMU broke previously existing patches

[Benj. Mako Hill]

quote who=David Prévot date=Mon, Oct 14, 2013 at 02:18:09PM -0400
 Thanks Mako. If you’re short on time, I’m willing to try and fix that
 tomorrow or the day after (I’d hate to see the broken version end up in
 Jessie, even shortly), just say the word (since you’re more aware of the
 most packaging, I’d prefer if you do, of course).

I'm not sure I'm going to be able to get to this in the next day. If
you take a stab at it -- even a rough one -- I am happy to take a look
at it, tweak it, and upload it. Just send an message with a link to
things if you do anything. I'll do the same.

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#725763: libwww-mediawiki-client-perl: some mediawiki servers don't support minor edit flag

[Benj. Mako Hill]

quote who=Brett Wuth date=Mon, Oct 07, 2013 at 10:40:07PM -0600
 The attached patch fixes the problem, allowing minor mode to be used
 when permitted, and to be ignored (off) when not permitted.

Great! Thanks for submittin this Brett. I'll prepare a new version and
upload it with this fixed.

Regards,
Mako



-- 
Benjamin Mako Hill
makoh...@uw.edu
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#708025: libtemplate-perl: FTBFS with perl 5.18: text.split.join d did not match expected

[Benj. Mako Hill]

quote who=Damyan Ivanov date=Wed, Jul 24, 2013 at 05:44:12PM +0300
 Control: -1 tags fixed-upstream
 
  This package FTBFS with perl 5.18 from experimental (in a clean
  sbuild session):
  
  FAILED 35:  - text.split.join d did not match expected
  t/vmethods/text.t .
  Failed 1/107 subtests
  
  There is a possible patch on the upstream bug report.
 
 Upstream has released a fixed version that is supposed work well with 
 pre- and post-5.18 perls.

Wonderful. Thanks for following up on this Dominic.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#504058: Zotero Update

[Benj. Mako Hill]

quote who=Luca Capello date=Mon, Apr 22, 2013 at 08:54:39PM +0200
 While I agree that both packages should come from the same source, after
 having heavily discussed with Michele Cane (who actually offered help in
 this same ITP [1]) we went ahead and both packages (zotero-standalone
 and the LO integration) are on their way to be uploaded [2].  The merge
 can be done later on, also considering that the last uploaded version
 for xul-ext-zotero is 10-month-old.

Wonderful. Thanks for doing this! I look forward to seeing this bug
closed!

Regards,
Mako



-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#504058: Zotero Update

[Benj. Mako Hill]

retitle 504058 RFP: zotero -- program to collect, manage and cite bibliographic 
information
thanks

Thanks Andreas for kicking me. :)

I'm not likely to get around to packaging soon this so I hope somebody
else can take this over. The package is not trivial and I have no done
a xulrunner package before. I thought this going to be trivial and
haven't found the time to address it. It may in fact be trivial for
someone familiar with packaging xulrunner applications.

And just to be clear: xul-ext-zotero is already in Debian but this is
a different package. The
suggestion here is for the standalone version of Debian (i.e., Zotero
Standalone).

Since they are built from what is essentially the same source and have
most of the same dependencies, I think we should probably build both
pieces of software from the same source package. In that sense, I
think my first preference would be for Theodore Lytras (who already
maintains xul-ext-zotero) to take this on.

At the very least, whoever *does* take this on should coordinate with
Theodore.

Thanks to everyone for your patience! I hope that stepping aside means
we see a Zotero standalone client in Debian quickly! 

Later,
Mako


-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#590180: Getting Sigil into Debian

[Benj. Mako Hill]

noowner 590180
retitle 590180 RFP: sigil -- A WYSIWYG ebook editor
thanks

This ITP is now more than two years old and we haven't heard from the
owner in more than year despite a few pings. And I (and other people
as well, I'm sure!) still really want Sigil in Debian. :)

Both Don Armstrong and the Kan-Ru (the owner) have suggested setting
up a shared repository. But really, *somebody* should make a stab at a
package. Since a few people have expressed interest in helping, this
seems like a great candidate for collaborative maintaince so that
anybody that wants to or can join to help. I'd encourage whoever runs
with this to create an Alioth project or something and run with it.

I'm tried to mark this bug accordingly because I think the ITP/owner
is scaring interested folks away from trying.

Thanks to Kan-Ru, Don, Mathieu, and everyone else who has spent time
on this already. I'm really looking forward to having Sigil in Debian!

Regards,
Mako

-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#590180: Status of sigil ITP

[Benj. Mako Hill]

quote who=Don Armstrong date=Wed, Nov 28, 2012 at 04:09:10PM -0800
 I found myself looking for sigil once again; what's the current status
 of this ITP? It would be ideal to at least get a preliminary git
 repository going, which can be sanitized of non-free code (if
 necessary) before putting it into the collab-maint repository.

It has been almost a year with no visible movement toward packaging
(at least on this bug). This is genuinely useful free software. We try
so hard to not step on each others toes that I think we sometimes
really hurt our users. And I think this is one of those cases.

Don: It may not be worth very much but you have my permission and
encouragement to go forward with whatever you you can do to help get
Sigil into Debian.

 If you don't have time to maintain sigil, I'm ok with starting a
 collaborative maintenance group for it.

And I'm still willing to put some time and effort into seeing this
happen. Keep me in the loop!

Later,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#682892: Patch

[Benj. Mako Hill]

quote who=Hilmar Preusse date=Fri, Aug 10, 2012 at 09:50:41AM +0200
   Yes, there could be, like dvipdfm.py, dvips.py, vtex.py,
   mpost.py.  But there shouldn't be many.  I'd wait for the next
   FTBFS bugs rolling in and then fix it.
  
  Please upload now to fix these two bugs. rubber will currently not
  work at all, in a very difficult to diagnose way, for any document
  with a bibtext bibliography or an index.
  
 Sorry, the sentence above was misunderstandable. I *will* upload
 rubber with these two patches, as they cause FTBFS on other packages,
 but I won't investigate myself if there are other possible problems.

Great! :) Sorry for the misunderstanding.

And thanks for maintaining rubber. As you can tell, I use it a lot and
love it. :)

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#682892: Patch

[Benj. Mako Hill]

quote who=Hilmar Preusse date=Thu, Aug 09, 2012 at 06:14:26PM +0200
 Yes, there could be, like dvipdfm.py, dvips.py, vtex.py, mpost.py.
 But there shouldn't be many.  I'd wait for the next FTBFS bugs
 rolling in and then fix it.

Please upload now to fix these two bugs. rubber will currently not
work at all, in a very difficult to diagnose way, for any document
with a bibtext bibliography or an index. Since you have patches, you
should fix that issue now rather than to wait to see if it's also
broken in other situations.

Regards,
Mako



-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#682892: Bug#684228: rubber is broken with bibtex in texlive 2012.20120628-2

[Benj. Mako Hill]

quote who=Hilmar Preusse date=Wed, Aug 08, 2012 at 09:41:24AM +0200
 Seem to be something like a duplicate. I'll have a look at both bugs
 ASAP, may I can write a patch for #682892 myself, but I'm not sure.

The problem looks similar, but I don't think this is the same bug. The
bug I reported (#684228) is in the latex module. Bug #682892 is
clearly not.

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#682892: Adjust Severity

[Benj. Mako Hill]

Control: severity 682892 important

This bus is clearly important not serious. Rubber works fine for
many, even most documents. The current bug only breaks for documents
which contains an index. It's a pretty bad bug, and it should be easy
to fix, but it's not serious.

In any case, I will try to fix this bug.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#682892: Patch

[Benj. Mako Hill]

Control: tags 682892 + patch

So, the problem with this bug does have to do with the same issue in
#684228 (namely, the move to paranoid mode through the openout_any =
p configuration).

As I said in #684228, I'm not an expert with this. But the attached
patch seems to fix the issue on my systems to the extent that I could
reproduce it.

I will also point that I'm still getting a FTBFS bug on
derivations. But it seems to be a different issue not caused by
rubber. The tex directory seems to build just fine with this patch.

There may be other places in the rubbery source code affected by this
bug. It's not clear to me how I would search for these
systematically. :-/

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto
--- rubber-1.1+20100306/src/latex_modules/index.py	2010-08-12 09:46:10.0 -0400
+++ /usr/share/pyshared/rubber/latex_modules/index.py	2012-08-08 11:38:57.0 -0400
@@ -54,9 +54,9 @@
 		(e.g. .ilg) file.  Transcript is used by glosstex.py.
 		
 		self.doc = doc
-		self.source = doc.target + . + source
-		self.target = doc.target + . + target
-		self.transcript = doc.target + . + transcript
+		self.source = os.path.basename(doc.target) + . + source
+		self.target = os.path.basename(doc.target) + . + target
+		self.transcript = os.path.basename(doc.target) + . + transcript
 		if os.path.exists(self.source):
 			self.md5 = md5_file(self.source)
 		else:


signature.asc
Description: Digital signature

Bug#617296: Any Progress with RStudio?

[Benj. Mako Hill]

Any progress to report on getting RStudio in Debian? The software has
a full debian/ directory and well functioning debs available on the
website so I wonder what the hold up is. If we think its unlikely that
others will get to it, mayb ewe can switch it back to an RFP or I can
help look into doing the upload.

In any case, the software is great and some people I'm working with
are using it extensively. I'd love to know if I could help!

Regards,
Mako

-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#664561: libtemplate-perl: New upstream release 2.24 please?

[Benj. Mako Hill]

quote who=Dominic Hargreaves date=Mon, May 28, 2012 at 09:24:42PM +0100
 On Sun, Apr 08, 2012 at 07:37:21PM -0400, Benj. Mako Hill wrote:
  Hi Dominic!
  
  Thanks for keeping an eye out for new versions of TT2!
  
  quote who=Dominic Hargreaves date=Sun, Mar 18, 2012 at 10:19:19PM 
  +
   A new upstream release, 2.24, is out. Please could this be packaged?
  
  I have prepared a new version of this package but the external HTML
  documentation tarball seems to be missing. I have emailed upstream and
  asked them to produce it. Once they do, I will include it in a new upload.
 
 The docs now appear to be available as
 
 http://template-toolkit.org/download/TT_v224_html_docs.tar.gz

Yes. Andy finally got back to me to tell me that he uploaded them a
couple days ago. I'll upload them in the next day or so.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#645164: not fixed

[Benj. Mako Hill]

quote who=Julian Taylor date=Sat, Apr 14, 2012 at 07:10:48PM +0200
 - using a temporary preinst like foolscap (definitely works)

This seems like the best approach to me and it's what I'm planning on
doing.

Regards,
Mako



-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#664561: libtemplate-perl: New upstream release 2.24 please?

[Benj. Mako Hill]

Hi Dominic!

Thanks for keeping an eye out for new versions of TT2!

quote who=Dominic Hargreaves date=Sun, Mar 18, 2012 at 10:19:19PM +
 A new upstream release, 2.24, is out. Please could this be packaged?

I have prepared a new version of this package but the external HTML
documentation tarball seems to be missing. I have emailed upstream and
asked them to produce it. Once they do, I will include it in a new upload.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#664561: TT 2.24 Documentation

[Benj. Mako Hill]

Greetings Andy!

I'm working on getting TT 2.24 packaged for Debian. In the process, I
realized that the the HTML documentation for the newest version of TT2
doesn't to be posted.

This page:

  http://template-toolkit.org/download/index.html

...has link text saying HTML Documentation for version 2.24 that
points here:

  http://template-toolkit.org/download/TT_v224_html_docs.tar.gz

But there doesn't seem to be anything there. :-/

Thanks in advance for all your help and for all your work over the
years maintaining Template Toolkit!

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#471927: [Scratch] Scratch 1.4 source code released under GPL v2

[Benj. Mako Hill]

quote who=Michael Hanke date=Wed, Apr 04, 2012 at 02:08:14PM +0200
 A more fundamental issue could be a potential show stopper. Take a look
 at the etoys package -- technically similar, FOSS license, but still in
 non-free.

This sounds like confusion. In any case, the FTP masters are a
different group now and I think this is tractable.

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#471927: [Scratch] Scratch 1.4 source code released under GPL v2

[Benj. Mako Hill]

quote who=Amos Blanton date=Fri, Mar 30, 2012 at 04:42:22PM -0400
 We've made some changes to page that describes the source code on our site,
 and also made a minor update to a license file in the source package, all
 based on suggestions from Mako Hill and friends from the free software
 community.
 
 http://info.scratch.mit.edu/Source_Code
 
 I hope we can alleviate any concerns folks at Debian might have about
 making Scratch available in the Debian repositories. Don't hesitate to
 contact me if you have questions or concerns.

I'm pretty sure that the changes to the website make it clear that the
website terms of use and the trademark license are not additional
copyright terms.

I also think that the current text describing the trademark license
make it clear that re-packaging is fine while using the marks (it
says as much) so I don't forsee that this will be a problem getting
things into Debian.

Of course, folks should know that changes to the license were done in
order to help Scratch into Debian, Ubuntu, Fedora, etc. If there
happen to be any lingering concerns, we can probably work with the
Scratch team to get them address.

Thanks to Miry and everyone else whose working on this! I'm really
looking forward to finally getting Scratch in Debian!

Later,
Mako


-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#661534: python-iso8601: Please convert to dh_python2

[Benj. Mako Hill]

The patch looks very reasonable to me. I'll apply the patch and upload
this to Debian in the next couple days. Thanks for making this so
easy!

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#647272: mailcap

[Benj. Mako Hill]

severity 647272 normal
thanks

I have also just bitten by this bug (also from Mutt).

Antoine Beaupré is correct in his last message. This seems to be at
least ignoring policy. Even if one wants to argue that this is not a
violation, this is much more than a wishlist bug:

  http://www.debian.org/doc/debian-policy/ch-opersys.html#s-mime
  http://www.debian.org/doc/packaging-manuals/mime-policy/

Josselin: If you don't *like* the mailcap or the current state of
Debian's MIME policy, you should work on changing the technology or
the policy. It's clear you don't want fix mailcap. Fine. But you can't
just ignore the policy.

Unilaterally changing your package so that it breaks the expected and
long-term behavior of a series of very widely used packages like mutt
and elinks assume that the policy as written is being followed is a
bug in *this* package. Until the policy changes, the .mime files
should be restored.

Later,
Mako

-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#625221: Gwibber still can't send messages

[Benj. Mako Hill]

retitle 625221 cannot send notices when using network manager
tags 625221 patch
thanks

Thanks for maintaining Gwibber!

This bug means that users of gwibber cannot send messages if they are
using Network Manager. This affects users of unstable and testing now.

There has been a patch for this bug since June (thanks Emilio!) and
I've just tested it on my system against the version of Gwibber in
Debian testing/sid. The patch applies cleanly and results in a fully
functioning Gwibber.

If this difficult, I'm happy to do an NMU to fix this bug.

Regards,
Mako


-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#590180: Sigile Debian package

[Benj. Mako Hill]

Hello Kanru (and others!)

Thanks everyone for your work so far to get Sigil into Debian.  I've
noticed that it's been a few months since this bug was updated.

I'm willing to put in an evening of work or two to help package
dependencies or do other work to get this package uploaded. Do you
have a repository where you are working? What, in particular, needs to
be changed?

Regards,
Mako



-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#441874: pwsafe: Defaults to clipboard, when $DISPLAY is not set

[Benj. Mako Hill]

Hi Kristof,

pwsafe has been removed from Debian. It has a number of problems (this
being one of the least, honestly) and nobody stepped up to take it on
when I couldn't do it. If you'd like to maintain it (or want to find
someone who can) I would be happy to help sponsor.

Later,
Mako


quote who=Kristof Provost date=Wed, May 11, 2011 at 08:22:09PM +0200
 The man page is incorrect: pwsafe simply doesn't implement this feature. 
 It never checks the $DISPAY variable until it tries to access the X clip
 board. If that fails it will return a failure instead of simply printing
 the password.
 
 I don't think it'd be a huge amount of work to make pwsafe behave as
 described in the man page, but I'm not sure if it's a good idea to.
 
 Assume the following scenario:
 The user has his laptop connected to a projector and is sharing his
 desktop. He wants to log in to a secure website. pwsafe can send the
 password to his clipboard, so that would be fine. However, for some
 reason $DISPLAY is not set. If the behavior implemented in the manual is
 implemented the password would just be printed and anyone could
 photograph, remember or film it.
 
 I admit this is a fairly unlikely scenario, so if I'm the only one with
 this concern I'd be willing to look into writing a patch to implement
 the feature as described in the manual page.
 
 Regards,
 Kristof
 
 

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618611: libwww-mediawiki-client-perl: can't get pages with ampersands

[Benj. Mako Hill]

Thanks Brett for the bug report.

Your patch looks simple enough. I wonder though if it's not better to
simply escape the whole line so that it is URL safe. I'll test that
patch and, if it seems to work and to solve the problem, I'll send
this upstream and patch it in Debian.

Regards,
Mako

quote who=Brett Wuth date=Wed, Mar 16, 2011 at 03:37:16PM -0600
 Package: libwww-mediawiki-client-perl
 Version: 0.31-1.1
 Severity: normal
 Tags: patch
 
 
 The program chokes when asked to get a wiki page that includes an
 ampersand () in its name.
 
 
 $  mvs update 'AW Restaurant.wiki'
 Doing update AW Restaurant.wiki with host: localhost and lang: en
 Can't call method isa without a package or object reference at /usr/bin/mvs 
 line 96.
 $ 
 
 with the attached patch to pagename_to_url, the operation succeeds.
 
 ---cut---
 --- Client.pm.orig  2006-07-01 09:55:08.0 -0600
 +++ Client.pm   2011-03-16 15:31:24.0 -0600
 @@ -1318,6 +1318,10 @@
  ) if $name =~ /.wiki$/;
  my $char = $self-space_substitute;
  $name =~ s/ /$char/;
 +
 +# ampersand is escaped in the URL
 +$name =~ s//%26/;
 +
  my $lang = $self-language_code;
  my $host = $self-host;
  $host =~ s/__LANG__/$lang/g;
 ---cut---
 
 -- System Information:
 Debian Release: 5.0.8
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core)
 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages libwww-mediawiki-client-perl depends on:
 ii  libexception-class-perl  1.24-1  a module that allows you to 
 declar
 ii  libvcs-lite-perl 0.08-2  Minimal version control system
 ii  libwww-perl  5.813-1+lenny2  WWW client/server library for 
 Perl
 ii  libxml-libxml-perl   1.66-1+b1   Perl module for using the GNOME 
 li
 ii  perl 5.10.0-19lenny3 Larry Wall's Practical 
 Extraction 
 
 libwww-mediawiki-client-perl recommends no packages.
 
 libwww-mediawiki-client-perl suggests no packages.
 
 -- no debconf information
 

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#504058: Packaging Zotero in Debian

[Benj. Mako Hill]

retitle 504058 ITP: zotero -- program to collect, manage and cite bibliographic 
information
thanks

The conversation on this bug seemed to end two years ago with no
consensus on what to do. Some people suggested that it would be useful
to have the Zotero extension packaged in Debian. Others disagreed
basically because they don't think FireFox/IceWeasel extensions should
be packaged in Debian at all.

In any case, recent upstream developments with Zotero change the
situation. The next version of Zotero is being developed as a
standalone application. As a result, this version of Zotero certainly
should be packaged in Debian. I am a maintainer and very heavy Zotero
user and I am happy to do it.

There is currently an alpha version as Zotero Standalone. I'm going
to create packages for Zotero standalone and I'll follow up with a
link to them here. Probably when upstream releases a beta, I will
upload those packages into Debian. I probably won't upload them
before.

Please contact me if you want to work on this or help, etc.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#542846: do we really want to distribute this?

[Benj. Mako Hill]

reassign 542846 ftp.debian.org
retitle 542846 RM: reseed -- ROM; potential security issues, depends on sketchy 
service which discourages its own use
thanks

For those just joining us:

There are no reverse dependencies.

reseed's removal has been proposed in the BTS for a year, it has a
series of other problems, and nobody can think of a compelling reason to
keep it. I maintained this once because I was once under the impression
that it was useful for the Hurd. There are better alternatives today and
may have been at the time I adopted (or packaged it -- I can't remember)
as well. :)

quote who=Christoph Anton Mitterer date=Wed, Aug 04, 2010 at 09:20:50AM 
+
 On Wed, 4 Aug 2010 08:05:59 +0200, martin f krafft madd...@debian.org
 wrote:
  No, but we can repurpose this bug against ftp.debian.org. I just
  wonder why Mako doesn't reply.

 I'd also prefer a removal by the maintainer himself...

I think the answer to the submitter's quesiton is No. It's been almost
a year since removal was suggested and nobody has objected. The package
is crufty, connects to insecure service, and raises non-free network
services issues. Let's rid ourselves of it. 

 If he's looking for a replacement package to maintain... he
 could/should take this:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591472

Thanks! But no thanks. :)

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#587339: Add -2 option to copy usernames and/or passwords to the clipboard twice.

[Benj. Mako Hill]

quote who=Daniel Burrows date=Sun, Jun 27, 2010 at 08:52:16AM -0700
 Package: pwsafe
 Version: 0.2.0-3.0~dburrows
 Severity: wishlist
 
   The Chrome browser appears to read the X clipboard twice when you
 paste a value, throwing away the first value it read.  This makes it
 difficult to use pwsafe with it.  Obviously a fix in the browser is
 ideal, but it would be nice in the meantime if pwsafe could get a -2
 option that would copy each value to the clipboard twice (and I suspect
 this patch is a lot easier to write and get applied than a patch for
 Chrome).
 
   I have a patch for this worked up, but I'll need to clear it with my
 employer before I can send it to you.

Wonderful! Thanks I'll hold off on forwarding this upstream until I hear back
about the patch.

Later,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so
far as society is free to use the results. --RMS



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578692: libmediawiki-perl: Security update of mediawiki will break login API

[Benj. Mako Hill]

quote who=Romain Beauxis date=Wed, Apr 21, 2010 at 03:31:14PM -0500
 We are planning to update the package in lenny with a backport of
 these changes. However, this change will break the
 libmediawiki-client-perl package so a coordinated upload should be
 necessary.

Thank so much for the patch! This is wonderful!

Sure. Do you want me to just go ahead and upload a patched version of
this software to sid?

Later,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#540564: On second thought..

[Benj. Mako Hill]

I'm not going to be able to give this package the attention it deserves,
especially with no upstream. I do really hope someone else takes this
over, though.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#545553: [libtemplate-perl] New version available

[Benj. Mako Hill]

quote who=Kartik Mistry date=Tue, Sep 08, 2009 at 09:45:10AM +0530
 New upstream version 2.22 is available at,
 http://cpan.org/modules/by-module/Template/Template-Toolkit-2.22.tar.gz
 
 Please consider packaging it.

Thanks for the hint Kartik! It's now on my list!

Later,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#544848: [ion3] license change, consider for main?

[Benj. Mako Hill]

quote who=Ben Hutchings date=Sat, Sep 05, 2009 at 09:30:01PM +0100
 No, the conditions on use of the name 'Ion' in derivatives are still too
 restrictive.  However, I will remove the obnoxious debconf warning.

Do you really think so? DFSG 4's The license may require derived works
to carry a different name or version number from the original software
seems to explicitly allow it!

Has this been discussed more widely and decided? While annoying, this
sure seems free to me.

Later,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#533845: New Upstream Version

[Benj. Mako Hill]

retitle 533845 new upstream version available
thanks

3.10-5 has now been replaced with yet another new version, 3.10-6. As
the original submitter has mentioned, these changes include important
changes for other packages. There doesn't seem to have been a new
upload of this Debian package for more than a year.

If you would like help with the package, let me know. Unless there is
something tricky, I should be able to help prepare a version.

Later,
Mako


-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#540564: Oh why not...

[Benj. Mako Hill]

I don't use this actively and I don't suppose anybody does either at
this point. That said, I've still got a bunch of slides in Docbook XML
that I have no interest of changing into any other format so I'd like to
at least ensure that Debian has a working copy of the software so I can
get at the data and put it in useful presentation formats.

Please speak up if actually use this regularly and the package is yours.
Otherwise, I'll be happy to take this on as it doesn't look like it's a
lot of work. There is a small handful of what look like ignored bugs and
nothing else.

Regards,
Mako


-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#527536: [rt.cpan.org #45835] Bug#527536: RFP: libmediawiki-api-perl -- replacement for libmediawiki-perl

[Benj. Mako Hill]

quote who=Romain Beauxis date=Thu, May 14, 2009 at 04:08:16PM +1100
 Unfortunately this work cannot be done by the mediawiki packaging team..
 
 The team is currently composed on a single active developper, me, and I feel 
 I 
 have enough work with the current packages.
 
 However, I would be very happy to add any interested contributor to the team.

I currently maintain another Mediawiki Perl and library and application
so I would probably be a good candidate. I could do it too in a couple
weeks. Of course, if there is a person who is actively using it already,
they would be a better candidate. Anyone?

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#508686: update after initramfs-tools upload

[Benj. Mako Hill]

severity 508686 important
thanks

This bug no longer needs to be marked critical because a fix to
initramfs-tools uploaded by Maximilian Attems works around address the
issue.  See #426465 and #505440 for more information on that fix.

That said, as far as I can tell, the issue still exists in this package
and the patch should be applied.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@debian.org
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#489501: [PATCH] Fixing #489501 (zekr depends on libxul0d)

[Benj. Mako Hill]

I tweaked your upload a little (there were a few nits in the changelog)
and uploaded it to Debian. It's been processed and ACCEPTED.

Later,
Mako


quote who=Asheesh Laroia date=Thu, Dec 11, 2008 at 07:16:56PM -0800
 On Thu, 11 Dec 2008, Mohammad wrote:

 Dear Asheesh,

 Thank you very much for your effort and working on zekr.
 I tested your source package. It woks fine for me on Ubuntu Intrepid.

 Unfortunately, our Debian sponsors were a little busy, so I couldn't resolve
 the problem myself.
 I really appreciate if you upload your package to Debian.

 P.S: The current version of zekr in Debian, 0.5.1, is very old. We have
 prepared a deb package for the latest release, 0.7.1, which is available
 here:
 https://launchpad.net/~zekr/+archivehttps://launchpad.net/%7Ezekr/+archive

 Dear Mako!

 Now that I have the maintainer's ACK, let's do this NMU!  Again, the .dsc 
 is at  
 http://mentors.debian.net/debian/pool/main/z/zekr/zekr_0.5.1.dfsg-1.1.dsc 
 .

 And dear Mohammad,

 Thanks for the prompt reply.  Let's talk in the future about getting zekr 
 in Debian back on track.  Maybe if one day I become a Debian Developer I  
 can see about sponsoring this for you. (-:

 (And dear Steffen: two of three Serious bugs fixed so far!)

 -- Asheesh.

 -- 
 Today is what happened to yesterday.

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#315043: Processed: Bug fixed upstream

[Benj. Mako Hill]

quote who=Debian Bug Tracking System date=Mon, Dec 01, 2008 at 02:21:18PM 
+
 Processing commands for [EMAIL PROTECTED]:
 
  tags 315043 + fixed-upstream
 Bug#315043: mairix fails with mmap: Invalid argument
 Tags were: upstream
 Tags added: fixed-upstream

Nice. Richard has not yet released a new version of Mairix though so
I'll wait for the new upstream version to roll a new package.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#504373: Template Toolkit, Template::DBI and Etch updates breakage

[Benj. Mako Hill]

quote who=Dominic Hargreaves date=Wed, Nov 05, 2008 at 12:07:32PM +
 On Wed, Nov 05, 2008 at 12:03:14PM +, Dominic Hargreaves wrote:
  ftpmaster, I've just uploaded libtemplate-plugin-dbi-perl to NEW in
  order to fix an RC bug in libtemplate-perl (this is a regression from
  the functionality in etch; the code is in the main libtemplate-perl
  package in etch).
  
  Please could you process this as a lenny-related priority?
 
 Further to this, attached is my proposed NMU diff once
 libtemplate-plugin-dbi-perl is available. Notice I've moved some other
 packages from Suggests to Recommend on the advice of 
 
 http://lists.debian.org/debian-release/2008/07/msg00828.html

Thanks for handling this Dominic.

Later,
Mako


-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#429031: Now please add Suggests: libtemplate-plugin-xml-perl

[Benj. Mako Hill]

quote who=Hideki Yamane date=Wed, Jul 30, 2008 at 02:28:24PM +0900
 On Thu, 24 Jul 2008 10:49:48 +0100
 Dominic Hargreaves [EMAIL PROTECTED] wrote:
  I will assume this is okay to NMU and will do so in the next day or two
  unless anyone says no.
 
  Go for it, now! :-)
 
  # then ask RM to unblock package.

Absolutely, if you have no already, please go ahead. I've been on
vacation a little slow to respond. Apologies.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#480649: typographic error in the man page

[Benj. Mako Hill]

quote who=Stéphane Blondon date=Sun, May 11, 2008 at 12:58:47PM +0200
 There is a mispell in most.1 (line 206):
 s/shoul/should
 
 An unified diff is provided to correct it.

thanks for late! I'll be sure to fix it in the next release and I'll
forward it to upstream!

Regards,
Mako



-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#453927: configuration file not saved automatically

[Benj. Mako Hill]

Thanks for submitting this bug Roberto!

This RC bug has been open for more than 100 days with a patch and
without a response from the maintainer or anyone else. The package is no
longer in testing as a result.  I'm going to NMU this pacakge unless
Ryan or someone else reacts, takes action on this bug in any way, or
objects.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#429031: Now please add Suggests: libtemplate-plugin-xml-perl

[Benj. Mako Hill]

quote who=Hideki Yamane date=Wed, Mar 05, 2008 at 12:39:04PM +0900
 On Wed, 17 Oct 2007 10:49:01 +0100
 Dominic Hargreaves [EMAIL PROTECTED] wrote:
  The package is now uploaded so the dependency can be added to
  libtemplate-perl.
 
  libtemplate-plugin-xml-perl package is in testing and unstable now.
  So time has come, Mako, please add Suggests: libtemplate-plugin-xml-perl
  to your libtemplate-perl package (and update to new policy 3.7.3).

Got it. Will get to it soon. It's on my list. :)

Later,
Mako


-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#453439: most: New upstream release 5.0.0

[Benj. Mako Hill]

quote who=Jari Aalto date=Thu, Nov 29, 2007 at 04:24:46PM +
 Please package new upstream release
 
   http://www.jedsoft.org/most/download.html

Awesome. Thanks for the pointer.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#452011: Advocate DM: Asheesh Laroia

[Benj. Mako Hill]

quote who=Anthony Towns date=Sat, Nov 24, 2007 at 11:18:29PM +1000
 On Fri, Nov 23, 2007 at 06:56:03PM +0100, Benj. Mako Hill wrote:
  I advocate Asheesh Laroia as a DM. I've been reviewing and uploading
  Asheesh's packages for sometime now and he already done a great job for
  Debian already and will continue to do so a sa DM.
 
 Could people advocating DMs (or potential DDs for that matter) go into
 a bit more detail in their advocacy? 

Sure. I modeled my message after the other advocacy messages sent to
this list.

Asheesh maintains a series of packages in Debian including Alpine which
is reasonably complex and increasingly important. He is quick and
responsive to issues with his packages and has been responsive and
respectful in his interactions with me and with users.

In the months I have been reviewing and uploading his packages, I've not
taken issue with any of his technical decisions or needed to suggest
changes. My role as sponsor is at this point one of rubber stamp and has
only served to increase the time his packages spending waiting to enter
the archive. I believe that this, combined with the fact that Asheesh
has fulfilled the requirements and agreed to our policies, qualifies him
as a DM.

I hope that helps.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#452011: Advocate DM: Asheesh Laroia

[Benj. Mako Hill]

I advocate Asheesh Laroia as a DM. I've been reviewing and uploading
Asheesh's packages for sometime now and he already done a great job for
Debian already and will continue to do so a sa DM.

Asheesh has acknowledged the Debian Social Contract, DFSG, DMUP and has
a GPG key 0x70096AD1 which is signed by quite a few Debian developers.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#429031: Whats happening?

[Benj. Mako Hill]

quote who=Dominic Hargreaves date=Sat, Oct 13, 2007 at 04:53:46PM +0100
 On Sat, Oct 13, 2007 at 11:40:50AM +0200, Jochen Topf wrote:
 
  I can´t find the libtemplate-plugin-xml-perl package in testing, so I
  can´t use TT any more. Whats the problem?
 
 My package was rejected by ftpmasters, it appears, so never made it into
 unstable never mind testing. I have now uploaded a fixed package.

Thanks for following up Dominic.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#445934: VRMS-Why is the Tango Icon theme listed as non-free

[Benj. Mako Hill]

quote who=[EMAIL PROTECTED] date=Tue, Oct 09, 2007 at 01:29:14AM -0700
 I was looking at the change log for vrms 1.13, and can't understand why
 this is listed as non-free. It is licensed under a Creative Commons
 Attribution-Share Alike 2.5 Generic license.  Which allows users to
 copy, distribute and transmit the work.  As well as to adapt the work.
 (http://creativecommons.org/licenses/by-sa/2.5/) 

For a while, ActualRMS did like not any Creative Commons license
because the brand also stood for licenses which he felt were
unacceptable. CC (the organization) has since retired those licenses
and Richard supports those licenses.

The BY and BY-SA licenses certainly seem free to me. They contain an
anti-DRM clause that some people on Debian-Legal have suggested might
be non-free but it is similar, and less extensive, than a similar
clause in the GFDL which the project voted on and decided met up the
requirements of the DFSG.

In any case, VRMS and ActualRMS are not the same. VRMS complains about
packages in the non-free repository. Questions about whether packages
belong in that package are important ones, but they are not ones to have
in bug reports for the VRMS package.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#429031: Please add Suggests: libtemplate-plugin-xml-perl

[Benj. Mako Hill]

quote who=Hideki Yamane date=Sun, Sep 02, 2007 at 09:53:07AM +0900
  Thanks for your ITP, Dominic. But this bug should be opened.
 
  I think this package should add suggests libtemplate-plugin-xml-perl, 
 because when stable users would upgrade their system from Etch to 
 Lenny, they will lost Template::XML modules and have to look for what 
 package would provide those modules.
 
  And libtemplate-plugin-xml-perl has not been in repository yet.
 
  So, 
  - libtemplate-plugin-xml-perl would be in repository,
  - libtemplate-perl package add Suggests: libtemplate-plugin-xml-perl,
  - then close this bug.

Having not pursued this issue in any depth, this sounds reasonable to
me.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#440111: Rockbox utility

[Benj. Mako Hill]

quote who=Jonas Häggqvist date=Fri, Aug 31, 2007 at 03:14:00PM +0200
 Benj. Mako Hill wrote:
  Actually, I mentioned a different RockBox installing utility which
  was one that I wrote.
 
 Nu-uh! http://mako.cc/copyrighteous/20070308-00.comment :-)
 
  That said, this one is much better. I'm happy to try it out and
  consider packing it though.
 
 I should probably note that there's an error in the instructions
 above. You need to svn co svn://svn.rockbox.org/rockbox/trunk/rbutil
 rockboxutility since some of the needed code lives a level below the
 Qt code. This is because of leftovers from the aforementioned
 abandoned wxwidgets version.  This should get cleared up soon though,
 and only the Qt version code should be in the rbutil directory. Build
 instructions are in the wikipage I linked, but amounts to basically
 (on Debian) qmake-qt4  make (no make install step yet).

You're right. :)

OK then. I'll look into it.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Bug#440111: Rockbox utility

[Benj. Mako Hill]

quote who=Jonas Häggqvist date=Wed, Aug 29, 2007 at 11:38:43PM +0200
 I saw you once mentioned on copyrighteous that you might help package
 Rockbox Utility for Debian and/or Ubuntu. I just filed an RFP in Debian for
 it if you're still interested (or know someone who might be):
 http://bugs.debian.org/440111
 
 http://www.rockbox.org/twiki/bin/view/Main/RockboxUtilityQt

Actually, I mentioned a different RockBox installing utility which was
one that I wrote. That said, this one is much better. I'm happy to try
it out and consider packing it though.

If someone else *really* wants it, I'm happy to defer or help and
sponsor.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/

Creativity can be a social contribution, but only in so
far as society is free to use the results. --RMS


signature.asc
Description: Digital signature

Bug#437714: Please don't make alpine-dbg depend on all packages

[Benj. Mako Hill]

quote who=Asheesh Laroia date=Mon, Aug 13, 2007 at 08:08:30PM -0700
 Right now the depends are generated automatically by debhelper.  As far 
 as I know, the official Debian Policy doesn't cover -dbg packages at all, 
 so I'm fine with alpine | pilot | alpine-pico.

There have been some debug related policy proposals but none that I
know were accepted and none that I think would impact this issue. Your
suggestion sounds find Asheesh.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#422527: must rename

[Benj. Mako Hill]

quote who=Ben Hutchings date=Tue, May 22, 2007 at 12:16:58AM +0100

 Finally, I don't think it would serve current and potential users of
 Ion on Debian to rename it.  We just about get away with Iceweasel as
 that controversy was widely publicised and the package is part of a
 standard desktop installation.  For any more obscure application I
 fear renaming means death for the package; users won't find it.

If Ion3 dies in Debian, it will Tuomo's fault, not yours. In fact, he's
said he wants exactly that to happen on several occasions.

 (On the other hand, you could argue this is true for non-free
 packages.  I don't really know how many users are aware of or have
 enabled use of the non-free section.)

Non-free has been disabled by default in an unasked Debconf questions
for several releases now. I don't know if we have numbers on the number
of people who use non-free but my gut feeling is that it's not large.

Users that use non-free are in the know -- enough so that I suspect
they'll be able to find an ion3 package under another name.

 That's been vetoed, as I expect would iron be.  I find the claim
 over anything referring to ion to be tenuous but I do not wish to
 antagonise the author.

The author is not making not antagonizing him very easy.

Regards,
Mako


-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#422527: must rename

[Benj. Mako Hill]

quote who=Don Armstrong date=Thu, May 17, 2007 at 05:30:57PM -0700
 On Thu, 17 May 2007, Ben Hutchings wrote:
  After discussing with upstream, I'm complying with the trademark licence
  conditions by prominent version qualifiers and notices of possible
  out-datedness rather than renaming.  Specifically, for a fresh
  installation, the postinst checks the upstream version (using uscan) and
  if the version being installed is out of date (or may be out of date,
  since the version check failed) it notes that it will not be supported
  upstream and requires acknowledgement of this.
 
 I suggest just getting around this issue by:
 
 1) renaming the actual package and command iron[1] or whatever you
 choose so that it can stay in main
 
 2) making a non-free transition package called ion3 which depends on
 the new package, has the symlink, and contains the annoying postinst.

Yes, please rename the package and include a non-free transition
package. I do not currently use any packages in non-free and really
don't want to turn it on for this since it can be so easily avoided.

FWIW, I like the name fission.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#422222: TT v2.19 is available

[Benj. Mako Hill]

quote who=Carl Johnstone date=Fri, May 04, 2007 at 12:13:05PM +0100
 New upstream - in fact I'm surprised that 2.14 is the latest available in 
 sarge!

I just saw it and had corresponded with Andy about this a bit. It fixes
a couple other bugs in the package as well.

Thanks for the poke!

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#422222: TT v2.19 is available

[Benj. Mako Hill]

quote who=Carl Johnstone date=Fri, May 04, 2007 at 12:13:05PM +0100
 New upstream - in fact I'm surprised that 2.14 is the latest available in 
 sarge!

In answer to your questions, it seems that none of the recent releases
have been noted on the TT2 website which still lists the latest version
as 2.15. I'll send a note to Andy about this.

I'm preparing an update now.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#419138: Mairix Segfaulting

[Benj. Mako Hill]

quote who=Vincent Lefevre date=Tue, Apr 24, 2007 at 03:11:35PM +0200
 On 2007-04-22 00:14:56 +0100, Richard Curnow wrote:
  I have finally been shamed into looking at this.  Attached are 2
  patches.  The first cures the problem.  The 2nd adds a diagnostic
  message if the problem is detected.
  
  Perhaps you guys can test these (especially the first patch) before I
  merge this into the master branch.
 
 They fix the problem, but there are so many Scanning messages that
 the diagnostic messages Header ... could not be parsed are not
 really visible.

I might suppress that when I apply the patch.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#420728: mairix finds no matches in UTF-8 locales

[Benj. Mako Hill]

Something's going on here. I *only* use mairix in UTF-8 locales and, as
you can imagine, it works just fine. Are you sure you have generated
your locale data?

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#420728: mairix finds no matches in UTF-8 locales

[Benj. Mako Hill]

quote who=Vincent Lefevre date=Wed, Apr 25, 2007 at 04:35:35PM +0200
 On 2007-04-25 09:21:21 -0400, Benj. Mako Hill wrote:
  Something's going on here. I *only* use mairix in UTF-8 locales and, as
  you can imagine, it works just fine. Are you sure you have generated
  your locale data?
 
 Yes, UTF-8 works fine with other applications.

My point was that it works fine with Mairix. I can't reproduce your bug.
I'm pretty sure you've got something screwing going on with your system.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#408179: [Templates] [EMAIL PROTECTED]: Bug#408179: Template::Stash::XS fails to set tied hash values]

[Benj. Mako Hill]

quote who=Andy Wardley date=Fri, Apr 20, 2007 at 01:58:49PM +0100
 Benj. Mako Hill wrote:
 I don't use Template::Stash::XS so I'm not really in a position to grok
 or fix this bug that was filed in Debian. At the moment, the Debian
 package/Ubuntu packages are not carrying around a delta to the library
 itself so it seem very unlikely that this is a problem that we've
 introduced.
 
 It was a problem in the XS Stash that was tickled by the latest version
 of Perl.  Steve Peters has provided a patch and it works OK now.  Expect
 a new version of TT some time soon.

Great. Thanks Andy for the reply.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#419069: Missing mairixrc man page

[Benj. Mako Hill]

severity minor
thanks

quote who=Chris Chiappa date=Fri, Apr 13, 2007 at 11:16:19AM -0400
 The mairix(1) manpage references the mairixrc manpage:
 ---===
 SEE ALSO
mairixrc(5)
 ===---
 but that page doesn't seem to be installed:
 
 $ dpkg -L mairix | grep man1/
 /usr/share/man/man1/mairix.1.gz

You're right. There are a few more more important bugs I'm waiting on
fixes for. I'll try to do an upload that fixes these and some other
things.

Thakns for the bug report and for using mairix! I appreciate the help!

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#419138: mairix segfaults on PowerPC

[Benj. Mako Hill]

retitle 419138 mairix segfaults
thanks

I am reasonably sure this is not powerPC based. I think it can be
cleared up by removing the old version of the database (usually
~/.mairix_database). Can you try this and verify that this does or
doesn't fix your problem?

Regards,
Mako

 
quote who=Vincent Lefevre date=Fri, Apr 13, 2007 at 11:29:58PM +0200
 Package: mairix
 Version: 0.20-1
 Severity: important
 
 ay:~/Mail mairix -p -v
 [...]
 Scanning /home/lefevre/Mail/oldarc/cur/1153867939.16800_502.prunille:2,RS
 Scanning /home/lefevre/Mail/oldarc/cur/1153867939.16800_504.prunille:2,S
 Scanning /home/lefevre/Mail/oldarc/cur/1153867939.16800_506.prunille:2,S
 zsh: segmentation fault (core dumped)  mairix -p -v
 
 ay:~/Mail gdb =mairix core
 GNU gdb 6.6-debian
 [...]
 Core was generated by `mairix -p -v'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x100165a0 in ?? ()
 (gdb) bt
 #0  0x100165a0 in ?? ()
 #1  0x1001628c in ?? ()
 #2  0x10008578 in ?? ()
 #3  0x10008ee8 in ?? ()
 #4  0x1000969c in ?? ()
 #5  0x10004e5c in ?? ()
 #6  0x100036ec in ?? ()
 #7  0x0fe40994 in ?? () from /lib/tls/libc.so.6
 #8  0x0fe40ad0 in __libc_start_main () from /lib/tls/libc.so.6
 Backtrace stopped: frame did not save the PC
 
 On Debian/x86 with the same mairix version and the same mailbox,
 mairix didn't segfault.
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers testing
   APT policy: (900, 'testing'), (900, 'stable'), (200, 'unstable')
 Architecture: powerpc (ppc)
 
 Kernel: Linux 2.6.18-3-powerpc
 Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages mairix depends on:
 ii  libbz2-1.0  1.0.3-6  high-quality block-sorting file 
 co
 ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
 ii  zlib1g  1:1.2.3-13   compression library - runtime
 
 mairix recommends no packages.
 
 -- no debconf information

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#315043: #315043: mairix fails with mmap: Invalid argument

[Benj. Mako Hill]

found 315043 0.17-2
found 315043 0.20-1
thanks

Greetings,

I've verified that this bug still shows up in versions 0.17 and 0.20 of
Mairix.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#379925: Bug Maintainance for libtext-wikiformat-perl

[Benj. Mako Hill]

severity 379925 minor
tag 379925 +upstream
tag 380563 +upstream
merge 380563 379925
retitle 380563 errors in manpage
thanks

Both of these bugs are about errors in the manual page for
libtext-wikiformat-perl. I'm merging these together and will fix them in
the next upload.

Thanks!

Regards,
Mako



-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#419138: mairix segfaults on PowerPC

[Benj. Mako Hill]

quote who=Vincent Lefevre date=Wed, Apr 18, 2007 at 08:35:25PM +0200
 On 2007-04-18 12:16:15 -0400, Benj. Mako Hill wrote:
  I am reasonably sure this is not powerPC based. I think it can be
  cleared up by removing the old version of the database (usually
  ~/.mairix_database). Can you try this and verify that this does or
  doesn't fix your problem?
 
 Same problem, at the same position:
 
 Scanning /home/lefevre/Mail/oldarc/cur/1153867939.16800_502.prunille:2,RS
 Scanning /home/lefevre/Mail/oldarc/cur/1153867939.16800_504.prunille:2,S
 Scanning /home/lefevre/Mail/oldarc/cur/1153867939.16800_506.prunille:2,S
 zsh: segmentation fault (core dumped)  mairix -p -v
 mairix -p -v  54.23s user 29.04s system 16% cpu 8:39.18 total

Grr... Good to know. Thanks for getting back to me on this.

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#419138: mairix segfaults on i386 (i686)

[Benj. Mako Hill]

quote who=Gijs Hillenius date=Sun, Apr 15, 2007 at 06:02:05PM +0200
 Package: mairix
 Version: 0.20-1
 Followup-For: Bug #419138
 
 This is the output of gdb

Remove the mairix database (~/.mairix_database ?) and then try running
it. Does this fix your issue?

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#419073: Adopt Packages

[Benj. Mako Hill]

retitle 419079 ITA: libtext-wikiformat-perl -- translates Wiki formatted text 
into other formats
owner 419079 [EMAIL PROTECTED]
retitle 419080 ITA: pwsafe -- command line encrypted password database
owner 419080 [EMAIL PROTECTED]
retitle 419073 ITA: reseed -- seeds urandom with a truly random seed
owner 419073 [EMAIL PROTECTED]
thanks

I'm going to adopt pwsafe, libtext-wikiformat-perl, reseed, because I
use and like these packages and am looking to take on few packages
becuase I am looking to orphan a couple of my own soon.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#418348: libtemplate-perl 2.15-0.0 (unstable/alpha): FTBFS under sudo

[Benj. Mako Hill]

Thanks Steve,

I'll take a look into this today.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#418348: libtemplate-perl 2.15-0.0 (unstable/alpha): FTBFS under sudo

[Benj. Mako Hill]

quote who=Info, GuiaArtistica.com.ar date=Mon, Apr 09, 2007 at 12:12:40PM 
-0300
 I am a victim of abuse.. a person put my email in much mailing list... 
 
 PLEASE UNSUBSCRIBE ME

I'm not sure which email list you are subscribed to but you should be
able to follow instructions at the bottom of mails or in email headers
and unsubscribe yourself. :)

Later,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#418348: libtemplate-perl 2.15-0.0 (unstable/alpha): FTBFS under sudo

[Benj. Mako Hill]

quote who=Steve Langasek date=Mon, Apr 09, 2007 at 03:20:49AM -0700
 A likely cause for this error is use of $(PWD) in debian/rules: recent
 versions of sudo do not propagate the caller's PWD env variable by default,
 and sudo ./debian/rules only invokes make, so this variable will be unset. 
 Please use the make built-in variable $(CURDIR) instead.

In fact, the problem here lines in Makefile.PL which is looking for
$ENV{PWD}. I'll work around this, try to fix #411044, and upload right
away.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#411044: libtemplate-perl: circular dependency hell

[Benj. Mako Hill]

quote who=Bill Allombert date=Thu, Feb 15, 2007 at 02:13:03PM +0100
 There is a circular dependency between libtemplate-perl and
 libtemplate-plugin-gd-perl:
 
 libtemplate-perl :Depends: libtemplate-plugin-gd-perl
 libtemplate-plugin-gd-perl :Depends: libtemplate-perl (= 2.15)
 
 Circular dependencies between libraries are known to cause problems
 during upgrade, so we should try to get rid of them.

This was introduced in an NMU recently. I'll try to address it in my
next upload.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature

Bug#408179: Template::Stash::XS fails to set tied hash values

[Benj. Mako Hill]

tag 408179 upstream
thanks

quote who=Joshua T. Corbin date=Tue, Jan 23, 2007 at 06:09:25PM -0500
 This is a regression from Template::Stash::XS in 2.14-1, downgrading the
 package to previous version fixes this.
 
 Looking at the upstream changelog suggests the only changes between 2.14
 and 2.15 were to explicitly fix issues with the xs stash and tied
 hashes, so I am reporting this error against the debian package.

In fact, there were no changes in the Debian package to any of the code
in question. This is, in fact, an upstream bug and I've gone ahead and
forwarded it to the Template Toolkit list.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



signature.asc
Description: Digital signature