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#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#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: 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#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#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#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#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#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#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#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#413469: bug 413469

[Benj. Mako Hill]

quote who=Tuomo Valkonen date=Thu, Mar 15, 2007 at 08:50:21AM +0200
 On 2007-03-14 19:58 -0400, Michael Gilbert wrote:
  with that said, i agree that in-development snapshots should be kept
  out of unstable, and only done in experimental.  maybe this should be
  a change to debian-policy?
 
 Nah, dev. snapshots can be in testing/unstable.. but should never get
 into stable... unless, of course, through an additional package
 collection for it (backports), that does keep upgraded.

Right. I don't see any reason to categorically keep all development
snapshots out of unstable/testing.

Development snapshot can mean different things in the context of
different projects. Our actions should be shaped more by the nature of
individual projects and by the expressed desire of upstream developers
than by whether or not the version number contains a date.

In this case, I see absolutely no reason to keep ion3 out of unstable
and testing -- especially since Tuomo says he doesn't either.

Regards,
Mako

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



signature.asc
Description: Digital signature

Bug#403994: marked as done (file conflict with webmagick)

[Benj. Mako Hill]

quote who=Debian Bug Tracking System date=Wed, Dec 27, 2006 at 10:03:25AM 
-0800
 Your message dated Wed, 27 Dec 2006 17:47:02 +
 with message-id [EMAIL PROTECTED]
 and subject line Bug#403994: fixed in aub 2.2.1
 has caused the attached Bug report to be marked as done.
 
 This means that you claim that the problem has been dealt with.
 If this is not the case it is now your responsibility to reopen the
 Bug report if necessary, and/or fix the problem forthwith.

Thanks Andreas for clearing this up!

As you know, it's the Holiday sand I've been traveling and largely
unresponsive over the last week or so. I saw the bug but had not had an
opportunity to address it yet.

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#322235: most and the libslang2

[Benj. Mako Hill]

severity 315639 grave
tags 315639 sid
merge 315639 322235
tags 322235 pending
tags 315639 pending
thanks

These two bugs are the same problem.

In any case, a fixed version of most that includes the latest upstream
version (4.10.2) has been prepared, uploaded and accepted and both of
these bugs should be closed as soon as that hits the archive.

Regards,
Mako

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



signature.asc
Description: Digital signature