> 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 t
> 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 VirtualB
>> 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 vi
> 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 unfortunatel
lined above?
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 debian
>> 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 ge
>> 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 particul
> 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 swa
> 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
> 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 un-up
> 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?
-- Julius
> 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
upstre
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 list
Tollef Fog Heen 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 would be eve
> 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 i
> 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
> 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 c
> 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 w
>>> 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 fin
> 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? Contac
>> 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 o
> 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 issu
>> 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
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 "strac
>>> 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-e
> 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. (Not
> 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 c
>>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 softwar
> 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 thin
>> 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
> 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
> | 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
> 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 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.
-- J
> 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:
> 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 deb
> 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
w
> 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.
-- Ju
> 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 gra
> 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
> 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 beha
> (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 multi-
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 system
> 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 signa
> 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
Thanks to both of you -- I've forwarded your messages to my (soon-to-be
former, sigh) users.
--Juliusz
pgpdCt7J6BkEQ.pgp
Description: PGP signature
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] http://packages.debian.org/l
>> 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
pgpEstR4god
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 mak
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 RFC
> | 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
>> 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 "un
>> 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
> 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 mis
>> 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 administr
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 humb
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 hig
> 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 ope
> 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.
> 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
> 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 fo
>> 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
ank you for your attention,
Juliusz Chroboczek
pgpkR46Mlau0d.pgp
Description: PGP signature
--- Begin Message ---
Dear Firefox/Iceweasel user,
Thanks for your interest in Firefox/Iceweasel and the bug report you have
contributed.
Your bug report [0] was
>> 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
the X
server to use x86emu instead of vm86.
Or am I missing 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 is
> 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 dou
> 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
