Re: length of a package extended description
On 10 January 2015 at 17:27, Guillem Jover guil...@debian.org wrote: So, no, fixing the translators tools is not an option. Whether or not texlive-* packages are too long is a debate I already had with Norbert in the bug report he mentioned. He gave a rationale which doesn't entirely satisfies mebut makes sense and I decided that we both have better things to do than argue over this...:-) I think fixing translator tools would be an improvement, because it would reduce translator work in other situations too, by chunking the description on long lists (and not necessarily just for godzilla-sized ones :). Since forever the DDTP project has always considered the paragraphs to be the blocks that people can translate. I can certainly see that in this case you don't need to see the surrounding context to be able to translate it, but is this always the case? Not being a translator myself I'm not sure if it better to provide the whole chunk, and make the tool recognise paragraphs, or to split the lists into seperate chunks to translate seperately... Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/
Re: use of RDRAND in $random_library
On 13 June 2014 06:27, Gunnar Wolf gw...@gwolf.org wrote: Excuse me if I'm blunt here, but I understand that, on the point of using entropy to seed a PRNG, if you have several shitty entropy sources and one _really_ good one, and you xor them all together, the resulting output is as random as the best of them. If your hardware entropy source is faulted and produces just an endless stream of '001001001001001001', xoring it with a valid Golomb sequence will give you something even more random than a Golomb sequence. Or am I misunderstanding my crypto? The proof that XORing streams can't reduce the entropy relies on the sources being independant. I think the issue here is we don't know if RDRAND is independent or not. That said, doing a SHA256 over the output should be sufficient (assuming the CPU doesn't see you're doing a hash and short circuits it). Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/
Bug#735927: general: X *always* crashes when 5 youtube video opened
On 18 January 2014 21:08, moli report...@moli.hu wrote: I dont have any knowledge in this area but i dont think this has anything to do with chrome, i think it's an intel graphics driver issue, it does not handle gracefully when the video memory is gone. Well, you state in your original email that you have no swap partition. Which is like tying one arm of the kernel behind its back. When the memory is full, what do you *expect* to happen. Something needs to get killed, and the X server does use a lot of memory so it is a good choice. You could disable memory overcommit, that would cause things to fall over sooner. You could change the OOM priority of the X server, this would cause some other process to be killed instead. Or (recommended) just add a small swap partition (say 128MB) to allow the kernel to put unused memory pages on disk so the X server can use them instead. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/
Re: packaging Postgres binary dump files
On 19 September 2013 14:42, Daniel Pocock dan...@pocock.com.au wrote: PostBooks distributes their schema as a Postgres binary dump file for use with pg_restore They are available for download here (not in the source tarball): http://sourceforge.net/projects/postbooks/files/03%20PostBooks-databases/4.1.0/ Is this format suitable for making a source package or do we need to load it into Postgres and then pg_dump it again as text / SQL? I would prefer to simply distribute the original files so that people can compare with upstream's checksums if they wish. FWIW, you can convert the file to text using pg_restore, you don't actually need a running database server. It's really just a compressed tarball and should be treated as such. That is, I think it can be included as-is. Unless you're thinking of patching it, in which case you need to think of something else. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/
Re: greater popularity of Debian on AMD64?
On 9 September 2012 16:49, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote: But I object to 32-bit PC and 64-bit PC. i686, amd64, x86-32, x86-64... at least those are correct. But none of them are widely understood. But they are googleable, whereas 32-bit PC matches stuff not directly relevant. 32-bit PC and 64-bit PC mean nothing, I think a lot more people know which of those they have. Do they, I wonder? Anyway, while it seems a nice idea to try and collapse the entire distinction between the two architectures into a single number, I'm not really sure who is helped here. The current architecture names are well established, also outside Debian. They're everywhere, in the output of gcc, packages names, library names, etc. Then there's the assumption that no other architecture can be a PC? I'd say, a single unambiguous label is better than a vague label for marketing purposes. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ -- 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/cadwg95t+5gfrivw4-+crk04cqwyanl9vkpcyxcy5sbpvhxj...@mail.gmail.com
Re: UDD gatherer for DDTP translations (Was: Extended descriptions size)
On Tue, Apr 7, 2009 at 9:49 AM, Andreas Tille til...@rki.de wrote: Well, I did not said that it is actually hard and in UDD you can get this easily by SELECT md5(description || E'\n' || long_description || E'\n' ) AS md5 FROM packages WHERE ... Ok, I see why you're having trouble now; you're splitting up the description in your DB and thus need to stick it back together. That does indeed make the process a bit less reliable. The DDTP/DDTSS treats the description as a single string, the exact string in the Packages file (the Description field is a single entry in the file) so we had no issues. By doing extra processing like splitting/stripping parts of the string it's quite possible you're doing a not invertible conversion, which would make matching later harder. It'd be nice if someone went over the version number stuff in DDTP/DDTSS since by and large it was never used (user display only and even then it wasn't accurate) and so probably there's plenty of work there. It might actually be easier to write a script which simply collected Packages files from say snapshot.debian.org, calculated all the MD5 sums (you can extract the description field using a regex so it's easy enough in Perl) and built a database of description MD5s and version numbers. That would give a reliable mapping, far more reliable than the DDTP/DDTSS is ever likely to do. Keep in mind that all dpkg frontends with description only work on the basis of the complete description string, I'm not sure if anyone is likely to switch to using versions. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UDD gatherer for DDTP translations (Was: Extended descriptions size)
On Wed, Apr 1, 2009 at 9:47 PM, Andreas Tille til...@rki.de wrote: On Wed, 1 Apr 2009, Goswin von Brederlow wrote: Then the version number will not be needed when an arch lags behind. The translation for the old md5sum can just be kept. Well, this thread was missused to discuss several issues. Would you mind reading my original posting why version numbers in Translation files make sense and would you please base your arguing on this posting. Perhaps I'm just wrong but version numbers are really handy in this case and I see an extra benefit in making these files somehow human readable (in the sense that I doubt you are able to calculate md5sums manually to find out the matching description. While I'm not against the idea of version numbers (though it would have to be a list since a single translation may apply to dozens of versions) it's not that hard to identify the description you want. What I often did was simply open up the description file to find the description I wanted to test, cut and paste it into another console running md5sum and that would be the md5 I needed to look for. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Clarification about bug #463538 is needed
On Sat, Jul 19, 2008 at 3:21 PM, Sergei Golovan [EMAIL PROTECTED] wrote: Hi! Currently APT fails to start all services which are based on Erlang (see bug #463538, [1]). It starts the service successfully but after apt-get finishes the service process get killed. I've found a one-line-patch which fixes this bug (see [2]) but I'm not sure if it's correct and doesn't break something else. Umm, if that patch fixes it (removing the TIOCSCTTY) then it seems to me that the erlang-based service will instead exit when the user who installed the server logs out. Evidently the services in erlang are not properly disassociating themselves from the terminal and this patch just makes it more obvious... Have a nice day, Could someone review the patch and either apply it to the next APT version or may be help to fix this in some other way? (It might be an Erlang fault but I can't find anything wrong in how it detaches from a controlling terminal.) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463538 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=tty.diff;att=1;bug=463538 Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: correct definition of localhost?
On Tue, Jul 8, 2008 at 2:37 AM, Joey Hess [EMAIL PROTECTED] wrote: http://sourceware.org/bugzilla/show_bug.cgi?id=4980 I just find it wierd that there doesn't appear to be a single person who can explain the reasoning for the change... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Boost 1.35 has been released
On Sat, Apr 19, 2008 at 10:43 PM, Steve M. Robbins [EMAIL PROTECTED] wrote: Can a process load 1.34 and 1.35 at the same time? Otherwise maybe you've got a problem if one lib uses 1.34 and another lib uses 1.35 and parts are exposed. I think you're right that there could be a problem. I'm not sure what can be done about it besides having the two boost-using libs upgrade together. If boost doesn't support symbol versioning yet, isn't it about time it did? A three line ld-script is all it takes. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should -dev packages providing .pc files depend on pkg-config?
On Sun, Apr 6, 2008 at 6:48 AM, Simon Richter [EMAIL PROTECTED] wrote: The use case here are people downloading a tarball and building that. These people are going to use a prebuilt configure script and expect the library to be found by it if the -dev package is installed. Then the configure script should do: Checking for pkg-config no ERROR: Please install pkg-config It's not the dev package's responsibility to ensure gcc/g++/binutils are installed, I beleive the same applies to pkg-config. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: preventing accidental deletion of system directories
On Sat, Mar 22, 2008 at 10:16 AM, Francois Marier [EMAIL PROTECTED] wrote: Having recently deleted my /usr/lib by mistake (and gone through the pain of reinstalling all of my packages), I wrote a little Perl script which I have now aliased to rm in my .bashrc. At one point I set my system up so that several key directories had the immutable bit set do you couldn't change them. Ofcourse, I still wanted upgrades to work so I used APT hooks to remove the bits prior to installing and add them back afterwards. It was a proofof concept, but it worked. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: idea: allow package combinations as alternatives, e.g. a | b + c
On Jan 24, 2008 10:05 AM, Fabian Greffrath [EMAIL PROTECTED] wrote: Now my idea is, that only both packages together, i.e. openoffice.org *and* openoffice.org-gnome, will make a good substitute for gnome-office. The Debian package management is currently not able to deal with this situation properly. It would be great if the gnome package could depend on 'gnome-office | openoffice.org + openoffice.org-gnome'. So the dependency will be satisfied if you install etiher gnome-office or both openoffice.org *and* openoffice.org-gnome. IIRC from logic, a | (bc) == (a|b) (a|c), which means you should be able to represent the above using: gnome-office | openoffice.org, gnome-office | openoffice.org-gnome Whether this actually works I don't know... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Debian i18n Meeting (Extremadura 2007)
On Jan 14, 2008 9:13 AM, Andreas Tille [EMAIL PROTECTED] wrote: Once this is working nicely we will issue an announcement on dda and try to make the code available for all CDDs in the common CDD framework. Which bit isn't working nicely? Apart from the fact that it's using the old address. There was a point about linking to packages that hadn't been requested but that got fixed at extremadura as well... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] [PATCH] 32-bit pointers in x86-64
On Nov 25, 2007 5:29 PM, Luca [EMAIL PROTECTED] wrote: This proof of concept patch modifies GCC to have 32-bit pointers and longs on x86-64. Quick question: Does this involve putting an opcode prefix in front of each instruction using either of these. i.e. doesn't it blowup the codesize considerably? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed for bug #441794 on postgis
On Nov 13, 2007 9:12 AM, Fabio Tranchitella [EMAIL PROTECTED] wrote: The bug report is #441794, and here there is a quick summary: the package provides a shared object (liblwgeom) which is used by postgresql for the postgis-specific functions. With the last upload (a new upstream release) the soname changed and the database became unusable because those functions referred to the old soname. Does the API actually change? Otherwise you might have to allow them to be parallel installable... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installinit
On Nov 12, 2007 11:00 PM, Arthur de Jong [EMAIL PROTECTED] wrote: Anyone have a better way to detect the highest open file descriptor (preferably something that also works inside a chroot jail that does not have /proc mounted)? NetBSD seems to have fcntl(F_MAXFD) that should do the trick, but it's unavailable on Linux. If we do find a method that works, it seems sensibile to make a simple LD_PRELOAD library you can set that will spit out warnings whenever extra file descriptiors are left open. The FD_CLOEXEC flag exists for a reason and most cases to probably bugs. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#417118: ntpdate: Start sequence problem for some network setups
On 7/4/07, Marco d'Itri [EMAIL PROTECTED] wrote: On Jul 04, Touko Korpela [EMAIL PROTECTED] wrote: Is there any ideas to fix this? I'm having same problem with ntp+dnsmasq Hope that some day we will switch to upstart. In my case the network connection doesn't come up until after I've logged in and given the pasword for the wireless network. I don't think upstart is going to fix that. I think there was a workaround so it didn't need the nameservers right away, that would solve the problem for me. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/15/07, Michael Banck [EMAIL PROTECTED] wrote: On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote: Actually, it seems to me the real problem is that when a new kernel is installed it is immediately used by the bootloader on the next reboot, without asking. That's because you installed the meta-package, saying I want to run the newest kernel without asking. If you don't want that, don't install the meta-package and install new kernel versions as they appear. Aha! I did a basic install from the CD so I had no idea there was a metapackage that did this. Now I know I can uninstall it and be happy! Thanks! Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/14/07, Luis Matos [EMAIL PROTECTED] wrote: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... if ... *if* i had used module-assistant to use nvidia graphics (or camera modules, or wifi, or what else), i would not mind to do that. Actually, it seems to me the real problem is that when a new kernel is installed it is immediately used by the bootloader on the next reboot, without asking. I explicitly check to see if there's a kernel upgrade and abort if that's the case, as I do not have the time to sort out the mess before the next reboot. Ideally, it could just install, without having it automatically used next time. Then, when I have time and everything is right, then the bootloader uses the new kernel. (This is probably possible, I just havn't worked out how yet). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On 6/12/07, Adam Borowski [EMAIL PROTECTED] wrote: Except, I did not claim that one of the versions is superior. What I stated was: 1. English is a language where the correct usage is what most people use, 2. kilobyte is preferred over kibibyte by a vast majority of those whose communicate using means accessible to Google search I didn't want to get involved with this, but it's seems clear to me that both KB and KiB would both be written out as kilobyte in most cases because most of the time it simply doesn't matter. It also seems clear to me that in cases where accuracy matters you should use the prefix that applies. However, I don't think any of the examples given it really matters, except possibly the DVD sizing, but in that case you'd just drag it and see if it fits. (Disclaimer: I'm from a metric country and bytes are really the only thing where there is ambiguity as to what the 'k' means). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On 6/12/07, Lennart Sorensen [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 06:25:22PM +0200, Josselin Mouette wrote: Prefixes are case-sensitive. Kilo is k. (This is also why there is much less ambiguity with K used for kibibytes.) Hmm, I used to think both k and K were accepted for kilo, but I can't find anything that says K is accepted for use as kilo. All the symbols in SI units have to be distinct, as combined units are units also. Consider: kWh = kilo-watt-hour = 3.6 MJ Nm = newton-metre The capital K is used for kelvin. So Km = kelvin-metre, which I suppose would be the unit to measure the total temperature over a length (product of temperature and length). Sure, most people can guess what you mean from the context but that doesn't make it right... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On 6/10/07, Junichi Uekawa [EMAIL PROTECTED] wrote: I might not have been clear on the wording. To fix this situation, ftp://ftp.jp.debian.org/debian/dists/sid/main/i18n/Translation-ja.bz2 needs to be encoded in UTF-8 instead of EUC-JP. (and I am wondering why this file is dated back to May 2006). That's because they're not the latest files. The latest output form the DDTP project is here: http://ddtp.debian.net/debian/dists/sid/main/i18n/ There have been requests to have the FTP site mirror from there or have some other mechanism to get the data to the main servers. As far as I know it needs an FTP master to fix. I understand the reason for it not having been done earlier was lack of support in apt? Now, the question is; who to ask? Michael Bramer (Grisu) is the maintainer of the DDTP project, but it needs an ftpmaster to fix. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Getting package translations into the mirrors (was Re: APT 0.7 for sid)
On 6/10/07, Frank Küster [EMAIL PROTECTED] wrote: That's because they're not the latest files. The latest output form the DDTP project is here: http://ddtp.debian.net/debian/dists/sid/main/i18n/ There have been requests to have the FTP site mirror from there or have some other mechanism to get the data to the main servers. As far as I know it needs an FTP master to fix. I understand the reason for it not having been done earlier was lack of support in apt? Have you submitted a bug against ftp.d.o? I couldn't find one. I havn't because I didn't think it was my problem. But I found it here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109955 It's six years old, the URLs have changed but thats it. I came to this rather late so I don't know the story. Just google for apt-i18n brings up some stuff. There's this: http://lists.debian.org/debian-i18n/2006/06/msg00107.html http://lists.debian.org/debian-devel-announce/2006/06/msg3.html When I last asked about it I was told to wait, so I've done nothing. I've CCed grisu, perhaps he knows what's going on... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On 4/10/07, Felipe Sateler [EMAIL PROTECTED] wrote: Maple is far away from any competitor I've seen. It provides you with anything you need plus everything you want, works in a nice environment and provides you with a _very_ comprehensive help. I have yet to find any free equivalent that has these three features. The makers are also very clever. Students can often get a licence for Maple on their own machines for free (it's being paid elsewhere). This kind of targets the group who would be most interested in writing a replacement. And lets face it, what Maple does is hard. I really wouldn't know where to begin. However, there are a lot of programs that implement peices: http://web.usna.navy.mil/~wdj/opensource_math.html It's just a matter of getting one of them to a point where it's useful... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: video codecs in HTML 5
On 3/24/07, Maik Merten [EMAIL PROTECTED] wrote: Taken that e.g. Mozilla and the KHTML team aren't able to build browsers with integrated (that's what video is for: Video without plugins) MPEG4 support without the appended patent licenses restricting the freedom of distribution it's worth to try to get a free format into as many browsers as possible. Sorry, this doesn't follow. Calling the tag video is completely orthoginal to whether it's implemented by a plugin or not. To support it all Firefox et al would need to do is convert it to the equivalent embed tag or whatever internally... Most (all?) program that manipulate video/audio data do so via plugins. That's because it's easier that way than trying to build support for every odd format someone might want to use into your binary... No matter what: Having Mozilla and Opera support a free format is good in any case. If something proprietary gets recommended Debian can only lose. If a free format is in place Debian users can at least watch parts of the content no matter what Microsoft does. Ofcourse, it'd be good for people to be able to ship a standards compliant browser without shipping non-free components, but that has nothing to do with whether it's a plugin or not... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNOME and trolls
On 2/17/07, Josselin Mouette [EMAIL PROTECTED] wrote: Ah, finally found them by searching on Slashdot. http://lists.linux-foundation.org/pipermail/desktop_architects/2007-February/001129.html Basically, there's zero chance they get accepted this way, as a patch not in bugzilla simply doesn't get reviewed. It's like asking for a patch to be added to Linux without posting it on the LKML. I think his comment about patches sent to the address in the README not being accepted is on the money. If you want people to use the bugzilla, say so. That said, he should have just used reportbug and let the maintainers work it out :) Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On 23 Nov 2006 13:43:52 +0200, Jari Aalto [EMAIL PROTECTED] wrote: Bash is not essential for running Debian. It is possible to run old PCs and old laptops completely free of bash. The point here is not the disk consumption, but the reduced memory constrainsts. When scripts are written with only sh in mind, they become portable to even embedded systems (think busybox). Every bash-dependent scipt that runs on the system, takes memory out from other processes. If disk-consumption is not the issue, the you don't need to uninstall it, you just need to point the /bin/sh symlink somewhere else. Bash can stay where it is and we don't have to have anyone declare dependancies on it either. If we want to mandate that maintainer scripts using /bin/sh should also work with dash, then do that, but I don't think we need we need to add complexity to the packaging system to deal with this. Education sector and 3rd world still have PCs that are *years* and *tears* old. Everybody do not live in countries where computers or hardware are cheap. There's a difference between requiring maintainer scripts to say /bin/bash if they need bash constructs and rewriting existing scripts to work with some generic shell. The former is going to be *much* easier. Isn't that enough? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
On 11/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Who should we help more: those who get paid to administer the machines, and are probably much more knowledable, or the occasional, home or small office user that doesn't have the knoweldge or the time to acquire it? Why is the occasional user installing an ftp server for anyway? It's not a service you want to be installing without some basic knowledge. What is the actual risk? That someone not too knowledgable will try to install multiple servers and getting confused? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alioth upgrade -- done
On 10/29/06, Wouter Verhelst [EMAIL PROTECTED] wrote: I don't think there's any explicit rationale -- at least, nothing beyond 8GB is quite a bit :-) I once heard that the way Linux works, it's best to have swap space anyway; I don't know what the rationale was from a technical perspective, but you may want to verify this. The usual reasoning (AFAIK) is that on any long running system there will be pages belonging to programs that are not used after startup. Having a small amount of swap (say 128MB or so) allows the system to swap out these useless pages and use that memory for cache or network buffers instead. On the systems I deal with that usually gives me an extra 50-100MB of free memory for caching, but whether that's noticable on a server with 8GB of RAM I have no idea. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On 9/28/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: Martijn van Oosterhout skrev: Which is all crap. Yes, this is the list you need for static, but pkg-config is recursing through modules even for dynamic linking which is wrong. Now either pkg-config of the gtk+2 pc file needs to be fixed, then you can start recompiling all the affected programs... The gtk+2 .pc file needs to be changed to mark a bunch of those Requires as Requires.private, pkg-config provides all the necessary infrastructure now. (If not, please do file bugs.) Ok, the reduces the libs list, but it also reduces the cflags list. So much so that you can't actually compile anything gtk-related. It'd be nice if there was a way to specify package that should be included for the purposes cflags, but excluded for the libs. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On 9/28/06, Kurt Roeckx [EMAIL PROTECTED] wrote: Note that Requires.private is used for cflags since the last version of pkg-config. Please see http://bugs.debian.org/340904 Well, then something wierd is going on. I have 0.21-1 installed and I get this. This first time is with Requires, the second is with Requires.private. My understanding is that the results should be the same? vali:/usr/lib/pkgconfig# dpkg -l pkg-config snip ii pkg-config 0.21-1 manage compile and link flags for libraries vali:/usr/lib/pkgconfig# pkg-config --cflags gtk+-2.0 -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 vali:/usr/lib/pkgconfig# joe gtk+-2.0.pc editted Requires to Requires.private File gtk+-2.0.pc saved. vali:/usr/lib/pkgconfig# pkg-config --cflags gtk+-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On 9/28/06, Mike Hommey [EMAIL PROTECTED] wrote: vali:/usr/lib/pkgconfig# pkg-config --cflags gtk+-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo I don't know what pkg-config is supposed to do, but surely you don't need the freetype2 nor the pango, nor the X11 includes files to build gtk applications. Have you tried? Try a simple #include gtk/gtk.h and you get errors like this: In file included from /usr/include/gtk-2.0/gdk/gdkcolor.h:31, from /usr/include/gtk-2.0/gdk/gdkcairo.h:23, from /usr/include/gtk-2.0/gdk/gdk.h:30, from /usr/include/gtk-2.0/gtk/gtk.h:31, from gtktest.c:10: /usr/include/gtk-2.0/gdk/gdktypes.h:33:25: error: pango/pango.h: No such file or directory In file included from /usr/include/gtk-2.0/gdk/gdk.h:30, from /usr/include/gtk-2.0/gtk/gtk.h:31, from gtktest.c:10: /usr/include/gtk-2.0/gdk/gdkcairo.h:25:30: error: pango/pangocairo.h: No such file or directory If you add /usr/include/pango-1.0 it works. Perhaps Requires.private is not recursive? It's not mentioned in the manpage, but I would've expected the there to be no difference between Requires and Requires.private when looking at cflags. At least, that's my interpretation of this thread. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On 9/26/06, Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: KBM Most of these are X-related, suggesting that quite a lot of .la KBM and .pc files are pretty indiscriminate about which X libs they KBM link in. Will this problem disappear if end programs will pass --as-needed flag to the ld command line? Some of it is also pkg-config's fault. For example, anyone using pkg-config with gtk+2 gets the following: # pkg-config --libs gtk+-2.0 -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXi -lXinerama -lXext -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXcursor -lpango-1.0 -lcairo -lXrender -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Which is all crap. Yes, this is the list you need for static, but pkg-config is recursing through modules even for dynamic linking which is wrong. Now either pkg-config of the gtk+2 pc file needs to be fixed, then you can start recompiling all the affected programs... Some of the discussion in bug #340904 is relevent here. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem including asm/timex.h (linux-kernel-headers 2.6.17)
On 9/22/06, Martin Kittel [EMAIL PROTECTED] wrote: So this brings me back to me original problem: are user-space applications allowed/supposed to use these headers? And if so, how are they to be used if the headers rely on __KERNEL__ to be defined? My understanding was that userspace should never use kernel headers directly. Instead, userspace should copy the parts of the header that is relevent to them. I think the idea is that eventually stuff expected to be used will be moved to the sanitized headers in glibc. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On 9/20/06, Michal Čihař [EMAIL PROTECTED] wrote: char1 bytes short 2 bytes int 4 bytes long 8 bytes Nothing says long has to be bigger that int, only thing which is defined is: sizeof(short) = sizeof(int) = sizeof(long) so having short, int, long of same size is not a problem. I think you're missing the point. If you make an int 8 bytes, what are you going to call 4 byte integers? If you call them short, what are you going to call 2 byte integers? Anyway, the link to the paper posted in this thread has many much better arguments. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Moving /var/run to a tmpfs?
On 9/19/06, Mario 'BitKoenig' Holbe [EMAIL PROTECTED] wrote: However, the question should rather be: *why* compilers do not define int to be 64bit on a 64bit architecture? And the answer is simple: Yes int should be 64bit on a 64bit architecture, since int is defined as the architectures natural size data type. However, it is mostly not because of the elsewise massively increasing porting-expenses due to many programmers who never thought about it and simply assumed int to be 32bit. Odd, I always thought is was because C did not have enough int types: char1 bytes short 2 bytes int 4 bytes long 8 bytes If you make an int 8 bytes, you have to find some other way of indicating one of the shorter types (short short maybe? or long char?). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linking a static library with -fPIC for flex
On 9/5/06, Manoj Srivastava [EMAIL PROTECTED] wrote: I was initially going to just provide libfl.a with position independent code, which would have prevented the FTBS breakage for scanner containing shared libraries, at the expense of a register lost for binaries that were otherwise statically linked, and perhaps slower execution speeds. There's no performance critical code in libfl. The main function is hardly ever used, and yywrap() is only called at an of input. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On 8/28/06, Mgr. Peter Tuharsky [EMAIL PROTECTED] wrote: We're speaking about distributions that are intended for daily use, not for experiments. To make it clear, Debian 3.1 Sarge and Ubuntu 6.06. If the Etch has it, that's great. However that dosen't matter answering the Debian is at least as good as Ubuntu, just needs more advertising. Would You advertise Etch? It is clearly advertised for Etch, that it is in TESTING state. Would You recommend it everyone for daily usage? I hope You'ld not. Hmm, to me this sounds like this is just another way of saying that Debian doesn't release fast enough. The fact is, sarge has been released, whatever your complaining about is never going to be fixed in sarge, so yes, you need to be comparing with Etch. If you can say that there are problems with Etch, then we can address those. complaining about Sarge is not terribly useful. And yes, lots of people are running etch for daily usage. I don't recommend anything to anyone, I just use what works... A little paraphrase: stable means, that feature bugs are kept for the whole release circle; don't expect them to get fixed. Well, ofcourse. Otherwise it wouldn't be stable... Certain types of bugs are fixed, but by and large, you're stuck with the bugs it was released with... Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem sending to Alioth lists?
On 8/28/06, Roberto C. Sanchez [EMAIL PROTECTED] wrote: No offense, but that is completely non-scalable. That only works for a small number of users which does not change frequently. Anyhow, thanks to 'Dato, I seem to have been able to convince mutt to play nicer with your mail server. Yeah. Other options include allowing users to create a file in their homedir which gives their real email address. However, the easiest in my experience is to do what in exim is called qualify_domain. When it gets a mail to send, that's the domain it appends. So while the host might be box12.mydomain.blah, you set the qualify domain to just mydomain.blah. If you set the same qualify_domain on all your servers, then the problem goes away. This does assume that your username on the machine matches the username of your email address, and that you want bounces coming to where you send the mail, rather than some third-party server elsewhere in the world. I've always found it interesting that mail clients that use SMTP to deliver, like many graphical clients, never suffer from this at all becase they always specify the sender as part of the protocol. Historically mail servers on UNIX have ignored the -f switch to the sendmail command which does the same thing. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem sending to Alioth lists?
On 8/28/06, Roberto C. Sanchez [EMAIL PROTECTED] wrote: What the message suggests to me is that the other machines in your domain should be using address rewriting if they are sending from unroutable addresses. Except that there are multiple domains hosted from my network. Which should I use? BTW, this occurs even from hosts which have publicly routable IP addresses, probably because they are not running a publicly accessible mail server. The point is that I only experience this problem with Alioth and SourceForge lists, where they use braindead call back mechanism to try and reach the host that originated the message. Since I am using mutt and I simply have postfix set to use a smarthost, which does have a publicly accesible postfix running. I'm not 100% sure, but I don't think it matters what domain, the address just has to exist. I think that they're checking your Sender header (which is where bounces get sent) for validity. I remember dealing with this once by getting mutt to add an explicit Sender header, but perhaps you can configure the mail server to rewrite the header to your normal email. Hope this helps, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 7/31/06, Charles Plessy [EMAIL PROTECTED] wrote: Dear Michael, how can we get description for specific packages? There are some pages of the debian web site, such as in the debian-med area [1], which contain package descriptions that have therefore have already been translated in some languages. I noticed no-one really answered your question. You have two options: If you grab the translation template from the DDTP website, you can fill in the translation there and send it via email. It's the little white square next to language on the page where you see the actual description. The other option is to use this[1] other system. Select your language, enter the package name in the field to download the translation template, then paste the translation. The advantage of this method is that other people can review it before it gets sent. It all ends up at the DDTP project eventually, it's just two way of doing the same thing. Hope this answers your question, [1] http://kleptog.org/cgi-bin/ddtss2-cgi/ -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On 8/14/06, Florian Weimer [EMAIL PROTECTED] wrote: And to some extent, the FSF must claim that it's not possible to escape the GPL with a second implementation (so that programs linking to readline must still be GPLed, even though you could use libedit as a mostly-transparent replacement, for instance). Well, if you ship a binary linked against readline, it's not totally unthinkable that the source of the program should be available under a GPL-compatable licence. On the other hand, if you ship the binary not linked against readline, or linked against editline instead, there's no reason that the source has to be distributed under a GPL-compatable licence just because the program _could_ be compiled against readline. If the source is not under a GPL-compatable licence, doesn't that just mean the resulting binary is not distributable at all? The GPL only give rules about redistribution, it doesn't change the licence of anything. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation
On 8/12/06, Marvin Renich [EMAIL PROTECTED] wrote: Also, it impresses me when a package description says something like if you need feature X, you are better off with package M, but this package provides feature Y which package M doesn't have. There was, not so long ago, a complaint about apt-cache search returning useless matches because descriptions tended to include stuff not relevent to them. Like searches for perl would match php, because they listed a competitor. If your package doesn't have feature X then you probably shouldn't be mentioning it in the description. What you say is nice to know, but the description is not the right place. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 8/6/06, Michael Bramer [EMAIL PROTECTED] wrote: Where can we download the script? Here: http://svana.org/kleptog/temp/ddtss-0.1.tar.gz Note, it's a collection of scripts and it needs a little confguration to work. Please read the README. Contact me if you have any questions. It's rough, please be gentle. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 8/7/06, Martijn van Oosterhout [EMAIL PROTECTED] wrote: On 8/6/06, Michael Bramer [EMAIL PROTECTED] wrote: Where can we download the script? Actually, please try this version: http://svana.org/kleptog/temp/ddtss-0.2.tar.gz It's a bit more advanced w.r.t. reviewing, but the nicest thing about it is that it can give hints about translations of technical words. For example, see these two pages: http://svana.org/kleptog/temp/man-db.html http://svana.org/kleptog/temp/atari-bootstrap.html If you hover the mouse over the underlined words, it will display a translation of it. I've added this because I find translating dictionaries tend not to include the technical definitions for many words. Here there is a file of words with translations relating to computers. Hopefully this way we can also encourage some consistancy w.r.t. translating terms like executable, library, caller, binary, script, etc, each of which tends to be translated in different ways by different people. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 8/4/06, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED] wrote: no. the currend ddtp-server don't support the review process, sorry. No problem, just to let the translators aware. We can use the pseudo-urls system to review that, before the translator send it back to the ddtp-server. I've been playing a little and have written a bunch of scripts which I've unimaginativly named DDTS Satellite. It can send and receive emails from the DDTS and provides a web interface where you can do the actual translating. It has the capability to let people review translations before sending them. Reviewers can also amend the translations straight away. It's a bit rough, but I'm using it for my own translation submissions. If people think it's interesting I can put up the source somewhere. Especially the reviewing bit might be handy, since the main server doesn't do that well right now. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 8/1/06, Michael Vogt [EMAIL PROTECTED] wrote: I think we got a step closer, but there is still some work to be done. I'm sure the ddtp server admins will appreciate any help and I would appreciate any testing of the new apt code :) Sure. I was wondering where the code for ddtp server is. There's an alioth project, but it has nothing past the initial commit. Thanks in advance, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
On 8/1/06, martin f krafft [EMAIL PROTECTED] wrote: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. The only example I can think of is programs that use configure to include support for anything they can find installed. So you get different results depending on what's installed in the buildd. It's a bug in the packaging though, the maintainer should be doing --enable-* or --disable-* for every option. The point being that if you only build in a clean chroot you'll never notice the problem. That's how I understand it anyway, Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 7/30/06, Michael Vogt [EMAIL PROTECTED] wrote: Dear Friends, As someone who has been loosely following this for a while and translated a few descriptions, I have a few little questions/comments: 1. The website you provide (http://ddtp.debian.net/) is extremely light on detail. It contains just the translations, nothing else. Something I've wished for is a link to a site provide translations of common technical terms, given they're not in the usual dictionaries. If that link got included in the email it'd be great. At the moment I'm using http://www.kde.nl/helpen/woordenlijst.html but even that's missing some common words. 2. What's with the graph? It looks odd. 3. There's some comments further in the thread about the review process not working, or something like that. What's up with that? Other than that, I'm glad there's progress. Getting translated descriptions is a really cool goal. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On 7/15/06, Andreas Metzler [EMAIL PROTECTED] wrote: Hello, The following setup would be in compliance with rfc2821 but would not be able to deliver mail to a greylisting host: - retrying every hour for up to five days - messages are sent out from 120 different IP-addresses all living in different /27 netblocks. - retries do not happen on the same IP. Initial try IP-address #1, 2nd try IP-address #2, ... ,120th try IP-address #120 I thought the point was that someone with such a setup is unlikely to have all 120 servers either listed on an RBL or with broken reverse DNS. And if they are, are you sure you want to receive mail from them? Greylisting everything is silly, and that's not what's being discussed here (AIUI anyway). Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: greylisting on debian.org?
On 7/9/06, martin f krafft [EMAIL PROTECTED] wrote: also sprach Marc Haber [EMAIL PROTECTED] [2006.07.09.1430 +0200]: For example, that greylisting puts significant load on systems that deliver mail to us, I am sorry, I don't buy this argument at all. First, a 4xx is not significant load on any mailer unless you're running some piece of crap. Sure, when you reach the thousands, even postfix could break the occasional sweat, but which one server delivers thousands of messages to continuously new from/rcpt combinations -- because remember, greylisting caches. The point was about mailers sending mail to debian. If they receive a 4xx they have to queue the mail and retry later. It's cheap for debian, but expensive for everyone else. A far more reasonable solution is to only greylist mail with an unreasonably high spamassassin score. Normal mail I assume generally doesn't score high and is not susceptable to greylisting. Not that I mind, the amount of spam received via this mailing list is so marginal I can hardly imagine people worrying about it. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On 7/7/06, Goswin von Brederlow [EMAIL PROTECTED] wrote: What code do you need there? If the rred method keeps the full Index file in memory during patching it can just be fed all the patches one after another and only write out the final result at the end. Combining the patches is a simple cat. As far as I can see from the code, it reads the input file and the patch with fgets() and writes the output file with fputs(). Since the diffs in the file are in reverse order, it first reads one ed command and recurses so it forms on the stack a set of the file offsets of all the patches. As it unwinds it scans forward through the data file once to apply the patches. Not a terribly bad algorith as such, but it's got quite a bit of disk overhead if the individual files are on disk. It would appear that the algorithm would allow itself to stream output from one patch applier to another, but it would seem to be easiest to simply combine the diffs into one large diff. Techniques for combining diffs are not new, I imagine someone just needs to code it... Hope this helps, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
On 7/3/06, Miles Bader [EMAIL PROTECTED] wrote: [Ok, I guess your autoconf script could guess that without being too ugly.] and pkg-config --libs OpenEXR yields: -lIlmImf -lImath -lHalf -lIex -lz [Yuck... even when using shared libraries, library dependencies don't seem to give -lImath, I'm not sure why (maybe it's only used by inline functions in the headers?)...] Which is a bug in openexr. At the very least -lz shouldn't be there. And -lHalf and -lIex are probably redundant also, since the other two are already linked against them. Until people get into the habit of only listing *direct* dependacies, pkg-config is not universally useful. autoconf works out what you what you need to link your program, and you have control over that. pkg-config leaves you in the hands of maintainers who regularly put the wrong thing in their .pc files. The extra libs should only be listed if you specify --static. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On 6/30/06, Florian Weimer [EMAIL PROTECTED] wrote: * Marc Haber: The machine in Question is a P3 with 1200 MHz. What's making the process slow is the turnaround time for the http requests, as observed multiple times in this thread alone. Then your setup is very broken. APT performs HTTP pipelining. Judging by the way I saw it run, it looked like it was pipelining but only maybe five at a time. Maybe some of the mirrors restrict the number of pipelined requests? Is there a way of detecting such a situation? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
On 7/1/06, Vincent Ho [EMAIL PROTECTED] wrote: On Fri, Jun 30, 2006 at 03:42:12PM +0200, Martijn van Oosterhout wrote: It is also used to compile contrib modules that are included in the distribution. If you started using pkg-config you'd have introduced a build dependancy on a GPL'd program in a BSD licenced package, not exactly a good idea. Hmm, that's an interesting thought, but I'm not sure it's a strong concern. Stephen Gran already mentioned libtool, but regardless you can arrange things so pkg-config isn't a strict dependency. Most configure scripts support various --with-foo arguments, so people who don't wish to use pkg-config can simply pass --with-foo=$HOME/local/foo. pkg-config would thus be helpful but not a strict build dependency. There's two seperate issues here. Firstly, using pkg-config to find libraries. Autoconf solves this nicely already. Maybe in the future autoconf can use pkg-config, but pkg-config is not widespread enough to really do that yet. No dependancy here. Secondly, providing a .pc file so other people can find you. For the libpq client library this might be useful. This doesn't require pkg-config at all, you just need to install a file of the right format in the right place. So no dependancy here either. However, the bit of the thread I responded to was about deprecating pg_config in postgres in favour of pkg-config. pg_config doesn't exist to find the libs or header files for libpq (for client programs), it's existance to provide the necessary information to build shared objects to load into the server. It provides similar information to perl -V and I don't think anyone is going to suggest loading all that into pkg-config. The dependancy I'm talking about would come about because of contrib modules shipped with postgres that create server modules and thus use pg_config to get the correct compiler flags. Replacing that with pkg-config creates a build time dependancy on pkg-config, which is entirely unnecessary. Let me rephrase my previous comment: pkg-config is good for library packages to help other programs find them. It's not as useful for building libraries to load into a specific program. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
On 6/30/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: Is there a reason why gnutls-config and xml2-config aren't just tiny wrappers around pkg-config for backwards compatibility? IMO, it's kinda silly to have each package provide its own -config script with its own set of bugs, rather than having a shared set of bugs in pkg-config. :-) 1. Maybe they need to work on systems where pkg-config isn't available 2. Maybe they predate the existance of pkg-config 3. Some of the pkg-config bugs were bad enough as to make you want to avoid it 4. Custom config tools can often provide more info than available in pkg-config (plugin or config directories). -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
On 6/30/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: | 4. Custom config tools can often provide more info than available in | pkg-config (plugin or config directories). Like: : [EMAIL PROTECTED] ~ pkg-config --variable=system_bus_default_address dbus-1 unix:path=/var/run/dbus/system_bus_socket Sure, but to take an example, PostgreSQL has had pg_config for ages and other projects use this to get the necessary parameters to compile against the installed version. There is no way pkg-config can copy the current set of command line arguments, so you have a backward compatability issue. Also, what you suggest is not exactly shorter. It is also used to compile contrib modules that are included in the distribution. If you started using pkg-config you'd have introduced a build dependancy on a GPL'd program in a BSD licenced package, not exactly a good idea. pkg-config is nice for the constellation of GPL'd libraries currently installed on most linux systems, but once you step outside of that it's not quite as useful. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
On 6/19/06, Marc Haber [EMAIL PROTECTED] wrote: On Sun, 18 Jun 2006 17:27:28 +0200, Martijn van Oosterhout [EMAIL PROTECTED] wrote: The other alternative is to port it to another SSL library, like Mozilla NSS or GnuTLS. Most of the time the SSL code is not terribly complicated and the port is fairly straight-forward. otoh, noone seems to care much about GnuTLS. GnuTLS is causing much grief with the exim4 packages and there is nobody who is willing to help. Is this the /dev/random issue? I thought there was a solution to that, except upstream disagreed? -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
The /dev/random issue is one of the issues, yes. One other is that GnuTLS seems to fail if used twice inside the same address space, such as receiving messages via SMTP over TLS and doing lookups via ldaps if both exim and libldap are linked against the same gnutls libs. Odd. The gnutls library is versioned (on debian anyway) to prevent that being a problem. Do you have a reference? Maybe someone forgot to enable thread safety for libgcrypt. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On 6/19/06, Bastian Blank [EMAIL PROTECTED] wrote: Would it be safe to assume that a size_t can always be cast losslessly to an unsigned long (and then printed with %lu), or are there systems on which only an unsigned long long will do? unsigned long is not sufficient. OTOH, you could weigh up the chance that the number you're going to output is greater than 2^32. If the chance is small, you cast it to long and print using %lu. No chance of compiler errors, the display will just look odd if you do try to print a larger number. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
On 6/18/06, Lars Wirzenius [EMAIL PROTECTED] wrote: The OpenSSL license is incompatible with the GPL. A GPL application needs an addition to its license that allows linking with OpenSSL. Some application authors do that and then Debian (or anyone) can distribute the apps (in a binary form); some don't, or haven't yet, and those apps Debian doesn't distribute. The other alternative is to port it to another SSL library, like Mozilla NSS or GnuTLS. Most of the time the SSL code is not terribly complicated and the port is fairly straight-forward. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
x.org related question
I just got around to upgrading to x.org in testing to see if it's better and see if the 3D support has improved. After much hassle, I got it, but I'm running into a problem with fvwm1. # dpkg --configure --pending Setting up fvwm1 (1.24r-50) ... update-alternatives: unable to make /usr/X11R6/man/man1/fvwm.1.gz.dpkg-tmp a symlink to /etc/alternatives/fvwm.1.gz: No such file or directory dpkg: error processing fvwm1 (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: fvwm1 It's probably because the /usr/X11R6/man/man1 directory doesn't exist, should it? You see, during the upgrade x11-common bailed out complaining that /usr/X11R6/bin wasn't empty. At the moment in /usr/X11R6 I have a symlink for bin but include, lib and man are real directories. Should they be? I can't find an answer. x11-common bailing out is very uncool btw. Letting me drop to a shell would have been better than leaving me with a system full of half configured packages. Even giving me the option to fix the issue in another screen would've been better. It was one lousy symlink from netscape-base-4 holding up the entire process. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x.org related question
On 6/15/06, Steve Langasek [EMAIL PROTECTED] wrote: It's probably because the /usr/X11R6/man/man1 directory doesn't exist, should it? Only if you install some package that contains it. Since nothing else on the system is using it anymore, this is a bug in fvwm1 for trying to create a symlink in a directory it does not ship. Aha, if you do a dpkg -L fvwm1 it doesn't list a /usr/X11R6 directory, but the postinst definitely refers to it. Looks like a bug, I'll file one in the morning... Thank you very much. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.
On 6/14/06, Jari Aalto+usenet [EMAIL PROTECTED] wrote: One thing, when etc/mailcap entry reads: application/msexcel; oocalc '%s'; edit=oocalc '%s What happens then 'oocalc' is not available? How is the error handling done, so that e.g. 'xmessage' is displayed under Window mamager to notify the user? Well, an error status is returned. The calling program can handle this any way it likes. Only the calling program knows the appropriate way to pass this information onto the user. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.
On 6/12/06, Kurt Roeckx [EMAIL PROTECTED] wrote: I'm not sure if the alternatives system is the best place to register mime types. I'm also not sure that a Debian specific solution as the alternatives system is the best way to go. But I can see why this would be useful, and maybe it should work in combination with the alternatives system. Opening based on mime-types is a solved problem, see /etc/mailcap. You can even specify different programs depending on whether you're in X or not. See run-mailcap. In particular: see mime-type:filename will determine the correct viewer for the file and display it. There is also edit, compose and print. Preferences can be consigured globally using /etc/mailcap.order. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Who can make binding legal agreements
On 6/7/06, Jon Kåre Hellan [EMAIL PROTECTED] wrote: Second question: Has a binding legal agreement been made? Indeed it has. Ftp-masters are empowered by Debian to include packages in the archive. They are without question agents of Debian. Debian must accept the legal consequences of their agents' actions, provided they stay within their authority. *If* SPI can be legally identified with Debian, SPI is also bound. You missing an important point. The relationship between SPI and Debian is a bit like the relationship between the EC and the EU. Neither Debian nor the EU exist as full legal entities so cannot have agents, enter into contracts, make agreements or own things. Ofcourse, there are assets to be managed, so there is a legal entity that does this. So strictly speaking you cannot work for or represent Debian, it just doesn't exist in a legal sense. How that applies to the situation at hand, well, use your imagination. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Who can make binding legal agreements
On 6/7/06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Russ Allbery [EMAIL PROTECTED] writes: John Goerzen [EMAIL PROTECTED] writes: Sure. SPI owns many of the machines that Debian owns. If any of these machines are being used to distribute this software, as I think is likely, then SPI could be liable. Oh, very good point. I hadn't thought of this. No. SPI is liable under the terms of copyright law; at most, it can be told to stop distributing things. Err, copyright infringement can be a criminal act as well. So if a DPP (DA or whatever it's called in your jurisdiction) takes a dislike to you (or perhaps someone whispers into their ear), they can haul you or SPI or mirror operators into court without Sun having anything to say about it. And the result could include gaol time, especially for this sort of large-scale willing mass copyright infringement. I guess it's a small risk though... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Please revoke your signatures from Martin Kraff's keys
On 5/27/06, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Fri, May 26, 2006 at 12:33:54PM -0500, Gunnar Wolf wrote: Within the Schengen area (European Union plus Norway, Vatican, and... any others?), you travel between countries without even waving your passport at anybody. That's not fully true. You have to show your passport to the *first* country of that area you get into, from there on, you don't (since there is no customs borders between countries there). Also, not all of the EU is member of the Schengen treaty. Switzerland recently joined even though they are not member of the EU (though they havn't implemented it yet, there are a number of things Switzerland has to do first). The obvious example is the UK, which insists on checking your passport if you come from the mainland. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Sun Java available from non-free
On 5/22/06, Russ Allbery [EMAIL PROTECTED] wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: Given the word estoppel only has meaning in jurisdictions deriving from English common law, I think it'd be silly to assume it works the way you think it does in any of the other jurisdictions Debian or any of its mirrors may come in contact with... In the other jurisdictions that you're familiar with, is there any similar principal where if you make a recorded public statement that something is okay, you cannot then later sue someone for doing what you said was okay? Well, IANAL, but as far as I can see, as long as Sun has a valid reason to change their mind and is willing to compensate any losses caused by them changing their mind, they can do whatever they like. A few possible problems are: - The promise was made without consideration (no symbolic one cent payment) - The promise was not formally notarised. A press notice may not count. - It wouldn't damage Debian or anybody much to revoke the statement. They may not be able to recover damges for the period you relied on their statement, but nothing prevents them from stating the contrary. that's assume the promise is considered valid ofcourse. A comparison of estoppel between English, American and German. It refers to contracts however, we we don't have in this case: http://tldb.uni-koeln.de/php/pub_show_document.php?pubdocid=114700 Thie simplest solution in this case would be if Sun simply attached the FAQ as an addendum to the licence rather than stating it's not legally binding. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Packages violating policy 8.2
On 5/21/06, Goswin von Brederlow [EMAIL PROTECTED] wrote: For multiarch this will be an inconvenience though as people might want to install both 32bit and 64bit of a -dev package. For such small scripts spliting them into extra packages seems wrong but then you have to use alternatives or similar to avoid conflicts. Hmm, if a program to be compiled requires libfoo and libbar, and the user has installed libfoo32-dev and libbar64-dev, where is the error going to be picked up? Are the -dev package actually architecture sensetive? I'd suggest pkgconfig could be used to fix this, except that the --libs produces too much rubbish to be truly useful (see Bug#340904). But if it worked correctly, you could add a --arch flags there to ensure you get the right version. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Sun Java available from non-free
On 5/21/06, Russ Allbery [EMAIL PROTECTED] wrote: The precise terms are to be found in the license: as long as the license is unchanged or unamended (with legally binding additions), the issues should not be considered solved... No one has addressed my question about estoppel. My guess is that Sun's publicly stated interpretation of a clause of the license is more legally binding than you think it is, but I'd love to see a legal opinion. Given the word estoppel only has meaning in jurisdictions deriving from English common law, I think it'd be silly to assume it works the way you think it does in any of the other jurisdictions Debian or any of its mirrors may come in contact with... If the choice-of-venue clause is debatable, then certainly any talk of estoppel is also. Certainly when it comes to licences, I'd say the written version trumps anything. After all, that can be verified, I havn't heard anything verbally from Sun myself saying what may or may not be allowed. But IANAL. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: [draft] Re: Sun Java available from non-free
On 5/19/06, Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: [snip] The software as distributed is complete, it has all the files in the .deb packages, and the dependencies ensure that on the user's system the software layout is like Sun requires, with the optional bits indeed being optional. [snip] Note that the license says ... is distributed *with* your Operating System, and not is part of. I don't know where you read the part of bit? Anyway, we definitely do distribute non-free *with* our OS, ... [snip] The license says distribute [...] to run in conjunction with. We do distribute eclipse, kaffe, gcj, and various others tools and applications, but not to run in conjunction with the Sun Java. Our own policy even prevents us from doing so unless we move the aforementioned stuff to contrib. [snip] Sun wants that every legal entity using the software agrees to its license, but doesn't want to, and doesn't require, the license to be explicitely affirmed manually on each computer. [snip] I think at the very least we can say the licence is terribly worded. The word with has at least 27 meanings, the word software is not adequately defined. Conjunction also has several possible meanings. Thing like estoppel don't apply the same way everywhere, so you can't rely on things like that. Maybe someone should come back with a More Carefully Worded New Sun Java Licence -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: multiarch status update
On 5/14/06, Olaf van der Spek [EMAIL PROTECTED] wrote: On 5/13/06, Henning Makholm [EMAIL PROTECTED] wrote: sense if one considers a #! program to be something that should have predictable behavior no matter what the user happens to have in his $PATH. If the independence is a requirement, yes. But I don't think it has to be a requirement. And I think you can replace the path way with a better solution. My question is: - Why does a python program care whether it's running under a 32 or 64 bit version? Surely it shouldn't matter? - Why would you want to have both types installed simultaneously anyway? For libraries the answer is simple, but multiarch applications simply don't seem useful to me. The solution would be to either forbid having both versions installed, or deal with it via alternatives. They should be indistinguishable from a users point of view. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: multiarch status update
On 5/10/06, Olaf van der Spek [EMAIL PROTECTED] wrote: On 5/10/06, Matt Taggart [EMAIL PROTECTED] wrote: Does it also allow multiple versions of the same package to be installed at the same time? For example, multiple minor versions or multiple major versions? Read the papers listed in the wiki. The short answer is no, same as it is today with single-arch. As explained in the papers, trying to do anything else results in a complex dependency nightmare. That's a shame, as I think a lot of the infrastructure required for multiple architectures overlaps with that required for multiple versions. You've been able to install multiple versions of the same package for a long time, just we give each package a new name. Libraries are the obvious example but you can install multiple versions of postgresql simultaneously. It's not rocket science, just most people don't consider it worth the effort. In any case, I don't think any of this is going to handle multiple architechtures simultaneously magically. It's more like each arch get given a namespace and everything is carefully designed to stop the namespaces conflicting. TANSTAAFL. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: bits from the release team
On 5/5/06, Pierre Habouzit [EMAIL PROTECTED] wrote: Proposal 1: a possible way would be to have two valid keys at any time. like one new key per year (or 6 month like you want) with a validity of 2 years (resp. one year). that would obviously mean two signatures per package (but I don't think that's that much work) and would require the user to update their keyring package only once every year (or 6 month), which looks like a quite reasonnable trade-off. Even stable updates can use that scheme, since it's released more than once a year. Why would you need two signitures per package? Simply have a new key each year this is valid for two years. apt/dpkg is going to have to be able to handle multiple keys anyway because a user can download from multiple respositories. The test is if a package is signed by any trusted key. Generate the key for 2007 on 1st of December 2006. This gives everyone a month to get the new key before it's used. As long as the packages file is signed with both, that should be enough for apt to trust the install. In reality, the only way you can truly trust any key is if you get verification of the fingerprint from some other trusted source. Since we don't do that, all this discussion is handwaving to solve practical problems. Perhaps we should be teaching apt/dpkg to fetch the key from some other source entirely, say an https server, thus avoiding the issues of transporting keys via the same mechanism as the packages. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Policy change about `/usr/lib/cgi-bin' - Mass bug filing pending...
On 5/3/06, Christoph Berg [EMAIL PROTECTED] wrote: Using the path component cgi-lib which will even be visible to users of the web server looks like a big chunk of NIH to me. Even worse, it will break existing URLs when CGIs start to move to their location. To be honest, I thought this policy had a different purpose entirely. I thought it was to deal with the problem of people installing packages and having them install things that conflict with the admin. Or alternately, the problem of having packages be accessable via the webserver before the admin has configured the package. So, debian changes packages to install to cgi-lib where we can ensure they won't conflict. If the admin wants to make them visible they symlink the stuff from cgi-lib to cgi-bin. No special webserver supported needed. Just changing the names seems silly in the extreme. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: effectiveness of rsync and apt
On 5/1/06, Brian Eaton [EMAIL PROTECTED] wrote: Hello all - Regarding the ideas discussed here: http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html A few comments: 3.2 rsync is too hard on servers That document claims it's an avoidable cost. It's not really, because the client presents hashes which the server has to find. The hashes can't be cached on the server because there would need to be 8 bytes of hash per file offset in the file. i.e. the size of the hashes would be 8 times the size of the file. Ergo, the server needs to scan the entirety of the file anyway. Disk i/o *is* expensive. Now, if someone can come up with a clever algorithm to compress the hashes by 100 times, we might have something useful. The reverse rsync algorithm described further down avoids this by having the client do the search. AIUI tridge avoided it because it appears to be patented. The rest of the page is a pretty good summary. The compression problem is the real stumbling block... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: gpg
On 4/29/06, Tamas SZERB [EMAIL PROTECTED] wrote: all replies tries to tell me that I'm intend to crack the GPG. Believe me, If I could do it, I would not use it anymore since it's not safe enough. Err, the password is not an unchangable part of the key. You are in the perfect condition to attempt to crack it since you have some idea of what the password was. If the cracking works, change the password to something you can remember. Anyway, at least, I resolved the upgrade from 1024 to more bits, but I loose my signatures unfortunately. :( If you can find the password again, you can change it without losing the signitures... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: nasty libgnutls11 bug still present (affects exim4 and libnss-ldap)
On 4/19/06, Daniel Hermann [EMAIL PROTECTED] wrote: At the very least, could you please reopen bug #325971 so that people can find out what's wrong with their server. AIUI, anybody can reopen a bug report. It's not considered nice if the maintainer disagrees, but as a rule, for a real bug you can just do it. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On 4/18/06, Rohan Dhruva [EMAIL PROTECTED] wrote: Package: general Severity: normal I want to use vim as my man pager. On other distros, and on sarge, I use this line in my .bashrc # Set vim as the man pager export PAGER=col -b | view -c 'set ft=man nomod nolist titlestring=MANPAGE' - I wonder if the problem is because man is splitting the command line itself rather than letting a shell do it. That's not a bug though... In any case,it seems to me the best solution is to create a scrupt in /usr/local/bin called vipager and set your pager variable to that... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: pkg-config including too much crap
On 4/4/06, Loïc Minier [EMAIL PROTECTED] wrote: gtk+-2.0.pc's Libs only has -lgtk, it requires gdk, atk, and cairo because of grep -ir #include /usr/include/gtk-2.0 | grep -v 'atk' (it needs at least the Cflags). Some people go as far as saying that since the headers are included from gtk's headers, the resulting binaries should be linked against these dependency-libs. Some discussion of this in #340904 and friends. So the end result of this is that pkg-config is great for extracting configuration info and pretty useless for determining which libs you actually need. As a conciencous developer trying to keep your dependancies straight, your only choices are to hard-code the library names in your makefile or to use -Wl,--as-needed. The latter ofcourse has the risk you might actually remove an entry you do actually depend on. What we need is an option follow requires for cflags but not for libs. Hopefully, one day Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
pkg-config including too much crap
Hi, When you run pkg-config you sometimes get a lot more crap than you need. For example: # pkg-config --libs gtkspell-2.0 -L/usr/X11R6/lib -lgtkspell -laspell -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXi -lXinerama -lXext -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXcursor -lpango-1.0 -lcairo -lXrender -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Like, err, a little too much, I think. There was Bug#229980 which says this is fixed only it's not. I'm running version 0.20-1. Is there a way to get sane output from pkg-config or should I just parse the .pc file myself? -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: pkg-config including too much crap
On 4/4/06, Roger Leigh [EMAIL PROTECTED] wrote:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
Is there a way to get sane output from pkg-config or should I just
parse the .pc file myself?
The .pc file needs converting to use Libs.private for libraries which
are only indirect dependencies.
Well, the thing is that the .pc doesn't list all those libraries, it's
just that pkg-config is adding them. The .pc file looks like below.
Apparently, pkg-config is following the Requires link and appending
all those libs also. Perhaps that's supposed to be Requires.private.
Of perhaps the Requires shouldn't be there at all.
There's a bug here somewhere...
-
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: GTKSpell
Description: GTK spelling library
Version: 2.0.10
Requires: gtk+-2.0
Libs: -L${libdir} -lgtkspell -laspell
Cflags: -I${includedir}/gtkspell-2.0
--
Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Bug#358695: ITP: latex-utils -- utilities for LaTeX/xfig
On 3/29/06, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Vincent Danjean [EMAIL PROTECTED] Package name : latex-compile Description : easy compiling of complexe (and simple) LaTeX documents This package provides several tools that aim to simplify the compilation of LaTeX documents : I'm marginally unhappy with the word compile here. LaTeX programs are not being _compiled_; they are being _executed_ and their output are page descriptions. I'd go for something like build or builder. That's somewhere between compiling and just scripts. Or may be make or maker as it's using Makefile fragments. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Australian timezone (australasia) update for this weekend
On 3/23/06, Aníbal Monsalve Salazar [EMAIL PROTECTED] wrote: Hello, The Australian timezone change is a couple of days away. If you are running servers depending on acurrate time, you will need to check or update them. Quick question: If there's an update to the stable libc due a security issue, will it have the update or will all our machines revert back to the wrong behaviour? Thanks in advance, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: shared libraries dependecy problem.
On 3/20/06, Grzegorz Bizon [EMAIL PROTECTED] wrote: Hi. I have problem with dependecies on shared libraries in my package (tleenx2). Linda complains that: W: tleenx2; A binary links against a library that is not depended on. (By the way - shoudn't it be error rather than warning ?) I have checked binary with objdump and ldd and i got ... simillar but not the same results. ldd output shows four more entries than objdump. That is: It's somewhat irritating that linda doesn't say *which* library, but that's beside the point. One way to determine what the issue is by repeating the final link line with -Wl,--as-needed to strip out unused libs. Then diff the objdump output to see which libraries were removed and thus extraneous. However, please *test* the resulting binary. There are libraries out there that don't declare all the libs they need and if you're using one of those the result might be that you fix your package only to reveal a bug in another. People building shared libraries can use -Wl,--no-allow-shlib-undefined to detect this situation. Hope this helps, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Bug#353277: ndiswrapper in main
2006/2/28, Henning Makholm [EMAIL PROTECTED]: Personally I favor using a test somebody invented an earlier time we discussed a similar problem: To determine whether A requires B for the purpose of the social contract, assume hypothetically that B was free and packaged, and then ask whether ordinary packaging practice would lead to A a declaring a Depends: relationship on B in that situation. This test would allow us to move the question into the technical realm. Thank you, this has cleared everything up for me. Now I can stop reading this thread :) -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Editorial changes to the Social Contract
2006/2/11, Jérôme Marant [EMAIL PROTECTED]: There isn't anything to do with politess. If I hurted you, them please accept my apologies. But I'm frank enough to express my view as I feel them. As a non-native English speaker, the vocabulary might not always be appropriate. Hmm, you should probably know that in some places the word extremist has becomes a dirty word like terrorist. I know it's not what you mean, but the evolution of language is not always something we can control. If you do not see how starting with a GNU Manifesto and modifying it to be Manoj's manifesto is a freedom that can be coveted, I am afraid I do not see how you understand the concept of freedom of software actually works. So, in real life, you shall be free to get a copy of some random novel, change few life, and sell it as Manoj novel? If the original is written under a free license, sure. If the author doesn't want that then they shouldn't use such a license. The DFSG does allow you the possibility of requiring changed works to have a different title and you can't pass off their work as yours. But you can use the text as a basis for your work. Either I do consider it as software, and in that case you are right. Or I don't because the hardware is just a container and the work could have an existance out of a computer. A program has no meaning out of a computer. The GNU Manifesto does. Huh? A program certainly has meaning without a computer. That's why you can print it out and read it. Many algorithms can be far better explained by presenting a peice of code than by trying to describe it in words. Being able to create new, derivative essays tailored to my needs and views but based on works by other people is a right that being able to modify software gives me. Even by taking entire paragraph with the exact wording? Please note I don't consider essays and program documentation on the same ground. Why not? Although you may not see the point of being able to produce derived works of essays, I really don't see the point of forbidding it. Words change their meaning over time and at some point the essay won't say what it originally meant. Why shouldn't people be able to touch up the language to match modern forms? For example, what you read as written by Shakespeare now often doesn't match what he wrote exactly. Derived works just take the idea further, in that you change the meaning also. You just can't pass it off as entirely your own. The question is, does Debian want to distribute stuff that it can't update if the need arises? Isn't that what freedom is all about? -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Hi, You make good arguments and I agree with many points. But the following: 2006/2/8, Nick Phillips [EMAIL PROTECTED]: Even if for some reason that I am unable to fathom you do fervently believe that I am wrong in the above paragraph, then there is *still nothing* to say that we can't happily pass GRs that contradict each other. It would be foolish, sure, and perhaps reflect poorly on our ability to work through these things, but democracies pass laws like that the whole time and the courts seem to manage to resolve the contradictions. Debian has no courts to resolve contradictions. No-one has the authority to rule one way or the other. So we have to decide now, before the vote, if there is a contradiction or not. Since there is disagreement here already, we have a difficulty. There are democracies that work this way. In some countries, courts cannot rule a law unconstitutional because that is the role of parliament. If the legislature says it's constitutional, it is. Contradictions are solved by the legislature. The point being that courts apply the law, but do not create it. Back to the issue at hand. Given the only source of authority considered by debian is the developers themselves, what we need to do is draft a GR as follows (I think Manoj suggested something like this): If there is a belief that a GR contradicts the foundations documents, this contradiction can be resolved by: 1. The project secretary 2. A majority vote 3. A 3:1 supermajority vote 4. The project leader. 5. The technical committee 6. Debian-legal The only other possibility is to add a second option to every possible vote asking developers to say whether they think this requires a supermajority or not. Or commually binding arbitration system to sort this out. I hope this doesn't go that far. Note that the alternative to this process is for someone (usually a General, it seems) to stand up and tell the parliament not to be so damn silly, and to follow his interpretation of the constitution, or else. This usually ends badly for all concerned. We have no courts, so what's the alternative? If we get a super-majority of developers to say a majority is enough, we're home. If a majority of developers say a majority is enough, what does that mean? Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: timezone data packaged separately and in volatile?
2006/2/7, Anand Kumria [EMAIL PROTECTED]: It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. Well, perhaps a first start is creating the package for stable-updates; would it be easier for you if I created a diff or would you rather do it yourself? The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ It's quite clear it's not a security bug. Whether it leads to critical data loss or an overly unusable system is debatable. It's just that the clock will be off by an hour for a few weeks. Hardly the end of the world, people run with the clocks on their machines off by months and it doesn't seem to break anything critical. ISTM the d-volatile is the right place for this. However, in the mean time I think someone should send a message to debian-announce that anyone running a debian machine with an Australian (or other affected) timezone needs to get updated zone files from $location. Past policy has been that stable updates don't cover things that arn't critical, even if it makes us look out of date compared to other distributions. A change to that policy should be carefully considered before doing it... -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: For those who care about the GR
2006/1/22, Thijs Kinkhorst [EMAIL PROTECTED]: This goes even further here, because the DFSG is not even a strict set of rules but are guidelines. As we all know, guidelines are subject to interpretation on a case-by-case basis, that's what distinguishes them from rules. Therefore, I think a specific application of guidelines can not be seen as a fact. As someone who can't vote and thus whose opinion doesn't matter, it seems to me that the issue is that people may actually want to vote multiple ways: 1. debian-legal is wrong, the GFDL is compatable with the DFSG and thus should be included in main. 2. I know the GFDL isn't compatable with the DFSG but I think it should be allowed in main anyway. 3. I know the GFDL isn't compatable with the DFSG but the DFSG is only for software not documentation, so it's allowed in main for documentation only. :) It seems that some people see the vote as meaning 1 and others want meaning 2. The latter would seems to require changing the SC, the former wouldn't. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: New make is breaking several packages
2005/12/20, Anthony Towns aj@azure.humbug.org.au: So the old behaviour's POSIX compatible as long as the Makefile doesn't specify the .POSIX target. The real question is, is there a way to allow the old supported-for-years syntax. With large makefiles it uglyfies the file somewhat. And interestingly, in the changelog it's listed as a bugfix. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Re: Size matters. Debian binary package stats
2005/12/18, Andreas Metzler [EMAIL PROTECTED]: Gürkan Sengün [EMAIL PROTECTED] wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - Have you perhaps run some benchmarks? That page has compression and decompression speeds, putting 7zip at about 40% slower than bzip2 and 90% slower than gzip. The decompression speed of 7zip is better than bzip2 but still nothing to write home about. Anyone know a good heuristic for measuring bang for buck for compression algorithms? Have a nice day, Martijn
Re: apt PARALLELISM
2005/12/13, Henrique de Moraes Holschuh [EMAIL PROTECTED]: Time to devise a way to teach it about that, then. HOW to do it is the big problem, though. How should one deal with round-robin DNS mirrors which are supposed to be equal, but are not. What are the failure modes to cater for? I'm not sure about all the failure modes but the two I can think of would be: 1. One of the mirrors out of sync 2. One of the mirrors down ISTM the easiest would be for apt to lookup the hostname itself and treat the single entry as a list of entires, one for each possible address the hostname can resolve to. If one fails, try the next. If you randomise the order you should be able to avoid most of the failure modes... Have a nice day,
Re: apt PARALLELISM
2005/12/12, Henrique de Moraes Holschuh [EMAIL PROTECTED]: We don't want them to open multiple connections even to MULTIPLE servers... That's odd though, because apt *does* open connections to multiple servers all the time. To fetch packages lists, or if a package is only available on one of the servers further down. Secondly, the amount of data to be downloaded is independant of the time it takes, thus, in aggregate, whether apt parallelizes or not won't make any difference to the total bandwidth used, although it may shift more load to the ftp2 servers since they never get used in normal usage. Finally, how much of these slowdowns reported by people are caused by the bandwidth delay product. In that case, two servers will definitly be able to use more than a single server by itself... I didn't think it common practice for large mirror to configure multi-megabyte windows... Have a nice day,
Re: StrongARM tactics
2005/12/8, Goswin von Brederlow [EMAIL PROTECTED]: Anthony Towns aj@azure.humbug.org.au writes:What is required is abuildd-give-back package_version(or whatever you called the alias for wanna-build --give-back). Following this train of thought, wouldn't it be reasonable to have a control @ buildd.debian.net that took simple commands like: give-back package version It could accept any email signed by a debian maintainer. Basic stuff like this is doesn't need to be restricted to just a few people.
Re: I am still on the keyring. With my old key.
2005/11/21, Henning Makholm [EMAIL PROTECTED]: It can be considered bad from a technical viewpoint - as far as I understand the master copy of the keyring is currently on a medium that is under the keyring maintainer's direct physical control. The obvious way of switching to team maintenance of the keyring would entail keeping the master copy in a central machine - for example on a debian.org box somewhere in a colo. Doing that in a way that does not leave the keyring more vulnerable to surreptitious compromise than some reasonable persons might prefer, requires software support that does not currently exist. Thanks for the clear explanation, I certainly hadn't heard that argument before. My first thought would be to simply create multiple keyrings, one for each keyring maintainer, which are merged on a regular basis. Teaching the archive scripts to look at more than one keyring wouldn't be too hard. Anyway, surely the acceptance onto the keyring is designated by a signiture on that key, not just by it's presense in a particular file? How do you ensure the file hasn't been tampered with? Signitures can be revoked, but only by the person who signed it in the first place. Anyway, my GPG knowledge isn't that great. so I'll leave it at that. Thanks for the info.
Re: I am still on the keyring. With my old key.
2005/11/20, Petter Reinholdtsen [EMAIL PROTECTED]: I suspect and hope the DPL try to reason with the people in question first, before the DPL wields his authority and push the current holder of privileged positions aside, as a power struggle with the overworked people in these privileged key positions could become ugly. Do you really want the DPL to push the keyring maintainer aside and give the task to someone else? Do you believe it would work, with the ftp-masters and the Debian system administrators on both sides of such conflict? push aside? There's no rule that says there can be only one. Yes, replacing someone could become ugly, but providing additional hands can't be considered bad, can it? Anyway, ISTM that removing keys from a keyring is much more important than adding new ones, right? I seriously hope the non-elected people blocking and slowing down several important processes in Debian soon realize that there is a problem and that it might be best for them to solve it by stepping aside or allowing new people to help them with the tasks. I hope there is more going on in the background that we are not seeing...
Re: master's mail backlog and upgrade time
2005/11/19, Andreas Metzler [EMAIL PROTECTED]: FWIW he currently does a. Rejecting at SMTP time causes backscatter on forwarded mail, as the forwarding host cannot reject because it already has accepted the mail. And usual way to deal with this is to set: ignore_errmsg_errors_after = 7d If a bounce message can't be delivered they are frozen. After 7 days they are deleted. Problem solved. I can't think of a reason that the mail would keep building up... Have a nice day,
