Re: Why Nautilus and GNOME applications use URIs?
On Thu, 2010-06-03 at 07:36 +0200, Aurélien Naldi wrote: > Hi, > > when using Drag and Drop, nautilus switches from GIO/GVFS URI to local > path, depending on the drop target (i.e. it will paste a local path if > you drop to a gnome-terminal). I guess dropping on a gtk filechooser > assumes that the application is using GIO. It may need some special > casing for this case. On one hand, if an application is gtk-based it > really should use gio, on the other hand I think at least firefox and > openoffice use gtk file chooser and won't use it. > > For GIO-based applications, using the GIO URI is much better, but as > far as I remember, several applications transform local paths into GIO > URIs, so providing a local path should always work. Dragging files from nautilus and dropping on the file open dialog in OOo works for me. Ubuntu's OOo doesn't use URIs due to prior bugs and I converted it to using the local path (gvfs-fuse) which appears to work more reliably. Chris -- 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: KDE PulseAudio Integration
I learned about the integration of PulseAudio into Mandriva (implemented as in Fedora) All you need to do here - http://pulseaudio.org/wiki/KDE -- 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: KDE PulseAudio Integration
[Adding kubuntu-devel]
On Thu, Jun 3, 2010 at 11:12 AM, Volovikov Taras wrote:
> All you need to do here - http://pulseaudio.org/wiki/KDE
Note that there is at least one additional subtlety for Kubuntu on
which I am not up-to-speed (and for which others will need to step up,
because my time on *Ubuntu development is winding down). If new users
are still added to @audio, this needs to stop as it breaks per-session
("seat") activation.
Regarding the wiki page, it is sufficient to use "pulseaudio -k"
instead of rebooting or invoking start-pulseaudio* explicitly, because
autospawn is enabled by default.
Best,
-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
Why do some updates skip proposed? (launchpad bug 589163)
Hey all, Quick question for anyone that can give a quick answer... The kernel released for lucid last night (2.6.32-22.35) broke kvm guests - prevented them from starting. The kernel that was in proposed (2.6.32-22.33) has no problems. Looking at launchpad it looks like 2.6.32-22.35 never hit proposed and went straight to updates/security: https://launchpad.net/ubuntu/+source/linux/2.6.32-22.35/+publishinghistory Given that this broke KVM guests on an LTS release no less (and kvm is pushed by Ubuntu as the virtualisation system to use) it presents a reasonably serious problem. How did this get straight to release with no testing in proposed? What is the point of having proposed for bug testing if a released package never goes through it - especially for something as critically important to the core system as the kernel? Hopefully the issue can be fixed soon so those of us who use KVM on Lucid are able to use the latest kernel with any bug fixes again.. As it is anyone with this issue cannot get a fix from Ubuntu as a vendor for the following CVE's as they are part of the update that broke kvm: CVE-2010-0419 CVE-2010-1162 CVE-2010-1488 CVE-2010-1148 CVE-2010-1146 CVE-2009-4537 And if they don't have the savvy (or are unwilling to run a 'proposed' kernel) to obtain the 2.6.32-22.33 kernel directly from the launchpad build page they will also be missing updates for launchpad bugs 526354 and 567016. Any thoughts on this issue? Regards, James -- 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: Why do some updates skip proposed? (launchpad bug 589163)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/10 18:16, James Hogarth wrote: > Hey all, > > Quick question for anyone that can give a quick answer... > > The kernel released for lucid last night (2.6.32-22.35) broke kvm > guests - prevented them from starting. > > The kernel that was in proposed (2.6.32-22.33) has no problems. > > Looking at launchpad it looks like 2.6.32-22.35 never hit proposed and > went straight to updates/security: > > https://launchpad.net/ubuntu/+source/linux/2.6.32-22.35/+publishinghistory > > Given that this broke KVM guests on an LTS release no less (and kvm is > pushed by Ubuntu as the virtualisation system to use) it presents a > reasonably serious problem. > > How did this get straight to release with no testing in proposed? > > What is the point of having proposed for bug testing if a released > package never goes through it - especially for something as critically > important to the core system as the kernel? > > Hopefully the issue can be fixed soon so those of us who use KVM on > Lucid are able to use the latest kernel with any bug fixes again.. > > As it is anyone with this issue cannot get a fix from Ubuntu as a > vendor for the following CVE's as they are part of the update that > broke kvm: > > CVE-2010-0419 > CVE-2010-1162 > CVE-2010-1488 > CVE-2010-1148 > CVE-2010-1146 > CVE-2009-4537 > > And if they don't have the savvy (or are unwilling to run a 'proposed' > kernel) to obtain the 2.6.32-22.33 kernel directly from the launchpad > build page they will also be missing updates for launchpad bugs 526354 > and 567016. > > Any thoughts on this issue? > > Regards, > > James > As stated on https://wiki.ubuntu.com/KernelTeam/KernelUpdates: * Security updates will be uploaded directly into -security without other changes. This just requires a temporary GIT fork which will be immediately merged back into the main branch for that stable release. * Normal updates will be provided as pre-releases through the kernel-ppa users PPA. At certain points those get made into proposed releases which are uploaded to the proposed pocket. Then again they have to get verified to fix the problems and not to cause regressions. As far as I know, this applies to most security updates, skipping the - -proposed step Whether or not this policy is a good one, is a matter of discussion, since it obviously failed this one. Would more testing, which would mean a slower procedure for getting the security fixes through, be a viable compromise in some cases? What kind of testing is already in place by the security team? Could that be expanded? - - arand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwIHE4ACgkQ67RiDgo9GiNR8QCghLwEDutw3x6i3YhxWJHlLrx4 xf0Anjle/R4uciiMfMGOfylk/AJZ2E8O =ImT2 -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: LiveCD optimisations
Ping! @list: If you don't know what this email is about, it continues a conversation from last month, which is archived. [1] I continued on the SVG optimisations, even creating a branch for Scour [2] having additional optimisations for things that I came across while looking at the Scoured SVG files within the LiveCD. The result is more savings on the LiveCD, but the law of diminishing returns kicked in. :) I only saved 90 more KB on SVGs since the last time I wrote about this. However, I also determined that some XML (xmllint) optimisations are safe for the CD: -- Safe optimisation list: Start /usr/lib/bonobo/servers/*.server /usr (recursive) *.glade or *.ui / (recursive) *.svg or *.xsl /usr/lib/openoffice (recursive) *.xcu or *.xcs or *.xlb or *.xba or *.xdl or *.xlc or *.xml or *.odb or *.soc or *.sod or *.soe or *.sog or *.soh /usr/share/gconf/schemas/*.schemas /usr/share/themes (recursive) metacity-theme-*.xml /usr/share/mime (recursive) *.xml /usr/share/gtksourceview-2.0/language-specs/*.lang /usr/share/gtksourceview-2.0/styles/*.xml All %gconf-tree*.xml files -- Safe optimisation list: End At 2010-05-21 21:52 GMT, Dmitrijs Ledkovs wrote: > -- Implementation -- > > 1) Should this go into deb-package mangler run by soyuz? > > 2) Or should this be implemented as debhelper addon / cdbs as no-op > ubuntu-patch and then if successful (all the quirks are worked out) > and pushed to Debian? I have no idea, and would like to defer to the Ubuntu packagers to gather their opinion on this. As I understand, both options would have advantages and drawbacks. * The package mangler would be able to take any package and optimise its files, for immediate savings. However, that doesn't give Debian or upstreams much, and a blanket use of the package mangler could completely break some software. * dh_svgopt, dh_pngopt and dh_xmlopt (proposed names, if you will) would at least give Debian something, and upstreams would be able to include these dh_*'s in their package building rules. Upstreams would make sure that the optimised files work with their software before adding the dh_*'s, or adjust their code so that it does. However, that means a lot of waiting around on some upstreams. Opinions on dh_* versus package mangler? Would I need to code these dh_*'s, or the addition to the package mangler? Should I move this to another mailing list, like ubuntu-devel or debian-devel? Regards, - Louis [1] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-May/thread.html [2] https://code.launchpad.net/~louis-simard/scour/rework -- 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: Why Nautilus and GNOME applications use URIs?
El 03/06/10 10:38, Chris Cheney escribió: On Thu, 2010-06-03 at 07:36 +0200, Aurélien Naldi wrote: Hi, when using Drag and Drop, nautilus switches from GIO/GVFS URI to local path, depending on the drop target (i.e. it will paste a local path if you drop to a gnome-terminal). I guess dropping on a gtk filechooser assumes that the application is using GIO. It may need some special casing for this case. On one hand, if an application is gtk-based it really should use gio, on the other hand I think at least firefox and openoffice use gtk file chooser and won't use it. For GIO-based applications, using the GIO URI is much better, but as far as I remember, several applications transform local paths into GIO URIs, so providing a local path should always work. Dragging files from nautilus and dropping on the file open dialog in OOo works for me. Ubuntu's OOo doesn't use URIs due to prior bugs and I converted it to using the local path (gvfs-fuse) which appears to work more reliably. Chris Well, yes, OOo can handle the URI GVFS through the package "openoffice.org-gnome". But of course, the system must have the package, as one of the main programs of the distributionn, to support URI. I refer to any application, not only for GNOME apps, that any user may need (the aforementioned Meld, Code:: Blocks, poEdit, and a long etc). These applications do not recognize URI with drag and drop, says can not open the file (the drag n drop not is the main problem, is only an example). To which I go is, what is the power of abstraction GVFS / FUSE if you do not actually use? Is there any advantage to using URI instead of the local address (for certainly I saw it more problems than anything else, so I opened the thread)? Is it feasible to stop using the URI to improve compatibility (speaking on development concepts)? Do you really believe it would do more usable and convenient to the system? Regards! -- Bueno, es cierto, OOo puede manejar las URI GVFS gracias al paquete "openoffice.org-gnome". Pero claro, lo debe tener, al ser un programa básico de la distribución, el soporte para URI. Yo me refiero a cualquier aplicación, no solo las de GNOME, que cualquier usuario puede llegar a necesitar (el mencionado Meld, Code::Blocks, Poedit, y un largo etc). Estas aplicaciones a mi no me reconocen URI mediante arrastrar y soltar, dice que no se puede abrir el fichero (esto por poner un ejemplo). A lo que voy es, ¿de qué sirve el poder de abstracción de GVFS/FUSE si realmente no se utiliza? ¿hay alguna ventaja en usar URI en lugar de la dirección local (porque ciertamente le vi mas problemas que otra cosa, por eso abrí el hilo)? ¿es factible dejar de usar las URI para mejorar la compatibilidad (hablando en conceptos de desarrollo)? ¿realmente creen ustedes que lo haría mas usable y cómodo al sistema? Un Saludo! -- 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
