RE: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future
Benno, Out of curiosity, why not just compile it yourself? According to the Jack2 and PulseAudio sites they can work together with PA automatically releasing the sound system for J2 when J2 needs it using DBUS. So rather than complain about it; just port it real quick and then you will have actual numbers and the component you need to continue your work on your main project. :-D I'm not saying you aren't right that J2 offers a lot; it just that I would venture a educated guess that Nokia will NOT waste resources to change the underlying sound system on a OS (Maemo) that is at a EOL status.As for Meego, you need to obviously present a case on the Meego mailing list -- but since they already shipped a version; gutting the sound system may not be something worth while that they would consider until a later major version.Although who knows, maybe they would -- and since it is Open Source, and you can submit patches; if you actually got J2 running great on Meego, that would make the process a whole lot easier for them to decide to switch. Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Benno Senoner Sent: Friday, June 18, 2010 6:19 AM To: maemo-developers@maemo.org Subject: Re: Low Latency Audio Capture on the N900, QAudioInput BUG: has 5000msec latency, Meego audio future I know that I'm a bit a repetitive person, but my intent is to raise an alarm, that nowadays companies cannot afford to ship, half-finished, half-baked, buggy systems, and moreover chose the vastly inferiour (pulseaudio) open source component over the better (JACK2 audio server). I reported my findings here, on the maemo-developers mailingslist, which is read by Nokia engineers too, and the only responses I get back is that I should not whine. No technical responses at all, how the latency can be lowered using other APIs etc.. Sadly, this week Nokia stock again dropped like a rock, while Apple gets preorders for 600k Iphone 4 in a day and have trouble to process all the orders. Does that not ring alarm bell at Nokia ? As said nowadays either you deliver a smooth user experience (including dropout free, low latency audio for apps) and make it easy for developers to access that features, or your market share will continue to drop and drop. It seems like Maemo will be end of lined soon so I'm not expecting Maemo getting much improvements, but it's successor, Meego HAS to deliver a smooth user experience. I will continue those discussions on the Meego list and perform benchmarks and tests so that everyone can see what the real numbers are and if there are still problems regarding low latency audio. Unfortunately, given the weak implementation of pulseaudio I fear that the prerformance will not be stellar. I hope that I'm proved wrong Did Meego enginers publish such numbers, yet ? eg what latency can be achieved on certain hardware, audio dropout frequency etc ? Execpt for technical discussions about audio I will not continue my long diatribes on this list. But as said I will continue to point out possible flaws in Meego regarding audio backing my claims up with numbers and bencharking apps. If the hardware is capable to be responsive, there is no reason why Meego should not fully exploit it regards, Benno The LinuxSampler Project http://www.linuxsampler.org 2010/6/16 Ville M. Vainio vivai...@gmail.com: On Wed, Jun 16, 2010 at 3:57 PM, Benno Senoner benno.seno...@googlemail.com wrote: I just represent a multimedia developer wanting to use the platform and point out the flaws in order to contribute to improve it. ... and that is appreciated. OTOH it's waste of typing to engage in long diatribes about business models and whatnot here (such discussion is more appropriate for talk.maemo.org). -- Ville M. Vainio http://tinyurl.com/vainio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: N900 kernel 2.6.28 no compiles after changing cb[] array size
Sergio,
If I had a guess, I would guess that the n900 probably has a
different set of compile time defines, that cause the ieee80211 structure to
be defined differently on the n900 vs a stock machine. The compile time
failsafe is to make sure that the structure iee80211 is larger than skb-cb.
Run a grep on the code to find out where/how the ieee80211 structure is
being defined and you will probably find the issue.
Nathan.
-Original Message-
From: maemo-developers-boun...@maemo.org
[mailto:maemo-developers-boun...@maemo.org] On Behalf Of Sergio Lembo
Sent: Thursday, June 17, 2010 3:08 AM
To: maemo-developers@maemo.org
Subject: N900 kernel 2.6.28 no compiles after changing cb[] array size
Hi,
I am having an inconsistent state in the N900 kernel 2.6.28 when I make a
very simple
change:
The problem is reproduced easily by just increasing the size of the
control buffer cb[] in struct sk_buff{} (include/linux/skbuff.h):
- charcb[48];
-
+ charcb[62];
Using cb[62] I get a compilation error :
CC [M] net/mac80211/main.o
net/mac80211/main.c: In function 'ieee80211_init':
net/mac80211/main.c:1026: error: size of array 'type name' is negative
make[2]: *** [net/mac80211/main.o] Error 1
make[1]: *** [net/mac80211] Error 2
make: *** [net] Error 2
The line with the error is a failsafe at compilation time
(net/mac80211/main.c):
BUILD_BUG_ON(sizeof(struct ieee80211_tx_info) sizeof(skb-cb));
Bypassing such failsafe line the kernel compiles Ok, but the binary
flashed to the N900 fails to boot the system.
I observe that such compilation error does not happen when compiling a
plain 2.6.28 kernel for a PC.
And note that this error is just caused by changing the size of cb[] from
48 to 62; that is the only modification we made to the kernel sources.
Regards,
Sergio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: N900 kernel 2.6.28 no compiles after changing cb[] array size
Sergio,
Maybe the actual problem is that 62 is not a multiple of 4. the
sizeof(void (*)) should be 4 on 32 bit platforms. So if you read that; you
get:
62-8 (=54)
54 / 4 (=13.5)
On the old value you get
48-8 (=40)
40/4 (=10)
What happens if you change it to
charcb[64];
The compiler could be having a issue because of 13.5 and just masking the
issue until later. (Gotta love C/C++ compilers, you can chase your tail
sometimes G)
Nathan
-Original Message-
From: maemo-developers-boun...@maemo.org
[mailto:maemo-developers-boun...@maemo.org] On Behalf Of Sergio Lembo
Sent: Thursday, June 17, 2010 1:59 PM
To: maemo-developers@maemo.org
Subject: RE: N900 kernel 2.6.28 no compiles after changing cb[] array size
Hi,
Thank you for your answer.
I observe that in include/net/mac80211.h the defines pasted below are
introducing a non-linear sizing (observe the hardcoded number 8) that may
cause problems for some ranges and thus validating (sizeof(struct
ieee80211_tx_info) sizeof(skb-cb)).
#define IEEE80211_TX_INFO_DRIVER_DATA_SIZE \
(sizeof(((struct sk_buff *)0)-cb) - 8)
#define IEEE80211_TX_INFO_DRIVER_DATA_PTRS \
(IEEE80211_TX_INFO_DRIVER_DATA_SIZE / sizeof(void *))
Although this is not directly the problem that I have and
BUILD_BUG_ON(sizeof(struct ieee80211_tx_info) sizeof(skb-cb));
is failing for some other reason that I did not find yet..
Regards,
Sergio
Quoting Nathan Anderson nat...@andersonsplace.net:
Sergio,
If I had a guess, I would guess that the n900 probably has a
different set of compile time defines, that cause the ieee80211
structure to be defined differently on the n900 vs a stock machine.
The compile time failsafe is to make sure that the structure iee80211 is
larger than skb-cb.
Run a grep on the code to find out where/how the ieee80211 structure
is being defined and you will probably find the issue.
Nathan.
-Original Message-
From: maemo-developers-boun...@maemo.org
[mailto:maemo-developers-boun...@maemo.org] On Behalf Of Sergio Lembo
Sent: Thursday, June 17, 2010 3:08 AM
To: maemo-developers@maemo.org
Subject: N900 kernel 2.6.28 no compiles after changing cb[] array size
Hi,
I am having an inconsistent state in the N900 kernel 2.6.28 when I
make a very simple
change:
The problem is reproduced easily by just increasing the size of the
control buffer cb[] in struct sk_buff{} (include/linux/skbuff.h):
- charcb[48];
-
+ charcb[62];
Using cb[62] I get a compilation error :
CC [M] net/mac80211/main.o
net/mac80211/main.c: In function 'ieee80211_init':
net/mac80211/main.c:1026: error: size of array 'type name' is negative
make[2]: *** [net/mac80211/main.o] Error 1
make[1]: *** [net/mac80211] Error 2
make: *** [net] Error 2
The line with the error is a failsafe at compilation time
(net/mac80211/main.c):
BUILD_BUG_ON(sizeof(struct ieee80211_tx_info)
sizeof(skb-cb));
Bypassing such failsafe line the kernel compiles Ok, but the binary
flashed to the N900 fails to boot the system.
I observe that such compilation error does not happen when
compiling a plain 2.6.28 kernel for a PC.
And note that this error is just caused by changing the size of
cb[] from
48 to 62; that is the only modification we made to the kernel sources.
Regards,
Sergio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
--
---
Sergio Lembo
sergio.le...@tkk.fi
---
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Promotion to Fremantle Testing broken on some packages
I was attempting to promote a couple packages in the samba set and I get a error. http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_ armel/smbclient/3.4.3-maemo2/ http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_ armel/smbfs/3.4.3-maemo2/ I get: --- Server Error Package libtext-iconv-perl is not available in this repository. Dependency is missing. Error 500 --- The funny thing is according to the list of dependancies; that dependancy isn't one of them. Nathan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo extras repository package uploader/maintainer verification?
Ok, I think I must be confused; I was under the impression that you leave the maintainer field alone if all you are doing it packaging it up for the maemo platform.I don't actually maintain any of the code for several of the projects that I have uploaded. All I've done is did the work to package it up. Am I supposed to put in the maintainer field my name, or leave it as the original team that wrote it. The only thing I change is the changelog to show that the program was packaged by me. (i.e. sword library, kernel modules) Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Simon Pickering Sent: Friday, January 22, 2010 7:00 AM To: 'Jeremiah Foster'; maemo-developers@maemo.org Subject: RE: Maemo extras repository package uploader/maintainer verification? What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo extras repository package uploader/maintainer verification?
Jeremiah, Thanks -- I have no issues with dropping my name into the maintainer field; I just didn't want to steal any credit from the real authors of those things that I just repackaged. I do know the language of everything I've repackages; and could probably muddle my way through something I didn't know. ;-) If the standard is that I take the maintainer field; I'll make sure to update all my packages. Thank you for the clarification! I do notice that the docs was for pre-fremantle, and somethings are no longer used. (i.e. maemo-select-menu-location and maemo-installer-utils I believe are no longer used in fremantle).Can you tell me if thumb and vfp options are still valid or does the autobuilder now automatically use them. Nathan. -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Jeremiah Foster Sent: Friday, January 22, 2010 10:40 AM To: maemo-developers@maemo.org Subject: Re: Maemo extras repository package uploader/maintainer verification? On Jan 22, 2010, at 5:17 PM, Nathan Anderson wrote: Ok, I think I must be confused; I was under the impression that you leave the maintainer field alone if all you are doing it packaging it up for the maemo platform.I don't actually maintain any of the code for several of the projects that I have uploaded. You do however maintain the package. So if there are bugs it is your responsibility to push the bugs upstream if they are in the code. This is how the responsibility is divided in debian anyway, it is not explicitly laid out for Maemo but I think it ought to be self-evident. All I've done is did the work to package it up. In many cases the developer is also the packager, but when the packager is different from the developer(s) then the packager has to take on a bit of responsibility for at least packaging QA. Maintaing the code as well is usually not required, but it is considered a good thing if at least you know the programming language it is written in, etc. Am I supposed to put in the maintainer field my name, or leave it as the original team that wrote it. The only thing I change is the changelog to show that the program was packaged by me. (i.e. sword library, kernel modules) The changelog is a must, but changing the maintainer name in the debian/control file is also a must, according to maemo packaging policy. Here is the policy in pdf: WARNING PDF! https://maemo.org/forrest-images/pdf/maemo-policy.pdf Jeremiah Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Simon Pickering Sent: Friday, January 22, 2010 7:00 AM To: 'Jeremiah Foster'; maemo-developers@maemo.org Subject: RE: Maemo extras repository package uploader/maintainer verification? What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to destroy your community
Dave, I would totally side with Jeff on this one -- the whole infrastructure has been a issue for a while. I do NOT see the primary issues getting any better. Sure the servers seems to be faster; but obviously the load needs more people to be able to handle it in a timely fashion. The consistent servers issues have caused me a whole lot of grief. And I really, really hate having to post; the package is done, but the autobuilders are down or the package was built; but the autobuilders aren't moving it into extras-devel or it is in extras-devel but I can't promote it to testing. All three which I have had to write several times in the last couple weeks and most of them the issues persisted 48 hours! That's not even counting the myriad of other issues that are caused by the servers and/or the move. The problem is I believe that we (the users and developers) did have realistic expectations. A fairly seamless move between servers. I have moved a large community (Larger than Maemo is) between servers; and I wasn't down more than 20 minutes on some services -- and that was because I double checked certain thing manually just to make sure I didn't loose any messages on the high volume board -- since I allowed posting to continue up until the very last second, before I had it switch to the other server in the other facility. I even made sure that DNS had a temporary address for the new server; so that the old server could redirect to the new dns address if people still had the old dns somehow in their cache. I can't say I had any complaints at all about the move, most people probably didn't even realize it had happened (besides everything going way faster). I've also setup completely new servers to be a mirror of another very large site (also larger than Maemo), with identical content and wasn't down at all. These are realistically done, with little or NO down time. I never told my customers; oh sorry -- we choose an isp that sucks, can't do anything about it, wait a couple days and it might be working again for most of your users. I made sure my customers knew up front about any thing that could be an issue. That way if it was an issue; they knew about it -- but because of planning; none of them actually turned into issues. If there are problems to be expected; PRE-post about them, so that all the expectations are set realistically.For instance, take people having to discover that they have to move their git, svn, or even dput AFTER the fact; what a pita. It really should have been PRE-posted to the list: Hey, we had issues getting the old svn address working; you will be forced to change it to xyz.mameo.org It never should have been some poor person attempt to svn commit and get a redirect error message, and having to ask the list what is up. The problem that Jeff presents is that Maemo for all practical purposes is Nokia and the team is acting as such. I see no such accountability to the users of Maemo who rely on these services. I have no doubt they (the web team) are doing their job; it is just they apparently report to Nokia and not Maemo. So, we sure as hell have no idea what is going on until we ask: Why is x not working; and then later get back the response; yeah that is known -- it might be fixed later. If they had done any due diligence; they would have either known it would take a couple days to get things smooth again and pre-posted this to the group, tmo and setup a wiki page with status on each service. Or, they would have done the transference in a much, much more seamless manner, i.e. move over each service one at a time pre-test then redirect dns for just that service. Yes, some smaller issues may have occurred; but this move has been a disaster and I would say a decent case study in how _not_ to move a community to new servers. Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Dave Neary Sent: Wednesday, January 20, 2010 12:55 PM To: Jeff Moe Cc: maemo-developers@maemo.org Subject: Re: How to destroy your community Hi, Jeff Moe wrote: People have been preaching patience (not just to me, to everyone) since I landed here and before. Why should we be patient? Why can't we demand things work like they do everywhere else? I'm sure google/apple would love for us to be patient for the next 3 years. I guess that the problem is that you demand rather than request. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to destroy your community
Jeremiah, Okay, so it's knives out is it? Fine. I have flame retardant underwear. :-) I think you just lost the battle; knives against flame retardant underwear; the knife wins. ;-D I know you want things to work smoothly, we all do. Believe me, the admins are working their butts off to make it so, they work long days and have been checking in on weekends too. I still see no reason for any personal attacks, it is not necessary. I don't recall seeing any personal attacks (but then my wife says I don't read between the lines very well either), in fact I've tried to make sure that I put in my messages that I realize you are all working probably long and hard. I do realize you are working hard, and we are where we are because none of this was discussed before. And some flaming is coming because there is no pre-emptive communication. So maybe you should ask for additional help. I can manage servers; everything from install to actual programming; both Linux and Windows servers, and I've played with BSD, and a couple other *nix's.Jeff apparently has some skills in this area also. Tap the community, it is supposed to be community servers. ;-D 3. Whatever ISP is chosen to host the site should feel like a stakeholder in the success of the maemo community. They should feel motivated for things to work 24/7. Actually, the problem is that this isp must be very small; which then means they are not well staffed. They really don't have to be part of the community. They just have to offer the services to make sure the community isn't going to suffer on failures. At this point, the unability to fix a nfs point over the weekend does not inspire any sort of confidence that they will be able to fix anything major. My recommendation is more a move to a Teir 1 or 2 class host, not some two bit host.I'm a two bit host on my personal projects (its only me), but the facility I host my servers through is a Tier 1. I'm notified of all issues on all my servers (multiple ways). My uptime is somewhere close to 99.9% on all the servers, and pretty much any downtime is self inflicted. ;-)I have to imagine that Nokia is probably spending a lot more than what I do for my servers, since I'm cheap! Not meant as an attack, but, why aren't we in a tier 1/2 facility? 4. The community should be allowed to help with the infrastructure. Perhaps some services should be entirely released to the community? Or maybe start using community resources like the SuSE OBS? 5. Greater communication and transparency from the maemo staff. Agreed. If I have missed anything I am sure you'll let me know, in no uncertain terms. ;) Lol, watch the knives come To bad your wearing flame resistant underwear. I'd rather have the armor in a knife fight. ;-D Nathan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to destroy your community
As maemo transitions to a much larger server farm, there have been hiccups. The site has been slow, but has recently gotten significantly faster, in certain parts. Tero is right though, you just haven't been here long enough to have a reliable sample of uptime vs. downtime with regards to maemo.org. I would disagree; a major hiccup is a hour of down time, a hiccup is the service being restarted.A disaster is this ongoing weekend, and still having several primary services broken and/or totally non-functional. You just don't run a ISP service where you can't fix things in a timely fashion. I have been here for quite a while; and servers just have not been really reliable for the most part (growth can do that -- but I think the warning signs about this ISP should have occurred when it took until late Dec/early Jan to provision the equipment when I believe it was on the Sprint task in Oct); I've also had to ping several people to get things kicked to make them start working again. Nokia/Maemo != Reliability I understand Tero and others have been working hard; but this move is still is a complete fail in how to move properly. My guess is the initial planning wasn't done properly or due diligence with the new isp wasn't done -- I can't think of a good excuse for this weekend with any decent isp host. I could have easily provisioned several servers and got them all setup, communicating and running with either of my own personal projects or my companies fairly complex sites and had them fully functional in under an hour. I just don't understand; Autobuilder, Repositories, Mailing Lists all still being broken several days after the move. 10) Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. Here is what I would like to know, since this has been a fiasco: 1. What servers do we have? Type, what do they each do? (i.e. 1 - HP 3080 2Ghz 8GB, 100GBHD, - handles Autobuilder, Community Mailling Lists) 2. What is the approx cost that Nokia is funding for this. 3. Who has access to them. This info would be great to drop in a wiki page. I might be a small fry, but I personally deal with two distinct webfarms for a couple high availability web sites. I'm sure their our others who have even more experience than I do; together we might be able to help make sure the infrastructure is sound. You do get many things done, but your communication style isn't polite. I do understand that controversy can bring about change, but it can also polarize situations. Ooops! No silence here! I guess that disproves point 10. :-) (http://jaaksi.blogspot.com/ -- More non-silence.) Actually I don't consider jaaksi a place of contact or even someone reliably involved community wise with Maemo. His blog posts are for the most part marketing and imho pointless. You want contact with Nokia, Quim is the person to chat with, he is imho the man for any real contact with Nokia. And he does get things done reliably to the best of his ability! He is our critical link/lifeline to Nokia. There are a couple other Nokians, that you can chat with on the mailing lists and TMO for certain specific issues, but for most issues Quim can get you pointed in the right direction. (btw, Thanks Quim!) There is plenty of room for criticism, just try to be polite so that the tenor and tone remain positive enough for people to get work done and not get distracted by pejorative attacks. I would agree be polite! Also don't dismiss the newer members (Not directed at you Jeremiah). Not only do they have fresh perspective; They see the site for how it is now which is what all the other new users of the n900 will see the site. They don't care about how it was during the Nokia 770 days. They care about how it is now! (I also care about now, I don't really care that you had to walk up hill both ways when the Nokia 770 was released G) For the end users they have seen: 1. Unreliable access to software 2. OVI store coming soon for months 3. The entire repositories down this weekend. 4. TMO unreliability For developers add: 1. Lots of Autobuilder issues 2. Garage Issues 3. Mailing list issues (Both Garage and these) 4. zip/gz issues 5. bugzilla lost data 6. SDK rootstraps replacement 7. Wiki Issues 8. DNS issues. These all are reflections not only on the community but on Nokia. The end user isn't going to know that Maemo is not Nokia. And in some cases these services are provided by Nokia. But for the purposes of perspective, it all just looks like Nokia hasn't a clue on how to run things. And if Nokia hasn't a clue, then why would I recommend the n900 to my friends. I think Jeff Moe has a very valid point, we need to take a hard look at what we can do to improve the situation now and in the future. We also probably need to figure out what we did wrong (
Proper location of Kernel modules
Over the last week or so, I've uploaded three different Kernel Modules; Cifs, NTFS, and NLS_UTF8. I had stuck them in the proper user/* categories but was questioning if I should (Cifs, should be a prereq of Wizard Mounter, so it won't have to be found by a end user to install it). But the other two are modules that are only rarely asked for (NTFS - Ability to access Windows NT File Systems, and NLS_UTF8 is used by file drivers for UTF8 support). Should they be put in a real user/* category to be easily found and installed or should they be basically hidden so only experts who run apt-get can get it? What do you all think? I also could put NLS_UTF8 as a pre-req of Cifs, but it is only required if you want to use UTF8 volume mounting, otherwise it isn't needed or loaded. I also could put NTFS as a pre-req of TrueCrypt, since off the top of my head it is the only item currently that can need access to NTFS volumes. Nathan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Another Extra's uploader issue
I've tried to upload Samba to the fremantle repository several times tonight; and after spending 5 minutes or so each time (23ish meg file). It says: Upload error, no repository selected! -- I've picked the fremantle repository each time; but it then fails. Nathan P.S. Thanks for getting the promotion system fixed; I was able to promote three packages that were awaiting. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Fremantle Dev - Testing promotion issue
Erps, Looks like I dropped this thread into the wrong mailing list. LOL, no wonder I didn't get a response. Although now the error has changed to: Fatal error: Allowed memory size of 104857600 bytes exhausted (tried to allocate 72 bytes) in /mnt/netapp/pear/midcom/lib/midcom/helper/_dbfactory.php on line 487 So, I would guess a configuration issue on the size php is allowed to allocate on the new servers. Nathan -Original Message- From: maemo-community-boun...@maemo.org [mailto:maemo-community-boun...@maemo.org] On Behalf Of Nathan Anderson Sent: Thursday, January 14, 2010 7:19 PM To: 'List for community development' Subject: RE: Fremantle Dev - Testing promotion issue It apparently isn't just me; someone on TMO also has asked the same question. Is this related to the server moves, or does someone need to kick something on the server to get this to work again. I can see the detail page on other peoples packages fine; but apparently if the page is for my own package it either times out or goes into la la land showing loading forever. Nathan -Original Message- From: maemo-community-boun...@maemo.org [mailto:maemo-community-boun...@maemo.org] On Behalf Of Nathan Anderson Sent: Wednesday, January 13, 2010 12:12 PM To: 'List for community development' Subject: Fremantle Dev - Testing promotion issue I've been trying to actually see the page to promote my cifs and ntfs modules from dev into testing and the web site has been either timing out (or going into lala land) for the last day or so. Anybody able to poke the machine to find out what is wrong with it. These are armel only packages (if that matters?) Nathan ___ maemo-community mailing list maemo-commun...@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-community ___ maemo-community mailing list maemo-commun...@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-community ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Uploading software to Maemo repos
Jeremiah, 1. Why will they not go through? What is so special that they aren't allowed? 2. Is their a list of packages that are not allowed, and why isn't it linked to on the main upload page. Nathan. -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Jeremiah Foster Sent: Friday, January 01, 2010 9:24 AM To: Bryan Jacobs Cc: maemo-developers mailing-list Subject: Re: Uploading software to Maemo repos On Jan 1, 2010, at 16:22, Bryan Jacobs wrote: Jeremiah, I needed ss-dev, debconf-utils, and a few other packages which *were* built from the Nokia official sources but which *were not* present in any repository I could find. The packages I built which are also in the official Nokia repository (e2fsprogs and debconf) are unmodified and constructed via apt-get source; dpkg-buildpackage. They will not go through - there is a check on the builder that prevents that sort of thing from happening, though the check sometimes fails. Do you read your build logs? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Uploading software to Maemo repos
Jeremiah, I'm not trying to be at all argumentive, I just would like to know the reasons. 1. Why will they not go through? What is so special that they aren't allowed? Because there are other versions which are needed to build other packages. Yes, but the build server should reset to known good config; why would someone building a newer version of debconf break it? 2. Is their a list of packages that are not allowed, and why isn't it linked to on the main upload page. Have you read the wiki? Or any other development documentation? Yes, in fact I've edited the docs when I've found things wrong. But I don't ever recall reading anything about building debconf breaking the builder and that I should not attempt to build it. Can you point to which wiki document has the info on bad packages not to build. I'd like to know so if in the future I can avoid them. (And as a recommendation, I would recommend someone add that as a link to the main package upload page) Nathan. -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Jeremiah Foster Sent: Friday, January 01, 2010 9:24 AM To: Bryan Jacobs Cc: maemo-developers mailing-list Subject: Re: Uploading software to Maemo repos On Jan 1, 2010, at 16:22, Bryan Jacobs wrote: Jeremiah, I needed ss-dev, debconf-utils, and a few other packages which *were* built from the Nokia official sources but which *were not* present in any repository I could find. The packages I built which are also in the official Nokia repository (e2fsprogs and debconf) are unmodified and constructed via apt-get source; dpkg-buildpackage. They will not go through - there is a check on the builder that prevents that sort of thing from happening, though the check sometimes fails. Do you read your build logs? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo-optify, autobuilder /opt
Anderson Lizardo, Unless I misunderstood; if the package itself has a /opt path in it the maemo-optify won't run on it. So if you are installing anything (even one file) under the /opt path (which based on what I see you saying below it appears you are); it should cause the maemo-optify to not run. Nathan Anderson -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Anderson Lizardo Sent: Wednesday, December 02, 2009 11:56 AM To: Marius Vollmer Cc: maemo-developers@maemo.org Subject: Re: maemo-optify, autobuilder /opt On Wed, Dec 2, 2009 at 12:56 PM, Marius Vollmer marius.voll...@nokia.com wrote: ext Anderson Lizardo anderson.liza...@openbossa.org writes: If you have plans to begin enabling auto-optification by default, please inform us here on the list so we can begin adding the debian/optify file to avoid optifying packages that were manually optified by other means (e.g. python packages). If a package already contains a /opt directory, no further optification is done by the maemo-optify tools in any case. Is that enough to protect you? No, because the optification was done by creating a pymaemo-optify package which bind mounts the relevant Python directories from /usr/... to /opt/pymaemo. These mounts are done during device boot by /etc/init.d/pymaemo-optify (they are not mounted inside scratchbox, of course). This means that there is no change required for python packages to become optified, they just need to depend on python. We can put additional checks into maemo-optify to disable optification. I don't know enough about Python packages to suggest a good one, but maybe just looking for /usr/lib/py* in a package and stopping to do anything would work. Actually the list of directories handled by pymaemo-optify is variable (but not expected to change). They are defined in /etc/default/pymaemo-optify and currently is: /usr/lib/python2.5 /usr/share/pyshared /usr/lib/pyshared /usr/share/python-support /usr/lib/python-support One idea might be to check whether this file exists and ignore any packages which install files to the directories listed on the BIND_MOUNTS directory (note that this file is a snippet of shell script read by /etc/init.d/pymaemo-optify). Or you can hard code this list somewhere, and you will get at least most Python packages ignored. As with every heuristics, we can't get 100% of cases, and others will need to have to be manually opted-out. My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
SVN Access and Failures
I started a project on the Garage, I added a senior developer to the project. He is attempting to check something in and it gives him one of two problems. If he uses a incorrect user/pw but then it will reprompt; but if he uses his Garage account it spits back: svn: Commit failed (details follow): svn: MKACTIVITY of '/svn/katana/!svn/act/2d6db847-5a77-0410-a29f-b87779591664': 403 Forbidden (https://garage.maemo.org) Any ideas, I can submit my changes fine. Nathan. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Ed, Cool! Thanks, I will upload my fixed dep package and I should be good to go! Nathan -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Thursday, October 22, 2009 2:17 AM To: Kamen Bundev Cc: Nathan Anderson; maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? Hi, I restarted Nathan's build and autobuilder seems to be able to install all build-deps. You can see autobuilder logs here soon: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/ 2009/10/22 Ed Bartosh bart...@gmail.com: Hi, Please read my last message. The issue is fixed. Nobody should do anything except of SDK guys. 2009/10/22 Kamen Bundev bun...@gmail.com: Hi guys, I've played around with maemo-optify yesterday and decided to instead of creating the paths in the package subdir, to create a symlink to /opt and drop everything there before packaging. Wrong move, dpkg-deb doesn't follow symlinks, it packages them :) So, the logical step was to instead of symlink to /opt, to create home/opt in the package subdir and symlink opt/ to it. That worked and I have a package ready that will work in the device, but I'm hesitant to try it in the autobuilder because if the autobuilder is like scratchbox, then the package will be installed to /home/opt but the /opt symlinks will point to somewhere else (/targets/links/opt) and the build will fail anyway. So my question is - is this the right way to go about this and can I control where the /opt dir is symlinked to in the autobuilder? Regards: Bundyo On Thu, Oct 22, 2009 at 2:35 AM, Nathan Anderson nat...@andersonsplace.net wrote: Kamen, I build both binary target and source targets debs in my scratchbox before I upload.For instance last night I had to rebuild the binary debs about 20 times (trying to get a weird make file rule to work). Once I got it working then I would copy my rules to a fresh copy and re-run a source deb then re-run a binary once more just to make sure it wasn't left over stuff causing a success. ;-) So, I don't think it has anything to do with the scratchbox. I suspect it as Ed found something to do with the symlink - directory or something in their on the auto-builder. Nathan. From: Kamen Bundev [mailto:bun...@gmail.com] Sent: Wednesday, October 21, 2009 6:14 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? Nah, that's not enough. Still fails. Another difference is that I'm building my optified package in scratchbox before upload and the other people are using the autobuilder, so the problem should be somewhere else. Regards: Bundyo On Thu, Oct 22, 2009 at 2:09 AM, Kamen Bundev bun...@gmail.com wrote: Nah, that's not enough. Still fails. Regards: Bundyo On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev bun...@gmail.com wrote: Looks like the only difference here is that my /opt should be pointing to /targets/links/opt which is symlinked to the proper target on target change. Uploading the new package to extras now. Regards: Bundyo On Thu, Oct 22, 2009 at 12:39 AM, Nathan Anderson nat...@andersonsplace.net wrote: Ed, I believe this is what you are asking: FREMANTLE_ARMEL cs2007q3-glibc2.5-arm7 FREMANTLE_X86cs2007q3-glibc2.5-i486 Nathan -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 4:03 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt I've found the difference! In your environment /targets/target/opt is a directory. In autobuilder environment it's a symlink: ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 builder1 builder19 Oct 21 23:50 opt - /home/opt And it looks like it becomes symlink after rootstrap unpacking. Look: [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf re -f [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 1005 1006 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --etc --devkits [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --fakeroot Installing
AutoBuilders ignoring a depenancy
Ed, I resubmitted my package; and it decided to ignore one of my dependency. (But it did pull in the optified packages! g) https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/armel.root.l og.OK.txt Shows: 2009-10-22 17:46:55] Try to install static depends: libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev zlib1g-dev python2.5 python2.5-dev maemo-optify However the dsc file has: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/sources/swor d_1.6.0a-0maemo1.dsc Build-Depends: debhelper (= 5), libcurl3, libcurl3-dev, libicu42, libicu42-dev, clucene-core, clucene-core-dev, zlib1g-dev, zlib1g, python2.5, python2.5-dev, swig1.3, maemo-optify It ignored my swig1.3 request. The default swig inside scratchbox/sdk is 1.3.29 -- It generates totally broken code for this package so I took the debian packaged 1.3.40 and added the minor changes to it to make it work on maemo. It is listed in the extras repository as swig1.3 Nathan. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Full Screen Hotkey?
Ctrl-f is very commonly used as Find. Users are used to that. But what about something like Ctrl-Volume (up/down) key? Or Ctrl-Camera Key. That way you aren't actually taking overriding a existing used key. And it could be used by pretty much any program that needed it w/o it being used for some other hotkey. Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Eero Tamminen Sent: Wednesday, October 21, 2009 7:21 AM To: ext ds Cc: maemo-developers@maemo.org Subject: Re: Call for testers with N900 for vncviewer Hi, ext ds wrote: Am Dienstag, den 20.10.2009, 20:08 +0200 schrieb Cornelius Hald: On Tue, 2009-10-20 at 15:01 +0200, ds wrote: I have no feeling for N900 at the moment. But yes, I have some feature requests left on garage, and as there is not too much UI it should not be a big deal:-) But first I want to have it running an the N900. I got it working now :) Attached is a screenshot (in case the list allows that). Thanks, at least my copy allowed it! Getting the UI Fremantle conform should be straight forward, at least it looks like that to me. If you need help there, just tell me. I got a message from maemo admin: After disabling the toolbar and switching to fullscreen mode there seems to be no way get out of full screen or getting the toolbar back. Can you confirm this? Is no Hardwarebutton bringing up the menu or toggle full screen anymore? Correct. I would suggest supporting additional shortcut like Ctrl-f as proposed in another mail. - Eero PS. User can switch to other apps by using the Ctrl-backspace shortcut for the task switcher (or by launching Camera app with the camera button or closing the application from the power menu End task button). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo-Optify Builder Bots = Broken?
Devs, Ok, I have been trying to be a good boy and optify all the items I have been putting into the fremantle extras. Up to now they have been standalone libraries and the build bots have done their job and optified the package (and then I've been able to install them in my sdk properly). However, I have finally submitted a library which depends on two other libraries that I did and optified. Well when it did the depends step to pull all the libraries; this is the output: --- Try to install static depends: libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev zlib1g-dev python2.5 python2.5-dev [2009-10-21 12:30:46] fakeroot apt-get -y -q -o APT::Get::AllowUnauthenticated=1 install --no-remove libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev zlib1g-dev python2.5 python2.5-dev /dev/null (My depends are listed properly) Unpacking libssl0.9.8 (from .../libssl0.9.8_0.9.8g-15maemo4+0m5_armel.deb) ... Selecting previously deselected package libreadline4. Unpacking libreadline4 (from .../libreadline4_4.3-10.1+0m5_armel.deb) ... Selecting previously deselected package clucene-core. Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack): trying to overwrite `/opt', which is also in package base-files Uhm, this is not good. Each of my optified packages throws this error. That kinda makes optifing the libraries a pointless exercise if I can't use them later in the buildbot. And Lib-icu is about 16 MEGS of libraries, so I would think it would be a great canidate for optification. Do I need to resubmit everything w/o optification, or are the build bots broken? The packages that I have optified has depends on maemo-optify and has maemo-optify as the step between (dh_gencontrol and dh_md5sums). dh_gencontrol maemo-optify dh_md5sums What do I need to do to solve this issue? I have no issues resubmitting the packages I have done again to test things, but I would rather have a known way to make it work since Lib-icu is a 2.5 hour (yes, 2 hours 30 minutes) build process on the builders; so if I would prefer not to have to tie up a buildbot for that length of time again until we have a known working solution. Nathan. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Full Screen Hotkey?
Luca, You would already have to have the keyboard open if you used Ctrl-S or Ctrl-Shift-F, Ctrl-F could be used for Find. Ctrl-S could be Save. Using Ctrl-key is hazardous since different apps have different requirements. My guesses for universal keys that all apps could accept for full screen would be: (It would be good if we make it as universal as possible so as not to confuse end users) Ctrl-Volume (Would possibly be used by a music program to switch mp3's tracks playing) Ctrl-Camera (could be used by a camera app to do something different (HDR?)) Ctrl-Power (If Possible, this might be imo the best one -- I can't think of any reason for any other program to use as a hotkey) Ctrl-Space (I can't think of any reason a app would need to map this as a normal hotkey either) Anything else on the keyboard (http://www.nokian900.com/wp-content/uploads/2009/01/Nokia-N900-front-open-k eyboard.jpg) would be easily up for application control and I can't see how we could make is a universal recommendation. Nathan. _ From: Luca Donaggio [mailto:donag...@gmail.com] Sent: Wednesday, October 21, 2009 10:17 AM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Full Screen Hotkey? I think that any combination of CTRL+hardware button of your choice would be a little awkward (CTRL is in the slideing keybord, other buttons are on the sides of the device). I would prefer an all-with-the-keyboard combination. Luca Donaggio On Wed, Oct 21, 2009 at 4:53 PM, Nathan Anderson nat...@andersonsplace.net wrote: Ctrl-f is very commonly used as Find. Users are used to that. But what about something like Ctrl-Volume (up/down) key? Or Ctrl-Camera Key. That way you aren't actually taking overriding a existing used key. And it could be used by pretty much any program that needed it w/o it being used for some other hotkey. Nathan -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Eero Tamminen Sent: Wednesday, October 21, 2009 7:21 AM To: ext ds Cc: maemo-developers@maemo.org Subject: Re: Call for testers with N900 for vncviewer Hi, ext ds wrote: Am Dienstag, den 20.10.2009, 20:08 +0200 schrieb Cornelius Hald: On Tue, 2009-10-20 at 15:01 +0200, ds wrote: I have no feeling for N900 at the moment. But yes, I have some feature requests left on garage, and as there is not too much UI it should not be a big deal:-) But first I want to have it running an the N900. I got it working now :) Attached is a screenshot (in case the list allows that). Thanks, at least my copy allowed it! Getting the UI Fremantle conform should be straight forward, at least it looks like that to me. If you need help there, just tell me. I got a message from maemo admin: After disabling the toolbar and switching to fullscreen mode there seems to be no way get out of full screen or getting the toolbar back. Can you confirm this? Is no Hardwarebutton bringing up the menu or toggle full screen anymore? Correct. I would suggest supporting additional shortcut like Ctrl-f as proposed in another mail. - Eero PS. User can switch to other apps by using the Ctrl-backspace shortcut for the task switcher (or by launching Camera app with the camera button or closing the application from the power menu End task button). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Julius, Thanks -- I thought I saw something on the list about it a couple days ago -- but I was thinking it was relating to something else. Well, I guess it is good to know that it isn't just my problem. But I know this basically halts what I'm doing. I've added it as a bug to the bugtracker: https://bugs.maemo.org/show_bug.cgi?id=5674 Nathan -Original Message- From: Julius Luukko [mailto:julle.luu...@quicknet.inet.fi] Sent: Wednesday, October 21, 2009 11:45 AM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? Nathan Anderson wrote: Try to install static depends: libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev zlib1g-dev python2.5 python2.5-dev [2009-10-21 12:30:46] fakeroot apt-get -y -q -o APT::Get::AllowUnauthenticated=1 install --no-remove libcurl3 libcurl3-dev libicu42 libicu42-dev clucene-core clucene-core-dev zlib1g-dev python2.5 python2.5-dev /dev/null (My depends are listed properly) Unpacking libssl0.9.8 (from .../libssl0.9.8_0.9.8g-15maemo4+0m5_armel.deb) ... Selecting previously deselected package libreadline4. Unpacking libreadline4 (from .../libreadline4_4.3-10.1+0m5_armel.deb) ... Selecting previously deselected package clucene-core. Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack): trying to overwrite `/opt', which is also in package base-files Hi Nathan, I reported the same problem a few days ago: http://lists.maemo.org/pipermail/maemo-developers/2009-October/021512.html No solution was found! -- Julius ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Ed, I have actually installed all the packages I have built and submitted to extras _inside_ my scratchbox from extras(-devel/testing) without any issues; in fact I needed install a dozen or so packages (some mine, some not) to make up all the dependancies on the one I was actually having the issues with and reported.This is the first package I've built that has relied upon a optified deb library. I had to actually wait to package this package up until I could get the optified ICU4.21 into the extras because I wanted to make sure that my scratchbox environment would match what the autobuilder would get. I never did a local install from the sources, I only did a apt-get install package to get my newly build packages back from the extras(-devel/testing) repositories. I can also build the source, armel and x86 of this package in my scratchbox using the dependancies I got from extra(dev/test). However, when I submit my nice source.deb to the autobuilder it fails with the /opt error I listed below. So even it their was some issue with scratchbox; there is still an serious issue with the autobuilder since it is not able to install optified deb packages it built using the maemo-optify program. Now as to if there is also a issue with scratchbox -- I can't see how; as I stated above I can ( have) installed the packages that the autobulder built and stuck into extras-develop for me. I have no issues inside my scratchbox. I do not have access to a n900 to test to see what happens on a real n900. Anyone who has a n900 want to try apt-get install clucene-core (you will need extras-devel enabled) and see if you get pretty much everything in /opt/maemo/usr/lib) Please remember the autobuilder built and optified all the .deb packages I am depending on. If I skipped the maemo-optify step in all my packages; we would not be having this discussion. ;-) So right now my choice is to rebuild and turn off the optifing step and theirby putting about _20_ megs of libraries into the /usr/lib folder or not do anything until a solution is found on why the autobuilder is having issues with .deb packages it built and optified. I'm not particlarly happy, having to wait, but having these packages optified makes a lot more sense to me. ;-) So I'm currently blocked. (Please note I am note the only person who has had this issue. I know of at least two others as of this moment.) If I do need to change something in my packages, I will! But I need to know what. Afaik, the only weirdity to these packages is adding the maemo-optify before the md5 generation step. Nathan. -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 1:26 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: ... Selecting previously deselected package clucene-core. Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives/clucene-core_0.9.21b-0maemo1_armel.deb (--unpack): trying to overwrite `/opt', which is also in package base-files Uhm, this is not good. Each of my optified packages throws this error. That kinda makes optifing the libraries a pointless exercise if I can't use them later in the buildbot. And Lib-icu is about 16 MEGS of libraries, so I would think it would be a great canidate for optification. Do I need to resubmit everything w/o optification, or are the build bots broken? Have you tried to reproduce this issue in your build environment by installing your library and base-files locally inside scratchbox? Below are my attempts to reproduce and fix the problem: This is what I see in autobulder environment: grep /opt$ /var/lib/dpkg/info/base-files.list /opt It means that /opt belongs to base-files package. And I can easily reproduce the error if I try to install any package with /opt directory inside it: fakeroot apt-get install clucene-core Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: clucene-core 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 319kB of archives. After unpacking 1085kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! clucene-core Install these packages without verification [y/N]? y Get:1 http://osso.stage.dmz fremantle/free clucene-core 0.9.21b-0maemo1 [319kB] Fetched 319kB in 0s (329kB/s) /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Selecting previously deselected package clucene-core. (Reading database ... 6395 files and directories currently installed.) Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... dpkg: error processing /var/cache/apt/archives
RE: Maemo-Optify Builder Bots = Broken?
Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt ls -l /targets/FREMANTLE_X86 | grep opt drwxr-xr-x 4 maemo sbox 4096 Oct 7 11:39 opt Dpkg -l base-files Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++---== == ii base-files 3.1.osso2+3.1.10.osso23+ Debian base system miscellaneous files Nathan P.S. I also put a bug report in earlier today at https://bugs.maemo.org/show_bug.cgi?id=5674 if you are handling it. ;-) -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 2:23 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, I have actually installed all the packages I have built and submitted to extras _inside_ my scratchbox from extras(-devel/testing) Good. In this case we just need to understand what's the difference between your environment and autobuilder one. Can you show me output of the following commands run inside scratchbox: ls -l / |grep opt dpkg -l base-files -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Ed, Here is my output. Looking through the list I do not appear to he -cputransp and -maemo3 ii scratchbox-core 1.0.16 Scratchbox base system ii scratchbox-devkit-apt-https 1.0.10 APT HTTPS devkit for Scratchbox ii scratchbox-devkit-debian1.0.10 Debian tools for Scratchbox ii scratchbox-devkit-doctools 1.0.13 Doctools for Scratchbox ii scratchbox-devkit-git 1.0.1 Git for Scratchbox ii scratchbox-devkit-perl 1.0.4 Perl modules for Scratchbox ii scratchbox-devkit-qemu 0.10.0-0sb5 Qemu scratchbox devkit ii scratchbox-devkit-svn 1.0 Subversion devkit for Scratchbox ii scratchbox-libs 1.0.16 Scratchbox libraries ii scratchbox-toolchain-cs2007q3-glibc2.5-arm7 1.0.12-10 cs2007q3-glibc2.5-arm7 compiler for Scratchb ii scratchbox-toolchain-cs2007q3-glibc2.5-i486 1.0.12-8 cs2007q3-glibc2.5-i486 compiler for Scratchb ii scratchbox-toolchain-host-gcc 1.0.16 Scratchbox host-gcc toolchain Nathan. Looks the same as in autobuilder environment. Can you show versions of scratchbox packages? This is what I have on autobuilder host: $ dpkg -l |grep scratchbox ii scratchbox-core 1.0.16 Scratchbox base system ii scratchbox-devkit-apt-https 1.0.10 APT HTTPS devkit for Scratchbox ii scratchbox-devkit-cputransp 1.0.9 CPU transparency methods ii scratchbox-devkit-debian 1.0.10 Debian tools for Scratchbox ii scratchbox-devkit-doctools1.0.13 Doctools for Scratchbox ii scratchbox-devkit-git 1.0.1 Git for Scratchbox ii scratchbox-devkit-maemo3 1.0.3 Maemo 3 devkit for Scratchbox ii scratchbox-devkit-perl1.0.4 Perl modules for Scratchbox ii scratchbox-devkit-qemu0.10.0-0sb5 Qemu scratchbox devkit ii scratchbox-devkit-svn 1.0 Subversion devkit for Scratchbox ii scratchbox-libs 1.0.16 Scratchbox libraries ii scratchbox-toolchain-cs2005q3.2-glibc2.5-arm 1.0.7.2 cs2005q3.2-glibc2.5-arm compiler for Scratch ii scratchbox-toolchain-cs2005q3.2-glibc2.5-i386 1.0.7 cs2005q3.2-glibc2.5-i386 compiler for Scratc ii scratchbox-toolchain-cs2007q3-glibc2.5-arm7 1.0.12-10 cs2007q3-glibc2.5-arm7 compiler for Scratchb ii scratchbox-toolchain-cs2007q3-glibc2.5-i486 1.0.12-8 cs2007q3-glibc2.5-i486 compiler for Scratchb ii scratchbox-toolchain-host-gcc 1.0.16 Scratchbox host-gcc toolchain -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Ed, Just tried on the armel target. [sbox-FREMANTLE_ARMEL: ~] apt-get install clucene-core clucene-core-dev Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: clucene-core clucene-core-dev 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 1043kB of archives. After unpacking 5292kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! clucene-core clucene-core-dev Install these packages without verification [y/N]? y Get:1 http://repository.maemo.org fremantle/free clucene-core 0.9.21b-0maemo1 [319kB] Get:2 http://repository.maemo.org fremantle/free clucene-core-dev 0.9.21b-0maemo1 [725kB] Fetched 1043kB in 3s (312kB/s) /scratchbox/tools/bin/sh: line 1: /usr/sbin/dpkg-preconfigure: No such file or directory Selecting previously deselected package clucene-core. (Reading database ... 27948 files and directories currently installed.) Unpacking clucene-core (from .../clucene-core_0.9.21b-0maemo1_armel.deb) ... Selecting previously deselected package clucene-core-dev. Unpacking clucene-core-dev (from .../clucene-core-dev_0.9.21b-0maemo1_armel.deb) ... Setting up clucene-core (0.9.21b-0maemo1) ... Setting up clucene-core-dev (0.9.21b-0maemo1) ... As you can see no issues. --- In the meantime I had also posted on Talk; and just got confirmation that both clucene-core and clucene-core-dev installed fine on a real n900. http://talk.maemo.org/showthread.php?p=354509 Nathan. -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 3:00 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt ls -l /targets/FREMANTLE_X86 | grep opt drwxr-xr-x 4 maemo sbox 4096 Oct 7 11:39 opt Oops, sorry. I've overlooked that you're using X86 target. Autobuilder used armel target when it failed. You can see it here: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/armel.root.l og.FAILED.txt Try to install your packages in armel target, please. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Ed, I believe this is what you are asking: FREMANTLE_ARMEL cs2007q3-glibc2.5-arm7 FREMANTLE_X86cs2007q3-glibc2.5-i486 Nathan -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 4:03 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt I've found the difference! In your environment /targets/target/opt is a directory. In autobuilder environment it's a symlink: ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 builder1 builder19 Oct 21 23:50 opt - /home/opt And it looks like it becomes symlink after rootstrap unpacking. Look: [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf re -f [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 1005 1006 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --etc --devkits [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --fakeroot Installing fakeroot version 1.4.2.1... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf rs /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz Unpacking rootstrap... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 1005 10069 Oct 21 23:57 opt - /home/opt So, the difference is in rootstraps. Tell me which rootstrap do you use and I'll compare it with the one autobuilder uses. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-Optify Builder Bots = Broken?
Kamen, I build both binary target and source targets debs in my scratchbox before I upload.For instance last night I had to rebuild the binary debs about 20 times (trying to get a weird make file rule to work). Once I got it working then I would copy my rules to a fresh copy and re-run a source deb then re-run a binary once more just to make sure it wasn't left over stuff causing a success. ;-) So, I don't think it has anything to do with the scratchbox. I suspect it as Ed found something to do with the symlink - directory or something in their on the auto-builder. Nathan. _ From: Kamen Bundev [mailto:bun...@gmail.com] Sent: Wednesday, October 21, 2009 6:14 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? Nah, that's not enough. Still fails. Another difference is that I'm building my optified package in scratchbox before upload and the other people are using the autobuilder, so the problem should be somewhere else. Regards: Bundyo On Thu, Oct 22, 2009 at 2:09 AM, Kamen Bundev bun...@gmail.com wrote: Nah, that's not enough. Still fails. Regards: Bundyo On Thu, Oct 22, 2009 at 12:52 AM, Kamen Bundev bun...@gmail.com wrote: Looks like the only difference here is that my /opt should be pointing to /targets/links/opt which is symlinked to the proper target on target change. Uploading the new package to extras now. Regards: Bundyo On Thu, Oct 22, 2009 at 12:39 AM, Nathan Anderson nat...@andersonsplace.net wrote: Ed, I believe this is what you are asking: FREMANTLE_ARMEL cs2007q3-glibc2.5-arm7 FREMANTLE_X86cs2007q3-glibc2.5-i486 Nathan -Original Message- From: Ed Bartosh [mailto:bart...@gmail.com] Sent: Wednesday, October 21, 2009 4:03 PM To: Nathan Anderson Cc: maemo-developers@maemo.org Subject: Re: Maemo-Optify Builder Bots = Broken? 2009/10/21 Nathan Anderson nat...@andersonsplace.net: Ed, Sure can (and following the chain). ls -l / | grep opt lrwxrwxrwx1 root root 18 Oct 6 22:36 opt - /targets/links/opt ls -l /targets/links/ | grep opt lrwxrwxrwx 1 maemo 1000 26 Oct 19 16:55 opt - /targets/FREMANTLE_X86/opt I've found the difference! In your environment /targets/target/opt is a directory. In autobuilder environment it's a symlink: ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 builder1 builder19 Oct 21 23:50 opt - /home/opt And it looks like it becomes symlink after rootstrap unpacking. Look: [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf re -f [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 1005 1006 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --etc --devkits [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf in --fakeroot Installing fakeroot version 1.4.2.1... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt drwxrwxr-x 2 builder1 builder1 4096 Oct 21 23:56 opt [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] sb-conf rs /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz Unpacking rootstrap... [sbox-maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c: ~] ls -l /targets/maemo5-arm-183e1d1de998260fa89b870d65b22998c6908b6c/ |grep opt lrwxrwxrwx 1 1005 10069 Oct 21 23:57 opt - /home/opt So, the difference is in rootstraps. Tell me which rootstrap do you use and I'll compare it with the one autobuilder uses. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Optification of dev libraries
Marius, Well, I agree dev packages are not really the target of a device. And as a dev I would probably feel comfortable moving things around (if they wanted to). I just noticed that about 75% of the .h files were optified and the rest weren't, and wanted to bring it up. Not really a huge issue. As a policy I've been optifing all the files it creates. Dev files actually would be a good canidate imho for the /opt folder since they aren't accesses often and can be large. Adding some more command line options might be useful. Nathan. ext Nathan Anderson nat...@andersonsplace.net writes: I noticed when I ran optification of a dev library is optified about 75% of the c/c++ .h files. I would think for consistancy sake maybe we should either optify all of them or none of them. Hmm, I think -dev libraries are not the primary target of optification right now. Would it be acceptable to have 'official' instructions (or a script) for moving all of /usr to the eMMC? I think this is preferable to using optified packages and people who want to develop on the device are probably willing and able to follow those instructions. Yes, No? But if we optify a -dev package, we should probably tune the heuristic. Many -dev packages install into /usr/include/name/ where name is close to but not exactly the same as the package name. Right now, maemo-optify only moves whole directories if they are named exactly like the package. We could improve this heuristic carefully, or add some command line options or a control file for maemo-optify. I think the latter would be more useful. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Optification of dev libraries
Marius, I noticed when I ran optification of a dev library is optified about 75% of the c/c++ .h files. I would think for consistancy sake maybe we should either optify all of them or none of them. Yes, No? Nathan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Cmake + Armel + Fremantle = Segfault
According to a set of posts on this mailing list this is a known issue (http://www.mail-archive.com/maemo-developers@maemo.org/msg20041.html); but I didn't see a resolution to this. As more developers start working on moving packages to the fremantle OS, this is going to crop up more and more. Can we come to some sort of conclusion on this so that we can get this fixed asap? The only two solutions I've seen presented are: 1. Putting of a non-arm binary in the extras-devel repository (i.e. a scratchbox host x86 cmake) so that we can use it as a dependancy. 2. Or the gatekeepers of the builder to add a new cmake to the devkit in the auto-build environment -- and have this cmake published (in a garage project?) so that the devs can get it so they can use it locally to test the compiling of apps on their scratchboxes armel targets. I think the devkit-cmake (or maybe it should be named scratchbox-cmake) idea is the simplist to implement -- and doesn't require the build-keepers to do anything. Or do we need to create a new repository (i.e. fremantle/scratchbox) so that any other tools we find broken in the future can be put in their to keep x86 binaries out of the repository. Nathan. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
