Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

[Anthony DeRobertis]

On 2/21/20 2:00 AM, Wouter Verhelst wrote:

Even so, if we want to do so, this can be done correctly by a preinst
script in new libc, by way of a script that does the following:

cp -a /lib/ /usr/lib/
ln -sf /lib/ /usr/lib/

The first of the above two creates the new file; the second replaces the
old file, atomically, by a symlink.


Errr, pretty sure you meant to have the ln arguments in the opposite 
order. The link name is the second argument to ln.


Besides that, you need a sync after the cp. Otherwise (in the event of 
an ill-timed crash) the data may not be written out, and you might wind 
up with /usr/lib/ being, e.g., a zero-byte file 
(with /lib/ a symlink to it). Possibly you even end 
up with /usr/lib/ missing, and /lib/name> a dangling link.


(It appears ln does not do a sync of any sort between the symlinkat and 
rename syscalls, no idea if that is also a bug.)

Re: Y2038 - best way forward in Debian?

[Anthony DeRobertis]

On February 14, 2020 7:45:30 PM UTC, Alan Corey  wrote:
>What if we define an epoch to be 50 years and the epoch number becomes
>part of how the computer keeps track of the date.  Something similar
>is done in astronomy I think, star charts always have an epoch.  So
>epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050.   Then we can keep
>a time_t at 32 bits.  Things like strptime() and strftime() and
>ctime() would need changing but since they were valid in epoch 0
>they'd only need to change for epoch 1 and later. 

Everything that handles time would need to change. Just think of the fun of 
"what's one year from today?" when you cross an epic. Far easier to just make 
time_t 64-bit.

And file formats and protocols that currently use time_t would need to be 
adjusted to add a second field for an epoch. Same incompatibility concerns as 
64-bit time_t. 

Not to mention that the Gregorian calendar leap year cycle is 400 years long, 
so if you ignore the epic, you'll have no idea if it's a leap year. Which also 
means that you have no idea how long your 50-year epic is, since they vary, 
they're not all the same number of seconds, or even days.

Ultimately, you'd wind up with a presumably int-sized epoch plus an int sized 
time_t. That's 64 bits still...

Lastly, 64-bit time_t has been tested widely (e.g., on amd64). That's not 
perfect of course since 32-bit archs have smaller basic integer types, but 
likely a lot less work fixing the stray "int"s than adding epochs all over the 
place. 

PS: Debian-devel is likely the wrong place to redesign C/POSIX functions. 

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

[Anthony DeRobertis]

On February 11, 2020 6:28:08 PM UTC, Ansgar  wrote:
>
>The downside is that magic like [rsyslog disabling persistent journal] might 
>not be easily discoverable
>and confuse people who for some reason want a persistent journal and
>syslog.

A lot of my machines are configured like that, mainly because of how much 
faster things like tail -f /var/log/syslog are vs. journalctl -f. So I keep a 
short amount of logs in traditional syslog format (quick access), and much 
longer history in journald (better search/filter). I get the best of both 
worlds.

It'd be very surprising if rsyslog disabled the persistent journal on upgrade. 
Or when installing it.

I think it'd be fine for it to give me the option, default do not disable, via 
debconf, not sure if that'd be low or medium.

There's the obvious point that enabling the persistent journal could be 
surprising, too. But I think the harm there is relatively minimal (increased 
disk usage, but journald will not fill a filesystem) and is easily fixed with 
rm. The lack of a persistent journal isn't necessarily noticed until you try to 
check the logs, and at that point may be unfixable: the data is gone.

I would more worry about the harm on systems where there are intentionally no 
persistent logs, neither journal nor syslog. There could be privacy 
implications. But hopefully the release notes cover that use case.

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

[Anthony DeRobertis]

On 2/6/20 6:26 AM, Martin Steigerwald wrote:

I solved this by removing Systemd from my systems.

And now what?


Then you're not running the default configuration, which is of course 
perfectly fine. As part of switching from systemd to your init system of 
choice, you'd also install your favorite non-journald logger.


I, personally, think the systemd maintainers here have made the right 
choice to enable the persistent journal by default. And that it really 
doesn't make sense to have two copies of the logs written to disk, 
increase the attack surface with another daemon, etc., so that yes, 
eventually rsyslog shouldn't be in the default install, even though I'll 
probably keep it installed on most of my machines for a while. I'm 
confident they're working hard to improve Debian, even and especially 
when I personally disagree with a decision, and thank them for that.


Finally, I believe you want Debian to continue to be a distro where 
admins have choice as to what runs on their systems. I believe the best 
way you could help to achieve this is to present easy technical 
solutions to make that choice possible. For example:


   If rsyslog is no longer installed by default, non-systemd init
   systems should add a Recommends: system-log-daemon, so that
   switching to one of them would (by default) pull in a syslogd.

Maybe that's not quite the right technical solution, but it'd be a much 
more pleasant and productive conversation to iterate on that than this 
conversation has been.

Re: Producing verifiable initramfs images

[Anthony DeRobertis]

An interesting challenge you've taken up, I fear it's going to be a lot 
of work.


On almost all of my older installs, the initramfs is built with 
MODULES=dep, because otherwise /boot runs out of space; the amount of 
space MODULES=most takes is ever-increasing. So the kernel packages 
plopping a default initramfs in /boot would break those systems (but 
that's solvable e.g., by having it be an optional extra binary package)


Even with the default, it's possible to include extra modules — either 
by the admin plopping them in /etc/initramfs-tools/modules or I believe 
through package hooks. (I'm not sure if it also does the work 
MODULES=dep does and adds any extra modules found). But maybe as long as 
the kernel is only loading signed modules, it's OK to put additional 
modules in an extra, non-TPM-measured archive?


/etc/modprobe.d is included in initramfs. That's going to be challenging 
because it can include both configuration and code, and even without the 
code, "arbitrary kernel modules loaded with arbitrary options" seems to 
big a difference to ignore. And you can't not include this, since 
initramfs loads so many modules.


Local udev rules (from /etc/udev/rules.d/) are included as well; they 
wind up in /usr/lib/udev/rules.d on the initramfs. Those are again an 
interesting combination of configuration and code.

Re: Adding security features

[Anthony DeRobertis]

On 2/5/20 2:52 PM, Nikolaus Rath wrote:


I think it's worth pointing out that this was an experimental feature
that users explicitly had to opt into. The original statement feels
misleading to me.



That's how it started, further looking (sorry, was replying from my 
phone before) give things like 
https://www.theandroidsoul.com/google-now-and-google-search-now-shows-your-recent-gmail-messages-when-you-search-my-inbox/ 
where various search terms show gmail messages. Which I just checked, 
searching "my inbox" still works here. I don't think that's anything 
special I've turned on, don't think "labs" even exists anymore in Gmail.

Re: Adding security features

[Anthony DeRobertis]

On February 5, 2020 9:49:36 AM UTC, Nikolaus Rath  wrote:
>On Feb 04 2020, Anthony DeRobertis  wrote:
>> Google has at some point had results from
>> Gmail in the web search results (no idea if they currently do).
>
>Would you have a reference for this please?

Here is a news report from when they were testing it:
 
https://www.pcworld.com/article/260600/google_tries_showing_gmail_emails_in_search_results.html
 

Not sure what came of it.

Re: Adding security features

[Anthony DeRobertis]

On 2/3/20 11:51 AM, Marvin Renich wrote:


As a specific example of unnecessary default security, take the "https
everywhere" campaign.  Having https available on most servers is
definitely good.  However, if you explicitly go to
http://www.google.com/ you are redirected to the https version.  Of all
the (hundreds of?) billions of google searches done every day, how many
of them would really cause any harm at all if the communications were
unencrypted?


I think you've picked a really bad example, and I'm not sure if that's 
because you grabbed something out of the air without really examining 
it, but just in case it's not...


I think, first, you're asking the wrong question. Almost no one, and 
definitely not the people we're setting the defaults for, would remember 
to pick between http:// and https:// each time they're doing a search. 
After all, we're presuming the default. So even if it turns out a small 
percentage of searches, it can easily mean that it's a large percent of 
*users*.


And it probably is. When I think of my own searches, sure, most are for 
boring things like looking up an API. Or random computer 
troubleshooting, or whatever. At first blush, even if those were public, 
seems relatively harmless. But sometimes I search for e.g., 
medical/health things that I'd definitely be upset if they were public. 
Of course, http doesn't mean public, but it definitely can — public WiFi 
is everywhere, for example. That alone, I think, makes https-by-default 
make sense for web searches.


But there is more. I've heard about plenty of research that it doesn't 
actually take that many search queries to get a pretty good profile of a 
person. All those queries that are innocuous taken individually when put 
together get a lot more sensitive. I'd definitely rather not share that 
info with my ISP, who of course could easily get it w/o https. (Choices 
here are Verizon and Comcast, who do you trust less to not try this and 
sell the results to the highest bidder?).


There is still more. Google results are heavily customized based on your 
past searches, and include ads based on, well, everything Google knows 
about you. Which (again, for the person defaults are targeted at) is a 
lot. So even innocuous searches can wind up including private things in 
the results. E.g., Google has at some point had results from Gmail in 
the web search results (no idea if they currently do).


We've only considered eavesdropping so far. But Google is a high-profile 
site, used by almost everyone, That makes it a very tempting target for 
active attacks — everything from ISPs injecting their own ads and 
content (not a hypothetical, even some large ISPs do this) to targeted 
attacks (e.g., when a user gets a scary security warning about running 
something from visiting Google.com, I bet "yes" is a much more likely 
answer). And of course all the attacks essentially on Google; e.g., 
inject some JavaScript to fake clicks on ads on results pages. Etc.


Finally, the cost really isn't that high...


  Yet the entire computer-using segment of society pays the
price for higher bandwidth and CPU usage.


The funny thing about forcing the deployment of HTTPS everywhere is that 
it got everyone on board with improving the protocols and 
implementations. HTTP/2 (and eventually /3) and TLS/1.3 aren't really 
that much slower than they would be w/o the encryption, modern ciphers 
are plenty fast even on fairly low-end hardware, etc. We've even made 
good progress on reducing the extra round-trips required (via session 
resumption, multiplexing, and TLS False Start). On very slow links 
(e.g., dial up modem), it's probably painful to lose link-layer 
compression... but I can't imagine how dreadful the modern web must be 
on dialup.


It's been a shame to lose web caches in some cases, too.

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

[Anthony DeRobertis]

On February 2, 2020 12:02:33 PM UTC, Simon khng  
wrote:

>Why was rsyslog used as the persistent storage instead of journald for
>previous Debian distribution?

rsyslog has been the default Debian log storage since before switching to 
systemd, possibly since before systemd existed (it was syslogd, but would have 
to check if it was rsyslog or some other implementation).

Re: migration from cron.daily to systemd timers

[Anthony DeRobertis]

On January 8, 2020 10:23:38 PM UTC, Noah Meyerhans  wrote:

>   a. If the administrator has created a file named
> /etc/spamassassin/skip-timer-conversion,

Seems to me that it'd make more sense for there to be once, system-wide file, 
instead of each package having its own. The the sysadmin can specify their 
preference once on whether to prefer cron or timers. 

I personally prefer timers, but if I didn't, then it'd be mighty annoying 
figuring out the dozens of individual use-cron flag files.

Re: migration from cron.daily to systemd timers

[Anthony DeRobertis]

On January 8, 2020 7:57:51 PM UTC, Noah Meyerhans  wrote:
>
>The big drawback of systemd timers, IMO, is that a nonzero exit code
>doesn't generate email by default the way cron does.  At smaller sites,
>anyway, this is a perfectly sensible way of being notified of problems
>with the job.

That's correct, they log the failure to the journal and/or syslog, but do not 
email. You can use OnFailure to send an email... not sure if there is a way to 
do that by default.

Also, don't think anyone has mentioned it, but "systemctl list-timers" is a 
nice advantage of timers, too. And it can actually take into account the 
randomized start delay, something no cron-equivalent could do.

Re: Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)

[Anthony DeRobertis]

You should fix the project license on GitLab, right now it's showing all rights 
reserved. That should be in the project settings somewhere... 

Also, have you seen ? That appears like it'll 
eventually allow a non-downloader package.

Re: Git Packaging Round 2: When to Salsa

[Anthony DeRobertis]

On 9/12/19 8:57 AM, Ansgar wrote:

I don't see much value in this requirement (besides additional work).
One should look at the repository anyway whan planning to do changes
(to match the existing style used); one would naturally see how files
are organized.  We already had tons of packages shipping a
README.source stating "this packages uses quilt, ..." before which I
also didn't find very valuable; this seems pretty similar.



Working with packages downstream it's nice to have that documented. 
E.g., needing to patch something for a weird site requirement, or 
backport a fix that isn't a big deal for anyone else (so likely wouldn't 
qualify for a stable update), etc. Not everyone who wants to modify a 
package is familiar with the multitude of ways of maintaining packages.


dgit makes this a lot better, though.

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Anthony DeRobertis]

On 9/13/19 7:05 AM, Simon Richter wrote:


Mandatory Encrypted SNI with no fallback option -- everything else can be
circumvented easily.

This is a game that we should not play, really. It raises the cost of
running a service on the Internet so only big players can afford to do so.


Does it? I haven't personally deployed it yet anywhere, but when I 
briefly looked into it, it appears to require adding a DNS record & some 
web server config. If anything, it appears to be harder to do if you're 
a big player (e.g., making sure your DNS servers always return matching 
ESNI and A/ records, even when you have geo-targeted DNS — so much 
easier when you only have one server.)

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Anthony DeRobertis]

On September 8, 2019 10:38:03 PM UTC, Adam Borowski  wrote:

>DoH doesn't stop ISP-based spying nor censorship. 

Firefox, I believe, already supports encrypted SNI (in nightly at least). 
Cloudflare does too. 

So fully deployed, your ISP can only tell that you're connecting to Cloudflare, 
Cloudfront, Akamai, Fastly, etc. At least when you're browsing sites using 
those CDNs. 

Trusting those parties is a huge can of worms, of course, but Mozilla has at 
least contractually limited what Cloudflare can collect and keep[1]. And the 
alternative for a lot of us is Verizon or Comcast. 

That said, ideally it'd be something that each user would be prompted about on 
first run, being given a clear description and asked if he/she wants it or not. 
But since upstream hasn't AFAIK coded that, it's not going to happen. 


[1] 
https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?

[Anthony DeRobertis]

On 8/7/19 4:14 AM, Marc Haber wrote:

Imo, there should be a possibility in a systemd timer to switch on the
"old" output-to-e-mail behavior. This is probably something that
systemd upstream would never implement, so we'd end up with a wrapper
that is called by the systemd timer unit.



You can sort of do this with a few systemd units, at least for failed 
jobs using the unit's OnFailure= action. 
https://wiki.archlinux.org/index.php/Systemd/Timers#MAILTO has details. 
That'd probably be a nice thing to ship with systemd-cron.

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Anthony DeRobertis]

On May 8, 2019 9:43:50 PM UTC, Adam Borowski  wrote:

>I just checked Stretch: not a single .bz2, either control nor data. 
>I'm not
>going to download all of Jessie just to check -- but even assuming
>something
>was left by Jessie's time, by Bullseye trying to install such a .deb
>will
>mean mixing packages 3 releases apart.

dpkg-deb is used to examine debs too, and considering Jessie is still LTS and 
Wheezy is ELTS, you may well want to examine packages from several releases ago 
on a current system. I have a weird case at work where I need to examine 
packages from as far back as Sarge and Etch through Buster, but I'd fully 
understand not supporting that. 

Some local packages can be long-lived, too. E.g., at work I have one that 
installs an internal CA. That package hasn't needed changing in a while, it 
drops a file and calls update-ca-certificates. Wouldn't be a huge deal to 
rebuild it, of course.

Re: Bug#927725: Please build with --enable-mmdblookup

[Anthony DeRobertis]

On 4/23/19 5:12 AM, Michael Biebl wrote:


My main concern is to keep the rsyslog core package reasonably small
(dependency wise).



If you check 
, 
note that a Depends is only required if "the depended-on package is 
required for the depending package to provide a significant amount of 
functionality". That, taken together with the tools typically installing 
Recommends by default, means you can make the libraries Recommends, not 
Depends. Or maybe even as Suggests.


Ideally, rsyslog would give a nice error if it fails to load a plugin 
due to a missing shared library, but even without that you can just 
mention needing to install Recommends and/or Suggests to use various 
optional plugins in the package extended description, README.Debian, etc.


(Of course, this does make the packaging a bit more complicated, since 
you'll need to add some -d options to your dpkg-shlibdeps call. Probably 
easier than even more extra packages, though.)

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

[Anthony DeRobertis]

On February 13, 2019 4:07:45 PM UTC, Ansgar  wrote:
>More importantly Jessie has reached end-of-life[1].  Please do not
>expect related suites (such as -security, -backports, -proposed-
>updates, -updates) to continue working after this.

-security and -updates are part of the LTS sources.list on 
https://wiki.debian.org/LTS/Using so ought to stick around until 2020, at least 
for some architectures (not arm64, though).

Re: Handling of entropy during boot

[Anthony DeRobertis]

On 1/14/19 7:07 AM, Thomas Goirand wrote:

On 12/18/18 8:11 PM, Theodore Y. Ts'o wrote:

If you are firmly convinced that there is a good
chance that the NSA has suborned Intel in putting a backdoor into
RDRAND, you won't want to use that boot option.

I have read numerous times that some people trust this or that part of
the instruction set, and I always found it silly. Why should some
instruction or part of the Intel CPU be more trusted? To me, either you
trust the entire CPU, or you just don't trust it at all and consider
using other CPU brands. Am I wrong with this reasoning?


I think the idea behind that is that the rest of the CPU has defined, 
verifiable behaviors. If NSA makes 1+1 sometimes equal 3, then that's 
detectable. So it'd be a fairly risky attack, someone might notice it. 
It also risks that other countries' NSA-equivalents make use of the 
backdoor.


OTOH, the RNG is not verifiable. It's supposed to take two entropy 
sources and apply AES to them to combine them. But how do you know it 
actually did that? You can't tell what the input to AES was, at least as 
long as AES remains secure. It could well be giving you the equivalent 
of 1, 2, 3, 4, etc. encrypted with a key known only to NSA. And there is 
much less risk of another country taking advantage as the numbers still 
are fully CSPRNG — to everyone but NSA.


(Also, see Dual_EC_DRBG)

Re: Sending using my @debian.org in gmail

[Anthony DeRobertis]

On 11/30/18 6:18 PM, Paul Wise wrote:

I've experienced spammers brute-forcing SMTP submission credentials
and using that to send spam before, so I think that mitigating that
using client-side TLS certs should be required, just as we do for SSH
access to Debian machines. I'm not sure how many MUAs support that but
MTAs do so using a local MTA to forward messages could be a
reasonablish workaround.


That honestly sounds like building a parallel system with at least as 
much complexity as gpg, just to prevent a largely non-existent problem 
(forged emails — the whole thread has been about its possible, but no 
reports of it happening). Of course, gpg is also a better (from a 
security standpoint) and more widely-supported solution. Which is 
already deployed in Debian.


Though, for the record, it appears both Mutt and Thunderbird support TLS 
client certificates.


Or you could just require strong passwords :-/

Re: dpkg path-exclude

[Anthony DeRobertis]

On 09/15/2018 09:41 AM, Marc Haber wrote:

Can you share some command lines and/or scripts and/or configuration
files please?


This is what I use for a few Docker image builds:

   $ cat /etc/dpkg/dpkg.cfg.d/10local-exclude
   path-exclude=/usr/share/doc/*
   path-exclude=/usr/share/man/*
   path-include=/usr/share/doc/*/copyright
   path-exclude=/usr/share/locale/*
   path-include=/usr/share/locale/en/*
   path-include=/usr/share/locale/en_US/*

and it seems to work fine. They're processed in order, so that excludes 
all the documentation except the copyright file, as well as locales we 
don't use, and manual packages (no need for in a Docker image). This 
works at least as far back as Wheezy.

Re: gnucash status

[Anthony DeRobertis]

It appears to be fixed in experimental, which has 3.0. Presumably that'll hit 
unstable when the maintainer feels it's ready. 

It appears the the BTS's version tracking may not have fully realized what was 
going on, explaining why it's closed and archived.

Re: missing recommends are not RC severity

[Anthony DeRobertis]

On 04/17/2018 09:21 AM, Jeremy Bicha wrote:

"It is my understanding that is a RC bug for package to recommend a
library that has been removed from Testing because recommended
packages won't be auto-removed on upgrade."


Neither will Suggested: packages, by the way, depending on 
APT::AutoRemove::SuggestsImportant (which defaults to true), at least 
according to [1]. At least in Aptitude; not sure about other frontends. 
So that doesn't seem like a reason for RC-ness.


Main is supposed to be self-contained, though; so if a package barely 
works or loses most of its functionality without non-main software, 
that'd seem RC. If it's just one feature, though, not sure it really is 
— though maybe it should be a Suggests and not a Recommends.


[1] https://www.debian.org/doc/manuals/aptitude/ch02s05s05.en.html|
|

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Anthony DeRobertis]

On 12/27/2017 05:06 AM, Paul Wise wrote:

Does anyone know if there is a tool similar to github-backup that
supports gitlab?

I haven't confirmed its available on salsa.d.o, and its unfortunately 
only one project at a time, but GitLab has an export under Project 
Settings→General.

Re: Bug#882723: src:keepassxc: Generated file without preferred form of source: src/zxcvbn/dict-src.h

[Anthony DeRobertis]

On 11/26/2017 02:38 PM, Sean Whitton wrote:


However, the preferred format of modification is in fact present in the
zxcvbn-c source package, which builds dict-src.h as part of its package
build.  So I wonder if you could refer to that package in README.source
and it would be enough for the ftp-masters?


That's fairly fragile, e.g., if a new version of zxcvbn-c comes out, the 
source (may) not be there any longer. That'd create an unexpected and 
surprising (at least to zxcvbn-c's maintainer) failure to meet the 
social contract.


I'm not sure if that (possibly very unlikely) chance is worth repacking 
the tarball or not. Or if ftp-masters will see it as required.

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

On Fri, Oct 27, 2017 at 01:00:58PM +, Holger Levsen wrote:

> recommends wont work, they arent installed on upgrades…

I haven't tested it, but at least according to apt's changelog new
recommends are installed on upgrade as of 0.7.0 as log as
APT::Install-Recommends is true, which has been the default since
0.7.17. So unless the changelog lies, recommends have been installed on
upgrade since 05 Nov 2008.

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

On Fri, Oct 27, 2017 at 10:01:18AM +0200, Mathieu Parent wrote:

> Could'nt we:
> 
> 5. Make linux-image-$abi-$arch Depends on apparmor | selinux-basics |
> tomoyo-tools | linux-no-lsm
> 
> With linux-no-lsm being a new empty package, and all of apparmor,
> selinux-basics, tomoyo-tools enable the corresponding LSM.

I don't think there is a good way to guarantee which alternative there
apt picks. It could pick to install linux-no-lsm for example (and who
knows, maybe due to fewer dependencies, or a conflict, or whatever, it
will). Even if it works today, that seems fragile...

Also, a Depends: with one of the alternatives being "don't install
anything" strikes me as a hack to work around not having Recommends or
Suggests — but we do have those, so I'm not sure why we wouldn't use
them instead.

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

On Fri, Oct 27, 2017 at 08:57:26AM -0400, Jeremy Bicha wrote:
> On Thu, Oct 26, 2017 at 11:29 PM, Anthony DeRobertis
>  wrote:
> > 3. Have a Recommends or Depends on it from another package that is
> > installed. (Presumably that'd be a Recommends from the linux-image-*
> > packages, and would be dropped down to a Suggests for buster+1).
> 
> Why shouldn't it stay a Recommends for Bullseye (buster+1) too?

Because for Bullseye, it'll already be pulled in (during the Buster
upgrade) or during the install (as both the Buster and Bullseye
installers will install it). So there is no longer any reason to inflate
the importance — the kernel runs just fine w/o and doesn't lose any
major functionality.

Normally it'd only be a Suggests (if anything), but Suggests won't pull
the package in on upgrade.

Re: Let's enable AppArmor by default (why not?)

[Anthony DeRobertis]

I think the only two ways to get a new package installed upon stretch → 
buster are:


1. Suggest the admin do it in the release notes. (It should be 
documented in the release notes no matter which option we pick, of course.)


2. Suggest the admin do it in a NEWS.Debian entry (but it needs to be an 
upgraded package, not a new one, else it won't be displayed. So the 
linux-image-4.* packages won't work, but e.g., linux-image-amd64 would).


3. Have a Recommends or Depends on it from another package that is 
installed. (Presumably that'd be a Recommends from the linux-image-* 
packages, and would be dropped down to a Suggests for buster+1).


4. Suggest the admin do it in a debconf note. Highly discouraged nowadays.

All of those except #1 also work for folks following testing or unstable.

Personally, I don't have a preference between #1 and #3, as long as we 
find some reasonable way to opt-out if we go with #3 (and document it in 
the release notes).


On 10/26/2017 11:02 AM, intrigeri wrote:

Hi,

intrigeri:

tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
and decide one year later if we want to keep it this way in the
Buster release.

Thanks a lot to everyone who participated on this thread, tried
AppArmor and reported bugs, or expressed support/interest privately!

Summary of the discussion: no strong objection was raised; quite a few
potential issues were mentioned; the most serious ones were either
resolved already, or in good way to be resolved in the next 2 weeks.
So, my understanding is that we have a broad consensus and can start
the proposed experiment.

I need advice from you folks on one specific matter, see below.


1. Enable AppArmor by default in testing/sid as soon as feasible in
the Buster cycle.
I can think of several possible ways to do it but for now I'd
rather focus on the "do we want to do it at all" conversation.

It's now time to discuss the "how" aspect.

Enabling AppArmor by default requires two changes:

1. enabling the LSM in Linux: problem solved, Ben Hutchings agreed
we should do this in src:linux, at least for the time being;

2. installing the apparmor package by default: it ships the bits of
code that load AppArmor policy during boot and some shared bits of
policy that most other AppArmor profiles rely upon.

This email is about (2). There are two aspects to it.

For new installations, it seems that making the apparmor package
"Priority: standard" is the way to go. I've asked debian-boot@'s
opinion about it [priority:standard?] but the rest of our developers
community is of course welcome to comment as well.

For upgrades it seems much more complicated. Ideally I would like the
apparmor package to be installed automatically:

  - on testing/sid upgrades, during the Buster dev cycle: this would
greatly increase the value of the "enable AppArmor by default for
a while" experiment as we would get lots more data to reason about
when the time comes;

  - during Stretch to Buster upgrades: this seems necessary so every
user gets the AppArmor benefits, regardless of when they installed
their system initially.

I also want to provide easy means for users to opt-out from
the experiment.

I've requested advice on this topic from a few fellow Debian people
and the conclusion seems to be:

  - I was told essentially "we generally don't do that in Debian" by
a few people who suggested me asking this mailing list.

I don't understand the rationale though — during system upgrades we
do change the distro behavior in many ways: we add new features, we
enable new security measures, we switch init systems, we switch
from MySQL to MariaDB and all sort of things — so it's not obvious
to me why doing the same to enable a security system like AppArmor
would be a Bad Thing™.

Is the concern specifically about doing so by pulling a new
package in?

Or is it specifically about enabling a LSM that was previously
disabled? (Any such big change brings a risk of introducing
regressions, so the underlying questions seem to be "is the risk
worth it? is the risk well managed?")

  - We have no better option to achieve that than having another
package, that's already installed by default, add a "Recommends:
apparmor". This feels artificial and rather ugly, but it might be
the only option. I don't know which other package would be the most
suitable to add this dependency. Any suggestion? Any other idea?

I'd love to read your thoughts about this. Let's discuss it.

[priority:standard?] https://bugs.debian.org/879590#25

Cheers,

Re: New package, name recycling

[Anthony DeRobertis]

It's still in a supported release (Jessie), two of you count LTS (wheezy). 
Reusing that name should probably wait until Jessie is out of LTS support 
otherwise there will be conflicts at least with the security tracker.

Re: Help, I broke sso.debian.org for chrome

[Anthony DeRobertis]

On Tue, Sep 05, 2017 at 02:08:38PM +0100, Ian Jackson wrote:
> 
> FYI, Enrico, the openssl CLI tool can dump this kind of thing so you
> can compare before and after.  I forget the exact runes I'm afraid.

openssl x509 -in <> -noout -text

is probably the magic line you're looking for.

Re: Whether remotely running software is considered "software" for Debian.

[Anthony DeRobertis]

On 08/29/2017 03:25 AM, Carsten Leonhardt wrote:

Actually, I haven't seen anyone citing the following part of policy
2.2.1: "None of the packages in the main archive area require software
outside of that area to function."

If we agree that "functioning software" does more than print an error or
a usage note, this part makes it rather clear where free client software
to non-free server software belongs.


It also would apply to anything where the server isn't packaged (in 
main)—whether or not a free server exists.. The plain wording of Policy 
requires that the server (if it's required for the client to operate) 
not only be free, but also be packaged in main.


That clearly doesn't match historical or current practice.

Policy is not the Social Contract, Policy is not the Constitution. 
Policy can be relatively easily changed and is supposed to largely 
document actual practices. So really, Policy needs to be amended. And 
attempting to language-lawyer Policy like this is pointless.

Re: A radically different proposal for differential updates

[Anthony DeRobertis]

On 08/15/2017 08:00 PM, Peter Silva wrote:

Isn't there kind of a universal issue that tar and compression happen
sort of in the wrong order?  Wouldn't it make more sense to make files
that were .gz.tar (ie. compress the files individually, then have an
index into them via tar.)


That way gives a lower compression ratio, especially when you have a 
bunch small, similar files. E.g., something that ships a lot of C header 
files. Or a bunch of plain text files.


Also of course there don't exist any good tools to create or extract 
such archives, but that could be fixed (afio exists, but it's non-free).


Also—if I'm remembering correctly, tar has no table of contents, I think 
listing a tar file is done by reading all the individual file headers, 
which are spread throughout the file.

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

[Anthony DeRobertis]

On 07/14/2017 08:01 PM, Russell Stuart wrote:

(b) Those who enter the debian device names manually into config
 files, and have machines that network device names even though
 no one armed with a screw driver has been near the thing.
 These people would very much care.  I was asking whether they
 exist.  So far I've seen person say they are one.


Then let me add myself to that list. I have a couple of firewall-routers 
at work, which have both onboard and PCI Ethernet cards. The onboard and 
PCI cards use chips from different companies, thus different drivers. So 
whether the first onboard port or the first PCI port becomes eth0 
(according to the kernel) depends on which module loads/initializes 
first. That changes each boot. (Or at least it did last time I checked).


I think the same is true for the mid-tower at home that's my home server 
& firewall—I wanted more ports, so I added a card. So the kernel order 
will again depend on module load/init order.


However, the new fixed names don't matter to me—I've always set custom 
names (not just on these machines, but most machines with multiple 
NICs). I rename the interfaces things like "lan", "dmz", "comcast", 
"verizon", etc. depending on what's connected to the port.


OTOH, my laptop runs Network Manager. I don't really care what the 
interfaces are called there, or if they're stable. Though it's a slight 
pain when I need to troubleshoot something and am faced with a long USB 
WiFi adapter interface name. (Actually, I set up teaming in Network 
Manager, which seems to require stable names hard-coded in the JSON 
config field—so this isn't quite true any longer. But let's ignore this, 
as I presume it's either due to me missing something or a feature that 
isn't yet 100% done in Network Manager)

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

[Anthony DeRobertis]

On 07/11/2017 03:08 PM, Nikolaus Rath wrote:


I wonder if anyone actually uses /dev/disk/by-path?


It's useful for a quick "ls -l /dev/disk/by-path | grep 'sda$;" to 
figure out which port a disk is plugged into. I'm sure there are other 
ways, probably better ones... but that one is easy to remember when I've 
been paged by a disk failure.


Also useful to make sure all the ports on an array are being e.g., 
monitored, even after changing a disk (which of course changes the 
/dev/disk/by-id/). Of course, a lot of times just doing all devices 
instead makes sense.

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

On Fri, Jun 09, 2017 at 03:21:25PM +0100, Ben Hutchings wrote:
> On Fri, 2017-06-09 at 03:02 -0400, Anthony DeRobertis wrote:
> [...]
> > firmware-linux Recommends: amd64-microcode
> > firmware-linux-nonfree Recommends: amd64-microcode
> > 
> > This machine has an Intel CPU. It should probably recommend
> > intel-microcode | amd64-microcode instead of both. Though we are
> > talking about an Installed-Size of 68 here.
> [...]
> 
> Then APT would never automatically install amd64-microcode.

True. Apt doesn't really have a good solution to that. The only thing
I've seen is 

Recommends: cpu-microcode-all | cpu-microcode

and having a cpu-microcode-all package that Depends on both, and having
the two real package Provides cpu-microcode. If I remember correctly,
Xorg did this at one point for video drivers (maybe still does).

Of course—for the under 100K being saved here, only Rube Goldberg would
approve.

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

Using you script, it doesn't seem to be too bad. I went through a few 
machines:



I went through the ones on my desktop here (running testing). Excluding 
non-Debian packages, I found:


blktrace Recommends: libtheora-bin, libav-tools, librsvg2-bin

   I suspect these are required for iowatcher (one of the three tools
   in the package) to run. I personally just use blktrace and blkparse;
   I think it's reasonable if the maintainer considers iowatcher
   important as well. But it is a huge dependency chain, especially for
   libav-tools (which nowadays is a transitional package for ffmpeg).


firmware-linux Recommends: amd64-microcode
firmware-linux-nonfree Recommends: amd64-microcode

   This machine has an Intel CPU. It should probably recommend
   intel-microcode | amd64-microcode instead of both. Though we are
   talking about an Installed-Size of 68 here.


geoclue-2.0 Recommends iio-sensor-proxy, modemmanager, wpasupplicant

   My desktop has none of this hardware. Network is wired Ethernet. It
   does have temperature sensors, though I doubt the CPU temperature is
   too useful for finding my location. (Given, geoclue is probably
   pretty useless on my box.)


get-flash-videos Recommends: get-iplayer

   I don't live in the UK, and AFAIK iplayer is geo-restricted to the UK.

vlc Recommends: vlc-plugin-samba (and a few others)

   Note this plugin is only needed to access Samba shares that aren't
   mounted (it's samba client in userspace). Seems like it's perfectly
   reasonable to only play mounted videos, or ones from network
   streams. VLC has a few more plugins in Recommends that I have installed.


There are various packages that Recommends: their -doc packages; those 
probably sense if you've installed them directly, but are annoying when 
the package has come in as a dependency.


There are of course a bunch more unsatisfied recommends, but they don't 
strike me as weird (e.g., where I've elected not to install -i18n packages).




On a home server, running Jessie—the script failed ("AttributeError: 
'Dependency' object has no attribute 'installed_target_versions'"). I 
don't know enough (any) Python to fix it.



On another desktop (at work) running testing (and ignoring ones already 
mentioned above):


hplip Recommends: sane-utils

   Printer is just a printer. Doesn't have a scanner.

libsane Recommends: sane-utils >= 1.0.25-4.1

   Don't have a scanner. (libsane is pulled some Depends). AFAIK -util
   is some programs to use SANE, not things called by the library.

openvpn Recommends: easy-rsa

   Unsure about this one. I have it a bunch of places, but the average
   person probably doesn't want to use the OpenSSL command line. Though
   certificate management is a once every X years problem, except on
   your CA.

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

On 06/01/2017 01:00 PM, Henrique de Moraes Holschuh wrote:


Anything on the top three priorities (critical, alert and emergency) is
supposed to be displayed immediately to all logged-in users (including
remote ones), no matter what.


Only LOG_EMERG does that, at least on my machine and I'm pretty sure 
that's the default rsyslog config. Unfortunately, a RAID member failure 
is only legitimately LOG_ALERT. Sort of a moot point though...





It would be great it we had an alert program to use instead of email

KDE displays high-priority system alerts as high priority notifications
by default (maybe some of it because of the default configuration of
rsyslog).


Running KDE here, so familiar with them. The first problem with those is 
they automatically vanish after a few seconds. They remain around, if 
you pull up the alert notifier, but that little (1) in the systray is 
easy to miss.


Second problem is that only works if you're logged in. Even on a typical 
desktop where the main user is the admin, it's not safe to assume a that 
user will always be logged in:


 * Turn on machine, go grab coffee or tea while it's booting. Disk
   failure occurs before you get back and log in.
 * Log out for the night, but leave it on for e.g. backups, file
   serving, or remote access
 * Log out so your kids can use the machine

Third problem, syslog imposes some pretty severe format restrictions on 
the message. An alert sent via email can have a lot more details & 
instructions than a syslog message.


Using a machine as a home media server (e.g., a NAS) is a reasonably 
common thing too—then it'll hardly ever have a local logged in user.


You can surely configure rsyslog to get that alert to you anyway. 
(Probably using ommail!). But that's no easier than configuring outgoing 
email.

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

On May 31, 2017 2:38:51 PM EDT, Nicholas D Steeves  wrote:

>
>Maybe exim should easily provide or default to authenticated smarthost
>(satellite) configuration and /etc/aliases should be configured to
>forward system mail somewhere else (eg: the sysadmin's work email, in
>case of SMART or md errors)?

I believe exim used to ask, via debconf, the user to configure email and that 
was one of the options (not sure if the debconf prompts would set up 
authentication for you, or if you had to edit one trial format config file as 
well). But the priority of those questions was lowered so now by default you're 
left without configured email.

That did reduce the number of questions asked for the default install—a 
worthwhile goal, I think. 

I don't think there is any way to configure mail to go to a non-local sysadmin 
email account without asking questions, unfortunately. Some of those questions 
are going to be confusing ("what is a smarthost? Sender rewriting?") or 
problematic (if you're installing on your primary computer, do you have email 
username and password readily available? what if it's Gmail, and you now need 
to go set up an app-specific password, or turn on SMTP? Hard to do from the 
installer.) 

Once you've got the system up, though, dpkg-reconfigure -plow exim4-config 
ought to get it set up. 

PS: there have been many discussions about changing the default MTA or dumping 
it all together on -devel.

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

On May 31, 2017 3:51:33 AM EDT, Simon McVittie  wrote:
>On Wed, 31 May 2017 at 00:20:18 +0000, Anthony DeRobertis wrote:
>> AFAIK, mdadm's default (and maybe only supported, without some custom
>> scripting) way to report a degraded array is email.
>
>Can't it report this via the system log? (syslog, systemd-journald)

The kernel already does, but of course the system log has a lot of messages, 
every several seconds on some systems. And the systemd journal can be even 
worse, volume-wise. 

Logs are great for figuring out what happened after the fact, but what it needs 
is an alert. Immediate action must be taken, data is at risk. 

It would be great it we had an alert program to use instead of email (and that 
program would make sure the user/admin is aware via persistent desktop alert, 
email, whatever). I think it's been discussed before... If we had one, it'd be 
relatively easy to have mdadm, smartmontools, etc. use it. 

>
>> OTOH, seems weird for Dracut to recommend mdadm. Surely a system
>> booting from RAID would already have it installed?
>
>dracut defaults to creating a general-purpose initramfs that is not
>meant
>to hard-code anything and can be used to boot "most" hardware 

I'm not really familiar with Dracut, but I'll note that needing mdadm is almost 
always a property of the OS install being booted, not of the hardware it's 
running on. So not including mdadm doesn't make the particular install any less 
portable, though it does make the initramfs less general to booting arbitrary 
installs.

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

AFAIK, mdadm's default (and maybe only supported, without some custom 
scripting) way to report a degraded array is email. That's definitely an 
important feature as not noticing a degraded array will result in complete data 
loss (well, or at least restore from backup). 

OTOH, seems weird for Dracut to recommend mdadm. Surely a system booting from 
RAID would already have it installed? 

On May 30, 2017 7:57:03 AM EDT, Ansgar Burchardt  wrote:
>Hi,
>
>my impression is that too many packages use Recommends that should
>really be Suggests.  As a random example: installing dracut as a
>initramfs provider will pull in exim4... (dracut-core Recommends: mdadm
>which Recommends: default-mta | mail-transport-agent).  This seems
>really not ideal.
>
>As a result many people seem to disable installing recommended packages
>by default.  I believe we should be much more agressive in downgrading
>dependencies to Suggests.
>
>For example, very few packages should Depend/Recommend a MTA: if you
>just send notifications (like mdadm), you would need a properly
>configured MTA anyway or they just end up in a file nobody will ever
>look at (I don't see local mail to root as very useful).
>
>I suggest that only very few packages should Recommend a MTA: packages
>that mainly deal with mail on servers in some way or another (for
>user-facing applications, speaking SMTP to a remote SMTP server is
>common enough that these shouldn't Recommend a MTA usually either).
>
>Ansgar

Re: Keysafe dynamic UID

[Anthony DeRobertis]

On Sun, Oct 23, 2016 at 04:59:20PM +0200, Guillem Jover wrote:
> 
> Also renaming a user is actually trivial:
> 
>   usermod -l _something Debian-something
> 

Unfortunately those names also get into various cron tabs, config files,
etc. Doing that with, e.g., Debian-exim would immediately break my mail
server, for example.

I wonder if just adding a second user with the same uid would be safer
(so then the packaged scripts can use the new name), and documenting
that the old one will be removed for the next release?

(Also, I haven't tested: does that properly handle group memberships?)

Re: Bug#822221: ITP: flipcoin -- flip an adjustable coin for random exit status

[Anthony DeRobertis]

On 04/22/2016 08:45 AM, Jakub Wilk wrote:



 memset(&maxInt, 0xff, sizeof(maxInt));


"maxInt = -1" is would be a more obvious way to write it, IMHO.


Both pale in comparison to UINT32_MAX, also found in .

Re: Favoring systemd timers over cron files Re: Removing sysV init files

[Anthony DeRobertis]

On 01/15/2016 09:29 PM, Jens Reyer wrote:
Does this also work somehow for e.g. foo-daily.service + 
foo-daily.timer being favored over /etc/cron.daily/foo? Next to a 
foo.service being favored over /etc/init.d/foo. Thanks and greets jre 


No, it won't work automatically. Cron doesn't look at systemd units. You 
could of course put something like this at the top of your 
/etc/cron.daily/foo:


   if [ -d /run/systemd/system ]; then
exit 0;
   fi

Re: Automatic dbgsym packages built by default as of today!

[Anthony DeRobertis]

Are there plans to teach httpredir.debian.org about the new debug mirror
network?

http://httpredir.debian.org/debian-debug/dists/unstable-debug/main/binary-amd64/Release
 is currently 404.

Re: PCRE package naming

[Anthony DeRobertis]

On 10/22/2015 10:47 AM, Matthew Vernon wrote:

The natural thing to call the PCRE2 packages is pcre2, but that's going
to lead to confusion - ISTM that something that makes it clear that
PCRE2 is newer than PCRE is desirable. And, obviously, PCRE & PCRE2 need
to be co-installable.


There are already libpcre16-3 and libpcre32-3 packages. That doesn't 
seem to have lead to confusion. Quite possibly because libpcre* is 
normally installed by apt automatically as a dependency, so the vast 
majority of users don't need to think about the package name.


Seems like the developers who are going to install -dev package could be 
helped by something in the short & long description. E.g., something as 
simple as putting "Old" and "New" in front of the short description, and 
then explaining in the long description.


And the pcregrep package doesn't have a 3 in it currently, so it's not a 
problem.

Re: certificate creation in postinst, potentially using letsencrypt script

[Anthony DeRobertis]

On 08/05/2015 07:11 AM, Thorsten Glaser wrote:

Bas Wijnen  debian.org> writes:


Certificates are placed in /etc/ssl/certs/.

No, in /etc/ssl. /etc/ssl/certs/ is for Root CA certificates *only*.


(sorry for responding to a very old message)

Really? I've often put the local machine's cert(s) in there. The private 
key goes in private, and the certificate in certs.


That's also how, for example, the autogenerated snakeoil cert works. 
That's where make-ssl-cert puts it.


If this isn't how its supposed to be used, that's surprising, and 
especially if its actually a security issue, ought to be documented in 
at least one of:


 - a README in /etc/ssl/ or /etc/ssl/certs
 - man update-ca-certificates
 - /usr/share/doc/ca-certificates/README.Debian
 - /usr/share/doc/openssl/README.Debian
 - bug #26406 (just kidding)

all of which I checked, and they either don't exist (that first one) or 
don't say to only put CA certs in /etc/ssl/certs.


And as noted above, ssl-cert puts the default snakeoil certs there—so 
that's the path you see in, e.g., shipped config files. Which naturally 
suggests to the admin that's where they belong.

Outdated mirror in http.us.debian.org

[Anthony DeRobertis]

http://35.9.37.225/debian/dists/testing/main/binary-amd64/ show this 
mirror hasn't updated since the 19th, but its still in the 
http.us.debian.org rotation.



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

Re: How to detect if inside a buildd chroot

[Anthony DeRobertis]

Roger Leigh wrote:
> You can't reliably (or portably) check if you are in a chroot. 
Hmm, if you're root you probably can. Something like this (completely
untested; probably doesn't even compile):

DIR *d;
int fd;
struct stat s1, s2;

mkdir("temp", 0700);
d = opendir("/");
fd = dirfd(d);
fstat(fd, &s1);

chroot("temp");
fchdir(fd);
stat("..", &s2);


if (s1.st_dev != s2.st_dev || s1.st_ino != s2.st_ino) {
/* we were in a chroot */
}
  

Actually, come to think of it, I wonder if stat'ing "/.." would work...
If it does, then you don't even need root.


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

Re: Etch Software RAID Upgrade Trouble & Suggested Installer Improvements

[Anthony DeRobertis]

Alexey Feldgendler wrote:
>
> cp -avx --preserve=all 1/* 2  # rsync will do as well 

Of course, 1/* misses any dot-files in 1.


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

Re: Ondemand governor by default in etch

[Anthony DeRobertis]

Matthew Garrett wrote:
> p4-clockmod is entirely useless. It's high-latency and doesn't drop the 
> core voltage.

Nice. Is there a good alternative for P4 machines? Is the ACPI one any
better (assuming a semi-sane BIOS)?


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

Re: Ondemand governor by default in etch

[Anthony DeRobertis]

On Thu, Dec 07, 2006 at 09:36:29AM -0600, John Goerzen wrote:
>
>  * Will cause negligible impact on system performance.  ondemand seems
>to have the philosophy of "max system speed unless I can be shown
>that the system is pretty much idle"

This isn't true on this machine here. Enabling it has the following
effects:
1) it slows the CPU down to the point where I can watch the title
   bars of windows redraw step-by-step when I move the mouse over them
2) according to the power meter in my UPS, saves approximately 0W
   (yes, zero) of electricity.
3) lets the chip run approximately 0°C cooler.

vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 1

analyzing CPU 0:
  driver: p4-clockmod
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 375 MHz - 3.00 GHz
  available frequency steps: 375 MHz, 750 MHz, 1.13 GHz, 1.50 GHz, 1.88 GHz, 
2.25 GHz, 2.63 GHz, 3.00 GHz

OTOH, it works absolutely great on AMD64 chips.


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

Re: Question about "Depends: bash"

[Anthony DeRobertis]

Michelle Konzack wrote:
>
> I do not know a singel person which open 20 xterms with bash at the
> same time.  On my IBM i have normaly 4-6 XTerms open, mozilla and gaim.
>   

That's nice. ps/grep/wc shows I have 27 xterms, all with bash running,
open at the moment. Of course, I have far more than a PII w/ 64M of RAM.

And, of course, iceweasel uses more memory than all the xterms and
bashes combined. Oddly enough, gaim is even bigger(!)


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

Re: Proposed new POSIX sh policy, version two

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:

> Somebody needs to explain to Jari the concept of a shared text segment.
>   

Bash:

[EMAIL PROTECTED]:~$ grep 'Private_Dirty' /proc/$$/smaps | perl -e '$t = 0; 
while (<>) { /(\d+) kB$/ or die "parse err: $_"; $t += $1 } print "tot: $t\n"'
tot: 2800


Dash:

$ grep 'Private_Dirty' /proc/$$/smaps | perl -e '$t = 0; while (<>) { /(\d+) 
kB$/ or die "parse err: $_"; $t += $1 } print "tot: $t\n"'
tot: 84


Indeed, checking /proc/pid/status, we find bash's VmData is a mere 16
times larger than dash's.

Something tells me that 2.8MB * 20 could indeed be a problem on a 64MB
system.


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

Re: Downgrading the priority of nfs-utils

[Anthony DeRobertis]

Matthias Julius wrote:
> I would guess that most people who install a linux system don't need
> NFS.
>   

Donno. I use it on all my systems, home and otherwise; how else would I
mount file servers...

> And actually, NFS us not required to run Debian.  Do I don't think it
> needs to be in the default installation even if 70% of the users will
> use it. IMHO
>   

I think you've misunderstood the purpose of the default installation.
It's not the bare minimum to make the system work (that's Essential:
yes). It's the standard stuff that everyone expects to be on a UNIX
system, including things like a working c & c++ compiler, etc. 70% of
users using something is, IMO, a very strong argument for it to be
installed by default.

(Remember: installed by default does not mean you have to install it. It
just means if you don't manually select packages, it will be installed).


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

Re: Bug#396117: ITP: cpufreq-detect -- detect CPU frequency control driver

[Anthony DeRobertis]

Mattia Dongili wrote:

> Yes, p4-clockmod is mostly useless for power saving but it helps
> reducing the processor temperature. And this is the only driver working
> for my p4 desktop.
>   

Odd. I was unable to measure any temperature reduction either.



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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Anthony DeRobertis]

Bruce Sass wrote:

> I don't think that disqualifies it as a solution, it just means there 
> would be a transition period while users learn that it is a required 
> part of messages sent to the BTS.

Yes it does. People other than Debian developers mail
[EMAIL PROTECTED] Heck, people who are not even Debian users
legitimately use [EMAIL PROTECTED] Example: upstream software authors.


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

Re: "Arch: all" package FTBFS due to test needing network access - RC?

[Anthony DeRobertis]

Lucas Nussbaum wrote:

> Some packages (e.g choose-mirror) fetch a newer version of a file during
> build if it's possible to fetch that file. I don't think this is RC,
> since the file is not missing from the package if the network is not
> available.
>   

In general, I strongly suspect that fetching updated source during build
is RC due to a violation of the Social Contract: the source we are
shipping intentionally does not correspond to the binary package.

I'm not sure if the above applies to choose-mirror. In particular, if
the file shipped in the binary is its own source, then it doesn't.
However, I'd still say it's bad idea, and a bug (maybe even RC). Some
more general reasons (not all necessarily apply to choose-mirror)

* changes to the package are not reflected in the changelog
* random network or remote server issues can cause a broken (or
  worse) build. What happens if the file on the server is corrupted?
* builds are no longer repeatable. Different source may even wind up
  built on different architectures.
* the package is much harder to NMU. What should be a spelling fix
  suddenly becomes a large change (due to the automated source
  pull), unbeknown to the NMU-er. Same problem for the security team.
* the supposedly-signed source package isn't really; it's pulling
  unsigned source for the build

Also, depending on what is being downloaded from the network, there
could be security issues. What happens if the server is compromised?


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

Re: Bug#396117: ITP: cpufreq-detect -- detect CPU frequency control driver

[Anthony DeRobertis]

Peter Palfrader wrote:
> How come it never outputs p4_clockmod?  I use that happily on several
> different machines.
>   

I can confirm I've tried it on a machine. The performance impact was
substantial (at least if I allowed it to go to its lowest speed); the
power consumption difference was immeasurable[0].

Have you actually measured the power savings?



[0] Immeasurable as in the measurement equipment (an UPS with load
indication, in this case) could not notice any difference. The same UPS
does notice a substantial difference with K8 chips.


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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Anthony DeRobertis]

Bruce Sass wrote:
> I have yet to see a spam message sent to the BTS which used a "Package:" 
> pseudoheader, so that should work to eliminate BTS spam without 
> preventing non-DD's helping out.
>   
OTOH, a /lot/ of legitimate mail is sent to the BTS w/o a Package:
pseudo-header (think: pretty much anything to [EMAIL PROTECTED]).
So this isn't really a solution.


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

Re: Orphaning most of my packages

[Anthony DeRobertis]

Steve Greenland wrote:
> Bug#392672: O: positron - synchronization manager for the Neuros Audio
> Computer Python. Probably dead after v1.1. Pierre Habouzit has NMU'd a
> version 1.1 upgrade and support for new python policy, see bug # 380895.
I can confirm that Positron is dead. Not only is it dead, it isn't
compatible with newer Neuros firmware. Sorune (Perl) and NDBM (Java) are
the two not-dead replacements.

I suggest removal.


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

Re: new mplayer

[Anthony DeRobertis]

Yavor Doganov wrote:
> I was wondering, what's so important about mplayer?  With totem and
> vlc (and I anticipate there's something similar for KDE) you have
> everything you need. 

Not true. Mplayer is the only one with proper support for ASS subtitles.


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

Re: how to deal with packages depending on mysql-server

[Anthony DeRobertis]

Bastian Venthur wrote:
> What is the preferred solution for this kind of problem?
>
>   


I've heard rumors that packages have a Description: field which could
probably contain a note along the lines of:

WordPress requires access to a local or remote MySQL server. If you
wish to run the server locally, additionally install the
mysql-server package.


of course, the rumors of the Description: field's existence could be false.


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

Re: cdrtools

[Anthony DeRobertis]

Erast Benson wrote:
>
> I do not need to make the build system 
> available under GPL (GPL §3 requires me to make it available but does
> not mention a license) 

GPL 3(a) requires the "complete corresponding source code [be]
distributed under the terms of Sections 1 and 2 above". GPL 3
defines the source code to include the "the scripts used to control
compilation and installation of the executable."

Section 2(b) requires third parties to publish derived works under the
GPL ("to be licensed as a whole at no charge to all third parties under
the terms of this License."). Section 2 also states "[T]he distribution
of the whole must be on the terms of this License, whose permissions for
other licensees extend to the entire whole, and thus to each and every
part regardless of who wrote it."


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

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Anthony DeRobertis]

Marco d'Itri wrote:
> Bullshit. The only criteria for defining freedom for the purposes of
> Debian *is* the DFSG.

Under a strict reading of the DFSG, I'm not sure how a license that
prohibits running the code would fail.


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

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Anthony DeRobertis]

Matthew Garrett wrote:
>
> Ok, but it still needs to be modified. Are you suggesting that the 
> freedom to produce a binary that can't be recompiled by anyone else is a 
> necessary freedom?
>
>   

I haven't read the license, and I suggest asking on -legal if you want a
full analysis, but the general problems of clauses like that are:

* Have to distribute source to people I never distributed binaries
  too. So I can't make private modifications for a friend (and give
  source only to him). Nor can I make modifications interesting only
  to my organization (say, to make it run in a special environment
  unique to my organization) unless I distribute source (which is
  useless to anyone else, and which is probably a fair bit of
  additional work to distribute, especially if I don't already have
  a website to do it from.
* Because I must publicly distribute source, I can not secretly use
  the software. While there is unlikely to be any problem with my
  use of a compiler being known (well, at least not today), in other
  cases this could be a problem: Crypto software, DMCA-circumvention
  devices, etc.
* In order to keep the source publicly available for 12 months, I
  may have to bear practically unlimited costs: What happens if
  Slashdot links to my website? What happens if it turns out the
  software may violate a patent, copyright, etc? With software e.g.,
  under the GPL, I can limit my expenses/legal exposure by ceasing
  distribution entirely: Take down both the binary and the source.
  With this clause, I may not.


Also, although I'm less sure of the argument, "in order to use this
software, you must provide public access to it's source code" sounds
like demanding a fee to use it.


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

Re: new tar behavior and --wildcards

[Anthony DeRobertis]

Bdale Garbee wrote:

>The following table summarizes pattern-matching default values:
>
>MembersDefault settings
>--
>Inclusion  `--no-wildcards --anchored
>--no-wildcards-match-slash'
>Exclusion  `--wildcards --no-anchored
>--wildcards-match-slash'
>
>-- Footnotes --

Will this break my Amanda config? I'm not sure what flags Amanda passes
to tar, but I'm pretty syre I have no control (absent changing the
source, of course) over them.

Do I need to worry now which version of tar is installed on each machine
being backed up by Amanda? That'll be fun :-(


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

Re: Bug#375047: ITP: srtp -- Secure RTP (SRTP) and UST Reference Implementations

[Anthony DeRobertis]

Jonas Smedegaard wrote:

> (Include the long description here.)
>   
Yes. Please do so.

Writing the long description in the ITP allows debian-devel to help spot
any mistakes in, and make suggestions for improvement to, the long
description.


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

Bug#72140: Setting up libraries too slow

[Anthony DeRobertis]

Tim Connors wrote:
> only the occasional slowness as apt
> replaces libc6 and the /sbin/ldconfig program gets restored.  I move it
> back out of the way when I notice that apt is taking so long, and all is
> fine.
man dpkg-divert

That should help with your libc6 upgrades.


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

Re: Real Life hits: need to give up packages for adoption

[Anthony DeRobertis]

Christoph Haas wrote:
> Yes, of course. Besides some minor things I don't quite like about
> Subversion ([...] getting out old revisions of a file means typing 
> the full URL for no reason) 

svn cat -r 

works for me...


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

Re: Testing security archive move

[Anthony DeRobertis]

Anthony DeRobertis wrote:

Errr... apt-get says:

Failed to fetch http://security.debian.org/dists/etch/updates/Release  
Unable to find expected entry  main/binary-amd64/Packages in 
Meta-index file (malformed Release file?)



And, indeed, despite appearing in Architectures, there is no 
binary-amd64 in the release file.




And indeed, it's still that way anyone know what's going on?


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

Re: Please revoke your signatures from Martin Kraff's keys

[Anthony DeRobertis]

Tyler MacDonald wrote:
WTF?  In Oregon, if you have a driver's license, you cannot get an ID card.  
If you have an ID card, you have to surrender it to get a driver's license.  
You're only legally allowed one ID.



	Weird! 


Not really, same rules apply in Virginia, AFAIK.


You can still keep your birth certificate and social security
card though, right?
  


Neither of those are photo IDs.


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

Re: sending debian-private postings to gmail

[Anthony DeRobertis]

Kevin B. McCarty wrote:


Come to think of it, [pgp encrypting each message] isn't a bad idea.  Is it 
feasible for this to
be done transparently?  Mailing list admins, any comments?


I suspect that the end result of this would be more people keeping their 
GPG keys unencrypted on Internet-accessible machines.



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

Re: Testing security archive move

[Anthony DeRobertis]

Neil McGovern wrote:

deb http://security.debian.org etch/updates main contrib non-free
deb-src http://security.debian.org etch/updates main contrib non-free
  

Errr... apt-get says:

Failed to fetch http://security.debian.org/dists/etch/updates/Release  
Unable to find expected entry  main/binary-amd64/Packages in Meta-index 
file (malformed Release file?)



And, indeed, despite appearing in Architectures, there is no 
binary-amd64 in the release file.



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

Re: the BTS gains a remote bug tracking feature for free !

[Anthony DeRobertis]

On Fri, May 05, 2006 at 09:35:16AM +0200, Pierre Habouzit wrote:

> Could you please point me to an UNMERGED bug to see what it looks like ? 
> (an URL to the {status=closed ; resolution=merged} bug that was reopen, 
> as well as the bug in was merged "into").

https://bugzilla.mozilla.org/show_bug.cgi?id=85084

seems to be one such bug.

https://bugzilla.mozilla.org/show_activity.cgi?id=85084 shows what
happened fairly well.


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

Re: Compiling packages for the standard distribution with -Os instead of -O2

[Anthony DeRobertis]

On Sat, May 06, 2006 at 04:44:23PM +0200, Goswin von Brederlow wrote:

> Initialiy this was for people with older computers, not a 2 GHz amd64
> with 2GB ram. Think P90 with 64Mb or slightly better.
> 
> We are not talking "generally" here but "specific". Specific to
> certain hardware.

OP mentioned:
"For Etch and Sid, it is probably a good idea to use -Os instead of
-O2 at least on the bigger arches (ia32, ia64, amd64, etc), [...]"

Notice he suggested doing it in general on ia32 (which definitely has
older machines) but also with amd64 (which I doubt there are any 64mb
AMD64 systems) and ia64 (which I very much doubt there are any 64mb
systems).


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

Re: Bug#366069: ITP: fusesmb -- filesystem client based on the samba file transfer protocol

[Anthony DeRobertis]

On Thu, May 04, 2006 at 10:29:25PM +0200, Samuel Mimram wrote:

>  fusesmb is a filesystem client based on the samba file transfer protocol.
>  .
>  It is based on FUSE (userspace filesystem framework for Linux), thus you will
>  have to prepare fuse kernel module to be able to use it.

Please explain in the long description how this is different/better than
the smbfs and cifs kernel file systems.

[Looking at the URL, it seems it has some sort of "network neighborhood"
thing built in.]


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

Re: Compiling packages for the standard distribution with -Os instead of -O2

[Anthony DeRobertis]

On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote:

> For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at
> least on the bigger arches (ia32, ia64, amd64, etc), as we can probably
> trust gcc not to screw up.

If gcc generally generates faster code with -Os than -O2, then isn't
that a gcc bug, in that the optimizations enabled by -O2 are incorrectly
picked?

[Also, are there that man AMD64 machines with limited memory? Or IA64?]


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

Re: the BTS gains a remote bug tracking feature for free !

[Anthony DeRobertis]

On Wed, May 03, 2006 at 01:21:41PM +0200, Pierre Habouzit wrote:

>  * the forward canonization is vital for things like tracking bugzilla's
>"merges" (it in fact rewrites a $(uri)/show_bug.cgi?old_nnn into the 
>$(uri)/show_bug.cgi?new_nnn)

Out of curiosity, how does it handle un-merges in Bugzilla?


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

Re: Bug#360340: ITP: libpcl1 -- the Portable Coroutine Library (PCL) implements the low level functionality for coroutines

[Anthony DeRobertis]

Ron Johnson wrote:

Vote: nay.  OP forgot to mention which volume of tAoCP.
  

I suspect some sarcasm has failed to convey over email.


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

Re: Maintainers Guide

[Anthony DeRobertis]

On Tue, Mar 28, 2006 at 03:51:30PM +0200, Henning Makholm wrote:

> Only for some pretty strange values of "worthless". AFAIU the only
> legal effect of the notice requirements you cite is as defined by
> subsection (d): if a compliant notice is present, a defendant is
> excluded from the defense that he did not understand that the work was
> copyrighted.

Well, isn't prohibiting the "I didn't know it is copyrighted" defence
the only legal effect of having the notice nowadays, anyway?


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

Re: Maintainers Guide

[Anthony DeRobertis]

Jeremy Stanley wrote:

   This has to include a copyright year, also.

...and following additional discussion, the resolution is:

   After considering the suggestion, I have decided to close this
   bug.
  
The year really should be included. At least in the US, not having a 
year in the notice appears to make the notice worthless. Quoting Title 
17 USC Sec. 401(b):


   (b) * Form of Notice.— *If a notice appears on the copies, it shall
   consist of the following three elements:

   (1) the symbol © (the letter C in a circle), or the word
   “Copyright”, or the abbreviation “Copr.”; and
   (2) the year of first publication of the work; in the case of
   compilations, or derivative works incorporating previously
   published material, the year date of first publication of the
   compilation or derivative work is sufficient. The year date may
   be omitted where a pictorial, graphic, or sculptural work, with
   accompanying text matter, if any, is reproduced in or on
   greeting cards, postcards, stationery, jewelry, dolls, toys, or
   any useful articles; and
   (3) the name of the owner of copyright in the work, or an
   abbreviation by which the name can be recognized, or a generally
   known alternative designation of the owner.

   
http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0401000-.html


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

Re: DPL Debate prepared questions list [Debian Policy Sucks]

[Anthony DeRobertis]

Martin Michlmayr wrote:

Anthony, do you still see this bug with 2.6.15 or (better yet) 2.6.16?
(will be uploaded tomorrow).
  
2.6.15, yes. I'll check 2.6.16 when it hits unstable (I'm guessing, 
though I still need to test, that the ide-tape cleanup in 2.6.9 borked it)



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

Re: DPL Debate prepared questions list [Debian Policy Sucks]

[Anthony DeRobertis]

Ritesh Raj Sarraf wrote:
Now, there was a known issue with those cards with e1000 driver upto kernel 
2.6.11, IIRC. 
  
Hmmm, and 2.6.12 panics (bug #327355 ) 
when I try and use the tape drive on my machine. New versions not only 
fix bugs, but introduce new ones, too.


[PS: Which e1000 bug are you referring to?]


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

Re: conffile purging and maintainer scripts

[Anthony DeRobertis]

Roger Leigh wrote:

> This updated version should cater for both the old and new behaviour.
> Any comments?

Maintainers using this should be aware that it will mistakenly delete
conffiles that have been converted to e.g., ucf configuration files.
This is, of course, unavoidable.

It will also delete any locally-installed configuration files, of
course. The following sequence of actions could be quite bad:

1. Locally install FOO, with its config file /etc/foo.conf. Maybe
because FOO isn't available in stable.

2. Someone packages FOO for Debian, with the config file /etc/foo.conf.

3. Debian package changes to using /etc/foo/foo.conf

4. Upgrade to stable+1, install Debian FOO package. Or install from
backport, whatever.

5. Decide you'd rather keep locally installed FOO, purge Debian FOO package.

Solution to this one is that admins should follow the FHS and put their
config files in /etc/local/ :-D


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

Re: the latest gnome

[Anthony DeRobertis]

Kevin Mark wrote:
> If 'upgrades'
> in Gnome are going to remove something, I think there should be
> something obvious like a document placed on the desktop saying
> 'gnome_2.12.2.removed.features' and explaining what was removed and how to 
> work around it
> based upon the functionality in the last version.

Well, personally, after the tasklist applet lost its ability to only
show iconified (minimized) windows, I found that the solution was along
the lines of: [At the risk of starting a flame war]

# apt-get install kicker
...
$ killall gnome-panel
... damn, it comes back.
$ while true; do killall -9 gnome-panel; done
... wait a few seconds, control-c the while true loop,
and now it doesn't come back. Yeah!
$ kicker


GNOME seems to be more and more focusing on the entry-level Linux user,
and less and less on advanced users. Most unfortunate, its much prettier
than KDE. And Nautilus beats Konqueror's file handling hands down.


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

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Anthony DeRobertis]

Nathanael Nerode wrote:

> In fact, this would solve in a certain sense the long argument about how many 
> protocols/services to include in the lists: alternate packages could 
> Provides: netbase-data if they included any superset of the most basic list.

In this way, I dare say, lies madness. Not only will there be multiple
packages owning the same config file, but there is the problem of
multiple versions existing --- package A and package B both include a
superset, and now for no good reason can't be installed together.

If there is really a problem with not being able to include everything
in netkit-data or whatever, we need an update-services command, etc.


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

Re: Obsolete packages in Experimental

[Anthony DeRobertis]

apt-show-versions | grep /experimental

should work too, but I haven't tested it (no experimental packages
installed on this machine)


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

Re: How to purge linux-image-2.6.14

[Anthony DeRobertis]

Sam Morris wrote:

> PS - why do packages without any config files get into the config-files
> state in the first place? :)

Possibly, because dpkg can only know if a package has conffiles, and not
configuration files in general?

Look up the details in policy, but not all configuration files are
managed by dpkg. Packages may manage their own (using, e.g., ucf) as
long as they follow the rules laid out by policy.

BTW: I think sometimes packages do go strait from installed to purged on
just remove... Not 100% sure if it even happens, but maybe its if there
is no postrm script and no conffiles.


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

Re: For those who care about the GR

[Anthony DeRobertis]

On Sun, Jan 22, 2006 at 03:42:39PM -0800, Steve Langasek wrote:

> > And what? If someone tries to bring through a GR stating that
> >  MS office warez can be distributed in main since it meets the DFSG,
> >  one might rule that as frivolous and a waste of time.
> 
> I'm not convinced the constitution gives the secretary the power to make
> such a ruling.  There are no provisions in the constitution for the Project
> Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> holds the value of pi to be 3 -- so long as the GR has the requisite number
> of seconds.

I suspect the Secretary could effectively do so by declining to take the
vote under Section 2.1.1 ("[n]othing in this constitution imposes an
obligation on anyone to do work for the Project.") It seems then that
the secretary has no obligation to actually perform 4.2.3 or 7.1.1.

> 
> In the present case, I understand that the proposed ballot option is
> ambiguous wrt whether it constitutes an implicit amendment to the foundation
> docs, and that in the absence of clarification (in the form of a re-worded
> proposal) on the part of the proposer, it is the project secretary's
> prerogative to specify a supermajority requirement.

I think that under 7.1.3, it'd be the Secretary's job/power to determine
supermajority requirement regardless of what the proposed ballot option
says.

If 6 developers (K=5 currently, I think) can decide that the
supermajority requirements to not apply to a ballot option, then the
supermajority requirements are rather worthless.


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

Re: yet another mass bug filing on GFDL issues ?

[Anthony DeRobertis]

Holger Levsen wrote:

> Hm, on a second thought this (*) _might_ be a feature: the GFDL says 
> invariant 
> sections need to be listed, but there aren't any, as a template has been 
> used. Yay ?!

I suspect that many of those cases might just be an accidental ommission
in the copyright file...

OTOH, it is hillarious that after typing 'info gdb' I was unable to
actually find the statement saying the documentation is under the GFDL;
it appears that the FSF has once again mis-applied their own license...


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

Re: Backports

[Anthony DeRobertis]

Joseph Smidt wrote:

> Were you writing this  just to ridicule  me?

No, not at all. It was just supposed to be a joke.

I appologize; I should have been clearer.


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

Re: Backports

[Anthony DeRobertis]

Joseph Smidt wrote:

> " I provide these files without any warranty. Use them at your own risk.
> If one of these packages eats your cat or your rabbit, kills your
> neighbour, or burns your fridge, don't bother me. "

Well, perhaps you should read the following, printed whenever you log in
to your Debian machine:

"Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law."

Hey, "without any warranty" is at least a step up from "ABSOLUTELY NO
WARRANTY", and the latter is even yelling at you.

:-D


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

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Anthony DeRobertis]

Christopher Martin wrote:

> Therefore, no modification of the DFSG would be required after the passage 
> of the amendment, since it would have been decided by the developers that 
> there was no inconsistency.

If a simple majority can yell, "there is no inconsistency" then the 3:1
requirement has little meaning. I think it'd be reasonable to request
that people who believe [0] is wrong should produce reasoned arguments
against it; to the best of my knowledge (and memory, of course), no one
has done so.

Without a reasoned argument for why the GFDL w/o Invariant Sections is
free, I don't see how the Secretary can consider the amendment anything
else than an attempt to change a foundation document, and either rule it
out of order or require the supermajority.

[0] http://people.debian.org/~srivasta/Position_Statement.xhtml


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

Re: libecw

[Anthony DeRobertis]

Miriam Ruiz wrote:
> I'm not sure if it's license (
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered
> free enough to be in main:

FYI, the right place to ask this is [EMAIL PROTECTED]
Moving it over there. Full-quoting because of this.

Summary: I don't believe this is a free software licence, failing at
least DFSG 3, 4, and 9. It may additionaly fail DFSG 6. Due to the
failure of DFSG 9, I doubt this can even go in non-free.


> 
> Use of the ECW SDK with Unlimited Decompressing and Unlimited Compression for
> applications licensed under a GNU General Public style license ("GPL") is
> governed by the "ECW SDK PUBLIC USE LICENSE AGREEMENT".

Not sure what they're thinking, as this definitely isn't GPL-compatible.

> 
> 
> * About modifications:
> 
> b)You may make modifications to the Software and distribute your
> modifications, in a form that is separate from the Software, such as 
> patches. The following restrictions apply to modifications: 

Requiring patches is allowed as an explicit exception given in DFSG.
However, I don't see anything allowing us to distribute binaries built
from patched sources, thus this seems to fail DFSG 4 ("[t]he license
must explicitly permit distribution of software built from modified
source code.")

> i)Modifications must not alter or remove any copyright notices in the
> Software. 

This is acceptable, provided they're actually reasonable copyright notices.

> ii)   When modifications to the Software are released under this license, a
> non-exclusive royalty-free right is granted to the initial 
> developer of the Software to distribute your modification in future versions
> of the Software provided such versions remain available under 
> these terms in addition to any other license(s) of the initial developer. 

I'm uncomfortable with this, but considering the other problems I can
punt on deciding :-D

> iii)  You are not permitted to change the ECW file format.

Fails DFSG 3.

> iv)   You are not permitted to use Software Product for development or
> distribution of "Server Software" that provides services or 
> functionality on a computer acting as a server.

Fails DFSG 3 and 9 (restriction in this case is "may not be distributed
alongside server software"); also possibly 6.

> 
> 
> * About restriction of use (I just don't know DFARS 252.227-7013 so I have no
> idea what's said in here)

Neither do I.

> 
> 3)U.S. GOVERNMENT RESTRICTED RIGHTS. 
> The SOFTWARE PRODUCT and documentation are provided with RESTRICTED RIGHTS.
> Use, duplication, or disclosure by the US Government is subject 
> to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in
> Technical Data and Computer Software clause at DFARS 252.227-7013 
> or subparagraphs (c)(1) and (2) of the Commercial Computer Software -
> Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is 
> Earth Resource Mapping Limited.
> 
> 4)DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. 
> a)Rental. You may not rent, lease or lend the SOFTWARE PRODUCT. 

Not sure how this affects DFSG freeness. I can't think of a single free
license we've seen on -legal with similar provisions.


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

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920

[Anthony DeRobertis]

Felipe Sateler wrote:

> This seems like a nice idea. File a whishlist bug against reportbug ;)
> 

If you really want to do this, look at
/usr/share/doc/reportbug/README.developers.


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

Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Anthony DeRobertis]

Steve Langasek wrote:

> That's fine; I'm just saying that there's not much point in telling people
> to *not* ship /var/run (or subdirectories thereof) in their package.

Well, there is the slight point that if you ship /var/run/foo in your
package, you (a) probably use /var/run/foo just assuming it exists
because, after all, you shipped in in your package; (b) if you actually
mkdir -p it, you have two different ways that /var/run/foo could be
created, and possibly with two different sets of permissions.


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

Re: dependencies on makedev

[Anthony DeRobertis]

Joey Hess wrote:

> If there is then it would be possible to write a tool
> like what I think Anthony is suggesting:
> 
> udev-chown 666 /dev/cdrom
> udev-chmod -a 644 /dev/sda /dev/sdb # change all scsi usb devices
> 

That'd definitely be a great tool.


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

Re: dependencies on makedev

[Anthony DeRobertis]

Matthew Garrett wrote:

> Indeed. Editing plain text configuration files has never been the Unix
> way, and vi certainly isn't a standard unix tool.
>

I think the right question for him to ask is, "what ever happened to the
 unix way?"

chmod, chown, etc. are all simple tools that do one job and do it well.
If I want to change the group of /dev/hdc to "foo" from its current
"cdrom", it is _very_ self-evident how to do that with chgrp.

Now, since my system actually runs udev, let's figure out how to do it
with vim... First, I take a look at /etc/udev.d. I see a udev.conf as
well as a bunch of other files. Open it up, nothing there. So next I go
look at rules.d (after trying to figure out where there is a rules.d as
well as a bunch of .rules files; aparently a less-clean version of
apache2's foo-available/foo-enabled. Should probably fix this. Whishlist
bug filed.) Next, it looks like you edit 020_permissions.rules (or
rather the file it is symlinked to). Maybe you change this line:

ENV{ID_CDROM}=="?*",GROUP="cdrom"

to

ENV{ID_CDROM}=="?*", KERNEL!="hdc"  GROUP="cdrom"

but I'm not sure.

I like udev overall (after all, I'm running it), however, this is
definitely not one of its strong points. It fails to keep simple things
simple.


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