Re: Moving /tmp to tmpfs is fine
* Ben Hutchings [120527 17:25]: > Creating arbitrarily large temporary files outside the user's home > directory is generally going to be unreliable. The only thing more unreliable than that is creating arbitrary large file in user's home directory. If it is not supposed to be persistent data that is available on every node the user can log in, then it does not belong into the home directory (unless the user explicitly choose to set TMPDIR there). The home directory can be quite slow (because being remote, being encrypted, ...) and quite scarce (permanent storage on server discs with redudancy and backup strategies is not that cheap). Unless a program is explicitly told otherwise, temporary files belong to TMPDIR and if that is not set to /tmp. (or any subdirectory thereof the programs like to create). If that is too small, then it is too small. The admin is able to configure /tmp differently, the user is able to set TMPDIR differently. my 0.02: I personally think having tmpdir on /tmp might be a good default for new systems. If systems get changed to that from something else on upgrade without asking, I consider that quite an ugly bug. Bernhard R. Link -- 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/20120528084732.ga4...@client.brlink.eu
Bug#666541: marked as done ([Wish] package OpenSearch descriptions for reuse by all browsers)
Your message dated Mon, 28 May 2012 11:04:38 +0200 with message-id <201205281104.39421.hol...@layer-acht.org> and subject line this ain't a general problem has caused the Debian Bug report #666541, regarding [Wish] package OpenSearch descriptions for reuse by all browsers to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 666541: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666541 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'd like to see a package like "opensearch-descriptions" in Debian containing a comprehensive database of opensearch description documents. Browser packages should depend on this package to provide a consistent set of opensearch providers. Not all search engines contained in the package should be included by default in all browsers. The package should rather provide a mechanism to select and deselect individual search engines system wide or for a user account. Databases of opensearch descriptions: * http://mycroft.mozdev.org * http://www.searchplugins.net The package should also provide support for extension-packages, that provide additional search engines. Thomas Koch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPdyzIAAoJEAf8SJEEK6ZaKx0QAI1r2xXwL2Bi2sTzlyoeiLZT lVLiuxj04zLWTZHIDW/8lX8FW9l8a3RiuZ0HgXo9x/0TwTL2qgbgFqElUyF1LhwK DZxxphDcrmQXekTny9MBNGe4bkmgk5Uv+AI4K+63FX6b2j/Ga0+aFn9irgbVihSp ceiDJPgpr16yA8v2y+r7gLG0KXLTdadaw9rPHtGztGmk/zCKOFIDEDqOnlmaiAfz 5KTzHTQV9rOehFEbb9HVsZACax+WpGPj8QW6BzZ8y2Nt+WIMyYKI2nvXimCuzlSt d+LMMkJmBG8Nd3qm/FV9vBh1sJY7clfDpswS8YQ986R+REd44O7la6WVoyUc77i8 +CONfhWEt9+Ik5YgPEajfjQgHbQKPwOC69GGFew7HI5JX29KN/32WsuYr8x0JrGL 5ytX4HC9NFE2CGz5MXQyd1KN8LQolXYM5Ogqpl98IcQGCiRpA59yfLeRT0Kg01dY pIW9ASuje81MUCaZasXVCZhT5hFytIb0Z/OUmNXUZyQ2r27o17ONuptqX9dNkx2O 12HEr8lIxXNKvr5zeMOC85iWXCwGkrUnpvaHXobs40RC4GzmXFY5zs6b4Uo84DJm YtlOcnu9qB316sr3FhAzjMGlcXloVUVZe2w3f/SZ6YkzTuqVy2nv+TIOstqoDGrr MWHpWiImUswYSdskMSVy =2te3 -END PGP SIGNATURE- --- End Message --- --- Begin Message --- Hi Thomas, this ain't a general problem, it's also not an ITP or RTP, but as I understand it, rather a wish that someone does something^w^writes some application / database. Definitly not a general problem in or for Debian, thus closing. cheers, Holger --- End Message ---
Bug#626424: marked as done (Please implement a method to save and restore netfilter rules at boot)
Your message dated Mon, 28 May 2012 11:10:45 +0200 with message-id <201205281110.46218.hol...@layer-acht.org> and subject line Re: Bug#626424: Please implement a method to save and restore netfilter rules at boot has caused the Debian Bug report #626424, regarding Please implement a method to save and restore netfilter rules at boot to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 626424: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626424 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: (none) Version: (none) There have been several requests against the iptables package to include a init script, all rejected by the maintainer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413550 (Can't set iptable rules before initiating network at boot) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434107 (Iptables init script [attached]) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580943 (Should include a simple ifupdown script to configure iptables from rules file or setup script) I wish there was a simple apt-gettable way of getting my netfilter rules saved and restored automatically. For example, Redhat's iptables package is a tested and working model that can be applied (I actually wget their src.rpm from which I extract the init script and mkdir the /etc/sysconfig/iptables) Thank you. Costin Gusa Independent IT Professional http://ro.linkedin.com/in/costinel +407.23.24.71.79 +40723.010.262 --- End Message --- --- Begin Message --- Hi Costin, On Freitag, 13. Mai 2011, Costin wrote: > >> See if iptables-persistent does what you need. > > Thank you for pointing that package, Andrei. Unfortunately [...] > It is however a good starting point and I will file a bug against this > package for feature requests. thus closing this bug, also since it's not a general issue in Debian :) cheers, Holger --- End Message ---
Bug#662932: marked as done (general: USB devices, mass storage, and printer cause system fail, and report a lot of log problems)
Your message dated Mon, 28 May 2012 11:11:39 +0200 with message-id <20120528.40391.hol...@layer-acht.org> and subject line hardware issue, thus closing has caused the Debian Bug report #662932, regarding general: USB devices, mass storage, and printer cause system fail, and report a lot of log problems to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 662932: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662932 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: important Dear Maintainer, I have some problem with USB, mass storage devices and printer (it detect some component as storage device), sometimes it send a lot of logs to /var/log/syslog, like these: Mar 7 08:02:20 dacer kernel: [668285.604061] usb 1-8: reset high-speed USB device number 7 using ehci_hcd It send thousand of this lines. Usually when this happend, when disconect printer or unplug usb, system HANG and have to press reset button. I report a lot of info to debians forums, but there is no support. Here is thread link http://forums.debian.net/viewtopic.php?f=10&t=75731 I don't know which package is related. This happen for a long time ago Thanks -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- --- End Message ---
Processed: reassign
Processing commands for cont...@bugs.debian.org: > reassign 635756 hal Bug #635756 [general] unknown: Improved useability for ExpressCard to CompactFlash adaptors Bug reassigned from package 'general' to 'hal'. Ignoring request to alter found versions of bug #635756 to the same values previously set Ignoring request to alter fixed versions of bug #635756 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 635756: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635756 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13381964431350.transcr...@bugs.debian.org
Re: Moving /tmp to tmpfs makes it useless
Hi, On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote: > What's a temporary file? Really, why would applications temporarily store > its data in a file? They do that to *free some memory*. Placing those files > back to memory renders the whole process of writing the file useless. > If the files are small and can stay in memory why would application save it > to file? how, or why, would an application know that I have enough memory to keep it all there, while you don't? The fail-safe way to code an application without copious special-casing is to use a file and then let the systems administrator decide what to do with it. If the application insists on keeping everything in memory, the systems administrator can, at best, add more swap, but if it uses a file, he can decide either way. > Since it's only reasonable to store large data sets in temporary files, > standard sets no size limits for these files. So if application's author > had actually read FHS he should expect these directories to handle > large files. It's not, see below. Also, most of the time, /tmp goes into / (on smaller systems), and is thus typically *very* much limited in space. Granted, the user can relocate /tmp to another place later, once he became aware of the limit... Running out of space in /tmp should be a one-time event for any system that one installs, since thereafter, /tmp will have enough space configured for the desired purposes. No need to make it non-tmpfs. > Who uses /tmp > = > Let's check the real world and see what applications actually use /tmp. > And the most important thing: file managers, browsers, image editors, > cd burners — these are not some rare scientific stuff, but a common > programs, that most people use every day. Putting them on a small tmpfs > will break them. Putting them on large tmpfs may slow down or freeze > the system due to heavy swapping. I wanted to make the argument that php uses /tmp as the session save path (it used to be there), but discovered, that someone has re-configured that to now be in /var/lib/php5, so I'd say put that on a tmpfs as well. Lots of small files with frequent accesses... whoever wants those on a real disk?!? > is to extend partitioner with a new option "Configure tmpfs partitions". > That option should allow to mount anything as tmpfs (not just /tmp, but > also /var/run, /media, /opt or whatever the user might want). It would be > nice to have the `size` option there as well. Having /var/run on a tmpfs may be a good idea, though. > Q: I extremely care about my / fs and want to use it as rarely as possible. > A: There're a lot of options: >* symlink or mount-bind /tmp to i.e. /home/tmp >* have /tmp on a separate partition (common and probably best solution) >* you hate partitions? make /home/tmp_ext3fs.img and loop-mount it. >That would solve your problem without making your system unstable because >of high memory usage, or break programs because of no free space in /tmp. It used to be /usr/tmp in olden days, just to have that out of / and give it more space at the same time, too. One might also consider to then merge /tmp with /var/tmp, eg. by way of symlinking them, as the one who is strapped on memory, might as well be strapped on Internet bandwidth to download that unfinished ISO that blew up his /tmp on tmpfs, then re-getting the rest of it after rebooting... > Q: /tmp on tmpfs increases apps performance. > A: What apps? Real apps don't write files during performance-critical >operations. Even if they do, they write large files. And large files are Dead wrong. Eg. web application's session data very frequently goes there, and/or the sysadmin wants it to go onto a tmpfs. > Q: gcc writes small files in /tmp > A: usually it does not, especially when used with -pipe option Changing all (generated?) Makefiles floating around out there, and getting the changes committed upstream to actually benefit from that is easier than using a tmpfs, of course. > That's it. Thanks for reading. > > PS: should I had filled this as a bugreport? I request that the bug be tagged wontfix. Kind regards, --Toni++ -- 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/20120528110346.ga19...@spruce.wiehl.oeko.net
Re: Packaging on GitHub ?
On Sun, May 27, 2012 at 05:58:55PM +, Thorsten Glaser wrote: > Charles Plessy dixit: > >upstream source moved to GitHub, and we would like to try to maintain the > >Debian package there as well. > > This is not a good idea: http://mako.cc/writing/hill-free_tools.html MUCH seconded. Thanks for sharing the link! Kind regards, --Toni++ -- 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/20120528111603.gb19...@spruce.wiehl.oeko.net
Re: Moving /tmp to tmpfs makes it useless
On Mon, 28 May 2012 13:03:47 +0200 Toni Mueller wrote: > It's not, see below. Also, most of the time, /tmp goes into / (on > smaller systems), and is thus typically *very* much limited in space. If the theory is to design for the "trained chicken" install (and it still is, right?), then / gets the entire disk minus whatever gets assigned to swap. The sort of administrator who knows why she would want /home, /usr, and /var mounted separately can also be trusted to do whatever the right thing for her situation is with /tmp. HOWEVER, what's currently missing is the ability in the installer to put /tmp on / (AFAICT). Giving it a partition puts it on disk, not doing anything puts it on tmpfs. Yes, it's a single-line change to fstab on your first boot, but still. Over the past decade or so of writing one-off scripts I have (rightly or wrongly) formed the habit that /tmp is a 1777 area of disk where I can dump large things I don't want in memory at the moment (and therefore also a poor man's very asynchronous IPC domain -- yes, it's not supposed to be, but I think we'll also all admit we've done that at some point). Much better developers than me seem to have formed this opinion too (cf browsers' behavior while it waits for you to tell it what to do with an unknown content-type: it's a disk-based pipe to whatever program you pick to open it, except now it's a memory-based pipe, and I think /tmp on tmpfs is breaking those developers' expectations). We may be wrong, but apparently a lot of us don't yet trust the swapping algorithm to put the right stuff on disk yet. Also, I'd be more comfortable with tmpfs if it could be quota'd with standard quota tools. > Having /var/run on a tmpfs may be a good idea, though. Gah! I want *somewhere* I can park stuff on disk. Why are people so against that? Can we at least keep /var/tmp? (But I'm more worried about /var filling up than /, personally.) And how many of these are we going to do? Right now on my Squeeze laptop I have /lib/init/rw, /dev/shm, and /tmp. Do we really need more things that look like on-disk directories but aren't? (Then again I'm still grumpy about sysfs.) Though actually /var/run makes more sense than /tmp, since it's pretty much just for pids and sockets. > > I request that the bug be tagged wontfix. Despite what I said above, I agree. The argument about web applications' session info is persuasive, and that's probably the hardest set of apps to change. As long as we are sure programs aren't dropping arbitrarily large files into it (I'm looking at you, Iceweasel...) and as long as there's *some* section of actual disk somewhere that's 1777. Also, this is rapidly approaching two sets of choir-preaching, so I'll bow out after this. Cheers, Weldon -- 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/20120528082652.f9a53baa.wel...@b.rontosaur.us
Re: Moving /tmp to tmpfs makes it useless
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote: As you wrote, nothing is infinite. I don't think that /tmp is worse than /home like other said. Your /home could become full as well. Your /home could be a network share like NFS and /tmp a local partition, so you don’t want to use /home for temporary downloads or caches. Besides that, on multi-user systems /tmp can be used to share files (I’ve downloaded the current ISO image to /tmp, so you can copy it from there). This is much better than to open access to your $HOME directory. And I think, it is clear as well that your disk space will always be much bigger than your RAM size. It seems very strange to waste RAM for a ramdisk to free disk space. I don’t think that there is a sane default as well. A desktop system which runs several VMs will probably not like to waste RAM for tmpfs. But since we are talking about defaults, how does d-i partition your hard disk in the following cases? a) Notebook 4 GB RAM 250GB disk b) PC 4 GB RAM 2TB disk If it creates 4 or 8 GB swap and a single partition for the remaining disk, tmpfs will never beat disk space. If the admin decides to partition manually he will know what he does (or he should ;-). My PC is normally used remote and acts more like a server. It uses tmpfs, but its size is only 635M, so I already have problems creating a CD ISO. Since the system has 2 TB disk space, my next repartitioning will create a separate /tmp with about 10 or 20 GB, much easier to spare than RAM. So I don’t see the advantage of using tmpfs as default, but d-i should offer the option to put /tmp on tmpfs if the admin wishes it. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Moving /tmp to tmpfs is fine
On Mon, May 28, 2012 at 01:59:24AM +0100, Ben Hutchings wrote: I don't recall that being common practice on any multi-user Unix-like system I've used. (It's also not something a Windows user would expect, Well, it was back in my university days, and it still is where I work. Maybe „multi-user” is wrong, but telling other user that the ISO lies on my system in /tmp is much easier than to tell them a location in my $HOME and to make sure they can access ist. as they already get per-user temporary directories.) One of the first things I do after a Windows installation is to create c:\temp. ;-) Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Bug#674904: ITP: libsiw -- user space library for SoftiWARP device
Package: wnpp Severity: wishlist Owner: Luk Claes * Package name: libsiw Version : 0.9? Upstream Author : Bernard Metzler * URL : https://gitorious.org/softiwarp/userlib * License : GPL-2 or BSD Programming Lang: C Description : user space library for SoftiWARP device A software-based iWARP stack that runs at reasonable performance levels and seamlessly fits into the OFA RDMA environment provides several benefits: - As a generic (RNIC-independent) iWARP device driver, it immediately enables RDMA services on all systems with conventional Ethernet adapters, which do not provide RDMA hardware support. - Soft-iWARP can be an intermediate step when migrating applications and systems to RDMA APIs and OpenFabrics. - Soft-iWARP can be a reasonable solution for client systems, allowing RNIC-equipped peers/servers to enjoy the full benefits of RDMA communication. - Soft-iWARP seamlessly supports direct as well as asynchronous transmission with multiple outstanding work requests and RDMA operations. - A software-based iWARP stack may flexibly employ any available hardware assists for performance-critical operations such as MPA CRC checksum calculation and direct data placement. The resulting performance levels may approach those of a fully offloaded iWARP stack. . This is the user space library that can be used with the SoftiWARP kernel module. -- 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/20120528135221.29082.7032.report...@station.luk.local
Re: Moving /tmp to tmpfs makes it useful
On 28/05/12 08:15, Miles Bader wrote: > Salvo Tomaselli writes: >>> This is indeed a valid point. But that’s no regression; /tmp has >>> always been for small short-lived files, and /var/tmp for those >>> that are not one of them or not both. >> >> You just made up this difference. > > No he didn't, it's common practice from unix-days-of-yore (though it > was /usr/tmp or whatever back then...). > > -miles > common practice? sorry I don't know about any standard which such name. Can you link here any document which says that its recommended the use of /tmp for "small" files? -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#674905: ITP: softiwarp-kernel -- Soft-iWARP kernel module implementing iWARP on top of tcp kernel sockets
Package: wnpp Severity: wishlist Owner: Luk Claes * Package name: softiwarp-kernel Version : ?? Upstream Author : Bernard Metzler * URL : https://gitorious.org/softiwarp/kernel * License : GPL-2 or BSD Programming Lang: C Description : Soft-iWARP kernel module implementing iWARP on top of tcp kernel sockets A software-based iWARP stack that runs at reasonable performance levels and seamlessly fits into the OFA RDMA environment provides several benefits: - As a generic (RNIC-independent) iWARP device driver, it immediately enables RDMA services on all systems with conventional Ethernet adapters, which do not provide RDMA hardware support. - Soft-iWARP can be an intermediate step when migrating applications and systems to RDMA APIs and OpenFabrics. - Soft-iWARP can be a reasonable solution for client systems, allowing RNIC-equipped peers/servers to enjoy the full benefits of RDMA communication. - Soft-iWARP seamlessly supports direct as well as asynchronous transmission with multiple outstanding work requests and RDMA operations. - A software-based iWARP stack may flexibly employ any available hardware assists for performance-critical operations such as MPA CRC checksum calculation and direct data placement. The resulting performance levels may approach those of a fully offloaded iWARP stack. . This is the kernel module that can be used by the userspace library libsiw. -- 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/20120528140051.29268.17776.report...@station.luk.local
Funds
Hi Debian, Are you still interested in learning more about green funds? Kind regards, Louise Smith Investment Consultant Offshore Consulting Group Email: l...@ocgbiz.com www.ocgbiz.com Tel: (0034)695 487 889 This e-mail and all information contained in it is confidential and may be legally privileged. If you are not the intended recipient, your access to this e-mail is unauthorised. Any use, dissemination, distribution, publication or copying by you of this e-mail or any of the information contained in it is prohibited and may be unlawful. The content of this e-mail and any attachments sent with it may have been altered without the consent or knowledge of the author. If you have received this email in error, please contact l...@ocgbiz.com and delete this e-mail from your system. Your co-operation is appreciated. Please don't print this e-mail unless you really need to. -- 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/20120528141857.10013lgq4o3ut...@rocket.xssl.net
Re: Moving /tmp to tmpfs is fine
On 05/28/2012 04:46 AM, Serge wrote: > The truth is that tmpfs IS FASTER in some cases. The problem is that > *nobody* can notice that on *real* applications. Serge, I'm on your side of the discussion, but the above is simply not truth. And by the way, that's not the issue. The issue is potential breakage, which we want to avoid *at all costs*. Thomas -- 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/4fc39e64.10...@debian.org
Re: Moving /tmp to tmpfs is fine
On 28/05/12 17:48, Thomas Goirand wrote: > On 05/28/2012 04:46 AM, Serge wrote: >> The truth is that tmpfs IS FASTER in some cases. The problem is that >> *nobody* can notice that on *real* applications. > Serge, I'm on your side of the discussion, but the above is simply > not truth. And by the way, that's not the issue. The issue is potential > breakage, which we want to avoid *at all costs*. > > Thomas > > I think this is a valid point. We should know what applications and workloads get a _measurable_ benefit by using tmpfs for /tmp instead of using a normal filesystem. If we are optimizing things for just a synthetic benchmark that does fsyncs on lot of small files then we are loosing the perspective of reality. We should have things on the table like the following to support the idea that tmpfs really gives any performance benefit in the day-to-day real-world-tasks of people and not only on synthetic benchmarks - Program X is a % faster when using tmpfs for /tmp - Compiling the Linux Kernel is a % faster when using tmpfs for /tmp - Task Z is a % faster when using tmpfs for /tmp - [...] Regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: zlib and biarch/triarch
On Tue, May 22, 2012 at 05:06:25PM -0700, Steve Langasek wrote: > Of course, all of these packages appear to be specific to amd64, so I don't > know why Mark would be adding new biarch packages for s390. You should > probably ask him. Ask the s390x folks, they asked for them. Though what on earth inspired them to name the new architecture such that the old architecture name is a substring of the new name is beyond me... As far as I can tell nobody is really using the biarch packages on most architectures, it's a check box feature for the architectures - a couple use them to build some of the bootloaders but not many. Aside from this sillyness with the s390x architecture name they're generally zero effort so it's not a big deal. -- 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/20120528162456.gd27...@sirena.org.uk
Re: zlib and biarch/triarch
On Tue, May 22, 2012 at 12:14:49PM +, Thorsten Glaser wrote: > Seeing the trouble broonie has with zlib, why are those > packages still built anyway? Can???t they please go away? The biarch packages really aren't any bother, the issue with s390x has been having to jump through hoops due to the fail with using -m31 and with the naming of the architecture. -- 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/20120528162617.ge27...@sirena.org.uk
Re: zlib and biarch/triarch
Mark Brown (28/05/2012):
> Ask the s390x folks, they asked for them. Though what on earth inspired
> them to name the new architecture such that the old architecture name is
> a substring of the new name is beyond me... As far as I can tell nobody
> is really using the biarch packages on most architectures, it's a check
> box feature for the architectures - a couple use them to build some of
> the bootloaders but not many.
Reminds me of arm/armel.
(I won't say a word on mips/mipsel and {*-,}{i386,amd64}. ;-))
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: Exported (ba)sh functions in the environment
[Philip Ashmore] > On my machine running "set > set.txt && ls -lsa set.txt" reveals that my > environment contains 225517 of "stuff" - some of it is even being > taken up by > exported function definitions! As mentioned earlier, 'set' is not reporting much more than the environment exported to external processes and scripts. Observe: $ set | wc -c 189097 That's my interactive bash session, including a huge chunk from bash-completion. But... $ env | wc -c 792 That's all that actually gets exported to external processes, including shell scripts. $ sh -c set | wc -c 908 $ sh -i -c set | wc -c 908 That's dash, including the 792 bytes of exported environment noted earlier. Interactive mode (-i) seems to make no difference. $ bash -c set | wc -c 1371 $ bash -i -c set | wc -c 189101 ...and that's bash, which does a bit more at startup than dash. Interactive mode (-i) enables bash-completion and other stuff. Big difference! But probably no shell scripts ever run in interactive mode. -- 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/20120528181744.gb3...@p12n.org
Re: Exported (ba)sh functions in the environment
On 28/05/12 19:17, Peter Samuelson wrote: [Philip Ashmore] On my machine running "set> set.txt&& ls -lsa set.txt" reveals that my environment contains 225517 of "stuff" - some of it is even being taken up by exported function definitions! As mentioned earlier, 'set' is not reporting much more than the environment exported to external processes and scripts. Observe: $ set | wc -c 189097 That's my interactive bash session, including a huge chunk from bash-completion. But... $ env | wc -c 792 That's all that actually gets exported to external processes, including shell scripts. $ sh -c set | wc -c 908 $ sh -i -c set | wc -c 908 That's dash, including the 792 bytes of exported environment noted earlier. Interactive mode (-i) seems to make no difference. $ bash -c set | wc -c 1371 $ bash -i -c set | wc -c 189101 ...and that's bash, which does a bit more at startup than dash. Interactive mode (-i) enables bash-completion and other stuff. Big difference! But probably no shell scripts ever run in interactive mode. Plus "set" is built-in and so doesn't run in a sub-shell, while "env" is a program so it is run in a sub-shell, so non-exported variables aren't available. I guess I'm confused as to why bash completion needs these. Philip -- 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/4fc3c66e.1040...@philipashmore.com
Re: Moving /tmp to tmpfs is fine
[Ben Hutchings] > We should be thinking about implementing per-user temporary directories > and making sure that programs respect $TMPDIR. Yes, per-user temp directories is a good idea. Installing the libpam-tmpdir package enable this by default, and beside some problems with the root user (bad TMPDIR is inherited when I restart services using /etc/init.d/ scripts), it work well. Perhaps it should be extended to allow the directory to be below ~/ instead of below /tmp/. :) It make it very easy to spot the programs not respecting $TMPDIR. :) > (On Linux it's also possible to give each user a different /tmp > through mount namespaces. I'm not sure whether that's compatible > with historical use of /tmp by the X window system.) This sound a bit more scary, yes. -- Happy hacking Petter Reinholdtsen -- 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/2fltxz0p18t@login2.uio.no
Re: Moving /tmp to tmpfs is fine
On 05/28/2012 04:47 PM, Bernhard R. Link wrote: > I personally think having tmpdir on /tmp might be a good default for > new systems. If systems get changed to that from something else on > upgrade without asking, I consider that quite an ugly bug. > And you're not the only one. It seems that at least one member of the release team (IMO rightly) think this way as well. See #674517. BTW, I don't think it was possible to hide the RAMTMP variable/switch better than it is right now in SID... :) Thomas -- 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/4fc3d1ff.8020...@debian.org
Re: Exported (ba)sh functions in the environment
[Philip Ashmore] > I guess I'm confused as to why bash completion needs these. Easy enough to read /etc/bash_completion and /etc/bash_completion.d/* and see for yourself why it needs these. bash-completion is full of special cases to "do the right thing" in hundreds or thousands of different circumstances. If it were as simple as "offer a list of filenames when you hit tab", that's already built in to bash and we wouldn't need bash-completion as a separate package. As a _very_ simple example, if you type 'kill ', you get a list of current process IDs. If you type 'kill -', you get a list of signals, plus the common options -l and -s. If you can think of a way to implement this same stuff (and remember, bash-completion supports a _lot_ more complex cases than 'kill') without adding 200 kB of shell functions to bash's runtime, by all means, do it and see how it works out. Peter -- 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/20120528194448.gc3...@p12n.org
Re: Exported (ba)sh functions in the environment
Peter Samuelson writes: > If you can think of a way to implement this same stuff (and remember, > bash-completion supports a _lot_ more complex cases than 'kill') > without adding 200 kB of shell functions to bash's runtime, by all > means, do it and see how it works out. What would seem interesting would be a way to autoload bash completion support for each command ... as it would seem not uncommon to have shell sessions where the user never tries to use completion for 99% of the commands handled. [or does it already do this?] -miles -- Consult, v.i. To seek another's disapproval of a course already decided on. -- 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/87obp7aioj@catnip.gol.com
Re: Exported (ba)sh functions in the environment
On Tue, May 29, 2012 at 9:18 AM, Miles Baderwrote: > What would seem interesting would be a way to autoload bash completion > support for each command ... as it would seem not uncommon to have shell > sessions where the user never tries to use completion for 99% of the > commands handled. > > [or does it already do this?] It already does this: http://packages.debian.org/changelogs/pool/main/b/bash-completion/current/changelog#version1:1.90-1 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6fuwbc4jjxtmksxpnxl91rtb8f-+-jy_jptyzixuca...@mail.gmail.com
Re: Moving /tmp to tmpfs is fine
On 05/29/2012 03:13 AM, Petter Reinholdtsen wrote: > Perhaps it should be > extended to allow the directory to be below ~/ instead of below > /tmp/. :) > I don't think so. As other pointed out, your /home could be remote (over NFS?), and then slow, while /tmp is normally on your local machine, so moving the temp folder in ~/ will potentially slow them down, and break quota. What's the folder structure in /tmp then? /tmp//$USER? Thomas -- 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/4fc44d4e.6030...@debian.org
Bug#674984: Moving /tmp to tmpfs is fine
Package: libpam-tmpdir Severity: wishlist ]] Petter Reinholdtsen > [Ben Hutchings] > > We should be thinking about implementing per-user temporary directories > > and making sure that programs respect $TMPDIR. > > Yes, per-user temp directories is a good idea. Installing the > libpam-tmpdir package enable this by default, and beside some problems > with the root user (bad TMPDIR is inherited when I restart services > using /etc/init.d/ scripts), it work well. Perhaps it should be > extended to allow the directory to be below ~/ instead of below > /tmp/. :) Thanks for this suggestion, filing it in the BTS. (JFTR, it won't be the default, but I don't see the harm in making it an option.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87r4u3vbpb@xoog.err.no
Re: Moving /tmp to tmpfs is fine
]] Thomas Goirand > What's the folder structure in /tmp then? /tmp//$USER? /tmp/user/$UID is the default. It can be overridden, but not in a manner that's compatible with Petter's suggestion. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87mx4rvblx@xoog.err.no
Re: Moving /tmp to tmpfs is fine
On Tue, 2012-05-29 at 12:15 +0800, Thomas Goirand wrote: > What's the folder structure in /tmp then? /tmp//$USER? It's the Wild West over there. You'll often see something like /tmp/$procname/$pid/blah or /tmp/$procname/$user/blah, or just /tmp/$some_hash_of_who_knows_what/blah. FHS is uncharacteristically laconic: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES Weldon -- 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/1338267368.2617.0.camel@minerva
Re: Packaging on GitHub ?
Brian May writes: >>> This is not a good idea: http://mako.cc/writing/hill-free_tools.html >> >> MUCH seconded. Thanks for sharing the link! > > I don't see the problem, github is just a hosting provider. Unlike, > say Bitkeeper, you are free to make git clones anywhere, entirely with > open source software, and are in no way locked down to using github. > > Except maybe features like the issue tracking, which may not be really > appropriate for Debian packages anyway. Debian has its own BTS that > should be used. Github issue tracking is very bare-bones, and they provide a convenient API that can be used to extract all information from it (or add new info); moving a project from github to a new service wouldn't be a huge task (if the new service provides equivalent functionality). Moreover, these days it's not uncommon to maintain a project on multiple sites simultaneously... So the amount of "lockin" with github seems fairly minimal. [Mako-hill's paper is well-intended, but seems a little dated in its assumptions.] -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- 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/87ipffa834@catnip.gol.com
Re: Moving /tmp to tmpfs is fine
Thomas Goirand writes: >> Perhaps it should be >> extended to allow the directory to be below ~/ instead of below >> /tmp/. :) >> > I don't think so. As other pointed out, your /home could be > remote (over NFS?), and then slow, while /tmp is normally > on your local machine, so moving the temp folder in ~/ will > potentially slow them down, and break quota. ... yeah, my homedir is in NFS, and I get no end of grief from the bazillion packages in debian that blithely cache vast quantities of (often very uninteresting) data in random subdirs of $HOME... and then expect accessing it to be very fast :[ -miles -- Year, n. A period of three hundred and sixty-five disappointments. -- 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/87d35na73z@catnip.gol.com
Re: Moving /tmp to tmpfs is fine
Miles Bader writes: > bazillion packages in debian that blithely cache vast quantities of > (often very uninteresting) data in random subdirs of $HOME... and then Fortunately there is some movement towards the use of XDG_CACHE_DIR (defaults to ~/.cache). -- 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/84wr3vk0id@sauna.l.org
Re: Packaging on GitHub ?
I am thinking about a more general topic like: Managing packaging on VCS services other than Alioth I think it is not good to focus on a specific service or tool. Just 2 cents. -- Yao Wei P.S. AFAIK pkg-ime is currently syncing pkg-ime packaging with GitHub for backup, for checking out them at Alioth's downage. -- 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/CAJkNRTFa8naM+5-k++BPxafQePTaS4KxKQ=wb49dy8uywre...@mail.gmail.com
Re: Packaging on GitHub ?
On 28 May 2012 21:16, Toni Mueller wrote: >> This is not a good idea: http://mako.cc/writing/hill-free_tools.html > > MUCH seconded. Thanks for sharing the link! I don't see the problem, github is just a hosting provider. Unlike, say Bitkeeper, you are free to make git clones anywhere, entirely with open source software, and are in no way locked down to using github. Except maybe features like the issue tracking, which may not be really appropriate for Debian packages anyway. Debian has its own BTS that should be used. Anyway, if github is still a problem, try http://gitorious.org/ - I believe that it is based entirely on open source software. -- Brian May -- 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/caa0zo6ck1qok8w3pc1760m5y8+gy9ykwfegkvcm3nolxg6r...@mail.gmail.com
Bug#674977: ITP: hime-table-dayi3 -- Dayi 3 table for hime input method
Package: wnpp Severity: wishlist Owner: "Yao Wei (魏銘廷)" * Package name: hime-table-dayi3 * URL : http://hime.luna.com.tw/ * License : Proprietary (Not modifiable) Description : Dayi 3-key table for hime input method This is one of the Chinese input method table called Dayi. This table is shipped with hime source code but the package uses dfsg-sanitized tarball packed by hime upstream, and I am packaging this to fulfill the missing piece. It is considered non-free because the license does not allow users to modify the relations, though changes on the presentation of the relations is permitted. Basically, its packaging is the same reason as gcin one (#674680) but with different IME. signature.asc Description: Digital signature
