Unless somebody's already put it there, I'm going to move these
suggestions to a wishlist bug against systemd. Not sure if it should
be one bug or a few, one for each suggestion.
Currently discussion about reaping /var/tmp/ is in
https://bugs.debian.org/966621 and
https://bugs.launchpad.net/ubuntu
> I'd like to hear some arguments *in favour* of making this change.
> Alignment with systemd-upstream, reduced package maintenance burden
> are two that I can think of, but perhaps I've missed more. These two,
> IMHO, are significantly outweighed by the risks.
Let me see if I understand the argum
I guess sometimes when people discuss technical matters, good ideas pop up.
(Although I still think that its problematic interactions with lengthy
suspends makes the whole idea of auto-deletion based purely on
timestamps problematic. I can imagine more coherent mechanisms, which
doesn't count time
> ...3) I would put a file in any auto-cleaned space named "1-AUTOCLEAN.txt"
> that contains some verbage explaining that things in this directory will be
> wiped based on rules set in (wherever).
You know, that's a pretty good idea!
Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly s
Rhys, I think you're being unfair. We have a *technical* disagreement
here. But our hearts are all in the same place: Luca, myself, and all
the other DDs discussing this, all want what's best for our users, we
all want to build the best OS possible, and are all discussing the
issue in good faith.
> tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
It's a question of what the *default* behaviour should be.
For whatever reason, a lot of people who process large data use
/var/tmp/FOO/ as a place to store information that should not be
backed up, but also should not just di
If it clones into /tmp the *entire* tree will either be reaped (upon
reboot) or not.
But having just some files deleted from a git dir or git working dir
is much more dangerous, because various git commands can treat files
deleted from the working tree as deliberate changes to be committed,
and fi
> What I am looking for right now is packages or internal
> infrastructure that need
> an update to cope with these two changes before I upload them, so if
> you know of any please do let me know and I'll happily look into it
> and at least file a bug, if not a MR. Thanks.
Okay.
git and other ver
> Then upon reading the release notes, on such a machine, one can simply do:
>
> touch /etc/tmpfiles.d/tmp.conf
>
> And they get no automated cleanups.
This also disables on-boot cleaning of /tmp/.
The root issue here is that deleting not-read-in-a-while
but-maybe-stat'ed-recently-by-make-that-do
> We have two separate issues here:
> a/ /tmp-on-tmpfs
> b/ time based clean-up of /tmp and /var/tmp
> I think it makes sense to discuss/handle those separately.
Agreed.
I also don't see any issue with a/, at worst people will be annoyed
with it for some reason and can then change it back.
> R
It is traditional to use the ancient IBM text "This page intentionally
left blank"
That file is specially compiled using a different set of flags. This
is done deliberately, and is not an issue. You can squelch the false
positive using an appropriate stanza in debian/rules, to issue a
command in the log that tells blhc to stand down. Like this:
execute_before_dh_auto_build:
Seriously? Being able to type
dpkg -S $(which cat)
instead of
dpkg -S $(which cat|sed 's:^/usr::')
is the big user-level pain point?
People seem pretty worked up over this, but honestly I'm not
understanding why. We already have $PATH which (let's be honest) is an
ancient crappy workaround for
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: youtubedl-gui
Version : 2.5
Upstream Author : Jason Goulet-Lipman
* URL : https://github.com/JaGoLi/ytdl-gui
* License
> Yes it would be fine. This page can also be a JSON page
> (opts="searchmode=plain")
Ah, then it wouldn't be Fossil-specific at all. Good idea.
As the Fossil Debian package maintainer, I'd certainly be grateful for
notes on how to use Fossil for Debian packages. I have my own
idiosyncratic workflow for Fossil itself, but it's not general because
it relies on upstream's distribution of tarballs, and otherwise uses
the local fossil repo, and
My Dell Inspiron 7591 2n1 required the SOF audio firmware, so I did a
quick packaging for my own purposes, to be sure I had the latest. See
https://github.com/barak/sof-bin
branch: debian
Works for me, and of course my packaging scripts are free for use in
whole or in part etc (I hereby place t
On Sun, 9 Aug 2020 at 19:01, Adrian Bunk wrote:
> The number of tools parsing build dependencies or doing dependency
> resolution is larger than you might expect.
Yeah, I can only imagine. And they're not all in one great big git
repo either! That's one reason I thought pushing it into the
archit
On Sun, 9 Aug 2020 at 17:05, Adrian Bunk wrote:
> The pragmatic solution is to list the 3 architectures where julia
> currently builds.
Okay, thanks for the hints, Adrian. That's what I'll do for now.
> The software engineering solution would be a dependency package
> julia-or-nothing that depen
I'm maintaining mlpack. It is able to generate julia bindings, so on
architectures in which julia is available I'd like to generate julia
bindings, and this requires julia to be installed at build time. I've
set up debian/rules to check if julia is installed, and set
configuration options appropria
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: gnu-apl
Version : 1.8
Upstream Author : Jürgen Sauermann
* URL : https://savannah.gnu.org/projects/apl
* License : GNU GPL
Programming Lang: C++
Description : GNU
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: qlogo
Version : 0.92
Upstream Author : Jason Sikes
* URL : https://qlogo.org/
* License : GPL2+
Programming Lang: C++
Description : Language using turtle graph
Package: wnpp
Owner: Barak A. Pearlmutter
Severity: wishlist
* Package name: chez-scheme
Version : 9.4
Upstream Author : R. Kent Dybvig and others
* URL or Web page : https://github.com/cisco/ChezScheme
* License : Apache 2
Description : Implementation of the R6RS
> Why "-linux" in the name if it doesn't seem to be Linux-specific?
Good question.
That's just the name of the source package, following upstream's repo name,
which is parallel to their nuntius-android source repo. The binary package
would be just nuntius.
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: nuntius-linux
Version : 0.2.0
Upstream Author : The Holy Lobster Team
* URL : https://github.com/holylobster
* License : GPL-2+
Programming Lang: Vala, C
Description
The package "ikarus", another programming language implementation,
also requires SSE2 support.
There is a check in the preinst script which aborts installation if
sse2 is unavailable.
case "$1" in
install|upgrade)
if egrep -q '^flags[[:space:]]*:.*\bsse2\b' /proc/cpuinfo; then
Package: wnpp
Owner: Barak A. Pearlmutter
Severity: wishlist
* Package name: latex-coffee-stains
Version : 4
Upstream Author : Hanno Rein
* URL or Web page : http://hanno-rein.de/archives/349
* License : "You can freely distribute this package as I do not believ
Package: wnpp
Owner: Barak A. Pearlmutter
Severity: wishlist
Package name: mlpack
Version : 1.0.8
Upstream Author : Ryan Curtin
URL or Web page : http://www.mlpack.org/
License : LGPL-3+
Description : Fast and scalable C++ machine learning library
MLPACK (Machine
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: colpack
Version : 1.0.9
Upstream Author : Alex Pothen
* URL : http://www.cscapes.org/coloringpage/
* License : LGPL-3+
Programming Lang: C++
Description : Special
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: zenlisp
Version : 2013.11.22
Upstream Author : Nils M Holm
* URL : http://www.t3x.org
* License : Public Domain (essentially)
Programming Lang: C
Description : I
could be
used there, with the post-installation scripts doing the de-obfuscation.
I won't say it's pretty ... but it would suppress these false positives.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Ki
7;t mind. Hint Hint.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscri
Good idea. Will add this info to the bug report.
Technically there are two bugs. 692623 is for the CSON "not evil" files
being derived files rather than truly original source, while 692624 is
for the "not evil" license itself. The latter is already tagged
wheezy-ignore, while the former is caus
> > # #692623
> > remove fossil/1:1.22.1-1
> This is worrying because fossil is the vcs used by sqlite upstream.
> It looks like fixing this would involve Packaging "cson" too. The
> alternative of dumping cson into the fossil source tree is probably
> not ideal.
> Barak, have you looked at thi
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: expand-region-el
Version : 0+git.1.d157d7f
Upstream Author : Magnar Sveen
* URL : https://github.com/magnars/expand-region.el
* License : GPL3
Programming L
mall files while also
handling large files well.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.deb
ith
override_dh_installman: debian/packagename.1
dh_installman
debian/packagename.1:
/somepath/create-a-man-page > $@
assuming the man page creation does not require some built executable.
Cheers,
ing on the particulars of the situation) a bit superfluous.
If people are going to do only one of (a) heads-up to upstream author,
and (b) file an ITP, I personally would rather see them do (a). Of
course, doing both would typically be best.
--Barak.
--
Barak A. P
page built-in html manual.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsu
Package: wnpp
Owner: Barak A. Pearlmutter
Severity: wishlist
* Package name: pdf-presenter-console
Version : 1.1
Upstream Author : Jakob Westhoff
* URL or Web page : http://westhoffswelt.de/projects/pdf_presenter_console.html
* License : GPL-3
Description : PPC is
Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter"
* Package name: scheme9
Version : 2009.02.09
Upstream Author : Nils M Holm
* URL : http://t3x.org/s9fes/
* License : ideosyncratic near-MIT/X
Programming Lang: C, Scheme
D
> (And if there is no progress again within the next two years or so,
> I'll likely close this again.)
Guess we have different ideas about what "wishlist" bugs are for.
My attitude is they're for wishes, like the sea is for fishes.
Sometimes someone picks one up, perhaps even a big wily old fat on
> As said, feel free to reopen.
Will do.
Debian has made analogous contributions in similar domains: see
package libpaper, or tempfile(1) in debianutils, or emacsen-common.
So it not just our mandate; we even have a history.
> And, as usual.., are you willing to work on this goal?
Willing? Yes
What makes Debian a "distribution" rather than just a random
collection of miscellaneous software is integration. This is an
integration wishlist. It has to happen at the distribution level if
it is to happen anywhere. I don't understand why you want to close
this issue---the logic seems to be j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
a65763d3-b1e2-4530-8ff8-aa5915274eb4
[ ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
[ ] Choice 2: Re-affirm DPL, do not endorse nor support his other pr
Are you one? Am I? Please help, I can't even tell which side
I'm on, or who the players are!
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Oops, guess I should have checked if it was already done. My bad.
(Given that the warning is working, why were people making such a
fuss? Well, never mind.)
--
Barak A. Pearlmutter <[EMAIL PROTECTED]>
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ire
that might otherwise elude us. Point (2) would be especially helpful
given that we're coming up on a release, so it would be nice to find
and correct all affected scripts as rapidly as possible.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://
48 matches
Mail list logo
