Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: makefs
Version : 20090724
Upstream Author : The MirOS Project
* URL : http://www.mirbsd.org/cvs.cgi/src/usr.sbin/makefs/
* License : 4-clause BSD
Programming Lang: C
Description
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser <[EMAIL PROTECTED]>
* Package name: libbsd-arc4random-perl
Version : 1.30
Upstream Author : Thorsten Glaser <[EMAIL PROTECTED]>
* URL : http://www.mirbsd.org/man3/arc4random
* License : MirOS L
Hi everyone,
as shown in http://thread.gmane.org/gmane.linux.debian.devel.release/17423
there's currently a discussion to use dash as /bin/sh instead of GNU bash.
Until now, /bin/sh used to be a symbolic link to /bin/bash, unless dash and,
later, mksh offered to install themselves there instead,
Pierre Habouzit dixit:
>I don't see a valid reason for the
>user to chose what lies behind /bin/sh.
Debian policy allows it.
>If he wants to use his favourite
>sh shell features in his scripts, he shall use #!/bin/favouritesh and
Indeed, since #!/bin/sh scripts must not use non-POSIX features.
Henrique de Moraes Holschuh dixit:
>There is just too much crap out there that thinks /bin/sh is bash.
Not in Debian – /bin/sh scripts must be POSIX compliant and not use
extensions, and with my experience from mksh (minus the “stop” alias
issue, which, with mksh R30, became a non-issue), and see
Henrique de Moraes Holschuh dixit:
>OTOH, specifically using something else than /bin/sh for a fast
>POSIX-with-the-extensions-Debian-mandates shell
No, that will not make sense. People who write #!/bin/sh scripts
should be tought that they can only use so-and-so few things.
//mirabile
--
I bel
Mike Hommey dixit:
>Yeah, they should be given solaris's /bin/sh.
That's a Bourne shell, not a POSIX shell. Try /usr/xpg4/bin/sh there.
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy
Pierre Habouzit dixit:
>> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463
This is just clueless script writers and general whining; these
issues could be fixed one by one. (Actually, even with current
Debian policy, they're bugs.)
> * [[ for test, trivial: add it as a test alias,
Thanks for keeping me in the Cc ☺ (but I guess I earned that from a PR)
Marco d'Itri dixit:
>Bad idea
Give the user the tools to shoot himself into the foot. Besides, dash
is already using the debconf dance, so why discriminate other shells
that are fine to do it according to policy?
>bash (the
Oleg Verych dixit:
>02-08-2007, Peter Samuelson:
>> unset foo
>> [ -n $foo ] && echo foo is non-empty
>> [[ -n $foo ]] && echo foo is non-empty
>>
>> As you can see, only the second one works.
True, that's why the Korn shell invented [[.
>Not quoting possible empty argument is a script wr
Goswin von Brederlow dixit:
>find -name \*mp3 -print0 | xargs -0 mpg123 -z
Hm. This just proves my example sucks ☺ Of course you've got
a point here, but I don't want to make another one…
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: kwalletcli
Version : 2.01
Upstream Author : Thorsten Glaser
* URL : https://www.mirbsd.org/kwalletcli.htm
* License : Code MirOS, Logo LGPL
Programming Lang: C, C++, mksh
Description
Raphael Geissert debian.org> writes:
> The shared debconf prompt idea was already discussed and discarded in one of
> the d-devel threads
Ah, okay. Didn’t know that.
> before the change was made. Which is what Thorsten's
> idea was all about.
Well, I hope you’ve got some better idea then ☺
Russ Allbery dixit:
>>> architectures which are expected to be part of Debian. Debian has
>>> needed to adapt to BSD behavior, non-standard or not, since the project
>>> decided to include the kfreebsd architectures. That's part of porting.
>
>> What is wrong with porting kfreebsd behaivour inst
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: ejabberd-mod-shared-roster-ldap
Version : 0.5.1
Upstream Author : Marcin Owsiany
* URL : https://alioth.debian.org/projects/ejabberd-msrl/
* License : GPL
Programming Lang: Erlang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi *,
since upstream appears dead for 4+ years, bugs are piling up, and it
doesn’t even compile with php 5.3 any more, I give up trying to pak-
kage this thing.
I’ll probably change Evolvis to use popen() or somesuch… ☹
bye,
//mirabilos
- --
Supp
Okay, again; waldi told me there are missing information,
and that debian-de...@lists.d.o has to be Cc’d.
Package name: php-perl (Binary: php5-perl)
Version:1.0.0
Upstream Author:Dmitry Stogov
Licence:PHP 3.0 (upstream), GPL (packaging)
Language:
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: openoffice.org-altsearch
Version : 1.2.2
Upstream Author : Tomáš Bílek
* URL : http://extensions.services.openoffice.org/node/525
* License : LGPL v2.1 or later
Programming Lang
Dixi quod…
>Ibwill publish URI (for criticism &c.) later.
.oO(the BTS doesn’t seem to cope with WTF-8 quite right)
https://eurynome.mirbsd.org/debs/dists/hardy/wtf/pkgs/openoffice-ext/openoffice.org-altsearch_1.2.2-1~wtf804+1.dsc
This is what we’ll use at work¹ for now; the final version will
o
Rene Engelhard dixit:
>Actually no, it's not. And it has some RC bugs right now even from
>quickly looking at it
Thanks for looking at it, still.
>- Depends: openoffice.org-common
>
>"for Writer". Please depend on writer. (which in turn depends on -common
>anyway)
Okay. I only looked for whic
On Thu, 12 Jun 2014, David Kalnischkies wrote:
> For your attack to be (always) successful, you need a full-sources
> mirror on which you modify all tarballs, so that you can build a valid
> Sources file. You can't just build your attack tarball on demand as the
Erm, no? You can just cache a work
Russell Stuart debian.org> writes:
> messages. One of the reasons raised for not doing it is some felt
> uncomfortable carrying around their GPG keys when travelling.
>
> My initial reaction was "that's being overly cautious" particularly
> given there signing every message doesn't mean you hav
Gunnar Wolf gwolf.org> writes:
> using entropy to seed a PRNG, if you have several shitty entropy
> sources and one _really_ good one, and you xor them all together, the
> resulting output is as random as the best of them. If your hardware
Your theory may be good, but we are talking about a scen
On Wed, 18 Jun 2014, Paul Wise wrote:
> Unicode 7.0 was recently released. I discovered some source packages
> contain outdated copies of various Unicode data files. At minimum, the
For mine, mksh and jupp do, but they do not use the data files directly.
Instead, when Unicode is updated, I change
Henrique de Moraes Holschuh dixit:
>Make it generic, instead. You could just automatize the table update
>through a script, and allow it to either fetch the data over the network
>using curl/wget/whatever (default), or to get the data from a local file.
It’s a bit more than a table. Also, the pr
Sylvestre Ledru debian.org> writes:
> > Build systems that ignore those environment variables are broken and
> > need to be fixed.
> >
> Yes, but we have plenty of packages not honoring CC, CXX or CLFAGS.
Yes, but I have a GCC patch (in MirBSD) that can make such builds
fail, by adding a non-sta
Ondřej Surý sury.org> writes:
> Or we can just keep db5.3 forever and wait what will BSD folks do.
> Maybe we will end up with LibreDB (*cough*)...
We have what essentially became db185 in libc, so there is no
need for that ;-) All the dbm functions are in libc already.
(This also holds true for
Ondřej Surý sury.org> writes:
> True, but gdbm is GPL and LGPL and that's a problem for many non-GPL
> applications using Berkeley DB now.
For applications that are not limited to the on-disc file format
compatibility, but just need an easy key/value storage API, like
gdbm users, you could just
Adam Borowski angband.pl> writes:
> On Wed, Jun 18, 2014 at 02:54:43PM +0200, Thorsten Glaser wrote:
> > > Unicode 7.0 was recently released. I discovered some source packages
> > > contain outdated copies of various Unicode data files. At minimum, the
> >
>
Simon McVittie dixit quod...
>On 25/06/14 15:43, Svante Signell wrote:
>> Regarding mate desktop policykit-1 build-depends on libsystemd-login-dev
>> only for linux-any. What functionality is missing for other
>> architectures?
[...]
>In Debian 7, PolicyKit could answer the question "is Svante logg
Russ Allbery dixit quod...
>Simon McVittie writes:
[ startx ]
>> a virtual console, a locked X screensaver is worthless, because someone
>> can just switch virtual console with Ctrl+Alt+Fn, press Ctrl+C and
>> they're in your shell session.
>
>This doesn't change anything else that you point out,
>No, it didn't work. You had to be root for operations as simple as
>shutting down the computer.
Only on Debian. OpenBSD and MirBSD have:
-r-sr-x--- 1 root operator 122716 Sep 10 2013 /sbin/shutdown*
I never understood why Debian doesn't.
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debi
Wookey wrote:
>+++ Matthias Urlichs [2014-06-26 11:58 +0200]:
>> Hi,
>>
>> Andrew Shadura:
>> > [14]http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+sysvinit&show_installed=on&want_legend=o
>n&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%Y-%m&beenhere=1
>> >
>> Sorry
Svante Signell wrote:
>On Thu, 2014-06-26 at 11:59 +0200, Ansgar Burchardt wrote:
>> On 06/26/2014 11:34, Thorsten Glaser wrote:
>> >> No, it didn't work. You had to be root for operations as simple as
>> >> shutting down the computer.
>> &g
Jean-Christophe Dubacq wrote:
>So that students can do eg ssh mybuddymachine /sbin/shutdown ?
>
>(and they need to be able to shutdown their own machine, power is not free).
Why do people always think that a proposal will automatically
exclude all others?
In your student scenario, you do *not* a
Simon McVittie wrote:
>tl;dr: these frameworks were not invented just to troll you, they do
>have a purpose :-)
Yes, I fully agree. But _please_ also realise that there are people,
a non-neglibile number of them, for whom these frameworks are not an
improvement, and who wish to be not forced to us
Wookey worte:
>> [11]http://users.unixforge.de/~tglaser/debs/dists/etch/wtf/Pkgs/mirabilos-support/
>
>Can it be uploaded please? As has been observed, there is a reasonable
>number of people who would like an easy way to control explicitly
>when/if they change to systemd for pid 1. Having to get
Russ Allbery wrote:
>Thorsten Glaser writes:
>
>> Yes, I fully agree. But _please_ also realise that there are people,
>> a non-neglibile number of them, for whom these frameworks are not an
>> improvement, and who wish to be not forced to use them.
>
>That's
Sune Vuorela wrote:
>The way is to put your time/money where your mouth is and provide the
>code. Asking others to do all the work is not the way forward in OSS.
I highly doubt you can call _me_ someone who does not do work in OSS.
You know, methods to clone a human being, time turners, etc. have
Romain Francoise dixit:
>Finally, please note that this new flag will not be used on m68k, or1k,
>powerpcspe, sh4, and x32. The stack protector itself is currently
Doko said he’d upload gcc-defaults with *all* arches set to 4.9 next.
If you upload after him, that will suffice. (Or rather: set cor
Andrei POPESCU dixit:
>Yes, I know everything in Debian is a package, but APT *is* the master
>of all packages :p
Wrong:
• dpkg (directly or via dselect) does not use APT’s system
(well, not necessarily, anyway)
• aptitude has been known to ignore the view dpkg/apt have
on the system, e.g.
Juliusz Chroboczek wrote:
>So I'm turning to this list for help:
>
> 1. Could some competent person tell me the right way to tell apt that it
> should fail an upgrade rather than installing systemd? I guess
> I could make a dummy package that conflicts with systemd, but I'm
I made such
Jeroen Dekkers wrote:
>Wookey wrote:
>> I think some people are failing to see the humour in this name
>> (and Dawkins knows we could use some humour round this subject), but I
>> guess if it's not going to be allowed then it's not going to be
>> allowed.
>
>Yes, I also completely fail to see the
Juliusz Chroboczek wrote:
>Emilio Pozuelo Monfort wrote:
>> You have not yet explained why apt pinning is not enough.
Simply because apt is not the only way to install packages.
> - conflicting packages are honoured by dpkg, unlike pinning;
> - a package can conflict with multiple packages, whil
Matthias Urlichs wrote:
>Thorsten Glaser:
>> >> 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 ther
On Thu, 3 Jul 2014, Didier 'OdyX' Raboud wrote:
> The proper solution is to stop trying to hide ourselves from to the fact
> that some sort of systemd interfaces have been made unavoidable in
> modern desktop environments (fact which is rightfully reflected in our
Eh… you know… these are not a
>Yet I didn't see any proposal for a "consolekit-must-die" package=
Must be because most people did not even get consolekit installed.
Or because it was not that intrusive?
(People "in the know" avoided *kit for a long time already anyway.)
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debian-
OdyX wrote:
>all means, go for it. That said, as far as I remember, the latest GR
>proposal [4] on this subject failed to gather the mandatory K seconds
>though. For me, this indicates that not even K=5 DDs were interested in
I was not even aware of that proposal. This may also indicate lack
of,
Juliusz Chroboczek wrote:
>> 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 aw
Dominik George dixit:
>systemd, in its nature as an init system, starts what you tell it to
>start. There is nothing that can prevent it from starting openntpd if
>you want that. If you through a service file at it, or even an LSB
>init script, then systemd has no choice but to start it.
No, this
Matthias Urlichs wrote:
>Thorsten Glaser:
>> systemd is a backdoor in that, like the availability of Steam
>> games for DDs, it has a chance to hinder the progress of all
>> projects done in the spare time of the people affected.
>Yeah. It "has a chance".
Yes
Steve McIntyre wrote:
>with this constant bickering and sniping. If you must do it, start the
>GR and see how that goes. I even offer to second it just to help get
Can you help formulate? I do not feel my English skills are
up to that.
Also, what options do we need?
1) systemd is the only init
Matthias Urlichs wrote:
>For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to
We're *what*?
(Says someone who uses X11 forwarding, VNC in, VNC out, and all
that on an almost-, if not daily, basis.)
OT: prevent-systemd-*_9_all.deb are in my repo. Wookey, feel
free to u
Norbert Preining wrote:
>On Mon, 07 Jul 2014, Josselin Mouette wrote:
>> If they donât need any of the systemd features, I guess they donât need
>> any of its reverse dependencies either.
>
>Rubbish. I want network-manager, but I don't want systemd.
I donât, but I want most KDE packages, so
Cyril Brulebois dixit:
>Thorsten Glaser (2014-07-12):
>> OK, can you please give-back makefs on mips once the new bmake
>> binaries are available for all buildds?
>
>Please send your request to the appropriate place.
Ookay. Yes, this was a mistake of mine. But it took
Martin Zobel-Helas dixit:
>Furthermore, we will change the people.debian.org web-service such that
>only HTTPS connections will be supported (unencrypted requests will be
>redirected).
This means that requests from wget (since it switched from OpenSSL to
GnuTLS) and other utilities from slow arch
Kibi wrote:
>Joachim Breitner (2014-07-13):
>>Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
>> >> [10]https://www.debian.org/intro/organization
>>not really helpful. It links to
>> [11]https://buildd.debian.org/
>> from where no information about how to query for rebuilds can be
h01ger wrote:
>I've never used "upgrade --purge" _in one step_ and I don't think it's a
>particularily smart idea at all. But if people want to shoot themselves in
The --purge is a no-op with "upgrade".
But I normally use "apt-get --purge dist-upgrade" both to upgrade
across distros and to stay
h01ger wrote:
>On Sonntag, 13. Juli 2014, Thorsten Glaser wrote:
>> >Furthermore, we will change the people.debian.org web-service such that
>> >only HTTPS connections will be supported (unencrypted requests will be
>> >redirected).
>> This means that reques
il it back to the list.
List works for me…
>On 14 July 2014 09:53, Thorsten Glaser wrote:
http://www.afaik.de/usenet/faq/zitieren/ please don’t top-post
or full-quote.
Thanks,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on
Dixi quod…
>Martin Zobel-Helas dixit:
>
>>Furthermore, we will change the people.debian.org web-service such that
>>only HTTPS connections will be supported (unencrypted requests will be
>>redirected).
[…]
>Take it as a heads-up to maybe move stuff elsewhere, if it needs http
>(e.g. APT repos work
Guillem Jover wrote:
>Exactly. I don't have any intention to change the current dpkg-source
>default behavior in that regard.
ACK.
But people who touch packages without d/s/format can just
write "1.0\n" into it, to retain existing behaviour without
the warning. Still, changing the default is bad
Russ Allbery wrote:
>Steven Chamberlain writes:
>> * first-forked process does not use the PRNG yet, but forks again
Actually, it does: it calls RAND_poll(), which libressl made
into a nop.
>control. There has been some talk of implementing PID randomization
>precisely to make this attack har
Ben Hutchings wrote:
>Since Linux 2.6.29, you get 128 random bits at each execve(), which you
>can access like this:
getauxval() is only in (e)glibc, not in dietlibc or klibc, though.
Also, glibc already uses all 128 bits in some other place.
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debia
Tollef Fog Heen wrote:
>> What are the reasons behind are you going for required and not standard?
>
>A Priority: required package (init) isn't allowed to depend on something
>with Priority: standard per policy.
Among even minbase, there are a *lot* of violations of this
particular rule of Policy
Luca Falavigna wrote:
>> Among even minbase, there are a *lot* of violations of this
>> particular rule of Policy. There is also nothing in place
>> checking them.
>
>Actually, there are two tools to check this:
> * [4]https://ftp-master.debian.org/override-disparity.gz
Ah, that's new... before
Luca Falavigna wrote:
>IMO, these should be handled on a case-by-case basis.
Agreed.
>Looking more at it, it seems there are a lot of packages requiring
>dependencies which are extra:
There is a bug in the file, IMHO, though:
mediawiki:
dependency:
php5-mysqlnd: extra
The situation is:
Cameron Norman wrote:
>I noticed that not doing the libraries cause apt to try to upgrade them
>on dist-upgrade and do some weird operations like try to remove my
>current init system and install systemd-sysv or remove all of systemd,
>as well as NM and udisks and a lot of other packages.
FWIW, t
Vincent Lefevre wrote:
>Screen sessions, SSH sessions and computation processes running in
>background are lost after a reboot, not after a relogin.
AIUI this is not true for systemd: once the "session" is
terminated, all background processes run in it are killed
too. There are lots of duckduckgo
Brian May wrote:
>* "apache2-reverse-dependency-calls-invoke-rc.d" - due to legacy fall back
>code that restarts Apache2.2 automatically.
Yeah, I'm overriding this one too.
>* "non-standard-apache2-configuration-name" - due to the fact I need to
>supply different configuration files for apache2.
Andreas Cadhalpun:
>So it's good that FFmpeg upstream does that backporting.
As opposed to, for example, MySQL and Iceweasel, for which
there is practically a blanket permission to upload new
upstream releases unchecked into stable. (There appears to
be one for Mediawiki and OpenJDK too, which do
On Thu, 31 Jul 2014, Don Armstrong wrote:
> 11. The prospective libjpeg-turbo maintainer should propose an appropriate
Who *is/are* the maintainer(s), anyway?
There are packaging bugs being ignored, and there is an open
bug on a non-release architecture whose suggested workaround
(or possibly fi
On Thu, 14 Aug 2014, Thomas Goirand wrote:
> Just a quick explanation of what I'm doing with the python-xstatic-*
> packages here. I've thought about how to do it best for a long time.
Thanks! I was wondering.
> It is also worth noting that the Debian package version for XStatic
> modules is fol
Brian May dixit:
>In what way will python-xstatic-jquery be better than libjs-jquery?
No.
What I meant is:
| Package: python-xstatic-jquery
| Provides: libjs-jquery
is better than
| Package: python-xstatic-jquery
| Depends: libjs-jquery
|
| Package: libjs-jquery
because it’s less packages.
On Thu, 14 Aug 2014, Thomas Goirand wrote:
> What would probably work better would be to add the python library
> inside upstream code.
That would work as well.
> But then we have another issue: the Python module is supposed to be
> packaged as python-, and the JS libs are supposed to be
> packa
On Sat, 16 Aug 2014, Thomas Goirand wrote:
> Why would you tag the upstream release? I mean, it's upstream's job to
Yeah, if upstream uses git at least it should NOT be done by
the packager.
If not, it depends.
> > - shall we standardize the "pristine-tar" branch?
>
> As in, always use pristin
On Fri, 15 Aug 2014, Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > The first step is to determine which problem you are trying to solve.
Surprisingly insightful, this one.
> I want to be able to check out a git repository and do packaging work and
> an upload, without having to
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> Like I wrote in another post, "master" doesn't express anything.
ACK.
> All of this is error prone. Using upstream tags and merging them rather
> than branches avoid troubles. I have yet to see a case where using
> upstream tags wasn't practical.
The
On Sun, 17 Aug 2014, Neil Williams wrote:
> > The vast majority (all?) of git packaging repositories have the
> > upstream sources.
>
> No. None of mine do, or will.
I’m working with some which also don’t, and find it would be easier
if there were a way to extract a .orig.tar.gz in the same way
On Sun, 17 Aug 2014, Jonathan Dowland wrote:
> On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> > - encoding (due to git restrictions):
> > ":" -> "%"
> > "~" -> "_"
I’d rather have something that sorts like Debian versions
in “git tag” output…
> "_" -> "_5f"
>
On Thu, 28 Aug 2014, Vittorio Giovara wrote:
> On 17/08/2014 18:15, Clément Bœsch wrote:
> > > - you leeching my work by leveraging git merge daily
> > Welcome to the wonderful world of Open Source Luca.
> Sorry but no, definitely no.
>
> While technically what ffmpeg does is allowed by the (L)GP
On Thu, 21 Aug 2014, Paul van der Vlis wrote:
> There is something called LLVMpipe, it's a software fallback when there
Hm, but LLVM is not available for all Debian (CPU) architectures.
bye,
//mirabilos (let’s make IceWM the default desktop and good is.)
--
[16:04:33] bkix: "veni vidi violini"
On Mon, 25 Aug 2014, Jerome BENOIT wrote:
> > On 25/08/14 16:53, Simon McVittie wrote:
> >> * Debian-foo
> >> * Dfoo
Uppercase may have problems dealing with eMail.
Sometimes, dæmon users may want that. I strongly suggest
to not use uppercase letters in usernames, system or not.
> >> I think I s
On Tue, 26 Aug 2014, Henrique de Moraes Holschuh wrote:
> If you happen to run Debian or Ubuntu on a computer with an old Intel
> processor (Pentium M, Celeron M, Pentium 4 Mobile, Mobile Celeron, Pentium
I’ve got an IBM X40. I can boot Grml off a USB stick, dist-upgrade
and run these commands, i
On Wed, 20 Aug 2014, Jeremy Stanley wrote:
> There still seems to be some legal contention around Apache License
> 2.0 expecting an authors list for a project. And I agree copyright
Not just that one, there are other licences with weird
terms like that.
> significant enough to amend the years/ho
On Sun, 31 Aug 2014, Octavio Alvarez wrote:
> Why don't you use JavaScript? I also don't like enabling JavaScript in
Because I use lynx as browser.
But then, this survey *does* work with Lynx. At least, I get a
success message at the end…
bye,
//mirabilos
--
Sometimes they [people] care too mu
On Tue, 2 Sep 2014, Ondřej Surý wrote:
> On Tue, Sep 2, 2014, at 10:24, Marco d'Itri wrote:
> > I know, but if systems on which xz-utils is not easily available really
> > exist then the interested parties could replace it with xzdec which is
> > small and statically linked.
>
> Is there such syst
On Tue, 2 Sep 2014, Changwoo Ryu wrote:
> In my quick experiments with some font packages, "-Sextream -z9"
> option still gives ~4% smaller size than the default. IMO this is
> still significant for big font packages.
Maybe, but please stick to -Sextreme -z7 at most, nevertheless.
Thanks,
//mir
On Mon, 1 Sep 2014, Adam Borowski wrote:
> Also, should we detect all other attempts to contact the outside network,
> and swat such builds with extreme prejudice?
Yes. These can be privacy breeches, licence violations (download
things that change what gets embedded into the packages), and
all ot
On Mon, 1 Sep 2014, Steven Chamberlain wrote:
> rejected. I hope a Blend would be a more constructive approach. I'm
> thinking sysvinit would be the easiest 'flavour' to implement for
Actually, I think it’s the hardest one.
All others will be task selections run after debootstrap.
Changing th
On Tue, 2 Sep 2014, Adam Borowski wrote:
> > (I’m aware that there is still *too* much “disable the network” in
> > pbuilder. Sorry for not having had the time to work on that. I’ll
> > try to do so shortly.)
>
> Could you tell us what's this "too much"?
#753944
> Here's how I would do it:
> uns
Svante Signell dixit:
> It would be nice to have the same init system:sysv-core, as well as the
> same default desktop:mate-desktop-environment (including accessibility
> enhancements), for all arches: Linux, kFreeBSD and Hurd :-) If possible,
> this could be an option in the advanced menu of the
On Wed, 3 Sep 2014, Changwoo Ryu wrote:
> I think 65MIB for decompressing is OK with current hardwares as long
> as it saves good amount of space and bandwidth.
Not on avr32, and it hurts sh4, m68k and others as well.
bye,
//mirabilos
--
>> Why don't you use JavaScript? I also don't like enabl
On Wed, 3 Sep 2014, Changwoo Ryu wrote:
> I can't imagine any 31 MiB machine which needs to render megabytes of
It’s *additional* memory. On top of kernel, libc, apt, dpkg, and
whatever the user is running in parallel.
bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [
Jonathan Dowland wrote:
> I suppose we should always be sympathetic towards such architectures, but at
> the end of the day we should primarily concern ourselves with release
> architectures.
Such as mips?
On Wed, 3 Sep 2014, Christian Kastner wrote:
> That is the key question, and I believe c
On Fri, 5 Sep 2014, Changwoo Ryu wrote:
> As I said, such lowmem embeded devices don't even need to install big
> packages.
Just you saying so doesn’t make it (more) true. Debian is a
universal operating system… at least it tries to. Maybe one
of these packages contains _one_ file you need to bui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi everyone,
some might have noticed that, once the Debian Linux Kernel Maintainers
activated x32 support in the standard Debian kernels, I cross-graded my
machine at work to it.
I would like to say thanks to the various maintainers involved in thi
On Fri, 5 Sep 2014, Ian Jackson wrote:
> Simon McVittie writes ("Re: daemon user naming scheme"):
> > It is reasonable to use /var/lib/foo (or /run/foo or /var/cache/foo or
> > /var/games/foo) as the home directory of a system user whose name is
> > _foo, debian-foo, Debian-foo or whatever.
>
> Y
On Sat, 6 Sep 2014, Michael Biebl wrote:
> Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
> going to make it the first alternative. Installing a half-broken logind
> whould be a disservice to our users.
Uhm, did you read this subthread at all?
Let me try to summarise:
At
On Sun, 7 Sep 2014, Andreas Metzler wrote:
> I think that is terrible idea, because it makes us release a system
> that is lot less tested than it should be. If only fresh installs were
Nonsense. sysvinit must continue to work anyway, for various
reasons (upgrades, kfreebsd, the TC decision).
Al
1 - 100 of 566 matches
Mail list logo
