Processed (with 1 errors): please specify more info
Processing commands for cont...@bugs.debian.org: > tags 506481 -patch +moreinfo Unknown tag/s: -patch, +moreinfo. Recognized are: patch wontfix moreinfo unreproducible fixed potato woody sid help security upstream pending sarge sarge-ignore experimental d-i confirmed ipv6 lfs fixed-in-experimental fixed-upstream l10n etch etch-ignore lenny lenny-ignore squeeze squeeze-ignore. > retitle 506481 wrong cpu optimisation, please specify more info Bug #506481 [general] initscripts: Fix to allow falsified cpu information in /proc/cpuinfo Changed Bug title to 'wrong cpu optimisation, please specify more info' from 'initscripts: Fix to allow falsified cpu information in /proc/cpuinfo' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506481: please specify more info
tags 506481 -patch +moreinfo retitle 506481 wrong cpu optimisation, please specify more info thanks Hi Mark, as I understand it, this bug report of yours is a bit useless atm, as it specifies a workaround for a non-existing (general) problem, while there is no indication which packages are/were really buggy. Please provide more information about the affcted packages (possible cloning and reassing this bug accordingly), else I'll close this bug in some time. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: new package format
2009/8/1 Tollef Fog Heen : > ]] Eugene Gorodinsky > > | I also think some abstraction from the actual filesystem is a good > | idea. For example currently the only way to install a lib in a > | directory other than the one it was intended for is by using a hack > | that would look at the directory of a file and move it somewhere. It > | seems that with the current situation where you want to use > | /lib/i386-linux-gnu tuples instead of the approach used before, would > | be less painful if the current package format had some abstraction > | from the filesystem. Since the programs don't usually care where the > | library is, as long as it is in the LDD_LIBRARY_PATH. > > Except that this doesn't work particularly well. Libraries embed > paths, and detecting when they do is painful. > Haven't thought of that, thanks for the input. > [...] > > | Currently debian policy is to have a .desktop file for each GUI > | program. What would be better, IMHO, is having some sort of > | abstraction, so that the package manager itself would create a > | .desktop file entry, given an icon and some information about the > | package. > > like, the path, the description, translated into multiple languages and > so on? This is just .desktop files reinvented. > Not quite. This separates the actual files the program uses and needs from the files that are needed by the user. It's up to the package manager to decide what to do with the information provided to it (e.g. it could create a desktop icon, a menu icon, add an icon to a dockbar or run the program once it is installed etc.). Granted, you can scan the package and check if it has a .desktop file and read it if the file exists, however this is a bit hackish. > -- > Tollef Fog Heen > UNIX is user friendly, it's just picky about who its friends are > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Hi, On Donnerstag, 30. Juli 2009, Jonathan Wiltshire wrote: > The press team are still announcing [1] this as a "decision to adopt the > policy of timed release freezes beginning with the next release", while > RT maintain that it is under consideration. Which is true? Both! ;-) Or the latter, take your pick. Really, it would have been extremly bad to make a press release the next day reverting yesterdays press release (noone would belive our press releases until after they have aged 48h...) as it would been very bad to just go on... Also, in any case, it's a time based freeze *plan* - how the reality will look when squeeze and squeeze+1 are frozen is not written in PR. And now everybody, fix an RC bug! :) regards, Holger P.S.: Yes, learning is sometimes hard and sometimes its painful too (to learn by mistakes), but in the end, it's definitly worth it. And the alternative is almost always worse. signature.asc Description: This is a digitally signed message part.
Re: Spam on the lists [Was: Re: Account Upgrade (Unex)]
2009/8/1 brian m. carlson : > On Sat, Aug 01, 2009 at 02:24:28AM +0300, Eugene Gorodinsky wrote: >> Is there any way to actually make it harder to spam the list? I just >> subscribed and already see spam and phishing attacks... > > Yes. There are infinitely many ways to make it harder to spam the list, > among them: > > * Allowing posting only by subscribers. > * Requiring a signed agreement and a surety bond before allowing posting > to the list. > * Only allowing people to post to the list if they have an armed guard > standing beside them who shoots spammers on sight. > * Not allowing posting to the list. > > Unfortunately, all the ways that have yet been proposed and not > implemented have been rejected by the listmasters because all of them > involve tradeoffs that are unacceptable to the listmasters or the Debian > community. If you think you have a better one that has not yet been > discussed, feel free to file a bug on the lists.debian.org > pseudo-package. > Thanks. Filed a wishlist proposal. > While you're at it, please don't reply to spam, and if you must reply to > it, please don't quote it. We don't want to see it (again) and you make > it harder for those of us who use statistics-based spam filters. > Ok. Sorry about that > HTH. > > -- > brian m. carlson / brian with sandals: Houston, Texas, US > +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only > OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBAgAGBQJKc4CaAAoJEL9TXYEfUvaLwH0P/jUEkouqTDUdeI53ojekh/TJ > GXQVZsH0xi4/fkK0uLpaYqIEqNWweC6TatAGAHWkHbw4f6DOo4zW7EmAx1Q3tk4v > 80pmgHUZsiwwtuEipEu1iCZGNLL/+QLeCD+YsfG7UY0YEZ5AJ4pviWsnEWrnhGii > cJUGWCF4HgYYwJE6Q6QgVZBGfL1fcTqxARFU6KxqBtfrznqHmC1QzeSt7Avl71sG > TM8Z/zr4mVwwKsRMJmlqLtXgPpOC3W2cQVFWO4g30ynDVvRcHVLRUvB1BCD4nZCE > mtU5PMSn1HMnBRBYkvqzH08H2DAk1V4EX2sB2JfbWN3JjY7WpROrX4rDy4aRszFw > FraRw4NmAh+nSnigpuoPxF87y3L1AoYzaB2zh/p2eQh4sqcZvykUvokMbdfE/gkr > DWFy8Pl7gbDI3q7gPwEQhU87ZOr2xO+EgFsf5QhrN61ZPYkLmri+sMrIfg6UCdKS > Uijb7DbWDtZ73MkJncYA3AxzF86DxYDI16VbU/XTyq+cfKHrCJWGQKgnukqFaw3Q > j6Ys5J4n6CNiKaf3MXLY5wxKXNn3nH0O744JCfUYnA7Baj/eGaPQ/lJnDHzIm602 > dCAZmBWr4N7Eq4FFW6zc570KCwxenMD/VS8+ceuZ79aOyr3c5+fW2vDUlAoLLbMo > NNiTm470tmOgAhL8POol > =fE7h > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Hi! Aurelien Jarno schrieb: >> The press release not only mentions release goals but also >> "infrastructure goals" ftpmaster would like to have done by then. > Then, maybe the ftpmasters should communicate through > debian-devel-announce *in addition* to the press releases. To the best of my knowledge all these points had already been mentioned on different lists, e.g. during the recent "NEW queue" thread. And honestly speaking: The points mentioned have nearly no effect for most maintainers. The point with the highest change of being noticed by Joe Random Developer are the automatic rejection of packages failing lintian tests, which is actually more or lest what is already done manually while processing the new queue now system wide and automatically. So I don't think it's that bad, that ftpmasters haven't announced their plans, yet to d-d-a. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: waf into NEW, please test it with your packages
Il giorno Fri, 31 Jul 2009 22:14:14 -0700 Ryan Niebur ha scritto: > On Sat, Aug 01, 2009 at 02:48:37AM +0200, Cyril Brulebois wrote: > > Ryan Niebur (30/07/2009): > > > would you mind providing a .deb of that so that I can test and > > > update my dh build system patch to use it? > > > > waf deb? Check first mail in the thread. > > > > ok, I misunderstood what Luca was saying. I thought Luca meant a new > version of waf, not a new version of midori :/. Yes, I meant new midori upstream version. I haven't specified it, sorry. We prepared waf_1.5.8+dfsg-2, which implements compatibility with intltool and older versions of wscript. I uploaded preview packages: http://alioth.debian.org/~dktrkranz-guest/waf_1.5.8+dfsg-2/ -- . ''`. Luca Falavigna : :' : Ubuntu MOTU Developer `. `'` Debian Maintainer `- GPG Key: 0x86BC2A50 signature.asc Description: PGP signature
Re: Installation of packages in home directories.
Charles Plessy (01/08/2009): > I would really love to have such a functionality in apt. reportbug cupt (Seems to be an interesting challenge. Not sure it's worth the pain though.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Installation of packages in home directories.
On Sat, Aug 1, 2009 at 3:31 AM, Charles Plessy wrote: > Le Fri, Jul 31, 2009 at 03:20:46PM +0200, Giacomo A. Catenazzi a écrit : >> >> Anyway RH has support to install packages in own homes. This kind of >> abstraction could be nice to have. > > Hi all, > > I would really love to have such a functionality in apt. At work, we use > shared There are various implementations of similar functionality out there, like 0install, klik etc. I imagine dpkg would need some changes, here is the bug for who want to work on implementing this: http://bugs.debian.org/170850 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: waf into NEW, please test it with your packages
On Sat, Aug 01, 2009 at 12:53:42PM +0200, Luca Falavigna wrote: > Il giorno Fri, 31 Jul 2009 22:14:14 -0700 > Ryan Niebur ha scritto: > > > On Sat, Aug 01, 2009 at 02:48:37AM +0200, Cyril Brulebois wrote: > > > Ryan Niebur (30/07/2009): > > > > would you mind providing a .deb of that so that I can test and > > > > update my dh build system patch to use it? > > > > > > waf deb? Check first mail in the thread. > > > > > > > ok, I misunderstood what Luca was saying. I thought Luca meant a new > > version of waf, not a new version of midori :/. > > Yes, I meant new midori upstream version. I haven't specified it, sorry. > > We prepared waf_1.5.8+dfsg-2, which implements compatibility with > intltool and older versions of wscript. I uploaded preview packages: > http://alioth.debian.org/~dktrkranz-guest/waf_1.5.8+dfsg-2/ > still fails, build log attached, you can 'debcheckout midori' and change the WAF variable in debian/rules to reproduce it yourself. -- _ Ryan Niebur ryanrya...@gmail.com tail: cannot open `debian/changelog' for reading: No such file or directory dpkg-parsechangelog: failure: tail of debian/changelog gave error exit status 1 grep: debian/watch: No such file or directory Option download-version requires an argument Usage: uscan [options] [directories] Run uscan --help for more details dpkg-source: warning: extracting unsigned source package (midori_0.1.8-1.dsc) dpkg-source: extracting midori in midori-0.1.8 dpkg-source: info: unpacking midori_0.1.8.orig.tar.gz dpkg-source: info: applying midori_0.1.8-1.diff.gz dpkg-buildpackage -rfakeroot -D -us -uc -i -ICVS -I.svn -I.arch -I.#* -I.cvsignore -I.bzr dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package midori dpkg-buildpackage: source version 0.1.8-1 dpkg-buildpackage: source changed by Ryan Niebur dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh --with quilt clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/tmp/tmp.SGXzStrTuI/midori-0.1.8' /usr/bin/waf --nocache distclean 'distclean' finished successfully (0.000s) rm -rf _build_ make[1]: Leaving directory `/tmp/tmp.SGXzStrTuI/midori-0.1.8' dh_quilt_unpatch No patch removed dh_clean dpkg-source -i -ICVS -I.svn -I.arch -I.#* -I.cvsignore -I.bzr -b midori-0.1.8 dpkg-source: info: using source format `1.0' dpkg-source: info: building midori using existing midori_0.1.8.orig.tar.gz dpkg-source: info: building midori in midori_0.1.8-1.diff.gz dpkg-source: info: building midori in midori_0.1.8-1.dsc debian/rules build dh --with quilt build dh_testdir debian/rules override_dh_quilt_patch make[1]: Entering directory `/tmp/tmp.SGXzStrTuI/midori-0.1.8' ln -sf ../debian/config/Debian.h midori/midori-debian.h test -e midori/midori-debian.h dh_quilt_patch Applying patch default-homepage patching file midori/midori-websettings.c Applying patch add-debian-searches patching file data/search Now at patch add-debian-searches make[1]: Leaving directory `/tmp/tmp.SGXzStrTuI/midori-0.1.8' debian/rules override_dh_auto_configure make[1]: Entering directory `/tmp/tmp.SGXzStrTuI/midori-0.1.8' /usr/bin/waf --nocache configure --prefix /usr Checking for program gcc : ok /usr/bin/gcc Checking for program cpp : ok /usr/bin/cpp Checking for program ar : ok /usr/bin/ar Checking for program ranlib : ok /usr/bin/ranlib Checking for gcc : ok Checking for program glib-genmarshal : ok /usr/bin/glib-genmarshal Checking for program glib-mkenums: ok /usr/bin/glib-mkenums Checking for program rst2html.py : not found Checking for program rst2html: ok /usr/bin/rst2html Checking for program msgfmt : ok /usr/bin/msgfmt Checking for program intltool-merge : ok /usr/bin/intltool-merge Checking for header locale.h : ok Checking for program rsvg-convert: ok /usr/bin/rsvg-convert Checking for unique-1.0 >= 0.9 : ok Checking for libidn >= 1.0 : ok Checking for sqlite3 >= 3.0 : ok Checking for library m : ok Checking for gmodule-2.0 >= 2.8.0: ok Checking for gthread-2.0 >= 2.8.0: ok Checking for gio-2.0 >= 2.16.0 : ok Checking for gtk+-2.0 >= 2.10.0 : ok Checking for webkit-1.0 >= 1.1.1 : ok Checking for libsoup-2.4 >= 2.25.2 : ok Checking for libxml-2.0 >= 2.6 : ok Checking for header unistd.h : ok 'configure' finished successfully (0.547s) Localization:yes (intltool) Icon optimizations: yes (rsvg-convert) Persistent history: yes (sqlite3)
merge sensible-browser in xdg-open AKA how to select the "best" browser
Hi all, this comes from #539191 and the discussion that generated on #d-devel. With Clint (s-b maintainer) we seem to agreed that since: - xdg-open identifies the preferred browser the user selected in his DE environment (like Gnome, KDE, XFCE, etc) - s-b relies on alternatives, that might differ from users selection - xdg-open falls back to s-b in case it's not in a DE env we can merge the s-b code into x-o. Right when I was about to reassign the bug (with the above reasoning) I received a "please don't". AFAIUI the main reasoning behind this requests is that x-o can also open files with the preferred application and not only URLs, and that can be a sort of "security problem" (for example x-o a malicious/dangerous file instead of a URL). But a reply from the originator is welcome to clarify it :) Honestly, I don't that problem (but it won't surprise anyone if I'm wrong) because it's something similar to double-click on a malicious/dangerous executable in a file manager, hence why I wanted to bring this to a wide audience. The questions are: - do you think that converge to x-o as the default way to open a browser is something interesting? (merging s-b into x-o) - do the addition of a "--browser" option to x-o (or a xdg-browser symlink to x-o and the latter to recognize the exec called and act accordingly) might be a solution to the above problem (if a problem exists)? Thanks for your feedback. Have fun, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)
Your message dated Sat, 1 Aug 2009 18:09:54 +0200 with message-id <200908011809.54427.hol...@layer-acht.org> and subject line your provider provides buggy internet has caused the Debian Bug report #535833, regarding general: Slow internet on iceweasel, epiphany and so on... to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 535833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535833 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: important The internet connection is very slow when using the internet navigator on Debian 5.0. This problem doesn't appear on another computer of my network under ubuntu whereas the DNS used is the same for all computers. I fixed this problem: after typing 'about:config' in the adress bar of iceweasel, I modified the key 'network.dns.disableIPv6' to 'true'. This operation works for iceweasel and for epiphany too. I don't know if other applications are affected by this problem (synaptic may be affected). -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- Hi, if you have to disable ipv6 to make "the internet connection fast", the setup at your provider is broken - Debian comes with working out of the box support for ipv6, if you need to disable it to make the network work for you, there is something wrong on the network. regards, Holger signature.asc Description: This is a digitally signed message part. --- End Message ---
Processed: tag
Processing commands for cont...@bugs.debian.org: > reassign 524729 meta-kde Bug #524729 [general] [other] Multimedia hot keys should work by default in KDE. Bug reassigned from package 'general' to 'meta-kde'. Bug #524729 [meta-kde] [other] Multimedia hot keys should work by default in KDE. Ignoring request to alter found versions of bug #524729 to the same values previously set Bug #524729 [meta-kde] [other] Multimedia hot keys should work by default in KDE. Ignoring request to alter fixed versions of bug #524729 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Processed (with 1 errors): tag
Processing commands for cont...@bugs.debian.org: > tag 506481 - patch Bug #506481 [general] wrong cpu optimisation, please specify more info Removed tag(s) patch. > tag 506481 + moreinfo Bug #506481 [general] wrong cpu optimisation, please specify more info Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: merge sensible-browser in xdg-open AKA how to select the "best" browser
* Sandro Tosi [090801 17:55]: > [ making sensible-browser a symlink to xdg-open] > Honestly, I don't that problem (but it won't surprise anyone if I'm > wrong) because it's something similar to double-click on a > malicious/dangerous executable in a file manager, hence why I wanted > to bring this to a wide audience. Please consider the following cases, which are usually considered security bugs: - some commercial mail program (you may guess one time which company wrote it), automatically played audio files attached to an email when opeing it. To determine it is an audio file it looked at the mime type, to play it the usual generic file opening code is used. You may guess one time what happens if such a file is called "virus.exe". - The browser links (or one of its many derivatives) has a list of external programs for the different file types. When it is about to start and external program it shows what file and which content type (and I think which program) it is about to start. Sadly that default was for images not 'see image/png:%' and so on, but only 'see %'. As wine was registering itself as program to open windows executables with, people suddenly got wine starting up, when they thought they had only authorized starting an image. Even in the case of the file manager quoted above, I consider any program just calling xdg-open[2] with it as very likely a security problem. While users should not click on arbitrary stuff, they are usually shown a file-type of what they click on: some text in mail program's attachment list, an icon in a file manager and so on. Thus causing it to start something else[1] is not the fault of the user, but that of the program. The possible problem with changing sensible-browser I see: Currently sensible-browser is opening a browser. All browsers I have yet met only show html (with enough ugly things like javascript and plugins, but only what you also expose when surfing the net) or ask before starting an other program (or were told to never ask again). Thus it is quite thinkable that some program has some file downloaded it things is html and gives this file to s-b, which would not a problem now, but with xdg-open it likely could be. Hochachtungsvoll, Bernhard R. Link [1] one could argue no such list should contain possible harmful things, but especially with interpreters it is hard to be sure there is none left. [2] without giving the mime-type as some option I do not know xdg-open has got yet... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: merge sensible-browser in xdg-open AKA how to select the "best" browser
Hi Bernhard, On Sat, Aug 1, 2009 at 18:41, Bernhard R. Link wrote: > * Sandro Tosi [090801 17:55]: >> [ making sensible-browser a symlink to xdg-open] >> Honestly, I don't that problem (but it won't surprise anyone if I'm >> wrong) because it's something similar to double-click on a >> malicious/dangerous executable in a file manager, hence why I wanted >> to bring this to a wide audience. > > Please consider the following cases, which are usually considered > security bugs: > > - some commercial mail program (you may guess one time which company > wrote it), automatically played audio files attached to an email > when opeing it. To determine it is an audio file it looked at the > mime type, to play it the usual generic file opening code is used. > You may guess one time what happens if such a file is called > "virus.exe". > > - The browser links (or one of its many derivatives) has a list of > external programs for the different file types. When it is about to > start and external program it shows what file and which content type > (and I think which program) it is about to start. Sadly that default not always: iceweasel (just to name one) asks but you can skip that window clicking on a box. Maybe you can skip that check for the every file, didn't want to check. > Even in the case of the file manager quoted above, I consider any > program just calling xdg-open[2] with it as very likely a security problem. > While users should not click on arbitrary stuff, they are usually shown > a file-type of what they click on: some text in mail program's they are usually shown a file extension (quite different from the content of the file, if we consider a malicious situation) or an icon, and I think a malicious guy can fake the "show the icon for the file" algorithm. > The possible problem with changing sensible-browser I see: > Currently sensible-browser is opening a browser. All browsers I have yet > met only show html (with enough ugly things like javascript and plugins, I tried iceweasel with png, pdf, txt and also a odt, and guess what, it opened it :) (end I was also surprised it opened the ooffice file in an embedded tab, nice to know ;) ). > but only what you also expose when surfing the net) or ask before > starting an other program (or were told to never ask again). > > Thus it is quite thinkable that some program has some file downloaded > it things is html and gives this file to s-b, which would not a problem > now, but with xdg-open it likely could be. So, I think that if you believe that x-o is so dangerous, you should file a grave bug against it and against all the applications that use it. But frankly I feel it too extreme. Anyway, have you look at x-o code? the file opening utility (because it seems that the main and only problem with this proposal) uses run-mailcap to open a file, the standard way to open a file or no? x-o is just a glue around other too to try to identify the best candidate to open a file/URL. So there are 2 options: or is so damn wrong that it must be removed from the archive, or there must be a stronger reasoning to not merge s-b in x-o (even more that x-o already uses s-b) then *hypothetical* security problems. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: merge sensible-browser in xdg-open AKA how to select the "best" browser
* Sandro Tosi [090801 20:22]: > x-o is just a glue around other too to try to identify the best > candidate to open a file/URL. So there are 2 options: or is so damn > wrong that it must be removed from the archive, I'm not claiming it is totally wrong. As I said I did not look at what it does. All I want to ask for: If you reinvent the wheel please make it at least round. Better learn from the wheels that were there before. It's really depressing to see the same security problems again and again and again. > or there must be a > stronger reasoning to not merge s-b in x-o (even more that x-o already > uses s-b) then *hypothetical* security problems. All I ask for is that you understand that you are about the change the relavant semantics of something security relevant, and act accordingly. to the rest of the mail: > > - The browser links (or one of its many derivatives) has a list of > > external programs for the different file types. When it is about to > > start and external program it shows what file and which content type > > (and I think which program) it is about to start. Sadly that default > > not always: iceweasel (just to name one) asks but you can skip that > window clicking on a box. Maybe you can skip that check for the every > file, didn't want to check. The browser "links" is not the browser "iceweasel". > > Even in the case of the file manager quoted above, I consider any > > program just calling xdg-open[2] with it as very likely a security problem. > > While users should not click on arbitrary stuff, they are usually shown > > a file-type of what they click on: some text in mail program's > > they are usually shown a file extension (quite different from the > content of the file, if we consider a malicious situation) or an icon, > and I think a malicious guy can fake the "show the icon for the file" > algorithm. Some filemanagers might have security problems. Being able to hide a security problem by another security problem does not reduce the problem. > > The possible problem with changing sensible-browser I see: > > Currently sensible-browser is opening a browser. All browsers I have yet > > met only show html (with enough ugly things like javascript and plugins, > > I tried iceweasel with png, pdf, txt and also a odt, and guess what, > it opened it :) (end I was also surprised it opened the ooffice file > in an embedded tab, nice to know ;) ). > > but only what you also expose when surfing the net) as I said: it's as dangerous as you already are otherwise. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)
]] (Debian Bug Tracking System) | if you have to disable ipv6 to make "the internet connection fast", | the setup at your provider is broken - Debian comes with working out | of the box support for ipv6, if you need to disable it to make the | network work for you, there is something wrong on the network. This is probably the same bug as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435646, which while a bug in the DSL router of users is not possible for most of them to work around, while fairly trivial for us to work around in libc. (Heck, I believe newer libcs already have the fix in.) (I think we should fix it, but I'm not going to fight that battle again, since apparently having loopback ipv6 when no other IPv6 address is configured working is more important than making Debian usable for certain people without having to disable ipv6. See 441857 for the other bug in the story.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
What to do with (packages like) Blender?
Hi folks. It's been a while and I'm now really wondering what to do with Blender. So that everyone can understand, I'm going to try and sum up what I'm facing. Please note it's not intended to be a rant, rather a summary of what I've to deal with. * Upstream doesn't really care about being distributed. The philosophy is rather "unzip and run". And by trying to distribute it, one might disable or even break some features (see below), which upstream doesn't like. * Similarly, when it comes to Release Candidates, the main idea is to get builds for every platform, meaning that between the first build and any other build, many patches get committed to fix various FTBFSes on Windows, Linux, and OS X (and even more?) platforms. No tag, people are supposed to use trunk when they see fit to give it a try. And what really matters is the availability of binaries. * Upstream doesn't really care about security. For example, there is a long standing patch to prevent using predictable filenames in /tmp (by moving the temporary directory to something like ~/.blender/tmp). Fortunately, other distributors seemed to care about sharing the patches and sdiscussing them. * Upstream uses a lot of embedded code copies. Most of them with patches. That means that one has to get rid of them, tweak the sources so as to be able to use system-wide libraries, and most importantly, deal with any breakages that may happen. That's my main problem: they have their own copy of ffmpeg, which is a huge, fast-moving library, and trying to ensure blender is usable at any time after ffmpeg updates isn't trivial (obvious API breakages are still OK, but subtle ones aren't). It looks like I was able to restore the broken sound output, but not the broken video output (not to mention it's been quite some time, like several weeks/months, and I'm quite feeling guilty about that). [I should note there's another upstream bugfix release (2.49a, Debian is at 2.49), which I didn't investigate yet. Maybe that particular bug was noted by upstream and fixed, but I think my point stands anyway.] Which makes me wonder if there's a point in keeping blender as it is. Maybe with someone able to dedicate a lot of time to it, that might be feasible; but for one, I'm not really keen on spending lots of time on problems upstream doesn't even care about (I've been kind of flamed for posting a patch to add support for using system-wide libraries). So: what should I do? I'm thinking about orphaning the package as a first step, and if nobody takes care of it as much as it is needed, just remove it from the distribution. Packaging would still be available in a git repository, so if someone sometime picks it up, it should be quite easy not to start from scratch again. Thanks for any insights. Mraw, (kind-of-lost-) KiBi. signature.asc Description: Digital signature
Re: What to do with (packages like) Blender?
On Sat, Aug 1, 2009 at 10:40 PM, Cyril Brulebois wrote: > It's been a while and I'm now really wondering what to do with > Blender. So that everyone can understand, I'm going to try and sum up > what I'm facing. Please note it's not intended to be a rant, rather a > summary of what I've to deal with. Has upstream been receptive to patches you sent? I would personally lean towards removing it from Debian even though some Debian users may riot. Perhaps they will riot in the direction of upstream and thus bring some sanity to the situation that hasn't yet been achieved. Unfortunately that means no Yo Frankie! in Debian (which has problems of its own). -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
emacs23 uploaded to unstable
I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Please file bugs as appropriate. Note that we have also begun the process of removing emacs21 from unstable/testing. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: emacs23 uploaded to unstable
On 2009-08-01 22:52 +0200, Rob Browning wrote: > I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Thanks! Unfortunately, the current status of NEW means that they will probably not be available for the public any time soon. :-( > Please file bugs as appropriate. Do you have a private repository where these packages are available for testing? Some add-on packages may not be compatible with emacs23, and it would be good to sort this out ASAP. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: emacs23 uploaded to unstable
Sven Joachim writes: > Do you have a private repository where these packages are available > for testing? Some add-on packages may not be compatible with emacs23, > and it would be good to sort this out ASAP. Sure. For now, I've put copies here: http://alioth.debian.org/~rlb/public_html/tmp/emacs23/ Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: emacs23 uploaded to unstable
On Sat, Aug 1, 2009 at 2:32 PM, Rob Browning wrote: > Sven Joachim writes: > >> Do you have a private repository where these packages are available >> for testing? Some add-on packages may not be compatible with emacs23, >> and it would be good to sort this out ASAP. > > Sure. For now, I've put copies here: > > http://alioth.debian.org/~rlb/public_html/tmp/emacs23/ Thanks for packaging this, I think you mean: http://alioth.debian.org/~rlb/tmp/emacs23/ Daniel -- Daniel Moerner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: emacs23 uploaded to unstable
Daniel Moerner writes: > Thanks for packaging this, I think you mean: > > http://alioth.debian.org/~rlb/tmp/emacs23/ > > Daniel Yes, and thanks. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539568: ITP: libsockets++ -- C++ sockets wrapper library
Package: wnpp Severity: wishlist Owner: Leinier Cruz Salfran -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libsockets++ Version : 2.3.4 Upstream Author : gry...@alhem.net * URL : http://www.alhemt.net/Sockets/ * License : GPL Programming Lang: C++ Description : C++ sockets class library This is a GPL licensed C++ class library wrapping the berkeley sockets C API, and therefore works on most unixes and also win32. The library is in use in a number of real world applications, both commercial and open source. .. Features include, but are not limited to, SSL support, IPv6 support, tcp and udp sockets, sctp sockets, http protocol, highly customizable error handling. Testing has been done on Linux and Windows 2000, and to some part on Solaris and Mac OS X. .. The source code is released under the terms of the GNU GPL, but is also available under an alternative license. - -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpz9C0ACgkQ8shpC1uVsMtHMwCdG/5Puo3yQddeN0ULd2h61jZL n34Anibxjw0sSzFCvF2rCmigQBlYLfSm =smrz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)
On Sat, Aug 01, 2009 at 09:51:26PM +0200, Tollef Fog Heen wrote: > ]] (Debian Bug Tracking System) > > | if you have to disable ipv6 to make "the internet connection fast", > | the setup at your provider is broken - Debian comes with working out > | of the box support for ipv6, if you need to disable it to make the > | network work for you, there is something wrong on the network. > > This is probably the same bug as > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435646, which while a > bug in the DSL router of users is not possible for most of them to work > around, while fairly trivial for us to work around in libc. (Heck, I > believe newer libcs already have the fix in.) > > (I think we should fix it, but I'm not going to fight that battle again, > since apparently having loopback ipv6 when no other IPv6 address is > configured working is more important than making Debian usable for > certain people without having to disable ipv6. See 441857 for the other > bug in the story.) Having working local networking is important. We wouldn't consider broken IPv4 loopback acceptable, and broken IPv6 loopback is just as bad. The idea behind the patch isn't bad, but the implementation proposed here is too naïve. The assumption that you only want working IPv6 name resolution when you have a globally-scoped IPv6 address is too simplistic. Not only do you have the local loopback, you also have link-local addresses which you can legitimately use. Does zeroconf support these? Fundamentally breaking IPv6 for these use cases to work around broken routing hardware is IMO a step too far. If there's a better metric for detecting that IPv6 name resolution is broken, and then disabling it, I wouldn't be opposed to it as long as it doesn't break things which are currently working. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
maybe a problem with sid branch
salfrancl:~# pbuilder create --distribution sid [...] The following packages have unmet dependencies: aptitude: Depends: libapt-pkg-libc6.9-6-4.7 but it is not installable Depends: libept0 (>= 0.5.26+b1) but it is not going to be installed E: Broken packages -> Aborting with an error -> unmounting dev/pts filesystem -> unmounting proc filesystem -> cleaning the build env -> removing directory /var/cache/pbuilder/build//31827 and its subdirectories signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: emacs23 uploaded to unstable
Rob Browning writes: > I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Please > file bugs as appropriate. Note that we have also begun the process of > removing emacs21 from unstable/testing. Thanks for packaging this. I grabbed the source packages you made available, built for amd64, and it emacs23-gtk presently working very nicely. Regards, Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: maybe a problem with sid branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leinier Cruz Salfran wrote: > salfrancl:~# pbuilder create --distribution sid > > [...] > > The following packages have unmet dependencies: > aptitude: Depends: libapt-pkg-libc6.9-6-4.7 but it is not installable > Depends: libept0 (>= 0.5.26+b1) but it is not going to be > installed > E: Broken packages > -> Aborting with an error > -> unmounting dev/pts filesystem > -> unmounting proc filesystem > -> cleaning the build env > -> removing directory /var/cache/pbuilder/build//31827 and its > subdirectories > Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539376 Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBCAAGBQJKdS70AAoJEMs9AU7X8bMq+hwQALYP3OuZeGzvSCCq0ykO03Cl Nxk1XsWia7ryKUq3X55+AH9gjBjxhJGtwhbR3fSNn4DVR0IWF04Mg6J2MiYDbwlP GDW6WCiJJL+XY9nlWZsmyamZ6+avU5vFv42bf/duczmNbipTZBSxJMRFulRd96l0 NEO9LIBeGCrRphFcpJ2KhOaRUN2q2YcA9xfBFDZTXH5NOksLn5w1wYB0gLij/Yzt KK4AgwpU6AtwP++A5YZl7fX/s1SupgGqZP4dbzfzzYOrvIQApgRrsrqB3FO3IGEG PPqwPuKWTxzSBxu4cG5BUnb34C1ov3YVJUuLCFZMs7Iwd2rDp4Pp39OoLf5uoLM8 dLbbYwbn+sa+Xy8l0WfDSthS2Gw8MJk70BOrObTgimakcorPG/VGbP89O/Jzmzg8 gqnv27JqGga6CkjDHrw6XbMH31fy06th9gXvpBo7ml8jmUzFOQO5JCXz6b0OsM3k 8QXLbSn7Fe3voEslAn4lQAP0ChU0ipII5mRzhdKlBgv4xN8aXns16bjOYWJanEwF Nc0884h4pUOyJFOZ2+EPbldxiDhivJbXfEx4zdMvlDKAFOaYsUHOjHSXqImNa6NK 4piwMuJqiHYiMNXf1ZrNM9X/lhg3ZSW0NYePBtMLySVVuPiPdT0bjo3qwwL8G8Nb dDL9WuYNcAieaS8Gcy/p =5jpO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)
]] Roger Leigh | Having working local networking is important. We wouldn't consider | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as | bad. Sure, having it working is important. Is it more important than keeping those (often new) users for whom Debian appears useless because of its perceived poor network performance? Anyway, IIRC this is now solved in glibc by sending out the queries in parallel and returning the first answer you get. | The idea behind the patch isn't bad, but the implementation proposed | here is too naïve. The assumption that you only want working IPv6 | name resolution when you have a globally-scoped IPv6 address is too | simplistic. FWIW, it roughly matches what Mac OS X and Windows do. | Not only do you have the local loopback, you also have link-local | addresses which you can legitimately use. Does zeroconf support | these? Fundamentally breaking IPv6 for these use cases to work around | broken routing hardware is IMO a step too far. Does anybody use IPv6-only link-local? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: maybe a problem with sid branch
Leinier Cruz Salfran wrote: > The following packages have unmet dependencies: > aptitude: Depends: libapt-pkg-libc6.9-6-4.7 but it is not installable > Depends: libept0 (>= 0.5.26+b1) but it is not going to be > installed This is not a "problem" with sid, but very simply how sid works. It is *normal* that packages are uninstallable sometimes due to uploads of new versions of packages they depend on. That's the whole point of having sid. Sure, it can be inconvenient if that lasts a bit longer sometimes, but normally the people responsible for solving such issues are well aware of them and such mails (or even bug reports like #539376) are not needed. If you use sid and there are minor dependency issues: tough luck, just be patient and try again later! Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
