Re: Future of Appmenu Outside Unity
On Tuesday, July 23, 2013 11:23:20 PM Ted Gould wrote: > On Tue, 2013-07-23 at 22:23 -0400, Scott Kitterman wrote: > > On Tuesday, July 23, 2013 09:00:33 PM Ted Gould wrote: > > > On Tue, 2013-07-23 at 21:01 -0400, Scott Kitterman wrote: > > > > Since shortly after Mark announced the global menu [1] Kubuntu has > > > > shipped > > > > plasma-widget-menubar to provide this functionality [2] and not only > > > > for > > > > Qt/KDE, but for Gtk apps as well [3]. This has served us well on > > > > netbooks > > > > for three years and I use it myself on a daily basis on a conventional > > > > laptop. > > > > > > > > As of today [4], that's no longer possible. Appmenu-gtk has been > > > > replaced > > > > by unity-gtk-module, which (apparently intentionally) doesn't work > > > > outside Unity [5]. > > > > > > > > Is this correct? That's my impression, but I'm not aware of any > > > > discussion > > > > this, so I may have missed something. > > > > > > Oh, cool. I honestly didn't realize that it was still in use, very cool > > > that it has been useful! > > > > > > In general, the big migration here is away from DBusMenu (which was > > > Ubuntu-only) to GMenu which is in GLib. That's basically the difference > > > between appmenu-gtk and unity-gtk-module. There's no technical reason > > > that it would only work on Unity, even if it's in the name. > > > > Actually, DBusMenu is an upstream KDE feature. You may recall it was > > originally a joint Ubuntu/KDE development. > > Hmm, I don't recall. But history is best argued over beer rather than > e-mail :-) > > > We're at KDE SC 4.11 RC1 right > > now, so it's too late to do anything upstream KDE in 4.11 and the Plasma > > Workspace is feature frozen after 4.11 so that upstream can focus on > > Plasma 2 (that will use Qt5 and KDE Frameworks). So we're several > > release cycles away from being able to do anything upstream. > > That's unfortunate. I don't know if I can get someone assigned to it, > but if so, would you guys be willing to distro patch it? I'm not sure > if QMenuModel works on Qt 4, I think so, but hopefully Lars can verify > that when it gets to his timezone. I think we don't have much of a choice. We'd need to coordinate this with upstream so it gets landed for Plasma 2 and then backport the appropriate changes. > > > Which means, in a nutshell, that plasma-widget-menubar would need some > > > porting. Canonical has been working on QMenuModel[1] which provides > > > simple Qt bindings for GMenu exported menus, and should work well for > > > this purpose. I know that Lars (cc'd) has some changes that he's > > > working on there, so it is expected to get better. We are using > > > QMenuModel for all of the indicators in the Unity 8 interface, so you > > > can expect it to be well supported. > > > > How does this impact support in applications? For Qt/KDE apps (due to the > > integration in Qt4) it just works. There's no need to patch individual > > applications. Is this true for QMenuMode? Is it for Qt4 and Qt5? What's > > the upstream plan for it? > > QMenuModel is just a helper library, similar to libdbusmenu. It's not > doing the integration aspects there. We haven't discussed (AFAIK) > porting libdbusmenu-qt users to QMenuModel with any seriousness. I > think that we should, but I'll need to gather more data on the impact, > etc. I imagine that most of the people I'd ping on it are maxed out for > 13.10 already though. I appreciate you looking into it. > > > In indicator-appmenu (the module in Unity that supports the global menu > > > bar) we are currently supporting both DBusmenu applications and GMenu > > > based ones. This is largely because everything isn't ported yet. It > > > has been an unofficial goal to remove DBusmenu for the LTS. I see no > > > issue in keeping appmenu-gtk as a package, but I would consider it > > > deprecated. > > > > AIUI, currently unity-gtk-module conflicts appmenu-gtk, so they can't both > > be installed together. That would have to be fixed since many users have > > both Kubuntu and Ubuntu installed and I think we want to support that. > > > > Also, the gtk/gtk3 patches that supported appmenu-gtk have been dropped, > > so > > even if we brought the package back, it wouldn't build. Can those be > > added > > back? > > > > Also keeping it now, just to drop it for the LTS doesn't really help much > > since the Plasma Desktop will still be using DBusMenu and we'd just have > > to > > drop it then. > > Yes, I forgot about the GTK patches, those are a bit trickier. What do > you think would be a good solution? Do you think it'd be reasonable to > have GTK applications not work in the plasma menubar for 13.10? That's > clearly the easiest solution, but perhaps too broken. I just removed plasma-widget-menubar from the Kubuntu seeds and from our default panel configuration for netbooks because I think that having a solution that only works for some applications and not
Re: Source packages appropriate by default?
On 24 July 2013 11:08, Scott Kitterman wrote: > On Wednesday, July 24, 2013 11:00:40 AM Daniel J Blueman wrote: >> Perhaps we have two issues here: > >> The 20% additional download due to sources [1] would help both issues, >> but perhaps of bigger impact, trusting the country-level mirror for >> the security updates? > ... > You aren't. Security updates are pushed first to security.ubuntu.com and then > copied to archive.ubuntu.com and mirrored from there. The security pocket > isn't mirrored so you always hit it directly and if a country mirror lags, you > get the package from security.ubuntu.com. Also, the signing key is the same > Ubuntu archive signing key whether you're getting a package form > archive.ubuntu.com or a country mirror, so you aren't trusting the country > mirror cryptographically either. What I meant, if the country-level archive is sync'd every 12-24 hours, would it be sufficient to download the security pocket from .archive.ubuntu.com? It is mirrored, so this would alleviate the second issue. Daniel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
Or 90/110K per day per computer for Precise. I guess what was getting me is the additional 6-7MB during install or first update: http://archive.ubuntu.com/ubuntu/dists/precise/universe/source/ 4.8M/5.9M http://archive.ubuntu.com/ubuntu/dists/precise/main/source/ 912K/1.1M On 24 July 2013 09:31, Scott Kitterman wrote: > On Tuesday, July 23, 2013 08:21:40 AM Jordon Bedwell wrote: >> On Tue, Jul 23, 2013 at 6:32 AM, Scott Kitterman > wrote: >> > Assuming add-apt-repository was installed by default, it's close. I think >> > something like this might be reasonable (imagine some policykit or >> > whatever it is called now magic here): >> > >> > $ sudo apt-get source hello >> > Reading package lists... Done >> > Building dependency tree >> > Reading state information... Done >> > E: You must put some 'source' URIs in your sources.list >> > Would you like 'source' URIs to be added? (y/N) >> > Y >> > deb-src lines have been added to your sources.list. >> > ... >> > Get:9 http://archive.ubuntu.com saucy/main Sources [1,001 kB] >> > Get:10 http://archive.ubuntu.com saucy/restricted Sources [6,578 B] >> > Get:11 http://archive.ubuntu.com saucy/universe Sources [6,071 kB] >> > >> > In other words, it's, I think, possible to make it roughly as easy as it >> > is >> > now to get source without having the sources.list "cluttered". For users >> > of our releases, I doubt it saves much, but that would be a way to do it >> > that both avoids whatever amount of bandwidth usage is involved until the >> > user opts in to it, but preserves ready access to the source that I think >> > is important. >> Depending on how clever and one-off you want to be you could also just >> give them the http url to the source as well. It shouldn't be that >> hard to guess since apt already has most of the information needed to >> just generate the URL from a chosen apt server in the normal deb. >> This would allow for one-off downloads (for example somebody needs to >> look at the way debian does some of it's compiles so they can >> replicate without a package so they grab the source for nginx -- >> that's a one-off IMO if they would never use any other source >> package.) >> >> Though I personally like a default command that would be something >> like add-apt-default-sources so you can also give them the ability to >> run that command and disable sources too (but you can already do that >> via the GUI and terminal by editing /etc/apt/sources.list and such.) > > Before we run off and expend a lot more effort on this, I'd like to see > something other than handwaving that this is really is a significant issue. > > /ubuntu/dists/raring-security/main/source > > [ ] Release 24-Jul-2013 01:16 106 > [ ] Sources.bz2 24-Jul-2013 01:16 32K > [ ] Sources.gz 24-Jul-2013 01:16 38K > > For end users, how much is really downloaded? > > /ubuntu/dists/raring-updates/main/source > > [ ] Release 24-Jul-2013 01:16 105 > [ ] Sources.bz2 24-Jul-2013 01:16 50K > [ ] Sources.gz 24-Jul-2013 01:16 62K > > /ubuntu/dists/raring-updates/universe/source > > [ ] Release 24-Jul-2013 01:16 109 > [ ] Sources.bz2 24-Jul-2013 01:16 64K > [ ] Sources.gz 24-Jul-2013 01:16 77K > > It doesn't seem like a lot. > > Scott K > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Daniel J Blueman -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
Perhaps we have two issues here: - the download during installs or first index update is 6-7MB extra, which makes a real difference when installing lots of computers - downloads from security.ubuntu.com being slow (eg 1-5KB/s) as it's >500ms away The 20% additional download due to sources [1] would help both issues, but perhaps of bigger impact, trusting the country-level mirror for the security updates? Daniel --- [1] Get:1 http://security.ubuntu.com precise-security Release.gpg [198 B] Get:2 http://security.ubuntu.com precise-security Release [49.6 kB] Get:3 http://security.ubuntu.com precise-security/main Sources [83.5 kB] Get:4 http://security.ubuntu.com precise-security/restricted Sources [2494 B] Get:5 http://security.ubuntu.com precise-security/universe Sources [27.1 kB] Get:6 http://security.ubuntu.com precise-security/multiverse Sources [1383 B] Get:7 http://security.ubuntu.com precise-security/main amd64 Packages [296 kB] Get:8 http://security.ubuntu.com precise-security/restricted amd64 Packages [4627 B] Get:9 http://security.ubuntu.com precise-security/universe amd64 Packages [77.7 kB] Get:10 http://security.ubuntu.com precise-security/multiverse amd64 Packages [2186 B] Get:11 http://security.ubuntu.com precise-security/main i386 Packages [311 kB] Get:12 http://security.ubuntu.com precise-security/restricted i386 Packages [4620 B] Get:13 http://security.ubuntu.com precise-security/universe i386 Packages [80.5 kB] Get:14 http://security.ubuntu.com precise-security/multiverse i386 Packages [2371 B] Get:15 http://security.ubuntu.com precise-security/main TranslationIndex [74 B] Get:16 http://security.ubuntu.com precise-security/multiverse TranslationIndex [71 B] Get:17 http://security.ubuntu.com precise-security/restricted TranslationIndex [72 B] Get:18 http://security.ubuntu.com precise-security/universe TranslationIndex [73 B] On 24 July 2013 10:46, Robie Basak wrote: > On Tue, Jul 23, 2013 at 09:31:15PM -0400, Scott Kitterman wrote: >> Before we run off and expend a lot more effort on this, I'd like to >> see something other than handwaving that this is really is a >> significant issue. > > [size comparisions snipped] > > My concern is latency, not size. How many round trips will we save this > way? For cloud images using Amazon S3 mirrors, for example, each request > is quite a bit slower AIUI, and apt-get doesn't currently support > concurrent requests to a single server. > > This is a pain for instances that start up with cloud-init and > immediately have to update sources and install things before they can > become functional. It'd be nice to see the delay from "juju deploy" to > having a live service running get shorter. Same for "juju add-unit". > Admittedly an alternative means to achieve this could be to have > cloud-init remove the deb-src lines first, but it seems a shame to leave > others behind if this really does improve things. > > I agree that I should come up with actual figures before pushing ahead > for this reason. > > -- > Ubuntu-devel-discuss mailing list > ubuntu-devel-disc...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Daniel J Blueman -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Wednesday, July 24, 2013 03:46:10 AM Robie Basak wrote: > On Tue, Jul 23, 2013 at 09:31:15PM -0400, Scott Kitterman wrote: > > Before we run off and expend a lot more effort on this, I'd like to > > see something other than handwaving that this is really is a > > significant issue. > > [size comparisions snipped] > > My concern is latency, not size. How many round trips will we save this > way? For cloud images using Amazon S3 mirrors, for example, each request > is quite a bit slower AIUI, and apt-get doesn't currently support > concurrent requests to a single server. > > This is a pain for instances that start up with cloud-init and > immediately have to update sources and install things before they can > become functional. It'd be nice to see the delay from "juju deploy" to > having a live service running get shorter. Same for "juju add-unit". > Admittedly an alternative means to achieve this could be to have > cloud-init remove the deb-src lines first, but it seems a shame to leave > others behind if this really does improve things. > > I agree that I should come up with actual figures before pushing ahead > for this reason. Has any work been done on concurrent requests? That would likely be pretty broadly useful, not just for cloud images. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tue, Jul 23, 2013 at 09:31:15PM -0400, Scott Kitterman wrote: > Before we run off and expend a lot more effort on this, I'd like to > see something other than handwaving that this is really is a > significant issue. [size comparisions snipped] My concern is latency, not size. How many round trips will we save this way? For cloud images using Amazon S3 mirrors, for example, each request is quite a bit slower AIUI, and apt-get doesn't currently support concurrent requests to a single server. This is a pain for instances that start up with cloud-init and immediately have to update sources and install things before they can become functional. It'd be nice to see the delay from "juju deploy" to having a live service running get shorter. Same for "juju add-unit". Admittedly an alternative means to achieve this could be to have cloud-init remove the deb-src lines first, but it seems a shame to leave others behind if this really does improve things. I agree that I should come up with actual figures before pushing ahead for this reason. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 09:19:36 PM Scott Ritchie wrote: > On 07/23/2013 12:02 AM, Scott Kitterman wrote: > > On Tuesday, July 23, 2013 06:59:43 AM Robie Basak wrote: > >> On Tue, Jul 23, 2013 at 01:51:46AM -0400, Scott Kitterman wrote: > >>> I think most developers would believe the current situation is > >>> appropriate. > >> > >> I disagree. > >> > >>> By default users have the same access to source and binary packages and > >>> for a free software distribution, that is the ethically correct > >>> approach. > >> > >> Indeed, but you never replied to my original response to your concern. > >> By "same access", do you specifically require the mechanism to be to > >> keep users' local apt caches maintained with source entries? If so, why > >> is such a mechanism necessary to fit the spirit of Free Software? If the > >> user still has easy access to the source, why is this not sufficient? > >> > >> I'm happy to discuss what "easy access" might actually mean, but I see > >> no reason that it should require the waste of users' bandwidth and time. > > > > Sorry. I didn't mean to ignore you. > > > > What's easy? For example, I think "install more packages to get the tools > > to get the source" (use pull-lp-source in ubuntu-dev-tools) doesn't > > qualify. There are tons of documentation all over the web and other > > places as well that assume apt-get source works. > > I agree, it would be nice to keep existing things working. > > > So those are a couple of examples of what I think is definitely not what > > we > > want. I'm open to discussion about alternate ways to preserve easy access > > to the source. > > What if we disabled default source fetching but changed apt-get source > to offer to turn them back on when it was run? One other aspect of this that has occurred to me is that adding new sources (whehter they are present, but disabled or added new) takes administrator rights. Currently, any user of the system can get source using standard distro tools (apt-get). If you have to add a repository, you either have to be an admin or get one. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Future of Appmenu Outside Unity
On Tue, 2013-07-23 at 22:23 -0400, Scott Kitterman wrote: > On Tuesday, July 23, 2013 09:00:33 PM Ted Gould wrote: > > On Tue, 2013-07-23 at 21:01 -0400, Scott Kitterman wrote: > > > Since shortly after Mark announced the global menu [1] Kubuntu has shipped > > > plasma-widget-menubar to provide this functionality [2] and not only for > > > Qt/KDE, but for Gtk apps as well [3]. This has served us well on netbooks > > > for three years and I use it myself on a daily basis on a conventional > > > laptop. > > > > > > As of today [4], that's no longer possible. Appmenu-gtk has been replaced > > > by unity-gtk-module, which (apparently intentionally) doesn't work > > > outside Unity [5]. > > > > > > Is this correct? That's my impression, but I'm not aware of any > > > discussion > > > this, so I may have missed something. > > > > Oh, cool. I honestly didn't realize that it was still in use, very cool > > that it has been useful! > > > > In general, the big migration here is away from DBusMenu (which was > > Ubuntu-only) to GMenu which is in GLib. That's basically the difference > > between appmenu-gtk and unity-gtk-module. There's no technical reason > > that it would only work on Unity, even if it's in the name. > > Actually, DBusMenu is an upstream KDE feature. You may recall it was > originally a joint Ubuntu/KDE development. Hmm, I don't recall. But history is best argued over beer rather than e-mail :-) > We're at KDE SC 4.11 RC1 right > now, so it's too late to do anything upstream KDE in 4.11 and the Plasma > Workspace is feature frozen after 4.11 so that upstream can focus on Plasma 2 > (that will use Qt5 and KDE Frameworks). So we're several release cycles away > from being able to do anything upstream. That's unfortunate. I don't know if I can get someone assigned to it, but if so, would you guys be willing to distro patch it? I'm not sure if QMenuModel works on Qt 4, I think so, but hopefully Lars can verify that when it gets to his timezone. > > Which means, in a nutshell, that plasma-widget-menubar would need some > > porting. Canonical has been working on QMenuModel[1] which provides > > simple Qt bindings for GMenu exported menus, and should work well for > > this purpose. I know that Lars (cc'd) has some changes that he's > > working on there, so it is expected to get better. We are using > > QMenuModel for all of the indicators in the Unity 8 interface, so you > > can expect it to be well supported. > > How does this impact support in applications? For Qt/KDE apps (due to the > integration in Qt4) it just works. There's no need to patch individual > applications. Is this true for QMenuMode? Is it for Qt4 and Qt5? What's > the > upstream plan for it? QMenuModel is just a helper library, similar to libdbusmenu. It's not doing the integration aspects there. We haven't discussed (AFAIK) porting libdbusmenu-qt users to QMenuModel with any seriousness. I think that we should, but I'll need to gather more data on the impact, etc. I imagine that most of the people I'd ping on it are maxed out for 13.10 already though. > > In indicator-appmenu (the module in Unity that supports the global menu > > bar) we are currently supporting both DBusmenu applications and GMenu > > based ones. This is largely because everything isn't ported yet. It > > has been an unofficial goal to remove DBusmenu for the LTS. I see no > > issue in keeping appmenu-gtk as a package, but I would consider it > > deprecated. > > AIUI, currently unity-gtk-module conflicts appmenu-gtk, so they can't both be > installed together. That would have to be fixed since many users have both > Kubuntu and Ubuntu installed and I think we want to support that. > > Also, the gtk/gtk3 patches that supported appmenu-gtk have been dropped, so > even if we brought the package back, it wouldn't build. Can those be added > back? > > Also keeping it now, just to drop it for the LTS doesn't really help much > since the Plasma Desktop will still be using DBusMenu and we'd just have to > drop it then. Yes, I forgot about the GTK patches, those are a bit trickier. What do you think would be a good solution? Do you think it'd be reasonable to have GTK applications not work in the plasma menubar for 13.10? That's clearly the easiest solution, but perhaps too broken. Ted signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On 07/23/2013 12:02 AM, Scott Kitterman wrote: > On Tuesday, July 23, 2013 06:59:43 AM Robie Basak wrote: >> On Tue, Jul 23, 2013 at 01:51:46AM -0400, Scott Kitterman wrote: >>> I think most developers would believe the current situation is >>> appropriate. >> >> I disagree. >> >>> By default users have the same access to source and binary packages and >>> for a free software distribution, that is the ethically correct approach. >> Indeed, but you never replied to my original response to your concern. >> By "same access", do you specifically require the mechanism to be to >> keep users' local apt caches maintained with source entries? If so, why >> is such a mechanism necessary to fit the spirit of Free Software? If the >> user still has easy access to the source, why is this not sufficient? >> >> I'm happy to discuss what "easy access" might actually mean, but I see >> no reason that it should require the waste of users' bandwidth and time. > > Sorry. I didn't mean to ignore you. > > What's easy? For example, I think "install more packages to get the tools to > get the source" (use pull-lp-source in ubuntu-dev-tools) doesn't qualify. > There are tons of documentation all over the web and other places as well > that > assume apt-get source works. > I agree, it would be nice to keep existing things working. > So those are a couple of examples of what I think is definitely not what we > want. I'm open to discussion about alternate ways to preserve easy access to > the source. > What if we disabled default source fetching but changed apt-get source to offer to turn them back on when it was run? -Scott Ritchie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch pilot report, 2013-07-24.
Total requests at start: 53 Bug #1194489 - A newer Debian revision is present in unstable, requested an updated merge. Bug #1204285 - Synced https://code.launchpad.net/~nitink/ubuntu/saucy/ushare/bug-1044024 - Uploaded after converting to a quilt patch. https://code.launchpad.net/~obounaim/ubuntu/saucy/curl/merge-from-debian - Uploaded https://code.launchpad.net/~jbicha/ubuntu/saucy/language-selector/help-update-for-python-distutils-extra - Uploaded Total Requests at end: 50 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Wednesday, July 24, 2013 11:00:40 AM Daniel J Blueman wrote: > Perhaps we have two issues here: > The 20% additional download due to sources [1] would help both issues, > but perhaps of bigger impact, trusting the country-level mirror for > the security updates? ... You aren't. Security updates are pushed first to security.ubuntu.com and then copied to archive.ubuntu.com and mirrored from there. The security pocket isn't mirrored so you always hit it directly and if a country mirror lags, you get the package from security.ubuntu.com. Also, the signing key is the same Ubuntu archive signing key whether you're getting a package form archive.ubuntu.com or a country mirror, so you aren't trusting the country mirror cryptographically either. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Future of Appmenu Outside Unity
On Tuesday, July 23, 2013 09:00:33 PM Ted Gould wrote: > On Tue, 2013-07-23 at 21:01 -0400, Scott Kitterman wrote: > > Since shortly after Mark announced the global menu [1] Kubuntu has shipped > > plasma-widget-menubar to provide this functionality [2] and not only for > > Qt/KDE, but for Gtk apps as well [3]. This has served us well on netbooks > > for three years and I use it myself on a daily basis on a conventional > > laptop. > > > > As of today [4], that's no longer possible. Appmenu-gtk has been replaced > > by unity-gtk-module, which (apparently intentionally) doesn't work > > outside Unity [5]. > > > > Is this correct? That's my impression, but I'm not aware of any > > discussion > > this, so I may have missed something. > > Oh, cool. I honestly didn't realize that it was still in use, very cool > that it has been useful! > > In general, the big migration here is away from DBusMenu (which was > Ubuntu-only) to GMenu which is in GLib. That's basically the difference > between appmenu-gtk and unity-gtk-module. There's no technical reason > that it would only work on Unity, even if it's in the name. Actually, DBusMenu is an upstream KDE feature. You may recall it was originally a joint Ubuntu/KDE development. We're at KDE SC 4.11 RC1 right now, so it's too late to do anything upstream KDE in 4.11 and the Plasma Workspace is feature frozen after 4.11 so that upstream can focus on Plasma 2 (that will use Qt5 and KDE Frameworks). So we're several release cycles away from being able to do anything upstream. > Which means, in a nutshell, that plasma-widget-menubar would need some > porting. Canonical has been working on QMenuModel[1] which provides > simple Qt bindings for GMenu exported menus, and should work well for > this purpose. I know that Lars (cc'd) has some changes that he's > working on there, so it is expected to get better. We are using > QMenuModel for all of the indicators in the Unity 8 interface, so you > can expect it to be well supported. How does this impact support in applications? For Qt/KDE apps (due to the integration in Qt4) it just works. There's no need to patch individual applications. Is this true for QMenuMode? Is it for Qt4 and Qt5? What's the upstream plan for it? > In indicator-appmenu (the module in Unity that supports the global menu > bar) we are currently supporting both DBusmenu applications and GMenu > based ones. This is largely because everything isn't ported yet. It > has been an unofficial goal to remove DBusmenu for the LTS. I see no > issue in keeping appmenu-gtk as a package, but I would consider it > deprecated. AIUI, currently unity-gtk-module conflicts appmenu-gtk, so they can't both be installed together. That would have to be fixed since many users have both Kubuntu and Ubuntu installed and I think we want to support that. Also, the gtk/gtk3 patches that supported appmenu-gtk have been dropped, so even if we brought the package back, it wouldn't build. Can those be added back? Also keeping it now, just to drop it for the LTS doesn't really help much since the Plasma Desktop will still be using DBusMenu and we'd just have to drop it then. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Future of Appmenu Outside Unity
On Tue, 2013-07-23 at 21:01 -0400, Scott Kitterman wrote: > Since shortly after Mark announced the global menu [1] Kubuntu has shipped > plasma-widget-menubar to provide this functionality [2] and not only for > Qt/KDE, but for Gtk apps as well [3]. This has served us well on netbooks > for > three years and I use it myself on a daily basis on a conventional laptop. > > As of today [4], that's no longer possible. Appmenu-gtk has been replaced by > unity-gtk-module, which (apparently intentionally) doesn't work outside Unity > [5]. > > Is this correct? That's my impression, but I'm not aware of any discussion > this, so I may have missed something. Oh, cool. I honestly didn't realize that it was still in use, very cool that it has been useful! In general, the big migration here is away from DBusMenu (which was Ubuntu-only) to GMenu which is in GLib. That's basically the difference between appmenu-gtk and unity-gtk-module. There's no technical reason that it would only work on Unity, even if it's in the name. Which means, in a nutshell, that plasma-widget-menubar would need some porting. Canonical has been working on QMenuModel[1] which provides simple Qt bindings for GMenu exported menus, and should work well for this purpose. I know that Lars (cc'd) has some changes that he's working on there, so it is expected to get better. We are using QMenuModel for all of the indicators in the Unity 8 interface, so you can expect it to be well supported. In indicator-appmenu (the module in Unity that supports the global menu bar) we are currently supporting both DBusmenu applications and GMenu based ones. This is largely because everything isn't ported yet. It has been an unofficial goal to remove DBusmenu for the LTS. I see no issue in keeping appmenu-gtk as a package, but I would consider it deprecated. Ted [1] https://launchpad.net/qmenumodel signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 08:21:40 AM Jordon Bedwell wrote: > On Tue, Jul 23, 2013 at 6:32 AM, Scott Kitterman wrote: > > Assuming add-apt-repository was installed by default, it's close. I think > > something like this might be reasonable (imagine some policykit or > > whatever it is called now magic here): > > > > $ sudo apt-get source hello > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > E: You must put some 'source' URIs in your sources.list > > Would you like 'source' URIs to be added? (y/N) > > Y > > deb-src lines have been added to your sources.list. > > ... > > Get:9 http://archive.ubuntu.com saucy/main Sources [1,001 kB] > > Get:10 http://archive.ubuntu.com saucy/restricted Sources [6,578 B] > > Get:11 http://archive.ubuntu.com saucy/universe Sources [6,071 kB] > > > > In other words, it's, I think, possible to make it roughly as easy as it > > is > > now to get source without having the sources.list "cluttered". For users > > of our releases, I doubt it saves much, but that would be a way to do it > > that both avoids whatever amount of bandwidth usage is involved until the > > user opts in to it, but preserves ready access to the source that I think > > is important. > Depending on how clever and one-off you want to be you could also just > give them the http url to the source as well. It shouldn't be that > hard to guess since apt already has most of the information needed to > just generate the URL from a chosen apt server in the normal deb. > This would allow for one-off downloads (for example somebody needs to > look at the way debian does some of it's compiles so they can > replicate without a package so they grab the source for nginx -- > that's a one-off IMO if they would never use any other source > package.) > > Though I personally like a default command that would be something > like add-apt-default-sources so you can also give them the ability to > run that command and disable sources too (but you can already do that > via the GUI and terminal by editing /etc/apt/sources.list and such.) Before we run off and expend a lot more effort on this, I'd like to see something other than handwaving that this is really is a significant issue. /ubuntu/dists/raring-security/main/source [ ] Release 24-Jul-2013 01:16 106 [ ] Sources.bz2 24-Jul-2013 01:16 32K [ ] Sources.gz 24-Jul-2013 01:16 38K For end users, how much is really downloaded? /ubuntu/dists/raring-updates/main/source [ ] Release 24-Jul-2013 01:16 105 [ ] Sources.bz2 24-Jul-2013 01:16 50K [ ] Sources.gz 24-Jul-2013 01:16 62K /ubuntu/dists/raring-updates/universe/source [ ] Release 24-Jul-2013 01:16 109 [ ] Sources.bz2 24-Jul-2013 01:16 64K [ ] Sources.gz 24-Jul-2013 01:16 77K It doesn't seem like a lot. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Future of Appmenu Outside Unity
Since shortly after Mark announced the global menu [1] Kubuntu has shipped plasma-widget-menubar to provide this functionality [2] and not only for Qt/KDE, but for Gtk apps as well [3]. This has served us well on netbooks for three years and I use it myself on a daily basis on a conventional laptop. As of today [4], that's no longer possible. Appmenu-gtk has been replaced by unity-gtk-module, which (apparently intentionally) doesn't work outside Unity [5]. Is this correct? That's my impression, but I'm not aware of any discussion this, so I may have missed something. Scott K [1] http://www.markshuttleworth.com/archives/359 [2] https://skitterman.wordpress.com/2010/07/08/global-menu-in-action-in-kubuntu-maverick/ [3] https://skitterman.wordpress.com/2010/07/09/menubar-for-gtk-and-qtkde-apps-on-kubuntu/ [4] https://bugs.launchpad.net/ubuntu/+source/appmenu-gtk/+bug/1196667 [5] https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/126 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: xubuntu-devel Digest, Vol 94, Issue 44
Hi guys. On Tue, Jul 23, 2013 at 10:42 PM, wrote: > > Today's Topics: > >1. Package testing - Xubuntu Team (Elfy) > > -- > > Message: 1 > Date: Tue, 23 Jul 2013 20:00:27 +0100 > From: Elfy > To: Xubuntu Development Discussion > Subject: Package testing - Xubuntu Team > Message-ID: <51eed2cb.3080...@btinternet.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Can the Xubuntu Team please check the current testcase bug list > > http://tinyurl.com/xubpkgs > > > Is there anything missing from there that you know of? > What about Gnome Character Map (https://wiki.gnome.org/Gucharmap)? Even though it's Gnome, it is packed with every Xubuntu distro since I can recall. > > We want to get all the packages we're likely to want testing with a > created testcase, once we've got that we can then ensure they are ready > on packages.qa.com for the start of 14.04. > > I'm working on a simple method to enable us to call for testing of these > as and when we want them - but that won't work if we don't have > testcases available :) > There are still 14 unassigned testcases to be worked on . > Thanks > > Kev > > -- > Ubuntu Forum Council Member > Xubuntu QA Lead > Cheers, David Pires -- xubuntu-devel mailing list xubuntu-de...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/xubuntu-devel
Patch pilot 2013-07-23
51 at start * Helped with problems/questions about python-django-piston * LP: #1203958 (unity-china-photo-scope) Reviewed, needs fixing * LP: #1203931 (unity-china-video-scope) Reviewed, needs fixing * LP: #1201323 (sync python-webob and forward changes to debian) 52 at start signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tue, Jul 23, 2013 at 6:32 AM, Scott Kitterman wrote: > Assuming add-apt-repository was installed by default, it's close. I think > something like this might be reasonable (imagine some policykit or whatever it > is called now magic here): > > $ sudo apt-get source hello > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: You must put some 'source' URIs in your sources.list > Would you like 'source' URIs to be added? (y/N) > Y > deb-src lines have been added to your sources.list. > ... > Get:9 http://archive.ubuntu.com saucy/main Sources [1,001 kB] > Get:10 http://archive.ubuntu.com saucy/restricted Sources [6,578 B] > Get:11 http://archive.ubuntu.com saucy/universe Sources [6,071 kB] > > In other words, it's, I think, possible to make it roughly as easy as it is > now to get source without having the sources.list "cluttered". For users of > our releases, I doubt it saves much, but that would be a way to do it that > both avoids whatever amount of bandwidth usage is involved until the user opts > in to it, but preserves ready access to the source that I think is important. Depending on how clever and one-off you want to be you could also just give them the http url to the source as well. It shouldn't be that hard to guess since apt already has most of the information needed to just generate the URL from a chosen apt server in the normal deb. This would allow for one-off downloads (for example somebody needs to look at the way debian does some of it's compiles so they can replicate without a package so they grab the source for nginx -- that's a one-off IMO if they would never use any other source package.) Though I personally like a default command that would be something like add-apt-default-sources so you can also give them the ability to run that command and disable sources too (but you can already do that via the GUI and terminal by editing /etc/apt/sources.list and such.) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes from the Ubuntu Kernel Team meeting, 2013-07-23
= Meeting Minutes = [[http://irclogs.ubuntu.com/2013/07/23/%23ubuntu-meeting.txt|IRC Log of the meeting.]] [[http://voices.canonical.com/kernelteam|Meeting minutes.]] == Agenda == [[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 23 Jul, 2013|20130723 Meeting Agenda]] === ARM Status === nothing new to report === Release Metrics and Incoming Bugs === Release metrics and incoming bug data can be reviewed at the following link: * http://people.canonical.com/~kernel/reports/kt-meeting.txt === Milestone Targeted Work Items === || apw || foundations-1305-arm64-bringup || 1 work item || || ppisati || foundations-1305-kernel|| 1 work item || || smb || servercloud-s-virtstack|| 3 work items || === Status: Saucy Development Kernel === We have recently uploaded a new 3.10.0-5.14 Saucy kernel to the archive. This includes the v3.10.2 upstream stable patch set, as well as a fix for a regression which was causing graphics failures on boot. We have also rebased our unstable branch to begin tracking v3.11-rc2. I also want to again point out that the 12.04.3 point release is approaching on Thurs Aug 22. Any kernel patches needing to land in the 12.04.3 point release need to be applied to our Raring kernel tree on or before Mon July 29 in order to hit the SRU cadence before the point release. Please get any patches submitted to the mailing list for proper review as soon as possible. Important upcoming dates: Thurs July 25 - Alpha 2 (opt in, 2 days) Thurs Aug 22 - 12.04.3 (~4 weeks) === Status: CVE's === The current CVE status can be reviewed at the following link: * http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html === Status: Stable, Security, and Bugfix Kernel Updates - Raring/Quantal/Precise/Lucid === Status for the main kernels, until today (July 23): * Lucid - Regression testing * Precise - Regression testing * Quantal - Regression testing * Raring - Regression testing Current opened tracking bugs details: * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html For SRUs, SRU report is a good source of information: * http://people.canonical.com/~kernel/reports/sru-report.html === Open Discussion or Questions? Raise your hand to be recognized === kamal: Folks playing with 3.11-rc2 should be aware that acpi backlight is borked for many systems. A revert of the offending commits is planned in advance of 3.11-rc3. The next two meetings will be canceled due to the kernel team sprint. The next meeting will be August 13th, 2013. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch pilot report, 2013-07-23
Hello all, During my patch pilot shift I reduced the queue from 77 to 47 today. items: various syncs https://code.launchpad.net/~darkxst/ubuntu/saucy/empathy/lp1203955/+merge/176322: merge, upload https://code.launchpad.net/~gandelman-a/ubuntu/saucy/cheetah/lp1183634/+merge/176128: upload https://code.launchpad.net/~obounaim/ubuntu/saucy/python-greenlet/merge-from-debian-2/+merge/176061: upload https://code.launchpad.net/~barcc/ubuntu/saucy/pyicu/lp1200419/+merge/176028: upload https://code.launchpad.net/~jbicha/update-manager/distutils-extra-help-update/+merge/176020: merge, upload https://code.launchpad.net/~jbicha/software-properties/use-distutils-extra-auto/+merge/175975: merge https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/libnss-ldap/debian_merge/+merge/174993: needs fixing https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/net-snmp/debian_merge/+merge/175043: asked for fix, got it, uploaded https://code.launchpad.net/~obounaim/ubuntu/saucy/wget/merge-from-debian/+merge/175580: upload python-webob (LP #1201323): needs fixing https://code.launchpad.net/~manishsinha/ubuntu/saucy/nautilus/move-to-zeitgeist2/+merge/173099: FTBFS, needs fixing http://code.launchpad.net/~noskcaj/ubuntu/saucy/libav/merge0.8.7-1/+merge/174075: fix changelog, upload https://code.launchpad.net/~broder/ubuntu-dev-tools/fix-1106429/+merge/173850: merge -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On 23.07.2013 12:09, Robie Basak wrote: > It is provided by software-properties-common in more recent releases, > and is seeded on server now. See bug 439566. That is good to know. Given that my server installs are based on LTS releases I only checked the latest LTS. > All this is true, but you haven't said specifically why this proposal is > a problem, or why. This proposal *will* make source available without > having to manually install anything. And providing easy access to the > source *is* essential, but this proposal doesn't take easy access away. It adds an additional step to enable sources. Now, if the source repository would be automatically enabled when the user is requesting a source package, that would be better than giving an error and asking the user to enable it. > Others have said why the current situation is a problem, and > you haven't addressed that here at all, given that add-apt-repository > *is* available by default now. To be absolutely honest, I don't see the problem. The source index files for precise-updates and precise-security (the only pockets that are expected to change as far as I can tell) are all-together something like 1MB and have a low rate of change. Is downloading that small amount of data once a week really that much of a problem? signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 08:12:16 AM Robie Basak wrote: > On Tue, Jul 23, 2013 at 03:02:02AM -0400, Scott Kitterman wrote: > > So those are a couple of examples of what I think is definitely not what > > we > > want. I'm open to discussion about alternate ways to preserve easy access > > to the source. > > How about: > > $ sudo apt-get source hello > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: You must put some 'source' URIs in your sources.list > E: Type "add-apt-repository sources" to do this automatically for you. > $ sudo add-apt-repository sources > deb-src lines have been added to your sources.list. > Now type "apt-get update", and then "apt-get source ..." will work. > $ sudo apt-get update > (...) > $ sudo apt-get source hello > (works) > > To do this, we'd need to patch apt to add the second error line, and > implement "sources" to add-apt-repository. Assuming add-apt-repository was installed by default, it's close. I think something like this might be reasonable (imagine some policykit or whatever it is called now magic here): $ sudo apt-get source hello Reading package lists... Done Building dependency tree Reading state information... Done E: You must put some 'source' URIs in your sources.list Would you like 'source' URIs to be added? (y/N) Y deb-src lines have been added to your sources.list. ... Get:9 http://archive.ubuntu.com saucy/main Sources [1,001 kB] Get:10 http://archive.ubuntu.com saucy/restricted Sources [6,578 B] Get:11 http://archive.ubuntu.com saucy/universe Sources [6,071 kB] ... apt-get source lightdm-kde Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'lightdm-kde' packaging is maintained in the 'Git' version control system at: git://git.debian.org/pkg-kde/kde-extras/lightdm-kde.git Need to get 1,386 kB of source archives. Get:1 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (dsc) [1,543 B] Get:2 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (tar) [1,379 kB] Get:3 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (diff) [5,088 B] Fetched 1,386 kB in 1s (807 kB/s) apt-get source lightdm-kde Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'lightdm-kde' packaging is maintained in the 'Git' version control system at: git://git.debian.org/pkg-kde/kde-extras/lightdm-kde.git Need to get 1,386 kB of source archives. Get:1 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (dsc) [1,543 B] Get:2 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (tar) [1,379 kB] Get:3 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (diff) [5,088 B] Fetched 1,386 kB in 1s (807 kB/s) (and so on) In other words, it's, I think, possible to make it roughly as easy as it is now to get source without having the sources.list "cluttered". For users of our releases, I doubt it saves much, but that would be a way to do it that both avoids whatever amount of bandwidth usage is involved until the user opts in to it, but preserves ready access to the source that I think is important. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On 23 July 2013 16:24, Andreas Moog wrote: > On 23.07.2013 09:12, Robie Basak wrote: > [...] >> E: You must put some 'source' URIs in your sources.list >> E: Type "add-apt-repository sources" to do this automatically for you. >> $ sudo add-apt-repository sources >> deb-src lines have been added to your sources.list. >> Now type "apt-get update", and then "apt-get source ..." will work. >> $ sudo apt-get update >> (...) >> $ sudo apt-get source hello >> (works) >> >> To do this, we'd need to patch apt to add the second error line, and >> implement "sources" to add-apt-repository. > > andreas@j3515:~$ sudo add-apt-repository > The program 'add-apt-repository' is currently not installed. You can > install it by typing: > sudo apt-get install python-software-properties > andreas@j3515:~$ > > add-apt-repository is not available on all Ubuntu systems by default. add-apt-repository is installed by default on desktop installs. On non-desktop seeds, it is still available, just not installed. > The current solution is easy and is available on virtually all > installations, without the need to manually install anything. Providing > easy access to the source is essential for a open source distribution. You're focussing on Ubuntu as a complete solution and not a platform or enabler in stating that easy access to source is essential. Do you agree that >99% of users don't care about source? For those who do, it's easy to find and tweak sources button in the software sources applet, no? >From deploying in the real world (eg countries without domestic mirrors or with radio links), reducing bandwidth requirements of updates makes a important difference. Daniel -- Daniel J Blueman -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tue, Jul 23, 2013 at 10:24:31AM +0200, Andreas Moog wrote: > andreas@j3515:~$ sudo add-apt-repository > The program 'add-apt-repository' is currently not installed. You can > install it by typing: > sudo apt-get install python-software-properties > andreas@j3515:~$ > > add-apt-repository is not available on all Ubuntu systems by default. It is provided by software-properties-common in more recent releases, and is seeded on server now. See bug 439566. $ seeded-in-ubuntu -b software-properties-common software-properties-common is seeded in: edubuntu: dvd kubuntu-active: daily-live kubuntu: daily-live lubuntu: daily, daily-live, daily-preinstalled mythbuntu: daily-live ubuntu-gnome: daily-live ubuntu-server: daily ubuntu-touch: daily-preinstalled ubuntu: daily-live ubuntukylin: daily-live ubuntustudio: dvd xubuntu: daily-live Where, specifically, is it missing? > The current solution is easy and is available on virtually all > installations, without the need to manually install anything. Providing > easy access to the source is essential for a open source distribution. All this is true, but you haven't said specifically why this proposal is a problem, or why. This proposal *will* make source available without having to manually install anything. And providing easy access to the source *is* essential, but this proposal doesn't take easy access away. Others have said why the current situation is a problem, and you haven't addressed that here at all, given that add-apt-repository *is* available by default now. If add-apt-repository is not available by default, do you object to it *being* made available by default to resolve this? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
Hi Daniel (2013.07.23_08:13:47_+0200) > For the other 99% of users, where practicality is more important than > immediate access to source, we end up wasting ~10% of Canonical and > our mirror's bandwidth on the source updates. Can you back that up with evidence? As I (and a few other people) have repeatedly said in this thread: The release pocket lists aren't changed after release. Only -updates, -security, -backports and -proposed change, and they are all small because they are an overlay on the release pocket. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On 23.07.2013 09:12, Robie Basak wrote: [...] > E: You must put some 'source' URIs in your sources.list > E: Type "add-apt-repository sources" to do this automatically for you. > $ sudo add-apt-repository sources > deb-src lines have been added to your sources.list. > Now type "apt-get update", and then "apt-get source ..." will work. > $ sudo apt-get update > (...) > $ sudo apt-get source hello > (works) > > To do this, we'd need to patch apt to add the second error line, and > implement "sources" to add-apt-repository. andreas@j3515:~$ sudo add-apt-repository The program 'add-apt-repository' is currently not installed. You can install it by typing: sudo apt-get install python-software-properties andreas@j3515:~$ add-apt-repository is not available on all Ubuntu systems by default. The current solution is easy and is available on virtually all installations, without the need to manually install anything. Providing easy access to the source is essential for a open source distribution. signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tue, Jul 23, 2013 at 03:02:02AM -0400, Scott Kitterman wrote: > So those are a couple of examples of what I think is definitely not what we > want. I'm open to discussion about alternate ways to preserve easy access to > the source. How about: $ sudo apt-get source hello Reading package lists... Done Building dependency tree Reading state information... Done E: You must put some 'source' URIs in your sources.list E: Type "add-apt-repository sources" to do this automatically for you. $ sudo add-apt-repository sources deb-src lines have been added to your sources.list. Now type "apt-get update", and then "apt-get source ..." will work. $ sudo apt-get update (...) $ sudo apt-get source hello (works) To do this, we'd need to patch apt to add the second error line, and implement "sources" to add-apt-repository. Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tue, Jul 23, 2013 at 01:51:46AM -0400, Scott Kitterman wrote: > I think most developers would believe the current situation is appropriate. I disagree. > By default users have the same access to source and binary packages and for a > free software distribution, that is the ethically correct approach. Indeed, but you never replied to my original response to your concern. By "same access", do you specifically require the mechanism to be to keep users' local apt caches maintained with source entries? If so, why is such a mechanism necessary to fit the spirit of Free Software? If the user still has easy access to the source, why is this not sufficient? I'm happy to discuss what "easy access" might actually mean, but I see no reason that it should require the waste of users' bandwidth and time. Robie -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
(pardon the top-posting) I think the slight reduction in ethics (relevant mainly to developers) is a good trade to help deployability in the real world. We'll leave sources enabled by default for development releases. For the other 99% of users, where practicality is more important than immediate access to source, we end up wasting ~10% of Canonical and our mirror's bandwidth on the source updates. This makes a difference when behind a congested network, running on battery or so on. That 10% when accessing security.ubuntu.com really helps, particularly when topologically distant from the UK (if you have good network connectivity, ask someone who hasn't got it). No? On 23 July 2013 13:51, Scott Kitterman wrote: > On Tuesday, July 23, 2013 11:02:00 AM Daniel J Blueman wrote: >> By large, developers are uninterested in this, but it is important for >> users and where we use Ubuntu. >> >> Anyone care to comment on how we can progress this? > > I think most developers would believe the current situation is appropriate. > By default users have the same access to source and binary packages and for a > free software distribution, that is the ethically correct approach. > > Scott K > >> On 15 July 2013 13:32, Daniel J Blueman wrote: >> > From earlier feedback, there were no overriding reasons why package >> > sources should be enabled by default. >> > >> > We not only save congestion on security.ubuntu.com, but quite a lot of >> > country-level mirrors point to Canonical's servers, which are >> > relatively distant and slow (~80KB/s from here), so this is a win. >> > >> > So, what's the path to change this? >> > >> > On 21 May 2013 22:04, J Fernyhough wrote: >> >> On 21 May 2013 13:55, Robie Basak wrote: >> >>> What if we provided a reasonable message if no deb-src lines are >> >>> defined, with a single simple command to add them and run "apt-get >> >>> update" for you? >> >> >> >> I don't think it would even need that - software-properties (Software >> >> & Updates) already has the necessary checkbox. All that is needed to >> >> enable sources is to tick that box. >> >> >> >>> From a technical point of view, does mirroring the deb lines into >> >>> deb-src lines work in all cases? Would doing so break anything? >> >> >> >> This is effectively what Software Sources does under-the-hood. >> >> >> >> I have to agree, if the amount being downloaded is not trivial (which >> >> I thought it was) then there's no need to have them enabled by default >> >> when it's very easy to turn them on. One of the first things I do on >> >> any new install is disable those that aren't needed. >> >> >> >> Jonathon >> >> >> >> (to the list this time) >> >> >> >> -- >> >> Ubuntu-devel-discuss mailing list >> >> ubuntu-devel-disc...@lists.ubuntu.com >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss> >> > -- >> > Daniel J Blueman > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Daniel J Blueman -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 06:59:43 AM Robie Basak wrote: > On Tue, Jul 23, 2013 at 01:51:46AM -0400, Scott Kitterman wrote: > > I think most developers would believe the current situation is > > appropriate. > > I disagree. > > > By default users have the same access to source and binary packages and > > for a free software distribution, that is the ethically correct approach. > Indeed, but you never replied to my original response to your concern. > By "same access", do you specifically require the mechanism to be to > keep users' local apt caches maintained with source entries? If so, why > is such a mechanism necessary to fit the spirit of Free Software? If the > user still has easy access to the source, why is this not sufficient? > > I'm happy to discuss what "easy access" might actually mean, but I see > no reason that it should require the waste of users' bandwidth and time. Sorry. I didn't mean to ignore you. What's easy? For example, I think "install more packages to get the tools to get the source" (use pull-lp-source in ubuntu-dev-tools) doesn't qualify. There are tons of documentation all over the web and other places as well that assume apt-get source works. I think access using installed tools that are normally used for the job (wget is installed (I think) by default, but I don't think having to go to a web page to find a URL and then wget'ing the components of the source package is easy either. So those are a couple of examples of what I think is definitely not what we want. I'm open to discussion about alternate ways to preserve easy access to the source. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
