The latest nightly cdimages / ISO's are above 710 megs
Hello! I know I'm subscribed to the digest for this mailing list so I don't know if it's been addressed yet, but it's not just the amd64 cd images. I've noticed that they're all too big since. At least since the 12th September. For people wanted to test actual hardware I think it may be a problem if the cd images remain so big as they won't be able to burn them. I filled a bug about this: https://bugs.edge.launchpad.net/ubuntu/+bug/139646 Cheers, Tim -- Forwarded message -- From: Scott Ritchie [EMAIL PROTECTED] To: Murat Gunes [EMAIL PROTECTED] Date: Sun, 16 Sep 2007 21:41:53 -0700 Subject: Re: The latest amd64 nightly desktop ISO is 730 megs Murat Gunes wrote: Bryce wrote: That really does not make any sense if thats the case. What is the point in making daily images available for testing if know one is going to be able to use them? Not many daily images end up oversized. If it were a substantial percentage of all images, you'd have a point. With the current state of things, people can wait a day, or two at worst, or use the image from a day or two before (I think jidgo is not an option with the live CDs, but should be usable with the alternate CD; I'd be happy if someone could confirm this). It's not realistic to expect all uploads to be concerted to such an extent as to be able to meet a certain maximum size on a daily basis. Scott Ritchie wrote: Perhaps the build script should throw up a warning somewhere. Otherwise there's almost no point to having them. I think it creates files that end with .OVERSIZED corresponding to the image that ends up being oversized. m. In this case it didn't - I didn't even come across a warning. Honestly it would be best if no image was made, rather than an unburnable one. Nothing wrong with skipping a few days when the nightly isn't buildable. Thanks, Scott Ritchie -- 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-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
usplash logo distorted
Hello all, I wanted to ask about the widescreen boot up splash/logo. My concerns have been raised at: https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/64147 In specific, from the bug report: There are only 4:3 and 16:9 themes. It picks the closest. I can understand if you don't want to make a lot of different logos, but: 16:9 is a standard TV format for widescreens. 16:10 is a more widespread format amoung computers, especially laptops! I found some popular formats for widescreens and their respective ratios. See for yourselves: 1280 x 768 = 16:9.6 (closer to 16:10 than 16:9) 1280 x 800 = 16:10 1366 x 768 = 16:9 1440 x 900 = 16:10 1920 x 1200 = 16:10 4 out of 5 of these resolutions are 16:10. Unless I'm not seeing something here, 16:10 should be in there instead of 16:9. I know that it's only a look thing and doesn't take from functionality, but it may take a bit from perceived quality as it's the very first thing that people see when trying ubuntu. Is this difficult to change? Cheers, Tim -- 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: The latest amd64 nightly desktop ISO is 730 megs
On Mon, 2007-09-17 at 07:37 +0300, Murat Gunes wrote: Not many daily images end up oversized. If it were a substantial percentage of all images, you'd have a point. With the current state of things, people can wait a day, or two at worst, or use the image from a day or two before (I think jidgo is not an option with the live CDs, but should be usable with the alternate CD; I'd be happy if someone could confirm this). Jigdo doesn't work with live CDs as they are just one file afaik. I would also expect it to have problems with daily snapshots in general as old versions of files are deleted from the archive meaning that I'd expect you'd get incomplete images. Jigdo can have this problem with our packages anyway as the images are not updated when a package is replaced by eg a security update. I have some ancient bugs opened about it somewhere. You can fix with rsync but it's not very user friendly. Caroline -- 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: That need to close bugs?
On 12/09/2007, Onno Benschop [EMAIL PROTECTED] wrote: 2. While Dapper isn't the bleeding edge of Ubuntu, code that exists in Dapper exists in Feisty and Gutsy today. That implies that bugs that exist in Dapper are also likely to exist. Disk space is cheap. A computer is great at searching stuff. Leave the bug in the system, leave it open so others can stumble upon it and not feel that they are the first to experience this problem. Debugging is as much about writing code as it is about the ah-ha moment in which someone determines the cause of the problem. What is the rationale behind skipping closed bugs in a search? I've been burned by this in the past. I can understand why the QA guys or the even developers would want this but for a user, who is actually making the effort to not only report a bug but to search for dups first, why would they want to ignore closed bugs? Closed bugs often contain exactly what that user needs - a workaround or a timeline for the fix to be released, F -- 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: That need to close bugs?
On Mon, 17 Sep 2007 10:27:49 +0100, Fergal Daly [EMAIL PROTECTED] said: On 12/09/2007, Onno Benschop [EMAIL PROTECTED] wrote: 2. While Dapper isn't the bleeding edge of Ubuntu, code that exists in Dapper exists in Feisty and Gutsy today. That implies that bugs that exist in Dapper are also likely to exist. Disk space is cheap. A computer is great at searching stuff. Leave the bug in the system, leave it open so others can stumble upon it and not feel that they are the first to experience this problem. Debugging is as much about writing code as it is about the ah-ha moment in which someone determines the cause of the problem. What is the rationale behind skipping closed bugs in a search? I've been burned by this in the past. I can understand why the QA guys or the even developers would want this but for a user, who is actually making the effort to not only report a bug but to search for dups first, why would they want to ignore closed bugs? Closed bugs often contain exactly what that user needs - a workaround or a timeline for the fix to be released, F Yes, yes, yes. As a sometimes-bug-filing-user, I would just like to just underline the above. Thanks Fergal. Best Regards Hugo Heden -- http://www.fastmail.fm - IMAP accessible web-mail -- 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: update-db cron job: solving a long-standing issue
On Mon, 2007-09-17 at 08:03 +0200, Martin Pitt wrote: Milan [2007-09-15 16:54 +0200]: We can also think (and this is my opinion ;-) ) that the locate command is only used by advanced users that now how to install slocate in two minutes, and thus that we don't need to install it by default. Newbies don't use locate in a terminal, but Tracker in GNOME. I fully agree. Installing *two* search tools by default is too much. We probably should not uninstall locate on upgrades, but we should not put it into new installations. One is painful enough (although they do not server the same purpose: locate only indexes file names, while tracker indexes your entire file system, which is much more heavyweight). Sounds entirely reasonable to me; -server might choose to retain it, but they don't have trackerd. Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- 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
Why is amd64 late?
Hi, Why is the amd64 release/tribe always late? My favorite example is about the Xen support: http://packages.ubuntu.com/gutsy/base/linux-image-2.6.22-11-xen It is i386 only at the moment... As far as I know, Ubuntu tries to be up to date and tries to support the maximum of hardware as possible. And recent hardware is mostly amd64. So, I probaly missed something: the reason. Would you help me to understand? Thank you. :) -- 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: The latest nightly cdimages / ISO's are above 710 megs
On Mon, Sep 17, 2007 at 08:29:10AM +0100, Tim Kersten wrote: I know I'm subscribed to the digest for this mailing list so I don't know if it's been addressed yet, but it's not just the amd64 cd images. I've noticed that they're all too big since. At least since the 12th September. For people wanted to test actual hardware I think it may be a problem if the cd images remain so big as they won't be able to burn them. Yes, we'll be sorting this out before beta. I filled a bug about this: https://bugs.edge.launchpad.net/ubuntu/+bug/139646 Please don't file bugs about this in future. They tend not to get noticed by the people who actually reduce the CD size again, and they just hang around until somebody remembers to close them. Furthermore, we don't need bugs about this as it's automatically a release blocker for CDs to be oversized. -- Colin Watson [EMAIL PROTECTED] -- 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: update-db cron job: solving a long-standing issue
On Mon, Sep 17, 2007 at 08:03:49AM +0200, Martin Pitt wrote: Milan [2007-09-15 16:54 +0200]: We can also think (and this is my opinion ;-) ) that the locate command is only used by advanced users that now how to install slocate in two minutes, and thus that we don't need to install it by default. Newbies don't use locate in a terminal, but Tracker in GNOME. I fully agree. Installing *two* search tools by default is too much. We probably should not uninstall locate on upgrades, but we should not put it into new installations. One is painful enough (although they do not server the same purpose: locate only indexes file names, while tracker indexes your entire file system, which is much more heavyweight). The idea of removing locate annoys me. I've spent too much time in past jobs fighting broken commercial Unix systems that decided to break (or didn't bother to test) standard Unix tools like man and locate. If you're working with a variety of different systems then this sort of thing is a real pain. Can we not come up with a way to generate the locate database from tracker instead? -- Colin Watson [EMAIL PROTECTED] -- 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: update-db cron job: solving a long-standing issue
Le lundi 17 septembre 2007 à 08:03 +0200, Martin Pitt a écrit : I fully agree. Installing *two* search tools by default is too much. We probably should not uninstall locate on upgrades, but we should not put it into new installations. That will break gnome-search-tools (the panel item to search files) which uses it at the moment. We should probably sort the issues with the different interfaces before removing it. Cheers, Sebastien Bacher -- 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: update-db cron job: solving a long-standing issue
On 17/09/2007 Mark Schouten wrote: Can we not come up with a way to generate the locate database from tracker instead? I prefer this too. I also think it is good to think about newbies, but is it really necessary to ignore more advanced users just because they know what they're looking for? I know I would be annoyed if locate was missing on my server. I am worried about system files creating noise in tracker searches, so that one finds non-relevant information for precise queries. If a locate-tracker package existed, I would expect it to be easy uninstallable without uninstalling tracker, and queries to default to user files only, enabling system-wide queries as an option. Vincenzo -- 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: The latest amd64 nightly desktop ISO is 730 megs
Bryce [EMAIL PROTECTED] writes: That really does not make any sense if thats the case. What is the point in making daily images available for testing if know one is going to be able to use them? You can always burn them on a DVD, or use it in a VM like qemu or vmware. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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: update-db cron job: solving a long-standing issue
On Mon, 2007-09-17 at 12:27 +0100, Colin Watson wrote: I fully agree. Installing *two* search tools by default is too much. We probably should not uninstall locate on upgrades, but we should not put it into new installations. One is painful enough (although they do not server the same purpose: locate only indexes file names, while tracker indexes your entire file system, which is much more heavyweight). The idea of removing locate annoys me. I've spent too much time in past jobs fighting broken commercial Unix systems that decided to break (or didn't bother to test) standard Unix tools like man and locate. If you're working with a variety of different systems then this sort of thing is a real pain. Can we not come up with a way to generate the locate database from tracker instead? I prefer this too. I also think it is good to think about newbies, but is it really necessary to ignore more advanced users just because they know what they're looking for? I know I would be annoyed if locate was missing on my server. Mark Schouten aka Jeeves_ -- 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: update-db cron job: solving a long-standing issue
snip I don´t know if that already happens, but the same way updatedb could be instructed to do a 'delta' only and leave unchanged files alone (instead of update the whole db each time). # time /etc/cron.weekly/slocate real1m6.354s user0m0.247s sys 0m0.581s # time /etc/cron.weekly/slocate real0m0.548s user0m0.110s sys 0m0.426s The second run was right after, so i think slocate is allready doing the 'delta' thingy. Scott K -- Thilo key: 0x4A411E09 -- 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: The latest nightly cdimages / ISO's are above 710 megs
On 9/17/07, Colin Watson [EMAIL PROTECTED] wrote: On Mon, Sep 17, 2007 at 08:29:10AM +0100, Tim Kersten wrote: I know I'm subscribed to the digest for this mailing list so I don't know if it's been addressed yet, but it's not just the amd64 cd images. I've noticed that they're all too big since. At least since the 12th September. For people wanted to test actual hardware I think it may be a problem if the cd images remain so big as they won't be able to burn them. Yes, we'll be sorting this out before beta. I filled a bug about this: https://bugs.edge.launchpad.net/ubuntu/+bug/139646 Please don't file bugs about this in future. They tend not to get noticed by the people who actually reduce the CD size again, and they just hang around until somebody remembers to close them. Furthermore, we don't need bugs about this as it's automatically a release blocker for CDs to be oversized. Sorry about that. Won't happen again :-) -- 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: The latest nightly cdimages / ISO's are above 710 megs
On Mon, Sep 17, 2007 at 08:29:10AM +0100, Tim Kersten wrote: For people wanted to test actual hardware I think it may be a problem if the cd images remain so big as they won't be able to burn them. As a temporary measure, they work fine if you burn them to a DVD RW (which is what I do) Also, there's a technique called overburning, as described here: http://www.cdrinfo.com/Sections/Reviews/Specific.aspx?ArticleId=6093 -- 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: update-db cron job: solving a long-standing issue
Mark Schouten said: I prefer this too. I also think it is good to think about newbies, but is it really necessary to ignore more advanced users just because they know what they're looking for? I know I would be annoyed if locate was missing on my server. We're not talking about servers but only Desktop versions. Of course, on servers admin should need it. Note I'm not hating locate by principle, but because it makes sometime computers hang without explanation. If we could use a more comprehensive way of indexing files, like Tracker does (ie when you do'nt work), this could be OK. Comparison with Tracker is not accurate because of this feature. rlocate seems to be resource-intensive too, because it needs a complete rescanning every 10 starts or so. IMHO, a workaround with find and dpkg is not so bad for occasional usages, and 'apt-get install slocate' is easy for anybody using the command-line. Colin Watson said: Can we not come up with a way to generate the locate database from tracker instead? Beagle does this for system-wide documentation, AFAIK. So this is possible, only taking care of the filenames. (But Beagle was eating CPU doing this too, though it is not necessary.) The dependencies point should be investigated more, but AFAIK gnome-utils (ie gnome-search-tool) doesn't depend on locate. Is it able to use find ? Anyway, I've opened a bug here: https://bugs.launchpad.net/ubuntu/+source/slocate/+bug/140493 We should use it when we have found a common position. -- 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: python-cjson is on Debian but not on Ubuntu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Another missing package in Gutsy is the emboss suite, even though it is in Sid: http://packages.debian.org/sid/emboss - -- Morten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG7s0hB4zzG0BIJecRAhWOAJ0Q0nkoYOS+r3igcIP4FlWyTqMkNQCfSXq+ WMvqce3IwMOKG+sWkdiUQMM= =uUDE -END PGP 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: python-cjson is on Debian but not on Ubuntu
On 9/17/07, Scott Kitterman [EMAIL PROTECTED] wrote: It wasn't in Sid when the auto-sync was turned off. It'll be automatically sync'ed for Hardy. Scott K For Hardy, could there be made a distinction between autosyncing new versions and autosyncing new packages? Autosyncing new packages could continue to sync new packages long after the importfreeze until universe new packages freeze. Wouter -- 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
Apturl (security) issues and inclusion in Gutsy
Hello, I would like to discuss the recent inclusion of apturl in the Gutsy default installation. The idea of apturl is great but the current implementation has a lot of issues, some of which I will list here: 1. It's possible to run arbitrary scripts in the preinst/postrm phase of dpkg installation or the installed program itself could be malicious. By allowing the repository to be specified the deb can come from anywhere. So, you've basically got just a yes/no dialog stopping arbitrary code execution. (Not far from UAC and ActiveX in windows.) 2. Repositories added through apturl could provide packages included in Ubuntu but with higher version numbers with malicious code. 3. there should be a VERY OBVIOUS visual indication of whether the program is going to be installed from the official repos or some third party site (right now it is not) 4. It is not well maintained. In the two months that it has been in the archives, 20 bugs have been reported, none have been fixed. Only one had a response and that is a bug about a spelling mistake in the package description. (all together it seems to have been uploaded only to enable the plugin wizard in firefox to work, after whcich it hasn't had any more attention) 5. It hasn't had a lot of testing. It wasn't mentioned in any of the tribe release notes. There hasn't been a post in the dev-link forum or on the mailing lists. So not many people know about it or have tested it. 6. It functions for firefox only, even though solutions to enable it for konqueror and opera have been provided in bug report. This makes it impossible for a website to provide an install this link for an Ubuntu package. They have to mention that it only works if you are running firefox, not if you are a kubuntu user running konqueror for example. 7. There is currently no way for a website to know whether apt urls will work on the users operating system. If a website provides an apt install link it will be broken for feisty and earlier ubuntu versions or other linux distributions, 8. making people enter their sudo password in a popup you got from clicking on a link on an arbitary website is definitely not secure. 9. apturl in its current version doesn't show the package description so people don't have a clue about what they are about to install other than the information provided on the website Conclusion: apturl is a great idea, but needs some work before it can be included and enabled by default on Ubuntu. In its current form it would do Gutsy more harm than good. With some work I think Gutsy could ship with it if for now it would only allow installation of packages from the official ubuntu repositories. Adding of third party repositories by clicking a weblink is something that at least needs some discussion and imho should not be done at all. Cheers, Wouter n.b. link to apturl bug list: https://bugs.launchpad.net/ubuntu/+source/apturl -- 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: That need to close bugs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As one of those who triages various KDE bugs...in the area of KDEBase, in particular, there are around 450 open bugs, we *have* to close invalid bugs. There are around 750, with the INVALID and WONTFIX bugs included. There is simply no way to deal with the current lot of open bugs, to get an overview of them all, let alone having the invalid ones in there - the problem gets too great, and you can't solve any of it (and become very demotivated in the process). Just my AUD $0.02 Hobbsee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG7qDu7/o1b30rzoURAn/kAKDsqfdUAQ7YaI+1bb4NA4wSd1oxcgCdFZaS 3hsxCXDhMM2YfaKO3ypZqTA= =DRYI -END PGP 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
