Vincent Lefevre wrote:
> So there's something contradictory. If the pipewire service alone
> doesn't take control of audio over pulseaudio, then the only culprit
> would be pipewire-media-session. Or what? A bug in pipewire, which
> would actually take control of audio even without pipewire-pulse?
Michael Gilbert wrote:
> How can you possibly think no more need said? You are one of four
> complicit in the act that finally pushed Joey over the edge [0].
>
> [0] https://lists.debian.org/debian-ctte/2014/11/msg00045.html
Please take that message with a pound of salt. I was upset when I wrote
It's become abundantly clear that this is no longer the project I
originally joined in 1996. We've made some good things, and I wish
everyone well, but I'm out.
Note that this also constitutes an orphaning as upstream of
debhelper, alien, dpkg-repack, and debmirror.
I will be making final orphani
Josselin Mouette wrote:
> GNOME works on all Linux architectures.
>
> GNOME *without hardware 3D* will probably have big trouble running
> anywhere but on i386 and amd64.
> So in the real world, it depends on the architectures:
> * real-world desktop powerpc hardware comes with hardware 3D
Christoph Anton Mitterer wrote:
> For git it's e.g. quite clear that it's use of SHA1 *is* security
> relevant.
I've talked about this with the git developers before, and while they
seemed to have some ideas for how to handle a conversion to a different
hash, they're not keen on doing it until for
Thorsten Glaser wrote:
> On Mon, 13 Oct 2014, Joey Hess wrote:
>
> > Only thing I don't understand is why so few votes for systemd-shim out
> > of the group who has it installed.
>
> Maybe noatime? That’s probably popular on desktops. “vote” does
> not really sa
Joey Hess wrote:
> A small percentage of server users are avoiding swiching to systemd,
> although that group looks to still be shrinking somewhat.
Of course, not many people use unstable/testing for servers, so we don't
really know much from popcon yet about whether server admins
Henrique de Moraes Holschuh wrote:
> Right now it is the "defaults" effect, because Debian stable is included in
> the report. We don't have a "testing + unstable" report.
Yes we do: sysvinit-core systemd-sysv systemd-shim
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-sys
Santiago Vila wrote:
> Before systemd arrived, it was possible to have a chroot free from
> init packages (not needed to build packages).
It seems reasonable for debootstrap --variant=buildd to omit any init
systems, if it doesn't already.
--
see shy jo
signature.asc
Description: Digital signa
Jonathan Dowland wrote:
> Thank you very much for doing this. I would love to see Debian transition to
> having this facility disabled by default at some point in the future.
Florian Weimer's patch doesn't go that far, instead environment
variables have to have special BASH_FUNC_FOO() names before
Theodore Ts'o wrote:
> One thought... there will probably be trademark concerns with "unix".[1]
> So we might have to choose a name for the tasksel task to be someting
> like "unix-like".
Or we could just call it "standard system".
--
see shy jo
signature.asc
Description: Digital signature
Russ Allbery wrote:
> No, I'm pretty sure that currently works. But I don't know how much that
> relies on modifications to Debian's tar package.
It doesn't matter what tar was used to create the original tarball; as
long as we know the files present in it, we can use a (necessarily
stable versio
Ian Jackson wrote:
> Do you intend to review (or are you reviewing) the decision taken in
> July 2012 [1] ? If so, is this discussion here on -devel useful ? If
> it is useful, what questions should we be focusing on ?
See my 1st message to this thread.
Can't say I've found most of the thread u
Yves-Alexis Perez wrote:
> I actually think having no default desktop would be just fine, instead
> having the current 3-4 desktop installation media. Then anyone can pick
> the DE she likes.
I recently spent some time installing community computer labs in rural
Brazil. Internet bandwidth was near
Incidentially, I don't much appreciate the counterproductive sniping
that Jordi added in his blog post about this. Perhaps you're not aware,
Jordi, but switching to xfce was discussed at last DebConf. It was not
done "announced in a git commit log".
--
see shy jo
signature.asc
Description: Digi
Jordi Mallach wrote:
> In addition to this, moving to Xfce now would mean yet another transition to
> a new desktop (if we consider GNOME 2.x → 3.x a transition, which it is),
Would that we had considered that when shipping wheezy...
> which would mean a new round of adapation for users installin
Jordi Mallach wrote:
> Accessibility
> Hardware: GNOME 3.12 will be one of the few desktop environments to support
> HiDPI displays, now very common on some laptop models. Lack of support for
> HiDPI means non-technical users will get an unreadable desktop by default, and
> no hints on how to fix
Filed a few bug reports on this:
#756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs
#756978 dgit: .tar-less push
The possibility of the second one is .. pretty amazing!
--
see shy jo
signature.asc
Description: Digital signature
Ansgar Burchardt wrote:
> * Architecture-independent (arch:all) packages must be included in
>uploads.
That can be read 2 different ways.. I hope it means:
If you have an arch:all, you have to upload it, but if there is none,
you can upload with no .debs. Is that correct?
--
see shy jo, sti
Tollef Fog Heen wrote:
> > On kfreebsd, init would then depend on an optional package as we don't
> > support arch-specific priorities. That is (IIRC) a policy violation, but
> > do any practical problems arise from this?
>
> It would be useful to have a comment from one of the debootstrap
> maint
Jeroen Dekkers wrote:
> You forget one of the big problems with OpenSSL that LibreSSL doesn't
> fix: the license. It actually makes the mess even bigger, given that
> some of the GPL exceptions only talk about "the OpenSSL library" and
> don't exempt OpenSSL-derived code. So even if LibreSSL is a d
This thread seems to be discussing the wrong problems[1].
We currently have the problem that systemd is still not installed by
default by debootstrap, despite the tech ctte decision being made months
ago. It's not clear what the right solution to that is; should
debootstrap special-case systemd o
Henrique de Moraes Holschuh wrote:
> Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that
> case, the kernel won't use it and it disappears from /proc/cpuinfo, and we
> could do that also to avoid processor errata, not just due to user request.
> However, AFAIK kernel blacklist
Christoph Anton Mitterer wrote:
> reopen 749795
> I'm reopening this for now, even if the issue is solved from a technical
> point of view (see below why).
AAICS, #749795 talked about bringing this to the security team's
attention, but they never seem to have been CCed.
So the security team may n
Jacob Appelbaum wrote:
> On 6/11/14, Joey Hess wrote:
> > I stumbled over a library which has switched to using RDRAND in a new
> > upsteam version (not yet packaged), instead of /dev/urandom[1].
>
> Which library is using it?
I didn't want to name names and am more
Josh Triplett wrote:
> However, just as we encourage projects to reuse libraries rather than
> copying code around, we *should* encourage projects to use standardized
> randomness libraries rather than hardcoding rdrand (or, for that matter,
> hardcoding /dev/urandom).
Performance aside, why is a
I stumbled over a library which has switched to using RDRAND in a new
upsteam version (not yet packaged), instead of /dev/urandom[1].
I don't have a stong opinion on the security of RDRAND, which is a
contentious topic in a domain I am not expert in. However, I would much
rather rely on linux deve
Petter Reinholdtsen wrote:
> #!/lib/init/init-d-script
> ### BEGIN INIT INFO
> # Provides: daemon
> # Required-Start:$remote_fs $syslog
> # Required-Stop: $remote_fs $syslog
> # Default-Start: 2 3 4 5
> # Default-Stop: 0 1 6
> # Short-Description: nice daem
Henrique de Moraes Holschuh wrote:
> Hmm? That's interesting, given that bug report I was cc'd (and which I later
> cc'd you asking about the -/_ thing) complaining that dh-autotools-dev-foo
> was not working because of that -/_ mismatch.
Which I answered the same way.
> Is the -/_ fixup a long t
Henrique de Moraes Holschuh wrote:
> On Tue, 24 Dec 2013, Wookey wrote:
> > 2) for dh packages:
> > adding --with autotools-dev to the dh invocation
>
> This is broken. debhelper modules are not allowed to use "-" in the name,
> the correct module name is "autotools_dev" as stated in the document
At DebConf there was an interesting proposal by Colin and Steve to
reduce testing migration times for packages that have an succeeding
autopkgtest. This would increase motivation for adding autopkgtests to
packages. More importantly, it would speed up testing propigation,
without a sacrifice in tes
Bas Wijnen wrote:
> As I wrote, the only thing you need is to search for any package using a
> config script. Searching for db_input path:\.config$ gives for example
> cyrus-sasl2 and bind9 on the first page.
No ,any package using a config script does not use debconf in a buggy
fashion. Sheesh. A
Bas Wijnen wrote:
> Debconf actively overwriting values is slightly different from it giving
> you a wrong default which it then allows you to set to the desired value
> again. The former is overwriting, the latter is just very annoying.
>
> Then again, with debconf's priority scheme, it may well
Bas Wijnen wrote:
(1)
> It's not about overwriting.
(2)
> The point is that debconf will use its own
> cache for defaults, which means that running dpkg-reconfigure and then
> pressing enter on all but the thing you're interested in changing should
> not make any changes on those items, but doe
If someone would really like to improve the state of debconf use in
config scripts, I think that the best approach would be to find a way
to replace the current imperative config scripts with a declarative
format.
--
see shy jo, fan of applicative functors, though sometimes you gotta
Bas Wijnen wrote:
> > (Citation needed.)
>
> http://codesearch.debian.net/search?q=db_get+path%3A.*config%24
If the presence of db_get in a config script was always a bug, then I
[cw]oud modify debconf to not allow db_get in config scripts.
But, it's not. Randomly reviewing only packages I have
Bas Wijnen wrote:
> Currently, many packages only do 2
(Citation needed.)
> packages should implement parsing code for it in its config script. My
> point is that this results in needless code duplication. Therefore I
> would like to move this parsing code to debconf
I'd think it would be obviou
Sune Vuorela wrote:
> On 2013-10-25, Neil Williams wrote:
> > Equally, is there genuine support for tablets within Debian beyond the
> > problems with GUIs and touchscreens? I'm not aware of anything
> > approaching usable GUI support, even discounting touch.
>
> Plasma Active is quite mature and
Gabriel de Perthuis wrote:
> I only know what dgit does from reading the source code. dgit works
> server-side and is only available to DDs; as I understand it it creates
> a new, canonical repo, imports the current version and uses that as a
> base for new uploads. It's useful as part of a maint
Neil Williams wrote:
> Is there one in Debian?
>
> Equally, is there genuine support for tablets within Debian beyond the
> problems with GUIs and touchscreens? I'm not aware of anything
> approaching usable GUI support, even discounting touch.
I know that multiple desktop projects are interested
Sune Vuorela wrote:
> I've said that for years, but we still haven't changed to KDE Plasma
> Desktop as the default.
http://qa.debian.org/popcon-graph.php?packages=task-xfce-desktop+task-lxde-desktop+task-kde-desktop&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&da
> I humbly disagree. I'm mainly interested in the perspectives of systemd on
> servers.
Systemd on servers is offtopic for this thread.
--
see shy jo
signature.asc
Description: Digital signature
Steve McIntyre wrote:
> This goes back to during the wheezy release cycle. There was a little
> discussion around a change in tasksel [1], but rather too late in the
> day for the change to make sense. Now we have rather more time, I
> feel. Let's change the default desktop for installation to xfce
Niels Thykier wrote:
> [KEY-PACKAGES]
> http://udd.debian.org/cgi-bin/key_packages.yaml.cgi
If you're curious, as I was, how this list is arrived at, here's the
source:
http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=scripts/update-key-packages;h=d214dcbbe4aea5b2b49b132a0c135dfef40
Ian Jackson wrote:
> That it doesn't browse well is indeed annoying. On the server the
> dgit suite branch ref names aren't in refs/heads/, which is needed to
> stop git pushing to them by default. But that makes gitweb not show
> them either. I'm open to suggestions for how to improve this.
>
Paul Tagliamonte wrote:
> Key word: we
>
> The issue is, users will think "Oh sure, this'll be a great way to get
> packages! Faster is better, right?"
Users are part of the development and testing infrastructure of Debian.
(Disparaging our users is another problem some of us seem to have..)
--
Ansgar Burchardt wrote:
> The more interesting part of the proposal has so far been ignored by
> most replies: we would make the incoming.d.o archive public. This would
> mean all new uploads are available after ~15 minutes via APT, a lot
> faster than the current interval between dinstall runs.
>
Joerg Jaspert wrote:
> Now there are those of us who think that this is against "the spirit" of
> having multiple dinstalls and that having apt-able incoming repositories
> will only lead to people with "versionitis" repeatedly abuse apt-get
> update, and not actually help development significantly
Ian Jackson wrote:
> Please let's not do this. Doing this would mean that after an upload
> there would be an even longer period where the archive database says
> that sid has version X but in fact it's difficult to find a copy of
> version X anywhere because the main archive and mirrors still hav
Philipp Kern wrote:
> I'd hope that the hashes of the .orig are part of the > -1 .dsc, even if
> not of the .changes (only with -sa).
They are, but dgit builds the dsc.
--
see shy jo
signature.asc
Description: Digital signature
Steve Langasek wrote:
> I would have expected dgit to support pristine-tar
> directly/automatically/unconditionally. Any system that requires me to
> download the same information (== the upstream source) both from a VCS
> repository and the archive in order to get a fully-formed source package fo
Ian Jackson wrote:
> Maybe there should be a way to make the dgit-repos tree a symlink to
> the collab-maint tree. Of course doing that would make it impossible
> ever to sever the two services.
I suspect you can manually remove the collab-maint repository and
symlink it to the dgit-repos reposit
Dmitrijs Ledkovs wrote:
> We have build log analyzers running for the build logs.
Checking heuristically for problems you know about does not help find
the class of problems you don't know about yet.
> How about a new DEB_BUILD_OPTION="silent" which opts into silent build
> log? Does that sound r
Joey Hess wrote:
> (The implementation needs to be improved; it should read both stdout and
> stderr and multiplex them properly. And it should check if stdout is not
> to a TTY, and if so avoid munging the build log output. The only other
> problem is that `make` outputs the line
Joey Hess wrote:
> Making all builds verbose by default has both advantages and
> disadvantages.
>
> The disadvantages include making builds possibly so noisy that when one
> runs them during daily work, once ignores all output. Including
> important compiler warnings.
>
Dmitrijs Ledkovs wrote:
> Is there any reason this hasn't been applied yet?
> Can I NMU this, as debhelper is marked as LowNMU package.
Not for reasons such as allowing patches like this.
Making all builds verbose by default has both advantages and
disadvantages.
The disadvantages include making
Tollef Fog Heen wrote:
> An AGPL licenced libdb isn't particularly useful for us, though. It'd
> mean distributing a fair amount of software including exim, postfix,
> squid, webalizer, dovecot and many other servers under the AGPL, which
> would mean patching them so you could download the source
Russ Allbery wrote:
> Given that the whole point of those files is to test clamav, I would hope
> that they would trigger clamav's detection. If not, that would be a bug
> in clamav, no?
However, the point of the pymilter source package is not to test clamav,
it's to distribute the source to pymi
Seems I confused xgalaga with xgalaga++, which does use dh.
--
see shy jo
signature.asc
Description: Digital signature
Paul Wise wrote:
> Control: severity -1 grave
> Control: reassign -1 debhelper 9.20130518
> Control: affects -1 + src:xgalaga++
> Control: tags -1 - jessie
>
> The FTBFS bug against xgalaga++ (#707481) is caused by debhelper, it
> builds fine with debhelper 9.20120909 but not with debhelper
> 9.20
Paul Wise wrote:
> Probably the rsync package should just ask you via debconf if you want
> to serve any directories and what their names and paths should be.
> Since most folks who have rsync installed don't need rsyncd, the
> default would be to not setup anything.
No, it should not. 60 packages
Christoph Anton Mitterer wrote:
> 2) No more packages that bypass the package management system and secure
> apt:
> a) There are still several (typically non-free) packages which download
> stuff from the web, install or at least un-tar it somwhere without
> checking any integrity information that
Raphael Hertzog wrote:
> I agree that we have such a consensus.
Not for packages installed by debootstrap.
> There was a time where d-i was not ready, but nowadays udeb are compressed
> with xz and busybox's xz is used in that context.
That's not relevant.
--
see shy jo
signature.asc
Descrip
Charles Plessy wrote:
> Conversely, the existence of sites such as Ubuntu's PPA, SourceForge, GitHub
> and many others show that a large number of software providers are confident
> that a policy of a posteriori removals is sufficient. I do not understand why
> we do not reach the same conclusion
Andreas Beckmann wrote:
> Can't we just annotate the foo-source binary package in some way - it
> should be pretty clear to the maintainer that he produces such a
> "special" package.
No, because it's not just foo-source packages.
One example of a package that needs to use built-using is
debian-
Ben Hutchings wrote:
> What I mean is that a changes file for a sourceful upload has
> 'source' (and maybe some real architecture names) in the Architecture
> field. Therefore 'source' cannot be assigned as the name of a real
> architecture.
Ah, sure.
However, "source" in Build-Depends could be
Ben Hutchings wrote:
> Or 'source', short for 'the build-dependency's source code should be
> treated as part of my source code'. This is already reserved as a
> special architecture name for use in changes file.
Hmm, if it's reserved, what use it is reserved for? Wouldn't want to
step on toes. I
The Built-Using field required[1] by recent policy results in some
problems for maintainers:
1. It needs to indicate the exact version of the source package used in
the build. So this has to be kept up-to-date, or dynamically
generated. Updating it manually is busywork and won't reflect
v
Julien Cristau wrote:
> > Maybe I forgot the answer, but at least in terms of git and the dpkg
> > 3.0 (git) format, why can't we simply make use of shallow cloning?
>
> At which point you have lost all the advantages of shipping the
> repository that Tollef mentioned, as far as I can tell. You'r
Samuel Thibault wrote:
> Could it be used to bootstrap ghc compilation way more easily?
Given the number of extensions used in ghc's own code, many of which
jhc does not support, this seems unlikely, at least not without
first mechanically converting its code to an intermediate form like
Haskell 9
Martín Ferrari wrote:
> (you have a really weird reply-to :))
I do? I see no such header..
> For KGB the concept of a repository is a bit fuzzy. It is just the
> unit it uses to separate access control (password), channels to
> broadcast to, and a word in the commit notification. But you can use
Martín Ferrari wrote:
> If you rather use our bots, we'll need you to provide: a project/repository
> name, an IRC channel, and a password (used to avoid spam, not really
> secure).
d-i would like to use your bots, but we have an ever-changing list of
repositories. It'd be wrong to centralize the
Don Armstrong wrote:
> This sort of sounds like Built-Using: only needs to contain things
> which the package doesn't already Depends: (or perhaps even
> Recommends:) on. [Which would resolve the archive licensing
> requirements.]
To to usable to ensure GPL compliance, Built-Using needs to specify
Russ Allbery wrote:
> 7.8
> New `Built-Using' field, which must be used to document the
> source packages for any binaries that are incorporated into this
> package at build time. This is used to ensure that the archive
> meets license requirements for
Package: wnpp
Severity: wishlist
Owner: Joey Hess
* Package name: haskell-network-info
* URL : http://hackage.haskell.org/package/network-info
* License : BSD
Description : listing network interfaces in Haskell
Another library I use in git-annex.
--
see shy jo
Steve McIntyre wrote:
> People have worried about it, but I think the consensus from DebConf
> is that we don't want to be hampered in our own development by
> considering external users
How are "external users" different from "users"?
--
see shy jo
signature.asc
Description: Digital signature
Per Olofsson wrote:
> 2012-07-21 18:37, Joey Hess skrev:
> > gnome-core depends on nautilus, which recommends synaptic.
> > Unless such recommends are being skipped by something, it should be
> > installed.
>
>
> nautilus (3.2.1-2) unstable; urgency=low
>
Mike Hommey wrote:
> Note that slower decompression doesn't necessarily mean longer
> installation time. I/O is still more time consuming than CPU.
Which is why I asked for actual, real-world benchmarks...
--
see shy jo
signature.asc
Description: Digital signature
Filipus Klutiero wrote:
> I tested d-i last week and accidentally installled GNOME. This
> allowed me to confirm that GNOME does not pull Synaptic in testing.
gnome-core depends on nautilus, which recommends synaptic.
Unless such recommends are being skipped by something, it should be
installed.
Hideki Yamane wrote:
> On Sun, 8 Jul 2012 17:58:16 +0200
> Adam Borowski wrote:
> > • xz -6 (the default) is a lot slower when compressing, fast when
> > decompressing, needs only 10MB memory, 58% size
> > • xz -9 has very slow compression, takes gobs of memory, 56% size
> > (Obviously
Cyril Brulebois wrote:
> It looks to me like a current debian-installer build installs grub2,
> with no option for grub-legacy, even in expert mode.
grub-legacy is still used for multipath and sataraid.
Something was going to be done to make grub2 support those, but
I don't know the status.
--
s
> - ftp, telnet: mostly redundant with wget and nc, unless you really like
> cleartext authentication
> - procmail: server
These are priority standard.
> - pcmciautils: PCMCIA is dead
> - jfsutils, reiserfsprogs, ufsutils: obscure
> - discover
> - openssh-server: server, not desktop
> - grub-lega
Alexander E. Patrakov wrote:
> A technology exists that can keep downtime to a minimum. It is called
> "btrfs snapshots", see below for the details. After Wheezy, Debian
> should support it natively in installer, dpkg and apt/aptitude.
That is a rather complicated solution. It has very significant
Ian Jackson wrote:
> > - It allows DMs to grant permissions to other DMs.
>
> It is far from clear that forbidding this is the right thing to do.
As far as I know, we did this intentionally. When a DM is the maintainer
of a package, they should be able to move it to team maintenance without
need
Wouter Verhelst wrote:
> Also, the symlink attack thing isn't just something I made up;
> tmpreaper's REAME.Debian actually warns about that.
It's not particularly hard to securely delete /tmp in single user mode,
ie at boot. Just don't follow symlinks. Tmpreaper's potential for
symlink attacks is
So RAMTMP now defaults to off. I know it can be hard to give ground on
something you've invested a lot of work into, so Roger Leigh has my
respect for taking this thread into consideration.
A lot of people came down on the pro-tmpfs side in this thread. You have
some good reasons to want to make i
Andreas Barth wrote:
> * Joey Hess (jo...@debian.org) [120605 17:53]:
> > I've read over this entire bug, and while there are clearly some hard
> > problems and a lot of good work shown here, I'm seeing a concerning
> > trend throughout it.
>
> I think the is
10 Jun 2010 a bug was filed wanting wine 1.2 packaged in time for squeeze.
12 Aug 2010 packages of 1.2 were available .. but not in Debian.
6 Feb 2011 squeeze shipped with the same wine version that shipped in lenny.
7 Mar 2012 wine 1.4 was released as the new upstream stable release
25 May 2
Roger Leigh wrote:
> OK, some benchmarks were requested in this thread in a few places.
No, a lack of premature optimisation was requested.
When one is engaged in premature optimisation, one does lots of
benchmarks, and finds things that seem to speed up nicely, and
has many happy nice numbers .
Ben Hutchings wrote:
> As will /tmp on a small root partition.
> As will a small dedicated /tmp partition.
The differences between these cases and forcing tmpfs by default is that
in the above cases, the person who installed the system chose those
partition sizes. They are therefore responsible fo
Adam Borowski wrote:
> I think that box had jfs, but other filesystems are no different: for
> example, ext* will fsync() during a rename() call behind your back even if
> you don't request it, forcing every file to hit the disk platters even
> though they'll immediately get changed again. For fil
Roger Leigh wrote:
> I did want to have this for wheezy (#633299). But I lacked the time
> and familiarity with the d-i code, and the d-i developers also have
> higher priorities.
Personally, this d-i developer has as one priority that the system d-i
installs be broadly useful. d-i has at times n
Ted Ts'o wrote:
> The main advantage of tmpfs is that it gets wiped on reboot, and so it
> prevents people and applications from thinking that they can keep
> stuff in /tmp forever. It's also faster because a file system has to
> do extra work to make sure the files are preserved after a reboot.
Josselin Mouette wrote:
> Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> commit the data on disk, and therefore can write it to disk whenever it
> likes, especially when the disk is not too used. There is no need to
> keep a journal nor to access the disk several times to u
Henrique de Moraes Holschuh wrote:
> In fact it is the other way. We have /var/tmp for the large file since
> about forever, and important platforms that have /tmp in memory since the
> early 2000's (Solaris)
>
> And that STILL wasn't enough for people to not screw it up and dump large
> file
Ted Ts'o wrote:
> If you're worried about installations which don't have much memory
> (i.e., the 512mb netbook), then swap is absolutely mandatory, I would
> think!
Not really. I have no legitimate programs that use more than 50% of my 1 gb.
I have an SSD. So why enable swap? If chromium goes cr
Steve Langasek wrote:
> Absolutely not. /run is a root-only directory, suitable only for
> system-wide data/sockets. It absolutely must not be used for non-root data.
With that said, if you want to fill up /run as a normal user,
and screen is installed, you certianly can. There are probably othe
While this has been an interesting thread, it may be predicated on a
false premise. I examined the latest weekly CD build, and the reason no
desktop tasks at all (even lxde or xfce) appear on their respective CDs
is because debian-cd is simply not including tasksel's new task-*
packages, at all.
Guillem Jover wrote:
> Only as long as the debian/control information matches the one from
> the archive override.
I checked, and currently the only base package with an overridden priority
is libsigc++-2.0-0c2a
--
see shy jo
signature.asc
Description: Digital signature
Goswin von Brederlow wrote:
> Joey Hess writes:
>
> > Adam Borowski wrote:
> >> Could you please mention which ones do not? And if so, how are they
> >> relevant/are they fixable?
> >
> > As one of the maintainers of debootstrap, I am perhaps more awa
1 - 100 of 1577 matches
Mail list logo
