[Bug 1752591] Re: CVE-2017-7651 and CVE-2017-7652
Thanks for the cleanup Marc :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1752591 Title: CVE-2017-7651 and CVE-2017-7652 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mosquitto/+bug/1752591/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1364544] Re: Openafs Not Building on arm64
** Changed in: openafs (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1364544 Title: Openafs Not Building on arm64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1364544/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1364544] Re: Openafs Not Building on arm64
Please find attached a debdiff applying the upstream patch and necessary packaging adjustments. While this is expected in the next upstream release, that is not expected to happen in time for bionic, making this change useful to adopt in advance of Debian, but only for release scheduling reasons (as Debian is better served by an updated git snapshot in due course). ** Patch added: "debdiff applying upstream port patch" https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1364544/+attachment/5079945/+files/openafs_1.8.0~pre5-1ubuntu1.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1364544 Title: Openafs Not Building on arm64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/1364544/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1752591] Re: CVE-2017-7651 and CVE-2017-7652
For clarity, the current debdiffs only address CVE 2017-7651, and I probably didn't add the right metadata to the changelog. I did not find the patches for CVE 2017-7652 to be trivial to port to the versions of mosquitto in Ubuntu artful or xenial. Bionic is not vulnerable to either, as a result of a recent sync from Debian. The use case I am supporting is largely unconcerned about the risk from CVE 2017-7652, so I am unlikely to put any effort into backporting that fix (and would prefer a separation of resolution for 7651 vs. 7652 unless if feels really easy to someone else (as 7651 is an immediate issue that likely affects xenial and bionic users). Anyone who has a current understanding of the correct metadata to put in debian/changelog is welcome to replace my debdiffs with corrected ones, including removal of my name from the changes if preferred (or leaving my name despite debian/changelog modification, if blaming me feels better at the time). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1752591 Title: CVE-2017-7651 and CVE-2017-7652 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mosquitto/+bug/1752591/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1556277] [NEW] When using unity, the diplomacy and cities menus are not shown for freeciv-gtk3
Public bug reported: Freeciv upstream now recommends freeciv-gtk3 as the appropriate client. While freeciv-gtk2 was fixed in bug #1242937, freeciv-gtk3 now needs the same adjustment. Eventually this might change in upstream freeciv, but there are no plans within the 2.x series at this time. ** Affects: unity-gtk-module (Ubuntu) Importance: Medium Assignee: Scott Kitterman (kitterman) Status: In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1556277 Title: When using unity, the diplomacy and cities menus are not shown for freeciv-gtk3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-gtk-module/+bug/1556277/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1556277] Re: When using unity, the diplomacy and cities menus are not shown for freeciv-gtk3
Debdiff including the necessary patch ** Patch added: "debdiff for 0.0.0+15.04.20150118-0ubuntu2" https://bugs.launchpad.net/ubuntu/+source/unity-gtk-module/+bug/1556277/+attachment/4596269/+files/unity-gtk-module_0.0.0+15.04.20150118-0ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1556277 Title: When using unity, the diplomacy and cities menus are not shown for freeciv-gtk3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-gtk-module/+bug/1556277/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
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: Compiling software with same options
Lanoxx wrote: thanks a lot for this explanation. I tried it and everything works until the last step. When I run sbuild, then it get a warning like this: W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or ‘/etc/schroot/chroot.d’ And the build finishes with this message: Finished at 20130127-1604 Build needed 00:00:00, 0k disc space So it appears that no .deb package was generated, right? Do I need to do something to set up the chroots? Yes, to use sbuild, you would need to set up build chroots. The sbuild documentation discusses a few ways to do this, and there are many variations you might find online. The simplest to document is to install the ubuntu-dev-tools package and run `mk-sbuild`, although this makes many assumptions about your environment and build preferences. -- Emmet HIKORY -- 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: Compiling software with same options
Lanoxx wrote:
I have a question regarding the options that are used to build the
source code of a package, there are often some options that can be
passed to either ./autogen.sh or ./configure which influence what
module are build or how a libarary or program is build. How can I
find out which options were used originally when the package was
build by Ubuntu?
For example I would like to rebuild the glib2.0-x source from Ubuntu
12.10 with a small patch. I have already downloaded patched and
compiled the Ubuntu source of glib2.0 with:
apt-get source glib2.0-...
//apply patch ...
./autogen.sh --prefix=/opt/... make sudo make install
And now I want to compile and install it into the prefix=/usr for
fix the bug on the system.
However given that glib is quite an essential library I am a bit
afraid that I am forgetting some important options and that
something might be broken afterwards. Could anyone give me a hint
how to properly compile this package?
Compilation and build of Debian-format packages is controlled by
the debian/control and debian/rules files. Chapters 4 and 5 of Debian
Policy describe these in some detail. For best results, you would want
to add your patch to those already being applied in the packaging, build
an updated source package, and create binary packages with sbuild, pbuilder,
or a PPA (or other archive build system). In the specific case of glib-2.0,
one set of commands to accomplish this would be:
apt-get source glib2.0
cd glib2.0-*
export QUILT_PATCHES=debian/patches
quilt import ${path-to-new-patch}
quilt push
dch -i
debuild -S -us -uc
cd ..
sbuild -A -d quantal-amd64 ${path-to-updated-dsc}
For quick local testing, you may often approximate this by ensuring
that all the Build-Depends, Build-Depends-Indep, and Built-Using packages
are installed and that none of the Build-Conflicts or Build-Conflicts-Indep
packages are installed, applying your patch, updating the changelog, and
running `dpkg-buildpackage -us -uc -b` (or calling debian/rules targets
directly if you prefer). Note that the results of this procedure may differ
from that above due to differences between your local system and the pristine
environments used by build management tools, so this may not be a complete
test of how the patch would integrate if applied to the package generally.
--
Emmet HIKORY
--
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
[Bug 924508] Re: Lucid to Precise: must Conflicts and Provides/Break older wildmidi to prevent APT loops during upgrade
The quantal upload is a no-change upload, and is not intended to fix any bugs. It should be tested only for regression potential, as the bug cannot manifest in quantal with any supported transition. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/924508 Title: Lucid to Precise: must Conflicts and Provides/Break older wildmidi to prevent APT loops during upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wildmidi/+bug/924508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: nautilus search function/ how about Nemo?
lukefro...@hushmail.com wrote: If Linux ever includes keyloggers or digital rights enforcement software, the open-source nature of the project means that would be detected almost instantly. That should be enough to make sure that malicious software never gets into the kernel except as a patch from a distro. You might think about using kernels directly from upstream if distro versions ever become untrusted, though all patches are applied as source and can be examined. We've had both for a while: the event stack can be asked to duplicate events to another stream, so it's relatively trivial to have a lightweight userspace program capture all keystrokes, mouse movements, etc. Most folk who use this use it for debugging purposes (for which it is incredibly useful). For DRM enforcement, one would use the feature that only permits launching signed binaries, and only sign binaries that enforced the set of restrictions one wanted enforced: I think most users of this feature are currently providing kiosk environments, but I may be mistaken. What is important here is that we, as the deveopers of Ubuntu Studio, have a choice about which software we provide, and we can select which features we enable or disable as we do so. Sometimes one of the upstream development teams whose work we have been using will have a philosophy that differs from our own, and in such cases we may need to seek extensions or alternatives to what they provide. Sometimes one of the upstream teams whose work we have previously ignored will develop a tool that we find very useful for the sorts of workflows we wish to enable, and in such cases we may choose to add their software to that which we recommend. There is nothing inherent in the Ubuntu project that inhibits these decisions, and we'd have branding issues were we to select another project within which to produce our distribution (or create a new project), as well as having reduced opportunities for collaboration with other flavours (for exampe, it's fairly nice to just be able to ask the Xubuntu team if we have an uncertainty about anything XFCE, rather than needing to track it down ourselves). So, at those times when we find that upstream changes affect us, let's focus on what needs doing to address this (patches, selection of additional tools, selection of alternate tools, etc.), rather than worrying about whether we agree with some philosophy expressed by the changes or about what choices other flavours may be making if those choices don't happen to correspond with the pursuit of our goals. Bringing the subject back to original topic, I was looking at Nemo about a week ago, and it looks like it won't get into Debian within the timeframe for this release. We could certainly include it directly in Ubuntu (although this may be a bit of work), but if we do so, we'd also want to update the versions of cinnamon, muffin, etc. we have in the archives, for which best practice would involve working with the current Debian mantainers to ensure we can share packaging and revert to inheritance for raring+1. Depending on the future direction of Nemo (intending to more closely integrate with cinnamon), this may or may not be possible as a long term choice, unless we're planning to also adopt cinnamon: more discussion with upstream may be useful to determine whether this makes sense, or if we might do better to direct our efforts towards another file manager or search provider. -- Emmet HIKORY -- 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: Styles of Packaging
Mike Carifio wrote: I would opine that many application developers are more than annoyed, they're lost. So presenting them with all the various variants and then asking them to select the right one based on criteria they neither appreciate nor care about pretty well assures that many will silently walk away. I know I'm saying the same thing a different way, but it bears repeating. Oh, indeed. There should be a simple default method presented for the ease of this audience. My fear is only that if we push too far, we lose the ability to handle exceptions, or fall into painful bikeshedding about the one true way when in practice the judgement should be on the end, rather than the means. As I understand it, policy based packaging just means declarative and declarative means I can state *what* I want and the toolchain will figure out the *how*. I don't find that true in practice, however. I find that I state the what in debian/control, then figure out the how in debian/rules and then figure out why I didn't say it all properly. So I google and find a thicket of various approaches and workflows which only serve to confuse me more. Your understanding matches mine. For purposes of how, I currently believe that the use of /usr/share/doc/debhelper/examples/rules.tiny should be complete from the perspective of application developers: nearly anything else may well indicate issues with the underlying build system. That said, from the perspective of distribution developers, I think it's important to understand debian/rules as something supporting an API for package creation and interaction to support uncooperative, abandoned, or strongly opinionated upstream developers when others are handling the packaging. Ensuring that we can support both audiences from the same documentation is tricky, but it should be our goal. I see packaging as something we want the app developer to do. They have the most knowledge about their application. Given a reasonable bar, I think they will actually do it. After all, they're written the application and they want to see it used. If/when Ubuntu's popularity grows, then the incentive to package will grow. But let us never forget that this is a tax they must bear to integrate into Ubuntu. If the tax is too high, they just won't do it. So we may appreciate a policy-based approach, the richness of many toolchains and so on. But *they* don't, unless it makes their lives easier. Note that I'm not saying that packaging is easy. I'm just saying it can't be a research project for each rookie developer who wants to take a shot at it. There have been many discussions in the past about generating documentation targeted to recommended procedures for build systems and release procedures for application developers to support the ease of packaging. Ideally, it should be possible to generate distribution artifacts that support near automated packaging for a variety of distributions (for debian-format distributions, this reduces to a need to write the Description and review if multiple binary packages are needed from a source artifact). This goes well beyond packaging and much is unlikely to be specific to an individual distribution, but is likely worth constructing, if there are sufficient members of the class of application developers willing to help define the nature of the issue (I'm not convinced it's something that distribution developers can see well enough to write well). Examples of things to address here might be handling init systems, writing man pages, use of .desktop or .service files, ensuring build systems allow for varied build and installation paths, documenting copyright and licensing assertions, modular configuration file handling, and similar issues. In my opinion, it would be best to have this also be a policy-based model, rather than an implementation-based model, but I suspect a simple set of recommendations can be constructed for common toolchains (e.g. If you're writing a desktop GUI in ruby, here's what you want to do to make it easily distributable. If you wrote it in python, you likely want to use this entirely different toolchain to do the same thing.), and that such documentation of best practices for application developers would reduce impression of integration tax, as the volume of effort to package something for a given target is significantly reduced. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Steve Langasek wrote: On Tue, Dec 18, 2012 at 09:33:18PM -0500, Scott Kitterman wrote: It only works better if you are using UDD. I agree that if your primary workflow is UDD based, then UDD branches are better. If I get a branch it's as useless for me as a debdiff is for you. When asked to sponsor things that have a branch, I generally decline or ask for a debdiff. Your decision to boycott UDD doesn't make a UDD branch useless. A debdiff for a merge of a new upstream package version actually *is* useless and is a waste of the sponsoree's time, for the stated reason that the review of such a debdiff involves re-doing the merge myself. This exchange leaves me even further confused about how UDD works, but reviewing merges for new upstream sources has always been a bit fussy, and while interdiffs of diff.gz worked reasonably for format:1.0 packages, there is no useful equivalent for format:3.0 packages. When I'm attempting to review someone else's merge, I generally want them to send me enough information that I can produce their candidate artifacts locally for upload, and generally want to do so in a way that reduces the opportunity for them to submit files that don't match history (either previously in Ubuntu or in Debian). My review tends to consist of looking at the prior Ubuntu-only changes, looking at the upstream changes, looking at any changes beyond the new upstream version from Debian, and ensuring that the resulting artifacts contain the best possible blend of all of these (possibly combined with fixes for other outstanding bugs found in Ubuntu). With a non-UDD workflow, this involves getting the outstanding Ubuntu diff (patches.ubuntu.com or merges.ubuntu.com have them if one doesn't want to download source artifacts and run locally), getting the Debian diff (also available from merges.ubuntu.com), and some artifact diff (which could be that presented for sponsoring, although I tend to generate local artifacts and regenerate the diff). If I want to separate distribution changes and upstream changes, filterdiff can help, or I can run diffs only against contents of debian.tar.gz (or other selected artifacts). With a UDD workflow, this involves getting the candidate branch, reviewing the history to confirm it inherits from preexisting UDD branches, and then using bzr to generate the same set of diffs, for the same level of manual consideration. There are no shortcut pre-generated diffs I can download, but the bzr branch contains everything so there is no need to pull from multiple sources: depending on one's local environment this may be either good or bad in terms of total bandwidth and processing requirements (and one can convince launchpad to generate the diffs, if one is sufficiently motivated and lacks local processing facilities). In either case, once I have a local artifact, unless I'm dealing with a package that is handled by some team that doesn't like it, I can just upload. When I'm dealing with packages where teams want special things done, regardless of which solution I choose above, I need to go fiddle with their special VCS arrangements or get complained at later. Now, it may be that in one of my summaries above, I've mischaracterised one of the workflows, and if so I'd very much like to read an expansion of both procedures by someone who has a very strong preference for one or another workflow based on what they consider to be the user experience. On the other hand, if I've not mischaracterised it, how can *either* the branch or the necessary diff to generate candidate artifacts be useless? While I don't personally see any benefit of one over the other except in terms of access speed to review materials (which depends on sufficient local factors that it isn't likely to be generally applicable), I don't understand how I would have to redo the merge in either case, how I would be able to perform the necessary level of scrutiny of the candidate without reviewing the same set of diffs (ubuntu-to-common-ancestor, debian-to-common-ancestor, candidate-to-debian, new-upstream-to-old-upstream), nor why I would need to perform any file editing or reconcillation as part of this review. Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? -- 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: UDD vs. non-UDD for merging (was: Deprecating the wiki-based Packaging Guide)
Scott Kitterman wrote: On Wednesday, December 19, 2012 01:02:21 PM Emmet Hikory wrote: Is it not the case that if one prefers UDD, one can just pull the current Debian import from launchpad, apply the diff proposed by the candidate, run debcommit, and end up with a branch with all the same characteristics as if a branch had been submitted for merging? Similarly, is it not the case that if someone submits a branch, one can ask launchpad to generate the diff, and use that as the merge artifact in a non-UDD workflow? With respect to the last point, similar to your description of your work flow, I want to see the packaging diff including the Debian - Debian packaging diff, the Ubuntu -- Ubuntu packaging diff and the Debian old/new -- Ubuntu old/new packaging diffs to ensure no Ubuntu changes have been inadvertently lost, the remaining changes are both needed and documents, and the changes from Debian are correctly applied. i end up needing then the old Debian and Ubuntu packages as well as the new Debian package and the proposed merged. There's probably some reasonable way for me to extract all that from some relevant branches somewhere, but to me it's far easier to use grab-merge and a debdiff. Do the diffs launchpad produces from UDD merge branches not work as an input diff with grab-merge? I've never tried for this specific type of merge, but in cases where it was just a patch being applied to an existing Ubuntu package, I had success pulling diffs from LP to apply. -- 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: Deprecating the wiki-based Packaging Guide
Andrew Starr-Bochicchio wrote: On Mon, Dec 17, 2012 at 4:53 PM, Benjamin Drung bdr...@ubuntu.com wrote: Am Montag, den 17.12.2012, 16:01 -0500 schrieb Andrew Starr-Bochicchio: 1) Send a last-call anouncement to ubuntu-devel requesting bug reports about any missing material. Announce steps 2 and 3 will take place after one month. 2) Move the entire PackagingGuide wiki namespace en masse to PackagingGuideDeprecated. 3) Redirect wiki.ubuntu.com/PackagingGuide to developer.ubuntu.com/packaging/html/ 4) After six months (one full development cycle) PackagingGuideDeprecated will be deleted. This is the mail referred to in step 1. In one month, I will move the entire PackagingGuide wiki namespace enmass to PackagingGuideDeprecated and set up a redirect. If you feel that there are any critical pieces of information that are missing from the Sphinx-based Ubuntu Packaging Guide, now is the time to file bugs (and provide patches). [4] Will these bugs tracked and fixed before step four? We should only remove the wiki based guide if all missing pieces from it are available in the Sphinx-based packaging guide. That said, I do think it is important to point out that all missing pieces will never be completely ported to the new guide. A large part of the reason for making the new guide in the first place has been to streamline it, making opinionated decisions of what to include, and eliminate the choose your own adventure style of the old guide. For instance, do we really need to discus desktop files and POD based manpages in the Packaging Guide? While I'm all in favour of a return to a managed (and packagable) packaging guide, I think there is value in being clear that folk who wish to package have a plethora of options available: by all means, let's advocate the latest labour-saving mechanisms, but at the same time, I think we need to avoid anything that implies there is some magic one true way to package. At least in the current text presented at developer.ubuntu.com, the suggestions on packaging new software recommend local compilation, which often hides all sorts of issues, although it significantly reduces the apparent setup required to get involved: I don't believe there is a good answer as to how folk should do this: some may prefer to set things up to match what they think most developers use, and others may just want to get something done. Similarly, we're recommending use of dh-make, and then recommending deleting all the example files that it produces: this is another case where there may be more value in having two paths: one that goes through the dh-make files, and the other that just focuses on changelog, compat, control, copyright, and rules (of which 60% are trivially generated automatically). Different folk learn differently, and as long as we're documenting things that we expect to be used not only for new packaging, but also for patching existing packages, it behooves us to ensure that we have coverage of all the different ways that packages might behave, and some guidance on how to discover when to apply any given rune from some assembled grimoire (assuming it will take some practice for folk to learn the tools well enough to remember how to do things without looking at their notes). Aside from my general belief that as long as we are careful to weave folk back into some central guide after each diversion, choose-your-own-adventure is the right model, I am *completely* certain that we should discuss .desktop files in the Packaging Guide: it's the means by which all XDG-compliant environments present applications to the user (even Unity, without XDG-menus, ends up using an index generated from collected .desktop files to fufill searches), and it's something that is often gotten wrong by upstream developers (because what makes a .desktop file work nicely on one's workstation isn't usually precisely the same as what makes a .desktop file work nicely as part of a distribution). Mind you, that discussion might just be references to the XDG spec, the relevant software centre documentation, and a pointer to the desktop-file-validate utility along with a couple paragraphs explaining why it's important to make it themeable, unique, HIGgy, etc. -- 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: Deprecating the wiki-based Packaging Guide
Andrew Starr-Bochicchio wrote: Hi Emmet! Hi! On Mon, Dec 17, 2012 at 8:11 PM, Emmet Hikory per...@ubuntu.com wrote: While I'm all in favour of a return to a managed (and packagable) packaging guide, I think there is value in being clear that folk who wish to package have a plethora of options available: by all means, let's advocate the latest labour-saving mechanisms, but at the same time, I think we need to avoid anything that implies there is some magic one true way to package. At There are many acceptable toolchains and approaches to packaging. My understanding of the aim of the new packaging guide [1] is not to suggest that there is one correct way to do things, but to provide a much clearer point of entry than the wiki guide. Excellent. This is precisely what the old docbook packaging guide did before we moved to the wiki. My apologies for being oversensitive to the idea of streamlining. least in the current text presented at developer.ubuntu.com, the suggestions on packaging new software recommend local compilation, which often hides all sorts of issues, although it significantly reduces the apparent setup required to get involved: I don't believe there is a good answer as to how folk should do this: some may prefer to set things up to match what they think most developers use, and others may just want to get something done. I'd be interested in the exact section you are referring to. Getting Set Up suggests the installation of pbuilder, and Tutorial: Fixing a bug in Ubuntu uses pbuilder-dist to compile. Am I misunderstanding what you mean by local? I was looking at Packaging New Software http://developer.ubuntu.com/packaging/html/packaging-new-software.html The local build in question is `bzr builddeb -- -us -uc` Yes, later it recommends pbuilder and PPAs, etc.: the criticism above was not intended as blanket criticism, but rather a pointer to a possible point of variance between different ways to address the issue. Some folk would regard having performed the local build hard, painful, and bad (especially if the software in question had many build-deps that were unsatisfied locally). Others almost always start with local compilation, considering a build in a structured environment to be part of the test and deployment phase of their work. I don't believe either school of thought is inherently right or wrong, but I do believe that it is important to make clear that folk who have already set up pbuilder (as documented in the Getting Set Up) may alternately do a source-only build and run the binary build in pbuilder (No, it doesn't matter much for hello, but nearly all the cross-platform tools that provide front-ends for a variety of desktop environments can significantly impact the user experience just by having the build-deps installed). we're recommending use of dh-make, and then recommending deleting all the example files that it produces: this is another case where there may be more value in having two paths: one that goes through the dh-make files, and the other that just focuses on changelog, compat, control, copyright, and rules (of which 60% are trivially generated automatically). I'm not sure how this differs from the wiki-based guide where you find this, for example [2]: | Running dh_make creates the basic files needed in debian/ and many template | files (.ex) that may be needed. The Hello program is not very complicated, and | as we have seen in the section called “Packaging From Scratch”, packaging it does | not require much more than the basic files. Therefore, let us remove the .ex files: | | cd debian | rm *.ex *.EX It doesn't differ significantly at all. My point was only that I don't think this represents the best of what we could achieve if we attempt to streamline it, making opinionated decisions of what to include and eliminate 'choose your own adventure' style. Plus, because there are so clearly two different ways to introduce folk to all the various sorts of helper files (generally dh_*, but also some of the older ones), it seemed a good candidate to illustrate the value of multiple possible streams of documentation. The Sphinx-based guide also contains a knowledge base article about files found in the debian directory. I'd be happy to merge a branch that expands on the Additional Files section. [3] Heh. If I had such a branch, I'd be happy to propose it :) For that matter, I think we'd both prefer to review how to improve the current document from the results of a real review, rather than issues cherrypicked for the sake of a (somewhat) unrelated assertion. Aside from my general belief that as long as we are careful to weave folk back into some central guide after each diversion, choose-your-own-adventure is the right model, I am *completely* certain that we should discuss .desktop files in the Packaging Guide: it's the means
Re: Bug in libicu48-dev please update version 4.8.1.1-8 = 4.8.1.1-10
Lanoxx wrote: Yeah, but for some reason it didint go into quantal and precise? I know that new features down go into stable releases, but this is a bug fix release, so I assume it would go to the current stabel versions as well, not? Should I manually pull the raring package and install it in quantal now? The migration of such fixes into earlier releases is very much a manual process (0). The change for -10 might be appropriate (to my non-authoritative eyes), but the change for -9 probably isn't. You might want to follow up on bug #1037588 (1), where there is a start on SRU processing for quantal. In this specific case, I suspect it unlikely that the change will be processed, based on my reading of the current bug comments, although with the status set to Incomplete, I do not believe a final determination has yet been made, and is likely pending preparation of a quantal-specific patch along with comprehensive test results documenting the impact, etc. as required by the SRU process. 0: https://wiki.ubuntu.com/StableReleaseUpdates 1: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1037588 -- Emmet HIKORY -- 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: can't use apt-get command with ubuntu core
Saqlain Abbas wrote: I have installed Ubuntu core on VM i followed instruction from https://wiki.ubuntu.com/Core I am able to boot and login, but if try apt-get install I get below errors, my system (virgin ubuntu core) got no packages installed like synaptic package manager etc could not open lock file /var/lib/dpkg/lock -open (13:permission denied) unable to lock the administration directory (/var/lib/dpkg) , are you root? I can't try using sudo command as it is not installed on (ubuntu core). If you wish to run apt-get, you will either need to grant a root password, and use su, or mount the filesystem on some other machine, chroot into it, and install sudo from the chroot. [T]he user i created ubuntu I added it to adm and sudo groups, groups command shows it is added to ubuntu adm and sudo groups. My other part of question is as user is added to sudo group why i got no root permission? Because the sudo package is not installed, so there is no interpretation of the sudo group meaning anything. While the adm group does grant the ability to access many files, it does not provide for any sort of root access. -- Emmet HIKORY -- 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
[Bug 1066387] Re: D-I install menu, select Boot from first hard disk and it goes back to Language selection
** Also affects: ubuntu-cdimage Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1066387 Title: D-I install menu, select Boot from first hard disk and it goes back to Language selection To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1066387/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1066387] Re: D-I install menu, select Boot from first hard disk and it goes back to Language selection
Setting the syslinux status to Invalid for now: currently syslinux is being instructed to localboot 0x80 from the boot menu, which relies on the BIOS actually setting the first (non-syslinux-containing) disk to this address. For folk booting from remapped drives, this fails. Note that there may be a syslinux bug related to this issue, that syslinux may not have sufficient syntax to allow a menu item to express boot from a hard drive other than the one that just booted beyond reliance on BIOS calls (e.g. -1 to send 18h): in such a case, if someone wants to repoen this issue against syslinux to address that, rather than creating a new bug, I encourage them to unset the invalid status. ** Changed in: syslinux (Ubuntu) Status: Triaged = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1066387 Title: D-I install menu, select Boot from first hard disk and it goes back to Language selection To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1066387/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 924508] Re: Lucid to Precise: must Conflicts and Provides/Break older wildmidi to prevent APT loops during upgrade
The attached patch looks correct to me, and I encourage it's application if anyone can verify it fixes the issue (as noted in other reports of this issue, I have been unable to replicate this at all). Note that *only* lucid-precise upgrades are affected, so this change only needs to be applied to precise. The upgrade path lucid-maverick-natty-oneiric-precise is safe, as is anything post- precise, from precise. Unfortunately, as there were no other changes in wildmidi in quantal, it may be required to push a no-op upload to quantal (without this patch) to ensure a forward progression of updates for precise-quantal-raring (development) upgrades. I expect to push a new upstream to raring, which would provide a larger version for upgrade, but if someone wants to verify and fix this before that happens, please also upload a no-change version-bump to raring to preserve the versions of the upgrade path. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/924508 Title: Lucid to Precise: must Conflicts and Provides/Break older wildmidi to prevent APT loops during upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wildmidi/+bug/924508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Plymouth text version
Len Ovens wrote: On Mon, November 12, 2012 10:28 am, lukefro...@hushmail.com wrote: Interesting. I was not aware plymouth started so late on installs. I was under the assumption it still started in initramfs. In short, there are two cases where plymouth actually works right: live installers and machines with cryptsetup installed, with or without any encrypted partitions. I don't know if we want to install cryptsetup by default just to get plymouth to work. -settings may be able to set this up though... or maybe -look should do that? Although it will look better (and in cases where the user needs to interact prior to x-display-manager launching will work better), choosing to force plymouth on in cases where no interaction is expected will slow the boot process, although not by terribly much. In some extreme cases, it may also enlarge the initramfs larger than can be stored properly, but none of our users installing from images should encounter this issue. In the case this is desired, the solution is to ship the appropriate configuration in /usr/share/initramfs-tools/conf-hooks.d/, but given the nature of initramfs generation and regeneration, it would be better to either set this or not, rather than have some configuration option: there are too many other packages that could conceivably have a requirement for early-user-interaction that could turn it on for user-visible settings to respond as expected to changes by the user. -- Emmet HIKORY -- 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: Plymouth text version
Ho Wan Chan wrote: no no no I mean to abolish the text theme ONLY. The graphical one should remain. This means that we have no output multiplexor when booting on devices that are in VGA fallback mode: as it turns out, in addition to some virtual environments, this is also true for lots of actual hardware (albeit low-end). While we don't really expect anyone to run a full DAW in such environments, there may be plenty of folk who have relatively underpowered machines they use as effects boxes of one sort or another in an analog mixer chain. That said, if there's no interest in maintaining a special Ubuntu Studio text theme, we could just fall back to the text theme used for the Desktop and Server products: there are few enough affected users that we're unlikely to receive too many complaints. -- Emmet HIKORY -- 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: Prevent deletion of file when it is being copied
Luis Mondesi wrote: Usually there are 2 solutions to these types of problems: 1. develop some complex code to deal with it 2. don't do the action to begin with Typically # 2 is the best answer. Writing complex code to avoid something that's obviously the wrong thing to do by the end user seems silly. The users simply have to wait until their files are copied. While often asking users to perform other actions can help with this sort of thing, we can certainly try to help users avoid making mistakes. I'm not sure how in this particular situation, given the vast number of tools that copy or delete files making it potentially risky to suggest that the problem is solved, but generally if there is a technical solution that can be done *once* to save every future user the effort of learning any given lesson, this represents a vast savings in the total human effort involved, and is hence a clear benefit. Why would you delete the file by shift-delete while is being copied!? While I'm not familiar with the details of the situation that started this thread, a possible answer to this question could be demonstrated by the following story: Alice and Bob share a laptop, and they find it convenient to have a single account for both of them, and use different workspaces to run their different programs. One morning, Alice decides to copy her collection of found audio recordings to their new network-enabled stereo. In the afternoon, Bob is using his workspace, and discovers that there is not enough disk space for the video he shot the day before, and asks if he can remove anything. Alice, being sure that she copied the files hours before, suggests her found audio files, which had yet to complete delivery over their home network. Bob knows that simply removing the file from a directory will not free space on the hard drive, so uses a shortcut to ensure that the contents are purged upon deletion, freeing up the space for the video clips. As Bob is using his workspace, rather than Alice's, he will not see the ongoing file transfer, so not be warned that what he is doing is potentially dangerous. Yes, this is contrived, etc. On the other hand, I suspect many of us have managed to be both Alice and Bob in a scenario much like that above when interrupted in the middle by some significant distraction, or just a sufficient span of time. -- Emmet HIKORY -- 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: Prevent deletion of file when it is being copied
Nimit Shah wrote: While copying a file from my computer to external disk, I by mistake shift+deleted the file. But still the file transfer dialog showed that it was continuing. At the end of the transfer it failed. Hence i request you to add a check for file transfer before deleting the file. As much as this would be a lovely feature, I don't believe that it is something that we could implement in Ubuntu. When copying a file, there are usually two ways to go about it: either open the entire file, and write it to a new location, or open a series of sections of the file, and write them each to a new location. There are a very large number of programs that provide both of these mechanisms in the archive. In the majority of cases, the first potential solution is not used, because it limits file copies to files that fit entirely in memory (with everything else), and requires a longer-running algorithm, but when the second method is used, the file cannot be allowed to be deleted before the file transfer is confirmed as complete. When deleting a file, the usual practice is to remove the reference from the directory definitions (unlinking), leaving the underlying filesystem to manage recovery of the newly available space. Again, there are a vast number of packages in the archive providing programs that do this. In order to implement the feature you describe, we would have to either provide some systems interface that traps all calls to unlink() and checks some external reference to determine if it is being copied or patch all software that could potentially delete files to check the reference, whilst simultaneously patching every package that provides a means to copy a file to populate this reference during the file copy, which would make all such operations considerably slower, with potentially massive impact on server capacities, interactive response times, and battery life. Further, it is unlikely that the developers and maintainers of most of the software in our archive would be willing to accept such patches, given the potential complications and incompatibilities with other systems, such that the result of this vast undertaking would require considerable ongoing development effort to port these patches for each new upstream release. Lastly, in the event that any of the programs providing file copy functionality were to crash, they may not properly clear the reference indicating files whose deletion need block on the transfer completion. As a result of such a crash (or any other bug when updating references), a user's system may end up having any number of files that cannot be deleted without manual intervention into the file transfer reference. -- Emmet HIKORY -- 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: Specialized kernel/base system for VM's/VE's
Enrico Weigelt wrote: is anyone currently working on optimized/minimized kernel and base packages for VM's ? My goal is having a really minimized base system for VMs and VEs, which don't have anything that's really needed there (eg. VEs dont need all the kernel related stuff, VMs just only those parts which are really required for running in an virtio-based environment, etc, etc). I suspect you're looking for the linux-virtual metapackage, and dependencies thereof for your kernel. You may wish to look at the available Cloud Images [1], which are likely suitable for deployment in your target environment with little or no modification. If the selection of modules in linux-virtual is insuffient for your target environment, the other modules are also available in the dependencies of the linux-image-extra-virtual package. 1: http://cloud-images.ubuntu.com/ -- Emmet HIKORY -- 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
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Also affects: asterisk (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: asterisk (Ubuntu Quantal) Importance: Undecided Status: New ** Changed in: asterisk (Ubuntu Quantal) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to asterisk in Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1048093] Re: Outstanding security fixes in asterisk
** Also affects: asterisk (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: asterisk (Ubuntu Quantal) Importance: Undecided Status: New ** Changed in: asterisk (Ubuntu Quantal) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048093 Title: Outstanding security fixes in asterisk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/1048093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1044479] Re: Sync graphicsmagick 1.3.16-1.1 (universe) from Debian unstable (main)
ACK. ** Changed in: graphicsmagick (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1044479 Title: Sync graphicsmagick 1.3.16-1.1 (universe) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphicsmagick/+bug/1044479/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1044479] Re: Sync graphicsmagick 1.3.16-1.1 (universe) from Debian unstable (main)
** Changed in: graphicsmagick (Ubuntu) Importance: Undecided = Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1044479 Title: Sync graphicsmagick 1.3.16-1.1 (universe) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphicsmagick/+bug/1044479/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Proposing a New App Developer Upload Process
Didier Roche wrote: Le 06/09/2012 10:20, Emmet Hikory a écrit : Given the current shape of the package, and the belief that packaging of this package could mostly safely be completely automated, would you expect that future uploads would be broken in some way so that these developers would be incapable of performing the maintenance? I think they should be able if I teach them about debian/changelog, dpkg-buildpackage, dput, gpg keys, signing the CoC… So even after the first upload, if they have PPU access, the bar to upload a new revision will still be high, even if there is no packaging changes to do. This makes sense, although I think that we'd want to ask folk to sign the CoC anyway, if for nothing else than to have their documented agreement to participate in our dispute resolution processes, for those exceptional cases where a problem occurs. Despite my agreement, I suspect that there is significant scope for improvement of this hurdle through automation without also forcing all participants to be subject to significant limitations on the functionality they are permitted to provide, and believe that as we develop the automation to support scalable automatic acception of applications, we should do so in a way that permits us to use what portions of that automation might reduce our educational requirements independently of our automatic acceptance system. In addition to that, as you told, the packaging is now done, but it took months for me to take some spare time to get to their package because of the queue of people asking me to package a new software is high, and I have other work to do for my direct work/life… So if relying to a human review or human first packaging from upstream will always take a lot of time (despite heroic effort on REVU, on the ARB, sponsoring queue…) and will give them a suboptimal first experience to deliver their application to ubuntu. Absolutely. My apologies if I gave the impression that this should be the typical model of inclusion - my intention was to use it as an example of a package where there had been time for human review (which we should only expect to be the case for a tiny minority of pacakges if we wish to scale broadly). [F]or applications, I think we shouldn't make everyone paying the high learning curve to developers. If they want to focus on packaging, we can direct them to this process, but if they don't, we need an easy way which have different tools, processes and reactivity. Those would of course, not cover the whole set of cases we can into the distro, but will deliver a snappy experience, which as much automation as possible on both packaging and server-side checking, in addition to insulation to protect our users. My concern here is that by maintaining entirely parallel processes, we create a situation where those whose software is unsuitable for the streamlined process must begin again, essentially from scratch, in order to deliver their software to our users. I'd much prefer that in these exceptional cases we had an integrated mechanism to assist the relevant developers with the delivery of their package - to be able to provide human review (resources permitting) and relax insulation restrictions without ever needing to give the developers any message that could be interpreted as rejection. Telling an application developer that their application is special, and that we apologize, but they will either have to wait for human review or limit the functionality of their software is a positive and reinforcing message. Telling the same application developer that their software cannot be accepted by this method, and they should go chat someone up on IRC, or repackage the software and resubmit it to some entirely other queue for which we won't hold their hand is less so, and may well cause those very developers whose applications would most enhance Ubuntu to discredit the process. Similarly, I would hope that as tools are developed to further automate the packaging process, these tools could be made available also to our developers, who might use them in producing packages intended for the current distribution mechanisms (where that distribution developer is presumably willing to provide human review for their own pacakge, but does appreciate the automation of the intial work). I strongly think that different process and scopes will need different tools and so, delivery mechanism. In addition to that, the tools will evolute quite quickly at the beginning, and we need to be able to change those without risking/impacting the distro and ubuntu developers. While I agree that we will need additional tools and an additional delivery mechanism to support arbitrary application developers interacting with an automated system to provide insulated pacakges to our users, I do not believe we need a different process, rather I submit that we should rather be extending our general process to include
Re: AppDevUploadProcess Automatic reviews
Michael Hall wrote: The only part of the spec that still uses a human review is in verifying the identity of the user (though some process yet to be determined). This is important because, as I mentioned above, the other parts of the spec are only intended to prevent accidental harm, not intentionally malicious code. We believe that verifying the identity of the uploader, so that it is not an anonymous relationship between the uploader and Ubuntu, should prevent intentional abuse on their part. For Ubuntu Developers, the current identity check consists only of ensuring there is a specific cryptgraphic secret associated with a given launchpad account, and ensuring that all uploads are checked in a way that requires access to this cryptographic secret, although we request that participants provide a believable pseudonym for use in maintaining the system. Are the identity verification mechanisms being mooted for this new process more stringent than that? If so how and why? Separately, unless we intend to impose a requirement for physical inspection of state-sponsored identity documentation in the presence of the individual whose identity is being verified, trust our identity reviewers to be familiar with these forms of documentation, and trust the applicants to be submitting true documents, why does this step require human review? What are the hard problems involved that would require human intelligence to resolve and cannot be automated? The specification appears to only require unsigned text submitted to MyApps, and I suspect that one could write a program that generated such text based on information available on an arbitrary project page. While such a submission might be later disavowed by the individual whose credentials had been borrowed for the purpose of submission, I am unconvinced that the documented non-interactive process is sufficient as a turing test, and would find it unfortunate if we expended human effort without some assurance that our counterparties were also so required to expend human effort. If there is a case of intentional abuse, we would be able to remove that app and prevent the submitter from using the system again. In the event of apparently intentional abuse, I'm unsure that the appropriate resolution is to prevent the submitter from using the system again: I'd prefer to see a limited cool-down period: for example 1 year, during which we ask that the person refrain from use of the system, and fail to accept their packages. Further, I would suggest that whatever terms of service are constructed indicate that the creation of new apparent identities during this time are subject to being added to the set of users whose packages will never be accepted. There ought be a well-defined appeal process, both for acceptance blocks and for the associated removal of the software demonstrating the apparently intentional abuse. I'm also curious if there has been discussion of apparently unintentional abuse (ranging from excessively slow response to security issues through unacknowledged and obfuscated mechanisms to provide those with the appropriate knowledge access to run arbitrary code in the process space of the application (perhaps tightly linked to some hard-coded data source to avoid accidental detection)). To take one example, I'm not sure that we could differentiate, even with expert human code inspection, between the various intents that might generate an easily exploitable buffer overflow, nor accurately protect ourselves against subsequent social engineering efforts. We should have some means to remove such offending code, or better, to patch it once the potential for problematic behaviour has been identified (essentially forcing the software in question to be collaboratively maintained, if perhaps only for potential security issues), even in the case where there is a clear and persuasive argument that there was no malicious intent on the part of the application developer (who, for example, is willing to provide an overwhelmingly large volume of evidence that they had nothing to do with that particular botnet). -- 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: Proposing a New App Developer Upload Process
Sebastien Bacher wrote: Le 05/09/2012 03:55, Steve Langasek a écrit : Note that, independent of any packaging issues for Ubuntu, upstream best practice would have the absolute paths in these files generated at build time, once it's known where they will be installed. The specification [1] allows both unity the command name only or the full qualified path to it without recommending a solution. Looking through /usr/share/applications the vast majority of programs nowadays opt for the simple form, likely to avoid having to deal with an extra .desktop.in - desktop through sed handling [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html Bare names are generally preferred, not because of any effort to avoid preprocessing files (there are lots of examples where packages use .desktop.in - .desktop processing and leave barenames), but rather to let $PATH operate as expected, and similar. I suspect the use of the bare name for the executable is also made more popular by the frequent insistence by .desktop file reviewers that the icon should *not* be an absolute path (as this breaks icon themes), and folk expect this to apply to other entries as well. -- 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: Proposing a New App Developer Upload Process
discussion of the role of the DMB and how we wish to manage upload rights in general. That said, from my previous work on the DMB, I think that we would need to ask the DMB to develop a lightweight PPU-only process to scale significantly, as the processes in place during my tenure would be unsuitable for use if there were a significant number of submissions by such a new process. Note also that if we decide to use the DMB and the PPU mechanism, we would likely be expected to have extras be part of Ubuntu, with all that this implies in terms of other goverance issues *OR* have packages accepted by such a means be placed in the regular archives (and thereby be expected to be policy compliant and treated as normal packages aside from the submission process and PPU). - Should we remove the /opt install requirement? This is just an implementation detail of our current insulation. While it is the FHS way and used widely in commercial packages for other unices, I don't believe it is useful to discuss in isolation, and I believe very strongly that if we do decide that it continues to be a useful mechanism that we ought modify our tools so that the application developers need not care precisely where in the filesystem their applications are delivered. Obviously, there exist some applications that are unsuitable for any sort of /opt jail, but I believe these to be few enough in number that we can spare manual review to allow them to be installed without insulation. (which likely means not in extras with the current implementation). - Should we start developing tooling for more automated package checking/sandboxing? Absolutely: we have a limited capacity for human review, and we can likely safely say that there are always going to be more people who are interested in writing software that does something than are interested in reviewing the software and the packaging for that software, and there are *lots* of sorts of software that will operate perfectly within a highly restricted container, for which we ideally would be able to dispense with human review. In cases where we need human review (either because our automation is not yet sufficiently mature or the package appears unsuitable for automated inclusion), I think we need to be flexible about the restrictions we impose: unless we are particularly unable to select capable reviewers/collaborators, we should allow the reviewer to decide if a package needs to be limited in some way, or would benefit more from normal inclusion in the distribution, and empower that reviewer to implement their decision directly, without being subject to further review (with the possible exception that if there are sufficient resources to permit peer review amoung reviewers, this would be a good thing), and most importantly, without the application author needing to resubmit to a separate queue with completely different requirements. My ideal future looks something like: Debian and Ubuntu co-habiting on DebExpo (either on mentors.debian.net, or two sites with federated data), with a slick UI, and fantastic integrated tools for automated package checks. But, there's a lot of development work between here and there, I can't just snap my fingers and make it happen tomorrow. I don't believe this is sufficient for truly extreme scaling. While something of this sort would greatly facilitate anything that would benefit from human review, I am unconvinced that we have sufficient humans willing to review things that an ideal future would not also require the completely automatic acceptance and inclusion of packages to be placed under a set of restrictions that we agree is sufficient to prevent damage to our users. Obviously, for extra points, these automatically accepted packages ought also be available on the super-debexpo as potentially suitable for manual review either because they are really cool or because the vast number of reviewers are becoming bored as a result of having completed the collaborative packaging and inclusion of all packages that required manual review. -- 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: Proposing a New App Developer Upload Process
Didier Roche wrote: I don't agree it's only for low quality apps. More than once, people asked me to package their apps into ubuntu. This is particularly annoying when I have no interest at all in the package itself. The last case is pyromaths, which turned out to be quite popular in schools. It's definitively a quality apps and I kind of regret to upload it to ubuntu proper instead of letting them deal with myapps for now as I have to admit I won't do a good job tracking them. In this case, do you see any reason that the developers of this package should not be able to be granted PPU access to keep their software well maintained in the archive now that it has been packaged, rather than being subjected to arbitrary restrictions on what the software may be allowed to do? If so, what do you think would be required for you to feel comfortable endorsing such a grant of access? If not, why should any Ubuntu Developer refrain from such an endorsement if they consider the application well-packaged (either as a result of their collaboration or review of the packaging)? The MyApps story is to avoid those 2 pitfalls to occur: * having ubuntu developers working on what they want to work on and focus their effort on that, following the components they selected closely and be able to help them. * having application developers being able to have the control where they should have: their own applications and decide when they update. We can enable them to update as long as they do no harm to the platform (like in the file conflict case, and many other use cases requiring insulation). The ultimate goal is that all the packaging part is helped/assisted to them: it's not because I want to upload my application to ubuntu that I have to become a packager and know every detail of the debian policy. I just want to deliver my application to users. While these are both laudable goals, I don't understand why there needs to be such a firm separation between packages that are in Ubuntu and packages that upstream authors may update. While I am in favor of taking care to insulate our users from potentially malicious packages in the presence of a completely automated acceptance process, I expect that the vast majority of software authors would also be perfectly happy to be able to upload their software directly after receiving some manual review or assistance from someone knowledgeable about packaging, and I believe that we both can and should attempt to enable as many as we feel we can trust to do just this, rather than relegating them to some more limited packaging area just because we don't want to be personally responsible for the package. -- 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: Proposing a New App Developer Upload Process
the package before they can do the next submission. The uploader would either be an Ubuntu developer (through the main archive) or an app developer (through extras, via MyApps). This would not only benefit the app developer process, but also fix the existing issue in the regular Ubuntu upload process. To avoid conflicts of interest, I suggest that agreeing that the content of the repository to be populated through MyApps is to be treated as part of Ubuntu is a prerequisite: otherwise there is too much potential for those Ubuntu Developers who have decided to entirely ignore the presence of a third-party external repository called extras to complain that their upload is unreasonably blocked, and no sensible conflict resolution path due to the lack of a common authority other than sabdfl. * Namespace ownership: even with conflict checking there is the issue of who gets to own a particular file name or namespace. E.g. would Mad Feathered Creatures (/usr/bin/birds, from Extras) have priority in owning the binary's name if it had been submitted before Jolly Flying Animals (also /usr/bin/birds, from Universe)? I think if we want to make apps first-class citizens, even if not part of the distro, a simple suggestion would just be to do it on a first-come-first-serve basis. Blindly allowing first-come-first-serve is likely to be fairly annoying (see the discussion about node), rather we ought generally allow developers to use any unclaimed name, and encourage collaborative dispute resolution for conflicts, with a clearly identified authority enabled to take decision in cases where such collaborative resolution is unable to reach a solution acceptable to the parties concerned. Finally, I believe we do need to provision for those cases, but my understanding is that the potential amount of occurrences would be rather low. So do you think they justify additional Engineering work, or rather they could be dealt manually on a case-by-case basis? If we're talking about hundreds of applications, yes the potential for conflict is low. If we're talking about hundreds of thousands of applications, we should expect lots of conflicts. It seems better to take the time now to determine sensible policy, and begin to develop tools that implement that policy, rather than attempting to generate ad-hoc policy based on exceptions as they are discovered: any specific case surely has merits and demerits that may weigh the decision in such a way that we end up creating precedent that makes it hard to decide the other way for the next specific case that apparently would encounter the same policy. Of course, there are surely many sorts of conflict that we have yet to understand, so we ought take care to ensure that we have exception processing built into all the policies we create surrounding this, with facility for the exceptions to be handled in a way that does not force the creation of precedent that may harden into policy later, but rather specifically endorses the discussion of the policy issue independently of the processing of the package which demonstrated the exception. -- 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: Proposing a New App Developer Upload Process
Scott Kitterman wrote: On Thursday, September 06, 2012 04:14:40 AM Emmet Hikory wrote: To avoid conflicts of interest, I suggest that agreeing that the content of the repository to be populated through MyApps is to be treated as part of Ubuntu is a prerequisite: otherwise there is too much potential for those Ubuntu Developers who have decided to entirely ignore the presence of a third-party external repository called extras to complain that their upload is unreasonably blocked, and no sensible conflict resolution path due to the lack of a common authority other than sabdfl. That's not the only way to solve the procedural problem. It's been established that the Ubuntu technical board has the authority to set policy for the Canonical Partner archive. I have assumed that they do for extras as well. If they don't, that can be fixed without redefining what is part of Ubuntu and what is external to it but related (for those unfamiliar, Partner is served from a different archive (archive.canonical.com) and not formally part of Ubuntu). Ah, if the partner precedent is extensible also to extras (and it may well be given that the ARB has often referred to the Tech Board to take decisions), then that also satisfies the prerequisite, so that in the event of conflict, there is a means to request external resolution (either from the Tech Board, or, if this becomes a significant burden, from some delegated authority), which we might reasonably expect to be binding for Ubuntu Developers. Independently of the conflict resolution model, I still don't understand why we would need to consider such a collection of software external, beyond the historical precedent: is there a reason we want to prevent an interested Ubuntu Developer from fixing a bug in one of these packages? Do we feel that having two clearly documented competing different processes for the inclusion of software will help our users to be able to run the software they prefer? Do we want to prevent upstream developers from being able to maintain their software as part of Ubuntu? Should flavours be restricted from seeding packages submitted by the original developers unless they are willing to override the upstream submission? Yes, there are trust issues, especially if the submission is the first time we encounter some developer, but these can be handled by limiting what their software is permitted to do, without necessarily resorting to banishing the software from Ubuntu, and doing so in such a way that also delivers it to users to that later inclusion in Ubuntu may require even more discussion and coordination than has historically been required, rather than just a shift between different parts of Ubuntu as the necessary trust is established. FWIW, I think it's entirely appropriate for Ubuntu developers to not be overly worried about third party repositories. Any solution that requires them to be concerned will drive Ubuntu to a forked namespace with Debian and that will be a fundamental change in the way the distribution works that I don't think we want. My apologies if I created this impression: while I agree that we should impose no requirement that Ubuntu Developers be aware of the content of arbitrary third-party repositories, I believe it is in our interest to both have a clear means in place to resolve potential conflicts resulting from those third-party repositories we have agreed to present to users as potential defaults, and to follow namespace claims for what we might expect to be promoted as the way to request that software be made available to our users by the developers of that software. Of course, if the inclusion requirements for such a third-party repository are such that it prevents any namespace claims, then there is no need to be concerned, but from the discussion so far, I don't believe we will reach this during the quantal cycle. -- 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: Proposing a New App Developer Upload Process
Michael Hall wrote:
On 09/05/2012 02:08 PM, Emmet Hikory wrote:
Regardless of our final decision with regard to the implementation
limiting the impact on users of potentially malicious automatically
reviewed applications, I think we ought continue to make efforts so
that our tools support /opt properly. There are many existing popular
and successful free and commercial applications using /opt today for
other unices, and we can only benefit by reducing the porting effort
for this software to Ubuntu.
It's important to remember that when we say support /opt/ properly
what we really mean is support /opt/extras.ubuntu.com/* properly. We
aren't just using /opt/ as an install prefix, we making a different
install prefix for every single application, and that means that every
tool is going to need to consider every install prefix for every
application that might be installed.
Actually, in the above context, I mean to add support for /opt/foo,
where foo represents both arbitrary values and arbitrary levels of
nesting. This can easily be used to support /opt/e.u.c/bar/, but also
allows the use of /opt/getdeb.net/baz or /opt/autodesk.com/autocad/,
or any other arbitrarily identified third-party install location that
some software distributor wants to present to their users.
In terms of runtime tool support, rather than attempting to identify
all possible values of foo in applications that perform discovery, we
would do better to either investigate, improve, and use tools like
xdg-icon-resource to manage third-party application support, allow such
packages to add paths to some consolidated virtual filesystem via
some well-defined API, or other similar solution. (Yes, this is another
potential source of namespace collisions, but one separated from the
base filesystem, and thereby in letter (if perhaps not entirely in
spirit), less likely to result in debian policy violations.
But at the same time we're not currently making those app-specific
install prefixes actual alternatives to /usr/, they don't contain
/opt/extras.ubuntu.com/{appname}/share/applications/{appname}.desktop,
or /opt/extras.ubuntu.com/{appname}/share/pixmaps/{appname}.png
Right, which I would argue is an incomplete implementation of the
FHS-compliant use of the /opt hierarchy. I consider our incomplete
adoption and support of this to be a set of bugs (although I make no
claim that these are important or even significant bugs, depending on
our final determination on the implementation of application insulation).
So even if we did make all of our tools use $XDG_DATA_DIRS, and we did
include every installed Extras app in $XDG_DATA_DIRS, they still
wouldn't work because we're not making those directories behave like an
XDG_DATA_DIR should.
If we took the first two steps, I do not understand why we would not
then take the third, and I certainly don't understand why our failure to
take the third should be interpreted as a failure of the proposition,
rather than a failure of our resolve. There do exist bugs for which the
simple use of XDG_DATA_DIRS is insufficient, the identification and
solution to which may cause us to decide that we do not wish to include
the restriction to /opt in our application insulation, but if we do
decide to use /opt as part of our solution, we should by all means expect
that applications built with an install path including /opt will not
require different configuration of the content, simply as a result of
the install location. ${INSTALL_PATH}/share/quux should have the same
content in both situations, such that, for example, we may expect that
/opt/extras.ubuntu.com/feathered-friends/share/applications/ would
contain .desktop files that could be selectively processed by any
compliant xdg-menu implementation, and, similarly, .../icons/ would
contain either bitmap icons in common formats or compliant themes
(or partial themes) to support those .desktop files.
--
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: Proposing a New App Developer Upload Process
Scott Kitterman wrote: On Thursday, September 06, 2012 05:05:41 AM Emmet Hikory wrote: Independently of the conflict resolution model, I still don't understand why we would need to consider such a collection of software external, beyond the historical precedent: is there a reason we want to prevent an interested Ubuntu Developer from fixing a bug in one of these packages? Do we feel that having two clearly documented competing different processes for the inclusion of software will help our users to be able to run the software they prefer? Do we want to prevent upstream developers from being able to maintain their software as part of Ubuntu? Should flavours be restricted from seeding packages submitted by the original developers unless they are willing to override the upstream submission? This alternate submission model will have it's own tools, processes and procedures. I doubt that all Ubuntu developers will be sufficiently aware of these that the ability to upload into the alternate process should be allowed by default. While I can accept this argument in terms of Ubuntu Developer access to insulated packages and conversely for access by developers of insulated packages to the Ubuntu archive, I believe you to be unnecessarily conflating separable concepts by claiming it to be true for [t]his alternate submission model. I would hope firstly that we don't end up arbitrarily rejecting applications submitted through MyApps simply because they should instead be submitted as system packages, and secondly that we could provide sufficient education to our developers of the the nature and restrictions of some collection of insulated software which we consider to be part of Ubuntu, but not (or perhaps not yet) given the human review required to be uninsulated, that it becomes safe to apply our regular upload permissions model. If we do continue to consider it an external third-party repository, albeit one we permit to be enabled by default during installation, then I suggest we should take extra care to make sure that we have a well-discussed mechanism to adopt these packages into the distribution itself (whether insulated or not), as some of them may be ideal for seeding by some flavour, and we most definitely do not want to create anything that could give the impression that we are only willing to grant developers this sort of access for applications that we believe to be unsuitable or unusable by default. It does raise an interesting question about the need for a group of extras 'gardeners' (in the same sense MOTU are Ubuntu archive 'gardeners'). Outside the ARB we don't have such a thing now, AFAIK, and we might want to get such a group if there are people interested. Is this something the ARB could do independently, delegating upload rights to extras to some group of interested folk who might volunteer to assist upstream developers keep their applications well groomed, or would it also require the involvement of other approval bodies? If the former, I would suggest that the ARB consider such a thing (and policies surrounding it), and make a call for volunteers. If the latter, I'd suggest that anyone with interest in doing such a thing draft some guidelines for how it would work, garner the review and approval of the ARB, and help get it approved by whatever necessary hierarchy of authorities - even if we initially have no members of such a group beyond the ARB, if we expect to scale to very large numbers of applications, we will likely need more available hands to assist with the various exception cases and I suspect we would all be happier with random folk trusted by the ARB being granted these rights than with the members of the ARB feeling overwhelmed with such administrative work to the degree that they don't feel they have time for accepting new packages or overseeing transitions between releases. -- 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: Proposing a New App Developer Upload Process
Michael Terry wrote: I imagine the easiest way to avoid this is to namespace the package names too. (Though with namespaced packages, the user can end up in a weird situation if the Extras package foo does find its way into Debian and Ubuntu quantal. Then, they really do want the foo package from Debian but are left with the non-maintained extras-foo from precise.) One way to work around these cases would be to have a transitional extras-foo in quantal-extras, which Depends: on foo, so that upgrading users would migrate from extras-foo to foo during the upgrade process. At some point the extras-foo package ought be removed from the system, but this is true for all the historical transitional packages, and so better handled as part of a general solution for that class of problem. -- 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: Proposing a New App Developer Upload Process
Daniel Holbach wrote: On 04.09.2012 15:28, Emmet Hikory wrote: The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. The fairest solution to this problem would be to turn on a conflict-check-before-publish for all parts of the archive. This would help us find these (and pre-existing) issues immediately and resolve them amongst the maintainers and upstreams. Completely independently of this discussion, this is a good idea, although we probably ought have the system respect Breaks, Conflicts, and Replaces, or we'll end up with lots of false positives. Mind you, given the vast number of reports from conflictchecker, it may be that we would want to put up a review system for some time to clean up the existing issues prior to actually blocking publication. That said, while I agree that such issues can be sorted between the various developers involved (perhaps easily, perhaps less so (see node)), I am much more concerned about the effect on users. Assume I'm using Ubuntu Desktop, and I add an extras application to the Dock. Now assume there is a namespace conflict for that application, which is resolved by the extras application taking a new name. Depending on what I happened to install on upgrade (as a new dependency of another installed package), my Dock entry may behave entirely differently. More generally, this may happen for startup programs, so that I would upgrade, reboot, and end up running something completely unexpected automatically, and I may not even notice if the automatic execution doesn't load a window, and just believe my upgrade broke (and potentially end up finding my computer slower, or behaving oddly, depending on what the new program happened to do). The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. Much of this can be avoided by allowing a common location for extras files, for example /opt/extras/bin, /opt/extras/applications, /opt/extras/pixmaps, etc. If these locations are only permitted to contain namespace-protected symlinks, then it can be a matter of adding one or two lines to the 8-12 tools that perform these sorts of discoveries. No, this isn't an ideal solution, but it significantly limits the effort required to support a separate namespace. For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). -- 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: Proposing a New App Developer Upload Process
Michael Hall wrote: We add an Extras package foo in precise. Then in quantal, we sync in some new, unrelated package foo from Debian that happens to share the same name. Now users that installed foo in precise that upgrade to quantal will be replacing their foo package with a completely unrelated one. It's possible for me to upload a package to Universe in Precise's development phase, then for an unrelated package by the same name to be in Debian's archives when we do the Quantal sync. How is this currently handled? The package would be listed as manual-merge, and the developer who looked at the merge would be expected to notice that these were not the same package at all, potentially raising the issue on ubuntu-motu@ for discussion, or potentially resolving the issue with interested parties in some other way. I don't remember this happening, although we've had a few cases where packages added to Ubuntu were later added to Debian with different names, in which cases we carried a transitional dummy binary package and associated patch until the next LTS. There have been a couple cases where we introduced filesystem conflicts as a result of new-in-Ubuntu packages: these were generally resolved by lengthy discussions with the relevant Debian maintainers and upstreams, with the end result that both previously conflicting packages were added to Debian, and the conflicts resolved there (I believe one of these transitions required two Debian releases, so such a process may not be fast, but it worked before). -- 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: Proposing a New App Developer Upload Process
the random apt repos, and work with REVU, I feel fairly strongly that we ought create an implementation that closely integrates with exsting Debian tools and avoids as many potential sources of conflict as possible. If we are to have a high-throughput mostly automated mechanism for new packages to be added, we need to be sure that we have not created too many bottlenecks relying on human discussion, whether this be too high a reviewer overhead, a need to coordinate yet another namespace conflict resolution forum, or anything else. Based on this belief, while we might have any arbitrary process by which applications are submitted for review, the only reason I can see for treating the packages as any different than any other unseeded package is either some technical limitation or if we somehow felt that we had different levels of trust for packages in one place or another (as reflected by our trust in the reviewers, presumably). The more effort we spend to create a special and different class of applications, the greater the chance we have created a division in the self-perceived identities of our various developers where none need exist. Of course, this may not be considered safe (see all the sandboxing discussion in the spec), but I believe we'd do better to help those who are developing applications follow a model that generates software that we would be happy to welcome as regular system software than to encourage those who might need greater system access to find ways to work around whatever limitations we might attempt to put in place. If we can use the same front-end to the application developers for *both* types of applications, we reduce both confusion and dissention, and likely find that our implementation need have fewer loopholes, as there is a means to easily move software from the restricted facility to a more regular facility, with full filesytem access, no network restrictions, etc. which we may use whenever we find a package that might otherwise require an extension to the facilities available. -- 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: Proposing a New App Developer Upload Process
Steve Langasek wrote:
On Tue, Sep 04, 2012 at 05:20:47PM -0400, Michael Hall wrote:
It's possible that namespacing within /usr - for instance,
requiring each subdirectory and binary name to be prefixed with
'extras.' - would give better results with regards to the upstream
build systems, I'm not sure. But if we are going to try to do
namespacing of extras packages to avoid the need for coordination,
we definitely would need improved package helpers that support
namespacing of packages (i.e., debhelper support).
Would it be reasonable for MyApps to add a package name prefix to the
submitted package, rather than requiring the developer to do so?
MyApps will already be modifying the submitted package to include the
generator AppArmor profile.
So, for example, if I submit quickly-gtk as a source package to
MyApps, it would convert it to extras-quickly-gtk, add the AppArmor
profile, and re-build the source package before submitting it to the
PPA/buildds.
For package renaming that seems easy enough to do, but if we're worried
about file conflicts, dynamically prefixing filenames when building the
package is going to have an even worse impact on the upstream code than
changing directories does.
Changing the base filename indeed generates more complicated issues,
not only in terms of collisions, but also in terms of coordination between
code and data (e.g. code expects to find ${CONFIG_DIR}/package and fails
to initialise properly with only ${CONFIG_DIR}/extras-package.
However, if we consider renaming to apply to the entire path, rather
than the bare filename, this becomes considerably less of an issue. If
MyApps were to call tooling that changed the default installation location
for files while preserving bare filenames, then there is less potential
for conflict. The standard mechanism for this is to place the non-system
files in per-package namespaced directories in /opt.
For the convenience of developers, this should likely be implemented
through debhelper support, so that if one specifies `dh --with-extras`
one gets the alternate installation prefix, as well as the apparmor
profile, etc.
--
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: Proposing a New App Developer Upload Process
Michael Hall wrote:
.desktop files, .service files (for dbus), .lens and .scope files (for
Unity) all needed to be changed to point to executables or images in
/opt/extra.ubuntu.com/${appname}/ when being packaged for Extras. Unity
APIs that require a .desktop or image file name had to use absolute
paths to the files in /opt/extras.ubuntu.com/{$appname}. These all
required changes to the app's source in order to support the
installation under /opt/.
The XDG menu specification provides very wide flexibility in where
and how .desktop files are stored, and all the compliant implementations
of which I am aware use a configuration file to determine where to find
the files, and which to include where. Similarly, dbus service files
may be placed in any of ${XDG_DATA_DIRS}/share/dbus-1/services. Icons
(for use in .desktop files) may be stored in ${XDG_DATA_DIRS}/icons. I
know less about .lens and .scope files, but presume that there would be
advantages beyond this discussion to have them check a runtime-determined
set of locations.
Where this gets extra annoying is the expectation that things
are found in application-specific locations: while it is possible
to add /opt/${PACKAGE}/applications to the menu search path for
each package, this quickly becomes unwieldy. While it reduces the
separation between applications to some degree, use of a shared
namespace for this sort of file (e.g. /opt/extras.ubuntu.com/applications
or /opt/extras.ubuntu.com/share/dbus-1/services) reduces the issue to
a simple configuration change and a symlink from the shared location
to the package namespace.
The disadvantage of doing it this way is that it imposes a requirement
for all extras packages to share a single namespace for these resources
(desktop files, icon names, dbus services, etc.), although on a given system
we would likely wish to impose that anyway (two packages providing the same
apparent program name, or the same apparent dbus service may lead to many
more complicated issues in terms of user confusion than fienames).
--
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: Proposing a New App Developer Upload Process
Steve Langasek wrote: On Wednesday, September 05, 2012 12:11:18 AM Emmet Hikory wrote: For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). There's a general sense that the Ubuntu archive can't scale out to the degree it needs to in order to take on the next challenges for the platform. While Debian packaging isn't hard for you or me, and while it's definitely gotten much easier over the past 4 years or so, it's still not so easy that we blindly trust outside contributors to get the packaging right without review by an Ubuntu developer. We do not have an infinite supply of Ubuntu developers to do this review. Should the set of software available to Ubuntu users through apt be limited to only that software that Ubuntu developers (or Debian maintainers) have time and interest to take care of directly? Or should users have better (not perfect, but better) ways to install software that's not gotten the attention of the elite inner circle? This needn't be an XOR model. Taking as given that our application acceptance model has not only failed to scale, but has actually become less efficient over the past couple years (roughly lucid through precise), and that we *must* come up with a way to ensure that our users can easily get new software in a safe manner (as opposed to use of random PPAs, arbitrary third-party archives, random downloads and local compilation attempts, etc.), we need not decide that this cannot interoperate with the existing processes by which we add new applications, nor that the existing processes are now inflexible to the point of no utility. Historically, the limitation has often been insufficient reviewers, and automation is a wonderful way to remove this, especially in combination with sufficient insulation of the application from the rest of the system. That said, we oughtn't force *all* applications to be so limited: there are many tools that we would welcome as regular packages, assuming we had reviewed them. Of course, unless we take care to ensure that, from the perspective of the application developer, the process for having the package included is very similar (and most importantly has the same widely-publicised entry point), we only create division: random arguments about the best way to submit packages in places we fail to see, people deciding not to submit because they are unsure, or feeling rejected by one process and not wanting to start another. So, if we encourage the development of portable applications, and create automation that can accept these packages, perform (limited) review, and wrap them in sufficient insulation before presenting them to users, we should be able to almost completely remove the requirement for human review (although there are complexities that may require a lightweight gatekeeper check to avoid repititions of the hotbabe discussions or similar). That said, if an application fails the automated insulation testing or requires deeper integration with the system, we should make it immediately available to human reviewers who would be empowered to accept the submission as a regular system package. For those applications requiring insulation, the use of the extras repository is likely the simplest route, although I'd personally prefer that if we do this we either claim extras to be part of Ubuntu (and place it under similar trust metrics), or create a new repository that we then consider part of Ubuntu. For those applications requiring human review, I don't see any reason we shouldn't strive for them to be included as part of the regular repositories, and suspect backports is the appropriate way to do this (although this may require some streamlining of the backports process for *entirely new* packages, if we find that this is a blocking factor). Where this becomes complicated in when we think about trust: who do we trust to perform the human reviews? Do we trust application developers who received human review to update their packages responsibly? If we wish to scale, I believe that we need to answer the first with Ubuntu Developers: if we have people
[Bug 1041765] Re: package libwildmidi-config 0.2.3.4-2.1 failed to install/upgrade: Versuche, »/etc/wildmidi/wildmidi.cfg« zu überschreiben, welches auch in Paket libwildmidi0 0.2.2-3~ppa1~lucid1 ist
Thanks for catching this. The Breaks and Replaces need to be extended. I'll test a patch right away. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1041765 Title: package libwildmidi-config 0.2.3.4-2.1 failed to install/upgrade: Versuche, »/etc/wildmidi/wildmidi.cfg« zu überschreiben, welches auch in Paket libwildmidi0 0.2.2-3~ppa1~lucid1 ist To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wildmidi/+bug/1041765/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1041765] Re: package libwildmidi-config 0.2.3.4-2.1 failed to install/upgrade: Versuche, »/etc/wildmidi/wildmidi.cfg« zu überschreiben, welches auch in Paket libwildmidi0 0.2.2-3~ppa1~lucid1 ist
Unfortunately, I'm having trouble reproducing the error: while I believe that the issue is that libwildmidi-config should both Breaks and Replaces libwildmidi0 as well as libwildmidi1, I haven't been able to reproduce it, and the PPA versioning makes me wonder if there is something different about the original installed package. If anyone is able to reproduce this in a lucid-precise upgrade using standard packages, please share the procedure used for reproduction. Alternately, if it is possible to identify the PPA from which the problematic package was produced, I may be able to work with the PPA owner to resolve the issue. ** Changed in: wildmidi (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1041765 Title: package libwildmidi-config 0.2.3.4-2.1 failed to install/upgrade: Versuche, »/etc/wildmidi/wildmidi.cfg« zu überschreiben, welches auch in Paket libwildmidi0 0.2.2-3~ppa1~lucid1 ist To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wildmidi/+bug/1041765/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Network Manager dependencies
Dale Amon wrote: On Wed, Aug 22, 2012 at 07:40:58PM -0500, Jordon Bedwell wrote: prefer to stay away from it, preference perhaps? But with preference comes the problem that NM relies on wpasupplicant and a couple of other wireless tools that we would absolutely never need on a server, unless we are crazy or there is some one-off sysadmin who has some crazy ideas. I agree for the most part... although there are appliances that use mobile phone connection as a sysadmin emergency back door to get at servers if the host facility backbone is down. Consider also the case of mobile servers, which have started to become available in retail: current devices are things like WiFi-4G bridge routers, portable WiFi NAS devices, etc. We very much shouldn't limit our conception of what makes sense on a server to only that set of things that happens to make sense for large devices in racks in a data centre. That said, ifupdown can currently handle just about any type of network connection the administrator can imagine, including complexities like autofailover to VPN over PAN, or arbitrary ESSID WiFi activated by USB key or local presence of a bluetooth device. Where Network Manager shines is in the close userspace coordination of the selection and activation of network connections, considerably reducing the advance configuration necessary to adjust to a wide variety of network options, and allowing users to immediately begin to use hotplug network devices. So, rather than debating whether a server should be using Network Manager or ifupdown based on the networking technologies that one might imagine to be used for some arbitrary hardware in some arbitrary environment, we should instead consider how we expect the users of the system to interact with the system we use to define and configure the networks. Devices with a single user running interactive processes will likely be better served by Network Manager (or similar tools), as the user will want to be able to select from available networking options at will and receive notifications about the current state of the network. Devices with few interactive processes will likely be better served by ifupdown, as the administrator will want to configure the networking options once, and allow users to attach to network services exposed once the network comes up. Of course, as the tools continue to advance, some other selection may make sense in the future, but even then I think we should continue to debate the tools in terms of how the system is expected to be used, rather than what hardware is present, or into which environment we expect that hardware to be placed. -- Emmet HIKORY -- 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: [Bug 1029767] [NEW] help button in preferences points to invalid page
Len Ovens wrote: I've switched this over from nautilus to ubuntustudio-meta because we are missing the package that makes this work (ubuntu-docs). However, I tried installing that package and when selecting help from nautilus it does show nautilus docs but at the top it has a desktop button that goes to an all unity page. I don't know which is better, no docs or extra wrong docs. Obviously the best thing would be to have a ubuntustudio-docs package, but that would require upkeep... more than our average :) A script that takes the ubuntu-docs pkg and auto creates a package with just what we need in it would be nice, but I don't know how doable. Perhaps a very minimal ubuntustudio-docs package would work for this, including only those files necessary to launch help, with pointers from the default page to the workflow documentation on the wiki? This would also become a good place for us to document the essential ideas of the workflows and special menus, etc., which might otherwise be confusing for users coming from some backgrounds. Once written, we ought not need to change that much, except where there are signficant changes to the basic environment (e.g. changing default desktop environment), or where there are changes in the underlying software (e.g. new location for default help file): I wouldn't expect this to mean more than one or two changes per cycle, until someone gets sufficiently excited about our documentation to maintain it more closely, with more content, etc. -- Emmet HIKORY -- 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: live video switching (was: Linux Tools for Serious Photographers)
Len Ovens wrote: Took a while to find any docs for it... in the doc directory of the src package. freemix is designed to do live showing switching of videos stored as file on the computer like a VJ. I don't know if it can connect to a gstream opened by another app or not. But it is not designed for it. It is only available as a src package right now. Ah, indeed: the demo I saw must have either used named pipes or been a derivative of the sources currently on launchpad (engine.py would need extension to directly access non-file sources, although it's all gstreamer). Packaging this source is fairly trivial, if it's considered particularly useful: it's a clean setup.py and fairly sensibly licensed. However, I tried looking up VJ in synaptic and that spit out LiVES, already in the repos. In it's features page it says Support for live firewire cameras and TV cards. I don't know that we should ship it by default, but extra sw yes. Unless someone can document a sensible video processing workflow (VJ, broadcasting, etc.) which is known to be well-done with it, I'm not sure it ought get any more or less attention than any of the other audio/video tools in the archive that aren't part of known workflows: while there's *lots* of software in the archive, and all of it is presumably useful and used by some folk, the more that we attempt to call supported (even as extra sw), the less I would expect we could refine the experience to be ideal for accomplishing real tasks. -- Emmet HIKORY -- 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: Another idea for comments
Len Ovens wrote: However, my concern is that installing from a live dvd/cd has some interesting effects on depends. These effects are not very noticeable for most flavours of ubuntu because they have one set of software that they install not 5 or 6. The install depends on everything, that is in our case where in the past graphics items would have depended on the graphics meta with the alt install, with the live ubiquity install those apps also depend on the install itself. This means, if the user chooses to uninstall one of these metas, the meta itself is uninstalled but not the apps that should only be dependants of that meta. This has meant that some users have uninstalled the apps manually not realizing that one or two of the apps might also be a depend for another package (like a font for desktop in the case that started me looking at this). These users end up with a broken system. My understanding is that packages that are installed are marked as automatically installed unless either 1) the user specifically chose to install the package, 2) the package is a dependency or recommendation of a package in Section:metapacakges, or 3) the package is a metapackage selected at install time. Removing the dependencies/recommendations of a metapackage safely requires using apt-mark to indicate that these are all automatically installed, and using apt-get autoremove to select the subset of automatically installed packages it is safe to remove. Documenting this is *hard* (there are manpages, etc., but they aren't considered very accessible to some hypothetical average user who doesn't want to understand the details of the packaging system). The reason that packages that are dependencies of metapackages default to being marked intentionally installed is that there were persistent complaints in the past that uninstalling package X (which the user never used nor wanted to use) would uninstall metapackage Y (because of a dependency relation), which would then cause half the system to uninstall (because it was the flavour-defining metapackage). If there is sufficient interest, it should be possible to write a tool that allows for clean install/remove of each workflow, where install means find out which packages are missing, and install them and their dependencies and remove means find out which packages are not needed if only this workflow is missing, and remove them (and only the unneeded ones). Separately from the above, as part of my catch-up reading, I thought there were some threads about merging the live and alternate images. While I Yikes! My first thought is that would greatly increase our ISO size (I was thinking double) but it would allow a better install. We do have one of the biggest ISOs and doubling it does not leave much room on a DVD... but, I think the future of things is to install from usb stick anyway. DVD drives are less often included as part of the hardware already, most new home video systems also accept USB sticks... I think it is only a matter of time before home movies are distributed on a read only memory stick (or maybe even with a limited number of plays). Anyway, it will be interesting to see where this goes. I think there was talk about finding ways to *not* double the size, rather providing both interfaces for the install from the same set of source data. Although I don't know the details of the implementation, all the possibilities I can imagine would imply that there would be more means by which greater flexibility could be implemented for the Ubuntu Studio install experience. -- Emmet HIKORY -- 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: ubuntustudio icons
Ralf Mardorf wrote: On Thu, 2012-07-26 at 00:00 +0900, Emmet Hikory wrote: `convert foo.png foo.svg` This is possible? For me it's important, since drawing an icon on a paper and than scanning it, is less work. Yes, but doing it this way avoids all benefits associated with the vector format. Some of the algorithms available have simple shape matching features, but in all likelihood every artifact, pixellation, dither effect, etc. is going to be assigned its own vector, so that the result is less scalable than the original file. The point of retracing the work is so that one has the original natural shapes stored as vectors, independent of the rendering: this allows the shape to be rendered at arbitrary scale and look reasonable. Automatic conversion may initially appear to be less work, but it likely generates a requirement to retouch all the scaled images, which tends to grow to be more work over time. * a single .png file can create multiple .png files during installation (greatly reducing size requirements) (blurred edges on lines are the most obvious of the possible effects). Regarding to the quality, if the original png/jpg is around 900x900 and you use cubic to scale and for the png/jpg best quality, such effects are reduced to a minimum, less noticeable. Sure, and if you choose a target resolution that is an absolute power of 2 of the starting resolution and only work in reduction, most of the lines even look crisp. With vector representation, one can scale indefintely with zero loss due to scaling: one only sees irregularities when either the target format cannot support the number of elements (e.g. drawing a chess set with grooves between squares at 16x16), or there are limitations of the creation medium (e.g. scaling a drawing done at 45x60 cm to A0). To put it differently, a vector representation (such as SVG) attempts to capture the individual strokes, and then renders them to any target, either specific targets (using imagemagick or another tool), or arbitrary targets (such as a 5x5 cm screen region). As such, when generating bitmaps from vector represenations, sufficient information is available to ensure that the artist's intent is preserved regarding hard or soft edges, smooth or jagged curves, etc. A bitmap representation only stores the result of the drawing for a specific size and colour depth, so when scaling, one must estimate the intent of the artist, and compromise accurate represenation of the relative size of elements against the quality of the appearance of the elements. To see the effect of this yourself, take a look through the icons already installed on your computer: try scaling them to various sizes (including upscaling to e.g. 800x800 or so). I suspect you'll find that vector files (from SVG) survive better than bitmaps. -- Emmet HIKORY -- 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: ubuntustudio icons
Len Ovens wrote: On Tue, July 24, 2012 7:56 am, Shubham Mishra wrote: And a SVG is really needed for the icons? Yes. The reason icons are made in vectors, is because of its scalability. You can export and SVG as a bitmap in any resolution that you want. Can I do this from the command line? How? `convert foo.svg -background none -resize 64x64 foo.png` -- Emmet HIKORY -- 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: ubuntustudio icons
Ralf Mardorf wrote: On Wed, 2012-07-25 at 02:38 +0900, Emmet Hikory wrote: convert foo.svg A dummy question. convert is from the package imagemagick? At least I googled this. Apologies, I hadn't realised there were multiple `convert`s floating around: the Imagemagick one is indeed the one I intended to suggest. -- Emmet HIKORY -- 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
[Bug 1007729] Re: Unable to edit files created with prior versions of audacity with ubuntu 12.04 LTS: keyboard and mouse are inactive
** Summary changed: - avec ubuntu 12.04 LTS, je ne peux plus modifier mes fichiers audacity enregistrés avec une version antérieure: clavier et souris sont inavtifs + Unable to edit files created with prior versions of audacity with ubuntu 12.04 LTS: keyboard and mouse are inactive -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1007729 Title: Unable to edit files created with prior versions of audacity with ubuntu 12.04 LTS: keyboard and mouse are inactive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1007729/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1007729] Re: Unable to edit files created with prior versions of audacity with ubuntu 12.04 LTS: keyboard and mouse are inactive
** Description changed: J'ai des fichiers Audacity enregistrés avec une précédente version de Ubuntu. Avec Ubuntu 12.04 LTS, je peux ouvrir ces fichiers Audacity: mais je ne peux rien faire ni avec la souris ni avec le clavier, ils ne sont pas reconnus par audacity. + + I have created some Audacity files with a prior version of Ubuntu. With + Ubuntu 12.04 LTS, I can open these files, but I am unable to use the + mouse or keyboard: they are not recognised by Audacity. Si j'ouvre un nouveau fichier dans Audacity, que j'importe un fichier audio (wav) et que je laisse ouvert ce nouveau fichier, je peux ouvrir un des anciens fichiers: il s'ouvre dans une autre fenêtre et je peux alors travailler dedans. + + If I open a new file in Audacity, into which I import an audio file + (wav) and which I let open this new file, I may open an older file: it + opens in another window, and I may work with these files. + + [Someone with greater facility in French is encouraged to correct the + gloss above, and remove the original entry.] ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: audacity 2.0.0-1 ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18 Uname: Linux 3.2.0-25-generic i686 AlsaCards: - 0 [CMI8738]: CMI8738-MC6 - C-Media CMI8738 -C-Media CMI8738 (model 55) at 0xc800, irq 19 + 0 [CMI8738]: CMI8738-MC6 - C-Media CMI8738 + C-Media CMI8738 (model 55) at 0xc800, irq 19 ApportVersion: 2.0.1-0ubuntu8 Architecture: i386 Date: Sat Jun 2 08:12:10 2012 InstallationMedia: Ubuntu 11.10 Oneiric - Build i386 LIVE Binary 20111013-11:02 SourcePackage: audacity UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1007729 Title: Unable to edit files created with prior versions of audacity with ubuntu 12.04 LTS: keyboard and mouse are inactive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audacity/+bug/1007729/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other
** Changed in: dnsmasq (Ubuntu) Assignee: Emmet Hikory (persia) = (unassigned) ** Changed in: libvirt (Ubuntu) Assignee: Emmet Hikory (persia) = (unassigned) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/231060 Title: packages dnsmasq and libvirt-bin conflict with each other To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/231060/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other
@Thomas, 959037 means that this issue potentially exists for everyone, rather than just those few folk with specialised needs (mine having been running both a virtualisation host and a tftp server on the same machine). The main issue being the racy nature of running multiple greedy dnsmasq configurations. There's likely a right way to do it, but it's tricky, especially as most of the potential solutions significantly complicate many of the current user-oriented use cases for dnsmasq. That said, I'm probably not the best person to own this bug any longer, having gotten stalled with the project that required tftp a couple years ago, and so not really trying to solve this. I have another project with TFTP coming up soon, and an running libvirt on the laptop I'd like to use as a server: if I happen to find a generic config that works, I'll post a patch (probably based on the plan outlined above, unless the changes to the code in the meantime are sufficiently large to make that no longer workable). -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/231060 Title: packages dnsmasq and libvirt-bin conflict with each other To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/231060/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other
** Changed in: dnsmasq (Ubuntu) Assignee: Emmet Hikory (persia) = (unassigned) ** Changed in: libvirt (Ubuntu) Assignee: Emmet Hikory (persia) = (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/231060 Title: packages dnsmasq and libvirt-bin conflict with each other To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/231060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other
@Thomas, 959037 means that this issue potentially exists for everyone, rather than just those few folk with specialised needs (mine having been running both a virtualisation host and a tftp server on the same machine). The main issue being the racy nature of running multiple greedy dnsmasq configurations. There's likely a right way to do it, but it's tricky, especially as most of the potential solutions significantly complicate many of the current user-oriented use cases for dnsmasq. That said, I'm probably not the best person to own this bug any longer, having gotten stalled with the project that required tftp a couple years ago, and so not really trying to solve this. I have another project with TFTP coming up soon, and an running libvirt on the laptop I'd like to use as a server: if I happen to find a generic config that works, I'll post a patch (probably based on the plan outlined above, unless the changes to the code in the meantime are sufficiently large to make that no longer workable). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/231060 Title: packages dnsmasq and libvirt-bin conflict with each other To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/231060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 820380] Re: Please sync golang r59 from Debian unstable
Sync ACK: Ubuntu variation is no longer required with closure of Debian bug #634270 (and confirmed in test-build for armel) Additional Debian changelog: golang (1:59-1) unstable; urgency=low * Imported Upstream version 59 * Refresh patches to a new release * Fix FTBFS on ARM (Closes: #634270) * Update version.bash to work with Debian packaging and not hg repository -- Ondřej Surý ond...@debian.org Wed, 03 Aug 2011 17:04:59 +0200 golang (1:58.1-2) unstable; urgency=low * Install golang-doc package by default (Recommends from golang-tools, Depends from golang) -- Ondřej Surý ond...@debian.org Mon, 18 Jul 2011 09:13:43 +0200 ** Package changed: ubuntu = golang (Ubuntu) ** Changed in: golang (Ubuntu) Importance: Undecided = Wishlist ** Changed in: golang (Ubuntu) Status: New = Confirmed ** Summary changed: - Please sync golang r59 from Debian unstable + Please sync golang 1:59-1 (universe) from Debian unstable (main) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/820380 Title: Please sync golang 1:59-1 (universe) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/820380/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 819802] Re: Please refactor plymouth to remove the libdrm2 dependency when text themes are used
The last image I checked was about 100MB, so the DRM implementations represent less than 1%, although anything that can be removed from this is interesting, as 100MB is considered very large when compared to other base rootfs environments made available by other projects (e.g. TLIB). In principle, there's no reason that Core couldn't be built for other architectures: although nobody has yet volunteered to care for the images for other than armel. I'd be opposed to attempting to trim packages on an architecture- specific basis: while there are no current chipsets available that use Intel DRI and armel, there are always discussions surrounding any new SoC design, and Intel has previously produced devices supporting ARM instruction sets. Further, there are devices supporting ARM instruction sets that allow attachment of external bus devices, such as PCIe: while Intel does not currently produce a discrete graphics solution, there have been persistent rumours of such devices for several years. I believe there exists available hardware for all other included DRM implementations for all architectures currently in Ubuntu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/819802 Title: Please refactor plymouth to remove the libdrm2 dependency when text themes are used To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/819802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 819802] [NEW] Please refactor plymouth to remove the libdrm2 dependency when text themes are used
Public bug reported: The Ubuntu Core image contains libdrm2 and various implementations of userspace interfaces for specific DRI modules, which may not match hardware on target systems, especially for users intending not to provide any graphical interface (often including no graphical console). This significantly increases the size of the image, without direct benefit to the user. plymouth should detect when the theme requires the direct rendering interface, and only load the appropriate DRM implementations at that time. The theme packages should depend on any required interfaces, and the plymouth package not require any DRM implementation when using text themes. ** Affects: plymouth (Ubuntu) Importance: Undecided Status: New ** Tags: core ** Tags added: core -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/819802 Title: Please refactor plymouth to remove the libdrm2 dependency when text themes are used To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/819802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 488380] Re: Freepats fails to install on Ubuntu Arm
Tested on a clean install of jaunty (from old-releases) and natty: unreproducible in both cases. I suspect it to be an artifact of the modifications to Ubuntu made in the default SmartQ images. Jaunty and Karmic are now both unsupported (and unsupportable, in the sense that we can't upload changes thereto), and the SmartQ 5 and SmartQ 7 devices cannot run more recent releases (due to the SoC used in the devices), making this unfixable for the reported environment, and unreproducible in more recent environments. Note that the freepats package is currently unchanged in Ubuntu since before Ubuntu supported any ARM processors, and, as Architecture: all, would be uninstallable in many more environments if the data were corrupt in some manner. ** Changed in: freepats (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/488380 Title: Freepats fails to install on Ubuntu Arm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freepats/+bug/488380/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 766024] Re: bochs version 2.4.5-1 failed to build on i386
** Changed in: bochs (Ubuntu Oneiric) Assignee: (unassigned) = Emmet Hikory (persia) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/766024 Title: bochs version 2.4.5-1 failed to build on i386 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bochs/+bug/766024/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 808810] Re: Please publish MLO and u-boot.bin on download page for OMAP netinst
** Branch linked: lp:~persia/debian-installer/publish-omap-spl -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/808810 Title: Please publish MLO and u-boot.bin on download page for OMAP netinst To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/808810/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 808810] [NEW] Please publish MLO and u-boot.bin on download page for OMAP netinst
Public bug reported: For the majority of our OMAP and OMAP4 reference devices, we aren't relying on vendor SPL in flash. As a result, we need to publish the low-level boot tools in order for users to construct their own bootable images. Currently, these are only included in the bundled boot.img files. ** Affects: debian-installer (Ubuntu) Importance: Wishlist Assignee: Emmet Hikory (persia) Status: In Progress ** Changed in: debian-installer (Ubuntu) Status: New = In Progress ** Changed in: debian-installer (Ubuntu) Importance: Undecided = Wishlist ** Changed in: debian-installer (Ubuntu) Assignee: (unassigned) = Emmet Hikory (persia) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/808810 Title: Please publish MLO and u-boot.bin on download page for OMAP netinst To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/808810/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 374113] Re: Easycrypt isn't necessary truecrypt is a very handy tool with a gui
** Also affects: easycrypt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/374113 Title: Easycrypt isn't necessary truecrypt is a very handy tool with a gui To manage notifications about this bug go to: https://bugs.launchpad.net/easycrypt/+bug/374113/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 374113] Re: Easycrypt isn't necessary truecrypt is a very handy tool with a gui
Please remove easycrypt from Oneiric. Rationale: The software has been superceded by Truecrypt's internal GUI The software is apparently unmaintained in Ubuntu (many untriaged crash bugs) The software is not present in Debian, so has no packaging maintenance oversight Upstream (LP:~stevenharperuk) is no longer supporting the package, so there is no code maintenance oversight ** Changed in: easycrypt (Ubuntu) Importance: Undecided = Wishlist ** Changed in: easycrypt (Ubuntu) Status: New = Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/374113 Title: Easycrypt isn't necessary truecrypt is a very handy tool with a gui To manage notifications about this bug go to: https://bugs.launchpad.net/easycrypt/+bug/374113/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 803836] [NEW] Please sync golang 1:57.2-1 from Debian unstable (main)
Public bug reported:
Please sync golang 1:57.2-1 from Debian unstable (main) into Ubuntu
Oneric (universe)
Debian changelog:
golang (1:57.2-1) unstable; urgency=low
* Imported Upstream version 57.2
* More spelling fixes (Closes: #630660)
-- Ond�ej Surý ond...@debian.org Thu, 16 Jun 2011 11:10:58 +0200
golang (1:57.1-4) unstable; urgency=low
* Description update to have proper articles and capitalization
(Closes: #630189)
* Add extended description about Go being experimental and that the
languager can change between releases
-- Ond�ej Surý ond...@debian.org Tue, 14 Jun 2011 21:38:11 +0200
golang (1:57.1-3) unstable; urgency=low
* Fix the Google's Go implementation in extended description
(Closes: #627814)
* Update Vcs-* links
* Install vim ftplugin files into correct directory (Closes: #629844)
-- Ond�ej Surý ond...@debian.org Thu, 09 Jun 2011 10:10:41 +0200
golang (1:57.1-2) unstable; urgency=low
* Bump standards version to 3.9.2
* Capitalize Kate (Closes: #627036)
* Import slightly modified patch to be more clear about $GOPATH
installs for non-root users
* Remove don't install deps patch from goinstall; deprecated by
$GOPATH installs
-- Ond�ej Surý ond...@debian.org Mon, 23 May 2011 11:07:11 +0200
golang (1:57.1-1) unstable; urgency=low
* Add support for dot-minor releases
* Imported Upstream version 57.1
-- Ond�ej Surý ond...@debian.org Mon, 16 May 2011 11:45:53 +0200
golang (1:57-3) unstable; urgency=low
[ Florian Weimer ]
* golang-tools: install gofix binary
[ Ond�ej Surý ]
* Add lintian-overrides for gofix binary
-- Ond�ej Surý ond...@debian.org Sat, 07 May 2011 20:41:58 +0200
golang (1:57-2) unstable; urgency=low
* Remove weekly code from debian/rules
* Add golang meta-package
* Don't create tool chain symlinks twice
* Make debian/rules more generic for simpler sync between weekly
and release branches
-- Ond�ej Surý ond...@debian.org Wed, 04 May 2011 16:48:24 +0200
golang (1:57-1) unstable; urgency=low
* Imported Upstream version r57
* Bumped epoch version to 1, to convert from date based versions
to release number based version
* Allow release to migrate to testing (Closes: #624408)
* Add kate and vim syntax highlighting (Closes: #624544)
* Add -dbg package with debugging symbols
-- Ond�ej Surý ond...@debian.org Wed, 04 May 2011 01:20:07 +0200
golang (2011.04.27-2) unstable; urgency=low
* Fix yet another build failure on kfreebsd (use linux userspace)
-- Ond�ej Surý ond...@debian.org Fri, 29 Apr 2011 16:22:47 +0200
golang (2011.04.27-1) unstable; urgency=low
* Imported Upstream version 2011.04.27
* Update debian/rules to allow pulling weekly upstream releases
* Don't remove RUNPATH from binaries; fixed upstream (golang#1527)
* Set GOHOSTOS and GOHOSTARCH to match dpkg-architecture variables
* Add support for kfreebsd-i386, kfreebsd-amd64, armel and armhf
architectures
+ 006-fix_kfreebsd_build.patch:
- Add GNU/KFreeBSD support by replacing all uname calls by $(GOOS)
+ 007-use_native_dynamic_linker_on_kfreebsd.patch:
- Use native kfreebsd dynamic linker (/lib/ld-*.so.1)
* Add information about available architectures (Closes: #623877)
* Don't strip gotest
* Add Depends: golang-go to golang-tools
* Add better support for armhf
-- Ond�ej Surý ond...@debian.org Thu, 28 Apr 2011 16:14:39 +0200
golang (2011.04.13-1) unstable; urgency=low
[ Florian Weimer ]
* Delete bin directory in clean target
* Enable parallel build
* golang-src: install source files directly
* Use proper symlink targets for architecture-independent toolchain
names
* Emacs mode: indent keys in struct literals properly
[ Ond�ej Surý ]
* Imported Upstream weekly version 2011.04.13
* Update patches to new weekly release
* Add lintian-override for gotest binary
-- Ond�ej Surý ond...@debian.org Tue, 26 Apr 2011 09:59:28 +0200
golang (2011.03.07.1-1) unstable; urgency=low
* Imported Upstream version 2011.03.07.1
* Install to /usr/lib/go
* Remove xkcd strip to get rid of CC-NC-BY
* Update golang-src.install to new upstream
* Remove 002-use_GOROOT_FINAL_in_generated_binaries.patch; merged
upstream
* Make all .go files no-executable
* Update lintian-overrides to include both types of syntax
-- Ond�ej Surý ond...@debian.org Wed, 20 Apr 2011 17:36:48 +0200
golang (2011.02.15-2) unstable; urgency=low
[ Ond�ej Surý ]
* Add ${misc:Depends} to golang-mode to shutup lintian
* Rehaul build system and add golang-src package with .go source files
* goinstall: do not automatically install prerequisities
* goinstall: don't report to dashboard by default
* Add a README.Debian about local modifications to goinstall
* Add warning about local modifications also directly to goinstall command
[ Florian Weimer ]
* Fix syntax error in 004-
[Bug 803836] Re: Please sync golang 1:57.2-1 from Debian unstable (main)
I just spoke with Gustavo: he's running for transportation, and doesn't have time to comment on the bug. Please proceed with the sync: if there are issues with the package post-sync, we'll do some more uploading next week. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/803836 Title: Please sync golang 1:57.2-1 from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/803836/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 626543] Re: kubuntu-mobile should be built against universe
Everything here appears to have happened within the natty cycle. ** Changed in: kubuntu-meta (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to kubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/626543 Title: kubuntu-mobile should be built against universe To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/626543/+subscriptions -- kubuntu-bugs mailing list kubuntu-b...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 787220] Re: [needs-packaging] celt051
** Bug watch added: Debian Bug tracker #603699 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603699 ** Also affects: debian via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603699 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/787220 Title: [needs-packaging] celt051 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 786505] Re: Window management - Super + W does not zoom out on all windows in all workspaces - minimized windows are ignored
** Changed in: compiz (Ubuntu) Importance: Undecided = Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/786505 Title: Window management - Super + W does not zoom out on all windows in all workspaces - minimized windows are ignored -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 787051] Re: mk-sbuild is untruthful
Rather, it's just outdated. There's some other cruft in there (for instance, the current created sbuild.conf entries will generate deprecation warnings, and they should have been put in conf.d anyway to avoid maintainer script merge issues). I don't know that it's worth fixing it: mk-sbuild should better be folded into sbuild-createchroot. ** Changed in: ubuntu-dev-tools (Ubuntu) Importance: Undecided = Low ** Changed in: ubuntu-dev-tools (Ubuntu) Status: New = Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/787051 Title: mk-sbuild is untruthful -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 771983] Re: Sometimes I am unable to type in the Post to.. input field.
** Changed in: indicator-me (Ubuntu) Importance: Undecided = Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/771983 Title: Sometimes I am unable to type in the Post to.. input field. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 754840] Re: Have to switch manually between audio output connectors
** Changed in: linux (Ubuntu) Importance: Undecided = Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/754840 Title: [HP Pavilion dv6 Notebook PC] Have to switch manually between audio output connectors -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 721602] Re: Typo in description field
** Changed in: google-gadgets (Ubuntu) Status: New = Triaged ** Changed in: google-gadgets (Ubuntu) Importance: Undecided = Wishlist ** Also affects: google-gadgets (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614013 Importance: Unknown Status: Unknown ** Changed in: googlegadgets Importance: Unknown = Undecided ** Changed in: googlegadgets Status: Fix Committed = New ** Changed in: googlegadgets Remote watch: Debian Bug tracker #614013 = None ** Changed in: googlegadgets Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/721602 Title: Typo in description field -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 721054] Re: Please merge epdfview-0.1.7-5 from Debian unstable
** Changed in: epdfview (Ubuntu Natty) Status: In Progress = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/721054 Title: Please merge epdfview-0.1.7-5 from Debian unstable -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 721054] Re: Please merge epdfview-0.1.7-5 from Debian unstable
** Changed in: epdfview (Ubuntu Natty) Assignee: (unassigned) = Emmet Hikory (persia) ** Changed in: epdfview (Ubuntu Natty) Status: Confirmed = In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/721054 Title: Please merge epdfview-0.1.7-5 from Debian unstable -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 718615] [NEW] Please add support for linux-linaro-imx51 on efika MX and efika SB
Public bug reported: Binary package hint: base-installer Please add kernel selection support in base-installer for linux-linaro- imx51 for the efika MX and efika SB. ** Affects: base-installer (Ubuntu) Importance: Undecided Assignee: Emmet Hikory (persia) Status: Incomplete ** Changed in: base-installer (Ubuntu) Status: New = Incomplete ** Changed in: base-installer (Ubuntu) Assignee: (unassigned) = Emmet Hikory (persia) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/718615 Title: Please add support for linux-linaro-imx51 on efika MX and efika SB -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 718615] Re: Please add support for linux-linaro-imx51 on efika MX and efika SB
** Changed in: base-installer (Ubuntu) Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/718615 Title: Please add support for linux-linaro-imx51 on efika MX and efika SB -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 718615] Re: Please add support for linux-linaro-imx51 on efika MX and efika SB
** Changed in: base-installer (Ubuntu) Status: Incomplete = In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/718615 Title: Please add support for linux-linaro-imx51 on efika MX and efika SB -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 713087] Re: Allow unity dock to be resizable
** Changed in: unity (Ubuntu) Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/713087 Title: Allow unity dock to be resizable -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 713083] Re: Allow location of the dock to be customizable
** Changed in: unity (Ubuntu) Importance: Undecided = Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/713083 Title: Allow location of the dock to be customizable -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 682680] Re: New upstream release, gearmand 0.14
** Tags added: update ** Tags removed: needs-packaging -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/682680 Title: New upstream release, gearmand 0.14 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 682680] Re: New upstream release, gearmand 0.14
** Bug watch added: Debian Bug tracker #590116 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590116 ** Also affects: gearmand (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590116 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/682680 Title: New upstream release, gearmand 0.14 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 704030] Re: name of dh-make package is misspelled
** Changed in: ubuntu-docs (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/704030 Title: name of dh-make package is misspelled -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 708519] Re: Please drop hal dependency
Upstream bug at http://bugreports.qt.nokia.com/browse/QTMOBILITY-1057 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/708519 Title: Please drop hal dependency -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 660452] Re: monkeystudio always crashes when creating new file or trying to open existing one
** Changed in: monkeystudio (Ubuntu Maverick) Assignee: Evgeni Golov (sargentd) = Emmet Hikory (persia) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/660452 Title: monkeystudio always crashes when creating new file or trying to open existing one -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 660452] Re: monkeystudio always crashes when creating new file or trying to open existing one
Note that if you aren't a regular user of MonkeyStudio, you may need to change the path for the new project to complete verification without errors. I've uploaded a 1.8.4.0-1ubuntu1.1 to maverick-proposed for consideration. ** Changed in: monkeystudio (Ubuntu Maverick) Assignee: Emmet Hikory (persia) = (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/660452 Title: monkeystudio always crashes when creating new file or trying to open existing one -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 660452] Re: monkeystudio always crashes when creating new file or trying to open existing one
** Also affects: monkeystudio (Ubuntu Maverick) Importance: Undecided Status: New ** Changed in: monkeystudio (Ubuntu Maverick) Importance: Undecided = Medium ** Changed in: monkeystudio (Ubuntu Maverick) Status: New = Triaged ** Changed in: monkeystudio (Ubuntu Maverick) Assignee: (unassigned) = Evgeni Golov (sargentd) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/660452 Title: monkeystudio always crashes when creating new file or trying to open existing one -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Introducing Products
In the testing team, we've been using the concept of product for some time, to better identify the artifacts that capture our attention, but I am unsure that this concept has been shared with the wider development community. A product is an image containing some portion of Ubuntu software, targeted for some specific installation environment, and released following our release management processes. Some examples of our current products include: Ubuntu Desktop Live i386 Ubuntu Server Alternate amd64 Kubuntu Desktop Live powerpc Ubuntu Netbook Preinstalled armel+omap3 In an attempt to better manage our products, and ensure that each product is well tested and well supported, a more formal means of tracking products is being established, so that each product must be deliberately selected by some team willing to commit to the validation and certification processes, consisting of those who have both the necessary hardware and familiarity with the software to provide effective testing; and each product must have a nominated product manager. Towards that end, each flavour team should consider which installation targets they wish to support, and identify a product manager who will be available as a contact for the release team to provide confirmation of the completion of milestone validations and release approval for each product. Depending on the internal organisation of any specific flavour team, these product managers might be part of the development team, part of the testing team, or part of a management team. In all cases, the nominated product managers should have access to the installation environment towards which their product is targeted. Those interested in following the specifics of the implementation are encouraged to subscribe to the relevant specification (1), which will be used for the tracking of the implementation. I will be contacting each flavour team in the near future to discuss the available installation targets and the set of products to be released with Ubuntu 11.04. Once complete, the set of images produced will be limited to only include those for which product managers have been nominated. 1: https://blueprints.launchpad.net/ubuntu/+spec/other-qa-n-testing-different-architectures -- Emmet HIKORY -- Ubuntu-qa mailing list Ubuntu-qa@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa
Re: Introducing Products
Tim Gardner wrote: On 11/22/2010 01:02 PM, Emmet Hikory wrote: Towards that end, each flavour team should consider which installation targets they wish to support, and identify a product manager who will be available as a contact for the release team to provide confirmation of the completion of milestone validations and release approval for each product. Depending on the internal organisation of any specific flavour team, these product managers might be part of the development team, part of the testing team, or part of a management team. In all cases, the nominated product managers should have access to the installation environment towards which their product is targeted. I like your proposal. In the past, due to the somewhat chaotic ARM planning process, the kernel team has spent time and energy on ARM branches for platforms that nobody has actually used. We have since retired some ARM branches as obsolete and unmaintained. I suspect the output of this discovery will go a fair way towards reducing that sort of confusion in the future, as we'll have a clearer identification of populations willing to test various installation targets. If folks wish to support a target that doesn't have a current kernel image, but can be supported by only configuration changes to the Ubuntu kernels, should they request more kernel images be produced by the kernel team, or upload their own derivative kernels? I'm hesitant to encourage anyone to attempt to produce images where there isn't a working kernel in Ubuntu, but I'm not sure how to advise folk who want to produce images for things that are mostly supported, except in cases where there are meaningfully invasive patchsets, where topic branches are clearly more appropriate (with separate source packages producing separate images). -- Emmet HIKORY -- 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
[Bug 669620] Re: gnome-web-photo --help shows wrong binary name
** Also affects: gnome-web-photo (Ubuntu Lucid) Importance: Undecided Status: New ** Also affects: gnome-web-photo (Ubuntu Maverick) Importance: Undecided Status: New -- gnome-web-photo --help shows wrong binary name https://bugs.launchpad.net/bugs/669620 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 486370] Re: Cannot rename folder from FOO to foo on vfat disk
This is an intentional design choice for FAT32. As the filesystem is intentionally case-insensitive, it cannot work, and hence cannot be fixed in Ubuntu. Further, even if someone submitted a working patch to make it work in Ubuntu, we wouldn't want to fix it, as it would break compatibility with the other several thousand implementations of FAT32 floating around the internet. ** Changed in: windows-el (Ubuntu) Status: New = Won't Fix -- Cannot rename folder from FOO to foo on vfat disk https://bugs.launchpad.net/bugs/486370 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605694] Re: ubuntu for mipsel
Unfortunately, adding a PPA is likely one of the last steps in enabling a new architecture, as it requires that architecture to be fully supported in Ubuntu, and have working virtualisation. So, based on ports that have appeared in the past, the following things seem to need to happen in order for it to be done. 1) Someone needs to be maintaining an Ubuntu kernel for the architecture (using all the Ubuntu sauce, etc.) 2) Someone needs to be actively maintaining the Ubuntu toolchain to ensure it works on that architecture 3) Someone needs to have bootstrapped a good chunk of the archive (Ubuntu Desktop is often the first target) 4) The architecture needs to be supported in Debian (although compiler defaults, etc. may differ) 5) There need to be a sufficient set of folks willing to test on that architecture Once all those conditions are met, it's mostly a matter of getting trusted buildds into the Canonical data centre. I don't know the precise procedure for that, but I'd guess that if the 5 conditions above were met, and hardware was available, one might start by making a request to rt.ubuntu.com. Note that this may take a long time to get a response, as there are many more time-critical tasks that the folk who process the RTs need to do. All that said, I'll note that someone had a working toolchain port for Intrepid, so it's not infeasible to do something. -- ubuntu for mipsel https://bugs.launchpad.net/bugs/605694 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 665191] [NEW] Update Manager stays open when it doesn't need to do so
Public bug reported: Binary package hint: update-manager Update Manager opened in a minimised state. I noticed it was open, and it reported there were 31 updates available. I figured it had probably been a while since it opened, so clicked Check to get it more up-to- date. It then reported there were zero updates available. I closed it. This wasn't a very useful experience. So, let's look at why this happened: I don't tend to use update-manager to manage my packages. It had probably been open for a couple days (I don't tend to reboot or shut down), and I would have noticed the available updates in byobu, and installed them without having ever noticed update-manager having been launched. (when I notice it launched, I tend to press Check to get updates faster than the regular however many days). This is entirely expected behaviour. What I think *should* happen is that if update-manager is running, and the user has not interacted with it in some time (maybe a couple hours), it ought see if the apt cache has been updated since it last checked, and if so, check again to make sure there are still updates, and if there are none, close itself silently. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: update-manager 1:0.142.20 ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4 Uname: Linux 2.6.35-22-generic x86_64 Architecture: amd64 Date: Sat Oct 23 01:11:21 2010 InstallationMedia: Ubuntu 10.10 Maverick Meerkat - Alpha amd64 (20100803.1) PackageArchitecture: all ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: update-manager ** Affects: update-manager (Ubuntu) Importance: Medium Status: Triaged ** Tags: amd64 apport-bug maverick -- Update Manager stays open when it doesn't need to do so https://bugs.launchpad.net/bugs/665191 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 665191] Re: Update Manager stays open when it doesn't need to do so
-- Update Manager stays open when it doesn't need to do so https://bugs.launchpad.net/bugs/665191 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
