Re: Seeking feedback on a meta package builder

[Matt Zagrabelny]

On Thu, Jun 10, 2021 at 8:01 AM Raphael Hertzog  wrote:

>
> > > PS: I already hate the "mdbp" name after having it typed so many times.
> >
> > I'm not attached to either. Any suggestions?
>
> sbp for "standardized build package" is easier to type but not necessarily
> nicer.
>
> "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I
> don't care how it gets built!).
>

vendeb - vending machine for .deb


> "deblord" or "debring" - the lord of the ring to tie all package builders
> together
>

omegabuild - the last build system (also sort of a joke about being far
from alpha software.)

-m

Re: Heads up: persistent journal has been enabled in systemd

[Matt Zagrabelny]

On Thu, Feb 6, 2020 at 11:03 AM Matthias Klumpp  wrote:
>
> >From personal experience, all that's needed to switch to the journal
> for an admin is to re-learn a couple of commands and be open to a bit
> of change. I so far found nothing that I could do with rsyslog to be
> impossible with the journal.

Additionally you don't have to guess where logs are being sent for a
particular service:

systemd: journalctl --since=-1h -u puppet

non-systemd: grep puppet /var/log/*
though that is inefficient and would possibly miss some data or give
false positives.

-m

Re: Heads up: persistent journal has been enabled in systemd

[Matt Zagrabelny]

On Wed, Feb 5, 2020 at 3:03 PM Dmitry Smirnov  wrote:

>
> Anyway the big disadvantage of changing default is that now random Debian
> systems will have no traditional logging interface (rsyslog) and we're all
> will be forced to adapt to the new interface in the absence of old one on
> some systems...
>

>From Michael's initial email:

"Depending on how it goes, I might ask the ftp-masters to lower the
priority of rsyslog from important to optional, so it would no longer be
installed by default on new bullseye installations."

As of right now, the only change is to enable persistent journal logs.

Text logs will still be there with the current systemd upload.

-m

Re: Heads up: persistent journal has been enabled in systemd

[Matt Zagrabelny]

On Tue, Feb 4, 2020 at 5:15 PM Scott Kitterman  wrote:
>
> On Tuesday, February 4, 2020 5:22:15 PM EST Vincent Bernat wrote:
> >  ❦  4 février 2020 11:30 -08, Russ Allbery :
> > >> As a heavy user or Rsyslog features I feel that switching default
> > >> logging system yields no benefits to say the least.
> > >
> > > As a heavy user, perhaps you're not the target audience for a default?
> > > You're going to install rsyslog no matter what, since you know it well and
> > > use it heavily.  The only effect of this change on you will be a one-line
> > > change to whatever you use for configuration management for new
> > > systems.
> >
> > rsyslog even knows how to directly pull logs from the journal, which
> > gives you access to stuff not logged to syslog (stdout/stderr of service
> > files, applications logging directly to journal), as well to structured
> > logs (comm pid, user, unit and more when the service supports journald
> > directly).
>
> For those of us who aren't customizers of Debian's logging function, it'd be
> nice to have a clearer understanding of what this changes means.
>
> Today, when, for example, I want to investigate something email related, I
> look in /var/log/mail.log.

Random email related journal commands:

journalctl -u postfix
journalctl -f -u postfix
journalctl -b -u postfix

the -u is for the unit name. the -b is for since boot. man journalctl
for details.

  Other specialized log files for their special
> purposes.  For data not covered by a specialized log, I look in /var/log/
> syslog.
>
> Will the specialized log files still be there?

I suppose it depends. Do the processes write to /dev/log or manually
write to files?

  Will the net effect be that I
> just need to look in /var/log/journal (or something similar) instead of in /
> var/log/syslog?

The contents of /var/log/journal will be binary files that journalctl
will read. IIRC.

  Is the persistent journal a text file or will I need
> specialized tools to interact with it?

specialized: journalctl.

-m




>
> Scott K

Re: Git Packaging Round 2: When to Salsa

[Matt Zagrabelny]

On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz  wrote:

>
> > There are a number of ways forward:
> >
> >[...]
> > 5) Make no recommendations in this space
>
> Why do all things need a recommendation? List the possible places to
> host a repository with their advantages/disadvantages. If somebody is
> not able to decide where to put a package based on that, they might not
> be able to maintain it anyway.
>

Having sensible recommendations reduces the barrier to entry. Even if you
provide a list with all the pros/cons there is still a decision to be made.
Every decision that needs to be made is a barrier. Reading and
understanding, research and applying context, contemplating and making
decisions.

I'm not suggesting that maintainers don't (eventually) understand all of
the relevant details and particulars. Sometimes not forcing them to drink
from the fire hose right away could be considered polite.

-m

Re: Handling of entropy during boot

[Matt Zagrabelny]

On Wed, Jan 9, 2019 at 12:13 PM Theodore Y. Ts'o  wrote:

> On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote:
> >
> > There have been a number of bug reports and blog posts about this,
> despite
> > buster not being release yet. So it's not that uncommon.
>
> Pointers, please?  Let's see them and investigate.


https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912616

There's lots of chatter in the systemd github isses, too.

I've been bitten by both ssh taking forever and puppet timing out on VMs.
I'll need to investigate about virtio-rng.

I've got an embedded x86-64 system where lightdm starts quickly when I am
plugged into an ethernet connection, but takes about 8 minutes when the
ethernet is disconnected. I am very suspicious of the low entropy in this
case, too.

-m

Accepted cdpr 2.4-2 (source amd64) into unstable

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 25 Jun 2018 16:02:40 -0500
Source: cdpr
Binary: cdpr
Architecture: source amd64
Version: 2.4-2
Distribution: unstable
Urgency: medium
Maintainer: Matt Zagrabelny 
Changed-By: Matt Zagrabelny 
Description:
 cdpr   - Cisco Discovery Protocol Reporter
Closes: 632665 901066
Changes:
 cdpr (2.4-2) unstable; urgency=medium
 .
   * [895bdef] d/control replace priority extra with priority optional.
   * [202edaa] bump standards version
   * [a667541] bump debhelper compat level
   * [87086e0] remove versioned dependency for libpcap0.8-dev.
   * [811a051] update git repo to salsa.debian.org
   * [cf9615d] enable all hardening options
   * [0d80c19] comment out CFLAGS to allow dpkg-buildflags to set CFLAGS.
   * [79a3c5b] fix ftbs with ld --as-needed, closes: #632665.
   * [3900e99] Simplify Makefile, add CPPFLAGS for hardening,
 also closes: #901066.
   * [d6595fa] update URI for machine parsable copyright format 1.0
   * [cd7664e] update copyright year for debian/* files
   * [ebf169d] update GPL-2+ text in d/copyright
Checksums-Sha1:
 4ce46b0fa5309ac2c7b8fc8e5e9e0dd459f86d0e 1783 cdpr_2.4-2.dsc
 0ca444d5a5732116b55ddb06a5d1f07601b39ea2 4812 cdpr_2.4-2.debian.tar.xz
 c5cc69a85dad235c61be9182466d7119cdea6db7 22404 cdpr-dbgsym_2.4-2_amd64.deb
 cd837b3b46bba8adb8113d69bd585597922442bb 5758 cdpr_2.4-2_amd64.buildinfo
 c4a8833169419c37f64a13f1c806f315a17686c1 19524 cdpr_2.4-2_amd64.deb
Checksums-Sha256:
 f910e68465135a006c1900538e9e6cb0e70980414535f29146f68ebb8b7fef8e 1783 
cdpr_2.4-2.dsc
 b2a5a0f608f39cd36e4ab890a752256c018ec4f75379508fad2a08ef986bd1ab 4812 
cdpr_2.4-2.debian.tar.xz
 61f142c11d07333ebff4e0b29fb8c12bf13469c09a33c01c424de574306112f1 22404 
cdpr-dbgsym_2.4-2_amd64.deb
 6b31120e04737f095b75abfcdf89c6e5f309551b47593123b88b6552280db281 5758 
cdpr_2.4-2_amd64.buildinfo
 d7bbc179be0ad2b1fa2e38d4106b2939565c2bff19b3e1d9ac3e13021f373314 19524 
cdpr_2.4-2_amd64.deb
Files:
 17745e7f6d2bd786f49cacf7b012ef3c 1783 net optional cdpr_2.4-2.dsc
 c15c59ed87d0b5a9aa635644a1bbf5a8 4812 net optional cdpr_2.4-2.debian.tar.xz
 998c6052292cc6f92c72f0df7ce84e25 22404 debug optional 
cdpr-dbgsym_2.4-2_amd64.deb
 00bd5a7268203010e11067edc065da2d 5758 net optional cdpr_2.4-2_amd64.buildinfo
 7e82727fc6eced8994ce3f3191a094ee 19524 net optional cdpr_2.4-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfAcX+forK514ixQbptwk2dokk9EFAlsx4QcACgkQptwk2dok
k9F3Rw//fvylF25STLzdFLVxcxyZ7nFugv3qoyFc2IiyvxjQaQ0tLq9SAWi8EwIb
rBpFiSA9hF8R7oS3pXH1YF8UnPTo6baBq9fK+Bwm36s8zdW6BztKaI8APwqAEPz/
8on/xJTvJUKugMhR4B8RUm41P+kROSRo6Mdj7wn5KbjdCAdga6huKLCjkxaHBl4D
2CPK+YY2JIhhnqluBFUPvqV2Bz5pahkSiZaGesfTQTDn/+ZSQ0Ywg/KAQr1FQYnt
8BJnqlRS7SsAbZ0Aj5K7mAiEo0GLmuBE2nuhNN4Upc5MyMX53Fk1x0c9y8LY85YF
WshJp1yC6pvRj8+h2uYmWDUavoB+b3Bot0SQtcqnlikgR1IW4OYqB0ty2nzxA1YL
gpyaWUsXF1hBQLTQPkXzLkIsgG2Q/0scyVK4lxqGTOejckji7xgprLgGAmqEKSsI
++lphxA1r77EHZ9zvyH+YJmO3pzslfodQ0UGxwfU+FiE0H+852lWq6O4amLaehim
Vo2QfLyvYqlg+pTKrpLAHvYiJLD3k07Ws4REoJOCrbZGChjVYiytZTTRm8DAOKvq
XphI5cuhDQ/dkWu0Qmq3mJ/vaY1+FbtP27ggacjEIRMNn4cFNdocs/EgVYM/Qeeq
y0axyiP5Mc1xYBqG3PFDeTvhywtztxW2tQQiqxwBsMjdSITTvts=
=7BPJ
-END PGP SIGNATURE-

DEP-14 Git branch names?

[Matt Zagrabelny]

Greetings Devel,

In November of 2014 Raphael Hertzog  posted [0] to
-devel about a proposal (DEP-14) for recommended git branch names.

The links he referenced are:

http://dep.debian.net/deps/dep14

http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn

and are both dead. Did DEP-14 find any traction with developers? I've
searched a bit and can't find any hint of a "resolution" after the
discussion or a current working link.

Thanks for any commentary,

-m

[0] https://lists.debian.org/debian-devel/2014/11/msg00444.html

Re: Debian part of a version number when epoch is bumped

[Matt Zagrabelny]

On Wed, Feb 14, 2018 at 2:15 PM, Michael Stone  wrote:

> On Wed, Feb 14, 2018 at 09:05:05PM +0100, Vincent Bernat wrote:
>
>> In the example above, while in Wheezy, the dependency was perfectly
>> correct. It became wrong because of the epoch bump (for no obvious
>> reason). For software we distribute ourselves, this change can be caught
>> at some point before the release (or by automation, like you suggest),
>> but for people packaging stuff outside Debian, this can be far more
>> painful.
>>
>
> It isn't clear how getting rid of epochs would prevent crazy versioning.
> You'd have just as much trouble with 1.8-really1.7-again1.8-fooledyou1.7
>

How about introducing an Upstream-Version field? It can go up or down
(forwards or backwards, newer or older) independent of the Debian (package)
version.

ITP
Package foo
Version: 1.0-1

Then a new upload
# error...
Package foo
Version: 2.0-1 (really 1.5)

Current corrections:
Package foo
Version: 1:1.5-1
or
Version 2.0-really1.5-1

Instead use a new field to correct:
Package foo
Version: 2.0-2
Upstream-Version: 1.5-1

debian/changelog
foo (2.0-2 Upstream:1.5-1) unstable; urgency=low

The Depends in the control can then look for Upstream-Version and use that
if it is set and fail back to Version if there is no Upstream-Version.

Just an idea.

-m

Re: Debian part of a version number when epoch is bumped

[Matt Zagrabelny]

On Mon, Feb 5, 2018 at 9:43 AM, Jeremy Bicha  wrote:

>
> The maintainer thinks the 1:1.0.51-12 version number would be "ugly"


The maintainer would not be wrong.

-m

Re: Why do we list individual copyright holders?

[Matt Zagrabelny]

On Tue, Jan 16, 2018 at 10:53 AM, Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:

>
> But I'm a hardy soul who is quite prepared to see a warning and decide
> to ignore it :-).
>
> My view is that the purpose of a warning is to alert you to something,
> so you can decide what to do about it.


What is the difference between "warn" and "info", then?

-m

Re: Call for volunteers: FTP Team

[Matt Zagrabelny]

On Thu, Aug 17, 2017 at 4:02 PM, Jonathan Carter (highvoltage) <
j...@debian.org> wrote:

> On 17/08/2017 20:11, Joerg Jaspert wrote:
> > it has been quite a while since the last call for volunteers, so here is
> > an update: Yeah, we still need people, and we want you. Well, that is,
> > if you are a Debian Developer, for this. If you are not and want to
> > help, read the last paragraph please.
>
> If someone hypothetically joins, are they allowed to rename the FTP team
> to something that doesn't include "FTP"?
>

Archive Team. Or the A-Team for short. The only Debian team with a theme
song.

-m

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  wrote:

> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain can
> > intervene ten years from now.
>
> thankfully tcpdump (and lots of other tools) have nice shell completion.
> tcpdump -i  works great her.
>
>
Agreed. However, I'd still rather deal with names like /dev/sda and eth0
than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.

It is kind of like using people's first names as opposed to their Social
Security Number (in US) or other form of national identification. I know
when I can use the name Matt and I know who it refers to, even if another
Matt enters the room. I'm comfortable with eth0 being the name, even when
another interface appears.

I completely understand, and largely agree with, the need for persistent
naming - but I think we are selling ourselves and our users short by not
pressing harder for network interface aliases. It seems to be too useful of
a solution for this problem.

-m

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Tue, Jul 11, 2017 at 10:12 AM, Samuel Thibault <sthiba...@debian.org>
wrote:

> Matt Zagrabelny, on mar. 11 juil. 2017 09:53:58 -0500, wrote:
> > Relatedly, network device name lengths are limited to the length of
> some
> > arbitrarily-sized struct field in the kernel ABI,
> >
> > Feature request to bump the size of of interface names struct? Any
> reason to
> > not do so?
>
> One reason is that it's already compiled in a lot of applications
> through the IFNAMSIZ and IF_NAMESIZE macros (8155 and 939 results in
> codesearch), so a lot of software would suddently break on interfaces
> with long names until recompiled.
>
>
Thanks for the input.

This particular thread isn't the first time I've heard commentary regarding
the interface name size in the kernel data structure.

I'm not sure what a sensible limit is, but 16 (or 15) seems a little on the
small side. Even Cisco has longer names than the Linux limit:

echo -n "TenGigabitEthernet1/0/24" | wc -c
24

-m




> Samuel
>
>

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Tue, Jul 11, 2017 at 9:18 AM, Simon McVittie  wrote:

> On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote:
> > I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
> > we need it for network devices?
>
> We do have stable names for disks: look in /dev/disk/by-* and you'll see
> a bewildering variety of ways to refer to the same disk or partition.
>
> The thing that is different for network devices is that network
> devices are not files (device nodes), so udev cannot create a symlink
> /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever.
> Network devices are (as far as I know) the only class of device managed by
> udev that is not backed by a device node, which means udev cannot provide
> multiple equivalent names for the same device, and is forced to choose
> exactly one of those names, and rename the device if the chosen name
> is not the kernel-generated one. That is why naming network devices is,
> and has always been, more controversial than naming disks: they are the
> one device class in Linux that violates the Unix design rule-of-thumb
> "everything is a file".
>

Is there any (technical) reason why there isn't a kernel mechanism for an
"alias" for interfaces that is roughly equivalent to symlinks for files?


> If network devices were files, udev wouldn't have a configurable
> NamePolicy to rename them: it would just provide symlinks for all the
> possible naming policies, and let the sysadmin use any, all or none of
> those names when configuring tools like ifupdown. Unfortunately, that
> isn't possible.
>
> Relatedly, network device name lengths are limited to the length of some
> arbitrarily-sized struct field in the kernel ABI,


Feature request to bump the size of of interface names struct? Any reason
to not do so?

I know that kernel solutions to our problems isn't a quick fix, but it
seems that having interface aliases would allow both camps to be happy.

Sorry if the answers to these questions is obvious.

-m

Re: Can we kill net-tools, please?

[Matt Zagrabelny]

On Tue, Dec 27, 2016 at 9:08 PM, Wookey  wrote:
 I am (vaguely) aware of
> something caled 'ip' which does a similar job but have no idea how to
> use it.

Here are the few sub-commands I use regularly. Their abbreviated form
and unabridged form, and the legacy command:

ip a
ip address show
ifconfig -a

ip r
ip route show
route -n

ip n
ip neigh show
arp -n

-m

Re: Bug#830983: ITP: field -- extracts a list of fields from a file

[Matt Zagrabelny]

On Wed, Jul 13, 2016 at 1:14 PM, Lars Wirzenius <l...@liw.fi> wrote:
> On Wed, Jul 13, 2016 at 01:08:25PM -0500, Matt Zagrabelny wrote:
>> Perhaps moreutils?
>>
>> The utilities provided therein are (partially) written in perl. So it
>> is out of place in that regards - but certainly not a show stopping
>> road block.
>>
>> Joey Hess is the maintainer according to:
>>
>> apt-cache show moreutils | grep '^Maintainer:'
>> Maintainer: Joey Hess <jo...@debian.org>
>
> That's obsolete information.

Indeed! :)

I thought I was performing the command on a sid machine, but it was
jessie. Oops!

-m

Re: Bug#830983: ITP: field -- extracts a list of fields from a file

[Matt Zagrabelny]

On Wed, Jul 13, 2016 at 12:50 PM, Trevor Bramwell  wrote:
> On Wed, Jul 13, 2016 at 07:39:32PM +0200, Geert Stappers wrote:

>> Such has having the 'field' codo in an existing Debian package.
>
> If you would be so kind as to point me to the right package this should
> be included in, I'd be happy to discuss it with the maintainer and close
> this bug.

Perhaps moreutils?

The utilities provided therein are (partially) written in perl. So it
is out of place in that regards - but certainly not a show stopping
road block.

Joey Hess is the maintainer according to:

apt-cache show moreutils | grep '^Maintainer:'
Maintainer: Joey Hess 

-m

Re: experimental syslog-ng

[Matt Zagrabelny]

On Fri, Jun 10, 2016 at 2:46 PM, Ansgar Burchardt <"Ansgar
Burchardt"@43-1.org> wrote:

>> At least the following mirrors' Packages.xz file shows the older
>> 3.6.1+git version:
>
> The package failed to build, see [1].

Ahhh. Thanks!

-m

experimental syslog-ng

[Matt Zagrabelny]

Greetings,

It appears that the version of syslog-ng for mirrors of
ftp.us.debian.org's experimental repository is still at version
3.6.1+git20141206-g4d90138-4+b1, while tracker.d.o is reporting that
the experimental version is at 3.7.1-3, and has been since Thu, 08 Oct
2015 21:51:09 +0200.

At least the following mirrors' Packages.xz file shows the older
3.6.1+git version:

64.50.236.52 (OSU)
128.61.240.89 (GATech)
128.30.2.26 (MIT)

Any ideas why this is the case?

Thanks for any feedback!

-m

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Matt Zagrabelny]

On Wed, Jun 8, 2016 at 12:40 PM, Alexander Wirt  wrote:
> On Wed, 08 Jun 2016, Jonathan Dowland wrote:
>
>> On Wed, Jun 08, 2016 at 09:47:56AM +0200, Alexander Wirt wrote:
>> > I am also not very keen on using a system with a "open core / enterprise"
>> > model. For such a crucial service I would really prefer a real open source
>> > system. But maybe I am alone with that oppinion.
>>
>> You are not alone, but please do not call Gitlab CE not "real open source".
> I do for every software which forces me to sign things like:
> https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md
>
> Thats far away from what I call open source. I also don't want to end with
> things like:
>
> Debian needs feature X but it is already in the e.nterprise version. We make
> a patch and for commercial reasons it never gets merged (they already sell it
> in the enterprise version). Which means we will have to fork the software and
> keep those patches forever. Been there done that. For me, that isn't
> acceptable.

That is the nature of free software, though. Any given upstream might
be unwilling to merge some useful patch for whatever reason they
choose. If enough of those patches don't get merged, then a fork may
be likely. This already happens in the FOSS community without any
commercial or proprietary interests.

Given that, I still prefer software that doesn't have a proprietary
licensed "enterprise" version as well as a free software version.

-m

Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space

[Matt Zagrabelny]

On Wed, Feb 24, 2016 at 8:53 AM, Jonathan Dowland  wrote:
> On Wed, Feb 24, 2016 at 03:29:35PM +0100, Jakub Wilk wrote:
>> To avoid unpleasant situations like this, I recommend to never combine roles
>> of upstream and Debian maintainer.
>
> An interesting idea in theory, but it would break down when you consider
> team-maintained packages.

I find the idea interesting, as well. I believe the concept also
breaks down for native, and native-like, packages.

DDs are (perhaps?) the ones most likely to see software needs in the
Debian ecosystem.

Suppose DD-A sees a need and writes useful software DebFoo for Debian.
Would they be permitted to package it, or would DD-B need to package
it?

Food for thought.

-m

Re: init script, installed but not activated

[Matt Zagrabelny]

On Tue, Oct 6, 2015 at 3:16 PM, Antonio Terceiro  wrote:
> On Tue, Oct 06, 2015 at 10:47:28PM +0300, Hleb Valoshka wrote:
>> Hi all.
>>
>> I'm packaging web server for ruby called unicorn. The package installs
>> sysv init script, I want to make it installed but not activated
>> because unicorn itself is useless, user should configure it and
>> activate it with "update-rc.d unicorn enable". Or it may installed as
>> dependency for rainbows, so it's clear that it should not run.
>>
>> So I need something like "dh_systemd_enable --no-enable", existing
>> options for dh_installinit like "--no-start" or
>> "--update-rcd-params=..." does not work such way, so we need to
>> introduce workarounds in postinstall script.
>>
>> Any suggestions?
>
> for sysvinit you need to code that manually in the initscript. several
> packages have their initscripts source /etc/default/$package, and check
> for some variable that says whether the service should start on boot or
> not.

I believe that practice is now frowned upon since update-rc.d has a
disable verb.

-m

Re: aptitude has Priority: standard, why?

[Matt Zagrabelny]

On Tue, Mar 31, 2015 at 9:32 AM, The Wanderer wande...@fastmail.fm wrote:

 Repeatedly over the years - I'd almost say consistently - I've seen
 aptitude report that a requested package change (install, remove, or
 some combination) would result in an invalid or conflicting dependency
 situation, and suggest a solution which involves _not making the change
 which was requested_.

 If the requested configuration is, in fact, contradictory, then this is
 of course reasonable. However, in most if not all such cases, requesting
 the same change of apt-get produces a workable dependency solution
 immediately.

 Sometimes (when I've bothered to stick with it long enough), telling
 aptitude no, try again a few dozen times (and rejecting solutions
 which would downgrade or remove dozens, if not hundreds, of packages
 along the way) will eventually get it to suggest a solution which will
 make that change without extraneous side effects - which may or may not
 be the same as the one provided by apt-get.

 But as long as aptitude continues to take this brain-dead approach to
 dependency resolution, necessitating digging through obviously-bad
 suggestions before finding something as reasonable as what apt-get
 provides easily, it is IMO not viable for actual use - except perhaps by
 people who already know completely what they are doing and how to
 override aptitude's suggestions.

I've grepped debian-devel, but cannot find an email that was sent to
the list some months ago about tweaks to /etc/apt/apt.conf (IIRC) to
make aptitude behave more sanely.

Thus, I believe there are a couple of knobs to turn to make aptitude
behave more expectedly.

Cheers,

-m


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caolfk3vm0kzvee-bypj6yjaqfwp-ma5ybn1k7y1w-cbev1c...@mail.gmail.com

Re: Being part of a community and behaving

[Matt Zagrabelny]

Hi Pat,

On Thu, Nov 13, 2014 at 4:25 PM, Patrick Ouellette poue...@debian.org wrote:
 On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote:

  For the record, I really don't care about the init system per-say.  I am
  more annoyed with the systemd insistence on logging to binary files than
  anything.  Log files should be plain text.

That's a loaded statement.

 Rsyslog is srill installed by default (and I guess that won't change
 soon), so you now have even better textlogs.

 I did not ask for evangelization about how wonderful binary logs are,
 nor for a lesson on how to get the info out of systemd with the
 systemctl command.

You shouldn't be surprised that there is dialogue surrounding it.

-m


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOLfK3XTG3ZT-AQHaem+kbsS7OueuCiSwgYZoYt+T=2qpgdB=g...@mail.gmail.com

Re: ITNMU nfdump

[Matt Zagrabelny]

On Mon, Oct 13, 2014 at 2:27 PM, Jaakko Niemi jaakko.ni...@iki.fi wrote:
 Hello,

 I'm planning to NMU nfdump, and have been unable to contact the maintainer
 (his
 MTA says I'm a spammer). Has anyone else been in contact with Erik lately?

I packaged up nfsen a while ago (maybe 16 months) and asked Erik about
sponsoring it. He replied with some feedback for the package, but that
was the last of our email exchange.

 On longer term, I'm planning to adopt the package,

Super!

-m


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caolfk3whzbm_pi0fomx6pzy1wrflaqjrkb3_tgbeykys2pz...@mail.gmail.com

Re: daemon user naming scheme

[Matt Zagrabelny]

On Tue, Aug 26, 2014 at 12:10 PM, Matthias Urlichs matth...@urlichs.de wrote:

 adduser tango --uid $UID --gid $GID

typo?

adduser _tango --uid $UID --gid $GID

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caolfk3x04x2iv0rzd9e5zpjwtpepgdtp++nj6mwm9zhnoma...@mail.gmail.com

Re: Let's shrink Packages.xz

[Matt Zagrabelny]

On Fri, Jul 25, 2014 at 6:50 AM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:

 Reducing the size of Packages.xz by 11% or 22% would leave room for quite
 a lot of small packages while not making the problem any worse than it is
 today.

 But the problem with lots of small packages is not that the
 Packages.xz has too many bytes.

 It's that the packaging tools, UIs (for users and developers), and
 humans, need to think about too many packages.

 This makes packaging tools slow, UIs cluttered, and humans confused.

What is too many packages?

It seems that the UI would need to be able to handle an arbitrary
number of packages. There have been many thousands of packages since
Woody/Sarge.

-m


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caolfk3xaxcftk57cd-qcudwnl1xwr84ebuougg_9qagqto0...@mail.gmail.com

Re: Idea for apt-get : getting source code instead getting binaries

[Matt Zagrabelny]

On Thu, Mar 6, 2014 at 9:33 AM, Solal Rastier solal.rast...@me.com wrote:
 Hello! I've an idea for a new apt-get package style :

 Developer side :
 -The developer create a ./install script in the source code.
 -The install script executes all commands necessary for install the software. 
 Also, it getting dependancies, etc.
 -The developer create a tarball (.tar.bzip2) and rename the file name. 
 Instead of software.tar.bzip2 , that's software.deb
 -The developer distribute the software.deb

 Apt-get side :
 -The apt-get tool download software.deb from the Debian repository.
 -The program is installed with dpkg

 Dpkg side :
 -dpkg rename the software.deb software.tar.bzip2
 -tar uncompress the software.tar.bzip2
 -cd go into the software folder
 -./install execute install script

Maybe I'm missing something:

apt-get source foo
apt-get build-dep foo

Do those commands do what you are needing?

-m


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caolfk3x-kesuqo+ozbeuu5ddbng9fxgaw1az5dadgo4vb9j...@mail.gmail.com

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

[Matt Zagrabelny]

On Thu, Feb 13, 2014 at 12:31 PM, Holger Levsen hol...@layer-acht.org wrote:
 Hi,

 On Donnerstag, 13. Februar 2014, Jakub Wilk wrote:
 https://en.wiktionary.org/wiki/poor_man%27s

 I knew that :) I still don't think it's appropriate nor helpful to describe
 software with these attributes. (Hints: free software is always free as in
 gratis, and men, well, men^wmeh.)

Packager is using upstream description. From their website,
https://github.com/np1/mps

   Poor Man's Spotify - Search and stream music

In English, the phrase doesn't carry a negative connotation. It is a
clever way to replace something expensive with something less
expensive.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3UKj9cpRywnvAFRopNL3QmdoUwJfqqiMRSegqgAyFFQ=q...@mail.gmail.com

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

[Matt Zagrabelny]

On Wed, Feb 12, 2014 at 1:02 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 On Wed, 12 Feb 2014 11:25:14 -0500
 Paul Tagliamonte wrote:

  If they have decided on systemd as default [...]

 https://lists.debian.org/debian-devel-announce/2014/02/msg5.html

 Can we please end this thread?

 Sure but perhaps you could save me the trouble to say if there is a
 general outline of the factors that the decision made was based upon
 perhaops somewhere in the ctte mailing list archive. Or a round up
 published before voting.

 Don't tell me it was just a vote with licensing issues being taken by
 many over real issues as some sites seem to be saying. Do voters give
 their primary reasons?

Kevin,

This is what I found. Hopefully it is useful.

Russ' reasoning:
https://lists.debian.org/debian-ctte/2013/12/msg00234.html

Colin's reasoning:
https://lists.debian.org/debian-ctte/2013/12/msg00296.html

Ian's reasoning:
https://lists.debian.org/debian-ctte/2013/12/msg00182.html

Bdale's reasoning:
https://lists.debian.org/debian-ctte/2014/01/msg00067.html

Digging through the mailing list archives to find the remaining CTTE
member's reasoning is left as an exercise to the reader. :)

-mz

PS. I'm looking forward to this thread ending - sorry for adding to it!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3w2x+zz+o8ykfpif4d1vsvurl4dqyrndfzsaxkpyu7...@mail.gmail.com

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

[Matt Zagrabelny]

On Tue, Feb 11, 2014 at 10:26 AM, Matthias Urlichs sm...@smurf.noris.de wrote:
 Hi,

 vita...@yourcmc.ru:
 Because I want logs to be plaintext in my system, not binary.

 Why? (Seriously.)

To use standard text based tools, eg. grep.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3X6Zpz=ysi8-yxypgdohohqfxevt2zhrasd9uaw5tv...@mail.gmail.com

Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]

[Matt Zagrabelny]

On Tue, Dec 31, 2013 at 8:54 AM, Clint Adams cl...@debian.org wrote:
 On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote:
 Apart from the termination clause, the GPLv2 is far more concise,
 I don't see tivoization as a problem (it's the software I want to
 protect, not anyone's combination of it with hardware), nor do I care
 about compatibility with Apache 2.0 -- I do, however, care about
 compatibility with GPL v2, which GPL v3 isn't.

 So your doomsday scenario is that if you license something
 GPLv2+, someone might fork and modify it to be GPLv3+,

I was under the impression that forks couldn't change licenses. Is the
scenario which Clint describes (legally) possible?

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3uoxx+f0_ca9lwe-n6p50y-cb4gs683w6cvfqvydw4...@mail.gmail.com

Re: Proposal: let’s have a GR about the init system

[Matt Zagrabelny]

On Fri, Oct 25, 2013 at 10:45 AM, Thomas Goirand z...@debian.org wrote:
 On 10/25/2013 11:02 PM, Thorsten Glaser wrote:
 Supporting two different init systems is something I don't think
 *anyone* wants to get into. Remember they use different files, so this

 Erm, we already support sysv-rc, file-rc, systemd, upstart…
 so my favourite GR outcome would just say that Debian fully
 commits to continue doing that.

 Plus if we choose Upstart or Systemd, then that's effectively what we
 are going to do (I mean, we'd have to support 2 init systems, because of
 Hurd  kFreeBSD).

popcon.debian.org has some data about the usage of said architectures/kernels:

amd64: 92600
i386: 63099
hurd-i386: 25
kfreebsd-amd64: 68
kfreebsd-i386: 53

Holding up development of our Linux architecture for the 0.1% isn't
serving the majority of Debian's users well. I know popcon isn't
perfect, but its margin of error is acceptable for talking about the
gross disparity in number of users between Linux and Hurd/kFreeBSD.

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3V_E=+l6fy6k7qseze6n_faacwskse1q1lct8_hxc2...@mail.gmail.com

Re: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Matt Zagrabelny]

On Tue, Jul 30, 2013 at 3:57 PM, Russ Allbery r...@debian.org wrote:
 Christoph Anton Mitterer cales...@scientia.net writes:

 - The system hostname (and domainname if any) should ALWAYS be
 resolvable, whether a network is up or not, regardless of which.
 (Assuming that lo is always up, if not, many things break anyway.)

 This principal (and the general UNIX tradition of putting the local host
 and IP address in /etc/hosts) has caused us no end of problems, since that
 information inevitably gets out of date when systems are moved around or
 re-IP'd.  We now do not put the local hostname anywhere in /etc/hosts, and
 I believe that's the correct configuration for any system with stable DNS
 and network.

Russ,

Does not the Wheezy installer still place hostname.domain.name entries
in /etc/hosts for said hostname?

Or do you mean some entity other than Debian when you say, we, or is
now after the Wheezy release?

Cheers,

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3vaz9x-xz4mruhmb_q6sjbndzgx7kedkownhvklhmq...@mail.gmail.com

Re: Debian naming scheme

[Matt Zagrabelny]

On Mon, Jun 17, 2013 at 12:59 PM, Nikolas Kallis n...@nikolaskallis.com wrote:
 Hello,



 I think Debian should stop releasing products as I.E 'Debian 7.0', and
 instead release them simply as I.E 'Debian 7', where its Debian version
 would be 7.0.

 It makes it hard for me writing documentation for applications that run on
 Debian when I have to write it supports I.E 'Debian (7.0, 7.1)'.

Could your documentation state, 'Debian 7.X' ?

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3WHo+Wr=lzbumlcb1wpicxtuuzksft2spdg331cdwk...@mail.gmail.com

Re: Debian systemd survey

[Matt Zagrabelny]

On Wed, May 22, 2013 at 3:30 PM, Russ Allbery r...@debian.org wrote:
 Martin Wuertele m...@debian.org writes:

 Seems like you haven't realised yet: only if a maintainer makes
 controversal decisions and several others disagree such a case comes
 before the CTTE.

 Having decisions appealed to the CTTE is not a punishment.  It just
 indicates that a decision is controversial and the project was unable to
 reach a consensus.  It's not always possible (and indeed not always wise)
 to avoid controversial decisions.

 Having choices ending up twice within relatively short time before the
 CTTE should give the maintainer a hint.

 It is, for example, probably a hint that the maintainer is working on
 something important that a lot of people care deeply about and therefore
 have strong opinions about.

Well said.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3wxeoscjz06nkqg1qtompftkegp3sb05tz5onng5en...@mail.gmail.com

epoch fix?

[Matt Zagrabelny]

Hello world,

I've grepped the d-d list, but didn't find any threads regarding
fixing epochs in package versions.

First, is there a consensus or quorum that believes that unnecessary
epochs is undesirable?

If so, could we add a field to debian/control such as
Supersede-Epoch. If set to 'yes', then dpkg considers this package
to have an epoch of infinity for version comparisons. After the next
stable is released with this version of the package, then the
maintainer could remove the control line Supersede-Epoch so that
epochs and dpkg behave as before.

Comments appreciated.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3xkblw0plu2g0ytmtj7rpnejobs3xwh25dbm0p+atg...@mail.gmail.com

Re: epoch fix?

[Matt Zagrabelny]

On Tue, May 7, 2013 at 5:08 PM, Noel David Torres Taño
env...@rolamasao.org wrote:
 On Martes, 7 de mayo de 2013 22:55:39 Matt Zagrabelny wrote:

 If so, could we add a field to debian/control such as
 Supersede-Epoch. If set to 'yes', then dpkg considers this package
 to have an epoch of infinity for version comparisons. After the next
 stable is released with this version of the package, then the
 maintainer could remove the control line Supersede-Epoch so that
 epochs and dpkg behave as before.


 What if between the time you supersede in unstable and it disappears with
 oldstable (several years after) you need again to create an epoch?

Use the mechanism of really:

% apt-cache policy libglib2.0-dev
libglib2.0-dev:
  Installed: 2.33.12+really2.32.4-5
  Candidate: 2.33.12+really2.32.4-5
  Version table:
 2.36.1-1 0
  1 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages
 *** 2.33.12+really2.32.4-5 0
500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages
500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages
500 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3XWHp4VcQWH_kcQUpFXtpgoDkcFEUC+wV4y=g1vra9...@mail.gmail.com

Re: epoch fix?

[Matt Zagrabelny]

On Tue, May 7, 2013 at 5:19 PM, Thorsten Glaser t...@debian.org wrote:
 Matt Zagrabelny mzagrabe at d.umn.edu writes:

 Use the mechanism of really:

 That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
 *much* *much* *much* *much* *much* *much* *much* more ugly than epochs
 and actually a prime example of why we *want* them.

epochs never go away - AIUI. They detract from meaningful information
in the version string.

I am not a proponent of +really - I agree that they are ugly, but
they do go away. I wanted to suggest a mechanism for working around
unnecessary epochs.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3VqiQ7A=fzmcydqpy8oumq3tft6f7yu1nxkp3mg7hq...@mail.gmail.com

Re: Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser

[Matt Zagrabelny]

On Mon, Apr 8, 2013 at 2:29 PM, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
 On 04/08/2013 09:23 PM, David Prévot wrote:

 The purpose would be to provide it, via a libjs-ie7, in order to be used
 as a third party in other packages like spip. As such, I intend to
 maintain it under the Debian Javascript umbrella.


 And how would I use it on Debian when there is no Internet Explorer 7
 available for non-Windows platforms? Wine?

I believe the HTTP server serves the .js to all clients (including
IE7.) In other words, this is a server solution for badly behaving
clients.

Correct me if I am wrong.

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3WJtiDDvthFo+5o-Xd6yBuwxd5d7X2HofROoFqrKQM=e...@mail.gmail.com

Re: Debian logo svg file is not loadable in Inkscape

[Matt Zagrabelny]

On Thu, Jan 24, 2013 at 9:51 AM, Christoph Anton Mitterer
cales...@scientia.net wrote:
 On Thu, 2013-01-24 at 16:35 +0100, Filippo Rusconi wrote:
 fails to load in the much-respected SVG-based graphics editor Inkscape
 (which I use daily and which works fine also for svg files not
 produced by itself).
 In mine it loads, version 0.48.3.1-1.3.

Curious. I am using the same version (0.48.3.1-1.3) and get the
specified failure in the original post.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3xaumqe0eiq_0tfy5ryd0tsz6j8h_dgfrcg_oawyvt...@mail.gmail.com

Re: GFDL in main

[Matt Zagrabelny]

On Wed, Dec 12, 2012 at 3:48 AM, Jakub Wilk jw...@debian.org wrote:
 * Serafeim Zanikolas s...@debian.org, 2012-12-12, 10:30:

 If I understand correctly, the way to go is to split every problematic
 source package in two different source packages, one for main (shipping
 programs) and another for non-free (shipping documentation), with the main
 package suggesting the non-free one.


 First one should ask upstream if they are willing to relicense the
 documentation. If they are not, then removing the documentation or moving it
 into a non-free package is the only option left.

A point of clarification: Relicensing can include an additional
license, thus making the documentation dual (or multi) licensed.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3U=7Vkhudr5JDWahH_sBCjz9C=kvpzo_mqnqfds8ko...@mail.gmail.com

Re: Ubuntu have done it again,

[Matt Zagrabelny]

On Fri, Dec 7, 2012 at 5:21 PM, Steve Langasek vor...@debian.org wrote:
 On Sat, Dec 08, 2012 at 12:09:10AM +0100, Svante Signell wrote:
 this time installing surveillance code.

 http://linux.slashdot.org/story/12/12/07/1527225/rms-speaks-out-against-ubuntu
 http://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do

 Any reason Debian should be so closely linked to Ubuntu?

 Curses!  My plan to make Debian's default init system phone home has been
 foiled!

It was probably those meddling kids and their dog.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3vqnqchir5_roxmijhxbntwc7wo-ftos_q66uo0wz6...@mail.gmail.com

Re: debian mate

[Matt Zagrabelny]

Hi Michael,

On Tue, Nov 20, 2012 at 9:03 PM, Michael Schmitt tcwardr...@gmail.com wrote:
 Am 20.11.2012 23:14, schrieb Carlos Alberto Lopez Perez:

 On 20/11/12 22:55, Michael Schmitt wrote:

 If one likes Gnome2.x or MATE or not is a question of taste, to
 acknowledge that many users are just mad about Gnome3 is a fact. To
 offer no real sane upgrade-path for those users is... dunno how to say
 it in another way, it is just insane! I did invest some time with
 thinking about all of this including talking to some MATE folks and
 current squeeze-gnome-users, and again thinking and thinking... imho it
 must be done everything possible to try to circumvent that imho probable
 desaster for the desktop users. Especially when I think of the real
 *average next door users* not the techie guys who may be happy (or at
 least not cry to loud about it) to invest some time tweaking their Xfce
 or KDE to behave more or less like their old gnome2 did. And if you
 really insist, I can give you detailed reports about what kind of
 problems those users have with the current DEs in Debian including
 gnome3, but I don't want to bloat this mail anymore. I just can
 guarantee you now, the panel in gnome3-fallback being black is not one
 of them. ;)

  From my point of view, as said I can't comment much on the technical
 aspects here. I can just ask those who may have the ability to do so, to
 do it in a fair way, with as less prejudice as possible. Again, for the
 users that will have an issue with the current envisioned upgrade-path.
 For those users not so keen about adding a third-party repo to their
 sources.list, those users not knowing about the possibility to do so,
 those users that will get pissed.

 regards
 Michael

 P.S.: I know there is already work in progress for MATE for jessie, I
 just think that is too late. But I don't want to trip on anyones toes
 here

 AFAIK is completely impossible that Debian ships MATE for Wheezy. Wheezy
 has been frozen time ago and by policy no new packages are allowed in
 the archive for testing during the freeze.

 So much for the general rules... but exceptions ARE possible! And I just try
 to make a case here about how important it might be!


 If you want a classical desktop your main options are: gnome3-classic,
 XFCE and LXDE. You have also cinnamon on sid (it won't make to wheezy)

 It is *not* about me and I know already all available options in all
 possible flavors and directions available as of today for wheezy.

I'm guessing that by the time wheezy is released MATE will be in
unstable and the wheezy-backports won't be far behind. It is a
sensible compromise.

Remember, Debian is more that just a Desktop operating system. Let's
work within policy and be respectful to those who are working hard to
get the release ready.

Cheers,

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3xq2cntrywk1lgjslglrhxv1yrfrbshoahrn3lprr_...@mail.gmail.com

Re: Help me DTRT with upstream naming

[Matt Zagrabelny]

On Fri, Sep 7, 2012 at 8:33 PM, The Fungi fu...@yuggoth.org wrote:
 On 2012-09-07 16:40:07 -0700 (-0700), Russ Allbery wrote:
 [...]
 The problem is that the software is called wallet, both the
 software itself and the primary client binary that users invoke.
 [...] I don't think there's another UNIX/Linux binary of that
 name.  But, of course, it's still not a very unique name. [...]
 (see the recent node discussion), but on the other hand it's going
 to be a big pain for me and for users
 [...]

 Frequently invoked console/text utilities have a good excuse for
 taking up short, easily typed and easily remembered words in the
 executable path namespace. That strikes me as the real reason to
 avoid having programs commonly launched from a GUI icon of some sort
 polluting that namespace--they aren't frequently called from the
 CLI.

 If your users are used to entering wallet blah and there's no
 wallet command in another package already, I'd be in favor of
 leaving it as is. Spending most of my life in a CLI, I'm not at all
 fond of typing one mile-long-hyphenated-command-name after another.

That is what tab completion is for.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3xy+4tk9aya89rezateq0bqsnyxckk92g3sx0gsqpc...@mail.gmail.com

Re: tasksel: Default desktop: Gnome→Xfce

[Matt Zagrabelny]

On Fri, Aug 3, 2012 at 4:52 PM, Arno Töll a...@debian.org wrote:
 Hi,

 On 03.08.2012 23:28, Michael Biebl wrote:
 Seriously, I'd just drop our CD1 installs and only provide a net-install
 image and a DVD image for desktop installations.

 Is there any serious survey how established DVD drives (and writers) are
 these days? CD images might be obsolete some day, but we should be sure
 (virtually) nobody notices once we drop it.

I don't know about serious surveys, but flash drives are ubiquitous
and have large storage. Some (many?) laptops don't have optical drives
either. For D-I, I would pick the most common USB flash drive size
(perhaps 2.0 GB) and target that.

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3u2er-v1xcyuzptmjskn_amiikcpa_kmgbfjnbp4mf...@mail.gmail.com

Re: Have NetworkManager disabled by default when...

[Matt Zagrabelny]

On Wed, Jul 18, 2012 at 3:46 PM, Michael Biebl bi...@debian.org wrote:
 On 18.07.2012 22:32, Wookey wrote:

 wicd is easy to disable as it has a ENABLE/DISABLE option in
 /etc/defaults. N-M doesn't so you either have to remove it properly or
 resort to nobbling the init script.

 Nope, you don't have to nobble the init script.
  Use update-rc.d network-manager disable.
 That's the proper interface to disable sysv services from starting.
 Those /etc/defaults ENABLE switches are a hack

 Why are people not a aware of that update-rc.d interface? Is this a
 general documentation problem?

I've been under the impression that future upgrades to the package
would re-enable the symlinks whereas /etc/default is not touched by
upgrades.

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3W3F=-kwd5mdn-a03ulai3rk8trggx-op7bh2g0jyr...@mail.gmail.com

Re: Packaging entirely via git

[Matt Zagrabelny]

On Tue, Jun 12, 2012 at 2:48 PM, Luis Alejandro Martínez Faneyth
l...@huntingbears.com.ve wrote:
 El 12/06/12 12:40, Enrico Weigelt escribió:

 Hi folks,


 is there already a way for maintaining debian packages entirely
 with git - without the orig tarball ?

I use something like this in the gbp.conf:

[DEFAULT]
builder = /home/mzagrabe/bin/git-pdebuild
upstream-branch = master
debian-branch   = debian
upstream-tag= v%(version)s

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3v28jvwwcen57+ouszs4mcdhdurgzu7ifun2jxg+1z...@mail.gmail.com

Re: Node.js and it's future in debian

[Matt Zagrabelny]

On Thu, May 3, 2012 at 12:35 PM, Patrick Ouellette poue...@debian.org wrote:
 On Thu, May 03, 2012 at 01:10:24PM +0200, Vincent Bernat wrote:

 As said many times, node is an interpreter used in shebang. Using a
 different name would just upset its user base. Debian will be seen,
 again, as the one harming a community, like this may happen in the
 Ruby community because of lack of understanding on how we work.
 Outside of Debian, nobody will understand why a package related to
 HAM radio hinders the use of one of the trendiest package (in the
 top 5 of most watched and forked repository in GitHub).

 So every time something is the hot new trend it has the right to usurp
 an established package's binary namespace?  I'm not asking this to be
 argumentative, I really want to know if this is your intention.

Not speaking for Vincent, here is my take:

A namespace is something that is distinctive and specific. Node is
neither. As it stands, it is foolish for both projects to use such
name(s).

All that being said, it would be nice to come to a good (or the
best possible) solution. Those are subjective terms and that is why
the arguments are revolving around popularity, ease of transitions,
and the best interests for (the majority of) Debian's users.

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3X=suoOLi-6gR=godx1fh8m8qdc3vuh7yxd7kdrakh...@mail.gmail.com

Bug#666961: ITP: milter-regex -- sendmail milter plugin for regular expression filtering

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny mzagr...@d.umn.edu

* Package name: milter-regex
  Version : 1.9
  Upstream Author : Daniel Hartmeier dan...@benzedrine.cx
* URL : http://www.benzedrine.cx/milter-regex.html
* License : BSD
  Programming Lang: C
  Description : sendmail milter plugin for regular expression filtering

The milter-regex plugin can be used with the milter API of sendmail(8)
to filter mails using regular expressions matching SMTP envelope
parameters and mail headers and body.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120402211057.28334.66276.report...@achilles.d.umn.edu

Re: On init in Debian

[Matt Zagrabelny]

On Fri, Mar 23, 2012 at 9:39 AM, Ritesh Raj Sarraf r...@researchut.com wrote:

 Today, on my typical laptop, boot is not the most important task. It
 is better to have something well working, fixable (being mere shell
 scripts and that's what your friend is also pointing). sysvinit serves
 this purpose well.

booting is just one of the things systemd/upstart changes.

I was working with a daemon yesterday (conserver-server, FWIW) and I performed:

invoke-rc.d conserver-server restart

This did not *successfully* restart the daemon. The daemon spawned
some ssh tunnels. These were forked off and had a parent PID of 1, did
not terminate, and caused a the daemon to not start correctly. It is
my understanding that systemd (not sure about upstart) would correctly
handle scenarios like this (by using cgroups.)

Switching gears...

If systemd becomes as widespread as pulseaudio (is becoming), we may
not have much of a choice about using it or not using it. If a
critical mass of upstreams use it, we will be somewhat forced to use
it. In 3-5 years instead of talking about sysvinit replacements and
the mechanics involved, we will be talking about how to retrofit our
packages to work around (or without) systemd.

Cheers,

-matt zagrabelny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3wjmrcomksb4quq5w7fuqmlbx08+++nafebxyjkgcp...@mail.gmail.com

Re: NM without X (general: users vs developers)

[Matt Zagrabelny]

On Fri, Mar 23, 2012 at 5:49 PM, Svante Signell
svante.sign...@telia.com wrote:
 On Fri, 2012-03-23 at 22:29 +, Jon Dowland wrote:
 This is completely off-topic for -devel. Please take it to debian-user
 if you want to continue.

 No it is not, this is as important as the systemd/upstart/sysvint\
 issue, now being discussed on Debian devel. The general question is:
 How much tolerance do we as users have towards the developers lack of
 listening to their users, not their own Freud happiness.  As an
 example: How much has gnome3 contributed to _users_ experiences, I'm
 using the fall-back solution, due to lack of alternatives right now.

I don't contribute as much as I'd like to Debian and thus my view of
d-devel might be wrong, but this mailing list is for developers who
need to communicate with developers. Not a place for users to air
their grievances. If you have coding solutions, please offer them or
if you need development advice, then ask. Otherwise, no one is
soliciting opinions about NM or gnome3.

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3UKjm65Dtcje=wsv0bkj+uuhp_tuo14eh0r5ecrtdr...@mail.gmail.com

Re: Unofficial repositories on 'debian' domains

[Matt Zagrabelny]

On Mon, Mar 5, 2012 at 9:45 AM, Reinhard Tartler siret...@gmail.com wrote:
 On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic m...@arvanta.net wrote:
 For me d-m.o was (and still is) valuable resource.
 Some codecs missing in Debian packages because of the policy (I don't
 blame Debian for that) and in that case d-m.o is best option for me
 because I don't want/have time to package it from the source.

 Out of curiousity, what codecs do you miss in the official debian packages?

libdvdcss2

This may have been mentioned elsewhere in this thread, but a wiki page
under wiki.debian.org instructs users to use d-m.o as a repository to
get various codecs.

http://wiki.debian.org/MultimediaCodecs

Obviously wikis need to be taken with a grain of salt, but anything
(including wiki.d.o) under the debian.org domain feels somewhat
official and can lead users without the requisite knowledge to heed
said advice. If there are users out there who can distill their
knowledge regarding codecs and improve the wiki page, then that would
be much appreciated.

Thanks!

-matt zagrabelny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3xqxeg-zjzcekbmo3mbto-9cqyscpmuevzfkq-rwza...@mail.gmail.com

Re: Unofficial repositories on 'debian' domains

[Matt Zagrabelny]

On Mon, Mar 5, 2012 at 11:55 AM, Reinhard Tartler siret...@gmail.com wrote:
 On Mon, Mar 5, 2012 at 6:32 PM, Matt Zagrabelny mzagr...@d.umn.edu wrote:
 On Mon, Mar 5, 2012 at 9:45 AM, Reinhard Tartler siret...@gmail.com wrote:
 On Mon, Mar 5, 2012 at 11:52 AM, Milan P. Stanic m...@arvanta.net wrote:
 For me d-m.o was (and still is) valuable resource.
 Some codecs missing in Debian packages because of the policy (I don't
 blame Debian for that) and in that case d-m.o is best option for me
 because I don't want/have time to package it from the source.

 Out of curiousity, what codecs do you miss in the official debian packages?

 libdvdcss2

 This is not a codec but a software package that cracks an encryption
 algorithm. It has been packaged for debian proper, uploaded and got
 rejected by ftp-master. BTW, the reason did not involve patents,
 AFAIUI.

I understand that it is not a codec. ;)

Nevertheless, it is a package that I find myself installing on just
about any workstation with a DVD drive.

 As an alternative source, the libdvdread3 package used to ship a
 /usr/share/doc/libdvdread3/install-css.sh script, which fetched a
 libdvdcss2 packages from debian-unofficial.org. From a packaging and
 maintenance POV, that package is in a much better state. Too bad that
 the libdvdread maintainer removed that really handy script.

What then is the recommended way of installing a the decryption
library for DVD/CSS?

I mean, from what I've read in this thread, d-m.o is not cooperative
with d.o regarding packages, what is the recommended way of installing
that libdvdcss2?

Cheers,

-mz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3wwy8k2agk-y307zbncroydamxitmpe_576s_nd8me...@mail.gmail.com

Re: upstart: please update to latest upstream version

[Matt Zagrabelny]

On Tue, Feb 28, 2012 at 12:22 PM, Russ Allbery r...@debian.org wrote:

 I, for one, have even more of a problem
 contributing to FSF projects that require copyright assignment than I
 would contributing to upstart.

Hi Russ,

Would you comment on why you have issues with the FSF contributor agreement?

Thanks,

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3Uoxi069Q=rhh5qbbfcjnal5on9f1eg_jtzjuvovb5...@mail.gmail.com

Re: Bug#655230: ITP: pushkey -- ITP: pushkey - Pushes your ssh key to a remote location. It tries to create a .ssh folder remotley then it adds your ssh key to authorized_keys.

[Matt Zagrabelny]

Hi Al,

On Mon, Jan 9, 2012 at 7:12 PM, Al abihe...@gmail.com wrote:
 OK I guess I am partially incorrect, however if .ssh or authorized_keys is
 wrong permission, ssh-copy-id doesn't fix it..
 I set .ssh folder to 777 and ssh-copy-id did not change it.

That is the sane behavior here.

The utilities that come in the openssh-client package do not set .ssh
to 777, they set it to 600, hence if it is set to 777, then someone
*manually* did that. That person should then manually fix it. It would
be illogical for some other program to fix the perms. A manual
correction is the proper place for it. Also, pushkey is doing more
than what it name implies. The name implies that a key would get
pushed, however:

1) a key gets created
2) it gets pushed
3) directory mode is changed

I wouldn't expect, nor want, 3 and possibly 1.


devil's advocate

I don't think anyone is going to:

apt-get install pushkey

When there is already a tool to copy keys around. I know that push key
will generate a key, but that goes against the grain of the UNIX
philosophy of having tools do one job and do it well.

It seems best to stick with:

ssh-keygen (once in a great while)
ssh-copy-id system (whenever you need to ssh to a new system)

I don't think anyone will advocate for pushkey, it seems rather unnecessary.

/devil's advocate


Respectfully,

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3u8tkbk2nfsy-joqeb-n5ehw0jztsv9pq0ugr7_++v...@mail.gmail.com

Re: Move all to /usr

[Matt Zagrabelny]

On Tue, Oct 11, 2011 at 11:09 AM, Ivan Shmakov i...@gray.siamics.net wrote:

        Saving a dozen of bytes in ${PATH} doesn't seem like an
        astonishing idea, anyway.  What's the point, then?

There are good arguments in the following link (Marco provided it with
his initial email.)

https://fedoraproject.org/wiki/Features/UsrMove

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3VOVgfKeRb=0vs3rzbbticnb5lszkyprpzog9eocdc...@mail.gmail.com

Re: alternative dependency ordering - with respect of packages in main

[Matt Zagrabelny]

Hi Bruce,

  I hope Debian would honour the Social Contract and put the needs of the
  users ahead of software freeness concerns in that case.

 Do we have a name for the DFSG equivalent of Godwin's Law?  Because you
 just failed it.

 Well, that's disappointing... called a Nazi for daring to explore the
 possibilities. sigh

I think you misread what Steve was saying. When you were calling out
those who are concerned about software free-ness, you were calling
them Nazis. Steve was not calling you a Nazi.

Anyhow...

If we don't have software free-ness, we don't really have much of a
social contract.

-mz


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caolfk3wimovdqj7bryziw5jix1cs+bezebs-rbydqzbv+py...@mail.gmail.com

Re: simple Debian package information in the wiki

[Matt Zagrabelny]

On Wed, Aug 31, 2011 at 10:03 AM, Gergely Nagy alger...@balabit.hu wrote:
 Henri Le Foll li...@lefoll.eu writes:

 http://wiki.debian.org/Packaging/Minimal (for empty packages)
 http://wiki.debian.org/Packaging/Trivial (for a pdf file)

 http://wiki.debian.org/Packaging

 I am interested to have feed back on it

 I maintain my view that to learn packaging, the best way to do that is
 to start from scratch - there are no unknown black boxes there one does
 not understand

The book The Debian System, by Martin Krafft, has a nice chapter or
two about packaging (bottom up learning, as you describe, Gergely.)

Unfortunately, it does not look like there is a free electronic
version available.

-Matt Zagrabelny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOLfK3WLLX7O98ygmS3tGT=j0ots6gdslqfqrnuzm_02au0...@mail.gmail.com

Re: Source format 3.0 (git) ?

[Matt Zagrabelny]

On Mon, May 30, 2011 at 6:27 PM, Charles Plessy ple...@debian.org wrote:
 Hello everybody,

 in echo to Raphaël's question about the use of a VCS together with the 3.0
 (quilt) format, I was just wondering, what is needed to have 3.0 (git)
 acceptable in Debian, and how can we solve this ?

IIRC, there was a BOF regarding 3.0 (git) at Debconf 10.

It seemed there was some concern regarding the ftp-masters and how
deep to make the git revisions.

Russ Allbery took notes in the meeting:

http://lists.debian.org/debian-devel/2010/08/msg00244.html

-matt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktiktqm+j5-pm3c7y-309d6qzve1...@mail.gmail.com

Re: How to become a contributor?

[Matt Zagrabelny]

On Thu, May 19, 2011 at 4:36 PM, Svante Signell
svante.sign...@telia.com wrote:
 Hi,

 I've been a GNU/Debian user for a long time now, after trying out
 Redhat, Mandrake, Suse, Mandriva, Debian, etc. Now, I'm stuck at Debian,
 which I find the best distribution not limited  to GNU/Linux.

 I would like to contribute more than just being a passive reader of the
 email lists and submitting bugs. How to proceed, I would like to start
 to adopt package(s) no longer being maintained actively, not adopt
 abandoned ones. As a start, I would need a sponsor to do the upload. How
 to proceed?

google:

debian mentors

also see:

http://www.debian.org/devel/wnpp/

-matt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktim+dgpvt7hk6tzo9gexn1cjexy...@mail.gmail.com

Accepted cdpr 2.4-1 (source i386)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 05 May 2011 17:42:51 -0500
Source: cdpr
Binary: cdpr
Architecture: source i386
Version: 2.4-1
Distribution: unstable
Urgency: low
Maintainer: Matt Zagrabelny mzagr...@d.umn.edu
Changed-By: Matt Zagrabelny mzagr...@d.umn.edu
Description: 
 cdpr   - Cisco Discovery Protocol Reporter
Closes: 527245 566983 570916
Changes: 
 cdpr (2.4-1) unstable; urgency=low
 .
   * New upstream release, closes: #570916
   * Bumped Standards-Version to 3.9.2
   * Added ${misc:Depends} to binary depends
   * Added a Homepage entry to the source fields
   * Checked cdpr into git
   * Upstream fixed blocking interface, closes: #566983
   * Added in patch to remove pseudo device any from list of interfaces,
 closes: #527245
   * Updated man page. '--help' and '-?' are invalid options and hence removed
   * Updated man page. Added '-r' for read a pcap-file
   * Updated copyright file to use
 http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=174
   * Added watch file
   * Added perl cgi and php server examples
   * Added example cdpr config file, for server usage
   * Bumped debhelper compat to v8
Checksums-Sha1: 
 f1b6ad2217c73d98b3263b3c70d097b75e129ee3 1752 cdpr_2.4-1.dsc
 45cc185ad0eb16178a795a46e676fa698eedb832 26053 cdpr_2.4.orig.tar.gz
 eff8b360effc49d476e372e1986c865325e83309 3950 cdpr_2.4-1.debian.tar.gz
 7d04a36cbb10d35cc3db30c51421a4b3bcbd999b 19888 cdpr_2.4-1_i386.deb
Checksums-Sha256: 
 ee4060e8fedd9a3f758e6aa6052fbeadac5e457e9907f785d76d44b2ead5f00b 1752 
cdpr_2.4-1.dsc
 32d3b58d8be7e2f78834469bd5f48546450ccc2a86d513177311cce994dfbec5 26053 
cdpr_2.4.orig.tar.gz
 7f6df530d4466a31b0944a9f9b7624b9f4637b87919fbc695c82c5bc8e3f80b2 3950 
cdpr_2.4-1.debian.tar.gz
 6f4d6ff9f9151dd4558edb902634a693e4dccabe887b47ca22ed1ad8f8d826d4 19888 
cdpr_2.4-1_i386.deb
Files: 
 ef962dab3f0d8b444edf57efd1672146 1752 net extra cdpr_2.4-1.dsc
 ee0f112e1a914168d088e4e0291efbcb 26053 net extra cdpr_2.4.orig.tar.gz
 58b40dacfdf77d4cc88a2b5e12c315e3 3950 net extra cdpr_2.4-1.debian.tar.gz
 ea655b9273213faebb8401e05cdc6d8f 19888 net extra cdpr_2.4-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJNzAM/AAoJEKbcJNnaJJPRHn4P/0ynYQqk3bf9Ivj5PQerkFQu
4s0pucHPUmO/6Zy5HZC751VMocYrfcmQq+YY9Y7JnmobaY4FuwtbBiRdHfJgvGmu
MVHb82BN6q0pksQBagx/JzQ4+JBvK5+WZgMhO4UTKOLVf+dVdSBzvWzHL5ZNRjIp
EnbO6YJVEZLMn+fGy99elve3UwYXVKaKGAb8xrkPv5q8HH9UxlEM94mx6h+Dk76t
4MafszTApsEQJMe3nsbS2fTBEFXjz2CjnCt0vm+Ib4VUDDqLB10fZ5EcVxwjg8Ej
cbsy36yQI9z2x2j+f6dzDwG8tKpSBD/3t41w66r/s47OjhORH3GnbchxWyPVwZxi
wLMC3H+4mYlRbq6Ojtnik7mbanIyqoGRV47KJmtj9fLnM6wi3W6rET9bXv3XSZkt
6bW4eazdpy7g0KSzLg6ZouWbXQvOBJhsk9DIoi03RuP1d2+KzIsCoxkc7INS/Xbd
UdCwG3f4eATa1Z4iAt9arS76jvabjWzAofPtWGTskPQx0ZfBaFPduKpCyEaZqVKq
MPnHlSHYa2CuSOW8Pv8pvT/c3jXZmvwZJ3xZM2XPwfuWSrIa/qqcYQZwxGRii5mS
J8QWjveLVaDyHc9WTDef+uLYK83Fnp6TY1DGx4/UuuZxJXwegi0NxCfhHRDZIIj+
hoIScBVFKylFQFmXsdsU
=e2dD
-END PGP SIGNATURE-


Accepted:
cdpr_2.4-1.debian.tar.gz
  to main/c/cdpr/cdpr_2.4-1.debian.tar.gz
cdpr_2.4-1.dsc
  to main/c/cdpr/cdpr_2.4-1.dsc
cdpr_2.4-1_i386.deb
  to main/c/cdpr/cdpr_2.4-1_i386.deb
cdpr_2.4.orig.tar.gz
  to main/c/cdpr/cdpr_2.4.orig.tar.gz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qkylj-0004a7...@franck.debian.org

Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)

[Matt Zagrabelny]

On Wed, Apr 6, 2011 at 9:45 AM, Heiko Schlittermann h...@schlittermann.de 
wrote:
 Stanislav Maslovski stanislav.maslov...@gmail.com (Sun Apr  3 12:37:26 
 2011):
 On Sun, Apr 03, 2011 at 10:11:03AM +0200, martin f krafft wrote:
  But if network-manager would become default and ifupdown an optional
  replacement, I would question Debian's capacity to make technically
  excellent decisions and wonder, how much we have been dragged along
  by user-friendly distros and slid off the track.

 I agree. If that happens I will seriously think about moving to
 another distro (I have been using Debian since around 1999). Or maybe
 to a *BSD.

 Using Debian (and partly supporting it) since about 1996: as soon as the
 network manager and similar tools become the default, it will be Debian's
 last days on my and our customers machines.

Wow. Just because a certain network configuration system is the
*default*? Are you this polar about text editors, web browsers, DE,
and other tools, too?

It seems like this thread is no longer productive.

-matt zagrabelny


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTi=7gwtax3meiwtftc3yxpykgif...@mail.gmail.com

Re: [RFC] Binary packages containing the source

[Matt Zagrabelny]

On Wed, Sep 22, 2010 at 12:35 PM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
 Brett Parker writes (Re: [RFC] Binary packages containing the source):
 On 22 Sep 12:47, Ian Jackson wrote:
  Julien Cristau writes (Re: [RFC] Binary packages containing the source):
   Why do people hate vowels so much?
 
  Bcs f y lv thm t y cn wrt ncmprhnsbl gbbrsh mch mr ffctvly.  Ls y sv
  smll mnt f typng.
                                                                ^Lts
                                                                surely?

 No :-).  Perhaps ls rather than Ls would have been more correct.
 I'm not sure of the correct rule for this situation...

 (If you're thinking of Lets, surely the sentence you are
 contemplating is missing its subject?)

I'll bite:

grep -i '^l[aeiou]*s[aeiou]*$' /usr/share/dict/american-english-insane
Lais
Laise
Laius
Laos
Las
Lasi
Leasia
Leesa
Leese
Leis
Leos
Les
Lesa
Lias
Liesa
Lis
Lisa
Lise
Loasa
Lois
Loise
Loos
Los
Lose
Louis
Louisa
Louise
Ls
Luis
Luisa
Luise
Lusa
Lusia
laas
laesie
laiose
laius
laos
las
lasa
lase
laus
leas
lease
lees
leese
leis
leos
les
lese
liaise
lias
lies
lieus
lis
lisu
loasa
looies
loos
loose
los
lose
louies
louis
louise
louse
ls
luaus
lues

Which one is it?!

Unless it is 'Also' and your capital L is nothing more than a red herring.

-matt zagrabelny


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinp-ozwt2ttu8-wjpww6bØxnuz3_svnsby...@mail.gmail.com

Re: [request-tracker-maintainers] Bug#595054: request-tracker3.8: Race condition between RT3.8+apache2 and MySQL when booting by insserv

[Matt Zagrabelny]

On Tue, Aug 31, 2010 at 3:39 PM, Dominic Hargreaves d...@earth.li wrote:
 On Tue, Aug 31, 2010 at 10:17:34PM +0400, Konstantin Khomoutov wrote:
 I'm using RT 3.8 with apache2 via mod_perl, MySQL is used as a database
 backend. When the server is booted using insserv, apache2 starts long
 before MySQL and for some reason some bit of RT tries to access the
 MySQL server, times out and fails; this prevents apache2 from starting.

 [snip logs]

 DBI connect('dbname=rtdb;host=localhost','rtuser',...) failed: Can't connect 
 to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at 
 /usr/share/perl5/DBIx/SearchBuilder/Handle.pm line 106
 [Tue Aug 31 21:40:18 2010] [error] Connect Failed Can't connect to local 
 MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)\n at 
 /usr/share/request-tracker3.8/lib/RT.pm line 217\nCompilation failed in 
 require at (eval 2) line 1.\n
 [Tue Aug 31 21:40:18 2010] [error] Can't load Perl file: 
 /usr/share/request-tracker3.8/libexec/webmux.pl for server 
 rt-admin.domain007.com:0, exiting...

 If I then start apache2 by hand, it starts OK (it only complains about
 the RTAddressRegexp config variable being unset which is harmless I suppose).

 [snip details]

 I suspect the included /etc/request-tracker3.8/apache2-modperl2.conf
 file might be a culprit as otherwise I can't imagine what other code
 could call RT internals and make it access the DB backend.

 Okay, there are two possible resolutions to this problem which spring
 to mind:

 * Arrange for database servers to start before Apache

 I'm not sure if this is feasible, but it seems to me that it's likely
 to be generally correct, given the layering implicit in database + web
 applications.

 * Arrange for RT to be more robust when a connection to the database fails

 This is certainly something worth exploring, but is likely to be a rather
 involved fix; not something I relish at this stage of the release cycle
 (diverging from upstream). Then again, perhaps changing Apache or MySQL
 (and the other database servers) would be more disruptive :)

 I've added the CC because I'm not sure where to start discussing
 whether the Apache/MySQL ordering can be changed. I had a look at
 Policy (which doesn't seem to mention dependency based booting at all;
 surely an inconsistency if it is to be enabled for squeeze?) and
 http://wiki.debian.org/LSBInitScripts which leads me to think that
 Apache needs something like Should-Start: $database_server, but this
 is mainly guessing. I would appreciate input from those familiar with
 this part of the Debian infrastructure.

Perhaps for /etc/init.d/mysql-server (or whatever it is called)

# X-Start-Before:apache2
# X-Stop-After:  apache2

I would think that it would be innocuous if apache2 was not installed.
Is there a way to reference the virtual package httpd in the LSB
headers?

-matt zagrabelny


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=l7r_sjw5k-zagks0juyy3m1p=gc4ledyfm...@mail.gmail.com

Accepted libtext-trim-perl 1.02-1 (source all)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 28 May 2010 14:42:32 -0500
Source: libtext-trim-perl
Binary: libtext-trim-perl
Architecture: source all
Version: 1.02-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Matt Zagrabelny mzagr...@d.umn.edu
Description: 
 libtext-trim-perl - module for remove leading and/or trailing whitespace from 
strings
Closes: 568144
Changes: 
 libtext-trim-perl (1.02-1) unstable; urgency=low
 .
   * Initial Release. (Closes: #568144)
Checksums-Sha1: 
 dbb4c4279c09392ca4f7756933c0105fff0374a8 2059 libtext-trim-perl_1.02-1.dsc
 46db3649b9713a9b0d7201f3cccf2b1e8e7e015e 5905 
libtext-trim-perl_1.02.orig.tar.gz
 93ba911c0765b91fa58d6976bb536c48327ee4e3 1489 
libtext-trim-perl_1.02-1.debian.tar.gz
 cfd80609b894b66ed6927909e393f8b33a74a990 7544 libtext-trim-perl_1.02-1_all.deb
Checksums-Sha256: 
 d28be90ad8cc876366f7631baa57a6b44d2a9096dd1709b54237743988c765ff 2059 
libtext-trim-perl_1.02-1.dsc
 1c739a2c7f04a6a3999c4eb394655c58c64baca4e5d4fcb3b58813600b95dcae 5905 
libtext-trim-perl_1.02.orig.tar.gz
 2e0fe3d8d2ab2b3d19510fae498bae6a8992341af692ec8c11ce9fb9cce4d01b 1489 
libtext-trim-perl_1.02-1.debian.tar.gz
 cb2c4ca2cc2b3e17530aff5901324420d7cc9d071b99f6e7ddaa71b3bd46cac5 7544 
libtext-trim-perl_1.02-1_all.deb
Files: 
 8eebe86da3ce586cfb79ad244b0c3cd9 2059 perl optional 
libtext-trim-perl_1.02-1.dsc
 91506dcbef8201fd4645e885b631c0fa 5905 perl optional 
libtext-trim-perl_1.02.orig.tar.gz
 d457d5a848a921274fc5a9be58bd67bc 1489 perl optional 
libtext-trim-perl_1.02-1.debian.tar.gz
 1e73e59d31ce5e08749db0deb1824a80 7544 perl optional 
libtext-trim-perl_1.02-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJMDRWNAAoJELs6aAGGSaoGDW8QALci9TgX2DoZH3MP9iAefwa2
Goh/e+5eyulh1e1fw27KHatKKUtoE9xHKAG90QIjUG4b7AvHjt7D3jkul3IEbC4l
P4uPG9nqrlIFSd1babUK5YuK1YqIYXlUZaxZLj0AzS6oBauGEgYsZL134qPPUjn7
bAG7Tkue+8Ir58fNwdnw8G7sTZ3PBO0Gt4YndppxM/BjUFXz9J5+EpM2yjBrK//B
q9Kv8oEywFaBAs5Gtsb1aDiIXTHgIrAKeXJQonuLvfGM8cJ9TIDAMIlHDxwdm6vL
4jSGFQbB+KMyDX4fIlgDdeA1duxwiUcCrbMsfzDnjvIAk5cbtN3KCK5VUrb9SKtq
GeN8h3YfL+N2VeQJBP04VHmMgum+X8Eoi3qQLwyxmJHHXi6WYSkUW/wn+ltQwJhN
0zsS0aw3kWqQd0dy5UaR14tQON7XPX/iuaY5FtwQshx3MVpkqFtXnK7lplCcoPqZ
ttiDdVF0XkGTNEkNQvvpSKuv6yfLWhNvfBF8hhnuaDAo2ADQTT61esxajnF24SxT
FDXa1+fhu1mOV8SXJupL+SfSTESxf2iTmd1VxnJQ16tFwXxWbOlpREy9ulDb3Tzf
05lXzjvWVVRSicmnIP9oDfgxyIC6SUjY0a05HCvLXb637aPzSwZTWbd3i1+YO1xm
PptsFKffoW5z0KH6kxHi
=rwey
-END PGP SIGNATURE-


Accepted:
libtext-trim-perl_1.02-1.debian.tar.gz
  to main/libt/libtext-trim-perl/libtext-trim-perl_1.02-1.debian.tar.gz
libtext-trim-perl_1.02-1.dsc
  to main/libt/libtext-trim-perl/libtext-trim-perl_1.02-1.dsc
libtext-trim-perl_1.02-1_all.deb
  to main/libt/libtext-trim-perl/libtext-trim-perl_1.02-1_all.deb
libtext-trim-perl_1.02.orig.tar.gz
  to main/libt/libtext-trim-perl/libtext-trim-perl_1.02.orig.tar.gz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1onqam-00064v...@ries.debian.org

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Matt Zagrabelny]

On Wed, 2010-02-03 at 11:01 +0100, Guus Sliepen wrote:
 On Wed, Feb 03, 2010 at 10:37:08AM +0100, Tollef Fog Heen wrote:
 
  ]] Tourneur Henry-Nicolas 
  
  | * License : No license, only a copyright file
  
  Surely that makes it illegal for us to distribute?
 
 Actually, it does have a license, which is in the COPYING file and at the top
 of all the source code files:
 
Permission to use, copy, modify, and distribute this software for
any purpose and without fee is hereby granted, provided that this
copyright and permission notice appear on all copies of the
software and supporting documentation, the name of Cisco Systems,
Inc. not be used in advertising or publicity pertaining to
distribution of the program without specific prior permission, and
notice be given in supporting documentation that modification,
copying and distribution is by permission of Cisco Systems, Inc.
 
 I think this can be distributed in the non-free section?

The old version of this package was distributed in main.

$ apt-cache policy tac-plus
tac-plus:
  Installed: 1:4.0.4.alpha-14.2
  Candidate: 1:4.0.4.alpha-14.2
  Version table:
 *** 1:4.0.4.alpha-14.2 0
100 /var/lib/dpkg/status
 1:4.0.4.alpha-14 0
500 http://ftp.us.debian.org oldstable/main Packages


-- 
Matt Zagrabelny - mzagr...@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems  Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF  C899 07E2 BFA8 42A0 0942

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot


signature.asc
Description: This is a digitally signed message part

git and quilt

[Matt Zagrabelny]

Greetings,

I read through the git-buildpackage docs and also a HOWTO by Russ
Allbery [1] regarding git and Debian packaging. I am wondering if those
who use git to manage their source package development are also using
the debian/patches mechanism for modifying the upstream tarball.

I receive the following error from lintian and am looking for some
guidance/best practices.

% lintian --pedantic cdpr_2.3-3.dsc
P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
1 more

I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
package.

Thanks for the tips,

[1] http://www.eyrie.org/~eagle/notes/debian/git.html

-- 
Matt Zagrabelny - mzagr...@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems  Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF  C899 07E2 BFA8 42A0 0942

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot


signature.asc
Description: This is a digitally signed message part

Accepted libthread-queue-any-perl 0.09-1 (source all)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 10 Apr 2009 16:01:37 -0500
Source: libthread-queue-any-perl
Binary: libthread-queue-any-perl
Architecture: source all
Version: 0.09-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Matt Zagrabelny mzagr...@d.umn.edu
Description: 
 libthread-queue-any-perl - thread-safe queues for any data-structure
Closes: 501694
Changes: 
 libthread-queue-any-perl (0.09-1) unstable; urgency=low
 .
   * Initial Release. (Closes: #501694)
Checksums-Sha1: 
 d28efd9b60c688c5738c30dd8ad4d9f4a355ccaf 1394 
libthread-queue-any-perl_0.09-1.dsc
 973a4e76bffd231aa0725009cbc1b2f820b26df4 4356 
libthread-queue-any-perl_0.09.orig.tar.gz
 e495dfd4a0d7969901f01f5dd878e37467f1f6ea 1383 
libthread-queue-any-perl_0.09-1.diff.gz
 1c2ec22382f6a8ac5d299b50c6f1da36766c13c0 8920 
libthread-queue-any-perl_0.09-1_all.deb
Checksums-Sha256: 
 78b925391efa602291388b20815c8fa12d4fd0c9be7a9248f8e591b942501e16 1394 
libthread-queue-any-perl_0.09-1.dsc
 7c65995d64aff3274b0c3321eea1f22ccd9383cd7ea496e93460c8dcbddb974d 4356 
libthread-queue-any-perl_0.09.orig.tar.gz
 f2723ccac76fc1d9783f09bd7c026db2b46a03ff1b80bbcf7d7ef6aacd30b50b 1383 
libthread-queue-any-perl_0.09-1.diff.gz
 1bf5377f44a96a3caea7acc91b8ff2e0f7d9e68bc8eb383e6b9ef337da35b818 8920 
libthread-queue-any-perl_0.09-1_all.deb
Files: 
 033cf9a9edc34991c968640d3470e29b 1394 perl optional 
libthread-queue-any-perl_0.09-1.dsc
 13fc0640ea1dd4cce02619cd7ab9c488 4356 perl optional 
libthread-queue-any-perl_0.09.orig.tar.gz
 c410c7601c8bb4438494e6660bb60a7b 1383 perl optional 
libthread-queue-any-perl_0.09-1.diff.gz
 ee49d15d6557b17452fd7bc944d5fbb5 8920 perl optional 
libthread-queue-any-perl_0.09-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknl++cACgkQy+HP4f7iC8uKvQCdGfpkgB1OR1Mcb+hyvZbXVmhf
zMYAoJT7Ne0xOvvjc0vQT7weRQU0659I
=lfbp
-END PGP SIGNATURE-


Accepted:
libthread-queue-any-perl_0.09-1.diff.gz
  to 
pool/main/libt/libthread-queue-any-perl/libthread-queue-any-perl_0.09-1.diff.gz
libthread-queue-any-perl_0.09-1.dsc
  to pool/main/libt/libthread-queue-any-perl/libthread-queue-any-perl_0.09-1.dsc
libthread-queue-any-perl_0.09-1_all.deb
  to 
pool/main/libt/libthread-queue-any-perl/libthread-queue-any-perl_0.09-1_all.deb
libthread-queue-any-perl_0.09.orig.tar.gz
  to 
pool/main/libt/libthread-queue-any-perl/libthread-queue-any-perl_0.09.orig.tar.gz


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

Accepted libthread-serialize-perl 0.10-1 (source all)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 10 Apr 2009 13:43:00 -0500
Source: libthread-serialize-perl
Binary: libthread-serialize-perl
Architecture: source all
Version: 0.10-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Matt Zagrabelny mzagr...@d.umn.edu
Description: 
 libthread-serialize-perl - serialize data-structures between threads
Closes: 501714
Changes: 
 libthread-serialize-perl (0.10-1) unstable; urgency=low
 .
   * Initial Release. (Closes: #501714)
Checksums-Sha1: 
 024a16a433d5d494e9c89f318985d1dff8c617db 1408 
libthread-serialize-perl_0.10-1.dsc
 2855e11976f538308ee38d2c19dc302bc5bc32bb 4847 
libthread-serialize-perl_0.10.orig.tar.gz
 0d76fc0555d54bf37bf9db2e4aab597ae8ca8852 1560 
libthread-serialize-perl_0.10-1.diff.gz
 a6aaeb36c0b144e6d1cfc5d7a0c8897553397883 9656 
libthread-serialize-perl_0.10-1_all.deb
Checksums-Sha256: 
 5573cbe48bd207d4a0517a28f2141548043bfd146a5ca027f8725e7658b16361 1408 
libthread-serialize-perl_0.10-1.dsc
 4dbfbd5e0a561f2cbc9ccc4c00e3cb0df0a3beff6f29f49773342483d84a26cb 4847 
libthread-serialize-perl_0.10.orig.tar.gz
 ca0e4504cfa9f7a89412c57f3b701101724f885e7bc7bec99e94a54ff0e766bc 1560 
libthread-serialize-perl_0.10-1.diff.gz
 0f95a86aa52f63dfbd972abd6605fe022d81a420c58747f935041f451fd16d8a 9656 
libthread-serialize-perl_0.10-1_all.deb
Files: 
 74a3eea7d8e4dd41467a7a52c020061b 1408 perl optional 
libthread-serialize-perl_0.10-1.dsc
 05fb8838800c3d5d053f35a995ce87d2 4847 perl optional 
libthread-serialize-perl_0.10.orig.tar.gz
 e3ad4c666c66187c772ec9c44f4d2168 1560 perl optional 
libthread-serialize-perl_0.10-1.diff.gz
 a3e940c4a8cd194f2f5ca20a7a06288d 9656 perl optional 
libthread-serialize-perl_0.10-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknl9rEACgkQy+HP4f7iC8uCEQCfV6VQxo3+WSES9lpwtYwmibs8
UycAn35SW5fDts2bAPxOPRcpTFvfyJYI
=abJQ
-END PGP SIGNATURE-


Accepted:
libthread-serialize-perl_0.10-1.diff.gz
  to 
pool/main/libt/libthread-serialize-perl/libthread-serialize-perl_0.10-1.diff.gz
libthread-serialize-perl_0.10-1.dsc
  to pool/main/libt/libthread-serialize-perl/libthread-serialize-perl_0.10-1.dsc
libthread-serialize-perl_0.10-1_all.deb
  to 
pool/main/libt/libthread-serialize-perl/libthread-serialize-perl_0.10-1_all.deb
libthread-serialize-perl_0.10.orig.tar.gz
  to 
pool/main/libt/libthread-serialize-perl/libthread-serialize-perl_0.10.orig.tar.gz


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

Accepted libload-perl 0.19-1 (source all)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 10 Apr 2009 10:55:52 -0500
Source: libload-perl
Binary: libload-perl
Architecture: source all
Version: 0.19-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Matt Zagrabelny mzagr...@d.umn.edu
Description: 
 libload-perl - control when subroutines will be loaded
Closes: 501716
Changes: 
 libload-perl (0.19-1) unstable; urgency=low
 .
   * Initial Release. (Closes: #501716)
Checksums-Sha1: 
 10bcf815d1d4ef872152426014dc852918be6d86 1265 libload-perl_0.19-1.dsc
 8c066269d4210f7413476fc300e5992bfdcf7edf 16059 libload-perl_0.19.orig.tar.gz
 a5f96b7add4593d21a2a681edef34bd39688870c 1793 libload-perl_0.19-1.diff.gz
 b8c8f49200272fa8bd45b526e16d3c7ea07c12bc 25734 libload-perl_0.19-1_all.deb
Checksums-Sha256: 
 59068b81c1fd9d1660274150ac800fd0bdda272e15e8ee9e2321921dbe7d573c 1265 
libload-perl_0.19-1.dsc
 571b9aac2e1c6ef25b46262592bd5d2dc23531e86433adfb70bcef12052c845d 16059 
libload-perl_0.19.orig.tar.gz
 76a81afdb1d7bbd8aaf8c35ac4453b291a4267411549847c3b062c77c8ec007e 1793 
libload-perl_0.19-1.diff.gz
 27d559db3cf3e8a75e4d473d8972aa78a4e0bd4d37e1d92da225f5715d51f6d1 25734 
libload-perl_0.19-1_all.deb
Files: 
 72ed7ed2c83a437564fc6892cb3adca5 1265 perl optional libload-perl_0.19-1.dsc
 30fec71cdc78ec2512764556b47fb051 16059 perl optional 
libload-perl_0.19.orig.tar.gz
 dd7145fafc07d4519ef19e3a58f38dab 1793 perl optional libload-perl_0.19-1.diff.gz
 dbf035b6c7de7c441c0e40dd011e7510 25734 perl optional 
libload-perl_0.19-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknl9bwACgkQy+HP4f7iC8vJAQCeKZgyilullzAd+iWR6aECyoLW
x98AoJCSNSx/oeaJh3vYeEUfl9SaMOdj
=hqJB
-END PGP SIGNATURE-


Accepted:
libload-perl_0.19-1.diff.gz
  to pool/main/libl/libload-perl/libload-perl_0.19-1.diff.gz
libload-perl_0.19-1.dsc
  to pool/main/libl/libload-perl/libload-perl_0.19-1.dsc
libload-perl_0.19-1_all.deb
  to pool/main/libl/libload-perl/libload-perl_0.19-1_all.deb
libload-perl_0.19.orig.tar.gz
  to pool/main/libl/libload-perl/libload-perl_0.19.orig.tar.gz


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

Accepted libnet-mac-vendor-perl 1.18-1 (source all)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 8 Apr 2009 13:31:24 -0500
Source: libnet-mac-vendor-perl
Binary: libnet-mac-vendor-perl
Architecture: source all
Version: 1.18-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Matt Zagrabelny mzagr...@d.umn.edu
Description: 
 libnet-mac-vendor-perl - look up the vendor by OUI
Closes: 501717
Changes: 
 libnet-mac-vendor-perl (1.18-1) unstable; urgency=low
 .
   * Initial Release. (Closes: #501717)
Checksums-Sha1: 
 a933c700ba02126f5fa4f84fdc3a82cdafcc31af 1388 libnet-mac-vendor-perl_1.18-1.dsc
 63c34e065327eaa0cb4fef584e560eedc8a01e62 43724 
libnet-mac-vendor-perl_1.18.orig.tar.gz
 c70298c245848edd17b7d05f2a4053803ad03a41 1671 
libnet-mac-vendor-perl_1.18-1.diff.gz
 d57e5fb6afbae32189e74f2c426364d5e337aea3 11966 
libnet-mac-vendor-perl_1.18-1_all.deb
Checksums-Sha256: 
 b63fdcf3633096828519fe16f3ebfef632af7a3e4cf2f685756cc7a1c43a3b3b 1388 
libnet-mac-vendor-perl_1.18-1.dsc
 c4e2c34471dcb13ecf3e4091c688694fda9960ba2bc1fcaa379edac6269ebc67 43724 
libnet-mac-vendor-perl_1.18.orig.tar.gz
 08c661254868895a74c944ead7e2827f2134992417c061b35b3470dffa40c4f6 1671 
libnet-mac-vendor-perl_1.18-1.diff.gz
 92a53755ccf2d465b5ff6175dbd399a907651cd0640c521bfc96c3dc0079db45 11966 
libnet-mac-vendor-perl_1.18-1_all.deb
Files: 
 9a684a65cca8e09ede648eb205423b0b 1388 perl optional 
libnet-mac-vendor-perl_1.18-1.dsc
 0f2f5b4b591351f8a878d92beca9a1ea 43724 perl optional 
libnet-mac-vendor-perl_1.18.orig.tar.gz
 b50d6abdc91a1b0701f7c8861c97b464 1671 perl optional 
libnet-mac-vendor-perl_1.18-1.diff.gz
 123ac9fab4f9c37568db3433ddaa5010 11966 perl optional 
libnet-mac-vendor-perl_1.18-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknl9MYACgkQy+HP4f7iC8sVHQCeMDTkjlg0YI6WDzjb/JG3zFUf
M7oAn1GHJ481Fp8PB7giu/dEtEP6vykH
=LBQF
-END PGP SIGNATURE-


Accepted:
libnet-mac-vendor-perl_1.18-1.diff.gz
  to pool/main/libn/libnet-mac-vendor-perl/libnet-mac-vendor-perl_1.18-1.diff.gz
libnet-mac-vendor-perl_1.18-1.dsc
  to pool/main/libn/libnet-mac-vendor-perl/libnet-mac-vendor-perl_1.18-1.dsc
libnet-mac-vendor-perl_1.18-1_all.deb
  to pool/main/libn/libnet-mac-vendor-perl/libnet-mac-vendor-perl_1.18-1_all.deb
libnet-mac-vendor-perl_1.18.orig.tar.gz
  to 
pool/main/libn/libnet-mac-vendor-perl/libnet-mac-vendor-perl_1.18.orig.tar.gz


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

Bug#501694: ITP: libthread-queue-any-perl -- Thread-safe queues for any data-structure

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny [EMAIL PROTECTED]


* Package name: libthread-queue-any-perl
  Version : 0.09
  Upstream Author : Elizabeth Mattijsen [EMAIL PROTECTED]
* URL :
* 
http://search.cpan.org/~elizabeth/Thread-Queue-Any-0.09/lib/Thread/Queue/Any.pm
* License : Same terms as Perl
  Programming Lang: Perl
  Description : Thread-safe queues for any data-structure

A queue, as implemented by Thread::Queue::Any is a thread-safe data
structure that inherits from Thread::Queue. But unlike the standard
Thread::Queue, you can pass (a reference to) any data structure to the
queue.

Apart from the fact that the parameters to enqueue are considered to be
a set that needs to be enqueued together and that dequeue returns all of
the parameters that were enqueued together, this module is a drop-in
replacement for Thread::Queue in every other aspect.

Any number of threads can safely add elements to the end of the list, or
remove elements from the head of the list. (Queues don't permit adding
or removing elements from the middle of the list).

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)



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

Bug#501714: ITP: libthread-serialize-perl -- Serialize data-structures between threads

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny [EMAIL PROTECTED]


* Package name: libthread-serialize-perl
  Version : 0.10
  Upstream Author : Elizabeth Mattijsen [EMAIL PROTECTED]
* URL :
* 
http://search.cpan.org/~elizabeth/Thread-Serialize-0.10/lib/Thread/Serialize.pm
* License : Same terms as Perl
  Programming Lang: Perl
  Description : Serialize data-structures between threads

The Thread::Serialize module is a library for centralizing the routines
used to serialize data-structures between threads. Because of this
central location, other modules such as Thread::Conveyor, Thread::Pool
or Thread::Tie can benefit from the same optimilizations that may take
place here in the future.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)



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

Bug#501716: ITP: libload-perl -- Control when subroutines will be loaded

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny [EMAIL PROTECTED]


* Package name: libload-perl
  Version : 0.19
  Upstream Author : Elizabeth Mattijsen [EMAIL PROTECTED]
* URL :
* http://search.cpan.org/~elizabeth/load-0.19/lib/load.pm
* License : Same terms as Perl
  Programming Lang: Perl
  Description : Control when subroutines will be loaded

The load pragma allows a module developer to give the application
developer more options with regards to optimize for memory or CPU usage.
The load pragma gives more control on the moment when subroutines are
loaded and start taking up memory. This allows the application developer
to optimize for CPU usage (by loading all of a module at compile time
and thus reducing the amount of CPU used during the execution of an
application). Or allow the application developer to optimize for memory
usage, by loading subroutines only when they are actually needed,
thereby however increasing the amount of CPU needed during execution.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)



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

Bug#501717: ITP: libnet-mac-vendor-perl -- Look up the vendor for a MAC

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny [EMAIL PROTECTED]


* Package name: libnet-mac-vendor-perl
  Version : 1.18
  Upstream Author : brian d foy [EMAIL PROTECTED]
* URL :
* http://search.cpan.org/~bdfoy/Net-MAC-Vendor-1.18/lib/Vendor.pm
* License : Same terms as Perl
  Programming Lang: Perl
  Description : Look up the vendor for a MAC

This module allows you to take a MAC address and turn it into the OUI
and vendor information.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)



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

Bug#472500: ITP: libfastthread-ruby -- Optimized replacement for thread.rb primitives

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny [EMAIL PROTECTED]


* Package name: libfastthread-ruby
  Version : 1.0.1
  Upstream Author : MenTaLguY [EMAIL PROTECTED]
* URL : http://rubyforge.org/frs/?group_id=1306
* License : Ruby License
  Programming Lang: C
  Description : Optimized replacement for thread.rb primitives

This library provides an optimized replacement for the thread.rb
primitives.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Accepted cdpr 2.2.1-1 (source i386)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 19 Oct 2006 10:33:24 -0500
Source: cdpr
Binary: cdpr
Architecture: source i386
Version: 2.2.1-1
Distribution: unstable
Urgency: low
Maintainer: Matt Zagrabelny [EMAIL PROTECTED]
Changed-By: Matt Zagrabelny [EMAIL PROTECTED]
Description: 
 cdpr   - Cisco Discovery Protocol Reporter
Closes: 393550
Changes: 
 cdpr (2.2.1-1) unstable; urgency=low
 .
   * New upstream release
   * Make sure all content gets installed when building only
 the binary-arch target, closes: #393550
   * Cleaned up manpage
   * Added upstream changelog
Files: 
 016f79689263c188234ef7b4db1f730b 632 net extra cdpr_2.2.1-1.dsc
 1e682e7e9c03f9b004c1f97c0ed25431 25050 net extra cdpr_2.2.1.orig.tar.gz
 d90511bbb46fe09c06b177786901bf15 2484 net extra cdpr_2.2.1-1.diff.gz
 2a8c2f3cb1adb909e20b8d8c7a355f09 15192 net extra cdpr_2.2.1-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Signed by Isaac Clerencia [EMAIL PROTECTED]

iD8DBQFFOHM2QET2GFTmct4RAlisAKCW6zkiAHaVrMKojtlxZ19yYORSgwCfZcx/
gv5XvNZbch+XQzKDvbun6gI=
=cSUc
-END PGP SIGNATURE-


Accepted:
cdpr_2.2.1-1.diff.gz
  to pool/main/c/cdpr/cdpr_2.2.1-1.diff.gz
cdpr_2.2.1-1.dsc
  to pool/main/c/cdpr/cdpr_2.2.1-1.dsc
cdpr_2.2.1-1_i386.deb
  to pool/main/c/cdpr/cdpr_2.2.1-1_i386.deb
cdpr_2.2.1.orig.tar.gz
  to pool/main/c/cdpr/cdpr_2.2.1.orig.tar.gz


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

Accepted cdpr 2.2.0-2 (source i386)

[Matt Zagrabelny]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 25 May 2006 12:40:20 -0600
Source: cdpr
Binary: cdpr
Architecture: source i386
Version: 2.2.0-2
Distribution: unstable
Urgency: low
Maintainer: Matt Zagrabelny [EMAIL PROTECTED]
Changed-By: Matt Zagrabelny [EMAIL PROTECTED]
Description: 
 cdpr   - Cisco Discovery Protocol Reporter
Closes: 338153
Changes: 
 cdpr (2.2.0-2) unstable; urgency=low
 .
   * Initial release, closes: Bug#338153
   * Updated 'Standards-Version' to 3.7.2 in debian/control.
   * Cleaned up debian/rules file.
Files: 
 0fc3c94cbb77b4bf3bb9d341a92ce5a8 632 net extra cdpr_2.2.0-2.dsc
 7a6631ffd63d0706fd82060391fc039b 2405 net extra cdpr_2.2.0-2.diff.gz
 f0bd99a5a1b6ce92c58aab63c7ddb72f 11924 net extra cdpr_2.2.0-2_i386.deb
 023b8bd6d399204a66ad728f2aa11ca3 25186 net extra cdpr_2.2.0.orig.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Signed by Isaac Clerencia [EMAIL PROTECTED]

iD8DBQFEvkqNQET2GFTmct4RArv3AJ0b2L7uf8YAhXy1U64EhFx0Pdbq3gCbB3Mn
PDJhPSUyTOptEJVO34GLqfQ=
=1XZ8
-END PGP SIGNATURE-


Accepted:
cdpr_2.2.0-2.diff.gz
  to pool/main/c/cdpr/cdpr_2.2.0-2.diff.gz
cdpr_2.2.0-2.dsc
  to pool/main/c/cdpr/cdpr_2.2.0-2.dsc
cdpr_2.2.0-2_i386.deb
  to pool/main/c/cdpr/cdpr_2.2.0-2_i386.deb
cdpr_2.2.0.orig.tar.gz
  to pool/main/c/cdpr/cdpr_2.2.0.orig.tar.gz


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

Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys

[Matt Zagrabelny]

 prove that?

there are countless things that cannot be proved. rsa crypto cannot be
proved to be a good crypto, it just appears to be. many things we rely
upon have no proof of being good, or right, or what we expect them
to provide, we just accept them as they are; and with that we accept the
risk of not knowing (for 100%) that things are as we expect them to be. 

  and, indeed, being rather well known (it seems) there would have
  made it more difficult for him to pull off than, say, someone off
  the street.
 
 Well known to whom?  I, for one, did not know very many people
  at the conference, and large chunks of people were in my shoes.
  Also, people who did know the perp were unlikely to look closely at
  the fake documents being brandished.

martin is supposed to accept (or know) the fact that ksp are insecure.
(though they cant be *proved* to be)

and you are unwilling to accept some account of what happened at the ksp
because it cant be *proved*.

this is an issue.

-- 
Matt Zagrabelny - [EMAIL PROTECTED] - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems  Services
PGP key 1024D/84E22DA2 2005-11-07
Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot


signature.asc
Description: This is a digitally signed message part

Bug#338153: ITP: cdpr -- Cisco Discovery Protocol Reporter

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny [EMAIL PROTECTED]


* Package name: cdpr
  Version : 2.2.0
  Upstream Author : Lance O'Connor [EMAIL PROTECTED]
* URL : http://www.d.umn.edu/~mzagrabe/debian/cdpr/
* License : GPL
  Description : Cisco Discovery Protocol Reporter

(Include the long description here.)

cdpr listens on specified network interfaces for Cisco Discovery
Protocol packets. It thendecodes those packets and outputs the
information, optionally sending the information to a server for
processing.



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.3.20050725.0
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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