Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
On Mon, Sep 13, 2021 at 5:06 AM Sam Hartman wrote: : > This seems clearly within the power Debian grants individual maintainers > to either keep the citation notice or to remove it. I hope my stance is clear: I want to have an income from developing free software. The citation notice indirectly gives me that. If you want to take away this without paying me in a different way, I can only see that as an active hostile action: You are threatening my livelihood. Having GNU Parallel moved to non-free or not being distributed by Debian at all is preferable to having my livelihood attacked. Remember: I am not the enemy - I am the reason you have something to package in the first place; so please don't behave like a dick - even if what you intend to do might technically be legal. I will be happy to work with anyone who understands this stance and who wants to work to find a solution that everyone can accept. And given I just want the citation notice shown to people who write scientific articles, I really think we can find such a solution. /Ole
Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
On Tue, Sep 7, 2021 at 11:06 AM Lucas Nussbaum wrote: : > (1) the wording almost requires citation I take this as you agree that it does not require citation. Also you do not point to how the default behaviour of the current version of GNU Parallel conflicts with Debian's standards. If you believe it conflicts with Debian's standards, please point to the specific paragraph(s). > (2) it does so by providing a version-specific citation, not a generic To me it is more honest to cite the specific version you are actually using than to cite an article about software that is 10 years old, and which may not have the features that you depend on. But if the general consensus is that it is more honest to cite the old article, I will be perfectly happy with that. If this is what blocks us from reaching a compromise we can agree on, I will change that in the next version. > With a wrong eye, one could even see it as extortion/blackmail. To me extortion/blackmail is when I have done something that I cannot undo and now I have to pay to keep it a secret. If you feel it can be seen as extortion/blackmail: Would it not make it even *more* important that the researchers read the citation notice *before* using the software? To me it could never be perceived as neither extortion nor blackmail: * The user is aware of the citation notice when he starts using GNU Parallel * There are plenty of alternatives - more than 50 of them are even mentioned in the documentation * If you feel GNU Parallel does not contribute enough to warrant a citation: Prove it by using an alternative Would it be fair to summarize your critique as you in your personal opinion do not like the citation notice, but there are neither legal nor technical reasons for this? In other words: It is a matter of taste. /Ole
Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
On Fri, Sep 3, 2021 at 5:05 PM Felix Lechner wrote: > On Fri, Sep 3, 2021 at 7:50 AM Tobias Frost wrote: > > > > But as said earlier: This is not a license issue; the license of GNU > > parallel > > would allow removal, but this would make upstream sad. > > The status quo is likely to mke our users sad, though. Maybe it would help if the consequences were explained to them: * Do you want the software with no citation notice and risk that the maintainer will step down because he cannot afford spending time on it - thus getting less free software in the long run? * Or do you want to spend the 10 seconds it takes to silence the notice if you don't want to see it? I think more users would be more sad if the software was no longer maintained. But you will no doubt get a few vocal exceptions. But maybe there exists a third option. > Maybe the debconf system can provide a choice? The default could be > consistent with Debian's standards. Can we agree that a click-wrap requires the user to actively do something (e.g. clicking) before he can use the software? If so: The citation notice is not a click-wrap, because the GNU Parallel will run just fine without silencing the notice. It doesn't even break scripts. It is still not clear to me how the default behaviour of the current version of GNU Parallel conflicts with Debian's standards: The citation notice provides you with useful information if you are a researcher who publishes; it does not limit who can use the software. If you believe it conflicts with Debian's standards, point to the specific paragraph. (I accept that wording in version 20141022 was unclear - and I can see how you could argue that back then). The ultimate goal has never been to have a license notice. The goal is to make it possible for me to spend time developing free software. In practice this means either pay my salary or have GNU Parallel cited, so it is easier for me to get a job that pays my salary. It is unlikely that the Debian project will provide my salary, so let us focus on the second part. Before the license notice was implemented researchers forgot to cite GNU Parallel; not because they did not want to honor the tradition, but simply because they forgot. The citation notice changed this for the better. If there is a different way that will ensure researchers will not forget, it would be acceptable to me. I am open to (but not convinced) that a debconf choice would accomplish this. If you believe it will, please elaborate how. /Ole
Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
On Mon, Aug 30, 2021 at 8:26 AM Andreas Tille wrote: > > since this issue becomes complex I'd like to bring up it at debian-legal > list for advise. In disagreements it often helps to first agree on what the parties disagree on. That way you can put aside the parts you agree on. Maybe this can also help here. In the text below The Notice refers to the citation notice in GNU Parallel version 20210722. Do you believe the original source code of version 20210722 is GPLv3 compliant in your interpretation of the GPLv3? If no: What license (if any) would give you the right to change the software? Do you believe The Notice conflicts with the 4 freedoms of Free Software? If so: please explain how. Do you believe The Notice conflicts with the DFSG? If so: please explain how. Do you believe The Notice breaks scripts - unattended or not? If so: Provide a minimal working example that shows a script actually breaking (don't assume it will break, instead show it actually breaks). Do you believe you can change the source code as much as you want and still call it GNU Parallel? Do you believe you can make significant changes and still call it GNU Parallel? Are you aware that in academia it is tradition to cite research you build upon? Are you aware citations are an important factor for some researchers to have their contract extended? Are you aware that GNU Parallel earlier tried only to have the citation notice in the documentation, but researchers simply did not read this, and thus forgot to cite - not because they did not want to cite, but because they simply were not aware? Are you aware there are plenty of alternatives, if you dislike GNU Parallel (man parallel_alternatives)? /Ole
Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
On Mon, Aug 30, 2021 at 3:38 PM Andreas Tille wrote: : > I admit I also considered a wrapper but with a different functionality: > Simply check whether --citation was used before and if not do so. If you mean a wrapper similar to this, then that would be a compromise I can live with: if [ -t 2 -a ! -e "$HOME/.citation-run" ] ; then # Only run if stderr is a terminal (to avoid breaking scripts) parallel.real --citation touch "$HOME/.citation-run" fi parallel.real "$@" By testing if stderr is redirected this should avoid breaking scripts (e.g. cron jobs or similar). To me it would feel similar to a dialog box, where you have to click "Don't show this again" to continue the first time. This is not that uncommon in graphical tools, so there is some precedence for this. I find it less than optimal, but if we can find common ground on that, it would be a compromise I can live with. /Ole
Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
Ian Turner wrote: > On 8/28/21 7:41 AM, Andreas Tille wrote: >>I updated the patch in Git[1] but did not yet activate it yet. I'm fine >>with uploading parallel with the patch activated if you really think we >>should disrespect the wish of the author and insist on plain GPL text. > > My reading of bug 905674 is that the citation notice has been previously > judged to be incompatible with the DFSG and that's why it was removed. > Also ultimately Debian developers will have to make their own decision, > though if you are asking my personal opinion, I think it would be best to > remove it. The only license that gives you the right to change the source code is GPLv3. #905674 and #915541 refer to the wording of version 20141022. The current wording (20210722) has been cleared by Richard M. Stallman to be compatible with GPLv3. This is because the citation notice is not part of the license, but part of academic tradition (this was not clear in version 20141022). DFSG mentions "The license must not restrict anyone from making use of the program in a specific field of endeavor", and since the academic tradition is not part of the license and since the tradition does not "restrict anyone from making use of the program in a specific field of endeavor", it is hard to see, how you would argue the wording of version 20210722 does not adhere to DFSG (the wording in 20141022 was different, and it is this old wording that is the background for #905674 and referred in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915541#5). If your stance is based on reading #905674 I will encourage you to read the current wording, and argue how the current wording does not adhere to DFSG. If you disagree with Richard M. Stallman's interpretation of GPLv3 and feel the citation notice does not adhere to GPLv3, you should treat the software as if it is not available under GPLv3. And since GPLv3 is the only thing that would give you the right to change it, you would not be allowed to change the software. In other words: If you want to remove the citation notice to make the software compliant with your interpretation of GPLv3, you first have to accept that the software is already compliant with GPLv3, because nothing else gives you the right to change it. And if you accept this, you do not need to change it to make it compliant. Citations are what indirectly fund maintaining GNU Parallel (for details see: https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt). Before the citation notice was implemented hardly anyone cited GNU Parallel, and that would not have been sustainable in the long term. Therefore it is more important to keep the notice than to be included in different distributions. Specifically, it will be preferable to be moved from Debian main to Debian non-free over having the notice removed (and staying in main). In other words: It is preferable having fewer users, who all know they should cite, over having many users, who do not know they should cite. This is because long-term survival with funding is more important than short-term gains in popularity that can be achieved by being distributed as part of a distribution. If the goal had been to get more users, then the license would have been public domain. By removing the citation notice you are knowingly making it harder for me to justify spending time on developing GNU Parallel, and sending a signal to future developers that Debian does not care about their long term survival - only short term benefits to the project. I hope we can agree we want more free software in the future - not less. > I am among those not persuaded by Ole's arguments to the > contrary, in the specific context of the Debian project. If the revised wording (from version 20141022 to version 20210722) does not change your opinion, I feel the only compromise that is acceptable to all the active parties is to keep the citation notice even if this means moving the software from main to non-free. /Ole
Bug#905674: Citation notice FAQ
Hi Kurt Fitzner You question whether software should be cited and if so how? These links suggest: Yes, you should cite software, and if the author suggests a way of citing use that. * https://blog.apastyle.org/apastyle/2015/01/how-to-cite-software-in-apa-style.html * https://libguides.mit.edu/c.php?g=551454&p=3900280 * https://www.software.ac.uk/how-cite-software * https://aut.ac.nz.libguides.com/APA6th/software * https://libguides.rgu.ac.uk/c.php?g=380081&p=2983956 * https://journals.aas.org/policy-statement-on-software/ * https://guides.lib.monash.edu/c.php?g=219786&p=1454293 * https://www.maxqda.com/how-to-cite-maxqda If you feel the benefit from using GNU Parallel is too small to warrant a citation, then prove that by simply using another tool. Here are other examples of software showing how to cite. Some of these refer to peer-reviewed articles - others do not: * https://www.scipy.org/citing.html * https://octave.org/doc/interpreter/Citing-Octave-in-Publications.html (Octave has citation for individual packages, too) * https://stat.ethz.ch/pipermail/r-help/2008-May/161481.html * https://stat.ethz.ch/R-manual/R-devel/library/utils/html/citation.html (R has citation for individual packages, too) * http://www.partek.com/citing-partek-software-in-a-publication/ * http://www.fluortools.com/misc/cite * https://www.maxqda.com/how-to-cite-maxqda * https://www.open-mpi.org/papers/ * https://www.tensorflow.org/about/bib * http://www.fon.hum.uva.nl/paul/praat.html I would think that most people, who appreciate GNU Parallel, would be happy to help funding the development even if it is simply by making a citation. So what really puzzles me is: If you feel very strongly against helping to fund future development of GNU Parallel, why not use an alternative tool? No one forces you to use GNU Parallel. Here is a list of alternatives to help you choose: https://www.gnu.org/software/parallel/parallel_alternatives.html You also pose it might be bad if more software asked for citations. Let us make one thing abundantly clear: The reason for the citing notice in GNU Parallel is _funding_ - not prestige of being cited in an academic journal, as you hint. It has never been a secret and has been explained from the start: https://lists.gnu.org/archive/html/parallel/2013-11/msg6.html If you find another way to pay my salary, so I can continue to devote time to develop GNU Parallel, then I will have no objections to removing the notice. So please help solve that problem. Not only will it please me, but if you find a general solution, many other free software developers will thank you for it. Focusing on how we can get more free software funded is constructive. Focusing on how we can remove funding for existing free software is not. It is unclear to me why you think that funding through citations suddenly will be the prevailing way of funding, if Debian affirms GNU Parallel's version of an 'OK. Do not show this again'-message (just like the GUI-messages this message can be silenced in less than 10 seconds, and if you do not save more than 10 seconds by using GNU Parallel, maybe you should not be using it anyway). First of all, I think that is unrealistic that this sudden change will happen (most other software is financed in different ways). But even if it _did_ happen, then you would be free to use different tools (or develop your own), if you prefer not to cite. To me your email could be summarized as: "I do not want to help fund the development, but I want to reap all the benefits - even if that means killing the long term development." To me it seems it is you whom Nadia Eghbal addresses in https://www.slideshare.net/NadiaEghbal/consider-the-maintainer: "Is it alright to compromise, or even deliberately ignore, the happiness of maintainers so we that can enjoy free and open source software?" == Citation notice FAQ == > Why does GNU Parallel show a citation notice? GNU Parallel is indirectly funded through citations. It is therefore important for the long term survival of GNU Parallel that it is cited. The citation notice makes users aware of this. See also: https://lists.gnu.org/archive/html/parallel/2013-11/msg6.html > Is the citation notice compatible with GPLv3? Yes. The wording has been cleared by Richard M. Stallman to be compatible with GPLv3. This is because the citation notice is not part of the license, but part of academic tradition. Therefore the notice is not adding a term that would require citation as mentioned on: https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation > Do automated scripts break if the notice is not silenced? No. Not a single time has that happened. This is due to the notice only being printed, if the output is to the screen - not if the output is to a file or a pipe. > How do I silence the citation notice? Run this once: parallel --citation It takes less than 10 seconds to do and is thus comparable to an 'OK. Do not show this again'-dial
Bug#905674: GNU Parallel patch
Dear Didier Thanks for help organizing the BSP in Bern. I have noticed that you have submitted a patch and closed this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905674#77 I am sure you are trying to do what is best for free software. But what looks like a good idea in the short run, may be a bad idea in the long run. The long term survival of Debian depends on others building free software that can be packaged, so destroying these people's livelihood is a bad long term strategy. In the reasoning for the patch you state: > Quoting the gpl-faq: [... https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation ...] > Therefore, removing this to make parallel GPL-compliant. I think this is due to a misunderstanding. Maybe you not aware that Richard M. Stallman together with the GNU leaders have cleared the wording and the use of the citation notice, and that he sees it as complying fully with GPLv3? And thus not in conflict with https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation The reasoning why there is no conflict is because citing is a matter of honor - not law. Thus it does not restrict anyone from making use of the program in a specific field of endeavor, but simply conveys that you will be taking away future funding for development if you do not cite. The mail from RMS is included below. Your patch therefore does not change the GPLv3-compliancy: The code was already compliant. But what your patch *does* do, is to make it harder to earn a living from developing GNU Parallel and will make it much harder for me to justify spending time maintaining GNU Parallel. Please help building more free software instead of attacking the developer's livelihood. Not everyone is so lucky that they are hired in a company where you get paid to develop free software. As Nadia Eghbal puts it in https://www.slideshare.net/NadiaEghbal/consider-the-maintainer: "Is it alright to compromise, or even deliberately ignore, the happiness of maintainers so we that can enjoy free and open source software?" This describes very well what you are doing with the patch, and I refuse to think that was your goal. So if you want to help other developers make a living and thereby get more free software made, I encourage you to revert the patch and instead upgrade to 20180922: Maybe you simply were not aware that the latest stable version (20180922) is *already* GPLv3 compliant. Thanks for your work on free software. It is appreciated. /Ole On Wed, Oct 17, 2018 at 9:07 AM Richard Stallman wrote: > > [[[ To any NSA and FBI agents reading my email: please consider]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > GNU leaders studied looked at the current version of GNU Parallel. > Based on their report, I've concluded there is no problem in it. : > -- > Dr Richard Stallman > President, Free Software Foundation (https://gnu.org, https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org)
Bug#905674: Ready for closing?
Upgrading from 20141022 to 20180922 seems to address all issues. Can we close this ticket? #884793 was due to user error, thus not breaking scripts. I still have not seen a single situation in which the current behaviour (version 20180922) breaks scripts when used correctly. Make a Minimal, Complete, Verifiable Example to change my mind. --citation was never designed to be used with any other parameter, but only to be run on its own: parallel --citation : > will cite After running this the citation notice is silenced for future runs. In other words: It is optional and takes literally less than 10 seconds to do; thus it is comparable to clicking 'OK, do not show this message again' in a GUI tool. The current (version 20280922) wording of the citation notice has been cleared by Richard M. Stallman and is deemed not in conflict with https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation because citing is a matter of honor - not law. Thus it does not restrict anyone from making use of the program in a specific field of endeavor, but simply conveys that you will be taking away future funding for development if you do not cite. As Nadia Eghbal puts it in https://www.slideshare.net/NadiaEghbal/consider-the-maintainer: "Is it alright to compromise, or even deliberately ignore, the happiness of maintainers so we that can enjoy free and open source software?" /Ole
Bug#884793: Use --citation the correct way
You are using --citation in a way it was never designed to be used. This is why you feel it breaks your script. It is like complaining you get control characters in the output if you run 'ls --color=always > output'. --citation was never designed to be used with any other parameter, but only to be run on its own: parallel --citation : > will cite After running this the citation notice is silenced for future runs. In other words: It takes literally less than 10 seconds to do; thus it is comparable to clicking 'OK, do not show this message again' in a GUI tool. Newer versions print a warning, if you use '--citation' with other arguments, and the man page states: | Print the citation notice and BibTeX entry for GNU parallel, silence | citation notice for all future runs, and exit. It will not run any | commands. The current wording of the citation notice has been cleared by Richard M. Stallman and is deemed not in conflict with https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation because citing is a matter of honor - not law. If you consider yourself an honorable person and you publish peer reviewed articles that uses GNU Parallel, then you should cite. If you consider yourself a dishonorable person and you publish peer reviewed articles that uses GNU Parallel, then you will probably not cite. But if you object to citing, why not do the honorable thing and either build your own tool, fund the project by paying, or simply use another tool? There are plenty other tools; see `man parallel_alternatives`. If you do not publish peer reviewed articles, the notice does not apply to you. Funding a free software project is hard. GNU parallel is no exception. On top of that it seems the less visible a project is, the harder it is to get funding. And the nature of GNU parallel is that it will never be seen by "the guy with the checkbook", but only by the people doing the actual work. This problem has been covered by others - though no solution has been found: https://www.numfocus.org/blog/why-is-numpy-only-now-getting-funded/ As Nadia Eghbal puts it in https://www.slideshare.net/NadiaEghbal/consider-the-maintainer: "Is it alright to compromise, or even deliberately ignore, the happiness of maintainers so we that can enjoy free and open source software?" Before implementing the citation notice it was discussed with the users: https://lists.gnu.org/archive/html/parallel/2013-11/msg6.html Having to spend 10 seconds on running 'parallel --citation' once is not an ideal solution, but no one has so far come up with an ideal solution - neither for funding GNU parallel nor other free software. If you believe you have the perfect solution, you should try it out, and if it works, you should post it on the email list. Ideas that will cost work and which have not been tested are, however, unlikely to be prioritized. Running 'parallel --citation' one single time takes less than 10 seconds, and will silence the citation notice for future runs. If that is too much trouble for you, why not use one of the alternatives instead? See a list in: man parallel_alternatives. Citations make it possible to get a job that can pay for the development of GNU Parallel. If you want to see more free software be developed, then help funding it. Citations are a very cheap way of doing that. /Ole
Bug#905674: Funding free software
Funding a free software project is hard. GNU Parallel is no exception.
On top of that it seems the less visible a project is, the harder it
is to get funding. And the nature of GNU Parallel is that it will
never be seen by "the guy with the checkbook", but only by the people
doing the actual work.
This problem has been covered by others - though no solution has been
found: https://www.slideshare.net/NadiaEghbal/consider-the-maintainer
https://www.numfocus.org/blog/why-is-numpy-only-now-getting-funded/
"Is it alright to compromise or even deliberately ignore the happiness
of the maintainers so that we can enjoy free and open source
software?"
(Slide 8 from: https://www.slideshare.net/NadiaEghbal/consider-the-maintainer)
Before implementing the citation notice it was discussed with the
users: https://lists.gnu.org/archive/html/parallel/2013-11/msg6.html
There is no doubt that this is not an ideal solution, but no one has
so far come up with an ideal solution - neither for funding GNU
Parallel nor other free software.
If you believe you have the perfect solution, you should try it out,
and if it works, you should post it on the email list. Ideas that will
cost work and which have not been tested are, however, unlikely to be
prioritized.
The notice in question:
"""
Academic tradition requires you to cite works you base your article on.
If you use programs that use GNU Parallel to process data for an article in a
scientific publication, please cite:
@book{tange_ole_2018_1146014,
author = {Tange, Ole},
title= {GNU Parallel 2018},
publisher= {Ole Tange},
month= Mar,
year = 2018,
ISBN = {9781387509881},
doi = {10.5281/zenodo.1146014},
url = {https://doi.org/10.5281/zenodo.1146014}
}
(Feel free to use \nocite{tange_ole_2018_1146014})
This helps funding further development; AND IT WON'T COST YOU A CENT.
If you pay 1 EUR you should feel free to use GNU Parallel without
citing.
More about funding GNU Parallel and the citation notice:
https://www.gnu.org/software/parallel/parallel_design.html#Citation-notice
If you send a copy of your published article to ta...@gnu.org, it will
be
mentioned in the release notes of next version of GNU Parallel.
"""
As you can see the citation notice is carefully worded so that it is
not a legal requirement. It was revised in collaboration with RMS to
make sure it was compatible with GPLv3. The notice does not deny users
the ability to use the software as they wish, for whatever purpose
they wish, without payment. It does, however, make it clear what the
wishes of the author are.
There have been rumours that the citation notice broke scripts, but
these rumours have never been backed up by evidence - so an actual
MCVE has never been shown.
As long as we have not found the perfect way of earning a living from
free software, we should try out as many methods as possible. Some
will try one method, and others will try another. If we find a way to
pay my salary I will be happy to remove the notice. And if we manage
to find a general way to fund development of free software, a lot more
developers will be happy, and we will be able to put Nadia Eghbal's
quote in the past:
"Is it alright to compromise or even deliberately ignore the happiness
of the maintainers so that we can enjoy free and open source
software?"
/Ole
On Fri, Aug 10, 2018 at 4:52 AM, Rogério Brito wrote:
> Dear Ole (and others potentially interested in having GNU Parallel in
> Debian's and derivatives' repositories),
>
> I don't know if you have been following the emails on the Debian BTS
> regarding GNU Parallel having restrictions regardings its distribution etc.
>
> Since this issue has surfaced itself once again, but now in a more intense
> manner, I believe that, if you have not yet been informed, you may want to
> give your opinion (and I will decide how I should follow my maintainership
> within the constraints of your software and the contraints of Debian).
>
> Thanks,
>
> Rogério Brito...
>
> On Aug 08 2018, Adam Borowski wrote:
>> Actually, it seems to me it's not even distributable.
>>
>> The wording sounds like a requirement rather than something non-mandatory --
>> reinforced by providing the alternative of paying €1. Yet the license
>> is GPL3+, which expressly forbids additional fees. This is even described
>> in FSF's GPL FAQ:
>> https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation
>>
>> Thus, the copyright holder can distribute this software, but no one else
>> can.
>>
>> As the requirement is not a part of the license, we could just remove the
>> demand nagware from the code. But alas, the upstream (Ole Tange) threatened
>> legal action
Bug#864647: Patch
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot
2015-01-22 22:03:47.0 +0100
+++ /root/cryptroot.new 2017-06-12 13:14:13.031995434 +0200
@@ -277,7 +277,20 @@
export CRYPTTAB_TRIED="$count"
count=$(( $count + 1 ))
+ /bin/sleep 3
+
if [ -z "$cryptkeyscript" ]; then
+ # Test all devices
+ mkdir /mnt
+ echo -n "Searching for cryptkey.txt on
available disks... "
+ for PART in `cat /proc/partitions |awk '{print
$4}'|tail -n +3`; do
+ if mount /dev/$PART /mnt 2>/dev/null; then
+ cat /mnt/cryptkey.txt >>
/tmp/cryptkeys.txt 2>/dev/null
+ umount /dev/$PART
+ fi
+done
+ echo "done."
+
if [ ${cryptsource#/dev/disk/by-uuid/} !=
$cryptsource ]; then
# UUIDs are not very helpful
diskname="$crypttarget"
@@ -297,10 +310,29 @@
if [ ! -e "$NEWROOT" ]; then
- if ! crypttarget="$crypttarget"
cryptsource="$cryptsource" \
-$cryptkeyscript "$cryptkey" | $cryptopen; then
+ keyfound=0
+ if [ -e /tmp/cryptkeys.txt ] ; then
+ echo Trying keys from cryptkey.txt
+ for key in `cat /tmp/cryptkeys.txt`; do
+ if crypttarget="$crypttarget"
cryptsource="$cryptsource" \
+ echo -n "$key" | $cryptopen; then
+# Found the key
+ echo Key found in cryptkey.txt
+ keyfound=1
+key=""
+ fi
+ done
+ # Remove traces of the key
+rm /tmp/cryptkeys.txt
+ unset key
+ fi
+ if [ "$keyfound" = "0" ]; then
+ # Fall back to manual entry
+ if ! crypttarget="$crypttarget"
cryptsource="$cryptsource" \
+ $cryptkeyscript "$cryptkey" | $cryptopen; then
message "cryptsetup: cryptsetup failed,
bad password or options?"
continue
+ fi
fi
fi
Bug#864647: cryptsetup: Patch to get cryptokey from external device (e.g. USB stick)
Package: cryptsetup Version: 2:1.6.6-5 Severity: wishlist Dear Maintainer, I use cryptosetup so that I can send disks for repairs without worrying about confidential data on the disks. I would love to use cryptsetup on servers, but I need to be able to reboot the servers without having to enter the passphrase. It would be ideal to me if I could simply have a small USB stick containing a passphrase that will unlock the disk. Not only would that be handy for servers (where you could leave the USB stick in the server), it would also be great for my laptop: Insert the USB stick when booting and remove it after unlocking the cryptodisk. I have now written a patch that will search all devices for the file 'cryptkey.txt' and try decrypting with each line as a key. The patch is released under the same license as /usr/share/initramfs-tools/scripts/local-top/cryptroot I am aware of the “passdev” keyscript (/usr/share/doc/cryptsetup/README.initramfs.gz section 10). My patch has the following advantages: * It searches every partition being connected. This gives 2 advantages: - You do not need to change the line in cryptsetup, but can have that be the same for all servers. - You do not need to remember the label of the USB-disk if the USB-disk breaks. * It tries all lines as a key. This way you can unlock many machines with different keys with a single USB-disk. * It is easy to get working. Creating a USB-disk with the key can be done on a Microsoft Windows machine with no special software. So even beginners can do this. * It is safe: Trying to get passdev to work I managed to make my server unbootable - it got stuck in a loop looking for the USB-disk, and it never gave me the option to enter the key manually even though I had put in a 10 seconds timeout. It took an hour to get the system working again - and I never got passdev to work. With my patch you simply enter the passphrase as normally, if the automation fails. (I was unable to reopen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746806) /Ole -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/nlv-root ro quiet -- /etc/crypttab #sda5_crypt UUID=b5da252b-d4ce-4c8b-9274-1dc6b53cbf5b none luks luks-b5da252b-d4ce-4c8b-9274-1dc6b53cbf5b UUID=b5da252b-d4ce-4c8b-9274-1dc6b53cbf5b none luks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/nlv-root / ext4errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=944f19d7-138a-4270-b42f-a5322a57b047 /boot ext2defaults 0 2 /dev/mapper/nlv-swap_1 noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sdb1 /media/usb0 autorw,user,noauto 0 0 /dev/sdb2 /media/usb1 autorw,user,noauto 0 0 #LABEL=freeagent /mnt/freeagent autorw,relatime,data=journal,auto 0 0 LABEL=freeagent /mnt/freeagent autorw,relatime,data=ordered,auto 0 0 #LABEL=freeagent /mnt/freeagent autorw,relatime,data=writeback,auto 0 0 tmpfs /mnt/ram tmpfs rw,noexec,nosuid,size=5%,mode=1777 0 0 -- lsmod Module Size Used by xt_nat 12601 1 xt_tcpudp 12527 3 veth 13095 0 xt_conntrack 12681 1 ipt_MASQUERADE 12594 2 iptable_nat12646 1 nf_conntrack_ipv4 18448 2 nf_defrag_ipv4 12483 1 nf_conntrack_ipv4 nf_nat_ipv412912 1 iptable_nat xt_addrtype12557 2 iptable_filter 12536 1 ip_tables 21711 2 iptable_filter,iptable_nat x_tables 27399 7 ip_tables,xt_tcpudp,ipt_MASQUERADE,xt_conntrack,xt_nat,iptable_filter,xt_addrtype nf_nat 18241 4 ipt_MASQUERADE,nf_nat_ipv4,xt_nat,iptable_nat nf_conntrack 87424 6 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,xt_conntrack,iptable_nat,nf_conntrack_ipv4 bridge106162 0 stp12437 1 bridge llc12745 2 stp,bridge aufs 199570 277 cpufreq_powersave 12454 0 binfmt_misc16949 1 cpufreq_stats 12782 0 cpufreq_userspace 12525 0 cpufreq_conservative14184 0 bnep 17431 2 nfsd 262938 2 auth_rpcgss51209 1 nfsd oid_registry 12419 1 auth_rpcgss nfs_acl12511 1 nfsd nfs 192232 0 lockd 83389 2 nfs,nfsd fscache45542 1 nfs sunrpc237406 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl ecb12737 1 btusb 29721 0 bluetooth 374429 2
Bug#746806: cryptsetup: Patch to get cryptokey from external device (e.g. USB stick)
Package: cryptsetup
Version: 2:1.4.3-4
Severity: wishlist
Dear Maintainer,
I use cryptosetup so that I can send disks for repairs without worrying about
confidential data on the
disks. I would love to use cryptsetup on servers, but I need to be able to
reboot the servers without
having to enter the passphrase.
It would be ideal to me if I could simply have a small USB stick containing a
passphrase that will
unlock the disk. Not only would that be handy for servers (where you could
leave the USB stick in the
server), it would also be great for my laptop: Insert the USB stick when
booting and remove it after
unlocking the cryptodisk.
I have now written a patch that will search all devices for the file
'cryptkey.txt' and try decrypting
with each line as a key.
The patch is released under the same license as
/usr/share/initramfs-tools/scripts/local-top/cryptroot
Regards,
Ole Tange
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot 2012-11-16
09:24:09.0 +0100
+++ /tmp/cryptroot 2014-05-03 21:52:18.537256317 +0200
@@ -263,11 +263,19 @@
while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do
count=$(( $count + 1 ))
- if [ $count -gt 1 ]; then
- /bin/sleep 3
- fi
+ /bin/sleep 3
if [ -z "$cryptkeyscript" ]; then
+ # Test all devices
+ mkdir /mnt
+ echo -n "Searching for cryptkey.txt on available
disks... "
+ for PART in `cat /proc/partitions |awk '{print
$4}'|tail -n +3`; do
+ if mount /dev/$PART /mnt 2>/dev/null; then
+ cat /mnt/cryptkey.txt >> /tmp/cryptkeys.txt
2>/dev/null
+ umount /dev/$PART
+ fi
+done
+ echo "done."
cryptkey="Unlocking the disk $cryptsource
($crypttarget)\nEnter passphrase: "
if [ -x /bin/plymouth ] && plymouth --ping; then
cryptkeyscript="plymouth ask-for-password
--prompt"
@@ -279,10 +287,24 @@
if [ ! -e "$NEWROOT" ]; then
- if ! crypttarget="$crypttarget"
cryptsource="$cryptsource" \
+ KEYFOUND=0
+ if [ -e /tmp/cryptkeys.txt ] ; then
+ echo Trying keys from cryptkey.txt
+ for KEY in `cat /tmp/cryptkeys.txt`; do
+ if crypttarget="$crypttarget"
cryptsource="$cryptsource" \
+ echo -n $KEY | $cryptcreate --key-file=- ;
then
+ # Found the key
+ echo Key found in cryptkey.txt
+ KEYFOUND=1
+ KEY=""
+ fi
+ done
+ rm /tmp/cryptkeys.txt
+ fi
+ if [ "$KEYFOUND" = "0" ]; then
+ if ! crypttarget="$crypttarget"
cryptsource="$cryptsource" \
$cryptkeyscript "$cryptkey" | $cryptcreate
--key-file=- ; then
message "cryptsetup: cryptsetup failed, bad
password or options?"
continue
+ fi
fi
fi
-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/nlv-root ro quiet
-- /etc/crypttab
sda5_crypt UUID=b5da252b-d4ce-4c8b-9274-1dc6b53cbf5b none luks
-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/nlv-root / ext4errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=944f19d7-138a-4270-b42f-a5322a57b047 /boot ext2defaults
0 2
/dev/mapper/nlv-swap_1 noneswapsw 0 0
/dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/sdb1 /media/usb0 autorw,user,noauto 0 0
/dev/sdb2 /media/usb1 autorw,user,noauto 0 0
-- lsmod
Module Size Used by
parport_pc 22364 0
ppdev 12763 0
lp 17149 0
parport31858 3 lp,ppdev,parport_pc
bnep 17567 2
Bug#710482: autofs: Stale NFS handle - if server is rebooted
Package: autofs Version: 5.0.7-3 Severity: normal Dear Maintainer, * What led up to the situation? I use autofs for /net to automount NFS dirs from servers. When a dir is mounted via NFS from a server that is rebooted, I sometimes get Stale NFS file handle. A simple 'umount -l' run by hand clears that error. But it would be nice if autofs could deal with this. The solution could be as crude as doing a stat on the automounted dirs now and then, and if you get Stale NFS file handle do an 'umount -l'. You probably have even better ideas. * What exactly did you do (or not do) that was effective (or ineffective)? When a dir is mounted via NFS from a server that is rebooted, I sometimes get Stale NFS file handle. A simple 'umount -l' run by hand clears that error. But it would be nice if autofs could deal with this. * What was the outcome of this action? I had expected the dir to be available. * What outcome did you expect instead? No error. -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/48 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages autofs depends on: ii libc6 2.13-38 ii libxml22.8.0+dfsg1-7+nmu1 ii multiarch-support 2.13-38 ii ucf3.0025+nmu3 Versions of packages autofs recommends: ii kmod 9-3 ii module-init-tools 9-3 ii nfs-common 1:1.2.6-3 autofs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695205: aptitude install name_of_the_missing_file should find the package of name_of_the_missing_file and install it
Package: aptitude Version: 0.6.8.1 Severity: wishlist I often experience some program depend on a file. I then have to locate which package may contain the file and then install the package. It looks like this: $ foo Could not load library: libglut.so.3: cannot open shared object file: No such file or directory. $ apt-file search libglut.so.3 freeglut3: /usr/lib/x86_64-linux-gnu/libglut.so.3 freeglut3: /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0 $ sudo aptitude install freeglut3 It would be nice if I did not have to go through apt-file to locate the package, but that I instead simply could do: $ sudo aptitude install libglut.so.3 If multiple packages contain libglut.so.3 then aptitude should ask me to select one of them. /Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688929: parallel: config file leads to non-standard behaviour
On Thu, Nov 22, 2012 at 11:31 PM, Dirk Eddelbuettel wrote: > > I, for one, stopped using parallel my scripts have to work across distros. --gnu is made for that situation (--gnu takes precedence over --tollef). /Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561938: Does maintainer want patch for size of buffer?
On Wed, May 23, 2012 at 7:19 AM, Martin Buck wrote: > Hi Ole, > > a patch would be great if it also includes changes to the man page > mentioning the buffer limit, the kernel limit, how to tune the latter and > the error message you get if it is exceeded. What would you suggest as the > new maximum block size? If I read the code correctly it costs nothing to set the maximum block size to max of 64-bit integer. > The more fundamental problem is that SysV-style shared memory really doesn't > seem to be made for such large amounts of shared memory (which is probably > why the kernel has such low limits as well). The right way to proceed would > be to switch to more modern mechanisms like mmap(), but I guess that's a > larger amount of work. A patch for that would be most welcome. The 64-bit limit might not work on all systems, but I find it ridiculous that it is 'buffer' and not the system that sets the limit. It seems 'mbuffer -q' can be used instead, but it seems to be slower than 'buffer'. With -t it does memory mapped temporary files. /Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561938: Does maintainer want patch for size of buffer?
Hi Martin Buck. We are some users who would like buffer to be able to handle much bigger buffers. If we make a patch will you then accept this patch and apply it? /Ole -- Did you get your GNU Parallel merchandise? https://www.gnu.org/software/parallel/merchandise.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671798: parallel: Passing args from command line is borked
On Mon, May 7, 2012 at 4:10 AM, Ian Zimmerman wrote: > Rogério> GNU parallel, to be compatible, also exposes that behavior, > Rogério> when invoked with the --tollef option. Otherwise, it is the > Rogério> pure GNU parallel behaviour. > > Rogério> The default behavior in Debian was chosen to be --tollef as > Rogério> moreutils's presence in Debian predated GNU parallel for some > Rogério> time and to not interfere with users that happen to have both > Rogério> moreutils and GNU parallel installed. > > I see. I mistakenly thought this dual personality was a Debian > invention. As it is it's clearly an upstream bug, they should document > it in the manpage or at least in the README. It is assumed that you do not enable --tollef by accident, and you only enable it to get compatibility with Tollef's parallel (i.e. you know what you are doing). That is why there is a warning when you run: parallel --version (with --tollef enabled in /etc/parallel/config) which you - according to documentation - must do before filing a bug report. I am somewhat annoyed that --tollef gives me more support work. --tollef was implemented to _avoid_ more support work by providing backwards compatibility to existing Tollef's parallel users to ease their migration to GNU Parallel. But if --tollef proves to give me more support work it might be preferable to retire that option. I would tend to agree with Ian: If I had explicitly asked to get GNU Parallel installed I would not expect it to go into tollef mode (It will be fair to call me biased here). /Ole -- Did you get your GNU Parallel merchandise? https://www.gnu.org/software/parallel/merchandise.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518696: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
On Wed, Mar 11, 2009 at 5:34 PM, Samuel Thibault wrote: > Ole Tange, le Wed 11 Mar 2009 17:05:34 +0100, a écrit : >> One of friends alerted me to your discussion of 'parallel' and whether >> other tools can replace it. > > The question could also be rephrased: can't we just extended xargs into > supporting what parallel does? Having two separate tools will always > make arguments about "A does this, B doesn't" and vice-versa, while > xargs could just do everything. When I started coding 'parallel' I thought of extending 'xargs' for exactly the same reason. I decided against it for two reasons: * My C-skills are rusty and I never really liked C, so I would have to convince someone else to write it. * I would not be able to change xargs so it became incompatible with the current version of xargs. This would make it impossible to change the default behaviour of xargs to something that would make sense 99% of the time. xargs default of treating printf "foo bar" | xargs echo the same as: printf "foo\nbar" | xargs echo is not what I want in 99% of the cases. In 90% of the cases I do not care, and the the last 9% I get burned by the behaviour. I have been burned quite a few times by xargs for not dealing nicely with input that is \n separated but which contains interesting characters such as space or '. parallel's primary purpose was to be run interactively for things that are only to be run once; if running the same input with xargs requires a lot of pre+postprocessing and special options, then it is easier to extend parallel to include what xargs does (BTW next version of parallel will support -x which will insert as many arguments as command line length permits). I believe the man page of xargs shows a good example of the problem of xargs not doing what the user expects. The first example says: find /tmp -name core -type f -print | xargs /bin/rm -f Find files named core in or below the directory /tmp and delete them. Note that this will work incorrectly if there are any filenames containing newlines or spaces. But even the man page writer forgets that if any of the dirs contain a ' or a ` or a " you still have to remember -0. If a dir is called "\\'" then xargs will not even complain but silently fail to remove the file. To me the default should work in most cases and not cause the user to rethink the strategy. On my alpha testers I tried out different defaults to get to a default setting that would do what they expected in most cases. /Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518696: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
One of friends alerted me to your discussion of 'parallel' and whether
other tools can replace it. Here are some good examples to try to
reproduce without 'parallel':
$ ls | grep abc | parallel gzip -c >/tmp/file.gz
Try this in a dir with 1000 50 kB sized mixed files with file names
that include these characters: [-'` "+*<>&$!?|]. The output is a valid
.gz file as the output is grouped. In other solutions not using
parallel you will often have a race condition (such as running two
cat's in parallel).
$ ls | parallel diff {} foo ">"{}.diff
$ ls | parallel 'echo -n {}" "; ls {}|wc -l'
These should also be run on files with names containing interesting
characters [-'` "+*<>&$!?|].
$ seq 1 255 | parallel -j 50 'ping -c 1 10.0.0.{} && wget
http://status-server/status.cgi?ip=10.0.0.{}'
The 3 above would normally require making a script and calling it. I
have yet to see how to do that on the command line (including the
parallelization).
$ cat shellscript
ls foo
touch bar
host foo.bar
ping bar.foo
seq 1 10 | ssh foo.bar "cat >/tmp/count"
wget http://foo.bar/info
[...100 other one line shell commands...]
$ cat shellscript | time sh
$ cat shellscript | time parallel
This one of the ways I use 'parallel' most with the shellscript often
being generated.
There are more examples in the man-page.
I am the author of 'parallel'
/Ole
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#485924: poster: Manual for -P is wrong
Package: poster Version: 1:20050907-1 Severity: minor The manual for -P says: -P Specify which pages of the poster to print. It consists of a comma-separated list of single pages or page ranges (using the dash). The order in which page number appears determines the final page order in the result PostScript file. Page numbering starts at 1, from left to right and bottom-up. Examples: 1-2 or 1,3-4,7 However, the actual ordering seems to be: bottom-up, right-to-left. That is very non-intuitively to me, so I consider making a patch that changes the ordering to the European way to read text: left-to-right, top-to-bottom. Would you include such a patch? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages poster depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libpaper1 1.1.23 library for handling paper charact poster recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485910: Comment changed
In this patch the comment is changed to describe the function.
/Ole
--- poster-20050907/poster.c 2008-06-10 19:10:13.0 +0200
+++ poster-nodupPS/poster.c 2008-06-12 10:10:07.0 +0200
@@ -831,6 +831,7 @@
printf ("%% Print poster %s in %dx%d tiles with %.3g magnification\n",
infile, nrows, ncols, scale);
}
+static void definepage();
/*/
/* output the poster, create tiles if needed */
@@ -840,6 +841,7 @@
int row, col, page;
printprolog();
+ definepage();
if ( pages == NULL )
for ( page = 0; page < number_pages; page++ )
for (row = 1; row <= nrows; row++)
@@ -977,6 +979,18 @@
printf( "EndSetup\n");
}
+/***/
+/* define a PS function to print the original page */
+/***/
+static void definepage()
+{
+ printf("/theoriginalpage {\n");
+ printf("BeginDocument: %s\n", infile);
+ printfile(0);
+ printf("\nEndDocument\n");
+ printf("} def\n");
+}
+
/*/
/* output one tile at a time */
/*/
@@ -988,9 +1002,7 @@
printf ("\nPage: (%d,%d) %d\n", pagetoprint+1, ((row-1)*ncols+col), page);
printf ("%d %d tileprolog\n", row, col);
- printf ("BeginDocument: %s\n", infile);
- printfile (pagetoprint);
- printf ("\nEndDocument\n");
+ printf ("theoriginalpage\n");
printf ("tileepilog\n");
page++;
Bug#485910: poster: Request for enhancement: Do not duplicate PS-code for every page
Package: poster
Version: 1:20050907-1
Severity: wishlist
poster duplicates all input for every page in the poster, so a 3x3
poster will take up 9 times the original PostScript code.
I have made a patch that solves this.
/Ole
--- poster-20050907/poster.c2008-06-10 19:10:13.0 +0200
+++ poster-nodupPS/poster.c 2008-06-10 19:14:34.0 +0200
@@ -831,6 +831,7 @@
printf ("%% Print poster %s in %dx%d tiles with %.3g magnification\n",
infile, nrows, ncols, scale);
}
+static void definepage();
/*/
/* output the poster, create tiles if needed */
@@ -840,6 +841,7 @@
int row, col, page;
printprolog();
+ definepage();
if ( pages == NULL )
for ( page = 0; page < number_pages; page++ )
for (row = 1; row <= nrows; row++)
@@ -977,6 +979,18 @@
printf( "EndSetup\n");
}
+/***/
+/* output PS prolog of the scaling and tiling routines */
+/***/
+static void definepage()
+{
+ printf("/theoriginalpage {\n");
+ printf("BeginDocument: %s\n", infile);
+ printfile(0);
+ printf("\nEndDocument\n");
+ printf("} def\n");
+}
+
/*/
/* output one tile at a time */
/*/
@@ -988,9 +1002,7 @@
printf ("\nPage: (%d,%d) %d\n", pagetoprint+1, ((row-1)*ncols+col),
page);
printf ("%d %d tileprolog\n", row, col);
- printf ("BeginDocument: %s\n", infile);
- printfile (pagetoprint);
- printf ("\nEndDocument\n");
+ printf ("theoriginalpage\n");
printf ("tileepilog\n");
page++;
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages poster depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libpaper1 1.1.23 library for handling paper charact
poster recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480775: xserver-xorg-video-intel: ver 2:2.2.1-2 breaks Virtual > 2048
On 5/12/08, Julien Cristau <[EMAIL PROTECTED]> wrote: > severity 480775 important > close 480775 2:2.3.0-1 > kthxbye > > On Mon, May 12, 2008 at 01:44:51 +0200, Ole Tange wrote: > > > Package: xserver-xorg-video-intel > > Version: 2:2.2.1-2 > > Severity: grave > > Justification: renders package unusable > > No it doesn't. You are probably right on some systems. On this system it was actually worse: It made it impossible log into the system using gdm, as the Virtual feature is used - and thereby rendered the whole system unusable for users that do not know how to use the command line. Note that the system is _not_ running unstable (in which case you would expect problems like that now and again) but it is running testing. > > This problem seems to be fixed in 2:2.3.0-1. > > > > I suggest either downgrading xserver-xorg-video-intel to 2:2.1.0-2 or > > upgrading to 2:2.3.0-1. > > > 2.3.1 should be out soon, at which point it will probably be uploaded to > unstable. The faulty package should never have made it into testing. Ignoring the problem and leaving it in testing will cause others to have this problem, too. /Ole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480775: xserver-xorg-video-intel: ver 2:2.2.1-2 breaks Virtual > 2048
Package: xserver-xorg-video-intel Version: 2:2.2.1-2 Severity: grave Justification: renders package unusable xserver-xorg-video-intel version 2:2.2.1-2 crashes if Virtual is > 2048. This problem seems to be fixed in 2:2.3.0-1. I suggest either downgrading xserver-xorg-video-intel to 2:2.1.0-2 or upgrading to 2:2.3.0-1. /Ole -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 2007-06-28 16:53 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1674940 2008-04-29 20:37 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 6874 2008-05-12 01:33 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # Run this before: #915resolution 58 1400 1050 32 # # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load"i2c" Load"bitmap" Load"ddc" ## Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "dk" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection Section "InputDevice" Driver"wacom" Identifier"stylus" Option"Device""/dev/ttyS0" Option"Type" "stylus" Option"ForceDevice" "ISDV4" Option"Tilt" "on" Option "PressCurve" "50,0,100,50" EndSection Section "InputDevice" Driver"wacom" Identifier"eraser" Option"Device""/dev/ttyS0" Option"Type" "eraser" Option"ForceDevice" "ISDV4" Option"Tilt" "on" EndSection Section "InputDevice" Driver"wacom" Identifier"cursor" Option"Device""/dev/ttyS0" Option"Type" "cursor" Option"ForceDevice" "ISDV4" Option"Tilt" "on" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents""true" # Option "Device""/dev/psaux" Option "Device""/dev/input/mouse0" Option "Protocol" "auto-dev" Option "HorizScrollDelta" "0" Option "MinSpeed" "0.09" Option "MaxSpeed" "0.78" Option "AccelFactor" "0.015" Option "MaxTapTime""180" Option "MaxTapMove""220" Endsection Section "InputDevice" Driver "synaptics" Identifier "Synaptics
