Weekly Reminder of Ubuntu Studio ToMerge packages
-- List of Ubuntu Studio merges that need attention by someone -- This is an automated post. Before doing anything, please read https://wiki.ubuntu.com/UbuntuDevelopment/Merging For detailed info on the individual packages, see https://merges.ubuntu.com/universe.html, and https://merges.ubuntu.com/multiverse.html And as the latter pages say: - If you are not the previous uploader, ask the previous uploader before doing the merge. This prevents two people from doing the same work. audacious-plugins - universe isdnutils - universe kdenlive - universe libav-extra - universe lightdm-gtk-greeter - universe murrine-themes - universe oss4 - universe xchat - universe alsa-tools - universe msttcorefonts - multiverse -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Weekly Reminder of Ubuntu Studio ToMerge packages
On Sun, May 12, 2013 11:00 pm, Kaj Ailomaa wrote: -- List of Ubuntu Studio merges that need attention by someone -- Assuming these are package names: isdnutils - universe oss4 - universe Ubuntustudio doesn't seem to ship either one. And this one doesn't show up at all: msttcorefonts - multiverse I can find ttf-mscorefonts-installer though. But it seems we don't need it to run. LMMS runs without. (or it runs with the installer failing for lack of user input) -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: Weekly Reminder of Ubuntu Studio ToMerge packages
On 05/13/2013 01:20 AM, Len Ovens wrote: On Sun, May 12, 2013 11:00 pm, Kaj Ailomaa wrote: -- List of Ubuntu Studio merges that need attention by someone -- Assuming these are package names: isdnutils - universe oss4 - universe Ubuntustudio doesn't seem to ship either one. And this one doesn't show up at all: msttcorefonts - multiverse I can find ttf-mscorefonts-installer though. But it seems we don't need it to run. LMMS runs without. (or it runs with the installer failing for lack of user input) These are source package names, not binary package names. You can see the binary packages by running rmadison -S -s saucy $SOURCE_PKG_NAME Micah -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Menu changes
Anyone who feels like trying out 13.10, please look at the menu(s) and give feedback. The major change is that the settings menu is gone to be completely replaced by the settings manager. Anything that used to be in the settings menu is now accessible from the settings manager. This is much cleaner than having some settings in a menu and some other ones in the settings manager. Xubuntu has also done this (for 13.04 actually) but many of the system utilities ended up in the xubuntu settings that I felt belonged in the system menu. (software installation, disk partitioning, etc.) I have fixed that in ours. I have also tried to make sure the various settings are in the right group. Because we use setting utilities from other places besides xfce for some things, the categories don't line up as well as they could. I have tried to make the best placement manually. Please feel free to comment on this as I can change which group things show up in. I have added an audio group for audio specific settings. Anything I should add there? Or should all of these things end up as part of the audio production menu? Right now it is just LADI config and the LADI log file viewer, but any audio controls could go here... or they could go in the audio menu somewhere. The other possibility I considered is to also incorporate the system utilities into this manager and get rid of the system menu as well. I felt that was to big of a change to just go there. I'm not sure that would be better. I don't think I have real strong preferences here. I just tried to make sense. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Call for testing: new udev -- switch to vendor/name/slot based net interface names?
Hello fellow Ubuntuers, now that we have logind/uaccess and libudev1 in Ubuntu, it is finally time to update to a current udev version. This will bring a faster system boot as it does not call the modprobe, scsi_id, blkid and other programs a gazillion times, but instead has all these built in (through libkmod, libblkid, etc.). It will also get us rid of quite a few patches which were piling up to make our increasingly ancient udev work with the current kernel and plumbing. I went through our current package and applied our remaining patches, initramfs integration and Ubuntu specific rules. There were two patches which were non-obvious: * avoid-exit-deadlock-for-timely-events: This was applied for http://pad.lv/842560 . Andy discussed that with upstream in http://comments.gmane.org/gmane.linux.hotplug.devel/17206 and as a result the whole TIMEOUT legacy stuff has been removed, so this does not apply any more. Also, firmware handling has changed quite a bit (e. g. recent kernels load it by themselves). So I dropped the patch. * avoid-exit-deadlock-for-dm_cookie.patch: This was applied as a kind of workaround for http://pad.lv/802626 (I think we really should stop having two udevs in the boot process, BTW), and further modified the code that avoid-exit-deadlock-for-timely-events already changed. I think I ported it correctly, but if you have an LVM setup, double-checking this can't hurt. There is one important change which warrants some discussion: By default, current udev now uses BIOS/vendor/slot number based names so that they are easier to identify, but more importantly, they have predictable names without the old 70-persistent-net.rules. My current package disables this for upgrades (to avoid changing any existing network configuration), but enables it for new installs. Stephane Graber mentioned that we might not want this as it might break too many tools which rely on the ethX naming; I can forward port the old generator for 70-persistent-net.rules (it's just a shell script) if we want. So before I land it in the archive I'd like to get a few more testing results on various machines. If you could install the packages from https://launchpad.net/~pitti/+archive/ppa (systemd is the only one for saucy in that PPA) and tell me how it goes, together with your machine/install config (UEFI, LVM, cryptsetup, etc.), I'd appreciate. Thank you in advance! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Unity APIs weekly (wk 19)
Hi, Scopes - Creation of missing scope previews - After fixing more bugs and integration issues quality is now good for inclusion into s, targeted for beginning of this week Indicators - Started on porting datetime indicator to new architecture and added tests - More work on shim layer enabling newly ported indicators to show up in Unity 7 shell (nux based shell) HUD - Fixed breakage in voice input since phablet move to Raring - Added context support to HUD service - Implemented rest of predefined actions: fullscreen, help, settings and undo Notifications - Completed backend implementation of new notification architecture, test coverage still to be increased Greeter - Infographics API almost complete (multi user support still missing) - Merged new LightDM API branch with info graphics and integrated everything in regular phablet shell (prototype works) - Helped out fixing some infographics UI issues related to layout, animations and stability Thomas -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot report 2013-05-13
https://code.launchpad.net/~yolanda.robla/nut/dep-8-tests/+merge/161414 Approved. https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/postfix/dep-8-tests/+merge/161610 Approved. https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/openldap/dep-8-tests/+merge/162097 Commented. https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/spamassassin/dep-8-tests/+merge/162690 Approved. https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/ganglia/dep-8-tests/+merge/163035 Approved. https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/iscsitarget/dep-8-tests/+merge/163368 Approved. https://code.launchpad.net/~cristiklein/ubuntu/precise/vm-builder/lp468809/+merge/161427 Approved. https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1121874 Commented. Great to see all these new DEP-8 tests [1] appearing! Let's keep the momentum going so we can turn [2] into a wall of green^H^H^H^H^H err blue sky and sunshine! :-) Kind regards, James. -- James Hunt #upstart on freenode http://upstart.ubuntu.com/cookbook https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
DEP-8 tests (was: Patch Pilot report 2013-05-13)
Am Montag, den 13.05.2013, 13:36 +0100 schrieb James Hunt: Great to see all these new DEP-8 tests [1] appearing! Let's keep the momentum going so we can turn [2] into a wall of green^H^H^H^H^H err blue sky and sunshine! :-) I found a bug: [1] and [2] are missing in your email. :) -- Benjamin Drung Debian Ubuntu Developer -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: DEP-8 tests
On 13/05/13 13:59, Benjamin Drung wrote: Am Montag, den 13.05.2013, 13:36 +0100 schrieb James Hunt: Great to see all these new DEP-8 tests [1] appearing! Let's keep the momentum going so we can turn [2] into a wall of green^H^H^H^H^H err blue sky and sunshine! :-) I found a bug: [1] and [2] are missing in your email. :) That got you interested right? :-) [1] - http://developer.ubuntu.com/packaging/html/auto-pkg-test.html [2] - https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ Kind regards, James. -- James Hunt #upstart on freenode http://upstart.ubuntu.com/cookbook https://lists.ubuntu.com/mailman/listinfo/upstart-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
Hi, Thanks for efforts on simplifying package management! I'll wait for further information from UDS session, but first I want to provide some additional info that can help you in research. I'm QtCreator contibutor, worked on source code models and project management subsystems, including build systems support. Click packages have many decisions that can scare experienced Linux users, but are reasonable. So, for marketing purposes and in order to defend idea, please make more detailed overview of each design decision, which includes: 1. Comparison of various approaches in this concrete problem, with pros and cons. 2. Destroying of common myths associated with selected approach (like if dependencies will be eliminated, size of packages will grow significantly). Possible research agenda: 1. Which benefits brings declarative property-based app manifest? 2. Which benefits brings reversing build system - package manager interaction order? 3. Can qmake automatically create app manifest in near future? 4. Does size of real applications packages really grow with no-dependencies system with SDK (which includes Qt)? 5. Which issues are in Listaller and existing build systems (mostly in qmake)? 6. Which pros and cons have installing a) from root b) from user to $HOME c) from partially privilegied, but non-root user (similar to wwwrun or vboxuser)? 7. Which ways exist to support development model build on newer system, deploy to older? Let me throw first stone: 1. Declarative manifest Main benefit is ability to handle this file automatically: index it, provide UI and either generate automatically from build system information or parse to get information back. Build systems is an excellent example: XCode, Visual Studio and CodeBlocks IDEs have property-based build settings, and they can automatically edit such settings for years. Meanwhile, no one IDE can automatically edit Autotools or Premake files, CMake editing is implemented only in KDevelop and is buggy; editing qmake in QtCreator also works wrong in complex cases. 2. Reversing build system - package manager Typical project selects one build system, but targets to many platforms. At first, when package manager handles buildsystem, user should manually debug package manager scripts on each platform. At second, build system developers do not want to implement creating packages (because package manager designed to handle build system): https://bugreports.qt-project.org/browse/QBS-16. At third, this situation previously led to ugly design of make-based build systems: they are script-based and expose hooks to package manager with environment variables or configure options, but have no ability to easily use different build configurations (Debug, Release) in same time, and portability between platforms achieved with hacks or annoying debugging. Declarative build systems have no such problems. 4. Packages size on disk and in memory. QtCreator in Ubuntu depends on Qt and Botan libraries. It doesn't depend on Botan in upstream version, since it keeps Botan copy in sources. Most crossplatform apps keep dependencies set as small as possible, because Windows and Mac OS X have no dependency-based package system. So, size growth will be insignificant. 5a. Listaller issues Currently Listaller handles build system: http://listaller.tenstral.net/docs/doc/packaging.html. Meanwhile, buildsystem should handle listaller, and do it easily. No one developer wants to manually write and debug list of files to install. 5b. Qmake issues QMake have INSTALL variable that tracks installable files, but doesn't keep target bundle version, description and name. Since QtCreator have qmake evaluator, it can be patched to create or update manifest file, but some information should be typed by developer. 7. Build on newer system, deploy to older Listaller and LSB tools from Linux Foundation both use wrappers around gcc and special linker wrapper / special version of glibc respectively. Another way used in Mac OS X and iOS: XCode contains several SDKs, and application builds with only one in sysroot. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
Hello! I want to ask some questions about new packaging manager (which I awaited for many years...) and add some requests while it's not too late. Questions: 1) Which libraries you will consider as BASE system? I hope not just Ubuntu default installation will treated as base system in purposes of distributive- and OS- independence... This set of libraries and it's versions will change in time, new libraries will require some system calls which is not available in older kernel versions. Also if this library set is quite small, could they be placed in every package? 2) Do you plan to use components in packages? Some details required about this question. Let's assume we want to pack Qt SDK with your brand new packaging manager. It will consist of Qt Creator, Qt library itself, documentation and sources. And of course, it would be convenient to include GCC or some different compiler it same package. But we want set of packages without unconvenient dependencies... I suggest to add support of package of packages as it done in Mac OS X (also, Qt SDK installer also could do this). Back to example, single Qt SDK package with several components packages inside, and we can choose which to install. If we already have compiler, we click to not install this component. Of course, this package of packages on top of plain packages, which installing by single click... I hope to see restore functionality (if we want to reset package to defaults and restore missing files). 3) Will directory with contents of package include it's version? P.S. Excuse me for my worse english... -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
mailto:cjwat...@ubuntu.com%20 Hi, mailto:cjwat...@ubuntu.com%20 I'm independent programmer not very connected over few years with Open Source software (like earlier). Your information about Click packages was cited in various IT portals and I have few comments: First - some time ago I was thinking about something similar, but it wasn't accepted by admins: http://brainstorm.ubuntu.com/idea/30533/ Second - I think, it would be nice to consider such scenario: there are left possibilities of installing current software and new format is built on top of it (like you propose), but it's a little more mature and during installation user is informed about few things: 1. Firewall network rules required by application (if application will try to get more after installation, system won't allow for it) 2. Task scheduler tasks (what will be run in cyclic manner and what will be run for example during system startup) 3. Permissions required by application (similar like in Android - for example access to concrete devices like GPS or Bluetooth) Later after installation it's possible to check it and revoke some of them (make them disabled). Format should allow for such things like providing kernel modules or access to concrete USB devices (it will allow for making for example players for concrete TV tuners) I was thinking also about limiting access for files by format (like in Windows) and user directories (in easy way - for details please refer to http://brainstorm.ubuntu.com/idea/30533/), but in Linux distribution it won't be probably possible. For now I think too, that there should be resolved problem of temp files (but rather on higher OS level) - OS should have ability of easy making RAM Disk for temp directory and temp files (separated of course) from Click apps should go there too. Regards, Marcin -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
On Wed, May 08, 2013 at 11:14:08AM +0100, Colin Watson wrote: I should have the prototype ready for people to look at in time for UDS next week, lp:click-package - of course, no interfaces there should be relied on, and many are skeletal. and I'll ensure that there's a session scheduled for this. http://summit.ubuntu.com/uds-1305/meeting/21760/foundations-1305-click-package/ -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
On Mon, May 13, 2013 at 12:05:57PM -0300, Alejandro J. Cura wrote: Colin Watson wrote on 08/05/13 11:14: Is there anything else people can think of that a system like this needs to consider? This thread assumes that packages need to be uncompressed and installed before usage, so I'd like to ask if there was any discussion re: using something like squashfs images as the distributed packages instead of a zip or tar-like file. I know some of the other relevant systems do this, and I did think about it. The main downside I see is that I want apps to be always fully present on the filesystem; it doesn't make so much difference on a phablet, I suppose, but later on a desktop system people are going to want to look around manually, symlink to things, wrap things in scripts, etc. If we use a mounted-image scheme that then implies that we need to take care to mount all apps at boot time. I'm concerned about the possible effect on boot speed and reliability that that could have. I'm also not clear that there's been much research on whether this type of scheme has significant negative effects on things like elevator algorithm performance, caching, etc. The bottom line for me is that I'd like to keep things as simple as possible, and unpacking seems to me to be essentially simpler than a persistent-loop-mount scheme. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
On Mon, May 13, 2013 at 08:30:16PM +0400, Alex M wrote: 1) Which libraries you will consider as BASE system? I hope not just Ubuntu default installation will treated as base system in purposes of distributive- and OS- independence... This set of libraries and it's versions will change in time, new libraries will require some system calls which is not available in older kernel versions. At present, the target is the Ubuntu SDK, although this will be explicit in the packages which rely on it (Click-Framework: ubuntu-sdk-13.10 etc.). Also if this library set is quite small, could they be placed in every package? They will not be small. :-) 2) Do you plan to use components in packages? Some details required about this question. Let's assume we want to pack Qt SDK with your brand new packaging manager. It will consist of Qt Creator, Qt library itself, documentation and sources. And of course, it would be convenient to include GCC or some different compiler it same package. But we want set of packages without unconvenient dependencies... This just seems to be a complex enough case that it's simply not a good target for this packaging system. I'm OK with that. As I said, this is not trying to be a complete replacement for debs, because if it tried to do that it would rapidly turn into a second system with a different set of flaws. I hope to see restore functionality (if we want to reset package to defaults and restore missing files). The unpacked package directory will not be writable by the ordinary user or the application directly, and should therefore not change. As such, I don't think a restore feature should be necessary. 3) Will directory with contents of package include it's version? Yes. There'll be a symlink to the current version for convenience. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
On 13-05-13 11:05 AM, Alejandro J. Cura wrote: Colin Watson wrote on 08/05/13 11:14: Is there anything else people can think of that a system like this needs to consider? This thread assumes that packages need to be uncompressed and installed before usage, so I'd like to ask if there was any discussion re: using something like squashfs images as the distributed packages instead of a zip or tar-like file. This would mean that such downloaded images can be mounted read-only by whatever launches applications, using nosuid, nodev, and with the required uid, and then run immediately, instead of having to go thru a copy of files from the package to the storage, which slows down installation and usually requires double the storage space. I'm surely missing some bits of the picture, so please flame me if that's the case. That would mean we'd need to have a privileged helper to be able to mount application packages at application execution time. There are a lot of security implications of doing something like this, and I fear this would be a substantial attack surface. Marc. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
Colin Watson wrote: On Mon, May 13, 2013 at 08:30:16PM +0400, Alex M wrote: I hope to see restore functionality (if we want to reset package to defaults and restore missing files). The unpacked package directory will not be writable by the ordinary user or the application directly, and should therefore not change. As such, I don't think a restore feature should be necessary. For those users who might need such a thing (e.g. partial loss of data from recoverably damaged secondary storage), wouldn't a reinstall of the relevant package work? dpkg is usually happy to overwrite files for the same package, and I don't see anything in the current code on launchpad that ought prevent this method working. I've certainly used the equivalent for normal packages in such situations in the past (although in practice, it is typically less painful to reinstall for significant recoverable damage). -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Fwd: App indicators in Java
Il giorno lun, 06/05/2013 alle 09.01 +0200, Marlin Cremers ha scritto: Hey Ted thanks for responding. So I've been trying some things by looking at the Ubuntu One source. I did succeed in getting a item in the sync menu. However I'm also trying to implement the on/off button. When its toggled it returns a GParamBoolean 'paused' but how do I access the state? I can't seem to get the value from it. So how would I do that. Also when I toggle the button for the first time my app doesn't seem to get a signal. Only the times after that. Do I need to listen to it in another way? I'm using this at the moment: self.app.connect(notify::paused, self.sync_stage_change) Marlin You can probably check the UbuntuOne code to see how to interact with the SyncMenu, give a look to http://go.3v1n0.net/10STY0G -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Should we sunset brainstorm.ubuntu.com?
Hi everyone, I got a ping from the technical board before their semi-annual review of Brainstorm ideas. There are some problems with the site, mainly: a) It is unmaintained (As you can see from the design). b) User interest (as indicated by the voting) is waning. c) It seems that developer interest is waning to a point that some developers feel that responding to the ideas isn't an ideal use of time. d) Most advanced users know how to contact developers and file wishlist bugs with the software affected directly and use those means instead. A cursory scan of the incoming ideas over the last 30 days seem just like wishlist bug reports, thoughts? -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
On Tue, May 14, 2013 at 03:23:26AM +0900, Emmet Hikory wrote: Colin Watson wrote: On Mon, May 13, 2013 at 08:30:16PM +0400, Alex M wrote: I hope to see restore functionality (if we want to reset package to defaults and restore missing files). The unpacked package directory will not be writable by the ordinary user or the application directly, and should therefore not change. As such, I don't think a restore feature should be necessary. For those users who might need such a thing (e.g. partial loss of data from recoverably damaged secondary storage), wouldn't a reinstall of the relevant package work? Yes. Or we could just remove the unpacked package directory and install afresh, since it contains nothing irreplaceable. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: App installer design: click packages
On Mon, May 13, 2013 at 01:56:43PM -0400, Marc Deslauriers wrote: On 13-05-13 11:05 AM, Alejandro J. Cura wrote: This thread assumes that packages need to be uncompressed and installed before usage, so I'd like to ask if there was any discussion re: using something like squashfs images as the distributed packages instead of a zip or tar-like file. This would mean that such downloaded images can be mounted read-only by whatever launches applications, using nosuid, nodev, and with the required uid, and then run immediately, instead of having to go thru a copy of files from the package to the storage, which slows down installation and usually requires double the storage space. That would mean we'd need to have a privileged helper to be able to mount application packages at application execution time. There are a lot of security implications of doing something like this, and I fear this would be a substantial attack surface. And even if we mounted them all just once at boot, (a) we'd still need to use root privilege to mount at application installation/upgrade time, (b) any bug in squashfs would now become an easy escalate-to-kernel vulnerability exploitable through the app store. Now, (b) is still true for dpkg/tar/etc., but tar is already assumed to take hostile input, and the relevant parts of dpkg are mainly shared with unprivileged operations such as 'dpkg -c' which are also assumed to take hostile input and have had a good deal of attention over the years; and even if there is a problem we can at least contain it to a less-privileged specialised 'software' user. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Redirect uploads from -updates to -proposed? [Was Re: Bug 1166294]
On Mon, May 13, 2013 at 8:05 PM, Adam Conrad adcon...@0c3.net wrote: Ignore the above message about this being Fix Released in raring- updates. This was due to the uploader mistargetting the upload to -updates instead of -proposed, and I have since copied it back to -proposed and it will be deleted from -updates. Please verify this SRU as usual, and we can migrate it once it's been checked. Sorry about that. For some reason I was under the impression that uploads to -updates were now redirected to -proposed, like is done in the development release. Which begs the question of why we don't do that. Redirecting uploads from -updates to -proposed would be more consistent. Unless I'm missing something, nothing should ever go directly into -updates. Even packages with MicroReleaseExceptions still have to go through -proposed; they just don't need to manually verify each specific bug-fix. Thanks, -- Andrew Starr-Bochicchio Ubuntu Developer https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb PGP/GPG Key ID: D53FDCB1 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Redirect uploads from -updates to -proposed? [Was Re: Bug 1166294]
On Mon, May 13, 2013 at 08:36:22PM -0400, Andrew Starr-Bochicchio wrote: Sorry about that. For some reason I was under the impression that uploads to -updates were now redirected to -proposed, like is done in the development release. Which begs the question of why we don't do that. We redirect from $series to $series-proposed (ie: you can upload just to raring or precise, and many people now do), but it seems we never got around to either redirecting or rejecting -updates uploads, I've just finished a conversation with our lead Soyuz developer about this very thing. ... Adam -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes of Technical Board meeting from 2013-05-13
Also available on the wiki at https://wiki.ubuntu.com/TechnicalBoard/TeamReports/13/May Chair: Martin Pitt Other members in attendance: Stéphane Graber, Soren Hansen Apologies: Matt Zimmerman, Colin Watson Full log: http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-05-13-20.07.log.html = SRU request for custom unity-greeter indicators (Mike Terry) = * One positive answer on the ML, no objection from other members. Granted. = openssl as a system library (Dave Walker) = * Carried over to next meeting as Colin has a strong and well-founded position but could not make it to today's meeting. = SRU approved without waiting in unapproved (Jonathan Riddell) = * Unanimous agreement that this is not a flaw in the defined SRU process, but a flaw in its execution. We do not want to give up peer review for what goes into stable releases, and rather want to address the workflow problem in the SRU team. * ACTION: Martin to mail SRU team members about this = Brain storm review = * Due to radically decreasing interest from both Ubuntu developers (judging by the decrease of answers) as well as users (judging by the decreasing number of voters) the TB feels that it is time to end brainstorm.ubuntu.com and its regular review. * The sole remaining maintainer (Stephane Graber) as well as the Ubuntu community QA team (who founded this service initially), represented by Jorge Castro and Nicholas Skaggs, all agree. * ACTION: Jorge to check whether brainstorm.ubuntu.com could be kept as a read-only archive, and otherwise shut it down. Chair for next meeting: Kees Cook -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
