Re: Spam on the lists [Was: Re: Account Upgrade (Unex)]
On Tue, Aug 04, 2009 at 08:36 +0200, Sandro Tosi wrote: > On Tue, Aug 4, 2009 at 08:33, Siggy Brentrup wrote: > > On Tue, Aug 04, 2009 at 08:28 +0200, Sandro Tosi wrote: > >> On Tue, Aug 4, 2009 at 08:24, Siggy Brentrup wrote: > >> > And if for whatever reason somebody wants to see your list disfunctional, > >> > you open an easy way to do so by implementing a bot that reports every > >> > message as spam. Do you volunteer to fix such a situation? > >> > >> every report has to be *reviewed* by humans (DDs in this case), so > >> other than a very high number of message to review it would do no > >> harm. > > > > That's obvious, I asked you if you volunteer. > > look it up yourself: > http://lists.debian.org/archive-spam-removals/review/stats.html (my > user is morph...). So, are you going to help us kill spam (reporting > it) or no time for this? So you're Debian's Mr. Antispam, my humble apologies. What I am missing on your statitics page is when statistics started and spam/ham ratio over all postings, not only reviewed ones or did I oversee sth? Moreover monthly summaries to judge current situation preferrably with graphics (cf webalizer statistics) would be a plus. I can only speak about what I received on 20+ mailing list (mostly non-Debian) during the last month. Current spam ratio is quite acceptable for me ( <10 out of >500 per day including personal mail ), it's a single keystroke to move spam to a special folder that is fed to spamprobe train-spam hourly. I can live with the current situation. Finally, if you want me to help on anything Debian related, nag DAM to reopen my account (which one you can deduce from my gpg key). Being a DD from '95 to '04, I won't do any substantial work on Debian without a vote. Thanks Siggy -- Please don't Cc: me when replying, I might not see either copy. bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O< ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature
Bug#539866: ITP: pdfchain -- a graphical user interface for the PDF Tool Kit
Package: wnpp Severity: wishlist Owner: Johann Felix Soden -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pdfchain Version : 0.123 Upstream Author : Martin Singer (m_pow...@users.sourceforge.net) * URL : http://pdfchain.sourceforge.net/ * License : GPL-3+ Programming Lang: C++ Description : a graphical user interface for the PDF Tool Kit The program includes features designed to handle PDF files in a easy way. Basically it can merge, split, add backgrounds or stamps and add attachments. There are some tools for extended needs, too. The GUI is written in GTKmm, a C++ library for GTK+. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCgAGBQJKd9noAAoJEINZGTv9ywnERxEQAI6UO51s4aAG1w7rQ3gFx/AE WNOGRJIdoiaNi2DLEXOIh2+cHpXJnX4/lVFZI606eiVq1H/ZaZOAaxTKuXkJdAYp g7jNQ3Mvr9govzYqr/l3MhYPV/YDcjPbi/Gyix3KOpuSFcTTWR/nSoKxYDWVhUvM d3UamMxJlCtOUVs+kKgKu1SPrzOYWiwa2Rb442oj65ZhyyeTBi3WXh7G1HumqOMO WZ88oA8ZZOAAKItB4RwaQaUy5iAT+RKTBsCMp51tcC+UrtNRkZ0dLtZX39BhR1sN odcCyYYkz8TlX3GbbvVv3WHDofxgOeGBJXGgfX5CcnrNzshk6GJ1aoICdd5k2JI0 BOUWRZ6k9v2F4aytGV+ij6qaVJtYMpvhmsilSSTU+PB1GzwSdppm/ym3BsNqxi4x f7FAm/6yKcH3nvLz91JXKk8n1u6n0M7aQpfLoAHxSvfMN5OLsp67OqaTQVJckuj6 Zyq6cZcZGEu2ORRJF0cSywci3CShcMlKSa54AHzvTRhg9v2EAfNp4RGOJOJ6PoXz 0fYrlsEt3dAFKe6FJ+LFOnGVKGvZvCLDBTCsR2YNYUIGLw8xYiBXQFAXV27ADbgo ZHIJs3f7kuKBNjMrduDD0Ov/CjiTm6EyXXL/xctTT7oaOu9T/FO2OMDIpoTA8gEm 4AGKlwHb8MjzpHEFZXOV =5GFe -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: Spam on the lists [Was: Re: Account Upgrade (Unex)]
Quoting Siggy Brentrup (deb...@psycho.i21k.de): > > look it up yourself: > > http://lists.debian.org/archive-spam-removals/review/stats.html (my > > user is morph...). So, are you going to help us kill spam (reporting > > it) or no time for this? > > So you're Debian's Mr. Antispam, my humble apologies. .../... What's interesting to add is that I've heard at Debconf that the identified (and removed) spam is now used to feed out CRM114 on lists.d.o (or will be, I'm not sure). So, the more spam filtering is done...the better our spam filters might become. signature.asc Description: Digital signature
Re: Status of new source formats project
Perhaps you could talk to upstream about switching to either using unified diffs for updates, tarballs for every release or a git/etc repository? -- 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
Bug#539884: ITP: elementary -- A graphical user interface library using Enlightenment Foundation Libraries
Package: wnpp Severity: wishlist Owner: pkg-e-de...@lists.alioth.debian.org * Package name: elementary Version : 0.5.1.0 Upstream Author : The e17 development team * URL : http://www.enlightenment.org * License : LGPL Programming Lang: C Description : A graphical user interface library using Enlightenment Foundation Libraries Elementary is a widget set based on the Enlightenment Foundation Libraries, primarily aimed at creating graphical user interfaces for mobile and embedded devices. -- Albin Tonnerre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539883: ITP: covered -- Verilog code coverage analysis tool
Package: wnpp Severity: wishlist Owner: "أحمد المحمودي" * Package name: covered Version : 0.7.5 Upstream Author : Trevor Williams * URL : http://covered.sourceforge.net/ * License : GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Programming Lang: C, Tcl Description : Verilog code coverage analysis tool Covered is a Verilog code coverage utility that reads in a Verilog design and a generated VCD/LXT dumpfile from that design and generates a coverage file that can be merged with other coverage files or used to create a coverage report. Covered also contains the GUI coverage report utility that reads in a coverage file to allow interactive coverage discovery. Areas of coverage measured by Covered are: line, toggle, memory, combinational logic, FSM state/state-transition and assertion coverage. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty-proposed'), (500, 'jaunty-backports'), (500, 'jaunty') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538897: marked as done (World and group readable home directories in a default install)
Your message dated Tue, 4 Aug 2009 11:19:22 +0200 with message-id <200908041119.29624.hol...@layer-acht.org> and subject line Re: Processed: Re: Bug#538897: World and group readable home directories in a default install has caused the Debian Bug report #538897, regarding World and group readable home directories in a default install 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.) -- 538897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: Unknown Version: Unknown In a default installation of debian 5.0 the home directories of users, including root, are world and group readable. May I suggest that the default permissions are user-only readable. I am using Debian/GNU Linux Lenny 5.0, kernel 2.6.26-1-686 -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze --- End Message --- --- Begin Message --- Hi, this is a feature not a bug. It also has been discussed several times on the debian-boot mailinglist, thus closing. regards, Holger signature.asc Description: This is a digitally signed message part. --- End Message ---
Bug#506481: marked as done (wrong cpu optimisation, please specify more info)
Your message dated Tue, 4 Aug 2009 11:22:26 +0200 with message-id <200908041122.27176.hol...@layer-acht.org> and subject line not a bug in debian has caused the Debian Bug report #506481, regarding wrong cpu optimisation, please specify more info 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.) -- 506481: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506481 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: initscripts Version: 2.86.ds1-61 Severity: normal Tags: patch This fix allows falsified cpu information in /proc/cpuinfo, by creating an override file /etc/cpuinfo: The following changes apply to the /etc/init.d/mountkernfs.sh script: # # Mount proc filesystem on /proc # domount proc "" /proc proc -onodev,noexec,nosuid # # Override /proc/cpuinfo with falsified information, if required # if [ -e /etc/cpuinfo] ; then mount --bind /etc/cpuinfo /proc/cpuinfo fi # # Mount sysfs on /sys # -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-486 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages initscripts depends on: ii debianutils 2.30Miscellaneous utilities specific t ii e2fsprogs1.41.2-1ext2/ext3/ext4 file system utiliti ii libc62.7-15 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii mount2.13.1.1-1 Tools for mounting and manipulatin ii sysvinit-utils 2.86.ds1-61 System-V-like utilities Versions of packages initscripts recommends: ii psmisc22.6-1 Utilities that use the proc filesy initscripts suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Hi, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506481#64 explains well, why this isn't a bug in Debian, thus closing. regards, Holger signature.asc Description: This is a digitally signed message part. --- End Message ---
Re: Bits from the release team and request for discussion
Hi Anthony, On 2009-08-03, Anthony Towns wrote: > So arm's dropped off that page, kfreebsd-* have been bumped to "TBD", > and alpha, hppa are still accompanied by ia64, powerpc, mips and s390 as > being "at risk". There's lots of fields with just a "?" -- apparently > there's no info on whether the RMs have concerns about everything but > amd64, m68k, s390 and sparc... Anyway, some suggestions: I'm grateful for those suggestions, Anthony. That page is just a pain to maintain though. Not everything on it is up-to-date yet but I updated quite some chunks. > m68k isn't "available" anymore, afaics -- it's not in unstable; > doesn't seem any point having it in the list afaics Yep, I thought the same but didn't dare to drop it. I agree. > amd64 has d-i support, surely? it did for lenny, despite lenny's > page... I marked it as green now, together with upstream support. > querying port maintainers for amd64 and i386 seems like a waste of > time. is there really any concern that no one will be > around to support them? I guess there is no real concern there as glibc/gcc maintainers are mainly working on that architectures. So porter requirements can be waived, IMHO. However there should be port maintainers for the others and I see some lacking in that regard. (One gets hit by a bus and the port dies or similar.) > the -concerns should probably have two possible states: "no", > or "yes" with one or more links to mailing list threads > stating those concerns ACK. > having the "Porting machine" answer be "yes" with a link to > the appropriate http://db.debian.org/machines.cgi?host=foo > page would be as informative and help make the table > take up less space True. I'm even not sure if everything's up-to-date there, yet. Aliases would be great like machine=$arch-porterbox. > using blue to distinguish waived requirements might be helpful, > with something like Users: "45 (w)" to save space. Having > (w) link to a list post explaining the waiver would > probably be helpful for people who'd like to understand > why armel gets a waiver for multiple buildds but hppa > doesn't, eg. hppa has currently 4 buildds because at least one is very crashy. But maybe we should decommission that twin then. I fully agree on the waiver thing, it also helps when revisiting the decisions. > both s390 and alpha seem to be keeping up with the build > up-to-dateness requirements, based on the buildd.d.o > graphs. probably worth linking the row headings for those > percentages to the buildd.d.o graphs, really While that might be currently true for alpha I expect that to drop rapidly as soon as problems pop up because nobody will care. That's probably playing into the number of porters part, but still. > redoing the qualification page every release seems pointless; it's > a wiki page so it's not automatically up to date or > correct, and still needs to be validated by the release > team; and arch maintainers don't seem to particularly be > excited about doing it for exiting architectures... after > initial qualification, why not have the status page be > the canonical summary, linking to list posts for further > information as necessary? There is still the problem that we want porters to commit themselves for a cycle. I don't see how we should find out about them, too, if they do not reply on mailinglists for example. Kind regards, Philipp Kern -- 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
On Tue, 04 Aug 2009, Philipp Kern wrote: > > with something like Users: "45 (w)" to save space. Having > > (w) link to a list post explaining the waiver would > > probably be helpful for people who'd like to understand > > why armel gets a waiver for multiple buildds but hppa > > doesn't, eg. > > hppa has currently 4 buildds because at least one is very crashy. But maybe > we should decommission that twin then. and one is security-only and the 4th is really the porterbox and the buildd was supposed to be there *temporarily* to see how it does. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539944: RFH: logcheck / also an idea for a logcheck rewrite
Package: wnpp Severity: normal We could use help with logcheck, specifically: - bug triaging, which is mainly updating rule files - bug fixing of features and faults - implementing templates for rules, e.g. @IPADDR@ and refactoring the rule files so that there aren't seven dozens different regexps for IP addresses - improving the performance and usefulness * only process filters for packages that are installed * find a way to avoid the multipass approach logcheck currently takes The package is maintained with Git, but there are no branches, so use is trivial. If you're interested, please pass me your alioth.debian.org account so that I can give you commit access. * * * In the long run, I'd love to see a rewrite of logcheck with some of the following features: - tag-based, so that an admin can choose whether to see e.g. daemon restart messages, authentication attempts for invalid/nonexistent accounts, etc. - runs as a daemon and can process new log entries instantly. - possibly interfaces directly with rsyslog to avoid having to go via log files - configurable actions, e.g. mail, jabber, file, postgresql - provide patterns/templates and easy instructions (possibly automatic filter generators) to encourage package maintainers to provide the files themselves. - possibly require message samples with each filter to allow for a test suite. - and many more. Please send further ideas to this bug report. Talk to me if you're interested in this, and I'd be happy to assist. I don't have time to do it myself. -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Processed: Re: Bug#539784: address lookup errors only in gnome-terminal
Processing commands for cont...@bugs.debian.org: > reassign 539784 general Bug #539784 [gnome-terminal] address lookup errors only in gnome-terminal Bug reassigned from package 'gnome-terminal' to 'general'. Bug #539784 [general] address lookup errors only in gnome-terminal Bug No longer marked as found in versions gnome-terminal/2.26.2-2. Bug #539784 [general] address lookup errors only in gnome-terminal Ignoring request to alter fixed versions of bug #539784 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
orphaning kazehakase
Hi, Is anyone interested in taking over kazehakase? kazehakase -- GTK+-base web browser that allows pluggable rendering engines It needs some serious love; upstream still appears to be somewhat active, but shifting gecko APIs and a lack of release in almost a year makes this more challenging than simple packaging. Oh, and knowing japanese would probably help, as that's what upstream speaks. It currently fails to build (debian's 0.5.4, upstream's 0.5.6 release, and the current svn trunk all FTBFS). I no longer use the package, and I haven't heard a peep from Hidetaka Iwai since...well, ever. It's time for someone who actually uses it to take it, or I'll request its removal from the archives. -- 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
On Tue, Aug 04, 2009 at 01:09:14PM +0200, Philipp Kern wrote:
> I'm grateful for those suggestions, Anthony. That page is just a pain
> to maintain though. Not everything on it is up-to-date yet but I updated
> quite some chunks.
So make it easy to maintain... Attached is an example converting it to
yaml with python table generation, coping with waivers.
I've made it automatically classify any arch with any failures as "at risk",
rather than letting it remain listed as a candidate. It'd probably be better
to have any warnings imply "at risk" and any failures come pretty close to
meaning "no", though...
Anyway, have a look, see what you think.
It'd be really nice to have all the buildd criteria be measurable (and then
automated). One idea might be to change "fast security" and "redundancy" into
speed/load measures, something like:
alpha amd64 armels390
buildd-speed 95%100% 50%113%
(%ge of i386/amd64)
buildd-load 55% 60% 95% 20%
n-buildds 2 3 6 1
idle-buildds 0.9 1.2 0.3 0.8
where speed is calculated as the overall average of:
time-to-build-on-$ARCH / time-to-build-on-i386/amd64
(ie, dpkg takes 20s to build on alpha, versus 13s to build on i386 after
and amd64+source upload would give 154%)
load is the percentage of time on average that each buildd is actually
building something, and idle-buildds is "n-buildds * (1 - buildd-load)".
Release criteria are then something like "buildd-speed >= 50%",
"idle-buildds >= 1".
Cheers,
aj
#!/usr/bin/env python
# Copyright (c) 2009 Anthony Towns
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
import sys, yaml
### formatting helpers
def FAIL(value): return ("red",value)
def WARN(value): return ("yellow",value)
def PASS(value): return ("lime",value)
def c_truth(value):
if value == True:
return PASS("yes")
elif value == False:
return FAIL("no")
else:
return WARN(value)
def c_untruth(value):
if value == True:
return FAIL("yes")
elif value == False:
return PASS("no")
else:
return WARN(value)
def c_host(value):
if not value: return FAIL("none")
return PASS('http://db.debian.org/machines.cgi?host=%s";>yes'%(value))
def c_list(maybe,okay):
def c_list_f(value):
n=len(value)
str='%s' % (", ".join(value),n)
if n < maybe: return FAIL(str)
if n >= okay: return PASS(str)
return WARN(str)
return c_list_f
def c_num(maybe,okay):
def c_list_f(value):
if value < maybe: return FAIL(value)
if value >= okay: return PASS(value)
return WARN(value)
return c_list_f
def c_str(value):
if not value: return FAIL("-")
return PASS(value)
# criteria
criteria = [
("available", c_truth),
("portbox", c_host),
("porters", c_list(2,5)),
("users", c_num(30,50)),
("installer", c_str),
("archive-coverage", c_num(90,95)),
("archive-uptodate", c_num(95,97)),
("buildds", c_list(2,2)),
("buildd-redundancy", c_truth),
("buildd-fast-sec", c_truth),
("buildd-247",c_truth),
("concerns-rm", c_untruth),
("concerns-srm", c_untruth),
("concerns-dsa", c_untruth),
("concerns-sec", c_untruth),
("candidate", c_truth),
]
# table output
def dump_table(info,waivers):
arches=info.keys()
arches.sort()
candidacy_at_risk = {}
print ""
print ""
for arch in arches:
print "%s" % (arch)
candidacy_at_risk[arch] = False
print ""
for c,c_fn in criteria:
print "%s" % (c)
for arch in arches:
v=info[arch].get(c,None)
if c=="candidate" and candidacy_at_risk[arch]:
if v == True: v = "at risk"
if v is not None:
col,contents = c_fn(v)
else:
col,contents = FAIL("-")
w = waivers.get(arch,{}).get(c,None)
if w:
col="cyan"
contents += ' (w)' % (w)
if col=="red":
candidacy_at_risk[arch]=True
print '%s' % (col,contents)
print ""
Bug#539961: ITP: firegpg -- Iceweasel/Firefox extension to use GnuPG on the web
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: firegpg Version : 0.7.8 Upstream Authors: Maximilien Cuony and Achraf Cherti * URL : http://getfiregpg.org/ * License : MPL/GPL/LGPL Programming Lang: C, XUL Description : Iceweasel/Firefox extension to use GnuPG on the web FireGPG is an Iceweasel (Mozilla Firefox) extension which brings an interface to perform OpenPGP operations over the web. With it, you can encrypt, decrypt, sign or verify the signature of a text in any web page, including GMail, using GnuPG. There are also special buttons that appear specifically in GMail. This extension works fine with any webmail or text box in websites. . FireGPG is written in English and French and is translated to many more languages. - FireGPG was in debian up until recently, but was removed due to security concerns. The new upstream version i'm preparing for debian addresses those concerns, and i've been working with upstream to address some other usability and security concerns. My goal is also to make this package conform to the new draft policy on xulrunner app extensions, as formulated here: http://wiki.debian.org/Teams/DebianMozExtTeam --dkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIVAwUBSniL8szS7ZTSFznpAQoZuw//fWTB48O944k6CptcWRXNOyIBI6FW32/Q fVCfW9yC50ZmZnZ6/Dru/KcwBM578Cvgi1YUIMbQQYCj+LmpHWiuH2RGuH3yj5zh nIZHgvsN3ypg6q6+Jpsu6C4jZ1rPEI6PH367f5rjiKs9L8LpQJS73d0rzbnVQkS7 JfNc+QdVV9CfqIKOk8r9rCOQfitRJi/vxo0NDVC6YlT8Ii05NgQggFFboS5lclsO TOEZSoMGID1DvilyEtD4vnjt2MDmM63+buUPeW+vNwQjRfTUP5cyotWES5KVActk 3/2lKr4zMh10IGz/4zVTEbK9O+HZ95NCPxVlnk/n0a0Osk14O8ud8S485C87S4KX FBQhuB1d3F/4Z3FWv/2JvUunFFCzTqe90FIuf57Fe1rc0j7iGegh3DPOactu4p6L HXuZGmv2LKvjrcANXrG0FB7SdFHmXaHKidV1kxDp8gjBJvR/pyAdByF7nIVMADFF f0gcGg39XE+CZcdeX7pOuhE7YH0RHVp4Rr0PZKZvAEadLrmX4nBbyPo6RxP+IJVO 2/wQj86kyAML1/WjQ8BdxA6kGvZHh1e9wpZI+s+Zv2j5HIgxb5NFxlWV7zj1jWu6 ED70mnlWLasAuBfVdHoe4tG4CjMrb4M9ijRYTej5I2o2MEy6aP6NhZFUQjQvSQNC dfdRFHO7f1s= =BP75 -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: Bug#539961: ITP: firegpg -- Iceweasel/Firefox extension to use GnuPG on the web
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel Kahn Gillmor wrote: > Package: wnpp > Severity: wishlist > Owner: Daniel Kahn Gillmor > > * Package name: firegpg > Version : 0.7.8 > Upstream Authors: Maximilien Cuony and Achraf Cherti > > * URL : http://getfiregpg.org/ > * License : MPL/GPL/LGPL > Programming Lang: C, XUL > Description : Iceweasel/Firefox extension to use GnuPG on the web > > FireGPG is an Iceweasel (Mozilla Firefox) extension which brings an > interface to perform OpenPGP operations over the web. With it, you > can encrypt, decrypt, sign or verify the signature of a text in any > web page, including GMail, using GnuPG. There are also special > buttons that appear specifically in GMail. This extension works fine > with any webmail or text box in websites. > . > FireGPG is written in English and French and is translated to many > more languages. > > > > > FireGPG was in debian up until recently, but was removed due to > security concerns. The new upstream version i'm preparing for debian > addresses those concerns, and i've been working with upstream to > address some other usability and security concerns. I originally filed the bug that got FireGPG removed from Lenny, and I just wanted to say that I absolutely support its reintroduction to the archive. FireGPG was removed because the old version had security flaws and it was too late in the Lenny release cycle to contact upstream to cherrypick the fixes from their svn. However, they seem to have a receptive upstream and it's a very useful plugin for firefox. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBCAAGBQJKeJKvAAoJEMs9AU7X8bMqYm8P+wUK0Tj0GciH3wcTrGQxzGdT vc3lA1WVf19xdY+YX14AKCBOwSPFRB9DA2Q9z//fitQS2Z/gBhu/vnY2YWdDA2to JGfiDxUCIWogUjDotLfcc9/yXyLwQ+815VNpMXL0Zrx+r3JAsLyQVSdJ2VYfzlU6 hkDZZx7YZy83zvU1gXTdCwt+70z9Lp3Wnl7E8qty/bYzg0KH8MI12GenbWGmPVUP GMlW1YBARqS0+uGlMQOKYwGxqhd9YfovVDG5Vu9JYofaPMIv9c0ls11iWaEDjI54 7H8OAN3Mde3V8fg/1mIu1QdL626y1VU4brzASWWEt0dztzXomt4R5Ii5cYROKcO4 jOnVFNCpVdIhC6L9/PRR+HmXIfJo592o2wEQ70hSpWd5ARJ2A7rqswKoGNP+2xyh iIlFBKz8eiCUDR8T7m32Fno/2hPtUYFq0upzDcdzRGgmImdABt9gbMu/eT2PETOw EFMIn1wAnhNOXWwnYH7mlPsBoFmEx73osmv3mQDWMPJSdfcDABA+kIDd5ljkWwS9 fdd6PS2521Kftji/1wgWVUkXKIl0RCc1ikDbc4vFS/yfL5MIx0AhT1u0wHlGCFez mMH2O62jBjfH4zkreJbuc5DMyEso5mvMIl5eF6Mmsx4pPgWUhuzHNZNE5AiJ1SIM jJVod6V3uhO5gWg5ZtkJ =wrTs -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#539965: ITP: jbig2dec -- JBIG2 decoder library
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: jbig2dec Version : 0.10 Upstream Author : Artifex Software, Inc. * URL : http://jbig2dec.sourceforge.net/ * License : GPL-2+ Programming Lang: C Description : JBIG2 decoder library jbig2dec is a decoder library and example utility implementing the JBIG2 bi-level image compression spec. Also known as ITU T.88 and ISO IEC 14492, and now included by reference in Adobe's PDF 1.4. -- 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 Anthony, On 2009-08-04, Anthony Towns wrote: > On Tue, Aug 04, 2009 at 01:09:14PM +0200, Philipp Kern wrote: >> I'm grateful for those suggestions, Anthony. That page is just a pain >> to maintain though. Not everything on it is up-to-date yet but I updated >> quite some chunks. > So make it easy to maintain... Attached is an example converting it to > yaml with python table generation, coping with waivers. wow thanks, that was unexpected. I'll try to get the YAML ready soon and deploy it. > It'd be really nice to have all the buildd criteria be measurable (and then > automated). One idea might be to change "fast security" and "redundancy" into > speed/load measures, something like: > > alpha amd64 armels390 > buildd-speed 95%100% 50%113% > (%ge of i386/amd64) > > buildd-load 55% 60% 95% 20% > > n-buildds 2 3 6 1 > > idle-buildds 0.9 1.2 0.3 0.8 > > where speed is calculated as the overall average of: > > time-to-build-on-$ARCH / time-to-build-on-i386/amd64 > > (ie, dpkg takes 20s to build on alpha, versus 13s to build on i386 after > and amd64+source upload would give 154%) > > load is the percentage of time on average that each buildd is actually > building something, and idle-buildds is "n-buildds * (1 - buildd-load)". > Release criteria are then something like "buildd-speed >= 50%", > "idle-buildds >= 1". This does assume though, that every buildd is doing everything which is not true for all architectures. And the buildd load is currently only calculated and stored on the buildd and not centrally. It could however be collected at some point. (We do not have all logs neither because security ones are not mailed to the log repository but only to security people.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539784: address lookup errors from terminals
On Tue, 4 Aug 2009, Emilio Pozuelo Monfort wrote: > reassign 539784 general > thanks > > I get the same in an xterm. Not a gnome-terminal bug. Yeah on the console too. Is it a network-manager problem maybe? I use iwl3945 - it is definitely broken at Brendan's Bakery on Mission in Santa Cruz - awesome sandwiches there. Both the stock kernel and my own have that problem. But I think it happened at home on the wire once. MDNS problem? iptables logs everything it blocks except windoze and it's not logging anything blocked. but i don't understand why the browser works on the same names, does iceweasel keep a dns cache? at home if i use the stock debian kernel (2.6.26-17) there is an arp loop on the wire interface asking who has 169.* addrs. i have been too lazy to figure out ip6tables so i turned off ipv6 in my own kernel. Mark -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539784: marked as done (address lookup errors only in gnome-terminal)
Your message dated Wed, 5 Aug 2009 01:03:41 +0100 with message-id <20090805000341.ga7...@carbon.pseudorandom.co.uk> and subject line Re: Bug#539784: address lookup errors only in gnome-terminal has caused the Debian Bug report #539784, regarding address lookup errors only in gnome-terminal 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.) -- 539784: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539784 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: gnome-terminal Version: 2.26.2-2 Severity: important Apologies if this is not the source of this bug but it's the only place I see it. This doesn't make a lot of sense. I first encountered this problem on a buggy wireless at a cafe. Now I'm having it at home. I can't explain this: ^ched...@maggie:~/Desktop$ ping scriptdolphin.com PING scriptdolphin.com (64.22.103.163) 56(84) bytes of data. 64 bytes from li16-163.members.linode.com (64.22.103.163): icmp_seq=1 ttl=51 time=81.9 ms ^C --- scriptdolphin.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 81.903/81.903/81.903/0.000 ms hed...@maggie:~/Desktop$ scp tuffytest.odt scriptdolpin.com:/tmp ssh: Could not resolve hostname scriptdolpin.com: Name or service not known lost connection hed...@maggie:~/Desktop$ scp tuffytest.odt scriptdolpin.com:/tmp ^ched...@maggie:~/Desktop$ scp tuffytest.odt 64.22.103.163:/tmp tuffytest.odt 100% 11KB 10.6KB/s 00:00 hed...@maggie:~/Desktop$ nslookup scriptdolphin.com Server: 68.87.76.182 Address:68.87.76.182#53 Non-authoritative answer: Name: scriptdolphin.com Address: 64.22.103.163 I can call up the hostname in iceweasel just fine. Now I can get it again in the command line, too, and everything seems fine again. Great. Mark -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-maggie-9 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-terminal depends on: ii gnome-terminal-data 2.26.2-2Data files for the GNOME terminal ii libatk1.0-0 1.26.0-1The ATK accessibility toolkit ii libc62.9-12 GNU C Library: Shared libraries ii libdbus-glib-1-2 0.80-4 simple interprocess messaging syst ii libgconf2-4 2.26.2-1GNOME configuration database syste ii libglib2.0-0 2.20.1-2The GLib library of C routines ii libgtk2.0-0 2.16.1-2The GTK+ graphical user interface ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libpango1.0-01.24.0-3+b1 Layout and rendering of internatio ii libsm6 2:1.1.0-2 X11 Session Management library ii libstartup-notification0 0.10-1 library for program launch feedbac ii libvte9 1:0.20.5-1 Terminal emulator widget for GTK+ ii libx11-6 2:1.2.2-1 X11 client-side library Versions of packages gnome-terminal recommends: ii gvfs 1.2.2-2userspace virtual filesystem - ser ii yelp 2.26.0-2 Help browser for GNOME gnome-terminal suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Mark Hedges wrote: > ^ched...@maggie:~/Desktop$ ping scriptdolphin.com ^^^ [...] > hed...@maggie:~/Desktop$ scp tuffytest.odt scriptdolpin.com:/tmp ^^ Er, check your spelling? That's not the same hostname. It looks as though everything you pasted is working fine, under the reasonable assumption that scriptdolphin.com is meant to exist, but scriptdolpin.com is not. As such, I'm closing this bug; feel free to reopen it if you can reproduce similar problems when using the same hostname consistently. Regards, Simon signature.asc Description: Digital signature --- End Message ---
Can you (re)confirm that packages re-uploaded to NEW are processed according to the date of their first upload?
Dear FTP team, when I notice potential problems in the debian/copyright file of packages in the NEW queue, I contact the maintainers and suggest them to re-upload a corrected version to save your time. (http://wiki.debian.org/CopyrightReview). The web summary of the queue contents lists the packages by upload date, but I remember reading from you in a previous discussion that the queue is processed according to the date of the first upload. Unfortunately, I lost the reference… Can you confirm, or can somebody point me at the correct message in our lists archive, so that I can document it on the wiki page? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Le Tue, Aug 04, 2009 at 09:51:26AM +0200, Paul Wise a écrit : > Perhaps you could talk to upstream about switching to either using > unified diffs for updates, tarballs for every release or a git/etc > repository? For sure, Debian can suggest them git, Ubuntu can suggest them bzr, Fedora can suggest them cvs, and Opensuze can suggest them svn. I do not mind working with patches instad of archive updates. For Debian, it also has the advantage of not having 12 orig.gz updates per year (12 × 20 Mo archives). I do not know how it matters with recent hard drives, however… And for the format of the patch, I do not know what to tell them apart that unified diff is the preferred format of some Debian developers, and that we like that others use the formats that we prefer. I think that is a too weak argument, so unless there is a real flaw in the format used upstream, I will not bother them for a change. This formats works with quilt, so I do not understand why it would be difficult to get it work with the format ’3.0 (quilt)’ of dpkg. According to the current discussion, the problem is more political than technical. We already do not manage to agree internally on what is the best workflow. I can propose Upstream to adapt their habits to our habits, but this has to come with benefits that overcome the energy invested in the changes, and the fact that what is best for distributor A will not match what distributor B expects. Much saner in my opinion is to have a toolchain that is liberal in what it accepts. (Hence the proposition to accept upstream ‘zip’ archives). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539997: RFP: pohmelfs -- Parallel Optimized Host Message Exchange Layered File System client and server
Package: wnpp Severity: wishlist * Package name: pohmelfs Version : Upstream Author : Evgeniy Polyakov * URL or Web page : http://www.ioremap.net/projects/pohmelfs/ * License : GPL2 Description : Parallel Optimized Host Message Exchange Layered File System client and server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539784: closed by Simon McVittie (Re: Bug#539784: address lookup errors only in gnome-terminal)
Where do I file bug reports about my brain? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Charles Plessy writes: > Le Tue, Aug 04, 2009 at 09:51:26AM +0200, Paul Wise a écrit : > > Perhaps you could talk to upstream about switching to either using > > unified diffs for updates, tarballs for every release or a git/etc > > repository? > > For sure, Debian can suggest them git, Ubuntu can suggest them bzr, > Fedora can suggest them cvs, and Opensuze can suggest them svn. Fine. Whichever one of those they choose, it can consume and produce unified-diff-format patches. > And for the format of the patch, I do not know what to tell them apart > that unified diff is the preferred format of some Debian developers, That's quite a misrepresentation; it's far wider than just “some Debian developers” who prefer that format. > and that we like that others use the formats that we prefer. The point, rather, seems to be that unified-diff format is the de facto standard format for exchanging patch information. > I think that is a too weak argument, so unless there is a real flaw in > the format used upstream, I will not bother them for a change. The flaw is that patch information in any format other than unified-diff format is nowhere near as portable. > Much saner in my opinion is to have a toolchain that is liberal in > what it accepts. (Hence the proposition to accept upstream ‘zip’ > archives). This is in opposition to the ideal of having standard [0] formats for data interchange, and choosing them on the basis of what is already widely produced and accepted. [0] “standard” in this usage necessarily including “freely-implemented”, which doesn't disqualify the other options being discussed, but I put this footnote in the hope of forestalling useless discussions about proprietary formats. -- \ “I moved into an all-electric house. I forgot and left the | `\ porch light on all day. When I got home the front door wouldn't | _o__)open.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
