Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote: > * Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]: > > We'd just have to teach the tool to binNMU all arches when the target > > package would need it due to multiarch. Release team requests a binNMU of a > > package for some arch, the tool notices it has to do them all because of > > multi-arch constraints, and replicates the request for all other arches. > > Just that this won't do it, because the changelogs for the different > arches will be binary different, so no win. > > However, we discussed that during the multi-arch bof last Debconf, and > came to the conclusion that it would be better to not modify the > changelog as we do now, but instead create a new file > changelog.$arch.$version with the binNMU. This is a bit more > complicated because it can't be done as of now just within the source > package. As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. This has (at least) the following advantages: * no need to concat different files to get the complete changelog. * the version in the changelog would match the package binary version. * the changelog file would *always* get to be referred by the same name regardless of the package being native, binNMUed or otherwise. * changelog extractors (like apt-listchanges) would not need (eventually) to extract the whole .deb data member to get the changelog, it would just need to extract the control member, and get a fixed filename. They would stop needing to hardcode possible paths to the files too. This still leaves the NEWS.Debian file but then maybe that should also be considered metadata... * dpkg can gain new commands to return/show these files reliably w/o needing (eventually) to hardcode the distribution's specific path (which is a matter of fileystem policy dpkg does not really need or has to know). * dpkg eventually could do a way better job at reducing duplicated data, by for example transparently hardlinking them, instead of our ad-hoc doc dir symlinking. * dpkg could reduce space usage by transparently compressing them with something better than gzip. * (minor) it's a common pattern to want to exclude all of /usr/share/doc/pkg but the copyright file, storing it elsewhere would avoid that. To that end, last month I cooked a preliminary patch for dpkg to add two new commands: --show-changelog and --show-copyright, that take a package name and print to stdout (through a pager if on a terminal) either of those files, and fallback to a configurable set of paths on the filesystem if the requested file is not in the database (decompressing them if need be). regards, guillem -- 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/20120610080128.ga8...@gaara.hadrons.org
Bug#676859: marked as done (general: Switch from ethernet to wifi connection problem)
Your message dated Sun, 10 Jun 2012 10:47:14 +0200 with message-id <201206101047.14893.hol...@layer-acht.org> and subject line Re: Bug#676859: general: Switch from ethernet to wifi connection problem has caused the Debian Bug report #676859, regarding general: Switch from ethernet to wifi connection problem 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.) -- 676859: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676859 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: important Tags: upstream Initial situation : I am connected to the internet by using an ethernet connexion. I use IPV4. When I switch to a wifi connection (by using nm-applet) : - I have a correct IP - I can't resolve domains - As root, when I ping a domain : "ping sendmg: operation not permitted" To resolve it, i must reboot. I don't use a firewall and I am the network administrator. Ifconfig: http://wall.deblan.fr/xa9/texte/1/ lspci: http://wall.deblan.fr/xaa/texte/1/ -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On Sonntag, 10. Juni 2012, Simon Vieille wrote: > When I switch to a wifi connection (by using nm-applet) : > - I have a correct IP > - I can't resolve domains > - As root, when I ping a domain : "ping sendmg: operation not permitted" > To resolve it, i must reboot. > I don't use a firewall and I am the network administrator. then please fix your network. --- End Message ---
Re: gnome is completely f^Mmessed up
On 06/08/2012 09:15 AM, Norbert Preining wrote:
Hi everyone,
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-fileroller.so
after log out and log in it sometimes works
starting it manually most of the times work, but not always
- ssh/gpg agent: most of the time just is completely useless
either does not ask, or just segfaults in libglib-2.0
- plugging/unplugging power cord makes gnome-shell crash (known bug)
- ...
When I finally manage to get a running session, then out of nothing
the blue whale appear, BSOD.
Is this a joke? Are we going to release that in June/July/whenever?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live& Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
PEEBLES (pl.n.)
Small, carefully rolled pellets of skegness (q.v.)
--- Douglas Adams, The Meaning of Liff
I switched to xfce4 after all.
I totally agree with points outlined by Roland Mas that gnome3 design is
too intrusive, but even without taking into account design changes, my
~/.xsession-errors looks like gnome3 is still beta.
Best regards,
Alex
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd46989.1090...@biotec.tu-dresden.de
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 08, 2012 at 04:59:14PM +0300, Serge wrote:
> 2012/6/8 Petter Reinholdtsen wrote:
>
> > [Wouter Verhelst]
> >> - You could mount your mail spool there, and make things go blazingly
> >> fast [1]
>
> You could, but this is not related to /tmp.
Sure; that was a joke, after all.
> >> - There's no danger of a symlink attack or similar with things like
> >> tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the
> >> system, and /tmp is clean again, no matter what was there before. This
> >> is more than just a convenience.
>
> This works for many years. /tmp on disk is also cleaned on reboot.
Yes, but that does have its downsides:
- It can be surprising to those who don't know about that fact
("whaddaya mean, it's gone? This is disk, right?")
- Removing files takes time, especially if there's large amounts of
files in that directory.
The two combined once made me wonder why booting my laptop took much
longer than usual after I had just restored some dozens of gigabytes
from bacula (which stores files in /tmp by default), and had forgotten
about the automatic cleaning.
When /tmp is in a tmpfs, it's easy to connect the dots if it's empty on
the next boot, and even easy to understand that restoring there (and
then rebooting) isn't going to be very helpful.
Also, the symlink attack thing isn't just something I made up;
tmpreaper's REAME.Debian actually warns about that.
[...]
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
--
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/20120610102032.ga9...@grep.be
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote: > Some people asked for a thread summary. So here it is. [Lots of drivel, including thoroughly debunked statements, snipped. Seriously, can't you even read what's written to you? Sorry for being angry, but there's a limit to how many times you can have folks explain the basics of page cache without starting to suspect malice.] But, for the rest of us, here's a different summary. And note that, even though I'm a strong proponent of tmpfs, I say it might be better to skip it for wheezy -- so there's a chance this summary is not as biased. There are exactly two downsides: * In the "everything on one partition" scheme, there is less space available on swap that on /. • This is the big show-stopping problem. * A test case was shown where tmpfs is somewhat slower (by 15%), with reduced interactivity as well. • Needs some investigation; is not a typical case as you'd need large files on /tmp, nonlinear access patterns and high memory pressure at the same time. Still, it needs to be fixed somehow. And upsides: * Massive speed increase for I/O operations: • if syncs are involved: ~1x • if the file survives longer than 5-30 seconds: by disk's speed • if the disk is not touched at all¹: ~10x • if there's a writeout: depending on file/metadata ratio (no need for journaling/barriers) Note that these speed-ups touch I/O on /tmp only. Obviously, a process that's CPU-bound won't see noticeable gains, and others typically do quite a lot of things other than I/O. * No spin-ups of laptop drives. • There's always a spin-up even if the file has been deleted before that 5-30 seconds passes. Laptop mode reduces these somehow but you'd have to set dirty_expire_centisecs to some giant value to make them not have a practical effect, risking losing actual data. * Less wear of SSD drives. • Contrary to Serge's claims, SSDs are not an oddity, and it's not unlikely these will be a majority before wheezy becomes oldstable. I intentionally did not include cases not involving typical use, like NFSed or read-only / (we can assume a competent admin there), user errors (like comparing spaces you configured yourself), or merits of LVM with unallocated disk space (ie, a competent or semi-competent admin) vs dynamic swap files. This basically boils down to: efficiency vs failures for a newbie user. Folks in this thread tend to agree that it's the user who can't deal with partitions or the notion of separate space on separate filesystems who needs the most help, as the rest of us can configure the system. Still, it'd not a nice thing to need to do all those repetitive tweaks you may not even know about (like mounting everything noatime, again a good thing even compared to relatime). So, I'd say: * let's play it safe and not default to tmpfs for wheezy * do it properly later Current size defaults for /tmp are naive to the point of brokenness: with modern systems not being expected to ever use swap, we'd want to cap /tmp at 100% of swap rather than mere 20% -- but it's tricky to tell apart that from systems that actually do need swap for memory. And the same RAM/swap combination can need different settings based on what the system is supposed to do. But no matter how we tweak the ratio, it won't let some hapless user plop a 50GB file into /tmp "because I have a lot of free space". This is not an insurmountable problem: /tmp might use some form of overlay that uses tmpfs for regular use and starts shunting to some area other than swap once it sees it is being used for large files. Or alternatively, there could possibly be a dynamic swap file on / earmarked for tmpfs pages only (not implemented yet?). Or... Too bad, any of these solutions would need a lot of testing, something for which there simply isn't time before wheezy. Let's go back here after the release. [¹]. During a short test; there'll be a spin-up later to write the directory even if the file has been deleted already. This is O(1) though. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote: > Some people asked for a thread summary. So here it is. Sorry, but this is a biased summary, and therefore useless for what it intends to be. [...] > "/tmp on tmpfs is good" quotes > == > No real quotes here. Most of this and other threads were about why > /tmp on tmpfs is not that bad. But there're no real quotes explaining > why it's good. This is wrong. There were several (including by me). You dismissed them, not considering them valid, but that doesn't mean they are. If you're going to post a thread summary, please do not filter out information you don't agree with. Otherwise you're not posting a thread summary, you're posting a 'my side of the fence' summary. Which is fine, but not the same thing. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120610105120.gb9...@grep.be
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120610 10:08]: > As I mentioned in the long ref-counting thread, I strongly disagree this > is a correct solution, it just seems like a hack to me. Instead I > think we should consider changelog (and copyright as long as it's in > machine parseable format) as dpkg metadata (something dpkg misses > compared to rpm or other package managers for example) and as such they > should go into the .deb control member, which would end up in the dpkg > database w/o any kind of file conflict, and very minor packaging effort > as for most that would be handled by helpers. I'm fully happy to see that solved in whatever way. However, getting it sorted out for binNMUs seems like some kind of priority to me. Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. Andi -- 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/20120610115223.gy2...@mails.so.argh.org
Planned changes to Debian Maintainer uploads
Hi, (Please send followup messages to -project.) The ftp team wants to change how allowing Debian Maintainers to upload packages works. The current approach with the DM-Upload-Allowed field has a few issues we would like to address: - It applies to all DMs listed as Maintainer/Uploaders. It is not possible to grant upload permission to only a specific DM. - It is tied to the source package so can only be changed with a sourceful upload. - It allows DMs to grant permissions to other DMs. We plan to instead implement an interface where developers upload a signed command file to ftp-master to grant upload permissions instead, similar to dcut. This could end up looking similar to this: --8<---cut here---start->8--- Archive: ftp.debian.org Action: dm Fingerprint: [...] Allow: a-source another-source Deny: yet-another-source Reason: We want people to say why they changed that. Action: dm Fingerprint: [...] Allow: yet-another-source Reason: ... --8<---cut here---end--->8--- Here "Allow" would add additional packages to the list of packages the Debian Maintainer (identified by his key fingerprint) may upload. "Deny" would be used to revoke this permission again[1]. Any DD may use this to grant/revoke upload permissions to existing packages (ie. at least in NEW); referring to non-existing packages will be an error (at least for Allow). [1] Having the same package in both Allow and Deny at the same time would result in revoking permissions. The "Archive" field is to prevent forwarding the commands file to another dak installation. Granting upload permissions for backports.d.o will require sending a commands file explicitly to backports-master. We will also drop the check that the DM is in Uploaders of the previous version and Changed-By of the current version. This has caused problems for DMs that have multiple uids attached to their key in the past. (This technically allows DMs to sponsor uploads to packages they have upload permissions for and to grant upload permissions to packages the DM does not maintain (yet). This should not be abused.) Please note that we currently do not know when we might get around to implement these changes. Ansgar for the ftp team pgpMRcDTflpXr.pgp Description: PGP signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote: > Perhaps we could add the binNMU entry for the moment and fix the rest > later? Or whatever would make you more happy. Just I'd like to be able > to schedule binNMUs again on ma-packages. There is no such block in place. Kind regards Philipp Kern signature.asc Description: Digital signature
Handling of changelogs and bin-nmus
[ Dropping the bug report, moving the discussion to debian-dpkg too ]
Hi,
On Sun, 10 Jun 2012, Guillem Jover wrote:
> On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote:
> > However, we discussed that during the multi-arch bof last Debconf, and
> > came to the conclusion that it would be better to not modify the
> > changelog as we do now, but instead create a new file
> > changelog.$arch.$version with the binNMU. This is a bit more
> > complicated because it can't be done as of now just within the source
> > package.
>
> As I mentioned in the long ref-counting thread, I strongly disagree this
> is a correct solution, it just seems like a hack to me. Instead I
> think we should consider changelog (and copyright as long as it's in
> machine parseable format) as dpkg metadata (something dpkg misses
> compared to rpm or other package managers for example) and as such they
> should go into the .deb control member, which would end up in the dpkg
> database w/o any kind of file conflict, and very minor packaging effort
> as for most that would be handled by helpers.
I agree that we should move into this direction. Still I believe it's
important to distinguish "source changelog" and "binary changelog".
And while we might not want to keep this distinction in the generated
package, we should have it at the source package level.
As such, I suggest that we handle "binary rebuild" differently:
- debian/changelog is left unmodified since it's the source changelog
=> it defines the ${source:Version} substvar
- debian/changelog.binary-rebuild (or any other better name) is created
when we want to do a bin-nmu
=> it defines the ${binary:Version} and it's not included in
the generated source package
This allows us to get rid of the special-casing of bin-nmu in dpkg where
we only support one extension (+bX).
We have many other cases where it would be helpful to be able to do such
binary-only rebuild in different environments and where it might be
interesting to share the same source package.
With this change, current packages would always install the unmodified
changelog and the short term problem would be gone. And obviously it
doesn't preclude moving to the long term solution that you presented.
Instead of just copying debian/changelog to pkg/DEBIAN/ it would copy both
files (or the result of their concatenation).
This is something that is on my relatively short-term TODO list for dpkg.
Guillem, do you agree with this change?
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
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/20120610124028.ge21...@rivendell.home.ouaza.com
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Adam Borowski wrote: >> Some people asked for a thread summary. So here it is. > Seriously, can't you even read what's written to you? Yes, I know it was a biased summary. So as yours. But there's a difference between mine and yours. Mine is based on some real-world applications, yours is based on... what? Can you confirm your words with some real-world use cases, not on artificial tests? > Sorry for being angry, but there's a limit to how many times you can > have folks explain the basics of page cache without starting to suspect > malice. Then stop explaining theories and show some examples. Theories can be wrong, examples are not. You missed some important part of the summary. I skipped almost everything, that was not related to /tmp or was not confirmed by some popular apps. The quotes I left were about *real* applications, mysql, gscan2pdf, dvd burning software, youtube, libreoffice, etc. And since there was no software in the "upsides" list I have nothing to quote. > But, for the rest of us, here's a different summary. And note that, even > though I'm a strong proponent of tmpfs, I say it might be better to skip > it for wheezy -- so there's a chance this summary is not as biased. [...] > And upsides: > * Massive speed increase for I/O operations: Really? Well, I can also say that tmpfs is 1 times slower than ext3. But if I cannot confirm that on a real-world applications, my words mean nothing. So as yours. > * No spin-ups of laptop drives. Have you ever checked that on real laptops? I did. The *only* case when /tmp caused additional spinup to me was a flash video. That's all. I remember no others. Since watching flash video was not the main purpose of that laptop it wasn't even 1% of total spinups. And it was completly solved with vm.laptop_mode=1. Do you want to know what have caused the rest of spinups? The main one was because of browser accessing the profile. That was about half of all the spinups. A major part was due to syslog writing to /var/log (by default it calls fsync on every line, I had to disable that). IIRC, another important part was because of wtmp being modified every time I open new console (I've put a hack to disable that too). One more part, not that large but still noticeable was because of /var/tmp/kdecache, so I reduced it as much as I could and put it to tmpfs (!). A small part of spinups were because of something being read from disk, so I hacked readahead so that it put more files in disk cache. That's all. /tmp was not even among top10. Why do you think that /tmp has anything to do with spinups in real world? > * Less wear of SSD drives. Again, how many disk writes are related to /tmp? Have you ever checked that? Can you confirm your words with some numbers or at least some examples? Do you dismiss the theory (confirmed by Uoti Urpala test script) that tmpfs+swap INCREASE number of writes and are hence bad for SSD? > • Contrary to Serge's claims, SSDs are not an oddity, and it's not >unlikely these will be a majority before wheezy becomes oldstable. I never said that SSD is an oddity, I said, that putting /tmp on tmpfs gives you a feeling of false safety. That was based on my own experience. I `btrace`-d disk usage, I wrote scripts to identify applications doing most of the writes, and they were not related to /tmp. Your words look correct in theory, but they're not true in practice. That's why to avoid theoretical mistakes (any theory can be wrong) I tried to stick to some popular applications, because they're easy to check and they can't be wrong. > This basically boils down to: > efficiency vs failures for a newbie user. Yes. Theoretical efficiency vs practical failures. > So, I'd say: > * let's play it safe and not default to tmpfs for wheezy > * do it properly later There're no real applications benefiting from /tmp on tmpfs now. Nothing will change later. There maybe fewer failures later, but still zero benefits to applications on the real world. Either now or later putting /tmp on tmpfs by default is useless in real world. That's the problem. :) -- Serge -- 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/caoveneqacnt9wrfdocm-qtde2mnfgo0qzqrj-1_5bab8pzm...@mail.gmail.com
Re: Dependency-based boot ordering and sysvinit in unstable
Roger Leigh dixit: >However, if you have any lingering scripts without any LSB headers, >you'll need to fix them up or remove them to allow dynamic boot >ordering to be enabled. This is obviously not too desirable, since sudo apt-get --purge install file-rc insserv- bye //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- 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/pine.bsm.4.64l.1206101408510.16...@herc.mirbsd.org
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge writes: > 2012/6/10 Adam Borowski wrote: > >>> Some people asked for a thread summary. So here it is. >> Seriously, can't you even read what's written to you? > > Yes, I know it was a biased summary. I think you might start to piss off a few people now... Look at what you are quoting above. You introduced your biased summary like this: "Some people asked for a thread summary. So here it is.". I will refrain from further comments. People can judge for themselves. Bjørn -- 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/87txyjp85k@nemi.mork.no
Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
Package: wnpp Severity: wishlist Owner: Henrique de Moraes Holschuh * Package name: amd64-microcode Version : 0.20120117 Upstream Author : AMD, Inc * URL : http://www.amd64.org/support/microcode.html * License : proprietary Description : Processor microcode firmware for AMD CPUs The microcode data file for Linux contains the latest microcode definitions for all AMD AMD64 processors. AMD releases microcode updates to correct processor behavior as documented in the respective processor revision guides. While the regular approach to getting this microcode update is via a BIOS upgrade, AMD realizes that this is an administrative hassle; the Linux Operating System has a mechanism to update the microcode after booting the OS. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20120610143102.ga9...@khazad-dum.debian.net
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Wouter Verhelst wrote: > Sorry, but this is a biased summary, and therefore useless for what it > intends to be. Yes, I know. It's biased toward the /tmp and real-world applications. >> "/tmp on tmpfs is good" quotes >> No real quotes here. Most of this and other threads were about why >> /tmp on tmpfs is not that bad. But there're no real quotes explaining >> why it's good. > > This is wrong. There were several (including by me). You dismissed them, > not considering them valid, but that doesn't mean they are. I dismissed everything that was not related to /tmp or some popular apps. A lot of people (including you) said that tmpfs makes things faster. But there were no examples of popular use-cases becoming faster because of /tmp on tmpfs, so I had nothing to quote. Nobody could provide examples or numbers of how much /tmp on tmpfs reduces amount of writes, and tests showed that tmpfs+swap may even increase amount of writes (hence not always good for SSD), tmpfs does not have 5% overflow safety, it does not help to protect from symlink attack and its name is not a reason to use it. :) (if I quoted "it's called *tmp*fs for a reason" in a "tmpfs is good" section it would be looking like humiliation, imho) If you need a tmpfs for your short builds you can mount it to /var/ram and use it there. But it's not related to /tmp, so I dismissed that too. Yes, tmpfs may be useful sometimes (and I even explained how to use it in "Alternatives" section), but that's outside of the topic of this thread if it's not about /tmp. If you'd said something like "I put /tmp on tmpfs and my ethernet became twice faster", or "Because of /tmp on tmpfs firefox loads pages 30% faster" that would be a good thing to quote. Especially if you could provide some details so that anybody could check it. :) But there were no examples, just some theories. And I tried to avoid theories because they may be wrong (I explained why some popular theories are wrong in the Q/A section however). > If you're going to post a thread summary, please do not filter out > information you don't agree with. Otherwise you're not posting a thread > summary, you're posting a 'my side of the fence' summary. I had to filter it. Otherwise it would be a copy of entire thread. :) Since the initial topic was not about tmpfs in general, but about /tmp and real-world applications, I filtered almost everything that's not related to it. It does not mean that I don't agree with that information. For example Stefan Lippers-Hollmann's test showed that kernel is building 15% faster on ext4 than on tmpfs, but I had not included that in summary, because people don't build their kernels in /tmp by default. I'm not stupidly opposite to tmpfs even for corner cases. I.e. if we could find that firefox works 30% faster with /tmp on tmpfs on PCs with >1GB RAM and disks with <1GB free space then... we could write an initscript, that checks for amount of RAM, free space and presence of firefox and mounts tmpfs to /tmp if it makes things faster. But there were no such examples, unfortunately. I could suggest a dozen of different solution, if only there were a problem to solve. Of course I could have missed some important examples about /tmp and real applications. Sorry if I did and I would be glad if you point them out. -- Serge -- 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/caovenepbcx9pzr8nzttfm_x_p22pj9w0g0p4rhctkyv-tr5...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge wrote: > 2012/6/10 Adam Borowski wrote: > >> Some people asked for a thread summary. So here it is. > > Seriously, can't you even read what's written to you? > > Yes, I know it was a biased summary. So as yours. But there's a difference > between mine and yours. Mine is based on some real-world applications, You've posted blatantly false claims. If you post claims like "1+1 equals 2 because the moon is made of cheese", then you're a moron, even if 1+1 does equal 2. And even if some of your arguments are valid, if you can't yourself tell the valid arguments apart from the crackpot claims that doesn't help your credibility. > Do you dismiss the theory (confirmed by Uoti Urpala test script) that > tmpfs+swap INCREASE number of writes and are hence bad for SSD? I think what the script shows is that there can be significant problems using tmpfs to hold large amounts of data, even if you have a lots of swap so that running out is not an issue. It doesn't show that the number of writes would increase on average. In general you seem to be quite clueless about the actual behavior of cache/swap, but you've still continued to make various claims about it. -- 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/1339341085.21597.72.camel@glyph.nonexistent.invalid
Re: gnome is completely f^Mmessed up
On 09/06/12 21:27, Roland Mas wrote: > here, but everything I've felt and read and heard is that the primary > focus of Gnome is no longer "everyone" but "users doing basic tasks", > and "users trying to be productive" (ie maximize the bandwidth of the > human-computer interface) are an afterthought at best. > [...] > I'm just fed up with people raising valid concerns about Gnome and being > dismissed as irrelevant. SAME thing for KDE imho - regular usability regressions for "power"users! well whatever - Xfce, guake and tmux to the rescue ;) #regards|marcel C: -- 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/4fd4c29b.2040...@gmx.net
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote: * Less wear of SSD drives. • Contrary to Serge's claims, SSDs are not an oddity, and it's not unlikely these will be a majority before wheezy becomes oldstable. He didn’t say they were oddities. He said you should more worry about firmware bugs than worry about write cycles. And I think he is quite right. Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? If not, you think that getting /tmp away from disk will help much? Even if you consider rsyslog and logfiles, browser caches and so on? You have some interesting ideas, but I think they are only valuable for the common case if we can buy computers with better RAM to disk ratio. I checked some offers for new PCs (here in Germany). If you don’t buy an expensive gaming PC (with 16 or 12 GB RAM), you will get 4 GB (sometimes 6 or 8 GB). It’s even worse with notebooks. And let me guess: if you ask people if they want to buy a PC with 4 GB RAM and 2 TB disk or a PC with 8 GB RAM and 1 TB disk, they will choose the first one, because they know more about disk space than RAM. This basically boils down to: efficiency vs failures for a newbie user. Replace newbie user with default installation. Even experienced users may wish to choose default installation for common desktop systems. We have popularity-contest to get statistics about packages. Can this script be extended to get hardware information (e.g. RAM, disk space and partition layout)? So we would see what computer are used by our users and how it is configured. If most people only have 4 GB RAM, it is quite useless to waste it with a RAM disk. If most people already have separate tmp partitions, we don’t need it either. Current size defaults for /tmp are naive to the point of brokenness: with modern systems not being expected to ever use swap, we'd want to Well, if I start Virtual Box on my notebook (4 GB RAM), the system uses the swap partition. So it is not modern enough? 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
Re: Dependency-based boot ordering and sysvinit in unstable
[Thorsten Glaser] > Roger Leigh dixit: > >>However, if you have any lingering scripts without any LSB headers, >>you'll need to fix them up or remove them to allow dynamic boot >>ordering to be enabled. This is obviously not too desirable, since > > sudo apt-get --purge install file-rc insserv- Good reply, and good short term solution! :) Now if only everyone else in Debian would follow your example, perhaps the old and obsolete static init.d script ordering will become maintained again. http://qa.debian.org/popcon.php?package=file-rc > show 0.18% of the population do so already, and there is an upward trend, so it might even lead to success. -- Happy hacking Petter Reinholdtsen One of the people who brought you dependency based boot sequencing -- 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/2flfwa388cf@login2.uio.no
Re: gnome is completely f^Mmessed up
On Sat, Jun 09, 2012 at 08:38:42PM +0200, Jerome BENOIT wrote: > Hello List: > > On 09/06/12 19:54, Stephen Allen wrote: > > > >+100 On that. Anyone that thinks 2 was better doesn't know much -- What > >most are saying is they liked the layout better (I think). In that case > >Cinamon is a good choice; best of both worlds. > > > > Is Cinnamon detributed within Debian ? No not last time I checked. It's availabe from LMDE (LinuxMintDebian) and since that distro works with Debian testing sources? well it shouldn't be too much of an issue in terms of dependencies when installing. YMMV -- 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/20120610160112.ga1...@thinkpad.gateway.2wire.net
Lets (eventually) find a good solution for /tmp
On Sun, 10 Jun 2012, Adam Borowski wrote: > This is not an insurmountable problem: /tmp might use some form of > overlay that uses tmpfs for regular use and starts shunting to some > area other than swap once it sees it is being used for large files. > Or alternatively, there could possibly be a dynamic swap file on / > earmarked for tmpfs pages only (not implemented yet?). Or... Too > bad, any of these solutions would need a lot of testing, something > for which there simply isn't time before wheezy. Either an overlay or swap file on / (or some other large disk) is really the direction that we should be going to for /tmp. That way we can support fast tiny files and avoid writing to anything for SSDs, but still support storing files as large as the underlying filesystem can support. Now someone just has to write it and get it tested. Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20120610160602.go8...@teltox.donarmstrong.com
Re: gnome is completely f^Mmessed up
On Sat, Jun 09, 2012 at 09:27:05PM +0200, Roland Mas wrote: > Stephen Allen, 2012-06-09 13:54:17 -0400 : > > [...] > > > +100 On that. Anyone that thinks 2 was better doesn't know much -- > > There's no call for that belittling. You're right, poor choice of words. My apologies. ;-D > > What most are saying is they liked the layout better (I think). In > > that case Cinamon is a good choice; best of both worlds. > > For what it's worth: what I liked better was the fact that the DE > stayed out of the way. From my few but good-faith Gnome Shell > experiments[1], this is no longer the case except visually. > > Gnome Shell (Gnome 3.4 in general, it seems) decided that I was no > longer allowed a dedicated Meta key; instead, the Meta modifier moved to > the Alt key (and I no longer have an Alt modifier). As a regular Emacs > user, I used to have both Meta-* and Alt-* shortcuts. No longer. > > Gnome Shell decided that Alt-Tab would switch amongst applications, > and no longer amongst windows. So when I have several open windows on > the same desktop and I want to switch from one to another, I have to > stop and think whether the new window I want to focus is of the same > application as the one currently focused before I go Alt-Tab or > Alt-key-above-tab. If it is not, then I need to use both Alt-Tab and > Alt-k-a-t in sequence. And "same application" actually means "same > instance of an application", so if I have two Emacs windows open I need > to remember if I opened one from the other or if I started them > independently. This breaks the "flow". To make things worse, > applications are listed by name and not by window title, so my Gnus > shows up the same as any other Emacs and I have no way to find out > whether I'll end up focusing Gnus or another Emacs; I just have to focus > one and hope it's the right one. > > Oh yeah, right, there's an extension allowing to switch back to the > standard Alt-Tab behaviour; except it doesn't restrict itself to the > current workspace, so I get to browse through my dozens of windows. > > Gnome Shell decided that if I overshoot when moving my mouse too close > to the top-left corner I should be punished and forced to reach for my > Escape key before I can actually click on wherever I wanted to click. There's an extension that removes the hot corner. Right now it's in need up an upgrade to work with 3.4, unfortunately. Hey I hear you; I disliked GnomeShell at 1st too, but after using it I gradually learned to work-a-round some of the issues and others were fixed by extensions. It's a major uprade and complelely new so I know that it will get fleshed out as it matures. I like it's stability and speed so, am not willing to trade that for the old way. I gave Cinnamon a good shot, but found myself actually missing Gnome-Shell, go figure! It looks cleaner I guess -- 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/20120610160837.gb1...@thinkpad.gateway.2wire.net
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Uoti Urpala wrote: >> Yes, I know it was a biased summary. So as yours. But there's a difference >> between mine and yours. Mine is based on some real-world applications, > > You've posted blatantly false claims. If you post claims like "1+1 > equals 2 because the moon is made of cheese", then you're a moron, even > if 1+1 does equal 2. (I like this example :)) It could be, it's impossible to know everything in the world, I can be wrong. What false claim are you talking about? >> Do you dismiss the theory (confirmed by Uoti Urpala test script) that >> tmpfs+swap INCREASE number of writes and are hence bad for SSD? > > I think what the script shows is that there can be significant problems > using tmpfs to hold large amounts of data, even if you have a lots of > swap so that running out is not an issue. It doesn't show that the > number of writes would increase on average. > > In general you seem to be quite clueless about the actual behavior of > cache/swap, but you've still continued to make various claims about it. I was referencing your words: 2012/5/25 Uoti Urpala wrote: > Thus, if you do multiple read iterations through a large set of data > (which does not fit in memory) on tmpfs, each iteration does disk > read AND write rather than just read. 2012/6/1 Uoti Urpala wrote: > I haven't read the relevant kernel code, but that doesn't match the > behavior I see. Reading a large file from tmpfs and then allocating > memory results in large swap writes every time, even if the newly > allocated memory is not itself immediately swapped out and the file > should already be in swap from before. Reading from swap generates additional writes. It mean that tmpfs+swap may actually increase amount of writes instead of reducing it, isn't it? If you don't want me to reference your words, well, let's recheck that guess again. Pressing "Enter" on .tar.bz2 archive in mc will untar it to /tmp, burning a CD may generate iso-image in /tmp, let's check how many write there would be in case of tmpfs? Startup conditions: # free total used free sharedbuffers cached Mem: 1017588 850224 167364 0 63332 480588 -/+ buffers/cache: 306304 711284 Swap: 2249092 407642208328 That is 1GB RAM, 2GB swap, 300MB RAM in use (which is barely enough for almost empty gnome session), 700MB free. Swap is on /dev/sda3: # cat /proc/swaps FilenameTypeSizeUsed Priority /dev/sda3 partition 2249092 40764 -1 and is almost unused. Initial `iostat -k /dev/sda3` output: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda3 9,7069,4680,04 122660 141340 So there were 140MB written yet. Now let's put a 1GB file on tmpfs: # dd if=/dev/zero of=/tmp/file bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 24,9147 s, 43,1 MB/s How many writes were done to swap? Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda3 12,2986,29 479,66 162996 906020 Hm, 750MB more... I have actually expected it to be about 300-400 MB, but well, I must have missed something like paging cluster... Anyway, it's still less than 1GB, so it looks like we saved 250MB of writes, right? Wrong! Because now we'll READ it back, that's what real app would do. # time cat /tmp/file > /dev/null real1m58.916s user0m0.139s sys 0m17.287s So what do we have with r/w stats now: Device:tpskB_read/skB_wrtn/skB_readkB_wrtn sda3 60,86 567,86 885,1512436761938604 WOW! Reading that tmpfs-file we've done 1GB of reads AND 1GB WRITES. Instead of 1GB writes for real filesystem, we'd got 1.7GB for tmpfs+swap. Conclusion: using tmpfs+swap for files that increase amount of free RAM generate (at least 70%?) MORE WRITES than regular filesystem. And the more reads you do the more writes it generates. (Imho, that deserves a place in summary!) Does anybody still think that tmpfs+swap is good for SSD? ;) What part of my summary's wrong? The QA part? Those were just theories. Theories can be wrong, that's why I always ask for tests and examples, they can't be wrong. Theories are there just to explain results of the tests. Any theory is useful only when applied to a real life. When the theory does not match real life it replaced with another theory. That's how the entire physics work. :) Which of my theories is wrong, BTW? -- Serge -- 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/caoveneowrbe0+061l7yop8zy8ehuxz_weggvwsbpavmo1l8...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
]] Stephan Seitz > Will Wheezy support SSDs out of the box with all trimming functions, > even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. -- 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/87d357ytuc@xoog.err.no
Re: Handling of changelogs and bin-nmus
Raphael Hertzog wrote:
> As such, I suggest that we handle "binary rebuild" differently:
> - debian/changelog is left unmodified since it's the source changelog
> => it defines the ${source:Version} substvar
> - debian/changelog.binary-rebuild (or any other better name) is created
> when we want to do a bin-nmu
> => it defines the ${binary:Version} and it's not included in
> the generated source package
Sounds good to me. Where would the binary changelog entry and binary
version be stored in the resulting binary package?
--
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/20120610171456.GB32613@burratino
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: ]] Stephan Seitz Will Wheezy support SSDs out of the box with all trimming functions, even if your SSD partition is using LUKS and LVM? Depends on what you mean by out of the box. I suspect you still need to turn on discard support (since it has security implications). It does not require extra packages or patches. Well, nice to hear, but I thought, discard was needed in all layers, so in my example in LUKS, then in LVM and then in the filesystem. Or is his only a function you activate via hdparm? 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: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 06:13:24PM +0300, Serge wrote: > 2012/6/10 Wouter Verhelst wrote: > > > Sorry, but this is a biased summary, and therefore useless for what it > > intends to be. > > Yes, I know. It's biased toward the /tmp and real-world applications. > > >> "/tmp on tmpfs is good" quotes > >> No real quotes here. Most of this and other threads were about why > >> /tmp on tmpfs is not that bad. But there're no real quotes explaining > >> why it's good. > > > > This is wrong. There were several (including by me). You dismissed them, > > not considering them valid, but that doesn't mean they are. > > I dismissed everything that was not related to /tmp or some popular apps. > > A lot of people (including you) said that tmpfs makes things faster. But > there were no examples of popular use-cases becoming faster because > of /tmp on tmpfs, so I had nothing to quote. You're not even trying. if tmpfs is faster than (say) ext4, then anything which uses /tmp will obviously speed up. Can I provide a use case where this will matter? Not necessarily. But then, can you provide a use case where this will *not* matter? Really? > Nobody could provide examples or numbers of how much /tmp on tmpfs reduces > amount of writes, and tests showed that tmpfs+swap may even increase amount > of writes (hence not always good for SSD), True, but then swapping to an SSD is the "best" idea since "640kB is enough for everyone" :-) > tmpfs does not have 5% overflow safety, Because it doesn't need it. The 5% overflow safety exists for two reasons: - to avoid excessive fragmentation (which is not relevant for tmpfs) - to allow you to clean up when the filesystem does fill up. For tmpfs, you do that with: mount -o remount,size=foo /tmp where 'foo' is some size or percentage that's larger than what the tmpfs is currently mounted with. Now you clean up, and you reset to what it was before. > > If you're going to post a thread summary, please do not filter out > > information you don't agree with. Otherwise you're not posting a thread > > summary, you're posting a 'my side of the fence' summary. > > I had to filter it. Yes, but if you want to have any remote resemblance of objectivity, then what you do not do is filter out everything you don't agree with. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120610175640.gb9...@grep.be
Re: Is it me or virtualbox memory management crap? (was: Summary: Moving /tmp to tmpfs makes it useless)
On 06/10/2012 11:55 PM, Stephan Seitz wrote: > Well, if I start Virtual Box on my notebook (4 GB RAM), the system > uses the swap partition. Frankly, I don't know what the fuck virtualbox is doing with its memory management, but I was tempted more than once to file a RC bug with a title like this one: Virtualbox fucks up Linux memory on nearly all cases I didn't do it, because I'm unsure if what I'm experiencing is to be considered "normal" or not, or if there are tricks to avoid that. Seriously, when I run it, I always do a "swapoff -a", otherwise my HDD starts spinning fast, even with 4 GB of RAM, and only 1.5 GB of it for the guest. Then even when I do this, I get some random memory allocation warnings printed in the kernel on tty1, as if the system went crazy with no handles for new chunks of memory. All this, when "top" shows there's some remaining free RAM. Let's put it this way: I can't run Virtualbox AND Firefox at the same time, or my laptop becomes unusably slow and non responsive. Am I the only one who experienced that? Is there something I didn't understand, or is it Virtualbox that has a problem? Cheers, 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/4fd4e76b.3000...@debian.org
Re: Lets (eventually) find a good solution for /tmp
On 06/11/2012 12:06 AM, Don Armstrong wrote: > swap file on / [...] is > really the direction that we should be going NO ! Does this need to be explained? :/ 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/4fd4e808.80...@debian.org
Re: Is it me or virtualbox memory management crap?
On Mon, Jun 11, 2012 at 02:28:59AM +0800, Thomas Goirand wrote: On 06/10/2012 11:55 PM, Stephan Seitz wrote: Well, if I start Virtual Box on my notebook (4 GB RAM), the system uses the swap partition. Frankly, I don't know what the fuck virtualbox is doing with its memory management, but I was tempted more than once to file a RC bug with a title like this one: Virtualbox fucks up Linux memory on nearly all cases I didn't do it, because I'm unsure if what I'm experiencing is to be considered "normal" or not, or if there are tricks to avoid that. I don’t know if this is normal. At least I can say, that I can use Virtual Box and Iceweasel together. The system gets slow, but it still is usable. 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: Handling of changelogs and bin-nmus
On Sun, 10 Jun 2012, Jonathan Nieder wrote:
> Raphael Hertzog wrote:
>
> > As such, I suggest that we handle "binary rebuild" differently:
> > - debian/changelog is left unmodified since it's the source changelog
> > => it defines the ${source:Version} substvar
> > - debian/changelog.binary-rebuild (or any other better name) is created
> > when we want to do a bin-nmu
> > => it defines the ${binary:Version} and it's not included in
> > the generated source package
>
> Sounds good to me. Where would the binary changelog entry and binary
> version be stored in the resulting binary package?
In the short term, the binary changelog would not be stored in the
package so that /usr/share/doc//changelog.Debian.gz is the
same across all bin-nmued package.
Later, it would be stored in the metadata as Guillem suggested (within
control.tar.gz and then installed by dpkg somewhere under /var/lib/dpkg/).
For the binary version, nothing would be changed (it's in the Version field
of the control file).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
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/20120610184323.ge14...@rivendell.home.ouaza.com
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 12:35:47PM +0200, Adam Borowski wrote: > On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote: > > Some people asked for a thread summary. So here it is. > But, for the rest of us, here's a different summary. I've long thought that the wiki might be a good tool for trying to summarize the key points of a discussion. If there was hot disagreement about the points of relevance in the discussion, at least those disagreements would be moved off the mailing list and onto an edit war on a page on the wiki, which could be summarily ignored by other wiki users. The fact w.d.o is really slow atm would also help to cool down such interactions :) -- 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/20120610184542.GA16293@debian
Re: Lets (eventually) find a good solution for /tmp
On Mon, Jun 11, 2012 at 02:31:36AM +0800, Thomas Goirand wrote: > On 06/11/2012 12:06 AM, Don Armstrong wrote: > > swap file on / [...] is > > really the direction that we should be going > NO ! > > Does this need to be explained? :/ Perhaps? Please point me at the msg-id of the explanation if I missed it. -- 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/20120610184646.GB16293@debian
Re: gnome is completely f^Mmessed up
On Sun, Jun 10, 2012 at 12:01:12PM -0400, Stephen Allen wrote: > On Sat, Jun 09, 2012 at 08:38:42PM +0200, Jerome BENOIT wrote: > > Is Cinnamon detributed within Debian ? > > No not last time I checked. It's availabe from LMDE (LinuxMintDebian) > and since that distro works with Debian testing sources? well it > shouldn't be too much of an issue in terms of dependencies when > installing. YMMV There's an ITP with no recent activity and no response to pings. I had a quick look at packaging it but decided it was not fit for a stable release so it wasn't worth rushing a package in before the freeze. -- 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/20120610184907.GC16293@debian
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: > On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: > >]] Stephan Seitz > >>Will Wheezy support SSDs out of the box with all trimming functions, > >>even if your SSD partition is using LUKS and LVM? > >Depends on what you mean by out of the box. I suspect you still need to > >turn on discard support (since it has security implications). It does > >not require extra packages or patches. > Well, nice to hear, but I thought, discard was needed in all layers, > so in my example in LUKS, then in LVM and then in the filesystem. Or > is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Summary: Moving /tmp to tmpfs makes it useless
Serge wrote: > 2012/6/10 Uoti Urpala wrote: > > You've posted blatantly false claims. If you post claims like "1+1 > > equals 2 because the moon is made of cheese", then you're a moron, even > > if 1+1 does equal 2. > > (I like this example :)) It could be, it's impossible to know everything > in the world, I can be wrong. What false claim are you talking about? The problem is that you've posted quite a few of those false claims, and don't seem a have a clear distinction between things you actually know and things you only have a vague guess about. You seem to make claims about both equally. For example, the page you linked for your "SSDs can take 50 years of writing before they wear out" claim has a first paragraph saying durability IS again an issue - much more so than it was in 2007 when the original article with the "50 years" claim was written (and even then that seems to have been some particularly durable high-end server hardware). As another example, this part from your FAQ is nonsense: >When you >read from ext3, the oldest part of the filecache is dropped and data is >placed to RAM. But reading from swap means that your RAM is full, and in >order to read a page from swap you must first write another page there. >I.e. sequential read from ext3 turns into random write+read from swap. There is no such difference reading from a normal filesystem or reading from swap. Iterating reads from swap can trigger writes, but if that's what you're referring to here, you've clearly either failed to understand what actually happens or are writing a very misleading description. > >> Do you dismiss the theory (confirmed by Uoti Urpala test script) that > >> tmpfs+swap INCREASE number of writes and are hence bad for SSD? > > > > I think what the script shows is that there can be significant problems > > using tmpfs to hold large amounts of data, even if you have a lots of > > swap so that running out is not an issue. It doesn't show that the > > number of writes would increase on average. > > > > In general you seem to be quite clueless about the actual behavior of > > cache/swap, but you've still continued to make various claims about it. > > I was referencing your words: Yes, I did say that it can generate writes in some circumstances. However, that does not imply your "tmpfs increases writes" claim in general. In what has been a default installation, I think you'd normally start hitting the tmpfs size limit before the problematic behavior shown by the script would become a serious issue. It mainly shows that "make the size limits bigger" may not be a good solution to the space issue. -- 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/1339354920.21597.97.camel@glyph.nonexistent.invalid
Re: Summary: Moving /tmp to tmpfs makes it useless
]] Philipp Kern > On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote: > > On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote: > > >]] Stephan Seitz > > >>Will Wheezy support SSDs out of the box with all trimming functions, > > >>even if your SSD partition is using LUKS and LVM? > > >Depends on what you mean by out of the box. I suspect you still need to > > >turn on discard support (since it has security implications). It does > > >not require extra packages or patches. > > Well, nice to hear, but I thought, discard was needed in all layers, > > so in my example in LUKS, then in LVM and then in the filesystem. Or > > is his only a function you activate via hdparm? > > It's available in all layers, but as Tollef said it's manual. (In crypttab > most > likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. -- 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/873962zz6u@xoog.err.no
Bug#676969: ITP: python-unshare -- Python bindings for the Linux unshare() syscall
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: python-unshare Version : 0.1 Upstream Author : "Martín Ferrari" * URL : http://code.google.com/p/python-unshare/ * License : GPLv2 Programming Lang: Python, C Description : Python bindings for the Linux unshare() syscall This simple extension provides bindings to the Linux unshare() syscall, added in kernel version 2.6.16. By using unshare(), new and interesting features of the Linux kernel can be exploited, such as: * Creating a new network name space (CLONE_NEWNET). * Creating a new file system mount name space (CLONE_NEWNS). * Reverting other features shared from clone(). This library provides an equivalent of the (recently added) util-linux command-line program unshare. -- 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/20120610203415.3361.25085.report...@abhean.lan
Re: Summary: Moving /tmp to tmpfs makes it useless
On Sun, Jun 10, 2012 at 10:31:21PM +0200, Tollef Fog Heen wrote: > Well, nice to hear, but I thought, discard was needed in all layers, > so in my example in LUKS, then in LVM and then in the filesystem. Or > is his only a function you activate via hdparm? It's available in all layers, but as Tollef said it's manual. (In crypttab most likely, because that's commonly the lowest layer.) You need to enable it in all layers (fstab, crypttab, lvm.conf), yes. Ah, thank you for your explanations. But the documentation doesn’t sound encouraging. „man crypttab” gives a security warning and „man mount” says, this option is not sufficiently tested yet. 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: gnome is completely f^Mmessed up
On Fri, 8 Jun 2012 16:15:42 +0900
Norbert Preining wrote:
> Hi everyone,
>
> is this only me or do I have the feeling that we are going down
> the trench with Gnome?
> Repeatedly:
> - first login: nautilus segfaults in libnautilus-fileroller.so
> after log out and log in it sometimes works
> starting it manually most of the times work, but not always
> - ssh/gpg agent: most of the time just is completely useless
> either does not ask, or just segfaults in libglib-2.0
> - plugging/unplugging power cord makes gnome-shell crash (known bug)
> - ...
> When I finally manage to get a running session, then out of nothing
> the blue whale appear, BSOD.
>
> Is this a joke? Are we going to release that in June/July/whenever?
>
> Best wishes
>
> Norbert
>
> Norbert Preiningpreining@{jaist.ac.jp, logic.at,
> debian.org} JAIST, Japan TeX Live &
> Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0
> D2BF 4AA3 09C5 B094
>
> PEEBLES (pl.n.) Small, carefully rolled pellets of skegness (q.v.)
> --- Douglas Adams, The Meaning of Liff
>
>
I have the added issue that GNOME seems to (somehow) manage to spawn in
excess of 100 Xserver when I try to log in.
I switched to XFCE4 as well.
~ Luke Cycon
DM -- University of California, San Diego CS Undergrad
--
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/20120610135404.72fcf...@lukelaptop.home.local
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Philipp Kern (pk...@debian.org) [120610 14:06]: > On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote: > > Perhaps we could add the binNMU entry for the moment and fix the rest > > later? Or whatever would make you more happy. Just I'd like to be able > > to schedule binNMUs again on ma-packages. > > There is no such block in place. No, just the package won't be co-installable afterwards. Which doesn't make me really happy. Andi -- 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/20120610213624.gz2...@mails.so.argh.org
Re: Is it me or virtualbox memory management crap?
Thomas Goirand writes:
> Let's put it this way: I can't run Virtualbox AND
> Firefox at the same time, or my laptop becomes unusably
> slow and non responsive.
>
> Am I the only one who experienced that? Is there something
> I didn't understand, or is it Virtualbox that has a problem?
I have the exact same problem. 1GB for VirtualBox, 1GB for Firefox, 4GB
RAM and the machine becomes slow as a dog. Never cared enough to
investigate.
--
panic("Fod fight!");
2.2.16 /usr/src/linux/drivers/scsi/aha1542.c
--
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/m3k3zec0tn@neo.luffy.cx
Re: Handling of changelogs and bin-nmus
* Raphael Hertzog (hert...@debian.org) [120610 20:44]:
> On Sun, 10 Jun 2012, Jonathan Nieder wrote:
> > Raphael Hertzog wrote:
> >
> > > As such, I suggest that we handle "binary rebuild" differently:
> > > - debian/changelog is left unmodified since it's the source changelog
> > > => it defines the ${source:Version} substvar
> > > - debian/changelog.binary-rebuild (or any other better name) is created
> > > when we want to do a bin-nmu
> > > => it defines the ${binary:Version} and it's not included in
> > > the generated source package
> >
> > Sounds good to me. Where would the binary changelog entry and binary
> > version be stored in the resulting binary package?
>
> In the short term, the binary changelog would not be stored in the
> package so that /usr/share/doc//changelog.Debian.gz is the
> same across all bin-nmued package.
>
> Later, it would be stored in the metadata as Guillem suggested (within
> control.tar.gz and then installed by dpkg somewhere under /var/lib/dpkg/).
>
> For the binary version, nothing would be changed (it's in the Version field
> of the control file).
Asking to be sure: For sbuild, that means instead of changing the file
debian/changelog before starting the build, a new file
debian/changelog.binary-rebuild (or however it is named) is created
and from there on all works "by itself"?
Do we have other tools than dpkg that parse the changelog to find out
the package version? How far are we away from getting that
implemented once we decide we want that?
Andi
--
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/20120610214037.ga2...@mails.so.argh.org
Re: Is it me or virtualbox memory management crap? (was: Summary: Moving /tmp to tmpfs makes it useless)
2012/6/10 Thomas Goirand wrote: > Let's put it this way: I can't run Virtualbox AND > Firefox at the same time, or my laptop becomes unusably > slow and non responsive. Do you use 2.6 kernel and have FF profile and VB images on the same ext4 partition? Can you reproduce that with 3.2 kernel? PS: you can check the output of `latencytop` as well. -- Serge -- 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/caoveneqplbjlgkvlvf-9tkynpngukbods2twnk0dnn6h9j8...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
> >>> Some people asked for a thread summary. So here it is. > >> Seriously, can't you even read what's written to you? > > > > Yes, I know it was a biased summary. > > I think you might start to piss off a few people now... > > Look at what you are quoting above. You introduced your biased summary > like this: > > "Some people asked for a thread summary. So here it is.". > > I will refrain from further comments. People can judge for themselves. I think that it is really great that Serge wrote a summary. Serge, I thank you a lot. Your summary may not be prefect, but as it was suggested, there are tools like wiki.debian.org if there is some will to make a more structured document. Roger's email where he announced that the defaults were reverted was also very informative, as it provided a broader overview of why there are filesystems on tmpfs, and what is the role of /tmp in that context. In the absence of a final combined summary, I suggest to link to the ones of Roger, Serge and Adam in the next "Developers News". http://wiki.debian.org/DeveloperNews#Using_RAM_for_temporary_files_.3F There are many long threads on -devel that are difficult to follow because of their large quantities of messages, to the point that I would almost call this a discrimination in the sense of our recent GR: I think it is pushing out contributions that we could have received if we self-moderated these posting bursts. For that reason, even if they are not perfect, I think that summaries are very welcome. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120610233432.gb7...@falafel.plessy.net
Re: Handling of changelogs and bin-nmus
Andreas Barth wrote: > Do we have other tools than dpkg that parse the changelog to find out > the package version? Yes, debian/rules parses the changelog in a low-tech way in some source packages. Someone with access to the lintian lab might be able to say how many packages would be hurt by not being able to read the binary package version from there (hopefully not many --- most packages use dpkg-parsechangelog instead). Jonathan -- 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/20120610235358.GA3390@burratino
Bug#677000: ITP: python-passfd -- Python extension to pass file descriptors across UNIX domain sockets
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: python-passfd Version : 0.2 Upstream Author : "Martín Ferrari" * URL : http://code.google.com/p/python-passfd/ * License : GPLv2 Programming Lang: Python, C. Description : Python extension to pass file descriptors across UNIX domain sockets This simple extension provides two functions to pass and receive file descriptors across UNIX domain sockets, using the BSD-4.3+ sendmsg() and recvmsg() interfaces. Direct bindings to sendmsg() and recvmsg() are not provided, as the API does not map nicely into Python. Please note that this only supports BSD-4.3+ style file descriptor passing, and was only tested on Linux. -- 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/20120611000904.4340.3774.report...@abhean.lan
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Uoti Urpala wrote: >> What false claim are you talking about? > > The problem is that you've posted quite a few of those false claims [...] > For example, the page you linked for your "SSDs can take 50 years > of writing before they wear out" claim has a first paragraph saying > durability IS again an issue Yes, it is an issue for MLC SSD disks, that's why in summary I wrote "SLC SSD disks". I even explicitly wrote that it depends on chip type. That's why I gave that link, so people could check the type of SSD, get to know the SLC/MLC difference, read about the calculation method (which is valid for any SSD disk), and could decide whether they should worry. Everything looks correct. No false claims there... > As another example, this part from your FAQ is nonsense: >> When you read from ext3, the oldest part of the filecache is dropped and >> data is placed to RAM. But reading from swap means that your RAM is full, >> and in order to read a page from swap you must first write another page >> there. I.e. sequential read from ext3 turns into random write+read from >> swap. > > There is no such difference reading from a normal filesystem or reading > from swap. Iterating reads from swap can trigger writes, but if that's > what you're referring to here, you've clearly either failed to > understand what actually happens or are writing a very misleading > description. Maybe I've just poorly expressed the theory. Basically it boils down to: In case of "write large file then read it back" (which is very common temporary file usage scenario) on the reading stage instead of plain sequential read (as it'd be for ext3) you'll get read+write from swap. Then I tried to explain: That's because on the write stage tmpfs was swapped out. The fact that it was swapped out means that the RAM is full, no free cache to use. And now when you start reading the file back, you need to read it from swap. But you cannot do that, because there's no free RAM. In order to read a page from swap you must first write another page of tmpfs there. That's why sequential read turns into random write+read from swap. That's what I wrote in the summary... or at least tried to write. When I was writing the summary it was just a theory, based on your email. I have not done any tests then. When a few hours ago I did it I was surprised how much true it was. It could be that my explanation is wrong, but test cannot be wrong: every read did generated equal number of writes. This actually means to me that as long as debian creates swap partition by default it should never create large tmpfs mountpoints by default, or it may badly affect SSD users. If you don't have a better explanation, then why do you think that mine was wrong? Of course if you do have a better explanation for results of that test I'm also interested to read it. > I think you'd normally start hitting the tmpfs size limit before the > problematic behavior shown by the script would become a serious issue. According to my theory the only thing you need to get the problem is a file on tmpfs that is larger than free RAM. I.e. if you have 1GB RAM and 600MB tmpfs (default for 2GB swap) you'll get swap reads+writes even with 500MB file, if your gnome+firefox took 600MB and you have less than 500MB RAM for cache. -- Serge -- 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/caoveneo078mwd-qr1m8cnefejyauhtbquhmkdp3ckh-4har...@mail.gmail.com
