Special offer on HQ Sites
Hi... I have HQ web sites.. All my sites have unique IPs address DA30+ PA 45+ Low OBL unique content Google indexed USA hosted. If you are looking for blog post blogroll links please let me know , I will offer you very competitive rates and with quality work. Looking forward to your positive response. Thanks.
Cross-directory hard links in Debian packages
Hi,
The tar file format supports hard links. Thus technically Debian
packages can contain hard links. A significant number of packages
including key packages such as bzip2, gzip, and ifupdown use this
technique. While same-directory hard links are an established practise,
the same is not so true for cross-directory hard links.
A good reason to use hard links is to save space. There are a number of
packages that ship the same content in multiple locations. The
alternative, soft links, has the downside of consuming inodes. When a
package ships very many duplicate small files, the savings for using
soft links are small compared to the savings achievable with hard links.
Also it is often not clear which of the copies is to be considered the
"canonical location".
The policy has an own stance on hard links in binary packages:
* 10.7.3 conffiles must not be hard links
* 12.1 manual page directories should not contain hard links
(without giving a rationale for this)
Lintian interprets policy 10.7.3 to also cover cross-directory hard
links (package-contains-hardlink):
| The package contains a hardlink in /etc or across different directories. This
| might not work at all if directories are on different filesystems (which can
| happen anytime as the system administrator sees fit), certain filesystems such
| as AFS don't even support cross-directory hardlinks at all.
Clearly, packages must not use hard links across usual mount locations
such as /usr. Unpacking a package with a hard link across different
filesystems simply fails with an error from tar.
How many people really use AFS for storing their system? Are there other
filesystems with a similar restriction? Is this aspect practically
relevant?
I propose to explicitly permit packages to use cross-directory hard
links within package-owned directories such as
/usr/{lib,share,share/doc}/$package.
About half of the packages flagged by lintian
http://lintian.debian.org/tags/package-contains-hardlink.html
use cross-directory hard links in this way.
Possible actions:
* Update the lintian check to exempt a few locations from the check.
* Update the policy to clarify which kinds of cross-directory hard
links are permitted. This is mostly a matter of documenting
established practise and the number of violations will be low in any
outcome.
Helmut
--
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/20131113091917.ga5...@alf.mars
Re: Cross-directory hard links in Debian packages
On Wed, Nov 13, 2013 at 10:19:17AM +0100, Helmut Grohne wrote: > While same-directory hard links are an established practise, > the same is not so true for cross-directory hard links. > > A good reason to use hard links is to save space. There are a number of > packages that ship the same content in multiple locations. The > alternative, soft links, has the downside of consuming inodes. When a > package ships very many duplicate small files, the savings for using > soft links are small compared to the savings achievable with hard links. So you save a small number of inodes, and get problems if the filesystem's layout is unconventional. Such savings don't seem to be worth the trouble to me. > Clearly, packages must not use hard links across usual mount locations > such as /usr. Unpacking a package with a hard link across different > filesystems simply fails with an error from tar. You don't know what directory resides on what filesystem. While splitting up /usr tends to be trouble, it is not unusual. For example Maemo has: /opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind,rbind) /opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind,rbind) /opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind,rbind) /opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind (bind,rbind) /opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind,rbind) So I'd keep this requirement as is. -- A tit a day keeps the vet away. -- 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/2013111327.ga24...@angband.pl
Kernel ABI Tracker
Hi all, There is a new tool available for Linux maintainers: Kernel ABI Tracker (http://upstream-tracker.org/kernel/). This tool looks for new releases of the Linux kernel, builds them and tracks API/ABI changes using a set of basic tools: ABI Dumper and ABI Compliance Checker. The tool is intended for Linux maintainers and developers of device drivers/kernel modules who are interested in ensuring backward compatibility of the Linux kernel interfaces. More info: http://wiki.rosalab.com/en/index.php/Blog:ROSA_Planet/Linux_Kernel_ABI_Tracker -- Andrey Ponomarenko, ROSA Lab. -- 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/52836963.6070...@rosalab.ru
Re: jessie release goal: verbose build logs
Le 14/06/2013 15:19, Timo Juhani Lindfors a écrit : >> This doesn't really help when trying to diagnose things, and even for >> successful >> builds it's valuable to have the complete build log, including the parts how >> the >> upstream build system is called from the Debian packaging. > > This is a useful goal. However, since fixing many different source > packages is a lot of work I recently explored some alternative > approaches. For example, with systemtap we can simply log all execve() > invocations complete with timing information and end up with fully > structured build logs. > > Here's example output from the proof of concept from a few years ago: > > http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build How do you do that exactly? Cheers, -- Stéphane -- 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/52837b52.4030...@debian.org
Bug#729491: ITP: libpoly2tri -- Lightweight triangulation library for simple polygons.
Package: wnpp Severity: wishlist Owner: Bryan Conrad Package name: libpoly2tri Version : 0.3.3 Upstream Author : Mason Green URL : http://code.google.com/p/poly2tri/ License : BSD Programming Lang: C++ Description : Lightweight triangulation library for simple polygons. Lightweight library for triangulating simple polygons. Supports polygons with holes, given that the polygons and holes are simple (in the formal sense) and not self-intersecting. -- 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/20131113143720.16084.2558.reportbug@debian
wxwidgets 3.0
[A Cc on list replies would be appreciated.] A few days ago wxwidgets 3.0.0 was officially released. I've already uploaded a package of it aimed at unstable, which is currently in NEW. Meanwhile you can download source and amd64 binaries from here: http://survex.com/~olly/wx3-debs/ My hope is that we can remove wxwidgets2.8 before the jessie freeze by either migrating packages to use 3.0, or removing them from Debian (during the wx 2.6 to 2.8 transition, I noticed a number of packages which appeared to have no maintainer either upstream or in Debian - for any where that's still the case, I think removal should be seriously considered). I'll be at the mini-debcamp in Cambridge, UK at the end of this week (14th and 15th November) and plan to make a start checking packages with the new release. I'd welcome local and/or remote assistance. I'll track progress here: https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0 Some important notes: * The wxwidgets2.8 source package was actually based on wxPython (which includes an embedded copy of the C++ wxWidgets library sources), but the wxwidgets3.0 source package is just the C++ library. There hasn't been an update of wxPython for 3.0 yet, and while I have managed to patch wxPython 2.9.5.0 to work, it turned out to be quite a complex change and at this point waiting for wxPython 3.0.0.0 and then packaging that as a separate source package seems better. (I've sent upstream my patches in case they're useful). * Upstream now enables their debug checks by default. One consequence of this is that in 2.8, the -dbg packages were a version built with these checks on, and debug info, but in 3.0, the -dbg packages are just detached debug symbols. The other is that code which misuses the wx API will now pop up warning dialogs, while previously the code would have quietly muddled through. Overall sorting out such issues is good, but these dialogs are intrusive for users. I suspect checking rebuilt packages and fixing such issues might be the biggest job in transitioning packages. * You should be able to co-install wx 2.8 and 3.0, so applications can switch independently of one another. The only wrinkle is that currently the -i18n packages attempt to install the same files - I need to look at how we handled that for 2.6 and 2.8. * The -doc package is temporarily gone in the 3.0 packages (upstream now release the docs as a separate download). Cheers, Olly -- 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/20131113154349.ga31...@survex.com
Re: porting OpenRC on kFreeBSD and Hurd
On 11/11/2013 11:26 PM, Thomas Goirand wrote: > On 11/11/2013 11:18 AM, Thomas Goirand wrote: >> On 11/09/2013 10:38 PM, Colin Watson wrote: >>> On Wed, Oct 30, 2013 at 02:45:31AM +0800, Thomas Goirand wrote: Note also that there's a *new* dependency problem (it wasn't there a month ago...), with ifupdown, openssh-server plus another one (I can't remember which one) which insist on having sysv-rc installed. >>> >>> This is because dh_installinit generates a versioned dependency on >>> sysv-rc if a package contains an Upstart job, because that relies on a >>> patch to invoke-rc.d so that sysvinit compatibility works properly. If >>> OpenRC ships a version of invoke-rc.d, it'll probably need a similar >>> patch and to have debhelper adjusted. I already did this for file-rc, >>> so perhaps you want to clone-and-hack my patches for OpenRC: >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709481 >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709482 >> >> Hi Colin and Joey, >> >> Following up what Colin wrote, I opened #729248. Then Joey closed the >> same day, writing: >> >> "Something is certianly wrong if every new init system requires packages >> that have a versioned ored dependency on every other init system be >> rebuilt. >> >> Someone else is going to have to figure this out, I am not interested in >> upstart." >> >> Well, I'm trying to fix the OpenRC problem, not Upstart. And I'm really >> confused, not knowing what's the way forward here... :( >> >> Any advice here? >> >> Cheers, >> >> Thomas > > Sorry for the confusion, it seems that it's been fixed with the latest > debhelper version. > > Cheers, > > Thomas After rebuilding ifupdown, sysvinit, udev and openssh, I could install OpenRC normally, as I was used to. Hoping that source-full uploads will happen before I fix the /sbin/rc issue, otherwise I'll ask for BINnmu. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5283bb8f.4050...@debian.org
Re: jessie release goal: verbose build logs
Stéphane Glondu writes: >> http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build > > How do you do that exactly? Can't remember the exact details but you can get the script with git clone http://lindi.iki.fi/lindi/git/structured-buildlogs.git/ -Timo -- 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/848uwshwfm@sauna.l.org
Re: wxwidgets 3.0
Hi Olly, On Wed, Nov 13, 2013 at 03:43:49PM +, Olly Betts wrote: > I'll be at the mini-debcamp in Cambridge, UK at the end of this week > (14th and 15th November) and plan to make a start checking packages > with the new release. I'd welcome local and/or remote assistance. I just arrived in Cambridge. I plan to update aegisub to newest upstream (using wxWidgets 2.9) during the mini-debconf. -- Sebastian signature.asc Description: Digital signature
Re: MIPS64EL rootfs available for use and test
On 11/11/2013 09:57 AM, YunQiang Su wrote: Hi, folks, In the recent days, I figure out the mips64el rootfs and test it on Loongson 3A platform. It works well in general, it's time to release it. It can be download from: http://mips64el.debian.net/debian/rootfs/ Nice! I tested it on our OCTEON boards. Seems to be working. I had to enable CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in my kernel and edit /etc/inittab to put gettys on my serial ports, and set the root password. But after that, it works seemingly without a hitch. To install it, what you need to do is just unpack it to a partition and configure kernel/bootloader/fstab by yourself. This is a more detailed instruction for Loongson 3A users: http://mips64el.debian.net/debian/rootfs/README Know issues: 1. MIPS64r2 ISA is required, while we have made a agree to downgrade the requirement to mips3 in future. 2. The permission is of /usr/bin/crontab is not correct, so you need to: apt-get install cron --reinstall 3. some files in /var/cache/man are not correct, you need to: rm -rf /var/cache/man/* ; mandb PS: we have 8500+ packages built now. Happy hacking, and I am wishing your feedback. -- 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/52841350.2010...@caviumnetworks.com
Bug#729535: general: mouse sometimes slow upon boot. must reboot to fix.
Package: general Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** Rebooted system after work (cold boot), and logged into my user name, started up X and my mouse was very slow and unresponsive. Sometimes freezing. If frozen I have to switch to another virtual terminal, and then switch back to X to un- freeze it. When it's slow, switching between the terminal and X does nothing. I have to reboot the entire system and log back in, fire up X and the mouse is then responsive again. I do this a few times a day and it's quite a pest. -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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/20131114002118.4388.72814.reportbug@debian
Re: MIPS64EL rootfs available for use and test
On Thu, Nov 14, 2013 at 8:03 AM, David Daney wrote: > On 11/11/2013 09:57 AM, YunQiang Su wrote: >> >> Hi, folks, >> >> In the recent days, I figure out the mips64el rootfs and test it on >> Loongson 3A platform. >> It works well in general, it's time to release it. >> >> It can be download from: >> http://mips64el.debian.net/debian/rootfs/ >> > > Nice! > > I tested it on our OCTEON boards. Seems to be working. I had to enable > CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in my kernel and edit /etc/inittab > to put gettys on my serial ports, and set the root password. But after > that, it works seemingly without a hitch. Great news, while wait... does OCTEON support little endian? > > > >> To install it, what you need to do is just unpack it to a partition >> and configure kernel/bootloader/fstab by yourself. >> >> This is a more detailed instruction for Loongson 3A users: >> http://mips64el.debian.net/debian/rootfs/README >> >> Know issues: >> 1. MIPS64r2 ISA is required, >> while we have made a agree to downgrade the requirement to >> mips3 in future. >> 2. The permission is of /usr/bin/crontab is not correct, so you need >> to: >> apt-get install cron --reinstall >> 3. some files in /var/cache/man are not correct, you need to: >>rm -rf /var/cache/man/* ; mandb >> >> PS: we have 8500+ packages built now. >> >> Happy hacking, and I am wishing your feedback. >> > -- YunQiang Su -- 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/cakcpw6xejpylmqutg+r7y5gshmfjeaij_53spz80ein+ew0...@mail.gmail.com
Re: MIPS64EL rootfs available for use and test
On 11/13/2013 04:32 PM, YunQiang Su wrote: On Thu, Nov 14, 2013 at 8:03 AM, David Daney wrote: On 11/11/2013 09:57 AM, YunQiang Su wrote: Hi, folks, In the recent days, I figure out the mips64el rootfs and test it on Loongson 3A platform. It works well in general, it's time to release it. It can be download from: http://mips64el.debian.net/debian/rootfs/ Nice! I tested it on our OCTEON boards. Seems to be working. I had to enable CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT in my kernel and edit /etc/inittab to put gettys on my serial ports, and set the root password. But after that, it works seemingly without a hitch. Great news, while wait... does OCTEON support little endian? Yes. The kernel.org kernel doesn't yet contain full little-endian support, but getting little-endian support merged is on our list of things to do. David Daney To install it, what you need to do is just unpack it to a partition and configure kernel/bootloader/fstab by yourself. This is a more detailed instruction for Loongson 3A users: http://mips64el.debian.net/debian/rootfs/README Know issues: 1. MIPS64r2 ISA is required, while we have made a agree to downgrade the requirement to mips3 in future. 2. The permission is of /usr/bin/crontab is not correct, so you need to: apt-get install cron --reinstall 3. some files in /var/cache/man are not correct, you need to: rm -rf /var/cache/man/* ; mandb PS: we have 8500+ packages built now. Happy hacking, and I am wishing your feedback. -- 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/52841d71.3090...@caviumnetworks.com
