Re: Suggestion
On Fri, 31 May 2024 18:35:53 +, nino He?i wrote: >My suggestion is regarding locales. Currently we get to chose locale based >on choices of language and keyboard layout and here in lies the problem. >Rather than offer locales based on our selections don't,just list all of >them in installer and let us users chose which one we want. The "expert" install offers just this and it can be preseeded accordingly. My routine choice is en_US.UTF-8, en_GB.UTF-8¹ and de_DE.UTF-8 with en_US being the default. |[2/5131]mh@swivel:~ $ < /etc/locale.gen grep -vE '^(#.*|)$' |de_DE.UTF-8 UTF-8 |en_GB.UTF-8 UTF-8 |en_US.UTF-8 UTF-8 |[3/5132]mh@swivel:~ $ locale |LANG=de_DE.UTF-8 |LANGUAGE=en |LC_CTYPE="de_DE.UTF-8" |LC_NUMERIC=de_DE.UTF-8 |LC_TIME=de_DE.UTF-8 |LC_COLLATE="de_DE.UTF-8" |LC_MONETARY=de_DE.UTF-8 |LC_MESSAGES=en_US.UTF-8 |LC_PAPER=de_DE.UTF-8 |LC_NAME=de_DE.UTF-8 |LC_ADDRESS=de_DE.UTF-8 |LC_TELEPHONE=de_DE.UTF-8 |LC_MEASUREMENT=de_DE.UTF-8 |LC_IDENTIFICATION="de_DE.UTF-8" |LC_ALL= |[4/5132]mh@swivel:~ $ Greetings Marc ¹ some software comes with its English translation in en_GB and if that's not present it falls back to the ugly de_DE translation -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Suggestion
On Fri, May 31, 2024 at 06:35:53PM +, nino Heđi wrote: > My suggestion is regarding locales. Currently we get to chose locale based > on choices of language and keyboard layout and here in lies the problem. > Rather than offer locales based on our selections don't,just list all of > them in installer and let us users chose which one we want. For most purposes in a single language, a keyboard, language and timezone can all be set in one locale. If you need to switch between multiple languages, you are the exceptional case. > For me english language and croatian layout blocks me from chosing > croatian locale during installation so i have to do it after installation > is complete and I do not like it and i think i am not the only one. Set Croatian locale up during installation - hr_HR.UTF-8 UTF-8 - and add a locale with an appropriate English keyboard layout in addition - maybe en_US.UTF-8 UTF-8 At any point you can run dpkg-reconfigure locales as root/sudo to generate extra locales as necessary Then set up your locales file accordingly. You should be able to switch straightforwardly between keyboard layouts in a graphical desktop environment / use a soft keyboard with no problem in any event. > I am going to switch to linux soon with Debian being my daily driver and all > the servers I decide run will also be on top of debian. So make small > change in installer for debian and turn off locales based on match between > language of a system and keyboard layout because it is problematic for > someone who doesn't use US layout on keyboard and i am among those since i > am croatian. > -- There's always more than one way to solve a problem appropriately in Debian - I'm sure others can think of other solutions. With every good wish, as ever, Andrew Cater (amaca...@debian.org) > Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com >
Suggestion
My suggestion is regarding locales. Currently we get to chose locale based on choices of language and keyboard layout and here in lies the problem. Rather than offer locales based on our selections don't,just list all of them in installer and let us users chose which one we want. For me english language and croatian layout blocks me from chosing croatian locale during installation so i have to do it after installation is complete and i do not like it and i think i am not the only one. I am going to switch to linux soon with Debian being my daily driver and all the servers i decide run will also be on top of debian. So make small change in installer for debian and turn off locales based on match between language of a system and keyboard layout because it is problematic for someone who doesn't use US layout on keyboard and i am among those since i am croatian. -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
ITP: golang-github-sajari-fuzzy -- Spell checking and fuzzy search suggestion written in Go
Package: wnpp Severity: wishlist Owner: Mark E. Fuller * Package name: golang-github-sajari-fuzzy Version : 1.0.0-1 Upstream Author : Search.io * URL : https://github.com/sajari/fuzzy * License : MIT Programming Lang: Go Description : Spell checking and fuzzy search suggestion written in Go Fuzzy is a very fast spell checker and query suggester written in Golang. Reason for packaging: Needed by go-task OpenPGP_0xD599E76CFFCABF60.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: a two cent suggestion
On 1.12.2022 12:16, Paul Wise wrote: On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote: Any (or a specific group of) users could be able to install any package of the first class by their own without asking a sysadmin (or explicitly acquiring privilege of) user. The general idea of a safe way to allow users to manage system-wide apt packages has come up before, here is another writeup about it: https://wiki.debian.org/UntrustedDebs The goal of allowing all users to manage installed software seems like something better served by app sandboxing technologies like Flatpak. It is probably possible to convert .deb packages to Flatpak packages. I think AppImages are great (from my perspective) for allowing people to run whatever they want on their systems, without getting root privileges and having a sandboxed, hermetically sealed application with batteries included. The nicer thing is, they have a tool to convert .deb packages to AppImages [0], and moreover, the tool doesn't need root permissions to run. The tool even includes recipes for popular packages, too. [0]: https://github.com/AppImageCommunity/pkg2appimage OpenPGP_signature Description: OpenPGP digital signature
Re: a two cent suggestion
On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote: > Any (or a specific group of) users could be able to install any > package of the first class by their own without asking a sysadmin (or > explicitly acquiring privilege of) user. The general idea of a safe way to allow users to manage system-wide apt packages has come up before, here is another writeup about it: https://wiki.debian.org/UntrustedDebs The goal of allowing all users to manage installed software seems like something better served by app sandboxing technologies like Flatpak. It is probably possible to convert .deb packages to Flatpak packages. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
allow users to install packages [was: Re: a two cent suggestion]
On 26.11.22 19:42, Patrice Duroux wrote: Dear Debian people, Already possible or not, I would like to have a Debian system for which packages can be installed either by a specific user (root/sysadmin as usual) only or by any other (or a group of) users. But this would also depend on the class of the requested packages: 1. packages providing mainly commands or library facility (large majority packages?), 2. packages providing modifying system runtime like (root) services, new kernel modules, ... (very few packages?). Any (or a specific group of) users could be able to install any package of the first class by their own without asking a sysadmin (or explicitly acquiring privilege of) user. With this goal (dream?) in mind, I tried to cluster all the packages between the one that wouldn't change the system runtime (and therefore even after a reboot) and whatever would be the sign of that.Those package installation should insure a sort of system default runtime reproducibility in fact. If needed in the future, any build process could help to class/tag a package regarding this purpose (as it could also read any debian/* packaging file). Finally the best would be for apt to handle such a scenario, allowing those users to run the apt command which may fail or not regarding each package class. To cluster packages, my first material is to look at the file contents of a package (having content related to sbin or a systemd service or init.d or ...) Opinions or ideas are welcome. Could this clustering by it-self be interesting fin any case (for Debian QA, metrics...)? A few thoughts - * You should not crosspost. There's various reasons for that f.ex. discussion will split because - as in my case - I am not subscribed to debian-users... * You haven't received any feedback yet on debian-devel. A reason for that might be that the idea is good, but the devil is in implementing it. So unless you come up with code and solutions, the idea for itself is maybe not that interesting to discuss (because everybody would like to have user installable packages...) * Debian has "Tags" for packages. Have a look whether there's not already a classification like you suggest (or something very similar). Maybe you can contribute there (note that last I've heard the tag DB and system was unmaintained). Greets, *t
a two cent suggestion
Dear Debian people, Already possible or not, I would like to have a Debian system for which packages can be installed either by a specific user (root/sysadmin as usual) only or by any other (or a group of) users. But this would also depend on the class of the requested packages: 1. packages providing mainly commands or library facility (large majority packages?), 2. packages providing modifying system runtime like (root) services, new kernel modules, ... (very few packages?). Any (or a specific group of) users could be able to install any package of the first class by their own without asking a sysadmin (or explicitly acquiring privilege of) user. With this goal (dream?) in mind, I tried to cluster all the packages between the one that wouldn't change the system runtime (and therefore even after a reboot) and whatever would be the sign of that.Those package installation should insure a sort of system default runtime reproducibility in fact. If needed in the future, any build process could help to class/tag a package regarding this purpose (as it could also read any debian/* packaging file). Finally the best would be for apt to handle such a scenario, allowing those users to run the apt command which may fail or not regarding each package class. To cluster packages, my first material is to look at the file contents of a package (having content related to sbin or a systemd service or init.d or ...) Opinions or ideas are welcome. Could this clustering by it-self be interesting fin any case (for Debian QA, metrics...)? Regards, Patrice
Re: Suggestion for db.debian.org/machines.cgi page
On Mon, 2022-08-22 at 07:12 -0500, Steven Robbins wrote: > NOTE for whoever is maintaining the very nice > db.debian.org/machines.cgi page: https://salsa.debian.org/dsa-team/mirror/userdir-ldap-cgi/ > I guess that one should really be searching in the Description field > rather than Architecture. Probably there needs to be a better way to define/export data about available chroots than a free-form Description field, until then... I think DSA would accept patches to the JavaScript doing the searching so that it searches Description too when Architecture is selected. Personally I use my browser search, which finds mips64el. > What does "Architecture" represent if not the base machine > architecture? I guess it is whatever DSA added to the Architecture field in LDAP, maybe copied from the architecture of the install on the machine: $ ldapsearch -LLL -x -H ldaps://db.debian.org -b ou=hosts,dc=debian,dc=org hostname=eller.debian.org architecture description dn: host=eller,ou=hosts,dc=debian,dc=org architecture: mipsel description: mipsel/mips64el porterbox pabs@eller:~$ dpkg --print-architecture mipsel -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Suggestion for db.debian.org/machines.cgi page
On Monday, August 22, 2022 1:29:13 A.M. CDT Nilesh Patra wrote: > On Mon, Aug 22, 2022 at 08:08:30AM +0200, Sebastiaan Couwenberg wrote: > > On 8/22/22 07:15, Steve Robbins wrote: > > > Oh. I did use Eller -- but the architecture is listed as mipsel. I need > > > mips64el> > > eller has mips64el chroots too, Ah, thank you. NOTE for whoever is maintaining the very nice db.debian.org/machines.cgi page: The way I use this page is to search the Architecture column for the architecture I want. It would help me (and, I expect, others) if there were a few sentences preamble alerting one to the presence of dual-chroot machines. I guess that one should really be searching in the Description field rather than Architecture. On the topic of eller architecture: when I put mips64el in the architecture search field, eller does not appear. I am puzzled by this because "uname -a" on eller apparently is a 64-bit machine so it can't be "mipsel", can it? What does "Architecture" represent if not the base machine architecture? Regards, -Steve signature.asc Description: This is a digitally signed message part.
Re: needs suggestion on LuaJit's IBM architecture dilemma
>From the buildlogs / testlogs / local tests (ppc64el qemu), it seems that there is completely no improvement for ppc64el. Simple scripts can still encounter segmentation faults (e.g., autopkgtest for src:lua-moses). s390x is newly enabled. I still have not seen enough test log to give any preliminary conclusion. On Thu, 2022-06-09 at 16:19 +0200, Frédéric Bonnard wrote: > Hi Mo, Paul, > did you see any improvement with luajit2 ? > I was looking at luakit, which still fails "silently" on ppc64el, a lua > script generating a .h with no symbols with luajit2, where it does work > with lua. > Also I see that the autopkgtest of knot-resolver still fails on > ppc64el. > > F. > > On Thu, 19 May 2022 22:14:01 -0400 "M. Zhou" wrote: > > On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote: > > > Hi, > > > > > > I've followed luajit closely since 2015 on ppc64el as a porter > > > without enough knowledge to port it, but trying to ease on the > > > packaging/Debian side (being both IBMer/DD). > > > That port has been a mixed effort between a code bounty and an IBM > > > effort (some devs) . > > > It didn't started well ( > > > https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) > > > and it has never grown and be really part of the upstream project > > > sadly. > > > > > > With the years, I'm even less optimistic as no IBM nor external > > > developer seem to be working on that. Mike Pall seems to be around > > > though as you said there's no release (not necessarily a bad sign). > > > I can ping inside IBM but I'm not sure there will be any positive > > > feedback. > > > > > > So I'd say we have no choice, i.e. let's drop IBM arches . > > > What I did a few times for packages depending on libluajit was to use > > > liblua instead : > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 > > > > > > Thanks, > > > F. > > > > Nobody want to spend time on an bottomless hole ... > > I'll simply remove ppc64el architecture support from src:luajit, > > and give src:luajit2 (openresty) a try. > >
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Frédéric, On 09-06-2022 16:19, Frédéric Bonnard wrote: did you see any improvement with luajit2 ? Improvements, yes. All fixed, no. I was looking at luakit, which still fails "silently" on ppc64el, a lua script generating a .h with no symbols with luajit2, where it does work with lua. Also I see that the autopkgtest of knot-resolver still fails on ppc64el. See also https://bugs.debian.org/1012362. Best to have the conversation there. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Mo, Paul, did you see any improvement with luajit2 ? I was looking at luakit, which still fails "silently" on ppc64el, a lua script generating a .h with no symbols with luajit2, where it does work with lua. Also I see that the autopkgtest of knot-resolver still fails on ppc64el. F. On Thu, 19 May 2022 22:14:01 -0400 "M. Zhou" wrote: > On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote: > > Hi, > > > > I've followed luajit closely since 2015 on ppc64el as a porter > > without enough knowledge to port it, but trying to ease on the > > packaging/Debian side (being both IBMer/DD). > > That port has been a mixed effort between a code bounty and an IBM > > effort (some devs) . > > It didn't started well ( > > https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) > > and it has never grown and be really part of the upstream project > > sadly. > > > > With the years, I'm even less optimistic as no IBM nor external > > developer seem to be working on that. Mike Pall seems to be around > > though as you said there's no release (not necessarily a bad sign). > > I can ping inside IBM but I'm not sure there will be any positive > > feedback. > > > > So I'd say we have no choice, i.e. let's drop IBM arches . > > What I did a few times for packages depending on libluajit was to use > > liblua instead : > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 > > > > Thanks, > > F. > > Nobody want to spend time on an bottomless hole ... > I'll simply remove ppc64el architecture support from src:luajit, > and give src:luajit2 (openresty) a try. > signature.asc Description: PGP signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote: > Hi, > > I've followed luajit closely since 2015 on ppc64el as a porter > without enough knowledge to port it, but trying to ease on the > packaging/Debian side (being both IBMer/DD). > That port has been a mixed effort between a code bounty and an IBM > effort (some devs) . > It didn't started well ( > https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) > and it has never grown and be really part of the upstream project > sadly. > > With the years, I'm even less optimistic as no IBM nor external > developer seem to be working on that. Mike Pall seems to be around > though as you said there's no release (not necessarily a bad sign). > I can ping inside IBM but I'm not sure there will be any positive > feedback. > > So I'd say we have no choice, i.e. let's drop IBM arches . > What I did a few times for packages depending on libluajit was to use > liblua instead : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 > > Thanks, > F. Nobody want to spend time on an bottomless hole ... I'll simply remove ppc64el architecture support from src:luajit, and give src:luajit2 (openresty) a try.
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi Dipack, I filed an ITP bug for luajit2 and will look into it. Thank you! On Mon, 2022-05-16 at 16:22 +, Dipak Zope1 wrote: > Hello all, > It'd be better to switch to luajit2 if it is possible. We can see > right now the main issue with luajit project is no response from > upstream of LuaJIT to previous merge request attempts. And luajit2 > already contains almost everything needed for s390x support. > > Thanks, > -Dipak >
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi, I've followed luajit closely since 2015 on ppc64el as a porter without enough knowledge to port it, but trying to ease on the packaging/Debian side (being both IBMer/DD). That port has been a mixed effort between a code bounty and an IBM effort (some devs) . It didn't started well ( https://www.freelists.org/post/luajit/PPC64le-port-status,1 ) and it has never grown and be really part of the upstream project sadly. With the years, I'm even less optimistic as no IBM nor external developer seem to be working on that. Mike Pall seems to be around though as you said there's no release (not necessarily a bad sign). I can ping inside IBM but I'm not sure there will be any positive feedback. So I'd say we have no choice, i.e. let's drop IBM arches . What I did a few times for packages depending on libluajit was to use liblua instead : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892765 Thanks, F. On Wed, 11 May 2022 21:29:26 -0400 "M. Zhou" wrote: > Hi folks, > > I learned in disappointment after becoming LuaJit uploader that > the LuaJit upstream behaves uncooperatively especially for IBM > architectures [1]. IIUC, the upstream has no intention to care > about IBM architectures (ppc64el, s390x). > > The current ppc64el support on stable is done through cherry-picked > out-of-tree patch. And I learned that the patch is no longer > functional[2] for newer snapshots if we step away from that > ancient 2.1.0~beta3 release. > > However, architectures like amd64 needs relatively newer version[3], > while IBM architecture still has demand luajit[4] (only the > ancient version will possibly work on IBM archs). > > I'm looking for suggestions on what to do next: > > option 1: > drop IBM architectures that the upstream cannot support > from src:luajit, and provide archs like amd64 with relatively > newer snapshot versions[5]. > and package reliable alternatives (if any) for IBM archs. > option 2: > use latest source for amd64 architecture, and rollback the > source specifically for IBM architectures to keep it > functional. > option 3: > rollback to the ancient stable release and screw it > option 4: > ... > > Thanks. > > [1] https://github.com/LuaJIT/LuaJIT/pull/140 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 > [5] Yes ... the upstream do not release anymore. > signature.asc Description: PGP signature
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hello all, It'd be better to switch to luajit2 if it is possible. We can see right now the main issue with luajit project is no response from upstream of LuaJIT to previous merge request attempts. And luajit2 already contains almost everything needed for s390x support. Thanks, -Dipak From: M. Zhou Date: Thursday, 12 May 2022 at 8:07 AM To: debian-devel Subject: [EXTERNAL] needs suggestion on LuaJit's IBM architecture dilemma Hi folks, I learned in disappointment after becoming LuaJit uploader that the LuaJit upstream behaves uncooperatively especially for IBM architectures [1]. IIUC, the upstream has no intention to care about IBM architectures (ppc64el, s390x). The current ppc64el support on stable is done through cherry-picked out-of-tree patch. And I learned that the patch is no longer functional[2] for newer snapshots if we step away from that ancient 2.1.0~beta3 release. However, architectures like amd64 needs relatively newer version[3], while IBM architecture still has demand luajit[4] (only the ancient version will possibly work on IBM archs). I'm looking for suggestions on what to do next: option 1: drop IBM architectures that the upstream cannot support from src:luajit, and provide archs like amd64 with relatively newer snapshot versions[5]. and package reliable alternatives (if any) for IBM archs. option 2: use latest source for amd64 architecture, and rollback the source specifically for IBM architectures to keep it functional. option 3: rollback to the ancient stable release and screw it option 4: ... Thanks. [1] https://github.com/LuaJIT/LuaJIT/pull/140 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 [5] Yes ... the upstream do not release anymore.
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi! On 5/12/22 03:29, M. Zhou wrote: > I learned in disappointment after becoming LuaJit uploader that > the LuaJit upstream behaves uncooperatively especially for IBM > architectures [1]. IIUC, the upstream has no intention to care > about IBM architectures (ppc64el, s390x). > > The current ppc64el support on stable is done through cherry-picked > out-of-tree patch. And I learned that the patch is no longer > functional[2] for newer snapshots if we step away from that > ancient 2.1.0~beta3 release. > > However, architectures like amd64 needs relatively newer version[3], > while IBM architecture still has demand luajit[4] (only the > ancient version will possibly work on IBM archs). I saw that Matej Cepl was replying in the thread who is a colleague of mine and who is the maintainer of the luajit package in openSUSE/SLE. Since SUSE has a commercial interest in working POWER/S390 support, he takes care of the package and makes sure it keeps working on these architectures. My suggestion would be to just pick the packages from openSUSE [1] since they are kept up-to-date. Adrian > [1] https://build.opensuse.org/package/show/devel:languages:lua/luajit -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
needs suggestion on LuaJit's IBM architecture dilemma
Hi folks, I learned in disappointment after becoming LuaJit uploader that the LuaJit upstream behaves uncooperatively especially for IBM architectures [1]. IIUC, the upstream has no intention to care about IBM architectures (ppc64el, s390x). The current ppc64el support on stable is done through cherry-picked out-of-tree patch. And I learned that the patch is no longer functional[2] for newer snapshots if we step away from that ancient 2.1.0~beta3 release. However, architectures like amd64 needs relatively newer version[3], while IBM architecture still has demand luajit[4] (only the ancient version will possibly work on IBM archs). I'm looking for suggestions on what to do next: option 1: drop IBM architectures that the upstream cannot support from src:luajit, and provide archs like amd64 with relatively newer snapshot versions[5]. and package reliable alternatives (if any) for IBM archs. option 2: use latest source for amd64 architecture, and rollback the source specifically for IBM architectures to keep it functional. option 3: rollback to the ancient stable release and screw it option 4: ... Thanks. [1] https://github.com/LuaJIT/LuaJIT/pull/140 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004511 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981808 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008858 [5] Yes ... the upstream do not release anymore.
Suggestion: You should delete Mozilla ESR programs
Dear Woman and Man! Suggestion: You should delete Mozilla ESR programs otherwise you have double work for programming, testing. You should leave more time for the normal version. http://ftp.mozilla.org/pub/firefox/releases/52.0.2/linux-x86_64/en-US/ With kind Greetings!
Re: Fonts hinting to upstream suggestion
Hi Marek, Quoting Marek Mosiewicz (2019-01-24 09:49:35) > I have been trying to have good looking fonts in Debian. What I found > it seems that Firefox ignores dpkg-reconfigure fontconfig-config. > > It is not case for Chromium. After playing with native/autohinting > configuration it seems that it is difficult to have all apps looking > good, because some things can use TrueType fonts which looks good with > autohinting and others with native. You can switch gnome fonts > depending on your setting, but you do not know if web page uses > TrueType or font which looks good with native > > So the idea. Why not detect if it is TrueType font or native font and > use appropriate hinting method for given font. Sounds like your investigations would be quite helpful to others as well: Please consider sharing what you've learned, e.g. on the Debian Wiki. I suspect what need detection here is not if fonts are TrueType or not, but whether a font provides custom hinting or not. And I suspect that some fonts provide native hinting but of poor quality, so that autohinting is still beneficial for those fonts. In any case, I believe the way forward is to first try collect knowledge on the matter (hence my encouragement above to document on our wiki!) and then figure out what to do about it when we know better. ...if if it is just me being stupid here, then great: Point me to the already well documented overview somewhere, so I can read up :-D - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Fonts hinting to upstream suggestion
Hello, I have been trying to have good looking fonts in Debian. What I found it seems that Firefox ignores dpkg-reconfigure fontconfig-config. It is not case for Chromium. After playing with native/autohinting configuration it seems that it is difficult to have all apps looking good, because some things can use TrueType fonts which looks good with autohinting and others with native. You can switch gnome fonts depending on your setting, but you do not know if web page uses TrueType or font which looks good with native So the idea. Why not detect if it is TrueType font or native font and use appropriate hinting method for given font. Cheers, Marek Mosiewicz http://marekmosiewicz.pl
Re: Openvas too old - suggestion
Hello Hans The earlier message in this thread mentioned that Debian Testing is "frozen". You'll find more information about what this means here: https://release.debian.org/stretch/freeze_policy.html though that document is really written for people who are familiar with Debian development. I'm not sure whether there's a document for those less familiar with the release process. In short, "debian testing" isn't getting new versions of software right now, and hasn't for some months, as a step towards making Stretch the next stable release of Debian. Only once Stretch is released will "testing" (which will then be known by the codename "Buster") start getting new versions from "unstable". Jeff
Re: Openvas too old - suggestion
Hi Andrey, > Now please look in experimental. Yes, I saw it in experimental. However, I wondered, why it is still not in unstable or testing, because in Kali it is already since weeks. > Please also remember that we are currently frozen. Of course, I forgot. This is an explanation, of course. No problem. However, I just wanted to point to the binaries of kali (I know, that there are also Ubuntu packages, but I do not trust Ubuntu packages, as they might destroy my system). I had the hope, that a look to kali might reduce your work and help. Please do not see it as mourning, see it as a hint. Best regards Hans -- Ullrich-IT-Consult Ihr Partner für die Themen * IT-SICHERHEIT * IT-SERVICE * * LINUX * EDV-SCHULUNGEN * Hans-J. Ullrich Münstedter Weg 10 31246 Oberg Tel.: 0179 3666 059 FAX: 05172 930 414 E-Mail: hans.ullr...@loop.de
Re: Openvas too old - suggestion
On Tue, May 23, 2017 at 07:48:39PM +0200, Hans wrote: > I see, that even in unstable openvas is still available in version 8. Now please look in experimental. Please also remember that we are currently frozen. -- WBR, wRAR signature.asc Description: PGP signature
Openvas too old - suggestion
Dear developers, I see, that even in unstable openvas is still available in version 8. The actual version however is version 9. Of course I understand, that you have to check the stability and other things. But please allow me to suggest this: In Kali-Linux there are already binary packages in version 9 available. As Kali-Linux is 95 percent based on debian, I think, it might be easy to build packages for debian. Maybe just the package name has to be changed. Just very few work. So, wouldn't it be easy, to use the kali sources to build version 9 packages for debian? I see no big difference between kali and debian except the name. However, maybe I see things wrong, so I am interested, why this will not work, or why the developers do not want to do as I suggested. Technically and political statements are welcome. Thank you for reading this and thanks for your clemency. Best regards Hans-J. Ullrich
Re: Packaging suggestion for the Universal Media Server program.
Aldrin P. S. Castro wrote... > I would very much like the Universal Media Server to be in the Debian > repositories. > He is a very good dlna server. It is done in Java. Unfortunately, by mailing debian-devel your suggestion will very likely not reach the people who might be willing to do the job. Debian's procedure to find someone for bringing software into the repository is called "Request for Packaging" (RFP). The document at https://wiki.debian.org/RFP describes the required steps and contains links to the details. Short version: After some checks you'll have to send an e-mail in a certain format, but the reportbug program will help you with that. Christoph signature.asc Description: Digital signature
Packaging suggestion for the Universal Media Server program.
I would very much like the Universal Media Server to be in the Debian repositories. He is a very good dlna server. It is done in Java.
Re: Suggestion for the DontBreakDebian wiki page section "Dont 'make install'"
On Tue, 20 Oct 2015 21:10:03 +0200, Arturo Borrero Gonzalez wrote: > El 20 oct. 2015 5:15 p. m., "Francisco José Fernández Naranjo" < > fjfnara...@gmail.com> escribió: >> >> I was considering myself adding a quick note to the section, but I am >> not an English native speaker and I am concerned with the quality of my >> contribution. > > In fact, your english level seems good enough to me :-) I agree. In fact, I found it good enough to copy-paste into my edit ;^P https://wiki.debian.org/DontBreakDebian#Don.27t_.27make_install.27
Re: Suggestion for the DontBreakDebian wiki page section "Dont 'make install'"
El 20 oct. 2015 5:15 p. m., "Francisco José Fernández Naranjo" < fjfnara...@gmail.com> escribió: > > I was considering myself adding a quick note to the section, but I am > not an English native speaker and I am concerned with the quality of > my contribution. In fact, your english level seems good enough to me :-)
Suggestion for the DontBreakDebian wiki page section "Dont 'make install'"
Hello guys. I was checking the DontBreakDebian wiki page and I realized one thing. In the section "Don't 'make install'" there is no mention to the alternative path installation options in automake or other building systems. Some people install packages in the system using "sudo" or root when the option for installing the software to the user is almost always available (--prefix=~/.local , etc). Giving that many people is going to end using root for installing software, I think mentioning it in this section will help to maintain the users systems clean. I was considering myself adding a quick note to the section, but I am not an English native speaker and I am concerned with the quality of my contribution. Will someone consider this and contribute it? Sorry for not doing the work myself :( Regards, Naranjo. P.D. Wrong mail-list? I was also thinking about "deity" but I was not sure and it ended here. I will repost it if you think there is a better place for this discussion.
Re: pro-active removals (was: Re: suggestion to add package vlan to default instalation DVD)
On Thu, Sep 17, 2015 at 10:55:58AM +0200, Andreas Henriksson wrote: this, I think it would be a *service* to our users if we removed this (and many other packages in similar situation) from the archive so that we don't fool users into using (or wasting time even looking at) long-deprecated software. If the package is no longer available that means It is not a service if you remove packages without replacement strategy. I don’t care if I use the package iproute2 or vlan/ifenslave to configure VLAN interfaces and/or bonds as long as I have documentation how to do this in /etc/network/interfaces in an easy way. The packages vlan and ifenslave are working very well. That said I think it would be very cool if I could configure VLANs and bonds with the Debian installer. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
pro-active removals (was: Re: suggestion to add package vlan to default instalation DVD)
Hello all. On Wed, Sep 16, 2015 at 09:10:15PM +0200, Sven Hartge wrote: [...] > Why? The vlan package is not needed since at least Wheezy to configure > VLANs on devices since the program "ip" can do everything the same or > even better. > > Also ifupdown was changed to be able to configure VLANs using "ip" > directly without the need for the "vconfig" from the vlan package. I think this example is a good one to describe why we should be more pro-active with removals from the archive. I filed http://bugs.debian.org/501402 in 2008 when the vlan package had already been deprecated. This was to allow the package maintainer (or anyone else!) to implement a smooth transition to the new tools for anyone still using the vlan package This has obviously not happened (and I don't blame people for loosing interest in something that becomes deprecated but it'd ofcourse be nice if we could provide smooth upgrades for our users). As the years pass by it seems less likely that anyone will step up and do the work to implement a smooth migration. Given this, I think it would be a *service* to our users if we removed this (and many other packages in similar situation) from the archive so that we don't fool users into using (or wasting time even looking at) long-deprecated software. If the package is no longer available that means they'll find out the reason and discover the newer replacement that anyone should really be looking at for new deployments today. Unfortunately getting things removed from the archive is alot harder than adding to the archive. This is something that I think we should fix. Regards, Andreas Henriksson
Re: suggestion to add package vlan to default instalation DVD
> it is possible to add package "vlan" to the DVD instalation images? > It is tiny package (36kB) and in some special environment (without > Internet with DVD in vmware environmen) i have to download and install > it manually. Hi Josef. In case you really need it, you can build you own live & install image with the wonderful live-build. You even don't need to that yourself since the debian-live team is providing an web auto-builder : http://cgi.build.live-systems.org/cgi-bin/live-build . Just fill a few fields and hop ! The live build system is sending you an email with what you requested. Isn't life beautiful ? Cheers, Olivier
Re: suggestion to add package vlan to default instalation DVD
Pascal Giard wrote: > On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote: >> Josef Masek wrote: >>> it is possible to add package "vlan" to the DVD instalation images? >>> It is tiny package (36kB) and in some special environment (without >>> Internet with DVD in vmware environmen) i have to download and >>> install it manually. >> >> Why? The vlan package is not needed since at least Wheezy to >> configure VLANs on devices since the program "ip" can do everything >> the same or even better. >> >> Also ifupdown was changed to be able to configure VLANs using "ip" >> directly without the need for the "vconfig" from the vlan package. > Pretty sure he meant VLC there. I don't think so, since vlc is nowhere near 36KB in size (it is 1.5MB) while the package vlan is exactly that: Package: vlan Version: 1.9-3.2 Filename: pool/main/v/vlan/vlan_1.9-3.2_amd64.deb Size: 36542 Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: suggestion to add package vlan to default instalation DVD
On Wed, 2015-09-16 at 15:26 -0400, Pascal Giard wrote: > On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote: > > Josef Masek wrote: > > > >> it is possible to add package "vlan" to the DVD instalation images? > >> It is tiny package (36kB) and in some special environment (without > >> Internet with DVD in vmware environmen) i have to download and install > >> it manually. > > > > Why? The vlan package is not needed since at least Wheezy to configure > > VLANs on devices since the program "ip" can do everything the same or > > even better. > > > > Also ifupdown was changed to be able to configure VLANs using "ip" > > directly without the need for the "vconfig" from the vlan package. > > Pretty sure he meant VLC there. Well, "vlan" in Jessie is 36KB, whereas "vlc" is nearer 1.5MB. So I'd assume he meant the former, really. Regards, Adam
Re: suggestion to add package vlan to default instalation DVD
On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote: > Josef Masek wrote: > >> it is possible to add package "vlan" to the DVD instalation images? >> It is tiny package (36kB) and in some special environment (without >> Internet with DVD in vmware environmen) i have to download and install >> it manually. > > Why? The vlan package is not needed since at least Wheezy to configure > VLANs on devices since the program "ip" can do everything the same or > even better. > > Also ifupdown was changed to be able to configure VLANs using "ip" > directly without the need for the "vconfig" from the vlan package. Pretty sure he meant VLC there. -Pascal -- Homepage (http://organact.mine.nu) Debian GNU/Linux (http://www.debian.org) COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca) ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca)
Re: suggestion to add package vlan to default instalation DVD
Josef Masek wrote: > it is possible to add package "vlan" to the DVD instalation images? > It is tiny package (36kB) and in some special environment (without > Internet with DVD in vmware environmen) i have to download and install > it manually. Why? The vlan package is not needed since at least Wheezy to configure VLANs on devices since the program "ip" can do everything the same or even better. Also ifupdown was changed to be able to configure VLANs using "ip" directly without the need for the "vconfig" from the vlan package. Grüße, Sven. -- Sigmentation fault. Core dumped.
suggestion to add package vlan to default instalation DVD
Hello, it is possible to add package "vlan" to the DVD instalation images? It is tiny package (36kB) and in some special environment (without Internet with DVD in vmware environmen) i have to download and install it manually. Ps. I did not find better mailing list for this purpose, so I am trying this... Regards, Josef Mašek
Re: Suggestion for the installer, when non-free firmwares are needed
On 01/27/2015 03:26 AM, Stephan Dörner wrote: > Dear Debian developers, > > 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. > > 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. Here's a suggestion: don't buy any realtek hardware anymore. These cards perform badly, and as you could see, require non-free hardware. You're also voting with the things you buy... Also, another suggestion: write to realtek to complain about it. Thomas -- 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/54c80bda.5030...@debian.org
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
Re: Suggestion for the installer, when non-free firmwares are needed
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) 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. On the other hand, the Debian Installation Guide section 6.4.1. already contains this information. So me and others could just have read that instead... Thanks for mentioning this! cheers, josch signature.asc Description: signature
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
Suggestion for the installer, when non-free firmwares are needed
Dear Debian developers, 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. 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. Best greetings from Berlin & Thanks, Stephan signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]
Octavio Alvarez: Question: is it safe to say that systemd doesn't yet support the > full /etc/fstab specification from util-linux [1]? Yes; it's safe. It's also wrong. But it's quite safe. (-: -- 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/5478885f.9020...@ntlworld.com
Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]
On 19/11/14 21:32, Steve Langasek wrote: >> 1) the problem with new feature in systemd which considers all >> filesystems in fstab vital for system boot and stops boot if they >> fail. It's been decided that although it is a change in behaviour >> that might render some systems unbootable it's technically correct >> implementation and only enforces that non-vital filesystems are >> marked as such in fstab which should have been the case from the >> start. >> > As regards the two issues you've described: the first is not a bug. > It's a necessary change in how we view the boot in a truly > event-driven system. There is no sane default policy for how to > interpret entries in /etc/fstab on upgrade except to regard them as > all mandatory - *but* it's important that the admin be given the > opportunity to intervene to override this policy. Question: is it safe to say that systemd doesn't yet support the full /etc/fstab specification from util-linux [1]? [1] man 5 fstab Thanks. -- 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/546e6113.2010...@alvarezp.ods.org
Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]
On Thu, Nov 20, 2014 at 01:45:55PM -0800, Octavio Alvarez wrote: > On 19/11/14 21:32, Steve Langasek wrote: > >> 1) the problem with new feature in systemd which considers all > >> filesystems in fstab vital for system boot and stops boot if they > >> fail. It's been decided that although it is a change in behaviour > >> that might render some systems unbootable it's technically correct > >> implementation and only enforces that non-vital filesystems are > >> marked as such in fstab which should have been the case from the > >> start. > > As regards the two issues you've described: the first is not a bug. > > It's a necessary change in how we view the boot in a truly > > event-driven system. There is no sane default policy for how to > > interpret entries in /etc/fstab on upgrade except to regard them as > > all mandatory - *but* it's important that the admin be given the > > opportunity to intervene to override this policy. > Question: is it safe to say that systemd doesn't yet support the full > /etc/fstab specification from util-linux [1]? No? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]
Michal, On Wed, Nov 19, 2014 at 09:34:22AM +0100, Michal Suchanek wrote: > On 19 November 2014 08:02, Didier 'OdyX' Raboud wrote: > > Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit : > >> On 18 November 2014 18:57, Jordi Mallach wrote: > >> > El dl 17 de 11 de 2014 a les 15:41 +0100, en/na Michal Suchanek va > >> > escriure: > >> >> -- System Information: > >> >> Distributor ID: Ubuntu > >> >> Description: Ubuntu GNU/Linux testing (jessie) > >> It's a cosmetic issue ;-). > >> I had Ubuntu base system on this particular PC some years ago and I > >> noticed this issue and spent a few minutes trying to figure out where > >> that value is stored. I did not figure it out and since the upgrade to > >> Debian base system is not supposed to handle this situation it is > >> technically not a bug in Debian. It's only a cosmetic issue so I left > >> it at that. > > Systems cross-craded from Ubuntu to Debian are absolutely not supported, > > and I wouldn't be surprised if some of the issues you're seeing are in > > some way related to this. > Sure, it's always user error when something fails. Systems upgraded > from Ubuntu are not supported, systems upgraded from Debian are not > supported, nor are systems freshly bootstrapped and booted inside > qemu. Because all these fail. Maybe the only clean enough approach is > to get rid of Debian and all its derivatives. Then you will be sure to > get rid of all Debian bugs. > However, I had this biased personal opinion that the goal of the > Debian project should to remove Debian bugs on systems that do run > Debian. Please corect me if this is too disconnected from reality. You aren't getting constructive responses here because you did not submit an actionable bug report. If you are experiencing a bug in upstart or in systemd (or both), the way to get that resolved is by filing a bug report against upstart or systemd (or both). If you think a particular bug is sufficiently grave and intractable to warrant Debian revisiting its choice of init system, there are ways to trigger such a review. But filing a 'general' bug report declaring that 'non-sysvinit init systems are made of fail' is not the way to accomplish anything. As regards the two issues you've described: the first is not a bug. It's a necessary change in how we view the boot in a truly event-driven system. There is no sane default policy for how to interpret entries in /etc/fstab on upgrade except to regard them as all mandatory - *but* it's important that the admin be given the opportunity to intervene to override this policy. The second is certainly a bug. I'm sure if you had filed it as a bug report against either of upstart or systemd, the response from the maintainers would have acknowledged that it is a bug. But you haven't done this; nor have you provided concrete details about the circumstances of your failure. So while you have encountered a bug, I'm sure it's a better use of the systemd maintainers' time to wait for a real bug report from someone who is actually interested in working with them to get this bug fixed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: a stupid suggestion for dpkg?
Le Wed, Oct 23, 2013 at 09:47:23PM +0200, Patrice Duroux a écrit : > > May be this is the wrong place or my subject has been already discussed > in different ways, but is it a crazy idea that a package provides kinds > of pre- prerm and/or post- postinst scripts regarding package(s) that > is(are) just recommended or suggested by it? So that those scripts are > then executed before removal or after installation of the related one(s) > (in conjonction of it then). > I was thinking of it as a general approach to solve small issues like > #727251 by for instance creating/deleting a link into /etc/xdg/autostart > or anything else similar. Dear Patrice, this is called dpkg triggers. They are explained in the manual pages of dpkg-trigger(1) and deb-triggers(5), and in /usr/share/doc/dpkg-dev/triggers.txt.gz on your system. By the way, fellow developers, I did some work to integrate this documentation in the Policy, and there needs one more assessement that this integration is correct and consensual. It seems that the size of the patch(es) has been an obstacle to the review, so your help would be greatly appreciated. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582109#209 I plan a Policy update by the end of October, and my gut feeling is that if by that time, peple stay silent on the issue, the work will go straight in the dust bin. I am of course happy to delay a bit the update if one needs more time to review the patches. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20131023220808.ga28...@falafel.plessy.net
a stupid suggestion for dpkg?
Dear Debian Developers, May be this is the wrong place or my subject has been already discussed in different ways, but is it a crazy idea that a package provides kinds of pre- prerm and/or post- postinst scripts regarding package(s) that is(are) just recommended or suggested by it? So that those scripts are then executed before removal or after installation of the related one(s) (in conjonction of it then). I was thinking of it as a general approach to solve small issues like #727251 by for instance creating/deleting a link into /etc/xdg/autostart or anything else similar. Best regards, Patrice -- 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/1382557643.7138.18.camel@localhost
Re: Suggestion about minor improvements to default bashrc
Le Sat, Jan 26, 2013 at 06:19:02PM +0100, Simon Johnsson a écrit : > Hello, this is my first minor contribution to Debian, but as it's my > Linux distribution of choise and the only one I chose to work with I > have found minor improvements that perhaps can be of use. Dear Simon, thank you for trying to improve Debian. The .bashrc file in fresh user accounts is derived from /etc/skel/.bashrc, which is created by the base-files package. To make your suggestion, you would therefore report a bug with a severity wishlist against this package. This said, be prepared to be disappointed by the answer. On a distribution that targets a broad range of users, /etc/skel/.bashrc, can only be minimal. Imagine that your alias pleases 90 % of the users and annoys the 10 % remaining. With a bunch of aliases that have non-overlapping user bases, we would quickly grow towards a very high probablity of annoying any of our users by default... But there are countless other ways where you can help Debian. You can have a look at http://www.debian.org/intro/help for a start. Have a nice Sunday, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20130127065329.ga28...@falafel.plessy.net
Re: Suggestion about minor improvements to default bashrc
On Sat, Jan 26, 2013 at 06:19:02PM +0100, Simon Johnsson wrote: > Hello, this is my first minor contribution to Debian, but as it's my > Linux distribution of choise and the only one I chose to work with I > have found minor improvements that perhaps can be of use. > > The first one I will mail about is so minor it might be uninteresting > but as I spend so much time on new VPS and Debain installations on > the net I tend to use the: > > $ clear > > Command more often than not. However, to save time I've begun to use > an .bashrc alias for it, as such: > > alias cl='clear' > > If you personally havn't tried it, do it. It's insanely addictive. Did you try Ctrl-L? > I have further ideas for improvements, but I am unaware of the > criteria for Debian scripts. Is it okay to use external sites for > information inside shell scripts? What do you mean? > Perhaps there's somekind of guildeline for Debian developers I can view > before I write more material! Guideline regarding what? -- WBR, wRAR signature.asc Description: Digital signature
Suggestion about minor improvements to default bashrc
Hello, this is my first minor contribution to Debian, but as it's my Linux distribution of choise and the only one I chose to work with I have found minor improvements that perhaps can be of use. The first one I will mail about is so minor it might be uninteresting but as I spend so much time on new VPS and Debain installations on the net I tend to use the: $ clear Command more often than not. However, to save time I've begun to use an .bashrc alias for it, as such: alias cl='clear' If you personally havn't tried it, do it. It's insanely addictive. I have further ideas for improvements, but I am unaware of the criteria for Debian scripts. Is it okay to use external sites for information inside shell scripts? Perhaps there's somekind of guildeline for Debian developers I can view before I write more material! // Slimbo -- 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/20130126171902.ga19...@wuut.se
Re: suggestion
Paul Wise, le Sun 28 Oct 2012 11:34:33 +0800, a écrit : > On Sat, Oct 27, 2012 at 6:39 PM, Samuel Thibault wrote: > > When somebody implements it. > > Someone already did: > > ftp://ftp.debian.org/debian/tools/win32-loader/unstable/win32-loader.txt Wubi is not only about installing from windows, but also installing *in* windows, without repartitioning. Samuel -- 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/20121028093405.gs5...@type.wlan.youpi.perso.aquilenet.fr
Re: suggestion
On Sat, Oct 27, 2012 at 6:39 PM, Samuel Thibault wrote: > When somebody implements it. Someone already did: ftp://ftp.debian.org/debian/tools/win32-loader/unstable/win32-loader.txt -- 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: http://lists.debian.org/CAKTje6GO+LQUt5nyg7SafW58xToD5czGFmfedEc_Ec=0q_f...@mail.gmail.com
Re: suggestion
Ricardo Obando, le Fri 26 Oct 2012 21:29:37 -0300, a écrit : > When will there be in debian installer for Debian and wubi as Ubuntu? When somebody implements it. Samuel -- 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/20121027103909.gv5...@type.wlan.youpi.perso.aquilenet.fr
Re: suggestion
Take a look: http://goodbye-microsoft.com/ Cheers! On Fri, Oct 26, 2012 at 7:29 PM, Ricardo Obando wrote: > When will there be in debian installer for Debian and wubi as Ubuntu? > > Attentively Ricardo Obando, from Chile. > -- William Vera | bi...@billy.mx Systems Engineer / Consultant IT / Sysadmin PGP Key: 1024D/F5CC22A4 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4
suggestion
When will there be in debian installer for Debian and wubi as Ubuntu? Attentively Ricardo Obando, from Chile.
Re: Feature suggestion: TCP-FIT congestion control
On Sun, Sep 09, 2012 at 04:06:36AM +0400, a...@mvpro.net wrote: > I see, that Debian Wheezy comes with new congestion control named 'yeah', > it's rather good innovation, but by my tests TCP-Fit congestion control > should be the best for now. The question is not only one of finding the local optimum, but also how the chosen congestion control algorithm monopolizes the available bandwidth, hurting other users. (Yeah, that might make introducing new congestion control algorithms harder, but it's a solvable problem.) Kind regards Philipp Kern -- 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/20120909095313.ga10...@hub.kern.lc
Re: Feature suggestion: TCP-FIT congestion control
On Sun, Sep 9, 2012 at 8:06 AM, Alex wrote: > I see, that Debian Wheezy comes with new congestion control named 'yeah', > it's rather good innovation, but by my tests TCP-Fit congestion control > should be the best for now. ... > It would be perfect if you'll innovate this into Wheezy. Debian Wheezy is now frozen so no new features will be added to it: http://lists.debian.org/debian-devel-announce/2012/06/msg9.html If you want TCP-Fit in Debian jessie (the version after wheezy), you will need to get it included into Linux upstream and then if it requires enabling you can file a bug against the Debian linux package to ask the Debian Linux packaging team to enable it. http://kernelnewbies.org/UpstreamMerge http://www.debian.org/Bugs/Reporting -- 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: http://lists.debian.org/CAKTje6HZoD9Gu5GyXwK=tj3lbexo4x3c4fuj-yq0hv_rcmi...@mail.gmail.com
Feature suggestion: TCP-FIT congestion control
Hello. I see, that Debian Wheezy comes with new congestion control named 'yeah', it's rather good innovation, but by my tests TCP-Fit congestion control should be the best for now. More information about it you can get here: http://media.cs.tsinghua.edu.cn/~multimedia/tcp-fit/ It would be perfect if you'll innovate this into Wheezy. I am working with high-loaded machines which needs to answer properly to all millions of requests, tcp-fit might be useful for it. Wanna to see native support for it on Debian Wheezy, because for now I am using Debian Wheezy as the main platform. You can reply me at ad...@mvpro.net. Thanks in advance, Alex. -- 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/398721347149...@web17d.yandex.ru
Re: Some suggestion
On Sat, 3 Dec 2011 03:59:18 +0800, pei deng wrote: >I think debian should release a publish version with roll updating as >archlinux. and remove testing and sid version. Kindly try to understand how Debian's release process works before suggesting things. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1rwt5i-0003ix...@swivel.zugschlus.de
Re: Some suggestion
2011/12/2 Игорь Пашев : > +1. Also there is no much difference between unstable and testing. > > > 2011/12/3 Mike Dupont >> >> so what is the difference, I am using unstable and it rolls >> mike >> Testing/Unstable/Experimental are kind-of rolling - it is rolling two months after release and somewhere to middle of soft freeze. Outside of this time frame it is too many changes introduced (after release) or too low number of changes (mainly stabilization of system, after soft freeze). Personally I don't believe rolling is so needed as a release - for me it seems it is more of fashion than actual need. darkestkhan -- Feel free to CC me. jid: darkestk...@gmail.com May The Source be with You. -- 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/cacrpbmggimqfn-tnzpm6hryh-ocgskgjdhnpjafkpxuafop...@mail.gmail.com
Re: Some suggestion
2011/12/2 pei deng : > I think debian should release a publish version with roll updating as > archlinux. and remove testing and sid version. > > because 'roll' is really a very good mechanism for software publish and > test. > And how would then Debian continue releasing stable? Debian is especially known for its stable release (prolly too much for it). Also there are some problems with rolling releases - something may break at unexpected point of time (just like in testing/unstable/experimental). Without Sid we wouldn't have testbed for updates/upgrades making system much less stable overall - and by then you could as well use Arch. Besides you can use Testing as (kind-of) rolling distribution (or if you want slightly newer packages then Sid or Sid/Experimental (I was using Sid/experimental for long time, and it worked nicely, until I tried playing with Linux containers (land of brevity, especially when you don't know what you are doing) on my main system). There was proposal for Constantly-Usable-Testing (CUT) as another release of Debian, but I don't know too much about it. darkestkhan -- Feel free to CC me. jid: darkestk...@gmail.com May The Source be with You. -- 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/CACRpbMhdEzoEV+kD0593JLWTeFHNjTmqBJ7U=vpqjxawcmm...@mail.gmail.com
Re: Some suggestion
+1. Also there is no much difference between unstable and testing. 2011/12/3 Mike Dupont > so what is the difference, I am using unstable and it rolls > mike > > On Fri, Dec 2, 2011 at 7:59 PM, pei deng wrote: > > I think debian should release a publish version with roll updating as > > archlinux. and remove testing and sid version. > > > > because 'roll' is really a very good mechanism for software publish and > > test. > > > > > > > > -- > > Regards, > > Deng Pei > > > > Software Engineering Institute > > HP GDSCA CDC > > Fedora Project Maintainer > > dpwa...@gmail.com > > dpwalle.users.sf.net > > East China Normal University, Shanghai, China 200062 > > > > > > -- > James Michael DuPont > Member of Free Libre Open Source Software Kosova http://flossk.org > > > -- > 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/caf0qkv32ndogsankwnin7xqba_3gcwp7egupsegpnprjj1...@mail.gmail.com > >
Re: Some suggestion
so what is the difference, I am using unstable and it rolls mike On Fri, Dec 2, 2011 at 7:59 PM, pei deng wrote: > I think debian should release a publish version with roll updating as > archlinux. and remove testing and sid version. > > because 'roll' is really a very good mechanism for software publish and > test. > > > > -- > Regards, > Deng Pei > > Software Engineering Institute > HP GDSCA CDC > Fedora Project Maintainer > dpwa...@gmail.com > dpwalle.users.sf.net > East China Normal University, Shanghai, China 200062 > -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org -- 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/CAF0qKV32ndOGsANkwNiN=7xqba_3gcwp7egupsegpnprjj1...@mail.gmail.com
Some suggestion
I think debian should release a publish version with roll updating as archlinux. and remove testing and sid version. because 'roll' is really a very good mechanism for software publish and test. -- *Regards,* *Deng Pei* * * *Software Engineering Institute* *HP GDSCA CDC* *Fedora Project Maintainer* *dpwa...@gmail.com* *dpwalle.users.sf.net* *East China Normal University, Shanghai, China 200062*
Re: suggestion: build-blockers field in control file
[Russell Coker]
> Why not have software which wants to have the dependencies of a
> package look at the dependencies line as well as the
> build-dependencies?
>
> It seems to me that the package maintainers are already providing the
> necessary information and the people who maintain autobuilder systems
> just need to use it.
H. Do you mean:
(1) The buildd should parse debian/control prior to building, and
delay the build ("dep-wait") if any binary package Depends line
would not (yet) be satisfied?
(2) The buildd should not upload a build until every binary package
in the built .changes file is installable?
(3) The buildd should edit the .changes file to exclude binary
packages that are not installable, upload _that_, then put the rest
of the binary packages in some sort of hold queue?
(4) ???
(1) is problematic for several reasons; most specifically, that it is
possible, and even common, for not every package in debian/control to
be built on every architecture. You can't predict which packages will
actually be built.
(2) is less problematic, but does introduce extra delay into package
build and propagation. It also would require manual intervention for
any dependency loop.
And (3) seems like a very complex workflow to solve a very small problem.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
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/20111202081023.ga3...@p12n.org
Re: suggestion: build-blockers field in control file
On Wed, 30 Nov 2011, peter green wrote: > Some packages have runtime dependencies on packages that they do not > have corresponding build-dependencies for. This leads to the building of > uninstallable packages which in turn leads to problems with testing > transition of packages. > > Currently there are two workarounds for this situation > > 1: manually alter the package's architecture list to limit building to > those architectures where runtime dependencis > 2: add an artificial build-dependency Why are such things required? Why not have software which wants to have the dependencies of a package look at the dependencies line as well as the build-dependencies? It seems to me that the package maintainers are already providing the necessary information and the people who maintain autobuilder systems just need to use it. I can't imagine that changing lots of packages and keeping track of new packages with similar issues would take less work than changing an autobuilder. I also can't imagine that changing lots of packages would be as reliable. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201112021230.36184.russ...@coker.com.au
Re: suggestion: build-blockers field in control file
* peter green , 2011-11-29, 19:23: Some packages have runtime dependencies on packages that they do not have corresponding build-dependencies for. This leads to the building of uninstallable packages which in turn leads to problems with testing transition of packages. Currently there are two workarounds for this situation 1: manually alter the package's architecture list to limit building to those architectures where runtime dependencis 2: add an artificial build-dependency Neither is ideal, the first must be manually undone if and when the dependencies do become available. The second is an abuse of the build-depends field (the package isn't REALLY needed for building) and causes pacakges to be unnessacerally installed in build environments (both on autobuilders and for those manually building the package) wasting time and network bandwidth. I therefore propose a new control field for source packages "build-blockers". Autobuilder management systems should generally treat build-blockers the same as build-depends but the systems that actually do the building do not need to take any notice of them. It doesn't sound completely crazy, but I doubt that implementing such field is worth the trouble. How many packages would benefit from it? Do you have any concrete examples? -- Jakub Wilk -- 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/20111201153020.gb4...@jwilk.net
Re: suggestion: build-blockers field in control file
peter green wrote: [...] > This leads to the building of > uninstallable packages which in turn leads to problems with testing > transition of packages. > > Currently there are two workarounds for this situation > > 1: manually alter the package's architecture list to limit building to those > architectures where runtime dependencis > 2: add an artificial build-dependency For completeness, it's probably worth mentioning a third option: 3: use the architecture list to document fundamental portability hurdles and packages-arch-specific[*] to document accidental ones [*] http://www.debian.org/doc/manuals/developers-reference/pkgs.html.en#packages-arch-specific -- 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/2029200854.ga9...@elie.hsd1.il.comcast.net
suggestion: build-blockers field in control file
Some packages have runtime dependencies on packages that they do not have corresponding build-dependencies for. This leads to the building of uninstallable packages which in turn leads to problems with testing transition of packages. Currently there are two workarounds for this situation 1: manually alter the package's architecture list to limit building to those architectures where runtime dependencis 2: add an artificial build-dependency Neither is ideal, the first must be manually undone if and when the dependencies do become available. The second is an abuse of the build-depends field (the package isn't REALLY needed for building) and causes pacakges to be unnessacerally installed in build environments (both on autobuilders and for those manually building the package) wasting time and network bandwidth. I therefore propose a new control field for source packages "build-blockers". Autobuilder management systems should generally treat build-blockers the same as build-depends but the systems that actually do the building do not need to take any notice of them. What do others think? -- 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/4ed5314b.1070...@p10link.net
Re: Suggestion to remove (eventually) libtar from Debian
Magnus Holmgren writes: > libtar popped up on wnpp-alert, so I ITAd it, but now I'm having second > thoughts. I've done one upload now though. > > - No new releases since 2003. Upstream hasn't bothered building a dynamic > library, that's a Debian patch (and a corresponding patch in other distros). > > - libarchive is superior (I suppose). > > - The API has some problems: th_get_pathname() sometimes returns a pointer > into the TAR struct passed to it and sometimes a pointer to malloc()ed memory > (a strdup() of a local buffer). It has been suggested to always strdup() the > result instead, but it's also been suggested to return a pointer to a static > buffer in applicable cases, which I think may be better (you have to copy the > returned string anyway since the TAR struct is updated as you iterate over > the > tar contents). Thoughts? Thread safety and rentrancy is a problem there. A third option is to pass a buffer to the function (plus its size) and fill it with the name. I would probide both a strdup() and a buffer passing version of the function so people can choose. > - Another problem is the tartype_t struct that you can pass to tar_open() to > provide your own functions for opening, reading and writing the underlying > file, e.g. to handle compressed tar files. Unfortunately you have to put your > context in an int instead of a more versatile void*. > > - It is riddled with MAXPATHLEN, so getting it to build on HURD doesn't seem > worthwile. > > - It has few rdepends: > barry - uses th_get_pathname() (with the comment "FIXME (leak) - someday, > when all distros use a patched version of libtar, we may be able to > avoid this memory leak, but th_get_pathname() does not consistently > return a user-freeable string on all distros." > composite - already supports libarchive, it seems. > lordsawar - Not sure about this one. > osmo - Uses libtar very simply to make and restore backups. Should be easy > to convert to libarchive. > stopmotion - Not sure about this one. > vlc - The skins2 UI module uses libtar to unpack skins. Should be easy > to convert to libarchive. > > Any thoughts? > > -- > Magnus Holmgrenholmg...@debian.org > Debian Developer I guess the maintainers of the rdepends should make the choice (and do the work :). MfG Goswin -- 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/87bp0virmp.fsf@frosties.localnet
Suggestion to remove (eventually) libtar from Debian
libtar popped up on wnpp-alert, so I ITAd it, but now I'm having second thoughts. I've done one upload now though. - No new releases since 2003. Upstream hasn't bothered building a dynamic library, that's a Debian patch (and a corresponding patch in other distros). - libarchive is superior (I suppose). - The API has some problems: th_get_pathname() sometimes returns a pointer into the TAR struct passed to it and sometimes a pointer to malloc()ed memory (a strdup() of a local buffer). It has been suggested to always strdup() the result instead, but it's also been suggested to return a pointer to a static buffer in applicable cases, which I think may be better (you have to copy the returned string anyway since the TAR struct is updated as you iterate over the tar contents). Thoughts? - Another problem is the tartype_t struct that you can pass to tar_open() to provide your own functions for opening, reading and writing the underlying file, e.g. to handle compressed tar files. Unfortunately you have to put your context in an int instead of a more versatile void*. - It is riddled with MAXPATHLEN, so getting it to build on HURD doesn't seem worthwile. - It has few rdepends: barry - uses th_get_pathname() (with the comment "FIXME (leak) - someday, when all distros use a patched version of libtar, we may be able to avoid this memory leak, but th_get_pathname() does not consistently return a user-freeable string on all distros." composite - already supports libarchive, it seems. lordsawar - Not sure about this one. osmo - Uses libtar very simply to make and restore backups. Should be easy to convert to libarchive. stopmotion - Not sure about this one. vlc - The skins2 UI module uses libtar to unpack skins. Should be easy to convert to libarchive. Any thoughts? -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
RE: suggestion about debian devel extension
Dear Pabs: > I was going to add it but I note the site seems to only list 21 out of > the thousands of source packages in Debian. I don't think it is > currently useful enough to add a debian.net domain alias. Please let > me know if that changes. There are many limitations for free web storage: 1. total storage is limited to 10G, or smaller (1G) 2. without ssh 3. upload files or size of each day is limited. 4. shell exec time is limited Because of shortcomming 1, It is imporsible to upload many packages to the web. The storage usage is 3G for now. Becuase of shortcomming 2, 3, 4, uploading is really tedious and time-cosuming. Currently, there are about 50 packages in my local computer. For some huge packages, it is imporsible to upload them. For example, only the kernel-2.26.22 needs more than 20G storage. The analysis is not perfect now. Finding and removing the bug is still time-undeterment. So the answer: it will be change, but maybe not the same as your expection. (And more, the analysis for c++ is on the way. However, the result is a liittle mess and only the creator know what it means. The analysis for c++ is not practical within 18 or 24 months. Is it good news or bad news? ) > I would also suggest source.debian.net instead of osa.debian.net since > it is more easy to remember. deal! > AFAICT it hasn't been started yet, so don't hold your breath :) :( best wishes, j > Date: Sat, 10 Jul 2010 16:53:09 +0800 > Subject: Re: suggestion about debian devel extension > From: p...@debian.org > To: debian-devel@lists.debian.org > > On Thu, Jul 8, 2010 at 4:50 PM, j jj wrote: > >> The open source analysis website runs on free host space. So the storage >> and the performance are limited, the website is also unstable. Would you >> still kindly sponsor me a domain ( osa.debian.net) ? > > I was going to add it but I note the site seems to only list 21 out of > the thousands of source packages in Debian. I don't think it is > currently useful enough to add a debian.net domain alias. Please let > me know if that changes. > > I would also suggest source.debian.net instead of osa.debian.net since > it is more easy to remember. > >> I wish source.debian could be finished soon, and I will try my best to >> make it better. Keep going! > > AFAICT it hasn't been started yet, so don't hold your breath :) > > -- > 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: > http://lists.debian.org/aanlktilhq_ebrpodcxu0fepztsa1y_dj0ntlsayi4...@mail.gmail.com > _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 -- 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/col105-w300f242f7670f1040370fdcf...@phx.gbl
Re: suggestion about debian devel extension
On Thu, Jul 8, 2010 at 4:50 PM, j jj wrote: > The open source analysis website runs on free host space. So the storage > and the performance are limited, the website is also unstable. Would you > still kindly sponsor me a domain ( osa.debian.net) ? I was going to add it but I note the site seems to only list 21 out of the thousands of source packages in Debian. I don't think it is currently useful enough to add a debian.net domain alias. Please let me know if that changes. I would also suggest source.debian.net instead of osa.debian.net since it is more easy to remember. > I wish source.debian could be finished soon, and I will try my best to make > it better. Keep going! AFAICT it hasn't been started yet, so don't hold your breath :) -- 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: http://lists.debian.org/aanlktilhq_ebrpodcxu0fepztsa1y_dj0ntlsayi4...@mail.gmail.com
Suggestion for new virtual package: httpd-wsgi
Hi there, I would like to suggest a new virtual package, "httpd-wsgi". I'm currently in the process of packaging a Pylons-based web-application that uses wsgi and instead of manually keeping / updating a list of all possible implementations (eg. libapache2-mod-wsgi) it would be very nice if I (and other people who might want to package wsgi applications) could use a virtual package instead (similar to httpd-cgi). Btw, I also filed this as #588497 cheers -- Stefan Ott http://www.ott.net/ "You are not Grey Squirrel?" -- 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/aanlktinzcmdeqa-lfagtasxn7gnhugjgfqcdrk_xy...@mail.gmail.com
RE: suggestion about debian devel extension
Dear Pabs: Thanks very much for your kind. The open source analysis website runs on free host space. So the storage and the performance are limited, the website is also unstable. Would you still kindly sponsor me a domain ( osa.debian.net) ? I wish source.debian could be finished soon, and I will try my best to make it better. Keep going! best wishes J > Date: Thu, 8 Jul 2010 10:23:08 +0800 > Subject: Re: suggestion about debian devel extension > From: p...@debian.org > To: debian-devel@lists.debian.org > > On Thu, Jul 8, 2010 at 8:57 AM, Peter Samuelson wrote: > >> 1) Maybe you wanted to have your software packaged and available on >> Debian mirrors, so developers everywhere could install it to >> cross-reference their codebases, for local use or for a corporate >> intranet. (Do people still use the word intranet?) > > Packaging is generally best done by the person interested in the > software. For more info about getting packages into Debian check out > the debian-mentors FAQ: > > http://people.debian.org/~mpalmer/debian-mentors_FAQ.html > >> 2) Maybe you wanted your site to be linked from some web page, perhaps >> www.debian.org/devel/. > > To get that done, file a bug on the www.debian.org pseudo-package: > > http://www.debian.org/Bugs/Reporting > >> 3) Maybe you wanted to obtain a 'debian.net' subdomain, in order to >> host something that is Debian-related but not officially part of the >> Debian project. > > I'd be happy to "sponsor" you such a domain, which one would you like? > >> 4) Maybe you wanted someone else to host the same. > > I've no machines or time to do that, perhaps someone else on this list > is willing and able. > >> 5) Maybe you wanted the Debian Project to host a copy of your webapp, >> indexing all of ftp.debian.org, for general public use. > > There are/were plans for something similar, see the source.d.o section here: > > http://dsa.debian.org/hardware-wishlist/ > > Seems to be waiting on hardware and folks to work on it. > > There also used to be source.d.n, which ran OpenGrok but the > maintainer of it didn't have time to keep it working so I had to > "de-sponsor" it. > > Not exactly a list of yes/no answers but I found your desire for such > answers confusing. > > -- > 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: > http://lists.debian.org/aanlktim5goitjpqf2ak1p-jzc2iu1asyvziqzqe4a...@mail.gmail.com > _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- 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/col105-w65fc0ba2fc600fa572fe63cf...@phx.gbl
Re: suggestion about debian devel extension
On Thu, Jul 8, 2010 at 8:57 AM, Peter Samuelson wrote: > 1) Maybe you wanted to have your software packaged and available on > Debian mirrors, so developers everywhere could install it to > cross-reference their codebases, for local use or for a corporate > intranet. (Do people still use the word intranet?) Packaging is generally best done by the person interested in the software. For more info about getting packages into Debian check out the debian-mentors FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html > 2) Maybe you wanted your site to be linked from some web page, perhaps > www.debian.org/devel/. To get that done, file a bug on the www.debian.org pseudo-package: http://www.debian.org/Bugs/Reporting > 3) Maybe you wanted to obtain a 'debian.net' subdomain, in order to > host something that is Debian-related but not officially part of the > Debian project. I'd be happy to "sponsor" you such a domain, which one would you like? > 4) Maybe you wanted someone else to host the same. I've no machines or time to do that, perhaps someone else on this list is willing and able. > 5) Maybe you wanted the Debian Project to host a copy of your webapp, > indexing all of ftp.debian.org, for general public use. There are/were plans for something similar, see the source.d.o section here: http://dsa.debian.org/hardware-wishlist/ Seems to be waiting on hardware and folks to work on it. There also used to be source.d.n, which ran OpenGrok but the maintainer of it didn't have time to keep it working so I had to "de-sponsor" it. Not exactly a list of yes/no answers but I found your desire for such answers confusing. -- 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: http://lists.debian.org/aanlktim5goitjpqf2ak1p-jzc2iu1asyvziqzqe4a...@mail.gmail.com
RE: suggestion about debian devel extension
You are very smart! Could you or somebody else give me the yes/no answer for the 5 methods? If it depends, depends what? Thanks! > Date: Wed, 7 Jul 2010 19:57:31 -0500 > From: pe...@p12n.org > To: debian-devel@lists.debian.org > Subject: Re: suggestion about debian devel extension > > >>> Do you mean "at debian.org"? > > [j jj] >> Is there any difference between "debian" and "debian.org"? >> The ultimate goal is benefits all developers. > > You could have meant several things: > > 1) Maybe you wanted to have your software packaged and available on > Debian mirrors, so developers everywhere could install it to > cross-reference their codebases, for local use or for a corporate > intranet. (Do people still use the word intranet?) > > 2) Maybe you wanted your site to be linked from some web page, perhaps > www.debian.org/devel/. > > 3) Maybe you wanted to obtain a 'debian.net' subdomain, in order to > host something that is Debian-related but not officially part of the > Debian project. > > 4) Maybe you wanted someone else to host the same. > > 5) Maybe you wanted the Debian Project to host a copy of your webapp, > indexing all of ftp.debian.org, for general public use. > > It seems you wanted 5), but I for one was not able to figure it out > immediately. My first guess was actually 1). > -- > Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ > > > -- > 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/20100708005731.ga3...@p12n.org > _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- 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/col105-w65def4523444397d00a2b1cf...@phx.gbl
Re: suggestion about debian devel extension
> > Do you mean "at debian.org"? [j jj] > Is there any difference between "debian" and "debian.org"? > The ultimate goal is benefits all developers. You could have meant several things: 1) Maybe you wanted to have your software packaged and available on Debian mirrors, so developers everywhere could install it to cross-reference their codebases, for local use or for a corporate intranet. (Do people still use the word intranet?) 2) Maybe you wanted your site to be linked from some web page, perhaps www.debian.org/devel/. 3) Maybe you wanted to obtain a 'debian.net' subdomain, in order to host something that is Debian-related but not officially part of the Debian project. 4) Maybe you wanted someone else to host the same. 5) Maybe you wanted the Debian Project to host a copy of your webapp, indexing all of ftp.debian.org, for general public use. It seems you wanted 5), but I for one was not able to figure it out immediately. My first guess was actually 1). -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20100708005731.ga3...@p12n.org
RE: suggestion about debian devel extension
> Do you mean "at debian.org"? Is there any difference between "debian" and "debian.org"? The ultimate goal is benefits all developers. > Date: Wed, 7 Jul 2010 11:00:01 -0500 > From: ron.l.john...@cox.net > To: debian-devel@lists.debian.org > Subject: Re: suggestion about debian devel extension > > On 07/07/2010 03:51 AM, j jj wrote: >> >> Dear Asheesh. >> >> It is very glad to disscuss with you. >> >> >>> That looks pretty cool! What do you mean by "put it under debian"? >> >> I want to host the website under debian. Because the number of packages in >> debian is huge, it is beyond my capibility to build a website with 1/1000 >> packages in debian. It comes from debian , so it should go under debian. >> This means debian has the full control of the website, even dismissing. >> >> > > Do you mean "at debian.org"? > > -- > Seek truth from facts. > > > -- > 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/4c34a481.1030...@cox.net > _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 -- 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/col105-w4790b8c77c18562aa79691cf...@phx.gbl
Re: suggestion about debian devel extension
On 07/07/2010 03:51 AM, j jj wrote: Dear Asheesh. It is very glad to disscuss with you. That looks pretty cool! What do you mean by "put it under debian"? I want to host the website under debian. Because the number of packages in debian is huge, it is beyond my capibility to build a website with 1/1000 packages in debian. It comes from debian , so it should go under debian. This means debian has the full control of the website, even dismissing. Do you mean "at debian.org"? -- Seek truth from facts. -- 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/4c34a481.1030...@cox.net
RE: suggestion about debian devel extension
Dear Asheesh.
It is very glad to disscuss with you.
> That looks pretty cool! What do you mean by "put it under debian"?
I want to host the website under debian. Because the number of packages in
debian is huge, it is beyond my capibility to build a website with 1/1000
packages in debian. It comes from debian , so it should go under debian. This
means debian has the full control of the website, even dismissing.
> How do you find your system compares to OpenGrok? It'd be good to know
> about advantages of yours.
OpenGrok is the front end of Exuberant Ctags .
For the advantages of mine:
1. Process condition pre compile directive, the uncompiled parts
will be gray.
It is very useful for multi-system packages. Normally the code for
linux, win. freebsd and so on is mess together. Such code will be annoying for
the coder for particular architecture.
2 File included by #include will be identified.
100% garantee is declaimed for #include directive. The wrong result
with same-name file is impossible.
3. The cross reference is accurate.
For example :
Use ctags, you get :
Searched defs:sigcontext (Results 1 -
4 of 4) sorted by null
/ext3/ext2-gate/usr/src/cmd/csh/i386/signal.h 45 struct
sigcontext { struct
/ext3/ext2-gate/usr/src/cmd/csh/sparc/signal.h 44 struct sigcontext {
struct
/ext3/ext2-gate/usr/src/lib/libbc/inc/include/sys/signal.h 160 struct
sigcontext { struct
/ext3/ext2-gate/usr/src/ucbhead/sys/signal.h 290 struct sigcontext { struct
349 void(*sv_handler)(int, int, struct sigcontext *, char *);
For mine, only one result will returned. even multi results are returned,
they link to the same positiion of the same file.
best wishes,
milkway_3
> Date: Wed, 7 Jul 2010 00:25:34 -0400
> From: ashe...@asheesh.org
> To: debian-devel@lists.debian.org
> Subject: Re: suggestion about debian devel extension
>
> On Wed, 7 Jul 2010, milkwa...@hotmail.com wrote:
>
>> As a programmer under debian, I really appriciate the rich debian
>> packages.
>>
>> However, it is not convenient to read and analysis source code, even
>> with emacs and scsope.
>>
>> A litte progress has been acheived after fighting for years. You can
>> test it at http://jp.hostesr.com/.
>>
>> For benefit of all developers, it is best to put it under debian.
>
> That looks pretty cool! What do you mean by "put it under debian"?
>
> Also, have you seen OpenGrok? There was effort to put a code index online
> using that -- see
> http://www.mail-archive.com/debian-devel@lists.debian.org/msg281864.html
> for a little more discussion of that. It's a pretty intense, effective
> code indexer. You can see it live on the OpenSolaris codebase, e.g.
> http://cvs.opensolaris.org/source/xref/ext3/ext2-gate/usr/src/ucblib/libucb/sparc/sys/signal.c
> -- check out how "signal.h" links to the signal.h file that gets used.
>
> How do you find your system compares to OpenGrok? It'd be good to know
> about advantages of yours.
>
> It's good to see that you're interested in making code easier to browse
> through! That is a real need.
>
> -- Asheesh.
>
> --
> A kind of Batman of contemporary letters.
> -- Philip Larkin on Anthony Burgess
>
>
> --
> 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/alpine.deb.2.00.1007070013130.8...@rose.makesad.us
>
_
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
--
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/col105-w25608ccf6f1d116e862baecf...@phx.gbl
Re: suggestion about debian devel extension
On Wed, 7 Jul 2010, milkwa...@hotmail.com wrote: As a programmer under debian, I really appriciate the rich debian packages. However, it is not convenient to read and analysis source code, even with emacs and scsope. A litte progress has been acheived after fighting for years. You can test it at http://jp.hostesr.com/. For benefit of all developers, it is best to put it under debian. That looks pretty cool! What do you mean by "put it under debian"? Also, have you seen OpenGrok? There was effort to put a code index online using that -- see http://www.mail-archive.com/debian-devel@lists.debian.org/msg281864.html for a little more discussion of that. It's a pretty intense, effective code indexer. You can see it live on the OpenSolaris codebase, e.g. http://cvs.opensolaris.org/source/xref/ext3/ext2-gate/usr/src/ucblib/libucb/sparc/sys/signal.c -- check out how "signal.h" links to the signal.h file that gets used. How do you find your system compares to OpenGrok? It'd be good to know about advantages of yours. It's good to see that you're interested in making code easier to browse through! That is a real need. -- Asheesh. -- A kind of Batman of contemporary letters. -- Philip Larkin on Anthony Burgess -- 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/alpine.deb.2.00.1007070013130.8...@rose.makesad.us
suggestion about debian devel extension
As a programmer under debian, I really appriciate the rich debian packages. However, it is not convenient to read and analysis source code, even with emacs and scsope. A litte progress has been acheived after fighting for years. You can test it at http://jp.hostesr.com/. For benefit of all developers, it is best to put it under debian. This is my seggestion. _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
Re: Suggestion to developer tools
On Thu, 18 Mar 2010 23:32:27 +0100, ceduardo wrote: Hi every body, thaks you for your suggestions. Well I am learning about C, C++ and Linux programing, jeje I am trying to be a Debian developer this is my objetive. On my practices use emacs and others tools from console. What Do you developer tools sugges? vim + ctags + git (My personal favorite combo). Regards, Tilo -- 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/op.vabpe6m3a8e...@dellschleppa
Re: Suggestion to developer tools
On Fri, Mar 26, 2010 at 05:04:08PM -0500, ceduardo wrote: > 2010/3/25 Brian Ryans : > > Quoting ceduardo on 2010-03-18 17:32:27: > >> What Do you developer tools sugges? > > If you use emacs for editing try its integration with gdb for debugging. I like it. As a way to manage your source I think the best tool to learn are: cmake and git. Bye Stefano -- Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it Three great virtues of a programmer: laziness, impatience and hubris. Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall) signature.asc Description: Digital signature
Re: Suggestion to developer tools
You mistakenly replied to me instead of to the list. I'll fix that. Quoting ceduardo on 2010-03-26 17:04:08: > Thanks, this more information to my objetive. I am from Colombia, my > native language is spanish. I don't know why I said Portuguese instead of Spanish. Brain fart on my part, likely. I'm unsure about where to get a copy of TAOUP in Spanish. Maybe regulars of debian-devel-spanish would know where to get such, if it even exists? I searched Google and nothing came up for a Spanish copy. -- _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org / \ Any technology distinguishable from magic is insufficiently advanced signature.asc Description: Digital signature
Re: Suggestion to developer tools
2010/3/25 Brian Ryans : > Quoting ceduardo on 2010-03-18 17:32:27: >> What Do you developer tools sugges? > > Not a piece of software proper, but I, too, am learning programming and > have found the book "The Art of Unix Programming" by Eric S. Raymond to > be quite invaluable. I don't have an ISBN, as I have the PDF version, > but a google for 'taoup.pdf site:catb.org' should yield something. > Unsure if it's been translated to Portugese though. > Thanks, this more information to my objetive. I am from Colombia, my native language is spanish. > Offtopic: I'm looking for a place where I can buy the paper copy using > cash or money order. > >> PD: I sorry but my english is very bad, I am learning too. > > Hey, it's better than that of some native English speakers I know :) Wow thank you > > -- > _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . > ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: > X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org > / \ Any technology distinguishable from magic is insufficiently advanced > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkusFKsACgkQCtCwFMESE9Do2gCeNPRgAv1hGQD20YojG3kLIcmE > 8gUAoIaxE4jdL4FsPfLg1w8jqyHEMpOT > =4JFA > -END PGP SIGNATURE- > > -- ceduardo -- 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/c068e3701003261504g66573289r6e3e726027ca3...@mail.gmail.com
Re: Suggestion to developer tools
Quoting ceduardo on 2010-03-18 17:32:27: > What Do you developer tools sugges? Not a piece of software proper, but I, too, am learning programming and have found the book "The Art of Unix Programming" by Eric S. Raymond to be quite invaluable. I don't have an ISBN, as I have the PDF version, but a google for 'taoup.pdf site:catb.org' should yield something. Unsure if it's been translated to Portugese though. Offtopic: I'm looking for a place where I can buy the paper copy using cash or money order. > PD: I sorry but my english is very bad, I am learning too. Hey, it's better than that of some native English speakers I know :) -- _ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 . ( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com ..: X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org / \ Any technology distinguishable from magic is insufficiently advanced signature.asc Description: Digital signature
Re: Suggestion to developer tools
ceduardo wrote: > The powerfull, vi, vim, gcc, g++, gdb and the others that I don't know > in this moment. Every C and C++ programmer should use Valgrind, often. Static analysis tools like cppcheck and flawfinder are also useful. All of these tools are available in debian main. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- 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/20100320173303.9da4c3d7.mle+deb...@mega-nerd.com
Re: Suggestion to developer tools
On Thu, 2010-03-18 at 22:12 -0500, ceduardo wrote: > > I wanted to know aobut the typicals develoment toolt that you use. > I mainly use eclipse or gedit or a command line text editor (Depending on my mood) I suggest you learn how to use these as well, they allow for much customization. > > I have Eclipse installed but I don't use this for C/C++, but It is a > good idea to try with this one. I am testing NetBeans IDE but I want > to know your suggestions. I prefer Eclipse over NetBeans for all of my development because I feel that NetBeans is a bit to "bloaty" As I said, this is a matter of preference. I can't really tell you what you will like best ;) -- Luke Cycon signature.asc Description: This is a digitally signed message part
Re: Suggestion to developer tools
2010/3/18 Luke Cycon : > On Thu, 2010-03-18 at 17:32 -0500, ceduardo wrote: >> Hi every body, thaks you for your suggestions. >> >> Well I am learning about C, C++ and Linux programing, jeje I am trying >> to be a Debian developer this is my objetive. On my practices use >> emacs and others tools from console. >> >> What Do you developer tools sugges? > > *If* I understand what you are asking (For suggestions for development > tools), you have got some of the main ones. I wanted to know aobut the typicals develoment toolt that you use. > When I need/want a nice GUI for when I am feeling lazy, I use Eclipse > (Available in the repos, though there are newer version out there). I have Eclipse installed but I don't use this for C/C++, but It is a good idea to try with this one. I am testing NetBeans IDE but I want to know your suggestions. > Other than that, a nice console text editor and the compiler (In C/C++'s > case) is a very powerful development environment. > The powerfull, vi, vim, gcc, g++, gdb and the others that I don't know in this moment. > All in all, it is a matter of choice. Do you like a more GUI-centric > style of programming? Or are you comfortable using command line tools? > > Again, sorry if I misunderstood the question. > Don't worry your message can help me in my way > (I am CCing you on the off chance that you may not be subscribed to this > list, sorry if you are (Somewhat of a generalization, I see many of > these questions asked by people not subscribed to the list.)) > > Thanks, > -- > Luke Cycon > > Thanks. -- ceduardo -- 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/c068e3701003182012m57524ad3h86fe4abe617ee...@mail.gmail.com
Re: Suggestion to developer tools
On Thu, 2010-03-18 at 17:32 -0500, ceduardo wrote: > Hi every body, thaks you for your suggestions. > > Well I am learning about C, C++ and Linux programing, jeje I am trying > to be a Debian developer this is my objetive. On my practices use > emacs and others tools from console. > > What Do you developer tools sugges? *If* I understand what you are asking (For suggestions for development tools), you have got some of the main ones. When I need/want a nice GUI for when I am feeling lazy, I use Eclipse (Available in the repos, though there are newer version out there). Other than that, a nice console text editor and the compiler (In C/C++'s case) is a very powerful development environment. All in all, it is a matter of choice. Do you like a more GUI-centric style of programming? Or are you comfortable using command line tools? Again, sorry if I misunderstood the question. (I am CCing you on the off chance that you may not be subscribed to this list, sorry if you are (Somewhat of a generalization, I see many of these questions asked by people not subscribed to the list.)) Thanks, -- Luke Cycon signature.asc Description: This is a digitally signed message part
Re: Suggestion to developer tools
Hi Carlos. Excerpts from ceduardo's message of Qui Mar 18 19:32:27 -0300 2010: (...) > Well I am learning about C, C++ and Linux programing, jeje I am trying > to be a Debian developer this is my objetive. On my practices use > emacs and others tools from console. > > What Do you developer tools sugges? > > Thanks > > PD: I sorry but my english is very bad, I am learning too. I could not understand what you are asking. Do you speak portuguese? Maybe you want to join debian-devel-portugu...@lists.debian.org . If not, you can search for a development list in your language in http://lists.debian.org/devel.html . Greetings. (...) -- marcot http://wiki.debian.org/MarcoSilva -- 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/1268953772-sup-3...@zezinho
Suggestion to developer tools
Hi every body, thaks you for your suggestions. Well I am learning about C, C++ and Linux programing, jeje I am trying to be a Debian developer this is my objetive. On my practices use emacs and others tools from console. What Do you developer tools sugges? Thanks PD: I sorry but my english is very bad, I am learning too. -- ceduardo -- 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/c068e3701003181532g79d476a4g497a49fc9ed84...@mail.gmail.com
Re: [Suggestion] Reject Mail to ITP Bug
Thomas Viehmann <[EMAIL PROTECTED]> writes: > Personally, I'm not sure that I'd be too excited to have reject mails > archived on the BTS when I'm on the receiving end, but I guess that's > just me. In most of the cases they would seem to add little value to the > ITP bug. Well, they would be pretty useful for the case that the package is team maintained and the uploader fails or forgets to forward the reject mail somewhere useful. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Suggestion] Reject Mail to ITP Bug
Roberto C. Sánchez wrote: That can be easily determined by looking in the .changes for the "closes" field. If more than one, you can check to see which has "ITP" in the title. If there is no closes, then assume that there is no ITP and that's it. I would suggest you always check for which one has ITP in the title. Otherwise it might not be an ITP bug at all. Even if it is a "new" source package. Or it might be an ITP for the wrong package. Maybe need to check the package name too. Maybe the uploader mistyped the bug number. This in turn might be the reason it was rejected. Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Suggestion] Reject Mail to ITP Bug
On Tue, Aug 26, 2008 at 8:37 PM, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
> How about BCC'ing the reject mail to a mailing list with a public,
> web-browsable archive?
Yes, even publicly available report is also fine.
--
Cheers,
Kartik Mistry | 0xD1028C8D | IRC: kart_
Homepage: people.debian.org/~kartik
Blogs: {ftbfs,kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
