Re: Considerations about official localized editions of Live CDs
On Thu, Dec 17, 2009 at 9:09 PM, Aron Xu wrote: > Hi Balmashnov, > > Thanks for your info, to be honest I hadn't seen that buleprint before. > I know that making a customized distribution is not too difficult, but > the problem is not just "make" a distribution, and I've explained in > previous reply to Arne. :) > > Have a nice day! > Aron Xu > > On Fri, Dec 18, 2009 at 5:20 AM, Alexey Balmashnov > wrote: >> For your info, after discussion within Russian team I tried to propose >> some ideas on officially approved Add-On CD generator: >> https://blueprints.edge.launchpad.net/ubuntu/+spec/add-on-cd-composer >> >> Did not get any comments, apart from standard: there is an easy way >> (bite me!) to make your own distribution. Look, some people have done >> it! (with pointers to >> based-on-ubuntu-local-distributions-which-are-not-Ubuntu-anymore-at-least-officially). >> >> Cheers, >> Alexey Balmashnov >> > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > I love this idea! It will be a considerable amount of overhead for canonical to get ( EVEN ) more CDs, but it would be a great step to a truly global operating system. -Paul -- #define sizeof(x) rand() :wq -- 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: Solang or Shotwell vs. F-Spot for Lucid
> Solang, Shotwell, and F-Spot are all fine image managers/organizers, > but the current plan is to work on F-Spot to get it to meet the > following needs: > * Quickly viewing images by folder [currently handled by EOG] > * Solang and F-Spot both have view-modes but still > require importing the image. Shotwell might not. > * Editing images without importing (Shotwell does this) > * Rotating [currently handled by EOG] > * Red-eye removal [currently handled by GIMP] > * Cropping [currently handled by GIMP] > * optional: Annotating (like making lolcat) [currently > handled by GIMP] > * optional: Painting on it [currently handled by GIMP] Resizing and saving the file in another file format are also common in-folder image manipulation tasks. Personally I prefer Gthumb over EOG or F-Spots view-mode, since it is fast, easy to use and has enough features. If I had the power, I'd replace EOG with Gthumb and make Gthumb the default program associated to all image file types. Current situation sucks. Even Windows XP's in-folder image manipulation is better.. Shotwell looks nice, but I'm a bit sceptic about new software and how mature they are. -- 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
vim-gnome (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Fresh install Ubuntu 9.10, and use synaptic to get vim and vim-gnome. In a terminal window, I run gvim and get: ** (gvim:2140): CRITICAL **: gtk_form_static_set_gravity: assertion 'static_gravity_supported' failed I see five lines with this message. Please fix it. Thanks. Classification: UNCLASSIFIED Caveats: NONE -- 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
Fwd: Introduction to Ubuntu Distributed Development
Lets be very clear here: the choice between git / bzr / hg in comparison to the tasks developers perform approach 0 relevance. Typing "bzr commit" vs. "git commit" does not matter to anyone when we are working on thousands of lines of source and intricate packaging. Launchpad has been built around bzr, and as someone who likes to get things done and not send emails, that is an easy and pragmatic choice. If you would like a more detailed email summarizing how to do commands and operations between hg / git / bzr, I will be more than happy to provide it so we can focus on the big picture. We could also offer an IRC class if there is enough interest, it could easily be done in under an hour. Thanks, Steve On Thu, Dec 17, 2009 at 11:59 AM, Adrian Perez wrote: > Your point is accurate. > But you might agree that work was accomplished by several people, and > not a single person. No need to tell us that you need a Git-enable infra > to compare with, when you know that can't be accomplished without the > community support as has the bzr one evolved from both canonical and the > community itself. > I'm not aware of the exact numbers, but I think you could find more > packages on git.debian.org than on bzr.debian.org; take that as an > example. > Said that, I don't think this discussion is going to drive us longer > than this, so I was just exposing my points. > > -- > Best Regards, > > Adrian Perez > Ubuntu Developer > > GPG Key ID: 8A9A3084 > GPG Key Fingerprint: 99E8 E74E 7B4F 93AE F32A 5523 9973 0D5C 8A9A 3084 > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- GPG Key ID: C92EF367 / 1428 FE8E 1E07 DDA8 EFD7 195F DCCD F5B3 C92E F367 WWW: http://www.sharms.org/blog -- 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
A problem with GSL and ROOT
I want to flag the followinq problem I meat building ROOT[1] on Kubuntu-9.10 (K-9.10). When 'configure' finds GSL on the system then a component of ROOT, called MathMore, is enabled for the build: [...] Checking for gsl/gsl_version.h ... /usr/include Checking for GSL version >= 1.8 ... ok Checking for libgsl, gslML, or gsl ... /usr/lib64 Checking for libgslcblas, gslcblasML, gslcblas, or cblas ... /usr/lib64 Checking whether to build libMathMore ... yes [...] But on K-910 it fails in this way: [...] g++ -shared -Wl,-soname,libNetx.so.5.25 -m64 -O2 -o lib/libNetx.so.5.25 net/netx/src/TXNetFile.o net/netx/src/TXNetFileStager.o net/netx/src/TXNetSystem.o net/netx/src/G__Netx.o -Llib -lNet -lRIO -lThread -Lnet/xrootd/src/xrootd/lib -lXrdOuc -lXrdSys -lXrdClient -Llib -lCore -lCint -ldl /usr/bin/ld: /usr/lib64/libgslcblas.a(sasum.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libgslcblas.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [lib/libMathMore.so] Errore 1 make: *** In attesa di lavori non terminati... ==> lib/libMatrix.so done ==> lib/libGeom.so done ==> lib/libNetx.so done rm core/utils/src/RStl_tmp.cxx core/utils/src/rootcint_tmp.cxx I flagged this to ROOT guys and they changed the configure test so that if 'libgslcblas.a' is found but built without '-fPIC', MathMore is disabled. This is a pity because on Kubuntu-8.04 ROOT builds fine with all its components. Thanks, Angelo. --- [1] http://root.cern.ch -- 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: Introduction to Ubuntu Distributed Development
On Thu, Dec 17, 2009 at 12:19 PM, Scott James Remnant wrote: > On Thu, 2009-12-17 at 11:59 -0500, Adrian Perez wrote: > >> But you might agree that work was accomplished by several people, and >> not a single person. No need to tell us that you need a Git-enable infra >> to compare with, when you know that can't be accomplished without the >> community support as has the bzr one evolved from both canonical and the >> community itself. >> > Nothing is stopping any Ubuntu Developer (even those who work for > Canonical) from building things with GIT or Mercurial if they like. I > take the fact that none of them are doing it as a sign that none of them > actually want it. I think that approach might be a bit deceiving. It has been pretty clear from the beginning that Launchpad (and hence Ubuntu to a great extent) was going to use bzr and only bzr. I would suggest that Ubuntu uses bzr primarily because Canonical created bzr and not because it was far and away the greatest DVCS out there at the time. I think it's pretty clearly a case of "those who fund the tools get to pick the tools". That's not necessarily bad or anything, but I think it's an important thing to acknowledge how decisions get made. > Indeed, the overwhelming feeling towards GIT I get from #ubuntu-devel is > one of dislike rather than love. Is that because of culture or quality of tools? I'm guessing people who would rather use git/hg just learn to shut up because it doesn't matter. I would also guess that the number of Ubuntu Developers who'd like to see more git support in Ubuntu is pretty significant. A whole lot of upstreams are moving to git and Debian is increasingly doing so as well. Having tools in common with the other people working on the code is often more important than the actual tool itself and having to learn multiple DVCSes is a pain. > If I'm wrong, and there's a hoard of developers aching to use GIT > instead of bzr, then vote with your code editor! :-) That is true, but it is also quite difficult to do. Canonical pretty much has the monopoly on the Ubuntu infrastructure and has said that non-bzr tools will not be supported by Launchpad. Without Launchpad support it's not exactly a very level playing field. I'm not suggesting that Ubuntu should ditch bzr or throw away all the hard work that's been done especially in the last year. But let's not kid ourselves either, Ubuntu uses bzr because it was selected for us by sabdfl/Canonical, not because we collectively decided that it was the way to go. I really don't see Ubuntu moving away from bzr as a lot of time and effort has already been put into making it the de facto standard and it basically gets the job done. I just hope the git <--> bzr and hg <--> bzr tools reach a level where the choice of DVCS isn't an issue. Interestingly, it actually seemed a lot easier when everybody was using SVN and we just got to pick which *-svn we used. :-) -Jordan -- 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
karmic: libghc6-src-exts-dev install failed: missing dependency
Hello,
installation of libghc6-src-exts-dev fails because of unmet dependencies.
Correponding bug report:
https://bugs.launchpad.net/ubuntu/+source/haskell-src-exts/+bug/496274
See the bottom for more information.
Is there any chance to get this repaired?
Greetings
ben
anabe...@sheldon:~$ sudo aptitude install libghc6-src-exts-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages are BROKEN:
libghc6-src-exts-dev
The following NEW packages will be installed:
cpp-4.1{a} g++-4.1{a} gcc-4.1{a} gcc-4.1-base{a} ghc6{a}
libffi-dev{a}
libghc6-cpphs-dev{a} libgmp3-dev{a} libgmpxx4ldbl{a}
libstdc++6-4.1-dev{a}
0 packages upgraded, 11 newly installed, 0 to remove and 17 not
upgraded.
Need to get 44.2MB of archives. After unpacking 259MB will be used.
The following packages have unmet dependencies:
libghc6-src-exts-dev: Depends: libghc6-cpphs-dev (< 1.7+) but 1.9-1 is
to be installed.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
libghc6-src-exts-dev [Not Installed]
Score is -9881
Accept this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
Abort.
anabe...@sheldon:~$ sudo aptitude show libghc6-src-exts-dev
Package: libghc6-src-exts-dev
State: not installed
Version: 1.0.1-1build1
Priority: optional
Section: universe/devel
Maintainer: Ubuntu Developers
Uncompressed Size: 15.5M
Depends: ghc6 (>= 6.10.4-1ubuntu2), ghc6 (< 6.10.4+), libghc6-cpphs-dev
(>=
1.7-2), libghc6-cpphs-dev (< 1.7+), libc6 (>= 2.4), libffi5 (>=
3.0.4),
libgmp3c2
Suggests: libghc6-src-exts-doc, libghc6-src-exts-prof
Description: Haskell-Source with eXtensions library for GHC6
haskell-src-exts (HSX, haskell-source with extensions) is an extension
of the
standard haskell-src package, and handles most common syntactic
extensions to
Haskell, including:
* Multi-parameter type classes with functional dependencies
* Indexed type families (including associated types)
* Empty data declarations
* GADTs
* Implicit parameters (ghc and hugs style)
* Template Haskell
Homepage: http://www.cs.chalmers.se/~d00nibro/haskell-src-exts/
%%
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
--
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: Introduction to Ubuntu Distributed Development
Jordan Mantha [2009-12-17 13:15 -0500]: > I would suggest that Ubuntu uses bzr primarily because Canonical > created bzr and not because it was far and away the greatest DVCS > out there at the time. But it was! Ever tried to use tla? It was almost as complicated as git (SCNR), slow, and far from being well-known/widespread. At "that time", DVCS were a pretty new thing in practical development life. > Interestingly, it actually seemed a lot easier when everybody was > using SVN and we just got to pick which *-svn we used. :-) Except that svn is not distributed, and didn't even have branches, so it's utterly useless for the things we are trying to achieve here :-) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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: Considerations about official localized editions of Live CDs
(Posted just to ubuntu-devel-discuss@lists.ubuntu.com, as I don't think my mail is relevant to the other lists) On Fri, Dec 18, 2009 at 2:26 PM, Paul Tagliamonte wrote: > > I love this idea! > > It will be a considerable amount of overhead for canonical to get ( > EVEN ) more CDs, but it would be a great step to a truly global > operating system. > I can see three forms of cost: 1) Ship-it cost 2) Space on mirrors. 3) Effort to generate images. Are these the main form of overhead? If [1] is a problem we could only ship one type of CD. IMHO ship-it is only of limited use anyway and if we are going to mail people a disk we may as well mail a DVD; cost is clearly an issue and DVDs can be a bit more expensive e.g. 50c vs. 40c *, but that does not seem a big deal if the DVD is only shipped to countries not supported by the main CD. Space on the mirrors does not seem too much of an issue as the country mirrors should only need one localisation. Presumably adding 1TB of storage to archives.ubuntu.com isn't a big deal. It would be kind of cool if the localized live cds could be generated with a script (similar to jigdo) avoiding this whole issue. The human effort to generate the images should not be too great if it is done by a script. The CPU time shouldn't be a big deal either since the disk images are only released once every few months. * according to: http://www.dvddemystified.com/dvdfaq.html#5.1 -- John C. McCabe-Dansted -- 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: Introduction to Ubuntu Distributed Development
Considering that ship has already sailed a long time ago, I don't think its wise to waste lumber on another ship when it is already needed elsewhere. If the bzr galleon runs aground or hits an iceberg in the future, however, things may change. Not being a developer myself I'm not aware of bzr's shortcomings/virtues, or those of git/hg, but if frustration with bzr is indeed nearing critical mass then it may well be prudent to consider adding support for alternatives. Personally though I think it's a bit of a waste of time discussing this "holy war of the DVCS's" if canonical and launchpad have both made it clear that bzr is the only offically supported VCS. -- 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: Introduction to Ubuntu Distributed Development
2009/12/18 Shentino : > Considering that ship has already sailed a long time ago, I don't think its > wise to waste lumber on another ship when it is already needed elsewhere. > If the bzr galleon runs aground or hits an iceberg in the future, however, > things may change. > Not being a developer myself I'm not aware of bzr's shortcomings/virtues, or > those of git/hg, but if frustration with bzr is indeed nearing critical mass > then it may well be prudent to consider adding support for alternatives. > Personally though I think it's a bit of a waste of time discussing this > "holy war of the DVCS's" if canonical and launchpad have both made it clear > that bzr is the only offically supported VCS. I have used bzr for some months and I love the LP integration. >From what I gather, the "thought model" of git is almost 1-1 with that of bzr. ( have only read a basic 5-minute tutorial on git ) Difference: Some practical differences regarding file systems and how they are organized between the two. But as DVCs they're similar close to identical, right? What git has is "gitorious" and other more "liberal"/minimalistic hosts. LP feels a bit *big* sometimes, especially for experimental/spike projects. But then I just use the +junk feature of LP. > > -- > 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 > > -- twitter.com/olofb olofb.wordpress.com -- 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: Introduction to Ubuntu Distributed Development
Seems that Gnome and Fedora are a little bit more conscious than us in the matter, no spam but check: http://www.linux-magazine.com/Online/News/Fedora-Will-Make-the-Leap-to-Package-Source-Control-System-Git On Thu, 2009-12-17 at 12:47 -0600, Dustin Kirkland wrote: > On Thu, Dec 17, 2009 at 10:40 AM, Scott James Remnant > wrote: > > On Thu, 2009-12-17 at 10:55 -0500, Adrian Perez wrote: > > > >> I think Git is better suited than Bzr for the job, and I don't make to > >> make it personal. > >> > > If you think Git is better suited, please demonstrate it by building up > > an equivalent infrastructure that has been built up around bzr, so fair > > side-by-side comparisons can be performed. > > > >> It's true that there's an infrastructure set up, but I think the idea of > >> voting is letting the community decide for itself, and don't impose us a > >> tool which might not be the preferred choice for most of our developers. > >> > > Right now, that vote would be: > > > > ( ) continue using the existing apt-get source infrastructure, and > > contribute by sending debdiffs around; merge from Debian by hand, > > etc. > > > > ( ) use the new bzr infrastructure, contribute directly to revision > > control branches, merge using native merge support > > There's also, as James mentioned, the git-bzr and hg-bzr projects. > > If there are people that really, really want to issue git commands (it > certainly sounds like there are), instead of bzr commands, I can > understand that. If you're in this camp, please consider contributing > to the translation-layer projects, such that you can happily work in > your git world with git commands, but when you're ready to push your > work, push it through the translation layer, and let it land in the > Launchpad/Bazaar backed repositories, which are currently > well-integrated tools. > > :-Dustin -- Best Regards, Adrian Perez Ubuntu Developer GPG Key ID: 8A9A3084 GPG Key Fingerprint: 99E8 E74E 7B4F 93AE F32A 5523 9973 0D5C 8A9A 3084 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
Re: Considerations about official localized editions of Live CDs
JimHu wrote: > Totally agree with you. CJK users can only do very little daily jobs > with LiveCD. They can't type their own language, so that they can't > search the Internet looking for infomation, using OOo to edit > documents, or chat with freinds in their native languages. > > And CJK are so different as those Latin based language, it's quite > hard for these users to learn English, especially Chinese users. > LiveCD session is useless to those who don't know English well, thus > marketing and promotion are quite poor in such area. The CJK input methods are not installed on the LiveCD, because they take a lot of space, which we don't have. However, it is possible to install them in the running session and they should be immediately available after installation and following IBus configuration if you run it in a CJK locale. (IBus does not require a restart to activate the changes.) Cheers Arne signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: slow boot-up
On Thu, 2009-12-17 at 22:56 -0500, Vikram Dhillon wrote: > Hope everyone is doing good. I beg your pardon, if I am > posting this message in the wrong place, someone in launchpad answers > is dual booting xp and ubuntu. After the update to 9.10 he is > experiencing quite slow boot up, a bootchart is attached to this > message and also [1], can you guys see why the last few processes are > taking unusually long. I suspect the problem is due to the dual > booting in GRUB 2. Thank you very much guys for your help :D > > [1] http://img29.imageshack.us/img29/6260/srikumardesktopkarmic20.png > His boot time is 23s. We don't generally consider that slow on a hard-drive based system; what kind of time was he expecting? Scott -- Scott James Remnant sc...@ubuntu.com 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
Ubuntu Upgrade-Experience
Here's an high-level user-experience view of the Upgrade/Update In this case, this was an unimportant, uninteresting server that I'm keeping mainly to host emails addresses for my friends, and similar stuff. Just mail + web, fairly standard config. I have about 10 servers, and use Linux since 10 years, and am a open source software developer, but server admin is not my job, I just run them myself for privacy reasons (my data on my machines) and to help my friends. In other words, I'm qualified, but no admin specialist, and this was a completely mundane standard job. It installed the server a good year ago, so it was hardy. Now, I decided to update it. I took 3 hours (!). Of that time, download of packages were about 30 seconds. Main reasons were: Config file mess Ideal: From a high-level perspective, /etc/ is config files, and it should contain only things that *I* specified, either manually with a text editor or via setup-tools. It should not contain distro-defaults. Given that Unix apps want them in /etc/, distro-defaults and user settings should at least be in separate dirs. Current situation: my.cnf and apache.conf contain both lots of distro-defaults, which are presumably needed for good operation, and my own changes, e.g. to specify a different error log file location, site config file locations and similar. This *must* lead to conflicts. Proposal: Make one config file for distro defaults, and one or more for user changes, and the latter is empty by default (and it works well), unless I change settings, which I then do there. This requires that it's easy to override settings, both ways, and that there are several config files, ordered. If the app doesn't support that, add it. Goal: should be that the "config directory" of the system, when freshly installed, contains only hostname, location and timezone of user and the account/password of the user, and similar things I specify during installation, or that I change later, possibly manually or via setup tools. This would solve all config file conflicts during update, because my my.cnf would contain only "datadir = /foo; enable-networking", and that would overlay nicely with the distro-defaults. Note how Mozilla does that: prefs have a default (which can be in several files, which are ordered, so you can have platform prefs, app prefs and distro prefs), and a user value. User values are stored in a different file and thus never ever conflict with app default config changes. If a pref format changes (which we try to avoid, but is sometimes necessary), we migrate user prefs explicitly to the new form. apt-get upgrade asking questions I know this is an old Debian topic, but it's *still* asking questions in-between, and blocking upgrade-progress on them, which requires me to constantly watch the upgrade-process, which took a long time. Most of the questions were either * "Should I restart postfix?" (YS! *duh* - Actually, I don't care, I'll reboot the machine at the end anyways, to use the new kernel) * The config file conflicts mentioned above * A few other ones. For the "few other ones", find one way to ask all that at the very beginning, or at least at the very end, never in the middle and blocking on it. It's totally unnerving that I have to read one sentence, press enter, and then wait for a few minutes, repeat. I can't do any other thought-requiring task at the same time. do-release-upgrade doesn't offer upgrade do-release-upgrade didn't work, it claimed there are no new releases, which is clearly wrong. do-release-upgrade --devel-release did something, but doesn't tell me what it would upgrade to. I realize that there are LTS branches, normal releases, and beta versions, but do-release-upgrade doesn't seem to realize that. If I call it, it should at least say: " You are currently running Ubuntu hardy 8.04. This is a LTS (long term support) release. It is still supported with security updates until April 2011 by current plans. You may choose to upgrade it to a newer release, if you want. The following newer LTS releases are available: none The following normal releases are available: karmic (9.10) The following beta releases are available: sid (10.04) If you want to upgrade to one of them, call do-release-upgrade --to " Note that fixing do-release-upgrade won't solve any of 1. or 2.. apt-get dist-upgrade should still work without constant attention and manual fixing, and do-release-upgrade shouldn't cause config file conflicts either. So, in sum, it took 3 hours just to update an unimportant, uninteresting server, in a virtual machine even, with not much stuff on it (mail + apache) and hardly any changes to the default configs. That needs to improve considerably, I don't have time to spend 3 hours per server per year just to change its pampers. Note that my server all have different tasks and all are thus slightly different in release and
Postfix authentication default configuration
I'm trying to set up a mail server with Ubuntu, Cyrus and Postix, and need authentication (via sasldb2) Cyrus works fine, and postfix works and delivers, but I find it extremely hard to configure SMTP AUTH, due to the Postfix-SASL connection, incl. chroot. It's normal for a mail server to not only offer IMAP, but also SMTP to clients. The new specs [1] say we should use port 587 (not 25) for that, and *require* authentication on port 587. This allows mail sending to work even when I'm not connected to the office / my ISP. Therefore, I (and the specs) consider SMTP AUTH to be basic feature of a mail server. Unfortunately, it's incredibly hard to configure in Ubuntu. I can't even find tutorials that get me there, but I don't think I should have to follow tutorials, it should be configured properly out of the box. So, I suggest as default config for a mail server: * sasldb2 (Unix accounts are a bad idea for mail users. More complex setups like mysql can be easily swapped for sasldb2, once that is working) * dovecot or cyrus with auth via SASL * postfix with SMTP auth via SASL * postfix on port 25 (only for incoming/MX) and port 587 (for clients, and mandating auth per spec) * working CRAM-MD5, plaintext login disabled. This is more or less what the specs require from mail servers these days. I think that should work out of the box. And a tutorial which tells how to add users (cyradm, saslpasswd2). [1] RFC 4409, RFC 5068 -- 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: Solang or Shotwell vs. F-Spot for Lucid
nautilus-image-converter provides some very useful tools, but it does feel a bit kludgy. For a simple viewer, I like EOG -- its UI is simple, and just what's needed. However, if it had a few more very basic editing tools, I'd be happy. 2009/12/12 Otto Kekäläinen > > > Solang, Shotwell, and F-Spot are all fine image managers/organizers, > > but the current plan is to work on F-Spot to get it to meet the > > following needs: > > * Quickly viewing images by folder [currently handled by EOG] > > * Solang and F-Spot both have view-modes but still > > require importing the image. Shotwell might not. > > * Editing images without importing (Shotwell does this) > > * Rotating [currently handled by EOG] > > * Red-eye removal [currently handled by GIMP] > > * Cropping [currently handled by GIMP] > > * optional: Annotating (like making lolcat) [currently > > handled by GIMP] > > * optional: Painting on it [currently handled by GIMP] > > Resizing and saving the file in another file format are also common > in-folder image manipulation tasks. > > Personally I prefer Gthumb over EOG or F-Spots view-mode, since it is > fast, easy to use and has enough features. If I had the power, I'd > replace EOG with Gthumb and make Gthumb the default program associated > to all image file types. Current situation sucks. Even Windows XP's > in-folder image manipulation is better.. > > Shotwell looks nice, but I'm a bit sceptic about new software and how > mature they are. > > > > > -- > 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
Re: Considerations about official localized editions of Live CDs
I fact, this will get people who want to use the Live CD as a rescue system away, but install language pack and input method during the global edition of LiveCD running is a good idea to improve user experience anyway. On Fri, Dec 18, 2009 at 10:18 PM, Arne Goetje wrote: > JimHu wrote: >> Totally agree with you. CJK users can only do very little daily jobs >> with LiveCD. They can't type their own language, so that they can't >> search the Internet looking for infomation, using OOo to edit >> documents, or chat with freinds in their native languages. >> >> And CJK are so different as those Latin based language, it's quite >> hard for these users to learn English, especially Chinese users. >> LiveCD session is useless to those who don't know English well, thus >> marketing and promotion are quite poor in such area. > > The CJK input methods are not installed on the LiveCD, because they take > a lot of space, which we don't have. However, it is possible to install > them in the running session and they should be immediately available > after installation and following IBus configuration if you run it in a > CJK locale. (IBus does not require a restart to activate the changes.) > > Cheers > Arne > > > > -- > ubuntu-translators mailing list > ubuntu-translat...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators > > -- 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: Considerations about official localized editions of Live CDs
@Arne: ibus and ibus-m17n have been included in LiveCD AFAIK, and we may consider to add ibus-pinyin with a tiny word stock, I know the size problem is that ibus-pinyin has a HUGE size of sqlite database, having a minimal word stock may help I guess. @JimHu: OpenSuSE and Mandriva has its Asia version aiming at mostly CJK users, and those editions are liked by their users from Asia. 2009/12/18 JimHu : > Arne wrote: >> The CJK input methods are not installed on the LiveCD, >> because they take >> a lot of space, which we don't have. However, it is >> possible to install >> them in the running session and they should be immediately >> available >> after installation and following IBus configuration if you >> run it in a >> CJK locale. (IBus does not require a restart to activate >> the changes.) > I understand what you have said, but it's quite hard for a none expert, none > English user to install the input method themselves under English locale. > Imagine you are running the LiveCD of a distribution whose default language > is Chinese, how can you figure out the way to install English language > support by yourself? After a glance at those unfamiliar characters, I think > you will probably restart your computer, eject the LiveCD and never try that > distribution or even Linux ever again. > > What I think it will be great is that we can have an offical localized LiveCD > at least for CJK users, not the way to solve those localize problem in the > LiveCD session we already have now. > > > ___ > 好玩贺卡等你发，邮箱贺卡全新上线！ > http://card.mail.cn.yahoo.com/ > > -- > ubuntu-translators mailing list > ubuntu-translat...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators > -- 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: slow boot-up
Having been grazing with the gentoo herd (admittedly out of frustration with karmic) I discovered that their RC system is dependency based, where each init script lists which other init scripts it depends upon. Sounds like just the sort of "hey that's cool" that could be included. Now, assuming that dependency siblings don't depend on each other, I presume it would be possible for such dependency information to permit parallelization of the startup process. I imagine most of the time during bootup is spent in disk-sleep with stuff being loaded so it seems like a good optimization to have the idle CPU time being put to good use. No I'm not trying to troll here, but I think that forking the ubuntu startup process so that non-dependent init-scripts can execute in parallel would be a good idea...no pun intended btw. Does ubuntu already have rc parallelization? On Fri, Dec 18, 2009 at 6:29 AM, Scott James Remnant wrote: > On Thu, 2009-12-17 at 22:56 -0500, Vikram Dhillon wrote: > > > Hope everyone is doing good. I beg your pardon, if I am > > posting this message in the wrong place, someone in launchpad answers > > is dual booting xp and ubuntu. After the update to 9.10 he is > > experiencing quite slow boot up, a bootchart is attached to this > > message and also [1], can you guys see why the last few processes are > > taking unusually long. I suspect the problem is due to the dual > > booting in GRUB 2. Thank you very much guys for your help :D > > > > [1] http://img29.imageshack.us/img29/6260/srikumardesktopkarmic20.png > > > His boot time is 23s. > > We don't generally consider that slow on a hard-drive based system; what > kind of time was he expecting? > > Scott > -- > Scott James Remnant > sc...@ubuntu.com > > -- > 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
Re: slow boot-up
On Fri, 2009-12-18 at 11:15 -0800, Shentino wrote: > Does ubuntu already have rc parallelization? > Ubuntu uses the Upstart init daemon, and has an event-driven boot sequence; this has even more advantages than dependency-based, as well as performs tasks in parallel. Scott -- Scott James Remnant sc...@ubuntu.com 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
Re: slow boot-up
Sounds double plus good then. On Fri, Dec 18, 2009 at 12:13 PM, Scott James Remnant wrote: > On Fri, 2009-12-18 at 11:15 -0800, Shentino wrote: > > > Does ubuntu already have rc parallelization? > > > Ubuntu uses the Upstart init daemon, and has an event-driven boot > sequence; this has even more advantages than dependency-based, as well > as performs tasks in parallel. > > Scott > -- > Scott James Remnant > sc...@ubuntu.com > -- 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: Considerations about official localized editions of Live CDs
We have our LoCo site translated including download instructions, but very few people pay attention their. For the main ubuntu.com, providing different languages is a good idea, but who should we ask? As for making CDs, it isn't a very tall order for some experienced users, I have stated in this thread before that there are many teams and individuals making their editions, some of them are not doing a good work and cause a lot of problems, it's really a mess at least in our country. You may heard about the very beginning state of Linux usage in China, LUGs even don't have that power to let everybody know about what does LUG exactly mean, and I think local community is a form of LUG. If the LoCo push out a distro and brand it as "Ubuntu China Community Edition", most people will think it is just another customized edition and have nothing different. Many people are just about to try out Linux, they choose Ubuntu for easy to use, and they want a fully localized one so more than half of them are likely to choose a LiveCD with full localization, but once they think it sucks (usually happen when they try a bad customized edition, or find our official edition doesn't fully translated at his first glance), they will give up possibly. I believe other languages can have some similar situation and have the same requirement to a official made localized LiveCD on its image server or other way they are easy to confirm, don't desire that everybody can look at our web site or do some search to find out things on Wiki, it is an Ad for community edition, but at most time only little amount of people can see them. Regards, Aron Xu On Fri, Dec 18, 2009 at 11:28 PM, Adi Roiban wrote: > În data de Vi, 18-12-2009 la 22:39 +0800, JimHu a scris: >> What I think it will be great is that we can have an offical localized >> LiveCD at least for CJK users, not the way to solve those localize >> problem in the LiveCD session we already have now. >> > > I encourage local communities to create their own LiveCD and host them > on their local website. > > For people without basic knowledge of english, browsing ubuntu.com is > not necessary an easy task... so the website or download instructions > should also be provided in different languages. > > I tried to followed the documentation from LiveCDCustomization wiki > page, and everything was smooth. > https://help.ubuntu.com/community/LiveCDCustomization > I asked some community members to test the image and then hosted the > image on ubuntu.ro . > > It would be nice to have the image already created by someone else, but > I think this is something a community can do. > > Maybe we can have a session about LiveCD customization during the next > Ubuntu Developers Week (or maybe we already did, I did not checked the > schedule). > > Also maybe we should seek ways in which we can encourage local > communities to create and support localized editions of Live CDs. > > Cheers, > > -- > Adi Roiban > > > -- > ubuntu-translators mailing list > ubuntu-translat...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators > -- 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: Considerations about official localized editions of Live CDs
Well I think it is normal for us don't distribute those images to worldwide severs. Simply make torrents and put the .torrent files on a public sever, then users can download it without pressing our server. The only thing we need to do is put the file on a place where won't be synced be default and just keep seeding to the bit-torrent network , no matter how much bandwidth, neither need to consider how to distribute a big amount of data. LoCo mirrors can choose to sync these images to their servers if they would like to do. Regards, Aron Xu On Sat, Dec 19, 2009 at 1:21 PM, yq s wrote: > I think bandwidth is not a problem here. > > we can apart locale liveCDs from current one. > and only the prober locale mirrors to mirror the locale's one. > for example only the mirrors in China Mainland to mirror the zh_CN one. > it won't take more bandwidth,even may reduce bandwidth usage of > ubuntu.com,because that the download of DVD will reduce. > > > > -- > ubuntu-translators mailing list > ubuntu-translat...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators > > -- 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: karmic: libghc6-src-exts-dev install failed: missing dependency
On Mon, Dec 14, 2009 at 11:48 AM, Benedikt Ahrens wrote: > installation of libghc6-src-exts-dev fails because of unmet dependencies. > > Correponding bug report: > https://bugs.launchpad.net/ubuntu/+source/haskell-src-exts/+bug/496274 As I commented, for Karmic you need a simple no-change source rebuild, which makes this a fairly straightforward candidate for a StableReleaseUpdate. -Dan -- 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
