Re: Malloc and security
In fact I didn't send it to both, I resent twice, a mistake as I thought the first email hadn't sent properly. Jamir Sent from my BlackBerry® smartphone on O2 -Original Message- From: Dmitrijs Ledkovs Sender: Dmitrijs Ledkovs Date: Mon, 18 Jun 2012 21:40:52 To: Cc: Subject: Re: Malloc and security On 18/06/12 21:11, Jamie White wrote: > Hiya > > Just a quick question, which malloc, is there anyway that this function > (used in C) could allocate memory into already allocated memory, such as > the stack - or code space! > > Jamie > > Cross posting offtopic email to two mailing lists (ubuntu-devel and debian-devel) is not nice. If you want quicker response times IRC would have been more appropriate. -- Regards, Dmitrijs. -- 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/4fdf9254.5080...@debian.org
Re: Feedback
Merry Christmas to you also. Incidently, I haven't written any the documentation. Jamie Sent from my BlackBerry® smartphone on O2 -Original Message- From: Mistikos Nik Date: Tue, 25 Dec 2012 22:50:57 To: Subject: Feedback Debian documentation is a joke. It constantly refers to Debian versions by their nick names, and not their versions. If I am new to Debian and go to read the manual and I see 'Squeeze', do you think I am going to know what the fuck that means? No, but if Debian actually used the official name, then it would fall in line with conistency. I.E documentation for 'Debian 6'. People outside the development circle arn't going to know what Debian jargon. This is a classic case of computer nerds lacking social skills. If you don't have good documentation, then the product isn't going to get used. Debian use to be really popular. Now only old people use it. Why because new comers will choose a well documented distro over one that doesn't make sense. Life is too short to fuck around. Merry Christmas! -- 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/3481651356439...@web15g.yandex.ru
Re: Feedback
Anyway, more to point, if you find the format of documentation, hard to work and perhaps fustrating, you seemed irritable, perhaps firstly best calm down before writing such an email. Your email only had as far as I could make out had only one constructive point, and a tirade of insults. Its only going to annoy people, it would be a lot better to go into more constructive detail about what you find makes it difficult. Jamie Sent from my BlackBerry® smartphone on O2 -Original Message- From: ja...@jatos.co.uk Date: Tue, 25 Dec 2012 13:17:40 To: Mistikos Nik; Reply-To: ja...@jatos.co.uk Subject: Re: Feedback Merry Christmas to you also. Incidently, I haven't written any the documentation. Jamie Sent from my BlackBerry® smartphone on O2 -Original Message- From: Mistikos Nik Date: Tue, 25 Dec 2012 22:50:57 To: Subject: Feedback Debian documentation is a joke. It constantly refers to Debian versions by their nick names, and not their versions. If I am new to Debian and go to read the manual and I see 'Squeeze', do you think I am going to know what the fuck that means? No, but if Debian actually used the official name, then it would fall in line with conistency. I.E documentation for 'Debian 6'. People outside the development circle arn't going to know what Debian jargon. This is a classic case of computer nerds lacking social skills. If you don't have good documentation, then the product isn't going to get used. Debian use to be really popular. Now only old people use it. Why because new comers will choose a well documented distro over one that doesn't make sense. Life is too short to fuck around. Merry Christmas! -- 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/3481651356439...@web15g.yandex.ru
Re: Feedback
I guess by twelve year old trolls, you refer to Mistikos?
To be honest, I am not sure I'd respond to him/her like that, they do not just
seem like a troll.
However they seem like someone who perhaps needs to think before they talk, and
spend more time explaining what is bothering them
Jamie
Sent from my BlackBerry® smartphone on O2
-Original Message-
From: Jeremy Stanley
Date: Tue, 25 Dec 2012 13:51:17
To:
Subject: Re: Feedback
On 2012-12-25 22:50:57 +1000 (+1000), Mistikos Nik wrote:
[...]
> Debian use to be really popular. Now only old people use it.
[...]
I suddenly feel very old. What distribution do twelve-year-old
trolls use these days, if not Debian? Have we lost our key
demographic?
--
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kin...@katarsis.mudpy.org:6669 );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl ); }
--
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/20121225135117.gq6...@yuggoth.org
Re: feedback
Your logic is inherently flawed. Fact is, if you do you research you will find that Ubuntu is built from Debian, thus is a form of it. Reality is Ubuntu when it first came was very little more than a version of Debian packaged to be easier to use and install, and slowly is has gained more unique features and characteristics to extent where Ubuntu is somewhat more distinct. However, you get under the hood, you still will find it has the debian base. Everytime you install package in Ubuntu, is installed using the Debian package manager! Ubuntu is a form of Debian your f.. a...h..e. Ubuntu you may find easier to use, but it relies on Debian base to be what it is. So stop throwing abuse at people who make what you use possible, because that's exactly what you are doing criticising and abusing the Debian developers! If I could I would personally ensure that you had no access to anything Debian developers have created for you're idiotic and ignorant attitudes, and if I did that, it would mean you had no Ubuntu, would be such a shame, er not! Jamie Sent from my BlackBerry® smartphone on O2
Re: Feedback
I didn't thought the use of codenames was hardly unique to Debian, remember Windows Longhorn? Also remember Windows XP, the practice he moans about is used in a form by the worlds most used OS. Also... Does Ubuntu not use names such as Dapper and Breezy? I think this guy is just too thick to understand the documentation, or perhaps too lazy. Sent from my BlackBerry® smartphone on O2
Re: Feedback
Do remember we have found this guy out to be a troll, so he was probably not on the whole trying to make much in the way of constructive comment. Although I think it is wise to include version numbers with version names often enough to create a clear understanding of the different versions. Jamie P.s. Please excuse the top loading, I can't do it differently on a BB. Sent from my BlackBerry® smartphone on O2 -Original Message- From: olivier sallou Date: Sun, 30 Dec 2012 09:42:03 To: Cc: Subject: Re: Feedback Le 25 déc. 2012 14:09, "Mistikos Nik" a écrit : > > Debian documentation is a joke. It constantly refers to Debian versions by their nick names, and not their versions. > Such version naming does not reduce the global quality and quantity of our doc, even if it could of course be improved. > If I am new to Debiannd go to read the manual and I see 'Squeeze', do you think I am going to know what the fuck that means? No, but if Debian actually used the official name, then it would fall in line with conistency. I.E documentation for 'Debian 6' Not sure people will rather know which version number is current one but I agree that version numbering is easier to follow history of features Doc could refer to both. When I install Ubuntu, I usually remember more easilly its version number than its name > > People outside the development circle arn't going to know what Debian jargon. > > This is a classic case of computer nerds lacking social skills. If you don't have good documentation, then the product isn't going to get used. If documentation is important I don't think it is related to the distro choice. I don't think so many people have read the Ubuntu or Mac OS one. Doc is often used as helpers when somethIng is wrong and Debian offers lots of thing in its wiki for this plus internet contributions of course > Debian use to be really popular. Now only old people use it. Why because new comers will choose a well documented distro over one that doesn't make sense. Life is too short to fuck around. > Doc is a work that anyone can contribute to, so I think you are welcome to help us improve it:-) Olivier > > Merry Christmas! > > > -- > 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/3481651356439...@web15g.yandex.ru >
Bug#348625: ITP: puppet -- centralised configuration management for networks
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson <[EMAIL PROTECTED]> * Package name: puppet Version : 0.11.1 Upstream Author : Luke Kanies <[EMAIL PROTECTED]> * URL : http://reductivelabs.com/projects/puppet/ * License : GPL Description : centralised configuration management for networks Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. Puppet's simple declarative specification language provides powerful classing abilities for drawing out the similarities between hosts while allowing them to be as specific as necessary, and it handles dependency and prerequisite relationships between objects clearly and explicitly. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304270: ITP: libfishsound -- simple programming interface that wraps Xiph.Org audio codecs
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson <[EMAIL PROTECTED]> * Package name: libfishsound Version : 0.6.3 Upstream Author : Conrad Parker <[EMAIL PROTECTED]>, Silvia Pfeiffer <[EMAIL PROTECTED]> Zentaro Kavanagh <[EMAIL PROTECTED]> * URL : http://annodex.net/software/libfishsound * License : BSD style Description : simple programming interface that wraps Xiph.Org audio codecs libfishsound is a wrapper around the existing codec libraries and provides a consistent, higher-level programming interface. It has been designed for use in a wide variety of applications; it has no direct dependencies on Annodex or Ogg encapsulation, though it is most commonly used in conjunction with liboggz to decode or encode Ogg encapsulated Vorbis or Speex files. The full text of the License and Copyright is as follows: Copyright (C) 2003 CSIRO Australia Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of the CSIRO nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE ORGANISATION OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364976: ITP: facter -- a library for retrieving facts from operating systems
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson <[EMAIL PROTECTED]> * Package name: facter Version : 1.1.4 Upstream Author : Luke Kanies <[EMAIL PROTECTED]> * URL : http://reductivelabs.com/projects/facter * License : GPL Programming Lang: Ruby Description : a library for retrieving facts from operating systems A cross-platform Ruby library for retrieving facts from operating systems. Supports multiple resolution mechanisms, any of which can be restricted to working only on certain operating systems or environments. Facter is especially useful for retrieving things like operating system names, IP addresses, MAC addresses, and SSH keys. . It is easy to extend Facter to include your own custom facts or to include additional mechanisms for retrieving facts. puppet (#348625) depends on facter. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366328: ITP: bsp -- nodes builder for doom-engine levels
On Sun, 2006-05-07 at 16:59 +0200, Pierre Habouzit wrote: > Le Dim 7 Mai 2006 15:07, Jon Dowland a écrit : > > BSP is a tool for calculating the Binary Space Partition > > (BSP) for doom-engine levels. The result is stored in the > > NODES lump for the level. Levels need a NODES lump in order > > to be playable. > > . > > BSP also exploits some corner-cases of the doom rendering > > engine to provide special effects such as transparent doors. > > G'day Jon, How does this compare to Zennode ( http://www.mrousseau.org/programs/ZenNode/ ) ? or glBSP ( http://glbsp.sourceforge.net/ and .debs are http://www.youmustbejoking.demon.co.uk/progs.sarge.html#glbsp )for node building ? Regards, -- Jamie Jones Proprietor E-Yagi Consulting ABN: 32 138 593 410 Mob: +61 4 16 025 081 Email: [EMAIL PROTECTED] Web: http://www.eyagiconsulting.com GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Very uneven distribution of packages per maintainer
This one time, at band camp, Petter Reinholdtsen wrote: >Packages Developers Looks like a normal distribution curve in gnuplot. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Debian Weekly News - June 3rd, 2003
This one time, at band camp, Martin Schulze wrote: >Flaming with Jamie Zawinski. Slow news day, Joey? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: package name change (moviemate -> mediamate)
This one time, at band camp, Sean 'Shaleh' Perry wrote: >you should Conflict, Replace, and provide MovieMate. This will ensure a >smooth transition. You instead (may) want to upload a package called >moviemate which is a dummy package that depends on MediaMate. You should do both, with the Conflict/Replace versioned to match all versions earlier than this one, for the smoothest transition. Take it from someone who suffered various forms of dependency bugs by trying the minimum amount of effort required to properly change package names. See the glut source package control file for more details. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Searching for Angus Lees
This one time, at band camp, Colin Walters wrote: >If someone here knows an alternate email address for Angus, could you >resend this message there? Thanks. Done. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: configure web proxy via DHCP server
This one time, at band camp, Russell Coker wrote: >The ideal solution however would be an addition to the DHCP standard for a >field to specify this information. My solution only works AFTER I have >figured out the correct data for each network by some other means and >customised my script. SRV records? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: "non-free" software included in contrib
This one time, at band camp, Bruce Sass wrote: >Exactly. What if a generalised DFSG-free software installer used a >separate config file to download, debianize (using dh_make templates), >then install the resulting package (most of it non-free because such a >scheme should not be necessary for free stuff)... imo, the installer >would go in main and the config/templates would go into contrib or >non-free. Wow, you just described my ideas for game-installer, a package that should eventually replace quake2-data (among others), just as soon as I get some more round tuits. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)
On Fri, 2005-07-22 at 12:12 +0100, Jon Dowland wrote: > On Fri, Jul 22, 2005 at 12:20:45AM +0200, Alexander Fieroch wrote: > > Package: wnpp > > Severity: wishlist > > > > URL: http://www.doomsdayhq.com/index.php > > License: GPL (see http://sourceforge.net/projects/deng) > > > > Description: > > > > About The Doomsday Engine > > The Doomsday Engine is an enhanced and extended version of DOOM, > > Heretic, and Hexen. It was originally based on the Hexen source code but > > parts of it have later been completely rewritten. Doomsday is only an > > engine; you will need a Game DLL if you want to play anything. Three > > such DLLs are being developed alongside the engine: jDoom, jHeretic and > > jHexen. > > I object to doomsday being packaged. The heretic/hexen source code > licence is utterly incompatible with the GPL, making this package > technically illegal. It is also very much against the DFSG. See > <http://bugs.debian.org/264816> for a similar bug against the existing > package for doom legacy. > > You could arguably only package the engine + doom library portions, but > I don't know how much of the heretic/hexen code has made its way into > those components (if any). > > I am currently trying to start negotiations with the publisher of > heretic/hexen to relicence under the GPL; this would be the ideal > solution to this problem (which applies to doomlegacy as alreay > mentioned, doomsday, the derivative risen3d, another port called vavoom: > unfortunately, virtually all the doom ports have disregarded the GPL > in one way or another :( ) anyone interested in progress updates > should mail me. > G'day Jon, As the unofficial maintainer for the past 6 months, I'd like to chime in here. The current version can be built without raven code rather easily so it could be made DFSG free with no major loss of functionality. The fact that no attempt has been made to contact me, when I'm listed in the official wiki, and present in the official forums announcing new release is disturbing. Us non-DD's don't like having our packages hijacked either, especially when we are preparing a new release. In this case no raven code is in the engine, and the doom or heretic plugins, only the hexen plugin is affected. Regards Jamie Please CC me for a prompt reply, as I read this list as a digest. -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)
On Fri, 2005-07-22 at 22:00 +0100, Jon Dowland wrote: > On Sat, Jul 23, 2005 at 04:13:30AM +1000, Jamie Jones wrote: > > G'day Jon, > > > > As the unofficial maintainer for the past 6 months, I'd like to chime in > > here. The current version can be built without raven code rather easily > > so it could be made DFSG free with no major loss of functionality. > > Glad to hear it. In the case of legacy, it's not so clear - and with > their re-write to C++ code, will be nigh-on impossible, so GPLed > heretic/hexen code is the only way out. > > > The fact that no attempt has been made to contact me, when I'm listed in > > the official wiki, and present in the official forums announcing new > > release is disturbing. Us non-DD's don't like having our packages > > hijacked either, especially when we are preparing a new release. > > I gather you mean the wiki/forum for the doomsday project and not > Debian. I'm suitably out of touch that I wasn't aware doomsday was > available for GNU/Linux natively, yet - I suppose this is what the ITP > process is for. > > 'Hijack' seems a bit strong - I can't find an ITP from you - do you ever > intend to submit your package to debian officially? After sleeping on it, yes hijack does seem a bit strong, but after a bad day, then downloading my mail to see an ITP on a package that has been kept out for a reason, I felt rather unhappy. > > > In this case no raven code is in the engine, and the doom or heretic > > plugins, only the hexen plugin is affected. > > I'll have to take your word for it on the engine, but surely raven code > is in the heretic plugin? > See for yourself, grab my package or upstreams tarball and grep for Raven. Most of the Raven code is from Heretic 2 and Hexen 2 anyway. Doomsday (or Deng as upstream and I refer to it) is the cleanest implementation in regards separation of the different game logic and features. The plugins are basically .so files, so if you want to play doom, you load the jdoom plugin, you want hexen, you load the jhexen plugin. The problem with legacy and the other ports mentioned is that this logic wasn't separated so that they could function without the raven code. The biggest problem is that many new wads (game levels) support hexen features in a doom wad (I believe that they call this zdoom format). By supporting zdoom format and not using a plugin they then fail the DFSG test with regards to the raven code. Deng doesn't even support Boom format (an extension to the GPL Doom wad format) that was the cause for a fork some time ago. Regards Jamie For anyone wanting to actually try the game to see what all the fuss is about, http://eyagi.bpa.nu/~jamie/doomsday.html has details on just exactly what is packaged and how to get it. -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: doomsday not DFSG
On Sat, 2005-07-23 at 18:31 +0100, Jon Dowland wrote: > > Doomsday (or Deng as upstream and I refer to it) is the cleanest > > implementation in regards separation of the different game logic and > > features. The plugins are basically .so files, so if you want to play > > doom, you load the jdoom plugin, you want hexen, you load the jhexen > > plugin. > > That's true. The heretic/hexen licence terms are so strict as to make > even this dodgy, but if the code was excluded from Debian, it wouldn't > be Debian's problem. I expect this confusion would have been avoided if > the upstream author didn't classify the entirety of the code as GPL in > sourceforge.net. True. I have raised this with upstream in the past and they are aware of the issue. We would prefer to include it with full functionality, but with the current codebase it is impossible. Upstream has stated that with the current code it would be more trouble then it is worth to redo the hexen plugin without the raven code, especially as the current codebase is more of a prototype to them of what they want their version 2 engine to be. I'm sure though, that if someone had patches they would be happy to include it. > > > The problem with legacy and the other ports mentioned is that this logic > > wasn't separated so that they could function without the raven code. > > Yes I know :( I've tried to persuade the upstream maintainers but it has > unfortunately been to no avail. The legacy maintainers are some of the > most polite, however: I received some pretty angry mail from some of the > others. Sadly that is the case, part of the reason I ended up doing Deng, was that upstream was much more approachable about these sorts of things. > > > The biggest problem is that many new wads (game levels) support hexen > > features in a doom wad (I believe that they call this zdoom format). > > By supporting zdoom format and not using a plugin they then fail the > > DFSG test with regards to the raven code. > > I only know of Zdoom that uses this different WAD structure (maybe > vavoom does too, not too familiar with that port). However, zdoom > implemented that *before* the heretic/hexen source code release. Despite > this, I think that there is no interest in relicencing under the GPL in > the zdoom camp. Really, Zdoom did that before the hexen release ? As I understand it, I thought Zdoom format was basically hexen in a doom container. > > > Deng doesn't even support Boom format (an extension to the GPL Doom > > wad format) that was the cause for a fork some time ago. > > Yup Risen3D - which is closed source :-( I understand that there is work > on putting boom support into Jdoom now - about time! (as an upstream > author of freedoom, I've had to field many questions about jdoom and > boom over the years) > Yeah, Skyjake has given DaniJ CVS access, and now DaniJ is working on some Boom stuff. I'm looking forward to the freedoom support myself, as it's something I'd like to play. Every time they release something, I happily break it in new and exiting ways (I already broke it on amd64, I just wish I could put it through all of Debian's arches to see what it breaks on) -- GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments PGP Key ID 0x4B6E7209 Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209 signature.asc Description: This is a digitally signed message part
Re: Bug#324179: ITP: quake3 -- a famous first person shooter by ID-Software
Hi! I only just found this ITP; I've been working on a debian/ dir for icculus.org's quake3 branch for a few weeks. Also in the pipeline is a quake3-data that doesn't suck as much as quake2-data... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
including full package source code in the debian release
Hi, Debian releases have 25,000 or so packages and don't include the source to them, so to recompile the package you use apt-get to connect to the internet and download the source to one package at a time if you want the source code. I did some calculations to see how much bulk adding the package source code to the debian release would add and using high compression it appears that it would increase the overall release size by less than 1%. Most users won't care or benefit from having the source code to these 25,000 packages included in the distribution, but some will probably like the ability to be able to have this source code and be able to recompile packages without requiring internet access to download package source code. Here are my calculations, they are rough estimates: packages included in Debian 4.0 etch (283 million lines of code) source: http://en.wikipedia.org/wiki/Debian assuming 32KB per 1000 lines of code, this would be about 8.6GB for 283 million lines of code. assuming a factor of 100 for the compression of this code, this would give approx 88MB of extra space required in the debian distribution for all of this source code. the total size of the current full Debian distribution is over 18GB: http://cdimage.debian.org/debian-cd/5.0.4/i386/iso-dvd/ so including compressed package source code would have a very minor impact on the overall file size of the debian release. cheers, Jamie
Re: including full package source code in the debian release
- Original Message - From: Josselin Mouette Date: Sunday, March 7, 2010 12:57 am Subject: Re: including full package source code in the debian release To: Jamie Morken Cc: debian-devel@lists.debian.org > There are two little flaws in your reasoning. > 1. Compression ratios, even for source > code, don’t reach 99%. Hi, I have seen some 7zip archives that can get up to a compression factor over 100 (ie. large wikipedia database dumps: enwiki-20080103-pages-meta-history.xml.7z 18GB enwiki-20080103-pages-meta-history.xml 2.8TB! Maybe this high compression is due to the xml repeating markup's in addition to the large file size, not sure though, but it is impressive compression. > 2. There are other very little things > in source packages, such as, > I don’t know… data? > > http://cdimage.debian.org/debian-cd/5.0.4/source/iso-dvd/ > > The overall size of the full compressed sources is 17 GB. Tell > me this > has only a minor impact. I forgot to consider images/data etc. Thanks for the clarification. cheers, Jamie > > -- > .''`. Josselin Mouette > : :' : > `. `' “I recommend you to learn English in hope that > you in > `- future understand > things” -- Jörg Schilling > >
Bug#609625: ITP: nsscache -- asynchronously synchronise local NSS databases with remote directory services
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson * Package name: nsscache Version : 0.19 Upstream Author : Jamie Wilkinson * URL : http://code.google.com/p/nsscache * License : GPL Programming Lang: Python Description : asynchronously synchronise local NSS databases with remote directory services Synchronises local NSS caches, such as those served by the libnss-cache module, against remote directory services, such as LDAP, or prebuild cache files from an HTTP server. This can be used alongside the libnss-cache package to keep user account information, groups, netgroups, and automounts up to date. Use of nsscache and libnss-cache eliminates the need for using a cache daemon such as nscd with networked NSS modules such as libnss-ldap. -- System Information: Debian Release: 5.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20110111013237.20290.71128.report...@li155-175.members.linode.com
Bug#609626: ITP: libnss-cache -- NSS module for using local cache files as a naming service
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson * Package name: libnss-cache Version : 0.10 Upstream Author : Jamie Wilkinson * URL : http://code.google.com/p/nsscache * License : GPL Programming Lang: C Description : NSS module for using local cache files as a naming service Provides a Name Service Switch module that allows you to use local cache files, such as those created by the nsscache utility, to act as a name service. This means providing user account information, groups, netgroups, and automounts in a file separate to, say, /etc/passwd, that can be kept synchronised with a directory server without interfering with local account customisations. Use of nsscache and libnss-cache eliminates the need for using a cache daemon such as nscd with networked NSS modules such as libnss-ldap. -- System Information: Debian Release: 5.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20110111013628.20311.9241.report...@li155-175.members.linode.com
Re: status of Progeny projects
This one time, at band camp, Ian Murdock wrote: >We have ported Red Hat's Anaconda installer to Debian; This rocks. I have an extensive PXE+kickstart based server build system at work and I was considering hacking d-i to read a kickstart configuration file, this looks like it's saved me the trouble. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Eduard Bloch wrote: >The fact of the too generic package name was mentioned before within >other arguments against your "linux" package. IIRC you prefered not to >answer to it but refered to an URL which did not contain the answers. 'linux' is a perfect name for the package. The tarballs contain that very name. >> 2) I use the upstream name. If you don't like it, bitch upstream. > >Sorry, how much did you drink to find an answer like this one? If Linus >changes the package name (which is unlikely to happen ;)), I am sure you >would rename your ITP to follow him. Are you implying that you make up names for the software that you package, rather than use the name given to it by upstream? I believe you don't. Given that there's a possibility that Debian will include non-linux kernels in the future. In that case, calling the linux kernel package 'kernel-image' doesn't give a lot of room for the other kernels to live in. Calling the package 'linux' makes it pretty clear which software it is packaging. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Eduard Bloch wrote: >You repeat this again and again and got answers from me and others to >such an ultimate argument. But did you ask yourself why Herbert does not >participiate this discussion to help you? Why does the lack of response from Herbert prove that this package is a bad idea? I'm saddened that you have to revert to intimidation in place of a technical argument. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Matthew Garrett wrote: >Robert Millan wrote: > >>But someone claimed there are critical problems with System.map in the way >>my package is upgraded, which is not the case. > >If I get a new linux package after doing apt-get ugprade which replaces >the one for my running kernel, then System.map and the kernel are going >to be out of sync until I reboot. Which would be bad. I do not expect Robert's package to make any more of an attempt to convince you a reboot is required than any of the other kernel packages. I quote from the postinst generated by kernel-package: I repeat: you have to reboot in order for the modules file to be created correctly. Until you reboot, it may be impossible to load some modules. Reboot as soon as this install is finished (Do not reboot right now, since you may not be able to boot back up until installation is over, but boot immediately after). I can not stress that too much. You need to reboot soon. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Marcelo E. Magallon wrote: > > > * A package which requires a reboot on updates > > > > Oh, now I'm suposed to fix that, too? Bitch upstream for a run-time > > updatable Linux kernel. > > ROTFL > > That's not the point, I thought that was obvious, sorry. The point is > how do you guarantee that this reboot is going to happen? How do the current kernel packages guarantee this? Why would Robert's package need to behave any differently? However, I do think your questions make very intersting challenges for this project. I do not expect Robert to have all the answers for them just now, but with some experimentation we can hope to find them. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)
This one time, at band camp, Eduard Bloch wrote: >#include >* Jamie Wilkinson [Mon, Nov 10 2003, 06:54:22PM]: > >> >The fact of the too generic package name was mentioned before within >> >other arguments against your "linux" package. IIRC you prefered not to >> >answer to it but refered to an URL which did not contain the answers. >> >> 'linux' is a perfect name for the package. The tarballs contain that very >> name. > >Note that the name is choosen not only to attract the user, but also to >catch that who blindly use "apt-get source linux". The user wouldn't get >the well-known and good kernel-source packages but something which is >under control of Robert. Further, what they would get is not a clean >source but something with debian/ dir inside which would confuse >make-kpkg. I would not mind if he had called it "linux-rmh" or such. I do not understand your point, you are trying to protect users who inadvertently type "apt-get source linux"? When I type "apt-get source pppoeconf", do I not get the source to the Debian package of ppoeconf? Why should it be any different? I'm not convinced that people type "apt-get source x" inadvertently either. Your second sentence is flagrant abuse, and its tone seems common in your attempts at constructing a reasoned argument. Please try to keep civil, Eduard. I trust your ability to maintain your packages, as I trust everyone else in this project, at least until I see the product of their work. Confusing make-kpkg would be an issue, I suppose -- given that one could want to get any kernel source and build it with the tools they're familiar with. If it were me, I'd make sure to include some extra information in the package README. >> >> 2) I use the upstream name. If you don't like it, bitch upstream. >> > >> >Sorry, how much did you drink to find an answer like this one? If Linus >> >changes the package name (which is unlikely to happen ;)), I am sure you >> >would rename your ITP to follow him. >> >> Are you implying that you make up names for the software that you package, >> rather than use the name given to it by upstream? I believe you don't. > >Ah, that is a good base to start a discussion. Of course it is better to >keep the upstreams name but make exceptions if they are too generic, to >confusing or to offensive (though we did already accept such ones, eg. >"pornview" ;)). I concur that packages have been renamed where their name is too generic, such as verbs and short nouns (one of my earliest packages, imgstamp, was originally named 'stamp' and rejected). However, this is the word 'linux'. What else do you think it could possibly refer to? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, A.J. Rossini wrote: >Jamie Wilkinson <[EMAIL PROTECTED]> writes: > >> This one time, at band camp, Eduard Bloch wrote: >>>You repeat this again and again and got answers from me and others to >>>such an ultimate argument. But did you ask yourself why Herbert does not >>>participiate this discussion to help you? >> >> Why does the lack of response from Herbert prove that this package is a bad >> idea? I'm saddened that you have to revert to intimidation in place of a >> technical argument. > >Herbert did respond with a single message, somewhat positively if I >recall. Check the archives on this thread. You are entirely correct but alas this datapoint is irrelevant. I'm not convinced that lack of participation of one party constitutes proof. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Andrew Suffield wrote: >On Mon, Nov 10, 2003 at 11:58:46AM +0100, Robert Millan wrote: >> On Sun, Nov 09, 2003 at 10:43:49PM +0100, Eduard Bloch wrote: >> > > 1) You said before you were concerned about my package occupiing the >> > > package >> > > namespace in the archive. The fact that you don't like the name of my >> > > package >> > > proves your previous argument was intentionaly bogus. >> > >> > The fact of the too generic package name was mentioned before within >> > other arguments against your "linux" package. >> >> How many software programs called "linux" are around? > >Dozens. Lots of people have created variations on the theme of >"linux". You're not even talking about packaging the one released from >kernel.org, you're talking about creating your own fork (vis. patches >to make it work on different architectures). In the context of Debian, does that make software such as 'larch' and 'blootbot' forks of their upstream? Of course not. There are already several forks of the Linux kernel in Debian anyway. Robert wishes to attempt to unify them, does that not grant him use of the name 'linux'? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Matthew Garrett wrote: >Robert Millan wrote: >>On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote: >>> klogd will be unable to look up symbols, and ps and top need it for >>> wchan to be displayable. >> >>I'm so scared. wchan won't be displayable! > >What were you saying about sarcasm? The fact remains that it's a bug, >and it's a bug that you should already have thought of. Put simply, if >this is the level of research you've done, I don't think you're suitable >for packaging something as important as the kernel. This doesn't mean >that you shouldn't do it (as an academic exercise it'd be a wonderful >learning experience, and lessons learned may be well applied else where) >- I just don't think it should go anywhere near the archive. Bollocks. Kernels install /boot/System.map-$version. There's a symlink from /boot/System.map to the current version. You are told you need to reboot after installing a kernel package. How much more research is there that needs to be done for this particular issue? It looks to me like you're harping on a single issue which would have been encountered during the process of making this package, and based on this Robert is suddenly a second-class maintainer? If everyone in this project had to get the right answer first time, there would be a lot fewer maintainers and a lot fewer bugs in the BTS. >>You're mixing trivial maintainer issues with this ITP. It's very pity of you >>if you're doing it on purpose. > >No, I'm saying that you're proposing to package a major piece of >infrastructure and give it a name that may attract users into installing >it, and the amount of thought and consideration that you seem to have >put in is insufficiently large for me to consider that it'll do anything >other than convince people that Debian kernel packagers are on crack. >Which would, again, be bad. I'd reiterate that you're implying Robert is going to make a half-arsed attempt and upload something he hasn't tested, but I've already said that. Besides, it's already evident that Debian maintainers (as a superset of kernel packagers) are on crack. -- This thread scores 3 Trogdors out of a possible 5 for flamability.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Robert Millan wrote: > Place the package files in /usr/lib, and copy them conditionaly (debconf) > into /boot. The debconf question would properly explain that if per chooses > to update it, then the system must be rebooted promptly. > >Another option: > > Place the package files in /boot, but save a backup of them before (preinst). > Then prompt the user to reboot through debconf. > >Or even a combination of the two. A third method may involve a rc script that makes sure the correct version of System.map is installed. Then the only time kernel symbols are not found is between the package upgrade and just after the next reboot. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Matthew Garrett wrote: >Jamie Wilkinson wrote: > >>I do not expect Robert's package to make any more of an attempt to convince >>you a reboot is required than any of the other kernel packages. > >The current kernel packages include the version number in the package >name, whereas Robert seems to be suggesting that his package would >maintain the same name. As a result, if I upgrade a stable box, I'm >going to need to reboot the system, whereas currently I can upgrade >everything other than the kernel and then deal with the kernel at my >leisure. I think this is a regression. I think your assumption is probably false. There are maintainer scripts in pacakges for a reason. There are init scripts. I'm surprised I have to explain this to you. I also wonder how many participants in this thread who have voiced valid concerns also have an idea for how to go about solving those concerns, but are too interested in tearing Robert apart than offering useful advice. -- This thread scored 3 Trogdors out of a possible 5 in flamability.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Marcelo E. Magallon wrote: > > How do the current kernel packages guarantee this? > > > > Why would Robert's package need to behave any differently? > > The current kernel packages don't make the old stuff just dissappear, > so it's less of an issue in that case. In fact, the only "bad" > situation with the current kernel packages is when you update between > package releases of the same kernel version, and the current kernel > packages make plenty of noise in that situation. I've had another thought, which was spurred by the System.map discussion; and some people are probably going to hate it because it duplicates some of the effort of having a package management system in the first place. The grub package doesn't ever install itself to /boot, it requires the admin to copy the binaries from /usr/lib after an upgrade (or my memory is totally flawed). It wouldn't be so difficult to rotate the previous (good) kernel and associated files and replace them with the new kernel. An update-kernel script which ran after installation, and again at boot time, could check to make sure the latest kernel was in place and that ones bootloader could find it, and that the previous kernel was also accessible to the bootloader. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
This one time, at band camp, Robert Millan wrote: >> being presented with. > >I'd really LOVE to. But this is my discussion. If I don't take part in it, >who will respond to all these bogus arguments some people enjoy sending in? > >Rather, this is you and the other trolls who are wasting my time. What I'd really like to see is some packages uploaded to your home on gluck, because this thread isn't advancing *anyones* arguments. -- This thread scores 3 Trogdors out of a possible 5 for flamability.
Re: GCC 3.2 transition
This one time, at band camp, Joseph Carter wrote: >[EMAIL PROTECTED]:/usr/local/j2sdk1.4.0_01/jre/plugin/i386/ns610$ ldd >libjavaplugin_oji.so > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40044000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4008e000) > libdl.so.2 => /lib/libdl.so.2 (0x40168000) > libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 >(0x4016b000) > libm.so.6 => /lib/libm.so.6 (0x401ad000) > libc.so.6 => /lib/libc.so.6 (0x401cf000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x402eb000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x402f3000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) > >That's one hell of a figment of my imagination. Although, it does seem >the plugin is the only thing which uses libstdc++. ldd will traverse the library dependencies tree for all libraries, so it's possible that the libstdc++ requirement is caused by any of the other libraries in that list. What does objdump -p libjavaplugin_oji.so tell you? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: RFC: A regression test framework for Debian packages?
This one time, at band camp, Jérôme Marant wrote: > In a chrooted environment, we can install deboostrap and > package dependencies through APT. About 6 months ago I started writing some code in expect to do just this, to test my quake2-data installer package. I was able to install the package into an UML machine, answer the debconf questions, and check the location of the installed files (being an installer package, not all files installed by the package are in the deb). I haven't touched this code for a long time, but I've been meaning to clean it up and start doing regression testing on parts of the archive. I envisage being able to run it once a week on the entire archive, testing the ability of every pacakge to cleanly upgrade from woody to sarge, and back again. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: RFC: A regression test framework for Debian packages?
This one time, at band camp, Jérôme Marant wrote: >On Mon, Sep 02, 2002 at 08:19:23PM +1000, Jamie Wilkinson wrote: >> This one time, at band camp, Jérôme Marant wrote: >> > In a chrooted environment, we can install deboostrap and >> > package dependencies through APT. >> >> About 6 months ago I started writing some code in expect to do just this, to >> test my quake2-data installer package. I was able to install the package >> into an UML machine, answer the debconf questions, and check the location of >> the installed files (being an installer package, not all files installed by >> the package are in the deb). >> >> I haven't touched this code for a long time, but I've been meaning to clean >> it up and start doing regression testing on parts of the archive. I envisage >> being able to run it once a week on the entire archive, testing the >> ability of every pacakge to cleanly upgrade from woody to sarge, and back >> again. > >Nice! How does it work exactly? How do you write tests? Do you have scenarii >or something? The expect script starts up a user-mode-linux on a pre-built chroot, and then attempts to install the package in it. If that succeeds, it tries to purge it. Testing an upgrade/downgrade requires a trivial bit of hacking in the script. Debconf questions/answers are read from a file, the questions are watched for in the console output. It's horridly inefficient, though---I chose uml over chroot because I wanted ordinary users to be able to run it. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: web browser bookmark defaults
This one time, at band camp, Mark Howard wrote: >I also vote for removing any other upstream bookmarks (e.g. rpm search, >slackware searches). Feel free to disagree, with a convincing argument. I use a Debian workstation, but admin a collection of Debian and Red Hat machines -- remove the rpm search and I will be filing bugs. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Bug#170484: ITP: chaksem -- a LaTeX class for presentations
Package: wnpp Version: unavailable; reported 2002-11-24 Severity: wishlist * Package name: chaksem Version : 1.6a Upstream Author : Manuel M. T. Chakravarty <[EMAIL PROTECTED]> * URL : http://www.cse.unsw.edu.au/~chak/presentation/presentation.html * License : GPL Description : a LaTeX class for presentations chaksem is a LaTeX2e class for slides. Based on seminar, it adds support for running footers as well as itemised and numbered lists, with a layout that fits nicely to the sans serif font used for text. There is support for overlays, which includes the ability to accumulate overlay images for online presentations. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux willow 2.4.18 #1 Sun Oct 27 21:03:52 EST 2002 i686 Locale: LANG=en_AU, LC_CTYPE=en_AU -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Multiple conflicts between firewall configuring packages (policy change? mass bug filing?)
This one time, at band camp, Javier Fernández-Sanguino Peña wrote: >He can either: >1.- get the rules of the latest firewall script that runs from init (if it >flushes the previous rules) >2.- get a mixed setup of rules. > >¿Shouldn't there be a way for these firewalls to cooperate so as to not >get users into trouble? I don't want to conflict with any other package if it's not necessary. filtergen's init script is turned off by default, for this reason, and is trivially enabled. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: ifupdown writes to /etc... a bug?
This one time, at band camp, Thomas Hood wrote: >On Thu, 2003-04-03 at 18:56, Steve Langasek wrote: >> The FHS is about more than just providing a system that technically >> allows you to mount different filesystems as needed. There are also >> aesthetic concerns in the heirarchy (in the broad sense of creating a >> system which follows a set of simple principles), and I believe /etc/run >> violates that aesthetic whereas /run does not. > >OK, but some people find /run more objectionable than /etc/run >because it adds a new root directory. I doubt that we will be >able to reach an agreement about which of the alternatives >is most beautiful. > >If /etc/run is no less damaging to the FHS aesthetic than /run >then the decision between the two has to be made on the basis >of technical advantages, and there /run has a slight edge. I find /etc/run more objectionable because it isn't actually moving the state files out of /etc, which is what the whole point of the excercise is, IMHO. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Blars Blarson wrote: >In article <[EMAIL PROTECTED]> >[EMAIL PROTECTED] writes: >>I won't debate whether this is true in general, bug it is certainly >>unnecessary in the case of pump. I have specifically added code to >>deal with the inability to write to /var/run by making pump fall back >>to using TCP sockets. > >It will also need to cope with writing to /var/run on the root >partition, having /var mounted, and later processes not being able to >open the file since the /var/run directory on the root disk is >inaccessable. Huh? This is not the case at all. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Marco d'Itri wrote: >On Apr 07, Steve Langasek <[EMAIL PROTECTED]> wrote: > > >Duh. Did you miss the part where people were talking about *amending the > >FHS because the FHS is flawed*? >Yes: I did not agree with them. >And looks like I was right, because as I showed nearly all programs do >not need a standardized /run directory provided by the OS. And you missed the part where we agreed that nearly all programs should be using /var/run, and that /run is a special case for when /var/run isn't yet available? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Marco d'Itri wrote: >On Apr 07, Thomas Hood <[EMAIL PROTECTED]> wrote: > > > * pam, shadow > > Allow either /etc/nologin or /run/nologin to prevent non-root logins >Use a symlink. > > > * util-linux > > Use /run/mtab for mount's statefile >Use a symlink. A symlink doens't actually solve the problem of keeping program state files in /etc. Luckily the patch to fix both these programs isn't very complex at all. See the suite of patches for base-files, mount, util-linux, sysvinit, and pam (in approxmately that order) at http://spacepants.org/src/patches Packages with these patches (source, powerpc) are available at http://spacepants.org/debian/experimental -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Thomas Hood wrote: >On Sat, 2003-04-12 at 10:12, Anthony DeRobertis wrote: >> On Wed, 2003-04-09 at 14:17, Thomas Hood wrote: >> > * ppp >> > * Change /usr/sbin/pppd to: >> > * Store PID in /run/, not in /var/run/ >> Why? Is the goal to make PPP-mounter /var to work?! > >I suppose someone might want to mount /var/ across a ppp link. >If we are making the other changes then we might as well make >this one too, unless there is absolutely no point in doing so >(... because it is impossible to mount /var/ across a ppp link >for some reason I am overlooking?). > >> If so, pppd has to be moved to /sbin. > >Well, /usr/ could be local but /var/ remote. > >> > The proposed new directory is for files similar to those in /var/run/ >> > that are not just variable and unshareable but also local -- i.e., they >> > must be writable independently of network connectivity. >> >> No, they must be on the root file system, like /bin and /sbin. Remember >> the root FS can be network mounted, e.g., over NFS. > >How about this then: > The proposed new directory is for files that serve similar > purposes to those in /var/run and that are not just variable > and unshareable but also available early enough to be used > by programs in /sbin and /bin. How about: The proposed new directory is for storing program state, for those programs that run early in the bootup process such that the relevant directory in /var is not yet available. Thus we don't need to compare /run to /var/run, but make /run available for the same purposes of the entirety of /var but only in the case that a required subdirectory of /var doesn't exist. This works for the case that some programs need a /var/run and some need a /var/state and some need a /var/lib for their file; there will be so few programs actually using /run that there is no need to separate /run into further subdirectories for each of the /var subdirectories. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Thomas Hood wrote:
>(Re: /etc/nologin)
>> A dangling symlink should be considered like a missing file.
>
>Yes, that would work. However, having separate /etc/nologin
>and /run/nologin looks like a useful feature, as I mentioned
>earlier.
For clarification, (and this is specifically not aimed at Thomas, but
others who may not understand what I've done with /{etc,run}/nologin):
/etc/nologin is a admin-created configuration file. When the admin wants no
users to log in, they create /etc/nologin just as they have in the past and
the behaviour is exactly the same. No programs will attempt to remove
/etc/nologin; it is entirely the admin's responsibility to look after /etc
and any program who thinks it knows better is flawed from the outset.
/run/nologin is a program state file, created by shutdown to alert login
that the system is shutting down and that no users should log in.
/run/nologin can be removed by programs, and will be, because it is only
necessary in the period between the beginning of the shutdown and the end of
the bootup.
Thus, we preserve the sanctity of /etc and preserve the behaviour of
existing programs.
I am using /run rather than /var/run because the file /run/nologin needs to
be available early on, possibly before a /var on a separate partition has
been mounted. If anyone can assure me with 100% confidence that /var/run is
available at all the times that /run/nologin is accessed, then I will
happily amend the patch to move the file.
--
[EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Anthony DeRobertis wrote: >On Wed, 2003-04-09 at 14:17, Thomas Hood wrote: >> The proposed new directory is for files similar to those in /var/run/ >> that are not just variable and unshareable but also local -- i.e., they >> must be writable independently of network connectivity. > >No, they must be on the root file system, like /bin and /sbin. Remember >the root FS can be network mounted, e.g., over NFS. That is right! The core of the matter is not whether filesystems need to be mounted over the network or not, but whether the parts of the filesystem you are attempting to write to are on the root filesystem or not. And as I've tried to explain numerous times, having /var on a separate partition is incredibly common (and I hope the people who don't make /var separate aren't running mail, news, or database servers). -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Thomas Hood wrote: > * base-files > Add /run/ directory #191036: create /run for programs that run before /var is mounted > * pam, shadow > Allow either /etc/nologin or /run/nologin to prevent nonroot login #191037: Allow both /etc/nologin and /run/nologin to prevent non-root logins #191038: Allow both /etc/nologin and /run/nologin to prevent a non-root user from logging in > * sysvinit: > Touch /run/nologin (not /etc/nologin) when there is a delay > before a shutdown. #191041: use /run/nologin instead of /etc/nologin for preventing non-root logins during shutdown > * util-linux > Use /run/mtab for mount's statefile #191042: use /run/mtab for storing mount's state -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run/, resolvconf and read-only root
This one time, at band camp, Sam Hartman wrote: >Until you get general consensus on a specific goal, I'm unlikely to >accept such changes if they are submitted to me. As a maintainer I >want to be able to look at some statement and answer the following >questions: Hi Sam, I've just filed the bug with my patch to pam. My goal is not specifically a read-only root (although that may be a useful by-product of it) but just to remove any program state out of /etc. It is my firm belief that programs should not be writing anything to /etc. The patch against pam doesn't ask you to violate the FHS as it currently stands, but it does attempt to test for a file that, if it does exist, violate FHS in its current incarnation. I don't believe that testing for a nonexistent file would warrant a RC-bug, would it? And if the patch against base-files (#191036) and sysvinit (#191041) get accepted, then the changed behaviour of pam wouldn't be a bug against pam. The only FHS violations I am proposing at the moment are to base-files (the creation of /run), sysvinit (using /run/nologin instead of /etc/nologin), and util-linux (#191042, using /run/mtab instead of /etc/mtab). In these cases, violating the FHS is entirely reasonable because we are attempting to improve the FHS. >2) When root is read-only, what information is variable and what information >should be immutable? Why is this a reasonable categorization? IMHO, everything in /etc should be considered immutable by every program, unless the program has been given explicit permission for the current invocation only. That is, any program attempting to modify a file in /etc should first alert the administrator for confirmation. If that cannot be done, then the program shouldn't be writing to /etc. For mount, that means using the correct state directory for mtab, and for sysvinit, that means using the correct state directory for nologin. For the specific case of nologin, which I cover in the patch to sysvinit, shadow, and pam, the admin may create /etc/nologin as they are used to, for this is a configuration file, whereas sysvinit should only create and remove /run/nologin as this is now a program state file. >3) What information needs to go in /var vs /run? As discussed earlier in this thread, /run is only allowed for programs that do not have /var/run available yet. So you see, we are making two changes here: the first is to move state files out of /etc, and the second is to make a directory that mount can use for storing state. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Marco d'Itri wrote: > >/etc has a "static nature". See the note on /etc/mtab under Table > >3.7.3.1. It is also for configuration files. /etc/adjtime is neither. >Then propose to change FHS. Welcome to the discussion. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Marco d'Itri wrote: >On Apr 07, Thomas Hood <[EMAIL PROTECTED]> wrote: > > >(I forgot to mention) J.W.'s patch does more than what a mere symlink > >would do. By making programs sensitive both to /run/nologin and > >/etc/nologin, it becomes possible for the administrator to prevent > >logins by touching /etc/nologin, and this will not affect or be > >affected by what sysvinit does to /run/nologin. Is this a good idea? >No. This is a gratuitous incompaibility from long time UNIX systems >practice. I see. It is incompatible because it preserves the behaviour that admins are expecting, and at the same time removing a program state file from /etc. I posit that you have not read the patch, nor read Thomas' mail that you replied to, nor have any idea what this thread is about. You, sir, are on crack. I am switching to mail(1). -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Thomas Hood wrote: >Jamie Wilkinson wrote: >> That is right! The core of the matter is not whether >> filesystems need to be mounted over the network or not, >> but whether the parts of the filesystem you are attempting >> to write to are on the root filesystem or not. > >The essence of /run/ had better not include that it be a >directory on the root filesystem, because the current proposal >is that it be possible for /run/ to be a RAM-based filesystem >on systems with read-only root media. The problem I have with that is a catch-22 situation with mount trying to write to mtab, when the directory containing mtab doesn't yet exist. Your goal to make / mounted read-only will obviously need a solution to that. I don't have an answer to that just yet. >[... in another message:] >> Thus we don't need to compare /run to /var/run, but make /run available >> for the same purposes of the entirety of /var but only in the case that >> a required subdirectory of /var doesn't exist. > >I balk at this. IMHO we should call the new directory '/run/' >if and only if we are going to use it for the same purposes >for which we use /var/run/. If the new directory is to be a >whole parallel local var hierarchy then we should call it >something like '/lvar/'. However, I don't think we need a >whole parallel local var. I encourage the use of /var for the purposes outlined in the FHS. I only provide /run as a catchall for those programs that have no /var available. I do not expect there to be 13 or so subdirectories in /run to mirror /var. I do not expect more than a handful of programs to need /run at all. Off the top of my head, the only programs needing /run are mount and the sysvinit/login/pam combination, and the latter is certainly debatable. > >> This works for the case that >> some programs need a /var/run and some need a /var/state >> and some need a /var/lib for their file; > >/var/state/ is deprecated. > >Files stored in the proposed new directory will be lost on reboot, >so it is not suited to be a "lib" directory. I agree. I was not aware that /var/state was deprecated (so excuse my ignorance) though. In that case, then the description for /run can definitely compare itself to /var/run. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, Steve Langasek wrote: >Shell pseudocode was posted to this thread (a month ago?) that showed >how the init scripts could handle the requirement that /run be mounted >early, even if it's not on the root fs. The init scripts already >include special handling of /proc and /, IIRC; one more special-cased >directory isn't technically infeasible, and unless someone decides to >move /run elsewhere, it should be the last mount point that ever needs >to be special cased wrt mtab. Great, then. I will hunt the archives for that message. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run and read-only /etc
This one time, at band camp, [EMAIL PROTECTED] wrote: >Sorry to reopen this at such a late date, but I'm way behind on -devel. > >"Hi, I'm Karl and I maintain login and passwd." > >Thomas Hood <[EMAIL PROTECTED]> writes: >> * pam, shadow >> Allow either /etc/nologin or /run/nologin to prevent non-root logins > >I don't like the idea of having multiple files to turn off logins. (I >can't log into my system, and /etc/nologin doesn't exist! What? didn't you >know about this *other* file?) I also don't want to solve this with a >symlink. I don't have a problem with that, except that a lot of people are going to complain when /etc/nologin no longer prevents non-root logins. The patches specifically only create /run/nologin when the machine is shutting down and removes it when the machine is booting up, so while no-one else creates /run/nologin there is no change in behaviour. Granted someone may actually do that; would a message inside /run/nologin warning that "/run/nologin is in place, non-root logins disallowed" be better? As I recall, the contents of the files get displayed to the user attempting to log in. Such a message would alert anyone attempting to login what restriction is in place. >I would favor (even though it's weird from the pan-unix admin point of >view) just deprecating /etc/nologin in favor of something more "sensible". > >It would also be nice to have some blessing of /run in the policy first, >but that doesn't seem terribly likely. I am currently drafting a policy amendment, stay tuned. In the meantime, do not feel you have to wait for policy to apply the patches to pam and login, because they will still work with Debian as it currently stands; that is, as long as you have been convinced of its merit. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run/, resolvconf and read-only root
This one time, at band camp, Theodore Ts'o wrote: >... and those who have tried to explain why it's a bad idea or have >concerns have been brushed off. So I've given up for now trying to >explain to you folks why I'm not convinced, since I don't have time to >go pig mud-wrestling, but please don't assume that silence means >assent. I don't recall you giving a strong argument why /run was a bad idea. I do recall you voicing your concern and then having your concerns addressed. If that is not the case, please reiterate them. As far as I can tell, there are only two strongly negative opinions to this, yours and the mad ramblings of Marco d'Itri. -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: /run/, resolvconf and read-only root
This one time, at band camp, Jamie Wilkinson wrote: >This one time, at band camp, Theodore Ts'o wrote: >>... and those who have tried to explain why it's a bad idea or have >>concerns have been brushed off. So I've given up for now trying to >>explain to you folks why I'm not convinced, since I don't have time to >>go pig mud-wrestling, but please don't assume that silence means >>assent. > >I don't recall you giving a strong argument why /run was a bad idea. I do >recall you voicing your concern and then having your concerns addressed. If >that is not the case, please reiterate them. And just to make sure, I had a look back up the thread to see what your complaints were, and the only thing you said in this thread was on the 21st of March, msgid <[EMAIL PROTECTED]> when you said: >Doing this would violate the FHS It was replied to by Anthony Towns, who said: >Nonsense; changes to the FHS have to first be trialled in distros, >so adding new directories and moving things around is explicitly a >supported part of the FHS process these days. It seemed to me that opinion was more swayed towards giving this a try, and seeing what happened. I don't know what it will take to convince you, but I would like you to answer these questions: Do you think having programs write to /etc is a bad thing? Where would you put /etc/mtab, to keep /etc sacrosanct? -- [EMAIL PROTECTED] http://people.debian.org/~jaq
Re: Quake 2 sources GPL'd
This one time, at band camp, Joey Hess wrote: >That's neat, but I wish we at least had quake 1 in contrib for woody. >Woody will be the first release of debian in years and years without the >possbility of quake at all (in main, contrib, or even non-free), I think. (I'm not yet a d-d, I'm currently halfway through the NM process.) For several months now, it has been my intention to get quake2 debs back into non-free, since they dissapeared from the archive. I have not yet contacted the previous maintainer (Roderick Schertler <[EMAIL PROTECTED]>) about this, but I've managed to dig up source packages from the depths of Google. I've been working with these to take care of the installation of data files. In any case, I'd still like to be the one to maintain quake2. This is *not* an ITP; the source isn't buildable with gcc yet, and will require a lot of work before packages can be made available. To answer the original poster's question: no, there won't be any quake2 debs for woody's release. My 2c on the location of the package: I'd put it in contrib. The binary would be useless without any data files, which implies a Depends: quake2-data, which as already discussed is non-free; policy dictates that it should be contrib. This doesn't preclude the package moving to main if that dependency is removed, however. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Virtual reality is its own reward.
Re: Quake2/GPL: At least source should go into main
This one time, at band camp, Erich Schubert wrote: >Software in contrib needs non-free software to run. >But the source of quake2 certainly is useful without the commercial game >data. This is a silly assertion; the source to *any* program is useful without the data files. As others have pointed out, the quake2 source is available from iD software's site if anyone wants to check it out. Distributing source that does not build gains Debian nothing. I wonder how many people in either of these threads have actually downloaded this source and looked at it? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Apparently, an episode of Seinfeld was pulled from syndication because one of Kramer's lines not only acknowledged the existence of pants but openly revelled in it. -- Sean Neakums, in the scarey.devil.monastery
Re: Quake2/GPL: At least source should go into main
This one time, at band camp, Erich Schubert wrote: >> I wonder how many people in either of these threads have actually downloaded >> this source and looked at it? > >i have. I even got it to compile... >and i think it'll need quite some work to get useful... >it has inline asm gcc doesn't like; the ref_glx driver is missing; it >currently requires svgalib and glide (or an old mesa, i'm not sure) to >compile (and probably will run on glide and software only right now) I've made it compile now, without the inline assembler (requires hacking around some #defines) and without ref_soft and ref_gl, ie with only the software x11 driver. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg RFC 882 put the dot in .com.
Bug#126716: ITP: quake2 -- popular 3D first person shooter game (engine only)
Package: wnpp Version: N/A; reported 2001-12-28 Severity: wishlist * Package name: quake2 Version : 3.21 Upstream Author : iD Software (unmaintained) * URL : ftp://ftp.idsoftware.com/idstuff/source/q2source-3.21.zip * License : GPL Version 2 Description : popular 3D first person shooter game (engine only) This will only be the game engine, no data files. The package will require installation of the non-free commercial game data or a free replacement. There is no specific free data files packaged for Debian, quake2 will go into contrib as per policy; once free data has been packaged, quake2 can go into main. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Never attribute to incompetence that which can be explained as allegience to the Ultimate Evil. -- Geoffrey Kinnel in the Scarey Devil Monastery
Re: BUG: Quake2 and mailcap file (mime-support)
This one time, at band camp, Pete Ryland wrote: >So is this a bug with mime-support (shouldn't have blown away mailcap when >/tmp was full), quake2-data (shouldn't have filled /tmp in the first place), >both, or should I have been monitoring /tmp and it's really my own silly >fault? (100M is surely enough for most things, no?) It's a bug with quake2-data for not checking that the unpack will fit into /tmp. I should add a debconf question asking where the user would like to unpack it to (or perhaps use the same directory that the data is downloaded to). As for blowing away mailcap, was this automagically rebuilt after quake2-data was installed? I am assuming that your /tmp and /etc are on the same partition. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Sodomy non sapient.
Re: SUGGESTION: Re: Some thoughts about problems within Debian
This one time, at band camp, Ola Lundqvist wrote: >Ahh it already exists! Cool. Well then it is a bug on the www pages. >Missing here ... >http://www.debian.org/Bugs/Developer#severities It was at http://www.debian.org/Bugs/Developer#tags when I looked today... -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg why can't I fill an area? Slashr: You're not fat enough. -- #sodfest97
Re: Debbugs and ACK messages
This one time, at band camp, Wichert Akkerman wrote: >Previously Colin Walters wrote: >> This gets tricky though, because right now the BTS isn't designed to >> do stuff depending on the submitter at all... > >It's simple, just stick a flag in the mail headers. And that flag is? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg A layman knows he has to kick it. An amateur knows where to kick it. A professional knows how hard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debbugs and ACK messages
This one time, at band camp, Colin Walters wrote: >On Wed, 2002-04-03 at 17:44, Wichert Akkerman wrote: > >> It's simple, just stick a flag in the mail headers. > >I don't really regard that as a reasonable solution. For example, my >email client doesn't (as far as I know) allow adding arbitrary headers >to a message. I suppose you could argue that my email client is broken >(and I would probably agree), but there are a lot of people out there in >a similar situation. Even if your client does allow it, it's often >inconvenient. The BTS already uses psuedo-headers; if it's smart, then it won't matter if you put your X-Debbugs-Flag: NoAck in the header or body. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg The email of the species is more deadly than the mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Conference 2 Registration
This one time, at band camp, Jeroen Dekkers wrote: >IMHO the non-free section should be removed. IMHO you should write less email and fix more bugs. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Commander Taco wastes our time with these dumb polls but we keep reading -- Syberghost (slashdot) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
This one time, at band camp, Aurelien Jarno wrote: >DFSG stand for "Debian Free Software Guidelines". IMHO we ave to create a >DFDG, "Debian Free Documentation Guidelines". I wrote this up last night after getting fed up with this thread, then modified it this morning after reading the thread on -legal that was referred to. Flame away. http://people.debian.org/~jaq/jfdl.html -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg This port may thing it's fortified, butt I seem to be mounting a pretty good assault -- #sodfest97 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
This one time, at band camp, Jamie Wilkinson wrote: >I wrote this up last night after getting fed up with this thread, then >modified it this morning after reading the thread on -legal that was >referred to. Flame away. > >http://people.debian.org/~jaq/jfdl.html Of course, I meant http://people.debian.org/~jaq/jfdg.html -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg He who laughs last thinks slowest! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
This one time, at band camp, Ola Lundqvist wrote: >On Mon, Apr 08, 2002 at 03:57:42PM +1000, Jamie Wilkinson wrote: >> http://people.debian.org/~jaq/jfdg.html > >Well written. Thanks. > >One issue though: >The license may not require a royalty or other fee for such sale. > --^^^ > >Shouldn't it say must? Good point, well argued. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Definition: A definition is something that defines what a word or phrase means. The definition of `definition' is something that defines what it means to define what something means. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
This one time, at band camp, Dale Scheetz wrote: >So, in fact, both of these licenses are non-free, as they contain clauses >that can be used, and will be considered non-free. > >I find it ... foolish to declare a license to be free IFF some clauses of >the license are not exercised. Using this language, any proprietary >license becomes free as long as none of the proprietary sections are >inforced by the author... So you have never checked your packages to make sure that the code within is all above board and licensed under the license it says it is? When a particular instance of a license can be considered free by our standards, why should we place a blanket rejection on all possible permutations of that license? We, as developers, should be able to recognise the difference between a document with and without invariant sections, and identify the documentation as non-free or free respectively under our current set of guidelines. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg The Tao that is seen Is not the true Tao - until You bring fresh toner. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug #140769: frozen-bubble: RC bug
This one time, at band camp, Rob Bradford wrote: >Package: frozen-bubble >Version: 0.9.2-9 >Severity: critical > >Frozen-bubble is holding up the release process as all the developers >are now hooked and are no longer working on woody, hence the RC status >as this package is single handedly holding the whole release process >back. Nice tautology. >Either the game is made less addictive or it should be removed until >after woody is released. There's a simple workaround. Once you finish level 50 it gets very boring. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Ah yes. The `graduate'. A measure of how fucked-up a software project is. Simple linear scale, no upper bound, the lower the value the less fucked-up the project. -- Matt McLeod in a.s.r -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree 4.2.0 - again
This one time, at band camp, Lasse Karkkainen wrote: >Time to throw some gasoline on the flames ... Branden apparently is >incapable of releasing it. So, I suggest that anyone, with enough >knowledge and TIME, reading this, would volunteer as XFree package >maintainer. Branden's comments suggest that he just doesn't have enough >time for that. You're 15 days late. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg The email of the species is more deadly than the mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree 4.2.0 - again
This one time, at band camp, David D. W. Downey wrote: >No apologies needed, we all know it's his evil twin. *evil* twin? Now I'm scared. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Marge, this ticket doesn't just give me a seat. It also gives me the right -- no, the duty -- to make a complete ass of myself. -- Homer Simpson, Dancin' Homer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree 4.2.0 - again
This one time, at band camp, Joseph Carter wrote: >On Wed, Apr 17, 2002 at 07:25:31PM -0500, Branden Robinson wrote: >> I didn't go anywhere. Nowhere in my platform did I claim I wasn't evil. >> ;-) > > this is the New Overfiend, preacher of Love and Tolerance Orwellian Love and Tolerance, that is. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg Remember: every member of your 'target audience' also owns a broadcasting station. These 'targets' can shoot back. -- Michael Rathbun to advertisers, in nanae -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
This one time, at band camp, Branden Robinson wrote: >Over six months ago, on 2001-11-14, Bug #119517 was submitted to the >Technical Committee for a ruling. No member of the Technical Committe >has participated in any public discussion of this bug (at least in the >bug logs or in available messages from the debian-ctte list archives) >since 2001-12-04, and no apparently discussion of any sort since >2002-02-26. As Brian has made it clear[1] that he does not wish to follow either suggestion made by Dale Scheetz[2] (splitting the package or changing the Depends:) to ensure all executables supplied in the package run as expected, IMHO the solution is as Ian Jackson proposed: |(a) The pcmcia-cs maintainer could choose to make `cardinfo' be a |script which checked whether the appropriate libraries were present |and otherwise produced a more helpful error message. Bugs that turn into political debates are boring. [1] <[EMAIL PROTECTED]> [2] <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg The ability to quote is a serviceable substitute for wit. -- W. S. Maugham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Malloc and security
Hiya Just a quick question, which malloc, is there anyway that this function (used in C) could allocate memory into already allocated memory, such as the stack - or code space! Jamie -- 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/4fdf8ecf.4030...@jatos.co.uk
Malloc and security
Hiya Just a quick question, which malloc, is there anyway that this function (used in C) could allocate memory into already allocated memory, such as the stack - or code space! Jamie -- 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/4fdf8b8e.2020...@jatos.co.uk
Re: Malloc and security
Aaah, any packages that need maintaining? Has there been swearing before? I assume to private email addys. Jamie On 18/06/2012 22:12, Dmitrijs Ledkovs wrote: I totally understand top posting from mobiles. Well, debian has improved, there was no swearing this time around, I don't think. Thick skin is good, please maintain a few packages. Regards, Dmitrijs. On 18/06/12 22:00, Jamie White wrote: Oh thats flaming? Just seems like just friendly requests not todo stuff. Certainly, had faaa worse said to me! I'm thick skinned :P Btw, please excuse top loading, BB doesn't allow base loading! Keeping same flow now though. Jamie On 18/06/2012 21:52, Dmitrijs Ledkovs wrote: anyway... You have been flamed to death by now =))) Welcome to friendly debian development. Smile, it gets worse (tm) =) feel free to him me up if you need advice or a sponsor. On 18/06/12 21:48, ja...@jatos.co.uk wrote: Okies, I ignore the second email I sent, I'll just send this one to you as not to clutter the list. Yeah, like I say, an error in thinking first one hadn't gone, apologies for that. Jamie --Original Message-- From: Dmitrijs Ledkovs Sender: Dmitrijs Ledkovs To: ja...@jatos.co.uk Subject: Re: Malloc and security Sent: 18 Jun 2012 21:45 sent an apology to the debian-devel. There are two identical emails to debian-devel ~10mins apart or so. On 18/06/12 21:44, ja...@jatos.co.uk wrote: I am not quite sure how it ended on Ubuntu devel, I didn't send it there... Sent from my BlackBerry® smartphone on O2 -Original Message- From: Dmitrijs Ledkovs Sender: Dmitrijs Ledkovs Date: Mon, 18 Jun 2012 21:40:52 To: Cc: Subject: Re: Malloc and security On 18/06/12 21:11, Jamie White wrote: Hiya Just a quick question, which malloc, is there anyway that this function (used in C) could allocate memory into already allocated memory, such as the stack - or code space! Jamie Cross posting offtopic email to two mailing lists (ubuntu-devel and debian-devel) is not nice. If you want quicker response times IRC would have been more appropriate. -- 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/4fdf9a88.7080...@jatos.co.uk
Re: tasksel: Default desktop: Gnome→Xfce
On 03/08/2012 23:24, Michael Biebl wrote: On 04.08.2012 00:03, Matt Zagrabelny wrote: On Fri, Aug 3, 2012 at 4:52 PM, Arno Töll wrote: Hi, On 03.08.2012 23:28, Michael Biebl wrote: Seriously, I'd just drop our CD1 installs and only provide a net-install image and a DVD image for desktop installations. Is there any serious survey how established DVD drives (and writers) are these days? CD images might be obsolete some day, but we should be sure (virtually) nobody notices once we drop it. Maybe this wasn't entirely obvious. I didn't say to drop CD images completely. Just that CD1 is no longer sufficient to provide a full desktop environment installation and instead promote an alternative installation image for desktop installations. I don't know about serious surveys, but flash drives are ubiquitous and have large storage. Some (many?) laptops don't have optical drives either. For D-I, I would pick the most common USB flash drive size (perhaps 2.0 GB) and target that. That sounds like an interesting idea. Even if a default DVD-RW would provide more space, having only 1 GB instead of 4.4 GB to download makes a difference. 2.0 GB would even probably be enough to fit GNOME and KDE (and maybe other alternatives) on that image. Michael Also, with the package survey, could you just work out what packages tend to be downloaded together and use that to make specialised CDs for a purpose, instead of numbered CDs. Jamie -- 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/501c5736.3040...@jatos.co.uk
Bug#634124: ITP: cronutils -- Utilities to assist running batch processing jobs
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson * Package name: cronutils Version : 1.0 Upstream Author : Jamie IWlkinson * URL : http://code.google.com/p/cronutils/ * License : Apache Programming Lang: C Description : Utilities to assist running batch processing jobs A set of utilities to complement batch processing jobs, such as those run from cron, by limiting concurrent execution of jobs, setting hard limits on the runtime of a job, and recording execution statistics of a completed job. -- 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/20110717070353.15229.2667.reportbug@localhost
Re: default firewall utility changes for Debian 11 bullseye
On Tue, 16 Jul 2019, Arturo Borrero Gonzalez wrote: > Hi there, > > as you may know, Debian 10 buster includes the iptables-nft utility by > default, > which is an iptables flavor that uses the nf_tables kernel subsystem. > Is intended to help people migrate from iptables to nftables. > > For the next release cycle I propose we move this default event further. > As of this email, iptables [0] is Priority: important and nftables [1] is > Priority: optional in both buster and bullseye. The important value means the > package gets installed by default in every Debian install. As the upstream ufw developer, this makes since to me. > Also, I believe the days of using a low level tool for directly configuring > the > firewall may be gone, at least for desktop use cases. It seems the industry > more > or less agreed on using firewalld [2] as a wrapper for the system firewall. > There are plenty of system services that integrate with firewalld anyway [3]. > By the way, firewalld is using (or should be using) nftables by default at > this > point. > > This email contains 2 changes/proposals for Debian 11 bullseye: > > 1) switch priority values for iptables/nftables, i.e, make nftables Priority: > important and iptables Priority: optional Makes sense. > 2) introduce firewalld as the default firewalling wrapper in Debian, at least > in > desktop related tasksel tasks. I'm obviously biased, but anecdotally I have had quite a few people say disparaging things about firewalld, particularly from server admins. I'm not really in a position for people to sing firewalld's praises to me, so take that for what it is worth. IIRC, network-manager has a fair frontend for firewalld that could be nice for desktop users if Debian wants that tight integration. That said, I can say that the ufw packaging makes it so it stays out of the way for people who want to use other firewall applications. I encourage Debian in whatever choice is made to make sure that the experience degrades gracefully if someone chooses something other than the default. -- Email: ja...@strandboge.com IRC: jdstrand
Re: default firewall utility changes for Debian 11 bullseye
On Tue, 16 Jul 2019, Raphael Hertzog wrote: > > 2) introduce firewalld as the default firewalling wrapper in Debian, at > > least in > > desktop related tasksel tasks. > > No objection. I think it's high time we have some default firewall > installed in particular with IPv6 getting more widely deployed... > > The other desktop firewall that I know is "ufw" but it doesn't seem to > have any momentum behind it. Again, I'm biased, but ufw supports IPv6. It's also been on the default server and desktop install of Ubuntu for 9+ years. ufw functions well for bastion hosts, less so for routers (though it has some facility there). Perhaps the perceived 'lack of momentum' has to do with a lack of feature development, but for the primary bastion host case, I haven't deemed this necessary. -- Email: ja...@strandboge.com IRC: jdstrand
Re: default firewall utility changes for Debian 11 bullseye
On Wed, 17 Jul 2019, Stephan Seitz wrote: > On Di, Jul 16, 2019 at 11:23:43 +0200, Guillem Jover wrote: > > On Tue, 2019-07-16 at 11:07:15 +0200, Arturo Borrero Gonzalez wrote: > > > as you may know, Debian 10 buster includes the iptables-nft utility by > > > default, which is an iptables flavor that uses the nf_tables kernel > > > subsystem. Is intended to help people migrate from iptables to nftables. > > Yeah, this was a great way to migrate, thanks! > > What is the problem with using iptables-nft compared to the new nft syntax? > > According to the documentation nft seems quite more complex. > What would be the replacement for a simple single line like > iptables -I INPUT -j DROP -s -p tcp –dport 587 ? > > What about other packages like fail2ban? Does it „hurt” if different > programs are using iptables-nft or nft? > The thing you want to avoid is mixing nft with iptables-legacy. iptables-nft and nft should be fine. -- Email: ja...@strandboge.com IRC: jdstrand signature.asc Description: PGP signature
Re: default firewall utility changes for Debian 11 bullseye
On Tue, 16 Jul 2019, Ben Hutchings wrote: > On Tue, 2019-07-16 at 11:57 +0200, Raphael Hertzog wrote: > [...] > > The other desktop firewall that I know is "ufw" but it doesn't seem to > > have any momentum behind it. > > Also, while its syntax is obviously intended to be simple, it's quite > irregular and the syntax error messages aren't very helpful. FYI, the simple syntax is meant to be, well, simple and the extended syntax is supposed to resemble OpenBSD's PF. That may not be everyone's cup of tea of course... :) As for syntax error messages, please file bugs in the BTS or upstream. I'd be happy to take a look. -- Email: ja...@strandboge.com IRC: jdstrand signature.asc Description: PGP signature
Re: default firewall utility changes for Debian 11 bullseye
On Wed, 17 Jul 2019, Chris Lamb wrote: > Raphael Hertzog wrote: > > > The other desktop firewall that I know is "ufw" but it doesn't seem to > > have any momentum behind it. > > It is curious you mention a lack of momentum; in my experience, it is > the most commonly recommended firewall on various support-adjacent > sites around the internet. (Perhaps due to it's Ubuntu/Canonical > associations and authorship.) > FYI, I'm not aware of any distributions other than Ubuntu where it is in the default install, but based on bug reports, I know it is in quite a few distributions. I've always been pleasantly surprised at how much it is used, and written about. :) -- Email: ja...@strandboge.com IRC: jdstrand
Re: default firewall utility changes for Debian 11 bullseye
On Wed, 17 Jul 2019, Jamie Strandboge wrote: > On Tue, 16 Jul 2019, Raphael Hertzog wrote: > > > > 2) introduce firewalld as the default firewalling wrapper in Debian, at > > > least in > > > desktop related tasksel tasks. > > > > No objection. I think it's high time we have some default firewall > > installed in particular with IPv6 getting more widely deployed... > > > > The other desktop firewall that I know is "ufw" but it doesn't seem to > > have any momentum behind it. > > Again, I'm biased, but ufw supports IPv6. It's also been on the default server > and desktop install of Ubuntu for 9+ years. ufw functions well for bastion > hosts, less so for routers (though it has some facility there). Perhaps the > perceived 'lack of momentum' has to do with a lack of feature development, but > for the primary bastion host case, I haven't deemed this necessary. Oh, I forgot to mention. I've never actually considered ufw as a "desktop" firewall. I've considered it a decent "bastion" firewall with a CLI experience (desktop or server). The ufw projects lacks a GUI frontend which may be desirable for a "desktop" firewall (see my previous comment re firewalld and network-manager; there are various GUIs written for ufw, but not associated with the project). -- Email: ja...@strandboge.com IRC: jdstrand
Re: default firewall utility changes for Debian 11 bullseye
On Wed, 17 Jul 2019, Chris Lamb wrote: > Jamie Strandboge wrote: > > > Again, I'm biased, but ufw supports IPv6. It's also been on the default > > server > > and desktop install of Ubuntu for 9+ years. ufw functions well for bastion > > hosts, less so for routers (though it has some facility there). > > It also has a first-class Ansible module which (given a flood of > firewall options around when I needed to pick something in haste > around the time of the stretch release…) was actually the deciding > factor for me: > > https://docs.ansible.com/ansible/latest/modules/ufw_module.html Oh, nice! I should probably collect the various projects that integrate with ufw and list them somewhere... (I've added that to my todo). Related, I have some improvements for fail2ban I've been meaning to upstream as well that make it work a lot better, esp wrt IPv6. On that note and to anyone participating in this thread or just coming across it some time in the future, if there are things that would make ufw better in Debian (particularly wrt bastion use cases), I'm happy to make improvements regardless of if it is a candidate as the default or not (please file bugs :). -- Email: ja...@strandboge.com IRC: jdstrand
Bug#946014: ITP: pyao -- Python interface to the Audio Output library
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson * Package name: pyao Version : 0.82 Upstream Author : Christian Schmitz * URL : http://www.xiph.org/ogg/vorbis/download/ * License : GPL-3 Programming Lang: C Description : Python interface to the Audio Output library This module makes the libao (Audio Output) functions available in Python. With this module you can write Python applications that use the cross platform audio output library. pyao was removed from the archive due to python3 incompatibility. I used it, and would like it to return to the archive! This upload addressds the pytbon3 issue as well as updating the package to modern standards. Packaging will be done on a public git repo just as soon as I have figured that out, and will be reflected in the control file.
Follow Up To IBM WebSphere or Apache Tomcat or Oracle WebLogic or IIS 7.5 Users List
Good Day, I hope this email finds you well. I am writing to you in regards to our recent list release, and check if you would be interested in acquiring recently verified Top IBM WebSphere or Apache Tomcat or Oracle WebLogic or IIS 7.5 Users List. Every contact from this database has completed verification on the 10th of jan2018 to give you 95%+ accuracy and ensure your message reaches the right contact from the right company. Titles: IT decision makers (C-level, VP-level, Directors and Managers) Please let me know if you would be interested in acquiring this list for your marketing initiatives and I will send you the counts and list details accordingly. Thank you for your time and I look forward to hearing from you soon. Best Regards, Jamie Messer Marketing & Lead Specialist
Re: [draft] need your help on the AI-DFSG general resolution prepration
On Sun, 2 Feb 2025 at 15:57, M. Zhou wrote: > (1) do you know any important but missing reference materials? Is it worth explicitly mentioning weights are also released under very restrictive non-free licenses? The list of Apache/MIT licenses might mislead a reader into believing all weights are licensed freely. For example, LG's EXAONE license is strictly non-commercial and says they own the model, and all derivative models, and even all output of the model (i.e. all text that users generate): https://ollama.com/library/exaone3.5 https://huggingface.co/LGAI-EXAONE/EXAONE-3.5-7.8B-Instruct/blob/main/LICENSE Also a small correction, just after heading "# Problem 1: "Preferred form of modification" there is a "udner" instead of "under". Jamie
