Bug#758874: ITP: python3-pyelliptic -- High level Python 3 wrapper for OpenSSL
Package: wnpp Severity: wishlist Owner: Riley * Package name: python3-pyelliptic Version : 1.5.3 Upstream Author : Yann Guibet * URL : https://github.com/yann2192/pyelliptic/ * License : GPL-3+ with OpenSSL linking exception Programming Lang: Python 3 Description : High level Python 3 wrapper for OpenSSL PyElliptic is a Python 3 module that provides high level access to the OpenSSL library, featuring elliptic curve cryptography (ECC), symmetric cryptography and more. The full list of functions is below: Key agreement : ECDH Digital signatures : ECDSA Hybrid encryption : ECIES (like RSA) AES-128 (CBC, OFB, CFB, CTR) AES-256 (CBC, OFB, CFB, CTR) Blowfish (CFB and CBC) RC4 CSPRNG HMAC (using SHA512) PBKDF2 (SHA256 and SHA512) -- 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/20140822102615.14869.86891.reportbug@fleetstreet
Bug#773850: ITP: signify-openbsd -- Lightweight cryptographic signing and verifying tool
Package: wnpp Severity: wishlist Owner: Riley * Package name: signify-openbsd Version : 7 Upstream Author : Adrian Perez * URL : https://github.com/aperezdc/signify * License : BSD Programming Lang: C Description : Lightweight cryptographic signing and verifying tool Similar to GNU Privacy Guard (GPG), signify is the tool which OpenBSD uses to cryptographically sign its releases, so that you can be sure that you are actually getting a release made by OpenBSD, as opposed to a malicious forgery designed to look the same. Signify's usage is not limited to OpenBSD's releases, however - it can be used to sign any software. So that it will work on Linux, the version of signify provided in this package is not exactly the same as the version provided in OpenBSD's CVS tree; however the upstream changes are frequently merged. -- 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/20141224024221.13086.89563.reportbug@fleetstreet
Bug#754357: ITP: gmastermind.app -- GNUstep clone of Mastermind (TM)
Package: wnpp Severity: wishlist Owner: Riley * Package name: gmastermind.app Version : 0.6 Upstream Author : Marko Riedel * URL : http://gap.nongnu.org/gmastermind/ * License : GPL2 Programming Lang: Objective C Description : GNUstep clone of Mastermind (TM) This game is part of GAP, the GNUstep Application Project. Guess the correct combination of pegs. With each guess, you will be given a hint indicating how close your guess was to the correct answer. You have eight turns to guess correctly. -- 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/20140710101245.5134.54375.reportbug@fleetstreet
Re: GUI Configuration tool for main Debian window managers
On 06/01/15 05:17, john Lutz wrote: > I was wondering how one would one go about buildinga GUI tool to cover every > imaginable setting via a GUIinterface for the majority of standard live and > other installedDebian distribtion?.. And what tools / standards > are required by such? Hmm... each GUI would be configured in a different way, so I guess that you'd have to write code for each individual environment. You can make a basic GUI using zenity. Alternatively, you could try to combine already existing configuration tools, like gnome-control-center and xfce4-settings, but I'm not sure how practical this would be. -- 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/54aaed5f.4080...@bitmessage.ch
Re: length of a package extended description
> Otherwise shouldn't utilities (such as "dpkg -s") provide a > configurable way to limit the output of the "Description:" field? You can pipe the output to "head" or "tail" to sort of achieve what you want to. -- 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/54b0349c.3060...@bitmessage.ch
Re: length of a package extended description
On 10/01/15 08:59, Vincent Lefevre wrote: > On 2015-01-10 07:05:48 +1100, Riley Baird wrote: >>> Otherwise shouldn't utilities (such as "dpkg -s") provide a >>> configurable way to limit the output of the "Description:" field? >> >> You can pipe the output to "head" or "tail" to sort of achieve what you >> want to. > > Obviously not. It may be possible with something like sed or perl, > but this may not be future-proof, and breakage due to changes in > the dpkg output may remain unnoticed. And doing that automatically > would need to write a dpkg wrapper, which could break dpkg in other > contexts. True. I honestly think that this is such an insignificant problem that updating the sed or perl script every so often wouldn't be that much of a problem. If it interests you, you could always right a patch for dpkg; it doesn't seem that it would be that hard to do so, and I don't see any reason why the patch would be refused. -- 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/54b06962.8000...@bitmessage.ch
Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows
> * URL : https://github.com/xaionaro/xlennart The URL should be the main branch of xlennart; that is https://github.com/Xylemon/xlennart >> if there are other packages providing similar functionality, how does it >> compare? > > This's a fork of XBill. Everything the same, just with Lennart and SystenD > instead of Bill and Wingdows. That sounds like a lot of code duplication. Is it possible to have a common library between XBill and XLennart? (Also, in any case, don't you think that this game is going a little too far? It's fine to be opposed to systemd, but don't do to Lennart Poettering what the gamergate people did to Anita Sarkeesian.) -- 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/54b823e9.70...@bitmessage.ch
Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows
On 16/01/15 12:40, Paul Wise wrote: > On Fri, Jan 16, 2015 at 4:32 AM, Riley Baird wrote: > >> That sounds like a lot of code duplication. Is it possible to have a >> common library between XBill and XLennart? > > ITP submitters aren't necessarily subscribed to debian-devel, please > CC the submitter and their bug. Sorry, will do. I just hit the "Reply List" button in Thunderbird without checking the addresses. -- 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/54b8a34e.3010...@bitmessage.ch
Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows
> While not a full-scale ad-hominem attack, I’d say that the two > differences I know of between the vrms operation and the > official FSF position amount to a misrepresentation at best. > Are we going to drop that package, too? If you apt-cache show vrms, you will see the notice explaining that RMS does not actually hold the same views on freedom as Debian, and that the software defaults to the DFSG in cases of difference of opinion. Similarly for the man page of vrms. In any case, it seems that Dmitry has now decided not to package the xlennart. If nobody else is willing to package it, I would recommend that this bug be closed. If someone else is willing to package it, then the bug ownership should be changed to reflect this. -- 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/54b9a247.3040...@bitmessage.ch
Re: length of a package extended description
> This is *not* what I asked. I've complained on the long description > only. The other fields like "Depends:" are still needed, without > having them to be truncated by "less". > > This shows that any attempt to write a wrapper will fail at some > point, and the real solution would be either to limit the length > of the extended description or to have an option in the tools to > limit the length of the output of the extended description. I realise that long package descriptions can be inconvenient. ~2000 lines is kind of ridiculous. However, is it really worth a discussion which has gone on this long? Even if a policy decision isn't made, you could: * File a lintian wishlist bug with the "pedantic" severity about extended descriptions over a certain length. This would convince many packagers to reduce the length of their description, even if not enforced. * Write a patch for apt or dpkg that allows the user to decide whether to limit the length of the output. I see no reason why it wouldn't be accepted. -- 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/54bee7e5.5060...@bitmessage.ch
Re: comment installer une imprimante canon PIXMA MG2450
On 24/01/15 02:18, bejaoui wrote: > j ' ai eu des problèmes d' installation de l' imprimante j' arrive télé > charger les logiciels qu' il faut je vous demande de l' aide merci. Nous ne parlons pas français. debian-devel-fre...@lists.debian.org -- 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/54c2a2be.3040...@bitmessage.ch
Re: motd handling in jessie
>> If we go the update-motd route, I'd like to see the update-motd calls be >> removed from login (and boot) and instead have the dynamic part of >> /etc/motd be updated via a cron job. > > Please, no. Under normal circumstances, the only dynamic bit of the > motd comes from uname, and only changes on reboot; updating it via cron > just wastes cycles and adds noise to syslog. > > I'm not particularly convinced that even the existing uname line has > much value. So what about this: why don't we move all of that machinery > to an update-motd package or similar (priority optional), which can hook > into PAM as desired to display its message, and have the default motd of > the base system be completely static, with nothing run at boot *or* > login? I think that this is a good idea. If the user needs to see the uname, and they're using a terminal, they'll most likely know the command to enter. -- 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/54c2a8b3.7080...@bitmessage.ch
Re: motd handling in jessie
On 24/01/15 15:18, Russ Allbery wrote: > Josh Triplett writes: > >> Please, no. Under normal circumstances, the only dynamic bit of the >> motd comes from uname, and only changes on reboot; updating it via cron >> just wastes cycles and adds noise to syslog. > >> I'm not particularly convinced that even the existing uname line has >> much value. So what about this: why don't we move all of that machinery >> to an update-motd package or similar (priority optional), which can hook >> into PAM as desired to display its message, and have the default motd of >> the base system be completely static, with nothing run at boot *or* >> login? > > I do feel like we're losing some value by not showing users the uname > information by default, and I'd like to still see us update that at boot. > I certainly agree that running shell code from PAM by default is not a > good idea. > > That said, by far the best way to handle MOTD is to write out a static > file using whatever configuration management system you're using, based on > all the information that it gathers about the system (via something like > ohai or facter). That lets you flesh out the MOTD with lots of details > that are actually interesting. But that's not something Debian needs to > be doing; each site can handle that. Sort of off topic, but as far as I can tell, the historical purpose of MOTD was to send a message to all users of a system. Is it still used for this? Are there other uses of it? -- 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/54c34bb4.4010...@bitmessage.ch
Re: Suggestion for the installer, when non-free firmwares are needed
> I just installed Debian 8 (testing) on a PC of mine with the > graphical installer and the setup ran really smooth - with one > exception: It was a big hassle to find and download the unfree > firmware for my Wifi adapter, which I needed for the installation. Generally, you shouldn't need a network connection for installation if you downloaded the full CD. > Here’s a suggestion: Let the installer display a code, which the > user can enter on debian.org - it then automatically shows you the > needed files and let you download them instead of mentioning > cryptic file names like rtl8168e-3.fw and so on. That's a good idea. That being said, tarballs containing *all* of the firmware are already (unofficially) produced on a regular basis[1]. Perhaps an easier way of solving this problem would be to have the installer tell the user where these tarballs/zip files are, and that they need to extract them onto a USB stick if they want to use them during the installation? [1] http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/ -- 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/54c6ff80.7090...@bitmessage.ch
Re: Suggestion for the installer, when non-free firmwares are needed
On 27/01/15 19:19, Johannes Schauer wrote: > Hi, > > Quoting Riley Baird (2015-01-27 04:01:20) >> That's a good idea. That being said, tarballs containing *all* of >> the firmware are already (unofficially) produced on a regular >> basis[1]. >> >> Perhaps an easier way of solving this problem would be to have >> the installer tell the user where these tarballs/zip files are, >> and that they need to extract them onto a USB stick if they want >> to use them during the installation? > > maybe it would also not hurt to, in addition to that, also make > this note on the main download page for the CD images? (probably > also noting that these files are unofficial and not part of Debian > but provided as a courtesy towards owners of hardware that > unfortunately requires non-free drivers/firmware) Unofficial CD images with the firmware included are also made. You don't even need a USB stick. http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ > That downloading these tarballs/zip files and putting them on a USB > stick would allow the Debian installer to find them was also news > to me and until now I always manually grabbed the specific needed > .deb from a mirror. Personally, I prefer this method. You can update the firmware more easily and it makes it easier to know which non-free packages are on your system. But it's important that people at least know about the other method. -- 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/54c74bbd.7090...@bitmessage.ch
Bug#776005: general: After finished the installation, I rebooted and the initialization has been stopped
I'm not sure - sorry. I have noticed, however, that you forgot to CC the bug. I've just done that now, so hopefully someone else will know. On 24/01/15 23:54, Fco. Javier Fdez. Serrador wrote: > No, I cannot it because the keyboard does not start. I started with > Advanced Options --> Debian GNU/Linux (recovery mode). > Then, as root, I do a exit, and then it start the rest OK greeen, and > then start LXDE. > > > 2015-01-22 21:04 GMT+01:00 Riley Baird > : >>> The initialization is stoped and the system does not do anything. I have to >>> do >>> a hard reboot, and select the emergency bootup. >> >> Does it work when you use the "sysvinit" option? > > > -- 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/54c8435d.1020...@bitmessage.ch
Re: Jessie Release
On 29/01/15 09:32, Balder García García wrote: > Hi, I only want to know when will jessie released , I am waitting for > SteamOS final version, but first you must launch jessie, thanks for your > time! // Hola, solo quería saber cuando se lanzará la versión estable de > Debian Jessie, estoy pendiente del lanzamiento de la versión definitiva de > SteamOS, pero primero se supone que debería salir Jessie, ¡Muchísimas > gracias por vuestro tiempo! Jessie won't be released until all of the RC bugs have been fixed. If you want to help, here's a list of the relevant bugs: https://bugs.debian.org/release-critical/other/testing.html -- 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/54c970c3.10...@bitmessage.ch
Re: Bug#777220: ITP: you-get -- downloader for youtube and number of sites
On 07/02/15 18:36, Paul Wise wrote: > On Fri, Feb 6, 2015 at 9:50 PM, Thorsten Glaser wrote: > >> I smell the chance to share… > > It would be nice if someone could contact all of the Python ones and > ask them to merge their code. Same for all of the Perl ones and all of > the other ones. Even more interesting would be a standard for video > downloader plugins so that video players like Totem and VLC could just > play videos on these sites. De-duplicate all the things! Still, until this happens, there's no reason why Debian shouldn't include you-get. -- 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/54d5e573.1070...@bitmessage.ch
Should we mark #388141 as jessie-ignore?
Hi, Bug #388141 [RC] refers to the relicensing of the debian www pages. After contacting debian-www, it seems that there isn't much interest in fixing it. The next step would involve compiling a list of website lines which are still active yet which relicensing permission has not been received. In any case, even if there is interest in closing this bug, it is definitely more of a long-term thing and is unlikely to be fixed before the jessie release. Because of this, would it be okay to mark it as "jessie-ignore"? Thanks, Riley Baird -- 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/20150213065944.be67bd6d5c9d151ef8264...@bitmessage.ch
Re: Should we mark #388141 as jessie-ignore?
On Fri, 13 Feb 2015 08:40:53 + "Adam D. Barratt" wrote: > On 2015-02-12 19:59, Riley Baird wrote: > > In any case, even if there is interest in closing this bug, it is > > definitely more of a long-term thing and is unlikely to be fixed before > > the jessie release. Because of this, would it be okay to mark it as > > "jessie-ignore"? > > For reference, as per https://www.debian.org/Bugs/Developer#tags , > setting -ignore tags is the purview of the Release Team, not maintainers > or debian-devel. Feel free to suggest such things, but please don't add > or remove any -ignore tags. I won't. Thanks for letting me know. -- 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/20150214070436.759e1add961d8bbd3ea14...@bitmessage.ch
Re: Should we mark #388141 as jessie-ignore?
On Thu, 12 Feb 2015 14:47:53 -0800 Don Armstrong wrote: > On Fri, 13 Feb 2015, Riley Baird wrote: > > In any case, even if there is interest in closing this bug, it is > > definitely more of a long-term thing and is unlikely to be fixed before > > the jessie release. Because of this, would it be okay to mark it as > > "jessie-ignore"? > > There's no point in marking bugs in psuedo packages jessie-ignore; > they're ignored for the purpose of releasing jessie anyway. Ah, I didn't know that. -- 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/20150214070548.770a5313f62ed50c2caa5...@bitmessage.ch
Re: Should we mark #388141 as jessie-ignore?
On Thu, 12 Feb 2015 21:16:39 +0100 Tomas Pospisek wrote: > Am 12.02.2015 um 20:59 schrieb Riley Baird: > > > Bug #388141 [RC] refers to the relicensing of the debian www pages. > > After contacting debian-www, it seems that there isn't much interest in > > fixing it. > > I interpret the relative silence in #388141 differently then you. I'd > say that everybody is busy with doing other stuff. So if you want the > state of affairs to change, just go after it, bit by bit. As you > describe here: > > > The next step would involve compiling a list of website > > lines which are still active yet which relicensing permission has not > > been received. > > And then just ask for permission, line by line. Surprisingly not! Everyone who has been contacted has already been contacted. The reason for collecting these lines is that we need to determine whether the lines in question are copyrightable, and whether they are still in use. > In the end I think it's work and if it should be accomplished then > someone has to do that work. Since you are interested, just go and hit > the work, it may well be that people will join or help you along the way. I've always been happy to do the work, but I thought that access to the wiki databases was necessary to compile such a list. Or is it possible to compile such a list with just a user account on the wiki? -- 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/20150214071524.fd5a9f473b50c52df74f6...@bitmessage.ch
Re: how to remove libsystemd0 from a live-running debian desktop system
> > But dictatorially coming in and demanding that volunteers join you in > > riding your hobby horse? Please leave. > > I did not see any dictatorial demands in his message, he gave the story > on how to get rid of systemd _within_ Debian, nothing else. True, but it was bait for another systemd debate, which unfortunately seems to have succeeded. (There would be nothing wrong with posting such a guide normally, but generally guides shouldn't be mixed with several paragraphs of politics.) pgpyT6S5E1KB8.pgp Description: PGP signature
Re: Should we mark #388141 as jessie-ignore?
On Mon, 16 Feb 2015 18:30:44 +0100 Tomas Pospisek wrote: > Am 13.02.2015 um 21:15 schrieb Riley Baird: > > On Thu, 12 Feb 2015 21:16:39 +0100 > > Tomas Pospisek wrote: > >> Am 12.02.2015 um 20:59 schrieb Riley Baird: > >> > >>> Bug #388141 [RC] refers to the relicensing of the debian www pages. > >>> After contacting debian-www, it seems that there isn't much interest in > >>> fixing it. > >> > >> I interpret the relative silence in #388141 differently then you. I'd > >> say that everybody is busy with doing other stuff. So if you want the > >> state of affairs to change, just go after it, bit by bit. As you > >> describe here: > >> > >>> The next step would involve compiling a list of website > >>> lines which are still active yet which relicensing permission has not > >>> been received. > >> > >> And then just ask for permission, line by line. > > > > Surprisingly not! Everyone who has been contacted has already been > > contacted. The reason for collecting these lines is that we need to > > determine whether the lines in question are copyrightable, and whether they > > are still in use. > > > >> In the end I think it's work and if it should be accomplished then > >> someone has to do that work. Since you are interested, just go and hit > >> the work, it may well be that people will join or help you along the way. > > > > I've always been happy to do the work, but I thought that access to the > > wiki databases was necessary to compile such a list. Or is it possible to > > compile such a list with just a user account on the wiki? > > I'm not sure I really understand what you want to do. > > Is something like this: > > https://wiki.debian.org/LXC?action=info > > not what you need? Kind of, but it's only for that one article. Is there something similar that lists all edits to the wiki itself like that? If not, I could make one by downloading the revision histories for all pages on the wiki and then parsing them, but this might place strain on the server (and would be much more difficult). pgpUlZQPEt4Z5.pgp Description: PGP signature
Re: Should we mark #388141 as jessie-ignore?
On Wed, 18 Feb 2015 08:19:34 +0800 Paul Wise wrote: > On Tue, Feb 17, 2015 at 6:12 PM, Riley Baird wrote: > > > Kind of, but it's only for that one article. Is there something similar > > that lists all edits to the wiki itself like that? If not, I could make > > one by downloading the revision histories for all pages on the wiki and > > then parsing them, but this might place strain on the server (and would > > be much more difficult). > > Isn't #388141 solely about the website? > > There is #385797 about the wiki content. Good point. I really should have noticed that. In any case, as ridiculous as it sounds, I've been trying to get CVS to show me the offending commits over the last couple of days, and I haven't worked out how to do it. So, I think that I'll leave this bug (at least for now), and go work on some other Debian-related activity. Thanks for your help everyone. pgpW5PigcIgKN.pgp Description: PGP signature
Re: manual in sgml
> the manual of my package is written in SGML language. > I guess that it may be translate into a more readable format: > What is the best Debian way to convert it in HTML and/or PDF (via LaTeX) ? I recently had to deal with this problem myself, when packaging the documentation for granule. If there are Makefiles distributed with the SGML, it might be easier, but otherwise, you can just use the relevant commands. Firstly, you should install the docbook-utils package. Then, for html, you can use the command "db2html -i online path/to/file.sgml" As for PDF and PS formats, I'm not sure. You might be able to use other tools in the docbook-utils package, though. pgpUHUbJH0o6u.pgp Description: PGP signature
Re: Minified javascripts in packages
On Fri, 10 Apr 2015 17:44:06 +0200 m...@linux.it (Marco d'Itri) wrote: > On Apr 10, Thomas Goirand wrote: > > > To put it simply: no, you should build everything from source, and not > > using pre-compiled code (yes, minified scripts can be (and actually are) > > considered as pre-compiled code...). > You should, but this is not mandatory. > What is mandatory is being able to rebuild everything from source with > tools available in Debian (main), but in some cases there are valid > reasons to not do it every time the package is being built. An example that comes to mind is the firmware-linux-free package. It would be impractical to rebuild so many toolchains just to make the package. pgptFHh6fmIfm.pgp Description: PGP signature
Re: Minified javascripts in packages
On Tue, 14 Apr 2015 08:40:07 +0200 Vincent Bernat wrote: > ❦ 14 avril 2015 11:00 +1000, Ben Finney : > > >> > I presume that we can agree that, if someone started offering a web > >> > service compiling C code with output an order of magnitude better in > >> > every dimension than gcc can achieve, we still wouldn't use it for > >> > our binaries (at least not unless it were available as free software > >> > that we could host ourselves). What makes JavaScript worthy of > >> > special treatment? > >> > >> It is an interpreted language and "compiled" source can sometimes be > >> considered as a pristine source too (for example, concatenation). > > > > No, a concatenated bundle – the compiled form – is not the preferred > > form for making modifications to the work. So it's not the source > > form. > > Sorry, that's not always true. The concatenated form may not be the > preferred form for making modifications for the upstream author but for > a user, this may be perfectly valid. The prefered form of modification > of the derivative may become the concatenated form. Or the selected > form. License-wise, those derivatives are still perfectly valid since > usually, all this is MIT-licensed. > > If you take bootstrap for example, the upstream preferred form for > making modifications is here: > https://github.com/twbs/bootstrap/tree/master/less > > But many people just starts of the generated bootstrap.css (which is > generated and concatenated but not minified) because it is perfectly > valid and understandable CSS. And they do modification to that when they > want to modify a small aspect. They don't bother starting from the whole > LESS files (especially if the remaining of their project is not using > LESS). They may also remove parts they don't use for optimization > purpose. That's very hard to rebuild what they got from the original > LESS files. It makes sense that for small changes, the preferred form for modification would be the generated bootstrap.css. A potential problem with this would be that you can generate bootstrap.css from the LESS files, but (I assume) you can't generate the LESS files from the bootstrap.css. Perhaps more importantly, CSS is easily understandable, whereas minified javascript is not. Debugging minified javascript is almost impossible. pgp2_cTpOT8wy.pgp Description: PGP signature
Re: Minified javascripts in packages
On Tue, 14 Apr 2015 18:42:00 +0200 Vincent Bernat wrote: > ❦ 14 avril 2015 18:22 +1000, Riley Baird > : > > > It makes sense that for small changes, the preferred form for > > modification would be the generated bootstrap.css. A potential problem > > with this would be that you can generate bootstrap.css from the LESS > > files, but (I assume) you can't generate the LESS files from the > > bootstrap.css. > > > > Perhaps more importantly, CSS is easily understandable, whereas > > minified javascript is not. Debugging minified javascript is almost > > impossible. > > JS doesn't have to minified. Like the example above, the code can be > concatenated and edited. jQuery non-minified is distributed as a single > JS file while the original source is composed of many files. Concatenated javascript sounds much more reasonable. I think that you could call this source code. pgpp9LQcVJWe4.pgp Description: PGP signature
Re: Minified javascripts in packages
> What I have done so far in my package is to include the concatenated > but unminified js from the upstream (that would be my upstream's > upstream) source tarball in debian/missing-sources. During package > build i use uglifyjs (which is already in Debian) to place minified > copies where the app I'm building expects them to be. > As mentioned above, what constitutes preferred form of modification > really is a question of who is doing the modification. Upstream uses > the un-concatenated files, but personally, I would find it easier to > modify one big file, at least for something interpreted like > javascript. While I still maintain my previous position that concatenated js is DFSG-free, even if it is not what upstream requires, I'm just wondering - what is your .orig.tar.gz? You might not need to repack it if you can concatenate the files with a debhelper override in d/rules. And you're still distributing source the way upstream wants it, so everyone's happy. pgpkYxqGKZX6X.pgp Description: PGP signature
Re: Minified javascripts in packages
On Wed, 15 Apr 2015 16:55:56 +0100
Ian Jackson wrote:
> Vincent Bernat writes ("Re: Minified javascripts in packages"):
> >13 avril 2015 17:37 +1000, Ben Finney :
> >> Is the implication of “built by web services” that the source isn't
> >> available for redistribution? Those would be excluded from Debian
> >> trivially by that criterion, then.
> >
> >Usually, this is something like this:
> > http://modernizr.com/download/#-fontface-backgroundsize-borderimage-borderradius-boxshadow-flexbox-hsla-multiplebgs-opacity-rgba-textshadow-cssanimations-csscolumns-generatedcontent-cssgradients-cssreflections-csstransforms-csstransforms3d-csstransitions-applicationcache-canvas-canvastext-draganddrop-hashchange-history-audio-video-indexeddb-input-inputtypes-localstorage-postmessage-sessionstorage-websockets-websqldatabase-webworkers-geolocation-inlinesvg-smil-svg-svgclippaths-touch-webgl-shiv-cssclasses-addtest-prefixed-teststyles-testprop-testallprops-hasevent-prefixes-domprefixes-load
>
> The preferred form for modification of the result is the web site plus
> that url, isn't it, then ?
What if that website goes down one day?
pgpT3rEe8vhCS.pgp
Description: PGP signature
Re: Ghostscript licensing changed to AGPL
> Yes. But this isn't as bad as you think, because the source > availability requirement exists only if you modify the AGPL'd > software. I don't think that this is the case. Firstly, because it leaves a practical loophole in the AGPL: -Person A takes some software under the AGPL. -Person A privately gives the new software to Person B under the AGPL. -Person B publishes the new program without source, because they haven't modified it Considering the legal aspects, the rule for verbatim copies only applies to distribution in source form. The 5 options for distributing object form all require offering source in some way. -- 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/536aa4ec.8000...@bitmessage.ch
Re: Ghostscript licensing changed to AGPL
> So please excuse my ignorance here: But how does that work? How can we, > as Debian, ensure that a user automatically complies with the license > when a package is installed and spawns up a service on a port? (Or > similarly, installs itself into a web server found on the system.) I don't think that, technically, Debian has any requirement to do so. However, I would definitely be less comfortable using Debian if I could end up inadvertently violating a license just by starting a web server. > Should it then communicate that it is Debian version X and that the > source can be found on any Debian mirror near you? What if the network in question is not the internet? -- 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/536b4f7c.8080...@bitmessage.ch
Re: Ghostscript licensing changed to AGPL
>> So if Debian provides, say, a web frontend to Ghostscript, then with >> AGPL Ghostscript running that web frontend as a service for others >> only require an interface serving its sources if the _webmaster_ >> changes the code for that frontend? >> >> Not if Debian makes changes to both the frontend and AGPL >> Ghostscript? >> >> That seems like a loophole to me: If Google wants an advantage by >> running better-than-ghostscript.google.com PDF convertor, they can >> simply let another company/organisation/person be the "Debian" in >> their chain and not need to reveal their patches to their users. > > You missed the hidden §18 (“No Loopholes Allowed”): > https://lists.debian.org/20130711174500.ga22...@redhat.com I don't think that we can simply say "No Loopholes Allowed". Otherwise, we could say the same of practically *any* license. As far as I can tell, nowhere in the AGPL (or the GPL for that matter), does it say that you only have to offer the code if you haven't modified it. You must offer the code if you distribute it (modified or unmodified) - that way, you're guaranteeing that all users are able to modify the program should they wish to. -- 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/536bf0f9.7080...@bitmessage.ch
Re: git and https
On Fri, 29 May 2015 13:55:31 +0800 Paul Wise wrote: > On Fri, May 29, 2015 at 7:40 AM, Russ Allbery wrote: > > > I'm fine with locking the doors. I'm not fine with paying protection > > money to a Mafia goon who claims they'll lock your windows, and sort of > > sometimes does. It's the extortion component that pisses me off about > > HTTPS. > > LetsEncrypt will save us! I just looked that up. What a wonderful idea! > > If we can use a Debian-specific CA, we can do cert pinning, since we're > > then assuming we have some control over the client. I was assuming a > > general client where we'd have to play nice with the normal CA roots. > > Then we would constantly get complaints from Ubuntu/etc > developers/users about why Debian uses invalid certs, as we did before > Debian moved to mafia certs. Unfortunately I don't think it is > possible to use both mafia CAs and non-mafia CAs without adding say a > lot of non-mafia subdomains, like non-mafia.www.debian.org. If having to manually add a CA annoys the Ubuntu developers that much, then surely they could just include the Debian CA certificate to Ubuntu's default? Anyway, I don't see the point in using both mafia CAs and non-mafia CAs. If you get the mafia CAs, you'll still be paying the extortion money regardless of whether or not you use the non-mafia CAs. pgpA630kssrel.pgp Description: PGP signature
Re: git and https
> > > > If we can use a Debian-specific CA, we can do cert pinning, since we're > > > > then assuming we have some control over the client. I was assuming a > > > > general client where we'd have to play nice with the normal CA roots. > > > > Then we would constantly get complaints from Ubuntu/etc > > > developers/users about why Debian uses invalid certs, as we did before > > > Debian moved to mafia certs. Unfortunately I don't think it is > > > possible to use both mafia CAs and non-mafia CAs without adding say a > > > lot of non-mafia subdomains, like non-mafia.www.debian.org. > > > If having to manually add a CA annoys the Ubuntu developers that > > much, then surely they could just include the Debian CA certificate to > > Ubuntu's default? > > It is my understanding that no, Ubuntu could not, because Ubuntu ships > firefox; and one of the things that's disallowed by Mozilla when using the > firefox trademark is extending the set of trusted CAs (for actually rather > good reason). I just looked at the Ubuntu ca-certificates package in vivid, and it ships the SPI certificate: /usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt Does Firefox in Ubuntu use this certificate, or does it only accept certificates in /usr/share/ca-certificates/mozilla? pgpk4tADfXSCP.pgp Description: PGP signature
Re: git and https
> > > > > > If we can use a Debian-specific CA, we can do cert pinning, since > > > > > > we're > > > > > > then assuming we have some control over the client. I was assuming > > > > > > a > > > > > > general client where we'd have to play nice with the normal CA > > > > > > roots. > > > > > > Then we would constantly get complaints from Ubuntu/etc > > > > > developers/users about why Debian uses invalid certs, as we did before > > > > > Debian moved to mafia certs. Unfortunately I don't think it is > > > > > possible to use both mafia CAs and non-mafia CAs without adding say a > > > > > lot of non-mafia subdomains, like non-mafia.www.debian.org. > > > > > If having to manually add a CA annoys the Ubuntu developers that > > > > much, then surely they could just include the Debian CA certificate to > > > > Ubuntu's default? > > > > It is my understanding that no, Ubuntu could not, because Ubuntu ships > > > firefox; and one of the things that's disallowed by Mozilla when using the > > > firefox trademark is extending the set of trusted CAs (for actually rather > > > good reason). > > > I just looked at the Ubuntu ca-certificates package in vivid, and it > > ships the SPI certificate: > > /usr/share/ca-certificates/spi-inc.org/spi-cacert-2008.crt > > Yes, because that's the ca-certificates package from Debian. But the > firefox package does not trust those certificates. > > > Does Firefox in Ubuntu use this certificate, or does it only accept > > certificates in /usr/share/ca-certificates/mozilla? > > Firefox doesn't use any certificates from the ca-certificates package. It > uses the CAs that are bundled in the upstream source. Ah, okay. Thanks for letting me know. pgpedegzUm3jf.pgp Description: PGP signature
Bug#789432: ITP: coq-highschoolgeometry -- coq library for high school geometry proofs/formalisation
Package: wnpp Severity: wishlist Owner: Riley Baird * Package name: coq-highschoolgeometry Version : 8.4+20150620 Upstream Author : Frédérique Guilhot * URL : http://www.lix.polytechnique.fr/coq/pylons/coq/pylons/contribs/view/HighSchoolGeometry/trunk * License : LGPL-2.1+ Programming Lang: Coq Description : coq library for high school geometry proofs/formalisation Created by Frédérique Guilhot, this library consists of a collection of "chapters" spanning most of the geometry taught in French high schools. The first part "2-3 dimensional affine geometry" deals with formalising: points, vectors, barycenters, oriented lengths collinearity, coplanarity parallelism and incidence of straight lines proofs of Thales and Desargues theorems. In the second part "3 dimensional affine geometry", we prove theorems about: relative positions of two straight lines in the space relative positions of a straight line and a plane relative positions of two planes parallelism and incidence properties for several planes and straight lines The third part "2-3 dimensional euclidean geometry" deals with formalising: scalar product, orthogonal vectors, and unitary vectors Euclidean distance and orthogonal projection on a line proofs of Pythagorean theorem, median theorem The fourth part "space orthogonality" deals with formalising: orthogonal line and plan The fifth part "plane euclidean geometry" deals with formalising: affine coordinate system, orthogonal coordinate system, affine coordinates oriented angles trigonometry proofs of Pythagorean theorem, median theorem, Al-Kashi and sine theorems perpendicular bisector, isocel triangle, orthocenter circle, cocyclicity, tangency (line or circle tangent) signed area, determinant equations for straight lines and circles in plane geometry The sixth part "plane transformations", deals with formalising: translations, homothety rotations, reflexions composition of these transformations. conservation of tangency for these transformations. In the seventh part "applications", we prove: Miquel's theorem, orthocenter theorem, Simson line circle power and plane inversion Euler line theorem and nine point circle theorem The eighth part "complex numbers", deals with formalising: the field properties of complex numbers application to geometry of complex numbers This package is a dependency of geoproof. -- 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/20150620232033.6879.50974.reportbug@debian.fleetstreet
Re: The Spirit of Free Software, or The Reality
> In the same way, I'm pretty sure is perfectly possible to make money > developing free software. You just don't charge for selling copies or > licenses, but instead you charge for developing new custom features or > offering support and consultancy around the software. True, but you would make much less money than if you charged individual users. If you only worked on a small software project, you would make nothing at all. pgpTrPwsK_LCk.pgp Description: PGP signature
Re: The Spirit of Free Software, or The Reality
> > FWIW, those [requests to search engines to retrieve their icons] are a > > consequence of removing supposedly non-free icons from the source > > package. But maybe you'd prefer no icons at all for the list of search > > engines. > > That's a tough one. I haven't yet got a firm position on what should be > done to resolve that. A possible solution would be to make new icons. The problem with this would be that they wouldn't be easily identifiable, which is the whole point of icons.,, pgpRwHWXpegEy.pgp Description: PGP signature
Re: The Spirit of Free Software, or The Reality
On Thu, 16 Jul 2015 22:20:35 +0200 "IOhannes m zmölnig (Debian/GNU)" wrote: > On 07/16/2015 08:29 PM, Don Armstrong wrote: > > On Thu, 16 Jul 2015, Simon Richter wrote: > >> > The problem is that the icons are displayed in the search field > >> > dropdown, which should be fully functional before visiting the first > >> > site. > > I was hoping that it could be semi-functional, with placeholder icons > > until the site in question is actually visited. But if the icons are > > necessary, then they're necessary. > > > > what is the "site in question" you are referring to? > > as in: the first time the user starts the browser, the search field will > be filled with empty (placeholder) icons. whenever they enter a search > term and select one of the unknown¹ search engines, the search is > performed (e.g. on wikipedia) and the placeholder icon is updated with > the real icon (since wikipedia was visited anyhow), and from know on the > user knows at least one of their search engines. > this feels a bit like > > Quaff the blue speckled potion. > > You have no more potions of blindness. What if the placeholder icons were the first letter of the search engine's name? pgpttdEVSZsSQ.pgp Description: PGP signature
Re: Feature Debian in MeetAdvisors Blog!
Hi Angela, > I am writing a blog at MeetAdvisors.com on companies that are driving > their industries forward, I would love to include you! > > I'll be looking for why you do what you, what your passion is, and to > gather a piece of advice you'd like to share with our community. Have you got a response yet? If not, you might want to try sending this message to our publicity department. Its email address is pr...@debian.org Thanks for taking an interest in Debian, Riley Baird pgpr66zRgMome.pgp Description: PGP signature
Re: Mass bug filing about non free lena image.
On Sat, 15 Aug 2015 14:10:21 +0100 Matthew Woodcraft wrote: > Phil Hands wrote: > > I saw that at least one package (I'm afraid I've forgotten which) > > settled on this picture of Grace Hooper: > > > > > https://upload.wikimedia.org/wikipedia/commons/a/ad/Commodore_Grace_M._Hopper%2C_USN_%28covered%29.jpg > > > It is Public Domain (having been released by the US Navy). Only in the US. The US Government retains copyright overseas. pgpThdqf3IoYd.pgp Description: PGP signature
Re: Bug#796467: general: if user has mail then how do we tell them if in GUI mode?
On Fri, 21 Aug 2015 17:20:17 -0500 Richard Jasmin wrote: > Package: general > Severity: important > > telling user has mail is easy as pi in console mode and when using a server. > But how do we tell the user they have mail without a configured mail client > when under runlevel 5? The activation of X11 practically hides all console > activity. > > We would need a UI tool to do this. We cannot assume use of neither gnome nor > KDE. User may have MATE or other UI installed.We should make an app > indicator(and mail viewer) as lite as possible. > > Also, when launching xterm or similar, user is never told if they have mail or > not.This should be a more eay fix.Since xterm emulates a vterm/getty checking > mail this way should never fail. Have you tried xfce4-mailwatch-plugin? pgpiJzGW0Udv_.pgp Description: PGP signature
Re: Security concerns with minified javascript code
> For years, we have been able to ship generated files without checking if > they can really be built from sources (for example, autoconf stuff). And > JS stuff should comply to stricter standards from day one? JS stuff has been in Debian for a long time; it isn't fair to say that this is day one. And autoconf isn't really a fair comparison, because you can generally read the output files of autoconf, whereas minified JS is just impossible. pgpx8G0_fmk2j.pgp Description: PGP signature
Re: Security concerns with minified javascript code
> Sure, you can proofread a 30k-line configure script without a > problem. So, the condition is now "must be generated from source only if > the generated from is hard-but-not-impossible to read". Several times over the last year I have modified the output form of autoconf directly when doing minor modifications, such as including or excluding a file. For that reason, I don't see much of a problem with automatically generated CSS being included in Debian. However, point taken - the output of autoconf is too hard to proofread, especially when it can be generated from source. > I would also like to stress that all this stuff is DFSG-compliant. Doesn't the DFSG require source code, as well as a free license? pgpulTRCVOf9t.pgp Description: PGP signature
Re: GNU IceCat?
> Is there any reason (other than lack of manpower) that GNU IceCat is not > packaged in Debian? > > I understand Debian has IceWeasel to (primarily?) fix the Firefox > trademark issue and to have a mechanism to deal with security backports. > > IceCat has diverged from Firefox/Iceweasel and has a different feature > set than both, so it would seem reasonable to have it available through > Debian. Would it really be worth it? There aren't that many changes: http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat Debian already has xul-ext-adblock-plus and xul-ext-https-everywhere, but we don't have librejs yet. pgp0Xm0yHXYqw.pgp Description: PGP signature
Re: GNU IceCat?
On Tue, 08 Sep 2015 08:58:46 +0200 Simon Josefsson wrote: > Riley Baird writes: > > >> Is there any reason (other than lack of manpower) that GNU IceCat is not > >> packaged in Debian? > >> > >> I understand Debian has IceWeasel to (primarily?) fix the Firefox > >> trademark issue and to have a mechanism to deal with security backports. > >> > >> IceCat has diverged from Firefox/Iceweasel and has a different feature > >> set than both, so it would seem reasonable to have it available through > >> Debian. > > > > Would it really be worth it? There aren't that many changes: > > http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat > > The entire tree contains a number of other things: > http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/ > > For example some privacy/security default settings: > http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/settings.js Ah, that's a good set of default settings. Perhaps a modified settings.js and an explanation of how to use it could be included with the iceweasel package? Also, what advantages does IceCat have over the Tor Browser? (Debian doesn't have the Tor Browser either, due to the impossibility of long term maintenance, but just wondering.) pgpSsPIG4v55O.pgp Description: PGP signature
Re: GNU IceCat?
On Tue, 08 Sep 2015 09:30:46 +0200 Simon Josefsson wrote: > Riley Baird > writes: > > > On Tue, 08 Sep 2015 08:58:46 +0200 > > Simon Josefsson wrote: > > > >> Riley Baird writes: > >> > >> >> Is there any reason (other than lack of manpower) that GNU IceCat is not > >> >> packaged in Debian? > >> >> > >> >> I understand Debian has IceWeasel to (primarily?) fix the Firefox > >> >> trademark issue and to have a mechanism to deal with security backports. > >> >> > >> >> IceCat has diverged from Firefox/Iceweasel and has a different feature > >> >> set than both, so it would seem reasonable to have it available through > >> >> Debian. > >> > > >> > Would it really be worth it? There aren't that many changes: > >> > http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat > >> > >> The entire tree contains a number of other things: > >> http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/ > >> > >> For example some privacy/security default settings: > >> http://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/settings.js > > > > Ah, that's a good set of default settings. Perhaps a modified > > settings.js and an explanation of how to use it could be included with > > the iceweasel package? > > That's up to the IceWeasel team -- my perception is that they want to > keep changes compared to Firefox to a minimum. Good point. > > Also, what advantages does IceCat have over the Tor Browser? (Debian > > doesn't have the Tor Browser either, due to the impossibility of long > > term maintenance, but just wondering.) > > I'm not familiar enough with how the Tor Browser is different to really > tell. It seems based on ESR, so long term maintenance may be possible? Maybe. I'm content with the upstream tarball of the Tor Browser (once you've installed it, it enables autoupdating), so I'm not willing to volunteer. pgp_db2ZzhF9b.pgp Description: PGP signature
Re: GNU IceCat?
> > Also, what advantages does IceCat have over the Tor Browser? (Debian > > doesn't have the Tor Browser either, due to the impossibility of long > > term maintenance, but just wondering.) > > Have a look at torbrowser-launcher in synaptic Ah, didn't realise that! pgpqsKNlZs_cp.pgp Description: PGP signature
Re: Request for documentation about creation of Debian Language Packs
On Mon, 5 Oct 2015 12:46:11 -0500 Zeus Hughes wrote: > Hello, > > I would like to request some documentation be provided to the public forums > or just myself appertaining the process of how a person can create a unique > language pack for Debian. I can't find any documentation on how to do this, but if you download the source package openoffice.org-dictionaries, you should be able to get an idea of how it's done. pgpj6dE66Rx8z.pgp Description: PGP signature
Re: IceCat package request
> Could somebody add/cerate a IceCat package? > https://www.gnu.org/software/gnuzilla/ This has been discussed about two months ago. You can read the discussions here: https://lists.debian.org/debian-devel/2015/09/msg00184.html To *greatly* simplify what was said: -Packaging icecat is difficult -Icecat is only trivially different from iceweasel -Nobody can be bothered packaging it for these reasons pgpAmNnFL4naM.pgp Description: PGP signature
Bug#808373: ITP: libwaive -- Allow processes to waive their rights
Package: wnpp Severity: wishlist Owner: Riley Baird * Package name: libwaive Version : 1.0.0+git20151218.a0e8c1 Upstream Author : Dima Krasner * URL : https://github.com/dimkr/libwaive * License : MIT Programming Lang: C Description : Allow processes to waive their rights libwaive is a tiny library that provides waive(), a function that allows a process to waive its right to perform certain actions (e.g. open a file). It is inspired by Theo de Raadt's tame() system call (http://article.gmane.org/gmane.os.openbsd.tech/43085)
Re: Help me please... I need help immediately becouse I can't open my pc and I need to use it for work
On Sat, 9 Jan 2016 22:07:15 +0100 Patrik Liçi wrote: > Hi debian I have a big problem and I need help immediately. ... I was > installing kali linux mini 2.0 in my pc then I power off the pc becouse > the downloads wants a lot to finish when I want to open my pc it > cant .the monitor stays black I tried to install kali linux again > eand when the installation finish the montior stays again black. I need > to use my pc for my work but it dont open... please help.. is there any way > to format my pc... becouse I put my windows 7 cd to format my pc but > nothing happened. ... the only thing that can be opened is kali linux > cd help pls Firstly: Can you do your work from within the Kali Linux CD? That could be a temporary solution. Secondly: The fact that you only get a black screen means that you haven't got to the bootloader. You can install the GRUB bootloader from Kali. From a terminal: 1. Install the required programs $ sudo apt-get install fdisk grub-install 2. After removing all external media (e.g. USBs) from your computer - except for the Kali Linux CD - run the following command: $ sudo fdisk -l | grep Disk You should see something like /dev/sda or /dev/hda. This is the name of your storage device. 3. Install GRUB to your storage device. If your storage device was /dev/sda, then you should run the command: $ sudo grub-install /dev/sda 4. Copy any output and save it to paste.debian.net. Write down the URL on a piece of paper. 5. Reboot your computer. $ sudo reboot 6. Write back to us, send us the link to paste.debian.net and tell us whether or not it worked. If it works, tell us exactly what you did so that other people reading this with the same problem will know. If it doesn't work, tell us what you can see and what you're trying to do. pgpDkHyfbLEYc.pgp Description: PGP signature
Re: 50.000 binary packages
On Mon, 8 Feb 2016 11:25:00 +0100 Enrico Zini wrote: > On Mon, Feb 08, 2016 at 12:01:41PM +0200, Lars Wirzenius wrote: > > > Possibly someone should set up an online quiz thing, where you're > > shown a package name, its short description, and three randomly chosen > > short descriptions, and have to guess which short description is > > correct. > > plee-the-bear > 2D platform game > program for gridfitting, or "hinting," TrueType fonts > free AdLib sound library (utils) > > (script attached) I've modified the script so that it is interactive. pkgquiz Description: Binary data
Re: Can "PDB" license be considered free ?
> The distribution of modified PDB data including the records HEADER, CAVEAT, > REVDAT, SPRSDE, DBREF, SEQADV, and MODRES in PDB format and their mmCIF and > XML equivalents is not allowed. I'm not sure what the PDB format is, so I might be wrong, but my intuition is that trying to stop people from distributing data in a certain file format would be non-free. pgpqoqpl4y3Gv.pgp Description: PGP signature
