Re: apt key handling needs to be properly documented--what to do?
Quoting Ross Boylan (2022-06-11 09:07:14) > The apt-secure man page in Debian 11 notes that repository signing is > a key part of the Debian security infrastructure. But key parts of it > are not documented. In my opinion that is a significant security > problem, but the apt maintainers clearly do not share that view. > > apt-secure's man page says to use apt-key to manage repository keys, > and provides no other information on how to manage them, not even > mentioning /etc/apt/trusted.gpg.d/. The apt-key manpage, on the other > hand, says the program is deprecated and you should not use it. But > it provides no clue about what you should do instead, aside from > referring you to apt-secure (!). Nor does it seem to be documented in > other man pages or /usr/share/doc/apt, or apt-doc. > > Bugs have been filed about this going back to 2020: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968148 and > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990521. The > maintainers have consistently minimized the problem, first of all by > downgrading the priority of those bugs to minor, and second by > offering a variety of sometimes inconsistent responses: >1. The priority is to get people to stop using apt-key. Apparently > this is not served by offering them any guidance about what they > should do instead, but just by putting in deprecation warnings. So > the failure to document an alternative leads to people sticking with > apt-key, and the fact they stick with apt-key is given as a reason to > "deprioritize" giving them guidance. >2. There are obvious alternatives. The fact that they are obvious > to the maintainers doesn't help the rest of us. >3. The best alternative isn't obvious. This seems a poor reason to > leave people adrift. > > As noted in other parts of those bugs, and in other bugs, people > continue to do the "wrong" thing, like trying to use keys in the wrong > format (for that matter, add-apt-repository does that itself, as I > recently discovered, > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012649) or > selecting wrong, or at least security-questionable, options, when they > try to populate /etc/apt/trusted.gpg.d/. > > An additional problem is that stable is frozen, so that the bar for > updates is higher (one of the reasons given for lack of action earlier > was that a release freeze was in effect). > > The lack of documentation seems to me to merit both a higher priority > and a faster response. And the security concerns seem to me clear > justification for an update to stable. > > Any suggestions about how to do that? > > I hasten to add, in anticipation of the inevitable "submit a patch", > that the patch should come from someone who actually understands the > security infrastructure. Which is not me, because it's not documented. Maybe you were looking for documentation like this: https://salsa.debian.org/apt-team/apt/-/commit/4a012436ce6a07dd435dca33b7ee2c41ea94c844 Is anything missing from that addition to the documentation that you'd like to add? Here is a version of the apt-key man page with better formatting: https://manpages.debian.org/unstable/apt/apt-key.8.en.html#DEPRECATION Thanks! cheers, josch signature.asc Description: signature
Re: Question related to Sbuild CLEAN_SOURCE
Hi, please keep me in CC as I'm not subscribed to debian-user@l.d.o. Quoting quirin.gylsto...@siemens.com (2022-02-08 15:40:40) > we are currently testing the integration of sbuild in ISAR[1] and have a > question related to the CLEAN_SOURCE behavior. > > > "When running sbuild from within an unpacked source tree, run the > 'clean' target before generating the source package. This might require > some of the build dependencies necessary for running the 'clean' target > to be installed on the host machine. Only disable if you start from a > clean checkout and you know what you are doing."[2] > > > As noted in [2] we observe that we need dh- in the host > environment to execute the dh clean -with . > > Our questions are: > > - Is there are reason sbuild executes clean outside of the chroot? Yes because if you don't know what you are doing (as it says in the manpage you cite) and you run sbuild from within an unpacked dirty source tree without running the clean target, then you might be building something that is not the source package you expect to be built. > - How does the buildd infrastructure deal with this behavior? The buildd infrastructure doesn't run sbuild from within an unpacked source tree so it will not run the clean target outside the chroot and thus doesn't need to have the necessary dependencies for running the clean target installed. The fact that sbuild is able to run from inside an unpacked source tree is a convenience feature which allows you to run sbuild without having to first create the source package. But the actual input to sbuild is the source package (the dsc). Don't use sbuild to create a source package. The source package is the input to sbuild. The output of sbuild are binary packages, not source packages. Thanks! cheers, josch signature.asc Description: signature
Re: Cross debootstrap without root rights
Hi, (please CC me, I'm not subscribed to d-user@l.d.o) Quoting Christoph Müllner (2020-02-09 12:54:56) > I'd like to run the second stage of debootstrap without root rights, but for > another architecture (host is x86_64 and target is arm64). > > I know how to do all that with root rights (i.e qemu-aarch64-static works > perfectly here, also, I can recommend using qemu-debootstrap), but I can't > figure out a way how to do that without root rights. > > I was expecting that fakechroot and fakeroot will do the necessary "magic" to > make chroot work for my use-case, but that's not the case (I need to have > libfakeroot.so and libfakechroot.so in the target rootfs, but I could not > find a reliable way to get them in). > > I found some emails in the archives about similar use cases (from ~10 years > ago). But I failed to identify the solution in those cases. > > Therefore I'd like to ask if anyone has a solution for my use case or some > hints/pointers. yes, there are several solutions. Either: a) You can use mmdebstrap which is a debootstrap replacement that focuses on not requiring superuser privileges and has foreign architecture support built in: $ mmdebstrap --arch=arm64 unstable debian-unstable.tar b) There is a proof-of-concept that allows one to run debootstrap with unprivileged usernamespaces here: https://bugs.debian.org/829134 This will probably also work with --second-stage c) Getting fakechroot and fakeroot to work with foreign architectures is tricky and requires the right libfakechroot.so being installed and several environment variables to be set differently. You can have a look at how mmdebstrap does this so that you can maybe replicate that for debootstrap: https://sources.debian.org/src/mmdebstrap/0.6.0-4/mmdebstrap/#L1942 Thanks! cheers, josch signature.asc Description: signature
Re: unable to boot with systemd (works with sysvinit)
Hi, Quoting Selim T. Erdoğan (2015-01-12 22:38:08) On Sat, Jan 10, 2015 at 12:33:36PM +0100, Johannes Schauer wrote: I'm unable to boot my laptop with systemd which worked before. I'm unable to tell the changes I made since the last time it worked because according to my uptime, the last time I rebooted was September last year. I see you already have a bug report, so including it for the list: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758808 this is the right bug report. Downgrading to 204-14 fixes the problem I encountered in my first email. My apologies for not having supplied that bug report in my initial email. I honestly forgot that I already faced the same problem in August last year. It looks to me like it's not fsck as much as not being able to access /boot, /home and swap. If you want to check this, you can probably tell systemd not to run fsck at boot. (How to do this was the topic of some recent threads on debian-user, but I didn't follow them so I can't help with that.) Searching the archives you might've meant to add fsck.mode=skip to my kernel command line. I tried that but it didn't fix the problem. I wonder if the problem is with decryption (under systemd), which then leads to the timeout when accessing everything inside it? Unfortunately, I don't know enough to suggest a good way to test this. This is a possibility. Thank you for your help! cheers, josch signature.asc Description: signature
unable to boot with systemd (works with sysvinit)
Hi, I'm not subscribed, so please keep me CC-ed. I'm unable to boot my laptop with systemd which worked before. I'm unable to tell the changes I made since the last time it worked because according to my uptime, the last time I rebooted was September last year. The output of `journalctl -xb` in the systemd rescue console is here: https://mister-muffin.de/p/AabX.txt My system contains up-to-date package versions with Debian Jessie. This means I'm running systemd and udev version 215-8. Since the problem seems to be related to a failed fsck job, according to above log, here is my fstab (minus comment lines): proc/proc procdefaults0 0 /dev/mapper/volumegroup-root/ ext4errors=remount-ro 0 1 UUID=ac034ff5-d28a-4ad1-8bac-97d554395e3e /boot ext2defaults 0 2 /dev/mapper/volumegroup-home /home ext4defaults0 2 /dev/mapper/volumegroup-swap noneswapsw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 cgroup /sys/fs/cgroup cgroup defaults 0 0 tmpfs /tmptmpfs nodev,nosuid,size=8G 0 0 tmpfs /runtmpfs nodev,nosuid,size=8G 0 0 I also booted my system into the initramfs busybox by passing break to the kernel command line and did an `fsck -f` on my root and home partitions and everything seems to be clean. Booting my laptop with sysvinit instead works fine, so my fstab should be correct. How can I further debug this problem? The journalctl output seems inconclusive. Thanks! signature.asc Description: signature
unix tool as precise counter/timer for periodic print/exec
Hi, I'm looking for a unix tool that does nothing else than increment and print an integer with a fixed frequency. As a bonus it should be able to execute a command with a fixed frequency. The special requirement: it should precise in the interval. Thus, the following will not work: #!/bin/sh while true; do print_counter sleep 1 done because each loop iteration will take one second plus how long print_counter takes to execute. Even the following will not work: #!/bin/sh while true; do print_counter sleep 1 done Because even the time it takes to fork print_counter will accumulate over time. Another inconvenience of the above is, that not all sleep(1) implementations do accept floating point arguments to run the above faster than every second. What I need is something that on each step recalculates how long to sleep based on the current time so that the overall frequency remains stable. I do not need each print_counter to be executed exactly at a very precise moment but just that the overall frequency stays the same. After having it run 1000 times with a frequency of 1Hz I want 1000 seconds to have passed. Some libraries like glib provide functions like g_timout_add or g_timeout_add_seconds but that does not 'catch up' as I require above. Is there some library that does? There is the watch(1) tool which already partly does what I want using the --precise switch. But it runs in fullscreen and even when using --precise, it will not compensate for commands that take longer than the given interval length as it doesnt fork them. Also, watch(1) will not allow intervals smaller than 0.1 seconds. So basic requirement: print a counter (counting up or down) in a fixed frequency. Either a tool that does that or a library that I can use to code it. Bonus: execute a command with a fixed frequency and in contrast to watch(1) even when executing the command takes longer than the interval. So is there a utility that just implements a simple, precise counter? Is there a better version of watch(1) that is not fullscreen, allows faster than 0.1 second intervals and forks the application so that their runtime can exceed the interval time? cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502082011.GA8564@hoothoot
Re: unix tool as precise counter/timer for periodic print/exec
Hi Darac, I'm not entirely sure if such a tool exists, but one thing you will need to bear in mind is that you will need to make sure you're running a real-time kernel (apt-cache search linux-image-rt). This will allow you to run your look with real-time priority. If you don't have real-time priority, then you basically have no way of ensuring that you will be able to run print_counter at the specified time - you could always get delayed because the kernel is writing to disk or some other process is doing work. I dont require that. Let me quote my original email: I do not need each print_counter to be executed exactly at a very precise moment but just that the overall frequency stays the same. After having it run 1000 times with a frequency of 1Hz I want 1000 seconds to have passed. This is also why I made the comparison to watch(1) with the --precise argument, which does what I want but has other deficiencies. Thank you for your input. cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502104526.GA19488@hoothoot
Re: unix tool as precise counter/timer for periodic print/exec
Hi Paul, Use crontab (see man crontab). But as far as I see, cron doesnt do what I want. First of all, it will run as a daemon in the background so there is no way (at least as far as I am aware) to make it output a counter/timer in my terminal. Second, as also mentioned in my initial email, I would also like a resolution higher than once per second which is (afaik) also not what cron is made for. Thank you for your reply! cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502150656.GA15709@hoothoot
Re: unix tool as precise counter/timer for periodic print/exec
Hi Karl,
Perhaps the sleepenh package will help you?
Not a solution per se, but possibly a useful building block..
It works perfectly and was exactly what I was looking for! Thanks a lot!
In case anybody ever finds this thread later on, this is what I now
wrote based on sleepenh which does exactly what I was looking for in my
initial email:
--%---
#!/bin/sh
usage() {
echo Usage: $0 [ARGS] [COMMAND]
echo
echo It counts upward (default) or downward (-d) starting at START (-s)
echo with a configurable floating point interval of SECS seconds (-n,
echo default 1.0) until infinity (default) or up to a maximum number of
echo COUNT intervals (-c). It optionally prints this counter (-p) and/or
echo the current date (-t) at each interval. It optionally executes a
echo COMMAND per interval which it can also fork (-f) in case the command
echo is expected to take longer than SECS seconds.
echo
echo -f fork COMMAND
echo -p print counter
echo -d count downward (default: upward)
echo -n SECS interval of SECS (can be floating point)
echo -c COUNT only run for COUNT interval(s)
echo -s START start counting at START
echo -t print the output of date(1) every interval
echo -h print this help message
}
INTERVAL=1.0
MAX_COUNT=-1
DOWN=0
PRINT=0
FORK=0
PRINT_DATE=0
START=0
while getopts fpdn:c:s:th option; do
case $option in
f)
FORK=1
;;
p)
PRINT=1
;;
d)
DOWN=1
;;
n)
INTERVAL=$OPTARG
;;
c)
MAX_COUNT=$OPTARG
;;
s)
START=$OPTARG
;;
t)
PRINT_DATE=1
;;
h)
usage
exit 0
;;
[?])
usage 12
exit 1
;;
esac
done
shift $(($OPTIND - 1))
TIMESTAMP=`sleepenh 0`
I=$START
while true; do
if [ $# -ne 0 ]; then
if [ $FORK -eq 1 ]; then
$@
else
$@
fi
fi
if [ $PRINT -eq 1 ]; then
echo $I
if [ $DOWN -eq 0 ]; then
I=$((I+1))
else
I=$((I-1))
fi
fi
if [ $PRINT_DATE -eq 1 ]; then
date
fi
if [ $DOWN -eq 0 ]; then
[ $((I-START)) -gt $MAX_COUNT ] break
else
[ $((START-I)) -gt $MAX_COUNT ] break
fi
TIMESTAMP=`sleepenh $TIMESTAMP $INTERVAL`; done
--%---
Feel free to use the above in any way you want.
cheers, josch
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502161840.GB15709@hoothoot
Re: is there no sane, minimal, graphical RSS feed reader in existance?
Hi again, about half a year ago, I complained about the lack of a good, minimal RSS reader: On Fri, Jul 15, 2011 at 10:20:47AM +0200, Johannes Schauer wrote: I've been looking for a good RSS feed reader for years now but I still seem not to be able to find a sane, minimal graphical RSS reader. What I'm using now is liferea which is okay but could be more minimal and mainly, is way too slow to enjoy using it (search for the fsync issue). [...] What I'm looking for is not much: it would just depend on either gtk/qt/efl/whatever for its UI, would have one list of the feeds, another list for recent feed items and another frame with a gecko or webkit plugin for presenting the item. Why this feature/dependency bloat everywhere? Why is there no simple reader with minimal dependencies? Am I just overlooking one? Are my requirements too weird? I'm not afraid to compile from source either, should it not be in Debian. Should I like it I would also package it for Debian. As I said, liferea is close (just had to bear with the gconf2 dependency) but slow as hell (and no, I refuse to use the fsync workaround). Are there others that share my need? If there is really no such thing as a real minimal graphical RSS reader, I'm close to writing one myself. Well, I wrote one myself and here it is: https://github.com/josch/pyferea Posting it here, as there were some others also interested in a solution. cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224151225.GA23926@hoothoot
Re: is there no sane, minimal, graphical RSS feed reader in existance?
Hi Tony, aptitude isntall newbeuter http://www.newsbeuter.org/ In my original email (that I was replying to with my last mail) I wrote: - There are readers for the terminal but I have several feeds with images and I dont want to open another window of my browser each time. I'm in great love with having as much of my applications terminal based but my RSS reader cannot be one of them as there are quite a number of them that are based on pictures (photo blogs, webcomics, mangas...) thank you for your input! :) cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224204227.GA18153@hoothoot
Re: is there no sane, minimal, graphical RSS feed reader in existance?
Hi, On Sat, Jul 16, 2011 at 01:21:53PM -0700, Mike Castle wrote: On Fri, Jul 15, 2011 at 1:20 AM, Johannes Schauer j.scha...@email.de wrote: Our of curiosity, why choose a local app over a central service like Reader or any of the others out there? I used to be a big fan of such local apps, but since I could be on any number of machines (2 home desktops, a couple of laptops, few machines at work), I've found a web app a lot more convenient. My reason is: I only have one machine with Xorg and access all other machines (home desktops, home servers, few clusters and other machines at work) via ssh. Since there is no other machine with a screen, I would only read my rss on that one machine and thus, having a local app is sufficient. Even though I have a umts flatrate as well, I mostly use umts when traveling (mostly via train) and there the connection is very flaky. So for me it is very useful to have my reader try downloading it periodically and then reading it all offline. Of course my other machine with a screen is my smartphone but due to limitations of screen size I dont use it for my rss feeds as some of them heavily rely on big photos/images (like photo blogs and webcomics). To the fsync issue: even with replacing fsync calls by empty ones, liferea is very slow. It's faster than before but far slower than a small python/gtk/webkit rss reader I hacked together in the meanwhile which reacts in an instant to any user input of mine instead of taking a few seconds to react. Since other users on the web report similar issues with liferea (even with fsync disabled) I dont think this is a misconfiguration of my system and liferea is just slow in general. thanks for your input! cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110716205005.GA1983@hoothoot
is there no sane, minimal, graphical RSS feed reader in existance?
Hi, I've been looking for a good RSS feed reader for years now but I still seem not to be able to find a sane, minimal graphical RSS reader. What I'm using now is liferea which is okay but could be more minimal and mainly, is way too slow to enjoy using it (search for the fsync issue). So what is left? - There is a bunch of web based readers but I treasure having my stuff offline as well. - There are readers for the gnome or KDE environment. Since I use neither it would mean to get 100s of MB (literally) of dependencies - There are firefox extensions but why would I have to install a web browser to read my RSS feeds? - There are thunderbird, evolution and opera but same argument: why would I want to install an email-client/browser for my feeds? - There are clients like blam that are written in .NET/mono and would also require dozens of dependencies (not talking about .NET evilness) - There are readers for the terminal but I have several feeds with images and I dont want to open another window of my browser each time. I can't imagine there are no others who do not use Gnome/KDE (having a more minimal setup) but would want to have a graphical RSS reader? What I'm looking for is not much: it would just depend on either gtk/qt/efl/whatever for its UI, would have one list of the feeds, another list for recent feed items and another frame with a gecko or webkit plugin for presenting the item. Why this feature/dependency bloat everywhere? Why is there no simple reader with minimal dependencies? Am I just overlooking one? Are my requirements too weird? I'm not afraid to compile from source either, should it not be in Debian. Should I like it I would also package it for Debian. As I said, liferea is close (just had to bear with the gconf2 dependency) but slow as hell (and no, I refuse to use the fsync workaround). Are there others that share my need? If there is really no such thing as a real minimal graphical RSS reader, I'm close to writing one myself. Since I'm not subscribed, please dont forget to CC me. Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715082047.GA15129@hoothoot
Re: is there no sane, minimal, graphical RSS feed reader in existance?
Hi, On Fri, Jul 15, 2011 at 06:55:01AM -0400, Eike Lantzsch wrote: Try gpodder? Depends only on python and some python libs. Reads podcasts and rss feeds. Enjoy I really like the minimalism of that piece of software - my ideal rss reader would be exactly like that! Unfortunately I didnt manage to abuse gpodder as an RSS reader. It doesnt seem to cope at all with feeds that do not contain podcasts? cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715111349.GA26932@hoothoot
Re: is there no sane, minimal, graphical RSS feed reader in existance?
Hi, On Fri, Jul 15, 2011 at 06:11:56PM +0200, Aniruddha wrote: I prefer RSSOwl: www.rssowl.org They have Debian repository. Thanks for the tip! Unfortunately, if you want a html renderer, you need libswt-gnome-gtk-3-jni which (since I do not use gnome) pulls in a few hundred megabytes of libgnome-* and other gnome related dependencies (like gvfs - wtf?). cheers, josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715170004.GA13646@hoothoot
control apt-get selection for packages having multiple virtual package alternatives
hi!let me explain with the example of xserver-xorg. amongst others it has dependencies of xserver-xorg-input-all and xserver-xorg-video-all but both dependencies can also be provided by the packages xserver-xorg-input-7 and xserver-xorg-video-6. as you all know, the difference is that the meta-packages of xserver-xorg-input-all and xserver-xorg-video-all will pull all video and input packages while the virtual packages of xserver-xorg-input-7 and xserver-xorg-video-6 allow only one of the drivers to be installed to satisfy the dependency.as a result apt-get install xserver-xorg-video-foobar will not install all video drivers and apt-get install xserver-xorg-input-baz will not install all input drivers. my problem now is, that when i do apt-get install xserver-xorg-video-foobar i will still get xserver-xorg-input all and when i do apt-get install xserver-xorg-input-baz i will still get xserver-xorg-video all.trying to resolv this by doing apt-get install xserver-xorg-video-foobar xserver-xorg-input-baz doesnt help and will still get the *-all package of input or video whichever is not mentioned first.so in the general case of having a package with several dependencies that are satisfied by either one *-all metapackage or one virtual package where i can select the package providing it - how do i tell apt to select the specific package i want in BOTH cases?and in particular: how do i do that for an installation of xserver-xorg without removing the unwanted packages later?cheers josch -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509156684.1654211.1281992923543.javamail.fm...@mwmweb027
