> Or an user error. In either case, I don't get what a 32-bit _x86_ virtual
> machine would be good for. Are you teaching some code archeology?
Not at all.
We're trying to make it compulsory for first year students to have a Unix
installation on their personal machine. In practice, this means
> Filing a bug on src:virtualbox with severity 'wishlist' or 'normal' for this
> issue to discuss it with the maintainer of the virtualbox package(s) seems a
> logical thing to do.
Unfortunately, we're speaking about running Debian under VirtualBox under
Windows, so it would need to be something
> When discussing virtual machines it would be helpful to mention which virtual
> machine hypervisor is being used, because the resulting behavior can differ
> depending on hypervisor.
It was VirtualBox under Windows. The underlying issue was that VT-x was
disabled in the BIOS, and hence
>> I've been encouraging my students to install Debian on their personal
>> machines, and we've found out that a lot of them get the wrong Debian
>> installer:
>>
>> - some of them attempt to install an AMD64 version of Debian in
>> a 32-bit-only virtual machine;
> Why are they creating 32-bit
> This is not what I get.
> - 32bit debian on 64bit machine: this should be working fine
> - 64bit debian on 32bit machine: I get the attached message
> If it's not what they get, there is some bug and more investigation is
> needed.
I no longer have access to their machines, so I'm
e?
Thanks,
-- Juliusz Chroboczek
- pipefail,
- local variables,
- array variables.
If dash had those features
Please don't -- some of us appreciate the fact that /bin/sh is
a reasonably minimal shell. Both ksh93 and pdksh/mksh have all three of
those, if memory serves.
-- Juliusz
--
To UNSUBSCRIBE, email to
Standardising on big-endian is a good idea [...]
Except that the endianness war has been won by little-endian
That's not what my mail was about. My point is that the issue with the
software should be resolved upstream, rather than implementing yet another
dodgy hack in dpkg.
Which particular
That's not what my mail was about. My point is that the issue with the
software should be resolved upstream,
in my case, it cannot be resolved upstream,
Yes, abandoned software is a problem, unfortunately quite common in the
scientific community. (Understandably so, since researchers get
The mesh files are stored in binary form, and thus endian-ness
is a worry when moving from one platform to another.
[...]
What is not clear to me right now is how to [store] those data files:
is there an endian triplet ?
Jérôme,
Please try to work with upstream to fix the issue. Byte
Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
wouldn’t it be a good opportunity to make a release goal of killing all
scripts with a #!/bin/bash shebang?
Just to make things clear -- you're advocating #!/bin/sh and running dash
as /bin/sh?
(Likely alternatives include
However, you're doing this during boot, so there *are* no active users,
since the system hasn't come up far enough to let anyone log in yet. So
it makes sense that you don't get a prompt.
Does that mean that the new pid 1 expects users to be logged in before it
starts the system?
-- Juliusz
I'm sure the texlive maintainers feel perfectly justified in breaking
existing setups and causing packages to FTBFS by doing this.
I don't think the comparison between texlive and systemd is quite fair.
Texlive updates don't break users' systems, they just make some packages
temporarily
I would like to make it co-installable with OpenSSL, but in general,
this should be a drop-in replacement until APIs really diverge in a
visible way. Yes, it would provide 'openssl', but I intend to place them
into a different directory, so you might have to use LD_PATH to get
them.
That
Meanwhile, we could try to get ever distro with a clue together, map the
versioned symbol diffs that already exist, and see if we can come up with a
plan to at least do downstream versioning in a compatible way.
Please, please, please speak to upstream first. It's hard work, but some
me:
(I did find his comment funny -- actually, I find the CoC ifself pretty
funny --, but I realise that this is an international mailing list and
that Austrian-Japanese humour is not necessarily obvious to everyone.)
Tollef Fog Heen:
Humour [...] does not work very well on large lists.
The problem is that some people bitch endlessly abut how evil systemd is
_instead_of_ producing software (not just patches) to replace what
systemd offers.
Abstracting away from your somewhat offensive choice of language, that's
a good point. As far as I'm aware, the only major distribution
While I have no interest in joining Norbert in calling for your ban,
Having had the pleasure to meet Norbert in person, I have no doubt that he
was joking when appealing to the CoC. (I did find his comment funny --
actually, I find the CoC ifself pretty funny --, but I realise that this
is an
Tollef Fog Heen tfh...@err.no wrote:
I [...] will try to avoid breaking stuff
I expect no less from a Debian Developer.
but it's also a use case we don't hit, so breakage there is less likely
to be seen by us. We'll do our best to fix it when reported, of course.
That is good to hear. It
You have not yet explained why apt pinning is not enough.
Simply because apt is not the only way to install packages.
Don't synaptic and/or whatever honor these pins too?
I have no idea about synaptic, but there’s e.g. cupt (which
works as apt replacement, but probably (didn’t check)
Juliusz, can you please paste your apt logs
Sent by private mail.
Please send it publicly in the Debian bug tracker.
Sorry, Thomas, but I'm not quite sure what are the privacy implications of
making public the set of packages running on my system. (Probably none,
but I'd rather not find out
You have not yet explained why apt pinning is not enough.
I'd appreciate an explanation too. I've inserted in my apt/preferences
file the incantation given by Vitali F. (to whom thanks) at the very
beginning of this thread, and it appears to have the requested effect.
I've looked through the
Dear all,
A few days ago, after a routine upgrade from testing, the power button on
my laptop ceased functioning. I was busy at the time, so I lived with
having to remember to type sudo shutdown -h now for a few days; yesterday,
I finally took the time to debug the issue.
I started with strace
gentle persuasion [...] is more in line with point 4 of the Debian
Social Contract than [...] bullying?
May I suggest that you treat others the way you want to be treated?
I am not a Debian Developer. I am not bound by the Social Contract.
Are we to expect a higher standard of behaviour
The replies were not just terse, the replies were downright rude.
That's hardly the main problem with Michael's behaviour.
I reported an actual bug, including conclusions that I got from fourty
minutes of tracing the ACPI scripts. Michael closed it straight away,
without investigating the
Michael closed it straight away, without investigating the issue.
Oh, I did. That's why I told you to install systemd-shim.
Now could you please reopen bug 753357, or at least allow me to do it?
-- Juliusz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Juliusz, can you please paste your apt logs showing what pulled systemd
in on the system?
Sent by private mail. If anyone else wants a copy, please drop me a note.
-- Juliusz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Maybe we could have an intermediate goal to patch any daemon to add an
option to not fork on start.
Yes, please. All the more so since it is effort well-spent,
No, this is not an effort well spent. And as already mentioned,
running the daemon in foreground has unwanted side-effects,
Maybe we could have an intermediate goal to patch any daemon to add an
option to not fork on start.
Yes, please. All the more so since it is effort well-spent, as it is
likely to be useful not only for systemd and upstart, but also for
whatever service management daemon comes next. (Note
No, I don't think so. If these external tools double fork then they
are just wrong.
Double Forking has been the right way to do it for decades.
It has been the default way for most daemons, granted. (Getty is
a notable exception.)
Demanding from upstreams that they change their software
From what I've seen in Lennart's posts, adding systemd support doesn't
seem to be too complicated.
No. No changes at all are necessary to be compatible with systemd.
This is a very impressive feature of systemd; at the same time, this is
what complicates systemd, and creates a dependency on
That is very good and has way more chances of changing the status quo
in Debian than any pro- or against-systemd thread on -devel.
Just to clarify -- this is not a pro- or against- thread, which, as I've
tried to make clear in my initial mail, would be premature. My goal is
to get people
It's not like boot speed would be the only reason to avoid shell.
I don't think that avoiding shell implies that all the distribution-
specific initialisation code must be hard-wired in pid 1. I'd be more
sympathetic to the idea of recoding everything in C if the initiali-
sation code lived in
| I'd be more sympathetic to the idea of recoding everything in C if
| the initialiation code lived in separate binaries.
system/ systemd-fsck* systemd-quotacheck* systemd-shutdown*
systemd-vconsole-setup*
[...]
Interesting. Looking at the code, I hadn't noticed these get compiled
into
Not rocket science about ipc only a loop and two signal to catch:
- get SIGING: respawn systemd
- get SIGUSR2: spawn a sulogin shell
- check if systemd child die, respawn it if needed (rate limited)
All the funky stuff is done by a child of init.
Hmm If you want to support forking
It seems this problem (double fork) is the basement of using cgroup
under systemd ;)
I think messing around with cgroups is a ridiculous way to solve this
problem.
To be fair, systemd also uses cgroups to reliably kill rogue child
processes when stopping a service. This is not unlike what
I think only supporting Linux is entirely his perogative: It's his
project, his time and he can support what he wants.
Hmm. I may be wrong, but I was under the impression that he's pushing
systemd as the standard init, not just as his hobby project. Josselin
may have more information.
--
start-stop-daemon (and/or a new C helper that is run like s-s-d and
does some of the same things as systemd)
Another architecture would be a daemon that is run from inittab, but
yes, your have a point there.
-- Juliusz
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
It's actually lighter than sysvinit, from what I've seen so far,
$ size /sbin/init /bin/systemd
textdata bss dec hex filename
300401320 612 319727ce4 /sbin/init
79369167482188 802627 c3f43 /bin/systemd
-- Juliusz
--
To UNSUBSCRIBE, email to
It's not a simple portability problem, systemd relies on very complex
Linux-specific stuff.
Well, having looked at the code, yes and no.
Yes, because systemd recodes the whole startup process in C.
Translating a lot of distritibution-specific shell code into C is not
going to be portable:
$
I have not seen any serious attempt at measuring how big this impact
actually is
I'd expect some important differences between shell script based init
and systemd-type init
Yeah, that's everybody's intuition too. But Steve is right -- it would
be good to see some real benchmarks.
--
Dear all,
Systemd[1] is the currently fashionable next-generation init
replacement, intended to replace both System V init and Ubuntu's
upstart. Since the Debian systemd package is now operational, I've
decided to try running it on my laptop. Here are my observations after
three days with
(I'm the systemd maintainer in Debian)
(Shakes hands.)
| Another case that I've actually been bitten by is that systemd
| hard-wires runlevel 5 in its SV init compatibility code;
It does?
I stand corrected, it's actually part of the configuration (symlink from
runlevel5.target to
This looks quite correct to me? (It's also what's shipped in the package.)
I'm confused, then. After installing systemd the first time, systemd
happily ran the init.d scripts that I had disabled in rc2.d but left
enabled in rc{3,4,5}.d. We can probably agree that this is not the
expected
So cgroups is optional, but not really if you want a supported
systemd installation :)
Yes, and that's exactly what I find worrying about Lennart's attitude:
he presumes to impose his policy on you -- you must use Linux, you must
use a recent kernel with cgroups enabled, you're not supposed to
What does systemctl show $service tell you?
I've now reconfigured my laptop to have identical rc?.d directories, so
I cannot easily reproduce the issue.
| Could you point me at where exactly systemd decides which of the rc?.d
| services to start?
default.target
It's linked to
Currently there are still some outstanding issues before we can really
start using multiarch.
Is there anything upstream maintainers should be doing in order to help?
(Except writing makefiles that allow easy cross-compilation, of course.)
-- Juliusz
pgpmIaWRYiIGs.pgp
Description: PGP
Hi,
I'm upstream for Cedilla [1,2], which has been orphaned and removed from
Sid. I'm receiving e-mail from Debian users of Cedilla, asking me what
is the suggested replacement. What shall I answer?
--Juliusz
[1] http://www.pps.jussieu.fr/~jch/software/cedilla/
[2]
Thanks to both of you -- I've forwarded your messages to my (soon-to-be
former, sigh) users.
--Juliusz
pgpdCt7J6BkEQ.pgp
Description: PGP signature
There is always the option of either recruiting one of those
disappointed users to maintain the package, or doing it yourself.
Thanks for the suggestion -- but I'm already spending all of my
proverbial Copious Free Time on upstream work.
It seems a shame to lose a bug-free package when you
Why is it that suddenly everyone is an expert in double-stack programming?
Brian May:
For me, bindv6only=0 seems like an ugly hack designed to make existing
applications work without change.
Bindv6only=0 is a way to allow servers to be written to listen to just
one socket, which allows making
With bindv6only=0, a v6 socket bound to :: will not accept v4
connections, full stop. With bindv6only=0, connecting a v6 socket to
a v4-mapped address will not work, full stop.
That's obviously a typo -- I meant bindv6only=1.
Juliusz
Dear all,
I would like to raise the issue of #560238 once again.
In netbase 4.38, Marco d'Itri has unilaterally decided to change the
value of the net.ipv6.bindv6only sysctl to 1. This change has the
following effects:
(1) it violates POSIX 2008, Volume 2, Section 2.10.20;
(2) it violates
What if it is just installed from the tarball?
Then that person is still using buggy, non-free software.
Proprietary, granted, but why buggy? bindv6only=0 is assumed by both
POSIX and RFC 3493.
--jch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
| bindv6only=0 is assumed by both POSIX and RFC 3493.
As the default value, yes. Not as the only possible value.
Please stop repeating this legend, it is simply not true.
POSIX 2008, Volume 2, Section 2.10.20 is extremely clear that AF_INET6
sockets can be used for IPv4:
Applications
If POSIX-compliant apps may only work with one setting then the standard would
say only this setting is compliant with POSIX. Since it does not,
Yes it does. Section 2.10.20, see the paragraph titled Compatibility
with IPv4.
You might argue that having this in the POSIX standard is a mistake,
The apparent consensus is being ignored -- the default value is still
- nobody cares about the consensus in the peanut gallery
I am not quite sure what to do with this sentence.
You have single-handedly broken peoples' systems, with no advance
warning. When people have complained, you have
unless I've missed something, I'm under the impression that people
agree that the change was a mistake.
Not again...
What do you mean?
The apparent consensus is being ignored -- the default value is still
the one that people don't want.
On Linux bindv6only is configurable by administrator,
I've been reading through the archives in order to find out if there's
been any consensus on the controversial change to the default value of
net.ipv6.bindv6only -- and unless I've missed something, I'm under the
impression that people agree that the change was a mistake.
May I therefore most
Package: wnpp
Severity: wishlist
* Package name: ccl
Version : 1.3
Upstream Author : Clozure Associates (Gary Byers)
* URL or Web page : http://openmcl.clozure.com/
* License : LGPL with Lisp exception
Description : Clozure Common Lisp (formerly OpenMCL)
Ccl is a
As a maintainer and a user, I have often wondered lately if the practice of
tracking numerous upstream bugs in the Debian BTS is something that should
be ended.
Please don't.
I always ask my downstream DDs to forward bugs to me together with the
Debian bug number, and to leave the bug open
for your attention,
Juliusz Chroboczek
pgpkR46Mlau0d.pgp
Description: PGP signature
---BeginMessage---
Dear Firefox/Iceweasel user,
Thanks for your interest in Firefox/Iceweasel and the bug report you have
contributed.
Your bug report [0] was done
Since this particular bug is trivial to reproduce (ls
~/.mozilla/firefox/), it would appear that the Firefox maintainers
are mass-closing bug reports without even checking what they are
about.
Considering that the message which has been sent to you does not close
the bug, nor does it do
If you can't find the time to triage old bugs, it's kinda hard to
convince a volunteer to do it for you.
I am not quite sure what you mean.
Are you saying that in order to submit a bug against a Debian package
without it being summarily closed, I need to be a member of the
development team for
Also node that many bugs are sometimes hard to reproduce, because you
need a very specific environment that the maintainer not always have
(e.g. the issue I have is that as a glibc maintainer, I've no large
enough and used pam-ldap or NIS setups, and we have some bugs that rot
because I
The insult isn't the request for help. The insult is the implication
that if there's no response, the bug will be summarily closed with no
attempt made to see if the problem reported is fixed.
Very well put. That's exactly the bit that got me annoyed.
The Firefox monoculture is doing a lot of harm to our community.
So, I don't know what monoculture you're referring to.
Popcon gives 23000 for iceweasel, 500 for dillo, and 18 for netsurf.
(Correct me if I'm wrong, but I believe that konqueror statistics are
not significant since it's also
+ Firefox developers should all know what to compete against, free closed
source programs are a means to communicate concepts and benchmarks between
developers
I think this is a very important point.
The Firefox monoculture is doing a lot of harm to our community. Just
like Linux learnt a
something?
Juliusz Chroboczek
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi Tom,
(I am the upstream author of Polipo.)
I have just checked the sources of polipo 0.9.8-1, and this bug is
still present. This is a serious security bug, but is mitigated by
the Debian installation.
The bug allows anyone who has access to Polipo's local web server to
read any file that
Usually, when I get problems with xpdf on a PDF, it is a PDF
1.5. Either it simply doesn't work, or very slowly, or text search
doesn't work in the PDF.
Lionel,
In my experience, the Xpdf upstream author is very responsive to bugs.
If you provide him with a suitable test case, I have no doubt
I am strongly against compressing PDFs
To add insult to injury, PDF 1.5 introduces ``object streams'' which
allow compressing arbitrarily long chunks of a PDF file without giving
up the random-access properties of PDF. All current Free PDF readers
grok PDF 1.5, although as far as I know no Free
72 matches
Mail list logo
