Re: 5 a day (was Using Harvest with your team)
Olá Daniel e a todos. On Tuesday 12 August 2008 10:30:47 Daniel Holbach wrote: > My 5 today: #256507, #256025, #256604, #256733, #211252 > Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day Why did you stop using the bug description? It was an eye catcher and promoted users/readers to check on those bugs. just mentioning a bug #id aint that helpful. -- BUGabundo :o) (``-_-´´) http://Ubuntu.BUGabundo.net Linux user #443786GPG key 1024D/A1784EBB My new micro-blog @ http://BUGabundo.net ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by... 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: 5 a day (was Using Harvest with your team)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (``-_-´´) -- Fernando schrieb: > Why did you stop using the bug description? It was an eye catcher and > promoted users/readers to check on those bugs. just mentioning a bug #id aint > that helpful. This is because of https://bugs.launchpad.net/python-launchpad-bugs/+bug/257516 Have a nice day, Daniel - -- My 5 today: #257313, #256619, #256584, #256625, #256628 Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIooyjRjrlnQWd1esRAk7AAJ9c0VRzuEI8aYUcYlVjqC0YZBWsMgCeL8wP 6wQbWghkcsbFrZR8XSKDFUM= =bbwK -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: Re-encoding sample content with latest theora encoders
2008/8/9 Onkar Shinde <[EMAIL PROTECTED]>: > Theora has improved really well in last year. I think we should take > advantage of the latest development in theora encoder [1] and > re-encode the video from original source to produce better looking > video. Yep, I've thought about this myself, too. I guess Canonical would have the original video somewhere, and this should definitely be done since the current quality is so poor. The newest improvements are not in the released Theora version yet, but anyone can take the latest versions from the correct version control branch and use those to encode the video. I volunteer to do the encoding experiments needed to improve the quality dramatically while keeping the file size same :) You could file a bug at https://bugs.launchpad.net/ubuntu/+source/example-content -Timo -- 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: Re-encoding sample content with latest theora encoders
That's already been done https://bugs.launchpad.net/ubuntu/+source/example-content/+bug/257098 On Wed, Aug 13, 2008 at 3:27 AM, Timo Jyrinki <[EMAIL PROTECTED]>wrote: > 2008/8/9 Onkar Shinde <[EMAIL PROTECTED]>: > > Theora has improved really well in last year. I think we should take > > advantage of the latest development in theora encoder [1] and > > re-encode the video from original source to produce better looking > > video. > > Yep, I've thought about this myself, too. I guess Canonical would have > the original video somewhere, and this should definitely be done since > the current quality is so poor. The newest improvements are not in the > released Theora version yet, but anyone can take the latest versions > from the correct version control branch and use those to encode the > video. I volunteer to do the encoding experiments needed to improve > the quality dramatically while keeping the file size same :) > > You could file a bug at > https://bugs.launchpad.net/ubuntu/+source/example-content > > -Timo > > -- > 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: Re-encoding sample content with latest theora encoders
Two more issues that can be fixed along with this bug: Ogg theora video should be .ogv https://bugs.edge.launchpad.net/ubuntu/+source/example-content/+bug/227492 The video should have subtitles: https://bugs.edge.launchpad.net/ubuntu/+source/example-content/+bug/47248 On Wed, Aug 13, 2008 at 3:34 AM, Timo Jyrinki <[EMAIL PROTECTED]>wrote: > 2008/8/13 Danny Piccirillo <[EMAIL PROTECTED]>: > > That's already been done > > https://bugs.launchpad.net/ubuntu/+source/example-content/+bug/257098 > > Right. I updated the title of it now. > > -Timo > -- 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: Automatic fsck
On Wed, Aug 13, 2008 at 07:41:18AM +0800, Onno Benschop wrote: > > >> On Mon, Aug 11, 2008 at 11:52:25AM +0100, Matt Zimmerman wrote: > >> > >>> == Filesystem checking / AutoFsck == > >>> > >>> A suggestion was made to the technical board that Ubuntu could be smarter > >>> about how and when it performs filesystem integrity checks (fsck). > >>> > >>> Decision: This should be discussed more widely in the developer community > >>> Action: Scott to start a thread on ubuntu-devel/-discuss > >>> > > One thing that I have not seen in this discussion is the notion that > fsck might be modified to run incrementally. That's an interesting idea, though I don't know enough about ext3 to comment on its feasibility. Perhaps something to discuss with upstream? > Another that I did not see is the idea that fsck can be run using -n > (though ReiserFS and minix aren't supported at the moment). If fsck is > run in the background and a notification is sent to the > user/administrator if corruption is found, then active intervention can > be recommended. It's easy to prevent fsck from changing the filesystem, but the trouble is that fsck can't be (usefully) run on a filesystem which is in use (mounted). > I see with some alarm discussion about reducing the frequency of running > fsck. I'm running an ext3 laptop and I'm seeing quite regular > corruptions that require an fsck run to fix. (It may be related to a > particular kernel, but I've not yet got to the bottom of that.) That is a very disconcerting (and atypical) problem. The appearance of errors in fsck indicates a serious problem which should be investigated, not a normal condition of wear and tear. > Fundamentally, in my opinion, fsck is a housekeeping process that is > required on a regular basis to ensure the sane state of a file-system, > no matter which one you use, errors do happen, even if there are no bugs > (ha!), we're talking about tiny magnetic fields affecting the > information on a hard-drive - this problem is only going to get bigger > with increased storage density. I don't think there's any disagreement on this point. The issues are: 1) The frequency at which fsck runs is somewhat arbitrary for many users, depending on their usage pattern, and doesn't relate particularly well to their risk of encountering errors. 2) The fsck runs themselves are very disruptive, blocking access to the computer when the user wants it. -- - mdz -- 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: Call for testing empathy
Le mercredi 13 août 2008 à 01:07 +0200, Aurélien Naldi a écrit : > I get the same icon between > two empathy but it does not appear next to the ichat-using contact I > wanted to talk to. AFAIK, ichat is supposed to work with gtalk, so I > expected it to work with empathy as well. No, iChat doesn't implement jingle audio/video. G. -- Guillaume Desmottes <[EMAIL PROTECTED]> Jabber <[EMAIL PROTECTED]> GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 -- 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: ext4 in Intrepid?
On Tue, Aug 12, 2008 at 09:32:31AM +1000, Chris Jones wrote: > I've been following the development of ext4 for what seems like an > eternity. > > >From what I understand, the latest Fedora 9 release features ext4 > support. So too do many other popular distros. And what I can't > understand is why Ubuntu still doesn't feature any support for ext4, to > my knowledge. > > I was hoping that the developers could shed some light on the reasons as > to why. And will it perhaps make its way into Intrepid? If not, when we > will see support for ext4 in Ubuntu. The reasons are, in no particular order: * There hasn't been a driving need for it (contrast with, say, improved NTFS filesystem support) * It isn't stable yet. The developers still recommend caution and lots of backups * Tool support (e2fsprogs) wasn't released in a stable version until last month (July) * The developers highly recommend tracking out-of-tree kernel patches, even for 2.6.26 (our current kernel in Intrepid) It looks as if it may be worth a more serious look in the next release cycle after 8.10. -- - mdz -- 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: Call for testing empathy
Who makes the final call on the inclusion of Empathy in Intrepid? Where does that discussion happen? -- 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: Automatic fsck
Andrew Sayers wrote: > I assume that the equivalent of "umount $snapshot" is done within the > kernel when the snapshot is created, because it gives you a new > non-mounted block device. It's therefore possible to do fsck from cron. The snapshot was never mounted in the first place, so there is no need to unmount it. As you mentioned before however, any files changed since the snapshot was made will be lost when you reboot and merge the snapshot back to the main volume. -- 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: Automatic fsck
ke, 2008-08-13 kello 18:33 -0400, Phillip Susi kirjoitti: > Andrew Sayers wrote: > > > I assume that the equivalent of "umount $snapshot" is done within the > > kernel when the snapshot is created, because it gives you a new > > non-mounted block device. It's therefore possible to do fsck from cron. > > The snapshot was never mounted in the first place, so there is no need > to unmount it. Right. Just to be clear, the following would be a reasonably reasonable scenario for boot-time fsck, in situations in which LVM snapshots are available: * kernel mounts root filesystem read-only * init scripts make LVM copy-on-write snapshot of all filesystems * init scripts re-mount root filesystem read-write, mount any other filesystems * fsck starts on each snapshot, preferably with "ionice -c3" * once a snapshot has been checked, it is destroyed Since the fscks can take a long time, the results can't be reported at boot-time, and an alternative communication channel is needed. For servers, e-mail and syslog seem reasonable. Any problems found with the snapshots will _not_ be fixed in the real filesystem, only in the snapshot. The real filesystem needs to be fixed too. Like Matt suggested, marking the filesystem dirty (so a real fsck is run at next boot) seems like a reasonable way of doing that. For desktops, putting errors into /var/log/background-fsck/foo.log and having something in the GNOME/KDE sessions watch those files and pop up an error message should be feasible. Would that work? -- 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
Intuitive "Popup" Scrollbars
"http://thorwil.wordpress.com/2008/05/09/popup-scrollbar-concept-demo/ This would just give Ubuntu more edge and make it even more intuitive. Although for people used to the old style scrollbar it may be confusing at first glance, it would quickly become another reason to get hooked on Ubuntu :)" https://bugs.edge.launchpad.net/ubuntu/+bug/253546 http://brainstorm.ubuntu.com/idea/8353/ Thoughts? -- 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: Intuitive "Popup" Scrollbars
I think there's little chance we'll be diverging from upstream GTK on a component as important as this. I suggest you take this concept straight to GTK. -- 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: Automatic fsck
Phillip Susi wrote: > The snapshot was never mounted in the first place, so there is no need > to unmount it. > > As you mentioned before however, any files changed since the snapshot > was made will be lost when you reboot and merge the snapshot back to the > main volume. > Either I'm not making myself clear or my lack of kernel mojo is showing. The test I did previously was on a running filesystem, while it was in use - not during boot-up as we'd previously discussed. It seems to me that a literal snapshot, capturing a random moment in the life of a filesystem, would be treated by e2fsck as not having been cleanly unmounted. Since e2fsck didn't complain about anything like that, some part of the snapshotting process must cleanly unmount the filesystem. This means that one can take a snapshot while the system is running, fsck the snapshot, and (if the snapshot is error-free) conclude that the main volume doesn't need an automatic check for another few months/reboots. So building on Lars' idea, I propose: At boot-time: 1. kernel mounts root filesystem read-only 2. init scripts check which filesystems have passed their max mount count/interval 2a. init scripts snapshot those filesystems 2b. the main volumes for those systems are mounted (without being checked) 3. init scripts continue as normal 4. fsck starts on each snapshot, preferably with "ionice -c3" 5. if a snapshot is found to be clean, 5a. the main volume has its mount-count/check-time reset 5b. the snapshot is destroyed 5c. the user is /not/ informed 6. if a snapshot is found to have problems, 6a. the main volume is marked to be fsck'd 6b. the snapshot is destroyed 6c. the user is asked to reboot In /etc/cron.weekly/fsck: 1. pick a device in /dev/mapper (i.e. only check one device per week) 2. snapshot that volume 3. continue from (4), above Since merging is currently in beta, and probably a daft idea in this context, it's better to roll out something more practical, and think about being more audacious next time. Remembering my aforementioned lack of kernel mojo, the biggest problems I can see with this approach are that it requires Ubiquity to do LVM by default and to keep a significant chunk of the drive free for snapshots (off the top of my head, I'd say 1-5% of total disk space). - Andrew -- 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: Automatic fsck
PLEASE redirect your efforts towards online fscking. This whole idea is absolutely horrible. -- 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: Automatic fsck
Alexander Jones wrote: > PLEASE redirect your efforts towards online fscking. This whole idea > is absolutely horrible. How so? - Andrew -- 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
MOTU School sessions for Developer week wanted
Hi all, Next month we have another Ubuntu Developer Week. It's still in the planning stage, and there will be a proper announcement later, so if you are interested in attending wait for that. This post is for those who are in a position to give sessions. I want to get several MOTU School sessions included in the schedule, but for that I need presenters willing to give them. There's a list of some ideas for sessions at https://wiki.ubuntu.com/MOTU/School/Requests as always. If there is a session there that you would like to give then get in touch with me. It doesn't have to be one from that list, I'm interested in any session that you are willing and able to present. In particular I'm really keen to see the sessions on Java this time. I'll also speak to the Soyuz team to see if they are willing to present a session, as that one has several votes. I'll also probably present a bzr session with David, and a packaging with bzr session. If you want to have a session during the week on something then stick your name and the title on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep or grab dholbach or me to discuss it. Thanks, James P.S. There's a session in about 21 hours, don't miss it. -- 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: Automatic fsck
Because people are talking about snapshotting a FS in a potentially broken state, fscking it in the background---whilst continuing to use it! Assuming that using a broken FS doesnt hose it (admittedly it shouldn't), merging a changeset from a broken state into a repaired state is a process which I think will be extremely fragile and prone to breakage, /especially/ if attempted FS-agnostically. I willfully invite people to prove me wrong, just tell me how to disable it before it eats my data. Or limit your scope a bit and thrash this out properly, for a single filesystem (hint, Ext3!), on LKML. -- 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: Automatic fsck
Alexander Jones wrote: > Because people are talking about snapshotting a FS in a potentially > broken state, fscking it in the background---whilst continuing to use > it! > > Assuming that using a broken FS doesnt hose it (admittedly it > shouldn't), merging a changeset from a broken state into a repaired > state is a process which I think will be extremely fragile and prone > to breakage, /especially/ if attempted FS-agnostically. > > I willfully invite people to prove me wrong, just tell me how to > disable it before it eats my data. Or limit your scope a bit and > thrash this out properly, for a single filesystem (hint, Ext3!), on > LKML. > Right, I understand your objection now. Some points I'd like to make: As I said before, merging back is at most something to consider in version 2. For now it's enough to use the snapshot in read-only mode to confirm whether the FS actually needs to be fixed. I'm only suggesting this be used in place of the regular boot-time fsck's that hardly ever turn up anything of interest. IMHO, when there's any significant probability of breakage, fsck's should be done before the disks are mounted - not in a snapshot, not online. As to the dangers of a broken FS, consider the following: disks are currently fsck'd once every few mounts/months. In order for that regular check to find a problem, you would have to be use a broken FS for anything up to that many mounts/months without noticing. If a cron job checks your disks twice as often (without modifying them), and triggers an old-fashioned boot-time fsck at the user's earliest convenience, that only serves to augment the current system by reducing the amount of time that you're using a broken FS. That said, I'd like to amend my previous proposal slightly based on your objection: 6b. the snapshot is marked to be destroyed _only after_ a successful fsck of the main volume. In the event that the main volume is too badly damaged, the snapshot might aid in recovery. If you didn't go out of your way to manage your disks with LVM when you installed Ubuntu, then this solution would be automatically disabled for you. Snapshotting requires LVM, which is currently only an option if you install from the alternate CD. I'm not aware of any mechanism to upgrade a normal partition table to LVM, so this solution would only work for new installs and systems that already use LVM. - Andrew -- 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
