Bug#974490: lmod: autopkgtest must be marked superficial

[Aaron Zauner]

PS: I'm barely maintaining this package anymore due to the amount of work I
have at the moment and me not working in the hpc sector anymore. But I get
regular bug reports and fixes for this package. Lucas Nussbaum was asking
around for a new maintainer, but while apparently quite a few people use
it, no one wants to actively maintain it.

Recently another person wrote me he maintains a current PPA for Ubuntu - I
wasn't even aware of that.

Aaron

On Wed 11. Nov 2020 at 20:41, Aaron Zauner (azet)  wrote:

> Hi,
>
> > On 11.11.2020, at 20:30, Paul Gevers  wrote:
> >
> > Hi Aaron,
> >
> >> On 11-11-2020 20:11, Sudip Mukherjee wrote:
> >> Hi Aaron,
> >>
> >>> On Wed, Nov 11, 2020 at 7:02 PM Aaron Zauner (azet) 
> wrote:
> >>>
> >>> Hey,
> >>>
> >>> That command does load everything that lmod needs in terms of
> dependencies and checks the environment. It's not a proper test suite but
> none exists so far, and I think this is sufficient to see if there's any
> bugs related to dependencies or the main function of the tool. writing a
> empty module to test lmod won't be any more effective.
> >
> > I have no clue what lmod does.
>
> Loads different environments for different compilers, blas and other
> libraries as toolchains for development, usually on high performance
> computing systems. it's based on "environment modules" an old tool from the
> HPC world that's very out of date but has a lot of modern and fast features
> to change the environment to the toolchain you need to work with for eg
> local development or sending cluster jobs.
>
> >
> >> I think what you said exactly matches my description in the bug. :)
> >
> > So do I.
> >
> >>>> Executing that command is considered to be a trivial test, which
> >>>> does not provide significant coverage for a package as a whole.
> >>>> But these tests are a useful way to detect regressions in dependencies
> >>>> and prevent them from breaking your package.
> >>
> >>>
> >>> If you can find a better alternative I'm all in, this was the best I
> could come up with when packaging initially. If you still think it should
> be marked superficial please do so.
> >
> > So, can you elaborate why you think that this test is substantially
> > testing your package. E.g. we have (for now) accepted that meta packages
> > actually do not much more than testing dependencies? But e.g. Python
> > modules or Node modules that just do an include are superficial. And so
> > are all tests that just print the version number although that "load
> > everything that X needs in terms of dependencies". These tests are
> > valuable, except they are not enough to warrant the exception that we
> > are giving packages with non-superficial tests during regular migration
> > (reduced age) and the bullseye freeze (longer period of uploading
> > without needing the release team).
>
> As I said I'm not aware that there's any test suite for lmod or I'd have
> included it. Writing a dummy module for the system toolchain gcc glibc etc
> won't really tell anything useful about lmod itself. Again: if you think it
> should be marked superficial that's fine by me.
>
> Aaron
>
> >
> > Paul
> >
>

Bug#974490: lmod: autopkgtest must be marked superficial

[Aaron Zauner (azet)]

Hi,

> On 11.11.2020, at 20:30, Paul Gevers  wrote:
> 
> Hi Aaron,
> 
>> On 11-11-2020 20:11, Sudip Mukherjee wrote:
>> Hi Aaron,
>> 
>>> On Wed, Nov 11, 2020 at 7:02 PM Aaron Zauner (azet)  wrote:
>>> 
>>> Hey,
>>> 
>>> That command does load everything that lmod needs in terms of dependencies 
>>> and checks the environment. It's not a proper test suite but none exists so 
>>> far, and I think this is sufficient to see if there's any bugs related to 
>>> dependencies or the main function of the tool. writing a empty module to 
>>> test lmod won't be any more effective.
> 
> I have no clue what lmod does.

Loads different environments for different compilers, blas and other libraries 
as toolchains for development, usually on high performance computing systems. 
it's based on "environment modules" an old tool from the HPC world that's very 
out of date but has a lot of modern and fast features to change the environment 
to the toolchain you need to work with for eg local development or sending 
cluster jobs.

> 
>> I think what you said exactly matches my description in the bug. :)
> 
> So do I.
> 
>>>> Executing that command is considered to be a trivial test, which
>>>> does not provide significant coverage for a package as a whole.
>>>> But these tests are a useful way to detect regressions in dependencies
>>>> and prevent them from breaking your package.
>> 
>>> 
>>> If you can find a better alternative I'm all in, this was the best I could 
>>> come up with when packaging initially. If you still think it should be 
>>> marked superficial please do so.
> 
> So, can you elaborate why you think that this test is substantially
> testing your package. E.g. we have (for now) accepted that meta packages
> actually do not much more than testing dependencies? But e.g. Python
> modules or Node modules that just do an include are superficial. And so
> are all tests that just print the version number although that "load
> everything that X needs in terms of dependencies". These tests are
> valuable, except they are not enough to warrant the exception that we
> are giving packages with non-superficial tests during regular migration
> (reduced age) and the bullseye freeze (longer period of uploading
> without needing the release team).

As I said I'm not aware that there's any test suite for lmod or I'd have 
included it. Writing a dummy module for the system toolchain gcc glibc etc 
won't really tell anything useful about lmod itself. Again: if you think it 
should be marked superficial that's fine by me.

Aaron

> 
> Paul
> 

Bug#951508: lmod: broken on all architectures except x86_64 (wrong search path)

[Aaron Zauner]

Hey,

Thanks for working this out guys! I think arch:all is a good solution
having the Lua paths fixed upstream.

Aaron

On Mon, Oct 26, 2020 at 1:45 PM Lucas Nussbaum  wrote:

> Hi,
>
> On 26/10/20 at 11:19 +0100, Baptiste Jonglez wrote:
> > Hi,
> >
> > On Tue, 15 Sep 2020 12:32:34 +0200 "Aaron Zauner (azet)" 
> wrote:
> > > If anyone wants to take over I'm more than fine with that. The amount
> of work I have at the moment barely permits me from maintaining projects.
> It's most sensible that someone actively using this project on Debian
> maintains it, as is, I'm not using it much anymore and am not working in
> HPC at the moment. The bug should definitely reported upstream. Upgrading
> the package should be fairly simple though - the dependencies are already
> in place, as are simple tests/git integration etc.:
> https://github.com/azet/lmod-deb
> >
> > I had a look, and it seems to be an upstream "feature" that was
> introduced
> > between lmod 6.2 and lmod 6.3.
> >
> > The root cause is that the configure script uses the build-time paths
> from
> > lua, and then uses these paths at runtime.  The upstream changelog for
> 6.3
> > states:
> >
> > > Lmod now uses the values of LUA_PATH and LUA_CPATH at configuration
> > > time.  This way Lmod is safe from user changes to these important Lua
> > > values.
> >
> > The corresponding upstream change and discussion:
> https://github.com/TACC/Lmod/issues/112
> >
> > This was already reported for ARM and closed:
> https://github.com/TACC/Lmod/issues/338
> >
> > Overall, I think the simplest solution is to change the architecture to
> "any".
>
> Thanks Baptiste for the investigation.
> I've just uploaded an NMU to unstable, and will also upload a fix to
> stable.
>
> I also opened an RFA bug for this package to reflect the current
> situation (#972938).
>
> - Lucas
>

Bug#951508: A patch file

[Aaron Zauner (azet)]

Hi,

If anyone wants to take over I'm more than fine with that. The amount of work I 
have at the moment barely permits me from maintaining projects. It's most 
sensible that someone actively using this project on Debian maintains it, as 
is, I'm not using it much anymore and am not working in HPC at the moment. The 
bug should definitely reported upstream. Upgrading the package should be fairly 
simple though - the dependencies are already in place, as are simple tests/git 
integration etc.: https://github.com/azet/lmod-deb

Thanks,
Aaron

> On 15.09.2020, at 09:33, Lucas Nussbaum  wrote:
> 
> retitle 951508 lmod: broken on all architectures except x86_64 (wrong search 
> path)
> severity 951508 serious
> thanks
> 
> Hi,
> 
> We ran into the same bug on an arm64 system, so it looks like lmod is
> broken on all architectures except x86_64. I'm updating the bug title
> and the severity to reflect that.
> 
> I'm attaching the diffoscope output that shows that the generated
> packages are indeed different on amd64 and arm64.
> 
> A simple fix would be to turn this package into an Architecture:any
> package.  But indeed, it should probably be reported (and fixed) upstream.
> 
>> On 17/02/20 at 19:49 +0100, Aaron Zauner wrote:
>> Since I'm barely keeping this package updated I'd suggest that you use the
>> upstream Lmod project source with the dependencies that come with this
>> package, you'll get more bug fixes, Performance and features out of it in a
>> production environment. That's what we used to do on live HPC systems since
>> a lot of software needs to be built by hand outside of the distro packaging
>> anyway.
> 
> Err, if this is the case, maybe you should mark this package as orphaned
> or RFA? I'm also Ccing people who uploaded NMUs for the package. Maybe
> someone is interested in taking over.
> 
> Lucas
> 

Bug#951508: A patch file

[Aaron Zauner]

Thanks for the information, interesting. These paths are auto generated
during setup and installation as far as i know, so either we're breaking
something in the build process within the package or as you point out it's
an issue with the package building system. I'll look into it once i have a
bit more time.

Since I'm barely keeping this package updated I'd suggest that you use the
upstream Lmod project source with the dependencies that come with this
package, you'll get more bug fixes, Performance and features out of it in a
production environment. That's what we used to do on live HPC systems since
a lot of software needs to be built by hand outside of the distro packaging
anyway.

Thanks,
Aaron

On Mon 17. Feb 2020 at 19:45, Tamar Klein  wrote:

> I did try with "apt source lmod" on the same system, in order to check you
> suggestion.
> So yes, it is the same version as debian's package, we're currently using
> the packages from:
>  http://snapshot.debian.org/archive/debian/20200217T030244Z/
>
> (We started upgrading the system this morning, so the date of the archive
> is this morning's)
>
>
> On Mon, Feb 17, 2020 at 8:40 PM Aaron Zauner  wrote:
>
>> It might be related to the version. Keep in mind that the version
>> packaged for Debian is quite old. Did you try with the same version?
>>
>> On Mon 17. Feb 2020 at 19:39, Tamar Klein  wrote:
>>
>>> Hi
>>>
>>> Thanks for your suggestion.
>>>
>>> When downloading the source package and building it locally, the paths
>>> seems to be correct.
>>> So I guess that the problem is either debian packagers used the same
>>> version for powerpc and x86 or was doing cross-site compilation without
>>> passing the correct parameters.
>>> It seems that the package is only have to be re-built in powerpc
>>> environment.
>>>
>>

Bug#951508: A patch file

[Aaron Zauner]

It might be related to the version. Keep in mind that the version packaged
for Debian is quite old. Did you try with the same version?

On Mon 17. Feb 2020 at 19:39, Tamar Klein  wrote:

> Hi
>
> Thanks for your suggestion.
>
> When downloading the source package and building it locally, the paths
> seems to be correct.
> So I guess that the problem is either debian packagers used the same
> version for powerpc and x86 or was doing cross-site compilation without
> passing the correct parameters.
> It seems that the package is only have to be re-built in powerpc
> environment.
>

Bug#951508: A patch file

[Aaron Zauner]

Hi Tamar

This is something you need to bring up with the upstream maintainer of
lmod. Replacing hard coded paths for one architecture with another will
just break it for most users except for you.

I suggest opening a GitHub PR with reference to this Debian bug report and
an explanation what doesn't work, like in your initial bug report here:
https://github.com/TACC/Lmod

Thanks,
Aaron

On Mon 17. Feb 2020 at 17:39, Tamar Klein  wrote:

> attached the patch file
>

Bug#793355: lmod: diff for NMU version 6.6-0.1

[Aaron Zauner]

BTW: In production HPC environments similar configurations are deployed,
I've done so in a few different installations (plus a few other neat hacks
for usability).

I don't see why someone that installs lmod by choice wouldn't want them.
I've just been conservative w.r.t. automatically setting lmod up for the
user.

Aaron

On Mon, Nov 21, 2016 at 4:39 AM, Aaron Zauner <a...@azet.org> wrote:

> Sorry for the late reply.
>
> Thanks for working on this. I'm fine with the changes you've made. Haven't
> tested to be honest as I had limited time since you've worked on these
> changes to do so.
>
> Again thanks for updating,
> Aaron
>
> On Fri, Nov 11, 2016 at 11:57 PM, Ana Guerrero Lopez <a...@debian.org>
> wrote:
>
>> Control: tags 793355 + patch
>> Control: tags 793355 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for lmod (versioned as 6.6-0.1) and uploaded it
>> to DELAYED/10. This means in 10 days my package will be automatically
>> uploaded to the archive unless you upload a package yourself or
>> ask me to remove the package from the delayed queue.
>>
>> I'm doing the NMU because it would be a pity to release Stretch with an
>> old version of lmod. Since you're maintaining the package in github,
>> I forked your repository and you can see easily my changes at:
>> https://github.com/ana/lmod-deb
>>
>> Please, take a look, some of my changes are quite intrusive since I
>> made some changes to have lmod behaving like environment-modules:
>> - MODULEPATH can be set in a file /etc/lmod/modulespath
>> - added /etc/profile.d/lmod.sh so /usr/share/lmod/lmod/init/$SHELL
>> is automatically run.
>>
>> Best regards,
>> Ana
>>
>
>

Bug#793355: lmod: diff for NMU version 6.6-0.1

[Aaron Zauner]

Sorry for the late reply.

Thanks for working on this. I'm fine with the changes you've made. Haven't
tested to be honest as I had limited time since you've worked on these
changes to do so.

Again thanks for updating,
Aaron

On Fri, Nov 11, 2016 at 11:57 PM, Ana Guerrero Lopez  wrote:

> Control: tags 793355 + patch
> Control: tags 793355 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for lmod (versioned as 6.6-0.1) and uploaded it
> to DELAYED/10. This means in 10 days my package will be automatically
> uploaded to the archive unless you upload a package yourself or
> ask me to remove the package from the delayed queue.
>
> I'm doing the NMU because it would be a pity to release Stretch with an
> old version of lmod. Since you're maintaining the package in github,
> I forked your repository and you can see easily my changes at:
> https://github.com/ana/lmod-deb
>
> Please, take a look, some of my changes are quite intrusive since I
> made some changes to have lmod behaving like environment-modules:
> - MODULEPATH can be set in a file /etc/lmod/modulespath
> - added /etc/profile.d/lmod.sh so /usr/share/lmod/lmod/init/$SHELL
> is automatically run.
>
> Best regards,
> Ana
>

Bug#796208: ca-certificates: removal of SPI CA

[Aaron Zauner]

Hi,

+1 on removal of this CA from the default system trusted CA
certificates. I get why back in the day CAcert and similar
projects looked like a valid idea, but the CA landscape has changed
significantly [0] since then and a CA that does not conform with
modern technical and operational procedures should not be included
by default (e.g. CA/B baseline requirements [1], RFC3647, certificate
transparency [2] et cetera) in any distribution, especially one
that's that popular and widely used on servers. This also affects
Ubuntu [3]..

Thanks,
Aaron

[0] - https://lwn.net/Articles/663875/
  https://lwn.net/Articles/664385/
[1] - https://cabforum.org/baseline-requirements-documents/
[2] - https://www.certificate-transparency.org/how-ct-works
[3] - 
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/ca-certificates/wily/files/head:/spi-inc.org/



signature.asc
Description: Digital signature

Bug#762637: status of qtile package?

[Aaron Zauner]

Hi,

I was wondering what the status of this RFP is? I'd also be
interested in seeing this available as a debian package.

Thanks,
Aaron



signature.asc
Description: Digital signature

Bug#793355: New upstream version

[Aaron Zauner]

Hi Andreas,

Andreas Hilboll wrote:
 Package: lmod
 Version: 5.8-1
 
 For some months now, a new upstream version 6.0.1 of the lmod package is
 available (see http://sourceforge.net/projects/lmod/).
 
 It would be great if this could be packaged for Debian; currently sid
 includes lmod version 5.8-1

I'll see to get this done - though I have quite a busy schedule
currently, might take a bit.

 
 Apologies if this is not the right place to ask for a packaging upgrade;
 I couldn't find any guidelines on how to do this.

Nah that's fine :)

Aaron



signature.asc
Description: OpenPGP digital signature

Bug#779683: [Pkg-postgresql-public] Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Aaron Zauner]

Hi,

I think we should take this discussion to an appropriate PostgreSQL
mailing list (please feel free to include me in a thread if you start
one). But I think it's best to close this bug for now. I agree that MD5
needs to be replaced, but using plaintext instead is certainly no option.

Aaron



signature.asc
Description: OpenPGP digital signature

Bug#779683: [Pkg-postgresql-public] Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Aaron Zauner]

Michael Samuel wrote:
 Hi,
 
 On 5 March 2015 at 19:58, Christoph Berg m...@debian.org wrote:
 That's an excellent thought..  I wasn't aware of this.  Unfortunately,
 I'm not sure that we could make it the default in Debian as it requires
 server-side certificates be configured and used properly (correct?) but
 I don't see a reason to not support it and encourage its use.
 
 TLS-SRP verifies both client and server.

Yep. I confused SRP with PSK ciphersuites here. There're no ciphersuites
that support PKIX and SRP. Unfortunately there's also only AES-CBC
(mac-then-encrypt) as a possible option when using SRP.
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Aaron



signature.asc
Description: OpenPGP digital signature

Bug#779683: [Pkg-postgresql-public] Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Aaron Zauner]

Hi Stephen

Stephen Frost wrote:
 
 That's an excellent thought..  I wasn't aware of this.  Unfortunately,
 I'm not sure that we could make it the default in Debian as it requires
 server-side certificates be configured and used properly (correct?) but
 I don't see a reason to not support it and encourage its use.

Depends on the TLS ciphersuite in use. But generally; yes. If you want
an authenticated connection a server certificate will be required (could
be autogenerated though).

Aaron



signature.asc
Description: OpenPGP digital signature

Bug#779683: [Pkg-postgresql-public] Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Aaron Zauner]

Hi,

Stephen Frost wrote:
 
 PG supports client-side certificate based authentication which would be
 far better than any kind of password-based authentication.  If password
 based auth is insisted upon then TLS to verify the server-side and
 protect the network connection would be good and remove the need for the
 challenge/response protocol and lead to 'password' being an acceptable
 option there, but that doesn't mean it'd be a good default for Debian,
 imv, because we *don't* require server-authenticated TLS, or TLS at all,
 currently.  Further, I'm not convined that 'password' there would really
 be all that much better than 'md5' as, as has been discussed, if you
 have access to pg_authid then you have access to the PG data directory.
 Further, at that point, you've probably got access to the backend and
 with password-based auth the postmaster process will see the user's
 actual password.
 
 In the end, I think we might move to support SCRAM and simply deprecate
 md5 in favor of that rather than try to fix the current mechanism
 without breaking things because any such fix wouldn't be a serious
 improvement and would just mislead users into thinking it's safe.
 
 We're currently looking at getting SCRAM support by implementing SASL,
 but I'm worried that we'll then create a dependency on SASL that people
 won't be happy with and therefore I'm very curious about how difficult
 it'd be to implement proper SCRAM directly.  Do you know if there is
 BSD-licensed code (PG is entirely BSD licensed) that implements SCRAM?
 

Just to put the idea out there; PGSQL currently links to OpenSSL for
TLS, right? TLS has support for SRP [0] [1]. This could be used for
password based authenticated TLS sessions without client certificates.
Might be less of a burden on users than deploying PKIX with
client-certificates while still providing proper security.

Aaron

[0] https://en.wikipedia.org/wiki/TLS-SRP
[1] http://www.ietf.org/rfc/rfc5054.txt



signature.asc
Description: OpenPGP digital signature

Bug#779683: [Pkg-postgresql-public] Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Aaron Zauner]

Hi Stephen,

* Stephen Frost sfr...@snowman.net [04/03/2015 01:45:56] wrote:
 Aaron,
 
 * Aaron Zauner (a...@azet.org) wrote:
  Debian ships a set of Perl scripts to configure for PostgreSQL server
  configurations, these are quite outdated and are currently configuring
  authentication to use MD5 when 'password' should be used instead.
 
 Uh, no, using 'password' is far worse, and uniformly so, than using md5.
 I have no idea why anyone would think it's better to store a cleartext
 version of your password in the pg_authid data (note that pg_shadow is
 only a view now, I replaced it long ago when I rewrote the user/group
 system to be role-based).
 

I assumed 'password' is an alias for a stronger hashing scheme. Mea
culpa, I should have read the source-code, not only the package
content and upstream defaults. I was not aware that 'password' is
indeed 'plaintext'.

 Absolutely no would be the answer. 

Given your explaination I totally agree here. I'm good to close this
- but let's wait if mik replies to this as well.

 The PG community has long been discussing the possibility of providing a
 new authentication mechanism to replace the md5 one, but anyone who
 actually cares about security will be using Kerberos or Certificate
 based authentication anyway, so it hasn't been a priority.

Agreed - most enterprise or cloud deployment I've been involved with
use either PKIX or kerberos. This is a good security measure.
Replacing MD5 would be nice as well (scrypt, bcrypt?). But I guess a
debian bug report is the wrong place to discuss this.

Thanks for clearing this up  your quick reply,
Aaron


signature.asc
Description: Digital signature

Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Aaron Zauner]

Package: postgresql
Severity: important
Tags: security

Hi,

Debian ships a set of Perl scripts to configure for PostgreSQL server
configurations, these are quite outdated and are currently configuring
authentication to use MD5 when 'password' should be used instead.

http://www.openwall.com/lists/oss-security/2015/03/03/12

I'd recommend to change this setting ASAP. Open to discuss.

(Also applies to Ubuntu)

Thanks,
Aaron


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

Bug#764722: lmod: Please package 5.7.5 upstream release

[Aaron Zauner]

Hi Valentin,

* Valentin Plugaru valentin.plug...@uni.lu [141010 16:27]:
 Package: lmod
 Version: 5.6.2-1
 Severity: wishlist
 
 Dear Maintainer,
 
 Please package the upstream 5.7.5 Lmod [1,2], as several important bugs
 have been fixed [3].
 
 [1] http://sourceforge.net/projects/lmod/files/Lmod-5.7.5.tar.bz2/download
 [2] https://github.com/TACC/Lmod
 [3] http://sourceforge.net/projects/lmod/files/README/download

Will do, please give me a couple of days. Due to so many new releases
that robert (the Lmod maintainer) puts out regularily I could not keep
up with updating the package, as some magic how he builds his project
also regularily changes. Current releases seem to be more stable as
I take it from the lmod mailing list - so thanks for reminding me to
update the package ;)

Aaron


signature.asc
Description: Digital signature

Bug#744731: debian-maintainers: Please add Aaron Zauner as a Debian Maintainer

[Aaron Zauner]

Package: debian-maintainers
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please add my GPG Key to the Maintainer Keyring. Attached is the Jetring 
changeset.

Looking forward to becoming a DM,
Aaron

- -- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTSyUEAAoJEOTbZJL9ubXV/DsP/j8qN2gncAPkBXkJgeTy4NRe
gXouT9JsOm2ZITl0W75G/a8pQaa3S/U7zfr/8bpqGm1txxk4cWOMwh7kIUoE5YNc
Zm4RXdXFX7GXWeyGmKZlrKjH1gUgcY9s8WUoTnQsxDhasrtzTw1u2T/KAInO1b8m
fcV1GCpTWRmrPqs2fLOASVyMn5Fd4ThcStCP0Y2gn4aU91alYJcEkB8HpTK0FTt8
wOIVBT3Fv/5YVVmbatr16ZF4U6SXjW4XOyBJ9/ch+5XF/cgyTc58N1+V/Vdp6huR
zl/jnt8BaZGjOuffu8eJAw56C6GI/tThr5aU+ESmN9iZxc4fIZ0RxIlwqxqYmuCn
cQSJoL1W7qAelGS0H/W3nc7XRhXUr9J+9ULhzQH7kkCLciKfFHAK7B1ldx6Frun7
3/g2UjtnF9RFe2aStN6iLLckFJoMQ2vN1Tc7janbm7kw2ShA5jNFzmiW1DS2SD8M
ZnO1o3AgyW0bhkADHGQl2RLzB88xgYV7MtmtAuADN4Q66OZHfIIakoB3mPSDBz+4
JRmJCmZ63P79ag3Mg2k7alUT1o2YX97MfqU0btKFzeVvwduK3wxMJzHXHuNJ8fEj
jERUrdGDVRR6DefUZmMOZMip1sGyyasPUaluL2uY57rbn/UrV0nlOcYYa4a3eCuW
gHQ83r6smMOO23+LknBQ
=VHg2
-END PGP SIGNATURE-
Comment: Add Aaron Zauner a...@azet.org as a Debian Maintainer
Date: Mon, 14 Apr 2014 01:42:17 +0200
Action: import
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFCcSnUBEAD2qDQD7BMKzL9J667SrJQvKYeUEpvDrrPO+kFy7FXIzCYsRHuB
  5sPxrxRRCOZIGfvdby3iSJYdb6RG7n7S4f/3yf+jJsvB25fqwL/A8K1VKfjYHXW7
  XxJWeSbgOvil1+FPiUILVb7lh0qdDA3Br+bjbxnf5mB0IgzduTy1scW/Vc07HbcP
  I4dWb5cizmgYbeXOixUkLFKfY4ql8F0DB/LN7S8VjMVY1mp0jKFrNHskN24nPOV7
  W1cPpJjzItlPV31/EuQojFms95gmNexqjfaC/pE4eFniHK13efXbAoeQtMjmoqx8
  fOSF2HfoPdirlNyLlS/o253W0V+Z9/IGfC/MppEbAjLxDa42eIvFp8cXr2n/R6z6
  UiNlcLAGV3YJFHeKyfZtvFLaCe1HdSz7jIebp8H5Am1QbCv0WKY8KqyHCCO0BYp2
  fNVhCPT+YBm91o/K1cNndwsiZo4f3w2lsT3EMqZ8JG2JBEEYeue+kW0JEVg7BBM8
  4iRoDD6fc7GmBrl6pKjCccLMdU5eByL8HzdGdnEehkuAkj6iAZa9jfDU+hkHg2zQ
  m0zbOSC6t/0fIUK3D3LlSqEsEmWJEo8BApyncSrTMtZIFfrCvx07ZdW3IhKe00Cj
  8VN/uOVjfPXMUMJRqY3d+W28Ge5hBj4cbeaxtgI+Tfp8J9S+3qfcKonc2QARAQAB
  tBxBYXJvbiBaYXVuZXIgPGF6ZXRAYXpldC5vcmc+iQKFBBABAgBvBQJQnEqAMBSA
  ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQML
  CQoCGQEZGGxkYXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUbAwUWAwIBAAUeAQAA
  AAQVCggJAAoJEOTbZJL9ubXVk4IQAMPytRQOpGLsB2o+iD3ShQtpuztcyChbg4An
  8NUkZOJozjhBfdvoqizW9i0ufgusHmogm5K78J3Wm2Aw4KslUhDrrm/pmQOxffMj
  /i7icdAfyCzWAsayZrY7IjvJ0ml4KS6w/KEtw8awVFhaVdR1RzOdi7FItfjTN+xo
  N8TjqvBeUiF8nG0y890Qo5iGeiRfICHWC1hreHSOtKla668hnbx8syNQeY8Iv7kH
  /u/CnRJE3+1+6WskljC+RL3jUXYx88n3culW9qK2gsD+4BU+UoHOQ+9avdTlnXn2
  PRQ99X8YXItQ+XTDPgNdXSpgGxRo136+IeZc7Fi2uzaV6J33VzFaqe8mW4itWvQ8
  N+SxiJYIeD7a/RBZk1NXBL9RwZeveC+8LmbjUYKp2REPjAwfVQ7aa4GVs2Rr6gzt
  LC5WhYBJdKlFYF9AMqc29LXLUkWx4gLXHmy/e6Tn98aTdjMQb/EihOWA3ahfNN4c
  WVUHa0SB60glRABYJncviEnU0dfPSzbiVqdtlDAouy6gTo+Ze1+Up77dVsBkCnVa
  l0e5Lbc0i01TN9H4bP2Y3MdUfY+OqnZCAL8uWCTDsY8Es4buoc9CIhrn29e/it6M
  q94G0QoxT+Jw+itjp2uyVg3A5u5srZvlhpQO2bjae0FVuhKAqSkYrClpggTeZgoJ
  dz+V0J67iQEiBBABAgAMBQJQnEqeBQMAEnUAAAoJEJcQuJvKV618MNcIAMe5I/yQ
  c5IK5/pilsTRMEd640R1eOjAG02APDjgucBzb0lvoz52ozWZu4vA82ZoC+IbzSSB
  erRooKnYssviLvIVULcPYyfSDkzrNV3bumcRXXW2qYYTOW7bt+t5SVpKI17vY0M6
  AABesaGMkr4a1KpqB8bBvTCR2TDytqSDgKM3CcayTIci5tJvDZQMc4q1oRgFgscb
  PVErbeiqExQI9l3zJyZLFhGiaGTzKS6WgQLUDufxdSCKBVd89IMVxjpj7XzGg7W4
  j5qMJWiFFdatAWsLzl2MM190G7iIPYB66FnruvURT7vrGljjz7/ue8tgs2JMcMmj
  ukfzUP1b+eHn9ve5Ag0EUJxKeQEQAPJUwaZoPG9YNfSfXR3tGhjQR6XmnJcvX7XG
  R/UM8LWH/PkVVg3ByL/vk1oo2T/tj4Hc1jA88zAjpLpHN21N5Q48WKEheURYxA+T
  n4kCHgUPGMTJP8KB3Gp0/G4XyQc9hISYeFXc8nQIbWkcLRDLzyorhp8esptUY+yt
  I29UhgEIcKsNFWQHpLxDnOSJhseh4iY347BkWkbQIMrGaloWrYEhjofGa1Dc/Nna
  HnRlqyjMX7C9Vj8tr+uxSAOuhUNQs7hSElGoM5+gHzoE+MiBJVRz8DsTI9jmGq3D
  ClXSESJWb+Lq5ylciuGyDe3mSXKOwVpdVgRWZwMo3uwiZ1XXleSEUuljznY2Bygu
  JcvIoiCAigwpLNrGMHDGl2cz+i1qmrehB03JIK5BK7Myt6H+29sz96D95lwN0zB0
  QF0UqfJZelBQvKQH63qey3fNGDhy9r0RpRzgLK5gYXK6dAXQNZkaKf5L+4IiUOxP
  MylFli+WhRrfFjuK9eyvd/BNh/uvzbhWYFD3KMguac66yYTXh6u+YqT3k665TzAW
  yHAMxEyx89r+eC0tDQdDt/X8pxTWDK/qBKrYx/78dch42NWu0+goxGy+cYwHJel3
  1XkpfvdK4iNwmE0/BEPTSfV9xmO/0EfN+xYVc7APZQAScel4FqlaeEnF7kBaoJQZ
  Nwn/3Vv7ABEBAAGJBEEEGAECAisFAlCcSnoFGwwAAADBXSAEGQEIAAYFAlCcSnkA
  CgkQTra1n33wDLSCABAAs16f17ZLItY0qEqFmBu42yZqqSOnVReQzO/3Hwj7JuF6
  cM8KbDKptIKHdB5m0W1eqCpNGzShT6rf8eFdqm71LnENmNr5YfpQzmXYS6yYirdF
  tfeG3k4Gu1lANUNbTI7tZ+IWIurl7j8UOQfSxOA5C697Rdx1Td3WEwc54UyVSyj6
  PUFcmIKwVRGARGBGMYT7oscVihtggoXJSUlG/1UHsbvEVQue5GoEA4LXLjzhQoXk
  hzGJDHDXizo2wmjnczFkYJ9e5XKcv53GQtVlLLgNZeIG5nIjqzfAUyoY3BInt2kq
  7E+m7aTjd2KCTT9/chsC6t3c3j9UjGpFQF6P74wQu2k0BmJG/Wu1MzMiG6RRx/g8
  4ktqsRf9N8HiBVluCQSHuq4RghbOjmZJabVHIcVYRJljcXWrtm0dSGxovII+eemy
  wVVCYbAVw8FSPooBjc4d7MvMBNbW2RF7XPloLgXuw8oDOIC+KYXZPkjWOri9kC6Z
  uDkNm+wsBSLIAc4OcK

Bug#744731: debian-maintainers: Please add Aaron Zauner as a Debian Maintainer

[Aaron Zauner]

Package: debian-maintainers
Followup-For: Bug #744731

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Whoops, just noticed that I put the required Recommended-by, Agreement and 
Advocates field in the wrong place in the add-E4DB6492FDB9B5D5 file. Attached 
is an updated version with correct formatting.

Sorry for the confusion,
Aaron

- -- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTSy2pAAoJEOTbZJL9ubXVhA4QAIG8uP7Bu4PYoBorCJ5HAPVK
5gRNR31UfPZxSCQwe1Ob0rVtDY60sohd0AdhJkutx1Q12h34xOc/lF6dOJiXfSlr
KIG32c2Qm0yuYcN17seXd8SbELKN1wCuEnJ9TS9S92DFJHpaN4LHsImLZ0VUU9cZ
y02/V4hXc13+cK5oldMJkfFzZRzRfmcKBbrvvIS4b+UfO2wonXhoXdksSTQ8lRFT
f1fiuA0Xih0Cc3bBw12JvfavN1rzGOWO/gs8qpeSLAULrjUfNKJOMnqO63jT330b
tM3hYBzQJNVKrDYB7hy4kCb3TMzp7Jl072csBk6uEQXGD/o1Yh1UcUVQLLRlKAvJ
eeiswxjP7acVAzTjvJQARgkGFl4lDU+xdi50rrcFcI7kPP7NcIEQ7XJ9Os8Qcomu
pSTzOL0dU0hc6FxjJPy/1gURH2yP0z6x0IXhitb48nZeV0hVRkCKOL+6quMYZ0B8
uBNTeCqtgvD8EULC/vY+G77lVjijRFY8tz/GkQ9iXJv3GjCXa45y1TfYbGmZWj05
KcLfTgcNH3H4IkyAuGUGz2tANAaP18ZoeQFvPaGxdB7A402v1brXYNR1M3XLFJX9
7KV40tRzx9HDdmPL8SghGFqtEj9d9sGeYGminRqhobpnvoLJ0B29MhHX8rZ6av/V
0YFPdUxFpXEC4+2TxkgH
=uslS
-END PGP SIGNATURE-
Comment: Add Aaron Zauner a...@azet.org as a Debian Maintainer
Date: Mon, 14 Apr 2014 01:42:17 +0200
Action: import
Recommended-By: 
  Christian Hofstaedler z...@debian.org
Agreement: 
  https://lists.debian.org/debian-newmaint/2014/04/msg9.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2014/04/msg00011.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFCcSnUBEAD2qDQD7BMKzL9J667SrJQvKYeUEpvDrrPO+kFy7FXIzCYsRHuB
  5sPxrxRRCOZIGfvdby3iSJYdb6RG7n7S4f/3yf+jJsvB25fqwL/A8K1VKfjYHXW7
  XxJWeSbgOvil1+FPiUILVb7lh0qdDA3Br+bjbxnf5mB0IgzduTy1scW/Vc07HbcP
  I4dWb5cizmgYbeXOixUkLFKfY4ql8F0DB/LN7S8VjMVY1mp0jKFrNHskN24nPOV7
  W1cPpJjzItlPV31/EuQojFms95gmNexqjfaC/pE4eFniHK13efXbAoeQtMjmoqx8
  fOSF2HfoPdirlNyLlS/o253W0V+Z9/IGfC/MppEbAjLxDa42eIvFp8cXr2n/R6z6
  UiNlcLAGV3YJFHeKyfZtvFLaCe1HdSz7jIebp8H5Am1QbCv0WKY8KqyHCCO0BYp2
  fNVhCPT+YBm91o/K1cNndwsiZo4f3w2lsT3EMqZ8JG2JBEEYeue+kW0JEVg7BBM8
  4iRoDD6fc7GmBrl6pKjCccLMdU5eByL8HzdGdnEehkuAkj6iAZa9jfDU+hkHg2zQ
  m0zbOSC6t/0fIUK3D3LlSqEsEmWJEo8BApyncSrTMtZIFfrCvx07ZdW3IhKe00Cj
  8VN/uOVjfPXMUMJRqY3d+W28Ge5hBj4cbeaxtgI+Tfp8J9S+3qfcKonc2QARAQAB
  tBxBYXJvbiBaYXVuZXIgPGF6ZXRAYXpldC5vcmc+iQKFBBABAgBvBQJQnEqAMBSA
  ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQML
  CQoCGQEZGGxkYXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUbAwUWAwIBAAUeAQAA
  AAQVCggJAAoJEOTbZJL9ubXVk4IQAMPytRQOpGLsB2o+iD3ShQtpuztcyChbg4An
  8NUkZOJozjhBfdvoqizW9i0ufgusHmogm5K78J3Wm2Aw4KslUhDrrm/pmQOxffMj
  /i7icdAfyCzWAsayZrY7IjvJ0ml4KS6w/KEtw8awVFhaVdR1RzOdi7FItfjTN+xo
  N8TjqvBeUiF8nG0y890Qo5iGeiRfICHWC1hreHSOtKla668hnbx8syNQeY8Iv7kH
  /u/CnRJE3+1+6WskljC+RL3jUXYx88n3culW9qK2gsD+4BU+UoHOQ+9avdTlnXn2
  PRQ99X8YXItQ+XTDPgNdXSpgGxRo136+IeZc7Fi2uzaV6J33VzFaqe8mW4itWvQ8
  N+SxiJYIeD7a/RBZk1NXBL9RwZeveC+8LmbjUYKp2REPjAwfVQ7aa4GVs2Rr6gzt
  LC5WhYBJdKlFYF9AMqc29LXLUkWx4gLXHmy/e6Tn98aTdjMQb/EihOWA3ahfNN4c
  WVUHa0SB60glRABYJncviEnU0dfPSzbiVqdtlDAouy6gTo+Ze1+Up77dVsBkCnVa
  l0e5Lbc0i01TN9H4bP2Y3MdUfY+OqnZCAL8uWCTDsY8Es4buoc9CIhrn29e/it6M
  q94G0QoxT+Jw+itjp2uyVg3A5u5srZvlhpQO2bjae0FVuhKAqSkYrClpggTeZgoJ
  dz+V0J67iQEiBBABAgAMBQJQnEqeBQMAEnUAAAoJEJcQuJvKV618MNcIAMe5I/yQ
  c5IK5/pilsTRMEd640R1eOjAG02APDjgucBzb0lvoz52ozWZu4vA82ZoC+IbzSSB
  erRooKnYssviLvIVULcPYyfSDkzrNV3bumcRXXW2qYYTOW7bt+t5SVpKI17vY0M6
  AABesaGMkr4a1KpqB8bBvTCR2TDytqSDgKM3CcayTIci5tJvDZQMc4q1oRgFgscb
  PVErbeiqExQI9l3zJyZLFhGiaGTzKS6WgQLUDufxdSCKBVd89IMVxjpj7XzGg7W4
  j5qMJWiFFdatAWsLzl2MM190G7iIPYB66FnruvURT7vrGljjz7/ue8tgs2JMcMmj
  ukfzUP1b+eHn9ve5Ag0EUJxKeQEQAPJUwaZoPG9YNfSfXR3tGhjQR6XmnJcvX7XG
  R/UM8LWH/PkVVg3ByL/vk1oo2T/tj4Hc1jA88zAjpLpHN21N5Q48WKEheURYxA+T
  n4kCHgUPGMTJP8KB3Gp0/G4XyQc9hISYeFXc8nQIbWkcLRDLzyorhp8esptUY+yt
  I29UhgEIcKsNFWQHpLxDnOSJhseh4iY347BkWkbQIMrGaloWrYEhjofGa1Dc/Nna
  HnRlqyjMX7C9Vj8tr+uxSAOuhUNQs7hSElGoM5+gHzoE+MiBJVRz8DsTI9jmGq3D
  ClXSESJWb+Lq5ylciuGyDe3mSXKOwVpdVgRWZwMo3uwiZ1XXleSEUuljznY2Bygu
  JcvIoiCAigwpLNrGMHDGl2cz+i1qmrehB03JIK5BK7Myt6H+29sz96D95lwN0zB0
  QF0UqfJZelBQvKQH63qey3fNGDhy9r0RpRzgLK5gYXK6dAXQNZkaKf5L+4IiUOxP
  MylFli+WhRrfFjuK9eyvd/BNh/uvzbhWYFD3KMguac66yYTXh6u+YqT3k665TzAW
  yHAMxEyx89r+eC0tDQdDt/X8pxTWDK/qBKrYx/78dch42NWu0+goxGy+cYwHJel3
  1XkpfvdK4iNwmE0/BEPTSfV9xmO/0EfN+xYVc7APZQAScel4FqlaeEnF7kBaoJQZ
  Nwn/3Vv7ABEBAAGJBEEEGAECAisFAlCcSnoFGwwAAADBXSAEGQEIAAYFAlCcSnkA
  CgkQTra1n33wDLSCABAAs16f17ZLItY0qEqFmBu42yZqqSOnVReQzO/3Hwj7JuF6
  cM8KbDKptIKHdB5m0W1eqCpNGzShT6rf8eFdqm71LnENmNr5YfpQzmXYS6yYirdF
  tfeG3k4Gu1lANUNbTI7tZ+IWIurl7j8UOQfSxOA5C697Rdx1Td3WEwc54UyVSyj6

Bug#743966: ITP: lua-term -- a Lua module for manipulating a terminal

[Aaron Zauner]

Package: wnpp
Severity: wishlist
Owner: Aaron Zauner a...@azet.org

* Package name: lua-term
  Version : 0.03
  Upstream Author : Rob Hoelz r...@hoelzro.net
* URL : https://github.com/hoelzro/lua-term
* License : MIT
  Programming Lang: Lua
  Description : a Lua module for manipulating a terminal


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

Bug#743967: Botan is built without Python support

[Aaron Zauner]

Package: libbotan1.10-dev
Version: 1.10.5-1
Severity: wishlist



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=locale: Cannot set LC_CTYPE 
to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libbotan1.10-dev depends on:
ii  libbotan-1.10-0  1.10.5-1

libbotan1.10-dev recommends no packages.

libbotan1.10-dev suggests no packages.

-- debconf information excluded


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

Bug#743967: Botan is built without Python support

[Aaron Zauner]

Hi,

reportbug(1) seems to have discarded my bug description:


```
Botan may build with optional Python language support that can be
configured by the configure.py option --with-boost-python and
optionally --with-python-version=$version. Although Python bindings
are currently considered Alpha by the upstream Botan authors, those
could be potentially useful for developers.
```

Sorry for the confusion,
Aaron



signature.asc
Description: OpenPGP digital signature

Bug#743823: ITP: lmod -- Lua environment modules

[Aaron Zauner]

Package: wnpp
Severity: wishlist
Owner: Aaron Zauner a...@azet.org

* Package name: lmod
  Version : 5.3.2
  Upstream Author : Robert McLay
* URL : https://www.tacc.utexas.edu/tacc-projects/lmod
* License : MIT
  Programming Lang: Lua
  Description : Lua environment modules

Lmod is a Lua based module system that easily handles the MODULEPATH
Hierarchical problem. Environment Modules provide a convenient way to
dynamically change the users' environment through modulefiles. This
includes easily adding or removing directories to the PATH environment
variable. Modulefiles for Library packages provide environment variables
that specify where the library and header files can be found.


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