Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
Package: wnpp Severity: wishlist Owner: Ricardo Mones * Package name: webkit2pdf Version : 0.1 Upstream Author : Colin Leroy * URL : http://webkit2pdf.sourceforge.net/ * License : GPLv2+ Programming Lang: C Description : export web pages to PDF files Webkit2pdf is a little GTK+ tool designed to fetch web pages and export them to numbered PDF files (or to print them). . Specifying paper size and output directory is also supported. -- 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/20110203093914.18635.65482.reportbug@busgosu
Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
Ricardo Mones (03/02/2011): > Description : export web pages to PDF files > > Webkit2pdf is a little GTK+ tool designed to fetch web pages and > export them to numbered PDF files (or to print them). > . > Specifying paper size and output directory is also supported. Hope this helps: $ apt-cache show wkhtmltopdf | sed -n '/^Description/,$p' Description: Command line utility to convert html to pdf using WebKit wkhtmltopdf is a command line program which permits to create a pdf from an url, a local html file or stdin. It produces a pdf like rendred with the WebKit engine. . This program requires an X11 server to run. Homepage: http://code.google.com/p/wkhtmltopdf/ Tag: implemented-in::c++, interface::x11, role::program, uitoolkit::qt, use::converting, works-with::text, works-with-format::html, x11::application KiBi. signature.asc Description: Digital signature
Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
Ricardo Mones scrisse: > Package: wnpp > Severity: wishlist > Owner: Ricardo Mones > > * Package name: webkit2pdf > Version : 0.1 > Upstream Author : Colin Leroy > * URL : http://webkit2pdf.sourceforge.net/ > * License : GPLv2+ > Programming Lang: C > Description : export web pages to PDF files > > Webkit2pdf is a little GTK+ tool designed to fetch web pages and > export them to numbered PDF files (or to print them). > . > Specifying paper size and output directory is also supported. Have you seen cutycapt[0] already? I see no advantages in having webkit2pdf in Debian too, so far. Care to compare and expand your rationale? [0] http://packages.debian.org/squeeze/cutycapt Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: PGP signature
Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
There is also webkit-image, which currently only exports to PNG image format, though. [0] http://packages.debian.org/source/sid/webkit-image -- 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/4d4a9bce.80...@greffrath.com
Bug#611895: ITP: django-kombu -- Kombu transport using the Django database as a message store
Package: wnpp Severity: wishlist Owner: Fladischer Michael -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: django-kombu Version : 0.9.1 Upstream Author : Ask Solem * URL : http://github.com/ask/django-kombu/ * License : BSD Programming Lang: Python Description : Kombu transport using the Django database as a message store This package provides a message store for Kombu inside a Django database. It is intended be used together with python-kombu and provides a transport for it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1KnRgACgkQeJ3z1zFMUGZEigCfcYJ8qJYOEhauvOANOEZ2Dqwt Or0AnRKCfuyyIKqaeMkSqu1iXvBZ7dzs =PG+U -END PGP SIGNATURE- -- 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/20110203121832.10874.65440.report...@ossus.home.fladi.at
Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
OoO En cette fin de matinée radieuse du jeudi 03 février 2011, vers 11:15, Cyril Brulebois disait : > $ apt-cache show wkhtmltopdf | sed -n '/^Description/,$p' OoO En cette fin de matinée radieuse du jeudi 03 février 2011, vers 11:19, Luca Bruno disait : > Have you seen cutycapt[0] already? I see no advantages in having > webkit2pdf in Debian too, so far. Care to compare and expand your > rationale? > [0] http://packages.debian.org/squeeze/cutycapt It seems neither cutycapt nor wkhtmltopdf (as compiled in Debian) allows to convert hyperlinks. Does webkit2pdf allows this? -- BOFH excuse #113: Root nameservers are out of sync pgpgPuZ6njyoQ.pgp Description: PGP signature
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
+++ Loïc Minier [2011-02-01 12:50 +0100]: > On Tue, Feb 01, 2011, Wookey wrote: > > But if something is looking for arch-independent stuff in /lib then in > > general that's wrong, and I'm not aware of any examples of > > correctly-packaged packages that need this. Any arch-independent files > > will be supplied by an arch all package that the build should depend > > on if needed. > > I might be getting your point wrong, but I certainly see a lot of files > in /lib itself which are arch-independent data used for early boot > (before /usr is available); PNG files and text files which would be > identical on all architectures. Sorry, I wasn't being very clear. By 'something is looking for arch-independent stuff in /lib' I really mean in /usr//lib, used during cross-building, (which will be put there by dpkg-cross-ed packages) (or in /usr/lib/ or /lib/ put there by dpkg on multiarch systems). Yes there are various things in /lib that are not arch-dependent. dpkg-cross does not put most(any?) of those in -cross packages. In fact this is so true that it doesn't copy /usr/lib/tcl8.5/tclConfig.sh over into the cross package either. I should have checked that. Bum. dpkg-cross in fact only picks files out of packages by positive identification as libraries or headers. It misses out generic 'other stuff' in ((/usr)/lib, which generally works pretty well, but in this tcl case it's not suffient for tcl-depending apps to cross-build. Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599206 discusses this issue. dpkg-cross is intended to put files needed for cross-building into -cross packages and it's currently missing this one out. Unfortunately because it doesn't match any of the 'standard paterns for cross-useful files' this can only be fixed by adding a fairly specific regexp, which is worrying close to special-casing or deciding that in fact just fishing out specific things from /usr/lib is too conservative and we should take the view that everything in /usr/lib is potentially useful in cross-building and should be copied into -cross packages. In multiarch world everything in (/usr)/lib is going to end up in /usr/lib/ or /lib/, unless packages are re-arranged to put them elsewhere, and we expect this to work fine so perhaps dpkg-cross should start doing the same thing, and thus discuver any problems this does potentially create. Would that actually do any harm? What files which are currently missed out of -cross packages would actually cause breakage if copied over into /usr//lib? I just tried a modified dpkg-cross on a pile of packages and whilst many come out the same, you do get quite a lot more files in some packages and some packages that were previously null now have stuff in them. e.g apache-modules. So there is quite a lot of bloat, but probably no breakage. Internally we will use a dpkg-cross modified to add /usr/lib/*/tclConfig.sh to the list of things that are important for cross-building. This means we will notice any other 'awkward cases' due to missing files. An alternative view is that anything (such as sqlite3) depending on tclConfig.sh to build tcl extensions is broken and should be changed to use some other mechanism, and until then simply cannot be cross-built using the dpkg-cross mechanism. I am not familiar enough with tcl extensions to know if this is a reasonable stance or not, but given that it works just fine, and it's not hard to deal with, and (after the fix in debian bug#611650) it will carry on 'just working' in multiarch, I'm not convinced this is a reasonable stance. Which leaves us with deciding whether to just copy over tclConfig.sh or everying in /usr/lib/*/* in dpkg-cross? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20110203153949.gi4...@dream.aleph1.co.uk
Re: tcl8.5 breaks dpkg-cross assumptions and multiarch
On Thu, 3 Feb 2011 15:39:49 + Wookey wrote: > dpkg-cross in fact only picks files out of packages by positive > identification as libraries or headers. It misses out generic 'other > stuff' in ((/usr)/lib, which generally works pretty well, but in > this tcl case it's not suffient for tcl-depending apps to cross-build. > > Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599206 discusses > this issue. ... and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611736 is probably going to be the root bug (renamed) to handle the clarification of exactly what files we keep and how we rationalise the legacy regular expressions in dpkg-cross. Please add further specific cases to that bug. > dpkg-cross is intended to put files needed for cross-building into > -cross packages and it's currently missing this one out. Unfortunately > because it doesn't match any of the 'standard paterns for cross-useful > files' this can only be fixed by adding a fairly specific regexp, > which is worrying close to special-casing or deciding that in fact > just fishing out specific things from /usr/lib is too conservative and we > should take the view that everything in /usr/lib is potentially useful > in cross-building and should be copied into -cross packages. Generally, from a cursory view of what is left out, the situation we have is this: 0: dpkg-cross supports autotools cross-building through a series of very detailed, very complex and potentially fragile regular expressions but, importantly, ALSO uses a series of very detailed, very complex and potentially equally fragile regular expressions on the CONTENTS of those files, some of which Debian is quietly trying to drop from packages because of other problems. (e.g .la files) 1: dpkg-cross has explicit support for pkg-config which appears to work perfectly well, principally because pkg-config is inherently less complex than the entirety of autoconf|automake|libtool|dpkg-shlibdeps etc. 2: dpkg-cross has support for CMake - although only as a direct result of 0: and 1: 3: dpkg-cross has no idea how to help SCons or any number of other build systems out there, but then it mostly doesn't have to because many of those simply don't compile stuff, (they create Arch:all packages) and the ones that do compile stuff aren't used by sufficient numbers of cross-building people for sufficient complaints to be seen for dpkg-cross to have had the support created. 4: Nobody gave a damn about Tcl until sqlite added bindings. 5: Nobody adds support to dpkg-cross until someone complains loudly enough *and* comes up with sane patches. 6: dpkg-cross has huge amounts of legacy code which someone added at somepoint because it was important but nobody has actually had the guts to unilaterally remove because we can't tell if the original package has since been fixed. (s/fixed/broken in a different way/). > In multiarch world everything in (/usr)/lib is going to end up in > /usr/lib/ or /lib/, unless packages are > re-arranged to put them elsewhere, and we expect this to work > fine so perhaps dpkg-cross should start doing the same thing, and thus > discuver any problems this does potentially create. Would > that actually do any harm? What files which are currently missed out > of -cross packages would actually cause breakage if copied over into > /usr//lib? Let's not break dpkg-cross fundamentally for everyone though. We can choose to make a different dpkg-cross which is FAR simpler (because it blindly moves files without any kind of safeguard) but as this does not involve fixing the contents of certain files, numerous autotools packages will break. So, if people want a broken dpkg-cross for testing, let's have a dpkg-multi-cross which breaks their cross-building world (using a different Provides: and conflicting with the "standard" cross packages) and leave the existing world alone. That version of dpkg-multi-cross would be trivial to write - unpack the .deb, unconditionally move all files in ./usr/lib to ./usr/$triplet, handle /usr/include and remove everything else. Repack the .deb as -cross. Break world. > I just tried a modified dpkg-cross on a pile of packages and whilst > many come out the same, you do get quite a lot more files in some > packages and some packages that were previously null now have stuff in > them. e.g apache-modules. So there is quite a lot of bloat, but > probably no breakage. Retaining the changes to the contents of the files whilst simply adding lots more *stuff* to -cross packages is the least harmful option. However, because the contents haven't changed, it doesn't actually help us identify the issues that would arise with Multiarch much. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpIBH9FhmlYv.pgp Description: PGP signature
[SRI-NEWS] Keeping on thinking in two dimensions we will not solve the problem. Join the Space Renaissance!
SPACE RENAISSANCE INTERNATIONAL - NEWS NO. 2 2011 Dear Members of the Space Renaissance International, and all true humanists, These days we are witnessing the effects of globalization in different countries with different histories and levels of industrial development, that are now being merged into a single world. Large and small companies are relocating to take advantage of lower labor costs and as a result, workers may have to agree to reductions of their rights, and to the worsening of working conditions. But simply throwing up barricades to protect local economic, social, political and religious benefits has no meaning or value if it does not take into account today's realities. This only triggers desperate dynamics which have many examples in history. The current situation compared to forty years ago, well within the lifetime of many of us, is quite different. The 1960's and '70's were historically situated at the height of a period of strong economic growth that reached its greatest success with the US team landing on the Moon on July 21, 1969. Workers around the world claimed their share of this well-being because they contributed to the growth of wealth and productivity. They worked hard and were sustained by strong reasons of ethics and social justice. This is not to say that purely defensive tactics are unnecessary and will inevitably cause dynamic involution, but neither does it provide an ethical license for large scale relocation of production facilities just to improve the "bottom line." Neither can we agree with those who--recalling the quasi-religious messages of the past--exhort us to be content to live with less, reduce consumption, resign ourselves to fewer rights, save energy, and so on. Some people were content for their whole life to carry their families with survival-level salaries. Others, who with great difficulty created their own companies, saw it swept away by the current economic crisis and even lost their homes. Meanwhile, they saw bankers, oilmen and corrupt politicians continue to wallow in gold in spite of the ruin of millions of people. The real problem is strategic. For example, Mr. Marchionne, CEO of Fiat/Chrysler, is going to continue making cars, anywhere the labor costs and financial incentives are greatest--for him and his company. He is not to blame for this, and it is clear that the freedom of movement guaranteed by private transport is to be preserved and even further developed, even into integrated transportation systems. The error of Mr. Marchionne, again using him as an example but not the only one, and his friends in the petroleum industry, is to think only in two dimensions--horizontally--on roads and rails crisscrossing the surface of our planet or within the envelope of our atmosphere. For some years the post-industrial world will retain an advantage in the emerging world of aerospace technologies. This advantage will rapidly disappear because the emerging powers of China and India seem to understand the value and importance of space for the further development of a world of seven billion people much better than our current Western political and economic leaders. This could change. By investing in the design and production of sub-orbital and orbital vehicles, and starting to think finally in three dimensions, the big automakers could become advocates of the new industrial revolution. Space tourism could develop a formidable momentum, and after it industrial estates could develop in Earth orbit, at the Lagrange points and the Moon, paving the way for large scale implementation of space based solar power and exploitation of lunar and asteroidal raw materials. Such a new course of a globalized economy in the process of becoming an exo-economy (that is, based off the Earth) could create millions of new jobs and new industries. Western workers could keep and even improve their rights to adequate wages, hours and working conditions and maybe become an --internationalist--example for workers in the developing countries. Here is a prospect of progress, and not defensive, from which all parts of society will gain--a revolution worth fighting for! If you think that it is worth working and fighting for, - Join the Space Renaissance http://www.spacerenaissance.org/sri-register.htm - Attend the first congress of the International Space Renaissance to be held in June 2011 http://www.spacerenaissance.org/SRIC/SRIC-HOME.html - Buy online the book "Three Theses for the Space Renaissance" http://www.lulu.com/commerce/index.php?fBuyContent=10003567 - Organize meetings for discussion of the above arguments for your community: You can participate in the Congress to improve the Thesis and be entitled to vote. - Submit papers to the Congress, responding to our Call for Papers http://www.spacerenaissance.org/SRIC/SRIC-CallForPapers.html Wherever there are at least five registered members, a l
Upcoming FTPMaster meeting
Hello world, i just want to take the opportunity that everyone is watching the final preparations for Squeeze to announce our next FTPMaster meeting. Your beloved team of FTPMasters will meet from the 21st til 27th of March in the LinuxHotel in Essen. During the weekend one of the wanna-build admins will join in. Similar to our last big meeting in Essen late in 2009 we again expect to have the archive turned off for much of the meeting time. I think expecting just something like "one dinstall per day, with packages accepted shortly before" is reasonable, but maybe there is a day or ten without even that. But we will keep you updated like we did last time, it is hard to exactly pin down today what will happen when during that week. As we know that the services we offer are pretty central to Debian and many people depend on what we do, we realize there are lots of people whose work is closely related to ours. Should you be one of those and run a service that can profit from something we can provide, or could profit from certain changes on our side - and you want to kick that off to get a better service from us: Please reply to me off-list and we can see if we can work something out for you to join us for the weekend. (I need a reason to see if it fits into the meeting and a half-way accurate amount your travel will cost[1]). Currently we can plan for about 3 more people. [1] If you fly, Cologne or Duesseldorf are nearby. Frankfurt works too, especially good if you come in from far away. Obviously train takes a bit longer from there. From wherever you get in, the final train station you want to get to is called "Horst S-Bahnhof Essen (Ruhr)". Attached below is a tentative agenda. This is an unsorted list and we might not get to every point. We might also have missed any number of points, if so feel free to tell us about them. * Switch to use release codenames primarily inside dak, not testing/unstable/foo (if not done at release time already, which we try) * Database "acl" set, ie. ability to merge security into main archive, but not have everyone see everything... * Leaf packages. that is, the possibility of having small packages in the archive, without bloating the packages files as a "full package" would. Somehow, less information stored for them. Like only "Package", "Installed-Size", "Version", "FileName", "Size", "Sha1Sum" and one new "mainpackage:" which is simply the package name of the "full package". maybe a one-line description entry, but thats it. Tools like apt then take all the other missing information, including the long desc, from the mainpackage, and voila we get the possibility to have something like foo-config-blabla and foo-config-blubber without much bloat. (this will need design work done now but we won't be able to use it before wheezy or wheezy+1) * pg9.0 fun (we want replication) * buildd autosigning * get rid of hurd (or discuss this) * get rid of md5sum and one of the two shasums in packages files * script point releases more. copy/paste from docs/README.stablefoo works, but script is nicer. * Throwaway DD built .debs (well, let's have the fight^Wdiscussion) * Built-Using infrastructure (for kernel udebs and so on) * dinstall replacement (from bash off to python). look at ducks * fix up build queue handling so security stuff works properly * Merge the archives codes even more, maybe end up with only one config/ directory, not one per archive * data.debian.org * Contents, Source-Contents * Packages generation (needs lots of db stuff) * Reduce the config file even more - more in the database * Apropos the above, centralise dak's email handling / sending so it's easier to override (i.e. even from shell scripts use a dak wrapper for it) * Documentation * dak for squeeze (python 2.6, sqlalchemy 0.6, python-apt 0.7.100) * explain the idea behind class ORMObject and friends * remote interfaces: ORMObject has a json() method for easier debugging but might that be a first step to provide a (maybe readonly) REST interface to dak in the future? -- bye, Joerg Weaseling out of things is important to learn. It's what separates us From the animals ... except the weasel. pgpA10UsOXa2u.pgp Description: PGP signature
Bug#611928: ITP: mrbayes -- Bayesian Inference of Phylogeny
Package: wnpp Severity: wishlist Owner: andr...@an3as.eu * Package name: mrbayes Version : 3.1.2 Upstream Author : Fredrik Ronquist * URL : http://mrbayes.sourceforge.net/ * License : GPL Programming Lang: C Description : Bayesian Inference of Phylogeny Bayesian inference of phylogeny is based upon a quantity called the posterior probability distribution of trees, which is the probability of a tree conditioned on the observations. The conditioning is accomplished using Bayes's theorem. The posterior probability distribution of trees is impossible to calculate analytically; instead, MrBayes uses a simulation technique called Markov chain Monte Carlo (or MCMC) to approximate the posterior probabilities of trees. The package will be maintained in the Debian Med team. Packaging stuff is available in SVN: Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/mrbayes/trunk/?rev=0&sc=0 Vcs-Svn: svn://svn.debian.org/svn/debian-med/trunk/packages/mrbayes/trunk/ -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- 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/20110203210644.3097.52748.report...@mail.an3as.eu
Re: Bug#611880: ITP: webkit2pdf -- export web pages to PDF files
Hi all, First thanks for your interest in webkit2pdf. I wasn't aware of the cutycapt and wkhtmltopdf packages, but now that you mention them and after having tested both alternatives I still prefer webkit2pdf, see below. On Thu, 03 Feb 2011 14:25:42 +0100 Vincent Bernat wrote: > OoO En cette fin de matinée radieuse du jeudi 03 février 2011, vers > 11:15, Cyril Brulebois disait : > > > $ apt-cache show wkhtmltopdf | sed -n '/^Description/,$p' > > OoO En cette fin de matinée radieuse du jeudi 03 février 2011, vers > 11:19, Luca Bruno disait : > > > Have you seen cutycapt[0] already? I see no advantages in having > > webkit2pdf in Debian too, so far. Care to compare and expand your > > rationale? Sure. First, it's GTK+-based and doesn't depend on QT libraries like the other two. Other important reason it has a minimalistic GUI which allows previewing the result, while retaining the ability to just work on the command line if the right parameters are supplied. The others are not capable of this. Also gets some extra points for being also the smallest of the three: -rwxr-xr-x 1 root root 28576 Feb 3 16:24 /usr/bin/webkit2pdf -rwxr-xr-x 1 root root 41056 Jul 2 2010 /usr/bin/cutycapt -rwxr-xr-x 1 root root 275520 Oct 12 23:26 /usr/bin/wkhtmltopdf My impression is that is also faster, though I've not done extensive timings. Is as fast as or slightly faster than wkhtmltopdf and a lot faster than cutycapt (I guess this being a SVN version has room for improvement). And finally, this is subjective and also is probably dependent on the page's CSS, but the default result of webkit2pdf is more readable to me than the others on the same pages. I'll update the long description with the non-subjective items :) > It seems neither cutycapt nor wkhtmltopdf (as compiled in Debian) allows > to convert hyperlinks. Does webkit2pdf allows this? Nope, the URLs are appended after the linked texts, just like the others. regards, P.S.: Please keep the bug address in Cc, I'm not subscribed to devel@ list. -- Ricardo Mones http://people.debian.org/~mones «Your aims are high, and you are capable of much.» signature.asc Description: PGP signature
does aptitude really need to lock the status database when downloading?
Hi debian-devel, I wanted to ask this for quite a long time: Does aptitude (I think apt-get does the same) really have to lock "the status database area" when _downloading_ packages? For example, I am running an update on a slow connection and want to uninstall or install with dpkg a few packages while the others are being downloaded. Should not this be possible? I understand that there can be a situation that a dependency could be affected by such an action, but is not it easy to check for this right before unpacking? -- Stanislav -- 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/20110204001054.GA31724@kaiba.homelan
Re: does aptitude really need to lock the status database when downloading?
#include * Stanislav Maslovski [Fri, Feb 04 2011, 03:10:54AM]: > Hi debian-devel, > > I wanted to ask this for quite a long time: Does aptitude (I think > apt-get does the same) really have to lock "the status database area" > when _downloading_ packages? > > For example, I am running an update on a slow connection and want to > uninstall or install with dpkg a few packages while the others are > being downloaded. Should not this be possible? I understand that there > can be a situation that a dependency could be affected by such an > action, but is not it easy to check for this right before unpacking? If you want to have that level of control, why don't you just check it manually? Use --download-only with apt-get (no dpkg locking this way) and when it's done, use apt-get without it to install the packages after making sure that there is no dpkg active anymore. Regards, Eduard. -- Wir lassen uns beide von unseren Frauen scheiden und ziehen zusammen. -- Toni Polster (über sein verbessertes Verhältnis zu Trainer Peter Neururer) -- 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/20110204002107.ga14...@rotes76.wohnheim.uni-kl.de
Re: does aptitude really need to lock the status database when downloading?
On Fri, 2011-02-04 at 03:10 +0300, Stanislav Maslovski wrote: > Hi debian-devel, > > I wanted to ask this for quite a long time: Does aptitude (I think > apt-get does the same) really have to lock "the status database area" > when _downloading_ packages? > > For example, I am running an update on a slow connection and want to > uninstall or install with dpkg a few packages while the others are > being downloaded. Should not this be possible? I understand that there > can be a situation that a dependency could be affected by such an > action, but is not it easy to check for this right before unpacking? > > -- > Stanislav > > FYI, There is a blueprint in ubuntu aimed for natty concerning this feature: https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-update-manager-incremental-updates >support downloading in parallel while upgrading the chunks: TODO Regards, Julian signature.asc Description: This is a digitally signed message part
there is /usr/lib64 symlink but no /usr/local/lib64
please do not slap me too hard (only so that I feel your warm carrying touch): is there a rationale for: on amd64 Debian systems having /lib64 -> /lib /usr/lib64 -> /usr/lib but no similar one for /usr/local/lib64, so that directory /usr/local/lib64 gets created if anyone (with enough rights) does 'make install' pointing there; and we do not include /usr/local/lib64 into ldconfig path (by default), so those libraries 'get lost' aren't we diverging from FHS: If directories /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local. ? thanks for the input -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20110204060813.ga16...@onerussian.com
Bug#611961: ITP: handlersocket -- HandlerSocket is a NoSQL plugin for MySQL
Package: wnpp Severity: wishlist Owner: Clint Byrum * Package name: handlersocket Version : 1.0.6-69-g28c51bc Upstream Author : Akira Higuchi (https://github.com/ahiguti) * URL : https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL * License : BSD Programming Lang: C++, Perl Description : HandlerSocket is a NoSQL plugin for MySQL HandlerSocket is a NoSQL plugin for MySQL. It works as a daemon inside the mysqld process, accept tcp connections, and execute requests from clients. HandlerSocket does not support SQL queries. Instead, it supports simple CRUD operations on tables. -- 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/20110204064536.7153.97085.reportbug@localhost6.localdomain6
Re: Upcoming FTPMaster meeting
Hi, On Thu, 03 Feb 2011, Joerg Jaspert wrote: > Attached below is a tentative agenda. This is an unsorted list and we > might not get to every point. We might also have missed any number of > points, if so feel free to tell us about them. I have not seen any word about XZ support. When you deployed support for new source package formats, you forbid lzma because xz was coming along and you mentioned that wheezy could have xz enabled. I would like to see xz allowed both for source package and for binary packages. So I would be glad if you added "allow XZ for source packages and fix #556407" to your agenda. Thanks for considering it. > * Leaf packages. that is, the possibility of having small packages in > the archive, without bloating the packages files as a "full package" > would. Somehow, less information stored for them. Like only "Package", > "Installed-Size", "Version", "FileName", "Size", "Sha1Sum" and one new > "mainpackage:" which is simply the package name of the "full > package". maybe a one-line description entry, but thats it. Is that also for very small perl modules that are bundled together currently? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110204072002.gg11...@rivendell.home.ouaza.com
Re: Upcoming FTPMaster meeting
On 2011-02-03, Joerg Jaspert wrote: > * Leaf packages. that is, the possibility of having small packages in > the archive, without bloating the packages files as a "full package" > would. Somehow, less information stored for them. Like only "Package", > "Installed-Size", "Version", "FileName", "Size", "Sha1Sum" and one new > "mainpackage:" which is simply the package name of the "full > package". maybe a one-line description entry, but thats it. > > Tools like apt then take all the other missing information, including > the long desc, from the mainpackage, and voila we get the possibility > to have something like foo-config-blabla and foo-config-blubber > without much bloat. (this will need design work done now but we won't > be able to use it before wheezy or wheezy+1) Which would mean stripping Depends and doing indirection. What about, instead, dropping two of the checksums and refering to the Description in another file which is planned for translations of them anyway? (I.e. refer by hash.) Would that already help quite a bit? The description and the hashsums probably contain a tad more entropy than the other bits and could already help quite a bit. (But then you're of course still bloating one Package file per arch and there's no compression to help here.) 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 Archive: http://lists.debian.org/slrniknaik.18e.tr...@kelgar.0x539.de
