Otto Kekäläinen wrote:
> I think this a reasonable suggestion by Soren. […]
Incidentally, the suggestion is good as illegible on a
usual-to-read-longer-text-sized webbrowser on the mailing
list archive (and it would be almost as illegible on the
usual slightly wider-sized work xterm due to its in
On Wed, 15 Jan 2025, Johannes Schauer Marin Rodrigues wrote:
>Quoting Thorsten Glaser (2025-01-15 00:50:55)
>> There should be something in this that says that they need to do so
>> in a way that matches ftpmaster policies.
>
>Do we really need to explicitly codify "plea
On Tue, 14 Jan 2025, Andreas Tille wrote:
>Task description
There should be something in this that says that they need to do so
in a way that matches ftpmaster policies.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Ansgar dixit:
> musescore-snapshot| 2019-07-05 00:19:11.735843+00
I do have plans to pick that up once I find the tuits for it
and have finished the preceding musescore{2,3} uploads. (Lots
to do there.) So please keep that for now.
Thanks,
//mirabilos
--
[16:04:33] bkix: "veni
Sune Vuorela dixit:
>In theory. I don't know if there are any statistics on 'popular'
>3rdparty repositories and their keys. But assuming they're doing key
Hm. My own private repo should be ok (3072R), but my Launchpad PPAs
incidentally are not okay (1024D).
Since this comes from Canonical, they
reopen 1063905
severity 1063905 wishlist
retitle 1063905 mksh: add /usr/bin/mksh{,-static} to /etc/shells
tags 1063905 + pending
found 1063905 59c-23
# well /usr/bin/mksh, /usr/bin/mksh-static is not, see below
notfound 1063905 59c-22
thanks
Russ Allbery dixit:
>After some research with git blame
Russ Allbery dixit:
>Thorsten Glaser writes:
>
>> Right… and why does pkexec check against /etc/shells?
>
>pkexec checks against /etc/shells because this is the traditional way to
>determine whether the user is in a restricted shell, and pkexec is
>essentially a ty
Russ Allbery dixit:
>It does check whether $SHELL is found in /etc/shells. So your question
>about what is setting the $SHELL variable is a good one, although I think
>I would still argue that it's not the most effective way to solve the
>issue.
Right… and why does pkexec check against /etc/shel
Dixi quod…
>Russ Allbery dixit:
>
>>> What sets $SHELL for the reporter’s case? Fix that instead. login(1)
>>> sets it to the path from passwd(5), which hopefully is from shells(5).
>>
>>My guess is that pkexec is calling realpath to canonicalize the path
>>before checking for it in /etc/shells,
Russ Allbery dixit:
>> What sets $SHELL for the reporter’s case? Fix that instead. login(1)
>> sets it to the path from passwd(5), which hopefully is from shells(5).
>
>My guess is that pkexec is calling realpath to canonicalize the path
>before checking for it in /etc/shells, although I have not
Russ Allbery dixit:
>3. Something else that I don't yet understand happened that caused pkexec
> to detect the shell as /usr/bin/mksh instead of /bin/mksh. I'm not
What sets $SHELL for the reporter’s case? Fix that instead.
login(1) sets it to the path from passwd(5), which hopefully
is from s
Matthias Klose dixit:
> you can work around it
Unfortunately not. (The musl packagers might be able to.)
>, this is not an RC issue. Please stop playing
> bug ping pong.
If GCC stops supporting an option it used to support,
and where the GCC documentation say it’s supported,
it in my opinion ve
Helmut Grohne dixit:
>> > rng-tools-debian
>>
>> Also false positive:
>>
>> Replaces: intel-rng-tools, rng-tools
>> Breaks: rng-tools (>= 5migratf), rng-tools (<< 5migrate)
>> Conflicts: intel-rng-tools
>
>This is *not* a false positive, but a real issue. It replaces any
>rng-tools, but breaks
Simon McVittie dixit:
>opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
>of libraries that can support it without breaking ABI, and similarly
Right, but e.g. refuses to work under it.
>That wasn't actually the reason for my concern. As far as I'm aware, the
>glibc dynamic l
Helmut Grohne dixit:
> openjdk-8 (U)
Should be convered by the Depends lines in the respective
binary packages, e.g:
Depends: openjdk-8-jre (>= ${source:Version}),
openjdk-8-jdk (>= ${binary:Version}),
${misc:Depends}
Replaces: openjdk-8-jdk (<< 8u20~b26-1~)
> rng-tools-debian
Also fal
The Wanderer dixit:
>> snes emulator. last upstream release 2007
>>> zsnes deb otherosfs optional arch=any-i386
>
>FWIW: though I haven't touched it in quite some while, I recall from all
FWIW, I occasionally use zsnes and it works well.
But yes, hand-written assembly was part of that IIRC.
by
Simon McVittie dixit:
>On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
[…]
>> i.e we could keep the existing i386 for the gamers and have i386t64
>> (or whatever we call it) for ongoing use of i386 as a real OS.
>
>On Fri, 09 Jun 2023 at 16:39:38 +, Thorsten Glaser w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Helmut Grohne dixit:
>I'm inclined to call this consensus now and therefore ask those that do
>not agree with it to reply here - even if your reply is only stating
I disagree.
I would like to see a long-term commitment against electronic waste
and
Ansgar dixit:
>the stretch, stretch-debug and stretch-proposed-updates suites have now
>also been imported on archive.debian.org. People still interested in
>these should update their sources.list.
Might be useful to note that stretch-updates should be dropped from
sources.list but has been empty
kilobyte wrote:
>At this point, I'd just enable os-prober unconditionally, and think of a
Erm, *no*?!
os-prober corrupts data when called (in virtualisation/emulation
guests, at the very least).
Steve wrote:
>I'm also pondering tweaking things in d-i to re-enable os-prober if
>the system look
Steve McIntyre dixit:
>Please go and *read* and *respond* in debian-vote. The discussion is
>there, not here.
I wrote where the Reply-To pointed to. Perhaps if that had been
correct…
>You've utterly missed Phil's point about people not seeing or hearing
>boot options.
I didn’t. I pointed out th
kilobyte dixit:
>Funny thing: there's not a single release architecture that's both
>bad-endian and supports X (they do build X related packages because the
>dependency graph is quite dense, but there are no users). So this
Meh. Remote X, X forwarding over SSH, VNC and RDP servers exist.
So do d
Thorsten Glaser dixit:
>PS: Please do Cc me on replies.
Phil Morrell dixit:
>> Is there support for something like A but not enabled by default?
>> That is, you have to actively select a nōn-default option
>
>I don't believe so, because that doesn't solve the p
Didier 'OdyX' Raboud dixit:
>If these tests are run at build-time, errors halt the build and that provides
That may not be enough, though; there are cases where the build
architecture determines artefact endianness (e.g. with PCF bitmap
fonts), and that may even be enough (X servers can load PCFs
Debian Project Secretary - Kurt Roeckx dixit:
>it are available at: https://www.debian.org/vote/2022/vote_003
Hrm.
Is there support for something like A but not enabled by default?
That is, you have to actively select a nōn-default option in the
boot menu so that the installer loads the non-free
Adam Borowski dixit:
>> These bugs are subtile miscompilations. In mksh, only one test
>> by accident fails due to the GCC LTO bug. It’s definitely *not*
>
>What was the last version of gcc that you have tested?
8, 9 and then-snapshot, i.e. 10 prereleases. So, pretty recent.
>> (As for dietlibc,
Matthias Klose dixit:
>The goal is to enable this optimization by default in an upcoming
>Debian release in dpkg-buildflags for 64bit architectures. The goal
>is to get this package to build with link time optimizations, or to
>explicitly disable link time optimizations for this package build.
T
Daniel Pocock dixit:
[ nōnsense ]
For all those who also got this eMail despite not being directly
subscribed to d-devel, apparently, “Software Freedom Institute SA”
is Pocock (didn’t someone ask for Init7 to do something about him?)
and blocking 195.8.117.0/24 and 2001:67c:1388::/48 in your firew
>"apt-get upgrade” doesn’t upgrade the linux-headers to the latest
>fixed version
You need “apt-get upgrade --with-new-pkgs” at the very least to keep
a stable system up-to-date. I use “apt-get --purge dist-upgrade” myself
while keeping an eye on what packages apt wants to remove with that.
bye,
Lucas Nussbaum dixit:
>column on https://udd.debian.org/cgi-bin/format10.cgi )
I’m apparently affected at least for cvs, but that package has
another very interesting use case for format 1.0:
Its .diff.gz file can *directly* be used as patch file in no less
than *two* other packaging systems (BS
Paul Gevers dixit:
>
> * **Unblock request** deadline: > 2021-08-03 12:00 UTC <
>
> - You must submit your unblock request *before* then
> - Your changes must be ready to migrate
Andreas Metzler dixit:
>1. Make merged-/usr-via-aliased-dirs the only supported layout and make
>this information available to apt. (Like we did for multi-arch-support.)
>2. After that individual packages can safely move files from / to /usr,
>pre-depending on merged-usr-support.
This will still
Johannes Drexl dixit:
>embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that
>/usr is allowed to be not only on a separate partition, but even on a
>network device shared by other machines:
This hasn’t been true on Debian for a while (partially due to the
systemd/usrmerge propone
Marc Haber dixit:
>think we can afford an additional time sink at the moment. Please, get
While that’s true…
>Can we please delay this discussion until after the release? I don't
… we can’t afford to: the TC discussion becomes valid as soon as
bullseye is released, which is in two weeks, and th
Guillem Jover dixit:
>I've been meaning to send a note about this for some time now, but
>as I feel it keeps getting ignored, it always seems a bit pointless.
Yeah, I saw this popping up multiple times in that bugreport ☹
>But in any case, given that merged-usr-via-aliased-dirs is not really
>su
Sean Whitton dixit:
>* #978636 move to merged-usr-only?
>
> We were asked to decide whether or not Debian 'bookworm' should
> continue to support systems which are not using the merged-usr
> filesystem layout. We decided that support should not continue beyond
> Debian 'bullseye'.
What? WHAT
Hi Paul,
> FTBFS) but it avoids busywork for maintainers that are not involved in
> bootstrapping java. Machine time is cheap, volunteer time is not.
this is not for bootstrapping. This is to prevent building of language
bindings for e.g. Java on platforms where there is simply no Java.
This is a
Hello Sean,
>> Does this mean merging copyright headers that differ only,
>> for example, in the copyright years for a given author, is
>> no longer permitted? If so, please consider this a protest
>> from me as that would go against usual and accepted practice.
>
>No, that's still intended to be
Sean Whitton dixit:
>The copyright information for files in a package must be copied
>verbatim into ``/usr/share/doc/PACKAGE/copyright`` when
Does this mean merging copyright headers that differ only,
for example, in the copyright years for a given author, is
no longer permitted? If so, p
On Wed, 24 Jun 2020, Emmanuel Bourg wrote:
> Version : 2.0.0~RC1
Given how long some packages stay in milestone status (some for
six years!) I’d prefer for there to be an actual 2.0.0 release
first before this can enter Debian.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-
On Sat, 23 May 2020, Sudip Mukherjee wrote:
> I have now made a list with package name, the jar files that it
> provides and the list of class that the jar provides.
This must be scripted/scriptable though… the list for stable is
pretty much fixed, but the one for unstable (which is the relevant
On Wed, 6 May 2020, Andreas Tille wrote:
> > Or perhaps we need a webpage or wiki page generated by parsing the
> > Contents file and listing the matching Debian package for each class
> > or, at least, Java package (unless split across multiple packages)…
>
> I remember times when such a web page
On Wed, 6 May 2020, Andrej Shadura wrote:
> I wonder could we improve the package description and maybe add some
YES please, me either. Why even Geronimo, why not Jakarta’s, which
is the most latest?
> Provides or something to make it clear? I saw changes to packages adding
Or perhaps we need a
Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser
* Package name: jamulus
Version : 3.5.1
Upstream Author : Volker Fischer
* URL : http://llcon.sourceforge.net/
* License : GPLv2+
Programming Lang: C++/Qt
Description : real-time collaborative
Arnd Bergmann wrote:
>is clearly needed anyway. Once there is a working armhf version with
>full time64 user space, there can be a separate discussion about what
>to do with the i386 port (phase out i386 before y2038, migrate all of
>i386 to time64 quickly, have two separate i386 ports, or somethi
gregor herrmann dixit:
>On Tue, 12 Nov 2019 15:08:56 -0700, Sean Whitton wrote:
>> optimising for writing these files, I don't think we should be expecting
>> people to come up with a package-specific reason if they find themselves
Thanks.
>> I'd like to suggest this recommendation could be of th
gregor herrmann dixit:
>Lately we as a project, guided by the DPL, have been in
>recommendation mode anyway: "Use dh(1) unless you have a reason not
>to", "Use git(1) and salsa unless …".
>
>I think "Write d/copyright in Copyright-Format 1.0 unless you have a
>specific reason not to do this for a
Andreas Tille dixit:
>explicit wish to not use DEP5. I wonder what other reasons might exist
>to explicitly stick to the non-machine readable format.
I prefer human-readable format. I also often deal in software which
has more… flexibility than the DEP 5 format allows, or where it is
plain simpl
Sam Hartman dixit:
>depend on non-free software. Github is a common example of a web
>service that uses non-free software.
So is Salsa. It does not use the packaged version of GitLab,
which is in a sorry state anyway, and not suitable for a stable
release, but the proprietary “open core” versioi
Dominik George dixit:
>>than you think, either bind-mount tons of filesystem from the host,
>>and this is only safe-ish if both run sysvinit
>Why should that not work on systemd?
I wrote safe-ish and deliberately didn’t focus on this
as it’s not relevant for the point I was trying to make.
Long
Hi Simon,
I ran into the same problem… in a chroot. Due to some bug,
systemd-sysv just did not want to install under cowbuilder
for some time.
I discovered that using the second alternative for *conf
worked: put this into /etc/apt/preferences:
Package: dconf-gsettings-backend
Pin: version *
Pin-
>At a glance, there are also unique LVM IDs in /boot/grub/grub.cfg,
>though whether those would need to be changed when cloning I don't know.
Normally, you mount the root filesystem, chroot into it (more complex
than you think, either bind-mount tons of filesystem from the host,
and this is only s
> Change popularity-contest by transmissing the hostid after it has been
> hashed with the content of /etc/machine-id.
Heh, there is no /etc/machine-id on my Debian system.
I have an …/etc/machine-id in buster and stretch chroots I created
and xenial, bionic and disco pbuilder base.cow directorie
>JFTR: aptitude (and all other libapt-based frontends) can make use of
>that feature via the config option APT::Sources::With, the commandline
>flag is just syntactic sugar.
Doesn’t match my use case of repository injection for anything
that might call apt later.
I could, perhaps, add stuff to ap
I wrote:
>in GCC 6 IIRC and *still* pertinent in GCC 8 and I believe 9,
Still present in (sid/amd64):
• gcc-8 (= 8.3.0-19)
• gcc-9 (= 9.1.0-10)
• gcc-snapshot (= 1:20190719-1)
>>I'm currently compiling e2fsprogs with LTO for Debian --- and I'm
>>seriously considering ditching that change. The
>We just had SuSE embracing LTO
Not entirely.
With my DD hat doffed and wearing the mksh upstream developer hat,
I’ve been asking the package maintainers of mksh in all distributions
to remove the LTO flags, and will remove the built-in support for
using LTO in the next release.
Why?
mksh’s tes
I actually have a use case: injecting packages from
/var/cache/pbuilder/base.cow-somedist/repo/ into APT
from an optional cowbuilder hook script that I can
enable (chmod +x) when needed.
The hook script has the interesting constraint that
it adds a repository to APT with*out* running apt-get
updat
Ian Jackson dixit:
>There is QA work on the many packages with no specific maintainer;
Sure, in that case I’ll have to take it over or deal with it.
>there are cross-archive campaigns such as reproducible builds,
>architecture support, init system diversity, i18n/l10n, and so on.
These are done
Sam Hartman dixit:
>He doesn't actually make that argument.
Hmm. Right, he doesn’t spell it out, but I got the impression.
Perhaps my reading was wrong.
>There are several reasons for not using dh we've already identified.
Sure… but…
>The fun factor is important.
… that.
>My reading of the com
I would very much like to argue that not using dh is not a bug,
but Joey Hess, with his credentials ☺, did that already (and much
better than I could):
http://joeyh.name/blog/entry/80_percent/
tl;dr: dh started as 80% solution, it’s maybe an 96% solution now,
but it’s not intended as, and won’t b
On Thu, 21 Mar 2019, Mattia Rizzolo wrote:
> > > Were the wheezy/updates and wheezy-updates merged into just wheezy
> > > as last step before archiving, so that those two lines can just be
> > > dropped?
> >
> > Yes, it is common that the last point release, just at end of life time,
> > takes in
Joerg Jaspert dixit:
> as Wheezy and Jessie have been integrated into the archive.debian.org
> structure recently, we are now removing all of Wheezy and all non-LTS
Which sources.list changes are necessary?
My starting point is this:
deb http://httpredir.debian.org/debian wheezy main
deb http:/
Ben Hutchings dixit:
>On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
>>Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
>>> • during postinst, creates a 128-byte random seed file in /
>>
>>Can you confirm that this is done with data from
&
Sebastian Andrzej Siewior dixit:
>so I have one older box that suffers from that. I installed haveged and
>seemed to went away:
I tried that, after the suggestion to use haveged went up, but…
>As far as I understand, it would reach the "init done" state before
>systemd took over, right?
… this
Ben Hutchings dixit:
>> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>> accredit them yet, just remembers the amount written)
>
>How do you determine the number of bytes here?
32 + arc4random_uniform(256 - 32 + 1)
[…]
>The major input into the new seed file contents
Uoti Urpala dixit:
>entropy to be secure. Consider the following scenario:
>
>Daemon
There are no daemons running at that time. This is run in
initramfs, just after the root filesystem has been mounted,
with no background tasks save udev running, and network has
not been set up (unless NFS or dro
Hi Philipp,
>FTR this is supposedly fixed on the main architectures featuring an RNG
>in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which Ben
that’s what I referred to by…
>>• it does not use/add CPU RNG output where present
>> ‣ though Linux can now do that itself, some comman
Hello fellow developers (and some users),
I would like to present a recent (this week) project of mine.
Background story:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during bo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Sean Whitton dixit:
>2.3 & 4.5
>In cases where a package's distribution license explicitly permits
>its copyright information to be excluded from distributions of
>binaries built from the source, a verbatim copy of the package's
>cop
On Fri, 21 Dec 2018, Dmitry Bogatov wrote:
> I propose to replace current approach with update-alternatives(1)
[…]
> Opinions?
No. update-alternatives is too fragile to handle things like
/bin/sh and init(8).
Also, what Josh Triplett said.
The packages you cited are basically just the hooks to
On Wed, 19 Dec 2018, Dmitry Smirnov wrote:
> trust - a something we can only have in backports-like "volatile" repo.
Did you mean: in an unstable-like “volatile” repo?
Backports have a defined mission, which has nothing to do
with the “volatile” proposal. What you were referring to,
integration-
On Tue, 16 Oct 2018, Adam Borowski wrote:
> > > With only two modified binary packages (policykit-1 and udisks2) I’ve
> 1. You need to recompile these packages, this is not something an average
> user or even sysadmin knows how to do.
I publish .deb packages for them (although not for all arches
On Mon, 15 Oct 2018, Petter Reinholdtsen wrote:
> Note, I can with authority, as the person introducing dependency based
> boot and shutdown ordering in Debian, report that insserv were not
> introduced for parallell boot, nor for boot speed. It was introduced to
> correct broken boot and shutdow
bly not very normal, though…
Adam Borowski wrote:
>On Mon, Oct 15, 2018 at 08:46:31AM +0200, Laurent Bigonville wrote:
>> Thorsten Glaser wrote:
>> > On Sun, 14 Oct 2018, Andreas Henriksson wrote:
>> >
>> > > Please note that sysvinit dependencies still have o
On Sun, 14 Oct 2018, Andreas Henriksson wrote:
> Please note that sysvinit dependencies still have open RC bugs which
> noone is caring for.
Oof. How do I find them out? The BTS shows no RC bugs, not even
ones tagged as affects src:sysvinit, and the QA page
https://packages.qa.debian.org/s/sysvin
On Sun, 14 Oct 2018, Ben Hutchings wrote:
> > > > sysvinit currently has two maintainers, but they've only
> > > > ever made one upload (over a year ago).
> > Why would sysvinit need uploads? It’s largely working software
> > that needs few changes.
>
> That may be, but there are many open bug
Hi Holger,
I’ve been totally shocked by the Subject, but reading on…
> On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
> > > Has policy changed regarding support for multiple inits, or is it
> > > just that no one is maintaining the shim and sysvinit-core?
> >
> > The latter. sys
Eek! I only saw this by accident, as I’m also not subscribed to
d-devel.
>On Sat, Sep 29, 2018 at 07:48:09AM +0100, Ben Hutchings wrote:
>> - x32 has 64-bit time_t and that never worked quite right. This may
>> have finally been fixed this year by Arnd Bergmann's work, but I'm
>> not sure.
Adrian wrote:
>Yes, of course. But Andreas hit a nerve with this on me. This project
>has cost me lots of blood, tears and sweat and if someone is asking
>for it to be completely thrown out out of nothing, I'm getting a bit
>stressed out.
I completely agree here. While I’m no longer involved with
James Clarke dixit:
>file for an amd64 build. Uploading a source-only changes file called
>_amd64.changes has been done many times in the past (and used to be what you
>would get with pbuilder pre-stretch) and never posed an issue, I guess because
>the .changes files were thrown away(?), though I
On Tue, 19 Jan 2016, Andreas Tille wrote:
> > dh exists to optimise the common case,
> > with some limited amount of extendability, but in some cases, dh5 style
> > works better and/or ensures more legible debian/rules files than dh7 style.
>
> s?ensures more legible debian/rules?ensures less legi
On Mon, 18 Jan 2016, Waldemar Brodkorb wrote:
> From a good friend I would expect some more positive feedback
> for my hobby project ;)
I said, it has its niche, but I doubt it has a place
as a generic Debian package… libraries are generally
only packaged when something uses them, and C libra‐
ri
Lucas Nussbaum debian.org> writes:
> qa-helper_classic_debhelper.txt (3647 packages)
>
>The package is still using "classic" debhelper (no dh, no CDBS).
Note that this is not a problem in the package, and there is absolutely
no requirement to act on this. dh exists to optimise the common ca
Ansgar Burchardt debian.org> writes:
> Marc Haber zugschlus.de> writes:
> > I, for example, am afraid of having to merge /usr in existing systems
> > during upgrades, causing repartitions to be necessary. I am afraid of
> > partition layout suddenly not fitting any more during an upgrade,
> > c
Marco d'Itri Linux.IT> writes:
> grml-rescueboot is way more useful for rescue purposes.
It is… except, I didn’t take it into account when creating the 256 MiB /boot
for a laptop, and the regular kernel and initrd are huge already these days,
and then you have two of them, plus a temporary initr
On Mon, 18 Jan 2016, Waldemar Brodkorb wrote:
> It is a try to build a Debian system with an alternative C library
That would require a new dpkg architecture and other changes,
e.g. you could build for linuxuclibc-i386 instead of linux-i386.
The avr32 people tried to make a µClibc-based Debian p
On Sun, 17 Jan 2016, Waldemar Brodkorb wrote:
> uClibc-ng is a small C library for developing embedded Linux systems. It is
> much smaller than the GNU C Library, but nearly all applications supported by
> glibc also work perfectly with uClibc-ng.
How is that relevant for a binary distribution in
On Fri, 23 Oct 2015, Steve McIntyre wrote:
> separate library for a single function as trivial as:
>
> for (var i = 0; i < arguments.length; i++) {
> if (arguments[i] !== undefined) return arguments[i];
> }
> Yes, by all means if you're using it a lot. But a separate library
> wi
On Sat, 26 Sep 2015, Jeroen Dekkers wrote:
> > How does failing the upgrade solve anything? The upgrade should only
> > fail if the failure of the service to start was because something in the
> > upgrade itself was broken; this is rarely the case.
>
> I think it solves the problem of notifying
On Wed, 23 Sep 2015, Wouter Verhelst wrote:
> Yes, but that would push complexity to the client side for no
> particularly good reason.
The “client” here is dak, and the info could be pushed to UDD,
if it isn’t already (didn’t check). That’s a one-off thing.
bye,
//mirabilos
--
tarent solutions
Wouter Verhelst debian.org> writes:
> Everything needed to remedy that would be to not do so, and include the
> source to a binNMU with its upload instead.
No. The entire delta between the source in the archive and
the .deb generated from a binNMU upload is contained in the
.changes file as well
Виталий Филиппов yourcmc.ru> writes:
> > Try using aptitude instead of apt. It sometimes does a better job, and
> I've tried and it offered me 100500 different insane ways of solving the
> situation... :) that's why I don't use it, its solver seems really insane.
> apt-get is far more ration
Vincent Bernat debian.org> writes:
> 2. Upstream may generate the final pre-minification file with complex
> tools, like an AMD loader or an ES6/ES5 transpiler, along with the
> use of non-packaged build tools like Grunt.
> problem. For the second one, a solution would be to consider th
Michael Meskes debian.org> writes:
> Who said the update failed? I want to make the decision as to when and
> how to update my system and I never want to see some stupid software
PSA: the src:mirabilos-support package¹ builds a growing number of
prevent-* packages; among them is prevent-unattend
IOhannes m zmölnig (Debian/GNU debian.org> writes:
> my first reaction was that the intention of this paragraph is mainly to
> keep the system uncontaminated from non-free and contrib, but while the
I think that is correct. Furthermore, arch-qualifying Recommends
is not possible in an arch:all p
Andreas Barth ayous.org> writes:
> - for i386, there is still sold new hardware with 32bit-only. Are
> there open issues for i386 (apart from the 32bit-generic ones)?
> Discussion that we need to get rid of it one day should be started.
Eh, is this some sort of conspiracy to make Debian even
Hi *,
we’ve been seeing a really weird behaviour for a while, as far as we can
tell since some openssh security update?
We’re losing SSH host keys in known_hosts. The entries are there, then,
days or weeks later, they’re no longer there.
We disabled host key hashing, but the effect is still ther
Václav Šmilauer doxos.eu> writes:
> host filesystem through NFS. The platform is identified as
> x86_64-k1om-linux-gnu; gcc, binutils and glibc support this arch
Why does this need to be a new port, then?
Did you try running a Debian/amd64 chroot on it, or even just
a couple of statical
Daniel Pocock pocock.pro> writes:
> However, I've come up against the DPI issues.
>
> The actual DPI is about 131x137 on a 32" display.
>
> xdpyinfo reports 96x96
I've recently had the problem that some applications like Kontact/KDEPIM
suddenly use the wrong fixedmisc font for eMail displaying
Thorsten Glaser tarent.de> writes:
> There are two variants. One does have the patches under debian/patches/
> (although this does not mix well with VCS IMO, so I don’t usually use
> it), in which case either the applied or unapplied source tree may be
> in the VCS. Both are trou
1 - 100 of 566 matches
Mail list logo
