Re: Whatever happened to apt-sync?
Evan wrote: IIRC, it was going to provide delta updates. Smaller server load, smaller downloads, etc. It's a great idea, but seems to be dead. All of the pages I can find that mention it are early 2007. Is there any particular reason that it never went anywhere? In 2006 I participated in summer of code to implement this, the project website is: https://launchpad.net/apt-sync The code is functional and I'm using it successfully on my home computer (usually saving around 50-90% on minor updates and 30% on a dist-upgrade), however I do not have resources available to distribute aptsync files, so it's not possible for me to perform any wide-scale testing. The issue is: AptSync requires a repository of `.aptsync' files to be stored server-side. These .aptsync files store control information about each file in the actual Ubuntu repository. To host such a repository, the following would be required: * Local access to a complete and up-to-date Ubuntu mirror * The ability to run `aptsyncmake' (Python) to construct .aptsync files for every file in the mirror * Webspace to store the repository. A rough estimate of space required is 50-100MB, and it need not be stored in the original repository tree (or even on the same server) If anyone has the above resources and would be willing to help me get this project into swing, then I'd be happy to hear! Alternatively, I've been toying with the idea of setting up a mechanism to automatically create and distribute aptsync files via peer-to-peer. Felix -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Whatever happened to apt-sync?
On Sat, Jun 28, 2008 at 5:33 AM, Felix Feyertag [EMAIL PROTECTED] wrote: In 2006 I participated in summer of code to implement this, the project website is: https://launchpad.net/apt-sync The code is functional and I'm using it successfully on my home computer (usually saving around 50-90% on minor updates and 30% on a dist-upgrade), however I do not have resources available to distribute aptsync files, so it's not possible for me to perform any wide-scale testing. The issue is: AptSync requires a repository of `.aptsync' files to be stored server-side. These .aptsync files store control information about each file in the actual Ubuntu repository. To host such a repository, the following would be required: * Local access to a complete and up-to-date Ubuntu mirror * The ability to run `aptsyncmake' (Python) to construct .aptsync files for every file in the mirror * Webspace to store the repository. A rough estimate of space required is 50-100MB, and it need not be stored in the original repository tree (or even on the same server) If anyone has the above resources and would be willing to help me get this project into swing, then I'd be happy to hear! Alternatively, I've been toying with the idea of setting up a mechanism to automatically create and distribute aptsync files via peer-to-peer. Felix If the code is functional, shouldn't this be pushed to Ubuntu to be used by their repositories? Or would the CPU drain for aptsyncmake on that many packages be too much? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Compiling subversion 1.5.0
I finally made the sources built correctly.
First I used the Intrepid sources instead of the debian sources.
https://launchpad.net/ubuntu/intrepid/+source/subversion/1.5.0dfsg1-1ubuntu2
But this was not the problem.
As you said correctly, the problem was that the headers of the nested
classes were not created.
So I created the headers myself using javah. But javah inserted a
constant 0024 into the names that were defined inside the header file
which I had to remove manually.
There is a patch attached which creates these headers.
So with this patch the libsvn-java packages is built successfully.
I am very thankful for your help!
Jason Crain schrieb:
It first compiles the .java files using javac, then creates header
files using javah. It skips several header files, including
org_tigris_subversion_javahl_ConflictDescriptor_Action.h, probably
because it is an inner class of ConflictDescriptor. The $ used to
mark inner classes may be confusing it?
You can create the files manually using javah:
javah -d subversion/bindings/javahl/include -classpath \
subversion/bindings/javahl/classes \
'org.tigris.subversion.javahl.ConflictDescriptor$Action'
And then rename it to what it expects:
mv
subversion/bindings/javahl/include/org_tigris_subversion_javahl_ConflictDescriptor\$Action.h
subversion/bindings/javahl/include/org_tigris_subversion_javahl_ConflictDescriptor_Action.h
But there are about 20 files that it will complain about, so you may
want to script it.
I'm not sure how to modify the makefile to work properly.
Benno Korn wrote:
Ok. Thank you.
I asked in subversion IRC channels and mailing lists, but no one had
a clue where the problem is.
Then I decided that when someone knows how to compile it then these
people who compiled the package
in the repositories.
And now I am asking here ;-)
Jason Crain schrieb:
Sorry, missed the problem with all of the extra long lines :)
It looks like the problem is it is missing the file
org_tigris_subversion_javahl_ConflictDescriptor_Action.h, probably
because
something went wrong building javahl. I'm compiling it now to see if I
can figure out why...
On Fri, June 27, 2008 2:15 pm, Benno Korn wrote:
I tried with the -W option.
But the same error occured again.
Jason Crain schrieb:
Those look like fairly benign warnings that could be ignored. I'm
not
too
familiar with debuild, but you could try running it with the -W
option.
That might set it to ignore warnings.
On Fri, June 27, 2008 1:33 pm, Benno Korn wrote:
Hello,
I am using Ubuntu 8.04 32 bit.
I try to package subversion 1.5.0 with JavaHL support.
Therefore I use these debian experimental sources:
http://packages.debian.org/experimental/subversion
When I build the package using:
tar xzf subversion_1.5.0dfsg1.orig.tar.gz
cd subversion-1.5.0dfsg1
zcat ../subversion_1.5.0dfsg1-1.diff.gz | patch -p1
debuild -us -uc
... the packages are successfully created but the libsvn-java
package
is
missing.
So I have to compile using:
DEB_BUILD_OPTIONS=with-javahl debuild -us -uc
But then I run into this error:
http://ubuntuusers.de/paste/373157/
How is the Ubuntu package in the repositories (version 1.4.6) being
built?
Or how else do I fix this problem?
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
#! /bin/sh /usr/share/dpatch/dpatch-run
## 01_javahl_headers_for_nested_classes.dpatch by [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: javahl_headers_for_nested_classes Adds the missing headers for the
## DP: nested classes inside the javahl sources
@DPATCH@
diff -Nru
subversion-1.5.0dfsg1.orig/BUILD/subversion/bindings/javahl/include/org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine.h
subversion-1.5.0dfsg1/BUILD/subversion/bindings/javahl/include/org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine.h
---
subversion-1.5.0dfsg1.orig/BUILD/subversion/bindings/javahl/include/org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine.h
1970-01-01 01:00:00.0 +0100
+++
subversion-1.5.0dfsg1/BUILD/subversion/bindings/javahl/include/org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine.h
2008-06-28 16:16:04.0 +0200
@@ -0,0 +1,18 @@
+/* DO NOT EDIT THIS FILE - it is machine generated */
+
+#include jni.h
+
+#ifndef __org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine__
+#define __org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine__
+
+#ifdef __cplusplus
+extern C
+{
+#endif
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __org_tigris_subversion_javahl_BlameCallbackImpl_BlameLine__ */
diff -Nru
subversion-1.5.0dfsg1.orig/BUILD/subversion/bindings/javahl/include/org_tigris_subversion_javahl_CommitItem_StateFlags.h
acpi-support, laptop-mode-tools, and hdparm: when will the madness end?
Hi, Nearly everyone has probably heard of the Ubuntu destroyed my hard drive controversy, which made headlines all over the Internet with stories such as these: http://www.google.com/search?hl=enq=ubuntu+load_cycle_countbtnG=Search In the end, it was proclaimed that the problem is not Ubuntu's fault, since the only software mechanism that sets overly aggressive APM settings for hard drives is laptop-mode, which is disabled by default. See #59695. Okay, I'm open to this argument. But I don't think that it means that simply enabling laptop-mode should indicate that the user has given permission to the OS to trash his hard drive. Users that do enable laptop mode reasonably expect that the relevant settings they choose and specify in /etc/laptop-mode/laptop-mode.conf will be respected. Yet, unless I'm missing something, /etc/acpi/power.sh just plain clobbers them. Not only does it clobber them, though, it overrides on-battery HDD APM settings (hdparm -B, hdparm -S) with some pretty aggressive settings that can, in fact, lead to people's hard drives dying early. Users that think they are setting their HDD APM settings on the safe side (in /etc/laptop-mode/laptop-mode.conf) have no idea that their drives are being worked pretty hard. See #37187. A less important but equally relevant issue is the fact that laptop-mode.conf pretends that you can control when laptop-mode is entered/exited, but, in fact, power.sh explicitly overrides these settings, too. See #74394. So here are my questions: Why does /etc/acpi/power.sh run hdparm? It only does so when laptop mode is enabled, and laptop mode does this itself. Not only that, when going on battery, laptop-mode's native handling is overridden, but when going on AC, power.sh wins. Moreover, why do we have so many different ways to control handling of power-related events? As a user, it is pretty difficult to get in there and figure out why your settings are being blown away. Here is a list of power script directories on my system: /etc/acpi /etc/pm /usr/lib/pm-utils /etc/power /etc/laptop-mode /etc/apm Maybe things really need to be this complicated. If that's the case, is there any way we can make it more obvious to users what they should be doing? In my opinion, power handling is one of the biggest problems on Ubuntu. While a good portion of that is related to difficult hardware, the fact that the power-handling software pieces are so disjointed is also a major contributor. What can we do to sort this out? Thanks, Forest -- Forest Bond http://www.alittletooquiet.net http://www.pytagsfs.org signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Whatever happened to apt-sync?
Evan wrote: If the code is functional, shouldn't this be pushed to Ubuntu to be used by their repositories? Or would the CPU drain for aptsyncmake on that many packages be too much? I would like to set up a repository of aptsync files, and if this can be done on the Ubuntu servers, that would be great. aptsyncmake would initially need to be run once for every file in the repository, and then whenever a new file is added, but I think the CPU load should be manageable. Felix -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: acpi-support, laptop-mode-tools, and hdparm: when will the madness end?
Am Samstag, den 28.06.2008, 14:21 -0400 schrieb Forest Bond: Not only does it clobber them, though, it overrides on-battery HDD APM settings (hdparm -B, hdparm -S) with some pretty aggressive settings that can, in fact, lead to people's hard drives dying early. Users that think they are setting their HDD APM settings on the safe side (in /etc/laptop-mode/laptop-mode.conf) have no idea that their drives are being worked pretty hard. See #37187. Hi, I don't want to dismiss your arguments, I have the problem (in quite a nonhazardous way though, my drive will only die in 3 years) myself. I just want to mention two things that are most probably true: 1) Power saving is known to destroy hardware, not even hard drives; That's known to technically inclined people. Monitors, power supplies, fans, anything can break earlier if power management interferes with it constantly, *especially* mechanical hardware like hard drives. 2) Users who tweak their configs should know what they are doing. = Users who tweak power management settings should be aware they might make things worse. I'm not saying to leave this bug alone. I'm only saying I'm much more worried about casual users who have the problem since install, and don't know anything... and suddenly their drive is trashed. I myself was completely unaware of the bug some months ago, but I was aware of my disk constantly clicking. After some time, I did some research, and then the issue also crept up on IT news sites. To conclude: If people change a config setting to be on the safe side, they better check if their (load_cycle_count / power_on) ratio decreases. You can't change configs and assume all is right without checking. ;-) Bye, Sebastian. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: acpi-support, laptop-mode-tools, and hdparm: when will the madness end?
Hi Sebastian, On Sat, Jun 28, 2008 at 09:00:05PM +0200, Sebastian Breier wrote: Am Samstag, den 28.06.2008, 14:21 -0400 schrieb Forest Bond: Not only does it clobber them, though, it overrides on-battery HDD APM settings (hdparm -B, hdparm -S) with some pretty aggressive settings that can, in fact, lead to people's hard drives dying early. Users that think they are setting their HDD APM settings on the safe side (in /etc/laptop-mode/laptop-mode.conf) have no idea that their drives are being worked pretty hard. See #37187. I don't want to dismiss your arguments, I have the problem (in quite a nonhazardous way though, my drive will only die in 3 years) myself. I just want to mention two things that are most probably true: 1) Power saving is known to destroy hardware, not even hard drives; That's known to technically inclined people. Monitors, power supplies, fans, anything can break earlier if power management interferes with it constantly, *especially* mechanical hardware like hard drives. 2) Users who tweak their configs should know what they are doing. = Users who tweak power management settings should be aware they might make things worse. I'm not saying to leave this bug alone. I'm only saying I'm much more worried about casual users who have the problem since install, and don't know anything... and suddenly their drive is trashed. I myself was completely unaware of the bug some months ago, but I was aware of my disk constantly clicking. After some time, I did some research, and then the issue also crept up on IT news sites. To conclude: If people change a config setting to be on the safe side, they better check if their (load_cycle_count / power_on) ratio decreases. You can't change configs and assume all is right without checking. ;-) I agree that it's reasonable to assume that users who go messing with /etc/* should be expected to know what they're doing. However, just because advanced users can debug these kinds of problems doesn't mean that they should have to. It is a time consuming process, and users should be able to assume that the default configs are at least coherent and behave as advertised in comments, etc. -Forest -- Forest Bond http://www.alittletooquiet.net http://www.pytagsfs.org signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Ubuntu Wanted Site
A while ago I posted an idea at Brainstorm [1] about the creation of a website where team administrators can post roles in their teams. This includes static tasks(bug triaging, MOTU) and tasks that are just suitable for one person(maintainer of package X, leader of team Y). The team administrator from an approved team can add a role. Other people can apply for a job and the poster can approve it. Some people really liked the idea and asked for further clarification of the idea. To do this I've created a blueprint [2] and a wiki page [3] for this specification. But it's not complete yet and still needs some discussion. Next to the FIXMEs at the wiki page the programming language needs to be discussed and if some other people have some suggestions, please give them. I want to ask you to read the blueprint and wiki page and give your opinion. Did I forget something? Do you have a concern or think something is wrong? Feel free to add something to the wiki page, but if you've got something major discuss it first at this mailist. Two things I came up with: -What if team administrators would like to let other people post the roles? How could we check that? -It would be nice to provide the option of a counter for the static jobs. If only 5 people are needed, the job will be marked as closed. Some issues: -Can you request teams and team roles from Launchpad when using OpenID? -Would it be good to keep all jobs in some kind of archive? Ideas from other people: -Integrate it with brainstorm -Show to all people the list of applicants. [1] http://brainstorm.ubuntu.com/idea/9810/ [2] https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-wanted [3] https://wiki.ubuntu.com/UbuntuWanted --- Sense Hofstede (Second try, first one was with my 'Dutch' email address. I cancelled that posting.) signature.asc Description: Dit berichtdeel is digitaal ondertekend -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
