Re: bug reporting workflow is outdated

[sean finney]

On Mon, May 23, 2011 at 01:47:22AM +0200, Goswin von Brederlow wrote:
> > I suggest that we can make an HTTP based bug reporting method.
> 
> The only advantage of this would be for systems that firewall outgoing
> mail conections but allow http or have a http proxy but no smarthost.

and that's a pretty big advantage.  requiring that submissions be done
only via SMTP seems a bit silly and self-limiting if you ask me.  

HTTP would be able to provide a super-set of the features of SMTP
submission, would not prevent SMTP submission from remaining as an option,
and is more likely to work in diverse environments.


sean


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523071056.ga17...@cobija.connexer.com

Re: bug reporting workflow is outdated

[Timo Juhani Lindfors]

sean finney  writes:
> HTTP would be able to provide a super-set of the features of SMTP
> submission, would not prevent SMTP submission from remaining as an option,
> and is more likely to work in diverse environments.

HTTP could also provide faster feedback on syntax errors in control
messages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84y61xvq8t@sauna.l.org

Re: bug reporting workflow is outdated

[Andrew O. Shadoura]

Hello,

On Mon, 23 May 2011 11:58:06 +1000
Russell Coker  wrote:

> I often use the -o option of reportbug and scp the file to somewhere
> I can send mail.

> It would be nice if there was a program that could take the output of 
> reportbug -o and send it via email.  Using cut/paste wastes a little
> time.

> Another option is to use ssh port redirection to tunnel SMTP over ssh.

Easier is to write a one-liner:

#!/bin/sh
ssh your-favourite-host-with-sendmail-set-up /usr/sbin/sendmail -f \
y...@email.org -t "$@"

and tell reportbug to use it.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Changed ssh key on git.debian.org

[Andrew O. Shadoura]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

On Sun, 22 May 2011 17:24:37 +0100
Klaus Ethgen  wrote:

> Now I got another problem. Well, it's not really a problem but a minor
> bug. When I push to a git repository I get a warning that was not
> there with alioth: "bash: warning: setlocale: LC_ALL: cannot change
> locale (de_DE)". It seems that not all locales are build on the
> system.

Yup. It doesn't even have en_GB.

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

iQIcBAEBCAAGBQJN2hcsAAoJEG6k0jEaLSaNGWEP/jjBgZlUGbLIOv/PvAfzK54l
oO2oXrtoXK7MaNwF4nrxboh1jbJh6veYkT9XZZAxaeejdzAk81lk07VKZoEk2S7I
xfcO9jQ59mWsh0z3qoPIKZ7jnORicImV7T43tB1diXzhQxbIoo/MjQKaiXXiHxTs
L4sXfjhtlvR7w40xdOw4BFYv5VRBkGYUCZXZQY+bUalngDnOfbk2EiSrGEKRPizC
mACZEhF+yVJB2cBItF8eEIwKB6IMNL5I8S5Dak1H3jVX6ahJJMX8rgqeGxfeekMF
AG6K1bixq/qPbdaJWBTjRaWYlZQPiGwXstMKHEi4CK3FEctsOJyPDI5XgGRJpXbV
oN5oHsWDt9h6a20/TReApOb1oi2VmESrkdjQLUsP8+u+M0CySbGp8Bs4967obsKh
mUFVAbc7X+AGCsqr1CszKRExCLJy0/B4ZLTgVQjGzbfrstdyRwMOFlM2HJv0jypm
6ZZcUa4VB9+5PqPn3gmYFnAF4UT+ddXAmdu2p7NSJ1qie+Q8vqNZKg+iF9m5z94a
HWOnM93wW//9KDtGA1iIT6n4FWFnCAranzt2ufxtcpHUZ8J8EkXtyNWN0rdWoH17
twxWHFNm/pnFMzhY88fj87coKHHRZ0tT9Daz9j9wmwp/Sz05s3xtsJHg5Jf0z//q
H8cSfB88L6xOuDNzaqYQ
=ba6x
-END PGP SIGNATURE-

Re: bug reporting workflow is outdated

[Paul Wise]

On Mon, May 23, 2011 at 3:24 PM, Andrew O. Shadoura  wrote:

> Easier is to write a one-liner:
>
> #!/bin/sh
> ssh your-favourite-host-with-sendmail-set-up /usr/sbin/sendmail -f \
>    y...@email.org -t "$@"
>
> and tell reportbug to use it.

Aha, thanks. I'm now using something similar to dump reportbug mail
into my (unsupported by reportbug) desktop MUA's drafts folder.

Hmm, I wonder if I can use that to launch a compose screen somehow.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#627658: ITP: netzhack -- German-localized version of the game NetHack

[Tony Crawford]

Package: wnpp
Severity: wishlist
Owner: Tony Crawford 


* Package name: netzhack
  Version : 0.2.1
  Upstream Author : Tony Crawford 
* URL : http://www.netzhack.de/
* License : Nethack General Public License
  Programming Lang: C
  Description : German-localized version of the game NetHack

Localizing the role-playing game NetHack is non-trivial because
the morphology of English is hard-coded into it at every level.
But now there is an idiomatic German version.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523101545.7048.44247.reportbug@vinteuil

Bug#627659: ITP: pythonwebkit -- Python DOM (HTML5) Bindings to Webkit

[lkcl]

Package: wnpp
Severity: wishlist
Owner: lkcl 

* Package name: pythonwebkit
  Version : 1.0-1
  Upstream Author : GNU Project 
* URL : http://www.gnu.org/software/pythonwebkit
* License : GPLv2, LGPLv2, LGPLv2+, BSD, MIT, MPL-1.1
  Programming Lang: C, C++, Perl, Python
  Description : Python DOM (HTML5) Bindings to Webkit

 WebKit is a web content engine, derived from KHTML and KJS from KDE, and
 used primarily in Apple's Safari browser.
 .
 It is able to display content such as HTML, SVG, XML, and others. It also
 supports DOM, XMLHttpRequest, XSLT, CSS, Javascript/ECMAscript and more.
 .
 This package contains a python module which provides a simple, single
 stand-alone window, where access to the full features of HTML5 are
 provided, directly, to python.  Features and functions which are normally
 the exclusive domain of javascript are made available in a 100% compatible
 way: Webkit "javascript" Timers, HTTPRequest, onmouseover and other callbacks,
 CSS properties, appendChild, getElementsByTagName: everything that can be
 expected to be accessed via javascript is made available to python
 programmers.
 .
 There are several "ports" of PythonWebkit: this module contains the GTK2
 version.  The PythonWebkit bindings are faster than the GObject bindings
 because they are direct; they are also feature-comparable to Javascript;
 they are also more stable than the GObject bindings.


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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523101209.3883.34980.reportbug@localhost

Re: bug reporting workflow is outdated

[Henrique de Moraes Holschuh]

On Mon, 23 May 2011, Paul Wise wrote:
> On Mon, May 23, 2011 at 7:47 AM, Goswin von Brederlow  
> wrote:
> > The only advantage of this would be for systems that firewall outgoing
> > mail conections but allow http or have a http proxy but no smarthost.
> 
> There are a *lot* of ISPs that do this. My ISP does this so I have to
> send mail via SSH tunnel or webmail.

It is now a best-standard-practice for ISPs to block port 25 traffic across
home-user access network borders.  It is being done on purpose to leverage
packet-filtering hardware and the distributed architecture characteristics
of access/border network filtering (which is already there).  Its objectives
are: reduce the overhead on MTAs everywhere due to spambot connections, and
reduce the number of botnet-caused incident complaints.

Users are now supposed to use ESMTPSA over port 587 to submit email (that
would be ESMTP with TLS+SMTP AUTH) to any email provider (including his own
ISP).  Port 25 is now reserved for static MTA-MTA (i.e. MX) traffic.

>From our (Debian) PoV, whether one agrees with port-25 blocking policy or
not doesn't matter.  It is already deployed to several million users
worldwide (which likely means at least several thousand Debian users), many
of which will not configure their local MTAs to forward email, and instead
just configure their MUAs.

We have to deal with it somehow.

Anyway, on this new port 587 world, to have reportbug reliably submit BTS
email on unconfigured local networks, it would have to use ESMTPS (or
deep-inspection firewalls will kill the tcp session off) over port 587.

And the receiving gateway would have to localy validate that the destination
are acceptable addresses (@bugs.debian.org), and also validate the sending
domain (to reduce spam and guarantee a return path for further bug
processing), etc.

Whether it is easier to do that or instead switch to a https application
gateway, I don't know.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523110124.ga10...@khazad-dum.debian.net

Re: bug reporting workflow is outdated

[Timo Juhani Lindfors]

Henrique de Moraes Holschuh  writes:
> guarantee a return path for further bug processing

Bugzilla and trac do this by allowing the user to register an account
and to keep the email address associated with that account up to
date. If somebody reopens an archived bug that I've reported a year ago
they can't ask me for more information if I've changed my email address.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84hb8lver0@sauna.l.org

Re: 'Alioth' status update

[Dominic Hargreaves]

On Sun, May 22, 2011 at 11:27:45AM +0100, Stephen Gran wrote:
> Hi everybody,
> 
> The host we knew and loved as alioth.debian.org is no more.
> 
> We are now running on two hosts, vasks.debian.org and wagner.debian.org.
> 
> The writable SCM repositories are hosted on vasks.debian.org, and DNS
> has been updated to reflect that.  The fingerprints for the two hosts
> are:
> 
> 2048 8c:c0:b8:9f:0a:79:ee:1c:77:c4:b8:a1:70:55:b7:31 vasks.debian.org (RSA)
> 2048 36:24:36:e2:99:44:8d:39:e1:d5:36:0b:e4:1d:5d:bd wagner.debian.org (RSA)
> 
> This information is also available in signed DNS, and also at
> /etc/ssh/ssh_known_hosts on any debian system.
> 
> Some bits of the infrastructure are still being bolted back together,
> and we expect to send further status updates as they happen.

Dear Alioth admins,

Since we're now out of the time period originally announced as the
service downtime, ("late afternoon (UK time) on Sunday, May 22nd."),
please could you send another update with any ETAs you have for the
restoration of the remaining alioth services? This will help everyone
plan work in the next couple of days.

The biggest downtime that matters to me personally is mailman and the
gitweb interfaces, but I'm sure there are others. Confirmation of
which services are known to be down and planned to be restored would
be welcome all round, I think.

One particular concern I can think of is that mail service
(for lists.alioth.debian.org, and does alioth.debian.org also have
a mail service?) is brought back up soon, because after 4 days we'll
start losing mail queued on remote servers.

Thanks for your work on this!

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523135024.gn29...@urchin.earth.li

Re: Conditional Recommends

[David Kalnischkies]

On Sat, May 21, 2011 at 17:56, Carsten Hey  wrote:
> With above exclamation mark syntax, we could also express "weak
> conflicts", e.g.:
>
>        Package: X
>        Recommends: !Y
>
> Apt would remove Y by default if X gets installed, but users could
> overwrite this.


As a user i hate it then packages are removed just because the maintainer
is bored and wants to force it now. That forces the user in dist-upgrades
to distinguish between different remove-types and the package manager
can very seldomly help with that:
a) two packages do not work (well) together
b) package A is unmaintained
c) the maintainer of package B is bored
With my APT hat i can add that apt-get and friends do not like removes, too.

c) happens all the time in package renames without a good reason as this
could be done later by the user with autoremove or deborphan or whatever
at a time the user expects the need to decide between keeping a package
or not. At dist-upgrade time it's a big annoyance and can even prevent
upgrades as a user has to fear that with the 200 packages which are going
to be removed by the dist-upgrade a lot of features will be gone, too.
So he will delay it until more time is available for checking everything.
Beside that the 190 renames hide the 10 removes the user should
really have a look at…
Yet alone that these removes tend to cause "unexpected results" anyway
as the recent libtar to libtar0 rename did for example… Not that it would
be too unexpected that a package manager can decide against removing
a package, it's just that maintainers never expect that…


And no, the solution to this is not to downgrade c) to a weak conflict.
The solution is to help autoremove and deborphan detect A properly by
hinting that the package A is obsolete (section: oldlibs, debtags, …)
and handle it in a different step. It's just bad to try to do everything at
the same time…


Best regards

David Kalnischkies, who is already waiting for 'iceweasel recommends !chromium'


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

Re: Conditional Recommends

[David Kalnischkies]

On Sun, May 22, 2011 at 16:07, Carsten Hey  wrote:
>  * Conflicts, Breaks, ..., Enhances:
>   - satisfied if any of the clauses is true

Uhm, a Conflicts/Breaks is satisfied if all clauses are false.
That way you could say Conflicts = ! Pre-Depends.
(regarding "…": Replaces doesn't fit to well in here…)
(Enhances are reverse-suggests so i really don't understand
 why it is in the same enumeration as Conflicts/Breaks…)


> If we allow logical 'and' in clauses of disjunctive fields and add
> a field similar to 'Enhances:', but for reverse recommendations instead,
> the above example could be written as:
>
>        Package: A-plugin-B
>        Depends: A, B
>        Recommended-By: A & B

Such a plugin 'Enhances: A' and maybe only 'Depends: B'.
A plugin like xul-ext-firegpg (removed & discontinued upstream) enhances
iceweasel and depends on gpg. Still, i don't think it would be a good
idea to add something like 'Recommended-By: iceweasel & gpg'
as this promotes this plugin nearly to priority (desktop-)standard…



If you want to your package manager (front-end) to suggest you to install
the plugin if you have A, B or A & B installed then please go ahead and
implement it in your front-end.

I don't see a good reason why the installation of A should install
"unconditional" a bunch of plugins just because i happen to have B and C
installed as it generates a bunch of new problems even if we leave
the very simple fact aside that the current dependencies are already
misused and something like that doesn't help in making it simpler…

It will be for example interesting in stable to stable+1 upgrades:
The dependency trees are already now very long and big, it doesn't
help in any way if we add even more subtrees and make them
conditional… (you want an example? udev effected kde: #610991)

Also, just imagine for a second we have such a field, then exactly is
your package manager supposed to install A-plugin-B?
Remember: New Recommends of a package are installed on a
package upgrade - and i will come back to you at the time i am forced
to implement logic to decide if A & B is compared to A & B & C a new
Recommended-By clause or not…
(We have such a problem already for or-groups in recommends)
Beside that the notion of 'new' is interesting in case A-plugin-B is new
in the archive and package A or B are upgraded (new compared to the
last time the packages were upgraded) …


> To prevent problems with partial upgrades, a logical 'and' should only
> be allowed in fields that do not exist in Squeeze.  After Wheezy, they
> could be allowed in 'Enhances:' too and if there are according use
> cases, maybe even in Conflicts or Breaks.

Do you have just one usecase for a 'Conflicts: A & B' which shouldn't
be a 'Conflicts: A, B' instead? I always thought an ',' is already an 'and'.
And if i keep thinking this, the only reason for an '&' would be to
write stuff like A | (BA & BB) | C, but in the end i properly need a
glue in between BA and BB which i could package as B… or if this glue is
really not needed i could use A | BA | C, A | BB | C and live on without
the introduction of (multi-level) nested and/or-groups in or-groups…

Similar thoughts for '!' - That 'Breaks' are already '! Depends' is clear,
so in which way does it help? With the current (mis)use of Breaks/Conflicts
i don't really want to imagine what 'Recommends: ! A' should tell me or
the package manager… KDE4 recommends !GNOME3… will be fun.

Beside that even if i could express 'Breaks' as '! Depends' i would prefer
to write them still as 'Breaks' as a small '!' easily gets lost between many
shared library dependencies. As a user its way easier to look for a Breaks
line instead of reading and parsing the complete Depends line…


Best regards

David Kalnischkies


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

Re: Conditional Recommends

[David Kalnischkies]

On Mon, May 23, 2011 at 06:50, Miles Bader  wrote:
> I've noticed many cases where packages recommend a bunch of stuff that,
> while it might be very nice for some users, really isn't of general
> interest.

So, because package maintainers don't read and understand the policy
which defines clearly for what 'Recommends' should be used
(hint: §7.2 "in all but unusual installations" != "nice for some users")
we should give maintainers even more options they don't understand?



The idea of using it for l10n-packages hints already that conditions based
on packages are not enough, soon it will be 'tasks' or based on local
environment. I can already hear someone asking for
Package: libc6
Recommends: libc6-686 {arch::supports:cmov}
which soon evolves to a complete language in which you really need
all the funky stuff like & and | and ! together with hard/soft constraints…

So, in the end what we would need is a machine parseable reason why
a package is recommend/suggested by a maintainer so the machine
can evaluate if it should suggest this to the user.

And in that end, the user still has to decide what should be installed and
what should not, so maybe we should focus on making the massive amount
of information we already have easily available before we add even more…


Best regards

David Kalnischkies


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

Re: Conditional Recommends

[Simon McVittie]

On Mon, 23 May 2011 at 16:31:10 +0200, David Kalnischkies wrote:
> A plugin like xul-ext-firegpg (removed & discontinued upstream) enhances
> iceweasel and depends on gpg. Still, i don't think it would be a good
> idea to add something like 'Recommended-By: iceweasel & gpg'
> as this promotes this plugin nearly to priority (desktop-)standard…

I don't think this would be a good use of conditional recommendation either:
it's entirely likely that you have both iceweasel and gpg and don't want to
use them together.

However, consider gstreamer0.10-pulseaudio: it's a plugin for GStreamer
applications to output audio through the PulseAudio daemon. Neither GStreamer
nor PulseAudio should depend on the other: GStreamer applications can equally
well use ALSA, OSS or even ESD, while PulseAudio can be used for output by
plenty of non-GStreamer audio APIs.

However, if you do happen to have both GStreamer and Pulse installed, you
probably want the one to be able to output through the other.
"Recommended-by: libgstreamer0.10-0 & pulseaudio" would express this, if it's
feasible to implement.

I suspect many of the use-cases for Recommended-by are also of the form
"plugin to give abstraction layer A the ability to use backend B". The
alternative is typically to add an artificial recommendation or even
dependency in one direction or the other (e.g. A Recommends a-plugin-b which
Depends: B, effectively promoting the priority of both the plugin and B, or
vice versa), or to add an artificial recommendation or dependency to some
random third package (e.g. rhythmbox Depends: gstreamer0.10-pulseaudio, even
though it can use many other output plugins).

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110523164102.gd24...@reptile.pseudorandom.co.uk

Re: bug reporting workflow is outdated

[Patrick Strasser]

schrieb Pedro Larroy am 2011-05-22 22:44:
> Hi
> 
> I think expecting having a working smtp on laptops, workstations, etc,
> is unreasonable these days.
> I suggest that we can make an HTTP based bug reporting method.

>From my experience as a occasional bug reporter, some thoughts that came
to my mind:

It's easier to get the mail setup wrong than to get it right. The
current procedure assumes you have a working mail configuration at the
reporting machine. That assumption is too strong. I need to authenticate
to my mail server, and from time to time I'm in a different network that
needs a changed configuration that I have to get right before using
reportbug.

reportbug should default to the worst case, that is: "I do not have a
clue how the message will get sent to BTS, just Do The Right Thing(tm)".
If someone knows that his/her mail config is working it should be an
opt-in to use that. Sysamins or DD/DMs will likely know what to do,
others should not need to care.

Compare:
> Will reportbug often have direct Internet access? (You should answer yes to
> this question unless you know what you are doing and plan to check whether
> duplicate reports have been filed via some other channel.) [Y|n|q|?]? 

and

> Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP
> configured on this computer to send mail to the Internet? [Y|n|q|?]? 

This should default to No.

bug filed ;-)

If sending a report fails, the message is saved to /tmp, and no advice
is given how to send the message by other means. I'm not afraid of
sendmail-ish programs, but I guess most of the non-developer users even
don't know what it is, or what to do with the message draft.

I understand Pedro's suggestion to implement an additional transport
from bugreport to BTS. I do not see a big difference to the mail
transport system.

What is the advantage of having a mail-only BTS reporting mechanism? One
thing would be to have a quite reliably working mail adress of the
reporter. There is no difference to a HTTP base reporting system. One
can easily get the mail config wrong, intentionally or by accident. In
fact, reportbug asks you for your name and mail address. If you really
want to be shure you need a three way handshake to verify the mail
adress, either way.
One thing I can think of is spam. How is spam handled with mail
currently? What would be the difference to HTTP?

Finally, BTS has a web frontend to read bug report, which I assume is
the preferred way of access. Why prohibit this way of transport for the
other direction? It does not need to be a web frontend for reporting or
replacing reportbug as preferred way to report bugs, just HTTP transport.
No one would think if reportbug to rely on mail transport for getting
the bug list...

Regards

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ire3if$54t$1...@dough.gmane.org

Re: Anyone looking at darcs?

[Gunnar Wolf]

Sandro Tosi dijo [Thu, May 19, 2011 at 02:37:45PM +0200]:
> >> and where was rudeness?
> >
> >> should I add flowers and kisses to emails?
> > ^^^
> > This.  This is rudeness.
> 
> oh really? thanks for letting me know.
> 
> > Lose the sarcasm, if you wish to communicate more effectively.
> 
> Thanks for the lecture, so sad I didn't ask for one.
> 
> why not concentrating on doing something productive instead of mailing
> non-sense? (ah please avoid replying I'm doing it, since some else
> started the "teach the stupid guy a lesson" subthread.)

Sandro, we have collectively walked a long way towards making the
Debian ecosphere less harsh. There is no need to be gratuitously rude,
we only lose potential contributors. Please don't use that tone when
writing to Debian mailing lists.


signature.asc
Description: Digital signature

mcs maintainership

[Andrew O. Shadoura]

Hello,

Considering that Adam Cécile (Le_Vert) hasn't been doing much work on
the package in question (mcs), and that I have prepared a packaging
for the new and the last upstream version, I'd like to become a new
maintainer for the package at least for the time this package is still
in use by at least one another Debian package.

These are the changes I've made to the packaging:

  * New upstream release.
  * Use dh7 and DebSrc3.0:
- Drop dpatch.
- Drop README.source.
- Use dh_installdocs instead of *.links tricks.
  * debian/control:
- Depend on autotools-dev (>= 20100122.1) which supports dh7.
- Update Standards-Version to 3.9.2.
- Updated the homepage.
- Updated the descriptions of the packages.
- Added Vcs-* fields.
- Purged KConfig backend.
  * Ship *.symbols and *.doc-base files.
  * Link with --as-needed.
  * Don't output ANSI codes during the build process.
  * Ship doxygened documentation (Closes: #521010):
- Run Doxygen on build.
- Also depend on LaTeX/TeXLive and Ghostscript.

Jakub Wilk agreed to sponsor this package if there will be no
objections from the current maintainer.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: 'Alioth' status update

[Yaroslav Halchenko]

I would also really appreciate any information on the status/future of
lists.a.d.o. 

With best regards,
Yaroslav

On Mon, 23 May 2011, Dominic Hargreaves wrote:

> One particular concern I can think of is that mail service
> (for lists.alioth.debian.org, and does alioth.debian.org also have
> a mail service?) is brought back up soon, because after 4 days we'll
> start losing mail queued on remote servers.

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523182844.gb16...@onerussian.com

Re: Conditional Recommends

[David Kalnischkies]

On Mon, May 23, 2011 at 18:41, Simon McVittie  wrote:
> However, consider gstreamer0.10-pulseaudio: it's a plugin for GStreamer
> applications to output audio through the PulseAudio daemon. Neither GStreamer
> nor PulseAudio should depend on the other: GStreamer applications can equally
> well use ALSA, OSS or even ESD, while PulseAudio can be used for output by
> plenty of non-GStreamer audio APIs.

Package: gstreamer0.10-pulseaudio
Provides: gstreamer0.10-audiosink

Package: rhythmbox
Depends: gstreamer0.10-audiosink


In that situation you want to choose the "best" provides based on certain
rules which is a different problem as the output plugin is not optional,
you can just choose one out of many, but at least one is needed to be able
to hear something…
(Not really limited to provides through, its the same for "simple" or-groups.)


Using something like Recommended-By here feels like a trick as you don't
want to recommend the installation of gstreamer0.10-pulseaudio at install
time of gstreamer0.10 or pulseaudio, but at the time a package needs an
audiosink for gstreamer0.10 you want one installed (not just recommend one).
(arguable, in this specific case the difference isn't very big)


Best regards

David Kalnischkies


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

Re: Conditional Recommends

[Carsten Hey]

* David Kalnischkies [2011-05-23 16:31 +0200]:
> On Sun, May 22, 2011 at 16:07, Carsten Hey  wrote:
> >  * Conflicts, Breaks, ..., Enhances:
> >   - satisfied if any of the clauses is true
>
> Uhm, a Conflicts/Breaks is satisfied if all clauses are false.

This misunderstanding is caused by the unclear definition of when
a Conflicts/Breaks is "satisfied", it is (depending on the definition)
either satisfied if a package can be installed, or if a package can not
be installed.

According to De Morgen's law, the following are equal:

Given that no installed package conflicts with or breaks package X,

… package X conflicting with "A, B , C" can be installed if all are
false, otherwise it can not be installed.

… package X conflicting with "A, B , C" can not be installed if any
is true, otherwise it can be installed.


> That way you could say Conflicts = ! Pre-Depends.
> (regarding "…": Replaces doesn't fit to well in here…)
> (Enhances are reverse-suggests so i really don't understand
>  why it is in the same enumeration as Conflicts/Breaks…)

"Depends: A, B, C | D" is equivalent to "Depends: A & B & (C | D)",
although the latter is not a valid syntax in Debian.  The commas in
'Depends:' fields can be read as 'and'.

"Conflicts: A, B, C" is equivalent to "Conflicts: A | B | C" and the
commas in 'Conflicts:' fields can be read as 'or'.  Alternatively, it
could also be read as "Pre-Depends: !A & !B & !C" - which would be very
similar to "a Conflicts/Breaks is satisfied if all clauses are false".

"Enhances: A, B, C" is equivalent to "Enhances: A | B | C" (the package
is suggested if A, B or C is installed).  Given that the package with
the 'Enhances:' control field is X, "Suggests: X" in packages A, B and
C would do the same.


'Conflicts:' and 'Enhances:' both do somehow the opposite of
'Pre-Depends:' or 'Suggests:' and are both in DNF.  'Depends:' et al.
are in CNF.

Also being in DNF is the reason I put 'Enhances:' into the same
enumeration as Conflicts/Breaks.


> > If we allow logical 'and' in clauses of disjunctive fields and add
> > a field similar to 'Enhances:', but for reverse recommendations instead,
> > the above example could be written as:
> >
> >        Package: A-plugin-B
> >        Depends: A, B
> >        Recommended-By: A & B
>
> Such a plugin 'Enhances: A' and maybe only 'Depends: B'.
> A plugin like xul-ext-firegpg (removed & discontinued upstream) enhances
> iceweasel and depends on gpg. Still, i don't think it would be a good
> idea to add something like 'Recommended-By: iceweasel & gpg'
> as this promotes this plugin nearly to priority (desktop-)standard…

Using a field 'Depends-Alternatively:' instead of alternative
dependencies via pipe symbols in the 'Depends:' field would be
a less sane solution, e.g.:

Package: foo
Depends: libc6 (>= 2.3.4)
Depends-Alternatively: debconf, cdebconf

… instead of:

Package: foo
Depends: libc6 (>= 2.3.4), debconf | cdebconf


The above would have been a very similar way to express things as the
proposed 'Recommends-When:'.  The main point of my mail was to propose
a more consistent alternative to 'Recommends-When:'.  I don't know the
details why gnome needs this or what exactly is planned for tdeps and
thus can't judge if 'Recommends-When:' or my alternative is a good idea
at all.


> If you want to your package manager (front-end) to suggest you to install
> the plugin if you have A, B or A & B installed then please go ahead and
> implement it in your front-end.

This would be even more wrong than implementing DPkg::Pre-Invoke and
DPkg::Post-Invoke in apt instead of dpkg.


> It will be for example interesting in stable to stable+1 upgrades:
> The dependency trees are already now very long and big, it doesn't
> help in any way if we add even more subtrees and make them
> conditional… (you want an example? udev effected kde: #610991)

I needed to upgrade epiphany-browser (or alternatively remove packages
I did not want to remove) to be able to upgrade to apt/squeeze because
of some python-libraries.


> Also, just imagine for a second we have such a field, then exactly is
> your package manager supposed to install A-plugin-B?
> Remember: New Recommends of a package are installed on a
> package upgrade - and i will come back to you at the time i am forced
> to implement logic to decide if A & B is compared to A & B & C a new
> Recommended-By clause or not…
>
> (We have such a problem already for or-groups in recommends)
> Beside that the notion of 'new' is interesting in case A-plugin-B is new
> in the archive and package A or B are upgraded (new compared to the
> last time the packages were upgraded) …

Yes, this could be "interesting" :)


> > To prevent problems with partial upgrades, a logical 'and' should only
> > be allowed in fields that do not exist in Squeeze.  After Wheezy, they
> > could be allowed in 'Enhances:' too and if there are according use
> > cases, maybe even in Conflicts 

Bug#627723: ITP: ocaml-mm -- Multimedia library for OCaml

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis 

* Package name: ocaml-mm
  Version : 0.1.0
  Upstream Author : The Savonet Team
* URL : http://savonet.sf.net/
* License : LGPL+link exception
  Programming Lang: OCaml
  Description : Multimedia library for OCaml

ocaml-mm is a toolkit for audio and video processing
in OCaml. It provides a standard interface and various
usual manipulations on audio data, images and video data.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523212447.2623.96385.reportbug@leonard

Bug#627724: ITP: ocaml-voaacenc -- Voaacenc bindings for OCaml

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis 

* Package name: ocaml-voaacenc
  Version : 0.1.0
  Upstream Author : The Savonet Team
* URL : http://savonet.sf.net/
* License : CPL
  Programming Lang: OCaml
  Description : OCaml bindings for the voaacenc AAC encoder

ocaml-voaacenc is a binding for libvoaacenc, which provides
AAC audio encoding.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523212713.2799.39378.reportbug@leonard

Re: Alioth status update, take 3

[Francesco Poli]

On Mon, 23 May 2011 22:35:00 +0200 Roland Mas wrote:

[...]
>   Status update for the Alioth situation:
[...]
> - read/write access to the repositories through SSH happen on
>   vasks.debian.org; the repositories have adresses that look like
>   $scm.debian.org/$scm/$project, for $scm in arch bzr cvs darcs git hg
>   svn;
> 
> - anonymous read-only access to the repositories is available by HTTP
>   from wagner, at URLs that look like
>   http://anonscm.debian.org/$scm/$project for $scm in arch bzr darcs git
>   hg;
> 
> - Git and Subversion also allow anonymous read-only access to the
>   repositories through a dedicated protocol, with URLs such as
>   git://anonscm.debian.org/$project/$project.git and
>   svn://anonscm.debian.org/$project/; I can't seem to get the equivalent
>   for CVS (pserver) to work right now;
> 
> - repository browsers for the major SCM tools are also available from
>   wagner, see http://anonscm.debian.org/ for the links.

I apologize in advance if this is a naive question, but: does this mean
that _all_ Vcs-* control fields in _all_ packages (that have them) have
to be changed?
Does this mean that _all_ existing personal repository clones (I am
thinking about git repository clones, for instance) have to change
their remote URLs (both for read-only access via specific protocol,
such as git://, and for write access via ssh://)?

I hope that some appropriate re-directions may be set up real soon now,
so that previous URLs can continue to work as before...


P.S.: Please keep me in Cc: on replies, since I am not subscribed to
debian-devel. Thanks!

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpBxVaTB4vU5.pgp
Description: PGP signature

Re: Conditional Recommends

[Carsten Hey]

* Eugene V. Lyubimkin [2011-05-22 18:08 +0300]:
> On 2011-05-22 16:07, Carsten Hey wrote:
> > 'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive
> > scanning in the package database.
>
> Conflicts and Breaks do not. So, yes, partly true. I personally don't
> want one more reverse-field to handle;

Two remain, good enough ;)


> > Anyway, this subthread is all about reverse recommendations, even with
> > negations you would need to scan the whole repository for implications
> > in 'Recommends:' fields, or they would neither solve the tdep problem
> > nor the original problem (see the end of this mail).
>
> I did not spot further statements about this in the end of your mail.

The point I had in mind is that forward recommendations, i.e.,
'Recommends:' require more effort to maintain than backward
recommendations for tdeps and similar packages.  Below mentioned is just
one way to implement the package relationships for tdeps, IIRC somewhere
in this thread the real plans to do so are mentioned.


tdeps with backward recommendations:

Package: hexahop

Package: hexahop-l10n-$LANGUAGE
Recommended-By: hexahop & translations-$LANGUAGE

The above is all the would be needed, additional to either a real
package translations-$LANGUAGE or a virtual package with this name
provided by hexahop-l10n-$LANGUAGE.


tdeps with forward recommendations:

Package: hexahop
Recommends: !translations-da | hexahop-l10n-da,
!translations-de | hexahop-l10n-de,
!translations-es | hexahop-l10n-es,
...


tdeps with forward recommendations and indirection:

Package: hexahop
Recommends: hexahop-translations

Package: hexahop-translations
Recommends: !translations-da | hexahop-l10n-da,
!translations-de | hexahop-l10n-de,
!translations-es | hexahop-l10n-es,
...

The third example with indirections would have advantages if one l10n
package contains the translations for multiple packages (which seems to
be planned).


Additionally, tdeps could be some kind of leaf packages, as mentioned in
http://lists.debian.org/debian-project/2011/03/msg00039.html or just
depend on the according package they provide translations for.


> So, no, this subthread is not about reverse recommendations, it's about
> conditional recommendations. I don't need to rescan the whole repository
> to satisfy '!A | B-plugin-A' given I scanned it once for Provides.

If apt and cupt don't (which would be correct, on a second thought),
installing translations for new languages would be all but easy for
users, unless package managers provides a clever way to do this.


Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523215906.gb22...@furrball.stateful.de

Re: Alioth status update, take 3

[Stig Sandbeck Mathisen]

Francesco Poli  writes:

> I hope that some appropriate re-directions may be set up real soon now,
> so that previous URLs can continue to work as before...

If you have a specific example of something that does not work, it can
be fixed.

-- 
Stig Sandbeck Mathisen
  ooo, shiny!


pgpS25Sqtp03c.pgp
Description: PGP signature

Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]

[Michael Biebl]

Am 23.05.2011 22:35, schrieb Roland Mas:
> - anonymous read-only access to the repositories is available by HTTP
>   from wagner, at URLs that look like
>   http://anonscm.debian.org/$scm/$project for $scm in arch bzr darcs git
>   hg;
> 
> - Git and Subversion also allow anonymous read-only access to the
>   repositories through a dedicated protocol, with URLs such as
>   git://anonscm.debian.org/$project/$project.git and
>   svn://anonscm.debian.org/$project/; I can't seem to get the equivalent
>   for CVS (pserver) to work right now;
>   We should now be in the phase where we pretend it's done, wait for the
> complaints, and fix the problems as they are reported

It looks like

git://git.debian.org/ and
svn://svn.debian.org/

no longer work for anonymous access. That basically means that existing Vcs-*
fields are broken. I hope the old URLs still continue to work, or do you expect
maintainers to update debian/control to use the new URL scheme?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Anyone looking at darcs?

[Erik de Castro Lopo]

Sandro Tosi wrote:

> On Wed, May 18, 2011 at 00:10, Erik de Castro Lopo  
> wrote:
> > Is anyone looking at getting the latest version of darcs into unstable?
> >
> > If not, I will have a crack at it.
> 
> Why didn't you ask its maintainers (or at least cc them)? why didn't
> you report a bug against darcs asking for the new version to be
> packaged? why didn't you check darcs pts page[1], where you would have
> seen they're looking for a new maintainer[2]?

Sorry, I actually meant to send this to the debian-haskell list
where the maintainer (who recently said he wanted to drop the package)
is subscribed as are many others who are interested in haskell and/or
darcs.

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110524090342.ba592047.mle+deb...@mega-nerd.com

Re: Alioth status update, take 3

[Russ Allbery]

Stig Sandbeck Mathisen  writes:
> Francesco Poli  writes:

>> I hope that some appropriate re-directions may be set up real soon now,
>> so that previous URLs can continue to work as before...

> If you have a specific example of something that does not work, it can
> be fixed.

windlord:~/tmp> debcheckout libpam-krb5
declared git repository at git://git.debian.org/git/pkg-k5-afs/pam-krb5.git
git clone git://git.debian.org/git/pkg-k5-afs/pam-krb5.git libpam-krb5 ...
Cloning into libpam-krb5...
git.debian.org[0: 217.196.43.140]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
checkout failed (the command above returned a non-zero exit code)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874o4l811e@windlord.stanford.edu

Bug#627729: ITP: ocaml-flac -- OCaml bindings for the FLAC audio decoding/encoding library

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis 

* Package name: ocaml-flac
  Version : 0.1.0
  Upstream Author : The Savonet Team
* URL : http://savonet.sf.net/
* License : GPL
  Programming Lang: OCaml
  Description : OCaml bindings for the FLAC audio decoding/encoding library

This module provides OCaml bindings for the FLAC audio decoding/encoding 
library.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523232429.24494.8672.reportbug@leroy

Bug#627731: ITP: ocaml-schroedinger -- OCaml bindings for the libschroedinger implementing the Dirac video encoding/decoding algorithm

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis 

* Package name: ocaml-schroedinger
  Version : 0.1.0
  Upstream Author : The Savonet Team
* URL : http://savonet.sf.net/
* License : GPL
  Programming Lang: OCaml
  Description : OCaml bindings for the libschroedinger implementing the 
Dirac video encoding/decoding algorithm



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110523232925.24827.34546.reportbug@leroy

double checking Debian's 686-pae vs. -486 probe

[jidanni]

Recently Debian sid split the kernel into these two packages,

linux-image-2.6.39-1-486_2.6.39-1_i386.deb
linux-image-2.6.39-1-686-pae_2.6.39-1_i386.deb

My Thinkpad ended up being told by the installation scripts to use -486.

But my Thinkpad isn't really very old... how can one double check to see
if the decision was correct? I can't figure it out even after probing
the .debs to find just where they probe the choice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739k5ynn6@jidanni.org

Re: double checking Debian's 686-pae vs. -486 probe

[Russell Coker]

On Tue, 24 May 2011, jida...@jidanni.org wrote:
> But my Thinkpad isn't really very old... how can one double check to see
> if the decision was correct? I can't figure it out even after probing
> the .debs to find just where they probe the choice.

Why not just install the other kernel and try booting it?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105241037.40889.russ...@coker.com.au

Re: double checking Debian's 686-pae vs. -486 probe

[jidanni]

> "RC" == Russell Coker  writes:
RC> Why not just install the other kernel and try booting it?
Maybe it will lead to subtle data loss. You never know. That's why I was
hoping to dig out of the .debs just how they determine which Thinkpads
are hip, and which to skip.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqn8yj1f@jidanni.org

Re: Alioth status update, take 3

[Yaroslav Halchenko]

on a related note (although not as critical as restoration of
git://git.d.o which I expect to impact  thousands:

$> grep git:// 
/var/lib/apt/lists/debian.lcs.mit.edu_debian_dists_sid_main_source_Sources | wc 
-l
3716

)

where previously available could be now?
http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file

both
http://anonscm.debian.org/viewvc/dep/
http://anonscm.debian.org/viewvc/deps/
seems to be empty

?

Thanks in advance for clarifications

On Mon, 23 May 2011, Russ Allbery wrote:
> > If you have a specific example of something that does not work, it can
> > be fixed.

> windlord:~/tmp> debcheckout libpam-krb5
> declared git repository at git://git.debian.org/git/pkg-k5-afs/pam-krb5.git
> git clone git://git.debian.org/git/pkg-k5-afs/pam-krb5.git libpam-krb5 ...
> Cloning into libpam-krb5...
> git.debian.org[0: 217.196.43.140]: errno=Connection refused
> fatal: unable to connect a socket (Connection refused)
> checkout failed (the command above returned a non-zero exit code)
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110524023948.gc16...@onerussian.com

Re: Conditional Recommends

[Goswin von Brederlow]

David Kalnischkies  writes:

> environment. I can already hear someone asking for
> Package: libc6
> Recommends: libc6-686 {arch::supports:cmov}
> which soon evolves to a complete language in which you really need
> all the funky stuff like & and | and ! together with hard/soft constraints…

That case would easily covered by multiarch and partial architectures.
There would be a i686 arch with just the optimized packages and apt/dpkg
would allow that arch if the cpu supports it. The configuration doesn't
even have to be in apt/dpkg but there could be a arch-detect package
that contains the detection logic and outputs suitable config for
apt/dpkg.

This would also solve the problem of having to use wrapper scripts,
diversions or runtime detection in binaries to provide an optimized
version.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hb8k3iac.fsf@frosties.localnet

Re: double checking Debian's 686-pae vs. -486 probe

[Goswin von Brederlow]

jida...@jidanni.org writes:

>> "RC" == Russell Coker  writes:
> RC> Why not just install the other kernel and try booting it?
> Maybe it will lead to subtle data loss. You never know. That's why I was
> hoping to dig out of the .debs just how they determine which Thinkpads
> are hip, and which to skip.

No. The kernels check the cpu features on boot. They either work or not.

As for your initial question: Depending on how you install the
installer has different sets of kernels to choose from. Due to space not
all kernels are on all images so sometimes you get the fallback option
because the right one simply isn't available.

Also try the -amd64 kernel. If supported that is generally preferable to
686-pae.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aaec3hia.fsf@frosties.localnet

Re: Alioth status update, take 3

[Guillem Jover]

Hi!

On Mon, 2011-05-23 at 22:35:00 +0200, Roland Mas wrote:
>   We should now be in the phase where we pretend it's done, wait for the
> complaints, and fix the problems as they are reported.

The project web sites do not seem to work anymore, for example:

  
  

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110524052945.ga22...@gaara.hadrons.org