Re: Questionable Package Present in Debian: fortune-mod
Hi Am 24.09.23 um 18:41 schrieb Salvo Tomaselli: Without an ftpteam hat on, but my point of view -- I believe the team would absolutely reject a package only based on its name (see: #914179). Not very consistently though: $ apt search penis | grep penis | wc -l 2 Can you please clarify what problem you see with these package names? The results I get for this search are: apt search penis | grep --color penis WARNING: apt does not have a stable CLI interface. Use with caution in scripts. libopeniscsiusr/stable,stable 2.1.8-1 amd64 libopeniscsiusr-dbgsym/stable-debug,stable-debug 2.1.8-1 amd64 debug symbols for libopeniscsiusr libopeniscsiusr-dev/stable,stable 2.1.8-1 all I.e. they don't actually contain the word “penis”, they just happen to contain words that when strung together contain these letters in this order. Regards Sven
Re: Automating signing of DKMS modules with machine owner key
Hi, Am Thu, 6 Aug 2020 17:24:08 + schrieb Jeremy Stanley : > The idea is that UEFI/BIOS checks the signature for GRUB before > executing it, and does so instructing GRUB to verify the signature > for its config. GRUB then checks the signatures on the kernel and > initrd before handing off control. To alter GRUB or its > configuration or the kernel or initrd ultimately (in theory, barring > bugs like the "Boot Hole" vulnerability everyone was talking about > over the weekend) you'll have to guess the BIOS password or have > access to reflash it with your own. Ideally this tampering also > invalidates cryptographic attestation for the entire chain, which > the user should then be able to detect. Are you talking about the Debian default setup or some custom setup? I don't really see how the Debian setup can do this, because the grub configuration and the initrd are generated on the end user machine. By default Debian doesn't enroll a MOK, so I don't see how the end user machine would sign the grub configuration and the initrd, as there is simply no key available that would be accepted by the UEFI. Regards Sven pgpk6dvOVIChn.pgp Description: Digitale Signatur von OpenPGP
Re: Automating signing of DKMS modules with machine owner key
Hi, On Tue, 4 Aug 2020 12:31:04 + Jeremy Stanley wrote: > Okay, so for systems to which a malicious party may gain physical > access (or remote console access) there's sort of a third risk this > addresses. A special case of the second risk really. *If* you're > also encrypting the filesystem on which that signing key resides > (via LUKS or similar) then this might keep you safe from someone > with access to replace the kernel or initrd on the unencrypted boot > partition... but only if they can't unlock the decryption key for > the FS which holds the signing key of course. to be protected from this threat, you'd also have to disable the platform key and instead also sign the kernel and grub yourself. Otherwise a malicious party can just boot anything signed with the platform key, which should be more than enough to do whatever malicious thing they want to do. Even if you do that, I don't think you've actually locked out malicious parties with physical access. The grub configuration (both on the boot partition and the EFI partition) and the initrd are AFAIK with the current configuration not signed. You would also have to protect your UEFI settings from being tampered with, to prevent a malicious party from just disabling secure boot entirely. However, that should be quite trivial as most UEFI firmware has the ability to protect the configuration by password. To sum it up, I think having a mechanism to automatically sign DKMS modules with the MOK would be a valuable step towards protecting against this threat, but I think to actually have full protection we would also need automatic mechanisms to: * sign installed kernels with the MOK, * sign the installed GRUB with the MOK and configure it to verify all loaded files with (taking care that a malicious party can't just use the grub console to disable signature checking), * sign generated grub configurations with , * sign generated initrds with . Maybe some or all of these things are already possible with current tooling, so please feel free to correct me if this is the case. Regards Sven pgpYc7PzmQdqf.pgp Description: OpenPGP digital signature
Re: Init systems and docker
Hi,
Am 12.10.19 um 19:00 schrieb Tomas Pospisek:
> However running a service ("a single application") often implies
> surrounding services. F.ex. you want logs to be saved? Maybe you need to
> run cron or at? Maybe you want to get notified about problems, stats,
> whatever via email?
>
> Now you can start re-implementing all the existing "surrounding" service
> solutions on the outside of the container. Which is a *lot* of complex
> work in my experience. The quick fix to those "surrounding" problems is
> often enough to stand onto proven-to-work shoulders and to install the
> "surrounding services" *inside* the container:
>
> apt-get install cron at rsyslogd etc. etc.
I don't see why you say, that you would have to *re-implement* the
surrounding solutions on the outside of the container. From my
experience, the most appropriate solution for having cron, at, and
rsyslogd run alongside you main service would be to put each of them
into their own container and link the containers together as needed.
This might sound more complicated than just installing everything you
need into one container, but container based service management (such as
kubernetes or docker swarm) are (at least in my experience) a lot easier
to manage and more effective, when you consistently separate each
service into its own container.
Regards
Sven
signature.asc
Description: OpenPGP digital signature
Re: GR: Declassifying debian-private: First call for votes
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- d495b767-7754-4e61-80ea-8b31c07f3595 [ 2 ] Choice 1: Repeal previous GR [ 1 ] Choice 2: Acknowledge difficulty [ 4 ] Choice 3: Remain private [ 3 ] Choice 4: Further Discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- pgpHcAFFkhJYQ.pgp Description: Digitale Signatur von OpenPGP
Re: Policy 12.3: should I rename?
On Wed, 27 Jul 2016 23:09:36 +0200 Tollef Fog Heen wrote: > ]] Sven Bartscher > > > I am a developer and regardless of the distribution I use, I often have > > a slow internet connection. So having to download possibly large > > documentation is a problem for me. "problem" may have been exaggerated. I should have written "inconvenient". > How do you keep up with unstable or testing, then? It's not that I can't download large files, but I think carefully before I install a larger package, because that would mean having to upgrade it regularly over a connection, which only allows a certain amount of traffic before it gets terribly slow. Having a slow/metered connection doesn't mean I can't keep up with testing, it just means the big upgrades take a long time whereas smaller packages mean less time/traffic used for upgrading packages. I'm not sure if merging -doc packages with their -dev packages would cause more benefit than inconvenience, as I have far greater problems with big packages than big Packages.gz files (as pabs said, pdiffs help with those). Regards Sven pgp5dx0RUsc4M.pgp Description: Digitale Signatur von OpenPGP
Re: Policy 12.3: should I rename?
On Sat, 23 Jul 2016 22:59:43 +0200 Tollef Fog Heen wrote: > ]] Jonas Smedegaard > > > Quoting Tollef Fog Heen (2016-07-23 18:58:37) > > > ]] Geert Stappers > > > > > >> FWIW I agree with both '"main package "should have > > >> documentation' and 'additional documentation in separate doc > > >> package'. > > > > > > I think we should stop recommending documentation be put in a > > > separate package and tell people who don't want docs to exclude > > > the relevant parts of /usr/share/doc using dpkg excludes > > > instead. Disk space is pretty cheap and we keep complaining > > > about the per-package overhead in Packages.gz, so it should be a > > > net gain for most people. > > > > If I understand you correctly, it will be a loss for those where > > bandwidth is expensive: Stripping documentation during install > > implied it need to be downloaded. > > Sure, but at the same time: docs tend to compress well, and people who > do development are more likely to run something up-to-date (like > testing or unstable) and so therefore are more likely to be able to > handle the bandwidth cost. I am a developer and regardless of the distribution I use, I often have a slow internet connection. So having to download possibly large documentation is a problem for me. Regards Sven
Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository
On Sun, 23 Aug 2015 13:24:03 +0200 Joachim Breitner wrote: > Hi Marvin, > > Am Samstag, den 22.08.2015, 16:47 -0400 schrieb Marvin Renich: > > I was under the (perhaps mistaken) impression that part of the > > purpose of /srv was to allow complete admin discretion with the > > directory structure, and that distributions were not to mandate any > > specific directory names. > > > > A low-priority debconf question asking the admin what directory to > > use, suggesting /srv/local-apt-repository, would satisfy that. If > > the question is not asked (or preseeded) the package would remain > > unconfigured. This would not be the only package to require > > explicit admin configuration to be operational, and the required > > configuration would be very minimal. (See below for an explanation of, why I think a debconf question would be better, though more complicated)) > With pow-priority, you mean one that does not get shown by default? > But is that much better than allowing the interested admin to change > the configuration afterwards? > > > Both apache2 and lighttpd use /var/www/html as the default > > directory to serve, and do not touch /srv automatically. I don't > > know of any Debian package that puts files in /srv. > > Note that my package does _not_ touch or put files in /srv. It merely > uses files that are put in a certain directory that, that the admin > has to create first. Does that mitigate your concerns? A problem, that I see with this, is that someone might already use /srv/local-apt-repository for something else. If that something is an apt repository (which is not unlikely with the given name) you might accidentally install files on your system, that weren't intended to be installed. With a debconf question, the admin is confronted with the fact, that this directory will be read, before doing so. If you don't want to do the debconf stuff, I offer to do it, as I have to get to know maintainer scripts and debconf anyway. Regards Sven
Re: debian github organization ?
On Thu, 16 Apr 2015 09:04:07 -0600 Dimitri John Ledkov wrote: > I'd rather see gitlab.debian.net :) I don't a reason to have gitlab/github/someother git stuff for debian, since we already have alioth. Maybe someone can enlighten me. Regards Sven pgphXmA_4Agbj.pgp Description: Digitale Signatur von OpenPGP
Re: GHC FFI libraries depend on unversioned SO.
On Wed, 20 Aug 2014 21:16:41 +0200 Sven Bartscher wrote: > Greetings, > > I noticed that libghc-regex-pcre-dev doesn't depend on libpcre6, which > causes it to fail at import. > I tried to fix that and noticed that ghc searches for the unversioned > SO (i.e. libpcre.so instead of libpcre.so.3). > > Is this normal with GHC or is this just some bug in regex-pcre? > If this is a common case, what cen we do against it? Is this only > something that can be fixed in GHC or can we fix this by some linker > options? Sorry, I mistyped the address. I actually wanted to send this to debian-haskell. Regards Sven signature.asc Description: PGP signature
GHC FFI libraries depend on unversioned SO.
Greetings, I noticed that libghc-regex-pcre-dev doesn't depend on libpcre6, which causes it to fail at import. I tried to fix that and noticed that ghc searches for the unversioned SO (i.e. libpcre.so instead of libpcre.so.3). Is this normal with GHC or is this just some bug in regex-pcre? If this is a common case, what cen we do against it? Is this only something that can be fixed in GHC or can we fix this by some linker options? Regards Sven signature.asc Description: PGP signature
Re: Hardware Support
On Tue, 19 Aug 2014 14:49:42 -0600 Ryan Burchett wrote: > Hello! My apologies if this is the wrong email to contact for my issue. debian-u...@lists.debian.org would have been better. > I would absolutely love to use Debian. I cannot do this however. The problem > I am having is that you guys do not support my Wireless card. I went to the > wiki and the wireless section and saw my wireless card on the list of > supported cards, but I can't get any internet on my computer. I would just > like if you guys could give support to the wireless card for the Asus X401U > laptop. When I run it in a live CD, the command "lspci" reads back: > > *Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe* You card is in fact already supported. The problem is, that the needed firmware to run it is not available during the installation. The only way I know around this is using a non-official installation image, with non-free firmware included. You can find them on http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/. So if you have AMD64 you would need to use http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/firmware-7.6.0-amd64-netinst.iso. Regards Sven signature.asc Description: PGP signature
Re: Why is package X not in testing yet?
On Mon, 18 Aug 2014 21:55:37 +0100
Gianfranco Costamagna wrote:
> Hi again Sven,
>
> I would just ask one (I hope little) feature, I'm not an haskell guy, so I
> find rather difficult to submit a patch :)
>
> I would like to see also this
> outputUrl =
> "people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt"
>
> (maybe with a deletion of ~/.reasons/update_output.txt)
>
> and replace "doesn't" with "doesn't " ;)
>
> maybe something like renaming update_output.txt.{ubuntu,debian} and passing
> something like -d {debian,ubuntu} by command line will make this program
> universally used and easily extensible to other debian based distros.
Greetings,
I'm now at a point, where I would like to start implementing this.
I'm not really into Ubuntu, so I have to ask a few questions.
My tool fetches the excuses using grep-excuses. Is the version of
grep-excuses in Ubuntu configured to fetch the right excuses (the ones
for Ubuntu)?
For analysing if "out of date" excuses are interesting it fetches
information from buildd.debian.org/stats/. Is this information
available in Ubuntu? Where do I get it?
Regards
Sven
signature.asc
Description: PGP signature
Re: Why is package X not in testing yet?
On Tue, 19 Aug 2014 19:15:25 +0200 Sven Bartscher wrote: > On Tue, 19 Aug 2014 18:53:52 +0200 > Jérôme Vouillon wrote: > > > Hi Joachim, > > > > On Tue, 19 Aug 2014 11:07:57, Joachim Breitner wrote: > > > unfortunately, comigrate doesn’t cut it for our case. From the page > > > for haskell-hgettext, I get redirected to haskell-uniplate, and from > > > there to other packages, none of which are the real culprit. Sven’s > > > tool has an idea of what must migrate together (relying on britney’s > > > autohinter) and ignores, for example, any dependency problems that > > > are among these packages. > > > > I agree that the online report on http://coinst.irill.org/report/ is not > > appropriate in your case. In general, it will not report all issues > > preventing the migration of a package, and the issues are not presented > > conveniently on a single page. You should try the command line tool > > (Debian package 'coinst') instead. > > > > Still, the report provides a lot more information than what you say. > > (Some list items can be unfolded by clicking on them or by clicking on > > the 'Expand all' button.) Here is what I can see regarding haskell-hgettext. > > > > haskell-hgettext needs (to migrate together with) haskell-uniplate > > which needs haskell-unordered-containers and yi. yi needs > > haskell-unordered-containers and haskell-regex-tdfa. > > > > haskell-unordered-containers will not migrate as it would break some > > packages on armel: > >haskell-github, pandoc > > and kfreebsd-amd64: > >haskell-snap, haskell-yesod-static, pandoc > > > > haskell-regex-tdfa will not migrate as it has not yet been rebuilt on > > mips. Some binaries packages from haskell-hakyll, > > haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils > > depends on the obsolete binary package. Besides, the package cannot > > migrate as this would break haskell-hakyll on armel, kfreebsd-i386 and > > kfreebsd-amd64. > > > > Thus, Bin-NMUS are needed for haskell-github, pandoc, haskell-snap, > > haskell-yesod-static and haskell-hakyll, haskell-regex-tdfa-utf8, > > haskell-hledger-lib and haskell-unixutils. > > > > The online report does not list all issues preventing the migration of > > haskell-hgettext. But note than none of the issues above are reported by > > Sven's tool. > > That's not really true. > My tool DID report that haskell-regex-tdfa is out of date on mips and > thus requires a binNMU. All reverse dependencies would have been > reported once haskell-regex-tdfa is rebuilt. > This is not really the best way, because it doesn't allow ordering > binNMUs in large groups. Sorry. s/is out of date/misses a dependency/ signature.asc Description: PGP signature
Re: Why is package X not in testing yet?
On Tue, 19 Aug 2014 18:53:52 +0200 Jérôme Vouillon wrote: > Hi Joachim, > > On Tue, 19 Aug 2014 11:07:57, Joachim Breitner wrote: > > unfortunately, comigrate doesn’t cut it for our case. From the page > > for haskell-hgettext, I get redirected to haskell-uniplate, and from > > there to other packages, none of which are the real culprit. Sven’s > > tool has an idea of what must migrate together (relying on britney’s > > autohinter) and ignores, for example, any dependency problems that > > are among these packages. > > I agree that the online report on http://coinst.irill.org/report/ is not > appropriate in your case. In general, it will not report all issues > preventing the migration of a package, and the issues are not presented > conveniently on a single page. You should try the command line tool > (Debian package 'coinst') instead. > > Still, the report provides a lot more information than what you say. > (Some list items can be unfolded by clicking on them or by clicking on > the 'Expand all' button.) Here is what I can see regarding haskell-hgettext. > > haskell-hgettext needs (to migrate together with) haskell-uniplate > which needs haskell-unordered-containers and yi. yi needs > haskell-unordered-containers and haskell-regex-tdfa. > > haskell-unordered-containers will not migrate as it would break some > packages on armel: >haskell-github, pandoc > and kfreebsd-amd64: >haskell-snap, haskell-yesod-static, pandoc > > haskell-regex-tdfa will not migrate as it has not yet been rebuilt on > mips. Some binaries packages from haskell-hakyll, > haskell-regex-tdfa-utf8, haskell-hledger-lib and haskell-unixutils > depends on the obsolete binary package. Besides, the package cannot > migrate as this would break haskell-hakyll on armel, kfreebsd-i386 and > kfreebsd-amd64. > > Thus, Bin-NMUS are needed for haskell-github, pandoc, haskell-snap, > haskell-yesod-static and haskell-hakyll, haskell-regex-tdfa-utf8, > haskell-hledger-lib and haskell-unixutils. > > The online report does not list all issues preventing the migration of > haskell-hgettext. But note than none of the issues above are reported by > Sven's tool. That's not really true. My tool DID report that haskell-regex-tdfa is out of date on mips and thus requires a binNMU. All reverse dependencies would have been reported once haskell-regex-tdfa is rebuilt. This is not really the best way, because it doesn't allow ordering binNMUs in large groups. Regards Sven signature.asc Description: PGP signature
Re: Why is package X not in testing yet?
On Mon, 18 Aug 2014 21:55:37 +0100
Gianfranco Costamagna wrote:
> I would just ask one (I hope little) feature, I'm not an haskell guy, so I
> find rather difficult to submit a patch :)
>
> I would like to see also this
> outputUrl =
> "people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt"
>
> (maybe with a deletion of ~/.reasons/update_output.txt)
>
> and replace "doesn't" with "doesn't " ;)
done.
>
> maybe something like renaming update_output.txt.{ubuntu,debian} and passing
> something like -d {debian,ubuntu} by command line will make this program
> universally used and easily extensible to other debian based distros.
That's a bit more tricky than it seems, due to limitations in wget.
wget doesn't support the -N (only download if remote file if newer)
together with -O. So if I rename them wget won't be able to check their
timestamps.
Even worse I'm currently working on a filter for "out of date" excuses,
which uses information from the buildds, which are Debian specific.
So support for derivates won't come very soon. But I will look at it as
soon as I have a clue how to do it.
>
> thanks again for the nice and useful work you did!
Regards
Sven
signature.asc
Description: PGP signature
Re: Why is package X not in testing yet?
On Mon, 18 Aug 2014 23:51:43 +0200 Pietro Abate wrote: > Hei Sven, > > On 18/08/14 18:10, Sven Bartscher wrote: > > If we have a package, which doesn't migrate to testing, we usually > > check the "Why does package X not in testing yet?" page or the PTS. > > Usually they do a great job in telling us why our package doesn't > > migrate. > > > > But sometimes you have packages, which have complicated dependencies, > > that don't make it easy to tell why our package doesn't migrate. > > Usually the PTS and "Why is package X not in testing yet?" fail at > > those packages and don't give any useful explanation. For example look > > at the page for haskell-hgettext[1]. > > you might want to have a look at comigrate [1] a tool designed to > answer these kind of questions and provide explanations that are as > compat as possible. For example for haskell-hgettext [2] . If you find > it useful, I'm sure the authors would be happy to hear from you. I looked at it and it's a great tool to identify problems with migrations, but it's not really what I was aiming for when I wrote my tool. The web interface does list that haskell-src-exts needs to migrate, which is right, but not really helpful. To find the root causes of the problem I need to navigate through all the packages with their own listings. If my browser wouldn't mark links I already visited I would have a great chance to end up in a loop. So it's just too much data to understand what's the problem and what to do against it. The command line interface couldn't provide as much information. It follows the dependency chain until it ends up at pandoc and doesn't know what to do. My tool (which still doesn't have a name, suggestions welcome) has another approach of identifying the problem. Instead of checking dependencies it checks for the autohint the package in question is in. So instead of searching for the relevant information itself, it takes a huge amount of information and filters it for the useful informations. Wile this approach gathers more relevant information than other tools (I know), I still don't know if it identifies all issues a package might have. So in conclusion: comigrate is a really nice tool. But, as far as I know, it's not really suitable to analyse transitions, as big as haskell transitions. Regards Sven signature.asc Description: PGP signature
Why is package X not in testing yet?
Greetings,
If we have a package, which doesn't migrate to testing, we usually
check the "Why does package X not in testing yet?" page or the PTS.
Usually they do a great job in telling us why our package doesn't
migrate.
But sometimes you have packages, which have complicated dependencies,
that don't make it easy to tell why our package doesn't migrate.
Usually the PTS and "Why is package X not in testing yet?" fail at
those packages and don't give any useful explanation. For example look
at the page for haskell-hgettext[1].
Those packages usually have to go into testing together with a few other
packages. If it's getting worse your package needs to go into testing
with a lot of other packages (usually if your package is part of a
bigger transition).
If your package is part of a transition you might have luck and the
transition page can tell you what the problem is. But sometimes not
even that pages help.
For that reason I made a tool that takes a package name and tries to
find out why your package doesn't migrate to testing.
When run, it gathers all packages that block our given package X.
Then it fetches all excuses for these packages and throws all of them
away, except those that are identified as interesting. These types of
excuses are identified as interesting:
- out of date on
- has new bugs
- Too young
This takes a long time (for me 3 Minutes) depending on your internet
connection.
This is mostly useful for haskell packages, as they have very close
dependencies. However, it might be interesting in any other transition.
The source code is attached and can be found in the tools repository[2]
of the Haskell Group.
In order to compile it you need the following packages:
- ghc
- libghc-regex-pcre-dev
- libpcre++-dev (This should be a dependency of libghc-regex-pcre-dev
but it isn't due to a bug)
Compile it with:
ghc --make reasons.hs
To run it you need the following packages:
- devscripts
- wget
- ca-certificates
- locales (you should use an UTF-8 encoding, otherwise its guaranteed
you will have problems.)
Also you must have enabled the source URIs in you sources.list.
There are still some rough edges. The most notable ones are:
- Most errors that can happen aren't catched. So an haskell exception
will be thrown, which gives not very much information of the problem.
- The excuses are fetched with grep-excuses. So the excuses file is
downloaded over ad over again. There is already a bug with a patch
filed against grep-excuses to fix this.
- "out of date" excuses are all considered interesting, even though it
would be better to only include those that aren't in state B-D
unistallable.
A bit more detail on the workflow of this tool is described in this[3]
post.
[1]:
https://release.debian.org/migration/testing.pl?package=haskell-hgettext
[2]: http://anonscm.debian.org/cgit/pkg-haskell/tools.git/
[3]: https://lists.debian.org/debian-haskell/2014/08/msg00027.html
import Text.Regex.PCRE
import System.Environment
import System.Exit
import System.Process
import System.IO
import Data.Maybe
import Data.List
import Data.Char
import qualified Data.Set as S
import Control.Exception
import System.IO.Error
import System.Directory
import Debug.Trace
data Excuses = Excuses String [String]
isEmpty :: Excuses -> Bool
isEmpty (Excuses _ []) = False
isEmpty (Excuses _ _) = True
excuses2String :: Excuses -> String
excuses2String (Excuses pkg excuses) = unlines $ (pkg ++ ":"):(map ("" ++) excuses)
main = do
package <- getArgs >>= parse
output <- fmap lines acquireBritneyOut
let bins = getBinBlockers output package
result <- try (fmap nub $ mapM getSrcPackage bins) :: IO (Either ErrorCall [String])
srcBlockers <- case result of
Left e -> putStrLn packageNotFoundMsg >> exitFailure
Right pkgs -> return pkgs
excuses <- mapM getExcuse srcBlockers
additionalExcuses <- getAdditionalExcuses srcBlockers excuses
let filteredExcuses = filterExcuses isInteresting $ excuses ++ additionalExcuses
mapM_ putStrLn $ map excuses2String filteredExcuses
acquireBritneyOut :: IO String
acquireBritneyOut = do
cachePath <- chooseCachePath
case cachePath of
Nothing -> readProcess "/usr/bin/wget" ["-q", "-O", "-", outputUrl] ""
Just path -> do
createDirectoryIfMissing False path
setCurrentDirectory path
readProcess "/usr/bin/wget" ["-q", "-N", outputUrl] ""
readFile "update_output.txt"
chooseCachePath :: IO (Maybe String)
chooseCachePath = do
result <- tryJust shouldCatch $ getAppUserDataDirectory "reasons"
hasHome <- getHomeDirectory >>= doesDirectoryExist
return $ case result of
Right dir -> if hasHome
then Just dir
else Nothing
Left _ -> Nothing
where shouldCatch e = if isDoesNotExistError e
then Just e
else Nothing
outputUrl :: String
outputUrl = "release.debian.org/britne
Re: suspension bug
On Thu, 14 Aug 2014 19:23:05 +0200 Sven Bartscher wrote: > Greetings, > > I have found a bug and don't know which package to report it on. > The bug is that my computer immediately awakes from suspension if > certain USB devices are connected. > Can anyone point me at the right package? It turned out that my usb-hub had wakeup enabled. Disabling it fixed the problem. Thanks for your time and help. Regards Sven signature.asc Description: PGP signature
Re: suspension bug
On Thu, 14 Aug 2014 20:00:03 +0100 Anthony F McInerney wrote: > I think it would be good to know if your running stable or testing. and if > you are on systemd or not. > irc channels on irc.debian.org #debian or #debian-next are very good for > 'live support' so that the issue can be dug into. I'm running testing, with systemd. I switched to systemd recently, but the with sysvinit I had the same problem. If you (or anyone else) have further questions, you can find in me in #debian-next (name: Kritzefitz). > On 14 August 2014 19:45, Sven Bartscher > wrote: > > > On Thu, 14 Aug 2014 14:34:23 -0300 > > Lisandro Damián Nicanor Pérez Meyer wrote: > > > > > On Thursday 14 August 2014 19:23:05 Sven Bartscher wrote: > > > > Greetings, > > > > > > > > I have found a bug and don't know which package to report it on. > > > > The bug is that my computer immediately awakes from suspension if > > > > certain USB devices are connected. > > > > Can anyone point me at the right package? > > > > > > IIRC there was an option on some BIOS to do exactly that. Check yours in > > case > > > you didn't already, and good luck :) > > > > I checked that. All wake events (that can be configured) are disabled. > > signature.asc Description: PGP signature
Re: suspension bug
On Thu, 14 Aug 2014 14:34:23 -0300 Lisandro Damián Nicanor Pérez Meyer wrote: > On Thursday 14 August 2014 19:23:05 Sven Bartscher wrote: > > Greetings, > > > > I have found a bug and don't know which package to report it on. > > The bug is that my computer immediately awakes from suspension if > > certain USB devices are connected. > > Can anyone point me at the right package? > > IIRC there was an option on some BIOS to do exactly that. Check yours in case > you didn't already, and good luck :) I checked that. All wake events (that can be configured) are disabled. signature.asc Description: PGP signature
Re: suspension bug
On Thu, 14 Aug 2014 20:13:04 +0200 Tomasz Nitecki wrote: > On 14/08/14 19:23, Sven Bartscher wrote: > > I have found a bug and don't know which package to report it on. > > The bug is that my computer immediately awakes from suspension if > > certain USB devices are connected. > > Can anyone point me at the right package? > > Hey, > > 1. You wrote about 'devices' so I assume that it happens only with a few > specific ones (but more than one) and not with others? Right. The devices are a HBCI card reader and USB receivers for wireless gamepads. But as I noticed just now: They only cause the computer to wake up if they are connected to an additional USB card (which is conect to the mainboard via an internal USB connector). > 2. Does it happen every time or just form time to time? It happens every time these devices are connected to the ports mentioned above. > 3. Did you check your dmesg for any warning or error messages after such > a wakeup? I didn't see anything suspicious. Just the messages about the computer going down, followed by the messages about the computer waking up again. Regards Sven signature.asc Description: PGP signature
suspension bug
Greetings, I have found a bug and don't know which package to report it on. The bug is that my computer immediately awakes from suspension if certain USB devices are connected. Can anyone point me at the right package? Regards Sven signature.asc Description: PGP signature
NVIDIA CUDA headers
Greetings everyone, I recently tried to compile some library against libcuda1. However I couldn't do so because the headers, in this case cuda.h, were missing. I searched a lot through the different cuda and nvidia packages but couldn't find a package containing the headers. A search on packages.d.o for the file cuda.h didn't yield something useful either. Can anyone tell me where they are? Are they even packaged? Regards Sven signature.asc Description: PGP signature
Re: systemd-sysv/shim in testing
On Sun, 27 Jul 2014 21:21:56 +0200 Holger Levsen wrote: > Hi, > > On Sonntag, 27. Juli 2014, Dominik George wrote: > > >To make it short: I suggest that systemd should only migrate together > > >with systemd-shim. > > ACK! > > I think you missed the mail (on this list) which explained that systemd has > been waiting for >6 months for systemd-shim to catch up. Yeah, I kind of missed that. It's right that my suggestion is not going to work if systemd-shim is that much behind. As a solution I would suggest that a few more people help with the development of the shim. (Of course, only if that's alright for the current maintainer.) For this matter I would offer my help for issues of this kind in the future, in the hope that we will be able to keep the shim up to date with systemd without blocking it too much. Regards Sven signature.asc Description: PGP signature
systemd-sysv/shim in testing
Greetings everyone, As brought up in this[0] thread, systemd-shim became incompatible with the latest versions of systemd and the alternative dependency was removed. While this is something I can totally understand, I don't think that systemd should migrate to testing without the possibility to use systemd-shim instead. My reasoning about this is as follows: Testing should be as close to a state in which it can be released as possible (I don't have a citation for that and just remember that I did read that somewhere, so please correct me if I'm wrong). Further we are not planning to release jessie without systemd-shim (at least I hope so, again please correct me if I'm wrong). This shouldn't be a huge problem, since waiting a week longer until systemd migrates shouldn't be that much of a problem, while it makes the risk smaller to accidentally remove your desktop-environment at a dist-upgrade (that's at least what apt wanted to do on my computer). To make it short: I suggest that systemd should only migrate together with systemd-shim. [0]: https://lists.debian.org/debian-devel/2014/07/msg00839.html Regards Sven signature.asc Description: PGP signature
"thanks" messages on mailing lists/bug reports
Greetings everyone, I recently started contributing to debian. Before that, most of my writing with people I don't know personally through the internet was on Stack Exchange. On Stack Exchange, messages that only consist of thanking people or agreement are not considered helpful. This in mind I'm very unsure if I should write messages like that to someone or if I should avoid them (to not annoy anyone with them), on Debian mailing lists or bug reports. What is your experience with that? How do you feel if you read such messages? Maybe more important: How do you feel if you don't get such messages? Regards (and in the hope of not annoying anyone) Sven signature.asc Description: PGP signature
Re: DFSG : Really useful?
On Sun, 27 Apr 2014 14:16:31 +0200 Solal wrote: > > I see that you don't like the DFSG. But as already has been said: We > > are Debian and follow our own contract and not a contact of some other > > project/company. > > I think if you have problems with the DFSG you should propose changes > > to improve it instead of saying we should drop it and follow someone > > else. > > > > PS: Please don't top-post. > > > > Regards > > Sven > > I understand you do not want use a someone else's contract, but the FSDG > are an anagream of DFSG, so that's the same... No, I joke. > There are a lot of things to change in the DFSG, but why change the > DFSG, the better contract is created : that's the FSDG! I do not see any > problems for using it! That's your opinion. I (for example) wouldn't call the FSDG "better" than the DFSG. So the problem is that the people making Debian are just not the same as the ones from FSF. I guess the differences between FSDG and DFSG are there because the people here WANT them like that. Not everyone here has to agree that FSDG is better than the DFSG just because you do. Regards Sven signature.asc Description: PGP signature
Re: DFSG : Really useful?
On Sun, 27 Apr 2014 12:05:21 +0200 Solal wrote: > The two documents are incompatible, and the DFSG is very laxist and do > not protects completely freedom. FSDG protects freedoms : it resolves > issues : proprietary software is totally banned, patents are prohibited, > trademarks limited, etc. > > GFDL is free, because Invariant Sections are free if used in opinions > (nobody want peoples modify their opinion in a text). The GFDL prohibit > the use of Invariant Sections in technic texts. > > The only case where a software respects FSD but not DFSG is good. That > can be a software which prohibit the use of proprietary software in > aggregates. > This is good, totally ethical, and I think a license should do that for > protect uers from proprietary. > > The cases where a software respects DFSG but not respects FSD are bad. > For example, a software which prohibit the distribution of modified > versions respects DFSG if it authorize patch files. > But it's unethical. > > In some years, the patch will maybe be incompatible with the new version. > The Debian project authorize that (but encourage to do not do that, but > that's not suffiscient). > > The Debian project authorize too certain licenses which is too vague for > talk about free (the Artistic License 1.0, for example). > > The DFSG is really bad, too laxist and useless. I see that you don't like the DFSG. But as already has been said: We are Debian and follow our own contract and not a contact of some other project/company. I think if you have problems with the DFSG you should propose changes to improve it instead of saying we should drop it and follow someone else. PS: Please don't top-post. Regards Sven signature.asc Description: PGP signature
Re: DFSG : Really useful?
On Fri, 25 Apr 2014 15:14:49 +0200 Solal wrote: > Why not just take the Free Software Definition[0] instead lose a lot of > time in specific guidelines. > I think use the Free System Distribution Guidelines published by the > FSF[1] is the best way. Use the FSDG instead of the DFSG will : > -Be more efficient instead of lose a lot of time in the DFSG. > -Be sure to be in the 100% free GNU/Linux distros list of the FSF. I think we still wouldn't get into the list of free distros, because Debian isn't classified as free (by FSF) because of the nonfree repositories, which we don't want to drop (as far as I know). Also I think it's useful to have our own guidelines. signature.asc Description: PGP signature
Re: Debian default desktop environment
On Wed, 9 Apr 2014 13:04:09 -0500 Gunnar Wolf wrote: > Each of us will have different anecdotary evidence pushing the opinion > one way or the other. We cannot please everyody with a single DE, and > that's (part of) the reason there are so many. I can speak you of the > users I switched over that are perfectly happy with Gnome (started > with 2.x and migrated painlessly to 3.x). Note that I could not do the > same - I was +- at ease with Gnome 2, but loathe the 3.x > interface. Oh, and the KDE interface has always stung my eyes and > fingers. I didn't really want to propose KDE as the default for Debian or say it's "better" than GNOME or XFCE. I just wanted to note that it's not really true that Linux has no competitor for windows-desktop. So I agree it's not helpful to speak about personal flavours. signature.asc Description: PGP signature
Re: Debian default desktop environment
On Tue, 08 Apr 2014 23:10:13 -0300 converge wrote: > The point is: is all this effort pointing to the future of linux > desktop, or is it just some workaround to try to make users a bit happy > for now ? > > The truth is that linux still doesn't have a competidor for windows and > mac window manager and we should care about it. Sorry. I can't really agree with you. When I compare KDE to the Windows window manager I don't see any points for windows. I see that this is a matter of taste. But saying it's not a competitor is something I can't agree with. I can't really say anything about Mac, because I never used it. > > Em 28/08/14 14:09, Kevin Chadwick escreveu: > > previously on this list Jean-Christophe Dubacq contributed: > > > >>> I am talking about focus follows mouse but raise only on clicking say > >>> the border or bar, you can still enter text into any layered windows > >>> that have focus. So you can quickly switch for entry to or from web > >>> pages on one screen or read a web page in the background. Reference 4 > >>> open windows at once, use the scroll upon focus etc.. Basically the > >>> closest thing to a panelling window manager like scrotwm (which I could > >>> learn) without needing to learn the commands (works for my users too > >>> and I should test what I provide) and allowing overlapping for > >>> redundant web edges, saves time re-sizing etc.. > >> > >> And this is a so tiny detail that it does not matter for what should be > >> the default desktop environment. No matter how configurable is your > >> thing, what matters is how usable is it out of the box. > > ??? I agree with someone else who responded with "killer feature" as for > > me it is also a primary requirement from a window manager precisely > > because of the usability increase. > > > >> For the rest, > >> apt-get or any other package management interface is your friend. > > Exactly, This all came from xfce multiple desktop support in debian 8 > > apparently not being the best, I was merely saying that it matters less > > to xfce because of this feature but also with *randr from apt-get it is > > not a problem and later versions than xfce-display-settings-4.10 I > > am pretty sure do have good support without *randr bootstrapping. > > > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/5344ac05.9040...@jplab.com.br > signature.asc Description: PGP signature
Re: identifying unused manually installed packages
On Fri, 28 Mar 2014 09:05:49 +0800 Paul Wise wrote: > On Fri, Mar 28, 2014 at 5:36 AM, Sven Bartscher wrote: > > > Also I'm not really sure if this is even a good idea, or if there is > > maybe another program already present which does already identify > > unused, manually installed packages and I just didn't find it. > > deborphan seems like a similar package: > > https://packages.debian.org/stable/deborphan I looked at it but don't really get how it guesses which packages are unneeded. It seems to only suggest leafs (of the dependency tree) but it doesn't suggest all leafs for removal. It doesn't seem like it is looking at timestamps. Can anyone tell me how it is searching for unneeded packages? While trying some stuff with my script I saw that most (maybe all) desktop applications, which have a menu entry, won't be found, because their .desktop files are frequently accessed. So I think following this approach isn't really worth the afford. > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > https://lists.debian.org/caktje6exk2ivaleescok+6tvq5dqx_oxhyk0pll5rh9c9bo...@mail.gmail.com > signature.asc Description: PGP signature
identifying unused manually installed packages
Greetings everyone. As we all know apt-get does a very good job, by identifying which packages were installed automatically as dependencies and aren't needed anymore. Wile this is very nice, I still fear that, from time to time, there are manually installed packages gathering on my computer which I don't use but don't remove because I don't even know I once installed them. Another problem like this is that build-depends aren't removed either, because they are marked as manually installed. I thought a little while about this problem and came up with the idea, that every manually installed package whose files were not accessed for more than a specified time (a month, a year, whatever) could be considered unneeded. So I started writing a script that identifies just those packages that are probably not needed anymore. As it seems it works as expected. This approach also brings some problems. For example some packages that have files which belong to a frequently scanned database aren't detected because they are accessed by the scan. Also I'm not really sure if this is even a good idea, or if there is maybe another program already present which does already identify unused, manually installed packages and I just didn't find it. But if this approach is maybe a good idea. Would it be worth to consider packaging it? If so, I would be able to maintain it, even though I would need a sponsor. What are your thoughts on this approach to take the system clean? Regards Sven Bartscher signature.asc Description: PGP signature
Re: "contrib" and "nonfree" distribs
On Fri, 28 Feb 2014 20:21:13 +0100 Bálint Réczey wrote: > Hi Solal, > > 2014-02-28 19:24 GMT+01:00 Solal Rastier : > > Le 28 févr. 2014 à 19:22, Octavio Alvarez a > > écrit : > > > >> On 02/28/2014 09:29 AM, Solal Rastier wrote: > > > My mail client top-posting automtically. I don't compare Windows and > > Debian. Windows is proprietariest than Debian, but Debian isn't 100% free. > > Now, think about the utility of "contrib" and "nonfree". We must create > > free replacements to proprietary, not put proprietary in Debian. Additionally I would like to say that Debian is a software distribution, not a project for creating new software. So it seems like a little bit out of scope to write new software. So like Balint says when there are good replacements, they will be happily included. I want to note at this point that the FSF isn't the ultimate resource for deciding what Free Software is and what not. There are many (well, at least me) people who don't agree with the explanation why Debian isn't free software. You could even argue that it wouldn't be free NOT to include non-free software into the Debian archives. Because (so one could argue) it would take away your freedom (which is all the FSF is reasoning about) to install non-free software through apt-get. > You are enthusiasm is welcome. Your help in improving free > replacements would also be appreciated. > There are pages for people who would like to start contributing to > Debian, they may be interesting for you: > https://www.debian.org/intro/help > https://wiki.debian.org/how-can-i-help > > The more we improve Free Software, the sooner we can remove > non-free(/contrib) parts of Debian. > > Cheers, > Balint signature.asc Description: PGP signature
Bug#739538: ITP: libghc-setlocale -- Haskell bindings to setlocale()
Package: wnpp Severity: wishlist Owner: Sven Bartscher * Package name: libghc-setlocale Version : 0.0.3 Upstream Author : Name l@web.de * URL : http://hackage.haskell.org/package/setlocale * License : PublicDomain Programming Lang: haskell Description : Haskell bindings to setlocale() This package provides haskell bindings to setlocale() I'm going to maintain this package together with a co-maintainer, Thomas Bartscher. We're going to need a sponsor. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140219192836.13187.99322.reportbug@sven.bartscher
