unsubscribe
Raphael Hertzog <[EMAIL PROTECTED]> wrote on 06/22/2005, 06:47:05 PM: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Format: 1.7 > Date: Wed, 22 Jun 2005 17:52:46 +0200 > Source: libdbd-pg-perl > Binary: libdbd-pg-perl > Architecture: source i386 > Version: 1.42-0sarge1 > Distribution: stable > Urgency: low > Maintainer: Raphael Hertzog > Changed-By: Raphael Hertzog > Description: > libdbd-pg-perl - a PostgreSQL interface for Perl 5 using DBI > Closes: 314421 > Changes: > libdbd-pg-perl (1.42-0sarge1) stable; urgency=low > . >* Simple recompile for sarge. Closes: #314421 >* This bug annoys enough users in my opinin to warrant an update > in stable. > Files: > 4249f8971f56b9e9fbae59731e69530f 734 perl optional > libdbd-pg-perl_1.42-0sarge1.dsc > 9defc6e0887f5e4d1207cc527271b41d 5142 perl optional > libdbd-pg-perl_1.42-0sarge1.diff.gz > fe5e807e6c76b3ed672cccb8621a7d34 115134 perl optional > libdbd-pg-perl_1.42-0sarge1_i386.deb > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFCuZNSvPbGD26BadIRAsuJAJ95fk7tmM54MDbPQn9eUWLXaE3j5QCfeeeZ > NBo61Hh97tPvUmUBc1q1yOk= > =01Mn > -END PGP SIGNATURE- > > > Accepted: > libdbd-pg-perl_1.42-0sarge1.diff.gz > to pool/main/libd/libdbd-pg-perl/libdbd-pg-perl_1.42-0sarge1.diff.gz > libdbd-pg-perl_1.42-0sarge1.dsc > to pool/main/libd/libdbd-pg-perl/libdbd-pg-perl_1.42-0sarge1.dsc > libdbd-pg-perl_1.42-0sarge1_i386.deb > to pool/main/libd/libdbd-pg-perl/libdbd-pg-perl_1.42-0sarge1_i386.deb > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
remove me from call wave
PLEASE REMOVE ME FROM CALL WAVE JAMES H. SCOTT, SR. 618 355 0976 PeoplePC Online A better way to Internet http://www.peoplepc.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
美國高科技生化公司徵才
美國高科技生化公司 徵才 尋求 .有國際事業觀念者 .肯學習 .略通英或他國語言佳 我們將提供您 1.國內外在職訓練 2.免費海外旅遊 3.良好升遷管道及值得的報酬 Enter Me!!
HP激光打印机专业维修，为您节省40%
上海天码，具8年HP激光打印机维修服务经验，通过大批量的采购，简化进货渠道，大幅度减低您的维修费用。 HP6L，接口板，450元；加热组件，420元；激光发生器。400元；分页器，200元（多纸一进） HP5000，接口板，1350；激光发生器，1300元；加热组件，1800元；分页器（三片），450元；搓纸轮，150元。 其他HP激光打印机配件应有尽有，欢迎来电：021-32270228，或光临网站：www.savemoney.com.cn(省钱网）
Bug#903590: general: REBOOT command shuts system off Pi3B+ without rebooting. Even kills the power, i.e. the red light on the Pi goes out
Package: general Severity: grave Tags: d-i Justification: renders package unusable Dear Maintainer, * What led up to the situation? Updated to the late June 2018 release of Rasbian from March 2018 release * What exactly did you do (or not do) that was effective (or ineffective)? Reboot. * What was the outcome of this action? Shutdown my Pi 3B+, and corrupted my USB Boot HDD * What outcome did you expect instead? normal re-boot -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 9.4 (stretch) Release:9.4 Codename: stretch Architecture: armv7l Kernel: Linux 4.14.52-v7+ (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_ZA.UTF-8), LANGUAGE=en_ZA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_ZA.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Font problem - Nimbus Sans L
I believe this problem could be considered a bug - or at least an error in the installation of Debian. I encountered it on Woody, and now have encountered the same problem on Sarge. Specifically, the standard fonts that are installed include Nimbus Sans L, and Nimbus Sans L Condensed. Nimbus Sans L is very similar to Helvetica or Arial and is important to have for interoperability with Windows machines. However, when characters are formatted Nimbus Sans L in Abiword and in OpenOffice, it is actually Nimbus Sans L Condensed that is displayed and printed. This means that there is no Arial/Helvetica equivalent font available to the user. On Woody, I deleted n019043l.pfb, n019044l.pfb, n019063l.pfb, n019064l.pfb from /usr/lib/X11/fonts/Type1. Then I ran type1inst in that directory, ran xset fp rehash, deleted XftCache. Atger rebooting, there were no more "Condensed" fonts and the real Nimbus Sans L was used in Abiword (I didn't have OpenOffice). On Sarge, the behaviour is stranger. I deleted the same files, which fixed the problem for Abiword but not OpenOffice. Then I restored the files. Still, Abiword used the correct Nimbus Sans L. I have spent a significant amount of time trying to understand the font system, and all that happens is that I follow symbolic links in circles. So perhaps someone more knowledgeable than I can identify the problem here. I suspect it has something to do with inappropriate font substitutions being specifed in the configuration that is set up by Debian Installer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Font problem - Nimbus Sans L
Josselin Mouette wrote: (Also note that Mr Dodds' mail server is on crack and refused mail from my SMTP for a mysterious reason; that's why you didn't receive my reply in private.) Thanks for pointing me at bug 243329, Josselin. Now I know that a) I am not alone; b) where to file this. And perhaps another user searching the debian lists for the same problem will benefit, so a reply to the newsgroup is be good thing. As for the mail server at aci.on.ca - they have a lot of anti-spam measures in effect. Probably your ISP is on their blacklist because another user at your ISP is infected with a bot which is spamming through your ISP's mailserver; or because your mailserver allows forwarding. In my email account at work (another ISP) I get about 200 spams per day. My personal account at aci.on.ca gets one or two. It's a mixed blessing because sometimes good emails do get bounced. On the whole I support aci.on.ca's efforts. The other ISP's just don't seem to care about spam. If more did, we wouldn't have a spam epidemic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#198104: ITP: positron -- A synchronization manager for the Neuros Audio Computer
Package: wnpp Version: unavailable; reported 2003-06-19 Severity: wishlist * Package name: positron Version : 1.0 Upstream Author : Stan Seibert <[EMAIL PROTECTED]> * URL : http://www.xiph.org/positron/ * License : BSD Description : A synchronization manager for the Neuros Audio Computer positron is the synchronization manager for the Neuros Audio Computer. It supports adding, removing, and syncing files to/from the Neuros device. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux babyjesus 2.4.20-ben8 #3 Sun Mar 16 10:47:59 MST 2003 ppc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Bug#463337: ITP: mod-atom -- Apache2 module for publishing and editing web resources
Package: wnpp Severity: wishlist Owner: Jack Bates <[EMAIL PROTECTED]> * Package name: mod-atom Upstream Author : Tim Bray <[EMAIL PROTECTED]> * URL : http://code.google.com/p/mod-atom/ * License : Apache Programming Lang: C Description : Apache2 module for publishing and editing web resources C language implementation of the Atom Publishing Protocol server function, implemented as an Apache module. Data storage is in the filesystem. Configuration is minimal. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465179: ITP: php-codesniffer -- tokenises PHP code and detects violations of a defined set of coding standards
Package: wnpp Severity: wishlist Owner: Jack Bates <[EMAIL PROTECTED]> * Package name: php-codesniffer * URL : http://pear.php.net/package/PHP_CodeSniffer/ * License : BSD Programming Lang: PHP Description : tokenises PHP code and detects violations of a defined set of coding standards PHP_CodeSniffer is a PHP5 script that tokenises and "sniffs" PHP code to detect violations of a defined set of coding standards. It is an essential development tool that ensures that your code remains clean and consistent. It can even help prevent some common semantic errors made by developers. http://cgi.sfu.ca/~jdbates/debian/pool/php-codesniffer/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Come join me on Learn Makeup Courses...
Learn Makeup Courses: Learn Makeup Courses and be Professional Makeup Artist at EI- Makeup School Jack Smith has invited you to join Learn Makeup Courses Watch my Makeup tips, blogs and video Check out Learn Makeup Courses: http://makeup-courses.ning.com/?xgi=gKx5nvR If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser About Learn Makeup Courses... EI School of Professional Makeup provides students with the opportunity to become skilled in all aspects of professional makeup Learn Makeup Courses includes: Blogs Photos Videos To control which emails you receive on the corner, or to opt-out, go to: http://makeup-courses.ning.com/?xgo=/KDuTG/iG6Lo/mk67pqedBEIX8yEyQLuhmwWy/cgk1IYybzGSeP/wg
cdbs: how to move file after install target?
I use cdbs to maintain the php-codesniffer package and have a very basic debian/rules: http://cgi.sfu.ca/~jdbates/tmp/debian/200809030/rules Unfortunately it installs a script at /usr/bin/scrips/phpcs-svn-pre-commit, instead of /usr/share/subversion/hook-scripts/phpcs So I tried inserting my own command to move /usr/bin/scrips/phpcs-svn-pre-commit to /usr/share/subversion/hook-scripts/phpcs after the debian/rules install target: install:: mv -i $(DEB_DESTDIR)/usr/bin/scripts/phpcs-svn-pre-commit $(DEB_DESTDIR)/usr/share/subversion/hook-scripts/phpcs - but it has no effect: The script is still installed at /usr/bin/scrips/phpcs-svn-pre-commit What is the "correct" way to move /usr/bin/scrips/phpcs-svn-pre-commit to /usr/share/subversion/hook-scripts/phpcs using cdbs? Thanks, Jack signature.asc Description: This is a digitally signed message part
Bug#511522: general: Man pages should say what package a program belongs to
Package: general Severity: wishlist If some program belongs to a package which does not have the same name as the program, the man page for that command should say which package the program is part of. This is not the case in, for instance, coreutils or util-linux. This information is needed, even for packages that are always installed as part of the base distribution, since to get source code for a program in coreutils one needs to know that it is part of that package. Jack -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18jack1 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511522: general: Man pages should say what package a program belongs to
As several people have pointed out, there is already a good way (that I was not aware of) to find out this information, therefore I agree that this bug should be closed. Jack -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#434132: ITP: php-sasl -- Cyrus SASL extension for PHP
Package: wnpp Severity: wishlist Owner: Jack Bates <[EMAIL PROTECTED]> * Package name: php-sasl Version : 0.1.0 Upstream Author : Jon Parise <[EMAIL PROTECTED]> * URL : http://pecl.php.net/package/sasl * License : PHP Programming Lang: PHP Description : Cyrus SASL extension for PHP SASL is the Simple Authentication and Security Layer (as defined by RFC ). It provides a system for adding plugable authenticating support to connection-based protocols. The SASL Extension for PHP makes the Cyrus SASL library functions available to PHP. It aims to provide a 1-to-1 wrapper around the SASL library to provide the greatest amount of implementation flexibility. To that end, it is possible to build both a client-side and server-side SASL implementation entirely in PHP. http://cgi.sfu.ca/~jdbates/debian/pool/php-sasl/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"dh" and dh_installxmlcatalogs
What's the preferred way to get "dh" to run dh_installxmlcatalogs? -- 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/1278985628.6812.33.ca...@selene
Re: GCC 3.2 transition
Steve, There shouldn't be huge issues in the gcc 2.95.4 to gcc 3.2 transition. Currently the only two major ones I know if are... 1) Rebuilding glibc with gcc 3.2 *may* require an arch to add a libgcc-compat section to provide libgcc symbols, now .hidden in gcc 3.2's libgcc_s.so, with local copies that are resolvable at runtime. Currently ia64 and ppc has such code available. This is to prevent breaking old binaries when a gcc 3.2 built glibc is installed. 2) Using something like a gcc 2.95.4 built jdk javaplugin (written in c++) with a gcc 3.2 built mozilla won't currently work although workarounds are said to exist. Since Blackdown JDK 1.4 development is underway a gcc 3.2 build JDK won't be far off. Jack
gnome 2.0 breakage
Is anyone else seeing major breakage on Gnome2 tonight? On current debian ppc sid, I found after rebooting that while gdm2 still worked and I could login that Nautilus2 is very broken and reports that variety of directory as being invalid with alerts at startup. Also the Applications menus are empty. I grabbed everything built tonight on incoming.debian.org but that didn't help. Jack
Re: gnome 2.0 breakage
It would appear the problem may be with the gnome-vfs2 currently built on voltaire. I had built my own copy waiting for it to come off of voltaire earlier in the week. With that locally built copy of gnome-vfs2 installed, nautilus2 works fine. Also, if I rebuild current gnome-vfs2 against current debian sid locally that copy of gnome-vfs2 works fine. For some reason the same package version off of voltaire causes nautilus2 to flake out and not recognize paths as being valid. Jack
xmms needs rebuild in sid
I believe the libpng2->libpng3 migration in sid may have
broken xmms. While I can run xmms somewhat, I can't get the
playlist to display. If strace a run I see...
rt_sigprocmask(SIG_SETMASK, NULL, [32], 8) = 0
rt_sigsuspend([]
--- SIGRT_0 (Real-time signal 0) ---
<... rt_sigsuspend resumed> ) = 32
shmat(0, 0, 0x6ptrace: umoven: Input/output error
)= ?
which isn't clearly associated with a particular module loading.
Jack
Re: xmms needs rebuild in sid
Eduard,
Actually, Michel Danzer says he thinks in may be related to
100 dpi fonts. In any case, does xmms display its playlist in
sid for you? Here I get nothing although xmms doesn't crash.
I just rebuilt it against current sid and that didn't help.
Do we know when this playlist failure bug arose?
Jack
Re: xmms needs rebuild in sid
Josip,
Changing the font didn't help, but deleting my .xmms
directory in my account seemed to have cured it. Odd.
Jack
Re: xmms needs rebuild in sid
Josip, Unless it was just random corruption of the .xmms in which case it would be impossible to determine what caused that. I actually set the font for the playlist to the same font as the main display (which is okay) and that didn't work. Unless someone else sees this today I would bet on random corruption of prefs. Jack
proposal for the gcc 3.2 transition
Hello,
I would like to make a proposal for one aspect of the
gcc 3.2 migration in sid. A critical part of this transition
will be the discovery of how many arches still require creation
of libgcc-compat code in glibc. Currently we are told by Jakub
Jelinek that i386 is fine. Franz Sirl has just finished ppc in
both branches of the glibc cvs. The ia64 arch has a version available
in the glibc trunk that could be backported. Jakub also said alpha
and sparc32 should be fine (not sure if that needs backported from
the trunk though into glibc-2-2-branch). The rest will have to be
handled by the arch maintainers here.
After talking to Daniel Stone, I found out that the kde 3.0.3
introduction to sid was being delayed until the gcc 3.2 switchover
has occurred. Since the scheme above will greatly delay kde 3.0.3
being added to sid, I would like to propose the following. Assuming
each arch passes their gcc 3.2 testsuite and the most current binutils
is mandated for use with gcc 3.2, we should be able to short-circuit
the process as follows.
1) adjust the debian/control in glibc to build all arches at their
current gcc < 3.1 regardless if gcc 3.2 is installed.
2) switch the gcc-default to gcc 3.2
3) as each arch can demonstrate that their libgcc-compat issues are
resolved, their arch would be switched over in the glibc debian/control
file to build glibc with gcc 3.2.
This approach has the advantages of making the transition to
gcc 3.2 go much faster while removing the need for each arch
to immediately resolve their issues with libgcc-compat.
All comments and suggestions are welcome.
Jack
re: First experience with gcc-3.2 recompiles
Gerhard,
I would be cautious about installing a gcc-3.2-built glibc
unless you first purge your system of all binaries that
were built with gcc < 3.1. Jakub Jelinek said he was uncertain
if s390/s390x was an arch that would require a libgcc-compat
be added to glibc. If a libgcc-compat is required you will
see certain old binaries fail under the new gcc 3.2 built
glibc. According to Jakub you can see if this will be the
case by doing the following...
>Basically, you take the list of libgcc.a (formerly) exported symbols
>and scan all binaries/libraries if they have undefined references to any
>of these symbols (as libc.so exports those on ia32/sparc and a few
>others only, they will not be exported on other arches from libc, thus
>are resolved to some unintentionally exported symbol in some other library
>which is going away after rebuild with 3.2).
>
>Jakub
...on a machine built entirely with a gcc < 3.1. If you do
find that binaries are showing undefined references to
any of the libgcc symbols (which are now .hidden in gcc >= 3.1)
you need to construct a sysdeps/s390/libgcc-compat.c or .S
that makes these libgcc symbols available for run-time
resolution (but not exporting them for linking).
Hope that helps.
Jack
libwww-perl
Has anyone had any luck building libwww-perl against perl 5.80 yet? Jack
consider regression of perl!
Hello,
Considering how unstable perl 5.80 currently is, wouldn't it be
wise to regress sid back to perl 5.60 and move 5.80 into experimental
instead? So far this upgrade has done major damage to dpkg by breaking
install-info making any additional glibc builds in sid impossible.
I have also found similar bugreports in bugzilla of perl segfaulting
in certain circumstances. With debian's heavy reliance on perl for its
system maintenance scripts this current move to 5.80 seems far too
destablizing for sid. Especially as it will wreak havoc with any move
to gcc 3.2 builds.
Jack
Re: consider regression of perl!
Adam,
Well it will be one thing if the debian perl maintainers
are going to actively track down and fix these critical perl
bugs on their own. However if we are going to passively wait
for fixes from upstream, perhaps perl 5.80 will introduce
a bit too much breakage for right now. I mean dpkg IS an
essential package. You can't break that willy nilly. Also,
correct me if I'm wrong but doesn't even gentoo linux consider
perl 5.80 too twitchy to include?
Jack
~
Re: consider regression of perl!
Dan, Then you might take a stab at debugging the testcase from the bugzilla report... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=69254 ...since it sounds similar. If it isn't then we have another bug to fix. Jack
why is /usr/sbin/install-info a perl script!!!
I am trying to get the glibc debian cvs for 2.2.92 to package (it builds and passes make check fine on debian ppc sid with the new gcc 3.2.1pre). However the buggy perl 5.80 in sid has broken install-info. I looked at a Yellow Dog Linux machine and noticed, however, that they had a texinfo 4.2 source package that builds an info package with a binary /usr/sbin/install-info instead of the perl version we have. Why is that and why don't we just NMU texinfo in sid to start building a binary install-info until perl 5.80's regex stops leaking memory like a sieve? Jack
install-info and LSB
Has there ever been any discussion of the binary /usr/sbin/install-info in terms of the Linux Standard Base? I ask because dpkg is providing a perl based version of this utility whereas all other distros appear to be using binary only version. This came up because the regex in perl 5.80 is buggy and breaks the perl install-info for building glibc now. As a workaround I rebuilt texinfo-4.2 with all of the redhat install-info related patches and substituted this binary only version for the one dpkg installs. While this version is sufficient for building the packages there does appear to be some incompatibilities related to installing glibc-doc with this version of install-info. I am wondering if we aren't violating the spirit if not the letter of LSB by using a non-standard version of install-info. Wouldn't it be better to move install-info out of dpkg, add any required additional functionality to the texinfo version of install-info and push those changes upstream to the texinfo maintainers? Since install-info is being called at both the Makefile level in builds as well as at the packager level (eg rpm or dpkg) it seems that we would be much better off if the install-info used by debian was uniform with what everyone else is using (be it a perl or binary version). Any comments? Jack
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
> > I just made an important change to PTS. Since the PTS email adresses > > have been available on the web, they start collecting a significant > > quantity of spam. As a first measure to avoid them I decided that any > > email sent directly to the PTS should be auto-approved. Auto-approval is > > easy, you just have to add an "X-PTS-Approved" header with a non-empty > > value. If you don't do that, you get a bounce (and the bounce explains > > you how to auto-approve your message). > > > why not use this trick also for posts to debian mailing lists? Is there some reason why TMDA isn't being used? We've used this at Xiph.org for the mailing lists for quite some time now, and I don't think a single spam has gotten through yet. It's somewhat similar what what you discuss above, but a lot more user friendly. jack.
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
> > Is there some reason why TMDA isn't being used? We've used this at > > Xiph.org for the mailing lists for quite some time now, and I don't > > think a single spam has gotten through yet. > > I don't know exactly. > > It's because most of the Debian lists have always been 100% open... and > requiring a confirmation would close the list for complete newbies who > can't understand the principle. We haven't seen this problem on the vorbis lists. We do occasionally get people who quote the entire reply from TMDA when authorizing themselves, but even so, it's better than a lot of spam and certainly better than closing the lists. jack.
evolution menu icons broken
Does gdk-imlib1 need to be rebuilt? It seems since the new png changes went into debian ppc sid, the menu icons are broken in evolution. Jack
libstdc++-pre6 vs build machines
I was wondering if any effort was being made to hold the build machines from installing the broken libstdc++-5_3.3-0pre6 packages. If there are missing symbols in those new libstdc++ libs I am wondering what the impact will be for any c++ code built against pre6 when the symbols return in the next fixed libstdc++ build. Jack
mozilla 1.3.1-1 segfaults
Are any arches other than debian ppc sid seeing the new mozilla 1.3.1-1 release segfault? This new version also causes galeon to segfault as well. Regressing back to 1.3-5 fixes both. Jack
openoffice in debian?
Hello,
What exactly is the situation with regard to openoffice going
into debian sid? I ask because OpenOffice 641C seems quite robust
now (I've been doing some statistical data analysis in it this
weekend and it works as well as Excel). The only current problem I
see in it is that the new format files are saved down as compressed
with gzip although the extensions don't indicate that which throws
gnome-vfs for a loop. Hopefully OO will fix that some by changing
their headers so that the files don't appear to be created by gzip.
Anyway...it would be great to get it into debian. The current version
loads in 7 secs now with combreloc. Quite nice.
Jack
Re: WARNING: Jack Howarth is an agent of destruction
This is absurd. Debian policy explicitly states that you should not create a shared lib using objects not created with -fPIC (which is exactly what libsdl-image does when it asks sdl-config what to use for static_x_extension_libs). This problem is identical to one just resolved in evolution... evolution (1.0-2) unstable; urgency=low * Applied fPIC patch of Bug#124141 (closes: #124141) * Applied correcthelosmtp.diff of Bug#123922 (closes: #123922) * debian/control: - remove beta notice from Description. ...where libcamellocal.so was being built using a static lib libebex built without using -fPIC. This was WRONG! One of the problems with this Debian policy violation is that it is not always reproducible as a bug on other folks machines. However feel free to ask on debian-powerpc and the will confirm that it is in fact wrong to use non-fPIC static libs in a shared lib on ppc and in fact any arch under Debian. Branden seems to have gone off the deep end here. All I am trying to do is eliminate a serious policy violation in libsdl. Either sdl-config is modified to be bright enough to return a different answer for static_x_extension_libs... static_x_extension_libs="-lXxf86dga_pic -lXxf86vm_pic -lXv_pic" if a shared lib is being built or sdl-config has to always assume a shared lib might be built and do the same. Again, I'm just reporting a real bug in these packages that impacts Debian ppc sid (and probably other arches). Don't flame me just because you don't want to hear a real problem. Jack ps I can't be held for treason in the UK. We bailed out of that joint almost 100 years ago.
why does xlibs-pic exist?
After a number of rants from Branden I rather confused now
as to why xlibs-pic exists at all. As best as I can tell through
the froth, Branden is saying that absolutely no static libs
should be linked into a shared lib. The conventional wisdom
on debian-powerpc seems to be that this should be extended a tad
to allow for programs that will need more work upstream. So that it
should be...
absolutely no static libs, that have not been built with -fPIC/-fpic,
will be linked into a shared lib.
The only statement I can find in the debian policy simply states...
All libraries must have a shared version in the lib* package and a static
version in the lib*-dev package. The shared version must be compiled with
-fPIC, and the static version must not be. In other words, each *.c file will
need to be compiled twice.
This seems to be different from what I recall from only a few weeks ago
when it seemed to only say shared libs must be built with -fPIC and nothing
about static not being built that way.
So what is really correct? It would seem that xlibs-pic seems to only
encourage breaking the current new stricter policy on shared libs not
containing static libs. I am very unclear as to what is the approved
fix then. If something like libsdl-image should not link any static lib
(even built with -fPIC) into its shared libs, then what use is xlibs-pic
at all? If we are going to enforce this darconian rule then xlibs-pic
should be depreciated out of xfree86 since it can't actually be used
without violating current debian policy. Nice Catch22.
Jack
ps I didn't realize some parts of England were only recently, and partially,
civilized (grin).
libsdl-image1.2
Ok.
I see Branden's NMU declaration for changing the use of the static
libs in SDL related packages. Still when I read the change log for
libsdl-image1.2 I find...
sdl-image1.2 (1.2.1-1) unstable; urgency=low
* new upstream version
* tried to add Brandens fixes again in Makefile.am, aclocal.m4 and
configure.in
* re-ran libtoolize --force --copy; aclocal; automake --foreign; autoconf
-- Christian T. Steigies <[EMAIL PROTECTED]> Tue, 18 Dec 2001 21:21:39 -0500
I assume this is an implementation of Branden's suggestions from...
http://lists.debian.org/debian-devel/2001/debian-devel-200110/msg00353.html
If it is...it isn't working on Debian ppc sid. We still get the static
versions of the libs.
Jack
sdl-image1.2 fixed
Branden and Christian, Sorry that I misunderstood that the fix for this was already in place in the current libsdl-image1.2 package. However on debian ppc sid it doesn't appear to work unless I make the following change to the rules file. I have to put a call to autoconf before the ./configure occurs. Otherwise the build using apt-get source sdl-image1.2 cd sdl-image1.2-1.2.1 dpkg-buildpackage -rfakeroot doesn't generate a usable shared lib. I find that armagetron still segfaults with... ./armagetron: error while loading shared libraries: /usr/lib/libSDL_image-1.2.so.0: R_PPC_REL24 relocation at 0x0ffc48b4 for symbol `LoadBMP_RW' out of range if I use the currently built versions of libsdl-image1.2 or rebuild them locally. Again if I make that one minor line change to the rules, adding a call to autoconf before configure, this appears to resolve the problems with armagetron. At least on my machine. What I did notice is that unless I invoke autoconf...all I ever get for 'grep library-libs *' is... aclocal.m4:SDL_LIBS_FOR_LIBS=`$SDL_CONFIG $sdlconf_args --library-libs` even after building sdl-image1.2 with 'dpkg-buildpackage -rfakeroot' however only if I do autoconf does the change in aclocal.m4 get transmitted to configure. Sorry again about the winding path to finding this fix but at least it is a trivial one. Jack
one last comment
Branden and Christian, I guess I don't follow the finer nuance here but these are the different compile lines generated from libtool without doing an autoconf before configure... gcc -shared IMG.lo IMG_bmp.lo IMG_gif.lo IMG_jpg.lo IMG_lbm.lo IMG_pcx.lo IMG_png.lo IMG_pnm.lo IMG_tga.lo IMG_tif.lo IMG_xcf.lo IMG_xpm.lo -L/usr/lib /usr/lib/libSDL.so -lpthread -L/usr/X11R6/lib -lXxf86dga -lXxf86vm -lXv /usr/lib/libjpeg.so -lpng -lz -Wl,-soname -Wl,libSDL_image-1.2.so.0 -o .libs/libSDL_image-1.2.so.0.1.0 ...and with doing an autoconf first before configure in libsdl-image1.2... gcc -shared IMG.lo IMG_bmp.lo IMG_gif.lo IMG_jpg.lo IMG_lbm.lo IMG_pcx.lo IMG_png.lo IMG_pnm.lo IMG_tga.lo IMG_tif.lo IMG_xcf.lo IMG_xpm.lo -L/usr/lib -L/usr/X11R6/lib -lXxf86dga -lXxf86vm -lXv /usr/lib/libjpeg.so -lpng -lz /usr/lib/libSDL.so -lpthread -Wl,-soname -Wl,libSDL_image-1.2.so.0 -o .libs/libSDL_image-1.2.so.0.1.0 Does this look correct now? I am surprised as this looks to be just a simple reordering of the linkage rather than anything that invokes the xlibs-pic versions of -lXxf86dga -lXxf86vm -lXv explicitly. Guess I'll need to reread the mailing list on that issue again. In any case, the second link command generates a good copy of libSDL_image-1.2.so.0.1.0. Jack
re vlc
Branden, Nevermind. I just heard back from Samuel Hocevar and he is aware of the problem and will fix it in the next build. I got thrown for a loop because there was a crashing bug not fixed in vlc until 0.2.92-7 (which isn't in sid ppc yet) and local builds were failing (because of xlibs-pics being installed). These two unrelated problems confused the situation for me. Jack
vlc, sdl and xlibs-pic conflict
Branden,
I guess I'm just a tad thick here but I don't understand
the rational for the following conflict. My debian ppc sid
machine is current for all the packages in sid and has xlibs-pic
installed as well. I discovered that when I tried to do...
apt-get -b source vlc
for the latest vlc-0.2.92-7 package to build locally that I got
a failure in the link. The problem disappears when I deinstall
xlibs-pic and then try rebuilding vlc again. The difference seems
to be that when xlibs-pic is installed I get a build with...
gcc -fPIC -o ../sdl.so sdl.o vout_sdl.o aout_sdl.o -shared -L/usr/lib
-lSDL -lpthread -L/usr/X11R6/lib -lXxf86dga_pic -lXxf86vm_pic -lXv_pic
which causes a link failure on vlc later on with unresolved symbols
from those static pic libs whereas when xlibs-pic is deinstalled I get...
gcc -fPIC -o ../sdl.so sdl.o vout_sdl.o aout_sdl.o -shared -L/usr/lib
-lSDL -lpthread -L/usr/X11R6/lib
and I get no link failures on vlc. I assume this is a flaw in vlc where
the static pic libs are being incorrectly linked into a shared lib
instead of the final program itself. I have passed this info onto the
vlc maintainer but since you did the sdl NMU and I assume this link
command is created using sdl-config, I thought you should be in the loop.
Perhaps xlibs-pic should be installed on all the build machines when
programs that link to libsdl1.2 are built so we can tickle this bug
and identity all the programs that need to be fixed. Call me silly but
it seems to me a program shouldn't have a build failure just because
xlibs-pic is installed.
Jack
ps No more postings to announcements please (grin).
gnumeric and guppi in sid
Has anyone managed to get guppi to work in current sid? I have yet to have any success. Before today guppi would silently fail whereas today I get a crash in guppi-gnumeric. I am trying the following... 1) run gnumeric 2) enter two columns of three rows of numbers (1,2,3 and 2,4,6) 3) select these 6 cells 4) click on graph icon in the gnumeric tool bar I am just wondering if guppi has every worked properly in sid. Jack
Re: gnumeric and guppi in sid
Well, this is on ppc sid. I'll try to find someone else
on ppc sid to check this. Oh I did file a bug report because
guppi hasn't been working for me for quite some time. This
is just the first time it actually showed a support program
was segfaulting.
Jack
xfree86 unbuildable on ppc
Hello, Could someone explain to me the point of releasing Xfree86 4.1.0-15 as is when clearly patch #065 was going to break builds on most non-intel arches? * patch #065: raped again by Herbert Xu and Ben Collins; you're not "supposed to" Build-Depend on a kernel package and at the same time the glibc versions of the kernel headers exclude SiS DRM ioctls that we need #defined to compile properly. Kludge these #defines into sis_alloc.c because, of course, it's XFree86's job to know what the uderlying kernel's ioctl numbers are. While we're at it, why don't we just stop using standardized constants in our C programs altogether? :-P Oh, by the way, these are the ioctl's for i386 Linux. Talk to Herbert and Ben if this sucks for you. (Closes: #139511) I simply don't see the logic at play here considering we're supposed to be closing in on woody's release. Jack Howarth ps See bug report 141114 for details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86 unbuildable on ppc
Opps...that bug report associated with this problem is 141116 not 141114...sorry. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree 4.2.0 - again
I agree with Chris it that is insulting for folks to be degrading the other arch's supported by Debian. What is strange is that someone would feel strongly enough about having a choice in operating systems to run Debian Linux yet think that a i386-only world is just fine. The two monopolies go hand in hand (Intel and Microsoft). Lastly the presence of non-i386 architectures has helped even the i386 folks by forcing Linux and gnu to be more rigorous in programming. The just because it runs on i386 won't cut it with multiple arches and enforces the requirement of clean coding that is processor independent. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#529761: ITP: libfake437 -- A simple cross-platform ANSI-art library
Package: wnpp Severity: wishlist Owner: Jack Kelly Package name: libfake437 Version : 0.4 Upstream Author : Jack Kelly URL : http://libfake437.googlecode.com License : LGPL 3+; Manual is CC-BY-SA-3.0 Programming Lang: C and C++ Description : A simple cross-platform ANSI-art library Libfake437 is a cross-platform library for rendering code page 437 'graphics' (think 'ANSI art', ZZT, Dwarf Fortress or Kingdom of Kroz). The library is written in C and uses SDL for drawing. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: bash readline
On 31 January 2013 21:24, Michael Stapelberg wrote: >> but on ubu^H^H^Hdebian, rlwrap uses the vanilla readline and it's >> really annoying that i can't get the same line editing features with >> rlwrap (and, i expect, readline). > I can confirm that. I suspect libreadline differs from bash’s readline. for the benefit of people finding this thread and looking for more vi-mode features in rlwrap, look at tecla and its 'enhance' which is a replacement for rlwrap. it has the vi key bindings i want. or look at the GNU readline links in the wikipedia page: http://en.wikipedia.org/wiki/GNU_readline#External_links ta, jack. -- 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/cajvhtnzdeckpoo2kpp6ob91e8qa3pnmgun4tfst_ky9kycs...@mail.gmail.com
Re: Fwd: Re: Open-FCoE for Wheezy
There is an effort to develop a software target along with the open-FCoE stack. This would help reduce some of the cost by removing the need for target and possible a switch. (back to back configuration: FCoE initiator to software target) You would still need a 10Gb adapter on both ends. There is already some support for this in opensuse, fedora and ubuntu. Thanks, On 12/10/2011 03:59 AM, Ritesh Raj Sarraf wrote: > Including debian-devel.. > > > Original Message > Subject: Re: Open-FCoE for Wheezy > Date: Fri, 09 Dec 2011 18:31:01 +0530 > From: Ritesh Raj Sarraf > Reply-To: r...@debian.org > Organization: RESEARCHUT > To: debian-rele...@lists.debian.org > > > > Any suggestions? > > It is a new and expensive technology and hasn't seen much adoption yet. > > > On 12/02/2011 01:14 AM, Ritesh Raj Sarraf wrote: >> Hello Release Team, >> >> Please provide me some Release readiness assistance for Open-FCoE's >> inclusion for Wheezy/Sid >> >> Open-FCoE [1], is a newer SAN technology to carry Fiber Channel traffic >> over Ethernet. The ethernet is generalized in the definition but in >> reality, a newer 10 GiB DCB Ethernet card is required for FCoE >> capabilities. Also to mention the refreshes required on the switch >> infrastructure. >> >> My initial hope was to get some access to FCoE hardware setup that I >> could spare for Debian. Unfortunately, for multiple reasons that didn't >> happen and I don't see having access to the hardware any time soon. >> >> Open-FCoE stack is currently in experimental. I have had no [bug] >> reports yet. Also the popcon stats is very low. >> >> >> The assistance I'm seeking from you is about its release readiness for >> Wheezy/Sid. Should I get these packages uploaded to Wheezy/Sid? There >> might not be many packaging errors, but with no real user testing in a >> production environment, I have no idea how the stack will behave. >> >> >> Should I go ahead with the inclusion of Open-FCoE into the Debian archive? >> >> >> [1] http://www.open-fcoe.org >> > > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs > Debian - The Universal Operating System > > > > -- Jack Morgan signature.asc Description: OpenPGP digital signature
bash readline
hi dd, i really like the readline in bash - it seems bash is "vi complete" in vi mode. now, i haven't looked closely, but i think the good vi mode is a patch on (bash?) readline in debian? in centos, i can't "df;" and delete up to next semicolon. but on ubu^H^H^Hdebian, rlwrap uses the vanilla readline and it's really annoying that i can't get the same line editing features with rlwrap (and, i expect, readline). what are my options? patch readline? ta, jack. -- 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/cajvhtnyg7qrna_yj6b5mmpddtsb5nar8zw+gea7wzcobeah...@mail.gmail.com
Re: Bug
I've noticed the same issue on a number of my systems after an update a few weeks ago. System shutdown or reboot via desktop menu does not work. Shutdown via commandline does. It's occurred on laptops, desktops and Virtual machines (all running Gnome 3.x).
Bug#642703: general: Scan lines appear in drop-down menus. LibreOffice also shows artifacts when starting. Might be something to do with the version of fglrx.
Package: general Severity: normal Accessing drop-down menus in LibreOffice shows scan lines. Starting LibreOffice shows artifacts on-screen. Then loads OK * What was the outcome of this action? * What outcome did you expect instead? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110924184050.2955.79055.report...@puppypc.lan
Re: libre version of iceweasel
On Tue, 9 Jun 2015, Luke Kenneth Casson Leighton wrote: open question: is there a perceived need to dig into the source code of firefox and, just as was done with google-chrome to create chromium-browser, permanently patch out certain "features"? There is GNU IceCat <http://www.gnu.org/software/gnuzilla/>, although I don't think it's packaged for Debian. Best, Jack -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1506092144150.6...@bog.hcoop.net
Re: Mass bug filing about non free lena image.
On Wed, 12 Aug 2015, Jakub Wilk wrote: Has anybody asked the copyright holders to release the image under a free license? Or is everybody assuming that they won't? Even if the image were free it is still disparaging to women. From the lintian message [0]: "Moreover, Lenna photo has been pointed to as an example of sexism in the sciences, reinforcing gender stereotypes." Best, Jack [0] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html
Bug#857113: ITP: httplab -- An interactive web server
Package: wnpp Severity: wishlist Owner: Jack Henschel X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: httplab Version : 0.1.0 Upstream Author : Gustavo Chaín URL : https://github.com/gchaincl/httplab License : Expat Programming Lang: Go Description : An interactive web server HTTPLab lets you inspect HTTP requests and forge responses via an intuitive console user interface. . asciicast: https://asciinema.org/a/c613qjyikodunp72ox54irn2j Packaging will be at https://anonscm.debian.org/cgit/pkg-go/packages/httplab.git/ signature.asc Description: PGP signature
Bug#1098523: ITP: appanvil -- graphical user interface for AppArmor
Package: wnpp Severity: wishlist Owner: Jack Ullery X-Debbugs-Cc: debian-devel@lists.debian.org, jackull...@proton.me * Package name: appanvil Version : 1.0.0 Upstream Contact: Jack Ullery * URL : https://github.com/jack-ullery/AppAnvil * License : GPL-3.0 Programming Lang: C++ Description : Graphical user interface for AppArmor AppAnvil provides an intuitive graphical interface for monitoring, editing, deploying, and configuring AppArmor. AppArmor is a Linux kernel extension, installed by default on Debian, that supplements the normal access control system. It can restrict specific processes from accessing files and other system resources. When properly configured, it can protect the system from internal or external threats. By restricting vulnerable processes, AppArmor mitigates the damage security vulnerabilities can cause. By default, AppArmor is not easy to configure, running silently in the background. Currently, it is only accessible through the command-line, and requires some specialized knowledge to configure. The AppAnvil project aims to create a graphical interface for monitoring and configuring AppArmor. In particular, we want it to be easy to monitor and deploy AppArmor application profiles, change a profile’s permissions, and to parse system logs. I am a newcomer to the Debian organization and will eventually require a sponser.
